Ask HN: IT Security Checklist for Startups?
There are a lot of good things mentioned already, to extend on that:<p>* Vulnerability management: Our customers (I do pentests) sometimes only have a vague idea what IT assets they have and what firmware&#x2F;software version these are running. Think an Excel list maintained by some random person from accounting, because &quot;IT knows it all and after all all servers&amp;switches are in the network plan&quot;. That way you get an out-dated QNAP NAS hosting backups (easy target for ransomware), or an IPMI nobody uses with IPMI-over-LAN enabled &amp; a weak password (trivial to hack). So get a good idea what hardware you have, and what firmware&#x2F;software is running on that. Whatever you use for that, make sure to get notified about new CVEs and general updates. I can not recommend a specific solution, the only thing I was demoed until now was something by Tenable; that was pretty nice but it&#x27;s probably out of &quot;startup budget&quot;. Worst case you can always run OpenVAS to scan your intranet.<p>* Apply the principle of least necessary privilege: If a dev gets pwned, an attacker should not be able to steal all your internal data, only the portion that specific dev needed for their work.<p>* If you really have no idea, push for a CISO (and the budget for the CISO to fulfill their role).<p>* You can hire a pentesting company to check your IT (usually this is recommended to be done regularly, e.g. twice a year).<p>* You can also hire people to assist you with creating a ISO27001-compliant security policy; not sure if that makes sense for a startup, except maybe if you really have no idea what you&#x27;re doing IT security wise. But then you should get help anyway.<p>* 2FA with FIDO&#x2F;U2F&#x2F;Yubikeys or similar hardware tokens (no need to get the expensive Yubikeys if generic FIDO&#x2F;U2F do the job as well)<p>* No BYOD<p>* Only IT admins need admin&#x2F;root privileges on their machines.<p>* If you&#x27;re using Active Directory: At least use the &quot;legacy AD tier model&quot;, or take a look at the <a href="https:&#x2F;&#x2F;docs.microsoft.com&#x2F;en-us&#x2F;security&#x2F;compass&#x2F;privileged-access-access-model" rel="nofollow">https:&#x2F;&#x2F;docs.microsoft.com&#x2F;en-us&#x2F;security&#x2F;compass&#x2F;privileged...</a> -- if you&#x27;re going to go the simple route (giving IT admins one account for their daily work, which also has domain admin privileges) lateral movement on your IT becomes much easier<p>* Use a password manager; we use the enterprise version of 1Password. If that&#x27;s out of budget, take a look at vaultwarden (self-hosted bitwarden), which is FOSS; I&#x27;m happy with that at home.<p>* I wouldn&#x27;t have mentioned it, as I don&#x27;t think it&#x27;s imperative to have. But since major players had such problems with roll out after their startup phase, I&#x27;d take away the opposite lesson of what some people recommend: It might be a good idea to implement DNSSEC early on, while it&#x27;s easier to integrate and doesn&#x27;t cause too much trouble.<p>* HTTPS with proper certs for everything. Might be difficult in an intranet: In my lab network I&#x27;m running a SmallStep CA with a NameConstraint for &#x27;foobar.tld&#x27; (so that can only be used to sign certs for my domain; if it is hacked, an attacker can not produce a cert for google.com that I&#x27;d accept). I&#x27;ve setup ACME on that CA, so all my PCs can just do internal HTTP challenges to get&#x2F;renew certs (DHCP clients are on &#x27;$clientname.dhcp.foobar.tld&#x27;, so they can&#x27;t spoof e.g. &#x27;vaultwarden.foobar.tld&#x27;). However most companies I&#x27;ve seen run a AD-based PKI and use other mechanisms for cert roll out. My variant is still about as safe as Let&#x27;s Encrypt (as long as the CA VM isn&#x27;t breached).<p>* If you&#x27;re running Active Directory (which you want to do in case you&#x27;re on Windows), harden the crap out of it. We usually point our customers to German checklists, but I bet there are also good English language ones.<p>* Network segmentation (VLANs) with firewalls between the segments. Only whitelist what&#x27;s needed; this applies to all segments. I have once reached our &quot;mark&quot; because while they properly firewalled the client VLAN, some VMs (which are intended to be accessible to most users) resided in the server VLAN, which in turn allowed every connection to everywhere - including our &quot;mark&quot;, as well as other <i>highly</i> critical stuff (think: people die if that&#x27;s pwned).<p>* Facilitate free&#x2F;open tools, e.g. OpenVAS or Bloodhound. Re OpenVAS: At our company, we run Nessus internally (we had an extra, unused license due to a project; else our CISO would probably just use OpenVAS) and this helped a lot with finding potential security issues.<p>* Foster a culture of IT security: Don&#x27;t blame the victim for falling for a phishing attack, blame the company for not doing better anti-phishing training. Similarly, devs make mistakes, but you want them to be open about it, not punish them for it.