19. DRAFT - DHA ACAS-NESSUS Scanning Guide-CUI.pdf

Defense Health Agency (DHA) Risk Management Executive Division

(RMED)

Assured Compliance Assessment Solution

(ACAS) Scanning Guide Version 2.7 March 2022

Prepared for:

Defense Health Agency

Office of the Chief Information Officer Risk Management Executive Division

Assessment & Authorization Branch Falls Church, Virginia 22041

CUI

CUI

Controlled By: Defense Health Agency Controlled By: DAD IO (J-6)/Risk Management Executive Division CUI Category: Controlled Technical Information (CTI) Distribution/Dissemination Control: DISTRO C POC: dha.jbcharleston.j-6.list.dha.a-a-program-support@mail.mil

Distribution Statement C: Distribution authorized to U.S. Government agencies and their contractors. This document contains technical details and security procedures not intended for release to unauthorized individuals. Date of determination is 31 March 2022. Other requests for this document shall be referred to DAD IO (J-6)/Risk Management Executive Division. POC: dha.jbcharleston.j-6.list.dha.a-a-program-support@mail.mil

REVISION AND HISTORY PAGE

Revisions and version changes to this document are recorded within the following table. New versions are published when changes to the document equate to 10 percent or greater of the document’s content, or if a change requires immediate implementation. This record is maintained throughout the life of the document.

This document will be reviewed at a minimum annually.

Version Date Author Description

1.0 8/27/2018 Mathew

Smith Document Creation

1.1 2/22/2019 Mathew Smith

Revision of CMRS and Enterprise Mission Assurance Support System (eMASS) / addition of plugin timeline.

1.2 7/20/2020 Mathew Smith

Addition of Advanced Scan Options/ E-mail info/ updated Taskord Information

2.0 9/25/2020 Anna Ehrhardt/ Mathew Smith

Complete rewrite due to merge of TASKORD 20-0020, DISA

ACAS

BPG v5.4 and DHA ACAS Scanning Guide

2.1 11/2/2020 Anna Ehrhardt

Additional Steps for Scanning Reports, Host Based Security System (HBSS) Setup, validate before publishing, Scanning for other A&A activities, and eMASS references.

2.1 11/17/202

Mathew Smith

Update of Section 3.6 Report Creation

2.2 6/03/2021 Brody Cambero

Added notes in section 4.3 and 4.3.2

2.3 6/16/2021 Mathew Smith

Realignment of sections, scan frequency update, BPG version updates, changes from Remedy to Service Now ticket instructions, plugin updates, removal of asset list descriptions, ACAS verbiage updates

2.4 10/15/202

Mathew Smith

- Consolidated Section “1.3 Why Scan” verbiage into “Introduction”

- Updated language in “2.2 Plugin Availability”

- Updated Section “2.7 Compliance Scanning” to reflect

STIG usage vice SCAP

- Updated ACAS Account Section to include new required training verbiage

- Updated email addresses for DISA ACAS Help Desk

- Cleaned up necessary grammatical anomalies

- Added Kerberos requirements to Section “3.2.4

Additional Creation Tips”

- Updated “9.1 MHS Service Now Ticket Submission” with additional URL

- Refinement of Repository descriptions

- Addition of unsupported device listing and verification updating of supported device list

- Modified Asset List verbiage in Section 2.1

- Removal of superfluous References from Section 10

- Modified points in Section 3.4.1.3 Target Selection

- Updated verbiage in Section “3.5 Scan Policies” to reflect BPG STIG updates

- Updated configuration scan frequency

2.5 1/19/2022 Carmeshia Miller

- Updated organization name, formatted header, and footer.

- Changed FOUO to CUI

CUI DHA ACAS Scanning Guide Version 2.7

CUI 2

2.6 3/16/2022 Carmeshia Miller

- Removed CUI from document

2.7 3/22/2022 Scott Walker /

RMED

Program Support Team

- Formatted for RMED consistency:

• Type fonts and sizes

• Paragraph / sentence spacing to 3 pt.

• “Note” boxes per RMED guidance

• Table headers and text for consistency

• Added CUI to headers and footers per

RMED guidance

• Updated links throughout document

• Updated all headings for consistency and

TOC inclusion

• Attributed references to all tables and figures throughout document to accommodate dynamic referencing

• Updated tables 1, 3, and 4 for consistency with RMED documentation

• Updated bullet alignment throughout document per MHS Writing and Style Guide

• Updated entire acronym list

• Other general formatting

2.7 3/29/2022 CPBO

Program Support Team Lead, Carmeshia Miller

- Added date to cover page.

CUI 3

Contents 1 Introduction

1.1 Purpose

1.2 Scanning Requirements

1.3 Organizational Responsibilities

2 DHA ACAS Basic Information

2.1 Components of a Scan

2.2 Plugin Availability

2.3 Differences between Supported and Unsupported Devices

2.4 Repository Naming Convention

2.5 Scan Results vs. Repository Results

2.6 Compliance Scanning

3 SecurityCenter Guidance

3.1 ACAS Accounts

3.1.1 User Account Access

3.1.2 Training

3.1.3 Groups

3.1.4 Initial Login

3.1.5 Deactivated Accounts

3.2 Credentials

3.2.1 Credential Ownership

3.2.2 Authentication Protocols

3.2.3 Create Credentials

3.2.4 Additional Creation Tips

3.2.5 ESX/ESXi SOAP Authentication

3.2.6 Adding Credentials to Scans

3.2.7 Non-Credentialed Scanning

3.3 Required System Configuration for a Successful Scan

3.3.1 General Configurations

3.3.2 Windows

3.3.3 Linux

3.3.4 Network Devices

3.4 Active Scan Configuration

3.4.1 Best Practice Active Scan Settings

3.4.2 Email Setting

3.5 Scan Policy

3.6 Dashboards

3.7 Report Creation

4 CMRS & eMASS

4.1 CMRS Ecosystem

4.2 COAMS Registration

4.2.1 Assign COAMS ID in eMASS

4.2.2 COAMS Asset List

4.3 Vulnerability Publishing

4.3.1 CMRS Publishing

4.3.2 Report Configuration

4.3.3 eMASS Publishing

4.4 Frequent Questions

CUI 4

5 Troubleshooting Scans

5.1 Plugins

5.1.1 Bad Scan Indicators

5.1.2 Authentication Status Plugin Summary

5.1.3 Specific Authentication/Local Check Issue Plugin Summary

5.1.4 Local Checks Status Summary

5.1.5 Operating System Enumeration Checks

5.1.6 Windows Access Checks

5.1.7 Windows Administrators

5.2 Troubleshooting through Queries (Asset Lists)

6 Common SC Errors and Questions 7 HBSS Waiver Process

7.1 Introduction

7.1.1 Purpose

7.1.2 Background

7.2 Waiver Criteria

7.2.1 Exemption

7.2.2 Exception to Policy – POA&M Only

7.2.3 Waiver Request

8 Glossary

8.1 ACAS Terminology

8.2 Acronym List

9 Troubleshooting Assistance

9.1 MHS ServiceNow Ticket Submission

9.2 Technical Points of Contact

10 References

APPENDIX A: USCYBERCOM HBSS Waiver Request

List of Figures:

Figure 1: SSH Password Credential Figure 2: CMRS Ecosystem Figure 3: COAMS System Affiliation Figure 4: Add DISA ASR Figure 5: Add DISA ASR Report Figure 6: Definition Figure 7: Filter Figure 8: Distribution Figure 9: Add DISA ASR Figure 10: Add DISA ASR Report Figure 11: Definition Figure 12: Distribution Figure 13: Add DISA ASR

CUI 5

Figure 14: Benchmark Report Setup Figure 15: Active Plugin Type Figure 16: DISA CMRS Figure 17: Authentication Plugin Flow Figure 18: HBSS Waiver Request Workflow

List of Tables:

Table 1: Scan Frequency Table 2: Organizational Responsibilities Table 3: Local Check Availability Table 4: Unsupported Devices Table 5: Windows Credential Setup Table 6: Linux Credential Setup Table 7: Windows Kerberos Attributes Table 8: Linux Kerberos Attributes

CUI 6

1 Introduction The Assured Compliance Assessment Solution (ACAS) is a Department of Defense (DoD) vulnerability-scanning suite leveraging the Tenable Commercial off the Shelf (COTS) Product. The Nessus Vulnerability Scanner actively scans operating systems (OS’s) and applications including database management software and web applications. The policies, plugins, reports, and vulnerability tracking information are consolidated for management and analysis by the SecurityCenter (SC) application.

When collectively utilized, the ACAS suite allows consumers to identify their cybersecurity posture and report their compliance in accordance with DoD, Joint Force Headquarters for the DoD Information Network (JFHQ-DoDIN), and Defense Health Agency (DHA) requirements.

DoD components must continue to regularly assess the cybersecurity posture within their scope of responsibility and identify vulnerabilities that provide a target of opportunity for threat actors to compromise the Confidentiality, Integrity, and Availability of DoD Information Systems (IS) and mission relevant data. Known vulnerabilities are regularly leveraged in targeted attacks against DoD IS’s and actions must be taken to identify and effectively remediate or mitigate any vulnerabilities to ensure protection of personal and national sensitive and / or classified information.

1.1 Purpose

The intention of this document is to provide general information for ACAS scanning operations and vulnerability management within DHA Medical Community of Interest (Med-COI) SCs to assist with establishing a foundation of knowledge for DHA Med-COI ACAS users. This document should assist the standard ACAS user with basic troubleshooting and provide information to preclude creation of trouble tickets regarding common issues as well as addressing common questions that may arise.

1.2 Scanning Requirements

Each Program of Record (POR) and Military Treatment Facility (MTF) is responsible for providing adequate staffing to perform the required scanning.

The expectation is for DHA Med-COI ACAS users to complete scans and publish results to Continuous Monitoring Risk Scoring (CMRS) in accordance with the schedule in the table below. This schedule specifies the minimum scan frequency and meets the requirements set forth in JFHQ-DoDIN Task Order (TASKORD) 20-0020 ASSURED COMPLIANCE ASSESSMENT SOLUTION (ACAS) OPERATIONAL GUIDANCE, Fragmentary Order’s (FRAGOs), and the latest Defense Information Systems Agency (DISA) ACAS Best Practices Guide (BPG).

Scan Category Frequency Discovery Scan Every 30 days

Full-plugin Vulnerability Scan Every 7 days Configuration Scan (STIG) Every 30 days

Table 1: Scan Frequency

NOTE: Users are responsible for scanning and are encouraged to take a more proactive approach, scanning more frequently than listed in the table

1.3 Organizational Responsibilities

The following table outlines the differing organizational responsibilities as they pertain to the ACAS Environment.

CUI 7

Task Matrix PMO CyOC CSD

COAMS Request X X (COAMs Team)

COAMS Registration in eMASS X SecurityCenter Registration X SecurityCenter Configuration with Site Info X SecurityCenter Scan / Report Setup X Security Center Report Filters/Publishing Schedule X HBSS Asset List X HBSS Scanning X CMRS Data Monitoring X eMASS Asset Tab Continuous Monitoring X eMASS Continuous Monitoring POAM Submissions X

Table 2: Organizational Responsibilities

2 DHA ACAS Basic Information

2.1 Components of a Scan

To start actively scanning assets, several components assemble in an Active Scan definition. These components are:

• Scan Policy

• Scan Zone

• Repository

• Asset Lists

• System Credentials.

A Scan Policy defines which plugins (and audit files, if selected) Nessus will launch against specified assets during the scan.

Scan Zones identify which Internet Protocol (IP) address ranges Security Center (SC) will feed to associated Nessus scanners. When more than one Nessus scanner is associated with a Scan Zone, SC will attempt to load balance among them.

NOTE: Best practice is to choose the Scan Zone configured for “Automatic Distribution”. This ensures that the scan is coming from the correct scanner

Repositories are similar to databases, defined by IP address ranges and aligned to Site and Program of Record (POR) accreditation boundaries. These ranges identify for which IPs the repository can store data.

When these ranges change, data for removed IPs does not immediately delete, but will be inaccessible unless the IPs are added back into the Repository’s ranges.

Targets for scanning can be defined either as an Asset List configured within the Assets section of SC or a discrete list of IPs added into the Scan directly. Although the capability exists for individual host names to

CUI 8

be utilized in the target field, this is not a recommended action due to possible issues with DNS not being able to resolve the said host name.

Asset Lists are useful in enumerating IP addresses and identifying logical groupings of IP addresses for Nessus to scan and report to SC. Each organization or site within SecurityCenter will maintain its own Asset Lists. Asset lists are not visible between sites unless specifically shared between the groups that own them. There are two main types of asset lists:

• Static lists (IP Addresses) can be inserted manually or uploaded in bulk via text files:

o Grouping machines that do not have common factors among them o Grouping machines that do not have a unique factor o Machines that change configuration, but are treated the same.

• Dynamic lists are computed based on the rich content of the plugin results discovered by Nessus (and re-computed when scan data is imported). Further elaboration on this can be found in Section 5.2 Troubleshooting through Queries (Asset Lists).

NOTE: Please limit your asset list to ONLY use assigned IP ranges that were provided via an IP Plan and/or RFI. The use of unassigned IP space in an asset list can have severe impacts on system resources and is strictly prohibited. Discovery of any Active Scans or Asset Lists utilizing unassigned IP space will be removed immediately upon discovery.

System credentials are the Server Message Block (SMB), Secure Shell (SSH), etc. credentials that Nessus will use during the scan to attempt to access targets within an Asset list or target group of systems.

Details about appropriate credential permissions and configuration are in Section 3.2 Credentials.

A more detailed description of each of these items (as well as others) are available in Section 8.1 ACAS Terminology.

2.2 Plugin Availability

ACAS plugin updates are pulled automatically from DISA once a day at 07:30 ET. The DHA Cyber Security Operations Center (CyOC) ACAS Team has no control over when the vendor makes them available to DISA, nor the turnaround time for DISA to make the plugins available to DoD components and agencies. Given this sequence of events, ACAS plugins within Med-COI typically lag behind their commercial release by approximately 24 hours and plugins supporting released Information Assurance Vulnerability Management (IAVM) notices usually arrive the following Monday.

2.3 Differences between Supported and Unsupported Devices

JFHQ-DoDIN TASKORD 20-0020 directs that vulnerability scans must be conducted a minimum of once every 7 days. The vulnerability scan must be credentialed unless the target of the scan is restricted to known unsupported devices. Nessus will return different levels of vulnerability detail and granularity in its Scan Results depending on whether a device is supported or unsupported.

A supported device is one which can be accessed remotely (via SMB, SSH, etc.) and has local security checks written specifically for its operating system. A local security check is one which evaluates a condition—e.g. a specific version of an application, existence of a .dll file, or Registry key’s value— known to be vulnerable to a Common Vulnerabilities and Exposure (CVE) and one for which a patch is available from its vendor.

CUI 9

Local checks for major operating systems with security advisories number in the thousands and are grouped into discrete Plugin Families named after the Operating Systems, though local checks exist in other families as well.

As of Oct 2021, ACAS has Plugin Families / local checks available for the following Operating Systems and appliances:

AIX HP-UX Red Hat Enterprise Linux

Amazon Linux Huawei Scientific Linux

CentOS Junos Slackware

Cisco (IOS & CatOS) MacOS Solaris

Debian Mandriva SuSE

F5 NewStart CGSL Ubuntu

Fedora Oracle (Linux and Vm) Virtuozzo

FreeBSD Palo Alto VMware ESX

Gentoo PhotonOS Microsoft Windows

Table 3: Local Check Availability Unsupported devices do not have dedicated or local checks available from the vendor, as such even if Nessus can login to a device it will not have security checks specific to the device’s OS. Usually this is because there are no known vulnerabilities specific to the device or the device has low rate of adoption among commercial and federal customers.

Devices are also known as unsupported if there is no remote authentication available, as is the case with many purpose-built appliances.

While not all inclusive due to the ever changing variety of available technologies, the following devices are currently known to be unsupported:

Hitachi AMS2500Disk Array Controller Hitachi AMS2500 Disk Array Controller

Hitachi VSP Hitachi VSP

Nutanix Management Interface Nutanix Management Interface

OpenVMS OpenVMS

HP iLO Appliance HP iLO Appliance

Brocade FastIron OS Brocade FastIron OS

Brocade Fabric OS Brocade Fabric OS

Table 4: Unsupported Devices

NOTE: Unsupported devices can still be checked for remote vulnerabilities, especially to third-party applications—e.g. OpenSSH, Apache web server, etc.—and, as stated at the beginning of this section, still require active scans as per published frequency outlined in TASKORD 20-0020

CUI 10

2.4 Repository Naming Convention

Repositories are shared with user groups and are utilized based on various defined data such as vulnerability versus compliance data. Repositories are built around a Program of Record (POR) or Military Treatment Facility’s (MTF) network structure and accreditation boundaries, and are set to allow only IP addresses which belong to the POR/MTF after which the repository is named. Changes to the IP address range definitions should be initiated by contacting the Subscriber Engagement Team. Contact information is provided in section 9 Troubleshooting Assistance.

Repositories hold different, discrete types of data and are named accordingly:

• Vulnerability: Full-system vulnerability scans handled primarily through Nessus plugins, tied to known vulnerabilities provided to Tenable by different software vendors

• Discovery: Scans conducted to discover live IPs on a network

• Security Technical Implementation Guide (STIG): Compliance scans using DISA STIG Audit Files from Tenable available within SC conducted through the use of audit files or STIG content, and are used to address software/system misconfigurations according to industry best practices or DISA STIG policies.

Due to the difference between the types of scans and the results each create, it is important to choose the correct repository for the scan results. Failure to utilize the correct repository can create skewed CSSP tool compliance metrics and negatively influences the ability to accurately parse vulnerability trending and mitigation.

NOTE: Discovery Repositories are not provided during initial setup for PORs however can be coordinated for setup if requested

2.5 Scan Results vs. Repository Results

Scan results are a snapshot in time. This type of result shows the current composition of vulnerabilities on the scanned assets at a specified moment in time. The results are not cumulative and show changes in vulnerability status only for hosts in the scan.

Repository results are a broader historical overview of cumulative open vulnerabilities resulting from historical scan data. Repositories include the results of all scans whose data are imported into them, and can be used for data trending as well.

2.6 Compliance Scanning

Sites must scan 100% of their active IP space using all applicable operating system and device level audit files. As per the DISA Best Practice Guide and TASKORD 20-0020 FRAGO 3, the usage of Security Content Automation Protocol (SCAP) Benchmarks is no longer authorized, only DISA STIG Tenable Audit files are to be used for configuration scanning within ACAS. As such, DHA Med-COI will be sun-setting the currently provided SCAP content and moving to the usage of DISA STIG Audit Files provided from Tenable via the application feed. Per the DISA BPG 5.4.2, “JFHQ-DODIN/DISA and the ACAS vendor are piloting an effort to publish Tenable Audit scan results into CMRS.” Additional information will be provided to subscribers as it becomes available.

Audit Files will no longer be provisioned up front by the DHA CyOC ACAS Team, but will be selectable by sites and PORs as needed from the SC feed. Instructions for this are as follows:

a) Proceed to Audit Files under the Scan tab

b) Select “Add” on the top right hand side

CUI 11

c) Either select the applicable operating system block, or…

d) enter “DISA STIG” in the search bar and press enter

e) Select the desired STIG and click the arrow on the right hand side

f) Enter desired name and fill out any applicable blocks as needed

g) Press Submit.

Some DISA STIG content will necessitate additional information be placed in order to provide customized compliance scanning, this may require coordination with administrative teams for the expected values, particularly values (file paths or usernames for example) that are site specific. Information in these blocks when first loaded are default values and as such may not be accurate for each environment. False positive results are greatly reduced when updating the user-defined values for the environment to be scanned. Take the time to ensure that these values are appropriate for the endpoint to be scanned.

Once the Audit File is configured, association will be necessary with a Scan Policy. A template Policy is provided under the “Policies” tab: “DHA STIG – Template”. This template policy will be maintained according to the most recent available DISA Policy templates.

To associate the Audit File, follow the below steps:

a) Locate the Policy: “DHA STIG – Template”

b) Select “Copy” from the right-hand side drop down

c) Select “Edit” from the right-hand side drop down

d) Rename as appropriate

e) Select “Compliance” tab

f) Select “Add Audit File”

g) Select Type from the drop down

h) Select applicable Audit File name

i) Press the Check Mark

j) Press “Submit”.

Once this is accomplished, the Policy / Audit File will be ready for use in a compliance scan as normal.

It is important to remember the following items when running STIG scans:

• Use a separate repository for STIG scan data (Med-COI provides a STIG Repository for each site and

POR)

• Use the same scan credential as used for vulnerability scans

• ACAS cannot resolve the difference between a Windows Member Server and Domain Controller.

ACAS does not interrogate the server to determine if the target is a domain controller. As a result, separate Member Server (MS) and Domain Controller (DC) audit files between different scan policies.

For newer benchmarks that are not MS / DC specific separation is not required.

NOTE: For successful generation of the ASR / ARF formatted report for eMASS consumption, the benchmark must be conducted in the form of a STIG scan utilizing the applicable audit file and policy first.

If this is not completed first, the benchmark will not appear in the list on the report configuration page

CUI 12

3 SecurityCenter Guidance

3.1 ACAS Accounts

3.1.1 User Account Access

Depending on information in a user’s SAAR and ACAS User RFI, an account is created as either a Review account or Scanning account. The account type affects what actions a user can perform inside of SC and may impact expected usability.

Review accounts can read data from Repositories and Scan Results but cannot create or launch active scans.

Review accounts can also create user objects, e.g., credentials or reports, which other users in the group can utilize.

Scanning accounts have the same permissions, as well as the ability to create and launch active scans against assets.

3.1.2 Training

To attain a user account, JFHQ-DODIN requires all ACAS users complete the DISA ACAS Operator and Supervisor Course. Completing all course requirements, passing the exam, and obtaining a certificate of completion are the necessary steps to successfully meet this requirement. For more information on completion of the required courses and necessary enrollment please email:

disa.meade.id.mbx.acas-virtual-training-support@mail.mil.

The online ACAS training located at https://portal.cyberforce.site/ has been retired as of 29 Oct 2021.

Other training opportunities that are not the DISA ACAS Operator and Supervisor Course do not meet the necessary requirement.

Changes to the ACAS baseline, tool capabilities, TASKORD, SOPs, etc., necessitate a 3-year re-training cycle. ACAS users are required to maintain a valid certificate of completion.

Contact the Subscriber Engagement Team for any additional requirements which may be necessary, contact information is provided in Section 9.2 Technical Points of Contact.

3.1.3 Groups

Users should specify on their User RFI the appropriate group that is desired for assignment. It is important to note that a user cannot belong to more than two groups and that user permissions cannot be spread across differing groups.

3.1.4 Initial Login

Once the user initiates the account process with the Subscriber Engagement Team, and the account request is processed, the DHA CyOC ACAS Team will execute account creation. Once created, the DHA CyOC ACAS Team will distribute a set of e-mails to the user with login instructions. Failure to utilize these temporary credentials in a timely manner will result in the account becoming deactivated.

Upon initial login, there will be a dialog box to map the utilized Common Access Card (CAC) / Personal Identity Verification (PIV) certificate to the account. To facilitate two-factor authentication (2FA), it is expected, and required that users associate their certificate with their login credentials.

Once certificate association is complete, it is also required to change the account password from the provided one—skipping this step may result in either a loss of access to the account or a blank screen which presents itself with classification banners on top and bottom. Either of these situations requires intervention by the DHA CyOC ACAS Team.

CUI DHA ACAS Scanning Guide Version 2.7

CUI 13

mailto:disa.meade.id.mbx.acas-virtual-training-support@mail.mil https://portal.cyberforce.site/

3.1.5 Deactivated Accounts

In compliance with the Risk Management Framework (RMF) STIG requirement regarding accounts with no activity for 35 days or more, inactive ACAS accounts will be deactivated and will be deleted if remaining in this state for an excessive period. To comply with this requirement and to avoid a disruption in service, please be sure to login to accounts within the required time period.

NOTE: Deletion of an ACAS account permanently removes all ACAS objects owned by the account such as scanning credentials, asset lists, scan jobs, reports, etc. Once deleted, such objects are not recoverable. If you rely on an ACAS object that has been shared to you by another user in your group, your scanning/reporting efforts could be negatively impacted if the owning account is deleted. To avoid such a disruption, please consider making a copy of any shared object that you or your team require for scanning/reporting efforts

3.2 Credentials

Credentials are reusable objects that facilitate a login to a scan target. Various types of credentials with different authentication methods may be configured for use within scan policies. SC supports the use of an unlimited number of Windows credential sets, four SNMP credential sets, an unlimited number of SSH credential sets, and database credential sets. Every effort should be made to launch active scans using valid credentials.

Credentialed scanning authenticates into the target device by the scanner to run commands locally to search for vulnerabilities or gather information. Some examples are logging in to run the netstat command, read the Registry, or grab file information such as the version, .dlls or .exe files.

A successful credentialed scan depends on two critical yet distinct conditions:

• Successful authentication

• Enabling of local security checks.

3.2.1 Credential Ownership

Credentials will be unique to the device and in many cases, the group that owns the devices. It is important to work with system owners and administrators to ensure correct credentials are configured for the target device and available to SC for desired scans. Credentials created by an administrator user are available to all organizations, while those created by organizational users are only available to their organization. Users can share credentials with other users, allowing them to scan remote hosts without knowing the credentials of the host.

NOTE: Credentials ARE NOT the user’s ACAS login credentials, but rather credentials provided by the system owner for ACAS scanning purposes

3.2.2 Authentication Protocols

Remote targets authenticate utilizing several different protocols. Commonly used protocols include SSH, SMB, SNMP, and HTTPS. It is possible for a target to have multiple protocols available for authentication, and authentication over each protocol can fail or succeed independently of other protocols. This means that it is possible to see both Authentication Success and Authentication Failure for the same target, if for example authentication to an ESX server succeeded over SSH but failed over the SOAP API over HTTPS.

Typically a credentialed scan will have Plugin 19506 Nessus Scan Information present with the vulnerability text “Credentialed checks: yes” present. Section 5 Troubleshooting Scans contains more

CUI 14

in-depth troubleshooting and information for determining credentialed scan success.

3.2.3 Create Credentials

Steps to create a credential:

a) Log in to Tenable.sc

b) Click Scans > Credentials

c) Click Add

d) In the Database, SNMP, SSH, or Windows database type section, click the tile for the specific method you want to configure

e) In the Name box, type a name for the credentials

f) In the Description box, type a description for the credentials

g) Type or select a Tag (Optional)

h) Configure the options. While there are many methods to configure ACAS scanning accounts the username password combination is the most common. These are described below for SSH and Windows:

Windows

Username The username for a user on the target system.

Password The password associated with the username you provided.

Domain Leave default unless specifically needed for login.

Table 5: Windows Credential Setup

SSH

Username The username for a user on the target system Password The password associated with the username you provided.

Privilege Escalation

The privilege escalation method you want to use to increase users' privileges after initial authentication. Your Privilege Escalation selection determines the specific options you must configure.

Table 6: Linux Credential Setup

i) Click Submit.

NOTE: When using escalation privileges, if the usernames are the same then leave username under escalation Username blank

CUI 15

Figure 1: SSH Password Credential

For further information on configurations needed for credentials and systems to achieve successful scanning please refer to Section 3.3 Required System Configuration for a Successful Scan. For assistance setting up any of the non-standard credentials please contact the DHA CyOC ACAS Team

3.2.4 Additional Creation Tips

3.2.4.1 Domain credentials vs. local credentials

If adding a Windows credential that is part of a domain, you must enter the username and domain information into the input fields labeled for each piece.

NOTE: If domain information is combined into the username field as domain / username, the scan will not function properly; these two pieces of information must be separated into their component fields

The actual domain name is only required if an account name is different on the domain from that on the computer. It is entirely possible to have an Administrator account on a Windows server and within the domain. In this case, to log onto the local server, the username of Administrator used with the password of that account. To log onto the domain, the Administrator username would also be used, but with the domain password and the name of the domain.

3.2.4.2 SSH username/password vs. certificates

SSH credentials are used to obtain local information from remote Linux, UNIX, and Cisco IOS systems.

SecurityCenter encrypts stored credentials using the AES-256-CBC algorithm. Regular username/ password can be utilized as one method or certificates can be utilized by uploading the User Certificate and Private Key files after inputting the username. These keys will be either RSA or DSA Open SSH.

3.2.4.3 Kerberos credentials for Domain Controllers

Kerberos credentials are required when scanning Active Directory managed endpoints.

CUI 16

Kerberos is a ticket-based system integrated in Microsoft’s Active Directory and available via many other enterprise authentication systems. Kerberos-based authentication allows for several benefits over traditional username/password credentials:

• There are no passwords used in the endpoint authentication process. Therefore, there is no risk of a password being intercepted or compromised while scanning

• Both the client and the server mutually authenticate

• Kerberos leverage tickets to grant a user/service the ability to authenticate. These tickets have specific timestamp and lifetime attributes to limit usability

• A Kerberos KDC system provides a directory service to centralize credential management. For

Microsoft Windows environments the KDC is likely the Active Directory implementation

• Create a Windows Kerberos or SSH Kerberos type credential in Tenable.sc.

Required Kerberos Credential Attributes for Windows

Username Account in MS Active Directory; this must have sufficient rights/privileges for scanning

Password Password to authenticate to AD implementation Domain MS Active Directory domain

KDC Host Key Distribution Center server IP or FQDN KDC Port Port number, typically 88

KDP Transport TCP or UDP, typically TCP Table 7: Windows Kerberos Attributes

Required Kerberos Credential Attributes for

SSH

Username Account in LDAP implementation; this must have sufficient rights/privileges for scanning

Password Password to authenticate to LDAP implementation Domain Kerberos domain

KDC Host Key Distribution Center server IP or FQDN KDC Port Port number, typically 88

KDP Transport TCP or UDP, typically TCP Realm KDC Realm

Privilege Escalation Optional, escalation method on the endpoint Table 8: Linux Kerberos Attributes

3.2.5 ESX/ESXi SOAP Authentication

Credentials for scanning VMware ESXi/Vsphere are configured differently than normal credentialed scans.

To be considered a successful scan, SOAP API authentication into an ESX/ESXi device over HTTPS is required, and achievable through proper configuration of a dedicated scan policy. The difference from normal policy setup is within the authentication field:

• Select “Add Authentication Settings”

• Select “Miscellaneous” from type

• Select the type of ESX host you are connecting to (i.e., ESX or vCenter)

• Hit Select

• Input credentials for the device.

CUI 17

After completing all other sections, create an active scan utilizing this policy. Because of this unique setup, it is not necessary to allow SSH access from the remote Nessus scanner.

3.2.6 Adding Credentials to Scans

To add a credential to a scan, select credential from the left side of the active scan setup window. Click the type of scan credential to add to the scan from the drop-down box. Then click the specific credential to add from the list by clicking the name. Credentials can be searched using the text search option. Only credentials that match the type selected appear. When you hover over a credential, the information icon appears which displays information about the credential such as the name, description, type, and owner.

After you select the credential, click the check mark to add it to the scan template. Clicking the X removes the credential from the list of added credentials.

3.2.7 Non-Credentialed Scanning

Non-credentialed scanning runs checks externally. It does not log into the device and tries to gather information by probing the host and seeing how it responds. Non-credentialed scans rely on items like http/ftp and telnet banner grabs as such, it is not as accurate as a credentialed check.

NOTE: ETERNALBLUE/ETERNALROMANCE and Heartbleed are good examples of remote exploits, which can be checked without credentials

3.3 Required System Configuration for a Successful Scan

In order for a credential to allow Nessus to perform local security checks, there are several account and asset (scanning target) configurations necessary to be in place. The below list is not exhaustive but is built from the DISA ACAS Best Practice Guide v5.4 and DHA CyOC ACAS Team experiences.

3.3.1 General Configurations

The following configurations need to be true of a system and the account used to access it:

• System must be configured to allow scanning account unrestricted access to the entire OS

• Account must be configured with SYSTEM/root (or equivalent) permissions

• Any host intrusion protection system (IPS) needs to whitelist the scanner IP and account.

Beyond these general stipulations some OSes have unique conditions, which are necessary for successful scans. These conditions are explored further in the following sections. If further troubleshooting of system or account configuration is necessary, please contact the DHA CyOC ACAS Team. Contact information is provided in section 9 Troubleshooting Assistance.

3.3.2 Windows

For proper scanning to occur within a Windows asset, the following configurations are required:

• Administrator-level account (domain or local) in the system’s local Administrators group

• Remote Registry service set to either Automatic or Manual

• WMI service enabled o Specific to 10, 2008, 2008 R2, 2012, 2012 R2, and 2016 Windows Firewall

• Ports 139 and 445 must be open between the host and scanner

• Scanning account able to access the default admin shares (ADMIN$, C$, IPC$)

• File and Printer Sharing enabled under Windows Firewall settings

CUI 18

o Specific to Windows 10 and Windows Server 2008/2106/2019

• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilt erPolicy key must be set to DWORD value of 1

• Local Group Policy Computer Configuration > Windows Settings > Security Settings > Local Policies

> Security Options > Network access: Sharing and security model for local accounts should be set to “Classic – local users authenticate as themselves”.

For Windows 10 assets, please also consider the following Registry setting:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\Sm bServerNameHardeningLevel key must be set DWORD value of 0 For Windows Server 2016 assets using the Protected Users group for scanning domain controllers:

• Account credentials in ACAS must be configured as Windows > Kerberos authentication, not

Windows > Password, with the primary KDC for the account provided For Windows 10 machines version 1709 or higher, that are not members of a domain

• Registry setting change to enable authenticated scanning: 'Computer Configuration\Windows

Settings\Security Settings\Local Policies\Security Options\Microsoft network server: Server SPN target name validation level to Off.

3.3.3 Linux

For proper scanning to occur within a Linux asset, the following configurations are required:

• SSH service running and port 22 open

• Scanner must be in /etc/hosts.allow (or similar) file for remote sshd access

• Root access for scanning account or ability for the scanner to escalate privileges as needed to run system commands (su, sudo, su+sudo, pbrun, dzdo, or k5login).

NOTE: Best practice is to utilize a DSA / RSA public-private key pair with a passphrase, though a username and password can be configured for access

For Red Hat-based OSes (i.e. Enterprise Linux, Cent OS and Fedora) ensure:

• /cat/etc/redhat-release is readable by the scanning account.

3.3.4 Network Devices

For proper network device scanning to occur, the following configurations are required:

• Cisco: needs privilege level 15 or enable-level access.

3.4 Active Scan Configuration

To add an active scan:

1. Log in to Tenable.sc via the user interface

2. Click Scans > Active Scans

3. Click Add

4. Click General

5. Type a Name for the scan

6. (Optional) Type a Description for the scan

7. Select a Policy for the scan

CUI 19

8. (Optional) If you want to schedule the scan to run automatically, select a Schedule for the scan

9. Click Settings

10. If prompted, select a preconfigured Scan Zone for the scan

11. Select an Import Repository for the scan

12. Select a Scan Timeout Action for the scan

13. Select a Rollover Schedule for the scan

14. Enable or disable the Advanced options

15. Click Targets

16. The page updates to show the required options for that target type

17. Select a Target Type for the scan

18. Select one or more Assets and/or IPs / DNS Names for the scan

19. (Optional) In the Credentials section, if you want to configure credentialed scanning, click Add

Credential. Then:

a. In the drop-down boxes, select a credential type and a preconfigured credential

b. Click the check mark to save your selection.

20. (Optional) If you want to configure multiple credentials for the active scan, repeat step 19.

3.4.1 Best Practice Active Scan Settings

The following sub-sections relate recommended configurations for scans as related in the latest DISA ACAS Best Practice Guide.

3.4.1.1 Basic Settings

• Scan Timeout Action: Import Completed Results and Create Rollover Scan

• Rollover Schedule: On Demand.

3.4.1.2 Advanced Settings

• Scan Virtual Hosts (e.g., Apache VirtualHosts, IIS Host Headers): Disabled

• Track hosts, which have been issued new IP address, (e.g., DHCP): Enabled, if DHCP, BOOTP, or other protocols are used, or if hosts transition in and out of the network on a regular basis

• Immediately remove vulnerabilities from scanned hosts that do not reply: Enabled for

TASKORD vulnerability scan, and Disabled (Number of days to wait before removing dead hosts should be greater than the TASKORD defined scan interval) for all other scans that can write into production repositories (repositories used for TASKORD reporting, the site is responsible to ensure they’re gathering and reporting accurate data)

• Max scan duration (hours): Approved for use if set to less than 20 hours. Scans should conclude before the next scheduled SecurityCenter plugin update.

3.4.1.3 Target Selection

It is recommended that Target selection should be based on IP ranges or specific IP address(es). In all cases target selection needs to factor in total IP addresses scanned, actual live hosts, credentials, host availability / utilization, and the allotted scan windows (operationally defined scan time limit).

• Generally, using subnets instead of large selections of IP addresses / hostnames will be more efficient

• Limit the number of scans when possible, fewer scan jobs to import will reduce the burden on the

Tenable.sc (cause SC to recalculate more often)

CUI 20

• Scan should be limited to a /20 network (16,382 IP addresses) in networks where large quantities of IP space is unused. Scans of this size will work best when distributed across 4+ scanners

• A vulnerability scan should not engage more than 4,000 target endpoints

• Group endpoints which are known to be under load (database or application servers), underpowered

(network switches or thin clients), or just respond slowly to being scanned (high scan durations in 19506 plugin text).

3.4.1.4 Active Scan Duration

If a scan is running when the Tenable.sc downloads updated plugins, it can prevent the scanners associated with the running scan from receiving the updated plugins and cause the scan to error out. This can cause a cascading situation where the plugins drift out-of-sync (and TASKORD compliance) but no associated alerts are generated.

Secondarily the longer scans run, the more likely an error may occur. Longer scans also require more resources and time for scan results to be parsed into the appropriate repository.

Lastly when a single scan encompasses large portions of the day, the data contained in the scan results are skewed by when specific IP addresses are interrogated (hosts that are online at 0900 may not be online at 1900 and vice-versa). Scanning servers in the middle of the night may produce logical results, scanning workstation/laptop networks in the middle of the night may produce skewed results. The key is to know what is being scanned when, and to ensure that scans are occurring within safe/logical timeframes.

3.4.2 Email Setting

As discussed in a previous section, due to limitations within the application for encryption of email traffic, the function allowing usage of email traffic out of the application has been disabled. Any attempts to email will fail with no error provided.

3.5 Scan Policy

Per TASKORD 20-0020 and the latest DISA ACAS Best Practices Guide, new scan policies have been uploaded to each Med-COI SecurityCenter. Please test these policies in your respective environments, then update your active scans, and/or create new scans to use these new policies accordingly. These include a vulnerability scan and discovery scan policy named DHA Full Safe Scan - BPG v5.4 – [Date] and DHA Host Discovery - BPG v5.4 – [Date] respectively. These policies will be updated as needed with each new version of DISA’s ACAS BPG scan policy guidance with the intent to create a well-balanced all-encompassing scan for subscriber utilization. The [date] field for each policy will be updated to represent the most recent iteration.

In addition, the DHA Full Safe Scan - BPG v5.4 – [Date] scan policy will include new IAVM Alerts and Bulletins (IAVAs and IAVBs) as they are released by DISA and is safe against common server and network infrastructures that Naval Information Warfare Center Atlantic (NIWC) has deployed throughout the Med- COI network. The DHA CyOC ACAS Team reasonably assures that this scan policy should not affect performance against any standard device against which it is used.

NOTE: It is important to test any potentially fragile devices that may be of concern in a laboratory / testing environment prior to scanning with the full policy

As mentioned in Section 2.1. A DHA STIG template policy is provided by the DHA CyOC ACAS Team, enabling compliance scanning of various OSes and applications as required by JFHQ-DoDIN

CUI 21

DHA ACAS Scanning Guide Version 2.7 TASKORD 20-0020. This Policy is named DHA STIG - Template - BPG v5.4 – [date] and should be copied and modified as needed as per Section 2.6 Compliance Scanning.

For further specifics on the DHA Full Safe Scan - BPG v5.4 – [Date], DHA Host Discovery - BPG v5.4

– [Date] and DHA STIG Policies, please refer to the most recent DISA ACAS Best Practice Guide and

TASKORD 20-0020.

3.6 Dashboards

Tenable.sc has several prebuilt dashboards that can be useful in identifying the quality of scans and the validity of credential access to targets. The DHA CyOC ACAS Team is only able to assist at a high level with these Dashboards and is unable to assist with the custom creation of Dashboards.

3.7 Report Creation

Once a scan has completed, the results are available on the “Scan Results” tab. When the need arises to produce a report for patching, compliance, or troubleshooting efforts, a user can select “Scan Results” to generate a CSV report, which opens in Excel, or a PDF report. This is accomplished by selecting and opening the desired scan result, then navigating to the “Options” button in the top right corner. Scan results are also downloadable as a. nessus file by selecting “Download” for an applicable scan on the main “Scan Result” menu under the cog wheel. From this same location scan results can also be sent to a preconfigured report through the “Send to Report” option.

Reports may also be configured through the “Reports” tab in customizable formats with user-defined fields.

Utilizing the “Add” button will allow a user to select a desired template or create a custom PDF, Word or CSV document utilizing a variety of charts, tables, or matrices to display scan or repository information.

Depending on the report type (and its complexity), completion can take seconds or hours to generate.

SecurityCenter completes report processing in a queue format, i.e., the application runs one report at a time, in the order the report generation requests are received. CSV reports will execute quickly and have a relatively small size. These reports are produced in a readable format. PDF reports form by constructing a framework around the vulnerability data. These can take much longer to execute, depending on complexity.

Tenable provides many varied templates for reports, depending on the user’s specific needs. Where possible, the DHA CyOC ACAS Team advocates use of the CSV report format, as this report type takes less time to execute than a PDF/RTF report with a similar definition.

With this in mind, it is useful to design queries to aid in report generation. If specific filter settings are constantly used, creating a query out of the filter may be more efficient with time. Because of the varied areas in which they can be used, queries should be made as general as possible to retain usefulness.

Creation and use of ASR/ARF files, which feed into the Continuous Monitoring and Risk Scoring (CMRS) site can be found in the following section (Section 4).

4 CMRS & eMASS

4.1 CMRS Ecosystem

The CMRS ecosystem utilizes Cyber Operational Attribute Management System (COAMS), SecurityCenter, ePO, CMRS, and eMASS to publish and track vulnerability Compliance. Section 4.2 will cover COAMs Registration. Section 4.3 will cover SecurityCenter and direct publishing to CMRS/eMASS.

CUI 22

Figure 2: CMRS Ecosystem

4.2 COAMS Registration

Cyber Operational Attributes Management System (COAMS) assigns a unique identifier number to a system for reporting capability. COAMS is used for asset reporting into CMRS. The agency assigns the unique identifier which is then applied to assets and eMASS. To request a COAMS ID email DHA Compliance Team dha.jbcharleston.j-6.mbx.compliance-team@mail.mil.

4.2.1 Assign COAMS ID in eMASS

To properly link a system COAMs ID in eMASS follow the below steps:

a) Log In to eMASS

b) Open System Record

c) Click on System Tab

d) Click on System Details

e) Click edit System Details

f) Scroll down until COAMS System Affiliation

Figure 3: COAMS System Affiliation

g) Type in System Full System Name

CUI 23

h) Select System Name

i) At bottom of page, Select Save.

4.2.2 COAMS Asset List

To ensure the…