Is HTTPS required when there's no sensitive data in the site

Question

I'm currently building a B2B e-commerce site for a client using WordPress. We sell industrial machinery ranging in the upper $100k-$400k price range. My client would like to have their financing form online where customers/businesses enter bank account information, as well as social security numbers. He wants this form to be emailed to our financing group to process. Instead of emailing this form, could I keep the data on my SSL server and encrypt it some way then provide a login link for our financing group to use, enter a key, then display the sensitive information? We are trying to eliminate the need to fax or mail an application.

We have 2 servers, an in-house MS SQL 2008 server and a MySQL/Nginx server WordPress is installed on.

After reading through many posts, what my client wants to do is a huge risk for users and our company. I'm not a security specialist, just looking for some feedback on what I should/could do.

Answer 1

It sounds like you have plenty of sensitive information on your website!

Even if your site contains no sensitive information, though, implementing HTTPS is a sound decision. Insecure HTTP connections are vulnerable to a man-in-the-middle (MITM) attack, allowing an attacker to impersonate your site with ease. Clients have no way to be sure they're actually connected to your server, rather than someone else's pretending to be yours.

HTTPS provides authentication by allowing clients to verify your server's identity, as well as confidentiality by preventing third parties from snooping on your traffic.

Answer 2

First of, HTTPS only protect data while in transit, it does not protect your data afterward. Therefore, you will need to implement security for this data at rest.

Designing a fully secure system is a really, really difficult task and evaluating what is an acceptable risk and what isn't is far from trivial. I would really suggest you seek advise from a professional security consultant (audit firms have access to such profile).

That being said, here are a few pointers on how you might want to go after this task:

1. First, you will need to estimate the value of the data you want to protect. This is VERY important because it will let you decide what security measure are necessary and which one are overkill (security always has a cost). Don't forget that this value should include the cost should that data be lost and should that data being stolen/disclosed.
2. Make sure you actually NEED all the data you're collecting. The simplest way to protect sensitive data is not to request or store them so you can minimize the risks (and costs) by reducing the amount of data you're storing.
3. Check if you'll need the sensitive data on the front server ever again. If not, a pretty simple - yet effective - implementation is to create a secure, one-way path for the data: implement a back-end server that will accept the data with a simple API (through a secure connection) but will not have anything else exposed. Another way of protecting this data is to encrypt it (for instance, using PGP) with a public key and keep the private key off the server. That way, the sensitive data cannot be easily retrieved as long as the private key isn't compromised.
4. In all cases, you will be better served by having a separate server for storing your sensitive data and performing access control. This server shouldn't be accessible from the outside, only from your front-end system. If an attacker gets hold of your frontal server, they will still need to gain access to this system to reach your sensitive data. The API used for contacting this secure server should be carefully designed, though.
5. Data at rest should be encrypted as well. Ideally, you will use a HSM to store the keys and not use transparent encryption (neither in the storage, nor in the database).
6. When you're done with your design have it audited.