Encrypted E-mail Solutions

Here is some information on setting up secure e-mail encryption with outside parties. There are basically two options available. Prices can vary based on the selected vendor and the information provided is for very general planning purposes and we would need to formally quote these before going forward. The major difference is how widely you intend on sending encrypted e-mail, and cost.

S/MIME:

This method is the simplest form of transmitting data between two trusted partners or individuals.

  • Pros: This security is built directly into Microsoft Outlook and it’s use is seamless for the sender and receiver. Meets HIPPA requirements for PHI. Best solution for a small number of users. Fastest method to receive encrypted e-mail. Lowest start up costs for a small number of users.
  • Cons: This requires a Digital Certificate to be purchased, renewed periodically and installed on both the sender and receiver systems. There is a degree of configuration required for all parties. Apex can provide support to other business with their permission and for an additional cost. E-mail is only encrypted when sent to recipients with Digital Certificates, you can accidentally send PHI or confidential information to the wrong person. Both users need to be configured before you can send encrypted e-mail.
  • Best Fit: When you’re exchanging secure e-mail with a well defined set of outside businesses and individuals which will not subject to change frequently.
  • Costs: $100 per user who will be receiving encrypted e-mail (reoccurring every 3 years); and $200 per user at an outside company who will be receiving encrypted e-mail (reoccurring costs every 3 years) – price include the rough estimate for labor and the Digital Certificate.

E-Mail Gateway:

This method will use a set of rules defined on the server to automatically determine PHI, such as sender/receipient/subject/content/etc. The system will automatically convert those e-mails into an encrypted format and send them to the recepient. There is no special software or configuration requirements for the sender or recipient.

  • Pros: This is good when the list of senders or recpients is not well define or may include home users. Automatically protects all PHI to avoid accidentally sending PHI in an unencrypted format, regardless of the recpient. On-the-fly encryption to anyone, which doesn’t require pre-configuration. 
  • Cons: It may require the recipient to go to a website to download the attachment, which makes frequent use of this method a slower method. Additional server hardware, software and maintenance is required.
  • Best Fit: If you’re exchanging e-mail with a diverse group of not-well-defined individuals, who may not have the ability or knowledge to work with Digital Certificates.
  • Costs: Around $3,000 per three year term, plus hardware around $1000 and installation labor and ongoing support. Pricing is subject to change, this was based on old pricing before Symantec Acquired the product from PGP. Another solution is the Cisco IronPort E-mail Security Appliance.

Hosted E-Mail Gateway:

Basically the same as the E-Mail Gateway from a security standpoint, with the only difference of the costs of implementation. The hosted solution doesn’t require a server nor the related hardware, software and support costs. However, it does have a higher ongoing service fee.

  • Pro/Con/Fit is the same as “E-Mail Gateway” above.
  • Costs: McAfee Email Encryption is $4,930 for a three year term for 100 users (again we need to do the entire company); or one year for $2,055.00 Other providers are McAfee/MXLogic Hosted Solution

Mixed 2003/2008 Domain Controllers: Account Compromised

While working with a Blackberry Enterprise Server install which recommends setting user AD account options to “this account supports Kerberos AES xxx encryption” this setting is not supported in a mixed 2003/2008 AD environment. Be sure to only select the “Kerberos DES encryption” per the BES setup instructions. AES encryption is not supported in Server 2003 DCs, and setting an account that way may result in errors authentication or changing passwords because your computer will try to use the most secure method, AES 256 which the account is marked as supporting, but depending on which DC it hits (2003 or 2008) it may or may not work. Which made isolating the issue a bit harder because it wouldn’t consistently work/not work.

 A couple of symptoms you’ll observe is:

  • Sys-tray pop-up that you account may be compromised
  • Sys-tray pop-up asking you to lock and unlock your computer, and after you complete it, it prompts you again
  • Event ID 14: While processing an AS request for target service, the account did not have a suitable key for generating a Kerberos ticket
  • Event ID 40960: The Security System detected an authentication error for the server…the failure code from the authentication protocol was “(0x80080341)”.
  • Event ID 6: Automatic certificate enrollment for USER failed (0,80072095) A directory service error has occurred.

Of course this issue is not isolated to Blackberry installations but typical out of the box configurations do not have AES selected, so this issue only arises when you’re in a mixed environment and change the setting… and in this case, BES was the case for change.

PCI-DSS Compliance for RDP Connections

This is a common problem that you’ll see from PCI-DSS compliance audits for customers which process credit cards on their PC network. In many cases simply disabling external RDP access is the answer, but when external RDP access is required, here is the proper way to address the following two errors:

  • Microsoft Windows Remote Desktop Protocol Server Man in the Middle Weakness (CVE-2005-1795)
  • Terminal Server Encryption Level is not FIPS-140 compliant

What I have seen other companies do is simply restrict RDP to a specifc set of WAN IP’s, which will appear solve the problem from the PCI audit report because they cannot access the RDP port open due to the firewall rules, however this is still a violation of PCI because the vulnerabilities still exist. The protocol needs to be properly secured, and the process is relatively simple.

1)      Create a self-signed SSL certificate (if one doesn’t already exist; of course a publicly signed SSL is better, but not needed for PCI compliance)

2)      Open Terminal Services Configuration

3)      Edit the properties of the RDP-Tcp  Connection

4)      Start from the bottom and work up

  1. Click Edit and add the self-signed SSL certificate
  2. Set the encryption level to FIPS compliant
  3. Click APPLY
  4. Set the Security layer to SSL (you will not see this as an option if the SSL cert is not configured and you haven’t applied the changes)
  5. Click APPLY again then OK

5)      Close all windows and all active RDP sessions

Simply have the PCI Compliance company run a new audit and you should be all set.

Nessus Security Scanner

NessusLogoTool Thursday: Nessus Security Scanner

This is an excellent professional tool you should add to your toolbox if you’re serious about vulnerability scanning and auditing your own work. This tool is pretty pricey for the individual technician, but is free for personal (non commerical, non consulting) work. There is also volume licenising available. As always, please respect the legal restrictions – solo consultants, don’t use the free license key.

The primary difference between the professional and free version is the time interval at which they release updated definition files for specific vulnerabilities. The professional also adds some wonderful reporting tools not available in the free release. Download it today and check it out at: http://nessus.org/

This is a great tool to audit and check your network from both outside and inside of your network – also be sure you’re using to only scan networks your authorized to check as the activity from Nessus will certainly trigger a host of firewall alarms at the target site.

Enjoy!

Powered by WordPress.com.

Up ↑