Simple steps in securing services

Nothing in this post is revolutionary or something I’ve come up with on my own but I feel these are things that still bear repeating. They will seem obvious but pick any day of the week and do a search on Google for phrases like “data breach” or “passwords leaked” and you can get an idea on the scale of the problem. So what can you do?

Reduce your data footprint

You should always ask yourself, do I really need this data from people? If the answer is no, them simply put, don’t ask for it. If you think it might come in handy in the future, well wait until you have a good reason for holding it and not before. Users will respond well if you’re asking for something sensible. Actually, if Facebook is anything to go by, they probably won’t think twice even about handing it over. So be responsible.

Reduce your software complexity

As developers we all like to think we’re good at our job. But everyone makes mistakes. The more complex your software is, the more likely you will make a mistake, cut corners or avoid the problems until it’s too late. Companies love doing features and not allowing developers to go back and take care of tech debt.

Develop like you’re not going to be able come back and improve it as there’s a fair chance you won’t be able to within a reasonable time.

It will also make it easier for less experienced developers to come in, understand the system sooner and be able to work on it as well. It’s not good be the lone person who understands the system.

Don’t restrict passwords

With the advent of password managers many people can easily handle many complex passwords. Do not restrict them. There just isn’t a good reason these days for people not to be able to have a 50 char password with any combination of letters, numbers, symbols or even emoji. This is especially true if you’re building out a new service. If you’re stuck with something old, you should do what you can to rectify the company’s password policies. It’s concerning that there are still sites that can limit passwords to something like 6 letters and numbers. Why?

Lock it all down

Hunt down all the gaps in your system, encrypt everything you can (email, S3 buckets, etc), no passwords for SSH. There’s great tool called Fail2Ban which will let you monitor logs and lock people out. It comes with some pre-built rules and you can make your own. I’d highly recommend it.

S3 buckets can be open and often data leaks from them because people don’t realise they’re open. Always check and lock down these resources.

Good practices

It can be hard to keep sensitive data out of repositories simply because people make mistakes. So in addition to simply being vigilant consider enforcing standard practices for holding this data. In doing so you can model your .gitignore file to catch mistakes.

It won’t be a perfect, catch all solution. But like most security it’s not about being perfect but doing what you can to avoid disasters.

Ensure passwords for internal systems are complex and realise people will have to share them. Personally I’d suggest heavily discouraging sharing via 3rd party services like Slack. You just don’t know where the data will end up and how long it will hang around. Encrypted email is convenient and works everywhere so it’s perhaps the best option that does not rely on a 3rd party service like 1password to share passwords. This is not to say 1password is bad (far from it) and if it fits your needs it's another good system to consider.

Conclusion

In the end whatever you do, if you keep things simple and be responsible and you should be off to a good start. Oh, and if you rely on open source software please consider donating, if not contributing, to help the project out. Often there aren’t as many eyes on open source as you may think.