Managed Risk Scanner FAQ
- Scanner installation and configuration FAQs
- Q: Where in the network should I deploy the scanner?
- Q: Who installs the scanner?
- Q: Who maintains the scanner?
- Q: How long does the hardware scanner installation take?
- Q: What are the physical space and power requirements of the hardware scanner?
- Q: Does the physical scanner support scanning multiple non-routable networks?
- Q: Do I need to configure the scanner?
- Q: Do I need to open a port in the firewall for the scanner?
- Q: Can I have multiple scanners for different parts of my network?
- Q: Can we configure our own NTP server for the scanner?
- Q: What virtual environments are supported for the virtual scanner?
- Q: What kind of impact does the scanner have on the network and systems?
- Scanner operation FAQs
- Q: What tests does the scanner perform?
- Q: What does the scanner do during a scan?
- Q: What kind of devices does the scanner scan?
- Q: Does the scanner scan over IPv6 networks?
- Q: Does the scanner exploit found vulnerabilities?
- Q: How resource-intensive is the scan on the target machine?
- Q: Should I stagger scan times based on location?
- Q: When is continuous scanning applicable or preferred?
- Q: How often are IVA discovery scans run?
- Q: Are there best practices for scan schedules?
- Q: How long does a typical scan take per device?
- Q: How should I configure the scanning schedule?
- Q: What is the difference between the default discovery scans, like Nmap, and a ping-only scan?
- Q: Does the scanner scan for or detect the SSL/TLS versions that a website supports?
- Q: Why is the scanner failing to resolve a host name?
- iVA scanning FAQs
- Q: Does the iVA Scanner scan for common passwords like “admin” or “password” to see if any devices have default or easily guessable passwords on them?
- Q: If scheduled scans are configured, why is host identification scanning occurring outside of the schedule?
- Q: How are the credentials that are used in credential scanning stored?
- Q: Does vulnerability scanning work if asset identification scanning is disabled?
- Q: How long does it take to scan my environment with continuous scanning?
- Q: Can I scan AWS or other cloud-hosted devices?
- Q: Can we schedule iVA scans of devices or IP addresses on a daily, monthly, or quarterly basis?
- Q: What is the underlying technology used for iVA scanning?
- EVA scanning FAQs
- Scanner troubleshooting FAQs
- See also
Overview Direct link to this section
This document contains frequently asked questions (FAQ) about the Arctic Wolf® Managed Risk® Scanner, including Internal Vulnerability Assessment (iVA) scanning.
See Managing Risk Scanner configuration in the Risk Dashboard User Guide for more information about Risk Scanner configuration.
Contact your Concierge Security® Team (CST) if you have questions that are not covered here.
Scanner installation and configuration FAQs Direct link to this section
Q: Where in the network should I deploy the scanner? Direct link to this section
A: You can place the scanner anywhere within the network to scan any device that has layer 3 (L3) reachability. If the scanner can ping a device, it can scan that device. This includes off-site devices that are connected to the customer network through VPN.
Q: Who installs the scanner? Direct link to this section
A: An Arctic Wolf employee and your IT staff install the scanner, depending on whether the customer chooses the virtual machine (VM) or physical scanner.
Q: Who maintains the scanner? Direct link to this section
A: Arctic Wolf owns the scanner hardware or VM software instance provided to enable network discovery of threats and vulnerabilities. Therefore, Arctic Wolf maintains scanner service, including regular software updates and scanner warranty.
Q: How long does the hardware scanner installation take? Direct link to this section
A: The physical installation takes minutes. To physically install the hardware scanner, you need to rack mount the scanner, and connect an Ethernet cable and power cord.
Once powered on, the scanner connects to Arctic Wolf servers within minutes.
Q: What are the physical space and power requirements of the hardware scanner? Direct link to this section
A: The physical scanner hardware is a 1RU rack-mountable server with these dimensions in inches: 1.7 high x 16.8 wide x 14.0 deep. A 200-W, low-noise AC power supply with power factor correction (PFC) powers the scanner.
Q: Does the physical scanner support scanning multiple non-routable networks? Direct link to this section
A: No, even though the physical scanner has multiple hardware network ports, the software is only configured to allow one primary network, or one network interface card (NIC). Multiple physical, non-routable networks are not supported because that configuration would cause the scanner itself to become a bridge between networks that are otherwise wholly separated, which is a violation of secure design principles.
Q: Do I need to configure the scanner? Direct link to this section
A: The scanner can search for hosts on its network and begin scanning without configuration. You can also easily configure the scanner to scan or ignore any other routable host(s) or network(s), if desired.
Q: Do I need to open a port in the firewall for the scanner? Direct link to this section
A: The scanner, both physical and virtual, communicates to the Arctic Wolf cloud infrastructure. We recommend that you create a defined outbound security rule from the scanner IP address to all necessary Arctic Wolf scanner IP addresses to ensure proper functionality. To see the complete list of IP addresses that you must allowlist, go to the Arctic Wolf Portal, and then click Account > Arctic Wolf IP Addresses. The IP addresses that must be allowlisted are listed under If you are a Managed Risk (MR) customer.
Q: Can I have multiple scanners for different parts of my network? Direct link to this section
A: Yes, you can deploy multiple scanners to scan separate parts of your network, such as a co-lo or remote office which do not have direct connectivity, or you otherwise do not want to scan from the location of the main Ssanner.
Q: Can we configure our own NTP server for the scanner? Direct link to this section
A: No, you cannot configure your own NTP server for the scanner. The scanner is configured to reach out to a pool of global, publicly available NTP servers. This is to ensure consistency in case of localized issues.
Q: What virtual environments are supported for the virtual scanner? Direct link to this section
A: See Managed Risk Scanner Installation and Configuration Guide for all requirements.
Q: What kind of impact does the scanner have on the network and systems? Direct link to this section
A: The network scanner primarily uses two tools to detect hosts and conduct vulnerability scans:
Nmap — Very lightweight, sending only Internet Control Message Protocol (ICMP) and synchronize (SYN) packets for port scanning.
OpenVAS — Also lightweight, typically sending and receiving <400 kB/sec of bandwidth on a typical network. Depending on the hosts that are scanned and what services they are running, occasional bursts of bandwidth to ~1 MB/sec may occur.
The actual impact of processing on the target systems is typically negligible. Some older systems, such as consumer-grade printers or network Internet-of-Things (IoT) devices, may have denial of service vulnerabilities that are revealed when scanned.
Scanner operation FAQs Direct link to this section
Q: What tests does the scanner perform? Direct link to this section
A: The scanner runs network vulnerability tests (NVTs) that provide:
Remote version detection — The scanner connects to the host services and collects self-reported version information, to verify if hosts are using versions with known vulnerabilities.
- These NVTs may miss self-applied patches without version numbers.
- When services are locked down or otherwise configured not to self-report versions, the scanner may not detect these vulnerabilities.
Crafted packet and response check — The scanner sends a specific series of packets that test if a vulnerability exists based on the response from the host.
Credentialed detection — If configured, the scanner connects using customer-supplied credentials to obtain a list of installed software, and then the version check NVTs run against that list.
Tip: This detection can find vulnerabilities that are not remotely exploitable, such as an Adobe Acrobat vulnerability.
Weak or default password checking — Services that have a sign-in prompt, such as SSH or web pages, or services that collect credentials as part of protocol, like SMB, are tested against default or weak passwords, like
Note: These scans can negatively impact services with lockout policies, so you may need to disable these types of scans on those devices.
Q: What does the scanner do during a scan? Direct link to this section
A: Using the provided schedules, the scanner gets the list of targets to look for. Using the list of targets and the data from the DenyList, it attempts to determine if relevant machines are online by sending out Address Resolution Protocol (ARP), Internet Control Message Protocol (ICMP), and Transmission Control Protocol (TCP) packets and monitoring for any responses.
In almost all cases, the scanner runs a full scan that:
Fingerprints web server software
Analyzes HTTP headers for security misconfiguration
Checks the security of HTTP cookies
Checks the SSL certificate of the server
Checks if known vulnerabilities are affecting server software
Analyzes robots.txt for interesting URLs, such as /admin or other restricted pages
Checks whether a client access file exists and if it contains a wildcard entry such as clientaccesspolicy.xml or crossdomain.xml
Discovers server configuration problems such as directory listing
Checks for SQL injection
Checks for cross-site scripting
Checks for local file inclusion and remote file inclusion
Checks for operating system (OS) command injection
Finds administrative pages
Checks for sensitive files such as archives, backups, certificates, or key stores, based on hostname and some common words
Attempts to find interesting files or functionality, such as restriction or permission concerns
Checks for information disclosure issues
Checks mail servers for SMTP problems, including mail relay
Q: What kind of devices does the scanner scan? Direct link to this section
A: The scanner can scan all device types on a network, including networking gear like switches and routers, printers, cameras, phones, and so on. However, scanning some devices can cause unintended behaviours, including significant issues to production environments if the scanner is configured to scan specific devices. Therefore, we recommend scanning only workstations and servers.
Here are some devices to avoid scanning:
- Printers, especially large scale printers
- Medical devices
- Internet-of-Things (IOT) devices
- VoIP phones
- Uninterruptible Power Supplies (UPSs)
- Small network appliances
- Old devices that likely were not built to handle frequent scanning activity
- ESXi servers — Scanning these servers may lock you out and force you to restart their
Q: Does the scanner scan over IPv6 networks? Direct link to this section
A: No, the scanner does not support scanning over IPv6 networks.
Q: Does the scanner exploit found vulnerabilities? Direct link to this section
A: These are the types of network tests that the scanner runs:
Host identification tests — ICMP and TCP SYN packets are sent to see if a specific host is connected to the network and responding to basic network connectivity checks.
Service detection tests — TCP SYN packets are sent to detect what services are responding on which ports.
Service version tests — The tests connect to a service on the host and determine the version of the service that is running, if possible. Any vulnerabilities for that specific version are checked against a database of known vulnerabilities and matches are reported.
Exploit tests — The tests connect to a service, wait for a response, and then use that response to send a specifically-crafted packet to determine if a particular vulnerability is exploitable.
Default credential tests — The tests connect to a service and attempt to login using known and/or default credentials for that service.
Note: The scanner never exploits a vulnerability discovered on a host. The scanner determines if a vulnerability exists and then drops the connection to that host or service.
Q: How resource-intensive is the scan on the target machine? Direct link to this section
A: Managed Risk scans have a very low impact. Users should not notice any impact on the target machine during scanning.
Q: Should I stagger scan times based on location? Direct link to this section
A: You can configure scans based on your preference, including location. You may prefer to perform workstation scanning during the day and server scanning overnight. Scans always run in the order that they are listed on the Risk Dashboard. See Risk Dashboard User Guide for more information.
Q: When is continuous scanning applicable or preferred? Direct link to this section
A: Continuous scanning enables continuous visibility and the immediate discovery of new devices and vulnerabilities that enter the network.
Continuous scanning is applicable to iVA scanning and host-based scanning, and is a preferred method because it provides insight that point-in-time vulnerability scans do not. Specifically, things happen in between those point-in-time scans that are missed if you are not continuously scanning.
Q: How often are IVA discovery scans run? Direct link to this section
A: Nmap scans start five minutes after the previous Nmap scan completes. Precise timing depends on how long it takes for the scan to complete. If Nmap scans take 60 seconds to complete, they would run every six minutes (5 + 1 minutes). If it is a complex network and the Nmap scan takes 15 minutes to run, the Nmap scans would run every 20 minutes (5 + 15 minutes).
Q: Are there best practices for scan schedules? Direct link to this section
A: We suggest starting the scans when a member of your team is available. That way, you can add devices to the DenyList or turn off scanning if a host reacts poorly to being scanned. Scanning schedules should help prevent devices from going offline or prevent scanners from overwhelming devices with HTTP requests during business hours.
Q: How long does a typical scan take per device? Direct link to this section
A: The scan can take up to an hour to complete but is usually faster. Scan time depends on the number of open ports and network vulnerability tests (NVTs) that the scan runs against the host. By default, six hosts can be scanned at the same time.
Note: After two hours, scans timeout so they quit scanning that particular asset.
Q: How should I configure the scanning schedule? Direct link to this section
A: You should only configure private internal IP addresses for the scanner to scan. Do not add anything outside of the ranges listed here: https://en.wikipedia.org/wiki/Private_network.
Note: An IP range such as 192.168/16 is the internal space, whereas 18.104.22.168 is a public internet address, and should not be configured to be scanned.
- Scanning subnet ranges
/24and smaller, excluding
/20. Scanning these larger subnet ranges may not complete in a reasonable timeframe.
- Limiting the host count to 2048 per scanner.
With the assumption that each scan takes about 12 minutes to complete per device and with 6 hosts/devices scanned by scanner at same time, this table provides estimates for how long it takes to scan specific subnet sizes:
|CIDR||Subnet mask||Total IP addresses||Minutes to scan||Hours to scan|
Q: What is the difference between the default discovery scans, like Nmap, and a ping-only scan? Direct link to this section
A: The default Nmap scan is used to find what hosts exist, which we should scan for vulnerabilities. The tests performed include:
Address Resolution Protocol (ARP) scan
Internet Control Message Protocol (ICMP) echo
Transmission Control Protocol (TCP) acknowledge (ACK) on port 80
TCP synchronize (SYN) on port 443
TCP SYN on more than 1,000 ports
Ping Only mode restricts host detection scans to the use of only ICMP echo, which means that hosts that do not respond to a ping are not detected.
Q: Does the scanner scan for or detect the SSL/TLS versions that a website supports? Direct link to this section
A: The scanner looks for weak TLS ciphers. It does not look at SSL registry information or test against failback methods.
Q: Why is the scanner failing to resolve a host name? Direct link to this section
A: The scanner does not perform asset profiling, including host name resolution if:
- The host was not detected during the identification phase.
- The host is on the DenyList for the scanner.
If you are seeing continued failures to resolve the name for a visible host, contact Arctic Wolf so that we can attempt manual tests on the scanner.
Note: We recommend adding all DNS servers to the Host Collection DNS Servers in the Risk Dashboard.
iVA scanning FAQs Direct link to this section
Q: Does the iVA Scanner scan for common passwords like “admin” or “password” to see if any devices have default or easily guessable passwords on them? Direct link to this section
A: There is an option on the iVA Scanner to perform brute-force scans, where common or default usernames and passwords are attempted. We limit the number of passwords attempted to the most common ones, and tailor the list based on the type of device detected to limit causing account lockouts. Additionally, Managed Risk (MR) performs Account Takeover (ATO) scans to identify instances of passwords, credentials, or other personally identifiable information (PII) that were exposed to malicious actors.
Q: If scheduled scans are configured, why is host identification scanning occurring outside of the schedule? Direct link to this section
A: The iVA Scanner maintains an active list of all targets and decides the targets and order for scanning during the scheduled vulnerability scan, based on the latest results. Host identification scanning is permitted outside of the vulnerability scanning window so that it does not limit the time remaining in the scheduled window for vulnerability scans.
Q: How are the credentials that are used in credential scanning stored? Direct link to this section
A: When a sensor first comes online and registers with our system, it generates a unique public/private cryptographic key pair using RSA with a 4096-bit key. Part of the registration process for the new sensor is to publish the public component of this key pair to our servers. The private key is never transmitted off of the sensor.
When a credential is added through the Risk Dashboard for credentialed scanning, the data is divided into public and private fields. Public fields include things such as the hosts that a given credential is for, the display name of the credential that is not the username, and a comment for easy viewing on the Risk Dashboard. Private fields include usernames, passwords, certificates, keys, and any information that could be used as a component of the actual credential.
The private fields are encrypted with a unique AES 256 key, or session key, which is in turn encrypted with the public key of a target sensor. This encrypted data package is then paired with the public fields and stored in our database. A copy of this data is sent to the target sensor over a secure channel that again uses unique AES 256 session keys secured with the sensor public key.
The public information is stored in the database for use with the Risk Dashboard, and the private information is stored for re-publishing to the sensor if the sensor ever requests it. Once stored in the database, there is no way for any device other than the sensor to read the private fields of a credential, and they cannot be recovered or moved to another sensor.
When the sensor receives the encrypted credential message, the message is stored to disk using the existing encryption before it is decrypted, and then it is decrypted only as required during use. It is never stored on disk in a decrypted form.
Q: Does vulnerability scanning work if asset identification scanning is disabled? Direct link to this section
A: No, you must enable asset identification scanning to perform vulnerability scanning. You can make these adjustments on the Scanner Config page of the Risk Dashboard. See Risk Dashboard User Guide for more information.
Q: How long does it take to scan my environment with continuous scanning? Direct link to this section
A: As a rough guideline, the Arctic Wolf 200 series physical scanner and the virtual scanner can scan approximately 150 devices in a 24-hour period. The 100 series physical scanners scan approximately 75 devices in a 24-hour period.
If you limit the scan window and you have a lot of devices to scan, the scan may never fully complete in the time window that you set. Since a scan can range from 2–200 minutes, we do not terminate scans at the end of a window to prevent a situation where some longer-running scans never complete. For example, if a customer sets several 60-minute windows and they have a host that takes 70 minutes to scan, the scan always fails. So we define the start of the scan, relying on the fact that the majority of scans take only 5-15 minutes to complete.
Q: Can I scan AWS or other cloud-hosted devices? Direct link to this section
A: Various cloud providers have different policies around when and if vulnerability assessments are allowed according to their respective Acceptable Use Policies (AUPs):
- AWS — AWS has a strict AUPs around vulnerability scanning, but you can deploy a vScanner for AWS to scan AWS resources. See Install a vScanner in AWS for steps.
- Digital Ocean — Digital Ocean has lightweight AUPs but we highly recommend checking with Digital Ocean to prevent any unintentional service interruptions.
- Others — Discuss and/or check with the appropriate cloud hosting provider on their AUP and vulnerability assessment.
Q: Can we schedule iVA scans of devices or IP addresses on a daily, monthly, or quarterly basis? Direct link to this section
A: You can schedule iVA scans to run monthly, weekly, daily, or continuously. This frequency is configurable on a network-by-network or host-by-host basis.
Q: What is the underlying technology used for iVA scanning? Direct link to this section
A: OpenVas is the underlying technology used for iVA scanning.
Note: Arctic Wolf uses a variety of effective cybersecurity technologies to ensure the security of our customers. Therefore, underlying technologies may change over time as other technologies become available.
EVA scanning FAQs Direct link to this section
Q: How many ports are scanned during an EVA scan? Direct link to this section
A: The Nmap or EVA scan uses the top 1,000 common ports. See Nmap Network Scanning Overview on the Nmap website for more information.
Q: How does the EVA Scanner determine if a host is online before performing a vulnerability scan? Direct link to this section
A: The EVA Scanner uses the results of an initial Nmap scan confirm that we received port information, even if the ports are reportedly closed, and then proceeds with the EVA scan.
Q: How often are EVA discovery scans run? Direct link to this section
A: Nmap discovery scans run before every scan, which occur monthly by default, but can also be requested.
Q: Can we schedule EVA scans of devices or IP addresses on a daily, monthly, or quarterly basis? Direct link to this section
A: By default, we run EVA scans on a monthly basis. You can adjust the frequency of EVA scans to weekly, but we do not recommend this approach because it increases the risk of firewall bans from generating too much noise.
Scanner troubleshooting FAQs Direct link to this section
Q: Why does the scanner show results for itself in the Risk Dashboard? Direct link to this section
A: If the scanner IP address is not added to the AllowList on the Scanner Config page of the Risk Dashboard, the scanner IP address can appear in scan results in the Risk Dashboard. To see the complete list of IP addresses that you must allowlist, go to the Arctic Wolf Portal, and then click Account > Arctic Wolf IP Addresses. The IP addresses that must be allowlisted are listed under If you are a Managed Risk (MR) customer.
Q: Why did I see a bandwidth spike during a scan? Direct link to this section
A: Spikes in bandwidth usage may be related to:
Webservers with a large 404 page — A webserver configured to use a custom 404 page, especially if it contains images, can often be large. The scanner checks for many URLs on webservers that do not exist and a large 404 page transmitted in response can generate large spikes in bandwidth.
Misconfigured and/or poorly behaving hosts — Some services may immediately respond to an initial connection with a large volume of unsolicited data, generating a spike in bandwidth.
Stateful east-west firewalls — Networks where Nmap scans travel through a firewall need to be configured to handle the Nmap traffic, or have a separate risks scanner deployed in the network segments. See iVA User Guide for more details.