Regulatory Compliance

Nikto is a lightweight, portable, PERL based web application scanner. The only requirements for Nikto to run are PERL and NET SSLeay, NET SSLeay is only needed if you plan on auditing SSL based applications. Nikto requires you to input the targets from the command line, because of this we’ll also be using NMAP with the http-headers NSE scripts to identify and gather basic information on HTTP based services for this overview. Nikto, as a standalone package, does not include the ability to perform port/service scanning. As such, NMAP will additionally need to be installed on the system performing the audits. NMAP is not a requirement; it just makes things easier…

Required Software/Packages:

Nikto

• http://cirt.net/nikto2

Net SSLeay

• http://search.cpan.org/CPAN/authors/id/S/SA/SAMPO/Net_SSLeay.pm-1.25.tar.gz

NMAP

• http://www.nmap.org/download

NMAP HTTP-Headers NSE

• http://nmap.org/svn/scripts/http-headers.nse

NMAP with NSE to discover potential Web Applications

This section assumes you are running at minimum nmap 5.21, nmap 5.2x is required for the application awareness checking of nmap. To begin, we will be probing the targets systems to discover all services and identify what is running on them using the service aware nmap config, but also using the http-headers nse to gather interesting information about the system(s) with potential web applications. From the nmap output, we’ll be targeting those systems running some type of web application. Side Note: for those services that show up as unknown, be sure to manually probe them later. nmap --script http-headers.nse -p 1-65535 –A

I’m targeting all ports here via nmap as some people still believe security through obscurity is a valid mechanism, don’t overlook anything. There are several other options for service level probing you may want to investigate, but for this I’m doing the quick and dirty.

Once nmap has completed its run, it will spit out everything it found to the console, from that list we will target the services to be audited with Nikto.

$ nmap --script http-headers.nse 192.168.0.1 -A

Starting Nmap 5.21 ( http://nmap.org )
NSE: Script Scanning completed.
Nmap scan report for 192.168.0.1
Host is up (0.0012s latency).
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.2.3 ((CentOS) mod_python/3.2.8 Python/2.4.3 mod_ssl/2.2.3 OpenSSL/0.9.8e-fips-rhel5 mod_perl/2.0.4 Perl/v5.8.8)
443/tcp open ssl/http Apache httpd 2.2.3 ((CentOS) mod_python/3.2.8 Python/2.4.3 mod_ssl/2.2.3 OpenSSL/0.9.8e-fips-rhel5 mod_perl/2.0.4 Perl/v5.8.8)

Installing Nikto and targeting the discovered web applications

Obtain the Nikto package and the NET SSLeay packages from the following locations:

Install NET SSLeay then untar the nikto package to your home directory, update Nikto

./nikto.pl –update

From the nessus NSE scan above, we found the following services in operation that are of interest:

• 80/tcp open http Apache httpd 2.2.3
• 5801/tcp open vnc-http RealVNC 4.0
• 3000/tcp open http WEBrick httpd 1.3.1
• 443/tcp open ssl/http Apache httpd 2.2.3

At the command line, we target these web applications specifically with Nikto by using the following type of command:

./nikto –h 'target' -p 80,443,5801,3000 –ssl –output report.html

As Nikto is performing the targeted assessment, any potential issues will be displayed to the console. As the scan is occuring, all results are output to the html file with the details of the scan along with the corresponding OSVDB^[?] identifiers broken down by service port tested.

The export format may additionally be set to either csv or XML as needed: report.csv, report.xml

Executing nmap and passing the results directly to nikto

This is useful when you want/need to check all active web servers in the target subnet(s). The following executes the nmap scan of the target subnet then pipes the discovered hosts to nikto.

nmap 192.168.0.0/24 -oG - | ./nikto.pl -output subnet.html -h -

Closing

Nikto standalone, I wasn't overly thrilled with. But again, in a pinch it is a nice tool to keep in the box. In testing nikto, some scans were needed to be run several times for nikto to actually do what it had been configured to do via the command line. The reporting isn't that clean, still leaves a lot of room for interpretation and understanding of common issues.

Whole Disk Encryption (WDE^[?]) – And Comparison of PGP vs TrueCrypt for WDE

In this day and age there is absolutely no reason for any business with laptops being used for business or personal reasons that contain sensitive information to not be encrypted.

• AT&T Laptop stolen with payroll data
• Stolen laptop exposes 207,000 Army reservists
• Laptop stolen containing Veteran Affairs patient information

Whole Disk Encryption, also known as Full Disk Encryption, is what it says; it encrypts all information contained on the specified disk or partition. WDE should not however not to be confused with file system encryption. With WDE one key is used to encrypt the entire disk. Should the key become compromised, the entire disk is thereby compromised. For those individuals needing or who are required to transmit sensitive information on their laptops, I would strongly recommend using WDE in conjunction with file system encryption.

File system encryption is often known as folder or file encryption because it was designed, from a high level, to encrypt specific targets within the system whereas WDE deals with the entire disk.

• File System encryption examples can be found in a previous blog post on TrueCrypt Containers for examples.

TrueCrypt vs PGP	TrueCrypt	PGP
Cost	Free	$149.00
Encrypt internal, external and removable media	yes	yes
Encrypt all user data, applications, boot sector and swap files	yes	yes
Shred/Wipe Function	no	yes
Encrypt Email	no	option $$
Encrypt IM	no	option $$

TrueCrypt Whole Disk Encryption on Windows - Step by Step

Select Create Volume

Encrypt the system partition or entire system drive

Type of System Encryption - Normal

Area to Encrypt – Encrypt the whole drive

Encryption of the Host Protected Area – If you know there are utilities in the Host Protected Area (HPA) you do not want encrypted, select No – Otherwise encrypted the HPA as well

Number of Operating Systems – Select the appropriate response, typically this will be 1

Encryption Options – Select the Preferred Encryption and hashing Algorithms – for NIST^[?] compliance select AES^[?]

• Notes:
• Unlike PGP below where you generate your public/private keypair that can be used for other PGP plug-in applications, the keys for TrueCrypt are generated based on the movement of your mouse and are only used for drive encrypt/decrypt functions
• If you are overly paranoid, you can select a cascading algorithm here such as AES+TwoFish to increase the strength

Password – enter the password, this will be used to access the system once the entire disk has been encrypted

Rescue Disk – The iso image created must be copied off the system and it is recommended it be burnt to a CD. This will be required if the password is forgotten or any portion of the loader becomes corrupted. Once the image has been burnt, eject and reinsert the CD and click next to allow Truecrypt to verify the image. Once it has completed, it will ask you to reboot, select yes for the encryption Pretest.

At the boot prompt, enter the password you had entered earlier.

Once Windows boots, you'll be presented with the Pretest screen and the option to begin the encryption process, select Encrypt, go for a coke...

The encryption status window will appear, once the disk encryption has completed a notification window will appear.

That’s about all that you need to do.

If for whatever reason you want to permanently decrypt the drive, open the TrueCrypt application, select System then “Permanently decrypt system partition/drive”.

PGP (Pretty Good Privacy) WDE on Windows - Quasi Step by Step

The setup is pretty straightforward and almost identical to the TrueCrypt setup; install the application from the exe. Once it finished open the PGP Desktop application from the system tray and click on PGP Disk then Encrypt Whole Disk.

• During the installation you`ll be prompted to create a key pair. These keys will be used for encrypting and decrypting the drive(s). These are also the keys you`ll use if you buy the extra PGP addons such as email. Make sure you use your legitimate email address during creation.

It is recommended you create a recovery disk, same as a above.

Select the disk to encrypt then select the keys you created during installation by selecting Add User Key.

Click Encrypt, go for a coke..

By default PGP uses AES-256 for encryption and SHA-1 for hashing. As far as I am aware there is no possible customization to either the encryption or hashing algorithms.

Soap Box

While I am a huge fan of TrueCrypt for only WDE or file system encryption, it does not scale well in large deployments like PGP offers with the Universal Server. With the PGP Universal Server, enrollments and encryption policies can be controlled and deployed from a central server. The PGP server can generate "reports" from the server on demand. I put the quotes around the word report because the export is simply a csv export of the entire database structure, which is severely lacking in the ability to perform decent reporting and database maintenance.

Seriously though, with whatever solution you choose..choose one. The 30 minutes of your time it takes to install and configure the software will pale in comparison to being immortalized on the Internet as yet another failure to protect sensitive information...

I’m on a vulnerability^[?] management and patch management tangent. No real reason why other than I was listening to a podcast and a comment irked me so I decided to write this up. This is a high level overview of my recommendations on implementing a program. As always if you have any questions on this feel free to ping me.

Identification of Assets

For whatever reason, I find this to be one portion of any vulnerability management process that continues to fail whether it is private or public sector. Network and Systems people love to turn up new technology but they typically do not want to generate any documentation on what the system is, who is responsible for it, what applications are installed onto the system and if some other person is responsible for those installed applications. This is a critical step to being capable of performing any type of vulnerability management.

Vulnerability^[?] Identification & Tracking

Vulnerability identification can be discovered from many sources including risk assessments, vendor notifications, open sources of information (exploit-db, securitytracker, packetstorm, etc) or vulnerability assessments through automated tools (Nexpose) or manual assessments (Penetration Testing, Risk Assessments).

Vulnerability, in itself, is a broad term. Vulnerabilities can be initially discovered pre-production through system or application configurations such as running an outdated version of MySQL or allowing connections from public facing systems to protected internal resources. These types of pre-production vulnerabilities must be documented in the Identification of Assets phase.

Vulnerabilities discovery through commercial sources or clearing houses are typically assigned a criticality grade or score (CVE^[?], CVSS^[?], Critical, Medium, etc). Those vulnerabilities that have been discovered from open sources, to which commercial or clearing houses have not process, you must review and assign a grade to the vulnerability. Based on the grade or score, coupled with the criticality of the systems that may be affected along with the probability of exploitation, we can then properly gauge the response to remediation.

If you are unsure of how to perform the grading on your own, or just want a quick and dirty, the DHS^[?] has made available a CVSS v2 Calculator available at the following URL:

• http://nvd.nist.gov/cvss.cfm?calculator&version=2

Vulnerabilities discovered after deployment must be tracked from discovery to remediation. This is heavily reliant on some type of internal tracking system, personally I use redmine, to track the lifecycle of the vulnerability from the time it is discovered, the entire internal review and assessment, recommended corrective actions, implementation of remediation action to verification and finally the lessons learned or RCA (root cause analysis). On a side note, any remediation actions must be included in the system documentation. This will assist in not on the vulnerability/patch management process, but will also greatly improve incident response timelines when necessary.

Response Planning

When new vulnerabilities are discovered, a response planning process should be engaged. As part of the response planning, the focus should be on the specific vulnerability as well any risks identified during the internal review and assessment. Once a new vulnerability has been discovered, there is of course a greater chance of exploitation of the vulnerability. The planning process should of course involve the incident response team but must also include the system/applications owner(s) as well as the applicable operational group (i.e networking, systems administration).
Vulnerability Remediation

At this point in the lifecycle, we’ve identified the vulnerability, identified the vulnerable systems, developed a remediation plan, engaged the incident response capability and are ready to implement the chosen solution. Prior to actually correcting the vulnerability, ensure the system/application owner(s) have been properly notified. Included within the notification must be the projected time frame to begin as well as conclude the corrective actions. Make sure the notification includes all applicable individuals so no one feels left out, this has come back to bite more than one handler.

• You’ve also created your back-out plan and you’ve also run the entire corrective and back-out past the system/application owners right? =)

Keep in mind that the chosen remediation method must follow the documented process previously defined and agreed upon. This process must be adhered to by all involved parties. Any deviation from the process must be authorized, if for some reason the deviation does not allow for authorization at the time, the reasoning for the deviation must be documented and the affected parties later informed of the deviation in totality.

Remediation Methods Overview

Remediation methods are typically classified into the following three:
• Installation of a security patch
o Application of security patches may replace specific portions of the application code that have been determined to expose a vulnerability

• Modification of a system or application configuration parameter
o Modifying the configuration of how the application, or a portion of the operating system, functions that has been determined to expose a vulnerability

• Removal of the affected application or service
o If, after thorough review, it is determined the vulnerable piece of software, or portion of the underlying operating system, is not a functional necessity of the system, the software or service should be removed.

Remediation Methods

1. Installation of the Software Patch
a. All software patch testing should be performed on non-production systems.
b. Verification should be performed to ensure installation of the most recent security patch does not inadvertently remove previous security patches.
c. If multiple patches were published, verify there is not a specific installation sequence.
d. Prior to installation of the patch, ensure that any applications that may rely on the portion of the application, or operating system, have been fully tested to ensure continued operability post patching.
e. The length of time to properly verify a patch or subset of patches is variable based on the scope of the patch and whether the patch will interact with subsets of the operating system or other applications. The exact time frame of patch testing must be defined by the parties responsible to the systems/applications to be patched as well as the group performing the testing.
i. Security patch installations should additionally be implemented into baseline operating system installation procedures.
f. Manual verification of the security patch should be performed through the use of an automated vulnerability assessment tool (Nexpose) or manual verification.
g. Once testing of the security patch has been completed, the patch(es) are to be introduced into the patch distribution system (i.e. SCCM) for dissemination into the environment.

2. Modification of System or Application Configuration Parameters
a. Modification of configuration parameters has traditionally been a “from the hip” response to a vulnerability, as such they typically do not receive thorough testing as security patches.
b. Configuration modifications should first be performed on non-production systems. Configuration modifications may impact operational privileges and in some cases functional stability. As such, post implementation of configuration changes should include monitoring the system/application for proper functionality and stability.
c. Manual verification of the security patch should be performed through the use of an automated vulnerability assessment tool or manual verification.
i. Configuration modifications, when permanent, should be implemented into the baseline operating system and/or application installation procedures.

3. Removal of the Affected Application or Service
a. Removal of the vulnerable application or service effectively eliminates the vulnerability. Prior to removal of the application or service however, a thorough analysis of the system and applications in operation must be performed to ensure that removal does not impact the operational requirements of the system.
i. Just because you think java is not needed on that server running Oracle 11gr2, from your perspective; realize that in doing so you may make that Oracle Enterprise Manager or Grid Control application stop functioning completely.
b. Removal of applications or services, as with patching, should be performed on test systems. A pre-defined period of time should be stated for review of the operational integrity of the system post removal.
c. Manual verification of the security patch should be performed through the use of the Vulnerability Assessment tool.

A final option, typically utilized by Governmental agencies, would be the issuance of a RAF^[?] (Risk Acceptance Form). The RAF neither mitigates nor eliminates the vulnerability, but indicates that the system/application owner recognizes that a potential vulnerability exists, acknowledges that no changes to the system will occur and accepts the potential risk. In my personal opinion, this is an option that should rarely, if ever, be utilized.

• Something else to bear in mind, the entire remediation process should follow your organization change management process..you do have a change management process right?

Remediation Verification

Upon completion of the selected remediation effort, verification must be performed through manual review of configuration files or patch installation logs and vulnerability assessments. It is my personal recommendation that systems/applications which have had some corrective measures made against them be monitored for at minimum one week to ensure system/application integrity and availability.

In previous posts we've reviewed the basic server and client configuration as well as how to, using the external parser, insert the alerts into BASE. At this point we're going to delve a bit deeper into the server side configuration.

Email Alerting

This is really personal preference, if you like receiving a ton of email with events that are also being inserted into the database, feel free to make use of this.

At the top of the ossec configuration file located in /var/ossec/etc/ossec.conf, the first container specifies what types of alerts you want to receive as well as where the you want the specified alerts being sent to. This container may already be populated if you enabled email notification during setup.

<global>
<email_notification>yes</email_notification>
<email_to>you@yourdomain.com</email_to>
<smtp_server>someserverhere</smtp_server>
<email_from>ossecm@yourdomain.com</email_from>
</global>

While this is the base configuration, there are a few additional options you may want to use here.

Enable throttling, this is highly recommended. If the systems you are monitoring become targeted by a high rate attack and ossec is configured to generate an email on every alarm. You can effectively cause a denial of service condition on your own systems. This is set with the following:

- <email_maxperhour>X</email_maxperhour>

X would be the maximum number of emails that ossec will generate in a given hour. Keep in mind, by setting this option, if you are relying on email alerts you may miss events with the high level threshold you set. The events are queued however once they reach the X limit you set, the queue is cleared 20 alerts at a time until cleared.

In addition to the global email alerting, we can also create targeted email groups based on server names, as they have been named when the client was configured when using ./manage_agents

<email_alerts>
<email_to>null@protectors.cc</email_to>
<event_location>servers1|server2</event_location>
</email_alerts>

Tweaking the email alerts

The default email alert configuration within OSSEC is as follows:

<alerts>
<log_alert_level>1</log_alert_level>
<email_alert_level>7</email_alert_level>
</alerts>

The alert levels are based on severity of the events ranging from 0 to 15. With 0 being information and 15 being high severity. The alert levels themselves are defined within the ossec rule files located in /var/ossec/rules. When modifying this log and email alert levels, ensure events you deem as important are not going to be missed during this tuning process. An example of the alert level in an ossec definition would be as follows:

<rule id="12109" <strong>level="12"</strong>>
<if_sid>12100</if_sid>
<match>exiting (due to fatal error)</match>
<description>Named fatal error. DNS service going down.</description>
<group>service_availability,</group>
</rule>

In this example, OSSEC will log all events level 1 and higher. Level 0 alerts are those that we have defined that we are not interested in being reported on. In the above example of email_alert_level, only events level 7 or higher would generate email alerts. This is only applicable if you have enabled email alerting that is.

Receiving and Processing Alerts from Remote System/Devices

With this portion, we are concerned with the receipt and processing of events from remote systems. We will receive these events in one of two manners. The first is syslog being configured on the remote device to send events to the OSSEC server, these will typically be networking devices or servers with syslog support. The second method is using the ossec agent on a remote system to send log events via a secure channel to the ossec server.

Configuring Standard Syslog and OSSEC to Monitor

In this example, we have our OSSEC server also running as a central log collector. All events received from remote system are received on Local6.info and are inserted into /var/log/messages.

The typical syslog configuration will appear as follows in /etc/syslog.conf

local6.* /var/log/messages

For the OSSEC configuration on the server, we define the following:

<localfile>
<log_format>syslog</log_format>
<location>/var/log/messages</location>
</localfile>

Now, on networking equipment such as switches and routers, we need to define the logging facility and host to log events to. The following would be an example for a Cisco Router:

logging facility local6
logging source-interface <interface facing the ossec server>
logging <ip address of the ossec server>
do wr
exit

As long as syslog is correctly configured on the server, messages from the device will begin to populate the /var/log/messages file. To start OSSEC processing the events, restart ossec after adding the above (note: /var/log/messages is typically added to most configuration by default on linux based systems).

OSSEC has the ability to monitor several including syslog, snort, squid, IIS, Windows event logs, mysql, postgresql and apache. However, the important thing to to remember with OSSEC is that the log formatting is completely customizable and can support nearly any type of logging.

Syscheck Configuration Options

My typical Linux syscheck template is along these lines depending on the installation and the purpose of the server:

<syscheck>
<frequency>14400</frequency>
<directories realtime="yes" >/var/www</directories>
<directories check_all="yes">/opt,/bin,/usr/bin,/usr/local/bin,/usr/local/sbin,/sbin,/boot,/etc,/home</directories>

<alert_new_files>yes</alert_new_files>
<scan_on_start>no</scan_on_start>
<auto_ignore>no</auto_ignore>

<!-- Files/directories to ignore -->
<ignore>/etc/mtab</ignore>
<ignore>/etc/mnttab</ignore>
<ignore>/etc/hosts.deny</ignore>
<ignore>/etc/mail/statistics</ignore>
<ignore>/etc/random-seed</ignore>
<ignore>/etc/adjtime</ignore>
<ignore>/etc/httpd/logs</ignore>
<ignore>/etc/utmpx</ignore>
<ignore>/etc/wtmpx</ignore>
<ignore>/etc/cups/certs</ignore>
<ignore>/etc/dumpdates</ignore>
<ignore>/etc/svc/volatile</ignore>
</syscheck>

Breaking this down piece by piece; when we specify the directory to monitor we have the following options available to us:

- realtime - provides realtime monitoring of the specified directories
- check_all - performs all of the below checks on the specified directories
- check_sum - checks for changes to the md5/sha1 hash of the files
- check_size - checks for changes to the sizes of the files
- check_owner - check for changes to the owner of the files
- check_group - check for changes to the group ownership
- check_perm - check for changes to the permissions

It would be my recommendation that either check_all by the default with realtime as the alternate option for those highly critical directories.

Frequency defines the amount of time, in seconds, that OSSEC will fire to perform the checks on the specified directories. Makes sure to tune this to an acceptable level. While 100 seconds may seem sexy, it's not realistic and may end up crushing your servers.

Alert_new_files - by default this is not in the configuration. I strongly recommend this be added and set to yes. When ossec makes its run, anything new it finds it will generate an alarm on, otherwise you`ll never know when someone uploads the c99.php file if you're not doing realtime checking of /var/www/html

Scan_on_start - by default this is set to yes, I would recommend this be set to no and let it run on against the frequency setting. I`m not sure if its a feature of a bug but on some rare occasions when I've restarted ossec it's caused scans an hosts to restart and when making several changes to the local_rules and restarting several times..it brought a system to a dead halt for a short time period.

auto_ignore - by default this is set to yes, this meaning after the 3rd time the file has changed in some way and you have not acknowledged the change it will simply ignore it. Not the best approach in my opinion for a noisy system that requires monitoring.

As for the ignores, those are some general noisy files, feel free to add more to the list as you see fit.

Additional options include scanning specific directories on certain days or at specific times if you do not want to rely on the general frequency directive.

scan_day - specifies the day or days you want the scan to run (scan_day sunday, wednesday, friday)

scan_time - specifies the time of the day you want the scan to run ( scan_time 12pm)

Ignoring sub-directories with syscheck

There may be on occasion you want to monitor for example /var/www/html and all directories contained with it, but you do not want to monitor sarg/

<directories check_all="yes">/var/www/html<directories>
<ignore>/var/www/html/sarg</ignore>

This will effectively ignore all files and directories contained within the /var/www/html/sarg directory.

Rootcheck Configuration Options

Again, my typical linux template..feel free to customize it as you see fit Something to bear in mind though, the rootcheck portion can be very resource intensive. This module will scan the entire operating system by default looking for both rootkits as well as common system configuration issues. While I personally let it scan the entire system, it can be disabled with the scanall no option.

<rootcheck>
<frequency>86400</frequency>
<rootkit_files>/var/ossec/etc/shared/rootkit_files.txt</rootkit_files>
<rootkit_trojans>/var/ossec/etc/shared/rootkit_trojans.txt</rootkit_trojans>
<system_audit>/var/ossec/etc/shared/system_audit_rcl.txt</system_audit>
<system_audit>/var/ossec/etc/shared/cis_rhel5_linux_rcl.txt</system_audit>
</rootcheck>

Frequency I define as daily, and as I use CentOS5 I leave in the rhel5 file and remove the cis_rhel_linux_rcl.txt. If you are running a non 5 release, feel free to add or replace cis_rhel_linux_rcl.txt as needed.

While most of this specifically addresses the server side configuration, the syscheck, rootcheck, and localfile parameters are portable to the client side ossec.conf configuration files.

Going to wrap it up with this, next section will likely be on OSSEC Reporting as I'm on a reporting and metrics kick as of late..

Any questions feel free to shoot me an email..

My "secure" USB drive and a toilet bowel had a duel and the toilet bowl won. With that, I was torn between buying a new "secure" USB drive for $70-100 or buying a base plain USB drive and finding some disk encryption software. Of course in the back of my mind was a task of encrypting the entire disk on my laptop. With that I set out to find a free and moderately easy to use disk encryption software package. My requirements for the software package were the following:

- Must work on all the different operating systems I commonly use (Windows & Linux)
- Must be portable, if needed to be accessed on a different system it must work with at most installing the application
- Must be able to encrypt the entire file system
- Must be able to create virtual encrypted volumes (volume must not be overtly visible)
- Must be able to create an encrypted file system on removable media (SD or USB & volume must not be overtly visible)
- Must allow for auto-mounting of the encrypted file system, either virtual or removable media
- Must automatically unmount the drive when system is shut down or idle for a predefined time period
- Must lock/wipe the device on a predefined numbers of authentication failures
- Must use NIST^[?] approved encryption and hashing algorithms

After tinkering with 12-13 different software packages I decided on TrueCrypt, it met all my requirements except the lock/wipe the device on authentication failures. I could live without that one.

In creating the volumes, you are offered standard encryption algorithms or cascading algorithms. Cascading meaning you can implement multiple types of encryption algorithms built atop each other. Supported direct and cascaded algorithms include the following:

- AES^[?] in XTS Mode (NIST Approved)
- TwoFish
- Serpent

Cascading algorithms include the following:

- AES-TwoFish
- Serpent-AES
- Serpent-TwoFish-AES
- AES-TwoFish-Serpent

Speed wise, the direct algorithm is the preferred choice. AES will be the fastest of the available algorithm selections. If you are more concerned with security of the data at rest, the AES-TwoFish-Serpent cascade algorithm is recommended. bearing in mind, using the cascade algorithms will significantly slow the overall encrypt/decrypt throughput.

Hashing algorithms supported include the following:

- RIPEMD160
- SHA512 (NIST Approved)
- Whirlpool

Quick Volume Setup Guide for Removable Media for the Windows Operating System

Insert the USB or SD card into the reader or USB slot, open TrueCrypt and click on Create Volume.

- Select Encrypt a non-system partition/drive
- Volume Type - Standard TrueCrypt volume
- Select the USB drive (IMPORTANT NOTE: Make sure you select the USB drive and not your primary hard disk)
-- you'll get an error asking you to confirm that you want to encrypt the device, select yes

- Volume Creation Mode
-- Create encrypted volume and format it

- Encryption Options (select what you want here)
-- Encryption Select AES
-- Hashing Select SHA512

Volume Size - Select next as you're encrypting the entire file space

Volume Password - Enter the password you want to use to access the encrypted volume here

Volume Format - select NTFS for the filesystem type - do not select Quick Format, select Format

Once the device has been wiped and encrypted, remove the USB device and reinsert it into the system.

Quick Setup Guide for Creating Encrypted File Containers

Create a dummy file someone on your primary harddisk, for simplicity I used c:\temp\TrueCryptVolume

From the TrueCrypt application, click on Create Volume

- Select Create an encrypted file container
- Standard TrueCrypt Volume
- Click on Select file and navigate to where your container file is located - when prompted if you want to replace it select Yes
- Choose the encryption and hashing algorithm of your preference
- Designate the desired size of the encrypted volume
- Set the volume password
- Select NTFS for the filesystem and click on format - click yes to the warning to confirm creating the container
- Mount the container by clicking on Select File, navigate to the container file, select an unused drive letter, then click on mount

Enabling Automount for TrueCrypt Volumes

From the TrueCrypt application select Settings -> Prefereces - Checks the boxes next to the following options:

- TrueCrypt Background Task Enable
- Start TrueCrypt Background Task
- Mount all device-hosted TrueCrypt Volumes
- Mount Favorite Volumes

If you want the drives, after being idle for a predefined time period, to automatically dismount, select the "auto dismount volume after no data has been read/written to it for" and enter your time limit.

Click OK - Click Auto-Mount Devices, you will be prompted for the volume password.

Important Notes

Be aware that all disk encryption programs only protect the information "physically" written to the encrypted media be it virtual or physical. Any information you access is temporarily stored in system memory. If a computer system is not:

- shut down properly
- suffers from a power failure
- the removable media is removed without being unmounted
- as well as slew of other issues that may cause an unclean memory purge

May result in sensitive information being inadvertently left in temporary file space on the hardrdrive of the computer. If the entire system harddisk, as well as removable media, is encrypted, this is not an issue.

if you are encrypting the entire system harddrive, there have been some freak occurrences of on improper shutdown, the boot record becoming corrupted; Thereby turning your computer into a doorstop. However, full disk encryption is the recommended path if the information on your laptop for example is sensitive and may cause some severe impact to you if it were say stolen..not that laptop theft ever occurs right =)