This article is framed toward “one day we’d like to pass a SOC2 audit”, but is also a good intro to some practices you should be doing, if you aren’t already. For 2FA I personally wouldn’t worry too much about forcing people to use hardware keys until you’ve dealt with other more low-hanging fruit – a TOTP authenticator app on the user’s phone is fine for most use cases and threat models.

Keep it as simple as you possibly can. Everything you add is a potential for intrusion. That of course includes any cloud/third party software/service and also the VPN. Don’t accidentally open ways in just for saving yourself three seconds a day. You use a password manager and consider hardware tokens with the same trade-off so don’t do the opposite in other scenarios.

Write docs and keep them up to date! Yes, you are small, so, you don’t need to have the big documentation, but have some kind of document, be it a Google Doc thing or simply a repo with markdown or plain text where you both document what you do and why. Especially important to do “one time” things or things that you rarely do. It doesn’t have to be some fancy documentation, copy and paste, cues, etc.

A typical scenario of messing up early is to change things and forgetting about something that allows for a way in.

Make it a habit to call for important stuff, rather than email to reduce the likelihood of attacks on that front.

For Azure: Why exactly do you use that as a small company? It feels like either you wanna go for a more complete solution, Heroku style (depending on what you need) or a simpler solution (a vserver somewhere). Don’t just use some cloud service if you don’t have a full time person with dedicated knowledge in the field or it eventually will cause issues, as things progress. Also since you say “We are moving…” what’s the rationale?

Use some form of Single SIgn on, and preferably only use one way to authenticate. You are likely to need to have more than one, so a password manager makes sense, but don’t let that be the reason you make all sorts of logins.

Make sure you have proper off-boarding in place as early as possible. That largely involves keeping a list of who can do what where. Make sure you keep it up to date, so you can properly restrict access. Not because you fear wrong-doing, but because it’s yet another way in for an attacker.

And to re-iterate: Make sure you keep everything as simple as possible. Don’t increase attack surface out of a whim. Try out new things on a separate server/network/cloud project/… Do not be tempted to just try it with anything production, that includes desktops/laptops.

Have a threat model! You are small, it is simple. It’s also psychologically important. There’s so many young/small companies that spend months on some mostly theoretical security issue, in the context of already being breached and one system containing some password to decrypt some information magically not being accessible to the attacker, when their front gate is completely open. It makes you feel good, cause you are working on security and yes, you should eventually get there, but get your priorities straight by analyzing what you have and where attackers get in.

Don’t assume the likeliest way in is someone finding a 0-day in OpenSSH or exploiting the OS’s network stack using ICMP to ruin a small company. But also don’t assume that “nobody will know the IP of this system”. Don’t work by hiding things, don’t practice security by obscurity.

So in short: Keep your attack surface small, have people know what they are doing. Practice security, rather than security theater.

Hey! Recently this was shared and it explains quite well many things that helped with SOC2 certification, but also many things that just make sense for security: https://fly.io/blog/soc2-the-screenshots-will-continue-until-security-improves/

I’m myself in a similar situation to you but much more advanced (it’s been 3 years now) and this article is definitely a gold mine, it has many links to other articles that are also awesome.

The things that I think make sense are the basics:

• business continuity and disaster recovery (backups, periodically tested, failover tests, HA, …)
• IAM and access control from the operators (is the DBA able to wipe the DB all by himself? If yes can you prove he did it and not a hacker ?)
• network access (firewalling, bastion-like aka Teleport, VPN-like aka Tailscale)
• security scans (periodic vulnerability scanning of your Infra)
• training ( for the whole company, phishing trainings etc…) …

I think stuff like yubikeys are very interesting but in the longer run. The thing that helped me a lot is reading the CERTs reports from big companies. They basically detail the main threats they see and most of the time, they are phishing, no firewalling, no regular patching of systems etc… when you cover all the big threats listed, it makes sense to have a risk based approach to understand what is your biggest risk and how to cover it.

Happy to talk over PM if you want :)

I’d recommend creating some checklists for onboarding/offboarding people (and actually use them). We have a template in our issue tracker for this, which has subtasks for all the necessary systems/setup/prep.

I’d also recommend keeping a spreadsheet of a) what services you use and b) who has access to them. Even if the bulk of them run through a single-sign-on provider like Okta, there’ll aways be something that’s incompatible – and those are normally the ones that have terrible audit logs.

Mandate 2-factor authorisation for everything that supports it.

Me, a contract developer and a support/helpdesk/dba person are going to be responsible for all the servers/network/database/etc and the users will never need to know about anything beyond their O365 login.

M365 now supports 2FA, so it’s a good idea to turn that on. If your clients devices are Windows / iOS / Android, the TPM or hardware root-of-trust that they use for credential storage is only slightly less secure than a U2F device (the only difference is that there’s no way of unplugging it, so a compromised OS can mount online attacks longer), and one fewer thing to lose.

The main thing that I’d suggest is to always keep in mind the axiom that if you don’t have security and usability then you don’t have security. If storing things in a secure location is hard, people will store them in insecure locations.

Move away from anything that involves passwords as quickly as you can. M365 and Azure don’t need them, they can use an authenticator app on a phone for folks that move between devices and a local TPM once you’ve authenticated a device. You can then centrally revoke access from that device if it’s stolen. Users will always pick insecure / weak passwords, or they will write them somewhere easy for an attacker to compromise.

For anything that you’re designing, keep two core principles in mind:

• The principle of least privilege. While performing task X, you should have the privileges to perform task X. You should not have any privileges that you don’t need to perform task X.
• The principle of intentionality. When exercising any kind of privilege, you should do so intentionally. RBAC lets you half-arse this (though suffer from role explosion), capability systems let you do it properly (you cannot perform any action unless you present the right capability to authorise it).

My advice would be to keep it simple: Managed server for E-Mail (e.g. Hetzner), Nextcloud for cloud needs, which can also be booked as a managed solution. The rest on separate servers.

I look back on a painful migration away from O365, but it paid out in the end due to the huge problems my customer had with it.

Hardware tokens is a great idea (or at least TOTP for 2FA with SMS not allowed), but I wouldn’t buy in to a single brand. FIDO2 is FIDO2 and many places can manufacture them.

I’m not sure that this is sufficient information - I’m not an IT or sysadmin person, there are other people on lobste.rs who are, but I’ve spent a lot of time dealing with protecting user data, and the nature of the data you end up with impacts how you should store that data, and how much it needs to be secured.

My questions are what data do you have? how much is your own internal data? how much is user data? How is the user data segregated?

The answers to those questions impact how you do data storage.

Use of hardware tokens is similarly ambiguous - there’s a canyon between yubikey as 2fa for logging into your services and yubikey as a device gating access to your company’s code signing key for instance. To be clear, you really need to be using 2FA at this point just in general, but the key material/device a user/employee uses to authenticate shouldn’t also be being used for protection of critical company data.

For setting up the standard service - website, email, etc - other people’s replies seem reasonable to me but again my job has been protecting user data, not company data.