- "Do I Know This Already?" Quiz
- Foundation Topics
- Exam Preparation Tasks
This chapter is from the book
This chapter is from the book
This chapter is from the book
Foundation Topics
Penetration Testing
A penetration test (often called a pen test) is designed to simulate an attack on a system, a network, or an application. Its value lies in its potential to discover security holes that may have gone unnoticed. It differs from a vulnerability test in that it attempts to exploit vulnerabilities rather than simply identify them. Nothing places the focus on a software bug like the exposure of critical data as a result of the bug.
In many cases, some of the valuable information that comes from these tests is the identification of single operations that, while benign on their own, create security problems when used in combination. These tests can be made more effective when utilized with a framework like Metasploit or CANVAS (discussed Chapter 14, “Using Cybersecurity Tools and Technologies”).
Penetration testing should be an operation that occurs at regular intervals, and its frequency should be determined by the sensitivity of the information on the network. An example of a pen test tool is Retina. Figure 4-1 shows Retina output from scanning a single device. In this output, you can see that the tool has identified eight serious problems (indicated by the upward-pointing arrows): weak encryption in Terminal Services, six weaknesses related to Oracle, and one weakness related to a virtualization product on the machine called Oracle VirtualBox.
)
Figure 4-1 Retina Output
The steps in performing a penetration test are as follows:
Step 1. Planning and preparation
Step 2. Information gathering and analysis
Step 3. Vulnerability detection
Step 4. Penetration attempt
Step 5. Analysis and reporting
Step 6. Cleaning up
Both internal and external tests should be performed. Internal tests occur from within the network, whereas external tests originate outside the network, targeting the servers and devices that are publicly visible.
Strategies for penetration testing are based on the testing objectives, as defined by the organization. The strategies that you should be familiar with include the following:
Blind test: The testing team is provided with limited knowledge of the network systems and devices, using publicly available information. The organization’s security team knows that an attack is coming. This test requires more effort by the testing team, and the testing team must simulate an actual attack.
Double-blind test: This test is like a blind test except the organization’s security team does not know that an attack is coming. Only a few individuals at the organization know about the attack, and they do not share this information with the security team. This test usually requires equal effort for both the testing team and the organization’s security team.
Target test: Both the testing team and the organization’s security team are given maximum information about the network and the type of test that will occur. This is the easiest test to complete but does not provide a full picture of the organization’s security.
Penetration testing is also divided into categories based on the amount of information to be provided. The main categories that you should be familiar with include the following:
Zero-knowledge test: The testing team is provided with no knowledge regarding the organization’s network. The testers can use any means at their disposal to obtain information about the organization’s network. This is also referred to as closed, or black-box, testing.
Partial-knowledge test: The testing team is provided with public knowledge regarding the organization’s network. Boundaries might be set for this type of test.
Full-knowledge test: The testing team is provided with all available knowledge regarding the organization’s network. This test is focused more on what attacks can be carried out.
Other penetration testing applications include Metasploit, Wireshark, CORE Impact, Nessus, Back Track, Cain & Abel, and John the Ripper. When selecting a penetration testing tool, you should first determine which systems you want to test. Then research the different tools to discover which of them can perform the tests that you want to perform for those systems. When you have a tool in mind, research the tool’s methodologies for testing. In addition, the correct individual needs to be selected to carry out the test. Remember that penetration tests should include manual methods as well as automated methods because relying on only one of these two does not result in a thorough result.
Rules of Engagement
The rules of engagement define how penetration testing should occur. These issues should be settled and agreed upon before any testing begins. The following are some of the key issues to be settled:
Timing: The timeline for the test must be established. The start and end times will be included in the scope of the project, but creating the timeline does not mean it cannot change as reality dictates; rather, it means that you have a framework to work from. This also includes the times of day the testing will occur.
Scope: The scope of the test incudes the timeline and also includes a list of all devices that are included in the test, as well as a description of all testing methodologies to be used. The output of this process should be a set of documents that are provided to the tester that include the following:
A network diagram depicting all network segments in scope for the test
A data flow diagram
A list of services and ports exposed at the perimeter
Details of how authorized users access the network
A list of all network segments that have been isolated from the test to reduce scope
Authorization: Formal authorization should be given to the tester to perform the test, with written approval by upper management. Without this, the tester could be liable for attempting to compromise the network.
Exploitation: Before the test occurs, it should be determined whether exploits will be attempted if vulnerable systems are found. This is intentionally included in some cases so the incident response plan can be tested.
Communication: Another of the issues in the rules of engagement is how communications are to occur between the tester and the stakeholders as the process unfolds. While regular meetings should be scheduled, there also must be a line of communication established for times when issues arise and changes may need to be made.
Reporting: The type of reports to be generated is determined during the establishment of the rules of engagement. This includes the timing of reports, the format, and the specific information to be included. While postponing of reports should be allowed, it should not be allowed to become chronic, and the rules of engagement may include both incentives and penalties for the timelessness of reports.
Reverse Engineering
Reverse engineering is a term that has been around for some time. Generically, it means taking something apart to discover how it works and perhaps to replicate it. In cybersecurity, it is used to analyze both hardware and software and for various other reasons, such as to do the following:
Discover how malware functions
Determine whether malware is present in software
Locate software bugs
Locate security problems in hardware
The following sections look at the role of reverse engineering in cybersecurity analysis.
Isolation/Sandboxing
You may be wondering what the concepts of isolation and sandboxing are doing in a section on reverse engineering. How can you analyze malware without suffering the effects of the malware? The answer is to place the malware where it is safe to probe it and play with it. This is done by isolating, or sandboxing, the malware. You can use a sandbox to run a possibly malicious program in a safe environment so that it doesn’t infect the local system.
By using sandboxing tools, you can execute malware executable files without allowing the files to interact with the local system. Some sandboxing tools also allow you to analyze the characteristics of an executable. There are cases when this is not possible because malware can be specifically written to do different things if it detects that it’s being executed in a sandbox.
In many cases, sandboxing tools operate by sending a file to a special server that analyzes the file and sends you a report on it. Sometimes this is a free service, but in many instances it is not. Some examples of these services include the following:
Sandboxie
Akana
Binary Guard True Bare Metal
BitBlaze Malware Analysis Service
Comodo Automated Analysis System and Valkyrie
Deepviz Malware Analyzer
Detux Sandbox (Linux binaries)
Another option for studying malware is to set up a sheep dip computer. This is a system that has been isolated from the other systems and is used for analyzing suspect files and messages for malware. You can take measures such as the following on a sheep dip system:
Install port monitors to discover ports used by the malware.
Install file monitors to discover what changes may be made to files.
Install network monitors to identify what communications the malware may attempt.
Install one or more antivirus programs to perform malware analysis.
Often these sheep dip systems are combined with antivirus sensor systems to which malicious traffic is reflected for analysis.
The safest way to perform reverse engineering and malware analysis is to prepare a test bed. Doing so involves the following steps:
Step 1. Install virtualization software on the host.
Step 2. Create a VM and install a guest operating system on the VM.
Step 3. Isolate the system from the network by ensuring that the NIC is set to “host” only mode.
Step 4. Disable shared folders and enable guest isolation on the VM.
Step 5. Copy the malware to the guest operating system.
Also, you need isolated network services for the VM, such as DNS. It may also be beneficial to install multiple operating systems in both patched and non-patched configurations. Finally, you can make use of virtualization snapshots and re-imaging tools to wipe and rebuild machines quickly.
Once the test bed is set up, you also need to install a number of other tools to use on the isolated VM, including the following:
Imaging tools: You need these tools to take images for forensics and prosecution procedures. Examples include Safe Back Version 2.0 and DD (which is covered in Chapter 14).
File/data analysis tools: You need these tools to perform static analysis of potential malware files. Examples include PE Studio and PEframe.
Registry/configuration tools: You need these tools to help identify infected settings in the registry and to identify the last saved settings. Examples include Microsoft’s Sysinternals Autoruns and Silent Runners.vbs.
Sandbox tools: You need these tools for manual malware analysis (listed earlier in this chapter, the “Isolation/Sandboxing” section)
Log analyzers: You need these tools to extract log files. Examples include AWStats and Apache Log Viewer.
Network capture tools: You need these tools to understand how the malware uses the network. Examples include Wireshark and Omnipeek.
While the use of virtual machines to investigate the effects of malware is quite common, you should know that some well-written malware can break out of a VM relatively easily, making this approach problematic.
Hardware
You must be concerned with the safety and the integrity of the hardware that you purchase. The following are some of the methods used to provide this assurance:
Source authenticity of hardware: When purchasing hardware to support any network or security solution, a security professional must ensure that the hardware’s authenticity can be verified. Just as expensive consumer items such as purses and watches can be counterfeited, so can network equipment. While the dangers with counterfeit consumer items are typically confined to a lack of authenticity and potentially lower quality, the dangers presented by counterfeit network gear can extend to the presence of backdoors in the software or firmware. Always purchase equipment directly from the manufacturer when possible, and when purchasing from resellers, use caution and insist on a certificate of authenticity. In any case where the price seems too good to be true, keep in mind that it may be an indication the gear is not authentic.
Trusted Foundry: The Trusted Foundry program can help you exercise care in ensuring the authenticity and integrity of the components of hardware purchased from a vendor. This DoD program identifies “trusted vendors” and ensures a “trusted supply chain.” A trusted supply chain begins with trusted design and continues with trusted mask, foundry, packaging/assembly, and test services. It ensures that systems have access to leading-edge integrated circuits from secure, domestic sources. At the time of this writing, 77 vendors have been certified as trusted.
OEM documentation: One of the ways you can reduce the likelihood of purchasing counterfeit equipment is to insist on the inclusion of verifiable original equipment manufacturer (OEM) documentation. In many cases, this paperwork includes anti-counterfeiting features. Make sure to use the vendor website to verify all the various identifying numbers in the documentation.
Software/Malware
Software of any type can be checked for integrity to ensure that it has not been altered since its release. Checking for integrity is one of the ways you can tell when a file has been corrupted (or perhaps replaced entirely) with malware. Two main methods are used in this process:
Fingerprinting/hashing: Fingerprinting, or hashing, is the process of using a hashing algorithm to reduce a large document or file to a character string that can be used to verify the integrity of the file (that is, whether the file has changed in any way). To be useful, a hash value must have been computed at a time when the software or file was known to have integrity (for example, at release time). Then at any time thereafter, the software file can be checked for integrity by calculating a new hash value and comparing it to the value from the initial calculation. If the character strings do not match, a change has been made to the software.
Fingerprinting/hashing has been used for some time to verify the integrity of software downloads from vendors. The vendor provides the hash value and specifies the hash algorithm, and the customer recalculates the hash value after the download. If the result matches the value from the vendor, the customer knows the software has integrity and is safe.
Anti-malware products also use this process to identify malware. The problem is that malware creators know this, and so they are constantly making small changes to malicious code to enable the code to escape detection through the use of hashes or signatures. When they make a small change, anti-malware products can no longer identify the malware, and they won’t be able to until a new hash or signature is created by the anti-malware vendor. For this reason, some vendors are beginning to use “fuzzy” hashing, which looks for hash values that are similar but not exact matches.
Decomposition: Decomposition is the process of breaking something down to discover how it works. When applied to software, it is the process of discovering how the software works, perhaps who created it, and, in some cases, how to prevent the software from performing malicious activity.
When used to assess malware, decomposition can be done two ways: statically and dynamically. When static or manual analysis is used, it takes hours per file and uses tools called disassemblers. Advanced expertise is required. Time is often wasted on repetitive sample unpacking and indicator extraction tasks.
With dynamic analysis tools, an automated static analysis engine is used to identify, de-archive, de-obfuscate, and unpack the underlying object structure. Then proactive threat indicators (PTI) are extracted from the unpacked files. A rules engine classifies the results to calculate the threat level and to route the extracted files for further analysis. Finally, the extracted files are repaired to enable further extraction or analysis with a sandbox, decompiler, or debugger. While the end result may be the same, these tools are much faster and require less skill than manual or static analysis.
Training and Exercises
Security analysts must practice responding to security events in order to react to them in the most organized and efficient manner. There are some well-established ways to approach this. This section looks at how teams of analysts, both employees and third-party contractors, can be organized and some well-established names for these teams.
Security posture is typically assessed by war game exercises in which one group attacks the network while another attempts to defend the network. These games typically have some implementation of the following teams:
Red team: The Red team acts as the attacking force. It typically carries out penetration tests by following a well-established process of gathering information about the network, scanning the network for vulnerabilities, and then attempting to take advantage of the vulnerabilities. The actions they can take are established ahead of time in the rules of engagement. Often these individuals are third-party contractors with no prior knowledge of the network. This helps them simulate attacks that are not inside jobs.
Blue team: The Blue team acts as the network defense team, and the attempted attack by the Red team tests the Blue team’s ability to respond to the attack. It also serves as practice for a real attack. This includes accessing log data, using a SIEM, garnering intelligence information, and performing traffic and data flow analysis.
White team: The White team is a group of technicians who referee the encounter between the Red team and the Blue team. Enforcing the rules of engagement might be one of the White team’s roles, along with monitoring the responses to the attack by the Blue team and making note of specific approaches employed by the Red team.
Risk Evaluation
Although penetration testing can identify vulnerabilities, it is not the recommended way to identify vulnerabilities. An organization should have a well-defined risk management process in place that includes the evaluation of risk that is present. When this process is carried out properly, threat modeling allows organizations to identify threats and potential attacks and implement the appropriate mitigations against these threats and attacks. These facets ensure that any security controls implemented are in balance with the operations of the organization. The three parts to this process are covered in the following sections.
Technical Impact and Likelihood
Once all assets have been identified and their value to the organization has been established, specific threats to each asset are identified. An attempt must be made to establish both the likelihood of the threat’s realization and the impact to the organization if it occurs. While both quantitative and qualitative risk assessments may be performed, when a qualitative assessment is conducted, the risks are placed into the following categories:
High
Medium
Low
Typically, a risk assessment matrix, such as the one in Figure 4-2, is created. Subject experts grade all risks based on their likelihood and impact. This helps prioritize the application of resources to the most critical vulnerabilities.
)
Figure 4-2 Risk Assessment Matrix
Technical Control Review
Technical controls are implemented with technology and include items such as firewalls, access lists, permissions on files and folders, and devices that identify and prevent threats. After it understands the threats, an organization needs to establish likelihoods and impacts, and it needs to select controls that, while addressing a threat, do not cost more than the cost of the realized threat. The review of these controls should be an ongoing process.
Operational Control Review
Operational controls are the policies, procedures, and work practices that either help prevent a threat or make the threat more likely. The review of these controls should be an ongoing process.
