Encryption, HIPAA & SOXS Compliance

Who Needs Data Encryption or Email Security ?

Data or Email encryption isn’t for everyone but is critical for many. If you answer “yes” to any of the questions below you should consider ensuring your privacy with some form of secure data & email service.
• Do you exchange confidential financial or personal data via email?
• Is your business in the financial, legal, or health care industries?
• Are you concerned about the email privacy and security of yourself and others?
• Subject to compliance audits for regulatory policies such as HIPAA, SOX or GLBA?

Most of the questions we receive about HIPAA, SOX or GLBA concern encrypting data. There are several places where encryption can be applied.

Password encryption:
Users’ passwords must be encrypted, and this is done automatically.

Encryption of network traffic:
You can encrypt your data while it is being transmitted between the server and the workstation. This is done as a countermeasure against packet sniffing, which is the unauthorized interception the data packets during transmission over the network. According to HIPAA, this is optional if your network is closed (i.e. private wire) but is recommended it your network is open (i.e. across the Internet). Most centers fall somewhere between a completely closed network and a completely open network. If you want to encrypt your data while it is being transmitted, you should use IPSec (Internet Protocol Security) or a VPN (Virtual Private Network). HIPAA states:

“When using open networks, some form of encryption should be employed. The utilization of less open systems/networks such as those provided by a value-added network (VAN) or private-wire arrangement provides sufficient access controls to allow encryption to be an optional feature.”
IPSec (IP Security Protocol) is an extended IP protocol which enables secure data transfer. It provides services similar to SSL/TLS, however, these services are provided on a network layer. IPSec can be used for creation of encrypted tunnels between networks (VPN)—so called tunnel mode, or for encryption of traffic between two hosts—so called transport mode.

Encryption of data on the hard drive:
As a countermeasure to unauthorized access to SQL Server data files on your server, you can also encrypt those data files. There are several third-party utilities for this, or you can also use Microsoft EFS, which is built into the Windows operating system. The links in the panel on the right describe how to accomplish this. With a properly configured SQL Server, there is no reason for any user to have access to the underlying SQL Server data files.

Encryption of data backup copies:
You should give careful consideration to what happens to backup copies of the data. It is up to you to decide if the physical security of the backup copies is sufficient. If it is not, then you can also employ one of many third party utilities to encrypt the backup copies of your data. Make sure that encrypted backups can be decrypted if necessary on a different computer. Do not encrypt backups using an encryption key that is generated by and stored only on the server, because that server may not be available when you need to decrypt a backup copy. As with all backup approaches, it is best to test your technique before relying on it. Backup your data, encrypt it, then decrypt and restore the data on another computer. Remember, if your backup encryption key is lost, your backups are useless.

We leverage industry and internationally recognized standards used by Government, Military, Financial Institutions, Medical Industry.
• Standards include PKI, X.509, SMIME, SSL, RSA, AES
• Standard interoperable with other standards-based systems including Verisign, Entrust.
• We use the strongest commercially available cryptography known to the industry

Our privacy applications and encryption platform are built on the following industry accepted standards for digital signatures and encryption:
o 1024 bit RSA End-user Keys
o 2048 bit RSA CA Keys
o SHA-1 hash
o PKIX X.509 v3 certificates & CRLs
o PKCS#10 certificate signing request
o PKCS#12 key storage
o 3DES and AES-256 symmetric encryption
o S/MIME PKCS#7 encrypted e-mail format
o HTML / XML, HTTP 1.1 / SSL
o 2048 bit CA keys
o CA Key Generation/Protection