pax_global_header00006660000000000000000000000064130167574670014532gustar00rootroot0000000000000052 comment=feb6160765dbd40bcf2400e2eb8e0824510fba4b scap-security-guide-0.1.31/000077500000000000000000000000001301675746700155025ustar00rootroot00000000000000scap-security-guide-0.1.31/.gitignore000066400000000000000000000017621301675746700175000ustar00rootroot00000000000000# Files and directories not to track in git tree # Global files for the entire tree *.swp *~ *.pyc # RPM build files rpmbuild scap-security-guide.spec **/build/* # Ignore dist directories but remember dist/README files **/dist !**/dist/README # Ignore .ini files in the following directories # */input/oval # */transforms # */output **/input/oval/*.ini **/transforms/*.ini **/output/* # Ignore docs tmp directories docs/Developer_Guide/tmp docs/SCAP_and_STIG_Workshop/tmp docs/User_Guide/tmp # Ignore docs publish directories docs/Developer_Guide/publish docs/SCAP_and_STIG_Workshop/publish docs/User_Guide/publish # Ignore docs SCAP_Security_Guide directory docs/html/en-US/SCAP_Security_Guide # Ignore shared directory .ini files shared/*.ini shared/modules/*.ini shared/oval/*.ini # Ignore intermediary output XML files in the shared directory shared/output/*.xml # Ignore PCI_DSS_v3-1.pdf shared/transforms/pcidss/PCI_DSS_v3-1.pdf # Ignore zipfile and tarball dirs zipfile/ tarball/ scap-security-guide-0.1.31/BUILD.md000066400000000000000000000040571301675746700166710ustar00rootroot00000000000000# Build from source 1. On Red Hat Enterprise Linux and Fedora make sure the packages `openscap-utils`, `openscap-python`, and `python-lxml` and their dependencies are installed. We require version `1.0.8` or later of `openscap-utils` (available in Red Hat Enterprise Linux) as well as `git`. `# yum -y install git openscap-utils openscap-python python-lxml` On Ubuntu make sure the packages `expat`, `libopenscap8`, `libxml2-utils`, `python-lxml`, `python-openscap`, and `xsltproc` and their dependencies are installed. `$ sudo apt -y install expat libopenscap8 libxml2-utils python-lxml python-openscap xsltproc` 1a. FEDORA ONLY: Install the ShellCheck package. `# dnf -y install ShellCheck` 2. Download the source code `$ git clone https://github.com/OpenSCAP/scap-security-guide.git` 3. Build the source code * To build all the content: `$ cd scap-security-guide/` `$ make` * To build an RPM for development/testing or non-official release use: `$ cd scap-security-guide/` `$ make rpm` * To build an RPM for official release use: `$ cd scap-security-guide/` `$ make SSG_VERSION_IS_GIT_SNAPSHOT=no rpm` * To build content only for a specific distribution: `$ cd scap-security-guide/` `$ make rhel6` Or alternatively, content can be made within the sub-group (e.g. RHEL7, RHEL6): `$ cd scap-security-guide/RHEL/6/` `$ make` When the content has completed the build process, the built content exists in the distribution's `output` directory. For example: `$ cd scap-security-guide/RHEL/6/output` 4. Discover the following: * A pretty prose guide **in rhel6-guide.html** containing practical, actionable information for administrators * A concise spreadsheet representation (potentially useful as the basis for an SRTM document) in **rhel6-table-nistrefs-server.html** * Files that can be ingested by SCAP-compatible scanning tools, to enable automated checking: * **ssg-rhel6-xccdf.xml** * **ssg-rhel6-oval.xml** * **ssg-rhel6-ds.xml** scap-security-guide-0.1.31/Chromium/000077500000000000000000000000001301675746700172655ustar00rootroot00000000000000scap-security-guide-0.1.31/Chromium/DISCLAIMER000066400000000000000000000004631301675746700206270ustar00rootroot00000000000000The SCAP content provided for Chromium, is based on the STIG requirements released by the DISA FSO. However, this content is in its initial stage of development and will be subject to ongoing changes as it matures. At this point in development there should be no expectation of accuracy or completeness. scap-security-guide-0.1.31/Chromium/Makefile000066400000000000000000000153451301675746700207350ustar00rootroot00000000000000all: tables guide content dist SHARED = ../shared include $(SHARED)/product-make.include PROD = chromium VENDOR = ssgproject checks: xmlwf $(IN)/oval/*.xml $(SHARED)/$(UTILS)/combine-ovals.py $(CONF) $(PROD) $(IN)/oval > $(OUT)/unlinked-$(PROD)-oval.xml xmllint --format --output $(OUT)/unlinked-$(PROD)-oval.xml $(OUT)/unlinked-$(PROD)-oval.xml # example, if needed: for converting XCCDF into shorthand #xccdf2shorthand: # xsltproc -o $(XCCDF_OUTPUT_DIR)/$(PROD)-shorthand.xml $(TRANS)/xccdf2shorthand.xslt $(REFS)/usgcb-$(PROD)desktop-xccdf.xml # tidy -m -xml -utf8 --indent-spaces=0 $(XCCDF_OUTPUT_DIR)/$(PROD)-shorthand.xml table-refs: $(OUT)/xccdf-unlinked-final.xml xsltproc -stringparam ref "nist" -o $(OUT)/table-$(PROD)-nistrefs.html $(TRANS)/xccdf2table-byref.xslt $< xsltproc -stringparam profile "common" -o $(OUT)/table-$(PROD)-nistrefs-common.html \ $(TRANS)/xccdf2table-profilenistrefs.xslt $< table-idents: $(OUT)/xccdf-unlinked-final.xml xsltproc -o $(OUT)/table-$(PROD)-cces.html $(TRANS)/xccdf2table-cce.xslt $< table-srgmap: $(OUT)/xccdf-unlinked-final.xml # the map-to-items filename must be provided relative to the root of the main document being processed xsltproc -stringparam map-to-items "../$<" -o $(OUT)/table-$(PROD)-srgmap.html \ $(TRANS)/table-srgmap.xslt $(REFS)/disa-google-chrome-browser-v1r2-stig.xml xsltproc -stringparam flat "y" -stringparam map-to-items "../$<" -o $(OUT)/table-$(PROD)-srgmap-flat.html \ $(TRANS)/table-srgmap.xslt $(REFS)/disa-google-chrome-browser-v1r2-stig.xml xmllint --xmlout --html --output $(OUT)/table-$(PROD)-srgmap-flat.xhtml $(OUT)/table-$(PROD)-srgmap-flat.html table-stigs: $(OUT)/xccdf-unlinked-final.xml table-srgmap checks xsltproc -o $(OUT)/table-$(PROD)-stig.html $(TRANS)/xccdf2table-stig.xslt $(REFS)/disa-google-chrome-browser-v1r2-stig.xml # xsltproc -o $(OUT)/table-$(PROD)-stig-manual.html $(TRANS)/xccdf2table-stig.xslt $(REFS)/u_google_chrome_browser_v1r2_stig.xml # xsltproc -stringparam notes "../$(IN)/auxiliary/transition_notes.xml" -o $(OUT)/table-$(PROD)-stig-manual-withnotes.html \ # $(TRANS)/xccdf2table-stig.xslt \ # $(REFS)/disa-stig-$(PROD)-v1r0.6-xccdf-manual.xml # temporarily retain an output file showing the short titles as well xsltproc -stringparam profile "stig-$(PROD)-upstream" -stringparam testinfo "y" -o $(OUT)/table-stig-$(PROD)-testinfo.html \ $(TRANS)/xccdf2table-profileccirefs.xslt $< xsltproc -stringparam overlay "../$(IN)/auxiliary/stig_overlay.xml" -o $(OUT)/unlinked-stig-$(PROD)-xccdf.xml \ $(TRANS)/xccdf-apply-overlay-stig.xslt $< xsltproc -o $(OUT)/table-$(PROD)-stig.html $(TRANS)/xccdf2table-stig.xslt $(OUT)/unlinked-stig-$(PROD)-xccdf.xml tables: table-refs table-idents table-stigs #tables: table-refs table-idents table-srgmap table-stigs content: $(OUT)/xccdf-unlinked-final.xml checks cp $< $(OUT)/unlinked-$(PROD)-xccdf.xml # Remove auxiliary Groups which are only for use in tables, and not guide output. xsltproc -o $(OUT)/unlinked-$(PROD)-xccdf-guide.xml $(TRANS)/xccdf-removeaux.xslt $(OUT)/unlinked-$(PROD)-xccdf.xml # The relabel-ids.py script chdirs to ./output, so refer to files from there. # its second argument controls the IDs, as well as the output filenames. # thus, with ID set to ssg, this creates ssg-$(PROD)-xccdf.xml and ssg-$(PROD)-oval.xml. $(SHARED)/$(UTILS)/cpe-generate.py $(OUT)/unlinked-$(PROD)-oval.xml $(IN)/oval/platform/$(PROD)-cpe-dictionary.xml $(ID) $(SHARED)/$(UTILS)/relabel-ids.py unlinked-$(PROD)-xccdf.xml $(ID) $(SHARED)/$(UTILS)/relabel-ids.py xccdf-unlinked-ocilrefs.xml $(ID) # Once things are relabelled, create a datastream xsltproc --stringparam reverse_DNS org.$(VENDOR).content /usr/share/openscap/xsl/xccdf_1.1_to_1.2.xsl \ $(OUT)/$(ID)-$(PROD)-xccdf.xml > $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml # Update @style attribute of to "SCAP_1.2". Fixes #1059 sed -i 's/style="SCAP_1.1"/style="SCAP_1.2"/' $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml oscap ds sds-compose $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml $(OUT)/$(ID)-$(PROD)-ds.xml # Update @schematron-version attribute in datastream to "1.2". Fixes #1191 # (Workaround for https://github.com/OpenSCAP/openscap/issues/383) sed -i 's/schematron-version="[0-9].[0-9]"/schematron-version="1.2"/' $(OUT)/$(ID)-$(PROD)-ds.xml # Add in CPE and OVAL content to datastream oscap ds sds-add $(OUT)/$(ID)-$(PROD)-cpe-dictionary.xml $(OUT)/$(ID)-$(PROD)-ds.xml oscap ds sds-add $(OUT)/$(ID)-$(PROD)-oval.xml $(OUT)/$(ID)-$(PROD)-ds.xml # Fixes https://github.com/OpenSCAP/scap-security-guide/issues/1100 # Fixes https://github.com/OpenSCAP/scap-security-guide/issues/1101 $(SHARED)/$(UTILS)/sds-move-ocil-to-checks.py $(OUT)/$(ID)-$(PROD)-ds.xml $(OUT)/$(ID)-$(PROD)-ds.xml content-stig: table-stigs guide checks xmllint --format --output $(OUT)/unlinked-stig-$(PROD)-xccdf.xml $(OUT)/unlinked-stig-$(PROD)-xccdf.xml $(SHARED)/$(UTILS)/cpe-generate.py $(OUT)/unlinked-$(PROD)-oval.xml $(IN)/oval/platform/$(PROD)-cpe-dictionary.xml disa-predraft $(SHARED)/$(UTILS)/relabel-ids.py unlinked-stig-$(PROD)-xccdf.xml disa-predraft xmllint --format --output $(OUT)/disa-predraft-stig-$(PROD)-xccdf.xml $(OUT)/disa-predraft-stig-$(PROD)-xccdf.xml guide: content ifeq ($(OPENSCAP_1_1_OR_LATER), 0) $(SHARED)/$(UTILS)/build-all-guides.py --input $(OUT)/$(ID)-$(PROD)-ds.xml else @echo "Building guides from XCCDF 1.1, use OpenSCAP 1.1.0 or later for guides from datastreams!" $(SHARED)/$(UTILS)/build-all-guides.py --input $(OUT)/$(ID)-$(PROD)-xccdf.xml endif submission-stig-check: table-stigs cd $(OUT); ../$(SHARED)/$(UTILS)/verify-references.py -p stig-$(PROD)-upstream \ --rules-with-disarefs-outside-profile unlinked-$(PROD)-xccdf-prerefs.xml # $(TRANS)/xccdf2csv-stig.py $(OUT)/unlinked-stig-$(PROD)-xccdf.xml > $(OUT)/table-stig.csv # content-usgcb: coming soon validate-xml: oscap xccdf validate-xml $(OUT)/$(ID)-$(PROD)-xccdf.xml oscap oval validate-xml --schematron $(OUT)/$(ID)-$(PROD)-oval.xml oscap cpe validate-xml $(OUT)/$(ID)-$(PROD)-cpe-dictionary.xml oscap oval validate-xml --schematron $(OUT)/$(ID)-$(PROD)-cpe-oval.xml oscap ds sds-validate $(OUT)/$(ID)-$(PROD)-ds.xml validate: validate-xml cd $(OUT); ../$(SHARED)/$(UTILS)/verify-references.py --rules-with-invalid-checks --ovaldefs-unused ssg-$(PROD)-xccdf.xml # Items in dist are expected for distribution in an rpm dist: tables guide content mkdir -p $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-xccdf.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-oval.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-ocil.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-cpe-dictionary.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-cpe-oval.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-ds.xml $(DIST)/content mkdir -p $(DIST)/guide cp $(OUT)/*-guide-*.html $(DIST)/guide clean: rm -rf $(OUT)/* rm -rf $(DIST)/content $(DIST)/guide rm -rf $(BUILD) scap-security-guide-0.1.31/Chromium/input/000077500000000000000000000000001301675746700204245ustar00rootroot00000000000000scap-security-guide-0.1.31/Chromium/input/auxiliary/000077500000000000000000000000001301675746700224335ustar00rootroot00000000000000scap-security-guide-0.1.31/Chromium/input/auxiliary/stig_overlay.xml000066400000000000000000000217171301675746700256740ustar00rootroot00000000000000 Firewall traversal from remote host must be disabled. Sites ability for showing desktop notifications must be disabled. Sites ability to show pop-ups must be disabled. Site tracking users location must be disabled. Extensions installation must be blacklisted by default. Extensions that are approved for use must be whitelisted. The default search providers name must be set. The default search provider URL must be set to perform encrypted searches. Default search provider must be enabled. Use of cleartext passwords in Password Manager must be disabled. The Password Manager must be disabled. The HTTP Authentication must be set to negotiate. The running of outdated plugins must be disabled. Plugins requiring authorization must ask for user permission. Third party cookes must be blocked. Background processing must be disabled. 3D Graphics APIs must be disabled. Google Data Synchronization must be disabled. The URL protocol schema javascript must be disabled. Autofill must be disabled. Cloud print mush be disabled. Network prediction must be disabled. Metrics reporting to Google must be disabled. Search suggestions must be disabled. Importing of saved passwords must be disabled. Metrics reporting to Google must be disabled. Plugins must be disabled by default. Plugins approved for use must be enabled. Automated installation of missing plugins must be disabled. Online revocation checks must be done. Safe Browsing must be enabled. Browser history must be saved. Default behavior must block webpages from automatically running plugins. Session only based cookies must be disabled. The home page must be set to a trusted site. URLs must be whitelisted for plugin use. scap-security-guide-0.1.31/Chromium/input/guide.xslt000066400000000000000000000035701301675746700224420ustar00rootroot00000000000000 A conditional clause for check statements. A conditional clause for check statements. This is a placeholder. scap-security-guide-0.1.31/Chromium/input/oval/000077500000000000000000000000001301675746700213655ustar00rootroot00000000000000scap-security-guide-0.1.31/Chromium/input/oval/chromium_blacklist_extension_installation.xml000066400000000000000000000022741301675746700326440ustar00rootroot00000000000000 Blacklist Extension Installation Google Chromium Browser Extensions installation must be blacklisted by default. /etc/chromium/policies/managed/.*\.json ^\{([^\n]*\n+)+[\s]+\"ExtensionInstallBlacklist\"\:[\s]+\[\"\*\"\], 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_block_desktop_notifications.xml000066400000000000000000000022371301675746700315720ustar00rootroot00000000000000 Block Desktop Notifications Google Chromium Browser Sites ability for showing desktop notifications must be disabled. /etc/chromium/policies/managed/.*\.json ^\{([^\n]*\n+)+[\s]+\"DefaultNotificationsSetting\"\:[\s]+2, 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_check_cert_revocation.xml000066400000000000000000000022151301675746700303350ustar00rootroot00000000000000 Check Certificate Revocation Google Chromium Browser Online revocation checks must be done. /etc/chromium/policies/managed/.*\.json ^\{([^\n]*\n+)+[\s]+\"EnableOnlineRevocationChecks\"\:[\s]+true, 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_default_block_plugins.xml000066400000000000000000000022361301675746700303540ustar00rootroot00000000000000 Block Plugin Execution By Default Google Chromium Browser Default behavior must block webpages from automatically running plugins. /etc/chromium/policies/managed/.*\.json ^\{([^\n]*\n+)+[\s]+\"DefaultPluginsSetting\"\:[\s]+3, 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_default_search_provider.xml000066400000000000000000000022371301675746700307010ustar00rootroot00000000000000 Enable Default Search Provider Google Chromium Browser Default search provider must be enabled. /etc/chromium/policies/managed/.*\.json ^\{([^\n]*\n+)+[\s]+\"DefaultSearchProviderEnabled\"\:[\s]+true, 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_default_search_provider_name.xml000066400000000000000000000030611301675746700316750ustar00rootroot00000000000000 Set Default Search Provider Name Google Chromium Browser The default search providers name must be set. /etc/chromium/policies/managed/.*\.json ^[\s]+"DefaultSearchProviderName"\:[\s]+"(\S+)",$ 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_disable_3d_graphics_api.xml000066400000000000000000000021701301675746700305140ustar00rootroot00000000000000 Disable 3D Graphics APIs Google Chromium Browser 3D Graphics APIs must be disabled. /etc/chromium/policies/managed/.*\.json ^\{([^\n]*\n+)+[\s]+\"Disable3DAPIs\"\:[\s]+true, 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_disable_autocomplete.xml000066400000000000000000000021661301675746700302030ustar00rootroot00000000000000 Disable Autocomplete For Forms Google Chromium Browser AutoFill must be disabled. /etc/chromium/policies/managed/.*\.json ^\{([^\n]*\n+)+[\s]+\"AutoFillEnabled\"\:[\s]+false, 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_disable_automatic_installation.xml000066400000000000000000000024021301675746700322420ustar00rootroot00000000000000 Disable Automatic Plugin Search And Installation Google Chromium Browser Automated installation of missing plugins must be disabled. /etc/chromium/policies/managed/.*\.json ^\{([^\n]*\n+)+[\s]+\"DisablePluginFinder\"\:[\s]+true, 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_disable_background_processing.xml000066400000000000000000000022631301675746700320530ustar00rootroot00000000000000 Disable Background Processing Google Chromium Browser Background processing must be disabled. /etc/chromium/policies/managed/.*\.json ^\{([^\n]*\n+)+[\s]+\"BackgroundModeEnabled\"\:[\s]+false, 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_disable_cleartext_passwords.xml000066400000000000000000000023051301675746700315750ustar00rootroot00000000000000 Disable Cleartext Passwords Google Chromium Browser Cleartext passwords in the Password Manager must be disabled. /etc/chromium/policies/managed/.*\.json ^\{([^\n]*\n+)+[\s]+\"PasswordManagerAllowShowPasswords\"\:[\s]+false, 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_disable_cloud_print_sharing.xml000066400000000000000000000022421301675746700315320ustar00rootroot00000000000000 Disable Cloud Print Sharing Google Chromium Browser Cloud print sharing must be disabled. /etc/chromium/policies/managed/.*\.json ^\{([^\n]*\n+)+[\s]+\"CloudPrintProxyEnabled\"\:[\s]+false, 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_disable_firewall_traversal.xml000066400000000000000000000022351301675746700313670ustar00rootroot00000000000000 Disable Firewall Traversal Google Chromium Browser Firewall traversal from remote host must be disabled. /etc/chromium/policies/managed/.*\.json ^\{([^\n]*\n+)+[\s]+\"RemoteAccessHostFirewallTraversal\"\:[\s]+false, 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_disable_google_sync.xml000066400000000000000000000021711301675746700300060ustar00rootroot00000000000000 Disable Google Data Synchronization Google Chromium Browser Google Data Synchronization must be disabled. /etc/chromium/policies/managed/.*\.json ^\{([^\n]*\n+)+[\s]+\"SyncDisabled\"\:[\s]+true, 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_disable_incognito_mode.xml000066400000000000000000000021641301675746700304750ustar00rootroot00000000000000 Disable Incognito Mode Google Chromium Browser Incognito mode must be disabled. /etc/chromium/policies/managed/.*\.json ^\{([^\n]*\n+)+[\s]+\"IncognitoModeAvailability\"\:[\s]+1, 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_disable_metrics_reporting.xml000066400000000000000000000022331301675746700312340ustar00rootroot00000000000000 Disable Metrics Reporting Google Chromium Browser Metrics reporting to Google must be disabled. /etc/chromium/policies/managed/.*\.json ^\{([^\n]*\n+)+[\s]+\"MetricsReportingEnabled\"\:[\s]+false, 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_disable_network_prediction.xml000066400000000000000000000022301301675746700314030ustar00rootroot00000000000000 Disable Network Prediction Google Chromium Browser Network prediction must be disabled. /etc/chromium/policies/managed/.*\.json ^\{([^\n]*\n+)+[\s]+\"DnsPrefetchingEnabled\"\:[\s]+false, 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_disable_outdated_plugins.xml000066400000000000000000000022241301675746700310470ustar00rootroot00000000000000 Disable Outdated Plugins Google Chromium Browser The running of outdated plugins must be disabled. /etc/chromium/policies/managed/.*\.json ^\{([^\n]*\n+)+[\s]+\"AllowOutdatedPlugins\"\:[\s]+false, 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_disable_password_manager.xml000066400000000000000000000022131301675746700310270ustar00rootroot00000000000000 Disable Password Manager Google Chromium Browser The Password Manager must be disabled. /etc/chromium/policies/managed/.*\.json ^\{([^\n]*\n+)+[\s]+\"PasswordManagerEnabled\"\:[\s]+false, 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_disable_plugin_blacklist.xml000066400000000000000000000021441301675746700310240ustar00rootroot00000000000000 Blacklist Plugins Google Chromium Browser Plugins must be disabled by default. /etc/chromium/policies/managed/.*\.json ^\{([^\n]*\n+)+[\s]+\"DisabledPlugins\"\:[\s]+\[\"\*\"\], 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_disable_popups.xml000066400000000000000000000021011301675746700270150ustar00rootroot00000000000000 Disable Pop-ups Google Chromium Browser Sites ability to show pop-ups must be disabled. /etc/chromium/policies/managed/.*\.json ^\{([^\n]*\n+)+[\s]+\"DefaultPopupsSetting\"\:[\s]+2, 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_disable_protocol_schemas.xml000066400000000000000000000030571301675746700310460ustar00rootroot00000000000000 Disable Javascript URL Protocol Schemas Google Chromium Browser The URL protocol schema javascript must be disabled. /etc/chromium/policies/managed/.*\.json ^[\s]+\"URLBlacklist\"\:[\s]+\[\"(\S+)"\], 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_disable_saved_passwords.xml000066400000000000000000000022471301675746700307110ustar00rootroot00000000000000 Disable Importing Saved Passwords Google Chromium Browser Importing of saved passwords must be disabled. /etc/chromium/policies/managed/.*\.json ^\{([^\n]*\n+)+[\s]+\"ImportSavedPasswords\"\:[\s]+false, 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_disable_search_suggestions.xml000066400000000000000000000022271301675746700313770ustar00rootroot00000000000000 Disable Search Suggestopms Google Chromium Browser Search suggestions must be disabled. /etc/chromium/policies/managed/.*\.json ^\{([^\n]*\n+)+[\s]+\"SearchSuggestEnabled\"\:[\s]+false, 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_disable_session_cookies.xml000066400000000000000000000022231301675746700306730ustar00rootroot00000000000000 Disable Per Session Cookies Google Chromium Browser Session only based cookies must be disabled. /etc/chromium/policies/managed/.*\.json ^[\s]+\"CookiesSessionOnlyForUrls\"\:[\s]+\[\"(none|)"\], 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_disable_thirdparty_cookies.xml000066400000000000000000000022271301675746700314060ustar00rootroot00000000000000 Disable Third Party Cookies Google Chromium Browser Third party cookies must be blocked. /etc/chromium/policies/managed/.*\.json ^\{([^\n]*\n+)+[\s]+\"BlockThirdPartyCookies\"\:[\s]+true, 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_disallow_location_tracking.xml000066400000000000000000000021761301675746700314100ustar00rootroot00000000000000 Disallow Location Tracking Google Chromium Browser Site tracking users location must be disabled. /etc/chromium/policies/managed/.*\.json ^\{([^\n]*\n+)+[\s]+\"DefaultGeolocationSetting\"\:[\s]+2, 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_enable_approved_plugins.xml000066400000000000000000000022101301675746700306740ustar00rootroot00000000000000 Enable Approved Plugins Google Chromium Browser Plugins approved for use must be enabled. /etc/chromium/policies/managed/.*\.json ^[\s]+\"EnabledPlugins\"\:[\s]+\[\"((none|[a-zA-Z]*)|!*)\"\], 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_enable_browser_history.xml000066400000000000000000000021711301675746700305650ustar00rootroot00000000000000 Enable Browser History Google Chromium Browser Browser history must be saved. /etc/chromium/policies/managed/.*\.json ^\{([^\n]*\n+)+[\s]+\"SavingBrowserHistoryDisabled\"\:[\s]+false, 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_enable_encrypted_searching.xml000066400000000000000000000030571301675746700313450ustar00rootroot00000000000000 Enable Encrypted Searching Google Chromium Browser The default search provider URL must be set to perform encrypted searches. /etc/chromium/policies/managed/.*\.json ^[\s]+\"DefaultSearchProviderSearchURL\"\:[\s]+\"(\S+)", 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_enable_safe_browsing.xml000066400000000000000000000021411301675746700301460ustar00rootroot00000000000000 Enable Safe Browsing Google Chromium Browser Safe Browsing must be enabled. /etc/chromium/policies/managed/.*\.json ^\{([^\n]*\n+)+[\s]+\"SafeBrowsingEnabled\"\:[\s]+true, 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_extension_whitelist.xml000066400000000000000000000030041301675746700301170ustar00rootroot00000000000000 Extension Whitelist Google Chromium Browser Extensions that are approved for use must be whitelisted. /etc/chromium/policies/managed/.*\.json ^[\s]+\"ExtensionInstallWhitelist\"\:[\s]+\[\"(\S+)\"], 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_http_authentication.xml000066400000000000000000000027541301675746700301000ustar00rootroot00000000000000 HTTP Authentication Google Chromium Browser The HTTP Authentication must be set to negotiate. /etc/chromium/policies/managed/.*\.json ^[\s]+\"AuthSchemes\"\:[\s]+\"(\S+)\", 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_plugins_require_authorization.xml000066400000000000000000000023111301675746700322040ustar00rootroot00000000000000 Plugins Require Authentication Google Chromium Browser Plugins requiring authorization must ask for user permission. /etc/chromium/policies/managed/.*\.json ^\{([^\n]*\n+)+[\s]+\"AlwaysAuthorizePlugins\"\:[\s]+false, 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_policy_file.xml000066400000000000000000000021041301675746700263050ustar00rootroot00000000000000 Chromium Policy File Exists Google Chromium Browser The Chromium policy file must exist and be configured correctly. /etc/chromium/policies/managed/.*\.json ^\{([^\n]*\n+)+[\s]+\".*\"\:[\s]+.*,([^\n]*\n+)+\} 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_trusted_home_page.xml000066400000000000000000000027351301675746700275170ustar00rootroot00000000000000 Set Trusted Homepage URL Google Chromium Browser The homepage must be set to a trusted site. /etc/chromium/policies/managed/.*\.json ^[\s]+\"HomepageLocation\"\:[\s]+\"(\S+)\", 1 scap-security-guide-0.1.31/Chromium/input/oval/chromium_whitelist_plugin_urls.xml000066400000000000000000000022021301675746700304450ustar00rootroot00000000000000 Configure Whitelisted Plugins For Use Google Chromium Browser URLs must be whitelisted for plugin use. /etc/chromium/policies/managed/.*\.json ^[\s]+\"PluginsAllowedForUrls\"\:[\s]+\[\"(none|!*)\"\], 1 scap-security-guide-0.1.31/Chromium/input/oval/installed_OS_is_part_of_Unix_family.xml000066400000000000000000000020271301675746700312410ustar00rootroot00000000000000 Installed operating system is part of the Unix family Google Chromium Browser The operating system installed on the system is part of the Unix OS family unix scap-security-guide-0.1.31/Chromium/input/oval/installed_app_is_chromium.xml000066400000000000000000000031761301675746700273330ustar00rootroot00000000000000 Google Chromium Browser Google Chromium Browser The application installed on the system is the Google Chromium Browser chromium-browser chromium scap-security-guide-0.1.31/Chromium/input/oval/platform/000077500000000000000000000000001301675746700232115ustar00rootroot00000000000000scap-security-guide-0.1.31/Chromium/input/oval/platform/chromium-cpe-dictionary.xml000066400000000000000000000012311301675746700304630ustar00rootroot00000000000000 Google Chromium Browser installed_app_is_chromium scap-security-guide-0.1.31/Chromium/input/oval/testoval.py000077500000000000000000000003471301675746700236070ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import testoval_module if __name__ == "__main__": testoval_module.main() scap-security-guide-0.1.31/Chromium/input/profiles/000077500000000000000000000000001301675746700222475ustar00rootroot00000000000000scap-security-guide-0.1.31/Chromium/input/profiles/stig-chromium-upstream.xml000066400000000000000000000103301301675746700274130ustar00rootroot00000000000000 Upstream STIG for Google Chromium This profile is developed under the DoD consensus model and DISA FSO Vendor STIG process, serving as the upstream development environment for the Google Chromium STIG. As a result of the upstream/downstream relationship between the SCAP Security Guide project and the official DISA FSO STIG baseline, users should expect variance between SSG and DISA FSO content. For official DISA FSO STIG content, refer to http://iase.disa.mil/stigs/app-security/browser-guidance/Pages/index.aspx. While this profile is packaged by Red Hat as part of the SCAP Security Guide package, please note that commercial support of this SCAP content is NOT available. This profile is provided as example SCAP content with no endorsement for suitability or production readiness. Support for this profile is provided by the upstream SCAP Security Guide community on a best-effort basis. The upstream project homepage is https://www.open-scap.org/security-policies/scap-security-guide/. scap-security-guide-0.1.31/Debian/8/input/profiles/common.xml000066400000000000000000000052041301675746700240300ustar00rootroot00000000000000 Common Profile for General-Purpose Debian Systems This profile contains items common to general-purpose Debian 8 installations. scap-security-guide-0.1.31/Fedora/input/xccdf/000077500000000000000000000000001301675746700211305ustar00rootroot00000000000000scap-security-guide-0.1.31/Fedora/input/xccdf/services/000077500000000000000000000000001301675746700227535ustar00rootroot00000000000000scap-security-guide-0.1.31/Fedora/input/xccdf/services/audit.xml000066400000000000000000000022471301675746700246100ustar00rootroot00000000000000 Audit Deamon The Linux Audit system provides a way to track security-relevant information on your system. Based on pre-configured rules, Audit generates log entries to record as much information about the events that are happening on your system as possible. This information is crucial for mission-critical environments to determine the violator of the security policy and the actions they performed. Audit does not provide additional security to your system; rather, it can be used to discover violations of security policies used on your system. These violations can further be prevented by additional security measures such as SELinux. Enable the Audit Daemon Enabling the auditd service ensures that The Linux Audit system is capable to watch the system and generate log entries. scap-security-guide-0.1.31/Fedora/input/xccdf/services/cron.xml000066400000000000000000000076261301675746700244510ustar00rootroot00000000000000 Cron and At Daemons The cron and at services are used to allow commands to be executed at a later time. The cron service is required by almost all systems to perform necessary maintenance tasks, while at may or may not be required on a given system. Both daemons should be configured defensively. Enable cron Service The crond service is used to execute commands at preconfigured times. It is required by almost all systems to perform necessary maintenance tasks, such as notifying root of system activity. Due to its usage for maintenance and security-supporting tasks, enabling the cron daemon is essential. Disable anacron Service The cronie-anacron package, which provides anacron functionality, is installed by default. The anacron service provides cron functionality for systems such as laptops and workstations that may be shut down during the normal times that cron jobs are scheduled to run. On systems which do not require this additional functionality, anacron could needlessly increase the possible attack surface for an intruder. Disable At Service (atd) The at and batch commands can be used to schedule tasks that are meant to be executed only once. This allows delayed execution in a manner similar to cron, except that it is not recurring. The daemon atd keeps track of tasks scheduled via at and batch, and executes them at the specified time. The atd service could be used by an unsophisticated insider to carry out activities outside of a normal login session, which could complicate accountability. Furthermore, the need to schedule tasks with at or batch is not common. Restrict at and cron to Authorized Users if Necessary The /etc/cron.allow and /etc/at.allow files contain lists of users who are allowed to use cron and at to delay execution of processes. If these files exist and if the corresponding files /etc/cron.deny and /etc/at.deny do not exist, then only users listed in the relevant allow files can run the crontab and at commands to submit jobs to be run at scheduled intervals. On many systems, only the system administrator needs the ability to schedule jobs. Note that even if a given user is not listed in cron.allow, cron jobs can still be run as that user. The cron.allow file controls only administrative access to the crontab command for scheduling and modifying cron jobs.

To restrict at and cron to only authorized users:
  • Remove the cron.deny file:
    $ sudo rm /etc/cron.deny
  • Edit /etc/cron.allow, adding one line for each user allowed to use the crontab command to create cron jobs.
  • Remove the at.deny file:
    $ sudo rm /etc/at.deny
  • Edit /etc/at.allow, adding one line for each user allowed to use the at command to create at jobs.
 scap-security-guide-0.1.31/Fedora/input/xccdf/services/ftp.xml000066400000000000000000000245201301675746700242710ustar00rootroot00000000000000 FTP Server FTP is a common method for allowing remote access to files. Like telnet, the FTP protocol is unencrypted, which means that passwords and other data transmitted during the session can be captured and that the session is vulnerable to hijacking. Therefore, running the FTP server software is not recommended.

However, there are some FTP server configurations which may be appropriate for some environments, particularly those which allow only read-only anonymous access as a means of downloading data available to the public. Disable vsftpd if Possible Disable vsftpd Service Running FTP server software provides a network-based avenue of attack, and should be disabled if not needed. Furthermore, the FTP protocol is unencrypted and creates a risk of compromising sensitive information. Uninstall vsftpd Package Removing the vsftpd package decreases the risk of its accidental activation. Use vsftpd to Provide FTP Service if Necessary Install vsftpd Package If this machine must operate as an FTP server, install the vsftpd package via the standard channels. 
$ sudo dnf install vsftpd
 After Red Hat Enterprise Linux 2.1, Red Hat switched from distributing wu-ftpd with Red Hat Enterprise Linux to distributing vsftpd. For security and for consistency with future Red Hat releases, the use of vsftpd is recommended. Use vsftpd to Provide FTP Service if Necessary The primary vsftpd configuration file is /etc/vsftpd.conf, if that file exists, or /etc/vsftpd/vsftpd.conf if it does not. Enable Logging of All FTP Transactions Add or correct the following configuration options within the vsftpd configuration file, located at /etc/vsftpd/vsftpd.conf: 
xferlog_enable=YES
xferlog_std_format=NO
log_ftp_protocol=YES
 Find if logging is applied to the FTP daemon.

Procedures:

If vsftpd is started by xinetd the following command will indicate the xinetd.d startup file: 
# grep vsftpd /etc/xinetd.d/*
# grep server_args vsftpd xinetd.d startup file
This will indicate the vsftpd config file used when starting through xinetd. If the server_args line is missing or does not include the vsftpd configuration file, then the default config file (/etc/vsftpd/vsftpd.conf) is used. 
# grep xferlog_enable vsftpd config file
 To trace malicious activity facilitated by the FTP service, it must be configured to ensure that all commands sent to the FTP server are logged using the verbose vsftpd log format. The default vsftpd log file is /var/log/vsftpd.log. If verbose logging to vsftpd.log is done, sparse logging of downloads to /var/log/xferlog will not also occur. However, the information about what files were downloaded is included in the information logged to vsftpd.log Create Warning Banners for All FTP Users Edit the vsftpd configuration file, which resides at /etc/vsftpd/vsftpd.conf by default. Add or correct the following configuration options: 
banner_file=/etc/issue
 This setting will cause the system greeting banner to be used for FTP connections as well. If FTP services are not installed, this is not applicable.

To verify this configuration, run the following command: 
grep "banner_file" /etc/vsftpd/vsftpd.conf
The output should show the value of banner_file is set to /etc/issue, an example of which is shown below: 
# grep "banner_file" /etc/vsftpd/vsftpd.conf
banner_file=/etc/issue
 Restrict the Set of Users Allowed to Access FTP This section describes how to disable non-anonymous (password-based) FTP logins, or, if it is not possible to do this entirely due to legacy applications, how to restrict insecure FTP login to only those users who have an identified need for this access. Restrict Access to Anonymous Users if Possible Is there a mission-critical reason for users to transfer files to/from their own accounts using FTP, rather than using a secure protocol like SCP/SFTP? If not, edit the vsftpd configuration file. Add or correct the following configuration option: 
local_enable=NO
If non-anonymous FTP logins are necessary, follow the guidance in the remainder of this section to secure these logins as much as possible. The use of non-anonymous FTP logins is strongly discouraged. Since SSH clients and servers are widely available, and since SSH provides support for a transfer mode which resembles FTP in user interface, there is no good reason to allow password-based FTP access. Limit Users Allowed FTP Access if Necessary If there is a mission-critical reason for users to access their accounts via the insecure FTP protocol, limit the set of users who are allowed this access. Edit the vsftpd configuration file. Add or correct the following configuration options: 
userlist_enable=YES
userlist_file=/etc/vsftp.ftpusers
userlist_deny=NO
Edit the file /etc/vsftp.ftpusers. For each user USERNAME who should be allowed to access the system via FTP, add a line containing that user's name: 
USERNAME
If anonymous access is also required, add the anonymous usernames to /etc/vsftp.ftpusers as well. 
anonymous
ftp
 Historically, the file /etc/ftpusers contained a list of users who were not allowed to access the system via FTP. It was used to prevent system users such as the root user from logging in via the insecure FTP protocol. However, when the configuration option userlist deny=NO is set, vsftpd interprets ftpusers as the set of users who are allowed to login via FTP. Since it should be possible for most users to access their accounts via secure protocols, it is recommended that this setting be used, so that non-anonymous FTP access can be limited to legacy users who have been explicitly identified. Disable FTP Uploads if Possible Is there a mission-critical reason for users to upload files via FTP? If not, edit the vsftpd configuration file to add or correct the following configuration options: 
write_enable=NO
If FTP uploads are necessary, follow the guidance in the remainder of this section to secure these transactions as much as possible. Anonymous FTP can be a convenient way to make files available for universal download. However, it is less common to have a need to allow unauthenticated users to place files on the FTP server. If this must be done, it is necessary to ensure that files cannot be uploaded and downloaded from the same directory. Place the FTP Home Directory on its Own Partition By default, the anonymous FTP root is the home directory of the FTP user account. The df command can be used to verify that this directory is on its own partition. If there is a mission-critical reason for anonymous users to upload files, precautions must be taken to prevent these users from filling a disk used by other services. Configure Firewalls to Protect the FTP Server By default, iptables blocks access to the ports used by the web server. Edit the file /etc/sysconfig/iptables-config. Ensure that the space-separated list of modules contains the FTP connection tracking module: 
IPTABLES_MODULES="ip_conntrack_ftp"
 These settings configure iptables to allow connections to an FTP server. The first line allows initial connections to the FTP server port. FTP is an older protocol which is not very compatible with firewalls. During the initial FTP dialogue, the client and server negotiate an arbitrary port to be used for data transfer. The ip_conntrack_ftp module is used by iptables to listen to that dialogue and allow connections to the data ports which FTP negotiates. This allows an FTP server to operate on a machine which is running a firewall. scap-security-guide-0.1.31/Fedora/input/xccdf/services/nfs.xml000066400000000000000000000447741301675746700243030ustar00rootroot00000000000000 NFS and RPC The Network File System is a popular distributed filesystem for the Unix environment, and is very widely deployed. This section discusses the circumstances under which it is possible to disable NFS and its dependencies, and then details steps which should be taken to secure NFS's configuration. This section is relevant to machines operating as NFS clients, as well as to those operating as NFS servers. Disable All NFS Services if Possible If there is not a reason for the system to operate as either an NFS client or an NFS server, follow all instructions in this section to disable subsystems required by NFS. The steps in this section will prevent a machine from operating as either an NFS client or an NFS server. Only perform these steps on machines which do not need NFS at all. Disable Services Used Only by NFS If NFS is not needed, disable the NFS client daemons nfslock, rpcgssd, and rpcidmapd.

All of these daemons run with elevated privileges, and many listen for network connections. If they are not needed, they should be disabled to improve system security posture. Disable Network File System Lock Service (nfslock) The Network File System Lock (nfslock) service starts the required remote procedure call (RPC) processes which allow clients to lock files on the server. If the local machine is not configured to mount NFS filesystems then this service should be disabled. Disable Secure RPC Client Service (rpcgssd) The rpcgssd service manages RPCSEC GSS contexts required to secure protocols that use RPC (most often Kerberos and NFS). The rpcgssd service is the client-side of RPCSEC GSS. If the system does not require secure RPC then this service should be disabled. Disable RPC ID Mapping Service (rpcidmapd) The rpcidmapd service is used to map user names and groups to UID and GID numbers on NFSv4 mounts. If NFS is not in use on the local system then this service should be disabled. Disable netfs if Possible To determine if any network filesystems handled by netfs are currently mounted on the system execute the following command: 
# mount -t nfs,nfs4,smbfs,cifs,ncpfs
If the command did not return any output then disable netfs. Disable Network File Systems (netfs) The netfs script manages the boot-time mounting of several types of networked filesystems, of which NFS and Samba are the most common. If these filesystem types are not in use, the script can be disabled, protecting the system somewhat against accidental or malicious changes to /etc/fstab and against flaws in the netfs script itself. Configure All Machines which Use NFS The steps in this section are appropriate for all machines which run NFS, whether they operate as clients or as servers. Make Each Machine a Client or a Server, not Both If NFS must be used, it should be deployed in the simplest configuration possible to avoid maintainability problems which may lead to unnecessary security exposure. Due to the reliability and security problems caused by NFS (specially NFSv3 and NFSv2), it is not a good idea for machines which act as NFS servers to also mount filesystems via NFS. At the least, crossed mounts (the situation in which each of two servers mounts a filesystem from the other) should never be used. Configure NFS Services to Use Fixed Ports (NFSv3 and NFSv2) Firewalling should be done at each host and at the border firewalls to protect the NFS daemons from remote access, since NFS servers should never be accessible from outside the organization. However, by default for NFSv3 and NFSv2, the RPC Bind service assigns each NFS service to a port dynamically at service startup time. Dynamic ports cannot be protected by port filtering firewalls such as iptables.

Therefore, restrict each service to always use a given port, so that firewalling can be done effectively. Note that, because of the way RPC is implemented, it is not possible to disable the RPC Bind service even if ports are assigned statically to all RPC services.

In NFSv4, the mounting and locking protocols have been incorporated into the protocol, and the server listens on the the well-known TCP port 2049. As such, NFSv4 does not need to interact with the rpcbind, lockd, and rpc.statd daemons, which can and should be disabled in a pure NFSv4 environment. The rpc.mountd daemon is still required on the NFS server to setup exports, but is not involved in any over-the-wire operations. Configure <tt>lockd</tt> to use static TCP port Configure the lockd daemon to use a static TCP port as opposed to letting the RPC Bind service dynamically assign a port. Edit the file /etc/sysconfig/nfs. Add or correct the following line: 
LOCKD_TCPPORT=lockd-port
Where lockd-port is a port which is not used by any other service on your network. Restrict service to always use a given port, so that firewalling can be done effectively. Configure <tt>lockd</tt> to use static UDP port Configure the lockd daemon to use a static UDP port as opposed to letting the RPC Bind service dynamically assign a port. Edit the file /etc/sysconfig/nfs. Add or correct the following line: 
LOCKD_UDPPORT=lockd-port
Where lockd-port is a port which is not used by any other service on your network. Restricting services to always use a given port enables firewalling to be done more effectively. Configure <tt>statd</tt> to use static port Configure the statd daemon to use a static port as opposed to letting the RPC Bind service dynamically assign a port. Edit the file /etc/sysconfig/nfs. Add or correct the following line: 
STATD_PORT=statd-port
Where statd-port is a port which is not used by any other service on your network. Restricting services to always use a given port enables firewalling to be done more effectively. Configure <tt>mountd</tt> to use static port Configure the mountd daemon to use a static port as opposed to letting the RPC Bind service dynamically assign a port. Edit the file /etc/sysconfig/nfs. Add or correct the following line: 
MOUNTD_PORT=statd-port
Where mountd-port is a port which is not used by any other service on your network. Restricting services to always use a given port enables firewalling to be done more effectively. Configure NFS Clients The steps in this section are appropriate for machines which operate as NFS clients. Disable NFS Server Daemons There is no need to run the NFS server daemons nfs and rpcsvcgssd except on a small number of properly secured machines designated as NFS servers. Ensure that these daemons are turned off on clients. Specify UID and GID for Anonymous NFS Connections To specify the UID and GID for remote root users, edit the /etc/exports file and add the following for each export: 
anonuid=-1
anongid=-1
Specifying the anonymous UID and GID as -1 ensures that the remote root user is mapped to a local account which has no permissions on the system. Disable Network File System (nfs) The Network File System (NFS) service allows remote hosts to mount and interact with shared filesystems on the local machine. If the local machine is not designated as a NFS server then this service should be disabled. It is prudent to ensure the nfs service is disabled in system boot, as well as not currently running. First, run the following to verify the service is stopped: 
$ service nfs status
If the service is stopped or disabled, it will return the following: 
rpc.svcgssd is stopped
rpc.mountd is stopped
nfsd is stopped
rpc.rquotad is stopped
To verify that the nfs service is disabled, run the following command: 
$ chkconfig --list nfs
If properly configured, the output should look like: 
nfs            	0:off	1:off	2:off	3:off	4:off	5:off	6:off
 Unnecessary services should be disabled to decrease the attack surface of the system. Disable Secure RPC Server Service (rpcsvcgssd) The rpcsvcgssd service manages RPCSEC GSS contexts required to secure protocols that use RPC (most often Kerberos and NFS). The rpcsvcgssd service is the server-side of RPCSEC GSS. If the system does not require secure RPC then this service should be disabled. Unnecessary services should be disabled to decrease the attack surface of the system. Mount Remote Filesystems with Restrictive Options Edit the file /etc/fstab. For each filesystem whose type (column 3) is nfs or nfs4, add the text ,nodev,nosuid to the list of mount options in column 4. If appropriate, also add ,noexec.

See the section titled "Restrict Partition Mount Options" for a description of the effects of these options. In general, execution of files mounted via NFS should be considered risky because of the possibility that an adversary could intercept the request and substitute a malicious file. Allowing setuid files to be executed from remote servers is particularly risky, both for this reason and because it requires the clients to extend root-level trust to the NFS server. Mount Remote Filesystems with nodev To verify the nodev option is configured for all NFS mounts, run the following command: 
$ mount  | grep nfs
All NFS mounts should show the nodev setting in parentheses. This is not applicable if NFS is not implemented. Legitimate device files should only exist in the /dev directory. NFS mounts should not present device files to users. Mount Remote Filesystems with nosuid To verify the nosuid option is configured for all NFS mounts, run the following command: 
$ mount  | grep nfs
All NFS mounts should show the nosuid setting in parentheses. This is not applicable if NFS is not implemented. NFS mounts should not present suid binaries to users. Only vendor-supplied suid executables should be installed to their default location on the local filesystem. Configure NFS Servers The steps in this section are appropriate for machines which operate as NFS servers. Configure the Exports File Restrictively Linux's NFS implementation uses the file /etc/exports to control what filesystems and directories may be accessed via NFS. (See the exports(5) manpage for more information about the format of this file.)

The syntax of the exports file is not necessarily checked fully on reload, and syntax errors can leave your NFS configuration more open than intended. Therefore, exercise caution when modifying the file.

The syntax of each line in /etc/exports is: 
/DIR	host1(opt1,opt2) host2(opt3)
where /DIR is a directory or filesystem to export, hostN is an IP address, netblock, hostname, domain, or netgroup to which to export, and optN is an option. Use Access Lists to Enforce Authorization Restrictions When configuring NFS exports, ensure that each export line in /etc/exports contains a list of hosts which are allowed to access that export. If no hosts are specified on an export line, then that export is available to any remote host which requests it. All lines of the exports file should specify the hosts (or subnets, if needed) which are allowed to access the exported directory, so that unknown or remote hosts will be denied.

Authorized hosts can be specified in several different formats:
  • Name or alias that is recognized by the resolver
  • Fully qualified domain name
  • IP address
  • IP subnets in the format address/netmask or address/CIDR
 Export Filesystems Read-Only if Possible If a filesystem is being exported so that users can view the files in a convenient fashion, but there is no need for users to edit those files, exporting the filesystem read-only removes an attack vector against the server. The default filesystem export mode is ro, so do not specify rw without a good reason. Use Root-Squashing on All Exports If a filesystem is exported using root squashing, requests from root on the client are considered to be unprivileged (mapped to a user such as nobody). This provides some mild protection against remote abuse of an NFS server. Root squashing is enabled by default, and should not be disabled.

Ensure that no line in /etc/exports contains the option no_root_squash. If the NFS server allows root access to local file systems from remote hosts, this access could be used to compromise the system. Restrict NFS Clients to Privileged Ports By default, the server NFS implementation requires that all client requests be made from ports less than 1024. If your organization has control over machines connected to its network, and if NFS requests are prohibited at the border firewall, this offers some protection against malicious requests from unprivileged users. Therefore, the default should not be changed.

To ensure that the default has not been changed, ensure no line in /etc/exports contains the option insecure. Allowing client requests to be made from ports higher than 1024 could allow a unprivileged user to initiate an NFS connection. If the unprivileged user account has been compromised, an attacker could gain access to data on the NFS server. Ensure Insecure File Locking is Not Allowed By default the NFS server requires secure file-lock requests, which require credentials from the client in order to lock a file. Most NFS clients send credentials with file lock requests, however, there are a few clients that do not send credentials when requesting a file-lock, allowing the client to only be able to lock world-readable files. To get around this, the insecure_locks option can be used so these clients can access the desired export. This poses a security risk by potentially allowing the client access to data for which it does not have authorization. Remove any instances of the insecure_locks option from the file /etc/exports. To verify insecure file locking has been disabled, run the following command: 
# grep insecure_locks /etc/exports
 Allowing insecure file locking could allow for sensitive data to be viewed or edited by an unauthorized user. scap-security-guide-0.1.31/Fedora/input/xccdf/services/ntp.xml000066400000000000000000000107211301675746700242770ustar00rootroot00000000000000 Network Time Protocol The Network Time Protocol is used to manage the system clock over a network. Computer clocks are not very accurate, so time will drift unpredictably on unmanaged systems. Central time protocols can be used both to ensure that time is consistent among a network of machines, and that their time is consistent with the outside world.

If every system on a network reliably reports the same time, then it is much easier to correlate log messages in case of an attack. In addition, a number of cryptographic protocols (such as Kerberos) use timestamps to prevent certain types of attacks. If your network does not have synchronized time, these protocols may be unreliable or even unusable.

Depending on the specifics of the network, global time accuracy may be just as important as local synchronization, or not very important at all. If your network is connected to the Internet, using a public timeserver (or one provided by your enterprise) provides globally accurate timestamps which may be essential in investigating or responding to an attack which originated outside of your network.

A typical network setup involves a small number of internal systems operating as NTP servers, and the remainder obtaining time information from those internal servers.

More information on how to configure the NTP server software, including configuration of cryptographic authentication for time data, is available at . Enable the Chrony Daemon Enabling the chronyd service ensures that the chronyd service will be running and that the system will synchronize its time to any servers specified. This is important whether the system is configured to be a client (and synchronize only its own clock) or it is also acting as an NTP server to other systems. Synchronizing time is essential for authentication services such as Kerberos, but it is also important for maintaining accurate logs and auditing possible security breaches.

The chrony daemon offers all of the functionality of ntpdate, which is now deprecated. Additional information on this is available at Specify a Remote NTP Server To specify a remote NTP server for time synchronization, edit the file /etc/chrony.conf. Add or correct the following lines, substituting the IP or hostname of a remote NTP server for ntpserver: 
server ntpserver
This instructs the NTP software to contact that remote server to obtain time data. To verify that a remote NTP service is configured for time synchronization, open the following file: 
/etc/chrony.conf
In the file, there should be a section similar to the following: 
server ntpserver
 Synchronizing with an NTP server makes it possible to collate system logs from multiple sources or correlate computer events with real time events. Specify Additional Remote NTP Servers Additional NTP servers can be specified for time synchronization in the file /etc/chrony.conf. To do so, add additional lines of the following form, substituting the IP address or hostname of a remote NTP server for ntpserver: 
server ntpserver
 Specifying additional NTP servers increases the availability of accurate time data, in the event that one of the specified servers becomes unavailable. This is typical for a system acting as an NTP server for other systems. scap-security-guide-0.1.31/Fedora/input/xccdf/services/snmp.xml000066400000000000000000000105361301675746700244570ustar00rootroot00000000000000 SNMP Server The Simple Network Management Protocol allows administrators to monitor the state of network devices, including computers. Older versions of SNMP were well-known for weak security, such as plaintext transmission of the community string (used for authentication) and usage of easily-guessable choices for the community string. Disable SNMP Server if Possible The system includes an SNMP daemon that allows for its remote monitoring, though it not installed by default. If it was installed and activated but is not needed, the software should be disabled and removed. Disable <tt>snmpd</tt> Service Running SNMP software provides a network-based avenue of attack, and should be disabled if not needed. Uninstall <tt>net-snmp</tt> Package The net-snmp package provides the snmpd service. If there is no need to run SNMP server software, removing the package provides a safeguard against its activation. Configure SNMP Server if Necessary If it is necessary to run the snmpd agent on the system, some best practices should be followed to minimize the security risk from the installation. The multiple security models implemented by SNMP cannot be fully covered here so only the following general configuration advice can be offered:
  • use only SNMP version 3 security models and enable the use of authentication and encryption
  • write access to the MIB (Management Information Base) should be allowed only if necessary
  • all access to the MIB should be restricted following a principle of least privilege
  • network access should be limited to the maximum extent possible including restricting to expected network addresses both in the configuration files and in the system firewall rules
  • ensure SNMP agents send traps only to, and accept SNMP queries only from, authorized management stations
  • ensure that permissions on the snmpd.conf configuration file (by default, in /etc/snmp) are 640 or more restrictive
  • ensure that any MIB files' permissions are also 640 or more restrictive
 Configure SNMP Service to Use Only SNMPv3 or Newer Edit /etc/snmp/snmpd.conf, removing any references to rocommunity, rwcommunity, or com2sec. Upon doing that, restart the SNMP service: 
# service snmpd restart
 To ensure only SNMPv3 or newer is used, run the following command: 
# grep 'rocommunity\|rwcommunity\|com2sec' /etc/snmp/snmpd.conf | grep -v "^#"
There should be no output. Earlier versions of SNMP are considered insecure, as they potentially allow unauthorized access to detailed system management information. Ensure Default Password Is Not Used Edit /etc/snmp/snmpd.conf, remove default community string public. Upon doing that, restart the SNMP service: 
# service snmpd restart
 To ensure the default password is not set, run the following command: 
# grep -v "^#" /etc/snmp/snmpd.conf| grep public
There should be no output. Presence of the default SNMP password enables querying of different system aspects and could result in unauthorized knowledge of the system. scap-security-guide-0.1.31/Fedora/input/xccdf/services/ssh.xml000066400000000000000000000107111301675746700242720ustar00rootroot00000000000000 SSH Server The SSH protocol is recommended for remote login and remote file transfer. SSH provides confidentiality and integrity for data exchanged between two systems, as well as server authentication, through the use of public key cryptography. The implementation included with the system is called OpenSSH, and more detailed documentation is available from its website, . Its server program is called sshd and provided by the RPM package openssh-server. SSH session Idle time Specify duration of allowed idle time. 300 300 600 900 SSH Server Listening Port Specify port the SSH server is listening. 22 22 Configure OpenSSH Server if Necessary If the system needs to act as an SSH server, then certain changes should be made to the OpenSSH daemon configuration file /etc/ssh/sshd_config. The following recommendations can be applied to this file. See the sshd_config(5) man page for more detailed information. SSH Root Login Disabled The root user should never be allowed to login to a system directly over a network. To disable root login via SSH, add or correct the following line in /etc/ssh/sshd_config: 
PermitRootLogin no
 Permitting direct root login reduces auditable information about who ran privileged commands on the system and also allows direct attack attempts on root's password. SSH Access via Empty Passwords Disabled To explicitly disallow remote login from accounts with empty passwords, add or correct the following line in /etc/ssh/sshd_config: 
PermitEmptyPasswords no
Any accounts with empty passwords should be disabled immediately, and PAM configuration should prevent users from being able to assign themselves empty passwords. Configuring this setting for the SSH daemon provides additional assurance that remote login via SSH will require a password, even in the event of misconfiguration elsewhere. SSH Idle Timeout Interval Used SSH allows administrators to set an idle timeout interval. After this interval has passed, the idle user will be automatically logged out.

To set an idle timeout interval, edit the /etc/ssh/sshd_config file, locate the following line: 
ClientAliveInterval INTERVAL
and correct it to have the form of: 
ClientAliveInterval
The timeout INTERVAL is given in seconds. To have a timeout of 15 minutes, set INTERVAL to 900.

If a shorter timeout has already been set for the login shell, that value will preempt any SSH setting made here. Keep in mind that some processes may stop SSH from correctly detecting that the user is idle. Causing idle users to be automatically logged out guards against compromises one system leading trivially to compromises on another. SSH Client Alive Count Used To ensure the SSH idle timeout occurs precisely when the ClientAliveCountMax is set, edit /etc/ssh/sshd_config as follows: 
ClientAliveCountMax 0
 This ensures a user login will be terminated as soon as the ClientAliveCountMax is reached. scap-security-guide-0.1.31/Fedora/input/xccdf/services/xorg.xml000066400000000000000000000045661301675746700244670ustar00rootroot00000000000000 X Window System The X Window System implementation included with the system is called X.org. Disable X Windows Unless there is a mission-critical reason for the system to run a graphical user interface, ensure X is not set to start automatically at boot and remove the X Windows software packages. There is usually no reason to run X Windows on a dedicated server machine, as it increases the system's attack surface and consumes system resources. Administrators of server systems should instead login via SSH or on the text console. Disable X Windows Startup By Setting Default Target Setting the system's default target to multi-user will prevent automatic startup of the X server. To do so, run: 
$ systemctl set-default multi-user.target
You should see the following output: 
rm '/etc/systemd/system/default.target'
ln -s '/usr/lib/systemd/system/multi-user.target' '/etc/systemd/system/default.target'
 To verify the default target is multi-user, run the following command: 
$ systemctl get-default
The output should show the following: 
multi-user.target
 Unnecessary services should be disabled to decrease the attack surface of the system. Remove the X Windows Package Group Removing all packages which constitute the X Window System ensures users or malicious software cannot start X. To do so, run the following command: 
$ sudo dnf groupremove "X Window System"
 To ensure the X Windows package group is removed, run the following command: 
$ rpm -qi xorg-x11-server-common
The output should be: 
package xorg-x11-server-common is not installed
 Unnecessary packages should not be installed to decrease the attack surface of the system. scap-security-guide-0.1.31/Fedora/input/xccdf/system/000077500000000000000000000000001301675746700224545ustar00rootroot00000000000000scap-security-guide-0.1.31/Fedora/input/xccdf/system/accounts/000077500000000000000000000000001301675746700242735ustar00rootroot00000000000000scap-security-guide-0.1.31/Fedora/input/xccdf/system/accounts/banners.xml000066400000000000000000000245161301675746700264550ustar00rootroot00000000000000 Warning Banners for System Accesses Each system should expose as little information about itself as possible.

System banners, which are typically displayed just before a login prompt, give out information about the service or the host's operating system. This might include the distribution name and the system kernel version, and the particular version of a network service. This information can assist intruders in gaining access to the system as it can reveal whether the system is running vulnerable software. Most network services can be configured to limit what information is displayed.

Many organizations implement security policies that require a system banner provide notice of the system's ownership, provide warning to unauthorized users, and remind authorized users of their consent to monitoring. Login Banner Verbiage Enter an appropriate login banner for your organization. Please note that new lines must be expressed by the '\n' character and special characters like parentheses and quotation marks must be escaped with '\'. --[\s\n]+WARNING[\s\n]+--[\s\n]*This[\s\n]+system[\s\n]+is[\s\n]+for[\s\n]+the[\s\n]+use[\s\n]+of[\s\n]+authorized[\s\n]+users[\s\n]+only.[\s\n]+Individuals[\s\n]*using[\s\n]+this[\s\n]+computer[\s\n]+system[\s\n]+without[\s\n]+authority[\s\n]+or[\s\n]+in[\s\n]+excess[\s\n]+of[\s\n]+their[\s\n]*authority[\s\n]+are[\s\n]+subject[\s\n]+to[\s\n]+having[\s\n]+all[\s\n]+their[\s\n]+activities[\s\n]+on[\s\n]+this[\s\n]+system[\s\n]*monitored[\s\n]+and[\s\n]+recorded[\s\n]+by[\s\n]+system[\s\n]+personnel.[\s\n]+Anyone[\s\n]+using[\s\n]+this[\s\n]*system[\s\n]+expressly[\s\n]+consents[\s\n]+to[\s\n]+such[\s\n]+monitoring[\s\n]+and[\s\n]+is[\s\n]+advised[\s\n]+that[\s\n]*if[\s\n]+such[\s\n]+monitoring[\s\n]+reveals[\s\n]+possible[\s\n]+evidence[\s\n]+of[\s\n]+criminal[\s\n]+activity[\s\n]*system[\s\n]+personal[\s\n]+may[\s\n]+provide[\s\n]+the[\s\n]+evidence[\s\n]+of[\s\n]+such[\s\n]+monitoring[\s\n]+to[\s\n]+law[\s\n]*enforcement[\s\n]+officials. You[\s\n]+are[\s\n]+accessing[\s\n]+a[\s\n]+U.S.[\s\n]+Government[\s\n]+\(USG\)[\s\n]+Information[\s\n]+System[\s\n]+\(IS\)[\s\n]+that[\s\n]+is[\s\n]+provided[\s\n]+for[\s\n]+USG-authorized[\s\n]+use[\s\n]+only.[\s\n]*By[\s\n]+using[\s\n]+this[\s\n]+IS[\s\n]+\(which[\s\n]+includes[\s\n]+any[\s\n]+device[\s\n]+attached[\s\n]+to[\s\n]+this[\s\n]+IS\),[\s\n]+you[\s\n]+consent[\s\n]+to[\s\n]+the[\s\n]+following[\s\n]+conditions\:[\s\n]*-[\s\n]*The[\s\n]+USG[\s\n]+routinely[\s\n]+intercepts[\s\n]+and[\s\n]+monitors[\s\n]+communications[\s\n]+on[\s\n]+this[\s\n]+IS[\s\n]+for[\s\n]+purposes[\s\n]+including,[\s\n]+but[\s\n]+not[\s\n]+limited[\s\n]+to,[\s\n]+penetration[\s\n]+testing,[\s\n]+COMSEC[\s\n]+monitoring,[\s\n]+network[\s\n]+operations[\s\n]+and[\s\n]+defense,[\s\n]+personnel[\s\n]+misconduct[\s\n]+\(PM\),[\s\n]+law[\s\n]+enforcement[\s\n]+\(LE\),[\s\n]+and[\s\n]+counterintelligence[\s\n]+\(CI\)[\s\n]+investigations.[\s\n]*-[\s\n]*At[\s\n]+any[\s\n]+time,[\s\n]+the[\s\n]+USG[\s\n]+may[\s\n]+inspect[\s\n]+and[\s\n]+seize[\s\n]+data[\s\n]+stored[\s\n]+on[\s\n]+this[\s\n]+IS.[\s\n]*-[\s\n]*Communications[\s\n]+using,[\s\n]+or[\s\n]+data[\s\n]+stored[\s\n]+on,[\s\n]+this[\s\n]+IS[\s\n]+are[\s\n]+not[\s\n]+private,[\s\n]+are[\s\n]+subject[\s\n]+to[\s\n]+routine[\s\n]+monitoring,[\s\n]+interception,[\s\n]+and[\s\n]+search,[\s\n]+and[\s\n]+may[\s\n]+be[\s\n]+disclosed[\s\n]+or[\s\n]+used[\s\n]+for[\s\n]+any[\s\n]+USG-authorized[\s\n]+purpose.[\s\n]*-[\s\n]*This[\s\n]+IS[\s\n]+includes[\s\n]+security[\s\n]+measures[\s\n]+\(e.g.,[\s\n]+authentication[\s\n]+and[\s\n]+access[\s\n]+controls\)[\s\n]+to[\s\n]+protect[\s\n]+USG[\s\n]+interests[\s\n]+--[\s\n]+not[\s\n]+for[\s\n]+your[\s\n]+personal[\s\n]+benefit[\s\n]+or[\s\n]+privacy.[\s\n]*-[\s\n]*Notwithstanding[\s\n]+the[\s\n]+above,[\s\n]+using[\s\n]+this[\s\n]+IS[\s\n]+does[\s\n]+not[\s\n]+constitute[\s\n]+consent[\s\n]+to[\s\n]+PM,[\s\n]+LE[\s\n]+or[\s\n]+CI[\s\n]+investigative[\s\n]+searching[\s\n]+or[\s\n]+monitoring[\s\n]+of[\s\n]+the[\s\n]+content[\s\n]+of[\s\n]+privileged[\s\n]+communications,[\s\n]+or[\s\n]+work[\s\n]+product,[\s\n]+related[\s\n]+to[\s\n]+personal[\s\n]+representation[\s\n]+or[\s\n]+services[\s\n]+by[\s\n]+attorneys,[\s\n]+psychotherapists,[\s\n]+or[\s\n]+clergy,[\s\n]+and[\s\n]+their[\s\n]+assistants.[\s\n]+Such[\s\n]+communications[\s\n]+and[\s\n]+work[\s\n]+product[\s\n]+are[\s\n]+private[\s\n]+and[\s\n]+confidential.[\s\n]+See[\s\n]+User[\s\n]+Agreement[\s\n]+for[\s\n]+details. I\'ve[\s\n]+read[\s\n]+\&[\s\n]+consent[\s\n]+to[\s\n]+terms[\s\n]+in[\s\n]+IS[\s\n]+user[\s\n]+agreem\'t. Implement a GUI Warning Banner In the default graphical environment, users logging directly into the system are greeted with a login screen provided by the GNOME3 Display Manager (GDM). The warning banner should be displayed in this graphical environment for these users. The following sections describe how to configure the GDM login banner. Enable GNOME3 Login Warning Banner To enable displaying a login warning banner in the GNOME Display Manager's login screen, the banner-message-enable setting must be set under an appropriate configuration file(s) in the /etc/dconf/db/gdm.d directory and locked in /etc/dconf/db/gdm.d/locks directory to prevent user modification. After the settings have been set, run dconf update. To display a banner, this setting must be enabled, and the user must be prevented from making changes. The banner text must also be set. To ensure a login warning banner is enabled, run the following: 
$ grep banner-message-enable /etc/dconf/db/gdm.d/*
If properly configured, the output should be true. To ensure a login warning banner is locked and cannot be changed by a user, run the following: 
$ grep banner-message-enable /etc/dconf/db/gdm.d/locks/*
If properly configured, the output should be /org/gnome/login-screen/banner-message-enable. An appropriate warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers. Set the GNOME3 Login Warning Banner Text To set the text shown by the GNOME3 Display Manager in the login screen, the banner-message-text setting must be set under an appropriate configuration file(s) in the /etc/dconf/db/gdm.d directory and locked in /etc/dconf/db/gdm.d/locks directory to prevent user modification. After the settings have been set, run dconf update. When entering a warning banner that spans several lines, remember to begin and end the string with ' and use \n for new lines. To ensure the login warning banner text is properly set, run the following: 
$ grep banner-message-text /etc/dconf/db/gdm.d/*
If properly configured, the proper banner text will appear. To ensure the login warning banner text is locked and cannot be changed by a user, run the following: 
$ grep banner-message-enable /etc/dconf/db/gdm.d/locks/*
If properly configured, the output should be /org/gnome/login-screen/banner-message-text. An appropriate warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers. scap-security-guide-0.1.31/Fedora/input/xccdf/system/accounts/pam.xml000066400000000000000000001070611301675746700255770ustar00rootroot00000000000000 Protect Accounts by Configuring PAM PAM, or Pluggable Authentication Modules, is a system which implements modular authentication for Linux programs. PAM provides a flexible and configurable architecture for authentication, and it should be configured to minimize exposure to unnecessary risk. This section contains guidance on how to accomplish that.

PAM is implemented as a set of shared objects which are loaded and invoked whenever an application wishes to authenticate a user. Typically, the application must be running as root in order to take advantage of PAM, because PAM's modules often need to be able to access sensitive stores of account information, such as /etc/shadow. Traditional privileged network listeners (e.g. sshd) or SUID programs (e.g. sudo) already meet this requirement. An SUID root application, userhelper, is provided so that programs which are not SUID or privileged themselves can still take advantage of PAM.

PAM looks in the directory /etc/pam.d for application-specific configuration information. For instance, if the program login attempts to authenticate a user, then PAM's libraries follow the instructions in the file /etc/pam.d/login to determine what actions should be taken.

One very important file in /etc/pam.d is /etc/pam.d/system-auth. This file, which is included by many other PAM configuration files, defines 'default' system authentication measures. Modifying this file is a good way to make far-reaching authentication changes, for instance when implementing a centralized authentication service. Be careful when making changes to PAM's configuration files. The syntax for these files is complex, and modifications can have unexpected consequences. The default configurations shipped with applications should be sufficient for most users. Running authconfig or system-config-authentication will re-write the PAM configuration files, destroying any manually made changes and replacing them with a series of system defaults. One reference to the configuration file syntax can be found at . remember The last n passwords for each user are saved in /etc/security/opasswd in order to force password change history and keep the user from alternating between the same password too frequently. 24 0 4 5 10 24 Set Last Logon/Access Notification To configure the system to notify users of last logon/access using pam_lastlog, add or correct the pam_lastlog settings in /etc/pam.d/postlogin to read as follows: 
session     [success=1 default=ignore] pam_succeed_if.so service !~ gdm* service !~ su* quiet
session     [default=1]   pam_lastlog.so nowtmp showfailed
session     optional      pam_lastlog.so silent noupdate showfailed
 To ensure that last logon/access notification is configured correctly, run the following command: 
$ grep pam_lastlog.so /etc/pam.d/postlogin
The output should show output showfailed. Users need to be aware of activity that occurs regarding their account. Providing users with information regarding the number of unsuccessful attempts that were made to login to their account allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators. Set Password Quality Requirements The default pam_pwquality PAM module provides strength checking for passwords. It performs a number of checks, such as making sure passwords are not similar to dictionary words, are of at least a certain length, are not the previous password reversed, and are not simply a change of case from the previous password. It can also require passwords to be in certain character classes. The pam_pwquality module is the preferred way of configuring password requirements.

The pam_cracklib PAM module can also provide strength checking for passwords as the pam_pwquality module. It performs a number of checks, such as making sure passwords are not similar to dictionary words, are of at least a certain length, are not the previous password reversed, and are not simply a change of case from the previous password. It can also require passwords to be in certain character classes.

The man pages pam_pwquality(8) and pam_cracklib(8) provide information on the capabilities and configuration of each. Set Password Quality Requirements with pam_pwquality The pam_pwquality PAM module can be configured to meet requirements for a variety of policies.

For example, to configure pam_pwquality to require at least one uppercase character, lowercase character, digit, and other (special) character, make sure that pam_pwquality exists in /etc/pam.d/system-auth: 
password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
If no such line exists, add one as the first line of the password section in /etc/pam.d/system-auth. Next, modify the settings in /etc/security/pwquality.conf to match the following: 
difok = 4
minlen = 14
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1
maxrepeat = 3
The arguments can be modified to ensure compliance with your organization's security policy. Discussion of each parameter follows. Note that the password quality requirements are not enforced for the root account for some reason. retry Number of retry attempts before erroring out 3 1 2 3 maxrepeat Maximum Number of Consecutive Repeating Characters in a Password 3 1 2 3 maxclassrepeat Maximum Number of Consecutive Repeating Characters in a Password From the Same Character Class 2 1 2 3 minlen Minimum number of characters in password 15 6 7 8 10 12 14 15 dcredit Minimum number of digits in password -1 -2 -1 0 ocredit Minimum number of other (special characters) in password -1 -2 -1 0 lcredit Minimum number of lower case in password -1 -2 -1 0 ucredit Minimum number of upper case in password -1 -2 -1 0 difok Minimum number of characters not present in old password Keep this high for short passwords 15 2 3 4 5 15 minclass Minimum number of categories of characters that must exist in a password 3 1 2 3 4 fail_deny Number of failed login attempts before account lockout 3 3 5 6 10 fail_unlock_time Seconds before automatic unlocking after excessive failed logins 604800 900 1800 3600 86400 604800 fail_interval Interval for counting failed login attempts before account lockout 900 900 1800 3600 86400 100000000 Set Password Retry Prompts Permitted Per-Session To configure the number of retry prompts that are permitted per-session:

Edit the pam_pwquality.so statement in /etc/pam.d/system-auth to show retry=, or a lower value if site policy is more restrictive.

The DoD requirement is a maximum of 3 prompts per session. To check how many retry attempts are permitted on a per-session basis, run the following command: 
$ grep pam_pwquality /etc/pam.d/system-auth
The retry parameter will indicate how many attempts are permitted. The DoD required value is less than or equal to 3. This would appear as retry=3, or a lower value. Setting the password retry prompts that are permitted on a per-session basis to a low value requires some software, such as SSH, to re-connect. This can slow down and draw additional attention to some types of password-guessing attacks. Note that this is different from account lockout, which is provided by the pam_faillock module. Set Password to Maximum of Three Consecutive Repeating Characters The pam_pwquality module's maxrepeat parameter controls requirements for consecutive repeating characters. When set to a positive number, it will reject passwords which contain more than that number of consecutive characters. Modify the maxrepeat setting in /etc/security/pwquality.conf to equal to prevent a run of ( + 1) or more identical characters. To check the maximum value for consecutive repeating characters, run the following command: 
$ grep maxrepeat /etc/security/pwquality.conf
Look for the value of the maxrepeat parameter. The DoD requirement is 3 which would appear as maxrepeat = 3. Passwords with excessive repeating characters may be more vulnerable to password-guessing attacks. Set Password to Maximum of Consecutive Repeating Characters from Same Character Class The pam_pwquality module's maxclassrepeat parameter controls requirements for consecutive repeating characters from the same character class. When set to a positive number, it will reject passwords which contain more than that number of consecutive characters from the same character class. Modify the maxclassrepeat setting in /etc/security/pwquality.conf to equal to prevent a run of ( + 1) or more identical characters. To check the value for maximum consecutive repeating characters, run the following command: 
$ grep maxclassrepeat /etc/security/pwquality.conf
The output should show maxclassrepeat=600. Passwords with excessive repeating characters from the same character class may be more vulnerable to password-guessing attacks. Set Password Strength Minimum Digit Characters The pam_pwquality module's dcredit parameter controls requirements for usage of digits in a password. When set to a negative number, any password will be required to contain that many digits. When set to a positive number, pam_pwquality will grant +1 additional length credit for each digit. Modify the dcredit setting in /etc/security/pwquality.conf to require the use of a digit in passwords. To check how many digits are required in a password, run the following command: 
$ grep dcredit /etc/security/pwquality.conf
The dcredit parameter (as a negative number) will indicate how many digits are required. The DoD requires at least one digit in a password. This would appear as dcredit = -1. Requiring digits makes password guessing attacks more difficult by ensuring a larger search space. Set Password Minimum Length The pam_pwquality module's minlen parameter controls requirements for minimum characters required in a password. Add minlen= after pam_pwquality to set minimum password length requirements. To check how many characters are required in a password, run the following command: 
$ grep minlen /etc/security/pwquality.conf
Your output should contain minlen = Password length is one factor of several that helps to determine strength and how long it takes to crack a password. Use of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password. Set Password Strength Minimum Uppercase Characters The pam_pwquality module's ucredit= parameter controls requirements for usage of uppercase letters in a password. When set to a negative number, any password will be required to contain that many uppercase characters. When set to a positive number, pam_pwquality will grant +1 additional length credit for each uppercase character. Modify the ucredit setting in /etc/security/pwquality.conf to require the use of an uppercase character in passwords. To check how many uppercase characters are required in a password, run the following command: 
$ grep ucredit /etc/security/pwquality.conf
The ucredit parameter (as a negative number) will indicate how many uppercase characters are required. The DoD and FISMA require at least one uppercase character in a password. This would appear as ucredit = -1. Requiring a minimum number of uppercase characters makes password guessing attacks more difficult by ensuring a larger search space. Set Password Strength Minimum Special Characters The pam_pwquality module's ocredit= parameter controls requirements for usage of special (or "other") characters in a password. When set to a negative number, any password will be required to contain that many special characters. When set to a positive number, pam_pwquality will grant +1 additional length credit for each special character. Modify the ocredit setting in /etc/security/pwquality.conf to equal to require use of a special character in passwords. To check how many special characters are required in a password, run the following command: 
$ grep ocredit /etc/security/pwquality.conf
The ocredit parameter (as a negative number) will indicate how many special characters are required. The DoD and FISMA require at least one special character in a password. This would appear as ocredit = -1. Requiring a minimum number of special characters makes password guessing attacks more difficult by ensuring a larger search space. Set Password Strength Minimum Lowercase Characters The pam_pwquality module's lcredit parameter controls requirements for usage of lowercase letters in a password. When set to a negative number, any password will be required to contain that many lowercase characters. When set to a positive number, pam_pwquality will grant +1 additional length credit for each lowercase character. Modify the lcredit setting in /etc/security/pwquality.conf to require the use of a lowercase character in passwords. To check how many lowercase characters are required in a password, run the following command: 
$ grep lcredit /etc/security/pwquality.conf
The lcredit parameter (as a negative number) will indicate how many special characters are required. The DoD and FISMA require at least one lowercase character in a password. This would appear as lcredit = -1. Requiring a minimum number of lowercase characters makes password guessing attacks more difficult by ensuring a larger search space. Set Password Strength Minimum Different Characters The pam_pwquality module's difok parameter controls requirements for usage of different characters during a password change. Modify the difok setting in /etc/security/pwquality.conf to equal to require differing characters when changing passwords. The DoD requirement is 4. To check how many characters must differ during a password change, run the following command: 
$ grep difok /etc/security/pwquality.conf
The difok parameter will indicate how many characters must differ. The DoD requires four characters differ during a password change. This would appear as difok = 4. Requiring a minimum number of different characters during password changes ensures that newly changed passwords should not resemble previously compromised ones. Note that passwords which are changed on compromised systems will still be compromised, however. Set Password Strength Minimum Different Categories The pam_pwquality module's minclass parameter controls requirements for usage of different character classes, or types, of character that must exist in a password before it is considered valid. For example, setting this value to three (3) requires that any password must have characters from at least three different categories in order to be approved. The default value is zero (0), meaning there are no required classes. There are four categories available: 
* Upper-case characters
* Lower-case characters
* Digits
* Special characters (for example, punctuation)
Modify the minclass setting in /etc/security/pwquality.conf entry to require differing categories of characters when changing passwords. The minimum requirement is 3. To check how many categories of characters must be used in password during a password change, run the following command: 
$ grep minclass /etc/security/pwquality.conf
The minclass parameter will indicate how many character classes must be used. If the requirement was for the password to contain characters from three different categories, then this would appear as minclass = 3. Requiring a minimum number of character categories makes password guessing attacks more difficult by ensuring a larger search space. Set Lockouts for Failed Password Attempts The pam_faillock PAM module provides the capability to lock out user accounts after a number of failed login attempts. Its documentation is available in /usr/share/doc/pam-VERSION/txts/README.pam_faillock.

Locking out user accounts presents the risk of a denial-of-service attack. The lockout policy must weigh whether the risk of such a denial-of-service attack outweighs the benefits of thwarting password guessing attacks. Set Deny For Failed Password Attempts To configure the system to lock out accounts after a number of incorrect login attempts using pam_faillock.so, modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows:

  • add the following line immediately before the pam_unix.so statement in the AUTH section: 
    auth required pam_faillock.so preauth silent deny= unlock_time= fail_interval=
  • add the following line immediately after the pam_unix.so statement in the AUTH section: 
    auth [default=die] pam_faillock.so authfail deny= unlock_time= fail_interval=
  • add the following line immediately before the pam_unix.so statement in the ACCOUNT section: 
    account required pam_faillock.so
 To ensure the failed password attempt policy is configured correctly, run the following command: 
$ grep pam_faillock /etc/pam.d/system-auth
The output should show deny=. Locking out user accounts after a number of incorrect attempts prevents direct password guessing attacks. Set Lockout Time For Failed Password Attempts To configure the system to lock out accounts after a number of incorrect login attempts and require an administrator to unlock the account using pam_faillock.so, modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows:

  • add the following line immediately before the pam_unix.so statement in the AUTH section: 
    auth required pam_faillock.so preauth silent deny= unlock_time= fail_interval=
  • add the following line immediately after the pam_unix.so statement in the AUTH section: 
    auth [default=die] pam_faillock.so authfail deny= unlock_time= fail_interval=
  • add the following line immediately before the pam_unix.so statement in the ACCOUNT section: 
    account required pam_faillock.so
 To ensure the failed password attempt policy is configured correctly, run the following command: 
$ grep pam_faillock /etc/pam.d/system-auth
The output should show unlock_time=<some-large-number>. Locking out user accounts after a number of incorrect attempts prevents direct password guessing attacks. Ensuring that an administrator is involved in unlocking locked accounts draws appropriate attention to such situations. Set Interval For Counting Failed Password Attempts Utilizing pam_faillock.so, the fail_interval directive configures the system to lock out accounts after a number of incorrect login attempts. Modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows:

  • add the following line immediately before the pam_unix.so statement in the AUTH section: 
    auth required pam_faillock.so preauth silent deny= unlock_time= fail_interval=
  • add the following line immediately after the pam_unix.so statement in the AUTH section: 
    auth [default=die] pam_faillock.so authfail deny= unlock_time= fail_interval=
  • add the following line immediately before the pam_unix.so statement in the ACCOUNT section: 
    account required pam_faillock.so
 To ensure the failed password attempt policy is configured correctly, run the following command: 
$ grep pam_faillock /etc/pam.d/system-auth /etc/pam.d/password-auth
For each file, the output should show fail_interval=<interval-in-seconds> where interval-in-seconds is or greater. If the fail_interval parameter is not set, the default setting of 900 seconds is acceptable. Locking out user accounts after a number of incorrect attempts within a specific period of time prevents direct password guessing attacks. Limit Password Reuse Do not allow users to reuse recent passwords. This can be accomplished by using the remember option for the pam_unix or pam_pwhistory PAM modules. In the file /etc/pam.d/system-auth, append remember= to the line which refers to the pam_unix.so or pam_pwhistory.somodule, as shown below:
  • for the pam_unix.so case: 
    password sufficient pam_unix.so existing_options remember=
  • for the pam_pwhistory.so case: 
    password requisite pam_pwhistory.so existing_options remember=
 To verify the password reuse setting is compliant, run the following command: 
$ grep remember /etc/pam.d/system-auth
The output should show the following at the end of the line: 
remember=
 Preventing re-use of previous passwords helps ensure that a compromised password is not re-used by a user. Set Password Hashing Algorithm The system's default algorithm for storing password hashes in /etc/shadow is SHA-512. This can be configured in several locations. Set Password Hashing Algorithm in /etc/pam.d/system-auth In /etc/pam.d/system-auth, the password section of the file controls which PAM modules execute during a password change. Set the pam_unix.so module in the password section to include the argument sha512, as shown below: 
password    sufficient    pam_unix.so sha512 other arguments...
This will help ensure when local users change their passwords, hashes for the new passwords will be generated using the SHA-512 algorithm. This is the default. Inspect the password section of /etc/pam.d/system-auth and ensure that the pam_unix.so module includes the argument sha512: 
$ grep sha512 /etc/pam.d/system-auth
 Using a stronger hashing algorithm makes password cracking attacks more difficult. Set Password Hashing Algorithm in /etc/login.defs In /etc/login.defs, add or correct the following line to ensure the system will use SHA-512 as the hashing algorithm: 
ENCRYPT_METHOD SHA512
 Inspect /etc/login.defs and ensure the following line appears: 
ENCRYPT_METHOD SHA512
 Using a stronger hashing algorithm makes password cracking attacks more difficult. Set Password Hashing Algorithm in /etc/libuser.conf In /etc/libuser.conf, add or correct the following line in its [defaults] section to ensure the system will use the SHA-512 algorithm for password hashing: 
crypt_style = sha512
 Inspect /etc/libuser.conf and ensure the following line appears in the [default] section: 
crypt_style = sha512
 Using a stronger hashing algorithm makes password cracking attacks more difficult. scap-security-guide-0.1.31/Fedora/input/xccdf/system/accounts/physical.xml000066400000000000000000000402511301675746700266330ustar00rootroot00000000000000 Protect Physical Console Access It is impossible to fully protect a system from an attacker with physical access, so securing the space in which the system is located should be considered a necessary step. However, there are some steps which, if taken, make it more difficult for an attacker to quickly or undetectably modify a system from its console. Set Boot Loader Password During the boot process, the boot loader is responsible for starting the execution of the kernel and passing options to it. The boot loader allows for the selection of different kernels - possibly on different partitions or media. The default Fedora boot loader for x86 systems is called GRUB2. Options it can pass to the kernel include single-user mode, which provides root access without any authentication, and the ability to disable SELinux. To prevent local users from modifying the boot parameters and endangering security, protect the boot loader configuration with a password and ensure its configuration file's permissions are set properly. Verify /boot/grub2/grub.cfg User Ownership The file /boot/grub2/grub.cfg should be owned by the root user to prevent destruction or modification of the file. Only root should be able to modify important boot parameters. Verify /boot/grub2/grub.cfg Group Ownership The file /boot/grub2/grub.cfg should be group-owned by the root group to prevent destruction or modification of the file. The root group is a highly-privileged group. Furthermore, the group-owner of this file should not have any access privileges anyway. Verify /boot/grub2/grub.cfg Permissions File permissions for /boot/grub2/grub.cfg should be set to 600, which is the default. To check the permissions of /boot/grub2/grub.cfg, run the command: 
$ sudo ls -lL /boot/grub2/grub.cfg
If properly configured, the output should indicate the following permissions: -rw------- Proper permissions ensure that only the root user can modify important boot parameters. Set Boot Loader Password The grub2 boot loader should have a superuser account and password protection enabled to protect boot-time settings.

To do so, select a superuser account and password and add them into the /etc/grub.d/01_users configuration file.

Since plaintext passwords are a security risk, generate a hash for the pasword by running the following command: 
$ grub2-mkpasswd-pbkdf2
When prompted, enter the password that was selected and insert the returned password hash into the /etc/grub.d/01_users configuration file immediately after the superuser account. (Use the output from grub2-mkpasswd-pbkdf2 as the value of password-hash): 
password_pbkdf2 superusers-account password-hash
NOTE: It is recommended not to use common administrator account names like root, admin, or administrator for the grub2 superuser account.

To meet FISMA Moderate, the bootloader superuser account and password MUST differ from the root account and password. Once the superuser account and password have been added, update the grub.cfg file by running: 
grub2-mkconfig -o /boot/grub2/grub.cfg
NOTE: Do NOT manually add the superuser account and password to the grub.cfg file as the grub2-mkconfig command overwrites this file. To verify the boot loader superuser account and superuser account password have been set, and the password encrypted, run the following command: 
sudo grep -A1 "superusers\|password" /etc/grub2.cfg
The output should show the following: 
set superusers="superusers-account"
password_pbkdf2 superusers-account password-hash
 Password protection on the boot loader configuration ensures users with physical access cannot trivially alter important bootloader settings. These include which kernel to use, and whether to enter single-user mode. For more information on how to configure the grub2 superuser account and password, please refer to
    • .
Set the UEFI Boot Loader Password The UEFI grub2 boot loader should have a superuser account and password protection enabled to protect boot-time settings.

To do so, select a superuser account and password and add them into the /etc/grub.d/01_users configuration file.

Since plaintext passwords are a security risk, generate a hash for the pasword by running the following command: 
$ grub2-mkpasswd-pbkdf2
When prompted, enter the password that was selected and insert the returned password hash into the /etc/grub.d/01_users configuration file immediately after the superuser account. (Use the output from grub2-mkpasswd-pbkdf2 as the value of password-hash): 
password_pbkdf2 superusers-account password-hash
NOTE: It is recommended not to use common administrator account names like root, admin, or administrator for the grub2 superuser account.

To meet FISMA Moderate, the bootloader superuser account and password MUST differ from the root account and password. Once the superuser account and password have been added, update the grub.cfg file by running: 
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
NOTE: Do NOT manually add the superuser account and password to the grub.cfg file as the grub2-mkconfig command overwrites this file. To verify the boot loader superuser account and superuser account password have been set, and the password encrypted, run the following command: 
sudo grep -A1 "superusers\|password" /etc/grub2-efi.cfg
The output should show the following: 
set superusers="superusers-account"
password_pbkdf2 superusers-account password-hash
 Password protection on the boot loader configuration ensures users with physical access cannot trivially alter important bootloader settings. These include which kernel to use, and whether to enter single-user mode. Require Authentication for Single User Mode Single-user mode is intended as a system recovery method, providing a single user root access to the system by providing a boot option at startup. By default, no authentication is performed if single-user mode is selected.

By default, single-user mode is protected by requiring a password and is set in /usr/lib/systemd/system/rescue.service. To check if authentication is required for single-user mode, run the following command: 
$ grep sulogin /usr/lib/systemd/system/rescue.service
The output should be similar to the following, and the line must begin with ExecStart and /sbin/sulogin: 
ExecStart=-/sbin/sulogin
 This prevents attackers with physical access from trivially bypassing security on the machine and gaining root access. Such accesses are further prevented by configuring the bootloader password. Disable debug-shell SystemD Service SystemD's debug-shell service is intended to diagnose SystemD related boot issues with various systemctl commands. Once enabled and following a system reboot, the root shell will be available on tty9 which is access by pressing CTRL-ALT-F9. The debug-shell service should only be used for SystemD related issues and should otherwise be disabled.

By default, the debug-shell SystemD service is disabled. This prevents attackers with physical access from trivially bypassing security on the machine through valid troubleshooting configurations and gaining root access when the system is rebooted. Disable Ctrl-Alt-Del Reboot Activation By default, SystemD will reboot the system if the Ctrl-Alt-Del key sequence is pressed.
To configure the system to ignore the Ctrl-Alt-Del key sequence from the command line instead of rebooting the system, do either of the following: 
ln -sf /dev/null /etc/systemd/system/ctrl-alt-del.target
or 
systemctl mask ctrl-alt-del.target

Do not simply delete the /usr/lib/systemd/system/ctrl-alt-del.service file, as this file may be restored during future system updates. To ensure the system is configured to mask the Ctrl-Alt-Del sequence, enter the following command: 
sudo ln -sf /dev/null /etc/systemd/system/ctrl-alt-del.target
or 
sudo systemctl mask ctrl-alt-del.target
 A locally logged-in user who presses Ctrl-Alt-Del, when at the console, can reboot the system. If accidentally pressed, as could happen in the case of mixed OS environment, this can create the risk of short-term loss of availability of systems due to unintentional reboot. Verify that Interactive Boot is Disabled Fedora systems support an "interactive boot" option that can be used to prevent services from being started. On a Fedora system, interactive boot can be enabled by providing a 1, yes, true, or on value to the systemd.confirm_spawn kernel argument in /etc/default/grub. Remove any instance of 
systemd.confirm_spawn=(1|yes|true|on)
from the kernel arguments in that file to disable interactive boot. Inspect /etc/default/grub for any instances of systemd.confirm_spawn=(1|yes|true|on) in the kernel boot arguments. Presence of a systemd.confirm_spawn=(1|yes|true|on) indicates that interactive boot is enabled at boot time. Using interactive boot, the console user could disable auditing, firewalls, or other services, weakening system security. The GRUB 2 configuration file, grub.cfg, is automatically updated each time a new kernel is installed. Note that any changes to /etc/default/grub require rebuilding the grub.cfg file. To update the GRUB 2 configuration file manually, use the 
grub2-mkconfig -o
command as follows:
  • On BIOS-based machines, issue the following command as root: 
    ~]# grub2-mkconfig -o /boot/grub2/grub.cfg
  • On UEFI-based machines, issue the following command as root: 
    ~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
 Configure Screen Locking When a user must temporarily leave an account logged-in, screen locking should be employed to prevent passersby from abusing the account. User education and training is particularly important for screen locking to be effective, and policies can be implemented to reinforce this.

Automatic screen locking is only meant as a safeguard for those cases where a user forgot to lock the screen. Configure Console Screen Locking A console screen locking mechanism is provided in the screen package, which is not installed by default. Install the screen Package To enable console screen locking, install the screen package:
Instruct users to begin new terminal sessions with the following command: 
$ screen
The console can now be locked with the following key combination: 
ctrl+a x
 A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but des not logout because of the temporary nature of the absence. Rather than relying on the user to manually lock their operation system session prior to vacating the vicinity, operating systems need to be able to identify when a user's session has idled and take action to initiate the session lock. The screen package allows for a session lock to be implemented and configured. Hardware Tokens for Authentication The use of hardware tokens such as smart cards for system login provides stronger, two-factor authentication than using a username and password. In Fedora servers and workstations, hardware token login is not enabled by default and must be enabled in the system settings. Enable Smart Card Login To enable smart card authentication, consult the documentation at:
Interview the SA to determine if all accounts not exempted by policy are using CAC authentication. Smart card login provides two-factor authentication stronger than that provided by a username and password combination. Smart cards leverage PKI (public key infrastructure) in order to provide and verify credentials. scap-security-guide-0.1.31/Fedora/input/xccdf/system/accounts/restrictions/000077500000000000000000000000001301675746700270235ustar00rootroot00000000000000scap-security-guide-0.1.31/Fedora/input/xccdf/system/accounts/restrictions/account_expiration.xml000066400000000000000000000127641301675746700334550ustar00rootroot00000000000000 Set Account Expiration Parameters Accounts can be configured to be automatically disabled after a certain time period, meaning that they will require administrator interaction to become usable again. Expiration of accounts after inactivity can be set for all accounts by default and also on a per-account basis, such as for accounts that are known to be temporary. To configure automatic expiration of an account following the expiration of its password (that is, after the password has expired and not been changed), run the following command, substituting NUM_DAYS and USER appropriately: 
$ sudo chage -I NUM_DAYS USER
Accounts, such as temporary accounts, can also be configured to expire on an explicitly-set date with the -E option. The file /etc/default/useradd controls default settings for all newly-created accounts created with the system's normal command line utilities. number of days after a password expires until the account is permanently disabled The number of days to wait after a password expires, until the account will be permanently disabled. This will only apply to newly created accounts 35 30 35 60 90 180 Set Account Expiration Following Inactivity To specify the number of days after a password expires (which signifies inactivity) until an account is permanently disabled, add or correct the following lines in /etc/default/useradd, substituting NUM_DAYS appropriately: 
INACTIVE=
A value of 35 is recommended. If a password is currently on the verge of expiration, then 35 days remain until the account is automatically disabled. However, if the password will not expire for another 60 days, then 95 days could elapse until the account would be automatically disabled. See the useradd man page for more information. Determining the inactivity timeout must be done with careful consideration of the length of a "normal" period of inactivity for users in the particular environment. Setting the timeout too low incurs support costs and also has the potential to impact availability of the system to legitimate users. To verify the INACTIVE setting, run the following command: 
grep "INACTIVE" /etc/default/useradd
The output should indicate the INACTIVE configuration option is set to an appropriate integer as shown in the example below: 
$ sudo grep "INACTIVE" /etc/default/useradd
INACTIVE=
 Disabling inactive accounts ensures that accounts which may not have been responsibly removed are not available to attackers who may have compromised their credentials. Ensure All Accounts on the System Have Unique Names Change usernames, or delete accounts, so each has a unique name. Run the following command to check for duplicate account names: 
$ sudo pwck -qr
If there are no duplicate names, no line will be returned. Unique usernames allow for accountability on the system. Assign Expiration Date to Temporary Accounts Temporary accounts are established as part of normal account activation procedures when there is a need for short-term accounts. In the event temporary or emergency accounts are required, configure the system to terminate them after a documented time period. For every temporary and emergency account, run the following command to set an expiration date on it, substituting USER and YYYY-MM-DD appropriately: 
$ sudo chage -E YYYY-MM-DD USER
YYYY-MM-DD indicates the documented expiration date for the account. For U.S. Government systems, the operating system must be configured to automatically terminate these types of accounts after a period of 72 hours. For every temporary and emergency account, run the following command to obtain its account aging and expiration information: 
$ sudo chage -l USER
Verify each of these accounts has an expiration date set as documented. If temporary user accounts remain active when no longer needed or for an excessive period, these accounts may be used to gain unauthorized access. To mitigate this risk, automated termination of all temporary accounts must be set upon account creation.
scap-security-guide-0.1.31/Fedora/input/xccdf/system/accounts/restrictions/password_expiration.xml000066400000000000000000000201461301675746700336540ustar00rootroot00000000000000 Set Password Expiration Parameters The file /etc/login.defs controls several password-related settings. Programs such as passwd, su, and login consult /etc/login.defs to determine behavior with regard to password aging, expiration warnings, and length. See the man page login.defs(5) for more information.

Users should be forced to change their passwords, in order to decrease the utility of compromised passwords. However, the need to change passwords often should be balanced against the risk that users will reuse or write down passwords if forced to change them too often. Forcing password changes every 90-360 days, depending on the environment, is recommended. Set the appropriate value as PASS_MAX_DAYS and apply it to existing accounts with the -M flag.

The PASS_MIN_DAYS (-m) setting prevents password changes for 7 days after the first change, to discourage password cycling. If you use this setting, train users to contact an administrator for an emergency password change in case a new password becomes compromised. The PASS_WARN_AGE (-W) setting gives users 7 days of warnings at login time that their passwords are about to expire.

For example, for each existing human user USER, expiration parameters could be adjusted to a 180 day maximum password age, 7 day minimum password age, and 7 day warning period with the following command: 
# chage -M 180 -m 7 -W 7 USER
 minimum password length Minimum number of characters in password This will only check new passwords 12 6 8 10 12 14 maximum password age Maximum age of password in days This will only apply to newly created accounts 60 60 90 120 180 minimum password age Minimum age of password in days This will only apply to newly created accounts 7 7 5 1 2 0 warning days before password expires The number of days' warning given before a password expires. This will only apply to newly created accounts 7 0 7 14 Password Minimum Length To specify password length requirements for new accounts, edit the file /etc/login.defs, locate the following line: 
PASS_MIN_LEN LENGTH
and correct it to have the form of: 
PASS_MIN_LEN

Nowadays recommended values, considered as secure by various organizations focused on topic of computer security, range from 12 (FISMA) up to 14 (DoD) characters for password length requirements. If a program consults /etc/login.defs and also another PAM module (such as pam_pwquality) during a password change operation, then the most restrictive must be satisfied. See PAM section for more information about enforcing password quality requirements. To check the minimum password length, run the command: 
$ grep PASS_MIN_LEN /etc/login.defs
Passwords of length 12 characters and more are nowadays considered to be a standard requirement. Requiring a minimum password length makes password cracking attacks more difficult by ensuring a larger search space. However, any security benefit from an onerous requirement must be carefully weighed against usability problems, support costs, or counterproductive behavior that may result. Password Minimum Age To specify password minimum age for new accounts, edit the file /etc/login.defs, locate the following line: 
PASS_MIN_DAYS DAYS
and correct it to have the form of: 
PASS_MIN_DAYS

A value greater than 1 day is considered to be sufficient for many environments. To check the minimum password age, run the command: 
$ grep PASS_MIN_DAYS /etc/login.defs
A value greater than 1 day is considered to be sufficient for many environments. Setting the minimum password age protects against users cycling back to a favorite password after satisfying the password reuse requirement. Password Maximum Age To specify password maximum age for new accounts, edit the file /etc/login.defs, locate the following line: 
PASS_MAX_DAYS DAYS
and correct it to have the form of: 
PASS_MAX_DAYS

A value less than 180 days is sufficient for many environments. To check the maximum password age, run the command: 
$ grep PASS_MAX_DAYS /etc/login.defs
A value less than 180 days is sufficient for many environments. Setting the password maximum age ensures users are required to periodically change their passwords. This could possibly decrease the utility of a stolen password. Requiring shorter password lifetimes increases the risk of users writing down the password in a convenient location subject to physical compromise. Password Warning Age To specify how many days prior to password expiration that a warning will be issued to users, edit the file /etc/login.defs, locate the following line: 
PASS_WARN_AGE DAYS
and correct it to have the form of: 
PASS_WARN_AGE

A value of 7 days would be nowadays considered to be a standard. To check the password warning age, run the command: 
$ grep PASS_WARN_AGE /etc/login.defs
A value of 7 days would be nowadays considered to be a standard. Setting the password warning age enables users to make the change at a practical time. scap-security-guide-0.1.31/Fedora/input/xccdf/system/accounts/restrictions/password_storage.xml000066400000000000000000000103421301675746700331330ustar00rootroot00000000000000 Proper Storage and Existence of Password Hashes By default, password hashes for local accounts are stored in the second field (colon-separated) in /etc/shadow. This file should be readable only by processes running with root credentials, preventing users from casually accessing others' password hashes and attempting to crack them. However, it remains possible to misconfigure the system and store password hashes in world-readable files such as /etc/passwd, or to even store passwords themselves in plaintext on the system. Using system-provided tools for password change/creation should allow administrators to avoid such misconfiguration. Log In to Accounts With Empty Password Impossible If an account is configured for password authentication but does not have an assigned password, it may be possible to log into the account without authentication. Remove any instances of the nullok option in /etc/pam.d/system-auth to prevent logins with empty passwords. To verify that null passwords cannot be used, run the following command: 
# grep nullok /etc/pam.d/system-auth
If this produces any output, it may be possible to log into accounts with empty passwords. If an account has an empty password, anyone could log in and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments. Password Hashes For Each Account Shadowed If any password hashes are stored in /etc/passwd (in the second field, instead of an x), the cause of this misconfiguration should be investigated. The account should have its password reset and the hash should be properly stored, or the account should be deleted entirely. To check that no password hashes are stored in /etc/passwd, run the following command: 
# awk -F: '($2 != "x") {print}' /etc/passwd
If it produces any output, then a password hash is stored in /etc/passwd. The hashes for all user account passwords should be stored in the file /etc/shadow and never in /etc/passwd, which is readable by all users. All GIDs referenced in /etc/passwd Defined in /etc/group Add a group to the system for each GID referenced without a corresponding group. To ensure all GIDs referenced in /etc/passwd are defined in /etc/group, run the following command: 
# pwck -qr
There should be no output. Inconsistency in GIDs between /etc/passwd and /etc/group could lead to a user having unintended rights. netrc Files Do Not Exist The .netrc files contain login information used to auto-login into FTP servers and reside in the user's home directory. These files may contain unencrypted passwords to remote FTP servers making them susceptible to access by unauthorized users and should not be used. Any .netrc files should be removed. To check the system for the existence of any .netrc files, run the following command: 
# find /home -xdev -name .netrc
 Unencrypted passwords for remote FTP servers may be stored in .netrc files. DoD policy requires passwords be encrypted in storage and not used in access scripts. scap-security-guide-0.1.31/Fedora/input/xccdf/system/accounts/restrictions/root_logins.xml000066400000000000000000000232721301675746700321110ustar00rootroot00000000000000 Restrict Root Logins Direct root logins should be allowed only for emergency use. In normal situations, the administrator should access the system via a unique unprivileged account, and then use su or sudo to execute privileged commands. Discouraging administrators from accessing the root account directly ensures an audit trail in organizations with multiple administrators. Locking down the channels through which root can connect directly also reduces opportunities for password-guessing against the root account. The login program uses the file /etc/securetty to determine which interfaces should allow root logins. The virtual devices /dev/console and /dev/tty* represent the system consoles (accessible via the Ctrl-Alt-F1 through Ctrl-Alt-F6 keyboard sequences on a default installation). The default securetty file also contains /dev/vc/*. These are likely to be deprecated in most environments, but may be retained for compatibility. Furthermore, /dev/hvc* represent virtio-serial consoles, /dev/hvsi* IBM pSeries serial consoles, and finally /dev/xvc0 Xen virtual console. Root should also be prohibited from connecting via network protocols. Other sections of this document include guidance describing how to prevent root from logging in via SSH. Direct root Logins Not Allowed To further limit access to the root account, administrators can disable root logins at the console by editing the /etc/securetty file. This file lists all devices the root user is allowed to login to. If the file does not exist at all, the root user can login through any communication device on the system, whether via the console or via a raw network interface. This is dangerous as user can login to his machine as root via Telnet, which sends the password in plain text over the network. By default, Fedora's /etc/securetty file only allows the root user to login at the console physically attached to the machine. To prevent root from logging in, remove the contents of this file. To prevent direct root logins, remove the contents of this file by typing the following command: 
echo > /etc/securetty
To ensure root may not directly login to the system over physical consoles, run the following command: 
cat /etc/securetty
If any output is returned, this is a finding. Disabling direct root logins ensures proper accountability and multifactor authentication to privileged accounts. Users will first login, then escalate to privileged (root) access via su / sudo. This scenario is nowadays required by security standards. Virtual Console Root Logins Restricted To restrict root logins through the (deprecated) virtual console devices, ensure lines of this form do not appear in /etc/securetty: 
vc/1
vc/2
vc/3
vc/4
 To check for virtual console entries which permit root login, run the following command: 
# grep ^vc/[0-9] /etc/securetty
If any output is returned, then root logins over virtual console devices is permitted. Preventing direct root login to virtual console devices helps ensure accountability for actions taken on the system using the root account. Serial Port Root Logins Restricted To restrict root logins on serial ports, ensure lines of this form do not appear in /etc/securetty: 
ttyS0
ttyS1
 To check for serial port entries which permit root login, run the following command: 
# grep ^ttyS/[0-9] /etc/securetty
If any output is returned, then root login over serial ports is permitted. Preventing direct root login to serial port interfaces helps ensure accountability for actions taken on the systems using the root account. Web Browser Use for Administrative Accounts Restricted Enforce policy requiring administrative accounts use web browsers only for local service administration. Check the root home directory for a .mozilla directory. If one exists, ensure browsing is limited to local service administration. If a browser vulnerability is exploited while running with administrative privileges, the entire system could be compromised. Specific exceptions for local service administration should be documented in site-defined policy. System Accounts Do Not Run a Shell Upon Login Some accounts are not associated with a human user of the system, and exist to perform some administrative function. Should an attacker be able to log into these accounts, they should not be granted access to a shell.

The login shell for each local account is stored in the last field of each line in /etc/passwd. System accounts are those user accounts with a user ID less than UID_MIN, where value of the UID_MIN directive is set in /etc/login.defs configuration file. In the default configuration UID_MIN is set to 1000, thus system accounts are those user accounts with a user ID less than 1000. The user ID is stored in the third field. If any system account SYSACCT (other than root) has a login shell, disable it with the command: 
# usermod -s /sbin/nologin SYSACCT
 To obtain a listing of all users, their UIDs, and their shells, run the command: 
$ awk -F: '{print $1 ":" $3 ":" $7}' /etc/passwd
Identify the system accounts from this listing. These will primarily be the accounts with UID numbers less than UID_MIN, other than root. Value of the UID_MIN directive is set in /etc/login.defs configuration file. In the default configuration UID_MIN is set to 1000. Ensuring shells are not given to system accounts upon login makes it more difficult for attackers to make use of system accounts. Do not perform the steps in this section on the root account. Doing so might cause the system to become inaccessible. Only Root Has UID 0 If any account other than root has a UID of 0, this misconfiguration should be investigated and the accounts other than root should be removed or have their UID changed. To list all password file entries for accounts with UID 0, run the following command: 
# awk -F: '($3 == "0") {print}' /etc/passwd
This should print only one line, for the user root. An account has root authority if it has a UID of 0. Multiple accounts with a UID of 0 afford more opportunity for potential intruders to guess a password for a privileged account. Proper configuration of sudo is recommended to afford multiple system administrators access to root privileges in an accountable manner. Root Path Is Vendor Default Assuming root shell is bash, edit the following files: 
~/.profile
~/.bashrc
Change any PATH variables to the vendor default for root and remove any empty PATH entries or references to relative paths. To view the root user's PATH, run the following command: 
# env | grep PATH
If correctly configured, the PATH must: use vendor default settings, have no empty entries, and have no entries beginning with a character other than a slash (/). The root account's executable search path must be the vendor default, and must contain only absolute paths. scap-security-guide-0.1.31/Fedora/input/xccdf/system/accounts/session.xml000066400000000000000000000322511301675746700265030ustar00rootroot00000000000000 Secure Session Configuration Files for Login Accounts When a user logs into a Unix account, the system configures the user's session by reading a number of files. Many of these files are located in the user's home directory, and may have weak permissions as a result of user error or misconfiguration. If an attacker can modify or even read certain types of account configuration information, they can often gain full access to the affected user's account. Therefore, it is important to test and correct configuration file permissions for interactive accounts, particularly those of privileged users such as root or system administrators. Maximum concurrent login sessions Maximum number of concurrent sessions by a user 1 1 3 5 10 15 20 Limit the Number of Concurrent Login Sessions Allowed Per User Limiting the number of allowed users and sessions per user can limit risks related to Denial of Service attacks. This addresses concurrent sessions for a single account and does not address concurrent sessions by a single user via multiple accounts. The DoD requirement is 10. To set the number of concurrent sessions per user add the following line in /etc/security/limits.conf: 
* hard maxlogins
Limiting simultaneous user logins can insulate the system from denial of service problems caused by excessive logins. Automated login processes operating improperly or maliciously may result in an exceptional number of simultaneous login sessions. Run the following command to ensure the maxlogins value is configured for all users on the system: 
$ grep "maxlogins" /etc/security/limits.conf
You should receive output similar to the following: 
*		hard	maxlogins
Ensure that No Dangerous Directories Exist in Root's Path The active path of the root account can be obtained by starting a new root shell and running: 
$ sudo echo $PATH
This will produce a colon-separated list of directories in the path.

Certain path elements could be considered dangerous, as they could lead to root executing unknown or untrusted programs, which could contain malicious code. Since root may sometimes work inside untrusted directories, the . character, which represents the current directory, should never be in the root path, nor should any directory which can be written to by an unprivileged or semi-privileged (system) user.

It is a good practice for administrators to always execute privileged commands by typing the full path to the command. Ensure that Root's Path Does Not Include Relative Paths or Null Directories Ensure that none of the directories in root's path is equal to a single . character, or that it contains any instances that lead to relative path traversal, such as .. or beginning a path without the slash (/) character. Also ensure that there are no "empty" elements in the path, such as in these examples: 
PATH=:/bin
PATH=/bin:
PATH=/bin::/sbin
These empty elements have the same effect as a single . character. Including these entries increases the risk that root could execute code from an untrusted location. Ensure that Root's Path Does Not Include World or Group-Writable Directories For each element in root's path, run: 
$ sudo ls -ld DIR
and ensure that write permissions are disabled for group and other. To ensure write permissions are disabled for group and other for each element in root's path, run the following command: 
$ sudo ls -ld DIR
 Such entries increase the risk that root could execute code provided by unprivileged users, and potentially malicious code. Ensure that User Home Directories are not Group-Writable or World-Readable For each human user of the system, view the permissions of the user's home directory: 
$ sudo ls -ld /home/USER
Ensure that the directory is not group-writable and that it is not world-readable. If necessary, repair the permissions: 
$ sudo chmod g-w /home/USER
$ sudo chmod o-rwx /home/USER
 To ensure the user home directory is not group-writable or world-readable, run the following: 
$ sudo ls -ld /home/USER
 This action may involve modifying user home directories. Notify your user community, and solicit input if appropriate, before making this type of change. User home directories contain many configuration files which affect the behavior of a user's account. No user should ever have write permission to another user's home directory. Group shared directories can be configured in sub-directories or elsewhere in the filesystem if they are needed. Typically, user home directories should not be world-readable, as it would disclose file names to other users. If a subset of users need read access to one another's home directories, this can be provided using groups or ACLs. Ensure that Users Have Sensible Umask Values The umask setting controls the default permissions for the creation of new files. With a default umask setting of 077, files and directories created by users will not be readable by any other user on the system. Users who wish to make specific files group- or world-readable can accomplish this by using the chmod command. Additionally, users can make all their files readable to their group by default by setting a umask of 027 in their shell configuration files. If default per-user groups exist (that is, if every user has a default group whose name is the same as that user's username and whose only member is the user), then it may even be safe for users to select a umask of 007, making it very easy to intentionally share files with groups of which the user is a member.

Sensible umask Enter default user umask 027 007 022 027 077 Ensure the Default Bash Umask is Set Correctly To ensure the default umask for users of the Bash shell is set properly, add or correct the umask setting in /etc/bashrc to read as follows: 
umask
The umask value influences the permissions assigned to files when they are created. A misconfigured umask value could result in files with excessive permissions that can be read or written to by unauthorized users. Verify the umask setting is configured correctly in the /etc/bashrc file by running the following command: 
$ grep "umask" /etc/bashrc
All output must show the value of umask set as shown below: 
$ grep "umask" /etc/bashrc
umask 
umask
Ensure the Default C Shell Umask is Set Correctly To ensure the default umask for users of the C shell is set properly, add or correct the umask setting in /etc/csh.cshrc to read as follows: 
umask
The umask value influences the permissions assigned to files when they are created. A misconfigured umask value could result in files with excessive permissions that can be read or written to by unauthorized users. Verify the umask setting is configured correctly in the /etc/csh.cshrc file by running the following command: 
$ grep "umask" /etc/csh.cshrc
All output must show the value of umask set as shown in the below: 
$ grep "umask" /etc/csh.cshrc
umask
Ensure the Default Umask is Set Correctly in /etc/profile To ensure the default umask controlled by /etc/profile is set properly, add or correct the umask setting in /etc/profile to read as follows: 
umask
The umask value influences the permissions assigned to files when they are created. A misconfigured umask value could result in files with excessive permissions that can be read or written to by unauthorized users. Verify the umask setting is configured correctly in the /etc/profile file by running the following command: 
$ grep "umask" /etc/profile
All output must show the value of umask set as shown in the below: 
$ grep "umask" /etc/profile
umask
Ensure the Default Umask is Set Correctly in login.defs To ensure the default umask controlled by /etc/login.defs is set properly, add or correct the UMASK setting in /etc/login.defs to read as follows: 
UMASK
The umask value influences the permissions assigned to files when they are created. A misconfigured umask value could result in files with excessive permissions that can be read and written to by unauthorized users. Verify the UMASK setting is configured correctly in the /etc/login.defs file by running the following command: 
$ grep -i "UMASK" /etc/login.defs
All output must show the value of umask set as shown in the below: 
$ grep -i "UMASK" /etc/login.defs
umask
scap-security-guide-0.1.31/Fedora/input/xccdf/system/auditing.xml000066400000000000000000002530601301675746700250100ustar00rootroot00000000000000 System Accounting with <tt>auditd</tt> The audit service provides substantial capabilities for recording system activities. By default, the service audits about SELinux AVC denials and certain types of security-relevant events such as system logins, account modifications, and authentication events performed by programs such as sudo. Under its default configuration, auditd has modest disk space requirements, and should not noticeably impact system performance.
NOTE: The Linux Audit daemon auditd can be configured to use the auditctl utility to read audit rules from the /etc/audit/audit.rules configuration file, and load them into the kernel during daemon startup (default configuration). Alternatively, the auditd daemon can be configured to use the augenrules program to read audit rules files (*.rules) located in /etc/audit/rules.d location and compile them to create the resulting form of the /etc/audit/audit.rules configuration file during the daemon startup. The expected behavior is configured via the appropriate ExecStartPost directive setting in the /usr/lib/systemd/system/auditd.service configuration file. To instruct the auditd daemon to use the auditctl utility to read audit rules (default configuration), use the following setting: 
ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rules
in the /usr/lib/systemd/system/auditd.service configuration file. In order to instruct the auditd daemon to use the augenrules program to read audit rules, use the following setting: 
ExecStartPost=-/sbin/augenrules --load
in the /usr/lib/systemd/system/auditd.service configuration file. Refer to [Service] section of the /usr/lib/systemd/system/auditd.service configuration for further details.
Government networks often have substantial auditing requirements and auditd can be configured to meet these requirements. Examining some example audit records demonstrates how the Linux audit system satisfies common requirements. The following example from Fedora Documentation available at shows the substantial amount of information captured in a two typical "raw" audit messages, followed by a breakdown of the most important fields. In this example the message is SELinux-related and reports an AVC denial (and the associated system call) that occurred when the Apache HTTP Server attempted to access the /var/www/html/file1 file (labeled with the samba_share_t type): 
type=AVC msg=audit(1226874073.147:96): avc:  denied  { getattr } for pid=2465 comm="httpd"
path="/var/www/html/file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file

type=SYSCALL msg=audit(1226874073.147:96): arch=40000003 syscall=196 success=no exit=-13
a0=b98df198 a1=bfec85dc a2=54dff4 a3=2008171 items=0 ppid=2463 pid=2465 auid=502 uid=48
gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=6 comm="httpd"
exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
  • msg=audit(1226874073.147:96)
    • The number in parentheses is the unformatted time stamp (Epoch time) for the event, which can be converted to standard time by using the date command.
  • { getattr }
    • The item in braces indicates the permission that was denied. getattr indicates the source process was trying to read the target file's status information. This occurs before reading files. This action is denied due to the file being accessed having the wrong label. Commonly seen permissions include getattr, read, and write.
  • comm="httpd"
    • The executable that launched the process. The full path of the executable is found in the exe= section of the system call (SYSCALL) message, which in this case, is exe="/usr/sbin/httpd".
  • path="/var/www/html/file1"
    • The path to the object (target) the process attempted to access.
  • scontext="unconfined_u:system_r:httpd_t:s0"
    • The SELinux context of the process that attempted the denied action. In this case, it is the SELinux context of the Apache HTTP Server, which is running in the httpd_t domain.
  • tcontext="unconfined_u:object_r:samba_share_t:s0"
    • The SELinux context of the object (target) the process attempted to access. In this case, it is the SELinux context of file1. Note: the samba_share_t type is not accessible to processes running in the httpd_t domain.
  • From the system call (SYSCALL) message, two items are of interest:
    • success=no: indicates whether the denial (AVC) was enforced or not. success=no indicates the system call was not successful (SELinux denied access). success=yes indicates the system call was successful - this can be seen for permissive domains or unconfined domains, such as initrc_t and kernel_t.
    • exe="/usr/sbin/httpd": the full path to the executable that launched the process, which in this case, is exe="/usr/sbin/httpd".
Enable Auditing for Processes Which Start Prior to the Audit Daemon To ensure all processes can be audited, even those which start prior to the audit daemon, add the argument audit=1 to the default GRUB 2 command line for the Linux operating system in /etc/default/grub, in the manner below: 
GRUB_CMDLINE_LINUX="rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/root rd.luks.uuid=luks-3431fd4f-80aa-436e-8acf-24f5bcb4e23a rhgb quiet audit=1"
 Inspect the form of default GRUB 2 command line for the Linux operating system in /etc/default/grub. If they include audit=1, then auditing is enabled at boot time. Each process on the system carries an "auditable" flag which indicates whether its activities can be audited. Although auditd takes care of enabling this for all processes which launch after it does, adding the kernel argument ensures it is set for every process during boot. The GRUB 2 configuration file, grub.cfg, is automatically updated each time a new kernel is installed. Note that any changes to /etc/default/grub require rebuilding the grub.cfg file. To update the GRUB 2 configuration file manually, use the 
grub2-mkconfig -o
command as follows:
  • On BIOS-based machines, issue the following command as root: 
    ~]# grub2-mkconfig -o /boot/grub2/grub.cfg
  • On UEFI-based machines, issue the following command as root: 
    ~]# grub2-mkconfig -o /boot/efi/fedora/grub2/grub.cfg
 Configure <tt>auditd</tt> Data Retention The audit system writes data to /var/log/audit/audit.log. By default, auditd rotates 5 logs by size (6MB), retaining a maximum of 30MB of data in total, and refuses to write entries when the disk is too full. This minimizes the risk of audit data filling its partition and impacting other services. This also minimizes the risk of the audit daemon temporarily disabling the system if it cannot write audit log (which it can be configured to do). For a busy system or a system which is thoroughly auditing system activity, the default settings for data retention may be insufficient. The log file size needed will depend heavily on what types of events are being audited. First configure auditing to log all the events of interest. Then monitor the log size manually for awhile to determine what file size will allow you to keep the required data for the correct time period.

Using a dedicated partition for /var/log/audit prevents the auditd logs from disrupting system functionality if they fill, and, more importantly, prevents other activity in /var from filling the partition and stopping the audit trail. (The audit logs are size-limited and therefore unlikely to grow without bound unless configured to do so.) Some machines may have requirements that no actions occur which cannot be audited. If this is the case, then auditd can be configured to halt the machine if it runs out of space. Note: Since older logs are rotated, configuring auditd this way does not prevent older logs from being rotated away before they can be viewed. If your system is configured to halt when logging cannot be performed, make sure this can never happen under normal circumstances! Ensure that /var/log/audit is on its own partition, and that this partition is larger than the maximum amount of data auditd will retain normally. Number of log files for auditd to retain The setting for num_logs in /etc/audit/auditd.conf 5 5 4 3 2 1 0 Maximum audit log file size for auditd The setting for max_log_size in /etc/audit/auditd.conf 6 20 10 6 5 1 Action for auditd to take when log files reach their maximum size The setting for max_log_file_action in /etc/audit/auditd.conf rotate ignore syslog suspend rotate keep_logs Action for auditd to take when disk space just starts to run low The setting for space_left_action in /etc/audit/auditd.conf email ignore syslog email exec suspend single halt Action for auditd to take when disk space just starts to run low The setting for space_left_action in /etc/audit/auditd.conf single ignore syslog email exec suspend single halt Account for auditd to send email when actions occurs The setting for action_mail_acct in /etc/audit/auditd.conf root root admin Auditd priority for flushing data to disk The setting for flush in /etc/audit/auditd.conf data none incremental data sync Configure auditd Number of Logs Retained Determine how many log files auditd should retain when it rotates logs. Edit the file /etc/audit/auditd.conf. Add or modify the following line, substituting NUMLOGS with the correct value of : 
num_logs = NUMLOGS
Set the value to 5 for general-purpose systems. Note that values less than 2 result in no log rotation. Inspect /etc/audit/auditd.conf and locate the following line to determine how many logs the system is configured to retain after rotation: $ sudo grep num_logs /etc/audit/auditd.conf 
num_logs = 5
 The total storage for audit log files must be large enough to retain log information over the period required. This is a function of the maximum log file size and the number of logs retained. Configure auditd Max Log File Size Determine the amount of audit data (in megabytes) which should be retained in each log file. Edit the file /etc/audit/auditd.conf. Add or modify the following line, substituting the correct value of for STOREMB: 
max_log_file = STOREMB
Set the value to 6 (MB) or higher for general-purpose systems. Larger values, of course, support retention of even more audit data. Inspect /etc/audit/auditd.conf and locate the following line to determine how much data the system will retain in each audit log file: $ sudo grep max_log_file /etc/audit/auditd.conf 
max_log_file = 6
 The total storage for audit log files must be large enough to retain log information over the period required. This is a function of the maximum log file size and the number of logs retained. Configure auditd max_log_file_action Upon Reaching Maximum Log Size The default action to take when the logs reach their maximum size is to rotate the log files, discarding the oldest one. To configure the action taken by auditd, add or correct the line in /etc/audit/auditd.conf: 
max_log_file_action = ACTION
Possible values for ACTION are described in the auditd.conf man page. These include:
  • ignore
  • syslog
  • suspend
  • rotate
  • keep_logs
Set the ACTION to rotate to ensure log rotation occurs. This is the default. The setting is case-insensitive. Inspect /etc/audit/auditd.conf and locate the following line to determine if the system is configured to rotate logs when they reach their maximum size: $ sudo grep max_log_file_action /etc/audit/auditd.conf 
max_log_file_action rotate
 Automatically rotating logs (by setting this to rotate) minimizes the chances of the system unexpectedly running out of disk space by being overwhelmed with log data. However, for systems that must never discard log data, or which use external processes to transfer it and reclaim space, keep_logs can be employed. Configure auditd space_left Action on Low Disk Space The auditd service can be configured to take an action when disk space starts to run low. Edit the file /etc/audit/auditd.conf. Modify the following line, substituting ACTION appropriately: 
space_left_action = ACTION
Possible values for ACTION are described in the auditd.conf man page. These include:
  • ignore
  • syslog
  • email
  • exec
  • suspend
  • single
  • halt
Set this to email (instead of the default, which is suspend) as it is more likely to get prompt attention. Acceptable values also include suspend, single, and halt. Inspect /etc/audit/auditd.conf and locate the following line to determine if the system is configured to email the administrator when disk space is starting to run low: $ sudo grep space_left_action /etc/audit/auditd.conf 
space_left_action
Acceptable values are email, suspend, single, and halt. Notifying administrators of an impending disk space problem may allow them to take corrective action prior to any disruption. Configure auditd admin_space_left Action on Low Disk Space The auditd service can be configured to take an action when disk space is running low but prior to running out of space completely. Edit the file /etc/audit/auditd.conf. Add or modify the following line, substituting ACTION appropriately: 
admin_space_left_action = ACTION
Set this value to single to cause the system to switch to single user mode for corrective action. Acceptable values also include suspend and halt. For certain systems, the need for availability outweighs the need to log all actions, and a different setting should be determined. Details regarding all possible values for ACTION are described in the auditd.conf man page. Inspect /etc/audit/auditd.conf and locate the following line to determine if the system is configured to either suspend, switch to single user mode, or halt when disk space has run low: 
admin_space_left_action single
 Administrators should be made aware of an inability to record audit records. If a separate partition or logical volume of adequate size is used, running low on space for audit records should never occur. Configure auditd mail_acct Action on Low Disk Space The auditd service can be configured to send email to a designated account in certain situations. Add or correct the following line in /etc/audit/auditd.conf to ensure that administrators are notified via email for those situations: 
action_mail_acct =
Inspect /etc/audit/auditd.conf and locate the following line to determine if the system is configured to send email to an account when it needs to notify an administrator: 
action_mail_acct = root
 Email sent to the root account is typically aliased to the administrators of the system, who can take appropriate action. Configure auditd flush priority The auditd service can be configured to synchronously write audit event data to disk. Add or correct the following line in /etc/audit/auditd.conf to ensure that audit event data is fully synchronized with the log files on the disk: 
flush =
Inspect /etc/audit/auditd.conf and locate the following line to determine if the system is configured to synchronize audit event data with the log files on the disk: $ sudo grep flush /etc/audit/auditd.conf 
flush = DATA
Acceptable values are DATA, and SYNC. The setting is case-insensitive. Audit data should be synchronously written to disk to ensure log integrity. These parameters assure that all audit event data is fully synchronized with the log files on the disk. Configure auditd to use audispd's syslog plugin To configure the auditd service to use the syslog plug-in of the audispd audit event multiplexor, set the active line in /etc/audisp/plugins.d/syslog.conf to yes. Restart the auditd service: 
$ sudo service auditd restart
 To verify the audispd's syslog plugin is active, run the following command: 
$ sudo grep active /etc/audisp/plugins.d/syslog.conf
If the plugin is active, the output will show yes. The auditd service does not include the ability to send audit records to a centralized server for management directly. It does, however, include a plug-in for audit event multiplexor (audispd) to pass audit records to the local syslog server Configure <tt>auditd</tt> Rules for Comprehensive Auditing The auditd program can perform comprehensive monitoring of system activity. This section describes recommended configuration settings for comprehensive auditing, but a full description of the auditing system's capabilities is beyond the scope of this guide. The mailing list linux-audit@redhat.com exists to facilitate community discussion of the auditing system.

The audit subsystem supports extensive collection of events, including:
  • Tracing of arbitrary system calls (identified by name or number) on entry or exit.
  • Filtering by PID, UID, call success, system call argument (with some limitations), etc.
  • Monitoring of specific files for modifications to the file's contents or metadata.

Auditing rules at startup are controlled by the file /etc/audit/audit.rules. Add rules to it to meet the auditing requirements for your organization. Each line in /etc/audit/audit.rules represents a series of arguments that can be passed to auditctl and can be individually tested during runtime. See documentation in /usr/share/doc/audit-VERSION and in the related man pages for more details.

If copying any example audit rulesets from /usr/share/doc/audit-VERSION, be sure to comment out the lines containing arch= which are not appropriate for your system's architecture. Then review and understand the following rules, ensuring rules are activated as needed for the appropriate architecture.

After reviewing all the rules, reading the following sections, and editing as needed, the new rules can be activated as follows: 
$ sudo service auditd restart
 Records Events that Modify Date and Time Information Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time. All changes to the system time should be audited. Record attempts to alter time through adjtimex If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S adjtimex -k audit_time_rules
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S adjtimex -k audit_time_rules
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S adjtimex -k audit_time_rules
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S adjtimex -k audit_time_rules
The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls: 
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k audit_time_rules
 Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited. Record attempts to alter time through settimeofday If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S settimeofday -k audit_time_rules
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S settimeofday -k audit_time_rules
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S settimeofday -k audit_time_rules
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S settimeofday -k audit_time_rules
The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls: 
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k audit_time_rules
 Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited. Record Attempts to Alter Time Through stime If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file for both 32 bit and 64 bit systems: 
-a always,exit -F arch=b32 -S stime -k audit_time_rules
Since the 64 bit version of the "stime" system call is not defined in the audit lookup table, the corresponding "-F arch=b64" form of this rule is not expected to be defined on 64 bit systems (the aforementioned "-F arch=b32" stime rule form itself is sufficient for both 32 bit and 64 bit systems). If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d for both 32 bit and 64 bit systems: 
-a always,exit -F arch=b32 -S stime -k audit_time_rules
Since the 64 bit version of the "stime" system call is not defined in the audit lookup table, the corresponding "-F arch=b64" form of this rule is not expected to be defined on 64 bit systems (the aforementioned "-F arch=b32" stime rule form itself is sufficient for both 32 bit and 64 bit systems). The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined system calls: 
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k audit_time_rules
 If the system is not configured to audit time changes, this is a finding. If the system is 64-bit only, this is not applicable
 Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited. Record Attempts to Alter Time Through clock_settime If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=time-change
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=time-change
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=time-change
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=time-change
The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls: 
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k audit_time_rules
 Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited. Record Attempts to Alter the localtime File If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: 
-w /etc/localtime -p wa -k audit_time_rules
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-w /etc/localtime -p wa -k audit_time_rules
The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport and should always be used. To determine if the system is configured to audit attempts to alter time via the /etc/localtime file, run the following command: 
$ sudo auditctl -l | grep "watch=/etc/localtime"
If the system is configured to audit this activity, it will return a line. Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited. Record Events that Modify User/Group Information If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following lines to /etc/audit/audit.rules file, in order to capture events that modify account changes: 
-w /etc/group -p wa -k audit_rules_usergroup_modification
-w /etc/passwd -p wa -k audit_rules_usergroup_modification
-w /etc/gshadow -p wa -k audit_rules_usergroup_modification
-w /etc/shadow -p wa -k audit_rules_usergroup_modification
-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d, in order to capture events that modify account changes: 
-w /etc/group -p wa -k audit_rules_usergroup_modification
-w /etc/passwd -p wa -k audit_rules_usergroup_modification
-w /etc/gshadow -p wa -k audit_rules_usergroup_modification
-w /etc/shadow -p wa -k audit_rules_usergroup_modification
-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification
 To determine if the system is configured to audit account changes, run the following command: 
auditctl -l | egrep '(/etc/passwd|/etc/shadow|/etc/group|/etc/gshadow|/etc/security/opasswd)'
If the system is configured to watch for account changes, lines should be returned for each file specified (and with perm=wa for each). In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy. Record Events that Modify the System's Network Environment If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following lines to /etc/audit/audit.rules file, setting ARCH to either b32 or b64 as appropriate for your system: 
-a always,exit -F arch=ARCH -S sethostname -S setdomainname -k audit_rules_networkconfig_modification
-w /etc/issue -p wa -k audit_rules_networkconfig_modification
-w /etc/issue.net -p wa -k audit_rules_networkconfig_modification
-w /etc/hosts -p wa -k audit_rules_networkconfig_modification
-w /etc/sysconfig/network -p wa -k audit_rules_networkconfig_modification
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d, setting ARCH to either b32 or b64 as appropriate for your system: 
-a always,exit -F arch=ARCH -S sethostname -S setdomainname -k audit_rules_networkconfig_modification
-w /etc/issue -p wa -k audit_rules_networkconfig_modification
-w /etc/issue.net -p wa -k audit_rules_networkconfig_modification
-w /etc/hosts -p wa -k audit_rules_networkconfig_modification
-w /etc/sysconfig/network -p wa -k audit_rules_networkconfig_modification
 To determine if the system is configured to audit changes to its network configuration, run the following command: 
auditctl -l | egrep '(/etc/issue|/etc/issue.net|/etc/hosts|/etc/sysconfig/network)'
If the system is configured to watch for network configuration changes, a line should be returned for each file specified (and perm=wa should be indicated for each). The network environment should not be modified by anything other than administrator action. Any change to network parameters should be audited. System Audit Logs Must Have Mode 0640 or Less Permissive Change the mode of the audit log files with the following command: 
$ sudo chmod 0640 audit_file
 Run the following command to check the mode of the system audit logs: 
$ sudo ls -l /var/log/audit
Audit logs must be mode 0640 or less permissive. If users can write to audit logs, audit trails can be modified or destroyed. System Audit Logs Must Be Owned By Root Failure to give ownership of the audit log files to root allows the designated owner, and unauthorized users, potential access to sensitive information. Record Events that Modify the System's Mandatory Access Controls If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: 
-w /etc/selinux/ -p wa -k MAC-policy
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-w /etc/selinux/ -p wa -k MAC-policy
 To determine if the system is configured to audit changes to its SELinux configuration files, run the following command: 
$ sudo auditctl -l | grep "dir=/etc/selinux"
If the system is configured to watch for changes to its SELinux configuration, a line should be returned (including perm=wa indicating permissions that are watched). The system's mandatory access policy (SELinux) should not be arbitrarily changed by anything other than administrator action. All changes to MAC policy should be audited. Record Events that Modify the System's Discretionary Access Controls At a minimum the audit system should collect file permission changes for all users and root. Note that the "-F arch=b32" lines should be present even on a 64 bit system. These commands identify system calls for auditing. Even if the system is 64 bit it can still execute 32 bit system calls. Additionally, these rules can be configured in a number of ways while still achieving the desired effect. An example of this is that the "-S" calls could be split up and placed on separate lines, however, this is less efficient. Add the following to /etc/audit/audit.rules: 
-a always,exit -F arch=b32 -S chmod -S fchmod -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod
    -a always,exit -F arch=b32 -S chown -S fchown -S fchownat -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod
    -a always,exit -F arch=b32 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
If your system is 64 bit then these lines should be duplicated and the arch=b32 replaced with arch=b64 as follows: 
-a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod
    -a always,exit -F arch=b64 -S chown -S fchown -S fchownat -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod
    -a always,exit -F arch=b64 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
 The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Record Events that Modify the System's Discretionary Access Controls - chmod At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S chmod  -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S chmod  -F auid>=1000 -F auid!=4294967295 -k perm_mod
 The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. Record Events that Modify the System's Discretionary Access Controls - chown At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=4294967295 -k perm_mod
 The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. Record Events that Modify the System's Discretionary Access Controls - fchmod At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=4294967295 -k perm_mod
 The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. Record Events that Modify the System's Discretionary Access Controls - fchmodat At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod
 The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. Record Events that Modify the System's Discretionary Access Controls - fchown At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_mod
 The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. Record Events that Modify the System's Discretionary Access Controls - fchownat At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=4294967295 -k perm_mod
 The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. Record Events that Modify the System's Discretionary Access Controls - fremovexattr At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
 The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. Record Events that Modify the System's Discretionary Access Controls - fsetxattr At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
 The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. Record Events that Modify the System's Discretionary Access Controls - lchown At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod
 The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. Record Events that Modify the System's Discretionary Access Controls - lremovexattr At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
 The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. Record Events that Modify the System's Discretionary Access Controls - lsetxattr At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
 The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. Record Events that Modify the System's Discretionary Access Controls - removexattr At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
 The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. Record Events that Modify the System's Discretionary Access Controls - setxattr At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
 The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. Record Attempts to Alter Logon and Logout Events The audit system already collects login information for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following lines to /etc/audit/audit.rules file in order to watch for attempted manual edits of files involved in storing logon events: 
-w /var/log/tallylog -p wa -k logins
-w /var/run/faillock/ -p wa -k logins
-w /var/log/lastlog -p wa -k logins
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d in order to watch for attempted manual edits of files involved in storing logon events: 
-w /var/log/tallylog -p wa -k logins
-w /var/run/faillock/ -p wa -k logins
-w /var/log/lastlog -p wa -k logins
 Manual editing of these files may indicate nefarious activity, such as an attacker attempting to remove evidence of an intrusion. Record Attempts to Alter Process and Session Initiation Information The audit system already collects process information for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following lines to /etc/audit/audit.rules file in order to watch for attempted manual edits of files involved in storing such process information: 
-w /var/run/utmp -p wa -k session
-w /var/log/btmp -p wa -k session
-w /var/log/wtmp -p wa -k session
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d in order to watch for attempted manual edits of files involved in storing such process information: 
-w /var/run/utmp -p wa -k session
-w /var/log/btmp -p wa -k session
-w /var/log/wtmp -p wa -k session
 Manual editing of these files may indicate nefarious activity, such as an attacker attempting to remove evidence of an intrusion. Ensure <tt>auditd</tt> Collects Unauthorized Access Attempts to Files (unsuccessful) At a minimum the audit system should collect unauthorized file accesses for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following lines to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k access
-a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k access
If the system is 64 bit then also add the following lines: 
-a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k access
-a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k access
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k access
-a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k access
If the system is 64 bit then also add the following lines: 
-a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k access
-a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k access
 To verify that the audit system collects unauthorized file accesses, run the following commands: 
$ sudo grep EACCES /etc/audit/audit.rules
$ sudo grep EPERM /etc/audit/audit.rules
 Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise. Ensure <tt>auditd</tt> Collects Information on the Use of Privileged Commands At a minimum the audit system should collect the execution of privileged commands for all users and root. To find the relevant setuid / setgid programs, run the following command for each local partition PART: 
$ sudo find PART -xdev -type f -perm -4000 -o -type f -perm -2000 2>/dev/null
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add a line of the following form to /etc/audit/audit.rules for each setuid / setgid program on the system, replacing the SETUID_PROG_PATH part with the full path of that setuid / setgid program in the list: 
-a always,exit -F path=SETUID_PROG_PATH -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d for each setuid / setgid program on the system, replacing the SETUID_PROG_PATH part with the full path of that setuid / setgid program in the list: 
-a always,exit -F path=SETUID_PROG_PATH -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged
 To verify that auditing of privileged command use is configured, run the following command for each local partition PART to find relevant setuid / setgid programs: 
$ sudo find PART -xdev -type f -perm -4000 -o -type f -perm -2000 2>/dev/null
Run the following command to verify entries in the audit rules for all programs found with the previous command: 
$ sudo grep path /etc/audit/audit.rules
It should be the case that all relevant setuid / setgid programs have a line in the audit rules. Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity. Ensure <tt>auditd</tt> Collects Information on Exporting to Media (successful) At a minimum the audit system should collect media exportation events for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file, setting ARCH to either b32 or b64 as appropriate for your system: 
-a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=4294967295 -k export
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d, setting ARCH to either b32 or b64 as appropriate for your system: 
-a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=4294967295 -k export
 To verify that auditing is configured for all media exportation events, run the following command: 
$ sudo auditctl -l | grep syscall | grep mount
 The unauthorized exportation of data to external media could result in an information leak where classified information, Privacy Act information, and intellectual property could be lost. An audit trail should be created each time a filesystem is mounted to help identify and guard against information loss. Ensure <tt>auditd</tt> Collects File Deletion Events by User At a minimum the audit system should collect file deletion events for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file, setting ARCH to either b32 or b64 as appropriate for your system: 
-a always,exit -F arch=ARCH -S rmdir -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k delete
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d, setting ARCH to either b32 or b64 as appropriate for your system: 
-a always,exit -F arch=ARCH -S rmdir -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k delete
 Auditing file deletions will create an audit trail for files that are removed from the system. The audit trail could aid in system troubleshooting, as well as, detecting malicious processes that attempt to delete log files to conceal their presence. Ensure <tt>auditd</tt> Collects System Administrator Actions At a minimum the audit system should collect administrator actions for all users and root. If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file: 
-w /etc/sudoers -p wa -k actions
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-w /etc/sudoers -p wa -k actions
 To verify that auditing is configured for system administrator actions, run the following command: 
$ sudo auditctl -l | grep "watch=/etc/sudoers"
 The actions taken by system administrators should be audited to keep a record of what was executed on the system, as well as, for accountability purposes. Ensure <tt>auditd</tt> Collects Information on Kernel Module Loading and Unloading If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following lines to /etc/audit/audit.rules file in order to capture kernel module loading and unloading events, setting ARCH to either b32 or b64 as appropriate for your system: 
-w /usr/sbin/insmod -p x -k modules
-w /usr/sbin/rmmod -p x -k modules
-w /usr/sbin/modprobe -p x -k modules
-a always,exit -F arch=ARCH -S init_module -S delete_module -k modules
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d to capture kernel module loading and unloading events, setting ARCH to either b32 or b64 as appropriate for your system: 
-w /usr/sbin/insmod -p x -k modules
-w /usr/sbin/rmmod -p x -k modules
-w /usr/sbin/modprobe -p x -k modules
-a always,exit -F arch=ARCH -S init_module -S delete_module -k modules
 The addition/removal of kernel modules can be used to alter the behavior of the kernel and potentially introduce malicious code into kernel space. It is important to have an audit trail of modules that have been introduced into the kernel. Make the <tt>auditd</tt> Configuration Immutable If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup (the default), add the following line to /etc/audit/audit.rules file in order to make the auditd configuration immutable: 
-e 2
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup, add the following line to a file with suffix .rules in the directory /etc/audit/rules.d in order to make the auditd configuration immutable: 
-e 2
With this setting, a reboot will be required to change any audit rules. Making the audit configuration immutable prevents accidental as well as malicious modification of the audit rules, although it may be problematic if legitimate changes are needed during system operation scap-security-guide-0.1.31/Fedora/input/xccdf/system/logging.xml000066400000000000000000000452511301675746700246330ustar00rootroot00000000000000 Configure Syslog The syslog service has been the default Unix logging mechanism for many years. It has a number of downsides, including inconsistent log format, lack of authentication for received messages, and lack of authentication, encryption, or reliable transport for messages sent over a network. However, due to its long history, syslog is a de facto standard which is supported by almost all Unix applications.

In Fedora, rsyslog has replaced ksyslogd as the syslog daemon of choice, and it includes some additional security features such as reliable, connection-oriented (i.e. TCP) transmission of logs, the option to log to database formats, and the encryption of log data en route to a central logging server. This section discusses how to configure rsyslog for best effect, and how to use tools provided with the system to maintain and monitor logs. Ensure rsyslog is Installed Rsyslog is installed by default. The rsyslog package provides the rsyslog daemon, which provides system logging services. Enable rsyslog Service The rsyslog service provides syslog-style logging by default on Fedora. The rsyslog service must be running in order to provide logging services, which are essential to system administration. Ensure Proper Configuration of Log Files The file /etc/rsyslog.conf controls where log message are written. These are controlled by lines called rules, which consist of a selector and an action. These rules are often customized depending on the role of the system, the requirements of the environment, and whatever may enable the administrator to most effectively make use of log data. The default rules in Fedora are: 
*.info;mail.none;authpriv.none;cron.none                /var/log/messages
authpriv.*                                              /var/log/secure
mail.*                                                  -/var/log/maillog
cron.*                                                  /var/log/cron
*.emerg                                                 *
uucp,news.crit                                          /var/log/spooler
local7.*                                                /var/log/boot.log
See the man page rsyslog.conf(5) for more information. Note that the rsyslog daemon can be configured to use a timestamp format that some log processing programs may not understand. If this occurs, edit the file /etc/rsyslog.conf and add or edit the following line: 
$ ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
 User who owns log files Specify user owner of all logfiles specified in /etc/rsyslog.conf. root group who owns log files Specify group owner of all logfiles specified in /etc/rsyslog.conf. root Ensure Log Files Are Owned By Appropriate User The owner of all log files written by rsyslog should be root. These log files are determined by the second part of each Rule line in /etc/rsyslog.conf and typically all appear in /var/log. For each log file LOGFILE referenced in /etc/rsyslog.conf, run the following command to inspect the file's owner: 
$ ls -l LOGFILE
If the owner is not root, run the following command to correct this: 
$ sudo chown root LOGFILE
 The owner of all log files written by rsyslog should be root. These log files are determined by the second part of each Rule line in /etc/rsyslog.conf and typically all appear in /var/log. To see the owner of a given log file, run the following command: 
$ ls -l LOGFILE
 The log files generated by rsyslog contain valuable information regarding system configuration, user authentication, and other such information. Log files should be protected from unauthorized access. Ensure Log Files Are Owned By Appropriate Group The group-owner of all log files written by rsyslog should be root. These log files are determined by the second part of each Rule line in /etc/rsyslog.conf and typically all appear in /var/log. For each log file LOGFILE referenced in /etc/rsyslog.conf, run the following command to inspect the file's group owner: 
$ ls -l LOGFILE
If the owner is not root, run the following command to correct this: 
$ sudo chgrp root LOGFILE
 The group-owner of all log files written by rsyslog should be root. These log files are determined by the second part of each Rule line in /etc/rsyslog.conf and typically all appear in /var/log. To see the group-owner of a given log file, run the following command: 
$ ls -l LOGFILE
 The log files generated by rsyslog contain valuable information regarding system configuration, user authentication, and other such information. Log files should be protected from unauthorized access. Ensure System Log Files Have Correct Permissions The file permissions for all log files written by rsyslog should be set to 600, or more restrictive. These log files are determined by the second part of each Rule line in /etc/rsyslog.conf and typically all appear in /var/log. For each log file LOGFILE referenced in /etc/rsyslog.conf, run the following command to inspect the file's permissions: 
$ ls -l LOGFILE
If the permissions are not 600 or more restrictive, run the following command to correct this: 
$ sudo chmod 0600 LOGFILE
 The file permissions for all log files written by rsyslog should be set to 600, or more restrictive. These log files are determined by the second part of each Rule line in /etc/rsyslog.conf and typically all appear in /var/log. To see the permissions of a given log file, run the following command: 
$ ls -l LOGFILE
The permissions should be 600, or more restrictive. Log files can contain valuable information regarding system configuration. If the system log files are not protected unauthorized users could change the logged data, eliminating their forensic value. Rsyslog Logs Sent To Remote Host If system logs are to be useful in detecting malicious activities, it is necessary to send logs to a remote server. An intruder who has compromised the root account on a machine may delete the log entries which indicate that the system was attacked before they are seen by an administrator.

However, it is recommended that logs be stored on the local host in addition to being sent to the loghost, especially if rsyslog has been configured to use the UDP protocol to send messages over a network. UDP does not guarantee reliable delivery, and moderately busy sites will lose log messages occasionally, especially in periods of high traffic which may be the result of an attack. In addition, remote rsyslog messages are not authenticated in any way by default, so it is easy for an attacker to introduce spurious messages to the central log server. Also, some problems cause loss of network connectivity, which will prevent the sending of messages to the central server. For all of these reasons, it is better to store log messages both centrally and on each host, so that they can be correlated if necessary. Ensure Logs Sent To Remote Host To configure rsyslog to send logs to a remote log server, open /etc/rsyslog.conf and read and understand the last section of the file, which describes the multiple directives necessary to activate remote logging. Along with these other directives, the system can be configured to forward its logs to a particular log server by adding or correcting one of the following lines, substituting loghost.example.com appropriately. The choice of protocol depends on the environment of the system; although TCP and RELP provide more reliable message delivery, they may not be supported in all environments.
To use UDP for log message delivery: 
*.* @loghost.example.com

To use TCP for log message delivery: 
*.* @@loghost.example.com

To use RELP for log message delivery: 
*.* :omrelp:loghost.example.com
 To ensure logs are sent to a remote host, examine the file /etc/rsyslog.conf. If using UDP, a line similar to the following should be present: 
 *.* @loghost.example.com
If using TCP, a line similar to the following should be present: 
 *.* @@loghost.example.com
If using RELP, a line similar to the following should be present: 
 *.* :omrelp:loghost.example.com
 A log server (loghost) receives syslog messages from one or more systems. This data can be used as an additional log source in the event a system is compromised and its local logs are suspect. Forwarding log messages to a remote loghost also provides system administrators with a centralized place to view the status of multiple hosts within the enterprise. Configure <tt>rsyslogd</tt> to Accept Remote Messages If Acting as a Log Server By default, rsyslog does not listen over the network for log messages. If needed, modules can be enabled to allow the rsyslog daemon to receive messages from other systems and for the system thus to act as a log server. If the machine is not a log server, then lines concerning these modules should remain commented out.

Ensure rsyslog Does Not Accept Remote Messages Unless Acting As Log Server The rsyslog daemon should not accept remote messages unless the system acts as a log server. To ensure that it is not listening on the network, ensure the following lines are not found in /etc/rsyslog.conf: 
$ModLoad imtcp
$InputTCPServerRun port
$ModLoad imudp
$UDPServerRun port
$ModLoad imrelp
$InputRELPServerRun port
 Any process which receives messages from the network incurs some risk of receiving malicious messages. This risk can be eliminated for rsyslog by configuring it not to listen on the network. Enable rsyslog to Accept Messages via TCP, if Acting As Log Server The rsyslog daemon should not accept remote messages unless the system acts as a log server. If the system needs to act as a central log server, add the following lines to /etc/rsyslog.conf to enable reception of messages over TCP: 
$ModLoad imtcp
$InputTCPServerRun 514
 If the system needs to act as a log server, this ensures that it can receive messages over a reliable TCP connection. Enable rsyslog to Accept Messages via UDP, if Acting As Log Server The rsyslog daemon should not accept remote messages unless the system acts as a log server. If the system needs to act as a central log server, add the following lines to /etc/rsyslog.conf to enable reception of messages over UDP: 
$ModLoad imudp
$UDPServerRun 514
 Many devices, such as switches, routers, and other Unix-like systems, may only support the traditional syslog transmission over UDP. If the system must act as a log server, this enables it to receive their messages as well. Ensure All Logs are Rotated by <tt>logrotate</tt> Edit the file /etc/logrotate.d/syslog. Find the first line, which should look like this (wrapped for clarity): 
/var/log/messages /var/log/secure /var/log/maillog /var/log/spooler \
  /var/log/boot.log /var/log/cron {
Edit this line so that it contains a one-space-separated listing of each log file referenced in /etc/rsyslog.conf.

All logs in use on a system must be rotated regularly, or the log files will consume disk space over time, eventually interfering with system operation. The file /etc/logrotate.d/syslog is the configuration file used by the logrotate program to maintain all log files written by syslog. By default, it rotates logs weekly and stores four archival copies of each log. These settings can be modified by editing /etc/logrotate.conf, but the defaults are sufficient for purposes of this guide.

Note that logrotate is run nightly by the cron job /etc/cron.daily/logrotate. If particularly active logs need to be rotated more often than once a day, some other mechanism must be used. Ensure Logrotate Runs Periodically The logrotate utility allows for the automatic rotation of log files. The frequency of rotation is specified in /etc/logrotate.conf, which triggers a cron task. To configure logrotate to run daily, add or correct the following line in /etc/logrotate.conf: 
# rotate log files frequency
daily
 Log files that are not properly rotated run the risk of growing so large that they fill up the /var/log partition. Valuable logging information could be lost if the /var/log partition becomes full. To determine the status and frequency of logrotate, run the following command: 
$ sudo grep logrotate /var/log/cron*
If logrotate is configured properly, output should include references to /etc/cron.daily. Configure Logwatch on the Central Log Server Is this machine the central log server? If so, edit the file /etc/logwatch/conf/logwatch.conf as shown below. Configure Logwatch HostLimit Line On a central logserver, you want Logwatch to summarize all syslog entries, including those which did not originate on the logserver itself. The HostLimit setting tells Logwatch to report on all hosts, not just the one on which it is running. 
 HostLimit = no
Configure Logwatch SplitHosts Line If SplitHosts is set, Logwatch will separate entries by hostname. This makes the report longer but significantly more usable. If it is not set, then Logwatch will not report which host generated a given log entry, and that information is almost always necessary 
 SplitHosts = yes
Disable Logwatch on Clients if a Logserver Exists Does your site have a central logserver which has been configured to report on logs received from all systems? If so: 
 
$ sudo rm /etc/cron.daily/0logwatch
If no logserver exists, it will be necessary for each machine to run Logwatch individually. Using a central logserver provides the security and reliability benefits discussed earlier, and also makes monitoring logs easier and less time-intensive for administrators. scap-security-guide-0.1.31/Fedora/input/xccdf/system/network/000077500000000000000000000000001301675746700241455ustar00rootroot00000000000000scap-security-guide-0.1.31/Fedora/input/xccdf/system/network/firewalld.xml000066400000000000000000000337761301675746700266600ustar00rootroot00000000000000 firewalld The dynamic firewall daemon firewalld provides a dynamically managed firewall with support for network “zones†to assign a level of trust to a network and its associated connections and interfaces. It has support for IPv4 and IPv6 firewall settings. It supports Ethernet bridges and has a separation of runtime and permanent configuration options. It also has an interface for services or applications to add firewall rules directly.
A graphical configuration tool, firewall-config, is used to configure firewalld, which in turn uses iptables tool to communicate with Netfilter in the kernel which implements packet filtering.
The firewall service provided by firewalld is dynamic rather than static because changes to the configuration can be made at anytime and are immediately implemented. There is no need to save or apply the changes. No unintended disruption of existing network connections occurs as no part of the firewall has to be reloaded. Inspect and Activate Default firewalld Rules Firewalls can be used to separate networks into different zones based on the level of trust the user has decided to place on the devices and traffic within that network. NetworkManager informs firewalld to which zone an interface belongs. An interface's assigned zone can be changed by NetworkManager or via the firewall-config tool.
The zone settings in /etc/firewalld/ are a range of preset settings which can be quickly applied to a network interface. These are the zones provided by firewalld sorted according to the default trust level of the zones from untrusted to trusted:
  • drop

    Any incoming network packets are dropped, there is no reply. Only outgoing network connections are possible.

  • block

    Any incoming network connections are rejected with an icmp-host-prohibited message for IPv4 and icmp6-adm-prohibited for IPv6. Only network connections initiated from within the system are possible.

  • public

    For use in public areas. You do not trust the other computers on the network to not harm your computer. Only selected incoming connections are accepted.

  • external

    For use on external networks with masquerading enabled especially for routers. You do not trust the other computers on the network to not harm your computer. Only selected incoming connections are accepted.

  • dmz

    For computers in your demilitarized zone that are publicly-accessible with limited access to your internal network. Only selected incoming connections are accepted.

  • work

    For use in work areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.

  • home

    For use in home areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.

  • internal

    For use on internal networks. You mostly trust the other computers on the networks to not harm your computer. Only selected incoming connections are accepted.

  • trusted

    All network connections are accepted.


It is possible to designate one of these zones to be the default zone. When interface connections are added to NetworkManager, they are assigned to the default zone. On installation, the default zone in firewalld is set to be the public zone.
To find out all the settings of a zone, for example the public zone, enter the following command as root: 
# firewall-cmd --zone=public --list-all
Example output of this command might look like the following: 
# firewall-cmd --zone=public --list-all
public
  interfaces:
  services: mdns dhcpv6-client ssh
  ports:
  forward-ports:
  icmp-blocks: source-quench
To view the network zones currently active, enter the following command as root: 
# firewall-cmd --get-service
The following listing displays the result of this command on common Fedora Server system: 
# firewall-cmd --get-service
amanda-client amanda-k5-client bacula bacula-client cockpit dhcp dhcpv6
dhcpv6-client dns dropbox-lansync freeipa-ldap freeipa-ldaps
freeipa-replication ftp high-availability http https imaps ipp ipp-client ipsec
iscsi-target kadmin kerberos kpasswd ldap ldaps libvirt libvirt-tls mdns mosh
mountd ms-wbt mysql nfs ntp openvpn pmcd pmproxy pmwebapi pmwebapis pop3s
postgresql privoxy proxy-dhcp ptp puppetmaster radius rpc-bind rsyncd samba
samba-client sane smtp squid ssh synergy telnet tftp tftp-client tinc tor-socks
transmission-client vdsm vnc-server wbem-https xmpp-bosh xmpp-client xmpp-local
xmpp-server
Finally to view the network zones that will be active after the next firewalld service reload, enter the following command as root: 
# firewall-cmd --get-service --permanent
 Verify firewalld Enabled The dynamic firewall daemon firewalld provides a dynamically managed firewall with support for network “zonesâ€, Ethernet bridges, and has a separation of runtime and permanent configuration options. It has support for both IPv4 and IPv6 firewall settings. Strengthen the Default Ruleset The default rules can be strengthened. The system scripts that activate the firewall rules expect them to be defined in configuration files under the /etc/firewalld/services and /etc/firewalld/zones directories.

The following recommendations describe how to strengthen the default ruleset configuration file. An alternative to editing this configuration file is to create a shell script that makes calls to the firewall-cmd program to load in rules under the /etc/firewalld/services and /etc/firewalld/zones directories.

Instructions apply to both unless otherwise noted. Language and address conventions for regular firewalld rules are used throughout this section. The program firewall-config allows additional services to penetrate the default firewall rules and automatically adjusts the firewalld ruleset(s). Set Default firewalld Zone for Incoming Packets To set the default zone to drop for the built-in default zone which processes incoming IPv4 and IPv6 packets, modify the following line in /etc/firewalld/firewalld.conf to be: 
DefaultZone=drop
 Inspect the file /etc/firewalld/firewalld.conf to determine the default zone for the firewalld. It should be set to DefaultZone=drop: 
$ sudo grep DefaultZone /etc/firewalld/firewalld.conf
 In firewalld the default zone is applied only after all the applicable rules in the table are examined for a match. Setting the default zone to drop implements proper design for a firewall, i.e. any packets which are not explicitly permitted should not be accepted. scap-security-guide-0.1.31/Fedora/input/xccdf/system/network/ipsec.xml000066400000000000000000000035471301675746700260030ustar00rootroot00000000000000 IPSec Support Support for Internet Protocol Security (IPsec) is provided in Fedora with Libreswan. Install libreswan Package The Libreswan package provides an implementation of IPsec and IKE, which permits the creation of secure tunnels over untrusted networks. Providing the ability for remote users or systems to initiate a secure VPN connection protects information when it is transmitted over a wide area network. Verify Any Configured IPSec Tunnel Connections Libreswan provides an implementation of IPsec and IKE, which permits the creation of secure tunnels over untrusted networks. As such, IPsec can be used to circumvent certain network requirements such as filtering. Verify that if any IPsec connection (conn) configured in /etc/ipsec.conf and /etc/ipsec.d exists is an approved organizational connection. To check for configured IPsec connections (conn), perform the following: 
grep -rni conn /etc/ipsec.conf /etc/ipsec.d/
Verify any returned results for organizational approval. IP tunneling mechanisms can be used to bypass network filtering. scap-security-guide-0.1.31/Fedora/input/xccdf/system/network/ipv6.xml000066400000000000000000000233151301675746700255570ustar00rootroot00000000000000 IPv6 The system includes support for Internet Protocol version 6. A major and often-mentioned improvement over IPv4 is its enormous increase in the number of available addresses. Another important feature is its support for automatic configuration of many network settings. Disable Support for IPv6 Unless Needed Despite configuration that suggests support for IPv6 has been disabled, link-local IPv6 address auto-configuration occurs even when only an IPv4 address is assigned. The only way to effectively prevent execution of the IPv6 networking stack is to instruct the system not to activate the IPv6 kernel module. Disable IPv6 Networking Support Automatic Loading To disable support for (ipv6) add the following line to /etc/sysctl.d/ipv6.conf (or another file in /etc/sysctl.d): 
net.ipv6.conf.all.disable_ipv6 = 1
This disables IPv6 on all network interfaces as other services and system functionality require the IPv6 stack loaded to work. If the system uses IPv6, this is not applicable.

If the system is configured to prevent the usage of the ipv6 on network interfaces, it will contain a line of the form: 
net.ipv6.conf.all.disable_ipv6 = 1
Such lines may be inside any file in the /etc/sysctl.d directory. This permits insertion of the IPv6 kernel module (which other parts of the system expect to be present), but otherwise keeps all network interfaces from using IPv6. Run the following command to search for such lines in all files in /etc/sysctl.d: 
$ grep -r ipv6 /etc/sysctl.d
 Any unnecessary network stacks - including IPv6 - should be disabled, to reduce the vulnerability to exploitation. Disable Interface Usage of IPv6 To disable interface usage of IPv6, add or correct the following lines in /etc/sysconfig/network: 
NETWORKING_IPV6=no
IPV6INIT=no
 Disable Support for RPC IPv6 RPC services for NFSv4 try to load transport modules for udp6 and tcp6 by default, even if IPv6 has been disabled in /etc/modprobe.d. To prevent RPC services such as rpc.mountd from attempting to start IPv6 network listeners, remove or comment out the following two lines in /etc/netconfig: 
udp6       tpi_clts      v     inet6    udp     -       -
tcp6       tpi_cots_ord  v     inet6    tcp     -       -
 Configure IPv6 Settings if Necessary A major feature of IPv6 is the extent to which systems implementing it can automatically configure their networking devices using information from the network. From a security perspective, manually configuring important configuration information is preferable to accepting it from the network in an unauthenticated fashion. Disable Automatic Configuration Disable the system's acceptance of router advertisements and redirects by adding or correcting the following line in /etc/sysconfig/network (note that this does not disable sending router solicitations): 
IPV6_AUTOCONF=no
 IPV6_AUTOCONF Toggle global IPv6 auto-configuration (only, if global forwarding is disabled) no yes no net.ipv6.conf.default.accept_ra Accept default router advertisements? 0 1 0 net.ipv6.conf.default.accept_redirects Toggle ICMP Redirect Acceptance 0 1 0 Disable Accepting IPv6 Router Advertisements An illicit router advertisement message could result in a man-in-the-middle attack. Disable Accepting IPv6 Redirects An illicit ICMP redirect message could result in a man-in-the-middle attack. Manually Assign Global IPv6 Address To manually assign an IP address for an interface, edit the file /etc/sysconfig/network-scripts/ifcfg-interface. Add or correct the following line (substituting the correct IPv6 address): 
IPV6ADDR=2001:0DB8::ABCD/64
Manually assigning an IP address is preferable to accepting one from routers or from the network otherwise. The example address here is an IPv6 address reserved for documentation purposes, as defined by RFC3849. Use Privacy Extensions for Address To introduce randomness into the automatic generation of IPv6 addresses, add or correct the following line in /etc/sysconfig/network-scripts/ifcfg-interface: 
IPV6_PRIVACY=rfc3041
Automatically-generated IPv6 addresses are based on the underlying hardware (e.g. Ethernet) address, and so it becomes possible to track a piece of hardware over its lifetime using its traffic. If it is important for a system's IP address to not trivially reveal its hardware address, this setting should be applied. Manually Assign IPv6 Router Address Edit the file /etc/sysconfig/network-scripts/ifcfg-interface, and add or correct the following line (substituting your gateway IP as appropriate): 
IPV6_DEFAULTGW=2001:0DB8::0001
Router addresses should be manually set and not accepted via any auto-configuration or router advertisement. Limit Network-Transmitted Configuration if Using Static IPv6 Addresses To limit the configuration information requested from other systems and accepted from the network on a system that uses statically-configured IPv6 addresses, add the following lines to /etc/sysctl.conf: 
net.ipv6.conf.default.router_solicitations = 0
net.ipv6.conf.default.accept_ra_rtr_pref = 0
net.ipv6.conf.default.accept_ra_pinfo = 0
net.ipv6.conf.default.accept_ra_defrtr = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.default.dad_transmits = 0
net.ipv6.conf.default.max_addresses = 1
The router_solicitations setting determines how many router solicitations are sent when bringing up the interface. If addresses are statically assigned, there is no need to send any solicitations.

The accept_ra_pinfo setting controls whether the system will accept prefix info from the router.

The accept_ra_defrtr setting controls whether the system will accept Hop Limit settings from a router advertisement. Setting it to 0 prevents a router from changing your default IPv6 Hop Limit for outgoing packets.

The autoconf setting controls whether router advertisements can cause the system to assign a global unicast address to an interface.

The dad_transmits setting determines how many neighbor solicitations to send out per address (global and link-local) when bringing up an interface to ensure the desired address is unique on the network.

The max_addresses setting determines how many global unicast IPv6 addresses can be assigned to each interface. The default is 16, but it should be set to exactly the number of statically configured global addresses required. scap-security-guide-0.1.31/Fedora/input/xccdf/system/network/kernel.xml000066400000000000000000000457121301675746700261600ustar00rootroot00000000000000 Kernel Parameters Which Affect Networking The sysctl utility is used to set parameters which affect the operation of the Linux kernel. Kernel parameters which affect networking and have security implications are described here. Network Parameters for Hosts Only If the system is not going to be used as a router, then setting certain kernel parameters ensure that the host will not perform routing of network traffic. Disable Kernel Parameter for Sending ICMP Redirects by Default ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages contain information from the system's route table possibly revealing portions of the network topology.
The ability to send ICMP redirects is only appropriate for systems acting as routers. Disable Kernel Parameter for Sending ICMP Redirects for All Interfaces ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages contain information from the system's route table possibly revealing portions of the network topology.
The ability to send ICMP redirects is only appropriate for systems acting as routers. Disable Kernel Parameter for IP Forwarding The ability to forward packets is only appropriate for routers. IP forwarding permits the kernel to forward packets from one network interface to another. The ability to forward packets between two networks is only appropriate for systems acting as routers. Network Related Kernel Runtime Parameters for Hosts and Routers Certain kernel parameters should be set for systems which are acting as either hosts or routers to improve the system's ability defend against certain types of IPv4 protocol attacks. net.ipv4.conf.all.accept_source_route Trackers could be using source-routed packets to generate traffic that seems to be intra-net, but actually was created outside and has been redirected. 0 1 0 net.ipv4.conf.all.accept_redirects Disable ICMP Redirect Acceptance 0 1 0 net.ipv4.conf.all.secure_redirects Enable to prevent hijacking of routing path by only allowing redirects from gateways known in routing table. 1 1 0 net.ipv4.conf.default.log_martians Disable so you don't Log Spoofed Packets, Source Routed Packets, Redirect Packets 1 1 0 net.ipv4.conf.all.log_martians Disable so you don't Log Spoofed Packets, Source Routed Packets, Redirect Packets 1 1 0 net.ipv4.conf.default.accept_source_route Disable IP source routing? 0 1 0 net.ipv4.conf.default.accept_redirects Disable ICMP Redirect Acceptance? 0 1 0 net.ipv4.conf.default.secure_redirects Log packets with impossible addresses to kernel log? 1 1 0 net.ipv4.icmp_echo_ignore_broadcasts Ignore all ICMP ECHO and TIMESTAMP requests sent to it via broadcast/multicast 1 1 0 net.ipv4.icmp_ignore_bogus_error_responses Enable to prevent unnecessary logging 1 1 0 net.ipv4.tcp_syncookies Enable to turn on TCP SYN Cookie Protection 1 1 0 net.ipv4.conf.all.rp_filter Enable to enforce sanity checking, also called ingress filtering or egress filtering. The point is to drop a packet if the source and destination IP addresses in the IP header do not make sense when considered in light of the physical interface on which it arrived. 1 1 0 net.ipv4.conf.default.rp_filter Enables source route verification 1 1 0 Configure Kernel Parameter for Accepting Source-Routed Packets for All Interfaces Source-routed packets allow the source of the packet to suggest routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routerd traffic, such as when IPv4 forwarding is enabled and the system is functioning as a router. Accepting source-routed packets in the IPv4 protocol has few legitimate uses. It should be disabled unless it is absolutely required. Configure Kernel Parameter for Accepting ICMP Redirects for All Interfaces ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack.
This feature of the IPv4 protocol has few legitimate uses. It should be disabled unless absolutely required. Configure Kernel Parameter for Accepting Secure Redirects for All Interfaces Accepting "secure" ICMP redirects (from those gateways listed as default gateways) has few legitimate uses. It should be disabled unless it is absolutely required. Configure Kernel Parameter to Log Martian Packets The presence of "martian" packets (which have impossible addresses) as well as spoofed packets, source-routed packets, and redirects could be a sign of nefarious network activity. Logging these packets enables this activity to be detected. Configure Kernel Parameter to Log Martian Packets By Default The presence of "martian" packets (which have impossible addresses) as well as spoofed packets, source-routed packets, and redirects could be a sign of nefarious network activity. Logging these packets enables this activity to be detected. Configure Kernel Parameter for Accepting Source-Routed Packets By Default Source-routed packates allow the source of the packet to suggest routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures.
Accepting source-routed packets in the IPv4 protocol has few legitimate uses. It should be disabled unless it is absolutely required, such as when IPv4 forwarding is enabled and the system is legitimately functioning as a router. Configure Kernel Parameter for Accepting ICMP Redirects By Default ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack.
This feature of the IPv4 protocol has few legitimate uses. It should be disabled unless absolutely required. Configure Kernel Parameter for Accepting Secure Redirects By Default Accepting "secure" ICMP redirects (from those gateways listed as default gateways) has few legitimate uses. It should be disabled unless it is absolutely required. Configure Kernel Parameter to Ignore ICMP Broadcast Echo Requests Responding to broadcast (ICMP) echoes facilitates network mapping and provides a vector for amplification attacks.
Ignoring ICMP echo requests (pings) sent to broadcast or multicast addresses makes the system slightly more difficult to enumerate on the network. Configure Kernel Parameter to Ignore Bogus ICMP Error Responses Ignoring bogus ICMP error responses reduces log size, although some activity would not be logged. Configure Kernel Parameter to Use TCP Syncookies A TCP SYN flood attack can cause a denial of service by filling a system's TCP connection table with connections in the SYN_RCVD state. Syncookies can be used to track a connection when a subsequent ACK is received, verifying the initiator is attempting a valid connection and is not a flood source. This feature is activated when a flood condition is detected, and enables the system to continue servicing valid connection requests. Configure Kernel Parameter to Use Reverse Path Filtering for All Interfaces Enabling reverse path filtering drops packets with source addresses that should not have been able to be received on the interface they were received on. It should not be used on systems which are routers for complicated networks, but is helpful for end hosts and routers serving small networks. Configure Kernel Parameter to Use Reverse Path Filtering by Default Enabling reverse path filtering drops packets with source addresses that should not have been able to be received on the interface they were received on. It should not be used on systems which are routers for complicated networks, but is helpful for end hosts and routers serving small networks. scap-security-guide-0.1.31/Fedora/input/xccdf/system/network/network.xml000066400000000000000000000060651301675746700263670ustar00rootroot00000000000000 Network Configuration and Firewalls Most machines must be connected to a network of some sort, and this brings with it the substantial risk of network attack. This section discusses the security impact of decisions about networking which must be made when configuring a system.

This section also discusses firewalls, network access controls, and other network security frameworks, which allow system-level rules to be written that can limit an attackers' ability to connect to your system. These rules can specify that network traffic should be allowed or denied from certain IP addresses, hosts, and networks. The rules can also specify which of the system's network services are available to particular hosts or networks. Disable Unused Interfaces Network interfaces expand the attack surface of the system. Unused interfaces are not monitored or controlled, and should be disabled.

If the system does not require network communications but still needs to use the loopback interface, remove all files of the form ifcfg-interface except for ifcfg-lo from /etc/sysconfig/network-scripts: 
$ sudo rm /etc/sysconfig/network-scripts/ifcfg-interface
If the system is a standalone machine with no need for network access or even communication over the loopback device, then disable this service. Disable Zeroconf Networking Zeroconf networking allows the system to assign itself an IP address and engage in IP communication without a statically-assigned address or even a DHCP server. Automatic address assignment via Zeroconf (or DHCP) is not recommended. To disable Zeroconf automatic route assignment in the 169.254.0.0 subnet, add or correct the following line in /etc/sysconfig/network: 
NOZEROCONF=yes
 Zeroconf addresses are in the network 169.254.0.0. The networking scripts add entries to the system's routing table for these addresses. Zeroconf address assignment commonly occurs when the system is configured to use DHCP but fails to receive an address assignment from the DHCP server. Ensure System is Not Acting as a Network Sniffer The system should not be acting as a network sniffer, which can capture all traffic on the network to which it is connected. Run the following to determine if any interface is running in promiscuous mode: 
$ ip link | grep PROMISC
 If any results are returned, then a sniffing process (such as tcpdump or Wireshark) is likely to be using the interface and this should be investigated. scap-security-guide-0.1.31/Fedora/input/xccdf/system/network/ssl.xml000066400000000000000000000011321301675746700254650ustar00rootroot00000000000000 Transport Layer Security Support Support for Transport Layer Security (TLS), and its predecessor, the Secure Sockets Layer (SSL), is included in Fedora in the OpenSSL software (RPM package openssl). TLS provides encrypted and authenticated network communications, and many network services include support for it. TLS or SSL can be leveraged to avoid any plaintext transmission of sensitive data.
For information on how to use OpenSSL, see . scap-security-guide-0.1.31/Fedora/input/xccdf/system/network/uncommon.xml000066400000000000000000000057441301675746700265340ustar00rootroot00000000000000 Uncommon Network Protocols The system includes support for several network protocols which are not commonly used. Although security vulnerabilities in kernel networking code are not frequently discovered, the consequences can be dramatic. Ensuring uncommon network protocols are disabled reduces the system's risk to attacks targeted at its implementation of those protocols. Although these protocols are not commonly used, avoid disruption in your network environment by ensuring they are not needed prior to disabling them. Disable DCCP Support The Datagram Congestion Control Protocol (DCCP) is a relatively new transport layer protocol, designed to support streaming media and telephony. Disabling DCCP protects the system against exploitation of any flaws in its implementation. scap-security-guide-0.1.31/Fedora/input/xccdf/system/network/wireless.xml000066400000000000000000000113631301675746700265300ustar00rootroot00000000000000 Wireless Networking Wireless networking, such as 802.11 (WiFi) and Bluetooth, can present a security risk to sensitive or classified systems and networks. Wireless networking hardware is much more likely to be included in laptop or portable systems than in desktops or servers.

Removal of hardware provides the greatest assurance that the wireless capability remains disabled. Acquisition policies often include provisions to prevent the purchase of equipment that will be used in sensitive spaces and includes wireless capabilities. If it is impractical to remove the wireless hardware, and policy permits the device to enter sensitive spaces as long as wireless is disabled, efforts should instead focus on disabling wireless capability via software. Disable Wireless Through Software Configuration If it is impossible to remove the wireless hardware from the device in question, disable as much of it as possible through software. The following methods can disable software support for wireless networking, but note that these methods do not prevent malicious software or careless users from re-activating the devices. Disable WiFi or Bluetooth in BIOS Some systems that include built-in wireless support offer the ability to disable the device through the BIOS. This is system-specific; consult your hardware manual or explore the BIOS setup during boot. Disabling wireless support in the BIOS prevents easy activation of the wireless interface, generally requiring administrators to reboot the system first. Deactivate Wireless Network Interfaces Deactivating wireless network interfaces should prevent normal usage of the wireless capability.

First, identify the interfaces available with the command: 
$ ifconfig -a
Additionally, the following command may be used to determine whether wireless support is included for a particular interface, though this may not always be a clear indicator: 
$ iwconfig
After identifying any wireless interfaces (which may have names like wlan0, ath0, wifi0, em1 or eth0), deactivate the interface with the command: 
$ sudo ifdown interface
These changes will only last until the next reboot. To disable the interface for future boots, remove the appropriate interface file from /etc/sysconfig/network-scripts: 
$ sudo rm /etc/sysconfig/network-scripts/ifcfg-interface
 Wireless networking allows attackers within physical proximity to launch network-based attacks against systems, including those against local LAN protocols which were not designed with security in mind. Disable Bluetooth Service 
$ sudo service bluetooth stop
 Disabling the bluetooth service prevents the system from attempting connections to Bluetooth devices, which entails some security risk. Nevertheless, variation in this risk decision may be expected due to the utility of Bluetooth connectivity and its limited range. Disable Bluetooth Kernel Modules The kernel's module loading system can be configured to prevent loading of the Bluetooth module. Add the following to the appropriate /etc/modprobe.d configuration file to prevent the loading of the Bluetooth module: 
install bluetooth /bin/true
 If Bluetooth functionality must be disabled, preventing the kernel from loading the kernel module provides an additional safeguard against its activation. scap-security-guide-0.1.31/Fedora/input/xccdf/system/permissions/000077500000000000000000000000001301675746700250275ustar00rootroot00000000000000scap-security-guide-0.1.31/Fedora/input/xccdf/system/permissions/execution.xml000066400000000000000000000253571301675746700275700ustar00rootroot00000000000000 Restrict Programs from Dangerous Execution Patterns The recommendations in this section are designed to ensure that the system's features to protect against potentially dangerous program execution are activated. These protections are applied at the system initialization or kernel level, and defend against certain types of badly-configured or compromised programs. Daemon Umask The umask is a per-process setting which limits the default permissions for creation of new files and directories. The system includes initialization scripts which set the default umask for system daemons. daemon umask Enter umask for daemons 022 022 027 Set Daemon Umask The file /etc/init.d/functions includes initialization parameters for most or all daemons started at boot time. The default umask of 022 prevents creation of group- or world-writable files. To set the default umask for daemons, edit the following line, inserting 022 or 027 for UMASK appropriately: 
umask
Setting the umask to too restrictive a setting can cause serious errors at runtime. Many daemons on the system already individually restrict themselves to a umask of 077 in their own init scripts. To check the value of the umask, run the following command: 
$ grep umask /etc/init.d/functions
The output should show either 022 or 027. The umask influences the permissions assigned to files created by a process at run time. An unnecessarily permissive umask could result in files being created with insecure permissions. Disable Core Dumps A core dump file is the memory image of an executable program when it was terminated by the operating system due to errant behavior. In most cases, only software developers legitimately need to access these files. The core dump files may also contain sensitive information, or unnecessarily occupy large amounts of disk space.

Once a hard limit is set in /etc/security/limits.conf, a user cannot increase that limit within his or her own session. If access to core dumps is required, consider restricting them to only certain users or groups. See the limits.conf man page for more information.

The core dumps of setuid programs are further protected. The sysctl variable fs.suid_dumpable controls whether the kernel allows core dumps from these programs at all. The default value of 0 is recommended. Disable Core Dumps for All Users To disable core dumps for all users, add the following line to /etc/security/limits.conf: 
*     hard   core    0
 To verify that core dumps are disabled for all users, run the following command: 
$ grep core /etc/security/limits.conf
The output should be: 
*     hard   core    0
 A core dump includes a memory image taken at the time the operating system terminates an application. The memory image could contain sensitive data and is generally useful only for developers trying to debug problems. Disable Core Dumps for SUID programs The core dump of a setuid program is more likely to contain sensitive data, as the program itself runs with greater privileges than the user who initiated execution of the program. Disabling the ability for any setuid program to write a core file decreases the risk of unauthorized access of such data. Enable ExecShield ExecShield describes kernel features that provide protection against exploitation of memory corruption errors such as buffer overflows. These features include random placement of the stack and other memory regions, prevention of execution in memory that should only hold data, and special handling of text buffers. These protections are enabled by default on 32-bit systems and controlled through sysctl variables kernel.exec-shield and kernel.randomize_va_space. On the latest 64-bit systems, kernel.exec-shield cannot be enabled or disabled with sysctl. Enable ExecShield By default on Fedora 64-bit systems, ExecShield is enabled and can only be disabled if the hardware does not support ExecShield or is disabled in /etc/default/grub. For Fedora 32-bit systems, sysctl can be used to enable ExecShield. To verify ExecShield is enabled on 64-bit Fedora systems, run the following command: 
$ dmesg | grep '[NX|DX]*protection'
The output should not contain 'disabled by kernel command line option'. To verify that ExecShield has not been disabled in the kernel configuration, run the following command: 
$ sudo grep noexec /boot/grub2/grub.cfg
The output should not return noexec=off. For 32-bit Fedora systems, run the following command: 
$ sysctl kernel.exec-shield
The output should be:
ExecShield uses the segmentation feature on all x86 systems to prevent execution in memory higher than a certain address. It writes an address as a limit in the code segment descriptor, to control where code can be executed, on a per-process basis. When the kernel places a process's memory regions such as the stack and heap higher than this address, the hardware prevents execution in that address range. This is enabled by default on the latest Red Hat and Fedora systems if supported by the hardware. Enable Randomized Layout of Virtual Address Space Address space layout randomization (ASLR) makes it more difficult for an attacker to predict the location of attack code they have introduced into a process's address space during an attempt at exploitation. Additionally, ASLR makes it more difficult for an attacker to know the location of existing code in order to re-purpose it using return oriented programming (ROP) techniques. Enable Execute Disable (XD) or No Execute (NX) Support on x86 Systems Recent processors in the x86 family support the ability to prevent code execution on a per memory page basis. Generically and on AMD processors, this ability is called No Execute (NX), while on Intel processors it is called Execute Disable (XD). This ability can help prevent exploitation of buffer overflow vulnerabilities and should be activated whenever possible. Extra steps must be taken to ensure that this protection is enabled, particularly on 32-bit x86 systems. Other processors, such as Itanium and POWER, have included such support since inception and the standard kernel for those platforms supports the feature. This is enabled by default on the latest Red Hat and Fedora systems if supported by the hardware. Install PAE Kernel on Supported 32-bit x86 Systems Systems that are using the 64-bit x86 kernel package do not need to install the kernel-PAE package because the 64-bit x86 kernel already includes this support. However, if the system is 32-bit and also supports the PAE and NX features as determined in the previous section, the kernel-PAE package should be installed to enable XD or NX support: 
$ sudo dnf install kernel-PAE
The installation process should also have configured the bootloader to load the new kernel at boot. Verify this at reboot and modify /etc/default/grub if necessary. The kernel-PAE package should not be installed on older systems that do not support the XD or NX bit, as this may prevent them from booting. On 32-bit systems that support the XD or NX bit, the vendor-supplied PAE kernel is required to enable either Execute Disable (XD) or No Execute (NX) support. Enable NX or XD Support in the BIOS Reboot the system and enter the BIOS or Setup configuration menu. Navigate the BIOS configuration menu and make sure that the option is enabled. The setting may be located under a Security section. Look for Execute Disable (XD) on Intel-based systems and No Execute (NX) on AMD-based systems. Computers with the ability to prevent this type of code execution frequently put an option in the BIOS that will allow users to turn the feature on or off at will. Restrict Access to Kernel Message Buffer Unprivileged access to the kernel syslog can expose sensitive kernel address information. scap-security-guide-0.1.31/Fedora/input/xccdf/system/permissions/files.xml000066400000000000000000000532361301675746700266640ustar00rootroot00000000000000 Verify Permissions on Important Files and Directories Permissions for many files on a system must be set restrictively to ensure sensitive information is properly protected. This section discusses important permission restrictions which can be verified to ensure that no harmful discrepancies have arisen. Verify Permissions on Files with Local Account Information and Credentials The default restrictive permissions for files which act as important security databases such as passwd, shadow, group, and gshadow files must be maintained. Many utilities need read access to the passwd file in order to function properly, but read access to the shadow file allows malicious attacks against system passwords, and should never be enabled. Verify User Who Owns <tt>shadow</tt> File The /etc/shadow file contains the list of local system accounts and stores password hashes. Protection of this file is critical for system security. Failure to give ownership of this file to root provides the designated owner with access to sensitive information which could weaken the system security posture. Verify Group Who Owns <tt>shadow</tt> File The /etc/shadow file stores password hashes. Protection of this file is critical for system security. Verify Permissions on <tt>shadow</tt> File The /etc/shadow file contains the list of local system accounts and stores password hashes. Protection of this file is critical for system security. Failure to give ownership of this file to root provides the designated owner with access to sensitive information which could weaken the system security posture. Verify User Who Owns <tt>group</tt> File The /etc/group file contains information regarding groups that are configured on the system. Protection of this file is important for system security. Verify Group Who Owns <tt>group</tt> File The /etc/group file contains information regarding groups that are configured on the system. Protection of this file is important for system security. Verify Permissions on <tt>group</tt> File The /etc/group file contains information regarding groups that are configured on the system. Protection of this file is important for system security. Verify User Who Owns <tt>gshadow</tt> File The /etc/gshadow file contains group password hashes. Protection of this file is critical for system security. Verify Group Who Owns <tt>gshadow</tt> File The /etc/gshadow file contains group password hashes. Protection of this file is critical for system security. Verify Permissions on <tt>gshadow</tt> File The /etc/gshadow file contains group password hashes. Protection of this file is critical for system security. Verify User Who Owns <tt>passwd</tt> File The /etc/passwd file contains information about the users that are configured on the system. Protection of this file is critical for system security. Verify Group Who Owns <tt>passwd</tt> File The /etc/passwd file contains information about the users that are configured on the system. Protection of this file is critical for system security. Verify Permissions on <tt>passwd</tt> File If the /etc/passwd file is writable by a group-owner or the world the risk of its compromise is increased. The file contains the list of accounts on the system and associated information, and protection of this file is critical for system security. Verify File Permissions Within Some Important Directories Some directories contain files whose confidentiality or integrity is notably important and may also be susceptible to misconfiguration over time, particularly if unpackaged software is installed. As such, an argument exists to verify that files' permissions within these directories remain configured correctly and restrictively. Verify that Shared Library Files Have Restrictive Permissions System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default: 
/lib
/lib64
/usr/lib
/usr/lib64
Kernel modules, which can be added to the kernel during runtime, are stored in /lib/modules. All files in these directories should not be group-writable or world-writable. If any file in these directories is found to be group-writable or world-writable, correct its permission with the following command: 
$ sudo chmod go-w FILE
 Shared libraries are stored in the following directories: 
/lib
/lib64
/usr/lib
/usr/lib64
To find shared libraries that are group-writable or world-writable, run the following command for each directory DIR which contains shared libraries: 
$ sudo find -L DIR -perm /022 -type f
 Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Restrictive permissions are necessary to protect the integrity of the system. Verify that Shared Library Files Have Root Ownership System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default: 
/lib
/lib64
/usr/lib
/usr/lib64
Kernel modules, which can be added to the kernel during runtime, are also stored in /lib/modules. All files in these directories should be owned by the root user. If the directory, or any file in these directories, is found to be owned by a user other than root correct its ownership with the following command: 
$ sudo chown root FILE
 Shared libraries are stored in the following directories: 
/lib
/lib64
/usr/lib
/usr/lib64
For each of these directories, run the following command to find files not owned by root: 
$ sudo find -L $DIR \! -user root -exec chown root {} \;
 Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Proper ownership is necessary to protect the integrity of the system. Verify that System Executables Have Restrictive Permissions System executables are stored in the following directories by default: 
/bin
/sbin
/usr/bin
/usr/libexec
/usr/local/bin
/usr/local/sbin
/usr/sbin
All files in these directories should not be group-writable or world-writable. If any file FILE in these directories is found to be group-writable or world-writable, correct its permission with the following command: 
$ sudo chmod go-w FILE
 System executables are stored in the following directories by default: 
/bin
/sbin
/usr/bin
/usr/libexec
/usr/local/bin
/usr/local/sbin
/usr/sbin
To find system executables that are group-writable or world-writable, run the following command for each directory DIR which contains system executables: 
$ sudo find -L DIR -perm /022 -type f
 System binaries are executed by privileged users, as well as system services, and restrictive permissions are necessary to ensure execution of these programs cannot be co-opted. Verify that System Executables Have Root Ownership System executables are stored in the following directories by default: 
/bin
/sbin
/usr/bin
/usr/libexec
/usr/local/bin
/usr/local/sbin
/usr/sbin
All files in these directories should be owned by the root user. If any file FILE in these directories is found to be owned by a user other than root, correct its ownership with the following command: 
$ sudo chown root FILE
 System executables are stored in the following directories by default: 
/bin
/sbin
/usr/bin
/usr/libexec
/usr/local/bin
/usr/local/sbin
/usr/sbin
To find system executables that are not owned by root, run the following command for each directory DIR which contains system executables: 
$ sudo find DIR/ \! -user root
 System binaries are executed by privileged users as well as system services, and restrictive permissions are necessary to ensure that their execution of these programs cannot be co-opted. Verify that All World-Writable Directories Have Sticky Bits Set When the so-called 'sticky bit' is set on a directory, only the owner of a given file may remove that file from the directory. Without the sticky bit, any user with write access to a directory may remove any file in the directory. Setting the sticky bit prevents users from removing each other's files. In cases where there is no reason for a directory to be world-writable, a better solution is to remove that permission rather than to set the sticky bit. However, if a directory is used by a particular application, consult that application's documentation instead of blindly changing modes.
To set the sticky bit on a world-writable directory DIR, run the following command: 
$ sudo chmod +t DIR
 To find world-writable directories that lack the sticky bit, run the following command: 
$ sudo find / -xdev -type d -perm 002 ! -perm 1000
 Failing to set the sticky bit on public directories allows unauthorized users to delete files in the directory structure.

The only authorized public directories are those temporary directories supplied with the system, or those designed to be temporary file repositories. The setting is normally reserved for directories used by the system, by users for temporary file storage (such as /tmp), and for directories requiring global read/write access. Ensure No World-Writable Files Exist It is generally a good idea to remove global (other) write access to a file when it is discovered. However, check with documentation for specific applications before making changes. Also, monitor for recurring world-writable files, as these may be symptoms of a misconfigured application or user account. To find world-writable files, run the following command: 
$ sudo find / -xdev -type f -perm -002
 Data in world-writable files can be modified by any user on the system. In almost all circumstances, files can be configured using a combination of user and group permissions to support whatever legitimate access is needed without the risk caused by world-writable files. Ensure All SGID Executables Are Authorized The SGID (set group id) bit should be set only on files that were installed via authorized means. A straightforward means of identifying unauthorized SGID files is determine if any were not installed as part of an RPM package, which is cryptographically verified. Investigate the origin of any unpackaged SGID files. To find world-writable files, run the following command: 
$ sudo find / -xdev -type f -perm -002
 Executable files with the SGID permission run with the privileges of the owner of the file. SGID files of uncertain provenance could allow for unprivileged users to elevate privileges. The presence of these files should be strictly controlled on the system. Ensure All SUID Executables Are Authorized The SUID (set user id) bit should be set only on files that were installed via authorized means. A straightforward means of identifying unauthorized SGID files is determine if any were not installed as part of an RPM package, which is cryptographically verified. Investigate the origin of any unpackaged SUID files. To find world-writable files, run the following command: 
$ sudo find / -xdev -type f -perm -002
 Executable files with the SUID permission run with the privileges of the owner of the file. SUID files of uncertain provenance could allow for unprivileged users to elevate privileges. The presence of these files should be strictly controlled on the system. Ensure All Files Are Owned by a User If any files are not owned by a user, then the cause of their lack of ownership should be investigated. Following this, the files should be deleted or assigned to an appropriate user. The following command will discover and print any files on local partitions which do not belong to a valid user. Run it once for each local partition PART: 
$ sudo find PART -xdev -nouser -print
 Unowned files do not directly imply a security problem, but they are generally a sign that something is amiss. They may be caused by an intruder, by incorrect software installation or draft software removal, or by failure to remove all files belonging to a deleted account. The files should be repaired so they will not cause problems when accounts are created in the future, and the cause should be discovered and addressed. Ensure All Files Are Owned by a Group If any files are not owned by a group, then the cause of their lack of group-ownership should be investigated. Following this, the files should be deleted or assigned to an appropriate group. The following command will discover and print any files on local partitions which do not belong to a valid group. Run it once for each local partition PART: 
$ sudo find PART -xdev -nogroup -print

Either remove all files and directories from the system that do not have a valid group, or assign a valid group with the chgrp command: 
$ sudo chgrp group file
 Unowned files do not directly imply a security problem, but they are generally a sign that something is amiss. They may be caused by an intruder, by incorrect software installation or draft software removal, or by failure to remove all files belonging to a deleted account. The files should be repaired so they will not cause problems when accounts are created in the future, and the cause should be discovered and addressed. Ensure All World-Writable Directories Are Owned by a System Account All directories in local partitions which are world-writable should be owned by root or another system account. If any world-writable directories are not owned by a system account, this should be investigated. Following this, the files should be deleted or assigned to an appropriate group. The following command will discover and print world-writable directories that are not owned by a system account, given the assumption that only system accounts have a uid lower than 500. Run it once for each local partition PART: 
$ sudo find PART -xdev -type d -perm -0002 -uid +499 -print
 Allowing a user account to own a world-writable directory is undesirable because it allows the owner of that directory to remove or replace any files that may be placed in the directory by other users. scap-security-guide-0.1.31/Fedora/input/xccdf/system/permissions/mounting.xml000066400000000000000000000175721301675746700274250ustar00rootroot00000000000000 Restrict Dynamic Mounting and Unmounting of Filesystems Linux includes a number of facilities for the automated addition and removal of filesystems on a running system. These facilities may be necessary in many environments, but this capability also carries some risk -- whether direct risk from allowing users to introduce arbitrary filesystems, or risk that software flaws in the automated mount facility itself could allow an attacker to compromise the system.

This command can be used to list the types of filesystems that are available to the currently executing kernel: 
$ find /lib/modules/`uname -r`/kernel/fs -type f -name '*.ko'
If these filesystems are not required then they can be explicitly disabled in a configuratio file in /etc/modprobe.d. Disable Modprobe Loading of USB Storage Driver To prevent USB storage devices from being used, configure the kernel module loading system to prevent automatic loading of the USB storage driver. This will prevent the modprobe program from loading the usb-storage module, but will not prevent an administrator (or another program) from using the insmod program to load the module manually. USB storage devices such as thumb drives can be used to introduce malicious software. Disable Kernel Support for USB via Bootloader Configuration All USB support can be disabled by adding the nousb argument to the kernel's boot loader configuration. To do so, append "nousb" to the kernel line in /etc/default/grub as shown: 
kernel /vmlinuz-VERSION ro vga=ext root=/dev/VolGroup00/LogVol00 rhgb quiet nousb
WARNING: Disabling all kernel support for USB will cause problems for systems with USB-based keyboards, mice, or printers. This configuration is infeasible for systems which require USB devices, which is common. Disabling the USB subsystem within the Linux kernel at system boot will protect against potentially malicious USB devices, although it is only practical in specialized systems. Disable Booting from USB Devices in Boot Firmware Configure the system boot firmware (historically called BIOS on PC systems) to disallow booting from USB drives. Booting a system from a USB device would allow an attacker to circumvent any security measures provided by the operating system. Attackers could mount partitions and modify the configuration of the OS. Assign Password to Prevent Changes to Boot Firmware Configuration Assign a password to the system boot firmware (historically called BIOS on PC systems) to require a password for any configuration changes. Assigning a password to the system boot firmware prevents anyone with physical access from configuring the system to boot from local media and circumvent the operating system's access controls. For systems in physically secure locations, such as a data center or Sensitive Compartmented Information Facility (SCIF), this risk must be weighed against the risk of administrative personnel being unable to conduct recovery operations in a timely fashion. Disable the Automounter The autofs daemon mounts and unmounts filesystems, such as user home directories shared via NFS, on demand. In addition, autofs can be used to handle removable media, and the default configuration provides the cdrom device as /misc/cd. However, this method of providing access to removable media is not common, so autofs can almost always be disabled if NFS is not in use. Even if NFS is required, it may be possible to configure filesystem mounts statically by editing /etc/fstab rather than relying on the automounter.

Disabling the automounter permits the administrator to statically control filesystem mounting through /etc/fstab. Disable Mounting of <tt>cramfs</tt> This effectively prevents usage of this uncommon filesystem. Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. Disable Mounting of <tt>freevxfs</tt> This effectively prevents usage of this uncommon filesystem. Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. Disable Mounting of <tt>jffs2</tt> This effectively prevents usage of this uncommon filesystem. Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. Disable Mounting of <tt>hfs</tt> This effectively prevents usage of this uncommon filesystem. Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. Disable Mounting of <tt>hfsplus</tt> This effectively prevents usage of this uncommon filesystem. Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. Disable Mounting of <tt>squashfs</tt> This effectively prevents usage of this uncommon filesystem. Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. Disable Mounting of <tt>udf</tt> This effectively prevents usage of this uncommon filesystem. Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. scap-security-guide-0.1.31/Fedora/input/xccdf/system/permissions/partitions.xml000066400000000000000000000225251301675746700277530ustar00rootroot00000000000000 Restrict Partition Mount Options System partitions can be mounted with certain options that limit what files on those partitions can do. These options are set in the /etc/fstab configuration file, and can be used to make certain types of malicious behavior more difficult. Removable Partition This value is used by the checks mount_option_nodev_removable_partitions, mount_option_nodev_removable_partitions, and mount_option_nodev_removable_partitions to ensure that the correct mount options are set on partitions mounted from removable media such as CD-ROMs, USB keys, and floppy drives. This value should be modified to reflect any removable partitions that are required on the local system. /dev/cdrom Add nodev Option to Non-Root Local Partitions The nodev mount option prevents files from being interpreted as character or block devices. Legitimate character and block devices should exist only in the /dev directory on the root partition or within chroot jails built for system services. The nodev mount option prevents files from being interpreted as character or block devices. The only legitimate location for device files is the /dev directory located on the root partition. The only exception to this is chroot jails, for which it is not advised to set nodev on these filesystems. Add nodev Option to Removable Media Partitions The nodev mount option prevents files from being interpreted as character or block devices. Legitimate character and block devices should exist only in the /dev directory on the root partition or within chroot jails built for system services. The only legitimate location for device files is the /dev directory located on the root partition. An exception to this is chroot jails, and it is not advised to set nodev on partitions which contain their root filesystems. Add noexec Option to Removable Media Partitions The noexec mount option prevents the direct execution of binaries on the mounted filesystem. Preventing the direct execution of binaries from removable media (such as a USB key) provides a defense against malicious software that may be present on such untrusted media. Allowing users to execute binaries from removable media such as USB keys exposes the system to potential compromise. To verify that binaries cannot be directly executed from removable media, run the following command: 
$ grep -v noexec /etc/fstab
The resulting output will show partitions which do not have the noexec flag. Verify all partitions in the output are not removable media. Add nosuid Option to Removable Media Partitions The nosuid mount option prevents set-user-identifier (SUID) and set-group-identifier (SGID) permissions from taking effect. These permissions allow users to execute binaries with the same permissions as the owner and group of the file respectively. Users should not be allowed to introduce SUID and SGID files into the system via partitions mounted from removeable media. The presence of SUID and SGID executables should be tightly controlled. Allowing users to introduce SUID or SGID binaries from partitions mounted off of removable media would allow them to introduce their own highly-privileged programs. Add nodev Option to /tmp The nodev mount option can be used to prevent device files from being created in /tmp. Legitimate character and block devices should not exist within temporary directories like /tmp. The only legitimate location for device files is the /dev directory located on the root partition. The only exception to this is chroot jails. Add noexec Option to /tmp The noexec mount option can be used to prevent binaries from being executed out of /tmp. Allowing users to execute binaries from world-writable directories such as /tmp should never be necessary in normal operation and can expose the system to potential compromise. Add nosuid Option to /tmp The nosuid mount option can be used to prevent execution of setuid programs in /tmp. The SUID and SGID permissions should not be required in these world-writable directories. The presence of SUID and SGID executables should be tightly controlled. Users should not be able to execute SUID or SGID binaries from temporary storage partitions. Add nodev Option to /dev/shm The nodev mount option can be used to prevent creation of device files in /dev/shm. Legitimate character and block devices should not exist within temporary directories like /dev/shm. The only legitimate location for device files is the /dev directory located on the root partition. The only exception to this is chroot jails. Add noexec Option to /dev/shm The noexec mount option can be used to prevent binaries from being executed out of /dev/shm. It can be dangerous to allow the execution of binaries from world-writable temporary storage directories such as /dev/shm. Allowing users to execute binaries from world-writable directories such as /dev/shm can expose the system to potential compromise. Add nosuid Option to /dev/shm The nosuid mount option can be used to prevent execution of setuid programs in /dev/shm. The SUID and SGID permissions should not be required in these world-writable directories. The presence of SUID and SGID executables should be tightly controlled. Users should not be able to execute SUID or SGID binaries from temporary storage partitions. Bind Mount /var/tmp To /tmp The /var/tmp directory is a world-writable directory. Bind-mount it to /tmp in order to consolidate temporary storage into one location protected by the same techniques as /tmp. To do so, edit /etc/fstab and add the following line: 
/tmp     /var/tmp     none     rw,nodev,noexec,nosuid,bind     0 0
See the mount(8) man page for further explanation of bind mounting. Having multiple locations for temporary storage is not required. Unless absolutely necessary to meet requirements, the storage location /var/tmp should be bind mounted to /tmp and thus share the same protections. scap-security-guide-0.1.31/Fedora/input/xccdf/system/selinux.xml000066400000000000000000000204011301675746700246620ustar00rootroot00000000000000 SELinux SELinux is a feature of the Linux kernel which can be used to guard against misconfigured or compromised programs. SELinux enforces the idea that programs should be limited in what files they can access and what actions they can take.

The default SELinux policy, as configured on Red Hat Enterprise Linux 7, has been sufficiently developed and debugged that it should be usable on almost any Red Hat machine with minimal configuration and a small amount of system administrator training. This policy prevents system services - including most of the common network-visible services such as mail servers, FTP servers, and DNS servers - from accessing files which those services have no valid reason to access. This action alone prevents a huge amount of possible damage from network attacks against services, from trojaned software, and so forth.

This guide recommends that SELinux be enabled using the default (targeted) policy on every Red Hat system, unless that system has unusual requirements which make a stronger policy appropriate. SELinux state enforcing - SELinux security policy is enforced.
permissive - SELinux prints warnings instead of enforcing.
disabled - SELinux is fully disabled. enforcing enforcing permissive disabled SELinux policy Type of policy in use. Possible values are:
targeted - Only targeted network daemons are protected.
strict - Full SELinux protection.
mls - Multiple levels of security targeted targeted mls Ensure SELinux Not Disabled in /etc/default/grub SELinux can be disabled at boot time by an argument in /etc/default/grub. Remove any instances of selinux=0 from the kernel arguments in that file to prevent SELinux from being disabled at boot. Inspect /etc/default/grub for any instances of selinux=0 in the kernel boot arguments. Presence of selinux=0 indicates that SELinux is disabled at boot time. Disabling a major host protection feature, such as SELinux, at boot time prevents it from confining system services at boot time. Further, it increases the chances that it will remain off during system operation. Ensure SELinux State is Enforcing The SELinux state should be set to at system boot time. In the file /etc/selinux/config, add or correct the following line to configure the system to boot into enforcing mode: 
SELINUX=
 Check the file /etc/selinux/config and ensure the following line appears: 
SELINUX=
 Setting the SELinux state to enforcing ensures SELinux is able to confine potentially compromised processes to the security policy, which is designed to prevent them from causing damage to the system or further elevating their privileges. Configure SELinux Policy The SELinux targeted policy is appropriate for general-purpose desktops and servers, as well as systems in many other roles. To configure the system to use this policy, add or correct the following line in /etc/selinux/config: 
SELINUXTYPE=
Other policies, such as mls, provide additional security labeling and greater confinement but are not compatible with many general-purpose use cases. Check the file /etc/selinux/config and ensure the following line appears: 
SELINUXTYPE=
 Setting the SELinux policy to targeted or a more specialized policy ensures the system will confine processes that are likely to be targeted for exploitation, such as network or system services. Note: During the development or debugging of SELinux modules, it is common to temporarily place non-production systems in permissive mode. In such temporary cases, SELinux policies should be developed, and once work is completed, the system should be reconfigured to . Uninstall setroubleshoot Package The SETroubleshoot service notifies desktop users of SELinux denials. The service provides information around configuration errors, unauthorized intrusions, and other potential errors. The SETroubleshoot service is an unnecessary daemon to have running on a server Uninstall mcstrans Package The mcstransd daemon provides category label information to client processes requesting information. The label translations are defined in /etc/selinux/targeted/setrans.conf. Since this service is not used very often, disable it to reduce the amount of potentially vulnerable code running on the system. NOTE: This rule was added in support of the CIS RHEL6 v1.2.0 benchmark. Please note that Red Hat does not feel this rule is security relevant. Ensure No Daemons are Unconfined by SELinux Daemons for which the SELinux policy does not contain rules will inherit the context of the parent process. Because daemons are launched during startup and descend from the init process, they inherit the initrc_t context.

To check for unconfined daemons, run the following command: 
$ sudo ps -eZ | egrep "initrc" | egrep -vw "tr|ps|egrep|bash|awk" | tr ':' ' ' | awk '{ print $NF }'
It should produce no output in a well-configured system. Daemons which run with the initrc_t context may cause AVC denials, or allow privileges that the daemon does not require. Ensure No Device Files are Unknown to SELinux Device files, which are used for communication with important system resources, should be labeled with proper SELinux types. If any device files carry the SELinux type device_t, report the bug so that policy can be corrected. Supply information about what the device is and what programs use it. To check for unknown device files, run the following command: 
$sudo find /dev -context *:device_t:* \( -type c -o -type b \) -printf "%p %Z\n"
It should produce no output in a well-configured system. If a device file carries the SELinux type device_t, then SELinux cannot properly restrict access to the device file. scap-security-guide-0.1.31/Fedora/input/xccdf/system/settings/000077500000000000000000000000001301675746700243145ustar00rootroot00000000000000scap-security-guide-0.1.31/Fedora/input/xccdf/system/settings/settings.xml000066400000000000000000000004331301675746700266760ustar00rootroot00000000000000 General System Wide Configuration Settings The following sections contain information on various security-relevant configuration settings that in particular way modify the behaviour of the system as a whole. scap-security-guide-0.1.31/Fedora/input/xccdf/system/software/000077500000000000000000000000001301675746700243065ustar00rootroot00000000000000scap-security-guide-0.1.31/Fedora/input/xccdf/system/software/gnome.xml000066400000000000000000001213361301675746700261430ustar00rootroot00000000000000 GNOME Desktop Environment GNOME is a graphical desktop environment bundled with many Linux distributions that allow users to easily interact with the operating system graphically rather than textually. The GNOME Graphical Display Manager (GDM) provides login, logout, and user switching contexts as well as display server management.

GNOME is developed by the GNOME Project and is considered the default Fedora Graphical environment.

For more information on GNOME and the GNOME Project, see Configure GNOME3 DConf User Profile By default, DConf provides a standard user profile. This profile contains a list of DConf configuration databases. The user profile and database always take the highest priority. As such the DConf User profile should always exist and be configured correctly.

To make sure that the user profile is configured correctly, the /etc/dconf/profile/user should be set as follows: 
user-db:user
system-db:local
system-db:site
system-db:distro
To verify that the DConf User profile is configured correctly, run the following command: 
$ cat /etc/dconf/profile/user
The output should show the following: 
user-db:user
system-db:local
system-db:site
system-db:distro
 Failure to have a functional DConf profile prevents GNOME3 configuration settings from being enforced for all users and allows various security risks. Configure GNOME Login Screen In the default GNOME3 desktop, the login is displayed after system boot and can display user accounts, allow users to reboot the system, and allow users to login automatically and/or with a guest account. The login screen should be configured to prevent such behavior.

For more information about enforcing preferences in the GNOME3 environment using the DConf configuration system, see and the man page dconf(1). Disable GDM Automatic Login The GNOME Display Manager (GDM) can allow users to automatically login without user interaction or credentials. User should always be required to authenticate themselves to the system that they are authorized to use. To disable user ability to automatically login to the system, set the AutomaticLoginEnable to false in the [daemon] section in /etc/gdm/custom.conf. For example: 
[daemon]
AutomaticLoginEnable=false
 To verify that automatic logins are disabled, run the following command: 
$ grep -Pzoi "^\[daemon]\\nautomaticlogin.*" /etc/gdm/custom.conf
The output should show the following: 
[daemon]
AutomaticLoginEnable=false
 Failure to restrict system access to authenticated users negatively impacts operating system security. Disable GDM Guest Login The GNOME Display Manager (GDM) can allow users to login without credentials which can be useful for public kiosk scenarios. Allowing users to login without credentials or "guest" account access has inherent security risks and should be disabled. To do disable timed logins or guest account access, set the TimedLoginEnable to false in the [daemon] section in /etc/gdm/custom.conf. For example: 
[daemon]
TimedLoginEnable=false
 To verify that timed logins are disabled, run the following command: 
$ grep -Pzoi "^\[daemon]\\ntimedlogin.*" /etc/gdm/custom.conf
The output should show the following: 
[daemon]
TimedLoginEnable=false
 Failure to restrict system access to authenticated users negatively impacts operating system security. Disable the GNOME3 Login User List In the default graphical environment, users logging directly into the system are greeted with a login screen that displays all known users. This functionality should be disabled by setting disable-user-list to true.

To disable, add or edit disable-user-list to /etc/dconf/db/gdm.d/00-security-settings. For example: 
[org/gnome/login-screen]
disable-user-list=true
Once the setting has been added, add a lock to /etc/dconf/db/gdm.d/locks/00-security-settings-lock to prevent user modification. For example: 
/org/gnome/login-screen/disable-user-list
After the settings have been set, run dconf update. To ensure the user list is disabled, run the following command: 
$ grep disable-user-list /etc/dconf/db/gdm.d/*
The output should be true. To ensure that users cannot enable displaying the user list, run the following: 
$ grep disable-user-list /etc/dconf/db/gdm.d/locks/*
If properly configured, the output should be /org/gnome/login-screen/disable-user-list Leaving the user list enabled is a security risk since it allows anyone with physical access to the system to quickly enumerate known user accounts without logging in. Disable the GNOME3 Login Restart and Shutdown Buttons In the default graphical environment, users logging directly into the system are greeted with a login screen that allows any user, known or unknown, the ability the ability to shutdown or restart the system. This functionality should be disabled by setting disable-restart-buttons to true.

To disable, add or edit disable-restart-buttons to /etc/dconf/db/gdm.d/00-security-settings. For example: 
[org/gnome/login-screen]
disable-restart-buttons=true
Once the setting has been added, add a lock to /etc/dconf/db/gdm.d/locks/00-security-settings-lock to prevent user modification. For example: 
/org/gnome/login-screen/disable-restart-buttons
After the settings have been set, run dconf update. To ensure disable and restart on the login screen are disabled, run the following command: 
$ grep disable-restart-buttons /etc/dconf/db/gdm.d/*
The output should be true. To ensure that users cannot enable disable and restart on the login screen, run the following: 
$ grep disable-restart-buttons /etc/dconf/db/gdm.d/locks/*
If properly configured, the output should be /org/gnome/login-screen/disable-restart-buttons A user who is at the console can reboot the system at the login screen. If restart or shutdown buttons are pressed at the login screen, this can create the risk of short-term loss of availability of systems due to reboot. Enable the GNOME3 Login Smartcard Authentication In the default graphical environment, smart card authentication can be enabled on the login screen by setting enable-smartcard-authentication to true.

To enable, add or edit enable-smartcard-authentication to /etc/dconf/db/gdm.d/00-security-settings. For example: 
[org/gnome/login-screen]
enable-smartcard-authentication=true
Once the setting has been added, add a lock to /etc/dconf/db/gdm.d/locks/00-security-settings-lock to prevent user modification. For example: 
/org/gnome/login-screen/enable-smartcard-authentication
After the settings have been set, run dconf update. To ensure smart card authentication on the login screen is enabled, run the following command: 
$ grep enable-smartcard-authentication /etc/dconf/db/gdm.d/*
The output should be true. To ensure that users cannot disable smart card authentication on the login screen, run the following: 
$ grep enable-smartcard-authentication /etc/dconf/db/gdm.d/locks/*
If properly configured, the output should be /org/gnome/login-screen/enable-smartcard-authentication Smart card login provides two-factor authentication stronger than that provided by a username and password combination. Smart cards leverage PKI (public key infrastructure) in order to provide and verify credentials. Set the GNOME3 Login Number of Failures In the default graphical environment, the GNOME3 login screen and be configured to restart the authentication process after a configured number of attempts. This can be configured by setting allowed-failures to 3 or less.

To enable, add or edit allowed-failures to /etc/dconf/db/gdm.d/00-security-settings. For example: 
[org/gnome/login-screen]
allowed-failures=3
Once the setting has been added, add a lock to /etc/dconf/db/gdm.d/locks/00-security-settings-lock to prevent user modification. For example: 
/org/gnome/login-screen/allowed-failures
After the settings have been set, run dconf update. To ensure the login screen resets after a specified number of failures, run the following command: 
$ grep allowed-failures /etc/dconf/db/gdm.d/*
The output should be 3 or less. To ensure that users cannot change or configure the resets after a specified number of failures on the login screen, run the following: 
$ grep allowed-failures /etc/dconf/db/gdm.d/locks/*
If properly configured, the output should be /org/gnome/login-screen/allowed-failures Setting the password retry prompts that are permitted on a per-session basis to a low value requires some software, such as SSH, to re-connect. This can slow down and draw additional attention to some types of password-guessing attacks. Configure GNOME Screen Locking In the default GNOME3 desktop, the screen can be locked by selecting the user name in the far right corner of the main panel and selecting Lock.

The following sections detail commands to enforce idle activation of the screensaver, screen locking, a blank-screen screensaver, and an idle activation time.

Because users should be trained to lock the screen when they step away from the computer, the automatic locking feature is only meant as a backup.

The root account can be screen-locked; however, the root account should never be used to log into an X Windows environment and should only be used to for direct login via console in emergency circumstances.

For more information about enforcing preferences in the GNOME3 environment using the DConf configuration system, see and the man page dconf(1). For Red Hat specific information on configuring DConf settings, see Inactivity timeout Choose allowed duration of inactive SSH connections, shells, and X sessions 900 300 600 900 Set GNOME3 Screensaver Inactivity Timeout The idle time-out value for inactivity in the GNOME3 desktop is configured via the idle-delay setting must be set under an appropriate configuration file(s) in the /etc/dconf/db/local.d directory and locked in /etc/dconf/db/local.d/locks directory to prevent user modification.
For example, to configure the system for a 15 minute delay, add the following to /etc/dconf/db/local.d/00-security-settings: 
[org/gnome/desktop/session]
idle-delay=900
Once the setting has been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
/org/gnome/desktop/session/idle-delay
After the settings have been set, run dconf update. To check the current idle time-out value, run the following command: 
$ gsettings get org.gnome.desktop.session idle-delay
If properly configured, the output should be 'uint32 '. To ensure that users cannot change the screensaver inactivity timeout setting, run the following: 
$ grep idle-delay /etc/dconf/db/local.d/locks/*
If properly configured, the output should be /org/gnome/desktop/session/idle-delay A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not logout because of the temporary nature of the absence. Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity, GNOME3 can be configured to identify when a user's session has idled and take action to initiate a session lock. Enable GNOME3 Screensaver Idle Activation To activate the screensaver in the GNOME3 desktop after a period of inactivity, add or set idle-activation-enabled to true in /etc/dconf/db/local.d/00-security-settings. For example: 
[org/gnome/desktop/screensaver]
idle_activation_enabled=true
Once the setting has been added, add a lock to /etc/dconf/db/gdm.d/locks/00-security-settings-lock to prevent user modification. For example: 
/org/gnome/desktop/screensaver/idle-activation-enabled
After the settings have been set, run dconf update. To check the screensaver mandatory use status, run the following command: 
$ gsettings get org.gnome.desktop.screensaver idle-activation-enabled
If properly configured, the output should be true. To ensure that users cannot disable the screensaver idle inactivity setting, run the following: 
$ grep idle-activation-enabled /etc/dconf/db/local.d/locks/*
If properly configured, the output should be /org/gnome/desktop/screensaver/idle-activation-enabled A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not logout because of the temporary nature of the absence. Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity, GNOME desktops can be configured to identify when a user's session has idled and take action to initiate the session lock. Enabling idle activation of the screensaver ensures the screensaver will be activated after the idle delay. Applications requiring continuous, real-time screen display (such as network management products) require the login session does not have administrator rights and the display station is located in a controlled-access area. Enable GNOME3 Screensaver Lock After Idle Period To activate locking of the screensaver in the GNOME3 desktop when it is activated, add or set lock-enabled to true and lock-delay to 0 in /etc/dconf/db/local.d/00-security-settings. For example: 
[org/gnome/desktop/screensaver]
lock-enabled=true
lock-delay=0
Once the settings have been added, add a lock to /etc/dconf/db/gdm.d/locks/00-security-settings-lock to prevent user modification. For example: 
/org/gnome/desktop/screensaver/lock-enabled
/org/gnome/desktop/screensaver/lock-delay
After the settings have been set, run dconf update. To check the status of the idle screen lock activation, run the following command: 
$ gsettings get org.gnome.desktop.screensaver lock-enabled
If properly configured, the output should be true. To check that the screen locks immediately when activated, run the following command: 
$ gsettings get org.gnome.desktop.screensaver lock-delay
If properly configured, the output should be 'uint32 0'. To ensure that users cannot change how long until the the screensaver locks, run the following: 
$ grep 'lock-enabled\|lock-delay' /etc/dconf/db/local.d/locks/*
If properly configured, the output for lock-enabled should be /org/gnome/desktop/screensaver/lock-enabled If properly configured, the output for lock-delay should be /org/gnome/desktop/screensaver/lock-delay A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not want to logout because of the temporary nature of the absense. Implement Blank Screensaver To set the screensaver mode in the GNOME3 desktop to a blank screen, add or set picture-uri to '' in /etc/dconf/db/local.d/00-security-settings. For example: 
[org/gnome/desktop/screensaver]
picture-uri=''
Once the settings have been added, add a lock to /etc/dconf/db/gdm.d/locks/00-security-settings-lock to prevent user modification. For example: 
/org/gnome/desktop/screensaver/picture-uri
After the settings have been set, run dconf update. To ensure the screensaver is configured to be blank, run the following command: 
$ gsettings get org.gnome.desktop.screensaver picture-uri
If properly configured, the output should be ''. To ensure that users cannot set the screensaver background, run the following: 
$ grep picture-uri /etc/dconf/db/local.d/locks/*
If properly configured, the output should be /org/gnome/desktop/screensaver/picture-uri Setting the screensaver mode to blank-only conceals the contents of the display from passersby. Disable Full User Name on Splash Shield By default when the screen is locked, the splash shield will show the user's full name. This should be disabled to prevent casual observers from seeing who has access to the system. This can be disabled by adding or setting show-full-name-in-top-bar to false in /etc/dconf/db/local.d/00-security-settings. For example: 
[org/gnome/desktop/screensaver]
show-full-name-in-top-bar=false
Once the settings have been added, add a lock to /etc/dconf/db/gdm.d/locks/00-security-settings-lock to prevent user modification. For example: 
/org/gnome/desktop/screensaver/show-full-name-in-top-bar
After the settings have been set, run dconf update. To ensure the splash screen is configured not to show user name, run the following command: 
$ gsettings get org.gnome.desktop.screensaver show-full-name-in-top-bar
If properly configured, the output should be false. To ensure that users cannot enable user name on the lock screen, run the following: 
$ grep show-full-name-in-top-bar /etc/dconf/db/local.d/locks/*
If properly configured, the output should be /org/gnome/desktop/screensaver/show-full-name-in-top-bar Setting the splash screen to not reveal the logged in user's name conceals who has access to the system from passersby. GNOME System Settings GNOME provides configuration and functionality to a graphical desktop environment that changes grahical configurations or allow a user to perform actions that users normally would not be able to do in non-graphical mode such as remote access configuration, power policies, Geo-location, etc. Configuring such settings in GNOME will prevent accidential graphical configuration changes by users from taking place. Disable Ctrl-Alt-Del Reboot Key Sequence in GNOME3 By default, GNOME will reboot the system if the Ctrl-Alt-Del key sequence is pressed.
To configure the system to ignore the Ctrl-Alt-Del key sequence from the Graphical User Interface (GUI) instead of rebooting the system, add or set logout to '' in /etc/dconf/db/local.d/00-security-settings. For example: 
[org/gnome/settings-daemon/plugins/media-keys]
logout=''
Once the settings have been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
/org/gnome/settings-daemon/plugins/media-keys/logout
After the settings have been set, run dconf update. To ensure the system is configured to ignore the Ctrl-Alt-Del sequence, run the following command: 
$ gsettings get org.gnome.settings-daemon.plugins.media-keys logout
If properly configured, the output should be ''. To ensure that users cannot enable the Ctrl-Alt-Del sequence, run the following: 
$ grep logout /etc/dconf/db/local.d/locks/*
If properly configured, the output should be /org/gnome/settings-daemon/plugins/media-keys/logout A locally logged-in user who presses Ctrl-Alt-Del, when at the console, can reboot the system. If accidentally pressed, as could happen in the case of mixed OS environment, this can create the risk of short-term loss of availability of systems due to unintentional reboot. Disable User Administration in GNOME3 By default, GNOME will allow all users to have some administratrion capability. This should be disabled so that non-administrative users are not making configuration changes. To configure the system to disable user administration capability in the Graphical User Interface (GUI), add or set user-administration-disabled to true in /etc/dconf/db/local.d/00-security-settings. For example: 
[org/gnome/desktop/lockdown]
user-administration-disabled=true
Once the settings have been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
/org/gnome/desktop/lockdown/user-administration-disabled
After the settings have been set, run dconf update. To ensure the GUI does not allow user administratrion capabilities to all users, run the following command: 
$ gsettings get org.gnome.desktop.lockdown user-administration-disabled
If properly configured, the output should be true. To ensure that users cannot enable user administration, run the following: 
$ grep user-administration /etc/dconf/db/local.d/locks/*
If properly configured, the output should be /org/gnome/desktop/lockdown/user-administration-disabled Allowing all users to have some administratrive capabilities to the system through the Graphical User Interface (GUI) when they would not have them otherwise could allow unintended configuration changes as well as a nefarious user the capability to make system changes such as adding new accounts, etc. Disable Power Settings in GNOME3 By default, GNOME enables a power profile designed for mobile devices with battery usage. While useful for mobile devices, this setting should be disabled for all other systems. To configure the system to disable the power setting, add or set active to false in /etc/dconf/db/local.d/00-security-settings. For example: 
[org/gnome/settings-daemon/plugins/power]
active=false
Once the settings have been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
/org/gnome/settings-daemon/plugins/power
After the settings have been set, run dconf update. To ensure that the GUI power settings are not active, run the following command: 
$ gsettings get org.gnome.settings-daemon.plugins.power active
If properly configured, the output should be false. To ensure that users cannot enable the power settings, run the following: 
$ grep power /etc/dconf/db/local.d/locks/*
If properly configured, the output should be /org/gnome/settings-daemon/plugins/power/active Power settings should not be enabled on systems that are not mobile devices. Enabling power settings on non-mobile devices could have unintended processing consequences on standard systems. Disable Geolocation in GNOME3 GNOME allows the clock and applications to track and access location information. This setting should be disabled as applications should not track system location. To configure the system to disable location tracking, add or set enabled to false in /etc/dconf/db/local.d/00-security-settings. For example: 
[org/gnome/system/location]
enabled=false
To configure the clock to disable location tracking, add or set geolocation to false in /etc/dconf/db/local.d/00-security-settings. For example: 
[org/gnome/clocks]
geolocation=false
Once the settings have been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
/org/gnome/system/location/enabled
/org/gnome/clocks/geolocation
After the settings have been set, run dconf update. To ensure that system location tracking is not active, run the following command: 
$ gsettings get org.gnome.system.location enabled
$ gsettings get org.gnome.clocks geolocation
If properly configured, the output should be false. To ensure that users cannot enable system location tracking, run the following: 
$ grep location /etc/dconf/db/local.d/locks/*
If properly configured, the output should be /org/gnome/system/location/enabled and /org/gnome/clocks/geolocation. Power settings should not be enabled on systems that are not mobile devices. Enabling power settings on non-mobile devices could have unintended processing consequences on standard systems. GNOME Network Settings GNOME network settings that apply to the graphical interface. Disable WIFI Network Connection Creation in GNOME3 GNOME allows users to create ad-hoc wireless connections through the NetworkManager applet. Wireless connections should be disabled by adding or setting disable-wifi-create to true in /etc/dconf/db/local.d/00-security-settings. For example: 
[org/gnome/nm-applet]
disable-wifi-create=true
Once the settings have been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
/org/gnome/nm-applet/disable-wifi-create
After the settings have been set, run dconf update. To ensure that WIFI connections caanot be created, run the following command: 
$ gsettings get org.gnome.nm-applet disable-wifi-create
If properly configured, the output should be true. To ensure that users cannot enable WIFI connection creation, run the following: 
$ grep wifi-create /etc/dconf/db/local.d/locks/*
If properly configured, the output should be /org/gnome/nm-applet/disable-wifi-create Wireless network connections should not be allowed to be configured by general users on a given system as it could open the system to backdoor attacks. Disable WIFI Network Notification in GNOME3 By default, GNOME disables WIFI notification. This should be permanently set so that users do not connect to a wireless network when the system finds one. While useful for mobile devices, this setting should be disabled for all other systems. To configure the system to disable the WIFI notication, add or set suppress-wireless-networks-available to true in /etc/dconf/db/local.d/00-security-settings. For example: 
[org/gnome/nm-applet]
suppress-wireless-networks-available=true
Once the settings have been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
/org/gnome/nm-applet/suppress-wireless-networks-available
After the settings have been set, run dconf update. To ensure that wireless network notification is disabled, run the following command: 
$ gsettings get org.gnome.nm-applet suppress-wireless-networks-available
If properly configured, the output should be true. To ensure that users cannot enable wireless notification, run the following: 
$ grep wireless-networks-available /etc/dconf/db/local.d/locks/*
If properly configured, the output should be /org/gnome/nm-applet/suppress-wireless-networks-available Wireless network connections should not be allowed to be configured by general users on a given system as it could open the system to backdoor attacks. GNOME Remote Access Settings GNOME remote access settings that apply to the graphical interface. Require Credential Prompting for Remote Access in GNOME3 By default, GNOME does not require credentials when using Vino for remote access. To configure the system to require remote credentials, add or set authentication-methods to ['vnc'] in /etc/dconf/db/local.d/00-security-settings. For example: 
[org/gnome/Vino]
authentication-methods=['vnc']
Once the settings have been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
/org/gnome/Vino/authentication-methods
After the settings have been set, run dconf update. To ensure that remote access requires credentials, run the following command: 
$ gsettings get org.gnome.Vino authentication-methods
If properly configured, the output should be false. To ensure that users cannot disable credentials for remote access, run the following: 
$ grep authentication-methods /etc/dconf/db/local.d/locks/*
If properly configured, the output should be /org/gnome/Vino/authentication-methods Username and password prompting is required for remote access. Otherwise, non-authorized and nefarious users can access the system freely. Require Encryption for Remote Access in GNOME3 By default, GNOME requires encryption when using Vino for remote access. To prevent remote access encryption from being disabled, add or set require-encryption to true in /etc/dconf/db/local.d/00-security-settings. For example: 
[org/gnome/Vino]
require-encryption=true
Once the settings have been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
/org/gnome/Vino/require-encryption
After the settings have been set, run dconf update. To ensure that remote access connections are encrypted, run the following command: 
$ gsettings get org.gnome.Vino require-encrpytion
If properly configured, the output should be true. To ensure that users cannot disable encrypted remote connections, run the following: 
$ grep require-encryption /etc/dconf/db/local.d/locks/*
If properly configured, the output should be /org/gnome/Vino/require-encryption Open X displays allow an attacker to capture keystrokes and to execute commands remotely. GNOME Media Settings GNOME media settings that apply to the graphical interface. Disable GNOME3 Automounting The system's default desktop environment, GNOME3, will mount devices and removable media (such as DVDs, CDs and USB flash drives) whenever they are inserted into the system. To disable automount and autorun within GNOME3, add or set automount to false, automount-open to false, and autorun-never to true in /etc/dconf/db/local.d/00-security-settings. For example: 
[org/gnome/desktop/media-handling]
automount=false
automount-open=false
autorun-never=true
Once the settings have been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
/org/gnome/desktop/media-handling/automount
/org/gnome/desktop/media-handling/auto-open
/org/gnome/desktop/media-handling/autorun-never
After the settings have been set, run dconf update. These settings can be verified by running the following: 
$ gsettings get org.gnome.desktop.media-handling automount
$ gsettings get org.gnome.desktop.media-handling automount-open
$ gsettings get org.gnome.desktop.media-handling autorun-never
If properly configured, the output for automount should be false. If properly configured, the output for automount-openshould be false. If properly configured, the output for autorun-never should be true. To ensure that users cannot enable automount and autorun in GNOME3, run the following: 
$ grep 'automount\|autorun' /etc/dconf/db/local.d/locks/*
If properly configured, the output for automount should be /org/gnome/desktop/media-handling/automount If properly configured, the output for automount-open should be /org/gnome/desktop/media-handling/auto-open If properly configured, the output for autorun-never should be /org/gnome/desktop/media-handling/autorun-never Disabling automatic mounting in GNOME3 can prevent the introduction of malware via removable media. It will, however, also prevent desktop users from legitimate use of removable media. Disable All GNOME3 Thumbnailers The system's default desktop environment, GNOME3, uses a number of different thumbnailer programs to generate thumbnails for any new or modified content in an opened folder. To disable the execution of these thumbnail applications, add or set disable-all to true in /etc/dconf/db/local.d/00-security-settings. For example: 
[org/gnome/desktop/thumbnailers]
disable-all=true
Once the settings have been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
/org/gnome/desktop/thumbnailers/disable-all
After the settings have been set, run dconf update. This effectively prevents an attacker from gaining access to a system through a flaw in GNOME3's Nautilus thumbnail creators. These settings can be verified by running the following: 
$ gsettings get org.gnome.desktop.thumbnailers disable-all
If properly configured, the output should be true. To ensure that users cannot how long until the the screensaver locks, run the following: 
$ grep disable-all /etc/dconf/db/local.d/locks/*
If properly configured, the output should be /org/gnome/desktop/thumbnailers/disable-all An attacker with knowledge of a flaw in a GNOME3 thumbnailer application could craft a malicious file to exploit this flaw. Assuming the attacker could place the malicious file on the local filesystem (via a web upload for example) and assuming a user browses the same location using Nautilus, the malicious file would exploit the thumbnailer with the potential for malicious code execution. It is best to disable these thumbnailer applications unless they are explicitly required. scap-security-guide-0.1.31/Fedora/input/xccdf/system/software/integrity.xml000066400000000000000000000251001301675746700270440ustar00rootroot00000000000000 Software Integrity Checking Both the AIDE (Advanced Intrusion Detection Environment) software and the RPM package management system provide mechanisms for verifying the integrity of installed software. AIDE uses snapshots of file metadata (such as hashes) and compares these to current system files in order to detect changes. The RPM package management system can conduct integrity checks by comparing information in its metadata database with files installed on the system.

Integrity checking cannot prevent intrusions, but can detect that they have occurred. Requirements for software integrity checking may be highly dependent on the environment in which the system will be used. Snapshot-based approaches such as AIDE may induce considerable overhead in the presence of frequent software updates. Verify Integrity with AIDE AIDE conducts integrity checks by comparing information about files with previously-gathered information. Ideally, the AIDE database is created immediately after initial system configuration, and then again after any software update. AIDE is highly configurable, with further configuration information located in /usr/share/doc/aide-VERSION. Install AIDE Install the AIDE package with the command: 
$ sudo dnf install aide
 The AIDE package must be installed if it is to be available for integrity checking. Disable Prelinking The prelinking feature changes binaries in an attempt to decrease their startup time. In order to disable it, change or add the following line inside the file /etc/sysconfig/prelink: 
PRELINKING=no
Next, run the following command to return binaries to a normal, non-prelinked state: 
$ sudo /usr/sbin/prelink -ua
 The prelinking feature can interfere with the operation of AIDE, because it changes binaries. Build and Test AIDE Database Run the following command to generate a new database: 
# /usr/sbin/aide --init
By default, the database will be written to the file /var/lib/aide/aide.db.new.gz. Storing the database, the configuration file /etc/aide.conf, and the binary /usr/sbin/aide (or hashes of these files), in a secure location (such as on read-only media) provides additional assurance about their integrity. The newly-generated database can be installed as follows: 
# cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
To initiate a manual check, run the following command: 
# /usr/sbin/aide --check
If this check produces any unexpected output, investigate. For AIDE to be effective, an initial database of "known-good" information about files must be captured and it should be able to be verified against the installed files. Configure Periodic Execution of AIDE To implement a daily execution of AIDE at 4:05am using cron, add the following line to /etc/crontab: 
05 4 * * * root /usr/sbin/aide --check
AIDE can be executed periodically through other means; this is merely one example. To determine that periodic AIDE execution has been scheduled, run the following command: 
# grep aide /etc/crontab
 By default, AIDE does not install itself for periodic execution. Periodically running AIDE is necessary to reveal unexpected changes in installed files. Verify Integrity with RPM The RPM package management system includes the ability to verify the integrity of installed packages by comparing the installed files with information about the files taken from the package metadata stored in the RPM database. Although an attacker could corrupt the RPM database (analogous to attacking the AIDE database as described above), this check can still reveal modification of important files. To list which files on the system differ from what is expected by the RPM database: 
# rpm -qVa
See the man page for rpm to see a complete explanation of each column. Verify and Correct File Permissions with RPM The RPM package management system can check file access permissions of installed software packages, including many that are important to system security. After locating a file with incorrect permissions, run the following command to determine which package owns it: 
# rpm -qf FILENAME
Next, run the following command to reset its permissions to the correct values: 
# rpm --setperms PACKAGENAME
 The following command will list which files on the system have permissions different from what is expected by the RPM database: 
# rpm -Va | grep '^.M'
 Permissions on system binaries and configuration files that are too generous could allow an unauthorized user to gain privileges that they should not have. The permissions set by the vendor should be maintained. Any deviations from this baseline should be investigated. Verify File Hashes with RPM The RPM package management system can check the hashes of installed software packages, including many that are important to system security. Run the following command to list which files on the system have hashes that differ from what is expected by the RPM database: 
# rpm -Va | grep '^..5'
A "c" in the second column indicates that a file is a configuration file, which may appropriately be expected to change. If the file was not expected to change, investigate the cause of the change using audit logs or other means. The package can then be reinstalled to restore the file. Run the following command to determine which package owns the file: 
# rpm -qf FILENAME
The package can be reinstalled from a dnf repository using the command: 
dnf reinstall PACKAGENAME
Alternatively, the package can be reinstalled from trusted media using the command: 
rpm -Uvh PACKAGENAME
 The following command will list which files on the system have file hashes different from what is expected by the RPM database. 
# rpm -Va | awk '$1 ~ /..5/ && $2 != "c"'
 The hashes of important files like system executables should match the information given by the RPM database. Executables with erroneous hashes could be a sign of nefarious activity on the system. Additional Security Software Additional security software that is not provided or supported by Red Hat can be installed to provide complementary or duplicative security capabilities to those provided by the base platform. Add-on software may not be appropriate for some specialized systems. Install Intrusion Detection Software The Red Hat platform includes a sophisticated auditing system and SELinux, which provide host-based intrusion detection capabilities. Inspect the system to determine if intrusion detection software has been installed. Verify this intrusion detection software is active. Host-based intrusion detection tools provide a system-level defense when an intruder gains access to a system or network. Install Virus Scanning Software Install virus scanning software, which uses signatures to search for the presence of viruses on the filesystem. The McAfee VirusScan Enterprise for Linux virus scanning tool is provided for DoD systems. Ensure virus definition files are no older than 7 days, or their last release. Configure the virus scanning software to perform scans dynamically on all accessed files. If this is not possible, configure the system to scan all altered files on the system on a daily basis. If the system processes inbound SMTP mail, configure the virus scanner to scan all received mail. Inspect the system for a cron job or system service which executes a virus scanning tool regularly.
To verify the McAfee VSEL system service is operational, run the following command: 
# /etc/init.d/nails status

To check on the age of uvscan virus definition files, run the following command: 
# cd /opt/NAI/LinuxShield/engine/dat
# ls -la avvscan.dat avvnames.dat avvclean.dat
 Virus scanning software can be used to detect if a system has been compromised by computer viruses, as well as to limit their spread to other systems. scap-security-guide-0.1.31/Fedora/input/xccdf/system/software/updating.xml000066400000000000000000000056651301675746700266570ustar00rootroot00000000000000 Updating Software The dnf command line tool is used to install and update software packages. The system also provides a graphical software update tool in the System menu, in the Administration submenu, called Software Update.

Fedora systems contain an installed software catalog called the RPM database, which records metadata of installed packages. Tools such as dnf or the graphical Software Update ensure usage of RPM packages for software installation. This allows for insight into the current inventory of installed software on the system, and is highly recommended. gpgcheck Enabled In Main Dnf Configuration The gpgcheck option should be used to ensure checking of an RPM package's signature always occurs prior to its installation. To configure dnf to check package signatures before installing them, ensure the following line appears in /etc/dnf/dnf.conf in the [main] section: 
gpgcheck=1
 To determine whether dnf is configured to use gpgcheck, inspect /etc/dnf/dnf.conf and ensure the following appears in the [main] section: 
gpgcheck=1
A value of 1 indicates that gpgcheck is enabled. Absence of a gpgcheck line or a setting of 0 indicates that it is disabled. Ensuring the validity of packages' cryptographic signatures prior to installation ensures the provenance of the software and protects against malicious tampering. gpgcheck Enabled For All Dnf Package Repositories To ensure signature checking is not disabled for any repos, remove any lines from files in /etc/yum.repos.d of the form: 
gpgcheck=0
 To determine whether dnf has been configured to disable gpgcheck for any repos, inspect all files in /etc/yum.repos.d and ensure the following does not appear in any sections: 
gpgcheck=0
A value of 0 indicates that gpgcheck has been disabled for that repo. Ensuring all packages' cryptographic signatures are valid prior to installation ensures the provenance of the software and protects against malicious tampering. scap-security-guide-0.1.31/Fedora/templates/000077500000000000000000000000001301675746700207005ustar00rootroot00000000000000scap-security-guide-0.1.31/Fedora/templates/csv/000077500000000000000000000000001301675746700214735ustar00rootroot00000000000000scap-security-guide-0.1.31/Fedora/templates/csv/packages_installed.csv000066400000000000000000000000061301675746700260210ustar00rootroot00000000000000audit scap-security-guide-0.1.31/Fedora/templates/csv/services_enabled.csv000066400000000000000000000000171301675746700255030ustar00rootroot00000000000000chronyd,chrony scap-security-guide-0.1.31/Fedora/templates/static/000077500000000000000000000000001301675746700221675ustar00rootroot00000000000000scap-security-guide-0.1.31/Fedora/templates/static/bash/000077500000000000000000000000001301675746700231045ustar00rootroot00000000000000scap-security-guide-0.1.31/Fedora/templates/static/bash/accounts_maximum_age_login_defs.sh000066400000000000000000000006561301675746700320300ustar00rootroot00000000000000# platform = multi_platform_fedora . /usr/share/scap-security-guide/remediation_functions declare var_accounts_maximum_age_login_defs populate var_accounts_maximum_age_login_defs grep -q ^PASS_MAX_DAYS /etc/login.defs && \ sed -i "s/PASS_MAX_DAYS.*/PASS_MAX_DAYS\t$var_accounts_maximum_age_login_defs/g" /etc/login.defs if ! [ $? -eq 0 ] then echo -e "PASS_MAX_DAYS\t$var_accounts_maximum_age_login_defs" >> /etc/login.defs fi scap-security-guide-0.1.31/Fedora/templates/static/bash/accounts_minimum_age_login_defs.sh000066400000000000000000000006561301675746700320260ustar00rootroot00000000000000# platform = multi_platform_fedora . /usr/share/scap-security-guide/remediation_functions declare var_accounts_minimum_age_login_defs populate var_accounts_minimum_age_login_defs grep -q ^PASS_MIN_DAYS /etc/login.defs && \ sed -i "s/PASS_MIN_DAYS.*/PASS_MIN_DAYS\t$var_accounts_minimum_age_login_defs/g" /etc/login.defs if ! [ $? -eq 0 ] then echo -e "PASS_MIN_DAYS\t$var_accounts_minimum_age_login_defs" >> /etc/login.defs fi scap-security-guide-0.1.31/Fedora/templates/static/bash/accounts_password_minlen_login_defs.sh000066400000000000000000000006721301675746700327410ustar00rootroot00000000000000# platform = multi_platform_fedora . /usr/share/scap-security-guide/remediation_functions declare var_accounts_password_minlen_login_defs populate var_accounts_password_minlen_login_defs grep -q ^PASS_MIN_LEN /etc/login.defs && \ sed -i "s/PASS_MIN_LEN.*/PASS_MIN_LEN\t$var_accounts_password_minlen_login_defs/g" /etc/login.defs if ! [ $? -eq 0 ] then echo -e "PASS_MIN_LEN\t$var_accounts_password_minlen_login_defs" >> /etc/login.defs fi scap-security-guide-0.1.31/Fedora/templates/static/bash/accounts_password_warn_age_login_defs.sh000066400000000000000000000007061301675746700332400ustar00rootroot00000000000000# platform = multi_platform_fedora . /usr/share/scap-security-guide/remediation_functions declare var_accounts_password_warn_age_login_defs populate var_accounts_password_warn_age_login_defs grep -q ^PASS_WARN_AGE /etc/login.defs && \ sed -i "s/PASS_WARN_AGE.*/PASS_WARN_AGE\t$var_accounts_password_warn_age_login_defs/g" /etc/login.defs if ! [ $? -eq 0 ] then echo -e "PASS_WARN_AGE\t$var_accounts_password_warn_age_login_defs" >> /etc/login.defs fi scap-security-guide-0.1.31/Fedora/templates/static/bash/disable_prelink.sh000066400000000000000000000006211301675746700265660ustar00rootroot00000000000000# platform = multi_platform_fedora # # Disable prelinking altogether # if grep -q ^PRELINKING /etc/sysconfig/prelink then sed -i 's/PRELINKING.*/PRELINKING=no/g' /etc/sysconfig/prelink else echo -e "\n# Set PRELINKING=no per security requirements" >> /etc/sysconfig/prelink echo "PRELINKING=no" >> /etc/sysconfig/prelink fi # # Undo previous prelink changes to binaries # /usr/sbin/prelink -ua scap-security-guide-0.1.31/Fedora/transforms/000077500000000000000000000000001301675746700211005ustar00rootroot00000000000000scap-security-guide-0.1.31/Fedora/transforms/constants.xslt000066400000000000000000000021641301675746700240330ustar00rootroot00000000000000 Fedora Fedora empty fedora empty FEDORA cpe:/o:fedoraproject:fedora:25,cpe:/o:fedoraproject:fedora:24,cpe:/o:fedoraproject:fedora:23 scap-security-guide-0.1.31/Fedora/transforms/shorthand2xccdf.xslt000066400000000000000000000005131301675746700250770ustar00rootroot00000000000000 unknown unlinked-fedora-oval.xml scap-security-guide-0.1.31/Fedora/transforms/xccdf-removeaux.xslt000066400000000000000000000005011301675746700251100ustar00rootroot00000000000000 scap-security-guide-0.1.31/Fedora/transforms/xccdf2table-profilecisrefs.xslt000066400000000000000000000007051301675746700272140ustar00rootroot00000000000000 scap-security-guide-0.1.31/Fedora/utils/000077500000000000000000000000001301675746700200425ustar00rootroot00000000000000scap-security-guide-0.1.31/Fedora/utils/README000066400000000000000000000010211301675746700207140ustar00rootroot00000000000000This file is meant to give a quick overview to some of the scripts located in this directory. verify-input-sanity.py Purpose: This script can be invoked without arguments to examine the files within src/input to make sure that they are in good shape *prior to* building the XCCDF and OVAL content with the various make commands. Intent: Help XCCDF and OVAL developers spot common mistakes *before* utilizing the Makefile to build the XCCDF and OVAL content. Usage: ../../shared/utils/verify-input-sanity.py scap-security-guide-0.1.31/Firefox/000077500000000000000000000000001301675746700171045ustar00rootroot00000000000000scap-security-guide-0.1.31/Firefox/Makefile000066400000000000000000000153461301675746700205550ustar00rootroot00000000000000all: tables guide content dist SHARED = ../shared include $(SHARED)/product-make.include PROD = firefox VENDOR = ssgproject checks: xmlwf $(IN)/oval/*.xml $(SHARED)/$(UTILS)/combine-ovals.py $(CONF) $(PROD) $(IN)/oval > $(OUT)/unlinked-$(PROD)-oval.xml xmllint --format --output $(OUT)/unlinked-$(PROD)-oval.xml $(OUT)/unlinked-$(PROD)-oval.xml # example, if needed: for converting XCCDF into shorthand #xccdf2shorthand: # xsltproc -o $(XCCDF_OUTPUT_DIR)/$(PROD)-shorthand.xml $(TRANS)/xccdf2shorthand.xslt $(REFS)/usgcb-$(PROD)desktop-xccdf.xml # tidy -m -xml -utf8 --indent-spaces=0 $(XCCDF_OUTPUT_DIR)/$(PROD)-shorthand.xml table-refs: $(OUT)/xccdf-unlinked-final.xml xsltproc -stringparam ref "nist" -o $(OUT)/table-$(PROD)-nistrefs.html $(TRANS)/xccdf2table-byref.xslt $< xsltproc -stringparam profile "common" -o $(OUT)/table-$(PROD)-nistrefs-common.html \ $(TRANS)/xccdf2table-profilenistrefs.xslt $< table-idents: $(OUT)/xccdf-unlinked-final.xml xsltproc -o $(OUT)/table-$(PROD)-cces.html $(TRANS)/xccdf2table-cce.xslt $< table-srgmap: $(OUT)/xccdf-unlinked-final.xml # the map-to-items filename must be provided relative to the root of the main document being processed xsltproc -stringparam map-to-items "../$<" -o $(OUT)/table-$(PROD)-srgmap.html \ $(TRANS)/table-srgmap.xslt $(REFS)/disa-stig-firefox-v4r11-xccdf-manual.xml xsltproc -stringparam flat "y" -stringparam map-to-items "../$<" -o $(OUT)/table-$(PROD)-srgmap-flat.html \ $(TRANS)/table-srgmap.xslt $(REFS)/disa-stig-firefox-v4r11-xccdf-manual.xml xmllint --xmlout --html --output $(OUT)/table-$(PROD)-srgmap-flat.xhtml $(OUT)/table-$(PROD)-srgmap-flat.html table-stigs: $(OUT)/xccdf-unlinked-final.xml table-srgmap checks xsltproc -o $(OUT)/table-firefox-stig.html $(TRANS)/xccdf2table-stig.xslt $(REFS)/disa-stig-firefox-v4r11-xccdf-manual.xml xsltproc -o $(OUT)/table-firefox-stig-manual.html $(TRANS)/xccdf2table-stig.xslt $(REFS)/disa-stig-firefox-v4r11-xccdf-manual.xml # xsltproc -stringparam notes "../$(IN)/auxiliary/transition_notes.xml" -o $(OUT)/table-$(PROD)-stig-manual-withnotes.html \ # $(TRANS)/xccdf2table-stig.xslt \ # $(REFS)/disa-stig-$(PROD)-v1r0.6-xccdf-manual.xml # temporarily retain an output file showing the short titles as well xsltproc -stringparam profile "stig-$(PROD)-upstream" -stringparam testinfo "y" -o $(OUT)/table-stig-$(PROD)-testinfo.html \ $(TRANS)/xccdf2table-profileccirefs.xslt $< xsltproc -stringparam overlay "../$(IN)/auxiliary/stig_overlay.xml" -o $(OUT)/unlinked-stig-$(PROD)-xccdf.xml \ $(TRANS)/xccdf-apply-overlay-stig.xslt $< xsltproc -o $(OUT)/table-$(PROD)-stig.html $(TRANS)/xccdf2table-stig.xslt $(OUT)/unlinked-stig-$(PROD)-xccdf.xml tables: table-refs table-idents table-stigs #tables: table-refs table-idents table-srgmap table-stigs content: $(OUT)/xccdf-unlinked-final.xml checks cp $< $(OUT)/unlinked-$(PROD)-xccdf.xml # Remove auxiliary Groups which are only for use in tables, and not guide output. xsltproc -o $(OUT)/unlinked-$(PROD)-xccdf-guide.xml $(TRANS)/xccdf-removeaux.xslt $(OUT)/unlinked-$(PROD)-xccdf.xml # The relabel-ids.py script chdirs to ./output, so refer to files from there. # its second argument controls the IDs, as well as the output filenames. # thus, with ID set to ssg, this creates ssg-$(PROD)-xccdf.xml and ssg-$(PROD)-oval.xml. $(SHARED)/$(UTILS)/cpe-generate.py $(OUT)/unlinked-$(PROD)-oval.xml $(IN)/oval/platform/$(PROD)-cpe-dictionary.xml $(ID) $(SHARED)/$(UTILS)/relabel-ids.py unlinked-$(PROD)-xccdf.xml $(ID) $(SHARED)/$(UTILS)/relabel-ids.py xccdf-unlinked-ocilrefs.xml $(ID) # Once things are relabelled, create a datastream xsltproc --stringparam reverse_DNS org.$(VENDOR).content /usr/share/openscap/xsl/xccdf_1.1_to_1.2.xsl \ $(OUT)/$(ID)-$(PROD)-xccdf.xml > $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml # Update @style attribute of to "SCAP_1.2". Fixes #1059 sed -i 's/style="SCAP_1.1"/style="SCAP_1.2"/' $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml oscap ds sds-compose $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml $(OUT)/$(ID)-$(PROD)-ds.xml # Update @schematron-version attribute in datastream to "1.2". Fixes #1191 # (Workaround for https://github.com/OpenSCAP/openscap/issues/383) sed -i 's/schematron-version="[0-9].[0-9]"/schematron-version="1.2"/' $(OUT)/$(ID)-$(PROD)-ds.xml # Add in CPE and OVAL content to datastream oscap ds sds-add $(OUT)/$(ID)-$(PROD)-cpe-dictionary.xml $(OUT)/$(ID)-$(PROD)-ds.xml oscap ds sds-add $(OUT)/$(ID)-$(PROD)-oval.xml $(OUT)/$(ID)-$(PROD)-ds.xml # Fixes https://github.com/OpenSCAP/scap-security-guide/issues/1100 # Fixes https://github.com/OpenSCAP/scap-security-guide/issues/1101 $(SHARED)/$(UTILS)/sds-move-ocil-to-checks.py $(OUT)/$(ID)-$(PROD)-ds.xml $(OUT)/$(ID)-$(PROD)-ds.xml content-stig: table-stigs guide checks xmllint --format --output $(OUT)/unlinked-stig-$(PROD)-xccdf.xml $(OUT)/unlinked-stig-$(PROD)-xccdf.xml $(SHARED)/$(UTILS)/cpe-generate.py $(OUT)/unlinked-$(PROD)-oval.xml $(IN)/oval/platform/$(PROD)-cpe-dictionary.xml disa-predraft $(SHARED)/$(UTILS)/relabel-ids.py unlinked-stig-$(PROD)-xccdf.xml disa-predraft xmllint --format --output $(OUT)/disa-predraft-stig-$(PROD)-xccdf.xml $(OUT)/disa-predraft-stig-$(PROD)-xccdf.xml guide: content ifeq ($(OPENSCAP_1_1_OR_LATER), 0) $(SHARED)/$(UTILS)/build-all-guides.py --input $(OUT)/$(ID)-$(PROD)-ds.xml else @echo "Building guides from XCCDF 1.1, use OpenSCAP 1.1.0 or later for guides from datastreams!" $(SHARED)/$(UTILS)/build-all-guides.py --input $(OUT)/$(ID)-$(PROD)-xccdf.xml endif submission-stig-check: table-stigs cd $(OUT); ../$(SHARED)/$(UTILS)/verify-references.py -p stig-$(PROD)-upstream \ --rules-with-disarefs-outside-profile unlinked-$(PROD)-xccdf-prerefs.xml # $(TRANS)/xccdf2csv-stig.py $(OUT)/unlinked-stig-$(PROD)-xccdf.xml > $(OUT)/table-stig.csv # content-usgcb: coming soon validate-xml: oscap xccdf validate-xml $(OUT)/$(ID)-$(PROD)-xccdf.xml oscap oval validate-xml --schematron $(OUT)/$(ID)-$(PROD)-oval.xml oscap cpe validate-xml $(OUT)/$(ID)-$(PROD)-cpe-dictionary.xml oscap oval validate-xml --schematron $(OUT)/$(ID)-$(PROD)-cpe-oval.xml oscap ds sds-validate $(OUT)/$(ID)-$(PROD)-ds.xml validate: validate-xml cd $(OUT); ../$(SHARED)/$(UTILS)/verify-references.py --rules-with-invalid-checks --ovaldefs-unused ssg-$(PROD)-xccdf.xml # Items in dist are expected for distribution in an rpm dist: tables guide content mkdir -p $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-xccdf.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-oval.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-ocil.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-cpe-dictionary.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-cpe-oval.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-ds.xml $(DIST)/content mkdir -p $(DIST)/guide cp $(OUT)/*-guide-*.html $(DIST)/guide clean: rm -rf $(OUT)/* rm -rf $(DIST)/content $(DIST)/guide rm -rf $(BUILD) scap-security-guide-0.1.31/Firefox/input/000077500000000000000000000000001301675746700202435ustar00rootroot00000000000000scap-security-guide-0.1.31/Firefox/input/auxiliary/000077500000000000000000000000001301675746700222525ustar00rootroot00000000000000scap-security-guide-0.1.31/Firefox/input/auxiliary/DISCLAIMER000066400000000000000000000020001301675746700236010ustar00rootroot00000000000000The upstream STIG for the Mozilla Firefox profile "stig-firefox-upstream" is developed under the DoD consensus model and DISA FSO Vendor STIG process, serving as the upstream development environment for the Mozilla Firefox STIG. As a result of the upstream/downstream relationship between the SCAP Security Guide project and the official DISA FSO STIG baseline, users should expect variance between SSG and DISA FSO content. For official DISA FSO STIG content, refer to http://iase.disa.mil/stigs/app-security/browser-guidance/Pages/index.aspx. While this profile is packaged by Red Hat as part of the SCAP Security Guide package, please note that commercial support of this SCAP content is NOT available. This profile is provided as example SCAP content with no endorsement for suitability or production readiness. Support for this profile is provided by the upstream SCAP Security Guide community on a best-effort basis. The upstream project homepage is https://www.open-scap.org/security-policies/scap-security-guide/. scap-security-guide-0.1.31/Firefox/input/auxiliary/stig_overlay.xml000066400000000000000000000156061301675746700255130ustar00rootroot00000000000000 Installed version of Firefox unsupported. The Firefox SSLV2 parameter is configured to allow use of SSL 2.0. The Firefox browser home page is not set to blank or a trusted site. Firefox is configured to allow use of SSL 3.0. Firefox is not configured to allow use of TLS 1.0. FireFox is configured to ask which certificate to present to a web site when a certificate is required. Firefox required security preferences can not be changed by user. Firefox application is set to auto-update. Firefox automatically checks for updated version of installed Search plugins. Firefox automatically updates installed add-ons and plugins. Firefox automatically executes or downloads MIME types which are not authorized for auto-download. Network shell protocol is enabled in FireFox. Firefox not configured to prompt user before download and opening for required file types. FireFox plug-in for ActiveX controls is installed. Firefox is not configured to provide warnings when a user switches from a secure (SSL-enabled) to a non-secure page. Firefox formfill assistance option is disabled. Firefox is configured to autofill passwords. FireFox is configured to use a password store with or without a master password. Firefox does not clear cookies upon closing. FireFox is not configured to block pop-up windows. FireFox is configured to allow JavaScript to move or resize windows. Firefox is configured to allow JavaScript to raise or lower windows. Firefox is must be configured to prevent JavaScript from disable or replace context menus. Firefox is configured to allow JavaScript to hide or change the status bar. Firefox is configured to allow JavaScript to change the status bar text. The DOD Root Certificate is not installed. scap-security-guide-0.1.31/Firefox/input/guide.xslt000066400000000000000000000035761301675746700222670ustar00rootroot00000000000000 A conditional clause for check statements. A conditional clause for check statements. This is a placeholder. scap-security-guide-0.1.31/Firefox/input/oval/000077500000000000000000000000001301675746700212045ustar00rootroot00000000000000scap-security-guide-0.1.31/Firefox/input/oval/firefox_preferences-addons_plugin_updates.xml000066400000000000000000000024011301675746700323170ustar00rootroot00000000000000 Disable Addons Plugin Updates Mozilla Firefox Firefox automatically updates installed add-ons and plugins. ^\/usr\/(|local\/)lib(|64)\/firefox ^.*\.cfg$ ^lockPref\("extensions.update.enabled",[\s]+false\);$ 1 scap-security-guide-0.1.31/Firefox/input/oval/firefox_preferences-auto-download_actions.xml000066400000000000000000000025161301675746700322500ustar00rootroot00000000000000 Disable Automatic Downloads of MIME Types Mozilla Firefox Firefox automatically executes or downloads MIME types which are not authorized for auto-download. ^\/usr\/(|local\/)lib(|64)\/firefox ^.*\.cfg$ ^lockPref\("browser.helperApps.alwaysAsk.force",[\s]+true\);$ 1 scap-security-guide-0.1.31/Firefox/input/oval/firefox_preferences-auto-update_of_firefox.xml000066400000000000000000000024071301675746700324100ustar00rootroot00000000000000 Disable Firefox Auto-Update Capability Mozilla Firefox Firefox should not be able to automatically update itself. ^\/usr\/(|local\/)lib(|64)\/firefox ^.*\.cfg$ ^lockPref\("app.update.enabled",[\s]+false\);$ 1 scap-security-guide-0.1.31/Firefox/input/oval/firefox_preferences-autofill_forms.xml000066400000000000000000000023021301675746700307710ustar00rootroot00000000000000 Disable Autofill Form Assistance Mozilla Firefox Firefox formfill assistance option is disabled. ^\/usr\/(|local\/)lib(|64)\/firefox ^.*\.cfg$ ^lockPref\("browser.formfill.enable",[\s]+false\);$ 1 scap-security-guide-0.1.31/Firefox/input/oval/firefox_preferences-autofill_passwords.xml000066400000000000000000000023551301675746700317000ustar00rootroot00000000000000 Disable User Ability To Autofill Passwords Mozilla Firefox Firefox should not be configured to autofill passwords. ^\/usr\/(|local\/)lib(|64)\/firefox ^.*\.cfg$ ^lockPref\("signon.prefillForms",[\s]+false\);$ 1 scap-security-guide-0.1.31/Firefox/input/oval/firefox_preferences-cookies_clear.xml000066400000000000000000000026361301675746700305600ustar00rootroot00000000000000 Clear Cookies And Other Data When Firefox Closes Mozilla Firefox Set browser preferences to perform a Clear Private Data operation when closing the browser in order to clear cookies and other data installed by websites visited during the session. ^\/usr\/(|local\/)lib(|64)\/firefox ^.*\.cfg$ ^lockPref\("privacy.sanitize.sanitizeOnShutdown",[\s]+true\);$ 1 scap-security-guide-0.1.31/Firefox/input/oval/firefox_preferences-cookies_user_notice.xml000066400000000000000000000025011301675746700320000ustar00rootroot00000000000000 Disable User Prompt For Clearing Cookies And Other Data Mozilla Firefox Users should not be prompted about data and cookies being cleared when the browser is closed. ^\/usr\/(|local\/)lib(|64)\/firefox ^.*\.cfg$ ^lockPref\("privacy.sanitize.promptOnSanitize",[\s]+false\);$ 1 scap-security-guide-0.1.31/Firefox/input/oval/firefox_preferences-home_page.xml000066400000000000000000000031311301675746700276710ustar00rootroot00000000000000 Default Firefox Home Page Configured Mozilla Firefox The default homepage for Firefox is set and cannot be changed. ^\/usr\/(|local\/)lib(|64)\/firefox ^.*\.cfg$ ^lockPref\("browser.startup.homepage",[\s]+"(\S+)"\);$ 1 scap-security-guide-0.1.31/Firefox/input/oval/firefox_preferences-javascript_context_menus.xml000066400000000000000000000025101301675746700330660ustar00rootroot00000000000000 Disable JavaScript Context Menus Mozilla Firefox Firefox should be configured to not allow JavaScript to disable or replace context menus. ^\/usr\/(|local\/)lib(|64)\/firefox ^.*\.cfg$ ^lockPref\("dom.event.contextmenu.enabled",[\s]+false\);$ 1 scap-security-guide-0.1.31/Firefox/input/oval/firefox_preferences-javascript_status_bar_changes.xml000066400000000000000000000025731301675746700340430ustar00rootroot00000000000000 Disable JavaScript's Ability To Change The Status Bar Mozilla Firefox Firefox should be configured to not allow JavaScript to hide or change the status bar. ^\/usr\/(|local\/)lib(|64)\/firefox ^.*\.cfg$ ^lockPref\("dom.disable_window_status_change",[\s]+true\);$ 1 scap-security-guide-0.1.31/Firefox/input/oval/firefox_preferences-javascript_status_bar_text.xml000066400000000000000000000025611301675746700334140ustar00rootroot00000000000000 Disable JavaScript's Ability To Modify The Browser Appearance Mozilla Firefox Firefox should be configured not to allow JavaScript to change the status bar text. ^\/usr\/(|local\/)lib(|64)\/firefox ^.*\.cfg$ ^lockPref\("dom.disable_window_open_feature.status",[\s]+true\);$ 1 scap-security-guide-0.1.31/Firefox/input/oval/firefox_preferences-javascript_window_changes.xml000066400000000000000000000024741301675746700332030ustar00rootroot00000000000000 Disable JavaScript's Raise Or Lower Windows Capability Mozilla Firefox Firefox should be configured to not allow JavaScript to raise or lower windows. ^\/usr\/(|local\/)lib(|64)\/firefox ^.*\.cfg$ ^lockPref\("dom.disable_window_flip",[\s]+true\);$ 1 scap-security-guide-0.1.31/Firefox/input/oval/firefox_preferences-javascript_window_resizing.xml000066400000000000000000000025261301675746700334230ustar00rootroot00000000000000 Disable JavaScript's Moving Or Resizing Windows Capability Mozilla Firefox FireFox should not be configured to allow JavaScript to move or resize windows. ^\/usr\/(|local\/)lib(|64)\/firefox ^.*\.cfg$ ^lockPref\("dom.disable_window_move_resize",[\s]+true\);$ 1 scap-security-guide-0.1.31/Firefox/input/oval/firefox_preferences-lock_settings_config_file.xml000066400000000000000000000025311301675746700331440ustar00rootroot00000000000000 Prevent Users from Changing Firefox Configuration Settings Mozilla Firefox Locked settings prevents users from accessing about:config and changing the security settings set by the system administrator. ^\/usr\/(|local\/)lib(|64)\/firefox\/defaults\/preferences ^.*\.js$ ^pref\("general.config.filename",[\s]+"(\S+)\.cfg"\);$ 1 scap-security-guide-0.1.31/Firefox/input/oval/firefox_preferences-lock_settings_obscure.xml000066400000000000000000000025221301675746700323420ustar00rootroot00000000000000 Prevent Users from Changing Firefox Configuration Settings Mozilla Firefox Locked settings prevents users from accessing about:config and changing the security settings set by the system administrator. ^\/usr\/(|local\/)lib(|64)\/firefox\/defaults\/preferences ^.*\.js$ ^pref\("general.config.obscure_value",[\s]+0\);$ 1 scap-security-guide-0.1.31/Firefox/input/oval/firefox_preferences-non-secure_page_warning.xml000066400000000000000000000025211301675746700325460ustar00rootroot00000000000000 Enable Non-Secure Page Warnings Mozilla Firefox Firefox is not configured to provide warnings when a user switches from a secure (SSL-enabled) to a non-secure page. ^\/usr\/(|local\/)lib(|64)\/firefox ^.*\.cfg$ ^lockPref\("security.warn_leaving_secure",[\s]+true\);$ 1 scap-security-guide-0.1.31/Firefox/input/oval/firefox_preferences-open_confirmation.xml000066400000000000000000000033151301675746700314620ustar00rootroot00000000000000 Enable Downloading and Opening File Confirmation Mozilla Firefox Firefox is not configured to prompt user before downloading and opening required file types. ^\/usr\/(|local\/)lib(|64)\/firefox ^.*\.cfg$ ^lockPref\("plugin.disable_full_page_plugin_for_types",[\s]+"(\S+)"\);$ 1 scap-security-guide-0.1.31/Firefox/input/oval/firefox_preferences-password_store.xml000066400000000000000000000023141301675746700310250ustar00rootroot00000000000000 Disable the Firefox Password Store Mozilla Firefox The Firefox password store should be disabled. ^\/usr\/(|local\/)lib(|64)\/firefox ^.*\.cfg$ ^lockPref\("signon.rememberSignons",[\s]+false\);$ 1 scap-security-guide-0.1.31/Firefox/input/oval/firefox_preferences-pop-up_windows.xml000066400000000000000000000024651301675746700307500ustar00rootroot00000000000000 Enable Firefox Pop-up Blocker Mozilla Firefox The Firefox Pop-up blocker should be enabled as windows may be used to launch an attack within a new browser window with altered settings. ^\/usr\/(|local\/)lib(|64)\/firefox ^.*\.cfg$ ^lockPref\("dom.disable_window_open_feature.status",[\s]+true\);$ 1 scap-security-guide-0.1.31/Firefox/input/oval/firefox_preferences-search_update.xml000066400000000000000000000025341301675746700305620ustar00rootroot00000000000000 Disable Installed Search Plugins Update Checking Mozilla Firefox Search plugins can be automatically configured to check for updates. Updates need to be controlled and installed from authorized and trusted servers. ^\/usr\/(|local\/)lib(|64)\/firefox ^.*\.cfg$ ^lockPref\("browser.search.update",[\s]+false\);$ 1 scap-security-guide-0.1.31/Firefox/input/oval/firefox_preferences-shell_protocol.xml000066400000000000000000000025311301675746700310000ustar00rootroot00000000000000 Disable Firefox Access to Shell Protocols Mozilla Firefox Firefox can be configured to access systems shells which could potentially allow Firefox and other users to access to the underlying system. ^\/usr\/(|local\/)lib(|64)\/firefox ^.*\.cfg$ ^lockPref\("network.protocol-handler.external.shell",[\s]+false\);$ 1 scap-security-guide-0.1.31/Firefox/input/oval/firefox_preferences-ssl_protocol_tls.xml000066400000000000000000000023431301675746700313550ustar00rootroot00000000000000 Enable TLS Usage in Firefox Mozilla Firefox DoD implementations of SSL must use TLS 1.0 in accordance with the Network Infrastructure STIG. ^\/usr\/(|local\/)lib(|64)\/firefox ^.*\.cfg$ ^lockPref\("security.enable_tls",[\s]+true\);$ 1 scap-security-guide-0.1.31/Firefox/input/oval/firefox_preferences-ssl_version_2.xml000066400000000000000000000023571301675746700305450ustar00rootroot00000000000000 Disable SSL Version 2.0 in Firefox Mozilla Firefox SSL 2.0 and SSL 3.0 contain a number of security flaws. Therefore, SSL 2.0 should be disabled. ^\/usr\/(|local\/)lib(|64)\/firefox ^.*\.cfg$ ^lockPref\("security.enable_ssl2",[\s]+false\);$ 1 scap-security-guide-0.1.31/Firefox/input/oval/firefox_preferences-ssl_version_3.xml000066400000000000000000000023551301675746700305440ustar00rootroot00000000000000 Disable SSL Version 3 in Firefox Mozilla Firefox Earlier versions of SSL have known security vulnerabilities and are not authorized for use in DOD. ^\/usr\/(|local\/)lib(|64)\/firefox ^.*\.cfg$ ^lockPref\("security.enable_ssl3",[\s]+false\);$ 1 scap-security-guide-0.1.31/Firefox/input/oval/firefox_preferences-verification.xml000066400000000000000000000027431301675746700304370ustar00rootroot00000000000000 Enable Certificate Verification Mozilla Firefox When a web site asks for a certificate for user authentication, Firefox must be configured to have the user choose which certificate to present. Websites within DOD require user authentication for access which increases security for DoD information. Access will be denied to the user if certificate management is not configured ^\/usr\/(|local\/)lib(|64)\/firefox ^.*\.cfg$ ^lockPref\("security.default_personal_cert",[\s]+"Ask Every Time"\);$ 1 scap-security-guide-0.1.31/Firefox/input/oval/installed_OS_is_part_of_Unix_family.xml000066400000000000000000000020171301675746700310570ustar00rootroot00000000000000 Installed operating system is part of the Unix family Mozilla Firefox The operating system installed on the system is part of the Unix OS family unix scap-security-guide-0.1.31/Firefox/input/oval/installed_app_is_firefox.xml000066400000000000000000000020001301675746700267520ustar00rootroot00000000000000 Mozilla Firefox Mozilla Firefox The application installed on the system is firefox. firefox scap-security-guide-0.1.31/Firefox/input/oval/installed_firefox_version_supported.xml000066400000000000000000000026311301675746700313030ustar00rootroot00000000000000 Supported Version of Firefox Installed Mozilla Firefox Use of versions of an application which are not supported by the vendor are not permitted. Vendors respond to security flaws with updates and patches. These updates are not available for unsupported versions which can leave the application vulnerable to attack. 3.0.0 firefox scap-security-guide-0.1.31/Firefox/input/oval/platform/000077500000000000000000000000001301675746700230305ustar00rootroot00000000000000scap-security-guide-0.1.31/Firefox/input/oval/platform/firefox-cpe-dictionary.xml000066400000000000000000000012101301675746700301160ustar00rootroot00000000000000 Mozilla Firefox installed_app_is_firefox scap-security-guide-0.1.31/Firefox/input/oval/testoval.py000077500000000000000000000003471301675746700234260ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import testoval_module if __name__ == "__main__": testoval_module.main() scap-security-guide-0.1.31/Firefox/input/profiles/000077500000000000000000000000001301675746700220665ustar00rootroot00000000000000scap-security-guide-0.1.31/Firefox/input/profiles/stig-firefox-upstream.xml000066400000000000000000000064531301675746700270640ustar00rootroot00000000000000 Upstream Firefox STIG This profile is developed under the DoD consensus model and DISA FSO Vendor STIG process, serving as the upstream development environment for the Firefox STIG. As a result of the upstream/downstream relationship between the SCAP Security Guide project and the official DISA FSO STIG baseline, users should expect variance between SSG and DISA FSO content. For official DISA FSO STIG content, refer to http://iase.disa.mil/stigs/app-security/browser-guidance/Pages/index.aspx. While this profile is packaged by Red Hat as part of the SCAP Security Guide package, please note that commercial support of this SCAP content is NOT available. This profile is provided as example SCAP content with no endorsement for suitability or production readiness. Support for this profile is provided by the upstream SCAP Security Guide community on a best-effort basis. The upstream project homepage is https://www.open-scap.org/security-policies/scap-security-guide/. scap-security-guide-0.1.31/Firefox/templates/000077500000000000000000000000001301675746700211025ustar00rootroot00000000000000scap-security-guide-0.1.31/Firefox/templates/static/000077500000000000000000000000001301675746700223715ustar00rootroot00000000000000scap-security-guide-0.1.31/Firefox/templates/static/bash/000077500000000000000000000000001301675746700233065ustar00rootroot00000000000000firefox_preferences-addons_plugin_updates.sh000066400000000000000000000002301301675746700341520ustar00rootroot00000000000000scap-security-guide-0.1.31/Firefox/templates/static/bash# platform = Mozilla Firefox . /usr/share/scap-security-guide/remediation_functions firefox_cfg_setting "stig.cfg" "extensions.update.enabled" "false" firefox_preferences-auto-download_actions.sh000066400000000000000000000002401301675746700340750ustar00rootroot00000000000000scap-security-guide-0.1.31/Firefox/templates/static/bash# platform = Mozilla Firefox . /usr/share/scap-security-guide/remediation_functions firefox_cfg_setting "stig.cfg" "browser.helperApps.alwaysAsk.force" "true" firefox_preferences-auto-update_of_firefox.sh000066400000000000000000000002561301675746700342450ustar00rootroot00000000000000scap-security-guide-0.1.31/Firefox/templates/static/bash# platform = Mozilla Firefox # platform = Mozilla Firefox . /usr/share/scap-security-guide/remediation_functions firefox_cfg_setting "stig.cfg" "app.update.enabled" "false" scap-security-guide-0.1.31/Firefox/templates/static/bash/firefox_preferences-autofill_forms.sh000066400000000000000000000002261301675746700327100ustar00rootroot00000000000000# platform = Mozilla Firefox . /usr/share/scap-security-guide/remediation_functions firefox_cfg_setting "stig.cfg" "browser.formfill.enable" "false" scap-security-guide-0.1.31/Firefox/templates/static/bash/firefox_preferences-autofill_passwords.sh000066400000000000000000000002221301675746700336030ustar00rootroot00000000000000# platform = Mozilla Firefox . /usr/share/scap-security-guide/remediation_functions firefox_cfg_setting "stig.cfg" "signon.prefillForms" "false" scap-security-guide-0.1.31/Firefox/templates/static/bash/firefox_preferences-cookies_clear.sh000066400000000000000000000002411301675746700324620ustar00rootroot00000000000000# platform = Mozilla Firefox . /usr/share/scap-security-guide/remediation_functions firefox_cfg_setting "stig.cfg" "privacy.sanitize.sanitizeOnShutdown" "true" scap-security-guide-0.1.31/Firefox/templates/static/bash/firefox_preferences-cookies_user_notice.sh000066400000000000000000000002401301675746700337120ustar00rootroot00000000000000# platform = Mozilla Firefox . /usr/share/scap-security-guide/remediation_functions firefox_cfg_setting "stig.cfg" "privacy.sanitize.promptOnSanitize" "false" scap-security-guide-0.1.31/Firefox/templates/static/bash/firefox_preferences-enable_ca_trust.sh000066400000000000000000000004301301675746700330120ustar00rootroot00000000000000# platform = Mozilla Firefox P11=$(readlink /etc/alternatives/libnssckbi.so*) P11LIB="/usr/lib/pkcs11/p11-kit-trust.so" P11LIB64="/usr/lib64/pkcs11/p11-kit-trust.so" if ! [[ ${P11} == "${P11LIB64}" ]] || ! [[ ${P11} == "${P11LIB}" ]] ; then /usr/bin/update-ca-trust enable fi scap-security-guide-0.1.31/Firefox/templates/static/bash/firefox_preferences-home_page.sh000066400000000000000000000003151301675746700316060ustar00rootroot00000000000000# platform = Mozilla Firefox . /usr/share/scap-security-guide/remediation_functions populate var_default_home_page firefox_cfg_setting "stig.cfg" "browser.startup.homepage" "\"${var_default_home_page}\"" firefox_preferences-javascript_context_menus.sh000066400000000000000000000002341301675746700347240ustar00rootroot00000000000000scap-security-guide-0.1.31/Firefox/templates/static/bash# platform = Mozilla Firefox . /usr/share/scap-security-guide/remediation_functions firefox_cfg_setting "stig.cfg" "dom.event.contextmenu.enabled" "false" firefox_preferences-javascript_status_bar_changes.sh000066400000000000000000000002361301675746700356720ustar00rootroot00000000000000scap-security-guide-0.1.31/Firefox/templates/static/bash# platform = Mozilla Firefox . /usr/share/scap-security-guide/remediation_functions firefox_cfg_setting "stig.cfg" "dom.disable_window_status_change" "true" firefox_preferences-javascript_status_bar_text.sh000066400000000000000000000002441301675746700352450ustar00rootroot00000000000000scap-security-guide-0.1.31/Firefox/templates/static/bash# platform = Mozilla Firefox . /usr/share/scap-security-guide/remediation_functions firefox_cfg_setting "stig.cfg" "dom.disable_window_open_feature.status" "true" firefox_preferences-javascript_window_changes.sh000066400000000000000000000002251301675746700350300ustar00rootroot00000000000000scap-security-guide-0.1.31/Firefox/templates/static/bash# platform = Mozilla Firefox . /usr/share/scap-security-guide/remediation_functions firefox_cfg_setting "stig.cfg" "dom.disable_window_flip" "true" firefox_preferences-javascript_window_resizing.sh000066400000000000000000000002341301675746700352520ustar00rootroot00000000000000scap-security-guide-0.1.31/Firefox/templates/static/bash# platform = Mozilla Firefox . /usr/share/scap-security-guide/remediation_functions firefox_cfg_setting "stig.cfg" "dom.disable_window_move_resize" "true" firefox_preferences-lock_settings_config_file.sh000066400000000000000000000002441301675746700350000ustar00rootroot00000000000000scap-security-guide-0.1.31/Firefox/templates/static/bash# platform = Mozilla Firefox . /usr/share/scap-security-guide/remediation_functions firefox_js_setting "stig_settings.js" "general.config.filename" "\"stig.cfg\"" firefox_preferences-lock_settings_obscure.sh000066400000000000000000000002361301675746700341770ustar00rootroot00000000000000scap-security-guide-0.1.31/Firefox/templates/static/bash# platform = Mozilla Firefox . /usr/share/scap-security-guide/remediation_functions firefox_js_setting "stig_settings.js" "general.config.obscure_value" "0" firefox_preferences-non-secure_page_warning.sh000066400000000000000000000002321301675746700344000ustar00rootroot00000000000000scap-security-guide-0.1.31/Firefox/templates/static/bash# platform = Mozilla Firefox . /usr/share/scap-security-guide/remediation_functions firefox_cfg_setting "stig.cfg" "security.warn_leaving_secure" "true" scap-security-guide-0.1.31/Firefox/templates/static/bash/firefox_preferences-open_confirmation.sh000066400000000000000000000003421301675746700333730ustar00rootroot00000000000000# platform = Mozilla Firefox . /usr/share/scap-security-guide/remediation_functions populate var_required_file_types firefox_cfg_setting "stig.cfg" "plugin.disable_full_page_plugin_for_types" "\"${var_required_file_types}\"" scap-security-guide-0.1.31/Firefox/templates/static/bash/firefox_preferences-password_store.sh000066400000000000000000000002251301675746700327400ustar00rootroot00000000000000# platform = Mozilla Firefox . /usr/share/scap-security-guide/remediation_functions firefox_cfg_setting "stig.cfg" "signon.rememberSignons" "false" scap-security-guide-0.1.31/Firefox/templates/static/bash/firefox_preferences-pop-up_windows.sh000066400000000000000000000002441301675746700326550ustar00rootroot00000000000000# platform = Mozilla Firefox . /usr/share/scap-security-guide/remediation_functions firefox_cfg_setting "stig.cfg" "dom.disable_window_open_feature.status" "true" scap-security-guide-0.1.31/Firefox/templates/static/bash/firefox_preferences-search_update.sh000066400000000000000000000002241301675746700324700ustar00rootroot00000000000000# platform = Mozilla Firefox . /usr/share/scap-security-guide/remediation_functions firefox_cfg_setting "stig.cfg" "browser.search.update" "false" scap-security-guide-0.1.31/Firefox/templates/static/bash/firefox_preferences-shell_protocol.sh000066400000000000000000000002461301675746700327150ustar00rootroot00000000000000# platform = Mozilla Firefox . /usr/share/scap-security-guide/remediation_functions firefox_cfg_setting "stig.cfg" "network.protocol-handler.external.shell" "false" scap-security-guide-0.1.31/Firefox/templates/static/bash/firefox_preferences-ssl_protocol_tls.sh000066400000000000000000000002211301675746700332620ustar00rootroot00000000000000# platform = Mozilla Firefox . /usr/share/scap-security-guide/remediation_functions firefox_cfg_setting "stig.cfg" "security.enable_tls" "true" scap-security-guide-0.1.31/Firefox/templates/static/bash/firefox_preferences-ssl_version_2.sh000066400000000000000000000002231301675746700324470ustar00rootroot00000000000000# platform = Mozilla Firefox . /usr/share/scap-security-guide/remediation_functions firefox_cfg_setting "stig.cfg" "security.enable_ssl2" "false" scap-security-guide-0.1.31/Firefox/templates/static/bash/firefox_preferences-ssl_version_3.sh000066400000000000000000000002231301675746700324500ustar00rootroot00000000000000# platform = Mozilla Firefox . /usr/share/scap-security-guide/remediation_functions firefox_cfg_setting "stig.cfg" "security.enable_ssl3" "false" scap-security-guide-0.1.31/Firefox/templates/static/bash/firefox_preferences-verification.sh000066400000000000000000000002521301675746700323440ustar00rootroot00000000000000# platform = Mozilla Firefox . /usr/share/scap-security-guide/remediation_functions firefox_cfg_setting "stig.cfg" "security.default_personal_cert" "\"Ask Every Time\"" scap-security-guide-0.1.31/Firefox/transforms/000077500000000000000000000000001301675746700213025ustar00rootroot00000000000000scap-security-guide-0.1.31/Firefox/transforms/cce_extract.py000077500000000000000000000003521301675746700241430ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import cce_extract_module if __name__ == "__main__": cce_extract_module.main() scap-security-guide-0.1.31/Firefox/transforms/cci2html.xsl000066400000000000000000000004661301675746700235450ustar00rootroot00000000000000 scap-security-guide-0.1.31/Firefox/transforms/constants.xslt000066400000000000000000000020701301675746700242310ustar00rootroot00000000000000 Firefox Firefox FIREFOX_STIG firefox empty FIREFOX cpe:/a:mozilla:firefox scap-security-guide-0.1.31/Firefox/transforms/shorthand2xccdf.xslt000066400000000000000000000005141301675746700253020ustar00rootroot00000000000000 unknown unlinked-firefox-oval.xml scap-security-guide-0.1.31/Firefox/transforms/splitchecks.py000077500000000000000000000003521301675746700241730ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import splitchecks_module if __name__ == "__main__": splitchecks_module.main() scap-security-guide-0.1.31/Firefox/transforms/table-add-srgitems.xslt000066400000000000000000000010751301675746700256710ustar00rootroot00000000000000 scap-security-guide-0.1.31/Firefox/transforms/table-sortbyref.xslt000066400000000000000000000005551301675746700253270ustar00rootroot00000000000000 scap-security-guide-0.1.31/Firefox/transforms/table-srgmap.xslt000066400000000000000000000011401301675746700245700ustar00rootroot00000000000000 scap-security-guide-0.1.31/Firefox/transforms/table-style.xslt000066400000000000000000000002511301675746700244410ustar00rootroot00000000000000 scap-security-guide-0.1.31/Firefox/transforms/xccdf-alt-titles.xslt000066400000000000000000000005021301675746700253620ustar00rootroot00000000000000 scap-security-guide-0.1.31/Firefox/transforms/xccdf-apply-overlay-stig.xslt000066400000000000000000000007511301675746700270560ustar00rootroot00000000000000 scap-security-guide-0.1.31/Firefox/transforms/xccdf-removeaux.xslt000066400000000000000000000005011301675746700253120ustar00rootroot00000000000000 scap-security-guide-0.1.31/Firefox/transforms/xccdf2csv-stig.py000077500000000000000000000003601301675746700245070ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import xccdf2csv_stig_module if __name__ == "__main__": xccdf2csv_stig_module.main() scap-security-guide-0.1.31/Firefox/transforms/xccdf2html.xslt000066400000000000000000000005501301675746700242540ustar00rootroot00000000000000 scap-security-guide-0.1.31/Firefox/transforms/xccdf2shorthand.xslt000066400000000000000000000005011301675746700252760ustar00rootroot00000000000000 scap-security-guide-0.1.31/Firefox/transforms/xccdf2stigformat.xslt000066400000000000000000000006751301675746700254770ustar00rootroot00000000000000 scap-security-guide-0.1.31/Firefox/transforms/xccdf2table-byref.xslt000066400000000000000000000006741301675746700255130ustar00rootroot00000000000000 scap-security-guide-0.1.31/Firefox/transforms/xccdf2table-cce.xslt000066400000000000000000000007331301675746700251320ustar00rootroot00000000000000 scap-security-guide-0.1.31/Firefox/transforms/xccdf2table-profileccirefs.xslt000066400000000000000000000015731301675746700274020ustar00rootroot00000000000000 scap-security-guide-0.1.31/Firefox/transforms/xccdf2table-profilecisrefs.xslt000066400000000000000000000007051301675746700274160ustar00rootroot00000000000000 scap-security-guide-0.1.31/Firefox/transforms/xccdf2table-profilenistrefs.xslt000066400000000000000000000007051301675746700276150ustar00rootroot00000000000000 scap-security-guide-0.1.31/Firefox/transforms/xccdf2table-stig.xslt000066400000000000000000000006731301675746700253510ustar00rootroot00000000000000 scap-security-guide-0.1.31/Firefox/utils/000077500000000000000000000000001301675746700202445ustar00rootroot00000000000000scap-security-guide-0.1.31/Firefox/utils/README000066400000000000000000000010001301675746700211130ustar00rootroot00000000000000This file is meant to give a quick overview to some of the scripts located in this directory. verify-input-sanity.py Purpose: This script can be invoked without arguments to examine the files within src/input to make sure that they are in good shape *prior to* building the XCCDF and OVAL content with the various make commands. Intent: Help XCCDF and OVAL developers spot common mistakes *before* utilizing the Makefile to build the XCCDF and OVAL content. Usage: ./verify-input-sanity.py scap-security-guide-0.1.31/Firefox/utils/sync-alt-titles.py000077500000000000000000000003621301675746700236560ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import sync_alt_titles_module if __name__ == "__main__": sync_alt_titles_module.main() scap-security-guide-0.1.31/Firefox/utils/verify-cce.py000077500000000000000000000003501301675746700226530ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import verify_cce_module if __name__ == "__main__": verify_cce_module.main() scap-security-guide-0.1.31/JBoss/000077500000000000000000000000001301675746700165225ustar00rootroot00000000000000scap-security-guide-0.1.31/JBoss/EAP/000077500000000000000000000000001301675746700171275ustar00rootroot00000000000000scap-security-guide-0.1.31/JBoss/EAP/5/000077500000000000000000000000001301675746700172735ustar00rootroot00000000000000scap-security-guide-0.1.31/JBoss/EAP/5/Makefile000066400000000000000000000166171301675746700207460ustar00rootroot00000000000000all: tables guide content dist SHARED = ../../../shared include $(SHARED)/product-make.include PROD = eap5 VENDOR = ssgproject checks: standard-oval-build # example, if needed: for converting XCCDF into shorthand #xccdf2shorthand: # xsltproc -o $(XCCDF_OUTPUT_DIR)/$(PROD)-shorthand.xml $(TRANS)/xccdf2shorthand.xslt $(REFS)/usgcb-$(PROD)desktop-xccdf.xml # tidy -m -xml -utf8 --indent-spaces=0 $(XCCDF_OUTPUT_DIR)/$(PROD)-shorthand.xml table-refs: $(OUT)/xccdf-unlinked-empty-groups.xml xsltproc -stringparam ref "nist" -o $(OUT)/table-$(PROD)-nistrefs.html $(TRANS)/xccdf2table-byref.xslt $< xsltproc -stringparam ref "cis" -o $(OUT)/table-$(PROD)-cisrefs.html $(TRANS)/xccdf2table-byref.xslt $< xsltproc -stringparam profile "common" -o $(OUT)/table-$(PROD)-nistrefs-common.html \ $(TRANS)/xccdf2table-profilenistrefs.xslt $< table-idents: $(OUT)/xccdf-unlinked-empty-groups.xml xsltproc -o $(OUT)/table-$(PROD)-cces.html $(TRANS)/xccdf2table-cce.xslt $< table-srgmap: $(OUT)/xccdf-unlinked-empty-groups.xml # the map-to-items filename must be provided relative to the root of the main document being processed xsltproc -stringparam map-to-items "../$<" -o $(OUT)/table-$(PROD)-srgmap.html \ $(TRANS)/table-srgmap.xslt $(REFS)/disa-application-srg-v2r1.xml xsltproc -stringparam flat "y" -stringparam map-to-items "../$<" -o $(OUT)/table-$(PROD)-srgmap-flat.html \ $(TRANS)/table-srgmap.xslt $(REFS)/disa-application-srg-v2r1.xml xmllint --xmlout --html --output $(OUT)/table-$(PROD)-srgmap-flat.xhtml $(OUT)/table-$(PROD)-srgmap-flat.html table-stigs: $(OUT)/xccdf-unlinked-final.xml table-srgmap checks # xsltproc -o $(OUT)/table-firefox-stig.html $(TRANS)/xccdf2table-stig.xslt $(REFS)/disa-stig-firefox-v4r11-xccdf-manual.xml # xsltproc -o $(OUT)/table-firefox-stig-manual.html $(TRANS)/xccdf2table-stig.xslt $(REFS)/disa-stig-firefox-v4r11-xccdf-manual.xml # xsltproc -stringparam notes "../$(IN)/auxiliary/transition_notes.xml" -o $(OUT)/table-$(PROD)-stig-manual-withnotes.html \ # $(TRANS)/xccdf2table-stig.xslt \ # $(REFS)/disa-stig-$(PROD)-v1r0.6-xccdf-manual.xml # temporarily retain an output file showing the short titles as well xsltproc -stringparam profile "stig-$(PROD)-upstream" -stringparam testinfo "y" -o $(OUT)/table-stig-$(PROD)-testinfo.html \ $(TRANS)/xccdf2table-profileccirefs.xslt $< xsltproc -stringparam overlay "../$(IN)/auxiliary/stig_overlay.xml" -o $(OUT)/unlinked-stig-$(PROD)-xccdf.xml \ $(TRANS)/xccdf-apply-overlay-stig.xslt $< xsltproc -o $(OUT)/table-$(PROD)-stig.html $(TRANS)/xccdf2table-stig.xslt $(OUT)/unlinked-stig-$(PROD)-xccdf.xml tables: table-refs table-idents table-srgmap table-stigs content: $(OUT)/xccdf-unlinked-final.xml checks cp $< $(OUT)/unlinked-$(PROD)-xccdf.xml # Remove auxiliary Groups which are only for use in tables, and not guide output. xsltproc -o $(OUT)/unlinked-$(PROD)-xccdf-guide.xml $(TRANS)/xccdf-removeaux.xslt $(OUT)/unlinked-$(PROD)-xccdf.xml # The relabel-ids.py script chdirs to ./output, so refer to files from there. # Its second argument controls the IDs, as well as the output filenames. # Thus, with ID set to ssg, this creates ssg-$(PROD)-xccdf.xml and ssg-$(PROD)-oval.xml. $(SHARED)/$(UTILS)/cpe-generate.py $(OUT)/unlinked-$(PROD)-oval.xml $(IN)/oval/platform/$(PROD)-cpe-dictionary.xml $(ID) $(SHARED)/$(UTILS)/relabel-ids.py unlinked-$(PROD)-xccdf.xml $(ID) $(SHARED)/$(UTILS)/relabel-ids.py xccdf-unlinked-ocilrefs.xml $(ID) # Once things are relabelled, create a datastream xsltproc --stringparam reverse_DNS org.$(VENDOR).content /usr/share/openscap/xsl/xccdf_1.1_to_1.2.xsl \ $(OUT)/$(ID)-$(PROD)-xccdf.xml > $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml # Update @style attribute of to "SCAP_1.2". Fixes #1059 sed -i 's/style="SCAP_1.1"/style="SCAP_1.2"/' $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml oscap ds sds-compose $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml $(OUT)/$(ID)-$(PROD)-ds.xml # Update @schematron-version attribute in datastream to "1.2". Fixes #1191 # (Workaround for https://github.com/OpenSCAP/openscap/issues/383) sed -i 's/schematron-version="[0-9].[0-9]"/schematron-version="1.2"/' $(OUT)/$(ID)-$(PROD)-ds.xml # Add in CPE and OVAL content to datastream oscap ds sds-add $(OUT)/$(ID)-$(PROD)-cpe-dictionary.xml $(OUT)/$(ID)-$(PROD)-ds.xml oscap ds sds-add $(OUT)/$(ID)-$(PROD)-oval.xml $(OUT)/$(ID)-$(PROD)-ds.xml # Fixes https://github.com/OpenSCAP/scap-security-guide/issues/1100 # Fixes https://github.com/OpenSCAP/scap-security-guide/issues/1101 $(SHARED)/$(UTILS)/sds-move-ocil-to-checks.py $(OUT)/$(ID)-$(PROD)-ds.xml $(OUT)/$(ID)-$(PROD)-ds.xml content-stig: table-stigs guide checks xmllint --format --output $(OUT)/unlinked-stig-$(PROD)-xccdf.xml $(OUT)/unlinked-stig-$(PROD)-xccdf.xml $(SHARED)/$(UTILS)/cpe-generate.py $(OUT)/unlinked-$(PROD)-oval.xml $(IN)/oval/platform/$(PROD)-cpe-dictionary.xml disa-predraft $(SHARED)/$(UTILS)/relabel-ids.py unlinked-stig-$(PROD)-xccdf.xml disa-predraft xmllint --format --output $(OUT)/disa-predraft-stig-$(PROD)-xccdf.xml $(OUT)/disa-predraft-stig-$(PROD)-xccdf.xml guide: content ifeq ($(OPENSCAP_1_1_OR_LATER), 0) $(SHARED)/$(UTILS)/build-all-guides.py --input $(OUT)/$(ID)-$(PROD)-ds.xml else @echo "Building guides from XCCDF 1.1, use OpenSCAP 1.1.0 or later for guides from datastreams!" $(SHARED)/$(UTILS)/build-all-guides.py --input $(OUT)/$(ID)-$(PROD)-xccdf.xml endif submission-stig-check: table-stigs cd $(OUT); ../$(SHARED)/$(UTILS)/verify-references.py -p stig-$(PROD)-upstream \ --rules-with-disarefs-outside-profile unlinked-$(PROD)-xccdf-prerefs.xml # $(TRANS)/xccdf2csv-stig.py $(OUT)/unlinked-stig-$(PROD)-xccdf.xml > $(OUT)/table-stig.csv # content-usgcb: coming soon validate-xml: oscap xccdf validate-xml $(OUT)/$(ID)-$(PROD)-xccdf.xml oscap oval validate-xml --schematron $(OUT)/$(ID)-$(PROD)-oval.xml oscap cpe validate-xml $(OUT)/$(ID)-$(PROD)-cpe-dictionary.xml oscap oval validate-xml --schematron $(OUT)/$(ID)-$(PROD)-cpe-oval.xml oscap ds sds-validate $(OUT)/$(ID)-$(PROD)-ds.xml validate: validate-xml ifeq ($(OVAL_5_11), 0) cd $(OUT); ../$(SHARED)/$(UTILS)/verify-references.py --rules-with-invalid-checks --ovaldefs-unused $(ID)-$(PROD)-xccdf.xml else # If we are building against oscap version not supporting OVAL-5.11 language version yet, # don't call verify-references.py with "--rules-with-invalid-checks" argument, since the # OVAL checks using the 5.11 OVAL version will not be included in that case @echo -e "\nWarning:\n" @echo -e "\tJBoss content build using oscap not supporting OVAL-5.11 language version detected!" @echo -e "\tSince the OVAL-5.11 JBoss OVAL checks are missing, will skip test for referenced," @echo -e "\tbut undefined OVAL definitions during content validation. Consider building JBoss" @echo -e "\tcontent with version OpenSCAP-1.2.2, or newer in order to perform full content validation!\n" cd $(OUT); ../$(SHARED)/$(UTILS)/verify-references.py --ovaldefs-unused $(ID)-$(PROD)-xccdf.xml endif # Items in dist are expected for distribution in an rpm dist: tables guide content mkdir -p $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-xccdf.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-oval.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-ocil.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-cpe-dictionary.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-cpe-oval.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-ds.xml $(DIST)/content mkdir -p $(DIST)/guide cp $(OUT)/*-guide-*.html $(DIST)/guide clean: rm -rf $(OUT)/* rm -rf $(DIST)/content $(DIST)/guide rm -rf $(BUILD) scap-security-guide-0.1.31/JBoss/EAP/5/input/000077500000000000000000000000001301675746700204325ustar00rootroot00000000000000scap-security-guide-0.1.31/JBoss/EAP/5/input/auxiliary/000077500000000000000000000000001301675746700224415ustar00rootroot00000000000000scap-security-guide-0.1.31/JBoss/EAP/5/input/auxiliary/README000066400000000000000000000000331301675746700233150ustar00rootroot00000000000000Remove or update this file scap-security-guide-0.1.31/JBoss/EAP/5/input/guide.xslt000066400000000000000000000060321301675746700224440ustar00rootroot00000000000000 A conditional clause for check statements. A conditional clause for check statements. This is a placeholder. scap-security-guide-0.1.31/JBoss/EAP/5/input/oval/000077500000000000000000000000001301675746700213735ustar00rootroot00000000000000scap-security-guide-0.1.31/JBoss/EAP/5/input/oval/installed_app_is_eap5.xml000066400000000000000000000051031301675746700263400ustar00rootroot00000000000000 JBoss Enterprise Application Platform 5 EAP Version should be version 5 JBoss Enterprise Application Platform 5 JBOSS_HOME boot.log Release ID: JBoss \[EAP\] ([0-9\.]{3,5}) 1 5\.(0|1)\.[0-2]+ production /server/ /log scap-security-guide-0.1.31/JBoss/EAP/5/input/oval/jboss_eap_admin_console_secure_remove.xml000066400000000000000000000060361301675746700317040ustar00rootroot00000000000000 Ensure Admin Console Is Secured Or Removed The Administration Console application must be secured or removed from deployment. jboss-web.xml boolean(/jboss-web/security-domain/text()) true /management /console-mgr.sar/web-console.war/WEB-INF JBOSS_HOME /server/ /deploy production scap-security-guide-0.1.31/JBoss/EAP/5/input/oval/jboss_eap_audit_appender_information.xml000066400000000000000000000040371301675746700315370ustar00rootroot00000000000000 Ensure Security Audit Appender Is Enabled The Security Audit Appender must be enabled. jboss-log4j.xml /log4j:configuration/appender[@name="AUDIT"]/layout[@class="org.apache.log4j.PatternLayout"]/param[@name="ConversionPattern"]/@value %d%-5p[%c](%t:%x)%m%n /server/ /conf production JBOSS_HOME scap-security-guide-0.1.31/JBoss/EAP/5/input/oval/jboss_eap_configure_credential_caching.xml000066400000000000000000000042641301675746700317770ustar00rootroot00000000000000 Configure User Credential Caching Security domains in use must use DefaultCacheTimeout less than or equal to 1800 seconds. jboss-service.xml /server/mbean[@code='org.jboss.security.plugins.JaasSecurityManagerService'and@name='jboss.security:service=JaasSecurityManager']/attribute[@name='DefaultCacheTimeout']/text() 1800 /server/ /conf production JBOSS_HOME scap-security-guide-0.1.31/JBoss/EAP/5/input/oval/jboss_eap_configure_security_logging.xml000066400000000000000000000057341301675746700315710ustar00rootroot00000000000000 Ensure the SecurityInterceptor Logging Level Is Set Correctly SecurityInterceptor logging level should be set to TRACE and Reference the AUDIT Appender. jboss-log4j.xml boolean(/log4j:configuration/category[@name="org.jboss.ejb.plugins.SecurityInterceptor"]/priority[@value="TRACE"]/@value) true jboss-log4j.xml boolean(/log4j:configuration/category[@name="org.jboss.ejb.plugins.SecurityInterceptor"]/appender-ref[@ref="AUDIT"]/@ref) true /server/ /conf production JBOSS_HOME scap-security-guide-0.1.31/JBoss/EAP/5/input/oval/jboss_eap_disable_console_logging.xml000066400000000000000000000037331301675746700310030ustar00rootroot00000000000000 Disable Console Output To The JBoss console Console logging in a production environment is a needless drain on system resources. jboss-log4j.xml boolean(/log4j:configuration/root/appender-ref[@ref='CONSOLE']/@ref) false /server/ /conf production JBOSS_HOME scap-security-guide-0.1.31/JBoss/EAP/5/input/oval/jboss_eap_disable_hot_deployment.xml000066400000000000000000000031701301675746700306600ustar00rootroot00000000000000 Disable Hot Deployment Hot deployment should be disabled on production servers. hdscanner-jboss-beans.xml /server/ /deploy production JBOSS_HOME scap-security-guide-0.1.31/JBoss/EAP/5/input/oval/jboss_eap_disable_hsqldb.xml000066400000000000000000000074111301675746700271050ustar00rootroot00000000000000 Ensure HSQLDB Is Disabled The default development HSQL database included with JBoss should be removed. hsqldb-ds.xml hsqldb.jar hsqldb-plugin.jar hsqldb-persistence-service.xml /messaging /common/lib /server/ /deploy production JBOSS_HOME scap-security-guide-0.1.31/JBoss/EAP/5/input/oval/jboss_eap_disable_tech_preview.xml000066400000000000000000000024501301675746700303120ustar00rootroot00000000000000 Ensure Technology Preview Is Disabled Remove the PicketLink technology preview folder. /../picketlink JBOSS_HOME scap-security-guide-0.1.31/JBoss/EAP/5/input/oval/jboss_eap_enable_audit_appender.xml000066400000000000000000000036231301675746700304400ustar00rootroot00000000000000 Ensure Security Audit Appender Is Enabled The Security Audit Appender must be enabled. jboss-log4j.xml boolean(/log4j:configuration/appender[@name="AUDIT"]/@name) true /server/ /conf production JBOSS_HOME scap-security-guide-0.1.31/JBoss/EAP/5/input/oval/jboss_eap_enable_audit_provider.xml000066400000000000000000000037661301675746700305040ustar00rootroot00000000000000 Ensure Security Audit Provider Is Enabled The Security Audit Provider category must be enabled for production environments. jboss-log4j.xml boolean(/log4j:configuration/category[@name="org.jboss.security.audit.providers.LogAuditProvider"]/@name) true /server/ /conf production JBOSS_HOME scap-security-guide-0.1.31/JBoss/EAP/5/input/oval/jboss_eap_java_security_manager_policy.xml000066400000000000000000000044401301675746700320650ustar00rootroot00000000000000 Configure the Java Security Manager's Environment Policy JBoss Enterprise Application Platform should be configured to load a Java security policy that has been vetted for use in the environment. run.conf ((?:#*)JAVA_OPTS="\$JAVA_OPTS-Djava\.security\.manager-Djava\.security\.policy==.*") 1 ((?:#*)JAVA_OPTS="\$JAVA_OPTS-Djava\.security\.manager-Djava\.security\.policy==.*") /bin JBOSS_HOME scap-security-guide-0.1.31/JBoss/EAP/5/input/oval/jboss_eap_jmx_console_secure_remove.xml000066400000000000000000000055571301675746700314210ustar00rootroot00000000000000 Ensure the JMX Console Is Secured Or Removed The JMX Console application must be secured or removed. jboss-web.xml boolean(/jboss-web/security-domain/text()) true /WEB-INF /jmx-console.war /server/ /deploy production JBOSS_HOME scap-security-guide-0.1.31/JBoss/EAP/5/input/oval/jboss_eap_remove_clustering.xml000066400000000000000000000035561301675746700277070ustar00rootroot00000000000000 Remove JBoss Clustering JBoss Clustering should be removed. hajndi-jboss-beans.xml /cluster /server/ /deploy production JBOSS_HOME scap-security-guide-0.1.31/JBoss/EAP/5/input/oval/jboss_eap_remove_hsqldb_domain.xml000066400000000000000000000036271301675746700303330ustar00rootroot00000000000000 Remove the HSQLDB Security Domain The security domain for HSQLDB should be removed. login-config.xml boolean(/policy/application-policy[@name="HsqlDbRealm"]/@name) false /server/ /conf production JBOSS_HOME scap-security-guide-0.1.31/JBoss/EAP/5/input/oval/jboss_eap_remove_snmp.xml000066400000000000000000000036071301675746700265020ustar00rootroot00000000000000 Remove the JBoss SNMP SAR file The file JBOSS_HOME/server/[PROFILE]/deploy/snmp-adaptor.sar should not exist. /snmp-adaptor.sar /server/ /deploy production JBOSS_HOME scap-security-guide-0.1.31/JBoss/EAP/5/input/oval/jboss_eap_secure_JMXInvokerServlet.xml000066400000000000000000000061251301675746700310550ustar00rootroot00000000000000 Secure the JMXInvokerServlet Servlet The JMXInvokerServlet servlet must be secured against web attacks. web.xml boolean(/web-app/security-constraint/web-resource-collection[contains(http-method,'GET')]) false web.xml boolean(/web-app/security-constraint/web-resource-collection[contains(http-method,'POST')]) false /httpha-invoker.sar/invoker.war/WEB-INF/ /server/ /deploy production JBOSS_HOME scap-security-guide-0.1.31/JBoss/EAP/5/input/oval/jboss_eap_set_strict_mode.xml000066400000000000000000000042151301675746700273330ustar00rootroot00000000000000 Set allRolesMode To Strict Mode The allRolesMode within JBOSS_HOME/server/production/deploy/jbossweb.sar/server.xml must be set to strict. server.xml /Server/Service/Engine[@name="jboss.web"]/Realm/@allRolesMode strict /jbossweb.sar /server/ /deploy production JBOSS_HOME jboss_eap_unprivileged_access_JMXInvokerServlet.xml000066400000000000000000000111561301675746700335260ustar00rootroot00000000000000scap-security-guide-0.1.31/JBoss/EAP/5/input/oval Prevent Unprivileged Access To The JMXInvokerServlet This interface must be made unavailable to unprivileged users. jmx-invoker-service.xml boolean(/server/mbean/xmbean/operation[contains(name,'invoke')]/descriptors/interceptors/interceptor[@code='org.jboss.jmx.connector.invoker.AuthorizationInterceptor' and @authorizingClass='org.jboss.jmx.connector.invoker.RolesAuthorization']) true login-config.xml /policy/application-policy[@name='jmx-console']/authentication/login-module[@code='org.jboss.security.auth.spi.UsersRolesLoginModule' and @flag='required']/module-option[@name='usersProperties']/text() props/jmx-console-users.properties login-config.xml /policy/application-policy[@name='jmx-console']/authentication/login-module[@code='org.jboss.security.auth.spi.UsersRolesLoginModule' and @flag='required']/module-option[@name='rolesProperties']/text() props/jmx-console-roles.properties /server/ /conf /server/ /deploy production JBOSS_HOME scap-security-guide-0.1.31/JBoss/EAP/5/input/oval/jboss_eap_vendor_supported.xml000066400000000000000000000007161301675746700275500ustar00rootroot00000000000000 JBoss Enterprise Application Platform Supported Version Installed version of JBoss is a vendor supported version. scap-security-guide-0.1.31/JBoss/EAP/5/input/oval/jboss_eap_web_console_secure_remove.xml000066400000000000000000000056021301675746700313670ustar00rootroot00000000000000 Ensure the Web Console Is Secured Or Removed The Web Console application must be secured or removed. jboss-web.xml boolean(/jboss-web/security-domain/text()) true /admin-console.war /WEB-INF /server/ /deploy production JBOSS_HOME scap-security-guide-0.1.31/JBoss/EAP/5/input/oval/platform/000077500000000000000000000000001301675746700232175ustar00rootroot00000000000000scap-security-guide-0.1.31/JBoss/EAP/5/input/oval/platform/eap5-cpe-dictionary.xml000066400000000000000000000036701301675746700275110ustar00rootroot00000000000000 JBoss Enterprise Application Platform 5.0.0 installed_app_is_eap5.xml JBoss Enterprise Application Platform 5.1.0 installed_app_is_eap5.xml JBoss Enterprise Application Platform 5.1.1 installed_app_is_eap5.xml JBoss Enterprise Application Platform 5.1.2 installed_app_is_eap5.xml JBoss Enterprise Application Platform 5.0.1 installed_app_is_eap5.xml scap-security-guide-0.1.31/JBoss/EAP/5/input/oval/templates/000077500000000000000000000000001301675746700233715ustar00rootroot00000000000000scap-security-guide-0.1.31/JBoss/EAP/5/input/oval/templates/README000066400000000000000000000000331301675746700242450ustar00rootroot00000000000000Remove or update this file scap-security-guide-0.1.31/JBoss/EAP/5/input/oval/testoval.py000077500000000000000000000003551301675746700236140ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import testoval_module if __name__ == "__main__": testoval_module.main() scap-security-guide-0.1.31/JBoss/EAP/5/input/profiles/000077500000000000000000000000001301675746700222555ustar00rootroot00000000000000scap-security-guide-0.1.31/JBoss/EAP/5/input/profiles/stig-eap5-upstream.xml000066400000000000000000000010071301675746700264310ustar00rootroot00000000000000 STIG for JBoss Enterprise Application Platform 5 This is a *draft* profile for STIG. This profile is being developed under the DoD consensus model to become a STIG in coordination with DISA FSO. scap-security-guide-0.1.31/JBoss/Fuse/6/input/profiles/stig-amq-upstream.xml000066400000000000000000000004631301675746700266600ustar00rootroot00000000000000 STIG for Apache ActiveMQ This is a *draft* profile for STIG. This profile is being developed under the DoD consensus model to become a STIG in coordination with DISA FSO. scap-security-guide-0.1.31/JBoss/Fuse/6/input/profiles/stig-fuse6-upstream.xml000066400000000000000000000004621301675746700271310ustar00rootroot00000000000000 STIG for JBoss Fuse 6 This is a *draft* profile for STIG. This profile is being developed under the DoD consensus model to become a STIG in coordination with DISA FSO. scap-security-guide-0.1.31/JBoss/Fuse/6/input/xccdf/000077500000000000000000000000001301675746700220175ustar00rootroot00000000000000scap-security-guide-0.1.31/JBoss/Fuse/6/input/xccdf/application/000077500000000000000000000000001301675746700243225ustar00rootroot00000000000000scap-security-guide-0.1.31/JBoss/Fuse/6/input/xccdf/application/amq.xml000066400000000000000000000150001301675746700256160ustar00rootroot00000000000000 Apache ActiveMQ Configuration The rules in this group validate Apache ActiveMQ related items. Ensure No Default User Accounts Exist Remove, rename, or comment out the default user accounts defined in .properties files. Default configurations are commonly leveraged by attackers to gain entry into closed systems. Removing, renaming, or commenting out default user accounts makes malicious exploitation more complex. Ensure No Default Roles Exist Remove, rename, or comment out the default roles defined in .properties files. Default configurations are commonly leveraged by attackers to gain entry into closed systems. Removing, renaming, or commenting out default roles makes malicious exploitation more complex. Ensure Default System Java Authentication and Authorization Service Is In Use Using the default system JAAS configuration ensures user identification and authentication are performed by JBoss Fuse. Using an administrator specified JAAS configuration enables a more rigorous security posture. Disable or Remove Clear-Text Passwords Eliminate clear-text passwords in JBoss configuration files. All passwords should be encrypted and all password files should have restricted file permissions. Clear-text passwords are an unnecessary security vulnerability. While risk of exposure can be mitigated through configured permissions and file ownership, these methods do not completely remediate the risk. Ensure Administrators Can Only Change Security Related Configuration Attributes Security attributes are typically associated with internal data structures and configuration (e.g., application deployment, logging, monitoring) within the application server and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the organizational information security policy. If unauthorized entities were able to change security attributes, the integrity and/or confidentiality of the server could be compromised. SSL Is Enabled on the ActiveMQ Web Console The server must utilize cryptography to protect the confidentiality of remote access management sessions. If cryptography is not used, then the session data traversing the remote connection could be intercepted and compromised. Stored Passwords Must Be Encrypted Stored passwords must be encrypted. Passwords need to be protected at all times and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read and easily compromised.  Ensure ActiveMQ Web Console is using PKI PKI should be enabled for the Web Console. All applications requiring user authentication to access sensitive data must be PKI-enabled in compliance with DoDI 8520.2 PKI and PKI Enabling and are required to credentials approved under the DoD PKI program. All PKI Certificates Are Valid DoD Certificates All PKI Certificates in use should be valid at the time of use. By using invalid certificates the server may allow unauthorized users access to the system. Ensure Only Administrators Can Modify Configuration Files Server should be protected with permission sets which allow only an application administrator to modify application resource configuration files. An access control flaw exists if users or processes can view or modify data to which they should not be permitted. This could result in situations ranging from information disclosure to system compromise and could potentially result in the compromise of other systems on the network. scap-security-guide-0.1.31/JBoss/Fuse/6/input/xccdf/application/camel.xml000066400000000000000000000002371301675746700261270ustar00rootroot00000000000000 Apache Camel Configuration The rules in this group validate Apache Camel related items. scap-security-guide-0.1.31/JBoss/Fuse/6/input/xccdf/application/cxf.xml000066400000000000000000000002311301675746700256200ustar00rootroot00000000000000 Apache CXF Configuration The rules in this group validate Apache CXF related items. scap-security-guide-0.1.31/JBoss/Fuse/6/input/xccdf/application/fuse6.xml000066400000000000000000000014341301675746700260760ustar00rootroot00000000000000 JBoss Fuse 6 JBoss Fuse is an open source Enterprise Service Bus (ESB) with an elastic footprint that supports integration beyond the data center. The lack of license fees and the ability to deploy JBoss Fuse in several different configurations advances intelligent integration to all facets of your business – on premise or in the Cloud.

JBoss Fuse combines Apache Camel, Apache CXF, Apache ActiveMQ, Apache Karaf and Fuse Fabric in a single integrated distribution. Core messaging is provided by Apache ActiveMQ, services framework (SOAP, XML/HTTP, RESTful HTTP) is provided by Apache CXF and integration framework is provided by Apache Camel. Apache Karaf provides a lightweight OSGI-based runtime container. scap-security-guide-0.1.31/JBoss/Fuse/6/input/xccdf/application/karaf.xml000066400000000000000000001313001301675746700261260ustar00rootroot00000000000000 Apache Karaf Configuration The rules in this group validate Apache Karaf related items. Apache Karaf Policies and Procedures The rules in this group validate Apache Karaf policies and procedures. Ensure Adequate Physical Protections The hardware and software executing JBoss Fuse, as well as the software critical to security policy enforcement must be protected from unauthorized modification including unauthorized modifications by potentially hostile outsiders. Reasonable physical security measures to ensure that unauthorized personnel do not have physical access to the hardware running the JBoss Enterprise Application Platform software must be implemented. Many software security precautions can easily be bypassed by personnel with physical access to hardware storing data or executing an application. Assign A JBoss Administrator There must be one or more competent individuals who are assigned to manage JBoss Fuse, its environment and the security of the information it contains. Incompetent, careless, or negligent JBoss administrators can completely invalidate a secure JBoss configuration and create numberless problems for JBoss. Document Incident Response Procedures Ensure well developed procedures exist for incident handling. Incidents include any events that are anomalous to the environment. Planning for incidents prior to real-life scenarios increases incident response time and mitigates damages. Failure to adequately prepare, plan, and exercise for these scenarios can result in extensive losses. Perform Periodic Incident Response Exercises Production environments should exercise incident response procedures at least annually. Environments requiring higher assurances of security should test incident response procedures more often, possibly quarterly or even monthly. Incident response procedures should cover all anomalous events. Planning for incidents and practicing procedures to be followed prior to real-life scenario improves response time and mitigates damages/losses that occur with incidents. Document Disaster Recovery Procedures Robust disaster recovery documentation and procedures should exist. This documentation should include provisions for the JBoss platform, deployed applications, required source code, and supporting applications (such as authentication stores or database servers). Planning for disasters and extended outages prior to a real-life scenario helps mitigate losses associated with identified disasters. Failure to adequately prepare, plan, and exercise for these scenarios can result in extensive losses. Perform Periodic Disaster Recovery Exercises Production environments should exercise disaster recovery procedures that include provisions for the JBoss platform, deployed applications, and any required source code at least annually. Environments requiring higher assurances of disaster recovery ability should test procedures more often, possibly quarterly or even monthly. Planning for disasters and extended outages prior to a real-life scenario helps mitigate losses associated with identified disasters. Failure to adequately prepare, plan, and exercise for these scenarios can result in extensive losses. Identify and Document Application Data Flows It is recommended to identify and document application data flows. This will allow insight into what paths sensitive information takes through the application environment and what data source connections need to be encrypted. Failure to document an application's data flows reduces security, increases the chance for architectural and configuration errors, and can impede performance. Many applications use network services that are not immediately apparent. Deployed Applications - Java Permission Deployment Docs Java permissions for applications should be documented and carefully reviewed prior to deployment. Developers and administrators should strive to balance application permissions and application functionality. Java permissions for deployed applications should be carefully restricted to enforce the least privilege principle. Careful documentation, along with a thorough review will help prevent needlessly insecure permission assignments for applications. An overabundance of Java permissions can allow applications to circumvent one of Java's strongest security features - the Java Security Manager sandbox. Ensure Regular Backup Schedule JBoss applications and configuration files should be backed up at least weekly, possibly more if needed by the environment. Failure to regularly backup JBoss configuration files and deployed applications can result in extensive downtime or information losses in the event of a disaster or other system outage. Ensure Auditing Policy Exists In order to effectively audit and review system logs, an audit policy should be written to identify data and trends of interest. Without a comprehensive audit policy and review procedures, organizations risk missing critical events or event trends within their environment. These missed events may indicate system anomalies ranging from malicious attacks, system instabilities, system misuse, etc. Access Control Policy and Procedures JBoss administrators must have access to guidance regarding account creation, permissions assignments, role assignments, etc. A consistent, cohesive access control policy is impossible to attain without a well-documented access control policy and related procedures. Failure to do so typically results in over-assignment of access permissions for users and applications, stale access for users and applications, and other access control misconfigurations that reduce the effectiveness of the security policy. Define Minimum and Maximum Password Length Requirement Organizations should create an authenticator management policy that defines minimum and maximum password sizes for user accounts accessing JBoss and its deployed applications. In brute force scenarios, passwords of extended lengths increase password security and the length of time required to decrypt the password. However, there are risks associated with requiring passwords of great lengths, as users may take steps to circumvent policy; such as using repetitive passwords, writing password reminders, or writing down their passwords. Define Minimum Password Complexity Requirement Organizations should create an authenticator management policy that defines a minimum level of complexity for user accounts accessing JBoss and its deployed applications. These requirements should also restrict passwords from containing dictionary words and reusing previous passwords. Complex passwords increase password security and the length of time required to decrypt the password. Additionally, complex passwords are less likely to be found in password dictionaries. However, there are risks associated with requiring overly complex passwords, as users may take steps to circumvent policy; such as using repetitive passwords, writing password reminders, or writing down their passwords. Define Minimum Password Expiration Interval Organizations should create an authenticator management policy that defines a maximum password age for user accounts accessing JBoss and its deployed applications. In combination with password length and complexity, regularly changing passwords can defeat many attacks. If a password or password hash is intercepted by a malicious party, changing the password can remove access or render invalid a cracking attempt on the hash. However, there are risks associated with frequently changing passwords. Users may take steps to circumvent policy such as using repetitive passwords or using password derivatives. Additionally, changing passwords for system or application accounts introduces an element of configuration risk. Poorly coordinated or documented changes can result in system outages or create other problems. Ensure JBoss Fuse Is A Vendor Supported Version Evaluated JBoss installation must be a vendor supported version of JBoss Fuse 6. Organizations using JBoss Fuse must use a vendor supported version with an active support contract. Failure to utilize a supported version of JBoss in a production environment can lead to outages, unresolvable problems, no access to security or functional updates, etc. Ensure Java Runtime Environment Is A Vendor Supported Version Evaluated JBoss installation must use a vendor supported Java virtual machine - i.e., one that has not reached end-of-life. Migration strategies should be developed when end-of-life is impending. Java installations should be a vendor supported version. If the Java virtual machine in use by JBoss is not supported by the vendor, this may result in outages, unresolvable problems, no access to security or functional updates, etc. Ensure All Downloaded Software Is Validated Software and packages should be downloaded from redhat.com, and hash validated. Without validating downloaded files are authentic, malicious users may compromise software before it has even been installed. Attackers may redirect traffic to alternate download locations and attempt to trick administrators into downloading modified software. Disable Hot Deployment Hot deployment should be disabled on production servers. Hot Deployment allows for automatic deployment of Java applications by simply placing Java applications into the deploy directory. Hot deployments are not a recommended best practice for production environments. By requiring the additional step of restarting the JBoss server, application deployments become more deliberate and purposeful. Ensure Default User Accounts Have Benn Removed Remove, rename, or comment out the default user accounts defined in .properties files. Default configurations are commonly leveraged by attackers to gain entry into closed systems. Removing, renaming, or commenting out default user accounts makes malicious exploitation more complex. Ensure Default Roles Have Been Removed Remove, rename, or comment out the default roles defined in .properties files. Default configurations are commonly leveraged by attackers to gain entry into closed systems. Removing, renaming, or commenting out default roles makes malicious exploitation more complex. Configure Java Security Manager To Use An Environment Policy The Java Security Manager is a crucial piece of the Java security infrastructure. JBoss Fuse should be configured to load a Java security policy that has been vetted for use in the environment. A weak, default, or incomplete Java Security Manager policy file can completely compromise the security of a Java installation by granting excessive permissions to applications running within the sandbox. These permissions can be leveraged (maliciously or not) to run code against the operating system. Ensure Deployed Applications Have Restricted File Permissions Deployed applications must not be granted file permissions - except to those that are dedicated to the application only. These permissions are enforced by the Java Security Manager and the policies it loads at startup. These permissions can be assigned or restricted in an application-specific, granular manner. Java permissions for deployed applications should be carefully restricted to enforce the least privilege principle. Granting unrestricted access to the host operating system creates a large attack vector for malicious users that have penetrated the JBoss server. Ensure Deployed Applications Do Not Have Network Permissions Deployed applications must not be granted network permissions. These permissions are enforced by the Java Security Manager and the policies it loads at startup. These permissions can be assigned or restricted in an application-specific, granular manner. Java permissions for deployed applications should be carefully restricted to enforce the least privilege principle. Disable Runtime Permissions for Deployed Applications Deployed applications must not be granted runtime permissions. These permissions are enforced by the Java Security Manager and the policies it loads at startup. These permissions can be assigned or restricted in an application-specific, granular manner. Java permissions for deployed applications should be carefully restricted to enforce the least privilege principle. Granting RuntimePermission to applications allows these applications to modify classloaders or modify the running security manager. Either of these actions can be used to elevate permissions and increase the number of potential damaging actions that can be taken. Disable Socket Permissions for Deployed Applications Deployed applications must not be granted any socket permissions. These permissions are enforced by the Java Security Manager and the policies it loads at startup. These permissions can be assigned or restricted in an application-specific, granular manner. Java permissions for deployed applications should be carefully restricted to enforce the least privilege principle. Most well-designed applications will not need to directly manipulate sockets for network access (access to datasources should be handled through datasources, which can be assigned SocketPermission. Disable All Permission for Deployed Applications Deployed applications must not be granted all permissions. These permissions are enforced by the Java Security Manager and the policies it loads at startup. These permissions can be assigned or restricted in an application-specific, granular manner. Java permissions for deployed applications should be carefully restricted to enforce the least privilege principle. Using AllPermissions is essentially disabling the Java security sandbox and is inadvisable in nearly every scenario. Ensure Java Authentication and Authorization Service Is Configured Using the default system JAAS configuration ensures user identification and authentication are performed by JBoss Fuse. Using an administrator specified JAAS configuration enables a more rigorous security posture. Enable CAC Card Usage for Deployed Applications JBoss applications implementing authentication should utilize the DoD Public Key Infrastructure. The DoD Public Key Infrastructure is designed to use hardware tokens such as the Common Access Card in conjunction with issued X.509 certificates. These tokens are typically protected with a PIN that unlocks access to the private certificate stored on the token. Leveraging the DoD Public Key Infrastructure increases the security of an application because the DoD PKI raises the bar for exploitation of user identities. Applications that require authentication and do not utilize PKI must then rely on a less secure form of authentication, such as username and password. Additionally, current DoD guidance requires the use of DoD PKI over username and password. Enable FIPS Compliant Modules While JBoss itself has no need to load FIPS compliant modules, the underlying technologies such as Java do. Utilizing only FIPS compliant modules decreases compatibility with applications that are not FIPS enabled. Enabling FIPS compliant algorithms ensures that the underlying technologies that JBoss works through are using cryptographic modules that have been vetted by NIST for security, stability, and strength. Failure to utilize FIPS certified modules may cause the underlying technologies used by JBoss to utilize older, less secure algorithms. Failure to enable only FIPS compliant modules may also have regulatory consequences, as FIPS 140-2 requires the use of FIPS compliant modules by all federal agencies. Disable and Remove Clear-Text Passwords Eliminate clear-text passwords in JBoss configuration files. All passwords should be encrypted and all password files should have restricted file permissions. Clear-text passwords are an unnecessary security vulnerability. While risk of exposure can be mitigated through configured permissions and file ownership, these methods do not completely remediate the risk. Ensure JBoss Process Owner Executes with Least Privilege Operating environment permissions assigned to the JBoss process owner should be in compliance with the principle of least privilege. In order to reduce the potential impact of exploitation against the JBoss application server (and the rest of the operating environment), the JBoss process owner should execute with as few permissions as possible in the environment (if the account is not local to the operating system or is distributed across multiple operating systems). Failure to limit permissions can dramatically increase the severity of exploits against the JBoss server, such as the execution of arbitrary code. Deny JBoss Process Owner Console Access The JBoss process owner should not have interactive console login access. In order to limit access in the event of an exploitation of the Jboss or one of its deployed applications, the account owning the Jboss process should be limited in its ability to interact with the supporting operating system where possible. Thus, the JBoss process owner account should not have interactive console access. Ensure JBoss Files Are Owned By Appropriate Users All JBoss Fuse files within the installation directory should be owned by the JBoss process owner account. To prevent unauthorized modification or disclosure of JBoss configuration settings, all files within the installation directory should be owned by the JBoss process owner account. Ensure JBoss Files Have Correct Permissions All JBoss files within the installation directory should be readable by the JBoss process owner and JBoss administrators only. To prevent unauthorized modification or disclosure of JBoss configuration settings, access to all files within the installation directory should be restricted to the JBoss process owner account and Jboss administrators. Disable Or Secure Remote Access Remote access must be secured so it is accessible by trusted administrators only. If this condition is not met, the access must be disabled from the deployment. Failure to secure against unauthorized access can quickly lead to system compromise. The default access included with JBoss is a well-known attack vector that can be leveraged to load malicious code to be executed on the server. Secure or Remove Web Console The Web Console application must be secured so it is accessible by trusted administrators only. If this condition is not met, the application must be removed (deleted) from deployment. Failure to secure the default consoles against unauthorized access can quickly lead to system compromise. The default consoles included with JBoss are a well-known attack vector that can be leveraged to load malicious code to be executed on the server. Secure or Disable JMX Access JMX access must be secured so it is accessible by trusted administrators only. If this condition is not met, the access must be disabled from the deployment. Failure to secure JMX against unauthorized access can quickly lead to system compromise. The default access included with JBoss is a well-known attack vector that can be leveraged to load malicious code to be executed on the server. Enable Encrypted Passwords Password hashing should be enabled in all security realms where plain-text passwords are currently in use. Failure to enable password hashing within a login module can result in plain-text exposure client passwords used for authentication. Ensure Administrators Can Only Change Security Related Configuration Attributes Security attributes are typically associated with internal data structures and configuration (e.g., application deployment, logging, monitoring) within the application server and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the organizational information security policy. If unauthorized entities were able to change security attributes, the integrity and/or confidentiality of the server could be compromised. Ensure Only Authorized Users Can Associate PKI Information Throughout the course of normal usage, authorized users of application servers will have the need to associate security attributes in the form of PKI credentials with information. The server utilizes a role based authentication model when managing server resources and limits access according to user role.  The server must ensure that only the users who are authorized to associate security attributes with information are allowed to do so. Enable SSL On The Web Console The server must utilize cryptography to protect the confidentiality of remote access management sessions. If cryptography is not used, then the session data traversing the remote connection could be intercepted and compromised. Secure Remote Access Via SSH The server must utilize cryptography to protect the confidentiality of remote access management sessions. If cryptography is not used, then the session data traversing the remote connection could be intercepted and compromised. Reduce Logging To Decrease Storage Capacity Limitations The server must configure auditing to reduce the likelihood of storage capacity being exceeded. The server auditing capability is critical for accurate forensic analysis. Alerting administrators when audit log size thresholds are exceeded helps ensure the administrators can respond to heavy activity in a timely manner. Failure to alert increases the probability that an adversary's actions will go undetected. The server or the configured Network Attached Storage Device (SAN) must alert administrators when audit log usage reaches a defined percentage of overall capacity. Configure JBoss Logs Number of Days Retained Logging should be configured to maintain logs for a organization defined continuous number of days. If adequate online audit storage capacity is not maintained, intrusion monitoring, security investigations, and forensic analysis can be negatively affected. Ensure Only Approved Administrators Can Change System Configurations The server must enforce logical access restrictions associated with changes to application configuration. When dealing with access restrictions pertaining to change control, it should be noted that any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. Accordingly, only qualified and authorized individuals should be allowed to obtain access to server components for the purposes of initiating changes, including upgrades and application modifications. Remove All Non-Essential Bundles And Features All non-essential bundles and features should be removed from production servers. The server provide a myriad of differing processes, features and functionalities. Some of these processes may be deemed to be unnecessary or too insecure to run on a production DoD system. Servers must provide the capability to disable or deactivate functionality and services that are deemed to be non-essential to the server mission or can adversely impact server performance. Disable All Unused Ports, Protocols, And services The server must prohibit or restrict the use of unauthorized functions, ports, protocols, and/or services. The server provides numerous processes, features and functionalities that utilize TCP/IP ports. Some of these processes may be deemed to be unnecessary or too insecure to run on a production system. Ensure Stored Passwords Are Encrypted Stored passwords must be encrypted. Passwords need to be protected at all times and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read and easily compromised.  Enable SSL When LDAP Is Configured The server must utilize encryption when using LDAP for authentication. Passwords need to be protected at all times and encryption is the standard method for protecting passwords during transmission. Enable FIPS for User and Process Authentication The Application Server must utilize FIPS 140-2 approved encryption modules when authenticating users and processes. Encryption is only as good as the encryption modules utilized. Unapproved cryptographic module algorithms cannot be verified, and cannot be relied upon to provide confidentiality or integrity and DoD data may be compromised due to weak algorithms. FIPS 140-2 is the current standard for validating cryptographic modules and NSA Type-X (where X=1, 2, 3, 4) products are NSA certified hardware-based encryption modules. Configure DoD or CNS approved PKI Class 3 and Class 4 Certificates The server must use DoD or CNS approved PKI Class 3 or Class 4 certificates. Class 3 PKI certificates are used for servers and software signing rather than for identifying individuals. Class 4 certificates are used for business-to-business transactions. Utilizing unapproved certificates not issued or approved by DoD or CNS creates an integrity risk. Configure LDAP To Fail Securely The server must fail securely in the event of an operational failure. Fail secure is a condition achieved by the server in order to ensure that in the event of an operational failure, the system does not enter into an unsecure state where intended security properties no longer hold. Ensure JBoss Logging Is Secured Only error messages that provide information necessary for corrective actions without revealing sensitive or potentially harmful information in error logs and administrative messages should be generated. Any application providing too much information in error logs and in administrative messages to the screen risks compromising the data and security of the application and system. The structure and content of error messages needs to be carefully considered by the organization and development team.  Ensure Log Files Are Only Accessed By Authorized Users Only authorized personnel may view log files. If the application provides too much information in error logs and administrative messages to the screen, this could lead to compromise. The structure and content of error messages need to be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.  Enable The Web Console To Use PKI PKI should be enabled for the Web Console. All applications requiring user authentication to access sensitive data must be PK-enabled in compliance with DoDI 8520.2 PKI and PK Enabling and are required to credentials approved under the DoD PKI program. All PKI Certificates Are Valid DoD Certificates All PKI Certificates in use should be valid at the time of use. By using invalid certificates the server may allow unauthorized users access to the system. Ensure Only Administrators Can Modify Configuration Files Server should be protected with permission sets which allow only an application administrator to modify application resource configuration files. An access control flaw exists if users or processes can view or modify data to which they should not be permitted. This could result in situations ranging from information disclosure to system compromise and could potentially result in the compromise of other systems on the network. scap-security-guide-0.1.31/JBoss/Fuse/6/input/xccdf/application/policy.xml000066400000000000000000000003221301675746700263400ustar00rootroot00000000000000 JBoss Fuse Policy Guidelines The rules in this group are used to manage Jboss servers in a secure manner. These rules are policy related. scap-security-guide-0.1.31/JBoss/Fuse/6/transforms/000077500000000000000000000000001301675746700217675ustar00rootroot00000000000000scap-security-guide-0.1.31/JBoss/Fuse/6/transforms/cce_extract.py000077500000000000000000000003601301675746700246270ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import cce_extract_module if __name__ == "__main__": cce_extract_module.main() scap-security-guide-0.1.31/JBoss/Fuse/6/transforms/cci2html.xsl000066400000000000000000000004741301675746700242310ustar00rootroot00000000000000 scap-security-guide-0.1.31/JBoss/Fuse/6/transforms/constants.xslt000066400000000000000000000022261301675746700247210ustar00rootroot00000000000000 JBoss Fuse 6 Fuse 6 FUSE_6_STIG fuse6 empty Jboss-Fuse-6 cpe:/a:redhat:jboss_fuse:6.0,cpe:/a:redhat:jboss_fuse:6.1.0,cpe:/a:redhat:jboss_fuse_service_works:6.0 scap-security-guide-0.1.31/JBoss/Fuse/6/transforms/shorthand2xccdf.xslt000066400000000000000000000005201301675746700257640ustar00rootroot00000000000000 unknown unlinked-fuse6-oval.xml scap-security-guide-0.1.31/JBoss/Fuse/6/transforms/splitchecks.py000077500000000000000000000003601301675746700246570ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import splitchecks_module if __name__ == "__main__": splitchecks_module.main() scap-security-guide-0.1.31/JBoss/Fuse/6/transforms/table-add-srgitems.xslt000066400000000000000000000011071301675746700263520ustar00rootroot00000000000000 scap-security-guide-0.1.31/JBoss/Fuse/6/transforms/table-sortbyref.xslt000066400000000000000000000005631301675746700260130ustar00rootroot00000000000000 scap-security-guide-0.1.31/JBoss/Fuse/6/transforms/table-srgmap.xslt000066400000000000000000000011461301675746700252630ustar00rootroot00000000000000 scap-security-guide-0.1.31/JBoss/Fuse/6/transforms/table-style.xslt000066400000000000000000000002571301675746700251340ustar00rootroot00000000000000 scap-security-guide-0.1.31/JBoss/Fuse/6/transforms/xccdf-alt-titles.xslt000066400000000000000000000005101301675746700260460ustar00rootroot00000000000000 scap-security-guide-0.1.31/JBoss/Fuse/6/transforms/xccdf-apply-overlay-stig.xslt000066400000000000000000000007571301675746700275510ustar00rootroot00000000000000 scap-security-guide-0.1.31/JBoss/Fuse/6/transforms/xccdf-removeaux.xslt000066400000000000000000000005071301675746700260050ustar00rootroot00000000000000 scap-security-guide-0.1.31/JBoss/Fuse/6/transforms/xccdf2csv-stig.py000077500000000000000000000003661301675746700252020ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import xccdf2csv_stig_module if __name__ == "__main__": xccdf2csv_stig_module.main() scap-security-guide-0.1.31/JBoss/Fuse/6/transforms/xccdf2html.xslt000066400000000000000000000005561301675746700247470ustar00rootroot00000000000000 scap-security-guide-0.1.31/JBoss/Fuse/6/transforms/xccdf2shorthand.xslt000066400000000000000000000005071301675746700257710ustar00rootroot00000000000000 scap-security-guide-0.1.31/JBoss/Fuse/6/transforms/xccdf2stigformat.xslt000066400000000000000000000007031301675746700261540ustar00rootroot00000000000000 scap-security-guide-0.1.31/JBoss/Fuse/6/transforms/xccdf2table-byref.xslt000066400000000000000000000007021301675746700261700ustar00rootroot00000000000000 scap-security-guide-0.1.31/JBoss/Fuse/6/transforms/xccdf2table-cce.xslt000066400000000000000000000007411301675746700256160ustar00rootroot00000000000000 scap-security-guide-0.1.31/JBoss/Fuse/6/transforms/xccdf2table-profileccirefs.xslt000066400000000000000000000016131301675746700300620ustar00rootroot00000000000000 scap-security-guide-0.1.31/JBoss/Fuse/6/transforms/xccdf2table-profilecisrefs.xslt000066400000000000000000000007131301675746700301020ustar00rootroot00000000000000 scap-security-guide-0.1.31/JBoss/Fuse/6/transforms/xccdf2table-profilenistrefs.xslt000066400000000000000000000007131301675746700303010ustar00rootroot00000000000000 scap-security-guide-0.1.31/JBoss/Fuse/6/transforms/xccdf2table-stig.xslt000066400000000000000000000007011301675746700260260ustar00rootroot00000000000000 scap-security-guide-0.1.31/JBoss/Fuse/6/utils/000077500000000000000000000000001301675746700207315ustar00rootroot00000000000000scap-security-guide-0.1.31/JBoss/Fuse/6/utils/README000066400000000000000000000010001301675746700216000ustar00rootroot00000000000000This file is meant to give a quick overview to some of the scripts located in this directory. verify-input-sanity.py Purpose: This script can be invoked without arguments to examine the files within src/input to make sure that they are in good shape *prior to* building the XCCDF and OVAL content with the various make commands. Intent: Help XCCDF and OVAL developers spot common mistakes *before* utilizing the Makefile to build the XCCDF and OVAL content. Usage: ./verify-input-sanity.py scap-security-guide-0.1.31/JBoss/Fuse/6/utils/sync-alt-titles.py000077500000000000000000000003701301675746700243420ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import sync_alt_titles_module if __name__ == "__main__": sync_alt_titles_module.main() scap-security-guide-0.1.31/JBoss/Fuse/6/utils/verify-cce.py000077500000000000000000000003561301675746700233460ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import verify_cce_module if __name__ == "__main__": verify_cce_module.main() scap-security-guide-0.1.31/JBossEAP5/000077500000000000000000000000001301675746700171355ustar00rootroot00000000000000scap-security-guide-0.1.31/JBossEAP5/README000066400000000000000000000010051301675746700200110ustar00rootroot00000000000000JBoss Enterprise Application Platform 5 SCAP Benchmark ================================================================= Notice: ----------------------------------------------------------------- This content was developed by Red Hat, Inc. for use by JBoss EAP5 Administrators and is released under the Public Domain License. Instructions: ----------------------------------------------------------------- For instructions and guidance on how to use this benchmark, please view the file "docs/JBossEAP5_Guide.html" scap-security-guide-0.1.31/JBossEAP5/Testing notes.txt000066400000000000000000000045431301675746700224320ustar00rootroot00000000000000------------------------ +++++Issue =====Recommendation *****Actions ------------------------ +++++No file labeled README in document root (should be plain-text to accompnay html) =====Add a plaintext README file ------------------------ +++++ovaldi is a no-go on RHEL 6 64bit without extensive troubleshooting. On RHEL 5 was able to install pcre.i386 to eliminate depenadcy problem for ovladi. =====Not our problem. ------------------------ +++++After unziping packaged SCAP content, no root directory created; content just explodes into current directory =====Ant script should package content into a root directory as a defacto standard. ------------------------ +++++No transform provided for viewing results? XML contains embedded HTML, but no colors and +++++No instructions on reviewing results =====Provide transform for viewing results. *****Tim: Find an XSL transform and add use text to the HTML guide ------------------------ +++++No descriptions for questionaires. =====Use a copy XCCDF DESCRIPTION element. *****Tim: Action item for after testing completed ------------------------ +++++Many of the complicated ocil test are not usable in xccdfexec without referencing the guide (since at present xccdf is not displyaing OCIL instructions). =====Provide better instruction to the auditor. Possible solutions: =====Add an EAP number and reference to the HTML Guide for each OCIL QUESTION element. =====Add the OCIL_INSTRUCTIONS to STEPS in line with the specification. =====Add the OCIL_INSTRUCTIONS to the OCIL_QUESTION - breaking with the specification. ******Tim: Add EAP ID links to XCCDF and OCIL question for usability ------------------------ +++++Forced to use production profile for all checks (Common Criteria and Best Practices). Currently, the CPE check for EAP version means that the content only runs on 5.1.0 and 5.1.1, not 5.x =====Remove the CPE check for EAP version and use as regular OVAL check for the Common Criteria profile instead. =====Use the CPE to check for JBoss EAP version 5.x instead of a specific version. *****Bryan: Add additional versions to CPE *****All: Revisit CPE problems after move to FedoraHosted *****Bryan: Add a variable for [PROFILE] defaults porduction and brief instructions for the user to modify the variable within the XML ------------------------ ******Kenny: sending EAP-51 ******Tim: add content for last 3 EAP'sscap-security-guide-0.1.31/JBossEAP5/build.xml000066400000000000000000000015401301675746700207560ustar00rootroot00000000000000 scap-security-guide-0.1.31/JBossEAP5/docs/000077500000000000000000000000001301675746700200655ustar00rootroot00000000000000scap-security-guide-0.1.31/JBossEAP5/docs/JBossEAP5_Guide.html000066400000000000000000014470521301675746700235400ustar00rootroot00000000000000 Security Benchmark JBoss Enterprise Application Platform 5.x
JBoss

Security Benchmark JBoss Enterprise Application Platform 5.x

Status: accepted Date: 2012-07-06

Notice

This content was developed by Red Hat, Inc. for use by JBoss Enterprise Application Platform 5.x Administrators and is released under the Public Domain License.

Table of Contents

Notice

Front Matter

Requirements

Steps to Run

Profiles

  1. JBoss Enterprise Application Platform 5 - Department of Defense

Guidance

  1. General Configuration
    1. JBoss Enterprise Application Platform should be a vendor supported version
    2. Ensure Java Runtime Environment in use is a supported version
    3. Ensure all configurations are made to the appropriate server profile
    4. Ensure Technology Preview components are disabled in production environments
    5. Disable Hot Deployment in production
    6. Production applications should not implement the default SRPVerifierStore interface for the Secure Remote Password (SRP) protocol
    7. Declare an EJB authorization policy for deployed applications
    8. Ensure appropriate permissions have been granted to Java Database Connectivity (JDBC) driver
    9. Ensure appropriate DefaultDS is enabled
    10. Deployed applications must not write data to DefaultDS
    11. Ensure default HSQLDB is disabled
    12. Ensure HSQLDB Security Domain is removed
    13. Ensure the appropriate Java Messaging Service (JMS) persistence configuration file is in use
    14. Ensure Oracle Database persistence plugin is set correctly
    15. Ensure IBM JRE 1.6 is configured correctly
    16. Configured security domains are recommended to secure production applications
    17. The allRolesMode must be configured to "strict"
    18. Define <security-role> elements
    19. Remove, rename, or comment out the default user accounts from production servers
    20. Remove, rename, or comment out the default roles from production servers
    21. Security constraint elements should exist for all URLs in production environment
    22. DefaultCacheTimeout must be configured properly for active security domains
    23. snmp-adaptor.sar must not be deployed
    24. Harden Tomcat Connectors: limit maxPostSize
    25. Harden Tomcat Connectors: limit maxSavePostSize
    26. Harden Tomcat Connectors: set server header tags
    27. Harden Tomcat Connectors: ciphers attribute
    28. Harden Tomcat Connectors: limit connectionTimeout
  2. Securing JBoss platform
    1. Configure Java Security Manager to use an environment specific policy
    2. Ensure proper permissions are configured for interactions with JBoss JMX Kernel MBean
    3. Ensure proper permissions are configured for deployed applications: java.io.FilePermission
    4. Ensure proper permissions are configured for deployed applications: java.net.NetPermission
    5. Ensure proper permissions are configured for deployed applications: java.lang.RuntimePermission
    6. Ensure proper permissions are configured for deployed applications: java.net.SocketPermission
    7. Ensure proper permissions are configured for deployed applications: java.security.AllPermission
    8. Ensure default system Java Authentication and Authorization Service configuration is in use for JBoss Seam
    9. Validate keystore and keystorePasswordURL properties are defined and loaded by Java Security Manager
    10. Validate a keystore file for JBoss exists and is accessible to JBoss
    11. Validate a password file for the Java keystore exists and is accessible to JBoss
    12. Validate JBoss keystore is password protected
    13. Ensure jboss alias is trusted within the JBoss keystore
    14. Ensure applications deployed by JBoss present valid DoD certificates where applicable
    15. Ensure X.509 keystore utilized by JBoss for certificate trusts contains DoD approved Certificate Authorities
    16. Ensure deployed applications requiring authentication utilizes DoD PKI Class 3 or Class 4 certificate and hardware security token or NSA-certified product
    17. Enable Federal Information and Processing Systems 140-2 (FIPS) compliant cryptographic modules for use by JBoss Java environment
    18. Eliminate clear-text passwords: data sources
    19. Eliminate clear-text passwords: Tomcat Connectors
    20. Eliminate clear-text passwords: XML configuration files
    21. Change default password: JBoss Messaging MessageSucker
    22. Change default password: Java cacerts keystore
    23. Ensure Security Audit Appender is enabled
    24. Ensure Security Audit Provider is enabled
    25. Ensure Configure SecurityInterceptor logging level is set correctly
    26. Ensure logging is enabled for Microcontainer bootstrap operations
    27. Ensure logging is enabled for web-based requests if required by deployed applications
    28. Ensure all required information is displayed in <layout>
    29. Production applications should not log output to the JBoss console
    30. Ensure JBoss process owner is executing with least privilege
    31. Deny the JBoss process owner console access
    32. Set JBoss file ownership
    33. Set JBoss file permissions
  3. Securing deployed applications
    1. Ensure JMX Console is either secured or removed
    2. Ensure Web Console is either secured or removed
    3. Ensure Administration Console is either secured or removed
    4. The JMXInvokerServlet servlet must be secured against web attacks
    5. The JMXInvokerServlet servlet must be configured to prevent unprivileged access using authentication
    6. The JMXInvokerServlet servlet must be configured to prevent unprivileged access using authorization
    7. Deployed applications should display a system use banner upon access
    8. Deployed applications should display a classification banner when required
    9. Password hashing must be enabled within the appropriate login module
    10. A password hashing algorithm must be defined within the appropriate login module
    11. Enterprise JavaBeans Specification v2.1 must be strictly followed
  4. Policy
    1. Ensure adequate physical protections are in place
    2. Assign a JBoss administrator
    3. Document incident response procedures
    4. Perform periodic incident response exercises
    5. Document disaster recovery procedures
    6. Perform periodic disaster recovery exercises
    7. Identify and document application data flows
    8. Java permissions for deployed applications should be documented and reviewed prior to deployment
    9. Regular backups should be performed
    10. Auditing policy should exist
    11. Access control policy and procedures
    12. Define an appropriate minimum and maximum password length requirement
    13. Define an appropriate minimum password complexity requirement
    14. Define an appropriate minimum password expiration interval
  5. Architecture
    1. Production JBoss EAP installations should reside on a dedicated platform
    2. Avoid multiple JBoss instances per server
    3. Bind multiple JBoss instances per server to different IPs
    4. Packet filtering should be emplaced around JBoss Enterprise Application Platform
    5. Do not transmit sensitive information over unsecured HTTP connections
  6. Policy
    1. Use a version control repository
    2. Automate JBoss Deployments
    3. Application performance testing
    4. Monitor JBoss servers
    5. Ensure all downloaded software is authentic
    6. Ensure JBoss is configured in accordance with Common Criteria configuration guides
  7. Trimming
    1. Unused features should be disabled or deleted: Java Universal Description, Discovery, Integration (JUDDI)
    2. Unused features should be disabled or deleted: Enterprise Java Beans (EJB) Services
    3. Unused features should be disabled or deleted: Universal Unique Identifier (UUID) Generator
    4. Unused features should be disabled or deleted: Java Message Service (JMS)
    5. Unused features should be disabled or deleted: JBoss Mail
    6. Unused features should be disabled or deleted: JBoss Scheduling
    7. Unused features should be disabled or deleted: Hypersonic SQL Database (HSQLDB)
    8. Unused features should be disabled or deleted: BeanShell (BSH) Deployer
    9. Unused features should be disabled or deleted: JBossWS
    10. Unused features should be disabled or deleted: Seam
    11. Unused features should be disabled or deleted: JBoss Internet Inter-ORB Protocol (IIOP)
    12. Unused features should be disabled or deleted: Miscellaneous
    13. Unused features should be disabled or deleted: HTTP Invokers
    14. Unused features should be disabled or deleted: Java Management Extensions (JMX) Invoker
    15. Unused features should be disabled or deleted: Pooled Invoker
    16. Unused features should be disabled or deleted: Java Remote Method Protocol (JRMP) Invoker
    17. Unused features should be disabled or deleted: Clustering

Rear Matter

Front Matter

JBoss Enterprise Application Platform is a popular Java Enterprise Edition application server platform by Red Hat. It is based on the open-source JBoss Application Server, Community Edition. Leveraging robust container architecture, JBoss EAP is capable of hosting a wide variety of applications - anything from simple, static HTML pages all the way to distributed, transaction-based Java Enterprise Edition applications. JBoss EAP is known for being dependable, fast, flexible, and cost-effective.

This benchmark provides security guidance on JBoss EAP 5 running on Red Hat Enterprise Linux. OVAL content for this benchmark to be run on other platforms is in development. This document assumes that the reader is familiar with JBoss EAP 5 and Red Hat Enterprise Linux administration. This document also assumes that the baseline configuration of the operating system and JBoss EAP 5 are up-to-date in terms of installed patches. The content within this benchmark was tested for compatibility with multiple SCAP tools on Red Hat Enterprise Linux 5 and 6. The following compatibility matrix shows our results:

XCCDFExec v1.1.4 Build 19 SPAWAR Compliance Checker v3.0.3 OpenSCAP v0.8.2
RHEL 5 - i386 Fully Compatible Fully Compatible Fully Compatible
RHEL 5 - x86_64 Fully Compatible Fully Compatible Fully Compatible
RHEL 6 - i386 Additional Dependencies Needed Fully Compatible Fully Compatible
RHEL 6 - x86_64 Additional Dependencies Needed Fully Compatible Fully Compatible

The recommendations included in this benchmark have been derived from various government and industry sources. All rules include a rationale, validation instructions (for OCIL rules), remediation instructions, references, risk assessments, and NIST/DoD Control mappings.

Platform(s):

  • cpe:/a:redhat:jboss_enterprise_application_platform:5.0.0
  • cpe:/a:redhat:jboss_enterprise_application_platform:5.0.1
  • cpe:/a:redhat:jboss_enterprise_application_platform:5.1.0
  • cpe:/a:redhat:jboss_enterprise_application_platform:5.1.1
  • cpe:/a:redhat:jboss_enterprise_application_platform:5.1.2

Requirements

Before running the JBoss EAP 5 benchmark, the target machine must meet the following requirements.

  • JBOSS_HOME environment variable properly set
  • JAVA_HOME environment variable properly set
  • JBoss server should be started prior to testing

    • NOTE: By default, the OVAL content will test the production server profile (use of the production profile is a requirement for JBoss Common Criteria compliance). To change the profile, perform the following actions:

    • Edit the eap5-oval.xml file and locate the <constant_variable id="oval:com.redhat.eap5.scap:var:900122"> element. Update the <value> element with the case-sensitive name of the server profile you wish to test.
    • Perform the same edit on the eap5-cpe-oval.xml file (the id attribute will be slightly different: 800122).

Steps to Run

The JBoss EAP 5 SCAP Benchmark can be run using the XCCDFExec interpreter. Follow the steps below to run the benchmark using XCCDFExec.

  1. Ensure all requirements detailed here have been met.
  2. Download the XCCDF Interpreter from sourceforge: http://sourceforge.net/projects/xccdfexec/
  3. Unzip and install the XCCDF Interpreter, as directed by its README.txt.
    1. NOTE: The XCCDF Interpreter is packaged with a Win32 build of the OVAL Definition Interpreter. To run OVAL checks on your Linux system you can edit the oval.dir and oval.bin properties within the xccdf_interpreter.properties file to reference your local OVALDI installation.
    2. A Linux build of the OVAL Definition Interpreter may be obtained at: http://sourceforge.net/projects/ovaldi/
  4. Navigate to the XCCDF Interpreter directory. For example: 
    cd /xccdf_interpreter_1.1.4_build_19-bin
  5. To run the interpreter, type the following replacing [PROFILE_NAME] with the name of the profile you want to run (as defined in the next section). The command assumes that the EAP5 SCAP files are in the same directory as the xccdf interpreter: 
    java -jar xccdfexec.jar eap5-xccdf.xml -c eap5-cpe-oval.xml -C eap5-cpe-dictionary.xml -P [PROFILE_NAME]
  6. When prompted with the OCIL Interpreter, answer each questionnaire, save the results, and exit.
  7. The results of the tests will be displayed on the screen and in several output files under the results directory. The XML result files can be transformed to HTML using transforms available online.
  8. A result of PASS indicates that the test passed, a result of FAIL indicates that the test failed and a setting may need to be adjusted. You can review the remediation instructions available for each rule to adjust any settings. A result of "NOT APPLICABLE" means that the recommendation is not applicable to your deployment. A result of "NOT CHECKED" means that the recommendations OCIL questionnaire was not answered.

Alternative Tools

There are several alternative tools that you can use to run the EAP 5 SCAP Benchmark. These tools include:

Please see the included documentation for instructions on how to run these tools.

Profiles

1. JBoss Enterprise Application Platform 5 - Department of Defense

Profile for testing a secure deployment of JBoss EAP 5 in a DoD environment.

Profile Name: eap5_full

Guidance

General Configuration

The rules in this group validation general configuration items.

1.1 - JBoss Enterprise Application Platform should be a vendor supported version

Evaluated JBoss installation must be a vendor supported version of JBoss Enterprise Application Platform 5. Red Hat typically offers full and production support for the first 7 years following a release. Extended support options can be negotiated with the vendor directly through a separate subscription. Organizations using JBoss EAP must use a vendor supported version with an active support contract.

Rationale

Failure to utilize a supported version of JBoss in a production environment can lead to outages, unresolvable problems, no access to security or functional updates, etc.

Additional information

CVSSv2 Risk Assessment: 7.5 / High - CVSSv2 Formula: (AV:N/AC:L/Au:N/C:P/I:P/A:P)

DoD Risk Category: CAT I

NIST 800.53 Mapping: CM-6

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1

Validation instructions

To determine the version of JBoss EAP installed, perform the following actions:

  • Execute run.bat --version or run.sh --version located within JBOSS_HOME/bin

The output of the command above will display a variety of information; including the version and build information for JBoss.

Next, review support documentation and interview JBoss administrators. Work with JBoss administrators to access the Red Hat Network customer portal in order to review and validate active subscriptions (https://access.redhat.com/home). Additionally, ensure the version of JBoss has not reached end-of-life. Organizations using JBoss EAP must use a vendor supported version with an active support contract.

Remediation instructions

Other environments should install a vendor supported version of Red Hat JBoss Enterprise Application Platform and maintain an active subscription. Contact Red Hat directly to subscribe to the JBoss software channel (http://www.redhat.com).

Ensure downloaded software is checked against vendor supplied hashes to ensure the software has not been modified in transit. Tools such as sha1sum or md5sum (Linux) or File Checksum Integrity Verifier (FCIV) for Windows can be used to generate hash checksums for downloaded files.

References

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

Check Summary

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:200001
File: eap5-ocil.xml

1.2 - Ensure Java Runtime Environment in use is a supported version

Evaluated JBoss installation must use a vendor supported Java virtual machine - i.e., one that has not reached end-of-life. Migration strategies should be developed when end-of-life is impending.

Rationale
Java installations should be a vendor supported version. If the Java virtual machine in use by JBoss is not supported by the vendor, this may result in outages, unresolvable problems, no access to security or functional updates, etc.
Additional information

CVSSv2 Risk Assessment: 7.5 / High - CVSSv2 Formula: (AV:N/AC:L/Au:N/C:P/I:P/A:P)

DoD Risk Category: CAT I

NIST 800.53 Mapping: CM-6

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1

Validation instructions

To identify the JRE used by JBoss, perform the following actions:

  • Execute run.bat --version or run.sh --version located within JBOSS_HOME/bin

The output of the command above will display a variety of information; including the vendor and version information for the JRE in use by JBoss. Search the vendor's website and support documentation to ensure the vendor actively supports the version of Java virtual machine in use. If the software will reach end-of-life within the next year, ensure the organization is developing a migration plan.

Java Runtime Environments commonly used with JBoss include:

  • Sun JRE 1.6.x
  • IBM JRE 1.6.x
  • OpenJDK JRE 1.6.x

Remediation instructions

Organizations should install a vendor supported Java Runtime Environment.

Ensure downloaded software is checked against vendor supplied hashes to ensure the software has not been modified in transit. Tools such as sha1sum or md5sum (Linux) or File Checksum Integrity Verifier (FCIV) for Windows can be used to generate hash checksums for downloaded files.

Finally, organizations must develop migration plans for Java Runtime Environments that reach end-of-life within the next year.

References

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

Check Summary

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:200201
File: eap5-ocil.xml

1.3 - Ensure all configurations are made to the appropriate server profile

Production environments should utilize the production server profile. Development and test environments should choose the profile that best fits their needs.

Rationale

The JBoss server profiles are preconfigured with various deployed applications. Using a more restrictive profile ensures that less applications are deployed, minimizing the attack surface of the JBoss server and decreasing the amount of trimming that must be performed.

Additional information

CVSSv2 Risk Assessment: 3 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: CM-6

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1

Validation instructions

Ensure that all configuration changes and deployments are made to the appropriate server profile. Production environments should utilize the production server profile. Development and test environments should choose the profile that best fits their needs.

Remediation instructions

JBoss administrators should use the profiles as defined in the validation text.

References

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

Check Summary

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:200501
File: eap5-ocil.xml

1.4 - Ensure Technology Preview components are disabled in production environments

Remove the PicketLink technology preview folder. By default, this folder is included at the same level as the JBoss-as folder. If you leave the picketlink folder as originally shipped in the EAP binary, PicketLink is unable to be launched, and subsequently interact with the certified configuration.

Rationale

Technology Preview components are not production-ready, vendor supported JBoss components. They may be incomplete, contain bugs, insecure features or architecture, etc.

Additional information

CVSSv2 Risk Assessment: 3 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: CM-7

DoD 8500.2 Mapping: DCPP-1

Remediation instructions

Delete the JBOSS_HOME/picketlink/ folder.

References

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

Check Summary

System: http://oval.mitre.org/XMLSchema/oval-definitions-5
Name: oval:com.redhat.eap5.scap:def:201801
File: eap5-oval.xml

1.5 - Disable Hot Deployment in production

Hot deployment should be disabled on production servers. Hot Deployment allows for automatic deployment of Java applications by simply placing Java applications into the deploy directory.

Rationale

Hot deployments are not a recommended best practice for production environments. By requiring the additional step of restarting the JBoss server, application deployments become more deliberate and purposeful. Additionally, the JBoss Hot Deployment feature has been known to become unstable over time - consuming additional memory and resources.

Additional information

CVSSv2 Risk Assessment: 3.0 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: CM-7

DoD 8500.2 Mapping: DCPP-1

Remediation instructions

Delete the following file:

  • JBOSS_HOME/server/[PROFILE]/deploy/hdscanner-jboss-beans.xml
Check Summary

System: http://oval.mitre.org/XMLSchema/oval-definitions-5
Name: oval:com.redhat.eap5.scap:def:113001
File: eap5-oval.xml

1.6 - Production applications should not implement the default SRPVerifierStore interface for the Secure Remote Password (SRP) protocol

The SRP protocol is a public key exchange protocol similar to Diffie-Hellman. The default implementation of the SRPVerifierStore interface is not recommended for a production security environment because it requires all password hash information to be available as a file of serialized objects.

Rationale

Serializing objects is not a recommended practice for Java applications. Object serialization shows poor performance and is not typically scalable for production. Additionally, object serialization creates dependency concerns within the object hierarchy.

Additional information

CVSSv2 Risk Assessment: 3 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: CM-6

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1

Validation instructions

Interview application developers and review application documentation. If deployed applications utilize SRP and/or source code is available for reference, review evidence that the default SRPVerifierStore interface is not in use and that the existing code does not use serialized objects for persistence.

Remediation instructions

Application developers should not use the default implementation for SRPVerifierStore, and should extend it to avoid the use of serialized password objects.

References

1. JBoss Enterprise Application Platform 5 Security Guide, 2011

Check Summary

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:110101
File: eap5-ocil.xml

1.7 - Declare an EJB authorization policy for deployed applications

When configuring your application specific security policy, you must declare one (or more) of the following authorization modules in the security domain <policy-module> element.

  • org.JBoss.security.authorization.modules.DelegatingAuthorizationModule
  • org.JBoss.security.authorization.modules.JACCAuthorizationModule

A security domain does not explicitly require an authorization policy. If an authorization policy is not specified, the default jboss-web-policy and jboss-ejb-policy authorization configured in jboss-as/server/$PROFILE/deploy/security/security-policies-jboss-beans.xml is used. If you do choose to specify an authorization policy, or create a custom deployment descriptor file with a valid authorization policy, these settings override the default settings in security-policies-jboss-beans.xml.

Rationale

Explicitly referencing one of the identified authorization modules ensures that applications extend the security policies defined in security-policies-jboss-beans.xml. This allows JBoss administrators to set a secure baseline that can be tuned on a per-application basis.

Additional information

CVSSv2 Risk Assessment: 3.5 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: AC-3,AC-4

DoD 8500.2 Mapping: ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1,EBBD-1,EBBD-2,EBBD-3

Validation instructions

Review possible locations for definition of <application-policy> elements. Specifically, ensure that 'code' attributes for <authorization><policy-module> elements are either 'org.JBoss.security.authorization.modules.DelegatingAuthorizationModule' or 'org.JBoss.security.authorization.modules.JACCAuthorizationModule'.

These <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.

  • JBOSS_HOME/server/[PROFILE]/conf/login-config.xml
  • JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xml
  • JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xml
  • JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml

NOTE: This applies even if the application is using Extensible Access Control Markup Language (XACML) Authorization Module.

Remediation instructions

Applications deploying their own security policies must specify one of the following <policy-module> within their 'code' attributes:

  • org.JBoss.security.authorization.modules.DelegatingAuthorizationModule
  • org.JBoss.security.authorization.modules.JACCAuthorizationModule

Example:

<application-policy name="demo">
	<authorization>
	<policy-module code="org.JBoss.security.authorization.modules.JACCAuthorizationModule"></policy-module>
	</authorization>
</application-policy>
References

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

Check Summary

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:203901
File: eap5-ocil.xml

1.8 - Ensure appropriate permissions have been granted to Java Database Connectivity (JDBC) driver

The security manager policy file may require permissions to be set for database drivers. The JBoss administrator can assign permissions to the database drivers that are needed by deployed applications. It is recommended that the most restrictive permissions are added. With some installations, permissions must be granted to database drivers that are not available to deployed applications; such as java.net.SocketPermission.

Rationale

Deployed applications requiring access to data sources should have limited permissions to interact with the database drivers.

Additional information

CVSSv2 Risk Assessment: 6.2 / Medium - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:C/I:C/A:C)

DoD Risk Category: CAT II

NIST 800.53 Mapping: AC-3,AC-6

DoD 8500.2 Mapping: ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1,ECLP-1

Validation instructions

To validate compliance, review all policy files defining permissions for the Java Security Manager. In a default Common Criteria compliant JBoss deployment the following policy files will be utilized by JSM (review run.conf or run.conf.bat for more):

  • java.home/lib/security/java.security
  • JBOSS_HOME/bin/security_cc.policy

Other environments will simply load the java.security properties file by default. Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy). Permissions required for JDBC drivers will vary and should be configured according to vendor documentation. In general, JDBC drivers should not be granted AllPermission.

Remediation instructions

The JBoss administrator must assign the most restrictive permissions possible (in accordance with the least privilege principle) to applications accessing defined data sources. This should be done in cooperation with application developers or application documentation. Substitute the directory name of the JDBC driver where [JDBC.DRIVER] is specified in the code sample.

// granting permissions to JDBC driver 
grant codeBase "file:${JBoss.server.home.dir}/lib/[JDBC.DRIVER]" { 
	//JDBC specific permissions to be granted go here
};
References

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

Check Summary

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:204201
File: eap5-ocil.xml

1.9 - Ensure appropriate DefaultDS is enabled

Create a default data store file for the desired database. Templates are located in JBOSS_HOME/docs/examples/jca.
The DefaultDS must not be a HSQLDB.

Rationale

To help ensure robust server operations, a DefaultDS that does not use HSQLDB should be specified. DefaultDS is used by some JBoss components by default.

Additional information

CVSSv2 Risk Assessment: 2.6 / Low - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:N/I:P/A:P)

DoD Risk Category: CAT III

NIST 800.53 Mapping: SC-4

DoD 8500.2 Mapping: ECRC-1

Validation instructions

Review defined data sources in the JBOSS_HOME/server/[PROFILE]/deploy directory. Data sources will be suffixed as -ds.xml. Search for a data source with a <jndi-name>DefaultDS</jndi-name> element. OS text searching utilities can help find the DefaultDS. The DefaultDS CANNOT be HSQL. An HSQL data source will contain elements like: <driver-class>org.hsqldb.jdbcDriver</driver-class> and <type-mapping>Hypersonic SQL</type-mapping>.

Linux: grep -Hri "<jndi-name>DefaultDS</jndi-name>" $JBOSS_HOME/server/[PROFILE]/deploy/*-ds.xml

Remediation instructions

Create a default DS file for the desired database at JBOSS_HOME/server/[PROFILE]/deploy/DefaultDS.xml. Examples of this file are located in JBOSS_HOME/docs/examples/jca. The DefaultDS must not be a HSQLDB.

References

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

Check Summary

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:204401
File: eap5-ocil.xml

1.10 - Deployed applications must not write data to DefaultDS

Deployed applications (other than JBoss default applications) must not write information to the database defined by the DefaultDS data source. These applications must use a database specific to the application.

Rationale

Sharing databases between applications is a poor security practice that can create injection and leakage vulnerabilities that cross application boundaries.

Additional information

CVSSv2 Risk Assessment: 5.1 / Medium - CVSSv2 Formula: (AV:N/AC:H/Au:N/C:P/I:P/A:P)

DoD Risk Category: CAT II

NIST 800.53 Mapping: SC-4

DoD 8500.2 Mapping: ECRC-1

Validation instructions

Interview the application developers and/or review source code to identify when data sources are used. Ensure that the application is not storing data within the DefaultDS.

Next, review the data source definition files (files suffixed *.xml) used by the deployed user applications to ensure they do not reference the same database used by the DefaultDS.

NOTE: Using the same database server is acceptable, however the database must not be the same.

Remediation instructions

Create and deploy a data source in addition to the DefaultDS to store application data. This new data source must not point to the same database as the DefaultDS data source.

Data source templates can be found in the JBOSS_HOME/docs/examples/jca/ directory.

References

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

Check Summary

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:215701
File: eap5-ocil.xml

1.11 - Ensure default HSQLDB is disabled

The default development HSQL database included with JBoss should be removed.

Rationale

HSQL is not meant for production environments - it is there to speed development and enable faster application prototyping. Thus, it is not a full-featured data source intended for production use.

Additional information

CVSSv2 Risk Assessment: 2.6 / Low - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:N/I:P/A:P)

DoD Risk Category: CAT III

NIST 800.53 Mapping: SC-4

DoD 8500.2 Mapping: ECRC-1

Remediation instructions

Delete the following files that refer to the HSQLDB database:

  • JBOSS_HOME/server/[PROFILE]/deploy/hsqldb-ds.xml
  • JBOSS_HOME/common/lib/hsqldb.jar
  • JBOSS_HOME/common/lib/hsqldb-plugin.jar
  • JBOSS_HOME/server/[PROFILE]/deploy/messaging/hsqldb-persistence-service.xml

Delete the HSLQDB database files:

  • JBOSS_HOME/server/[PROFILE]/data/hypersonic/*
References

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

Check Summary

System: http://oval.mitre.org/XMLSchema/oval-definitions-5
Name: oval:com.redhat.eap5.scap:def:204501
File: eap5-oval.xml

1.12 - Ensure HSQLDB Security Domain is removed

The security domain for HsqlDbRealm should be removed from the JBOSS_HOME/server/[PROFILE]/conf/login-config.xml file.

Rationale

HSQL is not meant for production environments - it is there to speed development and enable faster application prototyping. Thus, it is not a full-featured data source intended for production use.

Additional information

CVSSv2 Risk Assessment: 1 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: SC-4

DoD 8500.2 Mapping: ECRC-1

Remediation instructions

Remove the security domain for HsqlDbRealm in the JBOSS_HOME/server/[PROFILE]/conf/login-config.xml file as shown.

<!-- Security domains for testing new jca framework
<application-policy name = "HsqlDbRealm">
	<authentication>
		<login-module code = "org.JBoss.resource.security.ConfiguredIdentityLoginModule" flag = "required">
		<module-option name = "principal">sa</module-option>
		<module-option name = "userName">cctest</module-option>
		<module-option name = "password">cc1248</module-option>
		<module-option name = "managedConnectionFactoryName">JBoss.jca:service=LocalTxCM,name=DefaultDS</module-option>
		</login-module>
	</authentication>
</application-policy>
-->
References

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

Check Summary

System: http://oval.mitre.org/XMLSchema/oval-definitions-5
Name: oval:com.redhat.eap5.scap:def:204601
File: eap5-oval.xml

1.13 - Ensure the appropriate Java Messaging Service (JMS) persistence configuration file is in use

The [database]-persistence-service.xml file contains the persistence service definition for Java Messaging Service, for the database specified by the [database] in the filename. The database must not be HSQLDB.

Rationale

In order to function properly, JMS should be configured to use the appropriate datastore. Production environments require a persistence service definition for JMS that does not use HSQLDB.

Additional information

CVSSv2 Risk Assessment: 2.6 / Low - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:N/I:P/A:P)

DoD Risk Category: CAT III

NIST 800.53 Mapping: CM-6

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1

Validation instructions

Interview the JBoss administrators and application developers to determine if JMS is in use. A quick check can also be performed by checking for the existence of the following files:

  • JBOSS_HOME/server/[PROFILE]/deploy/messaging
  • JBOSS_HOME/server/[PROFILE]/deploy/jms-ra.rar

If JMS is installed, a persistence-service.xml file must exist that does not use HSQLDB. This persistence file will be located in the following location:

  • JBOSS_HOME/server/[PROFILE]/deploy/messaging/*persistence-service.xml
Remediation instructions

Copy the [database]-persistence-service.xml file that corresponds to the database you are using from the JBOSS_HOME/docs/examples/jms directory to JBOSS_HOME/server/[PROFILE]/deploy. Make any required content changes to fit the persistence service to the environment.

References

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

Check Summary

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:204701
File: eap5-ocil.xml

1.14 - Ensure Oracle Database persistence plugin is set correctly

When using the Oracle Database as the DefaultDS, the database persistence plugin definition must be updated in JBOSS_HOME/server/[PROFILE]/deploy/ejb2-timer-service.xml.

Rationale

This is a performance optimization when using Oracle Database as the DefaultDS.

Additional information

CVSSv2 Risk Assessment: 2.6 / Low - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:N/I:N/A:P)

DoD Risk Category: CAT III

NIST 800.53 Mapping: CM-6

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1

Validation instructions

Review defined data sources in the JBOSS_HOME/server/[PROFILE]/deploy directory. Data sources will be suffixed as -ds.xml. Search for a data source with a DefaultDS element. Review the DefaultDS datasource. If the DefaultDS is Oracle Database, review the persistence plugin located at JBOSS_HOME/server/[PROFILE]/deploy/ejb2-timer-service.xml. The DatabasePersistencePlugin attribute must be configured like below:

<attribute name="DatabasePersistencePlugin">
	org.JBoss.ejb.txtimer.OracleDatabasePersistencePlugin
</attribute>
Remediation instructions

When using the Oracle Database as the DefaultDS, the database persistence plugin definition must be updated in JBOSS_HOME/server/[PROFILE]/deploy/ejb2-timer-service.xml to:

<attribute name="DatabasePersistencePlugin">
	org.JBoss.ejb.txtimer.OracleDatabasePersistencePlugin
</attribute>
References

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

Check Summary

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:205001
File: eap5-ocil.xml

1.15 - Ensure IBM JRE 1.6 is configured correctly

When IBM JRE 1.6 is configured as the Java Runtime Environment, the following configuration changes must be made to ensure compatibility between JBoss EAP and IBM JRE.

IBM JRE 1.6 uses a default policy provider which does not work correctly with the JBoss Enterprise Application Platform security policy. The IBM JRE must be reconfigured to use the standard policy provider.

Rationale

The IBM JRE 1.6 default policy provider does not work correctly with the JBoss EAP security policy. Failure to assign the correct policy can lead to system instability.

Additional information

CVSSv2 Risk Assessment: 3.5 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: CM-6

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1

Validation instructions

Review the run.bat or run.sh file as appropriate to determine how JBoss Enterprise Application Platform is calling the Java Runtime Environment. By default, these files are configured to locate the JRE installation through the JAVA_HOME environment variable. If the JAVA_HOME environment variable is not configured, you must track the JRE installation path using information from the run.bat/run.sh file and the operating system PATH variables.

Open JAVA_HOME/jre/lib/security/java.security and review the entry for policy.provider. If the entry is not set to sun.security.provider.PolicyFile, this is a failure.

Remediation instructions

When IBM JRE 1.6 is configured as the Java Runtime Environment, the following configuration changes must be made for compatibility:

Edit the file JAVA_HOME/jre/lib/security/java.security and set the value of policy.provider to sun.security.provider.PolicyFile

References

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

Check Summary

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:206501
File: eap5-ocil.xml

1.16 - Configured security domains are recommended to secure production applications

SecurityDomain is an extension of the AuthenticationManager, RealmMapping, and SubjectSecurityManager interfaces. A java.security.KeyStore, and the Java Secure Socket Extension (JSSE) com.sun.net.ssl.KeyManagerFactory and com.sun.net.ssl.TrustManagerFactory interfaces are included in the class.

Rationale

SecurityDomain is the recommended way to implement security in components, because of the advantages the JAAS Subject offers, and the increased support offered to ASP-style application and resource deployments.

Additional information

CVSSv2 Risk Assessment: 3.5 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: AC-3,IA,SC

DoD 8500.2 Mapping: ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1

Validation instructions

Interview JBoss administrators and application developers. Review application documentation. If a need has been identified to secure production applications, JAAS SecurityDomains should be used.

Remediation instructions

Configure and apply SecurityDomains where appropriate for production applications.

For example, an <application-policy> (SecurityDomain) can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.

  • JBOSS_HOME/server/[PROFILE]/conf/login-config.xml
  • JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xml
  • JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xml
  • JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml

To determine which <application-policy> are in use by deployed applications, search for <security-domain> elements within the following deployment descriptors:

  • JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/jboss-web.xml
  • JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/jboss.xml
References

1. JBoss Enterprise Application Platform 5 Security Guide, 2011

Check Summary

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:110001
File: eap5-ocil.xml

1.17 - The allRolesMode must be configured to "strict"

The allRolesMode within JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml must be set to strict for production environments. This requires the authenticated user to be assigned to one of the web-app/security-role/role-name roles in order to be authorized.

Rationale

This rule enforces strict authorization, requiring authenticated users to be members of defined roles. This allows JBoss administrators to create a simpler, tighter security policy.

Additional information

CVSSv2 Risk Assessment: 4.6 / Medium - CVSSv2 Formula: (AV:N/AC:H/Au:S/C:P/I:P/A:P)

DoD Risk Category: CAT II

NIST 800.53 Mapping: AC-3,AC-6

DoD 8500.2 Mapping: ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1,ECLP-1

Remediation instructions

Update allRolesAttribute for the <Realm> element with className="org.jboss.web.tomcat.security.JBossWebRealm" in JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. Set the attribute value to "strict". By default, the allRolesAttribute is set to "authOnly". For example:

<Realm className="org.jboss.web.tomcat.security.JBossWebRealm" certificatePrincipal="org.jboss.security.auth.certs.SubjectDNMapping" allRolesMode="strict" />
References

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

Check Summary

System: http://oval.mitre.org/XMLSchema/oval-definitions-5
Name: oval:com.redhat.eap5.scap:def:203801
File: eap5-oval.xml

1.18 - Define <security-role> elements

Enable authorization and define <security-role> elements to control access to deployed applications.

Rationale

The specification of <security-role> elements is a recommended practice to ensure portability across application servers and for deployment descriptor maintenance.

Additional information

CVSSv2 Risk Assessment: 3.5 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: AC-3,AC-6

DoD 8500.2 Mapping: ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1,ECLP-1

Validation instructions

Review the web.xml deployment descriptors for deployed applications. Ensure that <security-role> elements have been define that are referenced by <security-constraint><auth-constraint> elements within the <web-app> root element.

Remediation instructions

Working with application developers (or available documentation), determine the desired roles for controlling access to the deployed applications.

Next, create the roles within web.xml.

<web-app>
	<security-role>
		<description>The role required to access restricted content </description>
		<role-name>AuthorizedUser</role-name>
	</security-role>
</web-app>

Finally, require the roles within the application's deployment descriptor, web.xml:

<web-app>
	<security-constraint>
		<auth-constraint>
			<role-name>AuthorizedUser</role-name>
		</auth-constraint>
	</security-constraint>
</web-app>
References

1. JBoss Enterprise Application Platform 5 Security Guide, 2011

Check Summary

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:109201
File: eap5-ocil.xml

1.19 - Remove, rename, or comment out the default user accounts from production servers

Remove, rename, or comment out the default user accounts defined in .properties files and login-config.xml.

Rationale

Default configurations are commonly leveraged by attackers to gain entry into closed systems. Removing, renaming, or commenting out default user accounts makes malicious exploitation more complex.

Additional information

CVSSv2 Risk Assessment: 6 / Medium - CVSSv2 Formula: (AV:N/AC:M/Au:S/C:P/I:P/A:P)

DoD Risk Category: CAT II

NIST 800.53 Mapping: IA-5

DoD 8500.2 Mapping: IAIA-1,IAIA-2,IATS-1,IATS-2

Validation instructions

Ensure the default user accounts in the default <application-policy> elements located within the configuration file: JBOSS_HOME/server/[PROFILE]/conf/login-config.xml have been removed, renamed, or commented out.


<module-option name="principal">sa</module-option>
<module-option name="userName">sa</module-option>
<module-option name="password"></module-option>

<module-option name="principal">guest</module-option>
<module-option name="userName">guest</module-option>
<module-option name="password">guest</module-option>

Examine the .properties files located within the JBOSS_HOME/server/[PROFILE]/conf/props/ directory.

By default, the following files exist:

  • jbossws-users.properties
  • jmx-console-users.properties
  • messaging-users.properties

Ensure the default user accounts have been removed, renamed, or commented out. This includes:

  • admin
  • kermit
  • guest

Remediation instructions

Remove, rename, or comment out the default user accounts in the default <application-policy> elements located within the configuration file: JBOSS_HOME/server/[PROFILE]/conf/login-config.xml. 


					<module-option name="principal">sa</module-option>
					<module-option name="userName">sa</module-option>
					<module-option name="password"></module-option>
					
					<module-option name="principal">guest</module-option>
					<module-option name="userName">guest</module-option>
					<module-option name="password">guest</module-option>

Remove, rename, or comment out the default user accounts in properties files: JBOSS_HOME/server/[PROFILE]/conf/props/

  • jbossws-users.properties
  • jmx-console-users.properties
  • messaging-users.properties

The default user accounts include:

  • admin
  • kermit
  • guest
NOTE: If access is required to the services protected by the <application-policy>, be sure that valid accounts and roles exist!

References

1. JBoss Enterprise Application Platform 5 Security Guide, 2011

Check Summary

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:300101
File: eap5-ocil.xml

1.20 - Remove, rename, or comment out the default roles from production servers

Remove, rename, or comment out the default role definitions in the default <application-policy> elements.

Additionally, remove, rename, or comment out the default role assignments in various properties files from JBOSS_HOME/server/[PROFILE]/conf/props/

Rationale

Default configurations are commonly leveraged by attackers to gain entry into closed systems. Renaming, removing, or commenting out default roles can make exploitation more complex. These steps can also prevent inadvertent assignment of permissions.

Additional information

CVSSv2 Risk Assessment: 6 / Medium - CVSSv2 Formula: (AV:N/AC:M/Au:S/C:P/I:P/A:P)

DoD Risk Category: CAT II

NIST 800.53 Mapping: IA-5

DoD 8500.2 Mapping: IAIA-1,IAIA-2,IATS-1,IATS-2

Validation instructions

Ensure the default role assignments have been removed, renamed, or commented out from the default properties files located in JBOSS_HOME/server/[PROFILE]/conf/props/

  • jbossws-roles.properties
  • jmx-console-roles.properties
  • messaging-roles.properties

The default role assignments are JBossAdmin, HttpInvoker, friend, and guest.

Finally, ensure the default role assignments within application specific deployment descriptors have been removed, renamed, or commented out:

  • JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/WEB-INF/web.xml
  • JBOSS_HOME/server/[PROFILE]/deploy/admin-console.war/WEB-INF/web.xml
  • JBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/WEB-INF/web.xml

These role assignments will fall within <auth-constraint> elements and will look similar to the following:

<security-constraint>
	<web-resource-collection>
		<web-resource-name>HtmlAdaptor</web-resource-name>
		<description>An example security config that only allows users with the role JBossAdmin to access the HTML JMX console web application</description>
		<url-pattern>/*</url-pattern>
	</web-resource-collection>
	<auth-constraint>
		<role-name>JBossAdmin</role-name>
	</auth-constraint>
</security-constraint>

Remediation instructions

Ensure the default role assignments have been removed, renamed, or commented out from the default properties files located in JBOSS_HOME/server/[PROFILE]/conf/props/

  • jbossws-roles.properties
  • jmx-console-roles.properties
  • messaging-roles.properties

The default role assignments are JBossAdmin, HttpInvoker, friend, and guest.

Finally, ensure the default role assignments within application specific deployment descriptors have been removed, renamed, or commented out:

  • JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/WEB-INF/web.xml
  • JBOSS_HOME/server/[PROFILE]/deploy/admin-console.war/WEB-INF/web.xml
  • JBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/WEB-INF/web.xml

These role assignments will fall within <auth-constraint> elements and will look similar to the following:

<security-constraint>
	<web-resource-collection>
		<web-resource-name>HtmlAdaptor</web-resource-name>
		<description>An example security config that only allows users with the role JBossAdmin to access the HTML JMX console web application</description>
		<url-pattern>/*</url-pattern>
	</web-resource-collection>
	<auth-constraint>
		<role-name>JBossAdmin</role-name>
	</auth-constraint>
</security-constraint>

References

1. JBoss Enterprise Application Platform 5 Security Guide, 2011

Check Summary

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:300201
File: eap5-ocil.xml

1.21 - Security constraint elements should exist for all URLs in production environment

The content to be secured is declared using one or more <web-resource-collection> elements. Each <web-resource-collection> element contains an optional series of <url-pattern> elements followed by an optional series of <http-method> elements. The <url-pattern> element value specifies a URL pattern against which a request URL must match for the request to correspond to an attempt to access secured content. The <http-method> element value specifies a type of HTTP request to allow.

Rationale

Whitelisting allowed HTTP methods against all URL's is a recommended security practice to minimize the attack surface of deployed applications. This must be done carefully to ensure that security loopholes are not created, as JBoss allows all HTTP methods by default..

Additional information

CVSSv2 Risk Assessment: 6 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: AC-3

DoD 8500.2 Mapping: ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1

Validation instructions

Review application deployment descriptors for indications that <http-method> has been used to whitelist HTTP verbs. Application deployment descriptors will be located at JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/web.xml All deployed applications should restrict HTTP verbs.

JBoss administrators must take care when restricting HTTP verbs, as JBoss restricts no verbs by default. An incomplete whitelist/blacklist combination could allow circumvention of the intended security policy.
Remediation instructions
Implement a whitelist for HTTP methods accepted by each deployed application. This will generally take the form of two separate security constraints.
References

1. JBoss Enterprise Application Platform 5 Security Guide, 2011

Check Summary

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:109301
File: eap5-ocil.xml

1.22 - DefaultCacheTimeout must be configured properly for active security domains

Security domains in use must use DefaultCacheTimeout less than or equal to 1800 seconds. If you want to disable caching of security credentials, set this to 0 to force authentication to occur every time. This has no affect if the AuthenticationCacheJndiName has been changed from the default value.

Rationale

Production applications should be carefully evaluated to determine the appropriate level of cache credential timeouts. Overuse of cached credentials can leave applications vulnerable to stale authentication stores.

Additional information

CVSSv2 Risk Assessment: 4 / Medium - CVSSv2 Formula: (AV:N/AC:H/Au:N/C:P/I:P/A:N)

DoD Risk Category: CAT II

NIST 800.53 Mapping: SC-8,SC-9,SC-23

DoD 8500.2 Mapping: ECTM-1,ECTM-2

Remediation instructions

Open the JaasSecurityManagerService Mbean configuration file located at JBOSS_HOME/server/[PROFILE]/conf/jboss-service.xml

Find the element <mbean code="org.jboss.security.plugins.JaasSecurityManagerService" name="jboss.security:service=JaasSecurityManager">

Change the <DefaultCacheTimeout> to 1800 or less.

References

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html
2. JBoss Enterprise Application Platform 5 Security Guide, 2011

Check Summary

System: http://oval.mitre.org/XMLSchema/oval-definitions-5
Name: oval:com.redhat.eap5.scap:def:109601
File: eap5-oval.xml

1.23 - snmp-adaptor.sar must not be deployed

The file JBOSS_HOME/server/[PROFILE]/deploy/snmp-adaptor.sar should not exist. snmp-adaptor.sar is the default deployment package for JBoss SNMP. The manager implements SNMP using joeSNMP, supporting only SNMP versions 1 and 2.

Rationale

The default SNMP package (snmp-adaptor.sar) implements joeSNMP, which itself implements SNMP versions 1 and 2. Both versions of the SNMP protocol have many flaws and known vulnerabilities that can leveraged by attackers. Often these are simple remote exploitations that can be easily used by attackers to penetrate a network.

Additional information

CVSSv2 Risk Assessment: 7.5 / High - CVSSv2 Formula: (AV:N/AC:L/Au:N/C:P/I:P/A:P)

DoD Risk Category: CAT I

NIST 800.53 Mapping: CM-6,CM-7

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1,DCPP-1

Validation instructions

To determine if SNMP capabilities have been completely removed, check for the existence of the SNMP adaptor located here: JBOSS_HOME/server/[PROFILE]/deploy/snmp-adaptor.sar/

If the exploded SAR exists, joeSNMP has been deployed and SNMP capabilities using this SNMP implementation still exist for the JBOSS server.

Remediation instructions

Delete the directory JBOSS_HOME/server/[PROFILE]/deploy/snmp-adaptor.sar/

Check Summary

System: http://oval.mitre.org/XMLSchema/oval-definitions-5
Name: oval:com.redhat.eap5.scap:def:200901
File: eap5-oval.xml

1.24 - Harden Tomcat Connectors: limit maxPostSize

The Tomcat container is commonly used to broker connections for JBoss. Several steps to harden the connectors can be taken quickly and easily. maxPostSize is the maximum size (in bytes) that the FORM URL parser can handle. Environments that pass large amounts of data through forms (such as file uploads), may need to increase this setting.

Rationale

An overly high setting can create a denial of service vulnerability in which an attacker simultaneously performs several large POSTS - tying up server resources and network bandwidth.

Additional information

CVSSv2 Risk Assessment: 6.3 / Medium - CVSSv2 Formula: (AV:N/AC:M/Au:S/C:N/I:N/A:C)

DoD Risk Category: CAT II

NIST 800.53 Mapping: CM-6,CM-7

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1,DCPP-1

Validation instructions

Review <Connector> elements in JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. Check for <Connector> elements that define a maxPostSize attribute. If a maxPostSize attribute is defined, it should be 104857600 or less (100 MB).

Remediation instructions

Ensure that all <Connector> elements within JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml have appropriately configured maxPostSize attributes (104857600 or less).

Check Summary

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:401101
File: eap5-ocil.xml

1.25 - Harden Tomcat Connectors: limit maxSavePostSize

The Tomcat container is commonly used to broker connections for JBoss. Several steps to harden the defined connectors can be taken quickly and easily. maxSavePostSize is the maximum size (in bytes) that is buffered during CLIENT-CERT and FORM authentication. The default setting of 4096 (4 KB) is sufficient for most environments.

Rationale

An overly high setting can inadvertently create a denial of service vulnerability in which many users are authenticated and tying up server resources.

Additional information

CVSSv2 Risk Assessment: 6.3 / Medium - CVSSv2 Formula: (AV:N/AC:M/Au:S/C:N/I:N/A:C)

DoD Risk Category: CAT II

NIST 800.53 Mapping: CM-6,CM-7

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1,DCPP-1

Validation instructions

Review <Connector> elements in JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. Check for <Connector> elements that define a maxSavePostSize attribute. If a maxSavePostSize attribute is defined, it should be 12288 or less (12 KB).

Remediation instructions

Ensure that all <Connector> elements within JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml have appropriately configured maxSavePostSize attributes (12288 or less).

Check Summary

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:401201
File: eap5-ocil.xml

1.26 - Harden Tomcat Connectors: set server header tags

The Tomcat container is commonly used to broker connections for JBoss. Several steps to harden the defined connectors can be taken quickly and easily. The server attribute controls the Server Header tag sent with each HTTP response. The default setting causes the server to return Apache-Coyote/1.1 with each HTTP response.

Rationale

Failure to set the server attribute aids malicious users in fingerprinting a web server. However, the server attribute is also used legitimately by some applications for identification.

Additional information

CVSSv2 Risk Assessment: 2.0 / Low

DoD Risk Category: CAT III

NIST 800.53 Mapping: CM-6,CM-7

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1,DCPP-1

Validation instructions

Review <Connector> elements in JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. Check each HTTP <Connector> element to ensure it defines a server attribute. A server attribute should be defined, and it should be set to something other than Apache-Coyote/1.1.

Remediation instructions

Ensure that all HTTP <Connector> elements within JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml have appropriately configured server attributes (set to something other than Apache-Coyote/1.1).

Check Summary

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:401301
File: eap5-ocil.xml

1.27 - Harden Tomcat Connectors: ciphers attribute

The Tomcat container is commonly used to broker connections for JBoss. Several steps to harden the defined connectors can be taken quickly and easily. The ciphers attribute controls the what ciphers are used to negotiate secure connections. The default setting causes the server to use the ciphers allowed by the running Java Virtual Machine.

Rationale

In an environment where FIPS mode has been enabled for the JVM, overriding those settings can lead to system instability or the use of non-FIPS algorithms.

Additional information

CVSSv2 Risk Assessment: 6.0 / Medium

DoD Risk Category: CAT II

NIST 800.53 Mapping: CM-6,CM-7

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1,DCPP-1

Validation instructions

Review <Connector> elements in JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. Check each <Connector> element that contains a secure=true attribute. Ensure this connector does not define a ciphers attribute and instead inherits ciphers defined by the JVM.

Remediation instructions

Ensure that all secure <Connector> elements within JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml have not defined cipher attributes.

Check Summary

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:401401
File: eap5-ocil.xml

1.28 - Harden Tomcat Connectors: limit connectionTimeout

The Tomcat container is commonly used to broker connections for JBoss. Several steps to harden the defined connectors can be taken quickly and easily. connectionTimeout is the time (in milliseconds) that the container will wait for URI content after receiving a connection. The default setting is 60000.

Rationale

An overly high setting can be easily exploited to create a denial of service condition by tying up server resources.

Additional information

CVSSv2 Risk Assessment: 6.3 / Medium - CVSSv2 Formula: (AV:N/AC:M/Au:S/C:N/I:N/A:C)

DoD Risk Category: CAT II

NIST 800.53 Mapping: CM-6,CM-7

DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1,DCPP-1

Validation instructions

Review HTTP <Connector> elements in JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. Check to ensure they define a connectionTimeout attribute. The connectionTimeout attribute should be 20000 or less (20 seconds).

Remediation instructions

Ensure that all HTTP <Connector> elements within JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml have appropriately configured connectionTimeout attributes (20000 or less).

Check Summary

System: http://scap.nist.gov/schema/ocil/2
Name: ocil:com.redhat.eap5.scap:questionnaire:401501
File: eap5-ocil.xml

Securing JBoss platform

The rules in this group are used to secure the JBoss platform and its dependencies.

2.1 - Configure Java Security Manager to use an environment specific policy

The Java Security Manager is a crucial piece of the Java security infrastructure. JBoss Enterprise Application Platform should be configured to load a Java security policy that has been vetted for use in the environment. This precludes the use of the simple default policy that ships with JBoss, but does not preclude the use of preconfigured policy files like the security policy designed for use in a Common Criteria environment (See JBoss Common Criteria Configuration Guide for details).

Rationale

A weak, default, or incomplete Java Security Manager policy file can completely compromise the security of a Java installation by granting excessive permissions to applications running within the sandbox. These permissions can be leveraged (maliciously or not) to run code against the operating system.

Additional information

CVSSv2 Risk Assessment: 6.8 / Medium - CVSSv2 Formula: (AV:N/AC:M/Au:N/C:P/I:P/A:P)

DoD Risk Category: CAT II

NIST 800.53 Mapping: SA-13

Remediation instructions

To load an environment specific security policy, simply append the following line to JBOSS_HOME/bin/run.conf or JBOSS_HOME/bin/run.conf.bat as appropriate (depending on the host operating system).

JAVA_OPTS="$JAVA_OPTS -Djava.security.manager -Djava.security.policy==[PATH TO POLICY FILE]"

NOTE: Using a prepackaged policy file is acceptable, as long as the policy file has been reviewed for compatibility and security within the current environment.

References

1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

Check Summary

System: http://oval.mitre.org/XMLSchema/oval-definitions-5
Name: oval:com.redhat.eap5.scap:def:204301
File: eap5-oval.xml

2.2 - Ensure proper permissions are configured for interactions with JBoss JMX Kernel MBean

Java permissions for MBeans should be carefully restricted to enforce the least privilege principle. These permissions are enforced by the Java Security Manager and the policies it loads at startup. These permissions can be assigned or restricted in an application-specific, granular manner.

Rationale
Java permissions for MBeans should be carefully restricted to enforce the least privilege principle. A JMX MBean server might have access to sensitive information and might be able to perform sensitive operations. JMX provides necessary access control that identifies which clients can access that information and who can perform those operations through the use of the Java Security Manager (JSM). An MBean has a management interface consisting of Named and typed attributes that can be read and written, Named and typed operations that can be invoked and Typed notifications that can be emitted by the MBean.
Additional information

CVSSv2 Risk Assessment: 3.7 / Low - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:P/I:P/A:P)

DoD Risk Category: CAT III

NIST 800.53 Mapping: AC-6

DoD 8500.2 Mapping: ECLP-1

Validation instructions

To validate compliance, review all policy files defining permissions for the Java Security Manager. In a default Common Criteria compliant JBoss deployment the following policy files will be utilized by JSM (review run.conf or run.conf.bat for more):

  • java.home/lib/security/java.security
  • JBOSS_HOME/bin/security_cc.policy

    • Other environments will simply load the java.security properties file by default. Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy)

    Review all JSM permissions granted to MBeans. Grant statements should be limited to specific users and specific methods.

    For example, permission A in the example below is allowed while permission B is not:

    //Permission A
grant principal javax.security.auth.x500.X500Principal "CN=Administrator,OU=JBoss,O=RedHat,L=Raleigh,ST=NC,C=US"
{
	permission javax.management.MBeanPermission
	"className#member[objectName]",
	"invoke";
}
grant principal javax.management.remote.JMXPrincipal "guest"
{
	permission javax.management.MBeanPermission "*", "queryNames";
	permission javax.management.remote.SubjectDelegationPermission;

//Permission B
grant {
	permission javax.management.MBeanPermission "*","invoke";
}
    Remediation instructions
    The JBoss administrator must assign the most restrictive permissions possible (in accordance with the least privilege principle) for MBeans. This should be done in cooperation with system administrators, application developers and/or application documentation.
    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:205101
    File: eap5-ocil.xml

    2.3 - Ensure proper permissions are configured for deployed applications: java.io.FilePermission

    Deployed applications must not be granted file permissions - except to those that are dedicated to the application only. These permissions are enforced by the Java Security Manager and the policies it loads at startup. These permissions can be assigned or restricted in an application-specific, granular manner.

    Rationale

    Java permissions for deployed applications should be carefully restricted to enforce the least privilege principle. Granting unrestricted access to the host operating system creates a large attack vector for malicious users that have penetrated the JBoss server.

    Additional information

    CVSSv2 Risk Assessment: 6.2 / Medium - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:C/I:C/A:C)

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: AC-6

    DoD 8500.2 Mapping: ECLP-1

    Validation instructions

    To validate compliance, review all policy files defining permissions for the Java Security Manager. In a default Common Criteria compliant JBoss deployment the following policy files will be utilized by JSM (review run.conf or run.conf.bat for more):

    • java.home/lib/security/java.security
    • JBOSS_HOME/bin/security_cc.policy

    Other environments will simply load the java.security properties file by default. Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy).

    Review all permissions granted to user deployed applications. The JBoss administrator must assign the most restrictive permissions possible (in accordance with the least privilege principle) for applications.

    Grant statements granting file permissions are permitted only when the file permission targets are located within the user application's directory and dedicated for use by the deployed application.

    For example, permission A in the example below is allowed while permission B is not:

    //Permission A
grant codeBase "file:${JBoss.server.home.dir}/deploy/userApplication/" { 
	permission java.io.FilePermission "${JBoss.server.home.dir}/deploy/userApplication/temp.txt", "read";
};
//Permission B
	grant codeBase "file:${JBoss.server.home.dir}/deploy/userApplication/" { 
	permission java.io.FilePermission "/etc/shadown", "read";
};
    Remediation instructions

    The JBoss administrator must assign the most restrictive permissions possible (in accordance with the least privilege principle) for applications. This should be done in cooperation with application developers or application documentation.

    Application access granted to files by java.io.FilePermission must be located within the deployed application's directory path and be dedicated for use by the deployed application. Grant statements in conflict with this guidance should be modified or removed.

    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:205201
    File: eap5-ocil.xml

    2.4 - Ensure proper permissions are configured for deployed applications: java.net.NetPermission

    Deployed applications must not be granted network permissions. These permissions are enforced by the Java Security Manager and the policies it loads at startup. These permissions can be assigned or restricted in an application-specific, granular manner.

    Rationale

    Java permissions for deployed applications should be carefully restricted to enforce the least privilege principle.

    Additional information

    CVSSv2 Risk Assessment: 5.2 / Medium - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:P/I:P/A:C)

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: AC-6

    DoD 8500.2 Mapping: ECLP-1

    Validation instructions

    To validate compliance, review all policy files defining permissions for the Java Security Manager. In a default Common Criteria compliant JBoss deployment the following policy files will be utilized by JSM (review run.conf or run.conf.bat for more):

    • java.home/lib/security/java.security
    • JBOSS_HOME/bin/security_cc.policy

    Other environments will simply load the java.security properties file by default. Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy).

    Review all permissions granted to user deployed applications. Grant statements granting network permissions are not allowed and will look similar to the following:

    grant codeBase "file:${JBoss.server.home.dir}/deploy/userApplication/" { 
	permission java.net.NetPermission [specific permissions];
};
    Remediation instructions

    The JBoss administrator must assign the most restrictive permissions possible (in accordance with the least privilege principle) for applications. This should be done in cooperation with application developers or application documentation.

    Permissions granted to applications via java.net.NetPermission should be removed.

    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:205301
    File: eap5-ocil.xml

    2.5 - Ensure proper permissions are configured for deployed applications: java.lang.RuntimePermission

    Deployed applications must not be granted runtime permissions. These permissions are enforced by the Java Security Manager and the policies it loads at startup. These permissions can be assigned or restricted in an application-specific, granular manner.

    Rationale

    Java permissions for deployed applications should be carefully restricted to enforce the least privilege principle. Granting RuntimePermission to applications allows these applications to modify classloaders or modify the running security manager. Either of these actions can be used to elevate permissions and increase the number of potential damaging actions that can be taken.

    Additional information

    CVSSv2 Risk Assessment: 6.2 / Medium - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:C/I:C/A:C)

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: AC-6

    DoD 8500.2 Mapping: ECLP-1

    Validation instructions

    To validate compliance, review all policy files defining permissions for the Java Security Manager. In a default Common Criteria compliant JBoss deployment the following policy files will be utilized by JSM (review run.conf or run.conf.bat for more):

    • java.home/lib/security/java.security
    • JBOSS_HOME/bin/security_cc.policy

    Other environments will simply load the java.security properties file by default. Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy)

    Review all permissions granted to user deployed applications. Grant statements granting runtime permissions are not allowed and will look similar to the following:

    grant codeBase "file:${JBoss.server.home.dir}/deploy/userApplication/" { 
	permission java.lang.RuntimePermission [specific permissions];
};
    Remediation instructions

    The JBoss administrator must assign the most restrictive permissions possible (in accordance with the least privilege principle) for applications. This should be done in cooperation with application developers or application documentation.

    Permissions granted to applications via java.lang.RuntimePermission should be removed.

    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:205401
    File: eap5-ocil.xml

    2.6 - Ensure proper permissions are configured for deployed applications: java.net.SocketPermission

    Deployed applications must not be granted any socket permissions. These permissions are enforced by the Java Security Manager and the policies it loads at startup. These permissions can be assigned or restricted in an application-specific, granular manner.

    Rationale

    Java permissions for deployed applications should be carefully restricted to enforce the least privilege principle. Most well-designed applications will not need to directly manipulate sockets for network access (access to datasources should be handled through datasources, which can be assigned SocketPermission.).

    Additional information

    CVSSv2 Risk Assessment: 6.2 / Medium - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:C/I:C/A:C)

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: AC-6

    DoD 8500.2 Mapping: ECLP-1

    Validation instructions

    To validate compliance, review all policy files defining permissions for the Java Security Manager. In a default Common Criteria compliant JBoss deployment the following policy files will be utilized by JSM (review run.conf or run.conf.bat for more):

    • java.home/lib/security/java.security
    • JBOSS_HOME/bin/security_cc.policy

    Other environments will simply load the java.security properties file by default. Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy)

    Review all permissions granted to user deployed applications. Grant statements granting socket permissions are not allowed and will look similar to the following: 

    grant codeBase "file:${JBoss.server.home.dir}/deploy/userApplication/" { 
	permission java.net.SocketPermission [specific permissions];
};
    Remediation instructions

    The JBoss administrator must assign the most restrictive permissions possible (in accordance with the least privilege principle) for applications. This should be done in cooperation with application developers or application documentation.

    Permissions granted to applications via java.net.SocketPermission should be removed.

    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:205501
    File: eap5-ocil.xml

    2.7 - Ensure proper permissions are configured for deployed applications: java.security.AllPermission

    Deployed applications must not be granted all permissions. These permissions are enforced by the Java Security Manager and the policies it loads at startup. These permissions can be assigned or restricted in an application-specific, granular manner.

    Rationale

    Java permissions for deployed applications should be carefully restricted to enforce the least privilege principle. Using AllPermissions is essentially disabling the Java security sandbox and is inadvisable in nearly every scenario.

    Additional information

    CVSSv2 Risk Assessment: 6.2 / Medium - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:C/I:C/A:C)

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: AC-6

    DoD 8500.2 Mapping: ECLP-1

    Validation instructions

    To validate compliance, review all policy files defining permissions for the Java Security Manager. In a default Common Criteria compliant JBoss deployment the following policy files will be utilized by JSM (review run.conf or run.conf.bat for more):

    • java.home/lib/security/java.security
    • JBOSS_HOME/bin/security_cc.policy

    Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy)

    Review all permissions granted to user deployed applications. Grant statements granting AllPermission are not allowed and will look similar to the following: 

    grant codeBase "file:${JBoss.server.home.dir}/deploy/userApplication/" { 
	permission java.security.AllPermission;
};
    Remediation instructions

    The JBoss administrator must assign the most restrictive permissions possible (in accordance with the least privilege principle) for applications. This should be done in cooperation with application developers or application documentation.

    Permissions granted to applications via java.security.AllPermission should be removed.

    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:205601
    File: eap5-ocil.xml

    2.8 - Ensure default system Java Authentication and Authorization Service configuration is in use for JBoss Seam

    For JBoss Seam, the simplified Java Authentication and Authorization Service configuration provided by the Seam Security API must not be used. The default system JAAS configuration should be used instead. Using the default system JAAS configuration ensures user identification and authentication are performed by the JBoss Enterprise Application Platform. JBoss Seam provides additional interfaces for implementing other security functions such as authorization (for example, entity bean permissions). This functionality is controlled by JBoss Seam, and is therefore outside the scope of the evaluated product.

    Rationale

    Using an administrator specified JAAS configuration enables a more rigorous security posture.

    Additional information

    CVSSv2 Risk Assessment: 5.5 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: CM-6

    DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1

    Validation instructions

    Check for components.xml. These files are typically located within the WEB-INF director of a deployed WAR. However, components.xml can also be located within the META-INF directory of a JAR or any JAR directory containing classes with a @Name annotation.

    Within components.xml, the security identity should specify a JAAS security domain to override the default Seam configuration. See the example below:

    <security:identity jaas-config-name="[security domain]"/>

    The security domain must map to a valid JAAS security domain.

    Remediation instructions

    Within components.xml, the security identity should specify a JAAS security domain to override the default Seam configuration. See the example below:

    <security:identity jaas-config-name="[security domain]"/>

    Components.xml is typically located within the WEB-INF director of a deployed WAR. However, components.xml can also be located within the META-INF directory of a JAR or any JAR directory containing classes with a @Name annotation.

    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:202801
    File: eap5-ocil.xml

    2.9 - Validate keystore and keystorePasswordURL properties are defined and loaded by Java Security Manager

    Ensure keystore and keystorePasswordURL properties exist and are loaded by Java Security Manager.

    Rationale

    A keystore should be setup for production environments. Defining a keystore is a basic step towards implementing security and allowing for the use of public/private key cryptography for JBoss. The keystore should be password protected to protect the integrity of the keystore and prevent unauthorized modification.

    Additional information

    CVSSv2 Risk Assessment: 2.4 / Low - CVSSv2 Formula: (AV:L/AC:H/Au:S/C:P/I:P/A:N)

    DoD Risk Category: CAT III

    NIST 800.53 Mapping: SC-28,IA-5

    DoD 8500.2 Mapping: ECCR-1,ECCR-2,ECCR-3,IAIA-1,IAIA-2,IATS-1,IATS-2

    Validation instructions

    In a default JBoss deployment the following policy file will be utilized by Java Security Manager: java.home/lib/security/java.security (Common Criteria installations are typically configured to use the JBOSS_HOME/bin/security_cc.policy file). Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy). Ensure the following lines exist within the any loaded policy file:

    keystore "file:[PATH TO KEYSTORE]";
keystorePasswordURL "file:[PATH TO PASSWORD FILE]";

    NOTE: The file names and paths may vary.

    Remediation instructions

    Add the following lines to any loaded policy file:

    keystore "file:[DESIRED PATH TO KEYSTORE]";
keystorePasswordURL "file:[DESIRED PATH TO PASSWORD FILE]";

    A typical configuration may look like the following:

    keystore "file:${JBoss.server.home.dir}/cc.keystore";
keystorePasswordURL "file:${JBoss.server.home.dir}/cc.password";

    NOTE: The file names and paths may be different. Those shown are the defaults. If the keystore or password file are in different locations, the policy should reflect that.

    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:206001
    File: eap5-ocil.xml

    2.10 - Validate a keystore file for JBoss exists and is accessible to JBoss

    Validate a keystore for JBoss exists and is accessible to JBoss.

    Rationale

    A keystore should be setup for production environments. Defining a keystore is a basic step towards implementing security and allowing for the use of public/private key cryptography for JBoss. The keystore should be password protected to protect the integrity of the keystore and prevent unauthorized modification.

    Additional information

    CVSSv2 Risk Assessment: 3.5 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: SC-8,IA-5

    DoD 8500.2 Mapping: ECTM-1,ECTM-2,IAIA-1,IAIA-2,IATS-1,IATS-2

    Validation instructions

    Determine which keystore is being used by JBoss. In a default JBoss deployment the following policy file will be utilized by Java Security Manager: java.home/lib/security/java.security (Common Criteria installations are typically configured to use the JBOSS_HOME/bin/security_cc.policy file). Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy). Search for a property similar to the following:

    keystore "file:[PATH TO KEYSTORE]";

    Next, validate that the keystore exists at the specified path and that the JBoss process owner account and JBoss administrators have READ/WRITE access to the keystore.

    Remediation instructions

    To create a JBoss keystore, run the following command (you will be prompted to create a password):

    keytool -importcert -alias jboss -keystore [PATH TO KEYSTORE AS DEFINED IN POLICY FILE] -file [PATH TO TRUSTED CERTIFICATE TO IMPORT] -noprompt -trustcacerts

    Setting permissions will vary by operating system, but typically commands like cacls, xacls, chmod, setfacl, etc can all be used to restrict permissions on the keystore. Only the JBoss process owner and JBoss administrators should have READ/WRITE access to the keystore.

    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:205901
    File: eap5-ocil.xml

    2.11 - Validate a password file for the Java keystore exists and is accessible to JBoss

    Validate a password file for the keystore defined in the properties file exists and is accessible to JBoss.

    Rationale

    A password-protected keystore should be setup for production environments. The password for the keystore should be stored in a password file to facilitate automated startup of JBoss Enterprise Application Platform.

    Additional information

    CVSSv2 Risk Assessment: 3.7 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: SC-28,IA-5

    DoD 8500.2 Mapping: ECCR-1,ECCR-2,ECCR-3,IAIA-1,IAIA-2,IATS-1,IATS-2

    Validation instructions

    Determine which keystore is being used by JBoss. In a default JBoss deployment the following policy file will be utilized by Java Security Manager: java.home/lib/security/java.security (Common Criteria installations are typically configured to use the JBOSS_HOME/bin/security_cc.policy file). Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy). Search for a property similar to the following:

    keystorePasswordURL "file:[PATH TO KEYSTORE PASSWORD FILE]";

    Next, validate that the password file exists at the specified path, that only JBoss process owner account and JBoss administrators have READ/WRITE access to the file, and the correct password for the JBoss keystore is in the file.

    Remediation instructions

    To add a password file for a JBoss keystore, simply add the plain-text password to a file and then specify that file in a loaded Java Security Manager policy.

    First, ensure the password file location is identified in the policy file being loaded by the Java Security Manager:

    keystorePasswordURL "file:[DESIRED PATH TO KEYSTORE PASSWORD FILE]";

    Next, add the plain-text password to file whose location you just defined.

    Finally, restrict permissions on the password file so that only the JBoss process owner account and JBoss administrators have READ/WRITE access. Setting permissions will vary by operating system, but typically commands like cacls, xacls, chmod, setfacl, etc can all be used to restrict permissions on the keystore. Only the JBoss process owner and JBoss administrators should have READ/WRITE access to the password file.

    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:216001
    File: eap5-ocil.xml

    2.12 - Validate JBoss keystore is password protected

    Validate the keystore loaded by the Java Security Manager is password protected. Password protecting the Java keystore used by JBoss issued to protect the integrity of the keystore. It does not prevent listing the content, but it does prevent modification of the keystore. Private keys within the keystore are still protected by their own passwords to prevent disclosure.

    Rationale

    Failure to protect the integrity of the keystore used by JBoss can result in authorized modification of the keystore and subsequent certificate trust compromises for JBoss.

    Additional information

    CVSSv2 Risk Assessment: 3.7 / Medium - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:P/I:P/A:P)

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: SC-28,IA-5

    DoD 8500.2 Mapping: ECCR-1,ECCR-2,ECCR-3,IAIA-1,IAIA-2,IATS-1,IATS-2

    Validation instructions

    Determine which keystore is being used by JBoss. In a default JBoss deployment the following policy file will be utilized by Java Security Manager: java.home/lib/security/java.security (Common Criteria installations are typically configured to use the JBOSS_HOME/bin/security_cc.policy file). Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy). Search for a property similar to the following:

    keystore "file:${JBoss.server.home.dir}/cc.keystore";

    Next, access the contents of the keystore using the following command:

    keytool -list -keystore [PATH TO KEYSTORE]

    You should be prompted for a password (non-blank).

    Remediation instructions

    Determine which keystore is being used by JBoss. In a default JBoss deployment the following policy file will be utilized by Java Security Manager: java.home/lib/security/java.security (Common Criteria installations are typically configured to use the JBOSS_HOME/bin/security_cc.policy file). Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy). Search for a property similar to the following:

    keystore "file:[PATH TO KEYSTORE]";

    Add a password to the keystore:

    keytool -storepasswd -keystore [PATH TO KEYSTORE]
    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:215801
    File: eap5-ocil.xml

    2.13 - Ensure jboss alias is trusted within the JBoss keystore

    The jboss alias must be a trustedCertEntry with the JBoss Java keystore. This allows code signed by with the default JBoss certificate to run when using a restrictive policy file.

    Rationale

    A keystore should be setup for production environments with JBoss as a trustedCertEntry for proper functioning of the JBoss Enterprise Application Platform.

    Additional information

    CVSSv2 Risk Assessment: 2.4 / Low - CVSSv2 Formula: (AV:L/AC:H/Au:S/C:P/I:P/A:N)

    DoD Risk Category: CAT III

    NIST 800.53 Mapping: IA-5

    DoD 8500.2 Mapping: IAIA-1,IAIA-2,IATS-1,IATS-2

    Validation instructions

    Determine which keystore is being used by JBoss. In a default JBoss deployment the following policy file will be utilized by Java Security Manager: java.home/lib/security/java.security (Common Criteria installations are typically configured to use the JBOSS_HOME/bin/security_cc.policy file). Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy). Search for a property similar to the following:

    keystore "file:${JBoss.server.home.dir}/cc.keystore";

    Next, list the contents of the keystore using the following command:

    keytool -list -keystore [PATH TO KEYSTORE]

    The jboss alias must exist as a trustedCertEntry.

    Remediation instructions

    To ensure the Jboss alias is a trustedCertEntry, the certificate must be imported to the keystore with the proper command:

    keytool -importcert -alias jboss -keystore [PATH TO KEYSTORE] -file JBOSS_HOME/bin/JBossPublicKey.RSA -noprompt -trustcacerts

    You can check the result with the following keytool command:

    keytool -list -keystore [PATH TO KEYSTORE]

    You should get similar results to those below:

    Your keystore contains 1 entry
jboss, May 17, 2012, trustedCertEntry,
Certificate fingerprint (MD5): 93:F2:F1:8B:EF:8A:E0:E3:D0:E7:69:BC:69:96:29:C1

    Alternatively, the Jboss public key can be added to the Java keystore:

    keytool -importcert -alias jboss -keystore JAVA_HOME/jre/lib/security/cacerts -storepass changeit -file JBOSS_HOME/bin/JBossPublicKey.RSA -noprompt -trustcacerts

    If the system Java keystore is used, the password should be changed with the following command. This may affect the functioning of other applications using the system Java keystore.

    keytool -storepasswd -keystore JAVA_HOME/jre/lib/security/cacerts
    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:206101
    File: eap5-ocil.xml

    2.14 - Ensure applications deployed by JBoss present valid DoD certificates where applicable

    JBoss applications implementing encryption should present a valid DoD issued X.509 certificate for purposes of identifying the server.

    Rationale

    Establishing trust between clients and servers is an important part of information security. Presenting a valid X.509 certificate leverages the mutually-trusted DoD Public Key Infrastructure. Failure to present a valid DoD certificate undermines user confidence, presents an inconsistent user experience for security, and creates potential for abuse of trust by malicious entities.

    Additional information

    CVSSv2 Risk Assessment: 3.5 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: IA-5

    DoD 8500.2 Mapping: IAIA-1,IAIA-2,IATS-1,IATS-2

    Validation instructions

    Using a web browser or similar tool, access deployed JBoss applications that implement encryption and certificate exchange. Examine the X.509 certificate presented to the browser by the server. The certificate must meet the following requirements:

    • The certificate must match the domain name of the webserver being accessed. This can be determined by comparing the DNS name used in the browser to the DNS name on the presented certificate.
    • The certificate must not be expired. This can be determined by reviewing the expiration dates on the server's certificate.
    • The certificate must be issued by a DoD approved Certificate Authority. This can be determined by examining the issuing hierarchy of the presented certificate. Valid Certificate Authorities can be found here: https://crl.gds.disa.mil/
    • The certificate must not be revoked. This can be determined by enabling revocation checking on the web browser or manually reviewing the revocation list identified by the certificate.
    • The certificate public key length must be at least 1024 bits.

    Remediation instructions

    The JBoss administrator must work with the local security manager and certificate registrar to successfully request a certificate from a DoD Certificate Authority.

    Once a valid X.509 certificate has been obtained from a Certificate Authority within the DoD PKI, the certificate and associated private key can be installed in the JBoss keystore. The following example imports a PCKS12 public/private key pair into a Java Key Store. 

    keytool -importkeystore -v -srckeystore KEYSTORE.p12 -srcstoretype PKCS12 -keystore NEW_KEYSTORE.jks

    The final step is to enable TLS on whichever Tomcat connector is used by the deployed application.

    
<Connector protocol="HTTP/1.1" SSLEnabled="true"
	port="8443" address="${jboss.bind.address}"
	scheme="https" secure="true" clientAuth="false"
	keystoreFile="${jboss.server.home.dir}/conf/NEW_KEYSTORE.jks"
	keystorePass="KEYSTORE_PASSWORD" sslProtocol = "TLS" />
    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:400501
    File: eap5-ocil.xml

    2.15 - Ensure X.509 keystore utilized by JBoss for certificate trusts contains DoD approved Certificate Authorities

    JBoss applications implementing encryption should utilize the DoD Public Key Infrastructure.

    Rationale

    Establishing trust between clients and servers is an important part of information security. Validating client X.509 certificates against the DoD Public Key Infrastructure leverages the enterprise trust system. Failure to validate client certificates undermines the enterprise trust infrastructure and makes the JBoss server vulnerable to trust abuse exploits.

    Additional information

    CVSSv2 Risk Assessment: 3.5 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: IA-5

    DoD 8500.2 Mapping: IAIA-1,IAIA-2,IATS-1,IATS-2

    Validation instructions

    Determine which keystore is being used by JBoss. Check for keystore definition lines within any .policy files loaded by the Java Security Manager to determine the path to the keystore. For example:

    keystore "file:${JBoss.server.home.dir}/jboss.keystore";

    List the contents of the keystore using the following command:

    keytool -list -keystore [PATH TO KEYSTORE]

    All currently active DoD Certificate Authorities must exist as trustedCertEntry. At the time of this writing, there were 39 separate Certificate Authorities controlled by DoD that should be trusted.

    Remediation instructions

    Download and install the DoD CA certificates. Currently, the CA certificates can be retrieved from https://crl.gds.disa.mil/.

    The keys can be added to the keystore with a command similar to the following:

    keytool -importcert -keystore [PATH TO KEYSTORE] -storepass [KEYSTORE PASSWORD] -file [PATH TO CERTIFICATE] -noprompt -trustcacerts
    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:400601
    File: eap5-ocil.xml

    2.16 - Ensure deployed applications requiring authentication utilizes DoD PKI Class 3 or Class 4 certificate and hardware security token or NSA-certified product

    JBoss applications implementing authentication should utilize the DoD Public Key Infrastructure. The DoD Public Key Infrastructure is designed to use hardware tokens such as the Common Access Card in conjunction with issued X.509 certificates. These tokens are typically protected with a PIN that unlocks access to the private certificate stored on the token.

    Rationale

    Leveraging the DoD Public Key Infrastructure increases the security of an application because the DoD PKI raises the bar for exploitation of user identities. Applications that require authentication and do not utilize PKI must then rely on a less secure form of authentication, such as username and password. Additionally, current DoD guidance requires the use of DoD PKI over username and password.

    Additional information

    CVSSv2 Risk Assessment: 5 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: IA-5

    DoD 8500.2 Mapping: IAIA-1,IAIA-2,IATS-1,IATS-2

    Validation instructions

    There are many options for implementing this rule on deployed applications. Authentication using DoD's PKI can be accomplished using JBoss itself, the webserver underneath JBoss, or a traffic aggregator in front of JBoss. This rule focuses on configuration of JBoss to authenticate users with a PKI. This rule requires multiple steps to validate.

    First, determine if authentication is required by the deployed application. Review the deployed application's jboss-web.xml (JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/) file to ensure that a security domain has been referenced. For example:

    <security-domain>java:/jaas/JBossTestRealm</security-domain>

    Next, review the deployed application's web.xml (JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/) file to ensure that resources within the web application have been identified to be secured. The <auth-method> element MUST contain CLIENT-CERT in order to implement certificate-based authentication. For example:

    <security-constraint>
	<web-resource-collection>
		<web-resource-name>TestResource</web-resource-name>
		<url-pattern>/*</url-pattern>
	</web-resource-collection>
	<auth-constraint>
		<role-name>JBossTestRole</role-name>
	</auth-constraint>
</security-constraint>
	
<login-config>
	<auth-method>CLIENT-CERT</auth-method>
	<realm-name>Test realm</realm-name>
</login-config>

<security-role>
	<role-name>JBossTestRole</role-name>
</security-role>

    Next, ensure that an <application-policy> element is defined that matches the <security-domain> referenced by the jboss-web.xml file. These <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.

    • JBOSS_HOME/server/[PROFILE]/conf/login-config.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml

    Check the <application-policy> element to ensure it has modules defined for authentication. This <login-module> MUST contain the following attributes:

    • code="org.jboss.security.auth.spi.BaseCertLoginModule"
    • flag="required"

    Example of a satisfactory element:

    <application-policy name="JBossTestRealm">
	<authentication>
		<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
			<module-option name="usersProperties">testUsers.properties</module-option>
			<module-option name="rolesProperties">testRoles.properties</module-option>
		</login-module>
	</authentication>
</application-policy>

    Additional modules can be included to shape the exact functionality desired. For example, <module>s such as SubjectCNMapping can be included to perform attribute mapping.

    Finally, the client certificate's Distinguished Name field must be mapped to a certificate alias stored in the a keystore. The keystore will be defined in the JaasSecurityDomain MBean. For example:

    <mbean code="org.jboss.security.plugins.JaasSecurityDomain" name="jboss.ch8:service=SecurityDomain">
	<constructor>
		<arg type="java.lang.String" value="JBossTestRealm"/>
	</constructor>
	<attribute name="KeyStoreURL">resource:localhost.keystore</attribute>
	<attribute name="KeyStorePass">cleartext-password-that-should-be-masked</attribute>
</mbean>
    Remediation instructions

    First, setup an <application-policy> that enforces certificate-based authentication. This can be accomplished in the following files:

    • JBOSS_HOME/server/[PROFILE]/conf/login-config.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml

    The <application-policy> should resemble the example below:

    <application-policy name="JBossTestRealm">
	<authentication>
		<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
			<module-option name="usersProperties">testUsers.properties</module-option>
			<module-option name="rolesProperties">testRoles.properties</module-option>
		</login-module>
	</authentication>
</application-policy>

    Next, add the <application-policy> to the deployment descriptors and setup the <security-constraint>.

    JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/jboss-web.xml

    <security-domain>java:/jaas/JBossTestRealm</security-domain>

    JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/web.xml

    <security-constraint>
	<web-resource-collection>
		<web-resource-name>TestResource</web-resource-name>
		<url-pattern>/*</url-pattern>
	</web-resource-collection>
	
	<auth-constraint>
		<role-name>JBossTestRole</role-name>
	</auth-constraint>
</security-constraint>
					
<login-config>
	<auth-method>CLIENT-CERT</auth-method>
	<realm-name>Test realm</realm-name>
</login-config>
					
<security-role>
	<role-name>JBossTestRole</role-name>
</security-role>

    Define a keystore to be used via the JaasSecurityDomain MBean:

    JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/jboss-service.xml:

    <mbean code="org.jboss.security.plugins.JaasSecurityDomain" name="jboss.ch8:service=SecurityDomain">
	<constructor>
		<arg type="java.lang.String" value="JBossTestRealm"/>
	</constructor>
	
	<attribute name="KeyStoreURL">resource:test.keystore</attribute>
	<attribute name="KeyStorePass">cleartext-password-that-should-be-masked</attribute>
</mbean>

    Finally, import the client certificates into the keystore using the keytool command. For example:

    keytool -importcert -alias "DN ON THE CERTIFICATE" -keystore JBOSS_HOME/server/[PROFILE]/conf/test.keystore -file [PATH TO CERTIFICATE]
    References

    1. JBoss Enterprise Application Platform Security Guide, 2011

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:400701
    File: eap5-ocil.xml

    2.17 - Enable Federal Information and Processing Systems 140-2 (FIPS) compliant cryptographic modules for use by JBoss Java environment

    While JBoss itself has no need to load FIPS compliant modules, the underlying technologies such as Java and the Apache Tomcat webcontainer do. Utilizing only FIPS compliant modules decreases compatibility with applications that are not FIPS enabled.

    Rationale

    Enabling FIPS compliant algorithms ensures that the underlying technologies that JBoss works through are using cryptographic modules that have been vetted by NIST for security, stability, and strength. Failure to utilize FIPS certified modules may cause the underlying technologies used by JBoss to utilize older, less secure algorithms. Failure to enable only FIPS compliant modules may also have regulatory consequences, as FIPS 140-2 requires the use of FIPS compliant modules by all federal agencies.

    Additional information

    CVSSv2 Risk Assessment: 4.0 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: SC-13

    DoD 8500.2 Mapping: DCNR-1,ECCR-1,ECCR-2,ECCR-3,ECCT-1,ECCT-2,ECNK-1,ECNK-2

    Validation instructions

    Validating this rule is a multi-step process.

    1. First, ensure that the FIPS compliant providers are enabled in the Java security files.

      For IBM JRE/JDK 6.x:

      Check for the following provider in the JAVA_HOME/jre/lib/security/java.security file:

      • security.provider.1=com.ibm.crypto.fips.provider.IBMJCEFIPS

      NOTE: The FIPS compliant provider MUST be at the top of the list as #1.

      Ensure the following line exists in the System.Defaults properties file:

      • com.ibm.jsse2.usefipsprovider=true

      Finally, ensure the following two properties are defined in JAVA_HOME/jre/lib/security/java.security:

      • ssl.SocketFactory.provider=com.ibm.jsse2.SSLSocketFactoryImpl
      • ssl.ServerSocketFactory.provider=com.ibm.jsse2.SSLServerSocketFactoryImpl

      For Sun JRE/JDK 6.x:

      Check for the following providers in the JAVA_HOME/jre/lib/security/java.security file:

      • security.provider.1=com.sun.net.ssl.internal.ssl.Provider SunPKCS11-NSS

      NOTE: The FIPS compliant provider MUST be at the top of the list as #1

      Next, review the application source code to ensure that the proper constructors are utilized for FIPS compliant algorithms. Review the constructor used to initialize SunJSSE and ensure that the FIPS compliant mode has been enabled.

    2. Lastly, perform a packet capture of the TLS handshake to ensure that only FIPS 140-2 algorithms are selected by the server (ServerHello message).
    Remediation instructions

    As this check is not specific to JBoss, validation steps will vary dependent on the Java vendor in use.

    For IBM JRE/JDK 6.x:

    Add the following provider to the JAVA_HOME/jre/lib/security/java.security file:

    • security.provider.1=com.ibm.crypto.fips.provider.IBMJCEFIPS

    NOTE: There will be a list of several providers already in place, numbered 1 to X. The FIPS compliant providers MUST go at the top of the list as #1 and #2. The other providers must be re-numbered.

    Ensure the following line exists in the System.Defaults properties file:

    • com.ibm.jsse2.usefipsprovider=true

    Finally, ensure the following two properties are defined in JAVA_HOME/jre/lib/security/java.security:

    • ssl.SocketFactory.provider=com.ibm.jsse2.SSLSocketFactoryImpl
    • ssl.ServerSocketFactory.provider=com.ibm.jsse2.SSLServerSocketFactoryImpl

    For Sun JRE/JDK 6.x:

    Add the following provider to the JAVA_HOME/jre/lib/security/java.security file:

    • security.provider.1=com.sun.net.ssl.internal.ssl.Provider SunPKCS11-NSS

    NOTE: There will be a list of several providers already in place, numbered 1 to X. The FIPS compliant provider MUST go at the top of the list as #1. The other providers must be re-numbered.

    Now the deployed applications must be written to take advantage of the FIPS enabled providers. The Sun SunJSSE provider must be initialized at run-time with the FIPS boolean value as true.

    References

    1. JBoss Enterprise Application Platform 5 Security Guide, 2011

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:400801
    File: eap5-ocil.xml

    2.18 - Eliminate clear-text passwords: data sources

    Eliminate clear-text passwords in data source configuration files. The class org.jboss.resource.security.SecureIdentityLoginModule can be used to both encrypt database passwords and to provide a decrypted version of the password when the data source configuration is required by the server. The SecureIdentityLoginModule uses a hard-coded password to encrypt/decrypt the data source password.

    Rationale

    Clear-text passwords are an unnecessary security vulnerability. While risk of exposure can be mitigated through configured permissions and file ownership, these methods do not completely remediate the risk.

    Additional information

    CVSSv2 Risk Assessment: 3.7 / Medium - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:P/I:P/A:P)

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: SC-28

    DoD 8500.2 Mapping: ECCR-1,ECCR-2,ECCR-3

    Validation instructions

    Review data source file located within JBOSS_HOME/server/deploy/ and subdirectories. Data sources with encrypted passwords will no longer have <user-name> or <password> elements, and will instead reference a <security-domain>.

    Remediation instructions

    Following the extensive instructions located within Chapter 17, "Encrypting Data Source Passwords" of the JBoss Enterprise Application Platform 5 Security Guide, 2011. While too lengthy to contain here, the summarized steps include:

    • Encrypt the data source password.
    • Create an application authentication policy with the encrypted password.
    • Configure the data source to use the application authentication policy.
    References

    1. JBoss Enterprise Application Platform 5 Security Guide, 2011

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:113601
    File: eap5-ocil.xml

    2.19 - Eliminate clear-text passwords: Tomcat Connectors

    Eliminate clear-text passwords in: Tomcat Connectors.

    Rationale

    Clear-text passwords are an unnecessary security vulnerability. While risk of exposure can be mitigated through configured permissions and file ownership, these methods do not completely remediate the risk.

    Additional information

    CVSSv2 Risk Assessment: 3.7 / Medium - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:P/I:P/A:P)

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: SC-28

    DoD 8500.2 Mapping: ECCR-1,ECCR-2,ECCR-3

    Validation instructions

    Review JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml for evidence of clear-text passwords in Connectors. These Connectors will contain a <attribute name="KeyStorePass"> or a keystorePass attribute as part of the <Connector> element, with a clear-text password.

    Remediation instructions

    Following the extensive instructions located within Chapter 18, "Encrypting the Keystore Password in a Tomcat Connector" of the JBoss Enterprise Application Platform 5 Security Guide, 2011. While too lengthy to contain here, the summarized steps include:

    • Configure JaasSecurityDomain MBean
    • Generate encrypted password
    • Update the Tomcat service MBean
    References

    1. JBoss Enterprise Application Platform 5 Security Guide, 2011

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:116301
    File: eap5-ocil.xml

    2.20 - Eliminate clear-text passwords: XML configuration files

    Using password masking, eliminate clear-text passwords in XML configuration files.

    Rationale

    Clear-text passwords are an unnecessary security vulnerability. While risk of exposure can be mitigated through configured permissions and file ownership, these methods do not completely remediate the risk.

    Additional information

    CVSSv2 Risk Assessment: 3.7 / Medium - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:P/I:P/A:P)

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: SC-28

    DoD 8500.2 Mapping: ECCR-1,ECCR-2,ECCR-3

    Validation instructions

    Review configuration files for evidence of clear-text passwords. No clear-text passwords should exist in XML configuration files (password masking should be used instead).

    Remediation instructions

    Follow the extensive instructions located within Chapter 16, "Masking Passwords in XML Configuration" of the JBoss Enterprise Application Platform 5 Security Guide, 2011. These instructions are too lengthy to summarize here.

    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html
    2. JBoss Enterprise Application Platform 5 Security Guide, 2011

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:116501
    File: eap5-ocil.xml

    2.21 - Change default password: JBoss Messaging MessageSucker

    JBoss Messaging ships with a default MessageSucker password located within the Messaging ServerPeer configuration. This password is used by JBoss to create connections and pass messages between nodes.

    Rationale

    The SuckerPassword ships with a default clear-text password that can be used by attackers to pass messages to default installations of Jboss. The exact content and ramifications of these messages will depend on the listening applications (application logic, input validations, etc.). Failure to change this password can allow an attacker to create connections and pass messages to nodes.

    Additional information

    CVSSv2 Risk Assessment: 7.5 / High - CVSSv2 Formula: (AV:N/AC:L/Au:N/C:P/I:P/A:P)

    DoD Risk Category: CAT I

    NIST 800.53 Mapping: IA-5

    DoD 8500.2 Mapping: IAIA-1,IAIA-2,IATS-1,IATS-2

    Validation instructions

    Review the Jboss Messaging configuration file for the Messaging ServerPeer located here:

    JBOSS_HOME/server[PROFILE]/deploy/messaging/messaging-jboss-beans.xml

    Ensure the <property name="suckerPassword" > has been changed from the default of "CHANGE ME!".

    Remediation instructions

    Open the Jboss Messaging configuration file for the Messaging ServerPeer located here:

    JBOSS_HOME/server[PROFILE]/deploy/messaging/messaging-jboss-beans.xml

    Locate the element <property name="suckerPassword" > and change the contents to a new password generated in accordance with your organization's password security requirements, restricting the use of predefined XML entities such as <'>@" or escaping them if you do. For example:

    <property name="suckerPassword" >Lmf3SdntiDFF6(D5</property>

    The encrypted version of this password can be added to JBOSS_HOME/server[PROFILE]/deploy/messaging/messaging-service.xml by following the directions located in Follow the extensive instructions located within Chapter 16, "Masking Passwords in XML Configuration" of the JBoss Enterprise Application Platform 5 Security Guide, 2011.

    References

    1. JBoss Enterprise Application Platform 5 Security Guide, 2011

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:400201
    File: eap5-ocil.xml

    2.22 - Change default password: Java cacerts keystore

    The Java cacerts keystore is installed by default with most versions of Java. It contains X.509 public certificates for a set of default commercial Certificate Authorities.

    Rationale

    To prevent compromise of the server's X.509 trust chains, the well-known default password on the cacerts keystore should be changed. Failure to change this password could lead to the malicious modification of trusted X.509 CA's.

    This would allow attackers to create connections as trusted entities, sign malicious could as a trusted entity, or create any other number of X.509 certificate abuses.

    Additional information

    CVSSv2 Risk Assessment: 2.6 / Low - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:P/I:P/A:N)

    DoD Risk Category: CAT III

    NIST 800.53 Mapping: IA-5

    DoD 8500.2 Mapping: IAIA-1,IAIA-2,IATS-1,IATS-2

    Validation instructions

    Attempt to access the contents of the Java cacerts keystore at the default location using the following command:

    keytool -list -keystore JAVA_HOME/lib/security/cacerts

    If the cacerts file cannot be found in your JAVA_HOME/lib/security/, try searching the system for the file named cacerts located in the Java install path.

    You should be prompted for a password (non-blank). Attempt to authenticate using the default password 'changeit'

    If you fail to authenticate, you will receive a warning message (and the contents of the keystore will still be displayed):

    ***************** WARNING WARNING WARNING *****************

    * The integrity of the information stored in your keystore *

    * has NOT been verified! In order to verify its integrity, *

    * you must provide your keystore password. *

    ***************** WARNING WARNING WARNING *****************

    Using the default password 'changeit' should fail to authenticate and thus produce the warning. If the default password successfully authenticates, this check fails.

    Remediation instructions

    Add a password to the default Java cacerts keystore:

    keytool -storepasswd -keystore [PATH TO KEYSTORE]
    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:400301
    File: eap5-ocil.xml

    2.23 - Ensure Security Audit Appender is enabled

    The Security Audit Appender must be enabled. The Security Audit Appender and the Security Audit Provider category together set up the audit infrastructure that allows deployed applications to easily audit authentication and authorization events.

    Rationale

    Enabling the Security Audit Appender is a necessary component of comprehensive auditing in a secure production environment.

    Additional information

    CVSSv2 Risk Assessment: 4 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: AU-12

    DoD 8500.2 Mapping: ECAT-1,ECAT-2

    Remediation instructions

    Ensure the Security Audit Appender is defined within JBOSS_HOME/server/[PROFILE]/conf/jboss-log4j.xml. By default, the Security Audit Appender exists and just needs to be uncommented.

    <!-- Security AUDIT Appender -->
<appender name="AUDIT" class="org.jboss.logging.appender.DailyRollingFileAppender">
	<errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
	<param name="File" value="${JBoss.server.log.dir}/audit.log"/>
	<param name="Append" value="true"/>
	<param name="DatePattern" value="'.'yyyy-MM-dd"/>
	<layout class="org.apache.log4j.PatternLayout">
		<param name="ConversionPattern" value="%d %-5p [%c] (%t:%x) %m%n"/>
	</layout>
</appender>
    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://oval.mitre.org/XMLSchema/oval-definitions-5
    Name: oval:com.redhat.eap5.scap:def:201901
    File: eap5-oval.xml

    2.24 - Ensure Security Audit Provider is enabled

    The Security Audit Provider category must be enabled for production environments. The Security Audit Appender and the Security Audit Provider category together set up the audit infrastructure that allows deployed applications to easily audit authentication and authorization events.

    Rationale

    Enabling the Security Audit Provider category is a necessary component of comprehensive auditing in a secure production environment.

    Additional information

    CVSSv2 Risk Assessment: 4 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: AU-12

    DoD 8500.2 Mapping: ECAT-1,ECAT-2

    Remediation instructions

    Ensure the Security Audit Provider category is defined within JBOSS_HOME/server/[PROFILE]/conf/jboss-log4j.xml. By default, the Security Audit Provider category exists and just needs to be uncommented.

    <!-- Category specifically for Security Audit Provider -->
<category name="org.jboss.security.audit.providers.LogAuditProvider" additivity="false">
	<priority value="TRACE"/>
	<appender-ref ref="AUDIT"/>
</category>
    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://oval.mitre.org/XMLSchema/oval-definitions-5
    Name: oval:com.redhat.eap5.scap:def:202001
    File: eap5-oval.xml

    2.25 - Ensure Configure SecurityInterceptor logging level is set correctly

    Production environments of JBoss require enhanced auditing on the SecurityInterceptor class.

    Rationale

    Enabling TRACE priority logging on the SecurityInterceptor class is a necessary component of comprehensive auditing in a secure production environment.

    Additional information

    CVSSv2 Risk Assessment: 4 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: AU-12

    DoD 8500.2 Mapping: ECAT-1,ECAT-2

    Remediation instructions

    Ensure a category is defined for SecurityInterceptor class with a priority of TRACE within JBOSS_HOME/server/[PROFILE]/conf/jboss-log4j.xml.

    <category name="org.jboss.ejb.plugins.SecurityInterceptor">
	<priority value="TRACE" />
	<appender-ref ref="AUDIT" />
</category>
    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://oval.mitre.org/XMLSchema/oval-definitions-5
    Name: oval:com.redhat.eap5.scap:def:202101
    File: eap5-oval.xml

    2.26 - Ensure logging is enabled for Microcontainer bootstrap operations

    Production environments of JBoss require auditing for Microcontainer bootstrap operations.

    Rationale

    Logging Microcontainer bootstrap operations is a necessary component of comprehensive auditing in a secure production environment.

    Additional information

    CVSSv2 Risk Assessment: 4 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: AU-3,AU-12

    DoD 8500.2 Mapping: ECAR-1,ECAR-2,ECAR-3,ECLC-1,ECAT-1,ECAT-2

    Remediation instructions

    Set the priority and appender-ref levels for the Microcontainer bootstrap by adding the <category> block as specified to JBOSS_HOME/server/[PROFILE]/conf/jboss-log4j.xml.

    <category name="org.jboss.bootstrap.microcontainer">
	<priority value="INFO"/>
	<appender-ref ref="AUDIT"/>
</category>
    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://oval.mitre.org/XMLSchema/oval-definitions-5
    Name: oval:com.redhat.eap5.scap:def:202201
    File: eap5-oval.xml

    2.27 - Ensure logging is enabled for web-based requests if required by deployed applications

    In the event that application requirements dictate additional logging for web-based requests, the AccessLogValve should be enabled.

    Rationale

    If application owners determine that additional logging of web-based requests is desired, it should be enabled.

    Additional information

    CVSSv2 Risk Assessment: 4 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: AU-3,AU-12

    DoD 8500.2 Mapping: ECAR-1,ECAR-2,ECAR-3,ECLC-1,ECAT-1,ECAT-2

    Validation instructions

    If logging of web-based requests has been required for deployed applications the AccessLogValve should be enabled. To check the status of the <Valve>, ensure the following element is defined within JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml.

    <Valve className="org.apache.catalina.valves.AccessLogValve" prefix="localhost_access_log." suffix=".log" pattern="common" directory="${JBoss.server.home.dir}/log" resolveHosts="false" />
    Remediation instructions

    Ensure the following <Valve> exists within: JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. By default, this <Valve> simply needs to be uncommented.

    <Valve className="org.apache.catalina.valves.AccessLogValve" prefix="localhost_access_log." suffix=".log" pattern="common" directory="${JBoss.server.home.dir}/log" resolveHosts="false" />
    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:202301
    File: eap5-ocil.xml

    2.28 - Ensure all required information is displayed in <layout>

    The Security Audit Appender must log all identified information.

    Rationale

    Logging full event information to the Security Audit Appender is a necessary component of comprehensive auditing in a secure production environment.

    Additional information

    CVSSv2 Risk Assessment: 3 / Low

    DoD Risk Category: CAT III

    NIST 800.53 Mapping: AU-12

    DoD 8500.2 Mapping: ECAT-1,ECAT-2

    Remediation instructions

    Enable server startup and shutdown events by making the following change to JBOSS_HOME/server/[PROFILE]/conf/jboss-log4j.xml. Update the ConversionPattern parameter in the Security Audit Appender to show thread information by replacing the default ConversionPattern with the pattern below:

    <!--The full pattern: Date MS Priority [Category] (Thread:NDC) Message -->
<layout class="org.apache.log4j.PatternLayout">
	<param name="ConversionPattern" value="%d %-5r %-5p [%c] (%t:%x) %m%n"/>
</layout>
    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://oval.mitre.org/XMLSchema/oval-definitions-5
    Name: oval:com.redhat.eap5.scap:def:202401
    File: eap5-oval.xml

    2.29 - Production applications should not log output to the JBoss console

    Turn off console logging in production. Console logging in a production environment is a needless drain on system resources.

    Rationale

    Logging to console is a potentially resource intensive activity that should be disabled in production environments. Additionally, disabling console logging removes a potential source of information leakage.

    Additional information

    CVSSv2 Risk Assessment: 3 / Low

    DoD Risk Category: CAT III

    NIST 800.53 Mapping: AU-9

    DoD 8500.2 Mapping: ECTB-1,ECTP-1

    Remediation instructions

    In order to prevent JBoss from logging to console, open the JBOSS_HOME/server/[PROFILE]/conf/jboss-log4j.xml file. Next, remove or comment out the <appender-ref> element with a ref attribute value of 'CONSOLE'. This <appender-ref> element will be a child of the <root> element, typically located near the end of the document.

    <root>
<!--Set the root logger priority via a system property. Note this is parsed by log4j,
so the full JBoss system property format is not supported; e.g.
setting a default via ${jboss.server.log.threshold:WARN} will not work.-->
	<priority value="${jboss.server.log.threshold}"/>
		<!-- appender-ref ref="CONSOLE"/ -->
	<appender-ref ref="ASYNC"/>
</root>
    References

    1. JBoss Enterprise Application Platform 5 Security Guide, 2011

    Check Summary

    System: http://oval.mitre.org/XMLSchema/oval-definitions-5
    Name: oval:com.redhat.eap5.scap:def:110301
    File: eap5-oval.xml

    2.30 - Ensure JBoss process owner is executing with least privilege

    Operating environment permissions assigned to the JBoss process owner should be in compliance with the principle of least privilege.

    Rationale

    In order to reduce the potential impact of exploitation against the JBoss application server (and the rest of the operating environment), the JBoss process owner should execute with as few permissions as possible in the environment (if the account is not local to the operating system or is distributed across multiple operating systems). Failure to limit permissions can dramatically increase the severity of exploits against the JBoss server, such as the execution of arbitrary code.

    Additional information

    CVSSv2 Risk Assessment: 5.1 / Medium - CVSSv2 Formula: (AV:N/AC:H/Au:N/C:P/I:P/A:P)

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: AC-6

    DoD 8500.2 Mapping: ECLP-1

    Validation instructions

    Work with the JBoss administrator to identify the JBoss process owner account. Determine if the account is local to the host operating system or is elsewhere in the environment. On Red Hat or Linux systems look for a service definition for JBoss within /etc/init.d/. On Windows systems, check for a service definition within the Services console (services.msc). Assuming JBoss is running, either operating system can also determine the JBoss process owner by examining the currently executing process.

    Next, work with the JBoss administrator to identify the permissions the JBoss process owner executes with. This procedure will vary based on the host operating system. On Red Hat or Linux systems, check the group membership for the account. On Windows systems, review the User Rights Assignments within the Local Security Policy console (secpol.msc).

    This check fails if the JBoss process owner is not executing with least privileges. The following list identifies common scenario failures:

    • The JBoss process owner is a privileged account such as root or administrator.
    • The JBoss process owner is a member of a privileged group, such wheel, root, administrators, power users, domain admins, backup operators, etc.
    • The JBoss process owner is used by multiple applications via use of username and password or group membership.
    • The JBoss process owner account has unnecessary network access to other operating systems or other network nodes, typically through the use of a directory based account with no logon restrictions.

    Remediation instructions

    Steps for implementing this configuration will vary dependent upon operating system. On Red Hat or Linux systems, use /etc/group and /etc/passwd to assign the JBoss process owner a unique local account and group (and limit its group membership). Windows systems can create local accounts through the Computer Management console (compmgmt.msc) and User Rights Assignments managed through the Local Security Policy console (secpol.msc)..

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:400401
    File: eap5-ocil.xml

    2.31 - Deny the JBoss process owner console access

    The JBoss Application Server process owner should not have interactive console login access.

    Rationale

    In order to limit access in the event of an exploitation of the Jboss or one of its deployed applications, the account owning the Jboss process should be limited in its ability to interact with the supporting operating system where possible. Thus, the JBoss process owner account should not have interactive console access.

    Additional information

    CVSSv2 Risk Assessment: 4.1 / Medium - CVSSv2 Formula: (AV:L/AC:M/Au:S/C:P/I:P/A:P)

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: AC-6

    Validation instructions

    Steps for validating this configuration will vary, dependent upon operating system:

    Red Hat Enterprise Linux: Interview JBoss administrators or review running processes with ps to identify the JBoss process owner account. Next, review the /etc/passwd file to ensure that the JBoss process owner account is not assigned a login shell (the shell field should read /sbin/nologin).

    Windows: Interview JBoss administrators, review the configured JBoss service, review running process with WMI or task manager to identify the JBoss process owner account. Next, using Local Security Policy Microsoft Management Console or Resultant Set of Policy MMC, ensure the JBoss process owner account has been added to the 'Deny logon locally' security policy and 'Deny log on through Remote Desktop Services' security policy.

    Remediation instructions

    Steps for implementing this configuration will vary, dependent upon operating system:

    Red Hat Enterprise Linux: To prevent users from gaining interactive access to the system console, simply ensure that they are assigned no shell interpreter via the /etc/passwd file. For instance, a properly configured passwd entry for the JBoss account owner may resemble this:

    jboss:x:494:494:JBossAS:/var/lib/jbossas:/sbin/nologin
    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html
    2. JBoss Enterprise Application Platform 5 Security Guide, 2011

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:109901
    File: eap5-ocil.xml

    2.32 - Set JBoss file ownership

    All JBoss Enterprise Application Platform files within JBOSS_HOME should be owned by the JBoss process owner account.

    Rationale

    To prevent unauthorized modification or disclosure of JBoss configuration settings, all files within JBOSS_HOME should be owned by the JBoss process owner account.

    Additional information

    CVSSv2 Risk Assessment: 3.7 / Medium - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:P/I:P/A:P)

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: AC-3

    DoD 8500.2 Mapping: ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1

    Validation instructions

    Validate file ownership for JBOSS_HOME files and subdirectories . Owner is required to be the JBoss process owner account. The JBoss administrators may have group ownership for operating systems that support it.

    Use the ls command to ensure the JBoss process owner owns all JBoss configuration files (JBOSS_HOME and subdirectories); JBoss administrators should be the group owners.

    Remediation instructions

    Steps for implementing this configuration will vary, dependent upon operating system.

    On Red Hat and Linux, use chown to ensure the JBoss process owner owns all JBoss configuration files (JBOSS_HOME and subdirectories); JBoss administrators may be the group owners.

    Windows environments can use the explorer GUI or cacls/xcacls to ensure the JBoss process owner owns all JBoss configuration files (JBOSS_HOME and subdirectories).

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:116201
    File: eap5-ocil.xml

    2.33 - Set JBoss file permissions

    All JBoss Enterprise Application Platform files within JBOSS_HOME should be readable by the JBoss Application Server process owner and JBoss administrators only.

    Rationale

    To prevent unauthorized modification or disclosure of JBoss configuration settings, access to all JBoss related files within JBOSS_HOME should be restricted to the JBoss process owner and JBoss administrators.

    Additional information

    CVSSv2 Risk Assessment: 4.3 / Medium - CVSSv2 Formula: (AV:L/AC:L/Au:S/C:P/I:P/A:P)

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: AC-3,AC-6

    DoD 8500.2 Mapping: ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1,ECLP-1

    Validation instructions

    Validate file permissions for JBOSS_HOME files and subdirectories. File permissions should be restricted to READ/WRITE for JBoss process owner and JBoss administrators. Other accounts that may require READ access include version control accounts or process owners for backup software.

    Red Hat Enterprise Linux: Use the ls command to check basic file permissions. The getfacl command can be useful as well.

    Remediation instructions

    Steps for implementing this configuration will vary, dependent upon operating system.

    Red Hat Enterprise Linux: Use chmod to restrict permissions on files to at least 660 for all files in JBOSS_HOME and subdirectories.

    Windows environments can use the explorer GUI or cacls/xcacls to restrict permissions for all files in JBOSS_HOME and subdirectories.

    File permissions should be restricted to READ/WRITE for JBoss process owner and JBoss administrators. Other accounts that may require READ access include version control accounts or process owners for backup software.

    References

    1. JBoss Enterprise Application Platform 5 Security Guide, 2011

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:109801
    File: eap5-ocil.xml

    Securing deployed applications

    The rules in this group are used to secure applications deployed on JBoss EAP. This includes applications that JBoss packages and deploys by default.

    3.1 - Ensure JMX Console is either secured or removed

    The JMX Console application must be secured so it is accessible by trusted administrators only. If this condition is not met, the application must be removed (deleted) from deployment.

    Rationale

    The JMX Console should require authentication or be removed. Failure to require authentication may allow unauthenticated users to invoke commands or gather information on the JBoss server. This access can be leveraged to do many things, including loading additional code from a malicious source.

    Additional information

    CVSSv2 Risk Assessment: 8 / High - CVSSv2 Formula: (AV:N/AC:L/Au:S/C:P/I:P/A:C)

    DoD Risk Category: CAT I

    NIST 800.53 Mapping: AC-3

    DoD 8500.2 Mapping: ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1

    Validation instructions

    This rule can be checked for compliance by either:

    1. Determine the console is not deployed.
      1. To determine if the JMX Console is deployed, check to see if the exploded WAR located is located here: JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/
    2. If the console is deployed, it must require authentication. Review the defined <security-domain> for the console.
      1. To determine if authentication is required, first check the JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/WEB-INF/jboss-web.xml file to ensure that a security domain has been referenced (example: <security-domain>java:/jaas/jmx-console</security-domain>).
      2. Next, ensure that an <application-policy> element is defined that matches the <security-domain> referenced by the jboss-web.xml file. These <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.
        • JBOSS_HOME/server/[PROFILE]/conf/login-config.xml
        • JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/META-INF/*-jboss-beans.xml
        • JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/WEB-INF/*-jboss-beans.xml
        • JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml
      3. Check the <application-policy> element to ensure it requires authentication. Example of a satisfactory element: 
        <application-policy name="jmx-console">
	<authentication>
		<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
			<module-option name="usersProperties">props/jmx-console-users.properties</module-option>
			<module-option name="rolesProperties">props/jmx-console-roles.properties</module-option>
		</login-module>
	</authentication>
</application-policy>
    Remediation instructions

    This rule can be made compliant by either:

    1. Require authentication for access to the JBoss JMX Console.
      1. First, ensure that an <application-policy> element is defined that requires authentication. Default policies exist for jmx-console and web-console. Example of a satisfactory element: 
        <application-policy name="jmx-console">
	<authentication>
		<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
			<module-option name="usersProperties">props/jmx-console-users.properties</module-option>
			<module-option name="rolesProperties">props/jmx-console-roles.properties</module-option>	
		</login-module> 
	</authentication> 
</application-policy>

        These <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.

        JBOSS_HOME/server/[PROFILE]/conf/login-config.xml
        JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/META-INF/*-jboss-beans.xml
        JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/WEB-INF/*-jboss-beans.xml
        JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml

      2. Next, check the JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/WEB-INF/jboss-web.xml file to ensure that a security domain requiring authentication has been referenced (example: <security-domain>java:/jaas/jmx-console</security-domain>). If no <security-domain> element exists, add it as a child of <jboss-web>.
      3. Next, review the JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/WEB-INF/web.xml. The <security-constraint> must not contain the default limitations on HTTP verbs. For example: <http-method>GET</http-method> or <http-method>POST</http-method>. The default limitations were shown to allow side channel access to malicious users.
      4. Finally, configure the usersProperties defined in the application policy to manage accounts. Example editing JBOSS_HOME/server/[PROFILE]/conf/props/jmx-console-users.properties: 
        # A sample users.properties file for use with the UsersRolesLoginModule
admin=1qaz!QAZ2wsx@WSX
    2. Remove the JBoss JMX Console from deployment.
      1. To remove the JMX Console from deployment, delete the exploded WAR located here: JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war/
    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://oval.mitre.org/XMLSchema/oval-definitions-5
    Name: oval:com.redhat.eap5.scap:def:200601
    File: eap5-oval.xml

    3.2 - Ensure Web Console is either secured or removed

    The Web Console application must be secured so it is accessible by trusted administrators only. If this condition is not met, the application must be removed (deleted) from deployment.

    Rationale

    Failure to secure the default consoles against unauthorized access can quickly lead to system compromise. The default consoles included with JBoss are a well-known attack vector that can be leveraged to load malicious code to be executed on the server.

    Additional information

    CVSSv2 Risk Assessment: 8 / High - CVSSv2 Formula: (AV:N/AC:L/Au:S/C:P/I:P/A:C)

    DoD Risk Category: CAT I

    NIST 800.53 Mapping: AC-3

    DoD 8500.2 Mapping: ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1

    Validation instructions

    This rule can be checked for compliance by either:

    1. Determine the console is not deployed.
      1. To determine if the Web Console is deployed, check to see if the exploded SAR located is located here: JBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/
    2. If the console is deployed, it must require authentication. Review the defined <security-domain> for the console.
      1. To determine if authentication is required, first check the JBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/WEB-INF/jboss-web.xml file to ensure that a security domain has been referenced (example: <security-domain>java:/jaas/web-console</security-domain>).
      2. Next, ensure that an <application-policy> element is defined that matches the <security-domain> referenced by the jboss-web.xml file. These <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.
        • JBOSS_HOME/server/[PROFILE]/conf/login-config.xml
        • JBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/META-INF/*-jboss-beans.xml
        • JBOSS_HOME/server/[PROFILE]/deploy//management/console-mgr.sar/web-console.war/WEB-INF/*-jboss-beans.xml
        • JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml
      3. Check the <application-policy> element to ensure it requires authentication. Example of a satisfactory element: 
        <application-policy name="web-console">
	<authentication>
		<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
			<module-option name="usersProperties">web-console-users.properties</module-option>
			<module-option name="rolesProperties">web-console-roles.properties</module-option>
		</login-module>
	</authentication>
</application-policy>
    Remediation instructions

    This rule can be made compliant by either:

    1. Require authorization for access to the JBoss Web Console.
      1. First, ensure that an <application-policy> element is defined that requires authentication. Default policies exist for jmx-console and web-console. Example of a satisfactory element: 
        <application-policy name="web-console">
	<authentication>
		<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
			<module-option name="usersProperties">web-console-users.properties</module-option>
			<module-option name="rolesProperties">web-console-roles.properties</module-option>
		</login-module>
	</authentication>
</application-policy>

        These <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.

        • JBOSS_HOME/server/[PROFILE]/conf/login-config.xml
        • JBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/META-INF/*-jboss-beans.xml
        • JBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/WEB-INF/*-jboss-beans.xml
        • JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml
      2. Next, check the JBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/WEB-INF/jboss-web.xml file to ensure that a security domain requiring authentication has been referenced (example: <security-domain>java:/jaas/web-console</security-domain>). If no <security-domain> element exists, add it as a child of <jboss-web>.
      3. Next, review the JBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/WEB-INF/web.xml. The <security-constraint> must not contain the default limitations on HTTP verbs. For example: <http-method>GET</http-method> or <http-method>POST</http-method>. The default limitations were shown to allow sidechannel access to malicious users.
      4. Finally, configure the usersProperties and rolesProperties files defined in the application policy to manage users and roles. Example editing JBOSS_HOME/server/[PROFILE]/conf/props/web-console-users.properties: 
        # A sample users.properties file for use with the UsersRolesLoginModule
admin=1qaz!QAZ2wsx@WSX
    2. Remove the JBoss Web Console from deployment.
      1. To remove the Web Console from deployment, delete the exploded SAR located here: JBOSS_HOME/server/[PROFILE]/deploy/management/
    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://oval.mitre.org/XMLSchema/oval-definitions-5
    Name: oval:com.redhat.eap5.scap:def:200701
    File: eap5-oval.xml

    3.3 - Ensure Administration Console is either secured or removed

    The Administration Console application must be secured so it is accessible by trusted administrators only. If this condition is not met, the application must be removed (deleted) from deployment.

    Rationale

    Failure to secure the default consoles against unauthorized access can quickly lead to system compromise. The default consoles included with JBoss are a well-known attack vector that can be leveraged to load malicious code to be executed on the server.

    Additional information

    CVSSv2 Risk Assessment: 8 / High - CVSSv2 Formula: (AV:N/AC:L/Au:S/C:P/I:P/A:C)

    DoD Risk Category: CAT I

    NIST 800.53 Mapping: AC-3

    DoD 8500.2 Mapping: ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1

    Validation instructions

    This rule can be checked for compliance by either:

    1. Determine the console is not deployed.
      1. To determine if the Administration Console is deployed, check to see if the exploded WAR located is located here: JBOSS_HOME/server/[PROFILE]/deploy/admin-console.war/
    2. If the console is deployed, it must require authentication. Review the defined <security-domain> for the console.
      1. To determine if authentication is required, first check the JBOSS_HOME/server/[PROFILE]/deploy/Administration-console.war/WEB-INF/jboss-web.xml file to ensure that a security domain has been referenced (example: <security-domain>java:/jaas/jmx-console</security-domain>).
      2. Next, ensure that an <application-policy> element is defined that matches the <security-domain> referenced by the jboss-web.xml file. These <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.
        • JBOSS_HOME/server/[PROFILE]/conf/login-config.xml
        • JBOSS_HOME/server/[PROFILE]/deploy/Administration-console.war/META-INF/*-jboss-beans.xml
        • JBOSS_HOME/server/[PROFILE]/deploy/Administration-console.war/WEB-INF/*-jboss-beans.xml
        • JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml
      3. Check the <application-policy> element to ensure it requires authentication. Example of a satisfactory element (this example leverages the pre-existing jmx-console policy): 
        <application-policy name="jmx-console">
	<authentication>
		<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
			<module-option name="usersProperties">props/jmx-console-users.properties</module-option>
			<module-option name="rolesProperties">props/jmx-console-roles.properties</module-option>
		</login-module>
	</authentication>
</application-policy>
      4. Finally, review the JBOSS_HOME/server/[PROFILE]/deploy/Administration-console.war/WEB-INF/web.xml. The <security-constraint> must not contain the default limitations on HTTP verbs. For example: <http-method>GET</http-method> or <http-method>POST</http-method>. The default limitations were shown to allow sidechannel access to malicious users.
    Remediation instructions

    This rule can be made compliant by either:

    1. Require authorization for access to the JBoss Administration Console.
      1. First, ensure that an <application-policy> element is defined that requires authentication. Default policies exist for jmx-console and web-console. Example of a satisfactory element: 
        <application-policy name="jmx-console">
	<authentication>
		<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
			<module-option name="usersProperties">web-console-users.properties</module-option>
			<module-option name="rolesProperties">web-console-roles.properties</module-option>
		</login-module>
	</authentication>
</application-policy>

        These <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.

        • JBOSS_HOME/server/[PROFILE]/conf/login-config.xml
        • JBOSS_HOME/server/[PROFILE]/deploy/Administration-console.war/META-INF/*-jboss-beans.xml
        • JBOSS_HOME/server/[PROFILE]/deploy/Administration-console.war/WEB-INF/*-jboss-beans.xml
        • JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml
      2. Next, check the JBOSS_HOME/server/[PROFILE]/deploy/management/console-mgr.sar/web-console.war/WEB-INF/jboss-web.xml file to ensure that a security domain requiring authentication has been referenced (example: <security-domain>java:/jaas/web-console</security-domain>). If no <security-domain> element exists, add it as a child of <jboss-web>.
      3. Next, review the JBOSS_HOME/server/[PROFILE]/deploy/Administration-console.war/WEB-INF/web.xml. The <security-constraint> must not contain the default limitations on HTTP verbs. For example: <http-method>GET</http-method> or <http-method>POST</http-method>. The default limitations were shown to allow sidechannel access to malicious users.
      4. Finally, configure the usersProperties and rolesProperties files defined in the application policy to manage users and roles. Example editing JBOSS_HOME/server/[PROFILE]/conf/props/jmx-console-users.properties: 
        # A sample users.properties file for use with the UsersRolesLoginModule
admin=1qaz!QAZ2wsx@WSX
    2. Remove the JBoss Administration Console from deployment.
      1. To remove the Administration Console from deployment, delete the exploded SAR located here: JBOSS_HOME/server/[PROFILE]/deploy/admin-console.war/
    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://oval.mitre.org/XMLSchema/oval-definitions-5
    Name: oval:com.redhat.eap5.scap:def:200801
    File: eap5-oval.xml

    3.4 - The JMXInvokerServlet servlet must be secured against web attacks

    The httpha-invoker.sar found in the deploy directory is a service that provides RMI/HTTP access for EJBs and the JNDI Naming service. By default older JBoss versions ship with a default set of <http-method> that allow attackers to bypass the security policy for JMX Invoker.

    Rationale

    Removing the default <http-method> security constraints allows JBoss to apply configured security settings to all HTTP verbs instead of only those specified. This is a well-known attack vector and failing to remove these constraints may allow attackers to gain authenticated or unauthorized access to the JMXInvokerServlet.

    Additional information

    CVSSv2 Risk Assessment: 8.3 / High - CVSSv2 Formula: (AV:N/AC:M/Au:N/C:P/I:P/A:C)

    DoD Risk Category: CAT I

    NIST 800.53 Mapping: AC-3

    DoD 8500.2 Mapping: ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1

    Validation instructions

    Review JBOSS_HOME/server/[PROFILE]/deploy/httpha-invoker.sar/invoker.war/WEB-INF/web.xml to ensure the following lines have been removed:

    <http-method>GET</http-method>
<http-method>POST</http-method>
    Remediation instructions

    Within the JBOSS_HOME/server/[PROFILE]/deploy/httpha-invoker.sar/invoker.war/WEB-INF/web.xml file, the following lines must be removed from the web-app/security-constraint/web-resource-collection node:

    <http-method>GET</http-method>
<http-method>POST</http-method>
    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://oval.mitre.org/XMLSchema/oval-definitions-5
    Name: oval:com.redhat.eap5.scap:def:202901
    File: eap5-oval.xml

    3.5 - The JMXInvokerServlet servlet must be configured to prevent unprivileged access using authentication

    The jmx-invoker-service.xml is a service that exposes the JMX MBeanServer interface via an RMI compatible interface using the RMI/JRMP detached invoker service. This interface must be made unavailable to unprivileged users which can be done by using the org.jboss.jmx.connector.invoker.AuthenticationInterceptor interceptor for performing identification and authentication using JAAS.

    Rationale

    The JMXInvokerServlet should require authentication. Failure to require authentication may allow unauthenticated users to invoke commands on the JBoss server. This access can be leveraged to do many things, including loading additional code from a malicious source.

    Additional information

    CVSSv2 Risk Assessment: 8.3 / High - CVSSv2 Formula: (AV:N/AC:M/Au:N/C:P/I:P/A:C)

    DoD Risk Category: CAT I

    NIST 800.53 Mapping: IA-2,IA-3

    DoD 8500.2 Mapping: EBRU-1,IAIA-1,IAIA-2,IAGA-1

    Remediation instructions

    Open JBOSS_HOME/server/[PROFILE]/deploy/jmx-invoker-service.xml, and ensure the <operation> element with child element <name>invoke</name> also contains the following <interceptor>:

    <interceptors>
	<interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor" securityDomain="java:/jaas/jmx-console"/>
</interceptors>

    Next, ensure a valid authentication module is enabled for the security domain. For example, the following elements exist within logon-config.xml and implement authentication using the UsersRolesLoginModule:

    <application-policy name="jmx-console">
	<authentication>
		<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
			<module-option name="usersProperties">props/jmx-console-users.properties</module-option>
			<module-option name="rolesProperties">props/jmx-console-roles.properties</module-option>
		</login-module>
	</authentication>
</application-policy>

    NOTE: By default, this forces the invoker to authenticate against the jmx-console-users.properties file, located here: JBOSS_HOME/server/PROFILE/conf/prop/
    NOTE: The securityDomain does not have to be called jmx-console.

    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://oval.mitre.org/XMLSchema/oval-definitions-5
    Name: oval:com.redhat.eap5.scap:def:203001
    File: eap5-oval.xml

    3.6 - The JMXInvokerServlet servlet must be configured to prevent unprivileged access using authorization

    The jmx-invoker-service.xml is a service that exposes the JMX MBeanServer interface via an RMI compatible interface using the RMI/JRMP detached invoker service. Access control for authenticated users must be configured using the interceptors of either org.jboss.jmx.connector.invoker.RolesAuthorization or org.jboss.jmx.connector.invoker.ExternalizableRolesAuthorization.

    Rationale

    The JMXInvokerServlet should require authorization. Failure to require authorization may allow unauthenticated users to invoke commands on the JBoss server. This access can be leveraged to do many things, including loading additional code from a malicious source.

    Additional information

    CVSSv2 Risk Assessment: 8.3 / High - CVSSv2 Formula: (AV:N/AC:M/Au:N/C:P/I:P/A:C)

    DoD Risk Category: CAT I

    NIST 800.53 Mapping: AC-3,AC-6

    DoD 8500.2 Mapping: ECAN-1,ECCD-1,ECCD-2,ECCR-2,ECIC-1,ECAN-1,ECLP-1

    Remediation instructions

    Open JBOSS_HOME/server/[PROFILE]/deploy/jmx-invoker-service.xml, and ensure the <operation> element with child element <name>invoke</name> also contains the following <interceptor>:

    <interceptors>
	<interceptor code="org.jboss.jmx.connector.invoker.AuthorizationInterceptor" authorizingClass="org.jboss.jmx.connector.invoker.RolesAuthorization"/>
</interceptors>

    Next, ensure a valid authorization module is enabled for the security domain. For example, the following elements exist within logon-config.xml and implement authorization using the UsersRolesLoginModule:

    <application-policy name="jmx-console">
	<authentication>
		<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
			<module-option name="usersProperties">props/jmx-console-users.properties</module-option>
			<module-option name="rolesProperties">props/jmx-console-roles.properties</module-option>
		</login-module>
	</authentication>
</application-policy>

    NOTE: By default, this forces the invoker to authenticate against the jmx-console-users.properties file, located here: JBOSS_HOME/server/PROFILE/conf/prop/
    NOTE: The securityDomain does not have to be called jmx-console.

    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://oval.mitre.org/XMLSchema/oval-definitions-5
    Name: oval:com.redhat.eap5.scap:def:203101
    File: eap5-oval.xml

    3.7 - Deployed applications should display a system use banner upon access

    Upon accessing the system, a notification banner, consent to use, or policy warning banner should be displayed to alert system users of the system use details. This may include items such as implied consent to monitor, privacy practices, or liability waivers.

    Rationale

    Failing to provide adequate notification of system use details to users accessing the system can create legal troubles in the event of a civil lawsuit or criminal investigation.

    Additional information

    CVSSv2 Risk Assessment: 2.0 / Low

    DoD Risk Category: CAT III

    NIST 800.53 Mapping: AC-8

    DoD 8500.2 Mapping: ECWM-1

    Validation instructions

    Access all deployed applications to determine if a warning banner is displayed. A code review showing the functional code will also suffice.

    This warning banner should be presented to the user prior to accessing any deployed application - commercial applications, in-house applications, or applications deployed by JBoss.

    Remediation instructions

    Create a system use notification message for all users who access the system. This can be done in a variety of ways, but a simple JavaScript alert(); containing a warning message will suffice. This warning banner should be presented to the user prior to accessing any deployed application - commercial applications, in-house applications, or applications deployed by JBoss. The contents of the system use notification should be clear, concise, in keeping with the organizational security policy, and should have been reviewed by the organization's legal team.

    On DoD systems, the warning banner should read:

    You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.

    By using this IS (which includes any device attached to this IS), you consent to the following conditions:

    -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.

    -At any time, the USG may inspect and seize data stored on this IS.

    -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.

    -This IS includes security measures (e.g., authentication and access controls) to protect USG interests—not for your personal benefit or privacy.

    -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:300601
    File: eap5-ocil.xml

    3.8 - Deployed applications should display a classification banner when required

    Deployed applications should present classification banners at the header and footer of each page in accordance with the applicable DoD classification guide for the environment (or in accordance with local security policies).

    Rationale

    Prominent classification banners reduce the risk of inadvertent information disclosure or data spillage across different classification levels.

    Additional information

    CVSSv2 Risk Assessment: 2.0 / Low

    DoD Risk Category: CAT III

    NIST 800.53 Mapping: AC-8

    DoD 8500.2 Mapping: ECWM-1

    Validation instructions

    Access all deployed applications to determine if classification banners are displayed in accordance with the authoritative classification guide or local security policies. A code review showing the functional code will also suffice.

    These classification banners should be presented to the user on all deployed applications - commercial applications, in-house applications, and even default applications deployed by JBoss. The exact banner requirements such as text, color, and placement will vary dependent on the system classification. See the classification guide or local security manager for further guidance.

    Remediation instructions

    Create system classification banners for all deployed applications. This can be done in a variety of ways, but using a simple linked JavaScript to create header/footer SPAN tags with inline CSS will fit the requirements.

    References

    1. Department of Defense, (1997). Information Security Program (DoD 5200.1-R)

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:300701
    File: eap5-ocil.xml

    3.9 - Password hashing must be enabled within the appropriate login module

    A Security Domain is a set of authentication, authorization, and mapping policies defined in XML and are available to applications at runtime using Java Naming and Directory Interface (JNDI).

    Rationale

    Failure to enable password hashing within a login module can result in plain-text exposure client passwords used for authentication.

    Additional information

    CVSSv2 Risk Assessment: 4.3 / Medium - CVSSv2 Formula: (AV:A/AC:M/Au:N/C:P/I:P/A:N)

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: SC-8,SC-9

    DoD 8500.2 Mapping: ECTM-1,ECTM-2,ECCT-1,ECCT-2,ECNK-1,ECNK-2

    Validation instructions

    To determine which <application-policy> are in use by deployed applications, search for <security-domain> elements within the following deployment descriptors:

    JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/jboss-web.xml
    JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/jboss.xml

    An <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.

    • JBOSS_HOME/server/[PROFILE]/conf/login-config.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml

    The element below should be included within a deployed application's <application-policy><login-module>:

    <module-option name="hashUserPassword">true</module-option>
    Remediation instructions

    Add the following child element to any <application-policy><login-module> in use:

    <module-option name="hashUserPassword">true</module-option>

    An <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.

    • JBOSS_HOME/server/[PROFILE]/conf/login-config.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml
    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:201501
    File: eap5-ocil.xml

    3.10 - A password hashing algorithm must be defined within the appropriate login module

    A Security Domain is a set of authentication, authorization, and mapping policies defined in XML and are available to applications at runtime using Java Naming and Directory Interface (JNDI). An <application-policy> can be defined in the server profile or in an application deployment descriptor.

    Rationale

    By default, a hashing algorithm is not identified for hashing clear-text passwords. DoD organizations should use the SHA algorithm or higher whenever possible to prevent collision attacks against captured password hashes.

    Additional information

    CVSSv2 Risk Assessment: 4.3 / Medium - CVSSv2 Formula: (AV:A/AC:M/Au:N/C:P/I:P/A:N)

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: SC-8,SC-9

    DoD 8500.2 Mapping: ECTM-1,ECTM-2,ECCT-1,ECCT-2,ECNK-1,ECNK-2

    Validation instructions

    To determine which <application-policy> are in use by deployed applications, search for <security-domain> elements within the following deployment descriptors:

    JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/jboss-web.xml
    JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/jboss.xml

    An <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.

    • JBOSS_HOME/server/[PROFILE]/conf/login-config.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml

    The element should be included within a deployed application's <application-policy><login-module>:

    <module-option name="hashAlgorithm">SHA</module-option>
    Remediation instructions

    Add the following child element to any <application-policy><login-module> in use:

    <module-option name="hashAlgorithm">SHA</module-option>

    An <application-policy> can be defined in the server profile conf directory, in an application deployment descriptor, or directly deployed as an MBean.

    • JBOSS_HOME/server/[PROFILE]/conf/login-config.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/META-INF/*-jboss-beans.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/[APPLICATION]/WEB-INF/*-jboss-beans.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/*-jboss-beans.xml
    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:201701
    File: eap5-ocil.xml

    3.11 - Enterprise JavaBeans Specification v2.1 must be strictly followed

    The programming restrictions mandated by the Enterprise JavaBeans Specification v2.1 must be strictly followed. For more information, refer to JSR-000153 Enterprise JavaBeans 2.1 specification. (Section 25.2, pages 562-564).

    Rationale

    Deployed applications should follow identified standards, procedures, and best practices. Compliance has many benefits, including helping applications stay interoperable with other programs and containers, implementing strong security and code standards, and improving performance and efficiency.

    Additional information

    CVSSv2 Risk Assessment: 6 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: CM-6

    DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1

    Validation instructions

    Interview developers or review product documentation to determine if deployed applications were developed in accordance with Enterprise JavaBeans 2.1 specifications. The list below denotes the restrictions identified by the specification.

    • An enterprise bean must not use read/write static fields. Using read-only static fields is allowed. Therefore, it is recommended that all static fields in the enterprise bean class be declared as final.
    • An enterprise bean must not use thread synchronization primitives to synchronize execution of multiple instances.
    • An enterprise bean must not use the AWT functionality to attempt to output information to a display, or to input information from a keyboard.
    • An enterprise bean must not use the java.io package to attempt to access files and directories in the file system.
    • An enterprise bean must not attempt to listen on a socket, accept connections on a socket, or use a socket for multicast.
    • The enterprise bean must not attempt to query a class to obtain information about the declared members that are not otherwise accessible to the enterprise bean because of the security rules of the Java language. The enterprise bean must not attempt to use the Reflection API to access information that the security rules of the Java programming language make unavailable.
    • The enterprise bean must not attempt to create a class loader; obtain the current class loader; set the context class loader; set security manager; create a new security manager; stop the JVM; or change the input, output, and error streams.
    • The enterprise bean must not attempt to set the socket factory used by ServerSocket, Socket, or the stream handler factory used by URL.
    • The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread, or to change a thread’s priority or name. The enterprise bean must not attempt to manage thread groups.
    • The enterprise bean must not attempt to directly read or write a file descriptor.
    • The enterprise bean must not attempt to obtain the security policy information for a particular code source.
    • The enterprise bean must not attempt to load a native library.
    • The enterprise bean must not attempt to gain access to packages and classes that the usual rules of the Java programming language make unavailable to the enterprise bean.
    • The enterprise bean must not attempt to define a class in a package.
    • The enterprise bean must not attempt to access or modify the security configuration objects (Policy, Security, Provider, Signer, and Identity).
    • The enterprise bean must not attempt to use the subclass and object substitution features of the Java Serialization Protocol.
    • The enterprise bean must not attempt to pass this as an argument or method result. The enterprise bean must pass the result of SessionContext.getEJBObject, Session-Context.getEJBLocalObject, EntityContext.getEJBObject,or Entity-Context.getEJBLocalObject instead.
    Remediation instructions

    Developers must follow Enterprise JavaBeans Specification v2.1.

    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:206801
    File: eap5-ocil.xml

    Policy

    The rules in this group are used to manage JBoss servers in a secure manner. These rules are policy related.

    4.1 - Ensure adequate physical protections are in place

    The hardware and software executing JBoss Enterprise Application Platform, as well as the software critical to security policy enforcement must be protected from unauthorized modification including unauthorized modifications by potentially hostile outsiders. Reasonable physical security measures to ensure that unauthorized personnel do not have physical access to the hardware running the JBoss Enterprise Application Platform software must be implemented.

    Rationale

    Many software security precautions can easily be bypassed by personnel with physical access to hardware storing data or executing an application.

    Additional information

    CVSSv2 Risk Assessment: 6.9 / High - CVSSv2 Formula: (AV:L/AC:M/Au:N/C:C/I:C/A:C)

    DoD Risk Category: CAT I

    NIST 800.53 Mapping: PE-1,PE-2,PE-3,PE-7,PE-18

    DoD 8500.2 Mapping: PEPF-1,PEPF-2,PECF-1,PECF-2,PEPS-1,PEVC-1

    Validation instructions

    Interview JBoss administrators and security personnel. Visually inspect physical security precautions. Review space certifications where appropriate.

    Remediation instructions

    Implement reasonable physical access controls to protect the hardware running and storing information for JBoss Enterprise Application Platform. Typically, these sorts of protections will include locked doors, locked server cabinets, security alarms, cameras, door guards, etc. What is considered 'reasonable' will scale with the importance of the JBoss server and the sensitivity of the information it processes.

    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:206201
    File: eap5-ocil.xml

    4.2 - Assign a JBoss administrator

    There must be one or more competent individuals who are assigned to manage JBoss Enterprise Application Platform, its environment and the security of the information it contains.

    Rationale

    Incompetent, careless, or negligent JBoss administrators can completely invalidate a secure JBoss configuration and create numberless problems for JBoss.

    Additional information

    CVSSv2 Risk Assessment: 8 / High

    DoD Risk Category: CAT I

    NIST 800.53 Mapping: AT-2,AT-3,AT-4

    DoD 8500.2 Mapping: PRTN-1,PETN-1

    Validation instructions

    Interview JBoss administrators. Review credentials and qualifications. JBoss Administrators should possess a basic level of proficiency with the software.

    Additionally, they must not be carelessly or willfully negligent, or hostile, and must follow the instructions provided by the administrator documentation.

    Remediation instructions

    Ensure a minimum level of competency / expertise has been established for JBoss administrators before granting them access to production systems.

    Ensure documentation and procedures exist (and are followed) for routine administrative tasks.

    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:206301
    File: eap5-ocil.xml

    4.3 - Document incident response procedures

    Ensure well developed procedures exist for incident handling. Incidents include any events that are anomalous to the environment, which typically include:

    • Intrusions (possibly including attempts)
    • Application failures
    • Unexpected platform activity such as restarts or configuration changes
    • Unusual network traffic to or from the server

    Rationale

    Planning for incidents prior to real-life scenarios increases incident response time and mitigates damages. Failure to adequately prepare, plan, and exercise for these scenarios can result in extensive losses.

    Additional information

    CVSSv2 Risk Assessment: 6 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: IR-1,IR-8

    DoD 8500.2 Mapping: VIIR-1,VIIR-2

    Validation instructions

    Interview JBoss administrators. Review system documentation, incident response documentation, contingency documentation, and any other relevant documentation. Determine if the incident response procedures in place are robust, up-to-date, and clear.

    Remediation instructions

    Draft formal incident response policies and procedures. Utilize national and international standards such as ISO/IEC TR 18044 or NIST Special Publication 800-61.

    References

    1. Mallik, R. (2011, May). Jboss in the Trenches.

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:112901
    File: eap5-ocil.xml

    4.4 - Perform periodic incident response exercises

    Production environments should exercise incident response procedures at least annually. Environments requiring higher assurances of security should test incident response procedures more often, possibly quarterly or even monthly. Incident response procedures should cover all anomalous events.

    Rationale

    Planning for incidents and practicing procedures to be followed prior to real-life scenario improves response time and mitigates damages/losses that occur with incidents.

    Additional information

    CVSSv2 Risk Assessment: 4 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: IR-3

    DoD 8500.2 Mapping: VIIR-1,VIIR-2

    Validation instructions

    Interview JBoss administrators. Review system documentation, incident response documentation, and any other relevant documentation. Review lessons-learned, after-action reports, or other historical documentation. Determine if the incident response procedures are meaningfully exercised at least annually.

    Remediation instructions

    Draft a schedule to ensure that documented procedures are exercised at least annually. More frequent exercises may be needed for some environments.

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:113301
    File: eap5-ocil.xml

    4.5 - Document disaster recovery procedures

    Robust disaster recovery documentation and procedures should exist. This documentation should include provisions for the JBoss platform, deployed applications, required source code, and supporting applications (such as authentication stores or database servers).

    Rationale

    Planning for disasters and extended outages prior to a real-life scenario helps mitigate losses associated with identified disasters. Failure to adequately prepare, plan, and exercise for these scenarios can result in extensive losses.

    Additional information

    CVSSv2 Risk Assessment: 6 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: CP-1,CP-2

    DoD 8500.2 Mapping: CODP-1,CODP-2,CODP-3,COEF-1,COEF-2

    Validation instructions

    Interview JBoss administrators. Review system documentation, disaster recovery documentation, contingency documentation, and any other relevant documentation. Determine if the disaster recovery procedures in place are robust, up-to-date, and feasible.

    Remediation instructions

    Draft formal disaster response policies and procedures. Utilize national and international standards such as ISO 17799 or NIST Special Publication 800-34.

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:113201
    File: eap5-ocil.xml

    4.6 - Perform periodic disaster recovery exercises

    Production environments should exercise disaster recovery procedures that include provisions for the JBoss platform, deployed applications, and any required source code at least annually. Environments requiring higher assurances of disaster recovery ability should test procedures more often, possibly quarterly or even monthly.

    Rationale

    Planning for disasters and extended outages prior to a real-life scenario helps mitigate losses associated with identified disasters. Failure to adequately prepare, plan, and exercise for these scenarios can result in extensive losses.

    Additional information

    CVSSv2 Risk Assessment: 4 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: CP-4

    DoD 8500.2 Mapping: DCSS-2,COED-1,COED-2

    Validation instructions

    Interview JBoss administrators. Review system documentation, disaster recovery documentation, contingency documentation, and any other relevant documentation. Review lessons-learned, after-action reports, or other historical documentation. Determine if the disaster recovery procedures are meaningfully exercised at least annually.

    Remediation instructions

    Draft a schedule to ensure that documented procedures are exercised at least annually. More frequent exercises may be needed for some environments.

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:113401
    File: eap5-ocil.xml

    4.7 - Identify and document application data flows

    It is recommended to identify and document application data flows. This will allow insight into what paths sensitive information takes through the application environment and what data source connections need to be encrypted.

    Rationale

    Failure to document an application's data flows reduces security, increases the chance for architectural and configuration errors, and can impede performance. Many applications use network services that are not immediately apparent.

    Additional information

    CVSSv2 Risk Assessment: 4.3 / Medium - CVSSv2 Formula: (AV:A/AC:M/Au:N/C:P/I:P/A:N)

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: SC-8,SC-9,SC-23

    DoD 8500.2 Mapping: ECTM-1,ECTM-2

    Validation instructions

    Examine application documentation, system architecture documentation, and any other pertinent diagrams. Interview JBoss administrators and application developers. Application data flows should be identified for all deployed applications, including the following information:

    • Relevant protocol information (for instance, TCP traffic should record port information)
    • Traffic destination
    • Purpose
    • Sensitivity of traffic
    • Applicable security information, such as encryption types, specific vulnerabilities in transport or application protocols, etc.
    Remediation instructions

    Work with JBoss administrators and application developers to document data flows for deployed applications. Information documented should include:

    • Relevant protocol information (for instance, TCP traffic should record port information)
    • Traffic destination
    • Purpose
    • Sensitivity of traffic
    • Applicable security information, such as encryption types, specific vulnerabilities in transport or application protocols, etc.
    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:113501
    File: eap5-ocil.xml

    4.8 - Java permissions for deployed applications should be documented and reviewed prior to deployment

    Java permissions for applications should be documented and carefully reviewed prior to deployment. Developers and administrators should strive to balance application permissions and application functionality.

    Rationale

    Java permissions for deployed applications should be carefully restricted to enforce the least privilege principle. Careful documentation, along with a thorough review will help prevent needlessly insecure permission assignments for applications. An overabundance of Java permissions can allow applications to circumvent one of Java's strongest security features - the Java Security Manager sandbox.

    Additional information

    CVSSv2 Risk Assessment: 5 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: AC-1

    Validation instructions

    Review documentation for an application's permission requirements. Review policy files to determine if applications are in compliance with their documentation. In a default JBoss deployment the following policy file will be utilized by JSM (review run.conf or run.conf.bat for more):

    • java.home/lib/security/java.security

    Additional policy files can be specified either at runtime (through run.conf or run.conf.bat) or by chaining existing policy files (policy.url.x=file:/user/application/java.policy)

    Remediation instructions

    The JBoss administrator must assign the most restrictive permissions possible (in accordance with the least privilege principle) for applications. This should be done in cooperation with application developers or application documentation.

    Further, documentation should exist for all applications that have been granted specific permissions.

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:115901
    File: eap5-ocil.xml

    4.9 - Regular backups should be performed

    JBoss applications and configuration files should be backed up at least weekly, possibly more if needed by the environment.

    Rationale

    Failure to regularly backup JBoss configuration files and deployed applications can result in extensive downtime or information losses in the event of a disaster or other system outage.

    Additional information

    CVSSv2 Risk Assessment: 6 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: CP-9

    DoD 8500.2 Mapping: DCSW-1,COBR-1,CODB-1,CODB-2,CODB-3,COSW-1,DCWH-1

    Validation instructions

    Interview JBoss administrators. Review backup policies, procedures, and other applicable documentation. Review backup media and validate presence of JBoss configuration files and deployed applications. Determine if JBoss configuration files and deployed applications are backed up at least once a week - or as specified by organization documentation.

    Remediation instructions

    Ensure backups are conducted regularly (at least once a week) in accordance with the organization backup-policy. All JBoss configuration files and deployed applications should be backed up.

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:114601
    File: eap5-ocil.xml

    4.10 - Auditing policy should exist

    In order to effectively audit and review system logs, an audit policy should be written to identify data and trends of interest.

    Rationale

    Without a comprehensive audit policy and review procedures, organizations risk missing critical events or event trends within their environment. These missed events may indicate system anomalies ranging from malicious attacks, system instabilities, system misuse, etc.

    Additional information

    CVSSv2 Risk Assessment: 4 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: AU-1,AU-2,AU-3,AU-5

    DoD 8500.2 Mapping: ECAR-1,ECAR-2,ECAR-3,ECLC-1,ECND-2

    Validation instructions

    Interview JBoss administrators. Review any available auditing documentation. Determine if the auditing policy is comprehensive and the auditing procedures are usable and up-to-date.

    Remediation instructions

    JBoss system administrators should work security team members to draft a comprehensive audit policy. Along with this auditing policy, a set of written procedures should be created that details what events or trends must be monitored, reactions, etc.

    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:115301
    File: eap5-ocil.xml

    4.11 - Access control policy and procedures

    JBoss administrators must have access to guidance regarding account creation, permissions assignments, role assignments, etc.

    Rationale

    A consistent, cohesive access control policy is impossible to attain without a well-documented access control policy and related procedures. Failure to do so typically results in over-assignment of access permissions for users and applications, stale access for users and applications, and other access control misconfigurations that reduce the effectiveness of the security policy.

    Additional information

    CVSSv2 Risk Assessment: 5 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: AC-1

    Validation instructions

    Interview JBoss administrators. Review all relevant documentation. Determine if an access control policy exists that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance. There should be an associated set of procedures with implementation details for specific tasks such as assigning user roles, creating user accounts, or assigning Java Security Manager permissions.

    Remediation instructions

    Draft an access control policy to address purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance. There should be an associated set of procedures with implementation details for specific tasks such as assigning user roles, creating user accounts, or assigning Java Security Manager permissions.

    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:116401
    File: eap5-ocil.xml

    4.12 - Define an appropriate minimum and maximum password length requirement

    Organizations should create an authenticator management policy that defines minimum and maximum password sizes for user accounts accessing JBoss and its deployed applications.

    Rationale

    In brute force scenarios, passwords of extended lengths increase password security and the length of time required to decrypt the password.

    However, there are risks associated with requiring passwords of great lengths, as users may take steps to circumvent policy; such as using repetitive passwords, writing password reminders, or writing down their passwords.

    Additional information

    CVSSv2 Risk Assessment: 5.0 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: IA-5

    DoD 8500.2 Mapping: IAIA-1,IAIA-2,IATS-1,IATS-2

    Validation instructions

    Work with JBoss administrators and security team members to identify and review relevant documentation. Minimum and maximum password lengths should be defined.

    Remediation instructions

    JBoss system administrators should work security team members to draft a comprehensive password policy. Minimum and maximum password lengths should be defined. Further, accounts may be categorized in order to define varying length requirements for particular types of accounts.

    For example:

    • User accounts shall require password lengths of between 8 and 24 characters
    • Administrator shall require password lengths of 24 characters
    • Web service accounts shall require password lengths of 24 characters

    Password storage software and password generation software are recommended for organizations to assist in managing a secure password policy. NIST Special Publication 800-118 (Draft) and NIST Special Publication 800-53 both contain extensive guidance on creating a password policy document.

    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html
    2. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Guide to Enterprise Password Management (Draft) (800-118). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:300301
    File: eap5-ocil.xml

    4.13 - Define an appropriate minimum password complexity requirement

    Organizations should create an authenticator management policy that defines a minimum level of complexity for user accounts accessing JBoss and its deployed applications. These requirements should also restrict passwords from containing dictionary words and reusing previous passwords.

    Rationale

    Complex passwords increase password security and the length of time required to decrypt the password. Additionally, complex passwords are less likely to be found in password dictionaries.

    However, there are risks associated with requiring overly complex passwords, as users may take steps to circumvent policy; such as using repetitive passwords, writing password reminders, or writing down their passwords.

    Additional information

    CVSSv2 Risk Assessment: 5.0 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: IA-5

    DoD 8500.2 Mapping: IAIA-1,IAIA-2,IATS-1,IATS-2

    Validation instructions

    Work with JBoss administrators and security team members to identify and review relevant documentation. Password complexity requirements should be defined. The policy should not allow passwords to be reused or contain dictionary words.

    Remediation instructions

    JBoss system administrators should work security team members to draft a comprehensive password policy. Password complexity requirements should be defined. The policy should not allow passwords to be reused or contain dictionary words. Further, accounts may be categorized in order to define varying complexity requirements for particular types of accounts.

    For example:

    • User accounts shall require passwords containing at least 1 lowercase alphanumeric character, 1 uppercase alphanumeric character, and 1 number
    • Administrator accounts shall require passwords containing at least 2 lowercase alphanumeric characters, 2 uppercase alphanumeric characters, 2 numbers, and 2 special characters. Special characters include: !@#$%^&*()
    • Web service accounts shall require passwords containing at least 3 lowercase alphanumeric characters, 3 uppercase alphanumeric characters, 3 numbers, and 3 special characters. Special characters include: !@#$%^&*()

    Password storage software and password generation software are recommended for organizations to assist in managing a secure password policy. NIST Special Publication 800-118 (Draft) and NIST Special Publication 800-53 both contain extensive guidance on creating a password policy document.

    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html
    2. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Guide to Enterprise Password Management (Draft) (800-118). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:300401
    File: eap5-ocil.xml

    4.14 - Define an appropriate minimum password expiration interval

    Organizations should create an authenticator management policy that defines a maximum password age for user accounts accessing JBoss and its deployed applications.

    Rationale

    In combination with password length and complexity, regularly changing passwords can defeat many attacks. If a password or password hash is intercepted by a malicious party, changing the password can remove access or render invalid a cracking attempt on the hash.

    However, there are risks associated with frequently changing passwords. Users may take steps to circumvent policy such as using repetitive passwords or using password derivatives. Additionally, changing passwords for system or application accounts introduces an element of configuration risk. Poorly coordinated or documented changes can result in system outages or create other problems.

    Additional information

    CVSSv2 Risk Assessment: 5.0 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: IA-5

    DoD 8500.2 Mapping: IAIA-1,IAIA-2,IATS-1,IATS-2

    Validation instructions

    Work with JBoss administrators and security team members to identify and review relevant documentation. Password complexity requirements should be defined. The policy should not allow passwords to be reused or contain dictionary words.

    Remediation instructions

    JBoss system administrators should work security team members to draft a comprehensive password policy. Password expiration requirements should be defined. Further, accounts may be categorized in order to define varying length requirements for particular types of accounts.

    For example:

    • Passwords for user accounts must expire every 90 days
    • Passwords for administrator accounts must expire every 30 days
    • Passwords for web service accounts must expire every 180 days

    Password storage software and password generation software are recommended for organizations to assist in managing a secure password policy. NIST Special Publication 800-118 (Draft) and NIST Special Publication 800-53 both contain extensive guidance on creating a password policy document.

    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html
    2. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Guide to Enterprise Password Management (Draft) (800-118). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:300501
    File: eap5-ocil.xml

    Architecture

    The rules in this group are used to manage JBoss servers in a secure manner. These rules are related to deploying a secure architecture.

    5.1 - Production JBoss EAP installations should reside on a dedicated platform

    Production JBoss servers in production environments should be hosted on dedicated operating systems and not sharing a host operating system with other service applications.

    Rationale

    Co-locating JBoss EAP with other critical infrastructure components in an organization can have multiple negative impacts on an organization's security posture. Applications sharing host operating systems cumulatively increase the surface area of attack for the other (including indirectly), increase the likelihood of resource contention, and increase the severity of any problems that do occur on the platform at a business process level.

    Additional information

    CVSSv2 Risk Assessment: 5 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: CM-6

    DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1

    Validation instructions

    Interview JBoss administrators, review system documentation and architecture diagrams. Review applications hosted by the same operating system as JBoss. Determine if JBoss Enterprise Application Platform installations are hosted on dedicated operating systems. JBoss installations should not be hosted by the same operating system that may be hosting other organization resources such as name resolution servers, directory servers, or database servers.

    Remediation instructions

    Installations of JBoss should reside on a dedicated operating system. If not, ensure the configuration, rationale, and risk assessment is well documented.

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:400101
    File: eap5-ocil.xml

    5.2 - Avoid multiple JBoss instances per server

    Multiple instances of JBoss deployed onto a single server should be avoided whenever possible to reduce environmental complexity and administrative burdens. However, occasionally circumstances require that multiple JBoss instances are deployed to the same server. In this scenario, the configurations and justifications should be documented along with the rest of the system's documentation.

    Rationale

    Multiple JBoss instances on a single server may occasionally become necessary due to resource or design constraints. However, this practice increases the complexity and administrative burden for the application servers - potentially leading to unforeseen problems and increasing chance of misconfigurations.

    Additional information

    CVSSv2 Risk Assessment: 5 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: CM-6

    DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1

    Validation instructions

    Interview JBoss administrators, review system documentation and architecture diagrams. Determine if JBoss Enterprise Application Platform installations are limited to one per server. If they are not limited to one per server, ensure the configuration, rationale, and risk assessment is well documented.

    Remediation instructions

    Limit JBoss Enterprise Applications Platform instances to one per server if possible. If not, ensure the configuration, rationale, and risk assessment is well documented.

    References

    1. Mallik, R. (2011, May). Jboss in the Trenches.

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:112401
    File: eap5-ocil.xml

    5.3 - Bind multiple JBoss instances per server to different IPs

    If multiple JBoss instances are installed, the servers should be set to bind to different IP addresses on the server rather than changing the default port configuration.

    Rationale

    Binding to different IP addresses eases administrative and maintenance burdens by reducing the number of variables between instances. In turn, this increases reliability and reduces the chances for configuration errors.

    Additional information

    CVSSv2 Risk Assessment: 3.5 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: CM-6

    DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1

    Validation instructions

    Interview JBoss administrators and review system documentation. Examine running JBoss servers and bound ports using commands like netstat. If multiple JBoss instances are deployed to a single server, it is a best practice to bind each instance to its own IP address.

    Remediation instructions

    If multiple JBoss Enterprise Application Platforms are deployed to a single server, the binding IP address can be specified at server startup using the -b argument to specify the binding IP. Example:

    run.sh -c public -b 10.10.10.75
    References

    1. Mallik, R. (2011, May). Jboss in the Trenches.

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:113101
    File: eap5-ocil.xml

    5.4 - Packet filtering should be emplaced around JBoss Enterprise Application Platform

    JBoss Enterprise Application Platform must operate in a network segment that is logically separated from any other network segment using a packet filtering mechanism. This packet filter must only allow incoming communication that is TCP with destination ports of 8080 or 8443. This packet filter can be resident on the host operating system or a completely separate system entirely. When JBoss Enterprise Application Platforms are clustered, all outgoing communication from the JBoss Enterprise Application Platform instance must be allowed.

    Rationale

    Packet filtering is a basic security technique for securing TCP/IP and UDP/IP communications.

    Additional information

    CVSSv2 Risk Assessment: 9.3 / High - CVSSv2 Formula: (AV:N/AC:M/Au:N/C:C/I:C/A:C)

    DoD Risk Category: CAT I

    NIST 800.53 Mapping: SC-7

    DoD 8500.2 Mapping: DCSS-2,EBBD-1,EBBD-2,EBBD-3,EBPW-1,ECID-1

    Validation instructions

    Interview JBoss administrators and architects. Review system network diagrams. Work with JBoss administrators to review ipfilter rulesets to ensure the TCP/IP and UDP/IP packet filters are protecting the JBoss Enterprise Platform. The packet filters must only allow incoming communication that is TCP with destination ports of 8080 or 8443. This packet filter can be resident on the host operating system or a completely separate system entirely.

    When JBoss Enterprise Application Platforms are clustered, all outgoing communication from the JBoss Enterprise Application Platform instance must be allowed.

    Remediation instructions

    Install and/or configure a TCP/IP and UDP/IP packet filtering device to logically separate the JBoss Enterprise Application Server from other networks.

    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:206401
    File: eap5-ocil.xml

    5.5 - Do not transmit sensitive information over unsecured HTTP connections

    Sensitive information should not be transferred over insecure means. This includes plaintext credential information, application information deemed sensitive, or other information that may be valuable to a malicious entity. The <auth-method> child element specifies the authentication mechanism for the web application. Using the BASIC authentication method causes the exchange of credentials in clear-text.

    Rationale

    Sensitive information being transmitted without strong encryption creates possible exposure for the deployed application and users connecting to it. Plain text transmission of authentication credentials over insecure channels (such as HTTP) exposes credential information to any entity capable of intercepting packets from the connection.

    Additional information

    CVSSv2 Risk Assessment: 4.3 / Medium - CVSSv2 Formula: (AV:A/AC:M/Au:N/C:P/I:P/A:N)

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: SC-8

    DoD 8500.2 Mapping: ECTM-1,ECTM-2

    Validation instructions

    Interview JBoss administrators and application developers. Review application documentation. Descriptive information for sensitive data used by the application should be readily available. Ensure this information is secured with SSL 3.x or TLS. There are multiple ways to secure the connections - the most common being configuration of the Apache Tomcat container (JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml).

    Real-world tests using a browser, wget, and a packet capture utility may also assist in validating the level of encryption for sensitive information.

    Remediation instructions

    Applications passing sensitive data should use a secure channel such as SSL or TLS. There are several ways to secure traffic with SSL, the method below uses the underlying Apache Tomcat technology to handle the connection.

    To setup SSL or TLS, proceed as follows:

    • Ensure a valid keystore is being loaded by JSM
    • Load the JBoss server's public/private key pair into the keystore
    • Add a secure connector to JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml 
      <Service name="jboss.web">
	<Connector protocol="HTTP/1.1" SSLEnabled="true"
		port="8443" address="${jboss.bind.address}"
		scheme="https" secure="true" clientAuth="false"
		keystoreFile="${jboss.server.home.dir}/conf/bp.keystore"
		keystorePass="KEYSTORE_PASSWORD" sslProtocol = "TLS" />
</Service>
    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html
    2. JBoss Enterprise Application Platform 5 Security Guide, 2011

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:109401
    File: eap5-ocil.xml

    Policy

    The rules in this group are used to manage JBoss servers in a secure manner. These rules are related to general best practices.

    6.1 - Use a version control repository

    All configuration files (such a data sources, custom connectors, etc) and any scripts used for modifications and deployments should be stored in the version control repository. Typical repositories include applications such as SVN or Git. Additionally, a hash-validated 'Gold' version of the JBoss installation package should also be stored in the version control system.

    Rationale

    Configuration management is an essential part long-term success for any software application - especially for complex software or collaborative environments. Using a versioning system allows for tighter control and accountability of application server changes.

    Maintaining a 'Gold' version of JBoss is useful for environments that may need to periodically or dynamically deploy JBoss instances. This can also be useful for static environments that simply desire to have a known baseline to deploy from.

    Additional information

    CVSSv2 Risk Assessment: 5 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: CM-3,CM-5

    DoD 8500.2 Mapping: DCCB-1,DCCB-2,ECPC-1,ECPC-2,DCSL-1,ECSD-1,ECSD-2

    Validation instructions

    Interview JBoss administrators and/or platform administrators. Review evidence of version control system and its use.

    Remediation instructions

    Initiate a version control repository such as Git or SVN for JBoss maintenance and deployments. This will likely be a multi-stage process requiring planning and implementation.

    References

    1. Mallik, R. (2011, May). Jboss in the Trenches.

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:110401
    File: eap5-ocil.xml

    6.2 - Automate JBoss Deployments

    Scripts or other software tools should be used to automatically configure and deploy JBoss applications in environments.

    Rationale

    As much as possible new application deployments to JBoss should be scripted. This increases standardization in deployments and reduces the possibility of errors and misconfigurations. Smaller environments may see less benefit from implementing an automated process.

    Additional information

    CVSSv2 Risk Assessment: 5 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: CM-6

    DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1

    Validation instructions

    Interview JBoss administrators and review procedural documentation. Determine if applications are deployed to JBoss Enterprise Application Platforms in an automated manner. The level of automation should be assessed vs. the costs for implementation.

    Remediation instructions

    Utilize custom scripts and/or software to automate application deployments to JBoss. Popular applications in this field include Cargo, ANT, JBoss Tools, and Hudson. Software in this category is quickly evolving and adding new features.

    References

    1. Mallik, R. (2011, May). Jboss in the Trenches.

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:112501
    File: eap5-ocil.xml

    6.3 - Application performance testing

    Ensure routine performance testing is completed before applications are deployed to production. Establish and document performance profiles.

    Rationale

    Without adequate performance testing, production applications may fail to perform to expectations - resulting in a denial of service.

    Additional information

    CVSSv2 Risk Assessment: 3.5 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: SA-3

    DoD 8500.2 Mapping: DCSP-1

    Validation instructions

    Interview JBoss system administrators and application developers. Review product documentation related to performance testing and load limits. Review policy and procedural documents related to performance testing. Production environments should have documented and established performance profiles. Applications should be performance tested prior to deployment to production environments.

    Remediation instructions

    Ensure routine performance testing is completed before applications are deployed to production. Establish and document performance profiles. Attempt to test against anticipated peak demands as well as load averages. Individual tests will vary, but commonly consist of testing message throughputs (various message types), application inputs, connections open/closed/expired, data transactions completed, method calls, objects persisted, etc.

    References

    1. Mallik, R. (2011, May). Jboss in the Trenches.

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:112701
    File: eap5-ocil.xml

    6.4 - Monitor JBoss servers

    JBoss Enterprise Application Platform servers in production environments should be monitored real-time. Information monitored and alarm thresholds will vary. Common monitoring tools include:

    • JBoss Operations Network (JON)
    • Foglight
    • HP Openview
    • Nagios

    Rationale

    Production environments should be carefully monitored to ensure the any problems on the server are detected as quickly as possible. Identifying and isolating a problem when it is small may prevent downtime or other problems on the network.

    Additional information

    CVSSv2 Risk Assessment: 6 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: AU-3,AU-6,AU-7,AU-12

    DoD 8500.2 Mapping: ECAR-1,ECAR-2,ECAR-3,ECLC-1,ECAT-1,ECAT-2,ECRG-1

    Validation instructions

    Interview JBoss system administrators. Review server documentation and system architecture diagrams. Review documents related to server monitoring. Production environments should have a real-time monitoring solution in place.

    Remediation instructions

    Research and implement an appropriate monitoring solution for the production environment. Different environments will have different requirements owing to sensitivity to downtime, regulatory requirements, service agreements, and other factors. Be careful when implementing a monitoring solution to minimize performance impact on the servers where possible. Common monitoring tools include:

    • JBoss Operations Network (JON)
    • Foglight
    • HP Openview
    • Nagios

    Common metrics include:

    • Active threads on the application server
    • Threads on the front-end http/ajp web connector
    • Database connection pools
    • JVM metrics such as memory usage and GCs
    • Typical host platform metrics such as available hard drive space, CPU usage, etc.
    References

    1. Mallik, R. (2011, May). Jboss in the Trenches.

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:112801
    File: eap5-ocil.xml

    6.5 - Ensure all downloaded software is authentic

    Software and packages should be downloaded from redhat.com, and hash validated.

    Rationale

    Without validating downloaded files are authentic, malicious users may compromise software before it has even been installed. Attackers may redirect traffic to alternate download locations and attempt to trick administrators into downloading modified software.

    Additional information

    CVSSv2 Risk Assessment: 6.2 / Medium - CVSSv2 Formula: (AV:L/AC:H/Au:N/C:C/I:C/A:C)

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: CM-6

    DoD 8500.2 Mapping: DCCS-1,DCCS-2,DCCT-1,ECSC-1,DCSS-1

    Validation instructions

    Interview JBoss administrators. JBoss administrators must demonstrate proficiency in securely acquiring JBoss Enterprise Application Platform installation materials.

    Remediation instructions

    When downloading software, first ensure it is coming from the site you expect it to. For instance, when downloading JBoss Enterprise Application Platform from Red Hat, JBoss administrators should review the X.509 certificate presented by the remote server to ensure the authenticity of the site.

    Next, JBoss administrators should hash validate files after completed downloads. Hash generation will vary depending on operating system. These hashes should be compared to one of the hashes available on the Red Hat website.

    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:205701
    File: eap5-ocil.xml

    6.6 - Ensure JBoss is configured in accordance with Common Criteria configuration guides

    JBoss deployments in government and DoD organizations require JBoss be deployed in a Common Criteria certified configuration. The Common Criteria configuration is a list of technical configuration items, policy requirements, and other configurations required to certify a JBoss installation at the EAL4+ protection level. Red Hat maintains configuration guidance available online to assist administrators during the installation and configuration of JBoss (http://docs.redhat.com/docs/en-US/index.html).

    Rationale

    By deviating from a Common Criteria configuration, JBoss will no longer be considered certified against any protection level - this may have legislative or regulatory consequences that must be identified and risk assessed dependent on your environment.

    Additional information

    CVSSv2 Risk Assessment: 6.2 / Medium

    DoD Risk Category: CAT II

    NIST 800.53 Mapping: SA-4

    DoD 8500.2 Mapping: DCAS-1,DCSR-1,DCSR-2,DCSR-3

    Validation instructions

    Interview JBoss administrators and review on-site documentation. Review the JBoss Common Criteria Configuration Guide (available here from Red Hat's website) to ensure JBoss has been installed and configured in accordance with the Common Criteria requirements.

    Remediation instructions

    Configure JBoss in its Common Criteria certified configuration. The configuration guide can be found here on Red Hat's website.

    References

    1. U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:401001
    File: eap5-ocil.xml

    Trimming

    The rules in this group concern trimming JBoss EAP.

    7.1 - Unused features should be disabled or deleted: Java Universal Description, Discovery, Integration (JUDDI)

    Features and services not in use should be removed. JUDDI is an open source Java implementation of the Universal Description, Discovery, and Integration (UDDI v3) specification for (Web) Services.

    Rationale

    Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

    Additional information

    CVSSv2 Risk Assessment: 3 / Low

    DoD Risk Category: CAT III

    NIST 800.53 Mapping: CM-7

    DoD 8500.2 Mapping: DCPP-1

    Validation instructions

    Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following directory:

    • JBOSS_HOME/server/[PROFILE]/deploy/juddi-service.sar
    Remediation instructions
    In order to completely disable the this component, take the following actions:

    Delete this directory:

    • JBOSS_HOME/server/[PROFILE]/deploy/juddi-service.sar
    References

    1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
    2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf
    3. JUDDI; An Apache Project. (February 6, 2012).

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:110601
    File: eap5-ocil.xml

    7.2 - Unused features should be disabled or deleted: Enterprise Java Beans (EJB) Services

    Features and services not in use should be removed.

    Rationale

    Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

    Additional information

    CVSSv2 Risk Assessment: 3 / Low

    DoD Risk Category: CAT III

    NIST 800.53 Mapping: CM-7

    DoD 8500.2 Mapping: DCPP-1

    Validation instructions

    Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following directory:

    • JBOSS_HOME/server/[PROFILE]/deploy/ejb3-connectors-jboss-beans.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/ejb3-container-jboss-beans.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/ejb3-interceptors-aop.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/ejb3-timerservice-jboss-beans.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/profile-service-secured.jar
    • JBOSS_HOME/server/[PROFILE]/deploy/ejb2-container-jboss-beans.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/ejb2-timer-service.xml
    • JBOSS_HOME/server/[PROFILE]/deployers/jboss-ejb3-endpoint-deployer.jar
    • JBOSS_HOME/server/[PROFILE]/deployers/ejb3-deployers-jboss-beans.xml
    Remediation instructions

    In order to completely disable the this component, Delete the following files and directories:

    • JBOSS_HOME/server/[PROFILE]/deploy/ejb3-connectors-jboss-beans.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/ejb3-container-jboss-beans.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/ejb3-interceptors-aop.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/ejb3-timerservice-jboss-beans.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/profile-service-secured.jar
    • JBOSS_HOME/server/[PROFILE]/deploy/ejb2-container-jboss-beans.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/ejb2-timer-service.xml
    • JBOSS_HOME/server/[PROFILE]/deployers/jboss-ejb3-endpoint-deployer.jar
    • JBOSS_HOME/server/[PROFILE]/deployers/ejb3-deployers-jboss-beans.xml
    References

    1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
    2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:110701
    File: eap5-ocil.xml

    7.3 - Unused features should be disabled or deleted: Universal Unique Identifier (UUID) Generator

    Features and services not in use should be removed. UUID Generator allows for the generation of unique identifiers for hosted Java applications.

    Rationale

    Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

    Additional information

    CVSSv2 Risk Assessment: 3 / Low

    DoD Risk Category: CAT III

    NIST 800.53 Mapping: CM-7

    DoD 8500.2 Mapping: DCPP-1

    Validation instructions

    Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following directory:

    • JBOSS_HOME/server/[PROFILE]/deploy/uuid-key-generator.sar
    Remediation instructions

    In order to completely disable the this component, Delete this directory:

    • JBOSS_HOME/server/[PROFILE]/deploy/uuid-key-generator.sar
    References

    1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
    2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:110801
    File: eap5-ocil.xml

    7.4 - Unused features should be disabled or deleted: Java Message Service (JMS)

    Features and services not in use should be removed. Java Message Service is a component of Java Enterprise Edition that enables application to send and receive messages. It is a cornerstone service that many distributed applications are built on.

    Rationale

    Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

    Additional information

    CVSSv2 Risk Assessment: 3 / Low

    DoD Risk Category: CAT III

    NIST 800.53 Mapping: CM-7

    DoD 8500.2 Mapping: DCPP-1

    Validation instructions

    Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:

    • JBOSS_HOME/server/[PROFILE]/conf/props/messaging-roles.properties
    • JBOSS_HOME/server/[PROFILE]/conf/props/messaging-users.properties
    • JBOSS_HOME/server/[PROFILE]/deploy/messaging
    • JBOSS_HOME/server/[PROFILE]/deploy/jms-ra.rar
    • JBOSS_HOME/server/[PROFILE]/deploy/quartz-ra.rar
    • JBOSS_HOME/server/[PROFILE]/deployers/messaging-definitions-jboss-beans.xml

    Validate changes to the following files:

    • Ensure all elements with references to JMS have been removed from: JBOSS_HOME/server/[PROFILE]/conf/standardjboss.xml
    • Ensure the following <property> element has been removed from JBOSS_HOME/server/[PROFILE]/conf/jbossts-properties.xml 
      <property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.JBMESSAGING1" value="org.jboss.jms.server.recovery.MessagingXAResourceRecovery;java:/DefaultJMSProvider"/>
    Remediation instructions

    In order to completely disable this component, take the following actions:

    Delete these files and directories:

    • JBOSS_HOME/server/[PROFILE]/conf/props/messaging-roles.properties
    • JBOSS_HOME/server/[PROFILE]/conf/props/messaging-users.properties
    • JBOSS_HOME/server/[PROFILE]/deploy/messaging
    • JBOSS_HOME/server/[PROFILE]/deploy/jms-ra.rar
    • JBOSS_HOME/server/[PROFILE]/deploy/quartz-ra.rar
    • JBOSS_HOME/server/[PROFILE]/deployers/messaging-definitions-jboss-beans.xml

    Make the identified changes to the following files:

    • Remove all elements with references to JMS from: JBOSS_HOME/server/[PROFILE]/conf/standardjboss.xml
    • Remove the following <property> element from JBOSS_HOME/server/[PROFILE]/conf/jbossts-properties.xml 
      <property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.JBMESSAGING1" value="org.jboss.jms.server.recovery.MessagingXAResourceRecovery;java:/DefaultJMSProvider"/>
    References

    1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
    2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:110901
    File: eap5-ocil.xml

    7.5 - Unused features should be disabled or deleted: JBoss Mail

    Features and services not in use should be removed. JBoss Mail is a deployed package for Java Mail - a set of Java API's implementing an email server supporting the SMTP, POP3, and IMAP protocols.

    Rationale

    Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

    Additional information

    CVSSv2 Risk Assessment: 3 / Low

    DoD Risk Category: CAT III

    NIST 800.53 Mapping: CM-7

    DoD 8500.2 Mapping: DCPP-1

    Validation instructions

    Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:

    • JBOSS_HOME/server/[PROFILE]/deploy/mail-ra.rar
    • JBOSS_HOME/server/[PROFILE]/deploy/mail-service.xml
    Remediation instructions

    In order to completely disable the this component, Delete the following files and directories:

    • JBOSS_HOME/server/[PROFILE]/deploy/mail-ra.rar
    • JBOSS_HOME/server/[PROFILE]/deploy/mail-service.xml
    References

    1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
    2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:111001
    File: eap5-ocil.xml

    7.6 - Unused features should be disabled or deleted: JBoss Scheduling

    Features and services not in use should be removed. JBoss Scheduling implements a JBoss service that supports scheduling and running jobs for deployed Java applications.

    Rationale

    Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

    Additional information

    CVSSv2 Risk Assessment: 3 / Low

    DoD Risk Category: CAT III

    NIST 800.53 Mapping: CM-7

    DoD 8500.2 Mapping: DCPP-1

    Validation instructions

    Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:

    • JBOSS_HOME/server/[PROFILE]/deploy/schedule-manager-service.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/scheduler-service.xml
    Remediation instructions

    In order to completely disable the this component, Delete the following files:

    • JBOSS_HOME/server/[PROFILE]/deploy/schedule-manager-service.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/scheduler-service.xml
    References

    1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
    2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:111101
    File: eap5-ocil.xml

    7.7 - Unused features should be disabled or deleted: Hypersonic SQL Database (HSQLDB)

    Features and services not in use should be removed. HSQLDB is the default datasource configured to run with JBoss Enterprise Application Platform out of the box. It is not recommended for production usage.

    Rationale

    Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

    Additional information

    CVSSv2 Risk Assessment: 3 / Low

    DoD Risk Category: CAT III

    NIST 800.53 Mapping: CM-7

    DoD 8500.2 Mapping: DCPP-1

    Validation instructions

    Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:

    • JBOSS_HOME/server/[PROFILE]/deploy/hsqldb-ds.xml
    • JBOSS_HOME/common/lib/hsqldb.jar
    • JBOSS_HOME/common/lib/hsqldb-plugin.jar
    • JBOSS_HOME/server/[PROFILE]/deploy/messaging/hsqldb-persistence-service.xml
    • JBOSS_HOME/server/[PROFILE]/data/hypersonic/
    Remediation instructions

    In order to completely disable the this component, Delete the following files and directories:

    • JBOSS_HOME/server/[PROFILE]/deploy/hsqldb-ds.xml
    • JBOSS_HOME/common/lib/hsqldb.jar
    • JBOSS_HOME/common/lib/hsqldb-plugin.jar
    • JBOSS_HOME/server/[PROFILE]/deploy/messaging/hsqldb-persistence-service.xml
    • JBOSS_HOME/server/[PROFILE]/data/hypersonic/
    References

    1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
    2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:111201
    File: eap5-ocil.xml

    7.8 - Unused features should be disabled or deleted: BeanShell (BSH) Deployer

    Features and services not in use should be removed. The BSH Deployer allows for the hot deployment of one use execution scripts or services.

    Rationale

    Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

    Additional information

    CVSSv2 Risk Assessment: 3 / Low

    DoD Risk Category: CAT III

    NIST 800.53 Mapping: CM-7

    DoD 8500.2 Mapping: DCPP-1

    Validation instructions

    Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:

    • JBOSS_HOME/server/[PROFILE]/deployers/bsh.deployer
    Remediation instructions

    In order to completely disable the this component, Delete the following files and directories:

    • JBOSS_HOME/server/[PROFILE]/deployers/bsh.deployer
    References

    1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
    2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:111301
    File: eap5-ocil.xml

    7.9 - Unused features should be disabled or deleted: JBossWS

    Features and services not in use should be removed. JBossWS is a web service framework for use with the JBoss Enterprise Application Platform.

    Rationale

    Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

    Additional information

    CVSSv2 Risk Assessment: 3 / Low

    DoD Risk Category: CAT III

    NIST 800.53 Mapping: CM-7

    DoD 8500.2 Mapping: DCPP-1

    Validation instructions

    Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:

    • JBOSS_HOME/server/[PROFILE]/conf/jax-ws-catalog.xml
    • JBOSS_HOME/server/[PROFILE]/conf/props/jbossws-roles.properties
    • JBOSS_HOME/server/[PROFILE]/conf/props/jbossws-users.properties
    • JBOSS_HOME/server/[PROFILE]/deploy/jbossws.sar
    • JBOSS_HOME/server/[PROFILE]/deploy/jbossws-console.war
    • JBOSS_HOME/server/[PROFILE]/deployers/jbossws.deployer
    Remediation instructions

    In order to completely disable the this component, Delete the following files and directories:

    • JBOSS_HOME/server/[PROFILE]/conf/jax-ws-catalog.xml
    • JBOSS_HOME/server/[PROFILE]/conf/props/jbossws-roles.properties
    • JBOSS_HOME/server/[PROFILE]/conf/props/jbossws-users.properties
    • JBOSS_HOME/server/[PROFILE]/deploy/jbossws.sar
    • JBOSS_HOME/server/[PROFILE]/deploy/jbossws-console.war
    • JBOSS_HOME/server/[PROFILE]/deployers/jbossws.deployer
    References

    1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
    2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:111401
    File: eap5-ocil.xml

    7.10 - Unused features should be disabled or deleted: Seam

    Features and services not in use should be removed. Seam is an application framework for Java designed to reduce application complexity.

    Rationale

    Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

    Additional information

    CVSSv2 Risk Assessment: 3 / Low

    DoD Risk Category: CAT III

    NIST 800.53 Mapping: CM-7

    DoD 8500.2 Mapping: DCPP-1

    Validation instructions

    Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:

    • JBOSS_HOME/server/[PROFILE]/deployers/seam.deployer
    • JBOSS_HOME/server/[PROFILE]/deployers/webbeans.deployer
    Remediation instructions

    In order to completely disable the this component, Delete the following files and directories:

    • JBOSS_HOME/server/[PROFILE]/deployers/seam.deployer
    • JBOSS_HOME/server/[PROFILE]/deployers/webbeans.deployer
    References

    1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
    2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:111501
    File: eap5-ocil.xml

    7.11 - Unused features should be disabled or deleted: JBoss Internet Inter-ORB Protocol (IIOP)

    Features and services not in use should be removed. JBoss IIOP implements a standards compliant CORBA server for JBoss.

    Rationale

    Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

    Additional information

    CVSSv2 Risk Assessment: 3 / Low

    DoD Risk Category: CAT III

    NIST 800.53 Mapping: CM-7

    DoD 8500.2 Mapping: DCPP-1

    Validation instructions

    Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:

    • JBOSS_HOME/server/[PROFILE]/conf/jacorb.properties
    • JBOSS_HOME/server/[PROFILE]/deploy/iiop-service.xml
    • JBOSS_HOME/server/[PROFILE]/deployers/ejb3.deployer/META-INF/ejb3-iiop-deployers-jboss-beans.xml
    • JBOSS_HOME/server/[PROFILE]/lib/jacorb.jar

    Validate changes to the following files:

    In JBOSS_HOME/server/[PROFILE]/conf/jndi.properties, Replace:

    java.naming.factory.initial=org.jboss.iiop.naming.ORBInitialContextFactory

    with

    java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
    Remediation instructions

    In order to completely disable this component, Delete these files and directories:

    • JBOSS_HOME/server/[PROFILE]/conf/jacorb.properties
    • JBOSS_HOME/server/[PROFILE]/deploy/iiop-service.xml
    • JBOSS_HOME/server/[PROFILE]/deployers/ejb3.deployer/META-INF/ejb3-iiop-deployers-jboss-beans.xml
    • JBOSS_HOME/server/[PROFILE]/lib/jacorb.jar

    Make the identified changes to the following files:

    In JBOSS_HOME/server/[PROFILE]/conf/jndi.properties, Replace:

    java.naming.factory.initial=org.jboss.iiop.naming.ORBInitialContextFactory

    with

    java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory

    In JBOSS_HOME/server/[PROFILE]/conf/standardjboss.xml, Delete text:

    invoker-proxy-binding iiop
    References

    1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
    2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:111601
    File: eap5-ocil.xml

    7.12 - Unused features should be disabled or deleted: Miscellaneous

    Miscellaneous features and services not in use should be removed.

    Rationale

    Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

    Additional information

    CVSSv2 Risk Assessment: 3 / Low

    DoD Risk Category: CAT III

    NIST 800.53 Mapping: CM-7

    DoD 8500.2 Mapping: DCPP-1

    Validation instructions

    Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:

    • JBOSS_HOME/server/[PROFILE]deployers/xnio.deployer
    • JBOSS_HOME/server/[PROFILE]deployers/hibernate-deployer-jboss-beans.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/jboss-xa-jdbc.rar
    • JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war
    • JBOSS_HOME/server/[PROFILE]/deploy/profileservice-jboss-beans.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/sqlexception-service.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/xnio-provider.jar
    • JBOSS_HOME/server/[PROFILE]/deploy/management/
    Remediation instructions

    In order to completely disable these components, Delete these files and directories:

    • JBOSS_HOME/server/[PROFILE]deployers/xnio.deployer
    • JBOSS_HOME/server/[PROFILE]deployers/hibernate-deployer-jboss-beans.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/jboss-xa-jdbc.rar
    • JBOSS_HOME/server/[PROFILE]/deploy/jmx-console.war
    • JBOSS_HOME/server/[PROFILE]/deploy/profileservice-jboss-beans.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/sqlexception-service.xml
    • JBOSS_HOME/server/[PROFILE]/deploy/xnio-provider.jar
    • JBOSS_HOME/server/[PROFILE]/deploy/management/
    References

    1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
    2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:111701
    File: eap5-ocil.xml

    7.13 - Unused features should be disabled or deleted: HTTP Invokers

    Features and services not in use should be removed. HTTP invocation allows the JBoss server to receive and act on remote instructions. This can be useful for administrators - especially in large or distributed environments.

    Rationale

    Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

    Additional information

    CVSSv2 Risk Assessment: 3 / Low

    DoD Risk Category: CAT III

    NIST 800.53 Mapping: CM-7

    DoD 8500.2 Mapping: DCPP-1

    Validation instructions

    Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:

    For HTTP Invoker for JNDI, EJB and JMX:

    • JBOSS_HOME/server/[PROFILE]/deploy/http-invoker.sar
    • JBOSS_HOME/server/[PROFILE]/deploy/httpha-invoker.sar

    For JMS HTTP Invoker:

    • JBOSS_HOME/server/[PROFILE]/deploy/jms/jbossmq-httpil.sar
    Remediation instructions

    In order to completely disable HTTP Invoker for JNDI, EJB and JMX, Delete these files and directories:

    • JBOSS_HOME/server/[PROFILE]/deploy/http-invoker.sar
    • JBOSS_HOME/server/[PROFILE]/deploy/httpha-invoker.sar

    In order to completely disable HTTP Invoker for JMS, Delete this directory:

    • JBOSS_HOME/server/[PROFILE]/deploy/jms/jbossmq-httpil.sar
    References

    1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
    2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:111801
    File: eap5-ocil.xml

    7.14 - Unused features should be disabled or deleted: Java Management Extensions (JMX) Invoker

    Features and services not in use should be removed. The JMX Invoker exposes the JMX MBeanServer interface via Remote Method Invocation compatible interface. This can be useful for administrators - especially in large or distributed environments.

    Rationale

    Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

    Additional information

    CVSSv2 Risk Assessment: 3 / Low

    DoD Risk Category: CAT III

    NIST 800.53 Mapping: CM-7

    DoD 8500.2 Mapping: DCPP-1

    Validation instructions

    Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:

    • JBOSS_HOME/server/[PROFILE]/deploy/jmx-invoker-service.xml
    Remediation instructions

    In order to completely disable this component, Delete these files and directories:

    • JBOSS_HOME/server/[PROFILE]/deploy/jmx-invoker-service.xml
    References

    1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
    2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:111901
    File: eap5-ocil.xml

    7.15 - Unused features should be disabled or deleted: Pooled Invoker

    Features and services not in use should be removed. The org.jboss.invocation.pooled.server.PooledInvoker provides RMI over a custom socket implementation of the Invoker interface.

    Rationale

    Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

    Additional information

    CVSSv2 Risk Assessment: 3 / Low

    DoD Risk Category: CAT III

    NIST 800.53 Mapping: CM-7

    DoD 8500.2 Mapping: DCPP-1

    Validation instructions

    Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate changes to the following files:

    In JBOSS_HOME/server/[PROFILE]/deploy/legacy-invokers-service.xml Ensure the <mbean> with name attribute of "jboss:service=invoker,type=pooled" has been deleted.

    Remediation instructions

    In order to completely disable this component, take the following actions:

    In JBOSS_HOME/server/[PROFILE]/deploy/legacy-invokers-service.xml, Delete the <mbean> with name attribute of "jboss:service=invoker,type=pooled"

    References

    1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
    2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:112001
    File: eap5-ocil.xml

    7.16 - Unused features should be disabled or deleted: Java Remote Method Protocol (JRMP) Invoker

    Features and services not in use should be removed. The org.jboss.invocation.jrmp.server.JRMPInvoker provides the RMI/JRMP implementation of the Invoker interface.

    Rationale

    Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

    Additional information

    CVSSv2 Risk Assessment: 3 / Low

    DoD Risk Category: CAT III

    NIST 800.53 Mapping: CM-7

    DoD 8500.2 Mapping: DCPP-1

    Validation instructions

    Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate changes to the following files:

    In JBOSS_HOME/server/[PROFILE]/deploy/legacy-invokers-service.xml, Ensure the <mbean> with name attribute of "jboss:service=invoker,type=jmrp" has been deleted.

    Remediation instructions

    In order to completely disable this component, take the following actions:

    In JBOSS_HOME/server/[PROFILE]/deploy/legacy-invokers-service.xml, Delete the <mbean> with name attribute of "jboss:service=invoker,type=jmrp"

    References

    1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
    2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:112101
    File: eap5-ocil.xml

    7.17 - Unused features should be disabled or deleted: Clustering

    Features and services not in use should be removed. Clustering allows deployed applications to run distributed across multiple JBoss Enterprise Application Platform servers.

    Rationale

    Removing unused features or services is a common security strategy that reduces the potential attack surface of an information system. Removing unused features or services also reduces resource usage.

    Additional information

    CVSSv2 Risk Assessment: 3 / Low

    DoD Risk Category: CAT III

    NIST 800.53 Mapping: CM-7

    DoD 8500.2 Mapping: DCPP-1

    Validation instructions

    Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate the removal of the following files and directories:

    • JBOSS_HOME/server/[PROFILE]/deploy-hasingleton/
    • JBOSS_HOME/server/[PROFILE]/farm/
    • JBOSS_HOME/server/[PROFILE]/deploy/cluster/

    Validate this change to the following file:

    In JBOSS_HOME/server/[PROFILE]/conf/bootstrap/profile.xml, Delete the following from "BootstrapProfileFactory":

    <property name="farmURIs">
	<list elementClass="java.net.URI">
		<value>${jboss.server.home.url}farm</value>
	</list>
</property>
    Remediation instructions

    In order to completely disable this component, take the following actions:

    Delete these files and directories:

    • JBOSS_HOME/server/[PROFILE]/deploy-hasingleton/
    • JBOSS_HOME/server/[PROFILE]/farm/
    • JBOSS_HOME/server/[PROFILE]/deploy/cluster/

    In JBOSS_HOME/server/[PROFILE]/conf/bootstrap/profile.xml, Delete the following from "BootstrapProfileFactory":

    <property name="farmURIs">
	<list elementClass="java.net.URI">
		<value>${jboss.server.home.url}farm</value>
	</list>
</property>
    References

    1. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming
    2. DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf

    Check Summary

    System: http://scap.nist.gov/schema/ocil/2
    Name: ocil:com.redhat.eap5.scap:questionnaire:112301
    File: eap5-ocil.xml

    Rear Matter

    For additional information regarding the JBoss EAP 5 SCAP benchmark, please visit https://fedorahosted.org/scap-security-guide/

    You may also contact the authors:

    scap-security-guide-0.1.31/JBossEAP5/docs/JBossEAP_5.x_SCAP.xlsx000066400000000000000000002415441301675746700236650ustar00rootroot00000000000000PK!†¯CŸ•l[Content_Types].xml ¢( ÄUKnÂ0ÝWê"o+b`QUEi—-ô&ˆEb[žáwûNBAA"R7‰{Þg¬yî 6E­  q6¸-"°©ÓÆÎñ=ùh½ˆIY­rg![@1è?>ô&[qµÅDdDþUJL3(Æ΃啙 …"þ séUºPsÝvûY¦ÎXjQ‰!ú½!ÌÔ2§è}ÿwJ¦ÆŠèm·¯¤J„ò>7©"*WVŸ´ÜlfRÐ.] £ 4fTä±†ÃˆØ y–3@Ž×‘þºŠ¹²†™ñøÄÖ/0”+—]]®[ÕÖ5wƒë‡A­Ù{)ì‹Ï; ÑHúT7Wnr¹va1un׫lf;î}uq¡ŒÝ7¦†¿ÚŒ²zuî,¤ôW_©£ûO:ˆ‡ dõ¼½Lƒq¤mxg·;Ð&æLÐcâ1ß]À_ì©+ÊôÀÛû}<{Ü:zŽ®Qp9\û(*«[ž C›¹#Gëõ„' evkÐg¸euWôÿÿPK!µU0#õL _rels/.rels ¢( Œ’ÏNÃ0 ÆïH¼CäûênH¡¥»LH»!TÀ$îµ£$@÷ö„‚JcÛÑöçÏ?[ÞîæiTb/Nú(A±3b{×jx­ŸV b"giÇŽaWÝÞl_x¤”›b×û¨²‹‹º”ü#b4O ñìr¥‘0QÊahÑ“¨eÜ”å=†¿P-<ÕÁj{ª>ú<ù²·4Mox/æ}b—NŒ@ž;ËvåCf ©ÏÛ¨šBËIƒóœÓÉû"cž&Ú\Oôÿ¶8q"K‰ÐHàó<ߊs@ëë.Ÿh©ø½Î<⧄áMdøaÁÅT_ÿÿPK!J©¦aúGxl/_rels/workbook.xml.rels ¢( ¼’ÍjÄ0 „ï…¾ƒÑ½q’þPÊ:{)…½¶Û0±‡Mlc©?yûš”î6°¤—У$4ó1Ìfû9ôâ#uÞ)(²ºÚ›Îµ ^÷OW÷ ˆµ3º÷ŒH°­./6ÏØkNOd»@"©8R`™Ãƒ”T[4e> K—ÆÇAsc+ƒ®ºEYæùŒ¿5 šiŠQwæÄ~ Éùomß4]¾~Ðñ ɉ “ Ž-²‚iü^Yyž¡\“áÃÇYD>qW$§K¹Sü3Ìb2·kÂÕÍ ÇT>:¥3[/%s³* }êú±+4Í?örVÿê ÿÿPK!OÔ„æÉxl/workbook.xmlŒROOÛ0¿OÚwðžz¥IšP j‚XZ›tpDnüÒXuìÈvIùö{NV·ìç÷üûg/¯b¯h4:‡dC]!õ.‡?›»³K`Îs-¸2sxC×Å×/ËÎØýÖ˜=#ír¨½oQäÊEMÊ؆{*í.r­E.\èÍâx5\jö0LUÉoMyhPûÄ¢âžä»Z¶Še%> ŽoÛß¼!ÝGLqçéQäpN¥éðã fí÷ƒTÔ½JãDÅ»É{Ë÷˜\Å…D‰Ô¦[ëýÖÆ÷Ü9PpüàÍÊ4dÓ¹{YúmBƒ€BRO;÷Jv|–Z˜.‡³ô’¼Êt¬ë[ÏRø:‡YÏi`8û‰rWû²ì‚æ<ß>d**J/_q÷A)QG#î>|ÒЯL÷ÉüZ?®‚#z–5Y9,$mìZô÷dz«˽MýûtŸXÔ…ÀJj!ýÏÕ?Ú—£ÒÍôåN*ö–“ î0"9}Þâ/ÿÿPK!ü9/ñÇ xl/styles.xmlÔX]Ú8}_©ÿ!ò;“ÀÀ@IU˜"UêV•†®öÕI°êÈ1-´Úÿ¾÷: ¦30¯]^°ßãsϵo®3y»‘ÂûÆLɵŠH÷" S©Î¸ZFäËbÞ¯´TeThÅ"²e%y¿ùcRÚ­`7+ƬªŒÈÊÚbìûeºb’–º` žäÚHj¡k–~YF³¤ð{ApåKÊ©Æ2=DRóu]tR- jy·[‡E<™Ž?,•64@uÓíÓ´Áv[ð’§F—:·çë<ç)»Í2ôCâI®•-½T¯•È q…ñW¥¿«9>ëYñ¤üá}£FâÇE%«ú1“QEqÐG¼ 5ž$0ðP›fþè¼%šéÝ.ÎOµÐƳ,ÐêˆäŒ žŽÓr*¹ØVÜ{8àâ[;#9¨ƒ®ìÖ9Bm¹~ õ—áž'WÛ°,"#G~¯ç‚®´tr¦+jJØŽ•ì·X%ȽÊ;Ò%hÄ…Øí‹+Ü0O`ZfÔ:^Ý^l P[ÁQªø¹y'f/ Ýv{ƒó J-x†,–³vŒ+„) Û9ŽñÌ2‰ÈÜýâ¤^h¤«¾cû”kÍ‚g_«> =âYŽ'¼\ôúa8vñ7…—èÕCœuúÂI´É Ç6©³D5OË- ¾\á¿Õ®¡­…„O2N—ZQM¿±¨›2!n0ÿï°{€½É=µ–si?ÀŒŽy¦iBÀëf…Wuÿ.£K°¯@™¶‘G‹Bl?­eÂÌÜ¥y·š:÷ýw‚/•d(+rS>mYjÝ‹Çm#¿íOå]˱îð·<ó6ùIQ¢_ë²³®(·¼ÀB–¬œÂ7¨å)æ{ ñ¾Z,ØœuÙÊßäwëÛ=wq|ÅÔ€wŪÿšX'$zˆ&öãÄÚ+mø„Ž<&`ß-OJç7µšÃ†ÇÝôŸTî5ȵt„”wçšRi՜ú÷º:ž úRäú!džú-ÓŽÊ=B¾9š­x(ï÷¹Î°¿‡ò!¹×ئ­ìs‚êKÅÕ¡¿§V¨ÎPäëàÿÖTŸ1¬®ƒ’«UYÔ•»úÌÃûWDÞ¥)TtPî‚›¬¹€â+®KW-›|Â:Q4˜öGE ÐÈ6ûÂÖ=µxµw%ïŽ`d,§ka»‡Ù·ÿd_Kwナìc 7nø÷Ö†Gäçûé0¼~?ïuFÁtÔé_²A'L¯;ƒþlz}=ƒ^0û§õ á_Ü—(»ýq)à;ƒ©Ý¨ÉßìÇ"Òê|Ä‹AUEm¸4Nøû/0ñ¿ÿÿPK!Õ8;=ð]#xl/worksheets/_rels/sheet2.xml.rels¬’ÁJ1†ï‚ïæn²© "ÍöR„^µ>@ÌÎî†n&!‰Õ¾½SuKÅKo™ùÉ7Ã,Wa{ÌÅG2 eÉÅÎÓ`àeûxs¢TK"¡Xµ×WË'œlåOeô©¦P10Öš”*nÄ`‹Œ ‰“>æ`+—yPɺP-šæNåß hgL±é äMw b{H<ùvì{ïpÝ[@ªgF(Ã1*Ì´yÀj@Ê練ì ê¼Æâ’û0­³}çÏDº¯^Q?¹–üþËI_Ò)eOó3ÖÊ^ó dê¤ÖòÕÓQRÍŽ¢ýÿÿPK!Iõ]óJñxl/worksheets/sheet2.xml¼[sÜF²­ßOÄù ½oŠh}qØÞ1šÍ¾¢Ñœsγ,ÑcÅ–D‰3ï_¿]¨ªÄÊEvÒ’fh úCÖmeV¡—ïÿó_Þ¿øçݧÏïî?þ𲸸|ùâîã›û·ï>þý‡—ÿço×ÿ1ùâóÃëo_¿¿ÿx÷ÃË?î>¿üÏÿ÷ÿúþ÷ûOÿõù×»»‡báãç^þúððÛw¯^}~óë݇ן/î»û(¿ürÿéÃëù¿ŸþþêóoŸî^¿=ôáý«ÉååôÕ‡×ï>¾ ¾ûä±qÿË/ïÞÜ]Ý¿ùLJ»Áȧ»÷¯¤þŸ}÷Ûçhí_o]öÞ~zý»´5ÖGUñ*ü’앩߇wo>ݾÿåáâÍý‡W¡j¶•‹W‹Q;?¼1†Hg}xýé¿þñÛˆáߤq?¿{ÿîáSs_¾øðæ»Õß?Þzýó{‘Õë7ª–¯­y=ÅÒߟFèðéÅ/ïÞ?Ü}ÚÝ¿•RŠ—¯~üþí;éô^)/>ÝýòÃË¿ßý­˜Íú_N§üßww¿Vÿ~ñðúçÛ»÷woîÞö^<Üÿ¶½ûåá¯wïßÿðr/þûþþÃí›×}3æµú¿û^5Âô{¡ý|ÿ_½õ•Ø¹”þöúãÝ‹?n“N±†ÿRÔrÚë7ïþywð‡—?ß?<Üè‹>‰ùAýòéþ¿ï>žª~ªaߨÞêFb}ë©œþÿOMßò¤Ý¯RÃõ¿c'\ŸÄ/=ùöî—×ÿxÿð×û÷ÿïÝÛ‡_¥ÎÒøáàñþ÷›»wÿµoÉäBŠ8 èwoÿ¸ºûüF4.-¾˜ôe½¹/†åï‹ïz_!¼þ×é¿¿F'Ål1ϤùŸþ8õêË?ß}~¸úéÍ?>KGÄ: Fƒ¹É`Nþû¤¹'L”ƒ ùo4Q_TuYLþL…ªÁšüw°¶¸¨«ÉŸmŸTáÔ]òß\¹?ß]2N'sòßln2]˜Ö>Ñ_³Á†ü7Ú˜þùþ’@}ª‘üw°V•³É´žþ©î_ æä¿Ñ\}±¸cO´®©$TþÛ7¿˜–“ùŸDï3Á ü#œÓ «åÔ|Eßÿc°X—džjfT}‘e?c6¼uŠº/”ð/ŸY§(ö"«}ºø1Qîý?†ŽšOY´yª§¢Þ‹,øjÂjõ”‘(ó"뼜[az{;ʼÈ:g枨Ñ$ê¼ÿÇÐ7Ú,g&IçÓržEÐË?Eõ~ê óÁiºzýðúÇï?ÝÿþB=='S™,ÉŠïú:õÿ3¡ aJ:A§§ºŸèŒ#SMoí/½¹`A¦¢Ï2ùþóÇzþý«ö5˜†0‹y9†þJ É|:†®TÔÕú‰BP§kÍ«ÅØÒ’B`é†@‹,­4)ŠqqkÕ“Ë1´¡XÚ¨˜Bï4) ¸~†ã[L'ã:µšÌgcè@!èÌŽAP¥#a Á-æTéoª‹¥eËÈ&ÄeË”—À¬-cÑm¶Z¶vjô‰eJ¼6Ù¦„Ai 3ÅÍ!0ZËõ˜ÎÚ1ZȨéFË–yTËbÈ«å©„{¯{³c!O¡Ïšˆ$!‡ò7M\VÈ–‘à±È®#Ä~“þIeØ lÝ{§·"L^ѵE¬Ž#Su¬Ž­\ÊìRC¸Ý[f:¦µL9Þ=FËx²€°ÝY;FÆ‘¿¹åFÆ–Ñ1Z7K}¼2~fHî-ƒ’Ák›ˆ$%‡ºq5vÀ•elHŽL¯d×2þ–;p^ÃÔx­öÉ Æjeœa×™Ï@×A[k§À•ÃÎ2%^Úî-3»„èÒZ¦œÀ%ö!0ò7ipv cÛY;8’Ç€èÑ^)[3su‘0’²l¨~#)÷–AÊ0ŒMD’”ÃÝ8+eËX)G†I9þ–ÇÁJ90#)/`Ë–æ˜zÙQeOŠ›aî³%PY_4+êH¬¼C_êá'ò&þ¨¼û¬O\÷ò>êçݨ×?*r ¹Ç1Ü$&+9œ¥c0Q²…ˆ’ôh ?¼Ýêiý%[hŽ êujiî ¨­¥…U²…J¼“nGŠ›áÈžAxZK ²‚iè@ Ya«#UrhÜ%h4t*¹ÍZÉOê/º’´É¥ÌžÍ0OÔ§'@OOä™#Å7¢ö4½$ˆ,¯#D—׶rdym¡ ®¬V© YÆÞ°±&Y^Ç gKdym¡²€ÕüŽWâ3{U°nl dÜý0@OÆ„ŽY‚È~˜3Z'£¢öhF‹’ÓcgN­3yèÕ¿,žhÓ.7ƒqh“‚ùpD·ÐÊ›@VÞ :-KÆ;bËTp–’]”h2ƒµ"Þo¸&Ì| 9˜Íé–/ÔP§þ–X*1"î„uÚ3·i dÕ=@O«›YBųp~½%®ÒXÝ}ê˫ë]r÷O~â’–Mb²¶mºŽhÛBDÛ¢Ú¶•#Ú¶Ð×Z«Ô„ì%%ׄ!ÚŽõ͆ˆ¶m•J|.eGŠ+ñ©¬=…`jm ¤…6F茶mÅÍÆÈ`茶m7é*µÝç}œÚžÏåÅ~q‡Œ’ܘæm&‘ÉâGt‰¸-DÄ!*îXpV·…&¸´Z¥&dK˜\†ˆ;Ö7"â¶UªðVÒ)®ÄÇîö‚+Ζ@ZIƒ¸CΈÛVÜŠ›ô€ ÜÒU‹»Oü|qÛÜ^ 5“ÈdqÛD·…ˆ¸#DÅ ÎJ"â¶P9…à¶JMÈ–J\q¬ DÔ+œ-u[¨ÄÇ9v¤¸r Ë©=…`¡ÐHKiPw¨ÓuÛδ궳[%C•tøÓU«»Ïõ8Õ]¿& Ѷm9Ѷ­R‰¹;R\‰3ΞBà-…À¤µ]âê­#–¬¶IØÈm!=(cm‹ø¾¶{Ãã]nLþ6§÷'õLÖv8댶-Dw„úÀ ã±LgEÚÝ•xØŠAøðúš@Dܱ¹NDÜ’¿i£¨ÄÛv¤¸ïïÙ3h ×û-´’†Àê¤Åm ŽY‚Q9Œ|¸m7éÒÆâS^qO¦ÕÅôRýO–?îË˾Ð:l<5ý¼pb²ÖÃù›ÆÒÞc’NˉãÑÕz,8[ Z·îÕ!ŽÂáz¨¯ƒÝgÙ'-/qCjG 9.Ó÷šaŠ©%P9ƒ=‚ÃéÖÍ Øêˆ%ÇãˆåA!R·”±Ô¥N#©Ÿ^BUÈûÒž!ãÞÆ8ïŽ7õ4“Èd‡#²aÿ”Œãi"2Ž•qü1[ 2¶î±AÆZ¨G÷NÐ:µS‡3öf€tÓíÓ8ÄÒ¼‚@5îîí ´À)ôïH>é}.¼¾)#“ÅŽh]ÛeÍpš†ˆø£%ŸøcMTZñ[¨Ä'äW©MÙ.Cׄ™ãÞõ†´r7þm‰¥ßš¼#PázO  §–@Dü¶› ÔKDüÁÒñH«áqñ÷‰%-þÓµi¿ÝãŽé6Ç…÷P6ed²¬ÃÝÓ+”ëÁvHøÀL¹~Ô>gWë©vY å–d+á¥Ûš0dù¥G‡,_b‡©*Mà"pGŠ«ñêuO )>EרÆçšâÌb}`ôØÛÂÒݤ}f¼|é“C(â²êèÉ—k—!§$;9éŠq‚ý×$(K7œ¦«_ããå×é´>ØÂFÍ2ý˜ 6iÈæÎ'áóá vË Ü)ÝQZ·'Pq‰—~-¡øÐð@b vþºÒR ÄÜ“[J©Ç—ƲëÓ6ZvOí‡<ïÆÕ²7=¾H, ®Mb²2ÃYÚgHPµY+D¨—¯ ª¶r$¨Z¨Âg®V© Ù&ØÎ5ì;*H7ݾ¤’X’÷,ŽïØQ$·'P‰*´Ò!lXÛ~2PÇ,Á¨F{‰ªq\U‡«…ÏXÞÒ™nyOË y¤.ÿOÖßîD_hfߦŒLÖz8"Sð&Z·Ñz„¨ÖÃÒm©¢u U—0[¯R²¥ >°&Ñz¬p¶D´Îêݺ#ÅUø О@%^˜¶22>x ŽAFë¡qg´n»IWi¬õ>ã å_¢õ6ÒrÂ+ó¦ŒLÖz8"íI"$Z·Ñz„¨ÖcÁ¹¢u Uj‚ [Û© ÙÒÛ¹&Ñz¬p¶D´ÎêÓåŽG´n-•ø~ð–XÒÂ⺵d ŽY2Z†Îh=@Z!º´±ÖÅÔ¿Eë}9㸎LM™¬õpD·„hÝBDë¢Zg]­[¨Â›,V© ÙÒ7Ö"ZΖˆÖY` ¾#Å­[K%¾­¶%–´°­[Kê˜%£õ`Hþ¦@GÖ0Ò Ñ¥µÞ§|¼q]¾å&FÝË›ÃÜASF&ËÛæ Èvž…ˆ¼#ÔË»‚OLaÌZ¦šäž5—œ7šàc+U&mI ²Ÿ[ëDöó¤gÌ Ÿ[ß‘âjÜÙSVi-´¸½Û:¨c–ŒÞƒ¡3z·Ý4W¯¼é½zFÚò™o09™†píi“ô>ÑÎjõN ›•OÐ)œ_À½ËTt“8ÌÀ­vM˜9f<7¤Û¾À}-±T›kRá-{ ÁŠ¿%P…¯a;h†—åj|_Êq€žøé~Ò£2xŸØñtçö*›ãÃëø&1YÕö¬ ¦á®ÒiY‘òѨñnÃO BK×hén<ÐÊ­=ÐÆm=ÐÎí=Pë¨ó@Gt{{@ŸÝñx€,¡¾äÕ•MZáU“˜ì6÷Dâ½…H¼Ð#ñÞVÄ{ Éý.c\¥Fd?-ñ>˜5ì~€t ³ xb©R¯9­0vÂMH Á¼ØH×° ñ@ƒ`p˜3ñ>Žlîp]¥±ÚûD˜Vû)?ù¼ÍôÊ&Óp}Ü$&+9œ¥›b/D‡Ó4D”,… åôî¹[6ô —(Ù¶A÷ÙiW©¹c1Ÿµ&Œ]™ÐXÈ ¿-±Tã ;aöO!VË ¼yè@ )~é¸#ÉQŒX{%:@º›æj152æ(ŸJ=ï­ÞUHHjáu|“˜¬ïp–®<‰Ô²W¢ƒí!oWæ¶zDߪñQøUjDÖwmR¢Zàã3áEì–@¾ìoG Ú¼è„@S|6¹%qñƒêît˜3·Ã¯«4¸èo©Ÿøó¶ZªÞ4\zÂ…M“˜,ðpÖXàÐ WÃi"òu’ñµV“ ,o›¹"ò¶‘w„ú( ûºËT°ê"¼û†@|3ËŠ@øðËš0Dܶȸ-Tá¶;R\¥Æÿä&{•µ"â¶u2PÇ,qCgÄ -n]ÚXÜbÊ+îg½Õ¤ê W r#Š;BYÜሮ;·…È$B,AbÑOÊÛBº'‡%ˆ…*|ãäštÙ ‰UÎu"»!¬8XÛíHq>&¶'P ¹–@®°ªñóiì$4Nþ¦¸L‚·í¦ÇƒwŸ ÒÁ»_ƒ<óSÁUH'‰W¥JxG“ ,e›ª"R¶‘r€]†„ŸõqÚ”©4ËÉìO¿/­ :­’ŸÄj{ò¯ÃÝ¢Ó˜@ÌGd¡>Û,c*:Û°YÚ–VøŽìõ`I/ЉBc•sˆBIq09ìHi•y#7j„ZUø Á¦øÙn€´ ̪z`ΨÝöÒ£YƺOØ8Õ>)ªç¼’ûd—˜šeÛ¸…ˆÀ#ôˆÀÃϺ¿‰À-Dn¡ ?p°ZzFà±ÊO œSÜŽG,é:Õè™-³„o÷<hŠïnîH÷¸Ux¨Ò…Ûnz\áRÜ·Rxo{QM¡¬ðpäL·Qx„Qx,:«‰(ÜBDáªð6‰õÐR­&Âc•sHgÅÁxGŠ# –tjtÍ–Y—Ü4ÅW˜w$…¦U¤Ux¨Ò…Hkäq… õ­Þ›F…Ã-©M¡¬ðpDþ¦n 1ÜBDázDáágÝßDá" ·P…/+X-Õj" UÎ' gÅA~`GŠ# –tj|˜½e–ðmÈMq)Ó îq«ðP¥3 ·Ýô¸Â¥ußJá½iP8Þ•ÞÔÊ G¤ O)ÜBDázDá±è\Q¸…ˆÂ-Tá=Eë¡¥‚¦v…KºñDá¬8XþíHqDáÁ’®S®Ù2KøR𦸔éèi…‡*Qx€t7=®p1åUø3wüzË(pˆ4M¡,ðpDWž„p GèÇ¢•âð†Ï›T¿ [Kê"?¤oˆ!²ãkœK#;~¶´ o/Ý‘âj\7í 4Å[[ Á¢ÿ@!X7u²<4Nþ¦0@vül<®ï>Óã¼Îü’‡êQÒÎ[àÓM‚²Úm"Š¨ÝBd;B½ÚKsok*:w, ç¶%Þ<°"–ðM{kµÇç*µÛ*™;[Ii¾ÙpO g¡–@ÆݨcÙB m;#vÛºJ£-Ä©IUŠÏ{ýÉd-ñYÀ&AIÈÃÝ+dÙ°=@ݤ=ü¬Í y€ôÌ]áÿ+ Á†Ýš@ |æfà ¼?uK  oÖØQ&Í=jõÂÔÓ„Ó2³Ï Ab¨#‰Û£‡ßÆíÒC÷¸”1Ùß@ò¼È4äµ |%W“ ¬äpšn Q²…Œ’lkKâŒã{±®(Þd¿~Ö}fó’©9’VøÜŠ@5¾³tMŠ[\ÂÎÒ†XZ¨§INúÛ¨ÂVw‚uÞ@5>'Ñ2wº ÂÔGG +w;üDî º#r¹ûD‘^¦ôr?½Ð{·É4¤šÆj‡uZ“ ¬v›Æ"j·Qûõ`ûQ!£Þ0÷µ¦úe!ëqRÖŠ@¾sM õ†A˜Tܨ6A¨ÂG›öªÕû†¸mDZ›ïÌÞÂÜÈ ÙŽ,2ºG…Ü瀴åP®åhSîðºàèV¸Í¯øýŸf¡¬p›•" ·Qx„Â%lG.SÑY¼ö ô" eKøœÀšš£l´ÀÅúv€ô7.^vÄPi–=ª9L-jÜÎ>0'Ž@Vß¡'õLô QhRý=Ô}È©ï/¹žœ†L“®So¶h”ÅnTDì"bP/vÄe*8 ”HÝ6HÝB5ÊxMŠ[ çoHËxïwÞhŽOmíHq5†à=æø8eK w¶šcº¿#{èË3b·®Ge,v‘ßHì§'Éž÷H䴷ד §&AYÈá4Ý"d !(¬Kç>#2ÔDÎIPDÙÁ¤^ké>–)¶r5®’שṸî¸l¤æßa½MŠÃ-æ±4Åâö‚ç£ZÕøÎAøBƒŽ@VÙ¶q$ŒHþæ¡SÙXÙ&FÊþŠË”Þ4î{ÃZ¡™F( >‘¿©öDð"‚ß LEç‚ÈJ°¡û’(<”-¸ƒ¾fÅ™çHì¥ÆÛ­@biŠÏƒìTcJ}O  g–Ax³ïBp‰ßÈ*<ô¥ŽwDáOÊXá\ w¾jÚÛYãÛ#›eYÛÓÌãWé´<üöi™Py ¥ºñ@+´ö@´õ@;´÷@­:x Î=ÐíhìâM. óEkõ¾t Ø´m¦Ê®Žè gßk2œ¦!ñ£¥Ó…éxƒq™ ÎÎEâ}¬]†H¼·P…!`ÍŠ³ñ>V8Gâ=)Wý;R\…/+ßSn h„_290ßÝÈÆûÐ8ù›g<œ;o™!õ`àXì}žÈyaúÌ1§6UL QÒ$(ë;œ¦¥Kôm!¢ïQ}ÛÚ}[ˆèÛB¶sÚ™Φ6H7蛇¬;R\…9„=ƒPq-… Ýp B¶®“.k¼a«£¦`¯ù8@gnû@ËHá3Ìn>¶fw®hNö0lÃÚ­IP’u:’{È®h¤¶”N—l?1Ȭh<ÐÒÝx •Z{ Úz Ú{ Ö¥ä ò^°)ª¿ÕÌ"”] yÒd]€@ÖÐ2Õò‰:Ýx •Z{ Úz Ú{ Öõ5]À&·Š ÌeÍ,BÙâ‘'äv•NSu‡¥kf ýdén<ÐÊ­=ÐÆm=ÐÎí=Pë¨ó@Gt{»@Ÿ¯úš.`ó_òΡñed3‹PvxD©5y•NSu‡¥kf ‹[z ´ò@k´ñ@[´ó@{Ôz ƒê<ÐÑÝžÆ.Ðg±¾¦ جX1‚f¡ìñˆR7jò*¦ ëK×Ì·ô@7håÖhã¶hçö¨õ@Ôy £º=] Ow}M°é³ÅÕÌ"”] QêÆÓ®Òi ².à°tÍ,aqKtãVhí6hëvhïZtð@:z Û3ÐØdƒí«º@ow„0u;‹PvxD©5y•NSu‡¥kf ‹[z ´ò@k´ñ@[´ó@{Ôz ƒê<ÐÑÝžÆ.ð•Ó¼3›¯-ða¶&AÙìidS”@Ö„ê¾NP΄ÐÒÝx •Z{ Úz Ú{ Ö•ö5B!5'«‘”)ð¦Ùf¡ìñH>¸¬ Õ}*ðDqKtãVhí6hëvhïZtð@:z Û3ÐØú4Ú×t›–+ðY¡f¡ìñÈš¼J§)Ⱥ€ÃÒ5³„~²ô@7håÖhã¶hçö¨õ@Ôy £º=\`þ•³Ã'{p-€ý4 J.Ž(u£&¯d\€AhéÚ-=ÐZy µÚx ­Úy ½j=ÐÁuèènÏ@cèó¤_q˜Û¼kÏ7 Ê.`O³ ¡tšòëK×ÌúÉÒÝx •Z{ Úz Ú{ Ö™ú5]À&g |d³™G(»@<¢Ôš¼J§)Ⱥ€ÃÒ5³„Å-=ÐZy µÚx ­Úy ½j=ÐÁuèènÏ@cè“©_Ólr¶À瘚y„² Ä#Jݨɫtš‚¬ 8,]3KXÜÒÝx •Z{ Úz Ú{ Ö™ú5]À&g |Ø­™G(»@<¢Ôš¼J§)Ⱥ€ÃÒ5³„Å-=ÐZy µÚx ­Úy ½j=ÐÁuèènÏ@cè“©_Ólr¶ÀgP›y„² Ä#Jݨɫtš‚¬ 8,]3KXÜÒÝx •Z{ Úz Ú{ Ö™ú5]À&g ”i3PvxD©5y•NSÚþ‰AhéÚ-=ÐZy µÚx ­Úy ½j=ÐÁuèènÏ@cè“©_Ólr¶PØŸkiæÊ.(u£p¯Òi ².à°tÍ,aqKtãVhí6hëvhïZtð@:z Û3ÐØúdê×t›œ-ð¤Í;œ äéˆR7jòŠAÆ„–®=ÐÒÝx •Z{ Úz Ú{ ÖsêÔûd6{ÎG66)[à{bše‰‡Ó´zk|áÄÕpš†ˆÄ£¥G$nëG$n!Ý—ƒÄcAyTj| Õ:µ4Có9¼lCÚe?_E,Mñ» ;b©ÆWí)~ÐRÔ{ ¼Ãµ#P߃;Љ?=,c‰÷™Q§Ä‹iy1¿Tÿ“„;¤Û lŸùjÊzG´”‰Þ-Dô!ö¬T°’¾Mì†@Dí±˜li‚;¼kbi>‡7ÄnH7}_DÚh‚Ï]ï4Ç7³í)¶¥ì\(~Óˆ¨=tæµHÒ›)êëa«½O‚:Õþ̯&/l~µÀªIPx8M2¸…ˆÀ#Ô ¼º€¡[¦¢s7‘€n¡ûrèš^Âø®Iq |Ùìf€de˜†n—)[bi†gÙhŠß8Ù3hfÖ,¬ufÍû:W|:¨#­ÃµÖq`Î(ÜVi®n¥+\”4RøéC(‹Ë 9þ¯¢zýæ»·\Ý}~s÷QºüRV,?~Õ¿,úÇïŸTøìn‚²~ÃiºF¿×é4{mÁF˜«d!wø?µ·fùfÉé /Ì7Kˆ¥âƒïŽRøµŸ=¥p±ÑjQƒ$Õ2º³JB+.ñ ·´@åÆcéõ¹E\{éM¦uÿ’ðý’›»w?½ÿœC–RÇ…b¦YD(k1ÑCk´x5œ¦!û1Àd;Ëm^ýô@7¤¸~ŸaE MŠ#5vJ®8‰¨ªðÃ^;Rœ|oBK(3a¡ã¼óšµ¸´¢“Ë"ôH)¡‡Cz˜ÍuäUPº˜ZÅ[[5æ3DñŒ‚ô¤(ÞRSü@§(ÞR:àž¦DQ¼ƒÅJ·‘M:7<]"(^Št+¾(/Ä3ý‹ŸÞ6jd'š”Ò|8$Óf Ó|<1Sìª5Úê5#-š·6ØEª¥ÌH‹æcI¹>Ó6QDóÖÖ7üEóÖÖ?ó&š·TeîLaTûÉ¢ykkŠ×=¢yFÁŠæ-Uãí¢yKMñÔc¤Îi>Øå'ÅèÍËå‘KóîÅOo… Gz¤”ÐÃ!©|®¶šœN!D?„"‹B¡-YüÄJ æ ú“ZRîËßþÕf™3§(>RJñá#å‡5ÅmqÅdz²˜â-¥û3*ÞRÅVu¢xK‘eiS¼µUcdÅJ÷S¼µ5Å[³Eñ–ªðÆfQ¼-qZYÅ[[Lñ:§xkK(¾ÏŸ9_<7ʇܜ ²O:N9‰æ#¥4éQbš·Ó|¤¸æcáOkÞRºG£æ-UL!NŠæ-Å4(ÝLóÖÖ7CEóÖÓ<±e¼¤öSLÝŠæ™-øŽQLóÁÖ9ÍÛõæûäØ·Ò¼M¼x»–h>RJóáq¦yK1ÍGŠk>þ´æ-¥{4jÞRea¶9SsU‰dek)¦y[âï²Í[[Ló’}‘tÙ8ÅU‰ó¬DXK‰æ›¡¢yK1Íêœæ­-=B ù>‹ö­42t£87 Šæ#¥4Ó¼¥˜æ#Å5 Ï#ÍÖ6–Ò=5o©)Þ3&qÞR,ÎJ÷Ó¼µ5ÃÍ[[LóÖÖ¿”$š'&Dó„RÏÉúK4o)¦ù@Ó¼µ¥G4/ŠüfšïmÃì.ÞEó‘Rš‡ôˆ³8o)¦ùHqÍÇŸּ¥tFÍ[jŠÛƒ¢yK1ÍJ÷Ó¼µ5Uê%š·¶˜æ™-¸ÍŠ¬ç …ߘÍ[Ši>Pç4oméÍK·º5?ØÛ[FÅÃ'Š”R|8$Ó,Ëo)¦øHqŇ_¥¿RI,Ê[J÷gT¼¥Jó˜Un®*‘¬lb­3ÅoKœâgEñÖS<³×"¢xFÁ¦„DyFÙ+XK1Åêœâ­-=B ø>­õ­V66eV,`é'š”Ò|8$íHJdš·Ó|¤¸æcá¹$¦yKéš·ÔÔîͧ檉æc­3Å4OJÄt˜hÞÚbš'¶0Ñ%šgLÜ¢yFA°“(o)¦ù@Ó¼µ¥G4/Ƽšæk5Š¢·q&KÑ|¤”æásš·Ó|¤¸æcáY[Ló–Ò=5o©)æWdec)¶² ”î¦ykkZA‹æ­-¦yb o ͪ²qžQ0gˆæ-Å4(ù›âIÈ[z„@ó}òÊç¿$![Ø,YO4‰DJ9@8¤‡Ÿ}K1ˆw€Xxî^æ–ÒÝÀRŦwqK1”îæÖÖï°¶˜[øZ7qFÁ<.AŸPø qK1Ô9°¶ô`òœ„l9ï_@ã^ÜŸlcÐ4E¢²æ‡Czĉæ E4Ÿ(ªùTø“š'”îÑAó„*¦×¹¹ªD»ÐIµÎÑ<)qf·ê‰-¢yf §¬–Õ~†››N™…)‘h~ ÎhžØÒ#šïsYÞ ÿÌôÔÄæÉ |SŒh>RJóáÐ9Í[Ši>R\ó±ð¬-çS3¥{4jÞÚšáR[4o)çJ÷Ó¼µ5ÃÒ],QÛbšg¶ ¥$šg,­DóŒ‚`×1Ši>Ø:§y[¢!Ð|ŸËòjþK:›4“‡Ò1?›(åáD=d,è[Š9@¤¸Ø*2°”îÞè–*¦Ð\qK1”îæÖÖ ?Ã(`m1`¶àºU€Q`,‡Ä…{¾ÇHskK8@ŸØú·8É ]ƒI2DJ9@8¤‡Ÿ9€¥˜DŠ;@,<Çvæ–ÒÝÀR3|“8€¥˜J÷skk†Ÿâ°¶˜0[°R` ©8£`ž q€@skK8@Ÿåò8€÷™” I›á VDè‘RB‡ô0›Çc¯â‰# —?Q »ó:Rzß”¸tQ7‘Õ K\¹(q‹Ø9ÙM½6.j©'ë%náèû½‹·pØ·pPâJæu©ÇFÜ¢O„yÜBöœž»ë9ém/€'ø ñH) ‡ôX²©ÀRl*ˆŸ báYl*°”4q*°TµŠæ-Ŧ‚@é`Sµ5Ã=HѼµÅ¦f ·hžQ°Ÿ)šg”½°»Ô¹©ÀÚÒ#š—nõjþyïË,ú쯑R½äa%̇_¥ÃRIä‰\Bé’%e[¥½ ŸØ"¯#(±˜êµÀ'Ú%ÌÛ%,¯¯Dò–šÎ¡'$Ì3 Ä,’gÔÿÐv­ÍqÛHð¯¨üýí“K—ã*?â÷[©»ûº±×Ž*²Ö%orÉ¿¿Á!‡=½$;ù $ØæÄtƒH™Ay…¢ì†yŠO䶨)Êg[ÞÞCDù´V8Ìßèý;s±ÅÆïiá 埋p»á#JÞPšðVy_“"|Dùî4Â[M½­Óc|´¥m)ÂGÔ‚SŽ |DU¼Ë Â+N ¼BÅõ®BÑÚ„(ñz‹š"|¶UHx+"|q¸Ÿ r0CC ˆn(Gô\䉂\„û%Â}âàá¾5¢'i¨ó@ á~A÷ PEA÷ P˜ j„, PE ²(@a(@A¨w†ž½p?Û:†¢y mŽÙ<ÐùÍööן·‘XMï¬V§«Á+(±ú(ßü»püÈÅPN.¹ÈËEÍ ¥æC5±ÿ)©°ê{¡¨™!¢ÔÌ`uõ¶æ"Š¶6œ†"ªæóÄ@¬±â'ª â XH@¡h4‡*Î E} D”š2 ï¢q桵5€[ %°ð[¾¸éŠ·±Í“ÅŠ÷gªg}[4Áz¬ïP‰õÎ>î+ï{Tp¾kbœïjêQ ~>õ™¬‘C<7”‚z¡PÐ/5ŠâœWE!ûk¢Ç¢¾«P‚óm¯Np~ÂCÄù´WFÃ~zlFŽûxEsúÚIñP¿qüÞPŽô¹È»\ õí…Hÿ“™_ß2óú"­kOÏ]¥ƒˆR:(ŽÑ¡ƒˆÚð(è £üíÖ|F:ˆ¶VüÒè ڪ⋩$Š-è@Ù"µ@ EûÐAD)dÔ”2êØØ߬Û~îk=Hi­T«³½Ÿm!vèøë3P†¡Œº¬È“@)#_èQá„P†¡Ì<”aEG⢮EãÚ°v÷¨®ì©Õåý3[Óø mD["+Úµ»¯QdEjγ´a}ÐÛZð‹~0GÄvU|\ Úˆ¨0J@(hÃÚeîzgESB(0!8ó$„´›V*„åˆbŸŽiƒ e7ä"Op%ƒˆR„¡Ì2ÄÕ‘QSÊÈ(ïÇà!(ÃjAHiÛíŸQFÞдŒ|ƒ2 eÔ…2rÑ”2"J)ÃPfÊ°":å_}«•."*ô:ta5õº˜óNè"ÚÚðû¼:E[5?ÆŽÐ)¢*þ¤%t¡Pq !PüåsLÅS ¦…¢ º0”9 ÓC.šAFy§w@Î<‰WþC"H–iѼ |D`(»qˆ M‰ ¢” eæ!+J" ˆëèü+þv™ %‚ˆ ½XM½­9T"ˆ¶65ÅéA´¥ÖUñ‹!…¢|&âBů†Š¸Êœä¢)dþvN y¸V,‚oÊŸ.RM, J(@†²Ž€(rþv·¨b¦ˆR¢0”™‡(¬H‹"ÿêûW‰"¢‚ «©¿‘9èE´µÙDQD[5ŸšÆÌQsž? ŠˆªÖqfP(’D¡P”v…(Šî¢0”9 ¢ÈES¢È(ï´àˆÂ™'Q¤}¹ÒðhvÇhbÓûB†²{‡rZ=ªƒˆR:0”™‡¬¨ÑAøP¹ýî;U)![ñ¨ÐõP‚ÕÕßÊœb‡2 »ŽŸ'•(Þg„TÄK(!¢*~PÓƒBÑ%(© JP(¡C™» „\4¥„Œòîðß(·\’3OJ€ýr%¤cåIÖdšçŠ¡CÙC¹hJ¥RI†2óÐ%,NiTB˜”t)¿õþ‰¡úì-Ho†{:Wü$HÍ×¼€BL”Qð[/ Ž0AzU#‘ ¤¨ ¿Ã¤¨jCîéŠ_xÒ ¿ò¤W(rtQøÛ÷»ãÜP§ñÃp˜¬F°tvíüŒÐ|Ê®Z§ä音åöýí=Ü}}¿»B+ÎNç·îÞi´uo¶Èû}ÞSsŽ%AsCAó¸Q°Õ.Ll¥1\µ_ûÎ c6ˆQøh Mí`f„Õ¼f ¿Ì(rÀL…¢Ü;˜QØð¡¾5#¬ÔŒ(|ŽÖJàf„Õ5 îàfDÁµ äŒ0?g™¸äÍÞÄÄæ-³ãžÉX¥´GùpÑÀ™z4R‚z–KqÔ‹¹1u:WÇY¬õÄ1 Ÿc»æü%OPÐnÈ·+„ÂÖÈ@’ 7èø˜3™sþo(×ñ¹ÈwCèxh>¢Âî%4oæ}7ã¡àQãŸ("lÎið5ÌîûÜŠü}8#¥#¼3Ò&ÇÍóy«œÕð#Õœ— p’¡¬±¬È768 ÝoŽw ÝŸQ¾FlbѸ„î°šŸA÷Ç*EZZÙŠ;$ UQH‰Zµ‹²Íà@Dp å'˜Ó±ý*&Ræ¼R‡Ï å|ó!Êçvá¸Ï Pðy¬±æGžàr…¢©.5òÛ’1) [¼Á†IY øl<œQ#ÎL9ï̱Üòl1ßXå,Êp Ççüáèæ<Ý–M¬áúKÇ}ÝÕ0ƒ³E¥Rá'†XQ­¹0'6ŸtëâûæàhéŒXLT‹5!E&ˆÆ4ŽFÄcGA6H)p#¬Li ÏÊ4Íäà|•¶JRØű ¸g(G½\ä‡y5ÈØ…#ŒÂ¼^€ïbb•&Psö>™Xc]‘O1|ˆù­aðTD8*%‹¼£Ðù¸^¦¾éò*g¥Ò§)»ÅÍœŸ1‚g;˜sm.C³º+ƒkØEºb¸³€ÈÂPi1Gq-o¿ö5‰S=E΂K…-¾_ÌUóÖ4QŽ‰*(Ý#…¢pÇBÑ܈ÁC¡h1÷V¢x×䡼€Õ’/Öè—|í±Ë¶]xl,PA)ágëÅéæÌýƒÅQñ)̦¢á)L~ˆtO­I Çö\4d;õ)ØQ¢Û •ØN6Àv«Ü³˜€a.¢qÇN æ|»ÐD´ҞЄµºo—xfQØZrÄMÄ—üÎ1h"¢|Öšˆ¨À=h¢M9’È üí>%‰Œò„ñÍ"ú§žïÿæú/æ çüž°ÛPŽÝ1…ÆrŒÒvaã"™Z‚c5kkˆZÌ(XU»h„ÅhmÕüÔ*¦éˆ:>M¯U2õæËöÆ GWêÝŸu¨Þmm‘g¢p[wá¨ÛJPO¬¾Fõ”‚yª`ó%ÍúÏ …¹£§žKïݼ0”oXÍÔ?W¨捻›åHv׌®s>Á{wçËx^ C9ç ý¨²âƒigí…%‚®Õœ<=C˜ìþ!o=6£¾Í! Aâùa¯‰ÀxËÍqàG´Uó,~o²ªFŠœ^Êßã:> l­+²õÚly'¬xñðÆP¾Æ?ÆùV¡Øëï 4@|2@t×Æ­|†óÒ:å5 %мµ8k,ã°%ç‚0æ弪ÄÚ¢A·r_@ùBR 0TˆÅG_ºê{™*Ê[#{Ô‚_’ Ê+ ò |DÕü&&P>£'ïÛ‚òÑÖ:†bµä¡ú•¶E‚åc+ÐAy…"ù€òÅnå3hŠòÑÔÆ%˜ˆò)gûÏP>gƒRç—A‚ò†rƒ~.òdÓ<(QŠò†jýáÊc¼UÞSY>¢ÔQK^_‚ðµá¨ „Ï(ß5?°ÂG[˘ºoQ^¢–|’„¨5ŸbáUëÃâ£EM1>Úò"ƧĶg|Z|`ËñŸ=rÿÜ`‘½Î©òÓyÓ å˜sì*¼‰(ÅôŒZ7Äs]õã\ÏV<Ö|胻BÅÁ=£|·¨Á=ÚªÅàQ+w³Ï( Ûàº@ÅWd)Ô­ÅÀua‹_q®G”Ü3hŠêå;udpl@õñ´÷:Á‡ ³Š=ðØPŽÇ¹È7=ŒØú =i-…1ÙÌ wÇk~Ø<¨5ûcr¬Q<‡®Pñ9tQcÍ»VX—Åv¬Ë0 œ8².›Ýðë‡ëd{–VÖñT¢ÜajAÚ1ðIi%†‰–å‡AËxAŒ–EÞ~Aóʳ#0 RŸ_hXL"ȶñÛË^±FŒz}è©+%æ½UÖ6.ÉHMy`ïÑ Ï‰ä2¿íž(÷µ åå| §¦Ÿn¿sBoÈ"Z¡-µêÙAmI‰ßÌGŸ1\¤s§cÝuoVåDÌÔÕfÁ˃îÒÑiâQ„‰ññŒ¾?Ð`Š.mÛë+UT®æô¤)n_œO5˜¯5œO…˜dãøÁs‰ó‘¹=÷]]žìñs¥œÝ¹?«:˜sy[æû!Dpywéˆ/—ÁàrQ©t¹À)—‹Æ)—+küà\.`8BL(\.p#.GW—'{.ï`ÎåmþÕŶÊåÝ¥=L,eª\.*•.8årQ«r¹²&\.`Òå7âò´˜¶}–ƒ®oØóâ|r`ï`ÎåmÚ?êòîÒ¦\^ƒËE¥Òå§\.jU.WÖ„ËLº\à¢Ëøúënwx¸=lïÞÙþ~Ø?º¸<ì®O®w¼uovûçܽó±)}°¿üýóÕÉûýåÓpzp6ÿðõä—ËíÕo(ëŠNþØ^þxëÁþó—ËÝawrquòß—/ÒiØ|…üùä_'W»Ý‡“Ãþä—ª¹úcw}Èÿÿúß÷ÂÕÿÙ_ÿvqõ©9 ܶYßÔ»w¾î¯ç‡-Zïh‘n <ä_ì¯>\.öWù×g³ÛM¢­ü¡»ÿÝ÷ËÝ;_¶Ÿv/·×Ÿ.®¾ž\î>‚“g§èèë‹O)kþû°ÿÒüFÙ_ö‡Ãþ³ý߯»í‡Ýuú?DY÷{ttþT˜ìžï¿9Ù__à˜ÛÔ¬o}Aû¯·Ôpû~ýôÃ,ÝðåîÓöý_¯·ÿCô¿Í›Îø:¦qëÝÿ ÿÿPK!È{Ö©üŠxl/theme/theme1.xmlìYMoE¾#ñF{oc'NGuªØ±hÓF±[Ôãx=öN3»³š'ñ µG$$DA\¸q@@¥VâR~M ŠÔ¿À;3»ëxÜ8!€€æÐzgŸ÷ûkföú㘡C"$åI#¨^­ˆ$!ÐdÔîõ:WÖ$N˜ñ„4‚ ‘ÁÍwß¹Ž7TDb‚€>‘¸DJ¥KK2„e,¯ò”$ðnÈEŒ<ŠÑÒ@à#à³¥åJem)Æ4 P‚c`{w8¤!A=Í2ØÌ™·<&Jê…‰®fM ƒT5BNd‹ tˆY#9~Ô#Ç*@ K/AÅüK›×—ðFFÄÔÚ]ÇüetÁà`ÙÈ£~!´Ú©Õ¯mü €©Y\»Ýnµ«?Àa–Z]Êþõ›'ø–Àý2¼Gc"Ñr„öy ¶Ǹš“¾8E/ÂÔ¡Àðö°n«ÈÞ™`æÃ5‰ë¼ûš‡xsüÐѵ‰±¢É·¢ØîrΚ\xpKË*y¸7NF~áb\Æíc|è“݉Úö8…®™'¥ãûVD5÷N‘„(¤ßñB<Ö= Ôñë. —|¨ÐŠš˜z]Ò£}'‘¦D;4†¸L|6C¨ßìÞGMÎ|Vo“C ™GùaŽoâ±Â±eǬìðÛXE>%»–qm© Ò#Â8jˆ”>š»ì-ý†~å û.›Ä.R(zàãys^FnóƒV„ãÔ‡íÒ$*cß“¢íqåƒïr·Bô3Ä'sÃ}Ÿ'Üg7‚{tä¨4Mýf,t,¡Q;ý7¦É›š1£Ðm¼mÆ` F“¯$vNµày¸aãÝÆãd@®Ïž·}÷mß þó}w^-/Úm§ z¯Þ<Ø}±Ù%Çs7ÉCÊXWM¹-Í>Y°t`QÓ™")Mi?³æîàF$¸ú€ª¨áöØÕ@3ÉŒõH¢”K8Û™e/o‡}º²'ÃU}f°ý@bµËvyE/çGƒ‚9#sþÌ­h‹ [¹–1³/"¬ª•ZXZÕ¨fZ#­0b8k,Þ„]‚½ xy ŽèZ4œM0#íw;€ó°˜(ü5!ʬ¶†Dx@lˆœå’7«&vy ™;H)OèÎçÍÂkà´³•0i1?trÎ`êd]v§ª‰%åÚb :jõÕåÕ…8mC8•ÂÏ8… I½oÃlW;¡6kϬES¤S‹ëþ¬ªÂEÃœ‚qÊ8RmcÙšWY¨X¢%Yý—Wk:Ù.Ç›¨ÐbeRäÓB톖 ‡$Tå`—V´ïìcÖ ùXÑG¨ÏÆbCøÁ§Úž•p¹` Z?ÀM˜ö¶yåöÖ¬Ó”ïŸ Î®c–F8ë–ú&%¯8 7õVè`žJêm^Ýqç7EWüe™RNãÿ™)zÀie #ÂE¬ÀH×k#àBEºPÑ°#`î›ÞÙ·©ðœ×ÁæAõÿ¶æ,SÖphSût„…q¢"AÈ´%“}g0«f£Ç²d#“Q%uejÕî“CÂzº®é RÝt“¬ ÜéüsŸ³ êô¥\oN)F§­¿{ãb‹Œ:µ—Ðù›û¿PÑ3ý,½!ÏgdÙýbºKªåUá ¿z=uAÀ¥Yk;ÖŒÅË«¹rÅY‹a±ØϤpgƒô?0ÿ¨™ý¶ jïCoEð©ÀúAV_Ñ] 2H7Hû«û»h“I³²®Ív>Úkù°¾äj!÷”³µf‹ÄûœÎ.6Q®8§/ÓÙ™‡_Ûµ¹®†Èž.QXæçóQªü݈÷B ·á†~Ìì—$™Â“©ƒtO˜ìêóÁ$ûɤ¸6ëôF#Y²O†ˆŽóóGá [BökF¾E6hM¦­ \ñ\ ¯Ií´,ˆ—Ï&.(ŒdhÙ±¹&ó1€oYYãÖG;ÀÛ&k­ÖÅ•{Š%Æe (ïw™÷䳨ËìAñº€ËÔñ›]–y œ7›xð5R`8štMÿ…¡c3ݤìæÿÿPK!ÀÆÚñ xl/worksheets/sheet1.xml”–moÚ0ÇßOÚw°ü¾I(D¨ªVÕ&mÓ´Ç×ÆqÀjg¶vŸ~wqãf-A€‰ÍùçÿÏ>/®«’줱J×eQB‰¬…ÎU½ÎèÏ÷W”XÇ뜗º–}’–^/ß¿[ìµy°)Bm3ºq®™Ç±YqéFÖðO¡MÅ4Í:¶‘C`:bÿøÙýÔq˜{¹xyïtÜ·kùÕ\|[º[]þV¹ÛÀÌŒvßôþƒTëƒÞ4š@È0róüéNZKŠ¢ÖM¡KÃ/©¦Dœ?¶Ï½‡NGÑd”^±|[ëtÕ͆QŠýøVðw|¹0zO ‡dŽÉæøÞöøñÞ¶õ¥ãhÖ¡ƒæÁ á7ã-„v·d‹x‡rà ‚ Œíi2¦i4Kúš×{ª(œ«õ*ˆJ‹‚HöE\šÎS´…Q éa(È= ¶ÇDNÏàmàÍËì·G}Û€»<ŒƒŒ9¶7>Œc°eOæ¡q^ _åÿQqßàtø*“ûù2ŽÎqŒƒÂÑðœ dÿ¥àÀæeçä ‰l`“°sÒ_ˆC^Ÿ“‰ 3Úf:à{[zOÊQ’F£YïæA Éè¸çGú:2¾Àø³»ÙÀíÂ)ťеÃÂ…™ôÔ@é­õ­®Ÿ¯(xò7|-?s³Vµ%%”D¬(S8­Œ¯:¾å²=WÚAáðG>\>$œáIÆ…Ö®k`5 ×™å?ÿÿPK!%­š@ÊZdxl/sharedStrings.xmlì}érÛH–îGø0ê[]v„HŠÚ,»Ë® Iº,µ´¨Zº;:* ’`“ ei&&bžåþ¸6Or¿ïœL $©ÍUí¹¢«Ë&€\Ožå;K~÷ýåh\Di'ã—+ÍúÚJûÉ Ÿ½\ùñøMmg%Ȧáx“qôrå*ÊV¾õøÑwY6 ðí8{¹r>N^4Yÿ<…Y=™Dc<9MÒQ8Å_Ó³F6I£pGÑt4l¬¯­m7Fa<^ úÉl<}¹²þ¬¹¾ÌÆñ?fQ[j®m­­¼ú.‹_}7}uf_»cmC Òè,L9Ê œMÏ£ñ4î‡S}ðYœF#ü”­ÊÃ$ÿÃûl<ÀóAéÇY2KûQVŽÏ£, Â4 †qÆ×1Öù—§çiÓð$ ž¬´0øý•Õ@þðWýF´ò´GÑi”b30‚i´i2‡së& Gfa"#‡YLÒä3 Áãó8 bgñ×a‚u+†¹Rêf…ŧ$'Ó`Â8½’ eÓtÖŸÎ0ÑäT~¨~êìúj¤òVZLêS<'FÔOÒ4êOëß5¦¯¾›œƒÐ°‡)Vx<Ý€<0Œ« ¨oœ´“±¡Ö•Æ«ï$!Òâ‹löñˆ-‹Ò‹håUð:LOÂ4 :³Ølëkvú6¦«A³´&i< Öך럽ó£|3îÑô«ý¸wôwÖÖjÏ·‚Ÿ£“ ‡¹Å¤Š^ÔŸ¥ñôêOAkv†9¬=»OG¤ƒÕqˆƒ^<‚õú:6 ~Ç—ÁOÍਬoûÉW«<áKO?W‡Ü®ôú.åµ{uÚëǽƒQ_¹D°±<Éf'Y4%)w:x¦ÔM~²³µ¶†•x²¼ÁÚc‘7ž‚k§i2Ì‚p2Æ8=8Ÿlô^#ãúwÀ¹úÓ$½r6ùx÷Yþë¿ùw#7,³ (ÛW3h> Þ…cÎwû¾{Ü ÁCBpÅž4ìG˜Kó9æ8™~&²u'£‡BN{'ºˆ†É„Â@{¿ØŽ6ƒõà Ï®›M™\ÁF^ýyed³YùÁ›Ü#™‘‚ç ÛÝÛ=>ê’Á·ÛÝÔ¤B ‡³ò}'šFéˆÒbNÏy²>A€ñëx<ÎRýHââxñs¾Û‘—GÓmÖÖÖ6½?o(+s&%ooløß^ÐÈ–ÿm¥§í£î›îQw¿Ý-¿ßÂ2}Š‚AÂ9“qmõÏÇ ¹aÓÿ˜} “³¸ âÁÿü÷ÿ+7ÑNF#,PL.Jã0èGé4>åÃ"Æg3]µ=~ô.¼ƒŸât:C{`cÝýÏÿß 7ï°QÍúvýRÚ}½WþéZ˻ο»??~„Ù&л‚4é×GÀÛpt±Q)äHû}<ž]ÛÁåÎöMÞ©mo^óÚÖ š’w®ojóMÉ;yS½dbZAs ’§uÔìp˜©ïý|ì«8æÒÄ“íÍÚI<}ªó®<ÝX÷>͛ۋûi’%§ÓàgÄ䥟ʌµµN0̵oê–½¶qãåÍ2Ù¾{d™K-Š Ãl‡á”jl`ˆ»m‰»­Äm^Ûª>wI>øê骗…uâ,<FÐG äø^4=OiTõ(Òžíí>…¶=€È¥nºK:†Î¥¨½Ódšô“aðdw÷àPåšsè»ãL4¿ñð*È&Q_%Ž2Z‡Ž8B;¡RCŽåÅ% ºï^Cžat¹‚~˜`®Ê¯›ÞÀXqü;Š3Ú+Ú‡e8”TWÑd˜\á/"›uÆflZÄðæ9‰¶8 PÐY´‚nÁ|°’™R~8‡Qy”­ñ•°rš \åO1Ø<—WÉáÝÞ/Á¿s™±¦ŸÎãþy€ÆÇj]AÛ;‰Â±’öS4ˤ2š`x—õQ8ÏÄÚ©ï½Æ§‡ùê°ZŠ½‰Õ )÷¡#>…Ú &Jf)/€S¾ŒUÇnêÙl\ï'£ÿ’EíÆ égpË/—0æì(2 @ýÖ^y™œ¥Ç1,ö àɆ<„1€-°Ý‚O±þ˜\c³#øÈ¡ì\:—?nU÷:›M& $ Ø{ù0Ιƒ£lÝ“(péâÛbßÚaÂP3¦zZHmPm‚³‰G sF%+Ò…>š\TO‹Y1ªþ÷ø¼5€ò“Ô(wiéÔús %MH¶ýœÇv¡9ç &!Óè"ÎĬ´Û"Œ§²0¥Æì:/X‡ÞþÞa ï°Kì‡=êå­¶$6€MÏs;9¿ÊDïÀA õN؆;‚öË p¢çÐ΄"i5æä]b»„bnÄä@>ˆ@zø¯vKçÔidL V!ØqÁDØ0²¾j/æj†N&Güa6æ)!ãÄ/b•[ùkzP4½ð,8a_Ô2cìÜUpž@çUB½Í VRàGQ˜l É—/çA´‚KD* ¦çPˆæzŸF äwÎà §±°O-Ù²Ù|µqrÇ<ëFK\ì%Ÿx4Êâô(ïì‚sž™¾fPåØs­†2W@[O¬@@r¨ÊO)€=ÿˉ½ãLsô #’;̽pÅÜ“è²O[ #À¦Ë±Úd—àÜx|$Ï qU#x~Ê3™¤"êp0Xø7X¨KWV̦AtΆÓàmïÏï;¯yîªfT„»ùàrÓÈ?’1àY8t³3 Ðè6èÏp‘ÜwEpG‡Ñé ú\43RÑ5x¸: gÏïðhf›œR XÕw×í`ÆD'†ñI µdføÚ ·Öß½>èõ~}{°×m¨HjÔÑÀwEËêÎÍéKõ‹Í¡;i¤è°LÖ–ã9ÊŠK?ròN¢hXµ8Ý-hî]«Õ h¹@gºýä:ûbZóO—T § p,aeCŽy–÷~¡ú1J© ±í\(þ×[{z”–á]Ð ž¡|]à@œáwÃ3f9„ ¥<òß®«¿Þ­++ÞÃ3ÔˆOâᔲs‘RÚ6z>ðƒï‰~N:6ŽÎY0$²qÓd‚¶ ™Ê=!áôú3Tú°5‘|£í0qÚ"=¥¢œcö5%(*X@Zp–N­†; X²2Ýed••ú¡»ß=Úm»ò¦(.RAun&IÊ¡}W‹Lðˆ[ù&/³èHÕí!´P  Øû·ñÙy­uÆÃð$’·½ÛïìÊ.œ¨… Z°#?H´æ‰ÖühÁ]UWÚVºòóŽ·ž{n®ù®ì­l¹ïË]6ýÓinúÛöϲYÁ¼´Kÿ,›þY6ý³\÷ÏrÝ?Ëuÿ¦­ûg¹îŸåº–ëþY®ûg¹îŸåº–þYnøg¹áïrÃß冿ËM—›þ.7ý »é_ØMÿÂnúvÓ¿°›þYnúg¹éŸå––[þYnùg¹åŸå––[þYnùg¹åŸå––[þYnûg¹íŸå¶–ÛþYnûg¹íŸå¶–ÛþYnûg¹íŸå3ÿ,ŸùgùÌ?ËgþY>óÏò™–Ïü³|æŸå3ÿ,Ÿùg¹ãŸåŽ–;þYîøg¹ãŸåŽ–;þYîøg¹ãŸåŽ–Ï«³Ì!ÕE¨ ÂöV@ÖªÀ7SS¶VƒŸ4`#ت#bƒÐÿP]Âkû¤½+ˆ_Éq2ï3Y æü%â˯¸Kªε½A€J<þ6Œ ˆª ګΗLœ/™øy®s¾,.^‚…¯§ËòçË›0Ζ…MŽë™s²8?ZŸÆüOÙ¿W+•'¹S¥x"•e¾Â™rí[-{¥p¢\ûVY3V\wº †=+Ö°Bˆ LØjÆD¬`G :EÂoÂöLÒ „6¼ª»ŒXÁ'095¨†ßßMWÅ´÷õh`ƒà â‚ ž*§ ]ÌuÑû”÷ɇÑe d€|ëáüzoœ0/qª…™1Ð&¥¯¾erQaß ¿ÔerÇý„fáÝ—Éq>øVhðý¯´X ¦ðDˆû+Wù¾BbX:¦ë>Q𠺈£OÄG'`Ûˆ²S r9˜ m5ìµxïé,ÿ$>ØSã¦pÈÓçó1ÂéN‚õîd¢úçáøŒˆ}§?€¡á€ñé9¢ô’ ÷¶U!Š¿vË¿üÔz_ù­½[ùM,¿çIÛév÷;ˆ‚ØíöÊ͘%T\CšÑ¶%€&àY6@ütF@ºAJP7ðâEü ‚ßO›`žå~È4t’óÌÛöQê7ÔPn„jüÒnwÞüúf÷—ãî/ÇåÙèÃN·×>Ú=<Þ=Ø/¿`½ÜoÁ¶Z—(`¥ôZþæÇ1àëˆÔ÷EvžÌ†€åŠÏ\Üp†½ƒCÃÛ oW–ÁÊIÔ]ðäÝ^ïé}lhÎ=Ú‹³>¼Ká8JfÙ=Ûz{||Œö¾m&xsÄ÷ž+¯rCzý6Âs¿ðÜo#<÷ÛÏý6Âs¿ðÜo#<÷Ú͵ªð¬¹Va.œesÍ;˦¯kú#ÃRí[Á¦ÆkšpÒ¦Ö\óβ¹æŸ¥ÆkVïd–~¯é‡ñš~¯ÙôÏÒã5›Þ½lúa¼¦Ækúa¼¦Ækúa¼¦Ækúa¼¦Ækúa¼¦Ækúa¼¦ÆkVa<åÒ»Çݽ_ZäÒ­÷Ѫïï¿ï"òÈF 2f²ÂFw¯Í äãx¦æuÁÃ4„Hd¼£màW=—Pø@Ü|v¥Œº é~4”n¼BVÀOq§ÉXÊÇd®Ï^e|Âp_C#Qa˜{,·™À±JçÞ4¢¸1áEkw|B¶œ7dB”˜˜+ø,Ò¹c`˜$T¬atÉYÑ-Úš‰àÀŒOfðêŽáªG8û'6»¼ß©#‰S¿§ýÙÈ·ˆ"‚çxd§ã`2)u)›*ªÔ)àþ6³A_»t}B…ƒÜÚ¨¹d:3 b´`!,Ì`Å: thÆEÆR0§ä¬”0µ0€šüßÂÍl^÷GPú˜ÛK.Ðç6Yw%«è5Tž^·zð)Ñ­ˆÑqà .„ žj¬Q'˼œí÷»ÝýãZ»{t|¿†:»?t÷¯Á¼98Ú»_ ûûÝ»·@ .+wqMjŸÛËòƒÂó—/È–4ÿ¥¯W[GlNÚG0nåìW[^ø*\£6¶Ìå–°ìw¢/ÎÏ œ®oŠa,ŒÆá ÖÎVV$»â‰ÒS_¹‚®ú}žâ™GP¡9ºŒBb’Ø@3ô0DÎoŒñLT§3_Ñ:‡»»fˆÙÉyÞù X_¢9©d’¼”„½#z)¯ZÎu ¾ v Y1¦F‡=b‘ÆÓsŒ¦¼»<`ײ4TÂÙx4©…ƒp‚#XÏBÉ©¢Î~˜™L!G3aó`BDÉ@£·ÀxÕ ê#žüFlÄÑfÿ‡Ó?}ÍÉâ˜5DìgÓ?@zD Ôƒ.„ÒM_—¡ÐßÝ ’ ÎÀÎÁ{<ÁÁ^gé°†L¬Þx®'5 š%ŠµøsFgÖ”;Í}.hË: í9Ãò˜¨] 1øñè=“8” SÕPȈ”Àw„ "§ aIÙ¸ñi–Š%Ï“+±H9[iÔ’ Ü°{bvªë‚ÙxÆÊ<0.¡X+Nï8ɧ Õýáîûîq·ó‡?”ÒŸ/ö3`h<¤8¥Kbz ¡rÜça-ÖÈ’jÃþp_ãçîëÚîþ›(¬Î»‚(Sn€AÄ‹´H'¦?’1[ÙäÆ©HOÁ)‘Z™d[J·Ð&UG0b –O8sç ÃÑaÝÔÌiøë€\Ñdv¦aä.`éÈ&4Çy2B§Ê ùq¤ãSDô—Ä)æ—ß!ßô'5ý EÍ ¯…ÝÜð[e ›G¶|Z_õ ù“³2†‹˜óf+D2¨M€€[0, ÔMy$zyÃaäIŠ1f=Qù5ƒ}†)Ò‹I q_~ÅØ-%d/¼ŒG³4JÅ“kV^j±aèö@Z+Ïv©MÓÌmå™ »@€³$ €°l†GyL¥Ù1ÊÆ.B"•ßÞoT S¥¿¥ìËhúã2šþ¸Œ¦?.£éËhúã2šþ¸Œ¦?.£éËhúã2šþ¸Œ¦?.£éËhúã2šþ¸Œ¦?.£éËhúã2šÕ¸ òjA6f0s`Û9j#y5}Â…µFfk0z[&€/…•Œ Ì"#¯Â‹Ù)\ÆsÉt¿M/̲ “`–…™†µ}k 'È;ÆRF‚£w‚{æ–þÀdV¿£°*²«LŠèX-L1y‡n¸ÎË5ÅÖÚ£!Πh)€ âú.»›sh1mÙPQÇOô;u}hÃ[Ç®ÝÝß¡[O4µZHyîƒ(ÈÆ@P[ˆJO!=¡JÝÏ#'-=À™ûB›:ÂáÎöh{I*÷)Þ•S-H(:³júgXÃäIý†ÏÆ8°÷šâ{C.FÛ§“Ë·\aåIsaáƒùu©*šæÃq‹I8=°ýë\ÝD×NTˆ ~v+V•¢/?G'e½Gêãƒ7»UûÎà_ÿü#@9 Ü¿ú<–òÆî~ïøèÇ6_ê•ÛßÕ¯ÏpE ¯ÍLzf¤D§Ì-€%³ª¡±l¬ÐVÓ ûËÄ-šëÖ K¦š…iQm¸F1%u.èbG•›E3ƒÑÐC“ Ò*A¥ŒÃ¡¶!îζ&óçùΖ Øýr&³Ï4)bjZ¦ Œ•Y'Xd€&0Bá8 $?±NH#ÔSäÝP&0hçÈðŽUÓ¼ERÄz‘ì( \5i΀`04Ë‹F«˜ö7A'Ê0Zƒ‹,±O°/òÓ°íµŽSËV=3†[ª°¬t;Œˆá¥•EéHl”LÀšHO¸”Rl™Èœ– ô„ˆ ã—ö@JC¢2xæI]9λsÍGá‰ãdR³0œk¾b®—ééCXq|—)0G@d<`’}ðùH§º>× ûŸ¶B†" s²—UŠ[%´tÆ¢0v®ž¯ eR5Ρ ³£–W&W.Uˆ)’úg²|r‘“G4šnna™h "ÁnßÜyø±5iµÆšYŽP:J•Õsr8ÒÃ\Bz1µÂ]U-VY6X´3H'#g8â}>ÿY íyñ„ J°’ ýBp"Cù~“E›€KÎÄ&Pì>!K—«I\ =ÝÁøk³×MóIJ²5$=vÌ;±9]¯rv´™|WŒý-qÎ;¸eU‹ÐNJñ\þÁΛ.7íÀDâ™ÉÅ済îí¼¨ hœÞ»²42m©<„#?Ì %,Dß´ÛÿȨ14•m¹‰ŸL á<9Yà›*=”?öm,èT`Ýÿò‡ê@ɘjá[ìÈ„]€Ðó¹Ñ&`ÃåoN'j`±(ã `¼Ks?W´ìÎè°g 7è<Ž{‚Fž¯­ñ‚ÀÀ±CfÉ•:ŠóÔŧáØœ‰ÉÖ ¶Š<…™†ç6_9 VyŽ¤øˆlúaÜÿMQÒê#BeòÀ_öÈÀ_((~AðšÙº’NŸ¨VŸ(ͳù4( rTbH4e&sNXˆ~·ÍQØ?8î¢Êçip•ÌèÝÎW'2PÌGÛ>Ãò#šŽop °I8&_VÍÓ«ÕÀ™ Ƈò´ u†álLRT?»ÔÿCFòx*–.´zÄ‘)}á± Ÿ·žG)nƒÒ´b]¦¹ä{àÂH ÐÒE} ˆ´DW:Œ¼b(öZ’¬cP2H¼Ppâ[¯(Žš®SuP³ÇdH&ËFÎ+þ#>ãy³%N$0b®!3,ø—Ü“–CÁz±®$Èáű‘ºøv¯ðžŸ/–ÞY? 20õ…®ÛÁÒ¸-,&#¶8ÎÖãG×}Ö½}âüácµï6pLA gz‚ 2ÖeniG€‡ÙLV¬#{R `GlfqÝ ^¥< ;(^3¡L'bcæc¶*£ê¡Ï) Xð” a ôLÂœ GкDŽƒu`” Eòž|'Ô)¬.nåÉs¼jÐRÝg>Ž ` @Ž8õÆ }¢19 ycCRõ¹ö…;«uAq@î„ø3¡½E"xì:nÕëÁJ2j ‹HĹǀPe€á3•OèÕAóØÁÉ,%GCÄCQIxN¬m—”»<¿J>Ž¡¤*‹–nfÍÈðÄN(u;Š‡Pþhà‰7ú™öÅn.&]pÚ²«à`2¼ïË2QɵC£fêæ`Cñ-™ŸÿÓ·”^ ‘œB”€5UŤ|¸õÄt}M¤)\Ó[W€²¬JnSj •P0 ôÍ·k:Á‰úí;Y`Ù~ÖIaKª ô@É:Ïu¾+[3oùzý,A.îÚa¥# (a¿ß’ÜEÁîRsjêl9GÕ´îä|ΰ¨mŠ,ìå÷‘‘ÈÉøO[`¼œþ‹°CÕ„›—–[ÔäàæÓà Ë£¡¼•)ß•#?fxθ” ÅÇÌ’½€Œ˜hÚoàЀe žŠa•¨kÊŒ¾€ÈŠãyÞíÜ'æ]*UàPj9Ë <çÒJŽˆ¹DЧbâ,¹†Ð@ë×pg ÖCo£ê#,£"²ì®‡šõ¯¸ÏŸÇµb÷XˆcΤҶú¨±Š¼FãÆ=u ÆöéÁ'PÈYCæŠ&Á°§,™úr¥õî°Ñ¬o¬ N6Åå(Ýþ|…ââ·%üŸÿ”sZ§X7¿þ×ÊãGà׊˜êW››h¡ÁàÎ’Xò‡.:¶úôs)yFEámöaG#P—šËPy*6 àñ˜‡Ð6 x{ôi,¬ƒÁ„ÿV« Ú§ú à‹åb ³ñC?Ī#—8×G];Gè™Ò‡c&¼ Vœá®p °<Ô:¯6Ú'úLG«åg~À$X Š#vAB} µ{hÔé]a@Ó+xHã1̳a´’7u: Ï86)‘Œýp´ëšüv*`ňlŸ„Cy? %ürîÕbËÚ¡ €ˆÇHšé#̦wmÊÂK¦)¤íܵ)M¾˜cUþ ø1 Øç#µÁ€Z¥:èàÏ4Ø—L†_¶÷V¹X/Û¸Ó³ß,”(D¢¡9ý®VÓÿ–ΚD¶Þ0Ì¡0 pB,‘ð°Ý6œ¦ Ç"rÃ+®I‹DŽ»$Ø@Gç`U¢û(©üÞq"$’ vAé…ëX ±¥TW§ŸX>Ð|x,v—¨üú Ô} ™•mgq_Ô{C~*²`,Àåx%FßwÊRæVžg© o²ò¡cÈ$!€ËZìr‚ù 0ª?;ôÒ²cŒÀ]³C4扅:=I¥L[vK%ÏÙC”Uô²Ï×%ð5:—ÃjnûïÐ)MV½ ¨H©¯v[ø{qZ@v ƒÙUÔ@ïÙàÞRèRIs˜ït¡²Ø­³Iúh| ¼®aï6?PbQL¿žÃ)™É­8½©†%Y‹Š—[ã$˜¼&qÓR –jV‚V8ŒM¿ØkýØÙ=¦Â­m);è %ìôWár+ò*®>ÂéóÒL4¤ÎYݾ^ï Aü Ð Áò7°më¶E,±õ(M“ô-Ìï!à‹…¢hñ°~€ê'8‹]ç“Q1¬|•j·"º^®°ËMÁ(´£a¬uh+ÿÕ ”êø«¶“ÊmHÇ7…Ò,Ñ’·;°è5%ÿäÛú·Wø§¶·W JßB£fž¨3s„`ýä @¦©÷òV±r*iÝQ‚ë_O¹÷oÁ7µ­Ið·oúž|3}ñÍåÓà›Ñ7ãÒH: ³ó(‘®[ÏßÊ¢Åå€ÔÓLaÞ6 ‘rEœŒ{Ö<5ùŒ‹I! :5•Ì¼·–± ÀË¢£‰ áIåö™e’â0NÀìQ„#%,Œƒ(e¤Á$ûùàmH]ýT•5É 0?ë˜Ö â´` „r¯qƒ•±ð‚dœÍð7ދöY:T\:`ìæâ8,Q«¥<ôAÊ—.㇨Ìã-B@¢Z5yå4W ˆB¥ÑHüj•µÍÍ$$£‡^øêC”6‹á¡Ã<½@*="3éwÁ‰ªýÞ0jÛA›S #¡‡¦DPyw™&Öjµ»ŠsØW,¦_)CHNáð"øe_â8v >ÜcÙ1²Ã¤_6ßܯçéþà5‘E–¯µ,"çʖŬjŽ·IÈ™r+T¾¨ôe¡KñxØguߧÉY„³‹[€&Âs…¸éOQ»È^?.•CiÃ;AýH?|$ðéKÒÏûoJx¿ ',ü7¬d„›ëˀݲyÝhé\aðÌ0qDc8§ÙBú.ÏsAÈÕÐÛƯaG…Šîì !º”‡F&7“eu{Tœ vly`>®96©îzûÎ">iߺ9£Ô™ç}ئ£€ §{”œ±šEüª‹DŸ8îq¡ó Ža}‘‚‚b›˜¼(ïÁ‰èO’)‹ÖL 3 Ó¨.5ŠÓ—a#›—ñyú x×­^דz>¢úˆ÷*çC]Jã¨du`…¼ºOQ¸¸”¬ Äž}Ÿ*°X¸¸.‚UZèF9ב\dár›ø* ;^½HÎÐ ¾ÕÈýÜ¡?'ö¾ªô7÷¿i`¹˜“«gÜ`#ÊòØîáR0õ–ÜPn»ƒ„óî©!ª,Ò[4R‚©¡ª=dç³)r¤*"ÌqòGáG{ò‹4|£s.úÕ¼sûÇ â“5O¦]v`"DÁÞ]j`:+ÖÊ®oôÎ.p9„Ý3mKªá‡¸V<µc‡üдÚ]~ã5’T˜_ ´²†-®sºî"slÙøæÁ&–T$þé!²l“œQ*1ûuo2q+ µÚ…Í>‘WœÈ½ûó4ê;oQ#¾ÖÒ"ñŽX©ƒçâŸÐe¡)§R$7è1É–<Žf›t¤*?ÑpÅÛç=‘;ÜzþåEì˜  ]µ1Ã~9V–P(­­`]#¸ÎÁ¡ù}!–©}X&M¬@‘bŠrÃoÂ&«—#4öºÇ-¹BQ=3¤¹äRéúêÀØtò¦ÔRY‡$¨:›E# ±ÕßâÏp£^^™ <š[c1å³<éΔbYåM/ÙÀ*j@À×úòm‹ÂG\åE•áý€Òò¾Ñe@·f@7L8„¡i¦[âØ0SôL{°-†ÍcÍ#` eËá¶æ†¤šèUPæ4¾@N’Ž0XQ²€¹’6}¸Hׄ¢É¬‰(fa48¥'Rß ¯KFÂ{ßÀn¾‡V‹†ÌÝš #B¤6ÌÚKP~ÏàQtÕW_8‡³j„2_æñ¬ÒCԌȾ–Üîæ¨ö7àå؉¨1&oªÜÕuyÛO˜ÖìïY¥Â¦§(ïŠñÐÂIFƒ@èR“Z$`H\Ô‘€¦ ÜÞ1npãyîÑ5dðD›t9©.'¹l¦Î ¯Xnkv¢•^U/ ?>–-âæ‡ù¦œÌœEü„6qéœ[€:ìø¸ß‚g¸e’Jy ó}È3g¼d”¦b² {{vÅç°È27pߢWÛ™³ìmÞ·hË«)Ü~H.~ûF<§ìöØMš_R\âj/;Â-¾¡‰åt!1Û®`B€N;$mhYy³ ÞTYÅÜ pMhs4>×zY’¬Bœèº8ïYZL-VfÜ»^‚wÜí ^eM庞‘*·ò d²ò0‡ø‹ ØP… ó‡ÜØ¿.ØOÆâñ_ŠH'ù0|`ùâÿùVÿnhSuý=c½Ûú³¡û®ÿDæÜsí—ñì/oõ½£½ÛúkS÷ÝN|†Ò’÷܃keð—·‹‡|·ÝpÚ»ï–ôzïï¾þr±×¨[_Öö,ÆÇÌZ '– ÊÜ[…ë1dÙá\"<~ä“ pçH˜Û/.µn|«\)D¼ÿ‚W®ýü&õÕQø*æ+ç#`LÐiíY¼CrCˆ ªÕÀî°ÀÏ1PD`Á÷+·Éä’â¯N<£uv„‚ÉæJ¤åuü¿ÿ$·³ãΫ¢-…å)â¹k‹…Z¯ó;–y,ª}¡÷¼‚ÞÅK=æ«& ³p¢àncÁGu÷Û*ä€ò‰Òa:€*/-¨cŠòúpâÉ!rZ2…çÛ’àˆ~œög#>¥g×M˜Êw²‚Æϼº!d0·»dšì‹­™$‡ÜhT ‚ÀøÓà\#G¾7¾0PÈ1 *z Tëi ½Š÷”ßbÛí¥¶ÈB:‹ê&²°{MÙ|K_ l'îáÅÀ&¸# j6•íäP Œ6Ñ8ÒsC´“:ĈŠP¯–1ÊfÓz ‹T‚#ÔCdÿæUñ4á#šnZv…™Ö÷Â1¦šªÅ†œ´ËX sÛçLä@ G;/Ír@ $ü)ÿÛЇIϨ¾åæÖÂÃM˜2 ¼,å´ãoã\óþh:"‹y¤óÇLº\;ôꤴ B§Xþ݇ØÜFŽ²CÈÀpÔÎ"¤Ür¤”âà"VI˜½[¬ºù[ µ”iùÒ…'Ƕ1ˆ.(1,=yg(õ‰N!‰mhl¨Ü‚«QÏÁ^g«Èý Øăš; Ðâ?ív;ºrœ&È2ÏÀ+$Iûa¶(»Œ=õÚt Ü3dôI)ÈGdÚd´Ø猡²E‡˜uúš÷;=M*VF\¬×›… ¦Ñ ,Ðì°Þñ⤥­‚òN•_¿ëÕÖÖÖš[þÎØz^âDb•‚àIÏý\ߪ¯ã:dlm¯×¶¶7ŸV&Ürr‰çÁ²Yð¤u¸›=5Ç‹Ï#6HÀwq°¸˜šbd=/‘Á2\-I ]~‹c fâ©! Ò=n^BX‡Ó‡"ç ë)F‹uaó‚°Ø†lýL»Ç£,’ìɨÛ››$6œq!âÅЕÃ[Jb\iaø ôYpì B8m’ŒWž^k_¡ºȼuó#õ=\q ?ç‰U§Åã§}JÀ⩘—­<•ÃéÝ5#„@Óßþ€ F¿Í¯B2RºI.týAïØ5æ?ÔL1I—OEéã(SB: ×Éï¦ÃÈaï2\Ó¤ö )Ìí¹M= º×5/æüÀBä«ä©{0±Xĉ\ZMó!›å-Ò`Œ¦Ì‚W5Ø /‡ÌÕöÄ”ZÒØ+í™òÄì…qóíqCÌ´ [@u×HÔdšñ@™‚ Ô x-ÿäÝ^ïi¹ùxƒt4d/Áâ`†VöÍFë›õ7ø_œeÀÉBÕ? ‰ðQ³Ï ÿá/ÍõæÆóuüQoÓ×È¥&ƒÓ?†£ÉŸ¢øåÉYty¼½~¼ŸŒ¶wZÇñÙŇ_Ú-y:ËÎ^¶ÞüùC{ÿ‡~ÝŽ¢ÍáÅ_6j?®ý4Úþdz_ºþ±ÿ¾UVˆwyc5¬:Š6™X˜Õ,Ÿ3ò³ÖïçÖ‹Þ»ä$uk¯"}Ôã” N *^kW¢/é† ,Ñ—Š†p7Lb¸¤BÅïç ¡î‡éDñ‡˜5fò~¬™‰•#.–÷Øîí¯ý~ÝÜb* й’!Ú3ȆØ9 C‹£U¿-…ÁöæV¸þlms{}§ÙÜx¶†ÊW;ýõííµ“pçys@ämk}kûEpú<Ü úýÓÍg§k§Íþvÿd{}skãô´ú<Ú¬=k®‡ƒçѳð¤Ù××ÖÃþf´~òl°õüùæéóÓ2õvÕ4)îhĤp³¶¡B^%%ÁÐ^ÈJPTcs÷2 ϳºXq+Ùun»Ô•£gõì3Pßø¬å>WˆfVD©6õ®Õnûá^Ìu^ÁºÞöþüžf?·~7Š:ì bÚ´wçƱ ¬ ¹_x+Ó”ïb'²““Y ä”ÌoÎV`û¨B8µž²2zV>œŒó¦J;v#`ïÕÇ+‚¾oðŽ¢”ÁÒÔO1,Ô|âë=Pb†s/´?”#²™ËÂ-ÆX ¯"Úâ%0h¢­;=±‘r¶bŠ_å·qÕƒî%D1EÒ@ž謴f0Kgö€ý³Fd>jà¾^¡0Nª£}¢K‰— Íb¨aÀ‰u^WƪbÄj]Œ5ljáMUª qj8Câ0° 1©ž½ºÓ8´ÁUÿ’Ìt4d1üÆðà<Íc­à‡ÈáMW»]4w¨bUÍOç1 W¬“ypow×RðüÊä »…Ί Èfüç'BÃUtñ*ŒçÖM‡³³‹@,ãº÷£ .ßD–šø'RG·¨ŸÌ6{Š›(™°Þ£=âÄK‰Þ97¨ébáÔ‡U^oÀi]­…@8¡>?žYÔ­tûwú†Ú&Àgqõ¹lb®TöL‡ã˜\,£ é$\Gœ‰(épÖ8¡åŒjM L’œ’\âù6Œ†àÎ[k²ß¿YÙñ÷š³‚U*Å‘)oçÍ…kí…ûW ‘bE–q‚“Ÿl1"žHr_PÂïtá¯vÄsc¸8„ú÷qÑ+Ô¥^5zsÅF aeÈ*•ô"Dé± µëÌš9VòÕ¦WâXæ.¹ /ß"]t#Œs&Çå^*V†ñI£Â ;öÊuœÚù`˜‚>áž!¥ö‘‹¥2Sϛ m‘PøGµö Xuƒ‚Hú™ûÚÓro®Ë r-Šù-ÁÐv> yÃZåBÖàDn/…þ¡þÚ“/X÷:çf–ÜŽ¾¢+t[‡µæÖ³òÌÅ⇰† ¦ˆ(/Äd2Gñ¨³8?t…ÏIÎ"ã!R¾ÄTª2ÀÍ8HÃ>¼IËØ «ñç|Ë5Ì4§ —‡ê 1ªRª¸]zðl‚TË\z`”a5pÝÌz [¥.¯ÐÆï;òÇî>tPº „YÄ¥ñÉ ç›ÂàåŠ]éÃB³;”«vW ƒ ð*žé¥,N]÷ja)¬k;$Ø[>H²†»¯÷\Ò4ëÛT½­0À†™Ý-Ñs··Cáµ_ê ´8X*…Ø!I0'£–M9]^LE ÷]ë§Ö¯oöºiÔ ‡µP œ#aŽœ„ üøRb\)Õ¢kP.ãh²Ù8ÿ(PW³ç DvyÅd-@ö# ­aª =ù\0—&ubš—ðÆ NÅ»è`éÛ³† €ËØ*çè³÷à§ÀÏÞ 'R>UŸ½?yWºAòöç‘d6ò™² ½FUã/VÀ& Ò”Rç—9­WrÎI!0Kݸò“ñÞþaY;ñÆÞÿgïÜ—›È²=ý?¼CŽ£OHÂPWWÐ3Â6Uæ`ðX¦8':::d[`-©%«ÀÝQóózó$óýÖÚ{çÎLÙ–MUwWáŽs(PfîËÚë~ÛýC*Bð—‘3GÇ¿èD–VkI²[úàò7[EN@¶ÅüÙ›ùˆ´Öñˆôpn”]jƒ‰r²qÒJÐó­]]5(ŠuW-ª‰Ýäqï™»¸z1žŽçoUIeÙò†0Š£Áñ„c#A›Ðʯp„Ï {ì[ù’Q@’Ì ¬@‡êQº|/@½K"‰þþœb³Ä¸ŸY®“rÔJìQwiå_ëÊŠÀX)©ï%rlGª¹.ãi)ù´eJ“ÍÒ«ù¾‹g¿?þØ8 cM…kª!Üyx-Ÿ©öQªy Rs“õ›:rìy!é{Wööµ©ˆ}ûˆ%šF;½‚eA‘õjÑûMS¶š.É/Ýßf€’0Ä îÀäCŒîŽ9¾¤ayoêÏQÕ|­ˆCð§ D»0—,b ßÉe1ì¥ý°b #CVn!lé±±-<ŸY†–nÒ§Òþ¯6ë]IzÂ-}8’ü^ñgÈNòô÷ö½Æb¶fEnîiꨃdñZ…—Ì•¹T ªyÝUÄäq»ÜÞ2R‹Þ(ÿ2㫱ü]g`aÙí}Î ±ÃÚ³£½Ã+Tª1.‘â}9ºÈo©™ ŒãéÏØ“7E‰öæè§!|IÜÞgÞöPɲ 3ƒ¿9fã¹K6ëA3g[»›•p ?:ƒÖÆ’‰‹y˜f†% D¥S†ô‹‹ßÓ,6_.â~qC‚HDî±ÙêK™ôI&w‡PîLílàÞ©ÝâõòÀÕ°|§»÷CZºv{®èUÌø µ´Z`>U-&Ë“¥ÅžÀ⯰ûAØX‰‘/G_ðýâ =¨ áa—ÅgZDX•Œ¡IÎxá"K¡gižÌà«$\d(Åàaèx‚æVi¬kQ¢ô;Ló÷n^R°}—8®•äô#‚{L4Š*mÕ|Àwج?•±ülFór{°HAjz92Kl6Z.X_ƒG¼–y–å~Ý\1†-¿Î*c>a=ä=Ü Ä=4§¿,ÜÌWx­ìj l®Â‚ò ÒÄgxŒÔga*6cxrÒ—zꉊ}˜ÿ. *iq*¥Ü[¬r²*ë›5ž¢Yq-w«>®+*[J‰°t*fèºV|tF³h•ëØÊ$qTÿŒ…4êÜ` <¢%]¾M¨Œ„\vÜ(ßú{…°é¥i$BØüpØ){> S›ΔÚŽâ=Èv8†`-I^ÿ ‡vÐGrNù=Oè¥ýé ?à’öù‹>¤NS .¬Œ01‡`ë3¨”£âN ¡;`2yŒB¹¡($f$åË÷V"àè5ÚPD†ãVåAIËa…ÿ“ #Èî¬WoüæÔ ®ÁBF^n_èªÝã1®×Xö?8Dá!ýÄ ŒH29’ƒth.úÆð{HÆUhcdÑŠÂvñü½úŠºê’^FÌý¿Æ¸“ö™Ë·Ï²éDZ̸_‚L r€{¯‰:tÓ7†#ȸL‡àãHOJCÓy~Ð?À’M~^Ã"Fcá ä#Xf|ÎhN < ½û}¨¾Úà5’—a/}¶eŸòlChòë—™D¶ ¤¤½­hikçÞ­™a…öûñ³\[×ÃW»Ï‹ËG˜„·WÑ“.ç#E&•ÅI2:1mš].h?kî è]“’P…Ð|èa@= §³`ƵÝòçhÞ˜ÔPäAiFZÿçh^Ø®h8Á¢ák™ÎÉÏ:\‡šÐâ²êqŒ(«% Ÿ÷//ÑØ>Çãœ#@öxpM=ðÍšq4›[®žF#Ô‡P}$yÇoM+¯£Jç¢å>”xÁyJB›jiuè ¬«¡€n¤ Z=a2 ÈÜYP1¯Ñ-¬MNRv«œ2²ÈËÙ#Tß +ÊÇ”ãW±ß¸ˆO៱&–N+®îI „í‡Úr’`?VÙ>*‡ºñÄœªETˆjÅÅ!ù.¸6:ãæÊsÛcWÙ1x®‰K•'G…~]8<1ã>­ r4 xççwÚAå×aþKÏ[ùÌ™T㢽‰ J)Lxš£ ¾;¢þz·þû¦áº¡nc™®åÈ’4®Ïêh­@=žDÍÅl(+OÈy…x „|b—Î"ÉäŠê^Ì(—f2ÊKæ£5ÁX•ƒ.~.³&S¹9ž9×vOh4¢Ž.s¢Ø,Åîfw#Z£5× túj§ÛÀă،:cý.4Òj1wMOPÕ­¦£Ë™0–m^ëF–3¤Qð/&–ä`½‰Âl}fm‰ Ñ,ð¬ àú Kú˱û°=ë|ø÷e$ü.Ž$pÊê™—ìRóÌF$iðN ƒ}õ ~Ö–p†±ÊéÁ¸¤+i°ezhòÎ8*eÞë×´€ê«*º>O÷¢F]jO•úµt={ÐòÒè¡J¹r>Q訡t¹ØNŘÛ/Sž÷éµyB°né» ëOÕƒJžZ²Ùßæ\¥Ñ^­å‹ÎsQú9Ï$Fr {kÄØW/êÔ^6¬f¶ÎÅ»ýG2ÓyubŠR¹ñ—igྰÎb§ ÷^&ó?ýÅ%ÞÕòO÷ÕºÑ PXª´6‰ý(ÄqHLùh,‡dðŽ²ւЫP B©Ò™_Œ—»$„ÔMÆ-„jrRÆ‹.Ÿ"Cs6Ëñ…k0ALjŠçî°Á1—²±bÙ¤nõ༹jŸ±_fÊ^ Õg]Ìê,"ˆƒˆj!^ú¬Ûí%òSÎèqô¦¸ø{ƒþI}À§°ˆò©‹'«@ufÁȨŠÄ¤jZÖÄ©a_ž¶gȇPMB4ÆxŒ\*°fh¨˜`ÐêÞ¾õÊ*²2Y|Á0+3¼§°+ègÞÌÌ\tb}RÚâO0Bsèw'妖:Q[Y <ù¹ÔèÔ«ŒC Àú¢'‡¤zhss°õÓòü…­ÀCm]ܧÂ#îJ –ê½t*ƒ[”ž§’Ü M¦£;ŲqÄ°dž•P·²þËU»§›´˜S :æ§òâMΈ[Fñ‘âøÚªÒ$Ä×åsôÈ ÒG¦¯‡J C¢\c~3?Í&64„¦BW‚š3™2É.”ú¬Jà‘3<¶ÀLÌ[1Š¸§&Þ1ØíSÏàÿ¤iYWqÁ6‚H³DÃ.T{Ä¿,¹%8‚­Và‘Ö‡Ó"¡?„€ÕK …%DC‡óØZÄûŽDhéÓò‘Oé›ÈdáKz¸æ JgÌÀV«À:Á³+í…#°h¦æ|: Q6‚ÑøšÕú«kônÀ¸Áá+d—ý×Ë¥Ùï –m¿WöxûÖS21ª ° ÜôCWEà Üg‹KOïGh® šËÀZF–KPiYc±E/Ä—®šø©5“Y8Axõ5ÖAXç×:þX$äœg©>jGÔÏÌ7H2 8õw+Oü{Bž\Ðç™è>ôûØçži8Kÿ`ª$Ÿìd`U Ìò fá9yO}ÊùˆÕ7øÆUK]²àúž-5í’=Z$ÝÉÐ("ÐrFǾXöí¨éŸÌâØxïÒÙùÂ1±“Õ†Á~ÉÂú¤[zšÃÆÒà­k¶2ŒcW†©b-Àç7¡éÝŒBaW(²¡e_ã´z/»Å“ÍÞ^±³Û]ßÛZß,¶»;õÓy±Å ë/_ìí¾|¾èùÆV¯{ÑóuoŒ¹®º>ÒxêÃ×ß/ž(’¿p·þö…ƒÐ{±½}e#ïEŽ–}Õ8Ôîö–%x[[/w\õÙWÔo&Ôl þòÇîóÎËõ­çõ•{jä·õŸÕÎG¼Ž®4ÞäeÀ» I¢ÛKdSm¢1Ê ½Æ¾ñÎÑìoLJû­C3*Å\âã‘ÕùKíw}Z¨dƒ6Þhy­[ãÅ`ËÍQ„XRePç„à}Ÿ¸oã:ÐÆb!^ä&¦Ÿã‡Þóÿ½ñ$mÖSË–Ø2Õ{£3Í1 :¬C|é rr¸ãδÁqaã–Ñÿ³ÀåTŸ¿ œ¶€•²G`Ñ•»&•.øìHlé0\E7×Ïà°Ž:Gߢj!œƒæ8´F\ÕtdµT‰â ž,a ­lüAvš¾b.fÒ—ÑÄô’ylê‚òkı@ΰ$L÷†îG#n-§dabR#îÊ'aéA 4øîq °.ññžÑ6czpÌÓ‡´®¢å@1×GqõxYÑ2LÏxšR,lß;ó}üEÿ98kï"ÄZ#Úh…EË òB"¨Svæ ôrÆÍ ¸ÛÜ9€cQ¨o‘s*ÂÓM ýÂr`d²¸šÑÉq+@u€©zp4ɵ+ÜRî¥ÄxÆ ·õ AQÖ0-( Ñ<¯zæ¬Vi(t¿Ø&,°úµõ‘çÆ‘:uÑ!~=#šqIŽ*RO‹»ôa»·V|ûhíéõ§«kß"i ž‡9ó¹°u¶±CÖ9E­ð"éÁ,­t‡ H;Å…„éB&å"lCZg‹._Ô]gÖ?¦0¹“îdKË‹Ë*¶ÀHêX•:MÛÿW[ÆÿWœ9Ã*[Ä»“êîæ³'÷ð9ûý uDŠB‘‚ãWjìÂiŽÇr·¡Ÿ;rµ^yJ‘RHUB~?‚Í›ü¶Éç"ä¸$Rq*P±I~zt¯æÄ‘n~÷õ`¿ÜUãÌ®±­:dž™.òUûc±Ç}a\½ã¡Ý Ö.î¾<8ï£K<´;OVWq$o…&9Ý^»ØàYÄÑzèÂ1ÊF«|±N»kú¨Ÿœ0.ÕŸŽÙ;†ï‡®K}õÑ'sŠÌ6ëÔyѪý5+Э-̪ç÷‹½©þÜAqŒJl† ÝÌû;æK¬¬Ê}£mì›ÛM7ãÓÁ ëÓh§cÆtgƬìðd¢ý‰šýj…†Åß©Š³ säÌw¦ãwÖût°?% þ¬øÊ¡qEˆ°wsípýž us`@åúV_3jÔŒ3 üÉS#Í\¡òb:|«‚`deŒË$~bLâ3³`_{ÂE3\!KàñãÀVSL™”z’齋G4- úV‚DÆeÑÞzW1BÔ ›uMt™»C×Òt@¸`ÄBWþ\›ÿ/ñZdieWâüÍr¥ÌsúzóI‹«ëqíáDÇ_"ÕQ UåÂ-¾îî²àÆ`’Ä*ª Þ~ÕPTN²±·7÷º•Á­Ö;º»+A¬ŽúkœCÀ©‰¤{¨ø%ÄÅŠÿõÝ‚/Fc<6â†)ói«kTàp x±9å€þ]‚CÈó»FkN±AtæQ8és$7ªxEÓBêl ‹£þÖè§ñûÁT*a¤ô¨x›_6 ±½†F N.áQ׉|f|U`6EnY:£~*Á‰Síø•c–¥KÄb¬Dl 4},n:às]3æ.0x&§áöãç(ÂÌ×Y‡[@O‹0‡>c|‹WÃÖb´ÙAÁﱄ‰„BOÀ÷d€iÈ¿œª5¶4€ÏÞ¯¬Ÿ¡º™ì*±¢;ìYÀL7KzW(m–j´¯% ]”I~=^QB¡[ Ãu ['™Ê~æ’³"x潕ɷ°‡µâV„´5à¬? Éu–Ÿ¢qjFuÙ$¶¹ùºW/VîÆ¥Ê~ 6‰A\Fh±"ty9:>[1,À¥€ z ŒûøSŠŒm㺻ÏÆb¸ƒÒ3¹ƒ‰&yýãšQò«Ïôö¬Ý›ïˤÙx± LOn _dÃí[ö–}þ¤tIa´Z¯Ö׳RüƒkÈ‹¢Ó±‘#7ª 4Ó¢MØ\0½·c»¹ðö­Ÿ¬uO S¶Á3¹çœ|¯áßKC€I bÖÈP´ÓÀ¡ŠZÙ° ÖƒÒyÞØÊQ²AÊ©ëb GëôÔ“÷Ó,Ãи^ÊÀÂ7ð€ûº,'FHÝwã)Ÿ™ Õñ+q&#’‹ F]b•.˜ÜF.†cL~6óføtĪ B¼Š·fÊu':8ï^½åÎM«y7:¦ÄÒx ŒôNåQŒ±0ìËZ>b`Úðb†ÈºÕ\(Ö—Ûc3iLcÐY#îb½û‚ø¢ˆI)Q<Æ«¿åš†³#P]Qฮo¾ç²P­ÒIËü+Òo¤’Æ$(͆i¶ú›RÓ<(ƒv·´* ñCÊ;*X}[ÅøÒóáhþq­€ &Eë‡é°XÑË°¥ÝÛ0•G+Å2ή>üÇ”ñ%—Ȉn(3®ã/Ü¢Ó+:[Wö?Êiÿ#è× î’‰óÖù¸Ú¿X10„.%µôÈÑ¿T|×X²ôbˆîº¢¿[B>¨dI"Ü1¹v^›Þ(øW©çÖéÉ]¹gÞ @Á:V88´îžã,QƜ⧋FA¾Wgj%ÄZk(+¼‘%s(Y((#ºJÁ€–j$wÖy™ l4†"oˆBJà>l¾{b'³}£j5döÄì‚ÑQ!¯o0 QŸÀzƒa W°ŠÂoÐLм1ì­Sž›ÚÉ û+¡Ù"gÙ ’Ý ÙÈŠËcêaÓ{t%$‹Þ†êýK Ùk¢äÚÅÞæ8ÌzI¦z ݧ*N”Xâ‘#å¤@BùPޒتrßkpqr¨“ ž¹:)¤«Õdͦúbe ÛõåDgÝmHž“%(¶LÊëðÀ|!µŸèØ«ž?Ë.vO‡1+DCÊ–ÀIßè3iõMu„0p©ù'—(ê/rÑ“¥¼ŸLOi©ÉðüH?]ã„™¾/«\Å—ýé۹◉#™/`—묧v'Þ¨öbŸX°lµn>J³•†NVâõYjt ÷_Ù[4Ωe©ÿ©m;{î}and& å> _ õB ®;ó“h]fpË J‰Û6ž–![ÍœÔÍÌ_\™$Ezˆ4ÊjГž* hÀ;¤Šíþ™&a»Øiè`< Ž=64©õæeé ¯:ååÊí4q¦Ú/Œž©×v O„(ŸOé’•Ü’x,«=ŽóSp¾[";–óÜ.͘Äû”ÄÀï NA„–NS2Ïò³WVMLp<Ÿ\õœ!¬L°—lÜi„·" ¯Ï w’,§8O”@GŒÎéÏ *«í‚¥<^qF3ØûP2 u`ŠãŠc¼UÊC` °ˆ‰ËÔZP݈˴ ¤³pp>›SôÙdRKqˆsxá׋rköW |->.úŠ#…Msþ| ÚQÌ¢‚Á”ùôð%¥ÅΊ»;¦Cœá=&ºzÍojAÁ@·%‹¿wÅEEæ=›ï;kÓ`>;´ÒáÄÒÓ ¹°€ Q*þî¦+;Œ£R´,}˃Âi£¡áuDL."AÊb¢ôc Ï2ŒaʨZ;°ÈÕÇ,|ÝwûíàÅö¥ÁUà´‡­êÓç¸(ã+›Ïê á ó§çoº|®á¶Há–ÇÜÑ“rQ2Ë«G˦‡PJ©Û‹2pÅTºÒó@ß!~  ]Œ‡,Ù/I´ €½µ¥÷<ɤU¨:ó>܃aæ†aèÊð«äXöC‡-s:mnÅ;¾³TêHóAƒsW ÇÄ«5îX]~„g½¬^@+Ý•ßäº[”Á=Pl˜¹LòæÍÑOî¸J4ÀÌÁ»Yˆ=çXg3·{6ŸL‚«.dÛâ\p½³ðÜϘ lƒyXÛµqjÖ„ü„úm…ÁS*ÎòÌã¤â¨ðšbÓ›0Ý›OŸ7é=<-j^%­˜ÉZµñùø0ÙcxVzÍ¡¼¿PT—®™%­UÜ™S{äd=5¾±–çajÀWmCM0 !sÿį °\¥%ìBÁ¶û´L,½Æ©ö¿²•|¥àp5öàŸ¸·§º_Ï6ÐÆÒj‚¼3L!é$%dåe4v3fì*€ù¸´G—¯mI@ ÝéÛš=QÒ½a›ÉÜÜ•œQUÑâ{9¬ FzÓ½DKdzývL'Ñ1Þ3-;1ѲÁTÓá`‚A80sÙ¸çðtøöˆEéxÔ}Õ¤D@ˆó"¿,ï)øÞ]r%g|¢)úÅïÇLJwâ´¦c:Pµè^’ë®ÑÓ…DAúä™u’«'ÞmD”ä|ÀôJ¢L×ӉᖂQÊÇÍ“ŒëÁŠ‚úùµÙ„f>W&ìA¶ßÊŸ€šÐCÕÄh—xÄxA¶«&¾¢]$€b˜RðøáÖ¥–4_€£ë?äôó¶¤õ™ ‰CíK'eáùˆë»3ÕÖï2 KÑHözX“)ëNA²­ÀÿOÊ$ÿ£jîî%ؾõSMH³»²d3¶uZßK»VŸÏT¢5ˆ¡TN§â붛]œs7¿s<0aÞ(©\Õú˜4E²ó÷Ýí¢´‹: íiig8»N8†2vÄ)Ú÷ÿŒJ'‚%B%>žIý_º–éé| l1‰ªñ´0cÉŸäù­0>ã?&,²“£ï:/•iðÅ=]LÉ, ·š]oÛ²,6áv>x½Âª€Ë Gèx–Ò×`]p ˆÉ³Ô±à¶eÚè6žõ¶CDÛìéžAxñèe¦ü‚Dyj™âJ$ÇœÜJ*(—é˨xüâ²;Ns‘´yÓÌå¤ߥ›ÚÏk™ dºþ‡½Â $”SÃEãu;®W½RëZö—Ì#-„´&i©í«†Á™5†ã[¬É×®;25[EQ‰Ð×ÍUþØi—â½ÁÀQk–ÚüéŠH×®*äÛ´´Ô¨Ä_Ìôˆ\ÀíDIV´­çyrW¹x›Ë×SçzÓÂý~Ù^m?àö‘'ÛÅÆ“‡Å·í¯×,n©X%\ÖDË*jŠ.•ETý¨éN\VñE›/¿¹}ë%u¿g«Þ»‹»?­>h?l?hA×Å꣠–ó¦¿P~ºÊ§«útUKkÝ~}ìÓÇ«ö±í ïoлøéî¹Cè©Ûïh…1¦6|ó—~U0óÒ_nŸ©èé§/ÛØ/¶¿þ–½ú¯˜W µŒ§gi­z §Ï&࣯.ù P>⻡zÆ“¹£ê&S¸a0<ø’9Ï{T)´üé‘på¼w¿9g˜~6ÀÉ”NÙÞ¿ú«àœ^ú¢Oèw]8À什óbëËU¦¯~ý¨½ººÔ×Z_=ø’òÕ3ÓAº½ÍbUà|´V„ŸÞˆWwüuq÷ Êþañð«/üw¢*Üê×ç“Á•¨ º|ÀpÀ”O$«l¤*…\‰¾XGõë+Ñ×WŸJ_Í'OW¿þöÛGÆ”ËIïRm–ʲi" i¨ÿuqf%É‘ª˜†™U´œè™Fá‘zw_Ê’Áz«ìq2YM¯Þ ±‡7–…•›cåD(†*ÁsW /Q‡,âo\)¹0yäÂB…ÎŽØ)&êkâþ)­ë8 [–Q(35í$Aª¹EiëZÅ-†<"iˆÃ¤5Ÿ[TxcÙ%ÆÜ 4¤Œ¢¾ùw–I¡_³9L!x/8ëô0¼+ÿN »/£‘s¤–0¯)úä»°IÜŽ‡æ©zþ“!å5Àe„†Y¢¦»ª6ìj_ÚÊMC#–ÖªëŽ)0d‡›C5ußò°·wÜqs ¿¾OŽó Hä<ù¼Ò[3M5F4d!¡ÝF5–«¤³Ø£ â!§’ U‡ÝséCaè;ò×ÜQæ{þfF½%‚Äi­;OêÖ!”"ÒÖío9ãÑÛnH®µ߶ǿÌ剛P2YN¬KÛÉÌs¿€2žŽÇ+‡ƒ“qhJ:ÙëùªD¾y— x ¯ØIÙÉã’Ý?뮯/Øwu¡£R§qi)Z‡ÝΔàë+õßKWIØ°Ö»eG»À¨Ú…xçÜÀ…-æ&®Ü¦¥º±ÕÌyß“âöñÔ[Kž%o¼ÓÙ—u€;·åລO•e÷ÂØ2/¨¼ýñÆ­úJó «1&i+0_.”æ̺Íãï=yò‚Õ\Ë­vñÅ\:, Ò^ØÜä„@íòÂÆ?æ¡Vü·}Êrt3I\Òb1¤6ÁO“ynÈ‘oA˜Ó4yåÔÀ›©]”c€$¡…¸À^\ÔÒp ¤ŸS]O<âÏ)þÒc]åãI7æà1j]Ìêôãçv_©‹)qçä¯Ï´\Œ³Nèª6ë¼ÃÏÕK±ÌÞtçn³ÊǶ²Ú”ŸºVBKŠ †¤0“ÿoHñ×ⲕAF”¤šUÿBÞ!½+c¸)¼ƒïb+õ²ŠŸm÷„AéúÄÝzÜ«AæþÌbt,Wº£c­=6PB(ÚŒ9cÍ‹=è‡Rš™"gâi –w8Éz}Ùëýõ‡—Û› ›N:¨Ö´ß&sIÊ—@¤ )½{³D–¤ók wÜ®@¤;” —R®»”9¿ Ë‚€*̈ýmb·ˆà6-K它γÙò¥×åH‰ç"D Rêñ1;úq¨”,\œ¨}Š”•6åëðU’D‰ãƒÐ,ÈOY‹@‹Óy ˆSY.ÀÝó–©ÀT«ËÅG6;+‘D`Áµ¨6‹Ð‘sH@ù ‹Té%€¥žDæ9Ìf #Çàá°¯´V½  E½ bᶠ¹àN Eñ-nÀúx–yã/¹GÃCp€W>Í f6ÅÑAl+otV„´Oój[r¢·7E6eqQ&tgåe>x³–R=•ìÙP¯P'РʆT¿ÿ Øx5DWñÀJT 8¿uãÂÒùª,Õ2‚=qÉÅùª<ß$OŸ©Aíª¬Ä8TŒní|Bœæ……G]/›È¡’Ùã>*SjÀ-„‡ˆø§êhÓf ÜYøÉt!aeÅÛ€Ó7•‡ëŒ—C/þ,iaþôÈsÌœT—ŠEXI’æÕ0ZHìž•byC´D !? «–ÊÎ=œ©AD±6s5ø§'ÁUµêTŸXG924P(Á»1De!bø‘ÑÆÄ£ÁÛãá[©% · ©¯OC©[Ög‘¢ %®– kn(h¯!W~4Wcͧ„ÎuJ§oÓ}Ží–²Ÿ¥öÔ‹haÁ/ŠKx¾Ø¼ê…‘vPJ³ÓpßñfÕSjHHR©Ôk6ƒ;¹¬ÐÌp¦¾r«pa%…ás4RúbGê?ójsàPY¶)9¹^+ ÌšgãéKAq&-ç€7èÒ*»!hVQâxC¸ÈLs¸”ÆÚçˆzVŒš×wÞ„Ø uÝÜvç¤AbŽn–¥Î+K]6~iî¢dÕDk÷¤ïID¸m-ÓÖ†®Ÿze;‘|uˆ@á\°~£ç‚#÷"TOKêùÅ¥¨çDTJ”vã éÏv7ÝEæÉ¥à,¹ùÉ´ æÑ!Urõå5ö¦½+É:9‰L(¸ÏÞ|Õ‘°Ò­íÑImÚ! ð|OOEe‹ uî¿áÙM$ªfT%²WRv-û4sVû}Ãó‘sõÃ⇽½!G¬œ«Ú[8ˆë.q&e!J5QÕ.,’iÑp¦gË„tXˆJâk<“H‰ÚÁ¢íÈ>l\Ë¡Wìq¢â Ê» Ë°Œc€I‹Çó,yÝ#ÃÇEš²ý0ŠH2‹™‚Æ=¥³…“å—|ÃbCÎ1‹Á¯)¨G:à &©:ð¥¡Rñ”0!>êJ8BœTฉ™]€1Qšºrƒ5[ó Ðxñ±b®QÆáÏM^§ÍŽõzÏ¥ ì=ï5bz´>œÒãB{ÏZæ ðJLëHñ#%#8Z$˪šNT©BZG¼ÉÕøLRw\K«¸'~d­"Ó‹Õó°É¥ådŠqÓeC^T<ˆ!±4ŽÕ(®1~®É+}5 óIZ¼ñ`Ûsd‘·˜ÒÉrJ·Þ•ÕÒ¸‚Šö~Ygé +x×Õ(±’ôÆŒš§>¶_™ky\«ü¦Ê‹[Åfj:·ê²Áì)Råù£`-ÙažcåDþQæЙ{¦q~=š…#£oP¶×éEË2"Ã#fè0…Ë!cF"€]aZ2%€ þp¤ò.¥‡*„Tm£+¯÷ñ¯Hkaä28PP,YŸ£vrÅ[Ë/þ&tKyéj}Ê­‡¯^mmÜ+¾¨Æ‰l¤:[¹fê¿F-u?”d@XQ±m?¬?‚•ŒÙÀAÕR©h¼/;ú¦þ­ ¯¨n^¹USŒZL¨gaÝÐÓÏ| D¶P ­m:†² ¾P½c+±N=³À„2ñpk‰¥J˜§(®AØWÉ_ÊÈ7ðâòîÔàÉÓÕVWn·HÇSÝ­R?ÄË}w{Ã5Á¡ü1‡,?"m].R¹¢LÓV Üýã(‹Ëç;üE÷ø«K~næ—we4\DZî¬NH Mn÷%ÎÖÞ(¬”ýëS=.Kð/ ™kpW(õj€ùš°Ð¥bÒÐ¥Õª J¢×+¤˜”‚8¹‰¬h×~¤{²Ó½·¦ Rt'H[ƒug…™"¸ÞöÞ•Ñ/w¹mk»»#G’•#7¹æ¯ÈÆô²}̈)Ñ‚Žý€ÏC7K¡Q`šùû¥š¸Ý_^צ¥^8Ά4ú$‚ £ŠqHétr‹ß´Æ@8É|%NC” †vwïÆû®’$Ò¼\׸¢æU½pÂnø°ôä»mdA^ØWâŠ;xB_ª÷~“'ÝûáÉæVlê5V¾ìÐ×Ä—=x"KN+®+¡Gè-~ò1#EierV•§b#ÑR—l2Òk.Ïöµåô 2“²ú†øèÀ\t’ZeqŠÅ;’_â kØnÿLN¿@3ZŠuûÅ.éB”L;BæÎÍŽîtŠ·¿(má¢7Z“ã9=Úïj/ž§D{í0ì!Ìp^ÚLeÖæ`Ô?vŽÒ 3߯à¹9¬‘:?çⵘ>E·ÆÙÙŸµƒŒkðíßsøMoð›Î»þÇÖnF‡C‹”-w1+±PÝ'äÔíãúâ[¿ÐV¿)r@¥~ƼhÁh/;€£Kœ]>…‹'¬¾¯;àÕÄ¥ýa¹ïtÂa£ j,Òw)X‰ç£zŒøßš"opáB¤,êr\¸†²Ô­ºP¾¦òÆý{'fÖWüߪrÕͬ u^¡C™Bé55Ç™93ƒñ#Q°†ÚvEE]Kªïî7Âܹnð$Ñý2|Fü•yÛd–>¬oþH²†¿y¾SÖ¯é+bªóoóI“ªž5ƒiëåîuõ3gUqwkëåNÃ8¾&­†é±ê1ˆéŠŽãÅê¹u–Ñþ5sÐ)ºØ Í+úõ´Ã ‹H±Û¿ªR0Ž'¹‡mYŠ¼Û”¨µ³½¹×mm½xÚÑÏ-3áiË”–Ó÷¥Ú’LÃw}Û‰Y|Åí[)œºÅ o…0¨á—´ò©KU)]ï™)~gïâ¡¡Püí;« ŸB¿Ø6µ™j÷X•f¶µ¶ößç¶ü…u²HÇxJpˆµ©dŠiäÿ¾t‚Ñ„ ¡)f'<ú–R¹Î*/øì*s2篯4—C\KmNŸ/C•jŒ‹01èØ›ÓxëïW$IZ¦µ,‡ÊÚCÍšdvÊÙY’4‰_ʇš¼¤ÞP–Š¥Ò’²©PÂZJmµ*e€ÓTäÑN4Æ nß Ë!–T­¾ÑÍ£3+]‹br%+©Ï}ùÔ6åé¬UZLn·yefø5Öc"AÚýé;Zs·ût}wJq Yp¤Jµÿ«»:HîÆŸž=ÙÞìõºßo½ø~u%5ÁÓ9•%‹ H§í†]9Ö¶5Óƒµ4ýN|a­³áp@ijÙ+‡¯[XÁ‚\\YyåPz)^›\å’ˆ¬åT^9H>À#zžÌ»¡´ýœ®mV—õ¹q+×ñ¥„ 2ØI|«lÏjŠÙ] –Õút f¡l¿ë²†0VW®á\Î`y…—¢ÌgÉ~ûAR&;GÃqÒ;/”Èå7GCJ1èñ>@^zÀ«),/Âœ « wZû­wÜXïõ–Ë|uòñª4ñucŠžñt­ÅÒ•iðÑroi"ÉCêÔå¾Ê°SY²ÒDŽ"/uið ¶M²"Qmç,1V•‡Ó‰Â´™žÕ?pØ2dÏÿˆ$²I‘ðß“­M¸¬÷ã O¬°¬P²%P„Gví7Â,ܧ ë¨bu¨ÇÃ÷ºžŠÜõ¾_4ÓBñ Eƒý BdžŠ£ê—w¥¥´e^6¬D9 Râ´áPi‰_'Ó4 BÜ­Ç×ÃŽ5%@s+høv®vÈ0†¡¦€5Ò’­Žá0Ü©ÑâÅ~÷€>‰±Žè¹4Ö;)ßšƒX¸w„%qœ5¹§@:ñ©!-ÊU>‡/÷’0¥Ï²‹gì‡>¥VþMÍ©R–³F§ÿÕþòÁ·Y ­Î…€S¶¾büRóX¶«N‚)é÷J•×3•ð27ê ¯¹Ö&-‰Ôkä.ZªäQ™åNà ¦–»HâÇ°…a`ÀQžìxέ—õ¶ê†›Rs4Rµìz$O5iæMÌš „N„CuR¦ìe _¯•­_¿ âúQ")‹F-¤ÕÂu]·ÅN¶Y)ÉwlA´Å·¸" £.ÞªŒÕ¶Ó„qÙY7°p}Ö›h¨ ‰U£Ü«­ˆ}óû‘µÙ„"´ê0$@ µ.ú|Ôý­ŒM>Ó:w©È­PK¨eoš vÛ®¾Í/¢eÄ”2ý êjäa[¤½•ß6R.2OA‰Ñ2výã3‹‘z^UæõWUDõµ4›–„`å`_ÑÐfCšžG7³m|¿-ÿ[Ŭ¿´ ÙJ.Þvà}à ¾ÃÌ3k+¬MUûæ=k÷æv«ËÆ‹mÂKÃJafY4‚º íúD]jË>XdŽêîRh‰ÿê`ì>mÁ{4eıiaÖ±^™«|‘*ÆMžviâ•Ö&]¨Q¶Úº *‘¢¦ #ÊÃÚl8Tòõ¬Q;Ó…!`F­6AYD3Û¦ú¸_uHgw,9øí7(W×ãᬩ0@ú‹"-v8$¹²nÅÎH©IµÎFe1Õ^¼/jÛ…à[Öþ ÜÁÚd@1¾ãrÞMËúÓ˜%k¨¬#v¨ñ²@×/­swX¸¤ X›ÌŽøw»\k}yos×ѯÊRØ"é° LÿUclÈG˜ %ˆh©¥Ì—¥—(73×-u•µª¬ BIôWÄîâ§Zš•'ßåιñüíQZk}Ý÷ô¬lö^’Vgha÷o‹ƒ{%Ž‡gm:D¶?>^ë %§,¬í»ó­yåNv”©Ë“à”weso—ÂK6åZo*'VçË© {ÐÊûEVúÜ;.x5Ì1fm‡C‹í¤G®ûÛ#ÃÊå5$Øk7¾ QêxÏ(œEÙØ~2ae†¯%n~Ð%P#w’eNvDÀ9 ³`8@& c0ZžuìþõåÎ^ïñÊÒß‹ÖF¿Ú±¥]ýw?¢Çó"D-èö­¸·ÿpT#~ϙΕ*¡y›úž|<Öâ]˜¶½có©ßB&jãØ®…Û¸u c{òþíÌ"iaNÿ_ùé|å†ùÜ0CýŒùìú•-&h2>é}@ü+8‡àó#Èÿž^ªÉ‡à<Æe߉-Š÷U„–¹ÿ›kv¸ÕA— ˜oÄ„LõeJ§ÜÆ=óMÍRÒ붢l!Ô¥º9ϱèþ(Í#6Ì}ü••m˜:ö”÷B«>³d‚l¥yJ¯¾ $Çã–Ýäm™ØDmñOô6ºvûV§S2Ï¢{û–AwÈáà‰î‚Y1ñ‡,d?w‚óP»í–Õ½•â¨Ò]/•€xerû)«É&]¹êèä¤}úñtå~±2åzBUrÿlÕÜ•Í<ù—l¦38=èÌŽúr#UxÃÚnXÛ?‹µÅv}%õ9§’ê›DÅqïùxü^wú u±.ÜÔØÝXoÁ%a¿>±Üö‹ÁiÆþTნAÿÅý†ŽnèèŸEGÑøúБ.šoïºÁxCL7ƾ.‘¼º±ÿkéÛ¿A¡Ô«ì )ÝÒ )ßÐuŒ¾èŒjW|u µ9Á©;ÏO-Ñþݵ¬†x8j*¾[Õ¨ÑÛo;—/KGõtÆøâ…{dÜâpŒ×±ZŠÊ^ns.«™Ÿ”aEœ°åñ Rè@vl%=ÕŠ»ûxÃiÊï%‘ÃœŽHDj﬿|Ñ{ù|óÓX¾Ê%cáLÇÌÝÇvoOÈpÐ7Óñø4Ÿ—ÀÌÙ$\9ý£xyPí÷ѹj.,ò|¬˜ ®ßþG«MvÙí=BIÓâßxû ^KÚ9ÁýiØg‰!FîLÂJgíâ…Ò6¬ ÞÒÂ]îûq.ƶ»)qÛÏÙ¬ùêCÉ%BÀ78)bŸ”ÁáwÅ ý–hö?ÂVÖh°ìœ©¥ýávÎ1ù–ùÛøÎø£×^ww_üìvŒ!Õés4áièVK°Žÿ|ÊÍ{žïE“üì)»ùçoŽB—Ç+9V:EsÂæÛÝÞ¿Xφֲ:/êVQNGàó‚.WxwôÀZ\Ñ!yÙW¾Ý`P‚eÑ©åM”…wSFxpl‘Ì~“ÐwIýpp«ý² }‹â qûèÊóHƒØ_#¿Ž³ ·c·”5˜€ú ÆË´qCr®Å·¢!d³oôôƒõO̽³öudŒ#nåÎG³ì‘èdL`°zSur—³dÃÛÈ–'·!=AÜmóÌV-F—…m`™ù¥(ýNBóf•gP–#›-ÓTˆèAÂhßöþßÒ†„ø•åþhöÆp]=ðªD¹³±Ü•Ãº®- CSgL»«²F—nPòH繎cQO"þI1Ôßbx´ÆxßPo7^ ÍpÚÐŒ§?ŒçÜÓQéx¨«î,íqaËÃÚ<ê–È%iKë_Bec\§¿…YÑu'Ë›â¦ÄÛ²'®Q¢rLÓ˜¡zM SèŸYY@øšDº7$8¾ñ©ç‡œ è|L¾–˜ÍsOØ Óñ™Ö¥kÛ]u­ÑùÁl· y`Ш.ta6ò݃i Nç“¢\$¡%õÊ©æOòRú-pÜár7”jFsÞÔÅUzÄ‚+¼oßâbÃçtê ô¯TGqŠXçû.áÌáOâythÆÜ@+ª¶ˆ½}ëѽ»ÈFû8K^ÍØŠÝIò0r\SV”NSÍEÙ¢–HÈ÷BÌ‘¥"¹rÃáæ6ÏXZO³ŸÓñÁ˜Œ#µrîp{éŠàçM¹¯œNç/ZšÐoùñÊ7_|ñhEœiF:hO„‘Ûáןý}õáR2ÔÑééd¶* H¦‰•§º`îñÊÒ!ñ•®‚>åà‹Kþ¹£DŒÎþ$µ'ö ãÇ; ÷ã•ÿÜüïÞÞËÝÍ¿ît{½×/w7XÂìx'ÿöÎ|·­dÛÏÿ7ÐïÀëh;Ð`»ûôà Ï MÉmùX6¯(·”DYlS¤.)ÚÖ äiò`y’|¿µªj×HQòÜG@·$“{×°jÍSýÚºEcç7U¥–"Óȹ_%QY2-ã°°Þ7à2›bt‡ôVNH‚l¶ÞhjHÖc5¯B’PGÊtÎg,²%Ò*uö ½ÕW› RV¨œOÀ?ë<ûÍèäûwb$À¢DЧóÑù5°FÑeAv3Ÿ¢y«ÙAdª;íè„Šìõ`]”ÉšG¼YvëöõñþŽQ¾ðÖQÎÉÿDbÛ•Fb#\Ë0…àS²Ö ¿z£D5°¶Û~èCn—ž›´ÂNÑ%~`"M­áŽì‘2™4–¶™î²Ïšµ+[ZíZn R5ÙªÍ:6“pDI;‚–e5-Ò¶W€±Õf‡ÓL F¯0†íµ*S¼D\5Í*OÑBú”O_ZÔ`{[9PX”VÔr­5ÀÈXÃo‰Ã£•›Œ±Šûªêy?0Ü_·ÄU¬ •»ó€}oZq*nZuÇFHÆX–uÆùÑpʈæãaÆPñ9öE‚]C£d 6Œ®ËŠ•Øa@˜YQIl­¤ŸÀg[E?éÄÊ'ãµÖÚš¯)Cñ|@r„ÕîÜ~òbkk§Öàâr!ó%·iþÀÝÍ£D¡€œªãKëöö“‡wp11ÏêÇ;o†˜ƒ‹Dõ— E£®ŽËÕEʼá¸W縻%ñŸ rʽm‰yÏv´v¹â(vS–ý%,üš*ÊGà2^q¨£ÞŸ´s͵ªëÍý|9Ìþ\Ml‚«â½TY&'‹¸°‘ YºˆD½l/¿|¾;ÐðßL^¤õ¼»X— +M_ÍzªRf7šC.db5,>¹ÊäLÁTòå˜19<äB¸É˜ì)£ÒëŠnU÷§\[M´k:ÌÑq¥pYã8™VøLp`I¶“xÅþä4æÎâÍ*”aôE·‰[j)g®ÖÌR•yy0çî ª‡™ALÉ„4àÉ‚;#CÕ€­•‹Yb¾ý\•t3)@ÀÇï'”ᦤT £å›£*·øêŠOÉ‹±¹LΗüR]® æ0‡p Lª|ŶŽà¥†‡r»-Ñyu<Á²U¿B‚dzRxbJX_¡?-íâµ,<ŽÂ¼™@ö­ú]G?hGlãàòso^x«¼ît5ÏH[Æ~¯íካ©x&ÄÐâR]»4gD¼ŠÞ–œ.Ý-îaj×Ù‚|{ ·a¦7f|<ÉI,~úãžQ/ MÔ@~“wà ^ÿŽ‹ûX‡ŠÖÚå›4—aÞÂÉŽ“³º÷óÝ» htä× ±Å‹ÉOˆâÕ/‡ %*ýÍ:  #S™œ‘.ƒÞÕÈà6ä’ªÒýü„‡—-Ñ:NÖ¦KöÀKUœqGpË+·Ns‚"a¹ÌD­(°íä©i’äŽ|r xeåÔkÍÇçµ…~”“þ—#ZyÉÖ `µ%÷Îg~_Dêû!bºLÂxÔKulkªÆPÚ|bN¤\©&’>¼æœy%5&tÁÈû6<Žçï´^À¨OX³,i~Ðå…ój~BÂ2Â:`2¿ª‘Îl~](Dàïü×fZ’ôÀh¼¢†ð̱R ‰ÿ-IA”–-öLë aŸþËþø뮡—´ ồ ÔC0I!3~IZ£m§ÀâÅ(Q“Ò¿Ç ¯4O€ gÚU6~±Š2¼[­çÆÅ`í©*€X7±êEOÊŠL²ÂùtZÖp/?«¸ª*ÊÝE¦L¼y6Ü ºÅ¥8bôLkÖð³°]µ¦|¿¦‰4a¦.õAíFo½´ýîlD­î´õÛ‹«Ó˜Ÿl›„mås®¡çgd%ˆ:mKÃäN.Þeºø†x¤@ó'èñãw Ÿ rºt»«q…Æ%0óÞv{kóåÞÎþv £©²Hêˬ)Z¼+œM™¦‹¤ gý«Qõ£ŠâTÒsrÿ{…<Ù¯³„@É¢þÀK ’Q?ñ.)E¤C¼!Y Å8vIœø~ˆŒÁðcר[³žM ¤U; _¾÷¡ ¿rœ“b«û ÏiVK+‘ÀR†3tòû0ËÌ»65ûÔµI«Æ¼ÄÅJ'¥HÄ]·å*§(8ïέkéé°LøfÏ•:$UÅLsJH´o¶Ì¼QŽ‚ÆS×Q%Ÿ±2R/DêI[)Œ(X^‚˜º‡;¢/‹(eûGo0lèæC>i·{­Ð^„GŽ‘¢n8k¾èzË;;#ÀŸp¸´{]©]pâ9 DƒÉÑáq$ÙݨÕcÙ²,1ÆÊ^ýcl¹¸Â’³V”Ñ°©Uð=®–só­èBÍ4ï¤2;n pMg{äÏžN¸Ch×^ûö›e¯<=꟭ü°2ÊtXÏœ-+¿¦bÚi²¥¾ýæ‘ÌÔw}¥gz&Í“Ý¿Ëe¤ÄfBbÊQH¿õ%rAŠNƒ!DŽ1{¥dUV³YG‚ͺÔùŽJnVª§h˜#îxÔõ+µ¸–Õv”­$®ÆgZŸøuè¾vP`:ë¦v¶öLw¦»Z·§²ÖÝ–ôZ.ß›ï½ôuËg³F±—ÎVm'»|6û6e±ûªŒÂñKÿªÈ& 'ª¯«dNƒ)xS­ç’HßÛÝck{£ÕöÖžAÕ#abÕ.öC)ø–°­®zùöbrYÿUç€Ùî{(Þ˜:-MH¼z¤V„™;åŒ6ZÇ\í36œ׃ÞéªR#=6 fP }‘•ÁÛƒ§¼,lÈF)ÚY†.Æ—IJí7Iqò§Á¯‹ñ6 ]Ýã" vÍk ¸“MpÛ^(-2ž¯ã`ŽïGa‹ˆK+hÂôNW‹&úð$¥™6sÈE˜Úeœ_ù7Ô$þ¹Ok½TÀ“q3Š‹„±É*ò€5ồ/Ät™âE®ÂšÌOð;Ãmù yšÿÇÿátxFš‹)nŸ4ðG$ Ìkí*n4T褡YÖEÅã$ZÅpáíS¬µ’Êý?ÚÝîÓN{çù³ÿYÜ×ð_ª)M©—örû¡]þpÍÁ^ƒ“é¥8®ö9ŸªÆ†ê+ËÈSVmƵyÂŒ2+ÕÚÍî—œ0bR…Jå^æÀ€äà)c›¹nCîébäí º«‹bs݇~ªLù±Î~I¦Ê6ªï.Ÿç3{í$ô÷oü z?CVL‡õÓWS+ÛÌ°ñËuAd‹”J‘ZTg‹Äë‚°°›âZÝ2 Ñþhb®âœ0džyÉiþù|/ Í£ªW4û(z×òQdÌàRÕÊŒÞ÷DûÕÝù\Ë=‘E•1*OÅ’%dl÷½eÃû:1²µ,7N or¬Ý„sûÕ#0áœÏìÄXîÅÈáÆìB\Õ¥‘Á­v;·q”Ò@ Øä]Ðc»nín–}ÇñM³Ùùu©Øý°v‘ã¥ëƒs£9k¢ùÙª:ò§rsè êçtã3üš}†7ŽŽ G/ä{ë¨~¸I¡˜ŒS‡¯"Ÿ±]„©"tœ3}åOœBqã¿X-Çb5Ý¡Ù•q½t‹:ù_ªZýÓx4œÆêÎüH®åܨŸÎ§òi”÷þÁäÃûú0²t¿õ"$šR¨z“’Ó>œKóîBÒYÃkw7‰µb¯û¸ÉJ_æ·Xâ¶0îýx•ROéh ng–ßWk…Sw¶eüïO¤MVUµÔDŠ XýJ„,ã©?¾Xàä“÷HGP-%—$F ­¾-¹ª‚§át¢TÙ. eh?êµLê˜k'ZzÃ]Täj.Íì ½Æ+1º›ú‚Kª>43¯¢W)¹–û1O– ’µÂqÔÑË18/!Æí £Œ(!K2å²d߀¼ÅÒ®=„k o :xsëUX¹Ü#°” ú>•6÷+½Áù¯&×…¼¤T5âíÙ‹ž ¡¤Ü[GKlÄlš¡ ë¾ÝELîúÁøk•l%Ô=,” ´SäKÓá=¤Ãòõo©˜Å¿e#ÕÿøÃ"é ÏKB#3¥aNïÞ{Œéñáýïý´hœªý*¨¶Šò7’jq¡Ð‘w#©¾²êÏç[OjÒ—"±J¬úkáøUFòEÈÎöè•î;95á¹»õ—EÒj™ä,Ò{Ü^4ÈÈ»y$kÜg^¤,ý¦áÁéŠImÍÊEƒ›xã¼áµo¿ù’E^™Ç~\F]•Tp¡¨ œØz³ÝIcê°Ø#.ûQI¿š=0btÃiäšsК.6[—#ë/^—GÎÉ[jt«¸÷Õ2º–µšZP…¿ì•ÏØêÆô¸1=Ô'Œ¤ú?mã™*ï ­bCzo– »Æ?ü†S\PKøS4aÈíé ­;57”{d}'öñ]Á>|5ô¶¶"Ûèhs!º¶™,³˜ƒÚ[]´¾[ÀLRÍî†;¤fº9á3Œ_µóév­eÞwtTùö›Õ{Òîtš†1–ˆò¦÷ÀWÒ{àÙóýíÞ®Þd¯Z­q {l*’Écõ÷˜Ûµ£Ûï¸oÂ.phµ½ÍéÑÖžt·?Uÿѧýñ«9)[·ÿÞîì>åÆÌãZŽrµ6» b÷>Ð’ž“šù¢Õ ×l…[Þª­Œ¾£*n:Ô]ÎEÔ´¤1d”v: ©æ2*¾]žíΗ©Ý÷¦“Ó–è}ö`“ž²§§Œ •yRãæÛáëá¦òã;Ÿ4Î)éµ5èp!8Äø’„YõýZkªŸÝéœð·ŒÞ.î|m}yÓ•jùK«ò‹˜6¸“oÝkÜœqÙÚŒ"»éjÓõæŒYÙáé™fôÏ6ÎŽŽµÂíBžåØúîþe­õŒ»0O¨{w Dv1 Œ¦Piö…0 ÄÙ Ä¡º‹‰-úPóKuùÎì¬p­Ð©7é¿ÂÅßÊ‹DÒ‡C°k1ª½î"Nuáºz™-Œþ€Àý8wrËI>”ËHÕ³œ¬‘ÉÖß~Ä{*áÎòð€šý±9q” hiA…#Hö–ÑæeŠ¿®±v~q6øõÌ€w«*0n ¶jœNÏ`†ò o›Ö ›v3‡÷á/2ØŒèM‹3tYÖWżíâ&Í…y…Áå]ëfÒ§–Ù_9\ 7/‡ê{¨„r »¸+qÅnãéé:·šÝo<ÙÛía'‹ù ¦´+{»;›ú²¸‰Æ\Ñ ˆï$]²¦èU;û‹ëvIW‘VΪ[¨˜Ã­CÔ{ÔŸ™ é>+îâÅXþ€Öq´ÿ ?Aù¤¦êÚ_)GÜ\Ñ}…FÝÅ_29œŒ°V'=¦Ý>®²ñëLäÖ‹5¬IFÑŒyvÿ¾pš¶®â!aã>E;ÆÔ¡ÈÏïÒ,RÒA…IPðŠûE8I‚/"Þ&4kÅ+›cŸP̦|,+p_A@1_Àp¤W‘}ƒéTž =uÊUžÁ ì)óáöNñfp¶¹Û®iVûkìùwð¹X„ B¤ø¦#G…–%ÛŸƒvÃ'è¢{:k(Ûv§r„®) n²¶Tê´?憨ë¸ÀB­åh>í§žÎu˜¶e [4.§·wv@Àˆ…Ö×v‰n—é6,>k!Ž8D€”ŒþâØý²ehá ú´LóCŒ^%HûÊk¨}ÎÿƒEÚEvÐòøÄ[Ê,};Q¾Û Ås:ÝÉÙ¯Vþ¨íÐtðãá`dw\Ë~oup~MÖZígûxÿì¦È}t)\µÇó£ÙdÌ€½Éñ97IÈÚex?ÔÁžÄ5üg³—¾FÓ¼™ŒÞ8Bœ8RF8ÎÈ·‰AÔpêõìrWÓ‡±"Vv½¬qLôS|$xÓj‹ÚÁÊ¡T€ˆ9JgH® +ŸBÖCY}©_¨–`U2Pj¦ÁuN­Vûü|pzvn»MZýW}œ9cB|C@hügƒþkv 2#~»¯~&}”`°Q×Κ±3>âC˜xS5Ï$à¾é«Y 1g¡ßédŒ ›IêŠÍì<Å$S¶Ðù 8üêälÎë·yu8™C$ñK<¡³;h:ëY»Ík BXÞjÀ‡ØÑ&x2$À@÷$®qm¡‰ŒgÄí±tÖkÌ`°ClLÆšüÁP† Z§ÞœÖP¨Û|è™ÙtˆEAŒž-³ñ¡‚›v•÷ pÏ©fä!Îvj7£If8‘;Oé¼À£’YïæΑâ±ÇB}‘æ ®  ý+Ü"cŠl®s±€™Ìh£©3lP^…–ß2À©åL˜ÞR©JëAz;™¾®íšø]··ÃžˆñzôÜL®ÖiÏÙYLªºÇì‚S8­¦9h»9*ä¹$­˜Õég”8–1 – Œü,š˜€6ô&ò4Ô5Çi4]Ezapæи°dº ËÆ5"¹i,#=²W;KDœ÷òï|¹,Á.„\Pg ·Å>¨3Z ÙØJ ¬~æ õeÎóÆ“)P9nÈ¡¯=Å÷èŸ@Èïð|.§Æ°ÿjÚ?Íàß+A6ŒY ÜÊpí7ã+ƒØÄßè0Ä­íúJÂÙ†¹”5 !ѨylâÔVSãG“æW@^º™Ž…2È›ÁtÝ-W@ c…w²mþ ó3¡WZ3;*´ú.r®¦ž’§Ä.ÜpD×Äî®æ2þ {5XDsÀÈ×ÙÁZk~¶~>YGÀ!Er€•A]ÕŒ|B¸ Ù–®n•3Ï¡qi—§®aAÂÁdÎOÃ…P–uˆ!À7xg†¯%mˆ½Y)µî2ö”¤³ØpËCNA|Úõ×(}èV ÕThˆ¤æIcVƒ>9‘”õ)63Šø¸U0®:t2n_å¥ãý b¨iÅ°DQV€ ´"a‚î—Äâ H¢¸h~/àv yªñRí¸¡ê%ÛÎJƢ˄´VSºhU³‰‘ŒiVàA¤ÛèÒ·®Œé9µw^¢§÷×€Æ+K,ÐÎý% ¢ÒÐ×°b0¿ý|ÛÀÏ»~Ø:3õRƒÜ»»áÿýô—*Ño·»ë÷~¼×üñýêÇ[—é40~Ó$̃6èºÆU—ÂÿÄÕ|}ò7ý’¸x}©Š‹—ÔÂ8M¦š¿¢¤ÿ™•ÈÇÒâ Åù™{д… bJôOÍkü¹”¿Ü|«/øÛo›;ÛÖþ^ëÞÏwøAR{©÷ã½»\D6Q] ÊjÃ^ñ|jRA{O]¨&­—mÄsçÝRi}(…ªÝn£*9R£ Ô€Û9Í5XƒÛY!CWÜü/Z;öêª)°¨:œÓ' 9æî[EF–ψóC}1QÀ±’°[¨Ö¹ J€ Lù 4“‡_^Áó3Nw–ñÖ0­)¶Ö9¥?&cn¤ø‹ êAÇŒB¤tm6è †Ä\É]ç(ò&âQ€Ÿ$1°˜pǘ™FÖóerƒ½¶[_y–™_ Ð/ϱq‰½yr4Ãà$ùoÝ>ÖP™gMå¶JÉ(É À™ÄP…»’{FÒ˜ð(tgÓ^ŽÞ)5ÙÐb¢´Ž­¦T —LO¾”aáG®Ñ}foÇ•¡?å‘ÀfƒGƒ+êéæÃÀí5©afƒÉÜùÁ·Õd•¹•ÁÎ)ãÉ]¢è"»RæJ Wº¬‚PÑK+ûðHÕO “ÓÓáƒsˆWùx|^%ó–2Ì¿÷ë-`j:Ó­¿¾Ô æžp½­¬0˜š­%¹ª`s‚_.s¦4¹ºØZîÞïBe_š)aë­½h"Bç–Cœj붦‰Š3EP®b›ÇÇÃÃ85ÅÔ¸ {Ó<ýûáÑ#xÌÐ=ò±vçSøÈ@ö2÷¹Â´þ‚¾i»+N•#XË!½ÿ~ôà¶Ä ž^œ™5®ÌÕ ³¶ÞÌGÐŽ[õÔÞò¾GfMÃfc9Äãöy_AØo¿©¨”Íǧ|¤ñ¸ÎT,p›"wŠVÕ=<÷@K~½,RµÜ£°@‡JQ†A…K(Q»ó …ny…‘$Ù®â·"É‚©e'sƒWW«¿®dÇÅÐ[Ñ=À½ÕêI CC²Ö_ ¤ Ö›sš^ÀYÁà¿>š¨5@<¼Âw)úŽÅÿ82•’œZw·:'ý3¦$2°ÖºE»R£5ÎKb¡ç¾ô.*\óhvËr-ÀŒ·)ó2ì3ÅlŽbJ¨ Æv>À/Œ¸P&¶áß½VX«!ªa}püŸ…Å2ÐýV ƒ+¹,˜”œž{üÝëì[xXŽt‹b°ï,µ•ÑSù¤0qI}œ³ŠÆyªå¯ÁY˜§€|õ¨ê©~A‹0î0›Ä|fX!\ÁÐa¢(/¥‚õm…ðïxÂ\ø§Ôá’U‚(»™®+Ö* á¥ú0BÃ> ¹®ðS© Q¢ÒC° +¾¾½üzq£A ?—‘Wç@¿ErZ{%ú­ýÉ) £ôˆá—„Ò~=é÷g‘ä·¬a‘WßNÿF… Þ¥&<ýöÐôŨäÈv+%E®6«à¯±X—¤s OÎ\²KO¢&€Îm‰µTíÈ¿ó¸÷oO·*ȈÁk­KD•6èúPæb¦ mËÂêÕäò cÀìÊô“ÆÀILÞIéA=óeI%AQÇ¢=Fÿ-†[íÇÂj³ÙÖÏa‹‰ªA@‹»rÕÙèÌ-#Ǻ£îŠ#V‘®iÀ÷z¼Ò–zªè+'@”•éÈq¹ãù…ÐÈcvHuédB{E¢¥òV<¦ ÏâTUcÄ]0 –Á;3äÑ]RñW‘ögÉhÊÇQìÝK‚Ö9JÎOLc2Ô g¶¢å°—,Bc[àS!Xœe‰‘.G@ 5œ©tT7&KªdÄ_)ø,t<ƒ?iíVæ×’põ€…8§…©ƒ´Áa5²èhƒµ¢•(#4þ窬m6û‚µ“Ï!’ò¤6õ@Kþ˜[ ØÛUn¿¥@3}>$2oÙ‹šù|x‘䣲ä˺'O.]fõd ¨3­È¢Ó ®áìÔÐ^(‘"Û €xa=ÚôÝÃvo§S"d;",|ŽÁ; ª&A q‚–)æV×Nm[ùq˜ h¶mùi&øs©&.´Ï⬥ °eªe¦·PçéJÓ†±ÒÁŽÞùÅÓ ½)½s\tƒ³÷ésàÄ»$5NY„=3ôɱ^Dò[KOäVΉ´Ô´üì9®•2 •—‡n¤êM \¨žDEkH³àÄ0/<î} ‡ƒG ê5mzÛJaÄ\ä®Eá8‘蹌î"çÑš`zV= ·¨‘_pÔì*o$1ÊÀ¬Õ…H[àx|€ïH¾‰<Ç-ù¾@¶n'Ì< ‚«>³5¹«-2T/ qcõubô—ùMÌ/XO•) ràÿä¶ ðÒä-K²®IøØ •X¯½Ø{JÞŠqœp&¾É¡{1žðÏTÿÄ’¹ëõ»#kgh¡[L\”àr_3Ke*0SIÜÞêV4n͘µ\r5ZsPËçeÅ3·q åéˆÃÛJB sTl‡Øþª’á©f×w¼UZMbYNòÜ[ÛÍPt”Ñv9É"¢*\0±îÑ/û˜hIáÀYMVC•z<[ØÂtÚ Š<ˆpýs¨¾Šû‹qæ k‹#ˆŒµiB¾ "¬ôñv{k­õÛö¾EºÏ{û†Õ:¢ˆoºBIrP†®/z‚#^žnžÂî·ugO©!PíÉÓÝ ;é‘ÍÒhñ™¬uª VoïV>_þ»½úKÍ’·ì«Òªð°'À´Ê-SÍN°™ÜE¨ÌzÏÒõ †iª D$¯‘Ï„B½‰º3Œ¨a~ƒáöàNÌã`ÆüôÍ·„2ѹâ(mX_#=FŠŸ/¸¹æªÞ¹’7$ˆ’&(J°h È]X3îî÷>,%„ýædï·Ô ±Æk^äbd²'&Îö·‹HòÓáxþî1~t·C8. ëå(&¯!LÓTí `™zCHŽÓ$šiŨŒ±Ï“Aä8á`8B†¯¨©B|"F—yá7‰o’k¶iÒÔ+$2güH€¦e •KÛbwî¿3`0fxÛKJ oqÿ!+¦\§–Ì‹r2ô+GÕH 2•yðîÁ¿ü`ÿÛ›íÞú†M7GÃM{ OG÷•!›ã‰y…/AgnyÐҿŤ¬Ñ]B6i\x¬G¾ÛiÉŠõ’]„—á»Âü ¹5bÞéA¯>tó.¨÷[ƒÙëóÉJ¿e*Ìj#÷¬ Û_½däûæ¨~Œ¯D*’N6{-ú_ì¸É ­ X—€P•®—á>QÝ!±·ù…>°¥(¶T_T0)èµ±,l 5Ôr3 TNÕ½:ljôJ›ü„„`ó3lɤ, |UŒ×x ˜Ü8dÌñHäÕf¡—8ÝÖþ'†ÝI‚ÚA–×Q«„Íw,Pžðy9`J;ˆL :ô½ÃB”=“ªÀÎ!÷R]ƒ!Tô_¨Ò.4¹(ÝÈz*:*<Ú]o³;T·/Rõ•ÜLå‹if€ÓLŽL§pYõ =w{Ç÷v;hÔ‘‹ENÒ ÿ$ª¨Ÿ›ÆÛ¿?Ølwøþ`“_;üõ JÙÛ¾3?¬ÜŽF‹Wž”g½Ö/0÷¡¸ðõ()É—?ƒyˆö µHÊê9ª3ÝfÃmíxW[~Æž»lºË®ŸÝizöYã³ÅÏ>Ö¸½lÜnã³O5®=«5tXC‡54[~öYXïeãækhÞ››à°| e8¬ðlÚÛrøÚø±2Ìl½ùÞ.ƒC~ÆÍÏÚÞjë]òlm½õsëüÞëµî·=ßÛ}ñ´]Å,}ûï½Îó½í¼·øËê7*‚@ÂU?~:y[ýh?ìü´úéc"™ÕÏzê'ݵÝöZ÷iõóÀÈ™’Y>? ‰gòzàF-S9ý¦<ÎÊXÃá’X¦Wt% ¬Â9IÅÀ=ð^‡´–‚ˆMU+1¿´. 7M>=«˜! "˲àH/¢ÔBÊ‘Ûöq,"Z*ŠÖ˜ÒjÂ,l°T\`ï'§‰RÜ]5·ÍVFKuËuptÇ´H4.–ŽúShR‚%³ênè}jËp¦‡ »Ý}SµbœøvS«>ô‡|ɹb P\0lzz®]ÅŒOŠ0§sö­M˜¼¹ïÁ¿˜;>q‘"¯• $x³fε궃9®2l»”wÐ?u}ú¸U> 4¥E‡QżåÊë &ež§ÍQdGl4¾ | …eöãºOõƒ±H“úyÚÔj½0ÈÐðÛ´8ZèDžFÍ=´?šÑwEù±x»üú§2NÚtnÆN,ò'céÿŠ¡[¡gìi—êu¥v:h*Ê(õÆ㺅 Æh‘|®VK˜I!"¯×ƒ d5¥:6-×,Ý \M-m¯ìª¹ÜÚ”¸ »qR?N–r¤X5ª+ýÃÌTdÝ}½æÄêÎá`/¢ Z|x X<…ô-EpŸ’:hyx†àÔ˜ÑhÔ6»VT[®ãs˜¬´Ï„$ܨ¦-Ôˆ„¯>Uj˜búüeWŠ_‰pS`iµ`I[%®Ëšmn»£óýÈT ý¸ŸŒí›Ç…™/ç]yÄ0½üÓ”dßsä-©C4lïM<›Zen-(û¿-”R³_³Ó¼«r*Õ¢Írâø[î|š~: Hl{Pì¨ 0¼ ´U$¦€C¹ÄÐ9‰ZÁrz2 zmå(§,L‹5žLZ¼·¢ñH Ï^Æ»ÕÑ ïÃÜ#ØÅù‹v_‘Mü‹=yEw-T þpUƒ%dྙsGƒ"Š¤‚Œÿ ççBø£4éàtÃ4QËÆTc¬@¤3ÖbÈu/’§Ý9V…ÌcÝ€x)}ÊDø‹šQ¯ýbýÞ?îëÇ÷úQka¿¸WkW¿ùQïý¤ Ï8NJš¡ ª³#+à\åTíÎz­cF[Ñ#FðÔà "1ótU†“ðqyÑ·¬(¬m‰õZ&’0Q·ã·Šp Aã©ŒãXáò²X.'Xª&øÖ¢†3d¢ ®`­Zfƒòð×Ýä7›næAWK!9ÂÜŸ§é2ÿ¬Nð¼_øu–=¨W=¿²¦aS…;2¸sÉb粓?IŒcz”œ‘é:}ÔˆjËy/:Gãù"bBS.‚ÔV6Ë^ñ ÑÙ`R“a­®U `dLèO5R+”á¶Ðj ‚œ*û#ˆK%TP qØ) Ý­`ãR’Š¾kñ'ër"9t=ä¹½ÀŸjtM¹Lż~Æ"PdܢɌô!€’FÆ*§xÁ,è^„¶;@,:ñ£zyüjü½ñÌX’\áPà(ŸïXª>ÆK.Å惞‰ Ú,h V’.:æFˆ˜HàK€ÅŸE_lô6÷g%DÆ×QŠ,¹ˆÔÈ ºÝAñžÏ)z€1öpðQðnCÄû”ñ˜ÿžÔ*îW½û ©¤{YšRbOa{$æ˜B&Ý•[R.}ÔœoÐ@]=Aÿò½LÔ9ŒGM«?ÒM«¬«®‡M7d¸l¼š¼Ùô¤×6i1:ëug'çõ»ä/³×Aᔯ¨}–Ãä~Ä1³Pµ‘ÍD “Lb"n"~ø‰`Í'M*&"µQÐgküø±AþÚµ`ÇwÚkuF­ñëÎîúOÕ™ù¬¶>û~5ÅDë‹ú(ôÜZët×k ŸÕöÄg¿T—Ž®–8þ”i¸•¶-äI€BtÃ* í+6ŽÜŒ•õŸ1GW–…(}0òrí°º”àÑàs˜›R„ä“a®` `ÄÝNs*ÿù ©ï@ †JSǯdEç„€Ù­¡×ƒ —ÅkE›ö+ê\Q= ¡?B¢&»°t¢ùw¼ò«ÍèÝlšvÞ’éÔ°ùÒÆ£úgv§&–2¯€³¯:øb®¶ÚE=Xcómé9ç }{Ø…n[Hƒ,ZTò‚ë|Aý÷v´5 ¯êÇ {3D0uªPŒ\µ ¦“…,¯ A²¬Tcç!L¨$|+Vc…FÚ÷6…Cè Äȧ•gjàY²uµyé:Ê&nÀ‡] ‡c®î ßµ/ùUƒdéË«-2•™óK„òìo6#¿j3º´Žîñ¨ez´"55YzîÂó,á\étä>&OCPoØTE£„³Ñ÷él#ï?\-ß~³âó^~YqpMhÍÊ$6Ñ[É}VÓ¸,‘QPð¼µõc)Ê|,‡¥LAe­fµþ(N·,Ï-íîAxñ׆ÝÝBc 1¡p—½Ã”ÅLtg™MÅ,€žÚXÞ6–> ¢Ç*@Ñ®¥$t`Í Ñò7–œ€%±¦ñ=Ñ—ŽÜ «Z­BæÅòH…CZ~ðØ—ž(—P„Í[Ø&\²œ=ª© ý8Ä)ù¬ôQiÀ±š’·3«h°‘ÿ3 KO¯fcËó©X1ts%ùWåC®ˆò†DðՒǽcN…èC~žºv["ý±% 4¬ºTð¼êÊ7¶prÕÔÓÎ ¢½7Jãî¤$BÞ U.?욉8Ž:ïQk¾m|[«Ø8$ýb¶Ñ›Ûíx[ÏvA3 h?7Ä ‹Ã:@ªvÇ?4›d¬Z—¨] Ê5¾ô» Éɯi»•îË«^q¯S‰-ñÐ Ò£®¿)+ogë›ÜÀíe¹tŠ(þqúÎj•,M‘ËÒ·b¬~ý*¬¾övÍ£¨¢Ö˜f7­+_q(é`)éÎ’ôgÕ#[:¬^jò”PÆå#E!‡ÓV»g¤Zã±”ÀÕâ¸Á¨¾‚‡í‘W”qõÒ™QØââSž½#òñµ7ö§C‹­¬“‰àã¾í.¢EFBxù)Qv/O¡—݇l Ïžïo÷ª>¤&5à’ ›B ‘ý‘”#Ý2FÆ’uq¯ûàºØÝT‘b-?¾Kd°ª<Ô Í꣤ªX®Fuu¹žÐÈÔ˜Ÿ!ÓҦÈ#‹¬6sõÙSÊk ‘ýC‡+áŒmõÏÑ«ëòãƬ­$^:nk ¦Õgÿ6SÃ̓“­êW¨²àE)«#lõzO[\•Œbm'ûÿþÏÿ­Ž´Òþ~v³‹R`ÀPBÔÐ냇ã7êý+–R¥lϳ Rã%èð†%ñš" Ä\Žœx²MÖ¨úXŒÑë\ü„~ ꨭÞýÖ¥QrGõjU°ô õT$’€ žXyÅ)ñpò2ÅÄ %Wt8˜B¿ÒñÁú ž‘&+d*´ëóÉc«zYu3تZÓâA/•_â ~muŠ¾Ük]ÐTÎKŒI|´@l¬*®mï7m~ì±áRŠ•yh}±äG;ݧ]ÜCZÓ£ñÝÉšpb²{F›­Û§V[#o!Àcß½¦p›~çºÍØŸ\ðÜݱƒ9?™{ùûŒnBZ­ ÙÅã<¨r6T‹! )±Ce„’úlI¥ iæ‰h5hv&ëV7©¹ ö’žrÕ*ƒ+WIÔ¸4Oc½K,¯0ÝÜGV+”o%E†ŒF±WvVçoQež4&èN{ÀÑÎC©,@!WÚ/ÌRèãV‹Ï ~ö"esQ“.¬××ÁÛÞÚT0Py¿t#32^Ç`rñ×hx2q*ŸÇK51ÿH"šŒÝ+Rze†,±›G41üðŒÛdì>rO´< )öÃZh«j~kgD¦-OÕ¾¹²–NØÓC3—µýöÎu)®#Éã߉àŽ=³;hF4tº9V1\-Îß/“&š/®~ŽªÀff@Gu–^³ï‡çEÊxc—&#vÛœÀðŽÇ@쬒ºæb}Ò‘_eI®’9÷°Ám§£ÿòoÛÐÍždxÊYkÍ}ƒ]bfùäÉ·ìw}G‚¥WƒÅ(°šÂêÆäó¨¯Qà⼉gÉQ¬tºÅ2©E”²ÆœTB¥GÌP¦øh¢OÉL¬T6ÏòqÃAÖ:œäj B'— ë/ž?Ç ûzûoÛ êí/1œòìô/ük_¯O ˆê¶¯¯”@éâVµ(¸^Õp=®Š¨Ï%’Ÿ‡ŸöجÀwÚø ›Óß—«½,­š8¤uÚHW캧ͪވíÒ}H £ÁîGì˜Ü äx‰JRLrÊ_wÞÜ/ØVÑ#—89³úÓ ?<1”KýsoÖ×7¶þk»¡­Tn‡W¹h÷Cç ~?-’®ÛéxC0ݺrÈoͧÕBýyC—p½>Ž&Œ EëÓµ|~3 %Æ®-š¢o[”©n0 @eY®sŒößöÜÛM\³wBÐÚØYc¶Ðt çÈáÐ+"EAAÞP•r°P6%*Êçœj›¥ÎqœKÚa$Núg$œixv육 ÏH™^ßõ"»£%œÄ¿ÄÜÑ‘îE0nàÊ´Œ ãË“ 1V®_ýbñV‘j‰›ÿD´¤ŽÖ>b´XCri>~ÕXA?­F‡ú<Ç©ý%eA2~粯ürćªkÁppzDJgd‚©z)Í2«§EŽHWâX$ø«E¶Ò+ÜNµ1±6Ò Ð[ «Js“FÇY'n„psÚJ™–ž‘xZ°èzQOBʳ0%ÔÖ”¦Jêi ùKr#V× Ä"šÇogÂÄ÷î»dKus8•_‚áâ̹Â+®Cߌâ¨³Í yÆ^ÆÇ‚áhmAëÇ7›ÑcÛ§ÅþXˆE¨Ëù\¥›žRmŠg"ƒæ}Ÿ¾È–~äÊWÆy «&bb_÷Ú ÷,Úw]8訑ÿÅi‰q;¿bŸË‹ƒh˜’œGØ‚Ž`J$¯ÓâûeÊd¯~æ;íÜUd_ v>ÝÃ)P²É›‡\ç~Ó}"ð‹ÛwÿÿÉ«£õE&nUŽÄZ7åÝÁ%)fáÞ6Ms^qÏ!ÊÝî£/†QÞÝ[Ý{Õ° e†ŸûXæÓŒHÐ= "‘6ÉJ3.o—Ôpøè¶u:Ÿ¾+}¹½õ¼* L3“ø1{ÿÆy+¹A¨}ü+vÜÔ'EJÊÊmÙŒí‡cd²/sõÁ·Äôµ¾$›ìF]ÄXã†Kj=]e[i>Ï#ƒŠ¬²\¡uçE¯Ó£ëuzæ‚Ýc(¥›„»Z{YÐJ¹èì"4Ýhí^…§m§ØXë;Ÿñ—6ÖÖ‹W§¶ýa±a ƒOÛ™rõÊ2¢•Ò´–;´|„›uÜ'Û_Ñ]<*~êsï)ÉÜë,v–ï‘£ò(6Œ/”M»4íªiWW¾ÎÃÎbÖئÆ]ë×êÍÂ0þ~îÊ.ô4Œœw4ÂF½4b[†0ù[|yê–;—:*Þ¯p³Ó;3Wÿëz,_±ðC«^a‘S3-“6péÁ ÍXÊ%Ú¥/úì®[7 ìXá›W=*lö~&Š÷KZé«Þ}tE7ùúY/1I¡õØܱú]hN/-Ù_ðûiî¼8¿ÒåóÙ;ïu–:ÝîT­—æ,®ÌÎì^Ú_ÝÝ,ºZÎ¥'(íO?‡¯Îøa1·69&PïÁÊbÒ”*¾*ƒD&=ZÙ€ö¥û9V·×YaàÕã3ýÉÊšÞîdÙá+¿ëou®Zz˜êTq«ßí}M§Ê6öáÕÇàV§‰s¹,B)Ÿx¬²žª'äVç‹qT[ßê|=øÔóµ°¹¶Õ}øøñRÃQð:Á-%ñjžËB]ÙžµÁy–Û Ô& {]u½5ˆÛ¼Çä¥yöbg3ÔZÀ”ÀØ…žZ(mlúÖDI@3]`xÍk0ef‡`’vÃ3˜û³Ô.L¦¿P_M”Lì¦þš=à45Ã’ª#Ç¡DGhäÁe‹æLÞ>rݼ½ø ìUi3ðc ¬ò^Â/l¾Tà3æ8Ëm÷†£û ñ™gNÛ¢„\dü*}8ÁloKÿ|{w¯Ø‘Ô «c*ÌÏ](™–Ò"šN5¼k_^Y¢3>4|œ–È|6–S(åc@ö 6ª4Ùš¡áÑÛÂð„Ô>2s}¥Æè4¼Òî/‡¯%õ’OL>óÜ_<7&´+_ «j r¿Q ¯FÜ#£Ý¬L¡ÀXx`•vc$o6°Š¼ô®èœäéƒRÇS_­nxUHŽAzÇIŽßŒ> ¨@g­UtbHƒ¡TÜ\ùŽ"‰¶_SûßêÀà§m]ŠsĦò NáÔLÜa˜fˬŽß³]àòXÕš¯´¹!â3òSîJ‡u·KìƒÝ# Å(ÊÚ™ec2G)_|I’#ó‡†\GlG?¿Ù&ÑW5‰@Ãä‚£i;üÞT J ýÝxûËHšW¹å¾j¾Gßæô7 ¢ÍÊr3€ux FÐqðjËJrÃ’7»Xº² 0¢M†Þì û(õpÇ»?†wo|iä (#1wN·Á±ô3¬½Oʸ¢ì„ßI±ì¼y!yzdÀZç–uDœ$¬¾Ý?äŠ*¬cö¢9»)]ƒY¬ÝûŠ¨þ¾½!¹rNBbIOÏ&GVDµëýd(دƒ`Š¯¿;þ9ÈÄÈÓCctC hò&ã»Ûb¿ú‹{FÜô¿PWt¼oY8%ÈrD©¢û>~ÙOm‚b8:Ú ¶†™a¬™#\%V1Ì!cÈÅ?I€ Pk,ö‹*…î†Ì£(ͱV¢Yö ê±DÄ` F‚cQq¬H"3,?D0 uŸåõI8é×JM¶Þ©QŽ²ðÜíZ€™…Ð@\¨çRìÌv™ÓÛ¿7üN¡ÁåN„$Bö„²>QìyøfUªõßb 9a£ÓƒL?>cŸ 7Cë5me‰wÉ_XGç Ÿ°8¢¼Ï°8`ôta9´£ ӧ譢$¨Ä Ž¦µº™¸6©ÖO#UKÒ?q·<èjþldʺ0ÿñ-tzJ”Fømܹó~|¡Ò >Ÿ®_-Òs ©@Ÿ§ÛxŽÒhoët£m®ÂÑ„¼Å7uîË{ý7â³õÜX‹©zž¹ÈTÚÆq›‚*ý¨‰¯ÂÐò$‹²3.œ!lggÊ»æ³Ù™½LfC=NÜÎM÷šeLFÑÙ[ F¡cÀ `è~»A¤^l^ B¨WRŒÉtà7(=‰4q5ë#8†’“&Ü—B P»;»´7‡Ç7uF”² Š$Þ5÷¯ãdN&çï‡QÒð×ZH€Õv?œæô4æçá#SùyºmÉH-W±Ò;ödÂÈ–ÉŠÎÎlþ"5Ù 2^€í-óFáèl¨t£B}kŠm3ÕÛ Ë°IWgÄ3}Εò0ŽònX:W§8HÕ0™+˜Þ5<&~Ý4¾\ѺÍ(YuƒSÿë¹ùºEbb%Fï{ƒ·Üð’­¥f¯7“Ä‹¿¯6Š~ÎØW¹†köd9üåë4ÛC2®¸Ð—iÜ–ÏÔ§éã]7Úmä-Ÿ® ¾Ï<Ù;Iõæ2«ü§ÎY>ŒôÔÒºŸ@3æ‘!¦èbL$mò·ã¬P¾&6<æýL¶—…ÅÌ»Ñh×Ê|iöïàSh†ªúÞüø—×»5ÒÄ¡gn†ŠV7XÆ .àÓ˜ÿ0[?c&-“‘ìGŽÕ¨¯M瓱@ÙæW6M”ðEð@Jú‘öÚ‚pU0¢‹3àx †õ‡#¼Nª¦7”#„îóÎd„3ëÚwt7í4¦Vž9¤í"‹9ƒÐXf”Žòy+¶¨}l½ÇFqïÆÁÙK>2~Ô@{~ÉГf)7`Dù”„GºY·øæ¯øã¿ý§±õ?Ï3¯4Ñ`ûqÓ[šfzKÓLo),|˜ÞÒ§OïΗÿ¾üöÔe0G^Ud£è1ÞÅHS-8™b<ôVÈ=LÒšÁ{%ÇŠ`} Òó5°Åšý×.IZ‘[€jxú{mßG‚RëíiwµÇíÛa.‘Ú›O_÷Ç– ܳ4’¤ñô,¤‚¸Sâ?®–ÕR £%•ýkòÂ×ß|Uva®=À¥«ŸóA¨4ß©Jè!¥Ðæà " c>Ú äå™æ2 Á¢DTLgp¿Z Ce@!&Xˆ—É4)@Ž•Á ÚEH§¬ª}JeƒòdF¡+É9„î£LvÌGgF R%Ъ¢`õ-и}Q [ +„­Â¼”5D§ª£²CšcÖGƒ3™ÚJ•Y¦²ðª°|¯§|ÕCÒc‘% ÏC@8jÇ@'Ãþ‡ó )AäÑ”±™·€+^+%i«ëÛ¹¡T02³&™Žø0ß65re695RZ¬+eRöÊÊîUÄï~{Yַ׊i»¿µ\‡ˆøÑrHGTÊNÁ ã1 ) ð`]È7(û¬–T)£vÍ î„4wﻊJE'Â8³ðžOÞRTZx†2Šï„cUêHQÿ–ŠMÔX5Ñ ÒµIÄcÒ¶Î]l@tÓFØ•/?L{H;T|@v¥¯+þ{0éSÉ›£¨¡ƒ$¯üô¹RzÌ=8 8„OiBy'$í ˆÄkPÒªïXÛ, ÃÍ•w]Û&|TmMq¬Š3Å•©qŒ\zjV ôC\È·“SÏ.„*¨·lËìÂ÷­Fåíô99§¸VãÄK±ÌX1Ÿ®åT3EQÏj½=ýrI?`#œkƲk†^æJoÝ)%b_^þbÙ>VSj>ÙIòƒáz1W mye …ÊW¢ ’G¦ôÈ/ÎÊ: },¥(fNä)@uÛx2æÍãÁ#Ÿè‘:;/ȸtôŽ‘ÐÙáă¢ÎPO_ÅèÌ`bAÅ×Î1† kÏvh4ÛõíôšN¿f1¬bMå45ƒ<_àÅÙU¾ç’„¨H€F kžÌ—¥D=¿×4÷–~Ñ°õñì8羸|Å/E¹³3=ü}³3„û¾˜\Œ&Ê€³ŒE"ÿgv†TäµDÊž>)ºËú¿ò÷apå×yUH_°y*™WU=)–WúûÝå•u÷—ºLJ«¬’µ¤ü9pšbÕ,n”1[KÒÉqÁ×np×™X‡t"'0ùØEà…ï+ÝãD«Äf$Ñb[5 Ú¥yPrý˜¿Ÿ lÓ8<áÐ$(I¸L o¨ (;–>Tjƒÿ‰Ö™’KûòåówǤ4=J)Üv_é¡$ÌV .?ö²£]“…/f4µ²ºzo£xù‡jÑMéò‘CºA秡rÃ" ]vªM™?Æž²¹MɶÇhª»Õ27Ó&ç/Á—3Ô{P¶ãØØi•ÄtÁZŽ+•×51•ÖÖ×æléb±g3)/€ðÆ`¸P¶Mˆ0|ëÄö…Á´;˜hšÈû•Aj`WÇÊ•e.û Žpt| Ř³Æ8ÿ‚¥„í4Aù1C^œÅµT.“‰FlðîÃÆ-(2EÆ*ô`€5s¡\I?‘Δ©þ |DI~j@ïçÍj)ˆ/!ä_þTê(˜ÝÌà +[Fàž+aæ¥ö—þíú³Õçßo;›ß|Û8¹/ØO—ã–<¹<3_ÑÂühˆ{eŒÌ›vÄQ}m¬y weÅu÷¡$ Ëá×mè︨ c?ÆkW°Ä4Ò….wEIëN£x[âðŠÛÆ$Á7¿Š9žÄkp¼àï ¶S3û“6÷¯ª·…îTÆ.O#ù0~{"EY€ûÔÔÁ>ša§åLœy0uì>’]{bðÀ:p­I‡HãIŸG"&Å ðIcqÔ"Qrc=ö^ײüÀÔ3ÚŒžÜá6¡‰Ç®õÎp¤s̤ÄÕÀ¸7v~8 ÒŒ-‹!)ò¨ˆŠÎîiž!ËÓaAÐ:E!ˆ]­MBËÜP)?Áu­’'/¥^ï ŽÊ˜‹{†3^ÃwâøsrĪm§a&V#Ír…~ª´,#ò¶‘ì탮շg³ïgÎÜñ»>ÁV 07³–Dsº–_¯f÷¿V×´…ü#S2¥.‰ÐJ3 ýcÆ©§©D MÅ…m¾ðex¶_ÃaÄá=tò.U fgç0{Z†é*Ñ&nÜP'Æcô‹…¹¬<k1ál–À½Uàè„ÉÀØ)¸ #XJ‘rÏÃß,™<ü­Bã¹%h3B¸]å&­m·´´´|8è.JG·‹ßåR|“AßåbÓ>6_Õv Á7ÊЗë/yð‹ÝJ“lþÚÔ"Ð"ð± w§tçREv"N:»ìÔ|L§øþй¾×ÝTß„Íl–á9<3gPŒçÌ ž9Ï1øÿÓïÀìâ™tŠ¹MÿþÿÿPK-!†¯CŸ•l[Content_Types].xmlPK-!µU0#õL Î_rels/.relsPK-!J©¦aúGôxl/_rels/workbook.xml.relsPK-!OÔ„æÉ. xl/workbook.xmlPK-!ü9/ñÇ $ xl/styles.xmlPK-!Õ8;=ð]#@xl/worksheets/_rels/sheet2.xml.relsPK-!Iõ]óJñqxl/worksheets/sheet2.xmlPK-!È{Ö©üŠš[xl/theme/theme1.xmlPK-!ÀÆÚñ Çbxl/worksheets/sheet1.xmlPK-!%­š@ÊZdîexl/sharedStrings.xmlPK-!­·k a‚`0xl/drawings/vmlDrawing1.vmlPK-!¢ç.Naú2docProps/core.xmlPK-!†þºÄb’5xl/comments1.xmlPK-!bN(ë•17docProps/app.xmlPK-!P3J <H"'Ú9xl/printerSettings/printerSettings1.binPKó[?scap-security-guide-0.1.31/JBossEAP5/docs/JBossEAP_5.x_SCAP_Naming_Conventions.txt000066400000000000000000000045741301675746700273640ustar00rootroot00000000000000XCCDF Files ------------------------ Groups: xccdf_com.redhat.eap5.scap_group_ grpName is one of 4 values: - rhbpGroup - cccGroup - nistGroup - disaGroup Rules: xccdf_com.redhat.eap5.scap_rule_ G - Group ID (1 = RHBP, 2 = CCC, 3 = DISA, 4 = NIST) R - Rule # from Spreadsheet (001, 002, ..., 999) Example: 1001 = RHBP Rule #1 OCIL Files ------------------------ Questionnaires: ocil:com.redhat.eap5.scap:questionnaire: G - Group ID (1 = RHBP, 2 = CCC, 3 = DISA, 4 = NIST) R - Rule # from Spreadsheet (001, 002, ..., 999) C - Check # (01, 02, .., 99) There will only be one OCIL Questionnaire per Rule, since each can have multiple Test Actions Test Actions: ocil:eap:testaction: G - Group ID (1 = RHBP, 2 = CCC, 3 = DISA, 4 = NIST) R - Rule # from Spreadsheet (001, 002, ..., 999) C - Check # (01, 02, .., 99) T - Test # (01, 02, .., 99) Example: 10010101 = RHBP Rule #1 Check #1 Test #1 Questions: ocil:com.redhat.eap5.scap:question: G - Group ID (1 = RHBP, 2 = CCC, 3 = DISA, 4 = NIST) R - Rule # from Spreadsheet (001, 002, ..., 999) C - Check # (01, 02, .., 99) T - Test # (01, 02, .., 99) Questions Match their Test Action since a Test Action can only have one Question Choice: ocil:com.redhat.eap5.scap:choice: G - Group ID (1 = RHBP, 2 = CCC, 3 = DISA, 4 = NIST) R - Rule # from Spreadsheet (001, 002, ..., 999) C - Check # (01, 02, .., 99) T - Test # (01, 02, .., 99) A - Choice # (01, 02, .., 99) Example: 10010101 = RHBP Rule #1 Check #1 Test #1 Choice #1 OVAL Files ------------------------ Definitions: oval:com.redhat.eap5.scap:def: G - Group ID (1 = RHBP, 2 = CCC, 3 = DISA, 4 = NIST) R - Rule # from Spreadsheet (001, 002, ..., 999) C - Check # (01, 02, .., 99) Tests: oval:com.redhat.eap5.scap:tst: G - Group ID (1 = RHBP, 2 = CCC, 3 = DISA, 4 = NIST) R - Rule # from Spreadsheet (001, 002, ..., 999) C - Check # (01, 02, .., 99) T - Test # (01, 02, .., 99) Objects: oval:com.redhat.eap5.scap:obj: G - Group ID (1 = RHBP, 2 = CCC, 3 = DISA, 4 = NIST) R - Rule # from Spreadsheet (001, 002, ..., 999) C - Check # (01, 02, .., 99) T - Test # (01, 02, .., 99) States: oval:com.redhat.eap5.scap:ste: G - Group ID (1 = RHBP, 2 = CCC, 3 = DISA, 4 = NIST) R - Rule # from Spreadsheet (001, 002, ..., 999) C - Check # (01, 02, .., 99) T - Test # (01, 02, .., 99)scap-security-guide-0.1.31/JBossEAP5/docs/Running_SCAP_Content.txt000066400000000000000000000020071301675746700245450ustar00rootroot00000000000000Using the steps below to run the JBoss EAP 5.x SCAP Content on a Red Hat Enterprise Linux 5.x system. Using XCCDFExec -------------------------- Requirements - Java 6 JDK must be installed Install OVAL Interpreter - Install OVALDI Libs RPM - http://sourceforge.net/projects/ovaldi/files/ovaldi/5.10.1%20Build%201/ovaldi-libs-5.10.1.1.el5.i386.rpm/download - Install OVALDI RPM - http://sourceforge.net/projects/ovaldi/files/ovaldi/5.10.1%20Build%201/ovaldi-5.10.1.1.el5.i386.rpm/download Install XCCDFExec - Download and Extract 1.1.4 Built 19 - http://sourceforge.net/projects/xccdfexec/files/1.1.4_build_19/xccdf_interpreter-bin-1.1.4_build_19.zip/download Configuration - Set xccdf_interpreter.properties - Note: These may be different depending on your installation, "yum -ql ovaldi" will locate your installed files. - Set: oval.dir=/usr/sbin - Set: oval.bin=ovaldi Run - From your XCCDF Directory, Run: - java -jar xccdfexec_v1.2.jar -C -c scap-security-guide-0.1.31/JBossEAP5/docs/jboss_logo.png000066400000000000000000000166241301675746700227440ustar00rootroot00000000000000‰PNG  IHDR×…È;mIsRGB®ÎégAMA± üa pHYsttÞfxtEXtSoftwareGreenshot ™Xn IDATx^í]›G’ÝswknwïnW^Z#³ò+@8ὄwBX!¼Þh„ðï„Â;á‘`¦Ç÷xoãê%ÊQOwuUduU›éŒï«Ob:+3ëU¼ÊÌÈȈ߀FÀ~ãI­ºR€F€4¹´h”¾Ý¶•öìÚIÓ¦L¢Ñ#†RvV–k½ˆ ¹\ë­ Å¹‰‹À7•]_Yé“ê*̨5Ö÷“'Œ£½»wQyy9RII‰µn\¿FC>îGùùù®€§ÉÅŒ°ëåè\wÆÛ­©&#Ó•¬+iŒÀÅÎÓ¢ysÄSÖ¯¥ùsfÓŠ/—ÐôÏ>%oÿÞ=ôMŠ;ÖkM®8$È–þÊ»:e‘_†9³fÐÛ?6 k-j˜QT\\lŒfe4 o/WZÖäŠSr`9]¸ò’u%¿"0yü؆uF®Ï&O ~½ºÓw‡6êßÛ#Pš\qL. Aµ¸‡À’…óéÒÅ F®Ý;wÐé“'ÄßòóòhØ w>jš\qN.l[hqLaШ3öba)üéÑC1-Ät±Â ‹Ñ Æ7D“Ë r{wo·±¾às”OŒc$ñ=÷/×÷_ÜPœD­VÁ•Ë¾¤Å æ‰õ•”ššÂ6qìhA27D‰\5Y„ÃÈ\“ž˜Ö,/Lñ鯼Çz0±—8bËŒp5¾ Výº £ ±Ìý‚öëMË—.æy·Ä–\Pˆ’­»LrÊLŽ±ÞV#–ä’ýá˜Ñ±@¶êûU±¡,{6ØË©ªRO¨Ú(F´…u þëÖ`Ö²2£­‚ÑVqQ‘£¶ª««éþ½{ÂzXjìu¹-–äBGß³¯Ûz4 †zÙþ#n÷Í“úâ\x°Ü~#lq•£XõOm±À×뉔ukhüè‘Ô½S{jÕìýFWǶ­hÖô©täð¡ˆ7JÓRSéøÑ#´vÕ š8n4uiß6¤=´ß³KG±ÆY³r¹°È¨oÐÂMéÐýb:“y×…mk꧓hCÊz:ûýòûý¶¸yY ,¹ÊO~o¬^d+b&Áâ…\…s—ò°5ÞÕÌ‹qæã`2Ùý{ä°!táü9%ýº|ñ¢Pp»ºÃýþQËæ´hþ\züóO–íâc¶@§mµiñ}¹x!åæä(=£[…MÉUq¤QÀ Xù‘§&Íx•x!Wþ´¹,rY%“xôð ê×DZòI¥]`x)`ÕJRSŸÐˆ!#nK¶Ùºù¿iã×)ÂR,þÜ\Â~”SRßBoþ&ú9¬MÉ¥’¾4Äuç_-ãÚºäÂ:6ýåwXäÂz×L0M‚Ò¸¥€˜¾]ºðƒi[W.]¤Žm[»ÖV`ŸçΞÕH_2ÒÓM§´n<çÒE „ >ZB®Êk·X/ÝÊŒ\qZ-q´íÄš\ ’•sÌðY­»›†?8°o'ŠŽiÔµ«W½Ž¬ÌLψ% ³uÓFÑfii©£é­ ñî^âÂrùGLd½x+åÈQÌEœèä‚ÑÓa««ìàQ*˜³„2^oÁÂ7íþNÕ?? 朱PWQ&Õ²0€PR`ŒP­Cµ|ûÖ-…uqëæž·Õ¹]aeŒ†„+ãY/ߊ\¾çߌFßµáÅÈÅ…TÊÀi·êö½çËË󇵔©*´Uù¡û Ó6¬mÜz'C;wl£oÝ4ÌÛwéæë´kÇvqfŠSÖ_Ý:†Z8Íî…!fǶ- mݸvUünKœ¶p@2B.x¨(‚iYïïäÊé1ˆ`ÂLæ|>“¥_ÁÂf§¤ø=صG¾ ì1MŸ2™UŒ%KÌg•Åhe%q9ýæ”Ù¾u‹e[°jÚÕ"GCBÈ•Õª[ÄäÊx«U4ú&W€Ÿ#LõÈÌ)eÙ’E¶J¥š:y¢%.øºô1«.®5‡í²xnÜ"6¸Ã]ó «¡)ð;N [¹(áù¬ÚÁo¾ZçHwTo !WɆm“+ž“*$ ¹0ÝÎ|·-ÕúŸz4ôîÖÙVù`í×ÛNpœ£È*eÆŽ!ÖZv$ ×·Ÿ=b÷ Xœ.F*ìÑ!F<‰é&rÁŒùŽÉ•7fJ<=_H_¼ WÚŸÿFù“fÙ\3E°TÄÇPýp!”¯G玖Cü® N„YÝø¦oãX½b9=r˜RŸ„÷“„Wz¤mÂc†Ÿí[6 ÷)/r¹›’«¾ªš°W¥ª‰èÛ rqœÈ—R“™M9ݲñMû¿R½qÞVÊo® P G‘q,ƒSN¥L÷ÎhÕò/CFšœìl%‹&§ML•2í‚ñ¼Ñ–°Ž»ªóšXåÇNSvûÞ¶WáÂðfa€äB?°6QñŒG®i(ˆ•BÁÃ+ð4ç(',†_¯_Ç*Ë©/° HvâØÑF]¾nìYµkÕ“ö`¦¦¯å‘¬ø«Í”aø †Å¡‰êÊÝ9½N9J6í`}éíŽÅÇ ¹ðœ8tÊäOž%ðí[Vñp>‰+Ü b¹ŽÃñ³c,ª„2+)c ¸í$Øf§Z“/-• SDålKʯlÅ©sÆšb¦v´ˆ›7~šáîs2j©J6ïd)b"‘ ØbJÉ!XV«®âEܧgXr©NDdY1à1/x—6˜u/§~YæüÙï)2Fvb\½b™8¦R—]YxrDãð(‹\Ñ×¥›¹#Ž¹J¶ðHÊQxYFuÍ 7ŸN}C†ïâ“‘‘ÎFûîÛ,…]·z•iØÆhãAç0%í”<ðwÔÎø‹#Ü©°×קGWV¿íÚÆT×kIr‰Ã›Œ`2¹ý?±Ä¬hÙ:V=œ¶"%²Áøž{ƒÕìyA¬üçdx0ŽÒÀTn§€øýðÁ¶ÕAùŸ<~,Nãp"6©¹Þ$}8yâ¸m[(bÃô¾iÃ×â0¥ª m‚¤^K q$8 5 •`߈SJ§#brÛç ¤¯ð'Ž×®âç•æzDÜþñ–#DŒ mÄA,Cá‘Á©`a©UÎaÎKIrÕ—°±?ÌÑ«p”ƒ«Ð\'f'äBÖ•=/¬q‘ÃjDÀÚ$0\X8Å1£C›–¶J3ö•Ë—^çá.Î>ÌîœQ{TVm=|ðÀ– XKr /8¾ã¥$ ¹‚•Õ20"`Žq~ {CRäEå„5êÈü ‹ˆraï—Ê W¨pÑJe/¬Ü¿g«¤œµŒeç”Á~™ & ˆÊ©Ïª ü 9ÂñfA;?œ3ÿsÚà”I(rÁ ‚;ê œï™×)«Eg‚1@å>ávÔkˆi89ÕzÜ*plûöì¶UP8ÛZm˜bªÆUrÎèÆ™Êa‹ÀÉ̬ŸÜ·Õkî¡K|¬¼”„"WùÑSÊ$qªÜÅk6Ä ¹dBøìq‰OuXØx§|á Ä=n‚6¦LOÜîêåË–:úÕÚ5ì~Û=ÂÆazN`ìàL a w.Ì-Â%¹`]ãN ’ ÷¥ýéª-(ŒrU^¾&Þ÷­›7\SR+%†C,Ö7XoÙ);~Ç”&{xÅ:êÂû~ʤ ¬:PÕ^`?0=„W|àq}¬ýàOhç)ë™ñ„K>ÇäªÍÉ¥òg¨lï!*ÿîU?ŽÎ®wéö=ž^ùSŸ&GËlÖÑó¶ì>ظœúå(|$eŽ¸$ Ð_©=xÀ3UéÂJc#Yå”E0R ¡üüü“uÜD.¬Ê)‘ ‡÷J6n'†4S X× ç/óôÈI½ážÝ¥¿gJŸñZs‚e2ÈçiEýCÆRñꯩ궷$Ý|]Wlˆ)¹nÓJ'–HyïÅ·ÄÈH™¹Q¥°îD¸l-+bJ.¤X„Xò^±—‚ŒûÚaÑ„S±“~äön&€Û]®i"3r ïß=ïH©ÍˆP¼~“òBü ¸f9!–¼IjG>r*w^ß÷ÄŒ\ˆ$‰Rß›n„Fƒa„+µù«Á|¡!¸}Ñåš&1!Ü¡TòdqIˆuWrŒt•ÜYm{(‘›ÛO].qˆ ¹jK•rXÃq¤lÿwž´Ì(NÄŸ›KË—.qr«Ò=8öƒ ùà )q½ÚÖ@FЂY ,û‰-ú.ia]i™ø½âü%¥ç•…áaT~ì´l§£ûÞrá!UHÃ-‹ÍlŽ8É×ÅéÂ};qRîÛ£›ˆýçµd·ïw#B\Üꫪ]ëâ^7d¦±™54ý•wM‹a{õ H«)?rBܔє˜ §’9ʪZÊc'øú©Ö«R¾t—}‚îà>öêÚ9ªäÊ;ÕPºø—kåMœÑ°Ÿ?íi†7#N<«ìÀ‘ä!¦O* Ë-›ÝÉ>­'ÒqësRÎIÔ@råççòZee6Ž†‹çˆt‹+X˜/1’X‰¹ÌÂfcʈø’iþ›‘¢2¤ÄDPUl¢cšNjÒ3E¹Úì\Š¹`Īº÷€*¾ÿ*¯ßj”ª}Ä© œ'Ä»„ Ó_¯¦ÀÁ˜ÄdäB>/'Škw¾Èv’Õ¦»'m7X ÇeU‘äBÆÀPÔóÜÅ2qþ+»ùÒçB»võŠù&ë˜\¸/xC bè#…m öY­ºRõßµ‡ÿÈÉ”jdhem™f׫i!œºƒ“Âûž{£ÑÚÍÌûñù£!1!tíˆâäwä³$wR·Ê=øb«ˆ$‚¤ )ëÖ4iCÊú†ªe¶nÚبú% ç‹¿&­3kßjäªÍõ?þáņ ä=Ùû‹¤È&¦zo¶#“$’ÀßÓ_k&œ¸sûÒ€3—\¾—Þ 1‚/ŒHfk®ª[wD*)´‡¥†øDQ–hyŽ°hÉjáÆ&úüz Êýx$ù‡ŽSy=ŽËÆ„\èmæÜUr„ÌΰO,€© Qœ”EÖM‘äB,w)ÈYÂôìÒ±!ê“ÇÅßÔ@ b¿#ñ,TØó‘DÁ‘ ,òÅeÌ"SG…ð¬¹G5Ô]yåºøî Ì?Kü½tç~Q¿á£…©¤”:¦´æ²ÃÚÌ Ô¾g_!—ôÐÆ8mGCbf- ~8<0Öœ£þP’HRÁÊý6‘™yÊp¾Ë‰Hra #XÃúÒ´kÕ‚îݽRe¡LrÏkÜ(ž!•„#F/¹Ç~2I=ׯ²æ‚¾øžyJ$´'?ÎòÃ8-Ç›~±ÃE ÛѸ!—|X€S1æï™ï¶¥ôü[ìeäôJ…‹VQ FŒ ¾Èr*äÁ`Èpš=sùÒÅ4çó™ó;²Øì×›>Ÿ1ÜR`ÞìY‚€HYÊLï`ª4—Ë{á̌߀q°`ÔÂþÞCfóNT´|=™}ý­ ûa(‡÷‡œÏ¨S8+Áôåà†e&°Râw`ÓQ¬A^˜E‚ÅÒo÷‰²H$(¥Û÷ˆikæûíŒÑÕ™ƒ5gY.îÈ¥úNËÃKºÁ›€92Y1š×0d`tÃÈVZªƒ®:Õ¯ïKZrXás&Ýu" ¬hÑ”ÓF"qŒZó¾ÐÙ:£‰»j[IM.€…¹¹c—(Ã]‘¢¢-“'Œäºzùr´›Öí) ôäVp›Êé~CÒl:`3ïrì…E±  Ÿµ·å¸}cÄhr@/¼ Ó ñ8Ìk\~*¯þêñÐ4Y4¹Â¼ZXaqÂÙ$œu‚׸€ š\*hé²4¹ÀÒE5*hr© ¥ËjÐäRKÕ¨  É¥‚–.«P@@“K,]T# ‚€&— Zº¬F@M.°tQ€ š\*hé²4¹ÀÒE5*hr© ¥ËjÐäRKÕ¨ ðÿQî–Ýdôk»IEND®B`‚scap-security-guide-0.1.31/JBossEAP5/eap5-cpe-dictionary.xml000066400000000000000000000041101301675746700234150ustar00rootroot00000000000000 JBoss Enterprise Application Platform 5.0.0 oval:com.redhat.eap5.scap:def:599601 JBoss Enterprise Application Platform 5.1.0 oval:com.redhat.eap5.scap:def:599901 JBoss Enterprise Application Platform 5.1.1 oval:com.redhat.eap5.scap:def:599701 JBoss Enterprise Application Platform 5.1.2 oval:com.redhat.eap5.scap:def:599801 JBoss Enterprise Application Platform 5.0.1 oval:com.redhat.eap5.scap:def:600001 scap-security-guide-0.1.31/JBossEAP5/eap5-cpe-oval.xml000066400000000000000000000164751301675746700222320ustar00rootroot00000000000000 5.4 2010-07-08T11:19:35.419-04:00 JBoss Enterprise Application Platform 5.1.0 EAP Version should be 5.1.0 JBoss Enterprise Application Platform 5.1.0 JBoss Enterprise Application Platform 5.1.2 EAP Version should be 5.1.2 JBoss Enterprise Application Platform 5.1.2 JBoss Enterprise Application Platform 5.1.1 EAP Version should be 5.1.1 JBoss Enterprise Application Platform 5.1.1 JBoss Enterprise Application Platform 5.0.0 EAP Version should be 5.0.0 JBoss Enterprise Application Platform 5.0.0 JBoss Enterprise Application Platform 5.0.1 EAP Version should be 5.0.1 JBoss Enterprise Application Platform 5.0.1 JBOSS_HOME boot.log Release ID: JBoss \[EAP\] ([0-9\.]{3,5}) 1 5.1.0 5.1.2 5.1.1 5.0.0 5.0.1 production /server/ /log scap-security-guide-0.1.31/JBossEAP5/eap5-ocil.xml000066400000000000000000005234131301675746700214450ustar00rootroot00000000000000 Timothy Falls Red Hat, Inc. tfalls@redhat.com Bryan Saunders Red Hat, Inc. bsaunder@redhat.com Kenneth Peeples Red Hat, Inc. kpeeples@redhat.com James Lopez Red Hat, Inc. jalopez@redhat.com 2.0 2012-04-08T12:00:00 JBOSS Enterprise Application Platform 5.x This content was developed by Red Hat, Inc. for use by JBoss EAP5 Administrators and is released under the Public Domain License. JBoss Enterprise Application Platform should be a vendor supported version Evaluated JBoss installation must be a vendor supported version of JBoss Enterprise Application Platform 5. Red Hat typically offers full and production support for the first 7 years following a release. Extended support options can be negotiated with the vendor directly through a separate subscription. Organizations using JBoss EAP must use a vendor supported version with an active support contract. ocil:com.redhat.eap5.scap:testaction:20000101 Ensure Java Runtime Environment in use is a supported version Evaluated JBoss installation must use a vendor supported Java virtual machine - i.e., one that has not reached end-of-life. Migration strategies should be developed when end-of-life is impending. ocil:com.redhat.eap5.scap:testaction:20020101 ocil:com.redhat.eap5.scap:testaction:20020102 Ensure the operating system in use is the correct version Evaluated JBoss installation must reside on one of the following operating systems: Red Hat Enterprise Linux 6 x86, Red Hat Enterprise Linux 6 x86-64, Red Hat Enterprise Linux 5 x86, Red Hat Enterprise Linux 5 x86-64, Red Hat Enterprise Linux 4 x86, Red Hat Enterprise Linux 4 x86-64, Solaris 10 SPARC 64, Solaris 10 x86-64, Solaris 10 x86, Solaris 9 SPARC (64-bit), Solaris 9 SPARC (32-bit), Solaris 9 x86, Microsoft Windows Server 2008 x86-64, Microsoft Windows Server 2008 x86, Microsoft Windows Server 2003 x86-64, Microsoft Windows Server 2003 x86 ocil:com.redhat.eap5.scap:testaction:20030101 Ensure all configurations are made to the appropriate server profile Production environments should utilize the production server profile. Development and test environments should choose the profile that best fits their needs. ocil:com.redhat.eap5.scap:testaction:20050101 Production applications should not implement the default SRPVerifierStore interface for the Secure Remote Password (SRP) protocol The SRP protocol is a public key exchange protocol similar to Diffie-Hellman. The default implementation of the SRPVerifierStore interface is not recommended for a production security environment because it requires all password hash information to be available as a file of serialized objects. ocil:com.redhat.eap5.scap:testaction:11010101 Declare an EJB authorization policy for deployed applications When configuring your application specific security policy, you must declare one (or more) of the following authorization modules in the security domain <policy-module> element: org.JBoss.security.authorization.modules.DelegatingAuthorizationModule, org.JBoss.security.authorization.modules.JACCAuthorizationModule. A security domain does not explicitly require an authorization policy. If an authorization policy is not specified, the default jboss-web-policy and jboss-ejb-policy authorization configured in jboss-as/server/$PROFILE/deploy/security/security-policies-jboss-beans.xml is used. If you do choose to specify an authorization policy, or create a custom deployment descriptor file with a valid authorization policy, these settings override the default settings in security-policies-jboss-beans.xml. ocil:com.redhat.eap5.scap:testaction:20390101 Ensure appropriate permissions have been granted to JDBC driver The security manager policy file may require permissions to be set for database drivers. The JBoss administrator can assign permissions to the database drivers that are needed by deployed applications. It is recommended that the most restrictive permissions are added. With some installations, permissions must be granted to database drivers that are not available to deployed applications; such as java.net.SocketPermission. ocil:com.redhat.eap5.scap:testaction:20420101 Ensure appropriate DefaultDS is enabled Create a default data store file for the desired database. Templates are located in JBOSS_HOME/docs/examples/jca. The DefaultDS must not be a HSQLDB. ocil:com.redhat.eap5.scap:testaction:20440101 Deployed applications must not write data to DefaultDS Deployed applications (other than JBoss default applications) must not write information to the database defined by the DefaultDS data source. These applications must use a database specific to the application. ocil:com.redhat.eap5.scap:testaction:21570101 Ensure the appropriate JMS persistence configuration file is in use The [database]-persistence-service.xml file contains the persistence service definition for Java Messaging Service, for the database specified by the [database] in the filename. The database must not be HSQLDB. ocil:com.redhat.eap5.scap:testaction:20470101 Ensure Oracle Database persistence plugin is set correctly When using the Oracle Database as the DefaultDS, the database persistence plugin definition must be updated in JBOSS_HOME/server/[PROFILE]/deploy/ejb2-timer-service.xml. ocil:com.redhat.eap5.scap:testaction:20500101 Ensure IBM JRE 1.6 is configured correctly When IBM JRE 1.6 is configured as the Java Runtime Environment, the following configuration changes must be made to ensure compatibility between JBoss EAP and IBM JRE. IBM JRE 1.6 uses a default policy provider which does not work correctly with the JBoss Enterprise Application Platform security policy. The IBM JRE must be reconfigured to use the standard policy provider. ocil:com.redhat.eap5.scap:testaction:20650101 Configured security domains are recommended to secure production applications SecurityDomain is an extension of the AuthenticationManager, RealmMapping, and SubjectSecurityManager interfaces. A java.security.KeyStore, and the Java Secure Socket Extension (JSSE) com.sun.net.ssl.KeyManagerFactory and com.sun.net.ssl.TrustManagerFactory interfaces are included in the class. ocil:com.redhat.eap5.scap:testaction:11000101 Define <security-role> elements Enable authorization and define <security-role> elements to control access to deployed applications. ocil:com.redhat.eap5.scap:testaction:10920101 Remove, rename, or comment out the default user accounts from production servers Remove, rename, or comment out the default user accounts defined in .properties files and login-config.xml. ocil:com.redhat.eap5.scap:testaction:30010101 Remove, rename, or comment out the default roles from production servers Remove, rename, or comment out the default role definitions in the default <application-policy> elements. ocil:com.redhat.eap5.scap:testaction:30020101 Security constraint elements should exist for all URLs in production environment The content to be secured is declared using one or more <web-resource-collection> elements. Each <web-resource-collection> element contains an optional series of <url-pattern> elements followed by an optional series of <http-method> elements. The <url-pattern> element value specifies a URL pattern against which a request URL must match for the request to correspond to an attempt to access secured content. The <http-method> element value specifies a type of HTTP request to allow. ocil:com.redhat.eap5.scap:testaction:10930101 Harden Tomcat Connectors: limit maxPostSize The Tomcat container is commonly used to broker connections for JBoss. Several steps to harden the defined connectors can be taken quickly and easily. maxPostSize is the maximum size (in bytes) that the FORM URL parser can handle. Environments that pass large amounts of data through forms (such as file uploads), may need to increase this setting. ocil:com.redhat.eap5.scap:testaction:40110101 Harden Tomcat Connectors: limit maxSavePostSize The Tomcat container is commonly used to broker connections for JBoss. Several steps to harden the defined connectors can be taken quickly and easily. maxSavePostSize is the maximum size (in bytes) that is buffered during CLIENT-CERT and FORM authentication. The default setting of 4096 (4 KB) is sufficient for most environments. ocil:com.redhat.eap5.scap:testaction:40120101 Harden Tomcat Connectors: set server header tags The Tomcat container is commonly used to broker connections for JBoss. Several steps to harden the defined connectors can be taken quickly and easily. The server attribute controls the Server Header tag sent with each HTTP response. The default setting causes the server to return Apache-Coyote/1.1 with each HTTP response. ocil:com.redhat.eap5.scap:testaction:40130101 Harden Tomcat Connectors: ciphers attribute The Tomcat container is commonly used to broker connections for JBoss. Several steps to harden the defined connectors can be taken quickly and easily. The ciphers attribute controls the what ciphers are used to negotiate secure connections. The default setting causes the server to use the ciphers allowed by the running Java Virtual Machine. ocil:com.redhat.eap5.scap:testaction:40140101 Harden Tomcat Connectors: limit connectionTimeout The Tomcat container is commonly used to broker connections for JBoss. Several steps to harden the defined connectors can be taken quickly and easily. connectionTimeout is the time (in milliseconds) that the container will wait for URI content after receiving a connection. The default setting is 60000. ocil:com.redhat.eap5.scap:testaction:40150101 Ensure proper permissions are configured for interactions with JBoss JMX Kernel MBean Java permissions for MBeans should be carefully restricted to enforce the least privilege principle. ocil:com.redhat.eap5.scap:testaction:20510101 Ensure proper permissions are configured for deployed applications: java.io.FilePermission Deployed applications must not be granted file permissions (except to those that are dedicated to the application only) in order to maintain a certified configuration. ocil:com.redhat.eap5.scap:testaction:20520101 Ensure proper permissions are configured for deployed applications: java.net.NetPermission Deployed applications must not be granted network permissions. ocil:com.redhat.eap5.scap:testaction:20530101 Ensure proper permissions are configured for deployed applications: java.lang.RuntimePermission Deployed applications must not be granted runtime permissions. ocil:com.redhat.eap5.scap:testaction:20540101 Ensure proper permissions are configured for deployed applications: java.net.SocketPermission Deployed applications must not be granted any socket permissions. ocil:com.redhat.eap5.scap:testaction:20550101 Ensure proper permissions are configured for deployed applications: java.security.AllPermission Deployed applications must not be granted all permissions. ocil:com.redhat.eap5.scap:testaction:20560101 Ensure default system Java Authentication and Authorization Service configuration is in use for JBoss Seam For JBoss Seam, the simplified Java Authentication and Authorization Service configuration provided by the Seam Security API must not be used. The default system JAAS configuration should be used instead. Using the default system JAAS configuration ensures user identification and authentication are performed by the JBoss Enterprise Application Platform. JBoss Seam provides additional interfaces for implementing other security functions such as authorization (for example, entity bean permissions). This functionality is controlled by JBoss Seam, and is therefore outside the scope of the evaluated product. ocil:com.redhat.eap5.scap:testaction:20280101 Validate keystore and keystorePasswordURL properties are defined and loaded by Java Security Manager Ensure valid keystore and keystorePasswordURL properties exist and are loaded by Java Security Manager. ocil:com.redhat.eap5.scap:testaction:20600101 Validate a keystore file for JBoss exists and is accessible to JBoss Validate JBOSS_HOME/server/[PROFILE]/cc.keystore exists or JAVA_HOME/jre/lib/security/cacerts exists. NOTE: The file names and locations may be different. ocil:com.redhat.eap5.scap:testaction:20590101 Validate a password file for the Java keystore exists and is accessible to JBoss Validate a password file for the keystore defined in the properties file exists and is accessible to JBoss. ocil:com.redhat.eap5.scap:testaction:21600101 Validate JBoss keystore is password protected Validate the keystore loaded by the Java Security Manager is password protected. Password protecting the Java keystore used by JBoss issued to protect the integrity of the keystore. It does not prevent listing the content, but it does prevent modification of the keystore. Private keys within the keystore are still protected by their own passwords to prevent disclosure. ocil:com.redhat.eap5.scap:testaction:21580101 Ensure JBoss alias is a trusted certificate The jboss alias must be a trustedCertEntry with the JBoss Java keystore. This allows code signed by with the default JBoss certificate to run when using a restrictive policy file. ocil:com.redhat.eap5.scap:testaction:20610101 Ensure applications deployed by JBoss present valid DoD certificates where applicable JBoss applications implementing encryption should present a valid DoD issued X.509 certificate for purposes of identifying the server. ocil:com.redhat.eap5.scap:testaction:40050101 Ensure X.509 keystore utilized by JBoss for certificate trusts contains DoD approved Certificate Authorities JBoss applications implementing encryption should utilize the DoD Public Key Infrastructure. ocil:com.redhat.eap5.scap:testaction:40060101 Ensure deployed applications requiring authentication utilizes DoD PKI Class 3 or Class 4 certificate and hardware security token or NSA-certified product JBoss applications implementing authentication should utilize the DoD Public Key Infrastructure. The DoD Public Key Infrastructure is designed to use hardware tokens such as the Common Access Card in conjunction with issued X.509 certificates. These tokens are typically protected with a PIN that unlocks access to the private certificate stored on the token. ocil:com.redhat.eap5.scap:testaction:40070101 Enable Federal Information and Processing Systems 140-2 (FIPS) compliant cryptographic modules for use by JBoss Java environment While JBoss itself has no need to load FIPS compliant modules, the underlying technologies such as Java and the Apache Tomcat webcontainer do. Utilizing only FIPS compliant modules decreases compatibility with applications that are not FIPS enabled. ocil:com.redhat.eap5.scap:testaction:40080101 Eliminate clear-text passwords: data sources Eliminate clear-text passwords in data source configuration files. The class org.jboss.resource.security.SecureIdentityLoginModule can be used to both encrypt database passwords and to provide a decrypted version of the password when the data source configuration is required by the server. The SecureIdentityLoginModule uses a hard-coded password to encrypt/decrypt the data source password. ocil:com.redhat.eap5.scap:testaction:11360101 Eliminate clear-text passwords: Tomcat Connectors Eliminate clear-text passwords in: Tomcat Connectors. ocil:com.redhat.eap5.scap:testaction:11630101 Eliminate clear-text passwords: XML configuration files Using password masking, eliminate clear-text passwords in XML configuration files. ocil:com.redhat.eap5.scap:testaction:11650101 Change default password: JBoss Messaging MessageSucker JBoss Messaging ships with a default MessageSucker password located within the Messaging ServerPeer configuration. This password is used by JBoss to create connections and pass messages between nodes. ocil:com.redhat.eap5.scap:testaction:40020101 Change default password: Java cacerts keystore The Java cacerts keystore is installed by default with most versions of Java. It contains X.509 public certificates for a set of default commercial Certificate Authorities. ocil:com.redhat.eap5.scap:testaction:40030101 Ensure logging is enabled for web-based requests if required by deployed applications In the event that application requirements dictate additional logging for web-based requests, the AccessLogValve should be enabled. ocil:com.redhat.eap5.scap:testaction:20230101 Ensure JBoss process owner is executing with least privilege Operating environment permissions assigned to the JBoss process owner should be in compliance with the principle of least privilege. ocil:com.redhat.eap5.scap:testaction:40040101 Deny the JBoss process owner console access The JBoss Application Server process owner should not have interactive console login access. ocil:com.redhat.eap5.scap:testaction:10990101 Set JBoss file ownership All JBoss Enterprise Application Platform files within JBOSS_HOME should be owned by the JBoss process owner account. ocil:com.redhat.eap5.scap:testaction:11620101 Set JBoss file permissions All JBoss Enterprise Application Platform files within JBOSS_HOME should be readable by the JBoss Application Server process owner and JBoss administrators only. ocil:com.redhat.eap5.scap:testaction:10980101 Deployed applications should display a system use banner upon access Upon accessing the system, a notification banner, consent to use, or policy warning banner should be displayed to alert system users of the system use details. This may include items such as implied consent to monitor, privacy practices, or liability waivers. ocil:com.redhat.eap5.scap:testaction:30060101 Deployed applications should display a classification banner when required Deployed applications should present classification banners at the header and footer of each page in accordance with the applicable DoD classification guide for the environment. ocil:com.redhat.eap5.scap:testaction:30070101 Password hashing must be enabled within the appropriate login module A Security Domain is a set of authentication, authorization, and mapping policies defined in XML and are available to applications at runtime using Java Naming and Directory Interface (JNDI). ocil:com.redhat.eap5.scap:testaction:20150101 A password hashing algorithm must be defined within the appropriate login module A Security Domain is a set of authentication, authorization, and mapping policies defined in XML and are available to applications at runtime using Java Naming and Directory Interface (JNDI). An <application-policy> can be defined in the server profile or in an application deployment descriptor. ocil:com.redhat.eap5.scap:testaction:20170101 Enterprise JavaBeans Specification v2.1 must be strictly followed The programming restrictions mandated by the Enterprise JavaBeans Specification v2.1 must be strictly followed. For more information, refer to JSR-000153 Enterprise JavaBeans 2.1 specification. (Section 25.2, pages 562-564). ocil:com.redhat.eap5.scap:testaction:20680101 Ensure adequate physical protections are in place The hardware and software executing JBoss Enterprise Application Platform, as well as the software critical to security policy enforcement must be protected from unauthorized modification including unauthorized modifications by potentially hostile outsiders. Reasonable physical security measures to ensure that unauthorized personnel do not have physical access to the hardware running the JBoss Enterprise Application Platform software must be implemented. ocil:com.redhat.eap5.scap:testaction:20620101 Assign a JBoss administrator There must be one or more competent individuals who are assigned to manage JBoss Enterprise Application Platform, its environment and the security of the information it contains. ocil:com.redhat.eap5.scap:testaction:20630101 Document incident response procedures Ensure well developed procedures exist for incident handling. Incidents include any events that are anomalous to the environment, which typically include: intrusions (possibly including attempts), application failures, unexpected platform activity such as restarts or configuration changes, and unusual network traffic to or from the server. ocil:com.redhat.eap5.scap:testaction:11290101 Perform periodic incident response exercises Production environments should exercise incident response procedures at least annually. Environments requiring higher assurances of security should test incident response procedures more often, possibly quarterly or even monthly. Incident response procedures should cover all anomalous events. ocil:com.redhat.eap5.scap:testaction:11330101 Document disaster recovery procedures Robust disaster recovery documentation and procedures should exist. This documentation should include provisions for the JBoss platform, deployed applications, required source code, and supporting applications (such as authentication stores or database servers). ocil:com.redhat.eap5.scap:testaction:11320101 Perform periodic disaster recovery exercises Production environments should exercise disaster recovery procedures that include provisions for the JBoss platform, deployed applications, and any required source code at least annually. Environments requiring higher assurances of disaster recovery ability should test procedures more often, possibly quarterly or even monthly. ocil:com.redhat.eap5.scap:testaction:11340101 Identify and document application data flows It is recommended to identify and document application data flows. This will allow insight into what paths sensitive information takes through the application environment and what data source connections need to be encrypted. ocil:com.redhat.eap5.scap:testaction:11350101 Java permissions for deployed applications should be documented and reviewed prior to deployment Java permissions for applications should be documented and carefully reviewed prior to deployment. Developers and administrators should strive to balance application permissions and application functionality. ocil:com.redhat.eap5.scap:testaction:11590101 Regular backups should be performed JBoss applications and configuration files should be backed up at least weekly, possibly more if needed by the environment. ocil:com.redhat.eap5.scap:testaction:11460101 Auditing policy should exist In order to effectively audit and review system logs, an audit policy should be written to identify data and trends of interest. ocil:com.redhat.eap5.scap:testaction:11530101 Access control policy and procedures JBoss administrators must have access to guidance regarding account creation, permissions assignments, role assignments, etc. ocil:com.redhat.eap5.scap:testaction:11640101 Define an appropriate minimum and maximum password length requirement Organizations should create an authenticator management policy that defines minimum and maximum password sizes for user accounts accessing JBoss and its deployed applications. ocil:com.redhat.eap5.scap:testaction:30030101 Define an appropriate minimum password complexity requirement Organizations should create an authenticator management policy that defines a minimum level of complexity for user accounts accessing JBoss and its deployed applications. These requirements should also restrict passwords from containing dictionary words and reusing previous passwords. ocil:com.redhat.eap5.scap:testaction:30040101 Define an appropriate minimum password expiration interval Organizations should create an authenticator management policy that defines a maximum password age for user accounts accessing JBoss and its deployed applications. ocil:com.redhat.eap5.scap:testaction:30050101 ocil:com.redhat.eap5.scap:testaction:30050102 Production JBoss EAP installations should reside on a dedicated platform Production JBoss servers should be hosted on dedicated operating systems and not sharing a host operating system with other service applications. ocil:com.redhat.eap5.scap:testaction:40010101 Avoid multiple JBoss instances per server Multiple instances of JBoss deployed onto a single server should be avoided whenever possible to reduce environmental complexity and administrative burdens. However, occasionally circumstances require that multiple JBoss instances are deployed to the same server. In this scenario, the configurations and justifications should be documented along with the rest of the system's documentation. ocil:com.redhat.eap5.scap:testaction:11240101 Bind multiple JBoss instances per server to different IPs If multiple JBoss instances are installed, the servers should be set to bind to different IP addresses on the server rather than changing the default port configuration. ocil:com.redhat.eap5.scap:testaction:11310101 Packet filtering should be emplaced around JBoss Enterprise Application Platform JBoss Enterprise Application Platform must operate in a network segment that is logically separated from any other network segment using a packet filtering mechanism. This packet filter must only allow incoming communication that is TCP with destination ports of 8080 or 8443. This packet filter can be resident on the host operating system or a completely separate system entirely. When JBoss Enterprise Application Platforms are clustered, all outgoing communication from the JBoss Enterprise Application Platform instance must be allowed. ocil:com.redhat.eap5.scap:testaction:20640101 Do not transmit sensitive information over unsecured HTTP connections Sensitive information should not be transferred over insecure means. This includes plaintext credential information, application information deemed sensitive, or other information that an may be valuable to a malicious entity. The <auth-method> child element specifies the authentication mechanism for the web application. Using the BASIC authentication method causes the exchange of credentials in clear text. ocil:com.redhat.eap5.scap:testaction:10940101 Use a version control repository All configuration files (such a data sources, custom connectors, etc) and any scripts used for modifications and deployments should be stored in the version control repository. Typical repositories include applications such as SVN or Git. Additionally, a hash-validated 'Gold' version of the JBoss installation package should also be stored in the version control system. ocil:com.redhat.eap5.scap:testaction:11040101 Automate JBoss Deployments Scripts or other software tools should be used to automatically configure and deploy JBoss applications in environments. ocil:com.redhat.eap5.scap:testaction:11250101 Application performance testing Ensure routine performance testing is completed before applications are deployed to production. Establish and document performance profiles. ocil:com.redhat.eap5.scap:testaction:11270101 Monitor JBoss servers JBoss Enterprise Application Platform servers in production environments should be monitored real-time. Information monitored and alarm thresholds will vary. Common monitoring tools include: JBoss Operations Network (JON), Foglight, HP Openview, and Nagios. ocil:com.redhat.eap5.scap:testaction:11280101 Ensure all downloaded software is authentic Software and packages should be downloaded from redhat.com, and hash validated. ocil:com.redhat.eap5.scap:testaction:20570101 Ensure JBoss is configured in accordance with Common Criteria configuration guides JBoss deployments in government and DoD organizations require JBoss be deployed in a Common Criteria certified configuration. The Common Criteria configuration is a list of technical configuration items, policy requirements, and other configurations required to certify a JBoss installation at the EAL4+ protection level. Red Hat maintains configuration guidance available online to assist administrators during the installation and configuration of JBoss. ocil:com.redhat.eap5.scap:testaction:40100101 Unused features should be disabled or deleted: Java Universal Description, Discovery, Integration (JUDDI) Features and services not in use should be removed. JUDDI is an open source Java implementation of the Universal Description, Discovery, and Integration (UDDI v3) specification for (Web) Services. ocil:com.redhat.eap5.scap:testaction:11060101 Unused features should be disabled or deleted: Enterprise Java Beans (EJB) Services Features and services not in use should be removed. ocil:com.redhat.eap5.scap:testaction:11070101 Unused features should be disabled or deleted: Universal Unique Identifier (UUID) Generator Features and services not in use should be removed. UUID Generator allows for the generation of unique identifiers for hosted Java applications. ocil:com.redhat.eap5.scap:testaction:11080101 Unused features should be disabled or deleted: Java Message Service (JMS) Features and services not in use should be removed. Java Message Service is a component of Java Enterprise Edition that enables application to send and receive messages. It is a cornerstone service that many distributed applications are built on. ocil:com.redhat.eap5.scap:testaction:11090101 Unused features should be disabled or deleted: JBoss Mail Features and services not in use should be removed. JBoss Mail is a deployed package for Java Mail - a set of Java API's implementing an email server supporting the SMTP, POP3, and IMAP protocols. ocil:com.redhat.eap5.scap:testaction:11100101 Unused features should be disabled or deleted: JBoss Scheduling Features and services not in use should be removed. JBoss Scheduling implements a JBoss service that supports scheduling and running jobs for deployed Java applications. ocil:com.redhat.eap5.scap:testaction:11110101 Unused features should be disabled or deleted: Hypersonic SQL Database (HSQLDB) Features and services not in use should be removed. HSQLDB is the default datasource configured to run with JBoss Enterprise Application Platform out of the box. It is not recommended for production usage. ocil:com.redhat.eap5.scap:testaction:11120101 Unused features should be disabled or deleted: BeanShell (BSH) Deployer Features and services not in use should be removed. The BSH Deployer allows for the hot deployment of one use execution scripts or services. ocil:com.redhat.eap5.scap:testaction:11130101 Unused features should be disabled or deleted: JBossWS Features and services not in use should be removed. JBossWS is a web service framework for use with the JBoss Enterprise Application Platform. ocil:com.redhat.eap5.scap:testaction:11140101 Unused features should be disabled or deleted: Seam Features and services not in use should be removed. Seam is an application framework for Java designed to reduce application complexity. ocil:com.redhat.eap5.scap:testaction:11150101 Unused features should be disabled or deleted: JBoss Internet Inter-ORB Protocol (IIOP) Features and services not in use should be removed. JBoss IIOP implements a standards compliant CORBA server for JBoss. ocil:com.redhat.eap5.scap:testaction:11160101 Unused features should be disabled or deleted: Miscellaneous Miscellaneous features and services not in use should be removed. ocil:com.redhat.eap5.scap:testaction:11170101 Unused features should be disabled or deleted: HTTP Invokers Features and services not in use should be removed. HTTP invocation allows the JBoss server to receive and act on remote instructions. This can be useful for administrators - especially in large or distributed environments. ocil:com.redhat.eap5.scap:testaction:11180101 Unused features should be disabled or deleted: Java Management Extensions (JMX) Invoker Features and services not in use should be removed. The JMX Invoker exposes the JMX MBeanServer interface via Remote Method Invocation compatible interface. This can be useful for administrators - especially in large or distributed environments. ocil:com.redhat.eap5.scap:testaction:11190101 Unused features should be disabled or deleted: Pooled Invoker Features and services not in use should be removed. The org.jboss.invocation.pooled.server.PooledInvoker provides RMI over a custom socket implementation of the Invoker interface. ocil:com.redhat.eap5.scap:testaction:11200101 Unused features should be disabled or deleted: Java Remote Method Protocol (JRMP) Invoker Features and services not in use should be removed. The org.jboss.invocation.jrmp.server.JRMPInvoker provides the RMI/JRMP implementation of the Invoker interface. ocil:com.redhat.eap5.scap:testaction:11210101 Unused features should be disabled or deleted: Clustering Features and services not in use should be removed. Clustering allows deployed applications to run distributed across multiple JBoss Enterprise Application Platform servers. ocil:com.redhat.eap5.scap:testaction:11230101 PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS ocil:com.redhat.eap5.scap:choice:2003010101 ocil:com.redhat.eap5.scap:choice:2003010102 ocil:com.redhat.eap5.scap:choice:2003010103 ocil:com.redhat.eap5.scap:choice:2003010104 ocil:com.redhat.eap5.scap:choice:2003010105 ocil:com.redhat.eap5.scap:choice:2003010106 ocil:com.redhat.eap5.scap:choice:2003010107 ocil:com.redhat.eap5.scap:choice:2003010108 ocil:com.redhat.eap5.scap:choice:2003010109 ocil:com.redhat.eap5.scap:choice:2003010110 ocil:com.redhat.eap5.scap:choice:2003010111 ocil:com.redhat.eap5.scap:choice:2003010112 ocil:com.redhat.eap5.scap:choice:2003010113 ocil:com.redhat.eap5.scap:choice:2003010114 ocil:com.redhat.eap5.scap:choice:2003010115 ocil:com.redhat.eap5.scap:choice:2003010116 FAIL ocil:com.redhat.eap5.scap:choice:2003010199 PASS FAIL PASS FAIL PASS FAIL ocil:com.redhat.eap5.scap:testaction:20230102 PASS PASS FAIL PASS FAIL PASS FAIL PASS FAIL ocil:com.redhat.eap5.scap:testaction:20440102 FAIL FAIL PASS PASS FAIL ocil:com.redhat.eap5.scap:testaction:20500102 PASS PASS FAIL PASS FAIL FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL ocil:com.redhat.eap5.scap:testaction:20650102 PASS PASS FAIL PASS FAIL FAIL PASS PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL FAIL PASS PASS FAIL PASS ocil:com.redhat.eap5.scap:testaction:11060102 PASS FAIL PASS ocil:com.redhat.eap5.scap:testaction:11070102 PASS FAIL PASS ocil:com.redhat.eap5.scap:testaction:11080102 PASS FAIL PASS ocil:com.redhat.eap5.scap:testaction:11090102 PASS FAIL PASS ocil:com.redhat.eap5.scap:testaction:11100102 PASS FAIL PASS ocil:com.redhat.eap5.scap:testaction:11110102 PASS FAIL PASS ocil:com.redhat.eap5.scap:testaction:11120102 PASS FAIL PASS ocil:com.redhat.eap5.scap:testaction:11130102 PASS FAIL PASS ocil:com.redhat.eap5.scap:testaction:11140102 PASS FAIL PASS ocil:com.redhat.eap5.scap:testaction:11150102 PASS FAIL PASS ocil:com.redhat.eap5.scap:testaction:11160102 PASS FAIL PASS ocil:com.redhat.eap5.scap:testaction:11170102 PASS FAIL PASS ocil:com.redhat.eap5.scap:testaction:11180102 PASS FAIL PASS ocil:com.redhat.eap5.scap:testaction:11190102 PASS FAIL PASS ocil:com.redhat.eap5.scap:testaction:11200102 PASS FAIL PASS ocil:com.redhat.eap5.scap:testaction:11210102 PASS FAIL PASS ocil:com.redhat.eap5.scap:testaction:11230102 PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL Is the version of JBoss installed actively supported by the vendor? [Please reference Rule ID #200001 in /docs/JBossEAP5_Guide.html for more information] Instructions Execute run.bat --version or run.sh --version located within JBOSS_HOME/bin to determine the version of JBoss EAP installed. Work with JBoss administrators to access the Red Hat Network customer portal in order to review and validate active subscriptions. Ensure the version of JBoss has not reached end-of-life. Does JBoss utilize a vendor supported Java Runtime Environment? [Please reference Rule ID #200201 in /docs/JBossEAP5_Guide.html for more information] Instructions Execute run.bat --version or run.sh --version located within JBOSS_HOME/bin to identify the version of Java used by JBoss. Search the vendor's website and support documentation to ensure the vendor actively supports the version of Java virtual machine in use. If The Java Runtime Environment will reach end-of-life within the next year, has the organization developed migration plans? [Please reference Rule ID #200201 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators and review relevant documentation. What operating system is hosting the Red Hat JBoss Enterprise Application Server (all binaries, configuration files, etc.)? [Please reference Rule ID #200301 in /docs/JBossEAP5_Guide.html for more information] Instructions From a command shell, execute "cat /etc/redhat-release" The output of the command above will display the host operating system version information. Red Hat Enterprise Linux 6 x86 Red Hat Enterprise Linux 6 x86-64 Red Hat Enterprise Linux 5 x86 Red Hat Enterprise Linux 5 x86-64 Red Hat Enterprise Linux 4 x86 Red Hat Enterprise Linux 4 x86-64 Solaris 10 SPARC 64 Solaris 10 x86-64 Solaris 10 x86 Solaris 9 SPARC (64-bit) Solaris 9 SPARC (32-bit) Solaris 9 x86 Microsoft Windows Server 2008 x86-64 Microsoft Windows Server 2008 x86 Microsoft Windows Server 2003 x86-64 Microsoft Windows Server 2003 x86 Other Have all configuration changes been made to the JBoss production profile? [Please reference Rule ID #200501 in /docs/JBossEAP5_Guide.html for more information] Instructions Ensure that all configuration changes and deployments are made to the production server profile. Do deployed applications requiring authentication by <login-module> require hashed passwords? [Please reference Rule ID #20150101 in /docs/JBossEAP5_Guide.html for more information] Instructions To determine which <application-policy> are in use by deployed applications, search for <security-domain> elements within deployment descriptors. This element should be included within a deployed application's <application-policy><login-module>: <module-option name="hashUserPassword">true</module-option> Do deployed applications requiring authentication by <login-module> define a hashing algorithm? [Please reference Rule ID #201501 in /docs/JBossEAP5_Guide.html for more information] Instructions To determine which <application-policy> are in use by deployed applications, search for <security-domain> elements within deployment descriptors. Add one of the following child elements to any <application-policy><login-module> in use: <module-option name="hashAlgorithm">MD5</module-option> <module-option name="hashAlgorithm">SHA</module-option> Do any deployed applications require logging for web-based requests? [Please reference Rule ID #201501 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators. Review application and system documentation. Determine if the ability to log web-based requests has been identified. Has the appropriate AccessLogValve been uncommented in JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml? [Please reference Rule ID #201501 in /docs/JBossEAP5_Guide.html for more information] Instructions If logging of web-based requests has been required for deployed applications the AccessLogValve should be enabled. To check the status of the <Valve>, ensure the following element is defined within JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. <Valve className="org.apache.catalina.valves.AccessLogValve" prefix="localhost_access_log." suffix=".log" pattern="common" directory="${JBoss.server.home.dir}/log" resolveHosts="false" /> Has a valid security domain been specified for the deployed applications (overriding the simplified Seam JAAS configuration)? [Please reference Rule ID #202801 in /docs/JBossEAP5_Guide.html for more information] Instructions Check for components.xml for the deployed application. A security domain must be defined and the security domain must map to a valid JAAS security domain. Do your application specific security policies declare one of the following authorization modules: org.JBoss.security.authorization.modules.DelegatingAuthorizationModule, org.JBoss.security.authorization.modules.JACCAuthorizationModule? [Please reference Rule ID #203901 in /docs/JBossEAP5_Guide.html for more information] Instructions Applications deploying their own security policies must specify org.JBoss.security.authorization.modules.DelegatingAuthorizationModule or org.JBoss.security.authorization.modules.JACCAuthorizationModule <policy-module> within their 'code' attributes: Are the most restrictive Java Database Connectivity (JDBC) permissions assigned via the Java Security Manager (JSM)? [Please reference Rule ID #204201 in /docs/JBossEAP5_Guide.html for more information] Instructions To validate compliance, review all policy files defining permissions for the Java Security Manager. The systems administrator must assign the most restrictive permissions possible (in accordance with the least privilege principle) to applications accessing defined data sources. Is a DefaultDS defined? [Please reference Rule ID #204401 in /docs/JBossEAP5_Guide.html for more information] Instructions Search for a data source with a <jndi-name>DefaultDS</jndi-name> element. Is the DefaultDS an instance of HSQLDB? [Please reference Rule ID #204401 in /docs/JBossEAP5_Guide.html for more information] Instructions The DefaultDS CANNOT be HSQL. An HSQL data source will contain elements like: <driver-class>org.hsqldb.jdbcDriver</driver-class> and <type-mapping>Hypersonic SQL</type-mapping>. For installations using Java Messaging Service, has the appropriate persistence-service.xml file been installed? [Please reference Rule ID #204701 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview the JBoss administrators and application developers to determine if JMS is in use. A quick check can also be performed by checking for the existence of JBOSS_HOME/server/[PROFILE]/deploy/messaging or JBOSS_HOME/server/[PROFILE]/deploy/jms-ra.rar. If JMS is installed, a persistence-service.xml file must exist that does not use HSQLDB. Is Oracle Database configured as the DefaultDS? [Please reference Rule ID #205001 in /docs/JBossEAP5_Guide.html for more information] Instructions Review the DefaultDS datasource. Is the Oracle Database persistence plugin configured correctly in JBOSS_HOME/server/[PROFILE]/deploy/ejb2-timer-service.xml? [Please reference Rule ID #205001 in /docs/JBossEAP5_Guide.html for more information] Instructions Review the persistence plugin located at JBOSS_HOME/server/[PROFILE]/deploy/ejb2-timer-service.xml. The DatabasePersistencePlugin attribute must be configured specifically for Oracle Database: org.JBoss.ejb.txtimer.OracleDatabasePersistencePlugin Are the most restrictive Java Security Manager (JSM) permissions assigned to deployed applications for JBoss JMX Kernel MBean interaction? [Please reference Rule ID #205101 in /docs/JBossEAP5_Guide.html for more information] Instructions Review all JSM permissions granted to MBeans. Grant statements should be limited to specific users and specific methods. Have java.io.FilePermission been appropriately assigned to deployed applications? [Please reference Rule ID #205201 in /docs/JBossEAP5_Guide.html for more information] Instructions Review all policy files defining permissions for the Java Security Manager. Review all permissions granted to user deployed applications. Grant statements granting file permissions are permitted only when the file permission targets are located within the user application's directory and dedicated for use by the deployed application. The systems administrator must assign the most restrictive permissions possible (in accordance with the least privilege principle) for applications. Have java.net.NetPermission been assigned to deployed applications? [Please reference Rule ID #205301 in /docs/JBossEAP5_Guide.html for more information] Instructions Review all policy files defining permissions for the Java Security Manager. Review all permissions granted to user deployed applications. Grant statements granting network permissions are not allowed Have java.lang.RuntimePermission been assigned to deployed applications? [Please reference Rule ID #205401 in /docs/JBossEAP5_Guide.html for more information] Instructions Review all policy files defining permissions for the Java Security Manager. Review all permissions granted to user deployed applications. Grant statements granting runtime permissions are not allowed. Have java.net.SocketPermission been assigned to deployed applications? [Please reference Rule ID #205501 in /docs/JBossEAP5_Guide.html for more information] Instructions Review all policy files defining permissions for the Java Security Manager. Review all permissions granted to user deployed applications. Grant statements granting socket permissions are not allowed. Have java.security.AllPermission (or equivalent for your JDBC driver) been assigned to deployed applications? [Please reference Rule ID #205601 in /docs/JBossEAP5_Guide.html for more information] Instructions Review all policy files defining permissions for the Java Security Manager. Review all permissions granted to user deployed applications. Grant statements granting AllPermission are not allowed. Has all downloaded and installed software been validated as authentic? [Please reference Rule ID #205701 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators. JBoss administrators must demonstrate proficiency in securely acquiring JBoss Enterprise Application Platform installation materials. Has the JBoss installation been configured and installed according to the JBoss Common Criteria Configuration Guide? [Please reference Rule ID #401001 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators and review on-site documentation. Review the JBoss Common Criteria Configuration Guide Review the JBoss Common Criteria Configuration Guide to ensure JBoss has been installed and configured in accordance with the Common Criteria requirements. Does a JBoss keystore exist that is accessible only to JBoss and JBoss administrators? [Please reference Rule ID #205901 in /docs/JBossEAP5_Guide.html for more information] Instructions Determine which keystore is being used by JBoss. Next, validate that the keystore exists at the specified path and that the JBoss process owner account and JBoss administrators have READ/WRITE access to the keystore. Is the jboss alias in the trustedCertEntry? [Please reference Rule ID #206101 in /docs/JBossEAP5_Guide.html for more information] Instructions Review the JBoss keystore to ensure the jboss alias exists as a trustedCertEntry. Does the hardware and software executing JBoss Enterprise Application Platform, as well as the software critical to security policy enforcement, have adequate physical protections? [Please reference Rule ID #206201 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators and security personnel. Visually inspect physical security precautions. Review space certifications where appropriate. Have administrative personnel requirements been met? [Please reference Rule ID #206301 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators. Review credentials and qualifications. JBoss Administrators should possess a basic level of proficiency with the software. Additionally, they must not be carelessly or willfully negligent, or hostile, and must follow the instructions provided by the administrator documentation. Have packet filtering protections been implemented? [Please reference Rule ID #206401 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators and architects. Review system network diagrams. Packet filters must only allow incoming communication that is TCP with destination ports of 8080 or 8443. Is the JBoss Installation using version 1.6 of the IBM JRE? [Please reference Rule ID #206501 in /docs/JBossEAP5_Guide.html for more information] Instructions See /docs/JBossEAP5_Guide.html for details. Has the IBM JRE 1.6 in use been reconfigured to use the standard policy provider? [Please reference Rule ID #206501 in /docs/JBossEAP5_Guide.html for more information] Instructions See /docs/JBossEAP5_Guide.html for details. Have deployed applications been developed in accordance with Enterprise JavaBeans Specification v2.1 (specifically Section 25.2, pages 562-564)? [Please reference Rule ID #206801 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview developers or review product documentation to determine if deployed applications were developed in accordance with Enterprise JavaBeans 2.1 specifications. Do deployed applications store data in the DefaultDS data source? [Please reference Rule ID #215701 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview the application developers and/or review source code to identify when data sources are used. Ensure that the application is not storing data within the DefaultDS. Are <security-role> elements used to control access to deployed applications? [Please reference Rule ID #109201 in /docs/JBossEAP5_Guide.html for more information] Instructions Review the web.xml deployment descriptors for deployed applications. Ensure that <security-role> elements have been define that are referenced by <security-constraint><auth-constraint> elements within the <web-app> root element. Have HTTP methods been whitelisted to control access to deployed applications via the web? [Please reference Rule ID #109301 in /docs/JBossEAP5_Guide.html for more information] Instructions Review application deployment descriptors for indications that <http-method> has been used to whitelist HTTP verbs. Have maxPostSize attributes been set correctly for the Tomcat container? [Please reference Rule ID #401101 in /docs/JBossEAP5_Guide.html for more information] Instructions Review <Connector> elements in JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. Check for <Connector> elements that define a maxPostSize attribute. If a maxPostSize attribute is defined, it should be 104857600 or less (100 MB). Have maxSavePostSize attributes been set correctly for the Tomcat container? [Please reference Rule ID #401201 in /docs/JBossEAP5_Guide.html for more information] Instructions Review <Connector> elements in JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. Check for <Connector> elements that define a maxSavePostSize attribute. If a maxSavePostSize attribute is defined, it should be 12288 or less (12 KB). Have server attributes been set correctly for the Tomcat container? [Please reference Rule ID #401301 in /docs/JBossEAP5_Guide.html for more information] Instructions Review HTTP <Connector> elements in JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. Check each HTTP <Connector> element to ensure it defines a server attribute. A server attribute should be defined, and it should be set to something other than Apache-Coyote/1.1. Have ciphers attributes been set correctly for the Tomcat container? [Please reference Rule ID #401401 in /docs/JBossEAP5_Guide.html for more information] Instructions Review <Connector> elements in JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. Check for <Connector> elements that define a secure=true attribute. Check each <Connector> element that contains a secure=true attribute. Ensure this connector does not define a ciphers attribute and instead inherits ciphers defined by the JVM. Have connectionTimeout attributes been set correctly for the Tomcat container? [Please reference Rule ID #401501 in /docs/JBossEAP5_Guide.html for more information] Instructions Review HTTP <Connector> elements in JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml. Check to ensure they define a connectionTimeout attribute. The connectionTimeout attribute should be 20000 or less (20 seconds). Is sensitive information transmitted only over secure channels such as SSL or TLS? [Please reference Rule ID #109401 in /docs/JBossEAP5_Guide.html for more information] Instructions >Interview JBoss administrators and application developers. Review application documentation. Descriptive information for sensitive data used by the application should be readily available. Ensure this information is secured with SSL 3.x or TLS. There are multiple ways to secure the connections. Are JBoss EAP file permissions set appropriately? [Please reference Rule ID #109801 in /docs/JBossEAP5_Guide.html for more information] Instructions Validate file permissions for JBOSS_HOME files and subdirectories. File permissions should be restricted to READ/WRITE for JBoss process owner and JBoss administrators. Other accounts that may require READ access include version control accounts or process owners for backup software. Do any deployed applications implement the default SRPVerifierStore interface? [Please reference Rule ID #110101 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview application developers and review application documentation. If deployed applications utilize SRP and/or source code is available for reference, review evidence that the default SRPVerifierStore interface is not in use and that the existing code does not use serialized objects for persistence. Is a version control repository in use for JBoss? [Please reference Rule ID #110401 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators and/or platform administrators. Review evidence of version control system and its use. Is JUDDI being used by deployed applications? [Please reference Rule ID #110601 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate its removal. Is the EJB Services being used by deployed applications? [Please reference Rule ID #110701 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate its removal. Is the UUID Generator being used by deployed applications? [Please reference Rule ID #110801 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate its removal. Is the Java Messaging Service being used by deployed applications? [Please reference Rule ID #110901 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate its removal. Is JBoss Mail being used by deployed applications? [Please reference Rule ID #111001 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate its removal. Is JBoss Scheduling being used by deployed applications? [Please reference Rule ID #111101 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate its removal. Is the Hypersonic SQL Database being used by deployed applications? [Please reference Rule ID #111201 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate its removal. Is the BSH Deployer being used by deployed applications? [Please reference Rule ID #111301 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate its removal. Is JBossWS being used by deployed applications? [Please reference Rule ID #111401 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate its removal. Is SEAM being used by deployed applications? [Please reference Rule ID #111501 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate its removal. Is IIOP/Corba being used by deployed applications? [Please reference Rule ID #111601 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate its removal. Are miscellaneous features being used by deployed applications? [Please reference Rule ID #111701 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate its removal. Is the HTTP Invoker being used by deployed applications? [Please reference Rule ID #111801 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate its removal. Is the JMX Invoker being used by deployed applications? [Please reference Rule ID #111901 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate its removal. Is the Pooled Invoker being used by deployed applications? [Please reference Rule ID #112001 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate its removal. Is the JRMP Invoker being used by deployed applications? [Please reference Rule ID #112101 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate its removal. Is Clustering being used by deployed applications? [Please reference Rule ID #112301 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators and/or platform administrators. If the feature or service is not used, validate its removal. Has JUDDI been disabled or deleted? [Please reference Rule ID #110601 in /docs/JBossEAP5_Guide.html for more information] Instructions Due to space and formatting limitations under the OCIL specification, see the /docs/JBossEAP5_Guide.html for details. Have the EJB Services been disabled or deleted? [Please reference Rule ID #110701 in /docs/JBossEAP5_Guide.html for more information] Instructions Due to space and formatting limitations under the OCIL specification, see the /docs/JBossEAP5_Guide.html for details. Has the UUID Generator been disabled or deleted? [Please reference Rule ID #110801 in /docs/JBossEAP5_Guide.html for more information] Instructions Due to space and formatting limitations under the OCIL specification, see the /docs/JBossEAP5_Guide.html for details. Has the Java Messaging Service been disabled or deleted? [Please reference Rule ID #110901 in /docs/JBossEAP5_Guide.html for more information] Instructions Due to space and formatting limitations under the OCIL specification, see the /docs/JBossEAP5_Guide.html for details. Has JBoss Mail been disabled or deleted? [Please reference Rule ID #111001 in /docs/JBossEAP5_Guide.html for more information] Instructions Due to space and formatting limitations under the OCIL specification, see the /docs/JBossEAP5_Guide.html for details. Has JBoss Scheduling been disabled or deleted? [Please reference Rule ID #111101 in /docs/JBossEAP5_Guide.html for more information] Instructions Due to space and formatting limitations under the OCIL specification, see the /docs/JBossEAP5_Guide.html for details. Has the Hypersonic SQL Database been disabled or deleted? [Please reference Rule ID #111201 in /docs/JBossEAP5_Guide.html for more information] Instructions Due to space and formatting limitations under the OCIL specification, see the /docs/JBossEAP5_Guide.html for details. Has the BSH Deployer been disabled or deleted? [Please reference Rule ID #111301 in /docs/JBossEAP5_Guide.html for more information] Instructions Due to space and formatting limitations under the OCIL specification, see the /docs/JBossEAP5_Guide.html for details. Has JBossWS been disabled or deleted? [Please reference Rule ID #111401 in /docs/JBossEAP5_Guide.html for more information] Instructions Due to space and formatting limitations under the OCIL specification, see the /docs/JBossEAP5_Guide.html for details. Has Seam been disabled or deleted? [Please reference Rule ID #111501 in /docs/JBossEAP5_Guide.html for more information] Instructions Due to space and formatting limitations under the OCIL specification, see the /docs/JBossEAP5_Guide.html for details. Has IIOP/Corba been disabled or deleted? [Please reference Rule ID #111601 in /docs/JBossEAP5_Guide.html for more information] Instructions Due to space and formatting limitations under the OCIL specification, see the /docs/JBossEAP5_Guide.html for details. Have the miscellaneous features disabled or deleted? [Please reference Rule ID #111701 in /docs/JBossEAP5_Guide.html for more information] Instructions Due to space and formatting limitations under the OCIL specification, see the /docs/JBossEAP5_Guide.html for details. Has the HTTP Invoker been disabled or deleted? [Please reference Rule ID #111801 in /docs/JBossEAP5_Guide.html for more information] Instructions Due to space and formatting limitations under the OCIL specification, see the /docs/JBossEAP5_Guide.html for details. Has the JMX Invoker been disabled or deleted? [Please reference Rule ID #111901 in /docs/JBossEAP5_Guide.html for more information] Instructions Due to space and formatting limitations under the OCIL specification, see the /docs/JBossEAP5_Guide.html for details. Has the Pooled Invoker been disabled or deleted? [Please reference Rule ID #112001 in /docs/JBossEAP5_Guide.html for more information] Instructions Due to space and formatting limitations under the OCIL specification, see the /docs/JBossEAP5_Guide.html for details. Has the JRMP Invoker been disabled or deleted? [Please reference Rule ID #112101 in /docs/JBossEAP5_Guide.html for more information] Instructions Due to space and formatting limitations under the OCIL specification, see the /docs/JBossEAP5_Guide.html for details. Has Clustering been disabled or deleted? [Please reference Rule ID #112301 in /docs/JBossEAP5_Guide.html for more information] Instructions Due to space and formatting limitations under the OCIL specification, see the /docs/JBossEAP5_Guide.html for details. Are JBoss installations limited toa single instance per server? [Please reference Rule ID #112401 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators, review system documentation and architecture diagrams. Determine if JBoss Enterprise Application Platform installations are limited to one per server. If they are not limited to one per server, ensure the configuration, rationale, and risk assessment is well documented. Is the deployment and configuration of JBoss to new environments automated? [Please reference Rule ID #112501 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators and review procedural documentation. Determine if applications are deployed to JBoss Enterprise Application Platforms in an automated manner. Is performance testing completed for applications prior to their deployment to production environments? [Please reference Rule ID #112701 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss system administrators and application developers. Review product documentation related to performance testing and load limits. Review policy and procedural documents related to performance testing. Production environments should have documented and established performance profiles. Applications should be performance tested prior to deployment to production environments. Is the JBoss server production environment being monitored in real-time with JON, Foglight, or another similar tool? [Please reference Rule ID #112801 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss system administrators. Review server documentation and system architecture diagrams. Review documents related to server monitoring. Production environments should have a real-time monitoring solution in place. Do JBoss administrators possess robust incident response procedures? [Please reference Rule ID #112901 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators. Review system documentation, incident response documentation, contingency documentation, and any other relevant documentation. Determine if the incident response procedures in place are robust, up-to-date, and clear. If multiple instances of JBoss Enterprise Application Platform are deployed on any servers, are those servers configured to bind to different IP addresses rather than changing the port binds? [Please reference Rule ID #113101 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators and review system documentation. Examine running JBoss servers and bound ports using commands like netstat. If multiple JBoss instances are deployed to a single server, it is a best practice to bind each instance to its own IP address. Do JBoss administrators possess a robust disaster recovery policy? [Please reference Rule ID #113201 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators. Review system documentation, disaster recovery documentation, contingency documentation, and any other relevant documentation. Determine if the disaster recovery procedures in place are robust, up-to-date, and feasible. Do JBoss administrators exercise incident response procedures at least annually? [Please reference Rule ID #113301 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators. Review system documentation, incident response documentation, and any other relevant documentation. Review lessons-learned, after-action reports, or other historical documentation. Determine if the incident response procedures are meaningfully exercised at least annually. Do JBoss administrators exercise disaster recovery procedures at least annually? [Please reference Rule ID #113401 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators. Review system documentation, disaster recovery documentation, contingency documentation, and any other relevant documentation. Review lessons-learned, after-action reports, or other historical documentation. Determine if the disaster recovery procedures are meaningfully exercised at least annually. Are data flows for deployed applications documented? [Please reference Rule ID #113501 in /docs/JBossEAP5_Guide.html for more information] Instructions >Examine application documentation, system architecture documentation, and any other pertinent diagrams. Interview JBoss administrators and application developers. Application data flows should be identified for all deployed applications. Have all cleartext passwords been removed from data sources? [Please reference Rule ID #113601 in /docs/JBossEAP5_Guide.html for more information] Instructions Review data source file located within JBOSS_HOME/server/deploy/ and subdirectories. Data sources with encrypted passwords will no longer have <user-name> or <password> elements, and will instead reference a <security-domain>. Have Java permissions for all deployed applications been documented and reviewed? [Please reference Rule ID #115901 in /docs/JBossEAP5_Guide.html for more information] Instructions >Review documentation for an application's permission requirements. Review policy files to determine if applications are in compliance with their documentation. Is the JBoss keystore password protected? [Please reference Rule ID #215801 in /docs/JBossEAP5_Guide.html for more information] Instructions Use the keytool command to list the contents of the JBoss keystore. Validate the requirement for a password prior to access to the keystore. Does a password file exist for the JBoss keystore that is accessible only to JBoss and JBoss administrators?? [Please reference Rule ID #216001 in /docs/JBossEAP5_Guide.html for more information] Instructions Review the JBoss security policy file to locate the JBoss keystore password file. Validate the existence of the file. Ensure only the JBoss process owner account and JBoss administrators have READ access to the file. Ensure the correct password for the JBoss keystore is in the file. Has console access been removed from the JBoss process owner? [Please reference Rule ID #109901 in /docs/JBossEAP5_Guide.html for more information] Instructions Due to space and formatting limitations under the OCIL specification, see the /docs/JBossEAP5_Guide.html for details. Do deployed production applications utilize SecurityDomains to protect resources? [Please reference Rule ID #110001 in /docs/JBossEAP5_Guide.html for more information] Instructions Due to space and formatting limitations under the OCIL specification, see the /docs/JBossEAP5_Guide.html for details. Are all files and folders under in JBOSS_HOME owned by the JBoss process owner account? [Please reference Rule ID #116201 in /docs/JBossEAP5_Guide.html for more information] Instructions Validate file ownership for JBOSS_HOME files and subdirectories . Owner is required to be the JBoss process owner account. The JBoss administrators may have group ownership for operating systems that support it. Have clear-text passwords been removed for all Tomcat Connectors? [Please reference Rule ID #116301 in /docs/JBossEAP5_Guide.html for more information] Instructions Review JBOSS_HOME/server/[PROFILE]/deploy/jbossweb.sar/server.xml for evidence of clear-text passwords in Connectors. These Connectors will contain a <attribute name="KeyStorePass"> or a keystorePass attribute as part of the <Connector> element, with a clear-text password. Has a comprehensive access control policy been created that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance? [Please reference Rule ID #116401 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators. Review all relevant documentation. Determine if an access control policy exists that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance. There should be an associated set of procedures with implementation details for specific tasks such as assigning user roles, creating user accounts, or assigning Java Security Manager permissions. Do JBoss administrators (or whomever performs regular log review), have access to a comprehensive audit policy and auditing procedures? [Please reference Rule ID #115301 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators. Review any available auditing documentation. Determine if the auditing policy is comprehensive and the auditing procedures are usable and up-to-date. Do regular backups of the JBoss configuration files and deployed applications occur at least once a week (or in accordance with organization documentation)? [Please reference Rule ID #114601 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators. Review backup policies, procedures, and other applicable documentation. Review backup media and validate presence of JBoss configuration files and deployed applications. Determine if JBoss configuration files and deployed applications are backed up at least once a week - or as specified by organization documentation. Have clear-text passwords been removed for all JBoss XML configuration files? [Please reference Rule ID #116501 in /docs/JBossEAP5_Guide.html for more information] Instructions Review configuration files for evidence of clear-text passwords. No clear-text passwords should exist in XML configuration files (password masking should be used instead). Is the Java Security Manager used by JBoss configured to load a password-protected keystore file? [Please reference Rule ID #206001 in /docs/JBossEAP5_Guide.html for more information] Instructions Search properties files loaded by Java Security Manager for valid keystore keystorePasswordURL properties. Do all deployed applications utilize FIPS compliant cryptography? [Please reference Rule ID #400801 in /docs/JBossEAP5_Guide.html for more information] Instructions Due to space and formatting limitations under the OCIL specification, see the /docs/JBossEAP5_Guide.html for details. Do all deployed applications requiring authentication utilize the DoD Public Key Infrastructure for authentication? [Please reference Rule ID #400701 in /docs/JBossEAP5_Guide.html for more information] Instructions Due to space and formatting limitations under the OCIL specification, see the /docs/JBossEAP5_Guide.html for details. Does the keystore used by JBoss contain the active DoD Certificate Authorities as trustedCertEntrys? [Please reference Rule ID #400601 in /docs/JBossEAP5_Guide.html for more information] Instructions Determine which keystore is being used by JBoss. List the contents of the keystore. Ensure all currently active DoD Certificate Authorities exist as trustedCertEntry. Do all deployed JBoss applications implementing encryption present valid X.509 certificates? [Please reference Rule ID #400501 in /docs/JBossEAP5_Guide.html for more information] Instructions Using a web browser or similar tool, access deployed JBoss applications that implement encryption and certificate exchange. Examine the X.509 certificate presented to the browser by the server. The certificate must match the domain name of the webserver being accessed. The certificate must not be expired. The certificate must be issued by a DoD approved Certificate Authority. The certificate must not be revoked. The certificate public key length must be at least 1024 bits. Do all deployed applications display classification banners as required by the appropriate classification guide or local security guidance? [Please reference Rule ID #300701 in /docs/JBossEAP5_Guide.html for more information] Instructions Access all deployed applications to determine if classification banners are displayed in accordance with the authoritative classification guide or local security policies. Is the JBoss process owner executing in accordance with the principle of least privilege? [Please reference Rule ID #400401 in /docs/JBossEAP5_Guide.html for more information] Instructions Work with the JBoss administrator to identify the JBoss process owner account. Work with the JBoss administrator to identify the permissions the JBoss process owner executes with. Determine if the JBoss process owner is executing with least privilege. Has the default Java cacerts keystore password been changed? [Please reference Rule ID #400301 in /docs/JBossEAP5_Guide.html for more information] Instructions Attempt to access the contents of the Java cacerts keystore at the default location (JAVA_HOME/lib/security/cacerts). Ensure the default password has been changed. Has the default JBoss Messaging MessageSucker password been changed? [Please reference Rule ID #400201 in /docs/JBossEAP5_Guide.html for more information] Instructions Review the Jboss Messaging configuration file for the Messaging ServerPeer. Ensure the <property name="suckerPassword" > has been changed from the default of "CHANGE ME!". Do JBoss installations in a production environment reside on dedicated operating systems? [Please reference Rule ID #400101 in /docs/JBossEAP5_Guide.html for more information] Instructions Interview JBoss administrators, review system documentation and architecture diagrams. Review applications hosted by the same operating system as JBoss. Determine if production environments host JBoss Enterprise Application Platform installations on dedicated operating systems. JBoss installations should not be hosted by the same operating system that may be hosting other organization resources such as name resolution servers, directory servers, or database servers. Do all deployed applications display a system use notification upon access? [Please reference Rule ID #300601 in /docs/JBossEAP5_Guide.html for more information] Instructions Access all deployed applications to determine if a warning banner is displayed. A code reviewing showing the functional code will also suffice.This warning banner should be presented to the user prior to accessing any deployed application - commercial applications, in-house applications, or applications deployed by JBoss. Has the organization defined password complexity requirements in a policy document? [Please reference Rule ID #300401 in /docs/JBossEAP5_Guide.html for more information] Instructions Work with JBoss administrators and security team members to identify and review relevant documentation. Password complexity requirements should be defined. The policy should not allow passwords to be reused or contain dictionary words. Has the organization defined password expiration requirements in a policy document? [Please reference Rule ID #300501 in /docs/JBossEAP5_Guide.html for more information] Instructions Work with JBoss administrators and security team members to identify and review relevant documentation. Password expiration requirements should be defined. Is evidence maintained of password changes for application or system accounts? [Please reference Rule ID #300501 in /docs/JBossEAP5_Guide.html for more information] Instructions Work with JBoss administrators and security team members to identify and review relevant documentation. Password expiration requirements should be defined. Has the organization defined password length requirements in a policy document? [Please reference Rule ID #300301 in /docs/JBossEAP5_Guide.html for more information] Instructions Work with JBoss administrators and security team members to identify and review relevant documentation. Minimum and maximum password lengths should be defined. Have default role assignments been removed, renamed, or commented out from jbossws-roles.properties, jmx-console-roles.properties, and messaging-roles.properties? [Please reference Rule ID #300201 in /docs/JBossEAP5_Guide.html for more information] Instructions Ensure the default role assignments have been removed, renamed, or commented out from the default properties files located in JBOSS_HOME/server/[PROFILE]/conf/props/ Have default user accounts been removed, renamed, or commented out from jbossws-users.properties, jmx-console-users.properties, and messaging-users.properties? [Please reference Rule ID #300101 in /docs/JBossEAP5_Guide.html for more information] Instructions Ensure the default user accounts in the default <application-policy> elements located within the configuration file: JBOSS_HOME/server/[PROFILE]/conf/login-config.xml have been removed, renamed, or commented out. scap-security-guide-0.1.31/JBossEAP5/eap5-oval.xml000066400000000000000000001747131301675746700214650ustar00rootroot00000000000000 5.4 2010-07-08T11:19:35.419-04:00 JBoss Enterprise Application Platform 5.1.0 EAP Version should be 5.1.0 JBoss Enterprise Application Platform 5.1.2 EAP Version should be 5.1.2 JBoss Enterprise Application Platform 5.1.1 EAP Version should be 5.1.1 JBoss Enterprise Application Platform 5.0.0 EAP Version should be 5.0.0 JBoss Enterprise Application Platform 5.0.1 EAP Version should be 5.0.1 Ensure JMX Console is either secured or removed Ensure JMX Console is either secured or removed Ensure Web Console is either secured or removed Ensure Web Console is either secured or removed Ensure Admin Console is either secured or removed Ensure Admin Console is either secured or removed SNMP must not be deployed SNMP must not be deployed Disable AJP from JBoss Web All AJP Connectors should be removed from JBOSS_HOME/server/production/deploy/jbossweb.sar/server.xml. Clustering High-Availability must be disabled Disable the HA Naming service interface via HTTP. Ensure Technology Preview components are disabled PicketLink technology preview folder should be deleted. Ensure all required information is displayed in Audit Logger The Security Audit Appender must log all identified information. The JMXInvokerServlet servlet must be configured to prevent unprivileged access using authentication The JMXInvokerServlet servlet must be configured to prevent unprivileged access using authN The JMXInvokerServlet servlet must be configured to prevent unprivileged access using authorization The jmx-invoker-service.xml is a service that exposes the JMX MBeanServer interface via an RMI compatible interface using the RMI/JRMP detached invoker service. Access control for authenticated users must be configured using the interceptors of either org.jboss.jmx.connector.invoker.RolesAuthorization or org.jboss.jmx.connector.invoker.ExternalizableRolesAuthorization. The JMXInvokerServlet servlet must be configured to prevent unprivileged access using authorization The jmx-invoker-service.xml is a service that exposes the JMX MBeanServer interface via an RMI compatible interface using the RMI/JRMP detached invoker service. Access control for authenticated users must be configured using the interceptors of either org.jboss.jmx.connector.invoker.RolesAuthorization or org.jboss.jmx.connector.invoker.ExternalizableRolesAuthorization. Ensure default HSQLDB is disabled All files for the default HSQLDB should be deleted. Ensure HSQLDB Security Domain is removed Security Domain for the default HSQLDB should be removed. Ensure Security Audit Appender is enabled The log4j configuration file must have an AUDIT appender uncommented. Ensure Security Audit Provider is enabled The log4j configuration file must have a security audit provider uncommented. Ensure Configure SecurityInterceptor logging level is set correctly SecurityInterceptor logging level should be set to TRACE and Reference the AUDIT Appender. Ensure logging is enabled for ServerImpl log messages Ensure logging is enabled for ServerImpl log messages. The JMXInvokerServlet servlet must be secured against web attacks The JMXInvokerServlet servlet must be secured against web attacks The allRolesMode must be configured appropriately The allRolesMode within JBOSS_HOME/server/production/deploy/jbossweb.sar/server.xml must be set to strict. This requires the authenticated user to be assigned to one of the web-app/security-role/role-name roles in order to be authorized. Configure Java Security Manager to use an environment specific policy The Java Security Manager is a crucial piece of the Java security infrastructure. JBoss Enterprise Application Platform should be configured to load a Java security policy that has been vetted for use in the environment. This precludes the use of the simple default policy that ships with JBoss, but does not preclude the use of preconfigured policy files like the security policy designed for use in a Common Criteria environment (See JBoss Common Criteria Configuration Guide for details). Production applications should not log output to the JBoss console Disable Hot Deployment in production DefaultCacheTimeout must be configured properly JBOSS_HOME boot.log Release ID: JBoss \[EAP\] ([0-9\.]{3,5}) 1 boot.log Release ID: JBoss \[EAP\] ([0-9\.]{3,5}) 1 boot.log Release ID: JBoss \[EAP\] ([0-9\.]{3,5}) 1 boot.log Release ID: JBoss \[EAP\] ([0-9\.]{3,5}) 1 boot.log Release ID: JBoss \[EAP\] ([0-9\.]{3,5}) 1 boot.log Release ID: JBoss \[EAP\] ([0-9\.]{3,5}) 1 jboss-web.xml boolean(/jboss-web/security-domain/text()) jboss-web.xml boolean(/jboss-web/security-domain/text()) jboss-web.xml boolean(/jboss-web/security-domain/text()) server.xml boolean(/Server/Service/Connector[contains(@protocol,'AJP')]/@protocol) server.xml boolean(/Server/Service[@name='jboss.web']/Engine[@name='jboss.web']/Realm[@className='org.jboss.web.tomcat.security.JBossWebRealm' and @certificatePrincipal='org.jboss.security.auth.certs.SubjectDNMapping']) hajndi-jboss-beans.xml jboss-log4j.xml /log4j:configuration/appender[@name="AUDIT"]/layout[@class="org.apache.log4j.PatternLayout"]/param[@name="ConversionPattern"]/@value jmx-invoker-service.xml boolean(/server/mbean/xmbean/operation[contains(name,'invoke')]/descriptors/interceptors/interceptor[@code='org.jboss.jmx.connector.invoker.AuthenticationInterceptor' and @securityDomain='java:/jaas/jmx-console']) login-config.xml /policy/application-policy[@name='jmx-console']/authentication/login-module[@code='org.jboss.security.auth.spi.UsersRolesLoginModule' and @flag='required']/module-option[@name='usersProperties']/text() login-config.xml /policy/application-policy[@name='jmx-console']/authentication/login-module[@code='org.jboss.security.auth.spi.UsersRolesLoginModule' and @flag='required']/module-option[@name='rolesProperties']/text() jmx-invoker-service.xml boolean(/server/mbean/xmbean/operation[contains(name,'invoke')]/descriptors/interceptors/interceptor[@code='org.jboss.jmx.connector.invoker.AuthorizationInterceptor' and @authorizingClass='org.jboss.jmx.connector.invoker.RolesAuthorization']) login-config.xml /policy/application-policy[@name='jmx-console']/authentication/login-module[@code='org.jboss.security.auth.spi.UsersRolesLoginModule' and @flag='required']/module-option[@name='usersProperties']/text() login-config.xml /policy/application-policy[@name='jmx-console']/authentication/login-module[@code='org.jboss.security.auth.spi.UsersRolesLoginModule' and @flag='required']/module-option[@name='rolesProperties']/text() hsqldb-ds.xml hsqldb.jarl hsqldb-plugin.jar hsqldb-persistence-service.xml login-config.xml boolean(/policy/application-policy[@name="HsqlDbRealm"]/@name) jboss-log4j.xml boolean(/log4j:configuration/appender[@name="AUDIT"]/@name) jboss-log4j.xml boolean(/log4j:configuration/category[@name="org.jboss.security.audit.providers.LogAuditProvider"]/@name) jboss-log4j.xml boolean(/log4j:configuration/category[@name="org.jboss.ejb.plugins.SecurityInterceptor"]/priority[@value="TRACE"]/@value) jboss-log4j.xml boolean(/log4j:configuration/category[@name="org.jboss.ejb.plugins.SecurityInterceptor"]/appender-ref[@ref="AUDIT"]/@ref) jboss-log4j.xml boolean(/log4j:configuration/category[@name="org.jboss.bootstrap.microcontainer"]/priority[@value="INFO"]/@value) jboss-log4j.xml boolean(/log4j:configuration/category[@name="org.jboss.bootstrap.microcontainer"]/appender-ref[@ref="AUDIT"]/@ref) web.xml boolean(/web-app/security-constraint/web-resource-collection[contains(http-method,'GET')]) web.xml boolean(/web-app/security-constraint/web-resource-collection[contains(http-method,'POST')]) server.xml /Server/Service/Engine[@name="jboss.web"]/Realm/@allRolesMode run.conf ((?:#*)JAVA_OPTS="\$JAVA_OPTS -Djava\.security\.manager -Djava\.security\.policy==.*") 1 jboss-log4j.xml boolean(/log4j:configuration/root/appender-ref[@ref='CONSOLE']/@ref) hdscanner-jboss-beans.xml jboss-service.xml /server/mbean[@code='org.jboss.security.plugins.JaasSecurityManagerService' and @name='jboss.security:service=JaasSecurityManager']/attribute[@name='DefaultCacheTimeout']/text() 5.1.0 5.1.2 5.1.1 5.0.0 5.0.1 5.1.0 5.1.1 true true true false true %d %-5p [%c] (%t:%x) %m%n false true true true true true true false false true props/jmx-console-users.properties props/jmx-console-roles.properties true props/jmx-console-users.properties props/jmx-console-roles.properties strict ((?:#*)JAVA_OPTS="\$JAVA_OPTS -Djava\.security\.manager -Djava\.security\.policy==.*") false 1800 production /server/ /log /server/ /deploy /snmp-adaptor.sar /cluster /../picketlink /messaging /common/lib /server/ /conf /server/ /lib /jbossweb.sar /httpha-invoker.sar/invoker.war/WEB-INF/ /server/ /deployers /jbossweb.deployer/META-INF /jmx-console.war /admin-console.war /management /WEB-INF /WEB-INF /console-mgr.sar/web-console.war/WEB-INF /httpha-invoker.sar/META-INF /bin scap-security-guide-0.1.31/JBossEAP5/eap5-xccdf.xml000066400000000000000000012306141301675746700216050ustar00rootroot00000000000000 accepted Security Benchmark JBoss Enterprise Application Platform 5.x This XCCDF benchmark is used for evaluating the security of Red Hat JBoss Enterprise Application Platform 5.x. This content was developed by Red Hat, Inc. for use by JBoss Enterprise Application Platform 5.x Administrators and is released under the Public Domain License. JBoss Enterprise Application Platform is a popular Java Enterprise Edition application server platform by Red Hat. It is based on the open-source JBoss Application Server, Community Edition. Leveraging robust container architecture, JBoss EAP is capable of hosting a wide variety of applications - anything from simple, static HTML pages all the way to distributed, transaction-based Java Enterprise Edition applications. JBoss EAP is known for being dependable, fast, flexible, and cost-effective. This benchmark provides security guidance on JBoss EAP 5 running on Red Hat Enterprise Linux. OVAL content for this benchmark to be run on other platforms is in development. This document assumes that the reader is familiar with JBoss EAP 5 and Red Hat Enterprise Linux administration. This document also assumes that the baseline configuration of the operating system and JBoss EAP 5 are up-to-date in terms of installed patches. The content within this benchmark was tested for compatibility with multiple SCAP tools on Red Hat Enterprise Linux 5 and 6. The following compatibility matrix shows our results: XCCDFExec v1.1.4 Build 19 SPAWAR Compliance Checker v3.0.3 OpenSCAP v0.8.2 RHEL 5 - i386 Fully Compatible Fully Compatible Fully Compatible RHEL 5 - x86_64 Fully Compatible Fully Compatible Fully Compatible RHEL 6 - i386 Additional Dependencies Needed Fully Compatible Fully Compatible RHEL 6 - x86_64 Additional Dependencies Needed Fully Compatible Fully Compatible The recommendations included in this benchmark have been derived from various government and industry sources. All rules include a rationale, validation instructions (for OCIL rules), remediation instructions, references, risk assessments, and NIST/DoD Control mappings. For additional information regarding the JBoss EAP 5 SCAP benchmark, please visit https://fedorahosted.org/scap-security-guide/ You may also contact the authors: Bryan Saunders Tim Falls James Lopez Kenneth Peeples v1.0 Security Benchmark JBoss Enterprise Application Platform 5.x Timothy Falls Bryan Saunders Kenny Peeples James Lopez Red Hat security for JBoss Enterprise Application Platform (EAP), version 5 Jason Wong Jesse Sightler JBoss Enterprise Application Platform 5 Security Guide, 2011 Mallik, R. (2011, May). Jboss in the Trenches. Jboss 6.x Tuning/Slimming. (October 21, 2011). In JBossAS. Retrieved May 1, 2012, from https://community.jboss.org/wiki/JBoss6xTuningSlimming DeCoste, W. (2011). Slim, Trim, Prune JBoss Enterprise Application Platform. Retrieved from https://access.redhat.com/sites/default/files/slimtrimpruneeap.pdf U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Recommended security controls for federal information systems and organizations (800-53). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Guide to Enterprise Password Management (Draft) (800-118). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html U.S. Department of Commerce, National Institute of Standards and Technology. (2009). Guidelines on Securing Public Web Servers (800-44). Retrieved from website: http://csrc.nist.gov/publications/PubsSPs.html JBoss Enterprise Application Platform 5 - Department of Defense Profile for testing a secure deployment of JBoss EAP 5 in a DoD environment. JBoss Fuse 6 Profile for testing a secure deployment of JBoss Fuse 6.x. scap-security-guide-0.1.31/JRE/templates/000077500000000000000000000000001301675746700201205ustar00rootroot00000000000000scap-security-guide-0.1.31/JRE/templates/static/000077500000000000000000000000001301675746700214075ustar00rootroot00000000000000scap-security-guide-0.1.31/JRE/templates/static/bash/000077500000000000000000000000001301675746700223245ustar00rootroot00000000000000scap-security-guide-0.1.31/JRE/templates/static/bash/java_jre_deployment_config_exists.sh000066400000000000000000000004571301675746700316330ustar00rootroot00000000000000# platform = Java Runtime Environment JAVA_CONFIG="/etc/.java/deployment/deployment.config" JAVA_DIR="/etc/.java/deployment" if [ ! -d ${JAVA_DIR} ] ; then mkdir -p -m 755 ${JAVA_DIR} fi if [ ! -e ${JAVA_CONFIG} ]; then touch ${JAVA_CONFIG} && chmod 644 ${JAVA_CONFIG} fi chmod 644 ${JAVA_CONFIG}scap-security-guide-0.1.31/JRE/templates/static/bash/java_jre_deployment_config_mandatory.sh000066400000000000000000000005611301675746700323060ustar00rootroot00000000000000# platform = Java Runtime Environment JAVA_CONFIG="/etc/.java/deployment/deployment.config" grep -q "^deployment.system.config.mandatory=false$" ${JAVA_CONFIG} && \ sed -i "s/deployment.system.config.mandatory=.*/deployment.system.config.mandatory=false/g" ${JAVA_CONFIG} if ! [ $? -eq 0 ] ; then echo "deployment.system.config.mandatory=false" >> ${JAVA_CONFIG} fi scap-security-guide-0.1.31/JRE/templates/static/bash/java_jre_deployment_config_properties.sh000066400000000000000000000007011301675746700325000ustar00rootroot00000000000000# platform = Java Runtime Environment JAVA_CONFIG="/etc/.java/deployment/deployment.config" JAVA_PROPERTIES="/etc/.java/deployment/deployment.properties" grep -q "^deployment.system.config=file://${JAVA_CONFIG}$" ${JAVA_CONFIG} && \ sed -i "s;deployment.system.config=.*;deployment.system.config=file:\/\/${JAVA_PROPERTIES};g" ${JAVA_CONFIG} if ! [ $? -eq 0 ] ; then echo "deployment.system.config=file://${JAVA_PROPERTIES}" >> ${JAVA_CONFIG} fi scap-security-guide-0.1.31/JRE/templates/static/bash/java_jre_deployment_properties_exists.sh000066400000000000000000000005101301675746700325500ustar00rootroot00000000000000# platform = Java Runtime Environment JAVA_PROPERTIES="/etc/.java/deployment/deployment.properties" JAVA_DIR="/etc/.java/deployment" if [ ! -d ${JAVA_DIR} ] ; then mkdir -p -m 755 ${JAVA_DIR} fi if [ ! -e ${JAVA_PROPERTIES} ]; then touch ${JAVA_PROPERTIES} && chmod 644 ${JAVA_PROPERTIES} fi chmod 644 ${JAVA_PROPERTIES} scap-security-guide-0.1.31/JRE/templates/static/bash/java_jre_untrusted_sources.sh000066400000000000000000000006441301675746700303250ustar00rootroot00000000000000# platform = Java Runtime Environment JAVA_PROPERTIES="/etc/.java/deployment/deployment.properties" grep -q "^deployment.security.askgrantdialog.notinca=false$" ${JAVA_PROPERTIES} && \ sed -i "s/deployment.security.askgrantdialog.notinca=.*/deployment.security.askgrantdialog.notinca=false/g" ${JAVA_PROPERTIES} if ! [ $? -eq 0 ] ; then echo "deployment.security.askgrantdialog.notinca=false" >> ${JAVA_PROPERTIES} fiscap-security-guide-0.1.31/JRE/templates/static/bash/java_jre_untrusted_sources_locked.sh000066400000000000000000000006511301675746700316440ustar00rootroot00000000000000# platform = Java Runtime Environment JAVA_PROPERTIES="/etc/.java/deployment/deployment.properties" grep -q "^deployment.security.askgrantdialog.notinca.locked$" ${JAVA_PROPERTIES} && \ sed -i "s/deployment.security.askgrantdialog.notinca\..*/deployment.security.askgrantdialog.notinca.locked/g" ${JAVA_PROPERTIES} if ! [ $? -eq 0 ] ; then echo "deployment.security.askgrantdialog.notinca.locked" >> ${JAVA_PROPERTIES} fi scap-security-guide-0.1.31/JRE/templates/static/bash/java_jre_validation_crl.sh000066400000000000000000000006011301675746700275100ustar00rootroot00000000000000# platform = Java Runtime Environment JAVA_PROPERTIES="/etc/.java/deployment/deployment.properties" grep -q "^deployment.security.validation.crl=true$" ${JAVA_PROPERTIES} && \ sed -i "s/deployment.security.validation.crl=.*/deployment.security.validation.crl=true/g" ${JAVA_PROPERTIES} if ! [ $? -eq 0 ] ; then echo "deployment.security.validation.crl=true" >> ${JAVA_PROPERTIES} fiscap-security-guide-0.1.31/JRE/templates/static/bash/java_jre_validation_crl_locked.sh000066400000000000000000000006111301675746700310320ustar00rootroot00000000000000# platform = Java Runtime Environment JAVA_PROPERTIES="/etc/.java/deployment/deployment.properties" grep -q "^deployment.security.validation.crl.locked$" ${JAVA_PROPERTIES} && \ sed -i "s/deployment.security.validation.crl\..*/deployment.security.validation.crl.locked/g" ${JAVA_PROPERTIES} if ! [ $? -eq 0 ] ; then echo "deployment.security.validation.crl.locked" >> ${JAVA_PROPERTIES} fi scap-security-guide-0.1.31/JRE/templates/static/bash/java_jre_validation_ocsp.sh000066400000000000000000000006051301675746700277000ustar00rootroot00000000000000# platform = Java Runtime Environment JAVA_PROPERTIES="/etc/.java/deployment/deployment.properties" grep -q "^deployment.security.validation.ocsp=true$" ${JAVA_PROPERTIES} && \ sed -i "s/deployment.security.validation.ocsp=.*/deployment.security.validation.ocsp=true/g" ${JAVA_PROPERTIES} if ! [ $? -eq 0 ] ; then echo "deployment.security.validation.ocsp=true" >> ${JAVA_PROPERTIES} fiscap-security-guide-0.1.31/JRE/templates/static/bash/java_jre_validation_ocsp_locked.sh000066400000000000000000000006151301675746700312220ustar00rootroot00000000000000# platform = Java Runtime Environment JAVA_PROPERTIES="/etc/.java/deployment/deployment.properties" grep -q "^deployment.security.validation.ocsp.locked$" ${JAVA_PROPERTIES} && \ sed -i "s/deployment.security.validation.ocsp\..*/deployment.security.validation.ocsp.locked/g" ${JAVA_PROPERTIES} if ! [ $? -eq 0 ] ; then echo "deployment.security.validation.ocsp.locked" >> ${JAVA_PROPERTIES} fi scap-security-guide-0.1.31/JRE/transforms/000077500000000000000000000000001301675746700203205ustar00rootroot00000000000000scap-security-guide-0.1.31/JRE/transforms/cce_extract.py000077500000000000000000000003521301675746700231610ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import cce_extract_module if __name__ == "__main__": cce_extract_module.main() scap-security-guide-0.1.31/JRE/transforms/cci2html.xsl000066400000000000000000000004661301675746700225630ustar00rootroot00000000000000 scap-security-guide-0.1.31/JRE/transforms/constants.xslt000066400000000000000000000021641301675746700232530ustar00rootroot00000000000000 Java Runtime Environment JRE JRE_STIG jre empty JRE cpe:/a:oracle:jre:,cpe:/a:sun:jre:,cpe:/a:redhat:openjdk:,cpe:/a:ibm:jre: scap-security-guide-0.1.31/JRE/transforms/shorthand2xccdf.xslt000066400000000000000000000005101301675746700243140ustar00rootroot00000000000000 unknown unlinked-jre-oval.xml scap-security-guide-0.1.31/JRE/transforms/splitchecks.py000077500000000000000000000003521301675746700232110ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import splitchecks_module if __name__ == "__main__": splitchecks_module.main() scap-security-guide-0.1.31/JRE/transforms/table-add-srgitems.xslt000066400000000000000000000010711301675746700247030ustar00rootroot00000000000000 scap-security-guide-0.1.31/JRE/transforms/table-sortbyref.xslt000066400000000000000000000005551301675746700243450ustar00rootroot00000000000000 scap-security-guide-0.1.31/JRE/transforms/table-srgmap.xslt000066400000000000000000000011401301675746700236060ustar00rootroot00000000000000 scap-security-guide-0.1.31/JRE/transforms/table-style.xslt000066400000000000000000000002511301675746700234570ustar00rootroot00000000000000 scap-security-guide-0.1.31/JRE/transforms/xccdf-alt-titles.xslt000066400000000000000000000005021301675746700244000ustar00rootroot00000000000000 scap-security-guide-0.1.31/JRE/transforms/xccdf-apply-overlay-stig.xslt000066400000000000000000000007511301675746700260740ustar00rootroot00000000000000 scap-security-guide-0.1.31/JRE/transforms/xccdf-removeaux.xslt000066400000000000000000000005011301675746700243300ustar00rootroot00000000000000 scap-security-guide-0.1.31/JRE/transforms/xccdf2csv-stig.py000077500000000000000000000003601301675746700235250ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import xccdf2csv_stig_module if __name__ == "__main__": xccdf2csv_stig_module.main() scap-security-guide-0.1.31/JRE/transforms/xccdf2html.xslt000066400000000000000000000005501301675746700232720ustar00rootroot00000000000000 scap-security-guide-0.1.31/JRE/transforms/xccdf2shorthand.xslt000066400000000000000000000005011301675746700243140ustar00rootroot00000000000000 scap-security-guide-0.1.31/JRE/transforms/xccdf2stigformat.xslt000066400000000000000000000006751301675746700245150ustar00rootroot00000000000000 scap-security-guide-0.1.31/JRE/transforms/xccdf2table-byref.xslt000066400000000000000000000006741301675746700245310ustar00rootroot00000000000000 scap-security-guide-0.1.31/JRE/transforms/xccdf2table-cce.xslt000066400000000000000000000007331301675746700241500ustar00rootroot00000000000000 scap-security-guide-0.1.31/JRE/transforms/xccdf2table-profileccirefs.xslt000066400000000000000000000015671301675746700264230ustar00rootroot00000000000000 scap-security-guide-0.1.31/JRE/transforms/xccdf2table-profilecisrefs.xslt000066400000000000000000000007051301675746700264340ustar00rootroot00000000000000 scap-security-guide-0.1.31/JRE/transforms/xccdf2table-profilenistrefs.xslt000066400000000000000000000007051301675746700266330ustar00rootroot00000000000000 scap-security-guide-0.1.31/JRE/transforms/xccdf2table-stig.xslt000066400000000000000000000006731301675746700243670ustar00rootroot00000000000000 scap-security-guide-0.1.31/JRE/utils/000077500000000000000000000000001301675746700172625ustar00rootroot00000000000000scap-security-guide-0.1.31/JRE/utils/README000066400000000000000000000007741301675746700201520ustar00rootroot00000000000000This file is meant to give a quick overview to some of the scripts located in this directory. verify-input-sanity.py Purpose: This script can be invoked without arguments to examine the files within src/input to make sure that they are in good shape *prior to* building the XCCDF and OVAL content with the various make commands. Intent: Help XCCDF and OVAL developers spot common mistakes *before* utilizing the Makefile to build the XCCDF and OVAL content. Usage: ./verify-input-sanity.py scap-security-guide-0.1.31/JRE/utils/sync-alt-titles.py000077500000000000000000000003621301675746700226740ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import sync_alt_titles_module if __name__ == "__main__": sync_alt_titles_module.main() scap-security-guide-0.1.31/JRE/utils/verify-cce.py000077500000000000000000000003501301675746700216710ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import verify_cce_module if __name__ == "__main__": verify_cce_module.main() scap-security-guide-0.1.31/LICENSE000066400000000000000000000030751301675746700165140ustar00rootroot00000000000000Files in this project are works of the US Government and cannot be copyrighted, unless explicitly stated otherwise. Files with certain copyrights (as permitted by the Fedora Project Contributor Agreement) may be added but should be identified as such. This is free and unencumbered software released into the public domain. Anyone is free to copy, modify, publish, use, compile, sell, or distribute this software, either in source code form or as a compiled binary, for any purpose, commercial or non-commercial, and by any means. In jurisdictions that recognize copyright laws, the author or authors of this software dedicate any and all copyright interest in the software to the public domain. We make this dedication for the benefit of the public at large and to the detriment of our heirs and successors. We intend this dedication to be an overt act of relinquishment in perpetuity of all present and future rights to this software under copyright law. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. For more information, please refer to: http://unlicense.org http://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement http://www.cendi.gov/publications/04-8copyright.html#toc30 scap-security-guide-0.1.31/Makefile000066400000000000000000000275241301675746700171540ustar00rootroot00000000000000include VERSION # Define RHEL6 / JBossEAP5 specific variables below ROOT_DIR ?= $(CURDIR) RPMBUILD ?= $(ROOT_DIR)/rpmbuild RPM_SPEC := $(ROOT_DIR)/scap-security-guide.spec PKGNAME := $(SSG_PROJECT_NAME) OS_DIST := $(shell rpm --eval '%{dist}') ARCH := noarch RPMBUILD_ARGS := --define '_topdir $(RPMBUILD)' --define '_tmppath $(RPMBUILD)' DATESTR:=$(shell date -u +'%Y%m%d%H%M') RPM_DATESTR := $(shell date -u +'%a %b %d %Y') ifeq ($(SSG_VERSION_IS_GIT_SNAPSHOT),"yes") GIT_VERSION:=$(shell git show --pretty=format:"%h" --stat HEAD 2>/dev/null|head -1) ifneq ($(GIT_VERSION),) SSG_VERSION=$(SSG_MAJOR_VERSION).$(SSG_MINOR_VERSION).$(SSG_RELEASE_VERSION).$(DATESTR)GIT$(GIT_VERSION) endif # in a git tree and git returned a version endif # git ifndef SSG_VERSION SSG_VERSION=$(SSG_MAJOR_VERSION).$(SSG_MINOR_VERSION) endif PKG := $(PKGNAME)-$(SSG_VERSION) TARBALL = $(RPMBUILD)/SOURCES/$(PKG).tar.gz PREFIX=$(DESTDIR)/usr DATADIR=share MANDIR=$(DATADIR)/man DOCDIR=$(DATADIR)/doc # Define custom canned sequences / macros below # Define Makefile targets below all: validate-buildsystem fedora rhel5 rhel6 rhel7 rhel-osp7 rhevm3 webmin firefox jre chromium debian8 wrlinux dist: chromium-dist firefox-dist fedora-dist jre-dist rhel6-dist rhel7-dist rhel-osp7-dist debian8-dist wrlinux-dist jenkins: all validate dist fedora: cd Fedora/ && $(MAKE) fedora-dist: cd Fedora/ && $(MAKE) dist rhel5: cd RHEL/5/ && $(MAKE) rhel6: cd RHEL/6/ && $(MAKE) rhel6-dist: cd RHEL/6/ && $(MAKE) dist rhel7: cd RHEL/7/ && $(MAKE) rhel7-dist: cd RHEL/7/ && $(MAKE) dist debian8: cd Debian/8/ && $(MAKE) debian8-dist: cd Debian/8/ && $(MAKE) dist ubuntu1604: cd Ubuntu/16.04/ && $(MAKE) ubuntu1604-dist: cd Ubuntu/16.04/ && $(MAKE) dist wrlinux: cd WRLinux/ && $(MAKE) wrlinux-dist: cd WRLinux/ && $(MAKE) dist rhel-osp7: cd OpenStack/RHEL-OSP/7 && $(MAKE) rhel-osp7-dist: cd OpenStack/RHEL-OSP/7 && $(MAKE) dist rhevm3: cd RHEVM3 && $(MAKE) jre: cd JRE/ && $(MAKE) jre-dist: cd JRE/ && $(MAKE) dist firefox: cd Firefox/ && $(MAKE) firefox-dist: cd Firefox/ && $(MAKE) dist webmin: cd Webmin/ && $(MAKE) chromium: cd Chromium/ && $(MAKE) chromium-dist: cd Chromium/ && $(MAKE) dist opensuse: cd OpenSUSE/ && $(MAKE) opensuse-dist: cd OpenSUSE && $(MAKE) dist suse11: cd SUSE/11 && $(MAKE) suse11-dist: cd SUSE/11 && $(MAKE) dist suse12: cd SUSE/12 && $(MAKE) suse12-dist: cd SUSE/12 && $(MAKE) dist validate-buildsystem: for makefile in `find -name Makefile`; do \ if grep '[[:space:]]\+$$' $$makefile; then \ echo "Trailing Whitespace in $$makefile"; \ exit 1; \ fi \ done validate-wrlinux: wrlinux # Enable below when content validates correctly # cd WRLinux/ && $(MAKE) validate validate-fedora: fedora cd Fedora/ && $(MAKE) validate validate-rhel5: rhel5 cd RHEL/5/ && $(MAKE) validate validate-rhel6: rhel6 cd RHEL/6/ && $(MAKE) validate validate-rhel7: rhel7 cd RHEL/7/ && $(MAKE) validate validate-debian8: debian8 validate-ubuntu1604: ubuntu1604 # Enable below when content validates correctly #cd Debian/8/ && $(MAKE) validate validate-rhel-osp7: rhel-osp7 cd OpenStack/RHEL-OSP/7/ && $(MAKE) validate validate-rhevm3: rhevm3 # Enable below when content validates correctly #cd RHEVM3 && $(MAKE) validate validate-chromium: chromium cd Chromium/ && $(MAKE) validate validate-firefox: firefox cd Firefox/ && $(MAKE) validate validate-jre: jre cd JRE/ && $(MAKE) validate validate-opensuse: opensuse # Enable below when content validates correctly #cd OpenSUSE/ && $(MAKE) validate validate-suse11: suse11 # Enable below when content validates correctly #cd SUSE/11 && $(MAKE) validate validate-suse12: suse12 # Enable below when content validates correctly #cd SUSE/12 && $(MAKE) validate validate: validate-fedora validate-rhel5 validate-rhel6 validate-rhel7 validate-debian8 validate-ubuntu1604 validate-wrlinux validate-rhel-osp7 validate-rhevm3 validate-chromium validate-firefox validate-jre tarball: @# Copy in the source trees for both RHEL @# and JBossEAP5 content mkdir -p tarball/$(PKG) cp Makefile tarball/$(PKG)/ cp BUILD.md Contributors.md LICENSE VERSION README.md tarball/$(PKG)/ cp -r config/ tarball/$(PKG) cp -r docs/ tarball/$(PKG) cp -r shared/ tarball/$(PKG) cp -r --preserve=links --parents Chromium/ tarball/$(PKG) cp -r --preserve=links --parents Debian/ tarball/$(PKG) cp -r --preserve=links --parents Fedora/ tarball/$(PKG) cp -r --preserve=links --parents Firefox/ tarball/$(PKG) cp -r --preserve=links --parents JBoss/ tarball/$(PKG) cp -r --preserve=links --parents JBossEAP5/ tarball/$(PKG) cp -r --preserve=links --parents JBossFuse6/ tarball/$(PKG) cp -r --preserve=links --parents JRE/ tarball/$(PKG) cp -r --preserve=links --parents OpenStack/ tarball/$(PKG) cp -r --preserve=links --parents OpenSUSE/ tarball/$(PKG) cp -r --preserve=links --parents RHEL/ tarball/$(PKG) cp -r --preserve=links --parents RHEVM3/ tarball/$(PKG) cp -r --preserve=links --parents SUSE/ tarball/$(PKG) cp -r --preserve=links --parents Webmin/ tarball/$(PKG) cp -r --preserve=links --parents WRLinux/ tarball/$(PKG) @# Don't trust the developers, clean out the build @# environment before packaging (cd tarball/$(PKG)/RHEL/5/ && $(MAKE) clean) (cd tarball/$(PKG)/RHEL/6/ && $(MAKE) clean) (cd tarball/$(PKG)/RHEL/7/ && $(MAKE) clean) (cd tarball/$(PKG)/Debian/8/ && $(MAKE) clean) (cd tarball/$(PKG)/WRLinux/ && $(MAKE) clean) (cd tarball/$(PKG)/Fedora/ && $(MAKE) clean) (cd tarball/$(PKG)/Chromium/ && $(MAKE) clean) (cd tarball/$(PKG)/JRE/ && $(MAKE) clean) (cd tarball/$(PKG)/Firefox/ && $(MAKE) clean) (cd tarball/$(PKG)/Webmin/ && $(MAKE) clean) cd tarball && tar -czf $(PKG).tar.gz $(PKG) @echo "Tarball is ready at tarball/$(PKG).tar.gz" rpmroot: mkdir -p $(RPMBUILD)/BUILD mkdir -p $(RPMBUILD)/RPMS mkdir -p $(RPMBUILD)/SOURCES mkdir -p $(RPMBUILD)/SPECS mkdir -p $(RPMBUILD)/SRPMS mkdir -p $(RPMBUILD)/ZIPS mkdir -p $(RPMBUILD)/BUILDROOT zipfile: dist @# ZIP only contains source datastreams and kickstarts, people who @# want sources to build from should get the tarball instead. rm -rf zipfile/$(PKG) mkdir -p zipfile/$(PKG) cp README.md zipfile/$(PKG)/ cp Contributors.md zipfile/$(PKG)/ cp LICENSE zipfile/$(PKG)/ cp */dist/content/*-ds.xml zipfile/$(PKG)/ cp */*/dist/content/*-ds.xml zipfile/$(PKG)/ cp */*/*/dist/content/*-ds.xml zipfile/$(PKG)/ mkdir zipfile/$(PKG)/kickstart cp RHEL/{6,7}/kickstart/*-ks.cfg zipfile/$(PKG)/kickstart/ (cd zipfile && zip -r $(PKG).zip $(PKG)/) @echo "ZIP file is ready at zipfile/$(PKG).zip" version-update: @echo -e "\nUpdating $(RPM_SPEC) version, release, and changelog..." sed -e s/__NAME__/$(PKGNAME)/ \ $(RPM_SPEC).in > $(RPM_SPEC) sed -i s/__VERSION__/$(SSG_VERSION)/ \ $(RPM_SPEC) sed -i s/__RELEASE__/$(SSG_RELEASE_VERSION)/ \ $(RPM_SPEC) sed -i 's/__DATE__/$(SSG_RELEASE_DATE)/' \ $(RPM_SPEC) sed -i 's/__REL_MANAGER__/$(SSG_REL_MANAGER)/' \ $(RPM_SPEC) sed -i 's/__REL_MANAGER_MAIL__/$(SSG_REL_MANAGER_MAIL)/' \ $(RPM_SPEC) srpm: tarball version-update rpmroot cat $(RPM_SPEC) > $(RPMBUILD)/SPECS/$(notdir $(RPM_SPEC)) cp tarball/$(PKG).tar.gz $(RPMBUILD)/SOURCES/ @echo -e "\nBuilding $(PKGNAME) SRPM..." cd $(RPMBUILD) && rpmbuild $(RPMBUILD_ARGS) --target=$(ARCH) -bs SPECS/$(notdir $(RPM_SPEC)) --nodeps rpm: srpm @echo -e "\nBuilding $(PKGNAME) RPM..." cd $(RPMBUILD)/SRPMS && rpmbuild --rebuild --target=$(ARCH) $(RPMBUILD_ARGS) --buildroot $(RPMBUILD)/BUILDROOT -bb $(PKG)-$(SSG_RELEASE_VERSION)$(OS_DIST).src.rpm git-tag: @echo -e "\nUpdating $(RPM_SPEC) changelog to reflect new release" sed -i '/\%changelog/{n;s/__DATE__/$(RPM_DATESTR)/}' $(RPM_SPEC).in sed -i '/\%changelog/{n;s/__REL_MANAGER__/$(SSG_REL_MANAGER)/}' $(RPM_SPEC).in sed -i '/\%changelog/{n;s/__REL_MANAGER_MAIL__/$(SSG_REL_MANAGER_MAIL)/}' $(RPM_SPEC).in sed -i '/\%changelog/{n;s/__VERSION__/$(SSG_VERSION)/}' $(RPM_SPEC).in sed -i '/\%changelog/{n;s/__RELEASE__/$(SSG_RELEASE_VERSION)/}' $(RPM_SPEC).in sed -i '/new/{s/__VERSION__/$(SSG_VERSION)/}' $(RPM_SPEC).in sed -i '/\%changelog/a\* __DATE__ __REL_MANAGER__ <__REL_MANAGER_MAIL__> __VERSION__-__RELEASE__\n- Make new __VERSION__ release\n' $(RPM_SPEC).in @echo -e "\nTagging $(PKGNAME) to new release $(NEW_RELEASE)" $(eval NEW_RELEASE:=$(shell git describe $(git rev-list --tags --max-count=1) | awk -F . '{printf "%s.%i.%i", $$1, $$2, $$3 + 1}' | sed 's/^.//')) $(eval NEW_MINOR_RELEASE:=$(shell echo $(NEW_RELEASE) | awk -F . '{printf "%i", $$3}')) @echo -e "\nUpdating VERSION to new minor release $(NEW_RELEASE)" sed -i 's/SSG_MINOR_VERSION.*/SSG_MINOR_VERSION = $(NEW_MINOR_RELEASE)/' $(ROOT_DIR)/VERSION sed -i 's/SSG_RELEASE_DATE.*/SSG_RELEASE_DATE = $(RPM_DATESTR)/' $(ROOT_DIR)/VERSION @echo -e "\nTagging to new release $(NEW_RELEASE)" git add $(RPM_SPEC).in $(ROOT_DIR)/VERSION git commit -m "Make new $(NEW_RELEASE) release" git tag -a -m "Version $(NEW_RELEASE)" v$(NEW_RELEASE) clean: rm -rf $(RPMBUILD) rm -rf tarball/ rm -rf zipfile/ rm -rf shared/output cd RHEL/5 && $(MAKE) clean cd RHEL/6 && $(MAKE) clean cd RHEL/7 && $(MAKE) clean cd Debian/8 && $(MAKE) clean cd WRLinux && $(MAKE) clean cd OpenStack/RHEL-OSP/7 && $(MAKE) clean cd RHEVM3 && $(MAKE) clean cd Fedora && $(MAKE) clean cd JRE && $(MAKE) clean cd Firefox && $(MAKE) clean cd Webmin && $(MAKE) clean cd Chromium && $(MAKE) clean rm -f scap-security-guide.spec install: dist install -d $(PREFIX)/$(DATADIR)/scap/ssg install -d $(PREFIX)/$(DATADIR)/scap-security-guide install -d $(PREFIX)/$(DATADIR)/scap-security-guide/kickstart install -d $(PREFIX)/$(MANDIR)/en/man8/ install -d $(PREFIX)/$(DOCDIR)/scap-security-guide/guides install -d $(PREFIX)/$(DOCDIR)/scap-security-guide/tables install -m 0644 Fedora/dist/content/* $(PREFIX)/$(DATADIR)/scap/ssg/ install -m 0644 Fedora/dist/guide/* $(PREFIX)/$(DOCDIR)/scap-security-guide/guides install -m 0644 RHEL/6/dist/content/* $(PREFIX)/$(DATADIR)/scap/ssg/ install -m 0644 RHEL/6/kickstart/*-ks.cfg $(PREFIX)/$(DATADIR)/scap-security-guide/kickstart install -m 0644 RHEL/6/dist/guide/* $(PREFIX)/$(DOCDIR)/scap-security-guide/guides install -m 0644 RHEL/6/dist/tables/* $(PREFIX)/$(DOCDIR)/scap-security-guide/tables install -m 0644 RHEL/7/kickstart/*-ks.cfg $(PREFIX)/$(DATADIR)/scap-security-guide/kickstart install -m 0644 RHEL/7/dist/content/* $(PREFIX)/$(DATADIR)/scap/ssg/ install -m 0644 RHEL/7/dist/guide/* $(PREFIX)/$(DOCDIR)/scap-security-guide/guides install -m 0644 RHEL/7/dist/tables/* $(PREFIX)/$(DOCDIR)/scap-security-guide/tables install -m 0644 OpenStack/RHEL-OSP/7/dist/content/* $(PREFIX)/$(DATADIR)/scap/ssg/ install -m 0644 OpenStack/RHEL-OSP/7/dist/guide/* $(PREFIX)/$(DOCDIR)/scap-security-guide/guides install -m 0644 Chromium/dist/content/* $(PREFIX)/$(DATADIR)/scap/ssg/ install -m 0644 Chromium/dist/guide/* $(PREFIX)/$(DOCDIR)/scap-security-guide/guides install -m 0644 Firefox/dist/content/* $(PREFIX)/$(DATADIR)/scap/ssg/ install -m 0644 Firefox/dist/guide/* $(PREFIX)/$(DOCDIR)/scap-security-guide/guides install -m 0644 JRE/dist/content/* $(PREFIX)/$(DATADIR)/scap/ssg/ install -m 0644 JRE/dist/guide/* $(PREFIX)/$(DOCDIR)/scap-security-guide/guides install -m 0644 Debian/8/dist/content/* $(PREFIX)/$(DATADIR)/scap/ssg/ install -m 0644 Debian/8/dist/guide/* $(PREFIX)/$(DOCDIR)/scap-security-guide/guides install -m 0644 WRLinux/dist/content/* $(PREFIX)/$(DATADIR)/scap/ssg/ install -m 0644 WRLinux/dist/guide/* $(PREFIX)/$(DOCDIR)/scap-security-guide/guides install -m 0644 docs/scap-security-guide.8 $(PREFIX)/$(MANDIR)/en/man8/ install -m 0644 LICENSE $(PREFIX)/$(DOCDIR)/scap-security-guide install -m 0644 README.md $(PREFIX)/$(DOCDIR)/scap-security-guide @# install a symlink in the old content location for compatibility install -d $(PREFIX)/$(DATADIR)/xml/scap/ssg ln -sf ../../../scap/ssg $(PREFIX)/$(DATADIR)/xml/scap/ssg/content .PHONY: rhel5 rhel6 rhel7 rhel-osp7 debian8 wrlinux jre firefox webmin tarball srpm rpm clean all rm -f scap-security-guide.spec scap-security-guide-0.1.31/OpenSUSE/000077500000000000000000000000001301675746700171035ustar00rootroot00000000000000scap-security-guide-0.1.31/OpenSUSE/Makefile000066400000000000000000000066701301675746700205540ustar00rootroot00000000000000all: guide content dist SHARED = ../shared include $(SHARED)/product-make.include PROD = opensuse VENDOR = ssgproject SHELLCHECK_AVAIL := $(shell which shellcheck >& /dev/null; echo $$?) checks: standard-oval-build content: $(OUT)/xccdf-unlinked-final.xml checks cp $< $(OUT)/unlinked-$(PROD)-xccdf.xml # Remove auxiliary Groups which are only for use in tables, and not guide output. xsltproc -o $(OUT)/unlinked-$(PROD)-xccdf-guide.xml $(TRANS)/xccdf-removeaux.xslt $(OUT)/unlinked-$(PROD)-xccdf.xml $(SHARED)/$(UTILS)/relabel-ids.py unlinked-$(PROD)-xccdf.xml $(ID) # Once things are relabelled, create a datastream xsltproc --stringparam reverse_DNS org.$(VENDOR).content /usr/share/openscap/xsl/xccdf_1.1_to_1.2.xsl \ $(OUT)/$(ID)-$(PROD)-xccdf.xml > $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml # Update @style attribute of to "SCAP_1.2". Fixes #1059 sed -i 's/style="SCAP_1.1"/style="SCAP_1.2"/' $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml oscap ds sds-compose $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml $(OUT)/$(ID)-$(PROD)-ds.xml # Update @schematron-version attribute in datastream to "1.2". Fixes #1191 # (Workaround for https://github.com/OpenSCAP/openscap/issues/383) sed -i 's/schematron-version="[0-9].[0-9]"/schematron-version="1.2"/' $(OUT)/$(ID)-$(PROD)-ds.xml # Fixes https://github.com/OpenSCAP/scap-security-guide/issues/1100 # Fixes https://github.com/OpenSCAP/scap-security-guide/issues/1101 $(SHARED)/$(UTILS)/sds-move-ocil-to-checks.py $(OUT)/$(ID)-$(PROD)-ds.xml $(OUT)/$(ID)-$(PROD)-ds.xml guide: content ifeq ($(OPENSCAP_1_1_OR_LATER), 0) $(SHARED)/$(UTILS)/build-all-guides.py --input $(OUT)/$(ID)-$(PROD)-ds.xml else @echo "Building guides from XCCDF 1.1, use OpenSCAP 1.1.0 or later for guides from datastreams!" $(SHARED)/$(UTILS)/build-all-guides.py --input $(OUT)/$(ID)-$(PROD)-xccdf.xml endif validate-xml: oscap xccdf validate-xml $(OUT)/$(ID)-$(PROD)-xccdf.xml oscap oval validate-xml --schematron $(OUT)/$(ID)-$(PROD)-oval.xml oscap ds sds-validate $(OUT)/$(ID)-$(PROD)-ds.xml validate: validate-xml validate-bash ifeq ($(OVAL_5_11), 0) cd $(OUT); ../$(SHARED)/$(UTILS)/verify-references.py --rules-with-invalid-checks --ovaldefs-unused $(ID)-$(PROD)-xccdf.xml else # If we are building against oscap version not supporting OVAL-5.11 language version yet, # don't call verify-references.py with "--rules-with-invalid-checks" argument, since the # OVAL checks using the 5.11 OVAL version will not be included in that case @echo -e "\nWarning:\n" @echo -e "\tOpenSUSE content build using oscap not supporting OVAL-5.11 language version detected!" @echo -e "\tSince the OVAL-5.11 OpenSUSE OVAL checks are missing, will skip test for referenced," @echo -e "\tbut undefined OVAL definitions during content validation. Consider building OpenSUSE" @echo -e "\tcontent with version OpenSCAP-1.2.2, or newer in order to perform full content validation!\n" cd $(OUT); ../$(SHARED)/$(UTILS)/verify-references.py --ovaldefs-unused $(ID)-$(PROD)-xccdf.xml endif # Items in dist are expected for distribution in an rpm dist: guide content mkdir -p $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-xccdf.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-oval.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-ocil.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-ds.xml $(DIST)/content mkdir -p $(DIST)/guide cp $(OUT)/*-guide-*.html $(DIST)/guide clean: rm -rf $(OUT)/* rm -f $(IN)/remediations/bash/templates/output/*.sh rm -rf $(DIST)/content $(DIST)/guide rm -rf $(BUILD) scap-security-guide-0.1.31/OpenSUSE/input/000077500000000000000000000000001301675746700202425ustar00rootroot00000000000000scap-security-guide-0.1.31/OpenSUSE/input/guide.xslt000066400000000000000000000144361301675746700222630ustar00rootroot00000000000000 A conditional clause for check statements. A conditional clause for check statements. This is a placeholder. scap-security-guide-0.1.31/OpenSUSE/input/oval/000077500000000000000000000000001301675746700212035ustar00rootroot00000000000000scap-security-guide-0.1.31/OpenSUSE/input/oval/oval_5.11/000077500000000000000000000000001301675746700226105ustar00rootroot00000000000000scap-security-guide-0.1.31/OpenSUSE/input/oval/oval_5.11/README000066400000000000000000000001711301675746700234670ustar00rootroot00000000000000This directory is for adding OVAL files for version 5.11. Please remove this file when content exists in this directory. scap-security-guide-0.1.31/OpenSUSE/input/oval/templates/000077500000000000000000000000001301675746700232015ustar00rootroot00000000000000scap-security-guide-0.1.31/OpenSUSE/input/oval/templates/Makefile000066400000000000000000000021051301675746700246370ustar00rootroot00000000000000templates: services packages kernel_modules permissions umasks sysctls SHARED_DIR=../../../../shared/templates export PYTHONPATH=../../../../shared SHARED_TEMPLATES=../../../../shared/templates OUTPUT:=$(shell mkdir -p output) services: ${SHARED_DIR}/create_services_enabled.py services_enabled.csv ${SHARED_DIR}/create_services_disabled.py services_disabled.csv packages: ${SHARED_DIR}/create_package_installed.py packages_installed.csv ${SHARED_DIR}/create_package_removed.py packages_removed.csv kernel_modules: ${SHARED_DIR}/create_kernel_modules_disabled.py kernel_modules_disabled.csv permissions: ${SHARED_DIR}/create_permission_checks.py file_dir_permissions.csv umasks: ${SHARED_TEMPLATES}/create_umask_checks.py ${SHARED_TEMPLATES}/file_umask_checks.csv sysctls: ${SHARED_DIR}/create_sysctl_checks.py sysctl_values.csv compare: diff output/ ../ | grep -v "Only in ../" copy: cp output/*.xml ../ cp output/*.sh ../../remediations/bash/ find-untemplated: templates ${SHARED_DIR}/find_untemplated.py clean: rm -f output/*.xml rm -f output/*.sh rm -rf output/ scap-security-guide-0.1.31/OpenSUSE/input/oval/templates/README000066400000000000000000000024121301675746700240600ustar00rootroot00000000000000These templates are designed to make generation of OVAL tests which have repetitive structure easier. For example: $ ./create_services_disabled.py services_disabled.csv will produce all the OVAL checks (in a shorthand format) to disable services, and store them in the output directory. The CSV input files should contain all the relevant information for each check. Files should be compared to existing OVAL checks for consistency before copying to the main oval directory. A Makefile exists to activate all the scripts here and ease comparison with existing checks. For example, to run all scripts to generate OVAL checks from the available templates: $ make templates To compare the newly-generated files in the output directory to the existing checks, run: $ make compare Then, if the changes are agreeable, the following command can be run to copy the newly generated files to the main oval directory: $ make copy To list files that have been manually created (and may potentially be templated), run: # make find-untemplated Note, however, that some checks may have been intentionally hand-edited. For example, some sysctl checks (such as for IPv6) may include additional tests so that they pass if the IPv6 module is disabled. Never blindly copy over existing checks. scap-security-guide-0.1.31/OpenSUSE/input/oval/templates/output/000077500000000000000000000000001301675746700245415ustar00rootroot00000000000000scap-security-guide-0.1.31/OpenSUSE/input/oval/templates/output/.gitignore000066400000000000000000000000131301675746700265230ustar00rootroot00000000000000*.xml *.sh scap-security-guide-0.1.31/OpenSUSE/input/profiles/000077500000000000000000000000001301675746700220655ustar00rootroot00000000000000scap-security-guide-0.1.31/OpenSUSE/input/profiles/common.xml000066400000000000000000000152401301675746700241010ustar00rootroot00000000000000 Common Profile for General-Purpose OpenSUSE Systems This profile contains items common to general-purpose OpenSUSE installations. scap-security-guide-0.1.31/OpenSUSE/input/profiles/standard.xml000066400000000000000000000023511301675746700244100ustar00rootroot00000000000000 Standard System Security Profile This profile contains rules to ensure standard security baseline of a OpenSUSE system. Regardless of your system's workload all of these checks should pass. I - Mission Critical Public <ProfileDescription></ProfileDescription> I - Mission Critical Sensitive <ProfileDescription></ProfileDescription> II - Mission Support Public <ProfileDescription></ProfileDescription> II - Mission Support Sensitive <ProfileDescription></ProfileDescription> III - Administrative Public <ProfileDescription></ProfileDescription> GEN000020 <GroupDescription></GroupDescription> GEN000020 The system must require authentication upon booting into single-user and maintenance modes. <VulnDiscussion>If the system does not require valid root authentication before it boots into single-user or maintenance mode, anyone who invokes single-user or maintenance mode is granted privileged access to all files on the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAIA-1, IAIA-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4241-6 CCI-000213 Edit /etc/inittab and set sulogin to run in single-user mode. Example line in /etc/inittab: ~:S:wait:/sbin/sulogin Check if the system requires a password for entering single-user mode. # grep ':S:' /etc/inittab If /sbin/sulogin is not listed, this is a finding. GEN000280 <GroupDescription></GroupDescription> GEN000280 Direct logins must not be permitted to shared, default, application, or utility accounts. <VulnDiscussion>Shared accounts (accounts where two or more people log in with the same user identification) do not provide identification and authentication. There is no way to provide for non-repudiation or individual accountability.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>true</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><Responsibility>Information Assurance Officer</Responsibility><IAControls>ECSC-1, IAIA-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000770 Use the switch user (su) command from a named account login to access shared accounts. Document requirements and procedures for users/administrators to log into their own accounts first and then switch user (su) to the account to be shared. Use the last command to check for multiple accesses to an account from different workstations/IP addresses. # last -w If users log directly onto accounts, rather than using the switch user (su) command from their own named account to access them, this is a finding (such as logging directly on to oracle). Verify with the SA or the IAO on documentation for users/administrators to log into their own accounts first and then switch user (su) to the account to be shared has been maintained including requirements and procedures. If no such documentation exists, this is a finding. GEN000300 <GroupDescription></GroupDescription> GEN000300 All accounts on the system must have unique user or account names. <VulnDiscussion>A unique user name is the first part of the identification and authentication process. If user names are not unique, there can be no accountability on the system for auditing purposes. Multiple accounts sharing the same name could result in the denial of service to one or both of the accounts or unauthorized access to files or privileges.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAIA-1, IAIA-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000764 Change user account names, or delete accounts, so each account has a unique name. Check the system for duplicate account names. Example: # pwck -r If any duplicate account names are found, this is a finding. GEN000320 <GroupDescription></GroupDescription> GEN000320 All accounts must be assigned unique User Identification Numbers (UIDs). <VulnDiscussion>Accounts sharing a UID have full access to each others' files. This has the same effect as sharing a login. There is no way to assure identification, authentication, and accountability because the system sees them as the same user. If the duplicate UID is 0, this gives potential intruders another privileged account to attack.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAIA-1, IAIA-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000764 Edit user accounts to provide unique UIDs for each account. Perform the following to ensure there are no duplicate UIDs: # cut -d: -f3 /etc/passwd | uniq -d If any duplicate UIDs are found, this is a finding. GEN000400 <GroupDescription></GroupDescription> GEN000400 The Department of Defense (DoD) login banner must be displayed immediately prior to, or as part of, console login prompts. <VulnDiscussion>Failure to display the logon banner prior to a logon attempt will negate legal proceedings resulting from unauthorized access to system resources.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECWM-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000048 Edit /etc/issue and add one of the DoD login banners (based on the character limitations imposed by the system). DoD Login Banners: You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests- -not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details. OR I've read & consent to terms in IS user agreem't. Access the system console and make a login attempt. Check for either of the following login banners based on the character limitations imposed by the system. An exact match is required. If one of these banners is not displayed, this is a finding. You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests- -not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details. OR I've read & consent to terms in IS user agreem't. GEN000440 <GroupDescription></GroupDescription> GEN000440 Successful and unsuccessful logins and logouts must be logged. <VulnDiscussion>Monitoring and recording successful and unsuccessful logins assists in tracking unauthorized access to the system. Without this logging, the ability to track unauthorized activity to specific user accounts may be diminished.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000126 Make sure the collection files exist. Procedure: If there are no successful logins being returned from the "last" command, create /var/log/wtmp: # touch /var/log/wtmp If there are no unsuccessful logins being returned from the "lastb" command, create /var/log/btmp: # touch /var/log/btmp Determine if all logon attempts are being logged. Procedure: Verify successful logins are being logged: # last -R | more If the command does not return successful logins, this is a finding. Verify if unsuccessful logons are being logged: # lastb -R | more If the command does not return unsuccessful logins, this is a finding. GEN000460 <GroupDescription></GroupDescription> GEN000460 The system must disable accounts after three consecutive unsuccessful login attempts. <VulnDiscussion>Disabling accounts after a limited number of unsuccessful login attempts improves protection against password guessing attacks.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLO-1, ECLO-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-3410-8 CCI-000044 By default link /etc/pam.d/system-auth points to /etc/pam.d/system-auth-ac which is the file maintained by the authconfig utility. In order to add pam options other than those available via the utility create /etc/pam.d/system-auth-local with the options and including system-auth-ac. In order to set the account lockout to three failed attempts the content should be similar to: auth required pam_access.so auth required pam_tally2.so deny=3 auth include system-auth-ac account required pam_tally2.so account include system-auth-ac password include system-auth-ac session include system-auth-ac Once system-auth-local is written reset the /etc/pam.d/system-auth to point to system-auth-local. This is necessary because authconfig writes directly to system-auth-ac so any changes made by hand will be lost if authconfig is run. Check the pam_tally configuration. # more /etc/pam.d/system-auth Confirm the following line is configured, before any "auth sufficient" lines: auth required pam_tally2.so deny=3 If no such line is found, this is a finding. GEN000480 <GroupDescription></GroupDescription> GEN000480 The delay between login prompts following a failed login attempt must be at least 4 seconds. <VulnDiscussion>Enforcing a delay between successive failed login attempts increases protection against automated password guessing attacks.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLO-1, ECLO-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000043 Add the pam_faildelay module and set the FAIL_DELAY variable. Procedure: Edit /etc/login.defs and set the value of the FAIL_DELAY variable to 4 or more. The default link /etc/pam.d/system-auth points to /etc/pam.d/system-auth-ac which is the file maintained by the authconfig utility. In order to add pam options other than those available via the utility create or modify /etc/pam.d/system-auth-local with the options and including system-auth-ac. For example: auth required pam_access.so auth optional pam_faildelay.so delay=4000000 auth include system-auth-ac account include system-auth-ac password include system-auth-ac session include system-auth-ac Once system-auth-local is written ensure the /etc/pam.d/system-auth points to system-auth-local. This is necessary because authconfig writes directly to system-auth-ac so any manual changes made will be lost if authconfig is run. Check the value of the FAIL_DELAY variable and the ability to use it. Procedure: # grep FAIL_DELAY /etc/login.defs If the value does not exist, or is less than 4, this is a finding. Check for the use of pam_faildelay. # grep pam_faildelay /etc/pam.d/system-auth* If pam_faildelay.so module is not present, this is a finding. If pam_faildelay is present only in /etc/pam.d/system-auth-ac: ensure that /etc/pam.d/system-auth includes /etc/pam.d/system-auth-ac. #grep system-auth-ac /etc/pam.d/system-auth This should return: auth include system-auth-ac account include system-auth-ac password include system-auth-ac session include system-auth-ac /etc/pam.d/system-auth-ac should only be included by /etc/pam.d/system-auth. All other pam files should include /etc/pam.d/system-auth. If pam_faildelay is not defined in /etc/pam.d/system-auth either directly or through inclusion of system-auth-ac, this is a finding. GEN000520 <GroupDescription></GroupDescription> GEN000520 The root user must not own the logon session for an application requiring a continuous display. <VulnDiscussion>If an application is providing a continuous display and is running with root privileges, unauthorized users could interrupt the process and gain root access to the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>PESL-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Configure the system so the owner of a session requires a continuous screen display, such as a network management display, is not root. Ensure the display is also located in a secure, controlled access area. Document and justify this requirement and ensure the terminal and keyboard for the display (or workstation) are secure from all but authorized personnel by maintaining them in a secure area, in a locked cabinet where a swipe card, or other positive forms of identification, must be used to gain entry. If there is an application running on the system continuously in use (such as a network monitoring application), ask the SA what the name of the application is. Verify documentation exists for the requirement and justification of the application. If no documentation exists, this is a finding. Execute "ps -ef | more" to determine which user owns the process(es) associated with the application. If the owner is root, this is a finding. GEN000560 <GroupDescription></GroupDescription> GEN000560 The system must not have accounts configured with blank or null passwords. <VulnDiscussion>If an account is configured for password authentication but does not have an assigned password, it may be possible to log into the account without authentication. If the root user is configured without a password, the entire system may be compromised. For user accounts not using password authentication, the account must be configured with a password lock value instead of a blank or null value. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAIA-1, IAIA-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit /etc/pam.d/system-auth and remove the "nullok" setting. Verify the system will not log in accounts with blank passwords. # grep nullok /etc/pam.d/system-auth /etc/pam.d/system-auth-ac If an entry for nullok is found, this is a finding on Linux. GEN000880 <GroupDescription></GroupDescription> GEN000880 The root account must be the only account having a UID of 0. <VulnDiscussion>If an account has a UID of 0, it has root authority. Multiple accounts with a UID of 0 afford more opportunity for potential intruders to guess a password for a privileged account. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1, IAIA-1, IAIA-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Remove or change the UID of accounts other than root that have UID 0. Check the system for duplicate UID 0 assignments by listing all accounts assigned UID 0. Procedure: # cat /etc/passwd | awk -F":" '{print$1":"$3":"}' | grep ":0:" If any accounts other than root are assigned UID 0, this is a finding. GEN000900 <GroupDescription></GroupDescription> GEN000900 The root user's home directory must not be the root directory (/). <VulnDiscussion>Changing the root home directory to something other than / and assigning it a 0700 protection makes it more difficult for intruders to manipulate the system by reading the files root places in its default directory. It also gives root the same discretionary access control for root's home directory as for the other user home directories.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 The root home directory should be something other than / (such as /roothome). Procedure: # mkdir /rootdir # chown root /rootdir # chgrp root /rootdir # chmod 700 /rootdir # cp -r /.??* /rootdir/. Then, edit the passwd file and change the root home directory to /rootdir. The cp -r /.??* command copies all files and subdirectories of file names beginning with "." into the new root directory, which preserves the previous root environment. Ensure you are in the "/" directory when executing the "cp" command. Determine if root is assigned a home directory other than / by listing its home directory. Procedure: # grep "^root" /etc/passwd | awk -F":" '{print $6}' If the root user home directory is /, this is a finding. GEN000920 <GroupDescription></GroupDescription> GEN000920 The root account's home directory (other than /) must have mode 0700. <VulnDiscussion>Permissions greater than 0700 could allow unauthorized users access to the root home directory.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 The root home directory will have permissions of 0700. Do not change the protections of the / directory. Use the following command to change protections for the root home directory: # chmod 0700 /rootdir. Check the mode of the root home directory. Procedure: # grep "^root" /etc/passwd | awk -F":" '{print $6}' # ls -ld <root home directory> If the mode of the directory is not equal to 0700, this is a finding. If the home directory is /, this check will be marked "Not Applicable". GEN000940 <GroupDescription></GroupDescription> GEN000940 The root account's executable search path must be the vendor default and must contain only absolute paths. <VulnDiscussion>The executable search path (typically the PATH environment variable) contains a list of directories for the shell to search to find executables. If this path includes the current working directory or other relative paths, executables in these directories may be executed instead of system commands. This variable is formatted as a colon-separated list of directories. If there is an empty entry, such as a leading or trailing colon or two consecutive colons, this is interpreted as the current working directory. Entries starting with a slash (/) are absolute paths. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2, ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit the root user's local initialization files ~/.profile,~/.bashrc (assuming root shell is bash). Change any found PATH variable settings to the vendor's default path for the root user. Remove any empty path entries or references to relative paths. To view the root user's PATH, log in as the root user, and execute: # env | grep PATH This variable is formatted as a colon-separated list of directories. If there is an empty entry, such as a leading or trailing colon, or two consecutive colons, this is a finding. If an entry starts with a character other than a slash (/), this is a finding. If directories beyond those in the vendor's default root path are present. This is a finding. GEN000960 <GroupDescription></GroupDescription> GEN000960 The root account must not have world-writable directories in its executable search path. <VulnDiscussion>If the root search path contains a world-writable directory, malicious software could be placed in the path by intruders and/or malicious users and inadvertently run by root with all of root's privileges. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 For each world-writable path in root's executable search path, do one of the following: 1. Remove the world-writable permission on the directory. Procedure: # chmod o-w <path> 2. Remove the world-writable directory from the executable search path. Procedure: Identify and edit the initialization file referencing the world-writable directory and remove it from the PATH variable. Check for world-writable permissions on all directories in the root user's executable search path. Procedure: # ls -ld `echo $PATH | sed "s/:/ /g"` If any of the directories in the PATH variable are world-writable, this is a finding. GEN000980 <GroupDescription></GroupDescription> GEN000980 The system must prevent the root account from directly logging in except from the system console. <VulnDiscussion>Limiting the root account direct logins to only system consoles protects the root account from direct unauthorized access from a non-console device.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECPA-1, ECSD-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000770 Create if needed and set the contents of /etc/securetty to a "console" or "tty" device. # echo console > /etc/securetty or # echo tty1 > /etc/securetty Check /etc/securetty # more /etc/securetty If the file does not exist, or contains more than "console" or a single "tty" device this is a finding. GEN000360 <GroupDescription></GroupDescription> GEN000360 GIDs reserved for system accounts must not be assigned to non-system groups. <VulnDiscussion>Reserved GIDs are typically used by system software packages. If non-system groups have GIDs in this range, they may conflict with system software, possibly leading to the group having permissions to modify system files.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Change the primary group GID numbers for non-system accounts with reserved primary group GIDs (those less or equal to 499). Confirm all accounts with a GID of 499 and below are used by a system account. Procedure: List all the users with a GID of 0-499. # cut -d: -f 1,4 /etc/passwd|egrep ":[1-4][0-9]{2}$|:[0-9]{1,2}$" If a GID reserved for system accounts (0 - 499) is used by a non-system account, this is a finding. GEN000380 <GroupDescription></GroupDescription> GEN000380 All GIDs referenced in the /etc/passwd file must be defined in the /etc/group file. <VulnDiscussion>If a user is assigned the GID of a group not existing on the system, and a group with the GID is subsequently created, the user may have unintended rights to the group. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Add a group to the system for each GID referenced without a corresponding group. Perform the following to ensure there are no GIDs referenced in /etc/passwd not defined in /etc/group: # pwck -r If GIDs referenced in /etc/passwd are not defined in /etc/group are returned, this is a finding. GEN006480 <GroupDescription></GroupDescription> GEN006480 The system must have a host-based intrusion detection tool installed. <VulnDiscussion>Without a host-based intrusion detection tool, there is no system-level defense when an intruder gains access to a system or network. Additionally, a host-based intrusion detection tool can provide methods to immediately lock out detected intrusion attempts.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECID-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001259 Install a host-based intrusion detection tool. Ask the SA or IAO if a host-based intrusion detection application is loaded on the system. The preferred intrusion detection system is McAfee HBSS available through Cybercom. If another host-based intrusion detection application, such as SELinux, is used on the system, this is not a finding. Procedure: Examine the system to see if the Host Intrusion Prevention System (HIPS) is installed #rpm -qa | grep MFEhiplsm If the MFEhiplsm package is installed, HBSS is being used on the system. If another host-based intrusion detection system is loaded on the system # find / -name <daemon name> Where <daemon name> is the name of the primary application daemon to determine if the application is loaded on the system. Determine if the application is active on the system. Procedure: # ps -ef | grep <daemon name> If no host-based intrusion detection system is installed on the system, this is a finding. GEN000120 <GroupDescription></GroupDescription> GEN000120 System security patches and updates must be installed and up-to-date. <VulnDiscussion>Timely patching is critical for maintaining the operational availability, confidentiality, and integrity of information technology (IT) systems. However, failure to keep operating system and application software patched is a common mistake made by IT professionals. New patches are released daily, and it is often difficult for even experienced system administrators to keep abreast of all the new patches. When new weaknesses in an operating system exist, patches are usually made available by the vendor to resolve the problems. If the most recent security patches and updates are not installed, unauthorized users may take advantage of weaknesses present in the unpatched software. The lack of prompt attention to patching could result in a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>VIVM-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001227 Install the patches or updated packages available from the vendor. Obtain the list of available package security updates from Red Hat. Check the available package security updates have been installed on the system. Use the "rpm" command to list the packages installed on the system. Example: # rpm -qa -last If updated packages are available and applicable to the system and have not been installed, this is a finding. One source for the list of Red Hat updates is available at https://access.redhat.com/security/updates/active/ GEN001140 <GroupDescription></GroupDescription> GEN001140 System files and directories must not have uneven access permissions. <VulnDiscussion>Discretionary access control is undermined if users, other than a file owner, have greater access permissions to system files and directories than the owner.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of files with uneven permissions so owners do not have less permission than group or world users. Check system directories for uneven file permissions. Procedure: # ls -lL /etc /bin /usr/bin /usr/lbin /usr/usb /sbin /usr/sbin Uneven file permissions exist if the file owner has less permissions than the group or other user classes. If any of the files in the above listed directories contain uneven file permissions, this is a finding. GEN001160 <GroupDescription></GroupDescription> GEN001160 All files and directories must have a valid owner. <VulnDiscussion>Un-owned files and directories may be unintentionally inherited if a user is assigned the same UID as the UID of the un-owned files.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 All directories and files (executable and data) will have an identifiable owner and group name. Either trace files to an authorized user, change the file's owner to root, or delete them. Determine the legitimate owner of the files and use the chown command to set the owner and group to the correct value. If the legitimate owner cannot be determined, change the owner to root (but make sure none of the changed files remain executable because they could be Trojan horses or other malicious code). Examine the files to determine their origin and the reason for their lack of an owner/group. Check the system for files with no assigned owner. Procedure: # find / -nouser If any files have no assigned owner, this is a finding. Caution should be used when centralized authorization is used because valid files may appear as unowned due to communication issues. GEN001180 <GroupDescription></GroupDescription> GEN001180 All network services daemon files must have mode 0755 or less permissive. <VulnDiscussion>Restricting permission on daemons will protect them from unauthorized modification and possible system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the network services daemon. # chmod go-w <path> Check the mode of network services daemons. # find /usr/sbin -type f -perm +022 -exec stat -c %a:%n {} \; This will return the octal permissions and name of all files that are group or world writable. If any network services daemon listed is world or group writable (either or both of the 2 lowest order digits contain a 2, 3 or 6), this is a finding. Note: Network daemons not residing in these directories (such as httpd or sshd) must also be checked for the correct permissions. GEN001260 <GroupDescription></GroupDescription> GEN001260 System log files must have mode 0640 or less permissive. <VulnDiscussion>If the system log files are not protected, unauthorized users could change the logged data, eliminating its forensic value.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECTP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001314 Change the mode of the system log file(s) to 0640 or less permissive. Procedure: # chmod 0640 /path/to/system-log-file Note: Do not confuse system log files with audit logs. Check the mode of log files. Procedure: # find /var/log /var/log/syslog /var/adm -type f -perm -640 \! -perm 640 With the exception of /var/log/wtmp, if any of the log files have modes more permissive than 0640, this is a finding. GEN001800 <GroupDescription></GroupDescription> GEN001800 All skeleton files (typically those in /etc/skel) must have mode 0644 or less permissive. <VulnDiscussion>If the skeleton files are not protected, unauthorized personnel could change user startup parameters and possibly jeopardize user files. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of skeleton files with incorrect mode: # chmod 0644 <skeleton file> Check skeleton files permissions. # ls -alL /etc/skel If a skeleton file has a mode more permissive than 0644, this is a finding. GEN001320 <GroupDescription></GroupDescription> GEN001320 NIS/NIS+/yp files must be owned by root, sys, or bin. <VulnDiscussion>NIS/NIS+/yp files are part of the system's identification and authentication processes and are critical to system security. Failure to give ownership of sensitive files or utilities to root or bin provides the designated owner and unauthorized users with the potential to access sensitive information or change the system configuration which could weaken the system's security posture.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the ownership of NIS/NIS+/yp files to root, sys or bin. Procedure (example): # chown root <filename> Perform the following to check NIS file ownership: # ls -la /var/yp/*; If the file ownership is not root, sys, or bin, this is a finding. GEN001340 <GroupDescription></GroupDescription> GEN001340 NIS/NIS+/yp files must be group-owned by root, sys, or bin. <VulnDiscussion>NIS/NIS+/yp files are part of the system's identification and authentication processes and are, therefore, critical to system security. Failure to give ownership of sensitive files or utilities to root or bin provides the designated owner and unauthorized users with the potential to access sensitive information or change the system configuration which could weaken the system's security posture.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Perform the following to change NIS file ownership. # chgrp root /var/yp/* Perform the following to check NIS file group ownership: # ls -la /var/yp/* If the file group ownership is not root, sys, or bin, this is a finding. GEN001360 <GroupDescription></GroupDescription> GEN001360 The NIS/NIS+/yp command files must have mode 0755 or less permissive. <VulnDiscussion>NIS/NIS+/yp files are part of the system's identification and authentication processes and are critical to system security. Unauthorized modification of these files could compromise these processes and the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of NIS/NIS+/yp command files to 0755 or less permissive. Procedure (example): # chmod 0755 <filename> Perform the following to check NIS file permissions. # ls -la /var/yp/* If the file's mode is more permissive than 0755, this is a finding. GEN001280 <GroupDescription></GroupDescription> GEN001280 Manual page files must have mode 0644 or less permissive. <VulnDiscussion>If manual pages are compromised, misleading information could be inserted, causing actions to compromise the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of manual page files to 0644 or less permissive. Procedure (example): # chmod 0644 /path/to/manpage Check the mode of the manual page files. Procedure: # ls -lL /usr/share/man /usr/share/info /usr/share/infopage If any of the manual page files have a mode more permissive than 0644, this is a finding. GEN001300 <GroupDescription></GroupDescription> GEN001300 Library files must have mode 0755 or less permissive. <VulnDiscussion>Unauthorized access could destroy the integrity of the library files.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCSL-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001499 Change the mode of library files to 0755 or less permissive. Procedure (example): # chmod go-w </path/to/library-file> Note: Library files should have an extension of ".a" or a ".so" extension, possibly followed by a version number. Check the mode of library files. Procedure: # DIRS="/usr/lib /lib";for DIR in $DIRS;do find $DIR -type f -perm +022 -exec stat -c %a:%n {} \;;done This will return the octal permissions and name of all group or world writable files. If any file listed is world or group writable (either or both of the 2 lowest order digits contain a 2, 3 or 6), this is a finding. GEN001200 <GroupDescription></GroupDescription> GEN001200 All system command files must have mode 0755 or less permissive. <VulnDiscussion>Restricting permissions will protect system command files from unauthorized modification. System command files include files present in directories used by the operating system for storing default system executables and files present in directories included in the system's default executable search paths.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance>Elevate to Severity Code I if any file listed world-writable.</SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001499 Change the mode for system command files to 0755 or less permissive taking into account necessary GIUD and SUID bits. Procedure: # chmod go-w <filename> Check the permissions for files in /etc, /bin, /usr/bin, /usr/lbin, /usr/usb, /sbin, and /usr/sbin. Procedure: # DIRS="/etc /bin /usr/bin /usr/lbin /usr/usb /sbin /usr/sbin";for DIR in $DIRS;do find $DIR -type f -perm +022 -exec stat -c %a:%n {} \;;done This will return the octal permissions and name of all group or world writable files. If any command file is listed and is world or group writable (either or both of the 2 lowest order digits contain a 2, 3 or 6), this is a finding. Note: Elevate to Severity Code I if any command file listed is world-writable. GEN001220 <GroupDescription></GroupDescription> GEN001220 All system files, programs, and directories must be owned by a system account. <VulnDiscussion>Restricting permissions will protect the files from unauthorized modification.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001499 Change the owner of system files, programs, and directories to a system account. Procedure: # chown root /some/system/file (A different system user may be used in place of root.) Check the ownership of system files, programs, and directories. Procedure: # ls -lLa /etc /bin /usr/bin /usr/lbin /usr/usb /sbin /usr/sbin If any of the system files, programs, or directories are not owned by a system account, this is a finding. GEN001240 <GroupDescription></GroupDescription> GEN001240 System files, programs, and directories must be group-owned by a system group. <VulnDiscussion>Restricting permissions will protect the files from unauthorized modification.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001499 Change the group-owner of system files to a system group. Procedure: # chgrp root /path/to/system/file (System groups other than root may be used.) Check the group-ownership of system files, programs, and directories. Procedure: # ls -lLa /etc /bin /usr/bin /usr/lbin /usr/usb /sbin /usr/sbin If any system file, program, or directory is not owned by a system group, this is a finding. GEN001400 <GroupDescription></GroupDescription> GEN001400 The /etc/shadow (or equivalent) file must be owned by root. <VulnDiscussion>The /etc/shadow file contains the list of local system accounts. It is vital to system security and must be protected from unauthorized modification. Failure to give ownership of sensitive files or utilities to root or bin provides the designated owner and unauthorized users with the potential to access sensitive information or change the system configuration which could weaken the system's security posture.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-3918-0 CCI-000225 Change the ownership of the /etc/shadow (or equivalent) file. # chown root /etc/shadow Check the ownership of the /etc/shadow file. # ls -lL /etc/shadow If the /etc/shadow file is not owned by root, this is a finding. GEN001380 <GroupDescription></GroupDescription> GEN001380 The /etc/passwd file must have mode 0644 or less permissive. <VulnDiscussion>If the passwd file is writable by a group-owner or the world, the risk of passwd file compromise is increased. The passwd file contains the list of accounts on the system and associated information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-3566-7 CCI-000225 Change the mode of the passwd file to 0644. Procedure: # chmod 0644 /etc/passwd Check the mode of the /etc/passwd file. Procedure: # ls -lL /etc/passwd If /etc/passwd has a mode more permissive than 0644, this is a finding. GEN001420 <GroupDescription></GroupDescription> GEN001420 The /etc/shadow (or equivalent) file must have mode 0400. <VulnDiscussion>The /etc/shadow file contains the list of local system accounts. It is vital to system security and must be protected from unauthorized modification. The file also contains password hashes which must not be accessible to users other than root.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4130-1 CCI-000225 Change the mode of the /etc/shadow (or equivalent) file. # chmod 0400 /etc/shadow Check the mode of the /etc/shadow file. # ls -lL /etc/shadow If the /etc/shadow file has a mode more permissive than 0400, this is a finding. GEN002380 <GroupDescription></GroupDescription> GEN002380 The owner, group-owner, mode, ACL, and location of files with the setuid bit set must be documented using site-defined procedures. <VulnDiscussion>All files with the setuid bit set will allow anyone running these files to be temporarily assigned the UID of the file. While many system files depend on these attributes for proper operation, security problems can result if setuid is assigned to programs allowing reading and writing of files, or shell escapes. Only default vendor-supplied executables should have the setuid bit set.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>true</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>System Administrator</Responsibility><IAControls>ECPA-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000368 Document the files with the suid bit set or unset the suid bit on the executable. If STIGID GEN000220 is satisfied, this is not a finding. List all setuid files on the system. Procedure: # find / -perm -4000 -exec ls -l {} \; | more Note: Executing these commands may result in large listings of files; the output may be redirected to a file for easier analysis. Ask the SA or IAO if files with the setuid bit set have been documented. Documentation must include the owner, group-owner, mode, ACL, and location of the files. If any undocumented file has its setuid bit set, this is a finding. GEN002440 <GroupDescription></GroupDescription> GEN002440 The owner, group-owner, mode, ACL and location of files with the setgid bit set must be documented using site-defined procedures. <VulnDiscussion>All files with the setgid bit set will allow anyone running these files to be temporarily assigned the GID of the file. While many system files depend on these attributes for proper operation, security problems can result if setgid is assigned to programs allowing reading and writing of files, or shell escapes.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>true</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><Responsibility>Information Assurance Officer</Responsibility><IAControls>ECPA-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000368 Document the files with the sgid bit set or unset the sgid bit on the executable. If STIGID GEN000220 is satisfied, this is not a finding. List all setgid files on the system. Procedure: # find / -perm -2000 -exec ls -l {} \; | more Note: Executing these commands may result in large listings of files; the output may be redirected to a file for easier analysis. Ask the SA or IAO if files with the setgid bit set have been documented. Documentation must include owner, group-owner, mode, ACL, and location. If any undocumented file has its setgid bit set, this is a finding. GEN002400 <GroupDescription></GroupDescription> GEN002400 The system must be checked weekly for unauthorized setuid files as well as unauthorized modification to authorized setuid files. <VulnDiscussion>Files with the setuid bit set will allow anyone running these files to be temporarily assigned the UID of the file. While many system files depend on these attributes for proper operation, security problems can result if setuid is assigned to programs allowing reading and writing of files, or shell escapes.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCSL-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000318 Establish a weekly automated or manual process to generate a list of suid files on the system and compare it with the prior list. To create a list of suid files: # find / -perm -4000 > suid-file-list NOTE: For MAC I systems, increase the frequency to daily. Ask the SA for the weekly automated or manual process used to generate a list of setuid files on the system and compare it with the prior list. If no such process is in place, this is a finding. Review the process. If the process does not identify and report changes in setuid files, this is a finding. NOTE: For MAC I systems, increase the frequency to daily. GEN002460 <GroupDescription></GroupDescription> GEN002460 The system must be checked weekly for unauthorized setgid files as well as unauthorized modification to authorized setgid files. <VulnDiscussion>Files with the setgid bit set will allow anyone running these files to be temporarily assigned the group id of the file. While many system files depend on these attributes for proper operation, security problems can result if setgid is assigned to programs allowing reading and writing of files, or shell escapes.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCSL-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000318 Establish a weekly automated or manual process to generate a list of setgid files on the system and compare it with the prior list. To create a list of setgid files: # find / -perm -2000 > setgid-file-list NOTE: For MAC I systems, increase the frequency to daily. Ask the SA if a weekly automated or manual process is used to generate a list of setgid files on the system and compare it with the prior list. If no such process is in place, this is a finding. NOTE: For MAC I systems, increase the frequency to daily. GEN002420 <GroupDescription></GroupDescription> GEN002420 Removable media, remote file systems, and any file system not containing approved setuid files must be mounted with the "nosuid" option. <VulnDiscussion>The "nosuid" mount option causes the system to not execute setuid files with owner privileges. This option must be used for mounting any file system not containing approved setuid files. Executing setuid files from untrusted file systems, or file systems not containing approved setuid files, increases the opportunity for unprivileged users to attain unauthorized administrative access.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Edit /etc/fstab and add the "nosuid" mount option to all file systems mounted from removable media or network shares, and any file system not containing approved setuid or setgid files. Check /etc/mtab and verify the "nosuid" mount option is used on file systems mounted from removable media, network shares, or any other file system not containing approved setuid or setgid files. If any of these files systems do not mount with the "nosuid" option, it is a finding. GEN002500 <GroupDescription></GroupDescription> GEN002500 The sticky bit must be set on all public directories. <VulnDiscussion>Failing to set the sticky bit on the public directories allows unauthorized users to delete files in the directory structure. The only authorized public directories are those temporary directories supplied with the system or those designed to be temporary file repositories. The setting is normally reserved for directories used by the system and by users for temporary file storage, (e.g., /tmp), and for directories requiring global read/write access.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-3399-3 CCI-000366 Set the sticky bit on all public directories. Procedure: # chmod 1777 /tmp (Replace /tmp with the public directory missing the sticky bit, if necessary.) Check all world-writable directories have the sticky bit set. Procedure: # find / -type d -perm -002 ! -perm -1000 > wwlist If the sticky bit is not set on a world-writable directory, this is a finding. GEN002520 <GroupDescription></GroupDescription> GEN002520 All public directories must be owned by root or an application account. <VulnDiscussion>If a public directory has the sticky bit set and is not owned by a privileged UID, unauthorized users may be able to modify files created by others. The only authorized public directories are those temporary directories supplied with the system or those designed to be temporary file repositories. The setting is normally reserved for directories used by the system and by users for temporary file storage, (e.g., /tmp), and for directories requiring global read/write access.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the owner of public directories to root or an application account. Procedure: # chown root /tmp (Replace root with an application user and/or /tmp with another public directory as necessary.) Check the ownership of all public directories. Procedure: # find / -type d -perm -1002 -exec ls -ld {} \; If any public directory is not owned by root or an application user, this is a finding. GEN002560 <GroupDescription></GroupDescription> GEN002560 The system and user default umask must be 077. <VulnDiscussion>The umask controls the default access mode assigned to newly created files. An umask of 077 limits new files to mode 700 or less permissive. Although umask can be represented as a 4-digit number, the first digit representing special access modes is typically ignored or required to be 0. This requirement applies to the globally configured system defaults and the user defaults for each account on the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>true</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance>If the default umask is 000 or does not restrict the world-writable permission, this becomes a CAT I finding.</SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit local and global initialization files that contain "umask" and change them to use 077 instead of the current value. NOTE: The following commands must be run in the BASH shell. Check global initialization files for the configured umask value. Procedure: # grep umask /etc/* Check local initialization files for the configured umask value. Procedure: # cut -d: -f6 /etc/passwd |xargs -n1 -IDIR find DIR -name ".*" -type f -maxdepth 1 -exec grep umask {} \; If the system and user default umask is not 077, this a finding. Note: If the default umask is 000 or allows for the creation of world-writable files this becomes a Severity Code I finding. GEN002640 <GroupDescription></GroupDescription> GEN002640 Default system accounts must be disabled or removed. <VulnDiscussion>Vendor accounts and software may contain backdoors allowing unauthorized access to the system. These backdoors are common knowledge and present a threat to system security if the account is not disabled.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAAC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000178 Lock the default system account(s). # passwd -l <user> Determine if default system accounts (such as those for sys, bin, uucp, nuucp, daemon, smtp) have been disabled. # cat /etc/shadow If an account's password field (which is the second field in the /etc/shadow file) is "*", "*LK*", or is prefixed with a '!', the account is locked or disabled. If there are any unlocked default system accounts this is a finding. GEN002660 <GroupDescription></GroupDescription> GEN002660 Auditing must be implemented. <VulnDiscussion>Without auditing, individual system accesses cannot be tracked and malicious activity cannot be detected and traced back to an individual account.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4292-9 CCI-000169 Start the auditd service and set it to start on boot. # service auditd start ; chkconfig auditd on Determine if auditing is enabled. # ps -ef |grep auditd If the auditd process is not found, this is a finding. GEN002680 <GroupDescription></GroupDescription> GEN002680 System audit logs must be owned by root. <VulnDiscussion>Failure to give ownership of system audit log files to root provides the designated owner and unauthorized users with the potential to access sensitive information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECTP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000162 Change the ownership of the audit log file(s). Procedure: # chown root <audit log file> Perform the following to determine the location of audit logs and then check the ownership. Procedure: # grep "^log_file" /etc/audit/auditd.conf|sed s/^[^\/]*//|xargs stat -c %U:%n If any audit log file is not owned by root, this is a finding. GEN002700 <GroupDescription></GroupDescription> GEN002700 System audit logs must have mode 0640 or less permissive. <VulnDiscussion>If a user can write to the audit logs, audit trails can be modified or destroyed and system intrusion may not be detected. System audit logs are those files generated from the audit system and do not include activity, error, or other log files created by application software.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECTP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000163 Change the mode of the audit log directories/files. # chmod 0750 <audit directory> # chmod 0640 <audit file> Perform the following to determine the location of audit logs and then check the mode of the files. Procedure: # grep "^log_file" /etc/audit/auditd.conf|sed s/^[^\/]*//|xargs stat -c %a:%n If any audit log file has a mode more permissive than 0640, this is a finding. GEN002720 <GroupDescription></GroupDescription> GEN002720 The audit system must be configured to audit failed attempts to access files and programs. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000126 Edit the audit.rules file and add the following line(s) to enable auditing of failed attempts to access files and programs: either: -a exit,always -F arch=<ARCH> -S creat -F success=0 or both: -a exit,always -F arch=<ARCH> -S creat -F exit=-EPERM -a exit,always -F arch=<ARCH> -S creat -F exit=-EACCES Restart the auditd service. # service auditd restart Verify auditd is configured to audit failed file access attempts. There must be an audit rule for each of the access syscalls logging all failed accesses (-F success=0) or there must both an "-F exit=-EPERM" and "-F exit=-EACCES" for each access syscall. Procedure: # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -e "-S creat" | grep -e "-F success=0" # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -e "-S creat" | grep -e "-F exit=-EPERM" # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -e "-S creat" | grep -e "-F exit=-EACCES" If an "-S creat" audit rule with "-F success" does not exist and no separate rules containing "-F exit=-EPERM" and "-F exit=-EACCES" for "creat" exist, then this is a finding. GEN002740 <GroupDescription></GroupDescription> GEN002740 The audit system must be configured to audit files and programs deleted by the user. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000126 Edit the audit.rules file and add the following line to enable auditing of deletions: -a exit,always -S unlink Restart the auditd service. # service auditd restart Check the system audit configuration to determine if file and directory deletions are audited. # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -i "unlink" If no results are returned, or the results do not contain "-S unlink", this is a finding. GEN002800 <GroupDescription></GroupDescription> GEN002800 The audit system must be configured to audit login, logout, and session initiation. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14904-7 CCI-000126 Ensure logins Procedure: Modify /etc/audit/audit.rules to contain: -w /var/log/faillog -p wa -w /var/log/lastlog -p wa The message types that are always recorded to /var/log/audit/audit.log include LOGIN,USER_LOGIN,USER_START,USER_END among others and do not need to be added to audit_rules. The log files /var/log/faillog and /var/log/lastlog must be protected from tampering of the login records. Procedure: #egrep "faillog|lastlog" /etc/audit/audit.rules|grep "-p (wa|aw)" If both /var/log/faillog and /var/log/lastlog entries do not exist, this is a finding. GEN002820 <GroupDescription></GroupDescription> GEN002820 The audit system must be configured to audit all discretionary access control permission modifications. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14058-2 CCI-000126 The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules. On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details. Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately. The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding. Procedure: Edit the audit.rules file and add the following lines to enable auditing of discretionary access control permissions modifications. -a exit,always -F arch=<ARCH> -S chmod Restart the auditd service. # service auditd restart Check the system's audit configuration. Procedure: # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -i " chmod " If "-S chmod" is not in the result, this is a finding GEN003720 <GroupDescription></GroupDescription> GEN003720 The inetd.conf file, xinetd.conf file, and the xinetd.d directory must be owned by root or bin. <VulnDiscussion>Failure to give ownership of sensitive files or utilities to root provides the designated owner and unauthorized users with the potential to access sensitive information or change the system configuration possibly weakening the system's security posture.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the owner of the xinetd configuration files. # chown root /etc/xinetd.conf /etc/xinetd.d/* Check the owner of the xinetd configuration files. Procedure: # ls -lL /etc/xinetd.conf # ls -laL /etc/xinetd.d This is a finding if any of the above files or directories are not owned by root or bin. GEN003740 <GroupDescription></GroupDescription> GEN003740 The xinetd configuration files must have mode 0640 or less permissive. <VulnDiscussion>The Internet service daemon configuration files must be protected as malicious modification could cause Denial of Service or increase the attack surface of the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the xinetd configuration files. # chmod 0640 /etc/xinetd.conf /etc/xinetd.d/* Check the mode of the xinetd configuration files. Procedure: # ls -lL /etc/xinetd.conf # ls -lL /etc/xinetd.d If the mode of the file(s) is more permissive than 0640, this is a finding. GEN003760 <GroupDescription></GroupDescription> GEN003760 The services file must be owned by root or bin. <VulnDiscussion>Failure to give ownership of sensitive files or utilities to root or bin provides the designated owner and unauthorized users with the potential to access sensitive information or change the system configuration possibly weakening the system's security posture.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the ownership of the services file to root or bin. Procedure: # chown root /etc/services Check the ownership of the services file. Procedure: # ls -lL /etc/services If the services file is not owned by root or bin, this is a finding. GEN003780 <GroupDescription></GroupDescription> GEN003780 The services file must have mode 0644 or less permissive. <VulnDiscussion>The services file is critical to the proper operation of network services and must be protected from unauthorized modification. Unauthorized modification could result in the failure of network services.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the services file to 0644 or less permissive. Procedure: # chmod 0644 /etc/services Check the mode of the services file. Procedure: # ls -lL /etc/services If the services file has a mode more permissive than 0644, this is a finding GEN001780 <GroupDescription></GroupDescription> GEN001780 Global initialization files must contain the "mesg -n" or "mesg n" commands. <VulnDiscussion>If the "mesg -n" or "mesg n" command is not placed into the system profile, messaging can be used to cause a Denial of Service attack.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit /etc/profile or another global initialization script, and add the "mesg -n" command. Check global initialization files for the presence of "mesg -n" or "mesg n". Procedure: # grep "mesg" etc/bashrc /etc/csh.cshrc /etc/csh.login /etc/csh.logout /etc/environment /etc/ksh.kshrc /etc/profile /etc/suid_profile /etc/profile.d/* If no global initialization files contain "mesg -n" or "mesg n", this is a finding. GEN003900 <GroupDescription></GroupDescription> GEN003900 The hosts.lpd file (or equivalent) must not contain a ‘+’ character. <VulnDiscussion>Having the '+' character in the hosts.lpd (or equivalent) file allows all hosts to use local system print resources.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Configure cups to use only the localhost or specified remote hosts. Procedure: Modify the /etc/cups/cupsd.conf file to "Listen" only to the local machine or a known set of hosts (i.e., Listen localhost:631). Modify the /etc/cups/cupsd.conf file "<Location />" element to "Deny From All" and "Allow from 127.0.0.1" or allowed host addresses. Restart cups: # service cups restart RHEL uses "cups" print service. Verify remote host access is limited. Procedure: # grep -i Listen /etc/cups/cupsd.conf The /etc/cups/cupsd.conf file must not contain a Listen *:<port> or equivalent line. If the network address of the "Listen" line is unrestricted, this is a finding. # grep -i "Allow From" /etc/cups/cupsd.conf The "Allow From" line within the "<Location />" element should limit access to the printers to @LOCAL and specific hosts. If the "Allow From" line contains "All" this is a finding GEN003920 <GroupDescription></GroupDescription> GEN003920 The hosts.lpd (or equivalent) file must be owned by root, bin, sys, or lp. <VulnDiscussion>Failure to give ownership of the hosts.lpd file to root, bin, sys, or lp provides the designated owner, and possible unauthorized users, with the potential to modify the hosts.lpd file. Unauthorized modifications could disrupt access to local printers from authorized remote hosts or permit unauthorized remote access to local printers.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the owner of the /etc/cups/printers.conf to root. Procedure: # chown root /etc/cups/printers.conf Check the ownership of the print service configuration file. Procedure: # ls -lL /etc/cups/printers.conf; If no print service configuration file is found, this is not applicable. If the owner of the file is not root, this is a finding GEN003940 <GroupDescription></GroupDescription> GEN003940 The hosts.lpd (or equivalent) must have mode 0644 or less permissive. <VulnDiscussion>Excessive permissions on the hosts.lpd (or equivalent) file may permit unauthorized modification. Unauthorized modifications could disrupt access to local printers from authorized remote hosts or permit unauthorized remote access to local printers.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the /etc/cups/printers.conf file to 0664 or less permissive. Procedure: # chmod 0664 /etc/cups/printers.conf Check the mode of the print service configuration file. Procedure: # ls -lL /etc/cups/printers.conf If no print service configuration file is found, this is not applicable. If the mode of the print service configuration file is more permissive than 0664, this is a finding. GEN004360 <GroupDescription></GroupDescription> GEN004360 The alias file must be owned by root. <VulnDiscussion>If the alias file is not owned by root, an unauthorized user may modify the file adding aliases to run malicious code or redirect e-mail.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the owner of the /etc/aliases file to root. Procedure: for sendmail: # chown root /etc/aliases # chown root /etc/aliases.db for postfix # chown root /etc/postfix/aliases # chown root /etc/postfix/aliases.db If the "sendmail" and "postfix" packages are not installed, this is not applicable. Check the ownership of the alias files. Procedure: for sendmail: # ls -lL /etc/aliases # ls -lL /etc/aliases.db If all the files are not owned by root, this is a finding. for postfix: Verify the location of the alias file. # postconf alias maps This will return the location of the "aliases" file, by default "/etc/postfix/aliases" # ls -lL <postfix aliases file> # ls -lL <postfix aliases.db file> If all the files are not owned by root, this is a finding. GEN004380 <GroupDescription></GroupDescription> GEN004380 The alias file must have mode 0644 or less permissive. <VulnDiscussion>Excessive permissions on the aliases file may permit unauthorized modification. If the alias file is modified by an unauthorized user, they may modify the file to run malicious code or redirect e-mail.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the alias files as needed to function. No higher than 0644. Procedure: for sendmail: # chmod 0644 /etc/aliases /etc/aliases.db for postfix (assuming the default postfix directory): # chmod 0644 /etc/postfix/aliases /etc/postfix/aliases.db If the "sendmail" and "postfix" packages are not installed, this is not applicable. Check the permissions of the alias file. Procedure: for sendmail: # ls -lL /etc/aliases /etc/aliases.db If an alias file has a mode more permissive than 0644, this is a finding. for postfix: Verify the location of the alias file. # postconf alias maps This will return the location of the "aliases" file, by default "/etc/postfix/aliases" # ls -lL <postfix aliases file> <postfix aliases.db file> If an alias file has a mode more permissive than 0644, this is a finding. GEN004400 <GroupDescription></GroupDescription> GEN004400 Files executed through a mail aliases file must be owned by root and must reside within a directory owned and writable only by root. <VulnDiscussion>If a file executed through a mail aliases file is not owned and writable only by root, it may be subject to unauthorized modification. Unauthorized modification of files executed through aliases may allow unauthorized users to attain root privileges.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Edit the /etc/aliases file (alternatively, /usr/lib/sendmail.cf). Locate the entries executing a program. They will appear similar to the following line: Aliasname: : /usr/local/bin/ls (or some other program name) Ensure root owns the programs and the directory(ies) they reside in by using the chown command to change owner to root. Procedure: # chown root <file or directory name> Verify the ownership of files referenced within the sendmail aliases file. Procedure: # more /etc/aliases Examine the aliases file for any utilized directories or paths. # ls -lL <directory or file path> Check the owner for any paths referenced. Check if the file or parent directory is owned by root. If not, this is a finding. GEN004420 <GroupDescription></GroupDescription> GEN004420 Files executed through a mail aliases file must have mode 0755 or less permissive. <VulnDiscussion>If a file executed through a mail aliases file has permissions greater than 0755, it can be modified by an unauthorized user and may contain malicious code or instructions potentially compromising the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Use the chmod command to change the access permissions for files executed from the alias file. For example: # chmod 0755 filename If the "sendmail" package is not installed, this is not applicable. Examine the contents of the /etc/aliases file. Procedure: # more /etc/aliases Examine the aliases file for any referenced programs, which are specified with the pipe (|) symbol. # ls -lL <file referenced from aliases> Check the permissions for any paths referenced. If any file referenced from the aliases file has a mode more permissive than 0755, this is a finding. GEN004440 <GroupDescription></GroupDescription> GEN004440 Sendmail logging must not be set to less than nine in the sendmail.cf file. <VulnDiscussion>If Sendmail is not configured to log at level 9, system logs may not contain the information necessary for tracking unauthorized use of the sendmail service.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit the sendmail.cf file, locate the "O L" or "LogLevel" entry and change it to 9. If the "sendmail" package is not installed, this is not applicable. Check if sendmail logging is set to level nine: Procedure: for sendmail: # grep "O L" /etc/mail/sendmail.cf OR # grep LogLevel /etc/mail/sendmail.cf If logging is set to less than nine, this is a finding. for Postfix: This rule is not applicable to postfix which does not use "log levels" in the same fashion as sendmail. GEN004460 <GroupDescription></GroupDescription> GEN004460 The system syslog service must log informational and more severe SMTP service messages. <VulnDiscussion>If informational and more severe SMTP service messages are not logged, malicious activity on the system may go unnoticed.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3, ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000126 Edit the syslog.conf file and add a configuration line specifying an appropriate destination for "mail.crit" or "mail.*" syslog messages. Check the syslog configuration file for mail.crit logging configuration. Procedure: # grep "mail\." /etc/syslog.conf If syslog is not configured to log critical sendmail messages ("mail.crit" or "mail.*"), this is a finding. GEN004480 <GroupDescription></GroupDescription> GEN004480 The SMTP service log file must be owned by root. <VulnDiscussion>If the SMTP service log file is not owned by root, then unauthorized personnel may modify or delete the file to hide a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the ownership of the sendmail log file. Procedure: The fix procedure is the same for both sendmail and Postfix. # chown root <sendmail log file> Locate any mail log files by checking the syslog configuration file. Procedure: The check procedure is the same for both sendmail and Postfix. Identify any log files configured for the "mail" service (excluding mail.none) at any severity level and check the ownership # egrep "mail\.[^n][^/]*" /etc/syslog.conf|sed 's/^[^/]*//'|xargs ls -lL If any mail log file is not owned by root, this is a finding. GEN004500 <GroupDescription></GroupDescription> GEN004500 The SMTP service log file must have mode 0644 or less permissive. <VulnDiscussion>If the SMTP service log file is more permissive than 0644, unauthorized users may be allowed to change the log file.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the SMTP service log file. Procedure: The fix procedure is the same for both sendmail and Postfix. # chmod 0644 <sendmail log file> Check the mode of the SMTP service log file. Procedure: The check procedure is the same for both sendmail and Postfix. Identify any log files configured for the "mail" service (excluding mail.none) at any severity level and check the permissions # egrep "mail\.[^n][^/]*" /etc/syslog.conf|sed 's/^[^/]*//'|xargs ls -lL If the log file permissions are greater than 0644, this is a finding. GEN004880 <GroupDescription></GroupDescription> GEN004880 The ftpusers file must exist. <VulnDiscussion>The ftpusers file contains a list of accounts not allowed to use FTP to transfer files. If this file does not exist, then unauthorized accounts can utilize FTP.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Create an ftpusers file appropriate for the running FTP service. For gssftp: Create an /etc/ftpusers file containing a list of accounts not authorized for FTP. For vsftp: Create an /etc/vsftpd.ftpusers or /etc/vsftpd/ftpusers (as appropriate) file containing a list of accounts not authorized for FTP. Check for the existence of the ftpusers file. Procedure: For gssftp: # ls -l /etc/ftpusers For vsftp: # ls -l /etc/vsftpd.ftpusers or # ls -l /etc/vsftpd/ftpusers If the appropriate ftpusers file for the running FTP service does not exist, this is a finding. GEN004900 <GroupDescription></GroupDescription> GEN004900 The ftpusers file must contain account names not allowed to use FTP. <VulnDiscussion>The ftpusers file contains a list of accounts not allowed to use FTP to transfer files. If the file does not contain the names of all accounts not authorized to use FTP, then unauthorized use of FTP may take place.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 For gssftp: Add accounts not allowed to use FTP to the /etc/ftpusers file. For vsftp: Add accounts not allowed to use FTP to the /etc/vsftpd.ftpusers or /etc/vsftpd/ftpusers file (as appropriate). Check the contents of the ftpusers file. For gssftp: # more /etc/ftpusers For vsftp: # more /etc/vsftpd.ftpusers /etc/vfsftpd/ftpusers If the system has accounts not allowed to use FTP and not listed in the ftpusers file, this is a finding. GEN004920 <GroupDescription></GroupDescription> GEN004920 The ftpusers file must be owned by root. <VulnDiscussion>If the file ftpusers is not owned by root, an unauthorized user may modify the file to allow unauthorized accounts to use FTP.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the owner of the ftpusers file to root. For gssftp: # chown root /etc/ftpusers For vsftp: # chown root /etc/vsftpd.ftpusers /etc/vsftpd/ftpusers Check the ownership of the ftpusers file. Procedure: For gssftp: # ls -l /etc/ftpusers For vsftp: # ls -l /etc/vsftpd.ftpusers /etc/vsftpd/ftpusers If the ftpusers file is not owned by root, this is a finding GEN004940 <GroupDescription></GroupDescription> GEN004940 The ftpusers file must have mode 0640 or less permissive. <VulnDiscussion>Excessive permissions on the ftpusers file could permit unauthorized modification. Unauthorized modification could result in Denial of Service to authorized FTP users or permit unauthorized users to access the FTP service.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the ftpusers file to 0640. Procedure: For gssftp: # chmod 0640 /etc/ftpusers For vsftp: # chmod 0640 /etc/vsftpd.ftpusers /etc/vsftpd/ftpusers Check the permissions of the ftpusers file. Procedure: For gssftp: # ls -l /etc/ftpusers For vsftp: # ls -l /etc/vsftpd.ftpusers /etc/vsftpd/ftpusers If the ftpusers file has a mode more permissive than 0640, this is a finding. GEN004980 <GroupDescription></GroupDescription> GEN004980 The FTP daemon must be configured for logging or verbose mode. <VulnDiscussion>The -l option allows basic logging of connections. The verbose (on HP) and the debug (on Solaris) allow logging of what files the ftp session transferred. This extra logging makes it possible to easily track which files are being transferred onto or from a system. If they are not configured, the only option for tracking is the audit files. The audit files are much harder to read. If auditing is not properly configured, then there would be no record at all of the file transfer transactions.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000130 Enable logging by changing ftpd startup or config files. Procedure: The procedure depends on the implementation of ftpd used by the system. For vsftpd: Ensure the server settings in "/etc/vsftpd.conf" (or other configuration file specified by the vaftpd xinetd.d startup file) contains: xferlog_enable = yes For gssftp: If the "disable" server setting is missing or set to "no" in "/etc/xinetd.d/gssftp" then ensure the server settings in "/etc/xinetd.d/gssftp" contains: server_args = -l The -l option may be added up to three times. Each -l will provide increasing verbosity on the log. Refer to the main page for ftpd for more information. For both if started using xinetd: If the "disable" server setting is missing or set to "no" in the /etc/xinetd.d startup file then ensure the server settings contains: log_on_success += DURATION USERID This will log the startup and shutdown of the daemon. log_on_failure += HOST USERID Find if logging is applied to the ftp daemon. The procedure depends on the implementation of ftpd used by the system. Procedures: For vsftpd: If vsftpd is started by xinetd: #grep vsftpd /etc/xinetd.d/* This will indicate the xinetd.d startup file #grep server_args <vsftpd xinetd.d startup file> This will indicate the vsftpd config file used when starting through xinetd. If the line is missing then "/etc/vsftpd/vsftpd.conf", the default config file, is used. #grep xferlog_enable <vsftpd config file> If "xferlog_enable" is missing or is not set to "yes", this is a finding. If vsftp is not started by xinetd: #grep xferlog_enable /etc/vsftpd/vsftpd.conf If "xferlog_enable" is missing or is not set to "yes", this is a finding. For gssftp: Find if the -l option will be applied when xinetd starts gssftp # grep server_args /etc/xinetd.d/gssftp If the line is missing or does not contain at least one -l, this is a finding. GEN004820 <GroupDescription></GroupDescription> GEN004820 Anonymous FTP must not be active on the system unless authorized. <VulnDiscussion>Due to the numerous vulnerabilities inherent in anonymous FTP, it is not recommended. If anonymous FTP must be used on a system, the requirement must be authorized and approved in the system accreditation package.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>true</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><Responsibility>Information Assurance Officer</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001475 Configure the FTP service to not permit anonymous logins. Attempt to log into this host with a user name of anonymous and a password of guest (also try the password of guest@mail.com). If the logon is successful and the use of anonymous ftp has not been documented and approved by the IAO, this is a finding. Procedure: # ftp localhost Name: anonymous 530 Guest login not allowed on this machine. GEN005080 <GroupDescription></GroupDescription> GEN005080 The TFTP daemon must operate in "secure mode" which provides access only to a single directory on the host file system. <VulnDiscussion>Secure mode limits TFTP requests to a specific directory. If TFTP is not running in secure mode, it may be able to write to any file or directory and may seriously impair system integrity, confidentiality, and availability.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit /etc/xinetd.d/tftp file and specify the "-s" parameter in server_args. # grep server_args /etc/xinetd.d/tftp If the "-s" parameter is not specified, this is a finding. GEN005100 <GroupDescription></GroupDescription> GEN005100 The TFTP daemon must have mode 0755 or less permissive. <VulnDiscussion>If TFTP runs with the setuid or setgid bit set, it may be able to write to any file or directory and may seriously impair system integrity, confidentiality, and availability.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECPA-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the TFTP daemon. Procedure: # chmod 0755 <in.tftpd binary> Check the mode of the TFTP daemon. Procedure: # grep "server " /etc/xinetd.d/tftp # ls -lL <in.tftpd binary> If the mode of the file is more permissive than 0755, this is a finding. GEN005120 <GroupDescription></GroupDescription> GEN005120 The TFTP daemon must be configured to vendor specifications, including a dedicated TFTP user account, a non-login shell such as /bin/false, and a home directory owned by the TFTP user. <VulnDiscussion>If TFTP has a valid shell, it increases the likelihood someone could log on to the TFTP account and compromise the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Configure TFTP to use a dedicated "tftp" user. Procedure: Create a dedicated "tftp" user account if none exists. Assign a non-login shell to the "tftp" user account, such as /bin/false. Assign a home directory to the "tftp" user account. Edit /etc/xinetd.d/tftp to have "tftp" as the value of the "user" parameter. Check the /etc/passwd file to determine if TFTP is configured properly. Procedure: Check if TFTP if used. # grep disable /etc/xinetd.d/tftp If the file does not exist or the returned line indicates "yes", then this is not a finding. Otherwise, if the returned line indicates "no" then TFTP is enabled and must use a dedicated "tftp" user. # grep user /etc/xinetd.d/tftp If the returned line indicates a user other than the dedicated "tftp" user, this is a finding. # grep tftp /etc/passwd If a "tftp" user account does not exist and TFTP is active, this is a finding. Check the user shell for the "tftp" user. If it is not /bin/false or equivalent, this is a finding. Check the home directory assigned to the "tftp" user. If no home directory is set, or the directory specified is not dedicated to the use of the TFTP service, this is a finding. GEN005160 <GroupDescription></GroupDescription> GEN005160 Any X Windows host must write .Xauthority files. <VulnDiscussion>.Xauthority files ensure the user is authorized to access specific X Windows host. If .Xauthority files are not used, it may be possible to obtain unauthorized access to the X Windows host.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000297 Ensure the X Windows host is configured to write .Xauthority files into user home directories. Edit the Xaccess file. Ensure the line writing the .Xauthority file is uncommented. Check for .Xauthority or .xauth files being utilized by looking for such files in the home directory of a user. Procedure: Verify Xwindows is used on the system. # egrep "^x:5.*X11" /etc/inittab If no line is returned the boot process does not start Xwindows. If Xwindows is not configured to run, this rule is not applicable. Look for xauthority files in user home directory. # cd ~someuser # ls -la|egrep "(\.Xauthority|\.xauth)" If the .Xauthority or .xauth (followed by apparently random characters) files do not exist, ask the SA if the user is using Xwindows. If the user is utilizing Xwindows and none of these files exist, this is a finding. GEN006400 <GroupDescription></GroupDescription> GEN006400 The Network Information System (NIS) protocol must not be used. <VulnDiscussion>Due to numerous security vulnerabilities existing within NIS, it must not be used. Possible alternative directory services are NIS+ and LDAP.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><Responsibility>Information Assurance Officer</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001435 Disable the use of NIS/NIS+. Use as a replacement Kerberos or LDAP. Perform the following to determine if NIS is active on the system: # ps -ef | grep ypbind If NIS is found active on the system, this is a finding. GEN001440 <GroupDescription></GroupDescription> GEN001440 All interactive users must be assigned a home directory in the /etc/passwd file. <VulnDiscussion>If users do not have a valid home directory, there is no place for the storage and control of files they own.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Assign a home directory to any user without one. Use pwck to verify home directory assignments are present. # pwck If any user is not assigned a home directory, this is a finding. GEN001460 <GroupDescription></GroupDescription> GEN001460 All interactive user home directories defined in the /etc/passwd file must exist. <VulnDiscussion>If a user has a home directory defined that does not exist, the user may be given the / directory, by default, as the current working directory upon logon. This could create a Denial of Service because the user would not be able to perform useful tasks in this location.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 If a user has no home directory, determine why. If possible, delete accounts without a home directory. If the account is valid, then create the home directory using the appropriate system administration utility or manually. For instance: mkdir directoryname; copy the skeleton files into the directory; chown accountname for the new directory and the skeleton files. Document all changes. Use pwck to verify assigned home directories exist. # pwck If any user's assigned home directory does not exist, this is a finding. GEN001480 <GroupDescription></GroupDescription> GEN001480 All user home directories must have mode 0750 or less permissive. <VulnDiscussion>Excessive permissions on home directories allow unauthorized access to user files.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4090-7 CCI-000225 Change the mode of user home directories to 0750 or less permissive. Procedure (example): # chmod 0750 <home directory> Note: Application directories are allowed and may need 0755 permissions (or greater) for correct operation. Check the home directory mode of each user in /etc/passwd. Procedure: # cut -d: -f6 /etc/passwd|sort|uniq|xargs -n1 ls -ld If a user home directory's mode is more permissive than 0750, this is a finding. Note: Application directories are allowed and may need 0755 permissions (or greater) for correct operation. GEN001500 <GroupDescription></GroupDescription> GEN001500 All interactive user home directories must be owned by their respective users. <VulnDiscussion>If users do not own their home directories, unauthorized users could access user files.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the owner of a user's home directory to its assigned user. Procedure: # chown <user> <home directory> Check the ownership of each user home directory listed in the /etc/passwd file. Procedure: # cut -d : -f 6 /etc/passwd | xargs -n1 ls -ld If any user home directory is not owned by the assigned user, this is a finding. GEN001520 <GroupDescription></GroupDescription> GEN001520 All interactive user home directories must be group-owned by the home directory owner's primary group. <VulnDiscussion>If the Group Identifier (GID) of the home directory is not the same as the GID of the user, this would allow unauthorized access to files.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group-owner for user home directories to the primary group of the assigned user. Procedure: Find the primary group of the user (GID) which is the fourth field of the user entry in /etc/passwd. # chgrp <GID> <user home directory> Document all changes. Check the group ownership for each user in the /etc/passwd file. Procedure: # cut -d : -f 6 /etc/passwd | xargs -n1 ls -ld If any user home directory is not group-owned by the assigned user's primary group, this is a finding. Home directories for application accounts requiring different group ownership must be documented using site-defined procedures. GEN001860 <GroupDescription></GroupDescription> GEN001860 All local initialization files must be owned by the home directorys user or root. <VulnDiscussion>Local initialization files are used to configure the user's shell environment upon login. Malicious modification of these files could compromise accounts upon logon.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the ownership of the startup and login files in the user's directory to the user or root, as appropriate. Examine each user's home directory and verify all filenames beginning with "." are owned by the owner of the directory or root. If they are not, use the chown command to change the owner to the user and research the reasons why the owners were not assigned as required. Procedure: # chown username .filename Document all changes. NOTE: The following commands must be run in the BASH shell. Check the ownership of local initialization files. Procedure: # ls -al /<usershomedirectory>/.login # ls -al /<usershomedirectory>/.cshrc # ls -al /<usershomedirectory>/.logout # ls -al /<usershomedirectory>/.profile # ls -al /<usershomedirectory>/.bash_profile # ls -al /<usershomedirectory>/.bashrc # ls -al /<usershomedirectory>/.bash_logout # ls -al /<usershomedirectory>/.env # ls -al /<usershomedirectory>/.dtprofile # ls -al /<usershomedirectory>/.dispatch # ls -al /<usershomedirectory>/.emacs # ls -al /<usershomedirectory>/.exrc # find /<usershomedirectory>/.dt ! -fstype nfs ! -user <username> -exec ls -ld {} \; If local initialization files are not owned by the home directory's user, this is a finding. GEN001880 <GroupDescription></GroupDescription> GEN001880 All local initialization files must have mode 0740 or less permissive. <VulnDiscussion>Local initialization files are used to configure the user's shell environment upon login. Malicious modification of these files could compromise accounts upon logon.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Ensure user startup files have permissions of 0740 or more restrictive. Examine each user's home directory and verify all file names beginning with "." have access permissions of 0740 or more restrictive. If they do not, use the chmod command to correct the vulnerability. Procedure: # chmod 0740 .filename Note: The period is part of the file name and is required. Check the modes of local initialization files. Procedure: # ls -al /<usershomedirectory>/.bashrc # ls -al /<usershomedirectory>/.bash_login # ls -al /<usershomedirectory>/.bash_logout # ls -al /<usershomedirectory>/.bash_profile # ls -al /<usershomedirectory>/.cshrc # ls -al /<usershomedirectory>/.kshrc # ls -al /<usershomedirectory>/.login # ls -al /<usershomedirectory>/.logout # ls -al /<usershomedirectory>/.profile # ls -al /<usershomedirectory>/.tcshrc # ls -al /<usershomedirectory>/.env # ls -al /<usershomedirectory>/.dtprofile (permissions should be 0755) # ls -al /<usershomedirectory>/.dispatch # ls -al /<usershomedirectory>/.emacs # ls -al /<usershomedirectory>/.exrc # find /<usershomedirectory>/.dt ! -fstype nfs \( -perm -0002 -o -perm -0020 \) -exec ls -ld {} \; (permissions not to be more permissive than 0755) If local initialization files are more permissive than 0740 or the .dt directory is more permissive than 0755 or the .dtprofile file is more permissive than 0755, this is a finding. GEN001580 <GroupDescription></GroupDescription> GEN001580 All run control scripts must have mode 0755 or less permissive. <VulnDiscussion>If the startup files are writable by other users, they could modify the startup files to insert malicious commands into the startup files.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Ensure all system startup files have mode 0755 or less permissive. Examine the "rc" files, and all files in the rc1.d (rc2.d, and so on) directories, and in the /etc/init.d directory to ensure they are not world-writable. If they are world-writable, use the chmod command to correct the vulnerability and research why they are world-writable. Procedure: # chmod 755 <startup file> Check run control script modes. # cd /etc # ls -lL rc* # cd /etc/init.d # ls -l If any run control script has a mode more permissive than 0755, this is a finding. GEN001600 <GroupDescription></GroupDescription> GEN001600 Run control scripts' executable search paths must contain only absolute paths. <VulnDiscussion>The executable search path (typically the PATH environment variable) contains a list of directories for the shell to search to find executables. If this path includes the current working directory or other relative paths, executables in these directories may be executed instead of system commands. This variable is formatted as a colon-separated list of directories. If there is an empty entry, such as a leading or trailing colon, or two consecutive colons, this is interpreted as the current working directory. Paths starting with a slash (/) are absolute paths.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit the run control script and remove the relative path entry from the executable search path variable. Verify run control scripts' library search paths. # grep -r PATH /etc/rc* /etc/init.d This variable is formatted as a colon-separated list of directories. If there is an empty entry, such as a leading or trailing colon, or two consecutive colons, this is a finding. If an entry begins with a character other than a slash (/), this is a relative path, this is a finding. GEN001640 <GroupDescription></GroupDescription> GEN001640 Run control scripts must not execute world-writable programs or scripts. <VulnDiscussion>World-writable files could be modified accidentally or maliciously to compromise system integrity.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the world-writable permission from programs or scripts executed by run control scripts. Procedure: # chmod o-w <program or script executed from run control script> Check the permissions on the files or scripts executed from system startup scripts to see if they are world-writable. Create a list of all potential run command level scripts. ls -l /etc/init.d/* | tr '\011' ' ' | tr -s ' ' | cut -f 9,9 -d " " Create a list of world writeable files. # find / -perm -002 -type f >> worldWriteableFileList Determine if any of the world writeable files in worldWriteableFileList are called from the run command level scripts. Note: Depending upon the number of scripts vs world writeable files, it may be easier to inspect the scripts manually. # more `ls -l /etc/init.d/* | tr '\011' ' ' | tr -s ' ' | cut -f 9,9 -d "` If any system startup script executes any file or script that is world-writable, this is a finding. GEN002000 <GroupDescription></GroupDescription> GEN002000 There must be no .netrc files on the system. <VulnDiscussion>Unencrypted passwords for remote FTP servers may be stored in .netrc files. Policy requires passwords be encrypted in storage and not used in access scripts.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2, IAIA-1, IAIA-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000196 Remove the .netrc file(s). Procedure: # find / -name .netrc # rm <.netrc file> Check the system for the existence of any .netrc files. Procedure: # find / -name .netrc If any .netrc file exists, this is a finding. GEN001540 <GroupDescription></GroupDescription> GEN001540 All files and directories contained in interactive user home directories must be owned by the home directory's owner. <VulnDiscussion>If users do not own the files in their directories, unauthorized users may be able to access them. Additionally, if files are not owned by the user, this could be an indication of system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>true</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><Responsibility>Information Assurance Officer</Responsibility><IAControls>ECCD-1, ECCD-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the ownership of files and directories in user home directories to the owner of the home directory. Procedure: # chown accountowner filename For each user in the /etc/passwd file, check for the presence of files and directories within the user's home directory not owned by the home directory owner. Procedure: # find /<usershomedirectory> ! -fstype nfs ! -user <username> ! \( -name .bashrc -o -name .bash_login -o -name .bash_logout -o -name .bash_profile -o -name .cshrc -o -name .kshrc -o -name .login -o -name .logout -o -name .profile -o -name .tcshrc -o -name .env -o -name .dtprofile -o -name .dispatch -o -name .emacs -o -name .exrc \) -exec ls -ld {} \; If user home directories contain files or directories not owned by the home directory owner, this is a finding. GEN001560 <GroupDescription></GroupDescription> GEN001560 All files and directories contained in user home directories must have mode 0750 or less permissive. <VulnDiscussion>Excessive permissions allow unauthorized access to user files. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>true</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of files and directories within user home directories to 0750. Procedure: # chmod 0750 filename Document all changes. For each user in the /etc/passwd file, check for files and directories with a mode more permissive than 0750. Procedure: # find /<usershomedirectory> ! -fstype nfs ! \( -name .bashrc -o -name .bash_login -o -name .bash_logout -o -name .bash_profile -o -name .cshrc -o -name .kshrc -o -name .login -o -name .logout -o -name .profile -o -name .tcshrc -o -name .env -o -name .dtprofile -o -name .dispatch -o -name .emacs -o -name .exrc \) \( -perm -0001 -o -perm -0002 -o -perm -0004 -o -perm -0020 -o -perm -2000 -o -perm -4000 \) -exec ls -ld {} \; If user home directories contain files or directories more permissive than 0750, this is a finding. GEN002120 <GroupDescription></GroupDescription> GEN002120 The /etc/shells (or equivalent) file must exist. <VulnDiscussion>The shells file (or equivalent) lists approved default shells. It helps provide layered defense to the security approach by ensuring users cannot change their default shell to an unauthorized unsecure shell.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Create a /etc/shells file containing a list of valid system shells. Consult vendor documentation for an appropriate list of system shells. Procedure: # echo "/bin/bash" >> /etc/shells # echo "/bin/csh" >> /etc/shells (Repeat as necessary for other shells.) Verify /etc/shells exists. # ls -l /etc/shells If the file does not exist, this is a finding. GEN002140 <GroupDescription></GroupDescription> GEN002140 All shells referenced in /etc/passwd must be listed in the /etc/shells file, except any shells specified for the purpose of preventing logins. <VulnDiscussion>The shells file lists approved default shells. It helps provide layered defense to the security approach by ensuring users cannot change their default shell to an unauthorized unsecure shell.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Use the "chsh" utility or edit the /etc/passwd file and correct the error by changing the default shell of the account in error to an acceptable shell name contained in the /etc/shells file. Example: # chsh -s /bin/bash testuser Confirm the login shells referenced in the /etc/passwd file are listed in the /etc/shells file. Procedure: # for USHELL in `cut -d: -f7 /etc/passwd`; do if [ $(grep -c "${USHELL}" /etc/shells) == 0 ]; then echo "${USHELL} not in /etc/shells"; fi; done The /usr/bin/false, /bin/false, /dev/null, /sbin/nologin, /bin/sync, /sbin/halt, /sbin/shutdown, (and equivalents), and sdshell will be considered valid shells for use in the /etc/passwd file, but will not be listed in the /etc/shells file. If a shell referenced in /etc/passwd is not listed in the shells file, excluding the above mentioned shells, this is a finding. GEN000760 <GroupDescription></GroupDescription> GEN000760 Accounts must be locked upon 35 days of inactivity. <VulnDiscussion>On some systems, accounts with disabled passwords still allow access using rcp, remsh, or rlogin through equivalent remote hosts. All that is required is the remote host name and the user name match an entry in a hosts.equiv file and have a .rhosts file in the user directory. Using a shell called /bin/false or /dev/null (or an equivalent) will add a layered defense. Non-interactive accounts on the system, such as application accounts, may be documented exceptions.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>true</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAAC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000017 All inactive accounts will have /sbin/nologin (or an equivalent), as the default shell in the /etc/passwd file and have the password disabled. Examine the user accounts using the "last" command. Note the date of last login for each account. If any (other than system and application accounts) exceed 35 days or the maximum number of days set by the site, not to exceed 35 days, then disable the accounts using system-config-users tool. Alternately place a shell field of /sbin/nologin /bin/false or /dev/null in the passwd file entry for the account. Indications of inactive accounts are those that have no entries in the "last" log. Check the date in the "last" log to verify it is within the last 35 days or the maximum numbers of days set by the site if more restrictive. If an inactive account is not disabled via an entry in the password field in the /etc/passwd or /etc/shadow (or equivalent), check the /etc/passwd file to check if the account has a valid shell. The passwd command can also be used to list a status for an account. For example, the following may be used to provide status information on each local account: NOTE: The following must be done in the BASH shell. # cut -d: -f1 /etc/passwd | xargs -n1 passwd -S If an inactive account is found not disabled, this is a finding. GEN002200 <GroupDescription></GroupDescription> GEN002200 All shell files must be owned by root or bin. <VulnDiscussion>If shell files are owned by users other than root or bin, they could be modified by intruders or malicious users to perform unauthorized actions.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the ownership of the shell with incorrect ownership. # chown root <shell> Check the ownership of the system shells. # cat /etc/shells | xargs -n1 ls -l If any shell is not owned by root or bin, this is a finding. GEN002220 <GroupDescription></GroupDescription> GEN002220 All shell files must have mode 0755 or less permissive. <VulnDiscussion>Shells with world/group write permissions give the ability to maliciously modify the shell to obtain unauthorized access.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the shell. # chmod 0755 <shell> If /etc/shells exists, check the group ownership of each shell referenced. # cat /etc/shells | xargs -n1 ls -l Otherwise, check any shells found on the system. # find / -name "*sh" | xargs -n1 ls -l If a shell has a mode more permissive than 0755, this is a finding. GEN002260 <GroupDescription></GroupDescription> GEN002260 The system must be checked for extraneous device files at least weekly. <VulnDiscussion>If an unauthorized device is allowed to exist on the system, there is the possibility the system may perform unauthorized operations.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><Responsibility>Information Assurance Officer</Responsibility><IAControls>DCSW-1, ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000318 Establish a weekly automated or manual process to create a list of device files on the system and determine if any files have been added, moved, or deleted since the last list was generated. A list of device files can be generated with this command: # find / -type b -o -type c > device-file-list Ask the SA for the automated or manual process used to check for extraneous device files. Review the process to determine if the system is checked for extraneous device files on a weekly basis. If no weekly automated or manual process is in place, this is a finding. If the process is not identifying extraneous device files, this is a finding. GEN002280 <GroupDescription></GroupDescription> GEN002280 Device files and directories must only be writable by users with a system account or as configured by the vendor. <VulnDiscussion>System device files in writable directories could be modified, removed, or used by an unprivileged user to control system hardware.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2, ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the world-writable permission from the device file(s). Procedure: # chmod o-w <device file> Document all changes. Find all world-writable device files existing anywhere on the system. Procedure: # find / -perm -2 -a \( -type b -o -type c \) > devicelist Check the permissions on the directories above subdirectories containing device files. If any of the device files or their parent directories are world-writable, excepting device files specifically intended to be world-writable such as /dev/null, this is a finding. GEN002300 <GroupDescription></GroupDescription> GEN002300 Device files used for backup must only be readable and/or writable by root or the backup user. <VulnDiscussion>System backups could be accidentally or maliciously overwritten and destroy the ability to recover the system if a compromise should occur. Unauthorized users could also copy system files.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>true</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Use the chmod command to remove the world-writable bit from the backup device files. Procedure: # chmod o-w <back device filename> Document all changes. Check the system for world-writable device files. Procedure: # find / -perm -2 -a \( -type b -o -type c \) -exec ls -ld {} \; Ask the SA to identify any device files used for backup purposes. If any device file(s) used for backup are writable by users other than root or the designated backup user, this is a finding. GEN005740 <GroupDescription></GroupDescription> GEN005740 The Network File System (NFS) export configuration file must be owned by root. <VulnDiscussion>Failure to give ownership of the NFS export configuration file to root provides the designated owner and possible unauthorized users with the potential to change system configuration which could weaken the system's security posture.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the owner of the exports file to root. Example: # chown root /etc/exports Check the owner of the exports file. Example: # ls -lL /etc/exports If the export configuration file is not owned by root, this is a finding. GEN005760 <GroupDescription></GroupDescription> GEN005760 The Network File System (NFS) export configuration file must have mode 0644 or less permissive. <VulnDiscussion>Excessive permissions on the NFS export configuration file could allow unauthorized modification of the file, which could result in Denial of Service to authorized NFS exports and the creation of additional unauthorized exports.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2, ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 # chmod 0644 /etc/exports # ls -lL /etc/exports If the file has a mode more permissive than 0644, this is a finding. GEN005800 <GroupDescription></GroupDescription> GEN005800 All Network File System (NFS) exported system files and system directories must be owned by root. <VulnDiscussion>Failure to give ownership of sensitive files or directories to root provides the designated owner and possible unauthorized users with the potential to access sensitive information or change system configuration which could weaken the system's security posture.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the ownership of exported file systems not owned by root. Procedure: # chown root <path> Check for NFS exported file systems. Procedure: # cat /etc/exports For each file system displayed, check the ownership. # ls -lLa <exported file system path> If the files and directories are not owned by root, this is a finding. GEN005820 <GroupDescription></GroupDescription> GEN005820 The Network File System (NFS) anonymous UID and GID must be configured to values without permissions. <VulnDiscussion>When an NFS server is configured to deny remote root access, a selected UID and GID are used to handle requests from the remote root user. The UID and GID should be chosen from the system to provide the appropriate level of non-privileged access.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1, IAIA-1, IAIA-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000062 Edit "/etc/exports" and set the "anonuid=-1" and "anongid=-1" options for exports lacking it. Re-export the filesystems. Check if the 'anonuid' and 'anongid' options are set correctly for exported file systems. List exported filesystems: # exportfs -v Each of the exported file systems should include an entry for the 'anonuid=' and 'anongid=' options set to "-1" or an equivalent (60001, 65534, or 65535). If appropriate values for 'anonuid' or 'anongid' are not set, this is a finding. GEN005840 <GroupDescription></GroupDescription> GEN005840 The Network File System (NFS) server must be configured to restrict file system access to local hosts. <VulnDiscussion>The NFS access option limits user access to the specified level. This assists in protecting exported file systems. If access is not restricted, unauthorized hosts may be able to access the system's NFS exports.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit /etc/exports and add ro and/or rw options (as appropriate) specifying a list of hosts or networks which are permitted access. Re-export the file systems. Check the permissions on exported NFS file systems. Procedure: # exportfs -v If the exported file systems do not contain the 'rw' or 'ro' options specifying a list of hosts or networks, this is a finding. GEN005880 <GroupDescription></GroupDescription> GEN005880 The Network File System (NFS) server must not allow remote root access. <VulnDiscussion>If the NFS server allows root access to local file systems from remote hosts, this access could be used to compromise the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Manager</Responsibility><Responsibility>Information Assurance Officer</Responsibility><Responsibility>System Administrator</Responsibility><IAControls>EBRP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4544-3 CCI-000225 Edit the "/etc/exports" file and add "root_squash" (or "all_squash") and remove "no_root_squash". List the exports. # cat /etc/exports If any export contains "no_root_squash" or does not contain "root_squash" or "all_squash", this is a finding. GEN005900 <GroupDescription></GroupDescription> GEN005900 The "nosuid" option must be enabled on all Network File System (NFS) client mounts. <VulnDiscussion>Enabling the nosuid mount option prevents the system from granting owner or group-owner privileges to programs with the suid or sgid bit set. If the system does not restrict this access, users with unprivileged access to the local system may be able to acquire privileged access by executing suid or sgid files located on the mounted NFS file system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>System Administrator</Responsibility><Responsibility>Information Assurance Manager</Responsibility><IAControls>ECPA-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4024-6 CCI-000225 Edit "/etc/fstab" and add the "nosuid" option for all NFS file systems. Remount the NFS file systems to make the change take effect. Check the system for NFS mounts not using the "nosuid" option. Procedure: # mount -v | grep " type nfs " | egrep -v "nosuid" If the mounted file systems do not have the "nosuid" option, this is a finding. GEN006580 <GroupDescription></GroupDescription> GEN006580 The system must use an access control program. <VulnDiscussion>Access control programs (such as TCP_WRAPPERS) provide the ability to enhance system security posture.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>EBRU-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Install and configure the tcp_wrappers package. The tcp_wrappers package is provided with the RHEL distribution. Other access control programs may be available but will need to be checked manually. Determine if tcp_wrappers is installed. # rpm -qa | grep tcp_wrappers If no package is listed, this is a finding. GEN006600 <GroupDescription></GroupDescription> GEN006600 The system's access control program must log each system access attempt. <VulnDiscussion>If access attempts are not logged, then multiple attempts to log on to the system by an unauthorized user may go undetected.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000126 Configure the access restriction program to log every access attempt. Ensure the implementation instructions for tcp_wrappers are followed so system access attempts are recorded to the system log files. If an alternate application is used, it must support this function. The tcp_wrappers package is provided with the RHEL distribution. Other access control programs may be available but will need to be checked manually. Normally, tcpd logs to the mail facility in "/etc/syslog.conf". Determine if syslog is configured to log events by tcpd. Procedure: # more /etc/syslog.conf Look for entries similar to the following: mail.debug /var/adm/maillog mail.none /var/adm/maillog mail.* /var/log/mail authpriv.info /var/log/messages The above entries would indicate mail alerts are being logged. If no entries for mail exist, then tcpd is not logging this is a finding. If an alternate access control program is used and it does not provide logging of access attempts, this is a finding. GEN002960 <GroupDescription></GroupDescription> GEN002960 Access to the cron utility must be controlled using the cron.allow and/or cron.deny file(s). <VulnDiscussion>The cron facility allows users to execute recurring jobs on a regular and unattended basis. The cron.allow file designates accounts allowed to enter and execute jobs using the cron facility. If the cron.allow file is not present, users listed in the cron.deny file are not allowed to use the cron facility. Improper configuration of cron may open the facility up for abuse by system intruders and malicious users.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Create /etc/cron.allow and/or /etc/cron.deny with appropriate content and reboot the system to ensure no lingering cron jobs are processed. This check is not applicable if only the root user is permitted to use cron. Check for the existence of the cron.allow and cron.deny files. # ls -lL /etc/cron.allow # ls -lL /etc/cron.deny If neither file exists, this is a finding. GEN002980 <GroupDescription></GroupDescription> GEN002980 The cron.allow file must have mode 0600 or less permissive. <VulnDiscussion>A readable and/or writable cron.allow file by users other than root could allow potential intruders and malicious users to use the file contents to help discern information, such as who is allowed to execute cron programs, which could be harmful to overall system and network security.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the cron.allow file to 0600. Procedure: # chmod 0600 /etc/cron.allow Check mode of the cron.allow file. Procedure: # ls -lL /etc/cron.allow If the file has a mode more permissive than 0600, this is a finding. GEN003000 <GroupDescription></GroupDescription> GEN003000 Cron must not execute group-writable or world-writable programs. <VulnDiscussion>If cron executes group-writable or world-writable programs, there is a possibility that unauthorized users could manipulate the programs with malicious intent. This could compromise system and network security.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCSL-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the world-writable and group-writable permissions from the cron program file(s) identified. # chmod go-w <cron program file> List all cronjobs on the system. Procedure: # ls /var/spool/cron # ls /etc/cron.d /etc/crontab /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly or # ls /etc/cron*|grep -v deny If cron jobs exist under any of the above directories, use the following command to search for programs executed by cron: # more <cron job file> Perform a long listing of each program file found in the cron file to determine if the file is group-writable or world-writable. # ls -la <cron program file> If cron executes group-writable or world-writable files, this is a finding. GEN003020 <GroupDescription></GroupDescription> GEN003020 Cron must not execute programs in, or subordinate to, world-writable directories. <VulnDiscussion>If cron programs are located in or subordinate to world-writable directories, they become vulnerable to removal and replacement by malicious users or system intruders.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCSL-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the world-writable permission from the cron program directories identified. Procedure: # chmod o-w <cron program directory> List all cronjobs on the system. Procedure: # ls /var/spool/cron # ls /etc/cron.d /etc/crontab /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly or # ls /etc/cron*|grep -v deny If cron jobs exist under any of the above directories, use the following command to search for programs executed by at: # more <cron job file> Perform a long listing of each directory containing program files found in the cron file to determine if the directory is world-writable. # ls -ld <cron program directory> If cron executes programs in world-writable directories, this is a finding. GEN003080 <GroupDescription></GroupDescription> GEN003080 Crontab files must have mode 0600 or less permissive, and files in cron script directories must have mode 0700 or less permissive. <VulnDiscussion>To protect the integrity of scheduled system jobs and prevent malicious modification to these jobs, crontab files must be secured.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the crontab files. # chmod 0600 /var/spool/cron/* /etc/cron.d/* /etc/crontab Check the mode of the crontab files. # ls -lL /var/spool/cron/ # ls -lL /etc/cron.d/ # ls -lL /etc/crontab If any crontab file has a mode more permissive than 0600, this is a finding. GEN003100 <GroupDescription></GroupDescription> GEN003100 Cron and crontab directories must have mode 0755 or less permissive. <VulnDiscussion>To protect the integrity of scheduled system jobs and to prevent malicious modification to these jobs, crontab files must be secured.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the crontab directories. # chmod 0755 <crontab directory> Check the mode of the crontab directories. Procedure: # ls -ld /var/spool/cron # ls -ld /etc/cron.d /etc/crontab /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly or # ls -ld /etc/cron*|grep -v deny If the mode of any of the crontab directories is more permissive than 0755, this is a finding. GEN003120 <GroupDescription></GroupDescription> GEN003120 Cron and crontab directories must be owned by root or bin. <VulnDiscussion>Incorrect ownership of the cron or crontab directories could permit unauthorized users the ability to alter cron jobs and run automated jobs as privileged users. Failure to give ownership of cron or crontab directories to root or to bin provides the designated owner and unauthorized users with the potential to access sensitive information or change the system configuration which could weaken the system's security posture.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the crontab directories. # chown root <crontab directory> Check the owner of the crontab directories. Procedure: # ls -ld /var/spool/cron # ls -ld /etc/cron.d /etc/crontab /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly or # ls -ld /etc/cron*|grep -v deny If the owner of any of the crontab directories is not root or bin, this is a finding. GEN003140 <GroupDescription></GroupDescription> GEN003140 Cron and crontab directories must be group-owned by root, sys, bin or cron. <VulnDiscussion>To protect the integrity of scheduled system jobs and to prevent malicious modification to these jobs, crontab files must be secured. Failure to give group-ownership of cron or crontab directories to a system group provides the designated group and unauthorized users with the potential to access sensitive information or change the system configuration which could weaken the system's security posture.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group owner of cron and crontab directories. # chgrp root <crontab directory> Check the group owner of cron and crontab directories. Procedure: # ls -ld /var/spool/cron # ls -ld /etc/cron.d /etc/crontab /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly or # ls -ld /etc/cron*|grep -v deny If a directory is not group-owned by root, sys, bin, or cron, this is a finding. GEN003160 <GroupDescription></GroupDescription> GEN003160 Cron logging must be implemented. <VulnDiscussion>Cron logging can be used to trace the successful or unsuccessful execution of cron jobs. It can also be used to spot intrusions into the use of the cron facility by unauthorized and malicious users. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000126 Edit /etc/syslog.conf and setup cron logging. # grep cron /etc/syslog.conf If cron logging is not configured, this is a finding. Check the configured cron log file found in the cron entry of /etc/syslog (normally /var/log/cron). # ls -lL /var/log/cron If this file does not exist, or is older than the last cron job, this is a finding. GEN003180 <GroupDescription></GroupDescription> GEN003180 The cronlog file must have mode 0600 or less permissive. <VulnDiscussion>Cron logs contain reports of scheduled system activities and must be protected from unauthorized access or manipulation. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1, ECTP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the cron log file. # chmod 0600 /var/log/cron Check the mode of the cron log file. Procedure: Check the configured cron log file found in the cron entry in /etc/syslog (normally /var/log/cron). # grep cron /etc/syslog.conf # ls -lL /var/log/cron If the mode is more permissive than 0600, this is a finding. GEN003280 <GroupDescription></GroupDescription> GEN003280 Access to the "at" utility must be controlled via the at.allow and/or at.deny file(s). <VulnDiscussion>The "at" facility selectively allows users to execute jobs at deferred times. It is usually used for one-time jobs. The at.allow file selectively allows access to the "at" facility. If there is no at.allow file, there is no ready documentation of who is allowed to submit "at" jobs.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Create at.allow and/or at.deny files containing appropriate lists of users to be allowed or denied access to the "at" daemon. If the "at" package is not installed, this is not applicable. Check for the existence of at.allow and at.deny files. # ls -lL /etc/at.allow # ls -lL /etc/at.deny If neither file exists, this is a finding. GEN003300 <GroupDescription></GroupDescription> GEN003300 The at.deny file must not be empty if it exists. <VulnDiscussion>On some systems, if there is no at.allow file and there is an empty at.deny file, then the system assumes everyone has permission to use the "at" facility. This could create an insecure setting in the case of malicious users or system intruders.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>true</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Add appropriate users to the at.deny file, or remove the empty at.deny file if an at.allow file exists. # more /etc/at.deny If the at.deny file exists and is empty, this is a finding. GEN003320 <GroupDescription></GroupDescription> GEN003320 Default system accounts (with the exception of root) must not be listed in the at.allow file or must be included in the at.deny file if the at.allow file does not exist. <VulnDiscussion>Default accounts, such as bin, sys, adm, uucp, daemon, and others, should never have access to the "at" facility. This would create a possible vulnerability open to intruders or malicious users.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECPA-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the default accounts (such as bin, sys, adm, and others, traditionally UID less than 500) from the at.allow file. # more /etc/at.allow If default accounts (such as bin, sys, adm, and others) are listed in the at.allow file, this is a finding. GEN003340 <GroupDescription></GroupDescription> GEN003340 The at.allow file must have mode 0600 or less permissive. <VulnDiscussion>Permissions more permissive than 0600 (read, write and execute for the owner) may allow unauthorized or malicious access to the at.allow and/or at.deny files.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the at.allow file. # chmod 0600 /etc/at.allow Check the mode of the at.allow file. # ls -lL /etc/at.allow If the at.allow file has a mode more permissive than 0600, this is a finding. GEN003360 <GroupDescription></GroupDescription> GEN003360 The "at" daemon must not execute group-writable or world-writable programs. <VulnDiscussion>If the "at" facility executes world-writable or group-writable programs, it is possible for the programs to be accidentally or maliciously changed or replaced without the owner's intent or knowledge. This would cause a system security breach.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCSL-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove group-write and world-write permissions from files executed by at jobs. Procedure: # chmod go-w <file> List the "at" jobs on the system. Procedure: # ls -la /var/spool/at For each "at" job file, determine which programs are executed. Procedure: # more <at job file> Check the each program executed by "at" for group- or world-writable permissions. Procedure: # ls -la <at program file> If "at" executes group or world-writable programs, this is a finding. GEN003380 <GroupDescription></GroupDescription> GEN003380 The "at" daemon must not execute programs in, or subordinate to, world-writable directories. <VulnDiscussion>If "at" programs are located in, or subordinate, to world-writable directories, they become vulnerable to removal and replacement by malicious users or system intruders.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCSL-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the world-writable permission from directories containing programs executed by "at". Procedure: # chmod o-w <at program directory> List any "at" jobs on the system. Procedure: # ls /var/spool/at For each "at" job, determine which programs are executed by "at." Procedure: # more <at job file> Check the directory containing each program executed by "at" for world-writable permissions. Procedure: # ls -la <at program file directory> If "at" executes programs in world-writable directories, this is a finding. GEN005300 <GroupDescription></GroupDescription> GEN005300 SNMP communities, users, and passphrases must be changed from the default. <VulnDiscussion>Whether active or not, default SNMP passwords, users, and passphrases must be changed to maintain security. If the service is running with the default authenticators, then anyone can gather data about the system and the network and use the information to potentially compromise the integrity of the system or network(s).</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAAC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000178 Change the default passwords. To change them, locate the file snmpd.conf. Edit the file. Locate the line system-group-read-community which has a default password of "public" and make the password something more secure and less guessable. Do the same for the lines reading system-group-write-community, read-community, write-community, trap and trap-community. Read the information in the file carefully. The trap is defining who to send traps to, for instance, by default. It is not a password, but the name of a host. Check the SNMP configuration for default passwords. Procedure: Examine the default install location /etc/snmp/snmpd.conf or: # find / -name snmpd.conf # more <snmpd.conf file> Identify any community names or user password configuration. If any community name or password is set to a default value such as "public", "private", "snmp-trap", or "password", or any value which does not meet DISA password requirements, this is a finding. GEN005320 <GroupDescription></GroupDescription> GEN005320 The snmpd.conf file must have mode 0600 or less permissive. <VulnDiscussion>The snmpd.conf file contains authenticators and must be protected from unauthorized access and modification.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the SNMP daemon configuration file to 0600. Procedure: # chmod 0600 <snmpd.conf> Check the mode of the SNMP daemon configuration file. Procedure: Examine the default install location /etc/snmp/snmpd.conf or: # find / -name snmpd.conf # ls -lL <snmpd.conf file> If the snmpd.conf file has a mode more permissive than 0600, this is a finding. GEN005340 <GroupDescription></GroupDescription> GEN005340 Management Information Base (MIB) files must have mode 0640 or less permissive. <VulnDiscussion>The ability to read the MIB file could impart special knowledge to an intruder or malicious user about the ability to extract compromising information about the system or network.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of MIB files to 0640. Procedure: # chmod 0640 <mib file> Check the modes for all Management Information Base (MIB) files on the system. Procedure: # find / -name *.mib # ls -lL <mib file> Any file returned with a mode 0640 or less permissive is a finding. GEN002480 <GroupDescription></GroupDescription> GEN002480 Public directories must be the only world-writable directories and world-writable files must be located only in public directories. <VulnDiscussion>World-writable files and directories make it easy for a malicious user to place potentially compromising files on the system. The only authorized public directories are those temporary directories supplied with the system or those designed to be temporary file repositories. The setting is normally reserved for directories used by the system and by users for temporary file storage, (e.g., /tmp), and for directories requiring global read/write access.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Remove or change the mode for any world-writable file on the system not required to be world-writable. Procedure: # chmod o-w <file> Document all changes Check the system for world-writable files. Procedure: # find / -perm -2 -a \( -type d -o -type f \) -exec ls -ld {} \; If any world-writable files are located, except those required for system operation such as /tmp and /dev/null, this is a finding. GEN003800 <GroupDescription></GroupDescription> GEN003800 Inetd or xinetd logging/tracing must be enabled. <VulnDiscussion>Inetd or xinetd logging and tracing allows the system administrators to observe the IP addresses connecting to their machines and what network services are being sought. This provides valuable information when trying to find the source of malicious users and potential malicious users.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3, ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000134 Edit each file in the /etc/xinetd.d directory and the /etc/xinetd.conf file to contain: log_type = SYSLOG authpriv log_on_success = HOST PID USERID EXIT log_on_failure = HOST USERID The /etc/xinetd.conf file contains default values that will hold true for all services unless individually modified in the service's xinetd.d file. To make the new settings effective, restart the xinetd service: # service xinetd restart The /etc/xinetd.conf file and each file in the /etc/xinetd.d directory file should be examined for the following: Procedure: log_type = SYSLOG authpriv log_on_success = HOST PID USERID EXIT log_on_failure = HOST USERID If xinetd is running and logging is not enabled, this is a finding. GEN008600 <GroupDescription></GroupDescription> GEN008600 The system must be configured to only boot from the system boot device. <VulnDiscussion>The ability to boot from removable media is the same as being able to boot into single user, or maintenance, mode without a password. This ability could allow a malicious user to boot the system and perform changes with the potential to compromise or damage the system. It could also allow the system to be used for malicious purposes by a malicious anonymous user.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Configure the system to only boot from system startup media. Procedure: On systems with a BIOS or system controller use the BIOS interface at startup to remove all but the proper boot device from the boot device list. Determine if the system is configured to boot from devices other than the system startup media. If so, this is a finding. GEN000000-LNX00360 <GroupDescription></GroupDescription> GEN000000-LNX00360 The X server must have the correct options enabled. <VulnDiscussion>Without the correct options enabled, the Xwindows system would be less secure and there would be no screen timeout.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Enable the following options: -audit (at level 4), -auth and -s with 15 minutes as the timeout value. Procedure for gdm: Edit /etc/gdm/custom.conf and add the following: [server-Standard] name=Standard server command=/usr/bin/Xorg -br -audit 4 -s 15 chooser=false handled=true flexible=true priority=0 Procedure for xinit: Edit or create a .xserverrc file in the users home directory containing the startup script for xinit. This script must have an exec line with at least these options: exec /usr/bin/X -audit 4 -s 15 -auth <Xauth file> & The <Xauth file> is created using the "xauth" command and is customarily located in the users home directory with the name ".Xauthority". Verify the options of the running Xwindows server are correct. Procedure: Get the running xserver information # ps -ef |grep X If the response contains /usr/bin/Xorg:0 /usr/bin/Xorg:0 -br -audit 0 -auth /var/gdm/:0.Xauth -nolisten tcp vt7 this is indicative of Xorg starting through gdm. This is the default on RHEL. Examine the Xorg line: If the "-auth" option is missing this would be a finding. If the "-audit" option is missing or not set to 4, this is a finding. If the "-s" option is missing or greater than 15, this is a finding. If the response to the grep contains X:0 /usr/bin/X:0 this indicates the X server was started with the xinit command with no associated .xserverrc in the home directory of the user. No options are selected by default. This is a finding. Otherwise if there are options on the X:0 line: If the "-auth" option is missing this is a finding If the "-audit" option is missing or not set to 4, this is a finding. If the "-s" option is missing or greater than 15, this is a finding. GEN000000-LNX00380 <GroupDescription></GroupDescription> GEN000000-LNX00380 An X server must have none of the following options enabled: -ac, -core (except for debugging purposes), or -nolock. <VulnDiscussion>These options will detract from the security of the Xwindows system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Disable the unwanted options: Procedure: For gdm: Remove the -ac, -core and -nolock options by creating a "command" entry in the /etc/gdm/custom.conf file with the options removed. For Xwindows started by xinit: Create or modify the .xserverrc script in the users home directory to remove the -ac, -core and -nolock options from the exec /usr/bin/X command. If the "xorg-x11-server-Xorg" package is not installed, this is not applicable. Verify the options of the running Xwindows server are correct. Procedure: Get the running xserver information # ps -ef |grep X If the response contains /usr/bin/Xorg:0 /usr/bin/Xorg:0 -br -audit 0 -auth /var/gdm/:0.Xauth -nolisten tcp vt7 this is indicative of Xorg starting through gdm. This is the default window manager on RHEL. If the "-ac" option is found, this is a finding. If the "-core" option is found, this is a finding. If the "-nolock" option is found, this is a finding. If the response to the grep contains X:0 /usr/bin/X:0 Examine the X:0 line: If the "-ac" option is found, this is a finding. If the "-core" option is found, this is a finding. If the "-nolock" option is found, this is a finding. GEN006240 <GroupDescription></GroupDescription> GEN006240 The system must not run an Internet Network News (INN) server. <VulnDiscussion>INN servers access Usenet newsfeeds and store newsgroup articles. INN servers use the Network News Transfer Protocol (NNTP) to transfer information from the Usenet to the server and from the server to authorized remote hosts. If this function is necessary to support a valid mission requirement, its use must be authorized and approved in the system accreditation package.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><Responsibility>Information Assurance Officer</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000381 Disable the INN server. # ps -ef | egrep "innd|nntpd" If an Internet Network News server is running, this is a finding. GEN000000-LNX00400 <GroupDescription></GroupDescription> GEN000000-LNX00400 The /etc/access.conf file must be owned by root. <VulnDiscussion>The /etc/access.conf file contains entries restricting access from the system console by authorized System Administrators. If the file is owned by a user other than root, it could compromise the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 CCI-000366 Follow the correct configuration parameters for access configuration file. Use the chown command to configure it properly. (for example: # chown root /etc/security/access.conf ). Check access configuration ownership: # ls -lL /etc/security/access.conf If this file exists and is not owned by root, this is a finding. GEN006080 <GroupDescription></GroupDescription> GEN006080 The Samba Web Administration Tool (SWAT) must be restricted to the local host or require SSL. <VulnDiscussion>SWAT is a tool used to configure Samba. It modifies Samba configuration, which can impact system security, and must be protected from unauthorized access. SWAT authentication may involve the root password, which must be protected by encryption when traversing the network. Restricting access to the local host allows for the use of SSH TCP forwarding, if configured, or administration by a web browser on the local system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>EBRP-1, ECCT-1, ECCT-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001436 Disable SWAT or require SWAT is only accessed via SSH. Procedure: If SWAT is not needed for operation of the system remove the SWAT package: # rpm -qa|grep swat Remove "samba-swat" or "samba3x-swat" depending on which one is installed # rpm --erase samba-swat or # rpm --erase samba3x-swat If SWAT is required but not at all times disable it when it is not needed. Modify the /etc/xinetd.d file for "swat" to contain a "disable = yes" line. To access using SSH: Follow vendor configuration documentation to create an stunnel for SWAT. SWAT is a tool for configuring Samba and should only be found on a system with a requirement for Samba. If SWAT is used, it must be utilized with SSL to ensure a secure connection between the client and the server. Procedure: # grep -H "bin/swat" /etc/xinetd.d/*|cut -d: -f1 |xargs grep "only_from" If the value of the "only_from" line in the "xinetd.d" file which starts "/usr/sbin/swat" is not "localhost" or the equivalent, this is a finding. GEN006100 <GroupDescription></GroupDescription> GEN006100 The /etc/smb.conf file must be owned by root. <VulnDiscussion>The /etc/smb.conf file allows access to other machines on the network and grants permissions to certain users. If it is owned by another user, the file may be maliciously modified and the Samba configuration could be compromised.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the ownership of the smb.conf file. Procedure: # chown root smb.conf Check the ownership of the /etc/samba/smb.conf file. Procedure: # ls -l /etc/samba/smb.conf If an smb.conf file is not owned by root, this is a finding. GEN006140 <GroupDescription></GroupDescription> GEN006140 The /etc/smb.conf file must have mode 0644 or less permissive. <VulnDiscussion>If the "smb.conf" file has excessive permissions, the file may be maliciously modified and the Samba configuration could be compromised.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the smb.conf file to 0644 or less permissive. Procedure: # chmod 0644 smb.conf. Check the mode of the smb.conf file. Procedure: # ls -lL /etc/samba/smb.conf If the "smb.conf" has a mode more permissive than 0644, this is a finding. GEN006160 <GroupDescription></GroupDescription> GEN006160 The /etc/smbpasswd file must be owned by root. <VulnDiscussion>If the "smbpasswd" file is not owned by root, it may be maliciously accessed or modified, potentially resulting in the compromise of Samba accounts.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Use the chown command to configure the files maintained by smbpasswd. For instance: # chown root /etc/samba/passdb.tdb /etc/samba/secrets.tdb Check the ownership of the "smbpasswd" file. # ls -l /etc/samba/passdb.tdb /etc/samba/secrets.tdb If the "smbpasswd" file is not owned by root, this is a finding. GEN006220 <GroupDescription></GroupDescription> GEN006220 The smb.conf file must use the "hosts" option to restrict access to Samba. <VulnDiscussion>Samba increases the attack surface of the system and must be restricted to communicate only with systems requiring access.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Edit the "/etc/samba/smb.conf" file and set the "hosts" option to permit only authorized hosts to access Samba. Examine the "smb.conf" file. # more /etc/samba/smb.conf If the "hosts" option is not present to restrict access to a list of authorized hosts and networks, this is a finding. GEN000540 <GroupDescription></GroupDescription> GEN000540 Users must not be able to change passwords more than once every 24 hours. <VulnDiscussion>The ability to change passwords frequently facilitates users reusing the same password. This can result in users effectively never changing their passwords. This would be accomplished by users changing their passwords when required and then immediately changing it to the original value. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4180-6 CCI-000198 Change the minimum time period between password changes for each user account to 1 day. # passwd -n 1 <user name> Check the minimum time period between password changes for each user account is 1 day. # cat /etc/shadow | cut -d ':' -f 4 | grep -v 1 If any results are returned, this is a finding. GEN001100 <GroupDescription></GroupDescription> GEN001100 Root passwords must never be passed over a network in clear text form. <VulnDiscussion>If a user accesses the root account (or any account) using an unencrypted connection, the password is passed over the network in clear text form and is subject to interception and misuse. This is true even if recommended procedures are followed by logging on to a named account and using the su command to access root.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECNK-1, ECNK-2, IAIA-1, IAIA-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000197 Enable SSH on the system and use it for all remote connections used to attain root access Determine if root has logged in over an unencrypted network connection. First determine if root has logged in over a network. Procedure: # last | grep "^root " | egrep -v "reboot|console" | more Next determine if the SSH daemon is running. Procedure: # ps -ef |grep sshd If root has logged in over the network and sshd is not running, this is a finding. GEN001120 <GroupDescription></GroupDescription> GEN001120 The system must not permit root logins using remote access programs such as ssh. <VulnDiscussion>Even though communications are encrypted, an additional layer of security may be gained by extending the policy of not logging directly on as root. In addition, logging in with a user-specific account preserves the audit trail.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECPA-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4387-7 CCI-000770 Edit the sshd_config file and set the PermitRootLogin option to "no". Determine if the SSH daemon is configured to permit root logins. Procedure: # grep -v "^#" /etc/ssh/sshd_config | grep -i permitrootlogin If the PermitRootLogin entry is not found or is not set to "no", this is a finding. GEN002320 <GroupDescription></GroupDescription> GEN002320 Audio devices must have mode 0660 or less permissive. <VulnDiscussion>Audio and video devices that are globally accessible have proven to be another security hazard. There is software that can activate system microphones and video devices connected to user workstations and/or X terminals. Once the microphone has been activated, it is possible to eavesdrop on otherwise private conversations without the victim being aware of it. This action effectively changes the user's microphone into a bugging device.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of audio devices. # chmod 0660 <audio device> Check the mode of audio devices. # ls -lL /dev/audio* /dev/snd/* If the mode of audio devices are more permissive than 660, this is a finding. GEN002340 <GroupDescription></GroupDescription> GEN002340 Audio devices must be owned by root. <VulnDiscussion>Audio and video devices globally accessible have proven to be another security hazard. There is software that can activate system microphones and video devices connected to user workstations and/or X terminals. Once the microphone has been activated, it is possible to eavesdrop on otherwise private conversations without the victim being aware of it. This action effectively changes the user's microphone into a bugging device.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the owner of the audio device. # chown root <audio device> Check the owner of audio devices. # ls -lL /dev/audio* /dev/snd/* If the owner of any audio device file is not root, this is a finding. GEN000000-LNX00420 <GroupDescription></GroupDescription> GEN000000-LNX00420 The /etc/access.conf file must have a privileged group owner. <VulnDiscussion>Depending on the access restrictions of the /etc/access.conf file, if the group owner were not a privileged group, it could endanger system security.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 CCI-000366 Use the chgrp command to ensure the group owner is root, sys, or bin. (for example: # chgrp root /etc/security/access.conf ). Check access configuration group ownership: # ls -lL /etc/security/access.conf If this file exists and has a group-owner that is not a privileged user, this is a finding. GEN000000-LNX00440 <GroupDescription></GroupDescription> GEN000000-LNX00440 The /etc/security/access.conf file must have mode 0640 or less permissive. <VulnDiscussion>If the access permissions are more permissive than 0640, system security could be compromised.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 CCI-000366 Use the chmod command to set the permissions to 0640. (for example: # chmod 0640 /etc/security/access.conf ). Check access configuration mode: # ls -lL /etc/security/access.conf If this file exists and has a mode more permissive than 0640, this is a finding. GEN006120 <GroupDescription></GroupDescription> GEN006120 The /etc/smb.conf file must be group-owned by root, bin, sys, or system. <VulnDiscussion>If the group owner of the "smb.conf" file is not root or a system group, the file may be maliciously modified and the Samba configuration could be compromised.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group owner of the smb.conf file. Procedure: # chgrp root smb.conf Check the group ownership of the "smb.conf" file. Procedure: # ls -lL /etc/samba/smb.conf If the "smb.conf" file is not group-owned by root, bin, sys, or system, this is a finding. GEN006180 <GroupDescription></GroupDescription> GEN006180 The smbpasswd file must be group-owned by root. <VulnDiscussion>If the smbpasswd file is not group-owned by root, the smbpasswd file may be maliciously accessed or modified, potentially resulting in the compromise of Samba accounts.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Use the chgrp command to ensure that the group owner of the smbpasswd file is root. For instance: # chgrp root /etc/samba/passdb.tdb /etc/samba/secrets.tdb Check "smbpasswd" ownership: # ls -lL /etc/samba/passdb.tdb /etc/samba/secrets.tdb If the "smbpasswd" file is not group-owned by root, this is a finding. GEN006200 <GroupDescription></GroupDescription> GEN006200 The smbpasswd file must have mode 0600 or less permissive. <VulnDiscussion>If the smbpasswd file has a mode more permissive than 0600, the smbpasswd file may be maliciously accessed or modified, potentially resulting in the compromise of Samba accounts.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the files maintained through smbpasswd to 0600. Procedure: # chmod 0600 /etc/samba/passdb.tdb /etc/samba/secrets.tdb Check the mode of files maintained using "smbpasswd". Procedure: # ls -lL /etc/samba/passdb.tdb /etc/samba/secrets.tdb If a "smbpasswd" maintained file has a mode more permissive than 0600, this is a finding. GEN002360 <GroupDescription></GroupDescription> GEN002360 Audio devices must be group-owned by root, sys, bin, or system. <VulnDiscussion>Without privileged group owners, audio devices will be vulnerable to being used as eaves-dropping devices by malicious users or intruders to possibly listen to conversations containing sensitive information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group-owner of the audio device. Procedure: # chgrp root <audio device> Check the group-owner of audio devices. Procedure: # ls -lL /dev/audio* /dev/snd/* If the group-owner of an audio device is not root, sys, bin, or system, this is a finding. GEN001080 <GroupDescription></GroupDescription> GEN001080 The root shell must be located in the / file system. <VulnDiscussion>To ensure the root shell is available in repair and administrative modes, the root shell must be located in the / file system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Change the root account's shell to one present on the / file system. Procedure: Edit /etc/passwd and change the shell for the root account to one present on the / file system (such as /bin/sh, assuming /bin is not on a separate file system). If the system does not store shell configuration in the /etc/passwd file, consult vendor documentation for the correct procedure for the system. Determine if root's shell executable resides on a dedicated file system. Procedure: Find the location of the root user's shell # grep "^root" /etc/passwd|cut -d: -f7|cut -d/ -f2 The result is the top level directory under / where the shell resides (e.g., usr) Check if it is on a dedicated file system. # grep /<top level directory> /etc/fstab If /<top level directory> is on a dedicated file system, this is a finding. GEN000500 <GroupDescription></GroupDescription> GEN000500 Graphical desktop environments provided by the system must automatically lock after 15 minutes of inactivity and the system must require users to re-authenticate to unlock the environment. Applications requiring continuous, real-time screen display (i.e., network management products) require the following and need to be documented with the IAO. -The logon session does not have administrator rights. -The display station (i.e., keyboard, monitor, etc.) is located in a controlled access area. <VulnDiscussion>If graphical desktop sessions do not lock the session after 15 minutes of inactivity, requiring re-authentication to resume operations, the system or individual data could be compromised by an alert intruder who could exploit the oversight. This requirement applies to graphical desktop environments provided by the system to locally attached displays and input devices as well as to graphical desktop environments provided to remote systems, including thin clients.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>PESL-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-3315-9 CCI-000057 For the Gnome screen saver, set the idle_activation_enabled flag. Procedure: # gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type bool --set /apps/gnome-screensaver/idle_activation_enabled true If the "xorg-x11-server-Xorg" package is not installed, this is not applicable. For the Gnome screen saver, check the idle_activation_enabled flag. Procedure: # gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --get /apps/gnome-screensaver/idle_activation_enabled If this does not return "true" and a documented exception has not been made by the IAO, this is a finding. GEN000800 <GroupDescription></GroupDescription> GEN000800 The system must prohibit the reuse of passwords within five iterations. <VulnDiscussion>If a user, or root, used the same password continuously or was allowed to change it back shortly after being forced to change it to something else, it would provide a potential intruder with the opportunity to keep guessing at one user's password until it was guessed correctly.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAIA-1, IAIA-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14939-3 CCI-000200 Create the password history file. # touch /etc/security/opasswd # chown root:root /etc/security/opasswd # chmod 0600 /etc/security/opasswd Enable password history. If /etc/pam.d/system-auth references /etc/pam.d/system-auth-ac refer to the man page for system-auth-ac for a description of how to add options not configurable with authconfig. Edit /etc/pam.d/system-auth to include the remember option on any "password pam_unix" or "password pam_history" lines set to at least 5. # ls /etc/security/opasswd If /etc/security/opasswd does not exist, then this is a finding. # grep password /etc/pam.d/system-auth| egrep '(pam_pwhistory.so|pam_unix.so)' | grep remember If the "remember" option in /etc/pam.d/system-auth is not 5 or greater, this is a finding. Check for system-auth-ac inclusions. # grep -c system-auth-ac /etc/pam.d/* If the system-auth-ac file is included anywhere # more /etc/pam.d/system-auth-ac | grep password | egrep '(pam_pwhistory.so|pam_unix.so)' | grep remember If in /etc/pam.d/system-auth-ac is referenced by another file and the "remember" option is not set to 5 or greater this is a finding. GEN001940 <GroupDescription></GroupDescription> GEN001940 User start-up files must not execute world-writable programs. <VulnDiscussion>If start-up files execute world-writable programs, especially in unprotected directories, they could be maliciously modified to become trojans that destroy user files or otherwise compromise the system at the user, or higher, level. If the system is compromised at the user level, it is much easier to eventually compromise the system at the root and network level.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCSW-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the world-writable permission of files referenced by local initialization scripts, or remove the references to these files in the local initialization scripts. Check local initialization files for any executed world-writable programs or scripts and scripts executing from world writable directories. Procedure: For each home directory on the system make a list of files referenced within any local initialization script. Show the mode for each file and its parent directory. # FILES=".bashrc .bash_login .bash_logout .bash_profile .cshrc .kshrc .login .logout .profile .tcshrc .env .dtprofile .dispatch .emacs .exrc"; # for HOMEDIR in `cut -d: -f6 /etc/passwd|sort|uniq`;do for INIFILE in $FILES;do REFLIST=`egrep " [\"~]?/" ${HOMEDIR}/${INIFILE} 2>null|sed "s/.*\([~ \"]\/[\.0-9A-Za-z_\/\-]*\).*/\1/"`;for REFFILE in $REFLIST;do FULLREF=`echo $REFFILE|sed "s:\~:${HOMEDIR}:g"|sed "s:^\s*::g"`;dirname $FULLREF|xargs stat -c "dir:%a:%n";stat -c "file:%a:%n" $FULLREF;done;done;done|sort|uniq This command outputs a list of files and directories and their associated access modes. If any local initialization file executes a world-writable program or script or a script from a world-writable directory, this is a finding. GEN001660 <GroupDescription></GroupDescription> GEN001660 All system start-up files must be owned by root. <VulnDiscussion>System start-up files not owned by root could lead to system compromise by allowing malicious users or applications to modify them for unauthorized purposes. This could lead to system and network compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the ownership of the run control script(s) with incorrect ownership. # find /etc -name "[SK][0-9]*"|xargs stat -L -c %U:%n|egrep -v "^root:"|cut -d: -f2|xargs chown root Check run control scripts' ownership. # ls -lL /etc/rc* /etc/init.d Alternatively: # find /etc -name "[SK][0-9]*"|xargs stat -L -c %U:%n If any run control script is not owned by root or bin, this is a finding. GEN001680 <GroupDescription></GroupDescription> GEN001680 All system start-up files must be group-owned by root, sys, bin, other, or system. <VulnDiscussion>If system start-up files do not have a group owner of root or a system group, the files may be modified by malicious users or intruders.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group ownership of the run control script(s) with incorrect group ownership. Procedure: # chgrp root <run control script> # find /etc -name "[SK][0-9]*"|xargs stat -L -c %G:%n|egrep -v "^(root|sys|bin|other):"|cut -d: -f2|xargs chgrp root Check run control scripts' group ownership. Procedure: # ls -lL /etc/rc* /etc/init.d Alternatively: # find /etc -name "[SK][0-9]*"|xargs stat -L -c %G:%n|egrep -v "^(root|sys|bin|other):" If any run control script is not group-owned by root, sys, bin, or other system groups, this is a finding. GEN001700 <GroupDescription></GroupDescription> GEN001700 System start-up files must only execute programs owned by a privileged UID or an application. <VulnDiscussion>System start-up files executing programs owned by other than root (or another privileged user) or an application indicating the system may have been compromised.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCSL-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the ownership of the file executed from system startup scripts to root, bin, sys, or other. # chown root <executed file> Determine the programs executed by system start-up files. Determine the ownership of the executed programs. # cat /etc/rc*/* /etc/init.d/* | more # ls -l <executed program> Alternatively: # for FILE in `egrep -r "/" /etc/rc.* /etc/init.d|awk '/^.*[^\/][0-9A-Za-z_\/]*/{print $2}'|egrep "^/"|sort|uniq`;do if [ -e $FILE ]; then stat -L -c '%U:%n' $FILE;fi;done This provides a list of files referenced by initialization scripts and their associated UIDs. If any file is run by an initialization file and is not owned by root, sys, bin, or in rare cases, an application account, this is a finding. GEN008620 <GroupDescription></GroupDescription> GEN008620 System BIOS or system controllers supporting password protection must have administrator accounts/passwords configured, and no others. <VulnDiscussion>A system's BIOS or system controller handles the initial startup of a system and its configuration must be protected from unauthorized modification. When the BIOS or system controller supports the creation of user accounts or passwords, such protections must be used and accounts/passwords only assigned to system administrators. Failure to protect BIOS or system controller settings could result in Denial of Service or compromise of the system resulting from unauthorized configuration changes.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000213 Access the system's BIOS or system controller. Set a supervisor/administrator password if one has not been set. Disable a user-level password if one has been set. On systems with a BIOS or system controller, verify a supervisor or administrator password is set. If a password is not set, this is a finding. If the BIOS or system controller supports user-level access in addition to supervisor/administrator access, determine if this access is enabled. If so, this is a finding. GEN008640 <GroupDescription></GroupDescription> GEN008640 The system must not use removable media as the boot loader. <VulnDiscussion>Malicious users with removable boot media can gain access to a system configured to use removable media as the boot loader.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Configure the system to use a bootloader installed on fixed media. Ask the SA if the system uses removable media for the boot loader. If it does, this is a finding. GEN008660 <GroupDescription></GroupDescription> GEN008660 For systems capable of using GRUB, the system must be configured with GRUB as the default boot loader unless another boot loader has been authorized, justified, and documented using site-defined procedures. <VulnDiscussion>GRUB is a versatile boot loader used by several platforms that can provide authentication for access to the system or boot loader.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Configure the system to use the GRUB bootloader or document, justify, and authorize the alternate bootloader. Determine if the system uses the GRUB boot loader; # ls -l /boot/grub/grub.conf If no grub.conf file exists, and the bootloader on the system has not been authorized, justified, and documented, this is a finding. GEN008700 <GroupDescription></GroupDescription> GEN008700 The system boot loader must require authentication. <VulnDiscussion>If the system's boot loader does not require authentication, users with console access to the system may be able to alter the system boot configuration or boot the system into single user or maintenance mode, which could result in Denial of Service or unauthorized privileged access to the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAIA-1, IAIA-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-3818-2 CCI-000213 The GRUB console boot loader can be configured to use an MD5 encrypted password by adding password --md5 password-hash to the "/boot/grub/grub.conf" file. Use "/sbin/grub-md5-crypt" to generate MD5 passwords from the command line. Check the "/boot/grub/grub.conf" or "/boot/grub/menu.lst" files. # more /boot/grub/menu.lst Check for a password configuration line, such as: password --md5 <password-hash> This line should be just below the line beginning with "timeout". Please note <password-hash> will be replaced by the actual MD5 encrypted password. If the password line is not in either of the files, this is a finding. For any bootloader other than GRUB which has been authorized, justified and documented for use on the system refer to the vendor documentation on password support. If the bootloader does not support encrypted passwords, this is a finding. GEN008720 <GroupDescription></GroupDescription> GEN008720 The system's boot loader configuration file(s) must have mode 0600 or less permissive. <VulnDiscussion>File permissions greater than 0600 on boot loader configuration files could allow an unauthorized user to view or modify sensitive information pertaining to system boot instructions.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-3923-0 CCI-000225 Change the mode of the grub.conf file to 0600. # chmod 0600 /boot/grub/grub.conf Check /boot/grub/grub.conf permissions: # ls -lL /boot/grub/grub.conf If /boot/grub/grub.conf has a mode more permissive than 0600, then this is a finding. For any bootloader other than GRUB which has been authorized, justified and documented for use on the system refer to the vendor documentation for the location of the configuration file. If the bootloader configuration file has a mode more permissive than 0600, this is a finding. GEN008680 <GroupDescription></GroupDescription> GEN008680 If the system boots from removable media, it must be stored in a safe or similarly secured container. <VulnDiscussion>Storing the boot loader on removable media in an insecure location could allow a malicious user to modify the systems boot instructions or boot to an insecure operating system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><Responsibility>Information Assurance Officer</Responsibility><IAControls>PESS-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001208 Store the system boot media in a secure container when not in use. Ask the SA if the system boots from removable media. If so, ask if the boot media is stored in a secure container when not in use. If it is not, this is a finding. GEN000000-LNX00320 <GroupDescription></GroupDescription> GEN000000-LNX00320 The system must not have special privilege accounts, such as shutdown and halt. <VulnDiscussion>If special privilege accounts are compromised, the accounts could provide privileges to execute malicious commands on a system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAAC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 CCI-000764 Remove any special privilege accounts, such as shutdown and halt, from the /etc/passwd and /etc/shadow files using the "userdel" or "system-config-users" commands. Perform the following to check for unnecessary privileged accounts: # grep "^shutdown" /etc/passwd # grep "^halt" /etc/passwd # grep "^reboot" /etc/passwd If any unnecessary privileged accounts exist this is a finding. GEN000290 <GroupDescription></GroupDescription> GEN000290 The system must not have unnecessary accounts. <VulnDiscussion>Accounts providing no operational purpose provide additional opportunities for system compromise. Unnecessary accounts include user accounts for individuals not requiring access to the system and application accounts for applications not installed on the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAAC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000012 Remove all unnecessary accounts from the /etc/passwd file before connecting a system to the network. Other accounts that are associated with a service not in use should also be removed. Check the system for unnecessary user accounts. Procedure: # more /etc/passwd Obtain a list of authorized accounts from the IAO. If any unnecessary accounts are found on the system, this is a finding. GEN006260 <GroupDescription></GroupDescription> GEN006260 The /etc/news/incoming.conf (or equivalent) must have mode 0600 or less permissive. <VulnDiscussion>Excessive permissions on the "incoming.conf" file may allow unauthorized modification which could lead to Denial-of-Service to authorized users or provide access to unauthorized users.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the "/etc/news/incoming.conf" file to 0600. # chmod 0600 /etc/news/incoming.conf RHEL uses the InternetNewsDaemon (innd) news server. The file corresponding to "/etc/news/hosts.nntp" is "/etc/news/incoming.conf". Check the permissions for "/etc/news/incoming.conf". # ls -lL /etc/news/incoming.conf If "/etc/news/incoming.conf" has a mode more permissive than 0600, this is a finding. GEN006280 <GroupDescription></GroupDescription> GEN006280 The /etc/news/infeed.conf (or equivalent) must have mode 0600 or less permissive. <VulnDiscussion>Excessive permissions on the "" file may allow unauthorized modification which could lead to Denial of Service to authorized users or provide access to unauthorized users.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of "/etc/news/infeed.conf" to 0600. # chmod 0600 /etc/news/infeed.conf RHEL uses the InternetNewsDaemon (innd) news server. The file that corresponds to "/etc/news/hosts.nntp.nolimit" is "/etc/news/infeed.conf". Check the permissions for "/etc/news/infeed.conf". # ls -lL /etc/news/infeed.conf If "/etc/news/infeed.conf" has a mode more permissive than 0600, this is a finding. GEN006300 <GroupDescription></GroupDescription> GEN006300 The /etc/news/readers.conf (or equivalent) must have mode 0600 or less permissive. <VulnDiscussion>Excessive permissions on the readers.conf file may allow unauthorized modification which could lead to Denial of Service to authorized users or provide access to unauthorized users.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the /etc/news/readers.conf file to 0600. # chmod 0600 /etc/news/readers.conf Check the permissions for "/etc/news/readers.conf". # ls -lL /etc/news/readers.conf If /etc/news/readers.conf has a mode more permissive than 0600, this is a finding. GEN006320 <GroupDescription></GroupDescription> GEN006320 The /etc/news/passwd.nntp file (or equivalent) must have mode 0600 or less permissive. <VulnDiscussion>File permissions more permissive than 0600 for "/etc/news/passwd.nntp" may allow access to privileged information by system intruders or malicious users.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the "/etc/news/passwd.nntp" file. # chmod 0600 /etc/news/passwd.nntp Check "/etc/news/passwd.nntp" permissions: # ls -lL /etc/news/passwd.nntp If "/etc/news/passwd.nntp" has a mode more permissive than 0600, this is a finding. GEN006340 <GroupDescription></GroupDescription> GEN006340 Files in /etc/news must be owned by root or news. <VulnDiscussion>If critical system files are not owned by a privileged user, system integrity could be compromised.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the ownership of the files in "/etc/news" to root or news. Procedure: # chown root /etc/news/* Check the ownership of the files in "/etc/news". Procedure: # ls -al /etc/news If any files are not owned by root or news, this is a finding. GEN006360 <GroupDescription></GroupDescription> GEN006360 The files in /etc/news must be group-owned by root or news. <VulnDiscussion>If critical system files do not have a privileged group-owner, system integrity could be compromised.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group-owner of the files in "/etc/news" to root or news. Procedure: # chgrp root /etc/news/* Check "/etc/news" files group ownership: Procedure: # ls -al /etc/news If "/etc/news" files are not group-owned by root or news, this is a finding. GEN005500 <GroupDescription></GroupDescription> GEN005500 The SSH daemon must be configured to only use the SSHv2 protocol. <VulnDiscussion>SSHv1 is not a DoD-approved protocol and has many well-known vulnerability exploits. Exploits of the SSH daemon could provide immediate root access to the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCPP-1, ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4325-7 CCI-001436 Edit the sshd_config file and set the "Protocol" setting to "2". If using the F-Secure SSH server, set the "Ssh1Compatibility" setting to "no". Restart the SSH daemon. # /sbin/service sshd restart Locate the sshd_config file: # more /etc/ssh/sshd_config Examine the file. If the variables 'Protocol 2,1' or 'Protocol 1' are defined on a line without a leading comment, this is a finding. If the SSH server is F-Secure, the variable name for SSH 1 compatibility is 'Ssh1Compatibility', not 'protocol'. If the variable 'Ssh1Compatiblity' is set to 'yes', then this is a finding. GEN001000 <GroupDescription></GroupDescription> GEN001000 Remote consoles must be disabled or protected from unauthorized access. <VulnDiscussion>The remote console feature provides an additional means of access to the system which could allow unauthorized access if not disabled or properly secured. With virtualization technologies, remote console access is essential as there is no physical console for virtual machines. Remote console access must be protected in the same manner as any other remote privileged access method.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000070 Create if needed and set the contents of /etc/securetty to a "console" or "tty" device. # echo console > /etc/securetty or # echo tty1 > /etc/securetty Check /etc/securetty # more /etc/securetty If the file does not exist, or contains more than "console" or a single "tty" device this is a finding. GEN000240 <GroupDescription></GroupDescription> GEN000240 The system clock must be synchronized to an authoritative DoD time source. <VulnDiscussion>To assure the accuracy of the system clock, it must be synchronized with an authoritative time source within DoD. Many system functions, including time-based login and activity restrictions, automated reports, system logs, and audit records depend on an accurate system clock. If there is no confidence in the correctness of the system clock, time-based functions may not operate as intended and records may be of diminished value. Authoritative time sources include authorized time servers within the enclave that synchronize with upstream authoritative sources. Specific requirements for the upstream synchronization of network time protocol (NTP) servers are covered in the Network Other Devices STIG. For systems located on isolated or closed networks, it is not necessary to synchronize with a global authoritative time source. If a global authoritative time source is not available to systems on an isolated network, a local authoritative time source must be established on this network and used by the systems connected to this network. This is necessary to provide the ability to correlate events and allow for the correct operation of time-dependent protocols between systems on the isolated network. If the system is completely isolated (i.e., it has no connections to networks or other systems), time synchronization is not required as no correlation of events between systems will be necessary. If the system is completely isolated, this requirement is not applicable.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001492 Use an authoritative local time server or a time server operated by the U.S. government. Ensure all systems in the facility feed from one or more local time servers which feed from the authoritative U.S. government time server. Check if NTP running: # ps -ef | egrep "xntpd|ntpd" Check if "ntpd -qg" scheduled to run: # grep "ntpd -qg" /var/spool/cron/* # grep "ntpd -qg" /etc/cron.d/* # grep "ntpd -qg" /etc/cron.daily/* # grep "ntpd -qg" /etc/cron.hourly/* # grep "ntpd -qg" /etc/cron.monthly/* # grep "ntpd -qg" /etc/cron.weekly/* If NTP is running or "ntpd -qg" is found: # more /etc/ntp.conf Confirm the timeservers and peers or multicast client (as applicable) are local or authoritative U.S. DoD sources appropriate for the level of classification which the network operates. If a non-local/non-authoritative time-server is used, this is a finding. GEN003640 <GroupDescription></GroupDescription> GEN003640 The root file system must employ journaling or another mechanism ensuring file system consistency. <VulnDiscussion>File system journaling, or logging, can allow reconstruction of file system data after a system crash, preserving the integrity of data that may have otherwise been lost. Journaling file systems typically do not require consistency checks upon booting after a crash, which can improve system availability. Some file systems employ other mechanisms to ensure consistency also satisfying this requirement.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000553 Implement file system journaling for the root file system, or use a file system with other mechanisms to ensure file system consistency. If the root file system supports journaling, enable it. If the file system does not support journaling or another mechanism to ensure file system consistency, a migration to a different file system will be necessary. Logging should be enabled for those types of file systems not turning on logging by default. Procedure: # mount JFS, VXFS, HFS, XFS, reiserfs, EXT3 and EXT4 all turn logging on by default and will not be a finding. The ZFS file system uses other mechanisms to provide for file system consistency, and will not be a finding. For other file systems types, if the root file system does not support journaling this is a finding. If the 'nolog' option is set on the root file system that does support journaling, this is a finding. GEN006060 <GroupDescription></GroupDescription> GEN006060 The system must not run Samba unless needed. <VulnDiscussion>Samba is a tool used for the sharing of files and printers between Windows and UNIX operating systems. It provides access to sensitive files and, therefore, poses a security risk if compromised.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCPD-1, ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001436 If there is no functional need for Samba and the daemon is running, disable the daemon by killing the process ID as noted from the output of ps -ef |grep smbd. The samba package should also be removed or not installed if there is no functional requirement. Procedure: rpm -qa |grep samba This will show whether "samba" or "samba3x" is installed. To remove: rpm --erase samba or rpm --erase samba3x Check the system for a running Samba server. Procedure: # ps -ef |grep smbd If the Samba server is running, ask the SA if the Samba server is operationally required. If it is not, this is a finding. GEN000000-LNX00480 <GroupDescription></GroupDescription> GEN000000-LNX00480 The /etc/sysctl.conf file must be owned by root. <VulnDiscussion>The sysctl.conf file specifies the values for kernel parameters to be set on boot. These settings can affect the system's security.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Use the chown command to change the owner of /etc/sysctl.conf to root: # chown root /etc/sysctl.conf Check /etc/sysctl.conf ownership. # ls -lL /etc/sysctl.conf If /etc/sysctl.conf is not owned by root, this is a finding. GEN000000-LNX00500 <GroupDescription></GroupDescription> GEN000000-LNX00500 The /etc/sysctl.conf file must be group-owned by root. <VulnDiscussion>The sysctl.conf file specifies the values for kernel parameters to be set on boot. These settings can affect the system's security.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Use the chgrp command to change the group owner of /etc/sysctl.conf to root: # chgrp root /etc/sysctl.conf Check /etc/sysctl.conf group ownership: # ls -lL /etc/sysctl.conf If /etc/sysctl.conf is not group-owned by root, this is a finding. GEN000000-LNX00520 <GroupDescription></GroupDescription> GEN000000-LNX00520 The /etc/sysctl.conf file must have mode 0600 or less permissive. <VulnDiscussion>The sysctl.conf file specifies the values for kernel parameters to be set on boot. These settings can affect the system's security.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Use the chmod command to change the mode of the /etc/sysctl.conf file. # chmod 0600 /etc/sysctl.conf Check /etc/sysctl.conf permissions: # ls -lL /etc/sysctl.conf If /etc/sysctl.conf has a mode more permissive than 0600, this is a finding. GEN000000-LNX00560 <GroupDescription></GroupDescription> GEN000000-LNX00560 The Linux NFS Server must not have the insecure file locking option. <VulnDiscussion>Insecure file locking could allow for sensitive data to be viewed or edited by an unauthorized user.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAIA-1, IAIA-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 CCI-000764 Remove the "insecure_locks" option from all NFS exports on the system. Procedure: Edit /etc/exports and remove all instances of the insecure_locks option. Re-export the file systems to make the setting take effect. # exportfs -a Determine if an NFS server is running on the system by: # ps -ef |grep nfsd If an NFS server is running, confirm it is not configured with the insecure_locks option by: # exportfs -v The example below would be a finding: /misc/export speedy.example.com(rw,insecure_locks) GEN000000-LNX00580 <GroupDescription></GroupDescription> GEN000000-LNX00580 The x86 CTRL-ALT-DELETE key sequence must be disabled. <VulnDiscussion>Undesirable reboots can occur if the CTRL-ALT-DELETE key sequence is not disabled. Such reboots may cause a loss of data or loss of access to critical information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Ensure the CTRL-ALT-DELETE key sequence has been disabled and attempts to use the sequence are logged. In the /etc/inittab file replace: ca::ctrlaltdel:/sbin/shutdown -t3 -r now with ca:nil:ctrlaltdel:/usr/bin/logger -p security.info "Ctrl-Alt-Del was pressed" Verify that reboot using the CTRL-ALT-DELETE key sequence has been disabled by performing: # grep ctrlaltdel /etc/inittab If the line returned does not specify "/usr/bin/logger", or is not commented out, this is a finding. GEN000000-LNX00600 <GroupDescription></GroupDescription> GEN000000-LNX00600 The Linux PAM system must not grant sole access to admin privileges to the first user who logs into the console. <VulnDiscussion>If an unauthorized user has been granted privileged access while logged in at the console, the security posture of a system could be greatly compromised. Additionally, such a situation could deny legitimate root access from another terminal.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECPA-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 CCI-000366 Configure PAM to not grant sole access of administrative privileges to the first user logged in at the console. Identify any instances of pam_console. # cd /etc/pam.d # grep pam_console.so * For any files containing an un-commented reference to pam_console.so, edit the file and remove or comment out the reference. Remove the console.perms file if it exists: # rm /etc/security/console.perms Ensure the pam_console.so module is not configured in any files in /etc/pam.d by: # cd /etc/pam.d # grep pam_console.so * Or # ls -la /etc/security/console.perms If either the pam_console.so entry or the file /etc/security/console.perms is found then this is a finding. GEN002860 <GroupDescription></GroupDescription> GEN002860 Audit logs must be rotated daily. <VulnDiscussion>Rotate audit logs daily to preserve audit file system space and to conform to the DoD/DISA requirement. If it is not rotated daily and moved to another location, then there is more of a chance for the compromise of audit data by malicious users.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Configure a cron job or other automated process to rotate the audit logs on a daily basis. Check for any crontab entries that rotate audit logs. Procedure: # crontab -l If such a cron job is found, this is not a finding. Otherwise, query the SA. If there is a process automatically rotating audit logs, this is not a finding. If the SA manually rotates audit logs, this is a finding, because if the SA is not there, it will not be accomplished. If the audit output is not archived daily, to tape or disk, this is a finding. This can be ascertained by looking at the audit log directory and, if more than one file is there, or if the file does not have today's date, this is a finding. GEN003200 <GroupDescription></GroupDescription> GEN003200 The cron.deny file must have mode 0600 or less permissive. <VulnDiscussion>If file permissions for cron.deny are more permissive than 0600, sensitive information could be viewed or edited by unauthorized users. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the cron.deny file. # chmod 0600 /etc/cron.deny Check the mode of the cron.deny file. # ls -lL /etc/cron.deny If the cron.deny file does not exist this is not a finding. If the cron.deny file exists and the mode is more permissive than 0600, this is a finding. GEN003220 <GroupDescription></GroupDescription> GEN003220 Cron programs must not set the umask to a value less restrictive than 077. <VulnDiscussion>The umask controls the default access mode assigned to newly created files. A umask of 077 limits new files to mode 700 or less permissive. Although umask is often represented as a 4-digit octal number, the first digit representing special access modes is typically ignored or required to be 0.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>true</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance>If a cron program sets the umask to 000 or does not restrict the world-writable permission, this becomes a CAT I finding.</SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Edit cron script files and modify the umask to 077. Determine if there are any crontabs by viewing a long listing of the directory. If there are crontabs, examine them to determine what cron jobs exist. Check for any programs specifying an umask more permissive than 077: Procedure: # ls -lL /var/spool/cron # ls -lL /etc/cron.d /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly or # ls -lL /etc/cron.*|grep -v deny # cat <crontab file> # grep umask <cron program> If there are no cron jobs present, this vulnerability is not applicable. If any cron job contains an umask more permissive than 077, this is a finding. GEN003240 <GroupDescription></GroupDescription> GEN003240 The cron.allow file must be owned by root, bin, or sys. <VulnDiscussion>If the owner of the cron.allow file is not set to root, bin, or sys, the possibility exists for an unauthorized user to view or to edit sensitive information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 # chown root /etc/cron.allow # ls -lL /etc/cron.allow If the cron.allow file is not owned by root, sys, or bin, this is a finding. GEN003400 <GroupDescription></GroupDescription> GEN003400 The "at" directory must have mode 0755 or less permissive. <VulnDiscussion>If the "at" directory has a mode more permissive than 0755, unauthorized users could be allowed to view or to edit files containing sensitive information within the "at" directory. Unauthorized modifications could result in Denial of Service to authorized "at" jobs.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the "at" directory to 0755. Procedure: # chmod 0755 <at directory> Check the mode of the "at" directory. Procedure: # ls -ld /var/spool/at If the directory mode is more permissive than 0755, this is a finding. GEN003420 <GroupDescription></GroupDescription> GEN003420 The at directory must be owned by root, bin, sys, daemon, or cron. <VulnDiscussion>If the owner of the "at" directory is not root, bin, or sys, unauthorized users could be allowed to view or edit files containing sensitive information within the directory.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the owner of the "at" directory to root, bin, sys, or system. Procedure: # chown <root or other system account> <"at" directory> Check the ownership of the "at" directory: Procedure: # ls -ld /var/spool/at If the directory is not owned by root, sys, bin, daemon, or cron, this is a finding. GEN003440 <GroupDescription></GroupDescription> GEN003440 "At" jobs must not set the umask to a value less restrictive than 077. <VulnDiscussion>The umask controls the default access mode assigned to newly created files. A umask of 077 limits new files to mode 700 or less permissive. Although umask is often represented as a 4-digit number, the first digit representing special access modes is typically ignored or required to be 0.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>true</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><Responsibility>Information Assurance Officer</Responsibility><IAControls>ECCD-1, ECCD-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Edit "at" jobs or referenced scripts to remove "umask" commands that set umask to a value less restrictive than 077. Determine what "at" jobs exist on the system. Procedure: # ls /var/spool/at If there are no "at" jobs present, this is not applicable. Determine if any of the "at" jobs or any scripts referenced execute the "umask" command. Check for any umask setting more permissive than 077. # grep umask <at job or referenced script> If any "at" job or referenced script sets umask to a value more permissive than 077, this is a finding. GEN003460 <GroupDescription></GroupDescription> GEN003460 The at.allow file must be owned by root, bin, or sys. <VulnDiscussion>If the owner of the at.allow file is not set to root, bin, or sys, unauthorized users could be allowed to view or edit sensitive information contained within the file.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the owner of the at.allow file. # chown root /etc/at.allow # ls -lL /etc/at.allow If the at.allow file is not owned by root, sys, or bin, this is a finding. GEN003480 <GroupDescription></GroupDescription> GEN003480 The at.deny file must be owned by root, bin, or sys. <VulnDiscussion>If the owner of the at.deny file is not set to root, bin, or sys, unauthorized users could be allowed to view or edit sensitive information contained within the file.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the owner of the at.deny file. # chown root /etc/at.deny # ls -lL /etc/at.deny If the at.deny file is not owned by root, sys, or bin, this is a finding. GEN003960 <GroupDescription></GroupDescription> GEN003960 The traceroute command owner must be root. <VulnDiscussion>If the traceroute command owner has not been set to root, an unauthorized user could use this command to obtain knowledge of the network topology inside the firewall. This information may allow an attacker to determine trusted routers and other network information potentially leading to system and network compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the owner of the traceroute command to root. Example: # chown root /bin/traceroute # ls -lL /bin/traceroute If the traceroute command is not owned by root, this is a finding. GEN003980 <GroupDescription></GroupDescription> GEN003980 The traceroute command must be group-owned by sys, bin, root, or system. <VulnDiscussion>If the group owner of the traceroute command has not been set to a system group, unauthorized users could have access to the command and use it to gain information regarding a network's topology inside of the firewall. This information may allow an attacker to determine trusted routers and other network information potentially leading to system and network compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group-owner of the traceroute command to root. Procedure: # chgrp root /bin/traceroute Check the group ownership of the traceroute file. Procedure: # ls -lL /bin/traceroute If the traceroute command is not group-owned by root, sys, bin, or system, this is a finding. GEN004000 <GroupDescription></GroupDescription> GEN004000 The traceroute file must have mode 0700 or less permissive. <VulnDiscussion>If the mode of the traceroute executable is more permissive than 0700, malicious code could be inserted by an attacker and triggered whenever the traceroute command is executed by authorized users. Additionally, if an unauthorized user is granted executable permissions to the traceroute command, it could be used to gain information about the network topology behind the firewall. This information may allow an attacker to determine trusted routers and other network information potentially leading to system and network compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the traceroute command. # chmod 0700 /bin/traceroute # ls -lL /bin/traceroute If the traceroute command has a mode more permissive than 0700, this is a finding. GEN004220 <GroupDescription></GroupDescription> GEN004220 Administrative accounts must not run a web browser, except as needed for local service administration. <VulnDiscussion>If a web browser flaw is exploited while running as a privileged user, the entire system could be compromised. Specific exceptions for local service administration should be documented in site-defined policy. These exceptions may include HTTP(S)-based tools used for the administration of the local system, services, or attached devices. Examples of possible exceptions are HP’s System Management Homepage (SMH), the CUPS administrative interface, and Sun's StorageTek Common Array Manager (CAM) when these services are running on the local system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Enforce policy requiring administrative accounts use web browsers only for local service administration. Look in the root account home directory for a .mozilla directory. If none exists, this is not a finding. If there is one, verify with the root users and the IAO the intent of the browsing. If the browsing is not limited to authorized local services administration, this is a finding. GEN004560 <GroupDescription></GroupDescription> GEN004560 The SMTP service's SMTP greeting must not provide version information. <VulnDiscussion>The version of the SMTP service can be used by attackers to plan an attack based on vulnerabilities present in the specific version.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Ensure sendmail or Postfix has been configured to mask the version information. Procedure for sendmail: Change the O SmtpGreetingMessage line in the /etc/mail/sendmail.cf file as noted below: O SmtpGreetingMessage=$j Sendmail $v/$Z; $b change it to: O SmtpGreetingMessage= Mail Server Ready ; $b for Postfix: Examine the "smtpd_banner" line of /etc/postfix/main.conf and remove any "$mail_version" entry on it or comment the entire "smtpd_banner" line to use the default value which does not display the version information. To check for the version of either sendmail or Postfix being displayed in the greeting: # telnet localhost 25 If a version number is displayed, this is a finding. GEN004580 <GroupDescription></GroupDescription> GEN004580 The system must not use .forward files. <VulnDiscussion>The .forward file allows users to automatically forward mail to another system. Use of .forward files could allow the unauthorized forwarding of mail and could potentially create mail loops which could degrade system performance.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Disable forwarding for sendmail and remove .forward files from the system Procedure: Edit the /etc/mail/sendmail.mc file to change the ForwardPath entry to a null path by adding the line define(`confFORWARD_PATH',`') rebuild the sendmail.cf file. Remove all .forward files on the system # find / -name .forward -delete Check forwarding capability from sendmail. Procedure: grep "O ForwardPath" /etc/mail/sendmail.cf If the entry contains a file path, this is a finding. Search for any .forward in users home directories on the system by: # for pwline in `cut -d: -f1,6 /etc/passwd`; do homedir=`echo ${pwline}|cut -d: -f2`;username=`echo ${pwline} | cut -d: -f1`;echo $username `stat -c %n $homedir/.forward 2>null`; done|egrep "\.forward" If any users have a .forward file in their home directory, this is a finding. GEN005000 <GroupDescription></GroupDescription> GEN005000 Anonymous FTP accounts must not have a functional shell. <VulnDiscussion>If an anonymous FTP account has been configured to use a functional shell, attackers could gain access to the shell if the account is compromised.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Configure anonymous FTP accounts to use a non-functional shell. If necessary, edit the /etc/passwd file to remove any functioning shells associated with the ftp account and replace them with non-functioning shells, such as /dev/null. Check the shell for the anonymous FTP account. Procedure: # grep "^ftp" /etc/passwd This is a finding if the seventh field is empty (the entry ends with a ':') or if the seventh field does not contain one of the following: /bin/false /dev/null /usr/bin/false /bin/true /sbin/nologin GEN005380 <GroupDescription></GroupDescription> GEN005380 If the system is a Network Management System (NMS) server, it must only run the NMS and any software required by the NMS. <VulnDiscussion>Installing extraneous software on a system designated as a dedicated Network Management System (NMS) server poses a security threat to the system and the network. Should an attacker gain access to the NMS through unauthorized software, the entire network may be susceptible to malicious activity.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCPA-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001208 Ensure only authorized software is loaded on a designated NMS server. Authorized software is limited to the NMS software itself, a database management system for the NMS server if necessary, and network management software. Ask the SA if this is an NMS server. If it is an NMS server, then ask what other applications run on it. If there is anything other than network management software and DBMS software used only for the storage and inquiry of NMS data, this is a finding. GEN005400 <GroupDescription></GroupDescription> GEN005400 The /etc/syslog.conf file must be owned by root. <VulnDiscussion>If the /etc/syslog.conf file is not owned by root, unauthorized users could be allowed to view, edit, or delete important system messages handled by the syslog facility.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Use the chown command to set the owner to root. # chown root /etc/syslog.conf Check /etc/syslog.conf ownership: # ls -lL /etc/syslog.conf If /etc/syslog.conf is not owned by root, this is a finding. GEN005420 <GroupDescription></GroupDescription> GEN005420 The /etc/syslog.conf file must be group-owned by root, bin, sys, or system. <VulnDiscussion>If the group owner of /etc/syslog.conf is not root, bin, or sys, unauthorized users could be permitted to view, edit, or delete important system messages handled by the syslog facility.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Procedure: # chgrp root /etc/syslog.conf Check /etc/syslog.conf group ownership. Procedure: # ls -lL /etc/syslog.conf If /etc/syslog.conf is not group owned by root, sys, bin, or system, this is a finding. GEN005460 <GroupDescription></GroupDescription> GEN005460 The system must only use remote syslog servers (log hosts) that is justified and documented using site-defined procedures. <VulnDiscussion>If a remote log host is in use and it has not been justified and documented with the IAO, sensitive information could be obtained by unauthorized users without the SA's knowledge. A remote log host is any host to which the system is sending syslog messages over a network.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>true</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Remove or document the referenced undocumented log host. Examine the syslog.conf file for any references to remote log hosts. # grep -v "^#" /etc/syslog.conf | grep '@' Destination locations beginning with an '@' represent log hosts. If the log host name is a local alias such as "loghost", consult the /etc/hosts or other name databases as necessary to obtain the canonical name or address for the log host. Determine if the host referenced is a log host documented using site-defined procedures. If an undocumented log host is referenced, this is a finding. GEN005560 <GroupDescription></GroupDescription> GEN005560 The system must be configured with a default gateway for IPv4 if the system uses IPv4, unless the system is a router. <VulnDiscussion>If a system has no default gateway defined, the system is at increased risk of man-in-the-middle, monitoring, and Denial of Service attacks.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Set a default gateway for IPv4. Check the system for an IPv4 default route. If the system is a VM host and acts as a router solely for the benefit of its client systems, then this rule is not applicable. Procedure: # netstat -r |grep default If a default route is not defined, this is a finding. GEN005580 <GroupDescription></GroupDescription> GEN005580 A system used for routing must not run other network services or applications. <VulnDiscussion>Installing extraneous software on a system designated as a dedicated router poses a security threat to the system and the network. Should an attacker gain access to the router through the unauthorized software, the entire network is susceptible to malicious activity.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCSP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001208 Ensure only authorized software is loaded on a designated router. Authorized software will be limited to the most current version of routing protocols and SSH for system administration purposes. If the system is a VM host and acts as a router solely for the benefit of its client systems, then this rule is not applicable. Ask the SA if the system is a designated router. If it is not, this is not applicable. Check the system for non-routing network services. Procedure: # netstat -a | grep -i listen # ps -ef If non-routing services, including Web servers, file servers, DNS servers, or applications servers, but excluding management services such as SSH and SNMP, are running on the system, this is a finding. GEN006380 <GroupDescription></GroupDescription> GEN006380 The system must not use UDP for NIS/NIS+. <VulnDiscussion>Implementing Network Information Service (NIS) or NIS+ under UDP may make the system more susceptible to a Denial of Service attack and does not provide the same quality of service as TCP.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001436 Configure the system to not use UDP for NIS and NIS+. Consult vendor documentation for the required procedure. If the system does not use NIS or NIS+, this is not applicable. Check if NIS or NIS+ is implemented using UDP. Procedure: # rpcinfo -p | grep yp | grep udp If NIS or NIS+ is implemented using UDP, this is a finding. GEN002020 <GroupDescription></GroupDescription> GEN002020 All .rhosts, .shosts, or host.equiv files must only contain trusted host-user pairs. <VulnDiscussion>If these files are not properly configured, they could allow malicious access by unknown malicious users from untrusted hosts who could compromise the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 If possible, remove the .rhosts, .shosts, hosts.equiv, and shosts.equiv files. If the files are required, remove any content from the files except for necessary host-user pairs. Locate and examine all r-commands access control files. Procedure: # find / -name .rhosts # more /<directorylocation>/.rhosts # find / -name .shosts # more /<directorylocation>/.shosts # find / -name hosts.equiv # more /<directorylocation>/hosts.equiv # find / -name shosts.equiv # more /<directorylocation>/shosts.equiv If any .rhosts, .shosts, hosts.equiv, or shosts.equiv file contains other than host-user pairs, this is a finding. GEN002060 <GroupDescription></GroupDescription> GEN002060 All .rhosts, .shosts, .netrc, or hosts.equiv files must be accessible by only root or the owner. <VulnDiscussion>If these files are accessible by users other than root or the owner, they could be used by a malicious user to set up a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Ensure the permission for these files is set to 600 or more restrictive and their owner is root or the same as the owner of the home directory in which they reside. Procedure: # chmod 600 /etc/hosts.equiv # chmod 600 /etc/ssh/shosts.equiv # chown root /etc/hosts.equiv # chown root /etc/ssh/shosts.equiv # find / -name .rhosts # chmod 600 /<home directory>/.rhosts # chown <home directory owner> <home directory>/.rhosts # find / -name .shosts # chmod 600 <directory location>/.shosts # chown <home directory owner> <home directory>/.shosts # find / -name .netrc # chmod 600 <directory location>/.netrc # chown <home directory owner> <home directory>/.netrc Procedure: # ls -l /etc/hosts.equiv # ls -l /etc/ssh/shosts.equiv # find / -name .rhosts # ls -al <home directory>/.rhosts # find / -name .shosts # ls -al <home directory>/.shosts # find / -name .netrc # ls -al <home directory>/.netrc If the .rhosts, .shosts, hosts.equiv, or shosts.equiv files have permissions greater than 600, then this is a finding. If the /etc/hosts.equiv, or /etc/ssh/shosts.equiv files are not owned by root, this is a finding. Any .rhosts, .shosts and .netrc files outside of home directories have no meaning and are not subject to this rule If the ~/.rhosts or ~/.shosts are not owned by the owner of the home directory where they are immediately located or by root, this is a finding. GEN003260 <GroupDescription></GroupDescription> GEN003260 The cron.deny file must be owned by root, bin, or sys. <VulnDiscussion>Cron daemon control files restrict the scheduling of automated tasks and must be protected. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 # chown root /etc/cron.deny # ls -lL /etc/cron.deny If the cron.deny file is not owned by root, sys, or bin, this is a finding. GEN003820 <GroupDescription></GroupDescription> GEN003820 The rsh daemon must not be running. <VulnDiscussion>The rshd process provides a typically unencrypted, host-authenticated remote access service. SSH should be used in place of this service.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>System Administrator</Responsibility><IAControls>EBRU-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4141-8 CCI-000068 Edit /etc/xinetd.d/rsh and set "disable=yes". Check to see if rshd is configured to run on startup. Procedure: # grep disable /etc/xinetd.d/rsh If /etc/xinetd.d/rsh exists and rsh is found to be enabled, this is a finding. GEN003840 <GroupDescription></GroupDescription> GEN003840 The rexec daemon must not be running. <VulnDiscussion>The rexecd process provides a typically unencrypted, host-authenticated remote access service. SSH should be used in place of this service.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>true</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><Responsibility>Information Assurance Officer</Responsibility><IAControls>EBRP-1, ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001435 Edit /etc/xinetd.d/rexec and set "disable=yes" # grep disable /etc/xinetd.d/rexec If the service file exists and is not disabled, this is a finding. GEN004600 <GroupDescription></GroupDescription> GEN004600 The SMTP service must be an up-to-date version. <VulnDiscussion>The SMTP service version on the system must be current to avoid exposing vulnerabilities present in unpatched versions.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>VIVM-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001230 Obtain and install a newer version of the SMTP service software (sendmail or Postfix) from RedHat. Determine the version of the SMTP service software. Procedure: #rpm -q sendmail RedHat sendmail 8.13.8-8 is the latest required version. If the RedHat sendmail is installed and the version is not at least 8.13.8-8, this is a finding. #rpm -q postfix RedHat postfix-2.3.3-6-el5 is the latest required version. If the postfix is installed and the version is not at least postfix-2.3.3-6-el5, this is a finding. GEN004620 <GroupDescription></GroupDescription> GEN004620 The sendmail server must have the debug feature disabled. <VulnDiscussion>Debug mode is a feature present in older versions of sendmail which, if not disabled, may allow an attacker to gain access to a system through the sendmail service.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Obtain and install a newer version of the SMTP service software (sendmail or Postfix) from RedHat. Check for an enabled "debug" command provided by the SMTP service. Procedure: # telnet localhost 25 debug If the command does not return a 500 error code of "command unrecognized" or a 550 error code of "access denied", this is a finding. The RHEL distribution ships with sendmail Version 8.13.8 which is not vulnerable. This should never be a finding. GEN004640 <GroupDescription></GroupDescription> GEN004640 The SMTP service must not have a uudecode alias active. <VulnDiscussion>A common configuration for older Mail Transfer Agents (MTAs) is to include an alias for the decode user. All mail sent to this user is sent to the uudecode program, which automatically converts and stores files. By sending mail to the decode or the uudecode aliases present on some systems, a remote attacker may be able to create or overwrite files on the remote host. This could possibly be used to gain remote access.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001230 Disable mail aliases for decode and uudecode. If the /etc/aliases or /usr/lib/aliases (mail alias) file contains entries for these programs, remove them or disable them by placing "#" at the beginning of the line, and then executing the new aliases command. For more information on mail aliases, refer to the man page for aliases. Disabled aliases would be similar to these examples: # decode: |/usr/bin/uudecode # uudecode: |/usr/bin/uuencode -d Check the SMTP service for an active "decode" command. Procedure: # telnet localhost 25 decode If the command does not return a 500 error code of "command unrecognized", this is a finding. GEN004660 <GroupDescription></GroupDescription> GEN004660 The SMTP service must not have the EXPN feature active. <VulnDiscussion>The SMTP EXPN function allows an attacker to determine if an account exists on a system, providing significant assistance to a brute force attack on user accounts. EXPN may also provide additional information concerning users on the system, such as the full names of account owners.</VulnDiscussion><FalsePositives>False positives may occur with the SMTP EXPN check. According to RFC821, it is acceptable for a server to respond with a 250 (success) or 550 (failure) when the server supports the EXPN command. For example, some servers return "550 EXPN command not available," meaning the command is not supported and the machine is not vulnerable. However, a result of "550 that is a mailing list, not a user" would be a failure code, but not an indication of an error, and the machine would be vulnerable. If a false positive is suspected, check the log file for the response from the server.</FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Rebuild /etc/mail/sendmail.cf with the "noexpn" Privacy Flag set. Procedure: Edit /etc/mail/sendmail.mc resetting the Privacy Flags to the default: define('confPRIVACYFLAGS', 'authwarnings,novrfy,noexpn,restrictqrun')dnl Rebuild the sendmail.cf file with: # make -C /etc/mail Restart the sendmail service. # service sendmail restart This vulnerability is applicable only to sendmail. If Postfix is the SMTP service for the system this will never be a finding. Procedure: Determine if EXPN is disabled. # grep -v "^#" /etc/mail/sendmail.cf |grep -i PrivacyOptions If nothing is returned or the returned line does not contain "noexpn", this is a finding. GEN004680 <GroupDescription></GroupDescription> GEN004680 The SMTP service must not have the Verify (VRFY) feature active. <VulnDiscussion>The VRFY command allows an attacker to determine if an account exists on a system, providing significant assistance to a brute force attack on user accounts. VRFY may provide additional information about users on the system, such as the full names of account owners.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Add the "novrfy" flag to your sendmail in /etc/mail/sendmail.cf. Procedure: Edit the definition of "confPRIVACY_FLAGS" in /etc/mail/sendmail.mc to include "novrfy". Rebuild the sendmail.cf file with: # make -C /etc/mail Restart the sendmail service. # service sendmail restart Determine if VRFY is disabled. Procedure: # telnet localhost 25 vrfy root If the command does not return a 500 error code of "command unrecognized", this is a finding. or: # grep -v "^#" /etc/mail/sendmail.cf |grep -i vrfy Verify the VRFY command is disabled with an entry in the sendmail.cf file. The entry could be any one of "Opnovrfy", "novrfy", or "goaway", which could also have other options included, such as "noexpn". The "goaway" argument encompasses many things, such as "novrfy" and "noexpn". If no setting to disable VRFY is found, this is a finding. GEN004700 <GroupDescription></GroupDescription> GEN004700 The sendmail service must not have the wizard backdoor active. <VulnDiscussion>Very old installations of the Sendmail mailing system contained a feature whereby a remote user connecting to the SMTP port can enter the WIZ command and be given an interactive shell with root privileges.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 If the WIZ command exists on sendmail then the version of sendmail is archaic and should be replaced with the latest version from RedHat. WIZ is not available on any sendmail distribution of RHEL. However, if the WIZ command is enabled on sendmail, it should be disabled by adding this line to the sendmail.cf configuration file (note that it must be typed in uppercase): OW* For the change to take effect, kill the sendmail process, refreeze the sendmail.cf file, and restart the sendmail process. Log into the sendmail server with telnet and test the "wiz" command. Procedure: # telnet localhost 25 Trying 127.0.0.1... Connected to locahost.localdomain (127.0.0.1). Escape character ... Once the telnet greeting is complete type: wiz If you do not get a "Command unrecognized: " message, this is a finding. GEN005140 <GroupDescription></GroupDescription> GEN005140 Any active TFTP daemon must be authorized and approved in the system accreditation package. <VulnDiscussion>TFTP is a file transfer protocol often used by embedded systems to obtain configuration data or software. The service is unencrypted and does not require authentication of requests. Data available using this service may be subject to unauthorized access or interception.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>System Administrator</Responsibility><IAControls>DCSW-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4273-9 CCI-000225 Document or Disable the TFTP daemon. If the TFTP daemon is necessary on the system, document and justify its usage for approval from the IAO. If the TFTP daemon is not necessary on the system, turn it off. # chkconfig tftp off # service xinetd restart Determine if the TFTP daemon is active. # chkconfig --list | grep tftp If TFTP is found enabled ("on") and not documented using site-defined procedures, it is a finding. GEN005280 <GroupDescription></GroupDescription> GEN005280 The system must not have the UUCP service active. <VulnDiscussion>The UUCP utility is designed to assist in transferring files, executing remote commands, and sending e-mail between UNIX systems over phone lines and direct connections between systems. The UUCP utility is a primitive and arcane system with many security issues. There are alternate data transfer utilities/products that can be configured to more securely transfer data by providing for authentication as well as encryption.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001436 # chkconfig uucp off # service uucp stop # service xinetd restart # service uucp status if UUCP is "running", this is a finding. GEN005200 <GroupDescription></GroupDescription> GEN005200 X displays must not be exported to the world. <VulnDiscussion>Open X displays allow an attacker to capture keystrokes and to execute commands remotely. Many users have their X Server set to “xhost +â€, permitting access to the X Server by anyone, from anywhere.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 If using an xhost-type authentication the "xhost -" command can be used to remove current trusted hosts and then selectively allow only trusted hosts to connect with "xhost +" commands. A cryptographically secure authentication, such as provided by the xauth program, is always preferred. Refer to your X11 server's documentation for further security information. If Xwindows is not used on the system, this is not applicable. Check the output of the "xhost" command from an X terminal. Procedure: # xhost If the output reports access control is enabled (and possibly lists the hosts able to receive X window logins), this is not a finding. If the xhost command returns a line indicating access control is disabled, this is a finding. Note: It may be necessary to define the display if the command reports it cannot open the display. Procedure: $ DISPLAY=MachineName:0.0; export DISPLAY MachineName may be replaced with an Internet Protocol Address. Repeat the check procedure after setting the display. GEN003860 <GroupDescription></GroupDescription> GEN003860 The system must not have the finger service active. <VulnDiscussion>The finger service provides information about the system's users to network clients. This information could expose more information for potential used in subsequent attacks.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCPP-1, EBRU-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001551 Edit /etc/xinetd.d/finger and set "disable=yes" # grep disable /etc/xinetd.d/finger If the finger service is not disabled, this is a finding. GEN004840 <GroupDescription></GroupDescription> GEN004840 If the system is an anonymous FTP server, it must be isolated to the DMZ network. <VulnDiscussion>Anonymous FTP is a public data service which is only permitted in a server capacity when located on the DMZ network.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>System Administrator</Responsibility><IAControls>EBBD-1, EBBD-2, EBBD-3, ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000787 Remove anonymous ftp capability or move the system to a DMZ network. Use the command "ftp" to connect the system's FTP service. Attempt to log into this host with a user name of anonymous and a password of guest (also try the password of guest@mail.com). If the logon is not successful, this check is Not Applicable. Ask the SA if the system is located on a DMZ network. If the system is not located on a DMZ network, this is a finding. GEN000100 <GroupDescription></GroupDescription> GEN000100 The operating system must be a supported release. <VulnDiscussion>An operating system release is considered "supported" if the vendor continues to provide security patches for the product. With an unsupported release, it will not be possible to resolve security issues discovered in the system software.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance>If an extended support agreement provides security patches for the unsupported product is procured from the vendor, this finding may be downgraded to a CAT III.</SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>VIVM-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001230 Upgrade to a supported version of the operating system. Check the version of the operating system. Example: # cat /etc/redhat-release Vendor End-of-Support Information: Red Hat Enterprise 5: 31 Mar 2017 Check with the vendor for additional information. If the version installed is not supported, this is a finding. GEN000220 <GroupDescription></GroupDescription> GEN000220 A file integrity tool must be used at least weekly to check for unauthorized file changes, particularly the addition of unauthorized system libraries or binaries, or for unauthorized modification to authorized system libraries or binaries. <VulnDiscussion>Changes in system libraries, binaries and other critical system files can indicate compromise or significant system events such as patching needing to be checked by automated processes and the results reviewed by the SA. NOTE: For MAC I systems, increase the frequency to daily.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCSL-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001069 Establish an automated job, scheduled to run weekly or more frequently, to run "aide --check" which is the file integrity tool to check for unauthorized system libraries or binaries. NOTE: For MAC I systems, increase the frequency to daily. Determine if there is an automated job, scheduled to run weekly or more frequently, to run the file integrity tool to check for unauthorized additions to system libraries. The check can be done using Advanced Intrusion Detection Environment (AIDE) which is part of the Red Hat Enterprise Linux (RHEL) distribution. Other file integrity software may be used but must be checked manually. Procedure: Check the root crontab (crontab -l) and the global crontabs in /etc/crontab, /etc/cron.d/* for the presence of an "aide" job to run at least weekly, which should have asterisks (*) in columns 3, 4, and 5. Check the weekly cron directory (/etc/cron.weekly) for any script running "aide --check" or "aide -C" or simply "aide". If there is not, this is a finding. NOTE: For MAC I systems, increase the frequency to daily. GEN000340 <GroupDescription></GroupDescription> GEN000340 UIDs reserved for system accounts must not be assigned to non-system accounts. <VulnDiscussion>Reserved UIDs are typically used by system software packages. If non-system accounts have UIDs in this range, they may conflict with system software, possibly leading to the user having permissions to modify system files.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Change the UID numbers for non-system accounts with reserved UIDs (those less or equal to 499). Check the UID assignments for all accounts. # cut -d: -f 1,3 /etc/passwd | egrep ":[1-4][0-9]{2}$|:[0-9]{1,2}$" Confirm all accounts with a UID of 499 and below are used by a system account. If a UID reserved for system accounts (0 - 499) is used by a non-system account, then this is a finding. GEN000580 <GroupDescription></GroupDescription> GEN000580 The system must require passwords contain a minimum of 14 characters. <VulnDiscussion>The use of longer passwords reduces the ability of attackers to successfully obtain valid passwords using guessing or exhaustive search techniques by increasing the password search space.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAIA-1, IAIA-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4154-1 CCI-000205 Edit "/etc/pam.d/system-auth" to include the line: password required pam_cracklib.so minlen=14 prior to the "password include system-auth-ac" line. Check the system password length setting. Procedure: Check the password minlen option # grep pam_cracklib.so /etc/pam.d/system-auth Confirm the minlen option is set to at least 14 as in the example below: password required pam_cracklib.so minlen=14 There may be other options on the line. If no such line is found, or the minlen is less than 14 this is a finding. GEN000600 <GroupDescription></GroupDescription> GEN000600 The system must require passwords contain at least one uppercase alphabetic character. <VulnDiscussion>To enforce the use of complex passwords, minimum numbers of characters of different classes are mandated. The use of complex passwords reduces the ability of attackers to successfully obtain valid passwords using guessing or exhaustive search techniques. Complexity requirements increase the password search space by requiring users to construct passwords from a larger character set than they may otherwise use.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAIA-1, IAIA-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14672-0 CCI-000192 Edit "/etc/pam.d/system-auth" to include the line: password required pam_cracklib.so ucredit=-1 prior to the "password include system-auth-ac" line. Check the ucredit setting. # grep ucredit /etc/pam.d/system-auth If ucredit is not set to -1, this is a finding. GEN000620 <GroupDescription></GroupDescription> GEN000620 The system must require passwords contain at least one numeric character. <VulnDiscussion>To enforce the use of complex passwords, minimum numbers of characters of different classes are mandated. The use of complex passwords reduces the ability of attackers to successfully obtain valid passwords using guessing or exhaustive search techniques. Complexity requirements increase the password search space by requiring users to construct passwords from a larger character set than they may otherwise use.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAIA-1, IAIA-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14113-5 CCI-000194 Edit "/etc/pam.d/system-auth" to include the line: password required pam_cracklib.so dcredit=-1 prior to the "password include system-auth-ac" line. Check the dcredit setting. Procedure: Check the password dcredit option # grep pam_cracklib.so /etc/pam.d/system-auth Confirm the dcredit option is set to -1 as in the example: password required pam_cracklib.so dcredit=-1 There may be other options on the line. If no such line is found, or the dcredit option is not -1 this is a finding. GEN000640 <GroupDescription></GroupDescription> GEN000640 The system must require passwords contain at least one special character. <VulnDiscussion>To enforce the use of complex passwords, minimum numbers of characters of different classes are mandated. The use of complex passwords reduces the ability of attackers to successfully obtain valid passwords using guessing or exhaustive search techniques. Complexity requirements increase the password search space by requiring users to construct passwords from a larger character set than they may otherwise use.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAIA-1, IAIA-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14122-6 CCI-001619 Edit "/etc/pam.d/system-auth" to include the line: password required pam_cracklib.so ocredit=-1 prior to the "password include system-auth-ac" line. Check the ocredit setting. Procedure: Check the password ocredit option # grep pam_cracklib.so /etc/pam.d/system-auth Confirm the ocredit option is set to -1 as in the example: password required pam_cracklib.so ocredit=-1 There may be other options on the line. If no such line is found, or the ocredit is not -1 this is a finding. GEN000680 <GroupDescription></GroupDescription> GEN000680 The system must require passwords contain no more than three consecutive repeating characters. <VulnDiscussion>To enforce the use of complex passwords, the number of consecutive repeating characters is limited. Passwords with excessive repeated characters may be more vulnerable to password-guessing attacks.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAIA-1, IAIA-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit "/etc/pam.d/system-auth" to include the line: password required pam_cracklib.so maxrepeat=3 prior to the "password include system-auth-ac" line. Check the maxrepeat setting. Procedure: Check the password maxrepeat configuration # grep pam_cracklib.so /etc/pam.d/system-auth If the maxrepeat option is missing, this is a finding. If the maxrepeat option is set to more than 3, this is a finding. GEN000700 <GroupDescription></GroupDescription> GEN000700 User passwords must be changed at least every 60 days. <VulnDiscussion>Limiting the lifespan of authenticators limits the period of time an unauthorized user has access to the system while using compromised credentials and reduces the period of time available for password-guessing attacks to run against a single password.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAIA-1, IAIA-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4092-3 CCI-000180 Set the max days field to 60 for all user accounts. # passwd -x 60 <user> Check the max days field (the 5th field) of /etc/shadow. # more /etc/shadow If the max days field is equal to 0 or greater than 60 for any user, this is a finding. GEN000740 <GroupDescription></GroupDescription> GEN000740 All non-interactive/automated processing account passwords must be changed at least once per year or be locked. <VulnDiscussion>Limiting the lifespan of authenticators limits the period of time an unauthorized user has access to the system while using compromised credentials and reduces the period of time available for password-guessing attacks to run against a single password. Locking the password for non-interactive and automated processing accounts is preferred as it removes the possibility of accessing the account by a password. On some systems, locking the passwords of these accounts may prevent the account from functioning properly. Passwords for non-interactive/automated processing accounts must not be used for direct logon to the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAIA-1, IAIA-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000199 Implement or establish procedures to change the passwords of automated processing accounts at least once per year or lock them. Ask the SA if there are any automated processing accounts on the system. If there are automated processing accounts on the system, ask the SA if the passwords for those automated accounts are changed at least once a year or are locked. If SA indicates passwords for automated processing accounts are not changed once per year or are not locked, this is a finding. GEN001020 <GroupDescription></GroupDescription> GEN001020 The root account must not be used for direct log in. <VulnDiscussion>Direct login with the root account prevents individual user accountability. Acceptable non-routine uses of the root account for direct login are limited to emergency maintenance, the use of single-user mode for maintenance, and situations where individual administrator accounts are not available.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECPA-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000770 Enforce policy requiring all root account access is attained by first logging into a user account and then becoming root preferably through the use of "sudo" which provides traceability to the command level. If that is not workable then using "su" to access the root account will provide traceability to the login user. Check if root is used for direct logins. Procedure: # last root | grep -v reboot Direct logins are indicated by the presence of a terminal or pseudo-terminal ID and/or X display name in the output of the last command. If any direct login records for root are listed, this is a finding. GEN001060 <GroupDescription></GroupDescription> GEN001060 The system must log successful and unsuccessful access to the root account. <VulnDiscussion>If successful and unsuccessful logins and logouts are not monitored or recorded, access attempts cannot be tracked. Without this logging, it may be impossible to track unauthorized access to the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000126 Troubleshoot the system logging configuration to provide for logging of root account login attempts. Procedure: Edit /etc/syslog.conf to make sure "authpriv.*" messages are directed to a file or remote system. Examine /etc/audit/audit.rules to ensure user authentication messages have not been specifically excluded. There remove any entries that correspond to: -a exclude,never -Fmsgtype=USER_START -a exclude,never -Fmsgtype=USER_LOGIN -a exclude,never -Fmsgtype=USER_AUTH -a exclude,never -Fmsgtype=USER_END -a exclude,never -Fmsgtype=USER_ACCT Check the log files to determine if access to the root account is being logged. Procedure: Examine /etc/syslog.conf to confirm the location to which "authpriv" messages will be directed. The default syslog.conf uses /var/log/messages and /var/log/secure but this needs to be confirmed. # grep @ /etc/syslog.conf If a line starting with "*.*" is returned then all syslog messages will be sent to system whose address appears after the "@". In this case syslog may or may not be configured to also log "authpriv" messages locally. # grep authpriv /etc/syslog.conf If any lines are returned which do not start with "#" the "authpriv" messages will be sent to the indicated files or remote systems. Try to "su -" and enter an incorrect password. If there are no records indicating the authentication failure, this is a finding. GEN001720 <GroupDescription></GroupDescription> GEN001720 All global initialization files must have mode 0644 or less permissive. <VulnDiscussion>Global initialization files are used to configure the user's shell environment upon login. Malicious modification of these files could compromise accounts upon logon.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the global initialization file(s) to 0644. # chmod 0644 <global initialization file> Check global initialization files permissions: # ls -l /etc/bashrc # ls -l /etc/csh.cshrc # ls -l /etc/csh.login # ls -l /etc/csh.logout # ls -l /etc/environment # ls -l /etc/ksh.kshrc # ls -l /etc/profile # ls -l /etc/suid_profile # ls -l /etc/profile.d/* If global initialization files are more permissive than 0644, this is a finding. GEN001740 <GroupDescription></GroupDescription> GEN001740 All global initialization files must be owned by root. <VulnDiscussion>Global initialization files are used to configure the user's shell environment upon login. Malicious modification of these files could compromise accounts upon logon. Failure to give ownership of sensitive files or utilities to root or bin provides the designated owner and unauthorized users with the potential to access sensitive information or change the system configuration which could weaken the system's security posture.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the ownership of global initialization files with incorrect ownership. Procedure: # chown root <global initialization files> or: # ls etc/bashrc /etc/csh.cshrc /etc/csh.login /etc/csh.logout /etc/environment /etc/ksh.kshrc /etc/profile /etc/suid_profile /etc/profile.d/* 2>null|xargs stat -L -c %U:%n|egrep -v "^root"|cut -d: -f2|xargs chown root will set the owner of all files not currently owned by root to root. Check the ownership of global initialization files. Procedure: # ls -lL etc/bashrc /etc/csh.cshrc /etc/csh.login /etc/csh.logout /etc/environment /etc/ksh.kshrc /etc/profile /etc/suid_profile /etc/profile.d/* This should show information for each file. Examine to ensure the owner is always root or: # ls etc/bashrc /etc/csh.cshrc /etc/csh.login /etc/csh.logout /etc/environment /etc/ksh.kshrc /etc/profile /etc/suid_profile /etc/profile.d/* 2>null|xargs stat -L -c %U:%n|egrep -v "^root" This will show you only the owner and filename of files not owned by root. If any global initialization file is not owned by root, this is a finding. GEN001760 <GroupDescription></GroupDescription> GEN001760 All global initialization files must be group-owned by root, sys, bin, other, system, or the system default. <VulnDiscussion>Global initialization files are used to configure the user's shell environment upon login. Malicious modification of these files could compromise accounts upon logon. Failure to give ownership of sensitive files or utilities to root or bin provides the designated owner and unauthorized users with the potential to access sensitive information or change the system configuration which could weaken the system's security posture.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group ownership of the global initialization file(s) with incorrect group ownership. Procedure: # chgrp root <global initialization file> or: # ls -lL /etc/bashrc /etc/csh.cshrc /etc/csh.login /etc/csh.logout /etc/environment /etc/ksh.kshrc /etc/profile /etc/suid_profile /etc/profile.d/* 2>null|sed "s/^[^\/]*//"|xargs stat -L -c %G:%n|egrep -v "^(root|sys|bin|other):"|cut -d: -f2|xargs chgrp root will set the group of all files not currently owned by an approved group to root. Check the group ownership of global initialization files. Procedure: # ls -lL etc/bashrc /etc/csh.cshrc /etc/csh.login /etc/csh.logout /etc/environment /etc/ksh.kshrc /etc/profile /etc/suid_profile /etc/profile.d/* This should show information for each file. Examine to ensure the group is always root or: # ls -lL etc/bashrc /etc/csh.cshrc /etc/csh.login /etc/csh.logout /etc/environment /etc/ksh.kshrc /etc/profile /etc/suid_profile /etc/profile.d/* 2>null|sed "s/^[^\/]*//"|xargs stat -L -c %G:%n|egrep -v "^(root|sys|bin|other):" will show you only the group and filename of files not owned by one of the approved groups. If any global initialization file is not group-owned by root, sys, bin, other, system, or the system default, this is a finding. GEN001820 <GroupDescription></GroupDescription> GEN001820 All skeleton files and directories (typically in /etc/skel) must be owned by root or bin. <VulnDiscussion>If the skeleton files are not protected, unauthorized personnel could change user startup parameters and possibly jeopardize user files. Failure to give ownership of sensitive files or utilities to root or bin provides the designated owner and unauthorized users with the potential to access sensitive information or change the system configuration which could weaken the system's security posture.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the ownership of skeleton files with incorrect mode: # chown root <skeleton file> or # ls -L /etc/skel|xargs stat -L -c %U:%n|egrep -v "^(root|bin):"|cut -d: -f2|chown root will change all files not owned by root or bin to root. Check skeleton files ownership. # ls -alL /etc/skel If a skeleton file is not owned by root or bin, this is a finding. GEN001840 <GroupDescription></GroupDescription> GEN001840 All global initialization files' executable search paths must contain only absolute paths. <VulnDiscussion>The executable search path (typically the PATH environment variable) contains a list of directories for the shell to search to find executables. If this path includes the current working directory or other relative paths, executables in these directories may be executed instead of system commands. This variable is formatted as a colon-separated list of directories. If there is an empty entry, such as a leading or trailing colon, or two consecutive colons, this is interpreted as the current working directory. Paths starting with a slash (/) are absolute paths.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit the global initialization file(s) with PATH variables containing relative paths. Edit the file and remove the relative path from the PATH variable. Check the global initialization files' executable search paths. Procedure: # grep PATH /etc/bashrc /etc/csh.cshrc /etc/csh.login /etc/csh.logout /etc/environment /etc/ksh.kshrc /etc/profile /etc/suid_profile /etc/profile.d/* This variable is formatted as a colon-separated list of directories. If there is an empty entry, such as a leading or trailing colon, or two consecutive colons, this is a finding. If an entry begins with a character other than a slash (/) this is a relative path, this is a finding. GEN001900 <GroupDescription></GroupDescription> GEN001900 All local initialization files' executable search paths must contain only absolute paths. <VulnDiscussion>The executable search path (typically the PATH environment variable) contains a list of directories for the shell to search to find executables. If this path includes the current working directory or other relative paths, executables in these directories may be executed instead of system commands. This variable is formatted as a colon-separated list of directories. If there is an empty entry, such as a leading or trailing colon, or two consecutive colons, this is interpreted as the current working directory. Paths starting with a slash (/) are absolute paths.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit the local initialization file and remove the relative path entry from the executable search path variable. If this is not feasible, justify and document the necessity of having the relative path for a specific application. Verify local initialization files have executable search path containing only absolute paths or relative paths are necessary and documented. Procedure: NOTE: This must be done in the BASH shell. # cut -d: -f6 /etc/passwd |xargs -n1 -IDIR find DIR -name ".*" -type f -maxdepth 1 -exec grep -l PATH {} \; This variable is formatted as a colon-separated list of directories. If there is an empty entry, such as a leading or trailing colon, or two consecutive colons, this is a finding. If an entry begins with a character other than a slash (/) this is a relative path, ask the SA or IAO if the relative path is required for the operation of a specific application. If it is not, this is a finding. GEN001980 <GroupDescription></GroupDescription> GEN001980 The .rhosts, .shosts, hosts.equiv, shosts.equiv, /etc/passwd, /etc/shadow, and/or /etc/group files must not contain a plus (+) without defining entries for NIS+ netgroups. <VulnDiscussion>A plus (+) in system accounts files causes the system to lookup the specified entry using NIS. If the system is not using NIS, no such entries should exist.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit the .rhosts, .shosts, hosts.equiv, shosts.equiv, /etc/passwd, /etc/shadow, and/or /etc/group files and remove entries containing a plus (+). Check system configuration files for plus (+) entries. Procedure: # find / -name .rhosts # grep + /<directorylocation>/.rhosts # find / -name .shosts # grep + /<directorylocation>/.shosts # find / -name hosts.equiv # grep + /<directorylocation>/hosts.equiv # find / -name shosts.equiv # grep + /<directorylocation>/shosts.equiv # grep + /etc/passwd # grep + /etc/shadow # grep + /etc/group If the .rhosts, .shosts, hosts.equiv, shosts.equiv, /etc/passwd, /etc/shadow, and/or /etc/group files contain a plus (+) and do not define entries for NIS+ netgroups, this is a finding. GEN002040 <GroupDescription></GroupDescription> GEN002040 There must be no .rhosts, .shosts, hosts.equiv, or shosts.equiv files on the system. <VulnDiscussion>The .rhosts, .shosts, hosts.equiv, and shosts.equiv files are used to configure host-based authentication for individual users or the system. Host-based authentication is not sufficient for preventing unauthorized access to the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Remove all the r-commands access control files. Procedure: # find / -name .rhosts -exec rm {} \; # find / -name .shosts -exec rm {} \; # find / -name hosts.equiv -exec rm {} \; # find / -name shosts.equiv -exec rm {} \; Check for the existence of the files. # find / -name .rhosts # find / -name .shosts # find / -name hosts.equiv # find / -name shosts.equiv If .rhosts, .shosts, hosts.equiv, or shosts.equiv are found and their use has not been documented and approved by the IAO, this is a finding. GEN002100 <GroupDescription></GroupDescription> GEN002100 The .rhosts file must not be supported in PAM. <VulnDiscussion>.rhosts files are used to specify a list of hosts permitted remote access to a particular account without authenticating. The use of such a mechanism defeats strong identification and authentication requirements.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>Information Assurance Officer</Responsibility><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit the file(s) in /etc/pam.d referencing the rhosts_auth module, and remove the references to the rhosts_auth module. Check the PAM configuration for rhosts_auth. Example: # grep rhosts_auth /etc/pam.d/* If a rhosts_auth entry is found, this is a finding. GEN002540 <GroupDescription></GroupDescription> GEN002540 All public directories must be group-owned by root, sys, bin, or an application group. <VulnDiscussion>If a public directory has the sticky bit set and is not group-owned by a privileged GID, unauthorized users may be able to modify files created by others. The only authorized public directories are those temporary directories supplied with the system or those designed to be temporary file repositories. The setting is normally reserved for directories used by the system and by users for temporary file storage, (e.g., /tmp), and for directories requiring global read/write access.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group-ownership of the public directory. Procedure: # chgrp root /tmp (Replace root with a different system group and/or /tmp with a different public directory as necessary.) Check the group-ownership of public directories. Procedure: # find / -type d -perm -1002 -exec ls -ld {} \; If any public directory is not group-owned by root, sys, bin, or an application group, this is a finding. GEN003040 <GroupDescription></GroupDescription> GEN003040 Crontabs must be owned by root or the crontab creator. <VulnDiscussion>To protect the integrity of scheduled system jobs and prevent malicious modification to these jobs, crontab files must be secured.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCSL-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the crontab owner to root or the crontab creator. # chown root <crontab file> or # chown <user> <crontab file> List all crontabs on the system. # ls -lL /var/spool/cron # ls -lL /etc/cron.d /etc/crontab /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly or # ls -lL /etc/cron*|grep -v deny If any crontab is not owned by root or the creating user, this is a finding. GEN003060 <GroupDescription></GroupDescription> GEN003060 Default system accounts (with the exception of root) must not be listed in the cron.allow file or must be included in the cron.deny file, if cron.allow does not exist. <VulnDiscussion>To centralize the management of privileged account crontabs, of the default system accounts, only root may have a crontab.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECPA-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove default system accounts (such as bin, sys, adm, or others, traditionally UID less than 500) from the cron.allow file if it exists, or add those accounts to the cron.deny file. Check the cron.allow and cron.deny files for the system. # more /etc/cron.allow # more /etc/cron.deny If a default system account (such as bin, sys, adm, or others, traditionally UID less than 500) is listed in the cron.allow file, or not listed in the cron.deny file and if no cron.allow file exists, this is a finding. GEN003500 <GroupDescription></GroupDescription> GEN003500 Process core dumps must be disabled unless needed. <VulnDiscussion>Process core dumps contain the memory in use by the process when it crashed. Process core dump files can be of significant size and their use can result in file systems filling to capacity, which may result in Denial of Service. Process core dumps can be useful for software debugging. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4225-9 CCI-000366 Edit /etc/security/limits.conf and set a hard limit for "core" to 0 for all users. # ulimit -c If the above command does not return 0 and the enabling of core dumps has not been documented and approved by the IAO, this a finding. GEN003520 <GroupDescription></GroupDescription> GEN003520 The kernel core dump data directory must be owned by root. <VulnDiscussion>Kernel core dumps may contain the full contents of system memory at the time of the crash. As the system memory may contain sensitive information, it must be protected accordingly. If the kernel core dump data directory is not owned by root, the core dumps contained in the directory may be subject to unauthorized access.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the owner of the kernel core dump data directory to root. # chown root /var/crash Check the ownership of the kernel core dump data directory. # ls -ld /var/crash If the kernel core dump data directory is not owned by root, this is a finding. GEN003540 <GroupDescription></GroupDescription> GEN003540 The system must implement non-executable program stacks. <VulnDiscussion>A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2, ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Examine /etc/sysctl.conf for "kernel.exec-shield" and "kernel.randomize_va_space" entries and if found remove them. The system default of "1" enables these modules. Verify "exec_shield" and "randomize_va_space" have not been changed from the default "1" settings. Procedure: #sysctl kernel.exec-shield If the return value is not: kernel.exec-shield = 1 this is a finding. #sysctl kernel.randomize_va_space If the return value is not: kernel.randomize_va_space = 1 this is a finding. GEN003600 <GroupDescription></GroupDescription> GEN003600 The system must not forward IPv4 source-routed packets. <VulnDiscussion>Source-routed packets allow the source of the packet to suggest routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routed traffic, such as when IPv4 forwarding is enabled and the system is functioning as a router.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4236-6 CCI-001551 Configure the system to not accept source-routed IPv4 packets. Edit /etc/sysctl.conf and add a setting for "net.ipv4.conf.all.accept_source_route=0" and "net.ipv4.conf.default.accept_source_route=0". Reload the sysctls. Procedure: # sysctl -p Verify the system does not accept source-routed IPv4 packets. Procedure: # grep [01] /proc/sys/net/ipv4/conf/*/accept_source_route|egrep "default|all" If all of the returned lines do not end with 0, this is a finding. Note: The same setting is used by Linux for both the local acceptance and forwarding of source-routed IPv4 packets. GEN003620 <GroupDescription></GroupDescription> GEN003620 A separate file system must be used for user home directories (such as /home or an equivalent). <VulnDiscussion>The use of separate file systems for different paths can protect the system from failures resulting from a file system becoming full or failing.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>true</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001208 Migrate the /home (or equivalent) path onto a separate file system. Determine if the /home path is a separate filesystem. # grep "/home " /etc/fstab If no result is returned, /home is not on a separate filesystem this is a finding. GEN003660 <GroupDescription></GroupDescription> GEN003660 The system must log informational authentication data. <VulnDiscussion>Monitoring and recording successful and unsuccessful logins assists in tracking unauthorized access to the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000126 Edit /etc/syslog.conf and add local log destinations for "authpriv.*", "authpriv.debug" or "authpriv.info". Check /etc/syslog.conf and verify the authpriv facility is logging both the "notice" and "info" priority messages. Procedure: For a given action all messages of a higher severity or "priority" are logged. The three lowest priorities in ascending order are "debug", "info" and "notice". A priority of "info" will include "notice". A priority of "debug" includes both "info" and "notice". Enter/Input: # grep "authpriv.debug" /etc/syslog.conf # grep "authpriv.info" /etc/syslog.conf # grep "authpriv\.\*" /etc/syslog.conf If an "authpriv.*", "authpriv.debug", or "authpriv.info" entry is not found, this is a finding. GEN003700 <GroupDescription></GroupDescription> GEN003700 Inetd and xinetd must be disabled or removed if no network services utilizing them are enabled. <VulnDiscussion>Unnecessary services should be disabled to decrease the attack surface of the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000305 # service xinetd stop ; chkconfig xinetd off # ps -ef |grep xinetd If xinetd is not running, this check is not a finding. # grep -v "^#" /etc/xinetd.conf # grep disable /etc/xinetd.d/* |grep no If no active services are found, and the inetd daemon is running, this is a finding. GEN004540 <GroupDescription></GroupDescription> GEN004540 The SMTP service HELP command must not be enabled. <VulnDiscussion>The HELP command should be disabled to mask version information. The version of the SMTP service software could be used by attackers to target vulnerabilities present in specific software versions.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 To disable the SMTP HELP command, clear the Sendmail help file. # echo > /etc/mail/helpfile Check if Help is disabled. This rule is for "sendmail" only and not applicable to "Postfix". Procedure: # telnet localhost 25 > help If the help command returns any sendmail version information, this is a finding. If sendmail is not installed this check is not applicable. GEN004800 <GroupDescription></GroupDescription> GEN004800 Unencrypted FTP must not be used on the system. <VulnDiscussion>: FTP is typically unencrypted and presents confidentiality and integrity risks. FTP may be protected by encryption in certain cases, such as when used in a Kerberos environment. SFTP and FTPS are encrypted alternatives to FTP.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>true</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Disable the FTP daemons. Procedure: # chkconfig gssftp off # chkconfig vsftpd off Perform the following to determine if unencrypted FTP is enabled: # chkconfig --list gssftp # chkconfig --list vsftpd If any of these services are found, ask the SA if these services are encrypted. If they are not, this is a finding. GEN005040 <GroupDescription></GroupDescription> GEN005040 All FTP users must have a default umask of 077. <VulnDiscussion>The umask controls the default access mode assigned to newly created files. An umask of 077 limits new files to mode 700 or less permissive. Although umask is stored as a 4-digit number, the first digit representing special access modes is typically ignored or required to be zero (0).</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Edit the initialization files for the ftp user and set the umask to 077. Procedure: For gssftp: Modify the /etc/xinetd.d/gssftp file adding "-u 077" to the server_args entry. For vsftp: Modify the "/etc/vsftpd/vsftpd.conf" setting "local_umask" and "anon_umask" to 077. Check the umask setting for FTP users. Procedure: For gssftp: Assuming an anonymous ftp user has been defined with no user initialization script invoked to change the umask # ftp localhost Name: (localhost:root): anonymous Password: anything ftp>umask If the umask value returned is not 077, this is a finding. or: # grep "server_args" /etc/xinetd.d/gssftp The default umask for FTP is "023" if the server _args entry does not contain "-u 077" this is a finding. For vsftp: # grep "_mask" /etc/vsftpd/vsftpd.conf The default "local_umask" setting is 077. If this has been changed, or the "anon_umask" setting is not 077, this is a finding. GEN005180 <GroupDescription></GroupDescription> GEN005180 All .Xauthority files must have mode 0600 or less permissive. <VulnDiscussion>.Xauthority files ensure the user is authorized to access specific X Windows host. Excessive permissions may permit unauthorized modification of these files, which could lead to Denial of Service to authorized access or allow unauthorized access to be obtained.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the .Xauthority files. Procedure: # chmod 0600 .Xauthority Check the file permissions for the .Xauthority files. Procedure: # ls -la |egrep "(\.Xauthority|\.xauth)" If the file mode is more permissive than 0600, this is finding. GEN005220 <GroupDescription></GroupDescription> GEN005220 .Xauthority or X*.hosts (or equivalent) file(s) must be used to restrict access to the X server. <VulnDiscussion>If access to the X server is not restricted, a user's X session may be compromised.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000297 Create an X*.hosts file, where "*" is a display number used to limit X window connections. Add the list of authorized X clients to the file. Determine if the X server is running. Procedure: # ps -ef |grep X Determine if xauth is being used. Procedure: # xauth xauth> list If the above command sequence does not show any host other than the localhost, then xauth is not being used. Search the system for an X*.hosts file, where "*" is a display number used to limit X window connections. If no files are found, X*.hosts files are not being used. If the X*.hosts files contain any unauthorized hosts, this is a finding. If both xauth and X*.hosts files are not being used, this is a finding. GEN005240 <GroupDescription></GroupDescription> GEN005240 The .Xauthority utility must only permit access to authorized hosts. <VulnDiscussion>If unauthorized clients are permitted access to the X server, a user's X session may be compromised.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove unauthorized clients from the xauth configuration. # xauth remove <display name> Check the X window system access is limited to authorized clients. Procedure: # xauth xauth> list Ask the SA if the clients listed are authorized. If any are not, this is a finding. GEN005260 <GroupDescription></GroupDescription> GEN005260 X Window System connections not required must be disabled. <VulnDiscussion>If unauthorized clients are permitted access to the X server, a user's X session may be compromised.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4462-8 CCI-001436 Disable the X Windows server on the system. Determine if the X window system is running. Procedure: # ps -ef |grep Xorg Ask the SA if the X window system is an operational requirement. If it is not, this is a finding. GEN005360 <GroupDescription></GroupDescription> GEN005360 The snmpd.conf file must be owned by root. <VulnDiscussion>The snmpd.conf file contains authenticators and must be protected from unauthorized access and modification. If the file is not owned by root, it may be subject to access and modification from unauthorized users.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the owner of the snmpd.conf file to root. Procedure: # chown root <snmpd.conf file> Determine the owner of the SNMP configuration file. Procedure: Find the snmpd.conf file. The default install location is /etc/snmp/snmpd.conf but may be different depending on the SNMP agent installed. # find / -name snmpd.conf # ls -lL <snmpd.conf> If the snmpd.conf file is not owned by root, this is a finding. GEN005440 <GroupDescription></GroupDescription> GEN005440 The system must not be used as a syslog server (loghost) for systems external to the enclave. <VulnDiscussion>Syslog messages are typically unencrypted, may contain sensitive information, and are restricted to the enclave.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Configure the hosts outside of the local enclave to not log to this system. Ask the SA if the loghost server is collecting data for hosts outside the local enclave. If it is, this is a finding. GEN005480 <GroupDescription></GroupDescription> GEN005480 The syslog daemon must not accept remote messages unless it is a syslog server documented using site-defined procedures. <VulnDiscussion>Unintentionally running a syslog server accepting remote messages puts the system at increased risk. Malicious syslog messages sent to the server could exploit vulnerabilities in the server software itself, could introduce misleading information in to the system's logs, or could fill the system's storage leading to a Denial of Service.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-3382-9 CCI-000366 Edit /etc/sysconfig/syslog to removing the '-r' in SYSLOGD_OPTIONS. Restart the syslogd service. Ask the SA if the system is an authorized syslog server. If the system is an authorized syslog server, this is not applicable. Determine if the system's syslog service is configured to accept remote messages. # ps -ef | grep syslogd If the '-r' option is present, the system is configured to accept remote syslog messages, and this is a finding. GEN005540 <GroupDescription></GroupDescription> GEN005540 The SSH daemon must be configured for IP filtering. <VulnDiscussion>The SSH daemon must be configured for IP filtering to provide a layered defense against connection attempts from unauthorized addresses.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1, ECWM-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Add appropriate IP restrictions for SSH to the /etc/hosts.deny and/or /etc/hosts.allow files. Check the TCP wrappers configuration files to determine if sshd is configured to use TCP wrappers. Procedure: # grep sshd /etc/hosts.deny # grep sshd /etc/hosts.allow If no entries are returned, the TCP wrappers are not configured for sshd, this is a finding. GEN005600 <GroupDescription></GroupDescription> GEN005600 IP forwarding for IPv4 must not be enabled, unless the system is a router. <VulnDiscussion>If the system is configured for IP forwarding and is not a designated router, it could be used to bypass network security by providing a path for communication not filtered by network devices.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-3561-8 CCI-000366 Edit "/etc/sysctl.conf" and set net.ipv4.ip_forward to "0". Restart the system or run "sysctl -p" to make the change take effect. Check if the system is configured for IPv4 forwarding. If the system is a VM host and acts as a router solely for the benefits of its client systems, then this rule is not applicable. Procedure: # cat /proc/sys/net/ipv4/ip_forward If the value is set to "1", IPv4 forwarding is enabled this is a finding. GEN006000 <GroupDescription></GroupDescription> GEN006000 The system must not have a public Instant Messaging (IM) client installed. <VulnDiscussion>Public (IM) systems are not approved for use and may result in the unauthorized distribution of information. IM clients provide a way for a user to send a message to one or more other users in real time. Additional capabilities may include file transfer and support for distributed game playing. Communication between clients and associated directory services are managed through messaging servers. Commercial IM clients include AOL Instant Messenger (AIM), MSN Messenger, and Yahoo! Messenger. IM clients present a security issue when the clients route messages through public servers. The obvious implication is potentially sensitive information could be intercepted or altered in the course of transmission. This same issue is associated with the use of public e-mail servers. In order to reduce the potential for disclosure of sensitive Government information and to ensure the validity of official government information, IM clients connecting to public IM services will not be installed. Clients use to access internal or DoD-controlled IM services are permitted.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECIM-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 CCI-001154 Uninstall the IM client from the system, or configure the client to only connect to DoD-approved IM services. If an IM client is installed, ask the SA if it has access to any public domain IM servers. If it does have access to public servers, this is a finding. GEN006040 <GroupDescription></GroupDescription> GEN006040 The system must not have any peer-to-peer file-sharing application installed. <VulnDiscussion>Peer-to-peer file-sharing software can result in the unintentional exfiltration of information. There are also many legal issues associated with these types of utilities including copyright infringement or other intellectual property issues. The ASD Memo "Use of Peer-to-Peer (P2P) File-Sharing Applications across the DoD" states the following: “P2P file-sharing applications are authorized for use on DOD networks with approval by the appropriate Designated Approval Authority (DAA). Documented requirements, security architecture, configuration management process, and a training program for users are all requirements within the approval process. The unauthorized use of application or services, including P2P applications, is prohibited, and such applications or services must be eliminated.†P2P applications include, but are not limited to, the following: -Napster -Kazaa -ARES -Limewire -IRC Chat Relay -BitTorrent</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><Responsibility>Designated Approving Authority</Responsibility><IAControls>DCPD-1, ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001436 Uninstall the peer-to-peer file sharing application(s) from the system. Ask the SA if any peer-to-peer file-sharing applications are installed. Some examples of these applications include: - Napster - Kazaa - ARES - Limewire - IRC Chat Relay - BitTorrent If any of these applications are installed, this is a finding. GEN006420 <GroupDescription></GroupDescription> GEN006420 NIS maps must be protected through hard-to-guess domain names. <VulnDiscussion>The use of hard-to-guess NIS domain names provides additional protection from unauthorized access to the NIS directory information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Change the NIS domainname to a value difficult to guess. Consult vendor documentation for the required procedure. Check the domain name for NIS maps. Procedure: # domainname If the name returned is simple to guess, such as the organization name, building or room name, etc., this is a finding. If the system does not use NIS, this is not applicable. GEN006560 <GroupDescription></GroupDescription> GEN006560 The system vulnerability assessment tool, host-based intrusion detection tool, and file integrity tool must notify the SA and the IAO of a security breach or a suspected security breach. <VulnDiscussion>Timely notifications of potential security compromises minimize the potential damage. Minimally, the system must log these events and the SA and the IAO will receive the notifications during the daily system log review. If feasible, active alerting (such as e-mail or paging) should be employed consistent with the site’s established operations management systems and procedures.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><Responsibility>Information Assurance Officer</Responsibility><IAControls>ECAT-1, ECAT-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 CCI-001266 Configure the security tools on the system to notify the IAO and SA when any security issues are detected. For each security tool on the system, determine if the tool is configured to notify the IAO and SA of any detected security problem. If such notifications are not configured, this is a finding. GEN006620 <GroupDescription></GroupDescription> GEN006620 The system's access control program must be configured to grant or deny system access to specific hosts. <VulnDiscussion>If the system's access control program is not configured with appropriate rules for allowing and denying access to system network resources, services may be accessible to unauthorized hosts.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECCD-1, ECCD-2, ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit the "/etc/hosts.all" and "/etc/hosts.deny" files to configure access restrictions. Check for the existence of the "/etc/hosts.allow" and "/etc/hosts.deny" files. Procedure: # ls -la /etc/hosts.allow # ls -la /etc/hosts.deny If either file does not exist, this is a finding. Check for the presence of a "default deny" entry. Procedure: # grep "ALL: ALL" /etc/hosts.deny If the "ALL: ALL" entry is not present the "/etc/hosts.deny" file, any TCP service from a host or network not matching other rules will be allowed access. If the entry is not in "/etc/hosts.deny", this is a finding. GEN000000-LNX00620 <GroupDescription></GroupDescription> GEN000000-LNX00620 The /etc/securetty file must be group-owned by root, sys, or bin. <VulnDiscussion>The securetty file contains the list of terminals permitting direct root logins. It must be protected from unauthorized modification.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group-owner of /etc/securetty to root, sys, or bin. Example: # chgrp root /etc/securetty Check /etc/securetty group ownership: # ls -lL /etc/securetty If /etc/securetty is not group owned by root, sys, or bin, then this is a finding. GEN000000-LNX00640 <GroupDescription></GroupDescription> GEN000000-LNX00640 The /etc/securetty file must be owned by root. <VulnDiscussion>The securetty file contains the list of terminals permitting direct root logins. It must be protected from unauthorized modification.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 CCI-000366 Change the owner of the /etc/securetty file to root. Procedure: # chown root /etc/securetty Check /etc/securetty ownership. Procedure: # ls -lL /etc/securetty If /etc/securetty is not owned by root, this is a finding. GEN000000-LNX00660 <GroupDescription></GroupDescription> GEN000000-LNX00660 The /etc/securetty file must have mode 0600 or less permissive. <VulnDiscussion>The securetty file contains the list of terminals permitting direct root logins. It must be protected from unauthorized modification.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 CCI-000366 Change the mode of the /etc/securetty file to 0600. Procedure: # chmod 0600 /etc/securetty Check /etc/securetty permissions. Procedure: # ls -lL /etc/securetty If /etc/securetty has a mode more permissive than 0600, this is a finding. GEN003865 <GroupDescription></GroupDescription> GEN003865 Network analysis tools must not be installed. <VulnDiscussion>Network analysis tools allow for the capture of network traffic visible to the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCPA-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000305 Remove each network analysis tool binary from the system. Remove package items with a package manager, others remove the binary directly. Procedure: Find the binary file: # find / -name <Item to be removed> Find the package, if any, to which it belongs: # rpm -qf <binary file> Remove the package if it does not also include other software: # rpm -e <package name> or # yum remove <package name> If the item to be removed is not in a package, or the entire package cannot be removed because of other software it provides, remove the item's binary file. # rm <binary file> Determine if any network analysis tools are installed. Procedure: # find / -name ethereal # find / -name wireshark # find / -name tshark # find / -name nc # find / -name tcpdump # find / -name snoop If any network analysis tools are found, this is a finding GEN006640 <GroupDescription></GroupDescription> GEN006640 The system must use and update a DoD-approved virus scan program. <VulnDiscussion>Virus scanning software can be used to protect a system from penetration from computer viruses and to limit their spread through intermediate systems. The virus scanning software should be configured to perform scans dynamically on accessed files. If this capability is not available, the system must be configured to scan, at a minimum, all altered files on the system on a daily basis. If the system processes inbound SMTP mail, the virus scanner must be configured to scan all received mail.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECVP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001668 Install a DoD-approved command-line virus scan tool, or an appropriate alternative. Ensure the virus signature definition files are no older than 7 days. Configure the system to run a virus scan on altered files dynamically or daily. If daily scans impede operations, justify, document, and obtain IAO approval for alternate scheduling. Check for the existence of a cron job to execute a DoD-approved command-line scan tool daily. Other tools may be available but will have to be manually reviewed if they are installed. In addition, the definitions files should not be older than 7 days. Check if DoD-approved command-line scan tool is scheduled to run: # grep [scan tool] /var/spool/cron/* /etc/cron.d/* /etc/cron.daily/* /etc/cron.hourly/* /etc/cron.monthly/* /etc/cron.weekly/* If a virus scanner is not being run daily and an exception has not been documented with the IAO, this is a finding. Perform the following command to ensure the virus definition signature files are not older than 7 days. # cd <scan tool install directory> # ls -la *.dat If the virus definitions are older than 7 days, this is a finding. GEN000241 <GroupDescription></GroupDescription> GEN000241 The system clock must be synchronized continuously, or at least daily. <VulnDiscussion>A synchronized system clock is critical for the enforcement of time-based policies and the correlation of logs and audit records with other systems. Internal system clocks tend to drift and require periodic resynchronization to ensure their accuracy. Software, such as ntpd, can be used to continuously synchronize the system clock with authoritative sources. Alternatively, the system may be synchronized periodically, with a maximum of one day between synchronizations. If the system is completely isolated (i.e., it has no connections to networks or other systems), time synchronization is not required as no correlation of events or operation of time-dependent protocols between systems will be necessary. If the system is completely isolated, this requirement is not applicable.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Enable the NTP daemon for continuous synchronization. # service ntpd start ; chkconfig ntpd on OR Add a daily or more frequent cronjob to perform synchronization using ntpdate. Check the root crontab (crontab -l) and the global crontabs in /etc/crontab, /etc/cron.d/* for the presence of an "ntpd -qg" job to run at least daily, which should have asterisks (*) in columns 3, 4, and 5. Check the daily cron directory (/etc/cron.daily) for any script running "ntpd -qg". Check for a running NTP daemon. # ps ax | grep ntpd If none of the above checks are successful, this is a finding. GEN000242 <GroupDescription></GroupDescription> GEN000242 The system must use at least two time sources for clock synchronization. <VulnDiscussion>A synchronized system clock is critical for the enforcement of time-based policies and the correlation of logs and audit records with other systems. For redundancy, two time sources are required so synchronization continues to function if one source fails. If the system is completely isolated (i.e., it has no connections to networks or other systems), time synchronization is not required as no correlation of events or operation of time-dependent protocols between systems will be necessary. If the system is completely isolated, this requirement is not applicable. Note: For the network time protocol (NTP), the requirement is two servers, but it is recommended to configure at least four distinct time servers which allow NTP to effectively exclude a time source not consistent with the others. The system's local clock must be excluded from the count of time sources.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000160 If using "ntpd -qg", add additional NTP servers to the cron job running "ntpd -qg". If using the NTP daemon, add an additional "server" line to /etc/ntp.conf for each additional NTP server. Check the root crontab (crontab -l) and the global crontabs in /etc/crontab, /etc/cron.d/*, or scripts in the /etc/cron.daily directory for the presence of an "ntpd -qg" job. If the "ntpd -qg" command is not invoked with at least two external NTP servers listed, this is a finding. Check the NTP daemon configuration for at least two external servers. # grep ^server /etc/ntp.conf | egrep -v '(127.127.1.0|127.127.1.1)' If less than two servers or external reference clocks (127.127.x.x other than 127.127.1.0 or 127.127.1.1) are listed, this is a finding. GEN000244 <GroupDescription></GroupDescription> GEN000244 The system must use time sources local to the enclave. <VulnDiscussion>A synchronized system clock is critical for the enforcement of time-based policies and the correlation of logs and audit records with other systems. The network architecture should provide multiple time servers within an enclave providing local service to the enclave and synchronize with time sources outside of the enclave. If this server is an enclave time server, this requirement is not applicable. If the system is completely isolated (i.e., it has no connections to networks or other systems), time synchronization is not required as no correlation of events or operation of time-dependent protocols between systems will be necessary. If the system is completely isolated, this requirement is not applicable.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000160 If using "ntpd -qg", remove NTP servers external to the enclave from the cron job running "ntpd -qg". If using the NTP daemon, remove the "server" line from /etc/ntp.conf for each NTP server external to the enclave. Check the root crontab (crontab -l) and the global crontabs in /etc/crontab, /etc/cron.d/*, or scripts in the /etc/cron.daily directory for the presence of an "ntpd -qg" job. If the "ntpd -qg" command is invoked with NTP servers outside of the enclave, this is a finding. Check the NTP daemon configuration for NTP servers. # grep ^server /etc/ntp.conf | grep -v 127.127.1.1 If an NTP server is listed outside of the enclave, this is a finding. GEN000250 <GroupDescription></GroupDescription> GEN000250 The time synchronization configuration file (such as /etc/ntp.conf) must be owned by root. <VulnDiscussion>A synchronized system clock is critical for the enforcement of time-based policies and the correlation of logs and audit records with other systems. If an illicit time source is used for synchronization, the integrity of system logs and the security of the system could be compromised. If the configuration files controlling time synchronization are not owned by a system account, unauthorized modifications could result in the failure of time synchronization.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the owner of the NTP configuration file. # chown root /etc/ntp.conf Check the ownership of the NTP configuration file. # ls -l /etc/ntp.conf If the owner is not root, this is a finding. GEN000251 <GroupDescription></GroupDescription> GEN000251 The time synchronization configuration file (such as /etc/ntp.conf) must be group-owned by root, bin, or sys. <VulnDiscussion>A synchronized system clock is critical for the enforcement of time-based policies and the correlation of logs and audit records with other systems. If an illicit time source is used for synchronization, the integrity of system logs and the security of the system could be compromised. If the configuration files controlling time synchronization are not owned by a system group, unauthorized modifications could result in the failure of time synchronization.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group-owner of the NTP configuration file. Procedure: # chgrp root /etc/ntp.conf Check the group ownership of the NTP configuration file. Procedure: # ls -lL /etc/ntp.conf If the group owner is not root, bin, or sys, this is a finding. GEN000252 <GroupDescription></GroupDescription> GEN000252 The time synchronization configuration file (such as /etc/ntp.conf) must have mode 0640 or less permissive. <VulnDiscussion>A synchronized system clock is critical for the enforcement of time-based policies and the correlation of logs and audit records with other systems. If an illicit time source is used for synchronization, the integrity of system logs and the security of the system could be compromised. If the configuration files controlling time synchronization are not protected, unauthorized modifications could result in the failure of time synchronization.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the NTP configuration file to 0640 or more restrictive. # chmod 0640 /etc/ntp.conf Check the mode for the NTP configuration file is not more permissive than 0640. # ls -l /etc/ntp.conf If the mode is more permissive than 0640, this is a finding. GEN000253 <GroupDescription></GroupDescription> GEN000253 The time synchronization configuration file (such as /etc/ntp.conf) must not have an extended ACL. <VulnDiscussion>A synchronized system clock is critical for the enforcement of time-based policies and the correlation of logs and audit records with other systems. If an illicit time source is used for synchronization, the integrity of system logs and the security of the system could be compromised. If the configuration files controlling time synchronization are not protected, unauthorized modifications could result in the failure of time synchronization.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the NTP configuration file. # setfacl --remove-all /etc/ntp.conf Check the NTP configuration file has no extended ACL. # ls -l /etc/ntp.conf If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN000450 <GroupDescription></GroupDescription> GEN000450 The system must limit users to 10 simultaneous system logins, or a site-defined number, in accordance with operational requirements. <VulnDiscussion>Limiting simultaneous user logins can insulate the system from denial of service problems caused by excessive logins. Automated login processes operating improperly or maliciously may result in an exceptional number of simultaneous login sessions. If the defined value of 10 logins does not meet operational requirements, the site may define the permitted number of simultaneous login sessions based on operational requirements. This limit is for the number of simultaneous login sessions for EACH user account. This is NOT a limit on the total number of simultaneous login sessions on the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>true</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000054 Add a "maxlogins" line such as "* hard maxlogins 10" to /etc/security/limits.conf or a file in /etc/security/limits.d. The enforced maximum should be defined by site requirements and policy. Check for a default maxlogins line in the /etc/security/limits.conf and /etc/security/limits.d/* files. Procedure: #grep maxlogins /etc/security/limits.conf /etc/security/limits.d/* The default maxlimits should be set to a max of 10 or a documented site defined number: * - maxlogins 10 If no such line exists, this is a finding. GEN000452 <GroupDescription></GroupDescription> GEN000452 The system must display the date and time of the last successful account login upon login. <VulnDiscussion>Providing users with feedback on when account accesses last occurred facilitates user recognition and reporting of unauthorized account use.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000052 Implement pam_lastlog, or enable PrintLastLog in the SSH daemon. To enable pam_lastlog, add a line such as "session required pam_lastlog.so" to /etc/pam.d/sshd. To enable PrintLastLog in the SSH daemon, remove any lines disabling this option from /etc/ssh/sshd_config. Check that pam_lastlog is used and not silent, or that the SSH daemon is configured to display last login information. # grep pam_lastlog /etc/pam.d/sshd If pam_lastlog is present, and does not have the "silent" option, this is not a finding. # grep -i PrintLastLog /etc/ssh/sshd_config If PrintLastLog is not present in the configuration, this is not a finding. This is the default setting. If PrintLastLog is present in the configuration and set to "yes" (case insensitive), this is not a finding. Otherwise, this is a finding. GEN000510 <GroupDescription></GroupDescription> GEN000510 The system must display a publicly-viewable pattern during a graphical desktop environment session lock. <VulnDiscussion>To protect the on-screen content of a session, it must be replaced with a publicly-viewable pattern upon session lock. Examples of publicly viewable patterns include screen saver patterns, photographic images, solid colors, or a blank screen, so long as none of those patterns convey sensitive information. This requirement applies to graphical desktop environments provided by the system to locally attached displays and input devices, as well as, to graphical desktop environments provided to remote systems using remote access protocols.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>PESL-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000061 Configure the system to display a publicly-viewable pattern during a session lock. This is done graphically by selecting a screensaver theme using gnome-screensaver-preferences command. Any of the themes distributed with RHEL may be used including "Blank Screen". Determine if a publicly-viewable pattern is displayed during a session lock. Some screensaver themes available but not included in the RHEL distribution use a snapshot of the current screen as a graphic. This theme does not qualify as a publicly-viewable pattern. If the session lock pattern is not publicly-viewable this is a finding. GEN000585 <GroupDescription></GroupDescription> GEN000585 The system must enforce compliance of the entire password during authentification. <VulnDiscussion>Some common password hashing schemes only process the first eight characters of a user's password, which reduces the effective strength of the password.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAIA-1, IAIA-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000205 Change the passwords for all accounts using non-compliant password hashes. (This requires GEN000590 is already met.) Verify no password hash in /etc/passwd or /etc/shadow begins with a character other than an underscore (_) or dollar sign ($). # cut -d ':' -f2 /etc/passwd # cut -d ':' -f2 /etc/shadow If any password hash is present that does not have an initial underscore (_) or dollar sign ($) character, this is a finding. GEN000590 <GroupDescription></GroupDescription> GEN000590 The system must use a FIPS 140-2 approved cryptographic hashing algorithm for generating account password hashes. <VulnDiscussion>Systems must employ cryptographic hashes for passwords using the SHA-2 family of algorithms or FIPS 140-2 approved successors. The use of unapproved algorithms may result in weak password hashes more vulnerable to compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCNR-1, IAIA-1, IAIA-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14063-2 CCI-000803 Change the default password algorithm. # authconfig --passalgo=sha512 --update Verify the algorithm used for password hashing is of the SHA-2 family. # egrep "password .* pam_unix.so" /etc/pam.d/system-auth-ac If the line indicates the hash algorithm is not set to sha256 or sha512, this is a finding. GEN000595 <GroupDescription></GroupDescription> GEN000595 The password hashes stored on the system must have been generated using a FIPS 140-2 approved cryptographic hashing algorithm. <VulnDiscussion>Systems must employ cryptographic hashes for passwords using the SHA-2 family of algorithms or FIPS 140-2 approved successors. The use of unapproved algorithms may result in weak password hashes more vulnerable to compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCNR-1, IAIA-1, IAIA-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000196 Change the passwords for all accounts using non-compliant password hashes. (This requires GEN000590 is already met.) Check all password hashes in /etc/passwd or /etc/shadow begin with '$5$' or '$6$'. Procedure: # cut -d ':' -f2 /etc/passwd # cut -d ':' -f2 /etc/shadow Any password hashes present not beginning with '$5$' or, '$6$' is a finding. Any entries showing only NP, LK, or x are not findings. GEN000610 <GroupDescription></GroupDescription> GEN000610 The system must require passwords contain at least one lowercase alphabetic character. <VulnDiscussion>To enforce the use of complex passwords, minimum numbers of characters of different classes are mandated. The use of complex passwords reduces the ability of attackers to successfully obtain valid passwords using guessing or exhaustive search techniques. Complexity requirements increase the password search space by requiring users to construct passwords from a larger character set than they may otherwise use.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAIA-1, IAIA-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14712-4 CCI-000193 Edit "/etc/pam.d/system-auth" to include the line: password required pam_cracklib.so lcredit=-1 prior to the "password include system-auth-ac" line. Check /etc/pam.d/system-auth for lcredit setting. Procedure: Check the password lcredit option # grep pam_cracklib.so /etc/pam.d/system-auth Confirm the lcredit option is set to -1 as in the example: password required pam_cracklib.so lcredit=-1 There may be other options on the line. If no such line is found, or the lcredit is not -1 this is a finding. GEN000750 <GroupDescription></GroupDescription> GEN000750 The system must require at least four characters be changed between the old and new passwords during a password change. <VulnDiscussion>To ensure password changes are effective in their goals, the system must ensure that old and new passwords have significant differences. Without significant changes, new passwords may be easily guessed based on the value of a previously compromised password.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAIA-1, IAIA-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14701-7 CCI-000195 If /etc/pam.d/system-auth references /etc/pam.d/system-auth-ac refer to the man page for system-auth-ac for a description of how to add options not configurable with authconfig. Edit /etc/pam.d/system-auth and add or edit a pam_cracklib entry with an difok parameter set equal to or greater than 4. Check /etc/pam.d/system-auth for a pam_cracklib parameter difok. Procedure: # grep difok /etc/pam.d/system-auth If difok is not present, or has a value less than 4, this is a finding. Check for system-auth-ac inclusions. # grep -c system-auth-ac /etc/pam.d/* If the system-auth-ac file is included anywhere # more /etc/pam.d/system-auth-ac | grep difok If system-auth-ac is included anywhere and difok is not present, or has a value less than 4, this is a finding. Ensure the passwd command uses the system-auth settings. # grep system-auth /etc/pam.d/passwd If a line "password include system-auth" is not found then the password checks in system-auth will not be applied to new passwords. GEN000790 <GroupDescription></GroupDescription> GEN000790 The system must prevent the use of dictionary words for passwords. <VulnDiscussion>An easily guessable password provides an open door to any external or internal malicious intruder. Many computer compromises occur as the result of account name and password guessing. This is generally done by someone with an automated script that uses repeated logon attempts until the correct account and password pair is guessed. Utilities, such as cracklib, can be used to validate passwords are not dictionary words and meet other criteria during password changes.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAIA-1, IAIA-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000189 If /etc/pam.d/system-auth references /etc/pam.d/system-auth-ac refer to the man page for system-auth-ac for a description of how to add options not configurable with authconfig. Edit /etc/pam.d/system-auth and configure pam_cracklib by adding a line such as "password required pam_cracklib.so" Check /etc/pam.d/system-auth for pam_cracklib configuration. Procedure: # grep pam_cracklib /etc/pam.d/system-auth* If pam_cracklib is not present. This is a finding. If pam_cracklib is present only in /etc/pam.d/system-auth-ac: ensure that /etc/pam.d/system-auth includes /etc/pam.d/system-auth-ac. #grep system-auth-ac /etc/pam.d/system-auth This should return: auth include system-auth-ac account include system-auth-ac password include system-auth-ac session include system-auth-ac /etc/pam.d/system-auth-ac should only be included by /etc/pam.d/system-auth. All other pam files should include /etc/pam.d/system-auth. If pam_cracklib is not defined in /etc/pam.d/system-auth either directly or through inclusion of system-auth-ac, this is a finding. Ensure the passwd command uses the system-auth settings. # grep system-auth /etc/pam.d/passwd If a line "password include system-auth" is not found then the password checks in system-auth will not be applied to new passwords, this is a finding. GEN000850 <GroupDescription></GroupDescription> GEN000850 The system must restrict the ability to switch to the root user to members of a defined group. <VulnDiscussion>Configuring a supplemental group for users permitted to switch to the root user prevents unauthorized users from accessing the root account, even with knowledge of the root credentials.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-15047-4 CCI-000009 Edit /etc/pam.d/su and uncomment or add a line such as "auth required pam_wheel.so". If necessary, create a "wheel" group and add administrative users to the group. Check /etc/pam.d/su uses pam_wheel. # grep pam_wheel /etc/pam.d/su If pam_wheel is not present, or is commented out, this is a finding. GEN000930 <GroupDescription></GroupDescription> GEN000930 The root account's home directory must not have an extended ACL. <VulnDiscussion>File system extended ACLs provide access to files beyond what is allowed by the unix permissions of the files.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the root account's home directory. # setfacl --remove-all <root home directory> Check the root account's home directory has no extended ACL. # grep "^root" /etc/passwd | awk -F":" '{print $6}' # ls -ld <root home directory> If the permissions include a '+' the directory has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN000945 <GroupDescription></GroupDescription> GEN000945 The root account's library search path must be the system default and must contain only absolute paths. <VulnDiscussion>The library search path environment variable(s) contain a list of directories for the dynamic linker to search to find libraries. If this path includes the current working directory or other relative paths, libraries in these directories may be loaded instead of system libraries. This variable is formatted as a colon-separated list of directories. If there is an empty entry, such as a leading or trailing colon or two consecutive colons, this is interpreted as the current working directory. Entries starting with a slash (/) are absolute paths.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit the root user initialization files and remove any definition of LD_LIBRARY_PATH. Check the LD_LIBRARY_PATH environment variable is empty or not defined for the root user. # echo $LD_LIBRARY_PATH If a path list is returned, this is a finding. GEN000950 <GroupDescription></GroupDescription> GEN000950 The root account's list of preloaded libraries must be empty. <VulnDiscussion>The library preload list environment variable contains a list of libraries for the dynamic linker to load before loading the libraries required by the binary. If this list contains paths to libraries relative to the current working directory, unintended libraries may be preloaded. This variable is formatted as a space-separated list of libraries. Paths starting with (/) are absolute paths.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit the root user initialization files and remove any definition of LD_PRELOAD. Check the LD_PRELOAD environment variable is empty or not defined for the root user. # echo $LD_PRELOAD If a path list is returned, this is a finding. GEN001170 <GroupDescription></GroupDescription> GEN001170 All files and directories must have a valid group-owner. <VulnDiscussion>Files without a valid group owner may be unintentionally inherited if a group is assigned the same GID as the GID of the files without a valid group-owner.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Change the group-owner for each file without a valid group-owner. # chgrp avalidgroup /tmp/a-file-without-a-valid-group-owner Search the system for files without a valid group-owner. # find / -nogroup If any files are found, this is a finding. GEN001190 <GroupDescription></GroupDescription> GEN001190 All network services daemon files must not have extended ACLs. <VulnDiscussion>Restricting permission on daemons will protect them from unauthorized modification and possible system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all /usr/sbin/* Check network services daemon files have no extended ACLs. # ls -la /usr/sbin If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. Note: Network daemons not residing in these directories must also be checked. GEN001210 <GroupDescription></GroupDescription> GEN001210 All system command files must not have extended ACLs. <VulnDiscussion>Restricting permissions will protect system command files from unauthorized modification. System command files include files present in directories used by the operating system for storing default system executables and files present in directories included in the system's default executable search paths.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001499 Remove the extended ACL from the file. # setfacl --remove-all [file with extended ACL] Check all system command files have no extended ACLs. # ls -lL /etc /bin /usr/bin /usr/lbin /usr/usb /sbin /usr/sbin If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN001270 <GroupDescription></GroupDescription> GEN001270 System log files must not have extended ACLs, except as needed to support authorized software. <VulnDiscussion>If the system log files are not protected, unauthorized users could change the logged data, eliminating its forensic value. Authorized software may be given log file access through the use of extended ACLs when needed and configured to provide the least privileges required.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>true</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1, ECTP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001314 Remove the extended ACL from the file. Procedure: # setfacl --remove-all [file with extended ACL] Verify system log files have no extended ACLs. Procedure: # ls -lL /var/log If the permissions include a '+', the file has an extended ACL. If an extended ACL exists, verify with the SA if the ACL is required to support authorized software and provides the minimum necessary permissions. If an extended ACL exists providing access beyond the needs of authorized software, this is a finding. GEN001290 <GroupDescription></GroupDescription> GEN001290 All manual page files must not have extended ACLs. <VulnDiscussion>If manual pages are compromised, misleading information could be inserted, causing actions to compromise the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all /usr/share/man/* /usr/share/info/* /usr/share/infopage/* Verify all manual page files have no extended ACLs. # ls -lL /usr/share/man /usr/share/info /usr/share/infopage If the permissions include a '+', the file has an extended ACL this is a finding. GEN001310 <GroupDescription></GroupDescription> GEN001310 All library files must not have extended ACLs. <VulnDiscussion>Unauthorized access could destroy the integrity of the library files.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001499 Remove the extended ACL from the file. # setfacl --remove-all /usr/lib/* /lib/* Verify system libraries have no extended ACLs. # ls -lL /usr/lib/* /lib/* | grep "+ " If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and has not been approved by the IAO, this is a finding. GEN001361 <GroupDescription></GroupDescription> GEN001361 NIS/NIS+/yp command files must not have extended ACLs. <VulnDiscussion>NIS/NIS+/yp files are part of the system's identification and authentication processes and are critical to system security. ACLs on these files could result in unauthorized modification, which could compromise these processes and the system. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all /var/yp/* Verify NIS/NIS+/yp files have no extended ACLs. # ls -lL /var/yp/* If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN001362 <GroupDescription></GroupDescription> GEN001362 The /etc/resolv.conf file must be owned by root. <VulnDiscussion>The resolv.conf (or equivalent) file configures the system's DNS resolver. DNS is used to resolve host names to IP addresses. If DNS configuration is modified maliciously, host name resolution may fail or return incorrect information. DNS may be used by a variety of system security functions such as time synchronization, centralized authentication, and remote system logging. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the owner of the /etc/resolv.conf file to root. # chown root /etc/resolv.conf Verify the /etc/resolv.conf file is owned by root. # ls -l /etc/resolv.conf If the file is not owned by root, this is a finding. GEN001363 <GroupDescription></GroupDescription> GEN001363 The /etc/resolv.conf file must be group-owned by root, bin, or sys. <VulnDiscussion>The resolv.conf (or equivalent) file configures the system's DNS resolver. DNS is used to resolve host names to IP addresses. If DNS configuration is modified maliciously, host name resolution may fail or return incorrect information. DNS may be used by a variety of system security functions such as time synchronization, centralized authentication, and remote system logging.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group-owner of the /etc/resolv.conf file to root, bin, or sys. Procedure: # chgrp root /etc/resolv.conf Check the group ownership of the resolv.conf file. Procedure: # ls -lL /etc/resolv.conf If the file is not group-owned by root, bin, or sys, this is a finding. GEN001364 <GroupDescription></GroupDescription> GEN001364 The /etc/resolv.conf file must have mode 0644 or less permissive. <VulnDiscussion>The resolv.conf (or equivalent) file configures the system's DNS resolver. DNS is used to resolve host names to IP addresses. If DNS configuration is modified maliciously, host name resolution may fail or return incorrect information. DNS may be used by a variety of system security functions such as time synchronization, centralized authentication, and remote system logging.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the /etc/resolv.conf file to 0644. # chmod 0644 /etc/resolv.conf Check the mode of the /etc/resolv.conf file. # ls -l /etc/resolv.conf If the file mode is not 0644, this is a finding. GEN001365 <GroupDescription></GroupDescription> GEN001365 The /etc/resolv.conf file must not have an extended ACL. <VulnDiscussion>The resolv.conf (or equivalent) file configures the system's DNS resolver. DNS is used to resolve host names to IP addresses. If DNS configuration is modified maliciously, host name resolution may fail or return incorrect information. DNS may be used by a variety of system security functions such as time synchronization, centralized authentication, and remote system logging.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all /etc/resolv.conf Verify /etc/resolv.conf has no extended ACL. # ls -l /etc/resolv.conf If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN001366 <GroupDescription></GroupDescription> GEN001366 The /etc/hosts file must be owned by root. <VulnDiscussion>The /etc/hosts file (or equivalent) configures local host name to IP address mappings that typically take precedence over DNS resolution. If this file is maliciously modified, it could cause the failure or compromise of security functions requiring name resolution, which may include time synchronization, centralized authentication, and remote system logging.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the owner of the /etc/hosts file to root. # chown root /etc/hosts Verify the /etc/hosts file is owned by root. # ls -l /etc/hosts If the file is not owned by root, this is a finding. GEN001367 <GroupDescription></GroupDescription> GEN001367 The /etc/hosts file must be group-owned by root, bin, or sys. <VulnDiscussion>The /etc/hosts file (or equivalent) configures local host name to IP address mappings that typically take precedence over DNS resolution. If this file is maliciously modified, it could cause the failure or compromise of security functions requiring name resolution, which may include time synchronization, centralized authentication, and remote system logging.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group-owner of the /etc/hosts file to root, sys, or bin. Procedure: # chgrp root /etc/hosts Check the /etc/hosts file's group ownership. Procedure: # ls -lL /etc/hosts If the file is not group-owned by root, bin, or sys, this is a finding. GEN001368 <GroupDescription></GroupDescription> GEN001368 The /etc/hosts file must have mode 0644 or less permissive. <VulnDiscussion>The /etc/hosts file (or equivalent) configures local host name to IP address mappings that typically take precedence over DNS resolution. If this file is maliciously modified, it could cause the failure or compromise of security functions requiring name resolution, which may include time synchronization, centralized authentication, and remote system logging.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the /etc/hosts file to 0644. # chmod 0644 /etc/hosts Check the mode of the /etc/hosts file. # ls -l /etc/hosts If the file mode is not 0644, this is a finding. GEN001369 <GroupDescription></GroupDescription> GEN001369 The /etc/hosts file must not have an extended ACL. <VulnDiscussion>The /etc/hosts file (or equivalent) configures local host name to IP address mappings that typically take precedence over DNS resolution. If this file is maliciously modified, it could cause the failure or compromise of security functions requiring name resolution, which may include time synchronization, centralized authentication, and remote system logging.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all /etc/hosts Verify /etc/hosts has no extended ACL. # ls -l /etc/hosts If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN001371 <GroupDescription></GroupDescription> GEN001371 The /etc/nsswitch.conf file must be owned by root. <VulnDiscussion>The nsswitch.conf file (or equivalent) configures the source of a variety of system security information including account, group, and host lookups. Malicious changes could prevent the system from functioning or compromise system security.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the owner of the /etc/nsswitch.conf file to root. # chown root /etc/nsswitch.conf Verify the /etc/nsswitch.conf file is owned by root. # ls -l /etc/nsswitch.conf If the file is not owned by root, this is a finding. GEN001372 <GroupDescription></GroupDescription> GEN001372 The /etc/nsswitch.conf file must be group-owned by root, bin, or sys. <VulnDiscussion>The nsswitch.conf file (or equivalent) configures the source of a variety of system security information including account, group, and host lookups. Malicious changes could prevent the system from functioning or compromise system security.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group-owner of the /etc/nsswitch.conf file to root, bin or sys. Procedure: # chgrp root /etc/nsswitch.conf Check the group ownership of the nsswitch.conf file. Procedure: # ls -lL /etc/nsswitch.conf If the file is not group-owned by root, bin or sys, this is a finding. GEN001373 <GroupDescription></GroupDescription> GEN001373 The /etc/nsswitch.conf file must have mode 0644 or less permissive. <VulnDiscussion>The nsswitch.conf file (or equivalent) configures the source of a variety of system security information including account, group, and host lookups. Malicious changes could prevent the system from functioning or compromise system security.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the /etc/nsswitch.conf file to 0644 or less permissive. # chmod 0644 /etc/nsswitch.conf Check the mode of the /etc/nsswitch.conf file. # ls -l /etc/nsswitch.conf If the file mode is not 0644, this is a finding. GEN001374 <GroupDescription></GroupDescription> GEN001374 The /etc/nsswitch.conf file must not have an extended ACL. <VulnDiscussion>The nsswitch.conf file (or equivalent) configures the source of a variety of system security information including account, group, and host lookups. Malicious changes could prevent the system from functioning or compromise system security.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all /etc/nsswitch.conf Verify /etc/nsswitch.conf has no extended ACL. # ls -l /etc/nsswitch.conf If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN001375 <GroupDescription></GroupDescription> GEN001375 For systems using DNS resolution, at least two name servers must be configured. <VulnDiscussion>To provide availability for name resolution services, multiple redundant name servers are mandated. A failure in name resolution could lead to the failure of security functions requiring name resolution, which may include time synchronization, centralized authentication, and remote system logging.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001182 Edit /etc/resolv.conf and add additional "nameserver" lines until at least two are present. Determine if DNS is enabled on the system. # grep dns /etc/nsswitch.conf If no line is returned, or any returned line is commented out, the system does not use DNS, and this is not applicable. Determine the name servers used by the system. # grep nameserver /etc/resolv.conf If less than two lines are returned that are not commented out, this is a finding. GEN001378 <GroupDescription></GroupDescription> GEN001378 The /etc/passwd file must be owned by root. <VulnDiscussion>The /etc/passwd file contains the list of local system accounts. It is vital to system security and must be protected from unauthorized modification.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-3958-6 CCI-000225 Change the owner of the /etc/passwd file to root. # chown root /etc/passwd Verify the /etc/passwd file is owned by root. # ls -l /etc/passwd If the file is not owned by root, this is a finding. GEN001379 <GroupDescription></GroupDescription> GEN001379 The /etc/passwd file must be group-owned by root, bin, or sys. <VulnDiscussion>The /etc/passwd file contains the list of local system accounts. It is vital to system security and must be protected from unauthorized modification.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group-owner of the /etc/passwd file to root, bin or sys. Procedure: # chgrp root /etc/passwd Check the group ownership of the passwd file. Procedure: # ls -lL /etc/passwd If the file is not group-owned by root, bin or sys, this is a finding. GEN001390 <GroupDescription></GroupDescription> GEN001390 The /etc/passwd file must not have an extended ACL. <VulnDiscussion>File system ACLs can provide access to files beyond what is allowed by the mode numbers of the files. The /etc/passwd file contains the list of local system accounts. It is vital to system security and must be protected from unauthorized modification.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all /etc/passwd Verify /etc/passwd has no extended ACL. # ls -l /etc/passwd If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN001391 <GroupDescription></GroupDescription> GEN001391 The /etc/group file must be owned by root. <VulnDiscussion>The /etc/group file is critical to system security and must be owned by a privileged user. The group file contains a list of system groups and associated information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-3276-3 CCI-000225 Change the owner of the /etc/group file to root. # chown root /etc/group Verify the /etc/group file is owned by root. # ls -l /etc/group If the file is not owned by root, this is a finding. GEN001392 <GroupDescription></GroupDescription> GEN001392 The /etc/group file must be group-owned by root, bin, or sys. <VulnDiscussion>The /etc/group file is critical to system security and must be protected from unauthorized modification. The group file contains a list of system groups and associated information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-3495-9 CCI-000225 Change the group-owner of the /etc/group file. Procedure: # chgrp root /etc/group Check the group ownership of the /etc/group file. Procedure: # ls -lL /etc/group If the file is not group-owned by root, bin or sys, this is a finding. GEN001393 <GroupDescription></GroupDescription> GEN001393 The /etc/group file must have mode 0644 or less permissive. <VulnDiscussion>The /etc/group file is critical to system security and must be protected from unauthorized modification. The group file contains a list of system groups and associated information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-3967-7 CCI-000225 Change the mode of the /etc/group file to 0644 or less permissive. # chmod 0644 /etc/group Check the mode of the /etc/group file. # ls -l /etc/group If the file mode is more permissive than 0644, this is a finding. GEN001394 <GroupDescription></GroupDescription> GEN001394 The /etc/group file must not have an extended ACL. <VulnDiscussion>The /etc/group file is critical to system security and must be protected from unauthorized modification. The group file contains a list of system groups and associated information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all /etc/group Verify /etc/group has no extended ACL. # ls -l /etc/group If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN001410 <GroupDescription></GroupDescription> GEN001410 The /etc/shadow file (or equivalent) must be group-owned by root, bin, or sys. <VulnDiscussion>The /etc/shadow file contains the list of local system accounts. It is vital to system security and must be protected from unauthorized modification. The file also contains password hashes which must not be accessible to users other than root.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-3988-3 CCI-000225 Change the group-owner of the /etc/shadow file. Procedure: # chgrp root /etc/shadow Check the ownership of the /etc/shadow file. Procedure: # ls -lL /etc/shadow If the file is not group-owned by root, bin, or sys, this is a finding. GEN001430 <GroupDescription></GroupDescription> GEN001430 The /etc/shadow file must not have an extended ACL. <VulnDiscussion>The /etc/shadow file contains the list of local system accounts. It is vital to system security and must be protected from unauthorized modification. The file also contains password hashes which must not be accessible to users other than root.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all /etc/shadow Verify /etc/shadow has no extended ACL. # ls -l /etc/shadow If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN000000-LNX001431 <GroupDescription></GroupDescription> GEN000000-LNX001431 The /etc/gshadow file must be owned by root. <VulnDiscussion>The /etc/gshadow file is critical to system security and must be owned by a privileged user. The /etc/gshadow file contains a list of system groups and hashes for group passwords.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4210-1 CCI-000225 Change the owner of the /etc/gshadow file to root. # chown root /etc/gshadow Check the /etc/gshadow file is owned by root. # ls -l /etc/gshadow If the file is not owned by root, this is a finding. GEN000000-LNX001432 <GroupDescription></GroupDescription> GEN000000-LNX001432 The /etc/gshadow file must be group-owned by root. <VulnDiscussion>The /etc/gshadow file is critical to system security and must be protected from unauthorized modification. The /etc/gshadow file contains a list of system groups and hashes for group passwords.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4064-2 CCI-000225 Change the group-owner of the /etc/gshadow file to root. # chgrp root /etc/gshadow Check the /etc/gshadow file is group-owned by root. # ls -l /etc/gshadow If the file is not group-owned by root, this is a finding. GEN000000-LNX001433 <GroupDescription></GroupDescription> GEN000000-LNX001433 The /etc/gshadow file must have mode 0400. <VulnDiscussion>The /etc/gshadow file is critical to system security and must be protected from unauthorized modification. The /etc/gshadow file contains a list of system groups and hashes for group passwords.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-3932-1 CCI-000225 Change the mode of the /etc/gshadow file to 0400 or less permissive. # chmod 0400 /etc/gshadow Check the mode of the /etc/gshadow file. # ls -l /etc/gshadow If the file mode is more permissive than 0400, this is a finding. GEN000000-LNX001434 <GroupDescription></GroupDescription> GEN000000-LNX001434 The /etc/gshadow file must not have an extended ACL. <VulnDiscussion>The /etc/gshadow file is critical to system security and must be protected from unauthorized modification. The /etc/gshadow file contains a list of system groups and hashes for group passwords.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all /etc/gshadow Check /etc/gshadow has no extended ACL. # ls -l /etc/gshadow If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN001470 <GroupDescription></GroupDescription> GEN001470 The /etc/passwd file must not contain password hashes. <VulnDiscussion>If password hashes are readable by non-administrators, the passwords are subject to attack through lookup tables or cryptographic weaknesses in the hashes.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000201 Migrate /etc/passwd password hashes to /etc/shadow. # pwconv Verify no password hashes are present in /etc/passwd. # cut -d : -f 2 /etc/passwd | egrep -v '^(x|\*)$' If any password hashes are returned, this is a finding. GEN001475 <GroupDescription></GroupDescription> GEN001475 The /etc/group file must not contain any group password hashes. <VulnDiscussion>Group passwords are typically shared and should not be used. Additionally, if password hashes are readable by non-administrators, the passwords are subject to attack through lookup tables or cryptographic weaknesses in the hashes.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Edit /etc/group and change the password field to an exclamation point (!) to lock the group password. Check the /etc/group file for password hashes. # cut -d : -f 2 /etc/group | egrep -v '^(x|!)$' If any password hashes are returned, this is a finding. GEN000000-LNX001476 <GroupDescription></GroupDescription> GEN000000-LNX001476 The /etc/gshadow file must not contain any group password hashes. <VulnDiscussion>Group passwords are typically shared and should not be used.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit /etc/gshadow and change the password field to an exclamation point (!) to lock the group password. Check the /etc/gshadow file for password hashes. # cut -d : -f 2 /etc/gshadow | egrep -v '^(x|!!)$' If any password hashes are returned, this is a finding. GEN001490 <GroupDescription></GroupDescription> GEN001490 User home directories must not have extended ACLs. <VulnDiscussion>Excessive permissions on home directories allow unauthorized access to user files.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all [user home directory with extended ACL] Verify user home directories have no extended ACLs. # cut -d : -f 6 /etc/passwd | xargs -n1 ls -ld If the permissions include a '+', the file has an extended ACL this is a finding. GEN001550 <GroupDescription></GroupDescription> GEN001550 All files and directories contained in user home directories must be group-owned by a group of which the home directory's owner is a member. <VulnDiscussion>If a user's files are group-owned by a group of which the user is not a member, unintended users may be able to access them.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group of a file not group-owned by a group of which the home directory's owner is a member. # chgrp <group with user as member> <file with bad group ownership> Document all changes. Check the contents of user home directories for files group-owned by a group of which the home directory's owner is not a member. 1. List the user accounts. # cut -d : -f 1 /etc/passwd 2. For each user account, get a list of GIDs for files in the user's home directory. # find ~username -printf %G\\n | sort | uniq 3. Obtain the list of GIDs where the user is a member. # id -G username 4. Check the GID lists. If there are GIDs in the file list not present in the user list, this is a finding. GEN001570 <GroupDescription></GroupDescription> GEN001570 All files and directories contained in user home directories must not have extended ACLs. <VulnDiscussion>Excessive permissions allow unauthorized access to user files.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all <user file with extended ACL> Check the contents of user home directories for files with extended ACLs. # cut -d : -f 6 /etc/passwd | xargs -n1 -IDIR ls -alLR DIR If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN001590 <GroupDescription></GroupDescription> GEN001590 All run control scripts must have no extended ACLs. <VulnDiscussion>If the startup files are writable by other users, they could modify the startup files to insert malicious commands into the startup files.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all <run control script with extended ACL> Verify run control scripts have no extended ACLs. # ls -lL /etc/rc* /etc/init.d If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN001605 <GroupDescription></GroupDescription> GEN001605 Run control scripts' library search paths must contain only absolute paths. <VulnDiscussion>The library search path environment variable(s) contain a list of directories for the dynamic linker to search to find libraries. If this path includes the current working directory or other relative paths, libraries in these directories may be loaded instead of system libraries. This variable is formatted as a colon-separated list of directories. If there is an empty entry, such as a leading or trailing colon, or two consecutive colons, this is interpreted as the current working directory. Paths starting with a slash (/) are absolute paths. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit the run control script and remove the relative path entry from the library search path variable. Verify run control scripts' library search paths. # grep -r LD_LIBRARY_PATH /etc/rc* /etc/init.d This variable is formatted as a colon-separated list of directories. If there is an empty entry, such as a leading or trailing colon, or two consecutive colons, this is a finding. If an entry begins with a character other than a slash (/) this is a relative path, this is a finding. GEN001610 <GroupDescription></GroupDescription> GEN001610 Run control scripts' lists of preloaded libraries must contain only absolute paths. <VulnDiscussion>The library preload list environment variable contains a list of libraries for the dynamic linker to load before loading the libraries required by the binary. If this list contains paths to libraries relative to the current working directory, unintended libraries may be preloaded. This variable is formatted as a space-separated list of libraries. Paths starting with a slash (/) are absolute paths.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit the run control script and remove the relative path entry from the library preload variable. Verify run control scripts' library preload list. # grep -r LD_PRELOAD /etc/rc* /etc/init.d This variable is formatted as a colon-separated list of paths. If there is an empty entry, such as a leading or trailing colon, or two consecutive colons, this is a finding. If an entry begins with a character other than a slash (/) this is a relative path, this is a finding. GEN001730 <GroupDescription></GroupDescription> GEN001730 All global initialization files must not have extended ACLs. <VulnDiscussion>Global initialization files are used to configure the user's shell environment upon login. Malicious modification of these files could compromise accounts upon logon.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # ls -l etc/bashrc /etc/csh.cshrc /etc/csh.login /etc/csh.logout /etc/environment /etc/ksh.kshrc /etc/profile /etc/suid_profile /etc/profile.d/* 2>null|grep "\+ "|sed "s/^.* \///g"|xargs setfacl --remove-all Check global initialization files for extended ACLs: # ls -l /etc/bashrc /etc/csh.cshrc /etc/csh.login /etc/csh.logout /etc/environment /etc/ksh.kshrc /etc/profile /etc/suid_profile /etc/profile.d/* 2>null|grep "\+ " If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN001810 <GroupDescription></GroupDescription> GEN001810 Skeleton files must not have extended ACLs. <VulnDiscussion>If the skeleton files are not protected, unauthorized personnel could change user startup parameters and possibly jeopardize user files.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all [skeleton file with extended ACL] or: # ls -lL /etc/skel|grep "\+ "|sed "s/^.* \//|xargs setfacl --remove-all will remove all ACLs from the files. Check skeleton files for extended ACLs: # ls -alL /etc/skel If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN001830 <GroupDescription></GroupDescription> GEN001830 All skeleton files (typically in /etc/skel) must be group-owned by root, bin, sys, system, or other. <VulnDiscussion>If the skeleton files are not protected, unauthorized personnel could change user startup parameters and possibly jeopardize user files.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group-owner of the skeleton file to root, bin, sys, system, or other. Procedure: # chgrp <group> /etc/skel/[skeleton file] or: # ls -L /etc/skel|xargs stat -L -c %G:%n|egrep -v "^(root|bin|sy|sytem|other):"|cut -d: -f2|chgrp root will change the group of all files not already one of the approved group to root. Verify the skeleton files are group-owned by root. Procedure: # ls -alL /etc/skel If a skeleton file is not group-owned by root, bin, sys, system, or other this is a finding. GEN001845 <GroupDescription></GroupDescription> GEN001845 Global initialization files' library search paths must contain only absolute paths. <VulnDiscussion>The library search path environment variable(s) contain a list of directories for the dynamic linker to search to find libraries. If this path includes the current working directory or other relative paths, libraries in these directories may be loaded instead of system libraries. This variable is formatted as a colon-separated list of directories. If there is an empty entry, such as a leading or trailing colon, or two consecutive colons, this is interpreted as the current working directory. Paths starting with a slash (/) are absolute paths.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit the global initialization file and remove the relative path entry from the library search path variable. Check the global initialization files' library search paths. Procedure: # grep LD_LIBRARY_PATH /etc/bashrc /etc/csh.cshrc /etc/csh.login /etc/csh.logout /etc/environment /etc/ksh.kshrc /etc/profile /etc/suid_profile /etc/profile.d/* This variable is formatted as a colon-separated list of directories. If there is an empty entry, such as a leading or trailing colon, or two consecutive colons, this is a finding. If an entry begins with a character other than a slash (/) this is a relative path, this is a finding. GEN001850 <GroupDescription></GroupDescription> GEN001850 Global initialization files' lists of preloaded libraries must contain only absolute paths. <VulnDiscussion>The library preload list environment variable contains a list of libraries for the dynamic linker to load before loading the libraries required by the binary. If this list contains paths to libraries relative to the current working directory, unintended libraries may be preloaded. This variable is formatted as a space-separated list of libraries. Paths starting with a slash (/) are absolute paths.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit the global initialization file and remove the relative path entry from the library preload variable. Check the global initialization files' library preload list. # grep -r LD_PRELOAD /etc/bashrc /etc/csh.cshrc /etc/csh.login /etc/csh.logout /etc/environment /etc/ksh.kshrc /etc/profile /etc/suid_profile /etc/profile.d/* This variable is formatted as a colon-separated list of paths. If there is an empty entry, such as a leading or trailing colon, or two consecutive colons, this is a finding. If an entry begins with a character other than a slash (/) this is a relative path, this is a finding. GEN001870 <GroupDescription></GroupDescription> GEN001870 Local initialization files must be group-owned by the user's primary group or root. <VulnDiscussion>Local initialization files are used to configure the user's shell environment upon login. Malicious modification of these files could compromise accounts upon logon.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group-owner of the local initialization file to the user's primary group, or root. # chgrp <user's primary GID> <user's local initialization file> Procedure: # FILES=".bashrc .bash_login .bash_logout .bash_profile .cshrc .kshrc .login .logout .profile .tcshrc .env .dtprofile .dispatch .emacs .exrc"; # for PWLINE in `cut -d: -f4,6 /etc/passwd`; do HOMEDIR=$(echo ${PWLINE}|cut -d: -f2);GROUP=$(echo ${PWLINE} | cut -d: -f1);for INIFILE in $FILES;do MATCH=$(stat -c %g/%G:%n ${HOMEDIR}/${INIFILE} 2>null|egrep -c -v "${GROUP}");if [ $MATCH != 0 ] ; then chgrp ${GROUP} ${HOMEDIR}/${INIFILE};fi;done;done Check user home directories for local initialization files group-owned by a group other than the user's primary group or root. Procedure: # FILES=" .login .cshrc .logout .profile .bash_profile .bashrc .bash_logout .env .dtprofile .dispatch .emacs .exrc"; # for PWLINE in `cut -d: -f4,6 /etc/passwd`; do HOMEDIR=$(echo ${PWLINE}|cut -d: -f2);GROUP=$(echo ${PWLINE} | cut -d: -f1);for INIFILE in $FILES;do stat -c %g/%G:%n ${HOMEDIR}/${INIFILE} 2>null|egrep -v "${GROUP}";done;done If any file is not group-owned by root or the user's primary GID, this is a finding. GEN001890 <GroupDescription></GroupDescription> GEN001890 Local initialization files must not have extended ACLs. <VulnDiscussion>Local initialization files are used to configure the user's shell environment upon login. Malicious modification of these files could compromise accounts upon logon.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all <local initialization file with extended ACL> Check user home directories for local initialization files with extended ACLs. # cut -d : -f 6 /etc/passwd | xargs -n1 -IDIR ls -alL DIR/.bashrc DIR/.bash_login DIR/.bash_logout DIR/.bash_profile DIR/.cshrc DIR/.kshrc DIR/.login DIR/.logout DIR/.profile DIR/.env DIR/.dtprofile DIR/.dispatch DIR/.emacs DIR/.exrc If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN001901 <GroupDescription></GroupDescription> GEN001901 Local initialization files' library search paths must contain only absolute paths. <VulnDiscussion>The library search path environment variable(s) contain a list of directories for the dynamic linker to search to find libraries. If this path includes the current working directory or other relative paths, libraries in these directories may be loaded instead of system libraries. This variable is formatted as a colon-separated list of directories. If there is an empty entry, such as a leading or trailing colon, or two consecutive colons, this is interpreted as the current working directory. Paths starting with a slash (/) are absolute paths.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit the local initialization file and remove the relative path entry from the library search path variable. Verify local initialization files have library search path containing only absolute paths. Procedure: NOTE: This must be done in the BASH shell. # cut -d: -f6 /etc/passwd |xargs -n1 -IDIR find DIR -name ".*" -type f -maxdepth 1 -exec grep -H LD_LIBRARY_PATH {} \; This variable is formatted as a colon-separated list of directories. If there is an empty entry, such as a leading or trailing colon, or two consecutive colons, this is a finding. If an entry begins with a character other than a slash (/) this is a relative path, this is a finding. GEN001902 <GroupDescription></GroupDescription> GEN001902 Local initialization files' lists of preloaded libraries must contain only absolute paths. <VulnDiscussion>The library preload list environment variable contains a list of libraries for the dynamic linker to load before loading the libraries required by the binary. If this list contains paths to libraries relative to the current working directory, unintended libraries may be preloaded. This variable is formatted as a space-separated list of libraries. Paths starting with a slash (/) are absolute paths.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit the local initialization file and remove the relative path entry from the library preload variable. Verify local initialization files have library preload list containing only absolute paths. NOTE: The following must be done in the BASH shell. Procedure: # cut -d: -f6 /etc/passwd |xargs -n1 -IDIR find DIR -name ".*" -type f -maxdepth 1 -exec grep -H LD_PRELOAD {} \; This variable is formatted as a colon-separated list of paths. If there is an empty entry, such as a leading or trailing colon, or two consecutive colons, this is a finding. If an entry begins with a character other than a slash (/) this is a relative path, this is a finding. GEN002210 <GroupDescription></GroupDescription> GEN002210 All shell files must be group-owned by root, bin, sys, or system. <VulnDiscussion>If shell files are group-owned by users other than root or a system group, they could be modified by intruders or malicious users to perform unauthorized actions.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group-owner of the shell to root, bin, sys, or system. Procedure: # chgrp root <shell> If /etc/shells exists, check the group ownership of each shell referenced. Procedure: # cat /etc/shells | xargs -n1 ls -l Otherwise, check any shells found on the system. Procedure: # find / -name "*sh" | xargs -n1 ls -l If a shell is not group-owned by root, bin, sys, or system, this is a finding. GEN002230 <GroupDescription></GroupDescription> GEN002230 All shell files must not have extended ACLs. <VulnDiscussion>Shells with world/group write permissions give the ability to maliciously modify the shell to obtain unauthorized access.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all [shell] If /etc/shells exists, check the permissions of each shell referenced. # cat /etc/shells | xargs -n1 ls -lL Otherwise, check any shells found on the system. # find / -name "*sh" | xargs -n1 ls -lL If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN002330 <GroupDescription></GroupDescription> GEN002330 Audio devices must not have extended ACLs. <VulnDiscussion>File system ACLs can provide access to files beyond what is allowed by the mode numbers of the files.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all [device file] Check the permissions of audio devices. # ls -lL /dev/audio* /dev/snd/* If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN002430 <GroupDescription></GroupDescription> GEN002430 Removable media, remote file systems, and any file system not containing approved device files must be mounted with the "nodev" option. <VulnDiscussion>The "nodev" (or equivalent) mount option causes the system to not handle device files as system devices. This option must be used for mounting any file system not containing approved device files. Device files can provide direct access to system hardware and can compromise security if not protected.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit /etc/fstab and add the "nodev" option to any filesystems mounted from removable media or network shares. Check /etc/mtab and verify the "nodev" mount option is used on any filesystems mounted from removable media or network shares. If any filesystem mounted from removable media or network shares does not have this option, this is a finding. GEN002710 <GroupDescription></GroupDescription> GEN002710 All system audit files must not have extended ACLs. <VulnDiscussion>If a user can write to the audit logs, then audit trails can be modified or destroyed and system intrusion may not be detected.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECTP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000163 Remove the extended ACL from the system audit file(s). Check the system audit log files for extended ACLs. Procedure: # grep "^log_file" /etc/audit/auditd.conf|sed s/^[^\/]*//|xargs ls -l If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN002715 <GroupDescription></GroupDescription> GEN002715 System audit tool executables must be owned by root. <VulnDiscussion>To prevent unauthorized access or manipulation of system audit logs, the tools for manipulating those logs must be protected.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001493 Change the owner of the audit tool executable to root. # chown root [audit tool executable] Verify the audit tool executables are owned by root. # ls -l /sbin/auditctl /sbin/auditd /sbin/ausearch /sbin/aureport /sbin/autrace /sbin/audispd If any listed file is not owned by root, this is a finding. GEN002716 <GroupDescription></GroupDescription> GEN002716 System audit tool executables must be group-owned by root, bin, sys, or system. <VulnDiscussion>To prevent unauthorized access or manipulation of system audit logs, the tools for manipulating those logs must be protected.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001493 Change the group-owner of the audit tool executable to root, bin, sys, or system. Procedure: # chgrp root <audit tool executable> Verify the audit tool executables are group-owned by root, bin, sys, or system. Procedure: # ls -lL /sbin/auditctl /sbin/auditd /sbin/ausearch /sbin/aureport /sbin/autrace /sbin/audispd If any listed file is not group-owned by root, bin, sys, or system, this is a finding. GEN002717 <GroupDescription></GroupDescription> GEN002717 System audit tool executables must have mode 0750 or less permissive. <VulnDiscussion>To prevent unauthorized access or manipulation of system audit logs, the tools for manipulating those logs must be protected.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001493 Change the mode of the audit tool executable to 0750, or less permissive. # chmod 0750 [audit tool executable] Check the mode of audit tool executables. # ls -l /sbin/auditctl /sbin/auditd /sbin/ausearch /sbin/aureport /sbin/autrace /sbin/audispd If any listed file has a mode more permissive than 0750, this is a finding. GEN002718 <GroupDescription></GroupDescription> GEN002718 System audit tool executables must not have extended ACLs. <VulnDiscussion>To prevent unauthorized access or manipulation of system audit logs, the tools for manipulating those logs must be protected.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001493 Remove the extended ACL from the file. # setfacl --remove-all [audit file] Check the permissions of audit tool executables. # ls -l /sbin/auditctl /sbin/auditd /sbin/ausearch /sbin/aureport /sbin/autrace /sbin/audispd If the permissions include a '+' the file has an extended ACL, this is a finding. GEN002719 <GroupDescription></GroupDescription> GEN002719 The audit system must alert the SA in the event of an audit processing failure. <VulnDiscussion>An accurate and current audit trail is essential for maintaining a record of system activity. If the system fails, the SA must be notified and must take prompt action to correct the problem. Minimally, the system must log this event and the SA will receive this notification during the daily system log review. If feasible, active alerting (such as e-mail or paging) should be employed consistent with the site’s established operations management systems and procedures.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAT-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000139 Edit /etc/audit/auditd.conf and set the disk_full_action and/or disk_error_action parameters to a valid setting of "syslog", "exec", "single" or "halt", adding the parameters if necessary. Verify the /etc/audit/auditd.conf has the disk_full_action and disk_error_action parameters set. Procedure: # grep disk_full_action /etc/audit/auditd.conf If the disk_full_action parameter is missing or set to "suspend" or "ignore" this is a finding. # grep disk_error_action /etc/audit/auditd.conf If the disk_error_action parameter is missing or set to "suspend" or "ignore" this is a finding. GEN002730 <GroupDescription></GroupDescription> GEN002730 The audit system must alert the SA when the audit storage volume approaches its capacity. <VulnDiscussion>An accurate and current audit trail is essential for maintaining a record of system activity. If the system fails, the SA must be notified and must take prompt action to correct the problem. Minimally, the system must log this event and the SA will receive this notification during the daily system log review. If feasible, active alerting (such as e-mail or paging) should be employed consistent with the site’s established operations management systems and procedures.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000143 Edit /etc/audit/auditd.conf and set the space_left_action parameter to a valid setting other than "ignore". If the space_left_action parameter is set to "email" set the action_mail_acct parameter to an e-mail address for the system administrator. Check /etc/audit/auditd.conf for the space_left_action and action_mail_accnt parameters. If the space_left_action or the action_mail_accnt parameters are set to blanks, this is a finding. If the space_left_action is set to "syslog", the system logs the event, this is not a finding. If the space_left_action is set to "exec", the system executes a designated script. If this script informs the SA of the event, this is not a finding. If the space_left_action parameter is missing, this is a finding. If the space_left_action parameter is set to "ignore" or "suspend" no logging would be performed after the event, this is a finding. If the space_left_action parameter is set to "single" or "halt" this effectively stops the system causing a Denial of Service, this is a finding. If the space_left_action is set to "email" and the action_mail_acct parameter is not set to the e-mail address of the system administrator, this is a finding. The action_mail_acct parameter, if missing, defaults to "root". Note that if the email address of the system administrator is on a remote system "sendmail" must be available. GEN002750 <GroupDescription></GroupDescription> GEN002750 The audit system must be configured to audit account creation. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises, and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAT-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000018 Configure execute auditing of the useradd and groupadd executables. Add the following to audit.rules: -w /usr/sbin/useradd -p x -k useradd -w /usr/sbin/groupadd -p x -k groupadd Configure append auditing of the passwd, shadow, group, and gshadow files. Add the following to audit.rules: -w /etc/passwd -p a -k passwd -w /etc/shadow -p a -k shadow -w /etc/group -p a -k group -w /etc/gshadow -p a -k gshadow Restart the auditd service. Determine if execution of the useradd and groupadd executable are audited. # auditctl -l | egrep '(useradd|groupadd)' If either useradd or groupadd are not listed with a permissions filter of at least 'x', this is a finding. Determine if /etc/passwd, /etc/shadow, /etc/group, and /etc/gshadow are audited for appending. # auditctl -l | egrep '(/etc/passwd|/etc/shadow|/etc/group|/etc/gshadow)' If any of these are not listed with a permissions filter of at least 'a', this is a finding. GEN002751 <GroupDescription></GroupDescription> GEN002751 The audit system must be configured to audit account modification. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAT-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001403 Configure execute auditing of the usermod and groupmod executables. Add the following to the audit.rules file: -w /usr/sbin/usermod -p x -k usermod -w /usr/sbin/groupmod -p x -k groupmod Configure append auditing of the passwd, shadow, group, and gshadow files. Add the following to the audit.rules file: -w /etc/passwd -p w -k passwd -w /etc/shadow -p w -k shadow -w /etc/group -p w -k group -w /etc/gshadow -p w -k gshadow Restart the auditd service. Determine if execution of the usermod and groupmod executable are audited. # auditctl -l | egrep '(usermod|groupmod)' If either useradd or groupadd are not listed with a permissions filter of at least 'w', this is a finding. Determine if /etc/passwd, /etc/shadow, /etc/group, and /etc/gshadow are audited for writing. # auditctl -l | egrep '(/etc/passwd|/etc/shadow|/etc/group|/etc/gshadow)' If any of these are not listed with a permissions filter of at least 'w', this is a finding. GEN002752 <GroupDescription></GroupDescription> GEN002752 The audit system must be configured to audit account disabling. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAT-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001404 Configure execute auditing of the passwd executable. Add the following to the audit.rules file: -w /usr/bin/passwd -p x -k passwd Restart the auditd service. Determine if execution of the passwd executable is audited. # auditctl -l | grep /usr/bin/passwd If passwd is not listed with a permissions filter of at least 'x', this is a finding. GEN002753 <GroupDescription></GroupDescription> GEN002753 The audit system must be configured to audit account termination. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAT-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001405 Configure execute auditing of the userdel and groupdel executables. Add the following to the audit.rules file: -w /usr/sbin/userdel -p x -w /usr/sbin/groupdel -p x Restart the auditd service. Determine if execution of the userdel and groupdel executable are audited. # auditctl -l | egrep '(userdel|groupdel)' If either userdel or groupdel are not listed with a permissions filter of at least 'x', this is a finding. GEN002825 <GroupDescription></GroupDescription> GEN002825 The audit system must be configured to audit the loading and unloading of dynamic kernel modules. <VulnDiscussion>Actions concerning dynamic kernel modules must be recorded as they are substantial events. Dynamic kernel modules can increase the attack surface of a system. A malicious kernel module can be used to substantially alter the functioning of a system, often with the purpose of hiding a compromise from the SA.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14688-6 CCI-000126 The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules. On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details. Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately. The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding. Procedure: Configure auditing of the init_module syscalls. Add the following to the "etc/audit/audit.rules" or "etc/audit.rules" file: -a exit,always -S init_module Restart the auditd service. # service auditd restart Determine if the init_module syscall is audited. # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -i "init_module" If the result does not contain "-S init_module", this is a finding. GEN002990 <GroupDescription></GroupDescription> GEN002990 The cron.allow file must not have an extended ACL. <VulnDiscussion>A readable and/or writeable cron.allow file by other users than root could allow potential intruders and malicious users to use the file contents to help discern information, such as who is allowed to execute cron programs, which could be harmful to overall system and network security.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all /etc/cron.allow Check the permissions of the cron.allow file. # ls -l /etc/cron.allow If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN003050 <GroupDescription></GroupDescription> GEN003050 Crontab files must be group-owned by root, cron, or the crontab creator's primary group. <VulnDiscussion>To protect the integrity of scheduled system jobs and prevent malicious modification to these jobs, crontab files must be secured.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group owner of the crontab file to root, cron, or the crontab's primary group. Procedure: # chgrp root [crontab file] Check the group ownership of the crontab files. Procedure: # ls -lL /var/spool/cron # ls -lL /etc/cron.d /etc/crontab /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly or # ls -lL /etc/cron*|grep -v deny If the group owner is not root or the crontab owner's primary group, this is a finding. GEN003090 <GroupDescription></GroupDescription> GEN003090 Crontab files must not have extended ACLs. <VulnDiscussion>To protect the integrity of scheduled system jobs and to prevent malicious modification to these jobs, crontab files must be secured. ACLs on crontab files may provide unauthorized access to the files.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all [crontab file] Check the permissions of the crontab files. Procedure: # ls -lL /var/spool/cron # ls -lL /etc/cron.d /etc/crontab /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly or # ls -lL /etc/cron*|grep -v deny If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN003110 <GroupDescription></GroupDescription> GEN003110 Cron and crontab directories must not have extended ACLs. <VulnDiscussion>To protect the integrity of scheduled system jobs and to prevent malicious modification to these jobs, crontab files must be secured. ACLs on cron and crontab directories may provide unauthorized access to these directories. Unauthorized modifications to these directories or their contents may result in the addition of unauthorized cron jobs or deny service to authorized cron jobs.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the directory. # setfacl --remove-all <crontab directory> Check the permissions of the crontab directories. Procedure: # ls -ld /var/spool/cron # ls -ld /etc/cron.d /etc/crontab /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly or # ls -ld /etc/cron*|grep -v deny If the permissions include a '+' the directory has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN003190 <GroupDescription></GroupDescription> GEN003190 The cron log files must not have extended ACLs. <VulnDiscussion>Cron logs contain reports of scheduled system activities and must be protected from unauthorized access or manipulation.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1, ECTP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all /var/log/cron Check the permissions of the file. Procedure: Check the configured cron log file found in the cron entry in /etc/syslog (normally /var/log/cron). # grep cron /etc/syslog.conf # ls -lL /var/log/cron If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN003210 <GroupDescription></GroupDescription> GEN003210 The cron.deny file must not have an extended ACL. <VulnDiscussion>If there are excessive file permissions for the cron.deny file, sensitive information could be viewed or edited by unauthorized users.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all /etc/cron.deny Check the permissions of the file. # ls -lL /etc/cron.deny If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN003245 <GroupDescription></GroupDescription> GEN003245 The at.allow file must not have an extended ACL. <VulnDiscussion>File system extended ACLs provide access to files beyond what is allowed by the mode numbers of the files. Unauthorized modification of the at.allow file could result in Denial of Service to authorized "at" users and the granting of the ability to run "at" jobs to unauthorized users.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all /etc/at.allow Check the permissions of the file. # ls -lL /etc/at.allow If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN003250 <GroupDescription></GroupDescription> GEN003250 The cron.allow file must be group-owned by root, bin, sys, or cron. <VulnDiscussion>If the group of the cron.allow is not set to root, bin, sys, or cron, the possibility exists for an unauthorized user to view or edit the list of users permitted to use cron. Unauthorized modification of this file could cause Denial of Service to authorized cron users or provide unauthorized users with the ability to run cron jobs.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group ownership of the file. Procedure: # chgrp root /etc/cron.allow Check the group ownership of the file. Procedure: # ls -lL /etc/cron.allow If the file exists and is not group-owned by root, bin, sys or cron, this is a finding. GEN003252 <GroupDescription></GroupDescription> GEN003252 The at.deny file must have mode 0600 or less permissive. <VulnDiscussion>The "at" daemon control files restrict access to scheduled job manipulation and must be protected. Unauthorized modification of the at.deny file could result in Denial of Service to authorized "at" users or provide unauthorized users with the ability to run "at" jobs.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the file. # chmod 0600 /etc/at.deny Check the permissions of the file. # ls -lL /etc/at.deny If the file has a mode more permissive than 0600, this is a finding. GEN003255 <GroupDescription></GroupDescription> GEN003255 The at.deny file must not have an extended ACL. <VulnDiscussion>The "at" daemon control files restrict access to scheduled job manipulation and must be protected. Unauthorized modification of the at.deny file could result in Denial of Service to authorized "at" users or provide unauthorized users with the ability to run "at" jobs.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all /etc/at.deny Check the permissions of the file. # ls -lL /etc/at.deny If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN003270 <GroupDescription></GroupDescription> GEN003270 The cron.deny file must be group-owned by root, bin, or sys. <VulnDiscussion>Cron daemon control files restrict the scheduling of automated tasks and must be protected. Unauthorized modification of the cron.deny file could result in Denial of Service to authorized cron users or could provide unauthorized users with the ability to run cron jobs.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group ownership of the file. # chgrp root /etc/cron.deny Check the group ownership of the file. Procedure: # ls -lL /etc/cron.deny If the file is not group-owned by root, bin, or sys, this is a finding. GEN003410 <GroupDescription></GroupDescription> GEN003410 The "at" directory must not have an extended ACL. <VulnDiscussion>If the "at" directory has an extended ACL, unauthorized users could be allowed to view or to edit files containing sensitive information within the "at" directory. Unauthorized modifications could result in Denial of Service to authorized "at" jobs.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the directory. # setfacl --remove-all /var/spool/at Check the permissions of the directory. # ls -lLd /var/spool/at If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN003430 <GroupDescription></GroupDescription> GEN003430 The "at" directory must be group-owned by root, bin, sys, or cron. <VulnDiscussion>If the group of the "at" directory is not root, bin, sys, or cron, unauthorized users could be allowed to view or edit files containing sensitive information within the directory.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group ownership of the file to root, bin, sys, daemon or cron. Procedure: # chgrp <root or other system group> <"at" directory> Check the group ownership of the file. Procedure: # ls -lL /var/spool/at If the file is not group-owned by root, bin, sys, daemon or cron, this is a finding. GEN003470 <GroupDescription></GroupDescription> GEN003470 The at.allow file must be group-owned by root, bin, sys, or cron. <VulnDiscussion>If the group owner of the at.allow file is not set to root, bin, sys, or cron, unauthorized users could be allowed to view or edit the list of users permitted to run "at" jobs. Unauthorized modification could result in Denial of Service to authorized "at" users or provide unauthorized users with the ability to run "at" jobs.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group ownership of the file. Procedure: # chgrp root /etc/at.allow Check the group ownership of the file. Procedure: # ls -lL /etc/at.allow If the file is not group-owned by root, bin, sys, or cron, this is a finding. GEN003490 <GroupDescription></GroupDescription> GEN003490 The at.deny file must be group-owned by root, bin, sys, or cron. <VulnDiscussion>If the group owner of the at.deny file is not set to root, bin, sys, or cron, unauthorized users could be allowed to view or edit sensitive information contained within the file. Unauthorized modification could result in Denial of Service to authorized "at" users or provide unauthorized users with the ability to run "at" jobs.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group ownership of the at.deny file to root, sys, bin, or cron. Procedure: # chgrp root /etc/at.deny Check the group ownership of the file. Procedure: # ls -lL /etc/at.deny If the file is not group-owned by root, bin, sys, or cron, this is a finding. GEN003510 <GroupDescription></GroupDescription> GEN003510 Kernel core dumps must be disabled unless needed. <VulnDiscussion>Kernel core dumps may contain the full contents of system memory at the time of the crash. Kernel core dumps may consume a considerable amount of disk space and may result in Denial of Service by exhausting the available space on the target file system. The kernel core dump process may increase the amount of time a system is unavailable due to a crash. Kernel core dumps can be useful for kernel debugging.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-3425-6 CCI-000366 Disable kdump. # service kdump stop # chkconfig kdump off Verify the kdump service is not running. Procedure: # service kdump status If "Kdump is operational" is returned, this is a finding. GEN003521 <GroupDescription></GroupDescription> GEN003521 The kernel core dump data directory must be group-owned by root, bin, sys, or system. <VulnDiscussion>Kernel core dumps may contain the full contents of system memory at the time of the crash. As the system memory may contain sensitive information, it must be protected accordingly. If the kernel core dump data directory is not group-owned by a system group, the core dumps contained in the directory may be subject to unauthorized access.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group-owner of the kernel core dump data directory. # chgrp root <kernel core dump data directory> Determine the kernel core dump data directory and check its ownership. Procedure: Examine /etc/kdump.conf. The "path" parameter, which defaults to /var/crash, determines the path relative to the crash dump device. The crash device is specified with a filesystem type and device, such as "ext3 /dev/sda2". Using this information, determine where this path is currently mounted on the system. # ls -ld <kernel dump data directory> If the directory is not group-owned by root, bin, sys, or system, this is a finding. GEN003522 <GroupDescription></GroupDescription> GEN003522 The kernel core dump data directory must have mode 0700 or less permissive. <VulnDiscussion>Kernel core dumps may contain the full contents of system memory at the time of the crash. As the system memory may contain sensitive information, it must be protected accordingly. If the mode of the kernel core dump data directory is more permissive than 0700, unauthorized users may be able to view or to modify kernel core dump data files.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group-owner of the kernel core dump data directory. # chmod 0700 <kernel core dump data directory> Determine the kernel core dump data directory and check its permissions. Procedure: Examine /etc/kdump.conf. The "path" parameter, which defaults to /var/crash, determines the path relative to the crash dump device. The crash device is specified with a filesystem type and device, such as "ext3 /dev/sda2". Using this information, determine where this path is currently mounted on the system. # ls -l <kernel dump directory> If the directory has a mode more permissive than 0700, this is a finding. GEN003523 <GroupDescription></GroupDescription> GEN003523 The kernel core dump data directory must not have an extended ACL. <VulnDiscussion>Kernel core dumps may contain the full contents of system memory at the time of the crash. As the system memory may contain sensitive information, it must be protected accordingly. If there is an extended ACL for the kernel core dump data directory, unauthorized users may be able to view or to modify kernel core dump data files.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all <core file directory> Determine the kernel core dump data directory and check its permissions. Procedure: Examine /etc/kdump.conf. The "path" parameter, which defaults to /var/crash, determines the path relative to the crash dump device. The crash device is specified with a filesystem type and device, such as "ext3 /dev/sda2". Using this information, determine where this path is currently mounted on the system. # ls -l <kernel dump directory> If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN003581 <GroupDescription></GroupDescription> GEN003581 Network interfaces must not be configured to allow user control. <VulnDiscussion>Configuration of network interfaces should be limited to privileged users. Manipulation of network interfaces may result in a Denial of Service or bypass of network security mechanisms.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Edit the configuration for the user-controlled interface and remove the "USERCTL=yes" configuration line or set to "USERCTL=no". Check the system for user-controlled network interfaces. # grep -l '^USERCTL=yes' /etc/sysconfig/network-scripts/ifcfg* If any results are returned, this is a finding. GEN003602 <GroupDescription></GroupDescription> GEN003602 The system must not process Internet Control Message Protocol (ICMP) timestamp requests. <VulnDiscussion>The processing of (ICMP) timestamp requests increases the attack surface of the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001551 Configure the system to not respond to ICMP TIMESTAMP_REQUESTs. This is done by rejecting ICMP type 13 and 14 messages at the firewall. Procedure: Edit /etc/sysconfig/iptables to add: -A RH-Firewall-1-INPUT -p ICMP --icmp-type timestamp-request -j DROP -A RH-Firewall-1-INPUT -p ICMP --icmp-type timestamp-reply -j DROP Restart the firewall: # service iptables restart Verify the system does not respond to ICMP TIMESTAMP_REQUESTs Procedure: # grep "timestamp" /etc/sysconfig/iptables This should return entries for "timestamp-reply" and "timestamp_request". Both should end with "-j DROP'. If either does not exist or does not "DROP" the message, this is a finding. GEN003603 <GroupDescription></GroupDescription> GEN003603 The system must not respond to Internet Control Message Protocol v4 (ICMPv4) echoes sent to a broadcast address. <VulnDiscussion>Responding to broadcast (ICMP) echoes facilitates network mapping and provides a vector for amplification attacks.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-3644-2 CCI-001551 Configure the system to not respond to ICMP ECHO_REQUESTs sent to broadcast addresses. Edit /etc/sysctl.conf and add a setting for "net.ipv4.icmp_echo_ignore_broadcasts=1" and reload the sysctls. Procedure: # echo "net.ipv4.icmp_echo_ignore_broadcasts=1" >> /etc/sysctl.conf # sysctl -p Verify the system does not respond to ICMP ECHO_REQUESTs set to broadcast addresses. Procedure: # cat /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts If the result is not 1, this is a finding. GEN003604 <GroupDescription></GroupDescription> GEN003604 The system must not respond to Internet Control Message Protocol (ICMP) timestamp requests sent to a broadcast address. <VulnDiscussion>The processing of (ICMP) timestamp requests increases the attack surface of the system. Responding to broadcast ICMP timestamp requests facilitates network mapping and provides a vector for amplification attacks.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations>GEN000000-FW</Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl>The system's firewall default-deny policy mitigates the risk from this vulnerability.</MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001551 Configure the system to not respond to ICMP TIMESTAMP_REQUESTs sent to broadcast addresses. Edit /etc/sysctl.conf and add a setting for "net.ipv4.icmp_echo_ignore_broadcasts=1" and reload the sysctls. Procedure: # echo "net.ipv4.icmp_echo_ignore_broadcasts=1" >> /etc/sysctl.conf # sysctl -p Verify the system does not respond to ICMP TIMESTAMP_REQUESTs set to broadcast addresses. Procedure: # cat /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts If the result is not 1, this is a finding. Note: The same parameter controls both ICMP ECHO_REQUESTs and TIMESTAMP_REQUESTs. GEN003607 <GroupDescription></GroupDescription> GEN003607 The system must not accept source-routed IPv4 packets. <VulnDiscussion>Source-routed packets allow the source of the packet to suggest routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the handling of source-routed traffic destined to the system itself, not to traffic forwarded by the system to another system, such as when IPv4 forwarding is enabled and the system is functioning as a router.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001551 Configure the system to not accept source-routed IPv4 packets. Edit /etc/sysctl.conf and add a setting for "net.ipv4.conf.all.accept_source_route=0" and "net.ipv4.conf.default.accept_source_route=0". Reload the sysctls. Procedure: # sysctl -p Verify the system does not accept source-routed IPv4 packets. Procedure: # grep [01] /proc/sys/net/ipv4/conf/*/accept_source_route|egrep "default|all" If all of the resulting lines do not end with "0", this is a finding. GEN003608 <GroupDescription></GroupDescription> GEN003608 Proxy Address Resolution Protocol (Proxy ARP) must not be enabled on the system. <VulnDiscussion>Proxy ARP allows a system to respond to ARP requests on one interface on behalf of hosts connected to another interface. If this function is enabled when not required, addressing information may be leaked between the attached network segments.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001551 Configure the system to not use proxy ARP. Edit /etc/sysctl.conf and add a setting for "net.ipv4.conf.all.proxy_arp=0" and "net.ipv4.conf.default.proxy_arp=0". # sysctl -p Verify the system does not use proxy ARP. # grep [01] /proc/sys/net/ipv4/conf/*/proxy_arp|egrep "default|all" If all of the resulting lines do not end with "0", this is a finding. GEN003609 <GroupDescription></GroupDescription> GEN003609 The system must ignore IPv4 Internet Control Message Protocol (ICMP) redirect messages. <VulnDiscussion>ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4217-6 CCI-001503 CCI-001551 Configure the system to not accept IPv4 ICMP redirect messages. Edit /etc/sysctl.conf and add a setting for "net.ipv4.conf.all.accept_redirects=0" and "net.ipv4.conf.default.accept_redirects=0". # sysctl -p Verify the system does not accept IPv4 ICMP redirect messages. # grep [01] /proc/sys/net/ipv4/conf/*/accept_redirects|egrep "default|all" If all of the resulting lines do not end with "0", this is a finding. GEN003610 <GroupDescription></GroupDescription> GEN003610 The system must not send IPv4 Internet Control Message Protocol (ICMP) redirects. <VulnDiscussion>ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages contain information from the system's route table possibly revealing portions of the network topology.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4155-8 CCI-001551 Configure the system to not send IPv4 ICMP redirect messages. Edit /etc/sysctl.conf and add a setting for "net.ipv4.conf.all.send_redirects=0" and "net.ipv4.conf.default.send_redirects=0". # sysctl -p Verify the system does not send IPv4 ICMP redirect messages. # grep [01] /proc/sys/net/ipv4/conf/*/send_redirects|egrep "default|all" If all of the resulting lines do not end with "0", this is a finding. GEN003611 <GroupDescription></GroupDescription> GEN003611 The system must log martian packets. <VulnDiscussion>Martian packets are packets containing addresses known by the system to be invalid. Logging these messages allows the SA to identify misconfigurations or attacks in progress.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAT-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4320-8 CCI-000126 Configure the system to log martian packets. Edit /etc/sysctl.conf and add a setting for "net.ipv4.conf.all.log_martians=1" and "net.ipv4.conf.default.log_martians=1". Reload the sysctls. Procedure: # sysctl -p Verify the system logs martian packets. # grep [01] /proc/sys/net/ipv4/conf/*/log_martians|egrep "default|all" If all of the resulting lines do not end with "1", this is a finding. GEN003612 <GroupDescription></GroupDescription> GEN003612 The system must be configured to use TCP syncookies when experiencing a TCP SYN flood. <VulnDiscussion>A TCP SYN flood attack can cause Denial of Service by filling a system's TCP connection table with connections in the SYN_RCVD state. Syncookies are a mechanism used to only track a connection when a subsequent ACK is received, verifying the initiator is attempting a valid connection and is not a flood source. This technique does not operate in a fully standards-compliant manner, but is only activated when a flood condition is detected, and allows defense of the system while continuing to service valid requests.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4265-5 CCI-001092 Configure the system to use TCP syncookies when experiencing a TCP SYN flood. Edit /etc/sysctl.conf and add a setting for "net.ipv4.tcp_syncookies=1". # sysctl -p Verify the system configured to use TCP syncookies when experiencing a TCP SYN flood. # cat /proc/sys/net/ipv4/tcp_syncookies If the result is not "1", this is a finding. GEN003619 <GroupDescription></GroupDescription> GEN003619 The system must not be configured for network bridging. <VulnDiscussion>Some systems have the ability to bridge or switch frames (link-layer forwarding) between multiple interfaces. This can be useful in a variety of situations but, if enabled when not needed, has the potential to bypass network partitioning and security.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001551 Configure the system to not use bridging. # rmmod bridge Edit /etc/modprobe.conf and add a line such as "install bridge /bin/false" to prevent the loading of the bridge module. Verify the system is not configured for bridging. # ls /proc/sys/net/bridge If the directory exists, this is a finding. # lsmod | grep '^bridge ' If any results are returned, this is a finding. Fix Text: Configure the system to not use bridging. GEN003650 <GroupDescription></GroupDescription> GEN003650 All local file systems must employ journaling or another mechanism ensuring file system consistency. <VulnDiscussion>File system journaling, or logging, can allow reconstruction of file system data after a system crash preserving the integrity of data that may have otherwise been lost. Journaling file systems typically do not require consistency checks upon booting after a crash, which can improve system availability. Some file systems employ other mechanisms to ensure consistency also satisfying this requirement.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000553 Convert local file systems to use journaling or another mechanism ensuring file system consistency. Verify local filesystems use journaling. # mount | grep '^/dev/' | egrep -v 'type (ext3|ext4|jfs|reiserfs|xfs|iso9660|udf)' If a mount is listed, this is a finding. GEN003730 <GroupDescription></GroupDescription> GEN003730 The inetd.conf file, xinetd.conf file, and the xinetd.d directory must be group-owned by root, bin, sys, or system. <VulnDiscussion>Failure to give ownership of sensitive files or utilities to system groups may provide unauthorized users with the potential to access sensitive information or change the system configuration possibly weakening the system's security posture.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group-owner of the xinetd configuration files and directories. Procedure: # chgrp -R root /etc/xinetd.conf /etc/xinetd.d Check the group ownership of the xinetd configuration files and directories. Procedure: # ls -alL /etc/xinetd.conf /etc/xinetd.d If a file or directory is not group-owned by root, bin, sys, or system, this is a finding. GEN003745 <GroupDescription></GroupDescription> GEN003745 The inetd.conf and xinetd.conf files must not have extended ACLs. <VulnDiscussion>The Internet service daemon configuration files must be protected as malicious modification could cause Denial of Service or increase the attack surface of the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all /etc/xinetd.conf Check the permissions of the xinetd configuration files. Procedure: # ls -alL /etc/xinetd.conf If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN003750 <GroupDescription></GroupDescription> GEN003750 The xinetd.d directory must have mode 0755 or less permissive. <VulnDiscussion>The Internet service daemon configuration files must be protected as malicious modification could cause Denial of Service or increase the attack surface of the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the directory. # chmod 0755 /etc/xinetd.d Check the permissions of the xinetd configuration directories. # ls -dlL /etc/xinetd.d If the mode of the directory is more permissive than 0755, this is a finding. GEN003755 <GroupDescription></GroupDescription> GEN003755 The xinetd.d directory must not have an extended ACL. <VulnDiscussion>The Internet service daemon configuration files must be protected as malicious modification could cause Denial of Service or increase the attack surface of the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all /etc/xinetd.d Check the permissions of the xinetd configuration files and directories. # ls -alL /etc/xinetd.conf /etc/xinetd.d If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN003770 <GroupDescription></GroupDescription> GEN003770 The services file must be group-owned by root, bin, sys, or system. <VulnDiscussion>Failure to give ownership of system configuration files to root or a system group provides the designated owner and unauthorized users with the potential to change the system configuration possibly weakening the system's security posture.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group-owner of the services file. Procedure: # chgrp root /etc/services Check the group ownership of the services file. Procedure: # ls -lL /etc/services If the file is not group-owned by root, bin, sys, or system, this is a finding GEN003790 <GroupDescription></GroupDescription> GEN003790 The services file must not have an extended ACL. <VulnDiscussion>The services file is critical to the proper operation of network services and must be protected from unauthorized modification. If the services file has an extended ACL, it may be possible for unauthorized users to modify the file. Unauthorized modification could result in the failure of network services.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all /etc/services Check the permissions of the /etc/services file. # ls -lL /etc/services If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN003810 <GroupDescription></GroupDescription> GEN003810 The portmap or rpcbind service must not be running unless needed. <VulnDiscussion>The portmap and rpcbind services increase the attack surface of the system and should only be used when needed. The portmap or rpcbind services are used by a variety of services using Remote Procedure Calls (RPCs).</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001436 Shutdown and disable the portmap service. # service portmap stop; chkconfig portmap off Check the status of the portmap service. # service portmap status If the service is running, this is a finding. GEN003815 <GroupDescription></GroupDescription> GEN003815 The portmap or rpcbind service must not be installed unless needed. <VulnDiscussion>The portmap and rpcbind services increase the attack surface of the system and should only be used when needed. The portmap or rpcbind services are used by a variety of services using Remote Procedure Calls (RPCs).</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000305 Remove the portmap package. # rpm -e portmap or # yum remove portmap Check if the portmap package is installed. # rpm -qa | grep portmap If a package is found, this is a finding. GEN003825 <GroupDescription></GroupDescription> GEN003825 The rshd service must not be installed. <VulnDiscussion>The rshd process provides a typically unencrypted, host-authenticated remote access service. SSH should be used in place of this service.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCPP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4308-3 CCI-000305 Remove the rsh-server package. Procedure: # rpm -e rsh-server Check if the rsh-server package is installed. Procedure: # rpm -qa | grep rsh-server If a package is found, this is a finding. GEN003830 <GroupDescription></GroupDescription> GEN003830 The rlogind service must not be running. <VulnDiscussion>The rlogind process provides a typically unencrypted, host-authenticated remote access service. SSH should be used in place of this service.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCPP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-3537-8 CCI-000068 Remove or disable the rlogin configuration and restart xinetd. # rm /etc/xinetd.d/rlogin ; service xinetd restart Check the rlogind configuration. # cat /etc/xinetd.d/rlogin If the file exists and does not contain "disable = yes" this is a finding. GEN003835 <GroupDescription></GroupDescription> GEN003835 The rlogind service must not be installed. <VulnDiscussion>The rlogind process provides a typically unencrypted, host-authenticated remote access service. SSH should be used in place of this service.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCPP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000305 Remove the rsh-server package. Procedure: # rpm -e rsh-server Check if the rsh-server package is installed. Procedure: # rpm -qa | grep rsh-server If a package is found, this is a finding. GEN003845 <GroupDescription></GroupDescription> GEN003845 The rexecd service must not be installed. <VulnDiscussion>The rexecd process provides a typically unencrypted, host-authenticated remote access service. SSH should be used in place of this service.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000305 Remove the rsh-server package. Procedure: # rpm -e rsh-server Check if the rsh-server package is installed. Procedure: # rpm -qa | grep rsh-server If a package is found, this is a finding. GEN003930 <GroupDescription></GroupDescription> GEN003930 The hosts.lpd (or equivalent) file must be group-owned by root, bin, sys, or system. <VulnDiscussion>Failure to give group-ownership of the hosts.lpd file to root, bin, sys, or system provides the members of the owning group and possible unauthorized users, with the potential to modify the hosts.lpd file. Unauthorized modifications could disrupt access to local printers from authorized remote hosts or permit unauthorized remote access to local printers.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group-owner of the printers.conf file. Procedure: # chgrp lp /etc/cups/printers.conf Check the group ownership of the /etc/cups/printers.conf file. Procedure: # ls -lL /etc/cups/printers.conf If the file is not group-owned by lp, this is a finding. GEN003950 <GroupDescription></GroupDescription> GEN003950 The hosts.lpd (or equivalent) file must not have an extended ACL. <VulnDiscussion>Excessive permissions on the hosts.lpd (or equivalent) file may permit unauthorized modification. Unauthorized modifications could disrupt access to local printers from authorized remote hosts or permit unauthorized remote access to local printers.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all /etc/cups/printers.conf Check the permissions of the /etc/cups/printers.conf file. # ls -lL /etc/cups/printers.conf If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN004010 <GroupDescription></GroupDescription> GEN004010 The traceroute file must not have an extended ACL. <VulnDiscussion>If an extended ACL exists on the traceroute executable file, it may provide unauthorized users with access to the file. Malicious code could be inserted by an attacker and triggered whenever the traceroute command is executed by authorized users. Additionally, if an unauthorized user is granted executable permissions to the traceroute command, it could be used to gain information about the network topology behind the firewall. This information may allow an attacker to determine trusted routers and other network information potentially leading to system and network compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all /bin/traceroute Check the permissions of the /bin/traceroute file. # ls -lL /bin/traceroute If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN004370 <GroupDescription></GroupDescription> GEN004370 The aliases file must be group-owned by root, sys, bin, or system. <VulnDiscussion>If the alias file is not group-owned by root or a system group, an unauthorized user may modify the file adding aliases to run malicious code or redirect e-mail.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group-owner of the /etc/aliases file. Procedure: for sendmail: # chgrp root /etc/aliases # chgrp smmsp /etc/aliases.db The aliases.db file must be owned by the same system group as sendmail, which is smmsp by default. for postfix # chgrp root /etc/postfix/aliases # chgrp root /etc/postfix/aliases.db If the "sendmail" and "postfix" packages are not installed, this is not applicable. Check the group ownership of the alias files. Procedure: for sendmail: # ls -lL /etc/aliases If the files are not group-owned by root, this is a finding. # ls -lL /etc/aliases.db If the file is not group-owned by the same system group as sendmail, which is smmsp by default, this is a finding. for postfix: Verify the location of the alias file. # postconf alias maps This will return the location of the "aliases" file, by default "/etc/postfix/aliases" # ls -lL <postfix aliases file> If the files are not group-owned by root, this is a finding. # ls -lL <postfix aliases.db file> If the file is not group-owned by root, this is a finding. GEN004390 <GroupDescription></GroupDescription> GEN004390 The alias file must not have an extended ACL. <VulnDiscussion>Excessive permissions on the aliases file may permit unauthorized modification. If the alias file is modified by an unauthorized user, they may modify the file to run malicious code or redirect e-mail.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended permissions from the alias files. Procedure: for sendmail: # setfacl --remove-all /etc/aliases /etc/aliases.db for postfix (assuming the default postfix directory): # setfacl --remove-all /etc/postfix/aliases /etc/postfix/aliases.db If the "sendmail" and "postfix" packages are not installed, this is not applicable. Check the permissions of the alias file. Procedure: for sendmail: # ls -lL /etc/aliases /etc/aliases.db If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. for postfix: Verify the location of the alias file. # postconf alias maps This will return the location of the "aliases" file, by default "/etc/postfix/aliases" # ls -lL <postfix aliases file> <postfix aliases.db file> If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN004410 <GroupDescription></GroupDescription> GEN004410 Files executed through a mail aliases file must be group-owned by root, bin, sys, or system, and must reside within a directory group-owned by root, bin, sys, or system. <VulnDiscussion>If a file executed through a mail aliases file is not group-owned by root or a system group, it may be subject to unauthorized modification. Unauthorized modification of files executed through aliases may allow unauthorized users to attain root privileges.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group ownership of the file referenced from /etc/aliases. Procedure: # chgrp root <file referenced from aliases> Examine the contents of the /etc/aliases file. Procedure: # more /etc/aliases Examine the aliases file for any utilized directories or paths. # ls -lL <file referenced from aliases> Check the permissions for any paths referenced. If the group owner of any file is not root, bin, sys, or system, this is a finding. GEN004430 <GroupDescription></GroupDescription> GEN004430 Files executed through a mail aliases file must not have extended ACLs. <VulnDiscussion>Excessive permissions on files executed through a mail aliases file could result in modification by an unauthorized user, execution of malicious code, and/or system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all <file referenced from aliases> Examine the contents of the /etc/aliases file. Procedure: # more /etc/aliases Examine the aliases file for any utilized directories or paths. # ls -lL <file referenced from aliases> Check the permissions for any paths referenced. If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN004510 <GroupDescription></GroupDescription> GEN004510 The SMTP service log file must not have an extended ACL. <VulnDiscussion>If the SMTP service log file has an extended ACL, unauthorized users may be allowed to access or to modify the log file.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 This fix is applicable to both Postfix and sendmail servers. Remove the extended ACL from the file. # setfacl --remove-all <log file> Examine /etc/syslog.conf and determine the log file(s) receiving logs for "mail.crit", "mail.debug", mail.*, or "*.crit". Procedure: This check is applicable to both Postfix or sendmail servers. Check the permissions on these log files.Identify any log files configured for "*.crit" and the "mail" service (excluding mail.none) and at any severity level. # egrep "(\*.crit|mail\.[^n][^/]*)" /etc/syslog.conf|sed 's/^[^/]*//'|xargs ls -lL If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN004930 <GroupDescription></GroupDescription> GEN004930 The ftpusers file must be group-owned by root, bin, sys, or system. <VulnDiscussion>If the ftpusers file is not group-owned by root or a system group, an unauthorized user may modify the file to allow unauthorized accounts to use FTP.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group owner of the ftpusers file. Procedure: # chgrp root /etc/ftpusers /etc/vsftpd.ftpusers /etc/vsftpd/ftpusers Check the group ownership of the ftpusers file. Procedure: # ls -lL /etc/ftpusers /etc/vsftpd.ftpusers /etc/vsftpd/ftpusers If the file is not group-owned by root, bin, sys, or system, this is a finding. GEN004950 <GroupDescription></GroupDescription> GEN004950 The ftpusers file must not have an extended ACL. <VulnDiscussion>Excessive permissions on the ftpusers file could permit unauthorized modification. Unauthorized modification could result in Denial of Service to authorized FTP users or permit unauthorized users to access the FTP service.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all /etc/ftpusers /etc/vsftpd.ftpusers /etc/vsftpd/ftpusers Check the permissions of the /etc/ftpusers file. # ls -lL /etc/ftpusers /etc/vsftpd.ftpusers /etc/vsftpd/ftpusers If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN005190 <GroupDescription></GroupDescription> GEN005190 The .Xauthority files must not have extended ACLs. <VulnDiscussion>.Xauthority files ensure the user is authorized to access specific X Windows host. Extended ACLs may permit unauthorized modification of these files, which could lead to Denial of Service to authorized access or allow unauthorized access to be obtained.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all .Xauthority Check the file permissions for the .Xauthority files. These files will be located in user home directories. Procedure: # ls -la ~username |egrep "(\.Xauthority|\.xauth)" If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN005305 <GroupDescription></GroupDescription> GEN005305 The SNMP service must use only SNMPv3 or its successors. <VulnDiscussion>SNMP Versions 1 and 2 are not considered secure. Without the strong authentication and privacy provided by the SNMP Version 3 User-based Security Model (USM), an attacker or other unauthorized users may gain access to detailed system management information and use the information to launch attacks against the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCPP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001435 Edit /etc/snmpd.conf and remove references to the "v1", "v2c", "community", or "com2sec". Restart the SNMP service. # service snmpd restart Check the SNMP daemon is not configured to use the v1 or v2c security models. Procedure: Examine the default install location /etc/snmpd.conf or: # find / -name snmpd.conf # grep -E '(v1|v2c|community|com2sec)' <snmp.conf file> | grep -v '^#' If any configuration is found, this is a finding. GEN005306 <GroupDescription></GroupDescription> GEN005306 The SNMP service must require the use of a FIPS 140-2 approved cryptographic hash algorithm as part of its authentication and integrity methods. <VulnDiscussion>The SNMP service must use SHA-1 or a FIPS 140-2 approved successor for authentication and integrity.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCNR-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001453 Edit /etc/snmp/snmpd.conf and add the SHA keyword for any create user statement without one. Restart the SNMP service. # service snmpd restart Verify the SNMP daemon uses SHA for SNMPv3 users. Procedure: Examine the default install location /etc/snmp/snmpd.conf or: # find / -name snmpd.conf # grep -v '^#' <snmpd.conf file> | grep -i createuser | grep -vi SHA If any line is present this is a finding. GEN005307 <GroupDescription></GroupDescription> GEN005307 The SNMP service must require the use of a FIPS 140-2 approved encryption algorithm for protecting the privacy of SNMP messages. <VulnDiscussion>The SNMP service must use AES or a FIPS 140-2 approved successor algorithm for protecting the privacy of communications.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCNR-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000068 Edit /etc/snmp/snmpd.conf and add the AES keyword for any create user statement without one. Restart the SNMP service. # service snmpd restart Verify the SNMP daemon uses AES for SNMPv3 users. Procedure: Examine the default install location /etc/snmp/snmpd.conf or: # find / -name snmpd.conf # grep -v '^#' <snmpd.conf file> | grep -i createuser | grep -vi AES If any line is present this is a finding. GEN005350 <GroupDescription></GroupDescription> GEN005350 Management Information Base (MIB) files must not have extended ACLs. <VulnDiscussion>The ability to read the MIB file could impart special knowledge to an intruder or malicious user about the ability to extract compromising information about the system or network.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all <mib file> Check the file permissions for the MIB files. # find / -name *.mib # ls -lL <mib file> If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN005365 <GroupDescription></GroupDescription> GEN005365 The snmpd.conf file must be group-owned by root, bin, sys, or system. <VulnDiscussion>The snmpd.conf file contains authenticators and must be protected from unauthorized access and modification. If the file is not group-owned by a system group, it may be subject to access and modification from unauthorized users.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group ownership of the SNMP configuration file. Procedure: # chgrp root <snmpd.conf> Check the group ownership of the SNMP configuration file. Procedure: Examine the default install location /etc/snmp/snmpd.conf or: # find / -name snmpd.conf # ls -lL <snmpd.conf> If the file is not group-owned by root, bin, sys, or system, this is a finding. GEN005375 <GroupDescription></GroupDescription> GEN005375 The snmpd.conf file must not have an extended ACL. <VulnDiscussion>The snmpd.conf file contains authenticators and must be protected from unauthorized access and modification.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all <snmpd.conf file> Check the permissions of the SNMP configuration file. Procedure: Examine the default install location /etc/snmp/snmpd.conf or: # find / -name snmpd.conf # ls -lL <snmpd.conf> If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN005390 <GroupDescription></GroupDescription> GEN005390 The /etc/syslog.conf file must have mode 0640 or less permissive. <VulnDiscussion>Unauthorized users must not be allowed to access or modify the /etc/syslog.conf file.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the permissions of the syslog configuration file. # chmod 0640 /etc/syslog.conf Check the permissions of the syslog configuration file. # ls -lL /etc/syslog.conf If the mode of the file is more permissive than 0640, this is a finding. GEN005395 <GroupDescription></GroupDescription> GEN005395 The /etc/syslog.conf file must not have an extended ACL. <VulnDiscussion>Unauthorized users must not be allowed to access or modify the /etc/syslog.conf file.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all /etc/syslog.conf Check the permissions of the syslog configuration file. # ls -lL /etc/syslog.conf If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN005450 <GroupDescription></GroupDescription> GEN005450 The system must use a remote syslog server (loghost). <VulnDiscussion>A syslog server (loghost) receives syslog messages from one or more systems. This data can be used as an authoritative log source in the event a system is compromised and its local logs are suspect.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAT-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4260-6 CCI-000136 Edit the syslog configuration file and add an appropriate remote syslog server. Check the syslog configuration file for remote syslog servers. # grep '@' /etc/syslog.conf | grep -v '^#' If no line is returned, this is a finding. GEN005501 <GroupDescription></GroupDescription> GEN005501 The SSH client must be configured to only use the SSHv2 protocol. <VulnDiscussion>SSHv1 is not a DoD-approved protocol and has many well-known vulnerability exploits. Exploits of the SSH client could provide access to the system with the privileges of the user running the client.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCPP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001436 Edit the /etc/ssh/ssh_config file and add or edit a "Protocol" configuration line not allowing versions less than 2. Check the SSH client configuration for allowed protocol versions. # grep -i protocol /etc/ssh/ssh_config | grep -v '^#' If the returned protocol configuration allows versions less than 2, this is a finding. GEN005504 <GroupDescription></GroupDescription> GEN005504 The SSH daemon must only listen on management network addresses unless authorized for uses other than management. <VulnDiscussion>The SSH daemon should only listen on network addresses designated for management traffic. If the system has multiple network interfaces and SSH listens on addresses not designated for management traffic, the SSH service could be subject to unauthorized access. If SSH is used for purposes other than management, such as providing an SFTP service, the list of approved listening addresses may be documented.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>true</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000069 Edit the SSH daemon configuration to specify listening network addresses designated for management traffic. Restart the SSH daemon. # /sbin/service sshd restart Ask the SA to identify which interfaces on the system are designated for management traffic. If all interfaces on the system are authorized for management traffic, this is not applicable. Check the SSH daemon configuration for listening network addresses. # grep -i Listen /etc/ssh/sshd_config | grep -v '^#' If no configuration is returned, or if a returned 'Listen' configuration contains addresses not designated for management traffic, this is a finding. GEN005505 <GroupDescription></GroupDescription> GEN005505 The SSH daemon must be configured to only use FIPS 140-2 approved ciphers. <VulnDiscussion>DoD information systems are required to use FIPS 140-2 approved ciphers. SSHv2 ciphers meeting this requirement are 3DES and AES.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCNR-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14491-5 CCI-000068 Edit the SSH daemon configuration and remove any ciphers not starting with "3des" or "aes" and remove any ciphers ending with "cbc". If necessary, add a "Ciphers" line. Ciphers aes256-ctr,aes192-ctr,aes128-ctr Restart the SSH daemon. # /sbin/service sshd restart Check the SSH daemon configuration for allowed ciphers. # grep -i ciphers /etc/ssh/sshd_config | grep -v '^#' If no lines are returned, or the returned ciphers list contains any cipher not starting with "3des" or "aes", this is a finding GEN005506 <GroupDescription></GroupDescription> GEN005506 The SSH daemon must be configured to not use Cipher-Block Chaining (CBC) ciphers. <VulnDiscussion>The Cipher-Block Chaining (CBC) mode of encryption as implemented in the SSHv2 protocol is vulnerable to chosen plain text attacks and must not be used. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit /etc/ssh/sshd_config and add or edit the "Ciphers" line. Only include ciphers that start with "3des" or "aes" and do not contain "cbc". For the list of available ciphers for the particular version of your software, consult the sshd_config manpage. Restart the SSH daemon. Check the SSH daemon configuration for allowed ciphers. # grep -i ciphers /etc/ssh/sshd_config | grep -v '^#' If no lines are returned, or the returned ciphers list contains any cipher ending with cbc, this is a finding. GEN005507 <GroupDescription></GroupDescription> GEN005507 The SSH daemon must be configured to only use Message Authentication Codes (MACs) employing FIPS 140-2 approved cryptographic hash algorithms. <VulnDiscussion>DoD information systems are required to use FIPS 140-2 approved cryptographic hash functions.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCNR-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001453 Edit the SSH daemon configuration and remove any MACs other than "hmac-sha1". If necessary, add a "MACs" line. Restart the SSH daemon. # /sbin/service sshd restart Check the SSH daemon configuration for allowed MACs. Procedure: # grep -i macs /etc/ssh/sshd_config | grep -v '^#' If no lines are returned, or the returned MACs list contains any MAC other than "hmac-sha1", this is a finding. GEN005510 <GroupDescription></GroupDescription> GEN005510 The SSH client must be configured to only use FIPS 140-2 approved ciphers. <VulnDiscussion>DoD information systems are required to use FIPS 140-2 approved ciphers. SSHv2 ciphers meeting this requirement are 3DES and AES.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCNR-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000068 Edit the SSH client configuration and remove any ciphers not starting with "3des" or "aes" and remove any ciphers ending with "cbc". If necessary, add a "Ciphers" line.   Check the SSH client configuration for allowed ciphers. # grep -i ciphers /etc/ssh/ssh_config | grep -v '^#' If no lines are returned, or the returned ciphers list contains any cipher not starting with "3des" or "aes", this is a finding. GEN005511 <GroupDescription></GroupDescription> GEN005511 The SSH client must be configured to not use Cipher-Block Chaining (CBC)-based ciphers. <VulnDiscussion>The (CBC) mode of encryption as implemented in the SSHv2 protocol is vulnerable to chosen-plaintext attacks and must not be used. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit the SSH client configuration and remove any ciphers not starting with "3des" or "aes" and remove any ciphers ending with "cbc". If necessary, add a "Ciphers" line. Check the SSH client configuration for allowed ciphers. # grep -i ciphers /etc/ssh/ssh_config | grep -v '^#' If no lines are returned, or the returned ciphers list contains any cipher ending with "cbc", this is a finding. GEN005512 <GroupDescription></GroupDescription> GEN005512 The SSH client must be configured to only use Message Authentication Codes (MACs) employing FIPS 140-2 approved cryptographic hash algorithms. <VulnDiscussion>DoD information systems are required to use FIPS 140-2 approved cryptographic hash functions.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCNR-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001453 Edit the SSH client configuration and remove any MACs other than "hmac-sha1". If necessary, add a "MACs" line. Check the SSH client configuration for allowed MACs. # grep -i macs /etc/ssh/ssh_config | grep -v '^#' If no lines are returned, or the returned MACs list contains any MAC other than "hmac-sha1", this is a finding. GEN005521 <GroupDescription></GroupDescription> GEN005521 The SSH daemon must restrict login ability to specific users and/or groups. <VulnDiscussion>Restricting SSH logins to a limited group of users, such as system administrators, prevents password-guessing and other SSH attacks from reaching system accounts and other accounts not authorized for SSH access.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Edit the SSH daemon configuration and add an "AllowGroups" or "AllowUsers" directive specifying the groups and users allowed to have access. Restart the SSH daemon. # /sbin/service sshd restart Alternatively, modify the /etc/pam.d/sshd file to include the line account required pam_access.so accessfile=<path to access.conf for sshd> If the "accessfile" option is not specified the default "access.conf" file will be used. The "access.conf" file must contain the user restriction definitions. There are two ways in which access to SSH may restrict users or groups. Check if /etc/pam.d/sshd is configured to require daemon style login control. # grep pam_access.so /etc/pam.d/sshd|grep "required"|grep "account"| grep -v '^#' If no lines are returned, sshd is not configured to use pam_access. Check the SSH daemon configuration for the AllowGroups setting. # egrep -i "AllowGroups|AllowUsers" /etc/ssh/sshd_config | grep -v '^#' If no lines are returned, sshd is not configured to limit access to users/groups. If sshd is not configured to limit access either through pam_access or the use "AllowUsers" or "Allowgroups", this is a finding. GEN005522 <GroupDescription></GroupDescription> GEN005522 The SSH public host key files must have mode 0644 or less permissive. <VulnDiscussion>If a public host key file is modified by an unauthorized user, the SSH service may be compromised.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the permissions for the SSH public host key files. # chmod 0644 /etc/ssh/*key.pub Check the permissions for SSH public host key files. # ls -lL /etc/ssh/*key.pub If any file has a mode more permissive than 0644, this is a finding. GEN005523 <GroupDescription></GroupDescription> GEN005523 The SSH private host key files must have mode 0600 or less permissive. <VulnDiscussion>If an unauthorized user obtains the private SSH host key file, the host could be impersonated.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the permissions for the SSH private host key files. # chmod 0600 /etc/ssh/*key Check the permissions for SSH private host key files. # ls -lL /etc/ssh/*key If any file has a mode more permissive than 0600, this is a finding. GEN005524 <GroupDescription></GroupDescription> GEN005524 The SSH daemon must not permit GSSAPI authentication unless needed. <VulnDiscussion>GSSAPI authentication is used to provide additional authentication mechanisms to applications. Allowing GSSAPI authentication through SSH exposes the system’s GSSAPI to remote hosts, increasing the attack surface of the system. GSSAPI authentication must be disabled unless needed.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit the SSH daemon configuration and set (add if necessary) a "GSSAPIAuthentication" directive set to "no". Restart the SSH daemon. # /sbin/service sshd restart Ask the SA if GSSAPI authentication is used for SSH authentication to the system. If so, this is not applicable. Check the SSH daemon configuration for the GSSAPIAuthentication setting. # grep -i GSSAPIAuthentication /etc/ssh/sshd_config | grep -v '^#' If no lines are returned, or the setting is set to "yes", this is a finding. GEN005525 <GroupDescription></GroupDescription> GEN005525 The SSH client must not permit GSSAPI authentication unless needed. <VulnDiscussion>GSSAPI authentication is used to provide additional authentication mechanisms to applications. Allowing GSSAPI authentication through SSH exposes the system’s GSSAPI to remote hosts, increasing the attack surface of the system. GSSAPI authentication must be disabled unless needed.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit the SSH client configuration and set the GSSAPIAuthentication" directive set to "no".   The default setting for GSSAPIAuthentication is "no" . Check for a change from the default. # grep -i GSSAPIAuthentication /etc/ssh/ssh_config | grep -v '^#' If the setting is "yes" this is a finding. GEN005526 <GroupDescription></GroupDescription> GEN005526 The SSH daemon must not permit Kerberos authentication unless needed. <VulnDiscussion>Kerberos authentication for SSH is often implemented using GSSAPI. If Kerberos is enabled through SSH, the SSH daemon provides a means of access to the system's Kerberos implementation. Vulnerabilities in the system's Kerberos implementation may then be subject to exploitation. To reduce the attack surface of the system, the Kerberos authentication mechanism within SSH must be disabled for systems not using this capability. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit the SSH daemon configuration and set (add if necessary) the "KerberosAuthentication" directive set to "no". Restart the SSH daemon. # /sbin/service sshd restart Ask the SA if Kerberos authentication is used by the system. If it is, this is not applicable. Check the SSH daemon configuration for the KerberosAuthentication setting. # grep -i KerberosAuthentication /etc/ssh/sshd_config | grep -v '^#' If no lines are returned, or the setting is set to "yes", this is a finding. GEN005536 <GroupDescription></GroupDescription> GEN005536 The SSH daemon must perform strict mode checking of home directory configuration files. <VulnDiscussion>If other users have access to modify user-specific SSH configuration files, they may be able to log into the system as another user.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Edit the SSH daemon configuration and add or edit the "StrictModes" setting value to "yes". Restart the SSH daemon. # /sbin/service sshd restart Check the SSH daemon configuration for the StrictModes setting. # grep -i StrictModes /etc/ssh/sshd_config | grep -v '^#' If the setting is not present, or not set to "yes", this is a finding. GEN005537 <GroupDescription></GroupDescription> GEN005537 The SSH daemon must use privilege separation. <VulnDiscussion>SSH daemon privilege separation causes the SSH process to drop root privileges when not needed, which would decrease the impact of software vulnerabilities in the unprivileged section.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Edit the SSH daemon configuration and add or edit the "UsePrivilegeSeparation" setting value to "yes". Restart the SSH daemon. # /sbin/service sshd restart Check the SSH daemon configuration for the UsePrivilegeSeparation setting. # grep -i UsePrivilegeSeparation /etc/ssh/sshd_config | grep -v '^#' If the setting is not present, or not set to "yes", this is a finding. GEN005538 <GroupDescription></GroupDescription> GEN005538 The SSH daemon must not allow rhosts RSA authentication. <VulnDiscussion>If SSH permits rhosts RSA authentication, a user may be able to log in based on the keys of the host originating the request and not any user-specific authentication.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4370-3 CCI-000366 Edit the SSH daemon configuration and add or edit the "RhostsRSAAuthentication" setting value to "no". Restart the SSH daemon. # /sbin/service sshd restart Check the SSH daemon configuration for the RhostsRSAAuthentication setting. # grep -i RhostsRSAAuthentication /etc/ssh/sshd_config | grep -v '^#' If the setting is set to "yes", this is a finding. GEN005539 <GroupDescription></GroupDescription> GEN005539 The SSH daemon must not allow compression or must only allow compression after successful authentication. <VulnDiscussion>If compression is allowed in an SSH connection prior to authentication, vulnerabilities in the compression software could result in compromise of the system from an unauthenticated connection, potentially with root privileges.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit the SSH daemon configuration and add or edit the "Compression" setting value to "no" or "delayed". Restart the SSH daemon. # /sbin/service sshd restart Check the SSH daemon configuration for the compression setting. # grep -i Compression /etc/ssh/sshd_config | egrep "no|delayed" If the setting is missing or is commented out, this is a finding. If the setting is present but is not set to "no" or "delayed", this is a finding. GEN005550 <GroupDescription></GroupDescription> GEN005550 The SSH daemon must be configured with the Department of Defense (DoD) logon banner. <VulnDiscussion>Failure to display the DoD logon banner prior to a logon attempt will negate legal proceedings resulting from unauthorized access to system resources. The SSH service must be configured to display the DoD logon warning banner either through the SSH configuration or a wrapper program such as TCP_WRAPPERS. The SSH daemon may also be used to provide SFTP service. The warning banner configuration for SSH will apply to SFTP.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECWM-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4431-3 CCI-000048 Edit /etc/issue and the DoD login banner. DoD Login Banners: You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests- -not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details. OR I've read & consent to terms in IS user agreem't. Find the location of the banner file for sshd and examine the content: # grep -i banner /etc/ssh/sshd_config | grep -v '^#' # cat Edit the SSH daemon configuration and add or edit a "Banner" setting referencing a file containing a logon warning banner. Restart the SSH daemon. # /sbin/service sshd restart Verify the SSH daemon is configured for logon warning banners. Procedure: An exact match is required to have a valid warning banner. Check for the following login banner. You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details. OR I've read & consent to terms in IS user agreem't. GEN005570 <GroupDescription></GroupDescription> GEN005570 The system must be configured with a default gateway for IPv6 if the system uses IPv6, unless the system is a router. <VulnDiscussion>If a system has no default gateway defined, the system is at increased risk of man-in-the-middle, monitoring, and Denial of Service attacks.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Add a default route for IPv6. Edit /etc/sysconfig/network-scripts/ifcfg-eth0 (substitute interface as appropriate). Add an IPV6_DEFAULTGW=<gateway> configuration setting. Restart the interface. # ifdown eth0; ifup eth0 Check for a default route for IPv6. If the system is a VM host and acts as a router solely for the benefit of its client systems, then this rule is not applicable. # ip -6 route list | grep default If the system uses IPv6, and no results are returned, this is a finding. GEN005610 <GroupDescription></GroupDescription> GEN005610 The system must not have IP forwarding for IPv6 enabled, unless the system is an IPv6 router. <VulnDiscussion>If the system is configured for IP forwarding and is not a designated router, it could be used to bypass network security by providing a path for communication not filtered by network devices.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Disable IPv6 forwarding. Edit /etc/sysctl.conf and add a setting for "net.ipv6.conf.all.forwarding=0" and "net.ipv6.conf.default.forwarding=0". Reload the sysctls. Procedure: # sysctl -p Check if the system is configured for IPv6 forwarding. # grep [01] /proc/sys/net/ipv6/conf/*/forwarding|egrep "default|all" If the /proc/sys/net/ipv6/conf/*/forwarding entries do not exist because of compliance with GEN007720, this is not a finding. If all of the resulting lines do not end with 0, this is a finding. GEN005750 <GroupDescription></GroupDescription> GEN005750 The Network File System (NFS) export configuration file must be group-owned by root, bin, sys, or system. <VulnDiscussion>Failure to give group-ownership of the NFS export configuration file to root or a system group provides the designated group-owner and possible unauthorized users with the potential to change system configuration which could weaken the system's security posture.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group ownership of the NFS export configuration file. Procedure: # chgrp root /etc/exports Check the group ownership of the NFS export configuration file. Procedure: # ls -lL /etc/exports If the file is not group-owned by root, bin, sys, or system, this is a finding. GEN005770 <GroupDescription></GroupDescription> GEN005770 The Network File System (NFS) exports configuration file must not have an extended ACL. <VulnDiscussion>File system extended ACLs provide access to files beyond what is allowed by the mode numbers of the files. Excessive permissions on the NFS export configuration file could allow unauthorized modification of the file, which could result in Denial of Service to authorized NFS exports and the creation of additional unauthorized exports.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all /etc/exports Check the permissions of the NFS export configuration file. # ls -lL /etc/exports If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN005810 <GroupDescription></GroupDescription> GEN005810 All Network File System (NFS) exported system files and system directories must be group-owned by root, bin, sys, or system. <VulnDiscussion>Failure to give group-ownership of sensitive files or directories to root provides the members of the owning group with the potential to access sensitive information or change system configuration which could weaken the system's security posture.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group owner of the export directory. # chgrp root <export> List the exports. # cat /etc/exports For each file system displayed, check the ownership. # ls -ldL <exported file system path> If the directory is not group-owned by root, bin, sys, or system, this is a finding. GEN006150 <GroupDescription></GroupDescription> GEN006150 The /etc/smb.conf file must not have an extended ACL. <VulnDiscussion>Excessive permissions could endanger the security of the Samba configuration file and, ultimately, the system and network.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all /etc/samba/smb.conf Check the permissions of the Samba configuration file. # ls -lL /etc/samba/smb.conf If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN006210 <GroupDescription></GroupDescription> GEN006210 The /etc/smbpasswd file must not have an extended ACL. <VulnDiscussion>If the permissions of the "smbpasswd" file are too permissive, it may be maliciously accessed or modified, potentially resulting in the compromise of Samba accounts.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all /etc/samba/passdb.tdb /etc/samba/secrets.tdb Check the permissions of the Samba password files. Procedure: # ls -lL /etc/samba/passdb.tdb /etc/samba/secrets.tdb If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN006225 <GroupDescription></GroupDescription> GEN006225 Samba must be configured to use an authentication mechanism other than "share." <VulnDiscussion>Samba share authentication does not provide for individual user identification and must not be used.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit the "/etc/samba/smb.conf" file and change the "security" setting to "user" or another valid setting other than "share". Check the security mode of the Samba configuration. # grep -i security /etc/samba/smb.conf If the security mode is "share", this is a finding. GEN006230 <GroupDescription></GroupDescription> GEN006230 Samba must be configured to use encrypted passwords. <VulnDiscussion>Samba must be configured to protect authenticators. If Samba passwords are not encrypted for storage, plain-text user passwords may be read by those with access to the Samba password file.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAIA-1, IAIA-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit the "/etc/samba/smb.conf" file and change the "encrypt passwords" setting to "yes". If the "samba-common" package is not installed, this is not applicable. Check the encryption setting of Samba. # grep -i 'encrypt passwords' /etc/samba/smb.conf If the setting is not present, or not set to 'yes', this is a finding. GEN006235 <GroupDescription></GroupDescription> GEN006235 Samba must be configured to not allow guest access to shares. <VulnDiscussion>Guest access to shares permits anonymous access and is not permitted.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit the "/etc/samba/smb.conf" file and change the "guest ok" setting to "no". Check the access to shares for Samba. # grep -i 'guest ok' /etc/samba/smb.conf If the setting exists and is set to 'yes', this is a finding. GEN006270 <GroupDescription></GroupDescription> GEN006270 The /etc/news/incoming.conf file must not have an extended ACL. <VulnDiscussion>File system extended ACLs provide access to files beyond what is allowed by the mode numbers of the files. Excessive permissions on the "incoming.conf" file may allow unauthorized modification which could lead to Denial of Service to authorized users or provide access to unauthorized users.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all /etc/news/incoming.conf Check the permissions of the file. # ls -lL /etc/news/incoming.conf If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN006290 <GroupDescription></GroupDescription> GEN006290 The /etc/news/hosts.nntp.nolimit file must not have an extended ACL. <VulnDiscussion>File system extended ACLs provide access to files beyond what is allowed by the mode numbers of the files. Excessive permissions on the hosts.nntp.nolimit file may allow unauthorized modification which could lead to Denial of Service to authorized users or provide access to unauthorized users.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all /etc/news/hosts.nntp.nolimit Check the permissions for "/etc/news/hosts.nntp.nolimit". # ls -lL /etc/news/hosts.nntp.nolimit If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN006310 <GroupDescription></GroupDescription> GEN006310 The /etc/news/nnrp.access file must not have an extended ACL. <VulnDiscussion>File system extended ACLs provide access to files beyond what is allowed by the mode numbers of the files. Excessive permissions on the nnrp.access file may allow unauthorized modification which could lead to Denial of Service to authorized users or provide access to unauthorized users.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all /etc/news/nnrp.access Check the permissions of the file. # ls -lL /etc/news/nnrp.access If the permissions include a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN006330 <GroupDescription></GroupDescription> GEN006330 The /etc/news/passwd.nntp file must not have an extended ACL. <VulnDiscussion>Extended ACLs may provide excessive permissions on the /etc/news/passwd.nntp file, which may permit unauthorized access or modification to the NNTP configuration.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all /etc/news/passwd.nntp Check the permissions of the file. # ls -lL /etc/news/passwd.nntp If the mode includes a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN006565 <GroupDescription></GroupDescription> GEN006565 The system package management tool must be used to verify system software periodically. <VulnDiscussion>Verification using the system package management tool can be used to determine that system software has not been tampered with. This requirement is not applicable to systems not using package management tools.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAT-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 CCI-000698 Add a cron job to run an rpm verification command such as: rpm -qVa | awk '$2!="c" {print $0}' For packages which failed verification: If the package is not necessary for operations, remove it from the system. If the package is necessary for operations, re-install the package. Check the root crontab (crontab -l) and the global crontabs in "/etc/crontab", "/etc/cron.*" for the presence of an rpm verification command such as: rpm -qVa | awk '$2!="c" {print $0}' If no such cron job is found, this is a finding. If the result of the cron job indicates packages which do not pass verification exist, this is a finding unless the changes were made due to another STIG entry. GEN006570 <GroupDescription></GroupDescription> GEN006570 The file integrity tool must be configured to verify ACLs. <VulnDiscussion>ACLs can provide permissions beyond those permitted through the file mode and must be verified by file integrity tools.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAT-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001297 If using AIDE, edit the configuration and add the "ACL" option for all monitored files and directories. If using a different file integrity tool, configure ACL checking per the tool's documentation. If using an Advanced Intrusion Detection Environment (AIDE), verify that the configuration contains the "ACL" option for all monitored files and directories. Procedure: Check for the default location /etc/aide/aide.conf or: # find / -name aide.conf # egrep "[+]?acl" <aide.conf file> If the option is not present. This is a finding. If using a different file integrity tool, check the configuration per tool documentation. GEN006571 <GroupDescription></GroupDescription> GEN006571 The file integrity tool must be configured to verify extended attributes. <VulnDiscussion>Extended attributes in file systems are used to contain arbitrary data and file metadata with security implications.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAT-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001297 If using AIDE, edit the configuration and add the "xattrs" option for all monitored files and directories. If using a different file integrity tool, configure extended attributes checking per the tool's documentation. If using an Advanced Intrusion Detection Environment (AIDE), verify the configuration contains the "xattrs" option for all monitored files and directories. Procedure: Check for the default location /etc/aide/aide.conf or: # find / -name aide.conf # egrep "[+]?xattrs" <aide.conf file> If the option is not present. This is a finding. If using a different file integrity tool, check the configuration per tool documentation. GEN006575 <GroupDescription></GroupDescription> GEN006575 The file integrity tool must use FIPS 140-2 approved cryptographic hashes for validating file contents. <VulnDiscussion>File integrity tools often use cryptographic hashes for verifying that file contents have not been altered. These hashes must be FIPS 140-2 approved.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001297 If using AIDE, edit the configuration and add the "sha512" option for all monitored files and directories. If using a different file integrity tool, configure FIPS 140-2 approved cryptographic hashes per the tool's documentation. If using an Advanced Intrusion Detection Environment (AIDE), verify the configuration contains the "sha256" or "sha512" options for all monitored files and directories. Procedure: Check for the default location /etc/aide/aide.conf or: # find / -name aide.conf # egrep "[+]?(sha256|sha512)" <aide.conf file> If the option is not present. This is a finding. If one of these options is not present. This is a finding. If using a different file integrity tool, check the configuration per tool documentation. GEN007020 <GroupDescription></GroupDescription> GEN007020 The Stream Control Transmission Protocol (SCTP) must be disabled unless required. <VulnDiscussion>The Stream Control Transmission Protocol (SCTP) is an Internet Engineering Task Force (IETF)-standardized transport layer protocol. This protocol is not yet widely used. Binding this protocol to the network stack increases the attack surface of the host. Unprivileged local processes may be able to cause the system to dynamically load a protocol handler by opening a socket using the protocol.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14132-5 CCI-000382 Prevent the SCTP protocol handler for dynamic loading. # echo "install sctp /bin/true" >> /etc/modprobe.conf Verify the SCTP protocol handler is prevented from dynamic loading. # grep 'install sctp /bin/true' /etc/modprobe.conf /etc/modprobe.d/* If no result is returned, this is a finding. GEN007080 <GroupDescription></GroupDescription> GEN007080 The Datagram Congestion Control Protocol (DCCP) must be disabled unless required. <VulnDiscussion>The DCCP is a proposed transport layer protocol. This protocol is not yet widely used. Binding this protocol to the network stack increases the attack surface of the host. Unprivileged local processes may be able to cause the system to dynamically load a protocol handler by opening a socket using the protocol.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14268-7 CCI-000382 Prevent the DCCP protocol handler for dynamic loading. # echo "install dccp /bin/true" >> /etc/modprobe.conf # echo "install dccp_ipv4 /bin/true" >> /etc/modprobe.conf # echo "install dccp_ipv6 /bin/true" >> /etc/modprobe.conf Verify the DCCP protocol handler is prevented from dynamic loading. # grep 'install dccp /bin/true' /etc/modprobe.conf /etc/modprobe.d/* If no result is returned, this is a finding. # grep 'install dccp_ipv4 /bin/true' /etc/modprobe.conf /etc/modprobe.d/* If no result is returned, this is a finding. # grep 'install dccp_ipv6 /bin/true' /etc/modprobe.conf /etc/modprobe.d/* If no result is returned, this is a finding. GEN007260 <GroupDescription></GroupDescription> GEN007260 The AppleTalk protocol must be disabled or not installed. <VulnDiscussion>The AppleTalk suite of protocols is no longer in common use. Binding this protocol to the network stack increases the attack surface of the host. Unprivileged local processes may be able to cause the system to dynamically load a protocol handler by opening a socket using the protocol.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000382 Prevent the AppleTalk protocol handler for dynamic loading. # echo "install appletalk /bin/true" >> /etc/modprobe.conf Verify the AppleTalk protocol handler is prevented from dynamic loading. # grep 'install appletalk' /etc/modprobe.conf /etc/modprobe.d/* If anything is returned check that appletalk is disabled by having the executable set to '/bin/true'. If an uncommented line containing "appletalk" is found which has not been disabled, this is a finding. GEN007480 <GroupDescription></GroupDescription> GEN007480 The Reliable Datagram Sockets (RDS) protocol must be disabled or not installed unless required. <VulnDiscussion>The RDS protocol is a relatively new protocol developed by Oracle for communication between the nodes of a cluster. Binding this protocol to the network stack increases the attack surface of the host. Unprivileged local processes may be able to cause the system to dynamically load a protocol handler by opening a socket using the protocol.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14027-7 CCI-000382 Prevent the RDS protocol handler for dynamic loading. # echo "install rds /bin/true" >> /etc/modprobe.conf Ask the SA if RDS is required by application software running on the system. If so, this is not applicable. Verify the RDS protocol handler is prevented from dynamic loading. # grep 'install rds /bin/true' /etc/modprobe.conf /etc/modprobe.d/* If no result is returned, this is a finding. GEN007540 <GroupDescription></GroupDescription> GEN007540 The Transparent Inter-Process Communication (TIPC) protocol must be disabled or uninstalled. <VulnDiscussion>The TIPC protocol is a relatively new cluster communications protocol developed by Ericsson. Binding this protocol to the network stack increases the attack surface of the host. Unprivileged local processes may be able to cause the system to dynamically load a protocol handler by opening a socket using the protocol.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14911-2 CCI-000382 Prevent the TIPC protocol handler for dynamic loading. # echo "install tipc /bin/true" >> /etc/modprobe.conf Verify the TIPC protocol handler is prevented from dynamic loading. # grep 'install tipc /bin/true' /etc/modprobe.conf /etc/modprobe.d/* If no result is returned, this is a finding. GEN007660 <GroupDescription></GroupDescription> GEN007660 The Bluetooth protocol handler must be disabled or not installed. <VulnDiscussion>Bluetooth is a Personal Area Network (PAN) technology. Binding this protocol to the network stack increases the attack surface of the host. Unprivileged local processes may be able to cause the kernel to dynamically load a protocol handler by opening a socket using the protocol.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001551 Prevent the Bluetooth protocol handler for dynamic loading. # echo "install bluetooth /bin/true" >> /etc/modprobe.conf Verify the Bluetooth protocol handler is prevented from dynamic loading. # grep 'install bluetooth /bin/true' /etc/modprobe.conf /etc/modprobe.d/* If no result is returned, this is a finding. GEN007700 <GroupDescription></GroupDescription> GEN007700 The IPv6 protocol handler must not be bound to the network stack unless needed. <VulnDiscussion>IPv6 is the next version of the Internet protocol. Binding this protocol to the network stack increases the attack surface of the host.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001551 Remove the capability to use IPv6 protocol handler. Procedure: Edit /etc/sysconfig/network and change NETWORKING_IPV6=yes to NETWORKING_IPV6=no Edit /etc/modprobe.conf and add these lines (if they are not in it): alias net-pf-10 off alias ipv6 off Stop the ipv6tables service by typing: service ip6tables stop Disable the ipv6tables service by typing: chkconfig ip6tables off Remove the ipv6 kernel module # rmmod ipv6 Reboot If the IPv6 protocol handler is bound to the network stack, and the system does not need IPv6, this is a finding. # grep NETWORKING_IPV6 /etc/sysconfig/network If the line is set to "yes", this is a finding. GEN007720 <GroupDescription></GroupDescription> GEN007720 The IPv6 protocol handler must be prevented from dynamic loading unless needed. <VulnDiscussion>IPv6 is the next generation of the Internet protocol. Binding this protocol to the network stack increases the attack surface of the host. Unprivileged local processes may be able to cause the system to dynamically load a protocol handler by opening a socket using the protocol.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-3562-6 CCI-001551 Prevent the IPv6 protocol handler for dynamic loading. # echo "install ipv6 /bin/true" >> /etc/modprobe.conf If this system uses IPv6, this is not applicable. Verify the IPv6 protocol handler is prevented from dynamic loading. # grep 'install ipv6 /bin/true' /etc/modprobe.conf /etc/modprobe.d/* If no result is returned, this is a finding. GEN007780 <GroupDescription></GroupDescription> GEN007780 The system must not have 6to4 enabled. <VulnDiscussion>6to4 is an IPv6 transition mechanism involving tunneling IPv6 packets encapsulated in IPv4 packets on an ad-hoc basis. This is not a preferred transition strategy and increases the attack surface of the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001551 Disable the active 6to4 tunnel. # ip link set <tunnel> down Add this command to a startup script, or remove the configuration creating the tunnel. Check the system for any active 6to4 tunnels without specific remote addresses. # ip tun list | grep "remote any" | grep "ipv6/ip" If any results are returned the "tunnel" is the first field. If any results are returned, this is a finding. GEN007800 <GroupDescription></GroupDescription> GEN007800 The system must not have Teredo enabled. <VulnDiscussion>Teredo is an IPv6 transition mechanism involving tunneling IPv6 packets encapsulated in IPv4 packets. Unauthorized tunneling may circumvent network security.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001551 Edit startup scripts to prevent the service from running on startup. Verify the Miredo service is not running. # ps ax | grep miredo | grep -v grep If the miredo process is running, this is a finding. GEN007820 <GroupDescription></GroupDescription> GEN007820 The system must not have IP tunnels configured. <VulnDiscussion>IP tunneling mechanisms can be used to bypass network filtering.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001551 Remove the tunnels. # ip tun del <tunnel> Edit system startup scripts to prevent tunnel creation on startup. Check for any IP tunnels. # ip tun list # ip -6 tun list If any tunnels are listed, this is a finding. GEN007840 <GroupDescription></GroupDescription> GEN007840 The DHCP client must be disabled if not needed. <VulnDiscussion>DHCP allows for the unauthenticated configuration of network parameters on the system by exchanging information with a DHCP server.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit the "/etc/sysconfig/network-scripts/ifcfg-*" file(s) and change the "bootproto" setting to "static". Verify no interface is configured to use DHCP. # grep -i bootproto=dhcp /etc/sysconfig/network-scripts/ifcfg-* If any configuration is found, this is a finding. GEN007850 <GroupDescription></GroupDescription> GEN007850 The DHCP client must not send dynamic DNS updates. <VulnDiscussion>Dynamic DNS updates transmit unencrypted information about a system including its name and address and should not be used unless needed.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit or add the "/etc/dhclient.conf" file and add or edit the "do-forward-updates" setting to false. Procedure: # echo "do-forward-updates false;" >> /etc/dhclient.conf If the "dhclient" package is not installed, this is not applicable. Verify the DHCP client is configured to not send dynamic DNS updates. Procedure: # grep do-forward-updates /etc/dhclient.conf If the file is not present, does not contain this configuration, or has the setting set to "true", this is a finding. GEN007860 <GroupDescription></GroupDescription> GEN007860 The system must ignore IPv6 ICMP redirect messages. <VulnDiscussion>ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001551 Configure the system to ignore IPv6 ICMP redirect messages. Edit "/etc/sysctl.conf" and add a settings for "net.ipv6.conf.default.accept_redirects=0" and "net.ipv6.conf.all.accept_redirects=0". Restart the system for the setting to take effect. Verify the system is configured to ignore IPv6 ICMP redirect messages. # cat /proc/sys/net/ipv6/conf/all/accept_redirects If the /proc/sys/net/ipv6/conf/all/accept_redirects entry does not exist because of compliance with GEN007720, this is not a finding. If the returned value is not "0", this is a finding. GEN007920 <GroupDescription></GroupDescription> GEN007920 The system must not forward IPv6 source-routed packets. <VulnDiscussion>Source-routed packets allow the source of the packet to suggest that routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routed traffic, such as when IPv6 forwarding is enabled and the system is functioning as a router. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001551 Configure the system to not forward IPv6 source-routed packets. Procedure: Edit the /etc/sysctl.conf file to include: net.ipv6.conf.all.forwarding = 0 net.ipv6.conf.default.forwarding = 0 Reload the kernel parameters: # sysctl -p Determine if the system is configured to forward IPv6 source-routed packets. Procedure: # egrep "net.ipv6.conf.*forwarding" /etc/sysctl.conf If there are no entries found or the value of the entries is not = "0", this is a finding. GEN007980 <GroupDescription></GroupDescription> GEN007980 If the system is using LDAP for authentication or account information, the system must use a TLS connection using FIPS 140-2 approved cryptographic algorithms. <VulnDiscussion>LDAP can be used to provide user authentication and account information, which are vital to system security. Communication between an LDAP server and a host using LDAP requires protection.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCNR-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001453 Edit "/etc/ldap.conf" and add a "ssl start_tls" and "tls_ciphers" options with only FIPS 140-2 approved ciphers. Check if the system is using NSS LDAP. # grep -v '^#' /etc/nsswitch.conf | grep ldap If no lines are returned, this vulnerability is not applicable. Check if NSS LDAP is using TLS. # grep '^ssl start_tls' /etc/ldap.conf If no lines are returned, this is a finding. Check if NSS LDAP TLS is using only FIPS 140-2 approved cryptographic algorithms. # grep '^tls_ciphers' /etc/ldap.conf If the line is not present, or contains ciphers not approved by FIPS 140-2, this is a finding. FIPS approved ciphers include 3DES and AES. FIPS approved hashes include the SHA hash family. GEN008000 <GroupDescription></GroupDescription> GEN008000 If the system is using LDAP for authentication or account information, certificates used to authenticate to the LDAP server must be provided from DoD PKI or a DoD-approved external PKI. <VulnDiscussion>LDAP can be used to provide user authentication and account information, which are vital to system security. Communication between an LDAP server and a host using LDAP requires authentication.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCNR-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000185 Edit "/etc/ldap.conf" and add or edit the 'tls_cert' setting to reference a file containing a client certificate issued by DoD PKI or a DoD-approved external PKI. Verify the source of the LDAP certificates Check if the system is using NSS LDAP. # grep -v '^#' /etc/nsswitch.conf | grep ldap If no lines are returned, this vulnerability is not applicable. Verify with the SA that the system is connected to the GIG. If the system part of a stand alone network which is not connected to the GIG this vulnerability is not applicable. Verify a certificate is used for client authentication to the server. # grep -i '^tls_cert' /etc/ldap.conf If no line is found, this is a finding. List the certificate issuer. # openssl x509 -text -in <cert> If the certificate is not issued by DoD PKI or a DoD-approved external PKI, this is a finding. GEN008020 <GroupDescription></GroupDescription> GEN008020 If the system is using LDAP for authentication or account information, the LDAP TLS connection must require the server provide a certificate with a valid trust path to a trusted CA. <VulnDiscussion>The NSS LDAP service provides user mappings which are a vital component of system security. Communication between an LDAP server and a host using LDAP for NSS require authentication.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCNR-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000185 Edit "/etc/ldap.conf" and add or set the "tls_checkpeer" setting to "yes". Check if the system is using NSS LDAP. # grep -v '^#' /etc/nsswitch.conf | grep ldap If no lines are returned, this vulnerability is not applicable. Verify a server certificate is required and verified by the NSS LDAP configuration. # grep -i '^tls_checkpeer' /etc/ldap.conf If no line is returned, or the value is not "yes", this is a finding. GEN008040 <GroupDescription></GroupDescription> GEN008040 If the system is using LDAP for authentication or account information, the system must verify the LDAP server's certificate has not been revoked. <VulnDiscussion>LDAP can be used to provide user authentication and account information, which are vital to system security. Communication between an LDAP server and a host using LDAP requires authentication.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCNR-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000185 Edit "/etc/ldap.conf" and add or set the "tls_crlcheck" setting to "all". Check if the system is using NSS LDAP. # grep -v '^#' /etc/nsswitch.conf | grep ldap If no lines are returned, this vulnerability is not applicable. Verify the NSS LDAP client is configured to check certificates against a certificate revocation list. # grep -i '^tls_crlcheck' /etc/ldap.conf If the setting does not exist, or the value is not "all", this is a finding. GEN008060 <GroupDescription></GroupDescription> GEN008060 If the system is using LDAP for authentication or account information the /etc/ldap.conf (or equivalent) file must have mode 0644 or less permissive. <VulnDiscussion>LDAP can be used to provide user authentication and account information, which are vital to system security. The LDAP client configuration must be protected from unauthorized modification.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the permissions of the file. # chmod 0644 /etc/ldap.conf Check the permissions of the file. # ls -lL /etc/ldap.conf If the mode of the file is more permissive than 0644, this is a finding. GEN008080 <GroupDescription></GroupDescription> GEN008080 If the system is using LDAP for authentication or account information, the /etc/ldap.conf (or equivalent) file must be owned by root. <VulnDiscussion>LDAP can be used to provide user authentication and account information, which are vital to system security. The LDAP client configuration must be protected from unauthorized modification.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the owner of the file. # chown root /etc/ldap.conf Check the ownership of the file. # ls -lL /etc/ldap.conf If the file is not owned by root, this is a finding. GEN008100 <GroupDescription></GroupDescription> GEN008100 If the system is using LDAP for authentication or account information, the /etc/ldap.conf (or equivalent) file must be group-owned by root, bin, sys, or system. <VulnDiscussion>LDAP can be used to provide user authentication and account information, which are vital to system security. The LDAP client configuration must be protected from unauthorized modification.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group owner of the file to root, bin, sys, or system. Procedure: # chgrp root /etc/ldap.conf Check the group ownership of the file. Procedure: # ls -lL /etc/ldap.conf If the file is not group-owned by root, bin, sys, or system, this is a finding. GEN008120 <GroupDescription></GroupDescription> GEN008120 If the system is using LDAP for authentication or account information, the /etc/ldap.conf (or equivalent) file must not have an extended ACL. <VulnDiscussion>LDAP can be used to provide user authentication and account information, which are vital to system security. The LDAP client configuration must be protected from unauthorized modification.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the "/etc/ldap.conf" file. # setfacl --remove-all /etc/ldap.conf Check the permissions of the file. # ls -lL /etc/ldap.conf If the mode includes a '+', the file has an extended ACL. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN008140 <GroupDescription></GroupDescription> GEN008140 If the system is using LDAP for authentication or account information, the TLS certificate authority file and/or directory (as appropriate) must be owned by root. <VulnDiscussion>LDAP can be used to provide user authentication and account information, which are vital to system security. The LDAP client configuration must be protected from unauthorized modification.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the ownership of the file or directory. # chown root <certpath> Determine if LDAP is used for account information on the system. # grep -i ldap /etc/nsswitch.conf If no un-commented reference to "ldap" is identified, LDAP is not used for account information on the system and this is not applicable. Determine the certificate authority file and/or directory. # grep -i '^tls_cacert' /etc/ldap.conf For each file or directory returned, check the ownership. # ls -lLd <certpath> If the owner of any file or directory is not root, this is a finding. GEN008160 <GroupDescription></GroupDescription> GEN008160 If the system is using LDAP for authentication or account information, the TLS certificate authority file and/or directory (as appropriate) must be group-owned by root, bin, sys, or system. <VulnDiscussion>LDAP can be used to provide user authentication and account information, which are vital to system security. The LDAP client configuration must be protected from unauthorized modification</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group ownership of the file or directory. # chgrp root <certpath> Determine the certificate authority file and/or directory. # grep -i '^tls_cacert' /etc/ldap.conf For each file or directory returned, check the group ownership. # ls -lLd <certpath> If the group-owner of any file or directory is not root, bin, sys, or system, this is a finding. GEN008180 <GroupDescription></GroupDescription> GEN008180 If the system is using LDAP for authentication or account information, the TLS certificate authority file and/or directory (as appropriate) must have mode 0644 (0755 for directories) or less permissive. <VulnDiscussion>LDAP can be used to provide user authentication and account information, which are vital to system security. The LDAP client configuration must be protected from unauthorized modification.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the file or directory. File Procedure: # chmod 0644 <certpath> Directory Procedure: # chmod 0755 <certpath> Determine the certificate authority file and/or directory. Procedure: # grep -i '^tls_cacert' /etc/ldap.conf For each file or directory returned, check the permissions. Procedure: # ls -lLd <certpath> If the mode of the file is more permissive than 0644 (or 0755 for directories), this is a finding. GEN008200 <GroupDescription></GroupDescription> GEN008200 If the system is using LDAP for authentication or account information, the LDAP TLS certificate authority file and/or directory (as appropriate) must not have an extended ACL. <VulnDiscussion>LDAP can be used to provide user authentication and account information, which are vital to system security. The LDAP client configuration must be protected from unauthorized modification.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the certificate file. Procedure: For each certificate file found remove all extended permissions # setfacl --remove-all <certpath> Determine the certificate authority file and/or directory. # grep -i '^tls_cacert' /etc/ldap.conf For each file or directory returned, check the permissions. # ls -lLd <certpath> If the mode of the file or directory contains a '+', an extended ACL is present. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN008220 <GroupDescription></GroupDescription> GEN008220 For systems using NSS LDAP, the TLS certificate file must be owned by root. <VulnDiscussion>The NSS LDAP service provides user mappings which are a vital component of system security. Its configuration must be protected from unauthorized modification.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the ownership of the file. # chown root <certpath> Determine the certificate file. # grep -i '^tls_cert' /etc/ldap.conf Check the ownership. # ls -lL <certpath> If the owner of the file is not root, this is a finding. GEN008240 <GroupDescription></GroupDescription> GEN008240 If the system is using LDAP for authentication or account information, the LDAP TLS certificate file must be group-owned by root, bin, sys, or system. <VulnDiscussion>LDAP can be used to provide user authentication and account information, which are vital to system security. The LDAP client configuration must be protected from unauthorized modification.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group ownership of the file. Procedure: # chgrp root <certpath> Determine the certificate file. Procedure: # grep -i '^tls_cert' /etc/ldap.conf Check the group ownership. Procedure: # ls -lL <certpath> If the group owner of the file is not root, bin, sys, or system, this is a finding. GEN008260 <GroupDescription></GroupDescription> GEN008260 If the system is using LDAP for authentication or account information, the LDAP TLS certificate file must have mode 0644 or less permissive. <VulnDiscussion>LDAP can be used to provide user authentication and account information, which are vital to system security. The LDAP client configuration must be protected from unauthorized modification.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the file. # chmod 0644 <certpath> Determine the certificate file. # grep -i '^tls_cacert' /etc/ldap.conf Check the permissions. # ls -lL <certpath> If the mode of the file is more permissive than 0644, this is a finding. GEN008280 <GroupDescription></GroupDescription> GEN008280 If the system is using LDAP for authentication or account information, the LDAP TLS certificate file must not have an extended ACL. <VulnDiscussion>LDAP can be used to provide user authentication and account information, which are vital to system security. The LDAP client configuration must be protected from unauthorized modification.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the certificate file. Procedure: For each certificate file found remove all extended permissions. # setfacl --remove-all <certpath> Determine the certificate file. # grep -i '^tls_cert' /etc/ldap.conf Check the permissions. # ls -lL <certpath> If the mode of the file contains a '+', an extended ACL is present. This is a finding. GEN008300 <GroupDescription></GroupDescription> GEN008300 If the system is using LDAP for authentication or account information, the LDAP TLS key file must be owned by root. <VulnDiscussion>LDAP can be used to provide user authentication and account information, which are vital to system security. The LDAP client configuration must be protected from unauthorized modification.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the ownership of the file. # chown root <keypath> Determine the key file. # grep -i '^tls_key' /etc/ldap.conf Check the ownership. # ls -lL <keypath> If the owner of the file is not root, this is a finding. GEN008320 <GroupDescription></GroupDescription> GEN008320 If the system is using LDAP for authentication or account information, the LDAP TLS key file must be group-owned by root, bin, or sys. <VulnDiscussion>LDAP can be used to provide user authentication and account information, which are vital to system security. The LDAP client configuration must be protected from unauthorized modification.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the group ownership of the file. # chgrp root <keypath> Determine the key file. # grep -i '^tls_key' /etc/ldap.conf Check the group ownership. # ls -lL <keypath> If the file is not group owned by root, bin, or sys, this is a finding. GEN008340 <GroupDescription></GroupDescription> GEN008340 If the system is using LDAP for authentication or account information, the LDAP TLS key file must have mode 0600 or less permissive. <VulnDiscussion>LDAP can be used to provide user authentication and account information, which are vital to system security. The LDAP client configuration must be protected from unauthorized modification. Note: Depending on the particular implementation, group and other read permission may be necessary for unprivileged users to successfully resolve account information using LDAP. This will still be a finding, as these permissions provide users with access to system authenticators.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the file. # chmod 0600 <keypath> Determine the key file. # grep -i '^tls_key' /etc/ldap.conf Check the permissions. # ls -lL <keypath> If the mode of the file is more permissive than 0600, this is a finding. GEN008360 <GroupDescription></GroupDescription> GEN008360 If the system is using LDAP for authentication or account information, the LDAP TLS key file must not have an extended ACL. <VulnDiscussion>LDAP can be used to provide user authentication and account information, which are vital to system security. The LDAP client configuration must be protected from unauthorized modification.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the key file. Procedure: For each key file found remove all extended permissions. # setfacl --remove-all <keypath> Determine the key file. # grep -i '^tls_key' /etc/ldap.conf Check the permissions. # ls -lL <keypath> If the permissions of the file contains a '+', an extended ACL is present. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN008380 <GroupDescription></GroupDescription> GEN008380 A root kit check tool must be run on the system at least weekly. <VulnDiscussion>Root kits are software packages designed to conceal the compromise of a system from the SA. Root kit checking tools examine a system for evidence that a root kit is installed. Dedicated root kit detection software or root kit detection capabilities included in anti-virus packages may be used to satisfy this requirement.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCSL-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001199 Create an automated job or establish a site-defined procedure to check the system weekly with a root kit check tool. Ask the SA if a root kit check tool is run on the system weekly. If this is not performed, this is a finding. GEN008420 <GroupDescription></GroupDescription> GEN008420 The system must use available memory address randomization techniques. <VulnDiscussion>Successful exploitation of buffer overflow vulnerabilities relies in some measure to having a predictable address structure of the executing program. Address randomization techniques reduce the probability of a successful exploit.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Edit the kernel boot parameters, or "/etc/sysctl.conf", and set exec-shield to "1". Reboot the system. Verify exec-shield is enabled if present. # cat /proc/sys/kernel/exec-shield If the file is present and contains a value of "0", this is a finding. GEN008440 <GroupDescription></GroupDescription> GEN008440 Automated file system mounting tools must not be enabled unless needed. <VulnDiscussion>Automated file system mounting tools may provide unprivileged users with the ability to access local media and network shares. If this access is not necessary for the system’s operation, it must be disabled to reduce the risk of unauthorized access to these resources.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4072-5 CCI-000366 Stop and disable the autofs service. # service autofs stop # chkconfig autofs off If the autofs service is needed, this vulnerability is not applicable. Check if the autofs service is running. # service autofs status If the service is running, this is a finding. GEN008460 <GroupDescription></GroupDescription> GEN008460 The system must have USB disabled unless needed. <VulnDiscussion>USB is a common computer peripheral interface. USB devices may include storage devices with the potential to install malicious software on a system or exfiltrate data.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>true</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4173-1 CCI-000366 Edit the grub bootloader file "/boot/grub/grub.conf" or "/boot/grub/menu.lst" by appending the "nousb" parameter to the kernel boot line. If the system needs USB, this vulnerability is not applicable. Check if the directory "/proc/bus/usb" exists. If so, this is a finding. GEN008480 <GroupDescription></GroupDescription> GEN008480 The system must have USB Mass Storage disabled unless needed. <VulnDiscussion>USB is a common computer peripheral interface. USB devices may include storage devices with the potential to install malicious software on a system or exfiltrate data</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>true</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Prevent the usb-storage module from loading. # echo 'install usb-storage /bin/true' >> /etc/modprobe.conf If the system needs USB storage, this vulnerability is not applicable. Check if usb-storage is prevented from loading. # grep 'install usb-storage /bin/true' /etc/modprobe.conf /etc/modprobe.d/* If no results are returned, this is a finding. GEN008500 <GroupDescription></GroupDescription> GEN008500 The system must have IEEE 1394 (Firewire) disabled unless needed. <VulnDiscussion>Firewire is a common computer peripheral interface. Firewire devices may include storage devices with the potential to install malicious software on a system or exfiltrate data.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>true</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Prevent the system from loading the firewire module. # echo 'install ieee1394 /bin/true' >> /etc/modprobe.conf If the system needs IEEE 1394 (Firewire), this is not applicable. Check if the firewire module is not disabled. # grep 'install ieee1394 /bin/true' /etc/modprobe.conf /etc/modprobe.d/* If no results are returned, this is a finding. GEN008520 <GroupDescription></GroupDescription> GEN008520 The system must employ a local firewall. <VulnDiscussion>A local firewall protects the system from exposing unnecessary or undocumented network services to the local enclave. If a system within the enclave is compromised, firewall protection on an individual system continues to protect it from attack.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4189-7 CCI-001118 Enable the system's local firewall. # chkconfig iptables on # service iptables start Determine if the system is using a local firewall. # chkconfig --list iptables If the service is not "on" in the standard runlevel (ordinarily 3 or 5), this is a finding. GEN008540 <GroupDescription></GroupDescription> GEN008540 The system's local firewall must implement a deny-all, allow-by-exception policy. <VulnDiscussion>A local firewall protects the system from exposing unnecessary or undocumented network services to the local enclave. If a system within the enclave is compromised, firewall protection on an individual system continues to protect it from attack.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14264-6 CCI-001109 Edit "/etc/sysconfig/iptables" and add a default deny rule. An example of a default deny rule: -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited Restart the iptable service. # service iptables restart Check the firewall rules for a default deny rule. # iptables --list Example of a rule meeting this criteria: REJECT all -- anywhere anywhere reject-with icmp-host-prohibited A rule using DROP is also acceptable. The default rule should be the last rule of a table and match all traffic. If there is no default deny rule, this is a finding. GEN000000-LNX00800 <GroupDescription></GroupDescription> GEN000000-LNX00800 The system must use a Linux Security Module configured to limit the privileges of system services. <VulnDiscussion>Linux Security Modules such as SELinux and AppArmor can be used to provide protection from software exploits by explicitly defining the privileges permitted to each software package.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-3977-6 CCI-000366 Enable one of the SELinux policies. Edit /etc/sysconfig/selinux and set the value of the SELINUX option to "enforcing" and SELINUXTYPE to "targeted" or "strict". Restart the system. Check if SELinux is enabled with at least a "targeted" policy. # grep ^SELINUX /etc/sysconfig/selinux If the SELINUX option is not set to "enforcing", this is a finding. If the SELINUXTYPE option is not set to "targeted" or "strict", this is a finding. If the use of the system is incompatible with the confines of SELinux this rule may be waived. GEN008740 <GroupDescription></GroupDescription> GEN008740 The system's boot loader configuration file(s) must not have extended ACLs. <VulnDiscussion>File system extended ACLs provide access to files beyond what is allowed by the mode numbers of the files. If extended ACLs are present on the system's boot loader configuration file(s), these files may be vulnerable to unauthorized access or modification, which could compromise the system's boot process.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all /etc/grub.conf Check the permissions of the file. # ls -lL /boot/grub/grub.conf If the permissions of the file or directory contains a '+', an extended ACL is present. This is a finding. GEN008760 <GroupDescription></GroupDescription> GEN008760 The system's boot loader configuration files must be owned by root. <VulnDiscussion>The system's boot loader configuration files are critical to the integrity of the system and must be protected. Unauthorized modification of these files resulting from improper ownership could compromise the system's boot loader configuration.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4144-2 CCI-000225 Change the ownership of the file. # chown root /boot/grub/grub.conf Check the ownership of the file. # ls -lLd /boot/grub/grub.conf If the owner of the file is not root, this is a finding. GEN008780 <GroupDescription></GroupDescription> GEN008780 The system's boot loader configuration file(s) must be group-owned by root, bin, sys, or system. <VulnDiscussion>The system's boot loader configuration files are critical to the integrity of the system and must be protected. Unauthorized modifications resulting from improper group ownership may compromise the boot loader configuration.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4197-0 CCI-000225 Change the group ownership of the file. # chgrp root /boot/grub/grub.conf Check the group ownership of the file. # ls -lLd /boot/grub/grub.conf If the group-owner of the file is not root, bin, sys, or system this is a finding. GEN008800 <GroupDescription></GroupDescription> GEN008800 The system package management tool must cryptographically verify the authenticity of software packages during installation. <VulnDiscussion>To prevent the installation of software from unauthorized sources, the system package management tool must use cryptographic algorithms to verify the packages are authentic.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14914-6 CCI-000351 Edit the RPM configuration file containing the "nosignature" option and remove the option. Edit the YUM configuration containing "gpgcheck=0" and set the value to "1". Verify RPM signature validation is not disabled. # grep nosignature /etc/rpmrc /usr/lib/rpm/rpmrc /usr/lib/rpm/redhat/rpmrc ~root/.rpmrc If any configuration is found, this is a finding. Verify YUM signature validation is not disabled. # grep gpgcheck /etc/yum.conf /etc/yum.repos.d/* If any "gpgcheck" setting is returned that is not equal to "1", this is a finding. GEN008820 <GroupDescription></GroupDescription> GEN008820 The system package management tool must not automatically obtain updates. <VulnDiscussion>System package management tools can obtain a list of updates and patches from a package repository and make this information available to the SA for review and action. Using a package repository outside of the organization's control presents a risk of malicious packages being introduced.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001233 Disable the yum service. # chkconfig yum-updatesd off ; service yum-updatesd stop Verify the YUM service is enabled. # service yum-updatesd status If the service is enabled, this is a finding. GEN000000-LNX00450 <GroupDescription></GroupDescription> GEN000000-LNX00450 The access.conf file must not have an extended ACL. <VulnDiscussion>If the access permissions are more permissive than 0640, system security could be compromised.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 CCI-000366 Remove the extended ACL from the file. # setfacl --remove-all /etc/security/access.conf Check the permissions of the file. # ls -lL /etc/security/access.conf If the permissions of the file or directory contain a '+', an extended ACL is present. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN000000-LNX00530 <GroupDescription></GroupDescription> GEN000000-LNX00530 The /etc/sysctl.conf file must not have an extended ACL. <VulnDiscussion>The sysctl.conf file specifies the values for kernel parameters to be set on boot. These settings can affect the system's security.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Remove the extended ACL from the file. # setfacl --remove-all /etc/sysctl.conf Check the permissions of the file. # ls -lL /etc/sysctl.conf If the permissions of the file or directory contain a '+', an extended ACL is present. If the file has an extended ACL and it has not been documented with the IAO, this is a finding. GEN000000-LNX00720 <GroupDescription></GroupDescription> GEN000000-LNX00720 Auditing must be enabled at boot by setting a kernel parameter. <VulnDiscussion>If auditing is enabled late in the boot process, the actions of startup scripts may not be audited. Some audit systems also maintain state information only available if auditing is enabled before a given process is created.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-15026-8 CCI-000366 Edit the grub bootloader file /boot/grub/grub.conf or /boot/grub/menu.lst by appending the "audit=1" parameter to the kernel boot line. Reboot the system for the change to take effect. Check for the audit=1 kernel parameter. # grep 'audit=1' /proc/cmdline If no results are returned, this is a finding. GEN005590 <GroupDescription></GroupDescription> GEN005590 The system must not be running any routing protocol daemons, unless the system is a router. <VulnDiscussion>Routing protocol daemons are typically used on routers to exchange network topology information with other routers. If this software is used when not required, system network information may be unnecessarily transmitted across the network.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Disable any routing protocol daemons. Check for any running routing protocol daemons. If the system is a VM host and acts as a router solely for the benefits of its client systems, then this rule is not applicable. # chkconfig --list |grep :on|egrep '(ospf|route|bgp|zebra|quagga)' If any routing protocol daemons are listed, this is a finding. GEN002690 <GroupDescription></GroupDescription> GEN002690 System audit logs must be group-owned by root, bin, sys, or system. <VulnDiscussion>Sensitive system and user information could provide a malicious user with enough information to penetrate further into the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1, ECTP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000162 CCI-000163 Change the group ownership of the audit log file(s). Procedure: # chgrp root <audit log file> Check the group ownership of the audit logs. Procedure: # grep "^log_file" /etc/audit/auditd.conf|sed s/^[^\/]*//|xargs stat -c %G:%n If any audit log file is not group-owned by root, bin, sys, or system, this is a finding. GEN000410 <GroupDescription></GroupDescription> GEN000410 The FTPS/FTP service on the system must be configured with the Department of Defense (DoD) login banner. <VulnDiscussion>Failure to display the logon banner prior to a logon attempt will negate legal proceedings resulting from unauthorized access to system resources. Note: SFTP and FTPS are encrypted alternatives to FTP to be used in place of FTP. SFTP is implemented by the SSH service and uses its banner configuration.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECWM-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4554-2 CCI-000048 Provide the proper text for the DoD banner to be presented by the FTP server to the user. For vsftp: Examine the /etc/vsftp.conf file for the "banner_file" entry. (i.e. banner_file = /etc/banner/vsftp) For gssftp: Examine the /etc/xinetd.d/gssftp file for the "banner" entry. (i.e. banner = /etc/banner/gssftp) For both: Add the banner entry if one is not found. Modify or create the referenced banner file to contain one of the following DoD login banners (based on the character limitations imposed by the system). DoD Login Banners: You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details. OR I've read & consent to terms in IS user agreem't. FTP to the system. # ftp localhost Check for either of the following login banners based on the character limitations imposed by the system. An exact match is required. If one of these banners is not displayed, this is a finding. If the system does not run the FTP service, this is not applicable. DoD Login Banners: You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details. OR I've read & consent to terms in IS user agreem't. GEN003621 <GroupDescription></GroupDescription> GEN003621 The system must use a separate file system for /var. <VulnDiscussion>The use of separate file systems for different paths can protect the system from failures resulting from a file system becoming full or failing.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001208 Migrate the /var path onto a separate file system. Determine if the /var path is a separate filesystem. # grep /var /etc/fstab If no result is returned, /var is not on a separate filesystem this is a finding. GEN003623 <GroupDescription></GroupDescription> GEN003623 The system must use a separate file system for the system audit data path. <VulnDiscussion>The use of separate file systems for different paths can protect the system from failures resulting from a file system becoming full or failing.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001208 Migrate the /var/log/audit path onto a separate filesystem. Determine if the /var/log/audit path is a separate filesystem. # grep /var/log/audit /etc/fstab If no result is returned, /var/log/audit is not on a separate filesystem this is a finding. GEN003624 <GroupDescription></GroupDescription> GEN003624 The system must use a separate file system for /tmp (or equivalent). <VulnDiscussion>The use of separate file systems for different paths can protect the system from failures resulting from a file system becoming full or failing.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001208 Migrate the /tmp path onto a separate file system. Determine if the /tmp path is a separate filesystem. # egrep "[\t ]/tmp[\t ]" /etc/fstab If no result is returned, /tmp is not on a separate filesystem this is a finding. GEN003601 <GroupDescription></GroupDescription> GEN003601 TCP backlog queue sizes must be set appropriately. <VulnDiscussion>To provide some mitigation to TCP Denial of Service attacks, the TCP backlog queue sizes must be set to at least 1280 or in accordance with product-specific guidelines.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 Edit /etc/sysctl.conf and add a setting for "net.ipv4.tcp_max_syn_backlog=1280". Procedure: # sysctl -p # cat /proc/sys/net/ipv4/tcp_max_syn_backlog If the result is not 1280 or greater, this is a finding. GEN004710 <GroupDescription></GroupDescription> GEN004710 Mail relaying must be restricted. <VulnDiscussion>If unrestricted mail relaying is permitted, unauthorized senders could use this host as a mail relay for the purpose of sending SPAM or other unauthorized activity.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-001305 If the system uses sendmail, edit the sendmail.mc file and remove the "promiscuous_relay" configuration. Rebuild the sendmail.cf file from the modified sendmail.mc and restart the service. If the system does not need to receive mail from external hosts, add one or more DaemonPortOptions lines referencing system loopback addresses (such as "O DaemonPortOptions=Addr=127.0.0.1,Port=smtp,Name=MTA") and remove lines containing non-loopback addresses. Restart the service. If the system uses Postfix, edit the main.cf file and add or edit the "smtpd_client_restrictions" line to have contents "permit_mynetworks, reject" or a similarly restrictive rule. If the system does not need to receive mail from external hosts, add or edit the "inet_interfaces" line to have contents "loopback-only" or a set of loopback addresses for the system. Restart the service. If the system is using other SMTP software, consult the software's documentation for procedures to restrict mail relaying. If the system uses sendmail examine the configuration files. Determine if sendmail only binds to loopback addresses by examining the "DaemonPortOptions" configuration options. Procedure: # grep -i "O DaemonPortOptions" /etc/mail/sendmail.cf If there are uncommented DaemonPortOptions lines, and all such lines specify system loopback addresses, this is not a finding. Otherwise, determine if sendmail is configured to allow open relay operation. Procedure: # grep -i promiscuous_relay /etc/mail/sendmail.mc If the promiscuous relay feature is enabled, this is a finding. If the system uses Postfix, locate the main.cf file. Procedure: # find / -name main.cf Determine if Postfix only binds to loopback addresses by examining the "inet_interfaces" line. Procedure: # grep inet_interfaces </path/to/main.cf> If "inet_interfaces" is set to "loopback-only" or contains only loopback addresses such as 127.0.0.1 and [::1], Postfix is not listening on external network interfaces, and this is not a finding. Otherwise, determine if Postfix is configured to restrict clients permitted to relay mail by examining the "smtpd_client_restrictions" line. Procedure: # grep smtpd_client_restrictions </path/to/main.cf> If the "smtpd_client_restrictions" line is missing, or does not contain "reject", this is a finding. If the line contains "permit" before "reject", this is a finding. If the system is using other SMTP software, consult the software's documentation for procedures to verify mail relaying is restricted. GEN007960 <GroupDescription></GroupDescription> GEN007960 The 'ldd' command must be disabled unless it protects against the execution of untrusted files. <VulnDiscussion>The 'ldd' command provides a list of dependent libraries needed by a given binary, which is useful for troubleshooting software. Instead of parsing the binary file, some 'ldd' implementations invoke the program with a special environment variable set, which causes the system dynamic linker to display the list of libraries. Specially crafted binaries can specify an alternate dynamic linker which may cause a program to be executed instead of examined. If the program is from an untrusted source, such as in a user home directory, or a file suspected of involvement in a system compromise, unauthorized software may be executed with the rights of the user running 'ldd'. Some 'ldd' implementations include protections that prevent the execution of untrusted files. Recent RHEL 5 glibc RPMs also protect against the execution of untrusted files. If such protections exist, this requirement is not applicable. An acceptable method of disabling 'ldd' is changing its mode to 0000. The SA may conduct troubleshooting by temporarily changing the mode to allow execution and running the 'ldd' command as an unprivileged user upon trusted system binaries.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000305 Remove the execute permissions from the 'ldd' executable. Procedure: # chmod a-x /usr/bin/ldd Check the system for the 'ldd' binary. Procedure: # ls -lL /usr/bin/ldd If the 'ldd' binary has any executable permissions bits set, this is a finding. GEN007950 <GroupDescription></GroupDescription> GEN007950 The system must not respond to ICMPv6 echo requests sent to a broadcast address. <VulnDiscussion>Responding to broadcast ICMP echo requests facilitates network mapping and provides a vector for amplification attacks.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000366 Add an iptables rule that drops inbound IPv6 ICMP ECHO_REQUESTs sent to the all-hosts multicast address. Edit /etc/sysconfig/ip6tables and add a rule in, or referenced by, the INPUT chain such as: -A INPUT -p icmpv6 -d ff02::1 --icmpv6-type 128 -j DROP Reload the iptables rules. Procedure: # service ip6tables restart Check for an iptables rule that drops inbound IPv6 ICMP ECHO_REQUESTs sent to the all-hosts multicast address. Procedure: # less /etc/sysconfig/ip6tables Check for a rule in, or referenced by, the INPUT chain such as: -A INPUT -p icmpv6 -d ff02::1 --icmpv6-type 128 -j DROP If such a rule does not exist, this is a finding. GEN000402 <GroupDescription></GroupDescription> GEN000402 The Department of Defense (DoD) login banner must be displayed immediately prior to, or as part of, graphical desktop environment login prompts. <VulnDiscussion>Failure to display the logon banner prior to a logon attempt will negate legal proceedings resulting from unauthorized access to system resources. This requirement applies to graphical desktop environments provided by the system to locally attached displays and input devices as well as to graphical desktop environments provided to remote systems, including thin clients.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECWM-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-4188-9 CCI-000048 Configure the system to display one of the DoD login banners prior to, or as part of, the graphical desktop environment login process. Procedure: Modify /usr/share/gdm/themes/RHEL/RHEL.xml by adding the following xml after the first two "pixmap" entries. <item type="rect" id="custom-dod-banner"> <pos anchor="nw" x="20%" y="10" width="80%" height="100%"/> <box> <item type="label"> <normal font="Sans Bold 9" color="#ffffff"/> <text> Insert the "approved text" here based on the character limitations imposed by the system. </text> </item> </box> </item> Approved text: DoD Login Banners: You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details. OR I've read & consent to terms in IS user agreem't. Access the graphical desktop environment(s) provided by the system and attempt to log in. Check for either of the following login banners based on the character limitations imposed by the system. An exact match is required. If one of these banners is not displayed, this is a finding. You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests- -not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details. OR I've read & consent to terms in IS user agreem't. GEN009120 <GroupDescription></GroupDescription> GEN009120 The system, if capable, must be configured to require the use of a CAC, PIV compliant hardware token, or Alternate Logon Token (ALT) for authentication. <VulnDiscussion>In accordance with CTO 07-015 PKI authentication is required. This provides stronger, two-factor authentication than using a username/password. NOTE: The following are exempt from this, however, they must meet all password requirements and must be documented with the IAO: - SIPRNET systems. - Stand-alone systems. - Application Accounts. - Students or unpaid employees (such as, interns) who are not eligible to receive or not in receipt of a CAC, PIV, or ALT. - Warfighters and support personnel located at operational tactical locations conducting wartime operations that are not collocated with RAPIDS workstations to issue CAC; are not eligible for CAC or do not have the capability to use ALT. - Test systems that have an Interim Approval to Test (IATT) and provide protection via separate VPN, firewall, or security measures preventing access to network and system components from outside the protection boundary documented in the IATT.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAIA-1, IAIA-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000768 Consult vendor documentation to determine the procedures necessary for configuring CAC authentication. Configure all accounts required by policy to use CAC authentication. Consult vendor documentation to determine if the system is capable of CAC authentication. If it is not, this is not applicable. Interview the SA to determine if all accounts not exempted by policy are using CAC authentication. If non-exempt accounts are not using CAC authentication, this is a finding. GEN002870 <GroupDescription></GroupDescription> GEN002870 The system must be configured to send audit records to a remote audit server. <VulnDiscussion>Audit records contain evidence that can be used in the investigation of compromised systems. To prevent this evidence from compromise, it must be sent to a separate system continuously. Methods for sending audit records include, but are not limited to, system audit tools used to send logs directly to another host or through the system's syslog service to another host. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECTB-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000136 Configure the system to send audit records to a remote server. Procedure: These instructions assume a known remote audit server is available to this system. Modify /etc/syslog.conf to contain a line sending all audit records to a remote audit server. The server is specified by placing an "@" before the DNS name or IP address in the line. *.* @<remote audit server> Edit the "active" line in /etc/audisp/plugins.d/syslog.conf so it shows "active = yes". Restart audit and syslog: # service auditd restart # service syslog restart Verify the system is configured to forward all audit records to a remote server. If the system is not configured to provide this function, this is a finding. Procedure: Ensure the audit option for the kernel is enabled. # grep "audit" /boot/grub/grub.conf | grep -v "^#" If the kernel does not have the "audit=1" option specified, this is a finding. Ensure the kernel auditing is active. # grep "active" /etc/audisp/plugins.d/syslog.conf | grep -v "^#" If the "active" setting is either missing or not set to "yes", this is a finding. Ensure all audit records are forwarded to a remote server. # grep "\*.\*" /etc/syslog.conf |grep "@" | grep -v "^#" (for syslog) or: # grep "\*.\*" /etc/rsyslog.conf | grep "@" | grep -v "^#" (for rsyslog) If neither of these lines exist, it is a finding. GEN008050 <GroupDescription></GroupDescription> GEN008050 If the system is using LDAP for authentication or account information, the /etc/ldap.conf file (or equivalent) must not contain passwords. <VulnDiscussion>The authentication of automated LDAP connections between systems must not use passwords since more secure methods are available, such as PKI and Kerberos. Additionally, the storage of unencrypted passwords on the system is not permitted.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAIA-1, IAIA-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000196 Edit the "/etc/ldap.conf" file to use anonymous binding by removing the "bindpw" option. Check for the "bindpw" option being used in the "/etc/ldap.conf" file. # grep bindpw /etc/ldap.conf If an uncommented "bindpw" option is returned then a cleartext password is in the file, this is a finding. GEN003850 <GroupDescription></GroupDescription> GEN003850 The telnet daemon must not be running. <VulnDiscussion>The telnet daemon provides a typically unencrypted remote access service which does not provide for the confidentiality and integrity of user passwords or the remote session. If a privileged user were to log on using this service, the privileged user password could be compromised.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations>GEN003850</Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl>If an enabled telnet daemon is configured to only allow encrypted sessions, such as with Kerberos or the use of encrypted network tunnels, the risk of exposing sensitive information is mitigated, and this is not a finding.</MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCPP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-3390-2 CCI-000197 Identify the telnet service running and disable it. Procedure: Disable the telnet server. # chkconfig telnet off Verify the telnet daemon is no longer running. # ps -ef |grep telnet The telnet service included in the RHEL distribution is part of krb5-workstation. There are two versions of telnetd server provided. The xinetd.d file ekrb5-telnet allows only connections authenticated through kerberos. The xinetd.d krb5-telnet allows normal telnet connections as well as kerberized connections. Both are set to "disable = yes" by default. Ensure that neither is running. Procedure: Check if telnetd is running: # ps -ef |grep telnetd If the telnet daemon is running, this is a finding. Check if telnetd is enabled on startup: # chkconfig --list|grep telnet If an entry with "on" is found, this is a finding. GEN008710 <GroupDescription></GroupDescription> GEN008710 The system boot loader must protect passwords using an MD5 or stronger cryptographic hash. <VulnDiscussion>If system boot loader passwords are compromised, users with console access to the system may be able to alter the system boot configuration or boot the system into single user or maintenance mode, which could result in Denial of Service or unauthorized privileged access to the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAIA-1, IAIA-2</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000213 Consult vendor documentation for procedures concerning the system's boot loader. Configure the boot loader to hash boot loader passwords using MD5 or a stronger hash. Check GRUB for password configuration. Procedure: Check the /boot/grub/grub.conf or /boot/grub/menu.lst files. # grep "password" /boot/grub/grub.conf /boot/grub/menu.lst Check for a password configuration line, such as: password --md5 <password-hash> If the boot loader passwords are not protected using an MD5 hash or stronger, this is a finding. GEN000140-2 <GroupDescription></GroupDescription> GEN000140-2 A file integrity baseline including cryptographic hashes must be created. <VulnDiscussion>A file integrity baseline is a collection of file metadata which is to evaluate the integrity of the system. A minimal baseline must contain metadata for all device files, setuid files, setgid files, system libraries, system binaries, and system configuration files. The minimal metadata must consist of the mode, owner, group owner, and modification times. For regular files, metadata must also include file size and a cryptographic hash of the file’s contents. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCSW-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000293 Use AIDE to create a file integrity baseline, including cryptographic hashes, for the system. Configure the /etc/aide.conf file to ensure some form of cryptographic hash (e.g., md5,rmd160,sha256) is used for files. In the default /etc/aide.conf the "NORMAL" or "LSPP" rules which are used for virtually all files DO include some form of cryptographic hash. Verify a system integrity baseline exists. The Advanced Intrusion Detection Environment (AIDE) is included in the distribution of RHEL. Other host intrusion detection system (HIDS) software is available but must be checked manually. Procedure: # grep DBDIR /etc/aide.conf If /etc/aide.conf does not exist AIDE has not been installed. Unless another HIDS is used on the system, this is a finding. Examine the response for "database" this indicates the location of the system integrity baseline database used as input to a comparison. # ls -la <DBDIR> If no "database" file as defined in /etc/aide.conf exists a system integrity baseline has not been created, this is a finding. Examine /etc/aide.conf to ensure some form of cryptographic hash (i.e. md5,rmd160,sha256) is used for files. In the default /etc/aide.conf the "NORMAL" or "LSPP" rules which are used for virtually all files DO include some form of cryptographic hash. If the site has defined rules to replace the functionality provided by the default "NORMAL" and "LSPP" rules but DOES NOT include cryptographic hashes, this is a finding. Otherwise, if any element used to define the "NORMAL" and "LSPP" rules has been modified resulting in cryptographic hashes not being used, this is a finding. If any other modification to the default /etc/aide.conf file have been made resulting in rules which do not include cryptographic hashes on appropriate files, this is a finding. GEN000140-3 <GroupDescription></GroupDescription> GEN000140-3 A file integrity baseline including cryptographic hashes must be maintained. <VulnDiscussion>A file integrity baseline is a collection of file metadata which is to evaluate the integrity of the system. A minimal baseline must contain metadata for all device files, setuid files, setgid files, system libraries, system binaries, and system configuration files. The minimal metadata must consist of the mode, owner, group owner, and modification times. For regular files, metadata must also include file size and a cryptographic hash of the file’s contents. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>DCSW-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000293 Regularly rebuild the integrity baseline, including cryptographic hashes, for the system to be consistent with the latest approved system configuration. Procedure: After an approved modification to the system configuration has been made perform: # aide -u This will update the database. Verify a system integrity baseline is maintained. The baseline has been updated to be consistent with the latest approved system configuration changes. The Advanced Intrusion Detection Environment (AIDE) is included in the distribution of RHEL-5. Other host intrusion detection system (HIDS) software is available but must be checked manually. Procedure: # grep DBDIR /etc/aide.conf If /etc/aide.conf does not exist AIDE has not been installed. Unless another HIDS is used on the system, this is a finding. Examine the response for "database" indicates the location of the system integrity baseline database used as input to a comparison. # ls -la <DBDIR> If the no "database" file as defined in /etc/aide.conf a system integrity baseline has not been created, this is a finding. Ask the SA when the last approved system configuration changes occurred. If the modification date of the AIDE database is prior to the last approved configuration change, this is a finding. GEN000290-2 <GroupDescription></GroupDescription> GEN000290-2 The system must not have the unnecessary "news" account. <VulnDiscussion>Accounts that provide no operational purpose provide additional opportunities for system compromise. Unnecessary accounts include user accounts for individuals not requiring access to the system and application accounts for applications not installed on the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAAC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000012 Remove the "news" account from the /etc/passwd file before connecting a system to the network. Check the system for the unnecessary "news" accounts. Procedure: # rpm -q inn If the "inn" is installed the "news" user is necessary and this is not a finding. # grep ^news /etc/passwd If this account exists and "inn" is not installed, this is a finding. GEN000290-3 <GroupDescription></GroupDescription> GEN000290-3 The system must not have the unnecessary "gopher" account. <VulnDiscussion>Accounts that provide no operational purpose provide additional opportunities for system compromise. Unnecessary accounts include user accounts for individuals not requiring access to the system and application accounts for applications not installed on the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAAC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000012 Remove the "gopher" account from the /etc/passwd file before connecting a system to the network. Check the system for the unnecessary "gopher" accounts. Procedure: # grep ^gopher /etc/passwd If this account exists, it is a finding. GEN000290-4 <GroupDescription></GroupDescription> GEN000290-4 The system must not have the unnecessary "ftp" account. <VulnDiscussion>Accounts that provide no operational purpose provide additional opportunities for system compromise. Unnecessary accounts include user accounts for individuals not requiring access to the system and application accounts for applications not installed on the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>IAAC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000012 Remove the "ftp" account from the /etc/passwd file before connecting a system to the network. Check the system for the unnecessary "ftp" accounts. Procedure: # rpm -q krb5-workstation An ftp server is part of "krb5-workstation". If it is installed the "ftp" user is necessary and this is not a finding. # rpm -q vsftp If the "vsftp" ftp server is installed the "ftp" user is necessary and this is not a finding. # grep ^ftp /etc/passwd If this account exists and no ftp server is installed which requires it, this is a finding. GEN000500-2 <GroupDescription></GroupDescription> GEN000500-2 The graphical desktop environment must set the idle timeout to no more than 15 minutes. <VulnDiscussion>If graphical desktop sessions do not lock the session after 15 minutes of inactivity, requiring re-authentication to resume operations, the system or individual data could be compromised by an alert intruder who could exploit the oversight. This requirement applies to graphical desktop environments provided by the system to locally attached displays and input devices as well as to graphical desktop environments provided to remote systems, including thin clients.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>PESL-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000057 For the Gnome screen saver, set idle_delay to 15. Procedure: # gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type int --set /apps/gnome-screensaver/idle_delay 15 If the "xorg-x11-server-Xorg" package is not installed, this is not applicable. For the Gnome screen saver, check the idle_delay setting. Procedure: # gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --get /apps/gnome-screensaver/idle_delay If this does not return 15 or less, this is a finding. GEN000500-3 <GroupDescription></GroupDescription> GEN000500-3 Graphical desktop environments provided by the system must have automatic lock enabled. <VulnDiscussion>If graphical desktop sessions do not lock the session after 15 minutes of inactivity, requiring re-authentication to resume operations, the system or individual data could be compromised by an alert intruder who could exploit the oversight. This requirement applies to graphical desktop environments provided by the system to locally attached displays and input devices as well as to graphical desktop environments provided to remote systems, including thin clients.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>PESL-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000057 For the Gnome screen saver, set the lock_enabled flag. Procedure: # gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type bool --set /apps/gnome-screensaver/lock_enabled true If the "xorg-x11-server-Xorg" package is not installed, this is not applicable. For the Gnome screen saver, check the lock_enabled flag. Procedure: # gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --get /apps/gnome-screensaver/lock_enabled If this does not return "true", this is a finding. GEN000600-2 <GroupDescription></GroupDescription> GEN000600-2 Global settings defined in system-auth must be applied in the pam.d definition files. <VulnDiscussion>Pam global requirements are generally defined in the /etc/pam.d/system-auth or /etc/pam.d/system-auth-ac file. In order for the requirements to be applied the file containing them must be included directly or indirectly in each program's definition file in /etc/pam.d </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECSC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000192 In the default distribution of RHEL "/etc/pam.d/system-auth" is a symlink "/etc/pam.d/system-auth-ac" which is an autogenerated file. When a site adds password requirements a new system-auth-local file must be created with only the additional requirements and includes for auth, account, passwd and session pointing to "/etc/pam.d/system-auth-ac". Then the symlink "/etc/system-auth" is modified to point to "/etc/pam.d/system-auth-local". This way any changes made do not get lost when "/etc/pam.d/system-auth-ac" is regenerated and each program's pam.d definition file need only have "include system-auth" for auth, account, passwd and session, as needed, in order to assure the password requirements will be applied to it. Verify the system-auth settings are being applied. Procedure: Verify the additional pam.d requirements are in use. The file "/etc/pam.d/system-auth-ac" is auto generated by "authconfig". Any manual changes made to it will be lost next time "authconfig" is run. Check to see if the systems default of the symlink "/etc/pam.d/system-auth" pointing to "/etc/pam.d/system-auth-ac" has been changed. # ls -l /etc/pam.d/system-auth If the symlink points to "/etc/pam.d/system-auth-ac", manual changes cannot be protected. This is a finding. # grep system-auth-ac /etc/pam.d/system-auth The local system-auth file pointed to by "/etc/pam.d/system-auth" must contain "/etc/pam.d/system-auth-ac" for the auth, account, password, and session lines. If it does not then the parameters maintained by "authconfig" will not be applied, this is a finding. GEN002720-2 <GroupDescription></GroupDescription> GEN002720-2 The audit system must be configured to audit failed attempts to access files and programs. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000126 Edit the audit.rules file and add the following line(s) to enable auditing of failed attempts to access files and programs: either: -a exit,always -F arch=<ARCH> -S open -F success=0 or both: -a exit,always -F arch=<ARCH> -S open -F exit=-EPERM -a exit,always -F arch=<ARCH> -S open -F exit=-EACCES Restart the auditd service. # service auditd restart Check that auditd is configured to audit failed file access attempts. There must be an audit rule for each of the access syscalls that logs all failed accesses (-F success=0) or there must both an "-F exit=-EPERM" and "-F exit=-EACCES" for each access syscall. Procedure: # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -e "-S open" | grep -e "-F success=0" # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -e "-S open" | grep -e "-F exit=-EPERM" # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -e "-S open" | grep -e "-F exit=-EACCES" If an "-S open" audit rule with "-F success" does not exist and no separate rules containing "-F exit=-EPERM" and "-F exit=-EACCES" for "open" exist, then this is a finding. GEN002720-3 <GroupDescription></GroupDescription> GEN002720-3 The audit system must be configured to audit failed attempts to access files and programs. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000126 Edit the audit.rules file and add the following line(s) to enable auditing of failed attempts to access files and programs: either: -a exit,always -F arch=<ARCH> -S openat -F success=0 or both: -a exit,always -F arch=<ARCH> -S openat -F exit=-EPERM -a exit,always -F arch=<ARCH> -S openat -F exit=-EACCES Restart the auditd service. # service auditd restart Verify auditd is configured to audit failed file access attempts. There must be an audit rule for each of the access syscalls logging all failed accesses (-F success=0) or there must both an "-F exit=-EPERM" and "-F exit=-EACCES" for each access syscall. Procedure: # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -e "-S openat" | grep -e "-F success=0" # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -e "-S openat" | grep -e "-F exit=-EPERM" # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -e "-S openat" | grep -e "-F exit=-EACCES" If an "-S openat" audit rule with "-F success" does not exist and no separate rules containing "-F exit=-EPERM" and "-F exit=-EACCES" for "openat" exist, then this is a finding. GEN002720-4 <GroupDescription></GroupDescription> GEN002720-4 The audit system must be configured to audit failed attempts to access files and programs. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000126 Edit the audit.rules file and add the following line(s) to enable auditing of failed attempts to access files and programs: either: -a exit,always -F arch=<ARCH> -S truncate -F success=0 or both: -a exit,always -F arch=<ARCH> -S truncate -F exit=-EPERM -a exit,always -F arch=<ARCH> -S truncate -F exit=-EACCES Restart the auditd service. # service auditd restart Verify auditd is configured to audit failed file access attempts. There must be an audit rule for each of the access syscalls logging all failed accesses (-F success=0) or there must both an "-F exit=-EPERM" and "-F exit=-EACCES" for each access syscall. Procedure: # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -e "-S truncate" | grep -e "-F success=0" # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -e "-S truncate" | grep -e "-F exit=-EPERM" # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -e "-S truncate" | grep -e "-F exit=-EACCES" If an "-S truncate" audit rule with "-F success" does not exist and no separate rules containing "-F exit=-EPERM" and "-F exit=-EACCES" for "truncate" exist, then this is a finding. GEN002720-5 <GroupDescription></GroupDescription> GEN002720-5 The audit system must be configured to audit failed attempts to access files and programs. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000126 Edit the audit.rules file and add the following line(s) to enable auditing of failed attempts to access files and programs: either: -a exit,always -F arch=<ARCH> -S ftruncate -F success=0 or both: -a exit,always -F arch=<ARCH> -S ftruncate -F exit=-EPERM -a exit,always -F arch=<ARCH> -S ftruncate -F exit=-EACCES Restart the auditd service. # service auditd restart Verify auditd is configured to audit failed file access attempts. There must be an audit rule for each of the access syscalls logging all failed accesses (-F success=0) or there must both an "-F exit=-EPERM" and "-F exit=-EACCES" for each access syscall. Procedure: # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -e "-S ftruncate" | grep -e "-F success=0" # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -e "-S ftruncate" | grep -e "-F exit=-EPERM" # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -e "-S ftruncate" | grep -e "-F exit=-EACCES" If an "-S ftruncate" audit rule with "-F success" does not exist and no separate rules containing "-F exit=-EPERM" and "-F exit=-EACCES" for "ftruncate" exist, then this is a finding. GEN002740-2 <GroupDescription></GroupDescription> GEN002740-2 The audit system must be configured to audit file deletions. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000126 Edit the audit.rules file and add the following line to enable auditing of deletions: -a exit,always -S rmdir Restart the auditd service. # service auditd restart Check the system audit configuration to determine if file and directory deletions are audited. # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -i "rmdir" If no results are returned, or the results do not contain "-S rmdir", this is a finding. GEN002760-2 <GroupDescription></GroupDescription> GEN002760-2 The audit system must be configured to audit all administrative, privileged, and security actions. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14051-7 CCI-000347 The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding. Procedure: Add the following lines to the audit.rules file to enable auditing of administrative, privileged, and security actions: -w /etc/audit/audit.rules Restart the auditd service. # service auditd restart Check the auditing configuration of the system. Procedure: # cat /etc/audit/audit.rules | grep -i "audit.rules" If no results are returned, or the line does not start with "-w", this is a finding. GEN002760-3 <GroupDescription></GroupDescription> GEN002760-3 The audit system must be configured to audit all administrative, privileged, and security actions. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14051-7 CCI-000347 The "-F arch=<ARCH>"restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules. On single architecture systems, the "-F arch=<ARCH>"restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details. Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately. The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding. Procedure: Add the following lines to the audit.rules file to enable auditing of administrative, privileged, and security actions: -a exit,always -F arch=<ARCH> -S adjtimex Restart the auditd service. # service auditd restart Check the auditing configuration of the system. Procedure: # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -i "adjtimex" If the result does not contain "-S adjtimex", this is a finding. GEN002760-4 <GroupDescription></GroupDescription> GEN002760-4 The audit system must be configured to audit all administrative, privileged, and security actions. <VulnDiscussion> If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14051-7 CCI-000347 The "-F arch=<ARCH>"restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules. On single architecture systems, the "-F arch=<ARCH>"restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details. Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately. The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding. Procedure: Add the following lines to the audit.rules file to enable auditing of administrative, privileged, and security actions: -a exit,always -F arch=<ARCH> -S settimeofday Restart the auditd service. # service auditd restart Check the auditing configuration of the system. Procedure: # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -i "settimeofday" If the result does not contain "-S settimeofday", this is a finding. GEN002760-5 <GroupDescription></GroupDescription> GEN002760-5 The audit system must be configured to audit all administrative, privileged, and security actions. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14051-7 CCI-000347 The "-F arch=<ARCH>"restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules. On single architecture systems, the "-F arch=<ARCH>"restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details. Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately. The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding. Procedure: Add the following lines to the audit.rules file to enable auditing of administrative, privileged, and security actions: -a exit,always -F arch=<ARCH> -S stime -a exit,always -F arch=<ARCH> -S settimeofday (only needed on systems using a b64 architecture) Restart the auditd service. # service auditd restart Check the auditing configuration of the system. Procedure: # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -i "stime" # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -i "settimeofday" If the result does not contain "-S stime", this is a finding. The settimeofday caveat is only required on systems using a b64 architecture. GEN002760-6 <GroupDescription></GroupDescription> GEN002760-6 The audit system must be configured to audit all administrative, privileged, and security actions. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14051-7 CCI-000347 The "-F arch=<ARCH>"restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules. On single architecture systems, the "-F arch=<ARCH>"restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details. Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately. The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding. Procedure: Add the following lines to the audit.rules file to enable auditing of administrative, privileged, and security actions: -a exit,always -F arch=<ARCH> -S clock_settime Restart the auditd service. # service auditd restart Check the auditing configuration of the system. Procedure: # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -i "clock_settime" If the result does not contain "-S clock_settime", this is a finding. GEN002760-7 <GroupDescription></GroupDescription> GEN002760-7 The audit system must be configured to audit all administrative, privileged, and security actions. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14051-7 CCI-000347 The "-F arch=<ARCH>"restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules. On single architecture systems, the "-F arch=<ARCH>"restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details. Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately. The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding. Procedure: Add the following lines to the audit.rules file to enable auditing of administrative, privileged, and security actions: -a exit,always -F arch=<ARCH> -S sethostname Restart the auditd service. # service auditd restart Check the auditing configuration of the system. Procedure: # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -i "sethostname" If the result does not contain "-S sethostname", this is a finding. GEN002760-8 <GroupDescription></GroupDescription> GEN002760-8 The audit system must be configured to audit all administrative, privileged, and security actions. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14051-7 CCI-000347 The "-F arch=<ARCH>"restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules. On single architecture systems, the "-F arch=<ARCH>"restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details. Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately. The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding. Procedure: Add the following lines to the audit.rules file to enable auditing of administrative, privileged, and security actions: -a exit,always -F arch=<ARCH> -S setdomainname Restart the auditd service. # service auditd restart Check the auditing configuration of the system. Procedure: # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -i "setdomain" If the result does not contain "-S setdomain", this is a finding. GEN002760-9 <GroupDescription></GroupDescription> GEN002760-9 The audit system must be configured to audit all administrative, privileged, and security actions. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14051-7 CCI-000347 The "-F arch=<ARCH>"restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules. On single architecture systems, the "-F arch=<ARCH>"restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details. Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately. The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding. Procedure: A Real Time Operating System (RTOS) provides specialized system scheduling which causes an inordinate number of messages to be produced when the sched_setparam and set_setscheduler are audited. This not only may degrade the system speed to an unusable level but obscures any forensic information which may otherwise have been useful. Unless the operating system is a Red Hat 5 based RTOS (including MRG and AS5300) the following should also be present in /etc/audit/audit.rules -a exit,always -F arch=<ARCH> -S sched_setparam Restart the auditd service. # service auditd restart Check the auditing configuration of the system. Procedure: # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -i "sched_setparam" If the result does not contain "-S sched_setparam", this is a finding. GEN002760-10 <GroupDescription></GroupDescription> GEN002760-10 The audit system must be configured to audit all administrative, privileged, and security actions. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14051-7 CCI-000347 The "-F arch=<ARCH>"restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules. On single architecture systems, the "-F arch=<ARCH>"restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details. Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately. The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding. Procedure: A Real Time Operating System (RTOS) provides specialized system scheduling which causes an inordinate number of messages to be produced when the sched_setparam and set_setscheduler are audited. This not only may degrade the system speed to an unusable level but obscures any forensic information which may otherwise have been useful. Unless the operating system is a Red Hat 5 based RTOS (including MRG and AS5300) the following should also be present in /etc/audit/audit.rules -a exit,always -F arch=<ARCH> -S sched_setscheduler Restart the auditd service. # service auditd restart Check the auditing configuration of the system. Procedure: # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -i "sched_setscheduler" If the result does not contain "-S sched_setscheduler", this is a finding. GEN002820-2 <GroupDescription></GroupDescription> GEN002820-2 The audit system must be configured to audit all discretionary access control permission modifications. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14058-2 CCI-000126 The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules. On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details. Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately. The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding. Procedure: Edit the audit.rules file and add the following lines to enable auditing of discretionary access control permissions modifications. -a exit,always -F arch=<ARCH> -S fchmod Restart the auditd service. # service auditd restart Check the system's audit configuration. Procedure: # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -i "fchmod" If "-S fchmod" is not in the result, this is a finding GEN002820-3 <GroupDescription></GroupDescription> GEN002820-3 The audit system must be configured to audit all discretionary access control permission modifications. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14058-2 CCI-000126 The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules. On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details. Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately. The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding. Procedure: Edit the audit.rules file and add the following lines to enable auditing of discretionary access control permissions modifications. -a exit,always -F arch=<ARCH> -S fchmodat Restart the auditd service. # service auditd restart Check the system's audit configuration. Procedure: # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -i "fchmodat" If "-S fchmodat" is not in the result, this is a finding. GEN002820-4 <GroupDescription></GroupDescription> GEN002820-4 The audit system must be configured to audit all discretionary access control permission modifications. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14058-2 CCI-000126 The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules. On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details. Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately. The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding. Procedure: Edit the audit.rules file and add the following lines to enable auditing of discretionary access control permissions modifications. -a exit,always -F arch=<ARCH> -S chown Additionally, the following rule is required in systems supporting the 32-bit syscall table (such as i686 and x86_64): -a exit,always -F arch=<ARCH> -S chown32 Restart the auditd service. # service auditd restart Check the system's audit configuration. Procedure: # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -i "chown" If "-S chown" is not in the result, this is a finding. Additionally, the following rule is required in systems supporting the 32-bit syscall table (such as i686 and x86_64): # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -i "chown32" If "-S chown32" is not in the result, this is a finding. GEN002820-5 <GroupDescription></GroupDescription> GEN002820-5 The audit system must be configured to audit all discretionary access control permission modifications. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14058-2 CCI-000126 The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules. On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details. Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately. The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding. Procedure: Edit the audit.rules file and add the following lines to enable auditing of discretionary access control permissions modifications. -a exit,always -F arch=<ARCH> -S fchown Additionally, the following rule is required in systems supporting the 32-bit syscall table (such as i686 and x86_64): -a exit,always -F arch=<ARCH> -S fchown32 Restart the auditd service. # service auditd restart Check the system's audit configuration. Procedure: # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -i "fchown" If "-S fchown" is not in the result, this is a finding. Additionally, the following rule is required in systems supporting the 32-bit syscall table (such as i686 and x86_64): # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -i "fchown32" If "-S fchown32" is not in the result, this is a finding. GEN002820-6 <GroupDescription></GroupDescription> GEN002820-6 The audit system must be configured to audit all discretionary access control permission modifications. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14058-2 CCI-000126 The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules. On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details. Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately. The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding. Procedure: Edit the audit.rules file and add the following lines to enable auditing of discretionary access control permissions modifications. -a exit,always -F arch=<ARCH> -S fchownat Restart the auditd service. # service auditd restart Check the system's audit configuration. Procedure: # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -i "fchownat" If "-S fchownat" is not in the result, this is a finding. GEN002820-7 <GroupDescription></GroupDescription> GEN002820-7 The audit system must be configured to audit all discretionary access control permission modifications. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14058-2 CCI-000126 The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules. On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details. Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately. The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding. Procedure: Edit the audit.rules file and add the following lines to enable auditing of discretionary access control permissions modifications. -a exit,always -F arch=<ARCH> -S lchown Additionally, the following rule is required in systems supporting the 32-bit syscall table (such as i686 and x86_64): -a exit,always -F arch=<ARCH> -S lchown32 Restart the auditd service. # service auditd restart Check the system's audit configuration. Procedure: # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -i "lchown" If "-S lchown" is not in the result, this is a finding. Additionally, the following rule is required in systems supporting the 32-bit syscall table (such as i686 and x86_64): # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -i "lchown32" If "-S lchown32" is not in the result, this is a finding. GEN002820-8 <GroupDescription></GroupDescription> GEN002820-8 The audit system must be configured to audit all discretionary access control permission modifications. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14058-2 CCI-000126 The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules. On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details. Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately. The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding. Procedure: Edit the audit.rules file and add the following lines to enable auditing of discretionary access control permissions modifications. -a exit,always -F arch=<ARCH> -S setxattr Restart the auditd service. # service auditd restart Check the system's audit configuration. Procedure: # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -i "setxattr" If "-S setxattr" is not in the result, this is a finding. GEN002820-9 <GroupDescription></GroupDescription> GEN002820-9 The audit system must be configured to audit all discretionary access control permission modifications. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14058-2 The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules. On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details. Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately. The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding. Procedure: Edit the audit.rules file and add the following lines to enable auditing of discretionary access control permissions modifications. -a exit,always -F arch=<ARCH> -S lsetxattr Restart the auditd service. # service auditd restart Check the system's audit configuration. Procedure: # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -i "lsetxattr" If "-S lsetxattr" is not in the result, this is a finding. GEN002820-10 <GroupDescription></GroupDescription> GEN002820-10 The audit system must be configured to audit all discretionary access control permission modifications. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14058-2 CCI-000126 The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules. On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details. Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately. The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding. Procedure: Edit the audit.rules file and add the following lines to enable auditing of discretionary access control permissions modifications. -a exit,always -F arch=<ARCH> -S fsetxattr Restart the auditd service. # service auditd restart Check the system's audit configuration. Procedure: # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -i "fsetxattr" If "-S fsetxattr" is not in the result, this is a finding. GEN002820-11 <GroupDescription></GroupDescription> GEN002820-11 The audit system must be configured to audit all discretionary access control permission modifications. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14058-2 CCI-000126 The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules. On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details. Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately. The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding. Procedure: Edit the audit.rules file and add the following lines to enable auditing of discretionary access control permissions modifications. -a exit,always -F arch=<ARCH> -S removexattr Restart the auditd service. # service auditd restart Check the system's audit configuration. Procedure: # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -i "removexattr" If "-S removexattr" is not in the result, this is a finding. GEN002820-12 <GroupDescription></GroupDescription> GEN002820-12 The audit system must be configured to audit all discretionary access control permission modifications. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14058-2 CCI-000126 The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules. On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details. Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately. The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding. Procedure: Edit the audit.rules file and add the following lines to enable auditing of discretionary access control permissions modifications. -a exit,always -F arch=<ARCH> -S lremovexattr Restart the auditd service. # service auditd restart Check the system's audit configuration. Procedure: # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -i "lremovexattr" If "-S lremovexattr" is not in the result, this is a finding. GEN002820-13 <GroupDescription></GroupDescription> GEN002820-13 The audit system must be configured to audit all discretionary access control permission modifications. <VulnDiscussion>If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14058-2 CCI-000126 The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules. On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details. Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately. The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding. Procedure: Edit the audit.rules file and add the following lines to enable auditing of discretionary access control permissions modifications. -a exit,always -F arch=<ARCH> -S fremovexattr Restart the auditd service. # service auditd restart Check the system's audit configuration. Procedure: # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -i "fremovexattr" If "-S fremovexattr" is not in the result, this is a finding. GEN002825-2 <GroupDescription></GroupDescription> GEN002825-2 The audit system must be configured to audit the loading and unloading of dynamic kernel modules - delete_module. <VulnDiscussion>Actions concerning dynamic kernel modules must be recorded as they are substantial events. Dynamic kernel modules can increase the attack surface of a system. A malicious kernel module can be used to substantially alter the functioning of a system, often with the purpose of hiding a compromise from the SA.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14688-6 CCI-000126 The "-F arch=<ARCH>" restriction is required on dual-architecture systems (such as x86_64). On dual-architecture systems, two separate rules must exist - one for each architecture supported. Use the generic architectures "b32" and "b64" for specifying these rules. On single architecture systems, the "-F arch=<ARCH>" restriction may be omitted, but if present must match either the architecture of the system or its corresponding generic architecture. The architecture of the system may be determined by running "uname -m". See the auditctl(8) manpage for additional details. Any restrictions (such as with "-F") beyond those provided in the example rules are not in strict compliance with this requirement, and are a finding unless justified and documented appropriately. The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding. Procedure: Configure auditing of the delete_module syscalls. Add the following to the "etc/audit/audit.rules" or "etc/audit.rules" file: -a exit,always -S delete_module Restart the auditd service. # service auditd restart Determine if the delete_module syscall is audited. # cat /etc/audit/audit.rules | grep -e "-a exit,always" | grep -i "delete_module" If the result does not contain "-S delete_module", this is a finding. GEN002825-3 <GroupDescription></GroupDescription> GEN002825-3 The audit system must be configured to audit the loading and unloading of dynamic kernel modules - /sbin/insmod. <VulnDiscussion>Actions concerning dynamic kernel modules must be recorded as they are substantial events. Dynamic kernel modules can increase the attack surface of a system. A malicious kernel module can be used to substantially alter the functioning of a system, often with the purpose of hiding a compromise from the SA.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14688-6 CCI-000126 The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding. Procedure: Configure auditing of the /sbin/insmod, files. Add the following to the "etc/audit/audit.rules" or "etc/audit.rules" file: -w /sbin/insmod -p x Restart the auditd service. # service auditd restart Determine if /sbin/insmod is audited. # cat /etc/audit/audit.rules | grep "/sbin/insmod" If the result does not start with "-w" and contain "-p x", this is a finding. GEN002825-4 <GroupDescription></GroupDescription> GEN002825-4 The audit system must be configured to audit the loading and unloading of dynamic kernel modules -/sbin/modprobe. <VulnDiscussion>Actions concerning dynamic kernel modules must be recorded as they are substantial events. Dynamic kernel modules can increase the attack surface of a system. A malicious kernel module can be used to substantially alter the functioning of a system, often with the purpose of hiding a compromise from the SA.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14688-6 CCI-000126 The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding. Procedure: -w /sbin/modprobe -p x Restart the auditd service. # service auditd restart Determine if the /sbin/modprobe file is audited. # cat /etc/audit/audit.rules | grep "/sbin/modprobe" If the result does not start with "-w" and contain "-p x", this is a finding. GEN002825-5 <GroupDescription></GroupDescription> GEN002825-5 The audit system must be configured to audit the loading and unloading of dynamic kernel modules - /sbin/rmmod <VulnDiscussion>Actions concerning dynamic kernel modules must be recorded as they are substantial events. Dynamic kernel modules can increase the attack surface of a system. A malicious kernel module can be used to substantially alter the functioning of a system, often with the purpose of hiding a compromise from the SA.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECAR-1, ECAR-2, ECAR-3</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCE-14688-6 CCI-000126 The use of audit keys consistent with the provided example is encouraged to provide for uniform audit logs, however omitting the audit key or using an alternate audit key is not a finding. Procedure: Configure auditing of the /sbin/rmmod file. Add the following to the "etc/audit/audit.rules" or "etc/audit.rules" file: -w /sbin/rmmod -p x Restart the auditd service. # service auditd restart Determine if the /sbin/rmmod file is audited. # cat /etc/audit/audit.rules | grep "/sbin/rmmod" If the result does not start with "-w" and contain "-p x", this is a finding. GEN003080-2 <GroupDescription></GroupDescription> GEN003080-2 Files in cron script directories must have mode 0700 or less permissive. <VulnDiscussion>To protect the integrity of scheduled system jobs and prevent malicious modification to these jobs, crontab files must be secured.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility>System Administrator</Responsibility><IAControls>ECLP-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000225 Change the mode of the cron scripts. # chmod 0700 /etc/cron.daily/* /etc/cron.hourly/* /etc/cron.monthly/* /etc/cron.weekly/* Check the mode of scripts in cron job directories. # ls -lL /etc/cron.daily/ # ls -lL /etc/cron.hourly/ # ls -lL /etc/cron.monthly/ # ls -lL /etc/cron.weekly/ If any cron script has a mode more permissive than 0700, this is a finding. GEN000290-1 <GroupDescription></GroupDescription> GEN000290-1 The system must not have the unnecessary "games" account. <VulnDiscussion>Accounts that provide no operational purpose provide additional opportunities for system compromise. Unnecessary accounts include user accounts for individuals not requiring access to the system and application accounts for applications not installed on the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls>IAAC-1</IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000012 Remove the "games" account. Procedure: # userdel games Check the system for the unnecessary "games" accounts. Procedure: # grep ^games /etc/passwd If this account exists, it is a finding. GEN006660 <GroupDescription></GroupDescription> GEN006660 Accounts must be locked upon 35 days of inactivity. <VulnDiscussion>Disabling inactive accounts ensures that accounts which may not have been responsibly removed are not available to attackers who may have compromised their credentials.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> DPMS Target Red Hat 5 DISA FSO DPMS Target Red Hat 5 2154 CCI-000017 To specify the number of days after a password expires (which signifies inactivity) until an account is permanently disabled, add or correct the following lines in "/etc/default/useradd", substituting "[NUM_DAYS]" appropriately: INACTIVE=[NUM_DAYS] A value of 35 is recommended. If a password is currently on the verge of expiration, then 35 days remain until the account is automatically disabled. However, if the password will not expire for another 60 days, then 95 days could elapse until the account would be automatically disabled. See the "useradd" man page for more information. Determining the inactivity timeout must be done with careful consideration of the length of a "normal" period of inactivity for users in the particular environment. Setting the timeout too low incurs support costs and also has the potential to impact availability of the system to legitimate users. To verify the "INACTIVE" setting, run the following command: grep "INACTIVE" /etc/default/useradd The output should indicate the "INACTIVE" configuration option is set to an appropriate integer as shown in the example below: # grep "INACTIVE" /etc/default/useradd INACTIVE=35 If it does not, this is a finding. scap-security-guide-0.1.31/RHEL/5/templates/000077500000000000000000000000001301675746700203765ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/5/templates/csv/000077500000000000000000000000001301675746700211715ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/5/templates/csv/file_dir_permissions.csv000066400000000000000000000011061301675746700261140ustar00rootroot00000000000000/bin,traceroute,0,0,700 /etc,at.allow,0,0,0600 /etc,at.deny,0,0,0600 /etc,cron.allow,0,0,0600 /etc,cron.deny,0,0,0600 /etc,cups/printers.conf,0,0,0644 /etc,exports,0,0,0644 /etc,group,0,0,0644 /etc,gshadow,0,0,0400 /etc,hosts,0,0,0644 /etc,ldap.conf,0,0,0644 /etc/news,incoming.conf,0,0,0600 /etc/news,infeed.conf,0,0,0600 /etc/news,passwd.nntp,0,0,0600 /etc,nsswitch.conf,0,0,0644 /etc,ntp.conf,0,0,0640 /etc,passwd,0,0,0644 /etc,resolv.conf,0,0,0644 /etc,securetty,0,0,0600 /etc/security,access.conf,0,0,0640 /etc,services,0,0,0644 /etc,shadow,0,0,0400 /etc,syslog.conf,0,0,0640 scap-security-guide-0.1.31/RHEL/5/templates/csv/kernel_modules_disabled.csv000066400000000000000000000001211301675746700265370ustar00rootroot00000000000000#dccp rds sctp tipc usb-storage bluetooth ieee1394 bridge appletalk #ipv6_option scap-security-guide-0.1.31/RHEL/5/templates/csv/packages_removed.csv000066400000000000000000000000361301675746700252040ustar00rootroot00000000000000#rpc rsh-server #samba xinetd scap-security-guide-0.1.31/RHEL/5/templates/csv/services_disabled.csv000066400000000000000000000003321301675746700253560ustar00rootroot00000000000000# service_name, package_name, daemon_name (as recognized by chkconfig / systemd. To be used when daemon_name differs from service_name) autofs,, rexec,, rlogin,, rsh,, telnetd,, tftp,, xinetd,, ypbind,, yum-updatesd,, scap-security-guide-0.1.31/RHEL/5/templates/csv/services_enabled.csv000066400000000000000000000000301301675746700251740ustar00rootroot00000000000000auditd, iptables, ntpd, scap-security-guide-0.1.31/RHEL/5/templates/csv/sysctl_values.csv000066400000000000000000000003761301675746700246140ustar00rootroot00000000000000net.ipv4.icmp_echo_ignore_broadcasts,1 #net.ipv4.conf_accept_source_route,1 #net.ipv4.conf_log_martians,1 #net.ipv4.conf_send_redirects,1 #net.ipv4.conf_accept_redirects,1 net.ipv4.ip_forward,0 net.ipv4.tcp_syncookies,1 net.ipv4.tcp_max_syn_backlog,1280 scap-security-guide-0.1.31/RHEL/5/templates/static/000077500000000000000000000000001301675746700216655ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/5/templates/static/bash/000077500000000000000000000000001301675746700226025ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/5/templates/static/bash/accounts_cracklib_present.sh000066400000000000000000000004251301675746700303500ustar00rootroot00000000000000authconfig --updateall if [ -e /etc/pam.d/system-auth-ac ]; then sed -i '/password.*include.*system-auth-ac/ipassword required pam_cracklib.so' /etc/pam.d/system-auth else sed -i '/password.*unix.so/ipassword required pam_cracklib.so' /etc/pam.d/system-auth fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/accounts_disable_expired.sh000066400000000000000000000003021301675746700301530ustar00rootroot00000000000000. /usr/share/scap-security-guide/remediation_functions populate var_account_disable_post_pw_expiration sed -i "/:\(!!\|*\):/!s/:[0-9]*/:${var_account_disable_post_pw_expiration}/6" /etc/shadow scap-security-guide-0.1.31/RHEL/5/templates/static/bash/accounts_disable_post_pw_expiration.sh000066400000000000000000000005471301675746700324630ustar00rootroot00000000000000. /usr/share/scap-security-guide/remediation_functions populate var_account_disable_post_pw_expiration if [ $(cat /etc/default/useradd | grep -c "^INACTIVE=") != 0 ]; then sed -i "s/^INACTIVE=.*/INACTIVE=${var_account_disable_post_pw_expiration}/" /etc/default/useradd else echo INACTIVE=${var_account_disable_post_pw_expiration} >>/etc/default/useradd fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/accounts_fail_delay.sh000066400000000000000000000011631301675746700271270ustar00rootroot00000000000000if [ $(grep -c ^FAIL_DELAY /etc/login.defs) != 0 ]; then sed -i 's/^FAIL_DELAY.*[0-9]*/FAIL_DELAY 4/' /etc/login.defs else echo "FAIL_DELAY 4" | tee -a /etc/login.defs &>/dev/null fi if [ $(grep -c pam_faildelay.so /etc/pam.d/system-auth) != 0 ]; then if [ $(grep -c pam_faildelay.so.*delay\= /etc/pam.d/system-auth) != 0 ]; then sed -i '/pam_faildelay.so/s/\(delay=\)[0-9]*/\14000000/' /etc/pam.d/system-auth else sed -i '/pam_faildelay.so/s/$/ delay=4000000/' /etc/pam.d/system-auth fi else sed -i '/auth.*include.*system-auth-ac/iauth optional pam_faildelay.so delay=4000000' /etc/pam.d/system-auth fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/accounts_global_setting.sh000066400000000000000000000004261301675746700300340ustar00rootroot00000000000000cat > /etc/pam.d/system-auth-local <<'STOP_HERE' auth include system-auth-ac account include system-auth-ac password include system-auth-ac session include system-auth-ac STOP_HERE ln -sf /etc/pam.d/system-auth-local /etc/pam.d/system-auth scap-security-guide-0.1.31/RHEL/5/templates/static/bash/accounts_logins_logged.sh000066400000000000000000000003261301675746700276520ustar00rootroot00000000000000if [ ! -e /var/log/btmp ]; then >/var/log/btmp chmod 600 /var/log/btmp chown root:root /var/log/btmp fi if [ ! -e /var/log/wtmp ]; then >/var/log/wtmp chmod 664 /var/log/wtmp chown root:root /var/log/wtmp fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/accounts_max_concurrent_login_sessions.sh000066400000000000000000000006101301675746700331770ustar00rootroot00000000000000. /usr/share/scap-security-guide/remediation_functions populate max_concurrent_login_sessions_value if [ $(grep -v "#" /etc/security/limits.conf | grep -c "maxlogins") = "0" ]; then echo "* hard maxlogins ${max_concurrent_login_sessions_value}" >>/etc/security/limits.conf else sed -i 's/.*maxlogins.*/* hard maxlogins ${max_concurrent_login_sessions_value}/' /etc/security/limits.conf fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/accounts_maximum_age_login_defs.sh000066400000000000000000000011131301675746700315130ustar00rootroot00000000000000. /usr/share/scap-security-guide/remediation_functions populate var_accounts_maximum_age_login_defs grep -q ^PASS_MAX_DAYS /etc/login.defs && \ sed -i "s/PASS_MAX_DAYS.*/PASS_MAX_DAYS $var_accounts_maximum_age_login_defs/g" /etc/login.defs if ! [ $? -eq 0 ]; then echo "PASS_MAX_DAYS $var_accounts_maximum_age_login_defs" >> /etc/login.defs fi USERACCT=$(egrep -v "^\+|^#" /etc/passwd | cut -d":" -f1) for SYS_USER in ${USERACCT}; do if [ $(grep -c ${SYS_USER} /etc/shadow) != 0 ]; then passwd -x $var_accounts_maximum_age_login_defs ${SYS_USER} &>/dev/null fi done scap-security-guide-0.1.31/RHEL/5/templates/static/bash/accounts_minimum_age_login_defs.sh000066400000000000000000000011131301675746700315110ustar00rootroot00000000000000. /usr/share/scap-security-guide/remediation_functions populate var_accounts_minimum_age_login_defs grep -q ^PASS_MIN_DAYS /etc/login.defs && \ sed -i "s/PASS_MIN_DAYS.*/PASS_MIN_DAYS $var_accounts_minimum_age_login_defs/g" /etc/login.defs if ! [ $? -eq 0 ]; then echo "PASS_MIN_DAYS $var_accounts_minimum_age_login_defs" >> /etc/login.defs fi USERACCT=$(egrep -v "^\+|^#" /etc/passwd | cut -d":" -f1) for SYS_USER in ${USERACCT}; do if [ $(grep -c ${SYS_USER} /etc/shadow) != 0 ]; then passwd -n $var_accounts_minimum_age_login_defs ${SYS_USER} &>/dev/null fi done scap-security-guide-0.1.31/RHEL/5/templates/static/bash/accounts_no_uid_except_zero.sh000066400000000000000000000002001301675746700307110ustar00rootroot00000000000000for UID0_USER in `cat /etc/passwd | cut -d: -f1,3 | grep :0$ | grep -v ^root: | cut -d: -f1`; do userdel -rf ${UID0_USER} done scap-security-guide-0.1.31/RHEL/5/templates/static/bash/accounts_password_pam_cracklib_dcredit.sh000066400000000000000000000013021301675746700330600ustar00rootroot00000000000000. /usr/share/scap-security-guide/remediation_functions populate var_password_pam_cracklib_dcredit if [ $(grep -c "dcredit=" /etc/pam.d/system-auth) != 0 ]; then sed -i "s/dcredit=[0-9]*/dcredit=$var_password_pam_cracklib_dcredit/" /etc/pam.d/system-auth else sed -i "/password.*pam_cracklib.so/s/$/ dcredit=$var_password_pam_cracklib_dcredit/" /etc/pam.d/system-auth fi if [ -e /etc/pam.d/system-auth-ac ]; then if [ $(grep -c "dcredit=" /etc/pam.d/system-auth-ac) != 0 ]; then sed -i "s/dcredit=[0-9]*/dcredit=$var_password_pam_cracklib_dcredit/" /etc/pam.d/system-auth-ac else sed -i "/password.*pam_cracklib.so/s/$/ dcredit=$var_password_pam_cracklib_dcredit/" /etc/pam.d/system-auth-ac fi fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/accounts_password_pam_cracklib_difok.sh000066400000000000000000000012501301675746700325400ustar00rootroot00000000000000. /usr/share/scap-security-guide/remediation_functions populate var_password_pam_cracklib_difok if [ $(grep -c "difok=" /etc/pam.d/system-auth) != 0 ]; then sed -i "s/difok=[0-9]*/difok=$var_password_pam_cracklib_difok/" /etc/pam.d/system-auth else sed -i "/password.*pam_cracklib.so/s/$/ difok=$var_password_pam_cracklib_difok/" /etc/pam.d/system-auth fi if [ -e /etc/pam.d/system-auth-ac ]; then if [ $(grep -c "difok=" /etc/pam.d/system-auth-ac) != 0 ]; then sed -i "s/difok=[0-9]*/difok=$var_password_pam_cracklib_difok/" /etc/pam.d/system-auth-ac else sed -i "/password.*pam_cracklib.so/s/$/ difok=$var_password_pam_cracklib_difok/" /etc/pam.d/system-auth-ac fi fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/accounts_password_pam_cracklib_lcredit.sh000066400000000000000000000013021301675746700330700ustar00rootroot00000000000000. /usr/share/scap-security-guide/remediation_functions populate var_password_pam_cracklib_lcredit if [ $(grep -c "lcredit=" /etc/pam.d/system-auth) != 0 ]; then sed -i "s/lcredit=[0-9]*/lcredit=$var_password_pam_cracklib_lcredit/" /etc/pam.d/system-auth else sed -i "/password.*pam_cracklib.so/s/$/ lcredit=$var_password_pam_cracklib_lcredit/" /etc/pam.d/system-auth fi if [ -e /etc/pam.d/system-auth-ac ]; then if [ $(grep -c "lcredit=" /etc/pam.d/system-auth-ac) != 0 ]; then sed -i "s/lcredit=[0-9]*/lcredit=$var_password_pam_cracklib_lcredit/" /etc/pam.d/system-auth-ac else sed -i "/password.*pam_cracklib.so/s/$/ lcredit=$var_password_pam_cracklib_lcredit/" /etc/pam.d/system-auth-ac fi fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/accounts_password_pam_cracklib_maxrepeat.sh000066400000000000000000000013331301675746700334340ustar00rootroot00000000000000. /usr/share/scap-security-guide/remediation_functions populate var_password_pam_cracklib_maxrepeat if [ $(grep -c "maxrepeat=" /etc/pam.d/system-auth) != 0 ]; then sed -i "s/maxrepeat=[0-9]*/maxrepeat=$var_password_pam_cracklib_maxrepeat/" /etc/pam.d/system-auth else sed -i "/password.*pam_cracklib.so/s/$/ maxrepeat=$var_password_pam_cracklib_maxrepeat/" /etc/pam.d/system-auth fi if [ -e /etc/pam.d/system-auth-ac ]; then if [ $(grep -c "maxrepeat=" /etc/pam.d/system-auth-ac) != 0 ]; then sed -i "s/maxrepeat=[0-9]*/maxrepeat=$var_password_pam_cracklib_maxrepeat/" /etc/pam.d/system-auth-ac else sed -i "/password.*pam_cracklib.so/s/$/ maxrepeat=$var_password_pam_cracklib_maxrepeat/" /etc/pam.d/system-auth-ac fi fiscap-security-guide-0.1.31/RHEL/5/templates/static/bash/accounts_password_pam_cracklib_minlen.sh000066400000000000000000000012651301675746700327340ustar00rootroot00000000000000. /usr/share/scap-security-guide/remediation_functions populate var_password_pam_cracklib_minlen if [ $(grep -c "minlen=" /etc/pam.d/system-auth) != 0 ]; then sed -i "s/minlen=[0-9]*/minlen=$var_password_pam_cracklib_minlen/" /etc/pam.d/system-auth else sed -i "/password.*pam_cracklib.so/s/$/ minlen=$var_password_pam_cracklib_minlen/" /etc/pam.d/system-auth fi if [ -e /etc/pam.d/system-auth-ac ]; then if [ $(grep -c "minlen=" /etc/pam.d/system-auth-ac) != 0 ]; then sed -i "s/minlen=[0-9]*/minlen=$var_password_pam_cracklib_minlen/" /etc/pam.d/system-auth-ac else sed -i "/password.*pam_cracklib.so/s/$/ minlen=$var_password_pam_cracklib_minlen/" /etc/pam.d/system-auth-ac fi fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/accounts_password_pam_cracklib_ocredit.sh000066400000000000000000000013021301675746700330730ustar00rootroot00000000000000. /usr/share/scap-security-guide/remediation_functions populate var_password_pam_cracklib_ocredit if [ $(grep -c "ocredit=" /etc/pam.d/system-auth) != 0 ]; then sed -i "s/ocredit=[0-9]*/ucredit=$var_password_pam_cracklib_ocredit/" /etc/pam.d/system-auth else sed -i "/password.*pam_cracklib.so/s/$/ ocredit=$var_password_pam_cracklib_ocredit/" /etc/pam.d/system-auth fi if [ -e /etc/pam.d/system-auth-ac ]; then if [ $(grep -c "ocredit=" /etc/pam.d/system-auth-ac) != 0 ]; then sed -i "s/ocredit=[0-9]*/ucredit=$var_password_pam_cracklib_ocredit/" /etc/pam.d/system-auth-ac else sed -i "/password.*pam_cracklib.so/s/$/ ocredit=$var_password_pam_cracklib_ocredit/" /etc/pam.d/system-auth-ac fi fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/accounts_password_pam_cracklib_ucredit.sh000066400000000000000000000013021301675746700331010ustar00rootroot00000000000000. /usr/share/scap-security-guide/remediation_functions populate var_password_pam_cracklib_ucredit if [ $(grep -c "ucredit=" /etc/pam.d/system-auth) != 0 ]; then sed -i "s/ucredit=[0-9]*/ucredit=$var_password_pam_cracklib_ucredit/" /etc/pam.d/system-auth else sed -i "/password.*pam_cracklib.so/s/$/ ucredit=$var_password_pam_cracklib_ucredit/" /etc/pam.d/system-auth fi if [ -e /etc/pam.d/system-auth-ac ]; then if [ $(grep -c "ucredit=" /etc/pam.d/system-auth-ac) != 0 ]; then sed -i "s/ucredit=[0-9]*/ucredit=$var_password_pam_cracklib_ucredit/" /etc/pam.d/system-auth-ac else sed -i "/password.*pam_cracklib.so/s/$/ ucredit=$var_password_pam_cracklib_ucredit/" /etc/pam.d/system-auth-ac fi fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/accounts_password_pam_tally_deny.sh000066400000000000000000000030161301675746700317600ustar00rootroot00000000000000. /usr/share/scap-security-guide/remediation_functions populate var_accounts_password_pam_tally_deny if [ $(grep auth.*required.*pam_tally2 /etc/pam.d/system-auth | grep -c "deny=") != 0 ]; then sed -i "/account.*required.*pam_tally/s/deny=[0-9]*/deny=${var_accounts_password_pam_tally_deny}/" /etc/pam.d/system-auth elif [ $(grep -c "auth.*required.*pam_tally2" /etc/pam.d/system-auth) = 0 ]; then if [ $(grep -c "pam_tally.so" /etc/pam.d/system-auth) != 0 ]; then sed -i "s/pam_tally.so/pam_tally2.so/g" /etc/pam.d/system-auth elif [ $(grep -c "auth.*include.*system-auth-ac" /etc/pam.d/system-auth) != 0 ]; then sed -i 's/\(auth\s*include\s*system-auth-ac\)/auth required pam_tally2.so\n\1/' /etc/pam.d/system-auth elif [ $(grep -c "auth.*pam_unix.so" /etc/pam.d/system-auth) != 0 ]; then sed -i 's/\(auth.*pam_unix.so\)/auth required pam_tally2.so\n\1/' /etc/pam.d/system-auth elif [ $(grep -c "auth.*pam_deny.so" /etc/pam.d/system-auth) != 0 ]; then sed -i 's/\(auth.*pam_deny.so\)/auth required pam_tally2.so\n\1/' /etc/pam.d/system-auth else sed -i ':a;N;$!ba;s/\([\n]*[#]*[\s]*account\)/\nauth required pam_tally2.so\n\1/' /etc/pam.d/system-auth fi sed -i "/auth.*pam_tally/s/$/ deny=${var_accounts_password_pam_tally_deny}/" /etc/pam.d/system-auth else sed -i "/auth.*pam_tally/s/$/ deny=${var_accounts_password_pam_tally_deny}/" /etc/pam.d/system-auth fi if [ ! -e /var/log/tallylog ]; then >/var/log/tallylog fi chmod 640 /var/log/tallylog chown root:root /var/log/tallylog scap-security-guide-0.1.31/RHEL/5/templates/static/bash/accounts_password_reuse_limit.sh000066400000000000000000000021451301675746700313020ustar00rootroot00000000000000. /usr/share/scap-security-guide/remediation_functions populate password_history_retain_number if [ $(egrep -c "password\s*(sufficient|required)\s*(pam_unix.so|pam_pwhistory).*remember" /etc/pam.d/system-auth) != 0 ]; then sed -i "s/remember=[0-9]*/remember=${password_history_retain_number}/" /etc/pam.d/system-auth else if [ $(egrep -c "password.*(pam_unix.so|pam_pwhistory)" /etc/pam.d/system-auth) != 0 ]; then sed -i "/password.*\(pam_unix.so\|pam_pwhistory.so\)/s/$/ remember=${password_history_retain_number}/" /etc/pam.d/system-auth else sed -i "/password.*pam_cracklib.so/ipassword sufficient pam_unix.so remember=${password_history_retain_number} sha512" /etc/pam.d/system-auth fi fi if [ -e /etc/pam.d/system-auth-ac ]; then if [ $(egrep -c "password\s*(sufficient|required)\s*(pam_unix.so|pam_pwhistory).*remember" /etc/pam.d/system-auth-ac) != 0 ]; then sed -i "s/remember=[0-9]*/remember=${password_history_retain_number}/" /etc/pam.d/system-auth-ac else sed -i "/password.*\(pam_unix.so\|pam_pwhistory.so\)/s/$/ remember=${password_history_retain_number}/" /etc/pam.d/system-auth-ac fi fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/accounts_umask.sh000066400000000000000000000004511301675746700261550ustar00rootroot00000000000000. /usr/share/scap-security-guide/remediation_functions populate var_accounts_user_umask egrep -li ^[[:blank:]]*umask `find /etc /root /home/* -maxdepth 1 -type f 2>/dev/null` | while read FILE; do sed -i "s/\([uU][mM][aA][sS][kK]\s*[=]*\s*\)[0-9]*/\1${var_accounts_user_umask}/" "${FILE}" done scap-security-guide-0.1.31/RHEL/5/templates/static/bash/aide_periodic_cron_checking.sh000066400000000000000000000001561301675746700305740ustar00rootroot00000000000000echo "/usr/sbin/aide --config=/etc/aide.conf --check" > /etc/cron.weekly/aide chmod 700 /etc/cron.weekly/aide scap-security-guide-0.1.31/RHEL/5/templates/static/bash/at_access_controlled.sh000066400000000000000000000007611301675746700273140ustar00rootroot00000000000000if [ ! -e [/etc/at.allow ]; then > /etc/at.allow chown root:root /etc/at.allow chmod 0600 /etc/at.allow fi if [ ! -e [/etc/at.deny ]; then SYS_USER=$(cat /etc/passwd | while read entry; do if [ "$(echo ${entry} | cut -d: -f3)" -lt "500" ]; then echo ${entry} | cut -d: -f1 ; fi; done) for USER in `echo $SYS_USER`; do if [ $(grep -c "^${USER}$" /etc/at.deny) = 0 ]; then echo ${USER} | tee -a /etc/at.deny &>/dev/null fi done chown root:root /etc/at.deny chmod 0600 /etc/at.deny fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/at_deny_nonempty.sh000066400000000000000000000004771301675746700265220ustar00rootroot00000000000000SYS_USER=$(cat /etc/passwd | while read entry; do if [ "$(echo ${entry} | cut -d: -f3)" -lt "500" ]; then echo ${entry} | cut -d: -f1 ; fi; done) for USER in `echo $SYS_USER`; do if [ $(grep -c "^${USER}$" /etc/at.deny) = 0 ]; then echo ${USER} | tee -a /etc/at.deny &>/dev/null fi done sed -i '/^$/d' /etc/at.deny scap-security-guide-0.1.31/RHEL/5/templates/static/bash/at_system_accounts.sh000066400000000000000000000004431301675746700270460ustar00rootroot00000000000000SYS_USER=$(cat /etc/passwd | while read entry; do if [ "$(echo ${entry} | cut -d: -f3)" -lt "500" ]; then echo ${entry} | cut -d: -f1 ; fi; done) for USER in `echo $SYS_USER`; do if [ $(grep -c "^${USER}$" /etc/at.deny) = 0 ]; then echo ${USER} | tee -a /etc/at.deny &>/dev/null fi done scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_audit_rules.sh000066400000000000000000000017771301675746700300720ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit/audit.rules" elif [ -e /etc/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit.rules" else exit fi if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${AUDIT_RULES_FILE}"`" = "0" ]; then echo "-w ${AUDIT_RULES_FILE} -p wa -k audit_rules_changes" >>${AUDIT_RULES_FILE} elif [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${AUDIT_RULES_FILE} -p [x]*\(wa\|aw\)"`" = "0" ]; then if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${AUDIT_RULES_FILE} -p "`" = "0" ]; then sed -i "s/\(-w ${AUDIT_RULES_FILE}\)/\1 -p wa/" ${AUDIT_RULES_FILE} else if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${AUDIT_RULES_FILE} -p [xa]*w"`" = "0" ]; then sed -i "s/\(-w ${AUDIT_RULES_FILE} -p \)/\1w/" ${AUDIT_RULES_FILE} fi if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${AUDIT_RULES_FILE} -p [xw]*a"`" = "0" ]; then sed -i "s/\(-w ${AUDIT_RULES_FILE} -p \)/\1a/" ${AUDIT_RULES_FILE} fi fi fi service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_dac_modification_chmod.sh000066400000000000000000000010241301675746700321610ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit/audit.rules" AUDIT_TAG="-k perm_mod" elif [ -e /etc/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit.rules" AUDIT_TAG="" else exit fi if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S chmod '`" = "0" ]; then if [ "`uname -p`" = "x86_64" ]; then echo "-a exit,always -F arch=b64 -S chmod ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} else echo "-a exit,always -F arch=b32 -S chmod ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} fi fi service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_dac_modification_chown.sh000066400000000000000000000014731301675746700322150ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit/audit.rules" AUDIT_TAG="-k perm_mod" elif [ -e /etc/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit.rules" AUDIT_TAG="" else exit fi if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S chown '`" = "0" ]; then if [ "`uname -p`" = "x86_64" ]; then echo "-a exit,always -F arch=b64 -S chown ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} else echo "-a exit,always -F arch=b32 -S chown ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} fi fi if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S chown32 '`" = "0" ]; then if [ "`uname -p`" = "x86_64" ]; then echo "-a exit,always -F arch=b64 -S chown32 ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} else echo "-a exit,always -F arch=b32 -S chown32 ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} fi fi service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_dac_modification_fchmod.sh000066400000000000000000000010271301675746700323320ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit/audit.rules" AUDIT_TAG="-k perm_mod" elif [ -e /etc/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit.rules" AUDIT_TAG="" else exit fi if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S fchmod '`" = "0" ]; then if [ "`uname -p`" = "x86_64" ]; then echo "-a exit,always -F arch=b64 -S fchmod ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} else echo "-a exit,always -F arch=b32 -S fchmod ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} fi fi service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_dac_modification_fchmodat.sh000066400000000000000000000010351301675746700326560ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit/audit.rules" AUDIT_TAG="-k perm_mod" elif [ -e /etc/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit.rules" AUDIT_TAG="" else exit fi if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S fchmodat '`" = "0" ]; then if [ "`uname -p`" = "x86_64" ]; then echo "-a exit,always -F arch=b64 -S fchmodat ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} else echo "-a exit,always -F arch=b32 -S fchmodat ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} fi fi service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_dac_modification_fchown.sh000066400000000000000000000015011301675746700323530ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit/audit.rules" AUDIT_TAG="-k perm_mod" elif [ -e /etc/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit.rules" AUDIT_TAG="" else exit fi if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S fchown '`" = "0" ]; then if [ "`uname -p`" = "x86_64" ]; then echo "-a exit,always -F arch=b64 -S fchown ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} else echo "-a exit,always -F arch=b32 -S fchown ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} fi fi if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S fchown32 '`" = "0" ]; then if [ "`uname -p`" = "x86_64" ]; then echo "-a exit,always -F arch=b64 -S fchown32 ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} else echo "-a exit,always -F arch=b32 -S fchown32 ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} fi fi service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_dac_modification_fchownat.sh000066400000000000000000000010351301675746700327020ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit/audit.rules" AUDIT_TAG="-k perm_mod" elif [ -e /etc/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit.rules" AUDIT_TAG="" else exit fi if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S fchownat '`" = "0" ]; then if [ "`uname -p`" = "x86_64" ]; then echo "-a exit,always -F arch=b64 -S fchownat ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} else echo "-a exit,always -F arch=b32 -S fchownat ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} fi fi service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_dac_modification_fremovexattr.sh000066400000000000000000000010511301675746700336150ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit/audit.rules" AUDIT_TAG="-k perm_mod" elif [ -e /etc/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit.rules" AUDIT_TAG="" else exit fi if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S fremovexattr '`" = "0" ]; then if [ "`uname -p`" = "x86_64" ]; then echo "-a exit,always -F arch=b64 -S fremovexattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} else echo "-a exit,always -F arch=b32 -S fremovexattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} fi fi service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_dac_modification_fsetxattr.sh000066400000000000000000000010401301675746700331110ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit/audit.rules" AUDIT_TAG="-k perm_mod" elif [ -e /etc/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit.rules" AUDIT_TAG="" else exit fi if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S fsetxattr '`" = "0" ]; then if [ "`uname -p`" = "x86_64" ]; then echo "-a exit,always -F arch=b64 -S fsetxattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} else echo "-a exit,always -F arch=b32 -S fsetxattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} fi fi service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_dac_modification_lchown.sh000066400000000000000000000015011301675746700323610ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit/audit.rules" AUDIT_TAG="-k perm_mod" elif [ -e /etc/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit.rules" AUDIT_TAG="" else exit fi if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S lchown '`" = "0" ]; then if [ "`uname -p`" = "x86_64" ]; then echo "-a exit,always -F arch=b64 -S lchown ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} else echo "-a exit,always -F arch=b32 -S lchown ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} fi fi if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S lchown32 '`" = "0" ]; then if [ "`uname -p`" = "x86_64" ]; then echo "-a exit,always -F arch=b64 -S lchown32 ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} else echo "-a exit,always -F arch=b32 -S lchown32 ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} fi fi service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_dac_modification_lremovexattr.sh000066400000000000000000000010511301675746700336230ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit/audit.rules" AUDIT_TAG="-k perm_mod" elif [ -e /etc/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit.rules" AUDIT_TAG="" else exit fi if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S lremovexattr '`" = "0" ]; then if [ "`uname -p`" = "x86_64" ]; then echo "-a exit,always -F arch=b64 -S lremovexattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} else echo "-a exit,always -F arch=b32 -S lremovexattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} fi fi service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_dac_modification_lsetxattr.sh000066400000000000000000000010401301675746700331170ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit/audit.rules" AUDIT_TAG="-k perm_mod" elif [ -e /etc/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit.rules" AUDIT_TAG="" else exit fi if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S lsetxattr '`" = "0" ]; then if [ "`uname -p`" = "x86_64" ]; then echo "-a exit,always -F arch=b64 -S lsetxattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} else echo "-a exit,always -F arch=b32 -S lsetxattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} fi fi service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_dac_modification_removexattr.sh000066400000000000000000000010461301675746700334530ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit/audit.rules" AUDIT_TAG="-k perm_mod" elif [ -e /etc/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit.rules" AUDIT_TAG="" else exit fi if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S removexattr '`" = "0" ]; then if [ "`uname -p`" = "x86_64" ]; then echo "-a exit,always -F arch=b64 -S removexattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} else echo "-a exit,always -F arch=b32 -S removexattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} fi fi service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_dac_modification_setxattr.sh000066400000000000000000000010351301675746700327470ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit/audit.rules" AUDIT_TAG="-k perm_mod" elif [ -e /etc/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit.rules" AUDIT_TAG="" else exit fi if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S setxattr '`" = "0" ]; then if [ "`uname -p`" = "x86_64" ]; then echo "-a exit,always -F arch=b64 -S setxattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} else echo "-a exit,always -F arch=b32 -S setxattr ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} fi fi service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_file_deletion_events.sh000066400000000000000000000010261301675746700317230ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit/audit.rules" AUDIT_TAG="-k delete" elif [ -e /etc/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit.rules" AUDIT_TAG="" else exit fi if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S unlink '`" = "0" ]; then if [ "`uname -p`" != "x86_64" ]; then echo "-a exit,always -F arch=b32 -S unlink ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} else echo "-a exit,always -F arch=b64 -S unlink ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} fi fi service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_file_deletion_events_rmdir.sh000066400000000000000000000010231301675746700331150ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit/audit.rules" AUDIT_TAG="-k delete" elif [ -e /etc/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit.rules" AUDIT_TAG="" else exit fi if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S rmdir '`" = "0" ]; then if [ "`uname -p`" != "x86_64" ]; then echo "-a exit,always -F arch=b32 -S rmdir ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} else echo "-a exit,always -F arch=b64 -S rmdir ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} fi fi service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_kernel_module_loading.sh000066400000000000000000000026261301675746700320660ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit/audit.rules" AUDIT_TAG="-k modules" elif [ -e /etc/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit.rules" AUDIT_TAG="" else exit fi if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S init_module '`" = "0" ]; then if [ "`uname -p`" != "x86_64" ]; then echo "-a exit,always -F arch=b32 -S init_module ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} else echo "-a exit,always -F arch=b64 -S init_module ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} fi fi if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S delete_module '`" = "0" ]; then if [ "`uname -p`" != "x86_64" ]; then echo "-a exit,always -F arch=b32 -S delete_module ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} else echo "-a exit,always -F arch=b64 -S delete_module ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} fi fi for FILE in /sbin/insmod /sbin/rmmod /sbin/modprobe; do if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE}"`" = "0" ]; then echo "-w ${FILE} -p x -k modules" >>${AUDIT_RULES_FILE} elif [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p [wa]*x"`" = "0" ]; then SED_FILE="$(echo ${FILE} | sed 's/\//\\\//g')" if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p "`" = "0" ]; then sed -i "s/\(-w ${SED_FILE}\)/\1 -p x/" ${AUDIT_RULES_FILE} else sed -i "s/\(-w ${SED_FILE} -p \)/\1x/" ${AUDIT_RULES_FILE} fi fi done service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_login_events.sh000066400000000000000000000020231301675746700302270ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit/audit.rules" elif [ -e /etc/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit.rules" else exit fi for FILE in /var/log/faillog /var/log/lastlog; do if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE}"`" = "0" ]; then echo "-w ${FILE} -p wa -k audit_login_events" >>${AUDIT_RULES_FILE} elif [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p [x]*\(wa\|aw\)"`" = "0" ]; then SED_FILE="$(echo ${FILE} | sed 's/\//\\\//g')" if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p "`" = "0" ]; then sed -i "s/\(-w ${SED_FILE}\)/\1 -p wa/" ${AUDIT_RULES_FILE} else if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p [xa]*w"`" = "0" ]; then sed -i "s/\(-w ${SED_FILE} -p \)/\1w/" ${AUDIT_RULES_FILE} fi if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p [xw]*a"`" = "0" ]; then sed -i "s/\(-w ${SED_FILE} -p \)/\1a/" ${AUDIT_RULES_FILE} fi fi fi done service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_sched_setparam.sh000066400000000000000000000010671301675746700305240ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit/audit.rules" AUDIT_TAG="-k set_scheduler_parameters" elif [ -e /etc/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit.rules" AUDIT_TAG="" else exit fi # check for realtime capabilities if [ `lsmod | grep -ic jiffies` = 0 ]; then if [ "`uname -p`" != "x86_64" ]; then echo "-a exit,always -F arch=b32 -S sched_setparam ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} else echo "-a exit,always -F arch=b64 -S sched_setparam ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} fi fi service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_sched_setscheduler.sh000066400000000000000000000010741301675746700314000ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit/audit.rules" AUDIT_TAG="-k set_scheduler_setting" elif [ -e /etc/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit.rules" AUDIT_TAG="" else exit fi # check for realtime capabilities if [ `lsmod | grep -ic jiffies` = 0 ]; then if [ "`uname -p`" != "x86_64" ]; then echo "-a exit,always -F arch=b32 -S sched_setscheduler ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} else echo "-a exit,always -F arch=b64 -S sched_setscheduler ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} fi fi service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_setdomainname.sh000066400000000000000000000007251301675746700303660ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit/audit.rules" AUDIT_TAG="-k set_domainname" elif [ -e /etc/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit.rules" AUDIT_TAG="" else exit fi if [ "`uname -p`" != "x86_64" ]; then echo "-a exit,always -F arch=b32 -S setdomainname ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} else echo "-a exit,always -F arch=b64 -S setdomainname ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} fi service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_sethostname.sh000066400000000000000000000007171301675746700300750ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit/audit.rules" AUDIT_TAG="-k set_hostname" elif [ -e /etc/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit.rules" AUDIT_TAG="" else exit fi if [ "`uname -p`" != "x86_64" ]; then echo "-a exit,always -F arch=b32 -S sethostname ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} else echo "-a exit,always -F arch=b64 -S sethostname ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} fi service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_time_adjtimex.sh000066400000000000000000000010461301675746700303620ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit/audit.rules" AUDIT_TAG="-k audit_time_rules" elif [ -e /etc/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit.rules" AUDIT_TAG="" else exit fi if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S adjtimex '`" = "0" ]; then if [ "`uname -p`" != "x86_64" ]; then echo "-a exit,always -F arch=b32 -S adjtimex ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} else echo "-a exit,always -F arch=b64 -S adjtimex ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} fi fi service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_time_settimeofday.sh000066400000000000000000000010621301675746700312500ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit/audit.rules" AUDIT_TAG="-k audit_time_rules" elif [ -e /etc/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit.rules" AUDIT_TAG="" else exit fi if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S settimeofday '`" = "0" ]; then if [ "`uname -p`" != "x86_64" ]; then echo "-a exit,always -F arch=b32 -S settimeofday ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} else echo "-a exit,always -F arch=b64 -S settimeofday ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} fi fi service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_time_stime.sh000066400000000000000000000007551301675746700277040ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit/audit.rules" AUDIT_TAG="-k audit_time_rules" elif [ -e /etc/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit.rules" AUDIT_TAG="" else exit fi if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c ' -S stime '`" = "0" ]; then if [ "`uname -p`" != "x86_64" ]; then echo "-a exit,always -F arch=b32 -S stime ${AUDIT_TAG}" >>${AUDIT_RULES_FILE} # stime is not supported on 64-bit. fi fi service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_unsuccessful_file_creat.sh000066400000000000000000000021701301675746700324350ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then if [ "`grep " -S creat " /etc/audit/audit.rules | grep -v '#' | grep -c '\-F exit=-EACCES'`" = "0" ]; then if [ "`uname -p`" != "x86_64" ]; then echo "-a exit,always -F arch=b32 -S creat -F exit=-EACCES -k access" >>/etc/audit/audit.rules else echo "-a exit,always -F arch=b64 -S creat -F exit=-EACCES -k access" >>/etc/audit/audit.rules fi fi if [ "`grep " -S creat " /etc/audit/audit.rules | grep -v '#' | grep -c '\-F exit=-EPERM'`" = "0" ]; then if [ "`uname -p`" != "x86_64" ]; then echo "-a exit,always -F arch=b32 -S creat -F exit=-EPERM -k access" >>/etc/audit/audit.rules else echo "-a exit,always -F arch=b64 -S creat -F exit=-EPERM -k access" >>/etc/audit/audit.rules fi fi elif [ -e /etc/audit.rules ]; then if [ "`grep " -S creat " /etc/audit.rules | grep -v '#' | grep -c '\success=0'`" = "0" ]; then if [ "`uname -p`" != "x86_64" ]; then echo "-a exit,always -F arch=b32 -S creat -F success=0" >>/etc/audit.rules else echo "-a exit,always -F arch=b64 -S creat -F success=0" >>/etc/audit.rules fi fi else exit fi service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_unsuccessful_file_ftruncate.sh000066400000000000000000000022341301675746700333330ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then if [ "`grep " -S ftruncate " /etc/audit/audit.rules | grep -v '#' | grep -c '\-F exit=-EACCES'`" = "0" ]; then if [ "`uname -p`" != "x86_64" ]; then echo "-a exit,always -F arch=b32 -S ftruncate -F exit=-EACCES -k access" >>/etc/audit/audit.rules else echo "-a exit,always -F arch=b64 -S ftruncate -F exit=-EACCES -k access" >>/etc/audit/audit.rules fi fi if [ "`grep " -S ftruncate " /etc/audit/audit.rules | grep -v '#' | grep -c '\-F exit=-EPERM'`" = "0" ]; then if [ "`uname -p`" != "x86_64" ]; then echo "-a exit,always -F arch=b32 -S ftruncate -F exit=-EPERM -k access" >>/etc/audit/audit.rules else echo "-a exit,always -F arch=b64 -S ftruncate -F exit=-EPERM -k access" >>/etc/audit/audit.rules fi fi elif [ -e /etc/audit.rules ]; then if [ "`grep " -S ftruncate " /etc/audit.rules | grep -v '#' | grep -c '\success=0'`" = "0" ]; then if [ "`uname -p`" != "x86_64" ]; then echo "-a exit,always -F arch=b32 -S ftruncate -F success=0" >>/etc/audit.rules else echo "-a exit,always -F arch=b64 -S ftruncate -F success=0" >>/etc/audit.rules fi fi else exit fi service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_unsuccessful_file_open.sh000066400000000000000000000021571301675746700323050ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then if [ "`grep " -S open " /etc/audit/audit.rules | grep -v '#' | grep -c '\-F exit=-EACCES'`" = "0" ]; then if [ "`uname -p`" != "x86_64" ]; then echo "-a exit,always -F arch=b32 -S open -F exit=-EACCES -k access" >>/etc/audit/audit.rules else echo "-a exit,always -F arch=b64 -S open -F exit=-EACCES -k access" >>/etc/audit/audit.rules fi fi if [ "`grep " -S open " /etc/audit/audit.rules | grep -v '#' | grep -c '\-F exit=-EPERM'`" = "0" ]; then if [ "`uname -p`" != "x86_64" ]; then echo "-a exit,always -F arch=b32 -S open -F exit=-EPERM -k access" >>/etc/audit/audit.rules else echo "-a exit,always -F arch=b64 -S open -F exit=-EPERM -k access" >>/etc/audit/audit.rules fi fi elif [ -e /etc/audit.rules ]; then if [ "`grep " -S open " /etc/audit.rules | grep -v '#' | grep -c '\success=0'`" = "0" ]; then if [ "`uname -p`" != "x86_64" ]; then echo "-a exit,always -F arch=b32 -S open -F success=0" >>/etc/audit.rules else echo "-a exit,always -F arch=b64 -S open -F success=0" >>/etc/audit.rules fi fi else exit fi service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_unsuccessful_file_openat.sh000066400000000000000000000022011301675746700326200ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then if [ "`grep " -S openat " /etc/audit/audit.rules | grep -v '#' | grep -c '\-F exit=-EACCES'`" = "0" ]; then if [ "`uname -p`" != "x86_64" ]; then echo "-a exit,always -F arch=b32 -S openat -F exit=-EACCES -k access" >>/etc/audit/audit.rules else echo "-a exit,always -F arch=b64 -S openat -F exit=-EACCES -k access" >>/etc/audit/audit.rules fi fi if [ "`grep " -S openat " /etc/audit/audit.rules | grep -v '#' | grep -c '\-F exit=-EPERM'`" = "0" ]; then if [ "`uname -p`" != "x86_64" ]; then echo "-a exit,always -F arch=b32 -S openat -F exit=-EPERM -k access" >>/etc/audit/audit.rules else echo "-a exit,always -F arch=b64 -S openat -F exit=-EPERM -k access" >>/etc/audit/audit.rules fi fi elif [ -e /etc/audit.rules ]; then if [ "`grep " -S openat " /etc/audit.rules | grep -v '#' | grep -c '\success=0'`" = "0" ]; then if [ "`uname -p`" != "x86_64" ]; then echo "-a exit,always -F arch=b32 -S openat -F success=0" >>/etc/audit.rules else echo "-a exit,always -F arch=b64 -S openat -F success=0" >>/etc/audit.rules fi fi else exit fi service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_unsuccessful_file_truncate.sh000066400000000000000000000022231301675746700331630ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then if [ "`grep " -S truncate " /etc/audit/audit.rules | grep -v '#' | grep -c '\-F exit=-EACCES'`" = "0" ]; then if [ "`uname -p`" != "x86_64" ]; then echo "-a exit,always -F arch=b32 -S truncate -F exit=-EACCES -k access" >>/etc/audit/audit.rules else echo "-a exit,always -F arch=b64 -S truncate -F exit=-EACCES -k access" >>/etc/audit/audit.rules fi fi if [ "`grep " -S truncate " /etc/audit/audit.rules | grep -v '#' | grep -c '\-F exit=-EPERM'`" = "0" ]; then if [ "`uname -p`" != "x86_64" ]; then echo "-a exit,always -F arch=b32 -S truncate -F exit=-EPERM -k access" >>/etc/audit/audit.rules else echo "-a exit,always -F arch=b64 -S truncate -F exit=-EPERM -k access" >>/etc/audit/audit.rules fi fi elif [ -e /etc/audit.rules ]; then if [ "`grep " -S truncate " /etc/audit.rules | grep -v '#' | grep -c '\success=0'`" = "0" ]; then if [ "`uname -p`" != "x86_64" ]; then echo "-a exit,always -F arch=b32 -S truncate -F success=0" >>/etc/audit.rules else echo "-a exit,always -F arch=b64 -S truncate -F success=0" >>/etc/audit.rules fi fi else exit fi service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_usergroup_creation.sh000066400000000000000000000025311301675746700314560ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit/audit.rules" elif [ -e /etc/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit.rules" else exit fi for FILE in /usr/sbin/useradd /usr/sbin/groupadd; do if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE}"`" = "0" ]; then echo "-w ${FILE} -p x -k audit_account_creation" >>${AUDIT_RULES_FILE} elif [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p [wa]*x"`" = "0" ]; then SED_FILE="$(echo ${FILE} | sed 's/\//\\\//g')" if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p "`" = "0" ]; then sed -i "s/\(-w ${SED_FILE}\)/\1 -p x/" ${AUDIT_RULES_FILE} else sed -i "s/\(-w ${SED_FILE} -p \)/\1x/" ${AUDIT_RULES_FILE} fi fi done for FILE in /etc/group /etc/passwd /etc/gshadow /etc/shadow; do if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE}"`" = "0" ]; then echo "-w ${FILE} -p a -k audit_account_creation" >>${AUDIT_RULES_FILE} elif [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p [wx]*a"`" = "0" ]; then SED_FILE="$(echo ${FILE} | sed 's/\//\\\//g')" if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p "`" = "0" ]; then sed -i "s/\(-w ${SED_FILE}\)/\1 -p a/" ${AUDIT_RULES_FILE} else sed -i "s/\(-w ${SED_FILE} -p \)/\1a/" ${AUDIT_RULES_FILE} fi fi done service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_usergroup_disabling.sh000066400000000000000000000013061301675746700316050ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit/audit.rules" elif [ -e /etc/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit.rules" else exit fi if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w /usr/bin/passwd"`" = "0" ]; then echo "-w /usr/bin/passwd -p x -k audit_account_changes" >>${AUDIT_RULES_FILE} elif [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w /usr/bin/passwd -p [wa]*x"`" = "0" ]; then if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w /usr/bin/passwd -p "`" = "0" ]; then sed -i "s/\(-w \/usr\/bin\/passwd\)/\1 -p x/" ${AUDIT_RULES_FILE} else sed -i "s/\(-w \/usr\/bin\/passwd -p \)/\1x/" ${AUDIT_RULES_FILE} fi fi service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_usergroup_modification.sh000066400000000000000000000025271301675746700323240ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit/audit.rules" elif [ -e /etc/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit.rules" else exit fi for FILE in /usr/sbin/usermod /usr/sbin/groupmod; do if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE}"`" = "0" ]; then echo "-w ${FILE} -p x -k audit_account_changes" >>${AUDIT_RULES_FILE} elif [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p [wa]*x"`" = "0" ]; then SED_FILE="$(echo ${FILE} | sed 's/\//\\\//g')" if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p "`" = "0" ]; then sed -i "s/\(-w ${SED_FILE}\)/\1 -p x/" ${AUDIT_RULES_FILE} else sed -i "s/\(-w ${SED_FILE} -p \)/\1x/" ${AUDIT_RULES_FILE} fi fi done for FILE in /etc/group /etc/passwd /etc/gshadow /etc/shadow; do if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE}"`" = "0" ]; then echo "-w ${FILE} -p w -k audit_account_changes" >>${AUDIT_RULES_FILE} elif [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p [xa]*w"`" = "0" ]; then SED_FILE="$(echo ${FILE} | sed 's/\//\\\//g')" if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p "`" = "0" ]; then sed -i "s/\(-w ${SED_FILE}\)/\1 -p w/" ${AUDIT_RULES_FILE} else sed -i "s/\(-w ${SED_FILE} -p \)/\1w/" ${AUDIT_RULES_FILE} fi fi done service auditd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/audit_rules_usergroup_termination.sh000066400000000000000000000014141301675746700322020ustar00rootroot00000000000000if [ -e /etc/audit/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit/audit.rules" elif [ -e /etc/audit.rules ]; then AUDIT_RULES_FILE="/etc/audit.rules" else exit fi for FILE in /usr/sbin/userdel /usr/sbin/groupdel; do if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE}"`" = "0" ]; then echo "-w ${FILE} -p x -k audit_account_changes" >>${AUDIT_RULES_FILE} elif [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p [wa]*x"`" = "0" ]; then SED_FILE="$(echo ${FILE} | sed 's/\//\\\//g')" if [ "`grep -v '#' ${AUDIT_RULES_FILE} | grep -c "\-w ${FILE} -p "`" = "0" ]; then sed -i "s/\(-w ${SED_FILE}\)/\1 -p x/" ${AUDIT_RULES_FILE} else sed -i "s/\(-w ${SED_FILE} -p \)/\1x/" ${AUDIT_RULES_FILE} fi fi done service auditd restart 1>/dev/null auditd_data_retention_audit_processing_failure.sh000066400000000000000000000014331301675746700345430ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/5/templates/static/bash. /usr/share/scap-security-guide/remediation_functions populate var_auditd_disk_error_action if [ -e /etc/audit/auditd.conf ]; then AUDITD_CONF_FILE="/etc/audit/auditd.conf" elif [ -e /etc/auditd.conf ]; then AUDITD_CONF_FILE="/etc/auditd.conf" else exit fi grep -q ^disk_error_action ${AUDITD_CONF_FILE} && \ sed -i "s/disk_error_action.*/disk_error_action = $var_auditd_disk_error_action/g" ${AUDITD_CONF_FILE} if ! [ $? -eq 0 ]; then echo "disk_error_action = $var_auditd_disk_error_action" >> ${AUDITD_CONF_FILE} fi grep -q ^disk_full_action ${AUDITD_CONF_FILE} && \ sed -i "s/disk_full_action.*/disk_full_action = $var_auditd_disk_error_action/g" ${AUDITD_CONF_FILE} if ! [ $? -eq 0 ]; then echo "disk_full_action = $var_auditd_disk_error_action" >> ${AUDITD_CONF_FILE} fi auditd_data_retention_audit_storage_failure.sh000066400000000000000000000006161301675746700340350ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/5/templates/static/bashif [ -e /etc/audit/auditd.conf ]; then AUDITD_CONF_FILE="/etc/audit/auditd.conf" elif [ -e /etc/auditd.conf ]; then AUDITD_CONF_FILE="/etc/auditd.conf" else exit fi if [ "$(grep -v "#" ${AUDITD_CONF_FILE} | grep -c space_left_action)" != "0" ]; then sed -i 's/space_left_action.*/space_left_action = syslog/' ${AUDITD_CONF_FILE} else echo "space_left_action = syslog">>${AUDITD_CONF_FILE} fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/banner_etc_issue.sh000066400000000000000000000003301301675746700264420ustar00rootroot00000000000000. /usr/share/scap-security-guide/remediation_functions populate system_login_banner_text echo $system_login_banner_text | sed -e 's/\[\\s\\n\][+|*]/ /g' -e 's/\&/\&/g' -e 's/\\//g' -e 's/ - /\n- /g' >/etc/issue scap-security-guide-0.1.31/RHEL/5/templates/static/bash/banner_gui_enabled.sh000066400000000000000000000010161301675746700267170ustar00rootroot00000000000000. /usr/share/scap-security-guide/remediation_functions populate gui_login_banner_text gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type bool --set /apps/gdm/simple-greeter/banner_message_enable true &>/dev/null gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type string --set /apps/gdm/simple-greeter/banner_message_text "$(echo $gui_login_banner_text | sed -e 's/\[\\s\\n\][+|*]/ /g' -e 's/\&/\&/g' -e 's/\\//g' -e 's/ - /\n- /g')" &>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/baseline_device_files.sh000066400000000000000000000075461301675746700274350ustar00rootroot00000000000000# Generate a device file baseline find / -type b -o -type c 2>/dev/null | sort > /var/log/device-file-list chmod 640 /var/log/device-file-list chown root:root /var/log/device-file-list # Generate a weekly cron job to check the device file baseline and report differences cat > /etc/cron.weekly/baseline_checker.sh <<'STOP_HERE' #!/bin/sh echo "Baseline check started on $(date +"%m-%d-%Y") at $(date +"%H:%M:%S")" | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log echo "Gathering current baseline." | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log rm -f /tmp/*BASELINE.tmp /tmp/*list.tmp find / -perm -4000 2>/dev/null | sort > /tmp/suid-file-list.tmp find / -perm -2000 2>/dev/null | sort > /tmp/sgid-file-list.tmp find / -type b -o -type c 2>/dev/null | sort > /tmp/device-file-list.tmp echo "Comparing the current baseline with the last known good configuration." | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log diff /var/log/suid-file-list /tmp/suid-file-list.tmp > /tmp/SUID_BASELINE.tmp diff /var/log/sgid-file-list /tmp/sgid-file-list.tmp > /tmp/SGID_BASELINE.tmp diff /var/log/device-file-list /tmp/device-file-list.tmp > /tmp/DEVICE_BASELINE.tmp if [ -s /tmp/SUID_BASELINE.tmp ]; then if [ $(grep -c "^>" /tmp/SUID_BASELINE.tmp) != 0 ]; then echo "The following files were detected to have the suid bit added:" | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log grep "^>" /tmp/SUID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log fi if [ $(grep -c "^<" /tmp/SUID_BASELINE.tmp) != 0 ]; then echo "The following files were detected to have the suid bit removed:" | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log grep "^<" /tmp/SUID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log fi fi if [ -s /tmp/SGID_BASELINE.tmp ]; then if [ $(grep -c "^>" /tmp/SGID_BASELINE.tmp) != 0 ]; then echo "The following files were detected to have the sgid bit added:" | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log grep "^>" /tmp/SGID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log fi if [ $(grep -c "^<" /tmp/SGID_BASELINE.tmp) != 0 ]; then echo "The following files were detected to have the sgid bit removed:" | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log grep "^<" /tmp/SGID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log fi fi if [ -s /tmp/DEVICE_BASELINE.tmp ]; then if [ $(grep -c "^>" /tmp/DEVICE_BASELINE.tmp) != 0 ]; then echo "The following device files were detected to have been added:" | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log grep "^>" /tmp/DEVICE_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log fi if [ $(grep -c "^<" /tmp/DEVICE_BASELINE.tmp) != 0 ]; then echo "The following device files were detected to have removed:" | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log grep "^<" /tmp/DEVICE_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log fi fi rm -f /tmp/*BASELINE.tmp /tmp/*list.tmp echo "Baseline check completed on $(date +"%m-%d-%Y") at $(date +"%H:%M:%S")" | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log echo "####################################################################" | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log chmod 640 /var/log/baseline.log chown root:root /var/log/baseline.log STOP_HERE chmod 700 /etc/cron.weekly/baseline_checker.sh chown root:root /etc/cron.weekly/baseline_checker.sh scap-security-guide-0.1.31/RHEL/5/templates/static/bash/baseline_sgid_files.sh000066400000000000000000000075351301675746700271220ustar00rootroot00000000000000# Generate a sgid file baseline find / -perm -2000 -type f 2>/dev/null | sort > /var/log/sgid-file-list chmod 640 /var/log/sgid-file-list chown root:root /var/log/sgid-file-list # Generate a weekly cron job to check the sgid file baseline and report differences cat > /etc/cron.weekly/baseline_checker.sh <<'STOP_HERE' #!/bin/sh echo "Baseline check started on $(date +"%m-%d-%Y") at $(date +"%H:%M:%S")" | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log echo "Gathering current baseline." | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log rm -f /tmp/*BASELINE.tmp /tmp/*list.tmp find / -perm -4000 2>/dev/null | sort > /tmp/suid-file-list.tmp find / -perm -2000 2>/dev/null | sort > /tmp/sgid-file-list.tmp find / -type b -o -type c 2>/dev/null | sort > /tmp/device-file-list.tmp echo "Comparing the current baseline with the last known good configuration." | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log diff /var/log/suid-file-list /tmp/suid-file-list.tmp > /tmp/SUID_BASELINE.tmp diff /var/log/sgid-file-list /tmp/sgid-file-list.tmp > /tmp/SGID_BASELINE.tmp diff /var/log/device-file-list /tmp/device-file-list.tmp > /tmp/DEVICE_BASELINE.tmp if [ -s /tmp/SUID_BASELINE.tmp ]; then if [ $(grep -c "^>" /tmp/SUID_BASELINE.tmp) != 0 ]; then echo "The following files were detected to have the suid bit added:" | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log grep "^>" /tmp/SUID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log fi if [ $(grep -c "^<" /tmp/SUID_BASELINE.tmp) != 0 ]; then echo "The following files were detected to have the suid bit removed:" | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log grep "^<" /tmp/SUID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log fi fi if [ -s /tmp/SGID_BASELINE.tmp ]; then if [ $(grep -c "^>" /tmp/SGID_BASELINE.tmp) != 0 ]; then echo "The following files were detected to have the sgid bit added:" | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log grep "^>" /tmp/SGID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log fi if [ $(grep -c "^<" /tmp/SGID_BASELINE.tmp) != 0 ]; then echo "The following files were detected to have the sgid bit removed:" | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log grep "^<" /tmp/SGID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log fi fi if [ -s /tmp/DEVICE_BASELINE.tmp ]; then if [ $(grep -c "^>" /tmp/DEVICE_BASELINE.tmp) != 0 ]; then echo "The following device files were detected to have been added:" | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log grep "^>" /tmp/DEVICE_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log fi if [ $(grep -c "^<" /tmp/DEVICE_BASELINE.tmp) != 0 ]; then echo "The following device files were detected to have removed:" | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log grep "^<" /tmp/DEVICE_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log fi fi rm -f /tmp/*BASELINE.tmp /tmp/*list.tmp echo "Baseline check completed on $(date +"%m-%d-%Y") at $(date +"%H:%M:%S")" | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log echo "####################################################################" | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log chmod 640 /var/log/baseline.log chown root:root /var/log/baseline.log STOP_HERE chmod 700 /etc/cron.weekly/baseline_checker.sh chown root:root /etc/cron.weekly/baseline_checker.sh scap-security-guide-0.1.31/RHEL/5/templates/static/bash/baseline_suid_files.sh000066400000000000000000000075351301675746700271400ustar00rootroot00000000000000# Generate a suid file baseline find / -perm -4000 -type f 2>/dev/null | sort > /var/log/suid-file-list chmod 640 /var/log/suid-file-list chown root:root /var/log/suid-file-list # Generate a weekly cron job to check the suid file baseline and report differences cat > /etc/cron.weekly/baseline_checker.sh <<'STOP_HERE' #!/bin/sh echo "Baseline check started on $(date +"%m-%d-%Y") at $(date +"%H:%M:%S")" | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log echo "Gathering current baseline." | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log rm -f /tmp/*BASELINE.tmp /tmp/*list.tmp find / -perm -4000 2>/dev/null | sort > /tmp/suid-file-list.tmp find / -perm -2000 2>/dev/null | sort > /tmp/sgid-file-list.tmp find / -type b -o -type c 2>/dev/null | sort > /tmp/device-file-list.tmp echo "Comparing the current baseline with the last known good configuration." | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log diff /var/log/suid-file-list /tmp/suid-file-list.tmp > /tmp/SUID_BASELINE.tmp diff /var/log/sgid-file-list /tmp/sgid-file-list.tmp > /tmp/SGID_BASELINE.tmp diff /var/log/device-file-list /tmp/device-file-list.tmp > /tmp/DEVICE_BASELINE.tmp if [ -s /tmp/SUID_BASELINE.tmp ]; then if [ $(grep -c "^>" /tmp/SUID_BASELINE.tmp) != 0 ]; then echo "The following files were detected to have the suid bit added:" | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log grep "^>" /tmp/SUID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log fi if [ $(grep -c "^<" /tmp/SUID_BASELINE.tmp) != 0 ]; then echo "The following files were detected to have the suid bit removed:" | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log grep "^<" /tmp/SUID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log fi fi if [ -s /tmp/SGID_BASELINE.tmp ]; then if [ $(grep -c "^>" /tmp/SGID_BASELINE.tmp) != 0 ]; then echo "The following files were detected to have the sgid bit added:" | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log grep "^>" /tmp/SGID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log fi if [ $(grep -c "^<" /tmp/SGID_BASELINE.tmp) != 0 ]; then echo "The following files were detected to have the sgid bit removed:" | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log grep "^<" /tmp/SGID_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log fi fi if [ -s /tmp/DEVICE_BASELINE.tmp ]; then if [ $(grep -c "^>" /tmp/DEVICE_BASELINE.tmp) != 0 ]; then echo "The following device files were detected to have been added:" | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log grep "^>" /tmp/DEVICE_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log fi if [ $(grep -c "^<" /tmp/DEVICE_BASELINE.tmp) != 0 ]; then echo "The following device files were detected to have removed:" | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log grep "^<" /tmp/DEVICE_BASELINE.tmp | awk '{ print $2 }' | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log fi fi rm -f /tmp/*BASELINE.tmp /tmp/*list.tmp echo "Baseline check completed on $(date +"%m-%d-%Y") at $(date +"%H:%M:%S")" | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log echo "####################################################################" | tee -a /var/log/baseline.log echo -e \\n | tee -a /var/log/baseline.log chmod 640 /var/log/baseline.log chown root:root /var/log/baseline.log STOP_HERE chmod 700 /etc/cron.weekly/baseline_checker.sh chown root:root /etc/cron.weekly/baseline_checker.sh scap-security-guide-0.1.31/RHEL/5/templates/static/bash/bootloader_audit_argument.sh000066400000000000000000000003331301675746700303570ustar00rootroot00000000000000if [ $(grep -v '#' /boot/grub/grub.conf | grep kernel | grep -c audit=) = 0 ]; then sed -i '/^[ |\t]*kernel/s/$/ audit=1/' /boot/grub/grub.conf else sed -i '/^[ |\t]*kernel/s/audit=./audit=1/' /boot/grub/grub.conf fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/bootloader_nousb_argument.sh000066400000000000000000000004421301675746700304000ustar00rootroot00000000000000USB_KEYBOARD=$(grep 'Product=' /proc/bus/usb/devices 2>/dev/null| egrep -ic '(ps2 to usb adapter|keyboard|kvm|sc reader)') if [ "${USB_KEYBOARD}" = "0" ]; then sed -i '/^[ |\t]*kernel/s/$/ nousb/' /boot/grub/grub.conf # else # A USB keyboard was detected so this fix has been skipped. fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/bootloader_password.sh000066400000000000000000000013441301675746700272140ustar00rootroot00000000000000if [ -e /tmp/GRUB.TMP ]; then /sbin/grub-md5-crypt < /tmp/GRUB.TMP &> /tmp/GRUB.TMP.out md5crypt=`tail -n1 /tmp/GRUB.TMP.out` if [ -f /boot/grub/grub.conf ] && [ ! -h /boot/grub/grub.conf ]; then if [ "$(grep -c '^password' /boot/grub/grub.conf)" = "0" ]; then sed -i "/timeout/apassword --md5 ${md5crypt}" /boot/grub/grub.conf else sed -i "s/^password .*/password --md5 ${md5crypt}/" /boot/grub/grub.conf fi fi if [ -f /etc/grub.conf ] && [ ! -h /etc/grub.conf ]; then if [ "$(grep -c '^password' /etc/grub.conf)" = "0" ]; then sed -i "/timeout/apassword --md5 ${md5crypt}" /etc/grub.conf else sed -i "s/^password .*/password --md5 ${md5crypt}/" /etc/grub.conf fi fi rm -f /tmp/GRUB.TMP /tmp/GRUB.TMP.out fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/bootloader_password_hash.sh000066400000000000000000000013441301675746700302170ustar00rootroot00000000000000if [ -e /tmp/GRUB.TMP ]; then /sbin/grub-md5-crypt < /tmp/GRUB.TMP &> /tmp/GRUB.TMP.out md5crypt=`tail -n1 /tmp/GRUB.TMP.out` if [ -f /boot/grub/grub.conf ] && [ ! -h /boot/grub/grub.conf ]; then if [ "$(grep -c '^password' /boot/grub/grub.conf)" = "0" ]; then sed -i "/timeout/apassword --md5 ${md5crypt}" /boot/grub/grub.conf else sed -i "s/^password .*/password --md5 ${md5crypt}/" /boot/grub/grub.conf fi fi if [ -f /etc/grub.conf ] && [ ! -h /etc/grub.conf ]; then if [ "$(grep -c '^password' /etc/grub.conf)" = "0" ]; then sed -i "/timeout/apassword --md5 ${md5crypt}" /etc/grub.conf else sed -i "s/^password .*/password --md5 ${md5crypt}/" /etc/grub.conf fi fi rm -f /tmp/GRUB.TMP /tmp/GRUB.TMP.out fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/cron_access_controlled.sh000066400000000000000000000010031301675746700276370ustar00rootroot00000000000000if [ ! -e [/etc/cron.allow ]; then > /etc/cron.allow chown root:root /etc/cron.allow chmod 0600 /etc/cron.allow fi if [ ! -e [/etc/cron.deny ]; then SYS_USER=$(cat /etc/passwd | while read entry; do if [ "$(echo ${entry} | cut -d: -f3)" -lt "500" ]; then echo ${entry} | cut -d: -f1 ; fi; done) for USER in `echo $SYS_USER`; do if [ $(grep -c "^${USER}$" /etc/cron.deny) = 0 ]; then echo ${USER} | tee -a /etc/cron.deny &>/dev/null fi done chown root:root /etc/cron.deny chmod 0600 /etc/cron.deny fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/cron_system_accounts.sh000066400000000000000000000004471301675746700274070ustar00rootroot00000000000000SYS_USER=$(cat /etc/passwd | while read entry; do if [ "$(echo ${entry} | cut -d: -f3)" -lt "500" ]; then echo ${entry} | cut -d: -f1 ; fi; done) for USER in `echo $SYS_USER`; do if [ $(grep -c "^${USER}$" /etc/cron.deny) = 0 ]; then echo ${USER} | tee -a /etc/cron.deny &>/dev/null fi done scap-security-guide-0.1.31/RHEL/5/templates/static/bash/dhcp_client_disable_ddns.sh000066400000000000000000000004151301675746700301050ustar00rootroot00000000000000if [ -e /etc/dhclient.conf ]; then if [ $(grep -c "do-forward-updates false;" /etc/dhclient.conf) = 0 ]; then echo "do-forward-updates false;" | tee -a /etc/dhclient.conf &>/dev/null fi else echo "do-forward-updates false;" | tee /etc/dhclient.conf &>/dev/null fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/dir_perms_world_writable_sticky_bits.sh000066400000000000000000000001551301675746700326320ustar00rootroot00000000000000find / /home /var /var/log /var/log/audit -xdev -perm -2 ! -perm -1000 -type d 2>/dev/null | xargs chmod o-w scap-security-guide-0.1.31/RHEL/5/templates/static/bash/disable_ctrlaltdel_reboot.sh000066400000000000000000000002231301675746700303220ustar00rootroot00000000000000sed -i 's/^.*:ctrlaltdel:.*\(shutdown\|reboot\).*/ca:nil:ctrlaltdel:\/usr\/bin\/logger -p security.info "Ctrl-Alt-Del was pressed"/' /etc/inittab scap-security-guide-0.1.31/RHEL/5/templates/static/bash/disable_users_coredumps.sh000066400000000000000000000000731301675746700300430ustar00rootroot00000000000000echo "* hard core 0" >> /etc/security/limits.conf scap-security-guide-0.1.31/RHEL/5/templates/static/bash/ensure_gpgcheck_never_disabled.sh000066400000000000000000000004011301675746700313130ustar00rootroot00000000000000grep -R gpgcheck /etc/yum.repos.d/* /etc/yum.conf /root/rpmrc /usr/lib/rpm/redhat/rpmrc /usr/lib/rpm/rpmrc /etc/rpmrc 2>/dev/null | grep -v 'gpgcheck=1' | cut -d: -f1 | sort -u | while read YUM_FILE; do sed -i 's/gpgcheck=.*/gpgcheck=1/g' ${YUM_FILE} done scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_group_owner_grub_conf.sh000066400000000000000000000000561301675746700305300ustar00rootroot00000000000000chgrp root /etc/grub.conf /boot/grub/grub.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_aliases.sh000066400000000000000000000001411301675746700300410ustar00rootroot00000000000000chown :root /etc/postfix/aliases /etc/postfix/aliases.db /etc/aliases /etc/aliases.db 2>/dev/nullscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_aliases_files.sh000066400000000000000000000001531301675746700312260ustar00rootroot00000000000000grep "/" /etc/aliases /etc/aliases.db | grep -v "#" | grep ^/ | sed 's/.*[\s|\t]\//\//' | xargs chown :rootscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_audio_devices.sh000066400000000000000000000005211301675746700312250ustar00rootroot00000000000000chown :root /dev/audio* /dev/snd/* if [[ "`uname -r`" = "2.6.9"* ]]; then sed -i 's/\(^audio\*:[a-z]*:\)[a-z]*:/\1sys:/' /etc/udev/permissions.d/50-udev.permissions elif [[ "`uname -r`" = "2.6.18"* ]]; then sed -i '/^ [0-9]* /s/.*/ 0600 root.root/' /etc/security/console.perms.d/50-default.perms fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_audit_log.sh000066400000000000000000000003451301675746700303750ustar00rootroot00000000000000if [ -e /etc/audit/auditd.conf ]; then grep ^log_file /etc/audit/auditd.conf | awk '{ print $3 }' | xargs chown :root if [ -e /etc/auditd.conf ]; then grep ^log_file /etc/auditd.conf | awk '{ print $3 }' | xargs chown :root fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_audit_tools.sh000066400000000000000000000001411301675746700307460ustar00rootroot00000000000000chown :root /sbin/auditctl /sbin/auditd /sbin/ausearch /sbin/aureport /sbin/autrace /sbin/audispdscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_bin_traceroute.sh000066400000000000000000000000331301675746700314250ustar00rootroot00000000000000chown :root /bin/traceroutescap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_binary_dirs.sh000066400000000000000000000001551301675746700307320ustar00rootroot00000000000000find /etc /bin /usr/bin /usr/lbin /usr/usb /sbin /usr/sbin -follow -gid +499 2>/dev/null | xargs chown :root scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_core_dump_dir.sh000066400000000000000000000001051301675746700312330ustar00rootroot00000000000000grep path.*/ /etc/kdump.conf | awk '{ print $2 }' | xargs chown :rootscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_crontab_dirs.sh000066400000000000000000000001671301675746700311010ustar00rootroot00000000000000chown :root /etc/cron.d /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly /var/spool/cron 2>/dev/nullscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_crontab_files.sh000066400000000000000000000001041301675746700312310ustar00rootroot00000000000000chown :root /etc/crontab /etc/cron.d/* /var/spool/cron/* 2>/dev/nullscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_etc_at_allow.sh000066400000000000000000000000311301675746700310530ustar00rootroot00000000000000chown :root /etc/at.allowscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_etc_at_deny.sh000066400000000000000000000000301301675746700306730ustar00rootroot00000000000000chown :root /etc/at.denyscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_etc_cron_allow.sh000066400000000000000000000000331301675746700314120ustar00rootroot00000000000000chown :root /etc/cron.allowscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_etc_cron_deny.sh000066400000000000000000000000321301675746700312320ustar00rootroot00000000000000chown :root /etc/cron.denyscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_etc_cups_printers_conf.sh000066400000000000000000000000431301675746700331610ustar00rootroot00000000000000chown :root /etc/cups/printers.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_etc_exports.sh000066400000000000000000000000301301675746700307540ustar00rootroot00000000000000chown :root /etc/exportsscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_etc_hosts.sh000066400000000000000000000000261301675746700304150ustar00rootroot00000000000000chown :root /etc/hostsscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_etc_ldap_conf.sh000066400000000000000000000000321301675746700311770ustar00rootroot00000000000000chown :root /etc/ldap.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_etc_nsswitch_conf.sh000066400000000000000000000000361301675746700321250ustar00rootroot00000000000000chown :root /etc/nsswitch.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_etc_ntp_conf.sh000066400000000000000000000000311301675746700310570ustar00rootroot00000000000000chown :root /etc/ntp.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_etc_resolv_conf.sh000066400000000000000000000000341301675746700315730ustar00rootroot00000000000000chown :root /etc/resolv.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_etc_samba_smb_conf.sh000066400000000000000000000000371301675746700322100ustar00rootroot00000000000000chown :root /etc/samba/smb.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_etc_samba_tdb.sh000066400000000000000000000000701301675746700311700ustar00rootroot00000000000000chown :root /etc/samba/passdb.tdb /etc/samba/secrets.tdbscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_etc_securetty.sh000066400000000000000000000000321301675746700313010ustar00rootroot00000000000000chown :root /etc/securettyscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_etc_security_access_conf.sh000066400000000000000000000000451301675746700334530ustar00rootroot00000000000000chown :root /etc/security/access.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_etc_services.sh000066400000000000000000000000311301675746700310740ustar00rootroot00000000000000chown :root /etc/servicesscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_etc_shadow.sh000066400000000000000000000000261301675746700305420ustar00rootroot00000000000000chgrp root /etc/shadowscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_etc_skel.sh000066400000000000000000000000271301675746700302140ustar00rootroot00000000000000chown :root /etc/skel/*scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_etc_sysctl_conf.sh000066400000000000000000000000341301675746700316020ustar00rootroot00000000000000chown :root /etc/sysctl.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_etc_syslog_conf.sh000066400000000000000000000000341301675746700316010ustar00rootroot00000000000000chown :root /etc/syslog.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_etc_xinetd_conf.sh000066400000000000000000000000341301675746700315540ustar00rootroot00000000000000chown :root /etc/xinetd.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_exports_dirs.sh000066400000000000000000000000711301675746700311470ustar00rootroot00000000000000cat /etc/exports | awk '{ print $1 }' | xargs chown :rootscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_grub_conf.sh000066400000000000000000000000321301675746700303630ustar00rootroot00000000000000chown :root /etc/grub.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_ldap_cacerts.sh000066400000000000000000000001361301675746700310500ustar00rootroot00000000000000grep -i '^tls_cacert' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs chown -R :rootscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_ldap_certs.sh000066400000000000000000000001341301675746700305420ustar00rootroot00000000000000grep -i '^tls_cert' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs chown -R :rootscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_groupowner_ldap_keys.sh000066400000000000000000000001331301675746700303740ustar00rootroot00000000000000grep -i '^tls_key' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs chown -R :rootscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_aliases.sh000066400000000000000000000001401301675746700267630ustar00rootroot00000000000000chown root /etc/postfix/aliases /etc/postfix/aliases.db /etc/aliases /etc/aliases.db 2>/dev/nullscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_aliases_files.sh000066400000000000000000000001521301675746700301500ustar00rootroot00000000000000grep "/" /etc/aliases /etc/aliases.db | grep -v "#" | grep ^/ | sed 's/.*[\s|\t]\//\//' | xargs chown rootscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_audio_devices.sh000066400000000000000000000000411301675746700301450ustar00rootroot00000000000000chown root /dev/audio* /dev/snd/*scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_audit_log.sh000066400000000000000000000003431301675746700273160ustar00rootroot00000000000000if [ -e /etc/audit/auditd.conf ]; then grep ^log_file /etc/audit/auditd.conf | awk '{ print $3 }' | xargs chown root if [ -e /etc/auditd.conf ]; then grep ^log_file /etc/auditd.conf | awk '{ print $3 }' | xargs chown root fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_audit_tools.sh000066400000000000000000000001401301675746700276700ustar00rootroot00000000000000chown root /sbin/auditctl /sbin/auditd /sbin/ausearch /sbin/aureport /sbin/autrace /sbin/audispdscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_bin_traceroute.sh000066400000000000000000000000321301675746700303470ustar00rootroot00000000000000chown root /bin/traceroutescap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_binary_dirs.sh000066400000000000000000000001541301675746700276540ustar00rootroot00000000000000find /etc /bin /usr/bin /usr/lbin /usr/usb /sbin /usr/sbin -follow -uid +499 2>/dev/null | xargs chown root scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_core_dump_dir.sh000066400000000000000000000000761301675746700301650ustar00rootroot00000000000000grep path.*/ /etc/kdump.conf | awk '{ print $2 }' | chown rootscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_crontab_dirs.sh000066400000000000000000000001661301675746700300230ustar00rootroot00000000000000chown root /etc/cron.d /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly /var/spool/cron 2>/dev/nullscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_crontab_files.sh000066400000000000000000000001031301675746700301530ustar00rootroot00000000000000chown root /etc/crontab /etc/cron.d/* /var/spool/cron/* 2>/dev/nullscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_etc_at_allow.sh000066400000000000000000000000301301675746700277750ustar00rootroot00000000000000chown root /etc/at.allowscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_etc_at_deny.sh000066400000000000000000000000271301675746700276240ustar00rootroot00000000000000chown root /etc/at.denyscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_etc_cron_allow.sh000066400000000000000000000000321301675746700303340ustar00rootroot00000000000000chown root /etc/cron.allowscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_etc_cron_deny.sh000066400000000000000000000000311301675746700301540ustar00rootroot00000000000000chown root /etc/cron.denyscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_etc_cups_printers_conf.sh000066400000000000000000000000421301675746700321030ustar00rootroot00000000000000chown root /etc/cups/printers.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_etc_exports.sh000066400000000000000000000000271301675746700277050ustar00rootroot00000000000000chown root /etc/exportsscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_etc_hosts.sh000066400000000000000000000000251301675746700273370ustar00rootroot00000000000000chown root /etc/hostsscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_etc_ldap_conf.sh000066400000000000000000000000311301675746700301210ustar00rootroot00000000000000chown root /etc/ldap.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_etc_nsswitch_conf.sh000066400000000000000000000000351301675746700310470ustar00rootroot00000000000000chown root /etc/nsswitch.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_etc_ntp_conf.sh000066400000000000000000000000301301675746700300010ustar00rootroot00000000000000chown root /etc/ntp.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_etc_resolv_conf.sh000066400000000000000000000000331301675746700305150ustar00rootroot00000000000000chown root /etc/resolv.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_etc_samba_smb_conf.sh000066400000000000000000000000361301675746700311320ustar00rootroot00000000000000chown root /etc/samba/smb.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_etc_samba_tdb.sh000066400000000000000000000000671301675746700301210ustar00rootroot00000000000000chown root /etc/samba/passdb.tdb /etc/samba/secrets.tdbscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_etc_securetty.sh000066400000000000000000000000311301675746700302230ustar00rootroot00000000000000chown root /etc/securettyscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_etc_security_access_conf.sh000066400000000000000000000000441301675746700323750ustar00rootroot00000000000000chown root /etc/security/access.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_etc_services.sh000066400000000000000000000000301301675746700300160ustar00rootroot00000000000000chown root /etc/servicesscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_etc_shadow.sh000066400000000000000000000000261301675746700274650ustar00rootroot00000000000000chown root /etc/shadowscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_etc_skel.sh000066400000000000000000000000261301675746700271360ustar00rootroot00000000000000chown root /etc/skel/*scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_etc_sysctl_conf.sh000066400000000000000000000000331301675746700305240ustar00rootroot00000000000000chown root /etc/sysctl.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_etc_syslog_conf.sh000066400000000000000000000000331301675746700305230ustar00rootroot00000000000000chown root /etc/syslog.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_etc_xinetd_conf.sh000066400000000000000000000000331301675746700304760ustar00rootroot00000000000000chown root /etc/xinetd.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_exports_dirs.sh000066400000000000000000000000701301675746700300710ustar00rootroot00000000000000cat /etc/exports | awk '{ print $1 }' | xargs chown rootscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_grub_conf.sh000066400000000000000000000000561301675746700273140ustar00rootroot00000000000000chown root /etc/grub.conf /boot/grub/grub.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_ldap_cacerts.sh000066400000000000000000000001351301675746700277720ustar00rootroot00000000000000grep -i '^tls_cacert' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs chown -R rootscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_ldap_certs.sh000066400000000000000000000001331301675746700274640ustar00rootroot00000000000000grep -i '^tls_cert' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs chown -R rootscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_owner_ldap_keys.sh000066400000000000000000000001321301675746700273160ustar00rootroot00000000000000grep -i '^tls_key' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs chown -R rootscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_aliases.sh000066400000000000000000000001371301675746700302120ustar00rootroot00000000000000chmod 644 /etc/postfix/aliases /etc/postfix/aliases.db /etc/aliases /etc/aliases.db 2>/dev/nullscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_aliases_files.sh000066400000000000000000000001511301675746700313700ustar00rootroot00000000000000grep "/" /etc/aliases /etc/aliases.db | grep -v "#" | grep ^/ | sed 's/.*[\s|\t]\//\//' | xargs chmod 755scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_audio_devices.sh000066400000000000000000000001621301675746700313720ustar00rootroot00000000000000chmod 660 /dev/audio* /dev/snd/* sed -i '/[audio|snd]/s/MODE="[0-9]*"/MODE="660"/' /etc/udev/rules.d/50-udev.rulesscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_audit_log.sh000066400000000000000000000003431301675746700305370ustar00rootroot00000000000000if [ -e /etc/audit/auditd.conf ]; then grep ^log_file /etc/audit/auditd.conf | awk '{ print $3 }' | xargs chmod 640 elif [ -e /etc/auditd.conf ]; then grep ^log_file /etc/auditd.conf | awk '{ print $3 }' | xargs chmod 640 fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_audit_tools.sh000066400000000000000000000001371301675746700311170ustar00rootroot00000000000000chmod 750 /sbin/auditctl /sbin/auditd /sbin/ausearch /sbin/aureport /sbin/autrace /sbin/audispdscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_binary_dirs.sh000066400000000000000000000001701301675746700310730ustar00rootroot00000000000000find /etc /bin /usr/bin /usr/lbin /usr/usb /sbin /usr/sbin -follow -perm -20 -o -perm -2 2>/dev/null | xargs chmod go-w scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_core_dump_dir.sh000066400000000000000000000001031301675746700313750ustar00rootroot00000000000000grep path.*/ /etc/kdump.conf | awk '{ print $2 }' | xargs chmod 700scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_cron_files.sh000066400000000000000000000001421301675746700307100ustar00rootroot00000000000000chmod 0700 /etc/cron.daily/* /etc/cron.hourly/* /etc/cron.monthly/* /etc/cron.weekly/* 2>/dev/nullscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_cron_log_files.sh000066400000000000000000000001041301675746700315470ustar00rootroot00000000000000grep ^cron /etc/syslog.conf | awk '{ print $2 }' | xargs chmod 0600 scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_crontab_dirs.sh000066400000000000000000000001661301675746700312440ustar00rootroot00000000000000chmod 755 /etc/cron.d /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly /var/spool/cron 2>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_crontab_files.sh000066400000000000000000000001021301675746700313730ustar00rootroot00000000000000chmod 600 /etc/crontab /etc/cron.d/* /var/spool/cron/* 2>/dev/nullscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_etc_samba_smb_conf.sh000066400000000000000000000000361301675746700323530ustar00rootroot00000000000000chmod 0644 /etc/samba/smb.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_etc_samba_tdb.sh000066400000000000000000000000671301675746700313420ustar00rootroot00000000000000chmod 0600 /etc/samba/passdb.tdb /etc/samba/secrets.tdbscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_etc_skel.sh000066400000000000000000000000261301675746700303570ustar00rootroot00000000000000chmod 0644 /etc/skel/*scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_etc_sysctl_conf.sh000066400000000000000000000000341301675746700317460ustar00rootroot00000000000000chmod 0600 /etc/sysctl.conf scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_etc_xinetd_conf.sh000066400000000000000000000000531301675746700317210ustar00rootroot00000000000000chmod 0640 /etc/xinetd.conf /etc/xinetd.d/*scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_etc_xinetd_dir.sh000066400000000000000000000000311301675746700315460ustar00rootroot00000000000000chmod 0755 /etc/xinet.d/*scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_aliases.sh000066400000000000000000000001521301675746700320670ustar00rootroot00000000000000setfacl --remove-all /etc/aliases /etc/aliases.db /etc/postfix/aliases /etc/postfix/aliases.db 2>/dev/nullscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_aliases_files.sh000066400000000000000000000001201301675746700332440ustar00rootroot00000000000000grep / /etc/aliases | grep -v "#" | sed s/^[^\/]*// | xargs setfacl --remove-allscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_audio_devices.sh000066400000000000000000000000671301675746700332560ustar00rootroot00000000000000setfacl --remove-all /dev/audio* /dev/snd/* 2>/dev/nullscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_audit_log.sh000066400000000000000000000003671301675746700324250ustar00rootroot00000000000000if [ -e /etc/audit/auditd.conf ]; then grep "^log_file" /etc/audit/auditd.conf | sed s/^[^\/]*// | xargs setfacl --remove-all elif [ -e /etc/auditd.conf ]; then grep "^log_file" /etc/auditd.conf | sed s/^[^\/]*// | xargs setfacl --remove-all fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_audit_tools.sh000066400000000000000000000001521301675746700327740ustar00rootroot00000000000000setfacl --remove-all /sbin/auditctl /sbin/auditd /sbin/ausearch /sbin/aureport /sbin/autrace /sbin/audispdscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_bin_traceroute.sh000066400000000000000000000000441301675746700334530ustar00rootroot00000000000000setfacl --remove-all /bin/traceroutescap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_binary_dirs.sh000066400000000000000000000001171301675746700327540ustar00rootroot00000000000000setfacl -RLb /etc /bin /usr/bin /usr/lbin /usr/usb /sbin /usr/sbin 2>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_core_dump_dir.sh000066400000000000000000000001311301675746700332560ustar00rootroot00000000000000grep path /etc/kdump.conf | grep -v "#" | awk '{ print $2 }' | xargs setfacl --remove-allscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_cron_log_files.sh000066400000000000000000000001321301675746700334300ustar00rootroot00000000000000grep cron /etc/syslog.conf | grep -v "#" | awk '{ print $2 }' | xargs setfacl --remove-allscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_crontab_dirs.sh000066400000000000000000000002151301675746700331170ustar00rootroot00000000000000setfacl --remove-all /etc/cron.d /etc/crontab /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly /var/spool/cron 2>/dev/nullscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_crontab_files.sh000066400000000000000000000002431301675746700332610ustar00rootroot00000000000000find /etc/cron.d /etc/crontab /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly /var/spool/cron -type f 2>/dev/null | xargs setfacl --remove-allscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_etc_at_allow.sh000066400000000000000000000000421301675746700331010ustar00rootroot00000000000000setfacl --remove-all /etc/at.allowscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_etc_at_deny.sh000066400000000000000000000000411301675746700327210ustar00rootroot00000000000000setfacl --remove-all /etc/at.denyscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_etc_cron_allow.sh000066400000000000000000000000441301675746700334400ustar00rootroot00000000000000setfacl --remove-all /etc/cron.allowscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_etc_cron_deny.sh000066400000000000000000000000431301675746700332600ustar00rootroot00000000000000setfacl --remove-all /etc/cron.denyfile_permissions_extended_etc_cups_printers_conf.sh000066400000000000000000000000541301675746700351300ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/5/templates/static/bashsetfacl --remove-all /etc/cups/printers.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_etc_exports.sh000066400000000000000000000000411301675746700330020ustar00rootroot00000000000000setfacl --remove-all /etc/exportsscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_etc_group.sh000066400000000000000000000000371301675746700324370ustar00rootroot00000000000000setfacl --remove-all /etc/groupscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_etc_gshadow.sh000066400000000000000000000000411301675746700327320ustar00rootroot00000000000000setfacl --remove-all /etc/gshadowscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_etc_hosts.sh000066400000000000000000000000371301675746700324430ustar00rootroot00000000000000setfacl --remove-all /etc/hostsscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_etc_ldap_conf.sh000066400000000000000000000000431301675746700332250ustar00rootroot00000000000000setfacl --remove-all /etc/ldap.conffile_permissions_extended_etc_news_hosts_nntp_nolimit.sh000066400000000000000000000000611301675746700362070ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/5/templates/static/bashsetfacl --remove-all /etc/news/hosts.nntp.nolimitfile_permissions_extended_etc_news_incoming_conf.sh000066400000000000000000000000541301675746700350670ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/5/templates/static/bashsetfacl --remove-all /etc/news/incoming.conffile_permissions_extended_etc_news_infeed_conf.sh000066400000000000000000000000521301675746700345140ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/5/templates/static/bashsetfacl --remove-all /etc/news/infeed.conffile_permissions_extended_etc_news_nnrp_access.sh000066400000000000000000000000521301675746700345530ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/5/templates/static/bashsetfacl --remove-all /etc/news/nnrp.accessfile_permissions_extended_etc_news_passwd_nntp.sh000066400000000000000000000000521301675746700346150ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/5/templates/static/bashsetfacl --remove-all /etc/news/passwd.nntpfile_permissions_extended_etc_nsswitch_conf.sh000066400000000000000000000000471301675746700340740ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/5/templates/static/bashsetfacl --remove-all /etc/nsswitch.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_etc_ntp_conf.sh000066400000000000000000000000421301675746700331050ustar00rootroot00000000000000setfacl --remove-all /etc/ntp.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_etc_passwd.sh000066400000000000000000000000401301675746700325760ustar00rootroot00000000000000setfacl --remove-all /etc/passwdscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_etc_resolv_conf.sh000066400000000000000000000000451301675746700336210ustar00rootroot00000000000000setfacl --remove-all /etc/resolv.conffile_permissions_extended_etc_samba_smb_conf.sh000066400000000000000000000000501301675746700341500ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/5/templates/static/bashsetfacl --remove-all /etc/samba/smb.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_etc_samba_tdb.sh000066400000000000000000000001011301675746700332070ustar00rootroot00000000000000setfacl --remove-all /etc/samba/passdb.tdb /etc/samba/secrets.tdbfile_permissions_extended_etc_security_access_conf.sh000066400000000000000000000000561301675746700354220ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/5/templates/static/bashsetfacl --remove-all /etc/security/access.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_etc_services.sh000066400000000000000000000000421301675746700331220ustar00rootroot00000000000000setfacl --remove-all /etc/servicesscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_etc_shadow.sh000066400000000000000000000000401301675746700325620ustar00rootroot00000000000000setfacl --remove-all /etc/shadowscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_etc_skel.sh000066400000000000000000000000671301675746700322440ustar00rootroot00000000000000find /etc/skel 2>/dev/null | xargs setfacl --remove-allscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_etc_sysctl_conf.sh000066400000000000000000000000451301675746700336300ustar00rootroot00000000000000setfacl --remove-all /etc/sysctl.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_etc_syslog_conf.sh000066400000000000000000000000451301675746700336270ustar00rootroot00000000000000setfacl --remove-all /etc/syslog.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_etc_xinetd_conf.sh000066400000000000000000000000451301675746700336020ustar00rootroot00000000000000setfacl --remove-all /etc/xinetd.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_etc_xinetd_dir.sh000066400000000000000000000001031301675746700334260ustar00rootroot00000000000000find /etc/xinetd.d -type f 2>/dev/null | xargs setfacl --remove-allscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_ftpusers.sh000066400000000000000000000001141301675746700323170ustar00rootroot00000000000000setfacl --remove-all /etc/ftpusers /etc/vsftpd.ftpusers /etc/vsftpd/ftpusersfile_permissions_extended_global_initialization_files.sh000066400000000000000000000002361301675746700361230ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/5/templates/static/bashsetfacl --remove-all /etc/bashrc /etc/csh.cshrc /etc/csh.login /etc/csh.logout /etc/environment /etc/ksh.kshrc /etc/profile /etc/suid_profile /etc/profile.d/*scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_grub_conf.sh000066400000000000000000000000701301675746700324110ustar00rootroot00000000000000setfacl --remove-all /etc/grub.conf /boot/grub/grub.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_home_dirs.sh000066400000000000000000000001121301675746700324130ustar00rootroot00000000000000cut -d: -f6 /etc/passwd | sort -u | xargs setfacl --remove-all 2>/dev/nullscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_home_files.sh000066400000000000000000000000731301675746700325620ustar00rootroot00000000000000find /home -type f 2>/dev/null | xargs setfacl --remove-allscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_ldap_cacerts.sh000066400000000000000000000001441301675746700330730ustar00rootroot00000000000000grep -i '^tls_cacert' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs setfacl --remove-allscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_ldap_certs.sh000066400000000000000000000001421301675746700325650ustar00rootroot00000000000000grep -i '^tls_cert' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs setfacl --remove-allscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_ldap_keys.sh000066400000000000000000000001411301675746700324170ustar00rootroot00000000000000grep -i '^tls_key' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs setfacl --remove-allscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_library_dirs.sh000066400000000000000000000000541301675746700331340ustar00rootroot00000000000000setfacl -RLb --remove-all /usr/lib/* /lib/* file_permissions_extended_local_initialization_files.sh000066400000000000000000000005501301675746700357540ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/5/templates/static/bashcut -d: -f6 /etc/passwd | sort -u | xargs -n1 -IDIR find DIR -maxdepth 1 -name .bashrc -o -name .bash_login -o -name .bash_logout -o -name .bash_profile -o -name .cshrc -o -name .kshrc -o -name .login -o -name .logout -o -name .profile -o -name .env -o -name .dtprofile -o -name .dispatch -o -name .emacs -o -name .exrc 2>/dev/null | xargs setfacl --remove-allscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_man_pages.sh000066400000000000000000000001061301675746700323770ustar00rootroot00000000000000setfacl -RLb /usr/share/man/* /usr/share/info/* /usr/share/infopage/* scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_mib_files.sh000066400000000000000000000000731301675746700324010ustar00rootroot00000000000000find / -name *.mib 2>/dev/null | xargs setfacl --remove-allscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_root_dir.sh000066400000000000000000000000251301675746700322660ustar00rootroot00000000000000setfacl -RLb /root/* file_permissions_extended_run_control_scripts.sh000066400000000000000000000001121301675746700344760ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/5/templates/static/bashfind /etc/rc* /etc/init.d -type f 2>/dev/null | xargs setfacl --remove-allscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_shell_files.sh000066400000000000000000000000541301675746700327400ustar00rootroot00000000000000cat /etc/shells | xargs setfacl --remove-allscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_smtp_logs.sh000066400000000000000000000001421301675746700324540ustar00rootroot00000000000000egrep "(\*.crit|mail\.[^n][^/]*)" /etc/syslog.conf | sed 's/^[^/]*//' | xargs setfacl --remove-allscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_snmpd_conf.sh000066400000000000000000000001001301675746700325650ustar00rootroot00000000000000find / -name snmpd.conf 2>/dev/null | xargs setfacl --remove-allscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_usr_sbin_dir.sh000066400000000000000000000000311301675746700331240ustar00rootroot00000000000000setfacl -RLb /usr/sbin/* scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_var_log.sh000066400000000000000000000000301301675746700320720ustar00rootroot00000000000000setfacl -RLb /var/log/* scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_var_spool_at.sh000066400000000000000000000000421301675746700331340ustar00rootroot00000000000000setfacl --remove-all /var/spool/atscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_extended_var_yp.sh000066400000000000000000000000271301675746700317470ustar00rootroot00000000000000setfacl -RLb /var/yp/* file_permissions_extended_xauthority_files.sh000066400000000000000000000002231301675746700337700ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/5/templates/static/bashcut -d: -f6 /etc/passwd | sort -u | xargs -n1 -IDIR find DIR -maxdepth 1 -name .Xauthority -o -name .xauth 2>/dev/null | xargs setfacl --remove-allscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_ftpusers.sh000066400000000000000000000001161301675746700304410ustar00rootroot00000000000000chmod 0640 /etc/ftpusers /etc/vsftpd.ftpusers /etc/vsftpd/ftpusers 2>/dev/nullfile_permissions_global_initialization_files.sh000066400000000000000000000002411301675746700342370ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/5/templates/static/bashchmod -R 0644 /etc/bashrc /etc/csh.cshrc /etc/csh.login /etc/csh.logout /etc/environment /etc/ksh.kshrc /etc/profile /etc/suid_profile /etc/profile.d 2>/dev/nullscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_grub_conf.sh000066400000000000000000000000561301675746700305350ustar00rootroot00000000000000chmod 0600 /etc/grub.conf /boot/grub/grub.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_home_files.sh000066400000000000000000000001661301675746700307050ustar00rootroot00000000000000find /root /home/* -perm -1 -o -perm -2 -o -perm -4 -o -perm -20 2>/dev/null | xargs -I entry chmod o-rwx,g-w "entry" scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_ldap_cacerts.sh000066400000000000000000000003431301675746700312140ustar00rootroot00000000000000KEY_PATH="`grep -i '^tls_cacert' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }'`" if [ -d "${KEY_PATH}" ]; then chmod 755 "${KEY_PATH}" chmod 644 "${KEY_PATH}"/* elif [ -e "${KEY_PATH}" ]; then chmod 644 "${KEY_PATH}" fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_ldap_certs.sh000066400000000000000000000001321301675746700307040ustar00rootroot00000000000000grep -i '^tls_cert' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs chmod -R 644scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_ldap_keys.sh000066400000000000000000000001321301675746700305370ustar00rootroot00000000000000grep -i '^tls_key' /etc/ldap.conf | grep -v "#" | awk '{ print $2 }' | xargs chmod -R 600 scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_library_dirs.sh000066400000000000000000000001201301675746700312460ustar00rootroot00000000000000find /lib /usr/lib -follow -perm -20 -o -perm -2 2>/dev/null | xargs chmod go-w file_permissions_local_initialization_files.sh000066400000000000000000000006421301675746700340760ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/5/templates/static/bashfind /root /home -maxdepth 2 -type f \( -perm -o+r -o -perm -o+w -o -perm -o+x -o -perm -g+w -o -perm -g+x \) -a \( -name \.bashrc -o -name \.bash_login -o -name \.bash_logout -o -name \.bash_profile -o -name \.cshrc -o -name \.kshrc -o -name \.login -o -name \.logout -o -name \.profile -o -name \.env -o -name \.dtprofile -o -name \.dispatch -o -name \.emacs -o -name \.exrc \) 2>/dev/null | xargs chmod o-rwx,g-wx scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_root_dir.sh000066400000000000000000000001351301675746700304100ustar00rootroot00000000000000grep ^root: /etc/passwd | awk -F: ' { print $6 }' | xargs -I entry chmod g-rwx,o-rwx "entry" scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_snmpd_conf.sh000066400000000000000000000000751301675746700307200ustar00rootroot00000000000000find / -name snmpd.conf 2>/dev/null | xargs chmod ugo-x,go-wrfile_permissions_unauthorized_world_writable.sh000066400000000000000000000001211301675746700343240ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/5/templates/static/bashfind / /var /home -xdev -follow -type f -perm -002 2>/dev/null | xargs chmod o-w scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_ungroupowned.sh000066400000000000000000000001311301675746700313170ustar00rootroot00000000000000find / /home /var /var/log /var/log/audit -xdev -nogroup 2>/dev/null | xargs chown :root scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_usr_bin_ldd.sh000066400000000000000000000000271301675746700310530ustar00rootroot00000000000000chmod a-x /usr/bin/ldd scap-security-guide-0.1.31/RHEL/5/templates/static/bash/file_permissions_var_log.sh000066400000000000000000000003671301675746700302270ustar00rootroot00000000000000find /var/log -follow -type f ! -name wtmp 2>/dev/null | xargs chmod o-rwx,g-wx,u-x # The following corrects the permission mask set for /var/log/rpmpkgs. if [ -e /etc/cron.daily/rpm ]; then sed -i '/rpmpkgs/s/0644/0640/' /etc/cron.daily/rpm fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/ftp_default_umask.sh000066400000000000000000000012401301675746700266300ustar00rootroot00000000000000if [ "$(rpm -q krb5-workstation &>/dev/null; echo $?)" = "0" ]; then if [ "$(grep server_args /etc/xinetd.d/gssftp | grep -v "#" | grep -c "\-u 077")" = "0" ]; then sed -i '/server_args/s/$/ -u 077/' /etc/xinetd.d/gssftp fi fi if [ "$(rpm -q vsftpd &>/dev/null; echo $?)" = "0" ]; then if [ "$(grep -c local_umask /etc/vsftpd/vsftpd.conf)" = "0" ]; then echo "local_umask=077" >> /etc/vsftpd/vsftpd.conf else sed -i '/local_umask/s/=.*/=077/' /etc/vsftpd/vsftpd.conf fi if [ "$(grep -c anon_umask /etc/vsftpd/vsftpd.conf)" = "0" ]; then echo "anon_umask=077" >> /etc/vsftpd/vsftpd.conf else sed -i '/anon_umask/s/=.*/=077/' /etc/vsftpd/vsftpd.conf fi fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/ftp_enable_warning_banner.sh000066400000000000000000000016271301675746700303150ustar00rootroot00000000000000. /usr/share/scap-security-guide/remediation_functions populate ftp_login_banner_text if [ -e /etc/xinetd.d/gssftp ]; then if [ "`egrep -c '^(\s|\t)banner' /etc/xinetd.d/gssftp`" = "0" ]; then sed -i "/^}$/i\\\tbanner\t\t= /etc/issue" /etc/xinetd.d/gssftp else GSSFTP_BANNER_FILE="`egrep '^(\s|\t)banner' /etc/xinetd.d/gssftp | awk '{ print $3 }'`" echo $ftp_login_banner_text | sed -e 's/\[\\s\\n\][+|*]/ /g' -e 's/\&/\&/g' -e 's/\\//g' -e 's/ - /\n- /g' >"${GSSFTP_BANNER_FILE}" fi fi if [ -e /etc/vsftpd/vsftpd.conf ]; then if [ "`egrep -c '^banner_file' /etc/vsftpd/vsftpd.conf`" = "0" ]; then echo "banner_file=/etc/issue" >> /etc/vsftpd/vsftpd.conf else VSFTPD_BANNER_FILE="`egrep '^banner_file' /etc/vsftpd/vsftpd.conf | awk -F= '{ print $2 }'`" echo $ftp_login_banner_text | sed -e 's/\[\\s\\n\][+|*]/ /g' -e 's/\&/\&/g' -e 's/\\//g' -e 's/ - /\n- /g' >"${VSFTPD_BANNER_FILE}" fi fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/ftp_ftpusers_file_empty.sh000066400000000000000000000015241301675746700301010ustar00rootroot00000000000000SYS_USER=$(cat /etc/passwd | while read entry; do if [ "$(echo ${entry} | cut -d: -f3)" -lt "500" ]; then echo ${entry} | cut -d: -f1 ; fi; done) if [ "$(rpm -q krb5-workstation &>/dev/null; echo $?)" = "0" ]; then if [ ! -e /etc/ftpusers ]; then >/etc/ftpusers chmod 0640 /etc/ftpusers chown root:root /etc/ftpusers fi for USER in `echo $SYS_USER`; do if [ $(grep -c "^${USER}$" /etc/ftpusers) = 0 ]; then echo ${USER} | tee -a /etc/ftpusers &>/dev/null fi done fi if [ "$(rpm -q vsftpd &>/dev/null; echo $?)" = "0" ]; then if [ ! -e /etc/vsftpd/ftpusers ]; then >/etc/vsftpd/ftpusers chmod 0640 /etc/vsftpd/ftpusers chown root:root /etc/vsftpd/ftpusers fi for USER in `echo $SYS_USER`; do if [ $(grep -c "^${USER}$" /etc/vsftpd/ftpusers) = 0 ]; then echo ${USER} | tee -a /etc/vsftpd/ftpusers &>/dev/null fi done fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/ftp_ftpusers_file_exists.sh000066400000000000000000000015241301675746700302620ustar00rootroot00000000000000SYS_USER=$(cat /etc/passwd | while read entry; do if [ "$(echo ${entry} | cut -d: -f3)" -lt "500" ]; then echo ${entry} | cut -d: -f1 ; fi; done) if [ "$(rpm -q krb5-workstation &>/dev/null; echo $?)" = "0" ]; then if [ ! -e /etc/ftpusers ]; then >/etc/ftpusers chmod 0640 /etc/ftpusers chown root:root /etc/ftpusers fi for USER in `echo $SYS_USER`; do if [ $(grep -c "^${USER}$" /etc/ftpusers) = 0 ]; then echo ${USER} | tee -a /etc/ftpusers &>/dev/null fi done fi if [ "$(rpm -q vsftpd &>/dev/null; echo $?)" = "0" ]; then if [ ! -e /etc/vsftpd/ftpusers ]; then >/etc/vsftpd/ftpusers chmod 0640 /etc/vsftpd/ftpusers chown root:root /etc/vsftpd/ftpusers fi for USER in `echo $SYS_USER`; do if [ $(grep -c "^${USER}$" /etc/vsftpd/ftpusers) = 0 ]; then echo ${USER} | tee -a /etc/vsftpd/ftpusers &>/dev/null fi done fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/ftp_log_transactions.sh000066400000000000000000000005671301675746700273700ustar00rootroot00000000000000if [ -e /etc/xinetd.d/gssftp ]; then if [ "$(grep server_args /etc/xinetd.d/gssftp | grep -c " -l")" = "0" ]; then sed -i "/server_args/s/$/ -l/" /etc/xinetd.d/gssftp fi fi if [ -e /etc/vsftpd/vsftpd.conf ]; then if [ "$(grep -ic "^xferlog_enable=yes" /etc/vsftpd/vsftpd.conf)" = "0" ]; then sed -i "s/xferlog_enable.*/xferlog_enable=yes/" /etc/xinetd.d/gssftp fi fi gconf_gnome_screensaver_idle_activation_enabled.sh000066400000000000000000000002451301675746700346310ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/5/templates/static/bashgconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type bool --set /apps/gnome-screensaver/idle_activation_enabled true &>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/gconf_gnome_screensaver_idle_delay.sh000066400000000000000000000002251301675746700321710ustar00rootroot00000000000000gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type int --set /apps/gnome-screensaver/idle_delay 15 &>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/gconf_gnome_screensaver_lock_enabled.sh000066400000000000000000000002321301675746700324760ustar00rootroot00000000000000gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type bool --set /apps/gnome-screensaver/lock_enabled true &>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/global_initialization_files_mesg.sh000066400000000000000000000000561301675746700317030ustar00rootroot00000000000000echo mesg n | tee -a /etc/profile &>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/ip6tables_input_icmpv6_broadcast.sh000066400000000000000000000007141301675746700315560ustar00rootroot00000000000000if [ ! -e /etc/sysconfig/ip6tables ] || [ "$(grep -c ^ /etc/sysconfig/ip6tables)" -lt "5" ]; then echo -e "*filter\n:INPUT DROP [0:0]\n:FORWARD DROP [0:0]\n:OUTPUT ACCEPT [0:0]\nCOMMIT" | tee /etc/sysconfig/ip6tables &>/dev/null echo "-A INPUT -p icmpv6 -d ff02::1 --icmpv6-type 128 -j DROP" | tee -a /etc/sysconfig/ip6tables &>/dev/null else echo "-A INPUT -p icmpv6 -d ff02::1 --icmpv6-type 128 -j DROP" | tee -a /etc/sysconfig/ip6tables &>/dev/null fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/ip_6to4_tunnels.sh000066400000000000000000000001611301675746700261700ustar00rootroot00000000000000ip tunnel list | cut -d: -f1 | while read TUNNEL_INTERFACE; do ip tunnel del $TUNNEL_INTERFACE 2>/dev/null; done scap-security-guide-0.1.31/RHEL/5/templates/static/bash/ip_teredo.sh000066400000000000000000000001111301675746700251010ustar00rootroot00000000000000ps ax | grep -i miredo | grep -v grep | awk ' { print $1 }' | xargs kill scap-security-guide-0.1.31/RHEL/5/templates/static/bash/ip_tunnels.sh000066400000000000000000000001611301675746700253140ustar00rootroot00000000000000ip tunnel list | cut -d: -f1 | while read TUNNEL_INTERFACE; do ip tunnel del $TUNNEL_INTERFACE 2>/dev/null; done scap-security-guide-0.1.31/RHEL/5/templates/static/bash/iptables_input_reject_rule.sh000066400000000000000000000001621301675746700305420ustar00rootroot00000000000000/sbin/iptables -A INPUT -j REJECT --reject-with icmp-host-prohibited /sbin/iptables-save > /etc/sysconfig/iptablesscap-security-guide-0.1.31/RHEL/5/templates/static/bash/iptables_timestamp_reject_rule.sh000066400000000000000000000012121301675746700314030ustar00rootroot00000000000000if [ "$(egrep -c '(--icmp-type 14|timestamp-reply) -j DROP')" = "0" ]; then /sbin/iptables -I INPUT -p ICMP --icmp-type timestamp-reply -j DROP fi if [ "$(egrep -c '(--icmp-type 13|timestamp-request) -j DROP')" = "0" ]; then /sbin/iptables -I INPUT -p ICMP --icmp-type timestamp-request -j DROP fi /sbin/iptables-save > /etc/sysconfig/iptables if [ "$(grep -c 'icmp-type 13' /etc/sysconfig/iptables)" != "0" ]; then sed -i 's/icmp-type 13/icmp-type timestamp-request/' /etc/sysconfig/iptables fi if [ "$(grep -c 'icmp-type 14' /etc/sysconfig/iptables)" != "0" ]; then sed -i 's/icmp-type 14/icmp-type timestamp-reply/' /etc/sysconfig/iptables fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/kernel_module_dccp_disabled.sh000066400000000000000000000006641301675746700306110ustar00rootroot00000000000000if [ -d /etc/modprobe.d/ ]; then echo "install dccp /bin/true" >> /etc/modprobe.d/disabled_modules.conf echo "install dccp_ipv4 /bin/true" >> /etc/modprobe.d/disabled_modules.conf echo "install dccp_ipv6 /bin/true" >> /etc/modprobe.d/disabled_modules.conf else echo "install dccp /bin/true" >> /etc/modprobe.conf echo "install dccp_ipv4 /bin/true" >> /etc/modprobe.conf echo "install dccp_ipv6 /bin/true" >> /etc/modprobe.conf fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/kernel_module_ipv6_option_disabled.sh000066400000000000000000000002761301675746700321530ustar00rootroot00000000000000if [ -d /etc/modprobe.d/ ]; then echo "install ipv6 /bin/true" >> /etc/modprobe.d/disabled_modules.conf else echo "install ipv6 /bin/true" >> /etc/modprobe.conf fi chkconfig ip6tables off scap-security-guide-0.1.31/RHEL/5/templates/static/bash/ldap_client_bindpw.sh000066400000000000000000000000411301675746700267520ustar00rootroot00000000000000sed -i '/bindpw/d' /etc/ldap.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/ldap_client_start_tls.sh000066400000000000000000000005721301675746700275170ustar00rootroot00000000000000if [ "$(cat /etc/ldap.conf | grep -c '^ssl ')" = "0" ]; then echo "ssl start_tls" | tee -a /etc/ldap.conf &>/dev/null else sed -i 's/^ssl .*/ssl start_tls/' /etc/ldap.conf fi if [ "$(cat /etc/ldap.conf | grep -c '^tls_ciphers ')" = "0" ]; then echo "tls_ciphers TLSv1" | tee -a /etc/ldap.conf &>/dev/null else sed -i 's/^tls_ciphers .*/tls_ciphers TLSv1/' /etc/ldap.conf fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/ldap_client_tls_cert.sh000066400000000000000000000000461301675746700273130ustar00rootroot00000000000000sed -i 's/ ldap//g' /etc/nsswitch.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/ldap_client_tls_checkpeer.sh000066400000000000000000000003111301675746700303020ustar00rootroot00000000000000if [ $(cat /etc/ldap.conf | grep -c "^tls_checkpeer") = "0" ]; then echo "tls_checkpeer yes" | tee -a /etc/ldap.conf &>/dev/null else sed -i 's/^tls_checkpeer.*/tls_checkpeer yes/' /etc/ldap.conf fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/ldap_client_tls_crlcheck.sh000066400000000000000000000003051301675746700301320ustar00rootroot00000000000000if [ $(cat /etc/ldap.conf | grep -c "^tls_crlcheck") = "0" ]; then echo "tls_crlcheck all" | tee -a /etc/ldap.conf &>/dev/null else sed -i 's/^tls_crlcheck.*/tls_crlcheck all/' /etc/ldap.conf fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/mail_forward_files.sh000066400000000000000000000015051301675746700267670ustar00rootroot00000000000000SENDMAIL_CONFIG=$(rpm -ql sendmail | grep sendmail.cf) SENDMAIL_MAINCONF=$(rpm -ql sendmail | grep sendmail.mc) if [ "$(rpm -q sendmail-cf &>/dev/null; echo $?)" = "0" ]; then if [ -e "${SENDMAIL_MAINCONF}" ]; then if [ "$(grep -c 'confFORWARD_PATH' "${SENDMAIL_MAINCONF}")" = "0" ]; then sed -i "0,/^define/s/\(^define\)/define(\`confFORWARD_PATH',\`')dnl\n\1/" "${SENDMAIL_MAINCONF}" elif [ "$(grep -c "define(\`confFORWARD_PATH',\`')dnl" "${SENDMAIL_MAINCONF}")" = "0" ]; then sed -i "s/define(\`confFORWARD.*/define(\`confFORWARD_PATH',\`')dnl/" "${SENDMAIL_MAINCONF}" fi m4 "${SENDMAIL_MAINCONF}" > "${SENDMAIL_CONFIG}" fi else sed -i 's/O ForwardPath.*/O ForwardPath/' "${SENDMAIL_CONFIG}" fi service sendmail restart 1>/dev/null for FILE in $(find /etc -name .forward -type f 2>/dev/null); do rm -f ${FILE} done scap-security-guide-0.1.31/RHEL/5/templates/static/bash/mail_help_command.sh000066400000000000000000000000241301675746700265620ustar00rootroot00000000000000>/etc/mail/helpfile scap-security-guide-0.1.31/RHEL/5/templates/static/bash/mail_version_info.sh000066400000000000000000000015761301675746700266510ustar00rootroot00000000000000SENDMAIL_CONFIG=$(rpm -ql sendmail | grep sendmail.cf) SENDMAIL_MAINCONF=$(rpm -ql sendmail | grep sendmail.mc) if [ "$(rpm -q sendmail-cf &>/dev/null; echo $?)" = "0" ]; then if [ -e "${SENDMAIL_MAINCONF}" ]; then if [ "$(grep -c "^define(\`confSMTP_LOGIN_MSG" "${SENDMAIL_MAINCONF}")" = "0" ]; then sed -i "0,/^define/s/\(^define\)/define(\`confSMTP_LOGIN_MSG', \` Mail Server Ready ; $b')dnl\n\1/" "${SENDMAIL_MAINCONF}" elif [ "$(grep -c "^define(\`confSMTP_LOGIN_MSG', \` Mail Server Ready ; \$b')dnl" "${SENDMAIL_MAINCONF}")" = "0" ]; then sed -i "s/^define(\`confSMTP_LOGIN_MSG.*/define(\`confSMTP_LOGIN_MSG', \`Mail Server Ready ; \$b')dnl/" "${SENDMAIL_MAINCONF}" fi m4 "${SENDMAIL_MAINCONF}" > "${SENDMAIL_CONFIG}" fi else sed -i 's/O SmtpGreetingMessage=.*/O SmtpGreetingMessage= Mail Server Ready ; $b/' "${SENDMAIL_CONFIG}" fi service sendmail restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/network_ipv6_disable_interfaces.sh000066400000000000000000000003661301675746700314660ustar00rootroot00000000000000if [ $(grep -c "^NETWORKING_IPV6" /etc/sysconfig/network) = 0 ]; then echo "NETWORKING_IPV6=no" | tee -a /etc/sysconfig/network &>/dev/null else sed -i 's/NETWORKING_IPV6.*/NETWORKING_IPV6=no/' /etc/sysconfig/network fi chkconfig ip6tables off scap-security-guide-0.1.31/RHEL/5/templates/static/bash/no_files_unowned_by_user.sh000066400000000000000000000001271301675746700302230ustar00rootroot00000000000000find / /home /var /var/log /var/log/audit -xdev -nouser 2>/dev/null | xargs chown root scap-security-guide-0.1.31/RHEL/5/templates/static/bash/no_root_webbrowsing.sh000066400000000000000000000001021301675746700272160ustar00rootroot00000000000000rm -rf `grep ^root: /etc/passwd | awk -F: '{ print $6 }'`/.mozillascap-security-guide-0.1.31/RHEL/5/templates/static/bash/package_rpc_removed.sh000066400000000000000000000000721301675746700271150ustar00rootroot00000000000000yum -y remove portmap rpcbind --disablerepo=* 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/package_samba_removed.sh000066400000000000000000000000671301675746700274200ustar00rootroot00000000000000yum -y remove samba-common --disablerepo=* 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/require_singleuser_auth.sh000066400000000000000000000002501301675746700300700ustar00rootroot00000000000000grep -q :S: /etc/inittab && \ sed -i "s/.*:S:.*/~:S:wait:\/sbin\/sulogin/g" /etc/inittab if ! [ $? -eq 0 ]; then echo "~:S:wait:/sbin/sulogin" >> /etc/inittab fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/restricted_accounts.sh000066400000000000000000000002611301675746700272040ustar00rootroot00000000000000/usr/bin/id shutdown &>/dev/null && /usr/sbin/userdel shutdown /usr/bin/id halt &>/dev/null && /usr/sbin/userdel halt /usr/bin/id reboot &>/dev/null && /usr/sbin/userdel reboot scap-security-guide-0.1.31/RHEL/5/templates/static/bash/restricted_accounts_ftp.sh000066400000000000000000000000651301675746700300570ustar00rootroot00000000000000/usr/bin/id ftp &>/dev/null && /usr/sbin/userdel ftp scap-security-guide-0.1.31/RHEL/5/templates/static/bash/restricted_accounts_games.sh000066400000000000000000000000711301675746700303570ustar00rootroot00000000000000/usr/bin/id games &>/dev/null && /usr/sbin/userdel games scap-security-guide-0.1.31/RHEL/5/templates/static/bash/restricted_accounts_gopher.sh000066400000000000000000000000731301675746700305510ustar00rootroot00000000000000/usr/bin/id gopher &>/dev/null && /usr/sbin/userdel gopher scap-security-guide-0.1.31/RHEL/5/templates/static/bash/restricted_accounts_news.sh000066400000000000000000000000671301675746700302440ustar00rootroot00000000000000/usr/bin/id news &>/dev/null && /usr/sbin/userdel news scap-security-guide-0.1.31/RHEL/5/templates/static/bash/rhosts_auth_pam_files.sh000066400000000000000000000000511301675746700275140ustar00rootroot00000000000000sed -i '/.*rhosts_auth.*/d' /etc/pam.d/* scap-security-guide-0.1.31/RHEL/5/templates/static/bash/rpm_nosignature.sh000066400000000000000000000003001301675746700263430ustar00rootroot00000000000000grep nosignature /etc/rpmrc /usr/lib/rpm/rpmrc /usr/lib/rpm/redhat/rpmrc ~root/.rpmrc 2>/dev/null | cut -d: -f1 | sort -u | while read RPM_FILE; do sed -i 's/nosignature//g' ${RPM_FILE} done scap-security-guide-0.1.31/RHEL/5/templates/static/bash/samba_encrypt_passwords_option.sh000066400000000000000000000003661301675746700314670ustar00rootroot00000000000000if [ "$(grep -c '^[ |\t]*encrypt passwords' /etc/samba/smb.conf)" = "0" ]; then sed -i 's/\(^\[global\]$\)/\1\n\n\tencrypt passwords = yes/' /etc/samba/smb.conf else sed -i '/^[#|;]/!s/\(encrypt passwords =\).*/\1 yes/g' /etc/samba/smb.conf fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/samba_guest_ok_option.sh000066400000000000000000000001001301675746700275000ustar00rootroot00000000000000sed -i '/^[#|;]/!s/\(guest ok =\).*/\1 no/g' /etc/samba/smb.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/samba_hosts_option.sh000066400000000000000000000001131301675746700270240ustar00rootroot00000000000000sed -i 's/\(^\[global\]$\)/\1\n\n\thosts allow = 127./' /etc/samba/smb.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/samba_security_option.sh000066400000000000000000000001101301675746700275300ustar00rootroot00000000000000sed -i '/^[#|;]/!s/\([ |\t]*security =\).*/\1 user/' /etc/samba/smb.confscap-security-guide-0.1.31/RHEL/5/templates/static/bash/securetty_root_login_console_only.sh000066400000000000000000000000331301675746700321770ustar00rootroot00000000000000echo tty1 > /etc/securetty scap-security-guide-0.1.31/RHEL/5/templates/static/bash/selinux_enforcing.sh000066400000000000000000000016361301675746700266650ustar00rootroot00000000000000. /usr/share/scap-security-guide/remediation_functions populate var_selinux_policy_name if [ "`grep -c ^SELINUX= /etc/sysconfig/selinux`" = "0" ]; then echo SELINUX=enforcing >> /etc/sysconfig/selinux else sed -i 's/^SELINUX=.*/SELINUX=enforcing/' /etc/sysconfig/selinux fi if [ "`grep -c ^SELINUX= /etc/selinux/config`" = "0" ]; then echo SELINUX=enforcing >> /etc/selinux/config else sed -i 's/^SELINUX=.*/SELINUX=enforcing/' /etc/selinux/config fi if [ "`grep -c ^SELINUXTYPE= /etc/sysconfig/selinux`" = "0" ]; then echo SELINUXTYPE=${var_selinux_policy_name} >> /etc/sysconfig/selinux else sed -i "s/^SELINUXTYPE=.*/SELINUXTYPE=${var_selinux_policy_name}/" /etc/sysconfig/selinux fi if [ "`grep -c ^SELINUXTYPE= /etc/selinux/config`" = "0" ]; then echo SELINUXTYPE=${var_selinux_policy_name} >> /etc/selinux/config else sed -i "s/^SELINUXTYPE=.*/SELINUXTYPE=${var_selinux_policy_name}/" /etc/selinux/config fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/set_password_hashing_algorithm_systemauth.sh000066400000000000000000000012121301675746700337040ustar00rootroot00000000000000if [ $(grep "password.*pam_unix.so" /etc/pam.d/system-auth | egrep -c '(descrypt|bigcrypt|md5|sha256)') != 0 ]; then sed -i '/password.*pam_unix.so/s/\(descrypt\|bigcrypt\|md5\|sha256\)/sha512/' /etc/pam.d/system-auth else sed -i '/password.*pam_unix.so/s/$/ sha512/' /etc/pam.d/system-auth fi if [ -e /etc/pam.d/system-auth-ac ]; then if [ $(grep "password.*pam_unix.so" /etc/pam.d/system-auth-ac | egrep -c '(descrypt|bigcrypt|md5|sha256)') != 0 ]; then sed -i '/password.*pam_unix.so/s/\(descrypt\|bigcrypt\|md5\|sha256\)/sha512/' /etc/pam.d/system-auth-ac else sed -i '/password.*pam_unix.so/s/$/ sha512/' /etc/pam.d/system-auth-ac fi fiscap-security-guide-0.1.31/RHEL/5/templates/static/bash/shells_file_references.sh000066400000000000000000000003741301675746700276340ustar00rootroot00000000000000for USHELL in `cut -d: -f7 /etc/passwd | egrep -v '(/usr/bin/false|/bin/false|/dev/null|/sbin/nologin|/bin/sync|/sbin/halt|/sbin/shutdown)' | uniq`; do if [ "$(grep -c "${USHELL}" /etc/shells)" = "0" ]; then echo "${USHELL}" >> /etc/shells fi done scap-security-guide-0.1.31/RHEL/5/templates/static/bash/snmpd_use_newer_protocol.sh000066400000000000000000000001471301675746700302560ustar00rootroot00000000000000find / -xdev -name snmpd.conf 2>/dev/null | xargs sed -i '/.*\(v1\|v2c\|community\|com2sec\).*/s/^/#/' scap-security-guide-0.1.31/RHEL/5/templates/static/bash/ssh_gssapiauthentication.sh000066400000000000000000000003621301675746700302420ustar00rootroot00000000000000if [ $(cat /etc/ssh/ssh_config | grep -c "^GSSAPIAuthentication") = "0" ]; then echo "GSSAPIAuthentication no" | tee -a /etc/ssh/ssh_config &>/dev/null else sed -i 's/^GSSAPIAuthentication.*/GSSAPIAuthentication no/' /etc/ssh/ssh_config fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/ssh_no_cbc.sh000066400000000000000000000003461301675746700252410ustar00rootroot00000000000000grep -q ^Ciphers /etc/ssh/ssh_config && \ sed -i "s/Ciphers.*/Ciphers aes128-ctr,aes192-ctr,aes256-ctr/g" /etc/ssh/ssh_config if ! [ $? -eq 0 ]; then echo "Ciphers aes128-ctr,aes192-ctr,aes256-ctr" >> /etc/ssh/ssh_config fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/ssh_protocol_2.sh000066400000000000000000000002561301675746700261000ustar00rootroot00000000000000if [ $(cat /etc/ssh/ssh_config | grep -c "^Protocol") != "0" ]; then sed -i 's/^Protocol.*/Protocol 2/' /etc/ssh/ssh_config else echo "Protocol 2">>/etc/ssh/ssh_config fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/ssh_use_approved_ciphers.sh000066400000000000000000000003471301675746700302300ustar00rootroot00000000000000grep -q ^Ciphers /etc/ssh/ssh_config && \ sed -i "s/Ciphers.*/Ciphers aes128-ctr,aes192-ctr,aes256-ctr/g" /etc/ssh/ssh_config if ! [ $? -eq 0 ]; then echo "Ciphers aes128-ctr,aes192-ctr,aes256-ctr" >> /etc/ssh/ssh_config fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/ssh_use_approved_macs.sh000066400000000000000000000003001301675746700275030ustar00rootroot00000000000000if [ $(cat /etc/ssh/ssh_config | grep -c "^MACs") = "0" ]; then echo "MACs hmac-sha1" | tee -a /etc/ssh/ssh_config &>/dev/null else sed -i 's/^MACs.*/MACs hmac-sha1/' /etc/ssh/ssh_config fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/sshd_compression.sh000066400000000000000000000003741301675746700265240ustar00rootroot00000000000000if [ $(cat /etc/ssh/sshd_config | grep -ic "^Compression") = "0" ]; then echo "Compression delayed" | tee -a /etc/ssh/sshd_config &>/dev/null else sed -i 's/^Compression.*/Compression delayed/' /etc/ssh/sshd_config fi service sshd restart 1>/dev/nullscap-security-guide-0.1.31/RHEL/5/templates/static/bash/sshd_disable_root_login.sh000066400000000000000000000003551301675746700300200ustar00rootroot00000000000000grep -q ^PermitRootLogin /etc/ssh/sshd_config && \ sed -i "s/PermitRootLogin.*/PermitRootLogin no/g" /etc/ssh/sshd_config if ! [ $? -eq 0 ]; then echo "PermitRootLogin no" >> /etc/ssh/sshd_config fi service sshd restart 1>/dev/nullscap-security-guide-0.1.31/RHEL/5/templates/static/bash/sshd_enable_warning_banner.sh000066400000000000000000000003331301675746700304560ustar00rootroot00000000000000grep -q ^Banner /etc/ssh/sshd_config && \ sed -i "s/Banner.*/Banner \/etc\/issue/g" /etc/ssh/sshd_config if ! [ $? -eq 0 ]; then echo "Banner /etc/issue" >> /etc/ssh/sshd_config fi service sshd restart 1>/dev/nullscap-security-guide-0.1.31/RHEL/5/templates/static/bash/sshd_gssapiauthentication.sh000066400000000000000000000004251301675746700304060ustar00rootroot00000000000000if [ $(cat /etc/ssh/sshd_config | grep -c "^GSSAPIAuthentication") = "0" ]; then echo "GSSAPIAuthentication no" | tee -a /etc/ssh/sshd_config &>/dev/null else sed -i 's/^GSSAPIAuthentication.*/GSSAPIAuthentication no/' /etc/ssh/sshd_config fi service sshd restart 1>/dev/nullscap-security-guide-0.1.31/RHEL/5/templates/static/bash/sshd_ipfiltering.sh000066400000000000000000000004611301675746700264740ustar00rootroot00000000000000MANAGEMENT_IP=$(/sbin/ifconfig | grep inet | grep -v 127.0.0.1 | cut -d: -f2 | awk '{ print $1}' | head -1 | cut -d. -f1-2) sed -i '/sshd/d' /etc/hosts.allow echo "sshd: ${MANAGEMENT_IP}.: spawn /bin/echo SSHD accessed on \$(/bin/date) from %h>>/var/log/host.access" | tee -a /etc/hosts.allow &>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/sshd_kerberosauthentication.sh000066400000000000000000000004361301675746700307360ustar00rootroot00000000000000if [ $(cat /etc/ssh/sshd_config | grep -ic "^KerberosAuthentication") = "0" ]; then echo "KerberosAuthentication no" | tee -a /etc/ssh/sshd_config &>/dev/null else sed -i 's/^KerberosAuthentication.*/KerberosAuthentication no/' /etc/ssh/sshd_config fi service sshd restart 1>/dev/nullscap-security-guide-0.1.31/RHEL/5/templates/static/bash/sshd_listen_addresses.sh000066400000000000000000000006021301675746700275100ustar00rootroot00000000000000MANAGEMENT_IP=$(/sbin/ifconfig | grep inet | grep -v 127.0.0.1 | cut -d: -f2 | awk '{ print $1}' | head -1) if [ $(cat /etc/ssh/sshd_config | grep -ic "^ListenAddress") = "0" ]; then echo "ListenAddress ${MANAGEMENT_IP}" | tee -a /etc/ssh/sshd_config &>/dev/null else sed -i "s/^ListenAddress.*/ListenAddress ${MANAGEMENT_IP}/" /etc/ssh/sshd_config fi service sshd restart 1>/dev/nullscap-security-guide-0.1.31/RHEL/5/templates/static/bash/sshd_no_cbc.sh000066400000000000000000000004171301675746700254040ustar00rootroot00000000000000grep -q ^Ciphers /etc/ssh/sshd_config && \ sed -i "s/Ciphers.*/Ciphers aes128-ctr,aes192-ctr,aes256-ctr/g" /etc/ssh/sshd_config if ! [ $? -eq 0 ]; then echo "Ciphers aes128-ctr,aes192-ctr,aes256-ctr" >> /etc/ssh/sshd_config fi /sbin/service sshd restart 1>/dev/nullscap-security-guide-0.1.31/RHEL/5/templates/static/bash/sshd_printlastlog.sh000066400000000000000000000010441301675746700267000ustar00rootroot00000000000000if [ "$(grep -c '^session.*required.*pam_lastlog.so$' /etc/pam.d/sshd)" = "0" ]; then echo -e "session required\tpam_lastlog.so" | tee -a /etc/pam.d/sshd &>/dev/null elif [ "$(grep pam_lastlog /etc/pam.d/sshd | grep -c silent)" != "0" ]; then sed -i '/pam_lastlog/s/silent//' /etc/pam.d/sshd fi if [ $(cat /etc/ssh/sshd_config | grep -ic "^PrintLastLog") = "0" ]; then echo "PrintLastLog yes" | tee -a /etc/ssh/sshd_config &>/dev/null else sed -i 's/^PrintLastLog.*/PrintLastLog yes/' /etc/ssh/sshd_config fi service sshd restart 1>/dev/nullscap-security-guide-0.1.31/RHEL/5/templates/static/bash/sshd_privilegeseparation.sh000066400000000000000000000004401301675746700302310ustar00rootroot00000000000000if [ $(cat /etc/ssh/sshd_config | grep -ic "^UsePrivilegeSeparation") = "0" ]; then echo "UsePrivilegeSeparation yes" | tee -a /etc/ssh/sshd_config &>/dev/null else sed -i 's/^UsePrivilegeSeparation.*/UsePrivilegeSeparation yes/' /etc/ssh/sshd_config fi service sshd restart 1>/dev/nullscap-security-guide-0.1.31/RHEL/5/templates/static/bash/sshd_protocol_2.sh000066400000000000000000000003201301675746700262340ustar00rootroot00000000000000if [ $(cat /etc/ssh/sshd_config | grep -c "^Protocol") != "0" ]; then sed -i 's/^Protocol.*/Protocol 2/' /etc/ssh/sshd_config else echo "Protocol 2">>/etc/ssh/sshd_config fi service sshd restart 1>/dev/nullscap-security-guide-0.1.31/RHEL/5/templates/static/bash/sshd_rhostsrsaauthentication.sh000066400000000000000000000004421301675746700311470ustar00rootroot00000000000000if [ $(cat /etc/ssh/sshd_config | grep -ic "^RhostsRSAAuthentication") = "0" ]; then echo "RhostsRSAAuthentication no" | tee -a /etc/ssh/sshd_config &>/dev/null else sed -i 's/^RhostsRSAAuthentication.*/RhostsRSAAuthentication no/' /etc/ssh/sshd_config fi service sshd restart 1>/dev/nullscap-security-guide-0.1.31/RHEL/5/templates/static/bash/sshd_strictmodes.sh000066400000000000000000000003631301675746700265210ustar00rootroot00000000000000if [ $(cat /etc/ssh/sshd_config | grep -c "^StrictModes") = "0" ]; then echo "StrictModes yes" | tee -a /etc/ssh/sshd_config &>/dev/null else sed -i 's/^StrictModes.*/StrictModes yes/' /etc/ssh/sshd_config fi service sshd restart 1>/dev/nullscap-security-guide-0.1.31/RHEL/5/templates/static/bash/sshd_use_approved_ciphers.sh000066400000000000000000000004121301675746700303650ustar00rootroot00000000000000grep -q ^Ciphers /etc/ssh/sshd_config && \ sed -i "s/Ciphers.*/Ciphers aes128-ctr,aes192-ctr,aes256-ctr/g" /etc/ssh/sshd_config if ! [ $? -eq 0 ]; then echo "Ciphers aes128-ctr,aes192-ctr,aes256-ctr" >> /etc/ssh/sshd_config fi service sshd restart 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/static/bash/sshd_use_approved_macs.sh000066400000000000000000000003431301675746700276560ustar00rootroot00000000000000if [ $(cat /etc/ssh/sshd_config | grep -c "^MACs") = "0" ]; then echo "MACs hmac-sha1" | tee -a /etc/ssh/sshd_config &>/dev/null else sed -i 's/^MACs.*/MACs hmac-sha1/' /etc/ssh/sshd_config fi service sshd restart 1>/dev/nullscap-security-guide-0.1.31/RHEL/5/templates/static/bash/sshd_users_groups.sh000066400000000000000000000001431301675746700267150ustar00rootroot00000000000000echo "AllowGroups wheel" | tee -a /etc/ssh/sshd_config &>/dev/null service sshd restart 1>/dev/nullscap-security-guide-0.1.31/RHEL/5/templates/static/bash/sudo_wheel.sh000066400000000000000000000003451301675746700252760ustar00rootroot00000000000000if [ "$(grep -c '#.*auth.*required.*pam_wheel.so' /etc/pam.d/su)" != "0" ]; then sed -i '/auth.*required.*pam_wheel.so/s/#//g' /etc/pam.d/su else sed -i '/auth.*include/iauth\t\trequired\tpam_wheel.so use_uid' /etc/pam.d/su fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/sysconfig_networking_bootproto_ifcfg.sh000066400000000000000000000001231301675746700326520ustar00rootroot00000000000000sed -i 's/^BOOTPROTO=.*/BOOTPROTO="static"/' /etc/sysconfig/network-scripts/ifcfg-*scap-security-guide-0.1.31/RHEL/5/templates/static/bash/sysconfig_networking_userctl_ifcfg.sh000066400000000000000000000001741301675746700323120ustar00rootroot00000000000000find /etc/sysconfig/network-scripts/ -name ifcfg-* | while read FILE; do sed -i 's/^USERCTL=.*/USERCTL=no/' "${FILE}" done scap-security-guide-0.1.31/RHEL/5/templates/static/bash/sysctl_kernel_execshield.sh000066400000000000000000000005501301675746700302140ustar00rootroot00000000000000/sbin/sysctl -q -n -w kernel.exec-shield=1 if grep --silent ^kernel.exec-shield /etc/sysctl.conf ; then sed -i 's/^kernel.exec-shield.*/kernel.exec-shield = 1/g' /etc/sysctl.conf else echo "" >> /etc/sysctl.conf echo "# Set kernel.exec-shield to 1 per security requirements" >> /etc/sysctl.conf echo "kernel.exec-shield = 1" >> /etc/sysctl.conf fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/sysctl_kernel_nonexec_stack.sh000066400000000000000000000014361301675746700307270ustar00rootroot00000000000000if [[ "`uname -r`" != "2.6.9"* ]]; then /sbin/sysctl -q -n -w kernel.randomize_va_space=1 if grep --silent ^kernel.randomize_va_space /etc/sysctl.conf ; then sed -i 's/^kernel.randomize_va_space.*/kernel.randomize_va_space = 1/g' /etc/sysctl.conf else echo "" >> /etc/sysctl.conf echo "# Set kernel.randomize_va_space to 1 per security requirements" >> /etc/sysctl.conf echo "kernel.randomize_va_space = 1" >> /etc/sysctl.conf fi fi /sbin/sysctl -q -n -w kernel.exec-shield=1 if grep --silent ^kernel.exec-shield /etc/sysctl.conf ; then sed -i 's/^kernel.exec-shield.*/kernel.exec-shield = 1/g' /etc/sysctl.conf else echo "" >> /etc/sysctl.conf echo "# Set kernel.exec-shield to 1 per security requirements" >> /etc/sysctl.conf echo "kernel.exec-shield = 1" >> /etc/sysctl.conf fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/sysctl_net_ipv4_conf_accept_redirects.sh000066400000000000000000000016321301675746700326610ustar00rootroot00000000000000/sbin/sysctl -q -n -w net.ipv4.conf.all.accept_redirects=0 /sbin/sysctl -q -n -w net.ipv4.conf.default.accept_redirects=0 if grep --silent ^net.ipv4.conf.all.accept_redirects /etc/sysctl.conf ; then sed -i 's/^net.ipv4.conf.all.accept_redirects.*/net.ipv4.conf.all.accept_redirects = 0/g' /etc/sysctl.conf else echo "" >> /etc/sysctl.conf echo "# Set net.ipv4.conf.all.accept_redirects to 0 per security requirements" >> /etc/sysctl.conf echo "net.ipv4.conf.all.accept_redirects = 0" >> /etc/sysctl.conf fi if grep --silent ^net.ipv4.conf.default.accept_redirects /etc/sysctl.conf ; then sed -i 's/^net.ipv4.conf.default.accept_redirects.*/net.ipv4.conf.default.accept_redirects = 0/g' /etc/sysctl.conf else echo "" >> /etc/sysctl.conf echo "# Set net.ipv4.conf.default.accept_redirects to 0 per security requirements" >> /etc/sysctl.conf echo "net.ipv4.conf.default.accept_redirects = 0" >> /etc/sysctl.conf fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/sysctl_net_ipv4_conf_accept_source_route.sh000066400000000000000000000016761301675746700334230ustar00rootroot00000000000000/sbin/sysctl -q -n -w net.ipv4.conf.all.accept_source_route=0 /sbin/sysctl -q -n -w net.ipv4.conf.default.accept_source_route=0 if grep --silent ^net.ipv4.conf.all.accept_source_route /etc/sysctl.conf ; then sed -i 's/^net.ipv4.conf.all.accept_source_route.*/net.ipv4.conf.all.accept_source_route = 0/g' /etc/sysctl.conf else echo "" >> /etc/sysctl.conf echo "# Set net.ipv4.conf.all.accept_source_route to 0 per security requirements" >> /etc/sysctl.conf echo "net.ipv4.conf.all.accept_source_route = 0" >> /etc/sysctl.conf fi if grep --silent ^net.ipv4.conf.default.accept_source_route /etc/sysctl.conf ; then sed -i 's/^net.ipv4.conf.default.accept_source_route.*/net.ipv4.conf.default.accept_source_route = 0/g' /etc/sysctl.conf else echo "" >> /etc/sysctl.conf echo "# Set net.ipv4.conf.default.accept_source_route to 0 per security requirements" >> /etc/sysctl.conf echo "net.ipv4.conf.default.accept_source_route = 0" >> /etc/sysctl.conf fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/sysctl_net_ipv4_conf_log_martians.sh000066400000000000000000000015521301675746700320360ustar00rootroot00000000000000/sbin/sysctl -q -n -w net.ipv4.conf.all.log_martians=1 /sbin/sysctl -q -n -w net.ipv4.conf.default.log_martians=1 if grep --silent ^net.ipv4.conf.all.log_martians /etc/sysctl.conf ; then sed -i 's/^net.ipv4.conf.all.log_martians.*/net.ipv4.conf.all.log_martians = 1/g' /etc/sysctl.conf else echo "" >> /etc/sysctl.conf echo "# Set net.ipv4.conf.all.log_martians to 1 per security requirements" >> /etc/sysctl.conf echo "net.ipv4.conf.all.log_martians = 1" >> /etc/sysctl.conf fi if grep --silent ^net.ipv4.conf.default.log_martians /etc/sysctl.conf ; then sed -i 's/^net.ipv4.conf.default.log_martians.*/net.ipv4.conf.default.log_martians = 1/g' /etc/sysctl.conf else echo "" >> /etc/sysctl.conf echo "# Set net.ipv4.conf.default.log_martians to 1 per security requirements" >> /etc/sysctl.conf echo "net.ipv4.conf.default.log_martians = 1" >> /etc/sysctl.conf fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/sysctl_net_ipv4_conf_send_redirects.sh000066400000000000000000000016021301675746700323500ustar00rootroot00000000000000/sbin/sysctl -q -n -w net.ipv4.conf.all.send_redirects=0 /sbin/sysctl -q -n -w net.ipv4.conf.default.send_redirects=0 if grep --silent ^net.ipv4.conf.all.send_redirects /etc/sysctl.conf ; then sed -i 's/^net.ipv4.conf.all.send_redirects.*/net.ipv4.conf.all.send_redirects = 0/g' /etc/sysctl.conf else echo "" >> /etc/sysctl.conf echo "# Set net.ipv4.conf.all.send_redirects to 0 per security requirements" >> /etc/sysctl.conf echo "net.ipv4.conf.all.send_redirects = 0" >> /etc/sysctl.conf fi if grep --silent ^net.ipv4.conf.default.send_redirects /etc/sysctl.conf ; then sed -i 's/^net.ipv4.conf.default.send_redirects.*/net.ipv4.conf.default.send_redirects = 0/g' /etc/sysctl.conf else echo "" >> /etc/sysctl.conf echo "# Set net.ipv4.conf.default.send_redirects to 0 per security requirements" >> /etc/sysctl.conf echo "net.ipv4.conf.default.send_redirects = 0" >> /etc/sysctl.conf fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/sysctl_net_ipv6_conf_all_accept_redirects.sh000066400000000000000000000013101301675746700335040ustar00rootroot00000000000000# # Set runtime for net.ipv6.conf.all.accept_redirects # if [ -e /proc/sys/net/ipv6/ ]; then /sbin/sysctl -q -n -w net.ipv6.conf.all.accept_redirects=0 fi # # If net.ipv6.conf.all.accept_redirects present in /etc/sysctl.conf, change value to "0" # else, add "net.ipv6.conf.all.accept_redirects = 0" to /etc/sysctl.conf # if grep --silent ^net.ipv6.conf.all.accept_redirects /etc/sysctl.conf ; then sed -i 's/^net.ipv6.conf.all.accept_redirects.*/net.ipv6.conf.all.accept_redirects = 0/g' /etc/sysctl.conf else echo "" >> /etc/sysctl.conf echo "# Set net.ipv6.conf.all.accept_redirects to 0 per security requirements" >> /etc/sysctl.conf echo "net.ipv6.conf.all.accept_redirects = 0" >> /etc/sysctl.conf fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/sysctl_net_ipv6_conf_forwarding.sh000066400000000000000000000025101301675746700315160ustar00rootroot00000000000000# # Set runtime for net.ipv6.conf.all.forwarding # if [ -e /proc/sys/net/ipv6/ ]; then /sbin/sysctl -q -n -w net.ipv6.conf.all.forwarding=0 fi # # If net.ipv6.conf.all.forwarding present in /etc/sysctl.conf, change value to "0" # else, add "net.ipv6.conf.all.forwarding = 0" to /etc/sysctl.conf # if grep --silent ^net.ipv6.conf.all.forwarding /etc/sysctl.conf ; then sed -i 's/^net.ipv6.conf.all.forwarding.*/net.ipv6.conf.all.forwarding = 0/g' /etc/sysctl.conf else echo "" >> /etc/sysctl.conf echo "# Set net.ipv6.conf.all.forwarding to 0 per security requirements" >> /etc/sysctl.conf echo "net.ipv6.conf.all.forwarding = 0" >> /etc/sysctl.conf fi # # Set runtime for net.ipv6.conf.default.forwarding # if [ -e /proc/sys/net/ipv6/ ]; then /sbin/sysctl -q -n -w net.ipv6.conf.default.forwarding=0 fi # # If net.ipv6.conf.default.forwarding present in /etc/sysctl.conf, change value to "0" # else, add "net.ipv6.conf.default.forwarding = 0" to /etc/sysctl.conf # if grep --silent ^net.ipv6.conf.default.forwarding /etc/sysctl.conf ; then sed -i 's/^net.ipv6.conf.default.forwarding.*/net.ipv6.conf.default.forwarding = 0/g' /etc/sysctl.conf else echo "" >> /etc/sysctl.conf echo "# Set net.ipv6.conf.default.forwarding to 0 per security requirements" >> /etc/sysctl.conf echo "net.ipv6.conf.default.forwarding = 0" >> /etc/sysctl.conf fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/system_access_control.sh000066400000000000000000000011121301675746700275360ustar00rootroot00000000000000if [ ! -e /etc/hosts.allow ]; then >/etc/hosts.allow chmod 644 /etc/hosts.allow chown root:root /etc/hosts.allow fi if [ ! -e /etc/hosts.deny ]; then >/etc/hosts.deny chmod 644 /etc/hosts.deny chown root:root /etc/hosts.deny fi if [ ! -e /var/log/host.access ]; then >/var/log/host.access chmod 640 /var/log/host.access chown root:root /var/log/host.access fi if [ $(grep -c "ALL: ALL" /etc/hosts.deny) = 0 ]; then echo 'ALL: ALL: spawn /bin/echo Access denied on $(/bin/date) from %a for access to %d \(pid %p\)>>/var/log/host.access' | tee -a /etc/hosts.deny &>/dev/null fi scap-security-guide-0.1.31/RHEL/5/templates/static/bash/xwindows_runlevel_setting.sh000066400000000000000000000000741301675746700304720ustar00rootroot00000000000000sed -i 's/.*:initdefault:.*/id:3:initdefault:/' /etc/inittabscap-security-guide-0.1.31/RHEL/5/templates/template_BASH_kernel_module_disabled000066400000000000000000000002621301675746700274650ustar00rootroot00000000000000if [ -d /etc/modprobe.d/ ]; then echo "install KERNMODULE /bin/true" >> /etc/modprobe.d/disabled_modules.conf else echo "install KERNMODULE /bin/true" >> /etc/modprobe.conf fi scap-security-guide-0.1.31/RHEL/5/templates/template_BASH_package_removed000066400000000000000000000000621301675746700261230ustar00rootroot00000000000000yum -y remove PKGNAME --disablerepo=* 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/template_BASH_service_disabled000066400000000000000000000002651301675746700263030ustar00rootroot00000000000000# # Disable SERVICENAME for all run levels # /sbin/chkconfig --level 0123456 SERVICENAME off # # Stop SERVICENAME if currently running # /sbin/service SERVICENAME stop 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/template_BASH_service_enabled000066400000000000000000000002711301675746700261230ustar00rootroot00000000000000# # Enable SERVICENAME for all run levels # /sbin/chkconfig --level 0123456 SERVICENAME on # # Start SERVICENAME if not currently running # /sbin/service SERVICENAME start 1>/dev/null scap-security-guide-0.1.31/RHEL/5/templates/template_kernel_module_disabled000066400000000000000000000001061301675746700266650ustar00rootroot00000000000000echo "install KERNMODULE /bin/true" > /etc/modprobe.d/KERNMODULE.conf scap-security-guide-0.1.31/RHEL/5/transforms/000077500000000000000000000000001301675746700205765ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/5/transforms/.gitignore000066400000000000000000000000061301675746700225620ustar00rootroot00000000000000*.bak scap-security-guide-0.1.31/RHEL/5/transforms/cce_extract.py000077500000000000000000000003551301675746700234420ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import cce_extract_module if __name__ == "__main__": cce_extract_module.main() scap-security-guide-0.1.31/RHEL/5/transforms/cci2html.xsl000066400000000000000000000004711301675746700230350ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/5/transforms/constants.xslt000066400000000000000000000024171301675746700235320ustar00rootroot00000000000000 Red Hat Enterprise Linux 5 RHEL 5 RHEL_5_STIG RHEL-5 cpe:/o:redhat:enterprise_linux:4,cpe:/o:redhat:enterprise_linux:5 rhel5 https://benchmarks.cisecurity.org/tools2/linux/CIS_Redhat_Linux_5_Benchmark_v2.0.0.pdf scap-security-guide-0.1.31/RHEL/5/transforms/shorthand2xccdf.xslt000066400000000000000000000005151301675746700245770ustar00rootroot00000000000000 unknown unlinked-rhel5-oval.xml scap-security-guide-0.1.31/RHEL/5/transforms/splitchecks.py000077500000000000000000000003551301675746700234720ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import splitchecks_module if __name__ == "__main__": splitchecks_module.main() scap-security-guide-0.1.31/RHEL/5/transforms/table-add-srgitems.xslt000066400000000000000000000011011301675746700251530ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/5/transforms/table-sortbyref.xslt000066400000000000000000000005601301675746700246170ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/5/transforms/table-srgmap.xslt000066400000000000000000000011431301675746700240670ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/5/transforms/table-style.xslt000066400000000000000000000002541301675746700237400ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/5/transforms/xccdf-alt-titles.xslt000066400000000000000000000005051301675746700246610ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/5/transforms/xccdf-apply-overlay-stig.xslt000066400000000000000000000007541301675746700263550ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/5/transforms/xccdf-removeaux.xslt000066400000000000000000000005041301675746700246110ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/5/transforms/xccdf2csv-stig.py000077500000000000000000000003631301675746700240060ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import xccdf2csv_stig_module if __name__ == "__main__": xccdf2csv_stig_module.main() scap-security-guide-0.1.31/RHEL/5/transforms/xccdf2html.xslt000066400000000000000000000005531301675746700235530ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/5/transforms/xccdf2shorthand.xslt000066400000000000000000000005041301675746700245750ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/5/transforms/xccdf2stigformat.xslt000066400000000000000000000007001301675746700247600ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/5/transforms/xccdf2table-byref.xslt000066400000000000000000000006771301675746700250120ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/5/transforms/xccdf2table-cce.xslt000066400000000000000000000007361301675746700244310ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/5/transforms/xccdf2table-profileccirefs.xslt000066400000000000000000000016021301675746700266670ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/5/transforms/xccdf2table-profilecisrefs.xslt000066400000000000000000000007101301675746700267060ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/5/transforms/xccdf2table-profilenistrefs.xslt000066400000000000000000000007101301675746700271050ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/5/transforms/xccdf2table-stig.xslt000066400000000000000000000006761301675746700246500ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/5/utils/000077500000000000000000000000001301675746700175405ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/5/utils/README000066400000000000000000000010241301675746700204150ustar00rootroot00000000000000This file is meant to give a quick overview to some of the scripts located in this directory. verify-input-sanity.py Purpose: This script can be invoked without arguments to examine the files within src/input to make sure that they are in good shape *prior to* building the XCCDF and OVAL content with the various make commands. Intent: Help XCCDF and OVAL developers spot common mistakes *before* utilizing the Makefile to build the XCCDF and OVAL content. Usage: ../../../shared/utils/verify-input-sanity.py scap-security-guide-0.1.31/RHEL/5/utils/sync-alt-titles.py000077500000000000000000000003651301675746700231550ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import sync_alt_titles_module if __name__ == "__main__": sync_alt_titles_module.main() scap-security-guide-0.1.31/RHEL/5/utils/verify-cce.py000077500000000000000000000003531301675746700221520ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import verify_cce_module if __name__ == "__main__": verify_cce_module.main() scap-security-guide-0.1.31/RHEL/6/000077500000000000000000000000001301675746700164015ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/6/Makefile000066400000000000000000000231451301675746700200460ustar00rootroot00000000000000all: tables guide content dist SHARED = ../../shared include $(SHARED)/product-make.include PROD = rhel6 OVAL_DIRS = $(SHARED_OVAL) $(IN)/oval VENDOR = ssgproject checks: # If openscap on the system supports OVAL-5.11 language version, include also OVAL-5.11 checks # into final list of OVAL checks ifeq ($(OVAL_5_11), 0) # RHEL/6/input/oval/oval_5.11 is empty for now!!! Uncomment the next statement once required # find $(IN)/oval/oval_5.11 -maxdepth 1 -type f -name '*.xml' -exec cp {} $(PROD_OVAL) ';' # System supports OVAL-5.11 => propagate 'RUNTIME_OVAL_VERSION' variable into the environment $(eval MOD_ENV := env RUNTIME_OVAL_VERSION='5.11') $(eval OVAL_DIRS+=$(SHARED_OVAL_5_11)) endif find $(OVAL_DIRS) -name "*.xml" | xargs xmlwf $(MOD_ENV) $(SHARED)/$(UTILS)/combine-ovals.py $(CONF) $(PROD) $(OVAL_DIRS) > $(OUT)/unlinked-$(PROD)-oval.xml xmllint --format --output $(OUT)/unlinked-$(PROD)-oval.xml $(OUT)/unlinked-$(PROD)-oval.xml # example, if needed: for converting XCCDF into shorthand #xccdf2shorthand: # xsltproc -o $(XCCDF_OUTPUT_DIR)/$(PROD)-shorthand.xml $(TRANS)/xccdf2shorthand.xslt $(REFS)/usgcb-$(PROD)desktop-xccdf.xml # tidy -m -xml -utf8 --indent-spaces=0 $(XCCDF_OUTPUT_DIR)/$(PROD)-shorthand.xml table-refs: $(OUT)/xccdf-unlinked-empty-groups.xml xsltproc -stringparam ref "nist" -o $(OUT)/table-$(PROD)-nistrefs.html $(TRANS)/xccdf2table-byref.xslt $< xsltproc -stringparam profile "common" -o $(OUT)/table-$(PROD)-nistrefs-common.html \ $(TRANS)/xccdf2table-profilenistrefs.xslt $< table-idents: $(OUT)/xccdf-unlinked-empty-groups.xml xsltproc -o $(OUT)/table-$(PROD)-cces.html $(TRANS)/xccdf2table-cce.xslt $< table-srgmap: $(OUT)/xccdf-unlinked-empty-groups.xml # the map-to-items filename must be provided relative to the root of the main document being processed xsltproc -stringparam map-to-items "../$<" -o $(OUT)/table-$(PROD)-srgmap.html \ $(TRANS)/table-srgmap.xslt $(REFS)/disa-os-srg-v1r4.xml xsltproc -stringparam flat "y" -stringparam map-to-items "../$<" -o $(OUT)/table-$(PROD)-srgmap-flat.html \ $(TRANS)/table-srgmap.xslt $(REFS)/disa-os-srg-v1r4.xml xmllint --xmlout --html --output $(OUT)/table-$(PROD)-srgmap-flat.xhtml $(OUT)/table-$(PROD)-srgmap-flat.html table-stigs: $(OUT)/xccdf-unlinked-final.xml table-srgmap checks xsltproc -o $(OUT)/table-$(PROD)-stig.html $(TRANS)/xccdf2table-stig.xslt $(REFS)/disa-stig-$(PROD)-v1r12-xccdf.xml xsltproc -o $(OUT)/table-$(PROD)-stig-manual.html $(TRANS)/xccdf2table-stig.xslt $(REFS)/disa-stig-$(PROD)-v1r12-xccdf-manual.xml # xsltproc -stringparam notes "../$(IN)/auxiliary/transition_notes.xml" -o $(OUT)/table-$(PROD)-stig-manual-withnotes.html \ # $(TRANS)/xccdf2table-stig.xslt \ # $(REFS)/disa-stig-$(PROD)-v1r12-xccdf-manual.xml # temporarily retain an output file showing the short titles as well xsltproc -stringparam profile "stig-$(PROD)-server-upstream" -stringparam testinfo "y" -o $(OUT)/table-stig-$(PROD)-testinfo.html \ $(TRANS)/xccdf2table-profileccirefs.xslt $< xsltproc -stringparam overlay "../$(IN)/auxiliary/stig_overlay.xml" -o $(OUT)/unlinked-stig-$(PROD)-xccdf.xml \ $(TRANS)/xccdf-apply-overlay-stig.xslt $< xsltproc -o $(OUT)/table-$(PROD)-stig.html $(TRANS)/xccdf2table-stig.xslt $(OUT)/unlinked-stig-$(PROD)-xccdf.xml tables: table-refs table-idents table-srgmap table-stigs content: $(OUT)/xccdf-unlinked-final.xml checks cp $< $(OUT)/unlinked-$(PROD)-xccdf.xml # Remove auxiliary Groups which are only for use in tables, and not guide output. xsltproc -o $(OUT)/unlinked-$(PROD)-xccdf-guide.xml $(TRANS)/xccdf-removeaux.xslt $(OUT)/unlinked-$(PROD)-xccdf.xml # The relabel-ids.py script chdirs to ./output, so refer to files from there. # Its second argument controls the IDs, as well as the output filenames. # Thus, with ID set to ssg, this creates ssg-$(PROD)-xccdf.xml and ssg-$(PROD)-oval.xml. $(SHARED)/$(UTILS)/cpe-generate.py $(OUT)/unlinked-$(PROD)-oval.xml $(IN)/oval/platform/$(PROD)-cpe-dictionary.xml $(ID) $(SHARED)/$(UTILS)/relabel-ids.py unlinked-$(PROD)-xccdf.xml $(ID) $(SHARED)/$(UTILS)/relabel-ids.py xccdf-unlinked-ocilrefs.xml $(ID) # Once things are relabelled, create a datastream xsltproc --stringparam reverse_DNS org.$(VENDOR).content /usr/share/openscap/xsl/xccdf_1.1_to_1.2.xsl \ $(OUT)/$(ID)-$(PROD)-xccdf.xml > $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml # Update @style attribute of to "SCAP_1.2". Fixes #1059 sed -i 's/style="SCAP_1.1"/style="SCAP_1.2"/' $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml oscap ds sds-compose $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml $(OUT)/$(ID)-$(PROD)-ds.xml # Make a PCI-DSS-centric Benchmark $(SHARED)/$(TRANS)/pcidss/transform_benchmark_to_pcidss.py $(SHARED)/$(TRANS)/pcidss/PCI_DSS.json $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml $(OUT)/$(ID)-$(PROD)-pcidss-xccdf-1.2.xml oscap ds sds-add $(OUT)/$(ID)-$(PROD)-pcidss-xccdf-1.2.xml $(OUT)/$(ID)-$(PROD)-ds.xml # Update @schematron-version attribute in datastream to "1.2". Fixes #1191 # (Workaround for https://github.com/OpenSCAP/openscap/issues/383) sed -i 's/schematron-version="[0-9].[0-9]"/schematron-version="1.2"/' $(OUT)/$(ID)-$(PROD)-ds.xml # Add in CPE content to datastream oscap ds sds-add $(OUT)/$(ID)-$(PROD)-cpe-dictionary.xml $(OUT)/$(ID)-$(PROD)-ds.xml # Fixes https://github.com/OpenSCAP/scap-security-guide/issues/1100 # Fixes https://github.com/OpenSCAP/scap-security-guide/issues/1101 $(SHARED)/$(UTILS)/sds-move-ocil-to-checks.py $(OUT)/$(ID)-$(PROD)-ds.xml $(OUT)/$(ID)-$(PROD)-ds.xml # Make CentOS variants of XCCDF and Source DataStream $(SHARED)/$(UTILS)/enable-derivatives.py --enable-centos -i $(OUT)/$(ID)-$(PROD)-xccdf.xml -o $(OUT)/$(ID)-centos6-xccdf.xml $(SHARED)/$(UTILS)/enable-derivatives.py --enable-centos -i $(OUT)/$(ID)-$(PROD)-ds.xml -o $(OUT)/$(ID)-centos6-ds.xml # Make Scientific Linux variants of XCCDF and Source DataStream $(SHARED)/$(UTILS)/enable-derivatives.py --enable-sl -i $(OUT)/$(ID)-$(PROD)-xccdf.xml -o $(OUT)/$(ID)-sl6-xccdf.xml $(SHARED)/$(UTILS)/enable-derivatives.py --enable-sl -i $(OUT)/$(ID)-$(PROD)-ds.xml -o $(OUT)/$(ID)-sl6-ds.xml content-stig: table-stigs guide checks xmllint --format --output $(OUT)/unlinked-stig-$(PROD)-xccdf.xml $(OUT)/unlinked-stig-$(PROD)-xccdf.xml $(SHARED)/$(UTILS)/cpe-generate.py $(OUT)/unlinked-$(PROD)-oval.xml $(IN)/oval/platform/$(PROD)-cpe-dictionary.xml disa-predraft $(SHARED)/$(UTILS)/relabel-ids.py unlinked-stig-$(PROD)-xccdf.xml disa-predraft xmllint --format --output $(OUT)/disa-predraft-stig-$(PROD)-xccdf.xml $(OUT)/disa-predraft-stig-$(PROD)-xccdf.xml guide: content ifeq ($(OPENSCAP_1_1_OR_LATER), 0) $(SHARED)/$(UTILS)/build-all-guides.py --input $(OUT)/$(ID)-$(PROD)-ds.xml $(SHARED)/$(UTILS)/build-all-guides.py --input $(OUT)/$(ID)-centos6-ds.xml $(SHARED)/$(UTILS)/build-all-guides.py --input $(OUT)/$(ID)-sl6-ds.xml else @echo "Building guides from XCCDF 1.1, use OpenSCAP 1.1.0 or later for guides from datastreams!" $(SHARED)/$(UTILS)/build-all-guides.py --input $(OUT)/$(ID)-$(PROD)-xccdf.xml $(SHARED)/$(UTILS)/build-all-guides.py --input $(OUT)/$(ID)-centos6-xccdf.xml $(SHARED)/$(UTILS)/build-all-guides.py --input $(OUT)/$(ID)-sl6-xccdf.xml endif submission-stig-check: table-stigs cd $(OUT); ../$(SHARED)/$(UTILS)/verify-references.py -p stig-$(PROD)-server-upstream \ --rules-with-disarefs-outside-profile unlinked-$(PROD)-xccdf-prerefs.xml # $(TRANS)/xccdf2csv-stig.py $(OUT)/unlinked-stig-$(PROD)-xccdf.xml > $(OUT)/table-stig.csv # content-usgcb: coming soon validate-xml: oscap xccdf validate-xml $(OUT)/$(ID)-$(PROD)-xccdf.xml oscap oval validate-xml --schematron $(OUT)/$(ID)-$(PROD)-oval.xml oscap cpe validate-xml $(OUT)/$(ID)-$(PROD)-cpe-dictionary.xml oscap oval validate-xml --schematron $(OUT)/$(ID)-$(PROD)-cpe-oval.xml oscap ds sds-validate $(OUT)/$(ID)-$(PROD)-ds.xml oscap xccdf validate-xml $(OUT)/$(ID)-centos6-xccdf.xml oscap ds sds-validate $(OUT)/$(ID)-centos6-ds.xml oscap xccdf validate-xml $(OUT)/$(ID)-sl6-xccdf.xml oscap ds sds-validate $(OUT)/$(ID)-sl6-ds.xml validate: validate-xml ifeq ($(OVAL_5_11), 0) cd $(OUT); ../$(SHARED)/$(UTILS)/verify-references.py --rules-with-invalid-checks --ovaldefs-unused $(ID)-$(PROD)-xccdf.xml else # If we are building against oscap version not supporting OVAL-5.11 language version yet, # don't call verify-references.py with "--rules-with-invalid-checks" argument, since the # OVAL checks using the 5.11 OVAL version will not be included in that case @echo -e "\nWarning:\n" @echo -e "\tRHEL-6 content build using oscap not supporting OVAL-5.11 language version detected!" @echo -e "\tSince the OVAL-5.11 RHEL-6 OVAL checks are missing, will skip test for referenced," @echo -e "\tbut undefined OVAL definitions during content validation. Consider building RHEL-6" @echo -e "\tcontent with version OpenSCAP-1.2.2, or newer in order to perform full content validation!\n" cd $(OUT); ../$(SHARED)/$(UTILS)/verify-references.py --ovaldefs-unused $(ID)-$(PROD)-xccdf.xml endif # Items in dist are expected for distribution in an rpm dist: tables guide content mkdir -p $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-xccdf.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-oval.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-ocil.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-cpe-dictionary.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-cpe-oval.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-ds.xml $(DIST)/content mkdir -p $(DIST)/tables cp $(OUT)/table-*.{x,}html $(DIST)/tables mkdir -p $(DIST)/guide cp $(OUT)/*-guide-*.html $(DIST)/guide cp $(OUT)/$(ID)-centos6-xccdf.xml $(DIST)/content cp $(OUT)/$(ID)-centos6-ds.xml $(DIST)/content cp $(OUT)/$(ID)-sl6-xccdf.xml $(DIST)/content cp $(OUT)/$(ID)-sl6-ds.xml $(DIST)/content clean: rm -rf $(OUT)/* rm -rf $(DIST)/content $(DIST)/guide rm -rf $(BUILD) scap-security-guide-0.1.31/RHEL/6/README000066400000000000000000000031201301675746700172550ustar00rootroot00000000000000Directory Structure of scap-security-guide ------------------------------------------ The input directory contains source files that generate SCAP content, such as XCCDF and OVAL. Since a single large XML file is an impractical format for multiple authors to collaborate on editing SCAP content, efforts are made to keep logically related guidance and checking content in individual files. The transforms directory contains resources that enable the files inside the input directory (or output directory) to be combined and reformatted into valid SCAP formats or human-readable formats. The output directory is used as a storage area for items generated by the files in the inputs directory. It should be empty in the repository, and built on users' individual systems (and rely on its .gitignore file to keep such files out). The output directory contains transitional output (which may only exist in order to be further transformed) as well as final output. The references directory should contain documents which are specified as references from within the SCAP content, or documents that are "seeds," viz. documents whose prose will be translated into SCAP formats, as well as other examples of SCAP content. The utils directory contains helper scripts and other items that are useful to developers but are not essential to producing the project's output. The dist directory contains final outputs, which could be shipped in an RPM for consumption by end-users. Updating the Makefile to copy an item from the outputs directory to the dist directory indicates that an item is considered a final output. scap-security-guide-0.1.31/RHEL/6/input/000077500000000000000000000000001301675746700175405ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/6/input/auxiliary/000077500000000000000000000000001301675746700215475ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/6/input/auxiliary/DISCLAIMER000066400000000000000000000020271301675746700231070ustar00rootroot00000000000000The upstream STIG for Red Hat Enterprise Linux 6 Server profile "stig-rhel6-server-upstream" is developed under the DoD consensus model and DISA FSO Vendor STIG process, serving as the upstream development environment for the Red Hat Enterprise Linux 6 Server STIG. As a result of the upstream/downstream relationship between the SCAP Security Guide project and the official DISA FSO STIG baseline, users should expect variance between SSG and DISA FSO content. For official DISA FSO STIG content, refer to http://iase.disa.mil/stigs/os/unix-linux/Pages/red-hat.aspx. While this profile is packaged by Red Hat as part of the SCAP Security Guide package, please note that commercial support of this SCAP content is NOT available. This profile is provided as example SCAP content with no endorsement for suitability or production readiness. Support for this profile is provided by the upstream SCAP Security Guide community on a best-effort basis. The upstream project homepage is https://www.open-scap.org/security-policies/scap-security-guide/. scap-security-guide-0.1.31/RHEL/6/input/auxiliary/nist_support.xml000066400000000000000000000102751301675746700250470ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/6/input/auxiliary/srg_support.xml000066400000000000000000000157631301675746700246740ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/6/input/auxiliary/stig_overlay.xml000066400000000000000000003700051301675746700250050ustar00rootroot00000000000000 The system must use a separate file system for /tmp. The system must use a separate file system for /var. The system must use a separate file system for /var/log. The system must use a separate file system for the system audit data path. The audit system must alert designated staff members when the audit storage volume approaches capacity. The system must use a separate file system for user home directories. Vendor-provided cryptographic certificates must be installed to verify the integrity of system software. The Red Hat Network Service (rhnsd) service must not be running, unless using RHN or an RHN Satellite. System security patches and updates must be installed and up-to-date. The system package management tool must cryptographically verify the authenticity of system software packages during installation. The system package management tool must cryptographically verify the authenticity of all software packages during installation. A file integrity tool must be installed. The system must use a Linux Security Module at boot time. A file integrity baseline must be created. There must be no .rhosts or hosts.equiv files on the system. The system must use a Linux Security Module configured to enforce limits on system services. The system must use a Linux Security Module configured to limit the privileges of system services. All device files must be monitored by the system Linux Security Module. The system must prevent the root account from logging in from virtual consoles. The system must prevent the root account from logging in from serial consoles. Default operating system accounts, other than root, must be locked. The system must not have accounts configured with blank or null passwords. The /etc/passwd file must not contain password hashes. The root account must be the only account having a UID of 0. The /etc/shadow file must be owned by root. The /etc/shadow file must be group-owned by root. The /etc/shadow file must have mode 0000. The /etc/gshadow file must be owned by root. The /etc/gshadow file must be group-owned by root. The /etc/gshadow file must have mode 0000. The /etc/passwd file must be owned by root. The /etc/passwd file must be group-owned by root. The /etc/passwd file must have mode 0644 or less permissive. The /etc/group file must be owned by root. The /etc/group file must be group-owned by root. The /etc/group file must have mode 0644 or less permissive. Library files must have mode 0755 or less permissive. Library files must be owned by root. All system command files must have mode 0755 or less permissive. All system command files must be owned by root. The system must require passwords to contain a minimum of 14 characters. Users must not be able to change passwords more than once every 24 hours. User passwords must be changed at least every 60 days. Users must be warned 7 days in advance of password expiration. The system must require passwords to contain at least one numeric character. The system must require passwords to contain at least one uppercase alphabetic character. The system must require passwords to contain at least one special character. The system must require passwords to contain at least one lowercase alphabetic character. The system must require at least four characters be changed between the old and new passwords during a password change. The system must disable accounts after three consecutive unsuccessful logon attempts. The system must use a FIPS 140-2 approved cryptographic hashing algorithm for generating account password hashes (system-auth). The system must use a FIPS 140-2 approved cryptographic hashing algorithm for generating account password hashes (login.defs). The system must use a FIPS 140-2 approved cryptographic hashing algorithm for generating account password hashes (libuser.conf). The system boot loader configuration file(s) must be owned by root. The system boot loader configuration file(s) must be group-owned by root. The system boot loader configuration file(s) must have mode 0600 or less permissive. Boot partitions based on VFAT, NTFS, or other non-standard configurations may require alternative measures. The system boot loader must require authentication. The system must require authentication upon booting into single-user and maintenance modes. The system must not permit interactive boot. The system must allow locking of the console screen in text mode. The Department of Defense (DoD) login banner must be displayed immediately prior to, or as part of, console login prompts. The system must implement virtual address space randomization. The system must limit the ability of processes to have simultaneous write and execute access to memory. The system must not send ICMPv4 redirects by default. The system must not send ICMPv4 redirects from any interface. IP forwarding for IPv4 must not be enabled, unless the system is a router. The system must not accept IPv4 source-routed packets on any interface. The system must not accept ICMPv4 redirect packets on any interface. The system must not accept ICMPv4 secure redirect packets on any interface. The system must log Martian packets. The system must not accept IPv4 source-routed packets by default. The system must not accept ICMPv4 secure redirect packets by default. The system must ignore ICMPv4 redirect messages by default. The system must not respond to ICMPv4 sent to a broadcast address. The system must ignore ICMPv4 bogus error responses. The system must be configured to use TCP syncookies. The system must use a reverse-path filter for IPv4 network traffic when possible on all interfaces. The system must use a reverse-path filter for IPv4 network traffic when possible by default. The IPv6 protocol handler must not be bound to the network stack unless needed. The system must ignore ICMPv6 redirects by default. The system must employ a local IPv6 firewall. If the system is a cross-domain system, this is not applicable. The system must employ a local IPv6 firewall. The operating system must connect to external networks or information systems only through managed IPv6 interfaces consisting of boundary protection devices arranged in accordance with an organizational security architecture. If the system is a cross-domain system, this is not applicable. The operating system must prevent public IPv6 access into an organizations internal networks, except as appropriately mediated by managed interfaces employing boundary protection devices. If the system is a cross-domain system, this is not applicable. The system must employ a local IPv6 firewall. The system must employ a local IPv6 firewall. The system must employ a local IPv4 firewall. The system must employ a local IPv4 firewall. The operating system must connect to external networks or information systems only through managed IPv4 interfaces consisting of boundary protection devices arranged in accordance with an organizational security architecture. The operating system must prevent public IPv4 access into an organizations internal networks, except as appropriately mediated by managed interfaces employing boundary protection devices. The system must employ a local IPv4 firewall. The system must employ a local IPv4 firewall. The systems local IPv4 firewall must implement a deny-all, allow-by-exception policy for inbound packets. The system's local firewall must implement a deny-all, allow-by-exception policy for inbound packets. The system's local firewall must implement a deny-all, allow-by-exception policy for inbound packets. The Datagram Congestion Control Protocol (DCCP) must be disabled unless required. The Stream Control Transmission Protocol (SCTP) must be disabled unless required. The Reliable Datagram Sockets (RDS) protocol must be disabled unless required. The Transparent Inter-Process Communication (TIPC) protocol must be disabled unless required. All rsyslog-generated log files must be owned by root. All rsyslog-generated log files must be group-owned by root. All rsyslog-generated log files must have mode 0600 or less permissive. The operating system must back up audit records on an organization defined frequency onto a different system or media than the system being audited. The operating system must support the requirement to centrally manage the content of audit records generated by organization defined information system components. System logs must be rotated daily. Auditing must be implemented. The operating system audit records must be able to be used by a report generation capability. The operating system must audit nonlocal maintenance and diagnostic sessions. The operating system must produce a system-wide (logical or physical) audit trail composed of audit records in a standardized format. The operating system must produce audit records containing sufficient information to establish the identity of any user/subject associated with the event. The operating system must employ automated mechanisms to facilitate the monitoring and control of remote access methods. The operating system must provide the capability to automatically process audit records for events of interest based upon selectable, event criteria. The operating system must fail to an organization defined known state for organization defined types of failures. The operating system must produce audit records containing sufficient information to establish what type of events occurred. Auditing must be enabled at boot by setting a kernel parameter. The system must retain enough rotated audit logs to cover the required log retention period. The system must set a maximum audit log file size. The system must rotate audit log files that reach the maximum file size. The audit system must switch the system to single-user mode when available audit storage volume becomes dangerously low. The audit system must be configured to audit all attempts to alter system time through adjtimex. The audit system must be configured to audit all attempts to alter system time through settimeofday. The audit system must be configured to audit all attempts to alter system time through stime. The audit system must be configured to audit all attempts to alter system time through clock_settime. The audit system must be configured to audit all attempts to alter system time through /etc/localtime. The operating system must automatically audit account creation. The operating system must automatically audit account modification. The operating system must automatically audit account disabling actions. The operating system must automatically audit account termination. The audit system must be configured to audit modifications to the systems network configuration. The audit system must be configured to audit modifications to the systems Mandatory Access Control (MAC) configuration (SELinux). The audit system must be configured to audit all discretionary access control permission modifications using chmod. The audit system must be configured to audit all discretionary access control permission modifications using chown. The audit system must be configured to audit all discretionary access control permission modifications using fchmod. The audit system must be configured to audit all discretionary access control permission modifications using fchmodat. The audit system must be configured to audit all discretionary access control permission modifications using fchown. The audit system must be configured to audit all discretionary access control permission modifications using fchownat. The audit system must be configured to audit all discretionary access control permission modifications using fremovexattr. The audit system must be configured to audit all discretionary access control permission modifications using fsetxattr. The audit system must be configured to audit all discretionary access control permission modifications using lchown. The audit system must be configured to audit all discretionary access control permission modifications using lremovexattr. The audit system must be configured to audit all discretionary access control permission modifications using lsetxattr. The audit system must be configured to audit all discretionary access control permission modifications using removexattr. The audit system must be configured to audit all discretionary access control permission modifications using setxattr. The audit system must be configured to audit failed attempts to access files and programs. The audit system must be configured to audit all use of setuid and setgid programs. The audit system must be configured to audit successful file system mounts. The audit system must be configured to audit user deletions of files and programs. The audit system must be configured to audit changes to the /etc/sudoers file. The audit system must be configured to audit the loading and unloading of dynamic kernel modules. The xinetd service must be disabled if no network services utilizing it are enabled. The xinetd service must be uninstalled if no network services utilizing it are enabled. The telnet-server package must not be installed. The telnet daemon must not be running. The rsh-server package must not be installed. The rshd service must not be running. The rexecd service must not be running. The rlogind service must not be running. The ypserv package must not be installed. The ypbind service must not be running. The tftp-server package must not be installed. The TFTP service must not be running. The cron service must be running. The SSH daemon must be configured to use only the SSHv2 protocol. The SSH daemon must set a timeout interval on idle sessions. The SSH daemon must set a timeout count on idle sessions. The SSH daemon must ignore .rhosts files. The SSH daemon must not allow host-based authentication. The SSH daemon must not allow host-based authentication. The system must not permit root logins using remote access programs such as ssh. The SSH daemon must not allow authentication using an empty password. The SSH daemon must be configured with the Department of Defense (DoD) login banner. The SSH daemon must not permit user environment settings. The SSH daemon must be configured to use only FIPS 140-2 approved ciphers. The operating system must employ FIPS-validated cryptography to protect unclassified information. The operating system must employ NSA-approved cryptography to protect classified information. The avahi service must be disabled. The system clock must be synchronized continuously, or at least daily. The system clock must be synchronized to an authoritative DoD time source. Mail relaying must be restricted. The operating system must uniquely identify and authenticate an organization defined list of specific devices and/or types of devices before establishing a connection. If the system is using LDAP for authentication or account information, the system must use a TLS connection using FIPS 140-2 approved cryptographic algorithms. The LDAP client must use a TLS connection using trust certificates signed by the site CA. The openldap-servers package must not be installed unless required. The graphical desktop environment must set the idle timeout to no more than 15 minutes. The graphical desktop environment must automatically lock after 15 minutes of inactivity and the system must require user to re-authenticate to unlock the environment. The graphical desktop environment must have automatic lock enabled. The system must display a publicly-viewable pattern during a graphical desktop environment session lock. The Automatic Bug Reporting Tool (abrtd) service must not be running. The atd service must be disabled. Automated file system mounting tools must not be enabled unless needed. The ntpdate service must not be running. The oddjobd service must not be running. The qpidd service must not be running. The rdisc service must not be running. Remote file systems must be mounted with the nodev option. Remote file systems must be mounted with the nosuid option. The noexec option must be added to removable media partitions. The system must use SMB client signing for connecting to samba servers using smbclient. The system must use SMB client signing for connecting to samba servers using mount.cifs. The system must prohibit the reuse of passwords within twenty-four iterations. The operating system must employ cryptographic mechanisms to protect information in storage. The operating system must protect the confidentiality and integrity of data at rest. The operating system must employ cryptographic mechanisms to prevent unauthorized disclosure of data at rest unless otherwise protected by alternative physical measures. The system package management tool must verify permissions on all files and directories associated with the audit package. The system package management tool must verify ownership on all files and directories associated with the audit package. The system package management tool must verify group-ownership on all files and directories associated with the audit package. The system package management tool must verify contents of all files associated with the audit package. There must be no world-writable files on the system. The system must use and update a DoD-approved virus scan program. The system must have a host-based intrusion detection tool installed. The x86 Ctrl-Alt-Delete key sequence must be disabled. The postfix service must be enabled for mail delivery. The sendmail package must be removed. The netconsole service must be disabled unless required. X Windows must not be enabled unless required. The xorg-x11-server-common (X Windows) package must not be installed, unless required. The DHCP client must be disabled if not needed. All GIDs referenced in /etc/passwd must be defined in /etc/group All accounts on the system must have unique user or account names Temporary accounts must be provisioned with an expiration date. Emergency accounts must be provisioned with an expiration date. The system must require passwords to contain no more than three consecutive repeating characters. All files and directories must have a valid owner. All files must be owned by a group. A file integrity tool must be used at least weekly to check for unauthorized file changes, particularly the addition of unauthorized system libraries or binaries, or for unauthorized modification to authorized system libraries or binaries. The operating system must employ automated mechanisms, per organization defined frequency, to detect the addition of unauthorized components/devices into the operating system. The operating system must employ automated mechanisms to detect the presence of unauthorized software on organizational information systems and notify designated organizational officials in accordance with the organization defined frequency. The operating system must provide a near real-time alert when any of the organization defined list of compromise or potential compromise indicators occurs. The operating system must detect unauthorized changes to software and information. The operating system must ensure unauthorized, security-relevant configuration changes detected are tracked. Process core dumps must be disabled unless needed. The NFS server must not have the insecure file locking option enabled. The audit system must provide a warning when allocated audit record storage volume reaches a documented percentage of maximum audit record storage capacity. The audit system must identify staff members to receive notifications of audit log storage volume capacity issues. The Bluetooth kernel module must be disabled. The system must have USB Mass Storage disabled unless needed. The system must limit users to 10 simultaneous system logins, or a site-defined number, in accordance with operational requirements. The systems local firewall must implement a deny-all, allow-by-exception policy for forwarded packets. The system must provide VPN connectivity for communications over untrusted networks. If the system does not communicate over untrusted networks, this is not applicable. A login banner must be displayed immediately prior to, or as part of, graphical desktop environment login prompts. The Department of Defense (DoD) login banner must be displayed immediately prior to, or as part of, graphical desktop environment login prompts. The Bluetooth service must be disabled. Accounts must be locked upon 35 days of inactivity. The operating system must manage information system identifiers for users and devices by disabling the user identifier after an organization defined time period of inactivity. The sticky bit must be set on all public directories. All public directories must be owned by a system account. The TFTP daemon must operate in secure mode which provides access only to a single directory on the host file system. The FTP daemon must be configured for logging or verbose mode. The snmpd service must use only SNMP protocol version 3 or newer. The snmpd service must not use a default password. The system default umask for the bash shell must be 077. The system default umask for the csh shell must be 077. The system default umask in /etc/profile must be 077. The system default umask in /etc/login.defs must be 077. The system default umask for daemons must be 027 or 022. There must be no .netrc files on the system. The FTPS/FTP service on the system must be configured with the Department of Defense (DoD) login banner. The system must be configured to require the use of a CAC, PIV compliant hardware token, or Alternate Logon Token (ALT) for authentication. The system must require administrator action to unlock an account locked by excessive failed login attempts. The system must disable accounts after excessive login failures within a 15-minute interval. The operating system must dynamically manage user privileges and associated access authorizations. The operating system must support organization defined one-way flows using hardware mechanisms. The operating system must provide the capability for a privileged administrator to enable/disable organization defined security policy filters. The operating system, upon successful logon, must display to the user the date and time of the last logon (access) via GUI. The operating system, upon successful logon/access, must display to the user the number of unsuccessful logon/access attempts since the last successful logon/access. The operating system must retain the session lock until the user reestablishes access using established identification and authentication procedures. The operating system must employ automated mechanisms to enable authorized users to make information sharing decisions based on access authorizations of sharing partners and access restrictions on information to be shared. The operating system must produce audit records containing sufficient information to establish when (date and time) the events occurred. The operating system must produce audit records containing sufficient information to establish where the events occurred. The operating system must produce audit records containing sufficient information to establish the sources of the events. The operating system must produce audit records containing sufficient information to establish the outcome (success or failure) of the events. The operating system must include organization defined additional, more detailed information in the audit records for audit events identified by type, location, or subject. Operating system must support the capability to centralize the review and analysis of audit records from multiple components within the system. The operating system must support an audit reduction capability. The operating system must use internal system clocks to generate time stamps for audit records. Audit log files must have mode 0640 or less permissive. Audit log files must be owned by root. Audit log directories must have mode 0755 or less permissive. The operating system must allow designated organizational personnel to select which auditable events are to be audited by the operating system. The operating system must support the capability to compile audit records from multiple components within the system into a system-wide (logical or physical) audit trail that is time-correlated to within organization defined level of tolerance. The operating system, for PKI-based authentication must validate certificates by constructing a certification path with status information to an accepted trust anchor. The operating system, for PKI-based authentication must enforce authorized access to the corresponding private key. The operating system must obscure feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals. The operating system must bind security attributes to information to facilitate information flow policy enforcement. The operating system must provide the capability for a privileged administrator to configure organization defined security policy filters to support different security policies. The operating system must enforce logical access restrictions associated with changes to the information system. The operating system must employ automated mechanisms to enforce access restrictions. The operating system must employ automated mechanisms to prevent program execution in accordance with the organization defined specifications. The operating system must dynamically manage identifiers, attributes, and associated access authorizations. The operating system must employ automated mechanisms to restrict the use of maintenance tools to authorized personnel only. The operating system must separate user functionality (including user interface services) from operating system management functionality. The operating system must prevent the presentation of information system management-related functionality at an interface for general (i.e., non-privileged) users. The operating system must isolate security functions from nonsecurity functions. The operating system must isolate security functions enforcing access and information flow control from both non-security functions and from other security functions. The operating system must implement an information system isolation boundary to minimize the number of non-security functions included within the boundary containing security functions. The operating system must implement security functions as a layered structure minimizing interactions between layers of the design and avoiding any dependence by lower layers on the functionality or correctness of higher layers. The operating system must prevent unauthorized and unintended information transfer via shared system resources. The operating system must not share resources used to interface with systems operating at different security levels. The operating system must limit the use of resources by priority. The operating system must prevent remote devices that have established a non-remote connection with the system from communicating outside of the communication path with resources in external networks. The operating system must protect the integrity of transmitted information. The operating system must employ cryptographic mechanisms to recognize changes to information during transmission unless otherwise protected by alternative physical measures. The operating system must maintain the integrity of information during aggregation, packaging, and transformation in preparation for transmission. The operating system must validate the integrity of security attributes exchanged between systems. The operating system must protect the integrity of information during the processes of data aggregation, packaging, and transformation in preparation for transmission. The operating system must employ organization defined information system components with no writeable storage that are persistent across component restart or power on/off. The operating system must install software updates automatically. The operating system must support automated patch management tools to facilitate flaw remediation to organization defined information system components. The operating system must prevent non-privileged users from circumventing malicious code protection capabilities. The operating system must prevent non-privileged users from circumventing intrusion detection and prevention capabilities. The operating system must protect information obtained from intrusion-monitoring tools from unauthorized access, modification, and deletion. The operating system must verify the correct operation of security functions in accordance with organization defined conditions and in accordance with organization defined frequency (if periodic verification). The operating system must provide notification of failed automated security tests. The operating system must provide automated support for the management of distributed security testing. The operating system must check the validity of information inputs. The operating system must support the requirement that organizations, if an information system component failure is detected must activate an organization defined alarm and/or automatically shuts down the operating system. The operating system must associate the identity of the information producer with the information. The operating system must enforce an organization defined Discretionary Access Control (DAC) policy that must allow users to specify and control sharing by named individuals or groups of individuals, or by both. The operating system must enforce approved authorizations for controlling the flow of information within the system in accordance with applicable policy. The operating system must support and maintain the binding of organization defined security attributes to information in storage. The operating system must support and maintain the binding of organization defined security attributes to information in process. The operating system must dynamically reconfigure security attributes in accordance with an identified security policy as information is created and combined. The operating system must only allow authorized entities to change security attributes. The operating system must maintain the binding of security attributes to information with sufficient assurance that the information--attribute association can be used as the basis for automated policy actions. The operating system must only allow authorized users to associate security attributes with information. The operating system must display security attributes in human-readable form on each object output from the system to system output devices to identify an organization-identified set of special dissemination, handling, or distribution instructions using organization-identified human readable, standard naming conventions. The operating system must enforce a Discretionary Access Control (DAC) policy that includes or excludes access to the granularity of a single user. The operating system must automatically implement organization defined safeguards and countermeasures if security functions (or mechanisms) are changed inappropriately. The operating system must enforce a Discretionary Access Control (DAC) policy that limits propagation of access rights. The operating system must preserve organization defined system state information in the event of a system failure. The operating system must take organization defined list of least disruptive actions to terminate suspicious events. The operating system must respond to security function anomalies in accordance with organization defined responses and alternative action(s). The operating system must enforce requirements for the connection of mobile devices to operating systems. The operating system must conduct backups of user-level information contained in the operating system per organization defined frequency to conduct backups consistent with recovery time and recovery point objectives. The operating system must conduct backups of system-level information contained in the information system per organization defined frequency to conduct backups that are consistent with recovery time and recovery point objectives. The operating system, upon successful logon, must display to the user the date and time of the last logon or access via ssh. The system must allow locking of graphical desktop sessions. The system must forward audit records to the syslog service. The audit system must take appropriate action when the audit storage volume is full. The audit system must take appropriate action when there are disk errors on the audit storage volume. The audit system must alert designated staff members when audit storage volume is full. The audit system must alert designated staff members when audit storage volume is generating disk errors. The RPM package management tool must cryptographically verify the authenticity of all software packages during installation. The NFS server must not have the all_squash option enabled. The system package management tool must verify ownership on all files and directories associated with packages. The system package management tool must verify group-ownership on all files and directories associated with packages. The system package management tool must verify permissions on all files and directories associated with packages. The system package management tool must verify contents of all files associated with packages. The mail system must forward all mail for root to one or more system administrators. Audit log files must be group-owned by root. The systems local IPv6 firewall must implement a deny-all, allow-by-exception policy for inbound packets. The system must provide automated support for account management functions. Auditing must be enabled at boot by setting a kernel parameter. Automated file system mounting tools must not be enabled unless needed. The operating system must enforce dual authorization, based on organizational policies and procedures for organization defined privileged commands. The operating system must prevent access to organization defined security-relevant information except during secure, non-operable system states. The operating system must enforce information flow control using explicit security attributes on information, source, and destination objects as a basis for flow control decisions. The operating system must enforce information flow control using protected processing domains (e.g., domain type-enforcement) as a basis for flow control decisions. The operating system must enforce dynamic information flow control based on policy that must allow or disallow information flows based upon changing conditions or operational considerations. The operating system must prevent encrypted data from bypassing content checking mechanisms. The operating system must enforce organization defined limitations on the embedding of data types within other data types. The operating system must enforce information flow control on metadata. The operating system must enforce information flow control using organization defined security policy filters as a basis for flow control decisions. The operating system must provide the capability for a privileged administrator to configure the organization defined security policy filters to support different security policies. The operating system must implement separation of duties through assigned information system access authorizations. The operating system must produce audit records on hardware-enforced, write-once media. The operating system must protect against an individual falsely denying having performed a particular action. The operating system, for PKI-based authentication must map the authenticated identity to the user account. The operating system must enforce password encryption for transmission. The operating system, when transferring information between different security domains, must identify information flows by data type specification and usage. The operating system, when transferring information between different security domains, must decompose information into policy-relevant subcomponents for submission to policy enforcement mechanisms. The operating system must enforce security policies regarding information on interconnected systems. The operating system must enforce a two-person rule for changes to organization defined information system components and system-level information. The operating system must employ automated mechanisms to centrally apply configuration settings. The operating system must employ automated mechanisms to centrally verify configuration settings. The operating system must conduct backups of operating system documentation including security-related documentation per organization defined frequency to conduct backups that is consistent with recovery time and recovery point objectives. The operating system must implement transaction recovery for transaction-based systems. The operating system must use multifactor authentication for local access to privileged accounts. The operating system must use multifactor authentication for local access to non-privileged accounts. The operating system must use multifactor authentication for network access to privileged accounts where one of the factors is provided by a device separate from the information system being accessed. The operating system must use multifactor authentication for network access to non-privileged accounts where one of the factors is provided by a device separate from the operating system being accessed. The operating system must authenticate devices before establishing remote network connections using bidirectional cryptographically based authentication between devices. The operating system must authenticate devices before establishing wireless network connections using bidirectional cryptographically based authentication between devices. The operating system must authenticate devices before establishing network connections using bidirectional cryptographically based authentication between devices. The operating system must implement a configurable capability to automatically disable the operating system if any of the organization defined lists of security violations are detected. The operating system must employ strong identification and authentication techniques in the establishment of nonlocal maintenance and diagnostic sessions. The operating system must protect nonlocal maintenance sessions through the use of a strong authenticator tightly bound to the user. The operating system must use cryptographic mechanisms to protect and restrict access to information on portable digital media. The operating system must protect against or must limit the effects of the organization defined or referenced types of Denial of Service attacks. The operating system must restrict the ability of users to launch Denial of Service attacks against other information systems or networks. The operating system must route organization defined internal communications traffic to organization defined external networks through authenticated proxy servers within the managed interfaces of boundary protection devices. The operating system, at managed interfaces, must deny network traffic and must audit internal users (or malicious code) posing a threat to external information systems. The operating system must route all networked, privileged accesses through a dedicated, managed interface for purposes of access control and auditing. The operating system must prevent discovery of specific system components (or devices) composing a managed interface. The operating system must employ automated mechanisms to enforce strict adherence to protocol format. The operating system must fail securely in the event of an operational failure of a boundary protection device. The operating system must employ cryptographic mechanisms to prevent unauthorized disclosure of information during transmission unless otherwise protected by alternative physical measures. The operating system must maintain the confidentiality of information during aggregation, packaging, and transformation in preparation for transmission. The operating system must establish a trusted communications path between the user and organization defined security functions within the operating system. The operating system must produce, control, and distribute symmetric cryptographic keys using NIST-approved or NSA-approved key management technology and processes. The operating system must produce, control, and distribute symmetric and asymmetric cryptographic keys using NSA-approved key management technology and processes. The operating system must produce, control, and distribute asymmetric cryptographic keys using approved PKI Class 3 certificates or prepositioned keying material. The operating system must produce, control, and distribute asymmetric cryptographic keys using approved PKI Class 3 or Class 4 certificates and hardware security tokens that protect the user's private key. The operating system must employ FIPS-validated cryptography to protect information when it must be separated from individuals who have the necessary clearances, yet lack the necessary access approvals. The operating system must employ FIPS-validate or NSA-approved cryptography to implement digital signatures. The operating system must protect the integrity and availability of publicly available information and applications. The operating system must prohibit remote activation of collaborative computing devices, excluding the organization defined exceptions where remote activation is to be allowed. The operating system must associate security attributes with information exchanged between information systems. The operating system must issue or obtain public key certificates under an appropriate certificate policy from an approved service provider. The operating system must implement detection and inspection mechanisms to identify unauthorized mobile code. The operating system must prevent the execution of prohibited mobile code. The operating system must prevent the download of prohibited mobile code. The operating system must prevent the automatic execution of mobile code in organization defined software applications and must require organization defined actions prior to executing the code. The operating system at organization defined information system components must load and execute the operating environment from hardware-enforced, read-only media. The operating system at organization defined information system components must load and execute organization defined applications from hardware-enforced, read-only media. The operating system must have malicious code protection mechanisms at system entry and exit points to detect and eradicate malicious code transported by electronic mail, electronic mail attachments, web accesses, removable media, or other common means. The operating system must identify potentially security-relevant error conditions. The operating system must generate error messages providing information necessary for corrective actions without revealing organization defined sensitive or potentially harmful information in error logs and administrative messages that could be exploited. The operating system must validate the binding of the information producer's identity to the information. The operating system must maintain reviewer/releaser identity and credentials within the established chain of custody for all information reviewed or released. The operating system must validate the binding of the reviewer's identity to the information at the transfer/release point prior to release/transfer from one security domain to another security domain. The operating system must employ automated mechanisms to alert security personnel of any organization defined inappropriate or unusual activities with security implications. The operating system must use cryptographic mechanisms to protect the integrity of audit information. The operating system must protect the audit records resulting from nonlocal accesses to privileged accounts and the execution of privileged functions. The operating system must monitor for atypical usage of operating system accounts. The operating system, when transferring information between different security domains, must implement policy filters constraining data structure and content to organization defined information security policy requirements. The operating system, when transferring information between different security domains, must detect unsanctioned information. The operating system, when transferring information between different security domains, must prohibit the transfer of unsanctioned information in accordance with the security policy. The operating system must uniquely identify source domains for information transfer. The operating system must uniquely authenticate source domains for information transfer. The operating system must provide additional protection for mobile devices accessed via login by purging information from the device after organization defined number of consecutive, unsuccessful login attempts to the mobile device. The operating system must employ automated mechanisms to centrally manage configuration settings. The operating system must notify the user of the number of successful logins/accesses that occur during the organization defined time period. The operating system must notify the user of the number of unsuccessful login/access attempts that occur during organization defined time period. The operating system must notify the user of organization defined security-related changes to the user's account that occur during the organization defined time period. The operating system must support and maintain the binding of organization defined security attributes to information in transmission. The operating system must ensure remote sessions for accessing an organization defined list of security functions and security-relevant information are audited. The operating system must provide the capability to capture/record and log all content related to a user session. The operating system uniquely must identify destination domains for information transfer. The operating system uniquely must authenticate destination domains for information transfer. The operating system must track problems associated with the information transfer. The operating system must protect nonlocal maintenance sessions by separating the maintenance session from other network sessions with the information system by either physically separated communications paths or logically separated communications paths. The operating system must take corrective actions, when unauthorized mobile code is identified. The operating system must notify, as required, appropriate individuals when accounts are created. The operating system must notify, as required, appropriate individuals when accounts are modified. The operating system must notify, as required, appropriate individuals when account is disabled. The operating system must notify, as required, appropriate individuals for account termination. scap-security-guide-0.1.31/RHEL/6/input/auxiliary/transition_notes.xml000066400000000000000000001467651301675746700257160ustar00rootroot00000000000000 This is covered in RHEL 6 content This is covered in RHEL 6 content This is not covered in RHEL 6 content This is covered in RHEL 6 content This is not covered in RHEL 6 content This is not covered in RHEL 6 content This is not covered in RHEL 6 content This is covered in RHEL 6 content This is covered in RHEL 6 content This is covered in RHEL 6 content This is covered in RHEL 6 content This is covered in RHEL 6 content This is covered in RHEL 6 content This is covered in RHEL 6 content This is covered in RHEL 6 content This is covered in RHEL 6 content This is covered in RHEL 6 content This is covered in RHEL 6 content This is covered in RHEL 6 content This is covered in RHEL 6 content This is covered in RHEL 6 content This is covered in RHEL 6 content This is covered in RHEL 6 content This is not covered in RHEL 6 content This is not covered in RHEL 6 content This is covered in RHEL 6 content This is covered in RHEL 6 content This is covered in RHEL 6 content This is covered in RHEL 6 content This is covered in RHEL 6 content This is not covered in RHEL 6 content This is not covered in RHEL 6 content This is covered in RHEL 6 content This is covered in RHEL 6 content This is covered in RHEL 6 content This is not covered in RHEL 6 content This is covered in RHEL 6 content This is not in the RHEL 6 content. Nosuid / nodev checks address perms on NFS shares. This is not in the RHEL 6 content. The requirements SSL / Localhost will be addressed via the Web Stig, there is no need (IMHO) to require this twice. This is covered in the RHEL 6 content This is covered in the RHEL 6 content. The check CCE-3987-5 meets this requirement This is not covered in the RHEL 6 content. This check is entirely manual and shouldn't be added to RHEL 6 content This is covered in the RHEL 6 content. This is covered in the RHEL 6 content. CCE-4191-3 This is covered in the RHEL 6 content by setting NIS to disabled. This is covered in the RHEL 6 content. This is covered in the RHEL 6 content. This is covered in the RHEL 6 content. By applying patches, this requirement will be addressed This is covered in the RHEL 6 content. By applying patches, this requirement will be addressed This is covered in the RHEL 6 content. This is not covered in the RHEL 6 content. There is a check to disable a GUI, but a GUI is sometimes required for install of 3rd party apps (Oracle, Weblogic, etc) This is covered in the RHEL 6 content in a slightly different manner. CCE-3919-8 is set vsftpd to off This is covered in RHEL 6 content in a slightly different manner. CCE-4092-3 sets pass max days in /etc/login.defs, not shadow. This is covered in RHEL 6 content in a slightly different manner. CCE-17248-6 states a *.*, which would include the authpriv being submitted to the loghost. The audit.rules settings are not called out This is not covered in the RHEL 6 content. This is not covered in the RHEL 6 content. This will have to be a manual check IF it is to be included. This is not covered in the RHEL 6 content. Default settings from RH should be acceptable for this and should be covered in the rpm verify check. This is not covered in the RHEL 6 content. This is covered in the RHEL 6 content in a slightly different manner. NIS+ is to be set to disable / erased. This is covered in the RHEL 6 content in a slightly different manner. CCE-TODO requires .rhosts file to be removed. This is covered in the RHEL 6 content in a slightly different manner. CCE-TODO requires .rhosts file to be removed. This is not covered in the RHEL 6 content. This is not covered in the RHEL 6 content. This is not covered in the RHEL 6 content. This is not covered in the RHEL 6 content. This is covered in the RHEL 6 content. CCE-4236-6 This is covered in RHEL 6 content in a slightly different manner. CCE-17248-6 states a *.*, which would include the authpriv being submitted to the loghost. The audit.rules settings are not called out This is covered in the RHEL 6 content. CCE-4236-6 This is not covered in the RHEL 6 content. The RHEL 6 requirement is to disable FTP This is not covered in the RHEL 6 content. This is not covered in the RHEL 6 content. This is covered in the RHEL 6 content. This is covered in the RHEL 6 content. This is a manual check. Previously have addressed this with DISA about this that HBSS (which is required on systems) meets this requirement. This is not covered in the RHEL 6 content. It is impossible to express network access rules for a particular use case in a baseline. Keep best practice suggestions in a howto guide. Furthermore, iptables obsolete TCPwrappers. This is covered in the RHEL 6 content. CCE-14735-5 This is covered in the RHEL 6 content. CCE-14063-2 This is covered in the RHEL 6 content. CCE-14063-2 This is covered in the RHEL 6 content. CCE-14063-2 This is covered in the RHEL 6 content. CCE-14063-2 This is covered in the RHEL 6 content. CCE-14701-7 This is covered in the RHEL 6 content. This is not covered in the RHEL 6 content. This is nice best practice for a howto guide, but it is unreasonable to dictate which groups a site should use for its privileged users. This is not covered in the RHEL 6 content. This is a manual check. This is covered in the RHEL 6 content. This is covered in the RHEL 6 content. CCE-14300-8 Password hashes are not stored in /etc/group. This is not covered in the RHEL 6 content. This is not covered in the RHEL 6 content. This is a manual check. This check typically fails with accounts for Oracle (ora:dba) is a good example of this. This is not covered in the RHEL 6 content. This is not covered in the RHEL 6 content. This is covered in the RHEL 6 content in a slightly different manner. RHEL 6 admin_space_left_action = ACTION This is covered in the RHEL 6 content in a slightly different manner. RHEL 6 admin_space_left_action = ACTION -w /usr/sbin/useradd -p x -k useradd - Not in RHEL 6 -w /usr/sbin/groupadd -p x -k groupadd - Not in RHEL 6 -w /etc/passwd -p a -k passwd - Is in RHEL 6 -w /etc/shadow -p a -k shadow - Is in RHEL 6 -w /etc/group -p a -k group - Is in RHEL 6 -w /etc/gshadow -p a -k gshadow - Is in RHEL 6 -w /usr/sbin/usermod -p x -k usermod - Not in RHEL 6 -w /usr/sbin/groupmod -p x -k groupmod - Not in RHEL 6 -w /etc/passwd -p w -k passwd - Is in RHEL 6 -w /etc/shadow -p w -k shadow - Is in RHEL 6 -w /etc/group -p w -k group - Is in RHEL 6 -w /etc/gshadow -p w -k gshadow - Is in RHEL 6 -w /usr/bin/passwd -p x -k passwd - Not in RHEL 6 -w /usr/sbin/userdel -p x - Not in RHEL 6 -w /usr/sbin/groupdel -p x - Not in RHEL 6 This is covered in the RHEL 6 content This is not covered in the RHEL 6 content This is not covered in the RHEL 6 content This is not covered in the RHEL 6 content This is not covered in the RHEL 6 content This is not covered in the RHEL 6 content This is not covered in the RHEL 6 content This is not covered in RHEL 6 content This is covered in RHEL 6 content This is covered in RHEL 6 content This is covered in RHEL 6 content This is not covered in RHEL 6 content This is covered in RHEL 6 content This is covered in RHEL 6 content This is covered in RHEL 6 content This is covered in RHEL 6 content This is not covered in RHEL 6 content This is not covered in RHEL 6 content This is not covered in RHEL 6 content This is not covered in RHEL 6 content This is covered in RHEL 6 content This is covered in RHEL 6 content This is covered in RHEL 6 content This is covered in RHEL 6 content This is not covered in RHEL 6 content This is covered in RHEL 6 content in a slightly different manner. CCE-3765-5 sets SNMP to disabled This is covered in RHEL 6 content in a slightly different manner. CCE-3765-5 sets SNMP to disabled This is covered in RHEL 6 content in a slightly different manner. CCE-3765-5 sets SNMP to disabled This is covered in RHEL 6 content This is covered in RHEL 6 content This is covered in RHEL 6 content This is not covered in RHEL 6 content. This is a manual check This is covered in RHEL 6 content This is covered in RHEL 6 content This is not covered in RHEL 6 content This is not covered in RHEL 6 content This is not covered in RHEL 6 content This is not covered in RHEL 6 content This is not covered in RHEL 6 content This is not covered in RHEL 6 content This is not covered in RHEL 6 content This is not covered in RHEL 6 content This is not covered in RHEL 6 content This is not covered in RHEL 6 content This is not covered in RHEL 6 content This is not covered in RHEL 6 content. IPV6 is set to disabled in RHEL 6 content This is not covered in RHEL 6 content. IPV6 is set to disabled in RHEL 6 content This is not covered in RHEL 6 content. This is not covered in RHEL 6 content. This is not covered in RHEL 6 content. This is not covered in RHEL 6 content. This is a manual check This is not covered in RHEL 6 content. AIDE is set to be installed, but not configuration changes are set for the aide.conf in RHEL 6 content. This is not covered in RHEL 6 content. AIDE is set to be installed, but not configuration changes are set for the aide.conf in RHEL 6 content. This is covered in RHEL 6 content. This is covered in RHEL 6 content. This is not covered in the RHEL6 content. AppleTalk support is not included in RHEL6. This is covered in RHEL 6 content. This is covered in RHEL 6 content. This is covered in the RHEL6 content. This is not covered in RHEL 6 content. IPV6 is set to be disabled This is not covered in RHEL 6 content. IPV6 is set to be disabled This is not covered in RHEL 6 content. IPV6 is set to be disabled This is not covered in RHEL 6 content. IPV6 is set to be disabled This is not covered in RHEL 6 content. IPV6 is set to be disabled This is covered in RHEL 6 content in a slightly different way. This is covered in RHEL 6 content in a slightly different way. This is covered in RHEL 6 content This is not covered in RHEL 6 content. IPV6 is set to be disabled This is covered in RHEL 6 content. This is covered in RHEL 6 content. This is a manual check This is not covered in RHEL 6 content. This is not covered in RHEL 6 content. This is not covered in RHEL 6 content. This is not covered in RHEL 6 content. This is not covered in RHEL 6 content. This is not covered in RHEL 6 content. This is not covered in RHEL 6 content. This is not covered in RHEL 6 content. This is not covered in RHEL 6 content. This is not covered in RHEL 6 content. This is not covered in RHEL 6 content. This is not covered in RHEL 6 content. *note* DISA FSO stated HBSS meets this requirement This is covered in the RHEL 6 content This is covered in the RHEL 6 content This is covered in the RHEL 6 content This is covered in the RHEL 6 content This is covered in the RHEL 6 content This is covered in the RHEL 6 content This is not covered in the RHEL 6 content This is covered in the RHEL 6 content This is not covered in the RHEL 6 content This is not covered in the RHEL 6 content This is not covered in the RHEL 6 content. FTP is set to be disabled in RHEL 6 This is covered in the RHEL 6 content. This is covered in the RHEL 6 content. This is covered in the RHEL 6 content. This is not covered in the RHEL 6 content. This is not covered in the RHEL 6 content. This is not covered in the RHEL 6 content. IPV6 is set to be disabled This is covered in the RHEL 6 content. This is not covered in the RHEL 6 content. This is covered in the RHEL 6 content. This is not covered in the RHEL 6 content. This is covered in the RHEL 6 content. This is covered in the RHEL 6 content. This is a manual/procedural check that requires human intervention. How to handle this for a specific OS's STIG is currently under investigation. This was identified as no longer practical for most use cases. This was identified as impractical/costly. This was identified as redundant to the integrity checking baseline requirements. This was identified as not indicative of the underlying driver behavior. This was identified as providing little confidence of proper system state, as it is extremely difficult to query the system with any confidence. This could be considered for a new group that involves ensuring LD_LIBRARY_PATH, LD_PRELOAD, LD_AUDIT, and relative paths do not occur in a particular set of initialization files. At the same time, this represents a level of misconfiguration-checking that may not be appropriate for a baseline. Isn't this redundant to V-914 and V-915? This rule is made irrelevant by the advent of browser-based IM clients. The intent of the check is addressed effectively only by network traffic filtering/inspection. We are manually inspecting the well-formedness of certain configuration files? What? This will be superseded by a new section describing expectations for permissions contained in certain important directories. DAC permissions on device files do not relate to their behavior, which depends on the implementation of the underlying device driver. This is superseded by the system-wide check for improper permissions provided by the package manager. Automating this check became possible with OVAL 5.8. This is superseded by the system-wide check for improper permissions provided by the package manager. Automating this check became possible with OVAL 5.8. The security argument is not apparent or salient. Existence of an ACL is not necessarily a problem, and checking for existence of ACLs on a random selection of files does not achieve any security goals. Alternatives include denying use of any ACLs unless documented, or simply dropping these rules entirely (preferred). This is covered in the RHEL6 content. This is covered in the RHEL6 content for NFS mounts. Need to investigate removable media (for which we put in a ticket for configuration options a long time ago). What is the distinction and purpose of different MAC levels? This is desirable but not practical in many environments. Notably, many other OSes do not even support this capability. This needs to be added to the RHEL6 content. Is this a concern on a modern system? This is covered in the RHEL6 content in a slightly different manner. This needs to be added to the RHEL6 content, as well as a complete re-write of its CUPS section. This is covered in the RHEL6 content in a slightly different manner: iptables is required. This is covered in the RHEL6 content in a slightly different manner: xinetd is required to be disabled, and inetd is not available as part of RHEL6. This could be covered in the RHEL6 content itself, though it seems more like something appropriate for a CTO upon retirement of major OS releases? This is covered in the RHEL6 content in a slightly different manner: xinetd services are not permitted. Finger is still part of RHEL, and so a separate rule could be created for this if we were so inclined. Postfix is the mail server on RHEL 6, and items peculiar to sendmail no longer apply. This needs to be added, but adjusting for Postfix as the mail server on RHEL 6. Is this not redundant to the system-wide requirement for keeping patches up to date (V-783)? This package is only available in EPEL. I suggest that this makes it out of scope. Is this not redundant to the system-wide aide check (V-11945)? Suggest that this be covered in the RHEL6 content in a slightly different manner: ensuring all setuid programs are packaged (which implies vendor provenance). Also, what is the goal of the documentation? The intent or utility of the check procedure is not clear or not actionable. NIS/NIS+/yp should be disabled, as stated in a Rule in the RHEL 6 content. NIS/NIS+/yp are obsolete and should not be running on any modern system. Note that sulogin may be going away in RHEL7. Shawn/Steve to followup. Also, need to add in architecture specific details e.g. s390x Current mapping does not meet requirement as it works for passwords, not keys Per Steve Grubb there is a patch coming to enable this through PAM, so we can map to met_inherently in RHEL 6.4 Put more mappings Where requirement says "must provide.." that is a yes/no. We can map to met_inherently. Poor CCI that can be restructured -- consider removing Perhaps move this to OCIL as interview question Valid requirement but not applicable to STIG-server. Change check procedure to check audit logs, not lastlog /etc/pam.d/gdm can enforce this, update the check Update guidance to say "don't change from default homedir" chmod to 550 or more restrictive, not 700 Reword to allow changes, but ensure we audit them. Language around MUST have absolute paths needs to stay. Path order must be vendor default. This is now default behavior, can be removed For filepermission checks, defer to common criteria accepted values Need to ensure rpm verify flags such files for all ACL content we will change to allow ACLs (via group prose) then mandate their audit (via a rule) change chkconfig off to chkconfig --del revisit polyinstantiation for RHEL7 Installation of NIS will now be a CAT I finding. NIS to be added to banned package list Language to be broadened to beyond just CAC cards per PKI-e Disablement of at service to be implemented in RHEL6 STIG News server content can be removed This requirement can be removed value of 10 is fine change value to 15 DoD - 60 IC - 90 days Update prose to 3 pam lastlog.so noupdate showfailed touch /etc/hushlogins disable account, not remove set shell to nologin met_inherently change to audit dispatch not rsyslog audsp-auremote update tool listing allow install but allow access by priv users (root, chmod 700) update to remove vendor specific language also watch for LD_AUDIT Check exists in the RHEL6 prose, it can be automated and the OVAL for it appears to already exist. rule=audit_rules_unsuccessful_file_modification manual=no Check exists in the RHEL6 prose, it can be automated and the OVAL for it appears to already exist. rule=audit_rules_file_deletion_events manual=no Check exists in the RHEL6 prose, it can be automated and the OVAL for it appears to already exist. rule=audit_rules_login_events manual=no Has no NIST controls associated Check exists in the RHEL6 prose, it can be automated and the OVAL for it appears to already exist. rule=audit_rules_dac_modification manual=no Sendmail is no longer shipped by default. Postfix is the default instead. Equivalent check does not exist in the RHEL6 prose, it can be automated and the OVAL for it does not appear to already exist. rule=null manual=no Sendmail is no longer shipped by default. Postfix is the default instead. Equivalent check does not exist in the RHEL6 prose, it can be automated and the OVAL for it does not appear to already exist. rule=null manual=no Sendmail is no longer shipped by default. Postfix is the default instead. rsyslog is used instead of syslog Check exists in multiple places in the RHEL6 prose, it can be automated and the OVAL for it appears to already exist. rule=postfix_logging manual=no group=ensure_rsyslog_log_file_configuration (redundant?) Has no cce associated This is superseded by a stronger requirement to not permit remote X sessions. Also, the RHEL 5 STIG text is wrong anyway. A non-mess version of this check exists in the RHEL 6 content, but could use further improvement. Check does not exist in the RHEL6 prose, it can be automated and the OVAL for it does not appear to already exist. rule=null manual=no Check does not exist in the RHEL6 prose, it can be automated and the OVAL for it does not appear to already exist. rule=null manual=no At the same time, does this check make sense? Given the many security issues present in ftp, does requiring credentials really provide authentication of the user? Check does not exist in the RHEL6 prose, it can be automated and the OVAL for it does not appear to already exist. rule=null manual=no By default new home directories will be given 700 perms. A STIG is not an unconstrained search for potential misconfigurations. If it were, there would far more files than these to consider. Check does not exist in the RHEL6 prose, it can be automated and the OVAL for it does not appear to already exist. rule=null manual=no Check does not exist in the RHEL6 prose, it can be automated and the OVAL for it does not appear to already exist. rule=null manual=no This check should be superseded by the system-wide check for improper permissions provided by the package manager. Automating this check became possible with OVAL 5.8 Check does not exist in the RHEL6 prose, it can be automated and the OVAL for it does not appear to already exist. rule=null manual=no This should not occur. If such a case is identified it should be brought to the vendor for correction as a bug in the product. Check does not exist in the RHEL6 prose, it cannot be entirely automated and the OVAL for it does not appear to already exist. rule=null manual=yes A simple example, a cronjob can be made to look for devices and compare to previous lists but still requires someone to review it which is a manual process Check does not exist in the RHEL6 prose, it can be automated and the OVAL for it does not appear to already exist. rule=null manual=no Check seems redundant with V-924 Check exists in the RHEL6 prose, it can be automated and the OVAL for it does not appear to already exist. group=specify_anonymous_uid_gid manual=no Check exists in the RHEL6 prose, it can be automated and the OVAL for it does not appear to already exist. group=export_filesystems_read_only manual=no Check exists in the RHEL6 prose, it can be automated and the OVAL for it does not appear to already exist. rule=use_root_squashing_all_exports manual=no Check exists in the RHEL6 prose, it can be automated and the OVAL for it appears to already exist. rule=use_nosuid_option_on_nfs_mounts manual=no Check does not exist in the RHEL6 prose, it can be automated and the OVAL for it does not appear to already exist. rule=blank manual=no There are some mentions in the RHEL6 prose (group=nfs_restrict_access_rpcbind) of using TCP Wrappers to protect certain versions of NFS but nothing specific which may be the intent as this check is not at all specific either. Check exists in the RHEL6 prose, it can be automated and the OVAL for it does not appear to exist. group=ensure_rsyslog_log_file_configuration manual=no Check exists in the RHEL6 prose, it can be automated and the OVAL for it appears to already exist. group=restrict_at_cron_users manual=no Partial check exists in the RHEL6 prose, it can be automated and the OVAL for it appears to already exist. rule=world_writable_files manual=no Check is addressed by the world_writable_files_system_ownership rule to find any files that are world writable but not system owned. System file permissions are addressed through the rpm verification check Partial check exists in the RHEL6 prose, it can be automated and the OVAL for it appears to already exist. rule=world_writable_files_system_ownership manual=no Check is addressed by the world_writable_files_system_ownership rule to find any files that are world writable but not system owned. System file permissions are addressed through the rpm verification check Check does not exist in the RHEL6 prose, it can be automated and the OVAL for it does not appear to already exist. rule=null manual=no A new section targeting permissions in key directories will be added. Check does exist in the RHEL6 prose, it can be automated and the OVAL for it does not appear to exist. rule=restrict_at_cron_users manual=no This and others like it should be covered under a new section targeting permissions in key directories Check exists in the RHEL6 prose, it cannot be automated and the OVAL/OCIL for it does not exist. rule=bios_disable_usb_boot manual=yes Check exists in the RHEL6 prose, it can be automated and the OVAL for it does not appear to exist. rule=smb_restrict_file_sharing manual=no Check exists in the RHEL6 prose, it can be automated and the OVAL for it does not appear to exist. rule=accounts_minimum_age_login_defs manual=no Check exists in the RHEL6 prose, it can be automated and the OVAL for it partially exists. rule=accounts_minimum_age_login_defs manual=no Guide and oval address changing the defaults but don't address the current values Check does not exist in the RHEL6 prose, it can be automated and the OVAL for it not exist. rule=null manual=no Not sure what the argument is for singling these specific things out. Check does exist in the RHEL6 prose, it can be automated and the OVAL for it does exist. rule=gconf_gnome_screensaver_idle_activation_enabled manual=no Check does exist in the RHEL6 prose, it can be automated and the OVAL for it does exist. rule=accounts_password_pam_unix_remember manual=no Check does exist in the RHEL6 prose, it can be automated and the OVAL for it does exist. rule=bootloader_password manual=no Check does not exist in the RHEL6 prose, it can be automated and the OVAL for it does not exist. rule=null manual=no System file permissions will be addressed through the rpm verification check Check does not exist in the RHEL6 prose, it cannot be automated and the OVAL for it does not exist. rule=null manual=yes Check does not exist in the RHEL6 prose, it can be automated and the OVAL for it does not exist. rule=null manual=yes This no longer ships in the default repo's. Should be removed. Check exists in the RHEL6 prose, it can be automated and the OVAL for it does exist. rule=sshd_allow_only_protocol2 manual=no Check does not exists in the RHEL6 prose, it can be automated and the OVAL for it does not exist. rule=null manual=no We do have a section for addressing these sorts of items under the group root_logins, but this particular concern is not addressed. Check does not exists in the RHEL6 prose, it cannot be automated and the OVAL for it does not exist. rule=null manual=yes Cannot programmatically determine if a server is a "valid" DoD time source without maintaining a exhaustive list of potentially sensitive information Check does not exist in the RHEL6 prose, it can be automated and the OVAL for it does not exist. rule=null manual=no This check doesn't actually determine if the file system is making use of journaling. Is it necessary to carry this forward? Check exists in the RHEL6 prose, it can be automated and the OVAL for it does exist. rule=disable_smb_server manual=no Check exists in the RHEL6 prose, it can be automated and the OVAL for it does exist. rule=postfix_server_banner manual=no Check does not exist in the RHEL6 prose, it can be automated and the OVAL for it does not exist. rule=null manual=no If we must include a section on ftp we should at least require it be done over SSH. Check does not exist in the RHEL6 prose, it cannot be automated and the OVAL for it does not exist. rule=null manual=yes This is not really feasible without maintaining an exhaustive list which constantly changes. Also, why NMS? We're allowed to run unauthorized s/w on non-NMS systems? Partial check does exists in the RHEL6 prose, it cannot be entirely automated and partial OVAL check for it does exist. rule=rsyslog_send_messages_to_logserver manual=yes We can verify that logs are sent to a remote server but we cannot determine in an automated fashion if it is "justified and documented using site-defined procedures." Partial check does exists in the RHEL6 prose, it can be automated an OVAL check for it appears to exist. rule=disable_dhcp_client manual=no Check in the RHEL6 prose requires NIS not be installed, it can be automated and an OVAL check for it appears to exist. rule=uninstall_ypserv manual=no Let NIS die. Check in the RHEL6 prose requires most if not all of these files be removed, it can be automated and an OVAL check for it appears to exist. rule=no_rsh_trust_files manual=no What "r-commands" are we suggesting be used with these? V-11988 wants these removed anyway. Check does not exist in the RHEL6 prose, it can be automated and the OVAL for it does not exist. rule=null manual=no This is root:root by default. A new section will be added discussing permissions on key files. Check does not exist in the RHEL6 prose, it can be automated and the OVAL for it does not exist. rule=null manual=no Wouldn't this also be covered by V-783 on keeping the system patched? Check does not exist in the RHEL6 prose, it can be automated and the OVAL for it does not exist. rule=null manual=no Wouldn't this also be covered by V-783 on keeping the system patched? Check does exist in the RHEL6 prose to deny use of TFTP, it can be automated and the OVAL for it does exist. rule=tftp-server manual=no Is it not necessary for other software on the system to be authorized and approved? Check does not exist in the RHEL6 prose, it cannot be automated and the OVAL for it does not exist. rule=null manual=yes Without knowing what hosts should be trusted we can't do this, we don't really want to either. X has numerous issues. If remote connections to X must be used it should be tunneled over something such as SSH. Check does not exist in the RHEL6 prose, it cannot be automated and the OVAL for it does not exist. rule=null manual=yes No automated means to determine presence in DMZ. We should not be allowing FTP. Check does exist in the RHEL6 prose, it can be automated and the OVAL for it does exist. rule=accounts_maximum_age_login_defs manual=yes Partial check for authpriv does exist in the RHEL6 prose, it can be automated and the OVAL for it does exist. group=ensure_rsyslog_log_file_configuration manual=no The authpriv portion seems to be covered in several different places (V-12004, V-941). The value provided by the second half of this is not apparent and not in the RHEL6 prose. Check does exist in the RHEL6 prose, it can be automated and the OVAL for it appears to exist. rule=disable_users_coredumps manual=no Check does exist in the RHEL6 prose, it can be automated and the OVAL for it does exist. rule=sysctl_kernel_exec_shield manual=no Check does exist in the RHEL6 prose, it can be automated and the OVAL for it does exist. rule=sysctl_net_ipv4_conf_all_accept_source_route manual=no This check is split in the RHEL6 prose and addressed in the rule listed above and the sysctl_net_ipv4_conf_default_accept_source_route rule Check does exist in the RHEL6 prose, it can be automated and the OVAL for it appears to exist. rule=uninstall_vsftpd manual=no Per V-12010 don't allow FTP. Lets get rid of these other random FTP rules. Check does exist in the RHEL6 prose, it can be automated and the OVAL for it does exist. rule=sysctl_ipv4_ip_forward manual=no Check does not exist in the RHEL6 prose, it cannot be automated and the OVAL for it does not exist. rule=null manual=yes Any automated effort to check this is at best a token effort. Check does exist in the RHEL6 prose, it can be automated and the OVAL for it does exist. rule=gconf_gnome_screensaver_mode_blank manual=no Check does exist in the RHEL6 prose, it can be automated and the OVAL for it does exist. rule=set_password_hashing_algorithm manual=no Check does exist in the RHEL6 prose, it can be automated and the OVAL for it does exist. group=password_quality_pamcracklib manual=no The cracklib checks are in the RHEL6 prose. Check does exist in the RHEL6 prose, it can be automated and the OVAL for it does exist. rule=no_files_unowned_by_group manual=no Check does exist in the RHEL6 prose, it can be automated and the OVAL for it does exist. rule=userowner_shadow_file manual=no Check does exist in the RHEL6 prose, it can be automated and the OVAL for it does exist. rule=accounts_password_all_shadowed manual=no Check does exist in the RHEL6 prose, it can be automated and the OVAL for it does exist. rule=auditd_data_retention_space_left_action manual=no Partial check does exist in the RHEL6 prose, it can be automated and a partial OVAL for it does exist. rule=audit_rules_usergroup_modification manual=no Auditing of the files is in place but not the commands. Check does exist in the RHEL6 prose, it can be automated and OVAL for it does exist. rule=audit_rules_kernel_module_loading manual=no Check does exist in the RHEL6 prose, it can be automated and OVAL for it does exist. rule=service_kdump_disabled manual=no Check does exist in the RHEL6 prose, it can be automated and OVAL for it does exist. rule=iptables_icmp_disabled manual=no This is accomplished by whitelisting specific types of icmp traffic. Check does exist in the RHEL6 prose, it can be automated and OVAL for it does exist. rule=sysctl_net_ipv4_icmp_echo_ignore_broadcasts manual=no V-22410 and V-22411 are the same. Check does exist in the RHEL6 prose, it can be automated and OVAL for it does exist. rule=sysctl_net_ipv4_conf_all_accept_source_route manual=no This check is split in the RHEL6 prose into the above and the sysctl_net_ipv4_conf_default_accept_source_route rule. Check does exist in the RHEL6 prose, it can be automated and OVAL for it does exist. rule=sysctl_net_ipv4_conf_all_accept_redirects manual=no This check is split in the RHEL6 prose into the above and the sysctl_net_ipv4_conf_default_accept_redirects rule. Check does exist in the RHEL6 prose, it can be automated and OVAL for it does exist. rule=sysctl_net_ipv4_conf_all_send_redirects manual=no This check is split in the RHEL6 prose into the above and the sysctl_net_ipv4_conf_default_send_redirects rule. Partial check does exist in the RHEL6 prose, it can be automated and partial OVAL for it does exist. rule=sysctl_net_ipv4_conf_all_log_martians manual=no This check is split in the RHEL6 prose into the above but no equivalent rule exists for "default." Check does exist in the RHEL6 prose, it can be automated and OVAL for it does exist. rule=sysctl_net_ipv4_tcp_syncookies manual=no Check does exist in the RHEL6 prose, it can be automated and OVAL for it does exist. rule=service_rpcbind_disabled manual=no Check does exist in the RHEL6 prose, it can be automated and OVAL for it does exist. rule=package_rsh-server_removed manual=no Check does not exist in the RHEL6 prose, it can be automated and OVAL for it does not exist. rule=null manual=no No check exists for the client side. Check does not exist in the RHEL6 prose, it cannot be automated and OVAL for it does not exist. rule=null manual=yes No automated way to determine the management interface. Check does exist in the RHEL6 prose, it can be automated and OVAL for it does exist. rule=sshd_use_approved_ciphers manual=no V-22458 and V-22459 are essentially the same. Partial check does exist in the RHEL6 prose, it can be automated and OVAL for it does exist. rule=sshd_limit_user_access manual=no Prose focuses on blacklisting where we should prefer a whitelist. Check does exist in the RHEL6 prose, it can be automated and OVAL for it does exist. rule=sshd_enable_warning_banner manual=no This is incoherent. There is no apparent relationship between the title, description, and fixtext/checktext. The checking text lists user IDs in /etc/passwd, which have nothing to do with group IDs. If something coherent is presented it could be considered for inclusion for RHEL 6, but even then, the possibilities suggest checking for a highly unlikely configuration which is not worth inclusion in a baseline. This is redundant to another rule requiring that the path be the vendor default. This is covered in the RHEL6 content. scap-security-guide-0.1.31/RHEL/6/input/guide.xslt000066400000000000000000000210521301675746700215510ustar00rootroot00000000000000 A conditional clause for check statements. A conditional clause for check statements. This is a placeholder. scap-security-guide-0.1.31/RHEL/6/input/oval/000077500000000000000000000000001301675746700205015ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/6/input/oval/README000066400000000000000000000025001301675746700213560ustar00rootroot00000000000000OVAL checks here are currently defined in individual files of well-formed XML, each of which contains the elements necessary to conduct the check. Each file consists of one definition and the tests, states, objects and variables upon which it depends. When developing new OVAL content make sure that IDs assigned to new definitions, tests, objects, states, and variables are unique and not replicated in any other OVAL check in this directory. The presence of duplicate IDs will result in a "Duplicate ID" warning being printed when the "make all" command is issued. Because each of these XML files is eventually concatenated and reordered to create a valid OVAL document, the presence of duplicate IDs can introduce errors when evaluating the OVAL content. Please note that there may be times when it makes sense to duplicate an object assuming that the object is *exactly* the same across OVAL checks. This warning is meant to discourage the accidental introduction of duplicate IDs. Interrogatory checks (which cannot be automated) may be defined in the OCIL language and stored here. As soon as it supports newer OVAL versions, checks may also be defined in (or replaced by translations of) the SC language and compiled into OVAL using the scc tool. More information is available at: http://oss.tresys.com/projects/scc scap-security-guide-0.1.31/RHEL/6/input/oval/accounts_password_pam_dcredit.xml000066400000000000000000000032151301675746700273200ustar00rootroot00000000000000 Set Password dcredit Requirements Red Hat Enterprise Linux 6 The password dcredit should meet minimum requirements /etc/pam.d/system-auth ^\s*password\s+(?:(?:required)|(?:requisite))\s+pam_cracklib\.so.*dcredit=(-?\d+)(?:[\s]|$) 1 1 scap-security-guide-0.1.31/RHEL/6/input/oval/accounts_password_pam_difok.xml000066400000000000000000000031651301675746700270020ustar00rootroot00000000000000 Set Password difok Requirements Red Hat Enterprise Linux 6 The password difok should meet minimum requirements /etc/pam.d/system-auth ^\s*password\s+(?:(?:required)|(?:requisite))\s+pam_cracklib\.so.*difok=(\d+)(?:[\s]|$) 1 1 scap-security-guide-0.1.31/RHEL/6/input/oval/accounts_password_pam_lcredit.xml000066400000000000000000000032151301675746700273300ustar00rootroot00000000000000 Set Password lcredit Requirements Red Hat Enterprise Linux 6 The password lcredit should meet minimum requirements /etc/pam.d/system-auth ^\s*password\s+(?:(?:required)|(?:requisite))\s+pam_cracklib\.so.*lcredit=(-?\d+)(?:[\s]|$) 1 1 scap-security-guide-0.1.31/RHEL/6/input/oval/accounts_password_pam_maxrepeat.xml000066400000000000000000000032011301675746700276630ustar00rootroot00000000000000 Set Password maxrepeat Requirements Red Hat Enterprise Linux 6 The password maxrepeat should meet minimum requirements using pam_pwquality /etc/pam.d/system-auth ^\s*password\s+(?:(?:required)|(?:requisite))\s+pam_cracklib\.so.*maxrepeat=([0-9]*).*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/accounts_password_pam_minclass.xml000066400000000000000000000032741301675746700275200ustar00rootroot00000000000000 Set Password minclass Requirements Red Hat Enterprise Linux 6 The password minclass should meet the minimum requirements /etc/pam.d/system-auth ^[\s]*password[\s]+(?:(?:required)|(?:requisite))[\s]+[\w_\.\-=\s]+[\s]minclass=(\d+)(?:[\s]|$) 1 1 scap-security-guide-0.1.31/RHEL/6/input/oval/accounts_password_pam_minlen.xml000066400000000000000000000031211301675746700271600ustar00rootroot00000000000000 Set Password minlen Requirements Red Hat Enterprise Linux 6 The password minlen should meet minimum requirements /etc/pam.d/system-auth ^\s*password\s+(?:(?:required)|(?:requisite))\s+pam_cracklib\.so.*minlen=(-?\d+)(?:[\s]|$) 1 1 scap-security-guide-0.1.31/RHEL/6/input/oval/accounts_password_pam_ocredit.xml000066400000000000000000000032151301675746700273330ustar00rootroot00000000000000 Set Password ocredit Requirements Red Hat Enterprise Linux 6 The password ocredit should meet minimum requirements /etc/pam.d/system-auth ^\s*password\s+(?:(?:required)|(?:requisite))\s+pam_cracklib\.so.*ocredit=(-?\d+)(?:[\s]|$) 1 1 scap-security-guide-0.1.31/RHEL/6/input/oval/accounts_password_pam_retry.xml000066400000000000000000000030231301675746700270440ustar00rootroot00000000000000 Set Password retry Requirements Red Hat Enterprise Linux 6 The password retry should meet minimum requirements /etc/pam.d/system-auth ^\s*password\s+(?:(?:required)|(?:requisite))\s+pam_cracklib\.so.*retry=([0-9]*).*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/accounts_password_pam_ucredit.xml000066400000000000000000000032151301675746700273410ustar00rootroot00000000000000 Set Password ucredit Requirements Red Hat Enterprise Linux 6 The password ucredit should meet minimum requirements /etc/pam.d/system-auth ^\s*password\s+(?:(?:required)|(?:requisite))\s+pam_cracklib\.so.*ucredit=(-?\d+)(?:[\s]|$) 1 1 scap-security-guide-0.1.31/RHEL/6/input/oval/audit_rules_dac_modification_chmod.xml000066400000000000000000000075431301675746700302620ustar00rootroot00000000000000 Audit Discretionary Access Control Modification Events - chmod Red Hat Enterprise Linux 6 The changing of file permissions and attributes should be audited. /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+chmod[\s]+)(?:.*-F\s+auid>=500[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+chmod[\s]+)(?:.*-F\s+auid>=500[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/audit_rules_dac_modification_chown.xml000066400000000000000000000075351301675746700303070ustar00rootroot00000000000000 Audit Discretionary Access Control Modification Events - chown Red Hat Enterprise Linux 6 The changing of file permissions and attributes should be audited. /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+chown[\s]+)(?:.*-F\s+auid>=500[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+chown[\s]+)(?:.*-F\s+auid>=500[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/audit_rules_dac_modification_fchmod.xml000066400000000000000000000075651301675746700304340ustar00rootroot00000000000000 Audit Discretionary Access Control Modification Events - fchmod Red Hat Enterprise Linux 6 The changing of file permissions and attributes should be audited. /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+fchmod[\s]+)(?:.*-F\s+auid>=500[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+fchmod[\s]+)(?:.*-F\s+auid>=500[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/audit_rules_dac_modification_fchmodat.xml000066400000000000000000000076451301675746700307600ustar00rootroot00000000000000 Audit Discretionary Access Control Modification Events - fchmodat Red Hat Enterprise Linux 6 The changing of file permissions and attributes should be audited. /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+fchmodat[\s]+)(?:.*-F\s+auid>=500[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+fchmodat[\s]+)(?:.*-F\s+auid>=500[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/audit_rules_dac_modification_fchown.xml000066400000000000000000000075651301675746700304600ustar00rootroot00000000000000 Audit Discretionary Access Control Modification Events - fchown Red Hat Enterprise Linux 6 The changing of file permissions and attributes should be audited. /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+fchown[\s]+)(?:.*-F\s+auid>=500[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+fchown[\s]+)(?:.*-F\s+auid>=500[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/audit_rules_dac_modification_fchownat.xml000066400000000000000000000076451301675746700310040ustar00rootroot00000000000000 Audit Discretionary Access Control Modification Events - fchownat Red Hat Enterprise Linux 6 The changing of file permissions and attributes should be audited. /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+fchownat[\s]+)(?:.*-F\s+auid>=500[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+fchownat[\s]+)(?:.*-F\s+auid>=500[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/audit_rules_dac_modification_fremovexattr.xml000066400000000000000000000100131301675746700317000ustar00rootroot00000000000000 Audit Discretionary Access Control Modification Events - fremovexattr Red Hat Enterprise Linux 6 The changing of file permissions and attributes should be audited. /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+fremovexattr[\s]+)(?:.*-F\s+auid>=500[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+fremovexattr[\s]+)(?:.*-F\s+auid>=500[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/audit_rules_dac_modification_fsetxattr.xml000066400000000000000000000077031301675746700312120ustar00rootroot00000000000000 Audit Discretionary Access Control Modification Events - fsetxattr Red Hat Enterprise Linux 6 The changing of file permissions and attributes should be audited. /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+fsetxattr[\s]+)(?:.*-F\s+auid>=500[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+fsetxattr[\s]+)(?:.*-F\s+auid>=500[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/audit_rules_dac_modification_lchown.xml000066400000000000000000000075651301675746700304660ustar00rootroot00000000000000 Audit Discretionary Access Control Modification Events - lchown Red Hat Enterprise Linux 6 The changing of file permissions and attributes should be audited. /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+lchown[\s]+)(?:.*-F\s+auid>=500[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+lchown[\s]+)(?:.*-F\s+auid>=500[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/audit_rules_dac_modification_lremovexattr.xml000066400000000000000000000100131301675746700317060ustar00rootroot00000000000000 Audit Discretionary Access Control Modification Events - lremovexattr Red Hat Enterprise Linux 6 The changing of file permissions and attributes should be audited. /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+lremovexattr[\s]+)(?:.*-F\s+auid>=500[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+lremovexattr[\s]+)(?:.*-F\s+auid>=500[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/audit_rules_dac_modification_lsetxattr.xml000066400000000000000000000076731301675746700312260ustar00rootroot00000000000000 Audit Discretionary Access Control Modification Events - lsetxattr Red Hat Enterprise Linux 6 The changing of file permissions and attributes should be audited. /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+lsetxattr[\s]+)(?:.*-F\s+auid>=500[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+lsetxattr[\s]+)(?:.*-F\s+auid>=500[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/audit_rules_dac_modification_removexattr.xml000066400000000000000000000077631301675746700315540ustar00rootroot00000000000000 Audit Discretionary Access Control Modification Events - removexattr Red Hat Enterprise Linux 6 The changing of file permissions and attributes should be audited. /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+removexattr[\s]+)(?:.*-F\s+auid>=500[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+removexattr[\s]+)(?:.*-F\s+auid>=500[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/audit_rules_dac_modification_setxattr.xml000066400000000000000000000076451301675746700310510ustar00rootroot00000000000000 Audit Discretionary Access Control Modification Events - setxattr Red Hat Enterprise Linux 6 The changing of file permissions and attributes should be audited. /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+setxattr[\s]+)(?:.*-F\s+auid>=500[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+setxattr[\s]+)(?:.*-F\s+auid>=500[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/audit_rules_file_deletion_events.xml000066400000000000000000000022611301675746700300120ustar00rootroot00000000000000 Audit File Deletion Events Red Hat Enterprise Linux 6 Audit files deletion events. /etc/audit/audit.rules ^\-a\s+always,exit\s+(\-F\s+arch=(b64|b32)\s+)?\-S\s+rmdir\s+\-S\s+unlink\s+\-S\s+unlinkat\s+\-S\s+rename\s+\-S\s+renameat\s+\-F\s+auid>=500\s+\-F\s+auid!=4294967295\s+\-k\s+[-\w]+\s*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/audit_rules_immutable.xml000066400000000000000000000017371301675746700256120ustar00rootroot00000000000000 Make Audit Configuration Immutable Red Hat Enterprise Linux 6 Force a reboot to change audit rules is enabled /etc/audit/audit.rules ^\-e\s+2\s*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/audit_rules_kernel_module_loading.xml000066400000000000000000000065061301675746700301540ustar00rootroot00000000000000 Audit Kernel Module Loading and Unloading Red Hat Enterprise Linux 6 The audit rules should be configured to log information about kernel module loading and unloading. /etc/audit/audit.rules ^\-w[\s]+/sbin/insmod[\s]+\-p[\s]+\b([raw]*x[raw]*)\b[\s]+\-k[\s]+[-\w]+[\s]*$ 1 /etc/audit/audit.rules ^\-w[\s]+/sbin/rmmod[\s]+\-p[\s]+\b([raw]*x[raw]*)\b[\s]+\-k[\s]+[-\w]+[\s]*$ 1 /etc/audit/audit.rules ^\-w\s+/sbin/modprobe[\s]+\-p[\s]+\b([raw]*x[raw]*)\b[\s]+\-k[\s]+[-\w]+[\s]*$ 1 /etc/audit/audit.rules ^\-a\s+always,exit\s+(\-F\s+arch=(b64|b32)\s+)?\-S\s+init_module\s+\-S\s+delete_module\s+\-k\s+[-\w]+\s*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/audit_rules_login_events.xml000066400000000000000000000046261301675746700263270ustar00rootroot00000000000000 Record Attempts to Alter Login and Logout Events Red Hat Enterprise Linux 6 Audit rules should be configured to log successful and unsuccessful login and logout events. /etc/audit/audit.rules ^\-w\s+/var/log/tallylog\s+\-p\s+wa\s+\-k\s+[-\w]+\s*$ 1 /etc/audit/audit.rules ^\-w\s+/var/run/faillock/\s+\-p\s+wa\s+\-k\s+[-\w]+\s*$ 1 /etc/audit/audit.rules ^\-w\s+/var/log/lastlog\s+\-p\s+wa\s+\-k\s+[-\w]+\s*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/audit_rules_mac_modification.xml000066400000000000000000000022741301675746700271150ustar00rootroot00000000000000 Record Events that Modify the System's Mandatory Access Controls Red Hat Enterprise Linux 6 Audit rules that detect changes to the system's mandatory access controls (SELinux) are enabled. /etc/audit/audit.rules ^\-w[\s]+/etc/selinux/[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s]+\-k[\s]+[-\w]+[\s]*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/audit_rules_media_export.xml000066400000000000000000000021561301675746700263070ustar00rootroot00000000000000 Audit Information Export To Media Red Hat Enterprise Linux 6 Audit rules that detect the mounting of filesystems should be enabled. /etc/audit/audit.rules ^\-a\s+always,exit\s+(\-F\s+arch=(b64|b32)\s+)?\-S\s+mount\s+\-F\s+auid>=500\s+\-F\s+auid!=4294967295\s+\-k\s+[-\w]+\s*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/audit_rules_networkconfig_modification.xml000066400000000000000000000110431301675746700312260ustar00rootroot00000000000000 Record Events that Modify the System's Network Environment Red Hat Enterprise Linux 6 The network environment should not be modified by anything other than administrator action. Any change to network parameters should be audited. /etc/audit/audit.rules ^\-a\s+always,exit\s+(\-F\s+arch=(b64|b32)\s+)?\-S\s+sethostname\s+\-S\s+setdomainname\s+\-k\s+[-\w]+\s*$ 1 /etc/audit/audit.rules ^\-w[\s]+/etc/issue[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s]+\-k[\s]+[-\w]+[\s]*$ 1 /etc/audit/audit.rules ^\-w[\s]+/etc/issue\.net[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s]+\-k[\s]+[-\w]+[\s]*$ 1 /etc/audit/audit.rules ^\-w[\s]+/etc/hosts[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s]+\-k[\s]+[-\w]+[\s]*$ 1 /etc/audit/audit.rules ^\-w[\s]+/etc/sysconfig/network[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s]+\-k[\s]+[-\w]+[\s]*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/audit_rules_privileged_commands.xml000066400000000000000000000214241301675746700276410ustar00rootroot00000000000000 Ensure auditd Collects Information on the Use of Privileged Commands Red Hat Enterprise Linux 6 Audit rules about the Information on the Use of Privileged Commands are enabled \/(?:(?!dev|proc|sys).)+ ^.*$ state_setuid_or_setgid_set true true -a always,exit -F path= -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged /etc/audit/audit.rules ^[\s]*(-a always,exit -F path=[^\n]+ -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged)[\s]*$ 1 state_proper_always_exit_rule_but_for_unprivileged_command variable_dimension_of_object_system_privileged_commands scap-security-guide-0.1.31/RHEL/6/input/oval/audit_rules_session_events.xml000066400000000000000000000045311301675746700266750ustar00rootroot00000000000000 Record Attempts to Alter Process and Session Initiation Information Red Hat Enterprise Linux 6 Audit rules should capture information about session initiation. /etc/audit/audit.rules ^\-w\s+/var/run/utmp\s+\-p\s+wa\s+\-k\s+[-\w]+\s*$ 1 /etc/audit/audit.rules ^\-w\s+/var/log/btmp\s+\-p\s+wa\s+\-k\s+[-\w]+\s*$ 1 /etc/audit/audit.rules ^\-w\s+/var/log/wtmp\s+\-p\s+wa\s+\-k\s+[-\w]+\s*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/audit_rules_sysadmin_actions.xml000066400000000000000000000021501301675746700271700ustar00rootroot00000000000000 Audit System Administrator Actions Red Hat Enterprise Linux 6 Audit actions taken by system administrators on the system. /etc/audit/audit.rules ^\-w[\s]+/etc/sudoers[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s]+\-k[\s]+[-\w]+[\s]*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/audit_rules_time_adjtimex.xml000066400000000000000000000046221301675746700264520ustar00rootroot00000000000000 Record Attempts to Alter Time Through Adjtimex Red Hat Enterprise Linux 6 Record attempts to alter time through adjtimex. /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+-F[\s]+arch=b32.*-S[\s]+adjtimex[\s]+.*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+-F[\s]+arch=b64.*-S[\s]+adjtimex[\s]+.*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/audit_rules_time_clock_settime.xml000066400000000000000000000051061301675746700274700ustar00rootroot00000000000000 Record Attempts to Alter Time Through Clock_settime Red Hat Enterprise Linux 6 Record attempts to alter time through clock_settime. /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+-F[\s]+arch=b32[\s]+-S[\s]+clock_settime[\s]+-F[\s]+a0=(?:0x)?0[\s]+(?:-F[\s]+key=|-k[\s]+)time-change[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+-F[\s]+arch=b64[\s]+-S[\s]+clock_settime[\s]+-F[\s]+a0=(?:0x)?0[\s]+(?:-F[\s]+key=|-k[\s]+)time-change[\s]*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/audit_rules_time_settimeofday.xml000066400000000000000000000047301301675746700273420ustar00rootroot00000000000000 Record Attempts to Alter Time Through Settimeofday Red Hat Enterprise Linux 6 Record attempts to alter time through settimeofday. /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+-F[\s]+arch=b32.*-S[\s]+settimeofday[\s]+.*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+-F[\s]+arch=b64.*-S[\s]+settimeofday[\s]+.*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/audit_rules_time_stime.xml000066400000000000000000000032621301675746700257650ustar00rootroot00000000000000 Record Attempts to Alter Time Through Stime Red Hat Enterprise Linux 6 Record attempts to alter time through stime. Note that on 64-bit architectures the stime system call is not defined in the audit system calls lookup table. /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+-F[\s]+arch=b32.*-S[\s]+stime[\s]+.*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/audit_rules_time_watch_localtime.xml000066400000000000000000000024601301675746700300020ustar00rootroot00000000000000 Record Attempts to Alter Time Through the Localtime File Red Hat Enterprise Linux 6 Record attempts to alter time through /etc/localtime /etc/audit/audit.rules ^[\s]*-w[\s]+\/etc\/localtime[\s]+-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b.*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/audit_rules_unsuccessful_file_modification.xml000066400000000000000000000111151301675746700320700ustar00rootroot00000000000000 Ensure auditd Collects Unauthorized Access Attempts to Files (unsuccessful) Red Hat Enterprise Linux 6 Audit rules about the Unauthorized Access Attempts to Files (unsuccessful) are enabled /etc/audit/audit.rules ^\-a\s+always,exit\s+\-F\s+arch=b32\s+?\-S\s+creat\s+\-S\s+open\s+\-S\s+openat\s+\-S\s+open_by_handle_at\s+\-S\s+truncate\s+\-S\s+ftruncate\s+\-F\s+exit=\-EACCES\s+\-F\s+auid>=500\s+\-F\s+auid!=4294967295\s+\-k\s+[-\w]+\s*$ 1 /etc/audit/audit.rules ^\-a\s+always,exit\s+\-F\s+arch=b32\s+?\-S\s+creat\s+\-S\s+open\s+\-S\s+openat\s+\-S\s+open_by_handle_at\s+\-S\s+truncate\s+\-S\s+ftruncate\s+\-F\s+exit=\-EPERM\s+\-F\s+auid>=500\s+\-F\s+auid!=4294967295\s+\-k\s+[-\w]+\s*$ 1 /etc/audit/audit.rules ^\-a\s+always,exit\s+\-F\s+arch=b64\s+?\-S\s+creat\s+\-S\s+open\s+\-S\s+openat\s+\-S\s+open_by_handle_at\s+\-S\s+truncate\s+\-S\s+ftruncate\s+\-F\s+exit=\-EACCES\s+\-F\s+auid>=500\s+\-F\s+auid!=4294967295\s+\-k\s+[-\w]+\s*$ 1 /etc/audit/audit.rules ^\-a\s+always,exit\s+\-F\s+arch=b64\s+?\-S\s+creat\s+\-S\s+open\s+\-S\s+openat\s+\-S\s+open_by_handle_at\s+\-S\s+truncate\s+\-S\s+ftruncate\s+\-F\s+exit=\-EPERM\s+\-F\s+auid>=500\s+\-F\s+auid!=4294967295\s+\-k\s+[-\w]+\s*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/audit_rules_usergroup_modification.xml000066400000000000000000000104321301675746700304030ustar00rootroot00000000000000 Audit User/Group Information Red Hat Enterprise Linux 6 Audit rules should detect modification to system files that hold information about users and groups. /etc/audit/audit.rules ^\-w[\s]+/etc/group[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s+]\-k[\s]+\w+[\s]*$ 1 /etc/audit/audit.rules ^\-w[\s]+/etc/passwd[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s]+\-k[\s]+\w+[\s]*$ 1 /etc/audit/audit.rules ^\-w[\s]+/etc/gshadow[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s]+\-k[\s]+\w+[\s]*$ 1 /etc/audit/audit.rules ^\-w[\s]+/etc/shadow[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s]+\-k[\s]+\w+[\s]*$ 1 /etc/audit/audit.rules ^\-w[\s]+/etc/security/opasswd[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s]+\-k[\s]+\w+[\s]*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/avahi_check_ttl.xml000066400000000000000000000024371301675746700243410ustar00rootroot00000000000000 Check Avahi Responses' to TTL Field Red Hat Enterprise Linux 6 Check that Avahi is ignoring packets unless the TTL field is 255. /etc/avahi/avahi-daemon.conf ^[\s]*check\-response\-ttl=yes$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/avahi_disable_publishing.xml000066400000000000000000000024371301675746700262300ustar00rootroot00000000000000 Disable Avahi Publishing Red Hat Enterprise Linux 6 Disable Avahi from publishing records. /etc/avahi/avahi-daemon.conf ^[\s]*disable\-publishing=yes$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/avahi_ip_only.xml000066400000000000000000000051621301675746700240500ustar00rootroot00000000000000 Serve Avahi Only via Required Protocol Red Hat Enterprise Linux 6 Require Avahi to run on IPv4 or IPv6. /etc/avahi/avahi-daemon.conf ^[\s]*use\-ipv4=yes$ 1 /etc/avahi/avahi-daemon.conf ^[\s]*use\-ipv6=yes$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/avahi_prevent_port_sharing.xml000066400000000000000000000025511301675746700266400ustar00rootroot00000000000000 Prevent Other Programs from using Avahi's Port Red Hat Enterprise Linux 6 Ensures that only Avahi is responsible for mDNS traffic coming from the port on the system. /etc/avahi/avahi-daemon.conf ^[\s]*disallow\-other\-stacks=yes$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/avahi_restrict_published_information.xml000066400000000000000000000111551301675746700307010ustar00rootroot00000000000000 Restrict Information Published by Avahi Red Hat Enterprise Linux 6 Prevent user applications from using Avahi to publish services. /etc/avahi/avahi-daemon.conf ^[\s]*disable\-user\-service\-publishing=yes$ 1 /etc/avahi/avahi-daemon.conf ^[\s]*publish\-addresses=no$ 1 /etc/avahi/avahi-daemon.conf ^[\s]*publish\-hinfo=no$ 1 /etc/avahi/avahi-daemon.conf ^[\s]*publish\-workstation=no$ 1 /etc/avahi/avahi-daemon.conf ^[\s]*publish\-domain=no$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/bootloader_audit_argument.xml000066400000000000000000000026621301675746700264530ustar00rootroot00000000000000 Enable Auditing for Processes Which Start Prior to the Audit Daemon Red Hat Enterprise Linux 6 Look for argument audit=1 in the kernel line in /etc/grub.conf. /etc/grub.conf ^\s*kernel\s/vmlinuz(.*)$ 1 ^.*audit=1.*$ scap-security-guide-0.1.31/RHEL/6/input/oval/bootloader_nousb_argument.xml000066400000000000000000000027351301675746700264740ustar00rootroot00000000000000 Disable Kernel Support for USB via Bootloader Configuration Red Hat Enterprise Linux 6 Look for argument "nousb" in the kernel line in /etc/grub.conf /etc/grub.conf ^\s*kernel\s/vmlinuz(.*)$ 1 ^.*nousb.*$ scap-security-guide-0.1.31/RHEL/6/input/oval/bootloader_password.xml000066400000000000000000000021201301675746700252720ustar00rootroot00000000000000 Set Boot Loader Password Red Hat Enterprise Linux 6 The grub boot loader should have password protection enabled. /etc/grub.conf ^[\s]*password[\s]+--encrypted[\s]+.* 1 scap-security-guide-0.1.31/RHEL/6/input/oval/dhcp_client_restrict_options.xml000066400000000000000000000171401301675746700271740ustar00rootroot00000000000000 Minimize DHCP Client Configured Options Red Hat Enterprise Linux 6 Limit the options that the DHCP gets and applies to the DHCP client. /etc/dhcp/dhclient.*\.conf ^[\s]*(request|require|supersede)[\s]+domain\-name[\s]*.*\;[\s]*(?:|(?:#.*))?$ 1 /etc/dhcp/dhclient.*\.conf ^[\s]*(request|require|supersede)[\s]+domain\-name\-servers[\s]*.*\;[\s]*(?:|(?:#.*))?$ 1 /etc/dhcp/dhclient.*\.conf ^[\s]*(request|require|supersede)[\s]+nis\-domain[\s]*.*\;[\s]*(?:|(?:#.*))?$ 1 /etc/dhcp/dhclient.*\.conf ^[\s]*(request|require|supersede)[\s]+nis\-servers[\s]*.*\;[\s]*(?:|(?:#.*))?$ 1 /etc/dhcp/dhclient.*\.conf ^[\s]*(request|require|supersede)[\s]+ntp\-servers[\s]*.*\;[\s]*(?:|(?:#.*))?$ 1 /etc/dhcp/dhclient.*\.conf ^[\s]*(request|require|supersede)[\s]+routers[\s]*.*\;[\s]*(?:|(?:#.*))?$ 1 /etc/dhcp/dhclient.*\.conf ^[\s]*(request|require|supersede)[\s]+time\-offset[\s]*.*\;[\s]*(?:|(?:#.*))?$ 1 /etc/dhcp/dhclient.*\.conf ^[\s]*(request|require|supersede)[\s]+subnet\-mask[\s]*.*\;[\s]*(?:|(?:#.*))?$ 1 /etc/dhcp/dhclient.*\.conf ^[\s]*(request|require|supersede)[\s]+broadcast\-address[\s]*.*\;[\s]*(?:|(?:#.*))?$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/dhcp_server_configure_logging.xml000066400000000000000000000024471301675746700273050ustar00rootroot00000000000000 Configure DHCP Logging Red Hat Enterprise Linux 6 Configure rsyslog to record DHCP daemon errors. /etc/rsyslog.conf ^[\s]*daemon\.\*[\s]+\/var\/log\/daemon\.log$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/dhcp_server_deny_bootp.xml000066400000000000000000000024071301675746700257540ustar00rootroot00000000000000 Deny BOOTP Requests Red Hat Enterprise Linux 6 Prevents the DHCP from responding to BOOTP requests. /etc/dhcp/dhcpd.conf ^[\s]*deny[\s]+bootp\;[\s]*(?:|(?:#.*))?$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/dhcp_server_deny_decline.xml000066400000000000000000000024451301675746700262360ustar00rootroot00000000000000 Deny Decline Messages Red Hat Enterprise Linux 6 Prevents the DHCP from responding to the DHCPDECLINE messages. /etc/dhcp/dhcpd.conf ^[\s]*deny[\s]+declines\;[\s]*(?:|(?:#.*))?$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/dhcp_server_disable_ddns.xml000066400000000000000000000025141301675746700262240ustar00rootroot00000000000000 Disable Dynamic DNS Red Hat Enterprise Linux 6 Prevents DHCP from publishing information about their clients using Dynamic DNS. /etc/dhcp/dhcpd.conf ^[\s]*ddns\-update\-style[\s]+none\;[\s]*(?:|(?:#.*))?$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/dhcp_server_minimize_served_info.xml000066400000000000000000000131051301675746700300130ustar00rootroot00000000000000 Minimize Served DHCP Information Red Hat Enterprise Linux 6 Limits the amount of information that that the DHCP server provides to clients. /etc/dhcp/dhcpd.conf ^[\s]*option[\s]+domain\-name[\s]+.*\;[\s]*(?:|(?:#.*))?$ 1 /etc/dhcp/dhcpd.conf ^[\s]*option[\s]+domain\-name\-servers[\s]+.*\;[\s]*(?:|(?:#.*))?$ 1 /etc/dhcp/dhcpd.conf ^[\s]*option[\s]+nis\-domain[\s]+.*\;[\s]*(?:|(?:#.*))?$ 1 /etc/dhcp/dhcpd.conf ^[\s]*option[\s]+nis\-servers[\s]+.*\;[\s]*(?:|(?:#.*))?$ 1 /etc/dhcp/dhcpd.conf ^[\s]*option[\s]+ntp\-servers[\s]+.*\;[\s]*(?:|(?:#.*))?$ 1 /etc/dhcp/dhcpd.conf ^[\s]*option[\s]+routers[\s]+.*\;[\s]*(?:|(?:#.*))?$ 1 /etc/dhcp/dhcpd.conf ^[\s]*option[\s]+time\-offset[\s]+.*\;[\s]*(?:|(?:#.*))?$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/dir_perms_world_writable_system_owned.xml000066400000000000000000000033651301675746700311160ustar00rootroot00000000000000 Find world writable directories not owned by a system account Red Hat Enterprise Linux 6 All world writable directories should be owned by a system user. / state_gid_is_user_and_world_writable 500 true scap-security-guide-0.1.31/RHEL/6/input/oval/disable_ctrlaltdel_reboot.xml000066400000000000000000000034721301675746700264200ustar00rootroot00000000000000 Disable Ctrl-Alt-Del Reboot Activation Red Hat Enterprise Linux 6 By default, the system will reboot when the Ctrl-Alt-Del key sequence is pressed. /etc/init/control-alt-delete.override ^[\s]*exec[\s]*/sbin/shutdown[\s]*\-r[\s]*now.*$ 1 /etc/init/control-alt-delete.override scap-security-guide-0.1.31/RHEL/6/input/oval/disable_interactive_boot.xml000066400000000000000000000050421301675746700262470ustar00rootroot00000000000000 Disable Interactive Boot Red Hat Enterprise Linux 6 The ability for users to perform interactive startups should be disabled. /etc/sysconfig/init ^[\s]*PROMPT=no[\s]+ 1 /etc/grub.conf ^[\s]*kernel[\s]+.*confirm.*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/display_login_attempts.xml000066400000000000000000000022161301675746700260020ustar00rootroot00000000000000 Set Last Login/Access Notification Red Hat Enterprise Linux 6 Configure the system to notify users of last login/access using pam_lastlog. /etc/pam.d/system-auth ^\s*session\s+(required|requisite)?\s+pam_lastlog.so[\s\w\d\=]+showfailed 1 scap-security-guide-0.1.31/RHEL/6/input/oval/dovecot_disable_plaintext_auth.xml000066400000000000000000000025511301675746700274650ustar00rootroot00000000000000 Disable Plaintext Authentication in Dovecot Red Hat Enterprise Linux 6 Plaintext authentication of mail clients should be disabled. /etc/dovecot/conf.d/10-auth.conf ^[\s]*disable_plaintext_auth[\s]*=[\s]*yes[\s]*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/dovecot_enable_ssl.xml000066400000000000000000000023341301675746700250570ustar00rootroot00000000000000 Enable SSL in Dovecot Red Hat Enterprise Linux 6 SSL capabilities should be enabled for the mail server. /etc/dovecot/conf.d/10-ssl.conf ^[\s]*ssl[\s]*=[\s]*(yes|required)[\s]*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/enable_selinux_bootloader.xml000066400000000000000000000023561301675746700264400ustar00rootroot00000000000000 Enable SELinux in /etc/grub.conf Red Hat Enterprise Linux 6 Check if selinux=0 OR enforcing=0 within /etc/grub.conf lines, fail if found. /etc/grub.conf ^[\s]*kernel[\s]+.*(selinux|enforcing)=0.*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/file_group_owner_grub_conf.xml000066400000000000000000000034661301675746700266250ustar00rootroot00000000000000 File grub.conf Owned By root Group Red Hat Enterprise Linux 6 The grub.conf file should be owned by the root group. By default, this file is located at /boot/grub/grub.conf or, for EFI systems, at /boot/efi/EFI/redhat/grub.conf /boot/grub/grub.conf /boot/efi/EFI/redhat/grub.conf 0 scap-security-guide-0.1.31/RHEL/6/input/oval/file_permissions_grub_conf.xml000066400000000000000000000026771301675746700266350ustar00rootroot00000000000000 File /boot/grub/grub.conf Permissions Red Hat Enterprise Linux 6 File permissions for /boot/grub/grub.conf should be set to 0600 (or stronger). /boot/grub/grub.conf false false false false false false false scap-security-guide-0.1.31/RHEL/6/input/oval/file_permissions_unauthorized_sgid.xml000066400000000000000000000061731301675746700304130ustar00rootroot00000000000000 Find setgid files system packages Red Hat Enterprise Linux 6 All files with setgid should be owned by a base system package / ^.*$ state_file_permissions_unauthorized_sgid state_sgid_whitelist true /bin/cgclassify /bin/cgexec /sbin/netreport /usr/bin/crontab /usr/bin/gnomine /usr/bin/iagno /usr/bin/locate /usr/bin/lockfile /usr/bin/same-gnome /usr/bin/screen /usr/bin/ssh-agent /usr/bin/wall /usr/bin/write /usr/lib64/vte/gnome-pty-helper /usr/libexec/kde4/kdesud /usr/libexec/utempter/utempter /usr/lib/mailman/cgi-bin/admindb /usr/lib/mailman/cgi-bin/admin /usr/lib/mailman/cgi-bin/confirm /usr/lib/mailman/cgi-bin/create /usr/lib/mailman/cgi-bin/edithtml /usr/lib/mailman/cgi-bin/listinfo /usr/lib/mailman/cgi-bin/options /usr/lib/mailman/cgi-bin/private /usr/lib/mailman/cgi-bin/rmlist /usr/lib/mailman/cgi-bin/roster /usr/lib/mailman/cgi-bin/subscribe /usr/lib/mailman/mail/mailman /usr/lib/vte/gnome-pty-helper /usr/sbin/lockdev /usr/sbin/postdrop /usr/sbin/postqueue /usr/sbin/sendmail.sendmail scap-security-guide-0.1.31/RHEL/6/input/oval/file_permissions_unauthorized_suid.xml000066400000000000000000000116411301675746700304250ustar00rootroot00000000000000 Find setuid files from system packages Red Hat Enterprise Linux 6 All files with setuid should be owned by a base system package / ^.*$ state_file_permissions_unauthorized_suid state_suid_whitelist true /bin/fusermount /bin/mount /bin/ping6 /bin/ping /bin/su /bin/umount /lib64/dbus-1/dbus-daemon-launch-helper /lib/dbus-1/dbus-daemon-launch-helper /sbin/mount.ecryptfs_private /sbin/mount.nfs /sbin/pam_timestamp_check /sbin/unix_chkpwd /usr/bin/abrt-action-install-debuginfo-to-abrt-cache /usr/bin/at /usr/bin/chage /usr/bin/chfn /usr/bin/chsh /usr/bin/crontab /usr/bin/gpasswd /usr/bin/kgrantpty /usr/bin/kpac_dhcp_helper /usr/bin/ksu /usr/bin/newgrp /usr/bin/newrole /usr/bin/passwd /usr/bin/pkexec /usr/bin/rcp /usr/bin/rlogin /usr/bin/rsh /usr/bin/sperl5.10.1 /usr/bin/staprun /usr/bin/sudoedit /usr/bin/sudo /usr/bin/Xorg /usr/lib64/amanda/calcsize /usr/lib64/amanda/dumper /usr/lib64/amanda/killpgrp /usr/lib64/amanda/planner /usr/lib64/amanda/rundump /usr/lib64/amanda/runtar /usr/lib64/nspluginwrapper/plugin-config /usr/lib/amanda/calcsize /usr/lib/amanda/dumper /usr/lib/amanda/killpgrp /usr/lib/amanda/planner /usr/lib/amanda/rundump /usr/lib/amanda/runtar /usr/libexec/abrt-action-install-debuginfo-to-abrt-cache /usr/libexec/spice-gtk-x86_64/spice-client-glib-usb-acl-helper /usr/libexec/mc/cons.saver /usr/libexec/openssh/ssh-keysign /usr/libexec/polkit-1/polkit-agent-helper-1 /usr/libexec/pt_chown /usr/libexec/pulse/proximity-helper /usr/lib/nspluginwrapper/plugin-config /usr/sbin/amcheck /usr/sbin/seunshare /usr/sbin/suexec /usr/sbin/userhelper /usr/sbin/usernetctl scap-security-guide-0.1.31/RHEL/6/input/oval/file_user_owner_grub_conf.xml000066400000000000000000000034451301675746700264440ustar00rootroot00000000000000 File grub.conf Owned By root User Red Hat Enterprise Linux 6 The grub.conf file should be owned by the root user. By default, this file is located at /boot/grub/grub.conf or, for EFI systems, at /boot/efi/EFI/redhat/grub.conf /boot/grub/grub.conf /boot/efi/EFI/redhat/grub.conf 0 scap-security-guide-0.1.31/RHEL/6/input/oval/ftp_configure_firewall.xml000066400000000000000000000024471301675746700257510ustar00rootroot00000000000000 Configure the Firewall to Protect the FTP Server Red Hat Enterprise Linux 6 Configure the FTP connection tracking module in iptables. /etc/sysconfig/iptables-config ^[\s]*IPTABLES_MODULES=\".*ip_conntrack_ftp.*\"$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/ftp_disable_uploads.xml000066400000000000000000000022421301675746700252260ustar00rootroot00000000000000 Disable FTP Uploads Red Hat Enterprise Linux 6 Disable FTP Uploads. /etc/vsftpd/vsftpd.conf ^[\s]*write_enable=NO$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/ftp_limit_users.xml000066400000000000000000000053661301675746700244450ustar00rootroot00000000000000 Limit Users Allowed to Access FTP Red Hat Enterprise Linux 6 Only authorized users should be able to access FTP. /etc/vsftpd/vsftpd.conf ^[\s]*userlist_enable=YES$ 1 /etc/vsftpd/vsftpd.conf ^[\s]*userlist_file=\/etc\/vsftp\.ftpusers$ 1 /etc/vsftpd/vsftpd.conf ^[\s]*userlist_deny=NO$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/ftp_restrict_to_anon.xml000066400000000000000000000023231301675746700254500ustar00rootroot00000000000000 Restrict Anonymous Users Red Hat Enterprise Linux 6 Disable anonymous access to FTP. /etc/vsftpd/vsftpd.conf ^[\s]*local_enable=NO$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/gconf_gdm_disable_user_list.xml000066400000000000000000000041061301675746700267230ustar00rootroot00000000000000 Disable the User List Red Hat Enterprise Linux 6 Disable the GUI listing of all known users on the login screen. /etc/gconf/gconf.xml.mandatory/%gconf-tree.xml /gconf/dir/dir/dir/entry[@name='disable_user_list']/@value /etc/gconf/gconf.xml.mandatory/apps/gdm/simple-greeter/%gconf.xml /gconf/entry[@name='disable_user_list']/@value true scap-security-guide-0.1.31/RHEL/6/input/oval/gconf_gdm_enable_warning_gui_banner.xml000066400000000000000000000052541301675746700304000ustar00rootroot00000000000000 Enable GUI Warning Banner Red Hat Enterprise Linux 6 Enable the GUI warning banner. /var/lib/gdm/.gconf/apps/gdm/simple-greeter/%gconf.xml /gconf/entry[@name='banner_message_enable']/@value /etc/gconf/gconf.xml.mandatory/%gconf-tree.xml /gconf/dir/dir/dir/entry[@name='banner_message_enable']/@value /etc/gconf/gconf.xml.mandatory/apps/gdm/simple-greeter/%gconf.xml /gconf/entry[@name='banner_message_enable']/@value true scap-security-guide-0.1.31/RHEL/6/input/oval/gconf_gdm_set_login_banner_text.xml000066400000000000000000000061551301675746700276110ustar00rootroot00000000000000 Set GUI Warning Banner Text Red Hat Enterprise Linux 6 The text to be displayed in the GUI warning banner should be set correctly. /var/lib/gdm/.gconf/apps/gdm/simple-greeter/%gconf.xml /gconf/entry[@name='banner_message_text']/stringvalue[1]/text() /etc/gconf/gconf.xml.mandatory/apps/gdm/simple-greeter/%gconf.xml /gconf/entry[@name='banner_message_text']/stringvalue[1]/text() /etc/gconf/gconf.xml.mandatory/%gconf-tree.xml /gconf/dir/dir/dir/entry[@name='banner_message_text']/stringvalue[1]/text() scap-security-guide-0.1.31/RHEL/6/input/oval/gconf_gnome_disable_automount.xml000066400000000000000000000076561301675746700273200ustar00rootroot00000000000000 Disable GNOME Automounting Red Hat Enterprise Linux 6 The system's default desktop environment, GNOME, will mount devices and removable media (such as DVDs, CDs and USB flash drives) whenever they are inserted into the system. Disable automount and autorun within GNOME. /etc/gconf/gconf.xml.mandatory/apps/nautilus/preferences/%gconf.xml /gconf/entry[@name='media_automount']/@value /etc/gconf/gconf.xml.mandatory/%gconf-tree.xml /gconf/dir/dir/dir/entry[@name='media_automount']/@value false /etc/gconf/gconf.xml.mandatory/apps/nautilus/preferences/%gconf.xml /gconf/entry[@name='media_autorun_never']/@value /etc/gconf/gconf.xml.mandatory/%gconf-tree.xml /gconf/dir/dir/dir/entry[@name='media_autorun_never']/@value true scap-security-guide-0.1.31/RHEL/6/input/oval/gconf_gnome_disable_clock_temperature.xml000066400000000000000000000041051301675746700307570ustar00rootroot00000000000000 Disable the GNOME Clock Temperature Feature Red Hat Enterprise Linux 6 The GNOME clock temperature feature should be disabled. /etc/gconf/gconf.xml.mandatory/apps/panel/applets/clock/prefs/%gconf.xml /gconf/entry[@name='show_temperature']/@value /etc/gconf/gconf.xml.mandatory/%gconf-tree.xml /gconf/dir/dir/dir/dir/dir/entry[@name='show_temperature']/@value false scap-security-guide-0.1.31/RHEL/6/input/oval/gconf_gnome_disable_clock_weather.xml000066400000000000000000000037641301675746700300730ustar00rootroot00000000000000 Disable the GNOME Clock Weather Feature Red Hat Enterprise Linux 6 The GNOME clock weather feature should be disabled. /etc/gconf/gconf.xml.mandatory/apps/panel/applets/clock/prefs/%gconf.xml /gconf/entry[@name='show_weather']/@value /etc/gconf/gconf.xml.mandatory/%gconf-tree.xml /gconf/dir/dir/dir/dir/dir/entry[@name='show_weather']/@value true scap-security-guide-0.1.31/RHEL/6/input/oval/gconf_gnome_disable_ctrlaltdel_reboot.xml000066400000000000000000000043331301675746700307560ustar00rootroot00000000000000 Disable Ctrl-Alt-Del Reboot Key Sequence in GNOME Red Hat Enterprise Linux 6 The Ctrl-Alt-Del reboot key sequence should be set to nothing. /etc/gconf/gconf.xml.mandatory/apps/gnome_settings_daemon/keybindings/%gconf.xml /gconf/entry[@name='power']/stringvalue[1]/text() /etc/gconf/gconf.xml.mandatory/%gconf-tree.xml /gconf/dir/dir/dir/entry[@name='power']/stringvalue[1]/text() scap-security-guide-0.1.31/RHEL/6/input/oval/gconf_gnome_disable_restart_shutdown.xml000066400000000000000000000042661301675746700306760ustar00rootroot00000000000000 Disable the GNOME Login Restart and Shutdown Buttons Red Hat Enterprise Linux 6 Disable GNOME Login restart and shutdown buttons to prevent users from restarting or powering off the system from the login screen. /etc/gconf/gconf.xml.mandatory/apps/gdm/simple-greeter/%gconf.xml /gconf/entry[@name='disable_restart_buttons']/@value /etc/gconf/gconf.xml.mandatory/%gconf-tree.xml /gconf/dir/dir/dir/entry[@name='disable_restart_buttons']/@value true scap-security-guide-0.1.31/RHEL/6/input/oval/gconf_gnome_disable_thumbnailers.xml000066400000000000000000000045401301675746700277470ustar00rootroot00000000000000 Disable All GNOME Thumbnailers Red Hat Enterprise Linux 6 The system's default desktop environment, GNOME, uses a number of different thumbnailer programs to generate thumbnails for any new or modified content in an opened folder. Disable the execution of these thumbnail applications within GNOME. /etc/gconf/gconf.xml.mandatory/desktop/gnome/thumbnailers/%gconf.xml /gconf/entry[@name='disable_all']/@value /etc/gconf/gconf.xml.mandatory/%gconf-tree.xml /gconf/dir/dir/dir/entry[@name='disable_all']/@value true scap-security-guide-0.1.31/RHEL/6/input/oval/gconf_gnome_disable_wifi_create.xml000066400000000000000000000037621301675746700275400ustar00rootroot00000000000000 >Disable WIFI Network Connection Creation in GNOME Red Hat Enterprise Linux 6 Disable GNOME's ability to create a wifi connection. /etc/gconf/gconf.xml.mandatory/apps/nm-applet/%gconf.xml /gconf/entry[@name='disable-wifi-create']/@value /etc/gconf/gconf.xml.mandatory/%gconf-tree.xml /gconf/dir/dir/entry[@name='disable-wifi-create']/@value true scap-security-guide-0.1.31/RHEL/6/input/oval/gconf_gnome_disable_wifi_disconnect.xml000066400000000000000000000041341301675746700304200ustar00rootroot00000000000000 Disable WIFI Network Disconnect Notification in GNOME Red Hat Enterprise Linux 6 Disable GNOME's ability to notify users when disconnecting from a wifi network. /etc/gconf/gconf.xml.mandatory/apps/nm-applet/%gconf.xml /gconf/entry[@name='disable-disconnected-notifications']/@value /etc/gconf/gconf.xml.mandatory/%gconf-tree.xml /gconf/dir/dir/entry[@name='disable-disconnected-notifications']/@value true scap-security-guide-0.1.31/RHEL/6/input/oval/gconf_gnome_disable_wifi_notification.xml000066400000000000000000000042551301675746700307610ustar00rootroot00000000000000 Disable WIFI Network Connection Notification in GNOME Red Hat Enterprise Linux 6 Disable GNOME's ability to notify users when connecting to a wifi network. /etc/gconf/gconf.xml.mandatory/apps/nm-applet/%gconf.xml /gconf/entry[@name='disable-connected-notifications']/@value /etc/gconf/gconf.xml.mandatory/%gconf-tree.xml /gconf/dir/dir/entry[@name='disable-connected-notifications']/@value true scap-security-guide-0.1.31/RHEL/6/input/oval/gconf_gnome_screensaver_idle_activation_enabled.xml000066400000000000000000000043241301675746700327770ustar00rootroot00000000000000 Implement idle activation of screen saver Red Hat Enterprise Linux 6 Idle activation of the screen saver should be enabled. /etc/gconf/gconf.xml.mandatory/apps/gnome-screensaver/%gconf.xml /gconf/entry[@name='idle_activation_enabled']/@value /etc/gconf/gconf.xml.mandatory/%gconf-tree.xml /gconf/dir/dir/entry[@name='idle_activation_enabled']/@value true scap-security-guide-0.1.31/RHEL/6/input/oval/gconf_gnome_screensaver_idle_delay.xml000066400000000000000000000045041301675746700302620ustar00rootroot00000000000000 Configure GUI Screen Locking Red Hat Enterprise Linux 6 The allowed period of inactivity before the screensaver is activated. /etc/gconf/gconf.xml.mandatory/desktop/gnome/session/%gconf.xml /gconf/entry[@name='idle_delay']/@value /etc/gconf/gconf.xml.mandatory/%gconf-tree.xml /gconf/dir/dir/dir/entry[@name='idle_delay']/@value scap-security-guide-0.1.31/RHEL/6/input/oval/gconf_gnome_screensaver_lock_enabled.xml000066400000000000000000000040511301675746700305660ustar00rootroot00000000000000 Implement idle activation of screen lock Red Hat Enterprise Linux 6 Idle activation of the screen lock should be enabled. /etc/gconf/gconf.xml.mandatory/apps/gnome-screensaver/%gconf.xml /gconf/entry[@name='lock_enabled']/@value /etc/gconf/gconf.xml.mandatory/%gconf-tree.xml /gconf/dir/dir/entry[@name='lock_enabled']/@value true scap-security-guide-0.1.31/RHEL/6/input/oval/gconf_gnome_screensaver_max_idle_action.xml000066400000000000000000000042741301675746700313120ustar00rootroot00000000000000 Set GNOME Login Maximum Allowed Inactivity Action Red Hat Enterprise Linux 6 Idle GNOME users should be logged off after a defined period of time. /etc/gconf/gconf.xml.mandatory/desktop/gnome/session/%gconf.xml /gconf/entry[@name='max_idle_action']/stringvalue[1]/text() /etc/gconf/gconf.xml.mandatory/%gconf-tree.xml /gconf/dir/dir/dir/entry[@name='max_idle_action']/stringvalue[1]/text() forced-logout scap-security-guide-0.1.31/RHEL/6/input/oval/gconf_gnome_screensaver_max_idle_time.xml000066400000000000000000000046221301675746700307700ustar00rootroot00000000000000 Set GNOME Login Maximum Allowed Inactivity Red Hat Enterprise Linux 6 The allowed period of inactivity before a user is logged off the system. /etc/gconf/gconf.xml.mandatory/desktop/gnome/session/%gconf.xml /gconf/entry[@name='max_idle_time']/@value /etc/gconf/gconf.xml.mandatory/%gconf-tree.xml /gconf/dir/dir/dir/entry[@name='max_idle_time']/@value scap-security-guide-0.1.31/RHEL/6/input/oval/gconf_gnome_screensaver_mode_blank.xml000066400000000000000000000040531301675746700302610ustar00rootroot00000000000000 Implement blank screen saver Red Hat Enterprise Linux 6 The screen saver should be blank. /etc/gconf/gconf.xml.mandatory/apps/gnome-screensaver/%gconf.xml /gconf/entry[@name='mode']/stringvalue[1]/text() /etc/gconf/gconf.xml.mandatory/%gconf-tree.xml /gconf/dir/dir/entry[@name='mode']/stringvalue[1]/text() blank-only scap-security-guide-0.1.31/RHEL/6/input/oval/grub_enable_fips_mode.xml000066400000000000000000000032441301675746700255200ustar00rootroot00000000000000 Enable FIPS Mode in GRUB Red Hat Enterprise Linux 6 Look for argument fips=1 in the kernel line in /etc/grub.conf. /etc/grub.conf ^\s*kernel\s/vmlinuz(.*)$ 1 ^.*fips=1.*$ scap-security-guide-0.1.31/RHEL/6/input/oval/iptables_sshd_disabled.xml000066400000000000000000000037621301675746700257060ustar00rootroot00000000000000 Disallow inbound firewall access to the SSH Server port. Red Hat Enterprise Linux 6 If inbound SSH access is not needed, the firewall should disallow or reject access to the SSH port (22). /etc/sysconfig/iptables ^-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT$ 1 /etc/sysconfig/ip6tables ^-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT$ 1 kernel_disable_entropy_contribution_for_solid_state_drives.xml000066400000000000000000000066011301675746700353050ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/6/input/oval Configure solid-state drives (SSDs) not to contribute to random-number entropy pool Red Hat Enterprise Linux 6 The add_random sysfs variable should be set correctly for each SSD drive on the system. /sys/block/ [^\/]+ /queue/rotational ^0$ 1 /add_random ^1$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/kernel_module_bluetooth_disabled.xml000066400000000000000000000041051301675746700277640ustar00rootroot00000000000000 Disable bluetooth Kernel Module Red Hat Enterprise Linux 6 The kernel module bluetooth should be disabled. /etc/modprobe.d ^.*\.conf$ ^\s*install\s+bluetooth\s+(/bin/false|/bin/true)$ 1 /etc/modprobe.conf ^\s*install\s+bluetooth\s+(/bin/false|/bin/true)$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/kernel_module_cramfs_disabled.xml000066400000000000000000000040141301675746700272310ustar00rootroot00000000000000 Disable cramfs Kernel Module Red Hat Enterprise Linux 6 The kernel module cramfs should be disabled. /etc/modprobe.d ^.*\.conf$ ^\s*install\s+cramfs\s+(/bin/false|/bin/true)$ 1 /etc/modprobe.conf ^\s*install\s+cramfs\s+(/bin/false|/bin/true)$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/kernel_module_dccp_disabled.xml000066400000000000000000000037461301675746700267020ustar00rootroot00000000000000 Disable dccp Kernel Module Red Hat Enterprise Linux 6 The kernel module dccp should be disabled. /etc/modprobe.d ^.*\.conf$ ^\s*install\s+dccp\s+(/bin/false|/bin/true)$ 1 /etc/modprobe.conf ^\s*install\s+dccp\s+(/bin/false|/bin/true)$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/kernel_module_freevxfs_disabled.xml000066400000000000000000000040621301675746700276110ustar00rootroot00000000000000 Disable freevxfs Kernel Module Red Hat Enterprise Linux 6 The kernel module freevxfs should be disabled. /etc/modprobe.d ^.*\.conf$ ^\s*install\s+freevxfs\s+(/bin/false|/bin/true)$ 1 /etc/modprobe.conf ^\s*install\s+freevxfs\s+(/bin/false|/bin/true)$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/kernel_module_hfs_disabled.xml000066400000000000000000000037231301675746700265440ustar00rootroot00000000000000 Disable hfs Kernel Module Red Hat Enterprise Linux 6 The kernel module hfs should be disabled. /etc/modprobe.d ^.*\.conf$ ^\s*install\s+hfs\s+(/bin/false|/bin/true)$ 1 /etc/modprobe.conf ^\s*install\s+hfs\s+(/bin/false|/bin/true)$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/kernel_module_hfsplus_disabled.xml000066400000000000000000000040371301675746700274470ustar00rootroot00000000000000 Disable hfsplus Kernel Module Red Hat Enterprise Linux 6 The kernel module hfsplus should be disabled. /etc/modprobe.d ^.*\.conf$ ^\s*install\s+hfsplus\s+(/bin/false|/bin/true)$ 1 /etc/modprobe.conf ^\s*install\s+hfsplus\s+(/bin/false|/bin/true)$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/kernel_module_ipv6_option_disabled.xml000066400000000000000000000024661301675746700302430ustar00rootroot00000000000000 Disable IPv6 Kernel Module Functionality via Disable Option Red Hat Enterprise Linux 6 The disable option will allow the IPv6 module to be inserted, but prevent address assignment and activation of the network stack. /etc/modprobe.d ^.*\.conf$ ^\s*options\s+ipv6\s+.*disable=1.*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/kernel_module_jffs2_disabled.xml000066400000000000000000000037711301675746700270010ustar00rootroot00000000000000 Disable jffs2 Kernel Module Red Hat Enterprise Linux 6 The kernel module jffs2 should be disabled. /etc/modprobe.d ^.*\.conf$ ^\s*install\s+jffs2\s+(/bin/false|/bin/true)$ 1 /etc/modprobe.conf ^\s*install\s+jffs2\s+(/bin/false|/bin/true)$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/kernel_module_rds_disabled.xml000066400000000000000000000037231301675746700265540ustar00rootroot00000000000000 Disable rds Kernel Module Red Hat Enterprise Linux 6 The kernel module rds should be disabled. /etc/modprobe.d ^.*\.conf$ ^\s*install\s+rds\s+(/bin/false|/bin/true)$ 1 /etc/modprobe.conf ^\s*install\s+rds\s+(/bin/false|/bin/true)$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/kernel_module_sctp_disabled.xml000066400000000000000000000037461301675746700267420ustar00rootroot00000000000000 Disable sctp Kernel Module Red Hat Enterprise Linux 6 The kernel module sctp should be disabled. /etc/modprobe.d ^.*\.conf$ ^\s*install\s+sctp\s+(/bin/false|/bin/true)$ 1 /etc/modprobe.conf ^\s*install\s+sctp\s+(/bin/false|/bin/true)$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/kernel_module_squashfs_disabled.xml000066400000000000000000000040621301675746700276160ustar00rootroot00000000000000 Disable squashfs Kernel Module Red Hat Enterprise Linux 6 The kernel module squashfs should be disabled. /etc/modprobe.d ^.*\.conf$ ^\s*install\s+squashfs\s+(/bin/false|/bin/true)$ 1 /etc/modprobe.conf ^\s*install\s+squashfs\s+(/bin/false|/bin/true)$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/kernel_module_tipc_disabled.xml000066400000000000000000000037461301675746700267300ustar00rootroot00000000000000 Disable tipc Kernel Module Red Hat Enterprise Linux 6 The kernel module tipc should be disabled. /etc/modprobe.d ^.*\.conf$ ^\s*install\s+tipc\s+(/bin/false|/bin/true)$ 1 /etc/modprobe.conf ^\s*install\s+tipc\s+(/bin/false|/bin/true)$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/kernel_module_udf_disabled.xml000066400000000000000000000037231301675746700265420ustar00rootroot00000000000000 Disable udf Kernel Module Red Hat Enterprise Linux 6 The kernel module udf should be disabled. /etc/modprobe.d ^.*\.conf$ ^\s*install\s+udf\s+(/bin/false|/bin/true)$ 1 /etc/modprobe.conf ^\s*install\s+udf\s+(/bin/false|/bin/true)$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/kernel_module_usb-storage_disabled.xml000066400000000000000000000041531301675746700302150ustar00rootroot00000000000000 Disable usb-storage Kernel Module Red Hat Enterprise Linux 6 The kernel module usb-storage should be disabled. /etc/modprobe.d ^.*\.conf$ ^\s*install\s+usb-storage\s+(/bin/false|/bin/true)$ 1 /etc/modprobe.conf ^\s*install\s+usb-storage\s+(/bin/false|/bin/true)$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/ldap_client_start_tls.xml000066400000000000000000000024731301675746700256060ustar00rootroot00000000000000 Configure LDAP to Use TLS for All Transactions Red Hat Enterprise Linux 6 Require the use of TLS for ldap clients. /etc/pam_ldap.conf ^[\s]*ssl[\s]+start_tls[\s]*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/ldap_client_tls_cacertpath.xml000066400000000000000000000041001301675746700265540ustar00rootroot00000000000000 Configure LDAP CA Certificate Path Red Hat Enterprise Linux 6 Require the use of TLS for ldap clients. /etc/pam_ldap.conf ^[\s]*tls_cacertdir[\s]+/etc/pki/tls/CA$ 1 /etc/pam_ldap.conf ^[\s]*tls_cacertfile[\s]+/etc/pki/tls/CA/.*\.(pem|crt)$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/network_ipv6_default_gateway.xml000066400000000000000000000024501301675746700271060ustar00rootroot00000000000000 Manually Assign IPv6 Router Address Red Hat Enterprise Linux 6 Define default gateways for IPv6 traffic /etc/sysconfig/network-scripts ifcfg-.* ^IPV6_DEFAULTGW=.+$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/network_ipv6_privacy_extensions.xml000066400000000000000000000025531301675746700277010ustar00rootroot00000000000000 Enable Privacy Extensions for IPv6 Red Hat Enterprise Linux 6 Enable privacy extensions for IPv6 /etc/sysconfig/network-scripts ifcfg-.* ^IPV6_PRIVACY=rfc3041$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/network_ipv6_static_address.xml000066400000000000000000000025201301675746700267330ustar00rootroot00000000000000 Manually Assign Global IPv6 Address Red Hat Enterprise Linux 6 Manually configure addresses for IPv6 /etc/sysconfig/network-scripts ifcfg-.* ^IPV6ADDR=.+$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/ntpd_specify_multiple_servers.xml000066400000000000000000000022331301675746700273760ustar00rootroot00000000000000 Specify Multiple Remote ntpd NTP Server for Time Data Red Hat Enterprise Linux 6 Multiple ntpd NTP Servers for time synchronization should be specified. /etc/ntp.conf ^([\s]*server[\s]+.+$){2,}$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/ntpd_specify_remote_server.xml000066400000000000000000000022411301675746700266520ustar00rootroot00000000000000 Specify a Remote ntpd NTP Server for Time Data Red Hat Enterprise Linux 6 A remote ntpd NTP Server for time synchronization should be specified (and dependencies are met) /etc/ntp.conf ^[\s]*server[\s]+.+$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/package_GConf2_installed.xml000066400000000000000000000017061301675746700260170ustar00rootroot00000000000000 Package GConf2 Installed Red Hat Enterprise Linux 6 The RPM package GConf2 should be installed. GConf2 scap-security-guide-0.1.31/RHEL/6/input/oval/package_abrt_removed.xml000066400000000000000000000016371301675746700253560ustar00rootroot00000000000000 Package abrt Removed Red Hat Enterprise Linux 6 The RPM package abrt should be removed. abrt scap-security-guide-0.1.31/RHEL/6/input/oval/package_at_removed.xml000066400000000000000000000016131301675746700250240ustar00rootroot00000000000000 Package at Removed Red Hat Enterprise Linux 6 The RPM package at should be removed. at scap-security-guide-0.1.31/RHEL/6/input/oval/package_autofs_removed.xml000066400000000000000000000016631301675746700257260ustar00rootroot00000000000000 Package autofs Removed Red Hat Enterprise Linux 6 The RPM package autofs should be removed. autofs scap-security-guide-0.1.31/RHEL/6/input/oval/package_avahi_installed.xml000066400000000000000000000015541301675746700260320ustar00rootroot00000000000000 Package avahi Installed Red Hat Enterprise Linux 6 The RPM package avahi should be installed. avahi scap-security-guide-0.1.31/RHEL/6/input/oval/package_bluez_removed.xml000066400000000000000000000015331301675746700255420ustar00rootroot00000000000000 Package bluez Removed Red Hat Enterprise Linux 6 The RPM package bluez should be removed. bluez scap-security-guide-0.1.31/RHEL/6/input/oval/package_cpuspeed_removed.xml000066400000000000000000000017071301675746700262340ustar00rootroot00000000000000 Package cpuspeed Removed Red Hat Enterprise Linux 6 The RPM package cpuspeed should be removed. cpuspeed scap-security-guide-0.1.31/RHEL/6/input/oval/package_cronie_installed.xml000066400000000000000000000017061301675746700262200ustar00rootroot00000000000000 Package cronie Installed Red Hat Enterprise Linux 6 The RPM package cronie should be installed. cronie scap-security-guide-0.1.31/RHEL/6/input/oval/package_cups_removed.xml000066400000000000000000000016371301675746700254000ustar00rootroot00000000000000 Package cups Removed Red Hat Enterprise Linux 6 The RPM package cups should be removed. cups scap-security-guide-0.1.31/RHEL/6/input/oval/package_cyrus-sasl_removed.xml000066400000000000000000000017331301675746700265300ustar00rootroot00000000000000 Package cyrus-sasl Removed Red Hat Enterprise Linux 6 The RPM package cyrus-sasl should be removed. cyrus-sasl scap-security-guide-0.1.31/RHEL/6/input/oval/package_dbus_removed.xml000066400000000000000000000016371301675746700253630ustar00rootroot00000000000000 Package dbus Removed Red Hat Enterprise Linux 6 The RPM package dbus should be removed. dbus scap-security-guide-0.1.31/RHEL/6/input/oval/package_esc_installed.xml000066400000000000000000000015301301675746700255060ustar00rootroot00000000000000 Package esc Installed Red Hat Enterprise Linux 6 The RPM package esc should be installed. esc scap-security-guide-0.1.31/RHEL/6/input/oval/package_gdm_installed.xml000066400000000000000000000016501301675746700255060ustar00rootroot00000000000000 Package gdm Installed Red Hat Enterprise Linux 6 The RPM package gdm should be installed. gdm scap-security-guide-0.1.31/RHEL/6/input/oval/package_hal_removed.xml000066400000000000000000000016251301675746700251670ustar00rootroot00000000000000 Package hal Removed Red Hat Enterprise Linux 6 The RPM package hal should be removed. hal scap-security-guide-0.1.31/RHEL/6/input/oval/package_iptables-ipv6_installed.xml000066400000000000000000000020141301675746700274170ustar00rootroot00000000000000 Package iptables-ipv6 Installed Red Hat Enterprise Linux 6 The RPM package iptables-ipv6 should be installed. iptables-ipv6 scap-security-guide-0.1.31/RHEL/6/input/oval/package_iptables_installed.xml000066400000000000000000000017321301675746700265430ustar00rootroot00000000000000 Package iptables Installed Red Hat Enterprise Linux 6 The RPM package iptables should be installed. iptables scap-security-guide-0.1.31/RHEL/6/input/oval/package_iputils_removed.xml000066400000000000000000000016751301675746700261210ustar00rootroot00000000000000 Package iputils Removed Red Hat Enterprise Linux 6 The RPM package iputils should be removed. iputils scap-security-guide-0.1.31/RHEL/6/input/oval/package_irqbalance_installed.xml000066400000000000000000000017561301675746700270470ustar00rootroot00000000000000 Package irqbalance Installed Red Hat Enterprise Linux 6 The RPM package irqbalance should be installed. irqbalance scap-security-guide-0.1.31/RHEL/6/input/oval/package_kexec-tools_removed.xml000066400000000000000000000017451301675746700266630ustar00rootroot00000000000000 Package kexec-tools Removed Red Hat Enterprise Linux 6 The RPM package kexec-tools should be removed. kexec-tools scap-security-guide-0.1.31/RHEL/6/input/oval/package_libcgroup_removed.xml000066400000000000000000000017211301675746700264060ustar00rootroot00000000000000 Package libcgroup Removed Red Hat Enterprise Linux 6 The RPM package libcgroup should be removed. libcgroup scap-security-guide-0.1.31/RHEL/6/input/oval/package_mdadm_removed.xml000066400000000000000000000016511301675746700255040ustar00rootroot00000000000000 Package mdadm Removed Red Hat Enterprise Linux 6 The RPM package mdadm should be removed. mdadm scap-security-guide-0.1.31/RHEL/6/input/oval/package_nfs-utils_removed.xml000066400000000000000000000017211301675746700263440ustar00rootroot00000000000000 Package nfs-utils Removed Red Hat Enterprise Linux 6 The RPM package nfs-utils should be removed. nfs-utils scap-security-guide-0.1.31/RHEL/6/input/oval/package_ntpdate_removed.xml000066400000000000000000000016751301675746700260670ustar00rootroot00000000000000 Package ntpdate Removed Red Hat Enterprise Linux 6 The RPM package ntpdate should be removed. ntpdate scap-security-guide-0.1.31/RHEL/6/input/oval/package_oddjob_removed.xml000066400000000000000000000016631301675746700256660ustar00rootroot00000000000000 Package oddjob Removed Red Hat Enterprise Linux 6 The RPM package oddjob should be removed. oddjob scap-security-guide-0.1.31/RHEL/6/input/oval/package_openswan_installed.xml000066400000000000000000000021641301675746700265720ustar00rootroot00000000000000 Package openswan / libreswan Installed Red Hat Enterprise Linux 6 The RPM package openswan / libreswan should be installed. ^(open|libre)swan$ scap-security-guide-0.1.31/RHEL/6/input/oval/package_pam_ldap_removed.xml000066400000000000000000000017071301675746700262010ustar00rootroot00000000000000 Package pam_ldap Removed Red Hat Enterprise Linux 6 The RPM package pam_ldap should be removed. pam_ldap scap-security-guide-0.1.31/RHEL/6/input/oval/package_pam_pkcs11_installed.xml000066400000000000000000000017561301675746700267050ustar00rootroot00000000000000 Package pam_pkcs11 Installed Red Hat Enterprise Linux 6 The RPM package pam_pkcs11 should be installed. pam_pkcs11 scap-security-guide-0.1.31/RHEL/6/input/oval/package_pcsc-lite_installed.xml000066400000000000000000000016241301675746700266230ustar00rootroot00000000000000 Package pcsc-lite Installed Red Hat Enterprise Linux 6 The RPM package pcsc-lite should be installed. pcsc-lite scap-security-guide-0.1.31/RHEL/6/input/oval/package_policycoreutils_installed.xml000066400000000000000000000020401301675746700301620ustar00rootroot00000000000000 Package policycoreutils Installed Red Hat Enterprise Linux 6 The RPM package policycoreutils should be installed. policycoreutils scap-security-guide-0.1.31/RHEL/6/input/oval/package_portreserve_removed.xml000066400000000000000000000017451301675746700270060ustar00rootroot00000000000000 Package portreserve Removed Red Hat Enterprise Linux 6 The RPM package portreserve should be removed. portreserve scap-security-guide-0.1.31/RHEL/6/input/oval/package_postfix_installed.xml000066400000000000000000000017201301675746700264310ustar00rootroot00000000000000 Package postfix Installed Red Hat Enterprise Linux 6 The RPM package postfix should be installed. postfix scap-security-guide-0.1.31/RHEL/6/input/oval/package_psacct_installed.xml000066400000000000000000000017061301675746700262160ustar00rootroot00000000000000 Package psacct Installed Red Hat Enterprise Linux 6 The RPM package psacct should be installed. psacct scap-security-guide-0.1.31/RHEL/6/input/oval/package_qpid-cpp-server_removed.xml000066400000000000000000000020151301675746700274360ustar00rootroot00000000000000 Package qpid-cpp-server Removed Red Hat Enterprise Linux 6 The RPM package qpid-cpp-server should be removed. qpid-cpp-server scap-security-guide-0.1.31/RHEL/6/input/oval/package_quota_removed.xml000066400000000000000000000016511301675746700255530ustar00rootroot00000000000000 Package quota Removed Red Hat Enterprise Linux 6 The RPM package quota should be removed. quota scap-security-guide-0.1.31/RHEL/6/input/oval/package_rhnsd_removed.xml000066400000000000000000000016511301675746700255400ustar00rootroot00000000000000 Package rhnsd Removed Red Hat Enterprise Linux 6 The RPM package rhnsd should be removed. rhnsd scap-security-guide-0.1.31/RHEL/6/input/oval/package_rpcbind_removed.xml000066400000000000000000000016751301675746700260510ustar00rootroot00000000000000 Package rpcbind Removed Red Hat Enterprise Linux 6 The RPM package rpcbind should be removed. rpcbind scap-security-guide-0.1.31/RHEL/6/input/oval/package_samba_removed.xml000066400000000000000000000016511301675746700255050ustar00rootroot00000000000000 Package samba Removed Red Hat Enterprise Linux 6 The RPM package samba should be removed. samba scap-security-guide-0.1.31/RHEL/6/input/oval/package_smartmontools_removed.xml000066400000000000000000000017711301675746700273460ustar00rootroot00000000000000 Package smartmontools Removed Red Hat Enterprise Linux 6 The RPM package smartmontools should be removed. smartmontools scap-security-guide-0.1.31/RHEL/6/input/oval/package_subscription-manager_removed.xml000066400000000000000000000020771301675746700305610ustar00rootroot00000000000000 Package subscription-manager Removed Red Hat Enterprise Linux 6 The RPM package subscription-manager should be removed. subscription-manager scap-security-guide-0.1.31/RHEL/6/input/oval/package_sysstat_removed.xml000066400000000000000000000016751301675746700261420ustar00rootroot00000000000000 Package sysstat Removed Red Hat Enterprise Linux 6 The RPM package sysstat should be removed. sysstat scap-security-guide-0.1.31/RHEL/6/input/oval/package_xorg-x11-server-common_removed.xml000066400000000000000000000021231301675746700305750ustar00rootroot00000000000000 Package xorg-x11-server-common Removed Red Hat Enterprise Linux 6 The RPM package xorg-x11-server-common should be removed. xorg-x11-server-common scap-security-guide-0.1.31/RHEL/6/input/oval/platform/000077500000000000000000000000001301675746700223255ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/6/input/oval/platform/rhel6-cpe-dictionary.xml000066400000000000000000000041071301675746700270010ustar00rootroot00000000000000 Red Hat Enterprise Linux 6 installed_OS_is_rhel6 Red Hat Enterprise Linux 6 Client installed_OS_is_rhel6 Red Hat Enterprise Linux 6 ComputeNode installed_OS_is_rhel6 CentOS 6 installed_OS_is_centos6 Scientific Linux 6 installed_OS_is_sl6 scap-security-guide-0.1.31/RHEL/6/input/oval/postfix_network_listening_disabled.xml000066400000000000000000000030501301675746700303710ustar00rootroot00000000000000 Postfix network listening should be disabled Red Hat Enterprise Linux 6 Postfix network listening should be disabled /etc/postfix/main.cf ^[\s]*inet_interfaces[\s]*=[\s]*localhost[\s]*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/require_singleuser_auth.xml000066400000000000000000000023541301675746700261640ustar00rootroot00000000000000 Require Authentication for Single-User Mode Red Hat Enterprise Linux 6 The requirement for a password to boot into single-user mode should be configured correctly. /etc/sysconfig/init ^SINGLE=/sbin/sulogin[\s]* 1 scap-security-guide-0.1.31/RHEL/6/input/oval/service_abrtd_disabled.xml000066400000000000000000000111641301675746700256710ustar00rootroot00000000000000 Service abrtd Disabled Red Hat Enterprise Linux 6 The abrtd service should be disabled if possible. abrtd 0 abrtd 1 abrtd 2 abrtd 3 abrtd 4 abrtd 5 abrtd 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_acpid_disabled.xml000066400000000000000000000106461301675746700256610ustar00rootroot00000000000000 Service acpid Disabled Red Hat Enterprise Linux 6 The acpid service should be disabled if possible. acpid 0 acpid 1 acpid 2 acpid 3 acpid 4 acpid 5 acpid 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_atd_disabled.xml000066400000000000000000000110001301675746700253320ustar00rootroot00000000000000 Service atd Disabled Red Hat Enterprise Linux 6 The atd service should be disabled if possible. atd 0 atd 1 atd 2 atd 3 atd 4 atd 5 atd 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_auditd_enabled.xml000066400000000000000000000112351301675746700256710ustar00rootroot00000000000000 Service auditd Enabled Red Hat Enterprise Linux 6 The auditd service should be enabled if possible. auditd 0 auditd 1 auditd 2 auditd 3 auditd 4 auditd 5 auditd 6 true false scap-security-guide-0.1.31/RHEL/6/input/oval/service_autofs_disabled.xml000066400000000000000000000112611301675746700260740ustar00rootroot00000000000000 Service autofs Disabled Red Hat Enterprise Linux 6 The autofs service should be disabled if possible. autofs 0 autofs 1 autofs 2 autofs 3 autofs 4 autofs 5 autofs 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_avahi-daemon_disabled.xml000066400000000000000000000114401301675746700271230ustar00rootroot00000000000000 Service avahi-daemon Disabled Red Hat Enterprise Linux 6 The avahi-daemon service should be disabled if possible. avahi-daemon 0 avahi-daemon 1 avahi-daemon 2 avahi-daemon 3 avahi-daemon 4 avahi-daemon 5 avahi-daemon 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_bluetooth_disabled.xml000066400000000000000000000114441301675746700266030ustar00rootroot00000000000000 Service bluetooth Disabled Red Hat Enterprise Linux 6 The bluetooth service should be disabled if possible. bluetooth 0 bluetooth 1 bluetooth 2 bluetooth 3 bluetooth 4 bluetooth 5 bluetooth 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_certmonger_disabled.xml000066400000000000000000000112641301675746700267430ustar00rootroot00000000000000 Service certmonger Disabled Red Hat Enterprise Linux 6 The certmonger service should be disabled if possible. certmonger 0 certmonger 1 certmonger 2 certmonger 3 certmonger 4 certmonger 5 certmonger 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_cgconfig_disabled.xml000066400000000000000000000114501301675746700263520ustar00rootroot00000000000000 Service cgconfig Disabled Red Hat Enterprise Linux 6 The cgconfig service should be disabled if possible. cgconfig 0 cgconfig 1 cgconfig 2 cgconfig 3 cgconfig 4 cgconfig 5 cgconfig 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_cgred_disabled.xml000066400000000000000000000106461301675746700256650ustar00rootroot00000000000000 Service cgred Disabled Red Hat Enterprise Linux 6 The cgred service should be disabled if possible. cgred 0 cgred 1 cgred 2 cgred 3 cgred 4 cgred 5 cgred 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_cpuspeed_disabled.xml000066400000000000000000000114451301675746700264070ustar00rootroot00000000000000 Service cpuspeed Disabled Red Hat Enterprise Linux 6 The cpuspeed service should be disabled if possible. cpuspeed 0 cpuspeed 1 cpuspeed 2 cpuspeed 3 cpuspeed 4 cpuspeed 5 cpuspeed 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_crond_enabled.xml000066400000000000000000000111511301675746700255210ustar00rootroot00000000000000 Service crond Enabled Red Hat Enterprise Linux 6 The crond service should be enabled if possible. crond 0 crond 1 crond 2 crond 3 crond 4 crond 5 crond 6 true false scap-security-guide-0.1.31/RHEL/6/input/oval/service_cups_disabled.xml000066400000000000000000000110751301675746700255500ustar00rootroot00000000000000 Service cups Disabled Red Hat Enterprise Linux 6 The cups service should be disabled if possible. cups 0 cups 1 cups 2 cups 3 cups 4 cups 5 cups 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_dhcpd_disabled.xml000066400000000000000000000111641301675746700256570ustar00rootroot00000000000000 Service dhcpd Disabled Red Hat Enterprise Linux 6 The dhcpd service should be disabled if possible. dhcpd 0 dhcpd 1 dhcpd 2 dhcpd 3 dhcpd 4 dhcpd 5 dhcpd 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_dovecot_disabled.xml000066400000000000000000000113531301675746700262400ustar00rootroot00000000000000 Service dovecot Disabled Red Hat Enterprise Linux 6 The dovecot service should be disabled if possible. dovecot 0 dovecot 1 dovecot 2 dovecot 3 dovecot 4 dovecot 5 dovecot 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_haldaemon_disabled.xml000066400000000000000000000115151301675746700265250ustar00rootroot00000000000000 Service haldaemon Disabled Red Hat Enterprise Linux 6 The haldaemon service should be disabled if possible. haldaemon 0 haldaemon 1 haldaemon 2 haldaemon 3 haldaemon 4 haldaemon 5 haldaemon 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_httpd_disabled.xml000066400000000000000000000111671301675746700257230ustar00rootroot00000000000000 Service httpd Disabled Red Hat Enterprise Linux 6 The httpd service should be disabled if possible. httpd 0 httpd 1 httpd 2 httpd 3 httpd 4 httpd 5 httpd 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_ip6tables_enabled.xml000066400000000000000000000115321301675746700263100ustar00rootroot00000000000000 Service ip6tables Enabled Red Hat Enterprise Linux 6 The ip6tables service should be enabled if possible. ip6tables 0 ip6tables 1 ip6tables 2 ip6tables 3 ip6tables 4 ip6tables 5 ip6tables 6 true false scap-security-guide-0.1.31/RHEL/6/input/oval/service_iptables_enabled.xml000066400000000000000000000114241301675746700262220ustar00rootroot00000000000000 Service iptables Enabled Red Hat Enterprise Linux 6 The iptables service should be enabled if possible. iptables 0 iptables 1 iptables 2 iptables 3 iptables 4 iptables 5 iptables 6 true false scap-security-guide-0.1.31/RHEL/6/input/oval/service_irqbalance_enabled.xml000066400000000000000000000116101301675746700265150ustar00rootroot00000000000000 Service irqbalance Enabled Red Hat Enterprise Linux 6 The irqbalance service should be enabled if possible. irqbalance 0 irqbalance 1 irqbalance 2 irqbalance 3 irqbalance 4 irqbalance 5 irqbalance 6 true false scap-security-guide-0.1.31/RHEL/6/input/oval/service_kdump_disabled.xml000066400000000000000000000112111301675746700257060ustar00rootroot00000000000000 Service kdump Disabled Red Hat Enterprise Linux 6 The kdump service should be disabled if possible. kdump 0 kdump 1 kdump 2 kdump 3 kdump 4 kdump 5 kdump 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_mdmonitor_disabled.xml000066400000000000000000000115231301675746700266040ustar00rootroot00000000000000 Service mdmonitor Disabled Red Hat Enterprise Linux 6 The mdmonitor service should be disabled if possible. mdmonitor 0 mdmonitor 1 mdmonitor 2 mdmonitor 3 mdmonitor 4 mdmonitor 5 mdmonitor 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_messagebus_disabled.xml000066400000000000000000000116071301675746700267350ustar00rootroot00000000000000 Service messagebus Disabled Red Hat Enterprise Linux 6 The messagebus service should be disabled if possible. messagebus 0 messagebus 1 messagebus 2 messagebus 3 messagebus 4 messagebus 5 messagebus 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_named_disabled.xml000066400000000000000000000111641301675746700256610ustar00rootroot00000000000000 Service named Disabled Red Hat Enterprise Linux 6 The named service should be disabled if possible. named 0 named 1 named 2 named 3 named 4 named 5 named 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_netconsole_disabled.xml000066400000000000000000000112641301675746700267470ustar00rootroot00000000000000 Service netconsole Disabled Red Hat Enterprise Linux 6 The netconsole service should be disabled if possible. netconsole 0 netconsole 1 netconsole 2 netconsole 3 netconsole 4 netconsole 5 netconsole 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_netfs_disabled.xml000066400000000000000000000106461301675746700257200ustar00rootroot00000000000000 Service netfs Disabled Red Hat Enterprise Linux 6 The netfs service should be disabled if possible. netfs 0 netfs 1 netfs 2 netfs 3 netfs 4 netfs 5 netfs 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_nfs_disabled.xml000066400000000000000000000110251301675746700253570ustar00rootroot00000000000000 Service nfs Disabled Red Hat Enterprise Linux 6 The nfs service should be disabled if possible. nfs 0 nfs 1 nfs 2 nfs 3 nfs 4 nfs 5 nfs 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_nfslock_disabled.xml000066400000000000000000000113611301675746700262330ustar00rootroot00000000000000 Service nfslock Disabled Red Hat Enterprise Linux 6 The nfslock service should be disabled if possible. nfslock 0 nfslock 1 nfslock 2 nfslock 3 nfslock 4 nfslock 5 nfslock 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_ntpd_enabled.xml000066400000000000000000000110511301675746700253600ustar00rootroot00000000000000 Service ntpd Enabled Red Hat Enterprise Linux 6 The ntpd service should be enabled if possible. ntpd 0 ntpd 1 ntpd 2 ntpd 3 ntpd 4 ntpd 5 ntpd 6 true false scap-security-guide-0.1.31/RHEL/6/input/oval/service_ntpdate_disabled.xml000066400000000000000000000113531301675746700262340ustar00rootroot00000000000000 Service ntpdate Disabled Red Hat Enterprise Linux 6 The ntpdate service should be disabled if possible. ntpdate 0 ntpdate 1 ntpdate 2 ntpdate 3 ntpdate 4 ntpdate 5 ntpdate 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_oddjobd_disabled.xml000066400000000000000000000113501301675746700261770ustar00rootroot00000000000000 Service oddjobd Disabled Red Hat Enterprise Linux 6 The oddjobd service should be disabled if possible. oddjobd 0 oddjobd 1 oddjobd 2 oddjobd 3 oddjobd 4 oddjobd 5 oddjobd 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_pcscd_enabled.xml000066400000000000000000000110411301675746700255060ustar00rootroot00000000000000 Service pcscd Enabled Red Hat Enterprise Linux 6 The pcscd service should be enabled if possible. pcscd 0 pcscd 1 pcscd 2 pcscd 3 pcscd 4 pcscd 5 pcscd 6 true false scap-security-guide-0.1.31/RHEL/6/input/oval/service_portreserve_disabled.xml000066400000000000000000000117231301675746700271560ustar00rootroot00000000000000 Service portreserve Disabled Red Hat Enterprise Linux 6 The portreserve service should be disabled if possible. portreserve 0 portreserve 1 portreserve 2 portreserve 3 portreserve 4 portreserve 5 portreserve 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_postfix_enabled.xml000066400000000000000000000113321301675746700261110ustar00rootroot00000000000000 Service postfix Enabled Red Hat Enterprise Linux 6 The postfix service should be enabled if possible. postfix 0 postfix 1 postfix 2 postfix 3 postfix 4 postfix 5 postfix 6 true false scap-security-guide-0.1.31/RHEL/6/input/oval/service_psacct_enabled.xml000066400000000000000000000112401301675746700256700ustar00rootroot00000000000000 Service psacct Enabled Red Hat Enterprise Linux 6 The psacct service should be enabled if possible. psacct 0 psacct 1 psacct 2 psacct 3 psacct 4 psacct 5 psacct 6 true false scap-security-guide-0.1.31/RHEL/6/input/oval/service_qpidd_disabled.xml000066400000000000000000000112251301675746700256740ustar00rootroot00000000000000 Service qpidd Disabled Red Hat Enterprise Linux 6 The qpidd service should be disabled if possible. qpidd 0 qpidd 1 qpidd 2 qpidd 3 qpidd 4 qpidd 5 qpidd 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_quota_nld_disabled.xml000066400000000000000000000115231301675746700265620ustar00rootroot00000000000000 Service quota_nld Disabled Red Hat Enterprise Linux 6 The quota_nld service should be disabled if possible. quota_nld 0 quota_nld 1 quota_nld 2 quota_nld 3 quota_nld 4 quota_nld 5 quota_nld 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_rdisc_disabled.xml000066400000000000000000000111751301675746700257030ustar00rootroot00000000000000 Service rdisc Disabled Red Hat Enterprise Linux 6 The rdisc service should be disabled if possible. rdisc 0 rdisc 1 rdisc 2 rdisc 3 rdisc 4 rdisc 5 rdisc 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_restorecond_enabled.xml000066400000000000000000000117161301675746700267520ustar00rootroot00000000000000 Service restorecond Enabled Red Hat Enterprise Linux 6 The restorecond service should be enabled if possible. restorecond 0 restorecond 1 restorecond 2 restorecond 3 restorecond 4 restorecond 5 restorecond 6 true false scap-security-guide-0.1.31/RHEL/6/input/oval/service_rexec_disabled.xml000066400000000000000000000026651301675746700257110ustar00rootroot00000000000000 Service rexec Disabled Red Hat Enterprise Linux 6 The rexec service should be disabled if possible. /etc/xinetd.d/rexec ^\s*disable\s+=\s+yes\s*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/service_rhnsd_disabled.xml000066400000000000000000000111671301675746700257160ustar00rootroot00000000000000 Service rhnsd Disabled Red Hat Enterprise Linux 6 The rhnsd service should be disabled if possible. rhnsd 0 rhnsd 1 rhnsd 2 rhnsd 3 rhnsd 4 rhnsd 5 rhnsd 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_rhsmcertd_disabled.xml000066400000000000000000000116001301675746700265630ustar00rootroot00000000000000 Service rhsmcertd Disabled Red Hat Enterprise Linux 6 The rhsmcertd service should be disabled if possible. rhsmcertd 0 rhsmcertd 1 rhsmcertd 2 rhsmcertd 3 rhsmcertd 4 rhsmcertd 5 rhsmcertd 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_rlogin_disabled.xml000066400000000000000000000027021301675746700260650ustar00rootroot00000000000000 Service rlogin Disabled Red Hat Enterprise Linux 6 The rlogin service should be disabled if possible. /etc/xinetd.d/rlogin ^\s*disable\s+=\s+yes\s*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/service_rpcbind_disabled.xml000066400000000000000000000113531301675746700262160ustar00rootroot00000000000000 Service rpcbind Disabled Red Hat Enterprise Linux 6 The rpcbind service should be disabled if possible. rpcbind 0 rpcbind 1 rpcbind 2 rpcbind 3 rpcbind 4 rpcbind 5 rpcbind 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_rpcgssd_disabled.xml000066400000000000000000000113611301675746700262410ustar00rootroot00000000000000 Service rpcgssd Disabled Red Hat Enterprise Linux 6 The rpcgssd service should be disabled if possible. rpcgssd 0 rpcgssd 1 rpcgssd 2 rpcgssd 3 rpcgssd 4 rpcgssd 5 rpcgssd 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_rpcidmapd_disabled.xml000066400000000000000000000115371301675746700265440ustar00rootroot00000000000000 Service rpcidmapd Disabled Red Hat Enterprise Linux 6 The rpcidmapd service should be disabled if possible. rpcidmapd 0 rpcidmapd 1 rpcidmapd 2 rpcidmapd 3 rpcidmapd 4 rpcidmapd 5 rpcidmapd 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_rpcsvcgssd_disabled.xml000066400000000000000000000116261301675746700267610ustar00rootroot00000000000000 Service rpcsvcgssd Disabled Red Hat Enterprise Linux 6 The rpcsvcgssd service should be disabled if possible. rpcsvcgssd 0 rpcsvcgssd 1 rpcsvcgssd 2 rpcsvcgssd 3 rpcsvcgssd 4 rpcsvcgssd 5 rpcsvcgssd 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_rsh_disabled.xml000066400000000000000000000026331301675746700253720ustar00rootroot00000000000000 Service rsh Disabled Red Hat Enterprise Linux 6 The rsh service should be disabled if possible. /etc/xinetd.d/rsh ^\s*disable\s+=\s+yes\s*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/service_rsyslog_enabled.xml000066400000000000000000000113321301675746700261170ustar00rootroot00000000000000 Service rsyslog Enabled Red Hat Enterprise Linux 6 The rsyslog service should be enabled if possible. rsyslog 0 rsyslog 1 rsyslog 2 rsyslog 3 rsyslog 4 rsyslog 5 rsyslog 6 true false scap-security-guide-0.1.31/RHEL/6/input/oval/service_saslauthd_disabled.xml000066400000000000000000000115421301675746700265650ustar00rootroot00000000000000 Service saslauthd Disabled Red Hat Enterprise Linux 6 The saslauthd service should be disabled if possible. saslauthd 0 saslauthd 1 saslauthd 2 saslauthd 3 saslauthd 4 saslauthd 5 saslauthd 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_smartd_disabled.xml000066400000000000000000000113061301675746700260650ustar00rootroot00000000000000 Service smartd Disabled Red Hat Enterprise Linux 6 The smartd service should be disabled if possible. smartd 0 smartd 1 smartd 2 smartd 3 smartd 4 smartd 5 smartd 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_smb_disabled.xml000066400000000000000000000104721301675746700253570ustar00rootroot00000000000000 Service smb Disabled Red Hat Enterprise Linux 6 The smb service should be disabled if possible. smb 0 smb 1 smb 2 smb 3 smb 4 smb 5 smb 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_snmpd_disabled.xml000066400000000000000000000112001301675746700257050ustar00rootroot00000000000000 Service snmpd Disabled Red Hat Enterprise Linux 6 The snmpd service should be disabled if possible. snmpd 0 snmpd 1 snmpd 2 snmpd 3 snmpd 4 snmpd 5 snmpd 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_squid_disabled.xml000066400000000000000000000111671301675746700257250ustar00rootroot00000000000000 Service squid Disabled Red Hat Enterprise Linux 6 The squid service should be disabled if possible. squid 0 squid 1 squid 2 squid 3 squid 4 squid 5 squid 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_sshd_disabled.xml000066400000000000000000000111331301675746700255320ustar00rootroot00000000000000 Service sshd Disabled Red Hat Enterprise Linux 6 The sshd service should be disabled if possible. sshd 0 sshd 1 sshd 2 sshd 3 sshd 4 sshd 5 sshd 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_sysstat_disabled.xml000066400000000000000000000113531301675746700263070ustar00rootroot00000000000000 Service sysstat Disabled Red Hat Enterprise Linux 6 The sysstat service should be disabled if possible. sysstat 0 sysstat 1 sysstat 2 sysstat 3 sysstat 4 sysstat 5 sysstat 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_telnetd_disabled.xml000066400000000000000000000024021301675746700262270ustar00rootroot00000000000000 Disable telnet Service Red Hat Enterprise Linux 6 Disable telnet Service /etc/xinetd.d/telnet ^\s*disable\s+=\s+no\s*$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/service_tftp_disabled.xml000066400000000000000000000111221301675746700255440ustar00rootroot00000000000000 Service tftp Disabled Red Hat Enterprise Linux 6 The tftp service should be disabled if possible. tftp 0 tftp 1 tftp 2 tftp 3 tftp 4 tftp 5 tftp 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_vsftpd_disabled.xml000066400000000000000000000112611301675746700261010ustar00rootroot00000000000000 Service vsftpd Disabled Red Hat Enterprise Linux 6 The vsftpd service should be disabled if possible. vsftpd 0 vsftpd 1 vsftpd 2 vsftpd 3 vsftpd 4 vsftpd 5 vsftpd 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_xinetd_disabled.xml000066400000000000000000000112611301675746700260660ustar00rootroot00000000000000 Service xinetd Disabled Red Hat Enterprise Linux 6 The xinetd service should be disabled if possible. xinetd 0 xinetd 1 xinetd 2 xinetd 3 xinetd 4 xinetd 5 xinetd 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/service_ypbind_disabled.xml000066400000000000000000000112611301675746700260600ustar00rootroot00000000000000 Service ypbind Disabled Red Hat Enterprise Linux 6 The ypbind service should be disabled if possible. ypbind 0 ypbind 1 ypbind 2 ypbind 3 ypbind 4 ypbind 5 ypbind 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/set_ip6tables_default_rule.xml000066400000000000000000000035571301675746700265340ustar00rootroot00000000000000 Change the default policy to DROP (from ACCEPT) for the INPUT built-in chain Red Hat Enterprise Linux 6 Change the default policy to DROP (from ACCEPT) for the INPUT built-in chain. /etc/sysconfig/ip6tables ^[\s]*:INPUT\sDROP\s\[0:0\] 1 /etc/sysconfig/ip6tables ^[\s]*:INPUT\sACCEPT\s\[0:0\] 1 scap-security-guide-0.1.31/RHEL/6/input/oval/set_iptables_default_rule.xml000066400000000000000000000035421301675746700264400ustar00rootroot00000000000000 Change the default policy to DROP (from ACCEPT) for the INPUT built-in chain Red Hat Enterprise Linux 6 Change the default policy to DROP (from ACCEPT) for the INPUT built-in chain. /etc/sysconfig/iptables ^[\s]*:INPUT\sDROP\s\[0:0\] 1 /etc/sysconfig/iptables ^[\s]*:INPUT\sACCEPT\s\[0:0\] 1 scap-security-guide-0.1.31/RHEL/6/input/oval/set_iptables_default_rule_forward.xml000066400000000000000000000036121301675746700301620ustar00rootroot00000000000000 Change the default policy to DROP (from ACCEPT) for the FORWARD built-in chain Red Hat Enterprise Linux 6 Change the default policy to DROP (from ACCEPT) for the FORWARD built-in chain. /etc/sysconfig/iptables ^[\s]*:FORWARD\sDROP\s\[0:0\] 1 /etc/sysconfig/iptables ^[\s]*:FORWARD\sACCEPT\s\[0:0\] 1 scap-security-guide-0.1.31/RHEL/6/input/oval/smartcard_auth.xml000066400000000000000000000162421301675746700242310ustar00rootroot00000000000000 Enable Smart Card Login Red Hat Enterprise Linux 6 Enable Smart Card logins /etc/pam_pkcs11/pam_pkcs11.conf ^[\s]*cert_policy=(.*)$ 1 ^.*ocsp_on.*$ \nauth[\s]+required[\s]+pam_env.so \nauth[\s]+\[success=1[\s]default=ignore\][\s]pam_succeed_if.so[\s]service[\s]notin[\s] login:gdm:xdm:kdm:xscreensaver:gnome-screensaver:kscreensaver[\s]quiet[\s]use_uid \nauth[\s]+\[success=done[\s]authinfo_unavail=ignore[\s]ignore=ignore[\s]default=die\][\s] pam_pkcs11.so[\s]card_only\n /etc/pam.d/system-auth 1 \nauth[\s]+required[\s]+pam_env.so \nauth[\s]+\[success=1[\s]default=ignore\][\s]pam_succeed_if.so[\s]service[\s]notin[\s] login:gdm:xdm:kdm:xscreensaver:gnome-screensaver:kscreensaver[\s]quiet[\s]use_uid \nauth[\s]+\[success=done[\s]ignore=ignore[\s]default=die\][\s] pam_pkcs11.so[\s]wait_for_card[\s]card_only\n /etc/pam.d/system-auth 1 \nauth[\s]+required[\s]+pam_env.so \nauth[\s]+\[success=done[\s]ignore=ignore[\s]default=die\][\s] pam_pkcs11.so[\s]wait_for_card[\s]card_only\n.* \npassword[\s]+required[\s]+pam_pkcs11.so\n /etc/pam.d/smartcard-auth 1 scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_fs_suid_dumpable.xml000066400000000000000000000015601301675746700261330ustar00rootroot00000000000000 Kernel "fs.suid_dumpable" Parameter Configuration and Runtime Check Red Hat Enterprise Linux 6 The "fs.suid_dumpable" kernel parameter should be set to the appropriate value in both system configuration and system runtime. scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_kernel_dmesg_restrict.xml000066400000000000000000000016231301675746700272040ustar00rootroot00000000000000 Kernel "kernel.dmesg_restrict" Parameter Configuration and Runtime Check Red Hat Enterprise Linux 6 The "kernel.dmesg_restrict" kernel parameter should be set to the appropriate value in both system configuration and system runtime. scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_kernel_exec_shield.xml000066400000000000000000000015761301675746700264510ustar00rootroot00000000000000 Kernel "kernel.exec-shield" Parameter Configuration and Runtime Check Red Hat Enterprise Linux 6 The "kernel.exec-shield" kernel parameter should be set to the appropriate value in both system configuration and system runtime. scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_kernel_randomize_va_space.xml000066400000000000000000000016571301675746700300260ustar00rootroot00000000000000 Kernel "kernel.randomize_va_space" Parameter Configuration and Runtime Check Red Hat Enterprise Linux 6 The "kernel.randomize_va_space" kernel parameter should be set to the appropriate value in both system configuration and system runtime. scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_net_ipv4_conf_all_accept_redirects.xml000066400000000000000000000017561301675746700316050ustar00rootroot00000000000000 Kernel "net.ipv4.conf.all.accept_redirects" Parameter Configuration and Runtime Check Red Hat Enterprise Linux 6 The "net.ipv4.conf.all.accept_redirects" kernel parameter should be set to the appropriate value in both system configuration and system runtime. scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_net_ipv4_conf_all_accept_source_route.xml000066400000000000000000000020031301675746700323210ustar00rootroot00000000000000 Kernel "net.ipv4.conf.all.accept_source_route" Parameter Configuration and Runtime Check Red Hat Enterprise Linux 6 The "net.ipv4.conf.all.accept_source_route" kernel parameter should be set to the appropriate value in both system configuration and system runtime. scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_net_ipv4_conf_all_log_martians.xml000066400000000000000000000017221301675746700307520ustar00rootroot00000000000000 Kernel "net.ipv4.conf.all.log_martians" Parameter Configuration and Runtime Check Red Hat Enterprise Linux 6 The "net.ipv4.conf.all.log_martians" kernel parameter should be set to the appropriate value in both system configuration and system runtime. scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_net_ipv4_conf_all_rp_filter.xml000066400000000000000000000016751301675746700302700ustar00rootroot00000000000000 Kernel "net.ipv4.conf.all.rp_filter" Parameter Configuration and Runtime Check Red Hat Enterprise Linux 6 The "net.ipv4.conf.all.rp_filter" kernel parameter should be set to the appropriate value in both system configuration and system runtime. scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_net_ipv4_conf_all_secure_redirects.xml000066400000000000000000000017561301675746700316340ustar00rootroot00000000000000 Kernel "net.ipv4.conf.all.secure_redirects" Parameter Configuration and Runtime Check Red Hat Enterprise Linux 6 The "net.ipv4.conf.all.secure_redirects" kernel parameter should be set to the appropriate value in both system configuration and system runtime. scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_net_ipv4_conf_all_send_redirects.xml000066400000000000000000000017401301675746700312700ustar00rootroot00000000000000 Kernel "net.ipv4.conf.all.send_redirects" Parameter Configuration and Runtime Check Red Hat Enterprise Linux 6 The "net.ipv4.conf.all.send_redirects" kernel parameter should be set to the appropriate value in both system configuration and system runtime. scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_net_ipv4_conf_default_accept_redirects.xml000066400000000000000000000020121301675746700324430ustar00rootroot00000000000000 Kernel "net.ipv4.conf.default.accept_redirects" Parameter Configuration and Runtime Check Red Hat Enterprise Linux 6 The "net.ipv4.conf.default.accept_redirects" kernel parameter should be set to the appropriate value in both system configuration and system runtime. scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_net_ipv4_conf_default_accept_source_route.xml000066400000000000000000000020371301675746700332040ustar00rootroot00000000000000 Kernel "net.ipv4.conf.default.accept_source_route" Parameter Configuration and Runtime Check Red Hat Enterprise Linux 6 The "net.ipv4.conf.default.accept_source_route" kernel parameter should be set to the appropriate value in both system configuration and system runtime. scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_net_ipv4_conf_default_rp_filter.xml000066400000000000000000000017311301675746700311350ustar00rootroot00000000000000 Kernel "net.ipv4.conf.default.rp_filter" Parameter Configuration and Runtime Check Red Hat Enterprise Linux 6 The "net.ipv4.conf.default.rp_filter" kernel parameter should be set to the appropriate value in both system configuration and system runtime. scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_net_ipv4_conf_default_secure_redirects.xml000066400000000000000000000020121301675746700324720ustar00rootroot00000000000000 Kernel "net.ipv4.conf.default.secure_redirects" Parameter Configuration and Runtime Check Red Hat Enterprise Linux 6 The "net.ipv4.conf.default.secure_redirects" kernel parameter should be set to the appropriate value in both system configuration and system runtime. scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_net_ipv4_conf_default_send_redirects.xml000066400000000000000000000017741301675746700321530ustar00rootroot00000000000000 Kernel "net.ipv4.conf.default.send_redirects" Parameter Configuration and Runtime Check Red Hat Enterprise Linux 6 The "net.ipv4.conf.default.send_redirects" kernel parameter should be set to the appropriate value in both system configuration and system runtime. scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_net_ipv4_icmp_echo_ignore_broadcasts.xml000066400000000000000000000017741301675746700321430ustar00rootroot00000000000000 Kernel "net.ipv4.icmp_echo_ignore_broadcasts" Parameter Configuration and Runtime Check Red Hat Enterprise Linux 6 The "net.ipv4.icmp_echo_ignore_broadcasts" kernel parameter should be set to the appropriate value in both system configuration and system runtime. scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_net_ipv4_icmp_ignore_bogus_error_responses.xml000066400000000000000000000020461301675746700334420ustar00rootroot00000000000000 Kernel "net.ipv4.icmp_ignore_bogus_error_responses" Parameter Configuration and Runtime Check Red Hat Enterprise Linux 6 The "net.ipv4.icmp_ignore_bogus_error_responses" kernel parameter should be set to the appropriate value in both system configuration and system runtime. scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_net_ipv4_ip_forward.xml000066400000000000000000000016051301675746700265720ustar00rootroot00000000000000 Kernel "net.ipv4.ip_forward" Parameter Configuration and Runtime Check Red Hat Enterprise Linux 6 The "net.ipv4.ip_forward" kernel parameter should be set to the appropriate value in both system configuration and system runtime. scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_net_ipv4_tcp_syncookies.xml000066400000000000000000000016411301675746700274720ustar00rootroot00000000000000 Kernel "net.ipv4.tcp_syncookies" Parameter Configuration and Runtime Check Red Hat Enterprise Linux 6 The "net.ipv4.tcp_syncookies" kernel parameter should be set to the appropriate value in both system configuration and system runtime. scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_net_ipv6_conf_all_accept_ra.xml000066400000000000000000000022421301675746700302140ustar00rootroot00000000000000 Kernel "net.ipv6.conf.all.accept_ra" Parameter Configuration and Runtime Check Red Hat Enterprise Linux 6 The "net.ipv6.conf.all.accept_ra" kernel parameter should be set to the appropriate value in both system configuration and system runtime. scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_net_ipv6_conf_all_accept_redirects.xml000066400000000000000000000023321301675746700315760ustar00rootroot00000000000000 Kernel "net.ipv6.conf.all.accept_redirects" Parameter Configuration and Runtime Check Red Hat Enterprise Linux 6 The "net.ipv6.conf.all.accept_redirects" kernel parameter should be set to the appropriate value in both system configuration and system runtime. scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_net_ipv6_conf_all_accept_source_route.xml000066400000000000000000000023621301675746700323330ustar00rootroot00000000000000 Kernel "net.ipv6.conf.all.accept_source_route" Parameter Configuration and Runtime Check Red Hat Enterprise Linux 6 The "net.ipv6.conf.all.accept_source_route" kernel parameter should be set to the appropriate value in both system configuration and system runtime. scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_net_ipv6_conf_all_forwarding.xml000066400000000000000000000022521301675746700304360ustar00rootroot00000000000000 Kernel "net.ipv6.conf.all.forwarding" Parameter Configuration and Runtime Check Red Hat Enterprise Linux 6 The "net.ipv6.conf.all.forwarding" kernel parameter should be set to the appropriate value in both system configuration and system runtime. scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_net_ipv6_conf_default_accept_ra.xml000066400000000000000000000023021301675746700310650ustar00rootroot00000000000000 Kernel "net.ipv6.conf.default.accept_ra" Parameter Configuration and Runtime Check Red Hat Enterprise Linux 6 The "net.ipv6.conf.default.accept_ra" kernel parameter should be set to the appropriate value in both system configuration and system runtime. scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_net_ipv6_conf_default_accept_redirects.xml000066400000000000000000000023721301675746700324560ustar00rootroot00000000000000 Kernel "net.ipv6.conf.default.accept_redirects" Parameter Configuration and Runtime Check Red Hat Enterprise Linux 6 The "net.ipv6.conf.default.accept_redirects" kernel parameter should be set to the appropriate value in both system configuration and system runtime. scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_net_ipv6_conf_default_accept_source_route.xml000066400000000000000000000024221301675746700332040ustar00rootroot00000000000000 Kernel "net.ipv6.conf.default.accept_source_route" Parameter Configuration and Runtime Check Red Hat Enterprise Linux 6 The "net.ipv6.conf.default.accept_source_route" kernel parameter should be set to the appropriate value in both system configuration and system runtime. scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_runtime_fs_suid_dumpable.xml000066400000000000000000000024301301675746700276730ustar00rootroot00000000000000 Kernel "fs.suid_dumpable" Parameter Runtime Check Red Hat Enterprise Linux 6 The kernel "fs.suid_dumpable" parameter should be set to "0" in system runtime. fs.suid_dumpable 0 scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_runtime_kernel_dmesg_restrict.xml000066400000000000000000000025241301675746700307500ustar00rootroot00000000000000 Kernel "kernel.dmesg_restrict" Parameter Runtime Check Red Hat Enterprise Linux 6 The kernel "kernel.dmesg_restrict" parameter should be set to "1" in system runtime. kernel.dmesg_restrict 1 scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_runtime_kernel_exec_shield.xml000066400000000000000000000024601301675746700302050ustar00rootroot00000000000000 Kernel "kernel.exec-shield" Parameter Runtime Check Red Hat Enterprise Linux 6 The kernel "kernel.exec-shield" parameter should be set to "1" in system runtime. kernel.exec-shield 1 scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_runtime_kernel_randomize_va_space.xml000066400000000000000000000026041301675746700315620ustar00rootroot00000000000000 Kernel "kernel.randomize_va_space" Parameter Runtime Check Red Hat Enterprise Linux 6 The kernel "kernel.randomize_va_space" parameter should be set to "2" in system runtime. kernel.randomize_va_space 2 scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_runtime_net_ipv4_conf_all_accept_redirects.xml000066400000000000000000000033571301675746700333470ustar00rootroot00000000000000 Kernel "net.ipv4.conf.all.accept_redirects" Parameter Runtime Check Red Hat Enterprise Linux 6 The kernel "net.ipv4.conf.all.accept_redirects" parameter should be set to the appropriate value in system runtime. net.ipv4.conf.all.accept_redirects sysctl_runtime_net_ipv4_conf_all_accept_source_route.xml000066400000000000000000000034341301675746700340160ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/6/input/oval Kernel "net.ipv4.conf.all.accept_source_route" Parameter Runtime Check Red Hat Enterprise Linux 6 The kernel "net.ipv4.conf.all.accept_source_route" parameter should be set to the appropriate value in system runtime. net.ipv4.conf.all.accept_source_route scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_runtime_net_ipv4_conf_all_log_martians.xml000066400000000000000000000032631301675746700325170ustar00rootroot00000000000000 Kernel "net.ipv4.conf.all.log_martians" Parameter Runtime Check Red Hat Enterprise Linux 6 The kernel "net.ipv4.conf.all.log_martians" parameter should be set to the appropriate value in system runtime. net.ipv4.conf.all.log_martians scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_runtime_net_ipv4_conf_all_rp_filter.xml000066400000000000000000000032061301675746700320230ustar00rootroot00000000000000 Kernel "net.ipv4.conf.all.rp_filter" Parameter Runtime Check Red Hat Enterprise Linux 6 The kernel "net.ipv4.conf.all.rp_filter" parameter should be set to the appropriate value in system runtime. net.ipv4.conf.all.rp_filter scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_runtime_net_ipv4_conf_all_secure_redirects.xml000066400000000000000000000033571301675746700333760ustar00rootroot00000000000000 Kernel "net.ipv4.conf.all.secure_redirects" Parameter Runtime Check Red Hat Enterprise Linux 6 The kernel "net.ipv4.conf.all.secure_redirects" parameter should be set to the appropriate value in system runtime. net.ipv4.conf.all.secure_redirects scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_runtime_net_ipv4_conf_all_send_redirects.xml000066400000000000000000000027301301675746700330330ustar00rootroot00000000000000 Kernel "net.ipv4.conf.all.send_redirects" Parameter Runtime Check Red Hat Enterprise Linux 6 The kernel "net.ipv4.conf.all.send_redirects" parameter should be set to "0" in system runtime. net.ipv4.conf.all.send_redirects 0 sysctl_runtime_net_ipv4_conf_default_accept_redirects.xml000066400000000000000000000034531301675746700341410ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/6/input/oval Kernel "net.ipv4.conf.default.accept_redirects" Parameter Runtime Check Red Hat Enterprise Linux 6 The kernel "net.ipv4.conf.default.accept_redirects" parameter should be set to the appropriate value in system runtime. net.ipv4.conf.default.accept_redirects sysctl_runtime_net_ipv4_conf_default_accept_source_route.xml000066400000000000000000000035301301675746700346670ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/6/input/oval Kernel "net.ipv4.conf.default.accept_source_route" Parameter Runtime Check Red Hat Enterprise Linux 6 The kernel "net.ipv4.conf.default.accept_source_route" parameter should be set to the appropriate value in system runtime. net.ipv4.conf.default.accept_source_route scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_runtime_net_ipv4_conf_default_rp_filter.xml000066400000000000000000000033021301675746700326740ustar00rootroot00000000000000 Kernel "net.ipv4.conf.default.rp_filter" Parameter Runtime Check Red Hat Enterprise Linux 6 The kernel "net.ipv4.conf.default.rp_filter" parameter should be set to the appropriate value in system runtime. net.ipv4.conf.default.rp_filter sysctl_runtime_net_ipv4_conf_default_secure_redirects.xml000066400000000000000000000034531301675746700341700ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/6/input/oval Kernel "net.ipv4.conf.default.secure_redirects" Parameter Runtime Check Red Hat Enterprise Linux 6 The kernel "net.ipv4.conf.default.secure_redirects" parameter should be set to the appropriate value in system runtime. net.ipv4.conf.default.secure_redirects scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_runtime_net_ipv4_conf_default_send_redirects.xml000066400000000000000000000030101301675746700336770ustar00rootroot00000000000000 Kernel "net.ipv4.conf.default.send_redirects" Parameter Runtime Check Red Hat Enterprise Linux 6 The kernel "net.ipv4.conf.default.send_redirects" parameter should be set to "0" in system runtime. net.ipv4.conf.default.send_redirects 0 scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_runtime_net_ipv4_icmp_echo_ignore_broadcasts.xml000066400000000000000000000034151301675746700337000ustar00rootroot00000000000000 Kernel "net.ipv4.icmp_echo_ignore_broadcasts" Parameter Runtime Check Red Hat Enterprise Linux 6 The kernel "net.ipv4.icmp_echo_ignore_broadcasts" parameter should be set to the appropriate value in system runtime. net.ipv4.icmp_echo_ignore_broadcasts sysctl_runtime_net_ipv4_icmp_ignore_bogus_error_responses.xml000066400000000000000000000035471301675746700351350ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/6/input/oval Kernel "net.ipv4.icmp_ignore_bogus_error_responses" Parameter Runtime Check Red Hat Enterprise Linux 6 The kernel "net.ipv4.icmp_ignore_bogus_error_responses" parameter should be set to the appropriate value in system runtime. net.ipv4.icmp_ignore_bogus_error_responses scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_runtime_net_ipv4_ip_forward.xml000066400000000000000000000024741301675746700303420ustar00rootroot00000000000000 Kernel "net.ipv4.ip_forward" Parameter Runtime Check Red Hat Enterprise Linux 6 The kernel "net.ipv4.ip_forward" parameter should be set to "0" in system runtime. net.ipv4.ip_forward 0 scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_runtime_net_ipv4_tcp_syncookies.xml000066400000000000000000000031121301675746700312300ustar00rootroot00000000000000 Kernel "net.ipv4.tcp_syncookies" Parameter Runtime Check Red Hat Enterprise Linux 6 The kernel "net.ipv4.tcp_syncookies" parameter should be set to the appropriate value in system runtime. net.ipv4.tcp_syncookies scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_runtime_net_ipv6_conf_all_accept_ra.xml000066400000000000000000000032061301675746700317600ustar00rootroot00000000000000 Kernel "net.ipv6.conf.all.accept_ra" Parameter Runtime Check Red Hat Enterprise Linux 6 The kernel "net.ipv6.conf.all.accept_ra" parameter should be set to the appropriate value in system runtime. net.ipv6.conf.all.accept_ra scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_runtime_net_ipv6_conf_all_accept_redirects.xml000066400000000000000000000033571301675746700333510ustar00rootroot00000000000000 Kernel "net.ipv6.conf.all.accept_redirects" Parameter Runtime Check Red Hat Enterprise Linux 6 The kernel "net.ipv6.conf.all.accept_redirects" parameter should be set to the appropriate value in system runtime. net.ipv6.conf.all.accept_redirects sysctl_runtime_net_ipv6_conf_all_accept_source_route.xml000066400000000000000000000034341301675746700340200ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/6/input/oval Kernel "net.ipv6.conf.all.accept_source_route" Parameter Runtime Check Red Hat Enterprise Linux 6 The kernel "net.ipv6.conf.all.accept_source_route" parameter should be set to the appropriate value in system runtime. net.ipv6.conf.all.accept_source_route scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_runtime_net_ipv6_conf_all_forwarding.xml000066400000000000000000000032251301675746700322020ustar00rootroot00000000000000 Kernel "net.ipv6.conf.all.forwarding" Parameter Runtime Check Red Hat Enterprise Linux 6 The kernel "net.ipv6.conf.all.forwarding" parameter should be set to the appropriate value in system runtime. net.ipv6.conf.all.forwarding scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_runtime_net_ipv6_conf_default_accept_ra.xml000066400000000000000000000033021301675746700326310ustar00rootroot00000000000000 Kernel "net.ipv6.conf.default.accept_ra" Parameter Runtime Check Red Hat Enterprise Linux 6 The kernel "net.ipv6.conf.default.accept_ra" parameter should be set to the appropriate value in system runtime. net.ipv6.conf.default.accept_ra sysctl_runtime_net_ipv6_conf_default_accept_redirects.xml000066400000000000000000000034531301675746700341430ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/6/input/oval Kernel "net.ipv6.conf.default.accept_redirects" Parameter Runtime Check Red Hat Enterprise Linux 6 The kernel "net.ipv6.conf.default.accept_redirects" parameter should be set to the appropriate value in system runtime. net.ipv6.conf.default.accept_redirects sysctl_runtime_net_ipv6_conf_default_accept_source_route.xml000066400000000000000000000035301301675746700346710ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/6/input/oval Kernel "net.ipv6.conf.default.accept_source_route" Parameter Runtime Check Red Hat Enterprise Linux 6 The kernel "net.ipv6.conf.default.accept_source_route" parameter should be set to the appropriate value in system runtime. net.ipv6.conf.default.accept_source_route scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_static_fs_suid_dumpable.xml000066400000000000000000000142531301675746700275050ustar00rootroot00000000000000 Kernel "fs.suid_dumpable" Parameter Configuration Check Red Hat Enterprise Linux 6 The kernel "fs.suid_dumpable" parameter should be set to "0" in the system configuration. /etc/sysctl.d ^.*$ (?:^|.*\n)[^#]*fs.suid_dumpable[\s]*=[\s]*(\d+)[\s]*\n 1 0 /etc/sysctl.conf (?:^|.*\n)[^#]*fs.suid_dumpable[\s]*=[\s]*(\d+)[\s]*\n 1 scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_static_kernel_dmesg_restrict.xml000066400000000000000000000145511301675746700305570ustar00rootroot00000000000000 Kernel "kernel.dmesg_restrict" Parameter Configuration Check Red Hat Enterprise Linux 6 The kernel "kernel.dmesg_restrict" parameter should be set to "1" in the system configuration. /etc/sysctl.d ^.*$ (?:^|.*\n)[^#]*kernel.dmesg_restrict[\s]*=[\s]*(\d+)[\s]*\n 1 1 /etc/sysctl.conf (?:^|.*\n)[^#]*kernel.dmesg_restrict[\s]*=[\s]*(\d+)[\s]*\n 1 scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_static_kernel_exec_shield.xml000066400000000000000000000143671301675746700300220ustar00rootroot00000000000000 Kernel "kernel.exec-shield" Parameter Configuration Check Red Hat Enterprise Linux 6 The kernel "kernel.exec-shield" parameter should be set to "1" in the system configuration. /etc/sysctl.d ^.*$ (?:^|.*\n)[^#]*kernel.exec-shield[\s]*=[\s]*(\d+)[\s]*\n 1 1 /etc/sysctl.conf (?:^|.*\n)[^#]*kernel.exec-shield[\s]*=[\s]*(\d+)[\s]*\n 1 scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_static_kernel_randomize_va_space.xml000066400000000000000000000150011301675746700313610ustar00rootroot00000000000000 Kernel "kernel.randomize_va_space" Parameter Configuration Check Red Hat Enterprise Linux 6 The kernel "kernel.randomize_va_space" parameter should be set to "2" in the system configuration. /etc/sysctl.d ^.*$ (?:^|.*\n)[^#]*kernel.randomize_va_space[\s]*=[\s]*(\d+)[\s]*\n 1 2 /etc/sysctl.conf (?:^|.*\n)[^#]*kernel.randomize_va_space[\s]*=[\s]*(\d+)[\s]*\n 1 scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_static_net_ipv4_conf_all_accept_redirects.xml000066400000000000000000000162401301675746700331460ustar00rootroot00000000000000 Kernel "net.ipv4.conf.all.accept_redirects" Parameter Configuration Check Red Hat Enterprise Linux 6 The kernel "net.ipv4.conf.all.accept_redirects" parameter should be set to the appropriate value in the system configuration. /etc/sysctl.d ^.*$ (?:^|.*\n)[^#]*net.ipv4.conf.all.accept_redirects[\s]*=[\s]*(\d+)[\s]*\n 1 /etc/sysctl.conf (?:^|.*\n)[^#]*net.ipv4.conf.all.accept_redirects[\s]*=[\s]*(\d+)[\s]*\n 1 scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_static_net_ipv4_conf_all_accept_source_route.xml000066400000000000000000000164331301675746700337040ustar00rootroot00000000000000 Kernel "net.ipv4.conf.all.accept_source_route" Parameter Configuration Check Red Hat Enterprise Linux 6 The kernel "net.ipv4.conf.all.accept_source_route" parameter should be set to the appropriate value in the system configuration. /etc/sysctl.d ^.*$ (?:^|.*\n)[^#]*net.ipv4.conf.all.accept_source_route[\s]*=[\s]*(\d+)[\s]*\n 1 /etc/sysctl.conf (?:^|.*\n)[^#]*net.ipv4.conf.all.accept_source_route[\s]*=[\s]*(\d+)[\s]*\n 1 scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_static_net_ipv4_conf_all_log_martians.xml000066400000000000000000000157741301675746700323350ustar00rootroot00000000000000 Kernel "net.ipv4.conf.all.log_martians" Parameter Configuration Check Red Hat Enterprise Linux 6 The kernel "net.ipv4.conf.all.log_martians" parameter should be set to the appropriate value in the system configuration. /etc/sysctl.d ^.*$ (?:^|.*\n)[^#]*net.ipv4.conf.all.log_martians[\s]*=[\s]*(\d+)[\s]*\n 1 /etc/sysctl.conf (?:^|.*\n)[^#]*net.ipv4.conf.all.log_martians[\s]*=[\s]*(\d+)[\s]*\n 1 scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_static_net_ipv4_conf_all_rp_filter.xml000066400000000000000000000156011301675746700316310ustar00rootroot00000000000000 Kernel "net.ipv4.conf.all.rp_filter" Parameter Configuration Check Red Hat Enterprise Linux 6 The kernel "net.ipv4.conf.all.rp_filter" parameter should be set to the appropriate value in the system configuration. /etc/sysctl.d ^.*$ (?:^|.*\n)[^#]*net.ipv4.conf.all.rp_filter[\s]*=[\s]*(\d+)[\s]*\n 1 /etc/sysctl.conf (?:^|.*\n)[^#]*net.ipv4.conf.all.rp_filter[\s]*=[\s]*(\d+)[\s]*\n 1 scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_static_net_ipv4_conf_all_secure_redirects.xml000066400000000000000000000162401301675746700331750ustar00rootroot00000000000000 Kernel "net.ipv4.conf.all.secure_redirects" Parameter Configuration Check Red Hat Enterprise Linux 6 The kernel "net.ipv4.conf.all.secure_redirects" parameter should be set to the appropriate value in the system configuration. /etc/sysctl.d ^.*$ (?:^|.*\n)[^#]*net.ipv4.conf.all.secure_redirects[\s]*=[\s]*(\d+)[\s]*\n 1 /etc/sysctl.conf (?:^|.*\n)[^#]*net.ipv4.conf.all.secure_redirects[\s]*=[\s]*(\d+)[\s]*\n 1 scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_static_net_ipv4_conf_all_send_redirects.xml000066400000000000000000000154131301675746700326410ustar00rootroot00000000000000 Kernel "net.ipv4.conf.all.send_redirects" Parameter Configuration Check Red Hat Enterprise Linux 6 The kernel "net.ipv4.conf.all.send_redirects" parameter should be set to "0" in the system configuration. /etc/sysctl.d ^.*$ (?:^|.*\n)[^#]*net.ipv4.conf.all.send_redirects[\s]*=[\s]*(\d+)[\s]*\n 1 0 /etc/sysctl.conf (?:^|.*\n)[^#]*net.ipv4.conf.all.send_redirects[\s]*=[\s]*(\d+)[\s]*\n 1 sysctl_static_net_ipv4_conf_default_accept_redirects.xml000066400000000000000000000165041301675746700337460ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/6/input/oval Kernel "net.ipv4.conf.default.accept_redirects" Parameter Configuration Check Red Hat Enterprise Linux 6 The kernel "net.ipv4.conf.default.accept_redirects" parameter should be set to the appropriate value in the system configuration. /etc/sysctl.d ^.*$ (?:^|.*\n)[^#]*net.ipv4.conf.default.accept_redirects[\s]*=[\s]*(\d+)[\s]*\n 1 /etc/sysctl.conf (?:^|.*\n)[^#]*net.ipv4.conf.default.accept_redirects[\s]*=[\s]*(\d+)[\s]*\n 1 sysctl_static_net_ipv4_conf_default_accept_source_route.xml000066400000000000000000000166771301675746700345130ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/6/input/oval Kernel "net.ipv4.conf.default.accept_source_route" Parameter Configuration Check Red Hat Enterprise Linux 6 The kernel "net.ipv4.conf.default.accept_source_route" parameter should be set to the appropriate value in the system configuration. /etc/sysctl.d ^.*$ (?:^|.*\n)[^#]*net.ipv4.conf.default.accept_source_route[\s]*=[\s]*(\d+)[\s]*\n 1 /etc/sysctl.conf (?:^|.*\n)[^#]*net.ipv4.conf.default.accept_source_route[\s]*=[\s]*(\d+)[\s]*\n 1 scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_static_net_ipv4_conf_default_rp_filter.xml000066400000000000000000000160451301675746700325100ustar00rootroot00000000000000 Kernel "net.ipv4.conf.default.rp_filter" Parameter Configuration Check Red Hat Enterprise Linux 6 The kernel "net.ipv4.conf.default.rp_filter" parameter should be set to the appropriate value in the system configuration. /etc/sysctl.d ^.*$ (?:^|.*\n)[^#]*net.ipv4.conf.default.rp_filter[\s]*=[\s]*(\d+)[\s]*\n 1 /etc/sysctl.conf (?:^|.*\n)[^#]*net.ipv4.conf.default.rp_filter[\s]*=[\s]*(\d+)[\s]*\n 1 sysctl_static_net_ipv4_conf_default_secure_redirects.xml000066400000000000000000000165041301675746700337750ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/6/input/oval Kernel "net.ipv4.conf.default.secure_redirects" Parameter Configuration Check Red Hat Enterprise Linux 6 The kernel "net.ipv4.conf.default.secure_redirects" parameter should be set to the appropriate value in the system configuration. /etc/sysctl.d ^.*$ (?:^|.*\n)[^#]*net.ipv4.conf.default.secure_redirects[\s]*=[\s]*(\d+)[\s]*\n 1 /etc/sysctl.conf (?:^|.*\n)[^#]*net.ipv4.conf.default.secure_redirects[\s]*=[\s]*(\d+)[\s]*\n 1 scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_static_net_ipv4_conf_default_send_redirects.xml000066400000000000000000000156431301675746700335220ustar00rootroot00000000000000 Kernel "net.ipv4.conf.default.send_redirects" Parameter Configuration Check Red Hat Enterprise Linux 6 The kernel "net.ipv4.conf.default.send_redirects" parameter should be set to "0" in the system configuration. /etc/sysctl.d ^.*$ (?:^|.*\n)[^#]*net.ipv4.conf.default.send_redirects[\s]*=[\s]*(\d+)[\s]*\n 1 0 /etc/sysctl.conf (?:^|.*\n)[^#]*net.ipv4.conf.default.send_redirects[\s]*=[\s]*(\d+)[\s]*\n 1 scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_static_net_ipv4_icmp_echo_ignore_broadcasts.xml000066400000000000000000000163621301675746700335110ustar00rootroot00000000000000 Kernel "net.ipv4.icmp_echo_ignore_broadcasts" Parameter Configuration Check Red Hat Enterprise Linux 6 The kernel "net.ipv4.icmp_echo_ignore_broadcasts" parameter should be set to the appropriate value in the system configuration. /etc/sysctl.d ^.*$ (?:^|.*\n)[^#]*net.ipv4.icmp_echo_ignore_broadcasts[\s]*=[\s]*(\d+)[\s]*\n 1 /etc/sysctl.conf (?:^|.*\n)[^#]*net.ipv4.icmp_echo_ignore_broadcasts[\s]*=[\s]*(\d+)[\s]*\n 1 sysctl_static_net_ipv4_icmp_ignore_bogus_error_responses.xml000066400000000000000000000167501301675746700347410ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/6/input/oval Kernel "net.ipv4.icmp_ignore_bogus_error_responses" Parameter Configuration Check Red Hat Enterprise Linux 6 The kernel "net.ipv4.icmp_ignore_bogus_error_responses" parameter should be set to the appropriate value in the system configuration. /etc/sysctl.d ^.*$ (?:^|.*\n)[^#]*net.ipv4.icmp_ignore_bogus_error_responses[\s]*=[\s]*(\d+)[\s]*\n 1 /etc/sysctl.conf (?:^|.*\n)[^#]*net.ipv4.icmp_ignore_bogus_error_responses[\s]*=[\s]*(\d+)[\s]*\n 1 scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_static_net_ipv4_ip_forward.xml000066400000000000000000000144351301675746700301460ustar00rootroot00000000000000 Kernel "net.ipv4.ip_forward" Parameter Configuration Check Red Hat Enterprise Linux 6 The kernel "net.ipv4.ip_forward" parameter should be set to "0" in the system configuration. /etc/sysctl.d ^.*$ (?:^|.*\n)[^#]*net.ipv4.ip_forward[\s]*=[\s]*(\d+)[\s]*\n 1 0 /etc/sysctl.conf (?:^|.*\n)[^#]*net.ipv4.ip_forward[\s]*=[\s]*(\d+)[\s]*\n 1 scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_static_net_ipv4_tcp_syncookies.xml000066400000000000000000000153351301675746700310460ustar00rootroot00000000000000 Kernel "net.ipv4.tcp_syncookies" Parameter Configuration Check Red Hat Enterprise Linux 6 The kernel "net.ipv4.tcp_syncookies" parameter should be set to the appropriate value in the system configuration. /etc/sysctl.d ^.*$ (?:^|.*\n)[^#]*net.ipv4.tcp_syncookies[\s]*=[\s]*(\d+)[\s]*\n 1 /etc/sysctl.conf (?:^|.*\n)[^#]*net.ipv4.tcp_syncookies[\s]*=[\s]*(\d+)[\s]*\n 1 scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_static_net_ipv6_conf_all_accept_ra.xml000066400000000000000000000156011301675746700315660ustar00rootroot00000000000000 Kernel "net.ipv6.conf.all.accept_ra" Parameter Configuration Check Red Hat Enterprise Linux 6 The kernel "net.ipv6.conf.all.accept_ra" parameter should be set to the appropriate value in the system configuration. /etc/sysctl.d ^.*$ (?:^|.*\n)[^#]*net.ipv6.conf.all.accept_ra[\s]*=[\s]*(\d+)[\s]*\n 1 /etc/sysctl.conf (?:^|.*\n)[^#]*net.ipv6.conf.all.accept_ra[\s]*=[\s]*(\d+)[\s]*\n 1 scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_static_net_ipv6_conf_all_accept_redirects.xml000066400000000000000000000162401301675746700331500ustar00rootroot00000000000000 Kernel "net.ipv6.conf.all.accept_redirects" Parameter Configuration Check Red Hat Enterprise Linux 6 The kernel "net.ipv6.conf.all.accept_redirects" parameter should be set to the appropriate value in the system configuration. /etc/sysctl.d ^.*$ (?:^|.*\n)[^#]*net.ipv6.conf.all.accept_redirects[\s]*=[\s]*(\d+)[\s]*\n 1 /etc/sysctl.conf (?:^|.*\n)[^#]*net.ipv6.conf.all.accept_redirects[\s]*=[\s]*(\d+)[\s]*\n 1 scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_static_net_ipv6_conf_all_accept_source_route.xml000066400000000000000000000164331301675746700337060ustar00rootroot00000000000000 Kernel "net.ipv6.conf.all.accept_source_route" Parameter Configuration Check Red Hat Enterprise Linux 6 The kernel "net.ipv6.conf.all.accept_source_route" parameter should be set to the appropriate value in the system configuration. /etc/sysctl.d ^.*$ (?:^|.*\n)[^#]*net.ipv6.conf.all.accept_source_route[\s]*=[\s]*(\d+)[\s]*\n 1 /etc/sysctl.conf (?:^|.*\n)[^#]*net.ipv6.conf.all.accept_source_route[\s]*=[\s]*(\d+)[\s]*\n 1 scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_static_net_ipv6_conf_all_forwarding.xml000066400000000000000000000156521301675746700320150ustar00rootroot00000000000000 Kernel "net.ipv6.conf.all.forwarding" Parameter Configuration Check Red Hat Enterprise Linux 6 The kernel "net.ipv6.conf.all.forwarding" parameter should be set to the appropriate value in the system configuration. /etc/sysctl.d ^.*$ (?:^|.*\n)[^#]*net.ipv6.conf.all.forwarding[\s]*=[\s]*(\d+)[\s]*\n 1 /etc/sysctl.conf (?:^|.*\n)[^#]*net.ipv6.conf.all.forwarding[\s]*=[\s]*(\d+)[\s]*\n 1 scap-security-guide-0.1.31/RHEL/6/input/oval/sysctl_static_net_ipv6_conf_default_accept_ra.xml000066400000000000000000000160451301675746700324450ustar00rootroot00000000000000 Kernel "net.ipv6.conf.default.accept_ra" Parameter Configuration Check Red Hat Enterprise Linux 6 The kernel "net.ipv6.conf.default.accept_ra" parameter should be set to the appropriate value in the system configuration. /etc/sysctl.d ^.*$ (?:^|.*\n)[^#]*net.ipv6.conf.default.accept_ra[\s]*=[\s]*(\d+)[\s]*\n 1 /etc/sysctl.conf (?:^|.*\n)[^#]*net.ipv6.conf.default.accept_ra[\s]*=[\s]*(\d+)[\s]*\n 1 sysctl_static_net_ipv6_conf_default_accept_redirects.xml000066400000000000000000000165041301675746700337500ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/6/input/oval Kernel "net.ipv6.conf.default.accept_redirects" Parameter Configuration Check Red Hat Enterprise Linux 6 The kernel "net.ipv6.conf.default.accept_redirects" parameter should be set to the appropriate value in the system configuration. /etc/sysctl.d ^.*$ (?:^|.*\n)[^#]*net.ipv6.conf.default.accept_redirects[\s]*=[\s]*(\d+)[\s]*\n 1 /etc/sysctl.conf (?:^|.*\n)[^#]*net.ipv6.conf.default.accept_redirects[\s]*=[\s]*(\d+)[\s]*\n 1 sysctl_static_net_ipv6_conf_default_accept_source_route.xml000066400000000000000000000166771301675746700345150ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/6/input/oval Kernel "net.ipv6.conf.default.accept_source_route" Parameter Configuration Check Red Hat Enterprise Linux 6 The kernel "net.ipv6.conf.default.accept_source_route" parameter should be set to the appropriate value in the system configuration. /etc/sysctl.d ^.*$ (?:^|.*\n)[^#]*net.ipv6.conf.default.accept_source_route[\s]*=[\s]*(\d+)[\s]*\n 1 /etc/sysctl.conf (?:^|.*\n)[^#]*net.ipv6.conf.default.accept_source_route[\s]*=[\s]*(\d+)[\s]*\n 1 scap-security-guide-0.1.31/RHEL/6/input/oval/templates/000077500000000000000000000000001301675746700224775ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/6/input/oval/templates/Makefile000066400000000000000000000022211301675746700241340ustar00rootroot00000000000000templates: services packages kernel_modules permissions umasks sysctls SHARED_DIR=../../../../../shared/templates export PYTHONPATH=../../../../../shared SHARED_TEMPLATES=../../../../../shared/templates OUTPUT:=$(shell mkdir -p output) services: ${SHARED_DIR}/create_services_enabled.py services_enabled.csv ${SHARED_DIR}/create_services_disabled.py services_disabled.csv packages: ${SHARED_DIR}/create_package_installed.py packages_installed.csv ${SHARED_DIR}/create_package_removed.py packages_removed.csv kernel_modules: ${SHARED_DIR}/create_kernel_modules_disabled.py kernel_modules_disabled.csv permissions: ${SHARED_DIR}/create_permission_checks.py file_dir_permissions.csv umasks: ${SHARED_TEMPLATES}/create_umask_checks.py ${SHARED_TEMPLATES}/file_umask_checks.csv sysctls: ${SHARED_DIR}/create_sysctl_checks.py sysctl_values.csv ${SHARED_DIR}/create_sysctl_ipv6_checks.py sysctl_ipv6_values.csv compare: diff output/ ../ | grep -v "Only in ../" copy: cp output/*.xml ../ cp output/*.sh ../../remediations/bash/ find-untemplated: templates ${SHARED_DIR}/find_untemplated.py clean: rm -f output/*.xml rm -f output/*.sh rm -rf output/ scap-security-guide-0.1.31/RHEL/6/input/oval/templates/README000066400000000000000000000024121301675746700233560ustar00rootroot00000000000000These templates are designed to make generation of OVAL tests which have repetitive structure easier. For example: $ ./create_services_disabled.py services_disabled.csv will produce all the OVAL checks (in a shorthand format) to disable services, and store them in the output directory. The CSV input files should contain all the relevant information for each check. Files should be compared to existing OVAL checks for consistency before copying to the main oval directory. A Makefile exists to activate all the scripts here and ease comparison with existing checks. For example, to run all scripts to generate OVAL checks from the available templates: $ make templates To compare the newly-generated files in the output directory to the existing checks, run: $ make compare Then, if the changes are agreeable, the following command can be run to copy the newly generated files to the main oval directory: $ make copy To list files that have been manually created (and may potentially be templated), run: # make find-untemplated Note, however, that some checks may have been intentionally hand-edited. For example, some sysctl checks (such as for IPv6) may include additional tests so that they pass if the IPv6 module is disabled. Never blindly copy over existing checks. scap-security-guide-0.1.31/RHEL/6/input/oval/templates/file_dir_permissions.csv000066400000000000000000000001001301675746700274130ustar00rootroot00000000000000/etc,shadow,0,0,0000 /etc,gshadow,0,0,0000 /etc,passwd,0,0,0644 scap-security-guide-0.1.31/RHEL/6/input/oval/templates/kernel_modules_disabled.csv000066400000000000000000000001301301675746700300450ustar00rootroot00000000000000cramfs dccp freevxfs hfs hfsplus jffs2 rds sctp squashfs tipc udf usb-storage bluetooth scap-security-guide-0.1.31/RHEL/6/input/oval/templates/packages_installed.csv000066400000000000000000000002151301675746700270270ustar00rootroot00000000000000aide audit avahi cronie esc GConf2 gdm iptables iptables-ipv6 irqbalance ntp pam_pkcs11 policycoreutils postfix psacct rsyslog screen vsftpd scap-security-guide-0.1.31/RHEL/6/input/oval/templates/packages_removed.csv000066400000000000000000000007061301675746700265160ustar00rootroot00000000000000abrt at autofs bind cpuspeed cups cyrus-sasl dbus dhcp dovecot hal httpd iputils kexec-tools libcgroup mcstrans mdadm net-snmp nfs-utils ntpdate oddjob openldap-servers openssh-server pam_ldap portreserve qpid-cpp-server quota rhnsd rpcbind rsh rsh-server samba samba-common sendmail setroubleshoot smartmontools squid subscription-manager sysstat talk-server talk telnet telnet-server tftp tftp-server vsftpd xinetd xorg-x11-server-common ypbind ypserv scap-security-guide-0.1.31/RHEL/6/input/oval/templates/services_disabled.csv000066400000000000000000000015471301675746700266750ustar00rootroot00000000000000# service_name, package_name, daemon_name (as recognized by chkconfig / systemd. To be used when daemon_name differs from service_name) abrtd,abrt, acpid,, autofs,autofs, certmonger,, cgred,, atd,at, avahi-daemon,, bluetooth,, cgconfig,libcgroup, cpuspeed,cpuspeed, cups,cups, dhcpd,dhcp, dovecot,dovecot, haldaemon,hal, httpd,httpd, kdump,kexec-tools, mdmonitor,mdadm, messagebus,dbus, named,bind, netconsole,, netfs,, nfs,nfs-utils, nfslock,nfs-utils, ntpdate,ntpdate, oddjobd,oddjob, portreserve,portreserve, qpidd,qpid-cpp-server, quota_nld,quota, rdisc,iputils, rhnsd,rhnsd, rhsmcertd,subscription-manager, rpcbind,rpcbind, rpcgssd,nfs-utils, rpcidmapd,nfs-utils, rpcsvcgssd,nfs-utils, saslauthd,cyrus-sasl, smartd,smartmontools, smb,, snmpd,net-snmp, squid,squid, sshd,openssh-server, sysstat,sysstat, tftp,tftp-server, vsftpd,vsftpd, xinetd,xinetd, ypbind,ypbind, scap-security-guide-0.1.31/RHEL/6/input/oval/templates/services_enabled.csv000066400000000000000000000002751301675746700265150ustar00rootroot00000000000000auditd,audit crond,cronie ip6tables,iptables-ipv6 iptables,iptables irqbalance,irqbalance ntpd,ntp pcscd,pcsc-lite postfix,postfix psacct,psacct restorecond,policycoreutils rsyslog,rsyslog scap-security-guide-0.1.31/RHEL/6/input/oval/templates/sysctl_ipv6_values.csv000066400000000000000000000006761301675746700270710ustar00rootroot00000000000000# Add to generate hard-coded OVAL and remediation content. # Add to generate OVAL and remediation content that use the XCCDF value. net.ipv6.conf.all.accept_ra, net.ipv6.conf.default.accept_ra, net.ipv6.conf.default.accept_redirects, net.ipv6.conf.all.accept_source_route, net.ipv6.conf.default.accept_source_route, net.ipv6.conf.all.accept_redirects, net.ipv6.conf.all.forwarding, scap-security-guide-0.1.31/RHEL/6/input/oval/templates/sysctl_ipv6_values_orig.csv000066400000000000000000000001131301675746700300730ustar00rootroot00000000000000net.ipv6.conf.default.accept_ra,0 net.ipv6.conf.default.accept_redirects,0 scap-security-guide-0.1.31/RHEL/6/input/oval/templates/sysctl_values.csv000066400000000000000000000014631301675746700261200ustar00rootroot00000000000000# Add to generate hard-coded OVAL and remediation content. # Add to generate OVAL and remediation content that use the XCCDF value. kernel.exec-shield,1 kernel.randomize_va_space,2 kernel.dmesg_restrict,1 net.ipv4.conf.all.accept_redirects, net.ipv4.conf.all.accept_source_route, net.ipv4.conf.all.log_martians, net.ipv4.conf.all.rp_filter, net.ipv4.conf.all.secure_redirects, net.ipv4.conf.all.send_redirects,0 net.ipv4.conf.default.accept_redirects, net.ipv4.conf.default.accept_source_route, net.ipv4.conf.default.rp_filter, net.ipv4.conf.default.secure_redirects, net.ipv4.conf.default.send_redirects,0 net.ipv4.icmp_echo_ignore_broadcasts, net.ipv4.icmp_ignore_bogus_error_responses, net.ipv4.ip_forward,0 net.ipv4.tcp_syncookies, fs.suid_dumpable,0 scap-security-guide-0.1.31/RHEL/6/input/oval/templates/sysctl_values_orig.csv000066400000000000000000000011741301675746700271370ustar00rootroot00000000000000kernel.exec-shield,1 kernel.randomize_va_space,2 kernel.dmesg_restrict,1 net.ipv4.conf.all.accept_redirects,0 net.ipv4.conf.all.accept_source_route,0 net.ipv4.conf.all.log_martians,1 net.ipv4.conf.all.rp_filter,1 net.ipv4.conf.all.secure_redirects,0 net.ipv4.conf.all.send_redirects,0 net.ipv4.conf.default.accept_redirects,0 net.ipv4.conf.default.accept_source_route,0 net.ipv4.conf.default.rp_filter,1 net.ipv4.conf.default.secure_redirects,0 net.ipv4.conf.default.send_redirects,0 net.ipv4.icmp_echo_ignore_broadcasts,1 net.ipv4.icmp_ignore_bogus_error_responses,1 net.ipv4.ip_forward,0 net.ipv4.tcp_syncookies,1 fs.suid_dumpable,0 scap-security-guide-0.1.31/RHEL/6/input/oval/templates/template_BASH_package_removed000066400000000000000000000005661301675746700302350ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 6 # CAUTION: This remediation script will remove PKGNAME # from the system, and may remove any packages # that depend on PKGNAME. Execute this # remediation AFTER testing on a non-production # system! # Include source function library. . /usr/share/scap-security-guide/remediation_functions package_command remove PKGNAME scap-security-guide-0.1.31/RHEL/6/input/oval/templates/template_OVAL_package_installed000066400000000000000000000017201301675746700305700ustar00rootroot00000000000000 Package PKGNAME Installed Red Hat Enterprise Linux 6 The RPM package PKGNAME should be installed. PKGNAME scap-security-guide-0.1.31/RHEL/6/input/oval/templates/template_kernel_module_disabled000066400000000000000000000041301301675746700307670ustar00rootroot00000000000000 Disable KERNMODULE Kernel Module Red Hat Enterprise Linux 6 The kernel module KERNMODULE should be disabled. /etc/modprobe.d ^.*\.conf$ ^\s*install\s+KERNMODULE\s+(/bin/false|/bin/true)$ 1 /etc/modprobe.conf ^\s*install\s+KERNMODULE\s+(/bin/false|/bin/true)$ 1 scap-security-guide-0.1.31/RHEL/6/input/oval/templates/template_package_removed000066400000000000000000000016751301675746700274420ustar00rootroot00000000000000 Package PKGNAME Removed Red Hat Enterprise Linux 6 The RPM package PKGNAME should be removed. PKGNAME scap-security-guide-0.1.31/RHEL/6/input/oval/templates/template_permissions000066400000000000000000000030531301675746700266710ustar00rootroot00000000000000 Verify FILEPATH Permissions Red Hat Enterprise Linux 6 This test makes sure that FILEPATH is owned by FILEUID, group owned by FILEGID, and has mode FILEMODE. If the target file or directory has an extended ACL then it will fail the mode check. FILEDIR UNIX_FILENAME FILEUID FILEGID STATEMODE scap-security-guide-0.1.31/RHEL/6/input/oval/templates/template_service_disabled000066400000000000000000000117231301675746700276100ustar00rootroot00000000000000 Service SERVICENAME Disabled Red Hat Enterprise Linux 6 The SERVICENAME service should be disabled if possible. SERVICENAME 0 SERVICENAME 1 SERVICENAME 2 SERVICENAME 3 SERVICENAME 4 SERVICENAME 5 SERVICENAME 6 false true scap-security-guide-0.1.31/RHEL/6/input/oval/templates/template_service_enabled000066400000000000000000000117021301675746700274300ustar00rootroot00000000000000 Service SERVICENAME Enabled Red Hat Enterprise Linux 6 The SERVICENAME service should be enabled if possible. SERVICENAME 0 SERVICENAME 1 SERVICENAME 2 SERVICENAME 3 SERVICENAME 4 SERVICENAME 5 SERVICENAME 6 true false scap-security-guide-0.1.31/RHEL/6/input/oval/templates/template_sysctl000066400000000000000000000014741301675746700256440ustar00rootroot00000000000000 Kernel "SYSCTLVAR" Parameter Configuration and Runtime Check Red Hat Enterprise Linux 6 The "SYSCTLVAR" kernel parameter should be set to the appropriate value in both system configuration and system runtime. scap-security-guide-0.1.31/RHEL/6/input/oval/templates/template_sysctl_ipv6000066400000000000000000000020171301675746700266020ustar00rootroot00000000000000 Kernel "SYSCTLVAR" Parameter Configuration and Runtime Check Red Hat Enterprise Linux 6 The "SYSCTLVAR" kernel parameter should be set to the appropriate value in both system configuration and system runtime. scap-security-guide-0.1.31/RHEL/6/input/oval/templates/template_sysctl_runtime000066400000000000000000000023251301675746700274030ustar00rootroot00000000000000 Kernel "SYSCTLVAR" Parameter Runtime Check Red Hat Enterprise Linux 6 The kernel "SYSCTLVAR" parameter should be set to "SYSCTLVAL" in system runtime. SYSCTLVAR SYSCTLVAL scap-security-guide-0.1.31/RHEL/6/input/oval/templates/template_sysctl_runtime_var000066400000000000000000000025571301675746700302620ustar00rootroot00000000000000 Kernel "SYSCTLVAR" Parameter Runtime Check Red Hat Enterprise Linux 6 The kernel "SYSCTLVAR" parameter should be set to the appropriate value in system runtime. SYSCTLVAR scap-security-guide-0.1.31/RHEL/6/input/oval/templates/template_sysctl_static000066400000000000000000000137101301675746700272070ustar00rootroot00000000000000 Kernel "SYSCTLVAR" Parameter Configuration Check Red Hat Enterprise Linux 6 The kernel "SYSCTLVAR" parameter should be set to "SYSCTLVAL" in the system configuration. /etc/sysctl.d ^.*$ (?:^|.*\n)[^#]*SYSCTLVAR[\s]*=[\s]*(\d+)[\s]*\n 1 SYSCTLVAL /etc/sysctl.conf (?:^|.*\n)[^#]*SYSCTLVAR[\s]*=[\s]*(\d+)[\s]*\n 1 scap-security-guide-0.1.31/RHEL/6/input/oval/templates/template_sysctl_static_var000066400000000000000000000142141301675746700300570ustar00rootroot00000000000000 Kernel "SYSCTLVAR" Parameter Configuration Check Red Hat Enterprise Linux 6 The kernel "SYSCTLVAR" parameter should be set to the appropriate value in the system configuration. /etc/sysctl.d ^.*$ (?:^|.*\n)[^#]*SYSCTLVAR[\s]*=[\s]*(\d+)[\s]*\n 1 /etc/sysctl.conf (?:^|.*\n)[^#]*SYSCTLVAR[\s]*=[\s]*(\d+)[\s]*\n 1 scap-security-guide-0.1.31/RHEL/6/input/oval/testoval.py000077500000000000000000000003521301675746700227170ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import testoval_module if __name__ == "__main__": testoval_module.main() scap-security-guide-0.1.31/RHEL/6/input/oval/xwindows_runlevel_setting.xml000066400000000000000000000020661301675746700265620ustar00rootroot00000000000000 Disable X Windows Startup By Setting Runlevel Red Hat Enterprise Linux 6 Checks /etc/inittab to ensure that default runlevel is set to 3. /etc/inittab ^[\s]*id:3:initdefault:[\s]*$ 1 scap-security-guide-0.1.31/RHEL/6/input/profiles/000077500000000000000000000000001301675746700213635ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/6/input/profiles/C2S.xml000066400000000000000000000743571301675746700225140ustar00rootroot00000000000000 C2S for Red Hat Enterprise Linux 6 This profile demonstrates compliance against the U.S. Government Commercial Cloud Services (C2S) baseline. This baseline was inspired by the Center for Internet Security (CIS) Red Hat Enterprise Linux 6 Benchmark, v1.2.0 - 06-25-2013. For the SCAP Security Guide project to remain in compliance with CIS' terms and conditions, specifically Restrictions(8), note there is no representation or claim that the C2S profile will ensure a system is in compliance or consistency with the CIS baseline. scap-security-guide-0.1.31/RHEL/6/input/profiles/CSCF-RHEL6-MLS.xml000066400000000000000000000425211301675746700240760ustar00rootroot00000000000000 CSCF RHEL6 MLS Core Baseline This profile reflects the Centralized Super Computing Facility (CSCF) baseline for Red Hat Enterprise Linux 6. This baseline has received government ATO through the ICD 503 process, utilizing the CNSSI 1253 cross domain overlay. This profile should be considered in active development. Additional tailoring will be needed, such as the creation of RBAC roles for production deployment. scap-security-guide-0.1.31/RHEL/6/input/profiles/common.xml000066400000000000000000000420241301675746700233770ustar00rootroot00000000000000 Common Profile for General-Purpose Systems This profile contains items common to general-purpose desktop and server installations. scap-security-guide-0.1.31/RHEL/6/input/profiles/desktop.xml000066400000000000000000000040101301675746700235510ustar00rootroot00000000000000 Desktop Baseline This profile is for a desktop installation of Red Hat Enterprise Linux 6. scap-security-guide-0.1.31/RHEL/6/input/profiles/fisma-medium-rhel6-server.xml000066400000000000000000000373031301675746700270120ustar00rootroot00000000000000 FISAMA Medium for Red Hat Enterprise Linux 6 FISMA Medium for Red Hat Enterprise Linux 6 scap-security-guide-0.1.31/RHEL/6/input/profiles/stig-rhel6-server-upstream.xml000066400000000000000000000141551301675746700272410ustar00rootroot00000000000000 Upstream STIG for Red Hat Enterprise Linux 6 Server This profile is developed under the DoD consensus model and DISA FSO Vendor STIG process, serving as the upstream development environment for the Red Hat Enterprise Linux 6 Server STIG. As a result of the upstream/downstream relationship between the SCAP Security Guide project and the official DISA FSO STIG baseline, users should expect variance between SSG and DISA FSO content. For official DISA FSO STIG content, refer to http://iase.disa.mil/stigs/os/unix-linux/Pages/red-hat.aspx. While this profile is packaged by Red Hat as part of the SCAP Security Guide package, please note that commercial support of this SCAP content is NOT available. This profile is provided as example SCAP content with no endorsement for suitability or production readiness. Support for this profile is provided by the upstream SCAP Security Guide community on a best-effort basis. The upstream project homepage is https://www.open-scap.org/security-policies/scap-security-guide/. scap-security-guide-0.1.31/RHEL/7/input/profiles/ospp-rhel7-server.xml000066400000000000000000000357051301675746700254240ustar00rootroot00000000000000 United States Government Configuration Baseline (USGCB / STIG) This is a *draft* profile for NIAP OSPP v4.0. This profile is being developed under the National Information Assurance Partnership. The scope of this profile is to configure Red Hat Enteprise Linux 7 against the NIAP Protection Profile for General Purpose Operating Systems v4.0. The NIAP OSPP profile also serves as a working draft for USGCB submission against RHEL7 Server. scap-security-guide-0.1.31/RHEL/7/input/profiles/pci-dss.xml000066400000000000000000000156071301675746700234610ustar00rootroot00000000000000 PCI-DSS v3 Control Baseline for Red Hat Enterprise Linux 7 This is a *draft* profile for PCI-DSS v3 scap-security-guide-0.1.31/RHEL/7/input/profiles/rht-ccp.xml000066400000000000000000000166421301675746700234570ustar00rootroot00000000000000 Red Hat Corporate Profile for Certified Cloud Providers (RH CCP) This is a *draft* SCAP profile for Red Hat Certified Cloud Providers scap-security-guide-0.1.31/RHEL/7/input/profiles/stig-rhel7-workstation-upstream.xml000066400000000000000000000051401301675746700303130ustar00rootroot00000000000000 STIG for Red Hat Enterprise Linux 7 Workstation This is a *draft* profile for STIG. This profile is being developed under the DoD consensus model to become a STIG in coordination with DISA FSO.

    Where is the RHEL7 STIG?

    • Question: May I deploy a product if no STIG exists?
      Answer: Yes, based on mission need and with DAA approval.
    • Question: What do I use if there is no STIG?
      Answer: DISA FSO developed Security Requirement Guides (SRGs) to address technology areas. In the absence of a STIG, an SRG can be used to determine compliance with DoD policies. If there is no applicable SRG or STIG, industry or vendor recommended practices may be used. Examples include Center for Internet Security Benchmarks, Payment Card Industry requirements or the vendor's own security documentation.
    Source: http://iase.disa.mil/stigs/Pages/faqs.aspx#STIG

    scap-security-guide-0.1.31/RHEL/7/kickstart/000077500000000000000000000000001301675746700204015ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/7/kickstart/ssg-rhel7-ospp-ks.cfg000066400000000000000000000131431301675746700242710ustar00rootroot00000000000000# SCAP Security Guide OSPP/USGCB profile kickstart for Red Hat Enterprise Linux 7 Server # Version: 0.0.2 # Date: 2015-11-19 # # Based on: # http://fedoraproject.org/wiki/Anaconda/Kickstart # https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Installation_Guide/sect-kickstart-syntax.html # http://usgcb.nist.gov/usgcb/content/configuration/workstation-ks.cfg # Install a fresh new system (optional) install # Specify installation method to use for installation # To use a different one comment out the 'url' one below, update # the selected choice with proper options & un-comment it # # Install from an installation tree on a remote server via FTP or HTTP: # --url the URL to install from # # Example: # # url --url=http://192.168.122.1/image # # Modify concrete URL in the above example appropriately to reflect the actual # environment machine is to be installed in # # Other possible / supported installation methods: # * install from the first CD-ROM/DVD drive on the system: # # cdrom # # * install from a directory of ISO images on a local drive: # # harddrive --partition=hdb2 --dir=/tmp/install-tree # # * install from provided NFS server: # # nfs --server= --dir= [--opts=] # # Set language to use during installation and the default language to use on the installed system (required) lang en_US.UTF-8 # Set system keyboard type / layout (required) keyboard us # Configure network information for target system and activate network devices in the installer environment (optional) # --onboot enable device at a boot time # --device device to be activated and / or configured with the network command # --bootproto method to obtain networking configuration for device (default dhcp) # --noipv6 disable IPv6 on this device # # NOTE: Usage of DHCP will fail CCE-27021-5 (DISA FSO RHEL-06-000292). To use static IP configuration, # "--bootproto=static" must be used. For example: # network --bootproto=static --ip=10.0.2.15 --netmask=255.255.255.0 --gateway=10.0.2.254 --nameserver 192.168.2.1,192.168.3.1 # network --onboot yes --device eth0 --bootproto dhcp --noipv6 # Set the system's root password (required) # Plaintext password is: server # Refer to e.g. http://fedoraproject.org/wiki/Anaconda/Kickstart#rootpw to see how to create # encrypted password form for different plaintext password rootpw --iscrypted $6$rhel6usgcb$aS6oPGXcPKp3OtFArSrhRwu6sN8q2.yEGY7AIwDOQd23YCtiz9c5mXbid1BzX9bmXTEZi.hCzTEXFosVBI5ng0 # Configure firewall settings for the system (optional) # --enabled reject incoming connections that are not in response to outbound requests # --ssh allow sshd service through the firewall firewall --enabled --ssh # Set up the authentication options for the system (required) # --enableshadow enable shadowed passwords by default # --passalgo hash / crypt algorithm for new passwords # See the manual page for authconfig for a complete list of possible options. authconfig --enableshadow --passalgo=sha512 # State of SELinux on the installed system (optional) # Defaults to enforcing selinux --enforcing # Set the system time zone (required) timezone --utc America/New_York # Specify how the bootloader should be installed (required) # Plaintext password is: password # Refer to e.g. http://fedoraproject.org/wiki/Anaconda/Kickstart#rootpw to see how to create # encrypted password form for different plaintext password bootloader --location=mbr --append="crashkernel=auto rhgb quiet" --password=$6$rhel6usgcb$kOzIfC4zLbuo3ECp1er99NRYikN419wxYMmons8Vm/37Qtg0T8aB9dKxHwqapz8wWAFuVkuI/UJqQBU92bA5C0 # Initialize (format) all disks (optional) zerombr # The following partition layout scheme assumes disk of size 20GB or larger # Modify size of partitions appropriately to reflect actual machine's hardware # # Remove Linux partitions from the system prior to creating new ones (optional) # --linux erase all Linux partitions # --initlabel initialize the disk label to the default based on the underlying architecture clearpart --linux --initlabel # Create primary system partitions (required for installs) part /boot --fstype=xfs --size=512 part pv.01 --grow --size=1 # Create a Logical Volume Management (LVM) group (optional) volgroup VolGroup --pesize=4096 pv.01 # Create particular logical volumes (optional) logvol / --fstype=xfs --name=LogVol06 --vgname=VolGroup --size=12288 --grow # CCE-26557-9: Ensure /home Located On Separate Partition logvol /home --fstype=xfs --name=LogVol02 --vgname=VolGroup --size=1024 --fsoptions="nodev" # CCE-26435-8: Ensure /tmp Located On Separate Partition logvol /tmp --fstype=xfs --name=LogVol01 --vgname=VolGroup --size=1024 --fsoptions="nodev,noexec,nosuid" # CCE-26639-5: Ensure /var Located On Separate Partition logvol /var --fstype=xfs --name=LogVol03 --vgname=VolGroup --size=2048 --fsoptions="nodev" # CCE-26215-4: Ensure /var/log Located On Separate Partition logvol /var/log --fstype=xfs --name=LogVol04 --vgname=VolGroup --size=1024 --fsoptions="nodev" # CCE-26436-6: Ensure /var/log/audit Located On Separate Partition logvol /var/log/audit --fstype=xfs --name=LogVol05 --vgname=VolGroup --size=512 --fsoptions="nodev" logvol swap --name=lv_swap --vgname=VolGroup --size=2016 %addon org_fedora_oscap content-type = scap-security-guide profile = ospp-rhel7-server %end # Packages selection (%packages section is required) %packages # Require @Base @Base # Install selected additional packages (required by profile) # CCE-27024-9: Install AIDE aide # Install libreswan package libreswan %end # End of %packages section # Reboot after the installation is complete (optional) # --eject attempt to eject CD or DVD media before rebooting reboot --eject scap-security-guide-0.1.31/RHEL/7/kickstart/ssg-rhel7-pci-dss-server-with-gui-oaa-ks.cfg000066400000000000000000000125711301675746700304530ustar00rootroot00000000000000# SCAP Security Guide PCI-DSS profile kickstart for Red Hat Enterprise Linux 7 Server # Version: 0.0.2 # Date: 2015-08-02 # # Based on: # http://fedoraproject.org/wiki/Anaconda/Kickstart # https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Installation_Guide/sect-kickstart-syntax.html # http://usgcb.nist.gov/usgcb/content/configuration/workstation-ks.cfg # Install a fresh new system (optional) install # Specify installation method to use for installation # To use a different one comment out the 'url' one below, update # the selected choice with proper options & un-comment it # # Install from an installation tree on a remote server via FTP or HTTP: # --url the URL to install from # # Example: # # url --url=http://192.168.122.1/image # # Modify concrete URL in the above example appropriately to reflect the actual # environment machine is to be installed in # # Other possible / supported installation methods: # * install from the first CD-ROM/DVD drive on the system: # # cdrom # # * install from a directory of ISO images on a local drive: # # harddrive --partition=hdb2 --dir=/tmp/install-tree # # * install from provided NFS server: # # nfs --server= --dir= [--opts=] # # Set language to use during installation and the default language to use on the installed system (required) lang en_US.UTF-8 # Set system keyboard type / layout (required) keyboard us # Configure network information for target system and activate network devices in the installer environment (optional) # --onboot enable device at a boot time # --device device to be activated and / or configured with the network command # --bootproto method to obtain networking configuration for device (default dhcp) # --noipv6 disable IPv6 on this device network --onboot yes --device eth0 --bootproto dhcp --noipv6 # Set the system's root password (required) # Plaintext password is: server # Refer to e.g. http://fedoraproject.org/wiki/Anaconda/Kickstart#rootpw to see how to create # encrypted password form for different plaintext password rootpw --iscrypted $6$rhel6usgcb$aS6oPGXcPKp3OtFArSrhRwu6sN8q2.yEGY7AIwDOQd23YCtiz9c5mXbid1BzX9bmXTEZi.hCzTEXFosVBI5ng0 # Configure firewall settings for the system (optional) # --enabled reject incoming connections that are not in response to outbound requests # --ssh allow sshd service through the firewall firewall --enabled --ssh # Set up the authentication options for the system (required) # --enableshadow enable shadowed passwords by default # --passalgo hash / crypt algorithm for new passwords # See the manual page for authconfig for a complete list of possible options. authconfig --enableshadow --passalgo=sha512 # State of SELinux on the installed system (optional) # Defaults to enforcing selinux --enforcing # Set the system time zone (required) timezone --utc America/New_York # Specify how the bootloader should be installed (required) # Plaintext password is: password # Refer to e.g. http://fedoraproject.org/wiki/Anaconda/Kickstart#rootpw to see how to create # encrypted password form for different plaintext password bootloader --location=mbr --append="crashkernel=auto rhgb quiet" --password=$6$rhel6usgcb$kOzIfC4zLbuo3ECp1er99NRYikN419wxYMmons8Vm/37Qtg0T8aB9dKxHwqapz8wWAFuVkuI/UJqQBU92bA5C0 # Initialize (format) all disks (optional) zerombr # The following partition layout scheme assumes disk of size 20GB or larger # Modify size of partitions appropriately to reflect actual machine's hardware # # Remove Linux partitions from the system prior to creating new ones (optional) # --linux erase all Linux partitions # --initlabel initialize the disk label to the default based on the underlying architecture clearpart --linux --initlabel # Create primary system partitions (required for installs) part /boot --fstype=xfs --size=512 part pv.01 --grow --size=1 # Create a Logical Volume Management (LVM) group (optional) volgroup VolGroup --pesize=4096 pv.01 # Create particular logical volumes (optional) logvol / --fstype=xfs --name=LogVol06 --vgname=VolGroup --size=12288 --grow # CCE-26557-9: Ensure /home Located On Separate Partition logvol /home --fstype=xfs --name=LogVol02 --vgname=VolGroup --size=1024 --fsoptions="nodev" # CCE-26435-8: Ensure /tmp Located On Separate Partition logvol /tmp --fstype=xfs --name=LogVol01 --vgname=VolGroup --size=1024 --fsoptions="nodev,noexec,nosuid" # CCE-26639-5: Ensure /var Located On Separate Partition logvol /var --fstype=xfs --name=LogVol03 --vgname=VolGroup --size=2048 --fsoptions="nodev" # CCE-26215-4: Ensure /var/log Located On Separate Partition logvol /var/log --fstype=xfs --name=LogVol04 --vgname=VolGroup --size=1024 --fsoptions="nodev" # CCE-26436-6: Ensure /var/log/audit Located On Separate Partition logvol /var/log/audit --fstype=xfs --name=LogVol05 --vgname=VolGroup --size=512 --fsoptions="nodev" logvol swap --name=lv_swap --vgname=VolGroup --size=2016 %addon org_fedora_oscap content-type = scap-security-guide profile = pci-dss %end # Packages selection (%packages section is required) %packages # Require 'Server with GUI' package environment to be installed @^Server with GUI # Install selected additional packages (required by PCI-DSS profile) # CCE-27024-9: Install AIDE aide # Install libreswan package libreswan %end # End of %packages section # Reboot after the installation is complete (optional) # --eject attempt to eject CD or DVD media before rebooting reboot --eject scap-security-guide-0.1.31/RHEL/7/templates/000077500000000000000000000000001301675746700204005ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/7/templates/csv/000077500000000000000000000000001301675746700211735ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/7/templates/csv/accounts_password.csv000066400000000000000000000001171301675746700254500ustar00rootroot00000000000000dcredit difok lcredit maxclassrepeat maxrepeat minclass minlen ocredit ucredit scap-security-guide-0.1.31/RHEL/7/templates/csv/file_dir_permissions.csv000066400000000000000000000001101301675746700261100ustar00rootroot00000000000000/etc,shadow,0,0,0000 #/boot/grub,grub.conf,0,0,600 # different filename scap-security-guide-0.1.31/RHEL/7/templates/csv/kernel_modules_disabled.csv000066400000000000000000000000711301675746700265450ustar00rootroot00000000000000cramfs dccp freevxfs hfs hfsplus jffs2 sctp squashfs udf scap-security-guide-0.1.31/RHEL/7/templates/csv/packages_installed.csv000066400000000000000000000002141301675746700255220ustar00rootroot00000000000000audit cronie esc irqbalance #kernel-PAE libreswan openssh-server pam_pkcs11 policycoreutils postfix psacct rsyslog screen sssd tcp_wrappers scap-security-guide-0.1.31/RHEL/7/templates/csv/packages_removed.csv000066400000000000000000000005511301675746700252100ustar00rootroot00000000000000acpid at avahi bind bluez certmonger cups cyrus-sasl dbus dhcp dovecot httpd kernel-tools kexec-tools libcgroup libcgroup-tools net-snmp nfs-utils oddjob openssh-server portreserve qpid-cpp-server quagga quota-nld rhnsd rsh rsh-server samba smartmontools squid subscription-manager sysstat talk talk-server telnet-server tftp-server vsftpd xinetd ypbind ypserv scap-security-guide-0.1.31/RHEL/7/templates/csv/services_disabled.csv000066400000000000000000000012011301675746700253540ustar00rootroot00000000000000# service_name, package_name, daemon_name (as recognized by chkconfig / systemd. To be used when daemon_name differs from service_name) abrtd,, acpid,, atd,, autofs,, #avahi-daemon,, #bluetooth,, certmonger,, cgconfig,, cgred,, #cups,, debug-shell,, dhcpd,, dovecot,, httpd,, kdump,, mdmonitor,, messagebus,, named,, netconsole,, nfs,, #nfslock, oddjobd,, portreserve,, qpidd,, quota_nld,, rdisc,, #rexec,, rhnsd,, rhsmcertd,, #rlogin,, #rpcgssd,, #todo check this! #rpcidmapd,, #todo check this! #rpcsvcgssd,, #todo check this! #rsh,, saslauthd,, smartd,, smb,, snmpd,, squid,, sshd,, sysstat,, #telnet,, vsftpd,, xinetd,, ypbind,, zebra,, scap-security-guide-0.1.31/RHEL/7/templates/csv/services_enabled.csv000066400000000000000000000001361301675746700252050ustar00rootroot00000000000000auditd, #chronyd_or_ntpd, crond, firewalld, irqbalance, ntpd, postfix, psacct, rsyslog, sssd, scap-security-guide-0.1.31/RHEL/7/templates/csv/sysctl_values.csv000066400000000000000000000014771301675746700246210ustar00rootroot00000000000000fs.suid_dumpable,0 kernel.dmesg_restrict,1 #kernel.exec-shield,1 kernel.randomize_va_space,2 net.ipv4.conf.all.accept_redirects, net.ipv4.conf.all.accept_source_route, net.ipv4.conf.all.log_martians, net.ipv4.conf.all.rp_filter, net.ipv4.conf.all.secure_redirects, net.ipv4.conf.all.send_redirects,0 net.ipv4.conf.default.accept_redirects, net.ipv4.conf.default.accept_source_route, net.ipv4.conf.default.log_martians, net.ipv4.conf.default.rp_filter, net.ipv4.conf.default.secure_redirects, net.ipv4.conf.default.send_redirects,0 net.ipv4.icmp_echo_ignore_broadcasts, net.ipv4.icmp_ignore_bogus_error_responses, net.ipv4.ip_forward,0 net.ipv4.tcp_syncookies, net.ipv6.conf.default.accept_ra, net.ipv6.conf.default.accept_redirects, net.ipv6.conf.all.accept_ra, net.ipv6.conf.all.accept_redirects, net.ipv6.conf.all.disable_ipv6,1 scap-security-guide-0.1.31/RHEL/7/templates/static/000077500000000000000000000000001301675746700216675ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/7/templates/static/ansible/000077500000000000000000000000001301675746700233045ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/7/templates/static/ansible/account_disable_post_pw_expiration.yml000066400000000000000000000002761301675746700331700ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 - name: "Disable POST password expiration" lineinfile: create=yes dest="/etc/default/useradd" regexp="^INACTIVE" line="INACTIVE=-1" scap-security-guide-0.1.31/RHEL/7/templates/static/ansible/service_avahi-daemon_disabled.yml000066400000000000000000000004761301675746700317360ustar00rootroot00000000000000# platform = multi_platform_rhel, multi_platform_fedora - name: Disable service avahi service: name="{{item}}" enabled="no" state="stopped" with_items: - avahi-daemon - name: Disable avahi socket service: name="{{item}}" enabled="no" state="stopped" with_items: - avahi-socket scap-security-guide-0.1.31/RHEL/7/templates/static/ansible/sshd_disable_empty_passwords.yml000066400000000000000000000003231301675746700317740ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 - name: "SSHD: Disable empty passwords" lineinfile: create=yes dest="/etc/ssh/sshd_config" regexp="^PermitEmptyPasswords" line="PermitEmptyPasswords no" scap-security-guide-0.1.31/RHEL/7/templates/static/ansible/sshd_do_not_permit_user_env.yml000066400000000000000000000003341301675746700316200ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 - name: "SSHD: Do not permit user environment" lineinfile: create=yes dest="/etc/ssh/sshd_config" regexp="^PermitUserEnvironment" line="PermitUserEnvironment no" scap-security-guide-0.1.31/RHEL/7/templates/static/ansible/sshd_enable_warning_banner.yml000066400000000000000000000002751301675746700313540ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 - name: "SSHD: Enable warning banner" lineinfile: create=yes dest="/etc/ssh/sshd_config" regexp="^Banner" line="Banner /etc/issue" scap-security-guide-0.1.31/RHEL/7/templates/static/ansible/sshd_set_idle_timeout.yml000066400000000000000000000003731301675746700304110ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 - name: "SSHD: Set client alive interval" lineinfile: create=yes dest="/etc/ssh/sshd_config" regexp="^ClientAliveInterval" line="ClientAliveInterval (ansible-populate sshd_idle_timeout_value)" scap-security-guide-0.1.31/RHEL/7/templates/static/bash/000077500000000000000000000000001301675746700226045ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/7/templates/static/bash/account_disable_post_pw_expiration.sh000066400000000000000000000003651301675746700323000ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 . /usr/share/scap-security-guide/remediation_functions populate var_account_disable_post_pw_expiration replace_or_append /etc/default/useradd INACTIVE "$var_account_disable_post_pw_expiration" '' '%s=%s' scap-security-guide-0.1.31/RHEL/7/templates/static/bash/accounts_maximum_age_login_defs.sh000066400000000000000000000006201301675746700315170ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 . /usr/share/scap-security-guide/remediation_functions populate var_accounts_maximum_age_login_defs grep -q ^PASS_MAX_DAYS /etc/login.defs && \ sed -i "s/PASS_MAX_DAYS.*/PASS_MAX_DAYS $var_accounts_maximum_age_login_defs/g" /etc/login.defs if ! [ $? -eq 0 ]; then echo "PASS_MAX_DAYS $var_accounts_maximum_age_login_defs" >> /etc/login.defs fi scap-security-guide-0.1.31/RHEL/7/templates/static/bash/accounts_minimum_age_login_defs.sh000066400000000000000000000006201301675746700315150ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 . /usr/share/scap-security-guide/remediation_functions populate var_accounts_minimum_age_login_defs grep -q ^PASS_MIN_DAYS /etc/login.defs && \ sed -i "s/PASS_MIN_DAYS.*/PASS_MIN_DAYS $var_accounts_minimum_age_login_defs/g" /etc/login.defs if ! [ $? -eq 0 ]; then echo "PASS_MIN_DAYS $var_accounts_minimum_age_login_defs" >> /etc/login.defs fi scap-security-guide-0.1.31/RHEL/7/templates/static/bash/accounts_no_uid_except_zero.sh000066400000000000000000000001651301675746700307250ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 awk -F: '$3 == 0 && $1 != "root" { print $1 }' /etc/passwd | xargs passwd -l scap-security-guide-0.1.31/RHEL/7/templates/static/bash/accounts_password_minlen_login_defs.sh000066400000000000000000000006301301675746700324330ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 . /usr/share/scap-security-guide/remediation_functions populate var_accounts_password_minlen_login_defs grep -q ^PASS_MIN_LEN /etc/login.defs && \ sed -i "s/PASS_MIN_LEN.*/PASS_MIN_LEN $var_accounts_password_minlen_login_defs/g" /etc/login.defs if ! [ $? -eq 0 ]; then echo "PASS_MIN_LEN $var_accounts_password_minlen_login_defs" >> /etc/login.defs fi scap-security-guide-0.1.31/RHEL/7/templates/static/bash/accounts_password_pam_retry.sh000066400000000000000000000006071301675746700307660ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 . /usr/share/scap-security-guide/remediation_functions populate var_password_pam_retry if grep -q "retry=" /etc/pam.d/system-auth; then sed -i --follow-symlinks "s/\(retry *= *\).*/\1$var_password_pam_retry/" /etc/pam.d/system-auth else sed -i --follow-symlinks "/pam_pwquality.so/ s/$/ retry=$var_password_pam_retry/" /etc/pam.d/system-auth fi scap-security-guide-0.1.31/RHEL/7/templates/static/bash/accounts_password_warn_age_login_defs.sh000066400000000000000000000006421301675746700327370ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 . /usr/share/scap-security-guide/remediation_functions populate var_accounts_password_warn_age_login_defs grep -q ^PASS_WARN_AGE /etc/login.defs && \ sed -i "s/PASS_WARN_AGE.*/PASS_WARN_AGE $var_accounts_password_warn_age_login_defs/g" /etc/login.defs if ! [ $? -eq 0 ]; then echo "PASS_WARN_AGE $var_accounts_password_warn_age_login_defs" >> /etc/login.defs fi scap-security-guide-0.1.31/RHEL/7/templates/static/bash/accounts_passwords_pam_faillock_deny_root.sh000066400000000000000000000013151301675746700336470ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 if [ $( grep -c "auth.*required.*pam_faillock.so.*even_deny_root" /etc/pam.d/system-auth ) -eq 0 ]; then BEGINNING_TXT=$( cat /etc/pam.d/system-auth | grep "auth.*required.*pam_faillock.so" | sed -e 's/[]\/$*.^|[]/\\&/g' ) sed -i --follow-symlinks "s/$BEGINNING_TXT/$BEGINNING_TXT even_deny_root/" /etc/pam.d/system-auth fi if [ $( grep -c "auth.*default.*die.*pam_faillock.so.*even_deny_root" /etc/pam.d/system-auth ) -eq 0 ]; then BEGINNING_TXT=$( cat /etc/pam.d/system-auth | grep "auth.*default.*die.*pam_faillock.so" | sed -e 's/[]\/$*.^|[]/\\&/g' ) sed -i --follow-symlinks "s/$BEGINNING_TXT/$BEGINNING_TXT even_deny_root/" /etc/pam.d/system-auth fi scap-security-guide-0.1.31/RHEL/7/templates/static/bash/accounts_tmout.sh000066400000000000000000000006231301675746700262100ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 . /usr/share/scap-security-guide/remediation_functions populate var_accounts_tmout if grep --silent ^TMOUT /etc/profile ; then sed -i "s/^TMOUT.*/TMOUT = $var_accounts_tmout/g" /etc/profile else echo -e "\n# Set TMOUT to $var_accounts_tmout per security requirements" >> /etc/profile echo "TMOUT = $var_accounts_tmout" >> /etc/profile fi scap-security-guide-0.1.31/RHEL/7/templates/static/bash/accounts_umask_etc_login_defs.sh000066400000000000000000000005021301675746700312000ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 . /usr/share/scap-security-guide/remediation_functions populate var_accounts_user_umask grep -q UMASK /etc/login.defs && \ sed -i "s/UMASK.*/UMASK $var_accounts_user_umask/g" /etc/login.defs if ! [ $? -eq 0 ]; then echo "UMASK $var_accounts_user_umask" >> /etc/login.defs fi scap-security-guide-0.1.31/RHEL/7/templates/static/bash/accounts_umask_etc_profile.sh000066400000000000000000000004711301675746700305340ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 . /usr/share/scap-security-guide/remediation_functions populate var_accounts_user_umask grep -q umask /etc/profile && \ sed -i "s/umask.*/umask $var_accounts_user_umask/g" /etc/profile if ! [ $? -eq 0 ]; then echo "umask $var_accounts_user_umask" >> /etc/profile fi scap-security-guide-0.1.31/RHEL/7/templates/static/bash/audit_rules_dac_modification_chmod.sh000066400000000000000000000014531301675746700321710ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions # Perform the remediation for the syscall rule # Retrieve hardware architecture of the underlying system [ $(getconf LONG_BIT) = "32" ] && RULE_ARCHS=("b32") || RULE_ARCHS=("b32" "b64") for ARCH in "${RULE_ARCHS[@]}" do PATTERN="-a always,exit -F arch=$ARCH -S .* -F auid>=1000 -F auid!=4294967295 -k *" GROUP="chmod" FULL_RULE="-a always,exit -F arch=$ARCH -S chmod -S fchmod -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod" # Perform the remediation for both possible tools: 'auditctl' and 'augenrules' fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" fix_audit_syscall_rule "augenrules" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" done scap-security-guide-0.1.31/RHEL/7/templates/static/bash/audit_rules_dac_modification_chown.sh000066400000000000000000000014711301675746700322150ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions # Perform the remediation for the syscall rule # Retrieve hardware architecture of the underlying system [ $(getconf LONG_BIT) = "32" ] && RULE_ARCHS=("b32") || RULE_ARCHS=("b32" "b64") for ARCH in "${RULE_ARCHS[@]}" do PATTERN="-a always,exit -F arch=${ARCH} -S .* -F auid>=1000 -F auid!=4294967295 -k *" GROUP="chown" FULL_RULE="-a always,exit -F arch=${ARCH} -S chown -S fchown -S fchownat -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod" # Perform the remediation for both possible tools: 'auditctl' and 'augenrules' fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" fix_audit_syscall_rule "augenrules" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" done scap-security-guide-0.1.31/RHEL/7/templates/static/bash/audit_rules_dac_modification_fchmod.sh000066400000000000000000000014531301675746700323370ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions # Perform the remediation for the syscall rule # Retrieve hardware architecture of the underlying system [ $(getconf LONG_BIT) = "32" ] && RULE_ARCHS=("b32") || RULE_ARCHS=("b32" "b64") for ARCH in "${RULE_ARCHS[@]}" do PATTERN="-a always,exit -F arch=$ARCH -S .* -F auid>=1000 -F auid!=4294967295 -k *" GROUP="chmod" FULL_RULE="-a always,exit -F arch=$ARCH -S chmod -S fchmod -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod" # Perform the remediation for both possible tools: 'auditctl' and 'augenrules' fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" fix_audit_syscall_rule "augenrules" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" done scap-security-guide-0.1.31/RHEL/7/templates/static/bash/audit_rules_dac_modification_fchmodat.sh000066400000000000000000000014531301675746700326640ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions # Perform the remediation for the syscall rule # Retrieve hardware architecture of the underlying system [ $(getconf LONG_BIT) = "32" ] && RULE_ARCHS=("b32") || RULE_ARCHS=("b32" "b64") for ARCH in "${RULE_ARCHS[@]}" do PATTERN="-a always,exit -F arch=$ARCH -S .* -F auid>=1000 -F auid!=4294967295 -k *" GROUP="chmod" FULL_RULE="-a always,exit -F arch=$ARCH -S chmod -S fchmod -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod" # Perform the remediation for both possible tools: 'auditctl' and 'augenrules' fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" fix_audit_syscall_rule "augenrules" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" done scap-security-guide-0.1.31/RHEL/7/templates/static/bash/audit_rules_dac_modification_fchown.sh000066400000000000000000000014711301675746700323630ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions # Perform the remediation for the syscall rule # Retrieve hardware architecture of the underlying system [ $(getconf LONG_BIT) = "32" ] && RULE_ARCHS=("b32") || RULE_ARCHS=("b32" "b64") for ARCH in "${RULE_ARCHS[@]}" do PATTERN="-a always,exit -F arch=${ARCH} -S .* -F auid>=1000 -F auid!=4294967295 -k *" GROUP="chown" FULL_RULE="-a always,exit -F arch=${ARCH} -S chown -S fchown -S fchownat -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod" # Perform the remediation for both possible tools: 'auditctl' and 'augenrules' fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" fix_audit_syscall_rule "augenrules" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" done scap-security-guide-0.1.31/RHEL/7/templates/static/bash/audit_rules_dac_modification_fchownat.sh000066400000000000000000000014711301675746700327100ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions # Perform the remediation for the syscall rule # Retrieve hardware architecture of the underlying system [ $(getconf LONG_BIT) = "32" ] && RULE_ARCHS=("b32") || RULE_ARCHS=("b32" "b64") for ARCH in "${RULE_ARCHS[@]}" do PATTERN="-a always,exit -F arch=${ARCH} -S .* -F auid>=1000 -F auid!=4294967295 -k *" GROUP="chown" FULL_RULE="-a always,exit -F arch=${ARCH} -S chown -S fchown -S fchownat -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod" # Perform the remediation for both possible tools: 'auditctl' and 'augenrules' fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" fix_audit_syscall_rule "augenrules" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" done scap-security-guide-0.1.31/RHEL/7/templates/static/bash/audit_rules_dac_modification_fremovexattr.sh000066400000000000000000000015221301675746700336220ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions # Perform the remediation for the syscall rule # Retrieve hardware architecture of the underlying system [ $(getconf LONG_BIT) = "32" ] && RULE_ARCHS=("b32") || RULE_ARCHS=("b32" "b64") for ARCH in "${RULE_ARCHS[@]}" do PATTERN="-a always,exit .* -F auid>=1000 -F auid!=4294967295 -k *" GROUP="xattr" FULL_RULE="-a always,exit -F arch=${ARCH} -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod" # Perform the remediation for both possible tools: 'auditctl' and 'augenrules' fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" fix_audit_syscall_rule "augenrules" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" done scap-security-guide-0.1.31/RHEL/7/templates/static/bash/audit_rules_dac_modification_fsetxattr.sh000066400000000000000000000015221301675746700331200ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions # Perform the remediation for the syscall rule # Retrieve hardware architecture of the underlying system [ $(getconf LONG_BIT) = "32" ] && RULE_ARCHS=("b32") || RULE_ARCHS=("b32" "b64") for ARCH in "${RULE_ARCHS[@]}" do PATTERN="-a always,exit .* -F auid>=1000 -F auid!=4294967295 -k *" GROUP="xattr" FULL_RULE="-a always,exit -F arch=${ARCH} -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod" # Perform the remediation for both possible tools: 'auditctl' and 'augenrules' fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" fix_audit_syscall_rule "augenrules" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" done scap-security-guide-0.1.31/RHEL/7/templates/static/bash/audit_rules_dac_modification_lchown.sh000066400000000000000000000014711301675746700323710ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions # Perform the remediation for the syscall rule # Retrieve hardware architecture of the underlying system [ $(getconf LONG_BIT) = "32" ] && RULE_ARCHS=("b32") || RULE_ARCHS=("b32" "b64") for ARCH in "${RULE_ARCHS[@]}" do PATTERN="-a always,exit -F arch=${ARCH} -S .* -F auid>=1000 -F auid!=4294967295 -k *" GROUP="chown" FULL_RULE="-a always,exit -F arch=${ARCH} -S chown -S fchown -S fchownat -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod" # Perform the remediation for both possible tools: 'auditctl' and 'augenrules' fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" fix_audit_syscall_rule "augenrules" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" done scap-security-guide-0.1.31/RHEL/7/templates/static/bash/audit_rules_dac_modification_lremovexattr.sh000066400000000000000000000015221301675746700336300ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions # Perform the remediation for the syscall rule # Retrieve hardware architecture of the underlying system [ $(getconf LONG_BIT) = "32" ] && RULE_ARCHS=("b32") || RULE_ARCHS=("b32" "b64") for ARCH in "${RULE_ARCHS[@]}" do PATTERN="-a always,exit .* -F auid>=1000 -F auid!=4294967295 -k *" GROUP="xattr" FULL_RULE="-a always,exit -F arch=${ARCH} -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod" # Perform the remediation for both possible tools: 'auditctl' and 'augenrules' fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" fix_audit_syscall_rule "augenrules" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" done scap-security-guide-0.1.31/RHEL/7/templates/static/bash/audit_rules_dac_modification_lsetxattr.sh000066400000000000000000000015221301675746700331260ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions # Perform the remediation for the syscall rule # Retrieve hardware architecture of the underlying system [ $(getconf LONG_BIT) = "32" ] && RULE_ARCHS=("b32") || RULE_ARCHS=("b32" "b64") for ARCH in "${RULE_ARCHS[@]}" do PATTERN="-a always,exit .* -F auid>=1000 -F auid!=4294967295 -k *" GROUP="xattr" FULL_RULE="-a always,exit -F arch=${ARCH} -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod" # Perform the remediation for both possible tools: 'auditctl' and 'augenrules' fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" fix_audit_syscall_rule "augenrules" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" done scap-security-guide-0.1.31/RHEL/7/templates/static/bash/audit_rules_dac_modification_removexattr.sh000066400000000000000000000015221301675746700334540ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions # Perform the remediation for the syscall rule # Retrieve hardware architecture of the underlying system [ $(getconf LONG_BIT) = "32" ] && RULE_ARCHS=("b32") || RULE_ARCHS=("b32" "b64") for ARCH in "${RULE_ARCHS[@]}" do PATTERN="-a always,exit .* -F auid>=1000 -F auid!=4294967295 -k *" GROUP="xattr" FULL_RULE="-a always,exit -F arch=${ARCH} -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod" # Perform the remediation for both possible tools: 'auditctl' and 'augenrules' fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" fix_audit_syscall_rule "augenrules" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" done scap-security-guide-0.1.31/RHEL/7/templates/static/bash/audit_rules_dac_modification_setxattr.sh000066400000000000000000000015221301675746700327520ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions # Perform the remediation for the syscall rule # Retrieve hardware architecture of the underlying system [ $(getconf LONG_BIT) = "32" ] && RULE_ARCHS=("b32") || RULE_ARCHS=("b32" "b64") for ARCH in "${RULE_ARCHS[@]}" do PATTERN="-a always,exit .* -F auid>=1000 -F auid!=4294967295 -k *" GROUP="xattr" FULL_RULE="-a always,exit -F arch=${ARCH} -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod" # Perform the remediation for both possible tools: 'auditctl' and 'augenrules' fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" fix_audit_syscall_rule "augenrules" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" done scap-security-guide-0.1.31/RHEL/7/templates/static/bash/audit_rules_file_deletion_events.sh000066400000000000000000000016021301675746700317250ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions # Perform the remediation for the syscall rule # Retrieve hardware architecture of the underlying system [ $(getconf LONG_BIT) = "32" ] && RULE_ARCHS=("b32") || RULE_ARCHS=("b32" "b64") for ARCH in "${RULE_ARCHS[@]}" do PATTERN="-a always,exit -F arch=$ARCH -S .* -F auid>=1000 -F auid!=4294967295 -k *" # Use escaped BRE regex to specify rule group GROUP="\(rmdir\|unlink\|rename\)" FULL_RULE="-a always,exit -F arch=$ARCH -S rmdir -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k delete" # Perform the remediation for both possible tools: 'auditctl' and 'augenrules' fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" fix_audit_syscall_rule "augenrules" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" done scap-security-guide-0.1.31/RHEL/7/templates/static/bash/audit_rules_kernel_module_loading.sh000066400000000000000000000031531301675746700320640ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions # First perform the remediation of the syscall rule # Retrieve hardware architecture of the underlying system # Note: 32-bit kernel modules can't be loaded / unloaded on 64-bit kernel => # it's not required on a 64-bit system to check also for the presence # of 32-bit's equivalent of the corresponding rule. Therefore for # each system it's enought to check presence of system's native rule form. [ $(getconf LONG_BIT) = "32" ] && RULE_ARCHS=("b32") || RULE_ARCHS=("b64") for ARCH in "${RULE_ARCHS[@]}" do PATTERN="-a always,exit -F arch=$ARCH -S .* -k *" # Use escaped BRE regex to specify rule group GROUP="\(init\|delete\)_module" FULL_RULE="-a always,exit -F arch=$ARCH -S init_module -S delete_module -k modules" # Perform the remediation for both possible tools: 'auditctl' and 'augenrules' fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" fix_audit_syscall_rule "augenrules" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" done # Then perform the remediations for the watch rules # Perform the remediation for both possible tools: 'auditctl' and 'augenrules' fix_audit_watch_rule "auditctl" "/usr/sbin/insmod" "x" "modules" fix_audit_watch_rule "augenrules" "/usr/sbin/insmod" "x" "modules" fix_audit_watch_rule "auditctl" "/usr/sbin/rmmod" "x" "modules" fix_audit_watch_rule "augenrules" "/usr/sbin/rmmod" "x" "modules" fix_audit_watch_rule "auditctl" "/usr/sbin/modprobe" "x" "modules" fix_audit_watch_rule "augenrules" "/usr/sbin/modprobe" "x" "modules" scap-security-guide-0.1.31/RHEL/7/templates/static/bash/audit_rules_mac_modification.sh000066400000000000000000000005311301675746700310240ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions # Perform the remediation for both possible tools: 'auditctl' and 'augenrules' fix_audit_watch_rule "auditctl" "/etc/selinux/" "wa" "MAC-policy" fix_audit_watch_rule "augenrules" "/etc/selinux/" "wa" "MAC-policy" scap-security-guide-0.1.31/RHEL/7/templates/static/bash/audit_rules_media_export.sh000066400000000000000000000014221301675746700302170ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions # Perform the remediation of the syscall rule # Retrieve hardware architecture of the underlying system [ $(getconf LONG_BIT) = "32" ] && RULE_ARCHS=("b32") || RULE_ARCHS=("b32" "b64") for ARCH in "${RULE_ARCHS[@]}" do PATTERN="-a always,exit -F arch=$ARCH -S .* -F auid>=1000 -F auid!=4294967295 -k *" GROUP="mount" FULL_RULE="-a always,exit -F arch=$ARCH -S mount -F auid>=1000 -F auid!=4294967295 -k export" # Perform the remediation for both possible tools: 'auditctl' and 'augenrules' fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" fix_audit_syscall_rule "augenrules" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" done scap-security-guide-0.1.31/RHEL/7/templates/static/bash/audit_rules_networkconfig_modification.sh000066400000000000000000000033201301675746700331420ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions # First perform the remediation of the syscall rule # Retrieve hardware architecture of the underlying system [ $(getconf LONG_BIT) = "32" ] && RULE_ARCHS=("b32") || RULE_ARCHS=("b32" "b64") for ARCH in "${RULE_ARCHS[@]}" do PATTERN="-a always,exit -F arch=$ARCH -S .* -k *" # Use escaped BRE regex to specify rule group GROUP="set\(host\|domain\)name" FULL_RULE="-a always,exit -F arch=$ARCH -S sethostname -S setdomainname -k audit_rules_networkconfig_modification" # Perform the remediation for both possible tools: 'auditctl' and 'augenrules' fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" fix_audit_syscall_rule "augenrules" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" done # Then perform the remediations for the watch rules # Perform the remediation for both possible tools: 'auditctl' and 'augenrules' fix_audit_watch_rule "auditctl" "/etc/issue" "wa" "audit_rules_networkconfig_modification" fix_audit_watch_rule "augenrules" "/etc/issue" "wa" "audit_rules_networkconfig_modification" fix_audit_watch_rule "auditctl" "/etc/issue.net" "wa" "audit_rules_networkconfig_modification" fix_audit_watch_rule "augenrules" "/etc/issue.net" "wa" "audit_rules_networkconfig_modification" fix_audit_watch_rule "auditctl" "/etc/hosts" "wa" "audit_rules_networkconfig_modification" fix_audit_watch_rule "augenrules" "/etc/hosts" "wa" "audit_rules_networkconfig_modification" fix_audit_watch_rule "auditctl" "/etc/sysconfig/network" "wa" "audit_rules_networkconfig_modification" fix_audit_watch_rule "augenrules" "/etc/sysconfig/network" "wa" "audit_rules_networkconfig_modification" scap-security-guide-0.1.31/RHEL/7/templates/static/bash/audit_rules_privileged_commands.sh000066400000000000000000000005411301675746700315530ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions # Perform the remediation for both possible tools: 'auditctl' and 'augenrules' perform_audit_rules_privileged_commands_remediation "auditctl" "1000" perform_audit_rules_privileged_commands_remediation "augenrules" "1000" scap-security-guide-0.1.31/RHEL/7/templates/static/bash/audit_rules_session_events.sh000066400000000000000000000011551301675746700306110ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions # Perform the remediation # Perform the remediation for both possible tools: 'auditctl' and 'augenrules' fix_audit_watch_rule "auditctl" "/var/run/utmp" "wa" "session" fix_audit_watch_rule "augenrules" "/var/run/utmp" "wa" "session" fix_audit_watch_rule "auditctl" "/var/log/btmp" "wa" "session" fix_audit_watch_rule "augenrules" "/var/log/btmp" "wa" "session" fix_audit_watch_rule "auditctl" "/var/log/wtmp" "wa" "session" fix_audit_watch_rule "augenrules" "/var/log/wtmp" "wa" "session" scap-security-guide-0.1.31/RHEL/7/templates/static/bash/audit_rules_sysadmin_actions.sh000066400000000000000000000005211301675746700311050ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions # Perform the remediation for both possible tools: 'auditctl' and 'augenrules' fix_audit_watch_rule "auditctl" "/etc/sudoers" "wa" "actions" fix_audit_watch_rule "augenrules" "/etc/sudoers" "wa" "actions" scap-security-guide-0.1.31/RHEL/7/templates/static/bash/audit_rules_time_adjtimex.sh000066400000000000000000000003071301675746700303630ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions rhel7_fedora_perform_audit_adjtimex_settimeofday_stime_remediation scap-security-guide-0.1.31/RHEL/7/templates/static/bash/audit_rules_time_settimeofday.sh000066400000000000000000000003071301675746700312530ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions rhel7_fedora_perform_audit_adjtimex_settimeofday_stime_remediation scap-security-guide-0.1.31/RHEL/7/templates/static/bash/audit_rules_time_stime.sh000066400000000000000000000003071301675746700276770ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions rhel7_fedora_perform_audit_adjtimex_settimeofday_stime_remediation scap-security-guide-0.1.31/RHEL/7/templates/static/bash/audit_rules_time_watch_localtime.sh000066400000000000000000000005471301675746700317230ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions # Perform the remediation for both possible tools: 'auditctl' and 'augenrules' fix_audit_watch_rule "auditctl" "/etc/localtime" "wa" "audit_time_rules" fix_audit_watch_rule "augenrules" "/etc/localtime" "wa" "audit_time_rules" audit_rules_unsuccessful_file_modification.sh000066400000000000000000000031261301675746700337310ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/7/templates/static/bash# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions # Perform the remediation of the syscall rule # Retrieve hardware architecture of the underlying system [ $(getconf LONG_BIT) = "32" ] && RULE_ARCHS=("b32") || RULE_ARCHS=("b32" "b64") for ARCH in "${RULE_ARCHS[@]}" do # First fix the -EACCES requirement PATTERN="-a always,exit -F arch=$ARCH -S .* -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k *" # Use escaped BRE regex to specify rule group GROUP="\(creat\|open\|truncate\)" FULL_RULE="-a always,exit -F arch=$ARCH -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k access" # Perform the remediation for both possible tools: 'auditctl' and 'augenrules' fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" fix_audit_syscall_rule "augenrules" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" # Then fix the -EPERM requirement PATTERN="-a always,exit -F arch=$ARCH -S .* -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k *" # No need to change content of $GROUP variable - it's the same as for -EACCES case above FULL_RULE="-a always,exit -F arch=$ARCH -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k access" # Perform the remediation for both possible tools: 'auditctl' and 'augenrules' fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" fix_audit_syscall_rule "augenrules" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE" done scap-security-guide-0.1.31/RHEL/7/templates/static/bash/audit_rules_usergroup_modification.sh000066400000000000000000000021731301675746700323230ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions # Perform the remediation # Perform the remediation for both possible tools: 'auditctl' and 'augenrules' fix_audit_watch_rule "auditctl" "/etc/group" "wa" "audit_rules_usergroup_modification" fix_audit_watch_rule "augenrules" "/etc/group" "wa" "audit_rules_usergroup_modification" fix_audit_watch_rule "auditctl" "/etc/passwd" "wa" "audit_rules_usergroup_modification" fix_audit_watch_rule "augenrules" "/etc/passwd" "wa" "audit_rules_usergroup_modification" fix_audit_watch_rule "auditctl" "/etc/gshadow" "wa" "audit_rules_usergroup_modification" fix_audit_watch_rule "augenrules" "/etc/gshadow" "wa" "audit_rules_usergroup_modification" fix_audit_watch_rule "auditctl" "/etc/shadow" "wa" "audit_rules_usergroup_modification" fix_audit_watch_rule "augenrules" "/etc/shadow" "wa" "audit_rules_usergroup_modification" fix_audit_watch_rule "auditctl" "/etc/security/opasswd" "wa" "audit_rules_usergroup_modification" fix_audit_watch_rule "augenrules" "/etc/security/opasswd" "wa" "audit_rules_usergroup_modification" auditd_data_retention_admin_space_left_action.sh000066400000000000000000000007051301675746700343070ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/7/templates/static/bash# platform = Red Hat Enterprise Linux 7 . /usr/share/scap-security-guide/remediation_functions populate var_auditd_admin_space_left_action grep -q ^admin_space_left_action /etc/audit/auditd.conf && \ sed -i "s/admin_space_left_action.*/admin_space_left_action = $var_auditd_admin_space_left_action/g" /etc/audit/auditd.conf if ! [ $? -eq 0 ]; then echo "admin_space_left_action = $var_auditd_admin_space_left_action" >> /etc/audit/auditd.conf fi scap-security-guide-0.1.31/RHEL/7/templates/static/bash/auditd_data_retention_space_left_action.sh000066400000000000000000000006331301675746700332160ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 . /usr/share/scap-security-guide/remediation_functions populate var_auditd_space_left_action grep -q ^space_left_action /etc/audit/auditd.conf && \ sed -i "s/space_left_action.*/space_left_action = $var_auditd_space_left_action/g" /etc/audit/auditd.conf if ! [ $? -eq 0 ]; then echo "space_left_action = $var_auditd_space_left_action" >> /etc/audit/auditd.conf fi scap-security-guide-0.1.31/RHEL/7/templates/static/bash/banner_etc_issue.sh000066400000000000000000000006241301675746700264520ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 . /usr/share/scap-security-guide/remediation_functions populate login_banner_text # There was a regular-expression matching various banners, needs to be expanded expanded=$(echo "$login_banner_text" | sed 's/\[\\s\\n\][+*]/ /g;s/\\//g;s/[^-]- /\n\n-/g') formatted=$(echo "$expanded" | fold -sw 80) cat </etc/issue $formatted EOF printf "\n" >> /etc/issue scap-security-guide-0.1.31/RHEL/7/templates/static/bash/bootloader_audit_argument.sh000066400000000000000000000007521301675746700303660ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Correct the form of default kernel command line in /etc/default/grub grep -q ^GRUB_CMDLINE_LINUX=\".*audit=0.*\" /etc/default/grub && \ sed -i "s/audit=[^[:space:]\+]/audit=1/g" /etc/default/grub if ! [ $? -eq 0 ]; then sed -i "s/\(GRUB_CMDLINE_LINUX=\)\"\(.*\)\"/\1\"\2 audit=1\"/" /etc/default/grub fi # Correct the form of kernel command line for each installed kernel # in the bootloader /sbin/grubby --update-kernel=ALL --args="audit=1" scap-security-guide-0.1.31/RHEL/7/templates/static/bash/chronyd_or_ntpd_specify_multiple_servers.sh000066400000000000000000000015061301675746700335430ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 . /usr/share/scap-security-guide/remediation_functions populate var_multiple_time_servers if ! `/usr/sbin/pidof ntpd`; then if [ `grep -c '^server' /etc/chrony.conf` -lt 2 ]; then if ! `grep -q '#[[:space:]]*server' /etc/chrony.conf` ; then for i in `echo "$var_multiple_time_servers" | tr ',' '\n'` ; do echo -ne "\nserver $i iburst" >> /etc/chrony.conf done else sed -i 's/#[ ]*server/server/g' /etc/chrony.conf fi fi else if [ `grep -c '^server' /etc/ntp.conf` -lt 2 ]; then if ! `grep -q '#[[:space:]]*server' /etc/ntp.conf` ; then for i in `echo "$var_multiple_time_servers" | tr ',' '\n'` ; do echo -ne "\nserver $i iburst" >> /etc/ntp.conf done else sed -i 's/#[ ]*server/server/g' /etc/ntp.conf fi fi fi scap-security-guide-0.1.31/RHEL/7/templates/static/bash/chronyd_or_ntpd_specify_remote_server.sh000066400000000000000000000014631301675746700330220ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 . /usr/share/scap-security-guide/remediation_functions populate var_multiple_time_servers if ! `/usr/sbin/pidof ntpd`; then if ! `grep -q ^server /etc/chrony.conf` ; then if ! `grep -q '#[[:space:]]*server' /etc/chrony.conf` ; then for i in `echo "$var_multiple_time_servers" | tr ',' '\n'` ; do echo -ne "\nserver $i iburst" >> /etc/chrony.conf done else sed -i 's/#[ ]*server/server/g' /etc/chrony.conf fi fi else if ! `grep -q ^server /etc/ntp.conf` ; then if ! `grep -q '#[[:space:]]*server' /etc/ntp.conf` ; then for i in `echo "$var_multiple_time_servers" | tr ',' '\n'` ; do echo -ne "\nserver $i iburst" >> /etc/ntp.conf done else sed -i 's/#[ ]*server/server/g' /etc/ntp.conf fi fi fi scap-security-guide-0.1.31/RHEL/7/templates/static/bash/clean_components_post_updating.sh000066400000000000000000000005751301675746700314360ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 if grep --silent ^clean_requirements_on_remove /etc/yum.conf ; then sed -i "s/^clean_requirements_on_remove.*/clean_requirements_on_remove=1/g" /etc/yum.conf else echo -e "\n# Set clean_requirements_on_remove to 1 per security requirements" >> /etc/yum.conf echo "clean_requirements_on_remove=1" >> /etc/yum.conf fi dconf_gnome_screensaver_idle_activation_enabled.sh000066400000000000000000000027571301675746700346420ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/7/templates/static/bash# platform = Red Hat Enterprise Linux 7 # Define constants to be reused below ORG_GNOME_DESKTOP_SCREENSAVER="org/gnome/desktop/screensaver" SSG_DCONF_IDLE_ACTIVATION_FILE="/etc/dconf/db/local.d/10-scap-security-guide" SCREENSAVER_LOCKS_FILE="/etc/dconf/db/local.d/locks/screensaver" IDLE_ACTIVATION_DEFINED="FALSE" # First update '[org/gnome/desktop/screensaver] idle-activation-enabled' settings in # /etc/dconf/db/local.d/* if already defined for FILE in /etc/dconf/db/local.d/* do if grep -q -d skip "$ORG_GNOME_DESKTOP_SCREENSAVER" "$FILE" then if grep 'idle-activation-enabled' "$FILE" then sed -i "s/idle-activation-enabled=.*/idle-activation-enabled=true/g" "$FILE" IDLE_ACTIVATION_DEFINED="TRUE" fi fi done # Then define '[org/gnome/desktop/screensaver] idle-activation-enabled' setting # if still not defined yet if [ "$IDLE_ACTIVATION_DEFINED" != "TRUE" ] then echo "" >> $SSG_DCONF_IDLE_ACTIVATION_FILE echo "[org/gnome/desktop/screensaver]" >> $SSG_DCONF_IDLE_ACTIVATION_FILE echo "idle-activation-enabled=true" >> $SSG_DCONF_IDLE_ACTIVATION_FILE fi # Verify if 'idle-activation-enabled' modification is locked. If not, lock it if ! grep -q "^/${ORG_GNOME_DESKTOP_SCREENSAVER}/idle-activation-enabled$" /etc/dconf/db/local.d/locks/* then # Check if "$SCREENSAVER_LOCK_FILE" exists. If not, create it. if [ ! -f "$SCREENSAVER_LOCKS_FILE" ] then touch "$SCREENSAVER_LOCKS_FILE" fi echo "/${ORG_GNOME_DESKTOP_SCREENSAVER}/idle-activation-enabled" >> "$SCREENSAVER_LOCKS_FILE" fi scap-security-guide-0.1.31/RHEL/7/templates/static/bash/dconf_gnome_screensaver_idle_delay.sh000066400000000000000000000026641301675746700322010ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 . /usr/share/scap-security-guide/remediation_functions populate inactivity_timeout_value # Define constants to be reused below ORG_GNOME_DESKTOP_SESSION="org/gnome/desktop/session" SSG_DCONF_IDLE_DELAY_FILE="/etc/dconf/db/local.d/10-scap-security-guide" SESSION_LOCKS_FILE="/etc/dconf/db/local.d/locks/session" IDLE_DELAY_DEFINED="FALSE" # First update '[org/gnome/desktop/session] idle-delay' settings in # /etc/dconf/db/local.d/* if already defined for FILE in /etc/dconf/db/local.d/* do if grep -q -d skip "$ORG_GNOME_DESKTOP_SESSION" "$FILE" then if grep 'idle-delay' "$FILE" then sed -i "s/idle-delay=.*/idle-delay=uint32 ${inactivity_timeout_value}/g" "$FILE" IDLE_DELAY_DEFINED="TRUE" fi fi done # Then define '[org/gnome/desktop/session] idle-delay' setting # if still not defined yet if [ "$IDLE_DELAY_DEFINED" != "TRUE" ] then echo "" >> $SSG_DCONF_IDLE_DELAY_FILE echo "[org/gnome/desktop/session]" >> $SSG_DCONF_IDLE_DELAY_FILE echo "idle-delay=uint32 ${inactivity_timeout_value}" >> $SSG_DCONF_IDLE_DELAY_FILE fi # Verify if 'idle-delay' modification is locked. If not, lock it if ! grep -q "^/${ORG_GNOME_DESKTOP_SESSION}/idle-delay$" /etc/dconf/db/local.d/locks/* then # Check if "$SESSION_LOCK_FILE" exists. If not, create it. if [ ! -f "$SESSION_LOCKS_FILE" ] then touch "$SESSION_LOCKS_FILE" fi echo "/${ORG_GNOME_DESKTOP_SESSION}/idle-delay" >> "$SESSION_LOCKS_FILE" fi scap-security-guide-0.1.31/RHEL/7/templates/static/bash/dconf_gnome_screensaver_lock_enabled.sh000066400000000000000000000041461301675746700325050ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Define constants to be reused below ORG_GNOME_DESKTOP_SCREENSAVER="org/gnome/desktop/screensaver" SSG_DCONF_LOCK_ENABLED_FILE="/etc/dconf/db/local.d/10-scap-security-guide" SCREENSAVER_LOCKS_FILE="/etc/dconf/db/local.d/locks/screensaver" LOCK_ENABLED_DEFINED="FALSE" LOCK_DELAY_DEFINED="FALSE" # First update '[org/gnome/desktop/screensaver] lock-enabled' and # '[org/gnome/desktop/screensaver] lock-delay' settings in # /etc/dconf/db/local.d/* if already defined for FILE in /etc/dconf/db/local.d/* do if grep -q -d skip "$ORG_GNOME_DESKTOP_SCREENSAVER" "$FILE" then if grep 'lock-enabled' "$FILE" then sed -i "s/lock-enabled=.*/lock-enabled=true/g" "$FILE" LOCK_ENABLED_DEFINED="TRUE" fi if grep 'lock-delay' "$FILE" then sed -i "s/lock-delay=.*/lock-delay=uint32 0/g" "$FILE" LOCK_DELAY_DEFINED="TRUE" fi fi done # Then define '[org/gnome/desktop/screensaver] lock-enabled' setting # if still not defined yet if [ "$LOCK_ENABLED_DEFINED" != "TRUE" ] || [ "$LOCK_DELAY_DEFINED" != "TRUE" ] then echo "" >> $SSG_DCONF_LOCK_ENABLED_FILE echo "[org/gnome/desktop/screensaver]" >> $SSG_DCONF_LOCK_ENABLED_FILE echo "lock-enabled=true" >> $SSG_DCONF_LOCK_ENABLED_FILE echo "lock-delay=uint32 0" >> $SSG_DCONF_LOCK_ENABLED_FILE fi # Verify if 'lock-enabled' modification is locked. If not, lock it if ! grep -q "^/${ORG_GNOME_DESKTOP_SCREENSAVER}/lock-enabled$" /etc/dconf/db/local.d/locks/* then # Check if "$SCREENSAVER_LOCK_FILE" exists. If not, create it. if [ ! -f "$SCREENSAVER_LOCKS_FILE" ] then touch "$SCREENSAVER_LOCKS_FILE" fi echo "/${ORG_GNOME_DESKTOP_SCREENSAVER}/lock-enabled" >> "$SCREENSAVER_LOCKS_FILE" fi # Verify if 'lock-delay' modification is locked. If not, lock it if ! grep -q "^/${ORG_GNOME_DESKTOP_SCREENSAVER}/lock-delay$" /etc/dconf/db/local.d/locks/* then # Check if "$SCREENSAVER_LOCK_FILE" exists. If not, create it. if [ ! -f "$SCREENSAVER_LOCKS_FILE" ] then touch "$SCREENSAVER_LOCKS_FILE" fi echo "/${ORG_GNOME_DESKTOP_SCREENSAVER}/lock-delay" >> "$SCREENSAVER_LOCKS_FILE" fi scap-security-guide-0.1.31/RHEL/7/templates/static/bash/dconf_gnome_screensaver_mode_blank.sh000066400000000000000000000025511301675746700321740ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Define constants to be reused below ORG_GNOME_DESKTOP_SCREENSAVER="org/gnome/desktop/screensaver" SSG_DCONF_MODE_BLANK_FILE="/etc/dconf/db/local.d/10-scap-security-guide" SCREENSAVER_LOCKS_FILE="/etc/dconf/db/local.d/locks/screensaver" MODE_BLANK_DEFINED="FALSE" # First update '[org/gnome/desktop/screensaver] picture-uri' settings in # /etc/dconf/db/local.d/* if already defined for FILE in /etc/dconf/db/local.d/* do if grep -q -d skip "$ORG_GNOME_DESKTOP_SCREENSAVER" "$FILE" then if grep 'picture-uri' "$FILE" then sed -i "s/picture-uri=.*/picture-uri=string ''/g" "$FILE" MODE_BLANK_DEFINED="TRUE" fi fi done # Then define '[org/gnome/desktop/screensaver] picture-uri' setting # if still not defined yet if [ "$MODE_BLANK_DEFINED" != "TRUE" ] then echo "" >> $SSG_DCONF_MODE_BLANK_FILE echo "[org/gnome/desktop/screensaver]" >> $SSG_DCONF_MODE_BLANK_FILE echo "picture-uri=string ''" >> $SSG_DCONF_MODE_BLANK_FILE fi # Verify if 'picture-uri' modification is locked. If not, lock it if ! grep -q "^/${ORG_GNOME_DESKTOP_SCREENSAVER}/picture-uri$" /etc/dconf/db/local.d/locks/* then # Check if "$SCREENSAVER_LOCK_FILE" exists. If not, create it. if [ ! -f "$SCREENSAVER_LOCKS_FILE" ] then touch "$SCREENSAVER_LOCKS_FILE" fi echo "/${ORG_GNOME_DESKTOP_SCREENSAVER}/picture-uri" >> "$SCREENSAVER_LOCKS_FILE" fi scap-security-guide-0.1.31/RHEL/7/templates/static/bash/disable_ctrlaltdel_reboot.sh000066400000000000000000000003271301675746700303310ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # The process to disable ctrl+alt+del has changed in RHEL7. # Reference: https://access.redhat.com/solutions/1123873 ln -sf /dev/null /etc/systemd/system/ctrl-alt-del.target scap-security-guide-0.1.31/RHEL/7/templates/static/bash/disable_prelink.sh000066400000000000000000000006261301675746700262730ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # # Disable prelinking altogether # if grep -q ^PRELINKING /etc/sysconfig/prelink then sed -i 's/PRELINKING.*/PRELINKING=no/g' /etc/sysconfig/prelink else echo -e "\n# Set PRELINKING=no per security requirements" >> /etc/sysconfig/prelink echo "PRELINKING=no" >> /etc/sysconfig/prelink fi # # Undo previous prelink changes to binaries # /usr/sbin/prelink -ua scap-security-guide-0.1.31/RHEL/7/templates/static/bash/disable_users_coredumps.sh000066400000000000000000000001431301675746700300430ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 echo "* hard core 0" >> /etc/security/limits.conf scap-security-guide-0.1.31/RHEL/7/templates/static/bash/ensure_gpgcheck_local_packages.sh000066400000000000000000000005061301675746700313050ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 if grep --silent ^localpkg_gpgcheck /etc/yum.conf ; then sed -i "s/^localpkg_gpgcheck.*/localpkg_gpgcheck=1/g" /etc/yum.conf else echo -e "\n# Set localpkg_gpgcheck to 1 per security requirements" >> /etc/yum.conf echo "localpkg_gpgcheck=1" >> /etc/yum.conf fi scap-security-guide-0.1.31/RHEL/7/templates/static/bash/ensure_gpgcheck_repo_metadata.sh000066400000000000000000000004621301675746700311630ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 if grep --silent ^repo_gpgcheck /etc/yum.conf ; then sed -i "s/^repo_gpgcheck.*/repo_gpgcheck=1/g" /etc/yum.conf else echo -e "\n# Set repo_gpgcheck to 1 per security requirements" >> /etc/yum.conf echo "repo_gpgcheck=1" >> /etc/yum.conf fi scap-security-guide-0.1.31/RHEL/7/templates/static/bash/file_group_owner_grub2_cfg.sh000066400000000000000000000001101301675746700304150ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 chgrp root /boot/grub2/grub.cfg scap-security-guide-0.1.31/RHEL/7/templates/static/bash/file_ownership_library_dirs.sh000066400000000000000000000002701301675746700307210ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 for LIBDIR in /usr/lib /usr/lib64 /lib /lib64 do if [ -d $LIBDIR ] then find -L $LIBDIR \! -user root -exec chown root {} \; fi done scap-security-guide-0.1.31/RHEL/7/templates/static/bash/file_permissions_grub2_cfg.sh000066400000000000000000000001071301675746700304300ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 chmod 600 /boot/grub2/grub.cfg scap-security-guide-0.1.31/RHEL/7/templates/static/bash/file_permissions_library_dirs.sh000066400000000000000000000002521301675746700312560ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 DIRS="/lib /lib64 /usr/lib /usr/lib64" for dirPath in $DIRS; do find "$dirPath" -perm /022 -type f -exec chmod go-w '{}' \; done scap-security-guide-0.1.31/RHEL/7/templates/static/bash/file_user_owner_grub2_cfg.sh000066400000000000000000000001101301675746700302370ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 chown root /boot/grub2/grub.cfg scap-security-guide-0.1.31/RHEL/7/templates/static/bash/groupowner_shadow_file.sh000066400000000000000000000000771301675746700277170ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 chgrp root /etc/shadow scap-security-guide-0.1.31/RHEL/7/templates/static/bash/grub2_enable_fips_mode.sh000066400000000000000000000010661301675746700275170ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 if grep --silent ^PRELINKING /etc/sysconfig/prelink ; then sed -i "s/^PRELINKING.*/PRELINKING=yes/g" /etc/sysconfig/prelink else echo -e "\n# Set PRELINKING to 'yes' per security requirements" >> /etc/sysconfig/prelink echo "PRELINKING=yes" >> /etc/sysconfig/prelink fi prelink -u -a dracut -f if [ -e /sys/firmware/efi ]; then BOOT=`df /boot/efi | tail -1 | awk '{print $1 }'` else BOOT=`df /boot | tail -1 | awk '{ print $1 }'` fi /sbin/grubby --update-kernel=ALL --args="boot=${BOOT} fips=1" scap-security-guide-0.1.31/RHEL/7/templates/static/bash/mount_option_tmp_nodev.sh000066400000000000000000000005771301675746700277560ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 NEW_OPT=nodev if [ $(grep " \/tmp " /etc/fstab | grep -c "$NEW_OPT" ) -eq 0 ]; then MNT_OPTS=$(grep " \/tmp " /etc/fstab | awk '{print $4}') sed -i "s/\( \/tmp.*${MNT_OPTS}\)/\1,${NEW_OPT}/" /etc/fstab if [ $MNT_OPTS = "defaults" ] then sed -i "s/defaults,//" /etc/fstab fi fi scap-security-guide-0.1.31/RHEL/7/templates/static/bash/mount_option_tmp_noexec.sh000066400000000000000000000006001301675746700301070ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 NEW_OPT=noexec if [ $(grep " \/tmp " /etc/fstab | grep -c "$NEW_OPT" ) -eq 0 ]; then MNT_OPTS=$(grep " \/tmp " /etc/fstab | awk '{print $4}') sed -i "s/\( \/tmp.*${MNT_OPTS}\)/\1,${NEW_OPT}/" /etc/fstab if [ $MNT_OPTS = "defaults" ] then sed -i "s/defaults,//" /etc/fstab fi fi scap-security-guide-0.1.31/RHEL/7/templates/static/bash/mount_option_tmp_nosuid.sh000066400000000000000000000005731301675746700301400ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 NEW_OPT="nosuid" if [ $(grep " \/tmp " /etc/fstab | grep -c "$NEW_OPT" ) -eq 0 ]; then MNT_OPTS=$(grep " \/tmp " /etc/fstab | awk '{print $4}') sed -i "s/\( \/tmp.*${MNT_OPTS}\)/\1,${NEW_OPT}/" /etc/fstab if [ $MNT_OPTS = "defaults" ] then sed -i "s/defaults,//" /etc/fstab fi fi scap-security-guide-0.1.31/RHEL/7/templates/static/bash/network_disable_zeroconf.sh000066400000000000000000000001301301675746700302130ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 echo "NOZEROCONF=yes" >> /etc/sysconfig/network scap-security-guide-0.1.31/RHEL/7/templates/static/bash/service_avahi-daemon_disabled.sh000066400000000000000000000005351301675746700310430ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # # Disable avahi-daemon.service for all systemd targets # systemctl disable avahi-daemon.service # # Stop avahi-daemon.service if currently running # and disable avahi-daemon.socket so the avahi-daemon.service # can't be activated # systemctl stop avahi-daemon.service systemctl disable avahi-daemon.socket scap-security-guide-0.1.31/RHEL/7/templates/static/bash/service_bluetooth_disabled.sh000066400000000000000000000005051301675746700305140ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 grep -qi disable /etc/xinetd.d/bluetooth && \ sed -i 's/disable.*/disable = yes/gI' /etc/xinetd.d/bluetooth # # Disable bluetooth.service for all systemd targets # systemctl disable bluetooth.service # # Stop bluetooth.service if currently running # systemctl stop bluetooth.service scap-security-guide-0.1.31/RHEL/7/templates/static/bash/service_chronyd_or_ntpd_enabled.sh000066400000000000000000000005721301675746700315310ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 . /usr/share/scap-security-guide/remediation_functions if ! `rpm -q --quiet chrony` && ! `rpm -q --quiet ntp-`; then package_command install chrony service_command enable chronyd elif `rpm -q --quiet chrony`; then if ! [ `/usr/sbin/pidof ntpd` ] ; then service_command enable chronyd fi else service_command enable ntpd fi scap-security-guide-0.1.31/RHEL/7/templates/static/bash/service_cups_disabled.sh000066400000000000000000000005131301675746700274600ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # # Disable cups.service for all systemd targets # systemctl disable cups.service # # Stop cups.service if currently running # and disable cups.path and cups.socket so # cups.service can't be activated # systemctl stop cups.service systemctl disable cups.path systemctl disable cups.socket scap-security-guide-0.1.31/RHEL/7/templates/static/bash/service_nfslock_disabled.sh000066400000000000000000000003241301675746700301450ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # # Disable nfs-lock.service for all systemd targets # systemctl disable nfs-lock.service # # Stop nfs-lock.service if currently running # systemctl stop nfs-lock.service scap-security-guide-0.1.31/RHEL/7/templates/static/bash/service_rexec_disabled.sh000066400000000000000000000004631301675746700276200ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 grep -qi disable /etc/xinetd.d/rexec && \ sed -i "s/disable.*/disable = yes/gI" /etc/xinetd.d/rexec # # Disable rexec.socket for all systemd targets # systemctl disable rexec.socket # # Stop rexec.socket if currently running # systemctl stop rexec.socket scap-security-guide-0.1.31/RHEL/7/templates/static/bash/service_rlogin_disabled.sh000066400000000000000000000004711301675746700300030ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 grep -qi disable /etc/xinetd.d/rlogin && \ sed -i "s/disable.*/disable = yes/gI" /etc/xinetd.d/rlogin # # Disable rlogin.socket for all systemd targets # systemctl disable rlogin.socket # # Stop rlogin.socket if currently running # systemctl stop rlogin.socket scap-security-guide-0.1.31/RHEL/7/templates/static/bash/service_rpcgssd_disabled.sh000066400000000000000000000003601301675746700301530ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # # Disable nfs-secure.service (rpcgssd) for all systemd targets # systemctl disable nfs-secure.service # # Stop nfs-secure.service (rpcgssd) if currently running # systemctl stop nfs-secure.service scap-security-guide-0.1.31/RHEL/7/templates/static/bash/service_rpcidmapd_disabled.sh000066400000000000000000000003601301675746700304510ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # # Disable nfs-idmap.service (rpcidmapd) for all systemd targets # systemctl disable nfs-idmap.service # # Stop nfs-idmap.service (rpcidmapd) if currently running # systemctl stop nfs-idmap.service scap-security-guide-0.1.31/RHEL/7/templates/static/bash/service_rpcsvcgssd_disabled.sh000066400000000000000000000004221301675746700306660ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # # Disable nfs-secure-server.service (rpcsvcgssd) for all systemd targets # systemctl disable nfs-secure-server.service # # Stop nfs-secure-server.service (rpcsvcgssd) if currently running # systemctl stop nfs-secure-server.service scap-security-guide-0.1.31/RHEL/7/templates/static/bash/service_rsh_disabled.sh000066400000000000000000000004471301675746700273100ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 grep -qi disable /etc/xinetd.d/rsh && \ sed -i "s/disable.*/disable = yes/gI" /etc/xinetd.d/rsh # # Disable rsh.socket for all systemd targets # systemctl disable rsh.socket # # Stop rsh.socket if currently running # systemctl stop rsh.socket scap-security-guide-0.1.31/RHEL/7/templates/static/bash/service_telnet_disabled.sh000066400000000000000000000004711301675746700300040ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 grep -qi disable /etc/xinetd.d/telnet && \ sed -i "s/disable.*/disable = yes/gI" /etc/xinetd.d/telnet # # Disable telnet.socket for all systemd targets # systemctl disable telnet.socket # # Stop telnet.socket if currently running # systemctl stop telnet.socket scap-security-guide-0.1.31/RHEL/7/templates/static/bash/smartcard_auth.sh000066400000000000000000000071751301675746700261530ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 . /usr/share/scap-security-guide/remediation_functions # Install required packages package_command install esc package_command install pam_pkcs11 # Enable pcscd.socket systemd activation socket service_command enable pcscd.socket # Configure the expected /etc/pam.d/system-auth{,-ac} settings directly # # The code below will configure system authentication in the way smart card # logins will be enabled, but also user login(s) via other method to be allowed # # NOTE: It is not possible to use the 'authconfig' command to perform the # remediation for us, because call of 'authconfig' would discard changes # for other remediations (see RH BZ#1357019 for details) # # Therefore we need to configure the necessary settings directly. # # Define system-auth config location SYSTEM_AUTH_CONF="/etc/pam.d/system-auth" # Define expected 'pam_env.so' row in $SYSTEM_AUTH_CONF PAM_ENV_SO="auth.*required.*pam_env.so" # Define 'pam_succeed_if.so' row to be appended past $PAM_ENV_SO row into $SYSTEM_AUTH_CONF SYSTEM_AUTH_PAM_SUCCEED="\ auth \[success=1 default=ignore\] pam_succeed_if.so service notin \ login:gdm:xdm:kdm:xscreensaver:gnome-screensaver:kscreensaver quiet use_uid" # Define 'pam_pkcs11.so' row to be appended past $SYSTEM_AUTH_PAM_SUCCEED # row into SYSTEM_AUTH_CONF file SYSTEM_AUTH_PAM_PKCS11="\ auth \[success=done authinfo_unavail=ignore ignore=ignore default=die\] \ pam_pkcs11.so nodebug" # Define smartcard-auth config location SMARTCARD_AUTH_CONF="/etc/pam.d/smartcard-auth" # Define 'pam_pkcs11.so' auth section to be appended past $PAM_ENV_SO into $SMARTCARD_AUTH_CONF SMARTCARD_AUTH_SECTION="\ auth [success=done ignore=ignore default=die] pam_pkcs11.so wait_for_card card_only" # Define expected 'pam_permit.so' row in $SMARTCARD_AUTH_CONF PAM_PERMIT_SO="account.*required.*pam_permit.so" # Define 'pam_pkcs11.so' password section SMARTCARD_PASSWORD_SECTION="\ password required pam_pkcs11.so" # First Correct the SYSTEM_AUTH_CONF configuration if ! grep -q 'pam_pkcs11.so' "$SYSTEM_AUTH_CONF" then # Append (expected) pam_succeed_if.so row past the pam_env.so into SYSTEM_AUTH_CONF file sed -i --follow-symlinks -e '/^'"$PAM_ENV_SO"'/a '"$SYSTEM_AUTH_PAM_SUCCEED" "$SYSTEM_AUTH_CONF" # Append (expected) pam_pkcs11.so row past the pam_succeed_if.so into SYSTEM_AUTH_CONF file sed -i --follow-symlinks -e '/^'"$SYSTEM_AUTH_PAM_SUCCEED"'/a '"$SYSTEM_AUTH_PAM_PKCS11" "$SYSTEM_AUTH_CONF" fi # Then also correct the SMARTCARD_AUTH_CONF if ! grep -q 'pam_pkcs11.so' "$SMARTCARD_AUTH_CONF" then # Append (expected) SMARTCARD_AUTH_SECTION row past the pam_env.so into SMARTCARD_AUTH_CONF file sed -i --follow-symlinks -e '/^'"$PAM_ENV_SO"'/a '"$SMARTCARD_AUTH_SECTION" "$SMARTCARD_AUTH_CONF" # Append (expected) SMARTCARD_PASSWORD_SECTION row past the pam_permit.so into SMARTCARD_AUTH_CONF file sed -i --follow-symlinks -e '/^'"$PAM_PERMIT_SO"'/a '"$SMARTCARD_PASSWORD_SECTION" "$SMARTCARD_AUTH_CONF" fi # Perform /etc/pam_pkcs11/pam_pkcs11.conf settings below # Define selected constants for later reuse SP="[:space:]" PAM_PKCS11_CONF="/etc/pam_pkcs11/pam_pkcs11.conf" # Ensure OCSP is turned on in $PAM_PKCS11_CONF # 1) First replace any occurrence of 'none' value of 'cert_policy' key setting with the correct configuration sed -i "s/^[$SP]*cert_policy[$SP]\+=[$SP]\+none;/\t\tcert_policy = ca, ocsp_on, signature;/g" "$PAM_PKCS11_CONF" # 2) Then append 'ocsp_on' value setting to each 'cert_policy' key in $PAM_PKCS11_CONF configuration line, # which does not contain it yet sed -i "/ocsp_on/! s/^[$SP]*cert_policy[$SP]\+=[$SP]\+\(.*\);/\t\tcert_policy = \1, ocsp_on;/" "$PAM_PKCS11_CONF" scap-security-guide-0.1.31/RHEL/7/templates/static/bash/sshd_disable_empty_passwords.sh000066400000000000000000000003341301675746700311070ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions replace_or_append '/etc/ssh/sshd_config' '^PermitEmptyPasswords' 'no' '$CCENUM' '%s %s' scap-security-guide-0.1.31/RHEL/7/templates/static/bash/sshd_do_not_permit_user_env.sh000066400000000000000000000003351301675746700307320ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions replace_or_append '/etc/ssh/sshd_config' '^PermitUserEnvironment' 'no' '$CCENUM' '%s %s' scap-security-guide-0.1.31/RHEL/7/templates/static/bash/sshd_enable_warning_banner.sh000066400000000000000000000003261301675746700304620ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions replace_or_append '/etc/ssh/sshd_config' '^Banner' '/etc/issue' '$CCENUM' '%s %s' scap-security-guide-0.1.31/RHEL/7/templates/static/bash/sshd_set_idle_timeout.sh000066400000000000000000000003541301675746700275210ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 . /usr/share/scap-security-guide/remediation_functions populate sshd_idle_timeout_value replace_or_append '/etc/ssh/sshd_config' '^ClientAliveInterval' $sshd_idle_timeout_value '$CCENUM' '%s %s' scap-security-guide-0.1.31/RHEL/7/templates/static/bash/sshd_set_keepalive.sh000066400000000000000000000003321301675746700267770ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions replace_or_append '/etc/ssh/sshd_config' '^ClientAliveCountMax' '0' '$CCENUM' '%s %s' scap-security-guide-0.1.31/RHEL/7/templates/static/bash/sshd_use_approved_ciphers.sh000066400000000000000000000004271301675746700303750ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # Include source function library. . /usr/share/scap-security-guide/remediation_functions replace_or_append '/etc/ssh/sshd_config' '^Ciphers' 'aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc' '$CCENUM' '%s %s' scap-security-guide-0.1.31/RHEL/7/templates/static/bash/sysctl_kernel_exec_shield.sh000066400000000000000000000016001301675746700303520ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 if [ $(getconf LONG_BIT) = "32" ] ; then # # Set runtime for kernel.exec-shield # sysctl -q -n -w kernel.exec-shield=1 # # If kernel.exec-shield present in /etc/sysctl.conf, change value to "1" # else, add "kernel.exec-shield = 1" to /etc/sysctl.conf # if grep --silent ^kernel.exec-shield /etc/sysctl.conf ; then sed -i 's/^kernel.exec-shield.*/kernel.exec-shield = 1/g' /etc/sysctl.conf else echo -e "\n# Set kernel.exec-shield to 1 per security requirements" >> /etc/sysctl.conf echo "kernel.exec-shield = 1" >> /etc/sysctl.d/sysctl.conf fi fi if [ $(getconf LONG_BIT) = "64" ] ; then if grep --silent noexec /boot/grub2/grub*.cfg ; then sed -i "s/noexec.*//g" /etc/default/grub sed -i "s/noexec.*//g" /etc/grub.d/* GRUBCFG=`ls | grep '.cfg$'` grub2-mkconfig -o /boot/grub2/$GRUBCFG fi fi scap-security-guide-0.1.31/RHEL/7/templates/static/bash/sysctl_kernel_randomize_va_space.sh000066400000000000000000000004601301675746700317320ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # # Set runtime for kernel.randomize_va_space # sysctl -q -n -w kernel.randomize_va_space=2 # Include source function library. . /usr/share/scap-security-guide/remediation_functions replace_or_append '/etc/sysctl.conf' '^kernel.randomize_va_space' '2' '$CCENUM' sysctl_net_ipv6_conf_all_accept_source_route.sh000066400000000000000000000012071301675746700341660ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/7/templates/static/bash# platform = Red Hat Enterprise Linux 7 # # Set runtime for SYSCTLVAR # /sbin/sysctl -q -n -w net.ipv6.conf.all.accept_source_route=0 # # If SYSCTLVAR present in /etc/sysctl.conf, change value to "SYSCTLVAL" # else, add "SYSCTLVAR = SYSCTLVAL" to /etc/sysctl.conf # if grep --silent ^net.ipv6.conf.all.accept_source_route /etc/sysctl.conf ; then sed -i 's/^net.ipv6.conf.all.accept_source_route.*/net.ipv6.conf.all.accept_source_route = 0/g' /etc/sysctl.conf else echo -e "\n# Set net.ipv6.conf.all.accept_source_route to 0 per security requirements" >> /etc/sysctl.conf echo "net.ipv6.conf.all.accept_source_route = 0" >> /etc/sysctl.conf fi scap-security-guide-0.1.31/RHEL/7/templates/static/bash/umask_for_daemons.sh000066400000000000000000000005171301675746700266370ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 . /usr/share/scap-security-guide/remediation_functions populate var_umask_for_daemons grep -q ^umask /etc/init.d/functions && \ sed -i "s/umask.*/umask $var_umask_for_daemons/g" /etc/init.d/functions if ! [ $? -eq 0 ]; then echo "umask $var_umask_for_daemons" >> /etc/init.d/functions fi scap-security-guide-0.1.31/RHEL/7/templates/static/bash/userowner_shadow_file.sh000066400000000000000000000000771301675746700275410ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 chown root /etc/shadow scap-security-guide-0.1.31/RHEL/7/templates/template_BASH_kernel_module_disabled000066400000000000000000000002741301675746700274720ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # reboot = true # strategy = disable # complexity = low # disruption = medium echo "install KERNMODULE /bin/true" > /etc/modprobe.d/KERNMODULE.conf scap-security-guide-0.1.31/RHEL/7/templates/template_BASH_service_disabled000066400000000000000000000003631301675746700263040ustar00rootroot00000000000000# platform = Red Hat Enterprise Linux 7 # reboot = false # strategy = disable # complexity = low # disruption = low # Include source function library. . /usr/share/scap-security-guide/remediation_functions service_command disable SERVICENAME scap-security-guide-0.1.31/RHEL/7/transforms/000077500000000000000000000000001301675746700206005ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/7/transforms/cce_extract.py000077500000000000000000000003551301675746700234440ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import cce_extract_module if __name__ == "__main__": cce_extract_module.main() scap-security-guide-0.1.31/RHEL/7/transforms/cci2html.xsl000066400000000000000000000004711301675746700230370ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/7/transforms/constants.xslt000066400000000000000000000025471301675746700235400ustar00rootroot00000000000000 Red Hat Enterprise Linux 7 RHEL 7 RHEL_7_STIG RHEL-7 cpe:/o:redhat:enterprise_linux:7,cpe:/o:redhat:enterprise_linux:7::client,cpe:/o:redhat:enterprise_linux:7::computenode rhel7 https://benchmarks.cisecurity.org/tools2/linux/CIS_Red_Hat_Enterprise_Linux_7_Benchmark_v1.1.0.pdf RHEL-07- scap-security-guide-0.1.31/RHEL/7/transforms/shorthand2xccdf.xslt000066400000000000000000000005151301675746700246010ustar00rootroot00000000000000 unknown unlinked-rhel7-oval.xml scap-security-guide-0.1.31/RHEL/7/transforms/splitchecks.py000077500000000000000000000003551301675746700234740ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import splitchecks_module if __name__ == "__main__": splitchecks_module.main() scap-security-guide-0.1.31/RHEL/7/transforms/table-add-srgitems.xslt000066400000000000000000000011011301675746700251550ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/7/transforms/table-sortbyref.xslt000066400000000000000000000005601301675746700246210ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/7/transforms/table-srgmap.xslt000066400000000000000000000011431301675746700240710ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/7/transforms/table-style.xslt000066400000000000000000000002541301675746700237420ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/7/transforms/xccdf-alt-titles.xslt000066400000000000000000000005051301675746700246630ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/7/transforms/xccdf-apply-overlay-stig.xslt000066400000000000000000000007541301675746700263570ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/7/transforms/xccdf-removeaux.xslt000066400000000000000000000005041301675746700246130ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/7/transforms/xccdf2csv-stig.py000077500000000000000000000003631301675746700240100ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import xccdf2csv_stig_module if __name__ == "__main__": xccdf2csv_stig_module.main() scap-security-guide-0.1.31/RHEL/7/transforms/xccdf2html.xslt000066400000000000000000000005531301675746700235550ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/7/transforms/xccdf2shorthand.xslt000066400000000000000000000005041301675746700245770ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/7/transforms/xccdf2stigformat.xslt000066400000000000000000000007001301675746700247620ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/7/transforms/xccdf2table-byref.xslt000066400000000000000000000006771301675746700250140ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/7/transforms/xccdf2table-cce.xslt000066400000000000000000000007361301675746700244330ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/7/transforms/xccdf2table-profileccirefs.xslt000066400000000000000000000016021301675746700266710ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/7/transforms/xccdf2table-profilecisrefs.xslt000066400000000000000000000007101301675746700267100ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/7/transforms/xccdf2table-profilenistrefs.xslt000066400000000000000000000007101301675746700271070ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/7/transforms/xccdf2table-stig.xslt000066400000000000000000000006761301675746700246520ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEL/7/utils/000077500000000000000000000000001301675746700175425ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEL/7/utils/README000066400000000000000000000010241301675746700204170ustar00rootroot00000000000000This file is meant to give a quick overview to some of the scripts located in this directory. verify-input-sanity.py Purpose: This script can be invoked without arguments to examine the files within src/input to make sure that they are in good shape *prior to* building the XCCDF and OVAL content with the various make commands. Intent: Help XCCDF and OVAL developers spot common mistakes *before* utilizing the Makefile to build the XCCDF and OVAL content. Usage: ../../../shared/utils/verify-input-sanity.py scap-security-guide-0.1.31/RHEL/7/utils/sync-alt-titles.py000077500000000000000000000003651301675746700231570ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import sync_alt_titles_module if __name__ == "__main__": sync_alt_titles_module.main() scap-security-guide-0.1.31/RHEL/7/utils/verify-cce.py000077500000000000000000000003531301675746700221540ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import verify_cce_module if __name__ == "__main__": verify_cce_module.main() scap-security-guide-0.1.31/RHEVM3/000077500000000000000000000000001301675746700164465ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEVM3/Makefile000066400000000000000000000171201301675746700201070ustar00rootroot00000000000000all: tables guide checks content dist SHARED = ../shared include $(SHARED)/product-make.include # todo: remove this local override of REFS variable REFS = references PROD = rhevm3 VENDOR = ssgproject checks: xmlwf $(IN)/oval/*.xml $(SHARED)/$(UTILS)/combine-ovals.py $(CONF) $(PROD) $(IN)/oval > $(OUT)/unlinked-$(PROD)-oval.xml xmllint --format --output $(OUT)/unlinked-$(PROD)-oval.xml $(OUT)/unlinked-$(PROD)-oval.xml # example, if needed: for converting XCCDF into shorthand #xccdf2shorthand: # xsltproc -o $(XCCDF_OUTPUT_DIR)/$(PROD)-shorthand.xml $(TRANS)/xccdf2shorthand.xslt $(REFS)/usgcb-$(PROD)desktop-xccdf.xml # tidy -m -xml -utf8 --indent-spaces=0 $(XCCDF_OUTPUT_DIR)/$(PROD)-shorthand.xml table-profilenistrefs: $(OUT)/xccdf-unlinked-final.xml xsltproc -stringparam profile "desktop" -o $(OUT)/table-$(PROD)-nistrefs-desktop.html \ $(TRANS)/xccdf2table-profilenistrefs.xslt $< xsltproc -stringparam profile "server" -o $(OUT)/table-$(PROD)-nistrefs-server.html \ $(TRANS)/xccdf2table-profilenistrefs.xslt $< xsltproc -stringparam profile "common" -o $(OUT)/table-$(PROD)-nistrefs-common.html \ $(TRANS)/xccdf2table-profilenistrefs.xslt $< xsltproc -stringparam profile "ftp" -o $(OUT)/table-$(PROD)-nistrefs-ftp.html \ $(TRANS)/xccdf2table-profilenistrefs.xslt $< table-refs: $(OUT)/xccdf-unlinked-final.xml xsltproc -stringparam ref "nist" -o $(OUT)/table-$(PROD)-nistrefs.html $(TRANS)/xccdf2table-byref.xslt $< # break apart references by delimiter: xsltproc -stringparam ref "nist" -stringparam delim "," -o $(OUT)/table-$(PROD)-nistrefs-delim.html $(TRANS)/xccdf2table-byref.xslt $< # then sort them: xsltproc --html -o $(OUT)/table-$(PROD)-nistrefs-delim-sorted.html $(TRANS)/table-sortbyref.xslt $(OUT)/table-$(PROD)-nistrefs-delim.html table-idents: $(OUT)/xccdf-unlinked-final.xml xsltproc -o $(OUT)/table-$(PROD)-cces.html $(TRANS)/xccdf2table-cce.xslt $< xsltproc -stringparam ref "../$(REFS)/cce-$(PROD).xml" -o $(OUT)/table-$(PROD)-cces-$(PROD).html $(TRANS)/xccdf2table-cce.xslt $< table-srgmap: $(OUT)/xccdf-unlinked-final.xml # the map-to-items filename must be provided relative to the root of the main document being processed xsltproc -stringparam map-to-items "../$<" -o $(OUT)/table-$(PROD)-srgmap.html \ $(TRANS)/table-srgmap.xslt $(REFS)/U_Application_SRG_V1R1_Manual-xccdf.xml xsltproc -stringparam flat "y" -stringparam map-to-items "../$<" -o $(OUT)/table-$(PROD)-srgmap-flat.html \ $(TRANS)/table-srgmap.xslt $(REFS)/U_Application_SRG_V1R1_Manual-xccdf.xml xmllint --xmlout --html --output $(OUT)/table-$(PROD)-srgmap-flat.xhtml $(OUT)/table-$(PROD)-srgmap-flat.html table-stigs: $(OUT)/xccdf-unlinked-final.xml table-srgmap checks xsltproc -stringparam alttitles "../$(IN)/auxiliary/alt-titles-stig.xml" -o $< \ $(TRANS)/xccdf-alt-titles.xslt \ $< xsltproc -stringparam profile "stig-$(PROD)-server" -o $(OUT)/unlinked-stig-$(PROD)-xccdf.xml \ $(TRANS)/xccdf2stigformat.xslt $< xsltproc -o $(OUT)/table-stig-$(PROD)-server-stigformat.html \ $(TRANS)/xccdf2table-stig.xslt $(OUT)/unlinked-stig-$(PROD)-xccdf.xml tables: table-refs table-idents table-profilenistrefs table-srgmap alt-titles: $(OUT)/xccdf-unlinked-final.xml $(UTILS)/sync-alt-titles.py -p stig-$(PROD)-server -f $(IN)/auxiliary/alt-titles-stig.xml $< XMLLINT_INDENT="" xmllint --format --output $(IN)/auxiliary/alt-titles-stig.xml $(IN)/auxiliary/alt-titles-stig.xml content: $(OUT)/xccdf-unlinked-final.xml checks cp $< $(OUT)/unlinked-$(PROD)-xccdf.xml # Remove auxiliary Groups which are only for use in tables, and not guide output. xsltproc -o $(OUT)/unlinked-$(PROD)-xccdf-guide.xml $(TRANS)/xccdf-removeaux.xslt $(OUT)/unlinked-$(PROD)-xccdf.xml # The relabel-ids.py script chdirs to ./output, so refer to files from there. # Its second argument controls the IDs, as well as the output filenames. # Thus, with ID set to ssg, this creates ssg-$(PROD)-xccdf.xml and ssg-$(PROD)-oval.xml. $(SHARED)/$(UTILS)/cpe-generate.py $(OUT)/unlinked-$(PROD)-oval.xml $(IN)/oval/platform/$(PROD)-cpe-dictionary.xml $(ID) $(SHARED)/$(UTILS)/relabel-ids.py unlinked-$(PROD)-xccdf.xml $(ID) $(SHARED)/$(UTILS)/relabel-ids.py xccdf-unlinked-ocilrefs.xml $(ID) # Once things are relabelled, create a datastream xsltproc --stringparam reverse_DNS org.$(VENDOR).content /usr/share/openscap/xsl/xccdf_1.1_to_1.2.xsl \ $(OUT)/$(ID)-$(PROD)-xccdf.xml > $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml # Update @style attribute of to "SCAP_1.2". Fixes #1059 sed -i 's/style="SCAP_1.1"/style="SCAP_1.2"/' $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml # TODO: enable once RHEVM3 has OVAL checks! #oscap ds sds-compose $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml $(OUT)/$(ID)-$(PROD)-ds.xml # Update @schematron-version attribute in datastream to "1.2". Fixes #1191 # (Workaround for https://github.com/OpenSCAP/openscap/issues/383) #sed -i 's/schematron-version="[0-9].[0-9]"/schematron-version="1.2"/' $(OUT)/$(ID)-$(PROD)-ds.xml # Add in CPE content to datastream # TODO: enable once RHEVM3 has OVAL checks! #oscap ds sds-add $(OUT)/$(ID)-$(PROD)-cpe-dictionary.xml $(OUT)/$(ID)-$(PROD)-ds.xml # Fixes https://github.com/OpenSCAP/scap-security-guide/issues/1100 # Fixes https://github.com/OpenSCAP/scap-security-guide/issues/1101 #$(SHARED)/$(UTILS)/sds-move-ocil-to-checks.py $(OUT)/$(ID)-$(PROD)-ds.xml $(OUT)/$(ID)-$(PROD)-ds.xml # not ready until oscap resolve behavior resolved content-stig: table-stigs guide checks xmllint --format --output $(OUT)/unlinked-stig-$(PROD)-xccdf.xml $(OUT)/unlinked-stig-$(PROD)-xccdf.xml $(SHARED)/$(UTILS)/cpe-generate.py $(OUT)/unlinked-$(PROD)-oval.xml $(IN)/oval/platform/$(PROD)-cpe-dictionary.xml disa-predraft $(SHARED)/$(UTILS)/relabel-ids.py unlinked-stig-$(PROD)-xccdf.xml disa-predraft xmllint --format --output $(OUT)/disa-predraft-stig-$(PROD)-xccdf.xml $(OUT)/disa-predraft-stig-$(PROD)-xccdf.xml guide: content # TODO: enable datastream builds once RHEVM3 can successfuly build a datastream #ifeq ($(OPENSCAP_1_1_OR_LATER), 0) # $(SHARED)/$(UTILS)/build-all-guides.py --input $(OUT)/$(ID)-$(PROD)-ds.xml #else # @echo "Building guides from XCCDF 1.1, use OpenSCAP 1.1.0 or later for guides from datastreams!" $(SHARED)/$(UTILS)/build-all-guides.py --input $(OUT)/$(ID)-$(PROD)-xccdf.xml #endif submission-stig-check: table-stigs cd $(OUT); ../$(SHARED)/$(UTILS)/verify-references.py -p stig-$(PROD)-server \ --rules-with-disarefs-outside-profile unlinked-$(PROD)-xccdf-prerefs.xml # $(TRANS)/xccdf2csv-stig.py $(OUT)/unlinked-stig-$(PROD)-xccdf.xml > $(OUT)/table-stig.csv validate-xml: oscap xccdf validate-xml $(OUT)/$(ID)-$(PROD)-xccdf.xml oscap oval validate-xml --schematron $(OUT)/$(ID)-$(PROD)-oval.xml oscap cpe validate-xml $(OUT)/$(ID)-$(PROD)-cpe-dictionary.xml oscap oval validate-xml --schematron $(OUT)/$(ID)-$(PROD)-cpe-oval.xml # TODO: uncomment when the datastream validates #oscap ds sds-validate $(OUT)/$(ID)-$(PROD)-ds.xml validate: validate-xml cd $(OUT); ../$(SHARED)/$(UTILS)/verify-references.py --rules-with-invalid-checks --ovaldefs-unused ssg-$(PROD)-xccdf.xml # Items in dist are expected for distribution in an rpm dist: tables guide content mkdir -p $(DIST)/guide $(DIST)/content $(DIST)/policytables cp $(OUT)/*-guide-*.html $(DIST)/guide cp $(OUT)/$(ID)-$(PROD)-xccdf.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-oval.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-ocil.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-cpe-dictionary.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-cpe-oval.xml $(DIST)/content cp $(OUT)/table-$(PROD)-* $(DIST)/policytables #install: # cp -r $(PROD)/src/dist/* /usr/share/scap-security-guide/$(PROD) clean: rm -rf $(OUT)/* rm -rf $(DIST)/content $(DIST)/guide rm -rf $(BUILD) scap-security-guide-0.1.31/RHEVM3/input/000077500000000000000000000000001301675746700176055ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEVM3/input/auxiliary/000077500000000000000000000000001301675746700216145ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEVM3/input/auxiliary/srg_support.xml000066400000000000000000000105551301675746700247330ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEVM3/input/guide.xslt000066400000000000000000000043021301675746700216150ustar00rootroot00000000000000 A conditional clause for check statements. A conditional clause for check statements. This is a placeholder. scap-security-guide-0.1.31/RHEVM3/input/oval/000077500000000000000000000000001301675746700205465ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEVM3/input/oval/platform/000077500000000000000000000000001301675746700223725ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEVM3/input/oval/platform/rhevm3-cpe-dictionary.xml000066400000000000000000000012131301675746700272250ustar00rootroot00000000000000 Red Hat Enterprise Linux 6 installed_OS_is_rhel6 scap-security-guide-0.1.31/RHEVM3/input/oval/templates/000077500000000000000000000000001301675746700225445ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEVM3/input/oval/templates/Makefile000066400000000000000000000017741301675746700242150ustar00rootroot00000000000000templates: services packages kernel_modules permissions umasks sysctls SHARED_DIR=../../../../shared/templates export PYTHONPATH=../../../../shared OUTPUT:=$(shell mkdir -p output) services: ${SHARED_DIR}/create_services_enabled.py services_enabled.csv ${SHARED_DIR}/create_services_disabled.py services_disabled.csv packages: ${SHARED_DIR}/create_package_installed.py packages_installed.csv ${SHARED_DIR}/create_package_removed.py packages_removed.csv kernel_modules: ${SHARED_DIR}/create_kernel_modules_disabled.py kernel_modules_disabled.csv permissions: ${SHARED_DIR}/create_permission_checks.py file_dir_permissions.csv umasks: ${SHARED_DIR}/create_umask_checks.py file_umask_checks.csv sysctls: ${SHARED_DIR}/create_sysctl_checks.py sysctl_values.csv compare: diff output/ ../ | grep -v "Only in ../" copy: cp output/*.xml ../ cp output/*.sh ../../remediations/bash/ find-untemplated: templates ${SHARED_DIR}/find_untemplated.py clean: rm -f output/*.xml rm -f output/*.sh rm -rf output/ scap-security-guide-0.1.31/RHEVM3/input/oval/templates/README000066400000000000000000000024121301675746700234230ustar00rootroot00000000000000These templates are designed to make generation of OVAL tests which have repetitive structure easier. For example: $ ./create_services_disabled.py services_disabled.csv will produce all the OVAL checks (in a shorthand format) to disable services, and store them in the output directory. The CSV input files should contain all the relevant information for each check. Files should be compared to existing OVAL checks for consistency before copying to the main oval directory. A Makefile exists to activate all the scripts here and ease comparison with existing checks. For example, to run all scripts to generate OVAL checks from the available templates: $ make templates To compare the newly-generated files in the output directory to the existing checks, run: $ make compare Then, if the changes are agreeable, the following command can be run to copy the newly generated files to the main oval directory: $ make copy To list files that have been manually created (and may potentially be templated), run: # make find-untemplated Note, however, that some checks may have been intentionally hand-edited. For example, some sysctl checks (such as for IPv6) may include additional tests so that they pass if the IPv6 module is disabled. Never blindly copy over existing checks. scap-security-guide-0.1.31/RHEVM3/input/oval/templates/file_dir_permissions.csv000066400000000000000000000001361301675746700274710ustar00rootroot00000000000000/etc,shadow,0,0,0000 /etc,gshadow,0,0,0000 /etc,passwd,0,0,0644 /boot/grub,grub.conf,0,0,0600 scap-security-guide-0.1.31/RHEVM3/input/oval/templates/kernel_modules_disabled.csv000066400000000000000000000001161301675746700301160ustar00rootroot00000000000000cramfs dccp freevxfs hfs hfsplus jffs2 rds sctp squashfs tipc udf usb-storage scap-security-guide-0.1.31/RHEVM3/input/oval/templates/packages_installed.csv000066400000000000000000000002371301675746700271000ustar00rootroot00000000000000aide audit cronie ipsec-tools iptables iptables-ipv6 irqbalance lvm2 ntpdate ntp openldap-servers openswan policycoreutils postfix psacct rsyslog vlock vsftpd scap-security-guide-0.1.31/RHEVM3/input/oval/templates/packages_removed.csv000066400000000000000000000007541301675746700265660ustar00rootroot00000000000000abrt acpid at autofs bind certmonger cpuspeed cronie-anacron cups cyrus-sasl dbus dhcp dhcpd dovecot hal httpd iputils irda-utils isdn4k-utils kexec-tools libcgroup mdadm net-snmp nfs-utils oddjob openldap openldap-servers openssh-server pam_ldap portreserve qpid-cpp-server quota rhnsd rpcbind rsh rsh-server samba-common samba sendmail smartmontools squid sssd subscription-manager sysstat talk talk-server telnet-server tftp-server vlock vsftpd xinetd xorg-x11-server-common ypbind ypserv scap-security-guide-0.1.31/RHEVM3/input/oval/templates/services_disabled.csv000066400000000000000000000016631301675746700267410ustar00rootroot00000000000000# service_name, package_name, daemon_name (as recognized by chkconfig / systemd. To be used when daemon_name differs from service_name) abrtd,, acpid,, autofs,, certmonger,, cgred,, sssd,, telnetd,, atd,at, avahi-daemon,, bluetooth,, cgconfig,libcgroup, cpuspeed,cpuspeed, cups,cups, dhcpd,dhcp, dovecot,dovecot, haldaemon,hal, httpd,httpd, isdn,isdn4k-utils, kdump,kexec-tools, mcstrans,, mdmonitor,mdadm, messagebus,dbus, named,bind, netconsole,, netfs,, nfs,nfs-utils, nfslock,nfs-utils, oddjobd,oddjob, portreserve,portreserve, qpidd,qpid-cpp-server, quota_nld,quota, rdisc,iputils, rhnsd,rhnsd, rhsmcertd,subscription-manager, rpcbind,rpcbind, rpcgssd,nfs-utils, rpcidmapd,nfs-utils, rpcsvcgssd,nfs-utils, saslauthd,cyrus-sasl, sendmail,sendmail, smartd,smartmontools, smb,, snmpd,net-snmp, squid,squid, sshd,openssh-server, sysstat,sysstat, telnet,telnet-server, tftp,tftp-server, vsftpd,vsftpd, xinetd,xinetd, ypbind,ypbind, ypserv,ypserv, scap-security-guide-0.1.31/RHEVM3/input/oval/templates/services_enabled.csv000066400000000000000000000003231301675746700265540ustar00rootroot00000000000000auditd,audit crond,cronie ip6tables,iptables-ipv6 iptables,iptables irqbalance,irqbalance lvm2-monitor,lvm2 network,initscripts ntpd,ntp postfix,postfix psacct,psacct restorecond,policycoreutils rsyslog,rsyslog scap-security-guide-0.1.31/RHEVM3/input/oval/templates/sysctl_values.csv000066400000000000000000000011201301675746700261530ustar00rootroot00000000000000kernel.exec-shield,1 kernel.randomize_va_space,2 net.ipv4.conf.all.accept_redirects,0 net.ipv4.conf.all.accept_source_route,0 net.ipv4.conf.all.log_martians,1 net.ipv4.conf.all.rp_filter,1 net.ipv4.conf.all.secure_redirects,0 net.ipv4.conf.all.send_redirects,0 net.ipv4.conf.default.accept_redirects,0 net.ipv4.conf.default.accept_source_route,0 net.ipv4.conf.default.rp_filter,1 net.ipv4.conf.default.secure_redirects,0 net.ipv4.conf.default.send_redirects,0 net.ipv4.icmp_echo_ignore_broadcasts,1 net.ipv4.icmp_ignore_bogus_error_responses,1 net.ipv4.ip_forward,0 net.ipv4.tcp_syncookies,1 scap-security-guide-0.1.31/RHEVM3/input/oval/templates/template_OVAL_package_installed000066400000000000000000000016741301675746700306450ustar00rootroot00000000000000 Package PKGNAME Installed Red Hat Enterprise Linux 6 The RPM package PKGNAME should be installed. PKGNAME scap-security-guide-0.1.31/RHEVM3/input/oval/templates/template_kernel_module_disabled000066400000000000000000000024071301675746700310410ustar00rootroot00000000000000 Disable KERNMODULE Kernel Module Red Hat Enterprise Linux 6 The kernel module KERNMODULE should be disabled. /etc/modprobe.d ^.*\.conf$ ^\s*install\s+KERNMODULE\s+/bin/false$ 1 scap-security-guide-0.1.31/RHEVM3/input/oval/templates/template_package_removed000066400000000000000000000016551301675746700275050ustar00rootroot00000000000000 Package PKGNAME Removed Red Hat Enterprise Linux 6 The RPM package PKGNAME should be removed. PKGNAME scap-security-guide-0.1.31/RHEVM3/input/oval/templates/template_permissions000066400000000000000000000030011301675746700267270ustar00rootroot00000000000000 Verify FILEPATH Permissions Red Hat Enterprise Linux 6 This test makes sure that FILEPATH is owned by FILEUID, group owned by FILEGID, and has mode FILEMODE. If the target file or directory has an extended ACL then it will fail the mode check. FILEDIR UNIX_FILENAME FILEUID FILEGID STATEMODE scap-security-guide-0.1.31/RHEVM3/input/oval/templates/template_service_disabled000066400000000000000000000117231301675746700276550ustar00rootroot00000000000000 Service SERVICENAME Disabled Red Hat Enterprise Linux 6 The SERVICENAME service should be disabled if possible. SERVICENAME 0 SERVICENAME 1 SERVICENAME 2 SERVICENAME 3 SERVICENAME 4 SERVICENAME 5 SERVICENAME 6 false true scap-security-guide-0.1.31/RHEVM3/input/oval/templates/template_service_enabled000066400000000000000000000117021301675746700274750ustar00rootroot00000000000000 Service SERVICENAME Enabled Red Hat Enterprise Linux 6 The SERVICENAME service should be enabled if possible. SERVICENAME 0 SERVICENAME 1 SERVICENAME 2 SERVICENAME 3 SERVICENAME 4 SERVICENAME 5 SERVICENAME 6 true false scap-security-guide-0.1.31/RHEVM3/input/oval/templates/template_sysctl000066400000000000000000000022711301675746700257050ustar00rootroot00000000000000 Kernel Runtime Parameter "SYSCTLVAR" Check Red Hat Enterprise Linux 6 The kernel runtime parameter "SYSCTLVAR" should be set to "SYSCTLVAL". SYSCTLVAR SYSCTLVAL scap-security-guide-0.1.31/RHEVM3/input/profiles/000077500000000000000000000000001301675746700214305ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEVM3/input/profiles/stig-rhevm3.xml000066400000000000000000000007111301675746700243210ustar00rootroot00000000000000 Common Profile for General-Purpose Systems This profile contains items common to general-purpose desktop and server installations. I - Mission Critical Sensitive <ProfileDescription></ProfileDescription> II - Mission Support Public <ProfileDescription></ProfileDescription> II - Mission Support Classified <ProfileDescription></ProfileDescription> III - Administrative Sensitive <ProfileDescription></ProfileDescription> SRG-APP-000001 <GroupDescription></GroupDescription> SRG-APP-000001 The application must be able to define the maximum number of concurrent sessions for an application account globally, by account type, by account, or a combination thereof. <VulnDiscussion>Application management includes the ability to control the number of users and user sessions that utilize an application. Limiting the number of allowed users and sessions per user is helpful in limiting risks related to Denial of Service attacks. This requirement addresses concurrent session control for a single information system account and does not address concurrent sessions by a single user via multiple system accounts. This requirement may be met via the application or by utilizing information system session control provided by a web server with specialized session management capabilities. If it has been specified that this requirement will be handled by the application, the capability to limit the maximum number of concurrent single user sessions must be designed and built into the application. The organization will need to define the maximum number of concurrent sessions for an information system account globally, by account type, by account, or a combination thereof and the application shall enforce that requirement. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000054 SRG-APP-000002 <GroupDescription></GroupDescription> SRG-APP-000002 The application must ensure that the screen display is obfuscated when an application session lock event occurs. <VulnDiscussion>A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not log out because of the temporary nature of the absence. The session lock is implemented at the point where session activity can be determined. This is typically at the operating system-level, but may be at the application-level. When the application design specifies the application rather than the operating system will determine when to lock the session, the application session lock event must include an obfuscation of the display screen so as to prevent other users from reading what was previously displayed. An example of obfuscation is a screensaver creating a viewable pattern that overwrites the entire screen rendering the screen contents unreadable. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000060 SRG-APP-000003 <GroupDescription></GroupDescription> SRG-APP-000003 The application must support the requirement to initiate a session lock after an organization defined time period of system or application inactivity has transpired. <VulnDiscussion>A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not log out because of the temporary nature of the absence. Rather than relying on the user to manually lock their application session prior to vacating the vicinity, applications need to be able to identify when a user's application session has idled and take action to initiate the session lock. The session lock is implemented at the point where session activity can be determined and/or controlled. This is typically at the operating system-level and results in a system lock, but may be at the application-level where the application interface window is secured instead. The organization defines the period of inactivity that shall pass before a session lock is initiated so this must be configurable. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000057 SRG-APP-000004 <GroupDescription></GroupDescription> SRG-APP-000004 Applications must ensure that users can directly initiate session lock mechanisms which prevent further access to the system. <VulnDiscussion>A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not want to log out because of the temporary nature of the absence. The session lock is implemented at the point where session activity can be determined. This is typically at the operating system-level, but may be at the application-level. Rather than be forced to wait for a period of time to expire before the user session can be locked, applications need to provide users with the ability to manually invoke a session lock so users may secure their application should the need arise for them to temporarily vacate the immediate physical vicinity.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000058 SRG-APP-000005 <GroupDescription></GroupDescription> SRG-APP-000005 The application must have the ability to retain a session lock remaining in effect until the user re-authenticates using established identification and authentication procedures. <VulnDiscussion>A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not want to log out because of the temporary nature of the absence. The session lock is implemented at the point where session activity can be determined. This is typically determined and performed at the operating system-level, but in some instances it may be at the application-level. Regardless of where the session lock is determined and implemented, once invoked the session lock shall remain in place until the user re-authenticates. No other system or application activity aside from re-authentication shall unlock the system. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000056 SRG-APP-000006 <GroupDescription></GroupDescription> SRG-APP-000006 The application must maintain and support the use of organization defined security attributes to stored information. <VulnDiscussion>Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information. These attributes are typically associated with internal data structures (e.g., records, buffers, files) within the information system and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. One example includes marking data as classified or FOUO. These security attributes may be assigned manually or during data processing but either way, it is imperative these assignments are maintained while the data is in storage. If the security attributes are lost when the data is stored, there is the risk of a data compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001399 SRG-APP-000007 <GroupDescription></GroupDescription> SRG-APP-000007 The application must support and maintain the binding of organization defined security attributes to information in process. <VulnDiscussion>Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information. These attributes are typically associated with internal data structures (e.g., records, buffers, files) within the application and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. Organizations define the security attributes of their data (e.g., classified, FOUO). Applications generating and/or processing data assigned these security attributes must maintain the binding of these security attributes to the data while it is being processed. If the application does not maintain the data security attributes while it processes the data, there is a risk of data compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001400 SRG-APP-000008 <GroupDescription></GroupDescription> SRG-APP-000008 The application must maintain and support the use of organization defined security attributes to information in transmission. <VulnDiscussion>Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information. These attributes are typically associated with internal data structures (e.g., records, buffers, files) within the application and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. Organizations define the security attributes of their data (e.g., classified, FOUO). Applications generating and/or processing data assigned these organization defined security attributes must maintain the binding of these attributes to the data when the data are transmitted. If the application does not maintain the data security attributes when it transmits the data, there is a risk of data compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001401 SRG-APP-000009 <GroupDescription></GroupDescription> SRG-APP-000009 The application must dynamically reconfigure security attributes in accordance with an identified security policy as information is created and combined. <VulnDiscussion>Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information. These attributes are typically associated with internal data structures (e.g., data records, buffers, files) within the application and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. Organizations define the security attributes of their data (e.g., classified, FOUO). When application data is created and/or combined, data security attributes defined by organizational policy must be dynamically created and/or updated to reflect the potential change in data sensitivity and characteristics. If the application does not dynamically reconfigure the data security attributes as data is created and combined, there is the possibility that classified data may become comingled with unclassified data resulting in a data compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001424 SRG-APP-000010 <GroupDescription></GroupDescription> SRG-APP-000010 The application must provide the capability to specify administrative users and grant them the right to change application security attributes pertaining to application data. <VulnDiscussion>Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information. Security attributes are typically associated with internal data structures (e.g., records, buffers, files) within the application and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the organizational information security policy. Organizations define the security attributes of their data (e.g., classified, FOUO, sensitive). Changing security attributes within an application is usually performed by a person or persons who have been delegated the task and the associated responsibilities accorded to application administrative personnel. Applications creating and/or assigning security attributes to data must have the flexibility to allow authorized staff to change these security attributes. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001425 SRG-APP-000011 <GroupDescription></GroupDescription> SRG-APP-000011 The application must maintain the binding of security attributes to information with sufficient assurance that the information/attribute association can be used as the basis for automated policy actions. <VulnDiscussion>Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information. These attributes are typically associated with internal data structures (e.g., records, buffers, files) within the information system and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. Examples of application security attributes are classified, FOUO, sensitive, etc. Applications maintaining the binding of organization defined security attributes to data must ensure the information-attribute associations can be used as a basis for automated policy actions. The integrity of security attribute values is critical to ensuring that automated policy actions are performed accurately. Examples of automated policy actions include automated access control decisions (e.g., Mandatory Access Control decisions), or decisions to release (or not release) information (e.g., information flows via cross domain systems). </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001426 SRG-APP-000012 <GroupDescription></GroupDescription> SRG-APP-000012 The application must allow authorized users to associate security attributes with information. <VulnDiscussion>Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information. These attributes are typically associated with internal data structures (e.g., records, buffers, files) within the information system and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. Examples of application security attributes are classified, FOUO, sensitive, etc. Throughout the course of normal usage, authorized users of applications that handle sensitive data will have the need to associate security attributes with information. Applications that maintain the binding of organization defined security attributes to data must ensure authorized users can associate security attributes with information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001427 SRG-APP-000013 <GroupDescription></GroupDescription> SRG-APP-000013 The application must display security attributes in human-readable form on each object output from the system to system output devices to identify an organization-identified set of special dissemination, handling, or distribution instructions using organization-identified human readable, standard naming conventions. <VulnDiscussion>Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information. These attributes are typically associated with internal data structures (e.g., records, buffers, files, registry keys) within the information system and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. Examples of application security attributes are classified, FOUO, sensitive, etc. Security attributes need to be displayed in human readable form in order to determine how the data should be disseminated, handled and what distribution instructions apply to the data. When applications generate or output data, the associated security attributes need to be displayed. Objects output from the information system include pages, screens, or equivalent. Output devices include printers and video displays on computer terminals, monitors, screens on notebook/laptop computers and personal digital assistants. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001428 SRG-APP-000014 <GroupDescription></GroupDescription> SRG-APP-000014 Applications providing remote access capabilities must utilize approved cryptography to protect the confidentiality of remote access sessions. <VulnDiscussion>Remote access is any access to an organizational information system by a user (or an information system) communicating through an external, non-organization-controlled network (e.g., the Internet). Examples of remote access methods include dial-up, broadband, and wireless. Remote network access is accomplished by leveraging common communication protocols and establishing a remote connection. These connections will typically occur over either the public Internet or the Public Switched Telephone Network (PSTN). Since neither of these internetworking mechanisms are private nor secure, if cryptography is not used, then the session data traversing the remote connection could be intercepted and compromised. Cryptography provides a means to secure the remote connection so as to prevent unauthorized access to the data traversing the remote access connection thereby providing a degree of confidentiality. The encryption strength of mechanism is selected based on the security categorization of the information traversing the remote connection.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000068 SRG-APP-000015 <GroupDescription></GroupDescription> SRG-APP-000015 Applications providing remote access connectivity must use cryptography to protect the integrity of the remote access session. <VulnDiscussion>Remote access is any access to an organizational information system by a user (or an information system) communicating through an external, non-organization-controlled network (e.g., the Internet). Examples of remote access methods include dial-up, broadband, and wireless. Remote network access is accomplished by leveraging common communication protocols and establishing a remote connection. These connections will typically occur over the public Internet, the Public Switched Telephone Network (PSTN) or sometimes both. Since neither of these internetworking mechanisms are private nor secure, if cryptography is not used, then the session data traversing the remote connection could be intercepted and potentially modified. Cryptography provides a means to secure the remote connection so as to prevent unauthorized access to the data traversing the remote access connection thereby providing a degree of integrity. The encryption strength of mechanism is selected based on the security categorization of the information traversing the remote connection.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001453 SRG-APP-000016 <GroupDescription></GroupDescription> SRG-APP-000016 The application must employ automated mechanisms to facilitate the monitoring and control of remote access methods. <VulnDiscussion>Remote network access is accomplished by leveraging common communication protocols and establishing a remote connection. These connections will occur over the public Internet. Remote access is any access to an organizational information system by a user (or an information system) communicating through an external, non-organization-controlled network (e.g., the Internet). Examples of remote access methods include dial-up, broadband, and wireless. Automated monitoring of remote access sessions allows organizations to audit user activities on a variety of information system components (e.g., servers, workstations, notebook/laptop computers) and to ensure compliance with remote access policy. Remote access applications such as those providing remote access to network devices and information systems and are individually configured with no monitoring or automation capabilities increase risk and makes remote user access management difficult at best. Applications providing remote access capability need to provide the ability to automatically monitor and control remote user sessions. This includes the capability to directly trigger actions based on user activity or pass information and or data to a separate application or entity that can then perform automated tasks based on the information. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000067 SRG-APP-000017 <GroupDescription></GroupDescription> SRG-APP-000017 Applications providing remote access must have capabilities that allow all remote access to be routed through managed access control points. <VulnDiscussion>This requirement relates to the use of applications providing remote access services. Remote access is any access to an organizational information system by a user (or an information system) communicating through an external, non-organization-controlled network (e.g., the Internet). Examples of remote access methods include dial-up, broadband, and wireless. Remote network access is accomplished by leveraging common communication protocols and establishing a remote connection. These connections will typically occur over either the public Internet or the Public Switched Telephone Network (PSTN). Please note, utilization of a virtual private network when adequately provisioned with appropriate security controls, is considered an internal network and is not considered remote access. Without centralized control of inbound connections, management of these access points is difficult at best. It is critical that applications providing or offering remote access capabilities also have the capability to route the access through managed access control points. One example is the use of software applications such as PCAnywhere or Terminal Services. Rather than having PCAnywhere installed on multiple systems, remote access software must have the capability to be centrally managed and controlled so there are not multiple disparate access points into the environment. Applications providing remote access must have capabilities that allow all remote access to be routed through managed access control points.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000069 SRG-APP-000018 <GroupDescription></GroupDescription> SRG-APP-000018 The application must monitor for unauthorized remote connections to the information system on an organization-defined frequency. <VulnDiscussion>Organizations need to monitor for unauthorized remote access connections to information systems in order to determine if break-in attempts or other unauthorized activity is occurring. There are already other SRG requirements for applications to generate audit connection logs to record connection activity. It is for the organization to determine which of those audited connections is unauthorized. This task is usually handled by the IDS, log alarming or some other security mechanism specifically designed to automate and address this requirement. This requirement is NA for applications not designed to monitor for unauthorized remote connections to information systems. Applications designed to meet this requirement must be able to do so on an organization-defined frequency.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000071 SRG-APP-000019 <GroupDescription></GroupDescription> SRG-APP-000019 The application must ensure remote sessions for accessing an organization-defined list of security functions and security-relevant information are audited. <VulnDiscussion>Remote access is any access to an organizational information system by a user (or an information system) communicating through an external, non-organization-controlled network (e.g., the Internet). Examples of remote access methods include dial-up, broadband, and wireless. Remote network and system access is accomplished by leveraging common communication protocols to establish a remote connection. These connections will typically originate over either the public Internet or the Public Switched Telephone Network (PSTN). Neither of these internetworking mechanisms is private or secure and they do not by default restrict access to networked resources once connectivity is established. Numerous best practices are employed to protect remote connections such as utilizing encryption to protect data sessions and firewalls to restrict and control network connectivity. In addition to these protections, auditing must also be utilized in order to track system activity, assist in diagnosing system issues and provide evidence needed for forensic investigations post security incident. When organizations define security related application functions or security-related application information, it is incumbent upon the application providing access to that data to ensure auditing of remote connectivity to those resources occurs in support of organizational requirements. Remote access to security functions (e.g., user management, audit log management, etc.) and security relevant information requires the activity be audited by the organization. Any application providing remote access must support organizational requirements to audit access or organization-defined security functions and security-relevant information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001454 SRG-APP-000020 <GroupDescription></GroupDescription> SRG-APP-000020 Applications must support the capability to disable network protocols deemed by the organization to be nonsecure except for explicitly identified components in support of specific operational requirements. <VulnDiscussion>This control is related to remote access but more specifically to the networking protocols allowing systems to communicate. Remote access is any access to an organizational information system by a user (or an information system) communicating through an external, non-organization-controlled network (e.g., the Internet). Examples of remote access methods include dial-up, broadband, and wireless. Some networking protocols allowing remote access may not meet security requirements to protect data and components. Bluetooth and peer-to-peer networking are examples of less than secure networking protocols. The DoD Ports, Protocols, and Services Management (PPSM) program provides implementation guidance on the use of IP protocols and application and data services traversing the DoD Networks in a manner supporting net-centric operations. Applications implementing or utilizing remote access network protocols need to ensure the application is developed and implemented in accordance with the PPSM requirements. In situations where it has been determined that specific operational requirements outweigh the risks of enabling an insecure network protocol, the organization may pursue a risk acceptance.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001436 SRG-APP-000021 <GroupDescription></GroupDescription> SRG-APP-000021 The application must monitor for unauthorized connections of mobile devices to organizational information systems. <VulnDiscussion>Mobile devices include portable storage media (e.g., USB memory sticks, external hard disk drives) and portable computing and communications devices with information storage capability (e.g., notebook/laptop computers, personal digital assistants, cellular telephones, digital cameras, and audio recording devices). Organization-controlled mobile devices include those devices for which the organization has the authority to specify and the ability to enforce specific security requirements. Usage restrictions and implementation guidance related to mobile devices include, configuration management, device identification and authentication, implementation of mandatory protective software (e.g., malicious code detection, firewall), scanning devices for malicious code, updating virus protection software, scanning for critical software updates and patches, conducting primary operating system (and possibly other resident software) integrity checks, and disabling unnecessary hardware (e.g., wireless, infrared). In order to detect unauthorized mobile device connections, organizations must first identify and document what mobile devices are authorized. Monitoring for unauthorized connections is usually handled by configuration management software, log alarming, IDS, or some other security mechanism specifically designed to automate and address this requirement. This requirement is NA for applications not designed to monitor for unauthorized connections to information systems. Applications designed to meet this requirement must be able to do so according to organizational usage restrictions and policy.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000085 SRG-APP-000022 <GroupDescription></GroupDescription> SRG-APP-000022 Applications must not enable information system functionality providing the capability for automatic execution of code on mobile devices without user direction. <VulnDiscussion>Mobile devices include portable storage media (e.g., USB memory sticks, external hard disk drives) and portable computing and communications devices with information storage capability (e.g., notebook/laptop computers, personal digital assistants, cellular telephones, digital cameras, and audio recording devices). Auto execution vulnerabilities can result in malicious programs being automatically executed. Examples of information system functionality providing the capability for automatic execution of code are Auto Run and Auto Play. Auto Run and Auto Play are components of the Microsoft Windows operating system dictating what actions the system takes when a drive is mounted. This requirement is designed to address vulnerabilities arising when mobile devices such as USB memory sticks or other mobile storage devices are automatically mounted and applications are automatically invoked without user knowledge or acceptance. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000087 SRG-APP-000023 <GroupDescription></GroupDescription> SRG-APP-000023 Applications must provide automated mechanisms for supporting user account management. The automated mechanisms may reside within the application itself or may be offered by the operating system or other infrastructure providing automated account management capabilities. <VulnDiscussion>A comprehensive application account management process that includes automation helps to ensure that accounts designated as requiring attention are consistently and promptly addressed. Examples include but are not limited to using automation to take action on multiple accounts designated as inactive, suspended or terminated or by disabling accounts located in non-centralized account stores such as multiple servers. Enterprise environments make application user account management challenging and complex. A user management process requiring administrators to manually address account management functions adds risk of potential oversight. Automated mechanisms may be comprised of differing technologies that when placed together contain an overall automated mechanism supporting an organization's automated account management requirements.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000015 SRG-APP-000024 <GroupDescription></GroupDescription> SRG-APP-000024 The application must provide a mechanism to automatically terminate accounts designated as temporary or emergency accounts after an organization-defined time period. <VulnDiscussion>Temporary application accounts could ostensibly be used in the event of a vendor support visit where a support representative requires a temporary unique account in order to perform diagnostic testing or conduct some other support related activity. When these types of accounts are created, there is a risk that the temporary account may remain in place and active after the support representative has left. To address this, in the event temporary application accounts are required, the application must ensure that accounts designated as temporary in nature shall automatically terminate these accounts after an organization-defined time period. Such a process and capability greatly reduces the risk that accounts will be misused, hijacked, or data compromised. To address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms meeting or exceeding access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality. Examples of enterprise level authentication/access mechanisms include but are not limited to, Active Directory and LDAP. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000016 SRG-APP-000025 <GroupDescription></GroupDescription> SRG-APP-000025 The application must be capable of automatically disabling accounts after a 35 day period of account inactivity. <VulnDiscussion>Users are often the first line of defense within an application. Active users take notice of system and data conditions and are usually the first to notify systems administrators when they notice a system or application related anomaly pertaining to their own account. Inactive user accounts pose a risk to systems and applications. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. Attackers that are able to exploit an inactive account can potentially obtain and maintain undetected access to an application. Applications need to track periods of user inactivity and disable application accounts after an organization-defined period of inactivity. Such a process greatly reduces the risk that accounts will be misused, hijacked, or data compromised. To address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality. Examples of enterprise level authentication/access mechanisms include but are not limited to, Active Directory and LDAP.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000017 SRG-APP-000026 <GroupDescription></GroupDescription> SRG-APP-000026 Applications must support the requirement to automatically audit account creation. <VulnDiscussion>Once an attacker establishes initial access to a system, they often attempt to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply create a new account. Auditing of account creation is one method and best practice for mitigating this risk. A comprehensive account management process will ensure an audit trail documents the creation of application user accounts and, as required, notifies administrators and/or application owners exists. Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes. To address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms meeting or exceeding access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality. Examples of enterprise level authentication/access mechanisms include but are not limited to, Active Directory and LDAP.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000018 SRG-APP-000027 <GroupDescription></GroupDescription> SRG-APP-000027 Applications must support the requirement to automatically audit account modification. <VulnDiscussion>Once an attacker establishes initial access to a system, they often attempt to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply modify an existing account. Auditing of account modification is one method and best practice for mitigating this risk. A comprehensive application account management process ensures an audit trail automatically documents the modification of application user accounts and, as required, notifies administrators, application owners, and/or appropriate individuals. Applications must provide this capability directly, leveraging complimentary technology providing this capability or a combination thereof. Automated account auditing processes greatly reduces the risk that accounts will be surreptitiously modified and provides logging that can be used for forensic purposes. To address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms meeting or exceeding access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality. Examples of enterprise level authentication/access mechanisms include but are not limited to, Active Directory and LDAP.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001403 SRG-APP-000028 <GroupDescription></GroupDescription> SRG-APP-000028 The application must automatically audit account disabling actions and notify appropriate individuals. <VulnDiscussion>When application accounts are disabled, user accessibility is affected. Accounts are utilized for identifying individual application users or for identifying the application processes themselves. In order to detect and respond to events affecting user accessibility and application processing, applications must audit account disabling actions and, as required, notify the appropriate individuals, so they can investigate the event. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes. To address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms meeting or exceeding access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality. Examples of enterprise level authentication/access mechanisms include but are not limited to, Active Directory and LDAP.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001404 SRG-APP-000029 <GroupDescription></GroupDescription> SRG-APP-000029 The application must automatically audit account termination and notify appropriate individuals. <VulnDiscussion>When application accounts are terminated, user accessibility is affected. Accounts are utilized for identifying individual application users or for identifying the application processes themselves. In order to detect and respond to events affecting user accessibility and application processing, applications must audit account terminating actions and notify the appropriate individuals, so they can investigate the event. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes. To address the multitude of policy based audit requirements, and to ease the burden of meeting these requirements, many application developers choose to integrate their applications with enterprise level authentication/access/audit mechanisms meeting or exceeding access control policy requirements. Examples include but are not limited to, Active Directory and LDAP.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001405 SRG-APP-000030 <GroupDescription></GroupDescription> SRG-APP-000030 Applications must support the organizational requirement to automatically monitor on atypical usage of accounts. <VulnDiscussion>Atypical account usage is behavior that is not part of normal usage cycles. For example, user account activity occurring after hours or on weekends. A comprehensive account management process will ensure that an audit trail which documents the use of application user accounts and as required, notifies administrators and/or application owners exists. Such a process greatly reduces the risk that compromised user accounts will continue to be used by unauthorized persons and provides logging that can be used for forensic purposes. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001356 SRG-APP-000031 <GroupDescription></GroupDescription> SRG-APP-000031 Service Oriented Architecture (SOA) based applications must dynamically manage user privileges and associated access authorizations. <VulnDiscussion>Web services are web applications providing a method of communication between two or more different electronic devices. They are normally used by applications to provide each other with data. The World Wide Web Consortium (W3C) defines a web service as: "a software system designed to support interoperable machine to machine interaction over a network. It has an interface described in a machine processable format (specifically, Web Services Description Language or WSDL). Other systems interact with the web service in a manner prescribed by its description using Simple Object Access Protocol (SOAP) messages typically conveyed using HTTP with an XML serialization in conjunction with other web-related standards". Web services provide different challenges in managing access than what is presented by typical user based applications. In contrast to conventional access control approaches which employ static information system accounts and predefined sets of user privileges, many service-oriented architecture implementations rely on run time access control decisions facilitated by dynamic privilege management. While user identities remain relatively constant over time, user privileges may change more frequently based on the ongoing mission/business requirements and operational needs of the organization. Service Oriented Architecture (SOA) based applications need to take this possibility into account and leverage dynamic access control methodologies.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000020 SRG-APP-000032 <GroupDescription></GroupDescription> SRG-APP-000032 The application must employ automated mechanisms enabling authorized users to make information sharing decisions based on access authorizations of sharing partners and access restrictions on information to be shared. <VulnDiscussion>User based collaboration and information sharing applications present challenges regarding classification and dissemination of information generated and shared among the application users. These types of applications are intended to share information created and stored within the application; however, not all users have a need to view all data created or stored within the collaboration tool. Collaboration tools and all applications handling information that may be restricted in some manner (e.g., privileged medical, contract-sensitive, proprietary, personally identifiable information, special access programs/compartments) must provide the capability to automatically enable authorized users to make information sharing decisions based upon access authorizations. Depending on the information-sharing circumstance, the sharing partner may be defined at the individual, group, or organization level and information may be defined by specific content, type, or security categorization. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000099 SRG-APP-000033 <GroupDescription></GroupDescription> SRG-APP-000033 The application must enforce approved authorizations for logical access to the system in accordance with applicable policy. <VulnDiscussion>Strong access controls are critical to securing application data. Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) must be employed by applications, when applicable, to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, domains) in the information system. Consideration should be given to the implementation of an audited, explicit override of automated mechanisms in the event of emergencies or other serious events. If encryption of stored information is employed as an access enforcement mechanism, the cryptography used is FIPS 140-2 (as amended) compliant. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000213 SRG-APP-000034 <GroupDescription></GroupDescription> SRG-APP-000034 The application must enforce dual authorization, based on organizational policies and procedures for organization-defined privileged commands. <VulnDiscussion>Dual authorization requires 2 distinct approving authorities to approve the use of an application command prior to it being invoked. This capability is typically reserved for specific application functionality where the application owner, data owner or organization requires an additional assurance that certain application commands are only invoked under the utmost authority. When a policy is defined stating that certain commands contained within an application require dual-authorization before they may be invoked, or when an organization defines a set of application related privileged commands requiring dual authorization, the application must support those requirements. Due to potential delays in obtaining secondary approvals prior to executing commands, dual authorization mechanisms should not be utilized when an immediate response is necessary in order to ensure public and/or environmental safety. If, after due consideration, it is determined the benefit of dual authorization outweighs identified risks, the organization must establish documented procedures, assign specific personnel to provide approvals and establish operational exercises assuring that any risks to public safety, environmental safety or otherwise, are minimized. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000021 SRG-APP-000035 <GroupDescription></GroupDescription> SRG-APP-000035 Applications must enforce non-discretionary access control policies over users and resources where the policy rule set for each policy specifies: access control information (i.e., attributes) employed by the policy rule set (e.g., position, nationality, age, project, time of day). <VulnDiscussion>Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) are employed to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, domains). Non-discretionary access controls are controls determined by policy makers, are managed centrally or by a central authority and may not be changed at the discretion of ordinary application users. Data protection requirements may result in a non-discretionary access control policy being specified as part of the application design. Non-discretionary access controls are employed at the application level to restrict and control access to application data thereby providing increased information security for the organization. Policy rule sets would be developed to establish that each user receives only the information to which the user is authorized. The policy rule set will specify that each application user account will be assigned attributes including information such as position, nationality, age, project, time of data, etc. Applications must enforce these non-discretionary access control policies over application users and resources.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000022 SRG-APP-000036 <GroupDescription></GroupDescription> SRG-APP-000036 The application must enforce Discretionary Access Control (DAC) policy allowing users to specify and control sharing by named individuals, groups of individuals, or by both, limiting propagation of access rights and includes or excludes access to the granularity of a single user. <VulnDiscussion>Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) are employed by organizations to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, domains). DAC is a type of access control methodology serving as a means of restricting access to objects and data based on the identity of subjects and/or groups to which they belong. It is discretionary in the sense that application users with the appropriate permissions to access an application resource or data have the discretion to pass that permission on to another user either directly or indirectly. Data protection requirements may result in a DAC policy being specified as part of the application design. Discretionary access controls would be employed at the application level to restrict and control access to application objects and data thereby providing increased information security for the organization. When DAC controls are employed, those controls must limit sharing to named application users, groups of users or both. The application DAC controls must also limit the propagation of access rights and have the ability to exclude access to data down to the granularity of a single user. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001362 SRG-APP-000037 <GroupDescription></GroupDescription> SRG-APP-000037 The application must prevent access to organization-defined security-relevant information except during secure, non-operable system states. <VulnDiscussion>Security-relevant information is any information within the information system that can potentially impact the operation of security functions in a manner possibly resulting in failure to enforce the system security policy or maintain isolation of code and data. Organizations may define specific security relevant information requiring protection. Filtering rules for routers and firewalls, cryptographic key management information, key configuration parameters for security services, and access control lists are examples of security-relevant information. Secure, non-operable system states are states in which the information system is not performing mission/business-related processing (e.g., the system is off-line for maintenance, troubleshooting, boot-up, shutdown). Access to these types of data is to be prevented unless the system is in a maintenance mode or has otherwise been brought off-line. The goal is to minimize the potential a security configuration or data may be dynamically and perhaps, surreptitiously overwritten or changed (without going through a formal system change process that can document the changes).</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000024 SRG-APP-000038 <GroupDescription></GroupDescription> SRG-APP-000038 Applications providing information flow control must enforce approved authorizations for controlling the flow of information within the system in accordance with applicable policy. <VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. From an application perspective, flow control is established once application data flow modeling has been completed. Data flow modeling can be described as: the process of identifying, modeling and documenting how data moves around an information system. Data flow modeling examines processes (activities transforming data from one form to another), data stores (the holding areas for data), external entities (what sends data into a system or receives data from a system, and data flows (routes by which data can flow). Once the application data flows have been identified, corresponding flow controls can be applied at the appropriate points. A few examples of flow control restrictions include: keeping export controlled information from being transmitted in the clear to the Internet and blocking information marked as classified but is being transported to an unapproved destination. Information flow control policies and enforcement mechanisms are commonly employed by organizations to control the flow of information between designated sources and destinations (e.g., networks, individuals, devices) within information systems and between interconnected systems. Flow control is based on the characteristics of the information and/or the information path. Application specific examples of flow control enforcement can be found in information protection software (e.g., guards, proxies, gateways and cross domain solutions) employing rule sets or establish configuration settings restricting information system services or provide message-filtering capability based on content (e.g., using key word searches or document characteristics). Applications providing information flow control must be able to enforce approved authorizations for controlling the flow of information within the system in accordance with applicable policy. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001368 SRG-APP-000039 <GroupDescription></GroupDescription> SRG-APP-000039 Applications providing information flow control must enforce approved authorizations for controlling the flow of information between interconnected systems in accordance with applicable policy. <VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. From an application perspective, flow control is established once application data flow modeling has been completed. Data flow modeling can be described as: the process of identifying, modeling and documenting how data moves around an information system. Data flow modeling examines processes (activities that transform data from one form to another), data stores (the holding areas for data), external entities (what sends data into a system or receives data from a system, and data flows (routes by which data can flow). Once the application data flows have been identified, corresponding flow controls can be applied at the appropriate points. A few examples of flow control restrictions include: keeping export controlled information from being transmitted in the clear to the Internet and blocking information that is marked as classified but is being transported to an unapproved destination. Information flow control policies and enforcement mechanisms are commonly employed by organizations to control the flow of information between designated sources and destinations (e.g., networks, individuals, devices) within information systems and between interconnected systems. Flow control is based on the characteristics of the information and/or the information path. Application specific examples of flow control enforcement can be found in information protection software (e.g., guards, proxies, gateways and cross domain solutions) employing rule sets or establishing configuration settings restricting information system services or provide message-filtering capability based on content (e.g., using key word searches or document characteristics). Applications providing information flow control must be able to enforce approved authorizations for controlling the flow of information between interconnected systems in accordance with applicable policy.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001414 SRG-APP-000040 <GroupDescription></GroupDescription> SRG-APP-000040 Applications providing information flow control must use explicit security attributes on information, source, and destination objects as a basis for flow control decisions. <VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. From an application perspective, flow control is established once application data flow modeling has been completed. Data flow modeling can be described as: the process of identifying, modeling and documenting how data moves around an information system. Data flow modeling examines processes (activities that transform data from one form to another), data stores (the holding areas for data), external entities (what sends data into a system or receives data from a system), and data flows (routes by which data can flow). Once the application data flows have been identified, corresponding flow controls can be applied at the appropriate points. A few examples of flow control restrictions include: keeping export controlled information from being transmitted in the clear to the Internet and blocking information marked as classified but is being transported to an unapproved destination. Information flow control policies and enforcement mechanisms are commonly employed by organizations to control the flow of information between designated sources and destinations (e.g., networks, individuals, devices) within information systems and between interconnected systems. Flow control is based on the characteristics of the information and/or the information path. Application specific examples of flow control enforcement can be found in information protection software (e.g., guards, proxies, gateways and cross domain solutions) employing rule sets or establish configuration settings restricting information system services or provide message-filtering capability based on content (e.g., using key word searches or document characteristics). Applications providing information flow control capabilities must use explicit security attributes on information, source, and destination objects as a basis for flow control decisions.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000025 SRG-APP-000041 <GroupDescription></GroupDescription> SRG-APP-000041 Applications providing information flow control must provide the capability for privileged administrators to enable/disable security policy filters. <VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. From an application perspective, flow control is established once application data flow modeling has been completed. Data flow modeling can be described as: the process of identifying, modeling and documenting how data moves around an information system. Data flow modeling examines processes (activities that transform data from one form to another), data stores (the holding areas for data), external entities (what sends data into a system or receives data from a system), and data flows (routes by which data can flow). Once the application data flows have been identified, corresponding flow controls can be applied at the appropriate points. A few examples of flow control restrictions include: keeping export controlled information from being transmitted in the clear to the Internet and blocking information marked as classified but is being transported to an unapproved destination. Information flow control policies and enforcement mechanisms are commonly employed by organizations to control the flow of information between designated sources and destinations (e.g., networks, individuals, devices) within information systems and between interconnected systems. Flow control is based on the characteristics of the information and/or the information path. Application specific examples of flow control enforcement can be found in information protection software (e.g., guards, proxies, gateways and cross domain solutions) employing rule sets or establishing configuration settings restricting information system services or provide message-filtering capability based on content (e.g., using key word searches or document characteristics). A crucial part of any flow control solution is the ability to create policy filters. Policy filters serve to enact and enforce the organizational policy as it pertains to controlling data flow. Organization-defined security policy filters include, for example, file type checking filters, structured data filters, unstructured data filters, metadata content filters, and hidden content filters. - Structured data permits the interpretation of its content by virtue of elements that are understandable by an application and are indivisible. - Unstructured data refers to masses of (usually) digital information that does not have a data structure or does have a data structure that is not easily readable by a machine. Unstructured data consists of two basic categories: (i) bitmap objects that are inherently non language-based (i.e., image, video, or audio files); and (ii) textual objects based on a written or printed language (i.e., commercial off-the-shelf word processing documents, spreadsheets, or emails). Applications providing information flow control must provide the capability for a privileged administrator to enable/disable security policy filters.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000034 SRG-APP-000042 <GroupDescription></GroupDescription> SRG-APP-000042 Applications providing information flow controls must provide the capability for privileged administrators to configure security policy filters to support different organizational security policies. <VulnDiscussion> Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. From an application perspective, flow control is established once application data flow modeling has been completed. Data flow modeling can be described as: the process of identifying, modeling and documenting how data moves around an information system. Data flow modeling examines processes (activities that transform data from one form to another), data stores (the holding areas for data), external entities (what sends data into a system or receives data from a system), and data flows (routes by which data can flow). Once the application data flows have been identified, corresponding flow controls can be applied at the appropriate points. A few examples of flow control restrictions include: keeping export controlled information from being transmitted in the clear to the Internet and blocking information marked as classified but is being transported to an unapproved destination. Information flow control policies and enforcement mechanisms are commonly employed by organizations to control the flow of information between designated sources and destinations (e.g., networks, individuals, devices) within information systems and between interconnected systems. Flow control is based on the characteristics of the information and/or the information path. Application specific examples of flow control enforcement can be found in information protection software (e.g., guards, proxies, gateways and cross domain solutions) employing rule sets or establish configuration settings restricting information system services or provide message filtering capability based on content (e.g., using key word searches or document characteristics). A crucial part of any flow control solution is the ability to create policy filters. Policy filters serve to enact and enforce the organizational policy as it pertains to controlling data flow. Organization-defined security policy filters include, file type checking filters, structured data filters, unstructured data filters, metadata content filters, and hidden content filters. - Structured data permits the interpretation of its content by virtue of atomic elements that are understandable by an application and indivisible. - Unstructured data refers to masses of (usually) digital information does not have a data structure or does have a data structure that is not easily readable by a machine. Unstructured data consists of two basic categories: (i) bitmap objects that are inherently non language-based (i.e., image, video, or audio files); and (ii) textual objects based on a written or printed language (i.e., commercial off-the-shelf word processing documents, spreadsheets, or emails). Applications providing information flow control must provide the capability for privileged administrators to configure security policy filters to support different security policies.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000035 SRG-APP-000043 <GroupDescription></GroupDescription> SRG-APP-000043 Applications providing flow control must identify data type, specification and usage when transferring information between different security domains so policy restrictions may be applied. <VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. An example of flow control restrictions includes: keeping export controlled information from being transmitted in the clear to the Internet. Information flow control policies and enforcement mechanisms are commonly employed by organizations to control the flow of information between designated sources and destinations (e.g., users, networks, devices) within information systems and between interconnected systems. Application specific examples of flow control enforcement can be found in information protection software (e.g., guards, proxies, application layer gateways and cross domain solutions) employing rule sets or establish configuration settings restricting information system services or provide message-filtering capability based on content (e.g., using key word searches or document characteristics). Flow control is based on the characteristics of the information and/or the information path. Applications providing flow control must identify data type, specification, and usage when transferring information between different security domains so policy restrictions may be applied. A Security domain is defined as a domain implementing a security policy and is administered by a single authority. Data type, specification and usage includes, using file naming to reflect the type of data being transferred and limiting data transfer based on file type. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000218 SRG-APP-000044 <GroupDescription></GroupDescription> SRG-APP-000044 Applications, when transferring information between different security domains, must decompose information into policy-relevant subcomponents for submission to policy enforcement mechanisms. <VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. Specific examples of flow control enforcement can be found in boundary protection devices (e.g., proxies, gateways, guards, encrypted tunnels, firewalls, and routers) employing rule sets or establish configuration settings restricting information system services, provide a packet-filtering capability based on header information, or message-filtering capability based on content (e.g., using key word searches or document characteristics). Policy enforcement mechanisms include the filtering and/or sanitization rules applied to information prior to transfer to a different security domain. Parsing transfer files facilitates policy decisions on source, destination, certificates, classification, subject, attachments, and other information security-related component differentiators. Policy rules for cross domain transfers include, limitations on embedding components/information types within other components/information types, prohibiting more than two-levels of embedding, and prohibiting the transfer of archived information types.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000219 SRG-APP-000045 <GroupDescription></GroupDescription> SRG-APP-000045 Applications, when transferring information between different security domains, must implement or incorporate policy filters that constrain data object and structure attributes according to organizational security policy requirements. <VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. Specific examples of flow control enforcement can be found in boundary protection devices (e.g., proxies, gateways, guards, encrypted tunnels, firewalls, and routers) employing rule sets or establish configuration settings restricting information system services, provide a packet-filtering capability based on header information, or message-filtering capability based on content (e.g., using key word searches or document characteristics). Examples of constraints include ensuring: (i) character data fields only contain printable ASCII; (ii) character data fields only contain alpha-numeric characters; (iii) character data fields do not contain special characters; (iv) maximum field sizes and file lengths are enforced based upon organization-defined security policy.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001372 SRG-APP-000046 <GroupDescription></GroupDescription> SRG-APP-000046 Applications designed to control information flow must provide the ability to detect unsanctioned information being transmitted across security domains. <VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. Specific examples of flow control enforcement can be found in boundary protection devices (e.g., proxies, application layer gateways, cross domain guards, content filters) employing rule sets or establish configuration settings restricting information system services, provide a packet-filtering capability based on header information, or message-filtering capability based on content (e.g., using key word searches or document characteristics). Actions to support this requirement include, but are not limited to: checking all transferred information for malware, implementing dirty word list searches on transferred information, and applying the same protection measures to metadata (e.g., security attributes) that is applied to the information payload.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001373 SRG-APP-000047 <GroupDescription></GroupDescription> SRG-APP-000047 Applications must provide the ability to prohibit the transfer of unsanctioned information in accordance with security policy. <VulnDiscussion>The application enforces approved authorizations for controlling the flow of information within the system and between interconnected systems in accordance with applicable policy. Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. Specific examples of flow control enforcement can be found in boundary protection devices (e.g., proxies, gateways, guards, encrypted tunnels, firewalls, and routers) employing rule sets or establish configuration settings restricting information system services, provide a packet-filtering capability based on header information, or message-filtering capability based on content (e.g., using key word searches or document characteristics). Actions to support this requirement include, but are not limited to: checking all transferred information for malware, implementing dirty word list searches on transferred information, and applying the same protection measures to metadata (e.g., security attributes) that is applied to the information payload.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001374 SRG-APP-000048 <GroupDescription></GroupDescription> SRG-APP-000048 Applications must provide the ability to enforce security policies regarding information on interconnected systems. <VulnDiscussion>The application enforces approved authorizations for controlling the flow of information within the system and between interconnected systems in accordance with applicable policy. Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. Transferring information between interconnected information systems of differing security policies introduces risk that such transfers violate one or more policies. While security policy violations may not be absolutely prohibited, policy guidance from information owners/stewards is implemented at the policy enforcement point between the interconnected systems. Specific architectural solutions are mandated, when required, to reduce the potential for undiscovered vulnerabilities. Architectural solutions include: (i) prohibiting information transfers between interconnected systems (i.e., implementing access only, one way transfer mechanisms); (ii) employing hardware mechanisms to enforce unitary information flow directions; and (iii) implementing fully tested, re-grading mechanisms to reassign security attributes and associated security labels. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000221 SRG-APP-000049 <GroupDescription></GroupDescription> SRG-APP-000049 Applications must uniquely identify source domains for information transfer. <VulnDiscussion>The application enforces approved authorizations for controlling the flow of information within the system and between interconnected systems in accordance with applicable policy. Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. Specific examples of flow control enforcement can be found in boundary protection devices (e.g., proxies, gateways, guards, encrypted tunnels, firewalls, and routers) employing rule sets or establish configuration settings restricting information system services, provide a packet-filtering capability based on header information, or message-filtering capability based on content (e.g., using key word searches or document characteristics). Attribution, (e.g., the ability to attribute actions to certain individuals) is a critical component of a security concept of operations. The ability to identify source and destination points for information flowing in an information system, allows forensic reconstruction of events when required, and increases policy compliance by attributing policy violations to specific organizations/individuals. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001376 SRG-APP-000050 <GroupDescription></GroupDescription> SRG-APP-000050 Applications must uniquely authenticate source domains for information transfer. <VulnDiscussion>The information system enforces approved authorizations for controlling the flow of information within the system and between interconnected systems in accordance with applicable policy. Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. Specific examples of flow control enforcement can be found in boundary protection devices (e.g., proxies, gateways, guards, encrypted tunnels, firewalls, and routers) employing rule sets or establish configuration settings restricting information system services, provide a packet-filtering capability based on header information, or message-filtering capability based on content (e.g., using key word searches or document characteristics). Attribution, (e.g., the ability to attribute actions to certain individuals) is a critical component of a security concept of operations. The ability to identify source and destination points for information flowing in an information system, allows forensic reconstruction of events when required, and increases policy compliance by attributing policy violations to specific organizations/individuals. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001377 SRG-APP-000051 <GroupDescription></GroupDescription> SRG-APP-000051 Applications must uniquely identify destination domains for information transfer. <VulnDiscussion>The application enforces approved authorizations for controlling the flow of information within the system and between interconnected systems in accordance with applicable policy. Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. Specific examples of flow control enforcement can be found in boundary protection devices (e.g., proxies, gateways, guards, encrypted tunnels, firewalls, and routers) employing rule sets or establish configuration settings restricting information system services, provide a packet-filtering capability based on header information, or message-filtering capability based on content (e.g., using key word searches or document characteristics). Attribution, (e.g., the ability to attribute actions to certain individuals) is a critical component of a security concept of operations. The ability to identify source and destination points for information flowing in an information system, allows forensic reconstruction of events when required, and increases policy compliance by attributing policy violations to specific organizations/individuals. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001555 SRG-APP-000052 <GroupDescription></GroupDescription> SRG-APP-000052 The application must bind security attributes to information to facilitate information flow policy enforcement. <VulnDiscussion>The application enforces approved authorizations for controlling the flow of information within the system and between interconnected systems in accordance with applicable policy. Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. Attribution is a critical component of a security concept of operations. The ability to identify source and destination points for information flowing in an information system, allows forensic reconstruction of events when required, and increases policy compliance by attributing policy violations to specific organizations/individuals. Binding security attributes to information allows policy enforcement mechanisms to act on that information and enforce policy. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000223 SRG-APP-000053 <GroupDescription></GroupDescription> SRG-APP-000053 Applications providing information flow control must track problems associated with the binding of security attributes to data. <VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. Attribution, (e.g., the ability to attribute actions to certain individuals) is a critical component of a security concept of operations. The ability to identify source and destination points for information flowing in an information system, allows forensic reconstruction of events when required, and increases policy compliance by attributing policy violations to specific organizations/individuals. In order to identify problems that may occur when binding security attributes to information, tracking and or auditing of these binding events must take place.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000224 SRG-APP-000054 <GroupDescription></GroupDescription> SRG-APP-000054 Applications must enforce information flow control using protected processing domains (e.g., domain type-enforcement) as a basis for flow control decisions. <VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. Information flow enforcement mechanisms compare security attributes on all information (data content and data structure), source and destination objects, and respond appropriately (e.g., block, quarantine, alert administrator) when the mechanisms encounter information flows not explicitly allowed by the information flow policy. Information flow enforcement using explicit security attributes can be used, for example, to control the release of certain types of information. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000026 SRG-APP-000055 <GroupDescription></GroupDescription> SRG-APP-000055 Applications must enforce information flow using dynamic control based on policy that allows or disallows information flow based on changing conditions or operational considerations. <VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. A few examples of flow control restrictions include: keeping export controlled information from being transmitted in the clear to the Internet, blocking outside traffic claiming to be from within the organization and not passing any web requests to the Internet that are not from the internal web proxy. Information flow control policies and enforcement mechanisms are commonly employed by organizations to control the flow of information between designated sources and destinations (e.g., networks, individuals, devices) within information systems and between interconnected systems. Flow control is based on the characteristics of the information and/or the information path. Flow control is also based on the characteristics of the information and/or the information path. Specific examples of flow control enforcement can be found in boundary protection devices (e.g., proxies, gateways, guards, encrypted tunnels, firewalls, and routers) employing rule sets or establish configuration settings restricting information system services, provide a packet-filtering capability based on header information, or message-filtering capability based on content (e.g., using key word searches or document characteristics). </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000027 SRG-APP-000056 <GroupDescription></GroupDescription> SRG-APP-000056 Applications must prevent encrypted data from bypassing content-checking mechanisms. <VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. Information flow enforcement mechanisms compare security attributes on all information (data content and data structure), source and destination objects, and respond appropriately (e.g., block, quarantine, alert administrator) when the mechanisms encounter information flows not explicitly allowed by the information flow policy. When data is encrypted, devices and software designed to examine data content so as to detect attacks or malicious code are unable to accomplish the task unless they are capable of unencrypting the data. Example includes decrypting email in order to scan attachments.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000028 SRG-APP-000057 <GroupDescription></GroupDescription> SRG-APP-000057 Applications must enforce organization-defined limitations on the embedding of data types within other data types. <VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. Information flow enforcement mechanisms compare security attributes on all information (data content and data structure), source and destination objects, and respond appropriately (e.g., block, quarantine, alert administrator) when the mechanisms encounter information flows not explicitly allowed by the information flow policy. Embedding of data within other data is often used for the surreptitious transfer of data. For example, embedding data within an image file (e.g., .jpg) is referred to as Steganography and is used to circumvent protections in place to protect information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000029 SRG-APP-000058 <GroupDescription></GroupDescription> SRG-APP-000058 Applications must enforce information flow control on metadata. <VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. Information flow enforcement mechanisms compare security attributes on all information (data content and data structure), source and destination objects, and respond appropriately (e.g., block, quarantine, alert administrator) when the mechanisms encounter information flows not explicitly allowed by the information flow policy. Metadata is defined as data providing information about one or more other pieces of data such as; purpose of the data, author/creator of the data, network location of where data was created, and application specific data information. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000030 SRG-APP-NA <GroupDescription></GroupDescription> SRG-APP-NA The information system must enforce organization-defined one-way flows using hardware mechanisms. <VulnDiscussion>This is a requirement to enforce information flow with a hardware device or mechanism. By definition, this is not related to software applications. This is expected to be addressed via hardware. Does not apply to applications.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000031 SRG-APP-000059 <GroupDescription></GroupDescription> SRG-APP-000059 Applications must use security policy filters as a basis for making information flow control decisions. <VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. Information flow enforcement mechanisms compare security attributes on all information (data content and data structure), source and destination objects, and respond appropriately (e.g., block, quarantine, alert administrator) when the mechanisms encounter information not explicitly allowed by the information flow policy. Security policy filters are defined by the organization and include, dirty word filters, file type checking filters, structured data filters, unstructured data filters, metadata content filters, and hidden content filters. - Structured data typically describes data intended for storage in a data management system such as a relational database. - Unstructured data refers to masses of digital information that do not have a data structure such as word processing documents, email, pictures, audio, and video. - In the case of unstructured data, metadata is considered to be data about the data in question. - In the case of structured data, metadata is considered to be data about the containers of the data. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000032 SRG-APP-000060 <GroupDescription></GroupDescription> SRG-APP-000060 Applications providing information flow control must uniquely authenticate destination domains when transferring information. <VulnDiscussion>Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. Specific examples of flow control enforcement can be found in boundary protection devices (e.g., proxies, application gateways, guards, cross domain systems) employing rule sets or establish configuration settings restricting information system services, provide a packet-filtering capability based on header information, or message-filtering capability based on content (e.g., using key word searches or document characteristics). Attribution, (e.g., the ability to attribute actions to individuals), processes or systems, is a critical component of a security concept of operations. The ability to identify source and destination points for information flowing in an information system, allows forensic reconstruction of events when required, and increases policy compliance by attributing policy violations to specific organizations/individuals. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001556 SRG-APP-000061 <GroupDescription></GroupDescription> SRG-APP-000061 In support of information flow requirements, applications must track problems associated with information transfer. <VulnDiscussion>When an application transfers data, there is the chance an error or problem with the data transfer may occur. Applications need to track failures and any problems encountered when performing data transfers so problems can be identified and remediated. Some potential issues with a failed or problematic data transfer include: leaving sensitive data in a processing queue indefinitely, partial or incomplete data transfers, and corrupted data transfers. Tracking problems with data transfers also serves to create a forensic record that can be retained to assist in investigations regarding the flow of application data.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001557 SRG-APP-000062 <GroupDescription></GroupDescription> SRG-APP-000062 Applications must support organizational requirements to implement separation of duties through assigned information access authorizations. <VulnDiscussion>Separation of duties is a prevalent Information Technology control that is implemented at different layers of the information system including the operating system and in applications. It serves to eliminate or reduce the possibility that a single user may carry out a prohibited action. Separation of duties requires that the person accountable for approving an action is not the same person who is tasked with implementing or carrying out that action. Additionally, the person or entity accountable for monitoring the activity must be separate as well. To meet this requirement, applications, when applicable, shall be divided where functionality is based on roles and duties. Examples of separation of duties include: (i) mission functions and distinct information system support functions are divided among different individuals/roles; (ii) different individuals perform information system support functions (e.g., system management, systems programming, configuration management, quality assurance and testing, network security); (iii) security personnel who administer access control functions do not administer audit functions; and (iv) different administrator accounts for different roles. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000037 SRG-APP-000063 <GroupDescription></GroupDescription> SRG-APP-000063 Application users must utilize a separate, distinct administrative account when accessing application security functions or security-relevant information. Non-privileged accounts must be utilized when accessing non-administrative application functions. The application must provide this functionality itself or leverage an existing technology providing this capability. <VulnDiscussion>This requirement is intended to limit exposure due to operating from within a privileged account or role. The inclusion of role is intended to address those situations where an access control policy such as Role Based Access Control (RBAC) is being implemented and where a change of role provides the same degree of assurance in the change of access authorizations for both the user and all processes acting on behalf of the user as would be provided by a change between a privileged and non-privileged account. Audit of privileged activity may require physical separation employing information systems on which the user does not have privileged access. To limit exposure and provide forensic history of activity when operating from within a privileged account or role, the application must support organizational requirements that users of information system accounts, or roles, with access to organization-defined list of security functions or security-relevant information, use non-privileged accounts, or roles, when accessing other (non-security) system functions. If feasible, applications should provide access logging that ensures users who are granted a privileged role (or roles) have their privileged activity logged. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000040 SRG-APP-000064 <GroupDescription></GroupDescription> SRG-APP-000064 Applications must be able to function within separate processing domains (virtualized systems), when specified, so as to enable finer-grained allocation of user privileges. <VulnDiscussion>Applications must employ the concept of least privilege, allowing only authorized accesses for users (and processes acting on behalf of users) which are necessary to accomplish assigned tasks in accordance with organizational missions and business functions. Employing virtualization techniques to allow greater privilege within a virtual machine, while restricting privilege to the underlying actual machine is an example of providing separate processing domains for finer-grained allocation of user privileges.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000226 SRG-APP-000095 <GroupDescription></GroupDescription> SRG-APP-000095 The application must produce audit records containing sufficient information to establish what type of events occurred. <VulnDiscussion>Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes: time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000130 SRG-APP-000096 <GroupDescription></GroupDescription> SRG-APP-000096 The application must produce audit records containing sufficient information to establish when (date and time) the events occurred. <VulnDiscussion>Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes: time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000131 SRG-APP-NA <GroupDescription></GroupDescription> SRG-APP-NA The information system must provide additional protection for mobile devices accessed via login by purging information from the device after organization-defined number of consecutive, unsuccessful login attempts to the mobile device. <VulnDiscussion>Mobile devices present additional risks related to attempted unauthorized access. If they are lost, stolen or misplaced, attempts can be made to unlock the device by guessing the pin. In order to address this risk, mobile devices shall provide additional protection enabling the device to automatically wipe itself clean and purge itself of any and all data. This does not apply to applications. This is a requirement for Mobile Devices (smart phones, PDAs, etc) to be able to purge themselves of data if x number of failed login attempts occur. This requirement applies only to mobile devices for which a login occurs (e.g., personal digital assistants and smart phones) and not to mobile devices accessed without a login such as removable media. In certain situations, this requirement may not apply to mobile devices if the information on the device is encrypted with sufficiently strong encryption mechanisms, making purging unnecessary. The login is to the mobile device, not to any one account on the device. Therefore, a successful login to any account on the mobile device resets the unsuccessful login count to zero. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001383 SRG-APP-000097 <GroupDescription></GroupDescription> SRG-APP-000097 The application must produce audit records containing sufficient information to establish where the events occurred. <VulnDiscussion>Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes: time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. Without sufficient information establishing where the audit events occurred, investigation into the cause of events is severely hindered.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000132 SRG-APP-000098 <GroupDescription></GroupDescription> SRG-APP-000098 The application must produce audit records containing sufficient information to establish the sources of the events. <VulnDiscussion>Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes but is not limited to: time stamps, source and destination IP addresses, user/process identifiers, event descriptions, application specific events, success/fail indications, filenames involved, access control or flow control rules invoked. Without information establishing the source of activity, the value of audit records from a forensics perspective is questionable.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000133 SRG-APP-000065 <GroupDescription></GroupDescription> SRG-APP-000065 Applications must have the capability to limit the number of failed login attempts based upon an organization defined number of consecutive invalid attempts occurring within an organization defined time period. <VulnDiscussion>Anytime an authentication method is exposed so as to allow for the utilization of an application, there is a risk that attempts will be made to obtain unauthorized access. To defeat these attempts, organizations define the number of times a user account may consecutively fail a login attempt. The organization also defines the period of time in which these consecutive failed attempts may occur. By limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced. Limits are imposed by locking the account. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000044 SRG-APP-000066 <GroupDescription></GroupDescription> SRG-APP-000066 The application must enforce the organization-defined time period during which the limit of consecutive invalid access attempts by a user is counted. <VulnDiscussion>Anytime an authentication method is exposed, so as to allow for the utilization of an application, there is a risk that attempts will be made to obtain unauthorized access. To aid in defeating these attempts, organizations define the number of times that a user account may consecutively fail a login attempt. The organization also defines the period of time in which these consecutive failed attempts may occur. By limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced. Limits are imposed by locking the account. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001452 SRG-APP-000067 <GroupDescription></GroupDescription> SRG-APP-000067 Applications, when the maximum number of unsuccessful attempts are exceeded, must automatically lock the account/node for an organization-defined time period or lock the account/node until released by an administrator IAW organizational policy. <VulnDiscussion>Anytime an authentication method is exposed so as to allow for the utilization of an application, there is a risk that attempts will be made to obtain unauthorized access. To defeat these attempts, organizations define the number of times a user account may consecutively fail a login attempt. The organization also defines the period of time in which these consecutive failed attempts may occur. By limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced. Limits are imposed by locking the account. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000047 SRG-APP-000068 <GroupDescription></GroupDescription> SRG-APP-000068 Applications must display an approved system use notification message or banner before granting access to the system. <VulnDiscussion>Applications are required to display an approved system use notification message or banner before granting access to the system providing privacy and security notices consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance and states that: (i) users are accessing a U.S. Government information system; (ii) system usage may be monitored, recorded, and subject to audit; (iii) unauthorized use of the system is prohibited and subject to criminal and civil penalties; and (iv) the use of the system indicates consent to monitoring and recording. System use notification messages can be implemented in the form of warning banners displayed when individuals log in to the information system. System use notification is intended only for information system access including an interactive login interface with a human user and is not intended to require notification when an interactive interface does not exist. Use this banner for desktops, laptops, and other devices accommodating banners of 1300 characters. The banner shall be implemented as a click-through banner at logon (to the extent permitted by the operating system), meaning it prevents further activity on the information system unless and until the user executes a positive action to manifest agreement by clicking on a box indicating “OKâ€. "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." For Blackberries and other PDAs/PEDs with severe character limitations use the following: "I've read & consent to terms in IS user agreem't." </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000048 SRG-APP-000099 <GroupDescription></GroupDescription> SRG-APP-000099 The application must produce audit records that contain sufficient information to establish the outcome (success or failure) of the events. <VulnDiscussion>Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes but is not limited to: time stamps, source and destination IP addresses, user/process identifiers, event descriptions, application specific events, success/fail indications, filenames involved, access control or flow control rules invoked. Success and failure indicators ascertain the outcome of a particular event. As such, they also provide a means to measure the impact of an event and help authorized personnel to determine the appropriate response.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000134 SRG-APP-000069 <GroupDescription></GroupDescription> SRG-APP-000069 The application must retain the notification message or banner on the screen until users take explicit actions to logon to or further access. <VulnDiscussion>To establish acceptance of system usage policy, a click-through banner at application logon is required. The banner shall prevent further activity on the application unless and until the user executes a positive action to manifest agreement by clicking on a box indicating "OK". The text of this banner should be customizable in the event of future user agreement changes. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000050 SRG-APP-000100 <GroupDescription></GroupDescription> SRG-APP-000100 The application must produce audit records containing sufficient information to establish the identity of any user/subject or process associated with the event. <VulnDiscussion>Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes: time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001487 SRG-APP-000070 <GroupDescription></GroupDescription> SRG-APP-000070 Applications must display an approved system use notification message or banner before granting access to the system. <VulnDiscussion>Applications must display an approved system use notification message or banner before granting access to the system. The banner shall be formatted in accordance with the DoD policy "Use of DoD Information Systems - Standard Consent and User Agreement". The message banner shall provide privacy and security notices consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance and shall state that: (i) users are accessing a U.S. Government information system; (ii) system usage may be monitored, recorded, and is subject to audit; (iii) unauthorized use of the system is prohibited and subject to criminal and civil penalties; (iv) the use of the system indicates consent to monitoring and recording; (v) in the notice given to public users of the information system, shall provide a description of the authorized uses of the system. System use notification messages are implemented in the form of warning banners displayed when individuals log in to the information system. System use notification is intended only for information system access including an interactive login interface with a human user and is not intended to require notification when an interactive interface does not exist. The banner shall state: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001384 CCI-001385 CCI-001386 CCI-001387 CCI-001388 SRG-APP-000101 <GroupDescription></GroupDescription> SRG-APP-000101 Applications must include organization-defined additional, more detailed information in the audit records for audit events identified by type, location, or subject. <VulnDiscussion>Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes: time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. In addition, the application must have the capability to include organization-defined additional, more detailed information in the audit records for audit events. These events may be identified by type, location, or subject. An example of detailed information that the organization may require in audit records is full-text recording of privileged commands or the individual identities of group account users.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000135 SRG-APP-000102 <GroupDescription></GroupDescription> SRG-APP-000102 To support DoD requirements to centrally manage the content of audit records, applications must provide the ability to write specified audit record content to a centralized audit log repository. <VulnDiscussion>Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes but is not limited: time stamps, source and destination IP addresses, user/process identifiers, event descriptions, application specific events, success/fail indications, filenames involved, access control or flow control rules invoked. Centralized management of audit records and logs provides for efficiency in maintenance and management of records, as well as the backup and archiving of those records. When organizations define application components requiring centralized audit log management, applications need to support that requirement.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000136 SRG-APP-000075 <GroupDescription></GroupDescription> SRG-APP-000075 Applications upon successful logon, must display to the user the date and time of the last logon (access). <VulnDiscussion>Users need to be aware of activity that occurs regarding their application account. Providing users with information regarding the date and time of their last successful login allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators. This requirement is intended to cover both traditional interactive logons to information systems and general accesses to information systems that occur in other types of architectural configurations (e.g., service oriented architectures). </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000052 SRG-APP-000076 <GroupDescription></GroupDescription> SRG-APP-000076 In order to inform the user of failed login attempts made with the users account, the application upon successful logon/access must display to the user the number of unsuccessful logon/access attempts since the last successful logon/access. <VulnDiscussion>Users need to be aware of activity that occurs regarding their application account. Providing users with information regarding the number of unsuccessful attempts made to login to their account allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators. This requirement is intended to cover both traditional logons to information systems and general accesses to information systems that occur in other types of architectural configurations (e.g., service oriented architectures). </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000053 SRG-APP-000072 <GroupDescription></GroupDescription> SRG-APP-000072 Applications must allocate audit record storage capacity. <VulnDiscussion>In order to ensure applications have a sufficient storage capacity in which to write the audit logs, applications need to be able to allocate audit record storage capacity. The task of allocating audit record storage capacity is usually performed during initial installation of the application and is closely associated with the DBA and system administrator roles. The DBA or system administrator will usually coordinate the allocation of physical drive space with the application owner/installer and the application will prompt the installer to provide the capacity information, the physical location of the disk, or both.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000137 SRG-APP-000077 <GroupDescription></GroupDescription> SRG-APP-000077 In order to inform the user of the number of successful login attempts made with the users account, the application must notify the user of the number of successful logins/accesses occurring during an organization-defined time period. <VulnDiscussion>Users need to be aware of activity that occurs regarding their application account. Providing users with information regarding the number of successful attempts made to login to their account allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators. This requirement is intended to cover both traditional logons to information systems and general accesses to information systems occurring in other types of architectural configurations (e.g., service oriented architectures). </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001391 SRG-APP-000078 <GroupDescription></GroupDescription> SRG-APP-000078 The application must notify the user of the number of unsuccessful login/access attempts occurring during an organization-defined time period. <VulnDiscussion>Users need to be aware of activity that occurs regarding their application account. Providing users with information regarding the number of unsuccessful attempts made to login to their account allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators. This requirement is intended to cover both traditional logons to information systems and general accesses to information systems occurring in other types of architectural configurations (e.g., service oriented architectures). In order to inform the user of the number of unsuccessful login attempts made with the users account.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001392 SRG-APP-000079 <GroupDescription></GroupDescription> SRG-APP-000079 Applications must notify users of organization-defined security-related changes to the user’s account occurring during the organization-defined time period. <VulnDiscussion>Some organizations may define certain security events as events requiring user notification. An organization may define an event such as a password change to a user's account occurring outside of normal business hours as a security related event requiring that the application user be notified. In those instances, where organizations define such events, the application must notify the affected user or users.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001395 SRG-APP-000071 <GroupDescription></GroupDescription> SRG-APP-000071 Applications must configure their auditing to reduce the likelihood of storage capacity being exceeded. <VulnDiscussion>Applications need to be cognizant of potential audit log storage capacity issues. During the installation and/or configuration process, applications should detect and determine if adequate storage capacity has been allocated for audit logs. During the installation process, a notification may be provided to the installer indicating, based on the auditing configuration chosen and the amount of storage space allocated for audit logs, the amount of storage capacity available is not sufficient enough to meet storage requirements. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000138 SRG-APP-000080 <GroupDescription></GroupDescription> SRG-APP-000080 The application must protect against an individual falsely denying having performed a particular action. <VulnDiscussion>Non-repudiation of actions taken is required in order to maintain application integrity. Examples of particular actions taken by individuals include creating information, sending a message, approving information (e.g., indicating concurrence or signing a contract), and receiving a message. Non-repudiation protects individuals against later claims by an author of not having authored a particular document, a sender of not having transmitted a message, a receiver of not having received a message, or a signatory of not having signed a document. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000166 SRG-APP-000103 <GroupDescription></GroupDescription> SRG-APP-000103 Applications themselves, or the logging mechanism the application utilizes, must provide a warning when allocated audit record storage volume reaches an organization-defined percentage of maximum audit record storage capacity. <VulnDiscussion>It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Audit processing failures include: software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. If audit log capacity were to be exceeded then events subsequently occurring will not be recorded. Organizations shall define a maximum allowable percentage of storage capacity serving as an alarming threshold (e.g., application has exceeded 80 % of log storage capacity allocated) at which time the application or the logging mechanism the application utilizes will provide a warning to the appropriate personnel. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000143 SRG-APP-000081 <GroupDescription></GroupDescription> SRG-APP-000081 The application must associate the identity of the information producer with the information. <VulnDiscussion>Non-repudiation supports audit requirements to provide the appropriate organizational officials the means to identify who produced specific information in the event of an information transfer. The nature and strength of the binding between the information producer and the information are determined and approved by the appropriate organizational officials based on the security categorization of the information and relevant risk factors. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001338 SRG-APP-000082 <GroupDescription></GroupDescription> SRG-APP-000082 Applications must validate the binding of the information producer’s identity to the information. <VulnDiscussion>Non-repudiation protects individuals against later claims by an author of not having authored a particular document, a sender of not having transmitted a message, a receiver of not having received a message, or a signatory of not having signed a document. This non-repudiation control enhancement is intended to mitigate the risk that information gets modified between production and review. The validation of bindings can be achieved, for example, by the use of cryptographic checksums. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001339 SRG-APP-000104 <GroupDescription></GroupDescription> SRG-APP-000104 The application must provide a real-time alert when organization-defined audit failure events occur. <VulnDiscussion>It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Audit processing failures include: software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. Organizations shall define audit failure events requiring an application to send an alarm. When those defined events occur, the application will provide a real-time alert to the appropriate personnel.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000144 SRG-APP-000083 <GroupDescription></GroupDescription> SRG-APP-000083 Applications must maintain reviewer/releaser identity and credentials within the established chain of custody for all information reviewed or released. <VulnDiscussion>Non-repudiation protects individuals against later claims by an author of not having authored a particular document, a sender of not having transmitted a message, a receiver of not having received a message, or a signatory of not having signed a document. Non-repudiation services can be used to determine if information originated from an individual, or if an individual took specific actions (e.g., sending an email, signing a contract, approving a procurement request) or received specific information. Non-repudiation services are obtained by employing various techniques or mechanisms (e.g., digital signatures, digital message receipts). When it comes to data review and data release, there must be a correlation between the data that is reviewed and the person who performs the review. If the reviewer is a human or if the review function is automated but separate from the release/transfer function, the application associates the identity of the reviewer of the information to be released with the information and the information label. In the case of human reviews, this requirement provides appropriate organizational officials the means to identify who reviewed and released the information. In the case of automated reviews, this control enhancement helps ensure only approved review functions are employed. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001340 SRG-APP-000084 <GroupDescription></GroupDescription> SRG-APP-000084 The application must validate the binding of the reviewer’s identity to the information at the transfer/release point prior to release/transfer from one security domain to another security domain. <VulnDiscussion>This non-repudiation control enhancement is intended to mitigate the risk that information could be modified between review and transfer/release particularly when transfer is occurring between security domains. In those instances where the application is transferring data intended for release across security domains, the application must validate the binding of the reviewer’s identity to the information at the transfer/release point prior to release/transfer from one security domain to another security domain.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001341 SRG-APP-000086 <GroupDescription></GroupDescription> SRG-APP-000086 The application must provide the capability to compile audit records from multiple components within the system into a system-wide (logical or physical) audit trail that is time-correlated to within organization-defined level of tolerance. <VulnDiscussion>Audit generation and audit records can be generated from various components within the information system. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records (i.e., auditable events). The events occurring must be time-correlated on order to conduct accurate forensic analysis. In addition, the correlation must meet a certain tolerance criteria. For instance, the organization may define that the time stamps of different audited events must not differ by any amount greater than ten seconds.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000174 SRG-APP-000088 <GroupDescription></GroupDescription> SRG-APP-000088 The application must produce a system-wide (logical or physical) audit trail composed of audit records in a standardized format. <VulnDiscussion>Audits records can be generated from various components within the information system. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records (i.e., auditable events). </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001353 SRG-APP-000089 <GroupDescription></GroupDescription> SRG-APP-000089 The application must provide audit record generation capability for defined auditable events within defined application components. <VulnDiscussion>Audit records can be generated from various components within the information system (e.g., network interface, hard disk, modem etc.). From an application perspective, certain specific application functionalities may be audited as well. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records (i.e., auditable events, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked). Organizations define which application components shall provide auditable events. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000169 SRG-APP-000090 <GroupDescription></GroupDescription> SRG-APP-000090 The application must allow designated organizational personnel to select which auditable events are to be audited by specific components of the system. <VulnDiscussion>Audit records can be generated from various components within the information system, such as network interfaces, hard disks, modems, etc. From an application perspective, certain specific application functionalities may be audited, as well. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records (i.e., auditable events, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked). Organizations may define the organizational personal accountable for determining which application components shall provide auditable events.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000171 SRG-APP-000091 <GroupDescription></GroupDescription> SRG-APP-000091 Applications must generate audit records for the DoD selected list of auditable events. <VulnDiscussion>Audit records can be generated from various components within the information system. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records (i.e., auditable events). DoD shall select the list of auditable events and applications must generate audit records for those events.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000172 SRG-APP-000092 <GroupDescription></GroupDescription> SRG-APP-000092 The application must initiate session auditing upon start up. <VulnDiscussion>Session auditing activities are developed, integrated, and used in consultation with legal counsel in accordance with applicable federal laws, Executive Orders, directives, policies, or regulations. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001464 SRG-APP-000093 <GroupDescription></GroupDescription> SRG-APP-000093 The application must provide the capability to capture, record, and log all content related to a user session. <VulnDiscussion>While a great deal of effort is made to secure applications so as to prevent unauthorized access, in certain instances there can be valid requirements to capture, record, and log all content related to a particular user's application session. These instances are reserved for monitoring or investigative purposes supported through policy and are officially sanctioned. Session auditing activities are developed, integrated, and used in consultation with legal counsel in accordance with applicable federal laws, Executive Orders, directives, policies, or regulations. These monitoring events occur at the application layer and as such maybe required to be conducted at a host system however in some cases network monitoring may be involved as well. Applications must support valid monitoring requirement capabilities performed in accordance with applicable federal laws, Executive Orders, directives, policies, or regulations. This includes the capability to capture, record, and log all content related to an established user session. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001462 SRG-APP-000094 <GroupDescription></GroupDescription> SRG-APP-000094 The application must provide the capability to remotely view/hear all content related to an established user session in real time. <VulnDiscussion>While a great deal of effort is made to secure applications so as to prevent unauthorized access, in certain instances there can be valid requirements to listen/hear or view all content related to a particular user's application session in real time as it occurs. These instances are reserved for monitoring or investigative purposes supported through policy and are officially sanctioned. Session auditing activities are developed, integrated, and used in consultation with legal counsel in accordance with applicable federal laws, Executive Orders, directives, policies, or regulations. These monitoring events occur at the application layer and as such, may be required to be conducted at a host system however in some cases network monitoring may be involved as well. Applications must support valid monitoring requirement capabilities performed in accordance with applicable federal laws, Executive Orders, directives, policies, or regulations. This includes the capability to remotely view/hear all content related to an established user session in real time. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001463 SRG-APP-000156 <GroupDescription></GroupDescription> SRG-APP-000156 The application must use organization-defined replay-resistant authentication mechanisms for network access to privileged accounts. <VulnDiscussion>An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. Techniques used to address this include protocols using nonce's (e.g., numbers generated for a specific one time use) or challenges (e.g., TLS, WS_Security), and time synchronous or challenge-response one-time authenticators. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000774 SRG-APP-000157 <GroupDescription></GroupDescription> SRG-APP-000157 The application must use organization-defined replay-resistant authentication mechanisms for network access to non-privileged accounts. <VulnDiscussion>An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. Techniques used to address this include protocols using nonce's (e.g., numbers generated for a specific one time use) or challenges (e.g., TLS, WS_Security), and time synchronous or challenge-response one-time authenticators. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000776 SRG-APP-000158 <GroupDescription></GroupDescription> SRG-APP-000158 Applications required to identify devices must uniquely identify and authenticate an organization-defined list of specific and/or types of devices before establishing a connection. <VulnDiscussion>Device authentication is a solution enabling an organization to manage both users and devices. It is an additional layer of authentication ensuring only specific pre-authorized devices operated by specific pre-authorized users can access the network. Device authentication requires unique identification and authentication that may be defined by type, by specific device, or by a combination of type and device, as deemed appropriate by the organization. The application typically uses either shared known information (e.g., Media Access Control [MAC] or Transmission Control Protocol/Internet Protocol [TCP/IP] addresses) for identification or an organizational authentication solution (e.g., IEEE 802.1x and Extensible Authentication Protocol [EAP], Radius server with EAP-Transport Layer Security [TLS] authentication, Kerberos) to identify and authenticate devices on local and/or wide area networks. The required strength of the device authentication mechanism is determined by the security categorization of the information system. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000778 SRG-APP-000159 <GroupDescription></GroupDescription> SRG-APP-000159 Applications managing devices must authenticate devices before establishing remote network connections using bidirectional authentication between devices that are cryptographically based. <VulnDiscussion>Device authentication is a solution enabling an organization to manage devices. It is an additional layer of authentication ensuring only specific pre-authorized devices operated by specific pre-authorized users can access the network. Device authentication requires unique identification and authentication that may be defined by type, by specific device, or by a combination of type and device, as deemed appropriate by the organization. The application typically uses either shared known information (e.g., Media Access Control [MAC] or Transmission Control Protocol/Internet Protocol [TCP/IP] addresses) for identification or an organizational authentication solution (e.g., IEEE 802.1x and Extensible Authentication Protocol [EAP], Radius server with EAP-Transport Layer Security [TLS] authentication, Kerberos) to identify and authenticate devices on local and/or wide area networks. The required strength of the device authentication mechanism is determined by the security categorization of the information system. Remote network connection is any connection with a device communicating through an external network (e.g., the Internet). Bidirectional authentication provides a means for both connecting parties to mutually authenticate one another and cryptographically based authentication provides a secure means of authenticating without the use of clear text passwords. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000779 SRG-APP-000160 <GroupDescription></GroupDescription> SRG-APP-000160 Applications managing network connections for devices must authenticate devices before establishing wireless network connections by using bidirectional authentication that is cryptographically based. <VulnDiscussion>Device authentication is a solution enabling an organization to manage devices. It is an additional layer of authentication ensuring only specific pre-authorized devices operated by specific pre-authorized users can access the network. Device authentication requires unique identification and authentication that may be defined by type, by specific device, or by a combination of type and device, as deemed appropriate by the organization. The application typically uses either shared known information (e.g., Media Access Control [MAC] or Transmission Control Protocol/Internet Protocol [TCP/IP] addresses) for identification or an organizational authentication solution (e.g., IEEE 802.1x and Extensible Authentication Protocol [EAP], Radius server with EAP-Transport Layer Security [TLS] authentication, Kerberos) to identify and authenticate devices on local and/or wide area networks. The required strength of the device authentication mechanism is determined by the security categorization of the information system. Bidirectional authentication provides a means for both connecting parties to mutually authenticate one another and cryptographically based authentication provides a secure means of authenticating without the use of clear text passwords. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000780 SRG-APP-000161 <GroupDescription></GroupDescription> SRG-APP-000161 Applications managing network connectivity must have the capability to authenticate devices before establishing network connections by using bidirectional authentication that is cryptographically based. <VulnDiscussion>Device authentication is a solution enabling an organization to manage both users and devices. It is an additional layer of authentication ensuring only specific pre-authorized devices operated by specific pre-authorized users can access the network. Device authentication requires unique identification and authentication that may be defined by type, by specific device, or by a combination of type and device as deemed appropriate by the organization. The application typically uses either shared known information (e.g., Media Access Control [MAC] or Transmission Control Protocol/Internet Protocol [TCP/IP] addresses) for identification or an organizational authentication solution (e.g., IEEE 802.1x and Extensible Authentication Protocol [EAP], Radius server with EAP-Transport Layer Security [TLS] authentication, Kerberos) to identify and authenticate devices on local and/or wide area networks. The required strength of the device authentication mechanism is determined by the security categorization of the information system. Bidirectional authentication provides a means for both connecting parties to mutually authenticate one another and cryptographically based authentication provides a secure means of authenticating without the use of clear text passwords. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000781 SRG-APP-000162 <GroupDescription></GroupDescription> SRG-APP-000162 Web services applications establishing identities at run-time for previously unknown entities must dynamically manage identifiers, attributes, and associated access authorizations. <VulnDiscussion>Web services are web applications providing a method of communication between two or more different electronic devices. They are normally used by applications to provide each other with data. The W3C defines a web service as: "a software system designed to support interoperable machine to machine interaction over a network. It has an interface described in a machine processable format (specifically Web Services Description Language or WSDL). Other systems interact with the web service in a manner prescribed by its description using SOAP messages typically conveyed using HTTP with an XML serialization in conjunction with other web-related standards". Web services provide different challenges in managing access than what is presented by typical user based applications. In contrast to conventional access control approaches which employ static information system accounts and predefined sets of user privileges, many service-oriented architecture implementations rely on run time access control decisions facilitated by dynamic privilege management. While user identities remain relatively constant over time, user privileges may change more frequently based on the ongoing mission/business requirements and operational needs of the organization. In contrast to conventional approaches to identification and authentication which employ static information system accounts for preregistered users, many service-oriented architecture implementations rely on establishing identities at run time for entities that were previously unknown. Dynamic establishment of identities and association of attributes and privileges with these identities are anticipated and provisioned. Pre-established trust relationships and mechanisms with appropriate authorities to validate identities and related credentials are essential.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000802 SRG-APP-000163 <GroupDescription></GroupDescription> SRG-APP-000163 Applications must support organizational requirements to disable user accounts after an organization-defined time period of inactivity. <VulnDiscussion>Users are often the first line of defense within an application. Active users take notice of system and data conditions and are usually the first to notify systems administrators when they notice a system or application related anomaly, particularly if the anomaly is related to their own account. Inactive user accounts pose a risk to systems and applications. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. Attackers that are able to exploit an inactive user account can potentially obtain and maintain undetected access to an application. Applications need to track periods of user inactivity and disable application accounts after an organization-defined period of inactivity. Such a process greatly reduces the risk that accounts will be misused, hijacked, or will have data compromised. Management of user identifiers is not applicable to shared information system accounts (e.g., guest and anonymous accounts). It is commonly the case that a user account is the name of an information system account associated with an individual. To avoid having to build complex user management capabilities directly into their application, wise developers leverage the underlying OS or other user account management infrastructure (AD, LDAP) that is already in place within the organization and meets organizational user account management requirements. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000795 SRG-APP-000164 <GroupDescription></GroupDescription> SRG-APP-000164 The application must support organizational requirements to enforce minimum password length. <VulnDiscussion>Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password. The shorter the password is, the lower the number of possible combinations that need to be tested before the password is compromised. Use of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000205 SRG-APP-000165 <GroupDescription></GroupDescription> SRG-APP-000165 The application must support organizational requirements to prohibit password reuse for the organization-defined number of generations. <VulnDiscussion>Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. To meet password policy requirements, passwords need to be changed at specific policy based intervals. If the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the end result is a password that is not changed as per policy requirements. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000200 SRG-APP-000105 <GroupDescription></GroupDescription> SRG-APP-000105 The application must enforce configurable traffic volume thresholds representing auditing capacity for network traffic. <VulnDiscussion>It is critical when a system is at risk of failing to process audit logs as required; actions are automatically taken to mitigate the failure. Audit processing failures include: software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. One method used to thwart the auditing system is for an attacker to attempt to overwhelm the auditing system with large amounts of irrelevant data. The end result being audit logs that are either overwritten and activity thereby erased or disk space that is exhausted and any future activity is no longer logged. Applications and/or logging mechanisms employed by applications must take steps to enforce configurable volume thresholds representing the auditing capacity for network traffic.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000145 SRG-APP-000166 <GroupDescription></GroupDescription> SRG-APP-000166 The application must support organizational requirements to enforce password complexity by the number of upper case characters used. <VulnDiscussion>Password complexity or strength is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised. Use of a complex password helps to increase the time and resources required to compromise the password. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000192 SRG-APP-000167 <GroupDescription></GroupDescription> SRG-APP-000167 The application must support organizational requirements to enforce password complexity by the number of lower case characters used. <VulnDiscussion>Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised. Use of a complex password helps to increase the time and resources required to compromise the password. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000193 SRG-APP-000168 <GroupDescription></GroupDescription> SRG-APP-000168 The application must support organizational requirements to enforce password complexity by the number of numeric characters used. <VulnDiscussion>Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised. Use of a complex password helps to increase the time and resources required to compromise the password. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000194 SRG-APP-000169 <GroupDescription></GroupDescription> SRG-APP-000169 The application must support organizational requirements to enforce password complexity by the number of special characters used. <VulnDiscussion>Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor in determining how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised. Use of a complex password helps to increase the time and resources required to compromise the password. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001619 SRG-APP-000170 <GroupDescription></GroupDescription> SRG-APP-000170 The application must support organizational requirements to enforce the number of characters that get changed when passwords are changed. <VulnDiscussion>Passwords need to be changed at specific policy based intervals. If the information system or application allows the user to consecutively reuse extensive portions of their password when they change their password, the end result is a password that has not had enough elements changed to meet the policy requirements. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000195 SRG-APP-000171 <GroupDescription></GroupDescription> SRG-APP-000171 The application must support organizational requirements to enforce password encryption for storage. <VulnDiscussion>Applications must enforce password encryption when storing passwords. Passwords need to be protected at all times and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read and easily compromised.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000196 SRG-APP-000172 <GroupDescription></GroupDescription> SRG-APP-000172 The application must support organizational requirements to enforce password encryption for transmission. <VulnDiscussion>Passwords need to be protected at all times and encryption is the standard method for protecting passwords during transmission.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000197 SRG-APP-000173 <GroupDescription></GroupDescription> SRG-APP-000173 Applications must enforce password minimum lifetime restrictions. <VulnDiscussion>Password minimum lifetime is defined as: the minimum period of time, (typically in days) a user's password must be in effect before the user can change it. Restricting this setting limits the user's ability to change their password. Passwords need to be changed at specific policy based intervals, however if the application allows the user to immediately and continually change their password then the password could be repeatedly changed in a short period of time so as to defeat the organizations policy regarding password reuse. This would allow users to keep using the same password over and over again by immediately changing their password X number of times. This would effectively negate password policy. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000198 SRG-APP-000174 <GroupDescription></GroupDescription> SRG-APP-000174 Applications must enforce password maximum lifetime restrictions. <VulnDiscussion>Password maximum lifetime is defined as: the maximum period of time, (typically in days) a user's password may be in effect before the user is forced to change it. Passwords need to be changed at specific policy based intervals as per policy. Any password no matter how complex can eventually be cracked. One method of minimizing this risk is to use complex passwords and periodically change them. If the application does not limit the lifetime of passwords and force users to change their passwords there is the risk that the system and/or application passwords could be compromised. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000199 SRG-APP-000175 <GroupDescription></GroupDescription> SRG-APP-000175 The application, when utilizing PKI-based authentication, must validate certificates by constructing a certification path with status information to an accepted trust anchor. <VulnDiscussion>A trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates, and DNSSEC. When there is a chain of trust, usually the top entity to be trusted becomes the trust anchor; it can be for example a Certification Authority (CA). A certification path starts with the Subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted CA. Path validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted. Status information for certification paths includes, certificate revocation lists or online certificate status protocol responses. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000185 SRG-APP-000176 <GroupDescription></GroupDescription> SRG-APP-000176 The application, when using PKI-based authentication, must enforce authorized access to the corresponding private key. <VulnDiscussion>The cornerstone of the PKI is the private key used to encrypt or digitally sign information. If the private key is stolen, this will lead to the compromise of the authentication and non-repudiation gained through PKI because the attacker can use the private key to digitally sign documents and can pretend to be the authorized user. Both the holders of a digital certificate and the issuing authority must protect the computers, storage devices, or whatever they use to keep the private keys. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000186 SRG-APP-000126 <GroupDescription></GroupDescription> SRG-APP-000126 The application must protect audit data records and integrity by using cryptographic mechanisms. <VulnDiscussion>Protection of audit records and audit data is of critical importance. Cryptographic mechanisms are the industry established standard used to protect the integrity of audit data. An example of a cryptographic mechanism is the computation and application of a cryptographic-signed hash using asymmetric cryptography. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001350 SRG-APP-000177 <GroupDescription></GroupDescription> SRG-APP-000177 Applications must ensure that PKI-based authentication maps the authenticated identity to the user account. <VulnDiscussion>The cornerstone of the PKI is the private key used to encrypt or digitally sign information. The key by itself is a cryptographic value that does not contain specific user information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000187 SRG-APP-000178 <GroupDescription></GroupDescription> SRG-APP-000178 The application must obscure feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals. <VulnDiscussion>To prevent the compromise of authentication information such as passwords during the authentication process, the feedback from the information system shall not provide any information that would allow an unauthorized user to compromise the authentication mechanism. Obfuscation of user provided information when typed into the system is a method used in addressing this risk. For example, displaying asterisks when a user types in a password, is an example of obscuring feedback of authentication information. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000206 SRG-APP-000127 <GroupDescription></GroupDescription> SRG-APP-000127 The application must protect the audit records generated as a result of remote accesses to privileged accounts and the execution of privileged functions. <VulnDiscussion>Protection of audit records and audit data is of critical importance. Care must be taken to ensure privileged users cannot circumvent audit protections put in place. Auditing might not be reliable when performed by an information system which the user being audited has privileged access to. The privileged user could inhibit auditing or directly modify audit records. To prevent this from occurring, privileged access shall be further defined between audit-related privileges and other privileges, thus, limiting the users with audit-related privileges. Reducing the risk of audit compromises by privileged users can also be achieved, for example, by performing audit activity on a separate information system where the user in question has limited access or by using storage media that cannot be modified (e.g., write-once recording devices).</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001352 SRG-APP-000128 <GroupDescription></GroupDescription> SRG-APP-000128 The application must support the enforcement of logical access restrictions associated with changes to application configuration. <VulnDiscussion>When dealing with access restrictions pertaining to change control, it should be noted any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. Accordingly, only qualified and authorized individuals should be allowed to obtain access to application components for the purposes of initiating changes, including upgrades and modifications. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000345 SRG-APP-000179 <GroupDescription></GroupDescription> SRG-APP-000179 The application must use mechanisms for authentication to a cryptographic module that meet the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance for such authentication. <VulnDiscussion>Encryption is only as good as the encryption modules utilized. Unapproved cryptographic module algorithms cannot be verified, and cannot be relied upon to provide confidentiality or integrity and DoD data may be compromised due to weak algorithms. Applications utilizing encryption are required to use approved encryption modules that meet the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. FIPS 140-2 is the current standard for validating cryptographic modules and NSA Type-X (where X=1, 2, 3, 4) products are NSA certified hardware based encryption modules. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000803 SRG-APP-000180 <GroupDescription></GroupDescription> SRG-APP-000180 The application must uniquely identify and authenticate non-organizational users (or processes acting on behalf of non-organizational users). <VulnDiscussion>Non-organizational users include all information system users other than organizational users which include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors, guest researchers, individuals from allied nations). Non-organizational users shall be uniquely identified and authenticated for all accesses other than those accesses explicitly identified and documented by the organization when related to the use of anonymous access such as accessing a web server. Accordingly, a risk assessment is used in determining the authentication needs of the organization. Scalability, practicality, and security are simultaneously considered in balancing the need to ensure ease of use for access to federal information and information systems with the need to protect and adequately mitigate risk to organizational operations, organizational assets, individuals, other organizations, and the Nation. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000804 SRG-APP-000129 <GroupDescription></GroupDescription> SRG-APP-000129 The application must support the organizational requirement to employ automated mechanisms enforcing access restrictions. <VulnDiscussion>When dealing with access restrictions pertaining to change control, it should be noted, any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. Accordingly, only qualified and authorized individuals should be allowed to obtain access to information system components for the purposes of initiating changes, upgrades, and modifications. Access restrictions for change also include application software libraries. Examples of access restrictions include, physical and logical access controls, workflow automation, media libraries, abstract layers (e.g., changes are implemented into a third-party interface rather than directly into the information system component), and change windows (e.g., changes occur only during specified times, making unauthorized changes outside the window easy to discover). </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000346 SRG-APP-000181 <GroupDescription></GroupDescription> SRG-APP-000181 Applications that are designed and intended to address incident response scenarios must provide a configurable capability to automatically disable an information system if any of the organization defined security violations are detected. <VulnDiscussion>When responding to a security incident a capability must exist allowing authorized personnel to disable a particular system if the system exhibits a security violation and the organization determines an action is warranted. Organizations shall define a list of security violations that warrant an immediate disabling of a system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000831 SRG-APP-000130 <GroupDescription></GroupDescription> SRG-APP-000130 The application must support the employment of automated mechanisms supporting the auditing of enforcement actions. <VulnDiscussion>Any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. Accordingly, only qualified and authorized individuals are allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. Access restrictions for change also include software libraries. Examples of access restrictions include: physical and logical access controls, workflow automation, media libraries, abstract layers (e.g., changes are implemented into a third-party interface rather than directly into the information system component), and change windows (e.g., changes occur only during specified times, making unauthorized changes outside the window easy to discover). </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000347 SRG-APP-000182 <GroupDescription></GroupDescription> SRG-APP-000182 Applications related to incident tracking must support organizational requirements to employ automated mechanisms to assist in the tracking of security incidents. <VulnDiscussion>Incident tracking is a method of monitoring networks and systems for activity indicative of viral infection or system attack. Monitoring for this type of activity provides the organization with the capability to proactively detect and respond to attacks. Automated mechanisms for tracking security incidents and collecting/analyzing incident information include, the Einstein network monitoring device and monitoring online Computer Incident Response Centers (CIRCs) or other electronic databases of incidents. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000833 SRG-APP-000131 <GroupDescription></GroupDescription> SRG-APP-000131 Applications must prevent the installation of organization-defined critical software programs not signed with a certificate that has been recognized and approved by the organization. <VulnDiscussion>Any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. Accordingly, software defined by the organization as critical software may be signed with a certificate recognized and approved by the organization. Examples of critical software programs and/or modules include, for example, patches, service packs, software libraries and where applicable, device drivers. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000352 SRG-APP-000073 <GroupDescription></GroupDescription> SRG-APP-000073 Applications scanning for malicious code must scan all media used for system maintenance prior to use. <VulnDiscussion>There are security-related issues arising from software brought into the information system specifically for diagnostic and repair actions (e.g., a software packet sniffer installed on a system in order to troubleshoot system traffic, or a vendor installing or running a diagnostic application in order to troubleshoot an issue with a vendor supported system). This requirement ensures the media containing the application is scanned for malicious code prior to use. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000870 SRG-APP-NA <GroupDescription></GroupDescription> SRG-APP-NA The organization must employ automated mechanisms to restrict the use of maintenance tools to authorized personnel only. <VulnDiscussion>The intent of this control is to address the security-related issues arising from the software brought into the information system specifically for diagnostic and repair actions (e.g., a software packet sniffer introduced for the purpose of a particular maintenance activity). This is an organizational requirement to utilize automated mechanisms in order to prevent maintenance tools from being utilized by unauthorized personnel. This requirement does not address application characteristics and does not apply.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000872 SRG-APP-000132 <GroupDescription></GroupDescription> SRG-APP-000132 The application must support the enforcement of a two-person rule for changes to organization-defined application components and system-level information. <VulnDiscussion>Regarding access restrictions for changes made to organization defined information system components and system level information. Any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. Accordingly, only qualified and authorized individuals are allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. A two person rule requires two separate individuals acknowledge and approve those changes. Two person rule for changes to critical application components helps to reduce risks pertaining to availability and integrity. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000354 SRG-APP-NA <GroupDescription></GroupDescription> SRG-APP-NA The organization must audit non-local maintenance and diagnostic sessions. <VulnDiscussion>Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network in order to conduct system diagnostics. This is an organizational requirement to audit non-local maintenance sessions. This does not address an application characteristic and does not apply to applications.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000880 SRG-APP-000183 <GroupDescription></GroupDescription> SRG-APP-000183 Applications used for non-local maintenance sessions must protect those sessions through the use of a strong authenticator tightly bound to the user. <VulnDiscussion>Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. Identification and authentication techniques used in the establishment of non-local maintenance and diagnostic sessions must be consistent with the network access requirements in IA-2. Strong authenticators include, PKI where certificates are stored on a token protected by a password, passphrase, or biometric. Examples of types of applications used for non-local maintenance and diagnostic activities are provided below. Use as an example does not imply compliance with policy requirements or approval for use. Examples include but are not limited to: - Terminal Services - Remote Desktop - Dameware - VNC (all variants) </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000884 SRG-APP-000133 <GroupDescription></GroupDescription> SRG-APP-000133 Applications must limit privileges to change the software resident within software libraries (including privileged programs). <VulnDiscussion>When dealing with change control issues, it should be noted any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. If the application were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement is contingent upon the language in which the application is programmed as many application architectures in use today incorporate their software libraries into and make them inseparable from their compiled distributions rendering them static and version dependant. However, this requirement does apply to applications with software libraries accessible and configurable as in the case of interpreted languages. Accordingly, only qualified and authorized individuals shall be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001499 SRG-APP-NA <GroupDescription></GroupDescription> SRG-APP-NA The organization must protect non-local maintenance sessions by separating the maintenance session from other network sessions with the information system by either physically separated communications paths; or logically separated communications paths based upon encryption. <VulnDiscussion>This is a requirement that maintenance needs to be done on a separate interface or encrypted channel to segment maintenance activity from regular usage. This does not address an application characteristic and does not apply.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001632 SRG-APP-000134 <GroupDescription></GroupDescription> SRG-APP-000134 Applications must automatically implement organization-defined safeguards and countermeasures if security functions (or mechanisms) are changed inappropriately. <VulnDiscussion>Any changes to the application components of the information system can potentially have significant effects on the overall security of the system. Accordingly, only qualified and authorized individuals shall be allowed to obtain access to the application components for purposes of initiating changes, including upgrades and modifications. In order to ensure a prompt response to unauthorized changes to application security functions or security mechanisms, organizations may define countermeasures and safeguards that monitoring applications must undertake in the event these types of changes occur. This degree of functionality is typically built into a support architecture providing change management and/or system monitoring capabilities. Automatic implementation of safeguards and countermeasures includes: reversing the change; halting the system; or triggering an audit alert when an unauthorized modification to a critical security file or process occurs. Examples of such support architecture include but are not limited to: HIDS, change management software or file/process monitoring software. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001500 SRG-APP-000184 <GroupDescription></GroupDescription> SRG-APP-000184 The application must employ cryptographic mechanisms to protect the integrity and confidentiality of non-local maintenance and diagnostic communications. <VulnDiscussion>Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. The act of managing systems and applications includes the ability to access sensitive application information such as system configuration details, diagnostic information, user information, and potentially sensitive application data. When applications provide a remote management capability that is inherent to the application, the application needs to ensure the communication channels used to remotely access the system are adequately protected. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000888 SRG-APP-000185 <GroupDescription></GroupDescription> SRG-APP-000185 The application must employ strong identification and authentication techniques when establishing non-local maintenance and diagnostic sessions <VulnDiscussion>Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. The act of managing systems and applications includes the ability to access sensitive application information, such as, system configuration details, diagnostic information, user information and potentially sensitive application data. When applications provide a remote management capability that is inherent to the application, the application needs to ensure the identification and authentication techniques used to remotely access the system are strong enough to protect the system. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000877 SRG-APP-000135 <GroupDescription></GroupDescription> SRG-APP-000135 Configuration management applications must employ automated mechanisms to centrally manage configuration settings. <VulnDiscussion>Configuration settings are the configurable security-related parameters of information technology products that are part of the information system. Security-related parameters are those parameters impacting the security state of the system including parameters related to meeting other security control requirements. Security-related parameters include: registry settings; account, file, and directory settings (i.e., permissions); and settings for services, ports, protocols, and remote connections. Rather than visiting each and every system when making application configuration changes, organizations will employ automated tools that can make changes across all systems. This greatly increases efficiency and manageability of systems and applications in a large scale environment. To support this requirement, configuration management applications will employ automated mechanisms to centrally manage configuration settings and applications, in general, will ensure that they do not hinder the use of such tools. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000370 SRG-APP-000136 <GroupDescription></GroupDescription> SRG-APP-000136 Configuration management applications must employ automated mechanisms to centrally apply configuration settings. <VulnDiscussion>Configuration settings are the configurable security-related parameters of information technology products that are part of the information system. Security-related parameters are those parameters impacting the security state of the system including parameters related to meeting other security control requirements. Security-related parameters include: registry settings; account, file, and directory settings (i.e., permissions); and settings for services, ports, protocols, and remote connections. Rather than visiting each and every system when making configuration changes, organizations will employ automated tools that can make changes across all systems. This greatly increases efficiency and manageability of systems and applications in a large scale environment. Centrally apply means to apply settings from a centralized location. In order to accommodate large scale environments, centralized solutions may also employ distributed systems used as configuration management proxies. This is allowable as long as these systems are centrally managed and controlled as part of the overall configuration management solution. To support this requirement, configuration management applications will employ automated mechanisms to centrally apply configuration settings and applications in general will ensure they do not hinder the use of such tools.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000371 SRG-APP-000137 <GroupDescription></GroupDescription> SRG-APP-000137 Configuration management applications must employ automated mechanisms to centrally verify configuration settings. <VulnDiscussion>Configuration settings are the configurable security-related parameters of information technology products that are part of the information system. Security-related parameters are those parameters impacting the security state of the system, including parameters related to meeting other security control requirements. Security-related parameters include: registry settings; account, file, and directory settings (i.e., permissions); and settings for services, ports, protocols, and remote connections. Rather than visiting each and every system when making configuration changes, organizations will employ automated tools that can make changes across all systems. This greatly increases efficiency and manageability of systems and applications in a large scale environment. Centrally verify means to verify settings have taken effect from a centralized location. In order to accommodate large scale environments, centralized solutions may also employ distributed systems used as configuration management proxies. This is allowable as long as these systems are centrally managed and controlled as part of the overall configuration management solution. To support this requirement, configuration management applications will employ automated mechanisms to centrally verify configuration settings and applications in general will ensure they do not hinder the use of such tools.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000372 SRG-APP-000138 <GroupDescription></GroupDescription> SRG-APP-000138 Configuration management applications must employ automated mechanisms to centrally respond to unauthorized changes to configuration settings. <VulnDiscussion>Configuration settings are the configurable security-related parameters of information technology products that are part of the information system. Security-related parameters are those parameters impacting the security state of the system, including parameters related to meeting other security control requirements. Security-related parameters include: registry settings; account, file, and directory settings (i.e., permissions); and settings for services, ports, protocols, and remote connections. Responses to unauthorized changes to configuration settings can include: alerting designated organizational personnel, restoring mandatory/organization-defined configuration settings, or in the extreme case, halting affected information system processing. Centrally respond means to respond to unauthorized changes to settings have taken effect from a centralized location. In order to accommodate large scale environments, centralized solutions may also employ distributed systems used as configuration management proxies. This is allowable as long as these systems are centrally managed and controlled as part of the overall configuration management solution.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000374 SRG-APP-000139 <GroupDescription></GroupDescription> SRG-APP-000139 Configuration management solutions must track unauthorized, security-relevant configuration changes. <VulnDiscussion>Configuration settings are the configurable security-related parameters of information technology products that are part of the information system. Security-related parameters are those parameters impacting the security state of the system including parameters related to meeting other security control requirements. Security-related parameters include: registry settings; account, file, and directory settings (i.e., permissions); and settings for services, ports, protocols, and remote connections. Incident Response teams require input from authoritative sources in order to investigate events that have occurred. Configuration management solutions are a logical source for providing information regarding system configuration changes. Unauthorized, security-relevant configuration changes must be incorporated into the organization’s incident response capability to ensure such detected events are tracked for historical purposes.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001589 SRG-APP-000141 <GroupDescription></GroupDescription> SRG-APP-000141 Applications must adhere to the principles of least functionality by providing only essential capabilities. <VulnDiscussion>Information systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions). It is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. Examples include, but are not limited to: installing advertising software, demo's or browser plugins not related to requirements or providing a wide array of functionality not required for every mission, yet cannot be disabled. Applications must adhere to the principles of least functionality by providing only essential capabilities.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000381 SRG-APP-000142 <GroupDescription></GroupDescription> SRG-APP-000142 The application must support the organizational requirements to specifically prohibit or restrict the use of unauthorized functions, ports, protocols, and/or services. <VulnDiscussion>Information systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions). Additionally, it is sometimes convenient to provide multiple services from a single component of an information system (e.g., email and web services) but doing so increases risk over limiting the services provided by any one component. To support the requirements and principles of least functionality the application must support the organizational requirements providing only essential capabilities and limiting the use of ports, protocols, and/or services to only those required, authorized, and approved to conduct official business or to address authorized quality of life issues.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000382 SRG-APP-000143 <GroupDescription></GroupDescription> SRG-APP-000143 To support the requirements and principles of least functionality, the application must support organizational requirements regarding the use of automated mechanisms preventing program execution on the information system in accordance with the organization-defined specifications. <VulnDiscussion>Information systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions). Standard operating procedure for placing an information system into a production environment includes creating a baseline configuration of the system. The baseline configuration provides information about the components of the information system (e.g., the standard software load for a workstation, server, network component, or mobile device including operating system/installed applications with current version numbers and patch information), network topology, and the logical placement of the component within the system architecture. It is sometimes convenient to provide multiple services from a single information system, but doing so increases risk when compared to limiting the services provided by any one system. This is particularly true when these services have conflicting missions, user communities or availability requirements. This requirement addresses the need to provide an automated mechanism that will prevent the execution of programs not associated with the established baseline configuration. This is a requirement to disable services as part of the baseline process and provide automated tools that monitor the system and prevent unauthorized system processes from executing. This requirement will apply to configuration management applications, HIDS applications and other similar types of applications designed to manage system processes and configurations. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000386 SRG-APP-NA <GroupDescription></GroupDescription> SRG-APP-NA The organization must employ automated mechanisms, per organization-defined frequency, to detect the addition of unauthorized components/devices into the information system. <VulnDiscussion>Information deemed to be necessary by the organization to achieve effective property accountability can include: hardware inventory specifications (manufacturer, type, model, serial number, physical location), software license information, information system/component owner, and for a networked component/device, the machine name and network address. This is not an application requirement. This requirement is regarding information system component inventory. The purpose is to require organizations to employ an automated mechanism to inventory and detect when new devices and components are installed into information systems. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000416 SRG-APP-000144 <GroupDescription></GroupDescription> SRG-APP-000144 Applications must implement transaction recovery for systems that are transaction-based. <VulnDiscussion>Application recovery and reconstitution constitutes executing an information system contingency plan that is comprised of activities that restore essential missions and business functions. Database management systems and transaction-based processing systems are examples of information systems that are transaction-based. Transaction rollback and transaction journaling are examples of mechanisms supporting transaction recovery. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000553 SRG-APP-000145 <GroupDescription></GroupDescription> SRG-APP-000145 Backup / Disaster Recovery oriented applications must be capable of backing up user-level information per a defined frequency. <VulnDiscussion>Information system backup is a critical step in maintaining data assurance and availability. User-level information is data generated by information system and/or application users. In order to assure availability of this data in the event of a system failure, DoD organizations are required to ensure user generated data is backed up at a defined frequency. This includes data stored on file systems, within databases or within any other storage media. Applications performing backups must be capable of backing up user-level information per the DoD defined frequency.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000535 SRG-APP-000106 <GroupDescription></GroupDescription> SRG-APP-000106 The application must reject or delay, as defined by the organization, network traffic generated above configurable traffic volume thresholds. <VulnDiscussion>It is critical when a system is at risk of failing to process audit logs as required; actions are automatically taken to mitigate the failure or risk of failure. One method used to thwart the auditing system is for an attacker to attempt to overwhelm the auditing system with large amounts of irrelevant data. The end result being audit logs that are either overwritten and activity thereby erased or disk space that is exhausted and any future activity is no longer logged. In many system configurations, the disk space allocated to the auditing system is separate from the disks allocated for the operating system; therefore, this may not result in a system outage.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001574 SRG-APP-000107 <GroupDescription></GroupDescription> SRG-APP-000107 The application must invoke a system shutdown in the event of an audit failure, unless an alternative audit capability exists. <VulnDiscussion>It is critical when a system is at risk of failing to process audit logs as required; it takes action to mitigate the failure. If the system were to continue processing without auditing enabled, actions can be taken on the system that cannot be tracked and recorded for later forensic analysis. Audit processing failures include; software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. In many system configurations, the disk space allocated to the auditing system is separate from the disks allocated for the operating system; therefore, this may not result in a system outage. This forces the application to detect and take actions.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001343 SRG-APP-000146 <GroupDescription></GroupDescription> SRG-APP-000146 The application must support and must not impede organizational requirements to conduct backups of system-level information contained in the information system per organization-defined frequency. <VulnDiscussion>Information system backup is a critical step in maintaining data assurance and availability. System-level information includes: system-state information, operating system and application software, and licenses. Backups shall be consistent with organizational recovery time and recovery point objectives. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000537 SRG-APP-000108 <GroupDescription></GroupDescription> SRG-APP-000108 The application must alert designated organizational officials in the event of an audit processing failure. <VulnDiscussion>It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Audit processing failures include; software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000139 SRG-APP-000147 <GroupDescription></GroupDescription> SRG-APP-000147 The application must support and must not impede organizational requirements to conduct backups of information system documentation including security-related documentation per organization-defined frequency. <VulnDiscussion>Information system backup is a critical step in maintaining data assurance and availability. Information system and security related documentation contains information pertaining to system configuration and security settings. Backups shall be consistent with organizational recovery time and recovery point objectives. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000539 SRG-APP-000148 <GroupDescription></GroupDescription> SRG-APP-000148 The application must uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users). <VulnDiscussion>To assure accountability and prevent unauthorized access, organizational users shall be identified and authenticated. Organizational users include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors, guest researchers, individuals from allied nations). Users (and any processes acting on behalf of users) are uniquely identified and authenticated for all accesses other than those accesses explicitly identified and documented by the organization which outlines specific user actions that can be performed on the information system without identification or authentication. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000764 SRG-APP-000149 <GroupDescription></GroupDescription> SRG-APP-000149 The application must use multifactor authentication for network access to privileged accounts. <VulnDiscussion>Multifactor authentication is defined as: using two or more factors to achieve authentication. Factors include: (i) something a user knows (e.g., password/PIN); (ii) something a user has (e.g., cryptographic identification device, token); or (iii) something a user is (e.g., biometric). A privileged account is defined as: An information system account with authorizations of a privileged user. Network Access is defined as: Access to an information system by a user (or a process acting on behalf of a user) communicating through a network (e.g., local area network, wide area network, Internet). </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000765 SRG-APP-000109 <GroupDescription></GroupDescription> SRG-APP-000109 The application must be capable of taking organization-defined actions upon audit failure (e.g., overwrite oldest audit records, stop generating audit records, cease processing, notify of audit failure). <VulnDiscussion>It is critical when a system is at risk of failing to process audit logs as required; it detects and takes action to mitigate the failure. Audit processing failures include: software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. Applications are required to be capable of either directly performing or calling system level functionality performing defined actions upon detection of an application audit log processing failure.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000140 SRG-APP-000150 <GroupDescription></GroupDescription> SRG-APP-000150 The application must use multifactor authentication for network access to non-privileged accounts. <VulnDiscussion>Multifactor authentication is defined as: using two or more factors to achieve authentication. Factors include: (i) something a user knows (e.g., password/PIN); (ii) something a user has (e.g., cryptographic identification device, token); or (iii) something a user is (e.g., biometric). A non-privileged account is defined as: An information system account with authorizations of a regular or non-privileged user. Network Access is defined as: Access to an information system by a user (or a process acting on behalf of a user) communicating through a network (e.g., local area network, wide area network, Internet). Applications integrating with the DoD Active Directory and utilize the DoD CAC are examples of compliant multifactor authentication solutions.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000766 SRG-APP-000110 <GroupDescription></GroupDescription> SRG-APP-000110 To support audit review, analysis and reporting the application must integrate audit review, analysis, and reporting processes to support organizational processes for investigation and response to suspicious activities. <VulnDiscussion>Successful incident response and auditing relies on timely, accurate system information and analysis in order to allow the organization to identify and respond to potential incidents in a proficient manner. Audit review, analysis and reporting are all activities related to the evaluation of system activity through the inspection and analysis of system log data. Some examples include but are not limited to: organizational requirements to cooperate with legal counsel and/or auditors in order to provide reports on certain types of system activity or analyzing system logs to ascertain sources or causes of certain system activity.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000152 SRG-APP-000151 <GroupDescription></GroupDescription> SRG-APP-000151 The application must use multifactor authentication for local access to privileged accounts. <VulnDiscussion>Multifactor authentication is defined as: using two or more factors to achieve authentication. Factors include: (i) something a user knows (e.g., password/PIN); (ii) something a user has (e.g., cryptographic identification device, token); or (iii) something a user is (e.g., biometric). A privileged account is defined as an information system account with authorizations of a privileged user. Local Access is defined as access to an organizational information system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000767 SRG-APP-000152 <GroupDescription></GroupDescription> SRG-APP-000152 The application must use multifactor authentication for local access to non-privileged accounts. <VulnDiscussion>Multifactor authentication is defined as: using two or more factors to achieve authentication. Factors include: (i) something a user knows (e.g., password/PIN); (ii) something a user has (e.g., cryptographic identification device, token); or (iii) something a user is (e.g., biometric). A non-privileged account is defined as an information system account with authorizations of a regular or non-privileged user. Local Access is defined as access to an organizational information system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000768 SRG-APP-000153 <GroupDescription></GroupDescription> SRG-APP-000153 Applications authenticating users must ensure users are authenticated with an individual authenticator prior to using a group authenticator. <VulnDiscussion>To assure individual accountability and prevent unauthorized access, application users (and any processes acting on behalf of users) must be individually identified and authenticated. A group authenticator is a generic account used by multiple individuals. Use of a group authenticator alone does not uniquely identify individual users. An example of a group authenticator is the UNIX OS 'root' user account, a Windows 'administrator' account, an 'sa' account or a "helpdesk" account. For example, the UNIX and Windows operating systems offer a 'switch user' capability allowing users to authenticate with their individual credentials and, when needed, 'switch' to the administrator role. This method provides for unique individual authentication prior to using a group authenticator. Some applications may not have the need to provide a group authenticator; this is considered a matter of application design. In those instances where the application design includes the use of a group authenticator, this requirement will apply. There may also be instances when specific user actions need to be performed on the information system without unique user identification or authentication. An example of this type of access is a web server which contains publicly releasable information. These types of accesses are allowed but must be explicitly identified and documented by the organization. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000770 SRG-APP-000154 <GroupDescription></GroupDescription> SRG-APP-000154 Applications using multifactor authentication when accessing privileged accounts via the network must provide one of the factors by a device that is separate from the information system gaining access. <VulnDiscussion>Multifactor authentication is defined as: using two or more factors to achieve authentication. Factors include: (i) something a user knows (e.g., password/PIN); (ii) something a user has (e.g., cryptographic identification device, token); or (iii) something a user is (e.g., biometric). A privileged account is defined as an information system account with authorizations of a privileged user. Network access is defined as; any access to an information system by a user (or process acting on behalf of a user) where said access is obtained through a network connection. Out Of Band 2 Factor Authentication (OOB2FA) is defined as: when one of the authentication factors is provided by a device that is separate from the system that is used to gain access. For example, a mobile device such as a smart phone is registered within the application to an application user. Upon a successful authentication, the system sends instructions to the registered mobile device in the form of on-screen prompts instructing the user on how to complete the login process. OOB2FA employs separate communication channels where at least one is independently maintained and trusted to authenticate an end user. Applications using multifactor authentication when accessing privileged accounts via the network must provide one of the factors by a device separate from the information system gaining access. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000771 SRG-APP-000155 <GroupDescription></GroupDescription> SRG-APP-000155 Applications using multifactor authentication when accessing non-privileged accounts via the network must provide one of the factors by a device separate from the information system gaining access. <VulnDiscussion>Multifactor authentication is defined as: using two or more factors to achieve authentication. Factors include: (i) something a user knows (e.g., password/PIN); (ii) something a user has (e.g., cryptographic identification device, token); or (iii) something a user is (e.g., biometric). A non-privileged account is defined as an information system account with authorizations of a non-privileged user or simply, a regular user. Network access is defined as any access to an information system by a user (or process acting on behalf of a user) where said access is obtained through a network connection. Out Of Band 2 Factor Authentication is defined as: when one of the authentication factors is provided by a device that is separate from the system that is used to gain access. For example, a mobile device such as a smart phone is registered within the application to an application user. Upon a successful authentication, the system sends instructions to the registered mobile device in the form of on-screen prompts instructing the user on how to complete the login process. OOB2FA employs separate communication channels where at least one is independently maintained and trusted to authenticate an end user. Applications using multifactor authentication when accessing non-privileged accounts via the network must provide one of the factors by a device separate from the information system gaining access. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000772 SRG-APP-000216 <GroupDescription></GroupDescription> SRG-APP-000216 The application must perform data origin authentication and data integrity verification on the name/address resolution responses the system receives from authoritative sources when requested by client systems. <VulnDiscussion>A recursive resolving or caching Domain Name System (DNS) server is an example of an information system providing name/address resolution service for local clients. Authoritative DNS servers are examples of authoritative sources. Information systems using technologies other than the DNS to map between host/service names and network addresses provide other means to enable clients to verify the authenticity and integrity of response data. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001180 SRG-APP-000217 <GroupDescription></GroupDescription> SRG-APP-000217 The application must perform data origin authentication and data integrity verification on all resolution responses received whether or not local client systems explicitly request this service. <VulnDiscussion>A recursive resolving or caching Domain Name System (DNS) server is an example of an information system providing name/address resolution service for local clients. Authoritative DNS servers are examples of authoritative sources owning DNS data. Information systems using technologies other than the DNS to map between host/service names and network addresses provide other means to enable clients to verify the authenticity and integrity of response data. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001181 SRG-APP-NA <GroupDescription></GroupDescription> SRG-APP-NA The information systems that collectively provide name/address resolution service for an organization must be fault-tolerant. <VulnDiscussion>A Domain Name System (DNS) server is an example of an information system providing name/address resolution service. To eliminate single points of failure and to enhance redundancy, there are typically at least two authoritative DNS servers, one configured as primary and the other as secondary. Additionally, the two servers are commonly located in two different network subnets and geographically separated (i.e., not located in the same physical facility). With regard to role separation, DNS servers with an internal role, only process name/address resolution requests from within the organization (i.e., internal clients). DNS servers with an external role only process name/address resolution information requests from clients external to the organization (i.e., on the external networks including the Internet). The set of clients that can access an authoritative DNS server in a particular role is specified by the organization (e.g., by address ranges, explicit lists). This requirement addresses the need to have redundant DNS servers and does not apply to DNS application functionality.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001182 SRG-APP-000218 <GroupDescription></GroupDescription> SRG-APP-000218 Applications that collectively provide name/address resolution service for an organization must implement internal/external role separation. <VulnDiscussion>A Domain Name System (DNS) server is an example of an information system providing name/address resolution service. To eliminate single points of failure and to enhance redundancy, there are typically at least two authoritative domain DNS servers, one configured as primary and the other as secondary. Additionally, the two servers are commonly located in two different network subnets and geographically separated (i.e., not located in the same physical facility). With regard to role separation, DNS servers with an internal role, only process name/address resolution requests from within the organization (i.e., internal clients). DNS servers with an external role only process name/address resolution information requests from clients external to the organization (i.e., on the external networks including the Internet). The set of clients that can access an authoritative DNS server in a particular role is specified by the organization (e.g., by address ranges, explicit lists). </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001183 SRG-APP-000219 <GroupDescription></GroupDescription> SRG-APP-000219 Application must ensure authentication of both client and server during the entire session. An example of this is SSL Mutual Authentication. <VulnDiscussion>This control focuses on communications protection at the session, versus packet level. At the application layer, session IDs are tokens generated by web applications to uniquely identify an application user's session. Web applications utilize session tokens or session IDs in order to establish application user identity. Proper use of session IDs addressed man-in-the-middle attacks including session hijacking or insertion of false information into a session. This control is only implemented where deemed necessary by the organization (e.g., sessions in service-oriented architectures providing web-based services). </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001184 SRG-APP-000220 <GroupDescription></GroupDescription> SRG-APP-000220 Applications must terminate user sessions upon user logout or any other organization or policy defined session termination events such as idle time limit exceeded. <VulnDiscussion>This requirement focuses on communications protection at the application session, versus network packet level. Session IDs are tokens generated by web applications to uniquely identify an application user's session. Applications will make application decisions and execute business logic based on the session ID. Unique session identifiers or IDs are the opposite of sequentially generated session IDs which can be easily guessed by an attacker. Unique session IDs help to reduce predictability of said identifiers. Unique session IDs address man-in-the-middle attacks including session hijacking or insertion of false information into a session. If the attacker is unable to identify or guess the session information related to pending application traffic, they will have more difficulty in hijacking the session or otherwise manipulating valid sessions. When a user logs out, or when any other session termination event occurs, the application must terminate the user session to minimize the potential for an attacker to hijack that particular user session.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001185 SRG-APP-000221 <GroupDescription></GroupDescription> SRG-APP-000221 Applications providing a login capability must also provide a logout functionality to allow the user to manually terminate the session. <VulnDiscussion>Manually terminating an application session allows users to immediately depart the physical vicinity of the system they are logged into without the risk of subsequent system users reactivating or continuing their application session. User's who log into applications must have the ability to manually terminate their application session. Without an observable manual logout capability provided by the application, the user will have no means of manually terminating their application session. Their session could remain active until which time the inactivity period expires and the application automatically logs the user out. This increases the likelihood that the next subsequent user of the system could pick up on the previous user's session and continue utilizing the application as the previous user.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001186 SRG-APP-000222 <GroupDescription></GroupDescription> SRG-APP-000222 Applications must generate a unique session identifier for each session. <VulnDiscussion>This requirement focuses on communications protection at the application session, versus network packet level. The intent of this control is to establish grounds for confidence at each end of a communications session in the ongoing identity of the other party and in the validity of the information being transmitted. Unique session IDs are the opposite of sequentially generated session IDs which can be easily guessed by an attacker. Unique session identifiers help to reduce predictability of said identifiers. Unique session IDs address man-in-the-middle attacks including session hijacking or insertion of false information into a session. If the attacker is unable to identify or guess the session information related to pending application traffic, they will have more difficulty in hijacking the session or otherwise manipulating valid sessions.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001187 SRG-APP-000223 <GroupDescription></GroupDescription> SRG-APP-000223 Applications must recognize only system-generated session identifiers. <VulnDiscussion>This requirement focuses on communications protection at the application session, versus network packet level. The intent of this control is to establish grounds for confidence at each end of a communications session in the ongoing identity of the other party and in the validity of the information being transmitted. Unique session IDs are the opposite of sequentially generated session IDs which can be easily guessed by an attacker. Unique session identifiers help to reduce predictability of said identifiers. Unique session IDs address man-in-the-middle attacks including session hijacking or insertion of false information into a session. If the attacker is unable to identify or guess the session information related to pending application traffic, they will have more difficulty in hijacking the session or otherwise manipulating valid sessions.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001664 SRG-APP-000224 <GroupDescription></GroupDescription> SRG-APP-000224 Applications must generate unique session identifiers with organization-defined randomness requirements. <VulnDiscussion>This requirement focuses on communications protection at the application session, versus network packet level. The intent of this control is to establish grounds for confidence at each end of a communications session in the ongoing identity of the other party and in the validity of the information being transmitted. Unique session IDs are the opposite of sequentially generated session IDs which can be easily guessed by an attacker. Unique session identifiers help to reduce predictability of said identifiers. Unique session IDs address man-in-the-middle attacks including session hijacking or insertion of false information into a session. If the attacker is unable to identify or guess the session information related to pending application traffic, they will have more difficulty in hijacking the session or otherwise manipulating valid sessions. Organizations can define the randomness of unique session identifiers when deemed necessary (e.g., sessions in service-oriented architectures providing web-based services). </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001188 SRG-APP-000225 <GroupDescription></GroupDescription> SRG-APP-000225 Applications must be built to fail to a known safe state for defined types of failures. <VulnDiscussion>Failure in a known state can address safety or security in accordance with the mission/business needs of the organization. Failure in a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. Failure in a known safe state helps prevent systems from failing to a state that may cause loss of data or unauthorized access to system resources. Applications or systems that fail suddenly and with no incorporated failure state planning may leave the hosting system available but with a reduced security protection capability. Preserving information system state information also facilitates system restart and return to the operational mode of the organization with less disruption of mission/business processes. An example is a firewall that blocks all traffic rather than allowing all traffic when a firewall component fails. This prevents an attacker from forcing a failure of the system in order to obtain access. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001190 SRG-APP-000229 <GroupDescription></GroupDescription> SRG-APP-000229 Only a Honey Pot information system and/or application must include components that proactively seek to identify web-based malicious code. Honey Pot systems must be not be shared or used for any other purpose other than described. <VulnDiscussion>A Honey Pot is an organization designated information system and/or application that includes components specifically designed to be the target of malicious attacks for the purpose of detecting, deflecting, and analyzing such attacks. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001196 SRG-APP-000231 <GroupDescription></GroupDescription> SRG-APP-000231 Applications must take needed steps to protect data at rest and ensure confidentiality and integrity of application data. <VulnDiscussion>This control is intended to address the confidentiality and integrity of information at rest in non-mobile devices and covers user information and system information. Information at rest refers to the state of information when it is located on a secondary storage device (e.g., disk drive, tape drive) within an organizational information system. Applications and application users generate information throughout the course of their application use. User data generated, as well as, application specific configuration data needs to be protected. Configurations and/or rule sets for firewalls, gateways, intrusion detection/prevention systems, and filtering routers and authenticator content are examples of system information likely requiring protection. Organizations may choose to employ different mechanisms to achieve confidentiality and integrity protections, as appropriate. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001199 SRG-APP-000233 <GroupDescription></GroupDescription> SRG-APP-000233 Applications must isolate security functions from non-security functions by means of an isolation boundary (implemented via partitions and domains) controlling access to and protecting the integrity of, the hardware, software, and firmware that perform those security functions. The application must isolate security functions from non-security functions. <VulnDiscussion>Security functions are defined as "the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based". Developers and implementers can increase the assurance in security functions by employing well-defined security policy models, structured, disciplined, and rigorous hardware and software development techniques, and sound system/security engineering principles. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001084 SRG-APP-000236 <GroupDescription></GroupDescription> SRG-APP-000236 Applications must meet organizational requirements to implement an information system isolation boundary that minimizes the number of non-security functions included within the boundary containing security functions. <VulnDiscussion>The information system isolates security functions from non-security functions by means of an isolation boundary (implemented via partitions and domains) controlling access to and protecting the integrity of, the hardware, software, and firmware that perform those security functions. The information system maintains a separate execution domain (e.g., address space) for each executing process.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001087 SRG-APP-000238 <GroupDescription></GroupDescription> SRG-APP-000238 Applications must meet organizational requirements to implement security functions as a layered structure minimizing interactions between layers of the design and avoiding any dependence by lower layers on the functionality or correctness of higher layers. <VulnDiscussion>The information system isolates security functions from non-security functions by means of an isolation boundary (implemented via partitions and domains) controlling access to and protecting the integrity of, the hardware, software, and firmware that perform those security functions. The information system maintains a separate execution domain (e.g., address space) for each executing process.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001089 SRG-APP-000239 <GroupDescription></GroupDescription> SRG-APP-000239 The application must protect the integrity of information during the processes of data aggregation, packaging, and transformation in preparation for transmission. <VulnDiscussion>Information can be subjected to unauthorized changes (e.g., malicious and/or unintentional modification) at information aggregation or protocol transformation points. It is therefore imperative the application take steps to validate and assure the integrity of data while at these stages of processing. For example, an application developer may determine based upon application requirements that various application data must accumulate in a processing queue where the application analyses, packages or transforms the data pending a data transfer. A window of time now exists where if an attacker were to gain access to the data residing in the application queue they could potentially compromise that data or alter results. The application must ensure the integrity of data that is pending transfer is maintained. If the application were to simply transmit aggregated, packaged or transformed data without ensuring the data was not manipulated during these processes, then the integrity of the data may be called into question.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001209 SRG-APP-000240 <GroupDescription></GroupDescription> SRG-APP-000240 Applications required to be non-modifiable must support organizational requirements to provide components that contain no writeable storage capability. These components must be persistent across restart and/or power on/off. <VulnDiscussion>Organizations may require applications or application components to be non-modifiable or to be stored and executed on non-writeable storage. Use of non-modifiable storage ensures the integrity of the software program from the point of creation of the read-only image and eliminates the possibility of malicious code insertion. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001214 SRG-APP-000241 <GroupDescription></GroupDescription> SRG-APP-000241 Applications must, for organization-defined information system components, load and execute the operating environment from hardware-enforced, read-only media. <VulnDiscussion>Organizations may require the information system to load the operating environment from hardware enforced read-only media. The term operating environment is defined as the code upon which applications are hosted, for example, a monitor, executive, operating system, or application running directly on the hardware platform. Hardware-enforced, read-only media include, CD-R/DVD-R disk drives. Use of non-modifiable storage ensures the integrity of the software program from the point of creation of the read-only image. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001210 SRG-APP-000242 <GroupDescription></GroupDescription> SRG-APP-000242 Applications must support organizationally-defined requirements to load and execute from hardware-enforced, read-only media. <VulnDiscussion>Use of non-modifiable storage ensures the integrity of the software program from the point of creation of the read-only image. Organizations may require the information system to load specified applications from hardware enforced read-only media. Hardware-enforced, read-only media include, CD-R/DVD-R disk drives. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001211 SRG-APP-000243 <GroupDescription></GroupDescription> SRG-APP-000243 Applications must prevent unauthorized and unintended information transfer via shared system resources. <VulnDiscussion>The purpose of this control is to prevent information, including encrypted representations of information, produced by the actions of a prior user/role (or the actions of a process acting on behalf of a prior user/role) from being available to any current user/role (or current process) that obtains access to a shared system resource (e.g., registers, main memory, secondary storage) after the resource has been released back to the information system. Control of information in shared resources is also referred to as object reuse. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001090 SRG-APP-000244 <GroupDescription></GroupDescription> SRG-APP-000244 Applications must not share resources used to interface with systems operating at different security levels. <VulnDiscussion>The purpose of this control is to prevent information, including encrypted representations of information, produced by the actions of a prior user/role (or the actions of a process acting on behalf of a prior user/role) from being available to any current user/role (or current process) that obtains access to a shared system resource (e.g., registers, main memory, secondary storage) after the resource has been released back to the information system. Shared resources include, memory, input/output queues, and network interface cards. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001091 SRG-APP-000245 <GroupDescription></GroupDescription> SRG-APP-000245 Applications must protect against or limit the effects of the organization-defined or referenced types of Denial of Service (DoS) attacks. <VulnDiscussion>A variety of technologies exist to limit, or in some cases, eliminate the effects of DoS attacks. For example, boundary protection devices can filter certain types of packets to protect devices on an organization’s internal network from being directly affected by DoS attacks. Employing increased capacity and bandwidth combined with service redundancy may reduce the susceptibility to some DoS attacks. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001092 SRG-APP-000226 <GroupDescription></GroupDescription> SRG-APP-000226 Applications must preserve any organization-defined system state information in the event of a system failure. <VulnDiscussion>Failure in a known state can address safety or security in accordance with the mission/business needs of the organization. Failure in a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. Preserving information system state information helps to facilitate system restart and return to the operational mode of the organization with less disruption of mission/business processes. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001665 SRG-APP-000246 <GroupDescription></GroupDescription> SRG-APP-000246 Applications must restrict the ability of users to launch Denial of Service (DoS) attacks against other information systems or networks. <VulnDiscussion>When it comes to DoS attacks most of the attention is paid to ensuring that systems and applications are not victims of these attacks. While it is true that those accountable for systems want to ensure they are not affected by a DoS attack, they also need to ensure their systems and applications are not used to launch such an attack against others. To that extent, a variety of technologies exist to limit, or in some cases, eliminate the effects of DoS attacks. For example, boundary protection devices can filter certain types of packets to protect devices from being directly affected by denial of service attacks. Limiting system resources that are allocated to any user to a bare minimum may also reduce the ability of users to launch some DoS attacks. Applications and application developers must take the steps needed to ensure that users cannot use these applications to launch DoS attacks against other systems and networks. An example would be designing applications to include mechanisms that throttle network traffic so that users are not able to generate unlimited network traffic via the application. The methods employed to counter this risk will be dependent upon the potential application layer methods that can be used to exploit it.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001094 SRG-APP-000247 <GroupDescription></GroupDescription> SRG-APP-000247 Applications must manage excess capacity, bandwidth, or other redundancy to limit the effects of information flooding types of Denial of Service (DoS) attacks. <VulnDiscussion>In the case of application DoS attacks, care must be taken when designing the application so as to ensure that the application makes the best use of system resources. SQL queries have the potential to consume large amounts of CPU cycles if they are not tuned for optimal performance. Web services containing complex calculations requiring large amounts of time to complete can bog down if too many requests for the service are encountered within a short period of time. The methods employed to meet this requirement will vary depending upon the technology the application utilizes. However, a variety of technologies exist to limit, or in some cases, eliminate the effects of application related DoS attacks. Employing increased capacity and bandwidth combined with specialized application layer protection devices and service redundancy may reduce the susceptibility to some DoS attacks. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001095 SRG-APP-000248 <GroupDescription></GroupDescription> SRG-APP-000248 Applications must limit the use of resources by priority and not impede the host from servicing processes designated as a higher-priority. <VulnDiscussion>Priority protection helps prevent a lower-priority process from delaying or interfering with the information system servicing any higher-priority process. This control does not apply to components in the information system for which there is only a single user/role. The application must limit the use of resources by priority.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001096 SRG-APP-000249 <GroupDescription></GroupDescription> SRG-APP-000249 Applications functioning in the capacity of a firewall must check incoming communications to ensure the communications are coming from an authorized source and routed to an authorized destination. <VulnDiscussion>In regards to boundary controls such as routers and firewalls, examples of restricting and prohibiting communications are: restricting external web traffic only to organizational web servers within managed interfaces and prohibiting external traffic that appears to be spoofing an internal address as the source. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001117 SRG-APP-000250 <GroupDescription></GroupDescription> SRG-APP-000250 The application must be capable of implementing host-based boundary protection mechanisms for servers, workstations, and mobile devices. <VulnDiscussion>A host-based boundary protection mechanism is a host-based firewall. Host-based boundary protection mechanisms are employed on mobile devices, such as notebook/laptop computers, and other types of mobile devices where such boundary protection mechanisms are available. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001118 SRG-APP-NA <GroupDescription></GroupDescription> SRG-APP-NA The organization must isolate organization-defined key information security tools, mechanisms, and support components from other internal information system components via physically separate subnets with managed interfaces to other portions of the system. <VulnDiscussion>The application must isolate organization-defined key information security tools, mechanisms, and support components from other internal information system components via physically separate subnets with managed interfaces to other portions of the system. This is a physical separation requirement and is not applicable.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001119 SRG-APP-NA <GroupDescription></GroupDescription> SRG-APP-NA The information system must route all networked, privileged accesses through a dedicated, managed interface for purposes of access control and auditing. <VulnDiscussion>Managed interfaces employing boundary protection devices include: proxies, gateways, routers, firewalls, guards, or encrypted tunnels arranged in effective security architecture (e.g., routers protecting firewalls and application gateways residing on a protected sub network commonly referred to as a demilitarized zone or DMZ). This is a configuration requirement to route privileged access through a dedicated managed interface (e.g., firewall) and does not apply to applications.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001123 SRG-APP-000252 <GroupDescription></GroupDescription> SRG-APP-000252 Boundary protection applications must prevent discovery of specific system components (or devices) composing a managed interface. <VulnDiscussion>Firewall control requirement for isolating and preventing the discovery of management interfaces. This control enhancement is intended to protect the network addresses of information system components that are part of the managed interface from discovery through common tools and techniques used to identify devices on a network.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001124 SRG-APP-000253 <GroupDescription></GroupDescription> SRG-APP-000253 Applications designed to enforce protocol formats must employ automated mechanisms to enforce strict adherence to protocol format. <VulnDiscussion>Automated mechanisms used to enforce protocol formats include, deep packet inspection firewalls and XML gateways. These devices verify adherence to the protocol specification (e.g., IEEE) at the application layer and serve to identify significant vulnerabilities that cannot be detected by devices operating at the network or transport layer. It is impractical to expect protocol format inspection to be conducted manually.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001125 SRG-APP-000254 <GroupDescription></GroupDescription> SRG-APP-000254 Boundary protection applications must fail securely in the event of an operational failure. <VulnDiscussion>Fail secure is a condition achieved by the application of a set of information system mechanisms to ensure that in the event of an operational failure of a boundary protection device at a managed interface (e.g., router, firewall, guard, application gateway residing on a protected sub network commonly referred to as a demilitarized zone), the system does not enter into an unsecure state where intended security properties no longer hold. A failure of a boundary protection device cannot lead to, or cause information external to the boundary protection device to enter the device, nor can a failure permit unauthorized information release.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001126 SRG-APP-000255 <GroupDescription></GroupDescription> SRG-APP-000255 Boundary protection applications must be capable of preventing public access into the organization’s internal networks except as appropriately mediated by managed interfaces. <VulnDiscussion>Access into an organization's internal network and to key internal boundaries must be tightly controlled and managed. Applications monitoring and/or controlling communications at the external boundary of the system and at key internal boundaries must be capable of preventing public access into the organization’s internal networks except as appropriately mediated by managed interfaces. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001100 SRG-APP-000256 <GroupDescription></GroupDescription> SRG-APP-000256 Any software application designed to function as a firewall must be capable employing a default deny all configuration. <VulnDiscussion>A firewall default deny is a firewall configuration setting that will force the administrator to explicitly allow network or application traffic rather than allowing all traffic by default. The purpose is to prevent unmanaged access into the internal network or in the case of an application firewall, to application content, features, or functionality. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001109 SRG-APP-000257 <GroupDescription></GroupDescription> SRG-APP-000257 Applications providing remote connectivity must prevent remote devices that have established a non-remote connection with the system from communicating outside of the communications path with resources in external networks. <VulnDiscussion>This control enhancement is implemented within the remote device (e.g., notebook/laptop computer) via configuration settings that are not configurable by the user of that device. An example of a non-remote communications path from a remote device is a virtual private network. When a non-remote connection is established using a virtual private network, the configuration settings prevent split-tunneling. Split-tunneling might otherwise be used by remote users to communicate with the information system as an extension of that system and to communicate with local resources such as, a printer or file server. Since the remote device, when connected by a non-remote connection, becomes an extension of the information system, allowing dual communications paths such as split-tunneling would be, in effect, allowing unauthorized external connections into the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001111 SRG-APP-000258 <GroupDescription></GroupDescription> SRG-APP-000258 Proxy applications must support logging individual Transmission Control Protocol (TCP) sessions and blocking specific Uniform Resource Locators (URLs), domain names, and Internet Protocol (IP) addresses. Proxy applications must also be configurable with organization-defined lists of authorized and unauthorized websites. <VulnDiscussion>External networks are networks outside the control of the organization. Proxy servers support logging individual Transmission Control Protocol (TCP) sessions and blocking specific Uniform Resource Locators (URLs), domain names, and Internet Protocol (IP) addresses. Proxy servers are also configurable with organization-defined lists of authorized and unauthorized websites.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001112 SRG-APP-000259 <GroupDescription></GroupDescription> SRG-APP-000259 Applications performing extrusion detection must be capable of denying network traffic and auditing internal users (or malicious code) posing a threat to external information systems. <VulnDiscussion>Detecting internal actions that may pose a security threat to external information systems is sometimes termed extrusion detection. Extrusion detection at the information system boundary includes the analysis of network traffic (incoming as well as, outgoing) looking for indications of an internal threat to the security of external systems.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001115 SRG-APP-NA <GroupDescription></GroupDescription> SRG-APP-NA The information system must monitor and control communications at the external boundary of the information system and at key internal boundaries within the system. <VulnDiscussion>Restricting external web traffic only to organizational web servers within managed interfaces and prohibiting external traffic that appears to be spoofing an internal address as the source are examples of restricting and prohibiting communications. The same can be said for the monitoring of the traffic. The information system must monitor and control communications at the external boundary of the information system and at key internal boundaries within the system. This is a boundary control requirement to use firewalls and proxy servers to control communications and is not an application requirement.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001097 SRG-APP-NA <GroupDescription></GroupDescription> SRG-APP-NA The information system must connect to external networks or information systems only through managed interfaces consisting of boundary protection devices arranged in accordance with an organizational security architecture. <VulnDiscussion>Managed interfaces employing boundary protection devices include: proxies, gateways, routers, firewalls, guards, or encrypted tunnels arranged in an effective security architecture (e.g., routers protecting firewalls and application gateways residing on a protected sub-network commonly referred to as a demilitarized zone or DMZ). This is a boundary control requirement to route traffic through managed firewalls and proxies deployed according to an architectural design. This is a network configuration issue not an application requirement.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001098 SRG-APP-NA <GroupDescription></GroupDescription> SRG-APP-NA Applications must protect the integrity of transmitted information. <VulnDiscussion>Ensuring the integrity of transmitted information requires that applications take feasible measures to employ security during data transport. Examples include but are not limited to SSL, TLS and IPSEC, and VPN. This requirement applies to communications across internal and external networks. If the organization is relying on a commercial service provider for transmission services as a commodity item rather than a fully dedicated service, it may be more difficult to obtain the necessary assurances regarding the implementation of needed security controls for transmission integrity. When it is infeasible or impractical to obtain the necessary security controls and assurances of control effectiveness through appropriate contracting vehicles, the organization either implements appropriate compensating security controls or explicitly accepts the additional risk. This is a network requirement regarding the use of dedicated circuits and does not apply to applications.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001127 SRG-APP-NA <GroupDescription></GroupDescription> SRG-APP-NA Applications must employ cryptographic mechanisms to recognize changes to information during transmission unless otherwise protected by alternative physical measures. <VulnDiscussion>Ensuring the integrity of transmitted information requires that applications take measures to employ some form of cryptographic mechanism in order to recognize changes to information. This is usually achieved through the use of checksums, cryptographic hash or message authentication. Alternative physical protection measures include, Protected Distribution Systems (PDS). PDS are used to transmit unencrypted classified NSI through an area of lesser classification or control. In as much as the classified NSI is unencrypted, the PDS must provide adequate electrical, electromagnetic, and physical safeguards to deter exploitation. This is a requirement for PDS systems to use cryptographic mechanisms and is not an application requirement.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001128 SRG-APP-NA <GroupDescription></GroupDescription> SRG-APP-NA The application must maintain the integrity of information during aggregation, packaging, and transformation in preparation for transmission. <VulnDiscussion>Ensuring the confidentiality of transmitted information requires that applications take feasible measures to employ transmission layer security. This requirement applies to communications across internal and external networks. If the organization is relying on a commercial service provider for transmission services as a commodity item rather than a fully dedicated service, it may be more difficult to obtain the necessary assurances regarding the implementation of needed security controls for transmission integrity. When it is infeasible or impractical to obtain the necessary security controls and assurances of control effectiveness through appropriate contracting vehicles, the organization either implements appropriate compensating security controls or explicitly accepts the additional risk. When transmitting data, applications need to leverage transmission protection mechanisms such as TLS, SSL VPNs, or IPSEC. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001129 SRG-APP-NA <GroupDescription></GroupDescription> SRG-APP-NA Applications must protect the confidentiality of transmitted information. <VulnDiscussion>Ensuring the confidentiality of transmitted information requires that applications take feasible measures to employ security mechanisms during data transmission. Examples include but are not limited to, SSL, TLS, IPSec, and VPN. This requirement applies to communications across internal and external networks. If the organization is relying on a commercial service provider for transmission services as a commodity item rather than a fully dedicated service, it may be more difficult to obtain the necessary assurances regarding the implementation of needed security controls for transmission integrity. When it is infeasible or impractical to obtain the necessary security controls and assurances of control effectiveness through appropriate contracting vehicles, the organization either implements appropriate compensating security controls or explicitly accepts the additional risk. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001130 SRG-APP-000264 <GroupDescription></GroupDescription> SRG-APP-000264 The application must employ cryptographic mechanisms preventing the unauthorized disclosure of information during transmission unless the transmitted data is otherwise protected by alternative physical measures. <VulnDiscussion>Preventing the disclosure of transmitted information requires that applications take measures to employ some form of cryptographic mechanism in order to protect the information during transmission. This is usually achieved through the use of Transport Layer Security (TLS), SSL VPN, or IPSEC tunnel. Alternative physical protection measures include, Protected Distribution Systems (PDS). PDS are used to transmit unencrypted classified NSI through an area of lesser classification or control. In as much as the classified NSI is unencrypted, the PDS must provide adequate electrical, electromagnetic, and physical safeguards to deter exploitation. Refer to NSTSSI No. 7003 for additional details on a PDS. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001131 SRG-APP-000230 <GroupDescription></GroupDescription> SRG-APP-000230 Applications must maintain the confidentiality of information during aggregation, packaging, and transformation in preparation for transmission. When transmitting data, applications need to leverage transmission protection mechanisms such as TLS, SSL VPNs, or IPSEC. <VulnDiscussion>Preventing the disclosure of transmitted information requires that applications take measures to employ some form of cryptographic mechanism in order to protect the information during transmission. This is usually achieved through the use of Transport Layer Security (TLS), SSL VPN, or IPSEC tunnel. Alternative physical protection measures include, protected distribution systems. Protective Distribution Systems (PDS) are used to transmit unencrypted classified NSI through an area of lesser classification or control. In as much as the classified NSI is unencrypted, the PDS must provide adequate electrical, electromagnetic and physical safeguards to deter exploitation. Refer to NSTSSI No. 7003 for additional details on a PDS.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001132 SRG-APP-000251 <GroupDescription></GroupDescription> SRG-APP-000251 The application must check the validity of data inputs. <VulnDiscussion>Invalid user input occurs when a user inserts data or characters into an applications data entry fields and the application is unprepared to process that data. This results in unanticipated application behavior potentially leading to an application or information system compromise. Invalid user input is one of the primary methods employed when attempting to compromise an application. All applications need to validate the data users attempt to input to the application for processing. Rules for checking the valid syntax and semantics of information system inputs (e.g., character set, length, numerical range, acceptable values) are in place to verify that inputs match specified definitions for format and content. Inputs passed to interpreters are prescreened to prevent the content from being unintentionally interpreted as commands.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001310 SRG-APP-000265 <GroupDescription></GroupDescription> SRG-APP-000265 The application must identify potentially security-relevant error conditions. <VulnDiscussion>The structure and content of error messages need to be carefully considered by the organization and development team. The extent to which the application is able to identify and handle error conditions is guided by organizational policy and operational requirements. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001311 SRG-APP-000266 <GroupDescription></GroupDescription> SRG-APP-000266 The application must only generate error messages that provide information necessary for corrective actions without revealing organization-defined sensitive or potentially harmful information in error logs and administrative messages that could be exploited. <VulnDiscussion>Any application providing too much information in error logs and in administrative messages to the screen risks compromising the data and security of the application and system. The structure and content of error messages needs to be carefully considered by the organization and development team. The extent to which the application is able to identify and handle error conditions is guided by organizational policy and operational requirements. Sensitive information includes, account numbers, social security numbers, and credit card numbers.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001312 SRG-APP-000267 <GroupDescription></GroupDescription> SRG-APP-000267 The application must restrict error messages so only authorized personnel may view them. <VulnDiscussion>If the application provides too much information in error logs and administrative messages to the screen, this could lead to compromise. The structure and content of error messages need to be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001314 SRG-APP-000268 <GroupDescription></GroupDescription> SRG-APP-000268 Applications must support the requirement to activate an alarm and/or automatically shut down the information system if an application component failure is detected. This can include conducting a graceful application shutdown to avoid losing information. <VulnDiscussion>Predictable failure prevention requires organizational planning to address system failure issues. If components key to maintaining systems security fail to function, the system could continue operating in an insecure state. The organization must be prepared and the application must support requirements that specify if the application must alarm for such conditions and/or automatically shut down the application or the system. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001328 SRG-APP-000269 <GroupDescription></GroupDescription> SRG-APP-000269 Applications providing patch management capabilities must support the organizational requirements to install software updates automatically. <VulnDiscussion>Security faults with software applications and operating systems are discovered daily. Vendors are constantly updating and patching their products to address newly discovered security vulnerabilities. Organizations (including any contractor to the organization) are required to promptly install security-relevant software updates (e.g., patches, service packs, and hot fixes). Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling, must also be addressed expeditiously. Anytime new software code is introduced to a system there is the potential for unintended consequences. There have been documented instances where the application of a patch has caused problems with system integrity or availability. Due to information system integrity and availability concerns, organizations must give careful consideration to the methodology used to carry out automatic updates. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001232 SRG-APP-000270 <GroupDescription></GroupDescription> SRG-APP-000270 Applications serving to determine the state of information system components with regard to flaw remediation (patching) must use automated mechanisms to make that determination. The automation schedule must be determined on an organization-defined basis and any solution utilized must support the scheduling requirement. <VulnDiscussion>Organizations are required to identify information systems containing software affected by recently announced software flaws (and potential vulnerabilities resulting from those flaws) and report this information to designated organizational officials with information security responsibilities (e.g., senior information security officers, information system security managers, information systems security officers). To support this requirement, an automated process or mechanism is required. This role is usually assigned to patch management software that is deployed in order to track the number of systems installed in the network, as well as, the types of software installed on these systems, the corresponding versions, and the related flaws that require patching. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001233 SRG-APP-000271 <GroupDescription></GroupDescription> SRG-APP-000271 The application must support organizational requirements to employ automated patch management tools to facilitate flaw remediation to organization-defined information system components. Patch management tools must be automated. <VulnDiscussion>The organization (including any contractor to the organization) shall promptly install security-relevant software updates (e.g., patches, service packs, and hot fixes). Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling, shall also be addressed expeditiously. Due to information system integrity and availability concerns, organizations shall give careful consideration to the methodology used to carry out automatic updates. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001237 SRG-APP-000272 <GroupDescription></GroupDescription> SRG-APP-000272 The application must automatically update malicious code protection mechanisms, including signature definitions. Examples include anti-virus signatures and malware data files employed to identify and/or block malicious software from executing. <VulnDiscussion>Anti-virus and malicious software detection applications utilize signature definitions in order to identify viruses and other malicious software. These signature definitions need to be constantly updated in order to identify the new threats that are discovered every day. All anti-virus and malware software shall come with an update mechanism that automatically updates these signatures. The organization (including any contractor to the organization) is required to promptly install security-relevant malicious code protection software updates (e.g., anti-virus signature updates and hot fixes). Malicious code includes, viruses, worms, Trojan horses, and Spyware. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001247 SRG-APP-000273 <GroupDescription></GroupDescription> SRG-APP-000273 The application must prevent non-privileged users from circumventing malicious code protection capabilities. <VulnDiscussion>Malicious code protection software must be protected so as to prevent a non-privileged user or malicious piece of software from disabling the protection mechanism. A common tactic of malware is to identify the type of malicious code protection software running on the system and deactivate it. Malicious code includes, viruses, worms, Trojan horses, and Spyware. Examples include the capability for non-administrative user's to turn off or otherwise disable anti-virus.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001248 SRG-APP-000111 <GroupDescription></GroupDescription> SRG-APP-000111 Applications must provide the capability to centralize the review and analysis of audit records from multiple components within the system. <VulnDiscussion>Successful incident response and auditing relies on timely, accurate system information and analysis in order to allow the organization to identify and respond to potential incidents in a proficient manner. Segregation of logging data to multiple disparate computer systems is counter-productive and makes log analysis and log event alarming difficult to implement and manage, particularly when the system or application has multiple logging components written to different locations or systems.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000154 SRG-APP-000274 <GroupDescription></GroupDescription> SRG-APP-000274 Malicious code protection applications must update malicious code protection mechanisms only when directed by a privileged user. <VulnDiscussion>Malicious code protection software must be protected to prevent a non-privileged user or malicious piece of software from manipulating the protection update mechanism. Malicious code includes, viruses, worms, Trojan horses, and Spyware. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001249 SRG-APP-NA <GroupDescription></GroupDescription> SRG-APP-NA Applications must support organizational requirements restricting users from introducing removable media into the information system. <VulnDiscussion>Malicious code is known to propagate via removable media such as, floppy disks, USB or flash drives, and removable hard drives. In order to prevent propagation and potential infection due to malware contained on removable media, the information system must be able to restrict and/or limit the use of removable media. Applications must not be designed so as to circumvent or otherwise disable this protection requirement. This is a requirement to restrict users from inserting removable media into a system. This is not an application requirement.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001250 SRG-APP-NA <GroupDescription></GroupDescription> SRG-APP-NA The organization must employ malicious code protection mechanisms at information system entry and exit points to detect and eradicate malicious code transported by electronic mail, electronic mail attachments, web accesses, removable media, or other common means. <VulnDiscussion>In order to minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated prior to entering protected enclaves via information system entry and exit points. Information system entry and exit points include: firewalls, electronic mail servers, web servers, proxy servers, and remote-access servers. Malicious code includes viruses, worms, Trojan horses, and Spyware. The requirement states that anti-virus and malware protection applications must be used at entry and exit points. This does not apply to applications. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001239 SRG-APP-NA <GroupDescription></GroupDescription> SRG-APP-NA The organization must employ malicious code protection mechanisms at workstations, servers, or mobile computing devices on the network to detect and eradicate malicious code transported by electronic mail, electronic mail attachments, web accesses, removable media, or other common means. <VulnDiscussion>In order to minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated. Malicious code includes viruses, worms, Trojan horses, and Spyware. Applications providing malicious code protection must support organizational requirements to employ malicious code protection mechanisms at workstations, servers, or mobile computing devices on the network to detect and eradicate malicious code transported by electronic mail, electronic mail attachments, web accesses, removable media, or other common means. The requirement states that malicious code protection mechanisms such as anti-virus must be used on workstations, servers and mobile computing devices. This does not apply to applications.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001668 SRG-APP-000276 <GroupDescription></GroupDescription> SRG-APP-000276 Applications providing malicious code protection must support organizational requirements to update malicious code protection mechanisms (including signature definitions) whenever new releases are available in accordance with organizational configuration management policy and procedures. <VulnDiscussion>Malicious code protection mechanisms include, but are not limited to, anti-virus and malware detection software. In order to minimize potential negative impact to the organization caused by malicious code, it is imperative that malicious code is identified and eradicated. Malicious code includes, viruses, worms, Trojan horses, and Spyware. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001240 SRG-APP-000277 <GroupDescription></GroupDescription> SRG-APP-000277 Applications scanning for malicious code must support organizational requirements to configure malicious code protection mechanisms to perform periodic scans of the information system on an organization-defined frequency. <VulnDiscussion>Malicious code protection mechanisms include but are not limited to anti-virus and malware detection software. In order to minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated. Malicious code includes, viruses, worms, Trojan horses, and Spyware. It is not enough to simply have the software installed. This software must periodically scan the system to search for malware on an organization defined frequency. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001241 SRG-APP-000113 <GroupDescription></GroupDescription> SRG-APP-000113 The application must provide an audit reduction capability. <VulnDiscussion>Audit reduction is used to reduce the volume of audit records in order to facilitate manual review. Before a security review information systems and/or applications with an audit reduction capability may remove many audit records known to have little security significance. This is generally accomplished by removing records generated by specified classes of events, such as records generated by nightly backups. Audit reduction does not alter original audit records. An audit reduction capability provides support for near real-time audit review and analysis requirements and after-the-fact investigations of security incidents. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000156 SRG-APP-000278 <GroupDescription></GroupDescription> SRG-APP-000278 Applications providing malicious code protection must support organizational requirements to configure malicious code protection mechanisms to perform real-time scans of files from external sources as the files are downloaded, opened, or executed in accordance with organizational security policy. <VulnDiscussion>Malicious code protection mechanisms include but are not limited to anti-virus and malware detection software. In order to minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated. Malicious code includes, viruses, worms, Trojan horses, and Spyware. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001242 SRG-APP-000279 <GroupDescription></GroupDescription> SRG-APP-000279 Applications providing malicious code protection must support organizational requirements to be configured to perform organization-defined action(s) in response to malicious code detection. <VulnDiscussion>Malicious code protection mechanisms include but are not limited to anti-virus and malware detection software. In order to minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated. Applications providing this capability must be able to perform actions in response to detected malware. Responses include, but are not limited to, quarantine, deletion, and alerting. Malicious code includes, viruses, worms, Trojan horses, and Spyware. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001243 SRG-APP-000280 <GroupDescription></GroupDescription> SRG-APP-000280 Applications providing malicious code protection must support organizational requirements to address the receipt of false positives during malicious code detection, eradication efforts, and the resulting potential impact on the availability of the information system. <VulnDiscussion>In order to minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated. Malicious code includes, viruses, worms, Trojan horses, and Spyware. Applications providing this capability must have an ability to address the issue of false alerts. False alerts can overwhelm reporting and administrative interfaces making it difficult to identify the true threat. A filtering capability that serves to identify and remove false positives is often employed to address this issue. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001245 SRG-APP-000114 <GroupDescription></GroupDescription> SRG-APP-000114 Applications must provide a report generation capability for audit reduction data. <VulnDiscussion>In support of Audit Review, Analysis, and Reporting requirements, audit reduction is a technique used to reduce the volume of audit records in order to facilitate a manual review. Before a security review is conducted, information systems and/or applications with an audit reduction capability may remove many audit records known to have little security significance. This is generally accomplished by removing records generated by specified classes of events, such as records generated by nightly backups. In order to identify and report on what (repetitive) data has been removed via the use of audit reduction, the application must provide a capability to generate reports containing what values were removed by the audit reduction. Audit reduction does not alter original audit records. An audit reduction capability provides support for near real-time audit review and analysis based on policy based requirements and after-the-fact investigations of security incidents. Reporting tools employing audit reduction methods must not alter the original audit data. An example of a tool employing audit reduction methods is the Windows Event Viewer tool which is used to view and analyze audit logs on Windows systems.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000157 SRG-APP-000281 <GroupDescription></GroupDescription> SRG-APP-000281 Intrusion detection software must be able to interconnect using standard protocols to create a system wide intrusion detection system. <VulnDiscussion>When utilizing intrusion detection software, monitoring components are usually dispersed throughout the network, such as, when utilizing HIDS and multiple NIDS sensors. In order to leverage the capabilities of intrusion detection systems to get a complete overall view of network and host activity, these separate components must be able to report and react to activity they detect. Non-standard or custom communication protocols do not provide the reliability and veracity required of an enterprise class intrusion detection system. An example of a custom protocol includes, but is not limited to, vendor specific communication protocols that have not undergone IETF RFC evaluation and/or are not in common use throughout the Internet as a whole.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001259 SRG-APP-000282 <GroupDescription></GroupDescription> SRG-APP-000282 For those instances where the organization requires encrypted traffic to be visible to information system monitoring tools, the application transmitting the encrypted traffic must make provisions to allow that traffic to be visible to specific system monitoring tools. <VulnDiscussion>There is a recognized need to balance encrypting traffic versus the need to have insight into the traffic from a monitoring perspective. For some organizations, the need to ensure the confidentiality of traffic is paramount; for others, the mission-assurance concerns are greater. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001272 SRG-APP-NA <GroupDescription></GroupDescription> SRG-APP-NA The organization must analyze outbound communications traffic at the external boundary of the system (i.e., system perimeter). <VulnDiscussion>Anomalies within the information system include, for example, large file transfers, long-time persistent connections, unusual protocols and ports in use, and attempted communications with suspected malicious external addresses. This is a requirement to analyze outbound traffic. This does not apply to applications.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001273 SRG-APP-NA <GroupDescription></GroupDescription> SRG-APP-NA The organization must analyze outbound communications traffic at selected interior points within the system (e.g., subnets, subsystems), as deemed necessary, to discover anomalies. <VulnDiscussion>Anomalies within the information system include, for example, large file transfers, long-time persistent connections, unusual protocols and ports in use, and attempted communications with suspected malicious external addresses. This is a requirement to analyze outbound traffic at selected interior points. This does not apply to applications.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001671 SRG-APP-NA <GroupDescription></GroupDescription> SRG-APP-NA The organization must employ a wireless intrusion detection system to detect attack attempts to the information system. <VulnDiscussion>Wireless intrusion detection monitors wireless network traffic for known attack patterns and notifies IA staff members when possible attacks are detected. This is a network monitoring traffic analysis requirement to deploy wireless IDS. This does not apply to applications. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001672 SRG-APP-NA <GroupDescription></GroupDescription> SRG-APP-NA The organization must employ a wireless Intrusion Detection System (IDS) to detect potential compromises/breaches to the information system. <VulnDiscussion>Wireless IDS is used to detect and alarm on known attack patterns. This is a requirement to deploy wireless IDS network monitoring. This does not apply to applications. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001673 SRG-APP-000283 <GroupDescription></GroupDescription> SRG-APP-000283 Applications providing malware and/or firewall protection must monitor inbound and outbound communications for unauthorized activities or conditions. <VulnDiscussion>Unusual/unauthorized activities or conditions include internal traffic indicating the presence of malicious code within an information system or propagating among system components, the unauthorized export of information, or signaling to an external information system. Evidence of malicious code is used to identify potentially compromised information systems or information system components. Examples of applications that provide monitoring capability for unusual/unauthorized activities include, but are not limited to, Intrusion Detection, Anti-Virus and Malware etc.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001262 SRG-APP-000284 <GroupDescription></GroupDescription> SRG-APP-000284 Applications that detect and alarm on security events such as Intrusion Detection, Firewalls, Anti-Virus, or Malware must provide near real-time alert notification. <VulnDiscussion>When an intrusion detection security event occurs it is imperative the application that has detected the event immediately notify the appropriate support personnel so they can respond accordingly. Lack of this capability increases the risk that attacks will go unnoticed or responses will be delayed.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001263 SRG-APP-000285 <GroupDescription></GroupDescription> SRG-APP-000285 Applications providing IDS and prevention capabilities must prevent non-privileged users from circumventing intrusion detection and prevention capabilities. <VulnDiscussion>Any application providing intrusion detection and prevention capabilities must be architected and implemented so as to prevent non-privileged users from circumventing such protections. This can be accomplished through the use of user roles, use of proper systems permissions, auditing, logging, etc.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001265 SRG-APP-000286 <GroupDescription></GroupDescription> SRG-APP-000286 Applications providing notifications regarding suspicious events must include the capability to notify an organization-defined list of response personnel who are identified by name and/or by role. <VulnDiscussion>Incident response applications are by their nature designed to monitor, detect, and alarm on defined events occurring on the system or on the network. A large part of their functionality is accurate and timely notification of events. Notifications can be made more efficient by the creation of notification groups containing members who would be responding to a particular alarm or event. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001266 SRG-APP-000287 <GroupDescription></GroupDescription> SRG-APP-000287 The application must support taking organization-defined list of least-disruptive actions to terminate suspicious events. <VulnDiscussion>System availability is a key tenet of system security. Organizations need to have the flexibility to be able to define the automated actions taken in response to an identified incident. This includes being able to define a least disruptive action that the application takes to terminate suspicious events. A least disruptive action may include initiating a request for human response rather than blocking traffic or disrupting system operation.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001670 SRG-APP-000288 <GroupDescription></GroupDescription> SRG-APP-000288 The application must enforce organizational requirements to protect information obtained from intrusion monitoring tools from unauthorized access, modification, and deletion. <VulnDiscussion>Intrusion monitoring applications are by their nature designed to monitor and record network and system traffic and activity. They can accumulate a significant amount of sensitive data, examples of which could include user account information and application data not related to the intrusion monitoring application itself. Intrusion monitoring tools also obtain information that is critical to conducting forensic analysis on attacks occurring within the network. This data may be sensitive in nature. Information obtained by intrusion monitoring applications in the course of evaluating network and system security needs to be protected. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001269 SRG-APP-000186 <GroupDescription></GroupDescription> SRG-APP-000186 The application must terminate all sessions and network connections when non-local maintenance is completed. <VulnDiscussion>Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. The act of managing systems and applications includes the ability to access sensitive application information such as system configuration details, diagnostic information, user information and potentially sensitive application data. When applications provide a remote management capability that is inherent to the application, the application needs to ensure all sessions and network connections are terminated when non-local maintenance is completed. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000879 SRG-APP-000289 <GroupDescription></GroupDescription> SRG-APP-000289 The application must either implement compensating security controls or the organization explicitly accepts the risk of not performing the verification as required. <VulnDiscussion>Application security functional testing involves testing the application for conformance to the applications security function specifications, as well as, for the underlying security model. The need to verify security functionality applies to all security functions. The conformance criteria state the conditions necessary for the application to exhibit the desired security behavior or satisfy a security property for example, successful login triggers an audit entry. Organizations may define conditions requiring verification and the frequency in which such testing occurs. Security function testing usually occurs during the development phase and can in some instances occur in the production phase if the developer provides the security conformance criteria or if the conformance criteria can be established. There are application testing frameworks available that can perform functional testing on production systems however they are limited in their applicability and are language or product centric. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001291 SRG-APP-000200 <GroupDescription></GroupDescription> SRG-APP-000200 Applications must respond to security function anomalies in accordance with organization-defined responses and alternative action(s). <VulnDiscussion>The need to verify security functionality applies to all security functions. For those security functions not able to execute automated self-tests the organization either implements compensating security controls or explicitly accepts the risk of not performing the verification as required. Information system transitional states include, startup, restart, shutdown, and abort.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001674 SRG-APP-000187 <GroupDescription></GroupDescription> SRG-APP-000187 Applications employed to write data to portable digital media must use cryptographic mechanisms to protect and restrict access to information on portable digital media. <VulnDiscussion>When data is written to portable digital media such as thumb drives, floppy diskettes, compact disks, magnetic tape, etc., there is risk of data loss. An organizational assessment of risk guides the selection of media and associated information contained on that media requiring restricted access. Organizations need to document in policy and procedures, the media requiring restricted access, individuals authorized to access the media, and the specific measures taken to restrict access. Fewer protection measures are needed for media containing information determined by the organization to be in the public domain, to be publicly releasable, or to have limited or no adverse impact if accessed by other than authorized personnel. In these situations, it is assumed the physical access controls where the media resides provide adequate protection. The employment of cryptography is at the discretion of the information owner/steward. The selection of the cryptographic mechanisms used is based upon maintaining the confidentiality and integrity of the information. The strength of mechanisms is commensurate with the classification and sensitivity of the information. When the organization has determined the risk warrants it, data written to portable digital media must be encrypted. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001009 SRG-APP-000188 <GroupDescription></GroupDescription> SRG-APP-000188 Applications must support organizational requirements to employ cryptographic mechanisms to protect information in storage. <VulnDiscussion>When data is written to digital media such as, hard drives, mobile computers, external/removable hard drives, personal digital assistants, flash/thumb drives, etc., there is risk of data loss and data compromise. An organizational assessment of risk guides the selection of media and associated information contained on that media requiring restricted access. Organizations need to document in policy and procedures, the media requiring restricted access, individuals authorized to access the media, and the specific measures taken to restrict access. Fewer protection measures are needed for media containing information determined by the organization to be in the public domain, to be publicly releasable, or to have limited or no adverse impact if accessed by other than authorized personnel. In these situations, it is assumed the physical access controls where the media resides provide adequate protection. As part of a defense-in-depth strategy, the organization considers routinely encrypting information at rest on selected secondary storage devices. The employment of cryptography is at the discretion of the information owner/steward. The selection of the cryptographic mechanisms used is based upon maintaining the confidentiality and integrity of the information. The strength of mechanisms is commensurate with the classification and sensitivity of the information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001019 SRG-APP-000275 <GroupDescription></GroupDescription> SRG-APP-000275 Applications must provide notification of failed automated security tests. <VulnDiscussion>The need to verify security functionality applies to all security functions. For those security functions not able to execute automated self-tests the organization either implements compensating security controls or explicitly accepts the risk of not performing the verification as required. Information system transitional states include, startup, restart, shutdown, and abort.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001294 SRG-APP-000189 <GroupDescription></GroupDescription> SRG-APP-000189 Application software used to detect the presence of unauthorized software must employ automated detection mechanisms and notify designated organizational officials in accordance with the organization-defined frequency. <VulnDiscussion>Scanning software is purpose built to check for vulnerabilities in the information system and hosted applications and is also used to enumerate platforms, software flaws, and improper configurations. Organizations are required to scan for vulnerabilities in information systems and hosted applications on an organization defined frequency and/or randomly in accordance with an organization defined process. Scanning software includes the capability to scan for specific functions, applications, ports, protocols, and services that should not be accessible to users or devices and for improperly configured or incorrectly operating information flow mechanisms. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001069 SRG-APP-NA <GroupDescription></GroupDescription> SRG-APP-NA The organization (or information system) must enforce explicit rules governing the installation of software by users. <VulnDiscussion>If provided the privilege, information system users have the ability to install software. This can create security related issues if the users install unapproved or insecurely written software. The organization shall identify what types of software installations are permitted (e.g., updates and security patches to existing software) and what types of installations are prohibited (e.g., software whose pedigree with regard to being potentially malicious is unknown or suspect). This is an OS requirement and does not apply to applications.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000663 SRG-APP-000190 <GroupDescription></GroupDescription> SRG-APP-000190 The application must terminate the network connection associated with a communications session at the end of the session or after an organization-defined time period of inactivity. <VulnDiscussion>This requirement applies to both internal and external networks. Terminating network connections associated with communications sessions include, de-allocating associated TCP/IP address/port pairs at the operating-system level, or de-allocating networking assignments at the application level if multiple application sessions are using a single, operating system-level network connection. The time period of inactivity may, as the organization deems necessary, be a set of time periods by type of network access or for specific accesses. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001133 SRG-APP-000191 <GroupDescription></GroupDescription> SRG-APP-000191 The application must establish a trusted communications path between the user and organization-defined security functions within the information system. <VulnDiscussion>The application user interface must provide an unspoofable and faithful communication channel between the user and any entity trusted to manipulate authorities on the user's behalf. A trusted path shall be employed for high-confidence connections between the security functions of the information system and the user (e.g., for login). </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001135 SRG-APP-000192 <GroupDescription></GroupDescription> SRG-APP-000192 Applications involved in the production, control, and distribution of symmetric cryptographic keys must use NIST-approved or NSA-approved key management technology and processes. <VulnDiscussion>Cryptographic key management and establishment can be performed using manual procedures or automated mechanisms with supporting manual procedures. In addition to being required for the effective operation of a cryptographic mechanism, effective cryptographic key management provides protections to maintain the availability of the information in the event of the loss of cryptographic keys by users. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001140 SRG-APP-000193 <GroupDescription></GroupDescription> SRG-APP-000193 Applications involved in the production, control, and distribution of symmetric and asymmetric cryptographic keys must use NIST-approved or NSA-approved key management technology and processes. <VulnDiscussion>Cryptographic key management and establishment can be performed using manual procedures or automated mechanisms with supporting manual procedures. In addition to being required for the effective operation of a cryptographic mechanism, effective cryptographic key management provides protections to maintain the availability of the information in the event of the loss of cryptographic keys by users. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001141 SRG-APP-000194 <GroupDescription></GroupDescription> SRG-APP-000194 Applications involved in the production, control, and distribution of asymmetric cryptographic keys must use must use approved PKI Class 3 certificates or prepositioned keying material. <VulnDiscussion>Cryptographic key management and establishment can be performed using manual procedures or automated mechanisms with supporting manual procedures. In addition to being required for the effective operation of a cryptographic mechanism, effective cryptographic key management provides protections to maintain the availability of the information in the event of the loss of cryptographic keys by users. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001142 SRG-APP-000263 <GroupDescription></GroupDescription> SRG-APP-000263 Applications must provide automated support for the management of distributed security testing. <VulnDiscussion>The need to verify security functionality applies to all security functions. For those security functions that are not able to execute automated self-tests the organization either implements compensating security controls or explicitly accepts the risk of not performing the verification as required. Information system transitional states include: startup, restart, shutdown, and abort.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001295 SRG-APP-000195 <GroupDescription></GroupDescription> SRG-APP-000195 Applications involved in the production, control, and distribution of asymmetric cryptographic keys must use approved PKI Class 3 or class 4 certificates and hardware tokens that protect the users private key. <VulnDiscussion>Cryptographic key management and establishment can be performed using manual procedures or automated mechanisms with supporting manual procedures. In addition to being required for the effective operation of a cryptographic mechanism, effective cryptographic key management provides protections to maintain the availability of the information in the event of the loss of cryptographic keys by users. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001143 SRG-APP-000262 <GroupDescription></GroupDescription> SRG-APP-000262 Applications utilized for integrity verification must detect unauthorized changes to software and information. <VulnDiscussion>Organizations are required to employ integrity verification applications on information systems to look for evidence of information tampering, errors, and omissions. The organization is also required to employ good software engineering practices with regard to commercial off-the-shelf integrity mechanisms (e.g., parity checks, cyclical redundancy checks, and cryptographic hashes) and uses tools to automatically monitor the integrity of the information system and the applications it hosts.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001297 SRG-APP-000261 <GroupDescription></GroupDescription> SRG-APP-000261 Applications that are utilized to address the issue of SPAM and provide protection from SPAM must automatically update any and all SPAM protection measures including signature definitions. <VulnDiscussion>Originators of SPAM emails are constantly changing their source email addresses in order to defeat SPAM countermeasures; therefore, SPAM software must be constantly updated to address the changing threat. A manual update procedure is labor intensive and does not scale well in an enterprise environment which necessitates an automatic update capability.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001308 SRG-APP-000196 <GroupDescription></GroupDescription> SRG-APP-000196 The application must implement required cryptographic protections using cryptographic modules complying with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. <VulnDiscussion>Cryptography is only as strong as the encryption modules/algorithms employed to encrypt the data. Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001144 SRG-APP-NA <GroupDescription></GroupDescription> SRG-APP-NA The organization must employ malicious code protection mechanisms at information system entry and exit points to detect and take action on unsolicited messages transported by electronic mail, electronic mail attachments, web accesses, removable media, or other common means. <VulnDiscussion>Unsolicited email messages otherwise known as SPAM are known to be one of the primary vectors for the propagation of many types of attacks including phishing attacks. SPAM and malware protection techniques include examining email messages, files, and web traffic at border gateways or proxies to determine if the traffic contains SPAM or some other type of malware. This is a requirement to deploy SPAM protection at certain locations on the network. This requirement does not apply to applications.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001305 SRG-APP-NA <GroupDescription></GroupDescription> SRG-APP-NA The organization must employ malicious code protection mechanisms at workstations, servers, or mobile computing devices on the network to detect and take action on unsolicited messages transported by electronic mail, electronic mail attachments, and web accesses. <VulnDiscussion>Senders of SPAM messages are continually modifying their tactics and source email addresses in order to elude protection mechanisms. To stay up-to-date with the changing threat and to identify SPAM messages, it is critical that SPAM protection mechanisms are kept current. Unsolicited email messages otherwise known as SPAM are known to be one of the primary vectors for the propagation of many types of attacks including phishing attacks. SPAM and malware protection techniques include examining email messages, files, and web traffic at border gateways or proxies to determine if the traffic contains SPAM or some other type of malware. This is a requirement to utilize SPAM prevention and anti-virus/malware software on workstations, servers, and laptops. This requirement does not apply to applications. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001677 SRG-APP-000260 <GroupDescription></GroupDescription> SRG-APP-000260 Applications that serve to protect organizations and individuals from SPAM messages must incorporate update mechanisms updating protection mechanisms and signature updates when new application releases are available in accordance with organizational configuration management policy and procedures. <VulnDiscussion>Senders of SPAM messages are continually modifying their tactics and source email addresses in order to elude protection mechanisms. To stay up-to-date with the changing threat and to identify SPAM messages, it is critical that SPAM protection mechanisms are kept current.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001306 SRG-APP-000115 <GroupDescription></GroupDescription> SRG-APP-000115 Applications must provide the capability to automatically process audit records for events of interest based upon selectable, event criteria. <VulnDiscussion>Audit reduction is used to reduce the volume of audit records in order to facilitate manual review. Before a security review information systems and/or applications with an audit reduction capability may remove many audit records known to have little security significance. This is generally accomplished by removing records generated by specified classes of events, such as records generated by nightly backups. An audit reduction capability provides support for near real-time audit review and analysis based on policy requirements regarding what must be audited on the system and after-the-fact investigations of security incidents. It is important to recognize audit reduction does not alter original audit records. Audit reduction and reporting tools do not alter original audit records. To leverage the complete capability of audit reduction, the application must possess the ability to specify and automatically process certain event criteria that are selectable in nature. In other words, a system administrator (SA) may be performing a manual review of audit data to identify a particular problem. The SA has determined that backup activity and network connections from a particular host comprise the bulk of the events. However, these events are not related to the activity being investigated. The application must be able to automatically process these audit records for audit reduction purposes rather than making the administrator manually process them.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000158 SRG-APP-000116 <GroupDescription></GroupDescription> SRG-APP-000116 Applications must use internal system clocks to generate time stamps for audit records. <VulnDiscussion>Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Time stamps generated by the information system shall include both date and time. The time may be expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000159 SRG-APP-000117 <GroupDescription></GroupDescription> SRG-APP-000117 The application must synchronize with internal information system clocks which in turn, are synchronized on an organization-defined frequency with an organization-defined authoritative time source. <VulnDiscussion>Determining the correct time a particular application event occurred on a system is critical when conducting forensic analysis and investigating system events. Synchronization of system clocks is needed in order to correctly correlate the timing of events that occur across multiple systems. To meet that requirement the organization will define an authoritative time source and frequency to which each system will synchronize its internal clock. An example is utilizing the NTP protocol to synchronize with centralized NTP servers. Time stamps generated by the information system shall include both date and time. The time may be expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC. Applications not purposed to provide NTP services should not try to compete with or replace NTP functionality and should synchronize with internal information system clocks that are in turn synchronized with an organization defined authoritative time source.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000160 SRG-APP-000118 <GroupDescription></GroupDescription> SRG-APP-000118 The application must protect audit information from any type of unauthorized access. <VulnDiscussion>If audit data were to become compromised then competent forensic analysis and discovery of the true source of potentially malicious system activity is difficult if not impossible to achieve. In addition, access to audit records provides information an attacker could potentially use to his or her advantage. To ensure the veracity of audit data the information system and/or the application must protect audit information from any and all unauthorized access. This includes read, write, copy, etc. This requirement can be achieved through multiple methods which will depend upon system architecture and design. Some commonly employed methods include ensuring log files enjoy the proper file system permissions utilizing file system protections and limiting log data location. Additionally, applications with user interfaces to audit records should not allow for the unfettered manipulation of or access to those records via the application. If the application provides access to the audit data, the application becomes accountable for ensuring that audit information is protected from unauthorized access. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000162 SRG-APP-000197 <GroupDescription></GroupDescription> SRG-APP-000197 Applications must employ FIPS-validated cryptography to protect unclassified information. <VulnDiscussion>Cryptography is only as strong as the encryption modules/algorithms employed to encrypt the data. Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001145 SRG-APP-000119 <GroupDescription></GroupDescription> SRG-APP-000119 The application must protect audit information from unauthorized modification. <VulnDiscussion>If audit data were to become compromised then competent forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. To ensure the veracity of audit data the information system and/or the application must protect audit information from unauthorized modification. This requirement can be achieved through multiple methods which will depend upon system architecture and design. Some commonly employed methods include ensuring log files enjoy the proper file system permissions, and limiting log data locations. Applications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights that the user enjoys in order to make access decisions regarding the modification of audit data. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000163 SRG-APP-000198 <GroupDescription></GroupDescription> SRG-APP-000198 Applications must employ NSA-approved cryptography to protect classified information. <VulnDiscussion>Cryptography is only as strong as the encryption modules/algorithms employed to encrypt the data. Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. NSA has developed Type 1 algorithms for protecting classified information. The Committee on National Security Systems (CNSS) National Information Assurance Glossary (CNSS Instruction No. 4009) defines Type 1 products as: “Cryptographic equipment, assembly or component classified or certified by NSA for encrypting and decrypting classified and sensitive national security information when appropriately keyed. Developed using established NSA business processes and containing NSA approved algorithms are used to protect systems requiring the most stringent protection mechanisms.†NSA-approved cryptography is required to be used for classified information system processing.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001146 SRG-APP-000199 <GroupDescription></GroupDescription> SRG-APP-000199 Applications must employ FIPS-validated cryptography to protect unclassified information when such information must be separated from individuals who have the necessary clearances yet lack the necessary access approvals. <VulnDiscussion>Cryptography is only as strong as the encryption modules/algorithms employed to encrypt the data. Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. FIPS 140-2 Security Requirements for Cryptographic Modules can be found at the following web site: http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf. Although persons may have a security clearance, they may not have a "need to know" and are required to be separated from the information in question. Applications must employ FIPS validated cryptography to protect unclassified information from those individuals who have no "need to know". </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001147 SRG-APP-NA <GroupDescription></GroupDescription> SRG-APP-NA Applications must employ FIPS-validated or NSA-approved cryptography to implement digital signatures. <VulnDiscussion>Cryptography is only as strong as the encryption modules/algorithms employed to encrypt the data. Use of weak or un-tested encryption algorithms undermines the purposes of utilizing encryption to protect data. The integrity and reliability of the algorithms used to generate digital signatures is just as important as those used to encrypt data. Digital signatures provide non-repudiation and authenticity of a message or document, therefore, it is imperative that applications employ FIPS validated algorithms when generating digital signatures to be applied to unclassified data and NSA approved algorithms when generating signatures to be applied to classified data. This application requirement is not applicable. This requirement is addressed by CCI-001342 which requires applications to meet policy and legal requirements regarding the use of approved encryption technology. CCI-001342 is a comprehensive cryptography requirement that mandates the use of FIPS-validation or NSA-approved cryptography when using digital signatures.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001148 SRG-APP-000201 <GroupDescription></GroupDescription> SRG-APP-000201 The application must protect the integrity and availability of publicly available information and applications. <VulnDiscussion>The purpose of this control is to ensure organizations explicitly address the protection needs for public information and applications with such protection likely being implemented as part of other security controls. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001149 SRG-APP-000120 <GroupDescription></GroupDescription> SRG-APP-000120 The application must protect audit information from unauthorized deletion. <VulnDiscussion>If audit data were to become compromised then competent forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. To ensure the veracity of audit data the information system and/or the application must protect audit information from unauthorized deletion. This requirement can be achieved through multiple methods which will depend upon system architecture and design. Some commonly employed methods include: ensuring log files enjoy the proper file system permissions utilizing file system protections; restricting access and backing up log data to ensure log data is retained. Applications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights the user enjoys in order make access decisions regarding the deletion of audit data. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000164 SRG-APP-NA <GroupDescription></GroupDescription> SRG-APP-NA The information system or supporting environment must block both inbound and outbound traffic between instant messaging clients that are independently configured by end users and external service providers. <VulnDiscussion>Blocking restrictions do not include instant messaging services configured by an organization to perform an authorized function. This requirement specifies blocking any external IRC chat clients that are not configured and managed by the organization. This requirement does not apply to applications.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001154 SRG-APP-000121 <GroupDescription></GroupDescription> SRG-APP-000121 The application must protect audit tools from unauthorized access. <VulnDiscussion>Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Depending upon the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data. It is, therefore, imperative that access to audit tools be controlled and protected from unauthorized access. Applications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the access to audit tools. Audit tools include but are not limited to OS provided audit tools, vendor provided audit tools, and open source audit tools needed to successfully view and manipulate audit information system activity and records. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001493 SRG-APP-000122 <GroupDescription></GroupDescription> SRG-APP-000122 The application must protect audit tools from unauthorized modification. <VulnDiscussion>Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Depending upon the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data. If the tools are compromised it could provide attackers with the capability to manipulate log data. It is, therefore, imperative that audit tools be controlled and protected from unauthorized modification. Audit tools include but are not limited to OS provided audit tools, vendor provided audit tools, and open source audit tools needed to successfully view and manipulate audit information system activity and records. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001494 SRG-APP-000123 <GroupDescription></GroupDescription> SRG-APP-000123 The application must protect audit tools from unauthorized deletion. <VulnDiscussion>Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Depending upon the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data. If the tools are deleted, it would affect the administrator’s ability to access and review log data. Audit tools include but are not limited to OS provided audit tools, vendor provided audit tools, and open source audit tools needed to successfully view and manipulate audit information system activity and records.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001495 SRG-APP-000124 <GroupDescription></GroupDescription> SRG-APP-000124 The application must have the capability to produce audit records on hardware-enforced, write-once media. <VulnDiscussion>Applications are typically designed to incorporate their audit logs into the auditing sub-system hosted by the operating system. However, in some instances application developers may decide to forego the audit capabilities offered by the operating system and maintain application audit logs separately. The protection of audit records from unauthorized or accidental deletion or modification requires that information systems be able to produce audit records on hardware enforced write-once media. Applications that do not write audit records to a resource (e.g., underlying OS or separate system) that is capable of producing audit records on hardware enforced, write-once media must provide the capability to do so. This requirement is related to backup of records and not real-time creation of audit records. Examples of such hardware devices include, but are not limited to: CD-R or DVD-R.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000165 SRG-APP-000125 <GroupDescription></GroupDescription> SRG-APP-000125 The application must support the requirement to back up audit data and records onto a different system or media than the system being audited on an organization-defined frequency. <VulnDiscussion>Protection of log data includes assuring log data is not accidentally lost or deleted. Backing up audit records to a different system or onto separate media than the system being audited on an organizationally defined frequency helps to assure in the event of a catastrophic system failure, the audit records will be retained. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001348 SRG-APP-000202 <GroupDescription></GroupDescription> SRG-APP-000202 Software and/or firmware used for collaborative computing devices must prohibit remote activation excluding the organization-defined exceptions where remote activation is to be allowed. <VulnDiscussion>Collaborative computing devices include, networked white boards, cameras, and microphones. Collaborative software examples include instant messaging or chat clients. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001150 SRG-APP-000203 <GroupDescription></GroupDescription> SRG-APP-000203 The application must associate security attributes with information exchanged between information systems. <VulnDiscussion>When data is exchanged between information systems, the security attributes associated with said data needs to be maintained. Security attributes are an abstraction representing the basic properties or characteristics of an entity with respect to safeguarding information, typically associated with internal data structures (e.g., records, buffers, files) within the information system and used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. Security attributes may be explicitly or implicitly associated with the information contained within the information system. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001157 SRG-APP-000204 <GroupDescription></GroupDescription> SRG-APP-000204 The application must validate the integrity of security attributes exchanged between systems. <VulnDiscussion>When data is exchanged between information systems, the security attributes associated with said data needs to be maintained. Security attributes are an abstraction representing the basic properties or characteristics of an entity with respect to safeguarding information, typically associated with internal data structures (e.g., records, buffers, files) within the information system and used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. Security attributes may be explicitly or implicitly associated with the information contained within the information system. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001158 SRG-APP-000205 <GroupDescription></GroupDescription> SRG-APP-000205 Applications must support organizational requirements to issue public key certificates under an appropriate certificate policy or obtain public key certificates under an appropriate certificate policy from an approved service provider. <VulnDiscussion>For user certificates, each organization attains certificates from an approved, shared service provider, as required by OMB policy. For federal agencies operating a legacy public key infrastructure cross-certified with the Federal Bridge Certification Authority at medium assurance or higher, this Certification Authority will suffice. This control focuses on certificates with a visibility external to the information system and does not include certificates related to internal system operations, for example, application-specific time services. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001159 SRG-APP-000206 <GroupDescription></GroupDescription> SRG-APP-000206 Applications designed to address malware issues and/or enforce policy pertaining to organizational use of mobile code must implement detection and inspection mechanisms to identify unauthorized mobile code <VulnDiscussion>Decisions regarding the employment of mobile code within organizational information systems are based on the potential for the code to cause damage to the system if used maliciously. Mobile code technologies include: Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on organizational servers and mobile code downloaded and executed on individual workstations. Policy and procedures related to mobile code, address preventing the development, acquisition, or introduction of unacceptable mobile code within the information system. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001166 SRG-APP-000207 <GroupDescription></GroupDescription> SRG-APP-000207 Applications designed to address malware issues and/or enforce policy pertaining to organizational use of mobile code must take corrective actions, when unauthorized mobile code is identified. <VulnDiscussion>Decisions regarding the employment of mobile code within organizational information systems are based on the potential for the code to cause damage to the system if used maliciously. Mobile code technologies include: Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on organizational servers and mobile code downloaded and executed on individual workstations. Policy and procedures related to mobile code, address preventing the development, acquisition, or introduction of unacceptable mobile code within the information system. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001662 SRG-APP-000208 <GroupDescription></GroupDescription> SRG-APP-000208 Applications utilizing mobile code must meet policy requirements regarding the acquisition, development, and/or use of mobile code. <VulnDiscussion>Decisions regarding the employment of mobile code within organizational information systems are based on the potential for the code to cause damage to the system if used maliciously. Mobile code technologies include: Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on organizational servers and mobile code downloaded and executed on individual workstations. DoDI 8552.01 policy pertains to the use of mobile code technologies within DoD information systems. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001167 SRG-APP-000209 <GroupDescription></GroupDescription> SRG-APP-000209 Applications designed to enforce policy pertaining to organizational use of mobile code must prevent the download and execution of prohibited mobile code. <VulnDiscussion>Decisions regarding the employment of mobile code within organizational information systems are based on the potential for the code to cause damage to the system if used maliciously. Mobile code technologies include: Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on organizational servers and mobile code downloaded and executed on individual workstations. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001169 SRG-APP-000210 <GroupDescription></GroupDescription> SRG-APP-000210 Applications designed to enforce policy pertaining to the use of mobile code must prevent the automatic execution of mobile code in organization-defined software applications and require organization-defined actions prior to executing the code. <VulnDiscussion>Decisions regarding the employment of mobile code within organizational information systems are based on the potential for the code to cause damage to the system if used maliciously. Mobile code technologies include: Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on organizational servers and mobile code downloaded and executed on individual workstations. Organization-defined software may be a specific application, web site or web sites in general. Organization-defined actions include but are not limited to: alerts to the user, logging actions, a centralized alarm, or any combination thereof.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001170 SRG-APP-000211 <GroupDescription></GroupDescription> SRG-APP-000211 The application must separate user functionality (including user interface services) from information system management functionality. <VulnDiscussion>Information system management functionality includes, functions necessary to administer databases, network components, workstations, or servers, and typically requires privileged user access. The separation of user functionality from information system management functionality is either physical or logical and is accomplished by using different computers, different central processing units, different instances of the operating system, different network addresses, combinations of these methods, or other methods, as appropriate. An example of this type of separation is observed in web administrative interfaces that use separate authentication methods for users of any other information system resources. This may include isolating the administrative interface on a different domain and with additional access controls. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001082 SRG-APP-000212 <GroupDescription></GroupDescription> SRG-APP-000212 The application must prevent the presentation of information system management-related functionality at an interface utilized by general (i.e., non-privileged) users. <VulnDiscussion>Information system management functionality includes, functions necessary to administer databases, network components, workstations, or servers, and typically requires privileged user access. The separation of user functionality from information system management functionality is either physical or logical and is accomplished by using different computers, different central processing units, different instances of the operating system, different network addresses, combinations of these methods, or other methods as appropriate. An example of this type of separation is observed in web administrative interfaces that use separate authentication methods for users of any other information system resources. This may include isolating the administrative interface on a different domain and with additional access controls. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001083 SRG-APP-000213 <GroupDescription></GroupDescription> SRG-APP-000213 The application must provide additional data origin and integrity artifacts along with the authoritative data the system returns in response to name/address resolution queries. <VulnDiscussion>This control enables remote clients to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service. A Domain Name System (DNS) server is an example of an information system providing name/address resolution service. Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are examples of authoritative data. Information systems using technologies other than the DNS to map between host/service names and network addresses provide other means to assure the authenticity and integrity of response data. The DNS security controls are consistent with, and referenced from, OMB Memorandum 08-23. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001178 SRG-APP-000214 <GroupDescription></GroupDescription> SRG-APP-000214 Applications, when operating as part of a distributed, hierarchical namespace, must provide the means to indicate the security status of child subspaces and (if the child supports secure resolution services) enable verification of a chain of trust among parent and child domains. <VulnDiscussion>This control enables remote clients to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service. A Domain Name System (DNS) server is an example of an information system providing name/address resolution service. Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are examples of authoritative data. Information systems using technologies other than the DNS to map between host/service names and network addresses provide other means to assure the authenticity and integrity of response data. The DNS security controls are consistent with, and referenced from, OMB Memorandum 08-23. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001179 SRG-APP-000215 <GroupDescription></GroupDescription> SRG-APP-000215 The application must perform data origin authentication and data integrity verification on the name/address resolution responses the system receives from authoritative sources when requested by client systems. <VulnDiscussion>A recursive resolving or caching Domain Name System (DNS) server is an example of an information system providing name/address resolution service for local clients. Authoritative DNS servers are examples of authoritative sources. Information systems using technologies other than the DNS to map between host/service names and network addresses provide other means to enable clients to verify the authenticity and integrity of response data. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001663 SRG-APP-000232 <GroupDescription></GroupDescription> SRG-APP-000232 Applications handling data requiring "data at rest" protections must employ cryptographic mechanisms to prevent unauthorized disclosure and modification of the information that is at rest unless otherwise protected by alternative physical measures. <VulnDiscussion>This control is intended to address the confidentiality and integrity of information at rest in non-mobile devices and covers user information and system information. Information at rest refers to the state of information when it is located on a secondary storage device (e.g., disk drive, tape drive) within an organizational information system. Alternative physical protection measures include, protected distribution systems. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001200 SRG-APP-000235 <GroupDescription></GroupDescription> SRG-APP-000235 Applications must isolate security functions enforcing access and information flow control from both non-security functions and from other security functions. <VulnDiscussion>Application functionality is typically broken down into modules that perform various tasks or roles. Examples of non-privileged application functionality include, but are not limited to, application modules written for displaying data or printing reports. Application security functionality that performs security tasks such as enforcing access and information flow control requires additional system privilege and can have a large impact on the security of the application and its data. Rather than allowing the entire application access to this security functionality, application developers must isolate these critical functions from non-privileged application functions and other security functions.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001086 SRG-APP-NA <GroupDescription></GroupDescription> SRG-APP-NA The information system must protect wireless access to the system using encryption. <VulnDiscussion>Wireless technologies include, but are not limited to, microwave, satellite, packet radio (UHF/VHF), 802.11x, and Bluetooth. Wireless networks use authentication protocols (e.g., EAP/TLS, PEAP), which provide credential protection and mutual authentication. In certain situations, wireless signals may radiate beyond the confines and control of organization-controlled facilities. When systems connect to a wireless access point there is a requirement to authenticate. Authentication applies to user, device, or both as necessary. Authentication data needs to be protected by encryption. This is a wireless access requirement regarding WAP encryption. This requirement does not apply to applications. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001444 SRG-APP-NA <GroupDescription></GroupDescription> SRG-APP-NA The information system must protect wireless access to the system using authentication. <VulnDiscussion>Wireless technologies include, but are not limited to, microwave, satellite, packet radio (UHF/VHF), 802.11x, and Bluetooth. Wireless networks use authentication protocols (e.g., EAP/TLS, PEAP), which provide credential protection and mutual authentication. In certain situations, wireless signals may radiate beyond the confines and control of organization-controlled facilities. When systems connect to a wireless access point they need to be authenticated by the WAP. Authentication applies to user, device, or both as necessary. This is a wireless access requirement regarding WAP authentication. This requirement does not apply to applications.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001443 SRG-APP-000140 <GroupDescription></GroupDescription> SRG-APP-000140 The application must enforce requirements for remote connections to the information system. <VulnDiscussion>Applications that provide remote access to information systems must be able to enforce remote access policy requirements or work in conjunction with enterprise tools designed to enforce policy requirements. Examples of policy requirements include but are not limited to; authorizing remote access to the information system, limiting access based on authentication credentials and monitoring for unauthorized access. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000066 SRG-APP-000227 <GroupDescription></GroupDescription> SRG-APP-000227 Applications must enforce requirements regarding the connection of mobile devices to organizational information systems. <VulnDiscussion>Applications designed to manage the connection of mobile devices to information systems must be able to enforce organizational connectivity requirements or work in conjunction with enterprise tools designed to enforce policy requirements. Mobile devices include portable storage media (e.g., USB memory sticks, external hard disk drives) and portable computing and communications devices with information storage capability (e.g., notebook/laptop computers, personal digital assistants, cellular telephones, digital cameras, and audio recording devices). Organizational connectivity requirements may include usage restrictions and implementation guidance related to mobile devices. For example, the organization may require the device be part of the configuration management environment or may require mandatory protective software be installed prior to connecting to the infrastructure (e.g., malicious code detection or a firewall). Scanning devices for malicious code may be required prior to connecting as well as updating virus protection software, scanning for critical software updates and patches, conducting primary operating system (and possibly other resident software) integrity checks, and disabling unnecessary hardware (e.g., wireless, infrared). An example of information system functionality that may need to be disabled prior to connecting includes the capability for automatic execution of code such as AutoRun and AutoPlay.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000086 SRG-APP-000228 <GroupDescription></GroupDescription> SRG-APP-000228 The application must disable network access by unauthorized components/devices or notify designated organizational officials. <VulnDiscussion>Maintaining system and network integrity requires all systems on the network are identified and accounted for. Without an accurate accounting of systems utilizing the network, the opportunity exists for the introduction of rogue systems. The significance of this manner of security compromise increases exponentially over time and could become a persistent threat. Therefore, organizations must employ automated mechanisms to detect the addition unauthorized devices. Information deemed to be necessary by the organization to achieve effective property accountability can include, for example, hardware inventory specifications (manufacturer, type, model, serial number, physical location), software license information, information system/component owner, and for a networked component/device, the machine name and network address. The monitoring for unauthorized components/devices on information system networks may be accomplished on an ongoing basis or by the periodic scanning of organizational networks for that purpose. Automated mechanisms can be implemented within the information system and/or in another separate information system or device. Applications that are designed as systems configuration management solutions or other solutions developed specifically to fill the role of identifying or managing systems in the enterprise must be able to either disable the identified device or notify the appropriate personnel when new systems have been introduced into the environment. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-000417 SRG-APP-NA <GroupDescription></GroupDescription> SRG-APP-NA The organization must protect against unauthorized physical connections across the boundary protections implemented at an organization-defined list of managed interfaces. <VulnDiscussion>This is a requirement to protect against physically by-passing the firewall interfaces by moving ethernet cables. This does not apply to applications.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001121 SRG-APP-000234 <GroupDescription></GroupDescription> SRG-APP-000234 The information system must automatically terminate emergency accounts after an organization-defined time period for each type of account. <VulnDiscussion>Emergency application accounts are typically created due to an unforeseen operational event or could ostensibly be used in the event of a vendor support visit where a support representative requires a temporary unique account in order to perform diagnostic testing or conduct some other support related activity. When these types of accounts are created, there is a risk that the temporary account may remain in place and active after the support representative has left. In the event emergency application accounts are required, the application must ensure that accounts designated as temporary in nature shall automatically terminate these accounts after an organization-defined time period. Such a process and capability greatly reduces the risk that accounts will be misused, hijacked, or application data compromised. To address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms that meet or exceed access control policy requirements. Such an integration allows the application developer to off-load those access control functions and focus on core application features and functionality. Examples of enterprise level authentication/access mechanisms include but are not limited to Active Directory and LDAP. The application must provide or utilize a mechanism to automatically terminate accounts that have been designated as temporary or emergency accounts after an organization defined time period.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001682 SRG-APP-000291 <GroupDescription></GroupDescription> SRG-APP-000291 The application must notify appropriate individuals when accounts are created. <VulnDiscussion>Once an attacker establishes initial access to a system, they often attempt to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply create a new account. Notification of account creation is one method and best practice for mitigating this risk. A comprehensive account management process will ensure that an audit trail which documents the creation of application user accounts and notifies administrators and/or application owners exists. Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes. To address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality. Examples of enterprise level authentication/access mechanisms include but are not limited to Active Directory and LDAP. Applications must support the requirement to notify appropriate individuals upon account creation.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001683 SRG-APP-000292 <GroupDescription></GroupDescription> SRG-APP-000292 The application must notify appropriate individuals when accounts are modified. <VulnDiscussion>Once an attacker establishes initial access to a system, they often attempt to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply modify or copy an existing account. Notification of account modification is one method and best practice for mitigating this risk. A comprehensive account management process will ensure that an audit trail which documents the modification of application user accounts and notifies administrators and/or application owners exists. Such a process greatly reduces the risk that accounts will be surreptitiously created or modified and provides logging that can be used for forensic purposes. To address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality. Examples of enterprise level authentication/access mechanisms include but are not limited to Active Directory and LDAP. Applications must support the requirement to notify appropriate individuals when accounts are modified.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001684 SRG-APP-000293 <GroupDescription></GroupDescription> SRG-APP-000293 The application must notify appropriate individuals when account disabling actions are taken. <VulnDiscussion>When application accounts are disabled, user accessibility is affected. Accounts are utilized for identifying individual application users or for identifying the application processes themselves. In order to detect and respond to events that affect user accessibility and application processing, applications must audit account disabling actions and, as required, notify as required the appropriate individuals so they can investigate the event. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and also provides logging that can be used for forensic purposes. To address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality. Examples of enterprise level authentication/access mechanisms include but are not limited to Active Directory and LDAP. Applications must notify, or leverage other mechanisms that notify, the appropriate individuals when accounts disabling actions are taken.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001685 SRG-APP-000294 <GroupDescription></GroupDescription> SRG-APP-000294 The application must notify appropriate individuals when accounts are terminated. <VulnDiscussion>When application accounts are terminated, user accessibility is affected. Accounts are utilized for identifying individual application users or for identifying the application processes themselves. In order to detect and respond to events that affect user accessibility and application processing, applications must notify the appropriate individuals when an account is terminated so they can investigate the event. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes. To address the multitude of policy based audit requirements, and to ease the burden of meeting these requirements, many application developers choose to integrate their applications with enterprise level authentication/access/audit mechanisms that meet or exceed access control policy requirements. Examples include but are not limited to Active Directory and LDAP. The application must automatically notify the appropriate individuals when accounts are terminated.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001686 SRG-APP-000074 <GroupDescription></GroupDescription> SRG-APP-000074 Applications utilizing mobile code must meet DoD-defined mobile code requirements. <VulnDiscussion>Decisions regarding the deployment of mobile code within organizational information systems are based on the potential for the code to cause damage to the system if used maliciously. Mobile code technologies include but are not limited to: Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on organizational servers and mobile code downloaded and executed on individual workstations. DoDI 8552.01 policy pertains to the use of mobile code technologies within DoD information systems. Applications utilizing mobile code must meet policy requirements regarding the deployment, and/or use of mobile code. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001687 SRG-APP-000290 <GroupDescription></GroupDescription> SRG-APP-000290 The application must use cryptographic mechanisms to protect the integrity of audit tools. <VulnDiscussion>Protecting the integrity of the tools used for auditing purposes is a critical step to ensuring the integrity of audit data. Audit data includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. It is not uncommon for attackers to replace the audit tools or inject code into the existing tools with the purpose of providing the capability to hide or erase system activity from the audit logs. To address this risk, audit tools must be cryptographically signed in order to provide the capability to identify when the audit tools have been modified, manipulated or replaced. An example is a checksum hash of the file or files. Applications that function as audit tools must use cryptographic mechanisms to protect the integrity of the tools or allow cryptographic protection mechanisms to be applied to their tools. All applications must not impede or hamper this requirement.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001496 SRG-APP-000237 <GroupDescription></GroupDescription> SRG-APP-000237 The application must employ automated mechanisms to alert security personnel of inappropriate or unusual activities with security implications. <VulnDiscussion>Applications will typically utilize logging mechanisms for maintaining a historical log of activity that occurs within the application. This information can then be used for diagnostic purposes, forensics purposes or other purposes relevant to ensuring the availability and integrity of the application. While it is important to log events identified as being critical and relevant to security, it is equally important to notify the appropriate personnel in a timely manner so they are able to respond to events as they occur. Solutions that include a manual notification procedure do not offer the reliability and speed of an automated notification solution. Applications must employ automated mechanisms to alert security personnel of inappropriate or unusual activities that have security implications. If this capability is not built directly into the application, the application must be able to integrate with existing security infrastructure that provides this capability.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001274 SRG-APP-000085 <GroupDescription></GroupDescription> SRG-APP-000085 Applications utilizing Discretionary Access Control (DAC) must enforce a policy that limits propagation of access rights. <VulnDiscussion>Discretionary Access Control (DAC) is based on the premise that individual users are "owners" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment. DAC allows the owner to determine who will have access to objects they control. An example of DAC includes user controlled file permissions. DAC models have the potential for the access controls to propagate without limit resulting in unauthorized access to said objects. When applications provide a discretionary access control mechanism, the application must be able to limit the propagation of those access rights.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001693 SRG-APP-000087 <GroupDescription></GroupDescription> SRG-APP-000087 Applications that utilize Discretionary Access Control (DAC) must enforce a policy that Includes or excludes access to the granularity of a single user. <VulnDiscussion>DAC is based on the notion that individual users are "owners" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment. DAC allows the owner to determine who will have access to objects they control. An example of DAC includes user controlled file permissions. Including or excluding access to the granularity of a single user means providing the capability to either allow or deny access to objects (e.g., files, folders) on a per single user basis. Applications that utilize Discretionary Access Control (DAC) must enforce a policy that includes or excludes access to the granularity of a single user.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001694 SRG-APP-NA <GroupDescription></GroupDescription> SRG-APP-NA The application must ensure the acquisition of mobile code to be deployed in information systems meets organization-defined mobile code requirements. <VulnDiscussion>Decisions regarding the acquisition of mobile code within organizational information systems need to include evaluations that determine the potential for the code to cause damage to the system if used maliciously. Mobile code technologies include, for example, Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on organizational servers and mobile code downloaded and executed on individual workstations. DoDI 8552.01 policy pertains to the use of mobile code technologies within DoD information systems. Mobile code that is acquired for use and deployment in DoD information systems must meet DoD policy requirements This requirement relates to the acquisition of mobile code. The purpose is to ensure DoD organizations review applications which utilize mobile code to ensure they adhere to DoD mobile code policy prior to acquiring these applications and introducing them into the DoD environment. This is not an application specific requirement and is Not Applicable to applications.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001688 SRG-APP-000112 <GroupDescription></GroupDescription> SRG-APP-000112 The application must prevent the execution of prohibited mobile code. <VulnDiscussion>Decisions regarding the utilization of mobile code within organizational information systems needs to include evaluations which help determine the potential for the code to cause damage to the system if used maliciously. Mobile code technologies include, for example, Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on organizational servers and mobile code downloaded and executed on individual workstations. Applications can prevent the execution of prohibited mobile code by leveraging architectures that provide a virtual execution environment sometimes referred to as a "sandbox". The mobile code is executed within this isolated environment apart from the hosts indigenous operating environment which allows for mobile code capability restrictions and helps to prevent malicious code from accessing system resources and data. Policy and procedures related to mobile code address preventing the introduction of unacceptable mobile code within the information system. The DoDI 8552.01 policy pertains to the use of mobile code technologies within DoD information systems. The application must prevent the execution of prohibited mobile code. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SecurityOverrideGuidance></SecurityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> CCI-001695 scap-security-guide-0.1.31/RHEVM3/transforms/000077500000000000000000000000001301675746700206445ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEVM3/transforms/cce_extract.py000077500000000000000000000003521301675746700235050ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import cce_extract_module if __name__ == "__main__": cce_extract_module.main() scap-security-guide-0.1.31/RHEVM3/transforms/cci2html.xsl000066400000000000000000000004661301675746700231070ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEVM3/transforms/constants.xslt000066400000000000000000000021421301675746700235730ustar00rootroot00000000000000 Red Hat Enterprise Virtualization Manager RHEVM RHEVM_3_STIG rhevm empty RHEVM-3 cpe:/o:redhat:enterprise_linux:6 scap-security-guide-0.1.31/RHEVM3/transforms/shorthand2xccdf.xslt000066400000000000000000000005131301675746700246430ustar00rootroot00000000000000 unknown unlinked-rhevm3-oval.xml scap-security-guide-0.1.31/RHEVM3/transforms/splitchecks.py000077500000000000000000000003521301675746700235350ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import splitchecks_module if __name__ == "__main__": splitchecks_module.main() scap-security-guide-0.1.31/RHEVM3/transforms/table-add-srgitems.xslt000066400000000000000000000010741301675746700252320ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEVM3/transforms/table-sortbyref.xslt000066400000000000000000000005551301675746700246710ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEVM3/transforms/table-srgmap.xslt000066400000000000000000000011401301675746700241320ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEVM3/transforms/table-style.xslt000066400000000000000000000002511301675746700240030ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEVM3/transforms/xccdf-alt-titles.xslt000066400000000000000000000005021301675746700247240ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEVM3/transforms/xccdf-apply-overlay-stig.xslt000066400000000000000000000007511301675746700264200ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEVM3/transforms/xccdf-removeaux.xslt000066400000000000000000000005011301675746700246540ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEVM3/transforms/xccdf2csv-stig.py000077500000000000000000000003601301675746700240510ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import xccdf2csv_stig_module if __name__ == "__main__": xccdf2csv_stig_module.main() scap-security-guide-0.1.31/RHEVM3/transforms/xccdf2html.xslt000066400000000000000000000005501301675746700236160ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEVM3/transforms/xccdf2shorthand.xslt000066400000000000000000000005011301675746700246400ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEVM3/transforms/xccdf2stigformat.xslt000066400000000000000000000006751301675746700250410ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEVM3/transforms/xccdf2table-byref.xslt000066400000000000000000000006741301675746700250550ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEVM3/transforms/xccdf2table-cce.xslt000066400000000000000000000007331301675746700244740ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEVM3/transforms/xccdf2table-profileccirefs.xslt000066400000000000000000000015721301675746700267430ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEVM3/transforms/xccdf2table-profilecisrefs.xslt000066400000000000000000000007051301675746700267600ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEVM3/transforms/xccdf2table-profilenistrefs.xslt000066400000000000000000000007051301675746700271570ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEVM3/transforms/xccdf2table-stig.xslt000066400000000000000000000006731301675746700247130ustar00rootroot00000000000000 scap-security-guide-0.1.31/RHEVM3/utils/000077500000000000000000000000001301675746700176065ustar00rootroot00000000000000scap-security-guide-0.1.31/RHEVM3/utils/README000066400000000000000000000010211301675746700204600ustar00rootroot00000000000000This file is meant to give a quick overview to some of the scripts located in this directory. verify-input-sanity.py Purpose: This script can be invoked without arguments to examine the files within src/input to make sure that they are in good shape *prior to* building the XCCDF and OVAL content with the various make commands. Intent: Help XCCDF and OVAL developers spot common mistakes *before* utilizing the Makefile to build the XCCDF and OVAL content. Usage: ../../shared/utils/verify-input-sanity.py scap-security-guide-0.1.31/RHEVM3/utils/sync-alt-titles.py000077500000000000000000000003621301675746700232200ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import sync_alt_titles_module if __name__ == "__main__": sync_alt_titles_module.main() scap-security-guide-0.1.31/SUSE/000077500000000000000000000000001301675746700162615ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/11/000077500000000000000000000000001301675746700165025ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/11/Makefile000066400000000000000000000210731301675746700201450ustar00rootroot00000000000000all: tables guide content dist SHARED = ../../shared include $(SHARED)/product-make.include PROD = sle11 OVAL_DIRS=$(SHARED_OVAL) $(IN)/oval VENDOR = ssgproject checks: # If openscap on the system supports OVAL-5.11 language version, include also OVAL-5.11 checks # into final list of OVAL checks ifeq ($(OVAL_5_11), 0) # SUSE/11//input/oval/oval_5.11 is empty for now!!! Uncomment the next statement once required # find $(IN)/oval/oval_5.11 -maxdepth 1 -type f -name '*.xml' -exec cp {} $(PROD_OVAL) ';' # System supports OVAL-5.11 => propagate 'RUNTIME_OVAL_VERSION' variable into the environment $(eval MOD_ENV := env RUNTIME_OVAL_VERSION='5.11') $(eval OVAL_DIRS+=$(SHARED_OVAL_5_11)) endif find $(OVAL_DIRS) -name "*.xml" | xargs xmlwf $(MOD_ENV) $(SHARED)/$(UTILS)/combine-ovals.py $(CONF) $(PROD) $(OVAL_DIRS) > $(OUT)/unlinked-$(PROD)-oval.xml xmllint --format --output $(OUT)/unlinked-$(PROD)-oval.xml $(OUT)/unlinked-$(PROD)-oval.xml # example, if needed: for converting XCCDF into shorthand #xccdf2shorthand: # xsltproc -o $(XCCDF_OUTPUT_DIR)/suse11-shorthand.xml $(TRANS)/xccdf2shorthand.xslt $(REFS)/usgcb-suse11desktop-xccdf.xml # tidy -m -xml -utf8 --indent-spaces=0 $(XCCDF_OUTPUT_DIR)/suse11-shorthand.xml table-refs: $(OUT)/xccdf-unlinked-empty-groups.xml xsltproc -stringparam ref "nist" -o $(OUT)/table-$(PROD)-nistrefs.html $(TRANS)/xccdf2table-byref.xslt $< xsltproc -stringparam profile "common" -o $(OUT)/table-$(PROD)-nistrefs-common.html \ $(TRANS)/xccdf2table-profilenistrefs.xslt $< table-idents: $(OUT)/xccdf-unlinked-empty-groups.xml xsltproc -o $(OUT)/table-$(PROD)-cces.html $(TRANS)/xccdf2table-cce.xslt $< table-srgmap: $(OUT)/xccdf-unlinked-empty-groups.xml # the map-to-items filename must be provided relative to the root of the main document being processed xsltproc -stringparam map-to-items "../$<" -o $(OUT)/table-$(PROD)-srgmap.html \ $(TRANS)/table-srgmap.xslt $(REFS)/disa-os-srg-v1r4.xml xsltproc -stringparam flat "y" -stringparam map-to-items "../$<" -o $(OUT)/table-$(PROD)-srgmap-flat.html \ $(TRANS)/table-srgmap.xslt $(REFS)/disa-os-srg-v1r4.xml xmllint --xmlout --html --output $(OUT)/table-$(PROD)-srgmap-flat.xhtml $(OUT)/table-$(PROD)-srgmap-flat.html table-stigs: $(OUT)/xccdf-unlinked-final.xml table-srgmap checks # xsltproc -o $(OUT)/table-sle11-stig.html $(TRANS)/xccdf2table-stig.xslt $(REFS)/disa-stig-sle11-v1r0.6-xccdf.xml # xsltproc -o $(OUT)/table-sle11-stig-manual.html $(TRANS)/xccdf2table-stig.xslt $(REFS)/disa-stig-rhel5-v1r0.6-xccdf-manual.xml # xsltproc -stringparam notes "../$(IN)/auxiliary/transition_notes.xml" -o $(OUT)/table-rhel5-stig-manual-withnotes.html \ # $(TRANS)/xccdf2table-stig.xslt \ # $(REFS)/disa-stig-rhel5-v1r0.6-xccdf-manual.xml # temporarily retain an output file showing the short titles as well xsltproc -stringparam profile "stig-$(PROD)-server-upstream" -stringparam testinfo "y" -o $(OUT)/table-stig-$(PROD)-testinfo.html \ $(TRANS)/xccdf2table-profileccirefs.xslt $< xsltproc -stringparam overlay "../$(IN)/auxiliary/stig_overlay.xml" -o $(OUT)/unlinked-stig-$(PROD)-xccdf.xml \ $(TRANS)/xccdf-apply-overlay-stig.xslt $< xsltproc -o $(OUT)/table-$(PROD)-stig.html $(TRANS)/xccdf2table-stig.xslt $(OUT)/unlinked-stig-$(PROD)-xccdf.xml tables: table-refs table-idents table-srgmap table-stigs content: $(OUT)/xccdf-unlinked-final.xml checks cp $< $(OUT)/unlinked-$(PROD)-xccdf.xml # Remove auxiliary Groups which are only for use in tables, and not guide output. xsltproc -o $(OUT)/unlinked-$(PROD)-xccdf-guide.xml $(TRANS)/xccdf-removeaux.xslt $(OUT)/unlinked-$(PROD)-xccdf.xml # The relabel-ids.py script chdirs to ./output, so refer to files from there. # Its second argument controls the IDs, as well as the output filenames. # Thus, with ID set to ssg, this creates ssg-$(PROD)-xccdf.xml and ssg-$(PROD)-oval.xml. $(SHARED)/$(UTILS)/cpe-generate.py $(OUT)/unlinked-$(PROD)-oval.xml $(IN)/oval/platform/$(PROD)-cpe-dictionary.xml $(ID) $(SHARED)/$(UTILS)/relabel-ids.py unlinked-$(PROD)-xccdf.xml $(ID) $(SHARED)/$(UTILS)/relabel-ids.py xccdf-unlinked-ocilrefs.xml $(ID) # Once things are relabelled, create a datastream xsltproc /usr/share/openscap/xsl/xccdf_1.1_remove_dangling_sub.xsl $(OUT)/$(ID)-$(PROD)-xccdf.xml \ > $(OUT)/$(ID)-$(PROD)-xccdf-nodangles.xml xsltproc --stringparam reverse_DNS org.$(VENDOR).content /usr/share/openscap/xsl/xccdf_1.1_to_1.2.xsl \ $(OUT)/$(ID)-$(PROD)-xccdf-nodangles.xml > $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml sed -i '/idref="dangling reference to /d' $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml # Update @style attribute of to "SCAP_1.2". Fixes #1059 sed -i 's/style="SCAP_1.1"/style="SCAP_1.2"/' $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml oscap ds sds-compose $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml $(OUT)/$(ID)-$(PROD)-ds.xml # Make a PCI-DSS-centric Benchmark $(SHARED)/$(TRANS)/pcidss/transform_benchmark_to_pcidss.py $(SHARED)/$(TRANS)/pcidss/PCI_DSS.json $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml $(OUT)/$(ID)-$(PROD)-pcidss-xccdf-1.2.xml oscap ds sds-add $(OUT)/$(ID)-$(PROD)-pcidss-xccdf-1.2.xml $(OUT)/$(ID)-$(PROD)-ds.xml # Update @schematron-version attribute in datastream to "1.2". Fixes #1191 # (Workaround for https://github.com/OpenSCAP/openscap/issues/383) sed -i 's/schematron-version="[0-9].[0-9]"/schematron-version="1.2"/' $(OUT)/$(ID)-$(PROD)-ds.xml # Add in CPE content to datastream oscap ds sds-add $(OUT)/$(ID)-$(PROD)-cpe-dictionary.xml $(OUT)/$(ID)-$(PROD)-ds.xml # Fixes https://github.com/OpenSCAP/scap-security-guide/issues/1100 # Fixes https://github.com/OpenSCAP/scap-security-guide/issues/1101 $(SHARED)/$(UTILS)/sds-move-ocil-to-checks.py $(OUT)/$(ID)-$(PROD)-ds.xml $(OUT)/$(ID)-$(PROD)-ds.xml content-stig: table-stigs guide checks xmllint --format --output $(OUT)/unlinked-stig-$(PROD)-xccdf.xml $(OUT)/unlinked-stig-$(PROD)-xccdf.xml $(SHARED)/$(UTILS)/cpe-generate.py $(OUT)/unlinked-$(PROD)-oval.xml $(IN)/oval/platform/$(PROD)-cpe-dictionary.xml disa-predraft $(SHARED)/$(UTILS)/relabel-ids.py unlinked-stig-$(PROD)-xccdf.xml disa-predraft xmllint --format --output $(OUT)/disa-predraft-stig-$(PROD)-xccdf.xml $(OUT)/disa-predraft-stig-$(PROD)-xccdf.xml guide: content ifeq ($(OPENSCAP_1_1_OR_LATER), 0) $(SHARED)/$(UTILS)/build-all-guides.py --input $(OUT)/$(ID)-$(PROD)-ds.xml else @echo "Building guides from XCCDF 1.1, use OpenSCAP 1.1.0 or later for guides from datastreams!" $(SHARED)/$(UTILS)/build-all-guides.py --input $(OUT)/$(ID)-$(PROD)-xccdf.xml endif submission-stig-check: table-stigs cd $(OUT); ../$(SHARED)/$(UTILS)/verify-references.py -p stig-$(PROD)-server-upstream \ --rules-with-disarefs-outside-profile unlinked-$(PROD)-xccdf-prerefs.xml # $(TRANS)/xccdf2csv-stig.py $(OUT)/unlinked-stig-$(PROD)-xccdf.xml > $(OUT)/table-stig.csv # content-usgcb: coming soon validate-xml: oscap xccdf validate-xml $(OUT)/$(ID)-$(PROD)-xccdf.xml oscap oval validate-xml --schematron $(OUT)/$(ID)-$(PROD)-oval.xml oscap cpe validate-xml $(OUT)/$(ID)-$(PROD)-cpe-dictionary.xml oscap oval validate-xml --schematron $(OUT)/$(ID)-$(PROD)-cpe-oval.xml oscap ds sds-validate $(OUT)/$(ID)-$(PROD)-ds.xml validate: validate-xml ifeq ($(OVAL_5_11), 0) cd $(OUT); ../$(SHARED)/$(UTILS)/verify-references.py --rules-with-invalid-checks --ovaldefs-unused $(ID)-$(PROD)-xccdf.xml else # If we are building against oscap version not supporting OVAL-5.11 language version yet, # don't call verify-references.py with "--rules-with-invalid-checks" argument, since the # OVAL checks using the 5.11 OVAL version will not be included in that case @echo -e "\nWarning:\n" @echo -e "\tSUSE/11 content build using oscap not supporting OVAL-5.11 language version detected!" @echo -e "\tSince the OVAL-5.11 SUSE/11 OVAL checks are missing, will skip test for referenced," @echo -e "\tbut undefined OVAL definitions during content validation. Consider building SUSE/11" @echo -e "\tcontent with version OpenSCAP-1.2.2, or newer in order to perform full content validation!\n" cd $(OUT); ../$(SHARED)/$(UTILS)/verify-references.py --ovaldefs-unused $(ID)-$(PROD)-xccdf.xml endif # Items in dist are expected for distribution in an rpm dist: tables guide content mkdir -p $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-xccdf.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-oval.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-ocil.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-cpe-dictionary.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-cpe-oval.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-ds.xml $(DIST)/content mkdir -p $(DIST)/tables cp $(OUT)/table-*.{x,}html $(DIST)/tables mkdir -p $(DIST)/guide cp $(OUT)/*-guide-*.html $(DIST)/guide clean: rm -rf $(OUT)/* rm -rf $(DIST)/content $(DIST)/guide rm -rf $(BUILD) scap-security-guide-0.1.31/SUSE/11/README000066400000000000000000000031201301675746700173560ustar00rootroot00000000000000Directory Structure of scap-security-guide ------------------------------------------ The input directory contains source files that generate SCAP content, such as XCCDF and OVAL. Since a single large XML file is an impractical format for multiple authors to collaborate on editing SCAP content, efforts are made to keep logically related guidance and checking content in individual files. The transforms directory contains resources that enable the files inside the input directory (or output directory) to be combined and reformatted into valid SCAP formats or human-readable formats. The output directory is used as a storage area for items generated by the files in the inputs directory. It should be empty in the repository, and built on users' individual systems (and rely on its .gitignore file to keep such files out). The output directory contains transitional output (which may only exist in order to be further transformed) as well as final output. The references directory should contain documents which are specified as references from within the SCAP content, or documents that are "seeds," viz. documents whose prose will be translated into SCAP formats, as well as other examples of SCAP content. The utils directory contains helper scripts and other items that are useful to developers but are not essential to producing the project's output. The dist directory contains final outputs, which could be shipped in an RPM for consumption by end-users. Updating the Makefile to copy an item from the outputs directory to the dist directory indicates that an item is considered a final output. scap-security-guide-0.1.31/SUSE/11/input/000077500000000000000000000000001301675746700176415ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/11/input/auxiliary/000077500000000000000000000000001301675746700216505ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/11/input/auxiliary/DISCLAIMER000066400000000000000000000020271301675746700232100ustar00rootroot00000000000000The upstream STIG for Red Hat Enterprise Linux 6 Server profile "stig-rhel6-server-upstream" is developed under the DoD consensus model and DISA FSO Vendor STIG process, serving as the upstream development environment for the Red Hat Enterprise Linux 6 Server STIG. As a result of the upstream/downstream relationship between the SCAP Security Guide project and the official DISA FSO STIG baseline, users should expect variance between SSG and DISA FSO content. For official DISA FSO STIG content, refer to http://iase.disa.mil/stigs/os/unix-linux/Pages/red-hat.aspx. While this profile is packaged by Red Hat as part of the SCAP Security Guide package, please note that commercial support of this SCAP content is NOT available. This profile is provided as example SCAP content with no endorsement for suitability or production readiness. Support for this profile is provided by the upstream SCAP Security Guide community on a best-effort basis. The upstream project homepage is https://www.open-scap.org/security-policies/scap-security-guide/. scap-security-guide-0.1.31/SUSE/11/input/guide.xslt000066400000000000000000000167161301675746700216650ustar00rootroot00000000000000 A conditional clause for check statements. A conditional clause for check statements. This is a placeholder. scap-security-guide-0.1.31/SUSE/11/input/oval/000077500000000000000000000000001301675746700206025ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/11/input/oval/README000066400000000000000000000025001301675746700214570ustar00rootroot00000000000000OVAL checks here are currently defined in individual files of well-formed XML, each of which contains the elements necessary to conduct the check. Each file consists of one definition and the tests, states, objects and variables upon which it depends. When developing new OVAL content make sure that IDs assigned to new definitions, tests, objects, states, and variables are unique and not replicated in any other OVAL check in this directory. The presence of duplicate IDs will result in a "Duplicate ID" warning being printed when the "make all" command is issued. Because each of these XML files is eventually concatenated and reordered to create a valid OVAL document, the presence of duplicate IDs can introduce errors when evaluating the OVAL content. Please note that there may be times when it makes sense to duplicate an object assuming that the object is *exactly* the same across OVAL checks. This warning is meant to discourage the accidental introduction of duplicate IDs. Interrogatory checks (which cannot be automated) may be defined in the OCIL language and stored here. As soon as it supports newer OVAL versions, checks may also be defined in (or replaced by translations of) the SC language and compiled into OVAL using the scc tool. More information is available at: http://oss.tresys.com/projects/scc scap-security-guide-0.1.31/SUSE/11/input/oval/platform/000077500000000000000000000000001301675746700224265ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/11/input/oval/platform/sle11-cpe-dictionary.xml000066400000000000000000000020171301675746700270050ustar00rootroot00000000000000 SUSE Linux Enterprise Server 11 installed_OS_is_sle11 SUSE Linux Enterprise Desktop 11 installed_OS_is_sle11 scap-security-guide-0.1.31/SUSE/11/input/oval/service_sshd_disabled.xml000066400000000000000000000111311301675746700256310ustar00rootroot00000000000000 Service sshd Disabled SUSE Linux Enterprise 11 The sshd service should be disabled if possible. sshd 0 sshd 1 sshd 2 sshd 3 sshd 4 sshd 5 sshd 6 false true scap-security-guide-0.1.31/SUSE/11/input/oval/templates/000077500000000000000000000000001301675746700226005ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/11/input/oval/templates/Makefile000066400000000000000000000022211301675746700242350ustar00rootroot00000000000000templates: services packages kernel_modules permissions umasks sysctls SHARED_DIR=../../../../../shared/templates export PYTHONPATH=../../../../../shared SHARED_TEMPLATES=../../../../../shared/templates OUTPUT:=$(shell mkdir -p output) services: ${SHARED_DIR}/create_services_enabled.py services_enabled.csv ${SHARED_DIR}/create_services_disabled.py services_disabled.csv packages: ${SHARED_DIR}/create_package_installed.py packages_installed.csv ${SHARED_DIR}/create_package_removed.py packages_removed.csv kernel_modules: ${SHARED_DIR}/create_kernel_modules_disabled.py kernel_modules_disabled.csv permissions: ${SHARED_DIR}/create_permission_checks.py file_dir_permissions.csv umasks: ${SHARED_TEMPLATES}/create_umask_checks.py ${SHARED_TEMPLATES}/file_umask_checks.csv sysctls: ${SHARED_DIR}/create_sysctl_checks.py sysctl_values.csv ${SHARED_DIR}/create_sysctl_ipv6_checks.py sysctl_ipv6_values.csv compare: diff output/ ../ | grep -v "Only in ../" copy: cp output/*.xml ../ cp output/*.sh ../../remediations/bash/ find-untemplated: templates ${SHARED_DIR}/find_untemplated.py clean: rm -f output/*.xml rm -f output/*.sh rm -rf output/ scap-security-guide-0.1.31/SUSE/11/input/oval/templates/README000066400000000000000000000024121301675746700234570ustar00rootroot00000000000000These templates are designed to make generation of OVAL tests which have repetitive structure easier. For example: $ ./create_services_disabled.py services_disabled.csv will produce all the OVAL checks (in a shorthand format) to disable services, and store them in the output directory. The CSV input files should contain all the relevant information for each check. Files should be compared to existing OVAL checks for consistency before copying to the main oval directory. A Makefile exists to activate all the scripts here and ease comparison with existing checks. For example, to run all scripts to generate OVAL checks from the available templates: $ make templates To compare the newly-generated files in the output directory to the existing checks, run: $ make compare Then, if the changes are agreeable, the following command can be run to copy the newly generated files to the main oval directory: $ make copy To list files that have been manually created (and may potentially be templated), run: # make find-untemplated Note, however, that some checks may have been intentionally hand-edited. For example, some sysctl checks (such as for IPv6) may include additional tests so that they pass if the IPv6 module is disabled. Never blindly copy over existing checks. scap-security-guide-0.1.31/SUSE/11/input/oval/testoval.py000077500000000000000000000003521301675746700230200ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import testoval_module if __name__ == "__main__": testoval_module.main() scap-security-guide-0.1.31/SUSE/11/input/profiles/000077500000000000000000000000001301675746700214645ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/11/input/profiles/common.xml000066400000000000000000000420151301675746700235000ustar00rootroot00000000000000 Common Profile for General-Purpose Systems This profile contains items common to general-purpose desktop and server installations. scap-security-guide-0.1.31/SUSE/11/input/profiles/desktop.xml000066400000000000000000000040061301675746700236570ustar00rootroot00000000000000 Desktop Baseline This profile is for a desktop installation of SUSE Linux Enterprise 11. scap-security-guide-0.1.31/SUSE/11/input/profiles/server.xml000066400000000000000000000007271301675746700235220ustar00rootroot00000000000000 Server Baseline This profile is for SUSE Enterprise Linux 11 acting as a server. scap-security-guide-0.1.31/SUSE/11/input/profiles/standard.xml000066400000000000000000000025341301675746700240120ustar00rootroot00000000000000 Standard System Security Profile This profile contains rules to ensure standard security baseline of SUSE Linux Enterprise 11 system. Regardless of your system's workload all of these checks should pass. scap-security-guide-0.1.31/SUSE/11/input/xccdf/000077500000000000000000000000001301675746700207305ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/11/input/xccdf/services/000077500000000000000000000000001301675746700225535ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/11/input/xccdf/services/README000066400000000000000000000001431301675746700234310ustar00rootroot00000000000000This directory should have XCCDF for system services. See RHEL/7/input/xccdf/services for example. scap-security-guide-0.1.31/SUSE/11/input/xccdf/system/000077500000000000000000000000001301675746700222545ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/11/input/xccdf/system/README000066400000000000000000000001411301675746700231300ustar00rootroot00000000000000This directory should have XCCDF for system settings. See RHEL/7/input/xccdf/system for example. scap-security-guide-0.1.31/SUSE/11/input/xccdf/system/permissions/000077500000000000000000000000001301675746700246275ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/11/input/xccdf/system/permissions/files.xml000066400000000000000000000052761301675746700264650ustar00rootroot00000000000000 Verify Permissions on Important Files and Directories Permissions for many files on a system must be set restrictively to ensure sensitive information is properly protected. This section discusses important permission restrictions which can be verified to ensure that no harmful discrepancies have arisen. Verify Permissions on Files with Local Account Information and Credentials The default restrictive permissions for files which act as important security databases such as passwd, shadow, group, and gshadow files must be maintained. Many utilities need read access to the passwd file in order to function properly, but read access to the shadow file allows malicious attacks against system passwords, and should never be enabled. Verify User Who Owns <tt>passwd</tt> File The /etc/passwd file contains information about the users that are configured on the system. Protection of this file is critical for system security. Verify Group Who Owns <tt>passwd</tt> File The /etc/passwd file contains information about the users that are configured on the system. Protection of this file is critical for system security. Verify Permissions on <tt>passwd</tt> File If the /etc/passwd file is writable by a group-owner or the world the risk of its compromise is increased. The file contains the list of accounts on the system and associated information, and protection of this file is critical for system security. scap-security-guide-0.1.31/SUSE/11/transforms/000077500000000000000000000000001301675746700207005ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/11/transforms/cce_extract.py000077500000000000000000000003551301675746700235440ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import cce_extract_module if __name__ == "__main__": cce_extract_module.main() scap-security-guide-0.1.31/SUSE/11/transforms/cci2html.xsl000066400000000000000000000004711301675746700231370ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/11/transforms/constants.xslt000066400000000000000000000022531301675746700236320ustar00rootroot00000000000000 SUSE Linux Enterprise 11 SUSE 11 SUSE_11_STIG SUSE-11 cpe:/o:suse:linux_enterprise_server:11 suse11 scap-security-guide-0.1.31/SUSE/11/transforms/shorthand2xccdf.xslt000066400000000000000000000005151301675746700247010ustar00rootroot00000000000000 unknown unlinked-sle11-oval.xml scap-security-guide-0.1.31/SUSE/11/transforms/splitchecks.py000077500000000000000000000003551301675746700235740ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import splitchecks_module if __name__ == "__main__": splitchecks_module.main() scap-security-guide-0.1.31/SUSE/11/transforms/table-add-srgitems.xslt000066400000000000000000000011011301675746700252550ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/11/transforms/table-sortbyref.xslt000066400000000000000000000005601301675746700247210ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/11/transforms/table-srgmap.xslt000066400000000000000000000011431301675746700241710ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/11/transforms/table-style.xslt000066400000000000000000000002541301675746700240420ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/11/transforms/xccdf-alt-titles.xslt000066400000000000000000000005051301675746700247630ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/11/transforms/xccdf-apply-overlay-stig.xslt000066400000000000000000000007541301675746700264570ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/11/transforms/xccdf-removeaux.xslt000066400000000000000000000005041301675746700247130ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/11/transforms/xccdf2csv-stig.py000077500000000000000000000003631301675746700241100ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import xccdf2csv_stig_module if __name__ == "__main__": xccdf2csv_stig_module.main() scap-security-guide-0.1.31/SUSE/11/transforms/xccdf2html.xslt000066400000000000000000000005531301675746700236550ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/11/transforms/xccdf2shorthand.xslt000066400000000000000000000005041301675746700246770ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/11/transforms/xccdf2stigformat.xslt000066400000000000000000000007001301675746700250620ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/11/transforms/xccdf2table-byref.xslt000066400000000000000000000006771301675746700251140ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/11/transforms/xccdf2table-cce.xslt000066400000000000000000000007361301675746700245330ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/11/transforms/xccdf2table-profileccirefs.xslt000066400000000000000000000016021301675746700267710ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/11/transforms/xccdf2table-profilecisrefs.xslt000066400000000000000000000007101301675746700270100ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/11/transforms/xccdf2table-profilenistrefs.xslt000066400000000000000000000007101301675746700272070ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/11/transforms/xccdf2table-stig.xslt000066400000000000000000000006761301675746700247520ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/11/utils/000077500000000000000000000000001301675746700176425ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/11/utils/README000066400000000000000000000010241301675746700205170ustar00rootroot00000000000000This file is meant to give a quick overview to some of the scripts located in this directory. verify-input-sanity.py Purpose: This script can be invoked without arguments to examine the files within src/input to make sure that they are in good shape *prior to* building the XCCDF and OVAL content with the various make commands. Intent: Help XCCDF and OVAL developers spot common mistakes *before* utilizing the Makefile to build the XCCDF and OVAL content. Usage: ../../../shared/utils/verify-input-sanity.py scap-security-guide-0.1.31/SUSE/11/utils/sync-alt-titles.py000077500000000000000000000003651301675746700232570ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import sync_alt_titles_module if __name__ == "__main__": sync_alt_titles_module.main() scap-security-guide-0.1.31/SUSE/11/utils/verify-cce.py000077500000000000000000000003531301675746700222540ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import verify_cce_module if __name__ == "__main__": verify_cce_module.main() scap-security-guide-0.1.31/SUSE/12/000077500000000000000000000000001301675746700165035ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/12/Makefile000066400000000000000000000227641301675746700201560ustar00rootroot00000000000000all: tables guide content dist SHARED = ../../shared include $(SHARED)/product-make.include PROD = sle12 VENDOR = ssgproject checks: standard-oval-build # example, if needed: for converting XCCDF into shorthand #xccdf2shorthand: # xsltproc -o $(XCCDF_OUTPUT_DIR)/rhel5-shorthand.xml $(TRANS)/xccdf2shorthand.xslt $(REFS)/usgcb-rhel5desktop-xccdf.xml # tidy -m -xml -utf8 --indent-spaces=0 $(XCCDF_OUTPUT_DIR)/rhel5-shorthand.xml table-refs: $(OUT)/xccdf-unlinked-empty-groups.xml xsltproc -stringparam ref "nist" -o $(OUT)/table-$(PROD)-nistrefs.html $(TRANS)/xccdf2table-byref.xslt $< xsltproc -stringparam ref "cis" -o $(OUT)/table-$(PROD)-cisrefs.html $(TRANS)/xccdf2table-byref.xslt $< xsltproc -stringparam profile "common" -o $(OUT)/table-$(PROD)-nistrefs-common.html \ $(TRANS)/xccdf2table-profilenistrefs.xslt $< xsltproc -stringparam profile "ospp-rhel7-server" -o $(OUT)/table-$(PROD)-nistrefs-ospp.html \ $(TRANS)/xccdf2table-profilenistrefs.xslt $< xsltproc -stringparam profile "C2S" -o $(OUT)/table-$(PROD)-cisrefs-c2s.html \ $(TRANS)/xccdf2table-profilecisrefs.xslt $< xsltproc -stringparam ref "pcidss" -o $(OUT)/table-$(PROD)-pcidss.html \ $(TRANS)/xccdf2table-byref.xslt $< table-idents: $(OUT)/xccdf-unlinked-empty-groups.xml xsltproc -o $(OUT)/table-$(PROD)-cces.html $(TRANS)/xccdf2table-cce.xslt $< table-srgmap: $(OUT)/xccdf-unlinked-empty-groups.xml # the map-to-items filename must be provided relative to the root of the main document being processed xsltproc -stringparam map-to-items "../$<" -o $(OUT)/table-$(PROD)-srgmap.html \ $(TRANS)/table-srgmap.xslt $(REFS)/disa-os-srg-v1r4.xml xsltproc -stringparam flat "y" -stringparam map-to-items "../$<" -o $(OUT)/table-$(PROD)-srgmap-flat.html \ $(TRANS)/table-srgmap.xslt $(REFS)/disa-os-srg-v1r4.xml xmllint --xmlout --html --output $(OUT)/table-$(PROD)-srgmap-flat.xhtml $(OUT)/table-$(PROD)-srgmap-flat.html table-stigs: $(OUT)/xccdf-unlinked-final.xml table-srgmap checks # xsltproc -o $(OUT)/table-rhel5-stig.html $(TRANS)/xccdf2table-stig.xslt $(REFS)/disa-stig-rhel5-v1r0.6-xccdf.xml # xsltproc -o $(OUT)/table-rhel5-stig-manual.html $(TRANS)/xccdf2table-stig.xslt $(REFS)/disa-stig-rhel5-v1r0.6-xccdf-manual.xml # xsltproc -stringparam notes "../$(IN)/auxiliary/transition_notes.xml" -o $(OUT)/table-rhel5-stig-manual-withnotes.html \ # $(TRANS)/xccdf2table-stig.xslt \ # $(REFS)/disa-stig-rhel5-v1r0.6-xccdf-manual.xml # temporarily retain an output file showing the short titles as well xsltproc -stringparam profile "stig-$(PROD)-server" -stringparam testinfo "y" -o $(OUT)/table-stig-$(PROD)-testinfo.html \ $(TRANS)/xccdf2table-profileccirefs.xslt $< xsltproc -stringparam overlay "../$(IN)/auxiliary/stig_overlay.xml" -o $(OUT)/unlinked-stig-$(PROD)-xccdf.xml \ $(TRANS)/xccdf-apply-overlay-stig.xslt $< xsltproc -o $(OUT)/table-$(PROD)-stig.html $(TRANS)/xccdf2table-stig.xslt $(OUT)/unlinked-stig-$(PROD)-xccdf.xml tables: table-refs table-idents table-srgmap table-stigs content: $(OUT)/xccdf-unlinked-final.xml checks cp $< $(OUT)/unlinked-$(PROD)-xccdf.xml # Remove auxiliary Groups which are only for use in tables, and not guide output. xsltproc -o $(OUT)/unlinked-$(PROD)-xccdf-guide.xml $(TRANS)/xccdf-removeaux.xslt $(OUT)/unlinked-$(PROD)-xccdf.xml # The relabel-ids.py script chdirs to ./output, so refer to files from there. # Its second argument controls the IDs, as well as the output filenames. # Thus, with ID set to ssg, this creates ssg-$(PROD)-xccdf.xml and ssg-$(PROD)-oval.xml. $(SHARED)/$(UTILS)/cpe-generate.py $(OUT)/unlinked-$(PROD)-oval.xml $(IN)/oval/platform/$(PROD)-cpe-dictionary.xml $(ID) $(SHARED)/$(UTILS)/relabel-ids.py unlinked-$(PROD)-xccdf.xml $(ID) $(SHARED)/$(UTILS)/relabel-ids.py xccdf-unlinked-ocilrefs.xml $(ID) # Once things are relabelled, create a datastream xsltproc /usr/share/openscap/xsl/xccdf_1.1_remove_dangling_sub.xsl $(OUT)/$(ID)-$(PROD)-xccdf.xml \ > $(OUT)/$(ID)-$(PROD)-xccdf-nodangles.xml xsltproc --stringparam reverse_DNS org.$(VENDOR).content /usr/share/openscap/xsl/xccdf_1.1_to_1.2.xsl \ $(OUT)/$(ID)-$(PROD)-xccdf-nodangles.xml > $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml sed -i '/idref="dangling reference to /d' $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml # Update @style attribute of to "SCAP_1.2". Fixes #1059 sed -i 's/style="SCAP_1.1"/style="SCAP_1.2"/' $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml oscap ds sds-compose $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml $(OUT)/$(ID)-$(PROD)-ds.xml # Make a PCI-DSS-centric Benchmark $(SHARED)/$(TRANS)/pcidss/transform_benchmark_to_pcidss.py $(SHARED)/$(TRANS)/pcidss/PCI_DSS.json $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml $(OUT)/$(ID)-$(PROD)-pcidss-xccdf-1.2.xml oscap ds sds-add $(OUT)/$(ID)-$(PROD)-pcidss-xccdf-1.2.xml $(OUT)/$(ID)-$(PROD)-ds.xml # Update @schematron-version attribute in datastream to "1.2". Fixes #1191 # (Workaround for https://github.com/OpenSCAP/openscap/issues/383) sed -i 's/schematron-version="[0-9].[0-9]"/schematron-version="1.2"/' $(OUT)/$(ID)-$(PROD)-ds.xml # Add in CPE content to datastream oscap ds sds-add $(OUT)/$(ID)-$(PROD)-cpe-dictionary.xml $(OUT)/$(ID)-$(PROD)-ds.xml # Fixes https://github.com/OpenSCAP/scap-security-guide/issues/1100 # Fixes https://github.com/OpenSCAP/scap-security-guide/issues/1101 $(SHARED)/$(UTILS)/sds-move-ocil-to-checks.py $(OUT)/$(ID)-$(PROD)-ds.xml $(OUT)/$(ID)-$(PROD)-ds.xml # Make CentOS variants of XCCDF and Source DataStream $(SHARED)/$(UTILS)/enable-derivatives.py --enable-centos -i $(OUT)/$(ID)-$(PROD)-xccdf.xml -o $(OUT)/$(ID)-centos7-xccdf.xml $(SHARED)/$(UTILS)/enable-derivatives.py --enable-centos -i $(OUT)/$(ID)-$(PROD)-ds.xml -o $(OUT)/$(ID)-centos7-ds.xml # Make Scientific Linux variants of XCCDF and Source DataStream $(SHARED)/$(UTILS)/enable-derivatives.py --enable-sl -i $(OUT)/$(ID)-$(PROD)-xccdf.xml -o $(OUT)/$(ID)-sl7-xccdf.xml $(SHARED)/$(UTILS)/enable-derivatives.py --enable-sl -i $(OUT)/$(ID)-$(PROD)-ds.xml -o $(OUT)/$(ID)-sl7-ds.xml content-stig: table-stigs guide checks xmllint --format --output $(OUT)/unlinked-stig-$(PROD)-xccdf.xml $(OUT)/unlinked-stig-$(PROD)-xccdf.xml $(SHARED)/$(UTILS)/cpe-generate.py $(OUT)/unlinked-$(PROD)-oval.xml $(IN)/oval/platform/$(PROD)-cpe-dictionary.xml disa-predraft $(SHARED)/$(UTILS)/relabel-ids.py unlinked-stig-$(PROD)-xccdf.xml disa-predraft xmllint --format --output $(OUT)/disa-predraft-stig-$(PROD)-xccdf.xml $(OUT)/disa-predraft-stig-$(PROD)-xccdf.xml guide: content ifeq ($(OPENSCAP_1_1_OR_LATER), 0) $(SHARED)/$(UTILS)/build-all-guides.py --input $(OUT)/$(ID)-$(PROD)-ds.xml $(SHARED)/$(UTILS)/build-all-guides.py --input $(OUT)/$(ID)-centos7-ds.xml $(SHARED)/$(UTILS)/build-all-guides.py --input $(OUT)/$(ID)-sl7-ds.xml else @echo "Building guides from XCCDF 1.1, use OpenSCAP 1.1.0 or later for guides from datastreams!" $(SHARED)/$(UTILS)/build-all-guides.py --input $(OUT)/$(ID)-$(PROD)-xccdf.xml $(SHARED)/$(UTILS)/build-all-guides.py --input $(OUT)/$(ID)-centos7-xccdf.xml $(SHARED)/$(UTILS)/build-all-guides.py --input $(OUT)/$(ID)-sl7-xccdf.xml endif submission-stig-check: table-stigs cd $(OUT); ../$(SHARED)/$(UTILS)/verify-references.py -p stig-$(PROD)-server \ --rules-with-disarefs-outside-profile unlinked-$(PROD)-xccdf-prerefs.xml # $(TRANS)/xccdf2csv-stig.py $(OUT)/unlinked-stig-$(PROD)-xccdf.xml > $(OUT)/table-stig.csv # content-usgcb: coming soon validate-xml: oscap xccdf validate-xml $(OUT)/$(ID)-$(PROD)-xccdf.xml oscap oval validate-xml --schematron $(OUT)/$(ID)-$(PROD)-oval.xml oscap cpe validate-xml $(OUT)/$(ID)-$(PROD)-cpe-dictionary.xml oscap oval validate-xml --schematron $(OUT)/$(ID)-$(PROD)-cpe-oval.xml oscap ds sds-validate $(OUT)/$(ID)-$(PROD)-ds.xml oscap xccdf validate-xml $(OUT)/$(ID)-centos7-xccdf.xml oscap ds sds-validate $(OUT)/$(ID)-centos7-ds.xml oscap xccdf validate-xml $(OUT)/$(ID)-sl7-xccdf.xml oscap ds sds-validate $(OUT)/$(ID)-sl7-ds.xml validate: validate-xml ifeq ($(OVAL_5_11), 0) cd $(OUT); ../$(SHARED)/$(UTILS)/verify-references.py --rules-with-invalid-checks --ovaldefs-unused $(ID)-$(PROD)-xccdf.xml else # If we are building against oscap version not supporting OVAL-5.11 language version yet, # don't call verify-references.py with "--rules-with-invalid-checks" argument, since the # OVAL checks using the 5.11 OVAL version will not be included in that case @echo -e "\nWarning:\n" @echo -e "\tSUSE/12 content build using oscap not supporting OVAL-5.11 language version detected!" @echo -e "\tSince the OVAL-5.11 SUSE/12 OVAL checks are missing, will skip test for referenced," @echo -e "\tbut undefined OVAL definitions during content validation. Consider building SUSE/12" @echo -e "\tcontent with version OpenSCAP-1.2.2, or newer in order to perform full content validation!\n" cd $(OUT); ../$(SHARED)/$(UTILS)/verify-references.py --ovaldefs-unused $(ID)-$(PROD)-xccdf.xml endif # Items in dist are expected for distribution in an rpm dist: tables guide content mkdir -p $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-xccdf.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-oval.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-ocil.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-cpe-dictionary.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-cpe-oval.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-ds.xml $(DIST)/content mkdir -p $(DIST)/tables cp $(OUT)/table-*.{x,}html $(DIST)/tables mkdir -p $(DIST)/guide cp $(OUT)/*-guide-*.html $(DIST)/guide cp $(OUT)/$(ID)-centos7-xccdf.xml $(DIST)/content cp $(OUT)/$(ID)-centos7-ds.xml $(DIST)/content cp $(OUT)/$(ID)-sl7-xccdf.xml $(DIST)/content cp $(OUT)/$(ID)-sl7-ds.xml $(DIST)/content clean: rm -rf $(OUT)/* rm -rf $(DIST)/content $(DIST)/guide rm -rf $(BUILD) scap-security-guide-0.1.31/SUSE/12/README000066400000000000000000000031201301675746700173570ustar00rootroot00000000000000Directory Structure of scap-security-guide ------------------------------------------ The input directory contains source files that generate SCAP content, such as XCCDF and OVAL. Since a single large XML file is an impractical format for multiple authors to collaborate on editing SCAP content, efforts are made to keep logically related guidance and checking content in individual files. The transforms directory contains resources that enable the files inside the input directory (or output directory) to be combined and reformatted into valid SCAP formats or human-readable formats. The output directory is used as a storage area for items generated by the files in the inputs directory. It should be empty in the repository, and built on users' individual systems (and rely on its .gitignore file to keep such files out). The output directory contains transitional output (which may only exist in order to be further transformed) as well as final output. The references directory should contain documents which are specified as references from within the SCAP content, or documents that are "seeds," viz. documents whose prose will be translated into SCAP formats, as well as other examples of SCAP content. The utils directory contains helper scripts and other items that are useful to developers but are not essential to producing the project's output. The dist directory contains final outputs, which could be shipped in an RPM for consumption by end-users. Updating the Makefile to copy an item from the outputs directory to the dist directory indicates that an item is considered a final output. scap-security-guide-0.1.31/SUSE/12/input/000077500000000000000000000000001301675746700176425ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/12/input/auxiliary/000077500000000000000000000000001301675746700216515ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/12/input/auxiliary/DISCLAIMER000066400000000000000000000020271301675746700232110ustar00rootroot00000000000000The upstream STIG for Red Hat Enterprise Linux 6 Server profile "stig-rhel6-server-upstream" is developed under the DoD consensus model and DISA FSO Vendor STIG process, serving as the upstream development environment for the Red Hat Enterprise Linux 6 Server STIG. As a result of the upstream/downstream relationship between the SCAP Security Guide project and the official DISA FSO STIG baseline, users should expect variance between SSG and DISA FSO content. For official DISA FSO STIG content, refer to http://iase.disa.mil/stigs/os/unix-linux/Pages/red-hat.aspx. While this profile is packaged by Red Hat as part of the SCAP Security Guide package, please note that commercial support of this SCAP content is NOT available. This profile is provided as example SCAP content with no endorsement for suitability or production readiness. Support for this profile is provided by the upstream SCAP Security Guide community on a best-effort basis. The upstream project homepage is https://www.open-scap.org/security-policies/scap-security-guide/. scap-security-guide-0.1.31/SUSE/12/input/guide.xslt000066400000000000000000000171131301675746700216560ustar00rootroot00000000000000 A conditional clause for check statements. A conditional clause for check statements. This is a placeholder. scap-security-guide-0.1.31/SUSE/12/input/oval/000077500000000000000000000000001301675746700206035ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/12/input/oval/README000066400000000000000000000025001301675746700214600ustar00rootroot00000000000000OVAL checks here are currently defined in individual files of well-formed XML, each of which contains the elements necessary to conduct the check. Each file consists of one definition and the tests, states, objects and variables upon which it depends. When developing new OVAL content make sure that IDs assigned to new definitions, tests, objects, states, and variables are unique and not replicated in any other OVAL check in this directory. The presence of duplicate IDs will result in a "Duplicate ID" warning being printed when the "make all" command is issued. Because each of these XML files is eventually concatenated and reordered to create a valid OVAL document, the presence of duplicate IDs can introduce errors when evaluating the OVAL content. Please note that there may be times when it makes sense to duplicate an object assuming that the object is *exactly* the same across OVAL checks. This warning is meant to discourage the accidental introduction of duplicate IDs. Interrogatory checks (which cannot be automated) may be defined in the OCIL language and stored here. As soon as it supports newer OVAL versions, checks may also be defined in (or replaced by translations of) the SC language and compiled into OVAL using the scc tool. More information is available at: http://oss.tresys.com/projects/scc scap-security-guide-0.1.31/SUSE/12/input/oval/oval_5.11/000077500000000000000000000000001301675746700222105ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/12/input/oval/oval_5.11/templates/000077500000000000000000000000001301675746700242065ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/12/input/oval/oval_5.11/templates/Makefile000066400000000000000000000013471301675746700256530ustar00rootroot00000000000000templates: services SHARED_DIR=../../../../../../shared/templates export PYTHONPATH=../../../../../../shared OUTPUT:=$(shell mkdir -p output) packages: ${SHARED_DIR}/create_package_installed.py packages_installed.csv ${SHARED_DIR}/create_package_removed.py packages_removed.csv services: ${SHARED_DIR}/create_services_enabled.py services_enabled.csv ${SHARED_DIR}/create_services_disabled.py services_disabled.csv sockets: ${SHARED_DIR}/create_sockets_disabled.py sockets_disabled.csv compare: diff output/ ../ | grep -v "Only in ../" copy: cp output/*.xml ../ cp output/*.sh ../../remediations/bash/ find-untemplated: templates ${SHARED_DIR}/find_untemplated.py clean: rm -f output/*.xml rm -f output/*.sh rm -rf output/ scap-security-guide-0.1.31/SUSE/12/input/oval/platform/000077500000000000000000000000001301675746700224275ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/12/input/oval/platform/sle12-cpe-dictionary.xml000066400000000000000000000020171301675746700270070ustar00rootroot00000000000000 SUSE Linux Enterprise Server 12 installed_OS_is_sle12 SUSE Linux Enterprise Desktop 12 installed_OS_is_sle12 scap-security-guide-0.1.31/SUSE/12/input/oval/templates/000077500000000000000000000000001301675746700226015ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/12/input/oval/templates/Makefile000066400000000000000000000021341301675746700242410ustar00rootroot00000000000000templates: packages kernel_modules permissions umasks sysctls SHARED_DIR=../../../../../shared/templates export PYTHONPATH=../../../../../shared SHARED_TEMPLATES=../../../../../shared/templates OUTPUT:=$(shell mkdir -p output) packages: ${SHARED_DIR}/create_package_installed.py packages_installed.csv ${SHARED_DIR}/create_package_removed.py packages_removed.csv kernel_modules: ${SHARED_DIR}/create_kernel_modules_disabled.py kernel_modules_disabled.csv permissions: ${SHARED_DIR}/create_permission_checks.py file_dir_permissions.csv umasks: ${SHARED_TEMPLATES}/create_umask_checks.py ${SHARED_TEMPLATES}/file_umask_checks.csv sysctls: ${SHARED_DIR}/create_sysctl_checks.py sysctl_values.csv ${SHARED_DIR}/create_sysctl_ipv6_checks.py sysctl_ipv6_values.csv sebools: ${SHARED_TEMPLATES}/create_sebool_oval.py ${SHARED_TEMPLATES}/selinux_booleans.csv compare: diff output/ ../ | grep -v "Only in ../" copy: cp output/*.xml ../ cp output/*.sh ../../remediations/bash/ find-untemplated: templates ${SHARED_DIR}/find_untemplated.py clean: rm -f output/*.xml rm -f output/*.sh rm -rf output/ scap-security-guide-0.1.31/SUSE/12/input/profiles/000077500000000000000000000000001301675746700214655ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/12/input/profiles/common.xml000066400000000000000000000052631301675746700235050ustar00rootroot00000000000000 Common Profile for General-Purpose Systems This profile contains items common to general-purpose desktop and server installations. scap-security-guide-0.1.31/SUSE/12/input/profiles/standard.xml000066400000000000000000000025341301675746700240130ustar00rootroot00000000000000 Standard System Security Profile This profile contains rules to ensure standard security baseline of SUSE Linux Enterprise 12 system. Regardless of your system's workload all of these checks should pass. scap-security-guide-0.1.31/SUSE/12/input/xccdf/000077500000000000000000000000001301675746700207315ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/12/input/xccdf/services/000077500000000000000000000000001301675746700225545ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/12/input/xccdf/services/avahi.xml000066400000000000000000000121641301675746700243720ustar00rootroot00000000000000 Avahi Server The Avahi daemon implements the DNS Service Discovery and Multicast DNS protocols, which provide service and host discovery on a network. It allows a system to automatically identify resources on the network, such as printers or web servers. This capability is also known as mDNSresponder and is a major part of Zeroconf networking. Disable Avahi Server if Possible Because the Avahi daemon service keeps an open network port, it is subject to network attacks. Disabling it can reduce the system's vulnerability to such attacks. Disable Avahi Server Software Because the Avahi daemon service keeps an open network port, it is subject to network attacks. Its functionality is convenient but is only appropriate if the local network can be trusted. Configure Avahi if Necessary If your system requires the Avahi daemon, its configuration can be restricted to improve security. The Avahi daemon configuration file is /etc/avahi/avahi-daemon.conf. The following security recommendations should be applied to this file: See the avahi-daemon.conf(5) man page, or documentation at http://www.avahi.org, for more detailed information about the configuration options. Serve Avahi Only via Required Protocol If you are using only IPv4, edit /etc/avahi/avahi-daemon.conf and ensure the following line exists in the [server] section: 
    use-ipv6=no
    Similarly, if you are using only IPv6, disable IPv4 sockets with the line: 
    use-ipv4=no
         Check Avahi Responses' TTL Field To make Avahi ignore packets unless the TTL field is 255, edit /etc/avahi/avahi-daemon.conf and ensure the following line appears in the [server] section: 
    check-response-ttl=yes
     This helps to ensure that only mDNS responses from the local network are processed, because the TTL field in a packet is decremented from its initial value of 255 whenever it is routed from one network to another. Although a properly-configured router or firewall should not allow mDNS packets into the local network at all, this option provides another check to ensure they are not permitted.     Prevent Other Programs from Using Avahi's Port To prevent other mDNS stacks from running, edit /etc/avahi/avahi-daemon.conf and ensure the following line appears in the [server] section: 
    disallow-other-stacks=yes
     This helps ensure that only Avahi is responsible for mDNS traffic coming from that port on the system.     Disable Avahi Publishing To prevent other mDNS stacks from running, edit /etc/avahi/avahi-daemon.conf and ensure the following line appears in the [server] section: 
    disallow-other-stacks=yes
     This helps ensure that only Avahi is responsible for mDNS traffic coming from that port on the system.     Restrict Information Published by Avahi If it is necessary to publish some information to the network, it should not be joined by any extraneous information, or by information supplied by a non-trusted source on the system. Prevent user applications from using Avahi to publish services by adding or correcting the following line in the [publish] section: 
    disable-user-service-publishing=yes
    Implement as many of the following lines as possible, to restrict the information published by Avahi. 
    publish-addresses=no
publish-hinfo=no
publish-workstation=no
publish-domain=no
    Inspect the files in the directory /etc/avahi/services/. Unless there is an operational need to publish information about each of these services, delete the corresponding file.     These options prevent publishing attempts from succeeding, and can be applied even if publishing is disabled entirely via disable-publishing. Alternatively, these can be used to restrict the types of published information in the event that some information must be published.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/services/base.xml000066400000000000000000000464051301675746700242210ustar00rootroot00000000000000 Base Services This section addresses the base services that are installed on a Red Hat Enterprise Linux 7 default installation which are not covered in other sections. Some of these services listen on the network and should be treated with particular discretion. Other services are local system utilities that may or may not be extraneous. In general, system services should be disabled if not required. Disable Automatic Bug Reporting Tool (abrtd) The Automatic Bug Reporting Tool (abrtd) daemon collects and reports crash data when an application crash is detected. Using a variety of plugins, abrtd can email crash reports to system administrators, log crash reports to files, or forward crash reports to a centralized issue tracking system such as RHTSupport. Mishandling crash data could expose sensitive information about vulnerabilities in software executing on the local machine, as well as sensitive information from within a process's address space or registers. Disable Advanced Configuration and Power Interface (acpid) The Advanced Configuration and Power Interface Daemon (acpid) dispatches ACPI events (such as power/reset button depressed) to userspace programs. ACPI support is highly desirable for systems in some network roles, such as laptops or desktops. For other systems, such as servers, it may permit accidental or trivially achievable denial of service situations and disabling it is appropriate. Disable Certmonger Service (certmonger) Certmonger is a D-Bus based service that attempts to simplify interaction with certifying authorities on networks which use public-key infrastructure. It is often combined with Red Hat's IPA (Identity Policy Audit) security information management solution to aid in the management of certificates. The services provided by certmonger may be essential for systems fulfilling some roles a PKI infrastructure, but its functionality is not necessary for many other use cases. Disable Control Group Config (cgconfig) Control groups allow an administrator to allocate system resources (such as CPU, memory, network bandwidth, etc) among a defined group (or groups) of processes executing on a system. The cgconfig daemon starts at boot and establishes the predefined control groups. Unless control groups are used to manage system resources, running the cgconfig service is not necessary. Disable Control Group Rules Engine (cgred) The cgred service moves tasks into control groups according to parameters set in the /etc/cgrules.conf configuration file. Unless control groups are used to manage system resources, running the cgred service service is not necessary. Disable CPU Speed (cpupower) The cpupower service can adjust the clock speed of supported CPUs based upon the current processing load thereby conserving power and reducing heat. The cpupower service is only necessary if adjusting the CPU clock speed provides benefit. Traditionally this has included laptops (to enhance battery life), but may also apply to server or desktop environments where conserving power is highly desirable or necessary. Enable IRQ Balance (irqbalance) The irqbalance service optimizes the balance between power savings and performance through distribution of hardware interrupts across multiple processors. In an environment with multiple processors (now common), the irqbalance service provides potential speedups for handling interrupt requests. Disable KDump Kernel Crash Analyzer (kdump) The kdump service provides a kernel crash dump analyzer. It uses the kexec system call to boot a secondary kernel ("capture" kernel) following a system crash, which can load information from the crashed kernel for analysis. Kernel core dumps may contain the full contents of system memory at the time of the crash. Kernel core dumps consume a considerable amount of disk space and may result in denial of service by exhausting the available space on the target file system partition. Unless the system is used for kernel development or testing, there is little need to run the kdump service. Disable Software RAID Monitor (mdmonitor) The mdmonitor service is used for monitoring a software RAID array; hardware RAID setups do not use this service. If software RAID monitoring is not required, there is no need to run this service. Disable D-Bus IPC Service (messagebus) D-Bus provides an IPC mechanism used by a growing list of programs, such as those used for Gnome, Bluetooth, and Avahi. Due to these dependencies, disabling D-Bus may not be practical for many systems. If no services which require D-Bus are needed, then it can be disabled. As a broker for IPC between processes of different privilege levels, it could be a target for attack. However, disabling D-Bus is likely to be impractical for any system which needs to provide a graphical login session. Disable Network Console (netconsole) The netconsole service is responsible for loading the netconsole kernel module, which logs kernel printk messages over UDP to a syslog server. This allows debugging of problems where disk logging fails and serial consoles are impractical. The netconsole service is not necessary unless there is a need to debug kernel panics, which is not common. Disable ntpdate Service (ntpdate) The ntpdate service sets the local hardware clock by polling NTP servers when the system boots. It synchronizes to the NTP servers listed in /etc/ntp/step-tickers or /etc/ntp.conf and then sets the local hardware clock to the newly synchronized system time. The ntpdate service may only be suitable for systems which are rebooted frequently enough that clock drift does not cause problems between reboots. In any event, the functionality of the ntpdate service is now available in the ntpd program and should be considered deprecated. Disable Odd Job Daemon (oddjobd) The oddjobd service exists to provide an interface and access control mechanism through which specified privileged tasks can run tasks for unprivileged client applications. Communication with oddjobd through the system message bus. The oddjobd service may provide necessary functionality in some environments, and can be disabled if it is not needed. Execution of tasks by privileged programs, on behalf of unprivileged ones, has traditionally been a source of privilege escalation security issues. Disable Portreserve (portreserve) The portreserve service is a TCP port reservation utility that can be used to prevent portmap from binding to well known TCP ports that are required for other services. The portreserve service provides helpful functionality by preventing conflicting usage of ports in the reserved port range, but it can be disabled if not needed. Enable Process Accounting (psacct) The process accounting service, psacct, works with programs including acct and ac to allow system administrators to view user activity, such as commands issued by users of the system. The psacct service can provide administrators a convenient view into some user activities. However, it should be noted that the auditing system and its audit records provide more authoritative and comprehensive records. Disable Apache Qpid (qpidd) The qpidd service provides high speed, secure, guaranteed delivery services. It is an implementation of the Advanced Message Queuing Protocol. By default the qpidd service will bind to port 5672 and listen for connection attempts. The qpidd service is automatically installed when the "base" package selection is selected during installation. The qpidd service listens for network connections, which increases the attack surface of the system. If the system is not intended to receive AMQP traffic, then the qpidd service is not needed and should be disabled or removed. Disable Quota Netlink (quota_nld) The quota_nld service provides notifications to users of disk space quota violations. It listens to the kernel via a netlink socket for disk quota violations and notifies the appropriate user of the violation using D-Bus or by sending a message to the terminal that the user has last accessed. If disk quotas are enforced on the local system, then the quota_nld service likely provides useful functionality and should remain enabled. However, if disk quotas are not used or user notification of disk quota violation is not desired then there is no need to run this service. Disable Network Router Discovery Daemon (rdisc) The rdisc service implements the client side of the ICMP Internet Router Discovery Protocol (IRDP), which allows discovery of routers on the local subnet. If a router is discovered then the local routing table is updated with a corresponding default route. By default this daemon is disabled. General-purpose systems typically have their network and routing information configured statically by a system administrator. Workstations or some special-purpose systems often use DHCP (instead of IRDP) to retrieve dynamic network configuration information. Disable Red Hat Network Service (rhnsd) The Red Hat Network service automatically queries Red Hat Network servers to determine whether there are any actions that should be executed, such as package updates. This only occurs if the system was registered to an RHN server or satellite and managed as such. Although systems management and patching is extremely important to system security, management by a system outside the enterprise enclave is not desirable for some environments. However, if the system is being managed by RHN or RHN Satellite Server the rhnsd daemon can remain on. Disable Red Hat Subscription Manager Daemon (rhsmcertd) The Red Hat Subscription Manager (rhsmcertd) periodically checks for changes in the entitlement certificates for a registered system and updates it accordingly. The rhsmcertd service can provide administrators with some additional control over which of their systems are entitled to particular subscriptions. However, for systems that are managed locally or which are not expected to require remote changes to their subscription status, it is unnecessary and can be disabled. Disable Cyrus SASL Authentication Daemon (saslauthd) The saslauthd service handles plaintext authentication requests on behalf of the SASL library. The service isolates all code requiring superuser privileges for SASL authentication into a single process, and can also be used to provide proxy authentication services to clients that do not understand SASL based authentication. The saslauthd service provides essential functionality for performing authentication in some directory environments, such as those which use Kerberos and LDAP. For others, however, in which only local files may be consulted, it is not necessary and should be disabled. Disable SMART Disk Monitoring Service (smartd) SMART (Self-Monitoring, Analysis, and Reporting Technology) is a feature of hard drives that allows them to detect symptoms of disk failure and relay an appropriate warning. SMART can help protect against denial of service due to failing hardware. Nevertheless, if it is not needed or the system's drives are not SMART-capable (such as solid state drives), it can be disabled. Disable System Statistics Reset Service (sysstat) The sysstat service resets various I/O and CPU performance statistics to zero in order to begin counting from a fresh state at boot time. By default the sysstat service merely runs a program at boot to reset the statistics, which can be retrieved using programs such as sar and sadc. These may provide useful insight into system operation, but unless used this service can be disabled. scap-security-guide-0.1.31/SUSE/12/input/xccdf/services/cron.xml000066400000000000000000000077441301675746700242530ustar00rootroot00000000000000 Cron and At Daemons The cron and at services are used to allow commands to be executed at a later time. The cron service is required by almost all systems to perform necessary maintenance tasks, while at may or may not be required on a given system. Both daemons should be configured defensively. Enable cron Service The crond service is used to execute commands at preconfigured times. It is required by almost all systems to perform necessary maintenance tasks, such as notifying root of system activity. Due to its usage for maintenance and security-supporting tasks, enabling the cron daemon is essential. Disable anacron Service The cronie-anacron package, which provides anacron functionality, is installed by default. The anacron service provides cron functionality for systems such as laptops and workstations that may be shut down during the normal times that cron jobs are scheduled to run. On systems which do not require this additional functionality, anacron could needlessly increase the possible attack surface for an intruder. Disable At Service (atd) The at and batch commands can be used to schedule tasks that are meant to be executed only once. This allows delayed execution in a manner similar to cron, except that it is not recurring. The daemon atd keeps track of tasks scheduled via at and batch, and executes them at the specified time. The atd service could be used by an unsophisticated insider to carry out activities outside of a normal login session, which could complicate accountability. Furthermore, the need to schedule tasks with at or batch is not common. Restrict at and cron to Authorized Users if Necessary The /etc/cron.allow and /etc/at.allow files contain lists of users who are allowed to use cron and at to delay execution of processes. If these files exist and if the corresponding files /etc/cron.deny and /etc/at.deny do not exist, then only users listed in the relevant allow files can run the crontab and at commands to submit jobs to be run at scheduled intervals. On many systems, only the system administrator needs the ability to schedule jobs. Note that even if a given user is not listed in cron.allow, cron jobs can still be run as that user. The cron.allow file controls only administrative access to the crontab command for scheduling and modifying cron jobs.

    To restrict at and cron to only authorized users:
    • Remove the cron.deny file:
      $ sudo rm /etc/cron.deny
    • Edit /etc/cron.allow, adding one line for each user allowed to use the crontab command to create cron jobs.
    • Remove the at.deny file:
      $ sudo rm /etc/at.deny
    • Edit /etc/at.allow, adding one line for each user allowed to use the at command to create at jobs.
         scap-security-guide-0.1.31/SUSE/12/input/xccdf/services/dhcp.xml000066400000000000000000000277541301675746700242330ustar00rootroot00000000000000 DHCP The Dynamic Host Configuration Protocol (DHCP) allows systems to request and obtain an IP address and other configuration parameters from a server.

    This guide recommends configuring networking on clients by manually editing the appropriate files under /etc/sysconfig. Use of DHCP can make client systems vulnerable to compromise by rogue DHCP servers, and should be avoided unless necessary. If using DHCP is necessary, however, there are best practices that should be followed to minimize security risk.     Disable DHCP Server The DHCP server dhcpd is not installed or activated by default. If the software was installed and activated, but the system does not need to act as a DHCP server, it should be disabled and removed. Disable DHCP Service The dhcpd service should be disabled on any system that does not need to act as a DHCP server. Unmanaged or unintentionally activated DHCP servers may provide faulty information to clients, interfering with the operation of a legitimate site DHCP server if there is one. Uninstall DHCP Server Package If the system does not need to act as a DHCP server, the dhcp package can be uninstalled. Removing the DHCP server ensures that it cannot be easily or accidentally reactivated and disrupt network operation. Disable DHCP Server If the system must act as a DHCP server, the configuration information it serves should be minimized. Also, support for other protocols and DNS-updating schemes should be explicitly disabled unless needed. The configuration file for dhcpd is called /etc/dhcp/dhcpd.conf. The file begins with a number of global configuration options. The remainder of the file is divided into sections, one for each block of addresses offered by dhcpd, each of which contains configuration options specific to that address block. Do Not Use Dynamic DNS To prevent the DHCP server from receiving DNS information from clients, edit /etc/dhcp/dhcpd.conf, and add or correct the following global option: 
    ddns-update-style none;
     The Dynamic DNS protocol is used to remotely update the data served by a DNS server. DHCP servers can use Dynamic DNS to publish information about their clients. This setup carries security risks, and its use is not recommended. If Dynamic DNS must be used despite the risks it poses, it is critical that Dynamic DNS transactions be protected using TSIG or some other cryptographic authentication mechanism. See dhcpd.conf(5) for more information about protecting the DHCP server from passing along malicious DNS data from its clients. The ddns-update-style option controls only whether the DHCP server will attempt to act as a Dynamic DNS client. As long as the DNS server itself is correctly configured to reject DDNS attempts, an incorrect ddns-update-style setting on the client is harmless (but should be fixed as a best practice).     Deny Decline Messages Edit /etc/dhcp/dhcpd.conf and add or correct the following global option to prevent the DHCP server from responding the DHCPDECLINE messages, if possible: 
    deny declines;
     The DHCPDECLINE message can be sent by a DHCP client to indicate that it does not consider the lease offered by the server to be valid. By issuing many DHCPDECLINE messages, a malicious client can exhaust the DHCP server's pool of IP addresses, causing the DHCP server to forget old address allocations.     Deny BOOTP Queries Unless your network needs to support older BOOTP clients, disable support for the bootp protocol by adding or correcting the global option: 
    deny bootp;
     The bootp option tells dhcpd to respond to BOOTP queries. If support for this simpler protocol is not needed, it should be disabled to remove attack vectors against the DHCP server.     Minimize Served Information Edit /etc/dhcp/dhcpd.conf. Examine each address range section within the file, and ensure that the following options are not defined unless there is an operational need to provide this information via DHCP: 
    option domain-name
option domain-name-servers
option nis-domain
option nis-servers
option ntp-servers
option routers
option time-offset
     Because the configuration information provided by the DHCP server could be maliciously provided to clients by a rogue DHCP server, the amount of information provided via DHCP should be minimized. Remove these definitions from the DHCP server configuration to ensure that legitimate clients do not unnecessarily rely on DHCP for this information. By default, the Red Hat Enterprise Linux client installation uses DHCP to request much of the above information from the DHCP server. In particular, domain-name, domain-name-servers, and routers are configured via DHCP. These settings are typically necessary for proper network functionality, but are also usually static across machines at a given site.     Configure Logging Ensure that the following line exists in /etc/rsyslog.conf: 
    daemon.*           /var/log/daemon.log
    Configure logwatch or other log monitoring tools to summarize error conditions reported by the dhcpd process.     By default, dhcpd logs notices to the daemon facility. Sending all daemon messages to a dedicated log file is part of the syslog configuration outlined in the Logging and Auditing section     Disable DHCP Client DHCP is the default network configuration method provided by the system installer, and common on many networks. Nevertheless, manual management of IP addresses for systems implies a greater degree of management and accountability for network activity. Disable DHCP Client For each interface on the system (e.g. eth0), edit /etc/sysconfig/network-scripts/ifcfg-interface and make the following changes:
    • Correct the BOOTPROTO line to read: 
      BOOTPROTO=none
    • Add or correct the following lines, substituting the appropriate values based on your site's addressing scheme: 
      NETMASK=255.255.255.0
IPADDR=192.168.1.2
GATEWAY=192.168.1.1
     To verify that DHCP is not being used, examine the following file for each interface: 
    # /etc/sysconfig/network-scripts/ifcfg-interface
    Look for the following: 
    BOOTPROTO=none
    and the following, substituting the appropriate values based on your site's addressing scheme: 
    NETMASK=255.255.255.0
IPADDR=192.168.1.2
GATEWAY=192.168.1.1
     DHCP relies on trusting the local network. If the local network is not trusted, then it should not be used. However, the automatic configuration provided by DHCP is commonly used and the alternative, manual configuration, presents an unacceptable burden in many circumstances.     Configure DHCP Client if Necessary If DHCP must be used, then certain configuration changes can minimize the amount of information it receives and applies from the network, and thus the amount of incorrect information a rogue DHCP server could successfully distribute. For more information on configuring dhclient, see the dhclient(8) and dhclient.conf(5) man pages. Minimize the DHCP-Configured Options Create the file /etc/dhcp/dhclient.conf, and add an appropriate setting for each of the ten configuration settings which can be obtained via DHCP. For each setting, do one of the following:
    If the setting should not be configured remotely by the DHCP server, select an appropriate static value, and add the line: 
    supersede setting value;
    If the setting should be configured remotely by the DHCP server, add the lines: 
    request setting;
require setting;
    For example, suppose the DHCP server should provide only the IP address itself and the subnet mask. Then the entire file should look like: 
    supersede domain-name "example.com";
supersede domain-name-servers 192.168.1.2;
supersede nis-domain "";
supersede nis-servers "";
supersede ntp-servers "ntp.example.com ";
supersede routers 192.168.1.1;
supersede time-offset -18000;
request subnet-mask;
require subnet-mask;
     By default, the DHCP client program, dhclient, requests and applies ten configuration options (in addition to the IP address) from the DHCP server. subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, host-name, nis-domain, nis-servers, and ntp-servers. Many of the options requested and applied by dhclient may be the same for every system on a network. It is recommended that almost all configuration options be assigned statically, and only options which must vary on a host-by-host basis be assigned via DHCP. This limits the damage which can be done by a rogue DHCP server. If appropriate for your site, it is also possible to supersede the host-name directive in /etc/dhcp/dhclient.conf, establishing a static hostname for the machine. However, dhclient does not use the host name option provided by the DHCP server (instead using the value provided by a reverse DNS lookup). In this example, the options nis-servers and nis-domain are set to empty strings, on the assumption that the deprecated NIS protocol is not in use. It is necessary to supersede settings for unused services so that they cannot be set by a hostile DHCP server. If an option is set to an empty string, dhclient will typically not attempt to configure the service.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/services/dns.xml000066400000000000000000000301051301675746700240610ustar00rootroot00000000000000 DNS Server Most organizations have an operational need to run at least one nameserver. However, there are many common attacks involving DNS server software, and this server software should be disabled on any system on which it is not needed. Disable DNS Server DNS software should be disabled on any machine which does not need to be a nameserver. Note that the BIND DNS server software is not installed on Red Hat Enterprise Linux 7 by default. The remainder of this section discusses secure configuration of machines which must be nameservers. Disable DNS Server All network services involve some risk of compromise due to implementation flaws and should be disabled if possible. Uninstall bind Package To remove the bind package, which contains the named service, run the following command: 
    $ sudo yum erase bind
     If there is no need to make DNS server software available, removing it provides a safeguard against its activation.     Isolate DNS from Other Services This section discusses mechanisms for preventing the DNS server from interfering with other services. This is done both to protect the remainder of the network should a nameserver be compromised, and to make direct attacks on nameservers more difficult. Run DNS Software on Dedicated Servers Since DNS is a high-risk service which must frequently be made available to the entire Internet, it is strongly recommended that no other services be offered by machines which act as organizational DNS servers. Run DNS Software in a chroot Jail Install the bind-chroot package: 
    $ sudo yum install bind-chroot
    Place a valid named.conf file inside the chroot jail: 
    $ sudo cp /etc/named.conf /var/named/chroot/etc/named.conf
$ sudo chown root:root /var/named/chroot/etc/named.conf
$ sudo chmod 644 /var/named/chroot/etc/named.conf
    Create and populate an appropriate zone directory within the jail, based on the options directive. If your named.conf includes: 
    options {
directory "/path/to/DIRNAME ";
...
}
    then copy that directory and its contents from the original zone directory: 
    $ sudo cp -r /path/to/DIRNAME /var/named/chroot/DIRNAME
    Add or correct the following line within /etc/sysconfig/named: 
    ROOTDIR=/var/named/chroot
     Chroot jails are not foolproof. However, they serve to make it more difficult for a compromised program to be used to attack the entire host. They do this by restricting a program's ability to traverse the directory upward, so that files outside the jail are not visible to the chrooted process. Since RHEL supports a standard mechanism for placing BIND in a chroot jail, you should take advantage of this feature. If you are running BIND in a chroot jail, then you should use the jailed named.conf as the primary nameserver configuration file. That is, when this guide recommends editing /etc/named.conf, you should instead edit /var/named/chroot/etc/named.conf.     Protect DNS Data from Tampering or Attack This section discusses DNS configuration options which make it more difficult for attackers to gain access to private DNS data or to modify DNS data. Run Separate DNS Servers for External and Internal Queries Is it possible to run external and internal nameservers on separate machines? If so, follow the configuration guidance in this section. On the external nameserver, edit /etc/named.conf to add or correct the following directives: 
    options {
  allow-query { any; };
  recursion no;
  ...
};
zone "example.com " IN {
  ...
};
    On the internal nameserver, edit /etc/named.conf. Add or correct the following directives, where SUBNET is the numerical IP representation of your organization in the form xxx.xxx.xxx.xxx/xx: 
    acl internal {
  SUBNET ;
  localhost;
};
options {
  allow-query { internal; };
  ...
};
zone "internal.example.com " IN {
  ...
};
     Enterprise nameservers generally serve two functions. One is to provide public information about the machines in a domain for the benefit of outside users who wish to contact those machines, for instance in order to send mail to users in the enterprise, or to visit the enterprise's external web page. The other is to provide nameservice to client machines within the enterprise. Client machines require both private information about enterprise machines (which may be different from the public information served to the rest of the world) and public information about machines outside the enterprise, which is used to send mail or visit websites outside of the organization.
    In order to provide the public nameservice function, it is necessary to share data with untrusted machines which request it - otherwise, the enterprise cannot be conveniently contacted by outside users. However, internal data should be protected from disclosure, and serving irrelevant public name queries for outside domains leaves the DNS server open to cache poisoning and other attacks. Therefore, local network nameservice functions should not be provided to untrusted machines.
    Separate machines should be used to fill these two functions whenever possible.     Use Views to Partition External and Internal Information If it is not possible to run external and internal nameservers on separate physical machines, run BIND9 and simulate this feature using views. Edit /etc/named.conf. Add or correct the following directives (where SUBNET is the numerical IP representation of your organization in the form xxx.xxx.xxx.xxx/xx): 
    acl internal {
  SUBNET ;
  localhost;
};
view "internal-view" {
  match-clients { internal; };
  zone "." IN {
    type hint;
    file "db.cache";
  };
  zone "internal.example.com " IN {
    ...
  };
};

view "external-view" {
  match-clients { any; };
  recursion no;
  zone "example.com " IN {
    ...
  };
};
     The view feature is provided by BIND9 as a way to allow a single nameserver to make different sets of data available to different sets of clients. If possible, it is always better to run external and internal nameservers on separate machines, so that even complete compromise of the external server cannot be used to obtain internal data or confuse internal DNS clients. However, this is not always feasible, and use of a feature like views is preferable to leaving internal DNS data entirely unprotected. As shown in the example, database files which are required for recursion, such as the root hints file, must be available to any clients which are allowed to make recursive queries. Under typical circumstances, this includes only the internal clients which are allowed to use this server as a general-purpose nameserver.     Disable Zone Transfers from the Nameserver Is it necessary for a secondary nameserver to receive zone data via zone transfer from the primary server? If not, follow the instructions in this section. If so, see the next section for instructions on protecting zone transfers. Add or correct the following directive within /etc/named.conf: 
    options {
  allow-transfer { none; };
  ...
}
     If both the primary and secondary nameserver are under your control, or if you have only one nameserver, it may be possible to use an external configuration management mechanism to distribute zone updates. In that case, it is not necessary to allow zone transfers within BIND itself, so they should be disabled to avoid the potential for abuse.     Authenticate Zone Transfers If it is necessary for a secondary nameserver to receive zone data via zone transfer from the primary server, follow the instructions here. Use dnssec-keygen to create a symmetric key file in the current directory: 
    $ cd /tmp
$ sudo dnssec-keygen -a HMAC-MD5 -b 128 -n HOST dns.example.com
Kdns.example.com .+aaa +iiiii
    This output is the name of a file containing the new key. Read the file to find the base64-encoded key string: 
    $ sudo cat Kdns.example.com .+NNN +MMMMM .key
dns.example.com IN KEY 512 3 157 base64-key-string
    Add the directives to /etc/named.conf on the primary server: 
    key zone-transfer-key {
  algorithm hmac-md5;
  secret "base64-key-string ";
};
zone "example.com " IN {
  type master;
  allow-transfer { key zone-transfer-key; };
  ...
};
    Add the directives below to /etc/named.conf on the secondary nameserver: 
    key zone-transfer-key {
  algorithm hmac-md5;
  secret "base64-key-string ";
};

server IP-OF-MASTER {
  keys { zone-transfer-key; };
};

zone "example.com " IN {
  type slave;
  masters { IP-OF-MASTER ; };
  ...
};
     The BIND transaction signature (TSIG) functionality allows primary and secondary nameservers to use a shared secret to verify authorization to perform zone transfers. This method is more secure than using IP-based limiting to restrict nameserver access, since IP addresses can be easily spoofed. However, if you cannot configure TSIG between your servers because, for instance, the secondary nameserver is not under your control and its administrators are unwilling to configure TSIG, you can configure an allow-transfer directive with numerical IP addresses or ACLs as a last resort. The purpose of the dnssec-keygen command is to create the shared secret string base64-key-string. Once this secret has been obtained and inserted into named.conf on the primary and secondary servers, the key files Kdns.example.com .+NNN +MMMMM .key and Kdns.example.com .+NNN +MMMMM .private are no longer needed, and may safely be deleted.     Disable Dynamic Updates Is there a mission-critical reason to enable the risky dynamic update functionality? If not, edit /etc/named.conf. For each zone specification, correct the following directive if necessary: 
    zone "example.com " IN {
  allow-update { none; };
  ...
};
     Dynamic updates allow remote servers to add, delete, or modify any entries in your zone file. Therefore, they should be considered highly risky, and disabled unless there is a very good reason for their use. If dynamic updates must be allowed, IP-based ACLs are insufficient protection, since they are easily spoofed. Instead, use TSIG keys (see the previous section for an example), and consider using the update-policy directive to restrict changes to only the precise type of change needed.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/services/ftp.xml000066400000000000000000000251731301675746700240770ustar00rootroot00000000000000 FTP Server FTP is a common method for allowing remote access to files. Like telnet, the FTP protocol is unencrypted, which means that passwords and other data transmitted during the session can be captured and that the session is vulnerable to hijacking. Therefore, running the FTP server software is not recommended.

    However, there are some FTP server configurations which may be appropriate for some environments, particularly those which allow only read-only anonymous access as a means of downloading data available to the public.     Disable vsftpd if Possible To minimize attack surface, disable vsftpd if at all possible. Disable vsftpd Service Running FTP server software provides a network-based avenue of attack, and should be disabled if not needed. Furthermore, the FTP protocol is unencrypted and creates a risk of compromising sensitive information. Uninstall vsftpd Package Removing the vsftpd package decreases the risk of its accidental activation. Use vsftpd to Provide FTP Service if Necessary If your use-case requires FTP service, install and set-up vsftpd to provide it. Install vsftpd Package If this machine must operate as an FTP server, install the vsftpd package via the standard channels. 
    $ sudo yum install vsftpd
     After Red Hat Enterprise Linux 2.1, Red Hat switched from distributing wu-ftpd with Red Hat Enterprise Linux to distributing vsftpd. For security and for consistency with future Red Hat releases, the use of vsftpd is recommended.     Use vsftpd to Provide FTP Service if Necessary The primary vsftpd configuration file is /etc/vsftpd.conf, if that file exists, or /etc/vsftpd/vsftpd.conf if it does not. Enable Logging of All FTP Transactions Add or correct the following configuration options within the vsftpd configuration file, located at /etc/vsftpd/vsftpd.conf: 
    xferlog_enable=YES
xferlog_std_format=NO
log_ftp_protocol=YES
     Find if logging is applied to the FTP daemon.

    Procedures:

    If vsftpd is started by xinetd the following command will indicate the xinetd.d startup file: 
    $ grep vsftpd /etc/xinetd.d/*
    $ grep server_args vsftpd xinetd.d startup file
    This will indicate the vsftpd config file used when starting through xinetd. If the server_args line is missing or does not include the vsftpd configuration file, then the default config file (/etc/vsftpd/vsftpd.conf) is used. 
    $ sudo grep xferlog_enable vsftpd config file
     To trace malicious activity facilitated by the FTP service, it must be configured to ensure that all commands sent to the FTP server are logged using the verbose vsftpd log format. The default vsftpd log file is /var/log/vsftpd.log. If verbose logging to vsftpd.log is done, sparse logging of downloads to /var/log/xferlog will not also occur. However, the information about what files were downloaded is included in the information logged to vsftpd.log     Create Warning Banners for All FTP Users Edit the vsftpd configuration file, which resides at /etc/vsftpd/vsftpd.conf by default. Add or correct the following configuration options: 
    banner_file=/etc/issue
     This setting will cause the system greeting banner to be used for FTP connections as well. If FTP services are not installed, this is not applicable.

    To verify this configuration, run the following command: 
    grep "banner_file" /etc/vsftpd/vsftpd.conf
    The output should show the value of banner_file is set to /etc/issue, an example of which is shown below: 
    $ sudo grep "banner_file" /etc/vsftpd/vsftpd.conf
banner_file=/etc/issue
         Restrict the Set of Users Allowed to Access FTP This section describes how to disable non-anonymous (password-based) FTP logins, or, if it is not possible to do this entirely due to legacy applications, how to restrict insecure FTP login to only those users who have an identified need for this access. Restrict Access to Anonymous Users if Possible Is there a mission-critical reason for users to transfer files to/from their own accounts using FTP, rather than using a secure protocol like SCP/SFTP? If not, edit the vsftpd configuration file. Add or correct the following configuration option: 
    local_enable=NO
    If non-anonymous FTP logins are necessary, follow the guidance in the remainder of this section to secure these logins as much as possible.     The use of non-anonymous FTP logins is strongly discouraged. Since SSH clients and servers are widely available, and since SSH provides support for a transfer mode which resembles FTP in user interface, there is no good reason to allow password-based FTP access.     Limit Users Allowed FTP Access if Necessary If there is a mission-critical reason for users to access their accounts via the insecure FTP protocol, limit the set of users who are allowed this access. Edit the vsftpd configuration file. Add or correct the following configuration options: 
    userlist_enable=YES
userlist_file=/etc/vsftp.ftpusers
userlist_deny=NO
    Edit the file /etc/vsftp.ftpusers. For each user USERNAME who should be allowed to access the system via FTP, add a line containing that user's name: 
    USERNAME
    If anonymous access is also required, add the anonymous usernames to /etc/vsftp.ftpusers as well. 
    anonymous
ftp
     Historically, the file /etc/ftpusers contained a list of users who were not allowed to access the system via FTP. It was used to prevent system users such as the root user from logging in via the insecure FTP protocol. However, when the configuration option userlist deny=NO is set, vsftpd interprets ftpusers as the set of users who are allowed to login via FTP. Since it should be possible for most users to access their accounts via secure protocols, it is recommended that this setting be used, so that non-anonymous FTP access can be limited to legacy users who have been explicitly identified.     Disable FTP Uploads if Possible Is there a mission-critical reason for users to upload files via FTP? If not, edit the vsftpd configuration file to add or correct the following configuration options: 
    write_enable=NO
    If FTP uploads are necessary, follow the guidance in the remainder of this section to secure these transactions as much as possible.     Anonymous FTP can be a convenient way to make files available for universal download. However, it is less common to have a need to allow unauthenticated users to place files on the FTP server. If this must be done, it is necessary to ensure that files cannot be uploaded and downloaded from the same directory.     Place the FTP Home Directory on its Own Partition By default, the anonymous FTP root is the home directory of the FTP user account. The df command can be used to verify that this directory is on its own partition. If there is a mission-critical reason for anonymous users to upload files, precautions must be taken to prevent these users from filling a disk used by other services. Configure Firewalls to Protect the FTP Server By default, firewalld blocks access to the ports used by the web server. These settings configure firewalld to allow connections to an FTP server. The first line allows initial connections to the FTP server port. FTP is an older protocol which is not very compatible with firewalls. During the initial FTP dialogue, the client and server negotiate an arbitrary port to be used for data transfer. The ip_conntrack_ftp module is used by firewalld to listen to that dialogue and allow connections to the data ports which FTP negotiates. This allows an FTP server to operate on a machine which is running a firewall.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/services/http.xml000066400000000000000000000777661301675746700243040ustar00rootroot00000000000000 Web Server The web server is responsible for providing access to content via the HTTP protocol. Web servers represent a significant security risk because:

    • The HTTP port is commonly probed by malicious sources
    • Web server software is very complex, and includes a long history of vulnerabilities
    • The HTTP protocol is unencrypted and vulnerable to passive monitoring


    The system's default web server software is Apache 2 and is provided in the RPM package httpd.     Disable Apache if Possible If Apache was installed and activated, but the system does not need to act as a web server, then it should be disabled and removed from the system. Disable httpd Service Running web server software provides a network-based avenue of attack, and should be disabled if not needed. Uninstall httpd Package If there is no need to make the web server software available, removing it provides a safeguard against its activation. Install Apache if Necessary If httpd was not installed and activated, but the system needs to act as a web server, then it should be installed on the system. Follow these guidelines to install it defensively. The httpd package can be installed with the following command: 
    $ sudo yum install httpd
    This method of installation is recommended over installing the "Web Server" package group during the system installation process. The Web Server package group includes many packages which are likely extraneous, while the command-line method installs only the required httpd package itself.     Confirm Minimal Built-in Modules Installed The default httpd installation minimizes the number of modules that are compiled directly into the binary (core prefork http_core mod_so). This minimizes risk by limiting the capabilities allowed by the web server. Query the set of compiled-in modules using the following command: 
    $ httpd -l
    If the number of compiled-in modules is significantly larger than the aforementioned set, this guide recommends re-installing httpd with a reduced configuration. Minimizing the number of modules that are compiled into the httpd binary, reduces risk by limiting the capabilities allowed by the webserver.     Secure Apache Configuration The httpd configuration file is /etc/httpd/conf/httpd.conf. Apply the recommendations in the remainder of this section to this file. Restrict Web Server Information Leakage The ServerTokens and ServerSignature directives determine how much information the web server discloses about the configuration of the system. Set httpd <tt>ServerTokens</tt> Directive to <tt>Prod</tt> ServerTokens Prod restricts information in page headers, returning only the word "Apache."

    Add or correct the following directive in /etc/httpd/conf/httpd.conf: 
    ServerTokens Prod
     Information disclosed to clients about the configuration of the web server and system could be used to plan an attack on the given system. This information disclosure should be restricted to a minimum.     Set httpd <tt>ServerSignature</tt> Directive to <tt>Off</tt> ServerSignature Off restricts httpd from displaying server version number on error pages.

    Add or correct the following directive in /etc/httpd/conf/httpd.conf: 
    ServerSignature Off
     Information disclosed to clients about the configuration of the web server and system could be used to plan an attack on the given system. This information disclosure should be restricted to a minimum.     Minimize Web Server Loadable Modules A default installation of httpd includes a plethora of dynamically shared objects (DSO) that are loaded at run-time. Unlike the aforementioned compiled-in modules, a DSO can be disabled in the configuration file by removing the corresponding LoadModule directive.

    Note: A DSO only provides additional functionality if associated directives are included in the httpd configuration file. It should also be noted that removing a DSO will produce errors on httpd startup if the configuration file contains directives that apply to that module. Refer to http://httpd.apache.org/docs/ for details on which directives are associated with each DSO.

    Following each DSO removal, the configuration can be tested with the following command to check if everything still works: 
    $ sudo service httpd configtest
    The purpose of each of the modules loaded by default will now be addressed one at a time. If none of a module's directives are being used, remove it.     <tt>httpd</tt> Core Modules These modules comprise a basic subset of modules that are likely needed for base httpd functionality; ensure they are not commented out in /etc/httpd/conf/httpd.conf: 
    LoadModule auth_basic_module modules/mod_auth_basic.so
LoadModule authn_default_module modules/mod_authn_default.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule authz_user_module modules/mod_authz_user.so
LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
LoadModule authz_default_module modules/mod_authz_default.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule logio_module modules/mod_logio.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule mime_module modules/mod_mome.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule negotiation_module modules/mod_negotiation.so
LoadModule dir_module modules/mod_dir.so
LoadModule alias_module modules/mod_alias.so
    Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server.     Minimize Modules for HTTP Basic Authentication The following modules are necessary if this web server will provide content that will be restricted by a password.

    Authentication can be performed using local plain text password files (authn_file), local DBM password files (authn_dbm) or an LDAP directory. The only module required by the web server depends on your choice of authentication. Comment out the modules you don't need from the following: 
    LoadModule authn_file_module modules/mod_authn_file.so
LoadModule authn_dbm_module modules/mod_authn_dbm.so
    authn_alias allows for authentication based on aliases. authn_anon allows anonymous authentication similar to that of anonymous ftp sites. authz_owner allows authorization based on file ownership. authz_dbm allows for authorization based on group membership if the web server is using DBM authentication.

    If the above functionality is unnecessary, comment out the related module: 
    #LoadModule authn_alias_module modules/mod_authn_alias.so
#LoadModule authn_anon_module modules/mod_authn_anon.so
#LoadModule authz_owner_module modules/mod_authz_owner.so
#LoadModule authz_dbm_module modules/mod_authz_dbm.so
         Disable HTTP Digest Authentication The auth_digest module provides encrypted authentication sessions. If this functionality is unnecessary, comment out the related module: 
    #LoadModule auth_digest_module modules/mod_auth_digest.so
     Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server.     Disable HTTP mod_rewrite The mod_rewrite module is very powerful and can protect against certain classes of web attacks. However, it is also very complex and has a significant history of vulnerabilities itself. If its functionality is unnecessary, comment out the related module: 
    #LoadModule rewrite_module modules/mod_rewrite.so
     Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server.     Disable LDAP Support The ldap module provides HTTP authentication via an LDAP directory. If its functionality is unnecessary, comment out the related modules: 
    #LoadModule ldap_module modules/mod_ldap.so
#LoadModule authnz_ldap_module modules/mod_authnz_ldap.so
    If LDAP is to be used, SSL encryption should be used as well.     Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server.     Disable Server Side Includes Server Side Includes provide a method of dynamically generating web pages through the insertion of server-side code. However, the technology is also deprecated and introduces significant security concerns. If this functionality is unnecessary, comment out the related module: 
    #LoadModule include_module modules/mod_include.so
    If there is a critical need for Server Side Includes, they should be enabled with the option IncludesNoExec to prevent arbitrary code execution. Additionally, user supplied data should be encoded to prevent cross-site scripting vulnerabilities.     Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server.     Disable MIME Magic The mime_magic module provides a second layer of MIME support that in most configurations is likely extraneous. If its functionality is unnecessary, comment out the related module: 
    #LoadModule mime_magic_module modules/mod_mime_magic.so
     Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server.     Disable WebDAV (Distributed Authoring and Versioning) WebDAV is an extension of the HTTP protocol that provides distributed and collaborative access to web content. If its functionality is unnecessary, comment out the related modules: 
    #LoadModule dav_module modules/mod_dav.so
#LoadModule dav_fs_module modules/mod_dav_fs.so
    If there is a critical need for WebDAV, extra care should be taken in its configuration. Since DAV access allows remote clients to manipulate server files, any location on the server that is DAV enabled should be protected by access controls.     Minimizing the number of loadable modules available to the web server, reduces risk by limiting the capabilities allowed by the web server.     Disable Server Activity Status The status module provides real-time access to statistics on the internal operation of the web server. This may constitute an unnecessary information leak and should be disabled unless necessary. To do so, comment out the related module: 
    #LoadModule status_module modules/mod_status.so
    If there is a critical need for this module, ensure that access to the status page is properly restricted to a limited set of hosts in the status handler configuration.     Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server.     Disable Web Server Configuration Display The info module creates a web page illustrating the configuration of the web server. This can create an unnecessary security leak and should be disabled. If its functionality is unnecessary, comment out the module: 
    #LoadModule info_module modules/mod_info.so
    If there is a critical need for this module, use the Location directive to provide an access control list to restrict access to the information.     Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server.     Disable URL Correction on Misspelled Entries The speling module attempts to find a document match by allowing one misspelling in an otherwise failed request. If this functionality is unnecessary, comment out the module: 
    #LoadModule speling_module modules/mod_speling.so
    This functionality weakens server security by making site enumeration easier.     Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server.     Disable Proxy Support The proxy module provides proxying support, allowing httpd to forward requests and serve as a gateway for other servers. If its functionality is unnecessary, comment out the module: 
    #LoadModule proxy_module modules/mod_proxy.so
    If proxy support is needed, load mod_proxy and the appropriate proxy protocol handler module (one of mod_proxy_http, mod_proxy_ftp, or mod_proxy_connect). Additionally, make certain that a server is secure before enabling proxying, as open proxy servers are a security risk. mod_proxy_balancer enables load balancing, but requires that mod status be enabled.     Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server.     Disable Cache Support The cache module allows httpd to cache data, optimizing access to frequently accessed content. However, it introduces potential security flaws such as the possibility of circumventing Allow and Deny directives.

    If this functionality is unnecessary, comment out the module: 
    #LoadModule cache_module modules/mod_cache.so
    If caching is required, it should not be enabled for any limited-access content.     Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server.     Disable CGI Support The cgi module allows HTML to interact with the CGI web programming language.

    If this functionality is unnecessary, comment out the module: 
    #LoadModule cgi_module modules/mod_cgi.so
    If the web server requires the use of CGI, enable mod_cgi.     Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server.     Minimize Various Optional Components The following modules perform very specific tasks, sometimes providing access to just a few additional directives. If such functionality is not required (or if you are not using these directives), comment out the associated module:
    • External filtering (response passed through external program prior to client delivery) 
      #LoadModule ext_filter_module modules/mod_ext_filter.so
    • User-specified Cache Control and Expiration 
      #LoadModule expires_module modules/mod_expires.so
    • Compression Output Filter (provides content compression prior to client delivery) 
      #LoadModule deflate_module modules/mod_deflate.so
    • HTTP Response/Request Header Customization 
      #LoadModule headers_module modules/mod_headers.so
    • User activity monitoring via cookies 
      #LoadModule usertrack_module modules/mod_usertrack.so
    • Dynamically configured mass virtual hosting 
      #LoadModule vhost_alias_module modules/mod_vhost_alias.so
    Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server.     Minimize Configuration Files Included The Include directive directs httpd to load supplementary configuration files from a provided path. The default configuration loads all files that end in .conf from the /etc/httpd/conf.d directory.

    To restrict excess configuration, the following line should be commented out and replaced with Include directives that only reference required configuration files: 
    #Include conf.d/*.conf
    If the above change was made, ensure that the SSL encryption remains loaded by explicitly including the corresponding configuration file: 
    Include conf.d/ssl.conf
    If PHP is necessary, a similar alteration must be made: 
    Include conf.d/php.conf
    Explicitly listing the configuration files to be loaded during web server start-up avoids the possibility of unwanted or malicious configuration files to be automatically included as part of the server's running configuration.     Directory Restrictions The Directory tags in the web server configuration file allow finer grained access control for a specified directory. All web directories should be configured on a case-by-case basis, allowing access only where needed. Restrict Root Directory The httpd root directory should always have the most restrictive configuration enabled. 
    <Directory / >
   Options None
   AllowOverride None
   Order allow,deny
</Directory>
     The Web Server's root directory content should be protected from unauthorized access by web clients.     Restrict Web Directory The default configuration for the web (/var/www/html) Directory allows directory indexing (Indexes) and the following of symbolic links (FollowSymLinks). Neither of these is recommended.

    The /var/www/html directory hierarchy should not be viewable via the web, and symlinks should only be followed if the owner of the symlink also owns the linked file.

    Ensure that this policy is adhered to by altering the related section of the configuration: 
    <Directory "/var/www/html">
#  ...
   Options SymLinksIfOwnerMatch
#  ...
</Directory>
     Access to the web server's directory hierarchy could allow access to unauthorized files by web clients. Following symbolic links could also allow such access.     Restrict Other Critical Directories All accessible web directories should be configured with similarly restrictive settings. The Options directive should be limited to necessary functionality and the AllowOverride directive should be used only if needed. The Order and Deny access control tags should be used to deny access by default, allowing access only where necessary. Directories accessible from a web client should be configured with the least amount of access possible in order to avoid unauthorized access to restricted content or server information. Limit Available Methods Web server methods are defined in section 9 of RFC 2616 (http://www.ietf.org/rfc/rfc2616.txt). If a web server does not require the implementation of all available methods, they should be disabled.

    Note: GET and POST are the most common methods. A majority of the others are limited to the WebDAV protocol. 
    <Directory /var/www/html>
# ...
   # Only allow specific methods (this command is case-sensitive!)
   <LimitExcept GET POST>
      Order allow,deny
   </LimitExcept>
# ...
</Directory>
     Minimizing the number of available methods to the web client reduces risk by limiting the capabilities allowed by the web server.     Use Appropriate Modules to Improve <tt>httpd</tt>'s Security Among the modules available for httpd are several whose use may improve the security of the web server installation. This section recommends and discusses the deployment of security-relevant modules. Deploy <tt>mod_ssl</tt> Because HTTP is a plain text protocol, all traffic is susceptible to passive monitoring. If there is a need for confidentiality, SSL should be configured and enabled to encrypt content.

    Note: mod_nss is a FIPS 140-2 certified alternative to mod_ssl. The modules share a considerable amount of code and should be nearly identical in functionality. If FIPS 140-2 validation is required, then mod_nss should be used. If it provides some feature or its greater compatibility is required, then mod_ssl should be used.     Install <tt>mod_ssl</tt> Install the mod_ssl module: 
    $ sudo yum install mod_ssl
     mod_ssl provides encryption capabilities for the httpd Web server. Unencrypted content is transmitted in plain text which could be passively monitored and accessed by unauthorized parties.     Deploy <tt>mod_security</tt> The security module provides an application level firewall for httpd. Following its installation with the base ruleset, specific configuration advice can be found at http://www.modsecurity.org/ to design a policy that best matches the security needs of the web applications. Usage of mod_security is highly recommended for some environments, but it should be noted this module does not ship with Red Hat Enterprise Linux itself, and instead is provided via Extra Packages for Enterprise Linux (EPEL). For more information on EPEL please refer to http://fedoraproject.org/wiki/EPEL. Install <tt>mod_security</tt> Install the security module: 
    $ sudo yum install mod_security
     mod_security provides an additional level of protection for the web server by enabling the administrator to implement content access policies and filters at the application layer.     Use Denial-of-Service Protection Modules Denial-of-service attacks are difficult to detect and prevent while maintaining acceptable access to authorized users. However, some traffic-shaping modules can be used to address the problem. Well-known DoS protection modules include: 
    mod_cband mod_bwshare mod_limitipconn mod_evasive
    Denial-of-service prevention should be implemented for a web server if such a threat exists. However, specific configuration details are very dependent on the environment and often best left at the discretion of the administrator.     Configure PHP Securely PHP is a widely-used and often misconfigured server-side scripting language. It should be used with caution, but configured appropriately when needed.

    Review /etc/php.ini and make the following changes if possible: 
    # Do not expose PHP error messages to external users
display_errors = Off

# Enable safe mode
safe_mode = On

# Only allow access to executables in isolated directory
safe_mode_exec_dir = php-required-executables-path

# Limit external access to PHP environment
safe_mode_allowed_env_vars = PHP_

# Restrict PHP information leakage
expose_php = Off

# Log all errors
log_errors = On

# Do not register globals for input data
register_globals = Off

# Minimize allowable PHP post size
post_max_size = 1K

# Ensure PHP redirects appropriately
cgi.force_redirect = 0

# Disallow uploading unless necessary
file_uploads = Off

# Disallow treatment of file requests as fopen calls
allow_url_fopen = Off

# Enable SQL safe mode
sql.safe_mode = On
    Configure Operating System to Protect Web Server The following configuration steps should be taken on the machine which hosts the web server, in order to provide as safe an environment as possible for the web server. Restrict File and Directory Access Minimize access to critical httpd files and directories. Set Permissions on the <tt>/var/log/httpd/</tt> Directory Ensure that the permissions on the web server log directory is set to 700: 
    $ sudo chmod 700 /var/log/httpd/
    This is its default setting.     Access to the web server's log files may allow an unauthorized user or attacker to access information about the web server or alter the server's log files.     Set Permissions on the <tt>/etc/httpd/conf/</tt> Directory Set permissions on the web server configuration directory to 750: 
    $ sudo chmod 750 /etc/httpd/conf/
     Access to the web server's configuration files may allow an unauthorized user or attacker to access information about the web server or alter the server's configuration files.     Set Permissions on All Configuration Files Inside <tt>/etc/httpd/conf/</tt> Set permissions on the web server configuration files to 640: 
    $ sudo chmod 640 /etc/httpd/conf/*
     Access to the web server's configuration files may allow an unauthorized user or attacker to access information about the web server or to alter the server's configuration files.     Configure <tt>firewalld</tt> to Allow Access to the Web Server By default, firewalld blocks access to the ports used by the web server. Run <tt>httpd</tt> in a <tt>chroot</tt> Jail if Practical Running httpd inside a chroot jail is designed to isolate the web server process to a small section of the filesystem, limiting the damage if it is compromised. Versions of Apache greater than 2.2.10 (such as the one included with Red Hat Enterprise Linux 7) provide the ChrootDir directive. To run Apache inside a chroot jail in /chroot/apache, add the following line to /etc/httpd/conf/httpd.conf: 
    ChrootDir /chroot/apache
    This necessitates placing all files required by httpd inside /chroot/apache , including httpd's binaries, modules, configuration files, and served web pages. The details of this configuration are beyond the scope of this guide. This may also require additional SELinux configuration.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/services/imap.xml000066400000000000000000000157031301675746700242320ustar00rootroot00000000000000 IMAP and POP3 Server Dovecot provides IMAP and POP3 services. It is not installed by default. The project page at http://www.dovecot.org contains more detailed information about Dovecot configuration. Disable Dovecot If the system does not need to operate as an IMAP or POP3 server, the dovecot software should be disabled and removed. Disable Dovecot Service Running an IMAP or POP3 server provides a network-based avenue of attack, and should be disabled if not needed. Uninstall dovecot Package The dovecot package can be uninstalled with the following command: 
    $ sudo yum erase dovecot
     If there is no need to make the Dovecot software available, removing it provides a safeguard against its activation.     Configure Dovecot if Necessary If the system will operate as an IMAP or POP3 server, the dovecot software should be configured securely by following the recommendations below. Support Only the Necessary Protocols Dovecot supports the IMAP and POP3 protocols, as well as SSL-protected versions of those protocols. Configure the Dovecot server to support only the protocols needed by your site. Edit /etc/dovecot/dovecot.conf. Add or correct the following lines, replacing PROTOCOL with only the subset of protocols (imap, imaps, pop3, pop3s) required: 
    protocols = PROTOCOL
    If possible, require SSL protection for all transactions. The SSL protocol variants listen on alternate ports (995 instead of 110 for pop3s, and 993 instead of 143 for imaps), and require SSL-aware clients. An alternate approach is to listen on the standard port and require the client to use the STARTTLS command before authenticating.     Configuring Dovecot to only support the protocols the protocols needed by your site reduces the risk of an attacker using one of the unused protocols to base an attack.     Enable SSL Support SSL should be used to encrypt network traffic between the Dovecot server and its clients. Users must authenticate to the Dovecot server in order to read their mail, and passwords should never be transmitted in clear text. In addition, protecting mail as it is downloaded is a privacy measure, and clients may use SSL certificates to authenticate the server, preventing another system from impersonating the server. Enable the SSL flag in <tt>/etc/dovecot.conf</tt> To allow clients to make encrypted connections the ssl flag in Dovecot's configuration file needs to be set to yes.

    Edit /etc/dovecot/conf.d/10-ssl.conf and add or correct the following line: 
    ssl = yes
     SSL encrypt network traffic between the Dovecot server and its clients protecting user credentials, mail as it is downloaded, and clients may use SSL certificates to authenticate the server, preventing another system from impersonating the server.     Configure Dovecot to Use the SSL Certificate file This option tells Dovecot where to find the the mail server's SSL Certificate.

    Edit /etc/dovecot/conf.d/10-ssl.conf and add or correct the following line (note: the path below is the default path set by the Dovecot installation. If you are using a different path, ensure you reference the appropriate file): 
    ssl_cert = </etc/pki/dovecot/certs/dovecot.pem
     SSL certificates are used by the client to authenticate the identity of the server, as well as to encrypt credentials and message traffic. Not using SSL to encrypt mail server traffic could allow unauthorized access to credentials and mail messages since they are sent in plain text over the network.     Configure Dovecot to Use the SSL Key file This option tells Dovecot where to find the the mail server's SSL Key.

    Edit /etc/dovecot/conf.d/10-ssl.conf and add or correct the following line (note: the path below is the default path set by the Dovecot installation. If you are using a different path, ensure you reference the appropriate file): 
    ssl_key = </etc/pki/dovecot/private/dovecot.pem
     SSL certificates are used by the client to authenticate the identity of the server, as well as to encrypt credentials and message traffic. Not using SSL to encrypt mail server traffic could allow unauthorized access to credentials and mail messages since they are sent in plain text over the network.     Disable Plaintext Authentication To prevent Dovecot from attempting plaintext authentication of clients, edit /etc/dovecot/conf.d/10-auth.conf and add or correct the following line: 
    disable_plaintext_auth = yes
     Using plain text authentication to the mail server could allow an attacker access to credentials by monitoring network traffic.     Allow IMAP Clients to Access the Server The default firewalld configuration does not allow inbound access to any services. This modification will allow remote hosts to initiate connections to the IMAP daemon, while keeping all other ports on the server in their default protected state.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/services/ldap.xml000066400000000000000000000156171301675746700242300ustar00rootroot00000000000000 LDAP LDAP is a popular directory service, that is, a standardized way of looking up information from a central database. Red Hat Enterprise Linux 7 includes software that enables a system to act as both an LDAP client and server. Configure OpenLDAP Clients This section provides information on which security settings are important to configure in OpenLDAP clients by manually editing the appropriate configuration files. Red Hat Enterprise Linux 7 provides an automated configuration tool called authconfig and a graphical wrapper for authconfig called system-config-authentication. However, these tools do not provide as much control over configuration as manual editing of configuration files. The authconfig tools do not allow you to specify locations of SSL certificate files, which is useful when trying to use SSL cleanly across several protocols. Installation and configuration of OpenLDAP on Red Hat Enterprise Linux 7 is available at https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/ch-Directory_Servers.html. Before configuring any system to be an LDAP client, ensure that a working LDAP server is present on the network. Configure LDAP Client to Use TLS For All Transactions This check verifies that RHEL7 impliments cryptography to protect the integrity of remote LDAP authentication sessions.

    To determine if LDAP is being used for authentication, use the following command: 
    $ sudo grep -i useldapauth /etc/sysconfig/authconfig


    If USELDAPAUTH=yes, then LDAP is being used. To check if LDAP is configured to use TLS, use the following command: 
    $ sudo grep -i ssl /etc/pam_ldap.conf
     If the system is not using TLS, set the ssl option in /etc/pam_ldap.conf to start_tls. Without cryptographic integrity protections, information can be altered by unauthorized users without detection. The ssl directive specifies whether to use TLS or not. If not specified it will default to no. It should be set to start_tls rather than doing LDAP over SSL.     Configure Certificate Directives for LDAP Use of TLS Ensure a copy of a trusted CA certificate has been placed in the file /etc/pki/tls/CA/cacert.pem. Configure LDAP to enforce TLS use and to trust certificates signed by that CA. First, edit the file /etc/nslcd.conf, and add or correct either of the following lines: 
    tls_cacertdir /etc/pki/tls/CA
    or 
    tls_cacertfile /etc/pki/tls/CA/cacert.pem
    Then review the LDAP server and ensure TLS has been configured.     To ensure TLS is configured with trust certificates, run the following command: 
    $ grep cert /etc/nslcd.conf
     The tls_cacertdir or tls_cacertfile directives are required when tls_checkpeer is configured (which is the default for openldap versions 2.1 and up). These directives define the path to the trust certificates signed by the site CA.     Configure OpenLDAP Server This section details some security-relevant settings for an OpenLDAP server. Installation and configuration of OpenLDAP on Red Hat Enterprise Linux 7 is available at: https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/ch-Directory_Servers.html. Uninstall openldap-servers Package The openldap-servers package should be removed if not in use. Is this machine the OpenLDAP server? If not, remove the package. 
    $ sudo yum erase openldap-servers
    The openldap-servers RPM is not installed by default on Red Hat Enterprise Linux 7 machines. It is needed only by the OpenLDAP server, not by the clients which use LDAP for authentication. If the system is not intended for use as an LDAP Server it should be removed.     To verify the openldap-servers package is not installed, run the following command: 
    $ rpm -q openldap-servers
    The output should show the following: 
    package openldap-servers is not installed
     Unnecessary packages should not be installed to decrease the attack surface of the system. While this software is clearly essential on an LDAP server, it is not necessary on typical desktop or workstation systems.     Install and Protect LDAP Certificate Files Create the PKI directory for LDAP certificates if it does not already exist: 
    $ sudo mkdir /etc/pki/tls/ldap
$ sudo chown root:root /etc/pki/tls/ldap
$ sudo chmod 755 /etc/pki/tls/ldap
    Using removable media or some other secure transmission format, install the certificate files onto the LDAP server:
    • /etc/pki/tls/ldap/serverkey.pem: the private key ldapserverkey.pem
    • /etc/pki/tls/ldap/servercert.pem: the certificate file ldapservercert.pem
    Verify the ownership and permissions of these files: 
    $ sudo chown root:ldap /etc/pki/tls/ldap/serverkey.pem
$ sudo chown root:ldap /etc/pki/tls/ldap/servercert.pem
$ sudo chmod 640 /etc/pki/tls/ldap/serverkey.pem
$ sudo chmod 640 /etc/pki/tls/ldap/servercert.pem
    Verify that the CA's public certificate file has been installed as /etc/pki/tls/CA/cacert.pem, and has the correct permissions: 
    $ sudo mkdir /etc/pki/tls/CA
$ sudo chown root:root /etc/pki/tls/CA/cacert.pem
$ sudo chmod 644 /etc/pki/tls/CA/cacert.pem
    As a result of these steps, the LDAP server will have access to its own private certificate and the key with which that certificate is encrypted, and to the public certificate file belonging to the CA. Note that it would be possible for the key to be protected further, so that processes running as ldap could not read it. If this were done, the LDAP server process would need to be restarted manually whenever the server rebooted.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/services/mail.xml000066400000000000000000000326111301675746700242230ustar00rootroot00000000000000 Mail Server Software Mail servers are used to send and receive email over the network. Mail is a very common service, and Mail Transfer Agents (MTAs) are obvious targets of network attack. Ensure that machines are not running MTAs unnecessarily, and configure needed MTAs as defensively as possible.

    Very few systems at any site should be configured to directly receive email over the network. Users should instead use mail client programs to retrieve email from a central server that supports protocols such as IMAP or POP3. However, it is normal for most systems to be independently capable of sending email, for instance so that cron jobs can report output to an administrator. Most MTAs, including Postfix, support a submission-only mode in which mail can be sent from the local system to a central site MTA (or directly delivered to a local account), but the system still cannot receive mail directly over a network.

    The alternatives program in Red Hat Enterprise Linux permits selection of other mail server software (such as Sendmail), but Postfix is the default and is preferred. Postfix was coded with security in mind and can also be more effectively contained by SELinux as its modular design has resulted in separate processes performing specific actions. More information is available on its website, http://www.postfix.org.     Enable Postfix Service The Postfix mail transfer agent is used for local mail delivery within the system. The default configuration only listens for connections to the default SMTP port (port 25) on the loopback interface (127.0.0.1). It is recommended to leave this service enabled for local mail delivery. Local mail delivery is essential to some system maintenance and notification tasks. Uninstall Sendmail Package Sendmail is not the default mail transfer agent and is not installed by default. The sendmail software was not developed with security in mind and its design prevents it from being effectively contained by SELinux. Postfix should be used instead. Configure SMTP For Mail Clients This section discusses settings for Postfix in a submission-only e-mail configuration. Disable Postfix Network Listening Edit the file /etc/postfix/main.cf to ensure that only the following inet_interfaces line appears: 
    inet_interfaces = localhost
     Run the following command to ensure postfix accepts mail messages from only the local system: 
    $ grep inet_interfaces /etc/postfix/main.cf
    If properly configured, the output should show only localhost.     This ensures postfix accepts mail messages (such as cron job reports) from the local system only, and not from the network, which protects it from network attack.     Configure Operating System to Protect Mail Server The guidance in this section is appropriate for any host which is operating as a site MTA, whether the mail server runs using Sendmail, Postfix, or some other software. Configure SSL Certificates for Use with SMTP AUTH If SMTP AUTH is to be used, the use of SSL to protect credentials in transit is strongly recommended. There are also configurations for which it may be desirable to encrypt all mail in transit from one MTA to another, though such configurations are beyond the scope of this guide. In either event, the steps for creating and installing an SSL certificate are independent of the MTA in use, and are described here. Ensure Security of Postfix SSL Certificate Create the PKI directory for mail certificates, if it does not already exist: 
    $ sudo mkdir /etc/pki/tls/mail
$ sudo chown root:root /etc/pki/tls/mail
$ sudo chmod 755 /etc/pki/tls/mail
    Using removable media or some other secure transmission format, install the files generated in the previous step onto the mail server: 
    /etc/pki/tls/mail/serverkey.pem: the private key mailserverkey.pem
/etc/pki/tls/mail/servercert.pem: the certificate file mailservercert.pem
    Verify the ownership and permissions of these files: 
    $ sudo chown root:root /etc/pki/tls/mail/serverkey.pem
$ sudo chown root:root /etc/pki/tls/mail/servercert.pem
$ sudo chmod 600 /etc/pki/tls/mail/serverkey.pem
$ sudo chmod 644 /etc/pki/tls/mail/servercert.pem
    Verify that the CA's public certificate file has been installed as /etc/pki/tls/CA/cacert.pem, and has the correct permissions: 
    $ sudo chown root:root /etc/pki/tls/CA/cacert.pem
$ sudo chmod 644 /etc/pki/tls/CA/cacert.pem
         Configure Postfix if Necessary Postfix stores its configuration files in the directory /etc/postfix by default. The primary configuration file is /etc/postfix/main.cf. Configure SMTP Greeting Banner Edit /etc/postfix/main.cf, and add or correct the following line, substituting some other wording for the banner information if you prefer: 
    smtpd_banner = $myhostname ESMTP
     The default greeting banner discloses that the listening mail process is Postfix. When remote mail senders connect to the MTA on port 25, they are greeted by an initial banner as part of the SMTP dialogue. This banner is necessary, but it frequently gives away too much information, including the MTA software which is in use, and sometimes also its version number. Remote mail senders do not need this information in order to send mail, so the banner should be changed to reveal only the hostname (which is already known and may be useful) and the word ESMTP, to indicate that the modern SMTP protocol variant is supported.     Configure Postfix Resource Usage to Limit Denial of Service Attacks Edit /etc/postfix/main.cf. Edit the following lines to configure the amount of system resources Postfix can consume: 
    default_process_limit = 100
smtpd_client_connection_count_limit = 10
smtpd_client_connection_rate_limit = 30
queue_minfree = 20971520
header_size_limit = 51200
message_size_limit = 10485760
smtpd_recipient_limit = 100
    The values here are examples.     These configuration options serve to make it more difficult for attackers to consume resources on the MTA host. The default_process_limit parameter controls how many smtpd processes can exist at a time, while smtpd_client_connection_count_limit controls the number of those which can be occupied by any one remote sender, and smtpd_client_connection_rate_limit controls the number of connections any one client can make per minute. By default, local hosts (those in mynetworks) are exempted from per-client rate limiting. The queue_minfree parameter establishes a free space threshold, in order to stop e-mail receipt before the queue filesystem is entirely full. The header_size_limit, message_size_limit, and smtpd_recipient_limit parameters place bounds on the legal sizes of messages received via SMTP. Note: The values given here are examples, and may need to be modified for any particular site. By default, the Postfix anvil process gathers mail receipt statistics. To get information about about what connection rates are typical at your site, look in /var/log/maillog for lines with the daemon name postfix/anvil.     Control Mail Relaying Postfix's mail relay controls are implemented with the help of the smtpd recipient restrictions option, which controls the restrictions placed on the SMTP dialogue once the sender and recipient envelope addresses are known. The guidance in the following sections should be applied to all machines. If there are machines which must be allowed to relay mail, but which cannot be trusted to relay unconditionally, configure SMTP AUTH with SSL support. Configure Trusted Networks and Hosts Edit /etc/postfix/main.cf, and configure the contents of the mynetworks variable in one of the following ways:
    • If any machine in the subnet containing the MTA may be trusted to relay messages, add or correct the following line: 
      mynetworks_style = subnet
      This is also the default setting, and is in effect if all my_networks_style directives are commented.
    • If only the MTA host itself is trusted to relay messages, add or correct the following line: 
      mynetworks_style = host
    • If the set of machines which can relay is more complicated, manually specify an entry for each netblock or IP address which is trusted to relay by setting the mynetworks variable directly: 
      mynetworks = 10.0.0.0/16, 192.168.1.0/24, 127.0.0.1
     The mynetworks variable must contain only the set of machines for which this MTA should unconditionally relay mail. This is a trust relationship - if spammers gain access to these machines, your site will effectively become an open relay. It is recommended that only machines which are managed by you or by another trusted organization be placed in mynetworks, and users of all other machines be required to use SMTP AUTH to send mail.     Enact SMTP Relay Restrictions To configure Postfix to restrict addresses to which it will send mail, see: http://www.postfix.org/SMTPD_ACCESS_README.html#danger
    The full contents of smtpd_recipient_restrictions will vary by site, since this is a common place to put spam restrictions and other site-specific options. The permit_mynetworks option allows all mail to be relayed from the machines in mynetworks. Then, the reject_unauth_destination option denies all mail whose destination address is not local, preventing any other machines from relaying. These two options should always appear in this order, and should usually follow one another immediately unless SMTP AUTH is used.     Enact SMTP Recipient Restrictions To configure Postfix to restrict addresses to which it will send mail, see: http://www.postfix.org/SMTPD_ACCESS_README.html#danger
    The full contents of smtpd_recipient_restrictions will vary by site, since this is a common place to put spam restrictions and other site-specific options. The permit_mynetworks option allows all mail to be relayed from the machines in mynetworks. Then, the reject_unauth_destination option denies all mail whose destination address is not local, preventing any other machines from relaying. These two options should always appear in this order, and should usually follow one another immediately unless SMTP AUTH is used.     Require SMTP AUTH Before Relaying from Untrusted Clients SMTP authentication allows remote clients to relay mail safely by requiring them to authenticate before submitting mail. Postfix's SMTP AUTH uses an authentication library called SASL, which is not part of Postfix itself. To enable the use of SASL authentication, see http://www.postfix.org/SASL_README.html Use TLS for SMTP AUTH Postfix provides options to use TLS for certificate-based authentication and encrypted sessions. An encrypted session protects the information that is transmitted with SMTP mail or with SASL authentication. To configure Postfix to protect all SMTP AUTH transactions using TLS, see http://www.postfix.org/TLS_README.html.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/services/nfs.xml000066400000000000000000000533411301675746700240720ustar00rootroot00000000000000 NFS and RPC The Network File System is a popular distributed filesystem for the Unix environment, and is very widely deployed. This section discusses the circumstances under which it is possible to disable NFS and its dependencies, and then details steps which should be taken to secure NFS's configuration. This section is relevant to machines operating as NFS clients, as well as to those operating as NFS servers. Disable All NFS Services if Possible If there is not a reason for the system to operate as either an NFS client or an NFS server, follow all instructions in this section to disable subsystems required by NFS. The steps in this section will prevent a machine from operating as either an NFS client or an NFS server. Only perform these steps on machines which do not need NFS at all. Disable Services Used Only by NFS If NFS is not needed, disable the NFS client daemons nfslock, rpcgssd, and rpcidmapd.

    All of these daemons run with elevated privileges, and many listen for network connections. If they are not needed, they should be disabled to improve system security posture.     Disable Network File System Lock Service (nfslock) The Network File System Lock (nfslock) service starts the required remote procedure call (RPC) processes which allow clients to lock files on the server. If the local machine is not configured to mount NFS filesystems then this service should be disabled. Disable Secure RPC Client Service (rpcgssd) The rpcgssd service manages RPCSEC GSS contexts required to secure protocols that use RPC (most often Kerberos and NFS). The rpcgssd service is the client-side of RPCSEC GSS. If the system does not require secure RPC then this service should be disabled. Disable rpcbind Service The rpcbind utility maps RPC services to the ports on which they listen. RPC processes notify rpcbind when they start, registering the ports they are listening on and the RPC program numbers they expect to serve. The rpcbind service redirects the client to the proper port number so it can communicate with the requested service. If the system does not require RPC (such as for NFS servers) then this service should be disabled. Disable RPC ID Mapping Service (rpcidmapd) The rpcidmapd service is used to map user names and groups to UID and GID numbers on NFSv4 mounts. If NFS is not in use on the local system then this service should be disabled.     Configure All Machines which Use NFS The steps in this section are appropriate for all machines which run NFS, whether they operate as clients or as servers. Make Each Machine a Client or a Server, not Both If NFS must be used, it should be deployed in the simplest configuration possible to avoid maintainability problems which may lead to unnecessary security exposure. Due to the reliability and security problems caused by NFS (specially NFSv3 and NFSv2), it is not a good idea for machines which act as NFS servers to also mount filesystems via NFS. At the least, crossed mounts (the situation in which each of two servers mounts a filesystem from the other) should never be used. Configure NFS Services to Use Fixed Ports (NFSv3 and NFSv2) Firewalling should be done at each host and at the border firewalls to protect the NFS daemons from remote access, since NFS servers should never be accessible from outside the organization. However, by default for NFSv3 and NFSv2, the RPC Bind service assigns each NFS service to a port dynamically at service startup time. Dynamic ports cannot be protected by port filtering firewalls such as firewalld.

    Therefore, restrict each service to always use a given port, so that firewalling can be done effectively. Note that, because of the way RPC is implemented, it is not possible to disable the RPC Bind service even if ports are assigned statically to all RPC services.

    In NFSv4, the mounting and locking protocols have been incorporated into the protocol, and the server listens on the the well-known TCP port 2049. As such, NFSv4 does not need to interact with the rpcbind, lockd, and rpc.statd daemons, which can and should be disabled in a pure NFSv4 environment. The rpc.mountd daemon is still required on the NFS server to setup exports, but is not involved in any over-the-wire operations.     Configure <tt>lockd</tt> to use static TCP port Configure the lockd daemon to use a static TCP port as opposed to letting the RPC Bind service dynamically assign a port. Edit the file /etc/sysconfig/nfs. Add or correct the following line: 
    LOCKD_TCPPORT=lockd-port
    Where lockd-port is a port which is not used by any other service on your network.     Restrict service to always use a given port, so that firewalling can be done effectively.     Configure <tt>lockd</tt> to use static UDP port Configure the lockd daemon to use a static UDP port as opposed to letting the RPC Bind service dynamically assign a port. Edit the file /etc/sysconfig/nfs. Add or correct the following line: 
    LOCKD_UDPPORT=lockd-port
    Where lockd-port is a port which is not used by any other service on your network.     Restricting services to always use a given port enables firewalling to be done more effectively.     Configure <tt>statd</tt> to use static port Configure the statd daemon to use a static port as opposed to letting the RPC Bind service dynamically assign a port. Edit the file /etc/sysconfig/nfs. Add or correct the following line: 
    STATD_PORT=statd-port
    Where statd-port is a port which is not used by any other service on your network.     Restricting services to always use a given port enables firewalling to be done more effectively.     Configure <tt>mountd</tt> to use static port Configure the mountd daemon to use a static port as opposed to letting the RPC Bind service dynamically assign a port. Edit the file /etc/sysconfig/nfs. Add or correct the following line: 
    MOUNTD_PORT=statd-port
    Where mountd-port is a port which is not used by any other service on your network.     Restricting services to always use a given port enables firewalling to be done more effectively.     Configure NFS Clients The steps in this section are appropriate for machines which operate as NFS clients. Disable NFS Server Daemons There is no need to run the NFS server daemons nfs and rpcsvcgssd except on a small number of properly secured machines designated as NFS servers. Ensure that these daemons are turned off on clients. Specify UID and GID for Anonymous NFS Connections To specify the UID and GID for remote root users, edit the /etc/exports file and add the following for each export: 
    anonuid=value greater than UID_MAX from /etc/login.defs
anongid=value greater than GID_MAX from /etc/login.defs
    Alternatively, functionally equivalent values of 60001, 65534, 65535 may be used.     Inspect the mounts configured in /etc/exports. Each mount should specify a value greater than UID_MAX and GID_MAX as defined in /etc/login.defs. Specifying the anonymous UID and GID ensures that the remote root user is mapped to a local account which has no permissions on the system.     Disable Network File System (nfs) The Network File System (NFS) service allows remote hosts to mount and interact with shared filesystems on the local machine. If the local machine is not designated as a NFS server then this service should be disabled. It is prudent to ensure the nfs service is disabled in system boot, as well as not currently running. First, run the following to verify the service is stopped: 
    $ service nfs status
    If the service is stopped or disabled, it will return the following: 
    rpc.svcgssd is stopped
rpc.mountd is stopped
nfsd is stopped
rpc.rquotad is stopped
    To verify that the nfs service is disabled, run the following command: 
    $ chkconfig --list nfs
    If properly configured, the output should look like: 
    nfs            	0:off	1:off	2:off	3:off	4:off	5:off	6:off
     Unnecessary services should be disabled to decrease the attack surface of the system.     Disable Secure RPC Server Service (rpcsvcgssd) The rpcsvcgssd service manages RPCSEC GSS contexts required to secure protocols that use RPC (most often Kerberos and NFS). The rpcsvcgssd service is the server-side of RPCSEC GSS. If the system does not require secure RPC then this service should be disabled. Unnecessary services should be disabled to decrease the attack surface of the system.     Mount Remote Filesystems with Restrictive Options Edit the file /etc/fstab. For each filesystem whose type (column 3) is nfs or nfs4, add the text ,nodev,nosuid to the list of mount options in column 4. If appropriate, also add ,noexec.

    See the section titled "Restrict Partition Mount Options" for a description of the effects of these options. In general, execution of files mounted via NFS should be considered risky because of the possibility that an adversary could intercept the request and substitute a malicious file. Allowing setuid files to be executed from remote servers is particularly risky, both for this reason and because it requires the clients to extend root-level trust to the NFS server.     Mount Remote Filesystems with nodev To verify the nodev option is configured for all NFS mounts, run the following command: 
    $ mount | grep nfs
    All NFS mounts should show the nodev setting in parentheses. This is not applicable if NFS is not implemented.     Legitimate device files should only exist in the /dev directory. NFS mounts should not present device files to users.     Mount Remote Filesystems with nosuid To verify the nosuid option is configured for all NFS mounts, run the following command: 
    $ mount | grep nfs
    All NFS mounts should show the nosuid setting in parentheses. This is not applicable if NFS is not implemented.     NFS mounts should not present suid binaries to users. Only vendor-supplied suid executables should be installed to their default location on the local filesystem.     Mount Remote Filesystems with Kerberos Security To verify the sec option is configured for all NFS mounts, run the following command: 
    $ mount | grep "sec="
    All NFS mounts should show the sec=krb5:krb5i:krb5p setting in parentheses. This is not applicable if NFS is not implemented.     When an NFS server is configured to use AUTH_SYS a selected userid and groupid are used to handle requests from the remote user. The userid and groupid could mistakenly or maliciously be set incorrectly. The AUTH_GSS method of authentication uses certificates on the server and client systems to more securely authenticate the remote mount request.     Configure NFS Servers The steps in this section are appropriate for machines which operate as NFS servers. Configure the Exports File Restrictively Linux's NFS implementation uses the file /etc/exports to control what filesystems and directories may be accessed via NFS. (See the exports(5) manpage for more information about the format of this file.)

    The syntax of the exports file is not necessarily checked fully on reload, and syntax errors can leave your NFS configuration more open than intended. Therefore, exercise caution when modifying the file.

    The syntax of each line in /etc/exports is: 
    /DIR	host1(opt1,opt2) host2(opt3)
    where /DIR is a directory or filesystem to export, hostN is an IP address, netblock, hostname, domain, or netgroup to which to export, and optN is an option.     Use Access Lists to Enforce Authorization Restrictions When configuring NFS exports, ensure that each export line in /etc/exports contains a list of hosts which are allowed to access that export. If no hosts are specified on an export line, then that export is available to any remote host which requests it. All lines of the exports file should specify the hosts (or subnets, if needed) which are allowed to access the exported directory, so that unknown or remote hosts will be denied.

    Authorized hosts can be specified in several different formats:
    • Name or alias that is recognized by the resolver
    • Fully qualified domain name
    • IP address
    • IP subnets in the format address/netmask or address/CIDR
         Export Filesystems Read-Only if Possible If a filesystem is being exported so that users can view the files in a convenient fashion, but there is no need for users to edit those files, exporting the filesystem read-only removes an attack vector against the server. The default filesystem export mode is ro, so do not specify rw without a good reason. Use Root-Squashing on All Exports If a filesystem is exported using root squashing, requests from root on the client are considered to be unprivileged (mapped to a user such as nobody). This provides some mild protection against remote abuse of an NFS server. Root squashing is enabled by default, and should not be disabled.

    Ensure that no line in /etc/exports contains the option no_root_squash.     If the NFS server allows root access to local file systems from remote hosts, this access could be used to compromise the system.     Restrict NFS Clients to Privileged Ports By default, the server NFS implementation requires that all client requests be made from ports less than 1024. If your organization has control over machines connected to its network, and if NFS requests are prohibited at the border firewall, this offers some protection against malicious requests from unprivileged users. Therefore, the default should not be changed.

    To ensure that the default has not been changed, ensure no line in /etc/exports contains the option insecure.     Allowing client requests to be made from ports higher than 1024 could allow a unprivileged user to initiate an NFS connection. If the unprivileged user account has been compromised, an attacker could gain access to data on the NFS server.     Ensure Insecure File Locking is Not Allowed By default the NFS server requires secure file-lock requests, which require credentials from the client in order to lock a file. Most NFS clients send credentials with file lock requests, however, there are a few clients that do not send credentials when requesting a file-lock, allowing the client to only be able to lock world-readable files. To get around this, the insecure_locks option can be used so these clients can access the desired export. This poses a security risk by potentially allowing the client access to data for which it does not have authorization. Remove any instances of the insecure_locks option from the file /etc/exports. To verify insecure file locking has been disabled, run the following command: 
    $ grep insecure_locks /etc/exports
     Allowing insecure file locking could allow for sensitive data to be viewed or edited by an unauthorized user.     Use Kerberos Security on All Exports Using Kerberos on all exported mounts prevents a malicious client or user from impersonating a system user. To cryptography authenticate users to the NFS server, add sec=krb5:krb5i:krb5p to each export in /etc/exports. To verify the sec option is configured for all NFS mounts, run the following command: 
    $ grep "sec=" /etc/exports
    All configured NFS exports should show the sec=krb5:krb5i:krb5p setting in parentheses. This is not applicable if NFS is not implemented.     When an NFS server is configured to use AUTH_SYS a selected userid and groupid are used to handle requests from the remote user. The userid and groupid could mistakenly or maliciously be set incorrectly. The AUTH_GSS method of authentication uses certificates on the server and client systems to more securely authenticate the remote mount request.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/services/ntp.xml000066400000000000000000000225121301675746700241010ustar00rootroot00000000000000 Network Time Protocol The Network Time Protocol is used to manage the system clock over a network. Computer clocks are not very accurate, so time will drift unpredictably on unmanaged systems. Central time protocols can be used both to ensure that time is consistent among a network of machines, and that their time is consistent with the outside world.

    If every system on a network reliably reports the same time, then it is much easier to correlate log messages in case of an attack. In addition, a number of cryptographic protocols (such as Kerberos) use timestamps to prevent certain types of attacks. If your network does not have synchronized time, these protocols may be unreliable or even unusable.

    Depending on the specifics of the network, global time accuracy may be just as important as local synchronization, or not very important at all. If your network is connected to the Internet, using a public timeserver (or one provided by your enterprise) provides globally accurate timestamps which may be essential in investigating or responding to an attack which originated outside of your network.

    A typical network setup involves a small number of internal systems operating as NTP servers, and the remainder obtaining time information from those internal servers.

    There is a choice between the daemons ntpd and chronyd, which are available from the repositories in the ntp and chrony packages respectively.

    The default chronyd daemon can work well when external time references are only intermittently accesible, can perform well even when the network is congested for longer periods of time, can usually synchronize the clock faster and with better time accuracy, and quickly adapts to sudden changes in the rate of the clock, for example, due to changes in the temperature of the crystal oscillator. Chronyd should be considered for all systems which are frequently suspended or otherwise intermittently disconnected and reconnected to a network. Mobile and virtual systems for example.

    The ntpd NTP daemon fully supports NTP protocol version 4 (RFC 5905), including broadcast, multicast, manycast clients and servers, and the orphan mode. It also supports extra authentication schemes based on public-key cryptography (RFC 5906). The NTP daemon (ntpd) should be considered for systems which are normally kept permanently on. Systems which are required to use broadcast or multicast IP, or to perform authentication of packets with the Autokey protocol, should consider using ntpd.

    Refer to https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/ch-Configuring_NTP_Using_the_chrony_Suite.html for more detailed comparison of features of chronyd and ntpd daemon features respectively, and for further guidance how to choose between the two NTP daemons.

    The upstream manual pages at http://chrony.tuxfamily.org/manual.html for chronyd and http://www.ntp.org for ntpd provide additional information on the capabilities and configuration of each of the NTP daemons.     Vendor Approved Time Servers The list of vendor-approved time servers 0.rhel.pool.ntp.org,1.rhel.pool.ntp.org,2.rhel.pool.ntp.org,3.rhel.pool.ntp.org 0.fedora.pool.ntp.org,1.fedora.pool.ntp.org,2.fedora.pool.ntp.org,3.fedora.pool.ntp.org Enable the NTP Daemon Note: The chronyd daemon is enabled by default.

    Note: The ntpd daemon is not enabled by default. Though as mentioned in the previous sections in certain environments the ntpd daemon might be preferred to be used rather than the chronyd one. Refer to: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/ch-Configuring_NTP_Using_the_chrony_Suite.html for guidance which NTP daemon to choose depending on the environment used.     Enabling some of chronyd or ntpd services ensures that the NTP daemon will be running and that the system will synchronize its time to any servers specified. This is important whether the system is configured to be a client (and synchronize only its own clock) or it is also acting as an NTP server to other systems. Synchronizing time is essential for authentication services such as Kerberos, but it is also important for maintaining accurate logs and auditing possible security breaches.

    The chronyd and ntpd NTP daemons offer all of the functionality of ntpdate, which is now deprecated. Additional information on this is available at http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate         Specify a Remote NTP Server Depending on specific functional requirements of a concrete production environment, the Red Hat Enterprise Linux 7 Server system can be configured to utilize the services of the chronyd NTP daemon (the default), or services of the ntpd NTP daemon. Refer to https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/ch-Configuring_NTP_Using_the_chrony_Suite.html for more detailed comparison of the features of both of the choices, and for further guidance how to choose between the two NTP daemons.
    To specify a remote NTP server for time synchronization, perform the following:
    • if the system is configured to use the chronyd as the NTP daemon (the default), edit the file /etc/chrony.conf as follows,
    • if the system is configured to use the ntpd as the NTP daemon, edit the file /etc/ntp.conf as documented below.
    Add or correct the following lines, substituting the IP or hostname of a remote NTP server for ntpserver: 
    server ntpserver
    This instructs the NTP software to contact that remote server to obtain time data.     To verify that a remote NTP service is configured for time synchronization, open the following file: 
    • /etc/chrony.conf
      in the case the system in question is configured to use the chronyd as the NTP daemon (default setting)
    • /etc/ntp.conf
      in the case the system in question is configured to use the ntpd as the NTP daemon
    In the file, there should be a section similar to the following: 
    server ntpserver
     Synchronizing with an NTP server makes it possible to collate system logs from multiple sources or correlate computer events with real time events.     Specify Additional Remote NTP Servers Depending on specific functional requirements of a concrete production environment, the Red Hat Enterprise Linux 7 Server system can be configured to utilize the services of the chronyd NTP daemon (the default), or services of the ntpd NTP daemon. Refer to https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/ch-Configuring_NTP_Using_the_chrony_Suite.html for more detailed comparison of the features of both of the choices, and for further guidance how to choose between the two NTP daemons.
    Additional NTP servers can be specified for time synchronization. To do so, perform the following:
    • if the system is configured to use the chronyd as the NTP daemon (the default), edit the file /etc/chrony.conf as follows,
    • if the system is configured to use the ntpd as the NTP daemon, edit the file /etc/ntp.conf as documented below.
    Add additional lines of the following form, substituting the IP address or hostname of a remote NTP server for ntpserver: 
    server ntpserver
     Specifying additional NTP servers increases the availability of accurate time data, in the event that one of the specified servers becomes unavailable. This is typical for a system acting as an NTP server for other systems.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/services/obsolete.xml000066400000000000000000000517241301675746700251230ustar00rootroot00000000000000 Obsolete Services This section discusses a number of network-visible services which have historically caused problems for system security, and for which disabling or severely limiting the service has been the best available guidance for some time. As a result of this, many of these services are not installed as part of Red Hat Enterprise Linux 7 by default.

    Organizations which are running these services should switch to more secure equivalents as soon as possible. If it remains absolutely necessary to run one of these services for legacy reasons, care should be taken to restrict the service as much as possible, for instance by configuring host firewall software such as firewalld to restrict access to the vulnerable service to only those remote hosts which have a known need to use it.     Xinetd The xinetd service acts as a dedicated listener for some network services (mostly, obsolete ones) and can be used to provide access controls and perform some logging. It has been largely obsoleted by other features, and it is not installed by default. The older Inetd service is not even available as part of Red Hat Enterprise Linux 7. Disable xinetd Service If network services are using the xinetd service, this is not applicable.

    The xinetd service provides a dedicated listener service for some programs, which is no longer necessary for commonly-used network services. Disabling it ensures that these uncommon services are not running, and also prevents attacks against xinetd itself.     Uninstall xinetd Package The xinetd package can be uninstalled with the following command: 
    $ sudo yum erase xinetd
     If network services are using the xinetd service, this is not applicable.

    Removing the xinetd package decreases the risk of the xinetd service's accidental (or intentional) activation.     Install tcp_wrappers Package When network services are using the xinetd service, the tcp_wrappers package should be installed. Access control methods provide the ability to enhance system security posture by restricting services and known good IP addresses and address ranges. This prevents connections from unknown hosts and protocols.     Telnet The telnet protocol does not provide confidentiality or integrity for information transmitted on the network. This includes authentication information such as passwords. Organizations which use telnet should be actively working to migrate to a more secure protocol. Disable telnet Service The telnet service configuration file /etc/xinetd.d/telnet is not created automatically. If it was created manually, check the /etc/xinetd.d/telnet file and ensure that disable = no is changed to read disable = yes as follows below: 
    # description: The telnet server serves telnet sessions; it uses \\
#       unencrypted username/password pairs for authentication.
service telnet
{
        flags           = REUSE
        socket_type     = stream

        wait            = no
        user            = root
        server          = /usr/sbin/in.telnetd
        log_on_failure  += USERID
        disable         = yes
}
    If the /etc/xinetd.d/telnet file does not exist, make sure that the activation of the telnet service on system boot is disabled via the following command:     The telnet protocol uses unencrypted network communication, which means that data from the login session, including passwords and all other information transmitted during the session, can be stolen by eavesdroppers on the network. The telnet protocol is also subject to man-in-the-middle attacks.     Uninstall telnet-server Package The telnet-server package can be uninstalled with the following command: 
    $ sudo yum erase telnet-server
     It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities are often overlooked and therefore may remain unsecure. They increase the risk to the platform by providing additional attack vectors.
    The telnet service provides an unencrypted remote access service which does not provide for the confidentiality and integrity of user passwords or the remote session. If a privileged user were to login using this service, the privileged user password could be compromised.
    Removing the telnet-server package decreases the risk of the telnet service's accidental (or intentional) activation.     Remove telnet Clients The telnet client allows users to start connections to other systems via the telnet protocol. The telnet protocol is insecure and unencrypted. The use of an unencrypted transmission medium could allow an unauthorized user to steal credentials. The ssh package provides an encrypted session and stronger security and is included in Red Hat Enterprise Linux.     Rlogin, Rsh, and Rexec The Berkeley r-commands are legacy services which allow cleartext remote access and have an insecure trust model. Uninstall rsh-server Package The rsh-server package can be uninstalled with the following command: 
    $ sudo yum erase rsh-server
     The rsh-server service provides unencrypted remote access service which does not provide for the confidentiality and integrity of user passwords or the remote session and has very weak authentication. If a privileged user were to login using this service, the privileged user password could be compromised. The rsh-server package provides several obsolete and insecure network services. Removing it decreases the risk of those services' accidental (or intentional) activation.     Disable rexec Service The rexec service, which is available with the rsh-server package and runs as a service through xinetd or separately as a systemd socket, should be disabled. If using xinetd, set disable to yes in /etc/xinetd.d/rexec. If using systemd, The rexec service uses unencrypted network communications, which means that data from the login session, including passwords and all other information transmitted during the session, can be stolen by eavesdroppers on the network. Disable rsh Service The rsh service, which is available with the rsh-server package and runs as a service through xinetd or separately as a systemd socket, should be disabled. If using xinetd, set disable to yes in /etc/xinetd.d/rsh. If using systemd, The rsh service uses unencrypted network communications, which means that data from the login session, including passwords and all other information transmitted during the session, can be stolen by eavesdroppers on the network. Uninstall rsh Package The rsh package contains the client commands for the rsh services These legacy clients contain numerous security exposures and have been replaced with the more secure SSH package. Even if the server is removed, it is best to ensure the clients are also removed to prevent users from inadvertently attempting to use these commands and therefore exposing their credentials. Note that removing the rsh package removes the clients for rsh,rcp, and rlogin. Disable rlogin Service The rlogin service, which is available with the rsh-server package and runs as a service through xinetd or separately as a systemd socket, should be disabled. If using xinetd, set disable to yes in /etc/xinetd.d/rlogin. If using systemd, The rlogin service uses unencrypted network communications, which means that data from the login session, including passwords and all other information transmitted during the session, can be stolen by eavesdroppers on the network. Remove Rsh Trust Files The files /etc/hosts.equiv and ~/.rhosts (in each user's home directory) list remote hosts and users that are trusted by the local system when using the rshd daemon. To remove these files, run the following command to delete them from any location: 
    $ sudo rm /etc/hosts.equiv
    $ rm ~/.rhosts
     The existence of the file /etc/hosts.equiv or a file named .rhosts inside a user home directory indicates the presence of an Rsh trust relationship. Trust files are convenient, but when used in conjunction with the R-services, they can allow unauthenticated access to a system.     NIS The Network Information Service (NIS), also known as 'Yellow Pages' (YP), and its successor NIS+ have been made obsolete by Kerberos, LDAP, and other modern centralized authentication services. NIS should not be used because it suffers from security problems inherent in its design, such as inadequate protection of important authentication information. Uninstall ypserv Package The ypserv package can be uninstalled with the following command: 
    $ sudo yum erase ypserv
     The NIS service provides an unencrypted authentication service which does not provide for the confidentiality and integrity of user passwords or the remote session. Removing the ypserv package decreases the risk of the accidental (or intentional) activation of NIS or NIS+ services.     Disable ypbind Service The ypbind service, which allows the system to act as a client in a NIS or NIS+ domain, should be disabled. Disabling the ypbind service ensures the system is not acting as a client in a NIS or NIS+ domain. Remove NIS Client The Network Information Service (NIS), formerly known as Yellow Pages, is a client-server directory service protocol used to distribute system configuration files. The NIS client (ypbind) was used to bind a machine to an NIS server and receive the distributed configuration files. The NIS service is inherently an insecure system that has been vulnerable to DOS attacks, buffer overflows and has poor authentication for querying NIS maps. NIS generally has been replaced by such protocols as Lightweight Directory Access Protocol (LDAP). It is recommended that the service be removed.     TFTP Server TFTP is a lightweight version of the FTP protocol which has traditionally been used to configure networking equipment. However, TFTP provides little security, and modern versions of networking operating systems frequently support configuration via SSH or other more secure protocols. A TFTP server should be run only if no more secure method of supporting existing equipment can be found. Disable tftp Service The tftp service should be disabled. Disabling the tftp service ensures the system is not acting as a TFTP server, which does not provide encryption or authentication. Uninstall tftp-server Package Removing the tftp-server package decreases the risk of the accidental (or intentional) activation of tftp services.

    If TFTP is required for operational support (such as transmission of router configurations), its use must be documented with the Information Systems Securty Manager (ISSM), restricted to only authorized personnel, and have access control rules established.     Remove tftp Daemon Trivial File Transfer Protocol (TFTP) is a simple file transfer protocol, typically used to automatically transfer configuration or boot files between machines. TFTP does not support authentication and can be easily hacked. The package tftp is a client program that allows for connections to a tftp server. It is recommended that TFTP be removed, unless there is a specific need for TFTP (such as a boot server). In that case, use extreme caution when configuring the services. Ensure <tt>tftp</tt> Daemon Uses Secure Mode If running the tftp service is necessary, it should be configured to change its root directory at startup. To do so, ensure /etc/xinetd.d/tftp includes -s as a command line argument, as shown in the following example (which is also the default): 
    server_args = -s /var/lib/tftpboot
     Using the -s option causes the TFTP service to only serve files from the given directory. Serving files from an intentionally-specified directory reduces the risk of sharing files which should remain private. If TFTP is not installed, this is not applicable. To determine if TFTP is installed, run the following command: 
    $ rpm -qa | grep tftp


    Verify tftp is configured by with the -s option by running the following command: 
    grep "server_args" /etc/xinetd.d/tftp
    The output should indicate the server_args variable is configured with the -s flag, matching the example below: 
    $ grep "server_args" /etc/xinetd.d/tftp
server_args = -s /var/lib/tftpboot
         Chat/Messaging Services The talk software makes it possible for users to send and receive messages across systems through a terminal session. Uninstall talk-server Package The talk software presents a security risk as it uses unencrypted protocols for communications. Removing the talk-server package decreases the risk of the accidental (or intentional) activation of talk services. Uninstall talk Package The talk package contains the client program for the Internet talk protocol, which allows the user to chat with other users on different systems. Talk is a communication program which copies lines from one terminal to the terminal of another user. The talk software presents a security risk as it uses unencrypted protocols for communications. Removing the talk package decreases the risk of the accidental (or intentional) activation of talk client program.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/services/printing.xml000066400000000000000000000070261301675746700251350ustar00rootroot00000000000000 Print Support The Common Unix Printing System (CUPS) service provides both local and network printing support. A system running the CUPS service can accept print jobs from other systems, process them, and send them to the appropriate printer. It also provides an interface for remote administration through a web browser. The CUPS service is installed and activated by default. The project homepage and more detailed documentation are available at http://www.cups.org.

    Disable the CUPS Service Turn off unneeded services to reduce attack surface. Configure the CUPS Service if Necessary CUPS provides the ability to easily share local printers with other machines over the network. It does this by allowing machines to share lists of available printers. Additionally, each machine that runs the CUPS service can potentially act as a print server. Whenever possible, the printer sharing and print server capabilities of CUPS should be limited or disabled. The following recommendations should demonstrate how to do just that. Disable Printer Browsing Entirely if Possible By default, CUPS listens on the network for printer list broadcasts on UDP port 631. This functionality is called printer browsing. To disable printer browsing entirely, edit the CUPS configuration file, located at /etc/cups/cupsd.conf, to include the following: 
    Browsing Off
     The CUPS print service can be configured to broadcast a list of available printers to the network. Other machines on the network, also running the CUPS print service, can be configured to listen to these broadcasts and add and configure these printers for immediate use. By disabling this browsing capability, the machine will no longer generate or receive such broadcasts.     Disable Print Server Capabilities To prevent remote users from potentially connecting to and using locally configured printers, disable the CUPS print server sharing capabilities. To do so, limit how the server will listen for print jobs by removing the more generic port directive from /etc/cups/cupsd.conf: 
    Port 631
    and replacing it with the Listen directive: 
    Listen localhost:631
    This will prevent remote users from printing to locally configured printers while still allowing local users on the machine to print normally.     By default, locally configured printers will not be shared over the network, but if this functionality has somehow been enabled, these recommendations will disable it again. Be sure to disable outgoing printer list broadcasts, or remote users will still be able to see the locally configured printers, even if they cannot actually print to them. To limit print serving to a particular set of users, use the Policy directive.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/services/quagga.xml000066400000000000000000000042361301675746700245500ustar00rootroot00000000000000 Network Routing A router is a very desirable target for a potential adversary because they fulfill a variety of infrastructure networking roles such as access to network segments, gateways to other networks, filtering, etc. Therefore, if one is required, the machine acting as a router should be dedicated to that purpose alone and be stored in a physically secure location. The system's default routing software is Quagga, and provided in an RPM package of the same name. Disable Quagga if Possible If Quagga was installed and activated, but the system does not need to act as a router, then it should be disabled and removed. Disable Quagga Service Routing protocol daemons are typically used on routers to exchange network topology information with other routers. If routing daemons are used when not required, system network information may be unnecessarily transmitted across the network. Uninstall quagga Package Routing software is typically used on routers to exchange network topology information with other routers. If routing software is used when not required, system network information may be unnecessarily transmitted across the network.
    If there is no need to make the router software available, removing it provides a safeguard against its activation.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/services/smb.xml000066400000000000000000000200021301675746700240510ustar00rootroot00000000000000 Samba(SMB) Microsoft Windows File Sharing Server When properly configured, the Samba service allows Linux machines to provide file and print sharing to Microsoft Windows machines. There are two software packages that provide Samba support. The first, samba-client, provides a series of command line tools that enable a client machine to access Samba shares. The second, simply labeled samba, provides the Samba service. It is this second package that allows a Linux machine to act as an Active Directory server, a domain controller, or as a domain member. Only the samba-client package is installed by default. Disable Samba if Possible Even after the Samba server package has been installed, it will remain disabled. Do not enable this service unless it is absolutely necessary to provide Microsoft Windows file and print sharing functionality. Disable Samba Running a Samba server provides a network-based avenue of attack, and should be disabled if not needed. Uninstall Samba Package The samba package can be uninstalled with the following command: 
    $ sudo yum erase samba
     If there is no need to make the Samba software available, removing it provides a safeguard against its activation.     Configure Samba if Necessary All settings for the Samba daemon can be found in /etc/samba/smb.conf. Settings are divided between a [global] configuration section and a series of user created share definition sections meant to describe file or print shares on the system. By default, Samba will operate in user mode and allow client machines to access local home directories and printers. It is recommended that these settings be changed or that additional limitations be set in place. Restrict SMB File Sharing to Configured Networks Only users with local user accounts will be able to log in to Samba shares by default. Shares can be limited to particular users or network addresses. Use the hosts allow and hosts deny directives accordingly, and consider setting the valid users directive to a limited subset of users or to a group of users. Separate each address, user, or user group with a space as follows for a particular share or global: 
    [share]
  hosts allow = 192.168.1. 127.0.0.1
  valid users = userone usertwo @usergroup
    It is also possible to limit read and write access to particular users with the read list and write list options, though the permissions set by the system itself will override these settings. Set the read only attribute for each share to ensure that global settings will not accidentally override the individual share settings. Then, as with the valid users directive, separate each user or group of users with a space: 
    [share]
  read only = yes
  write list = userone usertwo @usergroup
     The Samba service is only required for sharing files and printers with Microsoft Windows workstations, and even then, other options may exist.     Disable Root Access to SMB Shares Administrators should not use administrator accounts to access Samba file and printer shares. Disable the root user and the wheel administrator group: 
    [share]
  invalid users = root @wheel
    If administrator accounts cannot be disabled, ensure that local machine passwords and Samba service passwords do not match.     Typically, administrator access is required when Samba must create user and machine accounts and shares. Domain member servers and standalone servers may not need administrator access at all. If that is the case, add the invalid users parameter to [global] instead.     Require Client SMB Packet Signing, if using <tt>smbclient</tt> To require samba clients running smbclient to use packet signing, add the following to the [global] section of the Samba configuration file, /etc/samba/smb.conf: 
    client signing = mandatory
    Requiring samba clients such as smbclient to use packet signing ensures they can only communicate with servers that support packet signing.     To verify that Samba clients running smbclient must use packet signing, run the following command: 
    $ grep signing /etc/samba/smb.conf
    The output should show: 
    client signing = mandatory
     Packet signing can prevent man-in-the-middle attacks which modify SMB packets in transit.     Require Client SMB Packet Signing, if using mount.cifs Require packet signing of clients who mount Samba shares using the mount.cifs program (e.g., those who specify shares in /etc/fstab). To do so, ensure signing options (either sec=krb5i or sec=ntlmv2i) are used.

    See the mount.cifs(8) man page for more information. A Samba client should only communicate with servers who can support SMB packet signing.     To verify that Samba clients using mount.cifs must use packet signing, run the following command: 
    $ grep sec /etc/fstab
    The output should show either krb5i or ntlmv2i in use.     Packet signing can prevent man-in-the-middle attacks which modify SMB packets in transit.     Restrict Printer Sharing By default, Samba utilizes the CUPS printing service to enable printer sharing with Microsoft Windows workstations. If there are no printers on the local machine, or if printer sharing with Microsoft Windows is not required, disable the printer sharing capability by commenting out the following lines, found in /etc/samba/smb.conf: 
    [global]
  load printers = yes
  cups options = raw
[printers]
  comment = All Printers
  path = /usr/spool/samba
  browseable = no
  guest ok = no
  writable = no
  printable = yes
    There may be other options present, but these are the only options enabled and uncommented by default. Removing the [printers] share should be enough for most users. If the Samba printer sharing capability is needed, consider disabling the Samba network browsing capability or restricting access to a particular set of users or network addresses. Set the valid users parameter to a small subset of users or restrict it to a particular group of users with the shorthand @. Separate each user or group of users with a space. For example, under the [printers] share: 
    [printers]
  valid users = user @printerusers
     The Samba service is only required for sharing files and printers with Microsoft Windows workstations, and even then, other options may exist. Do not use the Samba service to share files between Unix or Linux machines.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/services/snmp.xml000066400000000000000000000116371301675746700242630ustar00rootroot00000000000000 SNMP Server The Simple Network Management Protocol allows administrators to monitor the state of network devices, including computers. Older versions of SNMP were well-known for weak security, such as plaintext transmission of the community string (used for authentication) and usage of easily-guessable choices for the community string. Disable SNMP Server if Possible The system includes an SNMP daemon that allows for its remote monitoring, though it not installed by default. If it was installed and activated but is not needed, the software should be disabled and removed. Disable <tt>snmpd</tt> Service Running SNMP software provides a network-based avenue of attack, and should be disabled if not needed. Uninstall <tt>net-snmp</tt> Package The net-snmp package provides the snmpd service. If there is no need to run SNMP server software, removing the package provides a safeguard against its activation. Configure SNMP Server if Necessary If it is necessary to run the snmpd agent on the system, some best practices should be followed to minimize the security risk from the installation. The multiple security models implemented by SNMP cannot be fully covered here so only the following general configuration advice can be offered:
    • use only SNMP version 3 security models and enable the use of authentication and encryption
    • write access to the MIB (Management Information Base) should be allowed only if necessary
    • all access to the MIB should be restricted following a principle of least privilege
    • network access should be limited to the maximum extent possible including restricting to expected network addresses both in the configuration files and in the system firewall rules
    • ensure SNMP agents send traps only to, and accept SNMP queries only from, authorized management stations
    • ensure that permissions on the snmpd.conf configuration file (by default, in /etc/snmp) are 640 or more restrictive
    • ensure that any MIB files' permissions are also 640 or more restrictive
     Configure SNMP Service to Use Only SNMPv3 or Newer Edit /etc/snmp/snmpd.conf, removing any references to rocommunity, rwcommunity, or com2sec. Upon doing that, restart the SNMP service: 
    $ sudo service snmpd restart
     To ensure only SNMPv3 or newer is used, run the following command: 
    $ sudo grep 'rocommunity\|rwcommunity\|com2sec' /etc/snmp/snmpd.conf | grep -v "^#"
    There should be no output.     Earlier versions of SNMP are considered insecure, as they potentially allow unauthorized access to detailed system management information.     Ensure Default SNMP Password Is Not Used Edit /etc/snmp/snmpd.conf, remove or change the default community strings of public and private. Once the default community strings have been changed, restart the SNMP service: 
    $ sudo service snmpd restart
     To ensure the default password is not set, run the following command: 
    $ sudo grep -v "^#" /etc/snmp/snmpd.conf| grep -E 'public|private'
    There should be no output.     Whether active or not, default simple network management protocol (SNMP) community strings must be changed to maintain security. If the service is running with the default authenticators, then anyone can gather data about the system and the network and use the information to potentially compromise the integrity of the system and network(s).     scap-security-guide-0.1.31/SUSE/12/input/xccdf/services/squid.xml000066400000000000000000000031001301675746700244150ustar00rootroot00000000000000 Proxy Server A proxy server is a very desirable target for a potential adversary because much (or all) sensitive data for a given infrastructure may flow through it. Therefore, if one is required, the machine acting as a proxy server should be dedicated to that purpose alone and be stored in a physically secure location. The system's default proxy server software is Squid, and provided in an RPM package of the same name. Disable Squid if Possible If Squid was installed and activated, but the system does not need to act as a proxy server, then it should be disabled and removed. Disable Squid Running proxy server software provides a network-based avenue of attack, and should be removed if not needed. Uninstall squid Package If there is no need to make the proxy server software available, removing it provides a safeguard against its activation. scap-security-guide-0.1.31/SUSE/12/input/xccdf/services/ssh.xml000066400000000000000000000665751301675746700241160ustar00rootroot00000000000000 SSH Server The SSH protocol is recommended for remote login and remote file transfer. SSH provides confidentiality and integrity for data exchanged between two systems, as well as server authentication, through the use of public key cryptography. The implementation included with the system is called OpenSSH, and more detailed documentation is available from its website, http://www.openssh.org. Its server program is called sshd and provided by the RPM package openssh-server. SSH session Idle time Specify duration of allowed idle time. 300 300 600 900 3600 7200 Install the OpenSSH Server Package The openssh-server package should be installed. Without protection of the transmitted information, confidentiality, and integrity may be compromised because unprotected communications can be intercepted and either read or altered. Enable the OpenSSH Service The SSH server service, sshd, is commonly needed. Without protection of the transmitted information, confidentiality, and integrity may be compromised because unprotected communications can be intercepted and either read or altered.

    This checklist item applies to both internal and external networks and all types of information system components from which information can be transmitted (e.g., servers, mobile devices, notebook computers, printers, copiers, scanners, etc). Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification.     Disable SSH Server If Possible (Unusual) The SSH server service, sshd, is commonly needed. However, if it can be disabled, do so. This is unusual, as SSH is a common method for encrypted and authenticated remote access. Verify Permissions on SSH Server Public <tt>*.pub</tt> Key Files If a public host key file is modified by an unauthorized user, the SSH service may be compromised. Verify Permissions on SSH Server Private <tt>*_key</tt> Key Files If an unauthorized user obtains the private SSH host key file, the host could be impersonated. Remove SSH Server <tt>firewalld</tt> Firewall exception (Unusual) By default, inbound connections to SSH's port are allowed. If the SSH server is not being used, this exception should be removed from the firewall configuration.

    If inbound SSH connections are not expected, disallowing access to the SSH port will avoid possible exploitation of the port by an attacker.     Configure OpenSSH Server if Necessary If the system needs to act as an SSH server, then certain changes should be made to the OpenSSH daemon configuration file /etc/ssh/sshd_config. The following recommendations can be applied to this file. See the sshd_config(5) man page for more detailed information. Allow Only SSH Protocol 2 Only SSH protocol version 2 connections should be permitted. The default setting in /etc/ssh/sshd_config is correct, and can be verified by ensuring that the following line appears: 
    Protocol 2
     To check which SSH protocol version is allowed, run the following command: 
    $ sudo grep Protocol /etc/ssh/sshd_config
    If configured properly, output should be 
    Protocol 2
     SSH protocol version 1 is an insecure implementation of the SSH protocol and has many well-known vulnerability exploits. Exploits of the SSH daemon could provide immediate root access to the system.     Limit Users' SSH Access By default, the SSH configuration allows any user with an account to access the system. In order to specify the users that are allowed to login via SSH and deny all other users, add or correct the following line in the /etc/ssh/sshd_config file: 
    DenyUsers USER1 USER2
    Where USER1 and USER2 are valid user names.     Specifying which accounts are allowed SSH access into the system reduces the possibility of unauthorized access to the system.     Disable GSSAPI Authentication Unless needed, SSH should not permit extraneous or unnecessary authentication mechanisms like GSSAPI. To disable GSSAPI authentication, add or correct the following line in the /etc/ssh/sshd_config file: 
    GSSAPIAuthentication no
     To check if GSSAPIAuthentication is disabled or set correctly, run the following command: 
    $ sudo grep GSSAPIAuthentication /etc/ssh/sshd_config
    If configured properly, output should be 
    no
     GSSAPI authentication is used to provide additional authentication mechanisms to applications. Allowing GSSAPI authentication through SSH exposes the system's GSSAPI to remote hosts, increasing the attack surface of the system.     Disable Kerberos Authentication Unless needed, SSH should not permit extraneous or unnecessary authentication mechanisms like Kerberos. To disable Kerberos authentication, add or correct the following line in the /etc/ssh/sshd_config file: 
    KerberosAuthentication no
     To check if KerberosAuthentication is disabled or set correctly, run the following command: 
    $ sudo grep KerberosAuthentication /etc/ssh/sshd_config
    If configured properly, output should be 
    no
     Kerberos authentication for SSH is often implemented using GSSAPI. If Kerberos is enabled through SSH, the SSH daemon provides a means of access to the system's Kerberos implementation. Vulnerabilities in the system's Kerberos implementations may be subject to exploitation.     Enable Use of Strict Mode Checking SSHs StrictModes option checks file and ownership permissions in the user's home directory .ssh folder before accepting login. If world- writable permissions are found, logon is rejected. To enable StrictModes in SSH, add or correct the following line in the /etc/ssh/sshd_config file: 
    StrictModes yes
     To check if StrictModes is enabled or set correctly, run the following command: 
    $ sudo grep StrictModes /etc/ssh/sshd_config
    If configured properly, output should be 
    yes
     If other users have access to modify user-specific SSH configuration files, they may be able to log into the system as another user.     Enable Use of Privilege Separation When enabled, SSH will create an unprivileged child process that has the privilege of the authenticated user. To enable privilege separation in SSH, add or correct the following line in the /etc/ssh/sshd_config file: 
    UsePrivilegeSeparation yes
     To check if UsePrivilegeSeparation is enabled or set correctly, run the following command: 
    $ sudo grep UsePrivilegeSeparation /etc/ssh/sshd_config
    If configured properly, output should be 
    yes
     SSH daemon privilege separation causes the SSH process to drop root privileges when not needed which would decrease the impact of software vulnerabilities in the unprivileged section.     Disable Compression Or Set Compression to <tt>delayed</tt> Compression is useful for slow network connections over long distances but can cause performance issues on local LANs. If use of compression is required, it should be enabled only after a user has authenticated; otherwise , it should be disabled. To disable compression or delay compression until after a user has successfully authenticated, add or correct the following line in the /etc/ssh/sshd_config file: 
    Compression no
    or 
    Compression delayed
     To check if compression is enabled or set correctly, run the following command: 
    $ sudo grep Compression /etc/ssh/sshd_config
    If configured properly, output should be 
    no
    or 
    delayed
    .     If compression is allowed in an SSH connection prior to authentication, vulnerabilities in the compression software could result in compromise of the system from an unauthenticated connection, potentially wih root privileges.     Print Last Log When enabled, SSH will display the date and time of the last successful account logon. To enable LastLog in SSH, add or correct the following line in the /etc/ssh/sshd_config file: 
    PrintLastLog yes
     To check if PrintLastLog is enabled or set correctly, run the following command: 
    $ sudo grep PrintLastLog /etc/ssh/sshd_config
    If configured properly, output should be 
    yes
     Providing users feedback on when account accesses last occurred facilitates user recognition and reporting of unauthorized account use.     Set SSH Idle Timeout Interval SSH allows administrators to set an idle timeout interval. After this interval has passed, the idle user will be automatically logged out.

    To set an idle timeout interval, edit the following line in /etc/ssh/sshd_config as follows: 
    ClientAliveInterval interval
    The timeout interval is given in seconds. To have a timeout of 10 minutes, set interval to 600.

    If a shorter timeout has already been set for the login shell, that value will preempt any SSH setting made here. Keep in mind that some processes may stop SSH from correctly detecting that the user is idle.     Run the following command to see what the timeout interval is: 
    $ sudo grep ClientAliveInterval /etc/ssh/sshd_config
    If properly configured, the output should be: 
    ClientAliveInterval 600
     Terminating an idle ssh session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been let unattended.     Set SSH Client Alive Count To ensure the SSH idle timeout occurs precisely when the ClientAliveCountMax is set, edit /etc/ssh/sshd_config as follows: 
    ClientAliveCountMax 0
     To ensure the SSH idle timeout will occur when the ClientAliveCountMax is set, run the following command: 
    $ sudo grep ClientAliveCountMax /etc/ssh/sshd_config
    If properly configured, output should be: 
    ClientAliveCountMax 0
     This ensures a user login will be terminated as soon as the ClientAliveCountMax is reached.     Disable SSH Support for .rhosts Files SSH can emulate the behavior of the obsolete rsh command in allowing users to enable insecure access to their accounts via .rhosts files.

    To ensure this behavior is disabled, add or correct the following line in /etc/ssh/sshd_config: 
    IgnoreRhosts yes
     SSH trust relationships mean a compromise on one host can allow an attacker to move trivially to other hosts.     Disable Host-Based Authentication SSH's cryptographic host-based authentication is more secure than .rhosts authentication. However, it is not recommended that hosts unilaterally trust one another, even within an organization.

    To disable host-based authentication, add or correct the following line in /etc/ssh/sshd_config: 
    HostbasedAuthentication no
     SSH trust relationships mean a compromise on one host can allow an attacker to move trivially to other hosts.     Enable Encrypted X11 Fordwarding By default, remote X11 connections are not encrypted when initiated by users. SSH has the capability to encrypt remote X11 connections when SSH's X11Forwarding option is enabled.

    To enable X11 Forwarding, add or correct the following line in /etc/ssh/sshd_config: 
    X11Forwarding yes
     Open X displays allow an attacker to capture keystrokes and to execute commands remotely.     Disable SSH Root Login The root user should never be allowed to login to a system directly over a network. To disable root login via SSH, add or correct the following line in /etc/ssh/sshd_config: 
    PermitRootLogin no
     Even though the communications channel may be encrypted, an additional layer of security is gained by extending the policy of not logging directly on as root. In addition, logging in with a user-specific account provides individual accountability of actions performed on the system and also helps to minimize direct attack attempts on root's password.     Disable SSH Access via Empty Passwords To explicitly disallow SSH login from accounts with empty passwords, add or correct the following line in /etc/ssh/sshd_config: 
    PermitEmptyPasswords no

    Any accounts with empty passwords should be disabled immediately, and PAM configuration should prevent users from being able to assign themselves empty passwords.     Configuring this setting for the SSH daemon provides additional assurance that remote login via SSH will require a password, even in the event of misconfiguration elsewhere.     Enable SSH Warning Banner To enable the warning banner and ensure it is consistent across the system, add or correct the following line in /etc/ssh/sshd_config: 
    Banner /etc/issue
    Another section contains information on how to create an appropriate system-wide warning banner.     The warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers. Alternatively, systems whose ownership should not be obvious should ensure usage of a banner that does not provide easy attribution.     Do Not Allow SSH Environment Options To ensure users are not able to override environment options to the SSH daemon, add or correct the following line in /etc/ssh/sshd_config: 
    PermitUserEnvironment no
     To ensure users are not able to present environment daemons, run the following command: 
    $ sudo grep PermitUserEnvironment /etc/ssh/sshd_config
    If properly configured, output should be: 
    PermitUserEnvironment no
     SSH environment options potentially allow users to bypass access restriction in some configurations.     Use Only Approved Ciphers Limit the ciphers to those algorithms which are FIPS-approved. Counter (CTR) mode is also preferred over cipher-block chaining (CBC) mode. The following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved ciphers: 
    Ciphers aes128-ctr,aes192-ctr,aes256-ctr
    The man page sshd_config(5) contains a list of supported ciphers.     Only FIPS-approved ciphers should be used. To verify that only FIPS-approved ciphers are in use, run the following command: 
    $ sudo grep Ciphers /etc/ssh/sshd_config
    The output should contain only those ciphers which are FIPS-approved, namely, aes128-ctr,aes192-ctr,aes256-ctr     Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore cannot be relied upon to provide confidentiality or integrity, and system data may be compromised.
    Operating systems utilizing encryption are required to use FIPS-compliant mechanisms for authenticating to cryptographic modules.
    FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets industry and government requirements. For government systems, this allows Security Levels 1, 2, 3, or 4 for use on Red Hat Enterprise Linux.     Use Only FIPS Approved MACs Limit the MACs to those hash algorithms which are FIPS-approved. The following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved MACs: 
    MACs hmac-sha2-512,hmac-sha2-256
     Only FIPS-approved MACs should be used. To verify that only FIPS-approved MACs are in use, run the following command: 
    $ sudo grep -i macs /etc/ssh/sshd_config
    The output should contain only those MACs which are FIPS-approved, namely, hmac-sha2-512 and hmac-sha2-256 hash functions.     DoD Information Systems are required to use FIPS-approved cryptographic hash functions. The only SSHv2 hash algorithms meeting this requirement is SHA2.     Strengthen Firewall Configuration if Possible If the SSH server is expected to only receive connections from the local network, then strengthen the default firewall rule for the SSH service to only accept connections from the appropriate network segment(s).

    Determine an appropriate network block, netwk, network mask, mask, and network protocol, ip_protocol, representing the machines on your network which will be allowed to access this SSH server.

    Run the following command: 
    firewall-cmd --permanent --add-rich-rule='rule family="ip_protocol" source address="netwk/mask" service name="ssh" accept'
     Restricting SSH access to only trusted network segments reduces exposure of the SSH server to attacks from unauthorized networks.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/services/sssd.xml000066400000000000000000000111771301675746700242610ustar00rootroot00000000000000 System Security Services Daemon The System Security Services Daemon (SSSD) is a system daemon that provides access to different identity and authentication providers such as Red Hat's IdM, Microsoft's AD, openLDAP, MIT Kerberos, etc. It uses a common framework that can provide caching and offline support to systems utilizing SSSD. SSSD using caching to reduce load on authentication servers permit offline authentication as well as store extended user user data.

    For more information, see https://access.redhat.com/documentation/en_US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/SSSD.html     Install the SSSD Package The sssd package should be installed. Enable the SSSD Service The SSSD service should be enabled. Configure SSSD's Memory Cache to Expire SSSD's memory cache should be configured to set to expire records after 1 day. To configure SSSD to expire memory cache, set memcache_timeout to 86400 under the [nss] section in /etc/sssd/sssd.conf. For example: 
    [nss]
memcache_timeout = 86400
    To verify that SSSD's in-memory cache expires after a day, run the following command: 
    $ sudo grep memcache_timeout /etc/sssd/sssd.conf
    If configured properly, output should be 
    memcache_timeout = 86400
    .     If cached authentication information is out-of-date, the validity of the authentication information may be questionable.     Configure SSSD to Expire Offline Credentials SSSD should be configured to expire offline credentials after 1 day. To configure SSSD to expire offline credentials, set offline_credentials_expiration to 1 under the [nss] section in /etc/sssd/sssd.conf. For example: 
    [nss]
offline_credentials_expiration = 1
    To verify that SSSD expires offline credentials, run the following command: 
    $ sudo grep offline_credentials_expiration
    If configured properly, output should be 
    offline_credentials_expiration = 1
     If cached authentication information is out-of-date, the validity of the authentication information may be questionable.     Configure SSSD to Expire SSH Known Hosts SSSD should be configured to expire keys from known SSH hosts after 1 day. To configure SSSD to known SSH hosts, set ssh_known_hosts_timeout to 86400 under the [nss] section in /etc/sssd/sssd.conf. For example: 
    [nss]
ssh_known_hosts_timeout = 86400
    To verify that SSSD expires known SSH host keys, run the following command: 
    $ sudo grep ssh_known_hosts_timeout
    If configured properly, output should be 
    ssh_known_hosts_timeout = 86400
     If cached authentication information is out-of-date, the validity of the authentication information may be questionable.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/services/xorg.xml000066400000000000000000000066511301675746700242650ustar00rootroot00000000000000 X Window System The X Window System implementation included with the system is called X.org. Disable X Windows Unless there is a mission-critical reason for the system to run a graphical user interface, ensure X is not set to start automatically at boot and remove the X Windows software packages. There is usually no reason to run X Windows on a dedicated server machine, as it increases the system's attack surface and consumes system resources. Administrators of server systems should instead login via SSH or on the text console. Disable X Windows Startup By Setting Default Target Systems that do not require a graphical user interface should only boot by default into multi-user.target mode. This prevents accidental booting of the system into a graphical.target mode. Setting the system's default target to multi-user.target will prevent automatic startup of the X server. To do so, run: 
    $ systemctl set-default multi-user.target
    You should see the following output: 
    rm '/etc/systemd/system/default.target'
ln -s '/usr/lib/systemd/system/multi-user.target' '/etc/systemd/system/default.target'
     To verify the default target is multi-user, run the following command: 
    $ systemctl get-default
    The output should show the following: 
    multi-user.target
     Services that are not required for system and application processes must not be active to decrease the attack surface of the system. X windows has a long history of security vulnerabilities and should not be used unless approved and documented.     Remove the X Windows Package Group By removing the xorg-x11-server-common package, the system no longer has X Windows installed. If X Windows is not installed then the system cannot boot into graphical user mode. This prevents the system from being accidentally or maliciously booted into a graphical.target mode. To do so, run the following command: 
    $ sudo yum groupremove "X Window System"
    $ sudo yum remove xorg-x11-server-common
     To ensure the X Windows package group is removed, run the following command: 
    $ rpm -qi xorg-x11-server-common
    The output should be: 
    package xorg-x11-server-common is not installed
     Unnecessary service packages must not be installed to decrease the attack surface of the system. X windows has a long history of security vulnerabilities and should not be installed unless approved and documented.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/000077500000000000000000000000001301675746700222555ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/accounts/000077500000000000000000000000001301675746700240745ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/accounts/banners.xml000066400000000000000000000340411301675746700262500ustar00rootroot00000000000000 Warning Banners for System Accesses Each system should expose as little information about itself as possible.

    System banners, which are typically displayed just before a login prompt, give out information about the service or the host's operating system. This might include the distribution name and the system kernel version, and the particular version of a network service. This information can assist intruders in gaining access to the system as it can reveal whether the system is running vulnerable software. Most network services can be configured to limit what information is displayed.

    Many organizations implement security policies that require a system banner provide notice of the system's ownership, provide warning to unauthorized users, and remind authorized users of their consent to monitoring.     Login Banner Verbiage Enter an appropriate login banner for your organization. Please note that new lines must be expressed by the '\n' character and special characters like parentheses and quotation marks must be escaped with '\'. --[\s\n]+WARNING[\s\n]+--[\s\n]*This[\s\n]+system[\s\n]+is[\s\n]+for[\s\n]+the[\s\n]+use[\s\n]+of[\s\n]+authorized[\s\n]+users[\s\n]+only.[\s\n]+Individuals[\s\n]*using[\s\n]+this[\s\n]+computer[\s\n]+system[\s\n]+without[\s\n]+authority[\s\n]+or[\s\n]+in[\s\n]+excess[\s\n]+of[\s\n]+their[\s\n]*authority[\s\n]+are[\s\n]+subject[\s\n]+to[\s\n]+having[\s\n]+all[\s\n]+their[\s\n]+activities[\s\n]+on[\s\n]+this[\s\n]+system[\s\n]*monitored[\s\n]+and[\s\n]+recorded[\s\n]+by[\s\n]+system[\s\n]+personnel.[\s\n]+Anyone[\s\n]+using[\s\n]+this[\s\n]*system[\s\n]+expressly[\s\n]+consents[\s\n]+to[\s\n]+such[\s\n]+monitoring[\s\n]+and[\s\n]+is[\s\n]+advised[\s\n]+that[\s\n]*if[\s\n]+such[\s\n]+monitoring[\s\n]+reveals[\s\n]+possible[\s\n]+evidence[\s\n]+of[\s\n]+criminal[\s\n]+activity[\s\n]*system[\s\n]+personal[\s\n]+may[\s\n]+provide[\s\n]+the[\s\n]+evidence[\s\n]+of[\s\n]+such[\s\n]+monitoring[\s\n]+to[\s\n]+law[\s\n]*enforcement[\s\n]+officials. You[\s\n]+are[\s\n]+accessing[\s\n]+a[\s\n]+U.S.[\s\n]+Government[\s\n]+\(USG\)[\s\n]+Information[\s\n]+System[\s\n]+\(IS\)[\s\n]+that[\s\n]+is[\s\n]+provided[\s\n]+for[\s\n]+USG-authorized[\s\n]+use[\s\n]+only.[\s\n]*By[\s\n]+using[\s\n]+this[\s\n]+IS[\s\n]+\(which[\s\n]+includes[\s\n]+any[\s\n]+device[\s\n]+attached[\s\n]+to[\s\n]+this[\s\n]+IS\),[\s\n]+you[\s\n]+consent[\s\n]+to[\s\n]+the[\s\n]+following[\s\n]+conditions\:[\s\n]*-[\s\n]*The[\s\n]+USG[\s\n]+routinely[\s\n]+intercepts[\s\n]+and[\s\n]+monitors[\s\n]+communications[\s\n]+on[\s\n]+this[\s\n]+IS[\s\n]+for[\s\n]+purposes[\s\n]+including,[\s\n]+but[\s\n]+not[\s\n]+limited[\s\n]+to,[\s\n]+penetration[\s\n]+testing,[\s\n]+COMSEC[\s\n]+monitoring,[\s\n]+network[\s\n]+operations[\s\n]+and[\s\n]+defense,[\s\n]+personnel[\s\n]+misconduct[\s\n]+\(PM\),[\s\n]+law[\s\n]+enforcement[\s\n]+\(LE\),[\s\n]+and[\s\n]+counterintelligence[\s\n]+\(CI\)[\s\n]+investigations.[\s\n]*-[\s\n]*At[\s\n]+any[\s\n]+time,[\s\n]+the[\s\n]+USG[\s\n]+may[\s\n]+inspect[\s\n]+and[\s\n]+seize[\s\n]+data[\s\n]+stored[\s\n]+on[\s\n]+this[\s\n]+IS.[\s\n]*-[\s\n]*Communications[\s\n]+using,[\s\n]+or[\s\n]+data[\s\n]+stored[\s\n]+on,[\s\n]+this[\s\n]+IS[\s\n]+are[\s\n]+not[\s\n]+private,[\s\n]+are[\s\n]+subject[\s\n]+to[\s\n]+routine[\s\n]+monitoring,[\s\n]+interception,[\s\n]+and[\s\n]+search,[\s\n]+and[\s\n]+may[\s\n]+be[\s\n]+disclosed[\s\n]+or[\s\n]+used[\s\n]+for[\s\n]+any[\s\n]+USG-authorized[\s\n]+purpose.[\s\n]*-[\s\n]*This[\s\n]+IS[\s\n]+includes[\s\n]+security[\s\n]+measures[\s\n]+\(e.g.,[\s\n]+authentication[\s\n]+and[\s\n]+access[\s\n]+controls\)[\s\n]+to[\s\n]+protect[\s\n]+USG[\s\n]+interests[\s\n]+--[\s\n]+not[\s\n]+for[\s\n]+your[\s\n]+personal[\s\n]+benefit[\s\n]+or[\s\n]+privacy.[\s\n]*-[\s\n]*Notwithstanding[\s\n]+the[\s\n]+above,[\s\n]+using[\s\n]+this[\s\n]+IS[\s\n]+does[\s\n]+not[\s\n]+constitute[\s\n]+consent[\s\n]+to[\s\n]+PM,[\s\n]+LE[\s\n]+or[\s\n]+CI[\s\n]+investigative[\s\n]+searching[\s\n]+or[\s\n]+monitoring[\s\n]+of[\s\n]+the[\s\n]+content[\s\n]+of[\s\n]+privileged[\s\n]+communications,[\s\n]+or[\s\n]+work[\s\n]+product,[\s\n]+related[\s\n]+to[\s\n]+personal[\s\n]+representation[\s\n]+or[\s\n]+services[\s\n]+by[\s\n]+attorneys,[\s\n]+psychotherapists,[\s\n]+or[\s\n]+clergy,[\s\n]+and[\s\n]+their[\s\n]+assistants.[\s\n]+Such[\s\n]+communications[\s\n]+and[\s\n]+work[\s\n]+product[\s\n]+are[\s\n]+private[\s\n]+and[\s\n]+confidential.[\s\n]+See[\s\n]+User[\s\n]+Agreement[\s\n]+for[\s\n]+details. I\'ve[\s\n]+read[\s\n]+\&[\s\n]+consent[\s\n]+to[\s\n]+terms[\s\n]+in[\s\n]+IS[\s\n]+user[\s\n]+agreem\'t. [\s\n]+Use[\s\n]+of[\s\n]+this[\s\n]+or[\s\n]+any[\s\n]+other[\s\n]+DoD[\s\n]+interest[\s\n]+computer[\s\n]+system[\s\n]+constitutes[\s\n]+consent[\s\n]+to[\s\n]+monitoring[\s\n]+at[\s\n]+all[\s\n]+times.[\s\n]+This[\s\n]+is[\s\n]+a[\s\n]+DoD[\s\n]+interest[\s\n]+computer[\s\n]+system.[\s\n]+All[\s\n]+DoD[\s\n]+interest[\s\n]+computer[\s\n]+systems[\s\n]+and[\s\n]+related[\s\n]+equipment[\s\n]+are[\s\n]+intended[\s\n]+for[\s\n]+the[\s\n]+communication,[\s\n]+transmission,[\s\n]+processing,[\s\n]+and[\s\n]+storage[\s\n]+of[\s\n]+official[\s\n]+U.S.[\s\n]+Government[\s\n]+or[\s\n]+other[\s\n]+authorized[\s\n]+information[\s\n]+only.[\s\n]+All[\s\n]+DoD[\s\n]+interest[\s\n]+computer[\s\n]+systems[\s\n]+are[\s\n]+subject[\s\n]+to[\s\n]+monitoring[\s\n]+at[\s\n]+all[\s\n]+times[\s\n]+to[\s\n]+ensure[\s\n]+proper[\s\n]+functioning[\s\n]+of[\s\n]+equipment[\s\n]+and[\s\n]+systems[\s\n]+including[\s\n]+security[\s\n]+devices[\s\n]+and[\s\n]+systems,[\s\n]+to[\s\n]+prevent[\s\n]+unauthorized[\s\n]+use[\s\n]+and[\s\n]+violations[\s\n]+of[\s\n]+statutes[\s\n]+and[\s\n]+security[\s\n]+regulations,[\s\n]+to[\s\n]+deter[\s\n]+criminal[\s\n]+activity,[\s\n]+and[\s\n]+for[\s\n]+other[\s\n]+similar[\s\n]+purposes.[\s\n]+Any[\s\n]+user[\s\n]+of[\s\n]+a[\s\n]+DoD[\s\n]+interest[\s\n]+computer[\s\n]+system[\s\n]+should[\s\n]+be[\s\n]+aware[\s\n]+that[\s\n]+any[\s\n]+information[\s\n]+placed[\s\n]+in[\s\n]+the[\s\n]+system[\s\n]+is[\s\n]+subject[\s\n]+to[\s\n]+monitoring[\s\n]+and[\s\n]+is[\s\n]+not[\s\n]+subject[\s\n]+to[\s\n]+any[\s\n]+expectation[\s\n]+of[\s\n]+privacy.[\s\n]+If[\s\n]+monitoring[\s\n]+of[\s\n]+this[\s\n]+or[\s\n]+any[\s\n]+other[\s\n]+DoD[\s\n]+interest[\s\n]+computer[\s\n]+system[\s\n]+reveals[\s\n]+possible[\s\n]+evidence[\s\n]+of[\s\n]+violation[\s\n]+of[\s\n]+criminal[\s\n]+statutes,[\s\n]+this[\s\n]+evidence[\s\n]+and[\s\n]+any[\s\n]+other[\s\n]+related[\s\n]+information,[\s\n]+including[\s\n]+identification[\s\n]+information[\s\n]+about[\s\n]+the[\s\n]+user,[\s\n]+may[\s\n]+be[\s\n]+provided[\s\n]+to[\s\n]+law[\s\n]+enforcement[\s\n]+officials.[\s\n]+If[\s\n]+monitoring[\s\n]+of[\s\n]+this[\s\n]+or[\s\n]+any[\s\n]+other[\s\n]+DoD[\s\n]+interest[\s\n]+computer[\s\n]+systems[\s\n]+reveals[\s\n]+violations[\s\n]+of[\s\n]+security[\s\n]+regulations[\s\n]+or[\s\n]+unauthorized[\s\n]+use,[\s\n]+employees[\s\n]+who[\s\n]+violate[\s\n]+security[\s\n]+regulations[\s\n]+or[\s\n]+make[\s\n]+unauthorized[\s\n]+use[\s\n]+of[\s\n]+DoD[\s\n]+interest[\s\n]+computer[\s\n]+systems[\s\n]+are[\s\n]+subject[\s\n]+to[\s\n]+appropriate[\s\n]+disciplinary[\s\n]+action.[\s\n]+Use[\s\n]+of[\s\n]+this[\s\n]+or[\s\n]+any[\s\n]+other[\s\n]+DoD[\s\n]+interest[\s\n]+computer[\s\n]+system[\s\n]+constitutes[\s\n]+consent[\s\n]+to[\s\n]+monitoring[\s\n]+at[\s\n]+all[\s\n]+times. Implement a GUI Warning Banner In the default graphical environment, users logging directly into the system are greeted with a login screen provided by the GNOME3 Display Manager (GDM). The warning banner should be displayed in this graphical environment for these users. The following sections describe how to configure the GDM login banner. Enable GNOME3 Login Warning Banner To enable displaying a login warning banner in the GNOME Display Manager's login screen, the banner-message-enable setting must be set under an appropriate configuration file(s) in the /etc/dconf/db/gdm.d directory and locked in /etc/dconf/db/gdm.d/locks directory to prevent user modification. After the settings have been set, run dconf update. To display a banner, this setting must be enabled, and the user must be prevented from making changes. The banner text must also be set. To ensure a login warning banner is enabled, run the following: 
    $ grep banner-message-enable /etc/dconf/db/gdm.d/*
    If properly configured, the output should be true. To ensure a login warning banner is locked and cannot be changed by a user, run the following: 
    $ grep banner-message-enable /etc/dconf/db/gdm.d/locks/*
    If properly configured, the output should be /org/gnome/login-screen/banner-message-enable.     Display of a standardized and approved use notification before granting access to the operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. For U.S. Government systems, system use notifications are required only for access via login interfaces with human users and are not required when such human interfaces do not exist.     Set the GNOME3 Login Warning Banner Text To set the text shown by the GNOME3 Display Manager in the login screen, the banner-message-text setting must be set under an appropriate configuration file(s) in the /etc/dconf/db/gdm.d directory and locked in /etc/dconf/db/gdm.d/locks directory to prevent user modification. After the settings have been set, run dconf update. When entering a warning banner that spans several lines, remember to begin and end the string with ' and use \n for new lines. To ensure the login warning banner text is properly set, run the following: 
    $ grep banner-message-text /etc/dconf/db/gdm.d/*
    If properly configured, the proper banner text will appear. To ensure the login warning banner text is locked and cannot be changed by a user, run the following: 
    $ grep banner-message-enable /etc/dconf/db/gdm.d/locks/*
    If properly configured, the output should be /org/gnome/login-screen/banner-message-text.     An appropriate warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/accounts/pam.xml000066400000000000000000001322201301675746700253730ustar00rootroot00000000000000 Protect Accounts by Configuring PAM PAM, or Pluggable Authentication Modules, is a system which implements modular authentication for Linux programs. PAM provides a flexible and configurable architecture for authentication, and it should be configured to minimize exposure to unnecessary risk. This section contains guidance on how to accomplish that.

    PAM is implemented as a set of shared objects which are loaded and invoked whenever an application wishes to authenticate a user. Typically, the application must be running as root in order to take advantage of PAM, because PAM's modules often need to be able to access sensitive stores of account information, such as /etc/shadow. Traditional privileged network listeners (e.g. sshd) or SUID programs (e.g. sudo) already meet this requirement. An SUID root application, userhelper, is provided so that programs which are not SUID or privileged themselves can still take advantage of PAM.

    PAM looks in the directory /etc/pam.d for application-specific configuration information. For instance, if the program login attempts to authenticate a user, then PAM's libraries follow the instructions in the file /etc/pam.d/login to determine what actions should be taken.

    One very important file in /etc/pam.d is /etc/pam.d/system-auth. This file, which is included by many other PAM configuration files, defines 'default' system authentication measures. Modifying this file is a good way to make far-reaching authentication changes, for instance when implementing a centralized authentication service.     Be careful when making changes to PAM's configuration files. The syntax for these files is complex, and modifications can have unexpected consequences. The default configurations shipped with applications should be sufficient for most users. Running authconfig or system-config-authentication will re-write the PAM configuration files, destroying any manually made changes and replacing them with a series of system defaults. One reference to the configuration file syntax can be found at http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-configuration-file.html. remember The last n passwords for each user are saved in /etc/security/opasswd in order to force password change history and keep the user from alternating between the same password too frequently. 5 0 4 5 10 24 Set Last Logon/Access Notification To configure the system to notify users of last logon/access using pam_lastlog, add or correct the pam_lastlog settings in /etc/pam.d/postlogin to read as follows: 
    session     [success=1 default=ignore] pam_succeed_if.so service !~ gdm* service !~ su* quiet
session     [default=1]   pam_lastlog.so nowtmp showfailed
session     optional      pam_lastlog.so silent noupdate showfailed
     To ensure that last logon/access notification is configured correctly, run the following command: 
    $ grep pam_lastlog.so /etc/pam.d/postlogin
    The output should show output showfailed.     Users need to be aware of activity that occurs regarding their account. Providing users with information regarding the number of unsuccessful attempts that were made to login to their account allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators.     Set Password Quality Requirements The default pam_pwquality PAM module provides strength checking for passwords. It performs a number of checks, such as making sure passwords are not similar to dictionary words, are of at least a certain length, are not the previous password reversed, and are not simply a change of case from the previous password. It can also require passwords to be in certain character classes. The pam_pwquality module is the preferred way of configuring password requirements.

    The pam_cracklib PAM module can also provide strength checking for passwords as the pam_pwquality module. It performs a number of checks, such as making sure passwords are not similar to dictionary words, are of at least a certain length, are not the previous password reversed, and are not simply a change of case from the previous password. It can also require passwords to be in certain character classes.

    The man pages pam_pwquality(8) and pam_cracklib(8) provide information on the capabilities and configuration of each.     Set Password Quality Requirements with pam_pwquality The pam_pwquality PAM module can be configured to meet requirements for a variety of policies.

    For example, to configure pam_pwquality to require at least one uppercase character, lowercase character, digit, and other (special) character, make sure that pam_pwquality exists in /etc/pam.d/system-auth: 
    password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
    If no such line exists, add one as the first line of the password section in /etc/pam.d/system-auth. Next, modify the settings in /etc/security/pwquality.conf to match the following: 
    difok = 4
minlen = 14
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1
maxrepeat = 3
    The arguments can be modified to ensure compliance with your organization's security policy. Discussion of each parameter follows.     Note that the password quality requirements are not enforced for the root account for some reason. retry Number of retry attempts before erroring out 3 1 2 3 4 5 maxrepeat Maximum Number of Consecutive Repeating Characters in a Password 3 1 2 3 maxclassrepeat Maximum Number of Consecutive Repeating Characters in a Password From the Same Character Class 4 1 2 3 4 minlen Minimum number of characters in password 15 6 7 8 10 12 14 15 dcredit Minimum number of digits in password -1 -2 -1 0 ocredit Minimum number of other (special characters) in password -1 -2 -1 0 lcredit Minimum number of lower case in password -1 -2 -1 0 ucredit Minimum number of upper case in password -1 -2 -1 0 difok Minimum number of characters not present in old password Keep this high for short passwords 15 2 3 4 5 5 5 5 15 minclass Minimum number of categories of characters that must exist in a password 3 1 2 3 4 fail_deny Number of failed login attempts before account lockout 3 3 5 6 10 fail_unlock_time Seconds before automatic unlocking after excessive failed logins 604800 600 900 1800 3600 86400 604800 fail_interval Interval for counting failed login attempts before account lockout 900 900 1800 3600 86400 100000000 Set Password Retry Prompts Permitted Per-Session To configure the number of retry prompts that are permitted per-session:

    Edit the pam_pwquality.so statement in /etc/pam.d/system-auth to show retry=, or a lower value if site policy is more restrictive.

    The DoD requirement is a maximum of 3 prompts per session.     To check how many retry attempts are permitted on a per-session basis, run the following command: 
    $ grep pam_pwquality /etc/pam.d/system-auth
    The retry parameter will indicate how many attempts are permitted. The DoD required value is less than or equal to 3. This would appear as retry=3, or a lower value.     Setting the password retry prompts that are permitted on a per-session basis to a low value requires some software, such as SSH, to re-connect. This can slow down and draw additional attention to some types of password-guessing attacks. Note that this is different from account lockout, which is provided by the pam_faillock module.     Set Password Maximum Consecutive Repeating Characters The pam_pwquality module's maxrepeat parameter controls requirements for consecutive repeating characters. When set to a positive number, it will reject passwords which contain more than that number of consecutive characters. Modify the maxrepeat setting in /etc/security/pwquality.conf to equal to prevent a run of ( + 1) or more identical characters. To check the maximum value for consecutive repeating characters, run the following command: 
    $ grep maxrepeat /etc/security/pwquality.conf
    Look for the value of the maxrepeat parameter. The DoD requirement is 2, which would appear as maxrepeat=2.     Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

    Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

    Passwords with excessive repeating characters may be more vulnerable to password-guessing attacks.     Set Password to Maximum of Consecutive Repeating Characters from Same Character Class The pam_pwquality module's maxclassrepeat parameter controls requirements for consecutive repeating characters from the same character class. When set to a positive number, it will reject passwords which contain more than that number of consecutive characters from the same character class. Modify the maxclassrepeat setting in /etc/security/pwquality.conf to equal to prevent a run of ( + 1) or more identical characters. To check the value for maximum consecutive repeating characters, run the following command: 
    $ grep maxclassrepeat /etc/security/pwquality.conf
    For DoD systems, the output should show maxclassrepeat=4.     Use of a complex password helps to increase the time and resources required to comrpomise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.
    Password complexity is one factor of several that determines how long it takes to crack a password. The more complex a password, the greater the number of possible combinations that need to be tested before the password is compromised.     Set Password Strength Minimum Digit Characters The pam_pwquality module's dcredit parameter controls requirements for usage of digits in a password. When set to a negative number, any password will be required to contain that many digits. When set to a positive number, pam_pwquality will grant +1 additional length credit for each digit. Modify the dcredit setting in /etc/security/pwquality.conf to require the use of a digit in passwords. To check how many digits are required in a password, run the following command: 
    $ grep dcredit /etc/security/pwquality.conf
    The dcredit parameter (as a negative number) will indicate how many digits are required. The DoD requires at least one digit in a password. This would appear as dcredit = -1.     Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possble combinations that need to be tested before the password is compromised. Requiring digits makes password guessing attacks more difficult by ensuring a larger search space.     Set Password Minimum Length The pam_pwquality module's minlen parameter controls requirements for minimum characters required in a password. Add minlen= after pam_pwquality to set minimum password length requirements. To check how many characters are required in a password, run the following command: 
    $ grep minlen /etc/security/pwquality.conf
    Your output should contain minlen =     The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised.
    Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password. Use of more characters in a password helps to exponentially increase the time and/or resources required to compromose the password.     Set Password Strength Minimum Uppercase Characters The pam_pwquality module's ucredit= parameter controls requirements for usage of uppercase letters in a password. When set to a negative number, any password will be required to contain that many uppercase characters. When set to a positive number, pam_pwquality will grant +1 additional length credit for each uppercase character. Modify the ucredit setting in /etc/security/pwquality.conf to require the use of an uppercase character in passwords. To check how many uppercase characters are required in a password, run the following command: 
    $ grep ucredit /etc/security/pwquality.conf
    The ucredit parameter (as a negative number) will indicate how many uppercase characters are required. The DoD and FISMA require at least one uppercase character in a password. This would appear as ucredit = -1.     Use of a complex password helps to increase the time and resources reuiqred to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

    Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.     Set Password Strength Minimum Special Characters The pam_pwquality module's ocredit= parameter controls requirements for usage of special (or "other") characters in a password. When set to a negative number, any password will be required to contain that many special characters. When set to a positive number, pam_pwquality will grant +1 additional length credit for each special character. Modify the ocredit setting in /etc/security/pwquality.conf to equal to require use of a special character in passwords. To check how many special characters are required in a password, run the following command: 
    $ grep ocredit /etc/security/pwquality.conf
    The ocredit parameter (as a negative number) will indicate how many special characters are required. The DoD and FISMA require at least one special character in a password. This would appear as ocredit = -1.     Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

    Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possble combinations that need to be tested before the password is compromised. Requiring a minimum number of special characters makes password guessing attacks more difficult by ensuring a larger search space.     Set Password Strength Minimum Lowercase Characters The pam_pwquality module's lcredit parameter controls requirements for usage of lowercase letters in a password. When set to a negative number, any password will be required to contain that many lowercase characters. When set to a positive number, pam_pwquality will grant +1 additional length credit for each lowercase character. Modify the lcredit setting in /etc/security/pwquality.conf to require the use of a lowercase character in passwords. To check how many lowercase characters are required in a password, run the following command: 
    $ grep lcredit /etc/security/pwquality.conf
    The lcredit parameter (as a negative number) will indicate how many special characters are required. The DoD and FISMA require at least one lowercase character in a password. This would appear as lcredit = -1.     Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

    Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possble combinations that need to be tested before the password is compromised. Requiring a minimum number of lowercase characters makes password guessing attacks more difficult by ensuring a larger search space.     Set Password Strength Minimum Different Characters The pam_pwquality module's difok parameter sets the number of characters in a password that must not be present in and old password during a password change. Modify the difok setting in /etc/security/pwquality.conf to equal to require differing characters when changing passwords. To check how many characters must differ during a password change, run the following command: 
    $ grep difok /etc/security/pwquality.conf
    The difok parameter will indicate how many characters must differ.     Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute–force attacks.

    Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

    Requiring a minimum number of different characters during password changes ensures that newly changed passwords should not resemble previously compromised ones. Note that passwords which are changed on compromised systems will still be compromised, however.     Set Password Strength Minimum Different Categories The pam_pwquality module's minclass parameter controls requirements for usage of different character classes, or types, of character that must exist in a password before it is considered valid. For example, setting this value to three (3) requires that any password must have characters from at least three different categories in order to be approved. The default value is zero (0), meaning there are no required classes. There are four categories available: 
    * Upper-case characters
* Lower-case characters
* Digits
* Special characters (for example, punctuation)
    Modify the minclass setting in /etc/security/pwquality.conf entry to require differing categories of characters when changing passwords.     To check how many categories of characters must be used in password during a password change, run the following command: 
    $ grep minclass /etc/security/pwquality.conf
    The minclass parameter will indicate how many character classes must be used. If the requirement was for the password to contain characters from three different categories, then this would appear as minclass = 3.     Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

    Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

    Requiring a minimum number of character categories makes password guessing attacks more difficult by ensuring a larger search space.     Set Lockouts for Failed Password Attempts The pam_faillock PAM module provides the capability to lock out user accounts after a number of failed login attempts. Its documentation is available in /usr/share/doc/pam-VERSION/txts/README.pam_faillock.

    Locking out user accounts presents the risk of a denial-of-service attack. The lockout policy must weigh whether the risk of such a denial-of-service attack outweighs the benefits of thwarting password guessing attacks. Set Deny For Failed Password Attempts To configure the system to lock out accounts after a number of incorrect login attempts using pam_faillock.so, modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows:

    • add the following line immediately before the pam_unix.so statement in the AUTH section: 
      auth required pam_faillock.so preauth silent deny= unlock_time= fail_interval=
    • add the following line immediately after the pam_unix.so statement in the AUTH section: 
      auth [default=die] pam_faillock.so authfail deny= unlock_time= fail_interval=
    • add the following line immediately before the pam_unix.so statement in the ACCOUNT section: 
      account required pam_faillock.so
     To ensure the failed password attempt policy is configured correctly, run the following command: 
    $ grep pam_faillock /etc/pam.d/system-auth
    The output should show deny=.     Locking out user accounts after a number of incorrect attempts prevents direct password guessing attacks.     Set Lockout Time For Failed Password Attempts To configure the system to lock out accounts after a number of incorrect login attempts and require an administrator to unlock the account using pam_faillock.so, modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows:

    • add the following line immediately before the pam_unix.so statement in the AUTH section: 
      auth required pam_faillock.so preauth silent deny= unlock_time= fail_interval=
    • add the following line immediately after the pam_unix.so statement in the AUTH section: 
      auth [default=die] pam_faillock.so authfail deny= unlock_time= fail_interval=
    • add the following line immediately before the pam_unix.so statement in the ACCOUNT section: 
      account required pam_faillock.so
     To ensure the failed password attempt policy is configured correctly, run the following command: 
    $ grep pam_faillock /etc/pam.d/system-auth
    The output should show unlock_time=<some-large-number>.     Locking out user accounts after a number of incorrect attempts prevents direct password guessing attacks. Ensuring that an administrator is involved in unlocking locked accounts draws appropriate attention to such situations.     Configure the <tt>root</tt> Account for Failed Password Attempts To configure the system to lock out the root account after a number of incorrect login attempts using pam_faillock.so, modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows:

    • Modify the following line in the AUTH section to add even_deny_root: 
      auth required pam_faillock.so preauth silent even_deny_root deny= unlock_time= fail_interval=
    • Modify the following line in the AUTH section to add even_deny_root: 
      auth [default=die] pam_faillock.so authfail even_deny_root deny= unlock_time= fail_interval=
     To ensure that even the root account is locked after a defined number of failed password attempts, run the following command: 
    $ grep even_deny_root /etc/pam.d/system-auth
    The output should show even_deny_root.     By limiting the number of failed logon attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute-forcing, is reduced. Limits are imposed by locking the account.     Set Interval For Counting Failed Password Attempts Utilizing pam_faillock.so, the fail_interval directive configures the system to lock out an accounts after a number of incorrect login attempts within a specified time period.. Modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows:

    • Add the following line immediately before the pam_unix.so statement in the AUTH section: 
      auth required pam_faillock.so preauth silent deny= unlock_time= fail_interval=
    • Add the following line immediately after the pam_unix.so statement in the AUTH section: 
      auth [default=die] pam_faillock.so authfail deny= unlock_time= fail_interval=
    • Add the following line immediately before the pam_unix.so statement in the ACCOUNT section: 
      account required pam_faillock.so
     To ensure the failed password attempt policy is configured correctly, run the following command: 
    $ grep pam_faillock /etc/pam.d/system-auth /etc/pam.d/password-auth
    For each file, the output should show fail_interval=<interval-in-seconds> where interval-in-seconds is or greater. If the fail_interval parameter is not set, the default setting of 900 seconds is acceptable.     By limiting the number of failed logon attempts the risk of unauthorized system access via user password guessing, otherwise known as brute-forcing, is reduced. Limits are imposed by locking the account.     Limit Password Reuse Do not allow users to reuse recent passwords. This can be accomplished by using the remember option for the pam_unix or pam_pwhistory PAM modules.

    In the file /etc/pam.d/system-auth, append remember= to the line which refers to the pam_unix.so or pam_pwhistory.somodule, as shown below:
    • for the pam_unix.so case: 
      password sufficient pam_unix.so ...existing_options... remember=
    • for the pam_pwhistory.so case: 
      password requisite pam_pwhistory.so ...existing_options... remember=
    The DoD STIG requirement is 5 passwords.     To verify the password reuse setting is compliant, run the following command: 
    $ grep remember /etc/pam.d/system-auth
    The output should show the following at the end of the line: 
    remember=
     Preventing re-use of previous passwords helps ensure that a compromised password is not re-used by a user.     Set Password Hashing Algorithm The system's default algorithm for storing password hashes in /etc/shadow is SHA-512. This can be configured in several locations. Set PAM's Password Hashing Algorithm The PAM system service can be configured to only store encrypted representations of passwords. In /etc/pam.d/system-auth, the password section of the file controls which PAM modules execute during a password change. Set the pam_unix.so module in the password section to include the argument sha512, as shown below: 
    password    sufficient    pam_unix.so sha512 other arguments...

    This will help ensure when local users change their passwords, hashes for the new passwords will be generated using the SHA-512 algorithm. This is the default.     Inspect the password section of /etc/pam.d/system-auth and ensure that the pam_unix.so module includes the argument sha512: 
    $ grep sha512 /etc/pam.d/system-auth
     Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. Passwords that are encrypted with a weak algorithm are no more protected than if they are kepy in plain text.

    This setting ensures user and group account administration utilities are configured to store only encrypted representations of passwords. Additionally, the crypt_style configuration option ensures the use of a strong hashing algorithm that makes password cracking attacks more difficult.     Set Password Hashing Algorithm in /etc/login.defs In /etc/login.defs, add or correct the following line to ensure the system will use SHA-512 as the hashing algorithm: 
    ENCRYPT_METHOD SHA512
     Inspect /etc/login.defs and ensure the following line appears: 
    ENCRYPT_METHOD SHA512
     Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. Passwords that are encrypted with a weak algorithm are no more protected than if they are kept in plain text.

    Using a stronger hashing algorithm makes password cracking attacks more difficult.     Set Password Hashing Algorithm in /etc/libuser.conf In /etc/libuser.conf, add or correct the following line in its [defaults] section to ensure the system will use the SHA-512 algorithm for password hashing: 
    crypt_style = sha512
     Inspect /etc/libuser.conf and ensure the following line appears in the [default] section: 
    crypt_style = sha512
     Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. Passwords that are encrypted with a weak algorithm are no more protected than if they are kepy in plain text.

    This setting ensures user and group account administration utilities are configured to store only encrypted representations of passwords. Additionally, the crypt_style configuration option ensures the use of a strong hashing algorithm that makes password cracking attacks more difficult.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/accounts/physical.xml000066400000000000000000000445061301675746700264430ustar00rootroot00000000000000 Protect Physical Console Access It is impossible to fully protect a system from an attacker with physical access, so securing the space in which the system is located should be considered a necessary step. However, there are some steps which, if taken, make it more difficult for an attacker to quickly or undetectably modify a system from its console. Set Boot Loader Password During the boot process, the boot loader is responsible for starting the execution of the kernel and passing options to it. The boot loader allows for the selection of different kernels - possibly on different partitions or media. The default Red Hat Enterprise Linux boot loader for x86 systems is called GRUB2. Options it can pass to the kernel include single-user mode, which provides root access without any authentication, and the ability to disable SELinux. To prevent local users from modifying the boot parameters and endangering security, protect the boot loader configuration with a password and ensure its configuration file's permissions are set properly. Verify /boot/grub2/grub.cfg User Ownership The file /boot/grub2/grub.cfg should be owned by the root user to prevent destruction or modification of the file. Only root should be able to modify important boot parameters. Verify /boot/grub2/grub.cfg Group Ownership The file /boot/grub2/grub.cfg should be group-owned by the root group to prevent destruction or modification of the file. The root group is a highly-privileged group. Furthermore, the group-owner of this file should not have any access privileges anyway. Verify /boot/grub2/grub.cfg Permissions File permissions for /boot/grub2/grub.cfg should be set to 600. To check the permissions of /boot/grub2/grub.cfg, run the command: 
    $ sudo ls -lL /boot/grub2/grub.cfg
    If properly configured, the output should indicate the following permissions: -rw-------     Proper permissions ensure that only the root user can modify important boot parameters.     Set Boot Loader Password The grub2 boot loader should have a superuser account and password protection enabled to protect boot-time settings.

    To do so, select a superuser account and password and add them into the /etc/grub.d/01_users configuration file.

    Since plaintext passwords are a security risk, generate a hash for the pasword by running the following command: 
    $ grub2-mkpasswd-pbkdf2
    When prompted, enter the password that was selected and insert the returned password hash into the /etc/grub.d/01_users configuration file immediately after the superuser account. (Use the output from grub2-mkpasswd-pbkdf2 as the value of password-hash): 
    password_pbkdf2 superusers-account password-hash
    NOTE: It is recommended not to use common administrator account names like root, admin, or administrator for the grub2 superuser account.

    To meet FISMA Moderate, the bootloader superuser account and password MUST differ from the root account and password. Once the superuser account and password have been added, update the grub.cfg file by running: 
    grub2-mkconfig -o /boot/grub2/grub.cfg
    NOTE: Do NOT manually add the superuser account and password to the grub.cfg file as the grub2-mkconfig command overwrites this file.     To verify the boot loader superuser account and superuser account password have been set, and the password encrypted, run the following command: 
    $ sudo grep -A1 "superusers\|password" /etc/grub2.cfg
    The output should show the following: 
    set superusers="superusers-account"
password_pbkdf2 superusers-account password-hash
     Password protection on the boot loader configuration ensures users with physical access cannot trivially alter important bootloader settings. These include which kernel to use, and whether to enter single-user mode. For more information on how to configure the grub2 superuser account and password, please refer to
    • https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sec-GRUB_2_Password_Protection.html
      • .
    Set the UEFI Boot Loader Password The UEFI grub2 boot loader should have a superuser account and password protection enabled to protect boot-time settings.

    To do so, select a superuser account and password and add them into the /etc/grub.d/01_users configuration file.

    Since plaintext passwords are a security risk, generate a hash for the pasword by running the following command: 
    $ grub2-mkpasswd-pbkdf2
    When prompted, enter the password that was selected and insert the returned password hash into the /etc/grub.d/01_users configuration file immediately after the superuser account. (Use the output from grub2-mkpasswd-pbkdf2 as the value of password-hash): 
    password_pbkdf2 superusers-account password-hash
    NOTE: It is recommended not to use common administrator account names like root, admin, or administrator for the grub2 superuser account.

    To meet FISMA Moderate, the bootloader superuser account and password MUST differ from the root account and password. Once the superuser account and password have been added, update the grub.cfg file by running: 
    grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
    NOTE: Do NOT manually add the superuser account and password to the grub.cfg file as the grub2-mkconfig command overwrites this file.     To verify the boot loader superuser account and superuser account password have been set, and the password encrypted, run the following command: 
    sudo grep -A1 "superusers\|password" /etc/grub2-efi.cfg
    The output should show the following: 
    set superusers="superusers-account"
password_pbkdf2 superusers-account password-hash
     Password protection on the boot loader configuration ensures users with physical access cannot trivially alter important bootloader settings. These include which kernel to use, and whether to enter single-user mode. For more information on how to configure the grub2 superuser account and password, please refer to
    • https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sec-GRUB_2_Password_Protection.html
      • .
    Require Authentication for Single User Mode Single-user mode is intended as a system recovery method, providing a single user root access to the system by providing a boot option at startup. By default, no authentication is performed if single-user mode is selected.

    By default, single-user mode is protected by requiring a password and is set in /usr/lib/systemd/system/rescue.service.     To check if authentication is required for single-user mode, run the following command: 
    $ grep sulogin /usr/lib/systemd/system/rescue.service
    The output should be similar to the following, and the line must begin with ExecStart and /sbin/sulogin: 
    ExecStart=-/sbin/sulogin
     This prevents attackers with physical access from trivially bypassing security on the machine and gaining root access. Such accesses are further prevented by configuring the bootloader password.     Disable debug-shell SystemD Service SystemD's debug-shell service is intended to diagnose SystemD related boot issues with various systemctl commands. Once enabled and following a system reboot, the root shell will be available on tty9 which is access by pressing CTRL-ALT-F9. The debug-shell service should only be used for SystemD related issues and should otherwise be disabled.

    By default, the debug-shell SystemD service is disabled.     This prevents attackers with physical access from trivially bypassing security on the machine through valid troubleshooting configurations and gaining root access when the system is rebooted.     Disable Ctrl-Alt-Del Reboot Activation By default, SystemD will reboot the system if the Ctrl-Alt-Del key sequence is pressed.

    To configure the system to ignore the Ctrl-Alt-Del key sequence from the command line instead of rebooting the system, do either of the following: 
    ln -sf /dev/null /etc/systemd/system/ctrl-alt-del.target
    or 
    systemctl mask ctrl-alt-del.target


    Do not simply delete the /usr/lib/systemd/system/ctrl-alt-del.service file, as this file may be restored during future system updates.     To ensure the system is configured to mask the Ctrl-Alt-Del sequence, enter the following command: 
    $ sudo ln -sf /dev/null /etc/systemd/system/ctrl-alt-del.target
    or 
    $ sudo systemctl mask ctrl-alt-del.target
     A locally logged-in user who presses Ctrl-Alt-Del, when at the console, can reboot the system. If accidentally pressed, as could happen in the case of mixed OS environment, this can create the risk of short-term loss of availability of systems due to unintentional reboot. Disabling the Ctrl-Alt-Del key sequence with SystemD DOES NOT disable the Ctrl-Alt-Del key sequence if running in graphical.target mode (e.g. in GNOME, KDE, etc.)! The Ctrl-Alt-Del key sequence will only be disabled if running in the non-graphical multi-user.target mode.     Verify that Interactive Boot is Disabled Red Hat Enterprise Linux systems support an "interactive boot" option that can be used to prevent services from being started. On a Red Hat Enterprise Linux 7 system, interactive boot can be enabled by providing a 1, yes, true, or on value to the systemd.confirm_spawn kernel argument in /etc/default/grub. Remove any instance of 
    systemd.confirm_spawn=(1|yes|true|on)
    from the kernel arguments in that file to disable interactive boot.     Inspect /etc/default/grub for any instances of systemd.confirm_spawn=(1|yes|true|on) in the kernel boot arguments. Presence of a systemd.confirm_spawn=(1|yes|true|on) indicates that interactive boot is enabled at boot time. Using interactive boot, the console user could disable auditing, firewalls, or other services, weakening system security. The GRUB 2 configuration file, grub.cfg, is automatically updated each time a new kernel is installed. Note that any changes to /etc/default/grub require rebuilding the grub.cfg file. To update the GRUB 2 configuration file manually, use the 
    grub2-mkconfig -o
    command as follows:
    • On BIOS-based machines, issue the following command as root: 
      ~]# grub2-mkconfig -o /boot/grub2/grub.cfg
    • On UEFI-based machines, issue the following command as root: 
      ~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
         Configure Screen Locking When a user must temporarily leave an account logged-in, screen locking should be employed to prevent passersby from abusing the account. User education and training is particularly important for screen locking to be effective, and policies can be implemented to reinforce this.

    Automatic screen locking is only meant as a safeguard for those cases where a user forgot to lock the screen.     Configure Console Screen Locking A console screen locking mechanism is provided in the screen package, which is not installed by default. Install the screen Package To enable console screen locking, install the screen package: 
    $ sudo yum install screen
    Instruct users to begin new terminal sessions with the following command: 
    $ screen
    The console can now be locked with the following key combination: 
    ctrl+a x
     A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but des not logout because of the temporary nature of the absence. Rather than relying on the user to manually lock their operation system session prior to vacating the vicinity, operating systems need to be able to identify when a user's session has idled and take action to initiate the session lock.

    The screen package allows for a session lock to be implemented and configured.     Hardware Tokens for Authentication The use of hardware tokens such as smart cards for system login provides stronger, two-factor authentication than using a username and password. In Red Hat Enterprise Linux servers and workstations, hardware token login is not enabled by default and must be enabled in the system settings. Enable Smart Card Login To enable smart card authentication, consult the documentation at:
    • https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html/System-Level_Authentication_Guide/authconfig-addl-auth.html#authconfig-smartcard
    For guidance on enabling SSH to authenticate against a Common Access Card (CAC), consult documentation at:
    • https://access.redhat.com/solutions/82273
     Interview the SA to determine if all accounts not exempted by policy are using CAC authentication. For DoD systems, the following systems and accounts are exempt from using smart card (CAC) authentication:
    • SIPRNET systems
    • Standalone systems
    • Application accounts
    • Temporary employee accounts, such as students or interns, who cannot easily receive a CAC or PIV
    • Operational tactical locations that are not collocated with RAPIDS workstations to issue CAC or ALT
    • Test systems, such as those with an Interim Approval to Test (IATT) and use a separate VPN, firewall, or security measure preventing access to network and system components from outside the protection boundary documented in the IATT.
     Smart card login provides two-factor authentication stronger than that provided by a username and password combination. Smart cards leverage PKI (public key infrastructure) in order to provide and verify credentials.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/accounts/restrictions/000077500000000000000000000000001301675746700266245ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/accounts/restrictions/account_expiration.xml000066400000000000000000000133501301675746700332460ustar00rootroot00000000000000 Set Account Expiration Parameters Accounts can be configured to be automatically disabled after a certain time period, meaning that they will require administrator interaction to become usable again. Expiration of accounts after inactivity can be set for all accounts by default and also on a per-account basis, such as for accounts that are known to be temporary. To configure automatic expiration of an account following the expiration of its password (that is, after the password has expired and not been changed), run the following command, substituting NUM_DAYS and USER appropriately: 
    $ sudo chage -I NUM_DAYS USER
    Accounts, such as temporary accounts, can also be configured to expire on an explicitly-set date with the -E option. The file /etc/default/useradd controls default settings for all newly-created accounts created with the system's normal command line utilities.     number of days after a password expires until the account is permanently disabled The number of days to wait after a password expires, until the account will be permanently disabled. This will only apply to newly created accounts 35 0 30 35 40 60 90 180 Set Account Expiration Following Inactivity To specify the number of days after a password expires (which signifies inactivity) until an account is permanently disabled, add or correct the following lines in /etc/default/useradd, substituting NUM_DAYS appropriately: 
    INACTIVE=
    A value of 35 is recommended. If a password is currently on the verge of expiration, then 35 days remain until the account is automatically disabled. However, if the password will not expire for another 60 days, then 95 days could elapse until the account would be automatically disabled. See the useradd man page for more information. Determining the inactivity timeout must be done with careful consideration of the length of a "normal" period of inactivity for users in the particular environment. Setting the timeout too low incurs support costs and also has the potential to impact availability of the system to legitimate users.     To verify the INACTIVE setting, run the following command: 
    $ grep "INACTIVE" /etc/default/useradd
    The output should indicate the INACTIVE configuration option is set to an appropriate integer as shown in the example below: 
    $ sudo grep "INACTIVE" /etc/default/useradd
INACTIVE=
     Disabling inactive accounts ensures that accounts which may not have been responsibly removed are not available to attackers who may have compromised their credentials.     Ensure All Accounts on the System Have Unique Names Change usernames, or delete accounts, so each has a unique name. Run the following command to check for duplicate account names: 
    $ sudo pwck -qr
    If there are no duplicate names, no line will be returned.     Unique usernames allow for accountability on the system.     Assign Expiration Date to Temporary Accounts Temporary accounts are established as part of normal account activation procedures when there is a need for short-term accounts. In the event temporary or emergency accounts are required, configure the system to terminate them after a documented time period. For every temporary and emergency account, run the following command to set an expiration date on it, substituting USER and YYYY-MM-DD appropriately: 
    $ sudo chage -E YYYY-MM-DD USER
    YYYY-MM-DD indicates the documented expiration date for the account. For U.S. Government systems, the operating system must be configured to automatically terminate these types of accounts after a period of 72 hours.     For every temporary and emergency account, run the following command to obtain its account aging and expiration information: 
    $ sudo chage -l USER
    Verify each of these accounts has an expiration date set as documented.     If temporary user accounts remain active when no longer needed or for an excessive period, these accounts may be used to gain unauthorized access. To mitigate this risk, automated termination of all temporary accounts must be set upon account creation.
    scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/accounts/restrictions/password_expiration.xml000066400000000000000000000210041301675746700334470ustar00rootroot00000000000000 Set Password Expiration Parameters The file /etc/login.defs controls several password-related settings. Programs such as passwd, su, and login consult /etc/login.defs to determine behavior with regard to password aging, expiration warnings, and length. See the man page login.defs(5) for more information.

    Users should be forced to change their passwords, in order to decrease the utility of compromised passwords. However, the need to change passwords often should be balanced against the risk that users will reuse or write down passwords if forced to change them too often. Forcing password changes every 90-360 days, depending on the environment, is recommended. Set the appropriate value as PASS_MAX_DAYS and apply it to existing accounts with the -M flag.

    The PASS_MIN_DAYS (-m) setting prevents password changes for 7 days after the first change, to discourage password cycling. If you use this setting, train users to contact an administrator for an emergency password change in case a new password becomes compromised. The PASS_WARN_AGE (-W) setting gives users 7 days of warnings at login time that their passwords are about to expire.

    For example, for each existing human user USER, expiration parameters could be adjusted to a 180 day maximum password age, 7 day minimum password age, and 7 day warning period with the following command: 
    $ sudo chage -M 180 -m 7 -W 7 USER
     minimum password length Minimum number of characters in password This will only check new passwords 14 6 8 10 12 14 maximum password age Maximum age of password in days This will only apply to newly created accounts 60 60 90 120 180 minimum password age Minimum age of password in days This will only apply to newly created accounts 7 7 5 2 1 0 warning days before password expires The number of days' warning given before a password expires. This will only apply to newly created accounts 7 0 7 14 Set Password Minimum Length in login.defs To specify password length requirements for new accounts, edit the file /etc/login.defs and add or correct the following lines: 
    PASS_MIN_LEN 14


    The DoD requirement is 14. The FISMA requirement is 12. If a program consults /etc/login.defs and also another PAM module (such as pam_pwquality) during a password change operation, then the most restrictive must be satisfied. See PAM section for more information about enforcing password quality requirements.     To check the minimum password length, run the command: 
    $ grep PASS_MIN_LEN /etc/login.defs
    The DoD requirement is 14.     Requiring a minimum password length makes password cracking attacks more difficult by ensuring a larger search space. However, any security benefit from an onerous requirement must be carefully weighed against usability problems, support costs, or counterproductive behavior that may result.     Set Password Minimum Age To specify password minimum age for new accounts, edit the file /etc/login.defs and add or correct the following line, replacing DAYS appropriately: 
    PASS_MIN_DAYS DAYS
    A value of 1 day is considered for sufficient for many environments. The DoD requirement is 1.     To check the minimum password age, run the command: 
    $ grep PASS_MIN_DAYS /etc/login.defs
     Enforcing a minimum password lifetime helps to prevent repeated password changes to defeat the password reuse or history enforcement requirement. If users are allowed to immediately and continually change their password, then the password could be repeatedly changed in a short period of time to defeat the organization's policy regarding password reuse.

    Setting the minimum password age protects against users cycling back to a favorite password after satisfying the password reuse requirement.     Set Password Maximum Age To specify password maximum age for new accounts, edit the file /etc/login.defs and add or correct the following line, replacing DAYS appropriately: 
    PASS_MAX_DAYS DAYS
    A value of 180 days is sufficient for many environments. The DoD requirement is 60.     To check the maximum password age, run the command: 
    $ grep PASS_MAX_DAYS /etc/login.defs
    The DoD and FISMA requirement is 60. A value of 180 days is sufficient for many environments.     Any password, no matter how complex, can eventually be cracked. Therefore, passwords need to be changed periodically. If the operating system does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the operating system passwords could be compromised.

    Setting the password maximum age ensures users are required to periodically change their passwords. Requiring shorter password lifetimes increases the risk of users writing down the password in a convenient location subject to physical compromise.         Set Password Warning Age To specify how many days prior to password expiration that a warning will be issued to users, edit the file /etc/login.defs and add or correct the following line, replacing DAYS appropriately: 
    PASS_WARN_AGE DAYS
    The DoD requirement is 7.     To check the password warning age, run the command: 
    $ grep PASS_WARN_AGE /etc/login.defs
    The DoD requirement is 7.     Setting the password warning age enables users to make the change at a practical time.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/accounts/restrictions/password_storage.xml000066400000000000000000000114611301675746700327370ustar00rootroot00000000000000 Verify Proper Storage and Existence of Password Hashes By default, password hashes for local accounts are stored in the second field (colon-separated) in /etc/shadow. This file should be readable only by processes running with root credentials, preventing users from casually accessing others' password hashes and attempting to crack them. However, it remains possible to misconfigure the system and store password hashes in world-readable files such as /etc/passwd, or to even store passwords themselves in plaintext on the system. Using system-provided tools for password change/creation should allow administrators to avoid such misconfiguration. Prevent Log In to Accounts With Empty Password If an account is configured for password authentication but does not have an assigned password, it may be possible to log into the account without authentication. Remove any instances of the nullok option in /etc/pam.d/system-auth to prevent logins with empty passwords. To verify that null passwords cannot be used, run the following command: 
    $ grep nullok /etc/pam.d/system-auth
    If this produces any output, it may be possible to log into accounts with empty passwords. Remove any instances of the nullok option to prevent logins with empty passwords.     If an account has an empty password, anyone could log in and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments.     Verify All Account Password Hashes are Shadowed If any password hashes are stored in /etc/passwd (in the second field, instead of an x), the cause of this misconfiguration should be investigated. The account should have its password reset and the hash should be properly stored, or the account should be deleted entirely. To check that no password hashes are stored in /etc/passwd, run the following command: 
    $ awk -F: '($2 != "x") {print}' /etc/passwd
    If it produces any output, then a password hash is stored in /etc/passwd.     The hashes for all user account passwords should be stored in the file /etc/shadow and never in /etc/passwd, which is readable by all users.     All GIDs referenced in /etc/passwd must be defined in /etc/group Add a group to the system for each GID referenced without a corresponding group. To ensure all GIDs referenced in /etc/passwd are defined in /etc/group, run the following command: 
    $ sudo pwck -qr
    There should be no output.     If a user is assigned the Group Identifier (GID) of a group not existing on the system, and a group with the Gruop Identifier (GID) is subsequently created, the user may have unintended rights to any files associated with the group.     Verify No netrc Files Exist The .netrc files contain login information used to auto-login into FTP servers and reside in the user's home directory. These files may contain unencrypted passwords to remote FTP servers making them susceptible to access by unauthorized users and should not be used. Any .netrc files should be removed. To check the system for the existence of any .netrc files, run the following command: 
    $ sudo find /home -xdev -name .netrc
     Unencrypted passwords for remote FTP servers may be stored in .netrc files. DoD policy requires passwords be encrypted in storage and not used in access scripts.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/accounts/restrictions/root_logins.xml000066400000000000000000000245461301675746700317170ustar00rootroot00000000000000 Restrict Root Logins Direct root logins should be allowed only for emergency use. In normal situations, the administrator should access the system via a unique unprivileged account, and then use su or sudo to execute privileged commands. Discouraging administrators from accessing the root account directly ensures an audit trail in organizations with multiple administrators. Locking down the channels through which root can connect directly also reduces opportunities for password-guessing against the root account. The login program uses the file /etc/securetty to determine which interfaces should allow root logins. The virtual devices /dev/console and /dev/tty* represent the system consoles (accessible via the Ctrl-Alt-F1 through Ctrl-Alt-F6 keyboard sequences on a default installation). The default securetty file also contains /dev/vc/*. These are likely to be deprecated in most environments, but may be retained for compatibility. Root should also be prohibited from connecting via network protocols. Other sections of this document include guidance describing how to prevent root from logging in via SSH. Direct root Logins Not Allowed To further limit access to the root account, administrators can disable root logins at the console by editing the /etc/securetty file. This file lists all devices the root user is allowed to login to. If the file does not exist at all, the root user can login through any communication device on the system, whether via the console or via a raw network interface. This is dangerous as user can login to his machine as root via Telnet, which sends the password in plain text over the network. By default, Red Hat Enteprise Linux's /etc/securetty file only allows the root user to login at the console physically attached to the machine. To prevent root from logging in, remove the contents of this file. To prevent direct root logins, remove the contents of this file by typing the following command: 
    $ sudo echo > /etc/securetty
    To ensure root may not directly login to the system over physical consoles, run the following command: 
    cat /etc/securetty
    If any output is returned, this is a finding.     Disabling direct root logins ensures proper accountability and multifactor authentication to privileged accounts. Users will first login, then escalate to privileged (root) access via su / sudo. This is required for FISMA Low and FISMA Moderate systems.     Restrict Virtual Console Root Logins To restrict root logins through the (deprecated) virtual console devices, ensure lines of this form do not appear in /etc/securetty: 
    vc/1
vc/2
vc/3
vc/4
     To check for virtual console entries which permit root login, run the following command: 
    $ sudo grep ^vc/[0-9] /etc/securetty
    If any output is returned, then root logins over virtual console devices is permitted.     Preventing direct root login to virtual console devices helps ensure accountability for actions taken on the system using the root account.     Restrict Serial Port Root Logins To restrict root logins on serial ports, ensure lines of this form do not appear in /etc/securetty: 
    ttyS0
ttyS1
     To check for serial port entries which permit root login, run the following command: 
    $ sudo grep ^ttyS/[0-9] /etc/securetty
    If any output is returned, then root login over serial ports is permitted.     Preventing direct root login to serial port interfaces helps ensure accountability for actions taken on the systems using the root account.     Restrict Web Browser Use for Administrative Accounts Enforce policy requiring administrative accounts use web browsers only for local service administration. Check the root home directory for a .mozilla directory. If one exists, ensure browsing is limited to local service administration. If a browser vulnerability is exploited while running with administrative privileges, the entire system could be compromised. Specific exceptions for local service administration should be documented in site-defined policy. Ensure that System Accounts Do Not Run a Shell Upon Login Some accounts are not associated with a human user of the system, and exist to perform some administrative function. Should an attacker be able to log into these accounts, they should not be granted access to a shell.

    The login shell for each local account is stored in the last field of each line in /etc/passwd. System accounts are those user accounts with a user ID less than UID_MIN, where value of UID_MIN directive is set in /etc/login.defs configuration file. In the default configuration UID_MIN is set to 1000, thus system accounts are those user accounts with a user ID less than 1000. The user ID is stored in the third field. If any system account SYSACCT (other than root) has a login shell, disable it with the command: 
    $ sudo usermod -s /sbin/nologin SYSACCT
     To obtain a listing of all users, their UIDs, and their shells, run the command: 
    $ awk -F: '{print $1 ":" $3 ":" $7}' /etc/passwd
    Identify the system accounts from this listing. These will primarily be the accounts with UID numbers less than UID_MIN, other than root. Value of the UID_MIN directive is set in /etc/login.defs configuration file. In the default configuration UID_MIN is set to 1000.     Ensuring shells are not given to system accounts upon login makes it more difficult for attackers to make use of system accounts. Do not perform the steps in this section on the root account. Doing so might cause the system to become inaccessible.     Verify Only Root Has UID 0 If any account other than root has a UID of 0, this misconfiguration should be investigated and the accounts other than root should be removed or have their UID changed.
    If the account is associated with system commands or applications the UID should be changed to one greater than "0" but less than "1000." Otherwise assign a UID greater than "1000" that has not already been assigned.     To list all password file entries for accounts with UID 0, run the following command: 
    $ awk -F: '($3 == "0") {print}' /etc/passwd
    This should print only one line, for the user root.
    If there is a finding, change the UID of the failing (non-root) user. If the account is associated with the system commands or applications the UID should be changed to one greater than 0 but less than 1000. Otherwise assign a UID of greater than 1000 that has not already been assigned.     An account has root authority if it has a UID of 0. Multiple accounts with a UID of 0 afford more opportunity for potential intruders to guess a password for a privileged account. Proper configuration of sudo is recommended to afford multiple system administrators access to root privileges in an accountable manner.     Root Path Must Be Vendor Default Assuming root shell is bash, edit the following files: 
    ~/.profile
    ~/.bashrc
    Change any PATH variables to the vendor default for root and remove any empty PATH entries or references to relative paths.     To view the root user's PATH, run the following command: 
    $ sudo env | grep PATH
    If correctly configured, the PATH must: use vendor default settings, have no empty entries, and have no entries beginning with a character other than a slash (/).     The root account's executable search path must be the vendor default, and must contain only absolute paths.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/accounts/session.xml000066400000000000000000000407041301675746700263060ustar00rootroot00000000000000 Secure Session Configuration Files for Login Accounts When a user logs into a Unix account, the system configures the user's session by reading a number of files. Many of these files are located in the user's home directory, and may have weak permissions as a result of user error or misconfiguration. If an attacker can modify or even read certain types of account configuration information, they can often gain full access to the affected user's account. Therefore, it is important to test and correct configuration file permissions for interactive accounts, particularly those of privileged users such as root or system administrators. Maximum concurrent login sessions Maximum number of concurrent sessions by a user 1 1 3 5 10 15 20 Maximum login attempts delay Maximum time in seconds between fail login attempts before re-prompting. 4 1 2 3 4 5 Account Inactivity Timeout (minutes) In an interactive shell, the value is interpreted as the number of seconds to wait for input after issueing the primary prompt. Bash terminates after waiting for that number of seconds if input does not arrive. 600 300 600 900 Set Interactive Session Timeout Setting the TMOUT option in /etc/profile ensures that RHEL7 will terminate all user sessions based on inactivity. Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. Run the following command to ensure the TMOUT value is configured for all users on the system: 
    $ sudo grep TMOUT /etc/profile
         Limit the Number of Concurrent Login Sessions Allowed Per User Limiting the number of allowed users and sessions per user can limit risks related to Denial of Service attacks. This addresses concurrent sessions for a single account and does not address concurrent sessions by a single user via multiple accounts. To set the number of concurrent sessions per user add the following line in /etc/security/limits.conf: 
    * hard maxlogins
    Limiting simultaneous user logins can insulate the system from denial of service problems caused by excessive logins. Automated login processes operating improperly or maliciously may result in an exceptional number of simultaneous login sessions. Run the following command to ensure the maxlogins value is configured for all users on the system: 
    # grep "maxlogins" /etc/security/limits.conf
    You should receive output similar to the following: 
    *		hard	maxlogins
    Ensure the Logon Failure Delay is Set Correctly in login.defs To ensure the logon failure delay controlled by /etc/login.defs is set properly, add or correct the FAIL_DELAY setting in /etc/login.defs to read as follows: 
    FAIL_DELAY
    Verify the FAIL_DELAY setting is configured correctly in the /etc/login.defs file by running the following command: 
    $ sudo grep -i "FAIL_DELAY" /etc/login.defs
    All output must show the value of FAIL_DELAY set as shown in the below: 
    $ sudo grep -i "FAIL_DELAY" /etc/login.defs
fail_delay
    Increasing the time between a failed authentication attempt and re-prompting to enter credentials helps to slow a single-threaded brute force attack.     Ensure that No Dangerous Directories Exist in Root's Path The active path of the root account can be obtained by starting a new root shell and running: 
    # echo $PATH
    This will produce a colon-separated list of directories in the path.

    Certain path elements could be considered dangerous, as they could lead to root executing unknown or untrusted programs, which could contain malicious code. Since root may sometimes work inside untrusted directories, the . character, which represents the current directory, should never be in the root path, nor should any directory which can be written to by an unprivileged or semi-privileged (system) user.

    It is a good practice for administrators to always execute privileged commands by typing the full path to the command.     Ensure that Root's Path Does Not Include Relative Paths or Null Directories Ensure that none of the directories in root's path is equal to a single . character, or that it contains any instances that lead to relative path traversal, such as .. or beginning a path without the slash (/) character. Also ensure that there are no "empty" elements in the path, such as in these examples: 
    PATH=:/bin
PATH=/bin:
PATH=/bin::/sbin
    These empty elements have the same effect as a single . character.     Including these entries increases the risk that root could execute code from an untrusted location.     Ensure that Root's Path Does Not Include World or Group-Writable Directories For each element in root's path, run: 
    # ls -ld DIR
    and ensure that write permissions are disabled for group and other.     To ensure write permissions are disabled for group and other for each element in root's path, run the following command: 
    # ls -ld DIR
     Such entries increase the risk that root could execute code provided by unprivileged users, and potentially malicious code.     Ensure that User Home Directories are not Group-Writable or World-Readable For each human user of the system, view the permissions of the user's home directory: 
    # ls -ld /home/USER
    Ensure that the directory is not group-writable and that it is not world-readable. If necessary, repair the permissions: 
    # chmod g-w /home/USER
# chmod o-rwx /home/USER
     To ensure the user home directory is not group-writable or world-readable, run the following: 
    # ls -ld /home/USER
     This action may involve modifying user home directories. Notify your user community, and solicit input if appropriate, before making this type of change. User home directories contain many configuration files which affect the behavior of a user's account. No user should ever have write permission to another user's home directory. Group shared directories can be configured in sub-directories or elsewhere in the filesystem if they are needed. Typically, user home directories should not be world-readable, as it would disclose file names to other users. If a subset of users need read access to one another's home directories, this can be provided using groups or ACLs.     Ensure that Users Have Sensible Umask Values The umask setting controls the default permissions for the creation of new files. With a default umask setting of 077, files and directories created by users will not be readable by any other user on the system. Users who wish to make specific files group- or world-readable can accomplish this by using the chmod command. Additionally, users can make all their files readable to their group by default by setting a umask of 027 in their shell configuration files. If default per-user groups exist (that is, if every user has a default group whose name is the same as that user's username and whose only member is the user), then it may even be safe for users to select a umask of 007, making it very easy to intentionally share files with groups of which the user is a member.

    Sensible umask Enter default user umask 027 007 022 027 077 Ensure the Default Bash Umask is Set Correctly To ensure the default umask for users of the Bash shell is set properly, add or correct the umask setting in /etc/bashrc to read as follows: 
    umask
    The umask value influences the permissions assigned to files when they are created. A misconfigured umask value could result in files with excessive permissions that can be read or written to by unauthorized users. Verify the umask setting is configured correctly in the /etc/bashrc file by running the following command: 
    # grep "umask" /etc/bashrc
    All output must show the value of umask set as shown below: 
    # grep "umask" /etc/bashrc
umask 
umask
    Ensure the Default C Shell Umask is Set Correctly To ensure the default umask for users of the C shell is set properly, add or correct the umask setting in /etc/csh.cshrc to read as follows: 
    umask
    The umask value influences the permissions assigned to files when they are created. A misconfigured umask value could result in files with excessive permissions that can be read or written to by unauthorized users. Verify the umask setting is configured correctly in the /etc/csh.cshrc file by running the following command: 
    # grep "umask" /etc/csh.cshrc
    All output must show the value of umask set as shown in the below: 
    # grep "umask" /etc/csh.cshrc
umask
    Ensure the Default Umask is Set Correctly in /etc/profile To ensure the default umask controlled by /etc/profile is set properly, add or correct the umask setting in /etc/profile to read as follows: 
    umask
    The umask value influences the permissions assigned to files when they are created. A misconfigured umask value could result in files with excessive permissions that can be read or written to by unauthorized users. Verify the umask setting is configured correctly in the /etc/profile file by running the following command: 
    # grep "umask" /etc/profile
    All output must show the value of umask set as shown in the below: 
    # grep "umask" /etc/profile
umask
    Ensure the Default Umask is Set Correctly in login.defs To ensure the default umask controlled by /etc/login.defs is set properly, add or correct the UMASK setting in /etc/login.defs to read as follows: 
    UMASK
    The umask value influences the permissions assigned to files when they are created. A misconfigured umask value could result in files with excessive permissions that can be read and written to by unauthorized users. Verify the UMASK setting is configured correctly in the /etc/login.defs file by running the following command: 
    # grep -i "UMASK" /etc/login.defs
    All output must show the value of umask set as shown in the below: 
    # grep -i "UMASK" /etc/login.defs
umask
    scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/auditing.xml000066400000000000000000002700571301675746700246160ustar00rootroot00000000000000 System Accounting with <tt>auditd</tt> The audit service provides substantial capabilities for recording system activities. By default, the service audits about SELinux AVC denials and certain types of security-relevant events such as system logins, account modifications, and authentication events performed by programs such as sudo. Under its default configuration, auditd has modest disk space requirements, and should not noticeably impact system performance.
    NOTE: The Linux Audit daemon auditd can be configured to use the augenrules program to read audit rules files (*.rules) located in /etc/audit/rules.d location and compile them to create the resulting form of the /etc/audit/audit.rules configuration file during the daemon startup (default configuration). Alternatively, the auditd daemon can use the auditctl utility to read audit rules from the /etc/audit/audit.rules configuration file during daemon startup, and load them into the kernel. The expected behavior is configured via the appropriate ExecStartPost directive setting in the /usr/lib/systemd/system/auditd.service configuration file. To instruct the auditd daemon to use the augenrules program to read audit rules (default configuration), use the following setting: 
    ExecStartPost=-/sbin/augenrules --load
    in the /usr/lib/systemd/system/auditd.service configuration file. In order to instruct the auditd daemon to use the auditctl utility to read audit rules, use the following setting: 
    ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rules
    in the /usr/lib/systemd/system/auditd.service configuration file. Refer to [Service] section of the /usr/lib/systemd/system/auditd.service configuration file for further details.
    Government networks often have substantial auditing requirements and auditd can be configured to meet these requirements. Examining some example audit records demonstrates how the Linux audit system satisfies common requirements. The following example from Fedora Documentation available at https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/SELinux_Users_and_Administrators_Guide/sect-Security-Enhanced_Linux-Troubleshooting-Fixing_Problems.html#sect-Security-Enhanced_Linux-Fixing_Problems-Raw_Audit_Messages shows the substantial amount of information captured in a two typical "raw" audit messages, followed by a breakdown of the most important fields. In this example the message is SELinux-related and reports an AVC denial (and the associated system call) that occurred when the Apache HTTP Server attempted to access the /var/www/html/file1 file (labeled with the samba_share_t type): 
    type=AVC msg=audit(1226874073.147:96): avc:  denied  { getattr } for pid=2465 comm="httpd"
path="/var/www/html/file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file

type=SYSCALL msg=audit(1226874073.147:96): arch=40000003 syscall=196 success=no exit=-13
a0=b98df198 a1=bfec85dc a2=54dff4 a3=2008171 items=0 ppid=2463 pid=2465 auid=502 uid=48
gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=6 comm="httpd"
exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
    • msg=audit(1226874073.147:96)
      • The number in parentheses is the unformatted time stamp (Epoch time) for the event, which can be converted to standard time by using the date command.
    • { getattr }
      • The item in braces indicates the permission that was denied. getattr indicates the source process was trying to read the target file's status information. This occurs before reading files. This action is denied due to the file being accessed having the wrong label. Commonly seen permissions include getattr, read, and write.
    • comm="httpd"
      • The executable that launched the process. The full path of the executable is found in the exe= section of the system call (SYSCALL) message, which in this case, is exe="/usr/sbin/httpd".
    • path="/var/www/html/file1"
      • The path to the object (target) the process attempted to access.
    • scontext="unconfined_u:system_r:httpd_t:s0"
      • The SELinux context of the process that attempted the denied action. In this case, it is the SELinux context of the Apache HTTP Server, which is running in the httpd_t domain.
    • tcontext="unconfined_u:object_r:samba_share_t:s0"
      • The SELinux context of the object (target) the process attempted to access. In this case, it is the SELinux context of file1. Note: the samba_share_t type is not accessible to processes running in the httpd_t domain.
    • From the system call (SYSCALL) message, two items are of interest:
      • success=no: indicates whether the denial (AVC) was enforced or not. success=no indicates the system call was not successful (SELinux denied access). success=yes indicates the system call was successful - this can be seen for permissive domains or unconfined domains, such as initrc_t and kernel_t.
      • exe="/usr/sbin/httpd": the full path to the executable that launched the process, which in this case, is exe="/usr/sbin/httpd".
    Enable auditd Service The auditd service is an essential userspace component of the Linux Auditing System, as it is responsible for writing audit records to disk. Without establishing what type of events occurred, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack.
    Ensuring the auditd service is active ensures audit records generated by the kernel are appropriately recorded.     Enable Auditing for Processes Which Start Prior to the Audit Daemon To ensure all processes can be audited, even those which start prior to the audit daemon, add the argument audit=1 to the default GRUB 2 command line for the Linux operating system in /etc/default/grub, in the manner below: 
    GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=VolGroup/LogVol06 rd.lvm.lv=VolGroup/lv_swap rhgb quiet rd.shell=0 audit=1"
     Inspect the form of default GRUB 2 command line for the Linux operating system in /etc/default/grub. If they include audit=1, then auditing is enabled at boot time. Each process on the system carries an "auditable" flag which indicates whether its activities can be audited. Although auditd takes care of enabling this for all processes which launch after it does, adding the kernel argument ensures it is set for every process during boot. The GRUB 2 configuration file, grub.cfg, is automatically updated each time a new kernel is installed. Note that any changes to /etc/default/grub require rebuilding the grub.cfg file. To update the GRUB 2 configuration file manually, use the 
    grub2-mkconfig -o
    command as follows:
    • On BIOS-based machines, issue the following command as root: 
      ~]# grub2-mkconfig -o /boot/grub2/grub.cfg
    • On UEFI-based machines, issue the following command as root: 
      ~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
         Configure <tt>auditd</tt> Data Retention The audit system writes data to /var/log/audit/audit.log. By default, auditd rotates 5 logs by size (6MB), retaining a maximum of 30MB of data in total, and refuses to write entries when the disk is too full. This minimizes the risk of audit data filling its partition and impacting other services. This also minimizes the risk of the audit daemon temporarily disabling the system if it cannot write audit log (which it can be configured to do). For a busy system or a system which is thoroughly auditing system activity, the default settings for data retention may be insufficient. The log file size needed will depend heavily on what types of events are being audited. First configure auditing to log all the events of interest. Then monitor the log size manually for awhile to determine what file size will allow you to keep the required data for the correct time period.

    Using a dedicated partition for /var/log/audit prevents the auditd logs from disrupting system functionality if they fill, and, more importantly, prevents other activity in /var from filling the partition and stopping the audit trail. (The audit logs are size-limited and therefore unlikely to grow without bound unless configured to do so.) Some machines may have requirements that no actions occur which cannot be audited. If this is the case, then auditd can be configured to halt the machine if it runs out of space. Note: Since older logs are rotated, configuring auditd this way does not prevent older logs from being rotated away before they can be viewed. If your system is configured to halt when logging cannot be performed, make sure this can never happen under normal circumstances! Ensure that /var/log/audit is on its own partition, and that this partition is larger than the maximum amount of data auditd will retain normally.     Number of log files for auditd to retain The setting for num_logs in /etc/audit/auditd.conf 5 5 4 3 2 1 0 Maximum audit log file size for auditd The setting for max_log_size in /etc/audit/auditd.conf 6 20 10 6 5 1 Action for auditd to take when log files reach their maximum size The setting for max_log_file_action in /etc/audit/auditd.conf rotate ignore syslog suspend rotate keep_logs Action for auditd to take when disk space just starts to run low The setting for space_left_action in /etc/audit/auditd.conf email ignore syslog email exec suspend single halt Action for auditd to take when disk space just starts to run low The setting for space_left_action in /etc/audit/auditd.conf single ignore syslog email exec suspend single halt Account for auditd to send email when actions occurs The setting for action_mail_acct in /etc/audit/auditd.conf root root admin Auditd priority for flushing data to disk The setting for flush in /etc/audit/auditd.conf data none incremental data sync Configure auditd Number of Logs Retained Determine how many log files auditd should retain when it rotates logs. Edit the file /etc/audit/auditd.conf. Add or modify the following line, substituting NUMLOGS with the correct value of : 
    num_logs = NUMLOGS
    Set the value to 5 for general-purpose systems. Note that values less than 2 result in no log rotation.     Inspect /etc/audit/auditd.conf and locate the following line to determine how many logs the system is configured to retain after rotation: $ sudo grep num_logs /etc/audit/auditd.conf 
    num_logs = 5
     The total storage for audit log files must be large enough to retain log information over the period required. This is a function of the maximum log file size and the number of logs retained.     Configure auditd Max Log File Size Determine the amount of audit data (in megabytes) which should be retained in each log file. Edit the file /etc/audit/auditd.conf. Add or modify the following line, substituting the correct value of for STOREMB: 
    max_log_file = STOREMB
    Set the value to 6 (MB) or higher for general-purpose systems. Larger values, of course, support retention of even more audit data.     Inspect /etc/audit/auditd.conf and locate the following line to determine how much data the system will retain in each audit log file: $ sudo grep max_log_file /etc/audit/auditd.conf 
    max_log_file = 6
     The total storage for audit log files must be large enough to retain log information over the period required. This is a function of the maximum log file size and the number of logs retained.     Configure auditd max_log_file_action Upon Reaching Maximum Log Size The default action to take when the logs reach their maximum size is to rotate the log files, discarding the oldest one. To configure the action taken by auditd, add or correct the line in /etc/audit/auditd.conf: 
    max_log_file_action = ACTION
    Possible values for ACTION are described in the auditd.conf man page. These include:
    • ignore
    • syslog
    • suspend
    • rotate
    • keep_logs
    Set the ACTION to rotate to ensure log rotation occurs. This is the default. The setting is case-insensitive.     Inspect /etc/audit/auditd.conf and locate the following line to determine if the system is configured to rotate logs when they reach their maximum size: $ sudo grep max_log_file_action /etc/audit/auditd.conf 
    max_log_file_action rotate
     Automatically rotating logs (by setting this to rotate) minimizes the chances of the system unexpectedly running out of disk space by being overwhelmed with log data. However, for systems that must never discard log data, or which use external processes to transfer it and reclaim space, keep_logs can be employed.     Configure auditd space_left Action on Low Disk Space The auditd service can be configured to take an action when disk space starts to run low. Edit the file /etc/audit/auditd.conf. Modify the following line, substituting ACTION appropriately: 
    space_left_action = ACTION
    Possible values for ACTION are described in the auditd.conf man page. These include:
    • ignore
    • syslog
    • email
    • exec
    • suspend
    • single
    • halt
    Set this to email (instead of the default, which is suspend) as it is more likely to get prompt attention. Acceptable values also include suspend, single, and halt.     Inspect /etc/audit/auditd.conf and locate the following line to determine if the system is configured to email the administrator when disk space is starting to run low: $ sudo grep space_left_action /etc/audit/auditd.conf 
    space_left_action
    Acceptable values are email, suspend, single, and halt.     Notifying administrators of an impending disk space problem may allow them to take corrective action prior to any disruption.     Configure auditd admin_space_left Action on Low Disk Space The auditd service can be configured to take an action when disk space is running low but prior to running out of space completely. Edit the file /etc/audit/auditd.conf. Add or modify the following line, substituting ACTION appropriately: 
    admin_space_left_action = ACTION
    Set this value to single to cause the system to switch to single user mode for corrective action. Acceptable values also include suspend and halt. For certain systems, the need for availability outweighs the need to log all actions, and a different setting should be determined. Details regarding all possible values for ACTION are described in the auditd.conf man page.     Inspect /etc/audit/auditd.conf and locate the following line to determine if the system is configured to either suspend, switch to single user mode, or halt when disk space has run low: 
    admin_space_left_action single
     Administrators should be made aware of an inability to record audit records. If a separate partition or logical volume of adequate size is used, running low on space for audit records should never occur.     Configure auditd mail_acct Action on Low Disk Space The auditd service can be configured to send email to a designated account in certain situations. Add or correct the following line in /etc/audit/auditd.conf to ensure that administrators are notified via email for those situations: 
    action_mail_acct =
    Inspect /etc/audit/auditd.conf and locate the following line to determine if the system is configured to send email to an account when it needs to notify an administrator: 
    action_mail_acct = root
     Email sent to the root account is typically aliased to the administrators of the system, who can take appropriate action.     Configure auditd flush priority The auditd service can be configured to synchronously write audit event data to disk. Add or correct the following line in /etc/audit/auditd.conf to ensure that audit event data is fully synchronized with the log files on the disk: 
    flush =
    Inspect /etc/audit/auditd.conf and locate the following line to determine if the system is configured to synchronize audit event data with the log files on the disk: $ sudo grep flush /etc/audit/auditd.conf 
    flush = DATA
    Acceptable values are DATA, and SYNC. The setting is case-insensitive.     Audit data should be synchronously written to disk to ensure log integrity. These parameters assure that all audit event data is fully synchronized with the log files on the disk.     Configure auditd to use audispd's syslog plugin To configure the auditd service to use the syslog plug-in of the audispd audit event multiplexor, set the active line in /etc/audisp/plugins.d/syslog.conf to yes. Restart the auditd service: 
    $ sudo service auditd restart
     To verify the audispd's syslog plugin is active, run the following command: 
    $ sudo grep active /etc/audisp/plugins.d/syslog.conf
    If the plugin is active, the output will show yes.     The auditd service does not include the ability to send audit records to a centralized server for management directly. It does, however, include a plug-in for audit event multiplexor (audispd) to pass audit records to the local syslog server     Configure <tt>auditd</tt> Rules for Comprehensive Auditing The auditd program can perform comprehensive monitoring of system activity. This section describes recommended configuration settings for comprehensive auditing, but a full description of the auditing system's capabilities is beyond the scope of this guide. The mailing list linux-audit@redhat.com exists to facilitate community discussion of the auditing system.

    The audit subsystem supports extensive collection of events, including:
    • Tracing of arbitrary system calls (identified by name or number) on entry or exit.
    • Filtering by PID, UID, call success, system call argument (with some limitations), etc.
    • Monitoring of specific files for modifications to the file's contents or metadata.

    Auditing rules at startup are controlled by the file /etc/audit/audit.rules. Add rules to it to meet the auditing requirements for your organization. Each line in /etc/audit/audit.rules represents a series of arguments that can be passed to auditctl and can be individually tested during runtime. See documentation in /usr/share/doc/audit-VERSION and in the related man pages for more details.

    If copying any example audit rulesets from /usr/share/doc/audit-VERSION, be sure to comment out the lines containing arch= which are not appropriate for your system's architecture. Then review and understand the following rules, ensuring rules are activated as needed for the appropriate architecture.

    After reviewing all the rules, reading the following sections, and editing as needed, the new rules can be activated as follows: 
    $ sudo service auditd restart
     Records Events that Modify Date and Time Information Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time. All changes to the system time should be audited. Record attempts to alter time through adjtimex If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
    -a always,exit -F arch=b32 -S adjtimex -k audit_time_rules
    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S adjtimex -k audit_time_rules
    If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
    -a always,exit -F arch=b32 -S adjtimex -k audit_time_rules
    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S adjtimex -k audit_time_rules
    The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls: 
    -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k audit_time_rules
     Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited.     Record attempts to alter time through settimeofday If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
    -a always,exit -F arch=b32 -S settimeofday -k audit_time_rules
    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S settimeofday -k audit_time_rules
    If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
    -a always,exit -F arch=b32 -S settimeofday -k audit_time_rules
    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S settimeofday -k audit_time_rules
    The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls: 
    -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k audit_time_rules
     Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited.     Record Attempts to Alter Time Through stime If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d for both 32 bit and 64 bit systems: 
    -a always,exit -F arch=b32 -S stime -k audit_time_rules
    Since the 64 bit version of the "stime" system call is not defined in the audit lookup table, the corresponding "-F arch=b64" form of this rule is not expected to be defined on 64 bit systems (the aforementioned "-F arch=b32" stime rule form itself is sufficient for both 32 bit and 64 bit systems). If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file for both 32 bit and 64 bit systems: 
    -a always,exit -F arch=b32 -S stime -k audit_time_rules
    Since the 64 bit version of the "stime" system call is not defined in the audit lookup table, the corresponding "-F arch=b64" form of this rule is not expected to be defined on 64 bit systems (the aforementioned "-F arch=b32" stime rule form itself is sufficient for both 32 bit and 64 bit systems). The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined system calls: 
    -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k audit_time_rules
     If the system is not configured to audit time changes, this is a finding. If the system is 64-bit only, this is not applicable
     Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited.     Record Attempts to Alter Time Through clock_settime If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
    -a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=time-change
    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=time-change
    If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
    -a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=time-change
    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=time-change
    The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls: 
    -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k audit_time_rules
     Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited.     Record Attempts to Alter the localtime File If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
    -w /etc/localtime -p wa -k audit_time_rules
    If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
    -w /etc/localtime -p wa -k audit_time_rules
    The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport and should always be used.     To determine if the system is configured to audit attempts to alter time via the /etc/localtime file, run the following command: 
    $ sudo auditctl -l | grep "watch=/etc/localtime"
    If the system is configured to audit this activity, it will return a line.     Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited.     Record Events that Modify User/Group Information If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d, in order to capture events that modify account changes: 
    -w /etc/group -p wa -k audit_rules_usergroup_modification
-w /etc/passwd -p wa -k audit_rules_usergroup_modification
-w /etc/gshadow -p wa -k audit_rules_usergroup_modification
-w /etc/shadow -p wa -k audit_rules_usergroup_modification
-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

    If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file, in order to capture events that modify account changes: 
    -w /etc/group -p wa -k audit_rules_usergroup_modification
-w /etc/passwd -p wa -k audit_rules_usergroup_modification
-w /etc/gshadow -p wa -k audit_rules_usergroup_modification
-w /etc/shadow -p wa -k audit_rules_usergroup_modification
-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification
     To determine if the system is configured to audit account changes, run the following command: 
    auditctl -l | egrep '(/etc/passwd|/etc/shadow|/etc/group|/etc/gshadow|/etc/security/opasswd)'
    If the system is configured to watch for account changes, lines should be returned for each file specified (and with perm=wa for each).     In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy.     Record Events that Modify the System's Network Environment If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d, setting ARCH to either b32 or b64 as appropriate for your system: 
    -a always,exit -F arch=ARCH -S sethostname -S setdomainname -k audit_rules_networkconfig_modification
-w /etc/issue -p wa -k audit_rules_networkconfig_modification
-w /etc/issue.net -p wa -k audit_rules_networkconfig_modification
-w /etc/hosts -p wa -k audit_rules_networkconfig_modification
-w /etc/sysconfig/network -p wa -k audit_rules_networkconfig_modification
    If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file, setting ARCH to either b32 or b64 as appropriate for your system: 
    -a always,exit -F arch=ARCH -S sethostname -S setdomainname -k audit_rules_networkconfig_modification
-w /etc/issue -p wa -k audit_rules_networkconfig_modification
-w /etc/issue.net -p wa -k audit_rules_networkconfig_modification
-w /etc/hosts -p wa -k audit_rules_networkconfig_modification
-w /etc/sysconfig/network -p wa -k audit_rules_networkconfig_modification
     To determine if the system is configured to audit changes to its network configuration, run the following command: 
    auditctl -l | egrep '(/etc/issue|/etc/issue.net|/etc/hosts|/etc/sysconfig/network)'
    If the system is configured to watch for network configuration changes, a line should be returned for each file specified (and perm=wa should be indicated for each).     The network environment should not be modified by anything other than administrator action. Any change to network parameters should be audited.     System Audit Logs Must Have Mode 0640 or Less Permissive If log_group in /etc/audit/auditd.conf is set to a group other than the root group account, change the mode of the audit log files with the following command: 
    $ sudo chmod 0640 audit_file

    Otherwise, change the mode of the audit log files with the following command: 
    $ sudo chmod 0600 audit_file
     Run the following command to check the mode of the system audit logs: 
    $ sudo ls -l /var/log/audit
    Audit logs must be mode 0640 or less permissive.     If users can write to audit logs, audit trails can be modified or destroyed.     System Audit Logs Must Be Owned By Root Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. Record Events that Modify the System's Mandatory Access Controls If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
    -w /etc/selinux/ -p wa -k MAC-policy
    If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
    -w /etc/selinux/ -p wa -k MAC-policy
     To determine if the system is configured to audit changes to its SELinux configuration files, run the following command: 
    $ sudo auditctl -l | grep "dir=/etc/selinux"
    If the system is configured to watch for changes to its SELinux configuration, a line should be returned (including perm=wa indicating permissions that are watched).     The system's mandatory access policy (SELinux) should not be arbitrarily changed by anything other than administrator action. All changes to MAC policy should be audited.     Record Events that Modify the System's Discretionary Access Controls At a minimum the audit system should collect file permission changes for all users and root. Note that the "-F arch=b32" lines should be present even on a 64 bit system. These commands identify system calls for auditing. Even if the system is 64 bit it can still execute 32 bit system calls. Additionally, these rules can be configured in a number of ways while still achieving the desired effect. An example of this is that the "-S" calls could be split up and placed on separate lines, however, this is less efficient. Add the following to /etc/audit/audit.rules: 
    -a always,exit -F arch=b32 -S chmod -S fchmod -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod
    -a always,exit -F arch=b32 -S chown -S fchown -S fchownat -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod
    -a always,exit -F arch=b32 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
    If your system is 64 bit then these lines should be duplicated and the arch=b32 replaced with arch=b64 as follows: 
    -a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod
    -a always,exit -F arch=b64 -S chown -S fchown -S fchownat -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod
    -a always,exit -F arch=b64 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
     The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Record Events that Modify the System's Discretionary Access Controls - chmod At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
    -a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=4294967295 -k perm_mod
    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S chmod  -F auid>=1000 -F auid!=4294967295 -k perm_mod
    If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
    -a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=4294967295 -k perm_mod
    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S chmod  -F auid>=1000 -F auid!=4294967295 -k perm_mod
     The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.     Record Events that Modify the System's Discretionary Access Controls - chown At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
    -a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=4294967295 -k perm_mod
    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=4294967295 -k perm_mod
    If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
    -a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=4294967295 -k perm_mod
    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=4294967295 -k perm_mod
     The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.     Record Events that Modify the System's Discretionary Access Controls - fchmod At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
    -a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=4294967295 -k perm_mod
    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=4294967295 -k perm_mod
    If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
    -a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=4294967295 -k perm_mod
    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=4294967295 -k perm_mod
     The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.     Record Events that Modify the System's Discretionary Access Controls - fchmodat At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
    -a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod
    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod
    If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
    -a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod
    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod
     The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.     Record Events that Modify the System's Discretionary Access Controls - fchown At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
    -a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_mod
    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_mod
    If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
    -a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_mod
    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_mod
     The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.     Record Events that Modify the System's Discretionary Access Controls - fchownat At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
    -a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=4294967295 -k perm_mod
    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=4294967295 -k perm_mod
    If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
    -a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=4294967295 -k perm_mod
    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=4294967295 -k perm_mod
     The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.     Record Events that Modify the System's Discretionary Access Controls - fremovexattr At a minimum the audit system should collect file permission changes for all users and root.

    If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
    -a always,exit -F arch=b32 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod


    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod


    If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
    -a always,exit -F arch=b32 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod


    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
     The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.     Record Events that Modify the System's Discretionary Access Controls - fsetxattr At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
    -a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
    If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
    -a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
     The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.     Record Events that Modify the System's Discretionary Access Controls - lchown At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
    -a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod
    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod
    If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
    -a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod
    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod
     The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.     Record Events that Modify the System's Discretionary Access Controls - lremovexattr At a minimum the audit system should collect file permission changes for all users and root.

    If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
    -a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod


    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod


    If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
    -a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod


    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
     The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.     Record Events that Modify the System's Discretionary Access Controls - lsetxattr At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
    -a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
    If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
    -a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
     The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.     Record Events that Modify the System's Discretionary Access Controls - removexattr At a minimum the audit system should collect file permission changes for all users and root.

    If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
    -a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod


    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod


    If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
    -a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod


    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
     The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.     Record Events that Modify the System's Discretionary Access Controls - setxattr At a minimum the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
    -a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
    If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
    -a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
    If the system is 64 bit then also add the following line: 
    -a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
     The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.     Record Attempts to Alter Logon and Logout Events The audit system already collects login information for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d in order to watch for attempted manual edits of files involved in storing logon events: 
    -w /var/log/tallylog -p wa -k logins
-w /var/run/faillock/ -p wa -k logins
-w /var/log/lastlog -p wa -k logins
    If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file in order to watch for unattempted manual edits of files involved in storing logon events: 
    -w /var/log/tallylog -p wa -k logins
-w /var/run/faillock/ -p wa -k logins
-w /var/log/lastlog -p wa -k logins
     Manual editing of these files may indicate nefarious activity, such as an attacker attempting to remove evidence of an intrusion.     Record Attempts to Alter Process and Session Initiation Information The audit system already collects process information for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d in order to watch for attempted manual edits of files involved in storing such process information: 
    -w /var/run/utmp -p wa -k session
-w /var/log/btmp -p wa -k session
-w /var/log/wtmp -p wa -k session
    If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file in order to watch for attempted manual edits of files involved in storing such process information: 
    -w /var/run/utmp -p wa -k session
-w /var/log/btmp -p wa -k session
-w /var/log/wtmp -p wa -k session
     Manual editing of these files may indicate nefarious activity, such as an attacker attempting to remove evidence of an intrusion.     Ensure <tt>auditd</tt> Collects Unauthorized Access Attempts to Files (unsuccessful) At a minimum the audit system should collect unauthorized file accesses for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: 
    -a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k access
-a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k access
    If the system is 64 bit then also add the following lines: 
    -a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k access
-a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k access
    If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file: 
    -a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k access
-a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k access
    If the system is 64 bit then also add the following lines: 
    -a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k access
-a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k access
     To verify that the audit system collects unauthorized file accesses, run the following commands: 
    $ sudo grep EACCES /etc/audit/audit.rules
    $ sudo grep EPERM /etc/audit/audit.rules
     Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise.     Ensure <tt>auditd</tt> Collects Information on the Use of Privileged Commands At a minimum the audit system should collect the execution of privileged commands for all users and root. To find the relevant setuid / setgid programs, run the following command for each local partition PART: 
    $ sudo find PART -xdev -type f -perm -4000 -o -type f -perm -2000 2>/dev/null
    If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d for each setuid / setgid program on the system, replacing the SETUID_PROG_PATH part with the full path of that setuid / setgid program in the list: 
    -a always,exit -F path=SETUID_PROG_PATH -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged
    If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules for each setuid / setgid program on the system, replacing the SETUID_PROG_PATH part with the full path of that setuid / setgid program in the list: 
    -a always,exit -F path=SETUID_PROG_PATH -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged
     To verify that auditing of privileged command use is configured, run the following command for each local partition PART to find relevant setuid / setgid programs: 
    $ sudo find PART -xdev -type f -perm -4000 -o -type f -perm -2000 2>/dev/null
    Run the following command to verify entries in the audit rules for all programs found with the previous command: 
    $ sudo grep path /etc/audit/audit.rules
    It should be the case that all relevant setuid / setgid programs have a line in the audit rules.     Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threast.
    Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity.     Ensure <tt>auditd</tt> Collects Information on Exporting to Media (successful) At a minimum the audit system should collect media exportation events for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d, setting ARCH to either b32 or b64 as appropriate for your system: 
    -a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=4294967295 -k export
    If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file, setting ARCH to either b32 or b64 as appropriate for your system: 
    -a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=4294967295 -k export
     To verify that auditing is configured for all media exportation events, run the following command: 
    $ sudo auditctl -l | grep syscall | grep mount
     The unauthorized exportation of data to external media could result in an information leak where classified information, Privacy Act information, and intellectual property could be lost. An audit trail should be created each time a filesystem is mounted to help identify and guard against information loss.     Ensure <tt>auditd</tt> Collects File Deletion Events by User At a minimum the audit system should collect file deletion events for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d, setting ARCH to either b32 or b64 as appropriate for your system: 
    -a always,exit -F arch=ARCH -S rmdir -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k delete
    If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file, setting ARCH to either b32 or b64 as appropriate for your system: 
    -a always,exit -F arch=ARCH -S rmdir -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k delete
     Auditing file deletions will create an audit trail for files that are removed from the system. The audit trail could aid in system troubleshooting, as well as, detecting malicious processes that attempt to delete log files to conceal their presence.     Ensure <tt>auditd</tt> Collects System Administrator Actions At a minimum the audit system should collect administrator actions for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
    -w /etc/sudoers -p wa -k actions
    If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
    -w /etc/sudoers -p wa -k actions
     To verify that auditing is configured for system administrator actions, run the following command: 
    $ sudo auditctl -l | grep "watch=/etc/sudoers"
     The actions taken by system administrators should be audited to keep a record of what was executed on the system, as well as, for accountability purposes.     Ensure <tt>auditd</tt> Collects Information on Kernel Module Loading and Unloading If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d to capture kernel module loading and unloading events, setting ARCH to either b32 or b64 as appropriate for your system: 
    -w /usr/sbin/insmod -p x -k modules
-w /usr/sbin/rmmod -p x -k modules
-w /usr/sbin/modprobe -p x -k modules
-a always,exit -F arch=ARCH -S init_module -S delete_module -k modules
    If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file in order to capture kernel module loading and unloading events, setting ARCH to either b32 or b64 as appropriate for your system: 
    -w /usr/sbin/insmod -p x -k modules
-w /usr/sbin/rmmod -p x -k modules
-w /usr/sbin/modprobe -p x -k modules
-a always,exit -F arch=ARCH -S init_module -S delete_module -k modules
     The addition/removal of kernel modules can be used to alter the behavior of the kernel and potentially introduce malicious code into kernel space. It is important to have an audit trail of modules that have been introduced into the kernel.     Make the <tt>auditd</tt> Configuration Immutable If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d in order to make the auditd configuration immutable: 
    -e 2
    If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file in order to make the auditd configuration immutable: 
    -e 2
    With this setting, a reboot will be required to change any audit rules.     Making the audit configuration immutable prevents accidental as well as malicious modification of the audit rules, although it may be problematic if legitimate changes are needed during system operation     scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/logging.xml000066400000000000000000000464351301675746700244410ustar00rootroot00000000000000 Configure Syslog The syslog service has been the default Unix logging mechanism for many years. It has a number of downsides, including inconsistent log format, lack of authentication for received messages, and lack of authentication, encryption, or reliable transport for messages sent over a network. However, due to its long history, syslog is a de facto standard which is supported by almost all Unix applications.

    In Red Hat Enterprise Linux 7, rsyslog has replaced ksyslogd as the syslog daemon of choice, and it includes some additional security features such as reliable, connection-oriented (i.e. TCP) transmission of logs, the option to log to database formats, and the encryption of log data en route to a central logging server. This section discusses how to configure rsyslog for best effect, and how to use tools provided with the system to maintain and monitor logs.     Ensure rsyslog is Installed Rsyslog is installed by default. The rsyslog package provides the rsyslog daemon, which provides system logging services. Enable rsyslog Service The rsyslog service provides syslog-style logging by default on Red Hat Enterprise Linux 7. The rsyslog service must be running in order to provide logging services, which are essential to system administration. Ensure Proper Configuration of Log Files The file /etc/rsyslog.conf controls where log message are written. These are controlled by lines called rules, which consist of a selector and an action. These rules are often customized depending on the role of the system, the requirements of the environment, and whatever may enable the administrator to most effectively make use of log data. The default rules in Red Hat Enterprise Linux 7 are: 
    *.info;mail.none;authpriv.none;cron.none                /var/log/messages
authpriv.*                                              /var/log/secure
mail.*                                                  -/var/log/maillog
cron.*                                                  /var/log/cron
*.emerg                                                 *
uucp,news.crit                                          /var/log/spooler
local7.*                                                /var/log/boot.log
    See the man page rsyslog.conf(5) for more information. Note that the rsyslog daemon can be configured to use a timestamp format that some log processing programs may not understand. If this occurs, edit the file /etc/rsyslog.conf and add or edit the following line: 
    $ ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
     User who owns log files Specify user owner of all logfiles specified in /etc/rsyslog.conf. root group who owns log files Specify group owner of all logfiles specified in /etc/rsyslog.conf. root Ensure Log Files Are Owned By Appropriate User The owner of all log files written by rsyslog should be root. These log files are determined by the second part of each Rule line in /etc/rsyslog.conf and typically all appear in /var/log. For each log file LOGFILE referenced in /etc/rsyslog.conf, run the following command to inspect the file's owner: 
    $ ls -l LOGFILE
    If the owner is not root, run the following command to correct this: 
    $ sudo chown root LOGFILE
     The owner of all log files written by rsyslog should be root. These log files are determined by the second part of each Rule line in /etc/rsyslog.conf and typically all appear in /var/log. To see the owner of a given log file, run the following command: 
    $ ls -l LOGFILE
     The log files generated by rsyslog contain valuable information regarding system configuration, user authentication, and other such information. Log files should be protected from unauthorized access.     Ensure Log Files Are Owned By Appropriate Group The group-owner of all log files written by rsyslog should be root. These log files are determined by the second part of each Rule line in /etc/rsyslog.conf and typically all appear in /var/log. For each log file LOGFILE referenced in /etc/rsyslog.conf, run the following command to inspect the file's group owner: 
    $ ls -l LOGFILE
    If the owner is not root, run the following command to correct this: 
    $ sudo chgrp root LOGFILE
     The group-owner of all log files written by rsyslog should be root. These log files are determined by the second part of each Rule line in /etc/rsyslog.conf and typically all appear in /var/log. To see the group-owner of a given log file, run the following command: 
    $ ls -l LOGFILE
     The log files generated by rsyslog contain valuable information regarding system configuration, user authentication, and other such information. Log files should be protected from unauthorized access.     Ensure System Log Files Have Correct Permissions The file permissions for all log files written by rsyslog should be set to 600, or more restrictive. These log files are determined by the second part of each Rule line in /etc/rsyslog.conf and typically all appear in /var/log. For each log file LOGFILE referenced in /etc/rsyslog.conf, run the following command to inspect the file's permissions: 
    $ ls -l LOGFILE
    If the permissions are not 600 or more restrictive, run the following command to correct this: 
    $ sudo chmod 0600 LOGFILE
     The file permissions for all log files written by rsyslog should be set to 600, or more restrictive. These log files are determined by the second part of each Rule line in /etc/rsyslog.conf and typically all appear in /var/log. To see the permissions of a given log file, run the following command: 
    $ ls -l LOGFILE
    The permissions should be 600, or more restrictive.     Log files can contain valuable information regarding system configuration. If the system log files are not protected unauthorized users could change the logged data, eliminating their forensic value.     Rsyslog Logs Sent To Remote Host If system logs are to be useful in detecting malicious activities, it is necessary to send logs to a remote server. An intruder who has compromised the root account on a machine may delete the log entries which indicate that the system was attacked before they are seen by an administrator.

    However, it is recommended that logs be stored on the local host in addition to being sent to the loghost, especially if rsyslog has been configured to use the UDP protocol to send messages over a network. UDP does not guarantee reliable delivery, and moderately busy sites will lose log messages occasionally, especially in periods of high traffic which may be the result of an attack. In addition, remote rsyslog messages are not authenticated in any way by default, so it is easy for an attacker to introduce spurious messages to the central log server. Also, some problems cause loss of network connectivity, which will prevent the sending of messages to the central server. For all of these reasons, it is better to store log messages both centrally and on each host, so that they can be correlated if necessary.     Ensure Logs Sent To Remote Host To configure rsyslog to send logs to a remote log server, open /etc/rsyslog.conf and read and understand the last section of the file, which describes the multiple directives necessary to activate remote logging. Along with these other directives, the system can be configured to forward its logs to a particular log server by adding or correcting one of the following lines, substituting loghost.example.com appropriately. The choice of protocol depends on the environment of the system; although TCP and RELP provide more reliable message delivery, they may not be supported in all environments.
    To use UDP for log message delivery: 
    *.* @loghost.example.com

    To use TCP for log message delivery: 
    *.* @@loghost.example.com

    To use RELP for log message delivery: 
    *.* :omrelp:loghost.example.com
     To ensure logs are sent to a remote host, examine the file /etc/rsyslog.conf. If using UDP, a line similar to the following should be present: 
     *.* @loghost.example.com
    If using TCP, a line similar to the following should be present: 
     *.* @@loghost.example.com
    If using RELP, a line similar to the following should be present: 
     *.* :omrelp:loghost.example.com
     A log server (loghost) receives syslog messages from one or more systems. This data can be used as an additional log source in the event a system is compromised and its local logs are suspect. Forwarding log messages to a remote loghost also provides system administrators with a centralized place to view the status of multiple hosts within the enterprise.     Configure <tt>rsyslogd</tt> to Accept Remote Messages If Acting as a Log Server By default, rsyslog does not listen over the network for log messages. If needed, modules can be enabled to allow the rsyslog daemon to receive messages from other systems and for the system thus to act as a log server. If the machine is not a log server, then lines concerning these modules should remain commented out.

    Ensure rsyslog Does Not Accept Remote Messages Unless Acting As Log Server The rsyslog daemon should not accept remote messages unless the system acts as a log server. To ensure that it is not listening on the network, ensure the following lines are not found in /etc/rsyslog.conf: 
    $ModLoad imtcp
$InputTCPServerRun port
$ModLoad imudp
$UDPServerRun port
$ModLoad imrelp
$InputRELPServerRun port
     Any process which receives messages from the network incurs some risk of receiving malicious messages. This risk can be eliminated for rsyslog by configuring it not to listen on the network.     Enable rsyslog to Accept Messages via TCP, if Acting As Log Server The rsyslog daemon should not accept remote messages unless the system acts as a log server. If the system needs to act as a central log server, add the following lines to /etc/rsyslog.conf to enable reception of messages over TCP: 
    $ModLoad imtcp
$InputTCPServerRun 514
     If the system needs to act as a log server, this ensures that it can receive messages over a reliable TCP connection.     Enable rsyslog to Accept Messages via UDP, if Acting As Log Server The rsyslog daemon should not accept remote messages unless the system acts as a log server. If the system needs to act as a central log server, add the following lines to /etc/rsyslog.conf to enable reception of messages over UDP: 
    $ModLoad imudp
$UDPServerRun 514
     Many devices, such as switches, routers, and other Unix-like systems, may only support the traditional syslog transmission over UDP. If the system must act as a log server, this enables it to receive their messages as well.     Ensure All Logs are Rotated by <tt>logrotate</tt> Edit the file /etc/logrotate.d/syslog. Find the first line, which should look like this (wrapped for clarity): 
    /var/log/messages /var/log/secure /var/log/maillog /var/log/spooler \
  /var/log/boot.log /var/log/cron {
    Edit this line so that it contains a one-space-separated listing of each log file referenced in /etc/rsyslog.conf.

    All logs in use on a system must be rotated regularly, or the log files will consume disk space over time, eventually interfering with system operation. The file /etc/logrotate.d/syslog is the configuration file used by the logrotate program to maintain all log files written by syslog. By default, it rotates logs weekly and stores four archival copies of each log. These settings can be modified by editing /etc/logrotate.conf, but the defaults are sufficient for purposes of this guide.

    Note that logrotate is run nightly by the cron job /etc/cron.daily/logrotate. If particularly active logs need to be rotated more often than once a day, some other mechanism must be used.     Ensure Logrotate Runs Periodically The logrotate utility allows for the automatic rotation of log files. The frequency of rotation is specified in /etc/logrotate.conf, which triggers a cron task. To configure logrotate to run daily, add or correct the following line in /etc/logrotate.conf: 
    # rotate log files frequency
daily
     Log files that are not properly rotated run the risk of growing so large that they fill up the /var/log partition. Valuable logging information could be lost if the /var/log partition becomes full. To determine the status and frequency of logrotate, run the following command: 
    $ sudo grep logrotate /var/log/cron*
    If logrotate is configured properly, output should include references to /etc/cron.daily.     Configure Logwatch on the Central Log Server Is this machine the central log server? If so, edit the file /etc/logwatch/conf/logwatch.conf as shown below. Configure Logwatch HostLimit Line On a central logserver, you want Logwatch to summarize all syslog entries, including those which did not originate on the logserver itself. The HostLimit setting tells Logwatch to report on all hosts, not just the one on which it is running. 
     HostLimit = no
    Configure Logwatch SplitHosts Line If SplitHosts is set, Logwatch will separate entries by hostname. This makes the report longer but significantly more usable. If it is not set, then Logwatch will not report which host generated a given log entry, and that information is almost always necessary 
     SplitHosts = yes
    Disable Logwatch on Clients if a Logserver Exists Does your site have a central logserver which has been configured to report on logs received from all systems? If so: 
     
$ sudo rm /etc/cron.daily/0logwatch
    If no logserver exists, it will be necessary for each machine to run Logwatch individually. Using a central logserver provides the security and reliability benefits discussed earlier, and also makes monitoring logs easier and less time-intensive for administrators.         scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/network/000077500000000000000000000000001301675746700237465ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/network/firewalld.xml000066400000000000000000000337011301675746700264450ustar00rootroot00000000000000 firewalld The dynamic firewall daemon firewalld provides a dynamically managed firewall with support for network “zones†to assign a level of trust to a network and its associated connections and interfaces. It has support for IPv4 and IPv6 firewall settings. It supports Ethernet bridges and has a separation of runtime and permanent configuration options. It also has an interface for services or applications to add firewall rules directly.
    A graphical configuration tool, firewall-config, is used to configure firewalld, which in turn uses iptables tool to communicate with Netfilter in the kernel which implements packet filtering.
    The firewall service provided by firewalld is dynamic rather than static because changes to the configuration can be made at anytime and are immediately implemented. There is no need to save or apply the changes. No unintended disruption of existing network connections occurs as no part of the firewall has to be reloaded.     Inspect and Activate Default firewalld Rules Firewalls can be used to separate networks into different zones based on the level of trust the user has decided to place on the devices and traffic within that network. NetworkManager informs firewalld to which zone an interface belongs. An interface's assigned zone can be changed by NetworkManager or via the firewall-config tool.
    The zone settings in /etc/firewalld/ are a range of preset settings which can be quickly applied to a network interface. These are the zones provided by firewalld sorted according to the default trust level of the zones from untrusted to trusted:
    • drop

      Any incoming network packets are dropped, there is no reply. Only outgoing network connections are possible.

    • block

      Any incoming network connections are rejected with an icmp-host-prohibited message for IPv4 and icmp6-adm-prohibited for IPv6. Only network connections initiated from within the system are possible.

    • public

      For use in public areas. You do not trust the other computers on the network to not harm your computer. Only selected incoming connections are accepted.

    • external

      For use on external networks with masquerading enabled especially for routers. You do not trust the other computers on the network to not harm your computer. Only selected incoming connections are accepted.

    • dmz

      For computers in your demilitarized zone that are publicly-accessible with limited access to your internal network. Only selected incoming connections are accepted.

    • work

      For use in work areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.

    • home

      For use in home areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.

    • internal

      For use on internal networks. You mostly trust the other computers on the networks to not harm your computer. Only selected incoming connections are accepted.

    • trusted

      All network connections are accepted.


    It is possible to designate one of these zones to be the default zone. When interface connections are added to NetworkManager, they are assigned to the default zone. On installation, the default zone in firewalld is set to be the public zone.
    To find out all the settings of a zone, for example the public zone, enter the following command as root: 
    # firewall-cmd --zone=public --list-all
    Example output of this command might look like the following: 
    # firewall-cmd --zone=public --list-all
public
  interfaces:
  services: mdns dhcpv6-client ssh
  ports:
  forward-ports:
  icmp-blocks: source-quench
    To view the network zones currently active, enter the following command as root: 
    # firewall-cmd --get-service
    The following listing displays the result of this command on common Red Hat Enterprise Linux 7 Server system: 
    # firewall-cmd --get-service
amanda-client bacula bacula-client dhcp dhcpv6 dhcpv6-client dns ftp
high-availability http https imaps ipp ipp-client ipsec kerberos kpasswd
ldap ldaps libvirt libvirt-tls mdns mountd ms-wbt mysql nfs ntp openvpn
pmcd pmproxy pmwebapi pmwebapis pop3s postgresql proxy-dhcp radius rpc-bind
samba samba-client smtp ssh telnet tftp tftp-client transmission-client
vnc-server wbem-https
    Finally to view the network zones that will be active after the next firewalld service reload, enter the following command as root: 
    # firewall-cmd --get-service --permanent
     Verify firewalld Enabled Access control methods provide the ability to enhance system security posture by restricting services and known good IP addresses and address ranges. This prevents connections from unknown hosts and protocols.     Strengthen the Default Ruleset The default rules can be strengthened. The system scripts that activate the firewall rules expect them to be defined in configuration files under the /etc/firewalld/services and /etc/firewalld/zones directories.

    The following recommendations describe how to strengthen the default ruleset configuration file. An alternative to editing this configuration file is to create a shell script that makes calls to the firewall-cmd program to load in rules under the /etc/firewalld/services and /etc/firewalld/zones directories.

    Instructions apply to both unless otherwise noted. Language and address conventions for regular firewalld rules are used throughout this section.     The program firewall-config allows additional services to penetrate the default firewall rules and automatically adjusts the firewalld ruleset(s). Set Default firewalld Zone for Incoming Packets To set the default zone to drop for the built-in default zone which processes incoming IPv4 and IPv6 packets, modify the following line in /etc/firewalld/firewalld.conf to be: 
    DefaultZone=drop
     Inspect the file /etc/firewalld/firewalld.conf to determine the default zone for the firewalld. It should be set to DefaultZone=drop: 
    $ sudo grep DefaultZone /etc/firewalld/firewalld.conf
     In firewalld the default zone is applied only after all the applicable rules in the table are examined for a match. Setting the default zone to drop implements proper design for a firewall, i.e. any packets which are not explicitly permitted should not be accepted.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/network/ipsec.xml000066400000000000000000000036541301675746700256030ustar00rootroot00000000000000 IPSec Support Support for Internet Protocol Security (IPsec) is provided in Red Hat Enterprise Linux 7 with Libreswan. Install libreswan Package The Libreswan package provides an implementation of IPsec and IKE, which permits the creation of secure tunnels over untrusted networks. Providing the ability for remote users or systems to initiate a secure VPN connection protects information when it is transmitted over a wide area network. Verify Any Configured IPSec Tunnel Connections Libreswan provides an implementation of IPsec and IKE, which permits the creation of secure tunnels over untrusted networks. As such, IPsec can be used to circumvent certain network requirements such as filtering. Verify that if any IPsec connection (conn) configured in /etc/ipsec.conf and /etc/ipsec.d exists is an approved organizational connection. To check for configured IPsec connections (conn), perform the following: 
    grep -rni conn /etc/ipsec.conf /etc/ipsec.d/
    Verify any returned results for organizational approval.     IP tunneling mechanisms can be used to bypass network filtering.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/network/ipv6.xml000066400000000000000000000375231301675746700253660ustar00rootroot00000000000000 IPv6 The system includes support for Internet Protocol version 6. A major and often-mentioned improvement over IPv4 is its enormous increase in the number of available addresses. Another important feature is its support for automatic configuration of many network settings. Disable Support for IPv6 Unless Needed Despite configuration that suggests support for IPv6 has been disabled, link-local IPv6 address auto-configuration occurs even when only an IPv4 address is assigned. The only way to effectively prevent execution of the IPv6 networking stack is to instruct the system not to activate the IPv6 kernel module. Disable IPv6 Networking Support Automatic Loading To disable support for (ipv6) add the following line to /etc/sysctl.d/ipv6.conf (or another file in /etc/sysctl.d): 
    net.ipv6.conf.all.disable_ipv6 = 1
    This disables IPv6 on all network interfaces as other services and system functionality require the IPv6 stack loaded to work.     If the system uses IPv6, this is not applicable.

    If the system is configured to prevent the usage of the ipv6 on network interfaces, it will contain a line of the form: 
    net.ipv6.conf.all.disable_ipv6 = 1
    Such lines may be inside any file in the /etc/sysctl.d directory. This permits insertion of the IPv6 kernel module (which other parts of the system expect to be present), but otherwise keeps all network interfaces from using IPv6. Run the following command to search for such lines in all files in /etc/sysctl.d: 
    $ grep -r ipv6 /etc/sysctl.d
     Any unnecessary network stacks - including IPv6 - should be disabled, to reduce the vulnerability to exploitation.     Disable Interface Usage of IPv6 To disable interface usage of IPv6, add or correct the following lines in /etc/sysconfig/network: 
    NETWORKING_IPV6=no
IPV6INIT=no
         Disable Support for RPC IPv6 RPC services for NFSv4 try to load transport modules for udp6 and tcp6 by default, even if IPv6 has been disabled in /etc/modprobe.d. To prevent RPC services such as rpc.mountd from attempting to start IPv6 network listeners, remove or comment out the following two lines in /etc/netconfig: 
    udp6       tpi_clts      v     inet6    udp     -       -
tcp6       tpi_cots_ord  v     inet6    tcp     -       -
         Configure IPv6 Settings if Necessary A major feature of IPv6 is the extent to which systems implementing it can automatically configure their networking devices using information from the network. From a security perspective, manually configuring important configuration information is preferable to accepting it from the network in an unauthenticated fashion. Disable Automatic Configuration Disable the system's acceptance of router advertisements and redirects by adding or correcting the following line in /etc/sysconfig/network (note that this does not disable sending router solicitations): 
    IPV6_AUTOCONF=no
     IPV6_AUTOCONF Toggle global IPv6 auto-configuration (only, if global forwarding is disabled) no yes no net.ipv6.conf.all.accept_source_route Trackers could be using source-routed packets to generate traffic that seems to be intra-net, but actually was created outside and has been redirected. 0 1 0 net.ipv6.conf.default.accept_ra Accept default router advertisements by default? 0 1 0 net.ipv6.conf.all.accept_ra Accept all router advertisements? 0 1 0 net.ipv6.conf.default.accept_redirects Toggle ICMP Redirect Acceptance By Default 0 1 0 net.ipv6.conf.all.accept_redirects Toggle ICMP Redirect Acceptance 0 1 0 net.ipv6.conf.default.accept_source_route Trackers could be using source-routed packets to generate traffic that seems to be intra-net, but actually was created outside and has been redirected. 0 1 0 net.ipv6.conf.all.forwarding Toggle IPv6 Forwarding 0 1 0 Configure Kernel Parameter for Accepting Source-Routed Packets for All Interfaces Source-routed packets allow the source of the packet to suggest routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routerd traffic, such as when IPv6 forwarding is enabled and the system is functioning as a router.

    Accepting source-routed packets in the IPv6 protocol has few legitimate uses. It should be disabled unless it is absolutely required.         Configure Accepting IPv6 Router Advertisements An illicit router advertisement message could result in a man-in-the-middle attack. Configure Accepting IPv6 Router Advertisements An illicit router advertisement message could result in a man-in-the-middle attack. Configure Accepting IPv6 Redirects By Default An illicit ICMP redirect message could result in a man-in-the-middle attack. Configure Accepting IPv6 Redirects By Default An illicit ICMP redirect message could result in a man-in-the-middle attack. Configure Kernel Parameter for Accepting Source-Routed Packets for Interfaces By Default Source-routed packets allow the source of the packet to suggest routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routerd traffic, such as when IPv6 forwarding is enabled and the system is functioning as a router. Accepting source-routed packets in the IPv6 protocol has few legitimate uses. It should be disabled unless it is absolutely required. Disable Kernel Parameter for IPv6 Forwarding The ability to forward packets is only appropriate for routers. IP forwarding permits the kernel to forward packets from one network interface to another. The ability to forward packets between two networks is only appropriate for systems acting as routers.     Manually Assign Global IPv6 Address To manually assign an IP address for an interface, edit the file /etc/sysconfig/network-scripts/ifcfg-interface. Add or correct the following line (substituting the correct IPv6 address): 
    IPV6ADDR=2001:0DB8::ABCD/64
    Manually assigning an IP address is preferable to accepting one from routers or from the network otherwise. The example address here is an IPv6 address reserved for documentation purposes, as defined by RFC3849.     Use Privacy Extensions for Address To introduce randomness into the automatic generation of IPv6 addresses, add or correct the following line in /etc/sysconfig/network-scripts/ifcfg-interface: 
    IPV6_PRIVACY=rfc3041
    Automatically-generated IPv6 addresses are based on the underlying hardware (e.g. Ethernet) address, and so it becomes possible to track a piece of hardware over its lifetime using its traffic. If it is important for a system's IP address to not trivially reveal its hardware address, this setting should be applied.     Manually Assign IPv6 Router Address Edit the file /etc/sysconfig/network-scripts/ifcfg-interface, and add or correct the following line (substituting your gateway IP as appropriate): 
    IPV6_DEFAULTGW=2001:0DB8::0001
    Router addresses should be manually set and not accepted via any auto-configuration or router advertisement.     Limit Network-Transmitted Configuration if Using Static IPv6 Addresses To limit the configuration information requested from other systems and accepted from the network on a system that uses statically-configured IPv6 addresses, add the following lines to /etc/sysctl.conf: 
    net.ipv6.conf.default.router_solicitations = 0
net.ipv6.conf.default.accept_ra_rtr_pref = 0
net.ipv6.conf.default.accept_ra_pinfo = 0
net.ipv6.conf.default.accept_ra_defrtr = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.default.dad_transmits = 0
net.ipv6.conf.default.max_addresses = 1
    The router_solicitations setting determines how many router solicitations are sent when bringing up the interface. If addresses are statically assigned, there is no need to send any solicitations.

    The accept_ra_pinfo setting controls whether the system will accept prefix info from the router.

    The accept_ra_defrtr setting controls whether the system will accept Hop Limit settings from a router advertisement. Setting it to 0 prevents a router from changing your default IPv6 Hop Limit for outgoing packets.

    The autoconf setting controls whether router advertisements can cause the system to assign a global unicast address to an interface.

    The dad_transmits setting determines how many neighbor solicitations to send out per address (global and link-local) when bringing up an interface to ensure the desired address is unique on the network.

    The max_addresses setting determines how many global unicast IPv6 addresses can be assigned to each interface. The default is 16, but it should be set to exactly the number of statically configured global addresses required.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/network/kernel.xml000066400000000000000000000472211301675746700257560ustar00rootroot00000000000000 Kernel Parameters Which Affect Networking The sysctl utility is used to set parameters which affect the operation of the Linux kernel. Kernel parameters which affect networking and have security implications are described here. Network Parameters for Hosts Only If the system is not going to be used as a router, then setting certain kernel parameters ensure that the host will not perform routing of network traffic. Disable Kernel Parameter for Sending ICMP Redirects by Default ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages contain information from the system's route table possibly revealing portions of the network topology.
    The ability to send ICMP redirects is only appropriate for systems acting as routers.     Disable Kernel Parameter for Sending ICMP Redirects for All Interfaces ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages contain information from the system's route table possibly revealing portions of the network topology.
    The ability to send ICMP redirects is only appropriate for systems acting as routers.     Disable Kernel Parameter for IP Forwarding The ability to forward packets is only appropriate for routers. Routing protocol daemons are typically used on routers to exchange network topology information with other routers. If this capability is used when not required, system network information may be unnecessarily transmitted across the network.     Network Related Kernel Runtime Parameters for Hosts and Routers Certain kernel parameters should be set for systems which are acting as either hosts or routers to improve the system's ability defend against certain types of IPv4 protocol attacks. net.ipv4.conf.all.accept_source_route Trackers could be using source-routed packets to generate traffic that seems to be intra-net, but actually was created outside and has been redirected. 0 1 0 net.ipv4.conf.all.accept_redirects Disable ICMP Redirect Acceptance 0 1 0 net.ipv4.conf.all.secure_redirects Enable to prevent hijacking of routing path by only allowing redirects from gateways known in routing table. 1 1 0 net.ipv4.conf.default.log_martians Disable so you don't Log Spoofed Packets, Source Routed Packets, Redirect Packets 1 1 0 net.ipv4.conf.all.log_martians Disable so you don't Log Spoofed Packets, Source Routed Packets, Redirect Packets 1 1 0 net.ipv4.conf.default.accept_source_route Disable IP source routing? 0 1 0 net.ipv4.conf.default.accept_redirects Disable ICMP Redirect Acceptance? 0 1 0 net.ipv4.conf.default.secure_redirects Log packets with impossible addresses to kernel log? 1 1 0 net.ipv4.icmp_echo_ignore_broadcasts Ignore all ICMP ECHO and TIMESTAMP requests sent to it via broadcast/multicast 1 1 0 net.ipv4.icmp_ignore_bogus_error_responses Enable to prevent unnecessary logging 1 1 0 net.ipv4.tcp_syncookies Enable to turn on TCP SYN Cookie Protection 1 1 0 net.ipv4.conf.all.rp_filter Enable to enforce sanity checking, also called ingress filtering or egress filtering. The point is to drop a packet if the source and destination IP addresses in the IP header do not make sense when considered in light of the physical interface on which it arrived. 1 1 0 net.ipv4.conf.default.rp_filter Enables source route verification 1 1 0 Configure Kernel Parameter for Accepting Source-Routed Packets for All Interfaces Source-routed packets allow the source of the packet to suggest routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routerd traffic, such as when IPv4 forwarding is enabled and the system is functioning as a router.

    Accepting source-routed packets in the IPv4 protocol has few legitimate uses. It should be disabled unless it is absolutely required.         Configure Kernel Parameter for Accepting ICMP Redirects for All Interfaces ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack.
    This feature of the IPv4 protocol has few legitimate uses. It should be disabled unless absolutely required.         Configure Kernel Parameter for Accepting Secure Redirects for All Interfaces Accepting "secure" ICMP redirects (from those gateways listed as default gateways) has few legitimate uses. It should be disabled unless it is absolutely required. Configure Kernel Parameter to Log Martian Packets The presence of "martian" packets (which have impossible addresses) as well as spoofed packets, source-routed packets, and redirects could be a sign of nefarious network activity. Logging these packets enables this activity to be detected. Configure Kernel Parameter to Log Martian Packets By Default The presence of "martian" packets (which have impossible addresses) as well as spoofed packets, source-routed packets, and redirects could be a sign of nefarious network activity. Logging these packets enables this activity to be detected. Configure Kernel Parameter for Accepting Source-Routed Packets By Default Source-routed packates allow the source of the packet to suggest routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures.
    Accepting source-routed packets in the IPv4 protocol has few legitimate uses. It should be disabled unless it is absolutely required, such as when IPv4 forwarding is enabled and the system is legitimately functioning as a router.         Configure Kernel Parameter for Accepting ICMP Redirects By Default ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack.
    This feature of the IPv4 protocol has few legitimate uses. It should be disabled unless absolutely required.         Configure Kernel Parameter for Accepting Secure Redirects By Default Accepting "secure" ICMP redirects (from those gateways listed as default gateways) has few legitimate uses. It should be disabled unless it is absolutely required. Configure Kernel Parameter to Ignore ICMP Broadcast Echo Requests Responding to broadcast (ICMP) echoes facilitates network mapping and provides a vector for amplification attacks.
    Ignoring ICMP echo requests (pings) sent to broadcast or multicast addresses makes the system slightly more difficult to enumerate on the network.     Configure Kernel Parameter to Ignore Bogus ICMP Error Responses Ignoring bogus ICMP error responses reduces log size, although some activity would not be logged. Configure Kernel Parameter to Use TCP Syncookies A TCP SYN flood attack can cause a denial of service by filling a system's TCP connection table with connections in the SYN_RCVD state. Syncookies can be used to track a connection when a subsequent ACK is received, verifying the initiator is attempting a valid connection and is not a flood source. This feature is activated when a flood condition is detected, and enables the system to continue servicing valid connection requests. Configure Kernel Parameter to Use Reverse Path Filtering for All Interfaces Enabling reverse path filtering drops packets with source addresses that should not have been able to be received on the interface they were received on. It should not be used on systems which are routers for complicated networks, but is helpful for end hosts and routers serving small networks. Configure Kernel Parameter to Use Reverse Path Filtering by Default Enabling reverse path filtering drops packets with source addresses that should not have been able to be received on the interface they were received on. It should not be used on systems which are routers for complicated networks, but is helpful for end hosts and routers serving small networks.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/network/network.xml000066400000000000000000000120721301675746700261630ustar00rootroot00000000000000 Network Configuration and Firewalls Most machines must be connected to a network of some sort, and this brings with it the substantial risk of network attack. This section discusses the security impact of decisions about networking which must be made when configuring a system.

    This section also discusses firewalls, network access controls, and other network security frameworks, which allow system-level rules to be written that can limit an attackers' ability to connect to your system. These rules can specify that network traffic should be allowed or denied from certain IP addresses, hosts, and networks. The rules can also specify which of the system's network services are available to particular hosts or networks.     Disable Unused Interfaces Network interfaces expand the attack surface of the system. Unused interfaces are not monitored or controlled, and should be disabled.

    If the system does not require network communications but still needs to use the loopback interface, remove all files of the form ifcfg-interface except for ifcfg-lo from /etc/sysconfig/network-scripts: 
    $ sudo rm /etc/sysconfig/network-scripts/ifcfg-interface
    If the system is a standalone machine with no need for network access or even communication over the loopback device, then disable this service.     Disable Client Dynamic DNS Updates Dynamic DNS allows clients to dynamically update their own DNS records. The updates are transmitted by unencrypted means which can reveal information to a potential malicious user. If the system does not require Dynamic DNS, remove all DHCP_HOSTNAME references from the /etc/sysconfig/network-scripts/ifcfg-interface scripts. If dhclient is used, remove all send host-name hostname references from the /etc/dhclient.conf configuration file and/or any reference from the /etc/dhcp directory. To verify that clients cannot automatically update DNS records, perform the following: 
    $ grep -i dhcp_hostname /etc/sysconfig/network-scripts/ifcfg-*
    $ grep -rni "send host-name" /etc/dhclient.conf /etc/dhcp
    The output should return no results.     Dynamic DNS updates transmit unencrypted information about a system including its name and address and should not be used unless needed.     Disable Zeroconf Networking Zeroconf networking allows the system to assign itself an IP address and engage in IP communication without a statically-assigned address or even a DHCP server. Automatic address assignment via Zeroconf (or DHCP) is not recommended. To disable Zeroconf automatic route assignment in the 169.254.0.0 subnet, add or correct the following line in /etc/sysconfig/network: 
    NOZEROCONF=yes
     Zeroconf addresses are in the network 169.254.0.0. The networking scripts add entries to the system's routing table for these addresses. Zeroconf address assignment commonly occurs when the system is configured to use DHCP but fails to receive an address assignment from the DHCP server.     Ensure System is Not Acting as a Network Sniffer The system should not be acting as a network sniffer, which can capture all traffic on the network to which it is connected. Run the following to determine if any interface is running in promiscuous mode: 
    $ ip link | grep PROMISC
     Promiscuous mode of an interface can be disabled with the following command: 
    $ sudo ip link set dev device_name promisc off
     Network interfaces in promiscuous mode allow for the capture of all network traffic visible to the system. If unauthorized individuals can access these applications, it may allow them to collect information such as logon IDs, passwords, and key exchanges between systems.

    If the system is being used to perform a network troubleshooting function, the use of these tools must be documented with the Information Systems Security Manager (ISSM) and restricted to only authorized personnel.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/network/ssl.xml000066400000000000000000000017401301675746700252730ustar00rootroot00000000000000 Transport Layer Security Support Support for Transport Layer Security (TLS), and its predecessor, the Secure Sockets Layer (SSL), is included in Red Hat Enterprise Linux in the OpenSSL software (RPM package openssl). TLS provides encrypted and authenticated network communications, and many network services include support for it. TLS or SSL can be leveraged to avoid any plaintext transmission of sensitive data.
    For information on how to use OpenSSL, see http://www.openssl.org/docs/HOWTO/. Information on FIPS validation of OpenSSL is available at http://www.openssl.org/docs/fips/fipsvalidation.html and http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm. For information on how to use and implement OpenSSL on Red Hat Enterprise Linux, see https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Using_OpenSSL.html     scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/network/uncommon.xml000066400000000000000000000035321301675746700263260ustar00rootroot00000000000000 Uncommon Network Protocols The system includes support for several network protocols which are not commonly used. Although security vulnerabilities in kernel networking code are not frequently discovered, the consequences can be dramatic. Ensuring uncommon network protocols are disabled reduces the system's risk to attacks targeted at its implementation of those protocols. Although these protocols are not commonly used, avoid disruption in your network environment by ensuring they are not needed prior to disabling them. Disable DCCP Support The Datagram Congestion Control Protocol (DCCP) is a relatively new transport layer protocol, designed to support streaming media and telephony. Disabling DCCP protects the system against exploitation of any flaws in its implementation. Disable SCTP Support The Stream Control Transmission Protocol (SCTP) is a transport layer protocol, designed to support the idea of message-oriented communication, with several streams of messages within one connection. Disabling SCTP protects the system against exploitation of any flaws in its implementation. scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/network/wireless.xml000066400000000000000000000115231301675746700263270ustar00rootroot00000000000000 Wireless Networking Wireless networking, such as 802.11 (WiFi) and Bluetooth, can present a security risk to sensitive or classified systems and networks. Wireless networking hardware is much more likely to be included in laptop or portable systems than in desktops or servers.

    Removal of hardware provides the greatest assurance that the wireless capability remains disabled. Acquisition policies often include provisions to prevent the purchase of equipment that will be used in sensitive spaces and includes wireless capabilities. If it is impractical to remove the wireless hardware, and policy permits the device to enter sensitive spaces as long as wireless is disabled, efforts should instead focus on disabling wireless capability via software.     Disable Wireless Through Software Configuration If it is impossible to remove the wireless hardware from the device in question, disable as much of it as possible through software. The following methods can disable software support for wireless networking, but note that these methods do not prevent malicious software or careless users from re-activating the devices. Disable WiFi or Bluetooth in BIOS Some systems that include built-in wireless support offer the ability to disable the device through the BIOS. This is system-specific; consult your hardware manual or explore the BIOS setup during boot. Disabling wireless support in the BIOS prevents easy activation of the wireless interface, generally requiring administrators to reboot the system first. Deactivate Wireless Network Interfaces Deactivating wireless network interfaces should prevent normal usage of the wireless capability.

    First, identify the interfaces available with the command: 
    $ ifconfig -a
    Additionally, the following command may be used to determine whether wireless support is included for a particular interface, though this may not always be a clear indicator: 
    $ iwconfig
    After identifying any wireless interfaces (which may have names like wlan0, ath0, wifi0, em1 or eth0), deactivate the interface with the command: 
    $ sudo ifdown interface
    These changes will only last until the next reboot. To disable the interface for future boots, remove the appropriate interface file from /etc/sysconfig/network-scripts: 
    $ sudo rm /etc/sysconfig/network-scripts/ifcfg-interface
     Wireless networking allows attackers within physical proximity to launch network-based attacks against systems, including those against local LAN protocols which were not designed with security in mind.     Disable Bluetooth Service 
    $ sudo service bluetooth stop
     Disabling the bluetooth service prevents the system from attempting connections to Bluetooth devices, which entails some security risk. Nevertheless, variation in this risk decision may be expected due to the utility of Bluetooth connectivity and its limited range.     Disable Bluetooth Kernel Modules The kernel's module loading system can be configured to prevent loading of the Bluetooth module. Add the following to the appropriate /etc/modprobe.d configuration file to prevent the loading of the Bluetooth module: 
    install bluetooth /bin/true
     If Bluetooth functionality must be disabled, preventing the kernel from loading the kernel module provides an additional safeguard against its activation.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/permissions/000077500000000000000000000000001301675746700246305ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/permissions/execution.xml000066400000000000000000000260101301675746700273540ustar00rootroot00000000000000 Restrict Programs from Dangerous Execution Patterns The recommendations in this section are designed to ensure that the system's features to protect against potentially dangerous program execution are activated. These protections are applied at the system initialization or kernel level, and defend against certain types of badly-configured or compromised programs. Daemon Umask The umask is a per-process setting which limits the default permissions for creation of new files and directories. The system includes initialization scripts which set the default umask for system daemons. daemon umask Enter umask for daemons 022 022 027 Set Daemon Umask The file /etc/init.d/functions includes initialization parameters for most or all daemons started at boot time. The default umask of 022 prevents creation of group- or world-writable files. To set the default umask for daemons, edit the following line, inserting 022 or 027 for UMASK appropriately: 
    umask
    Setting the umask to too restrictive a setting can cause serious errors at runtime. Many daemons on the system already individually restrict themselves to a umask of 077 in their own init scripts.     To check the value of the umask, run the following command: 
    $ grep umask /etc/init.d/functions
    The output should show either 022 or 027.     The umask influences the permissions assigned to files created by a process at run time. An unnecessarily permissive umask could result in files being created with insecure permissions.     Disable Core Dumps A core dump file is the memory image of an executable program when it was terminated by the operating system due to errant behavior. In most cases, only software developers legitimately need to access these files. The core dump files may also contain sensitive information, or unnecessarily occupy large amounts of disk space.

    Once a hard limit is set in /etc/security/limits.conf, a user cannot increase that limit within his or her own session. If access to core dumps is required, consider restricting them to only certain users or groups. See the limits.conf man page for more information.

    The core dumps of setuid programs are further protected. The sysctl variable fs.suid_dumpable controls whether the kernel allows core dumps from these programs at all. The default value of 0 is recommended.     Disable Core Dumps for All Users To disable core dumps for all users, add the following line to /etc/security/limits.conf: 
    *     hard   core    0
     To verify that core dumps are disabled for all users, run the following command: 
    $ grep core /etc/security/limits.conf
    The output should be: 
    *     hard   core    0
     A core dump includes a memory image taken at the time the operating system terminates an application. The memory image could contain sensitive data and is generally useful only for developers trying to debug problems.     Disable Core Dumps for SUID programs The core dump of a setuid program is more likely to contain sensitive data, as the program itself runs with greater privileges than the user who initiated execution of the program. Disabling the ability for any setuid program to write a core file decreases the risk of unauthorized access of such data.     Enable ExecShield ExecShield describes kernel features that provide protection against exploitation of memory corruption errors such as buffer overflows. These features include random placement of the stack and other memory regions, prevention of execution in memory that should only hold data, and special handling of text buffers. These protections are enabled by default on 32-bit systems and controlled through sysctl variables kernel.exec-shield and kernel.randomize_va_space. On the latest 64-bit systems, kernel.exec-shield cannot be enabled or disabled with sysctl. Enable ExecShield By default on Red Hat Enterprise Linux 7 64-bit systems, ExecShield is enabled and can only be disabled if the hardware does not support ExecShield or is disabled in /etc/default/grub. For Red Hat Enterprise Linux 7 32-bit systems, sysctl can be used to enable ExecShield. To verify ExecShield is enabled on 64-bit Red Hat Enterprise Linux 7 systems, run the following command: 
    $ dmesg | grep '[NX|DX]*protection'
    The output should not contain 'disabled by kernel command line option'. To verify that ExecShield has not been disabled in the kernel configuration, run the following command: 
    $ sudo grep noexec /boot/grub2/grub.cfg
    The output should not return noexec=off. For 32-bit Red Hat Enterprise Linux 7 systems, run the following command: 
    $ sysctl kernel.exec-shield
    The output should be:
    ExecShield uses the segmentation feature on all x86 systems to prevent execution in memory higher than a certain address. It writes an address as a limit in the code segment descriptor, to control where code can be executed, on a per-process basis. When the kernel places a process's memory regions such as the stack and heap higher than this address, the hardware prevents execution in that address range. This is enabled by default on the latest Red Hat and Fedora systems if supported by the hardware.     Enable Randomized Layout of Virtual Address Space Address space layout randomization (ASLR) makes it more difficult for an attacker to predict the location of attack code they have introduced into a process's address space during an attempt at exploitation. Additionally, ASLR makes it more difficult for an attacker to know the location of existing code in order to re-purpose it using return oriented programming (ROP) techniques.     Enable Execute Disable (XD) or No Execute (NX) Support on x86 Systems Recent processors in the x86 family support the ability to prevent code execution on a per memory page basis. Generically and on AMD processors, this ability is called No Execute (NX), while on Intel processors it is called Execute Disable (XD). This ability can help prevent exploitation of buffer overflow vulnerabilities and should be activated whenever possible. Extra steps must be taken to ensure that this protection is enabled, particularly on 32-bit x86 systems. Other processors, such as Itanium and POWER, have included such support since inception and the standard kernel for those platforms supports the feature. This is enabled by default on the latest Red Hat and Fedora systems if supported by the hardware. Install PAE Kernel on Supported 32-bit x86 Systems Systems that are using the 64-bit x86 kernel package do not need to install the kernel-PAE package because the 64-bit x86 kernel already includes this support. However, if the system is 32-bit and also supports the PAE and NX features as determined in the previous section, the kernel-PAE package should be installed to enable XD or NX support: 
    $ sudo yum install kernel-PAE
    The installation process should also have configured the bootloader to load the new kernel at boot. Verify this at reboot and modify /etc/default/grub if necessary.     The kernel-PAE package should not be installed on older systems that do not support the XD or NX bit, as this may prevent them from booting. On 32-bit systems that support the XD or NX bit, the vendor-supplied PAE kernel is required to enable either Execute Disable (XD) or No Execute (NX) support.     Enable NX or XD Support in the BIOS Reboot the system and enter the BIOS or Setup configuration menu. Navigate the BIOS configuration menu and make sure that the option is enabled. The setting may be located under a Security section. Look for Execute Disable (XD) on Intel-based systems and No Execute (NX) on AMD-based systems. Computers with the ability to prevent this type of code execution frequently put an option in the BIOS that will allow users to turn the feature on or off at will.     Restrict Access to Kernel Message Buffer Unprivileged access to the kernel syslog can expose sensitive kernel address information.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/permissions/files.xml000066400000000000000000000544301301675746700264620ustar00rootroot00000000000000 Verify Permissions on Important Files and Directories Permissions for many files on a system must be set restrictively to ensure sensitive information is properly protected. This section discusses important permission restrictions which can be verified to ensure that no harmful discrepancies have arisen. Verify Permissions on Files with Local Account Information and Credentials The default restrictive permissions for files which act as important security databases such as passwd, shadow, group, and gshadow files must be maintained. Many utilities need read access to the passwd file in order to function properly, but read access to the shadow file allows malicious attacks against system passwords, and should never be enabled. Verify User Who Owns <tt>shadow</tt> File The /etc/shadow file contains the list of local system accounts and stores password hashes. Protection of this file is critical for system security. Failure to give ownership of this file to root provides the designated owner with access to sensitive information which could weaken the system security posture. Verify Group Who Owns <tt>shadow</tt> File The /etc/shadow file stores password hashes. Protection of this file is critical for system security. Verify Permissions on <tt>shadow</tt> File The /etc/shadow file contains the list of local system accounts and stores password hashes. Protection of this file is critical for system security. Failure to give ownership of this file to root provides the designated owner with access to sensitive information which could weaken the system security posture. Verify User Who Owns <tt>group</tt> File The /etc/group file contains information regarding groups that are configured on the system. Protection of this file is important for system security. Verify Group Who Owns <tt>group</tt> File The /etc/group file contains information regarding groups that are configured on the system. Protection of this file is important for system security. Verify Permissions on <tt>group</tt> File The /etc/group file contains information regarding groups that are configured on the system. Protection of this file is important for system security. Verify User Who Owns <tt>gshadow</tt> File The /etc/gshadow file contains group password hashes. Protection of this file is critical for system security. Verify Group Who Owns <tt>gshadow</tt> File The /etc/gshadow file contains group password hashes. Protection of this file is critical for system security. Verify Permissions on <tt>gshadow</tt> File The /etc/gshadow file contains group password hashes. Protection of this file is critical for system security. Verify User Who Owns <tt>passwd</tt> File The /etc/passwd file contains information about the users that are configured on the system. Protection of this file is critical for system security. Verify Group Who Owns <tt>passwd</tt> File The /etc/passwd file contains information about the users that are configured on the system. Protection of this file is critical for system security. Verify Permissions on <tt>passwd</tt> File If the /etc/passwd file is writable by a group-owner or the world the risk of its compromise is increased. The file contains the list of accounts on the system and associated information, and protection of this file is critical for system security. Verify File Permissions Within Some Important Directories Some directories contain files whose confidentiality or integrity is notably important and may also be susceptible to misconfiguration over time, particularly if unpackaged software is installed. As such, an argument exists to verify that files' permissions within these directories remain configured correctly and restrictively. Verify that Shared Library Files Have Restrictive Permissions System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default: 
    /lib
/lib64
/usr/lib
/usr/lib64
    Kernel modules, which can be added to the kernel during runtime, are stored in /lib/modules. All files in these directories should not be group-writable or world-writable. If any file in these directories is found to be group-writable or world-writable, correct its permission with the following command: 
    $ sudo chmod go-w FILE
     Shared libraries are stored in the following directories: 
    /lib
/lib64
/usr/lib
/usr/lib64
    To find shared libraries that are group-writable or world-writable, run the following command for each directory DIR which contains shared libraries: 
    $ sudo find -L DIR -perm /022 -type f
     Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Restrictive permissions are necessary to protect the integrity of the system.     Verify that Shared Library Files Have Root Ownership System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default: 
    /lib
/lib64
/usr/lib
/usr/lib64
    Kernel modules, which can be added to the kernel during runtime, are also stored in /lib/modules. All files in these directories should be owned by the root user. If the directory, or any file in these directories, is found to be owned by a user other than root correct its ownership with the following command: 
    $ sudo chown root FILE
     Shared libraries are stored in the following directories: 
    /lib
/lib64
/usr/lib
/usr/lib64
    For each of these directories, run the following command to find files not owned by root: 
    $ sudo find -L $DIR \! -user root -exec chown root {} \;
     Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Proper ownership is necessary to protect the integrity of the system.     Verify that System Executables Have Restrictive Permissions System executables are stored in the following directories by default: 
    /bin
/sbin
/usr/bin
/usr/libexec
/usr/local/bin
/usr/local/sbin
/usr/sbin
    All files in these directories should not be group-writable or world-writable. If any file FILE in these directories is found to be group-writable or world-writable, correct its permission with the following command: 
    $ sudo chmod go-w FILE
     System executables are stored in the following directories by default: 
    /bin
/sbin
/usr/bin
/usr/libexec
/usr/local/bin
/usr/local/sbin
/usr/sbin
    To find system executables that are group-writable or world-writable, run the following command for each directory DIR which contains system executables: 
    $ sudo find -L DIR -perm /022 -type f
     System binaries are executed by privileged users, as well as system services, and restrictive permissions are necessary to ensure execution of these programs cannot be co-opted.     Verify that System Executables Have Root Ownership System executables are stored in the following directories by default: 
    /bin
/sbin
/usr/bin
/usr/libexec
/usr/local/bin
/usr/local/sbin
/usr/sbin
    All files in these directories should be owned by the root user. If any file FILE in these directories is found to be owned by a user other than root, correct its ownership with the following command: 
    $ sudo chown root FILE
     System executables are stored in the following directories by default: 
    /bin
/sbin
/usr/bin
/usr/libexec
/usr/local/bin
/usr/local/sbin
/usr/sbin
    To find system executables that are not owned by root, run the following command for each directory DIR which contains system executables: 
    $ sudo find DIR/ \! -user root
     System binaries are executed by privileged users as well as system services, and restrictive permissions are necessary to ensure that their execution of these programs cannot be co-opted.     Verify that All World-Writable Directories Have Sticky Bits Set When the so-called 'sticky bit' is set on a directory, only the owner of a given file may remove that file from the directory. Without the sticky bit, any user with write access to a directory may remove any file in the directory. Setting the sticky bit prevents users from removing each other's files. In cases where there is no reason for a directory to be world-writable, a better solution is to remove that permission rather than to set the sticky bit. However, if a directory is used by a particular application, consult that application's documentation instead of blindly changing modes.
    To set the sticky bit on a world-writable directory DIR, run the following command: 
    $ sudo chmod +t DIR
     To find world-writable directories that lack the sticky bit, run the following command: 
    $ sudo find / -xdev -type d -perm 002 ! -perm 1000
     Failing to set the sticky bit on public directories allows unauthorized users to delete files in the directory structure.

    The only authorized public directories are those temporary directories supplied with the system, or those designed to be temporary file repositories. The setting is normally reserved for directories used by the system, by users for temporary file storage (such as /tmp), and for directories requiring global read/write access.     Ensure No World-Writable Files Exist It is generally a good idea to remove global (other) write access to a file when it is discovered. However, check with documentation for specific applications before making changes. Also, monitor for recurring world-writable files, as these may be symptoms of a misconfigured application or user account. To find world-writable files, run the following command: 
    $ sudo find / -xdev -type f -perm -002
     Data in world-writable files can be modified by any user on the system. In almost all circumstances, files can be configured using a combination of user and group permissions to support whatever legitimate access is needed without the risk caused by world-writable files.     Ensure All SGID Executables Are Authorized The SGID (set group id) bit should be set only on files that were installed via authorized means. A straightforward means of identifying unauthorized SGID files is determine if any were not installed as part of an RPM package, which is cryptographically verified. Investigate the origin of any unpackaged SGID files. To find world-writable files, run the following command: 
    $ sudo find / -xdev -type f -perm -002
     Executable files with the SGID permission run with the privileges of the owner of the file. SGID files of uncertain provenance could allow for unprivileged users to elevate privileges. The presence of these files should be strictly controlled on the system.     Ensure All SUID Executables Are Authorized The SUID (set user id) bit should be set only on files that were installed via authorized means. A straightforward means of identifying unauthorized SGID files is determine if any were not installed as part of an RPM package, which is cryptographically verified. Investigate the origin of any unpackaged SUID files. To find world-writable files, run the following command: 
    $ sudo find / -xdev -type f -perm -002
     Executable files with the SUID permission run with the privileges of the owner of the file. SUID files of uncertain provenance could allow for unprivileged users to elevate privileges. The presence of these files should be strictly controlled on the system.     Ensure All Files Are Owned by a User If any files are not owned by a user, then the cause of their lack of ownership should be investigated. Following this, the files should be deleted or assigned to an appropriate user. The following command will discover and print any files on local partitions which do not belong to a valid user. 
    $ sudo find / -xdev -fstype local -nouser


    Either remove all files and directories from the system that do not have a valid user, or assign a valid user to all unowned files and directories on the system with the chown command: 
    $ sudo chown user file
     Unowned files do not directly imply a security problem, but they are generally a sign that something is amiss. They may be caused by an intruder, by incorrect software installation or draft software removal, or by failure to remove all files belonging to a deleted account. The files should be repaired so they will not cause problems when accounts are created in the future, and the cause should be discovered and addressed.     Ensure All Files Are Owned by a Group If any files are not owned by a group, then the cause of their lack of group-ownership should be investigated. Following this, the files should be deleted or assigned to an appropriate group. The following command will discover and print any files on local partitions which do not belong to a valid group. 
    $ sudo find / -xdev -fstype local -nogroup

    Either remove all files and directories from the system that do not have a valid group, or assign a valid group with the chgrp command: 
    $ sudo chgrp group file
     Unowned files do not directly imply a security problem, but they are generally a sign that something is amiss. They may be caused by an intruder, by incorrect software installation or draft software removal, or by failure to remove all files belonging to a deleted account. The files should be repaired so they will not cause problems when accounts are created in the future, and the cause should be discovered and addressed.     Ensure All World-Writable Directories Are Owned by a System Account All directories in local partitions which are world-writable should be owned by root or another system account. If any world-writable directories are not owned by a system account, this should be investigated. Following this, the files should be deleted or assigned to an appropriate group. The following command will discover and print world-writable directories that are not owned by a system account, given the assumption that only system accounts have a uid lower than 500. Run it once for each local partition PART: 
    $ sudo find PART -xdev -type d -perm -0002 -uid +499 -print
     Allowing a user account to own a world-writable directory is undesirable because it allows the owner of that directory to remove or replace any files that may be placed in the directory by other users.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/permissions/mounting.xml000066400000000000000000000211401301675746700272100ustar00rootroot00000000000000 Restrict Dynamic Mounting and Unmounting of Filesystems Linux includes a number of facilities for the automated addition and removal of filesystems on a running system. These facilities may be necessary in many environments, but this capability also carries some risk -- whether direct risk from allowing users to introduce arbitrary filesystems, or risk that software flaws in the automated mount facility itself could allow an attacker to compromise the system.

    This command can be used to list the types of filesystems that are available to the currently executing kernel: 
    $ find /lib/modules/`uname -r`/kernel/fs -type f -name '*.ko'
    If these filesystems are not required then they can be explicitly disabled in a configuratio file in /etc/modprobe.d.     Disable Modprobe Loading of USB Storage Driver To prevent USB storage devices from being used, configure the kernel module loading system to prevent automatic loading of the USB storage driver. This will prevent the modprobe program from loading the usb-storage module, but will not prevent an administrator (or another program) from using the insmod program to load the module manually. USB storage devices such as thumb drives can be used to introduce malicious software. Disable Kernel Support for USB via Bootloader Configuration All USB support can be disabled by adding the nousb argument to the kernel's boot loader configuration. To do so, append "nousb" to the kernel line in /etc/default/grub as shown: 
    kernel /vmlinuz-VERSION ro vga=ext root=/dev/VolGroup00/LogVol00 rhgb quiet nousb
    WARNING: Disabling all kernel support for USB will cause problems for systems with USB-based keyboards, mice, or printers. This configuration is infeasible for systems which require USB devices, which is common.     Disabling the USB subsystem within the Linux kernel at system boot will protect against potentially malicious USB devices, although it is only practical in specialized systems.     Disable Booting from USB Devices in Boot Firmware Configure the system boot firmware (historically called BIOS on PC systems) to disallow booting from USB drives. Booting a system from a USB device would allow an attacker to circumvent any security measures provided by the operating system. Attackers could mount partitions and modify the configuration of the OS. Assign Password to Prevent Changes to Boot Firmware Configuration Assign a password to the system boot firmware (historically called BIOS on PC systems) to require a password for any configuration changes. Assigning a password to the system boot firmware prevents anyone with physical access from configuring the system to boot from local media and circumvent the operating system's access controls. For systems in physically secure locations, such as a data center or Sensitive Compartmented Information Facility (SCIF), this risk must be weighed against the risk of administrative personnel being unable to conduct recovery operations in a timely fashion. Disable the Automounter The autofs daemon mounts and unmounts filesystems, such as user home directories shared via NFS, on demand. In addition, autofs can be used to handle removable media, and the default configuration provides the cdrom device as /misc/cd. However, this method of providing access to removable media is not common, so autofs can almost always be disabled if NFS is not in use. Even if NFS is required, it may be possible to configure filesystem mounts statically by editing /etc/fstab rather than relying on the automounter.

    Disabling the automounter permits the administrator to statically control filesystem mounting through /etc/fstab.

    Additionally, automatically mounting filesystems permits easy introduction of unknown devices, thereby facilitating malicious activity.     Disable Mounting of <tt>cramfs</tt> This effectively prevents usage of this uncommon filesystem. Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. Disable Mounting of <tt>freevxfs</tt> This effectively prevents usage of this uncommon filesystem. Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. Disable Mounting of <tt>jffs2</tt> This effectively prevents usage of this uncommon filesystem. Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. Disable Mounting of <tt>hfs</tt> This effectively prevents usage of this uncommon filesystem. Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. Disable Mounting of <tt>hfsplus</tt> This effectively prevents usage of this uncommon filesystem. Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. Disable Mounting of <tt>squashfs</tt> This effectively prevents usage of this uncommon filesystem. Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. Disable Mounting of <tt>udf</tt> This effectively prevents usage of this uncommon filesystem. Linux kernel modules which implement filesystems that are not needed by the local system should be disabled.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/permissions/partitions.xml000066400000000000000000000233751301675746700275600ustar00rootroot00000000000000 Restrict Partition Mount Options System partitions can be mounted with certain options that limit what files on those partitions can do. These options are set in the /etc/fstab configuration file, and can be used to make certain types of malicious behavior more difficult. Removable Partition This value is used by the checks mount_option_nodev_removable_partitions, mount_option_nodev_removable_partitions, and mount_option_nodev_removable_partitions to ensure that the correct mount options are set on partitions mounted from removable media such as CD-ROMs, USB keys, and floppy drives. This value should be modified to reflect any removable partitions that are required on the local system. /dev/cdrom Add nodev Option to Non-Root Local Partitions The nodev mount option prevents files from being interpreted as character or block devices. Legitimate character and block devices should exist only in the /dev directory on the root partition or within chroot jails built for system services. The nodev mount option prevents files from being interpreted as character or block devices. The only legitimate location for device files is the /dev directory located on the root partition. The only exception to this is chroot jails, for which it is not advised to set nodev on these filesystems. Add nodev Option to Removable Media Partitions The nodev mount option prevents files from being interpreted as character or block devices. Legitimate character and block devices should exist only in the /dev directory on the root partition or within chroot jails built for system services. The only legitimate location for device files is the /dev directory located on the root partition. An exception to this is chroot jails, and it is not advised to set nodev on partitions which contain their root filesystems. Add noexec Option to Removable Media Partitions The noexec mount option prevents the direct execution of binaries on the mounted filesystem. Preventing the direct execution of binaries from removable media (such as a USB key) provides a defense against malicious software that may be present on such untrusted media. Allowing users to execute binaries from removable media such as USB keys exposes the system to potential compromise. To verify that binaries cannot be directly executed from removable media, run the following command: 
    $ grep -v noexec /etc/fstab
    The resulting output will show partitions which do not have the noexec flag. Verify all partitions in the output are not removable media.     Add nosuid Option to Removable Media Partitions The nosuid mount option prevents set-user-identifier (SUID) and set-group-identifier (SGID) permissions from taking effect. These permissions allow users to execute binaries with the same permissions as the owner and group of the file respectively. Users should not be allowed to introduce SUID and SGID files into the system via partitions mounted from removeable media. The presence of SUID and SGID executables should be tightly controlled. Allowing users to introduce SUID or SGID binaries from partitions mounted off of removable media would allow them to introduce their own highly-privileged programs. Add nodev Option to /tmp The nodev mount option can be used to prevent device files from being created in /tmp. Legitimate character and block devices should not exist within temporary directories like /tmp. The only legitimate location for device files is the /dev directory located on the root partition. The only exception to this is chroot jails. Add noexec Option to /tmp The noexec mount option can be used to prevent binaries from being executed out of /tmp. Allowing users to execute binaries from world-writable directories such as /tmp should never be necessary in normal operation and can expose the system to potential compromise. Add nosuid Option to /tmp The nosuid mount option can be used to prevent execution of setuid programs in /tmp. The SUID and SGID permissions should not be required in these world-writable directories. The presence of SUID and SGID executables should be tightly controlled. Users should not be able to execute SUID or SGID binaries from temporary storage partitions. Add nodev Option to /dev/shm The nodev mount option can be used to prevent creation of device files in /dev/shm. Legitimate character and block devices should not exist within temporary directories like /dev/shm. The only legitimate location for device files is the /dev directory located on the root partition. The only exception to this is chroot jails. Add noexec Option to /dev/shm The noexec mount option can be used to prevent binaries from being executed out of /dev/shm. It can be dangerous to allow the execution of binaries from world-writable temporary storage directories such as /dev/shm. Allowing users to execute binaries from world-writable directories such as /dev/shm can expose the system to potential compromise. Add nosuid Option to /dev/shm The nosuid mount option can be used to prevent execution of setuid programs in /dev/shm. The SUID and SGID permissions should not be required in these world-writable directories. The presence of SUID and SGID executables should be tightly controlled. Users should not be able to execute SUID or SGID binaries from temporary storage partitions. Bind Mount /var/tmp To /tmp The /var/tmp directory is a world-writable directory. Bind-mount it to /tmp in order to consolidate temporary storage into one location protected by the same techniques as /tmp. To do so, edit /etc/fstab and add the following line: 
    /tmp     /var/tmp     none     rw,nodev,noexec,nosuid,bind     0 0
    See the mount(8) man page for further explanation of bind mounting.     Having multiple locations for temporary storage is not required. Unless absolutely necessary to meet requirements, the storage location /var/tmp should be bind mounted to /tmp and thus share the same protections.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/selinux.xml000066400000000000000000000213751301675746700244760ustar00rootroot00000000000000 SELinux SELinux is a feature of the Linux kernel which can be used to guard against misconfigured or compromised programs. SELinux enforces the idea that programs should be limited in what files they can access and what actions they can take.

    The default SELinux policy, as configured on Red Hat Enterprise Linux 7, has been sufficiently developed and debugged that it should be usable on almost any Red Hat machine with minimal configuration and a small amount of system administrator training. This policy prevents system services - including most of the common network-visible services such as mail servers, FTP servers, and DNS servers - from accessing files which those services have no valid reason to access. This action alone prevents a huge amount of possible damage from network attacks against services, from trojaned software, and so forth.

    This guide recommends that SELinux be enabled using the default (targeted) policy on every Red Hat system, unless that system has unusual requirements which make a stronger policy appropriate.     SELinux state enforcing - SELinux security policy is enforced.
    permissive - SELinux prints warnings instead of enforcing.
    disabled - SELinux is fully disabled.     enforcing enforcing permissive disabled     SELinux policy Type of policy in use. Possible values are:
    targeted - Only targeted network daemons are protected.
    strict - Full SELinux protection.
    mls - Multiple levels of security     targeted targeted mls     Ensure SELinux Not Disabled in /etc/default/grub SELinux can be disabled at boot time by an argument in /etc/default/grub. Remove any instances of selinux=0 from the kernel arguments in that file to prevent SELinux from being disabled at boot. Inspect /etc/default/grub for any instances of selinux=0 in the kernel boot arguments. Presence of selinux=0 indicates that SELinux is disabled at boot time. Disabling a major host protection feature, such as SELinux, at boot time prevents it from confining system services at boot time. Further, it increases the chances that it will remain off during system operation. Ensure SELinux State is Enforcing The SELinux state should be set to at system boot time. In the file /etc/selinux/config, add or correct the following line to configure the system to boot into enforcing mode: 
    SELINUX=
     Check the file /etc/selinux/config and ensure the following line appears: 
    SELINUX=
     Setting the SELinux state to enforcing ensures SELinux is able to confine potentially compromised processes to the security policy, which is designed to prevent them from causing damage to the system or further elevating their privileges.     Configure SELinux Policy The SELinux targeted policy is appropriate for general-purpose desktops and servers, as well as systems in many other roles. To configure the system to use this policy, add or correct the following line in /etc/selinux/config: 
    SELINUXTYPE=
    Other policies, such as mls, provide additional security labeling and greater confinement but are not compatible with many general-purpose use cases.     Check the file /etc/selinux/config and ensure the following line appears: 
    SELINUXTYPE=
     Setting the SELinux policy to targeted or a more specialized policy ensures the system will confine processes that are likely to be targeted for exploitation, such as network or system services.

    Note: During the development or debugging of SELinux modules, it is common to temporarily place non-production systems in permissive mode. In such temporary cases, SELinux policies should be developed, and once work is completed, the system should be reconfigured to .     Uninstall setroubleshoot Package The SETroubleshoot service notifies desktop users of SELinux denials. The service provides information around configuration errors, unauthorized intrusions, and other potential errors. The SETroubleshoot service is an unnecessary daemon to have running on a server Uninstall mcstrans Package The mcstransd daemon provides category label information to client processes requesting information. The label translations are defined in /etc/selinux/targeted/setrans.conf. Since this service is not used very often, disable it to reduce the amount of potentially vulnerable code running on the system. NOTE: This rule was added in support of the CIS RHEL6 v1.2.0 benchmark. Please note that Red Hat does not feel this rule is security relevant. Ensure No Daemons are Unconfined by SELinux Daemons for which the SELinux policy does not contain rules will inherit the context of the parent process. Because daemons are launched during startup and descend from the init process, they inherit the initrc_t context.

    To check for unconfined daemons, run the following command: 
    $ sudo ps -eZ | egrep "initrc" | egrep -vw "tr|ps|egrep|bash|awk" | tr ':' ' ' | awk '{ print $NF }'
    It should produce no output in a well-configured system.     Daemons which run with the initrc_t context may cause AVC denials, or allow privileges that the daemon does not require.     Ensure No Device Files are Unlabeled by SELinux Device files, which are used for communication with important system resources, should be labeled with proper SELinux types. If any device files do not carry the SELinux type device_t, report the bug so that policy can be corrected. Supply information about what the device is and what programs use it. To check for unlabeled device files, run the following command: 
    $ sudo find /dev -context *:device_t:* \( -type c -o -type b \) -printf "%p %Z\n"
    It should produce no output in a well-configured system.     If a device file carries the SELinux type device_t, then SELinux cannot properly restrict access to the device file.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/software/000077500000000000000000000000001301675746700241075ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/software/disk_partitioning.xml000066400000000000000000000173721301675746700303640ustar00rootroot00000000000000 Disk Partitioning To ensure separation and protection of data, there are top-level system directories which should be placed on their own physical partition or logical volume. The installer's default partitioning scheme creates separate logical volumes for /, /boot, and swap.
    • If starting with any of the default layouts, check the box to "Review and modify partitioning." This allows for the easy creation of additional logical volumes inside the volume group already created, though it may require making /'s logical volume smaller to create space. In general, using logical volumes is preferable to using partitions because they can be more easily adjusted later.
    • If creating a custom layout, create the partitions mentioned in the previous paragraph (which the installer will require anyway), as well as separate ones described in the following sections.
    If a system has already been installed, and the default partitioning scheme was used, it is possible but nontrivial to modify it to create separate logical volumes for the directories listed above. The Logical Volume Manager (LVM) makes this possible. See the LVM HOWTO at http://tldp.org/HOWTO/LVM-HOWTO/ for more detailed information on LVM.     Ensure /tmp Located On Separate Partition The /tmp directory is a world-writable directory used for temporary file storage. Ensure it has its own partition or logical volume at installation time, or migrate it using LVM. The /tmp partition is used as temporary storage by many programs. Placing /tmp in its own partition enables the setting of more restrictive mount options, which can help protect programs which use it. Ensure /var Located On Separate Partition The /var directory is used by daemons and other system services to store frequently-changing data. Ensure that /var has its own partition or logical volume at installation time, or migrate it using LVM. Ensuring that /var is mounted on its own partition enables the setting of more restrictive mount options. This helps protect system services such as daemons or other programs which use it. It is not uncommon for the /var directory to contain world-writable directories installed by other software packages. Ensure /var/log Located On Separate Partition System logs are stored in the /var/log directory. Ensure that it has its own partition or logical volume at installation time, or migrate it using LVM. Placing /var/log in its own partition enables better separation between log files and other files in /var/. Ensure /var/log/audit Located On Separate Partition Audit logs are stored in the /var/log/audit directory. Ensure that it has its own partition or logical volume at installation time, or migrate it later using LVM. Make absolutely certain that it is large enough to store all audit logs that will be created by the auditing daemon. Placing /var/log/audit in its own partition enables better separation between audit files and other files, and helps ensure that auditing cannot be halted due to the partition running out of space. Ensure /home Located On Separate Partition If user home directories will be stored locally, create a separate partition for /home at installation time (or migrate it later using LVM). If /home will be mounted from another system such as an NFS server, then creating a separate partition is not necessary at installation time, and the mountpoint can instead be configured later. Ensuring that /home is mounted on its own partition enables the setting of more restrictive mount options, and also helps ensure that users cannot trivially fill partitions used for log or audit data storage. Encrypt Partitions Red Hat Enterprise Linux 7 natively supports partition encryption through the Linux Unified Key Setup-on-disk-format (LUKS) technology. The easiest way to encrypt a partition is during installation time.

    For manual installations, select the Encrypt checkbox during partition creation to encrypt the partition. When this option is selected the system will prompt for a passphrase to use in decrypting the partition. The passphrase will subsequently need to be entered manually every time the system boots.

    For automated/unattended installations, it is possible to use Kickstart by adding the --encrypted and --passphrase= options to the definition of each partition to be encrypted. For example, the following line would encrypt the root partition: 
    part / --fstype=ext4 --size=100 --onpart=hda1 --encrypted --passphrase=PASSPHRASE
    Any PASSPHRASE is stored in the Kickstart in plaintext, and the Kickstart must then be protected accordingly. Omitting the --passphrase= option from the partition definition will cause the installer to pause and interactively ask for the passphrase during installation.

    Detailed information on encrypting partitions using LUKS can be found on the Red Hat Documentation web site:
    https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Encryption.html     Check the system partitions to determine if they are encrypted with the following command: 
    blkid


    Output will be similar to: 
    /dev/sda1: UUID=" ab12c3de-4f56-789a-8f33-3850cc8ce3a2
" TYPE="crypto_LUKS"
/dev/sda2: UUID=" bc98d7ef-6g54-321h-1d24-9870de2ge1a2
" TYPE="crypto_LUKS"


    Pseudo-file systems, such as /proc, /sys, and tmpfs, are not required to use disk encryption and are not a finding.     The risk of a system's physical compromise, particularly mobile systems such as laptops, places its data at risk of compromise. Encrypting this data mitigates the risk of its loss if the system is lost.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/software/gnome.xml000066400000000000000000001232121301675746700257370ustar00rootroot00000000000000 GNOME Desktop Environment GNOME is a graphical desktop environment bundled with many Linux distributions that allow users to easily interact with the operating system graphically rather than textually. The GNOME Graphical Display Manager (GDM) provides login, logout, and user switching contexts as well as display server management.

    GNOME is developed by the GNOME Project and is considered the default Red Hat Graphical environment.

    For more information on GNOME and the GNOME Project, see https://www.gnome.org     Configure GNOME3 DConf User Profile By default, DConf provides a standard user profile. This profile contains a list of DConf configuration databases. The user profile and database always take the highest priority. As such the DConf User profile should always exist and be configured correctly.

    To make sure that the user profile is configured correctly, the /etc/dconf/profile/user should be set as follows: 
    user-db:user
system-db:local
system-db:site
system-db:distro
    To verify that the DConf User profile is configured correctly, run the following command: 
    $ cat /etc/dconf/profile/user
    The output should show the following: 
    user-db:user
system-db:local
system-db:site
system-db:distro
     Failure to have a functional DConf profile prevents GNOME3 configuration settings from being enforced for all users and allows various security risks.     Configure GNOME Login Screen In the default GNOME3 desktop, the login is displayed after system boot and can display user accounts, allow users to reboot the system, and allow users to login automatically and/or with a guest account. The login screen should be configured to prevent such behavior.

    For more information about enforcing preferences in the GNOME3 environment using the DConf configuration system, see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Desktop_Migration_and_Administration_Guide/index.html and the man page dconf(1).     Disable GDM Automatic Login The GNOME Display Manager (GDM) can allow users to automatically login without user interaction or credentials. User should always be required to authenticate themselves to the system that they are authorized to use. To disable user ability to automatically login to the system, set the AutomaticLoginEnable to false in the [daemon] section in /etc/gdm/custom.conf. For example: 
    [daemon]
AutomaticLoginEnable=false
     To verify that automatic logins are disabled, run the following command: 
    $ grep -Pzoi "^\[daemon]\\nautomaticlogin.*" /etc/gdm/custom.conf
    The output should show the following: 
    [daemon]
AutomaticLoginEnable=false
     Failure to restrict system access to authenticated users negatively impacts operating system security.     Disable GDM Guest Login The GNOME Display Manager (GDM) can allow users to login without credentials which can be useful for public kiosk scenarios. Allowing users to login without credentials or "guest" account access has inherent security risks and should be disabled. To do disable timed logins or guest account access, set the TimedLoginEnable to false in the [daemon] section in /etc/gdm/custom.conf. For example: 
    [daemon]
TimedLoginEnable=false
     To verify that timed logins are disabled, run the following command: 
    $ grep -Pzoi "^\[daemon]\\ntimedlogin.*" /etc/gdm/custom.conf
    The output should show the following: 
    [daemon]
TimedLoginEnable=false
     Failure to restrict system access to authenticated users negatively impacts operating system security.     Disable the GNOME3 Login User List In the default graphical environment, users logging directly into the system are greeted with a login screen that displays all known users. This functionality should be disabled by setting disable-user-list to true.

    To disable, add or edit disable-user-list to /etc/dconf/db/gdm.d/00-security-settings. For example: 
    [org/gnome/login-screen]
disable-user-list=true
    Once the setting has been added, add a lock to /etc/dconf/db/gdm.d/locks/00-security-settings-lock to prevent user modification. For example: 
    /org/gnome/login-screen/disable-user-list
    After the settings have been set, run dconf update.     To ensure the user list is disabled, run the following command: 
    $ grep disable-user-list /etc/dconf/db/gdm.d/*
    The output should be true. To ensure that users cannot enable displaying the user list, run the following: 
    $ grep disable-user-list /etc/dconf/db/gdm.d/locks/*
    If properly configured, the output should be /org/gnome/login-screen/disable-user-list     Leaving the user list enabled is a security risk since it allows anyone with physical access to the system to quickly enumerate known user accounts without logging in.     Disable the GNOME3 Login Restart and Shutdown Buttons In the default graphical environment, users logging directly into the system are greeted with a login screen that allows any user, known or unknown, the ability the ability to shutdown or restart the system. This functionality should be disabled by setting disable-restart-buttons to true.

    To disable, add or edit disable-restart-buttons to /etc/dconf/db/gdm.d/00-security-settings. For example: 
    [org/gnome/login-screen]
disable-restart-buttons=true
    Once the setting has been added, add a lock to /etc/dconf/db/gdm.d/locks/00-security-settings-lock to prevent user modification. For example: 
    /org/gnome/login-screen/disable-restart-buttons
    After the settings have been set, run dconf update.     To ensure disable and restart on the login screen are disabled, run the following command: 
    $ grep disable-restart-buttons /etc/dconf/db/gdm.d/*
    The output should be true. To ensure that users cannot enable disable and restart on the login screen, run the following: 
    $ grep disable-restart-buttons /etc/dconf/db/gdm.d/locks/*
    If properly configured, the output should be /org/gnome/login-screen/disable-restart-buttons     A user who is at the console can reboot the system at the login screen. If restart or shutdown buttons are pressed at the login screen, this can create the risk of short-term loss of availability of systems due to reboot.     Enable the GNOME3 Login Smartcard Authentication In the default graphical environment, smart card authentication can be enabled on the login screen by setting enable-smartcard-authentication to true.

    To enable, add or edit enable-smartcard-authentication to /etc/dconf/db/gdm.d/00-security-settings. For example: 
    [org/gnome/login-screen]
enable-smartcard-authentication=true
    Once the setting has been added, add a lock to /etc/dconf/db/gdm.d/locks/00-security-settings-lock to prevent user modification. For example: 
    /org/gnome/login-screen/enable-smartcard-authentication
    After the settings have been set, run dconf update.     To ensure smart card authentication on the login screen is enabled, run the following command: 
    $ grep enable-smartcard-authentication /etc/dconf/db/gdm.d/*
    The output should be true. To ensure that users cannot disable smart card authentication on the login screen, run the following: 
    $ grep enable-smartcard-authentication /etc/dconf/db/gdm.d/locks/*
    If properly configured, the output should be /org/gnome/login-screen/enable-smartcard-authentication     Smart card login provides two-factor authentication stronger than that provided by a username and password combination. Smart cards leverage PKI (public key infrastructure) in order to provide and verify credentials.     Set the GNOME3 Login Number of Failures In the default graphical environment, the GNOME3 login screen and be configured to restart the authentication process after a configured number of attempts. This can be configured by setting allowed-failures to 3 or less.

    To enable, add or edit allowed-failures to /etc/dconf/db/gdm.d/00-security-settings. For example: 
    [org/gnome/login-screen]
allowed-failures=3
    Once the setting has been added, add a lock to /etc/dconf/db/gdm.d/locks/00-security-settings-lock to prevent user modification. For example: 
    /org/gnome/login-screen/allowed-failures
    After the settings have been set, run dconf update.     To ensure the login screen resets after a specified number of failures, run the following command: 
    $ grep allowed-failures /etc/dconf/db/gdm.d/*
    The output should be 3 or less. To ensure that users cannot change or configure the resets after a specified number of failures on the login screen, run the following: 
    $ grep allowed-failures /etc/dconf/db/gdm.d/locks/*
    If properly configured, the output should be /org/gnome/login-screen/allowed-failures     Setting the password retry prompts that are permitted on a per-session basis to a low value requires some software, such as SSH, to re-connect. This can slow down and draw additional attention to some types of password-guessing attacks.     Configure GNOME Screen Locking In the default GNOME3 desktop, the screen can be locked by selecting the user name in the far right corner of the main panel and selecting Lock.

    The following sections detail commands to enforce idle activation of the screensaver, screen locking, a blank-screen screensaver, and an idle activation time.

    Because users should be trained to lock the screen when they step away from the computer, the automatic locking feature is only meant as a backup.

    The root account can be screen-locked; however, the root account should never be used to log into an X Windows environment and should only be used to for direct login via console in emergency circumstances.

    For more information about enforcing preferences in the GNOME3 environment using the DConf configuration system, see http://wiki.gnome.org/dconf and the man page dconf(1). For Red Hat specific information on configuring DConf settings, see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Desktop_Migration_and_Administration_Guide/part-Configuration_and_Administration.html     Inactivity timeout Choose allowed duration of inactive SSH connections, shells, and X sessions 900 300 600 900 Set GNOME3 Screensaver Inactivity Timeout The idle time-out value for inactivity in the GNOME3 desktop is configured via the idle-delay setting must be set under an appropriate configuration file(s) in the /etc/dconf/db/local.d directory and locked in /etc/dconf/db/local.d/locks directory to prevent user modification.
    For example, to configure the system for a 15 minute delay, add the following to /etc/dconf/db/local.d/00-security-settings: 
    [org/gnome/desktop/session]
idle-delay=900
    Once the setting has been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
    /org/gnome/desktop/session/idle-delay
    After the settings have been set, run dconf update.     To check the current idle time-out value, run the following command: 
    $ gsettings get org.gnome.desktop.session idle-delay
    If properly configured, the output should be 'uint32 '. To ensure that users cannot change the screensaver inactivity timeout setting, run the following: 
    $ grep idle-delay /etc/dconf/db/local.d/locks/*
    If properly configured, the output should be /org/gnome/desktop/session/idle-delay     A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not logout because of the temporary nature of the absence. Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity, GNOME3 can be configured to identify when a user's session has idled and take action to initiate a session lock.     Enable GNOME3 Screensaver Idle Activation To activate the screensaver in the GNOME3 desktop after a period of inactivity, add or set idle-activation-enabled to true in /etc/dconf/db/local.d/00-security-settings. For example: 
    [org/gnome/desktop/screensaver]
idle_activation_enabled=true
    Once the setting has been added, add a lock to /etc/dconf/db/gdm.d/locks/00-security-settings-lock to prevent user modification. For example: 
    /org/gnome/desktop/screensaver/idle-activation-enabled
    After the settings have been set, run dconf update.     To check the screensaver mandatory use status, run the following command: 
    $ gsettings get org.gnome.desktop.screensaver idle-activation-enabled
    If properly configured, the output should be true. To ensure that users cannot disable the screensaver idle inactivity setting, run the following: 
    $ grep idle-activation-enabled /etc/dconf/db/local.d/locks/*
    If properly configured, the output should be /org/gnome/desktop/screensaver/idle-activation-enabled     A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not logout because of the temporary nature of the absence. Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity, GNOME desktops can be configured to identify when a user's session has idled and take action to initiate the session lock. Enabling idle activation of the screensaver ensures the screensaver will be activated after the idle delay. Applications requiring continuous, real-time screen display (such as network management products) require the login session does not have administrator rights and the display station is located in a controlled-access area.     Enable GNOME3 Screensaver Lock After Idle Period To activate locking of the screensaver in the GNOME3 desktop when it is activated, add or set lock-enabled to true and lock-delay to uint32 0 in /etc/dconf/db/local.d/00-security-settings. For example: 
    [org/gnome/desktop/screensaver]
lock-enabled=true
lock-delay=uint32 0
    Once the settings have been added, add a lock to /etc/dconf/db/gdm.d/locks/00-security-settings-lock to prevent user modification. For example: 
    /org/gnome/desktop/screensaver/lock-enabled
/org/gnome/desktop/screensaver/lock-delay
    After the settings have been set, run dconf update.     To check the status of the idle screen lock activation, run the following command: 
    $ gsettings get org.gnome.desktop.screensaver lock-enabled
    If properly configured, the output should be true.
    To check that the screen locks immediately when activated, run the following command: 
    $ gsettings get org.gnome.desktop.screensaver lock-delay
    If properly configured, the output should be 'uint32 0'.
    To ensure that users cannot change how long until the the screensaver locks, run the following: 
    $ grep 'lock-enabled\|lock-delay' /etc/dconf/db/local.d/locks/*
    If properly configured, the output for lock-enabled should be /org/gnome/desktop/screensaver/lock-enabled If properly configured, the output for lock-delay should be /org/gnome/desktop/screensaver/lock-delay     A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not want to logout because of the temporary nature of the absense.     Implement Blank Screensaver To set the screensaver mode in the GNOME3 desktop to a blank screen, add or set picture-uri to '' in /etc/dconf/db/local.d/00-security-settings. For example: 
    [org/gnome/desktop/screensaver]
picture-uri=''
    Once the settings have been added, add a lock to /etc/dconf/db/gdm.d/locks/00-security-settings-lock to prevent user modification. For example: 
    /org/gnome/desktop/screensaver/picture-uri
    After the settings have been set, run dconf update.     To ensure the screensaver is configured to be blank, run the following command: 
    $ gsettings get org.gnome.desktop.screensaver picture-uri
    If properly configured, the output should be ''. To ensure that users cannot set the screensaver background, run the following: 
    $ grep picture-uri /etc/dconf/db/local.d/locks/*
    If properly configured, the output should be /org/gnome/desktop/screensaver/picture-uri     Setting the screensaver mode to blank-only conceals the contents of the display from passersby.     Disable Full User Name on Splash Shield By default when the screen is locked, the splash shield will show the user's full name. This should be disabled to prevent casual observers from seeing who has access to the system. This can be disabled by adding or setting show-full-name-in-top-bar to false in /etc/dconf/db/local.d/00-security-settings. For example: 
    [org/gnome/desktop/screensaver]
show-full-name-in-top-bar=false
    Once the settings have been added, add a lock to /etc/dconf/db/gdm.d/locks/00-security-settings-lock to prevent user modification. For example: 
    /org/gnome/desktop/screensaver/show-full-name-in-top-bar
    After the settings have been set, run dconf update.     To ensure the splash screen is configured not to show user name, run the following command: 
    $ gsettings get org.gnome.desktop.screensaver show-full-name-in-top-bar
    If properly configured, the output should be false. To ensure that users cannot enable user name on the lock screen, run the following: 
    $ grep show-full-name-in-top-bar /etc/dconf/db/local.d/locks/*
    If properly configured, the output should be /org/gnome/desktop/screensaver/show-full-name-in-top-bar     Setting the splash screen to not reveal the logged in user's name conceals who has access to the system from passersby.     GNOME System Settings GNOME provides configuration and functionality to a graphical desktop environment that changes grahical configurations or allow a user to perform actions that users normally would not be able to do in non-graphical mode such as remote access configuration, power policies, Geo-location, etc. Configuring such settings in GNOME will prevent accidential graphical configuration changes by users from taking place. Disable Ctrl-Alt-Del Reboot Key Sequence in GNOME3 By default, GNOME will reboot the system if the Ctrl-Alt-Del key sequence is pressed.
    To configure the system to ignore the Ctrl-Alt-Del key sequence from the Graphical User Interface (GUI) instead of rebooting the system, add or set logout to '' in /etc/dconf/db/local.d/00-security-settings. For example: 
    [org/gnome/settings-daemon/plugins/media-keys]
logout=''
    Once the settings have been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
    /org/gnome/settings-daemon/plugins/media-keys/logout
    After the settings have been set, run dconf update.     To ensure the system is configured to ignore the Ctrl-Alt-Del sequence, run the following command: 
    $ gsettings get org.gnome.settings-daemon.plugins.media-keys logout
    If properly configured, the output should be ''. To ensure that users cannot enable the Ctrl-Alt-Del sequence, run the following: 
    $ grep logout /etc/dconf/db/local.d/locks/*
    If properly configured, the output should be /org/gnome/settings-daemon/plugins/media-keys/logout     A locally logged-in user who presses Ctrl-Alt-Del, when at the console, can reboot the system. If accidentally pressed, as could happen in the case of mixed OS environment, this can create the risk of short-term loss of availability of systems due to unintentional reboot.     Disable User Administration in GNOME3 By default, GNOME will allow all users to have some administratrion capability. This should be disabled so that non-administrative users are not making configuration changes. To configure the system to disable user administration capability in the Graphical User Interface (GUI), add or set user-administration-disabled to true in /etc/dconf/db/local.d/00-security-settings. For example: 
    [org/gnome/desktop/lockdown]
user-administration-disabled=true
    Once the settings have been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
    /org/gnome/desktop/lockdown/user-administration-disabled
    After the settings have been set, run dconf update.     To ensure the GUI does not allow user administratrion capabilities to all users, run the following command: 
    $ gsettings get org.gnome.desktop.lockdown user-administration-disabled
    If properly configured, the output should be true. To ensure that users cannot enable user administration, run the following: 
    $ grep user-administration /etc/dconf/db/local.d/locks/*
    If properly configured, the output should be /org/gnome/desktop/lockdown/user-administration-disabled     Allowing all users to have some administratrive capabilities to the system through the Graphical User Interface (GUI) when they would not have them otherwise could allow unintended configuration changes as well as a nefarious user the capability to make system changes such as adding new accounts, etc.     Disable Power Settings in GNOME3 By default, GNOME enables a power profile designed for mobile devices with battery usage. While useful for mobile devices, this setting should be disabled for all other systems. To configure the system to disable the power setting, add or set active to false in /etc/dconf/db/local.d/00-security-settings. For example: 
    [org/gnome/settings-daemon/plugins/power]
active=false
    Once the settings have been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
    /org/gnome/settings-daemon/plugins/power
    After the settings have been set, run dconf update.     To ensure that the GUI power settings are not active, run the following command: 
    $ gsettings get org.gnome.settings-daemon.plugins.power active
    If properly configured, the output should be false. To ensure that users cannot enable the power settings, run the following: 
    $ grep power /etc/dconf/db/local.d/locks/*
    If properly configured, the output should be /org/gnome/settings-daemon/plugins/power/active     Power settings should not be enabled on systems that are not mobile devices. Enabling power settings on non-mobile devices could have unintended processing consequences on standard systems.     Disable Geolocation in GNOME3 GNOME allows the clock and applications to track and access location information. This setting should be disabled as applications should not track system location. To configure the system to disable location tracking, add or set enabled to false in /etc/dconf/db/local.d/00-security-settings. For example: 
    [org/gnome/system/location]
enabled=false
    To configure the clock to disable location tracking, add or set geolocation to false in /etc/dconf/db/local.d/00-security-settings. For example: 
    [org/gnome/clocks]
geolocation=false
    Once the settings have been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
    /org/gnome/system/location/enabled
/org/gnome/clocks/geolocation
    After the settings have been set, run dconf update.     To ensure that system location tracking is not active, run the following command: 
    $ gsettings get org.gnome.system.location enabled
$ gsettings get org.gnome.clocks geolocation
    If properly configured, the output should be false. To ensure that users cannot enable system location tracking, run the following: 
    $ grep location /etc/dconf/db/local.d/locks/*
    If properly configured, the output should be /org/gnome/system/location/enabled and /org/gnome/clocks/geolocation.     Power settings should not be enabled on systems that are not mobile devices. Enabling power settings on non-mobile devices could have unintended processing consequences on standard systems.     GNOME Network Settings GNOME network settings that apply to the graphical interface. Disable WIFI Network Connection Creation in GNOME3 GNOME allows users to create ad-hoc wireless connections through the NetworkManager applet. Wireless connections should be disabled by adding or setting disable-wifi-create to true in /etc/dconf/db/local.d/00-security-settings. For example: 
    [org/gnome/nm-applet]
disable-wifi-create=true
    Once the settings have been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
    /org/gnome/nm-applet/disable-wifi-create
    After the settings have been set, run dconf update.     To ensure that WIFI connections caanot be created, run the following command: 
    $ gsettings get org.gnome.nm-applet disable-wifi-create
    If properly configured, the output should be true. To ensure that users cannot enable WIFI connection creation, run the following: 
    $ grep wifi-create /etc/dconf/db/local.d/locks/*
    If properly configured, the output should be /org/gnome/nm-applet/disable-wifi-create     Wireless network connections should not be allowed to be configured by general users on a given system as it could open the system to backdoor attacks.     Disable WIFI Network Notification in GNOME3 By default, GNOME disables WIFI notification. This should be permanently set so that users do not connect to a wireless network when the system finds one. While useful for mobile devices, this setting should be disabled for all other systems. To configure the system to disable the WIFI notication, add or set suppress-wireless-networks-available to true in /etc/dconf/db/local.d/00-security-settings. For example: 
    [org/gnome/nm-applet]
suppress-wireless-networks-available=true
    Once the settings have been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
    /org/gnome/nm-applet/suppress-wireless-networks-available
    After the settings have been set, run dconf update.     To ensure that wireless network notification is disabled, run the following command: 
    $ gsettings get org.gnome.nm-applet suppress-wireless-networks-available
    If properly configured, the output should be true. To ensure that users cannot enable wireless notification, run the following: 
    $ grep wireless-networks-available /etc/dconf/db/local.d/locks/*
    If properly configured, the output should be /org/gnome/nm-applet/suppress-wireless-networks-available     Wireless network connections should not be allowed to be configured by general users on a given system as it could open the system to backdoor attacks.     GNOME Remote Access Settings GNOME remote access settings that apply to the graphical interface. Require Credential Prompting for Remote Access in GNOME3 By default, GNOME does not require credentials when using Vino for remote access. To configure the system to require remote credentials, add or set authentication-methods to ['vnc'] in /etc/dconf/db/local.d/00-security-settings. For example: 
    [org/gnome/Vino]
authentication-methods=['vnc']
    Once the settings have been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
    /org/gnome/Vino/authentication-methods
    After the settings have been set, run dconf update.     To ensure that remote access requires credentials, run the following command: 
    $ gsettings get org.gnome.Vino authentication-methods
    If properly configured, the output should be false. To ensure that users cannot disable credentials for remote access, run the following: 
    $ grep authentication-methods /etc/dconf/db/local.d/locks/*
    If properly configured, the output should be /org/gnome/Vino/authentication-methods     Username and password prompting is required for remote access. Otherwise, non-authorized and nefarious users can access the system freely.     Require Encryption for Remote Access in GNOME3 By default, GNOME requires encryption when using Vino for remote access. To prevent remote access encryption from being disabled, add or set require-encryption to true in /etc/dconf/db/local.d/00-security-settings. For example: 
    [org/gnome/Vino]
require-encryption=true
    Once the settings have been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
    /org/gnome/Vino/require-encryption
    After the settings have been set, run dconf update.     To ensure that remote access connections are encrypted, run the following command: 
    $ gsettings get org.gnome.Vino require-encrpytion
    If properly configured, the output should be true. To ensure that users cannot disable encrypted remote connections, run the following: 
    $ grep require-encryption /etc/dconf/db/local.d/locks/*
    If properly configured, the output should be /org/gnome/Vino/require-encryption     Open X displays allow an attacker to capture keystrokes and to execute commands remotely.     GNOME Media Settings GNOME media settings that apply to the graphical interface. Disable GNOME3 Automounting The system's default desktop environment, GNOME3, will mount devices and removable media (such as DVDs, CDs and USB flash drives) whenever they are inserted into the system. To disable automount and autorun within GNOME3, add or set automount to false, automount-open to false, and autorun-never to true in /etc/dconf/db/local.d/00-security-settings. For example: 
    [org/gnome/desktop/media-handling]
automount=false
automount-open=false
autorun-never=true
    Once the settings have been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
    /org/gnome/desktop/media-handling/automount
/org/gnome/desktop/media-handling/auto-open
/org/gnome/desktop/media-handling/autorun-never
    After the settings have been set, run dconf update.     These settings can be verified by running the following: 
    $ gsettings get org.gnome.desktop.media-handling automount
$ gsettings get org.gnome.desktop.media-handling automount-open
$ gsettings get org.gnome.desktop.media-handling autorun-never
    If properly configured, the output for automount should be false. If properly configured, the output for automount-openshould be false. If properly configured, the output for autorun-never should be true. To ensure that users cannot enable automount and autorun in GNOME3, run the following: 
    $ grep 'automount\|autorun' /etc/dconf/db/local.d/locks/*
    If properly configured, the output for automount should be /org/gnome/desktop/media-handling/automount If properly configured, the output for automount-open should be /org/gnome/desktop/media-handling/auto-open If properly configured, the output for autorun-never should be /org/gnome/desktop/media-handling/autorun-never     Disabling automatic mounting in GNOME3 can prevent the introduction of malware via removable media. It will, however, also prevent desktop users from legitimate use of removable media.     Disable All GNOME3 Thumbnailers The system's default desktop environment, GNOME3, uses a number of different thumbnailer programs to generate thumbnails for any new or modified content in an opened folder. To disable the execution of these thumbnail applications, add or set disable-all to true in /etc/dconf/db/local.d/00-security-settings. For example: 
    [org/gnome/desktop/thumbnailers]
disable-all=true
    Once the settings have been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
    /org/gnome/desktop/thumbnailers/disable-all
    After the settings have been set, run dconf update. This effectively prevents an attacker from gaining access to a system through a flaw in GNOME3's Nautilus thumbnail creators.     These settings can be verified by running the following: 
    $ gsettings get org.gnome.desktop.thumbnailers disable-all
    If properly configured, the output should be true. To ensure that users cannot how long until the the screensaver locks, run the following: 
    $ grep disable-all /etc/dconf/db/local.d/locks/*
    If properly configured, the output should be /org/gnome/desktop/thumbnailers/disable-all     An attacker with knowledge of a flaw in a GNOME3 thumbnailer application could craft a malicious file to exploit this flaw. Assuming the attacker could place the malicious file on the local filesystem (via a web upload for example) and assuming a user browses the same location using Nautilus, the malicious file would exploit the thumbnailer with the potential for malicious code execution. It is best to disable these thumbnailer applications unless they are explicitly required.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/software/integrity.xml000066400000000000000000000547151301675746700266630ustar00rootroot00000000000000 Software Integrity Checking Both the AIDE (Advanced Intrusion Detection Environment) software and the RPM package management system provide mechanisms for verifying the integrity of installed software. AIDE uses snapshots of file metadata (such as hashes) and compares these to current system files in order to detect changes. The RPM package management system can conduct integrity checks by comparing information in its metadata database with files installed on the system.

    Integrity checking cannot prevent intrusions, but can detect that they have occurred. Requirements for software integrity checking may be highly dependent on the environment in which the system will be used. Snapshot-based approaches such as AIDE may induce considerable overhead in the presence of frequent software updates.     Disable Prelinking The prelinking feature changes binaries in an attempt to decrease their startup time. In order to disable it, change or add the following line inside the file /etc/sysconfig/prelink: 
    PRELINKING=no
    Next, run the following command to return binaries to a normal, non-prelinked state: 
    $ sudo /usr/sbin/prelink -ua
     Because the prelinking feature changes binaries, it can interfere with the operation of certain software and/or modes such as AIDE, FIPS, etc.     Verify Integrity with AIDE AIDE conducts integrity checks by comparing information about files with previously-gathered information. Ideally, the AIDE database is created immediately after initial system configuration, and then again after any software update. AIDE is highly configurable, with further configuration information located in /usr/share/doc/aide-VERSION. Install AIDE Install the AIDE package with the command: 
    $ sudo yum install aide
     The AIDE package must be installed if it is to be available for integrity checking.     Build and Test AIDE Database Run the following command to generate a new database: 
    $ sudo /usr/sbin/aide --init
    By default, the database will be written to the file /var/lib/aide/aide.db.new.gz. Storing the database, the configuration file /etc/aide.conf, and the binary /usr/sbin/aide (or hashes of these files), in a secure location (such as on read-only media) provides additional assurance about their integrity. The newly-generated database can be installed as follows: 
    $ sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
    To initiate a manual check, run the following command: 
    $ sudo /usr/sbin/aide --check
    If this check produces any unexpected output, investigate.     To find the location of the AIDE databse file, run the following command: 
    $ sudo ls -l DBDIR/database_file_name
     For AIDE to be effective, an initial database of "known-good" information about files must be captured and it should be able to be verified against the installed files.     Configure Periodic Execution of AIDE To implement a daily execution of AIDE at 4:05am using cron, add the following line to /etc/crontab: 
    05 4 * * * root /usr/sbin/aide --check
    AIDE can be executed periodically through other means; this is merely one example.     To determine that periodic AIDE execution has been scheduled, run the following command: 
    $ grep aide /etc/crontab
     By default, AIDE does not install itself for periodic execution. Periodically running AIDE is necessary to reveal unexpected changes in installed files.     Verify Integrity with RPM The RPM package management system includes the ability to verify the integrity of installed packages by comparing the installed files with information about the files taken from the package metadata stored in the RPM database. Although an attacker could corrupt the RPM database (analogous to attacking the AIDE database as described above), this check can still reveal modification of important files. To list which files on the system differ from what is expected by the RPM database: 
    $ rpm -qVa
    See the man page for rpm to see a complete explanation of each column.     Verify and Correct File Permissions with RPM Discretionary access control is weakened if a user or group has access permissions to system files and directories greater than the default. The RPM package management system can check file access permissions of installed software packages, including many that are important to system security. Verify that the file permissions, ownership, and gruop membership of system files and commands match vendor values. Check the file permissions, ownership, and group membership with the following command: 
    $ sudo rpm -Va | grep '^.M'
    Output indicates files that do not match vendor defaults. After locating a file with incorrect permissions, run the following command to determine which package owns it: 
    $ rpm -qf FILENAME

    Next, run the following command to reset its permissions to the correct values: 
    $ sudo rpm --setperms PACKAGENAME

     The following command will list which files on the system have permissions different from what is expected by the RPM database: 
    $ rpm -Va | grep '^.M'
     Permissions on system binaries and configuration files that are too generous could allow an unauthorized user to gain privileges that they should not have. The permissions set by the vendor should be maintained. Any deviations from this baseline should be investigated. Note: Due to a bug in the gdm package, the RPM verify command may continue to fail even after file permissions have been correctly set on /var/log/gdm. This is being tracked in Red Hat Bugzilla #1275532.     Verify File Hashes with RPM Without cryptographic integrity protections, system executables and files can be altered by unauthorized users without detection. The RPM package management system can check the hashes of installed software packages, including many that are important to system security. To verify that the cryptographic hash of system files and commands match vendor values, run the following command to list which files on the system have hashes that differ from what is expected by the RPM database: 
    $ rpm -Va | grep '^..5'
    A "c" in the second column indicates that a file is a configuration file, which may appropriately be expected to change. If the file was not expected to change, investigate the cause of the change using audit logs or other means. The package can then be reinstalled to restore the file. Run the following command to determine which package owns the file: 
    $ rpm -qf FILENAME
    The package can be reinstalled from a yum repository using the command: 
    $ sudo yum reinstall PACKAGENAME
    Alternatively, the package can be reinstalled from trusted media using the command: 
    $ sudo rpm -Uvh PACKAGENAME
     The following command will list which files on the system have file hashes different from what is expected by the RPM database. 
    $ rpm -Va | awk '$1 ~ /..5/ && $2 != "c"'
     The hashes of important files like system executables should match the information given by the RPM database. Executables with erroneous hashes could be a sign of nefarious activity on the system.     Additional Security Software Additional security software that is not provided or supported by Red Hat can be installed to provide complementary or duplicative security capabilities to those provided by the base platform. Add-on software may not be appropriate for some specialized systems. Install Intrusion Detection Software The base Red Hat platform already includes a sophisticated auditing system that can detect intruder activity, as well as SELinux, which provides host-based intrusion prevention capabilities by confining privileged programs and user sessions which may become compromised. Note in DoD environments, supplemental intrusion detection tools, such as the McAfee Host-based Security System, are available to integrate with existing infrastructure. When these supplemental tools interfere with proper functioning of SELinux, SELinux takes precedence. Inspect the system to determine if intrusion detection software has been installed. Verify this intrusion detection software is active. Host-based intrusion detection tools provide a system-level defense when an intruder gains access to a system or network. Install Virus Scanning Software Install virus scanning software, which uses signatures to search for the presence of viruses on the filesystem. Ensure virus definition files are no older than 7 days, or their last release. Configure the virus scanning software to perform scans dynamically on all accessed files. If this is not possible, configure the system to scan all altered files on the system on a daily basis. If the system processes inbound SMTP mail, configure the virus scanner to scan all received mail. Inspect the system for a cron job or system service which executes a virus scanning tool regularly.
    To verify the McAfee VSEL system service is operational, run the following command: 
    $ sudo /sbin/service nails status

    To check on the age of uvscan virus definition files, run the following command: 
    $ sudo cd /opt/NAI/LinuxShield/engine/dat
$ sudo ls -la avvscan.dat avvnames.dat avvclean.dat
     Virus scanning software can be used to detect if a system has been compromised by computer viruses, as well as to limit their spread to other systems.     McAfee Security Software In DoD environments, McAfee Host-based Security System (HBSS) and VirusScan Enterprise for Linux is required to be installed on all systems. Install McAfee Host-Based Intrusion Detection Software (HBSS) Install the McAfee Host-based Security System (HBSS) application. To verify that McAfee HBSS is installed, run the following command(s): 
    $ sudo ls /opt/McAfee/accm/bin/accm
    $ sudo ls /opt/McAfee/auditengine/bin/auditmanager
    $ rpm -q MFEcma && rpm -q MFErt
     Without a host-based intrusion detection tool, there is no system-level defense when an intruder gains access to a system or network. Additionally, a host-based intrusion prevention tool can provide methods to immediately lock out detected intrusion attempts.     Install McAfee Virus Scanning Software Install McAfee VirusScan Enterprise for Linux antivirus software which is provided for DoD systems and uses signatures to search for the presence of viruses on the filesystem. To verify that McAfee VirusScan Enterprise for Linux is installed and running, run the following command(s): 
    $ sudo systemctl status nails
    $ rpm -q McAfeeVSEForLinux
     Virus scanning software can be used to detect if a system has been compromised by computer viruses, as well as to limit their spread to other systems.     Enable nails Service The nails service is used to run McAfee VirusScan Enterprise for Linux and McAfee Host-based Security System (HBSS) services. Virus scanning software can be used to detect if a system has been compromised by computer viruses, as well as to limit their spread to other systems. Virus Scanning Software Definitions Are Updated Ensure virus definition files are no older than 7 days or their last release. To check on the age of McAfee virus definition files, run the following command: 
    $ sudo cd /opt/NAI/LinuxShield/engine/dat
$ sudo ls -la avvscan.dat avvnames.dat avvclean.dat
     Virus scanning software can be used to detect if a system has been compromised by computer viruses, as well as to limit their spread to other systems.     Federal Information Processing Standard (FIPS) The Federal Information Processing Standard (FIPS) is a computer security standard which is developed by the U.S. Government and industry working groups to validate the quality of cryptographic modules. The FIPS standard provides four security levels to ensure adequate coverage of different industries, implementation of cryptographic modules, and organizational sizes and requirements.

    FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets industry and government requirements. For government systems, this allows Security Levels 1, 2, 3, or 4 for use on Red Hat Enterprise Linux.

    See http://csrc.nist.gov/publications/PubsFIPS.html for more information.     Install the dracut-fips Package To enable FIPS, the system requires that the dracut-fips package be installed. Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The operating system must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated. Enable FIPS Mode in GRUB2 To ensure FIPS mode is enabled, rebuild initramfs by running the following command: 
    dracut -f
    After the dracut command has been run, add the argument fips=1 to the default GRUB 2 command line for the Linux operating system in /etc/default/grub, in the manner below: 
    GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=VolGroup/LogVol06 rd.lvm.lv=VolGroup/lv_swap rhgb quiet rd.shell=0 fips=1"
    Finally, rebuild the grub.cfg file by using the 
    grub2-mkconfig -o
    command as follows:
    • On BIOS-based machines, issue the following command as root: 
      ~]# grub2-mkconfig -o /boot/grub2/grub.cfg
    • On UEFI-based machines, issue the following command as root: 
      ~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
     To verify that FIPS is enabled properly in grub, run the following command: 
    $ grep fips /etc/default/grub
    The output should contain fips=1     Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The operating system must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated. Running 
    dracut -f
    will overwrite the existing initramfs file.     The system needs to be rebooted for these changes to take effect. The ability to enable FIPS does not denote FIPS compliancy or certification. Red Hat, Inc. and Red Hat Enterprise Linux are respectively FIPS certified and compliant. Community projects such as CentOS, Scientific Linux, etc. do not necessarily meet FIPS certification and compliancy. Therefore, non-certified vendors and/or projects do not meet this requirement even if technically feasible.

    See http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401vend.htm for a list of FIPS certified vendors.         Operating System Vendor Support and Certification The assurance of a vendor to provide operating system support and maintenance for their product is an important criterion to ensure product stability and security over the life of the product. A certified product that follows the necessary standards and government certification requirements guarantees that known software vulnerabilities will be remediated, and proper guidance for protecting and securing the operating system will be given. The Installed Operating System Is Vendor Supported and Certified The installed operating system must be maintained and certified by a vendor. Red Hat Enterprise Linux is supported by Red Hat, Inc. As the Red Hat Enterprise Linux vendor, Red Hat, Inc. is responsible for providing security patches as well as meeting and maintaining goverment certifications and standards. To verify that the installed operating system is supported or certified, run the following command: 
    $ grep -i "red hat" /etc/redhat-release
    The output should contain something similar to: 
    Red Hat Enterprise Linux Server 7.3 (Maipo)
     An operating system is considered "supported" if the vendor continues to provide security patches for the product as well as maintain government certification requirements. With an unsupported release, it will not be possible to resolve security issue discovered in the system software as well as meet government certifications.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/software/sudo.xml000066400000000000000000000056671301675746700256210ustar00rootroot00000000000000 Sudo Sudo, which stands for "su 'do'", provides the ability to delegate authority to certain users, groups of users, or system administrators. When configured for system users and/or groups, Sudo can allow a user or group to execute privileged commands that normally only root is allowed to execute.

    For more information on Sudo and addition Sudo configuration options, see https://www.sudo.ws     Ensure Users Re-Authenticate for Privilege Escalation - sudo NOPASSWD The sudo NOPASSWD tag, when specified, allows a user to execute commands using sudo without having to authenticate. This should be disabled by making sure that the NOPASSWD tag does not exist in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/. To determine if NOPASSWD has been configured for sudo, run the following command: 
    $ sudo grep -ri nopasswd /etc/sudoers /etc/sudoers.d/
    The command should return no output.     Without re-authentication, users may access resources or perform tasks for which they do not have authorization.

    When operating systems provide the capability to escalate a functional capability, it is critical that the user re-authenticate.     Ensure Users Re-Authenticate for Privilege Escalation - sudo !authenticate The sudo !authenticate option, when specified, allows a user to execute commands using sudo without having to authenticate. This should be disabled by making sure that the !authenticate option does not exist in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/. To determine if !authenticate has not been configured for sudo, run the following command: 
    $ sudo grep -r \!authenticate /etc/sudoers /etc/sudoers.d/
    The command should return no output.     Without re-authentication, users may access resources or perform tasks for which they do not have authorization.

    When operating systems provide the capability to escalate a functional capability, it is critical that the user re-authenticate.     scap-security-guide-0.1.31/SUSE/12/input/xccdf/system/software/updating.xml000066400000000000000000000301701301675746700264450ustar00rootroot00000000000000 Updating Software The yum command line tool is used to install and update software packages. The system also provides a graphical software update tool in the System menu, in the Administration submenu, called Software Update.

    Red Hat Enterprise Linux systems contain an installed software catalog called the RPM database, which records metadata of installed packages. Consistently using yum or the graphical Software Update for all software installation allows for insight into the current inventory of installed software on the system.     Ensure Red Hat GPG Key Installed To ensure the system can cryptographically verify base software packages come from Red Hat (and to connect to the Red Hat Network to receive them), the Red Hat GPG key must properly be installed. To install the Red Hat GPG key, run: 
    $ sudo rhn_register
    If the system is not connected to the Internet or an RHN Satellite, then install the Red Hat GPG key from trusted media such as the Red Hat installation CD-ROM or DVD. Assuming the disc is mounted in /media/cdrom, use the following command as the root user to import it into the keyring: 
    $ sudo rpm --import /media/cdrom/RPM-GPG-KEY
     To ensure that the GPG key is installed, run: 
    $ rpm -q --queryformat "%{SUMMARY}\n" gpg-pubkey
    The command should return the string below: 
    gpg(Red Hat, Inc. (release key 2)  <security@redhat.com>
     Changes to software components can have significant effects on the overall security of the operating system. This requirement ensures the software has not been tampered with and that it has been provided by a trusted vendor. The Red Hat GPG key is necessary to cryptographically verify packages are from Red Hat.     Ensure gpgcheck Enabled In Main Yum Configuration The gpgcheck option controls whether RPM packages' signatures are always checked prior to installation. To configure yum to check package signatures before installing them, ensure the following line appears in /etc/yum.conf in the [main] section: 
    gpgcheck=1
     To determine whether yum is configured to use gpgcheck, inspect /etc/yum.conf and ensure the following appears in the [main] section: 
    gpgcheck=1
    A value of 1 indicates that gpgcheck is enabled. Absence of a gpgcheck line or a setting of 0 indicates that it is disabled.     Changes to any software components can have significant effects on the overall security of the operating system. This requirement ensures the software has not been tampered with and that it has been provided by a trusted vendor.
    Accordingly, patches, service packs, device drivers, or operating system components must be signed with a certificate recognized and approved by the organization.
    Verifying the authenticity of the software prior to installation validates the integrity of the patch or upgrade received from a vendor. This ensures the software has not been tampered with and that it has been provided by a trusted vendor. Self-signed certificates are disallowed by this requirement. Certificates used to verify the software must be from an approved Certificate Authority (CA).     Ensure gpgcheck Enabled For All Yum Package Repositories To ensure signature checking is not disabled for any repos, remove any lines from files in /etc/yum.repos.d of the form: 
    gpgcheck=0
     To determine whether yum has been configured to disable gpgcheck for any repos, inspect all files in /etc/yum.repos.d and ensure the following does not appear in any sections: 
    gpgcheck=0
    A value of 0 indicates that gpgcheck has been disabled for that repo.     Verifying the authenticity of the software prior to installation validates the integrity of the patch or upgrade received from a vendor. This ensures the software has not been tampered with and that it has been provided by a trusted vendor. Self-signed certificates are disallowed by this requirement. Certificates used to verify the software must be from an approved Certificate Authority (CA).     Ensure Software Patches Installed If the system is joined to the Red Hat Network, a Red Hat Satellite Server, or a yum server, run the following command to install updates: 
    $ sudo yum update
    If the system is not configured to use one of these sources, updates (in the form of RPM packages) can be manually downloaded from the Red Hat Network and installed using rpm.

    NOTE: U.S. Defense systems are required to be patched within 30 days or sooner as local policy dictates.     If the system is joined to the Red Hat Network, a Red Hat Satellite Server, or a yum server which provides updates, invoking the following command will indicate if updates are available: 
    $ sudo yum check-update


    If the system is not configured to update from one of these sources, run the following command to list when each package was last updated: 
    $ rpm -qa -last


    Compare this to Red Hat Security Advisories (RHSA) listed at https://access.redhat.com/security/updates/active/ to determine if the system is missing applicable updates.     Installing software updates is a fundamental mitigation against the exploitation of publicly-known vulnerabilities. If the most recent security patches and updates are not installed, unauthorized users may take advantage of weaknesses in the unpatched software. The lack of prompt attention to patching could result in a system compromise.     Ensure YUM Removes Previous Package Versions Yum should be configured to remove previous software components after previous versions have been installed. To configure yum to remove the previous software components after updating, set the clean_requirements_on_remove to 1 in /etc/yum.conf. To verify that clean_requirements_on_remove is configured properly, run the following command: 
    $ grep clean_requirements_on_remove /etc/yum.conf
    The output should return something similar to: 
    clean_requirements_on_remove=1
     Previous versions of software components that are not removed from the information system after updates have been installed may be exploited by some adversaries.     Ensure gpgcheck Enabled for Local Packages Yum should be configured to verify the signature(s) of local packages prior to installation. To configure yum to verify signatures of local packages, set the localpkg_gpgcheck to 1 in /etc/yum.conf. To verify that localpkg_gpgcheck is configured properly, run the following command: 
    $ grep localpkg_gpgcheck /etc/yum.conf
    The output should return something similar to: 
    localpkg_gpgcheck=1
     Changes to any software components can have significant effects to the overall security of the operating system. This requirement ensures the software has not been tampered and has been provided by a trusted vendor.

    Accordingly, patches, service packs, device drivers, or operating system components must be signed with a certificate recognized and approved by the organization.     Ensure gpgcheck Enabled for Repository Metadata Verify the operating system prevents the installation of patches, service packs, device drivers, or operating system components of local packages without verification of the repository metadata.

    Check that yum verifies the repository metadata prior to install with the following command. This should be configured by setting repo_gpgcheck to 1 in /etc/yum.conf.     To verify that repo_gpgcheck is configured properly, run the following command: 
    $ grep repo_gpgcheck /etc/yum.conf
    The output should return something similar to: 
    repo_gpgcheck=1
     Changes to any software components can have significant effects to the overall security of the operating system. This requirement ensures the software has not been tampered and has been provided by a trusted vendor.

    Accordingly, patches, service packs, device drivers, or operating system components must be signed with a certificate recognized and approved by the organization.

    Verifying the authenticity of the software prior to installation validates the integrity of the patch or upgrade received from a vendor. This ensures the software has not been tampered with and that it has been provided by a trusted vendor. Self-signed certificates are disallowed by this requirement. The operating system should not have to verify the software again.

    NOTE: For U.S. Military systems, this requirement does not mandate DoD certificates for this purpose; however, the certificate used to verify the software must be from an approved Certificate Authority.     scap-security-guide-0.1.31/SUSE/12/transforms/000077500000000000000000000000001301675746700207015ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/12/transforms/cce_extract.py000077500000000000000000000003551301675746700235450ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import cce_extract_module if __name__ == "__main__": cce_extract_module.main() scap-security-guide-0.1.31/SUSE/12/transforms/cci2html.xsl000066400000000000000000000004711301675746700231400ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/12/transforms/constants.xslt000066400000000000000000000022551301675746700236350ustar00rootroot00000000000000 SUSE Linux Enterprise 12 SUSE 12 SUSE_12_STIG SUSE-12 cpe:/o:suse:linux_enterprise_server:12 suse12 scap-security-guide-0.1.31/SUSE/12/transforms/shorthand2xccdf.xslt000066400000000000000000000005151301675746700247020ustar00rootroot00000000000000 unknown unlinked-sle12-oval.xml scap-security-guide-0.1.31/SUSE/12/transforms/splitchecks.py000077500000000000000000000003551301675746700235750ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import splitchecks_module if __name__ == "__main__": splitchecks_module.main() scap-security-guide-0.1.31/SUSE/12/transforms/table-add-srgitems.xslt000066400000000000000000000011011301675746700252560ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/12/transforms/table-sortbyref.xslt000066400000000000000000000005601301675746700247220ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/12/transforms/table-srgmap.xslt000066400000000000000000000011431301675746700241720ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/12/transforms/table-style.xslt000066400000000000000000000002541301675746700240430ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/12/transforms/xccdf-alt-titles.xslt000066400000000000000000000005051301675746700247640ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/12/transforms/xccdf-apply-overlay-stig.xslt000066400000000000000000000007541301675746700264600ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/12/transforms/xccdf-removeaux.xslt000066400000000000000000000005041301675746700247140ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/12/transforms/xccdf2csv-stig.py000077500000000000000000000003631301675746700241110ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import xccdf2csv_stig_module if __name__ == "__main__": xccdf2csv_stig_module.main() scap-security-guide-0.1.31/SUSE/12/transforms/xccdf2html.xslt000066400000000000000000000005531301675746700236560ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/12/transforms/xccdf2shorthand.xslt000066400000000000000000000005041301675746700247000ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/12/transforms/xccdf2stigformat.xslt000066400000000000000000000007001301675746700250630ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/12/transforms/xccdf2table-byref.xslt000066400000000000000000000006771301675746700251150ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/12/transforms/xccdf2table-cce.xslt000066400000000000000000000007361301675746700245340ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/12/transforms/xccdf2table-profileccirefs.xslt000066400000000000000000000016021301675746700267720ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/12/transforms/xccdf2table-profilecisrefs.xslt000066400000000000000000000007101301675746700270110ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/12/transforms/xccdf2table-profilenistrefs.xslt000066400000000000000000000007101301675746700272100ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/12/transforms/xccdf2table-stig.xslt000066400000000000000000000006761301675746700247530ustar00rootroot00000000000000 scap-security-guide-0.1.31/SUSE/12/utils/000077500000000000000000000000001301675746700176435ustar00rootroot00000000000000scap-security-guide-0.1.31/SUSE/12/utils/README000066400000000000000000000010241301675746700205200ustar00rootroot00000000000000This file is meant to give a quick overview to some of the scripts located in this directory. verify-input-sanity.py Purpose: This script can be invoked without arguments to examine the files within src/input to make sure that they are in good shape *prior to* building the XCCDF and OVAL content with the various make commands. Intent: Help XCCDF and OVAL developers spot common mistakes *before* utilizing the Makefile to build the XCCDF and OVAL content. Usage: ../../../shared/utils/verify-input-sanity.py scap-security-guide-0.1.31/SUSE/12/utils/sync-alt-titles.py000077500000000000000000000003651301675746700232600ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import sync_alt_titles_module if __name__ == "__main__": sync_alt_titles_module.main() scap-security-guide-0.1.31/SUSE/12/utils/verify-cce.py000077500000000000000000000003531301675746700222550ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import verify_cce_module if __name__ == "__main__": verify_cce_module.main() scap-security-guide-0.1.31/Ubuntu/000077500000000000000000000000001301675746700167645ustar00rootroot00000000000000scap-security-guide-0.1.31/Ubuntu/16.04/000077500000000000000000000000001301675746700174345ustar00rootroot00000000000000scap-security-guide-0.1.31/Ubuntu/16.04/Makefile000066400000000000000000000164501301675746700211020ustar00rootroot00000000000000all: tables guide content dist SHARED = ../../shared include $(SHARED)/product-make.include PROD = ubuntu1604 OVAL_DIRS = $(SHARED_OVAL) $(OUT)/oval templates/static/oval VENDOR = ssgproject checks: # If openscap on the system supports OVAL-5.11 language version, include also OVAL-5.11 checks # add local Ubuntu1604 specific templated ovals # into final list of OVAL checks ifeq ($(OVAL_5_11), 0) # System supports OVAL-5.11 => propagate 'RUNTIME_OVAL_VERSION' variable into the environment $(eval MOD_ENV := env RUNTIME_OVAL_VERSION='5.11') $(eval OVAL_DIRS+=$(SHARED_OVAL_5_11) $(OUT)/oval templates/static/oval_5.11) endif find $(OVAL_DIRS) -name "*.xml" | xargs xmlwf $(SHARED)/utils/generate-from-templates.py --oval_version $(OVAL_VERSION) --input ./templates --output $(OUT) --language oval build $(MOD_ENV) $(SHARED)/$(UTILS)/combine-ovals.py $(CONF) $(PROD) $(OVAL_DIRS) > $(OUT)/unlinked-$(PROD)-oval.xml xmllint --format --output $(OUT)/unlinked-$(PROD)-oval.xml $(OUT)/unlinked-$(PROD)-oval.xml table-refs: $(OUT)/xccdf-unlinked-empty-groups.xml xsltproc -stringparam ref "nist" -o $(OUT)/table-$(PROD)-nistrefs.html $(TRANS)/xccdf2table-byref.xslt $< xsltproc -stringparam profile "common" -o $(OUT)/table-$(PROD)-nistrefs-common.html \ $(TRANS)/xccdf2table-profilenistrefs.xslt $< xsltproc -stringparam profile "ospp-$(PROD)-server" -o $(OUT)/table-$(PROD)-nistrefs-ospp.html \ $(TRANS)/xccdf2table-profilenistrefs.xslt $< xsltproc -stringparam ref "anssi" -o $(OUT)/table-$(PROD)-anssirefs.html $(TRANS)/xccdf2table-byref.xslt $< xsltproc -stringparam profile "common" -o $(OUT)/table-$(PROD)-anssirefs-common.html \ $(TRANS)/xccdf2table-profileanssirefs.xslt $< table-idents: $(OUT)/xccdf-unlinked-empty-groups.xml xsltproc -o $(OUT)/table-$(PROD)-cces.html $(TRANS)/xccdf2table-cce.xslt $< table-srgmap: $(OUT)/xccdf-unlinked-empty-groups.xml # the map-to-items filename must be provided relative to the root of the main document being processed xsltproc -stringparam map-to-items "../$<" -o $(OUT)/table-$(PROD)-srgmap.html \ $(TRANS)/table-srgmap.xslt $(REFS)/disa-os-srg-v1r4.xml xsltproc -stringparam flat "y" -stringparam map-to-items "../$<" -o $(OUT)/table-$(PROD)-srgmap-flat.html \ $(TRANS)/table-srgmap.xslt $(REFS)/disa-os-srg-v1r4.xml xmllint --xmlout --html --output $(OUT)/table-$(PROD)-srgmap-flat.xhtml $(OUT)/table-$(PROD)-srgmap-flat.html table-stigs: $(OUT)/xccdf-unlinked-final.xml table-srgmap checks xsltproc -o $(OUT)/table-$(PROD)-stig.html $(TRANS)/xccdf2table-stig.xslt $(REFS)/disa-stig-$(PROD)-v1r0.6-xccdf.xml xsltproc -o $(OUT)/table-$(PROD)-stig-manual.html $(TRANS)/xccdf2table-stig.xslt $(REFS)/disa-stig-$(PROD)-v1r0.6-xccdf-manual.xml # temporarily retain an output file showing the short titles as well xsltproc -stringparam profile "stig-$(PROD)-server" -stringparam testinfo "y" -o $(OUT)/table-stig-$(PROD)-testinfo.html \ $(TRANS)/xccdf2table-profileccirefs.xslt $< xsltproc -stringparam overlay "../$(IN)/auxiliary/stig_overlay.xml" -o $(OUT)/unlinked-stig-$(PROD)-xccdf.xml \ $(TRANS)/xccdf-apply-overlay-stig.xslt $< xsltproc -o $(OUT)/table-$(PROD)-stig.html $(TRANS)/xccdf2table-stig.xslt $(OUT)/unlinked-stig-$(PROD)-xccdf.xml tables: table-refs table-idents table-srgmap content: $(OUT)/xccdf-unlinked-final.xml checks cp $< $(OUT)/unlinked-$(PROD)-xccdf.xml # Remove auxiliary Groups which are only for use in tables, and not guide output. xsltproc -o $(OUT)/unlinked-$(PROD)-xccdf-guide.xml $(TRANS)/xccdf-removeaux.xslt $(OUT)/unlinked-$(PROD)-xccdf.xml # The relabel-ids.py script chdirs to ./output, so refer to files from there. # Its second argument controls the IDs, as well as the output filenames. # Thus, with ID set to ssg, this creates ssg-$(PROD)-xccdf.xml and ssg-$(PROD)-oval.xml. $(SHARED)/$(UTILS)/cpe-generate.py $(OUT)/unlinked-$(PROD)-oval.xml $(IN)/oval/platform/$(PROD)-cpe-dictionary.xml $(ID) $(SHARED)/$(UTILS)/relabel-ids.py unlinked-$(PROD)-xccdf.xml $(ID) $(SHARED)/$(UTILS)/relabel-ids.py xccdf-unlinked-ocilrefs.xml $(ID) # Once things are relabelled, create a datastream xsltproc --stringparam reverse_DNS org.$(VENDOR).content /usr/share/openscap/xsl/xccdf_1.1_to_1.2.xsl \ $(OUT)/$(ID)-$(PROD)-xccdf.xml > $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml # Update @style attribute of to "SCAP_1.2". Fixes #1059 sed -i 's/style="SCAP_1.1"/style="SCAP_1.2"/' $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml oscap ds sds-compose $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml $(OUT)/$(ID)-$(PROD)-ds.xml # Update @schematron-version attribute in datastream to "1.2". Fixes #1191 # (Workaround for https://github.com/OpenSCAP/openscap/issues/383) sed -i 's/schematron-version="[0-9].[0-9]"/schematron-version="1.2"/' $(OUT)/$(ID)-$(PROD)-ds.xml # Add in CPE and OVAL content to datastream oscap ds sds-add $(OUT)/$(ID)-$(PROD)-cpe-dictionary.xml $(OUT)/$(ID)-$(PROD)-ds.xml oscap ds sds-add $(OUT)/$(ID)-$(PROD)-oval.xml $(OUT)/$(ID)-$(PROD)-ds.xml # Fixes https://github.com/OpenSCAP/scap-security-guide/issues/1100 # Fixes https://github.com/OpenSCAP/scap-security-guide/issues/1101 $(SHARED)/$(UTILS)/sds-move-ocil-to-checks.py $(OUT)/$(ID)-$(PROD)-ds.xml $(OUT)/$(ID)-$(PROD)-ds.xml guide: content ifeq ($(OPENSCAP_1_1_OR_LATER), 0) $(SHARED)/$(UTILS)/build-all-guides.py --input $(OUT)/$(ID)-$(PROD)-ds.xml else @echo "Building guides from XCCDF 1.1, use OpenSCAP 1.1.0 or later for guides from datastreams!" $(SHARED)/$(UTILS)/build-all-guides.py --input $(OUT)/$(ID)-$(PROD)-xccdf.xml endif validate-xml: oscap xccdf validate-xml $(OUT)/$(ID)-$(PROD)-xccdf.xml oscap oval validate-xml $(OUT)/$(ID)-$(PROD)-oval.xml oscap cpe validate-xml $(OUT)/$(ID)-$(PROD)-cpe-dictionary.xml # not yet clean. To be updated # oscap oval validate-xml $(OUT)/$(ID)-$(PROD)-cpe-oval.xml # oscap ds sds-validate $(OUT)/$(ID)-$(PROD)-ds.xml validate: validate-xml ifeq ($(OVAL_5_11), 0) cd $(OUT); ../$(SHARED)/$(UTILS)/verify-references.py --rules-with-invalid-checks --ovaldefs-unused $(ID)-$(PROD)-xccdf.xml else # If we are building against oscap version not supporting OVAL-5.11 language version yet, # don't call verify-references.py with "--rules-with-invalid-checks" argument, since the # OVAL checks using the 5.11 OVAL version will not be included in that case @echo -e "\nWarning:\n" @echo -e "\tUbuntu 1604 content build using oscap not supporting OVAL-5.11 language version detected!" @echo -e "\tSince the OVAL-5.11 Fedora OVAL checks are missing, will skip test for referenced," @echo -e "\tbut undefined OVAL definitions during content validation. Consider building Ubuntu 1604" @echo -e "\tcontent with version OpenSCAP-1.2.2, or newer in order to perform full content validation!\n" cd $(OUT); ../$(SHARED)/$(UTILS)/verify-references.py --ovaldefs-unused $(ID)-$(PROD)-xccdf.xml endif oscap oval validate-xml --schematron $(OUT)/$(ID)-$(PROD)-oval.xml # Items in dist are expected for distribution in an rpm dist: guide content mkdir -p $(DIST)/guide $(DIST)/content cp $(OUT)/*-guide-*.html $(DIST)/guide cp $(OUT)/$(ID)-$(PROD)-xccdf.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-oval.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-ocil.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-cpe-dictionary.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-cpe-oval.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-ds.xml $(DIST)/content clean: rm -rf $(OUT)/* rm -rf $(DIST)/content $(DIST)/guide rm -rf $(BUILD) scap-security-guide-0.1.31/Ubuntu/16.04/README000066400000000000000000000031201301675746700203100ustar00rootroot00000000000000Directory Structure of scap-security-guide ------------------------------------------ The input directory contains source files that generate SCAP content, such as XCCDF and OVAL. Since a single large XML file is an impractical format for multiple authors to collaborate on editing SCAP content, efforts are made to keep logically related guidance and checking content in individual files. The transforms directory contains resources that enable the files inside the input directory (or output directory) to be combined and reformatted into valid SCAP formats or human-readable formats. The output directory is used as a storage area for items generated by the files in the inputs directory. It should be empty in the repository, and built on users' individual systems (and rely on its .gitignore file to keep such files out). The output directory contains transitional output (which may only exist in order to be further transformed) as well as final output. The references directory should contain documents which are specified as references from within the SCAP content, or documents that are "seeds," viz. documents whose prose will be translated into SCAP formats, as well as other examples of SCAP content. The utils directory contains helper scripts and other items that are useful to developers but are not essential to producing the project's output. The dist directory contains final outputs, which could be shipped in an RPM for consumption by end-users. Updating the Makefile to copy an item from the outputs directory to the dist directory indicates that an item is considered a final output. scap-security-guide-0.1.31/Ubuntu/16.04/input/000077500000000000000000000000001301675746700205735ustar00rootroot00000000000000scap-security-guide-0.1.31/Ubuntu/16.04/input/auxiliary/000077500000000000000000000000001301675746700226025ustar00rootroot00000000000000scap-security-guide-0.1.31/Ubuntu/16.04/input/auxiliary/stig_overlay.xml000066400000000000000000003643741301675746700260540ustar00rootroot00000000000000 The system must use a separate file system for /tmp. The system must use a separate file system for /var. The system must use a separate file system for /var/log. The system must use a separate file system for the system audit data path. The audit system must alert designated staff members when the audit storage volume approaches capacity. The system must use a separate file system for user home directories. Vendor-provided cryptographic certificates must be installed to verify the integrity of system software. The Red Hat Network Service (rhnsd) service must not be running, unless using RHN or an RHN Satellite. System security patches and updates must be installed and up-to-date. The system package management tool must cryptographically verify the authenticity of system software packages during installation. The system package management tool must cryptographically verify the authenticity of all software packages during installation. A file integrity tool must be installed. The system must use a Linux Security Module at boot time. There must be no .rhosts or hosts.equiv files on the system. The system must use a Linux Security Module configured to enforce limits on system services. The system must use a Linux Security Module configured to limit the privileges of system services. All device files must be monitored by the system Linux Security Module. The system must prevent the root account from logging in from virtual consoles. The system must prevent the root account from logging in from serial consoles. Default system accounts, other than root, must be locked. The system must not have accounts configured with blank or null passwords. The /etc/passwd file must not contain password hashes. The root account must be the only account having a UID of 0. The /etc/shadow file must be owned by root. The /etc/shadow file must be group-owned by root. The /etc/shadow file must have mode 0000. The /etc/gshadow file must be owned by root. The /etc/gshadow file must be group-owned by root. The /etc/gshadow file must have mode 0000. The /etc/passwd file must be owned by root. The /etc/passwd file must be group-owned by root. The /etc/passwd file must have mode 0644 or less permissive. The /etc/group file must be owned by root. The /etc/group file must be group-owned by root. The /etc/group file must have mode 0644 or less permissive. Library files must have mode 0755 or less permissive. Library files must be owned by root. All system command files must have mode 0755 or less permissive. All system command files must be owned by root. The system must require passwords to contain a minimum of 14 characters. Users must not be able to change passwords more than once every 24 hours. User passwords must be changed at least every 60 days. Users must be warned 7 days in advance of password expiration. The system must require passwords to contain at least one numeric character. The system must require passwords to contain at least one uppercase alphabetic character. The system must require passwords to contain at least one special character. The system must require passwords to contain at least one lowercase alphabetic character. The system must require at least four characters be changed between the old and new passwords during a password change. The system must disable accounts after three consecutive unsuccessful login attempts. The system must use a FIPS 140-2 approved cryptographic hashing algorithm for generating account password hashes (system-auth). The system must use a FIPS 140-2 approved cryptographic hashing algorithm for generating account password hashes (login.defs). The system must use a FIPS 140-2 approved cryptographic hashing algorithm for generating account password hashes (libuser.conf). The system boot loader configuration file(s) must be owned by root. The system boot loader configuration file(s) must be group-owned by root. The system boot loader configuration file(s) must have mode 0600 or less permissive. The system boot loader must require authentication. The system must require authentication upon booting into single-user and maintenance modes. The system must not permit interactive boot. The system must allow locking of the console screen. The Department of Defense (DoD) login banner must be displayed immediately prior to, or as part of, console login prompts. The system must implement virtual address space randomization. The system must limit the ability of processes to have simultaneous write and execute access to memory. The system must not send ICMPv4 redirects by default. The system must not send ICMPv4 redirects from any interface. IP forwarding for IPv4 must not be enabled, unless the system is a router. The system must not accept IPv4 source-routed packets on any interface. The system must not accept ICMPv4 redirect packets on any interface. The system must not accept ICMPv4 secure redirect packets on any interface. The system must log Martian packets. The system must not accept IPv4 source-routed packets by default. The system must not accept ICMPv4 secure redirect packets by default. The system must ignore IPv4 ICMP redirect messages. The system must not respond to ICMPv4 sent to a broadcast address. The system must ignore ICMPv4 bogus error responses. The system must be configured to use TCP syncookies when experiencing a TCP SYN flood. The system must use a reverse-path filter for IPv4 network traffic when possible on all interfaces. The system must use a reverse-path filter for IPv4 network traffic when possible by default. The IPv6 protocol handler must not be bound to the network stack unless needed. The system must ignore ICMPv6 redirects by default. The system must employ a local IPv6 firewall. The system must employ a local IPv6 firewall. The system must employ a local IPv6 firewall. The system must employ a local IPv6 firewall. The system must employ a local IPv6 firewall. The system must employ a local IPv6 firewall. The system must employ a local IPv4 firewall. The system must employ a local IPv4 firewall. The system must employ a local IPv4 firewall. The system must employ a local IPv4 firewall. The system must employ a local IPv4 firewall. The system must employ a local IPv4 firewall. The system's local IPv4 firewall must implement a deny-all, allow-by-exception policy for inbound packets. The system's local firewall must implement a deny-all, allow-by-exception policy for inbound packets. The system's local firewall must implement a deny-all, allow-by-exception policy for inbound packets. The Datagram Congestion Control Protocol (DCCP) must be disabled unless required. The Stream Control Transmission Protocol (SCTP) must be disabled unless required. The Reliable Datagram Sockets (RDS) protocol must be disabled unless required. The Transparent Inter-Process Communication (TIPC) protocol must be disabled unless required. All rsyslog-generated log files must be owned by root. All rsyslog-generated log files must be group-owned by root. All rsyslog-generated log files must have mode 0600 or less permissive. The operating system must back up audit records on an organization defined frequency onto a different system or media than the system being audited. The operating system must support the requirement to centrally manage the content of audit records generated by organization defined information system components. System logs must be rotated daily. Auditing must be implemented. The operating system audit records must be able to be used by a report generation capability. The operating system must audit nonlocal maintenance and diagnostic sessions. The operating system must produce a system-wide (logical or physical) audit trail composed of audit records in a standardized format. The operating system must produce audit records containing sufficient information to establish the identity of any user/subject associated with the event. The operating system must employ automated mechanisms to facilitate the monitoring and control of remote access methods. The operating system must provide the capability to automatically process audit records for events of interest based upon selectable, event criteria. The operating system must fail to an organization defined known state for organization defined types of failures. The operating system must produce audit records containing sufficient information to establish what type of events occurred. Auditing must be enabled at boot by setting a kernel parameter. The system must retain enough rotated audit logs to cover the required log retention period. The system must set a maximum audit log file size. The system must rotate audit log files that reach the maximum file size. The audit system must switch the system to single-user mode when available audit storage volume becomes dangerously low. The audit system must be configured to audit all attempts to alter system time through adjtimex. The audit system must be configured to audit all attempts to alter system time through settimeofday. The audit system must be configured to audit all attempts to alter system time through stime. The audit system must be configured to audit all attempts to alter system time through clock_settime. The audit system must be configured to audit all attempts to alter system time through /etc/localtime. The operating system must automatically audit account creation. The operating system must automatically audit account modification. The operating system must automatically audit account disabling actions. The operating system must automatically audit account termination. The audit system must be configured to audit modifications to the systems network configuration. The audit system must be configured to audit modifications to the system's Mandatory Access Control (MAC) configuration (SELinux). The audit system must be configured to audit all discretionary access control permission modifications using chmod. The audit system must be configured to audit all discretionary access control permission modifications using chown. The audit system must be configured to audit all discretionary access control permission modifications using fchmod. The audit system must be configured to audit all discretionary access control permission modifications using fchmodat. The audit system must be configured to audit all discretionary access control permission modifications using fchown. The audit system must be configured to audit all discretionary access control permission modifications using fchownat. The audit system must be configured to audit all discretionary access control permission modifications using fremovexattr. The audit system must be configured to audit all discretionary access control permission modifications using fsetxattr. The audit system must be configured to audit all discretionary access control permission modifications using lchown. The audit system must be configured to audit all discretionary access control permission modifications using lremovexattr. The audit system must be configured to audit all discretionary access control permission modifications using lsetxattr. The audit system must be configured to audit all discretionary access control permission modifications using removexattr. The audit system must be configured to audit all discretionary access control permission modifications using setxattr. The audit system must be configured to audit failed attempts to access files and programs. The audit system must be configured to audit all use of setuid programs. The audit system must be configured to audit successful file system mounts. The audit system must be configured to audit user deletions of files and programs. The audit system must be configured to audit changes to the "/etc/sudoers" file. The audit system must be configured to audit the loading and unloading of dynamic kernel modules. The xinetd service must be disabled if no network services utilizing it are enabled. The xinetd service must be uninstalled if no network services utilizing it are enabled. The telnet-server package must not be installed. The telnet daemon must not be running. The rsh-server package must not be installed. The rshd service must not be running. The rexecd service must not be running. The rlogind service must not be running. The ypserv package must not be installed. The ypbind service must not be running. The tftp-server package must not be installed. The TFTP service must not be running. The cron service must be running. The SSH daemon must be configured to use only the SSHv2 protocol. The SSH daemon must set a timeout interval on idle sessions. The SSH daemon must set a timeout count on idle sessions. The SSH daemon must ignore .rhosts files. The SSH daemon must not allow host-based authentication. The SSH daemon must not allow host-based authentication. The system must not permit root logins using remote access programs such as ssh. The SSH daemon must not allow authentication using an empty password. The SSH daemon must be configured with the Department of Defense (DoD) login banner. The SSH daemon must not permit user environment settings. The SSH daemon must be configured to use only FIPS 140-2 approved ciphers. The operating system must employ FIPS-validated cryptography to protect unclassified information. The operating system must employ NSA-approved cryptography to protect classified information. The avahi service must be disabled. The system clock must be synchronized continuously, or at least daily. The system clock must be synchronized to an authoritative DoD time source. Mail relaying must be restricted. The operating system must uniquely identify and authenticate an organization defined list of specific devices and/or types of devices before establishing a connection. If the system is using LDAP for authentication or account information, the system must use a TLS connection using FIPS 140-2 approved cryptographic algorithms. The LDAP client must use a TLS connection using trust certificates signed by the site CA. The openldap-servers package must not be installed unless required. The graphical desktop environment must set the idle timeout to no more than 15 minutes. The graphical desktop environment must automatically lock after 15 minutes of inactivity and the system must require user to re-authenticate to unlock the environment. The graphical desktop environment must have automatic lock enabled. The system must display a publicly-viewable pattern during a graphical desktop environment session lock. The Automatic Bug Reporting Tool (abrtd) service must not be running. The atd service must be disabled. Automated file system mounting tools must not be enabled unless needed. The ntpdate service must not be running. The oddjobd service must not be running. The qpidd service must not be running. The rdisc service must not be running. Remote file systems must be mounted with the "nodev" option. Remote file systems must be mounted with the "nosuid" option. The noexec option must be added to removable media partitions. The system must use SMB client signing for connecting to samba servers using smbclient. The system must use SMB client signing for connecting to samba servers using mount.cifs. The system must prohibit the reuse of passwords within twenty-four iterations. The operating system must employ cryptographic mechanisms to protect information in storage. The operating system must protect the confidentiality and integrity of data at rest. The operating system must employ cryptographic mechanisms to prevent unauthorized disclosure of data at rest unless otherwise protected by alternative physical measures. The system package management tool must verify permissions on all files and directories associated with the "audit" package. The system package management tool must verify ownership on all files and directories associated with the "audit" package. The system package management tool must verify group-ownership on all files and directories associated with the "audit" package. The system package management tool must verify contents of all files associated with the audit package. There must be no world-writable files on the system. The system must use and update a DoD-approved virus scan program. The system must have a host-based intrusion detection tool installed. The x86 Ctrl-Alt-Delete key sequence must be disabled. The postfix service must be enabled for mail delivery. The sendmail package must be removed. The netconsole service must be disabled unless required. X Windows must not be enabled unless required. The xorg-x11-server-common (X Windows) package must not be installed, unless required. The DHCP client must be disabled if not needed. All GIDs referenced in /etc/passwd must be defined in /etc/group All accounts on the system must have unique user or account names Temporary accounts must be provisioned with an expiration date. Emergency accounts must be provisioned with an expiration date. The system must require passwords to contain no more than three consecutive repeating characters. All files and directories must have a valid owner. All files must be owned by a group. A file integrity tool must be used at least weekly to check for unauthorized file changes, particularly the addition of unauthorized system libraries or binaries, or for unauthorized modification to authorized system libraries or binaries. The operating system must employ automated mechanisms, per organization defined frequency, to detect the addition of unauthorized components/devices into the operating system. The operating system must employ automated mechanisms to detect the presence of unauthorized software on organizational information systems and notify designated organizational officials in accordance with the organization defined frequency. The operating system must provide a near real-time alert when any of the organization defined list of compromise or potential compromise indicators occurs. The operating system must detect unauthorized changes to software and information. The operating system must ensure unauthorized, security-relevant configuration changes detected are tracked. Process core dumps must be disabled unless needed. The NFS server must not have the insecure file locking option enabled. The audit system must provide a warning when allocated audit record storage volume reaches a documented percentage of maximum audit record storage capacity. The audit system must identify staff members to receive notifications of audit log storage volume capacity issues. The Bluetooth kernel module must be disabled. The system must have USB Mass Storage disabled unless needed. The system must limit users to 10 simultaneous system logins, or a site-defined number, in accordance with operational requirements. The system's local firewall must implement a deny-all, allow-by-exception policy for forwarded packets. The system must provide VPN connectivity for communications over untrusted networks. A login banner must be displayed immediately prior to, or as part of, graphical desktop environment login prompts. The Department of Defense (DoD) login banner must be displayed immediately prior to, or as part of, graphical desktop environment login prompts. The Bluetooth service must be disabled. Accounts must be locked upon 35 days of inactivity. The operating system must manage information system identifiers for users and devices by disabling the user identifier after an organization defined time period of inactivity. The sticky bit must be set on all public directories. All public directories must be owned by a system account. The TFTP daemon must operate in "secure mode" which provides access only to a single directory on the host file system. The FTP daemon must be configured for logging or verbose mode. The snmpd service must use only SNMP protocol version 3 or newer. The snmpd service must not use a default password. The system default umask for the bash shell must be 077. The system default umask for the csh shell must be 077. The system default umask in /etc/profile must be 077. The system default umask in /etc/login.defs must be 077. The system default umask for daemons must be 027 or 022. There must be no .netrc files on the system. The FTPS/FTP service on the system must be configured with the Department of Defense (DoD) login banner. The system must be configured to require the use of a CAC, PIV compliant hardware token, or Alternate Logon Token (ALT) for authentication. The system must require administrator action to unlock an account locked by excessive failed login attempts. The system must disable accounts after excessive login failures within a 15-minute interval. The operating system must dynamically manage user privileges and associated access authorizations. The operating system must support organization defined one-way flows using hardware mechanisms. The operating system must provide the capability for a privileged administrator to enable/disable organization defined security policy filters. The operating system, upon successful logon, must display to the user the date and time of the last logon (access) via GUI. The operating system, upon successful logon/access, must display to the user the number of unsuccessful logon/access attempts since the last successful logon/access. The operating system must retain the session lock until the user reestablishes access using established identification and authentication procedures. The operating system must employ automated mechanisms to enable authorized users to make information sharing decisions based on access authorizations of sharing partners and access restrictions on information to be shared. The operating system must produce audit records containing sufficient information to establish when (date and time) the events occurred. The operating system must produce audit records containing sufficient information to establish where the events occurred. The operating system must produce audit records containing sufficient information to establish the sources of the events. The operating system must produce audit records containing sufficient information to establish the outcome (success or failure) of the events. The operating system must include organization defined additional, more detailed information in the audit records for audit events identified by type, location, or subject. Operating system must support the capability to centralize the review and analysis of audit records from multiple components within the system. The operating system must support an audit reduction capability. The operating system must use internal system clocks to generate time stamps for audit records. Audit log files must have mode 0640 or less permissive. Audit log files must be owned by root. Audit log directories must have mode 0755 or less permissive. The operating system must allow designated organizational personnel to select which auditable events are to be audited by the operating system. The operating system must support the capability to compile audit records from multiple components within the system into a system-wide (logical or physical) audit trail that is time-correlated to within organization defined level of tolerance. The operating system, for PKI-based authentication must validate certificates by constructing a certification path with status information to an accepted trust anchor. The operating system, for PKI-based authentication must enforce authorized access to the corresponding private key. The operating system must obscure feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals. The operating system must bind security attributes to information to facilitate information flow policy enforcement. The operating system must provide the capability for a privileged administrator to configure organization defined security policy filters to support different security policies. The operating system must enforce logical access restrictions associated with changes to the information system. The operating system must employ automated mechanisms to enforce access restrictions. The operating system must employ automated mechanisms to prevent program execution in accordance with the organization defined specifications. The operating system must dynamically manage identifiers, attributes, and associated access authorizations. The operating system must employ automated mechanisms to restrict the use of maintenance tools to authorized personnel only. The operating system must separate user functionality (including user interface services) from operating system management functionality. The operating system must prevent the presentation of information system management-related functionality at an interface for general (i.e., non-privileged) users. The operating system must isolate security functions from nonsecurity functions. The operating system must isolate security functions enforcing access and information flow control from both non-security functions and from other security functions. The operating system must implement an information system isolation boundary to minimize the number of non-security functions included within the boundary containing security functions. The operating system must implement security functions as a layered structure minimizing interactions between layers of the design and avoiding any dependence by lower layers on the functionality or correctness of higher layers. The operating system must prevent unauthorized and unintended information transfer via shared system resources. The operating system must not share resources used to interface with systems operating at different security levels. The operating system must limit the use of resources by priority. The operating system must prevent remote devices that have established a non-remote connection with the system from communicating outside of the communication path with resources in external networks. The operating system must protect the integrity of transmitted information. The operating system must employ cryptographic mechanisms to recognize changes to information during transmission unless otherwise protected by alternative physical measures. The operating system must maintain the integrity of information during aggregation, packaging, and transformation in preparation for transmission. The operating system must validate the integrity of security attributes exchanged between systems. The operating system must protect the integrity of information during the processes of data aggregation, packaging, and transformation in preparation for transmission. The operating system must employ organization defined information system components with no writeable storage that are persistent across component restart or power on/off. The operating system must install software updates automatically. The operating system must support automated patch management tools to facilitate flaw remediation to organization defined information system components. The operating system must prevent non-privileged users from circumventing malicious code protection capabilities. The operating system must prevent non-privileged users from circumventing intrusion detection and prevention capabilities. The operating system must protect information obtained from intrusion-monitoring tools from unauthorized access, modification, and deletion. The operating system must verify the correct operation of security functions in accordance with organization defined conditions and in accordance with organization defined frequency (if periodic verification). The operating system must provide notification of failed automated security tests. The operating system must provide automated support for the management of distributed security testing. The operating system must check the validity of information inputs. The operating system must support the requirement that organizations, if an information system component failure is detected must activate an organization defined alarm and/or automatically shuts down the operating system. The operating system must associate the identity of the information producer with the information. The operating system must enforce an organization defined Discretionary Access Control (DAC) policy that must allow users to specify and control sharing by named individuals or groups of individuals, or by both. The operating system must enforce approved authorizations for controlling the flow of information within the system in accordance with applicable policy. The operating system must support and maintain the binding of organization defined security attributes to information in storage. The operating system must support and maintain the binding of organization defined security attributes to information in process. The operating system must dynamically reconfigure security attributes in accordance with an identified security policy as information is created and combined. The operating system must only allow authorized entities to change security attributes. The operating system must maintain the binding of security attributes to information with sufficient assurance that the information--attribute association can be used as the basis for automated policy actions. The operating system must only allow authorized users to associate security attributes with information. The operating system must display security attributes in human-readable form on each object output from the system to system output devices to identify an organization-identified set of special dissemination, handling, or distribution instructions using organization-identified human readable, standard naming conventions. The operating system must enforce a Discretionary Access Control (DAC) policy that includes or excludes access to the granularity of a single user. The operating system must automatically implement organization defined safeguards and countermeasures if security functions (or mechanisms) are changed inappropriately. The operating system must enforce a Discretionary Access Control (DAC) policy that limits propagation of access rights. The operating system must preserve organization defined system state information in the event of a system failure. The operating system must take organization defined list of least disruptive actions to terminate suspicious events. The operating system must respond to security function anomalies in accordance with organization defined responses and alternative action(s). The system must have USB Mass Storage disabled unless needed. The operating system must conduct backups of user-level information contained in the operating system per organization defined frequency to conduct backups consistent with recovery time and recovery point objectives. The operating system must conduct backups of system-level information contained in the information system per organization defined frequency to conduct backups that are consistent with recovery time and recovery point objectives. The operating system, upon successful logon, must display to the user the date and time of the last logon or access via a local console or tty. The operating system, upon successful logon, must display to the user the date and time of the last logon or access via ssh. The system must allow locking of graphical desktop sessions. The system must forward audit records to the syslog service. The audit system must take appropriate action when the audit storage volume is full. The audit system must take appropriate action when there are disk errors on the audit storage volume. The audit system must alert designated staff members when audit storage volume is full. The audit system must alert designated staff members when audit storage volume is generating disk errors. The RPM package management tool must cryptographically verify the authenticity of all software packages during installation. The NFS server must not have the all_squash option enabled. The system package management tool must verify ownership on all files and directories associated with packages. The system package management tool must verify group-ownership on all files and directories associated with packages. The system package management tool must verify permissions on all files and directories associated with packages. The system package management tool must verify contents of all files associated with packages. The mail system must forward all mail for root to one or more system administrators. Audit log files must be group-owned by root. The system's local IPv6 firewall must implement a deny-all, allow-by-exception policy for inbound packets. The system must provide automated support for account management functions. Auditing must be enabled at boot by setting a kernel parameter. Automated file system mounting tools must not be enabled unless needed. The operating system must enforce dual authorization, based on organizational policies and procedures for organization defined privileged commands. The operating system must prevent access to organization defined security-relevant information except during secure, non-operable system states. The operating system must enforce information flow control using explicit security attributes on information, source, and destination objects as a basis for flow control decisions. The operating system must enforce information flow control using protected processing domains (e.g., domain type-enforcement) as a basis for flow control decisions. The operating system must enforce dynamic information flow control based on policy that must allow or disallow information flows based upon changing conditions or operational considerations. The operating system must prevent encrypted data from bypassing content checking mechanisms. The operating system must enforce organization defined limitations on the embedding of data types within other data types. The operating system must enforce information flow control on metadata. The operating system must enforce information flow control using organization defined security policy filters as a basis for flow control decisions. The operating system must provide the capability for a privileged administrator to configure the organization defined security policy filters to support different security policies. The operating system must implement separation of duties through assigned information system access authorizations. The operating system must produce audit records on hardware-enforced, write-once media. The operating system must protect against an individual falsely denying having performed a particular action. The operating system, for PKI-based authentication must map the authenticated identity to the user account. The operating system must enforce password encryption for transmission. The operating system, when transferring information between different security domains, must identify information flows by data type specification and usage. The operating system, when transferring information between different security domains, must decompose information into policy-relevant subcomponents for submission to policy enforcement mechanisms. The operating system must enforce security policies regarding information on interconnected systems. The operating system must enforce a two-person rule for changes to organization defined information system components and system-level information. The operating system must employ automated mechanisms to centrally apply configuration settings. The operating system must employ automated mechanisms to centrally verify configuration settings. The operating system must conduct backups of operating system documentation including security-related documentation per organization defined frequency to conduct backups that is consistent with recovery time and recovery point objectives. The operating system must implement transaction recovery for transaction-based systems. The operating system must use multifactor authentication for local access to privileged accounts. The operating system must use multifactor authentication for local access to non-privileged accounts. The operating system must use multifactor authentication for network access to privileged accounts where one of the factors is provided by a device separate from the information system being accessed. The operating system must use multifactor authentication for network access to non-privileged accounts where one of the factors is provided by a device separate from the operating system being accessed. The operating system must authenticate devices before establishing remote network connections using bidirectional cryptographically based authentication between devices. The operating system must authenticate devices before establishing wireless network connections using bidirectional cryptographically based authentication between devices. The operating system must authenticate devices before establishing network connections using bidirectional cryptographically based authentication between devices. The operating system must implement a configurable capability to automatically disable the operating system if any of the organization defined lists of security violations are detected. The operating system must employ strong identification and authentication techniques in the establishment of nonlocal maintenance and diagnostic sessions. The operating system must protect nonlocal maintenance sessions through the use of a strong authenticator tightly bound to the user. The operating system must use cryptographic mechanisms to protect and restrict access to information on portable digital media. The operating system must protect against or must limit the effects of the organization defined or referenced types of Denial of Service attacks. The operating system must restrict the ability of users to launch Denial of Service attacks against other information systems or networks. The operating system must route organization defined internal communications traffic to organization defined external networks through authenticated proxy servers within the managed interfaces of boundary protection devices. The operating system, at managed interfaces, must deny network traffic and must audit internal users (or malicious code) posing a threat to external information systems. The operating system must route all networked, privileged accesses through a dedicated, managed interface for purposes of access control and auditing. The operating system must prevent discovery of specific system components (or devices) composing a managed interface. The operating system must employ automated mechanisms to enforce strict adherence to protocol format. The operating system must fail securely in the event of an operational failure of a boundary protection device. The operating system must employ cryptographic mechanisms to prevent unauthorized disclosure of information during transmission unless otherwise protected by alternative physical measures. The operating system must maintain the confidentiality of information during aggregation, packaging, and transformation in preparation for transmission. The operating system must establish a trusted communications path between the user and organization defined security functions within the operating system. The operating system must produce, control, and distribute symmetric cryptographic keys using NIST-approved or NSA-approved key management technology and processes. The operating system must produce, control, and distribute symmetric and asymmetric cryptographic keys using NSA-approved key management technology and processes. The operating system must produce, control, and distribute asymmetric cryptographic keys using approved PKI Class 3 certificates or prepositioned keying material. The operating system must produce, control, and distribute asymmetric cryptographic keys using approved PKI Class 3 or Class 4 certificates and hardware security tokens that protect the user's private key. The operating system must employ FIPS-validated cryptography to protect information when it must be separated from individuals who have the necessary clearances, yet lack the necessary access approvals. The operating system must employ FIPS-validate or NSA-approved cryptography to implement digital signatures. The operating system must protect the integrity and availability of publicly available information and applications. The operating system must prohibit remote activation of collaborative computing devices, excluding the organization defined exceptions where remote activation is to be allowed. The operating system must associate security attributes with information exchanged between information systems. The operating system must issue or obtain public key certificates under an appropriate certificate policy from an approved service provider. The operating system must implement detection and inspection mechanisms to identify unauthorized mobile code. The operating system must prevent the execution of prohibited mobile code. The operating system must prevent the download of prohibited mobile code. The operating system must prevent the automatic execution of mobile code in organization defined software applications and must require organization defined actions prior to executing the code. The operating system at organization defined information system components must load and execute the operating environment from hardware-enforced, read-only media. The operating system at organization defined information system components must load and execute organization defined applications from hardware-enforced, read-only media. The operating system must have malicious code protection mechanisms at system entry and exit points to detect and eradicate malicious code transported by electronic mail, electronic mail attachments, web accesses, removable media, or other common means. The operating system must identify potentially security-relevant error conditions. The operating system must generate error messages providing information necessary for corrective actions without revealing organization defined sensitive or potentially harmful information in error logs and administrative messages that could be exploited. The operating system must validate the binding of the information producer's identity to the information. The operating system must maintain reviewer/releaser identity and credentials within the established chain of custody for all information reviewed or released. The operating system must validate the binding of the reviewer's identity to the information at the transfer/release point prior to release/transfer from one security domain to another security domain. The operating system must employ automated mechanisms to alert security personnel of any organization defined inappropriate or unusual activities with security implications. The operating system must use cryptographic mechanisms to protect the integrity of audit information. The operating system must protect the audit records resulting from nonlocal accesses to privileged accounts and the execution of privileged functions. The operating system must monitor for atypical usage of operating system accounts. The operating system, when transferring information between different security domains, must implement policy filters constraining data structure and content to organization defined information security policy requirements. The operating system, when transferring information between different security domains, must detect unsanctioned information. The operating system, when transferring information between different security domains, must prohibit the transfer of unsanctioned information in accordance with the security policy. The operating system must uniquely identify source domains for information transfer. The operating system must uniquely authenticate source domains for information transfer. The operating system must provide additional protection for mobile devices accessed via login by purging information from the device after organization defined number of consecutive, unsuccessful login attempts to the mobile device. The operating system must employ automated mechanisms to centrally manage configuration settings. The operating system must notify the user of the number of successful logins/accesses that occur during the organization defined time period. The operating system must notify the user of the number of unsuccessful login/access attempts that occur during organization defined time period. The operating system must notify the user of organization defined security-related changes to the user's account that occur during the organization defined time period. The operating system must support and maintain the binding of organization defined security attributes to information in transmission. The operating system must ensure remote sessions for accessing an organization defined list of security functions and security-relevant information are audited. The operating system must provide the capability to capture/record and log all content related to a user session. The operating system uniquely must identify destination domains for information transfer. The operating system uniquely must authenticate destination domains for information transfer. The operating system must track problems associated with the information transfer. The operating system must protect nonlocal maintenance sessions by separating the maintenance session from other network sessions with the information system by either physically separated communications paths or logically separated communications paths. The operating system must take corrective actions, when unauthorized mobile code is identified. The operating system must notify, as required, appropriate individuals when accounts are created. The operating system must notify, as required, appropriate individuals when accounts are modified. The operating system must notify, as required, appropriate individuals when account is disabled. The operating system must notify, as required, appropriate individuals for account termination. scap-security-guide-0.1.31/Ubuntu/16.04/input/guide.xslt000066400000000000000000000075111301675746700226100ustar00rootroot00000000000000 A conditional clause for check statements. A conditional clause for check statements. This is a placeholder. scap-security-guide-0.1.31/Ubuntu/16.04/input/oval/000077500000000000000000000000001301675746700215345ustar00rootroot00000000000000scap-security-guide-0.1.31/Ubuntu/16.04/input/oval/platform/000077500000000000000000000000001301675746700233605ustar00rootroot00000000000000scap-security-guide-0.1.31/Ubuntu/16.04/input/oval/platform/ubuntu1604-cpe-dictionary.xml000066400000000000000000000012321301675746700306450ustar00rootroot00000000000000 Ubuntu release 16.04 (Xenial) installed_OS_is_ubuntu1604 scap-security-guide-0.1.31/Ubuntu/16.04/input/oval/testoval.py000077500000000000000000000003521301675746700237520ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import testoval_module if __name__ == "__main__": testoval_module.main() scap-security-guide-0.1.31/Ubuntu/16.04/input/profiles/000077500000000000000000000000001301675746700224165ustar00rootroot00000000000000scap-security-guide-0.1.31/Ubuntu/16.04/input/profiles/anssi_np_nt28_average.xml000066400000000000000000000037711301675746700273270ustar00rootroot00000000000000 Profile for ANSSI DAT-NT28 Average (Intermediate) Level This profile contains items for GNU/Linux installations already protected by multiple higher level security stacks. scap-security-guide-0.1.31/Ubuntu/16.04/input/profiles/anssi_np_nt28_high.xml000066400000000000000000000007361301675746700266320ustar00rootroot00000000000000 Profile for ANSSI DAT-NT28 High (Enforced) Level This profile contains items for GNU/Linux installations storing sensitive informations that can be accessible from unauthenticated or uncontroled networks. scap-security-guide-0.1.31/Ubuntu/16.04/input/profiles/anssi_np_nt28_minimal.xml000066400000000000000000000014371301675746700273400ustar00rootroot00000000000000 Profile for ANSSI DAT-NT28 Minimal Level This profile contains items to be applied systematically. scap-security-guide-0.1.31/Ubuntu/16.04/input/profiles/anssi_np_nt28_restrictive.xml000066400000000000000000000015341301675746700302530ustar00rootroot00000000000000 Profile for ANSSI DAT-NT28 Restrictive Level This profile contains items for GNU/Linux installations exposed to unauthenticated flows or multiple sources. scap-security-guide-0.1.31/Ubuntu/16.04/input/xccdf/000077500000000000000000000000001301675746700216625ustar00rootroot00000000000000scap-security-guide-0.1.31/Ubuntu/16.04/input/xccdf/services/000077500000000000000000000000001301675746700235055ustar00rootroot00000000000000scap-security-guide-0.1.31/Ubuntu/16.04/input/xccdf/services/basics.xml000066400000000000000000000070661301675746700255040ustar00rootroot00000000000000 Generic required services Some services need to be deployed in order to ensure basic verifications and reporting on GNU/Linux operating systems. Each of these service take part in the administrability of the system. install the auditd service The auditd service should be installed. The auditd service is an access monitoring and accounting daemon, watching system calls to audit any access, in comparision with potential local access control policy such as SELinux policy. Enable the auditd service The auditd service should be enabled. The auditd service is an access monitoring and accounting daemon, watching system calls to audit any access, in comparision with potential local access control policy such as SELinux policy. Install the cron service The Cron service should be installed. The cron service allow periodic job execution, needed for almost all administrative tasks and services (software update, log rotating, etc.). Access to cron service should be restricted to administrative accounts only. Enable the cron service The Cron service should be enabled. The cron service allow periodic job execution, needed for almost all administrative tasks and services (software update, log rotating, etc.). Access to cron service should be restricted to administrative accounts only. Install the ntp service The ntpd service should be installed. Time synchronization (using NTP) is required by almost all network and administrative tasks (syslog, cryptographic based services (authentication, etc.), etc.). Ntpd is regulary maintained and updated, supporting security features such as RFC 5906. Enable the ntpd service The ntpd service should be enabled. Time synchronization (using NTP) is required by almost all network and administrative tasks (syslog, cryptographic based services (authentication, etc.), etc.). Ntpd is regulary maintained and updated, supporting security features such as RFC 5906. scap-security-guide-0.1.31/Ubuntu/16.04/input/xccdf/services/deprecated.xml000066400000000000000000000055501301675746700263340ustar00rootroot00000000000000 Deprecated services Some deprecated software services impact the overall system security due to their behavior (leak of confidentiality in network exchange, usage as uncontrolled communication channel, risk associated with the service due to its old age, etc. Uninstall the telnet server The telnet daemon should be uninstalled. telnet allows clear text communications, and does not protect any data transmission between client and server. Any confidential data can be listened and no integrity checking is made. Uninstall the inet-based telnet server The inet-based telnet daemon should be uninstalled. telnet allows clear text communications, and does not protect any data transmission between client and server. Any confidential data can be listened and no integrity checking is made. Uninstall the ssl compliant telnet server The telnet daemon, even with ssl support, should be uninstalled. telnet, even with ssl support, should not be installed. When remote shell is required, up-to-date ssh daemon can be used. Uninstall the nis package The support for Yellowpages should not be installed unless it is required. NIS is the historical SUN service for central account management, more and more replaced by LDAP. NIS does not support efficiently security constraints, ACL, etc. and should not be used. Uninstall the ntpdate package ntpdate is a historical ntp synchronization client for unixes. It sould be uninstalled. ntpdate is an old not security-compliant ntp client. It should be replaced by modern ntp clients such as ntpd, able to use cryptographic mechanisms integrated in NTP. scap-security-guide-0.1.31/Ubuntu/16.04/input/xccdf/services/ssh.xml000066400000000000000000000145301301675746700250270ustar00rootroot00000000000000 SSH Server The SSH protocol is recommended for remote access (remote login and secure remote file transfer). SSH provides both confidentiality and integrity for exchanged data but needs to be configured properly in term of:
    Cryptography usage, according to the current CVEs associated to the various cryptographic modes
    Authentication and autorization, depending on your needs but requiring some specific initial generic security
    consideration in the OpenSSH configuration writing More detailed information is available from the OpenSSH project's website . The Ubuntu package for server side implementation is called openssh-server.     SSH session Idle time Specify duration of allowed idle time. 300 300 600 900 3600 7200 Disable SSH Server if possible (unusual cases) Most of the time, the SSH server is needed. However, it can be disabled, do so. This is unusual, as SSH is a common method for encrypted and authenticated remote access. Configure OpenSSH Server if deployed If the system needs to act as an SSH server, then certain changes should be made to the OpenSSH daemon configuration file /etc/ssh/sshd_config. The following recommendations can be applied to this file. See the sshd_config(5) man page for more detailed information. Allow Only SSH Protocol 2 Only SSH protocol version 2 connections should be permitted. The default setting in /etc/ssh/sshd_config is correct, and can be verified by ensuring that the following line appears: 
    Protocol 2
     To check which SSH protocol version is allowed, run the following command: 
    $ sudo grep Protocol /etc/ssh/sshd_config
    If configured properly, output should be 
    Protocol 2
     SSH protocol version 1 suffers from design flaws that result in security vulnerabilities and should not be used.     Set SSH Idle Timeout Interval SSH allows administrators to set an idle timeout interval. After this interval has passed, the idle user will be automatically logged out.

    To set an idle timeout interval, edit the following line in /etc/ssh/sshd_config as follows: 
    ClientAliveInterval interval
    The timeout interval is given in seconds. To have a timeout of 15 minutes, set interval to 900.

    If a shorter timeout has already been set for the login shell, that value will preempt any SSH setting made here. Keep in mind that some processes may stop SSH from correctly detecting that the user is idle.     Run the following command to see what the timeout interval is: 
    $ sudo grep ClientAliveInterval /etc/ssh/sshd_config
    If properly configured, the output should be: 
    ClientAliveInterval 900
     Causing idle users to be automatically logged out guards against compromises one system leading trivially to compromises on another.     Set SSH Client Alive Count To ensure the SSH idle timeout occurs precisely when the ClientAliveCountMax is set, edit /etc/ssh/sshd_config as follows: 
    ClientAliveCountMax 0
     To ensure the SSH idle timeout will occur when the ClientAliveCountMax is set, run the following command: 
    $ sudo grep ClientAliveCountMax /etc/ssh/sshd_config
    If properly configured, output should be: 
    ClientAliveCountMax 0
     This ensures a user login will be terminated as soon as the ClientAliveCountMax is reached.     Disable SSH Root Login The root user should never be allowed to login to a system directly over a network. To disable root login via SSH, add or correct the following line in /etc/ssh/sshd_config: 
    PermitRootLogin no
     Permitting direct root login reduces auditable information about who ran privileged commands on the system and also allows direct attack attempts on root's password.     Disable SSH Access via Empty Passwords To explicitly disallow remote login from accounts with empty passwords, add or correct the following line in /etc/ssh/sshd_config: 
    PermitEmptyPasswords no
    Any accounts with empty passwords should be disabled immediately, and PAM configuration should prevent users from being able to assign themselves empty passwords.     Configuring this setting for the SSH daemon provides additional assurance that remote login via SSH will require a password, even in the event of misconfiguration elsewhere.     scap-security-guide-0.1.31/Ubuntu/16.04/input/xccdf/system/000077500000000000000000000000001301675746700232065ustar00rootroot00000000000000scap-security-guide-0.1.31/Ubuntu/16.04/input/xccdf/system/logging.xml000066400000000000000000000374101301675746700253630ustar00rootroot00000000000000 Configure Syslog The syslog service has been the default Unix logging mechanism for many years. It has a number of downsides, including inconsistent log format, lack of authentication for received messages, and lack of authentication, encryption, or reliable transport for messages sent over a network. However, due to its long history, syslog is a de facto standard which is supported by almost all Unix applications.

    In Ubuntu 1604, rsyslog has replaced syslog as the syslog daemon of choice, and it includes some additional security features such as reliable, connection-oriented (i.e. TCP) transmission of logs, the option to log to database formats, and the encryption of log data en route to a central logging server. This section discusses how to configure rsyslog for best effect, and how to use tools provided with the system to maintain and monitor logs.     Ensure rsyslog is Installed Rsyslog is installed by default. The rsyslog package provides the rsyslog daemon, which provides system logging services. Enable rsyslog Service The rsyslog service provides syslog-style logging by default on Ubuntu 1604. The rsyslog service must be running in order to provide logging services, which are essential to system administration. Ensure Proper Configuration of Log Files The file /etc/rsyslog.conf controls where log message are written. These are controlled by lines called rules, which consist of a selector and an action. These rules are often customized depending on the role of the system, the requirements of the environment, and whatever may enable the administrator to most effectively make use of log data. The default rules in Ubuntu 1604 are: 
    auth,authpriv.*			/var/log/auth.log
*.*;auth,authpriv.none          -/var/log/syslog
daemon.*                        -/var/log/daemon.log
kern.*                          -/var/log/kern.log
lpr.*                           -/var/log/lpr.log
mail.*                          -/var/log/mail.log
user.*                          -/var/log/user.log
mail.info                       -/var/log/mail.info
mail.warn                       -/var/log/mail.warn
mail.err                        /var/log/mail.err
news.crit                       /var/log/news/news.crit
news.err                        /var/log/news/news.err
news.notice                     -/var/log/news/news.notice
    See the man page rsyslog.conf(5) for more information. Note that the rsyslog daemon is configured to use traditional timestamping to be understood by any log processing program. For high precision timestamping, comment the following line in /etc/rsyslog.conf: 
    $ ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
         User who owns log files Specify user owner of all logfiles specified in /etc/rsyslog.conf. root group who owns log files Specify group owner of all logfiles specified in /etc/rsyslog.conf. adm Ensure Log Files Are Owned By Appropriate User The owner of all log files written by rsyslog should be root. These log files are determined by the second part of each Rule line in /etc/rsyslog.conf and typically all appear in /var/log. For each log file LOGFILE referenced in /etc/rsyslog.conf, run the following command to inspect the file's owner: 
    $ ls -l LOGFILE
    If the owner is not root, run the following command to correct this: 
    $ sudo chown root LOGFILE
     The owner of all log files written by rsyslog should be root. These log files are determined by the second part of each Rule line in /etc/rsyslog.conf and typically all appear in /var/log. To see the owner of a given log file, run the following command: 
    $ ls -l LOGFILE
     The log files generated by rsyslog contain valuable information regarding system configuration, user authentication, and other such information. Log files should be protected from unauthorized access.     Ensure Log Files Are Owned By Appropriate Group The group-owner of all log files written by rsyslog should be root. These log files are determined by the second part of each Rule line in /etc/rsyslog.conf and typically all appear in /var/log. For each log file LOGFILE referenced in /etc/rsyslog.conf, run the following command to inspect the file's group owner: 
    $ ls -l LOGFILE
    If the owner is not adm, run the following command to correct this: 
    $ sudo chgrp adm LOGFILE
     The group-owner of all log files written by rsyslog should be adm. These log files are determined by the second part of each Rule line in /etc/rsyslog.conf and typically all appear in /var/log. To see the group-owner of a given log file, run the following command: 
    $ ls -l LOGFILE
     The log files generated by rsyslog contain valuable information regarding system configuration, user authentication, and other such information. Log files should be protected from unauthorized access.     Ensure System Log Files Have Correct Permissions The file permissions for all log files written by rsyslog should be set to 640, or more restrictive. These log files are determined by the second part of each Rule line in /etc/rsyslog.conf and typically all appear in /var/log. For each log file LOGFILE referenced in /etc/rsyslog.conf, run the following command to inspect the file's permissions: 
    $ ls -l LOGFILE
    If the permissions are not 640 or more restrictive, run the following command to correct this: 
    $ sudo chmod 0640 LOGFILE
     The file permissions for all log files written by rsyslog should be set to 640, or more restrictive. These log files are determined by the second part of each Rule line in /etc/rsyslog.conf and typically all appear in /var/log. To see the permissions of a given log file, run the following command: 
    $ ls -l LOGFILE
    The permissions should be 640, or more restrictive.     Log files can contain valuable information regarding system configuration. If the system log files are not protected unauthorized users could change the logged data, eliminating their forensic value.     Rsyslog Logs Sent To Remote Host If system logs are to be useful in detecting malicious activities, it is necessary to send logs to a remote server. An intruder who has compromised the root account on a machine may delete the log entries which indicate that the system was attacked before they are seen by an administrator.

    However, it is recommended that logs be stored on the local host in addition to being sent to the loghost, especially if rsyslog has been configured to use the UDP protocol to send messages over a network. UDP does not guarantee reliable delivery, and moderately busy sites will lose log messages occasionally, especially in periods of high traffic which may be the result of an attack. In addition, remote rsyslog messages are not authenticated in any way by default, so it is easy for an attacker to introduce spurious messages to the central log server. Also, some problems cause loss of network connectivity, which will prevent the sending of messages to the central server. For all of these reasons, it is better to store log messages both centrally and on each host, so that they can be correlated if necessary.     Ensure Logs Sent To Remote Host To configure rsyslog to send logs to a remote log server, open /etc/rsyslog.conf and read and understand the last section of the file, which describes the multiple directives necessary to activate remote logging. Along with these other directives, the system can be configured to forward its logs to a particular log server by adding or correcting one of the following lines, substituting loghost.example.com appropriately. The choice of protocol depends on the environment of the system; although TCP and RELP provide more reliable message delivery, they may not be supported in all environments.
    To use UDP for log message delivery: 
    *.* @loghost.example.com

    To use TCP for log message delivery: 
    *.* @@loghost.example.com

    To use RELP for log message delivery: 
    *.* :omrelp:loghost.example.com
     To ensure logs are sent to a remote host, examine the file /etc/rsyslog.conf. If using UDP, a line similar to the following should be present: 
     *.* @loghost.example.com
    If using TCP, a line similar to the following should be present: 
     *.* @@loghost.example.com
    If using RELP, a line similar to the following should be present: 
     *.* :omrelp:loghost.example.com
     A log server (loghost) receives syslog messages from one or more systems. This data can be used as an additional log source in the event a system is compromised and its local logs are suspect. Forwarding log messages to a remote loghost also provides system administrators with a centralized place to view the status of multiple hosts within the enterprise.     Configure <tt>rsyslogd</tt> to Accept Remote Messages If Acting as a Log Server By default, rsyslog does not listen over the network for log messages. If needed, modules can be enabled to allow the rsyslog daemon to receive messages from other systems and for the system thus to act as a log server. If the machine is not a log server, then lines concerning these modules should remain commented out.

    Enable rsyslog to Accept Messages via TCP, if Acting As Log Server The rsyslog daemon should not accept remote messages unless the system acts as a log server. If the system needs to act as a central log server, add the following lines to /etc/rsyslog.conf to enable reception of messages over TCP: 
    $ModLoad imtcp
$InputTCPServerRun 514
     If the system needs to act as a log server, this ensures that it can receive messages over a reliable TCP connection.     Enable rsyslog to Accept Messages via UDP, if Acting As Log Server The rsyslog daemon should not accept remote messages unless the system acts as a log server. If the system needs to act as a central log server, add the following lines to /etc/rsyslog.conf to enable reception of messages over UDP: 
    $ModLoad imudp
$UDPServerRun 514
     Many devices, such as switches, routers, and other Unix-like systems, may only support the traditional syslog transmission over UDP. If the system must act as a log server, this enables it to receive their messages as well.     Ensure All Logs are Rotated by <tt>logrotate</tt> Edit the file /etc/logrotate.d/rsyslog. Find the first line, which should look like this (wrapped for clarity): 
    /var/log/messages /var/log/secure /var/log/maillog /var/log/spooler \
  /var/log/boot.log /var/log/cron {
    Edit this line so that it contains a one-space-separated listing of each log file referenced in /etc/rsyslog.conf.

    All logs in use on a system must be rotated regularly, or the log files will consume disk space over time, eventually interfering with system operation. The file /etc/logrotate.d/syslog is the configuration file used by the logrotate program to maintain all log files written by syslog. By default, it rotates logs weekly and stores four archival copies of each log. These settings can be modified by editing /etc/logrotate.conf, but the defaults are sufficient for purposes of this guide.

    Note that logrotate is run nightly by the cron job /etc/cron.daily/logrotate. If particularly active logs need to be rotated more often than once a day, some other mechanism must be used.     Ensure Logrotate Runs Periodically The logrotate utility allows for the automatic rotation of log files. The frequency of rotation is specified in /etc/logrotate.conf, which triggers a cron task. To configure logrotate to run daily, add or correct the following line in /etc/logrotate.conf: 
    # rotate log files frequency
daily
     Log files that are not properly rotated run the risk of growing so large that they fill up the /var/log partition. Valuable logging information could be lost if the /var/log partition becomes full. To determine the status and frequency of logrotate, run the following command: 
    $ sudo grep logrotate /var/log/cron*
    If logrotate is configured properly, output should include references to /etc/cron.daily.     scap-security-guide-0.1.31/Ubuntu/16.04/input/xccdf/system/partitions.xml000066400000000000000000000172121301675746700261270ustar00rootroot00000000000000 Hardening the filesystem Hardening the filesystem and its usage is an efficient way to ensure an efficient separation of services, data and configurations while ensuring a more precise management of filesystem level access rights, enabling deactivation of some specific rights at the filesystem level. Moreover, the Linux Virtual file system support various hardening mechanisms that can be set using sysctl. Partitioning Separating various locations of the file systems in different partitions allows a more restrictive segregation, distinctly from one location to another. Moreover, some native restrictions can be made by partitioning, such as no hard link between different filesystems, and reduce the corruption impact to the affected filesystem instead of the entire system. The last gain is to allow a differenciated usage of storage media, depending on the operational needs (speed, resilience, etc.). Filesystem Hierarchy Standard Ensure /tmp Located On Separate Partition The /tmp directory is a world-writable directory used for temporary file storage. Ensure it has its own partition or logical volume at installation time, or migrate it using LVM (when non-ephemeral is needed) or use tmpfs if possible. The /tmp partition is used as temporary storage by many programs. Placing /tmp in its own partition enables the setting of more restrictive mount options, which can help protect programs which use it. Ensure /var Located On Separate Partition The /var directory is used by daemons and other system services to store frequently-changing data. Ensure that /var has its own partition or logical volume at installation time, or migrate it using LVM. Ensuring that /var is mounted on its own partition enables the setting of more restrictive mount options. This helps protect system services such as daemons or other programs which use it. It is not uncommon for the /var directory to contain world-writable directories installed by other software packages. Ensure /var/log Located On Separate Partition System logs are stored in the /var/log directory. Ensure that it has its own partition or logical volume at installation time, or migrate it using LVM. Placing /var/log in its own partition enables better separation between log files and other files in /var/. Ensure /var/log/audit Located On Separate Partition Audit logs are stored in the /var/log/audit directory. Ensure that it has its own partition or logical volume at installation time, or migrate it later using LVM. Make absolutely certain that it is large enough to store all audit logs that will be created by the auditing daemon. Placing /var/log/audit in its own partition enables better separation between audit files and other files, and helps ensure that auditing cannot be halted due to the partition running out of space. Ensure /home Located On Separate Partition If user home directories will be stored locally, create a separate partition for /home at installation time (or migrate it later using LVM). If /home will be mounted from another system such as an NFS server, then creating a separate partition is not necessary at installation time, and the mountpoint can instead be configured later. Ensuring that /home is mounted on its own partition enables the setting of more restrictive mount options, and also helps ensure that users cannot trivially fill partitions used for log or audit data storage. Ensure /srv Located On Separate Partition If a file server (FTP, TFTP...) is hosted locally, create a separate partition for /srv at installation time (or migrate it later using LVM). If /srv will be mounted from another system such as an NFS server, then creating a separate partition is not necessary at installation time, and the mountpoint can instead be configured later. Srv deserves files for local network file server such as FTP. Ensuring that /srv is mounted on its own partition enables the setting of more restrictive mount options, and also helps ensure that users cannot trivially fill partitions used for log or audit data storage. filesystem rights management Adding filesystem specific hardening seriously limits various exploitation vectors based on filesystem invalid usage, such as invalid file types in invalid places (devices or setuid root files in external media, executable file in insecure filesystems, etc.). Some of these hardening require an efficient system partitioning. Disallow creating symlinks to a file you not own Disallowing such symlink mitigate vulnerabilities based on insecure file system accessed by privilegied programs, avoiding an exploitation vector exploiting unsafe use of open() or creat(). Disallow creating symlinks to a file you not own Disallowing such hardlink mitigate vulnerabilities based on insecure file system accessed by privilegied programs, avoiding an exploitation vector exploiting unsafe use of open() or creat(). scap-security-guide-0.1.31/Ubuntu/16.04/input/xccdf/system/permissions/000077500000000000000000000000001301675746700255615ustar00rootroot00000000000000scap-security-guide-0.1.31/Ubuntu/16.04/input/xccdf/system/permissions/execution.xml000066400000000000000000000104501301675746700303060ustar00rootroot00000000000000 Restrict Programs from Dangerous Execution Patterns The recommendations in this section are designed to ensure that the system's features to protect against potentially dangerous program execution are activated. These protections are applied at the system initialization or kernel level, and defend against certain types of badly-configured or compromised programs. Disable Core Dumps A core dump file is the memory image of an executable program when it was terminated by the operating system due to errant behavior. In most cases, only software developers legitimately need to access these files. The core dump files may also contain sensitive information, or unnecessarily occupy large amounts of disk space.

    Once a hard limit is set in /etc/security/limits.conf, a user cannot increase that limit within his or her own session. If access to core dumps is required, consider restricting them to only certain users or groups. See the limits.conf man page for more information.

    The core dumps of setuid programs are further protected. The sysctl variable fs.suid_dumpable controls whether the kernel allows core dumps from these programs at all. The default value of 0 is recommended.     Disable Core Dumps for SUID programs The core dump of a setuid program is more likely to contain wve data, as the program itself runs with greater privileges than the user who initiated execution of the program. Disabling the ability for any setuid program to write a core file decreases the risk of unauthorized access of such data.     Enable ExecShield ExecShield describes kernel features that provide protection against exploitation of memory corruption errors such as buffer overflows. These features include random placement of the stack and other memory regions, prevention of execution in memory that should only hold data, and special handling of text buffers. These protections are enabled by default on 32-bit systems and controlled through sysctl variables kernel.exec-shield and kernel.randomize_va_space. On the latest 64-bit systems, kernel.exec-shield cannot be enabled or disabled with sysctl. Enable Randomized Layout of Virtual Address Space Address space layout randomization (ASLR) makes it more difficult for an attacker to predict the location of attack code they have introduced into a process's address space during an attempt at exploitation. Additionally, ASLR makes it more difficult for an attacker to know the location of existing code in order to re-purpose it using return oriented programming (ROP) techniques. Restrict exposed kernel pointers addresses access Exposing kernel pointers (through procfs or seq_printf()) exposes kernel writeable structures that can contain functions pointers. If a write vulnereability occurs in the kernel allowing a write access to any of this structure, the kernel can be compromise. This option disallow any program withtout the CAP_SYSLOG capability from getting the kernel pointers addresses, replacing them with 0.     scap-security-guide-0.1.31/Ubuntu/16.04/input/xccdf/system/permissions/files.xml000066400000000000000000000126521301675746700274130ustar00rootroot00000000000000 Verify Permissions on Important Files and Directories Permissions for many files on a system must be set restrictively to ensure sensitive information is properly protected. This section discusses important permission restrictions which can be verified to ensure that no harmful discrepancies have arisen. Verify permissions on files containing sensitive informations about the system Various files contains sensitive informations that can leads to specific weaknesses or give structural informations for local exploits. Verify that local System.map file (if exists) is readable only by root Files containing sensitive informations should be protected by restrictive permissions. Most of the time, there is no need that these files need to be read by any non-root user The System.map file contains information about kernel symbols and can give some hints to generate local exploitation. Verify Permissions on Files with Local Account Information and Credentials The default restrictive permissions for files which act as important security databases such as passwd, shadow, group, and gshadow files must be maintained. Many utilities need read access to the passwd file in order to function properly, but read access to the shadow file allows malicious attacks against system passwords, and should never be enabled. Verify Permissions and ownership on <tt>shadow</tt> File The /etc/shadow file contains the list of local system accounts and stores password hashes. Protection of this file is critical for system security. Failure to give ownership of this file to root provides the designated owner with access to sensitive information which could weaken the system security posture. Verify Permissions and ownership on <tt>gshadow</tt> File The /etc/shadow file contains group password hashes. Protection of this file is critical for system security. Verify Permissions and ownership on <tt>passwd</tt> File The /etc/shadow file contains information about the users that are configured on the system. Protection of this file is critical for system security. Verify Permissions and ownership on <tt>group</tt> File The /etc/shadow file contains information about the groups that are configured on the system. Protection of this file is critical for system security. scap-security-guide-0.1.31/Ubuntu/16.04/templates/000077500000000000000000000000001301675746700214325ustar00rootroot00000000000000scap-security-guide-0.1.31/Ubuntu/16.04/templates/csv/000077500000000000000000000000001301675746700222255ustar00rootroot00000000000000scap-security-guide-0.1.31/Ubuntu/16.04/templates/csv/file_dir_permissions.csv000066400000000000000000000001261301675746700271510ustar00rootroot00000000000000/etc,shadow,0,42,0640 /etc,gshadow,0,42,0640 /etc,passwd,0,0,0644 /etc,group,0,0,0644 scap-security-guide-0.1.31/Ubuntu/16.04/templates/csv/oval_5.11/000077500000000000000000000000001301675746700236325ustar00rootroot00000000000000scap-security-guide-0.1.31/Ubuntu/16.04/templates/csv/oval_5.11/packages_installed.csv000066400000000000000000000000341301675746700301610ustar00rootroot00000000000000auditd, ntp, cron, rsyslog, scap-security-guide-0.1.31/Ubuntu/16.04/templates/csv/oval_5.11/services_disabled.csv000066400000000000000000000002351301675746700300210ustar00rootroot00000000000000# service_name, package_name, daemon_name (as recognized by chkconfig / systemd. To be used when daemon_name differs from service_name) sshd,openssh-server, scap-security-guide-0.1.31/Ubuntu/16.04/templates/csv/oval_5.11/services_enabled.csv000066400000000000000000000000611301675746700276410ustar00rootroot00000000000000auditd,auditd cron,cron ntpd,ntp rsyslog,rsyslog scap-security-guide-0.1.31/Ubuntu/16.04/templates/csv/packages_installed.csv000066400000000000000000000007301301675746700265570ustar00rootroot00000000000000# This file contains list of packages in the format of "daemon,pkgname" to # create "package_pkgname_installed" OVAL 5.10 checks for. # # If the corresponding "package_pkgname_installed" OVAL is not standalone # OVAL-5.10, but only a prerequisite in order to the corresponding # "service_daemon_enabled" OVAL-5.11 to work properly, such a package # SHOULD NOT be listed here, but rather in the 'packages_installed.csv' # file under oval_5.11/templates directory!!! # ntp, scap-security-guide-0.1.31/Ubuntu/16.04/templates/csv/packages_removed.csv000066400000000000000000000001071301675746700262370ustar00rootroot00000000000000telnetd, inetutils-telnetd, telnetd-ssl, ntpdate, nis, openssh-server, scap-security-guide-0.1.31/Ubuntu/16.04/templates/csv/services_disabled.csv000066400000000000000000000002401301675746700264100ustar00rootroot00000000000000# service_name, package_name, daemon_name (as recognized by chkconfig / systemd. To be used when daemon_name differs from service_name) sshd,openssh-server,ssh scap-security-guide-0.1.31/Ubuntu/16.04/templates/csv/sysctl_values.csv000066400000000000000000000010631301675746700256420ustar00rootroot00000000000000# Add to generate hard-coded OVAL and remediation content. # Add to generate OVAL and remediation content that use the XCCDF value. # xccdf value based (depend on the profile) net.ipv4.ip_forward, kernel.sysrq,0 fs.suid_dumpable,0 fs.protected_symlinks,1 fs.protected_hardlinks,1 kernel.randomize_va_space,2 vm.mmap_min_addr,65536 kernel.pid_max,65536 kernel.kptr_restrict,1 kernel.dmesg_restrict,1 kernel.perf_event_paranoid,2 kernel.perf_event_max_sample_rate,1 kernel.perf_cpu_time_max_percent,1 scap-security-guide-0.1.31/Ubuntu/16.04/templates/oval_5.11_templates/000077500000000000000000000000001301675746700251155ustar00rootroot00000000000000template_OVAL_package_installed000066400000000000000000000017051301675746700331320ustar00rootroot00000000000000scap-security-guide-0.1.31/Ubuntu/16.04/templates/oval_5.11_templates Package PKGNAME Installed Ubuntu 1604 The DEB package PKGNAME should be installed. PKGNAME scap-security-guide-0.1.31/Ubuntu/16.04/templates/oval_5.11_templates/template_service_disabled000066400000000000000000000042561301675746700322310ustar00rootroot00000000000000 Service SERVICENAME Disabled Ubuntu 1604 The SERVICENAME service should be disabled if possible. multi-user.target SERVICENAME.service scap-security-guide-0.1.31/Ubuntu/16.04/templates/oval_5.11_templates/template_service_enabled000066400000000000000000000041771301675746700320560ustar00rootroot00000000000000 Service SERVICENAME Enabled Ubuntu 1604 The SERVICENAME service should be enabled if possible. multi-user.target SERVICENAME.service scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/000077500000000000000000000000001301675746700227215ustar00rootroot00000000000000scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/bash/000077500000000000000000000000001301675746700236365ustar00rootroot00000000000000scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/bash/package_auditd_installed.sh000066400000000000000000000001241301675746700311530ustar00rootroot00000000000000# platform = Ubuntu 1604 # Include source function library. apt-get install auditd scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/bash/package_cron_installed.sh000066400000000000000000000001221301675746700306400ustar00rootroot00000000000000# platform = Ubuntu 1604 # Include source function library. apt-get install cron scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/bash/package_inetutils-telnetd_removed.sh000066400000000000000000000004521301675746700330440ustar00rootroot00000000000000# platform = Ubuntu 1604 # CAUTION: This remediation script will remove inetutils-telnetd # from the system, and may remove any packages # that depend on inetutils-telnetd. Execute this # remediation AFTER testing on a non-production # system! apt-get remove --purge inetutils-telnetd scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/bash/package_nis_removed.sh000066400000000000000000000004001301675746700301510ustar00rootroot00000000000000# platform = Ubuntu 1604 # CAUTION: This remediation script will remove nis # from the system, and may remove any packages # that depend on nis. Execute this # remediation AFTER testing on a non-production # system! apt-get remove --purge nis scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/bash/package_ntp_installed.sh000066400000000000000000000001211301675746700304770ustar00rootroot00000000000000# platform = Ubuntu 1604 # Include source function library. apt-get install ntp scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/bash/package_ntpd_installed.sh000066400000000000000000000001221301675746700306440ustar00rootroot00000000000000# platform = Ubuntu 1604 # Include source function library. apt-get install ntpd scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/bash/package_ntpdate_removed.sh000066400000000000000000000004141301675746700310240ustar00rootroot00000000000000# platform = Ubuntu 1604 # CAUTION: This remediation script will remove ntpdate # from the system, and may remove any packages # that depend on ntpdate. Execute this # remediation AFTER testing on a non-production # system! apt-get remove --purge ntpdate scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/bash/package_rsh-client_removed.sh000066400000000000000000000004251301675746700314370ustar00rootroot00000000000000# platform = Ubuntu 1604 # CAUTION: This remediation script will remove rsh-client # from the system, and may remove any packages # that depend on rsh-client. Execute this # remediation AFTER testing on a non-production # system! apt-get remove --purge rsh-client scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/bash/package_rsh-server_removed.sh000066400000000000000000000004251301675746700314670ustar00rootroot00000000000000# platform = Ubuntu 1604 # CAUTION: This remediation script will remove rsh-server # from the system, and may remove any packages # that depend on rsh-server. Execute this # remediation AFTER testing on a non-production # system! apt-get remove --purge rsh-server scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/bash/package_rsyslog_installed.sh000066400000000000000000000001251301675746700314040ustar00rootroot00000000000000# platform = Ubuntu 1604 # Include source function library. apt-get install rsyslog scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/bash/package_talk_removed.sh000066400000000000000000000004031301675746700303160ustar00rootroot00000000000000# platform = Ubuntu 1604 # CAUTION: This remediation script will remove talk # from the system, and may remove any packages # that depend on talk. Execute this # remediation AFTER testing on a non-production # system! apt-get remove --purge talk scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/bash/package_talkd_removed.sh000066400000000000000000000004061301675746700304650ustar00rootroot00000000000000# platform = Ubuntu 1604 # CAUTION: This remediation script will remove talkd # from the system, and may remove any packages # that depend on talkd. Execute this # remediation AFTER testing on a non-production # system! apt-get remove --purge talkd scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/bash/package_telnetd-ssl_removed.sh000066400000000000000000000004301301675746700316210ustar00rootroot00000000000000# platform = Ubuntu 1604 # CAUTION: This remediation script will remove telnetd-ssl # from the system, and may remove any packages # that depend on telnetd-ssl. Execute this # remediation AFTER testing on a non-production # system! apt-get remove --purge telnetd-ssl scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/bash/package_telnetd_removed.sh000066400000000000000000000004141301675746700310240ustar00rootroot00000000000000# platform = Ubuntu 1604 # CAUTION: This remediation script will remove telnetd # from the system, and may remove any packages # that depend on telnetd. Execute this # remediation AFTER testing on a non-production # system! apt-get remove --purge telnetd scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/oval/000077500000000000000000000000001301675746700236625ustar00rootroot00000000000000scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/oval/file_permissions_etc_passwd.xml000066400000000000000000000042471301675746700322010ustar00rootroot00000000000000 Verify /etc/passwd Permissions Ubuntu 1604 This test makes sure that /etc/passwd is owned by 0, group owned by 0, and has mode 0644. If the target file or directory has an extended ACL then it will fail the mode check. /etc passwd 0 0 false false false true true false true false false true false false scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/oval/file_permissions_etc_shadow.xml000066400000000000000000000042541301675746700321630ustar00rootroot00000000000000 Verify /etc/shadow Permissions Ubuntu 1604 This test makes sure that /etc/shadow is owned by 0, group owned by 42, and has mode 0640. If the target file or directory has an extended ACL then it will fail the mode check. /etc shadow 0 42 false false false true true false true false false false false false scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/oval/file_permissions_systemmap.xml000066400000000000000000000037311301675746700320640ustar00rootroot00000000000000 Verify that System.map files are readable only by root multi_platform_ubuntu Checks that /boot/System.map-* are only readable by root. /boot ^System\.map.*$ 0 false false false false false false false false false false scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/oval/installed_OS_is_ubuntu1604.xml000066400000000000000000000043551301675746700314030ustar00rootroot00000000000000 Ubuntu 1604 multi_platform_ubuntu The operating system installed on the system is Ubuntu 1604 /etc/lsb-release /etc/lsb-release ^DISTRIB_ID=Ubuntu$ 1 /etc/lsb-release ^DISTRIB_CODENAME=xenial$ 1 scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/oval/package_auditd_installed.xml000066400000000000000000000016731301675746700313770ustar00rootroot00000000000000 Package auditd Installed Ubuntu 1604 The DEB package auditd should be installed. auditd scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/oval/package_cron_installed.xml000066400000000000000000000016471301675746700310670ustar00rootroot00000000000000 Package cron Installed Ubuntu 1604 The DEB package cron should be installed. cron scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/oval/package_inetutils-telnetd_removed.xml000066400000000000000000000020261301675746700332550ustar00rootroot00000000000000 Package inetutils-telnetd Removed Ubuntu 1604 The DEB package inetutils-telnetd should be removed. inetutils-telnetd scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/oval/package_nis_removed.xml000066400000000000000000000016121301675746700303710ustar00rootroot00000000000000 Package nis Removed Ubuntu 1604 The DEB package nis should be removed. nis scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/oval/package_ntp_installed.xml000066400000000000000000000016351301675746700307240ustar00rootroot00000000000000 Package ntp Installed Ubuntu 1604 The DEB package ntp should be installed. ntp scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/oval/package_ntpdate_removed.xml000066400000000000000000000016621301675746700312440ustar00rootroot00000000000000 Package ntpdate Removed Ubuntu 1604 The DEB package ntpdate should be removed. ntpdate scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/oval/package_rsyslog_installed.xml000066400000000000000000000017051301675746700316230ustar00rootroot00000000000000 Package rsyslog Installed Ubuntu 1604 The DEB package rsyslog should be installed. rsyslog scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/oval/package_telnetd-ssl_removed.xml000066400000000000000000000017321301675746700320410ustar00rootroot00000000000000 Package telnetd-ssl Removed Ubuntu 1604 The DEB package telnetd-ssl should be removed. telnetd-ssl scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/oval/package_telnetd_removed.xml000066400000000000000000000016621301675746700312440ustar00rootroot00000000000000 Package telnetd Removed Ubuntu 1604 The DEB package telnetd should be removed. telnetd scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/oval/partition_for_home.xml000066400000000000000000000021441301675746700302740ustar00rootroot00000000000000 Ensure /home Located On Separate Partition Ubuntu 1604 If user home directories will be stored locally, create a separate partition for /home. If /home will be mounted from another system such as an NFS server, then creating a separate partition is not necessary at this time, and the mountpoint can instead be configured later. /home scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/oval/partition_for_srv.xml000066400000000000000000000022261301675746700301570ustar00rootroot00000000000000 Ensure /srv Located On Separate Partition Ubuntu 1604 If a file server (FTP, TFTP...) is hosted locally, create a separate partition for /srv at installation time (or migrate it later using LVM). If /srv will be mounted from another system such as an NFS server, then creating a separate partition is not necessary at installation time, and the mountpoint can instead be configured later. /srv scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/oval/partition_for_tmp.xml000066400000000000000000000016731301675746700301520ustar00rootroot00000000000000 Ensure /tmp Located On Separate Partition Ubuntu 1604 The /tmp directory is a world-writable directory used for temporary file storage. Verify that it has its own partition or logical volume. /tmp scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/oval/partition_for_var.xml000066400000000000000000000022141301675746700301320ustar00rootroot00000000000000 Ensure /var Located On Separate Partition Ubuntu 1604 Ensuring that /var is mounted on its own partition enables the setting of more restrictive mount options, which is used as temporary storage by many program, particularly system services such as daemons. It is not uncommon for the /var directory to contain world-writable directories, installed by other software packages. /var scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/oval/partition_for_var_log.xml000066400000000000000000000017051301675746700307770ustar00rootroot00000000000000 Ensure /var/log Located On Separate Partition Ubuntu 1604 System logs are stored in the /var/log directory. Ensure that it has its own partition or logical volume. /var/log scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/oval/partition_for_var_log_audit.xml000066400000000000000000000022101301675746700321550ustar00rootroot00000000000000 Ensure /var/log/audit Located On Separate Partition Ubuntu 1604 Audit logs are stored in the /var/log/audit directory. Ensure that it has its own partition or logical volume. Make absolutely certain that it is large enough to store all audit logs that will be created by the auditing daemon. /var/log/audit scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/oval_5.11/000077500000000000000000000000001301675746700243265ustar00rootroot00000000000000scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/oval_5.11/rsyslog_files_groupownership.xml000066400000000000000000000115741301675746700331170ustar00rootroot00000000000000 Confirm Existence and Permissions of System Log Files Ubuntu 1604 All syslog log files should be owned by the appropriate group. /etc/rsyslog.conf ^\$IncludeConfig[\s]+([^\s;]+) 1 %/etc/rsyslog.conf ^[^(\s|#|\$)]+[\s]+.*[\s]+-?(/+[^:;\s]+);*.*$ 1 regular 4 scap-security-guide-0.1.31/Ubuntu/16.04/templates/static/oval_5.11/rsyslog_files_permissions.xml000066400000000000000000000122401301675746700323660ustar00rootroot00000000000000 Confirm Existence and Permissions of System Log Files Ubuntu 1604 File permissions for all syslog log files should be set correctly. /etc/rsyslog.conf ^\$IncludeConfig[\s]+([^\s;]+) 1 %/etc/rsyslog.conf ^[^(\s|#|\$)]+[\s]+.*[\s]+-?(/+[^:;\s]+);*.*$ 1 regular false true false false false false false scap-security-guide-0.1.31/Ubuntu/16.04/templates/template_BASH_package_installed000066400000000000000000000002401301675746700274730ustar00rootroot00000000000000# platform = Ubuntu 1604 # reboot = false # strategy = enable # complexity = low # disruption = low # Include source function library. apt-get install PKGNAME scap-security-guide-0.1.31/Ubuntu/16.04/templates/template_BASH_package_removed000066400000000000000000000005301301675746700271570ustar00rootroot00000000000000# platform = Ubuntu 1604 # reboot = false # strategy = disable # complexity = low # disruption = low # CAUTION: This remediation script will remove PKGNAME # from the system, and may remove any packages # that depend on PKGNAME. Execute this # remediation AFTER testing on a non-production # system! apt-get remove --purge PKGNAME scap-security-guide-0.1.31/Ubuntu/16.04/templates/template_OVAL_package_installed000066400000000000000000000017051301675746700275260ustar00rootroot00000000000000 Package PKGNAME Installed Ubuntu 1604 The DEB package PKGNAME should be installed. PKGNAME scap-security-guide-0.1.31/Ubuntu/16.04/templates/template_package_removed000066400000000000000000000016621301675746700263710ustar00rootroot00000000000000 Package PKGNAME Removed Ubuntu 1604 The DEB package PKGNAME should be removed. PKGNAME scap-security-guide-0.1.31/Ubuntu/16.04/templates/template_permissions000066400000000000000000000030341301675746700256230ustar00rootroot00000000000000 Verify FILEPATH Permissions Ubuntu 1604 This test makes sure that FILEPATH is owned by FILEUID, group owned by FILEGID, and has mode FILEMODE. If the target file or directory has an extended ACL then it will fail the mode check. FILEDIR UNIX_FILENAME FILEUID FILEGID STATEMODE scap-security-guide-0.1.31/Ubuntu/16.04/templates/template_service_disabled000066400000000000000000000034071301675746700265430ustar00rootroot00000000000000 Service SERVICENAME Disabled Ubuntu 1604 The SERVICENAME service should be disabled if possible. ^/etc/rc[0-6S]\.d$ ^S\d{2}DAEMONNAME$ scap-security-guide-0.1.31/Ubuntu/16.04/templates/template_sysctl000066400000000000000000000014541301675746700245750ustar00rootroot00000000000000 Kernel "SYSCTLVAR" Parameter Configuration and Runtime Check Ubuntu 1604 The "SYSCTLVAR" kernel parameter should be set to the appropriate value in both system configuration and system runtime. scap-security-guide-0.1.31/Ubuntu/16.04/templates/template_sysctl_ipv6000066400000000000000000000020001301675746700255250ustar00rootroot00000000000000 Kernel "SYSCTLVAR" Parameter Configuration and Runtime Check Ubuntu 1604 The "SYSCTLVAR" kernel parameter should be set to the appropriate value in both system configuration and system runtime. scap-security-guide-0.1.31/Ubuntu/16.04/templates/template_sysctl_runtime000066400000000000000000000023321301675746700263340ustar00rootroot00000000000000 Kernel "SYSCTLVAR" Parameter Runtime Check Ubuntu 1604 The kernel "SYSCTLVAR" parameter should be set to "SYSCTLVAL" in system runtime. SYSCTLVAR SYSCTLVAL scap-security-guide-0.1.31/Ubuntu/16.04/templates/template_sysctl_runtime_var000066400000000000000000000026001301675746700272020ustar00rootroot00000000000000 Kernel "SYSCTLVAR" Parameter Runtime Check Ubuntu 1604 The kernel "SYSCTLVAR" parameter should be set to the appropriate value in system runtime. SYSCTLVAR scap-security-guide-0.1.31/Ubuntu/16.04/templates/template_sysctl_static000066400000000000000000000071221301675746700261420ustar00rootroot00000000000000 Kernel "SYSCTLVAR" Parameter Configuration Check Ubuntu 1604 The kernel "SYSCTLVAR" parameter should be set to "SYSCTLVAL" in the system configuration. /etc/sysctl.conf ^[\s]*SYSCTLVAR[\s]*=[\s]*SYSCTLVAL[\s]*$ 1 /etc/sysctl.d ^.*\.conf$ ^[\s]*SYSCTLVAR[\s]*=[\s]*SYSCTLVAL[\s]*$ 1 /run/sysctl.d ^.*\.conf$ ^[\s]*SYSCTLVAR[\s]*=[\s]*SYSCTLVAL[\s]*$ 1 /usr/lib/sysctl.d ^.*\.conf$ ^[\s]*SYSCTLVAR[\s]*=[\s]*SYSCTLVAL[\s]*$ 1 scap-security-guide-0.1.31/Ubuntu/16.04/templates/template_sysctl_static_var000066400000000000000000000105421301675746700270120ustar00rootroot00000000000000 Kernel "SYSCTLVAR" Parameter Configuration Check Ubuntu 1604 The kernel "SYSCTLVAR" parameter should be set to the appropriate value in the system configuration. /etc/sysctl.conf (?:^|.*\n)[^#]*SYSCTLVAR[\s]*=[\s]*(\d+)[\s]*\n 1 /etc/sysctl.d ^.*\.conf$ (?:^|.*\n)[^#]*SYSCTLVAR[\s]*=[\s]*(\d+)[\s]*\n 1 /run/sysctl.d ^.*\.conf$ (?:^|.*\n)[^#]*SYSCTLVAR[\s]*=[\s]*(\d+)[\s]*\n 1 /usr/lib/sysctl.d ^.*\.conf$ (?:^|.*\n)[^#]*SYSCTLVAR[\s]*=[\s]*(\d+)[\s]*\n 1 scap-security-guide-0.1.31/Ubuntu/16.04/transforms/000077500000000000000000000000001301675746700216325ustar00rootroot00000000000000scap-security-guide-0.1.31/Ubuntu/16.04/transforms/constants.xslt000066400000000000000000000022711301675746700245640ustar00rootroot00000000000000 Ubuntu 1604 Ubuntu 1604 UBUNTU_XENIAL_STIG UBUNTU-XENIAL cpe:/o:canonical:ubuntu_linux:16.04 ubuntu fixme scap-security-guide-0.1.31/Ubuntu/16.04/transforms/shorthand2xccdf.xslt000066400000000000000000000005221301675746700256310ustar00rootroot00000000000000 unknown unlinked-ubuntu1604-oval.xml scap-security-guide-0.1.31/Ubuntu/16.04/transforms/table-srgmap.xslt000066400000000000000000000011431301675746700251230ustar00rootroot00000000000000 scap-security-guide-0.1.31/Ubuntu/16.04/transforms/table-style.xslt000066400000000000000000000002541301675746700247740ustar00rootroot00000000000000 scap-security-guide-0.1.31/Ubuntu/16.04/transforms/xccdf-apply-overlay-stig.xslt000066400000000000000000000007541301675746700274110ustar00rootroot00000000000000 scap-security-guide-0.1.31/Ubuntu/16.04/transforms/xccdf-removeaux.xslt000066400000000000000000000005041301675746700256450ustar00rootroot00000000000000 scap-security-guide-0.1.31/Ubuntu/16.04/transforms/xccdf2table-byref.xslt000066400000000000000000000006771301675746700260460ustar00rootroot00000000000000 scap-security-guide-0.1.31/Ubuntu/16.04/transforms/xccdf2table-cce.xslt000066400000000000000000000007361301675746700254650ustar00rootroot00000000000000 scap-security-guide-0.1.31/Ubuntu/16.04/transforms/xccdf2table-profileanssirefs.xslt000066400000000000000000000067561301675746700303210ustar00rootroot00000000000000 <xsl:value-of select="/cdf:Benchmark/cdf:Profile[@id=$profile]/cdf:title" />



    Rule Title Description Rationale Variable Setting ANSSI Best practice Mapping

    scap-security-guide-0.1.31/Ubuntu/16.04/transforms/xccdf2table-profileccirefs.xslt000066400000000000000000000016071301675746700277300ustar00rootroot00000000000000 scap-security-guide-0.1.31/Ubuntu/16.04/transforms/xccdf2table-profilecisrefs.xslt000066400000000000000000000007101301675746700277420ustar00rootroot00000000000000 scap-security-guide-0.1.31/Ubuntu/16.04/transforms/xccdf2table-profilenistrefs.xslt000066400000000000000000000007101301675746700301410ustar00rootroot00000000000000 scap-security-guide-0.1.31/Ubuntu/16.04/transforms/xccdf2table-stig.xslt000066400000000000000000000006761301675746700257040ustar00rootroot00000000000000 scap-security-guide-0.1.31/Ubuntu/16.04/utils/000077500000000000000000000000001301675746700205745ustar00rootroot00000000000000scap-security-guide-0.1.31/Ubuntu/16.04/utils/README000066400000000000000000000010001301675746700214430ustar00rootroot00000000000000This file is meant to give a quick overview to some of the scripts located in this directory. verify-input-sanity.py Purpose: This script can be invoked without arguments to examine the files within src/input to make sure that they are in good shape *prior to* building the XCCDF and OVAL content with the various make commands. Intent: Help XCCDF and OVAL developers spot common mistakes *before* utilizing the Makefile to build the XCCDF and OVAL content. Usage: ./verify-input-sanity.py scap-security-guide-0.1.31/VERSION000066400000000000000000000041331301675746700165530ustar00rootroot00000000000000######################################################## # scap-security-guide Version # # # # scap-security-guide versions are as follows # # 0.1.x New production series # # 1.0.0GITabcdefg Build from GIT # # # ######################################################## SSG_PROJECT_NAME = scap-security-guide ######################################################## # This are the main version numbers # # # # .. # # # # e.g. SSG_MAJOR_VERSION = 0 # # SSG_MINOR_VERSION = 1 # # SSG_RELEASE_VERSION = 31 # # -> "0.1.31" # ######################################################## SSG_MAJOR_VERSION = 0.1 SSG_MINOR_VERSION = 31 SSG_RELEASE_VERSION = 1 ######################################################## # Contains the scap-security-guide release manager's # # name, email, and the date if the release i.e. # # 'git tag'. These are added to the rpm changelog # ######################################################## SSG_RELEASE_DATE = Mon Nov 28 2016 SSG_REL_MANAGER = Watson Yuuma Sato SSG_REL_MANAGER_MAIL = wsato@redhat.com ######################################################## # To mark GIT snapshots this should be set to 'yes' # # in the development BRANCH, and set to 'no' only in # # the SSG_X_X_RELEASE BRANCH # # # # ..GITxxx # # # # e.g. SSG_VERSION_IS_GIT_SNAPSHOT=yes # # -> "1.0.0GITabcdefg" # ######################################################## SSG_VERSION_IS_GIT_SNAPSHOT="yes" scap-security-guide-0.1.31/WRLinux/000077500000000000000000000000001301675746700170525ustar00rootroot00000000000000scap-security-guide-0.1.31/WRLinux/Makefile000066400000000000000000000070131301675746700205130ustar00rootroot00000000000000all: guide content dist SHARED = ../shared include $(SHARED)/product-make.include PROD = wrlinux VENDOR = ssgproject checks: standard-oval-build content: $(OUT)/xccdf-unlinked-final.xml checks cp $< $(OUT)/unlinked-$(PROD)-xccdf.xml # Remove auxiliary Groups which are only for use in tables, and not guide output. xsltproc -o $(OUT)/unlinked-$(PROD)-xccdf-guide.xml $(TRANS)/xccdf-removeaux.xslt $(OUT)/unlinked-$(PROD)-xccdf.xml $(SHARED)/$(UTILS)/cpe-generate.py $(OUT)/unlinked-$(PROD)-oval.xml $(IN)/oval/platform/$(PROD)-cpe-dictionary.xml $(ID) $(SHARED)/$(UTILS)/relabel-ids.py unlinked-$(PROD)-xccdf.xml $(ID) # Once things are relabelled, create a datastream xsltproc --stringparam reverse_DNS org.$(VENDOR).content /usr/share/openscap/xsl/xccdf_1.1_to_1.2.xsl \ $(OUT)/$(ID)-$(PROD)-xccdf.xml > $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml # Update @style attribute of to "SCAP_1.2". Fixes #1059 sed -i 's/style="SCAP_1.1"/style="SCAP_1.2"/' $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml oscap ds sds-compose $(OUT)/$(ID)-$(PROD)-xccdf-1.2.xml $(OUT)/$(ID)-$(PROD)-ds.xml # Update @schematron-version attribute in datastream to "1.2". Fixes #1191 # (Workaround for https://github.com/OpenSCAP/openscap/issues/383) sed -i 's/schematron-version="[0-9].[0-9]"/schematron-version="1.2"/' $(OUT)/$(ID)-$(PROD)-ds.xml # Fixes https://github.com/OpenSCAP/scap-security-guide/issues/1100 # Fixes https://github.com/OpenSCAP/scap-security-guide/issues/1101 $(SHARED)/$(UTILS)/sds-move-ocil-to-checks.py $(OUT)/$(ID)-$(PROD)-ds.xml $(OUT)/$(ID)-$(PROD)-ds.xml guide: content ifeq ($(OPENSCAP_1_1_OR_LATER), 0) $(SHARED)/$(UTILS)/build-all-guides.py --input $(OUT)/$(ID)-$(PROD)-ds.xml else @echo "Building guides from XCCDF 1.1, use OpenSCAP 1.1.0 or later for guides from datastreams!" $(SHARED)/$(UTILS)/build-all-guides.py --input $(OUT)/$(ID)-$(PROD)-xccdf.xml endif validate-xml: oscap xccdf validate-xml $(OUT)/$(ID)-$(PROD)-xccdf.xml oscap oval validate-xml --schematron $(OUT)/$(ID)-$(PROD)-oval.xml oscap ds sds-validate $(OUT)/$(ID)-$(PROD)-ds.xml validate: validate-xml validate-bash ifeq ($(OVAL_5_11), 0) cd $(OUT); ../$(SHARED)/$(UTILS)/verify-references.py --rules-with-invalid-checks --ovaldefs-unused $(ID)-$(PROD)-xccdf.xml else # If we are building against oscap version not supporting OVAL-5.11 language version yet, # don't call verify-references.py with "--rules-with-invalid-checks" argument, since the # OVAL checks using the 5.11 OVAL version will not be included in that case @echo -e "\nWarning:\n" @echo -e "\tWRLinux content build using oscap not supporting OVAL-5.11 language version detected!" @echo -e "\tSince the OVAL-5.11 WRLinux OVAL checks are missing, will skip test for referenced," @echo -e "\tbut undefined OVAL definitions during content validation. Consider building WRLinux" @echo -e "\tcontent with version OpenSCAP-1.2.2, or newer in order to perform full content validation!\n" cd $(OUT); ../$(SHARED)/$(UTILS)/verify-references.py --ovaldefs-unused $(ID)-$(PROD)-xccdf.xml endif # Items in dist are expected for distribution in an rpm dist: guide content mkdir -p $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-xccdf.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-oval.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-ocil.xml $(DIST)/content cp $(OUT)/$(ID)-$(PROD)-ds.xml $(DIST)/content mkdir -p $(DIST)/guide cp $(OUT)/*-guide-*.html $(DIST)/guide clean: rm -rf $(OUT)/* rm -f $(IN)/remediations/bash/templates/output/*.sh rm -rf $(OUT)/bash $(OUT)/ansible rm -rf $(DIST)/content $(DIST)/guide rm -rf $(BUILD) scap-security-guide-0.1.31/WRLinux/input/000077500000000000000000000000001301675746700202115ustar00rootroot00000000000000scap-security-guide-0.1.31/WRLinux/input/guide.xslt000066400000000000000000000146471301675746700222360ustar00rootroot00000000000000 A conditional clause for check statements. A conditional clause for check statements. This is a placeholder. scap-security-guide-0.1.31/WRLinux/input/oval/000077500000000000000000000000001301675746700211525ustar00rootroot00000000000000scap-security-guide-0.1.31/WRLinux/input/oval/accounts_logon_fail_delay.xml000066400000000000000000000031331301675746700270620ustar00rootroot00000000000000 Ensure that FAIL_DELAY is Configured in /etc/login.defs Wind River Linux 8 The delay between failed authentication attempts should be set for all users specified in /etc/login.defs /etc/login.defs ^[\s]*(?i)FAIL_DELAY(?-i)[\s]+([^#\s]*) 1 scap-security-guide-0.1.31/WRLinux/input/oval/file_permissions_unauthorized_sgid.xml000066400000000000000000000035121301675746700310560ustar00rootroot00000000000000 Find setgid files system packages Wind River Linux 8 All files with setgid should be owned by a base system package / ^.*$ state_file_permissions_unauthorized_sgid state_sgid_whitelist true /usr/bin/crontab /usr/sbin/postdrop /usr/sbin/postqueue scap-security-guide-0.1.31/WRLinux/input/oval/file_permissions_unauthorized_suid.xml000066400000000000000000000045241301675746700311000ustar00rootroot00000000000000 Find setuid files from system packages Wind River Linux 8 All files with setuid should be owned by a base system package / ^.*$ state_file_permissions_unauthorized_suid state_suid_whitelist true /bin/su.shadow /bin/su.util-linux /usr/bin/chage /usr/bin/chfn.shadow /usr/bin/chsh.shadow /usr/bin/expiry /usr/bin/gpasswd /usr/bin/newgidmap /usr/bin/newgrp.shadow /usr/bin/newuidmap /usr/bin/passwd.shadow /usr/bin/sudo /usr/lib64/dbus/dbus-daemon-launch-helper /usr/sbin/unix_chkpwd /usr/sbin/vlock-main scap-security-guide-0.1.31/WRLinux/input/oval/oval_5.11/000077500000000000000000000000001301675746700225575ustar00rootroot00000000000000scap-security-guide-0.1.31/WRLinux/input/oval/oval_5.11/.gitignore000066400000000000000000000000001301675746700245350ustar00rootroot00000000000000scap-security-guide-0.1.31/WRLinux/input/oval/platform/000077500000000000000000000000001301675746700227765ustar00rootroot00000000000000scap-security-guide-0.1.31/WRLinux/input/oval/platform/wrlinux-cpe-dictionary.xml000066400000000000000000000015261301675746700301440ustar00rootroot00000000000000 Wind River Linux 8 installed_OS_is_wrlinux Wind River Linux 9 installed_OS_is_wrlinux scap-security-guide-0.1.31/WRLinux/input/oval/service_sshd_disabled.xml000066400000000000000000000025131301675746700262050ustar00rootroot00000000000000 Service sshd Disabled multi_platform_wrlinux The sshd service should be disabled. /etc/systemd/system/multi-user.target.wants/sshd.service state_symlink symbolic link scap-security-guide-0.1.31/WRLinux/input/oval/templates/000077500000000000000000000000001301675746700231505ustar00rootroot00000000000000scap-security-guide-0.1.31/WRLinux/input/oval/templates/Makefile000066400000000000000000000021051301675746700246060ustar00rootroot00000000000000templates: services packages kernel_modules permissions umasks sysctls SHARED_DIR=../../../../shared/templates export PYTHONPATH=../../../../shared SHARED_TEMPLATES=../../../../shared/templates OUTPUT:=$(shell mkdir -p output) services: ${SHARED_DIR}/create_services_enabled.py services_enabled.csv ${SHARED_DIR}/create_services_disabled.py services_disabled.csv packages: ${SHARED_DIR}/create_package_installed.py packages_installed.csv ${SHARED_DIR}/create_package_removed.py packages_removed.csv kernel_modules: ${SHARED_DIR}/create_kernel_modules_disabled.py kernel_modules_disabled.csv permissions: ${SHARED_DIR}/create_permission_checks.py file_dir_permissions.csv umasks: ${SHARED_TEMPLATES}/create_umask_checks.py ${SHARED_TEMPLATES}/file_umask_checks.csv sysctls: ${SHARED_DIR}/create_sysctl_checks.py sysctl_values.csv compare: diff output/ ../ | grep -v "Only in ../" copy: cp output/*.xml ../ cp output/*.sh ../../remediations/bash/ find-untemplated: templates ${SHARED_DIR}/find_untemplated.py clean: rm -f output/*.xml rm -f output/*.sh rm -rf output/ scap-security-guide-0.1.31/WRLinux/input/oval/templates/README000066400000000000000000000024111301675746700240260ustar00rootroot00000000000000These templates are designed to make generation of OVAL tests which have repetitive structure easier. For example: $ ./create_services_disabled.py services_disabled.csv will produce all the OVAL checks (in a shorthand format) to disable services, and store them in the output directory. The CSV input files should contain all the relevant information for each check. Files should be compared to existing OVAL checks for consistency before copying to the main oval directory. A Makefile exists to activate all the scripts here and ease comparison with existing checks. For example, to run all scripts to generate OVAL checks from the available templates: $ make templates To compare the newly-generated files in the output directory to the existing checks, run: $ make compare Then, if the changes are agreeable, the following command can be run to copy the newly generated files to the main oval directory: $ make copy To list files that have been manually created (and may potentially be templated), run: # make find-untemplated Note, however, that some checks may have been intentionally hand-edited. For example, some sysctl checks (such as for IPv6) may include additional tests so that they pass if the IPv6 module is disabled. Never blindly copy over existing checks. scap-security-guide-0.1.31/WRLinux/input/oval/templates/output/000077500000000000000000000000001301675746700245105ustar00rootroot00000000000000scap-security-guide-0.1.31/WRLinux/input/oval/templates/output/.gitignore000066400000000000000000000000131301675746700264720ustar00rootroot00000000000000*.xml *.sh scap-security-guide-0.1.31/WRLinux/input/oval/templates/template_BASH_package_installed000066400000000000000000000002371301675746700312170ustar00rootroot00000000000000# platform = multi_platform_wrlinux # Include source function library. . /usr/share/scap-security-guide/remediation_functions package_command install PKGNAME scap-security-guide-0.1.31/WRLinux/input/oval/templates/template_BASH_package_removed000066400000000000000000000005621301675746700307020ustar00rootroot00000000000000# platform = multi_platform_wrlinux # CAUTION: This remediation script will remove PKGNAME # from the system, and may remove any packages # that depend on PKGNAME. Execute this # remediation AFTER testing on a non-production # system! # Include source function library. . /usr/share/scap-security-guide/remediation_functions package_command remove PKGNAME scap-security-guide-0.1.31/WRLinux/input/oval/testoval.py000077500000000000000000000003471301675746700233740ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/modules version SHARED_MODULE_PATH = "../../../shared/modules" sys.path.insert(0, SHARED_MODULE_PATH) import testoval_module if __name__ == "__main__": testoval_module.main() scap-security-guide-0.1.31/WRLinux/input/profiles/000077500000000000000000000000001301675746700220345ustar00rootroot00000000000000scap-security-guide-0.1.31/WRLinux/input/profiles/basic-embedded.xml000066400000000000000000000053441301675746700253740ustar00rootroot00000000000000 Basic Profile for Embedded Systems This profile contains items common to many embedded Linux installations. Regardless of your system's deployment objective, all of these checks should pass.
    collapse all

    The Navigation Menu above requires JavaScript to function.

    Enable JavaScript to allow the Navigation Menu to function.

    Disable CSS to view the Navigation options without JavaScript enabled

    Map Statistics Tech
    scap-security-guide-0.1.31/docs/html/en-US/toc.html000066400000000000000000000136501301675746700220050ustar00rootroot00000000000000 toc nav

    Welcome

    collapse all

    The Navigation Menu above requires JavaScript to function.

    Enable JavaScript to allow the Navigation Menu to function.

    Disable CSS to view the Navigation options without JavaScript enabled

    Map Statistics Tech
    scap-security-guide-0.1.31/docs/html/images/000077500000000000000000000000001301675746700206435ustar00rootroot00000000000000scap-security-guide-0.1.31/docs/html/images/arrows.png000066400000000000000000000023721301675746700226720ustar00rootroot00000000000000‰PNG  IHDR ôë×^sRGB®ÎébKGD³±±ÖÞÞ† pHYs × ×B(›xtIME× 01ÃC)zIDATxÚíÜAHYðÿL&u3MÅjrj¡¬¥F]Ë”R Ò‹,½¸îA–e¡ØC)ŠÐCO²PXÖKÉÁ–BOFh/¥´¥ˆZHi*Ù¢¨ÁÆDòt˜§óíÁf«š{éòý|“—?“7oÞa/DyðàA À ”7¡ …>UUÃ7oÞô={¶$±¾¾Ž‡n¹®Ûçyùòe¾­­Í]]] 777c~~¹\ÛÛÛ0 Ož00@BZ]]%! POOOû¡WÐÝÝ=F‰ˆ(Rww÷Øþϵýo„ƒ±Xì§`0x&‹åˆhðØñ ‡Ã‘p8Láp8òígÚ· …Ba@3€Q0ÆcŒ1ÆûÅãñX<?\F)¼xñ‚EÙ"¢{F®_¿.¿ «Å)%Z[[}¦iÞ—R&ž?Þ~dØq˜¦‰ÖÖV4666(Šòj|||l||Ÿw}>_2—Ëý AD¨ªªB*•‚”ò—åååEðìë[ZÓ´lÛþ±ººétù|þQ&“ùãÐË5M3`šæÆÅ‹É4Í Ó4ÇŽ®ë]×I×õHÙÁT÷ü¥ªªÊÓ1ÆcŒ1Æþÿ,ËŠY–uìæøþâ UU?X–uÛ²,ï±a×uÑÙÙé ÷]×M\¾|¹ýÈ°ã8¨ªªÂµk×påÊ•UU_…B¡±P(( K)!„ÀÄÄlÛFGG.\¸ðëÎÎÎ|}}}¤¾¾^=°…-„€”ïÞ½C6›ESSt]?333sps¼öx<8wîjjj099yø¶{1|éÒ%¬¬¬`jj Žã<0øùóçÒÍñµµ5$“Id³Ù€Èæææë£Vòäóù„®ë·u]÷–[ÉÇTU=Ïs™1ÆcŒ1ÆcŒ1ÆcŒý7"¢JÃ'úµ)‡9Ìas˜Ãæ0‡Ki°÷ç!åªFD /MåªV|ª+>ÜWÕ½0¡’ª}m@ÙªÑIFƒˆ* Âþn(([5P…CQìF¥ýP+†/Uûú¬]¾ªwxïvW~…U:åP „½WùªýÛ€òõ¤“¿òù¬U~^‚·x»Ë×Çwˆwa‚hÑIEND®B`‚scap-security-guide-0.1.31/docs/html/index.html000066400000000000000000000136671301675746700214100ustar00rootroot00000000000000 toc nav

    Welcome

    collapse all

    The Navigation Menu above requires JavaScript to function.

    Enable JavaScript to allow the Navigation Menu to function.

    Disable CSS to view the Navigation options without JavaScript enabled

    Map Statistics Tech
    scap-security-guide-0.1.31/docs/html/interactive.css000066400000000000000000000163121301675746700224300ustar00rootroot00000000000000.hidden {display:none;/*make submenu collapse*/} .version.collapsed, .version.expanded { background-image: url(images/arrows.png); background-repeat: no-repeat; } div.toc{ position:absolute; display:block; left:0; height:100%; } object.toc, iframe.toc{ height:100%; } .reset { float: right; text-align: right; padding-top: 0em; } .reset a { text-decoration: none; } .reset a:link, .reset a:visited { border-style: none; color: black; } .reset a:hover, .reset a:focus, .reset a:active { color: #777; } select, option { height: 1.5em; line-height: 1.5em; } div.nocookie { color: white; background-color: red; padding: 5px 20px; border: 1px solid #aaa; border-style: solid none; cursor: default; } span { margin: 0em !important; } .bottom_links a:link, .bottom_links a:visited, .types a:link, .types a:visited { border-style: none; } input { border: 1px solid #aaa; padding: 2px; } select { border: 1px solid #777; color: #444; background-color: #f6f6f6; width: 140px; cursor: pointer; } select:hover { background-color: #fff; color: black; border-color: black; } input:hover, select:hover { border-color: black; } form { padding: 0px; margin:0px; } div.search { padding: 12px 22px; background-color:#eee; } div.search .searchsub { cursor: pointer; color: black; background-color: #fafafa; font-size:.9em; } div.search .searchsub:hover { color: white; background-color: #444; border-color: #333; } div.search input:active, div.search input:focus { border-color: #69c !important; border-width: 1px; padding:2px; } div.lang { background-color: #ccc; padding:5px 20px; border: 1px solid #aaa; border-style: solid none; cursor: default; } .searchtxt { width: 150px; } div.lang:hover { background-color: #bbb; border-color: #777; } /*global*/ body { background-color: white; margin: 0em; font-family: "liberation sans", "Bitstream Vera Sans", "Luxi Sans", helvetica, verdana, arial, sans-serif; font-size: 9pt; color: #444; line-height: 150%; padding: 1em 1em; color: #555; position: relative; /* width: 100%;*/ float: left; } body.tocnav { background-color: white; margin: 0em; width: 100%; font-family: "liberation sans", "Bitstream Vera Sans", "Luxi Sans", helvetica, verdana, arial, sans-serif; font-size: 9pt; color: #444; line-height: 150%; padding: 0em 0em; color: #555; position: relative; } body.toc_embeded { /*for web hosting system only*/ margin-left: 300px; } object.toc, iframe.toc { /*for web hosting system only*/ border-style:none; position:fixed; width:290px; height:99.99%; top:0; left:0; z-index: 100; border-style:none; border-right:1px solid } .tocnav h1 span { display: none } .tocnav h1 a { display: block; width: 100%; height: 100px; background-image:url(images/title.png); background-repeat: no-repeat; background-color: #7b0000; } .tocnav h1 { margin:0em; padding:0em; } /*.tocnav select{border: 1px solid #777;margin:20px 0px 20px 20px; width:120px;cursor:pointer;} */ .tocnav div span { display: block; } /* Interactivity*/ .visible { display:block; } /*make submenu expand*/ .tocnav div:hover { cursor: default; } /*make link cursor*/ #tocnav { width:200px; } /*product*/ .tocnav div.product { line-height: 28px; border-bottom: 1px solid #eee; background-image: url(images/arrows.png); background-repeat: no-repeat; } .tocnav div.product:hover span.product { color: black; } .tocnav span.product { padding-left: 22px; font-size: 1.1em; color: #494949; background-color: transparent; padding-top: 2px; padding-bottom: 2px; line-height: 1.3em; cursor: pointer; } .product.expanded span.product { color: white; } .product.expanded:hover span.product { color: white !important; } .product.collapsed { background-position: 8px -82px; } .product.collapsed:hover { background-position: 8px -260px; } .product.expanded { color: white; background-color: #777; background-position: 8px 7px !important; } .product.expanded:hover { color: white !important; background-color: #666; background-position: 8px -170px !important; } .version div.untranslated { margin-left: 2em; } /*books*/ .tocnav div.book span.book { padding-left: 36px; background-color: white; color: #06c; text-decoration: underline; line-height: 1.3em; padding-top: 3px; padding-bottom: 0.4em; } .tocnav div.book span.book:hover { color: black; text-decoration: underline; } /*versions*/ .tocnav div.version { background-color: white; line-height: 20px; } .tocnav span.version { font-weight: bold; color: #999; cursor: pointer; } .tocnav span.version:hover { color: #000; } .tocnav span.version { padding-left: 36px; background-image: none; } .version.collapsed{ background-position: 22px -84px; } .version.collapsed:hover { background-position: 22px -260px; } .version.expanded span { color: #000; } .version.expanded { background-position: 22px 6px; } .version.expanded:hover { background-position: 22px -170px; } /*types*/ .tocnav .types { background-color: white; text-transform: uppercase; font-size: 0.8em; } .tocnav div.types { background: white; background-image: none; padding: 0em; padding-left: 32px; line-height: 8px; padding-bottom: 0.5em; } .types a:link ,.types a:visited { font-size: smaller; text-decoration: none; padding: 0em 0.5em; color: #777; } .types a:hover ,.types a:focus { font-size: smaller; text-decoration: none; padding: 0em 0.5em; color: #000; } .tocnav div.types a { padding-top: 0em; padding-left: 4px; } h1, h2, h3, h4, h5, th { color: #a70000 } .static_tocnavwrap ul { display: block; clear: both; } .static_tocnavwrap ul li { list-style: none; display: block; float: left; } .static_tocnavwrap ul li a { text-decoration: none; padding: 2px 5px; display: block; margin: 1px; } .static_tocnavwrap ul li a:link, .static_tocnavwrap ul li a:visited { color: #000; background-color: #eee; } .static_tocnavwrap ul li a:hover { color: white; background-color: black; } .static_tocnavwrap span.product { font-weight: bold; } .static_tocnavwrap .product { display: block; clear: both !important; background-image: none !important; } .static_tocnavwrap .book { width: 300px; float: left; } .static_tocnavwrap div.book { margin-bottom: 0.5em; } .static_tocnavwrap h1 { clear: both !important; padding-top: 1em; margin-left: 1em !important; font-size: 3em; color: #a70000; } .static_tocnavwrap h2 { clear: both !important; padding-top: 3em; margin-left: 1em !important; font-size: 2em; color: #a70000; } .static_tocnavwrap .version { clear: both; background-color: #eee; } div.bottom_links { background-color: #ccc; padding: 5px 20px; border: 1px solid #aaa; border-style: solid none; cursor: default; color: black; } div.bottom_links a { background-color: #eee; text-decoration:none; padding-left: 0.5em; padding-right: 0.5em; -moz-border-radius: 11px; -khtml-border-radius: 11px; -webkit-border-radius: 11px; } div.bottom_links a:link { color: black; } div.bottom_links a:hover { background-color:#bbb; } div.bottom_links a:visited { color:black; } h1.producttitle { width: 600px; margin: 0em; font-size: 3.0em; font-weight: bold; background: #336699 url(en-US/Common_Content/images/h1-bg.png) top left repeat; color: white; text-align: center; padding: 1em; } scap-security-guide-0.1.31/docs/html/site_overrides.css000066400000000000000000000000001301675746700231240ustar00rootroot00000000000000scap-security-guide-0.1.31/docs/html/toc.html000066400000000000000000000051761301675746700210620ustar00rootroot00000000000000 Map

    Map

    English (en-US)

    SCAP Security Guide
    0.1
    Developer Guide
    epub html html-single
    SCAP and STIG Workshop
    epub html html-single
    User Guide
    epub html html-single
    scap-security-guide-0.1.31/docs/html/toc.js000066400000000000000000000125531301675746700205270ustar00rootroot00000000000000var work = 1; var name_c = window.location.hostname + '-publican'; var num_days = 7; function setCookie(name, value, expires, path, domain, secure) { var curCookie = name + "=" + value + ((expires) ? ";expires=" + expires.toGMTString() : "") + ((path) ? ";path=" + path : ""); // + // ((domain) ? ";domain=" + domain : "") + // ((secure) ? ";secure" : ""); document.cookie = curCookie; } function addID(id) { var current_val = ""; if(document.cookie) { var cookies = document.cookie.split(/ *; */); for(var i=0; i < cookies.length; i++) { var current_c = cookies[i].split("="); if(current_c[0] == name_c) { current_val = current_c[1]; break; } } } if(current_val) { current_val += "," + id; } else { current_val = id; } var expDate = new Date(); expDate.setDate(expDate.getDate() + num_days); setCookie(name_c, current_val, expDate, '/', false, false); } function removeID(id) { var current_val = ""; if(document.cookie) { var cookies = document.cookie.split(/ *; */); for(var i=0; i < cookies.length; i++) { var current_c = cookies[i].split("="); if(current_c[0] == name_c) { current_val = current_c[1]; break; } } } if(current_val == id) { current_val = ""; } if(current_val.match("," + id + ",") != -1) { current_val = current_val.replace("," + id + ",", ","); } var rg = new RegExp("^" + id + ","); if(current_val.match(rg) != -1) { current_val = current_val.replace(rg, ""); } rg = new RegExp("," + id + "\$"); if(current_val.match(rg) != -1) { current_val = current_val.replace(rg, ""); } var expDate = new Date(); expDate.setDate(expDate.getDate() + num_days); setCookie(name_c, current_val, expDate, '/', false, false); } // TODO: Should really removeID all ID function clearCookie(id) { // TODO: split and toggle var current_val = ""; if(document.cookie) { var cookies = document.cookie.split(/ *; */); for(var i=0; i < cookies.length; i++) { var current_c = cookies[i].split("="); if(current_c[0] == name_c) { current_val = current_c[1]; break; } } } var ids = current_val.split(','); for(var j = 0; j < ids.length; j++) { work = 1; toggle("", ids[j]); } work = 1; current_val = ""; var expDate = new Date(); expDate.setDate(expDate.getDate() + num_days); setCookie(name_c, current_val, expDate, '/', false, false); } function getCookie() { var current_val = ""; if(document.cookie.length <= 0) { return;} var cookies = document.cookie.split(/ *; */); for(var i=0; i < cookies.length; i++) { var current_c = cookies[i].split("="); if(current_c[0] == name_c) { current_val = current_c[1]; break; } else if(current_c[0] == name_c + '-lang') { var lang = current_c[1]; var loc = location.href; var rg = new RegExp("/" + lang + "/"); if(loc.match(rg) == null) { location.href="../" + lang + "/toc.html"; } } } if(current_val.length <= 0) { return;} var ids = current_val.split(","); for(var i=0; i < ids.length; i++) { var entity = document.getElementById(ids[i]); if(entity) { var my_class = entity.className; var my_parent = entity.parentNode; if(my_class.indexOf("hidden") != -1) { entity.className = my_class.replace(/hidden/,"visible"); my_parent.className = my_parent.className.replace(/collapsed/,"expanded"); } } } } function toggle(e, id) { if(work) { work = 0; var entity = document.getElementById(id); if(entity) { var my_class = entity.className; var my_parent = entity.parentNode; if(my_class.indexOf("hidden") != -1) { entity.className = my_class.replace(/hidden/,"visible"); my_parent.className = my_parent.className.replace(/collapsed/,"expanded"); addID(id); } else if(my_class.indexOf("visible") != -1) { entity.className = my_class.replace(/visible/,"hidden"); my_parent.className = my_parent.className.replace(/expanded/,"collapsed"); removeID(id); } else { } } } } function loadToc() { var my_select = document.getElementById('langselect'); if (my_select.selectedIndex > 0) { var expDate = new Date(); expDate.setDate(expDate.getDate() + num_days); setCookie(name_c + '-lang', my_select.options[my_select.selectedIndex].value, expDate, '/', false, false); location.href="../" + my_select.options[my_select.selectedIndex].value + "/toc.html"; // parent.frames.main.location.replace("../" + my_select.options[my_select.selectedIndex].value + "/index.html"); } } function checkCookie() { var found = false; var testCookie = 'test_nocookie'; addID(testCookie); if(document.cookie) { var cookies = document.cookie.split(/ *; */); for(var i=0; i < cookies.length; i++) { var current_c = cookies[i].split("="); if(current_c[0] == name_c) { var ids = current_c[1].split(','); for( var j=0; j < ids.length; j++) { if(ids[j] == testCookie) { found = true; break; } } break; } } } if (found) { removeID(testCookie); } else { var entity = document.getElementById('nocookie'); var my_class = entity.className; entity.className = my_class.replace(/hidden/, "nocookie"); // alert("DEBUG: The Navigation Menu requires cookies to be enabled to function correctly."); } } function hideNoJS() { var entity = document.getElementById('nojs'); entity.className = 'hidden'; } scap-security-guide-0.1.31/docs/scap-security-guide.8000066400000000000000000000504311301675746700224140ustar00rootroot00000000000000.TH scap-security-guide 8 "26 Jan 2013" "version 1" .SH NAME SCAP Security Guide - Delivers security guidance, baselines, and associated validation mechanisms utilizing the Security Content Automation Protocol (SCAP). .SH DESCRIPTION The project provides practical security hardening advice for Red Hat products, and also links it to compliance requirements in order to ease deployment activities, such as certification and accreditation. These include requirements in the U.S. government (Federal, Defense, and Intelligence Community) as well as of the financial services and health care industries. For example, high-level and widely-accepted policies such as NIST 800-53 provides prose stating that System Administrators must audit "privileged user actions," but do not define what "privileged actions" are. The SSG bridges the gap between generalized policy requirements and specific implementation guidance, in SCAP formats to support automation whenever possible. The projects homepage is located at: https://www.open-scap.org/security-policies/scap-security-guide .SH Red Hat Enterprise Linux 6 PROFILES The Red Hat Enterprise Linux 6 SSG content is broken into 'profiles,' groupings of security settings that correlate to a known policy. Available profiles are: .I C2S .RS The C2S profile demonstrates compliance against the U.S. Government Commercial Cloud Services (C2S) baseline. This baseline was inspired by the Center for Internet Security (CIS) Red Hat Enterprise Linux 7 Benchmark, v1.1.0 - 04-02-2015. For the SCAP Security Guide project to remain in compliance with CIS' terms and conditions, specifically Restrictions(8), note there is no representation or claim that the C2S profile will ensure a system is in compliance or consistency with the CIS baseline. .RE .I CS2 .RS The CS2 is an example of a customized server profile. .RE .I CSCF-RHEL6-MLS .RS The CSCF RHEL6 MLS Core Baseline profile reflects the Centralized Super Computing Facility (CSCF) baseline for Red Hat Enterprise Linux 6. This baseline has received government ATO through the ICD 503 process, utilizing the CNSSI 1253 cross domain overlay. This profile should be considered in active development. Additional tailoring will be needed, such as the creation of RBAC roles for production deployment. .RE .I common .RS The Common Profile for General-Purpose Systems profile contains items common to general-purpose desktop and server installations. .RE .I desktop .RS The Desktop Baseline profile is for a desktop installation of Red Hat Enterprise Linux 6. .RE .I fisma-medium-rhel6-server .RS A FISMA Medium profile for Red Hat Enterprise Linux 6 .RE .I ftp .RS A profile for FTP servers .RE .I nist-cl-il-al .RS The CNSSI 1253 Low/Low/Low Control Baseline for Red Hat Enterprise Linux 6 Profile follows the Committee on National Security Systems Instruction (CNSSI) No. 1253, "Security Categorization and Control Selection for National Security Systems" on security controls to meet low confidentiality, low integrity, and low assurance." .RE .I pci-dss .RS The PCI-DSS v3 Control Baseline Profile for Red Hat Enterprise Linux 6 is a *draft* profile for PCI-DSS v3 .RE .I rht-ccp .RS The Red Hat Corporate Profile for Certified Cloud Providers (RH CCP) profile is a *draft* SCAP profile for Red Hat Certified Cloud Providers. .RE .I server .RS The Server Baseline profile is for Red Hat Enterprise Linux 6 acting as a server. .RE .I standard .RS The Standard System Security Profile contains rules to ensure standard security baseline of Red Hat Enterprise Linux 6 system. Regardless of your system's workload all of these checks should pass. .RE .I stig-rhel6-server-gui-upstream .RS The Security Technical Implementation Guides (STIGs) and the NSA Guides are the configuration standards for DOD IA and IA-enabled devices/systems. Since 1998, DISA Field Security Operations (FSO) has played a critical role enhancing the security posture of DoD's security systems by providing the Security Technical Implementation Guides (STIGs). This profile was created as a collaboration effort between the National Security Agency, DISA FSO, and Red Hat. As a result of the upstream/downstream relationship between the SCAP Security Guide project and the official DISA FSO STIG baseline, users should expect variance between SSG and DISA FSO content. For additional information relating to STIGs, please refer to the DISA FSO webpage at http://iase.disa.mil/stigs/ While this profile is packaged by Red Hat as part of the SCAP Security Guide package, please note that commercial support of this SCAP content is NOT available. This profile is provided as example SCAP content with no endorsement for suitability or production readiness. Support for this profile is provided by the upstream SCAP Security Guide community on a best-effort basis. The upstream project homepage is https://www.open-scap.org/security-policies/scap-security-guide. .RE .I stig-rhel6-server-upstream .RS The Security Technical Implementation Guides (STIGs) and the NSA Guides are the configuration standards for DOD IA and IA-enabled devices/systems. Since 1998, DISA Field Security Operations (FSO) has played a critical role enhancing the security posture of DoD's security systems by providing the Security Technical Implementation Guides (STIGs). This profile was created as a collaboration effort between the National Security Agency, DISA FSO, and Red Hat. As a result of the upstream/downstream relationship between the SCAP Security Guide project and the official DISA FSO STIG baseline, users should expect variance between SSG and DISA FSO content. For additional information relating to STIGs, please refer to the DISA FSO webpage at http://iase.disa.mil/stigs/ While this profile is packaged by Red Hat as part of the SCAP Security Guide package, please note that commercial support of this SCAP content is NOT available. This profile is provided as example SCAP content with no endorsement for suitability or production readiness. Support for this profile is provided by the upstream SCAP Security Guide community on a best-effort basis. The upstream project homepage is https://www.open-scap.org/security-policies/scap-security-guide. This profile is being developed under the DoD consensus model to become a STIG in coordination with DISA FSO. .RE .I stig-rhel6-workstation-upstream .RS The Security Technical Implementation Guides (STIGs) and the NSA Guides are the configuration standards for DOD IA and IA-enabled devices/systems. Since 1998, DISA Field Security Operations (FSO) has played a critical role enhancing the security posture of DoD's security systems by providing the Security Technical Implementation Guides (STIGs). This profile was created as a collaboration effort between the National Security Agency, DISA FSO, and Red Hat. As a result of the upstream/downstream relationship between the SCAP Security Guide project and the official DISA FSO STIG baseline, users should expect variance between SSG and DISA FSO content. For additional information relating to STIGs, please refer to the DISA FSO webpage at http://iase.disa.mil/stigs/ While this profile is packaged by Red Hat as part of the SCAP Security Guide package, please note that commercial support of this SCAP content is NOT available. This profile is provided as example SCAP content with no endorsement for suitability or production readiness. Support for this profile is provided by the upstream SCAP Security Guide community on a best-effort basis. The upstream project homepage is https://www.open-scap.org/security-policies/scap-security-guide. This profile is being developed under the DoD consensus model to become a STIG in coordination with DISA FSO. .RE .I usgcb-rhel6-server .RS The purpose of the United States Government Configuration Baseline (USGCB) initiative is to create security configuration baselines for Information Technology products widely deployed across the federal agencies. The USGCB baseline evolved from the Federal Desktop Core Configuration mandate. The USGCB is a Federal government-wide initiative that provides guidance to agencies on what should be done to improve and maintain an effective configuration settings focusing primarily on security. .B "NOTE: " While the current content maps to USGCB requirements, it has NOT been validated by NIST as of yet. This content should be considered draft, we are highly interested in feedback. For additional information relating to USGCB, please refer to the NIST webpage at http://usgcb.nist.gov/usgcb_content.html. .RE .SH Red Hat Enterprise Linux 7 PROFILES The Red Hat Enterprise Linux 7 SSG content is broken into 'profiles,' groupings of security settings that correlate to a known policy. Available profiles are: .I C2S .RS The C2S profile demonstrates compliance against the U.S. Government Commercial Cloud Services (C2S) baseline. This baseline was inspired by the Center for Internet Security (CIS) Red Hat Enterprise Linux 7 Benchmark, v1.1.0 - 04-02-2015. For the SCAP Security Guide project to remain in compliance with CIS' terms and conditions, specifically Restrictions(8), note there is no representation or claim that the C2S profile will ensure a system is in compliance or consistency with the CIS baseline. .RE .I cjis-rhel7-server .RS The Criminal Justice Information Services Security Policy is a *draft* profile for CJIS v5.4. The scope of this profile is to configure Red Hat Enteprise Linux 7 against the U. S. Department of Justice, FBI CJIS Security Policy. .RE .I common .RS The common profile is intended to be used as a base, universal profile for scanning of general-purpose Red Hat Enterprise Linux systems. .RE .I docker-host .RS The Standard Docker Host Security Profile contains rules to ensure standard security baseline of Red Hat Enterprise Linux 7 system running the docker daemon. This discussion is currently being held on open-scap-list@redhat.com and scap-security-guide@lists.fedorahosted.org. .RE .I nist-cl-il-al .RS The CNSSI 1253 Low/Low/Low Control Baseline for Red Hat Enterprise Linux 7 Profile follows the Committee on National Security Systems Instruction (CNSSI) No. 1253, "Security Categorization and Control Selection for National Security Systems" on security controls to meet low confidentiality, low integrity, and low assurance." .RE .I ospp-rhel7-server .RS This is a *draft* profile for NIAP OSPP v4.0. This profile is being developed under the National Information Assurance Partnership. The scope of this profile is to configure Red Hat Enteprise Linux 7 against the NIAP Protection Profile for General Purpose Operating Systems v4.0. The NIAP OSPP profile also serves as a working draft for USGCB submission against RHEL7 Server. .RE .I pci-dss .RS The PCI-DSS v3 Control Baseline Profile for Red Hat Enterprise Linux 7 is a *draft* profile for PCI-DSS v3 .RE .I rht-ccp .RS The Red Hat Corporate Profile for Certified Cloud Providers (RH CCP) profile is a *draft* SCAP profile for Red Hat Certified Cloud Providers. .RE .I standard .RS The Standard System Security Profile contains rules to ensure standard security baseline of Red Hat Enterprise Linux 7 system. Regardless of your system's workload all of these checks should pass. .RE .I stig-rhel7-server-gui-upstream .RS The STIG for Red Hat Enterprise Linux 7 Server Running GUIs is a *draft* profile for STIG. The Security Technical Implementation Guides (STIGs) and the NSA Guides are the configuration standards for DOD IA and IA-enabled devices/systems. Since 1998, DISA Field Security Operations (FSO) has played a critical role enhancing the security posture of DoD's security systems by providing the Security Technical Implementation Guides (STIGs). This profile was created as a collaboration effort between the National Security Agency, DISA FSO, and Red Hat. As a result of the upstream/downstream relationship between the SCAP Security Guide project and the official DISA FSO STIG baseline, users should expect variance between SSG and DISA FSO content. For additional information relating to STIGs, please refer to the DISA FSO webpage at http://iase.disa.mil/stigs/ While this profile is packaged by Red Hat as part of the SCAP Security Guide package, please note that commercial support of this SCAP content is NOT available. This profile is provided as example SCAP content with no endorsement for suitability or production readiness. Support for this profile is provided by the upstream SCAP Security Guide community on a best-effort basis. The upstream project homepage is https://www.open-scap.org/security-policies/scap-security-guide. This profile is being developed under the DoD consensus model to become a STIG in coordination with DISA FSO. .RE .I stig-rhel7-server-upstream .RS The STIG for Red Hat Enterprise Linux 7 Server is a *draft* profile for STIG. The Security Technical Implementation Guides (STIGs) and the NSA Guides are the configuration standards for DOD IA and IA-enabled devices/systems. Since 1998, DISA Field Security Operations (FSO) has played a critical role enhancing the security posture of DoD's security systems by providing the Security Technical Implementation Guides (STIGs). This profile was created as a collaboration effort between the National Security Agency, DISA FSO, and Red Hat. As a result of the upstream/downstream relationship between the SCAP Security Guide project and the official DISA FSO STIG baseline, users should expect variance between SSG and DISA FSO content. For additional information relating to STIGs, please refer to the DISA FSO webpage at http://iase.disa.mil/stigs/ While this profile is packaged by Red Hat as part of the SCAP Security Guide package, please note that commercial support of this SCAP content is NOT available. This profile is provided as example SCAP content with no endorsement for suitability or production readiness. Support for this profile is provided by the upstream SCAP Security Guide community on a best-effort basis. The upstream project homepage is https://www.open-scap.org/security-policies/scap-security-guide. This profile is being developed under the DoD consensus model to become a STIG in coordination with DISA FSO. .RE .I stig-rhel7-workstation-upstream .RS The STIG for Red Hat Enterprise Linux 7 Workstation is a *draft* profile for STIG. The Security Technical Implementation Guides (STIGs) and the NSA Guides are the configuration standards for DOD IA and IA-enabled devices/systems. Since 1998, DISA Field Security Operations (FSO) has played a critical role enhancing the security posture of DoD's security systems by providing the Security Technical Implementation Guides (STIGs). This profile was created as a collaboration effort between the National Security Agency, DISA FSO, and Red Hat. As a result of the upstream/downstream relationship between the SCAP Security Guide project and the official DISA FSO STIG baseline, users should expect variance between SSG and DISA FSO content. For additional information relating to STIGs, please refer to the DISA FSO webpage at http://iase.disa.mil/stigs/ While this profile is packaged by Red Hat as part of the SCAP Security Guide package, please note that commercial support of this SCAP content is NOT available. This profile is provided as example SCAP content with no endorsement for suitability or production readiness. Support for this profile is provided by the upstream SCAP Security Guide community on a best-effort basis. The upstream project homepage is https://www.open-scap.org/security-policies/scap-security-guide. This profile is being developed under the DoD consensus model to become a STIG in coordination with DISA FSO. .RE .SH Fedora PROFILES The Fedora SSG content is broken into 'profiles,' groupings of security settings that correlate to a known policy. Currently available profile: .I common .RS The common profile is intended to be used as a base, universal profile for scanning of general-purpose Fedora systems. .RE .I standard .RS The Standard System Security Profile contains rules to ensure standard security baseline of a Fedora system. Regardless of your system's workload all of these checks should pass. .RE .SH EXAMPLES To scan your system utilizing the OpenSCAP utility against the stig-rhel6-server-upstream profile: oscap xccdf eval --profile stig-rhel6-server-upstream \ --results /tmp/`hostname`-ssg-results.xml \ --report /tmp/`hostname`-ssg-results.html \ --cpe /usr/share/scap/ssg/ssg-rhel6-cpe-dictionary.xml \ /usr/share/scap/ssg/ssg-rhel6-xccdf.xml .PP Additional details can be found on the projects wiki page: https://www.github.com/OpenSCAP/scap-security-guide/wiki .SH FILES .I /usr/share/scap/ssg/ .RS Houses SCAP content utilizing the following naming conventions: .I CPE_Dictionaries: ssg-{profile}-cpe-dictionary.xml .I CPE_OVAL_Content: ssg-{profile}-cpe-oval.xml .I OVAL_Content: ssg-{profile}-oval.xml .I XCCDF_Content: ssg-{profile}-xccdf.xml .RE .I /usr/share/doc/scap-security-guide/guides/ .RS HTML versions of SSG profiles. .RE .SH STATEMENT OF SUPPORT The SCAP Security Guide, an open source project jointly maintained by Red Hat and the NSA, provides XCCDF and OVAL content for Red Hat technologies. As an open source project, community participation extends into U.S. Department of Defense agencies, civilian agencies, academia, and other industrial partners. SCAP Security Guide is provided to consumers through Red Hat's Extended Packages for Enterprise Linux (EPEL) repository. As such, SCAP Security Guide content is considered "vendor provided." Note that while Red Hat hosts the infrastructure for this project and Red Hat engineers are involved as maintainers and leaders, there is no commercial support contracts or service level agreements provided by Red Hat. Support, for both users and developers, is provided through the SCAP Security Guide community. Homepage: https://www.open-scap.org/security-policies/scap-security-guide .PP Mailing List: https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide .SH DEPLOYMENT TO U.S. CIVILIAN GOVERNMENT SYSTEMS SCAP Security Guide content is considered vendor (Red Hat) provided content. Per guidance from the U.S. National Institute of Standards and Technology (NIST), U.S. Government programs are allowed to use Vendor produced SCAP content in absence of "Governmental Authority" checklists. The specific NIST verbage: http://web.nvd.nist.gov/view/ncp/repository/glossary?cid=1#Authority .SH DEPLOYMENT TO U.S. MILITARY SYSTEMS DoD Directive (DoDD) 8500.1 requires that "all IA and IA-enabled IT products incorporated into DoD information systems shall be configured in accordance with DoD-approved security configuration guidelines" and tasks Defense Information Systems Agency (DISA) to "develop and provide security configuration guidance for IA and IA-enabled IT products in coordination with Director, NSA." The output of this authority is the DISA Security Technical Implementation Guides, or STIGs. DISA FSO is in the process of moving the STIGs towards the use of the NIST Security Content Automation Protocol (SCAP) in order to "automate" compliance reporting of the STIGs. Through a common, shared vision, the SCAP Security Guide community enjoys close collaboration directly with NSA and DISA FSO. As stated in Section 1.1 of the Red Hat Enterprise Linux 6 STIG Overview, Version 1, Release 2, issued on 03-JUNE-2013: "The consensus content was developed using an open-source project called SCAP Security Guide. The project's website is https://www.open-scap.org/security-policies/scap-security-guide. Except for differences in formatting to accomodate the DISA STIG publishing process, the content of the Red Hat Enterprise Linux 6 STIG should mirrot the SCAP Security Guide content with only minor divergence as updates from multiple sources work through the concensus process." The DoD STIG for Red Hat Enterprise Linux 6 was released June 2013. Currently, the DoD Red Hat Enterprise Linux 6 STIG contains only XCCDF content and is available online: http://iase.disa.mil/stigs/os/unix-linux/Pages/red-hat.aspx Content published against the iase.disa.mil website is authoritative STIG content. The SCAP Security Guide project, as noted in the STIG overview, is considered upstream content. Unlike DISA FSO, the SCAP Security Guide project does publish OVAL automation content. Individual programs and C&A evaluators make program-level determinations on the direct usage of the SCAP Security Guide. Currently there is no blanket approval. .SH SEE ALSO .B oscap(8) .SH AUTHOR Please direct all questions to the SSG mailing list: https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide scap-security-guide-0.1.31/docs/ssg-docs.cfg000066400000000000000000000003621301675746700206360ustar00rootroot00000000000000# Config::Simple 4.59 # Wed Oct 30 14:50:23 2013 db_file: /var/www/html/scap-security-guide/docs/ssg-docs.db toc_path: /var/www/html/scap-security-guide/docs/html title: "SCAP Security Guide" host: http://docs.ssgproject.org def_lang: en-US scap-security-guide-0.1.31/docs/ssg-docs.db000066400000000000000000000120001301675746700204540ustar00rootroot00000000000000SQLite format 3@ k ü©PÑþ©S{tablesettingssettingsCREATE TABLE settings ( host text(255), search blob )P++Ytablesqlite_sequencesqlite_sequenceCREATE TABLE sqlite_sequence(name,seq)‚~…[tablebooksbooksCREATE TABLE books ( ID INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, language text(255) NOT NULL, product text(255) NOT NULL, version text(255) NOT NULL, name text(255) NOT NULL, format text(31) NOT NULL, product_label text(255), version_label text(255), name_label text(255), update_date text(10), UNIQUE(language, product, version, name, format) ))=indexsqlite_autoindex_books_1books x4¹ôt¨cÄxJ 39!en-USSCAP_Security_Guide0.1SCAP_and_STIG_Workshopepub2014-05-12Q 39#!en-USSCAP_Security_Guide0.1SCAP_and_STIG_Workshophtml-single2014-05-12J 39!en-USSCAP_Security_Guide0.1SCAP_and_STIG_Workshophtml2014-05-12C 3+!en-USSCAP_Security_Guide0.1Developer_Guideepub2014-05-12J 3+#!en-USSCAP_Security_Guide0.1Developer_Guidehtml-single2014-05-12> 3!!en-USSCAP_Security_Guide0.1User_Guideepub2014-05-12> 3!!en-USSCAP_Security_Guide0.1User_Guidehtml2014-05-12C 3+!en-USSCAP_Security_Guide0.1Developer_Guidehtml2014-05-12E 3!#!en-USSCAP_Security_Guide0.1User_Guidehtml-single2014-05-12 ö·îöy4,^Ç=39en-USSCAP_Security_Guide0.1SCAP_and_STIG_WorkshopepubD39#en-USSCAP_Security_Guide0.1SCAP_and_STIG_Workshophtml-single=39en-USSCAP_Security_Guide0.1SCAP_and_STIG_Workshophtml63+en-USSCAP_Security_Guide0.1Developer_Guideepub=3+#en-USSCAP_Security_Guide0.1Developer_Guidehtml-single13!en-USSCAP_Security_Guide0.1User_Guideepub 13!en-USSCAP_Security_Guide0.1User_Guidehtml 63+en-USSCAP_Security_Guide0.1Developer_Guidehtml 83!#en-USSCAP_Security_Guide0.1User_Guidehtml-single õõ books ááAhttp://docs.ssgproject.orgscap-security-guide-0.1.31/scap-security-guide.spec.in000066400000000000000000000207471301675746700226630ustar00rootroot00000000000000Name: __NAME__ Version: __VERSION__ Release: __RELEASE__%{?dist} Summary: Security guidance and baselines in SCAP formats Vendor: scap-security-guide Group: Applications/System License: Public Domain URL: https://www.open-scap.org/security-policies/scap-security-guide/ Source0: https://github.com/OpenSCAP/scap-security-guide/archive/%{name}-%{version}.tar.gz BuildArch: noarch BuildRequires: libxslt, expat, python, openscap-utils >= 1.0.3, python-lxml %if 0%{?fedora} BuildRequires: openscap-utils >= 1.2.2 BuildRequires: ShellCheck %endif %if 0%{?wrlinux} BuildRequires: openscap-utils >= 1.2 %endif Requires: xml-common, openscap-utils >= 1.0.8 Provides: openscap-content %description The %{name} project provides a guide for configuration of the system from the final system's security point of view. The guidance is specified in the Security Content Automation Protocol (SCAP) format and constitutes a catalog of practical hardening advice, linked to government requirements where applicable. The project bridges the gap between generalized policy requirements and specific implementation guidelines. The system administrator can use the oscap command-line tool from the openscap-utils package to verify that the system conforms to provided guidelines. %package doc Summary: HTML formatted documents containing security guides generated from XCCDF benchmarks. Group: System Environment/Base Requires: %{name} = %{version}-%{release} %description doc The %{name}-doc package contains HTML formatted documents containing hardening guidances that have been generated from XCCDF benchmarks present in %{name} package. %prep %setup -q -n %{name}-%{version} %build %make_build %install %make_install %files %{_datadir}/scap %{_datadir}/xml/scap %{_datadir}/%{name}/kickstart %lang(en) %{_mandir}/en/man8/scap-security-guide.8.* %doc %{_docdir}/%{name}/LICENSE %doc %{_docdir}/%{name}/README.md %doc %{_docdir}/%{name}/tables/*.html %doc %{_docdir}/%{name}/tables/*.xhtml %files doc %doc %{_docdir}/%{name}/guides/*.html %changelog * __DATE__ __REL_MANAGER__ <__REL_MANAGER_MAIL__> __VERSION__-__RELEASE__ - Make new __VERSION__ release * Mon Nov 28 2016 Watson Yuuma Sato 0.1.31-1 - Make new 0.1.31 upstream release * Wed Jun 22 2016 Jan iankko Lieskovsky 0.1.30-1 - Make new 0.1.30 upstream release * Fri Apr 22 2016 Jan iankko Lieskovsky 0.1.29-1 - Make new 0.1.29 upstream release * Tue Jan 19 2016 Jan iankko Lieskovsky 0.1.28-1 - Make new 0.1.28 upstream release * Fri Dec 11 2015 Jan iankko Lieskovsky 0.1.27-1 - Make new 0.1.27 upstream release * Mon Oct 19 2015 Jan iankko Lieskovsky 0.1.26-1 - Make new 0.1.26 upstream release * Wed Aug 19 2015 Jan iankko Lieskovsky 0.1.25-1 - Make new 0.1.25 upstream release * Tue Jul 07 2015 Jan iankko Lieskovsky 0.1.24-1 - Make new 0.1.24 release * Mon Jun 22 2015 Jan iankko Lieskovsky 0.1.23-1 - Make new 0.1.23 release * Mon May 04 2015 Jan iankko Lieskovsky 0.1.22-1 - Make new 0.1.22 release * Fri Feb 20 2015 Jan iankko Lieskovsky 0.1.21-1 - Make new 0.1.21 release * Thu Jan 15 2015 Jan iankko Lieskovsky 0.1.20-1 - Make new 0.1.20 release * Sun Sep 28 2014 Jan iankko Lieskovsky 0.1.19-1 - Make new 0.1.19 release * Sun Jun 22 2014 Jan iankko Lieskovsky 0.1.18-1 - Make new 0.1.18 release * Fri May 09 2014 Jan iankko Lieskovsky 0.1.17-1 - Make new 0.1.17 release * Mon May 05 2014 Jan iankko Lieskovsky 0.1.16-1 - Change naming scheme (0.1-16 => 0.1.16-1) * Fri Feb 21 2014 Jan iankko Lieskovsky 0.1-16 - Include datastream files into RHEL6 and RHEL7 RPM packages too - Bump version * Thu Jan 23 2014 Shawn Wells 0.1-16.rc3 + Added to RHEL7 content pool - OVAL for sshd_set_idle_timeout - OVAL for sshd_set_keepalive - OVAL for sshd_disable_rhosts - OVAL for sshd_disable_root_login - OVAL for sshd_disable_empty_passwords - OVAL for sshd_enable_warning_banner - OVAL for sshd_do_not_permit_user_env - OVAL for sshd_use_approved_ciphers - OVAL for sshd_allow_only_protocol2 * Tue Dec 24 2013 Shawn Wells 0.1-16.rc2 + RHEL6 stig-rhel6-server XCCDF profile renamed to stig-rhel6-server-upstream * Mon Dec 23 2013 Shawn Wells 0.1-16.rc1 + Added RHEL7 content to SSG rpm + Added to RHEL7 content pool: - OVAL for partition_for_tmp - OVAL for partition_for_var - OVAL for partition_for_var_log - OVAL for partition_for_var_log_audit - OVAL for selinux_state - OVAL for selinux_policytype - OVAL for ensure_redhat_gpgkey_installed - OVAL for ensure_gpgcheck_never_disabled - OVAL for package_aide_installed - OVAL for accounts_password_reuse_limit - OVAL for no_shelllogin_for_systemaccounts - OVAL for no_empty_passwords - OVAL for no_hashes_outside_shadow - OVAL for accounts_no_uid_except_zero - OVAL for accounts_password_minlen_login_defs - OVAL for accounts_minimum_age_login_defs - OVAL for accounts_password_warn_age_login_defs - OVAL for accounts_password_pam_cracklib_retry - [bugfix] RHEL6 no_empty_passwords remediation script overwrote system-auth symlink. Added --follow-symlink to sed command. * Fri Nov 01 2013 Jan iankko Lieskovsky 0.1-15 - Version bump * Sat Oct 26 2013 Jan iankko Lieskovsky 0.1-15.rc5 - Point the spec's source to proper remote tarball location - Modify the main Makefile to use remote tarball when building RHEL/6's SRPM * Sat Oct 26 2013 Jan iankko Lieskovsky 0.1-15.rc4 - Don't include the table html files two times - Remove makewhatis * Fri Oct 25 2013 Shawn Wells 0.1-15.rc3 - [bugfix] Updated rsyslog_remote_loghost to scan /etc/rsyslog.conf and /etc/rsyslog.d/* - Numberous XCCDF->OVAL naming schema updates - All rules now have CCE * Fri Oct 25 2013 Shawn Wells 0.1-15.rc2 - Updated file permissions of JBossEAP5/eap5-cpe-dictionary.xml (chmod -x) to resolve rpmlint errors - RHEL/6 HTML table naming bugfixes (table-rhel6-*, not table-*-rhel6) * Fri Oct 25 2013 Jan iankko Lieskovsky 0.1-15.rc1 - Apply spec file changes required by review request (RH BZ#1018905) * Thu Oct 24 2013 Shawn Wells 0.1-14 - Formal RPM release - Inclusion of rht-ccp profile - OVAL unit testing patches - Bash remediation patches - Bugfixes * Mon Oct 07 2013 Jan iankko Lieskovsky 0.1-14.rc1 - Change RPM versioning scheme to include release into tarball * Sat Sep 28 2013 Shawn Wells 0.1-13 - Updated RPM spec file to fix rpmlint warnings * Wed Jun 26 2013 Shawn Wells 0.1-12 - Updated RPM version to 0.1-12 * Fri Apr 26 2013 Shawn Wells 0.1-11 - Significant amount of OVAL bugfixes - Incorporation of Draft RHEL/6 STIG feedback * Sat Feb 16 2013 Shawn Wells 0.1-10 - SSG now includes JBoss EAP5 content! - `man scap-security-guide` - OVAL bug fixes - NIST 800-53 mappings update * Wed Nov 28 2012 Shawn Wells 0.1-9 - Updated BuildRequires to reflect python-lxml (thank you, Ray S.!) - Reverting to noarch RPM * Tue Nov 27 2012 Shawn Wells 0.1-8 - Significant copy editing to XCCDF rules per community feedback on the DISA RHEL/6 STIG Initial Draft * Thu Nov 1 2012 Shawn Wells 0.1-7 - Corrected XCCDF content errors - OpenSCAP now supports CPE dictionaries, important to utilize --cpe-dict when scanning machines with OpenSCAP, e.g.: $ oscap xccdf eval --profile stig-server \ --cpe-dict ssg-rhel6-cpe-dictionary.xml ssg-rhel6-xccdf.xml * Mon Oct 22 2012 Shawn Wells 0.1-6 - Corrected RPM versioning, we're on 0.1 release 6 (not version 1 release 6) - Updated RPM includes feedback received from DoD Consensus meetings * Fri Oct 5 2012 Jeffrey Blank 1.0-5 - Adjusted installation directory to /usr/share/xml/scap. * Tue Aug 28 2012 Spencer Shimko 1.0-4 - Fix BuildRequires and Requires. * Tue Jul 3 2012 Jeffrey Blank 1.0-3 - Modified install section, made description more concise. * Thu Apr 19 2012 Spencer Shimko 1.0-2 - Minor updates to pass some variables in from build system. * Mon Apr 02 2012 Shawn Wells 1.0-1 - First attempt at SSG RPM. May ${deity} help us... scap-security-guide-0.1.31/shared/000077500000000000000000000000001301675746700167505ustar00rootroot00000000000000scap-security-guide-0.1.31/shared/images/000077500000000000000000000000001301675746700202155ustar00rootroot00000000000000scap-security-guide-0.1.31/shared/images/collapsed.png000066400000000000000000000013461301675746700226750ustar00rootroot00000000000000‰PNG  IHDR((Œþ¸msRGB®ÎébKGDÿÿÿ ½§“ pHYs……¥T<þtIMEÝ @M7fIDATXÃÝÙKˆNaðßghŒËÈÝ`$EMH¡¹,Ø ’ËB³°2X“R,dk!)5EVŠ)Q¬ÍB åR(I¹Œq¿3ãØ<_D¾o|s¾cž:«ó^þçyÞÿÿý¿ïíx…Ô£FÎâ’xncfbp^®Fw d‚›Ø@ëª ®0³Ü4`9fc"ÞÅ2è©À±c̵ÈÜt,Â|LÂ[<É ÈN7–`8Îã0 ˜ž‡fL‰öO³Îæ8´EF_bÆc%ŽâK¼û„»ñ ²9wÈE ,FÚSDú†NœÅ¨¬ÄîX‡ ¶þ¦Í&ÜÂÇ M‚÷Ø™•Ž6àLd( ’üñ-²ü¬:ÚŒû)†7þ¡ÝhlRuö…Žþ©02€ÖcÎÅäéøY»€‡)ÐÓ²ÐÑz\PÏ°¹„>°'P ®ãæVºÔM芉:0£ ÉZ…Sxý¿¹bN¥÷ê⇂ ¥D!€ö¹ŽÖÅ`E¬-³&::÷bà ±Ýõ6ÊÒÑREµ+\ÎÒ0pß{ðNà9j1,2¸2–S!À¿PrŒÅñøâ.¬À€¬LZGŸ§Ê{¨” c'!%C*Dđ؈K©²'h ßQÈ{‰KhP˜€¢–í+ÖÛ¨¸Ù¨šÌô ¡ÎõV—k³{»µ7¶šûËâƒ-8ý‹\t`_d¬¶_ZþÿîДûcg®î¹¾ú¨EkLžàÖguè)u¯-ú¼×¸’beŸK%F[êò²; +'ÖÈñ0ÿÁ%zk°¶ECüÃò+ˆ÷²çIEND®B`‚scap-security-guide-0.1.31/shared/images/expanded.png000066400000000000000000000022661301675746700225210ustar00rootroot00000000000000‰PNG  IHDR--:âšsRGB®ÎébKGDÿÿÿ ½§“ pHYs……¥T<þtIMEÝ 31þê›î6IDATXÃÕÙO¨TeÇñ÷J7o´ˆ-*™H¨…„ÙBP,¦ED`E+‡‚6!¸h‘1 \ˆáÂ0pð^Ì…šf´b¸iâÂü‹4ºtÓ¦…ϱ×aþœëíaÎyÏó>Ï÷<ç=ïyç â|?QÃß>{ à.ÁMÔã÷V„Óû"¸2Æ?`cìüÿ×ðæ?`àùÁq­o#<…+ ê8„×0ØgØÁÈ{(aɸ®¯éØ”LÁ/ÆÙÎëð¼Èw±8cÚ¼`)ÎÆ›øIÇ°¦ÇÀk"O–s"8²{îlpÞµ™Øšu(ËõB±\Ç…$ÈlÆì.ÃÎŽ¸÷äJ²ßÖà¼Ç–%c{,é´;é8Ž±®KÀë"Þx’cw’{,Ë˲NÓ“5lÇ'x.k,Ëk¡Z)Á£XŽX‰qý>`Ÿˆê¾…!L‹\°6ñË8¶HÆñ-ÎäXš%Öâ̇ðnLö/4œ|;›þ¢ÿPÄ«Eü»–ä?\ãÍ á'ì‰íE Åòb”#PKp07«X›Ç7„ÿ’èåˆÛhYþ=ÁuO°F{9.ÿÜÛ‹šQT+¥ýxDÓ|Qü•¸a>ÂKÑ6ƒ…bye‹Øc}oÇœ­U¥…Ãþ¨Ä¢V×9nŽ©HíÀ§˜msbG|›['U®Ç¡f—­™½ˆ¯ñ4nŠåávµZ)`uÒ4ãöÕ¨rf#…byu‡X70'÷Ž5ú ´è{ #±âîtwH —£i>O€/£Ô 8l8òŽ4n •lX­”®ç/Çt5Ú{kã¸UÎò\Šü-§ Vv‡ñf³'Q ðÑüÃÃG Åò— C¤ÍÄíÈ{T›©¨½gü8NŠå…½ZxT+¥x¿£ˆ}­|:ÄÚ”lží¥eó|­phX[˜Q­”N÷¨Ê§1#ò¬ïäŸúl‰ígzTå,î–È×Ö¦å : ?ãIœèæØŽ±¼0VrÏg3ÖT+ W±-¶»}3fñ¶EÝ‚¾…½Ù#»Z)ÕºTåZòhßyº '#0,îR•³8{#¾nCߌÕßÕ¨Ò©)VùT2ôvFü®C§êL±Ê š©’^@·U7“¨rKUÒ èŽê&§µT%½‚žÀ7¡*&]íÄÿLÄ™ètnus?ª¤—ÐðÎ%j#O•3¿sÑ_¿¡'¥nòª’^COJÝäU%ý€ÎÔÍíê&—*é4슧Ù`¬ØZ­äÃo×Tv:ºÉ­JúÝVÝLV•ôºº™”*é·ÍŠ—2u÷ËÇcÿrè,ýv3‹¡ìeù&ù_÷Ý–â7ÿ½Õ¯ÇþÒn&è2tªnê÷£J”-wç“F=þ—ûØ ÞwçKë{zðñô_CÏœ2jÄEIEND®B`‚scap-security-guide-0.1.31/shared/misc/000077500000000000000000000000001301675746700177035ustar00rootroot00000000000000scap-security-guide-0.1.31/shared/misc/compare_remediations.sh000077500000000000000000000030571301675746700244400ustar00rootroot00000000000000#!/bin/bash if [ "$#" -lt 2 ]; then echo "Usage:" echo -e "\t$0 [meld]" echo "" echo -e "\tBoth repositories have to be already compiled! (make)" echo -e "\tCompare elements from original DS with fixes in updated DSs" echo -e "\t[meld]\tUse meld tool to show differences" exit 1 fi originalRepo="$1/" updatedRepo="$2/" meld="$3" [ "$meld" == "meld" ] && { rpm --quiet -q meld || { echo "Please install \"meld\" package" >&2 } } # Get list of remediations in pretty & sorted xml function extractRemediations() { xsltproc $(dirname "$0")/../transforms/xccdf-get-only-remediations-sorted.xslt "$1" | tee /tmp/res.xml | \ xmllint --c14n11 /dev/stdin | \ xmllint -format /dev/stdin | \ sed 's;^\s*#.*$;;g' | \ sed '/^\s*$/d' # remove bash comments from output # remove empty lines } function compareFile() { local originalFile="$1" toCompare=$(sed "s;^$originalRepo;$updatedRepo;" <<< "$originalFile") echo "-----------------------------------------------------------------" echo "$originalFile <=> $toCompare" echo "-----------------------------------------------------------------" extractRemediations "$originalFile" > /tmp/original extractRemediations "$toCompare" > /tmp/new if [ "$meld" == "meld" ]; then diff /tmp/original /tmp/new -q || { meld /tmp/original /tmp/new } else diff /tmp/original /tmp/new fi } #compareFile ./original/Fedora/output/ssg-fedora-ds.xml #exit find "$originalRepo" -name "*-ds.xml" | grep output | while read originalFile; do compareFile "$originalFile" done scap-security-guide-0.1.31/shared/misc/count_oval_objects.py000077500000000000000000000101241301675746700241400ustar00rootroot00000000000000#!/usr/bin/python2 ''' count_oval_objects.py Shows OVAL objects used by XCCDF rules. Author: Jan Cerny ''' import xml.etree.ElementTree as ET import sys import os.path oval_files = dict() xccdf_dir = None help_text = '''Shows OVAL objects used by XCCDF rules. Usage: ./count_oval_objects.py xccdf_file.xml''' def get_args(): ''' Parses program arguments. ''' if len(sys.argv) == 2: if sys.argv[1] == "--help" or sys.argv[1] == "-h": print(help_text) exit(0) else: return sys.argv[1] else: sys.stderr.write("Bad argument. For more information, try --help.\n") exit(-1) def load_xml(file_name): ''' Loads XML files to memory and parses it into element tree ''' try: it = ET.iterparse(file_name) for _, el in it: el.tag = el.tag.split('}', 1)[1] # strip all namespaces root = it.root return root except: sys.stderr.write("Error while loading file " + file_name + ".\n") exit(-1) def find_oval_objects(oval_refs): ''' Finds OVAL objects according to definitions ID ''' tests = [] object_refs = [] objects = [] # find tests in definitions for def_id, oval_file in oval_refs: if oval_file not in oval_files: oval_file_path = os.path.join(xccdf_dir, oval_file) oval_files[oval_file] = load_xml(oval_file_path) oval_root = oval_files[oval_file] definition = None for d in oval_root.findall(".//definition"): if d.attrib.get('id') == def_id: definition = d break if definition is not None: for criterion in definition.findall(".//criterion"): test_ref = criterion.attrib["test_ref"] tests.append(test_ref) # find references to objects in tests for test in tests: test_element = None for t in oval_root.findall("tests/*"): if t.attrib.get('id') == test: test_element = t break if test_element is not None: for object_element in test_element.findall(".//*"): if 'object_ref' in object_element.attrib: object_ref = object_element.attrib['object_ref'] object_refs.append(object_ref) # find objects for r in object_refs: for obj in oval_root.findall("objects/*"): if obj.attrib.get('id') == r: objects.append(obj.tag) break return set(objects) def print_stats(stats): ''' Print statistic of most used objects in input''' print("") print("Count of used OVAL objects:") print("=" * 50) stats = stats.items() for key, value in reversed(sorted(stats, key=lambda obj: obj[1])): print(key.ljust(40) + str(value).rjust(10)) def main(): stats = {} global xccdf_dir xccdf_file_name = get_args() xccdf_root = load_xml(xccdf_file_name) xccdf_dir = os.path.dirname(xccdf_file_name) for rule in xccdf_root.findall(".//Rule"): rule_id = rule.attrib['id'] oval_refs = [] for ref in rule.findall(".//check-content-ref"): # Skip remotely referenced OVAL checks since they won't have the # 'name' attribute set (just 'href' would be set in that case) try: oval_name = ref.attrib['name'] except KeyError: if 'href' in ref.attrib: print("\nInfo: Skipping remotely referenced OVAL:") continue else: print("\nError: Invalid OVAL check detected! Exiting..") sys.exit(1) oval_file = ref.attrib['href'] oval_refs.append((oval_name, oval_file)) if oval_refs: objects = find_oval_objects(oval_refs) print(rule_id + ": " + ", ".join(objects)) for o in objects: stats[o] = stats.get(o, 0) + 1 else: print(rule_id + ":") print_stats(stats) if __name__ == "__main__": main() scap-security-guide-0.1.31/shared/misc/find_duplicates.py000077500000000000000000000140721301675746700234210ustar00rootroot00000000000000#!/usr/bin/python """ This script should find duplicates e.g. specific template is same as shared one """ import sys import os import re import glob def recursive_globi(mask): """ Simple replacement of glob.globi(mask, recursive=true) Reason: Older Python versions support """ parts = mask.split("**/") if not len(parts) == 2: raise NotImplementedError search_root = parts[0] # instead of '*' use regex '.*' path_mask = parts[1].replace("*", ".*") re_path_mask = re.compile(path_mask + "$") for root, dirnames, filenames in os.walk(search_root): paths = filenames + dirnames for path in paths: full_path = os.path.join(root, path) if re_path_mask.search(full_path): yield full_path class DuplicatesFinder(object): def __init__(self, root_dir, specific_dirs_mask, shared_dir, shared_files_mask): self._root_dir = root_dir self._specific_dirs_mask = os.path.join(root_dir, specific_dirs_mask) self._shared_dir = os.path.join(root_dir, shared_dir) self._clear_normalized() self._shared_files_mask = shared_files_mask def _clear_normalized(self): self._normalized = {} def _get_normalized(self, file_path): """ Return cached normalized content of file :param file_path: :return: """ if file_path in self._normalized: return self._normalized[file_path] with open(file_path, 'r') as content_file: content = content_file.read() normalized = self._normalize_content(content) self._normalized[file_path] = normalized return normalized def _compare_files(self, shared_filename, specific_filename): if not os.path.isfile(specific_filename): return False shared_normalized = self._get_normalized(shared_filename) specific_normalized = self._get_normalized(specific_filename) return shared_normalized == specific_normalized def _print_match(self, first_filename, second_filename): print("Duplicate found! {}\t=>\t{}".format(first_filename, second_filename)) def search(self): """ :return: True if any duplicate found """ found = False self._clear_normalized() specific_dirs = list(self._specific_dirs()) # Walk all shared files shared_files_mask = os.path.join(self._shared_dir, self._shared_files_mask) for shared_filename in glob.glob(shared_files_mask): basename = os.path.basename(shared_filename) # Walk all specific dirs for specific_dir in specific_dirs: # Get file to compare specific_filename = os.path.join(specific_dir, basename) # Compare if self._compare_files(shared_filename, specific_filename): found = True self._print_match(shared_filename, specific_filename) return found def _specific_dirs(self): for static_path in recursive_globi(self._specific_dirs_mask): if not static_path.startswith(self._shared_dir): yield static_path def _normalize_content(self, content): return content class BashDuplicatesFinder(DuplicatesFinder): def __init__(self, root_dir, specific_dirs_mask, shared_dir, shared_files_mask="*.sh"): DuplicatesFinder.__init__(self, root_dir, specific_dirs_mask, shared_dir, shared_files_mask) def _normalize_content(self, content): # remove comments # naive implementation (todo) content = re.sub(r"^\s*#.*", "", content) # remove empty lines content = "\n".join([s for s in content.split("\n") if s]) return content class OvalDuplicatesFinder(DuplicatesFinder): def __init__(self, root_dir, specific_dirs_mask, shared_dir, shared_files_mask="*.xml"): DuplicatesFinder.__init__(self, root_dir, specific_dirs_mask, shared_dir, shared_files_mask) def _normalize_content(self, content): # remove comments # naive implementation (todo) content = re.sub(r"^\s*#.*", "", content) # bash style comments - due to #platform content = re.sub('', "", content, flags=re.DOTALL) # xml comments # remove empty lines content = "\n".join([s for s in content.split("\n") if s]) return content def main(): ''' main function ''' if len(sys.argv) < 2: print("Usage : ./find_duplicates root_ssg_directory") sys.exit(1) root_dir = sys.argv[1] without_duplicates = True # Static bash scripts print("Static bash files:") static_bash_finder = BashDuplicatesFinder( root_dir, os.path.join("**", "static", "bash"), os.path.join("shared", "templates", "static", "bash") ) if static_bash_finder.search(): without_duplicates = False # Templates bash scripts print("Bash templates:") template_bash_finder = BashDuplicatesFinder( root_dir, os.path.join("**", "templates"), os.path.join("shared", "templates"), "template_BASH_*" ) if template_bash_finder.search(): without_duplicates = False # Static oval files print("Static oval files:") static_oval_finder = OvalDuplicatesFinder( root_dir, os.path.join("**", "static", "oval"), os.path.join("shared", "templates", "static", "oval") ) if static_oval_finder.search(): without_duplicates = False # Templates oval files print("Templates oval files:") templates_oval_finder = OvalDuplicatesFinder( root_dir, os.path.join("**", "templates"), os.path.join("shared", "templates"), "template_OVAL_*" ) if templates_oval_finder.search(): without_duplicates = False # Scan results if without_duplicates: print("No duplicates found") sys.exit(0) else: print("Duplicates found!") sys.exit(1) if __name__ == "__main__": main() scap-security-guide-0.1.31/shared/misc/find_orphans.py000077500000000000000000000046651301675746700227450ustar00rootroot00000000000000#!/usr/bin/python2 """ This script lists all oval files made for all platforms (set as multi_platform_all) , and check orphan oval files by parsing the XCCDF content. This allows newly added distributions to support shared oval and multi-platform oval without having a complete XCCDF checklist written, avoiding errors in validate target. This script is only a helper script, and should be used only while the XCCDF files are being written, giving some time to the authors. This is not for indefinite usage. Author: Jean-Baptiste Donnette updated by: Philippe Thierry """ import sys import os from lxml import etree def find_xccdf_files(folder_name, xccdf_list): ''' This fonction find every xccdf file that are in the input/xccdf/ ''' for element in os.listdir(folder_name): if element.endswith('.xml'): find_oval_def(folder_name + '/' + element, xccdf_list) else: find_xccdf_files(folder_name + '/' + element, xccdf_list) def find_oval_def(file_xccdf, xccdf_list): ''' This fonction find every oval definition countainin the file_xccdf and add it into the xccdf_list ''' tree = etree.parse(file_xccdf) for element in tree.iter(): if element.tag == "oval": xccdf_list.append(element.get("id")) def find_build_oval(folder_name, oval_list): ''' This fonction find every oval files that are in the build directory and add it into the xccdf_list ''' for element in os.listdir(folder_name): if element.endswith('.xml'): file_open = open(folder_name + '/' + element) for line in file_open: if "multi_platform_all" in line: oval_list.append(element) file_open.close() def main(): ''' main fonction ''' if len(sys.argv) < 2: print "Usage : ./find_orphans name_of distribution target" sys.exit(1) oval_list = [] xccdf_list = [] build_dir = "build/" + sys.argv[1] + '_oval/' xccdf_directory = "input/xccdf/" find_build_oval(build_dir, oval_list) find_xccdf_files(xccdf_directory, xccdf_list) for element_build in oval_list: find = False for element_xccdf in xccdf_list: if element_build == element_xccdf + ".xml": find = True if not find: print build_dir + element_build if __name__ == "__main__": main() scap-security-guide-0.1.31/shared/misc/generate-contributors.py000077500000000000000000000072061301675746700246120ustar00rootroot00000000000000#!/usr/bin/python import subprocess import re import os.path import codecs import datetime MANUAL_EDIT_WARNING = \ """ This file is generated using the %s script. DO NOT MANUALLY EDIT!!!! Last Modified: %s """ % (os.path.basename(__file__), datetime.datetime.now().strftime("%Y-%m-%d %H:%M")) email_mappings = { # Dave / David Smith "dsmith@secure-innovations.net": "dsmith@eclipse.ncsc.mil", "dsmith@fornax.eclipse.ncsc.mil": "dsmith@eclipse.ncsc.mil", # Frank Caviggia "fcaviggia@users.noreply.github.com": "fcaviggi@ra.iad.redhat.com", # Greg Elin "greg@fotonotes.net": "gregelin@gitmachines.com", # Jean-Baptiste Donnette "donnet_j@epita.fr": "jean-baptiste.donnette@epita.fr", # Martin Preisler "martin@preisler.me": "mpreisle@redhat.com", # Philippe Thierry "phil@internal.reseau-libre.net": "phil@reseau-libre.net", "philippe.thierry@reseau-libre.net": "phil@reseau-libre.net", "philippe.thierry@thalesgroup.com": "phil@reseau-libre.net", # Robin Price II "rprice@users.noreply.github.com": "robin@redhat.com", "rprice@redhat.com": "robin@redhat.com", # Zbynek Moravec "ybznek@users.noreply.github.com": "zmoravec@redhat.com", # Jeff Blank "jeff@t440.local": "blank@eclipse.ncsc.mil", # Shawn Wells "shawn@localhost.localdomain": "shawn@redhat.com", "shawnw@localhost.localdomain": "shawn@redhat.com", # Simon Lukasik "isimluk@fedoraproject.org": "slukasik@redhat.com", # Andrew Gilmore "agilmore@ecahdb2.bor.doi.net": "agilmore2@gmail.com", # No idea / ignore "lyd@chippy.(none)": "", "nick@null.net": "", "root@localhost.localdomain": "", "root@rhel6.(none)": "", } name_mappings = { "Gabe": "Gabe Alford" } def main(): emails = {} output = subprocess.check_output(["git", "shortlog", "-se"]).decode("utf-8") for line in output.split("\n"): match = re.match(r"[\s]*([0-9]+)[\s+](.+)[\s]+\<(.+)\>", line) if match is None: continue commits, name, email = match.groups() if email in email_mappings: email = email_mappings[email] if email == "": continue # ignored if email not in emails: emails[email] = [] emails[email].append((int(commits), name)) contributors = {} # We will use the most used full name for email in emails: _, name = sorted(emails[email], reverse=True)[0] if name in name_mappings: name = name_mappings[name] contributors[name] = email contributors_md = "\n\n" % MANUAL_EDIT_WARNING contributors_md += \ "The following people have contributed to the SCAP Security Guide project\n" contributors_md += "(listed in alphabetical order):\n\n" contributors_xml = "\n\n" % MANUAL_EDIT_WARNING contributors_xml += "\n" for name in sorted(contributors.keys(), key=lambda x: x.split(" ")[-1].upper()): email = contributors[name] contributors_md += "* %s <%s>\n" % (name, email) contributors_xml += "%s <%s>\n" % (name, email) contributors_xml += "\n" root_dir = os.path.dirname(os.path.dirname(os.path.dirname(__file__))) with codecs.open(os.path.join(root_dir, "Contributors.md"), mode="w", encoding="utf-8") as f: f.write(contributors_md) with codecs.open(os.path.join(root_dir, "Contributors.xml"), mode="w", encoding="utf-8") as f: f.write(contributors_xml) print("Don't forget to commit Contributors.md and Contributors.xml!") if __name__ == "__main__": main() scap-security-guide-0.1.31/shared/misc/profile_stats.py000077500000000000000000000365251301675746700231510ustar00rootroot00000000000000#!/usr/bin/python import json import lxml.etree as ET import optparse import sys script_usage = """ %prog -b XCCDF_file [-p XCCDF_profile] [--implemented] [--missing] [--all] [--implemented-ovals] [--implemented-fixes] [--assigned-cces] [--missing-ovals] [--missing-fixes] [--missing-cces] [--json] Obtains and displays XCCDF profile statistics like: * Count of rules present in the * Count of rules having OVAL implemented [% of completion] * Count of rules having remediation implemented [% of completion] for the XCCDF benchmark provided as -b or --benchmark argument. Unless -p or --profile option was provided, it will display statistics for all profiles found in the benchmark. Use -p or --profile XCCDF_profile to obtain statistics solely for particular profile. If --implemented option was provided it will also display the IDs of implemented OVAL checks, remediation scripts, and IDs of rules having CCE identifier already assigned. It is a shortcut for combination of --implemented-ovals, --implemented-fixes, and --assigned-cces options. If --missing option was provided it will also display the IDs of not implemented OVAL checks, remediation scripts, and IDs of rules not having CCE identifier assigned yet. It is a shortcut for combination of --missing-ovals, --missing-fixes, and --missing-cces options. If --all option was provided, it will display all available information. It is a shortcut for combination of --implemented and --missing options. If --json option is provided, it will display the statistics in the form of json format file (rather than default text form) NOTE: Does NOT work on DataStream benchmark format (yet)! """ xccdf_ns = "http://checklists.nist.gov/xccdf/1.1" oval_ns = "http://oval.mitre.org/XMLSchema/oval-definitions-5" rem_system = "urn:xccdf:fix:script:sh" cce_system = "https://nvd.nist.gov/cce/index.cfm" ssg_version_uri = "https://github.com/OpenSCAP/scap-security-guide/releases/latest" console_width = 80 class RuleStats(object): def __init__(self, rid=None, roval=None, rfix=None, rcce=None): self.dict = {'id': rid, 'oval': roval, 'fix': rfix, 'cce': rcce} class XCCDFBenchmark(object): def __init__(self, filepath): self.tree = None try: with open(filepath, 'r') as xccdf_file: file_string = xccdf_file.read() tree = ET.fromstring(file_string) self.tree = tree except IOError as ioerr: print("%s" % ioerr) sys.exit(1) def get_profile_stats(self, profile = None): """Obtain statistics for the profile""" # Holds the intermediary statistics for profile profile_stats = { 'profile_id' : None, 'ssg_version' : 0, 'rules_count' : 0, 'implemented_ovals' : [], 'implemented_ovals_pct' : 0, 'missing_ovals' : [], 'implemented_fixes' : [], 'implemented_fixes_pct' : 0, 'missing_fixes' : [], 'assigned_cces' : [], 'assigned_cces_pct' : 0, 'missing_cces' : [] } rule_stats = [] ssg_version_elem = self.tree.find("./{%s}version[@update=\"%s\"]" % (xccdf_ns, ssg_version_uri)) xccdf_profile = self.tree.find("./{%s}Profile[@id=\"%s\"]" % (xccdf_ns, profile)) if xccdf_profile is None: print("No such profile \"%s\" found in the benchmark!" % profile) print("* Available profiles:") profiles_avail = self.tree.findall("./{%s}Profile" % (xccdf_ns)) for profile in profiles_avail: print("** %s" % profile.get('id')) sys.exit(1) rules = xccdf_profile.findall("./{%s}select[@selected=\"true\"]" % xccdf_ns) for rule in rules: rule_id = rule.get('idref') xccdf_rule = self.tree.find(".//{%s}Rule[@id=\"%s\"]" % (xccdf_ns, rule_id)) if xccdf_rule is not None: oval = xccdf_rule.find("./{%s}check[@system=\"%s\"]" % (xccdf_ns, oval_ns)) fix = xccdf_rule.find("./{%s}fix[@system=\"%s\"]" % (xccdf_ns, rem_system)) cce = xccdf_rule.find("./{%s}ident[@system=\"%s\"]" % (xccdf_ns, cce_system)) rule_stats.append(RuleStats(rule_id, oval, fix, cce)) if not rule_stats: print('Unable to retrieve statistics for %s profile' % profile) sys.exit(1) profile_stats['profile_id'] = profile if ssg_version_elem is not None: profile_stats['ssg_version'] = \ 'SCAP Security Guide %s' % ssg_version_elem.text profile_stats['rules_count'] = len(rule_stats) profile_stats['implemented_ovals'] = \ [x.dict['id'] for x in rule_stats if x.dict['oval'] is not None] profile_stats['implemented_ovals_pct'] = \ float(len(profile_stats['implemented_ovals'])) / \ profile_stats['rules_count'] * 100 profile_stats['missing_ovals'] = \ [x.dict['id'] for x in rule_stats if x.dict['oval'] is None] profile_stats['implemented_fixes'] = \ [x.dict['id'] for x in rule_stats if x.dict['fix'] is not None] profile_stats['implemented_fixes_pct'] = \ float(len(profile_stats['implemented_fixes'])) / \ profile_stats['rules_count'] * 100 profile_stats['missing_fixes'] = \ [x.dict['id'] for x in rule_stats if x.dict['fix'] is None] profile_stats['assigned_cces'] = \ [x.dict['id'] for x in rule_stats if x.dict['cce'] is not None] profile_stats['assigned_cces_pct'] = \ float(len(profile_stats['assigned_cces'])) / \ profile_stats['rules_count'] * 100 profile_stats['missing_cces'] = \ [x.dict['id'] for x in rule_stats if x.dict['cce'] is None] return profile_stats def show_profile_stats(self, profile, options): """Displays statistics for specific profile""" profile_stats = self.get_profile_stats(profile) rules_count = profile_stats['rules_count'] impl_ovals_count = len(profile_stats['implemented_ovals']) impl_fixes_count = len(profile_stats['implemented_fixes']) impl_cces_count = len(profile_stats['assigned_cces']) if not options.json: print("\n* %s statistics of '%s' profile:" % (profile_stats['ssg_version'], profile)) print("** Count of rules: %d" % rules_count) print("** Count of ovals: %d [%d%% complete]" % (impl_ovals_count, \ profile_stats['implemented_ovals_pct'])) print("** Count of fixes: %d [%d%% complete]" % (impl_fixes_count, \ profile_stats['implemented_fixes_pct'])) print("** Count of CCEs: %d [%d%% complete]" % (impl_cces_count, \ profile_stats['assigned_cces_pct'])) if options.implemented_ovals and \ profile_stats['implemented_ovals']: print("*** Rules of '%s' " % profile + "profile having OVAL check: %d of %d [%d%% complete]" % (impl_ovals_count, rules_count, profile_stats['implemented_ovals_pct'])) self.console_print(profile_stats['implemented_ovals'], console_width) if options.implemented_fixes and \ profile_stats['implemented_fixes']: print("*** Rules of '%s' " % profile + "profile having " + "remediation script: %d of %d [%d%% complete]" % (impl_fixes_count, rules_count, profile_stats['implemented_fixes_pct'])) self.console_print(profile_stats['implemented_fixes'], console_width) if options.assigned_cces and \ profile_stats['assigned_cces']: print("*** Rules of '%s' " % profile + "profile having CCE assigned: %d of %d [%d%% complete]" % (impl_cces_count, rules_count, profile_stats['assigned_cces_pct'])) self.console_print(profile_stats['assigned_cces'], console_width) if options.missing_ovals and profile_stats['missing_ovals']: print("*** Rules of '%s' " % profile + "profile missing " + "OVAL: %d of %d [%d%% complete]" % (rules_count - impl_ovals_count, rules_count, profile_stats['implemented_ovals_pct'])) self.console_print(profile_stats['missing_ovals'], console_width) if options.missing_fixes and profile_stats['missing_fixes']: print("*** Rules of '%s' " % profile + "profile missing " + "remediation: %d of %d [%d%% complete]" % (rules_count - impl_fixes_count, rules_count, profile_stats['implemented_fixes_pct'])) self.console_print(profile_stats['missing_fixes'], console_width) if options.missing_cces and profile_stats['missing_cces']: print("***Rules of '%s' " % profile + "profile missing " + "CCE identifier: %d of %d [%d%% complete]" % (rules_count - impl_cces_count, rules_count, profile_stats['assigned_cces_pct'])) self.console_print(profile_stats['missing_cces'], console_width) else: # First delete the not requested information if not options.missing_ovals: del profile_stats['missing_ovals'] if not options.missing_fixes: del profile_stats['missing_fixes'] if not options.missing_cces: del profile_stats['missing_cces'] if not options.implemented_ovals: del profile_stats['implemented_ovals'] del profile_stats['implemented_ovals_pct'] if not options.implemented_fixes: del profile_stats['implemented_fixes'] del profile_stats['implemented_fixes_pct'] if not options.assigned_cces: del profile_stats['assigned_cces'] del profile_stats['assigned_cces_pct'] return profile_stats def console_print(self, content, width): """Prints the 'content' array left aligned, each time 45 characters long, each row 'width' characters wide""" msg = '' for x in content: if len(msg) + len(x) < width - 6: msg += ' ' + "%-45s" % x else: print("%s" % msg) msg = ' ' + "%-45s" % x if msg != '': print("%s" % msg) def parse_options(): parser = optparse.OptionParser(usage=script_usage, version="%prog 1.0") parser.add_option("-p", "--profile", default=False, action="store", dest="profile", help="Show statistics for this XCCDF Profile only.") parser.add_option("-b", "--benchmark", default=False, action="store", dest="benchmark_file", help="Specify XCCDF benchmark to act on.") parser.add_option("--implemented-ovals", default=False, action="store_true", dest="implemented_ovals", help="Show also IDs of implemented OVAL checks.") parser.add_option("--missing-ovals", default=False, action="store_true", dest="missing_ovals", help="Show also IDs of unimplemented OVAL checks.") parser.add_option("--implemented-fixes", default=False, action="store_true", dest="implemented_fixes", help="Show also IDs of implemented remediations.") parser.add_option("--missing-fixes", default=False, action="store_true", dest="missing_fixes", help="Show also IDs of unimplemented remediations.") parser.add_option("--assigned-cces", default=False, action="store_true", dest="assigned_cces", help="Show IDs of rules having CCE assigned.") parser.add_option("--missing-cces", default=False, action="store_true", dest="missing_cces", help="Show IDs of rules missing CCE element.") parser.add_option("--implemented", default=False, action="store_true", dest="implemented", help="Equivalent like --implemented-ovals, \ --implemented_fixes, and --assigned-cves \ would be set.") parser.add_option("--missing", default=False, action="store_true", dest="missing", help="Equivalent like --missing-ovals, --missing-fixes, \ and --missing-cces would be set.") parser.add_option("--all", default=False, action="store_true", dest="all", help="Show all available statistics.") parser.add_option("--json", default=False, action="store_true", dest="json", help="Show the statistics in json file format.") (options, args) = parser.parse_args() if not options.benchmark_file: print("Missing XCCDF location via -b or --benchmark arguments!\n") parser.print_help() sys.exit(1) return (options, args) def propagate_options(options): """Propagate child option values depending on selected parent options being specified""" if options.all: options.implemented = True options.missing = True if options.implemented: options.implemented_ovals = True options.implemented_fixes = True options.assigned_cces = True if options.missing: options.missing_ovals = True options.missing_fixes = True options.missing_cces = True return options def main(): (options, args) = parse_options() options = propagate_options(options) benchmark = XCCDFBenchmark(options.benchmark_file) if options.profile: profile = options.profile ret = benchmark.show_profile_stats(profile, options) if options.json: print(json.dumps(ret, indent=4)) else: all_profile_elems = benchmark.tree.findall("./{%s}Profile" % (xccdf_ns)) ret = [] for elem in all_profile_elems: profile = elem.get('id') if profile is not None: ret.append(benchmark.show_profile_stats(profile, options)) if options.json: print(json.dumps(ret, indent=4)) if __name__ == '__main__': main() scap-security-guide-0.1.31/shared/misc/refresh-stig-refs.sh000077500000000000000000000130571301675746700236070ustar00rootroot00000000000000# For this to work, you need to: # 1) Download the latest STIG, # 2) Extract the xccdf file into the root project folder (i.e. RHEL\5), # 3) Run this script from that same project folder. if [ -e input/auxiliary/stig_overlay.xml ]; then XCCDF_FILE=`find references -name \*xccdf.xml 2>/dev/null` if [ -e "$XCCDF_FILE" ]; then grep ".*//' | sort -u > xccdfchecks.out RULES="$(grep -c ^ xccdfchecks.out)" LINE=1 cat xccdfchecks.out | while read VKEY; do echo "Processing rule ${LINE} of ${RULES}" STIG_ID=$(awk "/" | sed -e "s/.*//" -e "s/<\/version>.*//") CCI=$(awk "/' -f2 | cut -d'<' -f1 | sed ':a;N;$!ba;s/\n/,/g' | sed 's/[cC][cC][iI]-[0]*//g') CCE=$(awk "/' -f2 | cut -d'<' -f1 | sed ':a;N;$!ba;s/\n/,/g' | sed 's/[cC][cC][eE]-//g') SEVERITY=$(awk "//" | grep '' | sed -e "s/.*<title>//" -e "s/<\/title>.*//") RULE_ID=$(grep "<overlay.*ownerid=\"${STIG_ID}\"" input/auxiliary/stig_overlay.xml | sed -e 's/.*ruleid="//' -e 's/".*//') echo "${VKEY}|${STIG_ID}|${CCI}|${CCE}|${SEVERITY}|${SVKEY}|${VRELEASE}|${IACONTROLS}|${TITLE}|${RULE_ID}" sed -i -e "/<overlay.*ownerid=\"${STIG_ID}\"/,/<\/overlay>/s/disa=\"[0-9]*\"/disa=\"$(echo ${CCI} | cut -d"," -f1)\"/" -e "/<overlay.*ownerid=\"${STIG_ID}\"/,/<\/overlay>/s/severity=\"[a-z]*\"/severity=\"${SEVERITY}\"/" -e "/<overlay.*ownerid=\"${STIG_ID}\"/,/<\/overlay>/s/VKey=\"[0-9]*\"/VKey=\"$(echo ${VKEY}|sed 's/[vV]-//')\"/" -e "/<overlay.*ownerid=\"${STIG_ID}\"/,/<\/overlay>/s/SVKey=\"[0-9]*\"/SVKey=\"${SVKEY}\"/" -e "/<overlay.*ownerid=\"${STIG_ID}\"/,/<\/overlay>/s/VRelease=\"[0-9]*\"/VRelease=\"${VRELEASE}\"/" -e "\|<overlay.*ownerid=\"${STIG_ID}\"|,\|</overlay>|s|<title>.*|${TITLE}|" input/auxiliary/stig_overlay.xml if [ "$(grep -R "/dev/null| grep -c ^)" != 0 ]; then grep -R "/dev/null | cut -d: -f1 | uniq | while read FILE; do # SEVERITY if [ ! -z "${SEVERITY}" ]; then sed -i -e "//s/severity=\"[a-z]*\"/severity=\"${SEVERITY}\"/" ${FILE} fi # CCE if [ ! -z "${CCE}" ]; then if [ "$(awk "//" ${FILE} | grep -c "/s/\(<\/Rule>\)/\n\1/" ${FILE} elif [ "$(awk "//" ${FILE} | grep "/s/\(/\1cce=\"${CCE}\" \/>/" ${FILE} else sed -i "//s/\(/" ${FILE} | grep -c "/s/\(<\/Rule>\)/\n\1/" ${FILE} elif [ "$(awk "//" ${FILE} | grep "/s/\(/\1stig=\"${STIG_ID}\" \/>/" ${FILE} else sed -i "//s/\(/" ${FILE} | grep -c "/s/\(<\/Rule>\)/\n\1/" ${FILE} elif [ "$(awk "//" ${FILE} | grep "/s/\(/\1nist=\"${IACONTROLS}\" \/>/" ${FILE} else sed -i "//s/\(/" ${FILE} | grep -c "/s/\(<\/Rule>\)/\n\1/" ${FILE} elif [ "$(awk "//" ${FILE} | grep "/s/\(/\1disa=\"${CCI}\" \/>/" ${FILE} else sed -i "//s/\(/dev/null` if [ -e "$XCCDF_FILE" ]; then grep "" $XCCDF_FILE | sed -e 's/.*//' -e 's/<\/version>.*//' -e 's/ .*//g' | grep -v ^[0-9] | sort -u > xccdfchecks.out cat xccdfchecks.out | while read CHECK; do if [ "`grep -c $CHECK input/auxiliary/stig_overlay.xml`" = "0" ]; then echo "$CHECK" >> stigtochecksnotfound.out fi done fi grep "ruleid" input/auxiliary/stig_overlay.xml | grep -v 'ownerid="SRG' | sed 's/.*> nochecks.out elif [ "$(echo $CHECK_ID | egrep -c '^(met_)')" != "0" ]; then echo "$STIG_ID|$CHECK_ID" >> inherentchecks.out else echo "$STIG_ID|$CHECK_ID" >> checks.out fi if [ -e "$XCCDF_FILE" ]; then if [ "`grep -c ${STIG_ID} xccdfchecks.out`" != "0" ]; then echo "$STIG_ID|$CHECK_ID" >> checkstostigfound.out else echo "$STIG_ID|$CHECK_ID" >> checkstostignotfound.out fi fi done if [ -e checks.out ]; then cat checks.out | cut -d "|" -f2 | sort -u | while read ENTRY; do if [ ! -e "input/checks/${ENTRY}.xml" ] && [ ! -e "${SHARED}/oval/${ENTRY}.xml" ]; then echo "${ENTRY}" >> missingchecks.out else echo "${ENTRY}" >> foundchecks.out fi if [ ! -e "input/fixes/bash/${ENTRY}.sh" ] && [ ! -e "${SHARED}/fixes/bash/${ENTRY}.xml" ]; then echo "${ENTRY}" >> missingfixes.out else echo "${ENTRY}" >> foundfixes.out fi done fi echo -e "\nSTIG INTEGRATION SUMMARY:\n\n" if [ -e "$XCCDF_FILE" ]; then echo -e "TOTAL XCCDF STIG REQUIREMENTS: `grep -c ^ xccdfchecks.out`\n" fi echo -e "TOTAL SSG STIG REQUIREMENTS: `grep "ruleid" input/auxiliary/stig_overlay.xml | grep -v 'ownerid="SRG' | grep -c ^`\n" if [ -e "foundchecks.out" ]; then echo -e "TOTAL SSG STIG CHECKS: `grep -c ^ foundchecks.out`\n" else echo -e "TOTAL SSG STIG CHECKS: 0\n" fi if [ -e "foundfixes.out" ]; then echo -e "TOTAL SSG STIG FIXES: `grep -c ^ foundfixes.out`\n" else echo -e "TOTAL SSG STIG FIXES: 0\n" fi if [ -e checkstostignotfound.out ] && [ ! -z checkstostignotfound.out ]; then echo -e "\nSSG STIG REQUIREMENTS NOT FOUND IN XCCDF STIG: `grep -c ^ checkstostignotfound.out`\n" cat checkstostignotfound.out fi if [ -e stigtochecksnotfound.out ] && [ ! -z stigtochecksnotfound.out ]; then echo -e "\nXCCDF STIG REQUIREMENTS NOT FOUND IN SSG STIG: `grep -c ^ stigtochecksnotfound.out`\n" cat stigtochecksnotfound.out fi rm -f *.out fi scap-security-guide-0.1.31/shared/modules/000077500000000000000000000000001301675746700204205ustar00rootroot00000000000000scap-security-guide-0.1.31/shared/modules/__init__.py000066400000000000000000000000001301675746700225170ustar00rootroot00000000000000scap-security-guide-0.1.31/shared/modules/cce_extract_module.py000066400000000000000000000030061301675746700246220ustar00rootroot00000000000000#!/usr/bin/python2 import sys import lxml.etree as ET # This script requires two arguments: an OVAL file and a CPE dictionary file. # It is designed to extract any inventory definitions and the tests, states, # objects and variables it references and then write them into a standalone # OVAL CPE file, along with a synchronized CPE dictionary file. cpe_ns = "http://cpe.mitre.org/dictionary/2.0" cce_ns = 'http://cce.mitre.org' def parse_xml_file(xmlfile): with open(xmlfile, 'r') as xml_file: filestring = xml_file.read() tree = ET.fromstring(filestring) # print filestring return tree def main(): if len(sys.argv) < 3: print ("Provide a CCE file and the name of the platform " + "whose CCEs to extract.") print "This script extracts those CCEs and writes them to STDOUT." sys.exit(1) ccefile = sys.argv[1] platform = sys.argv[2] # parse cce file ccetree = parse_xml_file(ccefile) # extract cces that match the platform name platform_cces = ccetree.findall(".//{%s}cce[@platform='%s']" % (cce_ns, platform)) cces = ccetree.find("./{%s}cces" % cce_ns) resources = ccetree.find("./{%s}resources" % cce_ns) cces.clear() resources.clear() # could include resources that are referenced, if we wanted to bother [cces.append(platform_cce) for platform_cce in platform_cces] ET.ElementTree(ccetree).write(sys.stdout) sys.exit(0) if __name__ == "__main__": main() scap-security-guide-0.1.31/shared/modules/idtranslate_module.py000077500000000000000000000102651301675746700246600ustar00rootroot00000000000000"""This class is designed to handle the mapping of meaningful, human-readable names to IDs in the formats required by the SCAP checking systems, such as OVAL and OCIL.""" import sys import lxml.etree as ET oval_ns = "http://oval.mitre.org/XMLSchema/oval-definitions-5" oval_cs = "http://oval.mitre.org/XMLSchema/oval-definitions-5" ocil_ns = "http://scap.nist.gov/schema/ocil/2.0" ocil_cs = "http://scap.nist.gov/schema/ocil/2" ovaltag_to_abbrev = { 'definition': 'def', 'criteria': 'crit', 'test': 'tst', 'object': 'obj', 'state': 'ste', 'variable': 'var', } ociltag_to_abbrev = { 'questionnaire': 'questionnaire', 'action': 'testaction', 'question': 'question', 'artifact': 'artifact', 'variable': 'variable', } ovalrefattr_to_tag = { "definition_ref": "definition", "test_ref": "test", "object_ref": "object", "state_ref": "state", "var_ref": "variable", } ocilrefattr_to_tag = { "question_ref": "question", } ocilrefchild_to_tag = { "test_action_ref": "action", } def split_namespace(tag): """returns a tuple of (namespace,name) removing any fragment id from namespace""" if tag[:1] == "{": namespace, name = tag[1:].split("}", 1) return namespace.split("#")[0], name else: return (None, tag) def namespace_to_prefix(tag): namespace, name = split_namespace(tag) if namespace == ocil_ns: return "ocil" if namespace == oval_ns: return "oval" sys.exit("Error: unknown checksystem referenced in tag : %s" % tag) def tagname_to_abbrev(tag): namespace, tag = split_namespace(tag) if tag == "extend_definition": return tag # grab the last part of the tag name to determine its type tag = tag.rsplit("_", 1)[-1] if namespace == ocil_ns: return ociltag_to_abbrev[tag] if namespace == oval_ns: return ovaltag_to_abbrev[tag] sys.exit("Error: unknown checksystem referenced in tag : %s" % tag) class idtranslator(object): def __init__(self, content_id): self.content_id = content_id def generate_id(self, tagname, name): str_id = "%s:%s-%s:%s:%d" % ( namespace_to_prefix(tagname), self.content_id, name, tagname_to_abbrev(tagname), 1 ) return str_id def translate(self, tree, store_defname=False): for element in tree.getiterator(): idname = element.get("id") if idname: # store the old name if requested (for OVAL definitions) if store_defname and element.tag == "{" + oval_ns + "}definition": metadata = element.find("{" + oval_ns + "}metadata") if metadata is None: metadata = ET.SubElement(element, "metadata") defnam = ET.SubElement(metadata, "reference", ref_id=idname, source=self.content_id) # set the element to the new identifier element.set("id", self.generate_id(element.tag, idname)) # continue if element.tag == "{" + oval_ns + "}filter": element.text = self.generate_id("{" + oval_ns + "}state", element.text) continue if element.tag == "{" + oval_ns + "#independent}var_ref": element.text = self.generate_id("{" + oval_ns + "}variable", element.text) continue for attr in element.keys(): if attr in ovalrefattr_to_tag.keys(): element.set(attr, self.generate_id("{" + oval_ns + "}" + ovalrefattr_to_tag[attr], element.get(attr))) if attr in ocilrefattr_to_tag.keys(): element.set(attr, self.generate_id("{" + ocil_ns + "}" + ocilrefattr_to_tag[attr], element.get(attr))) if element.tag == "{" + ocil_ns + "}test_action_ref": element.text = self.generate_id("{" + ocil_ns + "}action", element.text) return tree scap-security-guide-0.1.31/shared/modules/map_product_module.py000066400000000000000000000041661301675746700246630ustar00rootroot00000000000000import re # SSG Makefile to official product name mapping CHROMIUM = 'Google Chromium Browser' FEDORA = 'Fedora' FIREFOX = 'Mozilla Firefox' JRE = 'Java Runtime Environment' RHEL = 'Red Hat Enterprise Linux' WEBMIN = 'Webmin' DEBIAN = 'Debian' UBUNTU = 'Ubuntu' RHEVM = 'Red Hat Enterprise Virtualization Manager' EAP = 'JBoss EAP' FUSE = 'JBoss Fuse' OPENSUSE = 'OpenSUSE' SUSE = 'SUSE Linux Enterprise' WRLINUX = 'Wind River Linux' multi_product_list = ['rhel', 'fedora', 'rhel-osp', 'debian', 'ubuntu', 'wrlinux', 'sle'] def parse_product_name(product): product_version = None r = re.compile("([a-zA-Z\-]+)([0-9]+)") match = r.match(product) if match is not None: if isinstance(match.group(1), str) or isinstance(match.group(1), unicode): product = match.group(1) if match.group(2).isdigit(): product_version = match.group(2) return product, product_version def map_product(version): """Maps SSG Makefile internal product name to official product name""" product_name = None if re.findall('chromium', version): product_name = CHROMIUM if re.findall('fedora', version): product_name = FEDORA if re.findall('firefox', version): product_name = FIREFOX if re.findall('jre', version): product_name = JRE if re.findall('rhel', version): product_name = RHEL if re.findall('webmin', version): product_name = WEBMIN if re.findall('debian', version): product_name = DEBIAN if re.findall('ubuntu', version): product_name = UBUNTU if re.findall('rhevm', version): product_name = RHEVM if re.findall('eap', version): product_name = EAP if re.findall('fuse', version): product_name = FUSE if re.findall('opensuse', version): product_name = OPENSUSE if re.findall('sle', version): product_name = SUSE if re.findall('wrlinux', version): product_name = WRLINUX if product_name is None: raise RuntimeError("Can't map version '%s' to any known product!" % (version)) return product_name scap-security-guide-0.1.31/shared/modules/splitchecks_module.py000066400000000000000000000072361301675746700246630ustar00rootroot00000000000000#!/usr/bin/python2 import sys import os import errno import string import re from optparse import OptionParser import lxml.etree as ET xmlns = { "o": "http://oval.mitre.org/XMLSchema/oval-definitions-5", "xsi": "http://www.w3.org/2001/XMLSchema-instance", "oval": "http://oval.mitre.org/XMLSchema/oval-common-5", "unix": "http://oval.mitre.org/XMLSchema/oval-definitions-5#unix", "linux": "http://oval.mitre.org/XMLSchema/oval-definitions-5#linux", "ind": "http://oval.mitre.org/XMLSchema/oval-definitions-5#independent", } def parse_options(): usage = "usage: %prog [options] input_file [input_file . . .]" parser = OptionParser(usage=usage, version="%prog ") parser.add_option("-o", dest="out_dname", default="/tmp/checks", help="name of output directory. If unspecified, default is a new directory \"/tmp/checks\"") (options, args) = parser.parse_args() if len(args) < 1: parser.print_help() sys.exit(1) return (options, args) # look for any occurrences of these attributes, and then gather the node # referenced def gather_refs(element, defn): items_with_refs = element.findall(".//*[@test_ref]") items_with_refs.extend(element.findall(".//*[@var_ref]")) items_with_refs.extend(element.findall(".//*[@state_ref]")) items_with_refs.extend(element.findall(".//*[@object_ref]")) for item in items_with_refs: for attr in item.attrib.keys(): if attr.endswith("_ref"): ident = item.get(attr) referenced_item = id_element_map[ident] if referenced_item not in def_reflist_map[defn]: def_reflist_map[defn].append(referenced_item) gather_refs(referenced_item, defn) def gather_refs_for_defs(tree): defn_elements = tree.getiterator("{" + xmlns["o"] + "}definition") # initialize dictionary, which maps definitions to a list of those things # it references for defn in defn_elements: def_reflist_map[defn] = [] for defn in defn_elements: gather_refs(defn, defn) def output_checks(dname): try: os.makedirs(dname) except OSError, e: if e.errno != errno.EEXIST: raise # use namespace prefix-to-uri defined above, to provide abbreviations for prefix, uri in xmlns.iteritems(): ET.register_namespace(prefix, uri) os.chdir(dname) for defn, reflist in def_reflist_map.iteritems(): # create filename from id attribute, get rid of punctuation fname = defn.get("id") fname = fname.translate(string.maketrans("", ""), string.punctuation) + ".xml" # output definition, and then all elements that the definition # references outstring = ET.tostring(defn) for ref in reflist: outstring = outstring + ET.tostring(ref) with open(fname, 'w+') as xml_file: # giant kludge: get rid of per-node namespace attributes outstring = re.sub(r"\s+xmlns[^\s]+ ", " ", outstring) xml_file.write("\n" + outstring + "") return def gather_ids_for_elements(tree): for element in tree.findall(".//*[@id]"): id_element_map[element.get("id")] = element id_element_map = {} # map of ids to elements def_reflist_map = {} # map of definitions to lists of elements it references def main(): (options, args) = parse_options() for fname in args: tree = ET.parse(fname) # ET.dump(tree) gather_ids_for_elements(tree) gather_refs_for_defs(tree) output_checks(options.out_dname) sys.exit(0) if __name__ == "__main__": main() scap-security-guide-0.1.31/shared/modules/sync_alt_titles_module.py000066400000000000000000000064021301675746700255410ustar00rootroot00000000000000#!/usr/bin/python2 import sys import optparse import lxml.etree as ET # # This script is designed to synchronize an alternative-titles file, # which allows for specifying (and later inserting) titles of an alternate # format into the main body of XCCDF content. # # It requires three arguments: an XCCDF file with Rules (which already have # titles), a profile name (that specifies the Rules for which to populate the # alternative-titles file), and the name of the alternative-titles file. # xccdf_ns = "http://checklists.nist.gov/xccdf/1.1" oval_ns = "http://oval.mitre.org/XMLSchema/oval-definitions-5" def parse_options(): usage = "usage: %prog -p profile -f titlesfile xccdf_file" parser = optparse.OptionParser(usage=usage, version="%prog ") # only some options are on by default parser.add_option("-p", "--profile", default=False, action="store", dest="profile_name", help="provide title-holders for Rules in this XCCDF Profile") parser.add_option("-f", "--titles-file", default=False, action="store", dest="titlesfile", help="an alternate titles file, in which to populate title-holders") parser.add_option("-r", "--read-only", default=False, action="store_true", dest="readonly", help="print changes that would be made, but do not make them") (options, args) = parser.parse_args() if len(args) < 1 or not options.profile_name or not options.titlesfile: parser.print_help() sys.exit(1) return (options, args) def get_profileruleids(xccdftree, profile_name): ruleids = [] while profile_name: profile = xccdftree.find(".//{%s}Profile[@id='%s']" % (xccdf_ns, profile_name)) if profile is None: sys.exit("Specified XCCDF Profile %s was not found.") for select in profile.findall(".//{%s}select" % xccdf_ns): ruleids.append(select.get("idref")) profile_name = profile.get("extends") return ruleids def main(): (options, args) = parse_options() xccdffilename = args[0] # extract all of the rules within the xccdf xccdftree = ET.parse(xccdffilename) rules = xccdftree.findall(".//{%s}Rule" % xccdf_ns) profile_ruleids = get_profileruleids(xccdftree, options.profile_name) prunedrules = rules[:] for rule in rules: if rule.get("id") not in profile_ruleids: prunedrules.remove(rule) rules = prunedrules titlestree = ET.parse(options.titlesfile) alttitles = titlestree.findall(".//{%s}title" % xccdf_ns) alttitles_rulerefs = [alttitle.get("rule") for alttitle in alttitles] for rule in rules: ruleid = rule.get("id") if ruleid not in alttitles_ruleref: titleholder = ET.SubElement(titlestree.getroot(), "title") titleholder.text = "\n" else: titleholder = titlestree.find("./{"+xccdf_ns+"}title[@rule='"+ruleid+"']") titleholder.attrib['rule'] = rule.get("id") shorttitle = rule.find("./{%s}title" % xccdf_ns) titleholder.attrib['shorttitle'] = shorttitle.text titlestree.write(options.titlesfile, pretty_print=True) sys.exit(0) if __name__ == "__main__": main() scap-security-guide-0.1.31/shared/modules/testoval_module.py000066400000000000000000000222411301675746700242010ustar00rootroot00000000000000import sys import os import re import tempfile import subprocess import datetime import lxml.etree as ET from ConfigParser import SafeConfigParser import idtranslate_module as idtranslate SHARED_OVAL = re.sub('shared.*', 'shared', __file__) + '/oval/' timestamp = datetime.datetime.utcnow().strftime("%Y-%m-%dT%H:%M:%S") conf_file = re.sub('shared.*', '', __file__) + '/config/oval.config' footer = '' ovalns = "{http://oval.mitre.org/XMLSchema/oval-definitions-5}" # globals, to make recursion easier in case we encounter extend_definition definitions = ET.Element("definitions") tests = ET.Element("tests") objects = ET.Element("objects") states = ET.Element("states") variables = ET.Element("variables") def _header(schema_version): header = ''' testoval.py 0.0.1 %s %s ''' % (schema_version, timestamp) return header def parse_conf_file(conf_file): parser = SafeConfigParser() parser.read(conf_file) oval_version = None for section in parser.sections(): for name, setting in parser.items(section): setting = re.sub('.;:', ',', re.sub(' ', '', setting)) if not oval_version and name == 'oval_version': oval_version = setting if oval_version is None: print 'ERROR! The setting returned a value of \'%s\'!' % oval_version sys.exit(1) return oval_version # append new child ONLY if it's not a duplicate def append(element, newchild): newid = newchild.get("id") existing = element.find(".//*[@id='" + newid + "']") if existing is not None: if not silent_mode: sys.stderr.write("Notification: this ID is used more than once " + "and should represent equivalent elements: " + newid + "\n") else: element.append(newchild) def add_oval_elements(body, header): """Add oval elements to the global Elements defined above""" tree = ET.fromstring(header + body + footer) tree = replace_external_vars(tree) # parse new file(string) as an etree, so we can arrange elements # appropriately for childnode in tree.findall("./" + ovalns + "def-group/*"): # print "childnode.tag is " + childnode.tag if childnode.tag is ET.Comment: continue if childnode.tag == (ovalns + "definition"): append(definitions, childnode) defname = childnode.get("id") # extend_definition is a special case: must include a whole other # definition for defchild in childnode.findall(".//" + ovalns + "extend_definition"): defid = defchild.get("definition_ref") extend_ref = find_testfile(defid+".xml") includedbody = read_ovaldefgroup_file(extend_ref) # recursively add the elements in the other file add_oval_elements(includedbody, header) if childnode.tag.endswith("_test"): append(tests, childnode) if childnode.tag.endswith("_object"): append(objects, childnode) if childnode.tag.endswith("_state"): append(states, childnode) if childnode.tag.endswith("_variable"): append(variables, childnode) return defname def replace_external_vars(tree): """Replace external_variables with local_variables, so the definition can be tested independently of an XCCDF file""" # external_variable is a special case: we turn it into a local_variable so # we can test for node in tree.findall(".//"+ovalns+"external_variable"): print ("External_variable with id : " + node.get("id")) extvar_id = node.get("id") # for envkey, envval in os.environ.iteritems(): # print envkey + " = " + envval # sys.exit() if extvar_id not in os.environ.keys(): print ("External_variable specified, but no value provided via " + "environment variable") sys.exit(2) # replace tag name: external -> local node.tag = ovalns + "local_variable" literal = ET.Element("literal_component") literal.text = os.environ[extvar_id] node.append(literal) # TODO: assignment of external_variable via environment vars, for # testing return tree def find_testfile(testfile): """Find OVAL files in CWD or shared/oval""" for path in ['.', SHARED_OVAL]: for root, folder, files in os.walk(path): searchfile = root + '/' + testfile if not os.path.isfile(searchfile): searchfile = "" else: testfile = searchfile.strip() # Most likely found file, exit this loop break if not os.path.isfile(testfile): print ("ERROR: %s does not exist! Please specify a valid OVAL file.") % testfile sys.exit(1) return testfile def read_ovaldefgroup_file(testfile): """Read oval files""" with open(testfile, 'r') as test_file: body = test_file.read() return body def usage(): """Display script usage and exit""" print ("Usage: " + sys.argv[0] + " [-q | --quiet | --silent] definition_file.xml") sys.exit(2) def main(): global definitions global tests global objects global states global variables global silent_mode silent_mode = False silent_mode_options = ['-q', '--quiet', '--silent'] if len(sys.argv) < 2 or len(sys.argv) > 3: print ("Provide the name of an XML file, which contains" + " the definition to test.") usage() if len(sys.argv) == 3 and sys.argv[1] in silent_mode_options: if sys.argv[2].rfind('.xml') != -1: silent_mode = True sys.argv.pop(1) else: usage() if len(sys.argv) != 2 or sys.argv[1].rfind('.xml') == -1: usage() if not len(sys.argv) == 4: try: from openscap import oscap_get_version if oscap_get_version() < 1.2: schema = 5.10 else: schema = 5.11 except ImportError: schema = parse_conf_file(conf_file) else: # FUTURE: replace with sys arg schema = '5.10' testfile = sys.argv[1] header = _header(schema) testfile = find_testfile(testfile) body = read_ovaldefgroup_file(testfile) defname = add_oval_elements(body, header) ovaltree = ET.fromstring(header + footer) # append each major element type, if it has subelements for element in [definitions, tests, objects, states, variables]: if element.getchildren(): ovaltree.append(element) # re-map all the element ids from meaningful names to meaningless # numbers testtranslator = idtranslate.idtranslator("scap-security-guide.testing") ovaltree = testtranslator.translate(ovaltree) (ovalfile, fname) = tempfile.mkstemp(prefix=defname, suffix=".xml") os.write(ovalfile, ET.tostring(ovaltree)) os.close(ovalfile) if not silent_mode: print ("Evaluating with OVAL tempfile : " + fname) print ("Writing results to : " + fname + "-results") cmd = "oscap oval eval --results " + fname + "-results " + fname oscap_child = subprocess.Popen(cmd, stdout=subprocess.PIPE, shell=True) cmd_out = oscap_child.communicate()[0] if not silent_mode: print cmd_out if oscap_child.returncode != 0: if not silent_mode: print ("Error launching 'oscap' command: \n\t" + cmd) sys.exit(2) if 'false' in cmd_out: # at least one from the evaluated OVAL definitions evaluated to # 'false' result, exit with '1' to indicate OVAL scan FAIL result sys.exit(1) # perhaps delete tempfile? definitions = ET.Element("definitions") tests = ET.Element("tests") objects = ET.Element("objects") states = ET.Element("states") variables = ET.Element("variables") # 'false' keyword wasn't found in oscap's command output # exit with '0' to indicate OVAL scan TRUE result sys.exit(0) scap-security-guide-0.1.31/shared/modules/verify_cce_module.py000066400000000000000000000033771301675746700244670ustar00rootroot00000000000000#!/usr/bin/python2 import sys import platform from lxml import etree # This script checks the validity of assigned CCEs, lists granted and remaining # available CCEs, and checks for duplicates. release = '%.0f' % float(platform.linux_distribution()[1]) xccdf_ns = "http://checklists.nist.gov/xccdf/1.1" tree = etree.parse('../output/unlinked-rhel' + str(release) + '-xccdf.xml') cces_assigned = tree.findall("//{%s}ident[@system='http://cce.mitre.org']" % xccdf_ns) assigned_ids = [] granted_ids = [] # print the list of assigned CCEs print "Assigned CCEs:" for item in cces_assigned: print item.text assigned_ids.append(item.text) print "-------------" # check for duplicates in the assigned CCE list dup_assigned_ids = [item for item in cces_assigned if cces_assigned.count(item) > 1] for item in dup_assigned_ids: print "Duplicate assignment of CCE: %s" % item # open the available CCE file with open('../references/cce-rhel' + int(release) + '-avail.txt', 'r') as txt_file: for line in txt_file: granted_ids = [line.rstrip('\n') for line in txt_file] # print CCEs that are available (i.e. in granted but not assigned) for item in granted_ids: if item not in assigned_ids: print "Available CCE: %s" % item for rule in tree.findall("//{%s}Rule" % xccdf_ns): # print "rule is " + rule.get("id") items = rule.findall("{%s}ident[@system='http://cce.mitre.org']" % xccdf_ns) if len(items) > 1: print "Rule with multiple CCEs assigned: %s" % rule.get("id") if len(items) == 0: print "Rule without CCE: %s" % rule.get("id") for item in items: if item.text not in granted_ids: print "Invalid CCE: %s in %s" % (item.text, rule.get("id")) sys.exit() scap-security-guide-0.1.31/shared/modules/xccdf2csv_stig_module.py000066400000000000000000000035341301675746700252570ustar00rootroot00000000000000#!/usr/bin/python2 import sys import csv import lxml.etree as ET # This script creates a CSV file from an XCCDF file formatted in the # structure of a STIG. This should enable its ingestion into VMS, # as well as its comparison with VMS output. xccdf_ns = "http://checklists.nist.gov/xccdf/1.1" disa_cciuri = "http://iase.disa.mil/stigs/cci/Pages/index.aspx" disa_srguri = "http://iase.disa.mil/stigs/srgs/Pages/index.aspx" def parse_xml_file(xmlfile): with open(xmlfile, 'r') as xml_file: filestring = xml_file.read() tree = ET.fromstring(filestring) return tree def reflist(refs): refstring = ', '.join(refs) return refstring def node_to_text(node): textslist = node.xpath(".//text()") return ''.join(textslist) def main(): if len(sys.argv) < 2: print "Provide an XCCDF file to convert into a CSV file." sys.exit(1) xccdffile = sys.argv[1] xccdftree = parse_xml_file(xccdffile) rules = xccdftree.findall(".//{%s}Rule" % xccdf_ns) rulewriter = csv.writer(sys.stdout, quoting=csv.QUOTE_ALL) for rule in rules: cci_refs = [ref.text for ref in rule.findall("{%s}ident[@system='%s']" % (xccdf_ns, disa_cciuri))] srg_refs = [ref.text for ref in rule.findall("{%s}ident[@system='%s']" % (xccdf_ns, disa_srguri))] title = rule.find("{%s}title" % xccdf_ns).text description = node_to_text(rule.find("{%s}description" % xccdf_ns)) fixtext = node_to_text(rule.find("{%s}fixtext" % xccdf_ns)) checktext = node_to_text(rule.find(".//{%s}check-content" % xccdf_ns)) row = [reflist(cci_refs), reflist(srg_refs), title, description, fixtext, checktext] rulewriter.writerow(row) sys.exit(0) if __name__ == "__main__": main() scap-security-guide-0.1.31/shared/oval/000077500000000000000000000000001301675746700177115ustar00rootroot00000000000000scap-security-guide-0.1.31/shared/oval/account_disable_post_pw_expiration.xml000066400000000000000000000036571301675746700276020ustar00rootroot00000000000000 Set Accounts to Expire Following Password Expiration multi_platform_rhel The accounts should be configured to expire automatically following password expiration. /etc/default/useradd ^\s*INACTIVE\s*=\s*(\d+)\s*$ 1 -1 scap-security-guide-0.1.31/shared/oval/account_unique_name.xml000066400000000000000000000062051301675746700244600ustar00rootroot00000000000000 Set All Accounts To Have Unique Names multi_platform_all All accounts on the system should have unique names for proper accountability. /etc/passwd ^([^:]+):.*$ 1 variable_count_of_all_usernames_from_etc_passwd scap-security-guide-0.1.31/shared/oval/accounts_max_concurrent_login_sessions.xml000066400000000000000000000070311301675746700305000ustar00rootroot00000000000000 Set Maximum Number of Concurrent Login Sessions Per User multi_platform_rhel multi_platform_wrlinux The maximum number of concurrent login sessions per user should meet minimum requirements. /etc/security/limits.conf ^[\s]*\*[\s]+(?:(?:hard)|(?:-))[\s]+maxlogins[\s]+(\d+)\s*$ 1 /etc/security/limits.d ^.*\.conf$ ^[\s]*\*[\s]+(?:(?:hard)|(?:-))[\s]+maxlogins[\s]+(\d+)\s*$ 1 /etc/security/limits.d ^.*\.conf$ ^[\s]*\*[\s]+(?:(?:hard)|(?:-))[\s]+maxlogins 1 scap-security-guide-0.1.31/shared/oval/accounts_maximum_age_login_defs.xml000066400000000000000000000053601301675746700270200ustar00rootroot00000000000000 Set Password Expiration Parameters multi_platform_all The maximum password age policy should meet minimum requirements. /etc/login.defs .*\n[^#]*(PASS_MAX_DAYS\s+\d+)\s*\n 1 variable_last_pass_max_days_instance_value scap-security-guide-0.1.31/shared/oval/accounts_minimum_age_login_defs.xml000066400000000000000000000053741301675746700270230ustar00rootroot00000000000000 Set Password Expiration Parameters multi_platform_all The minimum password age policy should be set appropriately. /etc/login.defs .*\n[^#]*(PASS_MIN_DAYS\s+\d+)\s*\n 1 variable_last_pass_min_days_instance_value scap-security-guide-0.1.31/shared/oval/accounts_no_uid_except_zero.xml000066400000000000000000000022301301675746700262130ustar00rootroot00000000000000 UID 0 Belongs Only To Root multi_platform_all Only the root account should be assigned a user id of 0. /etc/passwd ^(?!root:)[^:]*:[^:]*:0 1 scap-security-guide-0.1.31/shared/oval/accounts_password_all_shadowed.xml000066400000000000000000000021271301675746700267040ustar00rootroot00000000000000 All Password Hashes Shadowed multi_platform_all All password hashes should be shadowed. .* x scap-security-guide-0.1.31/shared/oval/accounts_password_minlen_login_defs.xml000066400000000000000000000052531301675746700277340ustar00rootroot00000000000000 Set Password Expiration Parameters multi_platform_all The password minimum length should be set appropriately. /etc/login.defs .*\n[^#]*(PASS_MIN_LEN\s+\d+)\s*\n 1 variable_last_pass_min_len_instance_value scap-security-guide-0.1.31/shared/oval/accounts_password_pam_dcredit.xml000066400000000000000000000035101301675746700265260ustar00rootroot00000000000000 Set Password dcredit Requirements Red Hat Enterprise Linux 7 multi_platform_fedora The password dcredit should meet minimum requirements /etc/security/pwquality.conf ^dcredit[\s]*=[\s]*(-?\d+)(?:[\s]|$) 1 1 scap-security-guide-0.1.31/shared/oval/accounts_password_pam_difok.xml000066400000000000000000000034601301675746700262100ustar00rootroot00000000000000 Set Password difok Requirements Red Hat Enterprise Linux 7 multi_platform_fedora The password difok should meet minimum requirements /etc/security/pwquality.conf ^difok[\s]*=[\s]*(\d+)(?:[\s]|$) 1 1 scap-security-guide-0.1.31/shared/oval/accounts_password_pam_lcredit.xml000066400000000000000000000035101301675746700265360ustar00rootroot00000000000000 Set Password lcredit Requirements Red Hat Enterprise Linux 7 multi_platform_fedora The password lcredit should meet minimum requirements /etc/security/pwquality.conf ^lcredit[\s]*=[\s]*(-?\d+)(?:[\s]|$) 1 1 scap-security-guide-0.1.31/shared/oval/accounts_password_pam_maxclassrepeat.xml000066400000000000000000000036211301675746700301270ustar00rootroot00000000000000 Set Password maxclassrepeat Requirements Red Hat Enterprise Linux 7 multi_platform_fedora The password maxclassrepeat should meet minimum requirements using pam_pwquality /etc/security/pwquality.conf ^maxclassrepeat[\s]*=[\s]*(-?\d+)(?:[\s]|$) 1 scap-security-guide-0.1.31/shared/oval/accounts_password_pam_maxrepeat.xml000066400000000000000000000035131301675746700271010ustar00rootroot00000000000000 Set Password maxrepeat Requirements Red Hat Enterprise Linux 7 multi_platform_fedora The password maxrepeat should meet minimum requirements using pam_pwquality /etc/security/pwquality.conf ^maxrepeat[\s]*=[\s]*(-?\d+)(?:[\s]|$) 1 scap-security-guide-0.1.31/shared/oval/accounts_password_pam_minclass.xml000066400000000000000000000035471301675746700267330ustar00rootroot00000000000000 Set Password minclass Requirements Red Hat Enterprise Linux 7 multi_platform_fedora The password minclass should meet the minimum requirements /etc/security/pwquality.conf ^minclass[\s]*=[\s]*(-?\d+)(?:[\s]|$) 1 1 scap-security-guide-0.1.31/shared/oval/accounts_password_pam_minlen.xml000066400000000000000000000035001301675746700263710ustar00rootroot00000000000000 Set Password minlen Requirements Red Hat Enterprise Linux 7 multi_platform_fedora The password minlen should meet minimum requirements /etc/security/pwquality.conf ^minlen[\s]*=[\s]*(-?\d+)(?:[\s]|$) 1 1 scap-security-guide-0.1.31/shared/oval/accounts_password_pam_ocredit.xml000066400000000000000000000035101301675746700265410ustar00rootroot00000000000000 Set Password ocredit Requirements Red Hat Enterprise Linux 7 multi_platform_fedora The password ocredit should meet minimum requirements /etc/security/pwquality.conf ^ocredit[\s]*=[\s]*(-?\d+)(?:[\s]|$) 1 1 scap-security-guide-0.1.31/shared/oval/accounts_password_pam_pwquality.xml000066400000000000000000000022521301675746700271510ustar00rootroot00000000000000 Check pam_pwquality Existence in system-auth Red Hat Enterprise Linux 7 multi_platform_fedora Check that pam_pwquality.so exists in system-auth /etc/pam.d/system-auth ^\s*password\s+(?:(?:required)|(?:requisite))\s+pam_pwquality\.so.*$ 1 scap-security-guide-0.1.31/shared/oval/accounts_password_pam_retry.xml000066400000000000000000000063761301675746700262720ustar00rootroot00000000000000 Set Password retry Requirements multi_platform_fedora multi_platform_rhel multi_platform_rhel-osp The password retry should meet minimum requirements /etc/pam.d/system-auth ^\s*password\s+(?:(?:required)|(?:requisite))\s+pam_cracklib\.so.*retry=([0-9]*).*$ 1 /etc/pam.d/system-auth ^\s*password\s+(?:(?:required)|(?:requisite))\s+pam_pwquality\.so.*retry=([0-9]*).*$ 1 scap-security-guide-0.1.31/shared/oval/accounts_password_pam_ucredit.xml000066400000000000000000000035101301675746700265470ustar00rootroot00000000000000 Set Password ucredit Requirements Red Hat Enterprise Linux 7 multi_platform_fedora The password ucredit should meet minimum requirements /etc/security/pwquality.conf ^ucredit[s\]*=[\s]*(-?\d+)(?:[\s]|$) 1 1 scap-security-guide-0.1.31/shared/oval/accounts_password_pam_unix_remember.xml000066400000000000000000000056361301675746700277640ustar00rootroot00000000000000 Limit Password Reuse multi_platform_rhel multi_platform_fedora The passwords to remember should be set correctly. /etc/pam.d/system-auth ^\s*password\s+(?:(?:sufficient)|(?:required))\s+pam_unix\.so.*remember=([0-9]*).*$ 1 /etc/pam.d/system-auth ^\s*password\s+(?:(?:requisite)|(?:required))\s+pam_pwhistory\.so.*remember=([0-9]*).*$ 1 scap-security-guide-0.1.31/shared/oval/accounts_password_warn_age_login_defs.xml000066400000000000000000000053111301675746700302300ustar00rootroot00000000000000 Set Password Expiration Parameters multi_platform_all The password expiration warning age should be set appropriately. /etc/login.defs .*\n[^#]*(PASS_WARN_AGE\s+\d+)\s*\n 1 variable_last_pass_warn_age_instance_value scap-security-guide-0.1.31/shared/oval/accounts_passwords_pam_faillock_deny.xml000066400000000000000000000237331301675746700301070ustar00rootroot00000000000000 Lock out account after failed login attempts multi_platform_all The number of allowed failed logins should be set correctly. /etc/pam.d/system-auth [\n][\s]*auth[\s]+required[\s]+pam_faillock\.so[\s]+preauth[\s]+silent[\s]+[^\n]*deny=([0-9]+)[\s]*(?s).*[\n][\s]*auth[\s]+(?:(?:sufficient)|(?:\[.*default=die.*\]))[\s]+pam_unix\.so[^\n]*[\n] 1 /etc/pam.d/system-auth [\n][\s]*auth[\s]+(?:(?:sufficient)|(?:\[.*default=die.*\]))[\s]+pam_unix\.so[^\n]+(?s).*[\n][\s]*auth[\s]+\[default=die\][\s]+pam_faillock\.so[\s]+authfail[\s]+[^\n]*deny=([0-9]+)[^\n]*[\n] 1 /etc/pam.d/system-auth [\n][\s]*account[\s]+required[\s]+pam_faillock\.so[^\n]*[\n][\s]*account[\s]+required[\s]+pam_unix\.so[^\n]*[\n] 1 /etc/pam.d/password-auth [\n][\s]*auth[\s]+required[\s]+pam_faillock\.so[\s]+preauth[\s]+silent[\s]+[^\n]*deny=([0-9]+)[\s]*(?s).*[\n][\s]*auth[\s]+(?:(?:sufficient)|(?:\[.*default=die.*\]))[\s]+pam_unix\.so[^\n]*[\n] 1 /etc/pam.d/password-auth [\n][\s]*auth[\s]+(?:(?:sufficient)|(?:\[.*default=die.*\]))[\s]+pam_unix\.so[^\n]+(?s).*[\n][\s]*auth[\s]+\[default=die\][\s]+pam_faillock\.so[\s]+authfail[\s]+[^\n]*deny=([0-9]+)[^\n]*[\n] 1 /etc/pam.d/password-auth [\n][\s]*account[\s]+required[\s]+pam_faillock\.so[^\n]*[\n][\s]*account[\s]+required[\s]+pam_unix\.so[^\n]*[\n] 1 scap-security-guide-0.1.31/shared/oval/accounts_passwords_pam_faillock_interval.xml000066400000000000000000000124321301675746700307660ustar00rootroot00000000000000 Lock out account after failed login attempts multi_platform_rhel The number of allowed failed logins should be set correctly. /etc/pam.d/system-auth ^\s*auth\s+(?:(?:required))\s+pam_faillock\.so\s+preauth.*fail_interval=([0-9]*).*$ 1 /etc/pam.d/system-auth ^\s*auth\s+(?:(?:sufficient)|(?:\[default=die\]))\s+pam_faillock\.so\s+authfail.*fail_interval=([0-9]*).*$ 1 /etc/pam.d/password-auth ^\s*auth\s+(?:(?:sufficient)|(?:\[default=die\]))\s+pam_faillock\.so\s+authfail.*fail_interval=([0-9]*).*$ 1 /etc/pam.d/password-auth ^\s*auth\s+(?:(?:required))\s+pam_faillock\.so\s+preauth.*fail_interval=([0-9]*).*$ 1 scap-security-guide-0.1.31/shared/oval/accounts_passwords_pam_faillock_unlock_time.xml000066400000000000000000000124441301675746700314560ustar00rootroot00000000000000 Lock out account after failed login attempts multi_platform_rhel multi_platform_fedora The number of allowed failed logins should be set correctly. /etc/pam.d/system-auth ^\s*auth\s+(?:(?:required))\s+pam_faillock\.so\s+preauth.*unlock_time=([0-9]*).*$ 1 /etc/pam.d/system-auth ^\s*auth\s+(?:(?:sufficient)|(?:\[default=die\]))\s+pam_faillock\.so\s+authfail.*unlock_time=([0-9]*).*$ 1 /etc/pam.d/password-auth ^\s*auth\s+(?:(?:sufficient)|(?:\[default=die\]))\s+pam_faillock\.so\s+authfail.*unlock_time=([0-9]*).*$ 1 /etc/pam.d/password-auth ^\s*auth\s+(?:(?:required))\s+pam_faillock\.so\s+preauth.*unlock_time=([0-9]*).*$ 1 scap-security-guide-0.1.31/shared/oval/accounts_root_path_dirs_no_write.xml000066400000000000000000000050231301675746700272600ustar00rootroot00000000000000 Write permissions are disabled for group and other in all directories in Root's Path multi_platform_all Check each directory in root's path and make use it does not grant write permission to group and other PATH state_accounts_root_path_dirs_wrong_perms state_accounts_root_path_dirs_symlink true true symbolic link scap-security-guide-0.1.31/shared/oval/accounts_tmout.xml000066400000000000000000000042471301675746700235110ustar00rootroot00000000000000 Set Interactive Session Timeout multi_platform_rhel Checks interactive shell timeout /etc/profile ^[\s]*TMOUT[\s]*=[\s]*(.*)[\s]*$ 1 /etc/profile.d ^.*\.sh$ ^[\s]*TMOUT[\s]*=[\s]*(.*)[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/accounts_umask_etc_bashrc.xml000066400000000000000000000100771301675746700256340ustar00rootroot00000000000000 Ensure that Users Have Sensible Umask Values set for bash multi_platform_rhel multi_platform_wrlinux The default umask for users of the bash shell /etc/bashrc ^[\s]*(?i)UMASK(?-i)[\s]+([^#\s]*) 1 64 8 var_etc_bashrc_umask_as_number scap-security-guide-0.1.31/shared/oval/accounts_umask_etc_csh_cshrc.xml000066400000000000000000000102131301675746700263210ustar00rootroot00000000000000 Ensure that Users Have Sensible Umask Values set for csh multi_platform_rhel multi_platform_wrlinux The default umask for users of the csh shell /etc/csh.cshrc ^[\s]*(?i)UMASK(?-i)[\s]+([^#\s]*) 1 64 8 var_etc_csh_cshrc_umask_as_number scap-security-guide-0.1.31/shared/oval/accounts_umask_etc_login_defs.xml000066400000000000000000000102741301675746700265020ustar00rootroot00000000000000 Ensure that Users Have Sensible Umask Values in /etc/login.defs multi_platform_rhel multi_platform_wrlinux The default umask for all users specified in /etc/login.defs /etc/login.defs ^[\s]*(?i)UMASK(?-i)[\s]+([^#\s]*) 1 64 8 var_etc_login_defs_umask_as_number scap-security-guide-0.1.31/shared/oval/accounts_umask_etc_profile.xml000066400000000000000000000101461301675746700260270ustar00rootroot00000000000000 Ensure that Users Have Sensible Umask Values in /etc/profile multi_platform_rhel multi_platform_wrlinux The default umask for all users should be set correctly /etc/profile ^[\s]*(?i)UMASK(?-i)[\s]+([^#\s]*) 1 64 8 var_etc_profile_umask_as_number scap-security-guide-0.1.31/shared/oval/aide_build_database.xml000066400000000000000000000115521301675746700243440ustar00rootroot00000000000000 Aide Database Must Exist CentOS 4 CentOS 5 Red Hat Enterprise Linux 4 Red Hat Enterprise Linux 5 multi_platform_rhel multi_platform_fedora The aide database must be initialized. /etc/aide.conf ^@@define[\s]DBDIR[\s]+(/.*)$ 1 /etc/aide.conf ^database_out=file:@@{DBDIR}/([a-z.]+)$ 1 /etc/aide.conf ^database=file:@@{DBDIR}/([a-z.]+)$ 1 / / scap-security-guide-0.1.31/shared/oval/aide_periodic_cron_checking.xml000066400000000000000000000076021301675746700260740ustar00rootroot00000000000000 Configure Periodic Execution of AIDE multi_platform_rhel By default, AIDE does not install itself for periodic execution. Periodically running AIDE is necessary to reveal unexpected changes in installed files. /etc/crontab ^[0-9]*[\s]*[0-9]*[\s]*\*[\s]*\*[\s]*\*[\s]*root[\s]*/usr/sbin/aide[\s]*\-\-check.*$ 1 /etc/cron.d ^.*$ ^[0-9]*[\s]*[0-9]*[\s]*\*[\s]*\*[\s]*\*[\s]*root[\s]*/usr/sbin/aide[\s]*\-\-check.*$ 1 /var/spool/cron/root ^[0-9]*[\s]*[0-9]*[\s]*\*[\s]*\*[\s]*\*[\s]*(root|)/usr/sbin/aide[\s]*\-\-check.*$ 1 /etc/cron.(daily|weekly|monthly) ^.*$ ^\s*/usr/sbin/aide[\s]*\-\-check.*$ 1 scap-security-guide-0.1.31/shared/oval/aide_scan_notification.xml000066400000000000000000000063001301675746700251060ustar00rootroot00000000000000 Configure Notification of Post-AIDE Scan Details multi_platform_rhel AIDE should notify appropriate personnel of the details of a scan after the scan has been run. /etc/crontab ^.*/usr/sbin/aide[\s]*\-\-check.*\|.*/bin/mail[\s]*-s[\s]*".*"[\s]*root@.*$ 1 /var/spool/cron/root ^.*/usr/sbin/aide[\s]*\-\-check.*\|.*/bin/mail[\s]*-s[\s]*".*"[\s]*root@.*$ 1 /etc/cron.(d|daily|weekly|monthly) ^.*$ ^.*/usr/sbin/aide[\s]*\-\-check.*\|.*/bin/mail[\s]*-s[\s]*".*"[\s]*root@.*$ 1 scap-security-guide-0.1.31/shared/oval/aide_use_fips_hashes.xml000066400000000000000000000045201301675746700245660ustar00rootroot00000000000000 Configure AIDE to Use FIPS 140-2 for Validating Hashes multi_platform_rhel AIDE should be configured to use the FIPS 140-2 cryptographic hashes. /etc/aide.conf ^[A-Z]*[\s]*=[\s]*.*(sha1|rmd160|sha256|whirlpool|tiger|haval|gost|crc32).*$ 0 /etc/aide.conf ^[A-Z]*[\s]*=[\s]*([a-z0-9\+]*)$ 1 ^.*sha512.*$ scap-security-guide-0.1.31/shared/oval/aide_verify_acls.xml000066400000000000000000000026711301675746700237310ustar00rootroot00000000000000 Configure AIDE to Verify Access Control Lists (ACLs) multi_platform_rhel AIDE should be configured to verify Access Control Lists (ACLs). /etc/aide.conf ^(?!ALLXTRAHASHES)[A-Z]*[\s]*=[\s]*([a-z0-9\+]*)$ 1 ^.*acl.*$ scap-security-guide-0.1.31/shared/oval/aide_verify_ext_attributes.xml000066400000000000000000000027751301675746700260620ustar00rootroot00000000000000 Configure AIDE to Verify Extended Attributes multi_platform_rhel AIDE should be configured to verify extended file attributes. /etc/aide.conf ^(?!ALLXTRAHASHES)[A-Z]*[\s]*=[\s]*([a-z0-9\+]*)$ 1 ^.*xattrs.*$ scap-security-guide-0.1.31/shared/oval/audit_rules_dac_modification_chmod.xml000066400000000000000000000137231301675746700274670ustar00rootroot00000000000000 Audit Discretionary Access Control Modification Events - chmod Red Hat Enterprise Linux 7 multi_platform_fedora The changing of file permissions and attributes should be audited. /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/augenrules.*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+chmod[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+chmod[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/auditctl.*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+chmod[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+chmod[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/audit_rules_dac_modification_chown.xml000066400000000000000000000137231301675746700275130ustar00rootroot00000000000000 Audit Discretionary Access Control Modification Events - chown Red Hat Enterprise Linux 7 multi_platform_fedora The changing of file permissions and attributes should be audited. /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/augenrules.*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+chown[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+chown[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/auditctl.*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+chown[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+chown[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/audit_rules_dac_modification_fchmod.xml000066400000000000000000000137751301675746700276440ustar00rootroot00000000000000 Audit Discretionary Access Control Modification Events - fchmod Red Hat Enterprise Linux 7 multi_platform_fedora The changing of file permissions and attributes should be audited. /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/augenrules.*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+fchmod[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+fchmod[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/auditctl.*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+fchmod[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+fchmod[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/audit_rules_dac_modification_fchmodat.xml000066400000000000000000000141211301675746700301530ustar00rootroot00000000000000 Audit Discretionary Access Control Modification Events - fchmodat Red Hat Enterprise Linux 7 multi_platform_fedora The changing of file permissions and attributes should be audited. /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/augenrules.*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+fchmodat[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+fchmodat[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/auditctl.*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+fchmodat[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+fchmodat[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/audit_rules_dac_modification_fchown.xml000066400000000000000000000137751301675746700276700ustar00rootroot00000000000000 Audit Discretionary Access Control Modification Events - fchown Red Hat Enterprise Linux 7 multi_platform_fedora The changing of file permissions and attributes should be audited. /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/augenrules.*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+fchown[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+fchown[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/auditctl.*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+fchown[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+fchown[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/audit_rules_dac_modification_fchownat.xml000066400000000000000000000141211301675746700301770ustar00rootroot00000000000000 Audit Discretionary Access Control Modification Events - fchownat Red Hat Enterprise Linux 7 multi_platform_fedora The changing of file permissions and attributes should be audited. /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/augenrules.*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+fchownat[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+fchownat[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/auditctl.*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+fchownat[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+fchownat[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/audit_rules_dac_modification_fremovexattr.xml000066400000000000000000000143711301675746700311230ustar00rootroot00000000000000 Audit Discretionary Access Control Modification Events - fremovexattr Red Hat Enterprise Linux 7 multi_platform_fedora The changing of file permissions and attributes should be audited. /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/augenrules.*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+fremovexattr[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+fremovexattr[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/auditctl.*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+fremovexattr[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+fremovexattr[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/audit_rules_dac_modification_fsetxattr.xml000066400000000000000000000141731301675746700304210ustar00rootroot00000000000000 Audit Discretionary Access Control Modification Events - fsetxattr Red Hat Enterprise Linux 7 multi_platform_fedora The changing of file permissions and attributes should be audited. /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/augenrules.*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+fsetxattr[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+fsetxattr[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/auditctl.*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+fsetxattr[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+fsetxattr[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/audit_rules_dac_modification_lchown.xml000066400000000000000000000137751301675746700276760ustar00rootroot00000000000000 Audit Discretionary Access Control Modification Events - lchown Red Hat Enterprise Linux 7 multi_platform_fedora The changing of file permissions and attributes should be audited. /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/augenrules.*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+lchown[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+lchown[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/auditctl.*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+lchown[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+lchown[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/audit_rules_dac_modification_lremovexattr.xml000066400000000000000000000143711301675746700311310ustar00rootroot00000000000000 Audit Discretionary Access Control Modification Events - lremovexattr Red Hat Enterprise Linux 7 multi_platform_fedora The changing of file permissions and attributes should be audited. /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/augenrules.*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+lremovexattr[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+lremovexattr[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/auditctl.*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+lremovexattr[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+lremovexattr[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/audit_rules_dac_modification_lsetxattr.xml000066400000000000000000000142151301675746700304240ustar00rootroot00000000000000 Audit Discretionary Access Control Modification Events - lsetxattr Red Hat Enterprise Linux 7 multi_platform_fedora The changing of file permissions and attributes should be audited. /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/augenrules.*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+lsetxattr[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+lsetxattr[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/auditctl.*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+lsetxattr[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+lsetxattr[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/audit_rules_dac_modification_removexattr.xml000066400000000000000000000143171301675746700307550ustar00rootroot00000000000000 Audit Discretionary Access Control Modification Events - removexattr Red Hat Enterprise Linux 7 multi_platform_fedora The changing of file permissions and attributes should be audited. /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/augenrules.*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+removexattr[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+removexattr[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/auditctl.*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+removexattr[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+removexattr[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/audit_rules_dac_modification_setxattr.xml000066400000000000000000000141251301675746700302500ustar00rootroot00000000000000 Audit Discretionary Access Control Modification Events - setxattr Red Hat Enterprise Linux 7 multi_platform_fedora The changing of file permissions and attributes should be audited. /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/augenrules.*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+setxattr[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+setxattr[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/auditctl.*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b32[\s]+)(?:.*-S[\s]+setxattr[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+(?:.*-F[\s]+arch=b64[\s]+)(?:.*-S[\s]+setxattr[\s]+)(?:.*-F\s+auid>=1000[\s]+)(?:.*-F\s+auid!=4294967295[\s]+).*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/audit_rules_file_deletion_events.xml000066400000000000000000000076051301675746700272310ustar00rootroot00000000000000 Audit File Deletion Events Red Hat Enterprise Linux 7 multi_platform_fedora Audit files deletion events. /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/augenrules.*$ 1 /etc/audit/rules\.d/.*\.rules ^\-a\s+always,exit\s+(\-F\s+arch=(b64|b32)\s+)?\-S\s+rmdir\s+\-S\s+unlink\s+\-S\s+unlinkat\s+\-S\s+rename\s+\-S\s+renameat\s+\-F\s+auid>=1000\s+\-F\s+auid!=4294967295\s+\-k\s+[-\w]+\s*$ 1 /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/auditctl.*$ 1 /etc/audit/audit.rules ^\-a\s+always,exit\s+(\-F\s+arch=(b64|b32)\s+)?\-S\s+rmdir\s+\-S\s+unlink\s+\-S\s+unlinkat\s+\-S\s+rename\s+\-S\s+renameat\s+\-F\s+auid>=1000\s+\-F\s+auid!=4294967295\s+\-k\s+[-\w]+\s*$ 1 scap-security-guide-0.1.31/shared/oval/audit_rules_immutable.xml000066400000000000000000000062731301675746700250220ustar00rootroot00000000000000 Make Audit Configuration Immutable Red Hat Enterprise Linux 7 multi_platform_fedora Force a reboot to change audit rules is enabled /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/augenrules.*$ 1 /etc/audit/rules\.d/.*\.rules ^\-e\s+2\s*$ 1 /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/auditctl.*$ 1 /etc/audit/audit.rules ^\-e\s+2\s*$ 1 scap-security-guide-0.1.31/shared/oval/audit_rules_kernel_module_loading.xml000066400000000000000000000220451301675746700273600ustar00rootroot00000000000000 Audit Kernel Module Loading and Unloading Red Hat Enterprise Linux 7 multi_platform_fedora The audit rules should be configured to log information about kernel module loading and unloading. /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/augenrules.*$ 1 /etc/audit/rules\.d/.*\.rules ^\-w[\s]+/usr/sbin/insmod[\s]+\-p[\s]+\b([raw]*x[raw]*)\b[\s]+\-k[\s]+[-\w]+[\s]*$ 1 /etc/audit/rules\.d/.*\.rules ^\-w[\s]+/usr/sbin/rmmod[\s]+\-p[\s]+\b([raw]*x[raw]*)\b[\s]+\-k[\s]+[-\w]+[\s]*$ 1 /etc/audit/rules\.d/.*\.rules ^\-w\s+/usr/sbin/modprobe[\s]+\-p[\s]+\b([raw]*x[raw]*)\b[\s]+\-k[\s]+[-\w]+[\s]*$ 1 /etc/audit/rules\.d/.*\.rules ^\-a\s+always,exit\s+(\-F\s+arch=(b64|b32)\s+)?\-S\s+init_module\s+\-S\s+delete_module\s+\-k\s+[-\w]+\s*$ 1 /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/auditctl.*$ 1 /etc/audit/audit.rules ^\-w[\s]+/usr/sbin/insmod[\s]+\-p[\s]+\b([raw]*x[raw]*)\b[\s]+\-k[\s]+[-\w]+[\s]*$ 1 /etc/audit/audit.rules ^\-w[\s]+/usr/sbin/rmmod[\s]+\-p[\s]+\b([raw]*x[raw]*)\b[\s]+\-k[\s]+[-\w]+[\s]*$ 1 /etc/audit/audit.rules ^\-w\s+/usr/sbin/modprobe[\s]+\-p[\s]+\b([raw]*x[raw]*)\b[\s]+\-k[\s]+[-\w]+[\s]*$ 1 /etc/audit/audit.rules ^\-a\s+always,exit\s+(\-F\s+arch=(b64|b32)\s+)?\-S\s+init_module\s+\-S\s+delete_module\s+\-k\s+[-\w]+\s*$ 1 scap-security-guide-0.1.31/shared/oval/audit_rules_login_events.xml000066400000000000000000000136331301675746700255350ustar00rootroot00000000000000 Record Attempts to Alter Login and Logout Events Red Hat Enterprise Linux 7 multi_platform_fedora Audit rules should be configured to log successful and unsuccessful login and logout events. /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/augenrules.*$ 1 /etc/audit/rules\.d/.*\.rules ^\-w\s+/var/log/tallylog\s+\-p\s+wa\s+\-k\s+[-\w]+\s*$ 1 /etc/audit/rules\.d/.*\.rules ^\-w\s+/var/run/faillock/\s+\-p\s+wa\s+\-k\s+[-\w]+\s*$ 1 /etc/audit/rules\.d/.*\.rules ^\-w\s+/var/log/lastlog\s+\-p\s+wa\s+\-k\s+[-\w]+\s*$ 1 /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/auditctl.*$ 1 /etc/audit/audit.rules ^\-w\s+/var/log/tallylog\s+\-p\s+wa\s+\-k\s+[-\w]+\s*$ 1 /etc/audit/audit.rules ^\-w\s+/var/run/faillock/\s+\-p\s+wa\s+\-k\s+[-\w]+\s*$ 1 /etc/audit/audit.rules ^\-w\s+/var/log/lastlog\s+\-p\s+wa\s+\-k\s+[-\w]+\s*$ 1 scap-security-guide-0.1.31/shared/oval/audit_rules_mac_modification.xml000066400000000000000000000067671301675746700263400ustar00rootroot00000000000000 Record Events that Modify the System's Mandatory Access Controls Red Hat Enterprise Linux 7 multi_platform_fedora Audit rules that detect changes to the system's mandatory access controls (SELinux) are enabled. /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/augenrules.*$ 1 /etc/audit/rules\.d/.*\.rules ^\-w[\s]+/etc/selinux/[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s]+\-k[\s]+[-\w]+[\s]*$ 1 /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/auditctl.*$ 1 /etc/audit/audit.rules ^\-w[\s]+/etc/selinux/[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s]+\-k[\s]+[-\w]+[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/audit_rules_media_export.xml000066400000000000000000000071461301675746700255230ustar00rootroot00000000000000 Audit Information Export To Media Red Hat Enterprise Linux 7 multi_platform_fedora Audit rules that detect the mounting of filesystems should be enabled. /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/augenrules.*$ 1 /etc/audit/rules\.d/.*\.rules ^\-a\s+always,exit\s+(\-F\s+arch=(b64|b32)\s+)?\-S\s+mount\s+\-F\s+auid>=1000\s+\-F\s+auid!=4294967295\s+\-k\s+[-\w]+\s*$ 1 /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/auditctl.*$ 1 /etc/audit/audit.rules ^\-a\s+always,exit\s+(\-F\s+arch=(b64|b32)\s+)?\-S\s+mount\s+\-F\s+auid>=1000\s+\-F\s+auid!=4294967295\s+\-k\s+[-\w]+\s*$ 1 scap-security-guide-0.1.31/shared/oval/audit_rules_networkconfig_modification.xml000066400000000000000000000225421301675746700304440ustar00rootroot00000000000000 Record Events that Modify the System's Network Environment Red Hat Enterprise Linux 7 multi_platform_fedora The network environment should not be modified by anything other than administrator action. Any change to network parameters should be audited. /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/augenrules.*$ 1 /etc/audit/rules\.d/.*\.rules ^\-a\s+always,exit\s+(\-F\s+arch=(b64|b32)\s+)?\-S\s+sethostname\s+\-S\s+setdomainname\s+\-k\s+[-\w]+\s*$ 1 /etc/audit/rules\.d/.*\.rules ^\-w[\s]+/etc/issue[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s]+\-k[\s]+[-\w]+[\s]*$ 1 /etc/audit/rules\.d/.*\.rules ^\-w[\s]+/etc/issue\.net[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s]+\-k[\s]+[-\w]+[\s]*$ 1 /etc/audit/rules\.d/.*\.rules ^\-w[\s]+/etc/hosts[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s]+\-k[\s]+[-\w]+[\s]*$ 1 /etc/audit/rules\.d/.*\.rules ^\-w[\s]+/etc/sysconfig/network[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s]+\-k[\s]+[-\w]+[\s]*$ 1 /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/auditctl.*$ 1 /etc/audit/audit.rules ^\-a\s+always,exit\s+(\-F\s+arch=(b64|b32)\s+)?\-S\s+sethostname\s+\-S\s+setdomainname\s+\-k\s+[-\w]+\s*$ 1 /etc/audit/audit.rules ^\-w[\s]+/etc/issue[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s]+\-k[\s]+[-\w]+[\s]*$ 1 /etc/audit/audit.rules ^\-w[\s]+/etc/issue\.net[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s]+\-k[\s]+[-\w]+[\s]*$ 1 /etc/audit/audit.rules ^\-w[\s]+/etc/hosts[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s]+\-k[\s]+[-\w]+[\s]*$ 1 /etc/audit/audit.rules ^\-w[\s]+/etc/sysconfig/network[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s]+\-k[\s]+[-\w]+[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/audit_rules_privileged_commands.xml000066400000000000000000000213121301675746700270450ustar00rootroot00000000000000 Ensure auditd Collects Information on the Use of Privileged Commands Red Hat Enterprise Linux 7 multi_platform_fedora Audit rules about the information on the use of privileged commands are enabled. / [a-z]+ state_setuid_or_setgid_set state_dev_proc_sys_dirs true true ^\/(dev|proc|sys)\/.*$ -a always,exit -F path= -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged variable_count_of_suid_sgid_binaries_on_system /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/augenrules.*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*(-a always,exit -F path=[^\n]+ -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged)[\s]*$ 1 state_proper_audit_rule_but_for_unprivileged_command /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/auditctl.*$ 1 /etc/audit/audit.rules ^[\s]*(-a always,exit -F path=[^\n]+ -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged)[\s]*$ 1 state_proper_audit_rule_but_for_unprivileged_command scap-security-guide-0.1.31/shared/oval/audit_rules_session_events.xml000066400000000000000000000133701301675746700261060ustar00rootroot00000000000000 Record Attempts to Alter Process and Session Initiation Information Red Hat Enterprise Linux 7 multi_platform_fedora Audit rules should capture information about session initiation. /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/augenrules.*$ 1 /etc/audit/rules\.d/.*\.rules ^\-w\s+/var/run/utmp\s+\-p\s+wa\s+\-k\s+[-\w]+\s*$ 1 /etc/audit/rules\.d/.*\.rules ^\-w\s+/var/log/btmp\s+\-p\s+wa\s+\-k\s+[-\w]+\s*$ 1 /etc/audit/rules\.d/.*\.rules ^\-w\s+/var/log/wtmp\s+\-p\s+wa\s+\-k\s+[-\w]+\s*$ 1 /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/auditctl.*$ 1 /etc/audit/audit.rules ^\-w\s+/var/run/utmp\s+\-p\s+wa\s+\-k\s+[-\w]+\s*$ 1 /etc/audit/audit.rules ^\-w\s+/var/log/btmp\s+\-p\s+wa\s+\-k\s+[-\w]+\s*$ 1 /etc/audit/audit.rules ^\-w\s+/var/log/wtmp\s+\-p\s+wa\s+\-k\s+[-\w]+\s*$ 1 scap-security-guide-0.1.31/shared/oval/audit_rules_sysadmin_actions.xml000066400000000000000000000072161301675746700264100ustar00rootroot00000000000000 Audit System Administrator Actions Red Hat Enterprise Linux 7 multi_platform_fedora Audit actions taken by system administrators on the system. /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/augenrules.*$ 1 /etc/audit/rules\.d/.*\.rules ^\-w[\s]+/etc/sudoers[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s]+\-k[\s]+[-\w]+[\s]*$ 1 /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/auditctl.*$ 1 /etc/audit/audit.rules ^\-w[\s]+/etc/sudoers[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s]+\-k[\s]+[-\w]+[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/audit_rules_time_adjtimex.xml000066400000000000000000000133231301675746700256600ustar00rootroot00000000000000 Record Attempts to Alter Time Through Adjtimex Red Hat Enterprise Linux 7 multi_platform_fedora Record attempts to alter time through adjtimex. /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/augenrules.*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+-F[\s]+arch=b32.*-S[\s]+adjtimex[\s]+.*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+-F[\s]+arch=b64.*-S[\s]+adjtimex[\s]+.*-k[\s]+[\S]+[\s]*$ 1 /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/auditctl.*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+-F[\s]+arch=b32.*-S[\s]+adjtimex[\s]+.*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+-F[\s]+arch=b64.*-S[\s]+adjtimex[\s]+.*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/audit_rules_time_clock_settime.xml000066400000000000000000000141421301675746700267000ustar00rootroot00000000000000 Record Attempts to Alter Time Through Clock_settime Red Hat Enterprise Linux 7 multi_platform_fedora Record attempts to alter time through clock_settime. /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/augenrules.*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+-F[\s]+arch=b32[\s]+-S[\s]+clock_settime[\s]+-F[\s]+a0=(?:0x)?0[\s]+(?:-F[\s]+key=|-k[\s]+)time-change[\s]*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+-F[\s]+arch=b64[\s]+-S[\s]+clock_settime[\s]+-F[\s]+a0=(?:0x)?0[\s]+(?:-F[\s]+key=|-k[\s]+)time-change[\s]*$ 1 /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/auditctl.*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+-F[\s]+arch=b32[\s]+-S[\s]+clock_settime[\s]+-F[\s]+a0=(?:0x)?0[\s]+(?:-F[\s]+key=|-k[\s]+)time-change[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+-F[\s]+arch=b64[\s]+-S[\s]+clock_settime[\s]+-F[\s]+a0=(?:0x)?0[\s]+(?:-F[\s]+key=|-k[\s]+)time-change[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/audit_rules_time_settimeofday.xml000066400000000000000000000135771301675746700265630ustar00rootroot00000000000000 Record Attempts to Alter Time Through Settimeofday Red Hat Enterprise Linux 7 multi_platform_fedora Record attempts to alter time through settimeofday. /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/augenrules.*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+-F[\s]+arch=b32.*-S[\s]+settimeofday[\s]+.*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+-F[\s]+arch=b64.*-S[\s]+settimeofday[\s]+.*-k[\s]+[\S]+[\s]*$ 1 /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/auditctl.*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+-F[\s]+arch=b32.*-S[\s]+settimeofday[\s]+.*-k[\s]+[\S]+[\s]*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+-F[\s]+arch=b64.*-S[\s]+settimeofday[\s]+.*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/audit_rules_time_stime.xml000066400000000000000000000104471301675746700252000ustar00rootroot00000000000000 Record Attempts to Alter Time Through Stime Red Hat Enterprise Linux 7 multi_platform_fedora Record attempts to alter time through stime. Note that on 64-bit architectures the stime system call is not defined in the audit system calls lookup table. /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/augenrules.*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-a[\s]+always,exit[\s]+-F[\s]+arch=b32.*-S[\s]+stime[\s]+.*-k[\s]+[\S]+[\s]*$ 1 /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/auditctl.*$ 1 /etc/audit/audit.rules ^[\s]*-a[\s]+always,exit[\s]+-F[\s]+arch=b32.*-S[\s]+stime[\s]+.*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/audit_rules_time_watch_localtime.xml000066400000000000000000000067361301675746700272240ustar00rootroot00000000000000 Record Attempts to Alter Time Through the Localtime File Red Hat Enterprise Linux 7 multi_platform_fedora Record attempts to alter time through /etc/localtime. /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/augenrules.*$ 1 /etc/audit/rules\.d/.*\.rules ^[\s]*-w[\s]+\/etc\/localtime[\s]+-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b.*-k[\s]+[\S]+[\s]*$ 1 /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/auditctl.*$ 1 /etc/audit/audit.rules ^[\s]*-w[\s]+\/etc\/localtime[\s]+-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b.*-k[\s]+[\S]+[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/audit_rules_unsuccessful_file_modification.xml000066400000000000000000000235401301675746700313050ustar00rootroot00000000000000 Ensure auditd Collects Unauthorized Access Attempts to Files (unsuccessful) Red Hat Enterprise Linux 7 multi_platform_fedora Audit rules about the unauthorized access attempts to files (unsuccessful) are enabled. /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/augenrules.*$ 1 /etc/audit/rules\.d/.*\.rules ^\-a\s+always,exit\s+\-F\s+arch=b32\s+?\-S\s+creat\s+\-S\s+open\s+\-S\s+openat\s+\-S\s+open_by_handle_at\s+\-S\s+truncate\s+\-S\s+ftruncate\s+\-F\s+exit=\-EACCES\s+\-F\s+auid>=1000\s+\-F\s+auid!=4294967295\s+\-k\s+[-\w]+\s*$ 1 /etc/audit/rules\.d/.*\.rules ^\-a\s+always,exit\s+\-F\s+arch=b32\s+?\-S\s+creat\s+\-S\s+open\s+\-S\s+openat\s+\-S\s+open_by_handle_at\s+\-S\s+truncate\s+\-S\s+ftruncate\s+\-F\s+exit=\-EPERM\s+\-F\s+auid>=1000\s+\-F\s+auid!=4294967295\s+\-k\s+[-\w]+\s*$ 1 /etc/audit/rules\.d/.*\.rules ^\-a\s+always,exit\s+\-F\s+arch=b64\s+?\-S\s+creat\s+\-S\s+open\s+\-S\s+openat\s+\-S\s+open_by_handle_at\s+\-S\s+truncate\s+\-S\s+ftruncate\s+\-F\s+exit=\-EACCES\s+\-F\s+auid>=1000\s+\-F\s+auid!=4294967295\s+\-k\s+[-\w]+\s*$ 1 /etc/audit/rules\.d/.*\.rules ^\-a\s+always,exit\s+\-F\s+arch=b64\s+?\-S\s+creat\s+\-S\s+open\s+\-S\s+openat\s+\-S\s+open_by_handle_at\s+\-S\s+truncate\s+\-S\s+ftruncate\s+\-F\s+exit=\-EPERM\s+\-F\s+auid>=1000\s+\-F\s+auid!=4294967295\s+\-k\s+[-\w]+\s*$ 1 /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/auditctl.*$ 1 /etc/audit/audit.rules ^\-a\s+always,exit\s+\-F\s+arch=b32\s+?\-S\s+creat\s+\-S\s+open\s+\-S\s+openat\s+\-S\s+open_by_handle_at\s+\-S\s+truncate\s+\-S\s+ftruncate\s+\-F\s+exit=\-EACCES\s+\-F\s+auid>=1000\s+\-F\s+auid!=4294967295\s+\-k\s+[-\w]+\s*$ 1 /etc/audit/audit.rules ^\-a\s+always,exit\s+\-F\s+arch=b32\s+?\-S\s+creat\s+\-S\s+open\s+\-S\s+openat\s+\-S\s+open_by_handle_at\s+\-S\s+truncate\s+\-S\s+ftruncate\s+\-F\s+exit=\-EPERM\s+\-F\s+auid>=1000\s+\-F\s+auid!=4294967295\s+\-k\s+[-\w]+\s*$ 1 /etc/audit/audit.rules ^\-a\s+always,exit\s+\-F\s+arch=b64\s+?\-S\s+creat\s+\-S\s+open\s+\-S\s+openat\s+\-S\s+open_by_handle_at\s+\-S\s+truncate\s+\-S\s+ftruncate\s+\-F\s+exit=\-EACCES\s+\-F\s+auid>=1000\s+\-F\s+auid!=4294967295\s+\-k\s+[-\w]+\s*$ 1 /etc/audit/audit.rules ^\-a\s+always,exit\s+\-F\s+arch=b64\s+?\-S\s+creat\s+\-S\s+open\s+\-S\s+openat\s+\-S\s+open_by_handle_at\s+\-S\s+truncate\s+\-S\s+ftruncate\s+\-F\s+exit=\-EPERM\s+\-F\s+auid>=1000\s+\-F\s+auid!=4294967295\s+\-k\s+[-\w]+\s*$ 1 scap-security-guide-0.1.31/shared/oval/audit_rules_usergroup_modification.xml000066400000000000000000000242731301675746700276230ustar00rootroot00000000000000 Audit User/Group Modification Red Hat Enterprise Linux 7 multi_platform_fedora Audit user/group modification. /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/augenrules.*$ 1 /etc/audit/rules\.d/.*\.rules ^\-w[\s]+/etc/group[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s+]\-k[\s]+\w+[\s]*$ 1 /etc/audit/rules\.d/.*\.rules ^\-w[\s]+/etc/passwd[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s]+\-k[\s]+\w+[\s]*$ 1 /etc/audit/rules\.d/.*\.rules ^\-w[\s]+/etc/gshadow[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s]+\-k[\s]+\w+[\s]*$ 1 /etc/audit/rules\.d/.*\.rules ^\-w[\s]+/etc/shadow[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s]+\-k[\s]+\w+[\s]*$ 1 /etc/audit/rules\.d/.*\.rules ^\-w[\s]+/etc/security/opasswd[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s]+\-k[\s]+\w+[\s]*$ 1 /usr/lib/systemd/system/auditd.service ^ExecStartPost=\-\/sbin\/auditctl.*$ 1 /etc/audit/audit.rules ^\-w[\s]+/etc/group[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s+]\-k[\s]+\w+[\s]*$ 1 /etc/audit/audit.rules ^\-w[\s]+/etc/passwd[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s]+\-k[\s]+\w+[\s]*$ 1 /etc/audit/audit.rules ^\-w[\s]+/etc/gshadow[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s]+\-k[\s]+\w+[\s]*$ 1 /etc/audit/audit.rules ^\-w[\s]+/etc/shadow[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s]+\-k[\s]+\w+[\s]*$ 1 /etc/audit/audit.rules ^\-w[\s]+/etc/security/opasswd[\s]+\-p[\s]+\b([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)\b[\s]+\-k[\s]+\w+[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/auditd_audispd_syslog_plugin_activated.xml000066400000000000000000000025571301675746700304310ustar00rootroot00000000000000 The syslog Plugin Of the Audit Event Multiplexor (audispd) Is Activated multi_platform_all active setting in /etc/audisp/plugins.d/syslog.conf is set to 'yes' /etc/audisp/plugins.d/syslog.conf ^[ ]*active[ ]+=[ ]+yes[ ]*$ 1 scap-security-guide-0.1.31/shared/oval/auditd_conf_log_group_not_root.xml000066400000000000000000000023141301675746700267120ustar00rootroot00000000000000 'log_group' Not Set To 'root' In /etc/audit/auditd.conf multi_platform_all Verify 'log_group' is not set to 'root' in /etc/audit/auditd.conf. /etc/audit/auditd.conf ^[ ]*log_group[ ]+=[ ]+root[ ]*$ 1 scap-security-guide-0.1.31/shared/oval/auditd_data_retention_action_mail_acct.xml000066400000000000000000000033771301675746700303300ustar00rootroot00000000000000 Auditd Email Account to Notify Upon Action multi_platform_all action_mail_acct setting in /etc/audit/auditd.conf is set to a certain account /etc/audit/auditd.conf ^[ ]*action_mail_acct[ ]+=[ ]+(\S+)[ ]*$ 1 scap-security-guide-0.1.31/shared/oval/auditd_data_retention_admin_space_left_action.xml000066400000000000000000000035501301675746700316620ustar00rootroot00000000000000 Auditd Action to Take When Disk is Low on Space multi_platform_all admin_space_left_action setting in /etc/audit/auditd.conf is set to a certain action /etc/audit/auditd.conf ^[ ]*admin_space_left_action[ ]+=[ ]+(\S+)[ ]*$ 1 scap-security-guide-0.1.31/shared/oval/auditd_data_retention_flush.xml000066400000000000000000000032301301675746700261640ustar00rootroot00000000000000 Auditd priority for flushing data to disk multi_platform_rhel The setting for flush in /etc/audit/auditd.conf /etc/audit/auditd.conf ^[ ]*flush[ ]+=[ ]+(\S+)[ ]*$ 1 scap-security-guide-0.1.31/shared/oval/auditd_data_retention_max_log_file.xml000066400000000000000000000033321301675746700274730ustar00rootroot00000000000000 Auditd Maximum Log File Size multi_platform_all max_log_file setting in /etc/audit/auditd.conf is set to at least a certain value /etc/audit/auditd.conf ^[ ]*max_log_file[ ]+=[ ]+(\d+)[ ]*$ 1 scap-security-guide-0.1.31/shared/oval/auditd_data_retention_max_log_file_action.xml000066400000000000000000000035001301675746700310250ustar00rootroot00000000000000 Auditd Action to Take When Maximum Log Size Reached multi_platform_all max_log_file_action setting in /etc/audit/auditd.conf is set to a certain action /etc/audit/auditd.conf ^[ ]*max_log_file_action[ ]+=[ ]+(\S+)[ ]*$ 1 scap-security-guide-0.1.31/shared/oval/auditd_data_retention_num_logs.xml000066400000000000000000000032711301675746700266730ustar00rootroot00000000000000 Auditd Maximum Number of Logs to Retain multi_platform_all num_logs setting in /etc/audit/auditd.conf is set to at least a certain value /etc/audit/auditd.conf ^[ ]*num_logs[ ]+=[ ]+(\d+)[ ]*$ 1 scap-security-guide-0.1.31/shared/oval/auditd_data_retention_space_left_action.xml000066400000000000000000000034501301675746700305110ustar00rootroot00000000000000 Auditd Action to Take When Disk Starting to Run Low on Space multi_platform_all space_left_action setting in /etc/audit/auditd.conf is set to a certain action /etc/audit/auditd.conf ^[ ]*space_left_action[ ]+=[ ]+(\S+)[ ]*$ 1 scap-security-guide-0.1.31/shared/oval/banner_etc_issue.xml000066400000000000000000000023051301675746700237430ustar00rootroot00000000000000 /etc/issue 1 scap-security-guide-0.1.31/shared/oval/bootloader_audit_argument.xml000066400000000000000000000052151301675746700256600ustar00rootroot00000000000000 Enable Auditing for Processes Which Start Prior to the Audit Daemon Red Hat Enterprise Linux 7 multi_platform_fedora Look for argument audit=1 in the kernel line in /etc/default/grub. /etc/default/grub ^\s*GRUB_CMDLINE_LINUX="(.*)"$ 1 /etc/default/grub ^\s*GRUB_CMDLINE_LINUX_DEFAULT="(.*)"$ 1 ^.*audit=1.*$ scap-security-guide-0.1.31/shared/oval/bootloader_disable_recovery_set_to_true.xml000066400000000000000000000032451301675746700306060ustar00rootroot00000000000000 Verify GRUB_DISABLE_RECOVERY Set to true Red Hat Enterprise Linux 7 multi_platform_fedora GRUB_DISABLE_RECOVERY set to 'true' in /etc/default/grub /etc/default/grub ^\s*GRUB_DISABLE_RECOVERY=(.*)$ 1 ^true|"true"$ scap-security-guide-0.1.31/shared/oval/bootloader_nousb_argument.xml000066400000000000000000000027751301675746700257100ustar00rootroot00000000000000 Disable Kernel Support for USB via Bootloader Configuration Red Hat Enterprise Linux 7 multi_platform_fedora Look for 'nousb' argument in the kernel line in /etc/default/grub /etc/default/grub ^\s*GRUB_CMDLINE_LINUX="(.*)"$ 1 ^.*nousb.*$ scap-security-guide-0.1.31/shared/oval/bootloader_password.xml000066400000000000000000000047371301675746700245220ustar00rootroot00000000000000 Set Boot Loader Password Red Hat Enterprise Linux 7 multi_platform_fedora The grub2 boot loader should have password protection enabled. /boot/grub2/grub.cfg /boot/grub2/grub.cfg ^[\s]*set[\s]+superusers=\"(?i)(?!root|admin|administrator)(?-i).*\"$ 1 /boot/grub2/grub.cfg ^[\s]*password_pbkdf2[\s]+.*[\s]+grub\.pbkdf2\.sha512.*$ 1 scap-security-guide-0.1.31/shared/oval/bootloader_uefi_password.xml000066400000000000000000000053431301675746700255240ustar00rootroot00000000000000 Set the UEFI Boot Loader Password Red Hat Enterprise Linux 7 multi_platform_fedora The UEFI grub2 boot loader should have password protection enabled. /boot/efi/EFI/(redhat|fedora)/grub.cfg /boot/efi/EFI/(redhat|fedora)/grub.cfg ^[\s]*set[\s]+superusers=\"(?i)(?!root|admin|administrator)(?-i).*\"$ 1 /boot/efi/EFI/(redhat|fedora)/grub.cfg ^[\s]*password_pbkdf2[\s]+.*[\s]+grub\.pbkdf2\.sha512.*$ 1 scap-security-guide-0.1.31/shared/oval/cups_disable_browsing.xml000066400000000000000000000043101301675746700250000ustar00rootroot00000000000000 Disable Printer Browsing Entirely if Possible multi_platform_rhel The CUPS print service can be configured to broadcast a list of available printers to the network. Other machines on the network, also running the CUPS print service, can be configured to listen to these broadcasts and add and configure these printers for immediate use. By disabling this browsing capability, the machine will no longer generate or receive such broadcasts. /etc/cups/cupsd.conf ^[\s]*Browsing[\s]+(?:Off|No) 1 /etc/cups/cupsd.conf ^[\s]*BrowseAllow[\s]+(?:none) 1 scap-security-guide-0.1.31/shared/oval/cups_disable_printserver.xml000066400000000000000000000043541301675746700255410ustar00rootroot00000000000000 Disable Printer Server if Possible multi_platform_rhel By default, locally configured printers will not be shared over the network, but if this functionality has somehow been enabled, these recommendations will disable it again. Be sure to disable outgoing printer list broadcasts, or remote users will still be able to see the locally configured printers, even if they cannot actually print to them. To limit print serving to a particular set of users, use the Policy directive. /etc/cups/cupsd.conf ^[\s]*Port[\s]+(\d)+ 1 /etc/cups/cupsd.conf ^[\s]*Listen[\s]+(?:localhost|127\.0\.0\.1|::1):(\d)+ 1 scap-security-guide-0.1.31/shared/oval/dconf_gnome_banner_enabled.xml000066400000000000000000000044411301675746700257130ustar00rootroot00000000000000 Enable GNOME3 Login Warning Banner Red Hat Enterprise Linux 7 multi_platform_fedora Enable the GNOME3 Login warning banner. /etc/dconf/db/gdm.d/ ^.*$ ^\[org/gnome/login-screen]([^\n]*\n+)+?banner-message-enable=true$ 1 /etc/dconf/db/gdm.d/locks/ ^.*$ ^/org/gnome/login-screen/banner-message-enable$ 1 scap-security-guide-0.1.31/shared/oval/dconf_gnome_disable_automount.xml000066400000000000000000000132071301675746700265120ustar00rootroot00000000000000 Disable GNOME3 Automounting Red Hat Enterprise Linux 7 multi_platform_fedora The system's default desktop environment, GNOME3, will mount devices and removable media (such as DVDs, CDs and USB flash drives) whenever they are inserted into the system. Disable automount and autorun within GNOME3. /etc/dconf/db/local.d/ ^.*$ ^\[org/gnome/desktop/media-handling]([^\n]*\n+)+?automount=false$ 1 /etc/dconf/db/local.d/locks/ ^.*$ ^/org/gnome/desktop/media-handling/automount$ 1 /etc/dconf/db/local.d/ ^.*$ ^\[org/gnome/desktop/media-handling]([^\n]*\n+)+?automount-open=false$ 1 /etc/dconf/db/local.d/locks/ ^.*$ ^/org/gnome/desktop/media-handling/automount-open$ 1 /etc/dconf/db/local.d/ ^.*$ ^\[org/gnome/desktop/media-handling]([^\n]*\n+)+?autorun-never=true$ 1 /etc/dconf/db/local.d/locks/ ^.*$ ^/org/gnome/desktop/media-handling/autorun-never$ 1 scap-security-guide-0.1.31/shared/oval/dconf_gnome_disable_ctrlaltdel_reboot.xml000066400000000000000000000044301301675746700301610ustar00rootroot00000000000000 Disable Ctrl-Alt-Del Reboot Key Sequence in GNOME3 Red Hat Enterprise Linux 7 multi_platform_fedora Disable the GNOME3 ctrl-alt-del reboot key sequence in GNOME3. /etc/dconf/db/local.d/ ^.*$ ^\[org/gnome/settings-daemon/plugins/media-keys]([^\n]*\n+)+?logout=''$ 1 /etc/dconf/db/local.d/locks/ ^.*$ ^/org/gnome/settings-daemon/plugins/media-keys/logout$ 1 scap-security-guide-0.1.31/shared/oval/dconf_gnome_disable_geolocation.xml000066400000000000000000000072601301675746700267640ustar00rootroot00000000000000 Disable Geolocation in GNOME3 Red Hat Enterprise Linux 7 multi_platform_fedora Disable GNOME3 Geolocation for the clock and system. /etc/dconf/db/local.d/ ^.*$ ^\[org/gnome/system/location]([^\n]*\n+)+?enabled=false$ 1 /etc/dconf/db/local.d/locks/ ^.*$ ^/org/gnome/system/location/enabled$ 1 /etc/dconf/db/local.d/ ^.*$ ^\[org/gnome/clocks]([^\n]*\n+)+?geolocation=false$ 1 /etc/dconf/db/local.d/locks/ ^.*$ ^/org/gnome/clocks/geolocation$ 1 scap-security-guide-0.1.31/shared/oval/dconf_gnome_disable_power_settings.xml000066400000000000000000000043741301675746700275400ustar00rootroot00000000000000 Disable Power Settings in GNOME3 Red Hat Enterprise Linux 7 multi_platform_fedora Disable GNOME3 power settings. /etc/dconf/db/local.d/ ^.*$ ^\[org/gnome/settings-daemon/plugins/power/active]([^\n]*\n+)+?active=false$ 1 /etc/dconf/db/local.d/locks/ ^.*$ ^/org/gnome/settings-daemon/plugins/power/active$ 1 scap-security-guide-0.1.31/shared/oval/dconf_gnome_disable_restart_shutdown.xml000066400000000000000000000047061301675746700301020ustar00rootroot00000000000000 Disable the GNOME3 Login Restart and Shutdown Buttons Red Hat Enterprise Linux 7 multi_platform_fedora Disable the GNOME3 Login GUI Restart and Shutdown buttons to all users on the login screen. /etc/dconf/db/gdm.d/ ^.*$ ^\[org/gnome/login-screen]([^\n]*\n+)+?disable-restart-buttons=true$ 1 /etc/dconf/db/gdm.d/locks/ ^.*$ ^/org/gnome/login-screen/disable-restart-buttons$ 1 scap-security-guide-0.1.31/shared/oval/dconf_gnome_disable_thumbnailers.xml000066400000000000000000000050751301675746700271600ustar00rootroot00000000000000 Disable All GNOME3 Thumbnailers Red Hat Enterprise Linux 7 multi_platform_fedora The system's default desktop environment, GNOME3, uses a number of different thumbnailer programs to generate thumbnails for any new or modified content in an opened folder. Disable the execution of these thumbnail applications within GNOME3. /etc/dconf/db/local.d/ ^.*$ ^\[org/gnome/desktop/thumbnailers]([^\n]*\n+)+?disable-all=true$ 1 /etc/dconf/db/local.d/locks/ ^.*$ ^/org/gnome/desktop/thumbnailers/disable-all$ 1 scap-security-guide-0.1.31/shared/oval/dconf_gnome_disable_user_admin.xml000066400000000000000000000044161301675746700266070ustar00rootroot00000000000000 Disable User Administration in GNOME3 Red Hat Enterprise Linux 7 multi_platform_fedora Disable GNOME3's ability to give users some administrative rights. /etc/dconf/db/local.d/ ^.*$ ^\[org/gnome/desktop/lockdown]([^\n]*\n+)+?user-administratrion-enabled=true$ 1 /etc/dconf/db/local.d/locks/ ^.*$ ^/org/gnome/desktop/lockdown/user-administration-disabled$ 1 scap-security-guide-0.1.31/shared/oval/dconf_gnome_disable_user_list.xml000066400000000000000000000044471301675746700264760ustar00rootroot00000000000000 Disable the GNOME3 Login User List Red Hat Enterprise Linux 7 multi_platform_fedora Disable the GNOME3 GUI listing of all known users on the login screen. /etc/dconf/db/gdm.d/ ^.*$ ^\[org/gnome/login-screen]([^\n]*\n+)+?disable-user-list=true$ 1 /etc/dconf/db/gdm.d/locks/ ^.*$ ^/org/gnome/login-screen/disable-user-list$ 1 scap-security-guide-0.1.31/shared/oval/dconf_gnome_disable_wifi_create.xml000066400000000000000000000043751301675746700267460ustar00rootroot00000000000000 Disable WIFI Network Connection Creation in GNOME3 Red Hat Enterprise Linux 7 multi_platform_fedora Disable the GNOME3 wireless network creation settings. /etc/dconf/db/local.d/ ^.*$ ^\[org/gnome/nm-applet]([^\n]*\n+)+?disable-wifi-create=true$ 1 /etc/dconf/db/local.d/locks/ ^.*$ ^/org/gnome/nm-applet/disable-wifi-create$ 1 scap-security-guide-0.1.31/shared/oval/dconf_gnome_disable_wifi_notification.xml000066400000000000000000000045051301675746700301640ustar00rootroot00000000000000 Disable WIFI Network Notification in GNOME3 Red Hat Enterprise Linux 7 multi_platform_fedora Disable the GNOME3 wireless network notification. /etc/dconf/db/local.d/ ^.*$ ^\[org/gnome/nm-applet]([^\n]*\n+)+?suppress-wireless-networks-available=true$ 1 /etc/dconf/db/local.d/locks/ ^.*$ ^/org/gnome/nm-applet/suppress-wireless-networks-available$ 1 scap-security-guide-0.1.31/shared/oval/dconf_gnome_enable_smartcard_auth.xml000066400000000000000000000045761301675746700273140ustar00rootroot00000000000000 Enable the GNOME3 Login Smartcard Authentication Red Hat Enterprise Linux 7 multi_platform_fedora Enable smartcard authentication in the GNOME3 Login GUI. /etc/dconf/db/gdm.d/ ^.*$ ^\[org/gnome/login-screen]([^\n]*\n+)+?enable-smartcard-authentication=true$ 1 /etc/dconf/db/gdm.d/locks/ ^.*$ ^/org/gnome/login-screen/enable-smartcard-authentication$ 1 scap-security-guide-0.1.31/shared/oval/dconf_gnome_login_banner_text.xml000066400000000000000000000052461301675746700265010ustar00rootroot00000000000000 Enable GUI Warning Banner Red Hat Enterprise Linux 7 multi_platform_fedora Enable the GUI warning banner. /etc/dconf/db/gdm.d/locks/ ^.*$ ^/org/gnome/login-screen/banner-message-text$ 1 /etc/dconf/db/gdm.d/ ^.*$ ^banner-message-text=[\s']*([^']*) 1 scap-security-guide-0.1.31/shared/oval/dconf_gnome_login_retries.xml000066400000000000000000000045161301675746700256440ustar00rootroot00000000000000 Set the GNOME3 Login Number of Failures Red Hat Enterprise Linux 7 multi_platform_fedora Set the GNOME3 number of login failure attempts. /etc/dconf/db/gdm.d/ ^.*$ ^\[org/gnome/login-screen]([^\n]*\n+)+?allowed-failures=3$ 1 /etc/dconf/db/gdm.d/locks/ ^.*$ ^/org/gnome/login-screen/allowed-failures$ 1 scap-security-guide-0.1.31/shared/oval/dconf_gnome_remote_access_credential_prompt.xml000066400000000000000000000045521301675746700314060ustar00rootroot00000000000000 Require Credential Prompting for Remote Access in GNOME3 Red Hat Enterprise Linux 7 multi_platform_fedora Configure GNOME3 to require credential prompting for remote access. /etc/dconf/db/local.d/ ^.*$ ^\[org/gnome/Vino]([^\n]*\n+)+?authentication-methods=\['vnc'\]$ 1 /etc/dconf/db/local.d/locks/ ^.*$ ^/org/gnome/Vino/authentication-methods$ 1 scap-security-guide-0.1.31/shared/oval/dconf_gnome_remote_access_encryption.xml000066400000000000000000000045471301675746700300710ustar00rootroot00000000000000 Require Encryption for Remote Access in GNOME3 Red Hat Enterprise Linux 7 multi_platform_fedora Configure GNOME3 to require encryption for remote access connections. /etc/dconf/db/local.d/ ^.*$ ^\[org/gnome/Vino]([^\n]*\n+)+?require-encryption=true$ 1 /etc/dconf/db/local.d/locks/ ^.*$ ^/org/gnome/Vino/require-encryption$ 1 scap-security-guide-0.1.31/shared/oval/dconf_gnome_screensaver_idle_activation_enabled.xml000066400000000000000000000047501301675746700322070ustar00rootroot00000000000000 Enable GNOME3 Screensaver Idle Activation Red Hat Enterprise Linux 7 multi_platform_fedora Idle activation of the screen saver should be enabled. /etc/dconf/db/local.d/ ^.*$ ^\[org/gnome/desktop/screensaver]([^\n]*\n+)+?idle-activation-enabled=true$ 1 /etc/dconf/db/local.d/locks/ ^.*$ ^/org/gnome/desktop/screensaver/idle-activation-enabled$ 1 scap-security-guide-0.1.31/shared/oval/dconf_gnome_screensaver_idle_delay.xml000066400000000000000000000077531301675746700275000ustar00rootroot00000000000000 Configure the GNOME3 GUI Screen locking Red Hat Enterprise Linux 7 multi_platform_fedora The allowed period of inactivity before the screensaver is activated. /etc/dconf/db/local.d/ ^.*$ ^\[org/gnome/desktop/session]([^\n]*\n+)+?idle-delay=uint32[\s][0-9]*$ 1 /etc/dconf/db/local.d/locks/ ^.*$ ^/org/gnome/desktop/session/idle-delay$ 1 /etc/dconf/db/local.d/ ^.*$ ^idle-delay[\s=]*uint32[\s]([^=\s]*) 1 scap-security-guide-0.1.31/shared/oval/dconf_gnome_screensaver_lock_delay.xml000066400000000000000000000051641301675746700275050ustar00rootroot00000000000000 Enable GNOME3 Screensaver Lock Delay After Idle Period Red Hat Enterprise Linux 7 multi_platform_fedora Idle activation of the screen lock should be enabled immediately or after a delay. /etc/dconf/db/local.d/ ^.*$ ^\[org/gnome/desktop/screensaver]([^\n]*\n+)+?lock-delay=uint32[\s]0$ 1 /etc/dconf/db/local.d/locks/ ^.*$ ^/org/gnome/desktop/screensaver/lock-delay$ 1 scap-security-guide-0.1.31/shared/oval/dconf_gnome_screensaver_lock_enabled.xml000066400000000000000000000101271301675746700277740ustar00rootroot00000000000000 Enable GNOME3 Screensaver Lock After Idle Period Red Hat Enterprise Linux 7 multi_platform_fedora Idle activation of the screen lock should be enabled. /etc/dconf/db/local.d/ ^.*$ ^\[org/gnome/desktop/screensaver]([^\n]*\n+)+?lock-enabled=true$ 1 /etc/dconf/db/local.d/locks/ ^.*$ ^/org/gnome/desktop/screensaver/lock-enabled$ 1 /etc/dconf/db/local.d/ ^.*$ ^\[org/gnome/desktop/screensaver]([^\n]*\n+)+?lock-delay=uint32[\s]0$ 1 /etc/dconf/db/local.d/locks/ ^.*$ ^/org/gnome/desktop/screensaver/lock-delay$ 1 scap-security-guide-0.1.31/shared/oval/dconf_gnome_screensaver_mode_blank.xml000066400000000000000000000051041301675746700274640ustar00rootroot00000000000000 Implement Blank Screensaver Red Hat Enterprise Linux 7 multi_platform_fedora The GNOME3 screensaver should be blank. /etc/dconf/db/local.d/ ^.*$ ^\[org/gnome/desktop/screensaver]([^\n]*\n+)+?picture-uri=string[\s]\'\'$ 1 /etc/dconf/db/local.d/locks/ ^.*$ ^/org/gnome/desktop/screensaver/picture-uri$ 1 scap-security-guide-0.1.31/shared/oval/dconf_gnome_screensaver_user_info.xml000066400000000000000000000046161301675746700273710ustar00rootroot00000000000000 Disable Full User Name on Splash Shield Red Hat Enterprise Linux 7 multi_platform_fedora GNOME3 screen splash shield should not display full name of logged in user. /etc/dconf/db/local.d/ ^.*$ ^\[org/gnome/desktop/screensaver]([^\n]*\n+)+?show-full-name-in-top-bar=false$ 1 /etc/dconf/db/local.d/locks/ ^.*$ ^/org/gnome/desktop/screensaver/show-full-name-in-top-bar$ 1 scap-security-guide-0.1.31/shared/oval/dconf_gnome_session_user_locks.xml000066400000000000000000000046061301675746700267130ustar00rootroot00000000000000 Ensure Users Cannot Change GNOME3 Session Settings Red Hat Enterprise Linux 7 multi_platform_fedora Ensure that users cannot change GNOME3 session idle and lock settings. /etc/dconf/db/local.d/locks/ ^.*$ ^/org/gnome/desktop/session/idle-delay$ 1 /etc/dconf/db/local.d/locks/ ^.*$ ^/org/gnome/desktop/screensaver/lock-delay$ 1 scap-security-guide-0.1.31/shared/oval/dir_perms_etc_httpd_conf.xml000066400000000000000000000031171301675746700254640ustar00rootroot00000000000000 Directory /etc/httpd/conf/ Permissions multi_platform_rhel Directory permissions for /etc/httpd/conf/ should be set to 0750 (or stronger). /etc/httpd/conf false false false false false false false scap-security-guide-0.1.31/shared/oval/dir_perms_var_log_httpd.xml000066400000000000000000000032401301675746700253320ustar00rootroot00000000000000 Directory /var/log/httpd/ Permissions multi_platform_rhel Directory permissions for /var/log/httpd should be set to 0700 (or stronger). /var/log/httpd false false false false false false false false false scap-security-guide-0.1.31/shared/oval/dir_perms_world_writable_sticky_bits.xml000066400000000000000000000030311301675746700301230ustar00rootroot00000000000000 Verify that All World-Writable Directories Have Sticky Bits Set multi_platform_rhel The sticky bit should be set for all world-writable directories. / state_world_writable_and_not_sticky false true scap-security-guide-0.1.31/shared/oval/dir_perms_world_writable_system_owned.xml000066400000000000000000000033741301675746700303260ustar00rootroot00000000000000 Find world writable directories not owned by a system account Red Hat Enterprise Linux 7 All world writable directories should be owned by a system user. / state_gid_is_user_and_world_writable 1000 true scap-security-guide-0.1.31/shared/oval/disable_host_auth.xml000066400000000000000000000024701301675746700241170ustar00rootroot00000000000000 Disable Host-Based Authentication multi_platform_rhel SSH host-based authentication should be disabled. /etc/ssh/sshd_config ^[\s]*(?i)HostbasedAuthentication(?-i)[\s]+yes[\s]*(?:|(?:#.*))?$ 1 scap-security-guide-0.1.31/shared/oval/disable_interactive_boot.xml000066400000000000000000000055101301675746700254570ustar00rootroot00000000000000 Verify that Interactive Boot is Disabled Red Hat Enterprise Linux 7 multi_platform_fedora The ability for users to perform interactive startups should be disabled. /etc/default/grub ^\s*GRUB_CMDLINE_LINUX=".*systemd.confirm_spawn=(?:1|yes|true|on).*$ 1 /etc/default/grub ^\s*GRUB_CMDLINE_LINUX_DEFAULT=".*systemd.confirm_spawn=(?:1|yes|true|on).*$ 1 scap-security-guide-0.1.31/shared/oval/disable_prelink.xml000066400000000000000000000051101301675746700235570ustar00rootroot00000000000000 Disable Prelinking multi_platform_fedora multi_platform_rhel multi_platform_rhel-osp The prelinking feature can interfere with the operation of checksum integrity tools (e.g. AIDE), mitigates the protection provided by ASLR, and requires additional CPU cycles by software upgrades. /etc/sysconfig/prelink ^[\s]*PRELINKING=no[\s]* 1 scap-security-guide-0.1.31/shared/oval/disable_users_coredumps.xml000066400000000000000000000025741301675746700253500ustar00rootroot00000000000000 Disable Core Dumps multi_platform_rhel multi_platform_fedora Core dumps for all users should be disabled 0 /etc/security/limits.conf ^[\s]*\*[\s]+(?:hard|-)[\s]+core[\s]+([\d]+) 1 scap-security-guide-0.1.31/shared/oval/display_login_attempts.xml000066400000000000000000000027271301675746700252210ustar00rootroot00000000000000 Set Last Login/Access Notification Red Hat Enterprise Linux 7 multi_platform_fedora Configure the system to notify users of last login/access using pam_lastlog. /etc/pam.d/postlogin [\n][\s]*session[\s]+\[default=1\][\s]+pam_lastlog.so[\s\w\d\=]+showfailed[\s\w\d\=]*\n[\s]*session[\s]+optional[\s]+pam_lastlog.so[\s\w\d\=]+showfailed[\s\w\d\=]*[\n] 1 scap-security-guide-0.1.31/shared/oval/enable_dconf_user_profile.xml000066400000000000000000000021501301675746700256060ustar00rootroot00000000000000 Implement Local DB for DConf User Profile Red Hat Enterprise Linux 7 multi_platform_fedora The DConf User profile should have the local DB configured. /etc/dconf/profile/user ^user-db:user\nsystem-db:local$ 1 scap-security-guide-0.1.31/shared/oval/enable_selinux_bootloader.xml000066400000000000000000000056511301675746700256510ustar00rootroot00000000000000 Enable SELinux in the GRUB2 Bootloader" Red Hat Enterprise Linux 7 Check if selinux=0 OR enforcing=0 within the GRUB2 configuration files, fail if found. /etc/default/grub ^[\s]*GRUB_CMDLINE_LINUX.*(selinux|enforcing)=0.*$ 1 /etc/grub2.cfg ^.*(selinux|enforcing)=0.*$ 1 /etc/grub.d ^.*$ ^.*(selinux|enforcing)=0.*$ 1 scap-security-guide-0.1.31/shared/oval/ensure_gpgcheck_globally_activated.xml000066400000000000000000000043431301675746700275040ustar00rootroot00000000000000 Ensure Yum gpgcheck Globally Activated multi_platform_all The gpgcheck option should be used to ensure that checking of an RPM package's signature always occurs prior to its installation. /etc/yum.conf ^\s*gpgcheck\s*=\s*1\s*$ 1 /etc/dnf/dnf.conf ^\s*gpgcheck\s*=\s*1\s*$ 1 scap-security-guide-0.1.31/shared/oval/ensure_gpgcheck_never_disabled.xml000066400000000000000000000025701301675746700266210ustar00rootroot00000000000000 Ensure gpgcheck Enabled For All Yum or Dnf Package Repositories multi_platform_fedora multi_platform_rhel Ensure all yum or dnf repositories utilize signature checking. /etc/yum.repos.d .* ^\s*gpgcheck\s*=\s*0\s*$ 1 scap-security-guide-0.1.31/shared/oval/ensure_logrotate_activated.xml000066400000000000000000000076001301675746700260430ustar00rootroot00000000000000 Ensure the logrotate utility performs the automatic rotation of log files on daily basis multi_platform_rhel multi_platform_debian multi_platform_ubuntu The frequency of automatic log files rotation performed by the logrotate utility should be configured to run daily /etc/logrotate.conf (?:daily)*.*(?=[\n][\s]*daily)(.*)$ 1 state_another_rotate_interval_after_daily }[^{]+[\n][\s]*(weekly|monthly|yearly)|[\n][\s]*(weekly|monthly|yearly)[^}]+{ /etc/cron.daily/logrotate ^[\s]*/usr/sbin/logrotate[\s]*/etc/logrotate.conf(?:.*)$ 1 scap-security-guide-0.1.31/shared/oval/ensure_redhat_gpgkey_installed.xml000066400000000000000000000105671301675746700267010ustar00rootroot00000000000000 Red Hat Release and Auxiliary gpg-pubkey Packages Installed multi_platform_rhel The Red Hat release and auxiliary key packages are required to be installed. gpg-pubkey 4ae0493b fd431d51 45700c69 2fa658e0 53a7ff4b f4a80eb5 4e0fd3a3 c105b9de scap-security-guide-0.1.31/shared/oval/file_group_owner_grub2_cfg.xml000066400000000000000000000035431301675746700257250ustar00rootroot00000000000000 File grub.cfg Owned By root Group Red Hat Enterprise Linux 7 multi_platform_fedora The grub.cfg file should be owned by the root group. By default, this file is located at /boot/grub2/grub.cfg or, for EFI systems, at /boot/efi/EFI/redhat/grub.cfg /boot/grub2/grub.cfg /boot/efi/EFI/redhat/grub.cfg 0 scap-security-guide-0.1.31/shared/oval/file_groupowner_etc_group.xml000066400000000000000000000021071301675746700257100ustar00rootroot00000000000000 Verify group who owns 'group' file multi_platform_rhel The /etc/group file should be owned by the appropriate group. 0 /etc/group scap-security-guide-0.1.31/shared/oval/file_groupowner_etc_gshadow.xml000066400000000000000000000021371301675746700262130ustar00rootroot00000000000000 Verify group who owns 'gshadow' file multi_platform_rhel The /etc/gshadow file should be owned by the appropriate group. 0 /etc/gshadow scap-security-guide-0.1.31/shared/oval/file_groupowner_etc_passwd.xml000066400000000000000000000022211301675746700260520ustar00rootroot00000000000000 Verify group who owns 'passwd' file multi_platform_rhel multi_platform_sle The /etc/passwd file should be owned by the appropriate group. 0 /etc/passwd scap-security-guide-0.1.31/shared/oval/file_owner_etc_group.xml000066400000000000000000000020351301675746700246330ustar00rootroot00000000000000 Verify user who owns 'group' file multi_platform_rhel The /etc/group file should be owned by the appropriate user. 0 /etc/group scap-security-guide-0.1.31/shared/oval/file_owner_etc_gshadow.xml000066400000000000000000000020701301675746700251320ustar00rootroot00000000000000 Verify user who owns 'gshadow' file multi_platform_rhel The /etc/gshadow file should be owned by the appropriate user. 0 /etc/gshadow scap-security-guide-0.1.31/shared/oval/file_owner_etc_passwd.xml000066400000000000000000000021301301675746700247740ustar00rootroot00000000000000 Verify user who owns 'passwd' file multi_platform_rhel multi_platform_sle The /etc/passwd file should be owned by the appropriate user. 0 /etc/passwd scap-security-guide-0.1.31/shared/oval/file_ownership_binary_dirs.xml000066400000000000000000000050551301675746700260420ustar00rootroot00000000000000 Verify that System Executables Have Root Ownership CentOS 4 CentOS 5 Red Hat Enterprise Linux 4 Red Hat Enterprise Linux 5 multi_platform_rhel multi_platform_fedora Checks that /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin, /usr/libexec, and objects therein, are owned by root. ^\/(|s)bin|^\/usr\/(|local\/)(|s)bin|^\/usr\/libexec state_owner_binaries_not_root ^\/(|s)bin|^\/usr\/(|local\/)(|s)bin|^\/usr\/libexec ^.*$ state_owner_binaries_not_root 0 scap-security-guide-0.1.31/shared/oval/file_ownership_library_dirs.xml000066400000000000000000000042011301675746700262120ustar00rootroot00000000000000 Verify that Shared Library Files Have Root Ownership multi_platform_rhel multi_platform_fedora Checks that /lib, /lib64, /usr/lib, /usr/lib64, /lib/modules, and objects therein, are owned by root. ^\/lib(|64)\/|^\/usr\/lib(|64)\/ state_owner_libraries_not_root ^\/lib(|64)\/|^\/usr\/lib(|64)\/ ^.*$ state_owner_libraries_not_root 0 scap-security-guide-0.1.31/shared/oval/file_ownership_var_log_audit.xml000066400000000000000000000105601301675746700263510ustar00rootroot00000000000000 Verify /var/log/audit Ownership multi_platform_all Checks that all /var/log/audit files and directories are owned by the root user and group. /var/log/audit state_owner_not_root_root_var_log_audit /var/log/audit ^.*$ state_owner_not_root_root_var_log_audit 0 0 /var/log/audit state_owner_not_root_var_log_audit-non_root /var/log/audit ^.*$ state_owner_not_root_var_log_audit-non_root 0 0 scap-security-guide-0.1.31/shared/oval/file_permissions_binary_dirs.xml000066400000000000000000000041121301675746700263700ustar00rootroot00000000000000 Verify that System Executables Have Restrictive Permissions CentOS 4 CentOS 5 Red Hat Enterprise Linux 4 Red Hat Enterprise Linux 5 multi_platform_rhel multi_platform_fedora Checks that binary files under /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin, and /usr/libexec are not group-writable or world-writable. ^\/(|s)bin|^\/usr\/(|local\/)(|s)bin|^\/usr\/libexec ^.*$ state_perms_binary_files_nogroupwrite_noworldwrite state_perms_binary_files_symlink true true symbolic link scap-security-guide-0.1.31/shared/oval/file_permissions_etc_group.xml000066400000000000000000000027161301675746700260620ustar00rootroot00000000000000 Verify permissions on 'group' file multi_platform_rhel File permissions for /etc/group should be set correctly. false false false false false false false false /etc/group scap-security-guide-0.1.31/shared/oval/file_permissions_etc_gshadow.xml000066400000000000000000000042501301675746700263550ustar00rootroot00000000000000 Verify /etc/gshadow Permissions multi_platform_rhel This test makes sure that /etc/gshadow is owned by 0, group owned by 0, and has mode 0000. If the target file or directory has an extended ACL then it will fail the mode check. /etc/gshadow 0 0 false false false false false false false false false false false false scap-security-guide-0.1.31/shared/oval/file_permissions_etc_passwd.xml000066400000000000000000000040701301675746700262220ustar00rootroot00000000000000 Verify /etc/passwd Permissions multi_platform_rhel multi_platform_sle This test makes sure that /etc/passwd is owned by 0, group owned by 0, and has mode 0644 (or stronger). If the target file or directory has an extended ACL then it will fail the mode check. /etc/passwd 0 0 false false false false false false false false scap-security-guide-0.1.31/shared/oval/file_permissions_etc_shadow.xml000066400000000000000000000042301301675746700262040ustar00rootroot00000000000000 Verify /etc/shadow Permissions multi_platform_rhel This test makes sure that /etc/shadow is owned by 0, group owned by 0, and has mode 0000. If the target file or directory has an extended ACL then it will fail the mode check. /etc/shadow 0 0 false false false false false false false false false false false false scap-security-guide-0.1.31/shared/oval/file_permissions_grub2_cfg.xml000066400000000000000000000042501301675746700257260ustar00rootroot00000000000000 File grub.cfg Permissions Red Hat Enterprise Linux 7 multi_platform_fedora File permissions for grub.cfg should be set to 0600 (or stronger). By default, this file is located at /boot/grub2/grub.cfg or, for EFI systems, at /boot/efi/EFI/redhat/grub.cfg /boot/grub2/grub.cfg /boot/efi/EFI/redhat/grub.cfg false false false false false false false scap-security-guide-0.1.31/shared/oval/file_permissions_home_dirs.xml000066400000000000000000000037371301675746700260500ustar00rootroot00000000000000 Proper Permissions User Home Directories multi_platform_all File permissions should be set correctly for the home directories for all user accounts. /home state_home_dirs_home_itself state_home_dirs_wrong_perm /home true true true true true true true scap-security-guide-0.1.31/shared/oval/file_permissions_httpd_server_conf_files.xml000066400000000000000000000040061301675746700307650ustar00rootroot00000000000000 Verify Permissions On Apache Web Server Configuration Files multi_platform_rhel The /etc/httpd/conf/* files should have the appropriate permissions (0640 or stronger). false false false false false false false false false /etc/httpd/conf ^.*$ scap-security-guide-0.1.31/shared/oval/file_permissions_library_dirs.xml000066400000000000000000000047011301675746700265540ustar00rootroot00000000000000 Verify that Shared Library Files Have Restrictive Permissions multi_platform_rhel multi_platform_fedora Checks that /lib, /lib64, /usr/lib, /usr/lib64, /lib/modules, and objects therein, are not group-writable or world-writable. ^\/lib(|64)|^\/usr\/lib(|64) state_perms_nogroupwrite_noworldwrite perms_state_symlink ^\/lib(|64)|^\/usr\/lib(|64) ^.*$ state_perms_nogroupwrite_noworldwrite perms_state_symlink true true symbolic link scap-security-guide-0.1.31/shared/oval/file_permissions_unauthorized_world_writable.xml000066400000000000000000000056541301675746700317200ustar00rootroot00000000000000 Find Unauthorized World-Writable Files multi_platform_rhel multi_platform_wrlinux The world-write permission should be disabled for all files. / ^.*$ state_file_permissions_unauthorized_world_write state_file_permissions_unauthorized_world_write_exclude_special_selinux_files state_file_permissions_unauthorized_world_write_exclude_proc state_file_permissions_unauthorized_world_write_exclude_sys regular true ^/selinux/(?:(?:member)|(?:user)|(?:relabel)|(?:create)|(?:access)|(?:context))$ ^/proc/.*$ ^/sys/.*$ scap-security-guide-0.1.31/shared/oval/file_permissions_ungroupowned.xml000066400000000000000000000070061301675746700266240ustar00rootroot00000000000000 Find files unowned by a group Red Hat Enterprise Linux 4 Red Hat Enterprise Linux 5 CentOS 4 CentOS 5 multi_platform_rhel multi_platform_fedora All files should be owned by a group / .* state_file_permissions_ungroupowned /etc/group ^[^:]+:[^:]*:([\d]+):[^:]*$ 1 scap-security-guide-0.1.31/shared/oval/file_permissions_var_log_audit.xml000066400000000000000000000071361301675746700267130ustar00rootroot00000000000000 Verify /var/log/audit Permissions multi_platform_rhel Checks for correct permissions for all log files in /var/log/audit. /var/log/audit ^.*$ state_not_mode_0640 /var/log/audit ^.*$ state_not_mode_0600 true true true true true true true true true true true true true true true true true true true scap-security-guide-0.1.31/shared/oval/file_user_owner_grub2_cfg.xml000066400000000000000000000035221301675746700255440ustar00rootroot00000000000000 File grub.cfg Owned By root User Red Hat Enterprise Linux 7 multi_platform_fedora The grub.cfg file should be owned by the root user. By default, this file is located at /boot/grub2/grub.cfg or, for EFI systems, at /boot/efi/EFI/redhat/grub.cfg /boot/grub2/grub.cfg /boot/efi/EFI/redhat/grub.cfg 0 scap-security-guide-0.1.31/shared/oval/firewalld_sshd_disabled.xml000066400000000000000000000060141301675746700252550ustar00rootroot00000000000000 Disallow inbound firewall access to the SSH Server port Red Hat Enterprise Linux 7 If inbound SSH access is not needed, the firewall should disallow or reject access to the SSH port (22). /etc/firewalld/services ^.*\.xml$ /service/service[@name='ssh'] /etc/firewalld/services ^.*\.xml$ /service/port[@port='22'] /etc/firewalld/zones ^.*\.xml$ /zone/service[@name='ssh'] /etc/firewalld/zones ^.*\.xml$ /zone/port[@port='22'] scap-security-guide-0.1.31/shared/oval/firewalld_sshd_port_enabled.xml000066400000000000000000000073661301675746700261570ustar00rootroot00000000000000 Allow inbound firewall access to the SSH Server port Red Hat Enterprise Linux 7 If inbound SSH access is needed, the firewall should allow access to the SSH port (22). /etc/firewalld/services ^.*\.xml$ /service/service[@name='ssh'] /etc/firewalld/services ^.*\.xml$ <port.*port="(\d+)" 1 /etc/firewalld/zones ^.*\.xml$ /zone/service[@name='ssh'] /etc/firewalld/zones ^.*\.xml$ <port.*port="(\d+)" 1 scap-security-guide-0.1.31/shared/oval/ftp_log_transactions.xml000066400000000000000000000062331301675746700246610ustar00rootroot00000000000000 Banner for FTP Users multi_platform_fedora multi_platform_rhel multi_platform_rhel-osp To trace malicious activity facilitated by the FTP service, it must be configured to ensure that all commands sent to the FTP server are logged using the verbose vsftpd log format. /etc/vsftpd/vsftpd.conf ^[\s]*xferlog_enable[\s]*=[\s]*YES$ 1 /etc/vsftpd/vsftpd.conf ^[\s]*xferlog_std_format[\s]*=[\s]*NO$ 1 /etc/vsftpd/vsftpd.conf ^[\s]*log_ftp_protocol[\s]*=[\s]*YES$ 1 scap-security-guide-0.1.31/shared/oval/ftp_present_banner.xml000066400000000000000000000025671301675746700243230ustar00rootroot00000000000000 Banner for FTP Users multi_platform_fedora multi_platform_rhel multi_platform_rhel-osp This setting will cause the system greeting banner to be used for FTP connections as well. /etc/vsftpd/vsftpd.conf ^[\s]*banner_file[\s]*=[\s]*/etc/issue*$ 1 scap-security-guide-0.1.31/shared/oval/gid_passwd_group_same.xml000066400000000000000000000052761301675746700250120ustar00rootroot00000000000000 All GIDs Are Present In /etc/group CentOS 4 CentOS 5 Red Hat Enterprise Linux 4 Red Hat Enterprise Linux 5 multi_platform_rhel multi_platform_fedora All GIDs referenced in /etc/passwd must be defined in /etc/group. /etc/group ^.*:x:([0-9]+): 1 /etc/passwd ^.*:[0-9]+:([0-9]+): 1 scap-security-guide-0.1.31/shared/oval/gnome_gdm_disable_automatic_login.xml000066400000000000000000000025361301675746700273160ustar00rootroot00000000000000 Disable GDM Automatic Login Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 multi_platform_fedora Disable the GNOME Display Manager (GDM) ability to allow users to automatically login. /etc/gdm/custom.conf ^\[daemon]([^\n]*\n+)+?AutomaticLoginEnable=[Ff]alse$ 1 scap-security-guide-0.1.31/shared/oval/gnome_gdm_disable_guest_login.xml000066400000000000000000000024621301675746700264550ustar00rootroot00000000000000 Disable GDM Guest Login Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 multi_platform_fedora Disable the GNOME Display Manager (GDM) ability to allow guest users to login. /etc/gdm/custom.conf ^\[daemon]([^\n]*\n+)+?TimedLoginEnable=[Ff]alse$ 1 scap-security-guide-0.1.31/shared/oval/groupowner_shadow_file.xml000066400000000000000000000024001301675746700252020ustar00rootroot00000000000000 Verify group who owns 'shadow' file multi_platform_rhel CentOS 4 CentOS 5 Red Hat Enterprise Linux 4 Red Hat Enterprise Linux 5 The /etc/shadow file should be owned by the appropriate group. /etc/shadow 0 scap-security-guide-0.1.31/shared/oval/install_antivirus.xml000066400000000000000000000010531301675746700242040ustar00rootroot00000000000000 Package Antivirus Installed multi_platform_all Antivirus software should be installed. scap-security-guide-0.1.31/shared/oval/install_hids.xml000066400000000000000000000022151301675746700231100ustar00rootroot00000000000000 Install Intrusion Detection Software Red Hat Enterprise Linux 7 Intrusion detection software or SELinux should be installed and enabled. /etc/selinux/config ^[\s]*SELINUX[\s]*=[\s]*enforcing[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/install_mcafee_antivirus.xml000066400000000000000000000021511301675746700255040ustar00rootroot00000000000000 Package McAfeeVSEForLinux Installed multi_platform_all McAfee Antivirus software should be installed. McAfeeVSEForLinux scap-security-guide-0.1.31/shared/oval/install_mcafee_cma_rt.xml000066400000000000000000000026611301675746700247330ustar00rootroot00000000000000 Install the McAfee Runtime Libraries and Linux Agent multi_platform_all Install the McAfee Runtime Libraries (MFErt) and Linux Agent (MFEcma). MFErt MFEcma scap-security-guide-0.1.31/shared/oval/install_mcafee_hbss.xml000066400000000000000000000015321301675746700244210ustar00rootroot00000000000000 Install McAfee Host-Based Intrusion Detection Software (HBSS) multi_platform_all McAfee Host-Based Intrusion Detection Software (HBSS) software should be installed. scap-security-guide-0.1.31/shared/oval/install_mcafee_hbss_accm.xml000066400000000000000000000016441301675746700254100ustar00rootroot00000000000000 Install the Asset Configuration Compliance Module (ACCM) multi_platform_all Install the Asset Configuration Compliance Module (ACCM). /opt/McAfee/accm/bin accm scap-security-guide-0.1.31/shared/oval/install_mcafee_hbss_hips.xml000066400000000000000000000020161301675746700254420ustar00rootroot00000000000000 Install the Host Intrusion Prevention System (HIPS) Module multi_platform_all Install the McAfee Host Intrusion Prevention System (HIPS) Module if it is absolutely necessary. If SELinux is enabled, do not install or enable this module. MFEhiplsm scap-security-guide-0.1.31/shared/oval/install_mcafee_hbss_pa.xml000066400000000000000000000016751301675746700251110ustar00rootroot00000000000000 Install the Policy Auditor (PA) Module multi_platform_all Install the Policy Auditor (PA) Module. /opt/McAfee/auditengine/bin auditmanager scap-security-guide-0.1.31/shared/oval/installed_OS_is_centos6.xml000066400000000000000000000023051301675746700251470ustar00rootroot00000000000000 CentOS 6 multi_platform_all The operating system installed on the system is CentOS 6 ^6.*$ centos-release scap-security-guide-0.1.31/shared/oval/installed_OS_is_centos7.xml000066400000000000000000000023241301675746700251510ustar00rootroot00000000000000 CentOS 7 multi_platform_all The operating system installed on the system is CentOS 7 ^7.*$ centos-release scap-security-guide-0.1.31/shared/oval/installed_OS_is_certified.xml000066400000000000000000000014641301675746700255310ustar00rootroot00000000000000 Vendor Certified Operating System multi_platform_rhel The operating system installed on the system is a certified vendor operating system and meets government requirements/certifications such as FIPS, NIAP, etc. scap-security-guide-0.1.31/shared/oval/installed_OS_is_debian8.xml000066400000000000000000000017441301675746700251060ustar00rootroot00000000000000 Debian 8 Debian8 The operating system installed on the system is Debian 8 /etc/debian_version ^8.[0-9]+$ 1 scap-security-guide-0.1.31/shared/oval/installed_OS_is_fedora.xml000066400000000000000000000037761301675746700250430ustar00rootroot00000000000000 Installed operating system is Fedora multi_platform_all The operating system installed on the system is Fedora fedora-release /etc/system-release-cpe ^cpe:\/o:fedoraproject:fedora:[\d]+$ 1 scap-security-guide-0.1.31/shared/oval/installed_OS_is_part_of_Unix_family.xml000066400000000000000000000020241301675746700275620ustar00rootroot00000000000000 Installed operating system is part of the Unix family multi_platform_all The operating system installed on the system is part of the Unix OS family unix scap-security-guide-0.1.31/shared/oval/installed_OS_is_rhel6.xml000066400000000000000000000053101301675746700246050ustar00rootroot00000000000000 Red Hat Enterprise Linux 6 multi_platform_all The operating system installed on the system is Red Hat Enterprise Linux 6 ^6.*$ redhat-release-workstation ^6.*$ redhat-release-server ^6.*$ redhat-release-computenode scap-security-guide-0.1.31/shared/oval/installed_OS_is_rhel7.xml000066400000000000000000000062151301675746700246130ustar00rootroot00000000000000 Red Hat Enterprise Linux 7 multi_platform_all The operating system installed on the system is Red Hat Enterprise Linux 7 unix ^7.*$ redhat-release-workstation ^7.*$ redhat-release-server ^7.*$ redhat-release-computenode scap-security-guide-0.1.31/shared/oval/installed_OS_is_sl6.xml000066400000000000000000000023431301675746700242740ustar00rootroot00000000000000 Scientific Linux 6 multi_platform_all The operating system installed on the system is Scientific Linux 6 ^6.*$ sl-release scap-security-guide-0.1.31/shared/oval/installed_OS_is_sl7.xml000066400000000000000000000023431301675746700242750ustar00rootroot00000000000000 Scientific Linux 7 multi_platform_all The operating system installed on the system is Scientific Linux 7 ^7.*$ sl-release scap-security-guide-0.1.31/shared/oval/installed_OS_is_sle11.xml000066400000000000000000000047431301675746700245230ustar00rootroot00000000000000 SUSE Linux Enterprise 11 multi_platform_sle The operating system installed on the system is SUSE Linux Enterprise 11. unix ^11.*$ sled-release ^11.*$ sles-release scap-security-guide-0.1.31/shared/oval/installed_OS_is_sle12.xml000066400000000000000000000047431301675746700245240ustar00rootroot00000000000000 SUSE Linux Enterprise 12 multi_platform_sle The operating system installed on the system is SUSE Linux Enterprise 12. unix ^12.*$ sled-release ^12.*$ sles-release scap-security-guide-0.1.31/shared/oval/installed_OS_is_ubuntu1604.xml000066400000000000000000000043571301675746700254340ustar00rootroot00000000000000 Ubuntu 16.04 multi_platform_ubuntu The operating system installed on the system is Ubuntu 16.04 /etc/lsb-release /etc/lsb-release ^DISTRIB_ID=Ubuntu$ 1 /etc/lsb-release ^DISTRIB_CODENAME=xenial$ 1 scap-security-guide-0.1.31/shared/oval/installed_OS_is_wrlinux.xml000066400000000000000000000030311301675746700252730ustar00rootroot00000000000000 WRLinux multi_platform_all The operating system installed on the system is Wind River Linux unix /etc/wrlinux-release scap-security-guide-0.1.31/shared/oval/kernel_module_dccp_disabled.xml000066400000000000000000000107401301675746700261020ustar00rootroot00000000000000 Disable dccp Kernel Module Red Hat Enterprise Linux 7 multi_platform_fedora The kernel module dccp should be disabled. /etc/modprobe.d ^.*\.conf$ ^\s*install\s+dccp\s+(/bin/false|/bin/true)$ 1 /etc/modprobe.conf ^\s*install\s+dccp\s+(/bin/false|/bin/true)$ 1 /etc/modules-load.d ^.*\.conf$ ^\s*install\s+dccp\s+(/bin/false|/bin/true)$ 1 /run/modules-load.d ^.*\.conf$ ^\s*install\s+dccp\s+(/bin/false|/bin/true)$ 1 /usr/lib/modules-load.d ^.*\.conf$ ^\s*install\s+dccp\s+(/bin/false|/bin/true)$ 1 scap-security-guide-0.1.31/shared/oval/kernel_module_usb-storage_disabled.xml000066400000000000000000000114151301675746700274240ustar00rootroot00000000000000 Disable usb-storage Kernel Module Red Hat Enterprise Linux 7 multi_platform_fedora The kernel module usb-storage should be disabled. /etc/modprobe.d ^.*\.conf$ ^\s*install\s+usb-storage\s+(/bin/false|/bin/true)$ 1 /etc/modprobe.conf ^\s*install\s+usb-storage\s+(/bin/false|/bin/true)$ 1 /etc/modules-load.d ^.*\.conf$ ^\s*install\s+usb-storage\s+(/bin/false|/bin/true)$ 1 /run/modules-load.d ^.*\.conf$ ^\s*install\s+usb-storage\s+(/bin/false|/bin/true)$ 1 /usr/lib/modules-load.d ^.*\.conf$ ^\s*install\s+usb-storage\s+(/bin/false|/bin/true)$ 1 scap-security-guide-0.1.31/shared/oval/ldap_client_start_tls.xml000066400000000000000000000024221301675746700250100ustar00rootroot00000000000000 Configure LDAP to Use TLS for All Transactions Red Hat Enterprise Linux 7 Require the use of TLS for ldap clients. /etc/nslcd.conf ^[\s]*ssl[\s]+start_tls[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/ldap_client_tls_cacertpath.xml000066400000000000000000000040161301675746700257720ustar00rootroot00000000000000 Configure LDAP CA Certificate Path Red Hat Enterprise Linux 7 Require the use of TLS for ldap clients. /etc/nslcd.conf ^[\s]*tls_cacertdir[\s]+/etc/pki/tls/CA$ 1 /etc/nslcd.conf ^[\s]*tls_cacertfile[\s]+/etc/pki/tls/CA/.*\.(pem|crt)$ 1 scap-security-guide-0.1.31/shared/oval/logwatch_configured_hostlimit.xml000066400000000000000000000021511301675746700265430ustar00rootroot00000000000000 Ensure Logwatch HostLimit Configured multi_platform_rhel Test if HostLimit line in logwatch.conf is set appropriately. /etc/logwatch/conf/logwatch.conf ^[\s]HostLimit[\s]*=[\s]*no[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/logwatch_configured_splithosts.xml000066400000000000000000000021441301675746700267450ustar00rootroot00000000000000 Ensure Logwatch SplitHosts Configured multi_platform_rhel Check if SplitHosts line in logwatch.conf is set appropriately. /etc/logwatch/conf/logwatch.conf ^[\s]SplitHosts[\s]*=[\s]*yes[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/mount_option_dev_shm_nodev.xml000066400000000000000000000024251301675746700260700ustar00rootroot00000000000000 Add nodev Option to /dev/shm multi_platform_rhel multi_platform_fedora Legitimate character and block devices should not exist within temporary directories like /dev/shm. The nodev mount option should be specified for /dev/shm. /dev/shm nodev scap-security-guide-0.1.31/shared/oval/mount_option_dev_shm_noexec.xml000066400000000000000000000025231301675746700262350ustar00rootroot00000000000000 Add noexec Option to /dev/shm multi_platform_rhel multi_platform_fedora It can be dangerous to allow the execution of binaries from world-writable temporary storage directories such as /dev/shm. The noexec mount option prevents binaries from being executed out of /dev/shm. /dev/shm noexec scap-security-guide-0.1.31/shared/oval/mount_option_dev_shm_nosuid.xml000066400000000000000000000024621301675746700262570ustar00rootroot00000000000000 Add nosuid Option to /dev/shm multi_platform_rhel multi_platform_fedora The nosuid mount option should be set for temporary storage partitions such as /dev/shm. The suid/sgid permissions should not be required in these world-writable directories. /dev/shm nosuid scap-security-guide-0.1.31/shared/oval/mount_option_nodev_nonroot_local_partitions.xml000066400000000000000000000033741301675746700315730ustar00rootroot00000000000000 Add nodev Option to Non-Root Local Partitions multi_platform_rhel The nodev mount option prevents files from being interpreted as character or block devices. Legitimate character and block devices should exist in the /dev directory on the root partition or within chroot jails built for system services. All other locations should not allow character and block devices. ^/\w.*$ state_local_nodev ^/dev/.*$ nodev scap-security-guide-0.1.31/shared/oval/mount_option_nodev_remote_filesystems.xml000066400000000000000000000047531301675746700303730ustar00rootroot00000000000000 Mount Remote Filesystems with nodev multi_platform_rhel The nodev option should be enabled for all NFS mounts in /etc/fstab. /etc/fstab ^\s*\[?[\.\w-:]+\]?:[/\w-]+\s+[/\w-]+\s+nfs[4]?\s+(.*)$ 0 ^.*nodev.*$ /etc/fstab ^\s*\[?[\.\w-:]+\]?:[/\w-]+\s+[/\w-]+\s+nfs[4]?\s+.*$ 0 scap-security-guide-0.1.31/shared/oval/mount_option_nodev_removable_partitions.xml000066400000000000000000000220341301675746700306710ustar00rootroot00000000000000 Add nodev Option to Removable Media Partitions multi_platform_rhel The nodev mount option prevents files from being interpreted as character or block devices. Legitimate character and block devices should exist in the /dev directory on the root partition or within chroot jails built for system services. All other locations should not allow character and block devices. /dev/cdrom /dev/dvd /dev/scd0 /dev/sr0 ^[\s]* [\s]+[/\w]+[\s]+[\w]+[\s]+([^\s]+)(?:[\s]+[\d]+){2}$ /etc/fstab 1 ^.*,?nodev,?.*$ ^.*$ state_nodev_runtime_cd_dvd_drive nodev ^[\s]* [\s]+[/\w]+[\s]+[\w]+[\s]+([^\s]+)(?:[\s]+[\d]+){2}$ /etc/fstab 1 ^.*,?nodev,?.* ^.*$ state_nodev_runtime_not_cd_dvd_drive nodev scap-security-guide-0.1.31/shared/oval/mount_option_noexec_removable_partitions.xml000066400000000000000000000222471301675746700310450ustar00rootroot00000000000000 Add noexec Option to Removable Media Partitions multi_platform_rhel The noexec mount option prevents the direct execution of binaries on the mounted filesystem. Users should not be allowed to execute binaries that exist on partitions mounted from removable media (such as a USB key). The noexec option prevents code from being executed directly from the media itself, and may therefore provide a line of defense against certain types of worms or malicious code. /dev/cdrom /dev/dvd /dev/scd0 /dev/sr0 ^[\s]* [\s]+[/\w]+[\s]+[\w]+[\s]+([^\s]+)(?:[\s]+[\d]+){2}$ /etc/fstab 1 ^.*,?noexec,?.*$ ^.*$ state_noexec_runtime_cd_dvd_drive noexec ^[\s]* [\s]+[/\w]+[\s]+[\w]+[\s]+([^\s]+)(?:[\s]+[\d]+){2}$ /etc/fstab 1 ^.*,?noexec,?.* ^.*$ state_noexec_runtime_not_cd_dvd_drive noexec scap-security-guide-0.1.31/shared/oval/mount_option_nosuid_remote_filesystems.xml000066400000000000000000000047731301675746700305630ustar00rootroot00000000000000 Mount Remote Filesystems with nosuid multi_platform_rhel The nosuid option should be enabled for all NFS mounts in /etc/fstab. /etc/fstab ^\s*\[?[\.\w-:]+\]?:[/\w-]+\s+[/\w-]+\s+nfs[4]?\s+(.*)$ 0 ^.*nosuid.*$ /etc/fstab ^\s*\[?[\.\w-:]+\]?:[/\w-]+\s+[/\w-]+\s+nfs[4]?\s+.*$ 0 scap-security-guide-0.1.31/shared/oval/mount_option_nosuid_removable_partitions.xml000066400000000000000000000222211301675746700310550ustar00rootroot00000000000000 Add nosuid Option to Removable Media Partitions multi_platform_rhel The nosuid mount option prevents set-user-identifier (suid) and set-group-identifier (sgid) permissions from taking effect. These permissions allow users to execute binaries with the same permissions as the owner and group of the file respectively. Users should not be allowed to introduce suid and guid files into the system via partitions mounted from removeable media. /dev/cdrom /dev/dvd /dev/scd0 /dev/sr0 ^[\s]* [\s]+[/\w]+[\s]+[\w]+[\s]+([^\s]+)(?:[\s]+[\d]+){2}$ /etc/fstab 1 ^.*,?nosuid,?.*$ ^.*$ state_nosuid_runtime_cd_dvd_drive nosuid ^[\s]* [\s]+[/\w]+[\s]+[\w]+[\s]+([^\s]+)(?:[\s]+[\d]+){2}$ /etc/fstab 1 ^.*,?nosuid,?.* ^.*$ state_nosuid_runtime_not_cd_dvd_drive nosuid scap-security-guide-0.1.31/shared/oval/mount_option_smb_client_signing.xml000066400000000000000000000062411301675746700271050ustar00rootroot00000000000000 Require Client SMB Packet Signing, if using mount.cifs multi_platform_rhel Require packet signing of clients who mount Samba shares using the mount.cifs program (e.g., those who specify shares in /etc/fstab). To do so, ensure that signing options (either sec=krb5i or sec=ntlmv2i) are used. /etc/fstab ^[\s]*[\S]+[\s]+[\S]+[\s]+cifs[\s]+([\S]+) 1 2 sec=(krb5i|ntlmv2i) /etc/mtab ^[\s]*[\S]+[\s]+[\S]+[\s]+cifs[\s]+([\S]+) 1 scap-security-guide-0.1.31/shared/oval/mount_option_tmp_nodev.xml000066400000000000000000000023321301675746700252400ustar00rootroot00000000000000 Add nodev Option to /tmp multi_platform_rhel multi_platform_fedora Legitimate character and block devices should not exist within temporary directories like /tmp. The nodev mount option should be specified for /tmp. /tmp nodev scap-security-guide-0.1.31/shared/oval/mount_option_tmp_noexec.xml000066400000000000000000000023541301675746700254120ustar00rootroot00000000000000 Add noexec Option to /tmp multi_platform_rhel It can be dangerous to allow the execution of binaries from world-writable temporary storage directories such as /tmp. The noexec mount option prevents binaries from being executed out of /tmp. /tmp noexec scap-security-guide-0.1.31/shared/oval/mount_option_tmp_nosuid.xml000066400000000000000000000023731301675746700254330ustar00rootroot00000000000000 Add nosuid Option to /tmp multi_platform_rhel multi_platform_fedora The nosuid mount option should be set for temporary storage partitions such as /tmp. The suid/sgid permissions should not be required in these world-writable directories. /tmp nosuid scap-security-guide-0.1.31/shared/oval/mount_option_var_tmp_bind.xml000066400000000000000000000040171301675746700257130ustar00rootroot00000000000000 Bind Mount /var/tmp To /tmp multi_platform_rhel multi_platform_fedora The /var/tmp directory should be bind mounted to /tmp in order to consolidate temporary storage into one location protected by the same techniques as /tmp. /var/tmp /etc/mtab ^[\s]*/tmp[\s]+/var/tmp[\s]+.*bind.*$ 1 scap-security-guide-0.1.31/shared/oval/network_disable_zeroconf.xml000066400000000000000000000022001301675746700255060ustar00rootroot00000000000000 Disable Zeroconf Networking multi_platform_rhel Disable Zeroconf automatic route assignment in the 169.254.0.0 subnet. /etc/sysconfig/network ^[\s]*NOZEROCONF[\s]*=[\s]*yes 1 scap-security-guide-0.1.31/shared/oval/network_ipv6_default_gateway.xml000066400000000000000000000024401301675746700263150ustar00rootroot00000000000000 Manually Assign IPv6 Router Address Red Hat Enterprise Linux 7 Define default gateways for IPv6 traffic /etc/sysconfig/network-scripts ifcfg-.* ^IPV6_DEFAULTGW=.+$ 1 scap-security-guide-0.1.31/shared/oval/network_ipv6_disable_rpc.xml000066400000000000000000000035011301675746700254160ustar00rootroot00000000000000 Disable Support for RPC IPv6 multi_platform_rhel Disable ipv6 based rpc services /etc/netconfig ^udp6\s+tpi_clts\s+v\s+inet6\s+udp\s+-\s+-$ 1 /etc/netconfig ^tcp6\s+tpi_cots_ord\s+v\s+inet6\s+tcp\s+-\s+-$ 1 scap-security-guide-0.1.31/shared/oval/network_ipv6_privacy_extensions.xml000066400000000000000000000025431301675746700271100ustar00rootroot00000000000000 Enable Privacy Extensions for IPv6 Red Hat Enterprise Linux 7 Enable privacy extensions for IPv6 /etc/sysconfig/network-scripts ifcfg-.* ^IPV6_PRIVACY=rfc3041$ 1 scap-security-guide-0.1.31/shared/oval/network_ipv6_static_address.xml000066400000000000000000000025101301675746700261420ustar00rootroot00000000000000 Manually Assign Global IPv6 Address Red Hat Enterprise Linux 7 Manually configure addresses for IPv6 /etc/sysconfig/network-scripts ifcfg-.* ^IPV6ADDR=.+$ 1 scap-security-guide-0.1.31/shared/oval/network_sniffer_disabled.xml000066400000000000000000000021621301675746700254700ustar00rootroot00000000000000 Disable the network sniffer multi_platform_rhel Disable the network sniffer ^.*$ state_promisc PROMISC scap-security-guide-0.1.31/shared/oval/no_direct_root_logins.xml000066400000000000000000000034411301675746700250210ustar00rootroot00000000000000 Direct root Logins Not Allowed multi_platform_all Preventing direct root logins help ensure accountability for actions taken on the system using the root account. /etc/securetty ^.*$ 1 /etc/securetty ^$ 1 scap-security-guide-0.1.31/shared/oval/no_empty_passwords.xml000066400000000000000000000021411301675746700243700ustar00rootroot00000000000000 No nullok Option in /etc/pam.d/system-auth multi_platform_all The file /etc/pam.d/system-auth should not contain the nullok option /etc/pam.d/system-auth \s*nullok\s* 1 scap-security-guide-0.1.31/shared/oval/no_files_unowned_by_user.xml000066400000000000000000000040121301675746700255150ustar00rootroot00000000000000 Find files unowned by a user multi_platform_rhel All files should be owned by a user /etc/passwd ^[^:]+:[^:]+:([\d]+):[\d]+:[^:]*:[^:]+:[^:]*$ 1 / .* file_permissions_unowned_userid_list_match scap-security-guide-0.1.31/shared/oval/no_insecure_locks_exports.xml000066400000000000000000000022451301675746700257260ustar00rootroot00000000000000 Ensure insecure_locks is disabled multi_platform_all Allowing insecure file locking could allow for sensitive data to be viewed or edited by an unauthorized user. /etc/exports ^(.*?(\binsecure_locks\b)[^$]*)$ 1 scap-security-guide-0.1.31/shared/oval/no_netrc_files.xml000066400000000000000000000022031301675746700234210ustar00rootroot00000000000000 Verify No netrc Files Exist multi_platform_all The .netrc files contain login information used to auto-login into FTP servers and reside in the user's home directory. Any .netrc files should be removed. /home ^\.netrc$ scap-security-guide-0.1.31/shared/oval/no_rsh_trust_files.xml000066400000000000000000000044341301675746700243530ustar00rootroot00000000000000 No Legacy .rhosts Or hosts.equiv Files multi_platform_rhel There should not be any .rhosts or hosts.equiv files on the system. /root ^\.(r|s)hosts$ /home ^\.(r|s)hosts$ /etc ^s?hosts\.equiv$ scap-security-guide-0.1.31/shared/oval/no_shelllogin_for_systemaccounts.xml000066400000000000000000000370031301675746700273040ustar00rootroot00000000000000 System Accounts Do Not Run a Shell multi_platform_all The root account is the only system account that should have a login shell. /etc/login.defs .*\n(?!#|SYS_)(UID_MIN[\s]+[\d]+)\s*\n 1 /etc/login.defs .*\n[^#]*(SYS_UID_MIN[\s]+[\d]+)\s*\n 1 /etc/login.defs .*\n[^#]*(SYS_UID_MAX[\s]+[\d]+)\s*\n 1 /etc/passwd ^(?!root).*:x:([\d]+):[\d]+:[^:]*:[^:]*:(?!\/sbin\/nologin|\/bin\/sync|\/sbin\/shutdown|\/sbin\/halt).*$ 1 -1 -1 variable_default_range_quad_expr 0 -1 variable_reserved_range_quad_expr 0 -1 -1 variable_dynalloc_range_quad_expr 0 scap-security-guide-0.1.31/shared/oval/oval_5.11/000077500000000000000000000000001301675746700213165ustar00rootroot00000000000000scap-security-guide-0.1.31/shared/oval/oval_5.11/chronyd_specify_multiple_servers.xml000066400000000000000000000023661301675746700307230ustar00rootroot00000000000000 Specify Multiple Remote chronyd NTP Servers for Time Data Red Hat Enterprise Linux 7 multi_platform_fedora Multiple chronyd NTP Servers for time synchronization should be specified. /etc/chrony.conf ^([\s]*server[\s]+.+$){2,}$ 1 scap-security-guide-0.1.31/shared/oval/oval_5.11/chronyd_specify_remote_server.xml000066400000000000000000000023371301675746700301760ustar00rootroot00000000000000 Specify a Remote NTP Server for Time Data Red Hat Enterprise Linux 7 multi_platform_fedora A remote NTP Server for time synchronization should be specified (and dependencies are met) /etc/chrony.conf ^[\s]*server[\s]+.+$ 1 scap-security-guide-0.1.31/shared/oval/oval_5.11/disable_ctrlaltdel_reboot.xml000066400000000000000000000027071301675746700272350ustar00rootroot00000000000000 Disable Ctrl-Alt-Del Reboot Activation Red Hat Enterprise Linux 7 multi_platform_fedora By default, the system will reboot when the Ctrl-Alt-Del key sequence is pressed. /etc/systemd/system/ctrl-alt-del.target /etc/systemd/system/ctrl-alt-del.target /dev/null scap-security-guide-0.1.31/shared/oval/oval_5.11/dovecot_disable_plaintext_auth.xml000066400000000000000000000025511301675746700303020ustar00rootroot00000000000000 Disable Plaintext Authentication in Dovecot Red Hat Enterprise Linux 7 Plaintext authentication of mail clients should be disabled. /etc/dovecot/conf.d/10-auth.conf ^[\s]*disable_plaintext_auth[\s]*=[\s]*yes[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/oval_5.11/dovecot_enable_ssl.xml000066400000000000000000000023341301675746700256740ustar00rootroot00000000000000 Enable SSL in Dovecot Red Hat Enterprise Linux 7 SSL capabilities should be enabled for the mail server. /etc/dovecot/conf.d/10-ssl.conf ^[\s]*ssl[\s]*=[\s]*(yes|required)[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/oval_5.11/ntpd_specify_multiple_servers.xml000066400000000000000000000022331301675746700302130ustar00rootroot00000000000000 Specify Multiple Remote ntpd NTP Server for Time Data Red Hat Enterprise Linux 7 Multiple ntpd NTP Servers for time synchronization should be specified. /etc/ntp.conf ^([\s]*server[\s]+.+$){2,}$ 1 scap-security-guide-0.1.31/shared/oval/oval_5.11/ntpd_specify_remote_server.xml000066400000000000000000000022411301675746700274670ustar00rootroot00000000000000 Specify a Remote ntpd NTP Server for Time Data Red Hat Enterprise Linux 7 A remote ntpd NTP Server for time synchronization should be specified (and dependencies are met) /etc/ntp.conf ^[\s]*server[\s]+.+$ 1 scap-security-guide-0.1.31/shared/oval/oval_5.11/package_audit_installed.xml000066400000000000000000000017571301675746700266720ustar00rootroot00000000000000 Package audit Installed Red Hat Enterprise Linux 7 multi_platform_fedora The RPM package audit should be installed. audit scap-security-guide-0.1.31/shared/oval/oval_5.11/package_chrony_installed.xml000066400000000000000000000017711301675746700270620ustar00rootroot00000000000000 Package chrony Installed Red Hat Enterprise Linux 7 multi_platform_fedora The RPM package chrony should be installed. chrony scap-security-guide-0.1.31/shared/oval/oval_5.11/package_cronie_installed.xml000066400000000000000000000016511301675746700270340ustar00rootroot00000000000000 Package cronie Installed Red Hat Enterprise Linux 7 multi_platform_fedora The RPM package cronie should be installed. cronie scap-security-guide-0.1.31/shared/oval/oval_5.11/package_firewalld_installed.xml000066400000000000000000000020271301675746700275240ustar00rootroot00000000000000 Package firewalld Installed Red Hat Enterprise Linux 7 multi_platform_fedora The RPM package firewalld should be installed. firewalld scap-security-guide-0.1.31/shared/oval/oval_5.11/postfix_network_listening_disabled.xml000066400000000000000000000030501301675746700312060ustar00rootroot00000000000000 Postfix network listening should be disabled Red Hat Enterprise Linux 7 Postfix network listening should be disabled /etc/postfix/main.cf ^[\s]*inet_interfaces[\s]*=[\s]*localhost[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/oval_5.11/rsyslog_files_groupownership.xml000066400000000000000000000116671301675746700301120ustar00rootroot00000000000000 Confirm Existence and Permissions of System Log Files multi_platform_rhel multi_platform_fedora All syslog log files should be owned by the appropriate group. /etc/rsyslog.conf ^\$IncludeConfig[\s]+([^\s;]+) 1 %/etc/rsyslog.conf ^[^(\s|#|\$)]+[\s]+.*[\s]+-?(/+[^:;\s]+);*.*$ 1 regular 0 scap-security-guide-0.1.31/shared/oval/oval_5.11/rsyslog_files_ownership.xml000066400000000000000000000117571301675746700270350ustar00rootroot00000000000000 Confirm Existence and Permissions of System Log Files multi_platform_rhel multi_platform_fedora multi_platform_debian multi_platform_ubuntu All syslog log files should be owned by the appropriate user. /etc/rsyslog.conf ^\$IncludeConfig[\s]+([^\s;]+) 1 %/etc/rsyslog.conf ^[^(\s|#|\$)]+[\s]+.*[\s]+-?(/+[^:;\s]+);*.*$ 1 regular 0 scap-security-guide-0.1.31/shared/oval/oval_5.11/rsyslog_files_permissions.xml000066400000000000000000000123341301675746700273620ustar00rootroot00000000000000 Confirm Existence and Permissions of System Log Files multi_platform_rhel multi_platform_fedora File permissions for all syslog log files should be set correctly. /etc/rsyslog.conf ^\$IncludeConfig[\s]+([^\s;]+) 1 %/etc/rsyslog.conf ^[^(\s|#|\$)]+[\s]+.*[\s]+-?(/+[^:;\s]+);*.*$ 1 regular false false false false false false false scap-security-guide-0.1.31/shared/oval/oval_5.11/service_dovecot_disabled.xml000066400000000000000000000041551301675746700270570ustar00rootroot00000000000000 Service dovecot Disabled Red Hat Enterprise Linux 7 The dovecot service should be disabled if possible. multi-user.target dovecot.service scap-security-guide-0.1.31/shared/oval/oval_5.11/xwindows_runlevel_setting.xml000066400000000000000000000030031301675746700273670ustar00rootroot00000000000000 Disable X Windows Startup By Setting Default SystemD Target Red Hat Enterprise Linux 7 multi_platform_fedora Checks /etc/systemd/system/default.target to ensure that the default runlevel target is set to multi-user.target. /etc/systemd/system/default.target /etc/systemd/system/default.target /lib/systemd/system/multi-user.target$ scap-security-guide-0.1.31/shared/oval/package_aide_installed.xml000066400000000000000000000015331301675746700250510ustar00rootroot00000000000000 Package aide Installed multi_platform_rhel The RPM package aide should be installed. aide scap-security-guide-0.1.31/shared/oval/package_audit_installed.xml000066400000000000000000000021701301675746700252530ustar00rootroot00000000000000 Package audit Installed CentOS 4 CentOS 5 Red Hat Enterprise Linux 4 Red Hat Enterprise Linux 5 Red Hat Enterprise Linux 6 The RPM package audit should be installed. audit scap-security-guide-0.1.31/shared/oval/package_bind_removed.xml000066400000000000000000000016301301675746700245430ustar00rootroot00000000000000 Package bind Removed multi_platform_rhel The RPM package bind should be removed. bind scap-security-guide-0.1.31/shared/oval/package_dconf_installed.xml000066400000000000000000000017571301675746700252500ustar00rootroot00000000000000 Package dconf Installed Red Hat Enterprise Linux 7 multi_platform_fedora The RPM package dconf should be installed. dconf scap-security-guide-0.1.31/shared/oval/package_dhcp_removed.xml000066400000000000000000000016301301675746700245450ustar00rootroot00000000000000 Package dhcp Removed multi_platform_rhel The RPM package dhcp should be removed. dhcp scap-security-guide-0.1.31/shared/oval/package_dovecot_removed.xml000066400000000000000000000016661301675746700253030ustar00rootroot00000000000000 Package dovecot Removed multi_platform_rhel The RPM package dovecot should be removed. dovecot scap-security-guide-0.1.31/shared/oval/package_dracut-fips_installed.xml000066400000000000000000000021131301675746700263630ustar00rootroot00000000000000 Package dracut-fips Installed Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 The RPM package dracut-fips should be installed. dracut-fips scap-security-guide-0.1.31/shared/oval/package_gdm_installed.xml000066400000000000000000000016131301675746700247150ustar00rootroot00000000000000 Package gdm Installed Red Hat Enterprise Linux 7 multi_platform_fedora The RPM package gdm should be installed. gdm scap-security-guide-0.1.31/shared/oval/package_httpd_removed.xml000066400000000000000000000016421301675746700247550ustar00rootroot00000000000000 Package httpd Removed multi_platform_rhel The RPM package httpd should be removed. httpd scap-security-guide-0.1.31/shared/oval/package_libreswan_installed.xml000066400000000000000000000017441301675746700261410ustar00rootroot00000000000000 Package libreswan Installed Red Hat Enterprise Linux 7 The RPM package libreswan should be installed. libreswan scap-security-guide-0.1.31/shared/oval/package_mcstrans_removed.xml000066400000000000000000000017001301675746700254570ustar00rootroot00000000000000 Package mcstrans Removed multi_platform_rhel The RPM package mcstrans should be removed. mcstrans scap-security-guide-0.1.31/shared/oval/package_net-snmp_removed.xml000066400000000000000000000016771301675746700254030ustar00rootroot00000000000000 Package net-snmp Removed multi_platform_all The RPM package net-snmp should be removed. net-snmp scap-security-guide-0.1.31/shared/oval/package_nss-pam-ldapd_removed.xml000066400000000000000000000017711301675746700262750ustar00rootroot00000000000000 Package nss-pam-ldapd Removed Red Hat Enterprise Linux 7 The RPM package nss-pam-ldapd should be removed. nss-pam-ldapd scap-security-guide-0.1.31/shared/oval/package_ntp_installed.xml000066400000000000000000000021441301675746700247470ustar00rootroot00000000000000 Package ntp Installed CentOS 4 CentOS 5 Red Hat Enterprise Linux 4 Red Hat Enterprise Linux 5 Red Hat Enterprise Linux 6 The RPM package ntp should be installed. ntp scap-security-guide-0.1.31/shared/oval/package_openldap-servers_removed.xml000066400000000000000000000020201301675746700271120ustar00rootroot00000000000000 Package openldap-servers Removed multi_platform_rhel The RPM package openldap-servers should be removed. openldap-servers scap-security-guide-0.1.31/shared/oval/package_openssh-server_removed.xml000066400000000000000000000021371301675746700266150ustar00rootroot00000000000000 Package openssh-server Removed multi_platform_rhel multi_platform_fedora multi_platform_sle The RPM package openssh-server should be removed. openssh-server scap-security-guide-0.1.31/shared/oval/package_prelink_removed.xml000066400000000000000000000016631301675746700253010ustar00rootroot00000000000000 Package prelink Removed multi_platform_all The RPM package prelink should be removed. prelink scap-security-guide-0.1.31/shared/oval/package_rsh-server_removed.xml000066400000000000000000000017241301675746700257330ustar00rootroot00000000000000 Package rsh-server Removed multi_platform_rhel The RPM package rsh-server should be removed. rsh-server scap-security-guide-0.1.31/shared/oval/package_rsh_removed.xml000066400000000000000000000016161301675746700244270ustar00rootroot00000000000000 Package rsh Removed multi_platform_rhel The RPM package rsh should be removed. rsh scap-security-guide-0.1.31/shared/oval/package_rsyslog_installed.xml000066400000000000000000000017111301675746700256470ustar00rootroot00000000000000 Package rsyslog Installed multi_platform_rhel The RPM package rsyslog should be installed. rsyslog scap-security-guide-0.1.31/shared/oval/package_samba-common_installed.xml000066400000000000000000000016531301675746700265230ustar00rootroot00000000000000 Package samba-common Installed multi_platform_rhel The RPM package samba-common should be installed. samba-common scap-security-guide-0.1.31/shared/oval/package_samba-common_removed.xml000066400000000000000000000017501301675746700262030ustar00rootroot00000000000000 Package samba-common Removed multi_platform_rhel The RPM package samba-common should be removed. samba-common scap-security-guide-0.1.31/shared/oval/package_screen_installed.xml000066400000000000000000000016771301675746700254370ustar00rootroot00000000000000 Package screen Installed multi_platform_rhel The RPM package screen should be installed. screen scap-security-guide-0.1.31/shared/oval/package_sendmail_removed.xml000066400000000000000000000017001301675746700254210ustar00rootroot00000000000000 Package sendmail Removed multi_platform_rhel The RPM package sendmail should be removed. sendmail scap-security-guide-0.1.31/shared/oval/package_setroubleshoot_removed.xml000066400000000000000000000017741301675746700267210ustar00rootroot00000000000000 Package setroubleshoot Removed multi_platform_rhel The RPM package setroubleshoot should be removed. setroubleshoot scap-security-guide-0.1.31/shared/oval/package_squid_removed.xml000066400000000000000000000016421301675746700247570ustar00rootroot00000000000000 Package squid Removed multi_platform_rhel The RPM package squid should be removed. squid scap-security-guide-0.1.31/shared/oval/package_talk-server_removed.xml000066400000000000000000000016161301675746700260720ustar00rootroot00000000000000 Package talk-server Removed multi_platform_rhel The RPM package talk-server should be removed. talk-server scap-security-guide-0.1.31/shared/oval/package_talk_removed.xml000066400000000000000000000015101301675746700245570ustar00rootroot00000000000000 Package talk Removed multi_platform_rhel The RPM package talk should be removed. talk scap-security-guide-0.1.31/shared/oval/package_telnet-server_removed.xml000066400000000000000000000017621301675746700264340ustar00rootroot00000000000000 Package telnet-server Removed multi_platform_rhel The RPM package telnet-server should be removed. telnet-server scap-security-guide-0.1.31/shared/oval/package_telnet_removed.xml000066400000000000000000000016541301675746700251300ustar00rootroot00000000000000 Package telnet Removed multi_platform_rhel The RPM package telnet should be removed. telnet scap-security-guide-0.1.31/shared/oval/package_tftp-server_removed.xml000066400000000000000000000017361301675746700261170ustar00rootroot00000000000000 Package tftp-server Removed multi_platform_rhel The RPM package tftp-server should be removed. tftp-server scap-security-guide-0.1.31/shared/oval/package_tftp_removed.xml000066400000000000000000000016301301675746700246040ustar00rootroot00000000000000 Package tftp Removed multi_platform_rhel The RPM package tftp should be removed. tftp scap-security-guide-0.1.31/shared/oval/package_vsftpd_installed.xml000066400000000000000000000017621301675746700254610ustar00rootroot00000000000000 Package vsftpd Installed multi_platform_rhel multi_platform_fedora The RPM package vsftpd should be installed. vsftpd scap-security-guide-0.1.31/shared/oval/package_vsftpd_removed.xml000066400000000000000000000016541301675746700251430ustar00rootroot00000000000000 Package vsftpd Removed multi_platform_rhel The RPM package vsftpd should be removed. vsftpd scap-security-guide-0.1.31/shared/oval/package_xinetd_removed.xml000066400000000000000000000016541301675746700251300ustar00rootroot00000000000000 Package xinetd Removed multi_platform_rhel The RPM package xinetd should be removed. xinetd scap-security-guide-0.1.31/shared/oval/package_xorg-x11-server-common_removed.xml000066400000000000000000000020571301675746700300130ustar00rootroot00000000000000 Package xorg-x11-server-common Removed multi_platform_rhel multi_platform_fedora The RPM package xorg-x11-server-common should be removed. xorg-x11-server-common scap-security-guide-0.1.31/shared/oval/package_ypbind_removed.xml000066400000000000000000000016541301675746700251220ustar00rootroot00000000000000 Package ypbind Removed multi_platform_rhel The RPM package ypbind should be removed. ypbind scap-security-guide-0.1.31/shared/oval/package_ypserv_removed.xml000066400000000000000000000016541301675746700251650ustar00rootroot00000000000000 Package ypserv Removed multi_platform_rhel The RPM package ypserv should be removed. ypserv scap-security-guide-0.1.31/shared/oval/partition_for_home.xml000066400000000000000000000021541301675746700243240ustar00rootroot00000000000000 Ensure /home Located On Separate Partition multi_platform_rhel If user home directories will be stored locally, create a separate partition for /home. If /home will be mounted from another system such as an NFS server, then creating a separate partition is not necessary at this time, and the mountpoint can instead be configured later. /home scap-security-guide-0.1.31/shared/oval/partition_for_tmp.xml000066400000000000000000000017031301675746700241730ustar00rootroot00000000000000 Ensure /tmp Located On Separate Partition multi_platform_rhel The /tmp directory is a world-writable directory used for temporary file storage. Verify that it has its own partition or logical volume. /tmp scap-security-guide-0.1.31/shared/oval/partition_for_var.xml000066400000000000000000000022241301675746700241620ustar00rootroot00000000000000 Ensure /var Located On Separate Partition multi_platform_rhel Ensuring that /var is mounted on its own partition enables the setting of more restrictive mount options, which is used as temporary storage by many program, particularly system services such as daemons. It is not uncommon for the /var directory to contain world-writable directories, installed by other software packages. /var scap-security-guide-0.1.31/shared/oval/partition_for_var_log.xml000066400000000000000000000017151301675746700250270ustar00rootroot00000000000000 Ensure /var/log Located On Separate Partition multi_platform_rhel System logs are stored in the /var/log directory. Ensure that it has its own partition or logical volume. /var/log scap-security-guide-0.1.31/shared/oval/partition_for_var_log_audit.xml000066400000000000000000000022201301675746700262050ustar00rootroot00000000000000 Ensure /var/log/audit Located On Separate Partition multi_platform_rhel Audit logs are stored in the /var/log/audit directory. Ensure that it has its own partition or logical volume. Make absolutely certain that it is large enough to store all audit logs that will be created by the auditing daemon. /var/log/audit scap-security-guide-0.1.31/shared/oval/postfix_server_banner.xml000066400000000000000000000021301301675746700250360ustar00rootroot00000000000000 Configure Postfix Against Unnecessary Release of Information multi_platform_rhel Protect against unnecessary release of information. /etc/postfix/main.cf ^[\s]*smtpd_banner[\s]*=[\s]*\$myhostname[\s]+ESMTP[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/removable_partition_doesnt_exist.xml000066400000000000000000000022751301675746700272760ustar00rootroot00000000000000 Device Files for Removable Media Partitions Does Not Exist on the System multi_platform_rhel Verify if device file representing removable partitions exist on the system scap-security-guide-0.1.31/shared/oval/require_singleuser_auth.xml000066400000000000000000000067011301675746700253740ustar00rootroot00000000000000 Require Authentication for Single-User Mode Red Hat Enterprise Linux 7 multi_platform_fedora The requirement for a password to boot into single-user mode should be configured correctly. /usr/lib/systemd/system/rescue.service ^ExecStart=\-.*/sbin/sulogin 1 /usr/lib/systemd/system/runlevel1.target ^Requires=.*rescue.service 1 /etc/systemd/system ^rescue.service$ /etc/systemd/system ^runlevel1.target$ scap-security-guide-0.1.31/shared/oval/require_smb_client_signing.xml000066400000000000000000000031401301675746700260220ustar00rootroot00000000000000 Require Client SMB Packet Signing in smb.conf multi_platform_rhel Require samba clients which use smb.conf, such as smbclient, to use packet signing. A Samba client should only communicate with servers who can support SMB packet signing. /etc/samba/smb.conf ^[\s]*client[\s]+signing[\s]*=[\s]*mandatory 1 scap-security-guide-0.1.31/shared/oval/restrict_serial_port_logins.xml000066400000000000000000000023401301675746700262470ustar00rootroot00000000000000 Restrict Serial Port Root Logins multi_platform_all Preventing direct root login to serial port interfaces helps ensure accountability for actions taken on the system using the root account. /etc/securetty ^ttyS[0-9]+$ 1 scap-security-guide-0.1.31/shared/oval/root_path_no_dot.xml000066400000000000000000000110561301675746700237770ustar00rootroot00000000000000 Ensure that No Dangerous Directories Exist in Root's Path multi_platform_rhel multi_platform_wrlinux The environment variable PATH should be set correctly for the root user. PATH ^[:\.] :: \.\. [:\.]$ ^[^/] [^\\]:[^/] scap-security-guide-0.1.31/shared/oval/rpm_verify_hashes.xml000066400000000000000000000053471301675746700241610ustar00rootroot00000000000000 Verify File Hashes with RPM multi_platform_fedora multi_platform_rhel :w Verify the RPM digests of system binaries using the RPM database. .* .* .* .* .* ^.*bin/.*$ state_files_fail_md5_hash fail scap-security-guide-0.1.31/shared/oval/rpm_verify_permissions.xml000066400000000000000000000102031301675746700252440ustar00rootroot00000000000000 Verify File Ownership And Permissions Using RPM multi_platform_rhel multi_platform_fedora Verify the integrity of installed packages by comparing the installed files with information about the files taken from the package metadata stored in the RPM database. .* .* .* .* .* .* state_files_fail_user_ownership .* .* .* .* .* .* state_files_fail_group_ownership .* .* .* .* .* .* state_files_fail_mode fail fail fail scap-security-guide-0.1.31/shared/oval/rsyslog_nolisten.xml000066400000000000000000000022051301675746700240470ustar00rootroot00000000000000 Disable Rsyslogd from Accepting Remote Messages on Loghosts Only multi_platform_rhel rsyslogd should reject remote messages /etc/rsyslog.conf ^[\s]*\$(?:Input(?:TCP|RELP)|UDP)ServerRun 1 scap-security-guide-0.1.31/shared/oval/rsyslog_remote_loghost.xml000066400000000000000000000036511301675746700252540ustar00rootroot00000000000000 Send Logs to a Remote Loghost multi_platform_rhel multi_platform_debian multi_platform_ubuntu Syslog logs should be sent to a remote loghost /etc/rsyslog.conf ^\*\.\*[\s]+(?:@|\:omrelp\:) 1 /etc/rsyslog.d .* ^\*\.\*[\s]+(?:@|\:omrelp\:) 1 scap-security-guide-0.1.31/shared/oval/securetty_root_login_console_only.xml000066400000000000000000000023711301675746700275030ustar00rootroot00000000000000 Restrict Virtual Console Root Logins multi_platform_all Preventing direct root login to virtual console devices helps ensure accountability for actions taken on the system using the root account. /etc/securetty ^vc/[0-9]+$ 1 scap-security-guide-0.1.31/shared/oval/selinux_all_devicefiles_labeled.xml000066400000000000000000000030761301675746700267720ustar00rootroot00000000000000 Device Files Have Proper SELinux Context Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 All device files in /dev should be assigned an SELinux security context other than 'device_t'. /dev ^.*$ state_selinux_all_devicefiles_labeled device_t scap-security-guide-0.1.31/shared/oval/selinux_confinement_of_daemons.xml000066400000000000000000000031701301675746700267020ustar00rootroot00000000000000 Ensure No Daemons are Unconfined by SELinux Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Wind River Linux 8 All pids in /proc should be assigned an SELinux security context other than 'initrc_t'. /proc ^.*$ state_selinux_confinement_of_daemons initrc_t scap-security-guide-0.1.31/shared/oval/selinux_policytype.xml000066400000000000000000000026671301675746700244160ustar00rootroot00000000000000 Enable SELinux multi_platform_rhel The SELinux policy should be set appropriately. /etc/selinux/config ^[\s]*SELINUXTYPE[\s]*=[\s]*([^\s]*) 1 scap-security-guide-0.1.31/shared/oval/selinux_state.xml000066400000000000000000000026311301675746700233240ustar00rootroot00000000000000 SELinux Enforcing multi_platform_rhel The SELinux state should be enforcing the local policy. /etc/selinux/config ^[\s]*SELINUX[\s]*=[\s]*(.*)[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/set_firewalld_default_zone.xml000066400000000000000000000022001301675746700260100ustar00rootroot00000000000000 Change the default firewalld zone to drop Red Hat Enterprise Linux 7 multi_platform_fedora Change the default firewalld zone to drop. /etc/firewalld/firewalld.conf ^DefaultZone=drop$ 1 scap-security-guide-0.1.31/shared/oval/set_password_hashing_algorithm_libuserconf.xml000066400000000000000000000024221301675746700313120ustar00rootroot00000000000000 Set SHA512 Password Hashing Algorithm in /etc/libuser.conf multi_platform_rhel The password hashing algorithm should be set correctly in /etc/libuser.conf. /etc/libuser.conf ^[\s]*crypt_style[\s]+=[\s]+(?i)sha512[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/set_password_hashing_algorithm_logindefs.xml000066400000000000000000000051631301675746700307560ustar00rootroot00000000000000 Set SHA512 Password Hashing Algorithm in /etc/login.defs multi_platform_rhel multi_platform_fedora The password hashing algorithm should be set correctly in /etc/login.defs. /etc/login.defs .*\n[^#]*(ENCRYPT_METHOD\s+\w+)\s*\n 1 variable_last_encrypt_method_instance_value SHA512 scap-security-guide-0.1.31/shared/oval/set_password_hashing_algorithm_systemauth.xml000066400000000000000000000023251301675746700312070ustar00rootroot00000000000000 Set Password Hashing Algorithm in /etc/pam.d/system-auth multi_platform_rhel The password hashing algorithm should be set correctly in /etc/pam.d/system-auth. /etc/pam.d/system-auth ^[\s]*password[\s]+(?:(?:required)|(?:sufficient))[\s]+pam_unix\.so[\s]+.*sha512.*$ 1 scap-security-guide-0.1.31/shared/oval/snmpd_not_default_password.xml000066400000000000000000000022611301675746700260630ustar00rootroot00000000000000 SNMP default communities disabled multi_platform_all SNMP default communities must be removed. /etc/snmp/snmpd.conf ^[\s]*(com2se|rocommunity|rwcommunity|createUser).*(public|private) 1 scap-security-guide-0.1.31/shared/oval/snmpd_use_newer_protocol.xml000066400000000000000000000021331301675746700255500ustar00rootroot00000000000000 SNMP use newer protocols multi_platform_all SNMP version 1 and 2c must not be enabled. /etc/snmp/snmpd.conf ^[\s]*(com2se|rocommunity|rwcommunity) 1 scap-security-guide-0.1.31/shared/oval/sshd_allow_only_protocol2.xml000066400000000000000000000027551301675746700256470ustar00rootroot00000000000000 Ensure Only Protocol 2 Connections Allowed multi_platform_rhel multi_platform_debian multi_platform_ubuntu The OpenSSH daemon should be running protocol 2. /etc/ssh/sshd_config ^[\s]*(?i)Protocol[\s]+2[\s]*(?:|(?:#.*))?$ 1 scap-security-guide-0.1.31/shared/oval/sshd_disable_empty_passwords.xml000066400000000000000000000027061301675746700264070ustar00rootroot00000000000000 Disable Empty Passwords multi_platform_all Remote connections from accounts with empty passwords should be disabled (and dependencies are met) /etc/ssh/sshd_config ^[\s]*(?i)PermitEmptyPasswords(?-i)[\s]+no[\s]*(?:|(?:#.*))?$ 1 scap-security-guide-0.1.31/shared/oval/sshd_disable_rhosts.xml000066400000000000000000000026201301675746700244610ustar00rootroot00000000000000 Disable .rhosts Files multi_platform_rhel Emulation of the rsh command through the ssh server should be disabled (and dependencies are met) /etc/ssh/sshd_config ^[\s]*(?i)IgnoreRhosts(?-i)[\s]+no[\s]*(?:|(?:#.*))?$ 1 scap-security-guide-0.1.31/shared/oval/sshd_disable_rhosts_rsa.xml000066400000000000000000000027721301675746700253360ustar00rootroot00000000000000 Disable SSH Support for Rhosts RSA Authentication multi_platform_all SSH can allow authentication through the obsolete rsh command through the use of the authenticating user's SSH keys. This should be disabled. /etc/ssh/sshd_config ^[\s]*(?i)RhostsRSAAuthentication(?-i)[\s]+no[\s]*(?:|(?:#.*))?$ 1 scap-security-guide-0.1.31/shared/oval/sshd_disable_root_login.xml000066400000000000000000000025741301675746700253220ustar00rootroot00000000000000 Disable root Login via SSH multi_platform_all Root login via SSH should be disabled (and dependencies are met) /etc/ssh/sshd_config ^[\s]*(?i)PermitRootLogin(?-i)[\s]+no[\s]*(?:|(?:#.*))?$ 1 scap-security-guide-0.1.31/shared/oval/sshd_disable_user_known_hosts.xml000066400000000000000000000027621301675746700265600ustar00rootroot00000000000000 Disable SSH Support for User Known Hosts multi_platform_all SSH can allow system users host-based authentication to connect to systems if a cache of the remote systems public keys are available. This should be disabled. /etc/ssh/sshd_config ^[\s]*(?i)IgnoreUserKnownHosts(?-i)[\s]+yes[\s]*(?:|(?:#.*))?$ 1 scap-security-guide-0.1.31/shared/oval/sshd_do_not_permit_user_env.xml000066400000000000000000000025041301675746700262250ustar00rootroot00000000000000 Do Not Allow Users to Set Environment Options multi_platform_rhel PermitUserEnvironment should be disabled /etc/ssh/sshd_config ^[\s]*(?i)PermitUserEnvironment(?-i)[\s]+no[\s]*(?:|(?:#.*))?$ 1 scap-security-guide-0.1.31/shared/oval/sshd_enable_warning_banner.xml000066400000000000000000000024561301675746700257630ustar00rootroot00000000000000 Enable a Warning Banner multi_platform_rhel SSH warning banner should be enabled (and dependencies are met) /etc/ssh/sshd_config ^[\s]*(?i)Banner(?-i)[\s]+/etc/issue[\s]*(?:|(?:#.*))?$ 1 scap-security-guide-0.1.31/shared/oval/sshd_set_idle_timeout.xml000066400000000000000000000040521301675746700250130ustar00rootroot00000000000000 Set OpenSSH Idle Timeout Interval multi_platform_all The SSH idle timeout interval should be set to an appropriate value. /etc/ssh/sshd_config ^[\s]*(?i)ClientAliveInterval[\s]+(\d+)[\s]*(?:|(?:#.*))?$ 1 0 scap-security-guide-0.1.31/shared/oval/sshd_set_keepalive.xml000066400000000000000000000032031301675746700242720ustar00rootroot00000000000000 Set ClientAliveCountMax for User Logins multi_platform_all The SSH ClientAliveCountMax should be set to an appropriate value (and dependencies are met) 0 /etc/ssh/sshd_config ^[\s]*(?i)ClientAliveCountMax[\s]+([\d]+)[\s]*(?:|(?:#.*))?$ 1 scap-security-guide-0.1.31/shared/oval/sshd_use_approved_ciphers.xml000066400000000000000000000031251301675746700256660ustar00rootroot00000000000000 Use Only Approved Ciphers multi_platform_rhel Limit the ciphers to those which are FIPS-approved and only use ciphers in counter (CTR) mode. /etc/ssh/sshd_config ^[\s]*(?i)Ciphers(?-i)[\s]+aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc[\s]*(?:|(?:#.*))?$ 1 scap-security-guide-0.1.31/shared/oval/sshd_use_approved_macs.xml000066400000000000000000000027641301675746700251640ustar00rootroot00000000000000 Use Only FIPS MACs multi_platform_rhel Limit the Message Authentication Codes (MACs) to those which are FIPS-approved. /etc/ssh/sshd_config ^[\s]*(?i)MACs(?-i)[\s]+hmac-sha2-512,hmac-sha2-256,hmac-sha1[\s]*(?:|(?:#.*))?$ 1 scap-security-guide-0.1.31/shared/oval/sysconfig_networking_bootproto_ifcfg.xml000066400000000000000000000031171301675746700301550ustar00rootroot00000000000000 Disable DHCP Client multi_platform_rhel DHCP configuration should be static for all interfaces. ^(static|none)$ /etc/sysconfig/network-scripts ifcfg-.* ^[\s]*BOOTPROTO[\s]*=[\s"]*([^#"\s]*) 1 scap-security-guide-0.1.31/shared/oval/sysctl_kernel_dmesg_restrict.xml000066400000000000000000000015721301675746700264170ustar00rootroot00000000000000 Kernel "kernel.dmesg_restrict" Parameter Configuration and Runtime Check multi_platform_rhel The "kernel.dmesg_restrict" kernel parameter should be set to "1" in both system configuration and system runtime. scap-security-guide-0.1.31/shared/oval/sysctl_kernel_exec_shield.xml000066400000000000000000000070341301675746700256540ustar00rootroot00000000000000 Kernel Runtime Parameter "kernel.exec-shield" Check Red Hat Enterprise Linux 7 multi_platform_fedora The kernel runtime parameter "kernel.exec-shield" should not be disabled and set to 1 on 32-bit systems. /etc/sysctl.conf ^[\s]*kernel.exec-shield[\s]*=[\s]*1[\s]*$ 1 kernel.exec-shield 1 /boot/grub2/grub.cfg [\s]*noexec[\s]*=[\s]*off 1 scap-security-guide-0.1.31/shared/oval/sysctl_kernel_ipv6_disable.xml000066400000000000000000000017471301675746700257540ustar00rootroot00000000000000 Kernel Runtime Parameter IPv6 Check Red Hat Enterprise Linux 7 multi_platform_fedora Disables IPv6 for all network interfaces. scap-security-guide-0.1.31/shared/oval/sysctl_kernel_randomize_va_space.xml000066400000000000000000000016561301675746700272350ustar00rootroot00000000000000 Kernel "kernel.randomize_va_space" Parameter Configuration and Runtime Check Red Hat Enterprise Linux 7 The "kernel.randomize_va_space" kernel parameter should be set to the appropriate value in both system configuration and system runtime. scap-security-guide-0.1.31/shared/oval/sysctl_runtime_kernel_dmesg_restrict.xml000066400000000000000000000025151301675746700301600ustar00rootroot00000000000000 Kernel "kernel.dmesg_restrict" Parameter Runtime Check multi_platform_rhel The kernel "kernel.dmesg_restrict" parameter should be set to "1" in system runtime. kernel.dmesg_restrict 1 scap-security-guide-0.1.31/shared/oval/sysctl_runtime_kernel_randomize_va_space.xml000066400000000000000000000026201301675746700307700ustar00rootroot00000000000000 Kernel "kernel.randomize_va_space" Parameter Runtime Check Red Hat Enterprise Linux 7 The kernel "kernel.randomize_va_space" parameter should be set to "2" in system runtime. kernel.randomize_va_space 2 scap-security-guide-0.1.31/shared/oval/sysctl_runtime_net_ipv6_conf_all_disable_ipv6.xml000066400000000000000000000027771301675746700316320ustar00rootroot00000000000000 Kernel "net.ipv6.conf.all.disable_ipv6" Parameter Runtime Check Red Hat Enterprise Linux 7 multi_platform_fedora The kernel "net.ipv6.conf.all.disable_ipv6" parameter should be set to "1" in system runtime. net.ipv6.conf.all.disable_ipv6 1 scap-security-guide-0.1.31/shared/oval/sysctl_static_kernel_dmesg_restrict.xml000066400000000000000000000145421301675746700277670ustar00rootroot00000000000000 Kernel "kernel.dmesg_restrict" Parameter Configuration Check multi_platform_rhel The kernel "kernel.dmesg_restrict" parameter should be set to "1" in the system configuration. /etc/sysctl.d ^.*$ (?:^|.*\n)[^#]*kernel.dmesg_restrict[\s]*=[\s]*(\d+)[\s]*\n 1 1 /etc/sysctl.conf (?:^|.*\n)[^#]*kernel.dmesg_restrict[\s]*=[\s]*(\d+)[\s]*\n 1 scap-security-guide-0.1.31/shared/oval/sysctl_static_kernel_randomize_va_space.xml000066400000000000000000000100321301675746700305700ustar00rootroot00000000000000 Kernel "kernel.randomize_va_space" Parameter Configuration Check Red Hat Enterprise Linux 7 The kernel "kernel.randomize_va_space" parameter should be set to "2" in the system configuration. /etc/sysctl.conf ^[\s]*kernel.randomize_va_space[\s]*=[\s]*2[\s]*$ 1 /etc/sysctl.d ^.*\.conf$ ^[\s]*kernel.randomize_va_space[\s]*=[\s]*2[\s]*$ 1 /run/sysctl.d ^.*\.conf$ ^[\s]*kernel.randomize_va_space[\s]*=[\s]*2[\s]*$ 1 /usr/lib/sysctl.d ^.*\.conf$ ^[\s]*kernel.randomize_va_space[\s]*=[\s]*2[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/sysctl_static_net_ipv6_conf_all_disable_ipv6.xml000066400000000000000000000103501301675746700314200ustar00rootroot00000000000000 Kernel "net.ipv6.conf.all.disable_ipv6" Parameter Configuration Check Red Hat Enterprise Linux 7 multi_platform_fedora The kernel "net.ipv6.conf.all.disable_ipv6" parameter should be set to "1" in the system configuration. /etc/sysctl.conf ^[\s]*net.ipv6.conf.all.disable_ipv6[\s]*=[\s]*1[\s]*$ 1 /etc/sysctl.d ^.*\.conf$ ^[\s]*net.ipv6.conf.all.disable_ipv6[\s]*=[\s]*1[\s]*$ 1 /run/sysctl.d ^.*\.conf$ ^[\s]*net.ipv6.conf.all.disable_ipv6[\s]*=[\s]*1[\s]*$ 1 /usr/lib/sysctl.d ^.*\.conf$ ^[\s]*net.ipv6.conf.all.disable_ipv6[\s]*=[\s]*1[\s]*$ 1 scap-security-guide-0.1.31/shared/oval/system_info_architecture_64bit.xml000066400000000000000000000015121301675746700265430ustar00rootroot00000000000000 Test for 64-bit Architecture multi_platform_all Generic test for 64-bit architectures to be used by other tests scap-security-guide-0.1.31/shared/oval/system_info_architecture_ppc_64.xml000066400000000000000000000037701301675746700267160ustar00rootroot00000000000000 Test for PPC and PPCLE Architecture multi_platform_all Generic test for PPC PPC64LE architecture to be used by other tests ppc64 ppc64le scap-security-guide-0.1.31/shared/oval/system_info_architecture_x86.xml000066400000000000000000000023441301675746700262440ustar00rootroot00000000000000 Test for x86 Architecture multi_platform_all Generic test for x86 architecture to be used by other tests i686 scap-security-guide-0.1.31/shared/oval/system_info_architecture_x86_64.xml000066400000000000000000000024041301675746700265520ustar00rootroot00000000000000 Test for x86_64 Architecture multi_platform_all Generic test for x86_64 architecture to be used by other tests x86_64 scap-security-guide-0.1.31/shared/oval/testoval.py000077500000000000000000000003461301675746700221320ustar00rootroot00000000000000#!/usr/bin/python import sys # always use shared/testoval_module.py version SHARED_MODULE_PATH = "../modules/" sys.path.insert(0, SHARED_MODULE_PATH) import testoval_module if __name__ == "__main__": testoval_module.main() scap-security-guide-0.1.31/shared/oval/tftpd_uses_secure_mode.xml000066400000000000000000000023021301675746700251620ustar00rootroot00000000000000 TFTP Daemon Uses Secure Mode multi_platform_rhel The TFTP daemon should use secure mode. /etc/xinetd.d/tftp ^[\s]*server_args[\s]+=[\s]+\-s[\s]+.+$ 1 scap-security-guide-0.1.31/shared/oval/umask_for_daemons.xml000066400000000000000000000101341301675746700241260ustar00rootroot00000000000000 Set Daemon umask multi_platform_rhel The daemon umask should be set as appropriate /etc/init.d/functions ^[\s]*(?i)UMASK(?-i)[\s]+([^#\s]*) 1 64 8 var_etc_init_d_functions_umask_as_number scap-security-guide-0.1.31/shared/oval/userowner_shadow_file.xml000066400000000000000000000021411301675746700250260ustar00rootroot00000000000000 Verify user who owns 'shadow' file multi_platform_rhel The /etc/shadow file should be owned by the appropriate user. 0 /etc/shadow scap-security-guide-0.1.31/shared/oval/var_accounts_user_umask_as_number.xml000066400000000000000000000067411301675746700274230ustar00rootroot00000000000000 Value of 'var_accounts_user_umask' variable represented as octal number multi_platform_rhel multi_platform_wrlinux Value of 'var_accounts_user_umask' variable represented as octal number 64 8 var_accounts_user_umask_umask_as_number scap-security-guide-0.1.31/shared/oval/var_removable_partition_is_cd_dvd_drive.xml000066400000000000000000000030021301675746700305320ustar00rootroot00000000000000 Value of 'var_removable_partition' variable is set to '/dev/cdrom' multi_platform_rhel Verify if value of 'var_removable_partition' variable is set to '/dev/cdrom' var_removable_partition /dev/cdrom scap-security-guide-0.1.31/shared/oval/var_umask_for_daemons_as_number.xml000066400000000000000000000065711301675746700270430ustar00rootroot00000000000000 Value of 'var_umask_for_daemons' variable represented as octal number multi_platform_rhel Value of 'var_umask_for_daemons' variable represented as octal number 64 8 var_umask_for_daemons_umask_as_number scap-security-guide-0.1.31/shared/oval/wireless_disable_interfaces.xml000066400000000000000000000020611301675746700261550ustar00rootroot00000000000000 Deactivate Wireless Interfaces multi_platform_rhel All wireless interfaces should be disabled. /proc/net/wireless ^\s*[-\w]+: 1 scap-security-guide-0.1.31/shared/product-make.include000066400000000000000000000307421301675746700227160ustar00rootroot00000000000000# # product-make.include # # The common Makefile snippets used by other Makefiles in various product subfolders # # The snippets assume that the following variables are set by each product: # * $(SHARED) # # # Include project level information include $(SHARED)/../VERSION # Defaults for the global variables - directories IN = input OUT = output BUILD = build TRANS = transforms SHARED_OVAL = $(SHARED)/oval SHARED_OVAL_5_11 = $(SHARED_OVAL)/oval_5.11 SHARED_BASH_REMEDIATIONS = $(BUILD)/shared/output/bash $(SHARED)/templates/static/bash # Currently we cannot build shared remediations only once SHARED_ANSIBLE_REMEDIATIONS = $(BUILD)/shared/output/ansible $(SHARED)/templates/static/ansible # Currently we cannot build shared remediations only once SHARED_ANACONDA_REMEDIATIONS = $(BUILD)/shared/output/anaconda $(SHARED)/templates/static/anaconda # Currently we cannot build shared remediations only once SHARED_PUPPET_REMEDIATIONS = $(BUILD)/shared/output/puppet $(SHARED)/templates/static/puppet # Currently we cannot build shared remediations only once PRODUCT_BASH_REMEDIATIONS = $(OUT)/bash PRODUCT_ANSIBLE_REMEDIATIONS = $(OUT)/ansible PRODUCT_ANACONDA_REMEDIATIONS = $(OUT)/anaconda PRODUCT_PUPPET_REMEDIATIONS = $(OUT)/puppet STANDARD_OVAL_DIRS = $(SHARED_OVAL) $(IN)/oval REFS = $(SHARED)/references CONF = $(SHARED)/../config UTILS = utils DIST = dist OVAL_VERSION=$(if $(filter $(OVAL_5_11),0),oval_5.11,oval_5.10) # Defaults for the global variables - others ID = ssg # Query environment - ask openscap if it can do OVAL 5.11 OVAL_5_11 := $(shell oscap --version | grep -q "OVAL Version: 5.11.*"; echo $$?) # Query environment - ask openscap if it can generate guide from DataStream OPENSCAP_1_1_OR_LATER := $(shell oscap --version | grep -q -E "OpenSCAP command line tool \(oscap\) 1\.[1-9]+[0-9]*\."; echo $$?) # Query environment - ask openscap if it has SVG support in guides OPENSCAP_SVG := $(shell $(SHARED)/$(UTILS)/oscap-svg-support.py; echo $$?) # Query environment - check shellcheck SHELLCHECK_AVAIL := $(shell which shellcheck >& /dev/null; echo $$?) # Common build targets - include the SSG logo into the XCCDF header $(OUT)/guide.xml: $(SHARED)/$(TRANS)/includelogo.xslt $(SHARED)/xccdf/shared_guide.xml ifeq ($(OPENSCAP_SVG), 0) xsltproc -o $(OUT)/guide.xml $(SHARED)/$(TRANS)/includelogo.xslt $(SHARED)/xccdf/shared_guide.xml else mkdir -p $(OUT)/ cp $(SHARED)/xccdf/shared_guide.xml $(OUT)/ endif # Common build targets - compose single shorthand XCCDF guide from all the sources guide_xslt_deps= $(wildcard $(IN)/auxiliary/*.xml) $(wildcard $(IN)/profiles/*.xml) $(wildcard $(IN)/xccdf/**/*.xml) $(OUT)/shorthand.xml: $(OUT)/guide.xml $(IN)/guide.xslt $(guide_xslt_deps) xsltproc --stringparam SHARED_RP "$(realpath $(SHARED))" -o $@ $(IN)/guide.xslt $(OUT)/guide.xml xmllint --format --output $@ $@ # Create temporary $(SHARED)/$(OUT) folder to hold information like list of contributors or list of # available remediation functions used by all SSG benchmarks $(SHARED)/$(OUT): mkdir -p $@ # Common build targets - convert shorthand format to an XCCDF stub $(OUT)/xccdf-unlinked-unresolved.xml: $(OUT)/shorthand.xml $(TRANS)/shorthand2xccdf.xslt $(TRANS)/constants.xslt $(SHARED)/$(TRANS)/shared_constants.xslt xsltproc --stringparam ssg_version "$(SSG_MAJOR_VERSION).$(SSG_MINOR_VERSION)" -o $@ $(TRANS)/shorthand2xccdf.xslt $< # Common build targets - improve the XCCDF stub - first resolve $(OUT)/xccdf-unlinked-empty-groups.xml: $(OUT)/xccdf-unlinked-unresolved.xml oscap xccdf resolve -o $@ $< # Common build targets - improve the XCCDF stub - second resolve $(OUT)/xccdf-unlinked-empty-groups-unselected.xml: $(OUT)/xccdf-unlinked-empty-groups.xml $(SHARED)/$(UTILS)/unselect-empty-xccdf-groups.py $(SHARED)/$(UTILS)/unselect-empty-xccdf-groups.py --input $< --output $@ # Common build targets - improve the XCCDF stub - third resolve $(OUT)/xccdf-unlinked-resolved.xml: $(OUT)/xccdf-unlinked-empty-groups-unselected.xml oscap xccdf resolve -o $@ $< # Common build targets - create OCIL questionnaire stub for further processing $(OUT)/ocil-unlinked.xml: $(OUT)/xccdf-unlinked-resolved.xml $(SHARED)/$(TRANS)/xccdf-create-ocil.xslt xsltproc -o $@ $(SHARED)/$(TRANS)/xccdf-create-ocil.xslt $< xmllint --format --output $(OUT)/unlinked-$(PROD)-ocil.xml $@ # Common build targets - an XCCDF witch OCIL checks in the form of official OCIL-2.0 syntax $(OUT)/xccdf-unlinked-ocilrefs.xml: $(OUT)/xccdf-unlinked-resolved.xml $(OUT)/ocil-unlinked.xml $(SHARED)/$(TRANS)/xccdf-ocilcheck2ref.xslt $(SHARED)/$(TRANS)/shared_constants.xslt xsltproc -stringparam product "$(PROD)" -o $@ $(SHARED)/$(TRANS)/xccdf-ocilcheck2ref.xslt $< $(PRODUCT_ANACONDA_REMEDIATIONS): $(SHARED)/utils/generate-from-templates.py --oval_version $(OVAL_VERSION) --input ./templates --output $(OUT) --language anaconda build $(PRODUCT_ANSIBLE_REMEDIATIONS): $(SHARED)/utils/generate-from-templates.py --oval_version $(OVAL_VERSION) --input ./templates --output $(OUT) --language ansible build $(PRODUCT_BASH_REMEDIATIONS): $(SHARED)/utils/generate-from-templates.py --oval_version $(OVAL_VERSION) --input ./templates --output $(OUT) --language bash build $(PRODUCT_PUPPET_REMEDIATIONS): $(SHARED)/utils/generate-from-templates.py --oval_version $(OVAL_VERSION) --input ./templates --output $(OUT) --language puppet build $(BUILD)/shared/output/anaconda: $(SHARED)/utils/generate-from-templates.py --oval_version $(OVAL_VERSION) --input $(SHARED)/templates --output $(BUILD)/shared/output --language anaconda build $(BUILD)/shared/output/ansible: $(SHARED)/utils/generate-from-templates.py --oval_version $(OVAL_VERSION) --input $(SHARED)/templates --output $(BUILD)/shared/output --language ansible build $(BUILD)/shared/output/bash: $(SHARED)/utils/generate-from-templates.py --oval_version $(OVAL_VERSION) --input $(SHARED)/templates --output $(BUILD)/shared/output --language bash build $(BUILD)/shared/output/puppet: $(SHARED)/utils/generate-from-templates.py --oval_version $(OVAL_VERSION) --input $(SHARED)/templates --output $(BUILD)/shared/output --language puppet build $(BUILD)/shared/output/oval: $(SHARED)/utils/generate-from-templates.py --oval_version $(OVAL_VERSION) --input $(SHARED)/templates --output $(BUILD)/shared/output --language oval build templates/static/bash: mkdir -p $@ templates/static/ansible: mkdir -p $@ templates/static/anaconda: mkdir -p $@ templates/static/puppet: mkdir -p $@ # Common build targets - a catalogue of XCCDF remediations product_bash_remediations_deps=$(wildcard templates/static/bash/*.sh) shared_bash_remediations_deps= $(wildcard $(SHARED_BASH_REMEDIATIONS)/*.sh) bash_remediations_deps= $(product_bash_remediations_deps) $(shared_bash_remediations_deps) $(OUT)/bash-remediations.xml: $(SHARED)/$(UTILS)/combine-remediations.py $(bash_remediations_deps) $(PRODUCT_BASH_REMEDIATIONS) $(BUILD)/shared/output/bash templates/static/bash $(SHARED)/$(UTILS)/combine-remediations.py $(PROD) bash $(SHARED_BASH_REMEDIATIONS) $(PRODUCT_BASH_REMEDIATIONS) templates/static/bash $(OUT)/bash-remediations.xml # Common build targets - a catalogue of XCCDF remediations product_anaconda_remediations_deps=$(wildcard templates/static/anaconda/*.anaconda) shared_anaconda_remediations_deps= $(wildcard $(SHARED_ANACONDA_REMEDIATIONS)/*.anaconda) anaconda_remediations_deps= $(product_anaconda_remediations_deps) $(shared_anaconda_remediations_deps) $(OUT)/anaconda-remediations.xml: $(SHARED)/$(UTILS)/combine-remediations.py $(anaconda_remediations_deps) $(PRODUCT_ANACONDA_REMEDIATIONS) $(BUILD)/shared/output/anaconda templates/static/anaconda $(SHARED)/$(UTILS)/combine-remediations.py $(PROD) anaconda $(SHARED_ANACONDA_REMEDIATIONS) $(PRODUCT_ANACONDA_REMEDIATIONS) templates/static/anaconda $(OUT)/anaconda-remediations.xml # Common build targets - a catalogue of XCCDF remediations product_ansible_remediations_deps=$(wildcard templates/static/ansible/*.sh) shared_ansible_remediations_deps= $(wildcard $(SHARED_ANSIBLE_REMEDIATIONS)/*.sh) ansible_remediations_deps= $(product_ansible_remediations_deps) $(shared_ansible_remediations_deps) $(OUT)/ansible-remediations.xml: $(SHARED)/$(UTILS)/combine-remediations.py $(ansible_remediations_deps) $(PRODUCT_ANSIBLE_REMEDIATIONS) $(BUILD)/shared/output/ansible templates/static/ansible $(SHARED)/$(UTILS)/combine-remediations.py $(PROD) ansible $(SHARED_ANSIBLE_REMEDIATIONS) $(PRODUCT_ANSIBLE_REMEDIATIONS) templates/static/ansible $(OUT)/ansible-remediations.xml # Common build targets - a catalogue of XCCDF remediations product_puppet_remediations_deps=$(wildcard templates/static/puppet/*.pp) shared_puppet_remediations_deps= $(wildcard $(SHARED_PUPPET_REMEDIATIONS)/*.pp) puppet_remediations_deps= $(product_puppet_remediations_deps) $(shared_puppet_remediations_deps) $(OUT)/puppet-remediations.xml: $(SHARED)/$(UTILS)/combine-remediations.py $(puppet_remediations_deps) $(PRODUCT_PUPPET_REMEDIATIONS) $(BUILD)/shared/output/puppet templates/static/puppet $(SHARED)/$(UTILS)/combine-remediations.py $(PROD) puppet $(SHARED_PUPPET_REMEDIATIONS) $(PRODUCT_PUPPET_REMEDIATIONS) templates/static/puppet $(OUT)/puppet-remediations.xml # Common build targets - an XCCDF with remediations but not linked to OVAL yet # Prefer "$(OUT)/xccdf-unlinked-ocilrefs.xml" document below since it contains OCIL expanded to official OCIL-2.0 syntax # Fixes: https://github.com/OpenSCAP/scap-security-guide/issues/1037 # Fixes: https://github.com/OpenSCAP/scap-security-guide/issues/1038 $(OUT)/xccdf-unlinked-withremediations.xml: $(OUT)/xccdf-unlinked-ocilrefs.xml $(OUT)/xccdf-unlinked-resolved.xml $(OUT)/bash-remediations.xml $(OUT)/ansible-remediations.xml $(OUT)/anaconda-remediations.xml $(OUT)/puppet-remediations.xml $(SHARED)/$(TRANS)/xccdf-addremediations.xslt xsltproc \ -stringparam bash_remediations "$(realpath $(OUT)/bash-remediations.xml)" \ -stringparam ansible_remediations "$(realpath $(OUT)/ansible-remediations.xml)" \ -stringparam anaconda_remediations "$(realpath $(OUT)/anaconda-remediations.xml)" \ -stringparam puppet_remediations "$(realpath $(OUT)/puppet-remediations.xml)" \ -o $@ $(SHARED)/$(TRANS)/xccdf-addremediations.xslt $(OUT)/xccdf-unlinked-ocilrefs.xml xmllint --format --output $@ $@ # Common build targets - OVAL files standard-oval-build: # If openscap on the system supports OVAL-5.11 language version, include also OVAL-5.11 checks # into final list of OVAL checks ifeq ($(OVAL_5_11), 0) # System supports OVAL-5.11 => propagate 'RUNTIME_OVAL_VERSION' variable into the environment $(eval MOD_ENV := env RUNTIME_OVAL_VERSION='5.11') $(eval STANDARD_OVAL_DIRS+=$(SHARED_OVAL_5_11) $(IN)/oval/oval_5.11) endif find $(OVAL_DIRS) -name "*.xml" | xargs xmlwf $(MOD_ENV) $(SHARED)/$(UTILS)/combine-ovals.py $(CONF) $(PROD) $(STANDARD_OVAL_DIRS) > $(OUT)/unlinked-$(PROD)-oval.xml xmllint --format --output $(OUT)/unlinked-$(PROD)-oval.xml $(OUT)/unlinked-$(PROD)-oval.xml validate-bash: ifeq ($(SHELLCHECK_AVAIL), 0) shellcheck -s bash $(product_bash_remediations_deps) else @echo "Skipping ShellCheck analysis, ensure shellcheck executable is present in the PATH!" endif # Sanity check to verify if intended remediations got truly included into the benchmark being currently build # # In the case "$(OUT)/bash-remediations.xml" contains at least one " Microsoft Office User 2015-11-19T18:37:37Z 15.0 96 17540 28720 80 460 False False ACCESS CONTROL AC-1 ACCESS CONTROL POLICY AND PROCEDURES ü The organization: a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]: 1. An access control policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and 2. Procedures to facilitate the implementation of the access control policy and associated access controls; and b. Reviews and updates the current: 1. Access control policy [Assignment: organization-defined frequency]; and 2. Access control procedures [Assignment: organization-defined frequency]. Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the AC family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9. Control Enhancements: None. References: NIST Special Publications 800-12, 800-100. ü ü AC-1.b.1 [at least every 3 years] AC-1.b.2 [at least annually] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 AC-1.b.1 [at least annually] AC-1.b.2 [at least every six months] ACCESS CONTROL AC-2 ACCOUNT MANAGEMENT ü The organization: a. Identifies and selects the following types of information system accounts to support organizational missions/business functions: [Assignment 1: organization-defined information system account types]; b. Assigns account managers for information system accounts; c. Establishes conditions for group and role membership; d. Specifies authorized users of the information system, group and role membership, and access authorizations (i.e., privileges) and other attributes (as required) for each account; e. Requires approvals by [Assignment 2: organization-defined personnel or roles] for requests to create information system accounts; f. Creates, enables, modifies, disables, and removes information system accounts in accordance with [Assignment 3: organization-defined procedures or conditions]; g. Monitors the use of, information system accounts; h. Notifies account managers: 1. When accounts are no longer required; 2. When users are terminated or transferred; and 3. When individual information system usage or need-to-know changes; i. Authorizes access to the information system based on: 1. A valid access authorization; 2. Intended system usage; and 3. Other attributes as required by the organization or associated missions/business functions; j. Reviews accounts for compliance with account management requirements [Assignment: organization-defined frequency]; and k. Establishes a process for reissuing shared/group account credentials (if deployed) when individuals are removed from the group. Supplemental Guidance: Information system account types include, for example, individual, shared, group, system, guest/anonymous, emergency, developer/manufacturer/vendor, temporary, and service. Some of the account management requirements listed above can be implemented by organizational information systems. The identification of authorized users of the information system and the specification of access privileges reflects the requirements in other security controls in the security plan. Users requiring administrative privileges on information system accounts receive additional scrutiny by appropriate organizational personnel (e.g., system owner, mission/business owner, or chief information security officer) responsible for approving such accounts and privileged access. Organizations may choose to define access privileges or other attributes by account, by type of account, or a combination of both. Other attributes required for authorizing access include, for example, restrictions on time-of-day, day-of-week, and point-of-origin. In defining other account attributes, organizations consider system-related requirements (e.g., scheduled maintenance, system upgrades) and mission/business requirements, (e.g., time zone differences, customer requirements, remote access to support travel requirements). Failure to consider these factors could affect information system availability. Temporary and emergency accounts are accounts intended for short-term use. Organizations establish temporary accounts as a part of normal account activation procedures when there is a need for short-term accounts without the demand for immediacy in account activation. Organizations establish emergency accounts in response to crisis situations and with the need for rapid account activation. Therefore, emergency account activation may bypass normal account authorization processes. Emergency and temporary accounts are not to be confused with infrequently used accounts (e.g., local logon accounts used for special tasks defined by organizations or when network resources are unavailable). Such accounts remain available and are not subject to automatic disabling or removal dates. Conditions for disabling or deactivating accounts include, for example: (i) when shared/group, emergency, or temporary accounts are no longer required; or (ii) when individuals are transferred or terminated. Some types of information system accounts may require specialized training. Rela ü ü AC-2.j [at least annually] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 ACCESS CONTROL AC-2 (1) ACCOUNT MANAGEMENT | AUTOMATED SYSTEM ACCOUNT MANAGEMENT The organization employs automated mechanisms to support the management of information system accounts. Supplemental Guidance: The use of automated mechanisms can include, for example: using email or text messaging to automatically notify account managers when users are terminated or transferred; using the information system to monitor account usage; and using telephonic notification to report atypical system account usage. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 ACCESS CONTROL AC-2 (2) ACCOUNT MANAGEMENT | REMOVAL OF TEMPORARY / EMERGENCY ACCOUNTS ü The information system automatically [Selection: removes; disables] temporary and emergency accounts after [Assignment: organization-defined time period for each type of account]. Supplemental Guidance: This control enhancement requires the removal of both temporary and emergency accounts automatically after a predefined period of time has elapsed, rather than at the convenience of the systems administrator. ü [no more than 30 days for temporary and emergency account types] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 [no more than 15 days for temporary and emergency account types] ACCESS CONTROL AC-2 (3) ACCOUNT MANAGEMENT | DISABLE INACTIVE ACCOUNTS ü The information system automatically disables inactive accounts after [Assignment: organization-defined time period]. ü [90 days for user accounts] Requirement: The service provider defines the time period for non-user accounts (e.g., accounts associated with devices). The time periods are approved and accepted by the Authorizing Official. ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 [35 days for user accounts] Requirement: The service provider defines the time period for non-user accounts (e.g., accounts associated with devices). The time periods are approved and accepted by the Authorizing Official. Where user management is a funtion of the service, reports of activity of consumer users shall be made available. ACCESS CONTROL AC-2 (4) ACCOUNT MANAGEMENT | AUTOMATED AUDIT ACTIONS ü The information system automatically audits account creation, modification, enabling, disabling, and removal actions, and notifies [Assignment: organization-defined personnel or roles]. Supplemental Guidance: Related controls: AU-2, AU-12. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 [organization and/or service provider system owner] ACCESS CONTROL AC-2 (5) ACCOUNT MANAGEMENT | INACTIVITY LOGOUT ü The organization requires that users log out when [Assignment: organization-defined time-period of expected inactivity or description of when to log out]. Supplemental Guidance: Related control: SC-23. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 [organization and service provider-defined time-period/description of when to log out] ACCESS CONTROL AC-2 (7) ACCOUNT MANAGEMENT | ROLE-BASED SCHEMES ü The organization: (a) Establishes and administers privileged user accounts in accordance with a role-based access scheme that organizes allowed information system access and privileges into roles; (b) Monitors privileged role assignments; and (c) Takes [Assignment: organization-defined actions] when privileged role assignments are no longer appropriate. Supplemental Guidance: Privileged roles are organization-defined roles assigned to individuals that allow those individuals to perform certain security-relevant functions that ordinary users are not authorized to perform. These privileged roles include, for example, key management, account management, network and system administration, database administration, and web administration. ü ü Included in FedRAMP Moderate Baseline, Rev 4 [Disable/remove access within a organization-specified timeframe] c. Disables (or revokes) privileged user account ACCESS CONTROL AC-2 (9) ACCOUNT MANAGEMENT | RESTRICTIONS ON USE OF SHARED GROUPS / ACCOUNTS ü The organization only permits the use of shared/group accounts that meet [Assignment: organization-defined conditions for establishing shared/group accounts]. ü Required if shared/group accounts are deployed ü Included in FedRAMP Moderate Baseline, Rev 4 ACCESS CONTROL AC-2 (10) ACCOUNT MANAGEMENT | SHARED / GROUP ACCOUNT CREDENTIAL TERMINATION The information system terminates shared/group account credentials when members leave the group. ü Required if shared/group accounts are deployed ü Included in FedRAMP Moderate Baseline, Rev 4 ACCESS CONTROL AC-2 (12) ACCOUNT MANAGEMENT | ACCOUNT MONITORING / ATYPICAL USAGE ü The organization: (a) Monitors information system accounts for [Assignment: organization-defined atypical use]; and (b) Reports atypical usage of information system accounts to [Assignment: organization-defined personnel or roles]. Supplemental Guidance: Atypical usage includes, for example, accessing information systems at certain times of the day and from locations that are not consistent with the normal usage patterns of individuals working in organizations. Related control: CA-7. ü AC-2 (12)(a) and AC-2 (12)(b) Additional FedRAMP Requirements and Guidance: Required for privileged accounts. ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 ACCESS CONTROL AC-2 (13) ACCOUNT MANAGEMENT | DISABLE ACCOUNTS FOR HIGH-RISK INDIVIDUALS ü The organization disables accounts of users posing a significant risk within [Assignment: organization-defined time period] of discovery of the risk. Supplemental Guidance: Users posing a significant risk to organizations include individuals for whom reliable evidence or intelligence indicates either the intention to use authorized access to information systems to cause harm or through whom adversaries will cause harm. Harm includes potential adverse impacts to organizational operations and assets, individuals, other organizations, or the Nation. Close coordination between authorizing officials, information system administrators, and human resource managers is essential in order for timely execution of this control enhancement. Related control: PS-4. References: None. ü Included in NIST High Baseline, Rev 4 [one hour] ACCESS CONTROL AC-3 ACCESS ENFORCEMENT The information system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies. Supplemental Guidance: Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (e.g., devices, files, records, domains) in information systems. In addition to enforcing authorized access at the information system level and recognizing that information systems can host many applications and services in support of organizational missions and business operations, access enforcement mechanisms can also be employed at the application and service level to provide increased information security. Related controls: AC-2, AC-4, AC-5, AC-6, AC-16, AC-17, AC-18, AC-19, AC-20, AC-21, AC-22, AU-9, CM-5, CM-6, CM-11, MA-3, MA-4, MA-5, PE-3. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 ACCESS CONTROL AC-4 INFORMATION FLOW ENFORCEMENT ü The information system enforces approved authorizations for controlling the flow of information within the system and between interconnected systems based on [Assignment: organization-defined information flow control policies]. Supplemental Guidance: Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. Flow control restrictions include, for example, keeping export-controlled information from being transmitted in the clear to the Internet, blocking outside traffic that claims to be from within the organization, restricting web requests to the Internet that are not from the internal web proxy server, and limiting information transfers between organizations based on data structures and content. Transferring information between information systems representing different security domains with different security policies introduces risk that such transfers violate one or more domain security policies. In such situations, information owners/stewards provide guidance at designated policy enforcement points between interconnected systems. Organizations consider mandating specific architectural solutions when required to enforce specific security policies. Enforcement includes, for example: (i) prohibiting information transfers between interconnected systems (i.e., allowing access only); (ii) employing hardware mechanisms to enforce one-way information flows; and (iii) implementing trustworthy regarding mechanisms to reassign security attributes and security labels. Organizations commonly employ information flow control policies and enforcement mechanisms to control the flow of information between designated sources and destinations (e.g., networks, individuals, and devices) within information systems and between interconnected systems. Flow control is based on the characteristics of the information and/or the information path. Enforcement occurs, for example, in boundary protection devices (e.g., gateways, routers, guards, encrypted tunnels, firewalls) that employ rule sets or establish configuration settings that restrict information system services, provide a packet-filtering capability based on header information, or message- filtering capability based on message content (e.g., implementing key word searches or using document characteristics). Organizations also consider the trustworthiness of filtering/inspection mechanisms (i.e., hardware, firmware, and software components) that are critical to information flow enforcement. Control enhancements 3 through 22 primarily address cross-domain solution needs which focus on more advanced filtering techniques, in-depth analysis, and stronger flow enforcement mechanisms implemented in cross-domain products, for example, high-assurance guards. Such capabilities are generally not available in commercial off-the-shelf information technology products. Related controls: AC-3, AC-17, AC-19, AC-21, CM-6, CM-7, SA-8, SC-2, SC-5, SC-7, SC-18. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 ACCESS CONTROL AC-4 (8) INFORMATION FLOW ENFORCEMENT | SECURITY POLICY FILTERS ü The information system enforces information flow control using [Assignment: organization-defined security policy filters] as a basis for flow control decisions for [Assignment: organization-defined information flows]. Supplemental Guidance: Organization-defined security policy filters can address data structures and content. For example, security policy filters for data structures can check for maximum file lengths, maximum field sizes, and data/file types (for structured and unstructured data). Security policy filters for data content can check for specific words (e.g., dirty/clean word filters), enumerated values or data value ranges, and hidden content. Structured data permits the interpretation of data content by applications. Unstructured data typically refers to digital information without a particular data structure or with a data structure that does not facilitate the development of rule sets to address the particular sensitivity of the information conveyed by the data or the associated flow enforcement decisions. Unstructured data consists of: (i) bitmap objects that are inherently non language-based (i.e., image, video, or audio files); and (ii) textual objects that are based on written or printed languages (e.g., commercial off-the- shelf word processing documents, spreadsheets, or emails). Organizations can implement more than one security policy filter to meet information flow control objectives (e.g., employing clean word lists in conjunction with dirty word lists may help to reduce false positives). ü NEED. If there is a significant high-impact risk of inadvertent or intentional data leakage with a system deployed in a shared-service environment, this control is justified to mitigate that risk. Similar justification applies when an organization needs to ensure data isolation between different types of information enclaves within the organization. ANALYSIS. Although this control is usually employed to control flows between different classified enclaves, it can also apply to non-classified scenarios (e.g., the need to isolate legal, personnel, health-related, financial, or other information or files deemed sensitive. SAMPLE THREAT VECTORS. Sensitive free-text information passes from the personnel department to the rest of the organization. Law-enforcement sensitive information is inadvertently pulled from the organization's general counsel case management system and passed outside the department to users without authorization to view that information. HIPAA-protected health information flows freely from the HR department to all employees. Privacy-Act information flows from an HR system into a publicly released report. RELEVANT SECURITY CONTROL ATTRIBUTES. Integrity-Assured, Adaptive, Manageable, Assessed, Auditable, Regulated, Controlled, Monitored, Providing Good Data Stewardship, Assured, Competent, Confidential, Data Controllable, Access-Controlled. [security policy filters inherent in boundary protection devices such as gateways, routers, guards, encrypted tunnels, firewalls] [information containing PII or organization-sensitive information types] ACCESS CONTROL AC-4 (21) INFORMATION FLOW ENFORCEMENT | PHYSICAL / LOGICAL SEPARATION OF INFORMATION FLOWS ü The information system separates information flows logically or physically using [Assignment: organization-defined mechanisms and/or techniques] to accomplish [Assignment: organization- defined required separations by types of information]. Supplemental Guidance: Enforcing the separation of information flows by type can enhance protection by ensuring that information is not commingled while in transit and by enabling flow control by transmission paths perhaps not otherwise achievable. Types of separable information include, for example, inbound and outbound communications traffic, service requests and responses, and information of differing security categories. ü ü Included in FedRAMP Moderate Baseline, Rev 4 ACCESS CONTROL AC-5 SEPARATION OF DUTIES ü The organization: a. Separates [Assignment: organization-defined duties of individuals]; b. Documents separation of duties of individuals; and c. Defines information system access authorizations to support separation of duties. Supplemental Guidance: Separation of duties addresses the potential for abuse of authorized privileges and helps to reduce the risk of malevolent activity without collusion. Separation of duties includes, for example: (i) dividing mission functions and information system support functions among different individuals and/or roles; (ii) conducting information system support functions with different individuals (e.g., system management, programming, configuration management, quality assurance and testing, and network security); and (iii) ensuring security personnel administering access control functions do not also administer audit functions. Related controls: AC-3, AC-6, PE-3, PE-4, PS-2. Control Enhancements: None. References: None. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 ACCESS CONTROL AC-6 LEAST PRIVILEGE The organization employs the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) which are necessary to accomplish assigned tasks in accordance with organizational missions and business functions. Supplemental Guidance: Organizations employ least privilege for specific duties and information systems. The principle of least privilege is also applied to information system processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions/business functions. Organizations consider the creation of additional processes, roles, and information system accounts as necessary, to achieve least privilege. Organizations also apply least privilege to the development, implementation, and operation of organizational information systems. Related controls: AC-2, AC-3, AC-5, CM-6, CM-7, PL-2. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 ACCESS CONTROL AC-6 (1) LEAST PRIVILEGE | AUTHORIZE ACCESS TO SECURITY FUNCTIONS ü The organization explicitly authorizes access to [Assignment: organization-defined security functions (deployed in hardware, software, and firmware) and security-relevant information]. Supplemental Guidance: Security functions include, for example, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. Security-relevant information includes, for example, filtering rules for routers/firewalls, cryptographic key management information, configuration parameters for security services, and access control lists. Explicitly authorized personnel include, for example, security administrators, system and network administrators, system security officers, system maintenance personnel, system programmers, and other privileged users. Related controls: AC-17, AC-18, AC-19. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 [all functions not publicly accessible and all security-relevant information not publicly available] ACCESS CONTROL AC-6 (2) LEAST PRIVILEGE | NON-PRIVILEGED ACCESS FOR NONSECURITY FUNCTIONS ü The organization requires that users of information system accounts, or roles, with access to [Assignment: organization-defined security functions or security-relevant information], use non- privileged accounts or roles, when accessing nonsecurity functions. Supplemental Guidance: This control enhancement limits exposure when operating from within privileged accounts or roles. The inclusion of roles addresses situations where organizations implement access control policies such as role-based access control and where a change of role provides the same degree of assurance in the change of access authorizations for both the user and all processes acting on behalf of the user as would be provided by a change between a privileged and non-privileged account. Related control: PL-4. ü [all security functions] AC-6 (2). Guidance: Examples of security functions include but are not limited to: establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters, system programming, system and security administration, other privileged functions. ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 ACCESS CONTROL AC-6 (3) LEAST PRIVILEGE | NETWORK ACCESS TO PRIVILEGED COMMANDS ü The organization authorizes network access to [Assignment: organization-defined privileged commands] only for [Assignment: organization-defined compelling operational needs] and documents the rationale for such access in the security plan for the information system. Supplemental Guidance: Network access is any access across a network connection in lieu of local access (i.e., user being physically present at the device). Related control: AC-17. ü Included in NIST High Baseline, Rev 4 [privileged commands used to change/configure network devices] [compelling operational needs as defined by organization policy] ACCESS CONTROL AC-6 (5) LEAST PRIVILEGE | PRIVILEGED ACCOUNTS ü The organization restricts privileged accounts on the information system to [Assignment: organization-defined personnel or roles]. Supplemental Guidance: Privileged accounts, including super user accounts, are typically described as system administrator for various types of commercial off-the-shelf operating systems. Restricting privileged accounts to specific personnel or roles prevents day-to-day users from having access to privileged information/functions. Organizations may differentiate in the application of this control enhancement between allowed privileges for local accounts and for domain accounts provided organizations retain the ability to control information system configurations for key security parameters and as otherwise necessary to sufficiently mitigate risk. Related control: CM-6. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 ACCESS CONTROL AC-6 (9) LEAST PRIVILEGE | AUDITING USE OF PRIVILEGED FUNCTIONS The information system audits the execution of privileged functions. Supplemental Guidance: Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised information system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse, and in doing so, help mitigate the risk from insider threats and the advanced persistent threat (APT). Related control: AU-2. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 ACCESS CONTROL AC-6 (10) LEAST PRIVILEGE | PROHIBIT NON-PRIVILEGED USERS FROM EXECUTING PRIVILEGED FUNCTIONS The information system prevents non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures. Supplemental Guidance: Privileged functions include, for example, establishing information system accounts, performing system integrity checks, or administering cryptographic key management activities. Non-privileged users are individuals that do not possess appropriate authorizations. Circumventing intrusion detection and prevention mechanisms or malicious code protection mechanisms are examples of privileged functions that require protection from non-privileged users. References: None. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 ACCESS CONTROL AC-7 UNSUCCESSFUL LOGON ATTEMPTS ü The information system: a. Enforces a limit of [Assignment: organization-defined number] consecutive invalid logon attempts by a user during a [Assignment: organization-defined time period]; and b. Automatically [Selection: locks the account/node for an [Assignment: organization-defined time period]; locks the account/node until released by an administrator; delays next logon prompt according to [Assignment: organization-defined delay algorithm]] when the maximum number of unsuccessful attempts is exceeded. Supplemental Guidance: This control applies regardless of whether the logon occurs via a local or network connection. Due to the potential for denial of service, automatic lockouts initiated by information systems are usually temporary and automatically release after a predetermined time period established by organizations. If a delay algorithm is selected, organizations may choose to employ different algorithms for different information system components based on the capabilities of those components. Responses to unsuccessful logon attempts may be implemented at both the operating system and the application levels. Related controls: AC-2, AC-9, AC-14, IA-5. ü ü AC-7a [not more than three] [fifteen minutes] AC-7b [locks the account/node for thirty minutes] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 AC-7a [not more than three] [fifteen minutes] AC-7b [locks the account/node for a minimum of 3 hours or until unlocked by an administrator] ACCESS CONTROL AC-7 (2) UNSUCCESSFUL LOGON ATTEMPTS | PURGE / WIPE MOBILE DEVICE ü The information system purges/wipes information from [Assignment: organization-defined mobile devices] based on [Assignment: organization-defined purging/wiping requirements/techniques] after [Assignment: organization-defined number] consecutive, unsuccessful device logon attempts. Supplemental Guidance: This control enhancement applies only to mobile devices for which a logon occurs (e.g., personal digital assistants, smart phones, tablets). The logon is to the mobile device, not to any one account on the device. Therefore, successful logons to any accounts on mobile devices reset the unsuccessful logon count to zero. Organizations define information to be purged/wiped carefully in order to avoid over purging/wiping which may result in devices becoming unusable. Purging/wiping may be unnecessary if the information on the device is protected with sufficiently strong encryption mechanisms. Related controls: AC-19, MP-5, MP-6, SC-13. ü NEED. If an organization’s mobile devices carry information whose loss would have a high impact, this control is warranted in order to mitigate the risk of such loss. ANALYSIS. The technologies associated with this control are well established COTS hardware and software. SAMPLE THREAT VECTORS. Mobile device is lost, falls into the hands of people without authorization to view the information contained on the device. RELEVANT SECURITY CONTROL ATTRIBUTES. Integrity-Assured, Usable, Adaptive, Manageable, Agile, Supported, Assessed, Auditable, Regulated, Controlled, Monitored, Providing Good Data Stewardship, Assured, Confidential, Data Controllable, Access-Controlled, Mission Assured [mobile devices as defined by organization policy] [Organization-defined purging/wiping requirements/techniques] [three] ACCESS CONTROL AC-8 SYSTEM USE NOTIFICATION ü The information system: a. Displays to users [Assignment: organization-defined system use notification message or banner] before granting access to the system that provides privacy and security notices consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance and states that: 1. Users are accessing a U.S. Government information system; 2. Information system usage may be monitored, recorded, and subject to audit; 3. Unauthorized use of the information system is prohibited and subject to criminal and civil penalties; and 4. Use of the information system indicates consent to monitoring and recording; b. Retains the notification message or banner on the screen until users acknowledge the usage conditions and take explicit actions to log on to or further access the information system; and c. For publicly accessible systems: 1. Displays system use information [Assignment: organization-defined conditions], before granting further access; 2. Displays references, if any, to monitoring, recording, or auditing that are consistent with privacy accommodations for such systems that generally prohibit those activities; and 3. Includes a description of the authorized uses of the system. Supplemental Guidance: System use notifications can be implemented using messages or warning banners displayed before individuals log in to information systems. System use notifications are used only for access via logon interfaces with human users and are not required when such human interfaces do not exist. Organizations consider system use notification messages/banners displayed in multiple languages based on specific organizational needs and the demographics of information system users. Organizations also consult with the Office of the General Counsel for legal review and approval of warning banner content. Control Enhancements: None. References: None. ü ü Parameter: See Additional Requirements and Guidance. Requirement: The service provider shall determine elements of the cloud environment that require the System Use Notification control. The elements of the cloud environment that require System Use Notification are approved and accepted by the Authorizing Official (AO).Requirement: The service provider shall determine how System Use Notification is going to be verified and provide appropriate periodicity of the check. The System Use Notification verification and periodicity are approved and accepted by the AO.Guidance: If performed as part of a Configuration Baseline check, then the % of items requiring setting that are checked and that pass (or fail) check can be provided. Requirement: If not performed as part of a Configuration Baseline check, then there must be documented agreement on how to provide results of verification and the necessary periodicity of the verification by the service provider. The documented agreement on how to provide verification of the results are approved and accepted by the AO. ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 ACCESS CONTROL AC-10 CONCURRENT SESSION CONTROL ü The information system limits the number of concurrent sessions for each [Assignment: organization-defined account and/or account type] to [Assignment: organization-defined number]. Supplemental Guidance: Organizations may define the maximum number of concurrent sessions for information system accounts globally, by account type (e.g., privileged user, non-privileged user, domain, specific application), by account, or a combination. For example, organizations may limit the number of concurrent sessions for system administrators or individuals working in particularly sensitive domains or mission-critical applications. This control addresses concurrent sessions for information system accounts and does not address concurrent sessions by single users via multiple system accounts. Control Enhancements: None. References: None. ü [three (3) sessions for privileged access and two (2) sessions for non-privileged access] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 ACCESS CONTROL AC-11 SESSION LOCK ü The information system: a. Prevents further access to the system by initiating a session lock after [Assignment: organization-defined time period] of inactivity or upon receiving a request from a user; and b. Retains the session lock until the user reestablishes access using established identification and authentication procedures. Supplemental Guidance: Session locks are temporary actions taken when users stop work and move away from the immediate vicinity of information systems but do not want to log out because of the temporary nature of their absences. Session locks are implemented where session activities can be determined. This is typically at the operating system level, but can also be at the application level. Session locks are not an acceptable substitute for logging out of information systems, for example, if organizations require users to log out at the end of workdays. Related control: AC-7. ü AC-11a. [fifteen minutes] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 ACCESS CONTROL AC-11 (1) SESSION LOCK | PATTERN-HIDING DISPLAYS The information system conceals, via the session lock, information previously visible on the display with a publicly viewable image. Supplemental Guidance: Publicly viewable images can include static or dynamic images, for example, patterns used with screen savers, photographic images, solid colors, clock, battery life indicator, or a blank screen, with the additional caveat that none of the images convey sensitive information. References: OMB Memorandum 06-16. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 ACCESS CONTROL AC-12 SESSION TERMINATION ü The information system automatically terminates a user session after [Assignment: organization-defined conditions or trigger events requiring session disconnect]. Supplemental Guidance: This control addresses the termination of user-initiated logical sessions in contrast to SC-10 which addresses the termination of network connections that are associated with communications sessions (i.e., network disconnect). A logical session (for local, network, and remote access) is initiated whenever a user (or process acting on behalf of a user) accesses an organizational information system. Such user sessions can be terminated (and thus terminate user access) without terminating network sessions. Session termination terminates all processes associated with a user’s logical session except those processes that are specifically created by the user (i.e., session owner) to continue after the session is terminated. Conditions or trigger events requiring automatic session termination can include, for example, organization-defined periods of user inactivity, targeted responses to certain types of incidents, time-of-day restrictions on information system use. Related controls: SC-10, SC-23. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 ACCESS CONTROL AC-14 PERMITTED ACTIONS WITHOUT IDENTIFICATION OR AUTHENTICATION ü The organization: a. Identifies [Assignment: organization-defined user actions] that can be performed on the information system without identification or authentication consistent with organizational missions/business functions; and b. Documents and provides supporting rationale in the security plan for the information system, user actions not requiring identification or authentication. Supplemental Guidance: This control addresses situations in which organizations determine that no identification or authentication is required in organizational information systems. Organizations may allow a limited number of user actions without identification or authentication including, for example, when individuals access public websites or other publicly accessible federal information systems, when individuals use mobile phones to receive calls, or when facsimiles are received. Organizations also identify actions that normally require identification or authentication but may under certain circumstances (e.g., emergencies), allow identification or authentication mechanisms to be bypassed. Such bypasses may occur, for example, via a software-readable physical switch that commands bypass of the logon functionality and is protected from accidental or unmonitored use. This control does not apply to situations where identification and authentication have already occurred and are not repeated, but rather to situations where identification and authentication have not yet occurred. Organizations may decide that there are no user actions that can be performed on organizational information systems without identification and authentication and thus, the values for assignment statements can be none. Related controls: CP-2, IA-2. Control Enhancements: None. (1) PERMITTED ACTIONS WITHOUT IDENTIFICATION OR AUTHENTICATION | NECESSARY USES [Withdrawn: Incorporated into AC-14]. References: None. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 ACCESS CONTROL AC-17 REMOTE ACCESS The organization: a. Establishes and documents usage restrictions, configuration/connection requirements, and implementation guidance for each type of remote access allowed; and b. Authorizes remote access to the information system prior to allowing such connections. Supplemental Guidance: Remote access is access to organizational information systems by users (or processes acting on behalf of users) communicating through external networks (e.g., the Internet). Remote access methods include, for example, dial-up, broadband, and wireless. Organizations often employ encrypted virtual private networks (VPNs) to enhance confidentiality and integrity over remote connections. The use of encrypted VPNs does not make the access non-remote; however, the use of VPNs, when adequately provisioned with appropriate security controls (e.g., employing appropriate encryption techniques for confidentiality and integrity protection) may provide sufficient assurance to the organization that it can effectively treat such connections as internal networks. Still, VPN connections traverse external networks, and the encrypted VPN does not enhance the availability of remote connections. Also, VPNs with encrypted tunnels can affect the organizational capability to adequately monitor network communications traffic for malicious code. Remote access controls apply to information systems other than public web servers or systems designed for public access. This control addresses authorization prior to allowing remote access without specifying the formats for such authorization. While organizations may use interconnection security agreements to authorize remote access connections, such agreements are not required by this control. Enforcing access restrictions for remote connections is addressed in AC-3. Related controls: AC-2, AC-3, AC-18, AC-19, AC-20, CA-3, CA-7, CM-8, IA-2, IA-3, IA-8, MA-4, PE-17, PL-4, SC-10, SI-4. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 System-to-system remote access via Application Program Interfaces or other protocols or technologies is also included ACCESS CONTROL AC-17 (1) REMOTE ACCESS | AUTOMATED MONITORING / CONTROL The information system monitors and controls remote access methods. Supplemental Guidance: Automated monitoring and control of remote access sessions allows organizations to detect cyber attacks and also ensure ongoing compliance with remote access policies by auditing connection activities of remote users on a variety of information system components (e.g., servers, workstations, notebook computers, smart phones, and tablets). Related controls: AU-2, AU-12. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 ACCESS CONTROL AC-17 (2) REMOTE ACCESS | PROTECTION OF CONFIDENTIALITY / INTEGRITY USING ENCRYPTION The information system implements cryptographic mechanisms to protect the confidentiality and integrity of remote access sessions. Supplemental Guidance: The encryption strength of mechanism is selected based on the security categorization of the information. Related controls: SC-8, SC-12, SC-13. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 ACCESS CONTROL AC-17 (3) REMOTE ACCESS | MANAGED ACCESS CONTROL POINTS ü The information system routes all remote accesses through [Assignment: organization-defined number] managed network access control points. Supplemental Guidance: Limiting the number of access control points for remote accesses reduces the attack surface for organizations. Organizations consider the Trusted Internet Connections (TIC) initiative requirements for external network connections. Related control: SC-7. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 ACCESS CONTROL AC-17 (4) REMOTE ACCESS | PRIVILEGED COMMANDS / ACCESS ü The organization: (a) Authorizes the execution of privileged commands and access to security-relevant information via remote access only for [Assignment: organization-defined needs]; and (b) Documents the rationale for such access in the security plan for the information system. Supplemental Guidance: Related control: AC-6. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 ACCESS CONTROL AC-17 (9) REMOTE ACCESS | DISCONNECT / DISABLE ACCESS ü The organization provides the capability to expeditiously disconnect or disable remote access to the information system within [Assignment: organization-defined time period]. Supplemental Guidance: This control enhancement requires organizations to have the capability to rapidly disconnect current users remotely accessing the information system and/or disable further remote access. The speed of disconnect or disablement varies based on the criticality of missions/business functions and the need to eliminate immediate or future remote access to organizational information systems. ü [no greater than 15 minutes] ü Included in FedRAMP Moderate Baseline, Rev 4 [immediately] ACCESS CONTROL AC-18 WIRELESS ACCESS The organization: a. Establishes usage restrictions, configuration/connection requirements, and implementation guidance for wireless access; and b. Authorizes wireless access to the information system prior to allowing such connections. Supplemental Guidance: Wireless technologies include, for example, microwave, packet radio (UHF/VHF), 802.11x, and Bluetooth. Wireless networks use authentication protocols (e.g., EAP/TLS, PEAP), which provide credential protection and mutual authentication. Related controls: AC-2, AC-3, AC-17, AC-19, CA-3, CA-7, CM-8, IA-2, IA-3, IA-8, PL-4, SI-4. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 ACCESS CONTROL AC-18 (1) WIRELESS ACCESS | AUTHENTICATION AND ENCRYPTION ü The information system protects wireless access to the system using authentication of [Selection (one or more): users; devices] and encryption. Supplemental Guidance: Related controls: SC-8, SC-13. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 ACCESS CONTROL AC-18 (4) WIRELESS ACCESS | RESTRICT CONFIGURATIONS BY USERS The organization identifies and explicitly authorizes users allowed to independently configure wireless networking capabilities. Supplemental Guidance: Organizational authorizations to allow selected users to configure wireless networking capability are enforced in part, by the access enforcement mechanisms employed within organizational information systems. Related controls: AC-3, SC-15. ü Included in NIST High Baseline, Rev 4 ACCESS CONTROL AC-18 (5) WIRELESS ACCESS | ANTENNAS / TRANSMISSION POWER LEVELS The organization selects radio antennas and calibrates transmission power levels to reduce the probability that usable signals can be received outside of organization-controlled boundaries. Supplemental Guidance: Actions that may be taken by organizations to limit unauthorized use of wireless communications outside of organization-controlled boundaries include, for example: (i) reducing the power of wireless transmissions so that the transmissions are less likely to emit a signal that can be used by adversaries outside of the physical perimeters of organizations; (ii) employing measures such as TEMPEST to control wireless emanations; and (iii) using directional/beam forming antennas that reduce the likelihood that unintended receivers will be able to intercept signals. Prior to taking such actions, organizations can conduct periodic wireless surveys to understand the radio frequency profile of organizational information systems as well as other systems that may be operating in the area. Related control: PE-19. References: NIST Special Publications 800-48, 800-94, 800-97. ü Included in NIST High Baseline, Rev 4 ACCESS CONTROL AC-19 ACCESS CONTROL FOR MOBILE DEVICES The organization: a. Establishes usage restrictions, configuration requirements, connection requirements, and implementation guidance for organization-controlled mobile devices; and b. Authorizes the connection of mobile devices to organizational information systems. Supplemental Guidance: A mobile device is a computing device that: (i) has a small form factor such that it can easily be carried by a single individual; (ii) is designed to operate without a physical connection (e.g., wirelessly transmit or receive information); (iii) possesses local, non- removable or removable data storage; and (iv) includes a self-contained power source. Mobile devices may also include voice communication capabilities, on-board sensors that allow the device to capture information, and/or built-in features for synchronizing local data with remote locations. Examples include smart phones, E-readers, and tablets. Mobile devices are typically associated with a single individual and the device is usually in close proximity to the individual; however, the degree of proximity can vary depending upon on the form factor and size of the device. The processing, storage, and transmission capability of the mobile device may be comparable to or merely a subset of desktop systems, depending upon the nature and intended purpose of the device. Due to the large variety of mobile devices with different technical characteristics and capabilities, organizational restrictions may vary for the different classes/types of such devices. Usage restrictions and specific implementation guidance for mobile devices include, for example, configuration management, device identification and authentication, implementation of mandatory protective software (e.g., malicious code detection, firewall), scanning devices for malicious code, updating virus protection software, scanning for critical software updates and patches, conducting primary operating system (and possibly other resident software) integrity checks, and disabling unnecessary hardware (e.g., wireless, infrared). Organizations are cautioned that the need to provide adequate security for mobile devices goes beyond the requirements in this control. Many safeguards and countermeasures for mobile devices are reflected in other security controls in the catalog allocated in the initial control baselines as starting points for the development of security plans and overlays using the tailoring process. There may also be some degree of overlap in the requirements articulated by the security controls within the different families of controls. AC-20 addresses mobile devices that are not organization-controlled. Related controls: AC-3, AC-7, AC- 18, AC-20, CA-9, CM-2, IA-2, IA-3, MP-2, MP-4, MP-5, PL-4, SC-7, SC-43, SI-3, SI-4. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 ACCESS CONTROL AC-19 (5) ACCESS CONTROL FOR MOBILE DEVICES | FULL DEVICE / CONTAINER-BASED ENCRYPTION ü The organization employs [Selection: full-device encryption; container encryption] to protect the confidentiality and integrity of information on [Assignment: organization-defined mobile devices]. Supplemental Guidance: Container-based encryption provides a more fine-grained approach to the encryption of data/information on mobile devices, including for example, encrypting selected data structures such as files, records, or fields. Related controls: MP-5, SC-13, SC- 28. References: OMB Memorandum 06-16; NIST Special Publications 800-114, 800-124, 800-164. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 AC-20 USE OF EXTERNAL INFORMATION SYSTEMS The organization establishes terms and conditions, consistent with any trust relationships established with other organizations owning, operating, and/or maintaining external information systems, allowing authorized individuals to: a. Access the information system from external information systems; and b. Process, store, or transmit organization-controlled information using external information systems. Supplemental Guidance: External information systems are information systems or components of information systems that are outside of the authorization boundary established by organizations and for which organizations typically have no direct supervision and authority over the application of required security controls or the assessment of control effectiveness. External information systems include, for example: (i) personally owned information systems/devices (e.g., notebook computers, smart phones, tablets, personal digital assistants); (ii) privately owned computing and communications devices resident in commercial or public facilities (e.g., hotels, train stations, convention centers, shopping malls, or airports); (iii) information systems owned or controlled by nonfederal governmental organizations; and (iv) federal information systems that are not owned by, operated by, or under the direct supervision and authority of organizations. This control also addresses the use of external information systems for the processing, storage, or transmission of organizational information, including, for example, accessing cloud services (e.g., infrastructure as a service, platform as a service, or software as a service) from organizational information systems. For some external information systems (i.e., information systems operated by other federal agencies, including organizations subordinate to those agencies), the trust relationships that have been established between those organizations and the originating organization may be such, that no explicit terms and conditions are required. Information systems within these organizations would not be considered external. These situations occur when, for example, there are pre-existing sharing/trust agreements (either implicit or explicit) established between federal agencies or organizations subordinate to those agencies, or when such trust agreements are specified by applicable laws, Executive Orders, directives, or policies. Authorized individuals include, for example, organizational personnel, contractors, or other individuals with authorized access to organizational information systems and over which organizations have the authority to impose rules of behavior with regard to system access. Restrictions that organizations impose on authorized individuals need not be uniform, as those restrictions may vary depending upon the trust relationships between organizations. Therefore, organizations may choose to impose different security restrictions on contractors than on state, local, or tribal governments. This control does not apply to the use of external information systems to access public interfaces to organizational information systems (e.g., individuals accessing federal information through www.usa.gov). Organizations establish terms and conditions for the use of external information systems in accordance with organizational security policies and procedures. Terms and conditions address as a minimum: types of applications that can be accessed on organizational information systems from external information systems; and the highest security category of information that can be processed, stored, or transmitted on external information systems. If terms and conditions with the owners of external information systems cannot be established, organizations may impose restrictions on organizational personnel using those external systems. Related controls: AC-3, AC- 17, AC-19, CA-3, PL-4, SA-9. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 ACCESS CONTROL AC-20 (1) USE OF EXTERNAL INFORMATION SYSTEMS | LIMITS ON AUTHORIZED USE The organization permits authorized individuals to use an external information system to access the information system or to process, store, or transmit organization-controlled information only when the organization: (a) Verifies the implementation of required security controls on the external system as specified in the organization’s information security policy and security plan; or (b) Retains approved information system connection or processing agreements with the organizational entity hosting the external information system. Supplemental Guidance: This control enhancement recognizes that there are circumstances where individuals using external information systems (e.g., contractors, coalition partners) need to access organizational information systems. In those situations, organizations need confidence that the external information systems contain the necessary security safeguards (i.e., security controls), so as not to compromise, damage, or otherwise harm organizational information systems. Verification that the required security controls have been implemented can be achieved, for example, by third-party, independent assessments, attestations, or other means, depending on the confidence level required by organizations. Related control: CA-2. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 ACCESS CONTROL AC-20 (2) USE OF EXTERNAL INFORMATION SYSTEMS | PORTABLE STORAGE DEVICES ü The organization [Selection: restricts; prohibits] the use of organization-controlled portable storage devices by authorized individuals on external information systems. Supplemental Guidance: Limits on the use of organization-controlled portable storage devices in external information systems include, for example, complete prohibition of the use of such devices or restrictions on how the devices may be used and under what conditions the devices may be used. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 ACCESS CONTROL AC-21 INFORMATION SHARING ü The organization [Selection: restricts; prohibits] the use of organization-controlled portable storage devices by authorized individuals on external information systems. Supplemental Guidance: Limits on the use of organization-controlled portable storage devices in external information systems include, for example, complete prohibition of the use of such devices or restrictions on how the devices may be used and under what conditions the devices may be used. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 ACCESS CONTROL AC-22 PUBLICLY ACCESSIBLE CONTENT ü The organization: a. Designates individuals authorized to post information onto a publicly accessible information system; b. Trains authorized individuals to ensure that publicly accessible information does not contain nonpublic information; c. Reviews the proposed content of information prior to posting onto the publicly accessible information system to ensure that nonpublic information is not included; and d. Reviews the content on the publicly accessible information system for nonpublic information [Assignment: organization-defined frequency] and removes such information, if discovered. Supplemental Guidance: In accordance with federal laws, Executive Orders, directives, policies, regulations, standards, and/or guidance, the general public is not authorized access to nonpublic information (e.g., information protected under the Privacy Act and proprietary information). This control addresses information systems that are controlled by the organization and accessible to the general public, typically without identification or authentication. The posting of information on non-organization information systems is covered by organizational policy. Related controls: AC-3, AC-4, AT-2, AT-3, AU-13. ü ü AC-22d. [at least quarterly] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 AWARENESS AND TRAINING AT-1 SECURITY AWARENESS AND TRAINING POLICY ANDPROCEDURES ü The organization: a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]: 1. A security awareness and training policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and 2. Procedures to facilitate the implementation of the security awareness and training policy and associated security awareness and training controls; and b. Reviews and updates the current: 1. Security awareness and training policy [Assignment: organization-defined frequency]; and 2. Security awareness and training procedures [Assignment: organization-defined frequency]. Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the AT family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9. Control Enhancements: None. References: NIST Special Publications 800-12, 800-16, 800-50, 800-100. ü ü AT-1.b.1 [at least every 3 years] AT-1.b.2 [at least annually] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 AWARENESS AND TRAINING AT-2 SECURITY AWARENESS TRAINING The organization provides basic security awareness training to information system users (including managers, senior executives, and contractors): a. As part of initial training for new users; b. When required by information system changes; and c. [Assignment: organization-defined frequency] thereafter. Supplemental Guidance: Organizations determine the appropriate content of security awareness training and security awareness techniques based on the specific organizational requirements and the information systems to which personnel have authorized access. The content includes a basic understanding of the need for information security and user actions to maintain security and to respond to suspected security incidents. The content also addresses awareness of the need for operations security. Security awareness techniques can include, for example, displaying posters, offering supplies inscribed with security reminders, generating email advisories/notices from senior organizational officials, displaying logon screen messages, and conducting information security awareness events. Related controls: AT-3, AT-4, PL-4. ü ü AT-2. [Assignment: organization-defined frequency] Parameter: [at least annually] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 AWARENESS AND TRAINING AT-2 (2) SECURITY AWARENESS | INSIDER THREAT The organization includes security awareness training on recognizing and reporting potential indicators of insider threat. Supplemental Guidance: Potential indicators and possible precursors of insider threat can include behaviors such as inordinate, long-term job dissatisfaction, attempts to gain access to information not required for job performance, unexplained access to financial resources, bullying or sexual harassment of fellow employees, workplace violence, and other serious violations of organizational policies, procedures, directives, rules, or practices. Security awareness training includes how to communicate employee and management concerns regarding potential indicators of insider threat through appropriate organizational channels in accordance with established organizational policies and procedures. Related controls: PL-4, PM-12, PS-3, PS-6. References: C.F.R. Part 5 Subpart C (5 C.F.R 930.301); Executive Order 13587; NIST Special Publication 800-50. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 AWARENESS AND TRAINING AT-3 ROLE-BASED SECURITY TRAINING ü The organization provides role-based security training to personnel with assigned security roles and responsibilities: a. Before authorizing access to the information system or performing assigned duties; b. When required by information system changes; and c. [Assignment: organization-defined frequency] thereafter. Supplemental Guidance: Organizations determine the appropriate content of security training based on the assigned roles and responsibilities of individuals and the specific security requirements of organizations and the information systems to which personnel have authorized access. In addition, organizations provide enterprise architects, information system developers, software developers, acquisition/procurement officials, information system managers, system/network administrators, personnel conducting configuration management and auditing activities, personnel performing independent verification and validation activities, security control assessors, and other personnel having access to system-level software, adequate security-related technical training specifically tailored for their assigned duties. Comprehensive role-based training addresses management, operational, and technical roles and responsibilities covering physical, personnel, and technical safeguards and countermeasures. Such training can include for example, policies, procedures, tools, and artifacts for the organizational security roles defined. Organizations also provide the training necessary for individuals to carry out their responsibilities related to operations and supply chain security within the context of organizational information security programs. Role-based security training also applies to contractors providing services to federal agencies. Related controls: AT-2, AT-4, PL-4, PS-7, SA-3, SA-12, SA-16. ü ü AT-3c. [Assignment: organization-defined frequency] Parameter: [at least annually] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 AWARENESS AND TRAINING AT-3 (3) SECURITY TRAINING | PRACTICAL EXERCISES The organization includes practical exercises in security training that reinforce training objectives. Supplemental Guidance: Practical exercises may include, for example, security training for software developers that includes simulated cyber attacks exploiting common software vulnerabilities (e.g., buffer overflows), or spear/whale phishing attacks targeted at senior leaders/executives. These types of practical exercises help developers better understand the effects of such vulnerabilities and appreciate the need for security coding standards and processes. ü NEED. High-impact systems warrant significantly elevated protection; one of these elevated protections is provided through simulated no-notice attacks that exercise users’ ability to detect and respond correctly to attempts to steal internal information in their possession. ANALYSIS. These controls are well understood and widely installed; COTS components keep implementation time and cost low. SAMPLE THREAT VECTORS. Cybersecurity staff do not know how to monitor, respond, and manage complex enforcement systems and subsystems. Cybersecurity staff is not properly trained to understand how the controls are to operate. Staff does not understand the event alarms/logs. Staff is not able to protect from unauthorized disclosure. Staff is careless with handling data, or unwilling to follow the established security protocols, or willing to cut corners to save time. RELEVANT SECURITY CONTROL ATTRIBUTES. Integrity-Assured, Assessed, Auditable, Controlled, Monitored, Providing Good Data Stewardship, Assured, Competent, Confidential AWARENESS AND TRAINING AT-3 (4) SECURITY TRAINING | SUSPICIOUS COMMUNICATIONS AND ANOMALOUS SYSTEM BEHAVIOR ü The organization provides training to its personnel on [Assignment: organization-defined indicators of malicious code] to recognize suspicious communications and anomalous behavior in organizational information systems. Supplemental Guidance: A well-trained workforce provides another organizational safeguard that can be employed as part of a defense-in-depth strategy to protect organizations against malicious code coming in to organizations via email or the web applications. Personnel are trained to look for indications of potentially suspicious email (e.g., receiving an unexpected email, receiving an email containing strange or poor grammar, or receiving an email from an unfamiliar sender but who appears to be from a known sponsor or contractor). Personnel are also trained on how to respond to such suspicious email or web communications (e.g., not opening attachments, not clicking on embedded web links, and checking the source of email addresses). For this process to work effectively, all organizational personnel are trained and made aware of what constitutes suspicious communications. Training personnel on how to recognize anomalous behaviors in organizational information systems can potentially provide early warning for the presence of malicious code. Recognition of such anomalous behavior by organizational personnel can supplement automated malicious code detection and protection tools and systems employed by organizations. ü NEED. High-impact systems warrant significantly elevated protection; one of these elevated protections is provided through simulated no-notice attacks that exercise users’ ability to detect and respond correctly to attempts to steal internal information in their possession. ANALYSIS. These controls are well understood and widely installed; COTS components keep implementation time and cost low. THREAT VECTORS ADDRESSED. Staff does not know how to monitor or manage complex systems in a way that supports effective management decision or control. Malicious actors manipulate the system to appear as if functioning normally when in reality, it is not. People fail to review event logs. People make unauthorized changes to event logger. RELEVANT SECURITY CONTROL ATTRIBUTES. Integrity-Assured, Assessed, Auditable, Controlled, Monitored, Providing Good Data Stewardship, Assured, Competent, Confidential. [malicious code indicators as defined by organization incident policy/capability] AWARENESS AND TRAINING AT-4 SECURITY TRAINING RECORDS ü The organization: a. Documents and monitors individual information system security training activities including basic security awareness training and specific information system security training; and b. Retains individual training records for [Assignment: organization-defined time period]. Supplemental Guidance: Documentation for specialized training may be maintained by individual supervisors at the option of the organization. Related controls: AT-2, AT-3, PM-14. Control Enhancements: None. References: None. ü ü AT-4b. [Assignment: organization-defined frequency] Parameter: [At least one year] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 AUDIT AND ACCOUNTABILITY AU-1 AUDIT AND ACCOUNTABILITY POLICY AND PROCEDURES ü The organization: a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]: 1. An audit and accountability policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and 2. Procedures to facilitate the implementation of the audit and accountability policy and associated audit and accountability controls; and b. Reviews and updates the current: 1. Audit and accountability policy [Assignment: organization-defined frequency]; and 2. Audit and accountability procedures [Assignment: organization-defined frequency]. Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the AU family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9. Control Enhancements: None. References: NIST Special Publications 800-12, 800-100. ü ü AU-1.b.1 [at least every 3 years] AU-1.b.2 [at least annually] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 AU-1.b.1 [at least annually] AU-1.b.2 [at least annually] AUDIT AND ACCOUNTABILITY AU-2 AUDIT EVENTS ü The organization: a. Determines that the information system is capable of auditing the following events: [Assignment: organization-defined auditable events]; b. Coordinates the security audit function with other organizational entities requiring audit- related information to enhance mutual support and to help guide the selection of auditable events; c. Provides a rationale for why the auditable events are deemed to be adequate to support after- the-fact investigations of security incidents; and d. Determines that the following events are to be audited within the information system: [Assignment: organization-defined audited events (the subset of the auditable events defined in AU-2 a.) along with the frequency of (or situation requiring) auditing for each identified event]. Supplemental Guidance: An event is any observable occurrence in an organizational information system. Organizations identify audit events as those events which are significant and relevant to the security of information systems and the environments in which those systems operate in order to meet specific and ongoing audit needs. Audit events can include, for example, password changes, failed logons, or failed accesses related to information systems, administrative privilege usage, PIV credential usage, or third-party credential usage. In determining the set of auditable events, organizations consider the auditing appropriate for each of the security controls to be implemented. To balance auditing requirements with other information system needs, this control also requires identifying that subset of auditable events that are audited at a given point in time. For example, organizations may determine that information systems must have the capability to log every file access both successful and unsuccessful, but not activate that capability except for specific circumstances due to the potential burden on system performance. Auditing requirements, including the need for auditable events, may be referenced in other security controls and control enhancements. Organizations also include auditable events that are required by applicable federal laws, Executive Orders, directives, policies, regulations, and standards. Audit records can be generated at various levels of abstraction, including at the packet level as information traverses the network. Selecting the appropriate level of abstraction is a critical aspect of an audit capability and can facilitate the identification of root causes to problems. Organizations consider in the definition of auditable events, the auditing necessary to cover related events such as the steps in distributed, transaction-based processes (e.g., processes that are distributed across multiple organizations) and actions that occur in service-oriented architectures. Related controls: AC-6, AC-17, AU-3, AU-12, MA-4, MP-2, MP-4, SI-4. ü ü AU-2a. [Successful and unsuccessful account logon events, account management events, object access, policy change, privilege functions, process tracking, and system events. For Web applications: all administrator activity, authentication checks, authorization checks, data deletions, data access, data changes, and permission changes] AU-2d. [organization-defined subset of the auditable events defined in AU-2 a. to be audited continually for each identified event]. ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 Coordination between service provider and consumer shall be documented and accepted by the Authorizing Official AUDIT AND ACCOUNTABILITY AU-2 (3) AUDIT EVENTS | REVIEWS AND UPDATES ü The organization reviews and updates the audited events [Assignment: organization-defined frequency]. Supplemental Guidance: Over time, the events that organizations believe should be audited may change. Reviewing and updating the set of audited events periodically is necessary to ensure that the current set is still necessary and sufficient. ü AU-2 (3). [Assignment: organization-defined frequency] Parameter: [annually or whenever there is a change in the threat environment] Guidance: Annually or whenever changes in the threat environment are communicated to the service provider by the Authorizing Official. ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 AUDIT AND ACCOUNTABILITY AU-3 CONTENT OF AUDIT RECORDS The information system generates audit records containing information that establishes what type of event occurred, when the event occurred, where the event occurred, the source of the event, the outcome of the event, and the identity of any individuals or subjects associated with the event. Supplemental Guidance: Audit record content that may be necessary to satisfy the requirement of this control, includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. Event outcomes can include indicators of event success or failure and event-specific results (e.g., the security state of the information system after the event occurred). Related controls: AU-2, AU-8, AU-12, SI-11. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 AUDIT AND ACCOUNTABILITY AU-3 (1) CONTENT OF AUDIT RECORDS | ADDITIONAL AUDIT INFORMATION ü The information system generates audit records containing the following additional information: [Assignment: organization-defined additional, more detailed information]. Supplemental Guidance: Detailed information that organizations may consider in audit records includes, for example, full text recording of privileged commands or the individual identities of group account users. Organizations consider limiting the additional audit information to only that information explicitly needed for specific audit requirements. This facilitates the use of audit trails and audit logs by not including information that could potentially be misleading or could make it more difficult to locate information of interest. ü AU-3 (1). [Assignment: organization-defined additional, more detailed information] Parameter: [session, connection, transaction, or activity duration; for client-server transactions, the number of bytes received and bytes sent; additional informational messages to diagnose or identify the event; characteristics that describe or identify the object or resource being acted upon] AU-3 (1). Requirement: The service provider defines audit record types. The audit record types are approved and accepted by the Authorizing Official. Guidance: For client-server transactions, the number of bytes sent and received gives bidirectional transfer information that can be helpful during an investigation or inquiry. ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 AU-3 (1). [Assignment: organization-defined additional, more detailed information] Parameter: [session, connection, transaction, or activity duration; for client-server transactions, the number of bytes received and bytes sent; additional informational messages to diagnose or identify the event; characteristics that describe or identify the object or resource being acted upon; individual identities of group account users; full-text of privileged commands] AUDIT AND ACCOUNTABILITY AU-3 (2) CONTENT OF AUDIT RECORDS | CENTRALIZED MANAGEMENT OF PLANNED AUDIT RECORD CONTENT ü The information system provides centralized management and configuration of the content to be captured in audit records generated by [Assignment: organization-defined information system components]. Supplemental Guidance: This control enhancement requires that the content to be captured in audit records be configured from a central location (necessitating automation). Organizations coordinate the selection of required audit content to support the centralized management and configuration capability provided by the information system. Related controls: AU-6, AU-7. References: None. ü Included in NIST High Baseline, Rev 4 [all network, data storage, and computing devices] AUDIT AND ACCOUNTABILITY AU-4 AUDIT STORAGE CAPACITY ü The organization allocates audit record storage capacity in accordance with [Assignment: organization-defined audit record storage requirements]. Supplemental Guidance: Organizations consider the types of auditing to be performed and the audit processing requirements when allocating audit storage capacity. Allocating sufficient audit storage capacity reduces the likelihood of such capacity being exceeded and resulting in the potential loss or reduction of auditing capability. Related controls: AU-2, AU-5, AU-6, AU-7, AU-11, SI-4. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 AUDIT AND ACCOUNTABILITY AU-5 RESPONSE TO AUDIT PROCESSING FAILURES ü The information system: a. Alerts [Assignment: organization-defined personnel or roles] in the event of an audit processing failure; and b. Takes the following additional actions: [Assignment: organization-defined actions to be taken (e.g., shut down information system, overwrite oldest audit records, stop generating audit records)]. Supplemental Guidance: Audit processing failures include, for example, software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. Organizations may choose to define additional actions for different audit processing failures (e.g., by type, by location, by severity, or a combination of such factors). This control applies to each audit data storage repository (i.e., distinct information system component where audit records are stored), the total audit storage capacity of organizations (i.e., all audit data storage repositories combined), or both. Related controls: AU-4, SI-12. ü ü AU-5b. [Assignment: Organization-defined actions to be taken] Parameter: [low-impact: overwrite oldest audit records; moderate-impact: shut down] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 AU-5b. [Assignment: Organization-defined actions to be taken] Parameter: [high impact: shut down] AUDIT AND ACCOUNTABILITY AU-5 (1) RESPONSE TO AUDIT PROCESSING FAILURES | AUDIT STORAGE CAPACITY ü The information system provides a warning to [Assignment: organization-defined personnel, roles, and/or locations] within [Assignment: organization-defined time period] when allocated audit record storage volume reaches [Assignment: organization-defined percentage] of repository maximum audit record storage capacity. Supplemental Guidance: Organizations may have multiple audit data storage repositories distributed across multiple information system components, with each repository having different storage volume capacities. ü Included in NIST High Baseline, Rev 4 [service provider personnel with authority to address audit storage capacity planning] [24 hours] [in accordance with organization auditing policy] AUDIT AND ACCOUNTABILITY AU-5 (2) RESPONSE TO AUDIT PROCESSING FAILURES | REAL-TIME ALERTS ü The information system provides an alert in [Assignment: organization-defined real-time period] to [Assignment: organization-defined personnel, roles, and/or locations] when the following audit failure events occur: [Assignment: organization-defined audit failure events requiring real-time alerts]. Supplemental Guidance: Alerts provide organizations with urgent messages. Real-time alerts provide these messages at information technology speed (i.e., the time from event detection to alert occurs in seconds or less). ü Included in NIST High Baseline, Rev 4 [real-time] [service provider personnel with authority to address failed audit events] [audit failure events requiring real-time alerts, as defined by organization audit policy]. AUDIT AND ACCOUNTABILITY AU-6 AUDIT REVIEW, ANALYSIS, AND REPORTING ü The organization: a. Reviews and analyzes information system audit records [Assignment: organization-defined frequency] for indications of [Assignment: organization-defined inappropriate or unusual activity]; and b. Reports findings to [Assignment: organization-defined personnel or roles]. Supplemental Guidance: Audit review, analysis, and reporting covers information security-related auditing performed by organizations including, for example, auditing that results from monitoring of account usage, remote access, wireless connectivity, mobile device connection, configuration settings, system component inventory, use of maintenance tools and nonlocal maintenance, physical access, temperature and humidity, equipment delivery and removal, communications at the information system boundaries, use of mobile code, and use of VoIP. Findings can be reported to organizational entities that include, for example, incident response team, help desk, information security group/department. If organizations are prohibited from reviewing and analyzing audit information or unable to conduct such activities (e.g., in certain national security applications or systems), the review/analysis may be carried out by other organizations granted such authority. Related controls: AC-2, AC-3, AC-6, AC-17, AT-3, AU-7, AU-16, CA-7, CM-5, CM-10, CM-11, IA-3, IA-5, IR-5, IR-6, MA-4, MP-4, PE-3, PE-6, PE-14, PE-16, RA-5, SC-7, SC-18, SC-19, SI-3, SI-4, SI-7. ü ü AU-6a. [Assignment: organization-defined frequency] Parameter: [at least weekly] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 Coordination between service provider and consumer shall be documented and accepted by the Authorizing Official. In multi-tennant environments, capability and means for providing review, analysis, and reporting to consumer for data pertaining to consumer shall be documented. AUDIT AND ACCOUNTABILITY AU-6 (1) AUDIT REVIEW, ANALYSIS, AND REPORTING | PROCESS INTEGRATION The organization employs automated mechanisms to integrate audit review, analysis, and reporting processes to support organizational processes for investigation and response to suspicious activities. Supplemental Guidance: Organizational processes benefiting from integrated audit review, analysis, and reporting include, for example, incident response, continuous monitoring, contingency planning, and Inspector General audits. Related controls: AU-12, PM-7. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 AUDIT AND ACCOUNTABILITY AU-6 (3) AUDIT REVIEW, ANALYSIS, AND REPORTING | CORRELATE AUDIT REPOSITORIES The organization analyzes and correlates audit records across different repositories to gain organization-wide situational awareness. Supplemental Guidance: Organization-wide situational awareness includes awareness across all three tiers of risk management (i.e., organizational, mission/business process, and information system) and supports cross-organization awareness. Related controls: AU-12, IR-4. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 AUDIT AND ACCOUNTABILITY AU-6 (4) AUDIT REVIEW, ANALYSIS, AND REPORTING | CENTRAL REVIEW AND ANALYSIS The information system provides the capability to centrally review and analyze audit records from multiple components within the system. Supplemental Guidance: Automated mechanisms for centralized reviews and analyses include, for example, Security Information Management products. Related controls: AU-2, AU-12. ü NEED. Due to the complexity of independent systems exchanging security-related monitoring data, and high-impact systems implemented in shared-service environments, the responsible organization needs a centralized capability that integrates these various data sources into a unified whole permitting central review and analysis of diverse log data relevant to security audits. ANALYSIS. This control permits analysts and auditors to focus on their primary duty of analyzing log data, and relieves them of the usual burden of discovery, collection, validation, aggregation, and indexing of large log datasets relevant to system security. Since these latter collection tasks have been automated under this control, less time and funding will be required to execute this core audit/analysis activity. SAMPLE THREAT VECTORS. Staff does not know how to monitor or manage complex systems in a way that supports effective management decision or control. Malicious actors manipulate the system to appear as if functioning normally, when it is not. People fail to review event logs. People make unauthorized changes to event logger." RELEVANT SECURITY CONTROL ATTRIBUTES. Monitored. AUDIT AND ACCOUNTABILITY AU-6 (5) AUDIT REVIEW, ANALYSIS, AND REPORTING | INTEGRATION / SCANNING AND MONITORING CAPABILITIES ü The organization integrates analysis of audit records with analysis of [Selection (one or more): vulnerability scanning information; performance data; information system monitoring information; [Assignment: organization-defined data/information collected from other sources]] to further enhance the ability to identify inappropriate or unusual activity. Supplemental Guidance: This control enhancement does not require vulnerability scanning, the generation of performance data, or information system monitoring. Rather, the enhancement requires that the analysis of information being otherwise produced in these areas is integrated with the analysis of audit information. Security Event and Information Management System tools can facilitate audit record aggregation/consolidation from multiple information system components as well as audit record correlation and analysis. The use of standardized audit record analysis scripts developed by organizations (with localized script adjustments, as necessary) provides more cost-effective approaches for analyzing audit record information collected. The correlation of audit record information with vulnerability scanning information is important in determining the veracity of vulnerability scans and correlating attack detection events with scanning results. Correlation with performance data can help uncover denial of service attacks or cyber attacks resulting in unauthorized use of resources. Correlation with system monitoring information can assist in uncovering attacks and in better relating audit information to operational situations. Related controls: AU-12, IR-4, RA-5. ü Included in NIST High Baseline, Rev 4 [vulnerability scanning information; performance data; information system monitoring information; penetration test data; [Organization -defined data/information collected from other sources]] AUDIT AND ACCOUNTABILITY AU-6 (6) AUDIT REVIEW, ANALYSIS, AND REPORTING | CORRELATION WITH PHYSICAL MONITORING The organization correlates information from audit records with information obtained from monitoring physical access to further enhance the ability to identify suspicious, inappropriate, unusual, or malevolent activity. Supplemental Guidance: The correlation of physical audit information and audit logs from information systems may assist organizations in identifying examples of suspicious behavior or supporting evidence of such behavior. For example, the correlation of an individual’s identify for logical access to certain information systems with the additional physical security information that the individual was actually present at the facility when the logical access occurred, may prove to be useful in investigations. ü Included in NIST High Baseline, Rev 4 AUDIT AND ACCOUNTABILITY AU-6 (7) AUDIT REVIEW, ANALYSIS, AND REPORTING | PERMITTED ACTIONS ü The organization specifies the permitted actions for each [Selection (one or more): information system process; role; user] associated with the review, analysis, and reporting of audit information. Supplemental Guidance: Organizations specify permitted actions for information system processes, roles, and/or users associated with the review, analysis, and reporting of audit records through account management techniques. Specifying permitted actions on audit information is a way to enforce the principle of least privilege. Permitted actions are enforced by the information system and include, for example, read, write, execute, append, and delete. ü Included in NIST High Baseline, Rev 4 [information system process; role; user] AUDIT AND ACCOUNTABILITY AU-7 AUDIT REDUCTION AND REPORT GENERATION The information system provides an audit reduction and report generation capability that: a. Supports on-demand audit review, analysis, and reporting requirements and after-the-fact investigations of security incidents; and b. Does not alter the original content or time ordering of audit records. Supplemental Guidance: Audit reduction is a process that manipulates collected audit information and organizes such information in a summary format that is more meaningful to analysts. Audit reduction and report generation capabilities do not always emanate from the same information system or from the same organizational entities conducting auditing activities. Audit reduction capability can include, for example, modern data mining techniques with advanced data filters to identify anomalous behavior in audit records. The report generation capability provided by the information system can generate customizable reports. Time ordering of audit records can be a significant issue if the granularity of the timestamp in the record is insufficient. Related control: AU-6. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 AUDIT AND ACCOUNTABILITY AU-7 (1) AUDIT REDUCTION AND REPORT GENERATION | AUTOMATIC PROCESSING ü The information system provides the capability to process audit records for events of interest based on [Assignment: organization-defined audit fields within audit records]. Supplemental Guidance: Events of interest can be identified by the content of specific audit record fields including, for example, identities of individuals, event types, event locations, event times, event dates, system resources involved, IP addresses involved, or information objects accessed. Organizations may define audit event criteria to any degree of granularity required, for example, locations selectable by general networking location (e.g., by network or subnetwork) or selectable by specific information system component. Related controls: AU-2, AU-12. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 AUDIT AND ACCOUNTABILITY AU-8 TIME STAMPS ü The information system: a. Uses internal system clocks to generate time stamps for audit records; and b. Records time stamps for audit records that can be mapped to Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT) and meets [Assignment: organization-defined granularity of time measurement]. Supplemental Guidance: Time stamps generated by the information system include date and time. Time is commonly expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC. Granularity of time measurements refers to the degree of synchronization between information system clocks and reference clocks, for example, clocks synchronizing within hundreds of milliseconds or within tens of milliseconds. Organizations may define different time granularities for different system components. Time service can also be critical to other security capabilities such as access control and identification and authentication, depending on the nature of the mechanisms used to support those capabilities. Related controls: AU-3, AU-12. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 AUDIT AND ACCOUNTABILITY AU-8 (1) TIME STAMPS | SYNCHRONIZATION WITH AUTHORITATIVE TIME SOURCE ü The information system: (a) Compares the internal information system clocks [Assignment: organization-defined frequency] with [Assignment: organization-defined authoritative time source]; and (b) Synchronizes the internal system clocks to the authoritative time source when the time difference is greater than [Assignment: organization-defined time period]. Supplemental Guidance: This control enhancement provides uniformity of time stamps for information systems with multiple system clocks and systems connected over a network. ü AU-8 (1). [http://tf.nist.gov/tf-cgi/servers.cgi] <At least hourly> AU-8 (1). Requirement: The service provider selects primary and secondary time servers used by the NIST Internet time service. The secondary server is selected from a different geographic region than the primary server. Requirement: The service provider synchronizes the system clocks of network computers that run operating systems other than Windows to the Windows Server Domain Controller emulator or to the same time source for that server. Guidance: Synchronization of system clocks improves the accuracy of log analysis. ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 AUDIT AND ACCOUNTABILITY AU-9 PROTECTION OF AUDIT INFORMATION The information system protects audit information and audit tools from unauthorized access, modification, and deletion. Supplemental Guidance: Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. This control focuses on technical protection of audit information. Physical protection of audit information is addressed by media protection controls and physical and environmental protection controls. Related controls: AC-3, AC-6, MP-2, MP-4, PE-2, PE-3, PE-6. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 AUDIT AND ACCOUNTABILITY AU-9 (2) PROTECTION OF AUDIT INFORMATION | AUDIT BACKUP ON SEPARATE PHYSICAL SYSTEMS / COMPONENTS ü The information system backs up audit records [Assignment: organization-defined frequency] onto a physically different system or system component than the system or component being audited. Supplemental Guidance: This control enhancement helps to ensure that a compromise of the information system being audited does not also result in a compromise of the audit records. Related controls: AU-4, AU-5, AU-11. ü AU-9 (2). [at least weekly] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 AUDIT AND ACCOUNTABILITY AU-9 (3) PROTECTION OF AUDIT INFORMATION | CRYPTOGRAPHIC PROTECTION The information system implements cryptographic mechanisms to protect the integrity of audit information and audit tools. Supplemental Guidance: Cryptographic mechanisms used for protecting the integrity of audit information include, for example, signed hash functions using asymmetric cryptography enabling distribution of the public key to verify the hash information while maintaining the confidentiality of the secret key used to generate the hash. Related controls: AU-10, SC-12, SC-13. ü Included in NIST High Baseline, Rev 4 AUDIT AND ACCOUNTABILITY AU-9 (4) PROTECTION OF AUDIT INFORMATION | ACCESS BY SUBSET OF PRIVILEGED USERS ü The organization authorizes access to management of audit functionality to only [Assignment: organization-defined subset of privileged users]. Supplemental Guidance: Individuals with privileged access to an information system and who are also the subject of an audit by that system, may affect the reliability of audit information by inhibiting audit activities or modifying audit records. This control enhancement requires that privileged access be further defined between audit-related privileges and other privileges, thus limiting the users with audit-related privileges. Related control: AC-5. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 AUDIT AND ACCOUNTABILITY AU-10 NON-REPUDIATION ü The information system protects against an individual (or process acting on behalf of an individual) falsely denying having performed [Assignment: organization-defined actions to be covered by non-repudiation]. Supplemental Guidance: Types of individual actions covered by non-repudiation include, for example, creating information, sending and receiving messages, approving information (e.g., indicating concurrence or signing a contract). Non-repudiation protects individuals against later claims by: (i) authors of not having authored particular documents; (ii) senders of not having transmitted messages; (iii) receivers of not having received messages; or (iv) signatories of not having signed documents. Non-repudiation services can be used to determine if information originated from a particular individual, or if an individual took specific actions (e.g., sending an email, signing a contract, approving a procurement request) or received specific information. Organizations obtain non-repudiation services by employing various techniques or mechanisms (e.g., digital signatures, digital message receipts). Related controls: SC-12, SC-8, SC-13, SC-16, SC-17, SC-23. ü Included in NIST High Baseline, Rev 4 [actions including the addition, modification, deletion, approval, sending, or receiving of data] AUDIT AND ACCOUNTABILITY AU-11 AUDIT RECORD RETENTION ü The organization retains audit records for [Assignment: organization-defined time period consistent with records retention policy] to provide support for after-the-fact investigations of security incidents and to meet regulatory and organizational information retention requirements. Supplemental Guidance: Organizations retain audit records until it is determined that they are no longer needed for administrative, legal, audit, or other operational purposes. This includes, for example, retention and availability of audit records relative to Freedom of Information Act (FOIA) requests, subpoenas, and law enforcement actions. Organizations develop standard categories of audit records relative to such types of actions and standard response processes for each type of action. The National Archives and Records Administration (NARA) General Records Schedules provide federal policy on record retention. Related controls: AU-4, AU-5, AU-9, MP-6. ü ü AU-11. [at least ninety days] AU-11. Requirement: The service provider retains audit records on-line for at least ninety days and further preserves audit records off-line for a period that is in accordance with NARA requirements. ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 AU-11. [at least 1 year] AUDIT AND ACCOUNTABILITY AU-12 AUDIT GENERATION ü The information system: a. Provides audit record generation capability for the auditable events defined in AU-2 a. at [Assignment: organization-defined information system components]; b. Allows [Assignment: organization-defined personnel or roles] to select which auditable events are to be audited by specific components of the information system; and c. Generates audit records for the events defined in AU-2 d. with the content defined in AU-3. Supplemental Guidance: Audit records can be generated from many different information system components. The list of audited events is the set of events for which audits are to be generated. These events are typically a subset of all events for which the information system is capable of generating audit records. Related controls: AC-3, AU-2, AU-3, AU-6, AU-7. ü ü AU-12a. [all information system and network components where audit capability is deployed/available] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 AUDIT AND ACCOUNTABILITY AU-12 (1) AUDIT GENERATION | SYSTEM-WIDE / TIME-CORRELATED AUDIT TRAIL ü The information system compiles audit records from [Assignment: organization-defined information system components] into a system-wide (logical or physical) audit trail that is time- correlated to within [Assignment: organization-defined level of tolerance for relationship between time stamps of individual records in the audit trail]. Supplemental Guidance: Audit trails are time-correlated if the time stamps in the individual audit records can be reliably related to the time stamps in other audit records to achieve a time ordering of the records within organizational tolerances. Related controls: AU-8, AU-12. ü Included in NIST High Baseline, Rev 4 [all network, data storage, and computing devices] [organization -defined level of tolerance for relationship between time stamps of individual records in the audit trail] AUDIT AND ACCOUNTABILITY AU-12 (3) AUDIT GENERATION | CHANGES BY AUTHORIZED INDIVIDUALS ü The information system provides the capability for [Assignment: organization-defined individuals or roles] to change the auditing to be performed on [Assignment: organization-defined information system components] based on [Assignment: organization-defined selectable event criteria] within [Assignment: organization-defined time thresholds]. Supplemental Guidance: This control enhancement enables organizations to extend or limit auditing as necessary to meet organizational requirements. Auditing that is limited to conserve information system resources may be extended to address certain threat situations. In addition, auditing may be limited to a specific set of events to facilitate audit reduction, analysis, and reporting. Organizations can establish time thresholds in which audit actions are changed, for example, near real-time, within minutes, or within hours. Related control: AU-7. References: None. ü Included in NIST High Baseline, Rev 4 [service provider-defined individuals or roles with audit configuration responsibilities] [all network, data storage, and computing devices] [organization -defined threat situations] [organization -defined time thresholds]. SECURITY ASSESSMENT AND AUTHORIZATION CA-1 SECURITY ASSESSMENT AND AUTHORIZATION POLICIES AND PROCEDURES ü The organization: a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]: 1. A security assessment and authorization policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and 2. Procedures to facilitate the implementation of the security assessment and authorization policy and associated security assessment and authorization controls; and b. Reviews and updates the current: 1. Security assessment and authorization policy [Assignment: organization-defined frequency]; and 2. Security assessment and authorization procedures [Assignment: organization-defined frequency]. Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the CA family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9. Control Enhancements: None. References: NIST Special Publications 800-12, 800-37, 800-53A, 800-100. ü ü CA-1.b.1 [at least every 3 years] CA-1.b.2 [at least annually] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CA-1.b.1 [at least annually] CA-1.b.2 [at least every six months] SECURITY ASSESSMENT AND AUTHORIZATION CA-2 SECURITY ASSESSMENTS ü The organization: a. Develops a security assessment plan that describes the scope of the assessment including: 1. Security controls and control enhancements under assessment; 2. Assessment procedures to be used to determine security control effectiveness; and 3. Assessment environment, assessment team, and assessment roles and responsibilities; b. Assesses the security controls in the information system and its environment of operation [Assignment: organization-defined frequency] to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting established security requirements; c. Produces a security assessment report that documents the results of the assessment; and d. Provides the results of the security control assessment to [Assignment: organization-defined individuals or roles]. Supplemental Guidance: Organizations assess security controls in organizational information systems and the environments in which those systems operate as part of: (i) initial and ongoing security authorizations; (ii) FISMA annual assessments; (iii) continuous monitoring; and (iv) system development life cycle activities. Security assessments: (i) ensure that information security is built into organizational information systems; (ii) identify weaknesses and deficiencies early in the development process; (iii) provide essential information needed to make risk-based decisions as part of security authorization processes; and (iv) ensure compliance to vulnerability mitigation procedures. Assessments are conducted on the implemented security controls from Appendix F (main catalog) and Appendix G (Program Management controls) as documented in System Security Plans and Information Security Program Plans. Organizations can use other types of assessment activities such as vulnerability scanning and system monitoring to maintain the security posture of information systems during the entire life cycle. Security assessment reports document assessment results in sufficient detail as deemed necessary by organizations, to determine the accuracy and completeness of the reports and whether the security controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting security requirements. The FISMA requirement for assessing security controls at least annually does not require additional assessment activities to those activities already in place in organizational security authorization processes. Security assessment results are provided to the individuals or roles appropriate for the types of assessments being conducted. For example, assessments conducted in support of security authorization decisions are provided to authorizing officials or authorizing official designated representatives. To satisfy annual assessment requirements, organizations can use assessment results from the following sources: (i) initial or ongoing information system authorizations; (ii) continuous monitoring; or (iii) system development life cycle activities. Organizations ensure that security assessment results are current, relevant to the determination of security control effectiveness, and obtained with the appropriate level of assessor independence. Existing security control assessment results can be reused to the extent that the results are still valid and can also be supplemented with additional assessments as needed. Subsequent to initial authorizations and in accordance with OMB policy, organizations assess security controls during continuous monitoring. Organizations establish the frequency for ongoing security control assessments in accordance with organizational continuous monitoring strategies. Information Assurance Vulnerability Alerts provide useful examples of vulnerability mitigation procedures. External audits (e.g., audits by external entities such as regulatory agencies) are outside the scope of this control. Rela ü ü CA-2b. [at least annually] CA-2d. [individuals or roles to include FedRAMP PMO] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SECURITY ASSESSMENT AND AUTHORIZATION CA-2 (1) SECURITY ASSESSMENTS | INDEPENDENT ASSESSORS ü The organization employs assessors or assessment teams with [Assignment: organization-defined level of independence] to conduct security control assessments. Supplemental Guidance: Independent assessors or assessment teams are individuals or groups who conduct impartial assessments of organizational information systems. Impartiality implies that assessors are free from any perceived or actual conflicts of interest with regard to the development, operation, or management of the organizational information systems under assessment or to the determination of security control effectiveness. To achieve impartiality, assessors should not: (i) create a mutual or conflicting interest with the organizations where the assessments are being conducted; (ii) assess their own work; (iii) act as management or employees of the organizations they are serving; or (iv) place themselves in positions of advocacy for the organizations acquiring their services. Independent assessments can be obtained from elements within organizations or can be contracted to public or private sector entities outside of organizations. Authorizing officials determine the required level of independence based on the security categories of information systems and/or the ultimate risk to organizational operations, organizational assets, or individuals. Authorizing officials also determine if the level of assessor independence provides sufficient assurance that the results are sound and can be used to make credible, risk-based decisions. This includes determining whether contracted security assessment services have sufficient independence, for example, when information system owners are not directly involved in contracting processes or cannot unduly influence the impartiality of assessors conducting assessments. In special situations, for example, when organizations that own the information systems are small or organizational structures require that assessments are conducted by individuals that are in the developmental, operational, or management chain of system owners, independence in assessment processes can be achieved by ensuring that assessment results are carefully reviewed and analyzed by independent teams of experts to validate the completeness, accuracy, integrity, and reliability of the results. Organizations recognize that assessments performed for purposes other than direct support to authorization decisions are, when performed by assessors with sufficient independence, more likely to be useable for such decisions, thereby reducing the need to repeat assessments. ü ü Added to NIST Baseline for "Low" FedRAMP baseline. For JAB Authorization, must be an accredited 3PAO ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SECURITY ASSESSMENT AND AUTHORIZATION CA-2 (2) SECURITY ASSESSMENTS | SPECIALIZED ASSESSMENTS ü The organization includes as part of security control assessments, [Assignment: organization- defined frequency], [Selection: announced; unannounced], [Selection (one or more): in-depth monitoring; vulnerability scanning; malicious user testing; insider threat assessment; performance/load testing; [Assignment: organization-defined other forms of security assessment]]. Supplemental Guidance: Organizations can employ information system monitoring, insider threat assessments, malicious user testing, and other forms of testing (e.g., verification and validation) to improve readiness by exercising organizational capabilities and indicating current performance levels as a means of focusing actions to improve security. Organizations conduct assessment activities in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. Authorizing officials approve the assessment methods in coordination with the organizational risk executive function. Organizations can incorporate vulnerabilities uncovered during assessments into vulnerability remediation processes. Related controls: PE-3, SI-2. ü [at least annually] Requirement: To include 'announced', 'vulnerability scanning' ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SECURITY ASSESSMENT AND AUTHORIZATION CA-2 (3) SECURITY ASSESSMENTS | EXTERNAL ORGANIZATIONS ü The organization accepts the results of an assessment of [Assignment: organization-defined information system] performed by [Assignment: organization-defined external organization] when the assessment meets [Assignment: organization-defined requirements]. Supplemental Guidance: Organizations may often rely on assessments of specific information systems by other (external) organizations. Utilizing such existing assessments (i.e., reusing existing assessment evidence) can significantly decrease the time and resources required for organizational assessments by limiting the amount of independent assessment activities that organizations need to perform. The factors that organizations may consider in determining whether to accept assessment results from external organizations can vary. Determinations for accepting assessment results can be based on, for example, past assessment experiences one organization has had with another organization, the reputation that organizations have with regard to assessments, the level of detail of supporting assessment documentation provided, or mandates imposed upon organizations by federal legislation, policies, or directives. ü [Any FedRAMP Accredited 3PAO] [the conditions of a P-ATO in the FedRAMP Repository] ü Included in FedRAMP Moderate Baseline, Rev 4 SECURITY ASSESSMENT AND AUTHORIZATION CA-3 SYSTEM INTERCONNECTIONS ü The organization: a. Authorizes connections from the information system to other information systems through the use of Interconnection Security Agreements; b. Documents, for each interconnection, the interface characteristics, security requirements, and the nature of the information communicated; and c. Reviews and updates Interconnection Security Agreements [Assignment: organization-defined frequency]. Supplemental Guidance: This control applies to dedicated connections between information systems (i.e., system interconnections) and does not apply to transitory, user-controlled connections such as email and website browsing. Organizations carefully consider the risks that may be introduced when information systems are connected to other systems with different security requirements and security controls, both within organizations and external to organizations. Authorizing officials determine the risk associated with information system connections and the appropriate controls employed. If interconnecting systems have the same authorizing official, organizations do not need to develop Interconnection Security Agreements. Instead, organizations can describe the interface characteristics between those interconnecting systems in their respective security plans. If interconnecting systems have different authorizing officials within the same organization, organizations can either develop Interconnection Security Agreements or describe the interface characteristics between systems in the security plans for the respective systems. Organizations may also incorporate Interconnection Security Agreement information into formal contracts, especially for interconnections established between federal agencies and nonfederal (i.e., private sector) organizations. Risk considerations also include information systems sharing the same networks. For certain technologies (e.g., space, unmanned aerial vehicles, and medical devices), there may be specialized connections in place during preoperational testing. Such connections may require Interconnection Security Agreements and be subject to additional security controls. Related controls: AC-3, AC-4, AC-20, AU-2, AU-12, AU-16, CA-7, IA-3, SA-9, SC-7, SI-4. ü ü CA-3c. 3 Years / Annually and on input from FedRAMP ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CA-3c. At least annually and on input from FedRAMP SECURITY ASSESSMENT AND AUTHORIZATION CA-3 (3) SYSTEM INTERCONNECTIONS | UNCLASSIFIED NON-NATIONAL SECURITY SYSTEM CONNECTIONS ü The organization prohibits the direct connection of an [Assignment: organization-defined unclassified, non-national security system] to an external network without the use of [Assignment; organization-defined boundary protection device]. Supplemental Guidance: Organizations typically do not have control over external networks (e.g., the Internet). Approved boundary protection devices (e.g., routers, firewalls) mediate communications (i.e., information flows) between unclassified non-national security systems and external networks. This control enhancement is required for organizations processing, storing, or transmitting Controlled Unclassified Information (CUI). ü Boundary Protections which meet the Trusted Internet Connection (TIC) requirements CA-3(3) Guidance: Refer to Appendix H – Cloud Considerations of the TIC 2.0 Reference Architecture document. ü Included in FedRAMP Moderate Baseline, Rev 4 SECURITY ASSESSMENT AND AUTHORIZATION CA-3 (5) SYSTEM INTERCONNECTIONS | RESTRICTIONS ON EXTERNAL SYSTEM CONNECTIONS ü The organization employs [Selection: allow-all, deny-by-exception; deny-all, permit-by-exception] policy for allowing [Assignment: organization-defined information systems] to connect to external information systems. Supplemental Guidance: Organizations can constrain information system connectivity to external domains (e.g., websites) by employing one of two policies with regard to such connectivity: (i) allow-all, deny by exception, also known as blacklisting (the weaker of the two policies); or (ii) deny-all, allow by exception, also known as whitelisting (the stronger of the two policies). For either policy, organizations determine what exceptions, if any, are acceptable. Related control: CM-7. References: FIPS Publication 199; NIST Special Publication 800-47. ü For JAB Authorization, CSPs shall include details of this control in their Architecture Briefing ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 [deny-all, permit by exception] [any systems] SECURITY ASSESSMENT AND AUTHORIZATION CA-5 PLAN OF ACTION AND MILESTONES ü The organization: a. Develops a plan of action and milestones for the information system to document the organization’s planned remedial actions to correct weaknesses or deficiencies noted during the assessment of the security controls and to reduce or eliminate known vulnerabilities in the system; and b. Updates existing plan of action and milestones [Assignment: organization-defined frequency] based on the findings from security controls assessments, security impact analyses, and continuous monitoring activities. Supplemental Guidance: Plans of action and milestones are key documents in security authorization packages and are subject to federal reporting requirements established by OMB. Related controls: CA-2, CA-7, CM-4, PM-4. References: OMB Memorandum 02-01; NIST Special Publication 800-37. ü ü CA-5b. [at least monthly] CA-5 Guidance: Requirement: POA&Ms must be provided at least monthly. ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SECURITY ASSESSMENT AND AUTHORIZATION CA-6 SECURITY AUTHORIZATION ü The organization: a. Assigns a senior-level executive or manager as the authorizing official for the information system; b. Ensures that the authorizing official authorizes the information system for processing before commencing operations; and c. Updates the security authorization [Assignment: organization-defined frequency]. Supplemental Guidance: Security authorizations are official management decisions, conveyed through authorization decision documents, by senior organizational officials or executives (i.e., authorizing officials) to authorize operation of information systems and to explicitly accept the risk to organizational operations and assets, individuals, other organizations, and the Nation based on the implementation of agreed-upon security controls. Authorizing officials provide budgetary oversight for organizational information systems or assume responsibility for the mission/business operations supported by those systems. The security authorization process is an inherently federal responsibility and therefore, authorizing officials must be federal employees. Through the security authorization process, authorizing officials assume responsibility and are accountable for security risks associated with the operation and use of organizational information systems. Accordingly, authorizing officials are in positions with levels of authority commensurate with understanding and accepting such information security-related risks. OMB policy requires that organizations conduct ongoing authorizations of information systems by implementing continuous monitoring programs. Continuous monitoring programs can satisfy three-year reauthorization requirements, so separate reauthorization processes are not necessary. Through the employment of comprehensive continuous monitoring processes, critical information contained in authorization packages (i.e., security plans, security assessment reports, and plans of action and milestones) is updated on an ongoing basis, providing authorizing officials and information system owners with an up-to-date status of the security state of organizational information systems and environments of operation. To reduce the administrative cost of security reauthorization, authorizing officials use the results of continuous monitoring processes to the maximum extent possible as the basis for rendering reauthorization decisions. Related controls: CA-2, CA-7, PM-9, PM-10. Control Enhancements: None. References: OMB Circular A-130; OMB Memorandum 11-33; NIST Special Publications 800-37, 800-137. ü ü CA-6c. [at least every three years or when a significant change occurs] CA-6c. Guidance: Significant change is defined in NIST Special Publication 800-37 Revision 1, Appendix F. The service provider describes the types of changes to the information system or the environment of operations that would impact the risk posture. The types of changes are approved and accepted by the Authorizing Official. ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SECURITY ASSESSMENT AND AUTHORIZATION CA-7 CONTINUOUS MONITORING ü The organization develops a continuous monitoring strategy and implements a continuous monitoring program that includes: a. Establishment of [Assignment: organization-defined metrics] to be monitored; b. Establishment of [Assignment: organization-defined frequencies] for monitoring and [Assignment: organization-defined frequencies] for assessments supporting such monitoring; c. Ongoing security control assessments in accordance with the organizational continuous monitoring strategy; d. Ongoing security status monitoring of organization-defined metrics in accordance with the organizational continuous monitoring strategy; e. Correlation and analysis of security-related information generated by assessments and monitoring; f. Response actions to address results of the analysis of security-related information; and g. Reporting the security status of organization and the information system to [Assignment: organization-defined personnel or roles] [Assignment: organization-defined frequency]. Supplemental Guidance: Continuous monitoring programs facilitate ongoing awareness of threats, vulnerabilities, and information security to support organizational risk management decisions. The terms continuous and ongoing imply that organizations assess/analyze security controls and information security-related risks at a frequency sufficient to support organizational risk-based decisions. The results of continuous monitoring programs generate appropriate risk response actions by organizations. Continuous monitoring programs also allow organizations to maintain the security authorizations of information systems and common controls over time in highly dynamic environments of operation with changing mission/business needs, threats, vulnerabilities, and technologies. Having access to security-related information on a continuing basis through reports/dashboards gives organizational officials the capability to make more effective and timely risk management decisions, including ongoing security authorization decisions. Automation supports more frequent updates to security authorization packages, hardware/software/firmware inventories, and other system information. Effectiveness is further enhanced when continuous monitoring outputs are formatted to provide information that is specific, measurable, actionable, relevant, and timely. Continuous monitoring activities are scaled in accordance with the security categories of information systems. Related controls: CA-2, CA-5, CA-6, CM-3, CM-4, PM-6, PM- 9, RA-5, SA-11, SA-12, SI-2, SI-4. ü ü CA-7d. [To meet Federal and FedRAMP requirements] Operating System Scans: at least monthly Database and Web Application Scans: at least monthly All scans performed by Independent Assessor: at least annually CA-7 Guidance: CSPs must provide evidence of closure and remediation of high vulnerabilities within the timeframe for standard POA&M updates. ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SECURITY ASSESSMENT AND AUTHORIZATION CA-7 (1) CONTINUOUS MONITORING | INDEPENDENT ASSESSMENT ü The organization employs assessors or assessment teams with [Assignment: organization-defined level of independence] to monitor the security controls in the information system on an ongoing basis. Supplemental Guidance: Organizations can maximize the value of assessments of security controls during the continuous monitoring process by requiring that such assessments be conducted by assessors or assessment teams with appropriate levels of independence based on continuous monitoring strategies. Assessor independence provides a degree of impartiality to the monitoring process. To achieve such impartiality, assessors should not: (i) create a mutual or conflicting interest with the organizations where the assessments are being conducted; (ii) assess their own work; (iii) act as management or employees of the organizations they are serving; or (iv) place themselves in advocacy positions for the organizations acquiring their services. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SECURITY ASSESSMENT AND AUTHORIZATION CA-7 (3) CONTINUOUS MONITORING | TREND ANALYSES The organization employs trend analyses to determine if security control implementations, the frequency of continuous monitoring activities, and/or the types of activities used in the continuous monitoring process need to be modified based on empirical data. Supplemental Guidance: Trend analyses can include, for example, examining recent threat information regarding the types of threat events that have occurred within the organization or across the federal government, success rates of certain types of cyber attacks, emerging vulnerabilities in information technologies, evolving social engineering techniques, results from multiple security control assessments, the effectiveness of configuration settings, and findings from Inspectors General or auditors. ü NEED. Organization requires independent data to validate that current security monitoring continues to target the right data, and that no gaps have opened between what is currently measured and what needs to be measured given the constantly evolving threat environment. In particular, the organization determines that security management will need trend analytics tuned to the current security climate to ensure the organization’s security officials maintain general situational awareness of larger security trends that may pose a threat to the organization’s high-impact systems fielded in shared-service environments. ANALYSIS. Implementation of this control should provide security management with a technical advantage by forcing them to maintain continual current awareness of the larger security threat-scape, rather than become lost in the lower-level details of specific security metrics. Though the control is unlikely to have cost impacts, it is likely to involve implementation challenges related to validation of independent trend data sources, and reinforcement training of management to use the analyses efficiently. SAMPLE THREAT VECTORS ADDRESSED. Stakeholders do not have the information they need to make sound decisions due to technology capability. System fails to send alarms, logs, and other pertinent data to the event manager. Control processes involve too many layers of review, concurrence, and revision to support effective and timely conveyance of relevant information to decision-makers. Monitoring not effectively linked to control processes. RELEVANT SECURITY CONTROL ATTRIBUTES. Monitored, Controlled SECURITY ASSESSMENT AND AUTHORIZATION CA-8 PENETRATION TESTING ü The organization conducts penetration testing [Assignment: organization-defined frequency] on [Assignment: organization-defined information systems or system components]. Supplemental Guidance: Penetration testing is a specialized type of assessment conducted on information systems or individual system components to identify vulnerabilities that could be exploited by adversaries. Such testing can be used to either validate vulnerabilities or determine the degree of resistance organizational information systems have to adversaries within a set of specified constraints (e.g., time, resources, and/or skills). Penetration testing attempts to duplicate the actions of adversaries in carrying out hostile cyber attacks against organizations and provides a more in-depth analysis of security-related weaknesses/deficiencies. Organizations can also use the results of vulnerability analyses to support penetration testing activities. Penetration testing can be conducted on the hardware, software, or firmware components of an information system and can exercise both physical and technical security controls. A standard method for penetration testing includes, for example: (i) pretest analysis based on full knowledge of the target system; (ii) pretest identification of potential vulnerabilities based on pretest analysis; and (iii) testing designed to determine exploitability of identified vulnerabilities. All parties agree to the rules of engagement before the commencement of penetration testing scenarios. Organizations correlate the penetration testing rules of engagement with the tools, techniques, and procedures that are anticipated to be employed by adversaries carrying out attacks. Organizational risk assessments guide decisions on the level of independence required for personnel conducting penetration testing. Related control: SA-12. ü [at least annually] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SECURITY ASSESSMENT AND AUTHORIZATION CA-8 (1) PENETRATION TESTING | INDEPENDENT PENETRATION AGENT OR TEAM The organization employs an independent penetration agent or penetration team to perform penetration testing on the information system or system components. Supplemental Guidance: Independent penetration agents or teams are individuals or groups who conduct impartial penetration testing of organizational information systems. Impartiality implies that penetration agents or teams are free from any perceived or actual conflicts of interest with regard to the development, operation, or management of the information systems that are the targets of the penetration testing. Supplemental guidance for CA-2 (1) provides additional information regarding independent assessments that can be applied to penetration testing. Related control: CA-2. ü ü Included in FedRAMP Moderate Baseline, Rev 4 SECURITY ASSESSMENT AND AUTHORIZATION CA-9 INTERNAL SYSTEM CONNECTIONS ü The organization: a. Authorizes internal connections of [Assignment: organization-defined information system components or classes of components] to the information system; andb. Documents, for each internal connection, the interface characteristics, security requirements, and the nature of the information communicated.Supplemental Guidance: This control applies to connections between organizational information systems and (separate) constituent system components (i.e., intra-system connections) including, for example, system connections with mobile devices, notebook/desktop computers, printers, copiers, facsimile machines, scanners, sensors, and servers. Instead of authorizing each individual internal connection, organizations can authorize internal connections for a class of components with common characteristics and/or configurations, for example, all digital printers, scanners, and copiers with a specified processing, storage, and transmission capability or all smart phones with a specific baseline configuration. Related controls: AC-3, AC-4, AC-18, AC-19, AU-2, AU-12, CA- 7, CM-2, IA-3, SC-7, SI-4. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CONFIGURATION MANAGEMENT CM-1 CONFIGURATION MANAGEMENT POLICY AND PROCEDURES ü The organization: a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]: 1. A configuration management policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and 2. Procedures to facilitate the implementation of the configuration management policy and associated configuration management controls; and b. Reviews and updates the current: 1. Configuration management policy [Assignment: organization-defined frequency]; and 2. Configuration management procedures [Assignment: organization-defined frequency]. Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the CM family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9. Control Enhancements: None. References: NIST Special Publications 800-12, 800-100. ü ü CM-1.b.1 [at least every 3 years] CM-1.b.2 [at least annually] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CM-1.b.1 [at least annually] CM-1.b.2 [at least every six months] CONFIGURATION MANAGEMENT CM-2 BASELINE CONFIGURATION The organization develops, documents, and maintains under configuration control, a current baseline configuration of the information system. Supplemental Guidance: This control establishes baseline configurations for information systems and system components including communications and connectivity-related aspects of systems. Baseline configurations are documented, formally reviewed and agreed-upon sets of specifications for information systems or configuration items within those systems. Baseline configurations serve as a basis for future builds, releases, and/or changes to information systems. Baseline configurations include information about information system components (e.g., standard software packages installed on workstations, notebook computers, servers, network components, or mobile devices; current version numbers and patch information on operating systems and applications; and configuration settings/parameters), network topology, and the logical placement of those components within the system architecture. Maintaining baseline configurations requires creating new baselines as organizational information systems change over time. Baseline configurations of information systems reflect the current enterprise architecture. Related controls: CM-3, CM-6, CM-8, CM-9, SA-10, PM-5, PM-7. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CONFIGURATION MANAGEMENT CM-2 (1) BASELINE CONFIGURATION | REVIEWS AND UPDATES ü The organization reviews and updates the baseline configuration of the information system: (a) [Assignment: organization-defined frequency]; (b) When required due to [Assignment organization-defined circumstances]; and (c) As an integral part of information system component installations and upgrades. Supplemental Guidance: Related control: CM-5. ü CM-2 (1) (a). [at least annually] CM-2 (1) (b). [to include when directed by Authorizing Official] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CM-2 (1) (a). [at least annually or when a significant change occurs] CM-2 (1) (b). [to include when directed by Authorizing Official] CONFIGURATION MANAGEMENT CM-2 (2) BASELINE CONFIGURATION | AUTOMATION SUPPORT FOR ACCURACY / CURRENCY The organization employs automated mechanisms to maintain an up-to-date, complete, accurate, and readily available baseline configuration of the information system. Supplemental Guidance: Automated mechanisms that help organizations maintain consistent baseline configurations for information systems include, for example, hardware and software inventory tools, configuration management tools, and network management tools. Such tools can be deployed and/or allocated as common controls, at the information system level, or at the operating system or component level (e.g., on workstations, servers, notebook computers, network components, or mobile devices). Tools can be used, for example, to track version numbers on operating system applications, types of software installed, and current patch levels. This control enhancement can be satisfied by the implementation of CM-8 (2) for organizations that choose to combine information system component inventory and baseline configuration activities. Related controls: CM-7, RA-5. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CONFIGURATION MANAGEMENT CM-2 (3) BASELINE CONFIGURATION | RETENTION OF PREVIOUS CONFIGURATIONS ü The organization retains [Assignment: organization-defined previous versions of baseline configurations of the information system] to support rollback. Supplemental Guidance: Retaining previous versions of baseline configurations to support rollback may include, for example, hardware, software, firmware, configuration files, and configuration records. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CONFIGURATION MANAGEMENT CM-2 (7) BASELINE CONFIGURATION | CONFIGURE SYSTEMS, COMPONENTS, OR DEVICES FOR HIGH-RISK AREAS ü The organization: (a) Issues [Assignment: organization-defined information systems, system components, or devices] with [Assignment: organization-defined configurations] to individuals traveling to locations that the organization deems to be of significant risk; and (b) Applies [Assignment: organization-defined security safeguards] to the devices when the individuals return. Supplemental Guidance: When it is known that information systems, system components, or devices (e.g., notebook computers, mobile devices) will be located in high-risk areas, additional security controls may be implemented to counter the greater threat in such areas coupled with the lack of physical security relative to organizational-controlled areas. For example, organizational policies and procedures for notebook computers used by individuals departing on and returning from travel include, for example, determining which locations are of concern, defining required configurations for the devices, ensuring that the devices are configured as intended before travel is initiated, and applying specific safeguards to the device after travel is completed. Specially configured notebook computers include, for example, computers with sanitized hard drives, limited applications, and additional hardening (e.g., more stringent configuration settings). Specified safeguards applied to mobile devices upon return from travel include, for example, examining the device for signs of physical tampering and purging/reimaging the hard disk drive. Protecting information residing on mobile devices is covered in the media protection family.. References: NIST Special Publication 800-128. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CONFIGURATION MANAGEMENT CM-3 CONFIGURATION CHANGE CONTROL ü The organization: a. Determines the types of changes to the information system that are configuration-controlled; b. Reviews proposed configuration-controlled changes to the information system and approves or disapproves such changes with explicit consideration for security impact analyses; c. Documents configuration change decisions associated with the information system; d. Implements approved configuration-controlled changes to the information system; e. Retains records of configuration-controlled changes to the information system for [Assignment: organization-defined time period]; f. Audits and reviews activities associated with configuration-controlled changes to the information system; and g. Coordinates and provides oversight for configuration change control activities through [Assignment: organization-defined configuration change control element (e.g., committee, board] that convenes [Selection (one or more): [Assignment: organization-defined frequency]; [Assignment: organization-defined configuration change conditions]]. Supplemental Guidance: Configuration change controls for organizational information systems involve the systematic proposal, justification, implementation, testing, review, and disposition of changes to the systems, including system upgrades and modifications. Configuration change control includes changes to baseline configurations for components and configuration items of information systems, changes to configuration settings for information technology products (e.g., operating systems, applications, firewalls, routers, and mobile devices), unscheduled/unauthorized changes, and changes to remediate vulnerabilities. Typical processes for managing configuration changes to information systems include, for example, Configuration Control Boards that approve proposed changes to systems. For new development information systems or systems undergoing major upgrades, organizations consider including representatives from development organizations on the Configuration Control Boards. Auditing of changes includes activities before and after changes are made to organizational information systems and the auditing activities required to implement such changes. Related controls: CM-2, CM-4, CM-5, CM-6, CM-9, SA-10, SI-2, SI- 12. ü Requirement: The service provider establishes a central means of communicating major changes to or developments in the information system or environment of operations that may affect its services to the federal government and associated service consumers (e.g., electronic bulletin board, web status page). The means of communication are approved and accepted by the Authorizing Official. CM-3e Guidance: In accordance with record retention policies and procedures. ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CONFIGURATION MANAGEMENT CM-3 (1) CONFIGURATION CHANGE CONTROL | AUTOMATED DOCUMENT / NOTIFICATION / PROHIBITION OF CHANGES ü The organization employs automated mechanisms to: (a) Document proposed changes to the information system; (b) Notify [Assignment: organized-defined approval authorities] of proposed changes to the information system and request change approval; (c) Highlight proposed changes to the information system that have not been approved or disapproved by [Assignment: organization-defined time period]; (d) Prohibit changes to the information system until designated approvals are received; (e) Document all changes to the information system; and (f) Notify [Assignment: organization-defined personnel] when approved changes to the information system are completed. ü Included in NIST High Baseline, Rev 4 [service provider-defined configuration management approval authorities] [Organization and service provider-agreed upon time period] [service provider-defined configuration management approval authorities] CONFIGURATION MANAGEMENT CM-3 (2) CONFIGURATION CHANGE CONTROL | TEST / VALIDATE / DOCUMENT CHANGES The organization tests, validates, and documents changes to the information system before implementing the changes on the operational system. Supplemental Guidance: Changes to information systems include modifications to hardware, software, or firmware components and configuration settings defined in CM-6. Organizations ensure that testing does not interfere with information system operations. Individuals/groups conducting tests understand organizational security policies and procedures, information system security policies and procedures, and the specific health, safety, and environmental risks associated with particular facilities/processes. Operational systems may need to be taken off-line, or replicated to the extent feasible, before testing can be conducted. If information systems must be taken off-line for testing, the tests are scheduled to occur during planned system outages whenever possible. If testing cannot be conducted on operational systems, organizations employ compensating controls (e.g., testing on replicated systems). ü Included in NIST High Baseline, Rev 4 CONFIGURATION MANAGEMENT CM-4 SECURITY IMPACT ANALYSIS The organization analyzes changes to the information system to determine potential security impacts prior to change implementation. Supplemental Guidance: Organizational personnel with information security responsibilities (e.g., Information System Administrators, Information System Security Officers, Information System Security Managers, and Information System Security Engineers) conduct security impact analyses. Individuals conducting security impact analyses possess the necessary skills/technical expertise to analyze the changes to information systems and the associated security ramifications. Security impact analysis may include, for example, reviewing security plans to understand security control requirements and reviewing system design documentation to understand control implementation and how specific changes might affect the controls. Security impact analyses may also include assessments of risk to better understand the impact of the changes and to determine if additional security controls are required. Security impact analyses are scaled in accordance with the security categories of the information systems. Related controls: CA-2, CA-7, CM-3, CM-9, SA-4, SA-5, SA-10, SI-2. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CONFIGURATION MANAGEMENT CM-4 (1) SECURITY IMPACT ANALYSIS | SEPARATE TEST ENVIRONMENTS The organization analyzes changes to the information system in a separate test environment before implementation in an operational environment, looking for security impacts due to flaws, weaknesses, incompatibility, or intentional malice. Supplemental Guidance: Separate test environment in this context means an environment that is physically or logically isolated and distinct from the operational environment. The separation is sufficient to ensure that activities in the test environment do not impact activities in the operational environment, and information in the operational environment is not inadvertently transmitted to the test environment. Separate environments can be achieved by physical or logical means. If physically separate test environments are not used, organizations determine the strength of mechanism required when implementing logical separation (e.g., separation achieved through virtual machines). Related controls: SA-11, SC-3, SC-7. ü Included in NIST High Baseline, Rev 4 CONFIGURATION MANAGEMENT CM-5 ACCESS RESTRICTIONS FOR CHANGE The organization defines, documents, approves, and enforces physical and logical access restrictions associated with changes to the information system. Supplemental Guidance: Any changes to the hardware, software, and/or firmware components of information systems can potentially have significant effects on the overall security of the systems. Therefore, organizations permit only qualified and authorized individuals to access information systems for purposes of initiating changes, including upgrades and modifications. Organizations maintain records of access to ensure that configuration change control is implemented and to support after-the-fact actions should organizations discover any unauthorized changes. Access restrictions for change also include software libraries. Access restrictions include, for example, physical and logical access controls (see AC-3 and PE-3), workflow automation, media libraries, abstract layers (e.g., changes implemented into third-party interfaces rather than directly into information systems), and change windows (e.g., changes occur only during specified times, making unauthorized changes easy to discover). Related controls: AC-3, AC-6, PE-3. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CONFIGURATION MANAGEMENT CM-5 (1) ACCESS RESTRICTIONS FOR CHANGE | AUTOMATED ACCESS ENFORCEMENT / AUDITING The information system enforces access restrictions and supports auditing of the enforcement actions. Supplemental Guidance: Related controls: AU-2, AU-12, AU-6, CM-3, CM-6. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CONFIGURATION MANAGEMENT CM-5 (2) ACCESS RESTRICTIONS FOR CHANGE | REVIEW SYSTEM CHANGES ü The organization reviews information system changes [Assignment: organization-defined frequency] and [Assignment: organization-defined circumstances] to determine whether unauthorized changes have occurred. Supplemental Guidance: Indications that warrant review of information system changes and the specific circumstances justifying such reviews may be obtained from activities carried out by organizations during the configuration change process. Related controls: AU-6, AU-7, CM-3, CM-5, PE-6, PE-8. ü Included in NIST High Baseline, Rev 4 [at least every 90 days] [any change that affects the defined security posture] CONFIGURATION MANAGEMENT CM-5 (3) ACCESS RESTRICTIONS FOR CHANGE | SIGNED COMPONENTS ü The information system prevents the installation of [Assignment: organization-defined software and firmware components] without verification that the component has been digitally signed using a certificate that is recognized and approved by the organization. Supplemental Guidance: Software and firmware components prevented from installation unless signed with recognized and approved certificates include, for example, software and firmware version updates, patches, service packs, device drivers, and basic input output system (BIOS) updates. Organizations can identify applicable software and firmware components by type, by specific items, or a combination of both. Digital signatures and organizational verification of such signatures, is a method of code authentication. Related controls: CM-7, SC-13, SI-7. ü Guidance: If digital signatures/certificates are unavailable, alternative cryptographic integrity checks (hashes, self-signed certs, etc.) can be utilized. ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CONFIGURATION MANAGEMENT CM-5 (5) ACCESS RESTRICTIONS FOR CHANGE | LIMIT PRODUCTION / OPERATIONAL PRIVILEGES ü The organization: (a) Limits privileges to change information system components and system-related information within a production or operational environment; and (b) Reviews and reevaluates privileges [Assignment: organization-defined frequency]. Supplemental Guidance: In many organizations, information systems support multiple core missions/business functions. Limiting privileges to change information system components with respect to operational systems is necessary because changes to a particular information system component may have far-reaching effects on mission/business processes supported by the system where the component resides. The complex, many-to-many relationships between systems and mission/business processes are in some cases, unknown to developers. Related control: AC-2. ü CM-5 (5) (b). [at least quarterly] ü Included in FedRAMP Moderate Baseline, Rev 4 CONFIGURATION MANAGEMENT CM-6 CONFIGURATION SETTINGS ü The organization: a. Establishes and documents configuration settings for information technology products employed within the information system using [Assignment: organization-defined security configuration checklists] that reflect the most restrictive mode consistent with operational requirements; b. Implements the configuration settings; c. Identifies, documents, and approves any deviations from established configuration settings for [Assignment: organization-defined information system components] based on [Assignment: organization-defined operational requirements]; and d. Monitors and controls changes to the configuration settings in accordance with organizational policies and procedures. Supplemental Guidance: Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the information system that affect the security posture and/or functionality of the system. Information technology products for which security- related configuration settings can be defined include, for example, mainframe computers, servers (e.g., database, electronic mail, authentication, web, proxy, file, domain name), workstations, input/output devices (e.g., scanners, copiers, and printers), network components (e.g., firewalls, routers, gateways, voice and data switches, wireless access points, network appliances, sensors), operating systems, middleware, and applications. Security-related parameters are those parameters impacting the security state of information systems including the parameters required to satisfy other security control requirements. Security-related parameters include, for example: (i) registry settings; (ii) account, file, directory permission settings; and (iii) settings for functions, ports, protocols, services, and remote connections. Organizations establish organization-wide configuration settings and subsequently derive specific settings for information systems. The established settings become part of the systems configuration baseline. Common secure configurations (also referred to as security configuration checklists, lockdown and hardening guides, security reference guides, security technical implementation guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for specific information technology platforms/products and instructions for configuring those information system components to meet operational requirements. Common secure configurations can be developed by a variety of organizations including, for example, information technology product developers, manufacturers, vendors, consortia, academia, industry, federal agencies, and other organizations in the public and private sectors. Common secure configurations include the United States Government Configuration Baseline (USGCB) which affects the implementation of CM-6 and other controls such as AC-19 and CM-7. The Security Content Automation Protocol (SCAP) and the defined standards within the protocol (e.g., Common Configuration Enumeration) provide an effective method to uniquely identify, track, and control configuration settings. OMB establishes federal policy on configuration requirements for federal information systems. Related controls: AC-19, CM-2, CM-3, CM-7, SI-4. ü ü CM-6a. [United States Government Configuration Baseline (USGCB)] CM-6a. Requirement: The service provider shall use the Center for Internet Security guidelines (Level 1) to establish configuration settings or establishes its own configuration settings if USGCB is not available. CM-6a. Requirement: The service provider shall ensure that checklists for configuration settings are Security Content Automation Protocol (SCAP) validated or SCAP compatible (if validated checklists are not available). CM-6a. Guidance: Information on the USGCB checklists can be found at: http://usgcb.nist.gov/usgcb_faq.html#usgcbfaq_usgcbfdcc ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CONFIGURATION MANAGEMENT CM-6 (1) CONFIGURATION SETTINGS | AUTOMATED CENTRAL MANAGEMENT / APPLICATION / VERIFICATION ü The organization employs automated mechanisms to centrally manage, apply, and verify configuration settings for [Assignment: organization-defined information system components]. Supplemental Guidance: Related controls: CA-7, CM-4. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CONFIGURATION MANAGEMENT CM-6 (2) CONFIGURATION SETTINGS | RESPOND TO UNAUTHORIZED CHANGES ü The organization employs [Assignment: organization-defined security safeguards] to respond to unauthorized changes to [Assignment: organization-defined configuration settings]. Supplemental Guidance: Responses to unauthorized changes to configuration settings can include, for example, alerting designated organizational personnel, restoring established configuration settings, or in extreme cases, halting affected information system processing. Related controls: IR-4, SI-7. ü Included in NIST High Baseline, Rev 4 [service provider-defined security safeguards] [service provider-defined configuration settings]. CONFIGURATION MANAGEMENT CM-7 LEAST FUNCTIONALITY ü The organization: a. Configures the information system to provide only essential capabilities; and b. Prohibits or restricts the use of the following functions, ports, protocols, and/or services: [Assignment: organization-defined prohibited or restricted functions, ports, protocols, and/or services]. Supplemental Guidance: Information systems can provide a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions). Additionally, it is sometimes convenient to provide multiple services from single information system components, but doing so increases risk over limiting the services provided by any one component. Where feasible, organizations limit component functionality to a single function per device (e.g., email servers or web servers, but not both). Organizations review functions and services provided by information systems or individual components of information systems, to determine which functions and services are candidates for elimination (e.g., Voice Over Internet Protocol, Instant Messaging, auto-execute, and file sharing). Organizations consider disabling unused or unnecessary physical and logical ports/protocols (e.g., Universal Serial Bus, File Transfer Protocol, and Hyper Text Transfer Protocol) on information systems to prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling. Organizations can utilize network scanning tools, intrusion detection and prevention systems, and end-point protections such as firewalls and host-based intrusion detection systems to identify and prevent the use of prohibited functions, ports, protocols, and services. Related controls: AC-6, CM-2, RA-5, SA-5, SC-7. ü ü CM-7. [United States Government Configuration Baseline (USGCB)] Requirement: The service provider shall use the Center for Internet Security guidelines (Level 1) to establish list of prohibited or restricted functions, ports, protocols, and/or services or establishes its own list of prohibited or restricted functions, ports, protocols, and/or services if USGCB is not available. CM-7. Guidance: Information on the USGCB checklists can be found at: http://usgcb.nist.gov/usgcb_faq.html#usgcbfaq_usgcbfdcc. (Partially derived from AC-17(8).) ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CONFIGURATION MANAGEMENT CM-7 (1) LEAST FUNCTIONALITY | PERIODIC REVIEW ü The organization: (a) Reviews the information system [Assignment: organization-defined frequency] to identify unnecessary and/or nonsecure functions, ports, protocols, and services; and (b) Disables [Assignment: organization-defined functions, ports, protocols, and services within the information system deemed to be unnecessary and/or nonsecure]. Supplemental Guidance: The organization can either make a determination of the relative security of the function, port, protocol, and/or service or base the security decision on the assessment of other entities. Bluetooth, FTP, and peer-to-peer networking are examples of less than secure protocols. Related controls: AC-18, CM-7, IA-2. ü CM-7 (1). [at least monthly] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CONFIGURATION MANAGEMENT CM-7 (2) LEAST FUNCTIONALITY | PREVENT PROGRAM EXECUTION ü The information system prevents program execution in accordance with [Selection (one or more): [Assignment: organization-defined policies regarding software program usage and restrictions]; rules authorizing the terms and conditions of software program usage]. Supplemental Guidance: Related controls: CM-8, PM-5. ü CM-7(2) Guidance: This control shall be implemented in a technical manner on the information system to only allow programs to run that adhere to the policy (i.e. white listing). This control is not to be based off of strictly written policy on what is allowed or not allowed to run. ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CONFIGURATION MANAGEMENT CM-7 (5) LEAST FUNCTIONALITY | AUTHORIZED SOFTWARE / WHITELISTING ü The organization: (a) Identifies [Assignment: organization-defined software programs authorized to execute on the information system]; (b) Employs a deny-all, permit-by-exception policy to allow the execution of authorized software programs on the information system; and (c) Reviews and updates the list of authorized software programs [Assignment: organization- defined frequency]. Supplemental Guidance: The process used to identify software programs that are authorized to execute on organizational information systems is commonly referred to as whitelisting. In addition to whitelisting, organizations consider verifying the integrity of white-listed software programs using, for example, cryptographic checksums, digital signatures, or hash functions. Verification of white-listed software can occur either prior to execution or at system startup. Related controls: CM-2, CM-6, CM-8, PM-5, SA-10, SC-34, SI-7. References: DoD Instruction 8551.01. ü CM-7(5)[ at least Annually or when there is a change.] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 [at least quarterly or when there is a change] CONFIGURATION MANAGEMENT CM-8 INFORMATION SYSTEM COMPONENT INVENTORY ü The organization: a. Develops and documents an inventory of information system components that: 1. Accurately reflects the current information system; 2. Includes all components within the authorization boundary of the information system; 3. Is at the level of granularity deemed necessary for tracking and reporting; and 4. Includes [Assignment: organization-defined information deemed necessary to achieve effective information system component accountability]; and b. Reviews and updates the information system component inventory [Assignment: organization-defined frequency]. Supplemental Guidance: Organizations may choose to implement centralized information system component inventories that include components from all organizational information systems. In such situations, organizations ensure that the resulting inventories include system-specific information required for proper component accountability (e.g., information system association, information system owner). Information deemed necessary for effective accountability of information system components includes, for example, hardware inventory specifications, software license information, software version numbers, component owners, and for networked components or devices, machine names and network addresses. Inventory specifications include, for example, manufacturer, device type, model, serial number, and physical location. Related controls: CM-2, CM-6, PM-5. ü ü CM-8b. [at least monthly] CM-8 Requirement: must be provided at least monthly or when there is a change. ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CONFIGURATION MANAGEMENT CM-8 (1) INFORMATION SYSTEM COMPONENT INVENTORY | UPDATES DURING INSTALLATIONS / REMOVALS The organization updates the inventory of information system components as an integral part of component installations, removals, and information system updates. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CONFIGURATION MANAGEMENT CM-8 (2) INFORMATION SYSTEM COMPONENT INVENTORY | AUTOMATED MAINTENANCE The organization employs automated mechanisms to help maintain an up-to-date, complete, accurate, and readily available inventory of information system components. Supplemental Guidance: Organizations maintain information system inventories to the extent feasible. Virtual machines, for example, can be difficult to monitor because such machines are not visible to the network when not in use. In such cases, organizations maintain as up-to- date, complete, and accurate an inventory as is deemed reasonable. This control enhancement can be satisfied by the implementation of CM-2 (2) for organizations that choose to combine information system component inventory and baseline configuration activities. Related control: SI-7. ü Included in NIST High Baseline, Rev 4 CONFIGURATION MANAGEMENT CM-8 (3) INFORMATION SYSTEM COMPONENT INVENTORY | AUTOMATED UNAUTHORIZED COMPONENT DETECTION ü The organization: (a) Employs automated mechanisms [Assignment: organization-defined frequency] to detect the presence of unauthorized hardware, software, and firmware components within the information system; and (b) Takes the following actions when unauthorized components are detected: [Selection (one or more): disables network access by such components; isolates the components; notifies [Assignment: organization-defined personnel or roles]]. Supplemental Guidance: This control enhancement is applied in addition to the monitoring for unauthorized remote connections and mobile devices. Monitoring for unauthorized system components may be accomplished on an ongoing basis or by the periodic scanning of systems for that purpose. Automated mechanisms can be implemented within information systems or in other separate devices. Isolation can be achieved, for example, by placing unauthorized information system components in separate domains or subnets or otherwise quarantining such components. This type of component isolation is commonly referred to as sandboxing. Related controls: AC-17, AC-18, AC-19, CA-7, SI-3, SI-4, SI-7, RA-5. ü CM-8 (3) (a). [Continuously, using automated mechanisms with a maximum five-minute delay in detection.] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CONFIGURATION MANAGEMENT CM-8 (4) INFORMATION SYSTEM COMPONENT INVENTORY | ACCOUNTABILITY INFORMATION ü The organization includes in the information system component inventory information, a means for identifying by [Selection (one or more): name; position; role], individuals responsible/accountable for administering those components. Supplemental Guidance: Identifying individuals who are both responsible and accountable for administering information system components helps to ensure that the assigned components are properly administered and organizations can contact those individuals if some action is required (e.g., component is determined to be the source of a breach/compromise, component needs to be recalled/replaced, or component needs to be relocated). ü Included in NIST High Baseline, Rev 4 [position and role] CONFIGURATION MANAGEMENT CM-8 (5) INFORMATION SYSTEM COMPONENT INVENTORY | NO DUPLICATE ACCOUNTING OF COMPONENTS The organization verifies that all components within the authorization boundary of the information system are not duplicated in other information system inventories. Supplemental Guidance: This control enhancement addresses the potential problem of duplicate accounting of information system components in large or complex interconnected systems. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CONFIGURATION MANAGEMENT CM-9 CONFIGURATION MANAGEMENT PLAN The organization develops, documents, and implements a configuration management plan for the information system that: a. Addresses roles, responsibilities, and configuration management processes and procedures; b. Establishes a process for identifying configuration items throughout the system development life cycle and for managing the configuration of the configuration items; c. Defines the configuration items for the information system and places the configuration items under configuration management; and d. Protects the configuration management plan from unauthorized disclosure and modification. Supplemental Guidance: Configuration management plans satisfy the requirements in configuration management policies while being tailored to individual information systems. Such plans define detailed processes and procedures for how configuration management is used to support system development life cycle activities at the information system level. Configuration management plans are typically developed during the development/acquisition phase of the system development life cycle. The plans describe how to move changes through change management processes, how to update configuration settings and baselines, how to maintain information system component inventories, how to control development, test, and operational environments, and how to develop, release, and update key documents. Organizations can employ templates to help ensure consistent and timely development and implementation of configuration management plans. Such templates can represent a master configuration management plan for the organization at large with subsets of the plan implemented on a system by system basis. Configuration management approval processes include designation of key management stakeholders responsible for reviewing and approving proposed changes to information systems, and personnel that conduct security impact analyses prior to the implementation of changes to the systems. Configuration items are the information system items (hardware, software, firmware, and documentation) to be configuration-managed. As information systems continue through the system development life cycle, new configuration items may be identified and some existing configuration items may no longer need to be under configuration control. Related controls: CM-2, CM-3, CM-4, CM-5, CM-8, SA-10. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CONFIGURATION MANAGEMENT CM-10 SOFTWARE USAGE RESTRICTIONS The organization: a. Uses software and associated documentation in accordance with contract agreements and copyright laws; b. Tracks the use of software and associated documentation protected by quantity licenses to control copying and distribution; and c. Controls and documents the use of peer-to-peer file sharing technology to ensure that this capability is not used for the unauthorized distribution, display, performance, or reproduction of copyrighted work. Supplemental Guidance: Software license tracking can be accomplished by manual methods (e.g., simple spreadsheets) or automated methods (e.g., specialized tracking applications) depending on organizational needs. Related controls: AC-17, CM-8, SC-7. Supplemental Guidance: Open source software refers to software that is available in source code form. Certain software rights normally reserved for copyright holders are routinely provided under software license agreements that permit individuals to study, change, and improve the software. From a security perspective, the major advantage of open source software is that it provides organizations with the ability to examine the source code. However, there are also various licensing issues associated with open source software including, for example, the constraints on derivative use of such software. References: None. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CONFIGURATION MANAGEMENT CM-10 (1) SOFTWARE USAGE RESTRICTIONS | OPEN SOURCE SOFTWARE ü The organization establishes the following restrictions on the use of open source software: [Assignment: organization-defined restrictions]. Supplemental Guidance: Open source software refers to software that is available in source code form. Certain software rights normally reserved for copyright holders are routinely provided under software license agreements that permit individuals to study, change, and improve the software. From a security perspective, the major advantage of open source software is that it provides organizations with the ability to examine the source code. However, there are also various licensing issues associated with open source software including, for example, the constraints on derivative use of such software. ü ü Included in FedRAMP Moderate Baseline, Rev 4 CONFIGURATION MANAGEMENT CM-11 USER-INSTALLED SOFTWARE ü The organization: a. Establishes [Assignment: organization-defined policies] governing the installation of software by users; b. Enforces software installation policies through [Assignment: organization-defined methods]; and c. Monitors policy compliance at [Assignment: organization-defined frequency]. Supplemental Guidance: If provided the necessary privileges, users have the ability to install software in organizational information systems. To maintain control over the types of software installed, organizations identify permitted and prohibited actions regarding software installation. Permitted software installations may include, for example, updates and security patches to existing software and downloading applications from organization-approved “app stores.†Prohibited software installations may include, for example, software with unknown or suspect pedigrees or software that organizations consider potentially malicious. The policies organizations select governing user-installed software may be organization-developed or provided by some external entity. Policy enforcement methods include procedural methods (e.g., periodic examination of user accounts), automated methods (e.g., configuration settings implemented on organizational information systems), or both. Related controls: AC-3, CM-2, CM-3, CM-5, CM-6, CM-7, PL-4. ü ü CM-11.c. [Continuously (via CM-7 (5))] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CONFIGURATION MANAGEMENT CM-11 (1) USER-INSTALLED SOFTWARE | ALERTS FOR UNAUTHORIZED INSTALLATIONS ü The information system alerts [Assignment: organization-defined personnel or roles] when the unauthorized installation of software is detected. Supplemental Guidance: Related controls: CA-7, SI-4. ü NEED. High-impact systems will require special measures to ensure users cannot place the overall system at risk by installing unauthorized software. This control supports that need. ANALYSIS. Implementation of these controls is well understood, and relies on capabilities provided in COTS operating systems. SAMPLE THREAT VECTORS. The system executes malicious and harmful software. Software updates could render the system unstable or cause it to function incorrectly. Software is not designed with adequate safeguards to protect PII and other sensitive information. Users could make mistakes in following policy. Users could intentionally install unapproved/unvetted software. RELEVANT SECURITY CONTROL ATTRIBUTES. Quality Assured, Substantiated Integrity, Maintainable, Testable, Configuration Managed, Change Managed, Supported, Assessed, Auditable, Authorized, Regulated, Enforcement, Controlled, Reliable, Providing Good Data Stewardship, Assured, Confidential, Access-Controlled [service provider-defined personnel or roles] CONTINGENCY PLANNING CP-1 CONTINGENCY PLANNING POLICY AND PROCEDURES ü The organization: a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]: 1. A contingency planning policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and 2. Procedures to facilitate the implementation of the contingency planning policy and associated contingency planning controls; and b. Reviews and updates the current: 1. Contingency planning policy [Assignment: organization-defined frequency]; and 2. Contingency planning procedures [Assignment: organization-defined frequency]. Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the CP family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9. Control Enhancements: None. References: Federal Continuity Directive 1; NIST Special Publications 800-12, 800-34, 800-100. ü ü CP-1.b.1 [at least every 3 years] CP-1.b.2 [at least annually] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CP-1.b.1 [at least annually] CP-1.b.2 [at least annually] CONTINGENCY PLANNING CP-2 CONTINGENCY PLAN ü The organization: a. Develops a contingency plan for the information system that: 1. Identifies essential missions and business functions and associated contingency requirements; 2. Provides recovery objectives, restoration priorities, and metrics; 3. Addresses contingency roles, responsibilities, assigned individuals with contact information; 4. Addresses maintaining essential missions and business functions despite an information system disruption, compromise, or failure; 5. Addresses eventual, full information system restoration without deterioration of the security safeguards originally planned and implemented; and 6. Is reviewed and approved by [Assignment: organization-defined personnel or roles]; b. Distributes copies of the contingency plan to [Assignment: organization-defined key contingency personnel (identified by name and/or by role) and organizational elements]; c. Coordinates contingency planning activities with incident handling activities; d. Reviews the contingency plan for the information system [Assignment: organization-defined frequency]; e. Updates the contingency plan to address changes to the organization, information system, or environment of operation and problems encountered during contingency plan implementation, execution, or testing; f. Communicates contingency plan changes to [Assignment: organization-defined key contingency personnel (identified by name and/or by role) and organizational elements]; and g. Protects the contingency plan from unauthorized disclosure and modification. Supplemental Guidance: Contingency planning for information systems is part of an overall organizational program for achieving continuity of operations for mission/business functions. Contingency planning addresses both information system restoration and implementation of alternative mission/business processes when systems are compromised. The effectiveness of contingency planning is maximized by considering such planning throughout the phases of the system development life cycle. Performing contingency planning on hardware, software, and firmware development can be an effective means of achieving information system resiliency. Contingency plans reflect the degree of restoration required for organizational information systems since not all systems may need to fully recover to achieve the level of continuity of operations desired. Information system recovery objectives reflect applicable laws, Executive Orders, directives, policies, standards, regulations, and guidelines. In addition to information system availability, contingency plans also address other security-related events resulting in a reduction in mission and/or business effectiveness, such as malicious attacks compromising the confidentiality or integrity of information systems. Actions addressed in contingency plans include, for example, orderly/graceful degradation, information system shutdown, fallback to a manual mode, alternate information flows, and operating in modes reserved for when systems are under attack. By closely coordinating contingency planning with incident handling activities, organizations can ensure that the necessary contingency planning activities are in place and activated in the event of a security incident. Related controls: AC-14, CP-6, CP-7, CP-8, CP-9, CP-10, IR-4, IR-8, MP-2, MP-4, MP-5, PM-8, PM-11. ü ü CP-2d. [at least annually] Requirement: For JAB authorizations the contingency lists include designated FedRAMP personnel. ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CONTINGENCY PLANNING CP-9 (1) INFORMATION SYSTEM BACKUP | TESTING FOR RELIABILITY / INTEGRITY ü The organization tests backup information [Assignment: organization-defined frequency] to verify media reliability and information integrity. Supplemental Guidance: Related control: CP-4. ü CP-9 (1). [at least annually] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CP-9 (1). [at least monthly] CONTINGENCY PLANNING CP-9 (2) INFORMATION SYSTEM BACKUP | TEST RESTORATION USING SAMPLING The organization uses a sample of backup information in the restoration of selected information system functions as part of contingency plan testing. Supplemental Guidance: Related control: CP-4. ü Included in NIST High Baseline, Rev 4 CONTINGENCY PLANNING CP-9 (3) INFORMATION SYSTEM BACKUP | SEPARATE STORAGE FOR CRITICAL INFORMATION ü The organization stores backup copies of [Assignment: organization-defined critical information system software and other security-related information] in a separate facility or in a fire-rated container that is not collocated with the operational system. Supplemental Guidance: Critical information system software includes, for example, operating systems, cryptographic key management systems, and intrusion detection/prevention systems. Security-related information includes, for example, organizational inventories of hardware, software, and firmware components. Alternate storage sites typically serve as separate storage facilities for organizations. Related controls: CM-2, CM-8. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CONTINGENCY PLANNING CP-9 (5) INFORMATION SYSTEM BACKUP | TRANSFER TO ALTERNATE STORAGE SITE ü The organization transfers information system backup information to the alternate storage site [Assignment: organization-defined time period and transfer rate consistent with the recovery time and recovery point objectives]. Supplemental Guidance: Information system backup information can be transferred to alternate storage sites either electronically or by physical shipment of storage media. ü Included in NIST High Baseline, Rev 4 [time period and transfer rate consistent with the recovery time and recovery point objectives defined in the service provider and organization SLA]. CONTINGENCY PLANNING CP-10 INFORMATION SYSTEM RECOVERY AND RECONSTITUTION The organization provides for the recovery and reconstitution of the information system to a known state after a disruption, compromise, or failure. Supplemental Guidance: Recovery is executing information system contingency plan activities to restore organizational missions/business functions. Reconstitution takes place following recovery and includes activities for returning organizational information systems to fully operational states. Recovery and reconstitution operations reflect mission and business priorities, recovery point/time and reconstitution objectives, and established organizational metrics consistent with contingency plan requirements. Reconstitution includes the deactivation of any interim information system capabilities that may have been needed during recovery operations. Reconstitution also includes assessments of fully restored information system capabilities, reestablishment of continuous monitoring activities, potential information system reauthorizations, and activities to prepare the systems against future disruptions, compromises, or failures. Recovery/reconstitution capabilities employed by organizations can include both automated mechanisms and manual procedures. Related controls: CA-2, CA-6, CA-7, CP-2, CP-6, CP-7, CP-9, SC-24. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CONTINGENCY PLANNING CP-10 (2) INFORMATION SYSTEM RECOVERY AND RECONSTITUTION | TRANSACTION RECOVERY The information system implements transaction recovery for systems that are transaction-based. Supplemental Guidance: Transaction-based information systems include, for example, database management systems and transaction processing systems. Mechanisms supporting transaction recovery include, for example, transaction rollback and transaction journaling. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 CONTINGENCY PLANNING CP-10 (4) INFORMATION SYSTEM RECOVERY AND RECONSTITUTION | RESTORE WITHIN TIME PERIOD ü The organization provides the capability to restore information system components within [Assignment: organization-defined restoration time-periods] from configuration-controlled and integrity-protected information representing a known, operational state for the components. Supplemental Guidance: Restoration of information system components includes, for example, reimaging which restores components to known, operational states. Related control: CM-2. ü Included in NIST High Baseline, Rev 4 [time period consistent with the restoration time-periods defined in the service provider and organization SLA] IDENTIFICATION AND AUTHENTICATION IA-1 IDENTIFICATION AND AUTHENTICATION POLICY AND PROCEDURES ü The organization: a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]: 1. An identification and authentication policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and 2. Procedures to facilitate the implementation of the identification and authentication policy and associated identification and authentication controls; and b. Reviews and updates the current: 1. Identification and authentication policy [Assignment: organization-defined frequency]; and 2. Identification and authentication procedures [Assignment: organization-defined frequency]. Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the IA family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9. Control Enhancements: None. References: FIPS Publication 201; NIST Special Publications 800-12, 800-63, 800-73, 800-76, 800-78, 800-100. ü ü IA-1.b.1 [at least every 3 years] IA-1.b.2 [at least annually] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 IA-1.b.1 [at least annually] IA-1.b.2 [at least every six months] IDENTIFICATION AND AUTHENTICATION IA-2 IDENTIFICATION AND AUTHENTICATION (ORGANIZATIONAL USERS) The information system uniquely identifies and authenticates organizational users (or processes acting on behalf of organizational users). Supplemental Guidance: Organizational users include employees or individuals that organizations deem to have equivalent status of employees (e.g., contractors, guest researchers). This control applies to all accesses other than: (i) accesses that are explicitly identified and documented in AC- 14; and (ii) accesses that occur through authorized use of group authenticators without individual authentication. Organizations may require unique identification of individuals in group accounts (e.g., shared privilege accounts) or for detailed accountability of individual activity. Organizations employ passwords, tokens, or biometrics to authenticate user identities, or in the case multifactor authentication, or some combination thereof. Access to organizational information systems is defined as either local access or network access. Local access is any access to organizational information systems by users (or processes acting on behalf of users) where such access is obtained by direct connections without the use of networks. Network access is access to organizational information systems by users (or processes acting on behalf of users) where such access is obtained through network connections (i.e., nonlocal accesses). Remote access is a type of network access that involves communication through external networks (e.g., the Internet). Internal networks include local area networks and wide area networks. In addition, the use of encrypted virtual private networks (VPNs) for network connections between organization- controlled endpoints and non-organization controlled endpoints may be treated as internal networks from the perspective of protecting the confidentiality and integrity of information traversing the network. Organizations can satisfy the identification and authentication requirements in this control by complying with the requirements in Homeland Security Presidential Directive 12 consistent with the specific organizational implementation plans. Multifactor authentication requires the use of two or more different factors to achieve authentication. The factors are defined as: (i) something you know (e.g., password, personal identification number [PIN]); (ii) something you have (e.g., cryptographic identification device, token); or (iii) something you are (e.g., biometric). Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification card and the DoD common access card. In addition to identifying and authenticating users at the information system level (i.e., at logon), organizations also employ identification and authentication mechanisms at the application level, when necessary, to provide increased information security. Identification and authentication requirements for other than organizational users are described in IA-8. Related controls: AC-2, AC-3, AC-14, AC-17, AC-18, IA-4, IA-5, IA-8. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 IDENTIFICATION AND AUTHENTICATION IA-2 (1) IDENTIFICATION AND AUTHENTICATION | NETWORK ACCESS TO PRIVILEGED ACCOUNTS The information system implements multifactor authentication for network access to privileged accounts. Supplemental Guidance: Related control: AC-6. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 IDENTIFICATION AND AUTHENTICATION IA-2 (2) IDENTIFICATION AND AUTHENTICATION | NETWORK ACCESS TO NON-PRIVILEGED ACCOUNTS The information system implements multifactor authentication for network access to non- privileged accounts. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 IDENTIFICATION AND AUTHENTICATION IA-2 (3) IDENTIFICATION AND AUTHENTICATION | LOCAL ACCESS TO PRIVILEGED ACCOUNTS The information system implements multifactor authentication for local access to privileged accounts. Supplemental Guidance: Related control: AC-6. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 IDENTIFICATION AND AUTHENTICATION IA-2 (4) IDENTIFICATION AND AUTHENTICATION | LOCAL ACCESS TO NON-PRIVILEGED ACCOUNTS The information system implements multifactor authentication for local access to non-privileged accounts. ü Included in NIST High Baseline, Rev 4 IDENTIFICATION AND AUTHENTICATION IA-2 (5) IDENTIFICATION AND AUTHENTICATION (ORGANIZATIONAL USERS) | GROUP AUTHENTICATION The organization requires individuals to be authenticated with an individual authenticator when a group authenticator is employed. Supplemental Guidance: Requiring individuals to use individual authenticators as a second level of authentication helps organizations to mitigate the risk of using group authenticators. ü ü Included in FedRAMP Moderate Baseline, Rev 4 IDENTIFICATION AND AUTHENTICATION IA-2 (8) IDENTIFICATION AND AUTHENTICATION | NETWORK ACCESS TO PRIVILEGED ACCOUNTS - REPLAY RESISTANT The information system implements replay-resistant authentication mechanisms for network access to privileged accounts. Supplemental Guidance: Authentication processes resist replay attacks if it is impractical to achieve successful authentications by replaying previous authentication messages. Replay- resistant techniques include, for example, protocols that use nonces or challenges such as Transport Layer Security (TLS) and time synchronous or challenge-response one-time authenticators. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 IDENTIFICATION AND AUTHENTICATION IA-2 (9) IDENTIFICATION AND AUTHENTICATION | NETWORK ACCESS TO NON-PRIVILEGED ACCOUNTS - REPLAY RESISTANT The information system implements replay-resistant authentication mechanisms for network access to non-privileged accounts. Supplemental Guidance: Authentication processes resist replay attacks if it is impractical to achieve successful authentications by recording/replaying previous authentication messages. Replay-resistant techniques include, for example, protocols that use nonces or challenges such as Transport Layer Security (TLS) and time synchronous or challenge-response one-time authenticators. ü Included in NIST High Baseline, Rev 4 IDENTIFICATION AND AUTHENTICATION IA-2 (11) IDENTIFICATION AND AUTHENTICATION | REMOTE ACCESS - SEPARATE DEVICE ü The information system implements multifactor authentication for remote access to privileged and non-privileged accounts such that one of the factors is provided by a device separate from the system gaining access and the device meets [Assignment: organization-defined strength of mechanism requirements]. Supplemental Guidance: For remote access to privileged/non-privileged accounts, the purpose of requiring a device that is separate from the information system gaining access for one of the factors during multifactor authentication is to reduce the likelihood of compromising authentication credentials stored on the system. For example, adversaries deploying malicious code on organizational information systems can potentially compromise such credentials resident on the system and subsequently impersonate authorized users. Related control: AC-6. ü The information system implements multifactor authentication for remote access to privileged and non-privileged accounts such that one of the factors is provided by a device separate from the system gaining access and the device meets [Assignment: organization-defined strength of mechanism requirements]. PIV = separate device ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 [FIPS 140-2, NIAP Certification, or NSA approval] IDENTIFICATION AND AUTHENTICATION IA-2 (12) IDENTIFICATION AND AUTHENTICATION | ACCEPTANCE OF PIV CREDENTIALS The information system accepts and electronically verifies Personal Identity Verification (PIV) credentials. Supplemental Guidance: This control enhancement applies to organizations implementing logical access control systems (LACS) and physical access control systems (PACS). Personal Identity Verification (PIV) credentials are those credentials issued by federal agencies that conform to FIPS Publication 201 and supporting guidance documents. OMB Memorandum 11-11 requires federal agencies to continue implementing the requirements specified in HSPD-12 to enable agency-wide use of PIV credentials. Related controls: AU-2, PE-3, SA-4. ü ü Guidance: Include Common Access Card (CAC), i.e., the DoD technical implementation of PIV/FIPS 201/HSPD-12. ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 IDENTIFICATION AND AUTHENTICATION IA-3 DEVICE IDENTIFICATION AND AUTHENTICATION ü The information system uniquely identifies and authenticates [Assignment: organization- defined specific and/or types of devices] before establishing a [Selection (one or more): local; remote; network] connection. Supplemental Guidance: Organizational devices requiring unique device-to-device identification and authentication may be defined by type, by device, or by a combination of type/device. Information systems typically use either shared known information (e.g., Media Access Control [MAC] or Transmission Control Protocol/Internet Protocol [TCP/IP] addresses) for device identification or organizational authentication solutions (e.g., IEEE 802.1x and Extensible Authentication Protocol [EAP], Radius server with EAP-Transport Layer Security [TLS] authentication, Kerberos) to identify/authenticate devices on local and/or wide area networks. Organizations determine the required strength of authentication mechanisms by the security categories of information systems. Because of the challenges of applying this control on large scale, organizations are encouraged to only apply the control to those limited number (and type) of devices that truly need to support this capability. Related controls: AC-17, AC-18, AC-19, CA-3, IA-4, IA-5. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 IDENTIFICATION AND AUTHENTICATION IA-4 IDENTIFIER MANAGEMENT ü The organization manages information system identifiers by: a. Receiving authorization from [Assignment: organization-defined personnel or roles] to assign an individual, group, role, or device identifier; b. Selecting an identifier that identifies an individual, group, role, or device; c. Assigning the identifier to the intended individual, group, role, or device; d. Preventing reuse of identifiers for [Assignment: organization-defined time period]; and e. Disabling the identifier after [Assignment: organization-defined time period of inactivity]. Supplemental Guidance: Common device identifiers include, for example, media access control (MAC), Internet protocol (IP) addresses, or device-unique token identifiers. Management of individual identifiers is not applicable to shared information system accounts (e.g., guest and anonymous accounts). Typically, individual identifiers are the user names of the information system accounts assigned to those individuals. In such instances, the account management activities of AC-2 use account names provided by IA-4. This control also addresses individual identifiers not necessarily associated with information system accounts (e.g., identifiers used in physical security control databases accessed by badge reader systems for access to information systems). Preventing reuse of identifiers implies preventing the assignment of previously used individual, group, role, or device identifiers to different individuals, groups, roles, or devices. Related controls: AC-2, IA-2, IA-3, IA-5, IA-8, SC-37. ü ü IA-4d. [at least two years] IA-4e. [ninety days for user identifiers] (See additional requirements and guidance.) IA-4e. Requirement: The service provider defines time period of inactivity for device identifiers. ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 IDENTIFICATION AND AUTHENTICATION IA-4 (4) IDENTIFIER MANAGEMENT | IDENTIFY USER STATUS ü The organization manages individual identifiers by uniquely identifying each individual as [Assignment: organization-defined characteristic identifying individual status]. Supplemental Guidance: Characteristics identifying the status of individuals include, for example, contractors and foreign nationals. Identifying the status of individuals by specific characteristics provides additional information about the people with whom organizational personnel are communicating. For example, it might be useful for a government employee to know that one of the individuals on an email message is a contractor. Related control: AT-2. ü IA-4 (4). [contractors; foreign nationals] ü Included in FedRAMP Moderate Baseline, Rev 4 IDENTIFICATION AND AUTHENTICATION IA-5 AUTHENTICATOR MANAGEMENT ü The organization manages information system authenticators by: a. Verifying, as part of the initial authenticator distribution, the identity of the individual, group, role, or device receiving the authenticator; b. Establishing initial authenticator content for authenticators defined by the organization; c. Ensuring that authenticators have sufficient strength of mechanism for their intended use; d. Establishing and implementing administrative procedures for initial authenticator distribution, for lost/compromised or damaged authenticators, and for revoking authenticators; e. Changing default content of authenticators prior to information system installation; f. Establishing minimum and maximum lifetime restrictions and reuse conditions for authenticators; g. Changing/refreshing authenticators [Assignment: organization-defined time period by authenticator type]; h. Protecting authenticator content from unauthorized disclosure and modification; i. Requiring individuals to take, and having devices implement, specific security safeguards to protect authenticators; and j. Changing authenticators for group/role accounts when membership to those accounts changes. Supplemental Guidance: Individual authenticators include, for example, passwords, tokens, biometrics, PKI certificates, and key cards. Initial authenticator content is the actual content (e.g., the initial password) as opposed to requirements about authenticator content (e.g., minimum password length). In many cases, developers ship information system components with factory default authentication credentials to allow for initial installation and configuration. Default authentication credentials are often well known, easily discoverable, and present a significant security risk. The requirement to protect individual authenticators may be implemented via control PL-4 or PS-6 for authenticators in the possession of individuals and by controls AC-3, AC-6, and SC-28 for authenticators stored within organizational information systems (e.g., passwords stored in hashed or encrypted formats, files containing encrypted or hashed passwords accessible with administrator privileges). Information systems support individual authenticator management by organization-defined settings and restrictions for various authenticator characteristics including, for example, minimum password length, password composition, validation time window for time synchronous one-time tokens, and number of allowed rejections during the verification stage of biometric authentication. Specific actions that can be taken to safeguard authenticators include, for example, maintaining possession of individual authenticators, not loaning or sharing individual authenticators with others, and reporting lost, stolen, or compromised authenticators immediately. Authenticator management includes issuing and revoking, when no longer needed, authenticators for temporary access such as that required for remote maintenance. Device authenticators include, for example, certificates and passwords. Related controls: AC-2, AC-3, AC-6, CM-6, IA-2, IA-4, IA-8, PL-4, PS-5, PS-6, SC-12, SC-13, SC-17, SC-28. ü ü IA-5g. [to include sixty days for passwords] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 IDENTIFICATION AND AUTHENTICATION IA-5 (1) AUTHENTICATOR MANAGEMENT | PASSWORD-BASED AUTHENTICATION ü The information system, for password-based authentication: (a) Enforces minimum password complexity of [Assignment: organization-defined requirements for case sensitivity, number of characters, mix of upper-case letters, lower-case letters, numbers, and special characters, including minimum requirements for each type]; (b) Enforces at least the following number of changed characters when new passwords are created: [Assignment: organization-defined number]; (c) Stores and transmits only encrypted representations of passwords; (d) Enforces password minimum and maximum lifetime restrictions of [Assignment: organization- defined numbers for lifetime minimum, lifetime maximum]; (e) Prohibits password reuse for [Assignment: organization-defined number] generations; and (f) Allows the use of a temporary password for system logons with an immediate change to a permanent password. Supplemental Guidance: This control enhancement applies to single-factor authentication of individuals using passwords as individual or group authenticators, and in a similar manner, when passwords are part of multifactor authenticators. This control enhancement does not apply when passwords are used to unlock hardware authenticators (e.g., Personal Identity Verification cards). The implementation of such password mechanisms may not meet all of the requirements in the enhancement. Encrypted representations of passwords include, for example, encrypted versions of passwords and one-way cryptographic hashes of passwords. The number of changed characters refers to the number of changes required with respect to the total number of positions in the current password. Password lifetime restrictions do not apply to temporary passwords. Related control: IA-6. ü ü "IA-5 (1) (a). [case sensitive, minimum of twelve characters, and at least one each of upper-case letters, lower-case letters, numbers, and special characters] IA-5 (1) (b). [at least one] IA-5 (1) (d). [one day minimum, sixty day maximum] IA-5 (1) (e). [twenty four]" ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 "IA-5 (1) (a). [case sensitive, minimum of fifteen characters, and at least one each of upper-case letters, lower-case letters, numbers, and special characters] IA-5 (1) (b). [at least 50%] IA-5 (1) (d). [one day minimum, sixty day maximum] IA-5 (1) (e). [twenty four]" IDENTIFICATION AND AUTHENTICATION IA-5 (2) AUTHENTICATOR MANAGEMENT | PKI-BASED AUTHENTICATION The information system, for PKI-based authentication: (a) Validates certifications by constructing and verifying a certification path to an accepted trust anchor including checking certificate status information; (b) Enforces authorized access to the corresponding private key; (c) Maps the authenticated identity to the account of the individual or group; and (d) Implements a local cache of revocation data to support path discovery and validation in case of inability to access revocation information via the network. Supplemental Guidance: Status information for certification paths includes, for example, certificate revocation lists or certificate status protocol responses. For PIV cards, validation of certifications involves the construction and verification of a certification path to the Common Policy Root trust anchor including certificate policy processing. Related control: IA-6. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 IDENTIFICATION AND AUTHENTICATION IA-5 (3) AUTHENTICATOR MANAGEMENT | IN-PERSON OR TRUSTED THIRD-PARTY REGISTRATION ü The organization requires that the registration process to receive [Assignment: organization- defined types of and/or specific authenticators] be conducted [Selection: in person; by a trusted third party] before [Assignment: organization-defined registration authority] with authorization by [Assignment: organization-defined personnel or roles]. ü IA-5 (3). [All hardware/biometric (multifactor authenticators] [in person] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 IDENTIFICATION AND AUTHENTICATION IA-5 (4) AUTHENTICATOR MANAGEMENT | AUTOMATED SUPPORT FOR PASSWORD STRENGTH DETERMINATION ü The organization employs automated tools to determine if password authenticators are sufficiently strong to satisfy [Assignment: organization-defined requirements]. Supplemental Guidance: This control enhancement focuses on the creation of strong passwords and the characteristics of such passwords (e.g., complexity) prior to use, the enforcement of which is carried out by organizational information systems in IA-5 (1). Related controls: CA- 2, CA-7, RA-5. ü IA-4e Additional FedRAMP Requirements and Guidance: Guidance: If automated mechanisms which enforce password authenticator strength at creation are not used, automated mechanisms must be used to audit strength of created password authenticators ü Included in FedRAMP Moderate Baseline, Rev 4 IDENTIFICATION AND AUTHENTICATION IA-5 (6) AUTHENTICATOR MANAGEMENT | PROTECTION OF AUTHENTICATORS The organization protects authenticators commensurate with the security category of the information to which use of the authenticator permits access. Supplemental Guidance: For information systems containing multiple security categories of information without reliable physical or logical separation between categories, authenticators used to grant access to the systems are protected commensurate with the highest security category of information on the systems. ü ü Included in FedRAMP Moderate Baseline, Rev 4 IDENTIFICATION AND AUTHENTICATION IA-5 (7) AUTHENTICATOR MANAGEMENT | NO EMBEDDED UNENCRYPTED STATIC AUTHENTICATORS The organization ensures that unencrypted static authenticators are not embedded in applications or access scripts or stored on function keys. Supplemental Guidance: Organizations exercise caution in determining whether embedded or stored authenticators are in encrypted or unencrypted form. If authenticators are used in the manner stored, then those representations are considered unencrypted authenticators. This is irrespective of whether that representation is perhaps an encrypted version of something else (e.g., a password). ü ü Included in FedRAMP Moderate Baseline, Rev 4 IDENTIFICATION AND AUTHENTICATION IA-5 (8) AUTHENTICATOR MANAGEMENT | MULTIPLE INFORMATION SYSTEM ACCOUNTS ü The organization implements [Assignment: organization-defined security safeguards] to manage the risk of compromise due to individuals having accounts on multiple information systems. Supplemental Guidance: When individuals have accounts on multiple information systems, there is the risk that the compromise of one account may lead to the compromise of other accounts if individuals use the same authenticators. Possible alternatives include, for example: (i) having different authenticators on all systems; (ii) employing some form of single sign-on mechanism; or (iii) including some form of one-time passwords on all systems. ü NEED. In those cases where an organization’s user accounts authenticate to more than one system, and at least one of those systems is a high-impact system implemented in a shared-service environment, then this control is warranted as a baseline capability to guard against loss of high-impact, sensitive information. ANALYSIS. Organizations can use COTS tools and techniques to implement this control in many ways. Agencies should be prepared to document their plan and approach to this control technique. THREAT VECTORS ADDRESSED. A user’s account password is cracked, permitting attackers to identify all systems to which the user has access, and to gain access to the information in those systems. RELEVANT SECURITY CONTROL ATTRIBUTES. Monitored, Assessed [different authenticators on all system] IDENTIFICATION AND AUTHENTICATION IA-5 (11) AUTHENTICATOR MANAGEMENT | HARDWARE TOKEN-BASED AUTHENTICATION ü The information system, for hardware token-based authentication, employs mechanisms that satisfy [Assignment: organization-defined token quality requirements]. Supplemental Guidance: Hardware token-based authentication typically refers to the use of PKI-based tokens, such as the U.S. Government Personal Identity Verification (PIV) card. Organizations define specific requirements for tokens, such as working with a particular PKI. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 IDENTIFICATION AND AUTHENTICATION IA-6 AUTHENTICATOR FEEDBACK The information system obscures feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals. Supplemental Guidance: The feedback from information systems does not provide information that would allow unauthorized individuals to compromise authentication mechanisms. For some types of information systems or system components, for example, desktops/notebooks with relatively large monitors, the threat (often referred to as shoulder surfing) may be significant. For other types of systems or components, for example, mobile devices with 2-4 inch screens, this threat may be less significant, and may need to be balanced against the increased likelihood of typographic input errors due to the small keyboards. Therefore, the means for obscuring the authenticator feedback is selected accordingly. Obscuring the feedback of authentication information includes, for example, displaying asterisks when users type passwords into input devices, or displaying feedback for a very limited time before fully obscuring it. Related control: PE-18. Control Enhancements: None. References: None. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 IDENTIFICATION AND AUTHENTICATION IA-7 CRYPTOGRAPHIC MODULE AUTHENTICATION The information system implements mechanisms for authentication to a cryptographic module that meet the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance for such authentication. Supplemental Guidance: Authentication mechanisms may be required within a cryptographic module to authenticate an operator accessing the module and to verify that the operator is authorized to assume the requested role and perform services within that role. Related controls: SC-12, SC-13. Control Enhancements: None. References: FIPS Publication 140; Web: csrc.nist.gov/groups/STM/cmvp/index.html. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 IDENTIFICATION AND AUTHENTICATION IA-8 IDENTIFICATION AND AUTHENTICATION (NON- ORGANIZATIONAL USERS) The information system uniquely identifies and authenticates non-organizational users (or processes acting on behalf of non-organizational users). Supplemental Guidance: Non-organizational users include information system users other than organizational users explicitly covered by IA-2. These individuals are uniquely identified and authenticated for accesses other than those accesses explicitly identified and documented in AC- 14. In accordance with the E-Authentication E-Government initiative, authentication of non- organizational users accessing federal information systems may be required to protect federal, proprietary, or privacy-related information (with exceptions noted for national security systems). Organizations use risk assessments to determine authentication needs and consider scalability, practicality, and security in balancing the need to ensure ease of use for access to federal information and information systems with the need to protect and adequately mitigate risk. IA-2 addresses identification and authentication requirements for access to information systems by organizational users. Related controls: AC-2, AC-14, AC-17, AC-18, IA-2, IA-4, IA-5, MA-4, RA-3, SA-12, SC-8. ü ü PMO guidance on (1,2,3,4) supported, but not requirement to implement (CIS/CTW) ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 IDENTIFICATION AND AUTHENTICATION IA-8 (1) IDENTIFICATION AND AUTHENTICATION | ACCEPTANCE OF PIV CREDENTIALS FROM OTHER AGENCIES The information system accepts and electronically verifies Personal Identity Verification (PIV) credentials from other federal agencies. Supplemental Guidance: This control enhancement applies to logical access control systems (LACS) and physical access control systems (PACS). Personal Identity Verification (PIV) credentials are those credentials issued by federal agencies that conform to FIPS Publication 201 and supporting guidance documents. OMB Memorandum 11-11 requires federal agencies to continue implementing the requirements specified in HSPD-12 to enable agency-wide use of PIV credentials. Related controls: AU-2, PE-3, SA-4. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 IDENTIFICATION AND AUTHENTICATION IA-8 (2) IDENTIFICATION AND AUTHENTICATION | ACCEPTANCE OF THIRD-PARTY CREDENTIALS The information system accepts only FICAM-approved third-party credentials. Supplemental Guidance: This control enhancement typically applies to organizational information systems that are accessible to the general public, for example, public-facing websites. Third-party credentials are those credentials issued by nonfederal government entities approved by the Federal Identity, Credential, and Access Management (FICAM) Trust Framework Solutions initiative. Approved third-party credentials meet or exceed the set of minimum federal government-wide technical, security, privacy, and organizational maturity requirements. This allows federal government relying parties to trust such credentials at their approved assurance levels. Related control: AU-2. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 IDENTIFICATION AND AUTHENTICATION IA-8 (3) IDENTIFICATION AND AUTHENTICATION | USE OF FICAM-APPROVED PRODUCTS ü The organization employs only FICAM-approved information system components in [Assignment: organization-defined information systems] to accept third-party credentials. Supplemental Guidance: This control enhancement typically applies to information systems that are accessible to the general public, for example, public-facing websites. FICAM-approved information system components include, for example, information technology products and software libraries that have been approved by the Federal Identity, Credential, and Access Management conformance program. Related control: SA-4. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 IDENTIFICATION AND AUTHENTICATION IA-8 (4) IDENTIFICATION AND AUTHENTICATION | USE OF FICAM-ISSUED PROFILES The information system conforms to FICAM-issued profiles. Supplemental Guidance: This control enhancement addresses open identity management standards. To ensure that these standards are viable, robust, reliable, sustainable (e.g., available in commercial information technology products), and interoperable as documented, the United States Government assesses and scopes identity management standards and technology implementations against applicable federal legislation, directives, policies, and requirements. The result is FICAM-issued implementation profiles of approved protocols (e.g., FICAM authentication protocols such as SAML 2.0 and OpenID 2.0, as well as other protocols such as the FICAM Backend Attribute Exchange). Related control: SA-4. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 INCIDENT RESPONSE IR-1 INCIDENT RESPONSE POLICY AND PROCEDURES ü The organization: a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]: 1. An incident response policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and 2. Procedures to facilitate the implementation of the incident response policy and associated incident response controls; and b. Reviews and updates the current: 1. Incident response policy [Assignment: organization-defined frequency]; and 2. Incident response procedures [Assignment: organization-defined frequency]. Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the IR family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9. Control Enhancements: None. References: NIST Special Publications 800-12, 800-61, 800-83, 800-100. ü ü "IR-1.b.1 [at least every 3 years] IR-1.b.2 [at least annually]" ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 IR-1.b.1 [at least annually] IR-1.b.2 [at least every six months] INCIDENT RESPONSE IR-2 INCIDENT RESPONSE TRAINING ü The organization provides incident response training to information system users consistent with assigned roles and responsibilities: a. Within [Assignment: organization-defined time period] of assuming an incident response role or responsibility; b. When required by information system changes; and c. [Assignment: organization-defined frequency] thereafter. Supplemental Guidance: Incident response training provided by organizations is linked to the assigned roles and responsibilities of organizational personnel to ensure the appropriate content and level of detail is included in such training. For example, regular users may only need to know who to call or how to recognize an incident on the information system; system administrators may require additional training on how to handle/remediate incidents; and incident responders may receive more specific training on forensics, reporting, system recovery, and restoration. Incident response training includes user training in the identification and reporting of suspicious activities, both from external and internal sources. Related controls: AT-3, CP-3, IR-8. ü ü IR-2b. [at least annually] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 IR-2a. [within 10 days] IR-2c. [at least annually] INCIDENT RESPONSE IR-2 (1) INCIDENT RESPONSE TRAINING | SIMULATED EVENTS The organization incorporates simulated events into incident response training to facilitate effective response by personnel in crisis situations. ü Included in NIST High Baseline, Rev 4 INCIDENT RESPONSE IR-2 (2) INCIDENT RESPONSE TRAINING | AUTOMATED TRAINING ENVIRONMENTS The organization employs automated mechanisms to provide a more thorough and realistic incident response training environment. References: NIST Special Publications 800-16, 800-50. ü Included in NIST High Baseline, Rev 4 INCIDENT RESPONSE IR-3 INCIDENT RESPONSE TESTING ü The organization tests the incident response capability for the information system [Assignment: organization-defined frequency] using [Assignment: organization-defined tests] to determine the incident response effectiveness and documents the results. Supplemental Guidance: Organizations test incident response capabilities to determine the overall effectiveness of the capabilities and to identify potential weaknesses or deficiencies. Incident response testing includes, for example, the use of checklists, walk-through or tabletop exercises, simulations (parallel/full interrupt), and comprehensive exercises. Incident response testing can also include a determination of the effects on organizational operations (e.g., reduction in mission capabilities), organizational assets, and individuals due to incident response. Related controls: CP- 4, IR-8. ü IR-3. [at least annually] IR-3. Requirement: The service provider defines tests and/or exercises in accordance with NIST Special Publication 800-61 (as amended). Requirement: For JAB Authorization, the service provider provides test plans to the Authorizing Official (AO) annually. Requirement: Test plans are approved and accepted by the Authorizing Official prior to test commencing. ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 INCIDENT RESPONSE IR-3 (2) INCIDENT RESPONSE TESTING | COORDINATION WITH RELATED PLANS The organization coordinates incident response testing with organizational elements responsible for related plans. Supplemental Guidance: Organizational plans related to incident response testing include, for example, Business Continuity Plans, Contingency Plans, Disaster Recovery Plans, Continuity of Operations Plans, Crisis Communications Plans, Critical Infrastructure Plans, and Occupant Emergency Plans. References: NIST Special Publications 800-84, 800-115. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 INCIDENT RESPONSE IR-4 INCIDENT HANDLING The organization: a. Implements an incident handling capability for security incidents that includes preparation, detection and analysis, containment, eradication, and recovery; b. Coordinates incident handling activities with contingency planning activities; and c. Incorporates lessons learned from ongoing incident handling activities into incident response procedures, training, and testing/exercises, and implements the resulting changes accordingly. Supplemental Guidance: Organizations recognize that incident response capability is dependent on the capabilities of organizational information systems and the mission/business processes being supported by those systems. Therefore, organizations consider incident response as part of the definition, design, and development of mission/business processes and information systems. Incident-related information can be obtained from a variety of sources including, for example, audit monitoring, network monitoring, physical access monitoring, user/administrator reports, and reported supply chain events. Effective incident handling capability includes coordination among many organizational entities including, for example, mission/business owners, information system owners, authorizing officials, human resources offices, physical and personnel security offices, legal departments, operations personnel, procurement offices, and the risk executive (function). Related controls: AU-6, CM-6, CP-2, CP-4, IR-2, IR-3, IR-8, PE-6, SC-5, SC-7, SI-3, SI-4, SI-7. ü ü IR-4/A13. Requirement: The service provider ensures that individuals conducting incident handling meet personnel security requirements commensurate with the criticality/sensitivity of the information being processed, stored, and transmitted by the information system. ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 INCIDENT RESPONSE IR-4 (1) INCIDENT HANDLING | AUTOMATED INCIDENT HANDLING PROCESSES The organization employs automated mechanisms to support the incident handling process. Supplemental Guidance: Automated mechanisms supporting incident handling processes include, for example, online incident management systems. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 INCIDENT RESPONSE IR-4 (2) INCIDENT HANDLING | DYNAMIC RECONFIGURATION ü The organization includes dynamic reconfiguration of [Assignment: organization-defined information system components] as part of the incident response capability. Supplemental Guidance: Dynamic reconfiguration includes, for example, changes to router rules, access control lists, intrusion detection/prevention system parameters, and filter rules for firewalls and gateways. Organizations perform dynamic reconfiguration of information systems, for example, to stop attacks, to misdirect attackers, and to isolate components of systems, thus limiting the extent of the damage from breaches or compromises. Organizations include time frames for achieving the reconfiguration of information systems in the definition of the reconfiguration capability, considering the potential need for rapid response in order to effectively address sophisticated cyber threats. Related controls: AC-2, AC-4, AC-16, CM-2, CM-3, CM-4. ü NEED. Organization requires near real-time subsystem reconfiguration for high-impact systems, especially those deployed wholly or partially into shared-service environments. This dynamic reconfiguration is required for core infrastructure components such as routers, firewalls, messaging gateways, or access control/authentication servers, especially when these core components are under cyber-attack. ANALYSIS. These critical cyber controls are well understood, and to some extent their automated capability has been established. Other aspects still require human decisions. The implementation time and cost depend on the degree of automation required by the organization. Since this technology area is rapidly changing to meet new cyber-threat scenarios, it is expected that implementation of this control will be subject to significant change for the foreseeable future. Even so, its technology advantages are clear, especially for high-impact systems infrastructure. SAMPLE THREAT VECTORS. System does not have error-correcting or self-recovery capabilities. The system is not designed to allow for quick remediation of threats that will impact the system. RELEVANT SECURITY CONTROL ATTRIBUTES. Survivability, Absorptive, Adaptive, Restorative [all network, data storage, and computing devices] INCIDENT RESPONSE IR-4 (3) INCIDENT HANDLING | CONTINUITY OF OPERATIONS ü The organization identifies [Assignment: organization-defined classes of incidents] and [Assignment: organization-defined actions to take in response to classes of incidents] to ensure continuation of organizational missions and business functions. Supplemental Guidance: Classes of incidents include, for example, malfunctions due to design/implementation errors and omissions, targeted malicious attacks, and untargeted malicious attacks. Appropriate incident response actions include, for example, graceful degradation, information system shutdown, fall back to manual mode/alternative technology whereby the system operates differently, employing deceptive measures, alternate information flows, or operating in a mode that is reserved solely for when systems are under attack. ü NEED. Due to the direct connection between system function and critical mission/business capability, the organization determines that the system requires Continuity-of-Operations (COOP) controls or basic Disaster-Recovery (DR) defensive controls. ANALYSIS. These critical cyber controls are well understood, and to some extent their automated capability has been established. Other aspects still require human decisions. The implementation time and cost depend on the degree of automation required by the organization. Since this technology area is rapidly changing to meet new cyber-threat scenarios and also changes in subsystem technology, it is expected that implementation of this control will be subject to significant change for the foreseeable future. Even so, its technology advantages are fundamental, especially for high-impact systems infrastructure. SAMPLE THREAT VECTORS. The system does not have error-correcting or self-recovery capabilities. The system is not designed to allow for quick remediation of threats that will impact the system. Time does not allow for the design in error handling, self-recovery, or to capitalize on system diversity to restore a system. Also, the organization lacks the expertise to develop or implement a plan for restoring system. A malicious change may be implemented to counter the ability to restore the system. RELEVANT SECURITY CONTROL ATTRIBUTES. Survivability, Absorptive, Adaptive, Restorative [organization and service provider-defined classes of incidents] [organization and service provider-defined actions to take in response to classes of incidents] INCIDENT RESPONSE IR-4 (4) INCIDENT HANDLING | INFORMATION CORRELATION The organization correlates incident information and individual incident responses to achieve an organization-wide perspective on incident awareness and response. Supplemental Guidance: Sometimes the nature of a threat event, for example, a hostile cyber attack, is such that it can only be observed by bringing together information from different sources including various reports and reporting procedures established by organizations. ü Included in NIST High Baseline, Rev 4 INCIDENT RESPONSE IR-4 (6) INCIDENT HANDLING | INSIDER THREATS - SPECIFIC CAPABILITIES The organization implements incident handling capability for insider threats. Supplemental Guidance: While many organizations address insider threat incidents as an inherent part of their organizational incident response capability, this control enhancement provides additional emphasis on this type of threat and the need for specific incident handling capabilities (as defined within organizations) to provide appropriate and timely responses. ü NEED. High-impact systems will require special measures to ensure security incidents are correctly and effectively handled in a timely manner. This high-level control supports that need, and is therefore warranted as a baseline for high-impact systems in shared-service environments. ANALYSIS. Implementation of this general control is well understood among Departments and Agencies. However, it may require special funding and time to implement in a shared service environment, where response roles and responsibilities demand vigilant analysis and definition. SAMPLE THREAT VECTORS. Insiders gain access to information for which they have no authorization. Insiders push sensitive information to outside networks not authorized to receive it. Insiders violate agency information-security policies. Insider actions are not monitored. RELEVANT SECURITY CONTROL ATTRIBUTES. Agile, Owned, Enforcement INCIDENT RESPONSE IR-5 INCIDENT MONITORING The organization tracks and documents information system security incidents. Supplemental Guidance: Documenting information system security incidents includes, for example, maintaining records about each incident, the status of the incident, and other pertinent information necessary for forensics, evaluating incident details, trends, and handling. Incident information can be obtained from a variety of sources including, for example, incident reports, incident response teams, audit monitoring, network monitoring, physical access monitoring, and user/administrator reports. Related controls: AU-6, IR-8, PE-6, SC-5, SC-7, SI-3, SI-4, SI-7. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 INCIDENT RESPONSE IR-5 (1) INCIDENT MONITORING | AUTOMATED TRACKING / DATA COLLECTION / ANALYSIS The organization employs automated mechanisms to assist in the tracking of security incidents and in the collection and analysis of incident information. Supplemental Guidance: Automated mechanisms for tracking security incidents and collecting/analyzing incident information include, for example, the Einstein network monitoring device and monitoring online Computer Incident Response Centers (CIRCs) or other electronic databases of incidents. Related controls: AU-7, IR-4. References: NIST Special Publication 800-61. ü Included in NIST High Baseline, Rev 4 INCIDENT RESPONSE IR-6 INCIDENT REPORTING ü The organization: a. Requires personnel to report suspected security incidents to the organizational incident response capability within [Assignment: organization-defined time period]; and b. Reports security incident information to [Assignment: organization-defined authorities]. Supplemental Guidance: The intent of this control is to address both specific incident reporting requirements within an organization and the formal incident reporting requirements for federal agencies and their subordinate organizations. Suspected security incidents include, for example, the receipt of suspicious email communications that can potentially contain malicious code. The types of security incidents reported, the content and timeliness of the reports, and the designated reporting authorities reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Current federal policy requires that all federal agencies (unless specifically exempted from such requirements) report security incidents to the United States Computer Emergency Readiness Team (US-CERT) within specified time frames designated in the US-CERT Concept of Operations for Federal Cyber Security Incident Handling. Related controls: IR-4, IR-5, IR-8. ü ü IR-6a. [US-CERT incident reporting timelines as specified in NIST Special Publication 800-61 (as amended)] Requirement: Reports security incident information according to FedRAMP Incident Communications Procedure. ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 INCIDENT RESPONSE IR-6 (1) INCIDENT REPORTING | AUTOMATED REPORTING The organization employs automated mechanisms to assist in the reporting of security incidents. Supplemental Guidance: Related control: IR-7. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 INCIDENT RESPONSE IR-7 INCIDENT RESPONSE ASSISTANCE The organization provides an incident response support resource, integral to the organizational incident response capability that offers advice and assistance to users of the information system for the handling and reporting of security incidents. Supplemental Guidance: Incident response support resources provided by organizations include, for example, help desks, assistance groups, and access to forensics services, when required. Related controls: AT-2, IR-4, IR-6, IR-8, SA-9. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 INCIDENT RESPONSE IR-7 (1) INCIDENT RESPONSE ASSISTANCE | AUTOMATION SUPPORT FOR AVAILABILITY OF INFORMATION / SUPPORT The organization employs automated mechanisms to increase the availability of incident response- related information and support. Supplemental Guidance: Automated mechanisms can provide a push and/or pull capability for users to obtain incident response assistance. For example, individuals might have access to a website to query the assistance capability, or conversely, the assistance capability may have the ability to proactively send information to users (general distribution or targeted) as part of increasing understanding of current response capabilities and support. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 INCIDENT RESPONSE IR-7 (2) INCIDENT RESPONSE ASSISTANCE | COORDINATION WITH EXTERNAL PROVIDERS The organization: (a) Establishes a direct, cooperative relationship between its incident response capability and external providers of information system protection capability; and (b) Identifies organizational incident response team members to the external providers. Supplemental Guidance: External providers of information system protection capability include, for example, the Computer Network Defense program within the U.S. Department of Defense. External providers help to protect, monitor, analyze, detect, and respond to unauthorized activity within organizational information systems and networks. ü ü Included in FedRAMP Moderate Baseline, Rev 4 INCIDENT RESPONSE IR-8 INCIDENT RESPONSE PLAN ü The organization: a. Develops an incident response plan that: 1. Provides the organization with a roadmap for implementing its incident response capability; 2. Describes the structure and organization of the incident response capability; 3. Provides a high-level approach for how the incident response capability fits into the overall organization; 4. Meets the unique requirements of the organization, which relate to mission, size, structure, and functions; 5. Defines reportable incidents; 6. Provides metrics for measuring the incident response capability within the organization; 7. Defines the resources and management support needed to effectively maintain and mature an incident response capability; and 8. Is reviewed and approved by [Assignment: organization-defined personnel or roles]; b. Distributes copies of the incident response plan to [Assignment: organization-defined incident response personnel (identified by name and/or by role) and organizational elements]; c. Reviews the incident response plan [Assignment: organization-defined frequency]; d. Updates the incident response plan to address system/organizational changes or problems encountered during plan implementation, execution, or testing; e. Communicates incident response plan changes to [Assignment: organization-defined incident response personnel (identified by name and/or by role) and organizational elements]; and f. Protects the incident response plan from unauthorized disclosure and modification. Supplemental Guidance: It is important that organizations develop and implement a coordinated approach to incident response. Organizational missions, business functions, strategies, goals, and objectives for incident response help to determine the structure of incident response capabilities. As part of a comprehensive incident response capability, organizations consider the coordination and sharing of information with external organizations, including, for example, external service providers and organizations involved in the supply chain for organizational information systems. Related controls: MP-2, MP-4, MP-5. Control Enhancements: None. References: NIST Special Publication 800-61. ü ü IR-8c. [at least annually] IR-8(b) Additional FedRAMP Requirements and Guidance: The service provider defines a list of incident response personnel (identified by name and/or by role) and organizational elements. The incident response list includes designated FedRAMP personnel. IR-8(e) Additional FedRAMP Requirements and Guidance: The service provider defines a list of incident response personnel (identified by name and/or by role) and organizational elements. The incident response list includes designated FedRAMP personnel. ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 INCIDENT RESPONSE IR-9 INFORMATION SPILLAGE RESPONSE ü The organization: a. Develops an incident response plan that: 1. Provides the organization with a roadmap for implementing its incident response capability; 2. Describes the structure and organization of the incident response capability; 3. Provides a high-level approach for how the incident response capability fits into the overall organization; 4. Meets the unique requirements of the organization, which relate to mission, size, structure, and functions; 5. Defines reportable incidents; 6. Provides metrics for measuring the incident response capability within the organization; 7. Defines the resources and management support needed to effectively maintain and mature an incident response capability; and 8. Is reviewed and approved by [Assignment: organization-defined personnel or roles]; b. Distributes copies of the incident response plan to [Assignment: organization-defined incident response personnel (identified by name and/or by role) and organizational elements]; c. Reviews the incident response plan [Assignment: organization-defined frequency]; d. Updates the incident response plan to address system/organizational changes or problems encountered during plan implementation, execution, or testing; e. Communicates incident response plan changes to [Assignment: organization-defined incident response personnel (identified by name and/or by role) and organizational elements]; and f. Protects the incident response plan from unauthorized disclosure and modification. Supplemental Guidance: It is important that organizations develop and implement a coordinated approach to incident response. Organizational missions, business functions, strategies, goals, and objectives for incident response help to determine the structure of incident response capabilities. As part of a comprehensive incident response capability, organizations consider the coordination and sharing of information with external organizations, including, for example, external service providers and organizations involved in the supply chain for organizational information systems. Related controls: MP-2, MP-4, MP-5. Control Enhancements: None. References: NIST Special Publication 800-61. ü ü Included in FedRAMP Moderate Baseline, Rev 4 INCIDENT RESPONSE IR-9 (1) INFORMATION SPILLAGE RESPONSE | RESPONSIBLE PERSONNEL ü The organization assigns [Assignment: organization-defined personnel or roles] with responsibility for responding to information spills. ü ü Included in FedRAMP Moderate Baseline, Rev 4 INCIDENT RESPONSE IR-9 (2) INFORMATION SPILLAGE RESPONSE | TRAINING ü The organization provides information spillage response training [Assignment: organization- defined frequency]. ü ü Included in FedRAMP Moderate Baseline, Rev 4 [at least annually] INCIDENT RESPONSE IR-9 (3) INFORMATION SPILLAGE RESPONSE | POST-SPILL OPERATIONS ü The organization implements [Assignment: organization-defined procedures] to ensure that organizational personnel impacted by information spills can continue to carry out assigned tasks while contaminated systems are undergoing corrective actions. Supplemental Guidance: Correction actions for information systems contaminated due to information spillages may be very time-consuming. During those periods, personnel may not have access to the contaminated systems, which may potentially affect their ability to conduct organizational business. ü ü Included in FedRAMP Moderate Baseline, Rev 4 INCIDENT RESPONSE IR-9 (4) INFORMATION SPILLAGE RESPONSE | EXPOSURE TO UNAUTHORIZED PERSONNEL ü The organization employs [Assignment: organization-defined security safeguards] for personnel exposed to information not within assigned access authorizations. Supplemental Guidance: Security safeguards include, for example, making personnel exposed to spilled information aware of the federal laws, directives, policies, and/or regulations regarding the information and the restrictions imposed based on exposure to such information. ü ü Included in FedRAMP Moderate Baseline, Rev 4 MAINTENANCE MA-1 SYSTEM MAINTENANCE POLICY AND PROCEDURES ü The organization: a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]: 1. A system maintenance policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and 2. Procedures to facilitate the implementation of the system maintenance policy and associated system maintenance controls; and b. Reviews and updates the current: 1. System maintenance policy [Assignment: organization-defined frequency]; and 2. System maintenance procedures [Assignment: organization-defined frequency]. Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the MA family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9. Control Enhancements: None. References: NIST Special Publications 800-12, 800-100. ü ü MA-1.b.1 [at least every 3 years] MA-1.b.2 [at least annually] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 MA-1.b.1 [at least annually] MA-1.b.2 [at least every six months] MAINTENANCE MA-2 CONTROLLED MAINTENANCE ü The organization: a. Schedules, performs, documents, and reviews records of maintenance and repairs on information system components in accordance with manufacturer or vendor specifications and/or organizational requirements; b. Approves and monitors all maintenance activities, whether performed on site or remotely and whether the equipment is serviced on site or removed to another location; c. Requires that [Assignment: organization-defined personnel or roles] explicitly approve the removal of the information system or system components from organizational facilities for off-site maintenance or repairs; d. Sanitizes equipment to remove all information from associated media prior to removal from organizational facilities for off-site maintenance or repairs; e. Checks all potentially impacted security controls to verify that the controls are still functioning properly following maintenance or repair actions; and f. Includes [Assignment: organization-defined maintenance-related information] in organizational maintenance records. Supplemental Guidance: This control addresses the information security aspects of the information system maintenance program and applies to all types of maintenance to any system component (including applications) conducted by any local or nonlocal entity (e.g., in-contract, warranty, in- house, software maintenance agreement). System maintenance also includes those components not directly associated with information processing and/or data/information retention such as scanners, copiers, and printers. Information necessary for creating effective maintenance records includes, for example: (i) date and time of maintenance; (ii) name of individuals or group performing the maintenance; (iii) name of escort, if necessary; (iv) a description of the maintenance performed; and (v) information system components/equipment removed or replaced (including identification numbers, if applicable). The level of detail included in maintenance records can be informed by the security categories of organizational information systems. Organizations consider supply chain issues associated with replacement components for information systems. Related controls: CM-3, CM-4, MA-4, MP-6, PE-16, SA-12, SI-2. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 MAINTENANCE MA-2 (2) CONTROLLED MAINTENANCE | AUTOMATED MAINTENANCE ACTIVITIES The organization: (a) Employs automated mechanisms to schedule, conduct, and document maintenance and repairs; and (b) Produces up-to date, accurate, and complete records of all maintenance and repair actions requested, scheduled, in process, and completed. Supplemental Guidance: Related controls: CA-7, MA-3. References: None. ü Included in NIST High Baseline, Rev 4 MAINTENANCE MA-3 MAINTENANCE TOOLS The organization approves, controls, and monitors information system maintenance tools. Supplemental Guidance: This control addresses security-related issues associated with maintenance tools used specifically for diagnostic and repair actions on organizational information systems. Maintenance tools can include hardware, software, and firmware items. Maintenance tools are potential vehicles for transporting malicious code, either intentionally or unintentionally, into a facility and subsequently into organizational information systems. Maintenance tools can include, for example, hardware/software diagnostic test equipment and hardware/software packet sniffers. This control does not cover hardware/software components that may support information system maintenance, yet are a part of the system, for example, the software implementing “ping,†“ls,†“ipconfig,†or the hardware and software implementing the monitoring port of an Ethernet switch. Related controls: MA-2, MA-5, MP-6. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 MAINTENANCE MA-3 (1) MAINTENANCE TOOLS | INSPECT TOOLS The organization inspects the maintenance tools carried into a facility by maintenance personnel for improper or unauthorized modifications. Supplemental Guidance: If, upon inspection of maintenance tools, organizations determine that the tools have been modified in an improper/unauthorized manner or contain malicious code, the incident is handled consistent with organizational policies and procedures for incident handling. Related control: SI-7. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 MAINTENANCE MA-3 (2) MAINTENANCE TOOLS | INSPECT MEDIA The organization checks media containing diagnostic and test programs for malicious code before the media are used in the information system. Supplemental Guidance: If, upon inspection of media containing maintenance diagnostic and test programs, organizations determine that the media contain malicious code, the incident is handled consistent with organizational incident handling policies and procedures. Related control: SI-3. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 MAINTENANCE MA-3 (3) MAINTENANCE TOOLS | PREVENT UNAUTHORIZED REMOVAL ü The organization prevents the unauthorized removal of maintenance equipment containing organizational information by: (a) Verifying that there is no organizational information contained on the equipment; (b) Sanitizing or destroying the equipment; (c) Retaining the equipment within the facility; or (d) Obtaining an exemption from [Assignment: organization-defined personnel or roles] explicitly authorizing removal of the equipment from the facility. Supplemental Guidance: Organizational information includes all information specifically owned by organizations and information provided to organizations in which organizations serve as information stewards. ü MA-3 (3) (d). [the information owner explicitly authorizing removal of the equipment from the facility] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 MAINTENANCE MA-4 NONLOCAL MAINTENANCE The organization: a. Approves and monitors nonlocal maintenance and diagnostic activities; b. Allows the use of nonlocal maintenance and diagnostic tools only as consistent with organizational policy and documented in the security plan for the information system; c. Employs strong authenticators in the establishment of nonlocal maintenance and diagnostic sessions; d. Maintains records for nonlocal maintenance and diagnostic activities; and e. Terminates session and network connections when nonlocal maintenance is completed. Supplemental Guidance: Nonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection. Authentication techniques used in the establishment of nonlocal maintenance and diagnostic sessions reflect the network access requirements in IA-2. Typically, strong authentication requires authenticators that are resistant to replay attacks and employ multifactor authentication. Strong authenticators include, for example, PKI where certificates are stored on a token protected by a password, passphrase, or biometric. Enforcing requirements in MA-4 is accomplished in part by other controls. Related controls: AC- 2, AC-3, AC-6, AC-17, AU-2, AU-3, IA-2, IA-4, IA-5, IA-8, MA-2, MA-5, MP-6, PL-2, SC-7, SC-10, SC-17. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 MAINTENANCE MA-4 (2) NONLOCAL MAINTENANCE | DOCUMENT NONLOCAL MAINTENANCE The organization documents in the security plan for the information system, the policies and procedures for the establishment and use of nonlocal maintenance and diagnostic connections. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 MAINTENANCE MA-4 (3) NONLOCAL MAINTENANCE | COMPARABLE SECURITY / SANITIZATION The organization: (a) Requires that nonlocal maintenance and diagnostic services be performed from an information system that implements a security capability comparable to the capability implemented on the system being serviced; or (b) Removes the component to be serviced from the information system and prior to nonlocal maintenance or diagnostic services, sanitizes the component (with regard to organizational information) before removal from organizational facilities, and after the service is performed, inspects and sanitizes the component (with regard to potentially malicious software) before reconnecting the component to the information system. Supplemental Guidance: Comparable security capability on information systems, diagnostic tools, and equipment providing maintenance services implies that the implemented security controls on those systems, tools, and equipment are at least as comprehensive as the controls on the information system being serviced. Related controls: MA-3, SA-12, SI-3, SI-7. ü Included in NIST High Baseline, Rev 4 MAINTENANCE MA-5 MAINTENANCE PERSONNEL The organization: a. Establishes a process for maintenance personnel authorization and maintains a list of authorized maintenance organizations or personnel; b. Ensures that non-escorted personnel performing maintenance on the information system have required access authorizations; and c. Designates organizational personnel with required access authorizations and technical competence to supervise the maintenance activities of personnel who do not possess the required access authorizations. Supplemental Guidance: This control applies to individuals performing hardware or software maintenance on organizational information systems, while PE-2 addresses physical access for individuals whose maintenance duties place them within the physical protection perimeter of the systems (e.g., custodial staff, physical plant maintenance personnel). Technical competence of supervising individuals relates to the maintenance performed on the information systems while having required access authorizations refers to maintenance on and near the systems. Individuals not previously identified as authorized maintenance personnel, such as information technology manufacturers, vendors, systems integrators, and consultants, may require privileged access to organizational information systems, for example, when required to conduct maintenance activities with little or no notice. Based on organizational assessments of risk, organizations may issue temporary credentials to these individuals. Temporary credentials may be for one-time use or for very limited time periods. Related controls: AC-2, IA-8, MP-2, PE-2, PE-3, PE-4, RA-3. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 MAINTENANCE MA-5 (1) MAINTENANCE PERSONNEL | INDIVIDUALS WITHOUT APPROPRIATE ACCESS The organization: (a) Implements procedures for the use of maintenance personnel that lack appropriate security clearances or are not U.S. citizens, that include the following requirements: (1) Maintenance personnel who do not have needed access authorizations, clearances, or formal access approvals are escorted and supervised during the performance of maintenance and diagnostic activities on the information system by approved organizational personnel who are fully cleared, have appropriate access authorizations, and are technically qualified; (2) Prior to initiating maintenance or diagnostic activities by personnel who do not have needed access authorizations, clearances or formal access approvals, all volatile information storage components within the information system are sanitized and all nonvolatile storage media are removed or physically disconnected from the system and secured; and (b) Develops and implements alternate security safeguards in the event an information system component cannot be sanitized, removed, or disconnected from the system. Supplemental Guidance: This control enhancement denies individuals who lack appropriate security clearances (i.e., individuals who do not possess security clearances or possess security clearances at a lower level than required) or who are not U.S. citizens, visual and electronic access to any classified information, Controlled Unclassified Information (CUI), or any other sensitive information contained on organizational information systems. Procedures for the use of maintenance personnel can be documented in security plans for the information systems. Related controls: MP-6, PL-2. ü Requirement: Only MA-5 (1)(a)(1) is required by FedRAMP Moderate Baseline ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 MAINTENANCE MA-6 TIMELY MAINTENANCE ü The organization obtains maintenance support and/or spare parts for [Assignment: organization-defined information system components] within [Assignment: organization-defined time period] of failure. Supplemental Guidance: Organizations specify the information system components that result in increased risk to organizational operations and assets, individuals, other organizations, or the Nation when the functionality provided by those components is not operational. Organizational actions to obtain maintenance support typically include having appropriate contracts in place. Related controls: CM-8, CP-2, CP-7, SA-14, SA-15. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 MEDIA PROTECTION MP-1 MEDIA PROTECTION POLICY AND PROCEDURES ü The organization: a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]: 1. A media protection policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and 2. Procedures to facilitate the implementation of the media protection policy and associated media protection controls; and b. Reviews and updates the current: 1. Media protection policy [Assignment: organization-defined frequency]; and 2. Media protection procedures [Assignment: organization-defined frequency]. Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the MP family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9. Control Enhancements: None. References: NIST Special Publications 800-12, 800-100. ü ü "MP-1.b.1 [at least every 3 years] MP-1.b.2 [at least annually]" ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 MP-1.b.1 [at least annually] MP-1.b.2 [at least annually] MEDIA PROTECTION MP-2 MEDIA ACCESS ü The organization restricts access to [Assignment: organization-defined types of digital and/or non-digital media] to [Assignment: organization-defined personnel or roles]. Supplemental Guidance: Information system media includes both digital and non-digital media. Digital media includes, for example, diskettes, magnetic tapes, external/removable hard disk drives, flash drives, compact disks, and digital video disks. Non-digital media includes, for example, paper and microfilm. Restricting non-digital media access includes, for example, denying access to patient medical records in a community hospital unless the individuals seeking access to such records are authorized healthcare providers. Restricting access to digital media includes, for example, limiting access to design specifications stored on compact disks in the media library to the project leader and the individuals on the development team. Related controls: AC-3, IA-2, MP-4, PE-2, PE-3, PL-2. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 MEDIA PROTECTION MP-3 MEDIA MARKING ü The organization: a. Marks information system media indicating the distribution limitations, handling caveats, and applicable security markings (if any) of the information; and b. Exempts [Assignment: organization-defined types of information system media] from marking as long as the media remain within [Assignment: organization-defined controlled areas]. Supplemental Guidance: The term security marking refers to the application/use of human-readable security attributes. The term security labeling refers to the application/use of security attributes with regard to internal data structures within information systems (see AC-16). Information system media includes both digital and non-digital media. Digital media includes, for example, diskettes, magnetic tapes, external/removable hard disk drives, flash drives, compact disks, and digital video disks. Non-digital media includes, for example, paper and microfilm. Security marking is generally not required for media containing information determined by organizations to be in the public domain or to be publicly releasable. However, some organizations may require markings for public information indicating that the information is publicly releasable. Marking of information system media reflects applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. Related controls: AC-16, PL-2, RA-3. Control Enhancements: None. References: FIPS Publication 199. ü MP-3b. [no removable media types] MP-3b. Guidance: Second parameter not-applicable ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 MEDIA PROTECTION MP-4 MEDIA STORAGE ü The organization: a. Physically controls and securely stores [Assignment: organization-defined types of digital and/or non-digital media] within [Assignment: organization-defined controlled areas]; and b. Protects information system media until the media are destroyed or sanitized using approved equipment, techniques, and procedures. Supplemental Guidance: Information system media includes both digital and non-digital media. Digital media includes, for example, diskettes, magnetic tapes, external/removable hard disk drives, flash drives, compact disks, and digital video disks. Non-digital media includes, for example, paper and microfilm. Physically controlling information system media includes, for example, conducting inventories, ensuring procedures are in place to allow individuals to check out and return media to the media library, and maintaining accountability for all stored media. Secure storage includes, for example, a locked drawer, desk, or cabinet, or a controlled media library. The type of media storage is commensurate with the security category and/or classification of the information residing on the media. Controlled areas are areas for which organizations provide sufficient physical and procedural safeguards to meet the requirements established for protecting information and/or information systems. For media containing information determined by organizations to be in the public domain, to be publicly releasable, or to have limited or no adverse impact on organizations or individuals if accessed by other than authorized personnel, fewer safeguards may be needed. In these situations, physical access controls provide adequate protection. Related controls: CP-6, CP-9, MP-2, MP-7, PE-3. ü MP-4a. [all types of digital and non-digital media with sensitive information] within [FedRAMP Assignment: see additional FedRAMP requirements and guidance] MP-4a Additional FedRAMP Requirements and Guidance: Requirement: The service provider defines controlled areas within facilities where the information and information system reside. ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 MEDIA PROTECTION MP-5 MEDIA TRANSPORT The organization: a. Protects and controls [Assignment: organization-defined types of information system media] during transport outside of controlled areas using [Assignment: organization-defined security safeguards]; b. Maintains accountability for information system media during transport outside of controlled areas; c. Documents activities associated with the transport of information system media; and d. Restricts the activities associated with the transport of information system media to authorized personnel. Supplemental Guidance: Information system media includes both digital and non-digital media. Digital media includes, for example, diskettes, magnetic tapes, external/removable hard disk drives, flash drives, compact disks, and digital video disks. Non-digital media includes, for example, paper and microfilm. This control also applies to mobile devices with information storage capability (e.g., smart phones, tablets, E-readers), that are transported outside of controlled areas. Controlled areas are areas or spaces for which organizations provide sufficient physical and/or procedural safeguards to meet the requirements established for protecting information and/or information systems. Physical and technical safeguards for media are commensurate with the security category or classification of the information residing on the media. Safeguards to protect media during transport include, for example, locked containers and cryptography. Cryptographic mechanisms can provide confidentiality and integrity protections depending upon the mechanisms used. Activities associated with transport include the actual transport as well as those activities such as releasing media for transport and ensuring that media enters the appropriate transport processes. For the actual transport, authorized transport and courier personnel may include individuals from outside the organization (e.g., U.S. Postal Service or a commercial transport or delivery service). Maintaining accountability of media during transport includes, for example, restricting transport activities to authorized personnel, and tracking and/or obtaining explicit records of transport activities as the media moves through the transportation system to prevent and detect loss, destruction, or tampering. Organizations establish documentation requirements for activities associated with the transport of information system media in accordance with organizational assessments of risk to include the flexibility to define different record-keeping methods for the different types of media transport as part of an overall system of transport-related records. Related controls: AC-19, CP-9, MP-3, MP-4, RA-3, SC-8, SC-13, SC-28. ü MP-5a. [all media with sensitive information] [prior to leaving secure/controlled environment: for digital media, encryption using a FIPS 140-2 validated encryption module; for non-digital media, secured in locked container] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 MEDIA PROTECTION MP-5 (4) MEDIA TRANSPORT | CRYPTOGRAPHIC PROTECTION The information system implements cryptographic mechanisms to protect the confidentiality and integrity of information stored on digital media during transport outside of controlled areas. Supplemental Guidance: This control enhancement applies to both portable storage devices (e.g., USB memory sticks, compact disks, digital video disks, external/removable hard disk drives) and mobile devices with storage capability (e.g., smart phones, tablets, E-readers). Related control: MP-2. References: FIPS Publication 199; NIST Special Publication 800-60. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 MEDIA PROTECTION MP-6 MEDIA SANITIZATION ü The organization: a. Sanitizes [Assignment: organization-defined information system media] prior to disposal, release out of organizational control, or release for reuse using [Assignment: organization- defined sanitization techniques and procedures] in accordance with applicable federal and organizational standards and policies; and b. Employs sanitization mechanisms with the strength and integrity commensurate with the security category or classification of the information. Supplemental Guidance: This control applies to all information system media, both digital and non- digital, subject to disposal or reuse, whether or not the media is considered removable. Examples include media found in scanners, copiers, printers, notebook computers, workstations, network components, and mobile devices. The sanitization process removes information from the media such that the information cannot be retrieved or reconstructed. Sanitization techniques, including clearing, purging, cryptographic erase, and destruction, prevent the disclosure of information to unauthorized individuals when such media is reused or released for disposal. Organizations determine the appropriate sanitization methods recognizing that destruction is sometimes necessary when other methods cannot be applied to media requiring sanitization. Organizations use discretion on the employment of approved sanitization techniques and procedures for media containing information deemed to be in the public domain or publicly releasable, or deemed to have no adverse impact on organizations or individuals if released for reuse or disposal. Sanitization of non-digital media includes, for example, removing a classified appendix from an otherwise unclassified document, or redacting selected sections or words from a document by obscuring the redacted sections/words in a manner equivalent in effectiveness to removing them from the document. NSA standards and policies control the sanitization process for media containing classified information. Related controls: MA-2, MA-4, RA-3, SC-4. ü ü MP-6a.1 [Assignment: organization-defined information system media] MP-6a.2 [Assignment: organization-defined sanitization techniques and procedures] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 MEDIA PROTECTION MP-6 (1) MEDIA SANITIZATION | REVIEW / APPROVE / TRACK / DOCUMENT / VERIFY The organization reviews, approves, tracks, documents, and verifies media sanitization and disposal actions. Supplemental Guidance: Organizations review and approve media to be sanitized to ensure compliance with records-retention policies. Tracking/documenting actions include, for example, listing personnel who reviewed and approved sanitization and disposal actions, types of media sanitized, specific files stored on the media, sanitization methods used, date and time of the sanitization actions, personnel who performed the sanitization, verification actions taken, personnel who performed the verification, and disposal action taken. Organizations verify that the sanitization of the media was effective prior to disposal. Related control: SI-12. ü Included in NIST High Baseline, Rev 4 MEDIA PROTECTION MP-6 (2) MEDIA SANITIZATION | EQUIPMENT TESTING ü The organization tests sanitization equipment and procedures [Assignment: organization-defined frequency] to verify that the intended sanitization is being achieved. Supplemental Guidance: Testing of sanitization equipment and procedures may be conducted by qualified and authorized external entities (e.g., other federal agencies or external service providers). ü [At least annually] Guidance: Equipment and procedures may be tested or validated for effectiveness ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 MEDIA PROTECTION MP-6 (3) MEDIA SANITIZATION | NONDESTRUCTIVE TECHNIQUES ü The organization applies non-destructive sanitization techniques to portable storage devices prior to connecting such devices to the information system under the following circumstances: [Assignment: organization-defined circumstances requiring sanitization of portable storage devices]. Supplemental Guidance: This control enhancement applies to digital media containing classified information and Controlled Unclassified Information (CUI). Portable storage devices can be the source of malicious code insertions into organizational information systems. Many of these devices are obtained from unknown and potentially untrustworthy sources and may contain malicious code that can be readily transferred to information systems through USB ports or other entry portals. While scanning such storage devices is always recommended, sanitization provides additional assurance that the devices are free of malicious code to include code capable of initiating zero-day attacks. Organizations consider nondestructive sanitization of portable storage devices when such devices are first purchased from the manufacturer or vendor prior to initial use or when organizations lose a positive chain of custody for the devices. Related control: SI-3. ü Included in NIST High Baseline, Rev 4 MEDIA PROTECTION MP-7 MEDIA USE ü The organization [Selection: restricts; prohibits] the use of [Assignment: organization- defined types of information system media] on [Assignment: organization-defined information systems or system components] using [Assignment: organization-defined security safeguards]. Supplemental Guidance: Information system media includes both digital and non-digital media. Digital media includes, for example, diskettes, magnetic tapes, external/removable hard disk drives, flash drives, compact disks, and digital video disks. Non-digital media includes, for example, paper and microfilm. This control also applies to mobile devices with information storage capability (e.g., smart phones, tablets, E-readers). In contrast to MP-2, which restricts user access to media, this control restricts the use of certain types of media on information systems, for example, restricting/prohibiting the use of flash drives or external hard disk drives. Organizations can employ technical and nontechnical safeguards (e.g., policies, procedures, rules of behavior) to restrict the use of information system media. Organizations may restrict the use of portable storage devices, for example, by using physical cages on workstations to prohibit access to certain external ports, or disabling/removing the ability to insert, read or write to such devices. Organizations may also limit the use of portable storage devices to only approved devices including, for example, devices provided by the organization, devices provided by other approved organizations, and devices that are not personally owned. Finally, organizations may restrict the use of portable storage devices based on the type of device, for example, prohibiting the use of writeable, portable storage devices, and implementing this restriction by disabling or removing the capability to write to such devices. Related controls: AC-19, PL-4. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 MEDIA PROTECTION MP-7 (1) MEDIA USE | PROHIBIT USE WITHOUT OWNER The organization prohibits the use of portable storage devices in organizational information systems when such devices have no identifiable owner. Supplemental Guidance: Requiring identifiable owners (e.g., individuals, organizations, or projects) for portable storage devices reduces the risk of using such technologies by allowing organizations to assign responsibility and accountability for addressing known vulnerabilities in the devices (e.g., malicious code insertion). Related control: PL-4. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 PHYSICAL AND ENVIRONMENTAL PROTECTION PE-1 PHYSICAL AND ENVIRONMENTAL PROTECTION POLICY AND PROCEDURES ü The organization: a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]: 1. A physical and environmental protection policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and 2. Procedures to facilitate the implementation of the physical and environmental protection policy and associated physical and environmental protection controls; and b. Reviews and updates the current: 1. Physical and environmental protection policy [Assignment: organization-defined frequency]; and 2. Physical and environmental protection procedures [Assignment: organization-defined frequency]. Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the PE family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9. Control Enhancements: None. References: NIST Special Publications 800-12, 800-100. ü ü PE-1.b.1 [at least every 3 years] PE-1.b.2 [at least annually] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 PE-1.b.1 [at least annually] PE-1.b.2 [at least every six months] PHYSICAL AND ENVIRONMENTAL PROTECTION PE-2 PHYSICAL ACCESS AUTHORIZATIONS ü The organization: a. Develops, approves, and maintains a list of individuals with authorized access to the facility where the information system resides; b. Issues authorization credentials for facility access; c. Reviews the access list detailing authorized facility access by individuals [Assignment: organization-defined frequency]; and d. Removes individuals from the facility access list when access is no longer required. Supplemental Guidance: This control applies to organizational employees and visitors. Individuals (e.g., employees, contractors, and others) with permanent physical access authorization credentials are not considered visitors. Authorization credentials include, for example, badges, identification cards, and smart cards. Organizations determine the strength of authorization credentials needed (including level of forge-proof badges, smart cards, or identification cards) consistent with federal standards, policies, and procedures. This control only applies to areas within facilities that have not been designated as publicly accessible. Related controls: PE-3, PE-4, PS-3. ü ü PE-2c. [at least annually] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 c. [at least every 90 days] PHYSICAL AND ENVIRONMENTAL PROTECTION PE-3 PHYSICAL ACCESS CONTROL ü The organization: a. Enforces physical access authorizations at [Assignment: organization-defined entry/exit points to the facility where the information system resides] by; 1. Verifying individual access authorizations before granting access to the facility; and 2. Controlling ingress/egress to the facility using [Selection (one or more): [Assignment: organization-defined physical access control systems/devices]; guards]; b. Maintains physical access audit logs for [Assignment: organization-defined entry/exit points]; c. Provides [Assignment: organization-defined security safeguards] to control access to areas within the facility officially designated as publicly accessible; d. Escorts visitors and monitors visitor activity [Assignment: organization-defined circumstances requiring visitor escorts and monitoring]; e. Secures keys, combinations, and other physical access devices; f. Inventories [Assignment: organization-defined physical access devices] every [Assignment: organization-defined frequency]; and g. Changes combinations and keys [Assignment: organization-defined frequency] and/or when keys are lost, combinations are compromised, or individuals are transferred or terminated. Supplemental Guidance: This control applies to organizational employees and visitors. Individuals (e.g., employees, contractors, and others) with permanent physical access authorization credentials are not considered visitors. Organizations determine the types of facility guards needed including, for example, professional physical security staff or other personnel such as administrative staff or information system users. Physical access devices include, for example, keys, locks, combinations, and card readers. Safeguards for publicly accessible areas within organizational facilities include, for example, cameras, monitoring by guards, and isolating selected information systems and/or system components in secured areas. Physical access control systems comply with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. The Federal Identity, Credential, and Access Management Program provides implementation guidance for identity, credential, and access management capabilities for physical access control systems. Organizations have flexibility in the types of audit logs employed. Audit logs can be procedural (e.g., a written log of individuals accessing the facility and when such access occurred), automated (e.g., capturing ID provided by a PIV card), or some combination thereof. Physical access points can include facility access points, interior access points to information systems and/or components requiring supplemental access controls, or both. Components of organizational information systems (e.g., workstations, terminals) may be located in areas designated as publicly accessible with organizations safeguarding access to such devices. Related controls: AU-2, AU-6, MP-2, MP-4, PE-2, PE-4, PE-5, PS-3, RA-3. ü ü PE-3a.2 [CSP defined physical access control systems/devices AND guards] PE-3d. [in all circumstances within restricted access area where the information system resides] PE-3f. [at least annually] PE-3g. [at least annually] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 PHYSICAL AND ENVIRONMENTAL PROTECTION PE-3 (1) PHYSICAL ACCESS CONTROL | INFORMATION SYSTEM ACCESS ü The organization enforces physical access authorizations to the information system in addition to the physical access controls for the facility at [Assignment: organization-defined physical spaces containing one or more components of the information system]. Supplemental Guidance: This control enhancement provides additional physical security for those areas within facilities where there is a concentration of information system components (e.g., server rooms, media storage areas, data and communications centers). Related control: PS-2. ü Included in NIST High Baseline, Rev 4 [service provider physical spaces containing components that contain organization data] PHYSICAL AND ENVIRONMENTAL PROTECTION PE-4 ACCESS CONTROL FOR TRANSMISSION MEDIUM ü The organization controls physical access to [Assignment: organization-defined information system distribution and transmission lines] within organizational facilities using [Assignment: organization-defined security safeguards]. Supplemental Guidance: Physical security safeguards applied to information system distribution and transmission lines help to prevent accidental damage, disruption, and physical tampering. In addition, physical safeguards may be necessary to help prevent eavesdropping or in transit modification of unencrypted transmissions. Security safeguards to control physical access to system distribution and transmission lines include, for example: (i) locked wiring closets; (ii) disconnected or locked spare jacks; and/or (iii) protection of cabling by conduit or cable trays. Related controls: MP-2, MP-4, PE-2, PE-3, PE-5, SC-7, SC-8. Control Enhancements: None. References: NSTISSI No. 7003. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 PHYSICAL AND ENVIRONMENTAL PROTECTION PE-5 ACCESS CONTROL FOR OUTPUT DEVICES The organization controls physical access to information system output devices to prevent unauthorized individuals from obtaining the output. Supplemental Guidance: Controlling physical access to output devices includes, for example, placing output devices in locked rooms or other secured areas and allowing access to authorized individuals only, and placing output devices in locations that can be monitored by organizational personnel. Monitors, printers, copiers, scanners, facsimile machines, and audio devices are examples of information system output devices. Related controls: PE-2, PE-3, PE-4, PE-18. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 PHYSICAL AND ENVIRONMENTAL PROTECTION PE-6 MONITORING PHYSICAL ACCESS ü The organization: a. Monitors physical access to the facility where the information system resides to detect and respond to physical security incidents; b. Reviews physical access logs [Assignment: organization-defined frequency] and upon occurrence of [Assignment: organization-defined events or potential indications of events]; and c. Coordinates results of reviews and investigations with the organizational incident response capability. Supplemental Guidance: Organizational incident response capabilities include investigations of and responses to detected physical security incidents. Security incidents include, for example, apparent security violations or suspicious physical access activities. Suspicious physical access activities include, for example: (i) accesses outside of normal work hours; (ii) repeated accesses to areas not normally accessed; (iii) accesses for unusual lengths of time; and (iv) out-of-sequence accesses. Related controls: CA-7, IR-4, IR-8. ü ü PE-6b. [at least monthly] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 PHYSICAL AND ENVIRONMENTAL PROTECTION PE-6 (1) MONITORING PHYSICAL ACCESS | INTRUSION ALARMS / SURVEILLANCE EQUIPMENT The organization monitors physical intrusion alarms and surveillance equipment. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 PHYSICAL AND ENVIRONMENTAL PROTECTION PE-6 (4) MONITORING PHYSICAL ACCESS | MONITORING PHYSICAL ACCESS TO INFORMATION SYSTEMS ü The organization monitors physical access to the information system in addition to the physical access monitoring of the facility as [Assignment: organization-defined physical spaces containing one or more components of the information system]. Supplemental Guidance: This control enhancement provides additional monitoring for those areas within facilities where there is a concentration of information system components (e.g., server rooms, media storage areas, communications centers). Related controls: PS-2, PS- ü Included in NIST High Baseline, Rev 4 [service provider physical spaces containing components that contain organization data] PHYSICAL AND ENVIRONMENTAL PROTECTION PE-8 VISITOR ACCESS RECORDS ü The organization: a. Maintains visitor access records to the facility where the information system resides for [Assignment: organization-defined time period]; and b. Reviews visitor access records [Assignment: organization-defined frequency]. Supplemental Guidance: Visitor access records include, for example, names and organizations of persons visiting, visitor signatures, forms of identification, dates of access, entry and departure times, purposes of visits, and names and organizations of persons visited. Visitor access records are not required for publicly accessible areas. ü ü PE-8a. [for a minimum of one year] PE-8b. [at least monthly] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 PHYSICAL AND ENVIRONMENTAL PROTECTION PE-8 (1) VISITOR ACCESS RECORDS | AUTOMATED RECORDS MAINTENANCE / REVIEW The organization employs automated mechanisms to facilitate the maintenance and review of visitor access records. ü Included in NIST High Baseline, Rev 4 PHYSICAL AND ENVIRONMENTAL PROTECTION PE-9 POWER EQUIPMENT AND CABLING The organization protects power equipment and power cabling for the information system from damage and destruction. Supplemental Guidance: Organizations determine the types of protection necessary for power equipment and cabling employed at different locations both internal and external to organizational facilities and environments of operation. This includes, for example, generators and power cabling outside of buildings, internal cabling and uninterruptable power sources within an office or data center, and power sources for self-contained entities such as vehicles and satellites. Related control: PE-4. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 PHYSICAL AND ENVIRONMENTAL PROTECTION PE-10 EMERGENCY SHUTOFF ü The organization: a. Provides the capability of shutting off power to the information system or individual system components in emergency situations; b. Places emergency shutoff switches or devices in [Assignment: organization-defined location by information system or system component] to facilitate safe and easy access for personnel; and c. Protects emergency power shutoff capability from unauthorized activation. Supplemental Guidance: This control applies primarily to facilities containing concentrations of information system resources including, for example, data centers, server rooms, and mainframe computer rooms. Related control: PE-15. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 PHYSICAL AND ENVIRONMENTAL PROTECTION PE-11 EMERGENCY POWER ü The organization provides a short-term uninterruptible power supply to facilitate [Selection (one or more): an orderly shutdown of the information system; transition of the information system to long-term alternate power] in the event of a primary power source loss. Supplemental Guidance: Related controls: AT-3, CP-2, CP-7. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 PHYSICAL AND ENVIRONMENTAL PROTECTION PE-11 (1) EMERGENCY POWER | LONG-TERM ALTERNATE POWER SUPPLY - MINIMAL OPERATIONAL CAPABILITY The organization provides a long-term alternate power supply for the information system that is capable of maintaining minimally required operational capability in the event of an extended loss of the primary power source. Supplemental Guidance: This control enhancement can be satisfied, for example, by the use of a secondary commercial power supply or other external power supply. Long-term alternate power supplies for the information system can be either manually or automatically activated. ü Included in NIST High Baseline, Rev 4 PHYSICAL AND ENVIRONMENTAL PROTECTION PE-12 EMERGENCY LIGHTING The organization employs and maintains automatic emergency lighting for the information system that activates in the event of a power outage or disruption and that covers emergency exits and evacuation routes within the facility. Supplemental Guidance: This control applies primarily to facilities containing concentrations of information system resources including, for example, data centers, server rooms, and mainframe computer rooms. Related controls: CP-2, CP-7. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 PHYSICAL AND ENVIRONMENTAL PROTECTION PE-13 FIRE PROTECTION The organization employs and maintains fire suppression and detection devices/systems for the information system that are supported by an independent energy source. Supplemental Guidance: This control applies primarily to facilities containing concentrations of information system resources including, for example, data centers, server rooms, and mainframe computer rooms. Fire suppression and detection devices/systems include, for example, sprinkler systems, handheld fire extinguishers, fixed fire hoses, and smoke detectors. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 PHYSICAL AND ENVIRONMENTAL PROTECTION PE-13 (1) FIRE PROTECTION | DETECTION DEVICES / SYSTEMS ü The organization employs fire detection devices/systems for the information system that activate automatically and notify [Assignment: organization-defined personnel or roles] and [Assignment: organization-defined emergency responders] in the event of a fire. Supplemental Guidance: Organizations can identify specific personnel, roles, and emergency responders in the event that individuals on the notification list must have appropriate access authorizations and/or clearances, for example, to obtain access to facilities where classified operations are taking place or where there are information systems containing classified information. ü Included in NIST High Baseline, Rev 4 [service provider building maintenance/physical security personnel] [service provider emergency responders with incident response responsibilities] PHYSICAL AND ENVIRONMENTAL PROTECTION PE-13 (2) FIRE PROTECTION | SUPPRESSION DEVICES / SYSTEMS ü The organization employs fire suppression devices/systems for the information system that provide automatic notification of any activation to Assignment: organization-defined personnel or roles] and [Assignment: organization-defined emergency responders]. Supplemental Guidance: Organizations can identify specific personnel, roles, and emergency responders in the event that individuals on the notification list must have appropriate access authorizations and/or clearances, for example, to obtain access to facilities where classified operations are taking place or where there are information systems containing classified information. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 PHYSICAL AND ENVIRONMENTAL PROTECTION PE-13 (3) FIRE PROTECTION | AUTOMATIC FIRE SUPPRESSION The organization employs an automatic fire suppression capability for the information system when the facility is not staffed on a continuous basis. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 PHYSICAL AND ENVIRONMENTAL PROTECTION PE-14 TEMPERATURE AND HUMIDITY CONTROLS ü The organization: a. Maintains temperature and humidity levels within the facility where the information system resides at [Assignment: organization-defined acceptable levels]; and b. Monitors temperature and humidity levels [Assignment: organization-defined frequency]. Supplemental Guidance: This control applies primarily to facilities containing concentrations of information system resources, for example, data centers, server rooms, and mainframe computer rooms. Related control: AT-3. ü ü PE-14a. [consistent with American Society of Heating, Refrigerating and Air-conditioning Engineers (ASHRAE) document entitled Thermal Guidelines for Data Processing Environments] PE-14b. [continuously] PE-14a. Requirements: The service provider measures temperature at server inlets and humidity levels by dew point. ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 PHYSICAL AND ENVIRONMENTAL PROTECTION PE-14 (2) TEMPERATURE AND HUMIDITY CONTROLS | MONITORING WITH ALARMS / NOTIFICATIONS The organization employs temperature and humidity monitoring that provides an alarm or notification of changes potentially harmful to personnel or equipment. ü ü Included in FedRAMP Moderate Baseline, Rev 4 PHYSICAL AND ENVIRONMENTAL PROTECTION PE-15 WATER DAMAGE PROTECTION The organization protects the information system from damage resulting from water leakage by providing master shutoff or isolation valves that are accessible, working properly, and known to key personnel. Supplemental Guidance: This control applies primarily to facilities containing concentrations of information system resources including, for example, data centers, server rooms, and mainframe computer rooms. Isolation valves can be employed in addition to or in lieu of master shutoff valves to shut off water supplies in specific areas of concern, without affecting entire organizations. Related control: AT-3. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 PHYSICAL AND ENVIRONMENTAL PROTECTION PE-15 (1) WATER DAMAGE PROTECTION | AUTOMATION SUPPORT ü The organization employs automated mechanisms to detect the presence of water in the vicinity of the information system and alerts [Assignment: organization-defined personnel or roles]. Supplemental Guidance: Automated mechanisms can include, for example, water detection sensors, alarms, and notification systems. ü Included in NIST High Baseline, Rev 4 [service provider building maintenance/physical security personnel] PHYSICAL AND ENVIRONMENTAL PROTECTION PE-16 DELIVERY AND REMOVAL ü The organization authorizes, monitors, and controls [Assignment: organization-defined types of information system components] entering and exiting the facility and maintains records of those items. Supplemental Guidance: Effectively enforcing authorizations for entry and exit of information system components may require restricting access to delivery areas and possibly isolating the areas from the information system and media libraries. Related controls: CM-3, MA-2, MA-3, MP-5, SA-12. ü ü PE-16. [all information system components] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 PHYSICAL AND ENVIRONMENTAL PROTECTION PE-17 ALTERNATE WORK SITE ü The organization: a. Employs [Assignment: organization-defined security controls] at alternate work sites; b. Assesses as feasible, the effectiveness of security controls at alternate work sites; and c. Provides a means for employees to communicate with information security personnel in case of security incidents or problems. Supplemental Guidance: Alternate work sites may include, for example, government facilities or private residences of employees. While commonly distinct from alternative processing sites, alternate work sites may provide readily available alternate locations as part of contingency operations. Organizations may define different sets of security controls for specific alternate work sites or types of sites depending on the work-related activities conducted at those sites. This control supports the contingency planning activities of organizations and the federal telework initiative. Related controls: AC-17, CP-7. Control Enhancements: None. References: NIST Special Publication 800-46. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 PHYSICAL AND ENVIRONMENTAL PROTECTION PE-18 LOCATION OF INFORMATION SYSTEM COMPONENTS ü The organization positions information system components within the facility to minimize potential damage from [Assignment: organization-defined physical and environmental hazards] and to minimize the opportunity for unauthorized access. Supplemental Guidance: Physical and environmental hazards include, for example, flooding, fire, tornados, earthquakes, hurricanes, acts of terrorism, vandalism, electromagnetic pulse, electrical interference, and other forms of incoming electromagnetic radiation. In addition, organizations consider the location of physical entry points where unauthorized individuals, while not being granted access, might nonetheless be in close proximity to information systems and therefore increase the potential for unauthorized access to organizational communications (e.g., through the use of wireless sniffers or microphones). Related controls: CP-2, PE-19, RA-3. ü Included in NIST High Baseline, Rev 4 [physical and environmental hazards identified during threat assessment] PLANNING PL-1 SECURITY PLANNING POLICY AND PROCEDURES ü The organization: a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]: 1. A security planning policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and 2. Procedures to facilitate the implementation of the security planning policy and associated security planning controls; and b. Reviews and updates the current: 1. Security planning policy [Assignment: organization-defined frequency]; and 2. Security planning procedures [Assignment: organization-defined frequency]. Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the PL family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9. Control Enhancements: None. References: NIST Special Publications 800-12, 800-18, 800-100. ü ü PL-1.b.1 [at least every 3 years] PL-1.b.2 [at least annually] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 PL-1.b.1 [at least annually] PL-1.b.2 [at least annually] PLANNING PL-2 SYSTEM SECURITY PLAN ü The organization: a. Develops a security plan for the information system that: 1. Is consistent with the organization’s enterprise architecture; 2. Explicitly defines the authorization boundary for the system; 3. Describes the operational context of the information system in terms of missions and business processes; 4. Provides the security categorization of the information system including supporting rationale; 5. Describes the operational environment for the information system and relationships with or connections to other information systems; 6. Provides an overview of the security requirements for the system; 7. Identifies any relevant overlays, if applicable; 8. Describes the security controls in place or planned for meeting those requirements including a rationale for the tailoring and supplementation decisions; and 9. Is reviewed and approved by the authorizing official or designated representative prior to plan implementation; b. Distributes copies of the security plan and communicates subsequent changes to the plan to [Assignment: organization-defined personnel or roles]; c. Reviews the security plan for the information system [Assignment: organization-defined frequency]; d. Updates the plan to address changes to the information system/environment of operation or problems identified during plan implementation or security control assessments; and e. Protects the security plan from unauthorized disclosure and modification. Supplemental Guidance: Security plans relate security requirements to a set of security controls and control enhancements. Security plans also describe, at a high level, how the security controls and control enhancements meet those security requirements, but do not provide detailed, technical descriptions of the specific design or implementation of the controls/enhancements. Security plans contain sufficient information (including the specification of parameter values for assignment and selection statements either explicitly or by reference) to enable a design and implementation that is unambiguously compliant with the intent of the plans and subsequent determinations of risk to organizational operations and assets, individuals, other organizations, and the Nation if the plan is implemented as intended. Organizations can also apply tailoring guidance to the security control baselines in Appendix D and CNSS Instruction 1253 to develop overlays for community-wide use or to address specialized requirements, technologies, or missions/environments of operation (e.g., DoD-tactical, Federal Public Key Infrastructure, or Federal Identity, Credential, and Access Management, space operations). Appendix I provides guidance on developing overlays. Security plans need not be single documents; the plans can be a collection of various documents including documents that already exist. Effective security plans make extensive use of references to policies, procedures, and additional documents (e.g., design and implementation specifications) where more detailed information can be obtained. This reduces the documentation requirements associated with security programs and maintains security-related information in other established management/operational areas related to enterprise architecture, system development life cycle, systems engineering, and acquisition. For example, security plans do not contain detailed contingency plan or incident response plan information but instead provide explicitly or by reference, sufficient information to define what needs to be accomplished by those plans. Related controls: AC-2, AC-6, AC-14, AC-17, AC-20, CA-2, CA-3, CA-7, CM-9, CP-2, IR-8, MA-4, MA-5, MP-2, MP-4, MP-5, PL-7, PM-1, PM-7, PM-8, PM-9, PM-11, SA-5, SA-17. ü ü PL-2b. [at least annually] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 PLANNING PL-2 (3) SYSTEM SECURITY PLAN | PLAN / COORDINATE WITH OTHER ORGANIZATIONAL ENTITIES ü The organization plans and coordinates security-related activities affecting the information system with [Assignment: organization-defined individuals or groups] before conducting such activities in order to reduce the impact on other organizational entities. Supplemental Guidance: Security-related activities include, for example, security assessments, audits, hardware and software maintenance, patch management, and contingency plan testing. Advance planning and coordination includes emergency and nonemergency (i.e., planned or nonurgent unplanned) situations. The process defined by organizations to plan and coordinate security-related activities can be included in security plans for information systems or other documents, as appropriate. Related controls: CP-4, IR-4. References: NIST Special Publication 800-18. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 PLANNING PL-4 RULES OF BEHAVIOR ü The organization: a. Establishes and makes readily available to individuals requiring access to the information system, the rules that describe their responsibilities and expected behavior with regard to information and information system usage; b. Receives a signed acknowledgment from such individuals, indicating that they have read, understand, and agree to abide by the rules of behavior, before authorizing access to information and the information system; c. Reviews and updates the rules of behavior [Assignment: organization-defined frequency]; and d. Requires individuals who have signed a previous version of the rules of behavior to read and resign when the rules of behavior are revised/updated. Supplemental Guidance: This control enhancement applies to organizational users. Organizations consider rules of behavior based on individual user roles and responsibilities, differentiating, for example, between rules that apply to privileged users and rules that apply to general users. Establishing rules of behavior for some types of non-organizational users including, for example, individuals who simply receive data/information from federal information systems, is often not feasible given the large number of such users and the limited nature of their interactions with the systems. Rules of behavior for both organizational and non-organizational users can also be established in AC-8, System Use Notification. PL-4 b. (the signed acknowledgment portion of this control) may be satisfied by the security awareness training and role-based security training programs conducted by organizations if such training includes rules of behavior. Organizations can use electronic signatures for acknowledging rules of behavior. Related controls: AC-2, AC-6, AC-8, AC-9, AC-17, AC-18, AC-19, AC-20, AT-2, AT-3, CM-11, IA-2, IA-4, IA-5, MP-7, PS-6, PS-8, SA-5. ü ü PL-4c. [At least every 3 years] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 PL-4c. [annually] PLANNING PL-4 (1) RULES OF BEHAVIOR | SOCIAL MEDIA AND NETWORKING RESTRICTIONS The organization includes in the rules of behavior, explicit restrictions on the use of social media/networking sites and posting organizational information on public websites. Supplemental Guidance: This control enhancement addresses rules of behavior related to the use of social media/networking sites: (i) when organizational personnel are using such sites for official duties or in the conduct of official business; (ii) when organizational information is involved in social media/networking transactions; and (iii) when personnel are accessing social media/networking sites from organizational information systems. Organizations also address specific rules that prevent unauthorized entities from obtaining and/or inferring non- public organizational information (e.g., system account information, personally identifiable information) from social media/networking sites. References: NIST Publication 800-18. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 PLANNING PL-8 INFORMATION SECURITY ARCHITECTURE ü The organization: a. Develops an information security architecture for the information system that: 1. Describes the overall philosophy, requirements, and approach to be taken with regard to protecting the confidentiality, integrity, and availability of organizational information; 2. Describes how the information security architecture is integrated into and supports the enterprise architecture; and 3. Describes any information security assumptions about, and dependencies on, external services; b. Reviews and updates the information security architecture [Assignment: organization-defined frequency] to reflect updates in the enterprise architecture; and c. Ensures that planned information security architecture changes are reflected in the security plan, the security Concept of Operations (CONOPS), and organizational procurements/acquisitions. Supplemental Guidance: This control addresses actions taken by organizations in the design and development of information systems. The information security architecture at the individual information system level is consistent with and complements the more global, organization-wide information security architecture described in PM-7 that is integral to and developed as part of the enterprise architecture. The information security architecture includes an architectural description, the placement/allocation of security functionality (including security controls), security-related information for external interfaces, information being exchanged across the interfaces, and the protection mechanisms associated with each interface. In addition, the security architecture can include other important security-related information, for example, user roles and access privileges assigned to each role, unique security requirements, the types of information processed, stored, and transmitted by the information system, restoration priorities of information and information system services, and any other specific protection needs. In today’s modern architecture, it is becoming less common for organizations to control all information resources. There are going to be key dependencies on external information services and service providers. Describing such dependencies in the information security architecture is important to developing a comprehensive mission/business protection strategy. Establishing, developing, documenting, and maintaining under configuration control, a baseline configuration for organizational information systems is critical to implementing and maintaining an effective information security architecture. The development of the information security architecture is coordinated with the Senior Agency Official for Privacy (SAOP)/Chief Privacy Officer (CPO) to ensure that security controls needed to support privacy requirements are identified and effectively implemented. PL-8 is primarily directed at organizations (i.e., internally focused) to help ensure that organizations develop an information security architecture for the information system, and that the security architecture is integrated with or tightly coupled to the enterprise architecture through the organization-wide information security architecture. In contrast, SA-17 is primarily directed at external information technology product/system developers and integrators (although SA-17 could be used internally within organizations for in-house system development). SA-17, which is complementary to PL-8, is selected when organizations outsource the development of information systems or information system components to external entities, and there is a need to demonstrate/show consistency with the organization’s enterprise architecture and information security architecture. Related controls: CM-2, CM-6, PL-2, PM-7, SA-5, SA-17, Appendix J. ü PL-8b. [At least annually or when a significant change occurs] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 PERSONNEL SECURITY PS-1 PERSONNEL SECURITY POLICY AND PROCEDURES ü The organization: a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]: 1. A personnel security policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and 2. Procedures to facilitate the implementation of the personnel security policy and associated personnel security controls; and b. Reviews and updates the current: 1. Personnel security policy [Assignment: organization-defined frequency]; and 2. Personnel security procedures [Assignment: organization-defined frequency]. Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the PS family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9. Control Enhancements: None. References: NIST Special Publications 800-12, 800-100. ü ü PS-1.b.1 [at least every 3 years] PS-1.b.2 [at least annually] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 PS-1.b.1 [at least annually] PS-1.b.2 [at least every six months] PERSONNEL SECURITY PS-2 POSITION RISK DESIGNATION ü The organization: a. Assigns a risk designation to all organizational positions; b. Establishes screening criteria for individuals filling those positions; and c. Reviews and updates position risk designations [Assignment: organization-defined frequency]. Supplemental Guidance: Position risk designations reflect Office of Personnel Management policy and guidance. Risk designations can guide and inform the types of authorizations individuals receive when accessing organizational information and information systems. Position screening criteria include explicit information security role appointment requirements (e.g., training, security clearances). Related controls: AT-3, PL-2, PS-3. Control Enhancements: None. References: 5 C.F.R. 731.106(a). ü ü PS-2c. [at least every three years] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 PS-2c. [at least annually] PERSONNEL SECURITY PS-3 PERSONNEL SCREENING ü The organization: a. Screens individuals prior to authorizing access to the information system; and b. Rescreens individuals according to [Assignment: organization-defined conditions requiring rescreening and, where rescreening is so indicated, the frequency of such rescreening]. Supplemental Guidance: Personnel screening and rescreening activities reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, guidance, and specific criteria established for the risk designations of assigned positions. Organizations may define different rescreening conditions and frequencies for personnel accessing information systems based on types of information processed, stored, or transmitted by the systems. Related controls: AC-2, IA- 4, PE-2, PS-2. ü ü PS-3b. [for national security clearances; a reinvestigation is required during the 5th year for top secret security clearance, the 10th year for secret security clearance, and 15th year for confidential security clearance. For moderate risk law enforcement and high impact public trust level, a reinvestigation is required during the 5th year. There is no reinvestigation for other moderate risk positions or any low risk positions] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 PERSONNEL SECURITY PS-3 (3) PERSONNEL SCREENING | INFORMATION WITH SPECIAL PROTECTION MEASURES ü The organization ensures that individuals accessing an information system processing, storing, or transmitting information requiring special protection: (a) Have valid access authorizations that are demonstrated by assigned official government duties; and (b) Satisfy [Assignment: organization-defined additional personnel screening criteria]. Supplemental Guidance: Organizational information requiring special protection includes, for example, Controlled Unclassified Information (CUI) and Sources and Methods Information (SAMI). Personnel security criteria include, for example, position sensitivity background screening requirements. ü PS-3 (3)(b). [personnel screening criteria – as required by specific information] ü Included in FedRAMP Moderate Baseline, Rev 4 PERSONNEL SECURITY PS-4 PERSONNEL TERMINATION ü The organization, upon termination of individual employment: a. Disables information system access within [Assignment: organization-defined time period]; b. Terminates/revokes any authenticators/credentials associated with the individual; c. Conducts exit interviews that include a discussion of [Assignment: organization-defined information security topics]; d. Retrieves all security-related organizational information system-related property; e. Retains access to organizational information and information systems formerly controlled by terminated individual; and f. Notifies [Assignment: organization-defined personnel or roles] within [Assignment: organization-defined time period]. Supplemental Guidance: Information system-related property includes, for example, hardware authentication tokens, system administration technical manuals, keys, identification cards, and building passes. Exit interviews ensure that terminated individuals understand the security constraints imposed by being former employees and that proper accountability is achieved for information system-related property. Security topics of interest at exit interviews can include, for example, reminding terminated individuals of nondisclosure agreements and potential limitations on future employment. Exit interviews may not be possible for some terminated individuals, for example, in cases related to job abandonment, illnesses, and nonavailability of supervisors. Exit interviews are important for individuals with security clearances. Timely execution of termination actions is essential for individuals terminated for cause. In certain situations, organizations consider disabling the information system accounts of individuals that are being terminated prior to the individuals being notified. Related controls: AC-2, IA-4, PE-2, PS-5, PS-6. ü ü PS-4.a. [same day] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 PS-4.a. [immediately] PERSONNEL SECURITY PS-4 (2) PERSONNEL TERMINATION | AUTOMATED NOTIFICATION ü The organization employs automated mechanisms to notify [Assignment: organization-defined personnel or roles] upon termination of an individual. Supplemental Guidance: In organizations with a large number of employees, not all personnel who need to know about termination actions receive the appropriate notifications—or, if such notifications are received, they may not occur in a timely manner. Automated mechanisms can be used to send automatic alerts or notifications to specific organizational personnel or roles (e.g., management personnel, supervisors, personnel security officers, information security officers, systems administrators, or information technology administrators) when individuals are terminated. Such automatic alerts or notifications can be conveyed in a variety of ways, including, for example, telephonically, via electronic mail, via text message, or via websites. References: None. ü Included in NIST High Baseline, Rev 4 [access control personnel responsible for disabling access to the system] PERSONNEL SECURITY PS-5 PERSONNEL TRANSFER ü The organization: a. Reviews and confirms ongoing operational need for current logical and physical access authorizations to information systems/facilities when individuals are reassigned or transferred to other positions within the organization; b. Initiates [Assignment: organization-defined transfer or reassignment actions] within [Assignment: organization-defined time period following the formal transfer action]; c. Modifies access authorization as needed to correspond with any changes in operational need due to reassignment or transfer; and d. Notifies [Assignment: organization-defined personnel or roles] within [Assignment: organization-defined time period]. Supplemental Guidance: This control applies when reassignments or transfers of individuals are permanent or of such extended durations as to make the actions warranted. Organizations define actions appropriate for the types of reassignments or transfers, whether permanent or extended. Actions that may be required for personnel transfers or reassignments to other positions within organizations include, for example: (i) returning old and issuing new keys, identification cards, and building passes; (ii) closing information system accounts and establishing new accounts; (iii) changing information system access authorizations (i.e., privileges); and (iv) providing for access to official records to which individuals had access at previous work locations and in previous information system accounts. Related controls: AC-2, IA-4, PE-2, PS-4. Control Enhancements: None. References: None. ü ü PS-5. [within five days of the formal transfer action (DoD 24 hours)] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 PS-5b. [within 24 hours] PERSONNEL SECURITY PS-6 ACCESS AGREEMENTS ü The organization: a. Develops and documents access agreements for organizational information systems; b. Reviews and updates the access agreements [Assignment: organization-defined frequency]; and c. Ensures that individuals requiring access to organizational information and information systems: 1. Sign appropriate access agreements prior to being granted access; and 2. Re-sign access agreements to maintain access to organizational information systems when access agreements have been updated or [Assignment: organization-defined frequency]. Supplemental Guidance: Access agreements include, for example, nondisclosure agreements, acceptable use agreements, rules of behavior, and conflict-of-interest agreements. Signed access agreements include an acknowledgement that individuals have read, understand, and agree to abide by the constraints associated with organizational information systems to which access is authorized. Organizations can use electronic signatures to acknowledge access agreements unless specifically prohibited by organizational policy. Related control: PL-4, PS-2, PS-3, PS-4, PS-8. ü ü PS-6b. [at least annually] PS-6c.2. [at least annually] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 PS-6b. [at least annually] PS-6c.2. [at least annually and any time there is a change to the user's level of access] PERSONNEL SECURITY PS-7 THIRD-PARTY PERSONNEL SECURITY ü The organization: a. Establishes personnel security requirements including security roles and responsibilities for third-party providers; b. Requires third-party providers to comply with personnel security policies and procedures established by the organization; c. Documents personnel security requirements; d. Requires third-party providers to notify [Assignment: organization-defined personnel or roles] of any personnel transfers or terminations of third-party personnel who possess organizational credentials and/or badges, or who have information system privileges within [Assignment: organization-defined time period]; and e. Monitors provider compliance. Supplemental Guidance: Third-party providers include, for example, service bureaus, contractors, and other organizations providing information system development, information technology services, outsourced applications, and network and security management. Organizations explicitly include personnel security requirements in acquisition-related documents. Third-party providers may have personnel working at organizational facilities with credentials, badges, or information system privileges issued by organizations. Notifications of third-party personnel changes ensure appropriate termination of privileges and credentials. Organizations define the transfers and terminations deemed reportable by security-related characteristics that include, for example, functions, roles, and nature of credentials/privileges associated with individuals transferred or terminated. Related controls: PS-2, PS-3, PS-4, PS-5, PS-6, SA-9, SA-21. Control Enhancements: None. References: NIST Special Publication 800-35. ü ü PS-7d. organization-defined time period – same day ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 [terminations: immediately; transfers: same day] PERSONNEL SECURITY PS-8 PERSONNEL SANCTIONS ü The organization: a. Employs a formal sanctions process for individuals failing to comply with established information security policies and procedures; and b. Notifies [Assignment: organization-defined personnel or roles] within [Assignment: organization-defined time period] when a formal employee sanctions process is initiated, identifying the individual sanctioned and the reason for the sanction. Supplemental Guidance: Organizational sanctions processes reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Sanctions processes are described in access agreements and can be included as part of general personnel policies and procedures for organizations. Organizations consult with the Office of the General Counsel regarding matters of employee sanctions. Related controls: PL-4, PS-6. Control Enhancements: None. References: None. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 RISK ASSESSMENT RA-1 RISK ASSESSMENT POLICY AND PROCEDURES ü The organization: a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]: 1. A risk assessment policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and 2. Procedures to facilitate the implementation of the risk assessment policy and associated risk assessment controls; and b. Reviews and updates the current: 1. Risk assessment policy [Assignment: organization-defined frequency]; and 2. Risk assessment procedures [Assignment: organization-defined frequency]. Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the RA family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9. Control Enhancements: None. References: NIST Special Publications 800-12, 800-30, 800-100. ü ü RA-1.b.1 [at least every 3 years] RA-1.b.2 [at least annually] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 RA-1.b.1 [at least annually] RA-1.b.2 [at least every six months] RISK ASSESSMENT RA-2 SECURITY CATEGORIZATION The organization: a. Categorizes information and the information system in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance; b. Documents the security categorization results (including supporting rationale) in the security plan for the information system; and c. Ensures that the security categorization decision is reviewed and approved by the authorizing official or authorizing official designated representative. Supplemental Guidance: Clearly defined authorization boundaries are a prerequisite for effective security categorization decisions. Security categories describe the potential adverse impacts to organizational operations, organizational assets, and individuals if organizational information and information systems are comprised through a loss of confidentiality, integrity, or availability. Organizations conduct the security categorization process as an organization-wide activity with the involvement of chief information officers, senior information security officers, information system owners, mission/business owners, and information owners/stewards. Organizations also consider the potential adverse impacts to other organizations and, in accordance with the USA PATRIOT Act of 2001 and Homeland Security Presidential Directives, potential national-level adverse impacts. Security categorization processes carried out by organizations facilitate the development of inventories of information assets, and along with CM-8, mappings to specific information system components where information is processed, stored, or transmitted. Related controls: CM-8, MP-4, RA-3, SC-7. Control Enhancements: None. References: FIPS Publication 199; NIST Special Publications 800-30, 800-39, 800-60. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 RISK ASSESSMENT RA-3 RISK ASSESSMENT ü The organization: a. Conducts an assessment of risk, including the likelihood and magnitude of harm, from the unauthorized access, use, disclosure, disruption, modification, or destruction of the information system and the information it processes, stores, or transmits; b. Documents risk assessment results in [Selection: security plan; risk assessment report; [Assignment: organization-defined document]]; c. Reviews risk assessment results [Assignment: organization-defined frequency]; d. Disseminates risk assessment results to [Assignment: organization-defined personnel or roles]; and e. Updates the risk assessment [Assignment: organization-defined frequency] or whenever there are significant changes to the information system or environment of operation (including the identification of new threats and vulnerabilities), or other conditions that may impact the security state of the system. Supplemental Guidance: Clearly defined authorization boundaries are a prerequisite for effective risk assessments. Risk assessments take into account threats, vulnerabilities, likelihood, and impact to organizational operations and assets, individuals, other organizations, and the Nation based on the operation and use of information systems. Risk assessments also take into account risk from external parties (e.g., service providers, contractors operating information systems on behalf of the organization, individuals accessing organizational information systems, outsourcing entities). In accordance with OMB policy and related E-authentication initiatives, authentication of public users accessing federal information systems may also be required to protect nonpublic or privacy-related information. As such, organizational assessments of risk also address public access to federal information systems. Risk assessments (either formal or informal) can be conducted at all three tiers in the risk management hierarchy (i.e., organization level, mission/business process level, or information system level) and at any phase in the system development life cycle. Risk assessments can also be conducted at various steps in the Risk Management Framework, including categorization, security control selection, security control implementation, security control assessment, information system authorization, and security control monitoring. RA-3 is noteworthy in that the control must be partially implemented prior to the implementation of other controls in order to complete the first two steps in the Risk Management Framework. Risk assessments can play an important role in security control selection processes, particularly during the application of tailoring guidance, which includes security control supplementation. Related controls: RA-2, PM-9. Control Enhancements: None. References: OMB Memorandum 04-04; NIST Special Publication 800-30, 800-39; Web: idmanagement.gov. ü ü RA-3b. [security assessment report] RA-3c. [at least every three years or when a significant change occurs] RA-3d. [at least every three years or when a significant change occurs] Guidance: Significant change is defined in NIST Special Publication 800-37 Revision 1, Appendix F. RA-3d. Requirement: to include the Authorizing Official; for JAB authorizations to include FedRAMP ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 RA-3b. [security assessment report] RA-3c. [Refer to CDM requirement] RA-3e. [Refer to CDM requirements] RISK ASSESSMENT RA-5 VULNERABILITY SCANNING ü The organization: a. Scans for vulnerabilities in the information system and hosted applications [Assignment: organization-defined frequency and/or randomly in accordance with organization-defined process] and when new vulnerabilities potentially affecting the system/applications are identified and reported; b. Employs vulnerability scanning tools and techniques that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for: 1. Enumerating platforms, software flaws, and improper configurations; 2. Formatting checklists and test procedures; and 3. Measuring vulnerability impact; c. Analyzes vulnerability scan reports and results from security control assessments; d. Remediates legitimate vulnerabilities [Assignment: organization-defined response times] in accordance with an organizational assessment of risk; and e. Shares information obtained from the vulnerability scanning process and security control assessments with [Assignment: organization-defined personnel or roles] to help eliminate similar vulnerabilities in other information systems (i.e., systemic weaknesses or deficiencies). Supplemental Guidance: Security categorization of information systems guides the frequency and comprehensiveness of vulnerability scans. Organizations determine the required vulnerability scanning for all information system components, ensuring that potential sources of vulnerabilities such as networked printers, scanners, and copiers are not overlooked. Vulnerability analyses for custom software applications may require additional approaches such as static analysis, dynamic analysis, binary analysis, or a hybrid of the three approaches. Organizations can employ these analysis approaches in a variety of tools (e.g., web-based application scanners, static analysis tools, binary analyzers) and in source code reviews. Vulnerability scanning includes, for example: (i) scanning for patch levels; (ii) scanning for functions, ports, protocols, and services that should not be accessible to users or devices; and (iii) scanning for improperly configured or incorrectly operating information flow control mechanisms. Organizations consider using tools that express vulnerabilities in the Common Vulnerabilities and Exposures (CVE) naming convention and that use the Open Vulnerability Assessment Language (OVAL) to determine/test for the presence of vulnerabilities. Suggested sources for vulnerability information include the Common Weakness Enumeration (CWE) listing and the National Vulnerability Database (NVD). In addition, security control assessments such as red team exercises provide other sources of potential vulnerabilities for which to scan. Organizations also consider using tools that express vulnerability impact by the Common Vulnerability Scoring System (CVSS). Related controls: CA-2, CA-7, CM-4, CM-6, RA-2, RA-3, SA-11, SI-2. ü ü RA-5a. [monthly operating system/infrastructure; monthly web applications and databases] RA-5d. [high-risk vulnerabilities mitigated within thirty days from date of discovery; moderate-risk vulnerabilities mitigated within ninety days from date of discovery] RA-5a. Requirement: an accredited independent assessor scans operating systems/infrastructure, web applications, and databases once annually. RA-5e. Requirement: to include the Risk Executive; for JAB authorizations to include FedRAMP ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 RISK ASSESSMENT RA-5 (1) VULNERABILITY SCANNING | UPDATE TOOL CAPABILITY The organization employs vulnerability scanning tools that include the capability to readily update the information system vulnerabilities to be scanned. Supplemental Guidance: The vulnerabilities to be scanned need to be readily updated as new vulnerabilities are discovered, announced, and scanning methods developed. This updating process helps to ensure that potential vulnerabilities in the information system are identified and addressed as quickly as possible. Related controls: SI-3, SI-7. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 RISK ASSESSMENT RA-5 (2) VULNERABILITY SCANNING | UPDATE BY FREQUENCY / PRIOR TO NEW SCAN / WHEN IDENTIFIED ü The organization updates the information system vulnerabilities scanned [Selection (one or more): [Assignment: organization-defined frequency]; prior to a new scan; when new vulnerabilities are identified and reported]. Supplemental Guidance: Related controls: SI-3, SI-5. ü RA-5 (2). [prior to a new scan] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 RISK ASSESSMENT RA-5 (3) VULNERABILITY SCANNING | BREADTH / DEPTH OF COVERAGE The organization employs vulnerability scanning procedures that can identify the breadth and depth of coverage (i.e., information system components scanned and vulnerabilities checked). ü ü Included in FedRAMP Moderate Baseline, Rev 4 RISK ASSESSMENT RA-5 (4) VULNERABILITY SCANNING | DISCOVERABLE INFORMATION ü The organization determines what information about the information system is discoverable by adversaries and subsequently takes [Assignment: organization-defined corrective actions]. Supplemental Guidance: Discoverable information includes information that adversaries could obtain without directly compromising or breaching the information system, for example, by collecting information the system is exposing or by conducting extensive searches of the web. Corrective actions can include, for example, notifying appropriate organizational personnel, removing designated information, or changing the information system to make designated information less relevant or attractive to adversaries. Related control: AU-13. ü Included in NIST High Baseline, Rev 4 [notify appropriate service provider personnel and follow procedures for organization and service provider-defined corrective actions] RISK ASSESSMENT RA-5 (5) VULNERABILITY SCANNING | PRIVILEGED ACCESS ü The information system implements privileged access authorization to [Assignment: organization- identified information system components] for selected [Assignment: organization-defined vulnerability scanning activities]. Supplemental Guidance: In certain situations, the nature of the vulnerability scanning may be more intrusive or the information system component that is the subject of the scanning may contain highly sensitive information. Privileged access authorization to selected system components facilitates more thorough vulnerability scanning and also protects the sensitive nature of such scanning. ü RA-5 (5). [operating systems / web applications / databases] [all scans] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 RISK ASSESSMENT RA-5 (6) VULNERABILITY SCANNING | AUTOMATED TREND ANALYSES The organization employs automated mechanisms to compare the results of vulnerability scans over time to determine trends in information system vulnerabilities. Supplemental Guidance: Related controls: IR-4, IR-5, SI-4. ü RA-5(6) Guidance: include in Continuous Monitoring ISSO digest/report to Authorizing Official ü Included in FedRAMP Moderate Baseline, Rev 4 RISK ASSESSMENT RA-5 (8) VULNERABILITY SCANNING | REVIEW HISTORIC AUDIT LOGS The organization reviews historic audit logs to determine if a vulnerability identified in the information system has been previously exploited. Supplemental Guidance: Related control: AU-6. ü RA-5 (8). Requirements: This enhancement is required for all high vulnerability scan findings. Guidance: While scanning tools may label findings as high or critical, the intent of the control is based around NIST's definition of high vulnerability. ü Included in FedRAMP Moderate Baseline, Rev 4 RISK ASSESSMENT RA-5 (10) VULNERABILITY SCANNING | CORRELATE SCANNING INFORMATION The organization correlates the output from vulnerability scanning tools to determine the presence of multi-vulnerability/multi-hop attack vectors. ü NEED. Organizations commonly run vulnerability scanning tools against diverse enterprise systems and subsystems. These tools are often attuned to the specific subsystems, and often provided by different manufacturers. Because there is no single-vendor consolidation of all scanning tools, organizations need to correlate the outputs of these tools in order to triangulate on potential threats that may be related, or identical at their source. When the security impact is high a shared-service environment may increase the number of independent scanning tools, implementation of this control is warranted. ANALYSIS. Although this control is well understood by vendors, its implementation takes many forms, depending on the scanning tools adopted by a particular organization. Depending on the variety of tools and the complexity of systems scanned, cost and time to implementation could become significant factors. SAMPLE THREAT VECTORS. Different scanning tools discover low-impact vulnerabilities in multiple subsystems of a system. Considered individually, none of them warrants immediate action,; yet when considered together, they constitute a significant attack pattern. RELEVANT SECURITY CONTROL ATTRIBUTES. Interoperable, Change Managed, Agile, Supported, Assessed, Monitored SYSTEM AND SERVICES ACQUISITION SA-1 SYSTEM AND SERVICES ACQUISITION POLICY AND PROCEDURES ü The organization: a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]: 1. A system and services acquisition policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and 2. Procedures to facilitate the implementation of the system and services acquisition policy and associated system and services acquisition controls; and b. Reviews and updates the current: 1. System and services acquisition policy [Assignment: organization-defined frequency]; and 2. System and services acquisition procedures [Assignment: organization-defined frequency]. Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the SA family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9. Control Enhancements: None. References: NIST Special Publications 800-12, 800-100. ü ü SA-1.b.1 [at least every 3 years] SA-1.b.2 [at least annually] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SA-1.b.1 [at least annually] SA-1.b.2 [at least annually] SYSTEM AND SERVICES ACQUISITION SA-2 ALLOCATION OF RESOURCES The organization: a. Determines information security requirements for the information system or information system service in mission/business process planning; b. Determines, documents, and allocates the resources required to protect the information system or information system service as part of its capital planning and investment control process; and c. Establishes a discrete line item for information security in organizational programming and budgeting documentation. Supplemental Guidance: Resource allocation for information security includes funding for the initial information system or information system service acquisition and funding for the sustainment of the system/service. Related controls: PM-3, PM-11. Control Enhancements: None. References: NIST Special Publication 800-65. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND SERVICES ACQUISITION SA-3 SYSTEM DEVELOPMENT LIFE CYCLE ü The organization: a. Manages the information system using [Assignment: organization-defined system development life cycle] that incorporates information security considerations; b. Defines and documents information security roles and responsibilities throughout the system development life cycle; c. Identifies individuals having information security roles and responsibilities; and d. Integrates the organizational information security risk management process into system development life cycle activities. Supplemental Guidance: A well-defined system development life cycle provides the foundation for the successful development, implementation, and operation of organizational information systems. To apply the required security controls within the system development life cycle requires a basic understanding of information security, threats, vulnerabilities, adverse impacts, and risk to critical missions/business functions. The security engineering principles in SA-8 cannot be properly applied if individuals that design, code, and test information systems and system components (including information technology products) do not understand security. Therefore, organizations include qualified personnel, for example, chief information security officers, security architects, security engineers, and information system security officers in system development life cycle activities to ensure that security requirements are incorporated into organizational information systems. It is equally important that developers include individuals on the development team that possess the requisite security expertise and skills to ensure that needed security capabilities are effectively integrated into the information system. Security awareness and training programs can help ensure that individuals having key security roles and responsibilities have the appropriate experience, skills, and expertise to conduct assigned system development life cycle activities. The effective integration of security requirements into enterprise architecture also helps to ensure that important security considerations are addressed early in the system development life cycle and that those considerations are directly related to the organizational mission/business processes. This process also facilitates the integration of the information security architecture into the enterprise architecture, consistent with organizational risk management and information security strategies. Related controls: AT-3, PM-7, SA-8. Control Enhancements: None. References: NIST Special Publications 800-37, 800-64. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND SERVICES ACQUISITION SA-4 ACQUISITION PROCESS The organization includes the following requirements, descriptions, and criteria, explicitly or by reference, in the acquisition contract for the information system, system component, or information system service in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, guidelines, and organizational mission/business needs: a. Security functional requirements; b. Security strength requirements; c. Security assurance requirements; d. Security-related documentation requirements; e. Requirements for protecting security-related documentation; f. Description of the information system development environment and environment in which the system is intended to operate; and g. Acceptance criteria. Supplemental Guidance: Information system components are discrete, identifiable information technology assets (e.g., hardware, software, or firmware) that represent the building blocks of an information system. Information system components include commercial information technology products. Security functional requirements include security capabilities, security functions, and security mechanisms. Security strength requirements associated with such capabilities, functions, and mechanisms include degree of correctness, completeness, resistance to direct attack, and resistance to tampering or bypass. Security assurance requirements include: (i) development processes, procedures, practices, and methodologies; and (ii) evidence from development and assessment activities providing grounds for confidence that the required security functionality has been implemented and the required security strength has been achieved. Security documentation requirements address all phases of the system development life cycle. Security functionality, assurance, and documentation requirements are expressed in terms of security controls and control enhancements that have been selected through the tailoring process. The security control tailoring process includes, for example, the specification of parameter values through the use of assignment and selection statements and the specification of platform dependencies and implementation information. Security documentation provides user and administrator guidance regarding the implementation and operation of security controls. The level of detail required in security documentation is based on the security category or classification level of the information system and the degree to which organizations depend on the stated security capability, functions, or mechanisms to meet overall risk response expectations (as defined in the organizational risk management strategy). Security requirements can also include organizationally mandated configuration settings specifying allowed functions, ports, protocols, and services. Acceptance criteria for information systems, information system components, and information system services are defined in the same manner as such criteria for any organizational acquisition or procurement. The Federal Acquisition Regulation (FAR) Section 7.103 contains information security requirements from FISMA. Related controls: CM-6, PL-2, PS-7, SA-3, SA-5, SA-8, SA- 11, SA-12. ü ü "SA-4. Guidance: The use of Common Criteria (ISO/IEC 15408) evaluated products is strongly preferred. See http://www.niap-ccevs.org/vpl or http://www.commoncriteriaportal.org/products.html. " ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND SERVICES ACQUISITION SA-4 (1) ACQUISITION PROCESS | FUNCTIONAL PROPERTIES OF SECURITY CONTROLS The organization requires the developer of the information system, system component, or information system service to provide a description of the functional properties of the security controls to be employed. Supplemental Guidance: Functional properties of security controls describe the functionality (i.e., security capability, functions, or mechanisms) visible at the interfaces of the controls and specifically exclude functionality and data structures internal to the operation of the controls. Related control: SA-5. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND SERVICES ACQUISITION SA-4 (2) ACQUISITION PROCESS | DESIGN / IMPLEMENTATION INFORMATION FOR SECURITY CONTROLS ü The organization requires the developer of the information system, system component, or information system service to provide design and implementation information for the security controls to be employed that includes: [Selection (one or more): security-relevant external system interfaces; high-level design; low-level design; source code or hardware schematics; [Assignment: organization-defined design/implementation information]] at [Assignment: organization-defined level of detail]. Supplemental Guidance: Organizations may require different levels of detail in design and implementation documentation for security controls employed in organizational information systems, system components, or information system services based on mission/business requirements, requirements for trustworthiness/resiliency, and requirements for analysis and testing. Information systems can be partitioned into multiple subsystems. Each subsystem within the system can contain one or more modules. The high-level design for the system is expressed in terms of multiple subsystems and the interfaces between subsystems providing security-relevant functionality. The low-level design for the system is expressed in terms of modules with particular emphasis on software and firmware (but not excluding hardware) and the interfaces between modules providing security-relevant functionality. Source code and hardware schematics are typically referred to as the implementation representation of the information system. Related control: SA-5. ü [to include security-relevant external system interfaces and high-level design] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 [to include security-relevant external system interfaces, high-level design, hardware schematics] SYSTEM AND SERVICES ACQUISITION SA-4 (8) ACQUISITION PROCESS | CONTINUOUS MONITORING PLAN ü The organization requires the developer of the information system, system component, or information system service to produce a plan for the continuous monitoring of security control effectiveness that contains [Assignment: organization-defined level of detail]. Supplemental Guidance: The objective of continuous monitoring plans is to determine if the complete set of planned, required, and deployed security controls within the information system, system component, or information system service continue to be effective over time based on the inevitable changes that occur. Developer continuous monitoring plans include a sufficient level of detail such that the information can be incorporated into the continuous monitoring strategies and programs implemented by organizations. Related control: CA-7. ü SA-4 (8). [at least the minimum requirement as defined in control CA-7] SA-4 (8) Guidance: CSP must use the same security standards regardless of where the system component or information system service is acquired. ü Included in FedRAMP Moderate Baseline, Rev 4 SYSTEM AND SERVICES ACQUISITION SA-4 (9) ACQUISITION PROCESS | FUNCTIONS / PORTS / PROTOCOLS / SERVICES IN USE The organization requires the developer of the information system, system component, or information system service to identify early in the system development life cycle, the functions, ports, protocols, and services intended for organizational use. Supplemental Guidance: The identification of functions, ports, protocols, and services early in the system development life cycle (e.g., during the initial requirements definition and design phases) allows organizations to influence the design of the information system, information system component, or information system service. This early involvement in the life cycle helps organizations to avoid or minimize the use of functions, ports, protocols, or services that pose unnecessarily high risks and understand the trade-offs involved in blocking specific ports, protocols, or services (or when requiring information system service providers to do so). Early identification of functions, ports, protocols, and services avoids costly retrofitting of security controls after the information system, system component, or information system service has been implemented. SA-9 describes requirements for external information system services with organizations identifying which functions, ports, protocols, and services are provided from external sources. Related controls: CM-7, SA-9. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND SERVICES ACQUISITION SA-4 (10) ACQUISITION PROCESS | USE OF APPROVED PIV PRODUCTS The organization employs only information technology products on the FIPS 201-approved products list for Personal Identity Verification (PIV) capability implemented within organizational information systems. Supplemental Guidance: Related controls: IA-2; IA-8. References: HSPD-12; ISO/IEC 15408; FIPS Publications 140-2, 201; NIST Special Publications 800-23, 800-35, 800-36, 800-37, 800-64, 800-70, 800-137; Federal Acquisition Regulation; Web: www.niap-ccevs.org, fips201ep.cio.gov, www.acquisition.gov/far. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND SERVICES ACQUISITION SA-5 INFORMATION SYSTEM DOCUMENTATION ü The organization: a. Obtains administrator documentation for the information system, system component, or information system service that describes: 1. Secure configuration, installation, and operation of the system, component, or service; 2. Effective use and maintenance of security functions/mechanisms; and 3. Known vulnerabilities regarding configuration and use of administrative (i.e., privileged) functions; b. Obtains user documentation for the information system, system component, or information system service that describes: 1. User-accessible security functions/mechanisms and how to effectively use those security functions/mechanisms; 2. Methods for user interaction, which enables individuals to use the system, component, or service in a more secure manner; and 3. User responsibilities in maintaining the security of the system, component, or service; c. Documents attempts to obtain information system, system component, or information system service documentation when such documentation is either unavailable or nonexistent and [Assignment: organization-defined actions] in response; d. Protects documentation as required, in accordance with the risk management strategy; and e. Distributes documentation to [Assignment: organization-defined personnel or roles]. Supplemental Guidance: This control helps organizational personnel understand the implementation and operation of security controls associated with information systems, system components, and information system services. Organizations consider establishing specific measures to determine the quality/completeness of the content provided. The inability to obtain needed documentation may occur, for example, due to the age of the information system/component or lack of support from developers and contractors. In those situations, organizations may need to recreate selected documentation if such documentation is essential to the effective implementation or operation of security controls. The level of protection provided for selected information system, component, or service documentation is commensurate with the security category or classification of the system. For example, documentation associated with a key DoD weapons system or command and control system would typically require a higher level of protection than a routine administrative system. Documentation that addresses information system vulnerabilities may also require an increased level of protection. Secure operation of the information system, includes, for example, initially starting the system and resuming secure system operation after any lapse in system operation. Related controls: CM-6, CM-8, PL-2, PL-4, PS-2, SA-3, SA-4. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND SERVICES ACQUISITION SA-8 SECURITY ENGINEERING PRINCIPLES The organization applies information system security engineering principles in the specification, design, development, implementation, and modification of the information system. Supplemental Guidance: Organizations apply security engineering principles primarily to new development information systems or systems undergoing major upgrades. For legacy systems, organizations apply security engineering principles to system upgrades and modifications to the extent feasible, given the current state of hardware, software, and firmware within those systems. Security engineering principles include, for example: (i) developing layered protections; (ii) establishing sound security policy, architecture, and controls as the foundation for design; (iii) incorporating security requirements into the system development life cycle; (iv) delineating physical and logical security boundaries; (v) ensuring that system developers are trained on how to build secure software; (vi) tailoring security controls to meet organizational and operational needs; (vii) performing threat modeling to identify use cases, threat agents, attack vectors, and attack patterns as well as compensating controls and design patterns needed to mitigate risk; and (viii) reducing risk to acceptable levels, thus enabling informed risk management decisions. Related controls: PM-7, SA-3, SA-4, SA-17, SC-2, SC-3. Control Enhancements: None. References: NIST Special Publication 800-27. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND SERVICES ACQUISITION SA-9 EXTERNAL INFORMATION SYSTEM SERVICES ü The organization: a. Requires that providers of external information system services comply with organizational information security requirements and employ [Assignment: organization-defined security controls] in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance; b. Defines and documents government oversight and user roles and responsibilities with regard to external information system services; and c. Employs [Assignment: organization-defined processes, methods, and techniques] to monitor security control compliance by external service providers on an ongoing basis. Supplemental Guidance: External information system services are services that are implemented outside of the authorization boundaries of organizational information systems. This includes services that are used by, but not a part of, organizational information systems. FISMA and OMB policy require that organizations using external service providers that are processing, storing, or transmitting federal information or operating information systems on behalf of the federal government ensure that such providers meet the same security requirements that federal agencies are required to meet. Organizations establish relationships with external service providers in a variety of ways including, for example, through joint ventures, business partnerships, contracts, interagency agreements, lines of business arrangements, licensing agreements, and supply chain exchanges. The responsibility for managing risks from the use of external information system services remains with authorizing officials. For services external to organizations, a chain of trust requires that organizations establish and retain a level of confidence that each participating provider in the potentially complex consumer-provider relationship provides adequate protection for the services rendered. The extent and nature of this chain of trust varies based on the relationships between organizations and the external providers. Organizations document the basis for trust relationships so the relationships can be monitored over time. External information system services documentation includes government, service providers, end user security roles and responsibilities, and service-level agreements. Service-level agreements define expectations of performance for security controls, describe measurable outcomes, and identify remedies and response requirements for identified instances of noncompliance. Related controls: CA-3, IR-7, PS-7. ü ü SA-9a. [FedRAMP Security Controls Baseline(s) if Federal information is processed or stored within the external system] SA-9c. [Federal/FedRAMP Continuous Monitoring requirements must be met for external systems where Federal information is processed or stored] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND SERVICES ACQUISITION SA-9 (1) EXTERNAL INFORMATION SYSTEMS | RISK ASSESSMENTS / ORGANIZATIONAL APPROVALS ü The organization: (a) Conducts an organizational assessment of risk prior to the acquisition or outsourcing of dedicated information security services; and (b) Ensures that the acquisition or outsourcing of dedicated information security services is approved by [Assignment: organization-defined personnel or roles]. Supplemental Guidance: Dedicated information security services include, for example, incident monitoring, analysis and response, operation of information security-related devices such as firewalls, or key management services. Related controls: CA-6, RA-3. ü SA-9 (1) see Additional Requirement and Guidance ü Included in FedRAMP Moderate Baseline, Rev 4 SYSTEM AND SERVICES ACQUISITION SA-9 (2) EXTERNAL INFORMATION SYSTEMS | IDENTIFICATION OF FUNCTIONS / PORTS / PROTOCOLS / SERVICES ü The organization requires providers of [Assignment: organization-defined external information system services] to identify the functions, ports, protocols, and other services required for the use of such services. Supplemental Guidance: Information from external service providers regarding the specific functions, ports, protocols, and services used in the provision of such services can be particularly useful when the need arises to understand the trade-offs involved in restricting certain functions/services or blocking certain ports/protocols. Related control: CM-7. ü SA-9 (2). [All external systems where Federal information is processed or stored] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND SERVICES ACQUISITION SA-9 (4) EXTERNAL INFORMATION SYSTEMS | CONSISTENT INTERESTS OF CONSUMERS AND PROVIDERS ü The organization employs [Assignment: organization-defined security safeguards] to ensure that the interests of [Assignment: organization-defined external service providers] are consistent with and reflect organizational interests. Supplemental Guidance: As organizations increasingly use external service providers, the possibility exists that the interests of the service providers may diverge from organizational interests. In such situations, simply having the correct technical, procedural, or operational safeguards in place may not be sufficient if the service providers that implement and control those safeguards are not operating in a manner consistent with the interests of the consuming organizations. Possible actions that organizations might take to address such concerns include, for example, requiring background checks for selected service provider personnel, examining ownership records, employing only trustworthy service providers (i.e., providers with which organizations have had positive experiences), and conducting periodic/unscheduled visits to service provider facilities. ü SA-9 (4). [All external systems where Federal information is processed or stored] ü Included in FedRAMP Moderate Baseline, Rev 4 SYSTEM AND SERVICES ACQUISITION SA-9 (5) EXTERNAL INFORMATION SYSTEMS | PROCESSING, STORAGE, AND SERVICE LOCATION ü The organization restricts the location of [Selection (one or more): information processing; information/data; information system services] to [Assignment: organization-defined locations] based on [Assignment: organization-defined requirements or conditions]. Supplemental Guidance: The location of information processing, information/data storage, or information system services that are critical to organizations can have a direct impact on the ability of those organizations to successfully execute their missions/business functions. This situation exists when external providers control the location of processing, storage or services. The criteria external providers use for the selection of processing, storage, or service locations may be different from organizational criteria. For example, organizations may want to ensure that data/information storage locations are restricted to certain locations to facilitate incident response activities (e.g., forensic analyses, after-the-fact investigations) in case of information security breaches/compromises. Such incident response activities may be adversely affected by the governing laws or protocols in the locations where processing and storage occur and/or the locations from which information system services emanate. ü SA-9 (5). [information processing, information data, AND information services] ü Included in FedRAMP Moderate Baseline, Rev 4 SYSTEM AND SERVICES ACQUISITION SA-10 DEVELOPER CONFIGURATION MANAGEMENT ü The organization requires the developer of the information system, system component, or information system service to: a. Perform configuration management during system, component, or service [Selection (one or more): design; development; implementation; operation]; b. Document, manage, and control the integrity of changes to [Assignment: organization-defined configuration items under configuration management]; c. Implement only organization-approved changes to the system, component, or service; d. Document approved changes to the system, component, or service and the potential security impacts of such changes; and e. Track security flaws and flaw resolution within the system, component, or service and report findings to [Assignment: organization-defined personnel]. Supplemental Guidance: This control also applies to organizations conducting internal information systems development and integration. Organizations consider the quality and completeness of the configuration management activities conducted by developers as evidence of applying effective security safeguards. Safeguards include, for example, protecting from unauthorized modification or destruction, the master copies of all material used to generate security-relevant portions of the system hardware, software, and firmware. Maintaining the integrity of changes to the information system, information system component, or information system service requires configuration control throughout the system development life cycle to track authorized changes and prevent unauthorized changes. Configuration items that are placed under configuration management (if existence/use is required by other security controls) include: the formal model; the functional, high-level, and low-level design specifications; other design data; implementation documentation; source code and hardware schematics; the running version of the object code; tools for comparing new versions of security-relevant hardware descriptions and software/firmware source code with previous versions; and test fixtures and documentation. Depending on the mission/business needs of organizations and the nature of the contractual relationships in place, developers may provide configuration management support during the operations and maintenance phases of the life cycle. Related controls: CM-3, CM-4, CM-9, SA-12, SI-2. ü SA-10a. [development, implementation, AND operation] SA-10e. Requirement: for JAB authorizations, track security flaws and flaw resolution within the system, component, or service and report findings to organization-defined personnel, to include FedRAMP. ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND SERVICES ACQUISITION SA-10 (1) DEVELOPER CONFIGURATION MANAGEMENT | SOFTWARE / FIRMWARE INTEGRITY VERIFICATION The organization requires the developer of the information system, system component, or information system service to enable integrity verification of software and firmware components. Supplemental Guidance: This control enhancement allows organizations to detect unauthorized changes to software and firmware components through the use of tools, techniques, and/or mechanisms provided by developers. Integrity checking mechanisms can also address counterfeiting of software and firmware components. Organizations verify the integrity of software and firmware components, for example, through secure one-way hashes provided by developers. Delivered software and firmware components also include any updates to such components. Related control: SI-7. ü ü Included in FedRAMP Moderate Baseline, Rev 4 SYSTEM AND SERVICES ACQUISITION SA-11 DEVELOPER SECURITY TESTING AND EVALUATION ü The organization requires the developer of the information system, system component, or information system service to: a. Create and implement a security assessment plan; b. Perform [Selection (one or more): unit; integration; system; regression] testing/evaluation at [Assignment: organization-defined depth and coverage]; c. Produce evidence of the execution of the security assessment plan and the results of the security testing/evaluation; d. Implement a verifiable flaw remediation process; and e. Correct flaws identified during security testing/evaluation. Supplemental Guidance: Developmental security testing/evaluation occurs at all postâ€design phases of the system development life cycle. Such testing/evaluation confirms that the required security controls are implemented correctly, operating as intended, enforcing the desired security policy, and meeting established security requirements. Security properties of information systems may be affected by the interconnection of system components or changes to those components. These interconnections or changes (e.g., upgrading or replacing applications and operating systems) may adversely affect previously implemented security controls. This control provides additional types of security testing/evaluation that developers can conduct to reduce or eliminate potential flaws. Testing custom software applications may require approaches such as static analysis, dynamic analysis, binary analysis, or a hybrid of the three approaches. Developers can employ these analysis approaches in a variety of tools (e.g., web-based application scanners, static analysis tools, binary analyzers) and in source code reviews. Security assessment plans provide the specific activities that developers plan to carry out including the types of analyses, testing, evaluation, and reviews of software and firmware components, the degree of rigor to be applied, and the types of artifacts produced during those processes. The depth of security testing/evaluation refers to the rigor and level of detail associated with the assessment process (e.g., black box, gray box, or white box testing). The coverage of security testing/evaluation refers to the scope (i.e., number and type) of the artifacts included in the assessment process. Contracts specify the acceptance criteria for security assessment plans, flaw remediation processes, and the evidence that the plans/processes have been diligently applied. Methods for reviewing and protecting assessment plans, evidence, and documentation are commensurate with the security category or classification level of the information system. Contracts may specify documentation protection requirements. Related controls: CA-2, CM-4, SA-3, SA-4, SA-5, SI-2. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND SERVICES ACQUISITION SA-11 (1) DEVELOPER SECURITY TESTING AND EVALUATION | STATIC CODE ANALYSIS The organization requires the developer of the information system, system component, or information system service to employ static code analysis tools to identify common flaws and document the results of the analysis. Supplemental Guidance: Static code analysis provides a technology and methodology for security reviews. Such analysis can be used to identify security vulnerabilities and enforce security coding practices. Static code analysis is most effective when used early in the development process, when each code change can be automatically scanned for potential weaknesses. Static analysis can provide clear remediation guidance along with defects to enable developers to fix such defects. Evidence of correct implementation of static analysis can include, for example, aggregate defect density for critical defect types, evidence that defects were inspected by developers or security professionals, and evidence that defects were fixed. An excessively high density of ignored findings (commonly referred to as ignored or false positives) indicates a potential problem with the analysis process or tool. In such cases, organizations weigh the validity of the evidence against evidence from other sources. ü Requirement: SA-11 (1) or SA-11 (8) or both Requirement: The service provider documents in the Continuous Monitoring Plan, how newly developed code for the information system is reviewed. ü Included in FedRAMP Moderate Baseline, Rev 4 SYSTEM AND SERVICES ACQUISITION SA-11 (2) DEVELOPER SECURITY TESTING AND EVALUATION | THREAT AND VULNERABILITY ANALYSES The organization requires the developer of the information system, system component, or information system service to perform threat and vulnerability analyses and subsequent testing/evaluation of the as-built system, component, or service. Supplemental Guidance: Applications may deviate significantly from the functional and design specifications created during the requirements and design phases of the system development life cycle. Therefore, threat and vulnerability analyses of information systems, system components, and information system services prior to delivery are critical to the effective operation of those systems, components, and services. Threat and vulnerability analyses at this phase of the life cycle help to ensure that design or implementation changes have been accounted for, and that any new vulnerabilities created as a result of those changes have been reviewed and mitigated. Related controls: PM-15, RA-5. ü ü Included in FedRAMP Moderate Baseline, Rev 4 SYSTEM AND SERVICES ACQUISITION SA-11 (8) DEVELOPER SECURITY TESTING AND EVALUATION | DYNAMIC CODE ANALYSIS The organization requires the developer of the information system, system component, or information system service to employ dynamic code analysis tools to identify common flaws and document the results of the analysis. Supplemental Guidance: Dynamic code analysis provides run-time verification of software programs, using tools capable of monitoring programs for memory corruption, user privilege issues, and other potential security problems. Dynamic code analysis employs run-time tools to help to ensure that security functionality performs in the manner in which it was designed. A specialized type of dynamic analysis, known as fuzz testing, induces program failures by deliberately introducing malformed or random data into software programs. Fuzz testing strategies derive from the intended use of applications and the functional and design specifications for the applications. ü Requirement: SA-11 (1) or SA-11 (8) or both Requirement: The service provider documents in the Continuous Monitoring Plan, how newly developed code for the information system is reviewed. ü Included in FedRAMP Moderate Baseline, Rev 4 SYSTEM AND SERVICES ACQUISITION SA-12 SUPPLY CHAIN PROTECTION ü The organization protects against supply chain threats to the information system, system component, or information system service by employing [Assignment: organization-defined security safeguards] as part of a comprehensive, defense-in-breadth information security strategy. Supplemental Guidance: Information systems (including system components that compose those systems) need to be protected throughout the system development life cycle (i.e., during design, development, manufacturing, packaging, assembly, distribution, system integration, operations, maintenance, and retirement). Protection of organizational information systems is accomplished through threat awareness, by the identification, management, and reduction of vulnerabilities at each phase of the life cycle and the use of complementary, mutually reinforcing strategies to respond to risk. Organizations consider implementing a standardized process to address supply chain risk with respect to information systems and system components, and to educate the acquisition workforce on threats, risk, and required security controls. Organizations use the acquisition/procurement processes to require supply chain entities to implement necessary security safeguards to: (i) reduce the likelihood of unauthorized modifications at each stage in the supply chain; and (ii) protect information systems and information system components, prior to taking delivery of such systems/components. This control enhancement also applies to information system services. Security safeguards include, for example: (i) security controls for development systems, development facilities, and external connections to development systems; (ii) vetting development personnel; and (iii) use of tamper-evident packaging during shipping/warehousing. Methods for reviewing and protecting development plans, evidence, and documentation are commensurate with the security category or classification level of the information system. Contracts may specify documentation protection requirements. Related controls: AT-3, CM-8, IR- 4, PE-16, PL-8, SA-3, SA-4, SA-8, SA-10, SA-14, SA-15, SA-18, SA-19, SC-29, SC-30, SC-38, SI-7. ü Included in NIST High Baseline, Rev 4 [organization and service provider-defined personnel security requirements, approved HW/SW vendor list/process, and secure SDLC procedures] SYSTEM AND SERVICES ACQUISITION SA-15 DEVELOPMENT PROCESS, STANDARDS, AND TOOLS ü The organization: a. Requires the developer of the information system, system component, or information system service to follow a documented development process that: 1. Explicitly addresses security requirements; 2. Identifies the standards and tools used in the development process; 3. Documents the specific tool options and tool configurations used in the development process; and 4. Documents, manages, and ensures the integrity of changes to the process and/or tools used in development; and b. Reviews the development process, standards, tools, and tool options/configurations [Assignment: organization-defined frequency] to determine if the process, standards, tools, and tool options/configurations selected and employed can satisfy [Assignment: organization- defined security requirements]. Supplemental Guidance: Development tools include, for example, programming languages and computer-aided design (CAD) systems. Reviews of development processes can include, for example, the use of maturity models to determine the potential effectiveness of such processes. Maintaining the integrity of changes to tools and processes enables accurate supply chain risk assessment and mitigation, and requires robust configuration control throughout the life cycle (including design, development, transport, delivery, integration, and maintenance) to track authorized changes and prevent unauthorized changes. Related controls: SA-3, SA-8. ü Included in NIST High Baseline, Rev 4 [as needed and as dictated by the current threat posture] [organization and service provider- defined security requirements] SYSTEM AND SERVICES ACQUISITION SA-16 DEVELOPER-PROVIDED TRAINING ü The organization requires the developer of the information system, system component, or information system service to provide [Assignment: organization-defined training] on the correct use and operation of the implemented security functions, controls, and/or mechanisms. Supplemental Guidance: This control applies to external and internal (in-house) developers. Training of personnel is an essential element to ensure the effectiveness of security controls implemented within organizational information systems. Training options include, for example, classroom-style training, web-based/computer-based training, and hands-on training. Organizations can also request sufficient training materials from developers to conduct in-house training or offer self- training to organizational personnel. Organizations determine the type of training necessary and may require different types of training for different security functions, controls, or mechanisms. Related controls: AT-2, AT-3, SA-5. References: None. ü Included in NIST High Baseline, Rev 4 [annually and on an "as-needed" basis] SYSTEM AND SERVICES ACQUISITION SA-17 DEVELOPER SECURITY ARCHITECTURE AND DESIGN The organization requires the developer of the information system, system component, or information system service to produce a design specification and security architecture that: a. Is consistent with and supportive of the organization’s security architecture which is established within and is an integrated part of the organization’s enterprise architecture; b. Accurately and completely describes the required security functionality, and the allocation of security controls among physical and logical components; and c. Expresses how individual security functions, mechanisms, and services work together to provide required security capabilities and a unified approach to protection. Supplemental Guidance: This control is primarily directed at external developers, although it could also be used for internal (in-house) development. In contrast, PL-8 is primarily directed at internal developers to help ensure that organizations develop an information security architecture and such security architecture is integrated or tightly coupled to the enterprise architecture. This distinction is important if/when organizations outsource the development of information systems, information system components, or information system services to external entities, and there is a requirement to demonstrate consistency with the organization’s enterprise architecture and information security architecture. Related controls: PL-8, PM-7, SA-3, SA-8. ü Included in NIST High Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-1 SYSTEM AND COMMUNICATIONS PROTECTION POLICY AND PROCEDURES ü The organization: a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]: 1. A system and communications protection policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and 2. Procedures to facilitate the implementation of the system and communications protection policy and associated system and communications protection controls; and b. Reviews and updates the current: 1. System and communications protection policy [Assignment: organization-defined frequency]; and 2. System and communications protection procedures [Assignment: organization-defined frequency]. Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the SC family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9. Control Enhancements: None. References: NIST Special Publications 800-12, 800-100. ü ü SC-1.b.1 [at least every 3 years] SC-1.b.2 [at least annually] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SC-1.b.1 [at least annually] SC-1.b.2 [at least every six months] SYSTEM AND COMMUNICATIONS PROTECTION SC-2 APPLICATION PARTITIONING The information system separates user functionality (including user interface services) from information system management functionality. Supplemental Guidance: Information system management functionality includes, for example, functions necessary to administer databases, network components, workstations, or servers, and typically requires privileged user access. The separation of user functionality from information system management functionality is either physical or logical. Organizations implement separation of system management-related functionality from user functionality by using different computers, different central processing units, different instances of operating systems, different network addresses, virtualization techniques, or combinations of these or other methods, as appropriate. This type of separation includes, for example, web administrative interfaces that use separate authentication methods for users of any other information system resources. Separation of system and user functionality may include isolating administrative interfaces on different domains and with additional access controls. Related controls: SA-4, SA-8, SC-3. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-3 SECURITY FUNCTION ISOLATION The information system isolates security functions from nonsecurity functions. Supplemental Guidance: The information system isolates security functions from nonsecurity functions by means of an isolation boundary (implemented via partitions and domains). Such isolation controls access to and protects the integrity of the hardware, software, and firmware that perform those security functions. Information systems implement code separation (i.e., separation of security functions from nonsecurity functions) in a number of ways, including, for example, through the provision of security kernels via processor rings or processor modes. For non-kernel code, security function isolation is often achieved through file system protections that serve to protect the code on disk, and address space protections that protect executing code. Information systems restrict access to security functions through the use of access control mechanisms and by implementing least privilege capabilities. While the ideal is for all of the code within the security function isolation boundary to only contain security-relevant code, it is sometimes necessary to include nonsecurity functions within the isolation boundary as an exception. Related controls: AC- 3, AC-6, SA-4, SA-5, SA-8, SA-13, SC-2, SC-7, SC-39. ü Included in NIST High Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-4 INFORMATION IN SHARED RESOURCES The information system prevents unauthorized and unintended information transfer via shared system resources. Supplemental Guidance: This control prevents information, including encrypted representations of information, produced by the actions of prior users/roles (or the actions of processes acting on behalf of prior users/roles) from being available to any current users/roles (or current processes) that obtain access to shared system resources (e.g., registers, main memory, hard disks) after those resources have been released back to information systems. The control of information in shared resources is also commonly referred to as object reuse and residual information protection. This control does not address: (i) information remanence which refers to residual representation of data that has been nominally erased or removed; (ii) covert channels (including storage and/or timing channels) where shared resources are manipulated to violate information flow restrictions; or (iii) components within information systems for which there are only single users/roles. Related controls: AC-3, AC-4, MP-6. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-5 DENIAL OF SERVICE PROTECTION ü The information system protects against or limits the effects of the following types of denial of service attacks: [Assignment: organization-defined types of denial of service attacks or reference to source for such information] by employing [Assignment: organization-defined security safeguards]. Supplemental Guidance: A variety of technologies exist to limit, or in some cases, eliminate the effects of denial of service attacks. For example, boundary protection devices can filter certain types of packets to protect information system components on internal organizational networks from being directly affected by denial of service attacks. Employing increased capacity and bandwidth combined with service redundancy may also reduce the susceptibility to denial of service attacks. Related controls: SC-6, SC-7. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-6 RESOURCE AVAILABILITY ü The information system protects the availability of resources by allocating [Assignment: organization-defined resources] by [Selection (one or more); priority; quota; [Assignment: organization-defined security safeguards]]. Supplemental Guidance: Priority protection helps prevent lower-priority processes from delaying or interfering with the information system servicing any higher-priority processes. Quotas prevent users or processes from obtaining more than predetermined amounts of resources. This control does not apply to information system components for which there are only single users/roles. Control Enhancements: None. References: None. ü ü Included in FedRAMP Moderate Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-7 BOUNDARY PROTECTION ü The information system: a. Monitors and controls communications at the external boundary of the system and at key internal boundaries within the system; b. Implements subnetworks for publicly accessible system components that are [Selection: physically; logically] separated from internal organizational networks; and c. Connects to external networks or information systems only through managed interfaces consisting of boundary protection devices arranged in accordance with an organizational security architecture. Supplemental Guidance: Managed interfaces include, for example, gateways, routers, firewalls, guards, network-based malicious code analysis and virtualization systems, or encrypted tunnels implemented within a security architecture (e.g., routers protecting firewalls or application gateways residing on protected subnetworks). Subnetworks that are physically or logically separated from internal networks are referred to as demilitarized zones or DMZs. Restricting or prohibiting interfaces within organizational information systems includes, for example, restricting external web traffic to designated web servers within managed interfaces and prohibiting external traffic that appears to be spoofing internal addresses. Organizations consider the shared nature of commercial telecommunications services in the implementation of security controls associated with the use of such services. Commercial telecommunications services are commonly based on network components and consolidated management systems shared by all attached commercial customers, and may also include third party-provided access lines and other service elements. Such transmission services may represent sources of increased risk despite contract security provisions. Related controls: AC-4, AC-17, CA-3, CM-7, CP-8, IR-4, RA-3, SC-5, SC-13. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-7 (3) BOUNDARY PROTECTION | ACCESS POINTS The organization limits the number of external network connections to the information system. Supplemental Guidance: Limiting the number of external network connections facilitates more comprehensive monitoring of inbound and outbound communications traffic. The Trusted Internet Connection (TIC) initiative is an example of limiting the number of external network connections. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-7 (4) BOUNDARY PROTECTION | EXTERNAL TELECOMMUNICATIONS SERVICES ü The organization: (a) Implements a managed interface for each external telecommunication service; (b) Establishes a traffic flow policy for each managed interface; (c) Protects the confidentiality and integrity of the information being transmitted across each interface; (d) Documents each exception to the traffic flow policy with a supporting mission/business need and duration of that need; and (e) Reviews exceptions to the traffic flow policy [Assignment: organization-defined frequency] and removes exceptions that are no longer supported by an explicit mission/business need. Supplemental Guidance: Related control: SC-8. ü SC-7 (4). [at least annually] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SC-7 (4)e. [at least every 180 days or whenever there is a change in the threat environment that warrants a review of the exceptions] SYSTEM AND COMMUNICATIONS PROTECTION SC-7 (5) BOUNDARY PROTECTION | DENY BY DEFAULT / ALLOW BY EXCEPTION The information system at managed interfaces denies network communications traffic by default and allows network communications traffic by exception (i.e., deny all, permit by exception). Supplemental Guidance: This control enhancement applies to both inbound and outbound network communications traffic. A deny-all, permit-by-exception network communications traffic policy ensures that only those connections which are essential and approved are allowed. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-7 (7) BOUNDARY PROTECTION | PREVENT SPLIT TUNNELING FOR REMOTE DEVICES The information system, in conjunction with a remote device, prevents the device from simultaneously establishing non-remote connections with the system and communicating via some other connection to resources in external networks. Supplemental Guidance: This control enhancement is implemented within remote devices (e.g., notebook computers) through configuration settings to disable split tunneling in those devices, and by preventing those configuration settings from being readily configurable by users. This control enhancement is implemented within the information system by the detection of split tunneling (or of configuration settings that allow split tunneling) in the remote device, and by prohibiting the connection if the remote device is using split tunneling. Split tunneling might be desirable by remote users to communicate with local information system resources such as printers/file servers. However, split tunneling would in effect allow unauthorized external connections, making the system more vulnerable to attack and to exfiltration of organizational information. The use of VPNs for remote connections, when adequately provisioned with appropriate security controls, may provide the organization with sufficient assurance that it can effectively treat such connections as non-remote connections from the confidentiality and integrity perspective. VPNs thus provide a means for allowing non-remote communications paths from remote devices. The use of an adequately provisioned VPN does not eliminate the need for preventing split tunneling. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-7 (8) BOUNDARY PROTECTION | ROUTE TRAFFIC TO AUTHENTICATED PROXY SERVERS ü The information system routes [Assignment: organization-defined internal communications traffic] to [Assignment: organization-defined external networks] through authenticated proxy servers at managed interfaces. Supplemental Guidance: External networks are networks outside of organizational control. A proxy server is a server (i.e., information system or application) that acts as an intermediary for clients requesting information system resources (e.g., files, connections, web pages, or services) from other organizational servers. Client requests established through an initial connection to the proxy server are evaluated to manage complexity and to provide additional protection by limiting direct connectivity. Web content filtering devices are one of the most common proxy servers providing access to the Internet. Proxy servers support logging individual Transmission Control Protocol (TCP) sessions and blocking specific Uniform Resource Locators (URLs), domain names, and Internet Protocol (IP) addresses. Web proxies can be configured with organization-defined lists of authorized and unauthorized websites. Related controls: AC-3, AU-2. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-7 (10) BOUNDARY PROTECTION | PREVENT UNAUTHORIZED EXFILTRATION The organization prevents the unauthorized exfiltration of information across managed interfaces. Supplemental Guidance: Safeguards implemented by organizations to prevent unauthorized exfiltration of information from information systems include, for example: (i) strict adherence to protocol formats; (ii) monitoring for beaconing from information systems; (iii) monitoring for steganography; (iv) disconnecting external network interfaces except when explicitly needed; (v) disassembling and reassembling packet headers; and (vi) employing traffic profile analysis to detect deviations from the volume/types of traffic expected within organizations or call backs to command and control centers. Devices enforcing strict adherence to protocol formats include, for example, deep packet inspection firewalls and XML gateways. These devices verify adherence to protocol formats and specification at the application layer and serve to identify vulnerabilities that cannot be detected by devices operating at the network or transport layers. This control enhancement is closely associated with cross-domain solutions and system guards enforcing information flow requirements. Related control: SI-3. ü NEED. High-impact systems warrant careful attention to scenarios associated with exfiltration of sensitive organizational information. Different systems and implementation will trigger different scenarios, but regardless of the specific system context, organizations are warranted in establishing this control for high-impact systems with subsystems deployed into shared-service environments. ANALYSIS. Organizations should devote careful attention to design considerations relative to this control. Simpler designs will allow the use of COTS tools that will lower implementation time and costs. More sensitive and complex environments will drive those costs higher. SAMPLE THREAT VECTORS. Authorized processes push very large volumes of data to external networks. Internal devices send address/status/security information to external networks. Relevant security-control attributes: Integrity-Assured, Absorptive, Survivable, Adaptive, Agile, Auditable, Monitored, Controlled, Data Controllable, Access-Controlled SYSTEM AND COMMUNICATIONS PROTECTION SC-7 (12) BOUNDARY PROTECTION | HOST-BASED PROTECTION ü The organization implements [Assignment: organization-defined host-based boundary protection mechanisms] at [Assignment: organization-defined information system components]. Supplemental Guidance: Host-based boundary protection mechanisms include, for example, host-based firewalls. Information system components employing host-based boundary protection mechanisms include, for example, servers, workstations, and mobile devices. ü ü Included in FedRAMP Moderate Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-7 (13) BOUNDARY PROTECTION | ISOLATION OF SECURITY TOOLS / MECHANISMS / SUPPORT COMPONENTS ü The organization isolates [Assignment: organization-defined information security tools, mechanisms, and support components] from other internal information system components by implementing physically separate subnetworks with managed interfaces to other components of the system. Supplemental Guidance: Physically separate subnetworks with managed interfaces are useful, for example, in isolating computer network defenses from critical operational processing networks to prevent adversaries from discovering the analysis and forensics techniques of organizations. Related controls: SA-8, SC-2, SC-3. ü SC-7 (13). Requirement: The service provider defines key information security tools, mechanisms, and support components associated with system and security administration and isolates those tools, mechanisms, and support components from other internal information system components via physically or logically separate subnets. ü Included in FedRAMP Moderate Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-7 (18) BOUNDARY PROTECTION | FAIL SECURE The information system fails securely in the event of an operational failure of a boundary protection device. Supplemental Guidance: Fail secure is a condition achieved by employing information system mechanisms to ensure that in the event of operational failures of boundary protection devices at managed interfaces (e.g., routers, firewalls, guards, and application gateways residing on protected subnetworks commonly referred to as demilitarized zones), information systems do not enter into unsecure states where intended security properties no longer hold. Failures of boundary protection devices cannot lead to, or cause information external to the devices to enter the devices, nor can failures permit unauthorized information releases. Related controls: CP-2, SC-24. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-7 (20) BOUNDARY PROTECTION | DYNAMIC ISOLATION / SEGREGATION ü The information system provides the capability to dynamically isolate/segregate [Assignment: organization-defined information system components] from other components of the system. Supplemental Guidance: The capability to dynamically isolate or segregate certain internal components of organizational information systems is useful when it is necessary to partition or separate certain components of dubious origin from those components possessing greater trustworthiness. Component isolation reduces the attack surface of organizational information systems. Isolation of selected information system components is also a means of limiting the damage from successful cyber attacks when those attacks occur. ü NEED. High-impact systems warrant careful attention to situations where specific sources or methods become suspect. Such situations can involve specific user accounts, messages, message payloads, data, applications, or even entire subsystems. Under these circumstances, a capability for dynamic segregation is highly justified. ANALYSIS. Isolation techniques are well understood in the cyber market, and constantly evolving. Example techniques include honey pots and honey nets. Both techniques can isolate a user, an autonomous application, or an entire subsystem. By doing so, honey pots/honey nets allow analysis to continue as the suspected user/component continues activity in controlled and observed conditions where the organization’s data and systems are not directly exposed. SAMPLE THREAT VECTORS. Anomalous user behavior is detected Messages arrive from suspect domains. Messages arrive with suspect attachments. Applications begin to behave anomalously. Subsystems begin moving data anomalously. RELEVANT SECURITY CONTROL ATTRIBUTES. Integrity-Assured, Absorptive, Survivable, Adaptive, Agile, Auditable, Monitored, Controlled, Data Controllable, Access-Controlled [organization and service provider-defined information system components] SYSTEM AND COMMUNICATIONS PROTECTION SC-7 (21) BOUNDARY PROTECTION | ISOLATION OF INFORMATION SYSTEM COMPONENTS ü The organization employs boundary protection mechanisms to separate [Assignment: organization-defined information system components] supporting [Assignment: organization- defined missions and/or business functions]. Supplemental Guidance: Organizations can isolate information system components performing different missions and/or business functions. Such isolation limits unauthorized information flows among system components and also provides the opportunity to deploy greater levels of protection for selected components. Separating system components with boundary protection mechanisms provides the capability for increased protection of individual components and to more effectively control information flows between those components. This type of enhanced protection limits the potential harm from cyber attacks and errors. The degree of separation provided varies depending upon the mechanisms chosen. Boundary protection mechanisms include, for example, routers, gateways, and firewalls separating system components into physically separate networks or subnetworks, cross-domain devices separating subnetworks, virtualization techniques, and encrypting information flows among system components using distinct encryption keys. Related controls: CA-9, SC-3. ü Included in NIST High Baseline, Rev 4 [organization and service provider-defined information system components] [organization-defined mission and/or business functions] SYSTEM AND COMMUNICATIONS PROTECTION SC-8 TRANSMISSION CONFIDENTIALITY AND INTEGRITY ü The information system protects the [Selection (one or more): confidentiality; integrity] of transmitted information. Supplemental Guidance: This control applies to both internal and external networks and all types of information system components from which information can be transmitted (e.g., servers, mobile devices, notebook computers, printers, copiers, scanners, facsimile machines). Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and/or integrity of organizational information can be accomplished by physical means (e.g., by employing physical distribution systems) or by logical means (e.g., employing encryption techniques). Organizations relying on commercial providers offering transmission services as commodity services rather than as fully dedicated services (i.e., services which can be highly specialized to individual customer needs), may find it difficult to obtain the necessary assurances regarding the implementation of needed security controls for transmission confidentiality/integrity. In such situations, organizations determine what types of confidentiality/integrity services are available in standard, commercial telecommunication service packages. If it is infeasible or impractical to obtain the necessary security controls and assurances of control effectiveness through appropriate contracting vehicles, organizations implement appropriate compensating security controls or explicitly accept the additional risk. Related controls: AC-17, PE-4. ü SC-8. [confidentiality AND integrity] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-8 (1) TRANSMISSION CONFIDENTIALITY AND INTEGRITY | CRYPTOGRAPHIC OR ALTERNATE PHYSICAL PROTECTION ü The information system implements cryptographic mechanisms to [Selection (one or more): prevent unauthorized disclosure of information; detect changes to information] during transmission unless otherwise protected by [Assignment: organization-defined alternative physical safeguards]. Supplemental Guidance: Encrypting information for transmission protects information from unauthorized disclosure and modification. Cryptographic mechanisms implemented to protect information integrity include, for example, cryptographic hash functions which have common application in digital signatures, checksums, and message authentication codes. Alternative physical security safeguards include, for example, protected distribution systems. Related control: SC-13. ü SC-8 (1). [prevent unauthorized disclosure of information AND detect changes to information] [a hardened or alarmed carrier Protective Distribution System (PDS)] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-10 NETWORK DISCONNECT ü The information system terminates the network connection associated with a communications session at the end of the session or after [Assignment: organization-defined time period] of inactivity. Supplemental Guidance: This control applies to both internal and external networks. Terminating network connections associated with communications sessions include, for example, de-allocating associated TCP/IP address/port pairs at the operating system level, or de-allocating networking assignments at the application level if multiple application sessions are using a single, operating system-level network connection. Time periods of inactivity may be established by organizations and include, for example, time periods by type of network access or for specific network accesses. Control Enhancements: None. References: None. ü SC-10. [no longer than 30 minutes for RAS-based sessions or no longer than 60 minutes for non-interactive user sessions] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 [no longer than 10 minutes in-band management and no longer than 15 minutes for user sessions] SYSTEM AND COMMUNICATIONS PROTECTION SC-12 CRYPTOGRAPHIC KEY ESTABLISHMENT AND MANAGEMENT ü The organization establishes and manages cryptographic keys for required cryptography employed within the information system in accordance with [Assignment: organization-defined requirements for key generation, distribution, storage, access, and destruction]. Supplemental Guidance: Cryptographic key management and establishment can be performed using manual procedures or automated mechanisms with supporting manual procedures. Organizations define key management requirements in accordance with applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance, specifying appropriate options, levels, and parameters. Organizations manage trust stores to ensure that only approved trust anchors are in such trust stores. This includes certificates with visibility external to organizational information systems and certificates related to the internal operations of systems. Related controls: SC-13, SC-17. ü ü SC-12 Guidance: Federally approved cryptography ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-12 (1) CRYPTOGRAPHIC KEY ESTABLISHMENT AND MANAGEMENT | AVAILABILITY The organization maintains availability of information in the event of the loss of cryptographic keys by users. Supplemental Guidance: Escrowing of encryption keys is a common practice for ensuring availability in the event of loss of keys (e.g., due to forgotten passphrase). ü Included in NIST High Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-12 (2) CRYPTOGRAPHIC KEY ESTABLISHMENT AND MANAGEMENT | SYMMETRIC KEYS ü The organization produces, controls, and distributes symmetric cryptographic keys using [Selection: NIST FIPS-compliant; NSA-approved] key management technology and processes. ü SC-12 (2). [NIST FIPS-compliant] ü Included in FedRAMP Moderate Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-12 (3) CRYPTOGRAPHIC KEY ESTABLISHMENT AND MANAGEMENT | ASYMMETRIC KEYS ü The organization produces, controls, and distributes asymmetric cryptographic keys using [Selection: NSA-approved key management technology and processes; approved PKI Class 3 certificates or prepositioned keying material; approved PKI Class 3 or Class 4 certificates and hardware security tokens that protect the user’s private key]. ü ü Included in FedRAMP Moderate Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-13 CRYPTOGRAPHIC PROTECTION ü The information system implements [Assignment: organization-defined cryptographic uses and type of cryptography required for each use] in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. Supplemental Guidance: Cryptography can be employed to support a variety of security solutions including, for example, the protection of classified and Controlled Unclassified Information, the provision of digital signatures, and the enforcement of information separation when authorized individuals have the necessary clearances for such information but lack the necessary formal access approvals. Cryptography can also be used to support random number generation and hash generation. Generally applicable cryptographic standards include FIPS-validated cryptography and NSA-approved cryptography. This control does not impose any requirements on organizations to use cryptography. However, if cryptography is required based on the selection of other security controls, organizations define each type of cryptographic use and the type of cryptography required (e.g., protection of classified information: NSA-approved cryptography; provision of digital signatures: FIPS-validated cryptography). Related controls: AC-2, AC-3, AC-7, AC-17, AC-18, AU-9, AU-10, CM-11, CP-9, IA-3, IA-7, MA-4, MP-2, MP-4, MP-5, SA-4, SC-8, SC-12, SC-28, SI-7. ü ü [FIPS-validated or NSA-approved cryptography] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-15 COLLABORATIVE COMPUTING DEVICES ü The information system: a. Prohibits remote activation of collaborative computing devices with the following exceptions: [Assignment: organization-defined exceptions where remote activation is to be allowed]; and b. Provides an explicit indication of use to users physically present at the devices. Supplemental Guidance: Collaborative computing devices include, for example, networked white boards, cameras, and microphones. Explicit indication of use includes, for example, signals to users when collaborative computing devices are activated. Related control: AC-21. ü ü SC-15a. [no exceptions] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-17 PUBLIC KEY INFRASTRUCTURE CERTIFICATES ü The organization issues public key certificates under an [Assignment: organization- defined certificate policy] or obtains public key certificates from an approved service provider. Supplemental Guidance: For all certificates, organizations manage information system trust stores to ensure only approved trust anchors are in the trust stores. This control addresses both certificates with visibility external to organizational information systems and certificates related to the internal operations of systems, for example, application-specific time services. Related control: SC-12. Control Enhancements: None. References: OMB Memorandum 05-24; NIST Special Publications 800-32, 800-63. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-18 MOBILE CODE The organization: a. Defines acceptable and unacceptable mobile code and mobile code technologies; b. Establishes usage restrictions and implementation guidance for acceptable mobile code and mobile code technologies; and c. Authorizes, monitors, and controls the use of mobile code within the information system. Supplemental Guidance: Decisions regarding the employment of mobile code within organizational information systems are based on the potential for the code to cause damage to the systems if used maliciously. Mobile code technologies include, for example, Java, JavaScript, ActiveX, Postscript, PDF, Shockwave movies, Flash animations, and VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on servers and mobile code downloaded and executed on individual workstations and devices (e.g., smart phones). Mobile code policy and procedures address preventing the development, acquisition, or introduction of unacceptable mobile code within organizational information systems. Related controls: AU-2, AU-12, CM-2, CM-6, SI-3. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-19 VOICE OVER INTERNET PROTOCOL The organization: a. Establishes usage restrictions and implementation guidance for Voice over Internet Protocol (VoIP) technologies based on the potential to cause damage to the information system if used maliciously; and b. Authorizes, monitors, and controls the use of VoIP within the information system. Supplemental Guidance: Related controls: CM-6, SC-7, SC-15. References: NIST Special Publication 800-58. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-20 SECURE NAME /ADDRESS RESOLUTION SERVICE (AUTHORITATIVE SOURCE) The information system: a. Provides additional data origin and integrity artifacts along with the authoritative name resolution data the system returns in response to external name/address resolution queries; and b. Provides the means to indicate the security status of child zones and (if the child supports secure resolution services) to enable verification of a chain of trust among parent and child domains, when operating as part of a distributed, hierarchical namespace. Supplemental Guidance: This control enables external clients including, for example, remote Internet clients, to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service. Information systems that provide name and address resolution services include, for example, domain name system (DNS) servers. Additional artifacts include, for example, DNS Security (DNSSEC) digital signatures and cryptographic keys. DNS resource records are examples of authoritative data. The means to indicate the security status of child zones includes, for example, the use of delegation signer resource records in the DNS. The DNS security controls reflect (and are referenced from) OMB Memorandum 08-23. Information systems that use technologies other than the DNS to map between host/service names and network addresses provide other means to assure the authenticity and integrity of response data. Related controls: AU-10, SC-8, SC-12, SC- 13, SC-21, SC-22. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-21 SECURE NAME /ADDRESS RESOLUTION SERVICE (RECURSIVE OR CACHING RESOLVER) The information system requests and performs data origin authentication and data integrity verification on the name/address resolution responses the system receives from authoritative sources. Supplemental Guidance: Each client of name resolution services either performs this validation on its own, or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include, for example, recursive resolving or caching domain name system (DNS) servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations. Information systems that use technologies other than the DNS to map between host/service names and network addresses provide other means to enable clients to verify the authenticity and integrity of response data. Related controls: SC-20, SC-22. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-22 ARCHITECTURE AND PROVISIONING FOR NAME/ADDRESS RESOLUTION SERVICE The information systems that collectively provide name/address resolution service for an organization are fault-tolerant and implement internal/external role separation. Supplemental Guidance: Information systems that provide name and address resolution services include, for example, domain name system (DNS) servers. To eliminate single points of failure and to enhance redundancy, organizations employ at least two authoritative domain name system servers, one configured as the primary server and the other configured as the secondary server. Additionally, organizations typically deploy the servers in two geographically separated network subnetworks (i.e., not located in the same physical facility). For role separation, DNS servers with internal roles only process name and address resolution requests from within organizations (i.e., from internal clients). DNS servers with external roles only process name and address resolution information requests from clients external to organizations (i.e., on external networks including the Internet). Organizations specify clients that can access authoritative DNS servers in particular roles (e.g., by address ranges, explicit lists). Related controls: SC-2, SC-20, SC-21, SC-24. Control Enhancements: None. References: NIST Special Publication 800-81. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-23 SESSION AUTHENTICITY The information system protects the authenticity of communications sessions. Supplemental Guidance: This control addresses communications protection at the session, versus packet level (e.g., sessions in service-oriented architectures providing web-based services) and establishes grounds for confidence at both ends of communications sessions in ongoing identities of other parties and in the validity of information transmitted. Authenticity protection includes, for example, protecting against man-in-the-middle attacks/session hijacking and the insertion of false information into sessions. Related controls: SC-8, SC-10, SC-11. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-24 FAIL IN KNOWN STATE ü The information system fails to a [Assignment: organization-defined known-state] for [Assignment: organization-defined types of failures] preserving [Assignment: organization-defined system state information] in failure. Supplemental Guidance: Failure in a known state addresses security concerns in accordance with the mission/business needs of organizations. Failure in a known secure state helps to prevent the loss of confidentiality, integrity, or availability of information in the event of failures of organizational information systems or system components. Failure in a known safe state helps to prevent systems from failing to a state that may cause injury to individuals or destruction to property. Preserving information system state information facilitates system restart and return to the operational mode of organizations with less disruption of mission/business processes. Related controls: CP-2, CP- 10, CP-12, SC-7, SC-22. Control Enhancements: None. References: None. ü Included in NIST High Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-28 PROTECTION OF INFORMATION AT REST ü The information system protects the [Selection (one or more): confidentiality; integrity] of [Assignment: organization-defined information at rest]. Supplemental Guidance: This control addresses the confidentiality and integrity of information at rest and covers user information and system information. Information at rest refers to the state of information when it is located on storage devices as specific components of information systems. System-related information requiring protection includes, for example, configurations or rule sets for firewalls, gateways, intrusion detection/prevention systems, filtering routers, and authenticator content. Organizations may employ different mechanisms to achieve confidentiality and integrity protections, including the use of cryptographic mechanisms and file share scanning. Integrity protection can be achieved, for example, by implementing Write-Once-Read-Many (WORM) technologies. Organizations may also employ other security controls including, for example, secure off-line storage in lieu of online storage when adequate protection of information at rest cannot otherwise be achieved and/or continuous monitoring to identify malicious code at rest. Related controls: AC-3, AC-6, CA-7, CM-3, CM-5, CM-6, PE-3, SC-8, SC-13, SI-3, SI-7. ü SC-28. [confidentiality AND integrity] SC-28. Guidance: The organization supports the capability to use cryptographic mechanisms to protect information at rest. ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-28 (1) PROTECTION OF INFORMATION AT REST | CRYPTOGRAPHIC PROTECTION ü The information system implements cryptographic mechanisms to prevent unauthorized disclosure and modification of [Assignment: organization-defined information] on [Assignment: organization-defined information system components]. Supplemental Guidance: Selection of cryptographic mechanisms is based on the need to protect the confidentiality and integrity of organizational information. The strength of mechanism is commensurate with the security category and/or classification of the information. This control enhancement applies to significant concentrations of digital media in organizational areas designated for media storage and also to limited quantities of media generally associated with information system components in operational environments (e.g., portable storage devices, mobile devices). Organizations have the flexibility to either encrypt all information on storage devices (i.e., full disk encryption) or encrypt specific data structures (e.g., files, records, or fields). Organizations employing cryptographic mechanisms to protect information at rest also consider cryptographic key management solutions. Related controls: AC-19, SC-12. ü ü Included in FedRAMP Moderate Baseline, Rev 4 SYSTEM AND COMMUNICATIONS PROTECTION SC-39 PROCESS ISOLATION The information system maintains a separate execution domain for each executing process. Supplemental Guidance: Information systems can maintain separate execution domains for each executing process by assigning each process a separate address space. Each information system process has a distinct address space so that communication between processes is performed in a manner controlled through the security functions, and one process cannot modify the executing code of another process. Maintaining separate execution domains for executing processes can be achieved, for example, by implementing separate address spaces. This capability is available in most commercial operating systems that employ multi-state processor technologies. Related controls: AC-3, AC-4, AC-6, SA-4, SA-5, SA-8, SC-2, SC-3. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND INFORMATION INTEGRITY SI-1 SYSTEM AND INFORMATION INTEGRITY POLICY AND PROCEDURES ü The organization: a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]: 1. A system and information integrity policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and 2. Procedures to facilitate the implementation of the system and information integrity policy and associated system and information integrity controls; and b. Reviews and updates the current: 1. System and information integrity policy [Assignment: organization-defined frequency]; and 2. System and information integrity procedures [Assignment: organization-defined frequency]. Supplemental Guidance: This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the SI family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9. Control Enhancements: None. References: NIST Special Publications 800-12, 800-100. ü ü SI-1.b.1 [at least every 3 years] SI-1.b.2 [at least annually] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SI-1.b.1 [at least annually] SI-1.b.2 [at least every six months] SYSTEM AND INFORMATION INTEGRITY SI-2 FLAW REMEDIATION ü The organization: a. Identifies, reports, and corrects information system flaws; b. Tests software and firmware updates related to flaw remediation for effectiveness and potential side effects before installation; c. Installs security-relevant software and firmware updates within [Assignment: organization- defined time period] of the release of the updates; and d. Incorporates flaw remediation into the organizational configuration management process. Supplemental Guidance: Organizations identify information systems affected by announced software flaws including potential vulnerabilities resulting from those flaws, and report this information to designated organizational personnel with information security responsibilities. Security-relevant software updates include, for example, patches, service packs, hot fixes, and anti-virus signatures. Organizations also address flaws discovered during security assessments, continuous monitoring, incident response activities, and system error handling. Organizations take advantage of available resources such as the Common Weakness Enumeration (CWE) or Common Vulnerabilities and Exposures (CVE) databases in remediating flaws discovered in organizational information systems. By incorporating flaw remediation into ongoing configuration management processes, required/anticipated remediation actions can be tracked and verified. Flaw remediation actions that can be tracked and verified include, for example, determining whether organizations follow US-CERT guidance and Information Assurance Vulnerability Alerts. Organization-defined time periods for updating security-relevant software and firmware may vary based on a variety of factors including, for example, the security category of the information system or the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw). Some types of flaw remediation may require more testing than other types. Organizations determine the degree and type of testing needed for the specific type of flaw remediation activity under consideration and also the types of changes that are to be configuration-managed. In some situations, organizations may determine that the testing of software and/or firmware updates is not necessary or practical, for example, when implementing simple anti-virus signature updates. Organizations may also consider in testing decisions, whether security-relevant software or firmware updates are obtained from authorized sources with appropriate digital signatures. Related controls: CA-2, CA-7, CM-3, CM-5, CM-8, MA-2, IR-4, RA-5, SA-10, SA-11, SI-11. ü ü SI-2c. [Within 30 days of release of updates] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND INFORMATION INTEGRITY SI-2 (1) FLAW REMEDIATION | CENTRAL MANAGEMENT The organization centrally manages the flaw remediation process. Supplemental Guidance: Central management is the organization-wide management and implementation of flaw remediation processes. Central management includes planning, implementing, assessing, authorizing, and monitoring the organization-defined, centrally managed flaw remediation security controls. ü Included in NIST High Baseline, Rev 4 SYSTEM AND INFORMATION INTEGRITY SI-2 (2) FLAW REMEDIATION | AUTOMATED FLAW REMEDIATION STATUS ü The organization employs automated mechanisms [Assignment: organization-defined frequency] to determine the state of information system components with regard to flaw remediation. Supplemental Guidance: Related controls: CM-6, SI-4. ü SI-2 (2). [at least monthly] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND INFORMATION INTEGRITY SI-2 (3) FLAW REMEDIATION | TIME TO REMEDIATE FLAWS / BENCHMARKS FOR CORRECTIVE ACTIONS ü The organization: (a) Measures the time between flaw identification and flaw remediation; and (b) Establishes [Assignment: organization-defined benchmarks] for taking corrective actions. Supplemental Guidance: This control enhancement requires organizations to determine the current time it takes on the average to correct information system flaws after such flaws have been identified, and subsequently establish organizational benchmarks (i.e., time frames) for taking corrective actions. Benchmarks can be established by type of flaw and/or severity of the potential vulnerability if the flaw can be exploited. ü ü Included in FedRAMP Moderate Baseline, Rev 4 SYSTEM AND INFORMATION INTEGRITY SI-3 MALICIOUS CODE PROTECTION ü The organization: a. Employs malicious code protection mechanisms at information system entry and exit points to detect and eradicate malicious code; b. Updates malicious code protection mechanisms whenever new releases are available in accordance with organizational configuration management policy and procedures; c. Configures malicious code protection mechanisms to: 1. Perform periodic scans of the information system [Assignment: organization-defined frequency] and real-time scans of files from external sources at [Selection (one or more); endpoint; network entry/exit points] as the files are downloaded, opened, or executed in accordance with organizational security policy; and 2. [Selection (one or more): block malicious code; quarantine malicious code; send alert to administrator; [Assignment: organization-defined action]] in response to malicious code detection; and d. Addresses the receipt of false positives during malicious code detection and eradication and the resulting potential impact on the availability of the information system. Supplemental Guidance: Information system entry and exit points include, for example, firewalls, electronic mail servers, web servers, proxy servers, remote-access servers, workstations, notebook computers, and mobile devices. Malicious code includes, for example, viruses, worms, Trojan horses, and spyware. Malicious code can also be encoded in various formats (e.g., UUENCODE, Unicode), contained within compressed or hidden files, or hidden in files using steganography. Malicious code can be transported by different means including, for example, web accesses, electronic mail, electronic mail attachments, and portable storage devices. Malicious code insertions occur through the exploitation of information system vulnerabilities. Malicious code protection mechanisms include, for example, anti-virus signature definitions and reputation-based technologies. A variety of technologies and methods exist to limit or eliminate the effects of malicious code. Pervasive configuration management and comprehensive software integrity controls may be effective in preventing execution of unauthorized code. In addition to commercial off-the-shelf software, malicious code may also be present in custom-built software. This could include, for example, logic bombs, back doors, and other types of cyber attacks that could affect organizational missions/business functions. Traditional malicious code protection mechanisms cannot always detect such code. In these situations, organizations rely instead on other safeguards including, for example, secure coding practices, configuration management and control, trusted procurement processes, and monitoring practices to help ensure that software does not perform functions other than the functions intended. Organizations may determine that in response to the detection of malicious code, different actions may be warranted. For example, organizations can define actions in response to malicious code detection during periodic scans, actions in response to detection of malicious downloads, and/or actions in response to detection of maliciousness when attempting to open or execute files. Related controls: CM-3, MP-2, SA-4, SA-8, SA-12, SA-13, SC-7, SC-26, SC-44, SI-2, SI-4, SI-7. ü ü SI-3.c.1 [at least weekly] [to include endpoints] SI-3.c.2 [to include alerting administrator or defined security personnel] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SI-3.c.1 [at least weekly] [to include endpoints] SI-3.c.2 [to include blocking and quarantining malicious code and alerting administrator or defined security personnel near-realtime] SYSTEM AND INFORMATION INTEGRITY SI-3 (1) MALICIOUS CODE PROTECTION | CENTRAL MANAGEMENT The organization centrally manages malicious code protection mechanisms. Supplemental Guidance: Central management is the organization-wide management and implementation of malicious code protection mechanisms. Central management includes planning, implementing, assessing, authorizing, and monitoring the organization-defined, centrally managed flaw malicious code protection security controls. Related controls: AU-2, SI-8. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND INFORMATION INTEGRITY SI-3 (2) MALICIOUS CODE PROTECTION | AUTOMATIC UPDATES The information system automatically updates malicious code protection mechanisms. Supplemental Guidance: Malicious code protection mechanisms include, for example, signature definitions. Due to information system integrity and availability concerns, organizations give careful consideration to the methodology used to carry out automatic updates. Related control: SI-8. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND INFORMATION INTEGRITY SI-3 (7) MALICIOUS CODE PROTECTION | NONSIGNATURE-BASED DETECTION The information system implements nonsignature-based malicious code detection mechanisms. Supplemental Guidance: Nonsignature-based detection mechanisms include, for example, the use of heuristics to detect, analyze, and describe the characteristics or behavior of malicious code and to provide safeguards against malicious code for which signatures do not yet exist or for which existing signatures may not be effective. This includes polymorphic malicious code (i.e., code that changes signatures when it replicates). This control enhancement does not preclude the use of signature-based detection mechanisms. ü ü Included in FedRAMP Moderate Baseline, Rev 4 SYSTEM AND INFORMATION INTEGRITY SI-4 INFORMATION SYSTEM MONITORING ü The organization: a. Monitors the information system to detect: 1. Attacks and indicators of potential attacks in accordance with [Assignment: organization- defined monitoring objectives]; and 2. Unauthorized local, network, and remote connections; b. Identifies unauthorized use of the information system through [Assignment: organization- defined techniques and methods]; c. Deploys monitoring devices: (i) strategically within the information system to collect organization-determined essential information; and (ii) at ad hoc locations within the system to track specific types of transactions of interest to the organization; d. Protects information obtained from intrusion-monitoring tools from unauthorized access, modification, and deletion; e. Heightens the level of information system monitoring activity whenever there is an indication of increased risk to organizational operations and assets, individuals, other organizations, or the Nation based on law enforcement information, intelligence information, or other credible sources of information; f. Obtains legal opinion with regard to information system monitoring activities in accordance with applicable federal laws, Executive Orders, directives, policies, or regulations; and g. Provides [Assignment: organization-defined information system monitoring information] to [Assignment: organization-defined personnel or roles] [Selection (one or more): as needed; [Assignment: organization-defined frequency]]. Supplemental Guidance: Information system monitoring includes external and internal monitoring. External monitoring includes the observation of events occurring at the information system boundary (i.e., part of perimeter defense and boundary protection). Internal monitoring includes the observation of events occurring within the information system. Organizations can monitor information systems, for example, by observing audit activities in real time or by observing other system aspects such as access patterns, characteristics of access, and other actions. The monitoring objectives may guide determination of the events. Information system monitoring capability is achieved through a variety of tools and techniques (e.g., intrusion detection systems, intrusion prevention systems, malicious code protection software, scanning tools, audit record monitoring software, network monitoring software). Strategic locations for monitoring devices include, for example, selected perimeter locations and near server farms supporting critical applications, with such devices typically being employed at the managed interfaces associated with controls SC-7 and AC-17. Einstein network monitoring devices from the Department of Homeland Security can also be included as monitoring devices. The granularity of monitoring information collected is based on organizational monitoring objectives and the capability of information systems to support such objectives. Specific types of transactions of interest include, for example, Hyper Text Transfer Protocol (HTTP) traffic that bypasses HTTP proxies. Information system monitoring is an integral part of organizational continuous monitoring and incident response programs. Output from system monitoring serves as input to continuous monitoring and incident response programs. A network connection is any connection with a device that communicates through a network (e.g., local area network, Internet). A remote connection is any connection with a device communicating through an external network (e.g., the Internet). Local, network, and remote connections can be either wired or wireless. Related controls: AC-3, AC-4, AC-8, AC-17, AU-2, AU-6, AU-7, AU-9, AU-12, CA-7, IR-4, PE-3, RA-5, SC-7, SC-26, SC-35, SI-3, SI-7. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 Coordination between service provider and consumer, including exchange of analysis information, signatures, indicators of compromise, etc. shall be documented and accepted by the Authorizing Official. In multi-tennant environments, capability and means for providing appropriate level(s) of issolation pertaining to consumers data shall be documented. SYSTEM AND INFORMATION INTEGRITY SI-4 (1) INFORMATION SYSTEM MONITORING | SYSTEM-WIDE INTRUSION DETECTION SYSTEM The organization connects and configures individual intrusion detection tools into an information system-wide intrusion detection system. ü ü Included in FedRAMP Moderate Baseline, Rev 4 SYSTEM AND INFORMATION INTEGRITY SI-4 (2) INFORMATION SYSTEM MONITORING | AUTOMATED TOOLS FOR REAL-TIME ANALYSIS The organization employs automated tools to support near real-time analysis of events. Supplemental Guidance: Automated tools include, for example, host-based, network-based, transport-based, or storage-based event monitoring tools or Security Information and Event Management (SIEM) technologies that provide real time analysis of alerts and/or notifications generated by organizational information systems. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND INFORMATION INTEGRITY SI-4 (4) INFORMATION SYSTEM MONITORING | INBOUND AND OUTBOUND COMMUNICATIONS TRAFFIC ü The information system monitors inbound and outbound communications traffic [Assignment: organization-defined frequency] for unusual or unauthorized activities or conditions. Supplemental Guidance: Unusual/unauthorized activities or conditions related to information system inbound and outbound communications traffic include, for example, internal traffic that indicates the presence of malicious code within organizational information systems or propagating among system components, the unauthorized exporting of information, or signaling to external information systems. Evidence of malicious code is used to identify potentially compromised information systems or information system components. ü SI-4 (4). [continuously] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SI-4 (4). [continuously] SYSTEM AND INFORMATION INTEGRITY SI-4 (5) INFORMATION SYSTEM MONITORING | SYSTEM-GENERATED ALERTS ü The information system alerts [Assignment: organization-defined personnel or roles] when the following indications of compromise or potential compromise occur: [Assignment: organization- defined compromise indicators]. Supplemental Guidance: Alerts may be generated from a variety of sources, including, for example, audit records or inputs from malicious code protection mechanisms, intrusion detection or prevention mechanisms, or boundary protection devices such as firewalls, gateways, and routers. Alerts can be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. Organizational personnel on the notification list can include, for example, system administrators, mission/business owners, system owners, or information system security officers. Related controls: AU-5, PE-6. ü SI-4(5) Guidance: In accordance with the incident response plan. ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND INFORMATION INTEGRITY SI-4 (11) INFORMATION SYSTEM MONITORING | ANALYZE COMMUNICATIONS TRAFFIC ANOMALIES ü The organization analyzes outbound communications traffic at the external boundary of the information system and selected [Assignment: organization-defined interior points within the system (e.g., subnetworks, subsystems)] to discover anomalies. Supplemental Guidance: Anomalies within organizational information systems include, for example, large file transfers, long-time persistent connections, unusual protocols and ports in use, and attempted communications with suspected malicious external addresses. ü NEED. When a high-impact system is implemented in a shared-service environment, organizations should ensure their sensitive data is properly protected against classic threats to the confidentiality of its sensitive information. This control partially meets that need. ANALYSIS. The tools and techniques for implementing this monitoring control are now well understood and embedded in COTS operating systems and software. SAMPLE THREAT VECTORS. Large outbound file transfers execute without being detected. External malware network sites are accessed from within the organization without detection. Network sessions remain connected for long periods of time without detection. Esoteric protocols are active and undetected on ports not defined by the organization. RELEVANT SECURITY CONTROL ATTRIBUTES. Monitored [organization and service provider-defined interior points within the system (e.g., subnetworks, subsystems)] SYSTEM AND INFORMATION INTEGRITY SI-4 (14) INFORMATION SYSTEM MONITORING | WIRELESS INTRUSION DETECTION The organization employs a wireless intrusion detection system to identify rogue wireless devices and to detect attack attempts and potential compromises/breaches to the information system. Supplemental Guidance: Wireless signals may radiate beyond the confines of organization- controlled facilities. Organizations proactively search for unauthorized wireless connections including the conduct of thorough scans for unauthorized wireless access points. Scans are not limited to those areas within facilities containing information systems, but also include areas outside of facilities as needed, to verify that unauthorized wireless access points are not connected to the systems. Related controls: AC-18, IA-3. ü ü Included in FedRAMP Moderate Baseline, Rev 4 SYSTEM AND INFORMATION INTEGRITY SI-4 (16) INFORMATION SYSTEM MONITORING | CORRELATE MONITORING INFORMATION The organization correlates information from monitoring tools employed throughout the information system. Supplemental Guidance: Correlating information from different monitoring tools can provide a more comprehensive view of information system activity. The correlation of monitoring tools that usually work in isolation (e.g., host monitoring, network monitoring, anti-virus software) can provide an organization-wide view and in so doing, may reveal otherwise unseen attack patterns. Understanding the capabilities/limitations of diverse monitoring tools and how to maximize the utility of information generated by those tools can help organizations to build, operate, and maintain effective monitoring programs. Related control: AU-6. ü ü Included in FedRAMP Moderate Baseline, Rev 4 SYSTEM AND INFORMATION INTEGRITY SI-4 (18) INFORMATION SYSTEM MONITORING | ANALYZE TRAFFIC / COVERT EXFILTRATION ü The organization analyzes outbound communications traffic at the external boundary of the information system (i.e., system perimeter) and at [Assignment: organization-defined interior points within the system (e.g., subsystems, subnetworks)] to detect covert exfiltration of information. Supplemental Guidance: Covert means that can be used for the unauthorized exfiltration of organizational information include, for example, steganography. ü NEED. When a high-impact system is implemented in a shared-service environment, organizations should ensure their sensitive data is properly protected against classic threats to the confidentiality of sensitive information. This control partially meets that need. ANALYSIS. The tools and techniques for implementing this monitoring control are now well understood, and embedded in COTS operating systems and software. SAMPLE THREAT VECTORS. Large outbound files are disguised to transfer without being detected. Communications with external malware network sites are embedded to avoid detection. RELEVANT SECURITY CONTROL ATTRIBUTES. Substantiated Integrity, Monitored, Assessed [organization and service provider-defined interior points within the system (e.g., subnetworks, subsystems)] SYSTEM AND INFORMATION INTEGRITY SI-4 (22) INFORMATION SYSTEM MONITORING | UNAUTHORIZED NETWORK SERVICES ü The information system detects network services that have not been authorized or approved by [Assignment: organization-defined authorization or approval processes] and [Selection (one or more): audits; alerts [Assignment: organization-defined personnel or roles]]. Supplemental Guidance: Unauthorized or unapproved network services include, for example, services in service-oriented architectures that lack organizational verification or validation and therefore may be unreliable or serve as malicious rogues for valid services. Related controls: AC-6, CM-7, SA-5, SA-9. ü NEED. When a high-impact system is implemented across networks in a shared-service environment, organizations should monitor network services to protect against unauthorized services capable of exfiltrating sensitive information. This control meets that monitoring need. ANALYSIS. The tools and techniques for implementing this monitoring control are well understood, and embedded in COTS operating systems and software. SAMPLE THREAT VECTORS. Systems daemons and application services running in the background, exfiltrating sensitive information to external networks. RELEVANT SECURITY CONTROL ATTRIBUTES. Monitored, Assessed [organization and service provider-defined authorization or approval processes] [audits; alerts organization and service provider designated security personnel ]]. SYSTEM AND INFORMATION INTEGRITY SI-4 (23) INFORMATION SYSTEM MONITORING | HOST-BASED DEVICES ü The organization implements [Assignment: organization-defined host-based monitoring mechanisms] at [Assignment: organization-defined information system components]. Supplemental Guidance: Information system components where host-based monitoring can be implemented include, for example, servers, workstations, and mobile devices. Organizations consider employing host-based monitoring mechanisms from multiple information technology product developers. ü ü Included in FedRAMP Moderate Baseline, Rev 4 SYSTEM AND INFORMATION INTEGRITY SI-4 (24) INFORMATION SYSTEM MONITORING | INDICATORS OF COMPROMISE The information system discovers, collects, distributes, and uses indicators of compromise. Supplemental Guidance: Indicators of compromise (IOC) are forensic artifacts from intrusions that are identified on organizational information systems (at the host or network level). IOCs provide organizations with valuable information on objects or information systems that have been compromised. IOCs for the discovery of compromised hosts can include for example, the creation of registry key values. IOCs for network traffic include, for example, Universal Resource Locator (URL) or protocol elements that indicate malware command and control servers. The rapid distribution and adoption of IOCs can improve information security by reducing the time that information systems and organizations are vulnerable to the same exploit or attack. ü NEED. When a high-impact system is implemented across networks in a shared-service environment, organizations should aggressively monitor for symptoms that system integrity has been compromised. This control addresses that monitoring need. ANALYSIS. The tools and techniques for implementing this monitoring control are no longer unusual, but their implementation still requires careful initial analysis of tools, standards, and sources for indicators of compromise (IOC) data. This capability is not a simple matter of installing COTS software and watching for alerts. Rather, it requires staff to maintain a keen understanding of the threat-scape in order to properly understand the alerts coming from the IOC subsystem. SAMPLE THREAT VECTORS. Temporary files appear but are not associated with any known system processes; independent security services warn of new surveillance techniques appearing globally; evidence of those new techniques appears in an organization’s event logs. Reports on the payload of a new botnet indicate that the system has been touched by the botnet. RELEVANT SECURITY CONTROL ATTRIBUTES. Monitored, Assessed SYSTEM AND INFORMATION INTEGRITY SI-5 SECURITY ALERTS, ADVISORIES, AND DIRECTIVES ü The organization: a. Receives information system security alerts, advisories, and directives from [Assignment: organization-defined external organizations] on an ongoing basis; b. Generates internal security alerts, advisories, and directives as deemed necessary; c. Disseminates security alerts, advisories, and directives to: [Selection (one or more): [Assignment: organization-defined personnel or roles]; [Assignment: organization-defined elements within the organization]; [Assignment: organization-defined external organizations]]; and d. Implements security directives in accordance with established time frames, or notifies the issuing organization of the degree of noncompliance. Supplemental Guidance: The United States Computer Emergency Readiness Team (US-CERT) generates security alerts and advisories to maintain situational awareness across the federal government. Security directives are issued by OMB or other designated organizations with the responsibility and authority to issue such directives. Compliance to security directives is essential due to the critical nature of many of these directives and the potential immediate adverse effects on organizational operations and assets, individuals, other organizations, and the Nation should the directives not be implemented in a timely manner. External organizations include, for example, external mission/business partners, supply chain partners, external service providers, and other peer/supporting organizations. Related control: SI-2. ü ü SI-5a. [to include US-CERT] SI-5c. [to include system security personnel and administrators with configuration/patch-management responsibilities] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND INFORMATION INTEGRITY SI-5 (1) SECURITY ALERTS, ADVISORIES, AND DIRECTIVES | AUTOMATED ALERTS AND ADVISORIES The organization employs automated mechanisms to make security alert and advisory information available throughout the organization. Supplemental Guidance: The significant number of changes to organizational information systems and the environments in which those systems operate requires the dissemination of security-related information to a variety of organizational entities that have a direct interest in the success of organizational missions and business functions. Based on the information provided by the security alerts and advisories, changes may be required at one or more of the three tiers related to the management of information security risk including the governance level, mission/business process/enterprise architecture level, and the information system level. References: NIST Special Publication 800-40. ü Included in NIST High Baseline, Rev 4 SYSTEM AND INFORMATION INTEGRITY SI-6 SECURITY FUNCTION VERIFICATION ü The information system: a. Verifies the correct operation of [Assignment: organization-defined security functions]; b. Performs this verification [Selection (one or more): [Assignment: organization-defined system transitional states]; upon command by user with appropriate privilege; [Assignment: organization-defined frequency]]; c. Notifies [Assignment: organization-defined personnel or roles] of failed security verification tests; and d. [Selection (one or more): shuts the information system down; restarts the information system; [Assignment: organization-defined alternative action(s)]] when anomalies are discovered. ü SI-6b [to include upon system startup and/or restart and at least monthly] SI-6c [to include system administrators and security personnel] SI-6d [to include notification of system administrators and security personnel] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND INFORMATION INTEGRITY SI-7 SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY ü The organization employs integrity verification tools to detect unauthorized changes to [Assignment: organization-defined software, firmware, and information]. Supplemental Guidance: Unauthorized changes to software, firmware, and information can occur due to errors or malicious activity (e.g., tampering). Software includes, for example, operating systems (with key internal components such as kernels, drivers), middleware, and applications. Firmware includes, for example, the Basic Input Output System (BIOS). Information includes metadata such as security attributes associated with information. State-of-the-practice integrity- checking mechanisms (e.g., parity checks, cyclical redundancy checks, cryptographic hashes) and associated tools can automatically monitor the integrity of information systems and hosted applications. Related controls: SA-12, SC-8, SC-13, SI-3. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND INFORMATION INTEGRITY SI-7 (1) SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY | INTEGRITY CHECKS ü The information system performs an integrity check of [Assignment: organization-defined software, firmware, and information] [Selection (one or more): at startup; at [Assignment: organization-defined transitional states or security-relevant events]; [Assignment: organization- defined frequency]]. Supplemental Guidance: Security-relevant events include, for example, the identification of a new threat to which organizational information systems are susceptible, and the installation of new hardware, software, or firmware. Transitional states include, for example, system startup, restart, shutdown, and abort. ü SI-7 (1). [Selection to include security relevant events and at least monthly] ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND INFORMATION INTEGRITY SI-7 (2) SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY | AUTOMATED NOTIFICATIONS OF INTEGRITY VIOLATIONS ü The organization employs automated tools that provide notification to [Assignment: organization- defined personnel or roles] upon discovering discrepancies during integrity verification. Supplemental Guidance: The use of automated tools to report integrity violations and to notify organizational personnel in a timely matter is an essential precursor to effective risk response. Personnel having an interest in integrity violations include, for example, mission/business owners, information system owners, systems administrators, software developers, systems integrators, and information security officers. ü Included in NIST High Baseline, Rev 4 [organization and service provider-defined system/application admin personnel] SYSTEM AND INFORMATION INTEGRITY SI-7 (5) SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY | AUTOMATED RESPONSE TO INTEGRITY VIOLATIONS ü The information system automatically [Selection (one or more): shuts the information system down; restarts the information system; implements [Assignment: organization-defined security safeguards]] when integrity violations are discovered. Supplemental Guidance: Organizations may define different integrity checking and anomaly responses: (i) by type of information (e.g., firmware, software, user data); (ii) by specific information (e.g., boot firmware, boot firmware for a specific types of machines); or (iii) a combination of both. Automatic implementation of specific safeguards within organizational information systems includes, for example, reversing the changes, halting the information system, or triggering audit alerts when unauthorized modifications to critical security files occur. ü Included in NIST High Baseline, Rev 4 [organization and service provider selects (one or more): shuts the information system down; restarts the information system; implements [organization and service provider-defined security safeguards]] SYSTEM AND INFORMATION INTEGRITY SI-7 (7) SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY | INTEGRATION OF DETECTION AND RESPONSE ü The organization incorporates the detection of unauthorized [Assignment: organization-defined security-relevant changes to the information system] into the organizational incident response capability. Supplemental Guidance: This control enhancement helps to ensure that detected events are tracked, monitored, corrected, and available for historical purposes. Maintaining historical records is important both for being able to identify and discern adversary actions over an extended period of time and for possible legal actions. Security-relevant changes include, for example, unauthorized changes to established configuration settings or unauthorized elevation of information system privileges. Related controls: IR-4, IR-5, SI-4. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND INFORMATION INTEGRITY SI-7 (14) SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY | BINARY OR MACHINE EXECUTABLE CODE The organization: (a) Prohibits the use of binary or machine-executable code from sources with limited or no warranty and without the provision of source code; and (b) Provides exceptions to the source code requirement only for compelling mission/operational requirements and with the approval of the authorizing official. Supplemental Guidance: This control enhancement applies to all sources of binary or machine- executable code including, for example, commercial software/firmware and open source software. Organizations assess software products without accompanying source code from sources with limited or no warranty for potential security impacts. The assessments address the fact that these types of software products may be very difficult to review, repair, or extend, given that organizations, in most cases, do not have access to the original source code, and there may be no owners who could make such repairs on behalf of organizations. Related control: SA-5. ü Included in NIST High Baseline, Rev 4 SYSTEM AND INFORMATION INTEGRITY SI-8 SPAM PROTECTION The organization: a. Employs spam protection mechanisms at information system entry and exit points to detect and take action on unsolicited messages; and b. Updates spam protection mechanisms when new releases are available in accordance with organizational configuration management policy and procedures. Supplemental Guidance: Information system entry and exit points include, for example, firewalls, electronic mail servers, web servers, proxy servers, remote-access servers, workstations, mobile devices, and notebook/laptop computers. Spam can be transported by different means including, for example, electronic mail, electronic mail attachments, and web accesses. Spam protection mechanisms include, for example, signature definitions. Related controls: AT-2, AT-3, SC-5, SC- 7, SI-3. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND INFORMATION INTEGRITY SI-8 (1) SPAM PROTECTION | CENTRAL MANAGEMENT The organization centrally manages spam protection mechanisms. Supplemental Guidance: Central management is the organization-wide management and implementation of spam protection mechanisms. Central management includes planning, implementing, assessing, authorizing, and monitoring the organization-defined, centrally managed spam protection security controls. Related controls: AU-3, SI-2, SI-7. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND INFORMATION INTEGRITY SI-8 (2) SPAM PROTECTION | AUTOMATIC UPDATES The information system automatically updates spam protection mechanisms. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND INFORMATION INTEGRITY SI-10 INFORMATION INPUT VALIDATION ü The information system checks the validity of [Assignment: organization-defined information inputs]. Supplemental Guidance: Checking the valid syntax and semantics of information system inputs (e.g., character set, length, numerical range, and acceptable values) verifies that inputs match specified definitions for format and content. Software applications typically follow well-defined protocols that use structured messages (i.e., commands or queries) to communicate between software modules or system components. Structured messages can contain raw or unstructured data interspersed with metadata or control information. If software applications use attacker- supplied inputs to construct structured messages without properly encoding such messages, then the attacker could insert malicious commands or special characters that can cause the data to be interpreted as control information or metadata. Consequently, the module or component that receives the tainted output will perform the wrong operations or otherwise interpret the data incorrectly. Prescreening inputs prior to passing to interpreters prevents the content from being unintentionally interpreted as commands. Input validation helps to ensure accurate and correct inputs and prevent attacks such as cross-site scripting and a variety of injection attacks. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND INFORMATION INTEGRITY SI-11 ERROR HANDLING ü The information system: a. Generates error messages that provide information necessary for corrective actions without revealing information that could be exploited by adversaries; and b. Reveals error messages only to [Assignment: organization-defined personnel or roles]. Supplemental Guidance: Organizations carefully consider the structure/content of error messages. The extent to which information systems are able to identify and handle error conditions is guided by organizational policy and operational requirements. Information that could be exploited by adversaries includes, for example, erroneous logon attempts with passwords entered by mistake as the username, mission/business information that can be derived from (if not stated explicitly by) information recorded, and personal information such as account numbers, social security numbers, and credit card numbers. In addition, error messages may provide a covert channel for transmitting information. Related controls: AU-2, AU-3, SC-31. Control Enhancements: None. References: None. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND INFORMATION INTEGRITY SI-12 INFORMATION HANDLING AND RETENTION The organization handles and retains information within the information system and information output from the system in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and operational requirements. Supplemental Guidance: Information handling and retention requirements cover the full life cycle of information, in some cases extending beyond the disposal of information systems. The National Archives and Records Administration provides guidance on records retention. Related controls: AC-16, AU-5, AU-11, MP-2, MP-4. ü ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 SYSTEM AND INFORMATION INTEGRITY SI-16 MEMORY PROTECTION ü The information system implements [Assignment: organization-defined security safeguards] to protect its memory from unauthorized code execution. Supplemental Guidance: Some adversaries launch attacks with the intent of executing code in non- executable regions of memory or in memory locations that are prohibited. Security safeguards employed to protect memory include, for example, data execution prevention and address space layout randomization. Data execution prevention safeguards can either be hardware-enforced or software-enforced with hardware providing the greater strength of mechanism. Related controls: AC-25, SC-3. Control Enhancements: None. References: None. ü ü Included in NIST High Baseline, Rev 4 and FedRAMP Moderate Baseline, Rev 4 Inherited from RHEL