• To identify vulnerabilities that may be evasive or impractical to detect with automated network or application vulnerability scanning software

• To identify high-risk vulnerabilities resulting from an amalgamation of lower risk vulnerabilities exploited in a noteworthy sequence

• To regulate the viability of a particular set of attack vectors

• To assess the magnitude of potential business and operational impacts of successful incidents

• To test the ability of network defenders to successfully detect and counter incidents

• Will the test include a vulnerability list, an activity report, or something else?

• What is the process output or report format?

• Will testers attempt to gain access to control sensitive resources?

• Is there a manual component, or is there just automated scanning?

Port Scanning and Password Cracking

Port scanning is one of the most popular techniques a hacker can use to discover services that can be compromised. For instance, a port scanner will send a TCP SYN request to the host (or range of hosts) set to scan. Ping sweeps are also an option when attempting to define which hosts are available before starting the TCP port scans. Most port scanners only scan TCP ports by default, and some will have UDP by default as well. Some software packages will perform the discovery and auditing of your systems and network, or if you’re really good and know your way around the command line on a switch, you can navigate around a network quickly to locate and there are free open-source programs as well. Network Mapper (NMAP), an open-source license, will allow scanning of UDP packets and is shown in Figure 12.1. Other common programs that can be used, other than NMAP, are SuperScan and NetScan. A scan will probe the accessible hosts for up to 65,535 viable TCP and UDP ports. You can select specific ports you’d like to scan in order to return fewer results, and also filter to view the services available. Port scans provide the following information from accessible hosts on the network:

For your initial scan, it is recommended that you scan all ports from 1 to 65,535. There are many options to get as granular as you want. For instance, a scan can be performed on only well-known ports, or a scan may only involve a certain range of ports specific to your system. If the scanner is unable to find hosts that you are certain would show up, ICMP may be blocked. Once you have concluded what hosts are available and which ports are open, more sophisticate scans can be run to verify that the ports are open and that the tool is not reporting a false positive:

In Chapter 60, denial-of-service attack was one of the many attacks that were described. When running scans, it is possible to create your own denial-of-dervice attack and potentially crash applications or the entire network. Unfortunately, if there is a host on the network with a weak TCP/IP stack, there is no way to prevent your scan from becoming a DoS attack. To reduce the chance of this happening, use slow NMAP timing options when running scans. Refer to Figure 12.1 to see all the options available when running scans.

Password cracking is a process whereby a hacker or a system can retrieve passwords from records that have been stored or transmitted by a system. A popular tactic, and most common, is to try and guess the password. There is always the option to change the password and to state you have forgotten it; that approach works more than most would assume and has destroyed many people’s virtual lives. In an organization, it is always more secure to assign a user a new password rather than allow them to answer a set of questions to recover their forgotten password. Although only administrators can assign new passwords, the extra security layer is a must. When reflecting how all of us have answered a series of questions to regain a forgotten password, consider a program running through a file system, file by file, attempting to obtain the record where the answers to your challenge questions and password are makes complete sense. That is exactly how a password can be cracked.

Encryption is a common process that individuals and organizations practice, and although it may take longer to crack, an encrypted password is easily attainable. If MD5 or SHA1 hash is used to encrypt a string of characters, that encrypted password is then a string of characters that is stored in the database. Rainbow tables of encrypted hashes contain all possible uses of a password, and such tools are available for free downloads. When comparing the rainbow tables and the target hashes, newer computers have a powerful enough processor and graphics card to achieve quantifiable results quickly. Graphic processing units (GPUs) were designed to do supercomputing where high-end math calculations can be done quickly in electronic trading and password cracking. GPUs are much faster than CPUs at calculating predefined tasks and comprise faster memory and wider input/output (I/O) channels to facilitate rapid computations.

There are several ways to limit the effectiveness of the powerful tools available to hackers. Salted hashes are a randomly generated piece of information that is added to the data prior to running it through the hashing process. A salt is arbitrarily generated information that is added to the data before running through the hashing process. Now the encrypted value cannot be cracked using rainbow tables, and the salt will have to be stored in encrypted databases utilizing a different salt for each password. A hacker would have to decrypt the database as well as each password and its record. Two-factor authentication is another technique organizations can use to intensify security measures. This is a form of security that will add greater security, even in the event a hashed password has been breached.

OVAL and CVE

Open Vulnerability and Assessment Language (OVAL) is the standard for determining vulnerability and configuration issues on systems. OVAL is an open community that was created by MITRE, and it is where knowledge can be shared and the content stored may be accessible to the public in an effort to standardize security efforts and how to assess and report systems and their states. OVAL utilitizes a three-step system assessment:

Here is a case where OVAL could be useful: An organization designed their security procedures, protocols, and policies surrounding the Cisco products that were in their infrastructure. Three companies were acquired, and each of the three companies had hardware other than Cisco. Any vulnerability that was found prior to the acquisition and was corrected will no longer be valid once this other hardware is integrated into the infrastructure. Scanning your territory with three or four tools will now yield completely different results, making it more complex and prove that customized needs will have to be developed for the new assessment tool. Vendors, partners, and various other contributors will report the state of their systems, and this data should be referenced anytime your environment changes. The need for open standardization is clear in an example like this, and the process is represented in Figure 12.2.

Through public analysis, direct vendor support, and community contributions, OVAL provides vulnerability content that is reliable and verifiable. OVAL uses the robustness of XML to create a standard language for defining, assessing, and reporting vulnerabilities and configurations. Providing this vulnerability scanning content for the IT industry to collaborate and share technical details allows administrators and engineers to rapidly determine which systems are vulnerable and to rectify those vulnerabilities. And when there is a bug or a false positive, the community is astute to share fixes through use of publicly accessible repositories.

So, where do you go to get this content? There are tools that ship with vulnerability checks and receive regular content updates, or one of the OVAL repositories can assist. Table 12.1 represents the repository and its corresponding platform and content.

New repositories are added to OVAL’s Web site after they have been created and verified. If you are assessing systems for use with the U.S. federal government, the NIST SCAP repository is your area of interest. Microsoft Security Guides, DISA Security Technical Implementation Guides, and Federal Desktop Core Configuration guides have been developed for assessing the systems established on current federal and vendor systems. Whether you are assessing the impact of the latest vulnerability or checking for federal compliance, the substantial public environment of OVAL developers and contributors will provide useful information to you and your infrastructure.

Common Vulnerabilities and Exposures (CVE) provides reference for information security vulnerability and exposures. MITRE assigns a CVE identifier to every vulnerability or exposure. A CVE is used to track vulnerability through different pieces of software, as a single CVE can affect multiple software packages and multiple vendors. The vulnerability is defined as a mistake in the software which may be directly oppressed by an attacker to compromise a system, and an exposure as a fault that could be used as an opportunity to launch an attack. CVE efforts include:

When working with a common identifier, administrators and engineers find it less difficult to share data across separate databases, tools, and services. This data is not only easily accessible but can be integrated with ease. Unless a report comes up stating there is a bug, you’re good to go. CVE is free and available for anyone who is interested in correlating data between diverse vulnerability or security tools, repositories, and services. Anyone could search or download CVE, copy it, redistribute it, reference it, and analyze it, provided you do not modify CVE itself. Companies are allowed to add links and pages to CVE’s Web sites, products, publications, or other capacities. CVE Identifiers, or CVE names, are exclusive and collective identifiers for publicly known information. CVE-2001-0731 references a bug on how Google indexed a file without an external link. A CVE Identifier can be in the form of one of the following:

Using CVEs to identify vulnerabilities and exposures in your organization will allow for accurate and obtainable information from a vast selection of CVE information sources. CVE can help you make informed decisions and determine which of the capabilities are appropriate for your particular needs. Another plus is having the ability to create a suite of interoperable security tools and capabilities available as a translation mechanism.

• Real-time alert configuration: Data centers have become the core of a business, acting as an operations center. Managing logs is a significant step, and it is equally important to access and monitor alerts.

• Proactive protection of the environment: Log management tools and baseline analysis assist an organization to be proactive in their security methodology. Catching holes in security or issues existing, engineers can make a significant difference in time and money. Patching a server is an easy task, but when it is overlooked patch after patch, a vulnerability exists.

• Incident containment: When an unauthorized event occurs in an infrastructure, logs that are set up correctly can alert engineers and pinpoint the exact location quickly. If an engineer can see where the issue resides in a timely manner, that network or server can be isolated to prevent further damage.

• Creation of an audit trail for forensics analysis: When an intrusion is suspected or data loss has occurred, a rockstar audit trail will allow forensic data engineers to retrace the steps taken by someone who has entered the environment and correlate that data into usable information.

• Creation of online documentation as the environment evolves: IT must keep an activity log, tracking all logs across all the environments. Understanding the various systems and how they’re performing allows engineers to shape the infrastructure as the business needs change.

Establishing a Baseline

Two types of alerts should be logged: faults that are generated by the system and the applications running on it, and faults or errors reported by the system’s users. Fault logging and analysis is often the only way of finding out what is unsuitable about a system or application. The analysis of fault logs can be used to identify trends that may indicate deeper issues, such as defective hardware or a lack of competence or training for system administrators or users. All operating systems and many applications, such as database software, provide event logging and basic alerting faculties. This logging functionality should be configured to log all faults and send alerts if the error threshold is above an acceptable, defined threshold. Fault logging and analysis is often the only way to find out what is wrong with a system or an application. Documentation is key when defining which faults to record or report, who is responsible to investigate the faults, and an expected resolution time.

Since data center environments continue to grow, it has become more evident that administrators need to properly manage logs. Checking in on servers, firewalls, appliances, and switching gear event logs will assist IT to do more than simply check for reactive issues. If the process is managed and kept accurate, engineers can create a proactive environment that is capable of spotting and controlling issues before they even arise. Logs can also help an environment plan for the future. Network logs can show engineers where they are lacking and how they can competently plan for growth.

Auditing and Logging

Many devices that provide protection to the infrastructure within networks allow the ability to log events and take actions based on those events. This application system and monitoring provide details both on what has happened to the device and on what is happening in real time. It provides security against lapses in perimeter and application defenses by alerting an administrator about issues, so that defensive measures can be enacted prior to any damage taking place. Without monitoring, an organization does not stand a chance of ascertaining whether a live application is under attack or if it has been compromised.

Business critical applications, processes handling valuable or sensitive information, previously compromised or abused systems, and those systems connected to third parties, all require active monitoring. Whenever suspicious behavior or critical events arise, an alert will be generated and must be acted on. Risk assessments must be done to determine logging levels and which actions are projected from a specified set of alerts. Logging and auditing work together, ensuring that users are only performing the activities they are authorized to perform. This data also plays a key role in preventing, spotting, tracking, and stopping unwanted or inappropriate activities. The levels of alerts, log reviews, and monitoring are an additional necessary component, and at least the following will need to be logged:

When these types of data are collected, that data will assist in access control monitoring and can provide audit trails when an incident is being investigated. Usually, logs are covered by some form of regulation of how many days it should be kept in case they are needed for an investigation. Employees need to be made aware of any firm monitoring policy activities on the network. Log files are a great source of information, but they serve absolutely no purpose if no one monitors them. When a firm purchases and deploys a solution, the product will not provide security unless the information is collected and analyzed on a regular basis. Some procedures require that the results be reviewed regularly to identify possible security threats and incidents. Each company differs in its processes based on the operations and content, and on how attractive that data may be.

Reviewing Policy Settings

Small networks can generate large amounts of information if the log settings are not optimal. Although log analyzers could automate the auditing and analysis of logs, storage for logs may be another challenge. This type of automated feedback frees up your resources, and your engineer can work to refine the log levels or parse through alerts of accurate threats. Recognizing true threats will help reduce the number of false positives. Eliminating false positives, while maintaining strict controls, is next to impossible. New threats and changes in the network infrastructure are ever changing and will likely affect the effectiveness of existing rule sets. Analyzing logs can provide a basis for focused security awareness training, reduced network misuse, and stronger policy enforcement.

Administrators have powerful access, and their activity should also be recorded and checked. A system restart may be prompted to correct serious errors, and those restarts may not be recorded if an administrator disables the alarm. Administrators’ actions should be logged, notating start and finish times, who was involved and at what capacity, and what actions were taken. The name of the individual recording the information also should be recorded, along with the date and time. An organization with an internal audit team needs to maintain these records.

True/False

Multiple Choice

Problem

Why are risk assessment and risk management relevant to information security?

Hands-On Projects

Case Projects

Optional Team Case Project