About Alert Logic Scans

A scan detects and identifies network and host vulnerabilities in your environment. Scans can perform external attack simulations as well as comprehensive vulnerability checks including registry evaluation. Alert Logic scans can also help you meet PCI compliance requirements.

This topic describes the types of scans that are supported, best practices for running successful scans, and how to configure and manage scan definitions and results. A suggested workflow for using Alert Logic vulnerability scans to meet your PCI compliance requirements is also provided.

Scan types

The following table describes the types of supported scans:

Scan Type Description
internal

An internal scan runs from an Alert Logic appliance in your environment. When you define a scan, you can specify credentials to use with the internal scan. If you provide credentials, Alert Logic can log on to each host on your network and collect information about the host while it performs comprehensive vulnerability checks including registry setting evaluation. If you do not provide credentials, Alert Logic scans your network without logging on to each host and performs as many checks as possible.

external An external scan runs from the Alert Logic data centers against your environment. This type of scan simulates attacks from outside your network and identifies potential issues from these attack types.
PCI A PCI scan is a special type of external scan that is used specifically for Payment Card Industry (PCI) compliance requirements.

Scanning best practices

When configuring your scans, use the following guidelines to create successful scans and scan results.

Request authorization before scanning cloud-based assets

AWS

Alert Logic performs vulnerability scans, not penetration testing. AWS treats scanning the same as penetration testing, requiring scan clients to fill out and submit a penetration testing request form. This authorization allows AWS to differentiate between testing and a real attack on their systems.

The process and form for requesting authorization from AWS are located here.

Azure

While Azure does not require pre-approval for scanning, clients must comply with their terms and are encouraged to fill out and submit a penetration testing notification form.

The terms and notification form from Microsoft are located here.

Be smart when scheduling scans

Schedule your scans to be both effective and efficient.

  • Scan your servers, firewalls, and routers during off-peak times. To effectively balance scanning resources across your enterprise, configure scanning of data center assets to occur during off-peak times.
  • Do not scan during service windows. Service windows are the times when you do backups, hardware maintenance, or apply patches. Valid scan results require that the server is powered on and not in the middle of a reboot. For best results, scan after you apply patches and not while applying patches.
  • Scan your workstations during working hours. At night, laptops go home and workstations get powered off. Scan laptops and workstations when they are available on your network.
  • Scan new computers before use. Scan new servers before you plug in to the Internet. Time to infection for an unpatched, unprotected server can be less than an hour.
  • Scan often. Security is a moving target that you cannot hit in three month scan intervals. Establish a reasonable schedule that scans as frequently as possible and can be adhered to.

Make sure your scans have time to complete

An incomplete scan yields incomplete results. If your scans cannot finish, you may have undetected vulnerabilities. To get a comprehensive vulnerability assessment, it is imperative that all scans—no matter how lengthy—run to completion. You can affect your scanning throughput by either modifying scan definitions or by increasing scanning capability, as follows:

  • Open your scan window. Because of improvements in scanning technologies, you do not necessarily need to limit your scanning activities to narrow time frames during off-peak hours. It is generally safe to let your scan run during normal business hours without impact to performance or availability of assets. Many customers run their scans continuously.
  • Run open-ended scans. When scheduling your scan, consider leaving the scan end time blank.
  • Split up long scans. Rather than a single, comprehensive scan, use multiple scans. Set several smaller scopes and spread the load across multiple scanners.
  • Run scanners in parallel. If you have multiple appliances, you can run scans in parallel. Running scans in parallel requires spreading scans across multiple appliances.

If scans are taking an unusually long time to complete, there may be other local factors involved. Factors include:

  • Back-end database speed
  • Network connection or infrastructure issues
  • Number of simultaneous connections by the scanner
  • Number of vulnerability checks
  • Client computer/server performance and response time

Know what to scan

Consider what to scan and how often to scan it. Your scanning strategy might require multiple scan definitions with different schedules and frequencies.

  • Scan common ports often, and all ports less often. Use the following recommendations:
    • Scan common TCP and UDP ports often, at least once a week. Almost all new vulnerabilities appear on common TCP and UDP ports.
    • Use authenticated scanning on common ports. This is the best way to lower scan times, reduce false positives, and detect the latest vulnerabilities.
    • Scan all ports infrequently. Scanning all TCP ports and all UDP ports is time-consuming and has minimal benefit over scanning common TCP and common UDP ports.

      As a general best practice, on external systems, disable all UDP ports at the host level, the firewall level, and the router level. Unless you have a specific reason, do not have open UDP ports on your internet-facing systems.

    • Scan frequency recommendations:

      Scan frequencyCommon TCP and UDP portsTypically Vulnerable TCP and UDP portsAll TCP and UDP ports
      Internal scanExternal scanInternal scanExternal scanInternal scanExternal scan
      Daily x    
      Weeklyx  x  
      Monthly  x  x
      Quarterly    x 
      After configuration change    xx
      Suspicion of break or infection    xx
  • Do not scan "all ports open" configurations commonly found on firewalls. To improve security posture, some users implement firewall or router configurations that are designed to slow scans. These configurations are designed specifically to slow down an attacker but will slow down your scans as well. Scanning targets with these types of configurations should not be done as part of regular scanning, but should be scanned individually using an outside vendor tool to assess the effectiveness of the protection mechanism. If you decide to use this protection mechanism, ensure that Alert Logic appliances and external scanners are whitelisted and not affected by the protection mechanism.
  • Configure personal firewalls to allow access by scanner. Where personal firewalls are used for desktops or workstations, credential-based scans are not possible without configuration setting changes. Configure Windows firewalls to allow scanner access on Windows Management Instrumentation (WMI), configure your Linux box to allow access via SSH, and then run a credentialed scan.
  • Define reasonable, non-overlapping scopes.
    • Scan a range of 256–1024 IP addresses at a time. Scanning large IP address ranges (for example, 10.0.0.0/9) will send large amounts of unnecessary traffic to your network which might cause the scan to fail.
    • Avoid configuring multiple scans that overlap IP address ranges. This creates redundant results and extends scan times.
    • Scan DMZ, internal servers, and workstations separately, as they will likely need different levels of attention. Also, consider limiting scope by role (for example, database, web, application, QA, test, development, production).

Optimize your scans

When setting up your scans, consider your strategy. Develop an implementation that is particular to your scanning targets and environment.

  • Establish your initial scan window. The time required to complete a scan is greatly dependent on the types of scans you run as well as environmental factors like hosts and bandwidth. If you must set an end time and want to determine the scan window requirements, run a one-off scan without an end time to establish the initial duration, and then add 20-30 percent more time to accommodate future growth. If the scan takes longer than you want, consider reducing scan scope and spreading scans across multiple appliances to reduce time.
  • Be mindful of what you are scanning. In terms of length, not all types of scans are equal. Windows-credentialed scanning takes longer than all other credentialed or non-credentialed scans. Under test scenarios, Windows-credentialed scans have taken up to four times as long as other scans. The web application scanning component used in Alert Logic PCI scans can also run long due to the amount of web pages present and the number of fields on each page, multiplied by the number of sites being scanned. Consider these factors when defining your scans and determining scan windows.
  • Multitask. Scan your servers and workstations separately in a staggered schedule to allow remediation in stages. For example, you can perform remediation on servers while scans on workstations continue to run.
  • Try not to scan over WAN links or VPN. The traffic between the scanner and the scan target is high compared to the relatively low traffic between the scanner and Alert Logic. Place the scanner on the same side of the VPN or WAN link as the scan target for the best use of your bandwidth.
  • Use un-credentialed scans as fallback. Credentialed scans produce the most accurate results and should be used on all servers and workstations. Un-credentialed scans should be used only for devices where credentialed scanning is not available, for example, routers, switches, and printers.

Originating IP addresses for scanning

The following table contains the broad range of IP addresses owned by Alert Logic for existing and future use. Alert Logic scanning technologies use a specific subset of these IP addresses for scan origination. Make sure that your active protective mechanisms, such as IDS, IPS, WAFs, and firewalls that can send shun/block requests, to allow scanning traffic from all of the following IP addresses.

IP/CIDR # of addresses Included addresses
204.110.218.0/23 512 204.110.218.0 — 204.110.219.255
208.71.208.0/22 1024 208.71.208.0 — 208.71.211.255
185.54.124.0/22 1024 185.54.124.0 — 185.54.127.255