CompTIA Security SY0-601 Exam: Host and Application Security Solutions

Objective: Given a scenario, implement host or application security solutions.

Topics:
- antivirus
- anti-malware
- endpoint detection and response (EDR)
- data loss prevention (DLP)
- host-based intrusion prevention system (HIPS)
- host-based intrusion detection system (HIDS)
- host-based firewall
- boot integrity
- database tokenization
- secure cookie
- code signing
- allow list
- block list/deny list
- static code analysis
- dynamic code analysis
- fuzzing
- system hardening
- self-encrypting drive (SED)
- full disk encryption (FDE)
- hardware root of trust
- Trusted Platform Module (TPM)
- sandboxing

Endpoint Protection
Organizational attacks are likely to continue increasing in complexity, and all host devices must have some type of malware protection. Malicious code authors are using the dark parts of the Internet to create smarter, shadier, and stealthier threats. Worse, those authors can adeptly camouflage their work.

Firewalls and HIPS/HIDS Solutions
Desktops and laptops need to have layered security, just as servers do. However, many organizations stop this protection at antivirus software. In today’s environment, that might not be enough to ward off malware, phishing, and rootkits. One of the most common ways to protect desktops and laptops is to use a host firewall. A firewall can consist of hardware, software, or a combination of both. This guide focuses on software firewalls, or host-based firewalls that can be implemented in the user environment.
The potential for hackers to access data through a user’s machine has grown substantially as hacking tools have become more sophisticated and difficult to spot. This is especially true for telecommuters’ machines. Always-connected computers, typically with cable modems, give attackers plenty of time to discover and exploit system vulnerabilities. Many software firewalls are available, and most operating systems come with them. Users can opt for the OS vendor firewall or can install a separate host-based firewall.
Firewalls have strengths and weaknesses. By design, firewalls close off systems to scanning and entry by blocking ports or nontrusted services and applications. However, firewalls must be properly configured. Typically, the first time a program tries to access the Internet, a software firewall asks whether it should permit the communication. Some users might find this annoying and, consequently, either disable the firewall or else allow all communications because they do not understand what the software is asking. Another caveat is that some firewalls monitor only for incoming connections, not outgoing ones. Monitoring outbound connections is important in the case of malware that “phones home.” Without this type of protection, the environment is not properly protected. Remember that even a good firewall cannot protect you if users do not think before downloading and do not exercise a proper level of caution. No system is foolproof, but software firewalls installed on user systems can help make the computing environment safer.
Host-based intrusion detection system (HIDS) solutions involve processes running on a host monitoring event, application logs, port access, and other running processes to identify signatures or behaviors that indicate an attack or unauthorized access attempt. Some HIDS solutions involve deploying on each host individual client applications that relay their findings to a central IDS server, which is responsible for compiling the data to identify distributed trends. 

Strengths of Host-Based IDS Solutions

Host-based intrusion prevention system (HIPS) solutions are a necessity in any enterprise environment. HIPS solutions protect hosts against known and unknown malicious attacks from the network layer up through the application layer. HIPS technologies can be categorized based on what they scan for, how they recognize an attack, and at what layer they attempt to detect the attack. HIPS systems encompass many technologies to protect servers, desktops, and laptops. A HIPS may be used as an all-in-one solution that includes everything from traditional signature-based antivirus technology to behavior analysis.
The exam might use two different acronyms in intrusion detection questions: NIDS and NIPS. A network-based intrusion detection system (NIDS) examines data traffic to identify unauthorized access attempts and generate alerts. Network-based intrusion prevention system (NIPS) solutions are intended to provide direct protection against identified attacks. A NIDS solution might be configured to automatically drop connections from a range of IP addresses during a DoS attack, for example.
When using HIDS/HIPS solutions, you leave the security decisions up to the user. When a program runs with elevated privileges or for the first time, it gives the user the option to either allow or block the action. The system is only as good as the user’s response. Most users choose the Allow option, inadvertently allowing the system to be infected.
In analyzing the output from HIDS and HIPS solutions, the biggest issue is false positives. For example, a HIPS monitors changes that other software programs attempt to make on the local system. Registry keys are problematic because a legitimate program is likely to add a key upon installation, and a HIPS may flag this as a malicious action.
Often a file integrity checker is included as part of an IDS. For example, Advanced Intrusion Detection Environment (AIDE) is a file and directory integrity checker for use on Linux-based systems.
A file integrity checker tool computes a cryptographic hash such as SHA-1 or MD5 for all selected files and creates a database of the hashes. The hashes are periodically recalculated and compared to the hashes in the database to check for modification.
The primary purpose of a file integrity checker is to detect when a file has been improperly modified. As with HIDS/HIPS solutions, the biggest issue is false positives. Files often make changes when an application is updated or OS updates are applied. Keeping the hash database current is challenging, especially if it does not run in real time or is not run on a regular basis. File checkers serve a good purpose, of course, and even if the file integrity checker is run only once, the database information can provide a baseline record to let you know whether a file has been modified. This brings us to another problem with file integrity checkers: File integrity checkers should be run when a system is first installed, to create a clean database. If they are run after the system hits the Internet and a user starts downloading or installing files, the system might already be compromised. It is also a good security practice to store the hash database on a server offline so that attackers cannot alter it.

Anti-Malware and Other Host Protections
Antivirus software is a necessary software program for protecting the user environment. Antivirus software scans for malicious code in email and downloaded files. Antivirus software, in a way, works backward. Virus writers release a virus, it is reported, and then antivirus vendors reverse-engineer the code to find a solution. After the virus has been analyzed, the antivirus software can look for specific characteristics of the virus. Remember that, for a virus to be successful, it must replicate its code.
The most common method used in an antivirus program is scanning. Scanning involves searching files in memory, the boot sector, and the hard drive and removable media for identifiable virus code. Scanning identifies virus code based on a unique string of characters known as a signature. When the virus software detects the signature, it isolates the file. Then, depending on the software settings, the antivirus software either quarantines the virus or permanently deletes it. Interception software detects virus-like behavior and pops up a warning to the user; however, because the software looks only at file changes, it might also detect legitimate files.
In the past, antivirus software used a heuristic engine to detect virus structures or used integrity checking as a method of file comparison. A false positive occurs when the software classifies an action as a possible intrusion when it is actually a nonthreatening action.
Heuristic scanning looks for instructions or commands that are not typically found in application programs. However, these methods are susceptible to false positives and cannot identify new viruses until the database is updated.
Antivirus software vendors update their virus signatures on a regular basis. Most antivirus software connects to the vendor website to check the software database for updates and then automatically downloads and installs them as they become available. Besides setting your antivirus software for automatic updates, you should set the machine to automatically scan at least once a week. If a machine does become infected, it needs to be removed from the network as quickly as possible so that it cannot damage other machines.
The best defense against virus infection is user education. Most antivirus software used today is fairly effective, but only if it is kept updated and the user practices safe computing habits, such as not opening unfamiliar documents or programs. However, antivirus software cannot protect against brand-new viruses. Furthermore, users often do not take the necessary precautions and might even disable antivirus software if it interferes with programs that are currently installed on the machine. Be sure to guard against this type of incident through a combination of education and enabling tamperproof controls if available.
Especially in large enterprises, antivirus software has expanded to what is now generally known as anti-malware, given the range of the threats detected. Advanced malware, such as ransomware, is complex malware that includes components such as command and control, data exfiltration, and payload execution. Traditional antivirus programs are ineffective against such malware because the malware uses a variety of techniques to obscure and avoid detection.
Advanced malware tools use behavior-based and context-based detection methods instead of signature-based methods.
Advanced malware tools employ various methods to detect malware, including sandboxing and indicator of compromise (IoC) capabilities. Characteristics include continuous analysis and big data analytics. The main point to remember about advanced malware tools is that they tend to be complex enterprise solutions that are built to protect organizations before, during, and after a malware attack. For example, Cisco’s Advanced Malware Protection uses real-time threat intelligence and dynamic malware analytics, along with continuous analysis. This tool can be deployed on endpoints, networks, and firewalls, as well as in cloud-based environments.
Antispam software is often part of antivirus software or a host security suite. Antispam software can add another layer of defense to the infrastructure. The most common installation locations are at the email server or email client. When the software and updates are installed on a central server and pushed out to the client machines, this is a centralized solution. When the updates are left up to the individual users, it is a decentralized environment. The main component of antispam software is heuristic filtering, which compares incoming email information against a predefined rule set. The software reads the contents of each message and compares the words in that message against the words in typical spam messages. Each rule assigns a numeric score to the probability that the message is spam. This score is then used to determine whether the message meets the acceptable level set. If many of the same words from the rule set are in the message being examined, the message is marked as spam. Specific spam filtering levels can be set on the user’s email account. If the setting is high, more spam will be filtered, but this can also trigger false positives and lead to legitimate email being filtered as spam.
Naturally, software cannot assign meaning to the words it examines. It simply tracks and compares the words used.
Additional settings can be used in a rule set. An email address that you add to the approved list—the allow list—is never considered spam. Using an allow list gives you flexibility in the type of email you receive. For example, adding the addresses of your relatives or friends to your allow list permits you to receive any type of content from them. Conversely, an email address that you add to a blocked list—known as a block or deny list—is always considered spam. Other factors might affect the ability to receive email on a allow list. For example, if attachments are not allowed and the email has an attachment, the message might be filtered even if the address is on the approved list.
For additional host protection, many antispyware programs are available. These programs scan a machine, much as antivirus software scans for viruses. As with antivirus software, it is important to keep antispyware programs updated and regularly run scans. Configuration options on antispyware software allow the program to check for updates on a regularly scheduled basis. Antispyware software should be set to load upon startup and to automatically update spyware definitions.
Most online toolbars come with pop-up blockers. In addition, various downloadable pop-up blocking software programs are available; the browsers included with some operating systems, such as Windows, can block pop-ups. As with much of the other defensive software discussed so far, pop-up blockers have settings that you can adjust. Try setting the software to a medium level so that it will block most automatic pop-ups but still allow functionality. Keep in mind that you can adjust the settings on pop-up blockers to meet organizational policy or to best protect the user environment.
Several caveats apply when using pop-up blockers. Remember that some pop-ups are helpful, and some web-based programmed application installers actually use pop-ups to install software.
If all pop-ups are blocked, the user might not be able to install certain applications or programs.
It is possible to circumvent pop-up blockers in various ways. Most pop-up blockers block only JavaScript and do not block other technologies, such as Flash. On some Internet browsers, holding down the Ctrl key while clicking a link allows the browser to bypass the pop-up filter.

Endpoint Detection and Response (EDR)
Many of the solutions discussed previously now are available with endpoint detection and response (EDR) solutions. EDR isn’t necessarily focused on prevention. The idea is to provide a layered solution that assumes something may not have been prevented. As a result, the goal of EDR is to detect and respond. EDR technology often uses a combination of machine learning and behavioral analytics to detect suspicious activity. Today EDR plays a predominant role as part of an overall endpoint security strategy. EDR solutions generally provide the following capabilities beyond anti-malware and antispyware:
- Application allow list
- Data loss prevention
- Full disk encryption
- Application control
- Host-based firewall
- Targeted attack analytics and behavioral forensics
- Intrusion detection and intrusion prevention

Data Execution Prevention (DEP)
Data execution prevention (DEP) is a security technology that can prevent security threats from executing code on a system.
DEP works by preventing malware from executing in memory space that is reserved for operating system processes. DEP can be either hardware or software based.
Hardware-based DEP prevents code from being executed by using processor hardware to set a memory attribute designating that code should not run in that memory space. Both AMD and Intel platforms have DEP hardware capabilities for Windows-based systems. Software-based DEP prevents malicious code from taking advantage of exception-handling mechanisms in Windows by throwing an exception when the injected code attempts to run. This essentially blocks the malware from running the injected code.
Software-based DEP works even if hardware DEP is not available but is more limited. Its main function is to block malicious programs that use exception-handling mechanisms in Windows for execution. Sometimes older, nonmalicious programs trigger DEP due to faulty coding.

Data Loss Prevention (DLP)
Data loss is a problem that all organizations face, and it can be especially challenging for global organizations that store a large volume of PII in different legal jurisdictions. Privacy issues differ by country, region, and state. Organizations implement data loss prevention tools as a way to prevent data loss. Data loss prevention (DLP) tools can detect and prevent confidential data from being exfiltrated physically or logically from an organization by accident or on purpose. DLP systems are basically designed to detect and prevent unauthorized use and transmission of confidential information, based on one of the three states of data: in use, in motion, or at rest.
DLP systems offer a way to enforce data security policies by providing centralized management for detecting and preventing the unauthorized use and transmission of data that the organization deems confidential. A well-designed DLP strategy allows control over sensitive data, reduces the cost of data breaches, and achieves greater insight into organizational data use. International organizations should ensure that they are in compliance with local privacy regulations before implementing DLP tools and processes.
Protection of data in use is considered an endpoint solution. In this case, the application is run on end-user workstations or servers in the organization. Endpoint systems also can monitor and control access to physical devices such as mobile devices and tablets. Protection of data in transit is considered a network solution, and either a hardware or software solution is installed near the network perimeter to monitor and flag policy violations. Protection of data at rest is considered a storage solution and is generally a software solution that monitors how confidential data is stored.
When evaluating DLP solutions, key content-filtering capabilities to look for are high performance, scalability, and the capability to accurately scan nearly anything. High performance is necessary to keep the end user from experiencing lag time and delays. The solution must readily scale as both the volume of traffic and bandwidth needs increase. The tool should also be capable of accurately scanning nearly anything.

Here are some examples of security policy violations an endpoint solution would flag and alert a user about in order to prevent sensitive information from leaving the user’s desktop:
- Forwarding an email with sensitive information to unauthorized recipients inside or outside the organization
USB flash drives and other portable storage devices are pervasive in the workplace and pose a real threat. They can introduce viruses or malicious code to the network and can store sensitive corporate information. Sensitive information is often stored on thumb and external hard drives, which then may be lost or stolen. DLP solutions allow policies for USB blocking, such as a policy to block the copying of any network information to removable media or a policy to block the use of unapproved USB devices.
Although some DLP solutions provide remediation processes, an incident generally means that data has been lost. Be sure the proper protections are put in place.

Removable Media Control
Most DLP solutions have the capability to control or manage removable media such as USB devices, mobile devices, email, and storage media. In many instances, banning USB and not permitting copying to devices is not an acceptable solution. For example, thumb drives were banned after malicious software infected thousands of military computers and networks. The ban was a major inconvenience for those who relied on thumb drives. Aircraft and vehicle technicians stored manuals on thumb drives. Medical records of wounded troops were sometimes stored on thumb drives and accompanied patients from field hospitals in foreign countries to their final U.S.-based hospitals. Pilots used thumb drives to transfer mission plans from operations rooms to aircraft computers.
When employees must use removable drives, finding a way to secure data that is taken outside a managed environment is part of doing business. Encryption is essential. Some disk encryption products protect only the local drive, not USB devices. Other encryption products automatically encrypt data that is copied or written to removable media. Other solutions include antivirus software that actively scans removable media and grants access to only approved devices. In a Windows environment, group policy objects (GPOs) offer another solution.

Application Allow/Block Lists
Organizations control application installations by using either an allow list or a block list/deny list. Placing applications on an block or deny list involves listing all applications that the organization deems undesirable or banned and then preventing those applications from being installed. The concept of a block/deny list for applications is similar to the way antivirus software works. A block/deny list is generally done to reduce security-related issues, but organizations also can block time-wasting or bandwidth-intensive applications.
An allow list for applications tends to make an environment more closed by allowing only approved applications to be installed. You may be already familiar with an allow list being known as a whitelist, and a block/deny list being known as a blacklist. Remember the industry is moving away from the use of the whitelist/blacklist terms.
An allow list approach uses a list of approved applications. If an application is not on the approved list of software, the application installation is denied or restricted. An allow list is the preferred method of restricting applications because the approved apps can be allowed to run using numerous methods of trust. This decreases the risk of infection and improves system stability.

Web Application Firewall
In response to the onslaught of web-based attacks, many organizations have implemented web application firewalls in addition to network firewalls. Put simply, a web application firewall is software or a hardware appliance used to protect an organization’s web server from attack. A web application firewall can be an appliance, a server plug-in, or a filter that is used specifically for preventing execution of common web-based attacks such as Cross-Site Scripting (XSS) and SQL injection on a web server. Web application firewalls can be either signature based or anomaly based. Some look for particular attack signatures to try to identify an attack, whereas others look for abnormal behavior outside the website’s normal traffic patterns. The device sits between a web client and a web server and analyzes communication at the application layer, much like a network stateful-inspection firewall. A web application firewall is placed in front of a web server in an effort to shield it from incoming attacks. Web application firewalls are sometimes referred to as deep packet inspection (DPI) firewalls because they can look at every request and response within web service layers.

Application Security
Application security begins with secure coding practices. Validating all data that can be provided to an application is one of the most important controls you should be familiar with. Lack of proper validation also leads to many of the top application security risks. Applications that take input from a source such as a user should be able to properly and safely handle that data before it is passed along for further processing. Special characters, markup, and other formatted code might be filtered out. At the least, you don’t want that data to be interpreted so that it performs an unexpected or authorized task. Such input could also cause errors and other unexpected results.
After initial development, most executables designed to install and run on a device are digitally signed in a process known as code signing. Code signing provides validation of the author’s identity and provides assurance that the software code has not been tampered with since it was signed. Many operating systems block or alert the installation of software that has not been signed by a trusted certificate authority (CA).
Cloud-based applications or applications designed for delivery over a network using a web browser depend on many of the same secure coding techniques as traditional applications. The use of secure cookies is a unique requirement you should be familiar with. When a client interacts with the server, the server provides a response in the Hypertext Transfer Protocol (HTTP) header that instructs the client’s web browser to create one or more cookies, which are used to store data. This data is used with future requests when interacting with the associated sites.
Although websites are increasingly defaulting to being secure HTTPS sites, web application developers should only allow cookies to be used with HTTPS through the use of the Secure attribute. This attribute prohibits cookies from being transmitted over unencrypted HTTP to prevent the contents of the cookie from being read by a malicious actor.
During the development process—and certainly before code is released into production—code should be analyzed for mistakes and vulnerabilities. One method of analysis is manual secure code review, which is a laborious process of going line by line through the code to ensure that it is ready. While the software belonging to many organizations may never reach the 50 million lines of code in Microsoft Windows 10 or the 2 billion lines of code across Google services, modern software and web applications are too large to rely on manual code review only. Therefore, automated tools are used and often integrated into the development process. The following sections discuss some of these tools.

Code Analyzers
Quality assurance and testing processes directly affect code quality. The earlier defects in software are found, the easier and cheaper they are to fix. The benefits of implementing a sound QA and testing process far outweigh the associated costs. The SDLC must include quality code and testing: Reports of website vulnerabilities and data breaches are reported in the news almost daily. Providing quality software also builds a positive reputation for an organization and gives customers confidence in the products they are purchasing.

Static Code Analyzers
Static code analysis is performed in a non-runtime environment. Typically, a static analysis tool inspects the code for all possible runtime behaviors and looks for problematic code such as backdoors or malicious code.
Static analysis is a white-box software testing process for detecting bugs. The idea behind static analysis is to take a thorough approach to bug detection in the early stages of program development.
The same kind of compiler is used in static code analyzers that is used to compile code. Integrating a source code analyzer into a compiler makes the best use of the compiler and reduces complexity. The code analyzer can use preexisting compiler data flow algorithms to perform analysis. The analysis is a complete program analysis that checks complex code interactions. Static code analyzers can detect a wide array of vulnerabilities, including memory leaks.

Dynamic Analysis
As noted in the previous section, static code analysis is performed without executing any code. Dynamic code analysis is based on observing how the code behaves during execution. Dynamic analysis is done while a program is in operation and monitors functional behavior and overall performance. Dynamic analysis uses a technique called fuzzing, which enables an attacker to inject random-looking data into a program to see if it can cause the program to crash.
Fuzzing is a black-box software-testing process in which semi-random data is injected into a program or protocol stack to detect bugs.
A systematic discovery approach should find application bugs sooner or later. The data generation part consists of generators. Generators typically use combinations of static fuzzing vectors or totally random data. Vulnerability identification relies on debugging tools. Most fuzzers are either protocol/file format dependent or data type dependent. New-generation fuzzers use genetic algorithms to link injected data and observed impact. OWASP provides a web page on fuzz vector resources, which is a great source for fuzzing methodology and real-life fuzzing vector examples.

Several different types of fuzzing exist:
- Application fuzzing: Attack vectors are within an application’s inputs and outputs—for example, the user interface, the command-line options, URLs, forms, user-generated content, and RPC requests.
- Protocol fuzzing: Forged packets are sent to the tested application, which can act as a proxy and modify requests on the fly and then replay them.
- File format fuzzing: Multiple malformed samples are generated and then opened sequentially. When the program crashes, debugging information is kept for further investigation.
An advantage of fuzzing is that the test design is generally very simple, without any presumptions about system behavior. This approach makes it possible to find bugs that human testing would miss. With a closed application, fuzzing might be the only means of reviewing the security quality of the program.
The simplicity of fuzzing can be a disadvantage because it may not find more advanced bugs. In addition, a fuzzer that is very protocol aware tends to miss odd errors.
While fuzzers may generate data using known dangerous values, the use of random data is still a good idea for best results. Fuzzing can add another dimension to normal software-testing techniques.

Stress Testing
Stress testing measures how much stress an application or program can withstand before it breaks. Stress testing uses methods to overload the existing resources in an attempt to break the application. The primary purpose of stress testing is to assess the behavior of the application beyond normal conditions. It serves the following purposes:
- Offers a method of nonfunctional testing
- Identifies the breaking point of the application
- Determines application stability
- Provides statistics on application availability and error handling under high usage
- Produces information on crash conditions under lack of resources
- Provides a reference point for application robustness and stability

Application Sandboxing
Sandboxing allows programs and processes to be run in an isolated environment, to limit access to files and the host system. Running a program or file in a sandbox contains it so that it can be tested, and this reduces some security issues because the program or file cannot harm the host or make any changes to the host. In software development, especially when Agile methods are used, common best practice is to ensure that each developer works in his or her own sandbox. A sandbox is basically a technical environment whose scope is well defined and respected. Sandboxing reduces the risk of programming errors adversely affecting an entire team. In software development, the following types of sandboxes can be used:
- Development
- Project integration
- Demo
- Preproduction test or QA
- Production
Organizations that use development sandboxes have the distinct advantage of being able to scan applications more frequently and early in the SDLC. Their development teams are cognizant of application security, detect issues early in the process, and reduce risk to the organization.

Hardware and Firmware Security
Security begins at the hardware level. When a device is infected at the hardware or firmware level, the root cause might evade detection for an extended period of time simply because people tend to implicitly trust hardware and firmware. In today’s environment, however, hardware and firmware are no longer trustworthy and need to be secured. As the Internet of Things (IoT) grows, firmware- and hardware-based exploits will become more common in the very near future.

FDE and SED
Full disk encryption (FDE), also called whole disk encryption, is commonly used to mitigate the risks associated with lost or stolen mobile devices and accompanying disclosure laws.
FDE can be either hardware or software based. Unlike file- or folder-level encryption, FDE is meant to encrypt the entire contents of a drive—even temporary files and memory.
FDE involves encrypting the operating system partition on a computer and then booting and running with the system drive encrypted at all times. If the device is stolen or lost, the OS and all the data on the drive become unreadable without the decryption key.
Unlike selective file encryption, which might require the end user to take responsibility for encrypting files, encryption of the contents of an entire drive takes the onus off individual users.
As an example of full disk encryption, BitLocker is an FDE feature included with Microsoft Windows OSs. It is designed to protect data by providing encryption for entire volumes. By default, BitLocker uses the Advanced Encryption Standard (AES) encryption algorithm.
Encrypting File System (EFS) is a feature of Microsoft Windows OSs that provides filesystem-level encryption. EFS enables files to be transparently encrypted to protect confidential data from attackers who gain physical access to the computer. By default, no files are encrypted, so the encryption must be enabled. The user encrypts files on a per-file, per-directory, or per-drive basis. Some EFS settings can be implemented through Group Policy in Windows domain environments, which gives the organization a bit more control.
It is not unusual for end users to sacrifice security for convenience, especially when they do not fully understand the associated risks. Nevertheless, along with the benefits of whole disk encryption come certain trade-offs. For example, key management becomes increasingly important as loss of the decryption keys could render the data unrecoverable. In addition, although FDE might make it easier for an organization to deal with a stolen or lost device, the fact that the entire drive is encrypted could present management challenges, including the inability to effectively control who has unauthorized access to sensitive data.
After a device with FDE is booted and running, it is just as vulnerable as a drive that has no encryption on it.
The term self-encrypting drive (SED) is often used when referring to FDE on hard disks. The Trusted Computing Group (TCG) security subsystem storage standard Opal provides industry-accepted standardization SEDs. SEDs automatically encrypt all data in the drive, preventing attackers from accessing the data through the operating system. SED vendors include Seagate Technology, Hitachi, Western Digital, Samsung, and Toshiba.
Firmware and hardware implement common cryptographic functions. Disk encryption that is embedded in the hard drive provides performance that is very close to that of unencrypted disk drives; the user sees no noticeable difference from using an unencrypted disk. Advantages of hardware drive encryption include faster setup time, enhanced scalability, improved portability, and better system performance. Disadvantages include lack of management software and weak authentication components. Coupled with hardware-based technologies, a SED can achieve strong authentication. You can use hardware drive encryption to protect data at rest because all the data—even the OS—is encrypted with a secure mode of AES.
With hardware drive encryption, authentication happens on drive power-up either through a software preboot authentication environment or with a BIOS password. Enhanced firmware and special-purpose cryptographic hardware are built into the hard drive.

To effectively use FDE products, you should also use a preboot authentication mechanism. That is, the user attempting to log on must provide authentication before the operating system boots. Thus, the encryption key is decrypted only after another key is input into this preboot environment. Vendors offer a variety of preboot authentication options, such as the following:
- Username and password: This is typically the least secure option.
- Smart card or smart card–enabled USB token along with a PIN: This option provides two-factor functionality, and the smart card can often be the same token or smart card currently used for access elsewhere.
- Trusted Platform Module (TPM): TPM can be used to store the decryption key.

Full disk encryption is especially useful for devices taken on the road by people such as traveling executives, sales managers, or insurance agents. For example, on Windows-based laptops, FDE implementations could include combining technologies such as a TPM and BitLocker. Because encryption adds overhead, FDE is typically not appropriate for a computer in a fixed location with strong physical access control unless the data is extremely sensitive and must be protected at all costs.

TPM and HSM
Some organizations use hardware-based encryption devices because of factors such as the need for a highly secure environment, the unreliability of software, and increases in complex attacks. Hardware-based encryption basically allows IT administrators to move certificate authentication software components to hardware. For authentication, a user provides a credential to the hardware on the machine. Such a hardware-based authentication solution can be used with wireless networks and virtual private networks (VPNs) and eliminates the possibility of users sharing keys.
The Trusted Computing Group is responsible for the Trusted Platform Module (TPM) specification. At the most basic level, TPM provides for the secure storage of keys, passwords, and digital certificates. A TPM chip is hardware that is typically attached to the circuit board of a system. In addition, TPM can ensure that a system is authenticated and has not been altered or breached.
A TPM chip is a secure cryptoprocessor that is used to authenticate hardware devices such as PCs, laptops, and tablets.

TPM consists of various components, and you should be familiar with key concepts such as the following:
- Endorsement key (EK): A 2,048-bit asymmetric key pair is created at the time of manufacturing. It cannot be changed.
- Storage root key (SRK): A 2,048-bit asymmetric key pair is generated within a TPM chip and used to provide encrypted storage.
- Sealed storage: TPM protects information by binding it to the system. This means that the information can be read only by the same system in a particular described state.
- Attestation: TPM vouches for the accuracy of the system.

A computer that uses a TPM chip has the capability to create and encrypt cryptographic keys through a process called wrapping. Each TPM chip has a root wrapping key, called the storage root key (SRK), that is stored within the TPM chip. In addition, TPM-enabled computers can create and tie a key to certain platform measurements. This type of key can be unwrapped only when the platform measurements have the same values that they had when the key was created. This process is called sealing the key to the TPM; decrypting it is called unsealing. Attestation and other TPM functions do not transmit users’ personal information.
The idea behind TPM is to allow any encryption-enabled application to take advantage of the chip. Therefore, TPM has many possible applications, such as network access control (NAC), secure remote access, secure transmission of data, whole disk encryption, software license enforcement, digital rights management (DRM), and credential protection. Interestingly, part of what makes TPM effective is that the TPM module is given a unique ID and master key that even the owner of the system neither controls nor has knowledge of.
Critics of TPM argue that this security architecture puts too much control into the hands of the people who design the related systems and software. Concerns thus arise about several issues, including DRM, loss of end-user control, loss of anonymity, and interoperability. If standards and shared specifications do not exist, components of the trusted environment cannot interoperate, and trusted computing applications cannot be implemented to work on all platforms. It is also important to understand that TPM can store pre-runtime configuration parameters but does not control the software running on a device. If something happens to the TPM chip or the motherboard, you need a separate recovery key to access your data when simply connecting the hard drive to another computer.
A TPM module can offer increased security protection for processes such as digital signing, mission-critical applications, and businesses that require high security. Trusted modules can also be used in mobile phones and network equipment.
Hardware-based cryptography ensures that the information stored in hardware is better protected from external software attacks. Newer Windows systems incorporate a TPM Management console. The TPM Management console and an API called TPM Base Services (TBS) can be used for administration of TPM security hardware.
Whereas a TPM module is an embedded chip, a hardware security module (HSM) is a removable or external device used in asymmetric encryption. An HSM can be described as a black-box combination of hardware and software and/or firmware that is attached or contained inside a computer used to provide cryptographic functions for tamper protection and increased performance. The main goals of HSMs are performance and key storage space. HSMs can also enforce separation of duties for key management by separating database administration from security administration. For example, HSMs support payment processing and cardholder authentication applications for PCI DSS compliance under FIPS 140-2.
Hardware can protect encryption keys better than software because it stores the cryptographic keys inside a hardened, tamper-resistant device. Some additional reasons hardware is better at protecting encryption keys are that the application does not directly handle the key; the key does not leave the device; and, because the host OS is not storing the key, it cannot be compromised on the host system.

Boot Integrity
Boot integrity ensures that the system is trusted and has not been altered during the boot process while the operating systems loads. The basic input/output system (BIOS) consists of firmware or software instructions about basic computer functions, stored on a small memory chip on the motherboard. BIOS is the first program that runs when a computer is turned on. Unified Extensible Firmware Interface (UEFI) is a newer version of BIOS. A computer equipped with UEFI runs it first when turned on.
UEFI is an industry-wide standard managed by the Unified Extended Firmware Interface Forum. UEFI defines a standard interface between an OS, firmware, and external devices. The UEFI firmware enables OS boot loaders and UEFI applications to be called from the UEFI preboot environment.
UEFI is compatible with today’s PCs, and the majority of computers use UEFI instead of BIOS. UEFI supports security features, larger-capacity hard drives, and faster boot times. UEFI-enabled OSs are preferred over BIOS-enabled OSs because they can run in 64-bit mode and provide better support for external devices and boot targets. Sophisticated attacks can occur with traditional boot processes.
Remember that combining UEFI with a TPM establishes certainty that the system is trusted when the OS loads.
Boot drive encryption solutions require a secure boot or preboot authentication component. Today’s PCs ship with a feature called Secure Boot, which UEFI supports. With Secure Boot enabled, a PC boots using only trusted software from the PC manufacturer. Secure Boot is basically an extension of UEFI. It was added to the UEFI specification in Version 2.2 as an optional component.
Most PC manufacturers that install current Windows OSs are required by Microsoft to enable Secure Boot. Secure Boot uses a series of sequential image verification steps in the boot sequence to prevent unauthorized code from running. Software images are authenticated by previously verified software before they are executed. This sequence is the beginning of what is called the chain or root of trust. It starts with the software that is executed from read-only memory (ROM). The ROM bootloader cryptographically verifies the signature of the next bootloader. That bootloader cryptographically verifies the signature of the next software image, and so on, until the full OS is loaded. This level of trust provides an authentication chain and validates the integrity of the rest of the system.
Windows 8 introduced a new feature called Measured Boot that can provide stronger validation than Secure Boot alone. Measured Boot measures each component, from firmware up through the boot start drivers, stores those measurements in the TPM chip on the machine, and then makes available a log that can be tested remotely to verify the boot state of the client. Microsoft’s Measured Boot provides a number of advantages, including identifying and fixing errors automatically as well as stopping and mitigating malware attacks. Measured Boot can identify early untrusted applications trying to load and allows anti-malware solutions to load earlier for better protection.

Boot Attestation
The trustworthiness of a platform is based on attestation. Secure Boot permits a platform to record evidence that can be presented to a remote party in a platform attestation. The purpose of attestation is to give you confidence in the identity and trustworthiness of a target device before you interact with the device. Consider the following examples of when attestation is used:
- A device can access a network only if it is up-to-date and contains all OS patches.
- A laptop is allowed to access an enterprise environment only if it is running authorized software.
- A gaming machine can join the gaming network only if its game client is unmodified.
Think about how TPM chips are used in the attestation process. Recall from earlier in this guide that the first component of a TPM chip is an endorsement key (EK). The EK is created at the time of manufacture. It cannot be changed and is used for attestation. An attestation identity key (AIK) is also created the time of manufacture. The AIK is a private key known only by the TPM chip. In addition, a set of special-purpose platform configuration registers (PCRs) participate in attestation by recording the aggregate platform state.

To perform attestation, the attesting platform’s TPM chip signs new challenge and PCR values with the AIK. The challenger then verifies information before deciding whether to trust the attesting platform. Here are the actual steps in attestation:
The requesting party sends a message to the attesting platform, asking for evidence of authenticity.
A platform agent gathers the requested information.
The platform agent returns the information and credentials to the challenger.
The relying party verifies and validates the returned information, establishing identity and configuration of the platform.
If the relying party trusts the information provided to vouch for the attesting platform, it compares the attested configuration to configuration information that is already deemed trustworthy.
Attestation is merely disclosure about the trustworthiness of a platform at a given point in time. It does not provide validation about the running state of a system.
Original equipment manufacturers (OEMs) rely on global operations in their supply chains for manufacturing and shipping. The end product may cross several international borders and storage facilities along the way. This becomes problematic because it provides opportunities for product tampering before the equipment reaches the end user.
During manufacturing, it is critical to ensure that any root of trust device is programmed securely. To mitigate supply-chain threats and risks, manufacturers often implement root of trust measures to be sure their products boot only authenticated code. One approach is to tie Secure Boot to the system by loading a component with Secure Boot logic and making it CPU independent. Control of the system is more reliable because the approach uses existing components. The likelihood that an attacker would remove and replace components to defeat Secure Boot capabilities is greatly reduced. A system approach that supports key revocation with in-band or out-of-band management can be implemented as well.
Creating a key hierarchy to secure supply chains starts by building a root of trust at the very beginning level of the system and then using the Secure Boot process to validate the integrity of all software that executes on the platform. Secure boot has been proven to reduce the risks associated with global manufacturing operations and remote deployment.

Hardware Root of Trust
So far in this guide, we have discussed roots of trust in regard to hardware such as TPM chips and software such as UEFI, which supports Secure Boot. Roots of trust are basically hardware or software components that are inherently trusted. Secure Boot is considered a root of trust. Roots of trust are inherently trusted and must be secure by design, which is why many roots of trust are implemented in hardware. Malware can embed itself at a level lower than the OS or can be disguised as an OS loader or third-party update or boot driver; a software root of trust would not be effective against such malware, but a hardware root of trust would.

TPMs and HSMs are good examples of hardware roots of trust. TPM is now embedded in all types of devices from most major vendors. Consider two implementation examples of how organizations are using hardware roots of trust:
- The Google Chromebook uses TPM to find and correct corruption in firmware.
- PricewaterhouseCoopers uses a TPM-aware cryptographic service provider (CSP) installed under a Microsoft cryptography API in its PCs to import identity certificates.
Examples of hardware roots of trust include SEDs, TPMs, virtual TPMs, and HSMs.
Hardware roots of trust are used extensively in virtual environments. According to NIST, hardware roots of trust are preferred over software roots of trust because they are less susceptible to change, have smaller attack surfaces, and exhibit more reliable behavior.

Operating System Security
Operating systems come in various shapes and forms and are essential in the computing environment. Many exploits occur due to vulnerabilities in operating system code that allow attackers to steal information and damage the system. Operating system security is of utmost importance because it involves the main platform of the computer. In addition, several areas must be secured because the OS communicates with the hardware, performs common required application tasks, and serves as an interface with programs and applications. The following are some of the most common operating system spaces to be secured:
- Network: A network supports local area network (LAN) connections for workstations, personal computers, and sometimes legacy terminals.
- Server: Servers are specialized machines that operate in a client/server architecture and used specifically for responding to network client requests.
- Workstation: A workstation is computer hardware that runs applications for a single end user.
- Appliance: An appliance is either industry-standard hardware or a virtual machine that contains software and/or an operating system.
- Kiosk: A kiosk consists of specialized hardware and software and provides access to information and applications in a locked-down environment to protect the kiosk.
- Mobile OS: A mobile operating system runs applications for a single end user on a mobile device.
Security planning and protection cover all devices connected to a network. Each OS is configured differently and has its own security considerations. For example, securing a web server involves different security considerations than securing an airport ticket kiosk.

Patch Management
Improperly programmed software can be exploited. Software exploitation involves searching for specific problems, weaknesses, or security holes in software code and taking advantage of a program’s flawed code. The most effective ways to prevent an attacker from exploiting software bugs are to ensure that the latest manufacturer patches and service packs are applied and to monitor the web for new vulnerabilities.
Before applying patches to systems, you should verify the integrity of any patch you download. Most publishers provide MD5 hash values, which you can use for comparison after you hash your downloaded file.
Applications and operating systems include a function for auto-updates. Usually this is a viable solution for workstations, laptops, and mobile devices; however, for critical servers, it is still typically best to go through proper patch testing to make sure the system is updated to a working state. Large organizations tend to rely upon patch management tools.
The patch management infrastructure of an organization includes all tools and technologies that are used to assess, test, deploy, and install software updates. This infrastructure is essential for keeping the entire environment secure and reliable, and it must be managed and maintained properly. When it comes to managing your infrastructure, chances are good that your network includes many types of clients, which might have different needs regarding updates and hotfixes.
The most efficient way to update client machines is to use automated processes and products. Many vendors provide regular updates for installed products, managed through automated deployment tools or by manual update procedures that a system user carries out.
Regular maintenance is required to meet emerging security threats, whether you are applying an updated RPM (Red Hat Package Manager, a file format used to distribute Linux applications and update packages) by hand or using fully automated “call home for updates” options, such as those in many commercial operating systems and applications.
Various vendors provide solutions to assist in security patch management by scanning computers remotely throughout a network and reporting the results to a central repository. The results can then be assessed and compared to determine which computers need additional patches. One common example is Microsoft Endpoint Configuration Manager, formerly known as Microsoft System Center Configuration Manager.
Microsoft maintains an Automatic Updates website, which contains all the latest security updates. Starting with Windows 10, the user configuration options have changed so that, by default, updates are automatically downloaded and installed. Unless the update setting is changed manually or through Group Policy, all client computers will receive updates as soon as they come out.

Disabling Unnecessary Ports and Services
In security terms, system hardening refers to reducing the security exposure of a system and strengthening its defenses against unauthorized access attempts and other forms of malicious attention. A “soft” system is one that is installed with default configurations or unnecessary services or one that is not maintained to include emerging security updates. No completely safe system exists; the process of hardening simply reflects attention to security thresholds.
Systems installed in default configurations often include many unnecessary services that are configured automatically. These services are potential avenues for unauthorized access to a system or network. Many services have known vulnerabilities, and specific actions must be taken to make them more secure; some services could actually impair system function by causing additional processing overhead. Default configurations also allow for unauthorized access and exploitation.
A denial-of-service (DoS) attack could be conducted against an unneeded web service; this is one example of how a nonessential service can potentially cause problems for an otherwise functional system.
Common default configuration exploits include both services (such as anonymous-access FTP servers) and network protocols (such as Simple Network Management Protocol). Others exploit vendor-supplied default logon/password combinations.
When you are presented with a scenario on the exam, you might be tempted to keep all services enabled to cover all requirements. Be wary of this option as it might mean installing unnecessary services or protocols.

A computer can communicate through 65,535 TCP and UDP ports. The port numbers are divided into three ranges:
- Well-known ports: The well-known ports are 0 through 1,023.
- Registered ports: The registered ports are 1,024 through 49,151.
- Dynamic/private ports: The dynamic/private ports are 49,152 through 65,535.
Often these ports are not secured and, as a result, may be used for exploitation. Table 18.2 lists some of the most commonly used ports and the services and protocols that use them. Many of these ports and services have associated vulnerabilities. You should know what common ports are used by network protocols and how to securely implement services on these ports.

Commonly Used Ports

Know the differences in the various ports that are used for network services and protocols.
The protocols listed in the table above might be currently in use on a network. These protocols, along with some older or antiquated protocols, could be configured open by default by the machine manufacturer or when an operating system is installed. Every operating system requires different services in order to operate properly. If ports are open for manufacturer-installed tools, the manufacturer should have the services listed in the documentation. Ports for older protocols such as Chargen (port 19) and Telnet (port 23) might still be accessible. For example, Finger, which uses port 79, was widely used during the early days of the Internet, but today’s sites no longer offer the service. However, you might still find some old implementations of Eudora mail that use the Finger protocol. Worse, a mail client may have long since been upgraded, but the port used 10 years ago may have somehow been left open. The quickest way to tell which ports are open and which services are running is to do a Netstat scan on the machine. You can also run local or online port scans.
The best way to protect the network infrastructure from attacks aimed at antiquated or unused ports and protocols is to remove any unnecessary protocols and create access control lists to allow traffic on necessary ports only. By doing so, you eliminate the possibility of exploiting unused and antiquated protocols and minimize the threat of attack.

Least Functionality
Least functionality is based on the principle that, by default, systems provide a wide variety of functions and services, some of which are not necessary to support the essential operation of the organization. Least functionality prevents an organization from using a single system to provide multiple services, which would increase risk. Where feasible, organizations must limit component functionality to a single function per device and must disable any unnecessary protocols, ports, or services. Any functionality that does not support a business need should be removed or disabled.
The term least functionality comes from configuration management 7 (CM-7) in NIST 800-53, which states that an organization must configure an information system to provide only essential capabilities and must specifically prohibit or restrict the use of certain ports, protocols, or services. Network scanning tools can be used to identify prohibited functions, ports, protocols, and services. Enforcement can be accomplished through IPSs, firewalls, and endpoint protections.

Secure Configurations
Secure configurations are imperative to prevent malware from infiltrating a network. Hardening an operating system is a large part of making sure that systems have secure configurations. Hardening an operating system includes using fault-tolerant hardware and software solutions to prevent both accidental data deletion and directed attacks. In addition, an organization must implement an effective system for file-level security, including encrypted file support and secured filesystem selection that allows the proper level of access control. For example, NTFS allows file-level access control and encryption, whereas most FAT-based filesystems allow only share-level access control, without encryption.
Organizations also must conduct regular update reviews for all deployed operating systems to address newly identified exploits and apply security updates and hotfixes. Many automated attacks make use of common vulnerabilities for which patches and hotfixes are available but have not been applied. Failure to update applications on a regular basis or perform regular auditing can result in an insecure solution that gives an attacker access to additional resources throughout an organization’s network.
IP Security (IPsec) and public key infrastructure (PKI) implementations must also be properly configured and updated to maintain key and ticket stores. Some systems can be hardened to include specific levels of access, gaining the C2 security rating that many government deployment scenarios require. The Trusted Computer System Evaluation Criteria (TCSEC) rating C2 indicates a discretionary access control (DAC) environment with additional requirements such as individual logon accounts and access logging.
Operating system hardening includes configuring log files and auditing, changing default administrator account names and default passwords, and instituting account lockout and password policies to guarantee strong passwords that can resist brute-force attacks. File-level security and access control mechanisms isolate access attempts in the operating system environment.

Trusted Operating System
The trusted operating system concept was developed in the early 1980s and is based on technical standards of the TCSEC. Trusted operating systems are security-enhanced versions of operating systems that have access segmented through compartmentalization and role, least-privilege, and kernel-level enforcement. Individual components are locked down to protect memory and files, restrict object access, and enforce user authentication. Some applications cannot work on a trusted OS because of the strict security settings.
An operating system is considered a trusted OS if it meets specified security requirements. A certain level of trust can be assigned to an operating system depending on the degree to which it meets a specific set of requirements. A trusted operating system is designed from the beginning with security in mind. Evaluating the level of trust depends on security policy enforcement and the sufficiency of the operating system’s measures and mechanisms.

Quiz:

1. Why do vendors provide MD5 values for their software patches? A. To provide the necessary key for patch activation B. To allow the downloader to verify the authenticity of the site providing the patch C. To ensure that auto-updates are enabled for subsequent patch releases D. To allow the recipient to verify the integrity of the patch prior to installation

2. Your developers made certain that any input to a search function they developed would result in commas, quotes, and other certain special characters being stripped out. Which of the following is likely their reasoning? A. They are paranoid, and they should allow the original input term to process as is. B. They want to prevent SQL injection by validating the input. C. They want to prevent privilege escalation by providing proper exception handling. D. They are lazy and didn’t want to have to refactor their search algorithm.

3. You are a security administrator and learn that a user has been emailing files containing credit card number data from the corporate domain to his personal email account. This data is typically required to go to a third-party business partner. Which of the following solutions could you implement to prevent these emails or attachments from being sent to personal email accounts? A. Implement a DLP solution to prevent employees from emailing sensitive data. B. Implement a mail solution that requires TLS connections to encrypt the emails. C. Implement a mail solution that employs encryption and that will prevent email from being sent externally. D. Implement a DLP solution to prevent sensitive data from being emailed to non-business accounts.

4. Which of the following correctly matches each protocol to its default port? A. SSH:22; SMTP:25; DNS:53; HTTP:80; LDAPS:389 B. SSH:21; SMTP:22; DNS:35; HTTP:110; LDAPS:636 C. SSH:22; SMTP:25; DNS:53; HTTP:80; LDAPS:636 D. SSH:22; SMTP:23; DNS:35; HTTP:69; LDAPS:389

5. Which of the following is a white-box testing process for detecting bugs in the early stages of program development? A. Dynamic analysis B. Static analysis C. Fuzzing D. Sandboxing

Answer 1: D. MD5 is a hashing value used to verify integrity. Software developers provide these hash values so users can verify that nothing has changed. Answers A and B are incorrect. MD5 is for integrity checking, not authentication, and some patches may be downloaded from sites other than the original author’s site. Answer C is incorrect.
Answer 2: B. The developers are following a best practice of input validation by preventing various types of negative impacts, such as SQL injection. Answers A, C, and D are all incorrect and are not directly related to the issue described here.
Answer 3: D. Implementing a DLP solution to prevent sensitive data from being emailed to non-business accounts is the best choice. Answer A is incorrect as this solution isn’t necessarily needed to halt all email. Answer B is incorrect as transport encryption will still allow personal email accounts to receive the sensitive data. Answer C is incorrect because encryption will still allow the email to be sent externally.
Answer 4: C. Answer C maps the protocols with their correct default ports. The other answers, A, B, and D, are incorrect. Refer to Table 18.2 for a list of commonly used services and ports you should be familiar with.
Answer 5: B. Static analysis is a white-box software testing process for detecting bugs. Static analysis is a thorough approach to bug detection in the early stages of program development. Answers A and C are incorrect because dynamic analysis is done while a program is in operation. Dynamic analysis uses a technique called fuzzing, which is a black-box software-testing process in which semi-random data is injected into a program or protocol stack to detect bugs. Answer D is incorrect. Sandboxing allows programs and processes to be run in an isolated environment in order to limit access to files and the host system.