4 ms·

There are a lot of good things mentioned already, to extend on that: * Vulnerability management: Our customers (I do pentests) sometimes only have a vague idea

There are a lot of good things mentioned already, to extend on that: * Vulnerability management: Our customers (I do pentests) sometimes only have a vague idea what IT assets they have and what firmware/software version these are running. Think an Excel list maintained by some random person from accounting, because "IT knows it all and after all all servers&switches are in the network plan". 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 & a weak password (trivial to hack). So get a good idea what hardware you have, and what firmware/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's probably out of "startup budget". Worst case you can always run OpenVAS to scan your intranet. * 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. * If you really have no idea, push for a CISO (and the budget for the CISO to fulfill their role). * You can hire a pentesting company to check your IT (usually this is recommended to be done regularly, e.g. twice a year). * 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're doing IT security wise. But then you should get help anyway. * 2FA with FIDO/U2F/Yubikeys or similar hardware tokens (no need to get the expensive Yubikeys if generic FIDO/U2F do the job as well) * No BYOD * Only IT admins need admin/root privileges on their machines. * If you're using Active Directory: At least use the "legacy AD tier model", or take a look at the https://docs.microsoft.com/en-us/security/compass/privileged-access-access-model https://docs.microsoft.com/en-us/security/compass/privileged... -- if you'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 * Use a password manager; we use the enterprise version of 1Password. If that's out of budget, take a look at vaultwarden (self-hosted bitwarden), which is FOSS; I'm happy with that at home. * I wouldn't have mentioned it, as I don't think it's imperative to have. But since major players had such problems with roll out after their startup phase, I'd take away the opposite lesson of what some people recommend: It might be a good idea to implement DNSSEC early on, while it's easier to integrate and doesn't cause too much trouble. * HTTPS with proper certs for everything. Might be difficult in an intranet: In my lab network I'm running a SmallStep CA with a NameConstraint for 'foobar.tld' (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'd accept). I've setup ACME on that CA, so all my PCs can just do internal HTTP challenges to get/renew certs (DHCP clients are on '$clientname.dhcp.foobar.tld', so they can't spoof e.g. 'vaultwarden.foobar.tld'). However most companies I've seen run a AD-based PKI and use other mechanisms for cert roll out. My variant is still about as safe as Let's Encrypt (as long as the CA VM isn't breached). * If you're running Active Directory (which you want to do in case you'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. * Network segmentation (VLANs) with firewalls between the segments. Only whitelist what's needed; this applies to all segments. I have once reached our "mark" 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 "mark", as well as other highly critical stuff (think: people die if that's pwned). * Facilitate free/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. * Foster a culture of IT security: Don'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.

tptacek 4y ago
Two quick notes: If you really have no idea, push for a CISO (and the budget for the CISO to fulfill their role). There's no hard-and-fast rule for this but the sense I get from doing this work is that the startup industry norm is to make a first security hire somewhere between engineer #20 and #40. That hire is usually not a CISO: your first security hire needs to be a hands-on-keyboard person, and CISOs are not that. "Senior Security Engineer" is probably the modal first security hire at startups, followed by "Director of Security" (for startups that expect to hire security person #2 within 6-9 months of #1). A decent general rule might be "if you have to ask, you shouldn't be hiring a CISO". * You can hire a pentesting company to check your IT (usually this is recommended to be done regularly, e.g. twice a year). The industry standard here is software/prodsec pentests done once a year or on major releases, whichever interval is longer. Figure a serious software pentest is going to cost $25k-35k for a typical SAAS product. You can get network pentests done; they're much cheaper than software pentests. I probably wouldn't do them annually. Also, don't do DNSSEC.
- cpach 4y ago
  What’s the difference between CISO and Director of Security?
  - tptacek 4y ago
    * A CISO designs and staffs the whole security practice. * A CISO is management-team and, especially, customer-facing. * A CISO's reports tend to be managers, not IC's. * A CISO often reports to the CEO, the CFO (if they own risk), and, sometimes, to the board. * A CISO will tend to own multiple security sub-practices: product security, IT security, abuse, sometimes risk. * A Dir/Sec tends to report to engineering management. * A Dir/Sec is occasionally customer-facing, but it's not most of the job. * A Dir/Sec will tend not to own things like abuse and risk. * A Dir/Sec will usually, when first hired, do IC-level work on prodsec and IT security. * A Dir/Sec's reports are usually ICs. A pretty normal progression might be: 1. Hire a Sr Sec Eng 2. Hire another Sr Sec Eng 3. Hire a Dir/Sec 4. Hire a bunch of Sec Eng (build out an ops team, a product security team, and a team for IT stuff) 5. Promote the Dir/Sec to VP/Sec and hire managers for the teams. 6. Get real big. 7. Promote or hire a CISO (the CISO hire is often an opportunity to bring a marquee resume into the company to impress the market). I think the thing to remember about startups is that even startups with traction rarely have the headcount slots to get past (2) or (3) on that list until they have lots of engineers; I don't have numbers to back this up but my guess is that the median startup with a 3+ person security team has over 100 employees. So, if you're talking about your first security hire, as a young startup, it's hard to make a CISO make sense. You might call your first security hire "the CISO", but I'd say willingness to be called a "CISO" at a startup when you have low-single-digit reports is probably a mild red flag for that person. It may be an idiosyncrasy of mine to call the title "Dir/Sec"; "Dir/Sec" is the fluffiest title I think an experienced security person would be comfortable taking in a young startup. But you could also call that person a "Security Manager" or a "Security Lead"; some of this also depends on how flat your org is.

tptacek 4y ago

Two quick notes: If you really have no idea, push for a CISO (and the budget for the CISO to fulfill their role). There's no hard-and-fast rule for this but the sense I get from doing this work is that the startup industry norm is to make a first security hire somewhere between engineer #20 and #40. That hire is usually not a CISO: your first security hire needs to be a hands-on-keyboard person, and CISOs are not that. "Senior Security Engineer" is probably the modal first security hire at startups, followed by "Director of Security" (for startups that expect to hire security person #2 within 6-9 months of #1). A decent general rule might be "if you have to ask, you shouldn't be hiring a CISO". * You can hire a pentesting company to check your IT (usually this is recommended to be done regularly, e.g. twice a year). The industry standard here is software/prodsec pentests done once a year or on major releases, whichever interval is longer. Figure a serious software pentest is going to cost $25k-35k for a typical SAAS product. You can get network pentests done; they're much cheaper than software pentests. I probably wouldn't do them annually. Also, don't do DNSSEC.

cpach 4y ago
What’s the difference between CISO and Director of Security?
- tptacek 4y ago
  * A CISO designs and staffs the whole security practice. * A CISO is management-team and, especially, customer-facing. * A CISO's reports tend to be managers, not IC's. * A CISO often reports to the CEO, the CFO (if they own risk), and, sometimes, to the board. * A CISO will tend to own multiple security sub-practices: product security, IT security, abuse, sometimes risk. * A Dir/Sec tends to report to engineering management. * A Dir/Sec is occasionally customer-facing, but it's not most of the job. * A Dir/Sec will tend not to own things like abuse and risk. * A Dir/Sec will usually, when first hired, do IC-level work on prodsec and IT security. * A Dir/Sec's reports are usually ICs. A pretty normal progression might be: 1. Hire a Sr Sec Eng 2. Hire another Sr Sec Eng 3. Hire a Dir/Sec 4. Hire a bunch of Sec Eng (build out an ops team, a product security team, and a team for IT stuff) 5. Promote the Dir/Sec to VP/Sec and hire managers for the teams. 6. Get real big. 7. Promote or hire a CISO (the CISO hire is often an opportunity to bring a marquee resume into the company to impress the market). I think the thing to remember about startups is that even startups with traction rarely have the headcount slots to get past (2) or (3) on that list until they have lots of engineers; I don't have numbers to back this up but my guess is that the median startup with a 3+ person security team has over 100 employees. So, if you're talking about your first security hire, as a young startup, it's hard to make a CISO make sense. You might call your first security hire "the CISO", but I'd say willingness to be called a "CISO" at a startup when you have low-single-digit reports is probably a mild red flag for that person. It may be an idiosyncrasy of mine to call the title "Dir/Sec"; "Dir/Sec" is the fluffiest title I think an experienced security person would be comfortable taking in a young startup. But you could also call that person a "Security Manager" or a "Security Lead"; some of this also depends on how flat your org is.