MODULE 38
Security Assessment
By this point, you’ve learned how to defend your systems and networks and the information that’s processed on them. Assuming you’ve implemented all of the security methods you’ve learned about, you might be tempted to say that your systems and network are fairly secure. But suppose someone posed the question, “How do you know they’re secure?” What would your answer be? How can you measure the level of security you’ve implemented on your systems? Is it enough? You’ll get answers to these questions by performing security assessments on your infrastructure. In this module, you’ll learn a few things about assessing security as well as some security tools and techniques you can use to test security on your network.
Security Assessment Tools and Techniques
You may have heard of the terms security assessment, penetration test, and ethical hacker. If you know don’t what those terms mean, you’ll learn a little bit about them in this module. When conducting a security assessment, you approach your system security from an aggressive or offensive perspective, rather than a defensive one. When you’re working in defensive mode, you’re implementing security controls that can help protect your systems, such as patching workstations and servers, encrypting traffic, creating firewall rules, and so on. Your focus in this capacity is on defending the network from attack and from data loss.
During a security assessment, you’ll determine whether the security controls in place are adequate and will stand up to attacks or any other negative event that might cause a loss of data or systems. To do this, you have to take an offensive posture. This means using tools and techniques on your network that will help you see exactly how secure it really is. We’ll talk about several different types of assessments, including risk assessments, vulnerability tests, and penetration testing. Understand that some of these assessments may involve using tools and techniques that are designed to circumvent security or at least determine how strong your security controls really are. Before we get into the meat of this module, here’s a word of caution: The tools and techniques we’ll discuss are meant to be used for good purposes only. We’re not trying to train you to be malicious hackers or to compromise systems, but it’s important that you understand how some of the same tools and techniques that hackers use can be used to test security on systems that you own and manage. In other words, use your Jedi powers for good, not evil!
Assessment Types
You can use several assessment types, each offering different tools and techniques, to achieve a variety of goals. Some assessments are meant to test security management practices, while others are meant to test the more technical aspects of systems. The types of assessments we’ll discuss in the next few sections support the overall risk management process as well. We’ll also talk about how to calculate the risk after you have performed some of these assessments to make your results more meaningful.
Threat Assessment
Use a threat assessment to determine what threats, both natural and man-made, exist that might negatively impact your systems and data. Remember that a threat is something that can do harm, so during a threat assessment you are trying to gather as much information as you can on what possible harm can befall your computing assets and data. Where do you get this information? There are several potential sources, and you should take advantage of as many of them as you can. Law enforcement and cybersecurity organizations can give you threat information particular to your market space, industry, and even geographical location that concerns the possible threats to your systems and data from a technical perspective. You can also get good information regarding threats from historical or statistical information that may apply to your particular industry or area. Often, larger organizations have their own threat assessment or intelligence units that can provide information on potential threats.
The key is to gather this information and see how it might apply to your particular situation. For example, if you work in the defense industry, then obviously intelligence sources can give you information on foreign intelligence threats, industrial espionage, and so on, from both a cybersecurity-specific as well as a general view. You may be able to get information on the latest attack techniques and tools that an adversary may use to penetrate your network and steal data, for example. Another example might be if you work in the healthcare industry. There are specific cybersecurity threats out in the world that target both personal and protected health information; information concerning these threats can be gathered from other similar institutions, government agencies, and so on. Your organization must use the expertise it has in order to determine to what level and how these threats would affect its infrastructure and data.
Vulnerability Assessment
A vulnerability assessment looks at systems, data, processes, procedures, and even the people element, to determine what weaknesses or vulnerabilities exist within those systems. All systems and processes have vulnerabilities somewhere; it’s up to you to determine what they are, what threats could target them, and how to prevent threats from exploiting those vulnerabilities. A vulnerability assessment can be a very comprehensive effort across a large organization that looks at security management, procedures, policies, and so on. A vulnerability assessment can also look at the more technical areas as well, including patch management, secure configuration, protection of data in transit and at rest, and so forth. You should look at vulnerabilities to the most detailed degree as possible. This means looking at individual systems, operating systems, applications, networks, processes, and so on. You would then match each of those vulnerabilities with a potential threat.
Risk Assessment
A risk assessment involves several elements, including the threat and vulnerability assessments we just discussed. A risk assessment determines whether the threats and vulnerabilities you’ve discovered are likely to be exercised against the particular vulnerability to produce an adverse effect (the impact). Impact is the level of harm to an organization if a particular capability, such as a server, process, or even data, were lost or diminished so that the organization could not fully utilize them. The likelihood is combined with the potential impact if the threat was to materialize against the vulnerability, and this is the risk to the system or data involved.
The risk assessment attempts to determine the level of risk to the system or organization. Risk can be expressed in qualitative terms such as high, medium, or low, or in quantitative terms expressed as numerical values, such as 1 to 10. The assessment is based on probability (likelihood), cost (impact), and other factors. Risk can be expressed in terms that apply to specific systems or data, in terms of program security management that apply to the business processes in the organization, and even as an overall cumulative risk to the organization itself. In the next few sections, we’ll go a little bit more into calculating risk using some of the factors we just discussed.
Risk Calculations
Risk can be calculated following assessments, using factors such as threat, vulnerability, likelihood, and impact. Basic risk calculations are considered a must-know for the Security+ exam as well as more advanced security certifications, and this information is also useful in this place we like to call “real life.” Let’s take a few moments to go through how to calculate some of these factors that you study during a risk assessment.
Threats and Likelihood
To calculate risk, you must gather information regarding threats and vulnerabilities by performing a threat assessment for a system; then you can assign likelihood values for each threat. For example, if you determine that there is a significant threat of an insider stealing data from a particular system, you would assign a likelihood value to that threat. A qualitative value could be low, medium, or high, depending on how likely you think the threat is to materialize. A quantitative value might use a numerical value, such as a statistical probability (say, a 60 percent chance of occurrence), or a number on a scale of 1 to 10 (say, a 6), where 1 is very unlikely and 10 is extremely likely. You might be tempted to think that the use of a qualitative value (such as low, medium, or high) is very subjective and might not be as accurate as a quantitative. This, however, isn’t always the case. Note that a qualitative or quantitative measurement doesn’t necessarily mean that either are completely subjective or objective in nature; a qualitative measurement can be quite objective at times, and a quantitative measurement, even though it may use statistical values, can also be quite subjective. It really depends on what you are measuring and how it was measured.
Vulnerabilities and Impact
Vulnerabilities are also assigned values, in terms of impact. As mentioned, impact relates to how serious the damage would be to an asset or an organization if a threat were to materialize against a particular vulnerability. Impact values are also expressed in qualitative or quantitative terms. An impact may be rated very high if a server with company secrets were compromised by a hacker, for example. Impact is also often expressed in terms of cost to the organization in quantitative terms, such as dollars.
Note that threats and vulnerabilities aren’t always easy to separate; if you can’t determine a valid threat for a particular vulnerability, does the vulnerability really exist? That’s more than just a philosophical question; from a practical perspective, you almost can’t have a particular vulnerability if there is no matching threat, and vice versa, because there would be either nothing to defend or nothing to protect against. If a vulnerability exists, there must be a matching threat, and vice versa, in order for risk to exist.
Risk
Risk is a combination of likelihood and impact. As either increases, risk increases. In general, the more the likelihood of a threat occurring, the greater the risk to the system or organization. And the higher the impact to the organization if the threat were actually exercised, the greater the risk is as well. You can calculate risk in several ways, beyond simply classifying it in terms of qualitative and quantitative. Some organizations use different “weights” for certain factors such as impact, or they develop complex formulas for calculating risk.
Remember that risk is also cumulative; several low-risk issues might amount to a higher risk when combined. At the same time, remember that risk tends to “roll-up” as well. So the various risk levels you’ve calculated for many different subsystems in an organization rolls up to a larger risk at the organizational level. Figure 38-1 shows a notional view from the National Institute of Standards and Technology (NIST) on how risk can be calculated qualitatively, based upon differing values of likelihood and impact.
Figure 38-1 Example of risk determination using different values of likelihood and impact (from NIST SP 800-30, rev. 1)
Assessment Techniques
You’ll need to know some basic assessment techniques for the exam, and even probably more importantly, for your real-life work as a security professional. Several more advanced techniques are not covered here, but the following are some of the basic ones that will give you a solid foundation of knowledge.
Baseline Reporting
Before you begin to look at assessing the vulnerabilities on a system or network, you should develop a baseline of how the system operates on a normal basis. Create documentation regarding the versions of operating systems on your boxes, their patch levels, configuration settings, ports and protocols used, and so forth. You should also use your first assessment as part of the baseline, so you have a starting point to compare any changes against. When you make changes to any of your systems based upon your security analysis, you should make these changes part of the new baseline after you have tested them and made sure they function properly and work as they should.
Code Review
Code review is a type of security assessment in which you actually examine as much of the source code of a system or application as possible to determine whether it has been written with security in mind. Of course, a full discussion on code review would be a book unto itself, so we’ll describe it only in general terms here. During a code review, you’re looking for common vulnerabilities such as input validation, bounds checking, memory allocation and usage, embedded passwords, weak encryption, use of static ports and protocols that may be unsecure, and so forth. The goal of a code review is to detect vulnerabilities before the application goes into production, but this isn’t always possible, so you may have to conduct code reviews on applications and operating systems that are actually in use.
Review Architecture
Another way to assess security in a system is to review its architecture—how it’s built and connects to other systems and interfaces. You also want to look at how it exchanges data with other systems. When reviewing the architecture, examine security mechanisms built into a system to determine whether they are adequate in protecting data while it’s in storage, during transmission, and processing. Some items you should review include authentication mechanisms, encryption mechanisms, secure exchange of data, and so on. Again, this is one of those assessments that you hope to be able to perform before a system goes into production and implementation, so that you can mitigate any vulnerabilities before the system gets put in the use.
Review Designs
Another part of security engineering involves looking at the design of the system. This is very much like looking at the architecture itself, but you are also looking at different products used in the system and what their vulnerabilities may be, how they have been configured for processing and exchanging data, and how their security mechanisms are supposed to work. In this case, you’re looking for any security vulnerabilities introduced by the way the system was put together and connected to its own components and to any external systems.
Determine Attack Surface
You look at the attack surface to determine how exposed to threats the system is. A system with a large attack surface has many different vulnerabilities that are unprotected; it offers many different possible avenues of attack. Usually these systems have unnecessary ports and protocols running on the box, unpatched operating systems and applications, configuration issues, possibly faulty authentication mechanisms, and weak encryption systems. A system with a small attack surface, on the other hand, has a locked down configuration that has been patched as much as practicable, and it’s running only the applications, ports, protocols, and services that are absolutely necessary for its function. The more the attack surface for a system or network has been reduced, the less likely it is to be attacked and the less effective an attack will be on it—in other words, it will be more secure.
Vulnerability Scanning
The purpose of vulnerability scanning is to identify vulnerabilities caused by lack of security controls, common misconfigurations, and so on. Vulnerability scanning is a passive way of testing security controls, because no actual exploits are attempted on potential vulnerabilities. In other words, a vulnerability scan tells you all of the possible vulnerabilities, not what actually could be exploited. Vulnerability scans look for known weaknesses in a system, based upon operating system configuration, patch levels, software versions, running ports and services, and so on.
Vulnerability scanning software can be intrusive or non-intrusive, depending upon how it’s configured. Non-intrusive scans are set to provide a cursory look at a system, preventing the scanner from affecting performance of the system being scanned. An intrusive scan, on the other hand, performs in-depth checking on potential vulnerabilities and in some cases can cause a system to crash or reboot, affecting availability for its users. In addition to configuring the level of intrusiveness for a scan, most scanning programs allow you to perform a credentialed scan versus a non-credentialed one. A credentialed scan gives you much more information, because you are able to access more information and configuration details about a system when logged in with valid privileged credentials than you would if you used a non-credentialed scan. A non-credentialed scan might be used in a black box or blind test (described next) when you have no knowledge of any system accounts.
Penetration Testing
Penetration testing, as opposed to vulnerability testing, actually exploits weaknesses on a system. Although vulnerability testing presents the possibilities regarding how a threat could be exploited, the results of a vulnerability tests are purely theoretical to a large degree. A vulnerability test doesn’t tell you whether a threat could actually exploit any particular weakness, just that the possibility is there. Penetration testing, on the other hand, goes a step further. In addition to identifying vulnerabilities on the system, a penetration test can verify that a threat exists and that it actually could, in fact, exploit a given vulnerability.
During a penetration test, so-called ethical hackers (an interesting term for people who possess hacking knowledge and skills, but use their Jedi powers only for good) attempt to bypass security controls by actively testing them and exploiting any identified vulnerabilities. The penetration tester performs attacks on the system to see if he or she can compromise the system, steal data, conduct denial-of-service attacks, and so on. Through penetration testing, a security professional can determine whether a weaknesses can be exploited way before a malicious hacker tries. Results from penetration tests can be used to determine how better to protect the system by mitigating the vulnerabilities that the tester was able to exploit. In some cases, you don’t have to waste your time or resources mitigating vulnerabilities that actually might not be so easily exploitable in the real world. Of course, you shouldn’t necessarily ignore these vulnerabilities, but you may be able to lower the risk incurred from them and spend your money and other resources on vulnerabilities that are actually exploitable and that may in fact be high-risk items.
You should be aware of a couple of different types of penetration tests. First, there’s the black box test, in which an ethical hacker performs a penetration test on the system with no prior knowledge whatsoever about how the system is designed and architected, what defenses it may have, or any other characteristics about the system or network. The tester will have to perform foot printing and reconnaissance activities on the network to find out how it’s connected and what its defenses are, as well as its weaknesses, just the same as a malicious hacker would do. Note that this type of testing is also referred to as blind testing.
The next type of penetration test is called a gray box test. In this type of test, the ethical hacker may have some limited knowledge of the network or systems, gained from the organization that wants the test. They may have an IP address range, for example, or a simple network diagram, or even a listing of the operating systems they will find a network. Beyond this, though, they have no knowledge of any vulnerabilities in the system.
At the other end of the spectrum is a white box test. In a white box test, the penetration tester has full knowledge of the network and access to network diagrams, detailed information about hosts and services on the network, and even previous vulnerability scans that may show weaknesses in systems.
The type of penetration test the organization uses depends on how much time they want to spend on the tester getting information about the network versus actually trying to exploit the vulnerabilities. There may be value to having the tester start with no knowledge and trying to find out what they can, so that the organization can determine how much information a malicious hacker could actually get. On the flipside of that argument, the goal may be to exploit vulnerabilities versus trying to gain information about the system, so a full white box test can save time and enable the tester to focus on that important part of the assessment.
Two other characteristics of penetration testing aren’t necessarily types of test, but they can affect how the test is performed. Internal testing approaches the test from the inside of the network; the test team plugs into the secured part of the network and attacks from within, testing internal security measures. External testing involves the attack team hacking the perimeter of the organization first and working their way in; this allows the team to test the external defenses before testing the interior of the network.
As mentioned, in a blind (or black box) penetration test, the testers have no prior knowledge of the network they are testing. In a double-blind type of test, the network defenders also have no prior knowledge of the test and aren’t aware of any attacks unless they can detect and defend against them. One of the goals of this type of test may be to see how they react and if they can even detect the hacking attempts on the system and the network.
Figure 38-2 shows the generic process of penetration testing.
Figure 38-2 The penetration testing process
Don’t confuse the terms “black box,” “white box,” and “gray box” with other terms you may hear that describe the hacker. A black hat hacker, for example, is an malicious hacker who uses her knowledge and skills to compromise systems. A gray hat hacker is known to use her skills for both good and evil at times, and a white hat hacker is usually a penetration testing professional or ethical hacker.
Tools
We’ve discussed various methods of conducting security assessments and penetration tests; now it’s time to talk about some of the tools we can use to perform these assessments. Keep in mind that most of these tools are like a double-edged sword: They can be used for good purposes, by ethical security professionals, to maintain the security of their systems and networks. Or they can be used by malicious individuals to steal data, conduct denial-of-service attacks, hack into systems, and perform all sorts of other kinds of malicious mischief. It’s up to you, of course, as a security professional, to use your newfound Jedi powers that you get from these tools for the good of your network and all mankind! Let’s take a look at some of these tools now. Keep in mind that this is a sampling of the available tools that are out there; these are probably the simpler tools that every security professionals should be familiar with, but far more sophisticated and advanced tools are available both to security professionals and, unfortunately, hackers.
Passive vs. Active Tools
Before we jump into the discussion on tools, we should discuss the difference between passive and active tools. A passive tool is used when you don’t want to interfere with any hosts or networks. Passive tools primarily listen for network traffic or monitor the hosts they reside on. Hackers like passive tools because they’re often difficult to detect, because they send out little to no data or evidence that they are attached to the network or host. Security professionals like passive tools so they can make sure that their actions don’t interfere with the performance of the network. An example of a passive tool might be a passive sniffer (which we’ll discuss in a moment).
An active tool, on the other hand, does in fact send out traffic or data to the network or host and actually interacts with systems. This is good from the perspective that you can usually gather more data and perform actions that can give you a better idea of the security of the systems you’re working with. The bad part about an active tool is that it can cause performance problems or even interfere with network traffic and system operations if used improperly. Security professionals are usually very careful about using active tools, especially on a production network, because they don’t want to interfere accidentally with the infrastructure or cause any damage to any systems. Hackers, on the other hand, use active tools to run exploits against vulnerable systems to compromise them. Fortunately, a drawback to active tools is that they usually are very easy to detect, making the job of a hacker that much harder. An example of an active tool would be a port or vulnerability scanner, both of which we’ll talk about as well.
Protocol Analyzer
A protocol analyzer is better known in the trade as a “sniffer.” A sniffer can be a piece of dedicated hardware, which is usually quite expensive, or software that is installed on a regular PC or laptop. A sniffer collects network traffic, throughout the OSI levels, regardless of port, protocol, or service (provided it’s one that the sniffer can understand). It can be used to troubleshoot network connectivity problems by collecting network traffic and examining it to determine different characteristics about the traffic. It can also be used to intercept and collect traffic that can be examined for security issues. For example, a security professional could intercept traffic on the network to see if there are any unauthorized FTP servers connected to the infrastructure. The professional could look for FTP traffic, determine the source IP address, and track down the unauthorized box and yank it from the network. A malicious person, on the other hand, could use a sniffer to intercept traffic in hopes of capturing plaintext information, such as passwords, personal or confidential information, and so on. One protection against a malicious person using a sniffer to gather information is through the use of encryption. Sniffers can still capture encrypted traffic, but since it can’t easily be decrypted, the malicious hacker gets to see only garbage, unless he employs other, more sophisticated methods to decrypt the traffic.
Sniffers can be used on either wired or wireless networks, provided the device has a supported wired or wireless network card that can be used to capture the traffic. Although a wide variety of sniffers are available out in the world, Wireshark is probably the most popular sniffer software among security professionals and hackers, because it works great and it’s free. Wireshark is available for both Windows and Linux platforms. A screenshot of Wireshark in action is shown in Figure 38-3.
Figure 38-3 Wireshark, a popular network sniffer
Port Scanner
A port scanner is a network tool used to send specially constructed network traffic to the host to get it to reply in a specific manner. Because of the way the TCP/IP stack is implemented on various hosts, the replies that are returned from the host can indicate what the operating system is, what ports and services it is using, and whether it is susceptible to certain types of network-based attacks. Nmap is probably the most commonly used port scanner, and it is available for almost any OS you can imagine. Security folks use it to detect unsecure hosts on the network so they can be fixed, while evil hackers use it to try to find attack vectors in vulnerable hosts. Nmap comes in both command-line and GUI flavors. Figure 38-4 shows output from the command-line version.
Figure 38-4 Results from the nmap network scanner
Vulnerability Scanner
A vulnerability scanner is software used to determine vulnerabilities on a host. The scanner can gather information about a computer, including what ports and services it is running, what software is on the box, the operating system and its version, what patches the box has installed on it, and even vulnerabilities that exist on the computer. A network-based vulnerability scanner, such as the popular Nessus scanner, can send specifically crafted network traffic to a host to elicit certain responses from that host. The responses from the computer can show vulnerabilities that might allow an attacker to compromise the host over the network, such as using unsecure protocols, weak encryption, open file shares, and so forth. A security professional can use a vulnerability scanner to discover weaknesses in the hosts on the network and fix those vulnerabilities, so hackers can’t take advantage of them. A malicious person, on the other hand, can use a vulnerability scanner to determine how best to attack a host or network. Figure 38-5 shows an example of Nessus, one of the most popular vulnerability scanners.
Figure 38-5 The Nessus vulnerability scanner
Honeypots
A honeypot is a host that has been intentionally compromised so that it has multiple vulnerabilities. A honeypot is placed on the network to attract the attention of a malicious hacker, hopefully drawing him away from being interested in other, more sensitive, hosts. If an attacker victimizes a honeypot, his methods and techniques can be studied to help you better protect the actual network against those same methods and techniques.
Honeypots can be boxes that are misconfigured or intentionally not patched, or they can be prebuilt virtual machines. There’s even software out there that can emulate dozens or hundreds of hosts at the same time, spanning several different operating systems, including different versions of Windows, Linux, Mac OS, UNIX, and so on. A honeynet, as you might guess, is an entire network of honeypots on their own network segment, used to get a hacker bogged down in a decoy network while the administrator locks down and secures the sensitive network and records and tracks the actions of the hacker.
Banner Grabbing
Banner grabbing is a technique used to footprint a system and the services that run on it. For example, you could run the telnet command and connect to a certain web server on TCP port 80, and in some cases, you might receive an error message that tells you the type of web server software running on the box, its version, and other juicy information about it that might help you plan an attack against it. Banner grabbing is kind of a hit-or-miss technique, however, because a lot of modern network-based software by default is protected against giving up information about itself. Other software can be manually configured not to give up information, but oftentimes the administrator has not bothered to configure it this way. Other services, such as file shares, FTP servers, DNS and other network services, and even particular operating systems are vulnerable to different banner grabbing techniques. Figure 38-6 shows an example of banner grabbing.
Figure 38-6 Banner grabbing from a web server
Interpreting Security Assessment Tool Results
Once you run all of your cool security tools against the system or network, you’ll be tempted to plunge right in and start exploiting all the different vulnerabilities you find, or at least you’ll want to begin to remediate them by changing configurations, installing patches, and throwing money and resources at the system. One word of caution about this, however: You can’t always rely solely on the results of tool findings as a basis for your security and remediation strategy. Different tools interpret findings from different systems, well, differently. Some tools may find a vulnerability and indicate that it’s a very high risk, while others may find the same vulnerability a low or medium risk. Some tools may not even find the vulnerabilities that other tools identified. For that reason alone, it’s a good idea to use several different tools and look at the findings from a holistic approach.
Because of inconsistencies and tool findings, and because they don’t give the entire picture of how your systems and networks are set up, you have to consider tool findings in addition to other factors when you analyze the results. For example, the tool may tell you that you have ports open on a system that may be high risk, but the tool doesn’t know that you have an application or a valid business process that requires those ports to be open. You may have mitigated the risk of those open ports in a different way, such as by isolating the system on a restricted network, locking down application permissions, installing network security devices to protect the system, and so forth. So, even though a tool finding may indicate that the vulnerability is a high risk, you’ve mitigated that risk down to a lower level through other means, using other compensating security controls. This actually is part of your entire risk assessment, analysis, and mitigation strategy.
False Positives
When you’re looking at tool findings and want a broader picture of how effective security controls are, be aware of false positives and false negatives. A false positive occurs when a tool finds a vulnerability that you know really isn’t one. For example, we’ve seen a popular assessment tool find vulnerabilities associated with Microsoft’s Internet Information Server (IIS) on a Linux box, which is pretty much ridiculous since IIS won’t run on Linux! Of course, this is a fairly off-the-wall example of a false positive. Often, false positives are not so easy to detect and can be quite subtle. You may have to investigate the details of the findings to determine if it’s an actual vulnerability. The good thing about a false positive is that it can be a relief to find that you really don’t have a vulnerability even if the scanner detects one. The bad thing about a false positive is that you may expend resources, such as time and money, on correcting a vulnerability that doesn’t really exist, before you determine it’s a false positive. That’s why it’s a good idea to analyze each vulnerability and get confirmation from another tool or method before you assume that you actually have a vulnerability. False positives can create more work for you as a security person, which reduces your effectiveness in managing other real vulnerabilities.
False Negatives
A false negative, on the other hand, can be a very serious thing. A false negative occurs when your tool doesn’t detect a vulnerability, when in fact one exists. It can also be a process or system that allows unauthorized access, for example, where it should not. This is another reason to use multiple tools when you perform security scanning on your systems. This is also a very good reason for performing in-depth penetration tests. A penetration test can locate vulnerabilities that ordinary vulnerability scanning may not detect, since experienced penetration testers know to try various tools and techniques on different types of systems that may allow them to compromise a system.
Module 38 Questions and Answers
Questions
1. Which of the following types of assessments is designed to tell you what potential negative events may affect the vulnerabilities of a system?
A. Vulnerability scan
B. Threat assessment
C. Penetration test
D. Impact assessment
2. Which of the following are appropriately matched? (Choose two.)
A. Threat and likelihood
B. Vulnerability and likelihood
C. Risk and threat
D. Vulnerability and impact
3. Your manager wants you to attempt to determine what security vulnerabilities may be present in an application before it goes into production. You’re to take the application directly from the programmers and go through the program itself. Which of the following assessment techniques will you use?
A. Architecture review
B. Design review
C. Code review
D. Port scan
4. Which of the following types of assessments actually exploits weaknesses found in a system?
A. Code review
B. Architecture review
C. Vulnerability test
D. Penetration test
5. You are performing a penetration test and are given only some basic information on the target system, including its IP address range and a basic network diagram. What type of penetration tests is this considered to be?
A. Gray box test
B. Black box test
C. White box test
D. Double-blind test
6. A security testing tool that does not interfere with the operation of the system or network at all is considered:
A. Active
B. Passive
C. Less accurate
D. Easily detectable
7. Which of the following tools can be used to capture network traffic for analysis?
A. Vulnerability scanner
B. Port scanner
C. Sniffer
D. Honeynet
8. Which of the following tools would be used to determine what active ports, protocols, and services are running on a host on the network?
A. Wireshark
B. Nmap
C. Honeypot
D. Banner Grabber
9. You’ve just finished scanning your network with a vulnerability scanning tool, and the tool reports several strange vulnerabilities for software you do not have installed on that system. What should you do to verify that those vulnerabilities actually exist on the host?
A. Run a different vulnerability scanner on the same system and compare the results.
B. Assume that all the vulnerabilities are valid and immediately start to remediate them.
C. Assume that all vulnerabilities reported by the tool are invalid and that the system is secure.
D. Rerun the same vulnerability scanner over and over on the system to see if you get different results.
10. Which of the following is considered a dangerous type of finding because it can actually mean that a potential security vulnerability goes undetected?
A. False positive
B. False negative
C. False flag
D. False scan
Answers
1. B. A threat assessment is used to determine the possible negative events that can target the vulnerabilities on a system.
2. A, D. In risk assessments, the likelihood of a threat is determined, as well as a vulnerability and its impact if exploited.
3. C. Code review is an appropriate assessment technique in this case, since you are looking at the program itself before it goes into production.
4. D. A penetration test is designed to exploit any vulnerabilities found in a system.
5. A. A gray box test is one in which the tester is given only limited information on the target network.
6. B. A passive tool does not interfere with the operation or performance of the system or network.
7. C. A sniffer is used to capture network traffic for later analysis.
8. B. Nmap is a popular port scanning tool used to determine what active ports, protocols, and services are running on a network host.
9. A. You should run a different vulnerability scanner on the same system and compare the results to see if the second scanner confirms or disputes the results of the first.
10. B. A false negative can mean that an actual vulnerability goes undetected.