Packet filtering firewalls work at the network level of the OSI model, or the IP layer of TCP/IP. These firewalls are normally part of a router, which is a device that receives and forwards packets to networks. "In a packet filtering firewall each packet is compared to a set of criteria before it is forwarded. Depending on the packet and the criteria, the firewall can drop the packet, forward it, or send a message to the originator." The criteria used to evaluate a packet include source, destination IP address, destination port, and protocol used. These types of firewalls are low in cost and don't have much of an impact on the network's performance.

It is important to note that mandatory controls are prohibitive (i.e., all that is not expressly permitted is forbidden), not permissive. Only within that context do discretionary controls operate, prohibiting still more access with the same exclusionary principle. In this type of control system decisions are based on privilege (clearance) of subject (user) and sensitivity (classification) of object (file). It requires labeling.

The Secure Socket Layer (SSL) Protocol is primarily used to provide confidentiality
to the information sent across clients and servers.
For your exam you should know the information below:
The Secure Sockets Layer (SSL) is a commonly-used protocol for managing the security of a
message transmitted over a public network such as the Internet.
SSL has recently been succeeded by Transport Layer Security (TLS), which is based on SSL.
SSL uses a program layer located between the Internet's Hypertext Transfer Protocol (HTTP) and
Transport Control Protocol (TCP) layers.
SSL is included as part of both the Microsoft and Netscape browsers and most Web server
products.
Developed by Netscape, SSL also gained the support of Microsoft and other Internet client/server
developers as well and became the de facto standard until evolving into Transport Layer Security.
The "sockets" part of the term refers to the sockets method of passing data back and forth
between a client and a server program in a network or between program layers in the same
computer. SSL uses the public-and-private key encryption system from RSA, which also includes
the use of a digital certificate. Later on SSL uses a Session Key along a Symmetric Cipher for the
bulk of the data.
TLS and SSL are an integral part of most Web browsers (clients) and Web servers. If a Web site is
on a server that supports SSL, SSL can be enabled and specific Web pages can be identified as
requiring SSL access. Any Web server can be enabled by using Netscape's SSLRef program
library which can be downloaded for noncommercial use or licensed for commercial use.
TLS and SSL are not interoperable. However, a message sent with TLS can be handled by a
client that handles SSL but not TLS.
The SSL handshake
A HTTP-based SSL connection is always initiated by the client using a URL starting with https://
instead of with http://. At the beginning of an SSL session, an SSL handshake is performed. This
handshake produces the cryptographic parameters of the session. A simplified overview of how
the SSL handshake is processed is shown in the diagram below.
SSL Handshake
Image Reference - http://publib.boulder.ibm.com/tividd/td/ITAME/SC32-1363-
00/en_US/HTML/handshak.gif
The client sends a client "hello" message that lists the cryptographic capabilities of the client
(sorted in client preference order), such as the version of SSL, the cipher suites supported by the
client, and the data compression methods supported by the client. The message also contains a
28-byte random number.
The server responds with a server "hello" message that contains the cryptographic method (cipher
suite) and the data compression method selected by the server, the session ID, and another
random number.
Note:
The client and the server must support at least one common cipher suite, or else the handshake
fails. The server generally chooses the strongest common cipher suite.
The server sends its digital certificate. (In this example, the server uses X.509 V3 digital
certificates with SSL.)
If the server uses SSL V3, and if the server application (for example, the Web server) requires a
digital certificate for client authentication, the server sends a "digital certificate request" message.
In the "digital certificate request" message, the server sends a list of the types of digital certificates
supported and the distinguished names of acceptable certificate authorities.
The server sends a server "hello done" message and waits for a client response. Upon receipt of
the server "hello done" message, the client (the Web browser) verifies the validity of the server's
digital certificate and checks that the server's "hello" parameters are acceptable.
If the server requested a client digital certificate, the client sends a digital certificate, or if no
suitable digital certificate is available, the client sends a "no digital certificate" alert. This alert is
only a warning, but the server application can fail the session if client authentication is mandatory.
The client sends a "client key exchange" message. This message contains the pre-master secret,
a 46-byte random number used in the generation of the symmetric encryption keys and the
message authentication code (MAC) keys, encrypted with the public key of the server.
If the client sent a digital certificate to the server, the client sends a "digital certificate verify"
message signed with the client's private key. By verifying the signature of this message, the server
can explicitly verify the ownership of the client digital certificate.
Note:
An additional process to verify the server digital certificate is not necessary. If the server does not
have the private key that belongs to the digital certificate, it cannot decrypt the pre-master secret
and create the correct keys for the symmetric encryption algorithm, and the handshake fails.
The client uses a series of cryptographic operations to convert the pre-master secret into a master
secret, from which all key material required for encryption and message authentication is derived.
Then the client sends a "change cipher spec" message to make the server switch to the newly
negotiated cipher suite. The next message sent by the client (the "finished" message) is the first
message encrypted with this cipher method and keys.
The server responds with a "change cipher spec" and a "finished" message of its own. The SSL handshake ends, and encrypted application data can be sent.
The following answers are incorrect: FTP - File Transfer Protocol (FTP) is a standard Internet protocol for transmitting files between computers on the Internet. Like the Hypertext Transfer Protocol (HTTP), which transfers displayable Web pages and related files, and the Simple Mail Transfer Protocol (SMTP), which transfers e-mail, FTP is an application protocol that uses the Internet's TCP/IP protocols. FTP is commonly used to transfer Web page files from their creator to the computer that acts as their server for everyone on the Internet. It's also commonly used to download programs and other files to your computer from other servers.
SSH - Secure Shell (SSH) is a cryptographic network protocol for secure data communication, remote command-line login, remote command execution, and other secure network services between two networked computers. It connects, via a secure channel over an insecure network, a server and a client running SSH server and SSH client programs, respectively.
S/MIME - S/MIME (Secure Multi-Purpose Internet Mail Extensions) is a secure method of sending e-mail that uses the Rivest-Shamir-Adleman encryption system. S/MIME is included in the latest versions of the Web browsers from Microsoft and Netscape and has also been endorsed by other vendors that make messaging products. RSA has proposed S/MIME as a standard to the Internet Engineering Task Force (IETF).
Following reference(s) were/was used to create this question: CISA review manual 2014 Page number 352 Official ISC2 guide to CISSP CBK 3rd Edition Page number 256 http://publib.boulder.ibm.com/tividd/td/ITAME/SC32-1363-00/en_US/HTML/ss7aumst18.htm
Topic 3, Security and Risk Management

Several rootkit-detection tools are available, some of which are able to remove known rootkits.
However, once you suspect a rootkit is on a system, the only truly secure response is to reconstitute or replace the entire computer. Reconstitution involves performing a thorough storage sanitization operation on all storage devices on that system, reinstalling the OS and all applications from trusted original sources, and then restoring files from trusted rootkit-free backups. Obviously, the best protection against rootkits is defense (i.e., don't get infected in the first place) rather than response.