Regulatory Environment

Many organizations find themselves bound by laws and regulations that govern the ways they store, process, and transmit different types of data. This is especially true when the organization handles sensitive personal information or information belonging to government agencies.

Many of these laws are not overly prescriptive and do not specifically address the implementation of a vulnerability management program. For example, the Health Insurance Portability and Accountability Act (HIPAA) regulates the ways that healthcare providers, insurance companies, and their business associates handle protected health information. Similarly, the Gramm–Leach–Bliley Act (GLBA) governs how financial institutions handle customer financial records. Neither of these laws specifically requires that covered organizations conduct vulnerability scanning.

Two regulatory schemes, however, do specifically mandate the implementation of a vulnerability management program: the Payment Card Industry Data Security Standard (PCI DSS) and the Federal Information Security Management Act (FISMA).

Federal Information Security Management Act (FISMA)

The Federal Information Security Management Act (FISMA) requires that government agencies and other organizations operating on behalf of government agencies comply with a series of security standards. The specific controls required by these standards depend on whether the government designates the system as low impact, moderate impact, or high impact, according to the definitions shown in Figure 4.1. Further guidance on system classification is found in Federal Information Processing Standard (FIPS) 199: Standards for Security Categorization of Federal Information and Information Systems.

All federal information systems, regardless of their impact categorization, must meet the basic requirements for vulnerability scanning found in NIST Special Publication 800-53: Security and Privacy Controls for Federal Information Systems and Organizations. These require that each organization subject to FISMA do the following:

1. Scan for vulnerabilities in the information system and hosted applications and, when new vulnerabilities potentially affecting the system/application are identified, report them.
2. Employ 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
   3. Measuring vulnerability impact
3. Analyze vulnerability scan reports and results from security control assessments.
4. Remediate legitimate vulnerabilities in accordance with an organizational assessment of risk.
5. Share information obtained from the vulnerability scanning process and security control assessments to help eliminate similar vulnerabilities in other information systems (i.e., systemic weaknesses or deficiencies).

These requirements establish a baseline for all federal information systems. NIST 800-53 then describes eight control enhancements that may be required depending on the circumstances:

1. The organization employs vulnerability scanning tools that include the capability to readily update the information system vulnerabilities to be scanned.
2. The organization updates the information system vulnerabilities scanned prior to a new scan (and/or) when new vulnerabilities are identified and reported.
3. The organization employs vulnerability scanning procedures that can identify the breadth and depth of coverage (i.e., information system components scanned and vulnerabilities checked).
4. The organization determines what information about the information system is discoverable by adversaries and subsequently takes organization-defined corrective actions.
5. The information system implements privileged access authorization to information system components for selected vulnerability scanning activities.
6. The organization employs automated mechanisms to compare the results of vulnerability scans over time to determine trends in information system vulnerabilities.
7. (Requirement 7 was withdrawn.)
8. The organization reviews historic audit logs to determine if a vulnerability identified in the information system has been previously exploited.
9. (Requirement 9 was withdrawn.)
10. The organization correlates the output from vulnerability scanning tools to determine the presence of multi-vulnerability/multi-hop attack vectors.

Note that requirements 7 and 9 were control enhancements that were previously included in the standard but were later withdrawn.

In cases where a federal agency determines that an information system falls into the moderate impact category, it must implement control enhancements 1, 2, and 5, at a minimum. If the agency determines a system is high impact, it must implement at least control enhancements 1, 2, 4, and 5.

Corporate Policy

The prescriptive security requirements of PCI DSS and FISMA cover organizations involved in processing retail transactions and operating government systems, but those two groups constitute only a fraction of enterprises. Cybersecurity professionals widely agree that vulnerability management is a critical component of any information security program, and for this reason, many organizations mandate vulnerability scanning in corporate policy, even if this requirement is not imposed by regulatory requirements.

Identifying Scan Targets

Once an organization decides that it wishes to conduct vulnerability scanning and determines which, if any, regulatory requirements apply to their scans, they move on to the more detailed phases of the planning process. The next step is to identify the systems that will be covered by the vulnerability scans. Some organizations choose to cover all systems in their scanning process whereas others scan systems differently (or not at all) depending on the answers to many different questions, including

• What is the data classification of the information stored, processed, or transmitted by the system?
• Is the system exposed to the Internet or other public or semipublic networks?
• What services are offered by the system?
• Is the system a production, test, or development system?

Organizations also use automated techniques to identify the systems that may be covered by a scan. Cybersecurity professionals use scanning tools to search the network for connected systems, whether they were previously known or unknown, and build an asset inventory. Figure 4.2 shows an example of an asset map developed using the Qualys vulnerability scanner's asset inventory functionality.

Administrators may then supplement this inventory with additional information about the type of system and the information it handles. This information then helps make determinations about which systems are critical and which are noncritical. Asset inventory and asset criticality information helps guide decisions about the types of scans that are performed, the frequency of those scans, and the priority administrators should place on remediating vulnerabilities detected by the scan.

Determining Scan Frequency

Cybersecurity professionals depend on automation to help them perform their duties in an efficient, effective manner. Vulnerability scanning tools allow the automated scheduling of scans to take the burden off administrators. Figure 4.3 shows an example of how these scans might be configured in Tenable's Nessus product. Nessus was one of the first vulnerability scanners on the market and remains widely used today. Administrators may designate a schedule that meets their security, compliance, and business requirements.

Administrators should configure these scans to provide automated alerting when they detect new vulnerabilities. Many security teams configure their scans to produce automated email reports of scan results, such as the report shown in Figure 4.4.

Many different factors influence how often an organization decides to conduct vulnerability scans against its systems:

• The organization's risk appetite is its willingness to tolerate risk within the environment. If an organization is extremely risk averse, it may choose to conduct scans more frequently to minimize the amount of time between when a vulnerability comes into existence and when it is detected by a scan.
• Regulatory requirements, such as PCI DSS or FISMA, may dictate a minimum frequency for vulnerability scans. These requirements may also come from corporate policies.

  

  

• Technical constraints may limit the frequency of scanning. For example, the scanning system may only be capable of performing a certain number of scans per day, and organizations may need to adjust scan frequency to ensure that all scans complete successfully.
• Business constraints may limit the organization from conducting resource-intensive vulnerability scans during periods of high business activity to avoid disruption of critical processes.
• Licensing limitations may curtail the bandwidth consumed by the scanner or the number of scans that may be conducted simultaneously.

Cybersecurity professionals must balance each of these considerations when planning a vulnerability scanning program. It is usually wise to begin small and slowly expand the scope and frequency of vulnerability scans over time to avoid overwhelming the scanning infrastructure or enterprise systems.

Active vs. Passive Scanning

Most vulnerability scanning tools perform active vulnerability scanning, meaning that the tool actually interacts with the scanned host to identify open services and check for possible vulnerabilities. Active scanning does provide high-quality results, but those results come with some drawbacks:

• Active scanning is noisy and will likely be detected by the administrators of scanned systems. This may not be an issue in environments where administrators have knowledge of the scanning, but active scanning is problematic if the scan is meant to be stealthy.
• Active scanning also has the potential to accidentally exploit vulnerabilities and interfere with the functioning of production systems. Although active scanners often have settings that you can use to minimize this risk, the reality is that active scanning can cause production issues.
• Active scans may also completely miss some systems if they are blocked by firewalls, intrusion prevention systems, network segmentation, or other security controls.

Passive vulnerability scanning takes a different approach that supplements active scans. Instead of probing systems for vulnerabilities, passive scanners monitor the network, similar to the technique used by intrusion detection systems. But instead of watching for intrusion attempts, they look for the telltale signatures of outdated systems and applications, reporting results to administrators.

Passive scans have some very attractive benefits, but they're only capable of detecting vulnerabilities that are reflected in network traffic. They're not a replacement for active scanning, but they are a very strong complement to periodic active vulnerability scans.

Scoping Vulnerability Scans

The scope of a vulnerability scan describes the extent of the scan, including answers to the following questions:

• What systems and networks will be included in the vulnerability scan?
• What technical measures will be used to test whether systems are present on the network?
• What tests will be performed against systems discovered by a vulnerability scan?

Administrators should first answer these questions in a general sense and ensure that they have consensus from technical staff and management that the scans are appropriate and unlikely to cause disruption to the business. Once they've determined that the scans are well designed and unlikely to cause serious issues, they may then move on to configuring the scans within the vulnerability management tool.

Configuring Vulnerability Scans

Vulnerability management solutions provide administrators with the ability to configure many different parameters related to scans. In addition to scheduling automated scans and producing reports, administrators can customize the types of checks performed by the scanner, provide credentials to access target servers, install scanning agents on target servers, and conduct scans from a variety of network perspectives.

Scan Sensitivity Levels

Cybersecurity professionals configuring vulnerability scans should pay careful attention to the configuration settings related to the scan sensitivity level. These settings determine the types of checks that the scanner will perform and should be customized to ensure that the scan meets its objectives while minimizing the possibility of disrupting the target environment.

Typically, administrators create a new scan by beginning with a template. This may be a template provided by the vulnerability management vendor and built into the product, such as the Nessus templates shown in Figure 4.5, or it may be a custom-developed template created for use within the organization. As administrators create their own scan configurations, they should consider saving common configuration settings in templates to allow efficient reuse of their work, saving time and reducing errors when configuring future scans.

Administrators may also improve the efficiency of their scans by configuring the specific plug-ins that will run during each scan. Each plug-in performs a check for a specific vulnerability, and these plug-ins are often grouped into families based on the operating system, application, or device that they involve. Disabling unnecessary plug-ins improves the speed of the scan by bypassing unnecessary checks and also may reduce the number of false positive results detected by the scanner.

For example, an organization that does not use the Amazon Linux operating system may choose to disable all checks related to Amazon Linux in their scanning template. Figure 4.6 shows an example of disabling these plug-ins in Nessus.

Supplementing Network Scans

Basic vulnerability scans run over a network, probing a system from a distance. This provides a realistic view of the system's security by simulating what an attacker might see from another network vantage point. However, the firewalls, intrusion prevention systems, and other security controls that exist on the path between the scanner and the target server may affect the scan results, providing an inaccurate view of the server's security independent of those controls.

Additionally, many security vulnerabilities are difficult to confirm using only a remote scan. Vulnerability scans that run over the network may detect the possibility that a vulnerability exists but be unable to confirm it with confidence, causing a false positive result that requires time-consuming administrator investigation.

Modern vulnerability management solutions can supplement these remote scans with trusted information about server configurations. This information may be gathered in two ways. First, administrators can provide the scanner with credentials that allow the scanner to connect to the target server and retrieve configuration information. This information can then be used to determine whether a vulnerability exists, improving the scan's accuracy over noncredentialed alternatives. For example, if a vulnerability scan detects a potential issue that can be corrected by an operating system update, the credentialed scan can check whether the update is installed on the system before reporting a vulnerability.

Figure 4.7 shows an example of the credentialed scanning options available within Qualys. Credentialed scans may access operating systems, databases, and applications, among other sources.

In addition to credentialed scanning, some scanners supplement the traditional server-based scanning approach to vulnerability scanning with a complementary agent-based scanning approach. In this approach, administrators install small software agents on each target server. These agents conduct scans of the server configuration, providing an “inside-out” vulnerability scan, and then report information back to the vulnerability management platform for analysis and reporting.

Scan Perspective

Comprehensive vulnerability management programs provide the ability to conduct scans from a variety of scan perspectives. Each scan perspective conducts the scan from a different location on the network, providing a different view into vulnerabilities. For example, an external scan is run from the Internet, giving administrators a view of what an attacker located outside the organization would see as potential vulnerabilities. Internal scans might run from a scanner on the general corporate network, providing the view that a malicious insider might encounter. Finally, scanners located inside the datacenter and agents located on the servers offer the most accurate view of the real state of the server by showing vulnerabilities that might be blocked by other security controls on the network. Controls that might affect scan results include

• Firewall settings
• Network segmentation
• Intrusion detection systems (IDSs)
• Intrusion prevention systems (IPSs)

Vulnerability management platforms have the ability to manage different scanners and provide a consolidated view of scan results, compiling data from different sources. Figure 4.8 shows an example of how the administrator may select the scanner for a newly configured scan using Qualys.

Scanner Maintenance

As with any technology product, vulnerability management solutions require care and feeding. Administrators should conduct regular maintenance of their vulnerability scanner to ensure that the scanning software and vulnerability feeds remain up-to-date.

Scanner Software

Scanning systems themselves aren't immune from vulnerabilities. As shown in Figure 4.9, even vulnerability scanners can have security issues! Regular patching of scanner software protects an organization against scanner-specific vulnerabilities and also provides important bug fixes and feature enhancements to improve scan quality.

Vulnerability Plug-in Feeds

Security researchers discover new vulnerabilities every week, and vulnerability scanners can be effective against these vulnerabilities only if they receive frequent updates to their plug-ins. Administrators should configure their scanners to retrieve new plug-ins on a regular basis, preferably daily. Fortunately, as shown in Figure 4.10, this process is easily automated.

Reporting and Communication

Communicating vulnerability scan results to technologists who have the ability to remediate them and managers responsible for the security of the environment is a critical component of vulnerability management. After all, if the team members who can correct the issue never see the results, vulnerability scanning is a waste of time!

Modern vulnerability management tools provide very strong reporting capabilities. These reports may be manually generated on demand to answer specific questions, or administrators may set up automated reports that generate on a scheduled basis and are pushed out to those who need to see them. Additionally, administrators may set up alerting mechanisms to immediately notify key personnel of critical new vulnerabilities as soon as they are detected.

Management-level dashboards provide a very high-level summary of the cybersecurity health of the environment. This type of report is often used to give leaders a quick snapshot of the environment. An example of a dashboard from Qualys appears in Figure 4.12.

As cybersecurity analysts drill deeper into the vulnerability management system, they can see summary technical reports that show the specific vulnerabilities detected on the network and sort them by vulnerability type, severity, host group, and other factors. An example of this type of report from Nessus appears in Figure 4.13. These reports are useful in identifying the widespread issues that require attention from cybersecurity professionals.

System engineers are typically more interested in detailed reports listing all the vulnerabilities on the systems they administer. Figure 4.14 shows a Nessus report listing all the vulnerabilities that exist on a single system scanned by the tool. The report provides a full listing of vulnerabilities, sorted by severity, and can serve as a checklist that system engineers can use to prioritize their remediation efforts for a system.

The final level of drill-down provides the nitty-gritty details required to fix an individual vulnerability on a system. Figure 4.15 shows an example of this type of reporting. The report identifies the vulnerability that was detected, explains the significance and cause of the vulnerability, and provides remediation instructions to help guide the administrator's efforts in correcting the underlying security issue.

Prioritizing Remediation

As cybersecurity analysts work their way through vulnerability scanning reports, they must make important decisions about prioritizing remediation to use their limited resources to resolve the issues that pose the greatest danger to the organization. There is no cut-and-dried formula for prioritizing vulnerabilities. Rather, analysts must take several important factors into account when choosing where to turn their attention first.

Some of the most important factors in the remediation prioritization decision-making process include the following:

• Criticality of the Systems and Information Affected by the Vulnerability Criticality measures should take into account confidentiality, integrity, and availability requirements, depending on the nature of the vulnerability. For example, if the vulnerability allows a denial-of-service attack, cybersecurity analysts should consider the impact to the organization if the system became unusable due to an attack. If the vulnerability allows the theft of stored information from a database, cybersecurity analysts should consider the impact on the organization if that information were stolen.
• Difficulty of Remediating the Vulnerability If fixing a vulnerability will require an inordinate commitment of human or financial resources, that fact should be factored into the decision-making process. Cybersecurity analysts may find that they can fix five issues rated numbers 2 through 6 in priority order for the same investment that would be required to address the top issue. This doesn't mean that they should necessarily choose to make that decision based on cost and difficulty alone, but it is a consideration in the prioritization process.
• Severity of the Vulnerability The more severe an issue is, the more important it is to correct that issue. Analysts may turn to the Common Vulnerability Scoring System (CVSS) to provide relative severity rankings for different vulnerabilities. Remember from earlier in this chapter that CVSS is a component of SCAP.
• Exposure of the Vulnerability Cybersecurity analysts should also consider how exposed the vulnerability is to potential exploitation. For example, if an internal server has a serious SQL injection vulnerability but that server is accessible only from internal networks, remediating that issue may take a lower priority than remediating a less severe issue that is exposed to the Internet and, therefore, more vulnerable to external attack.

Identifying the optimal order of remediating vulnerabilities is more of an art than a science. Cybersecurity analysts must evaluate all the information at their disposal and make informed decisions about the sequence of remediation that will deliver the most security value to their organization.

Testing and Implementing Fixes

Before deploying any remediation activity, cybersecurity professionals and other technologists should thoroughly test their planned fixes in a sandbox environment. This allows technologists to identify any unforeseen side effects of the fix and reduces the likelihood that remediation activities will disrupt business operations or cause damage to the organization's information assets.

After deploying a fix by patching or hardening the affected system(s), you should take steps to verify that the mitigation was effective. This typically involves repeating the vulnerability scan that initially identified the vulnerability and confirming that the issue does not appear in the new scan results.

When you do perform mitigation activities, it's important to remember to update your configuration baseline as well. For example, if you apply a security patch to your systems, you should also modify your configuration baseline to ensure that future systems are patched against that same vulnerability from the start.

Delayed Remediation Options

It's not always possible to remediate every vulnerability. In cases where you can't correct the problem immediately, you have two basic options available to you.

First, you can implement a compensating control. Compensating controls are additional security measures that you take to address a vulnerability without remediating the underlying issue. For example, if you have a web application that is vulnerable to SQL injection but you can't correct the web application itself, you might use a web application firewall to block SQL injection attack attempts. The web application firewall serves as a compensating control.

Second, you can decide that the risk is acceptable and that you will continue business as usual, acknowledging the risk and moving on.

Infrastructure Vulnerability Scanning

As you prepare for the CySA+ exam, you should be familiar with the major infrastructure vulnerability scanning tools used by cybersecurity analysts. The following tools are examples of network vulnerability scanners:

• Tenable's Nessus is a well-known and widely respected network vulnerability scanning product that was one of the earliest products in this field.
• Qualys's vulnerability scanner is a more recently developed commercial network vulnerability scanner that offers a unique deployment model using a software-as-a-service (SaaS) management console to run scans using appliances located both in on-premises datacenters and in the cloud.
• Rapid7's Nexpose is another commercial vulnerability management system that offers capabilities similar to those of Nessus and Qualys.
• The open source OpenVAS offers a free alternative to commercial vulnerability scanners.

These four products are the network vulnerability scanners that you are required to know for the CySA+ exam. Many other examples of network vulnerability scanners are on the market today, and every mature organization should have at least one scanner in their toolkit. Many organizations choose to deploy two different vulnerability scanning products in the same environment as a defense-in-depth control.

Web Application Scanning

Web application scanners are specialized tools used to examine the security of web applications. These tools test for web-specific vulnerabilities, such as SQL injection, cross-site scripting (XSS), and cross-site request forgery (CSRF) vulnerabilities. They work by combining traditional network scans of web servers with detailed probing of web applications using such techniques as sending known malicious input sequences and fuzzing in attempts to break the application.

Nikto is one of the two open source web application scanning tools that are required knowledge for the CySA+ exam. As an open source tool, it is freely available for anyone to use. As shown in Figure 4.17, Nikto uses a command-line interface and is somewhat difficult to use.

The other open source tool available for web application scanning is Arachni. This tool, shown in Figure 4.18, is a packaged scanner available for Windows, macOS, and Linux operating systems.

Most organizations use web application scanners, but they choose to use commercial products that offer advanced capabilities and user-friendly interfaces. Although there are dedicated web application scanners, such as Acunetix, on the market, many firms use the web application scanning capabilities of traditional network vulnerability scanners, such as Nessus, Qualys, and Nexpose. Figure 4.19 shows an example of Nessus used in a web scanning role.

Interception Proxies

Interception proxies are valuable tools for penetration testers and others seeking to evaluate the security of web applications. As such, they can be classified as exploit tools. They run on the tester's system and intercept requests being sent from the web browser to the web server before they are released onto the network. This allows the tester to manually manipulate the request to attempt the injection of an attack.

Figure 4.20 shows the popular open source Zed Attack Proxy (ZAP). ZAP is a community development project coordinated by the Open Web Application Security Project (OWASP). Users of ZAP can intercept requests sent from any web browser and alter them before passing them to the web server.

The Burp Proxy, shown in Figure 4.21, is another option available to cybersecurity analysts seeking an interception proxy. It is part of a commercial web application security toolkit called the Burp Suite from PortSwigger. While the full Burp Suite requires a paid license, Burp Proxy is currently available as part of a free edition of the product.

Wireless Assessment Tools

If you are tasked with performing a vulnerability assessment of a wireless network, there are three tools covered on the CySA+ exam that you might find useful. As you prepare for the exam, you should know the names and purposes of each of these tools:

• Aircrack-ng is a suite of tools designed for wireless network testing. The tools in this suite can capture packets from wireless networks, conduct packet injection attacks, and crack preshared keys used on WEP, WPA, and WPA2 networks.
• Reaver is a specialized tool used to find WPA and WPA2 passphrases specifically on networks that support the Wi-Fi Protected Setup (WPS) feature.
• Hashcat is a general-purpose password cracking tool that may also be used on wireless networks.

Activity 4.1: Install a Vulnerability Scanner

In this lab, you will install the Nessus vulnerability management package on a system.

This lab requires access to a Linux system that you can use to install Nessus (preferably Ubuntu, Debian, Red Hat, SUSE, or Fedora).

Part 1: Obtain a Nessus Essentials activation code

• Visit the Nessus website (www.tenable.com/products/nessus/nessusessentials) and fill out the form to obtain an activation code.

  Save the email containing the code for use during the installation and activation process.

Part 2: Download Nessus and install it on your system

1. Visit the Nessus download page (www.tenable.com/products/nessus/select-your-operating-system#download) and download the appropriate version of Nessus for your system.
2. Install Nessus following the documentation available at docs.tenable.com/nessus/8_8/Content/Install.htm.
3. Verify that your installation was successful by logging into your Nessus server.

Activity 4.2: Run a Vulnerability Scan

In this lab, you will run a vulnerability scan against a server of your choice. It is important to note that you should never run a vulnerability scan without permission.

You will need access to both your vulnerability scanning server that you built in Activity 4.1 and a target server for your scan. If you do not have a server that you currently have permission to scan, you may build one using a cloud service provider, such as Amazon Web Services (AWS), Microsoft Azure, or Google Compute Platform.

Conduct a vulnerability scan against your server and save the resulting report. If you need assistance, consult the Nessus documentation. You will need the report from this vulnerability scan to complete the activities in the next chapter.

1. What federal law requires the use of vulnerability scanning on information systems operated by federal government agencies?
   1. HIPAA
   2. GLBA
   3. FISMA
   4. FERPA
2. Gary is the system administrator for a federal agency and is responsible for a variety of information systems. Which systems must be covered by vulnerability scanning programs?
   1. Only high-impact systems
   2. Only systems containing classified information
   3. High- or moderate-impact systems
   4. High-, moderate-, and low-impact systems
3. What tool can administrators use to help identify the systems present on a network prior to conducting vulnerability scans?
   1. Asset inventory
   2. Web application assessment
   3. Router
   4. DLP
4. Tonya is configuring vulnerability scans for a system that is subject to the PCI DSS compliance standard. What is the minimum frequency with which she must conduct scans?
   1. Daily
   2. Weekly
   3. Monthly
   4. Quarterly
5. Which one of the following is not an example of a vulnerability scanning tool?
   1. Qualys
   2. Snort
   3. Nessus
   4. OpenVAS
6. Bethany is the vulnerability management specialist for a large retail organization. She completed her last PCI DSS compliance scan in March. In April, the organization upgraded their point-of-sale system, and Bethany is preparing to conduct new scans. When must she complete the new scan?
   1. Immediately
   2. June
   3. December
   4. No scans are required
7. Renee is configuring her vulnerability management solution to perform credentialed scans of servers on her network. What type of account should she provide to the scanner?
   1. Domain administrator
   2. Local administrator
   3. Root
   4. Read-only
8. Jason is writing a report about a potential security vulnerability in a software product and wishes to use standardized product names to ensure that other security analysts understand the report. Which SCAP component can Jason turn to for assistance?
   1. CVSS
   2. CVE
   3. CPE
   4. OVAL
9. Bill would like to run an internal vulnerability scan on a system for PCI DSS compliance purposes. Who is authorized to complete one of these scans?
   1. Any employee of the organization
   2. An approved scanning vendor
   3. A PCI DSS service provider
   4. Any qualified individual
10. Which type of organization is the most likely to face a statutory requirement to conduct vulnerability scans?
    1. Bank
    2. Hospital
    3. Government agency
    4. Doctor's office
11. What minimum level of impact must a system have under FISMA before the organization is required to determine what information about the system is discoverable by adversaries?
    1. Low
    2. Moderate
    3. High
    4. Severe
12. What term describes an organization's willingness to tolerate risk in their computing environment?
    1. Risk landscape
    2. Risk appetite
    3. Risk level
    4. Risk adaptation
13. Which one of the following factors is least likely to impact vulnerability scanning schedules?
    1. Regulatory requirements
    2. Technical constraints
    3. Business constraints
    4. Staff availability
14. Barry placed all of his organization's credit card processing systems on an isolated network dedicated to card processing. He has implemented appropriate segmentation controls to limit the scope of PCI DSS to those systems through the use of VLANs and firewalls. When Barry goes to conduct vulnerability scans for PCI DSS compliance purposes, what systems must he scan?
    1. Customer systems
    2. Systems on the isolated network
    3. Systems on the general enterprise network
    4. Both B and C
15. Ryan is planning to conduct a vulnerability scan of a business-critical system using dangerous plug-ins. What would be the best approach for the initial scan?
    1. Run the scan against production systems to achieve the most realistic results possible.
    2. Run the scan during business hours.
    3. Run the scan in a test environment.
    4. Do not run the scan to avoid disrupting the business.
16. Which one of the following activities is not part of the vulnerability management life cycle?
    1. Detection
    2. Remediation
    3. Reporting
    4. Testing
17. What approach to vulnerability scanning incorporates information from agents running on the target servers?
    1. Continuous monitoring
    2. Ongoing scanning
    3. On-demand scanning
    4. Alerting
18. Brian is seeking to determine the appropriate impact categorization for a federal information system as he plans the vulnerability scanning controls for that system. After consulting management, he discovers that the system contains information that, if disclosed improperly, would have a serious adverse impact on the organization. How should this system be categorized?
    1. Low impact
    2. Moderate impact
    3. High impact
    4. Severe impact
19. Jessica is reading reports from vulnerability scans run by different parts of her organization using different products. She is responsible for assigning remediation resources and is having difficulty prioritizing issues from different sources. What SCAP component can help Jessica with this task?
    1. CVSS
    2. CVE
    3. CPE
    4. XCCDF
20. Sarah would like to run an external vulnerability scan on a system for PCI DSS compliance purposes. Who is authorized to complete one of these scans?
    1. Any employee of the organization
    2. An Approved Scanning Vendor
    3. A PCI DSS service provider
    4. Any qualified individual