Data security is something that no company, no matter the size can afford to ignore. No developer wants to be “that person” that uploaded the credentials to the public GIT repository – but it happens. And no one wants to have to send out emails to your user base telling them that their social security numbers or bank account information has been compromised because an employee’s laptop was stolen. Even if you are just creating a small project: if you are storing information about your users you need to have data security in mind. Here are the first minimum considerations for the non-security expert.
Don’t Think You Are Smarter Than You Are
Don’t create your own login security. Don’t try to create a custom encryption method. Unless you are a Data Security genius (and you are not) you are not going to do a better job than well tested, widely used tools that have teams of people working on them and millions of users in the wild. You just aren’t. Do not fall victim to the “Not Invented Here” fallacy and spend time creating your own tools.
Don’t Store What You Don’t Need
It is surprising how often companies will store social security numbers, medical information or banking information because “it might come in handy someday”. Just don’t do that. Only store what you actually need to have. If that magic someday ever comes where you need the extra information it is far better to collect it then instead of taking the responsibility for storing information securely. For example if you need to verify a birth date for COPA reasons you do not need to actually store the birthday – only that the user was old enough.
Protecting Your Data in Flight and at Rest
This means that you need to protect your data both while it is being transferred to you or from you and while it is stored. There are many good references on both of these topics so we won’t go into this here, but pay attention and plan for data security both at rest and in flight.
Protect your Account Access
Your user’s data is only as secure as your account as a whole. If your AWS, Salesforce or GCP credentials are compromised then your data is instantly at risk. Do not use root credentials. Do use MFA, IAM and strong password policies. Be proactive in educating your employees on good security habits (I am looking at you bit yellow post-it password).
Do Not Store Sensitive Data Locally
Even good employees will make mistakes (leave a laptop in a car, forget to log out of their work station) and some people will stoop to malicious or even criminal acts. Make sure that you do not store sensitive information on the client side. While this might mean that some information will not be available if the user is unable to connect to the VPN or internet. It is far better to have a small inconvenience than it is for you to risk user information.
Have a Disaster Plan
You never want to have to use it but be able to do so if you need it. Your disaster plan at a minimum should include back-up and a process for altering users of a security information breach. And while it should be obvious the core elements of your plan need to be stored somewhere seperate from your main accounts.