Breach Insider

Security for Startups – What you need to know

Sometimes we are simply too busy grafting or deeply involved in our startups and nurturing their growth, that we forget to think about the security of our employees, our infrastructure or our code. Often it is necessary to cut a few corners & occasionally think about security a little further down the line, but it’s important that we never fully ignore it. It is this very reason that startups make for very tempting targets to the nefarious among us, where large growth equals lots of potential user data to steal.

This guide aims to help you minimise that risk, by listing some key areas and ideas that’ll help make you a much harder target for the next big data breach.

Who is this for?

This document is for founders, CTOs or VPs – it will be fairly high level with actionable outcomes. There may be parts in here for your developers, but this won’t be a technical deep dive into poor coding practices that lead to vulnerable web applications.

Contents

| Securing you & your employees

Humans are unfortunately excellent way into a business for a hacker, due to our curious nature and strange urges to seemingly click on just about anything. Lets see if we can make that a little less likely to happen…

– Make everyone aware of security

A problem shared is a problem halved. Try and get everyone thinking about their own security, and how their actions could impact the company’s security. For example, posting their corporate email address online may be great for receiving that all important feedback, but that now makes them a potential target for spam & malicious emails (or worse, targeting phishing emails). Whilst there is nothing wrong with email addresses being public (except for the spam), the person who will be looking at that inbox should be aware of how to distinguish a malicious email from a genuine query.

Those that may be at risk in their role due to being ‘customer facing’, should spend some time doing Security Awareness training (Udemy is a great source for this, with many being free).

– 2FA Everything.

Two factor authentication (2FA) means logins will require an additional step once you have entered your username & password, verifying it is indeed you via another factor, such as a time sensitive code or an actionable push notification.

Every possible account in use within your startup should have 2FA enabled if it is available. Why? Because even if someone finds out your username and password, without that 2nd factor, they still can’t get into your account. So when one of your suppliers or a startup you trialled with has a data breach, and your corporate credentials make it into the public domain for anyone to try on any website, they’ll still fail (but they won’t, because you wouldn’t use the same password everywhere, would you).

– Password Managers

Where possible, try and get everyone using a password manager (KeePass & PasswordSafe are both free and open source), for their own individual accounts. Similar to the point made in 2FA, when one of your suppliers or 3rd party tools has a breach, and an employee’s password make it into the public domain that clearly follows the format of “increment by 1”, it won’t take someone long to go and casually try a range of passwords for that account on GitHub or similar.

Password managers which integrate and offer auto-fill functionality within web browsers can also help minimise the effects of phishing websites on your employees. If they receive a convincing phishing email that takes them to a fancy Stripe login page, but their auto-fill doesn’t work, that should be enough of a prompt for them to think something might not be quite right…

– Shared Accounts

In an ideal world, such a thing wouldn’t exist, but unfortunately they do so lets secure them properly. The best option is to use a dedicated team password manager (1Password Teams is an option here), where everyone is singing from the same hymn-sheet. This single source allows you to quickly track who has access to what, and when the password was last reset or changed. This is very important, especially when employees leave, as those shared accounts need to be updated as soon as possible.

However you manage it, just ensure you keep a log of all the shared accounts, the associated passwords, and when they were last updated.

– Encryption

Consider encrypting and securing all employee devices – use full disk encryption on desktops or laptops, and set strong screen-lock passcodes on mobile devices (or even better, fingerprint authentication via TouchID etc.)

Not only will this help when the inevitable happens, and someone leaves a bag or phone at a bar or on a train, but can also help minimise the chances of accidental incidents caused by small hands of a child or inquisitive friend.

Full disk encryption is pretty common these days, and can be enabled within minutes on most systems.

| Securing your infrastructure

Your infrastructure is likely to be a tempting target to anyone who wants to find potential holes in your company. Your servers are (hopefully) online 24/7/365, and likely to be connected to the Internet in one way or another, meaning they will be scanned continuously by hackers and security researchers for open ports or misconfiguration. It is therefore important to regularly ensure your infrastructure is locked down as much as possible.

- Keep track of your infrastructure

This may sound a little obvious to some, but it is hugely important to keep an inventory of your assets/infrastructure. Without this list, you don’t know what you need to go out and update or patch when the next Heartbleed comes around. A great list would include the following for your servers:

  • What are they running (web server, cache, background workers?)
  • Where are they hosted (In the office, or one of the many cloud providers?)
  • What OS they are running (Debian, Ubuntu, Windows…)
  • Their public address(es)

- TLS for web servers

For the sake of your users and your brand, apply TLS to your web servers so that all traffic between them and the endpoint are encrypted. HTTPS is getting a lot of attention at the moment, including from browsers such as Chrome who have started to mark unencrypted websites using HTTP as insecure, which isn’t a great look.

TLS certificates don’t have to cost a fortune, in fact you can pick them up for free using Lets Encrypt, who supply valid certificates which expire after 90 days. This is to encourage you to automate the renewal (easily done with software) of your certificates, rather than having the huge headache of dealing with an expired certificate on your website.

- Patch everything, always

If you’re managing your own servers or equipment, keep them up to date. This includes OS patches, as well as applications and any libraries/dependencies you might make use of.

There is a temptation to only patch when it is absolutely necessary (e.g. a critical vulnerability is publicly disclosed), however this route can lead to further issues. When it comes to patching important assets or fixing critical vulnerabilities, you want to be able to deploy them as quickly and as trouble-free as possible. If you’re many versions behind, you not only have to deal with non-backwards compatibility issues, you also compound the issue by having to deploy sudden fixes to your code to fix these new bugs.

- Strong authentication everywhere

  • Always change default credentials. Always. Make use of the password manager you chose above and generate a password longer than 20 characters. You don’t need to remember this, thanks to our password manager.
  • Where possible (SSH), use key-based authentication to ensure only those with the correct private keys can login to your servers. If you’re using key-based authentication, don’t forget to disable password prompts!

- Keep internal servers private

If you have servers within your infrastructure that don’t need to be connected to the Internet, utilise services like private or internal networking provided by the majority of hosting/cloud companies.

If you’re wondering how you would access these hosts if they’re not connected to the Internet (e.g directly accessing your database for maintenance), simply setup tiny server to act as a ‘jump-box’ into your private network. This box will sit on the edge of your VPC and have a public IP address for you to connect to. This server should be locked down to key-based SSH authentication only, and ideally, only over online or ‘spun up’ when it is absolutely necessary.

What about Windows and RDP? Tunnel RDP over SSH, so that you don’t have to expose port 3389 to the Internet for anyone to bruteforce.

- Centralised Logging

Logging can be critical when we need to find out why something bad happened, or when we are trying to trace a hard to reproduce bug – however for the rest of the time it largely goes unnoticed.

Logs during a security incident are critical to answering what, when, where, and who, helping you to paint a picture as to the scope of the incident. When these logs are left locally on the servers, they can easily be tampered with by the attacker, or simply deleted to remove any trace of their access to the server (or application). By securely transporting these logs to a central location, they can be preserved and monitored.

  • If you’re using a cloud provider (AWS, Google), consider using their in-house logging platform.
  • For a self-hosted option, consider the ELK Stack or Graylog, both excellent and well documented approaches.

| Protect your brand

It isn’t all about employees and infrastructure – sometimes you need to think about those additional critical services that simply aren’t within your full control.

- Secure your domain name

Your domain name is everything – your brand, your website, your email etc. So you should do more than just renew it each year.

If you have the choice, you should pick a domain registrar not because of their yearly renewal price, but because of how trustworthy they are and the level of security you can apply to the account.

  • Use a very strong password for your domain registrar account
  • Use two-factor authentication if it is available – Ideally using a security key or time-based one-time passwords (TOTP) via Google Authenticator or Microsoft Authenticator.
  • Renew for as long as you can afford, and always put the renew dates into your calendar.

- Secure your third party services

Similar to the above, you should apply the same level of scrutiny and security your critical third-party applications or services. A data breach for your business does not have to occur on your servers, as it is highly likely that customer or private information is shared across multiple other businesses. For example it is unlikely you host your own email platform – the life and soul of any business – so it is therefore critical that you make this as difficult to access maliciously as possible. All reputable providers will allow you to secure your account using two-factor authentication and a long complex password.

- Detect your data breach

Preventing a data breach can be incredibly difficult, due to the sheer number of ways they can occur. Prevention software and services can require a large number of resources to not only setup, but also maintain. Often then require a dedicated team to monitor and react to the alarms, which can be a tough cost to swallow for agile startups. These services can also produce a large number of false positive alerts when not setup and maintained correctly, leading you to a potentially disastrous ’the service who cried wolf’ scenario.

That is why we at Breach Insiders decided to take a different approach, and look at detection rather than prevention. For those that don’t know, we supply businesses of all sizes with unique users to add to their databases, CRMs and newsletters. These users come with real email addresses and mobile numbers, which when contacted (by someone other than your business) will raise the alarm instantly for you to investigate. The added bonus of these users being entirely unique to your business means we can scan the Internet and Dark Web (Tor) continually for any references to them, alerting you as soon as we detect a match.

We are of course hugely biased, but we definitely think you should consider our 14-day free trial, to find out how you can setup data breach detect in under 10 minutes

- Be open and honest

Be honest with your users about the data you collect (and this is now required by law for those operating within the EU by GDPR), in clear and simple terms. Also show how seriously you take security by outlining your approaches or even publishing your internal security policy to the general public (or an simplified version of it).

You should also strongly consider having a security point of contact, so that researchers can easily get in touch to let you know if they’ve found anything that might concern your business. This can be as simple as setting up a security@your-domain.com email alias.

By being open and honest, not only will you build up good will with the general public, but also provoke fewer attacks by not making bold “we cannot be hacked” claims.

| Securing your application & code

Suffering a data breach is a case of ‘when’ rather than ‘if’. When that time comes, it is important that your application and code is also secured to minimise the after-affects.

- Use strong and recommended hashing algorithms for passwords – with salt!

Poor or weak hashing algorithms allow what should be uncrackable passwords to be bruteforced.

The truly worst offenders use plain-text passwords with zero hashing – never store passwords in plain-text. MD5 and SHA1 are next, as they be easily reversed with readily available rainbow tables. Using a random salt per password would mean these are no longer effective, but they can still be very quickly bruteforced using a powerful CPU or even a couple of GPUs.

As per the brilliant OWASP Foundation it is recommended you use one of the following, in order of preference:

  • Argon2
  • PBKDF2
  • scrypt
  • bcrypt

- Never store payment details

Storing payment details can get you into a lot of trouble if you don’t meet strict requirements outlined via Payment Card Industry Data Security Standard (PCI DSS). It is much easier to outsource this to a service who live and breathe these regulations & can correctly store and manage this sensitive information.

- Monitor your dependencies

It is highly likely that your startup relies on software or libraries supplied by third parties or are open source. It is important that these dependencies are kept up to date as they will regularly contain important security updates. An example of a common dependency may be Django - the popular Python web framework, or a json parsing library written for Python, Ruby or NodeJS.

- Keep your secrets secret

It is important that you keep secrets – such as private keys, passwords and api credentials – under strict controls. This includes those used by your developers in environments other that production (for testing etc.)

This is important as these can provide people with an incredible amount of access to your company and your systems. The common example is api keys being committed to your code repository (such as Github), where they can then potentially be viewed by anyone within your business. This can be tricky to fix due to the nature of these services, as committing another update with the sensitive string removed doesn’t actually remove it from your repository, as it is of course still included within the history of that file.

In an ideal world, where the scenario of an employee’s Github account being misused or bruteforced to gain access to your source code, should mean that that is all they get access to. But when secrets are committed (even if it is just once), they can scour your code to utilise these strings to gain deeper access into your business.

  • Consider using git-secrets, made by AWS Labs, to stop developers committing sensitive strings.

- 2FA for your users too!

Don’t forget to allow your users to protect themselves too. By implementing two-factor authentication you allow them to take control of their own security, as well as improving your brand image by showing that your take security seriously. For some users, the decision between you and your competitor can be ‘small’ features like 2FA.

Lots of web frameworks have had 2FA plugins built for them: