9 ms·

Ask HN: IT Security Checklist for Startups?

133 points by faizshah 4y ago

Hi HN, Does anyone have a list of IT security stuff that you should setup for your early stage startup? Like for example DNSSEC, VPN, forcing employees to use 2-factor etc.

snowstormsun 4y ago
https://owasp.org/www-project-top-ten/ https://owasp.org/www-project-top-ten/ and the owasp's cheatsheets in general
PeterisP 4y ago
If you do proper 2FA, always change the default credentials (including dev/test/temporary systems!) and test the recovery of your backups you're probably above the median already. Logging turned on, and preferably centralized is also low-hanging fruit. For an early stage startup I feel that some unnecessary risks are caused by the lack of separation of privileges because a few people do have the rights to do everything. I'd recommend having your key people keep a separate account for privileged actions so that you're not reading your email with an account that has the access to the keys of the kingdom, that you're not doing stuff on your cloud provider with a user account that has the privileges to accidentally delete everything. Have the superuser accounts on all the third-party systems be something that you use rarely, make a limited account for your daily work.
dfc 4y ago
https://latacora.micro.blog/2020/03/12/the-soc-starting.html https://latacora.micro.blog/2020/03/12/the-soc-starting.html That is specifically written for startups that may have to do SOC2 compliance in the future. But it is a useful starting point for most people. #1: Single Sign-On #2: PRs, Protected Branches, and CI/CD #3: Centralized Logging #4: Terraform Or Something #5: CloudTrail And AssumeRole #6: MDM #7: VendorSec
- jms703 4y ago
  Came here to post this!
- number6 4y ago
  I am currently stuggeling setting up centralized logging; just can´t grok it. Logstash? Beats? Elastic Agent? Is ELK-Stack right in 2022? How do I get Logs out of Docker to Logstash? Do I? Seems I need to get my head around this...
  - patrakov 4y ago
    Please take a look at Loki. It's more lightweight than the ELK stack.
  - zie 4y ago
    Generally you will find lots of different solutions to make it all work right. None of them are "wrong" or "right", there are 2 pieces to logs: 1) Capturing them 2) Indexing/acting on them Most tools focus on one or the other, some focus on both. > Logstash? Beats? Elastic Agent? Is ELK-Stack right in 2022? Loki and Graylog solve both issues in an integrated way. logstash, beats and syslog tend to focus only on the 1st part, moving the lots to a central place. > How do I get Logs out of Docker to Logstash? Do I? Yes you want the logs from Docker jobs. You can use a sidecar, or you can have the Docker image ship the logs or if you are running k8s, Nomad, etc they might be able to do it for you. The more important thing is the 1st, getting them all to one host, in pretty much any format. Once you have them there, then you can worry about trying to make sense of them.
    - theblazehen 4y ago
      I'm pretty happy with Loki + promtail so far
      - number6 4y ago
        I will set it up next Day at work, thanks for the advice
        alexjplant 4y ago
        If you do I strongly recommend storing the indices with the chunks[0] and configuring a hassle-free, scalable storage solution [1] up front. Migrating chunk storage after the fact is a royal pain. Do also note that the official Helm chart will only get you so far before you have to start horizontally scaling individual components [2]; depending upon your query and log volume you might want to scale these separately and the chart [3] doesn't support this. This GitHub issue [4] has some Kubernetes YAML examples if you need them. [0] https://grafana.com/docs/loki/latest/operations/storage/boltdb-shipper/ https://grafana.com/docs/loki/latest/operations/storage/bolt... [1] https://grafana.com/docs/loki/latest/operations/storage/#supported-stores https://grafana.com/docs/loki/latest/operations/storage/#sup... [2] https://grafana.com/docs/loki/latest/fundamentals/architecture/components/ https://grafana.com/docs/loki/latest/fundamentals/architectu... [3] https://github.com/grafana/helm-charts/blob/main/charts/loki/templates/statefulset.yaml https://github.com/grafana/helm-charts/blob/main/charts/loki... [4] https://github.com/grafana/loki/issues/643 https://github.com/grafana/loki/issues/643
- pc86 4y ago
  The most important (IMO) paragraph from that page: > If there is one thing to understand about SOC2 audits, it’s: SOC2 is about documentation, not reality. SOC2 audits are performed by accountants, not pentesters. You’ll tell your audit team what security things you try to do. They’ll call upon the four cardinal directions of ontology in a ceremony of shamanic accountancy. They’ll tell you those security things are just fine. Then they’ll give you a 52,000-line questionnaire called the Information Request List (IRL), based in some occult way on what you told them you’re doing. And you’ll fill it out. You’ll have a few meetings and then write them a check. They’ll put your company name on a report.
  - gooseyman 4y ago
    First job after college was subbing in for a team doing a SOC2 audit. They sent me in to test AD. I googled AD before the client meeting to learn that it was this thing called Active Directory. They had really well documented controls and the screenshot of the AD settings they sent me looked great in my report. (Yup - all AD settings in one screenshot).
- dyeje 4y ago
  IMO 1, 5, and 6 are not appropriate for early stage startups (unless you’re making enterprise software). They’re going to slow you down, add unnecessary burn, and just generally not be value adds. You should be focused on making a product that people pay money for, not box checking for a hypothetical SOC2.
  - tptacek 4y ago
    I wrote this list, several years ago. I've since had the pleasure of taking a fast-growing startup (Fly.io) through SOC2. (This list was based on my experience consulting with a bunch of large-ish startups while they were SOC2'ing, and interviewing peers). I would hold fast on #1 (Single Sign-On). Do SSO now. Make it one of the first security things you do. It's worth it on its own merits, and if you do it right, it makes things easier, not harder. My one-two punch for most startups would be Google SSO and Tailscale. If you're hosting in AWS, you basically have to turn CloudTrail on, which was my #5. It's not slowing you down; you just need the data collecting. You can't deploy on AWS and not have an audit trail; that's bananas. If I was writing that article over again, I'd strike #6 (MDM). It's fallen out of fashion to do endpoint security in SOC2; you should introduce endpoint security when you have the bandwidth to do it well. So: #1-5 and #7, I'd do right away. #6, I'd wait until after my first security hire.
    - dyeje 4y ago
      It’s a good list and I’ve referenced it a few times over the years. I misunderstood your intent on #5. I still think SSO is inappropriate because it’s going to bump you into enterprise tiers for random products when you need to be the most frugal with your burn. Going with 1Password or similar gets the job done. You 100% need SSO eventually and it does get harder to implement the longer you wait, but I still don’t think it’s worth it early. I think MDM is still a thing for SOC2, but my point is that most startups will not need a SOC2 immediately and folks should be mindful of what moves the needle security wise vs what auditors want.
      - tptacek 4y ago
        We just did a SOC2, and were encouraged not to do endpoint stuff in it. You can ask your auditors to require MDM, but you don't have to, and shouldn't. You can pick which apps to enroll in SSO; you don't have to pay the sso.tax on everything. Most of the time it's not material anyways.
- throwawaymanbot 4y ago
r4vik 4y ago
It's all about good hygiene early. - MDM for laptops/phones, don't let people use their own devices. The point of MDM isn't to stop people installing their favourite IDE, the point of it is to make sure the device is patched and running latest OS. If you have a VPN (even AWS Client VPN supports this...) tie MDM together with device attestation so only patched machines can connect to your VPN. - Unified login, for a start up you can use Google workspace or even GitHub as your identity provider (this gets weird if you have non-devs but you can push it for a bit). Don't have more than one account/password for things, you just log into your google account then use OIDC/SAML to auth against internal apps. If you do this you probably don't need VPN. Use this to auth into AWS too. - Don't share accounts on SaaS services (e.g domain registrar), this will make rotating stuff when someone leaves a nightmare. If a service doesn't support teams or you don't want to pay for the enterprise version then it's OK for the CTO and 1 other person to have their own login. - Minimise/avoid static credentials for your infra (e.g. web server talking to postgres) prefer to use AWS Instance roles with short lived dynamic credentials. - Make sure network isolation is set up correctly, your Mongo db shouldn't be listening on the internet - Use 2fa but make sure it's WebAuthn/FIDO. Issue everyone with 2x security keys. People wipe / screw up their phones/TOTP authenticator apps far too much. - Centralised logging, make sure your apps can output logs to opensearch/datadog/whatever. Whenever a user performs an action make sure this gets logged. - Don't let people manage prod infrastructure without using Infrastructure as code tools (CDK/Pulumi/Terraform), best thing would be not to give people prod access and all changes have to go through CI - Make sure you know your product is down before your users start calling/emailing. Set up healhchecks.io / pingdom whatever.
- dissent 4y ago
  MDM for laptops? No thanks. It's a world of security theatre - the main purpose of which seems to be to stop me doing my job. Also it invariably means Windows.
  - eswat 4y ago
    MDM doesn't have to be a heavy-handed thing and solutions exist for macOS at least. Even something that just makes sure the OS and critical apps always have the latest security patches - and ideally pushes those changes when it’s not disruptive to the host – can go a long way.
ross-sec-audio 4y ago
--- CIS Top 18: --- CIS have a top 18 critical security control checklist, which is pretty incredible. https://www.cisecurity.org/controls/cis-controls-list https://www.cisecurity.org/controls/cis-controls-list CIS Top 18 Version 8 works sequentially too, so you implement control 1 and it sets you up in a good place to then implement control 2, and so on. --- Cyber Essentials: --- The UK's Cyber Essentials scheme is a certification standard (but you can ignore that and just use it as a checklist if you'd like). It's designed for small to medium size organizations, and focused on getting the foundations right. This would be a useful place to start but it won't cover some of the specific threats and risks associated with software/app development. See @snowstormsun's comment about OWASP Top 10 for that. https://www.ncsc.gov.uk/cyberessentials/overview https://www.ncsc.gov.uk/cyberessentials/overview --- There's loads of other standards like this out there, that are free to use and are each focused on different security challenges etc. I've shared these two standards as they both setup a solid foundation.
- tptacek 4y ago
  This list is very general (it's about high-level controls, not actual tactics) and is geared towards enterprises, so there are things on it that definitely are not startup best-practices. For example: most startups don't do any serious network monitoring (even if they do operate monitorable networks, which isn't a given).
- westurner 4y ago
  https://dev-sec.io/baselines/ https://dev-sec.io/baselines/ has executable implementations of CIS and other guides
willfarrell 4y ago
OWASP has everything you need; SAMM for policies and procedures https://owasp.org/www-project-samm/ https://owasp.org/www-project-samm/ ASVS for your application https://owasp.org/www-project-application-security-verification-standard/ https://owasp.org/www-project-application-security-verificat...
Amedeemus 4y ago
I do not know of a go-to checklist but as I work in the industry, I hope I can provide some tips from experience. Any service that is needed for the day-to-day working of your business should be properly secured. You mention DNSSEC but it starts with the user accounts that are used to log in to your registrar, hosting provider, payment provider, any SaaS... Generate unique, strong passwords for every business related service. Use a password vault like keepass or a service like 1password for secure storage and ease of use. Multi-factor everything you can, and prefer to use an app or physical token over SMS-based multifactor. I have recommended Twilio Authy a lot due to the multi-device support and google authenticator compatibility. Use DNSSEC for your domain(s), enable SPF, DKIM and DMARC for your mail, set up TLS for your website(s). Depending your needs, cloudflare has some great options for the latter. Security of the endpoints and endusers greatly depends on wether your employees BYOD, what the network looks like and most of all, what you are protecting. I recommend to search for some public "acceptable use policy" or "security policy" documents, especially in the context of ISO27001 and create an own policy based on that, depending on your needs and environment. Even better than policy is proper training for employees on security hygiene, how to avoid phishing and if relevant, secure development. Ceate an open environment for employees to report potential issues or mistakes. Regarding secure development, OWASP is a great resource for anything application security.
- tptacek 4y ago
  You're recommending this startup do DNSSEC. Can you rattle off some pre-acquisition startups of any note that have DNSSEC-signed their domains? Slack, for instance, is DNSSEC-signed (signing infamously took them off the Internet for the better part of a day) --- because Salesforce, their acquirer, required it; they did the same to Heroku (which also suffered a DNS outage). My point is not so much to litigate DNSSEC itself (although I'll do that) as it is to establish the ground truth that DNSSEC-signing is not a norm among tech companies. It would be a particularly weird bit of ops overhead for a young startup to invest in. If you'd like some tips on how to quickly test whether a startup (or a large list of them) have signed their domains, I'm happy to help.
  - Amedeemus 4y ago
paulschreiber 4y ago
Mandatory Yubikeys should be on your list.
dogman144 4y ago
this stage security program needs to make technical security decisions that have large risk management payoffs versus the effort involved. You also have to understand the accepted risks are huge, and you have to focus on risks that span infra, the enterprise, endpoints, and GRC. A narrow technical focus won’t help much. Outside of basic netsec for your app and “corporate network” (creatively defined for a remote startup), it’s worth focusing on decisions that do initial security hygiene that long term really helps but is hard to fix retroactively, and once in place it’s easier to build the exotic controls on top of. You should also not forget basic GRC capabilities, as a bulk of the “doing security” tasks can easily turn into passing vendor audits and RFPs because sales is big for a startup, so having a bank of security policies complete way ahead of time and knowing the way around frameworks like CIS or NIST CSF will save you a lot of work during a sales-stress period. So, in practice, I think getting these done early naturally leads to good decisions and a decent security program to start. - corporate IT: > seriously, make a large and vocal push to get off of personal computers and on to work laptops. Its worth burning some of your security capital for. All of the follow-on work you’ll do for security, to include sales support for the startup (so, you can tie this decision to revenue) gets undermined security-technically and passing audit-ally via work on personal computers. > password manager, or can get by for a while with in-browser password managers vs LastPass > secrets management: very early on, get a firm handle where the passwords/keys to production and service accounts are, store them in a shareable way (AWS secrets manager or shared LastPass), and don’t budge on this. They will too easily (and probably will anyway) end up all over developer computers and note apps. Eventually one will leak this way. By having a work computer, easier to guarantee safety around this loose secrets manager. By having them stored how I said, easy to find and rotate when they leak. > have 2Fa/MFA setup by default from the get go. Don’t make compromises on this > MDM/EDR: start trying to move towards this, but work computers are worth getting deployed prior to pushing for MDM. MDM or anti-virus or preferable EDR will show up as a requirement very soon via sales or audits. EDR can be surprisingly cheap for a small fleet of computers, so I’d look there and skip AV and table MDM. Also, these tools will generate alerts, so you’ll have to have a process in place to respond to the alerts. - Developer productivity > get the enterprise GitHub hardened very early on - know where the audit logs are, turn on alerts that GH has for free for compromised dependencies, and have a plan for API keys ending up in GH, yours or personal ones accidentally pushed to. Both will happen. > get a handle on what IDE extensions are installed, and have a firm line on what is not safe to install, and get a senior eng leader to verify and support this decision. Stuff like a random extension to connect and quickly test a prod DB via your IDE suddenly leads to a random malicious extension having your prod DB secrets and connection string. It’s not worth pursuing white/blacklists really, but it’s worth getting a list of really unsafe library types to use and make sure everyone knows why. - AWS > heavily support any impulse in the company to use IaC - cloudformation, terrsrorm, etc. this will get a lot of secure-by-default capabilities in place. > turn on guardduty across all accounts and start watching. I’d stay away from securityhub as it generates a lot of noise and it’s not worth knowing about until you have the means to fix it and other stuff is taken care of in this list. > build your cloud accounts under an AWS Organization or equivalent. If accounts start under an Org, it’s much easier to build and enforce blanket configs/tooling across all of them, which is needed for security. - incident response > build a shell plan for handling incidents. It’ll help everyone, to include non-security incidents like prod crashing. It’ll also save your butt in a security incident. What matters in them is good documentation and good processes, because if/when a security incident happens, being able to answer what you did and why/when is key as all that data surfaces to legal and/or media comms eventually. - compliance/GRC: > try to get a sales RFP or vendor audit doc and look what they ask for in security evals. Your sales team may totally be BS’ing these answers currently, forewarning. Figure out what’s asked, prepare those documents. - further ideas > where do I find someone to do this: Finding sec eng to take all this on could be hard. This is like a CISO in a box with a fraction or none of the usual funding and headcount. You could then hire a non-technical security lead, but that could turn into an advice/doom machine who isn’t helping fix tech. Sec eng or VP security, either way the salaries are high - $145k base and way up. A sec analyst, who is cheaper, won’t help at this point. So, my advice is pay up for a sec eng who is strong on infra, or pair a security-conscious IT and/or a security conscious devops/infra lead with a comp sci-ish college student with a cloud cert looking to break into security engineering. They’ll get their break, you’ll get someone who knows tech/security but won’t cost a ton and will take a job like this to get the resume bullet (security engineering is hard to break into), and you’ll have someone watching all this and a strong IT and infra eng to help guide them. > I want a framework to follow still: CIS benchmark or better NIST cybersecurity framework. I’d go for the latter. Focusing on CIS or similar can lead to a narrow IT security focus that doesn’t help with actually building a security program, which is what the startup needs. Edit - other advice ITT like leveraging SSO/Gsuite heavily and IAM roles over secrets are really sound.
zach_garwood 4y ago
My former employer, Havoc Shield, is a service to helps small businesses and startups establish a basic security posture: https://havocshield.com/ https://havocshield.com/
cols 4y ago
For application development, the SANS Web App Security Checklist is good: https://www.sans.org/cloud-security/securing-web-application-technologies/ https://www.sans.org/cloud-security/securing-web-application...
belter 4y ago
If you use Cloud, look first, at the best practices resources available from your Cloud provider.
tptacek 4y ago
Your startup should absolutely not be doing DNSSEC; virtually nobody does this, most especially at successful startups with security teams. This is a good example of why a good checklist like this would be useful; I wish I had one to offer.
cweagans 4y ago
Resources I know of that may be of interest: https://github.com/strongdm/comply https://github.com/strongdm/comply https://www.security4startups.com/ https://www.security4startups.com/
mattpallissard 4y ago
Shameless plug. I'm an independent consultant that can help guide infrastructure and devops decisions in early stage start ups. I've spent a lot of time in highly regulated industries. Feel free to reach out with any questions. contact at pallissard dot net.
deleted 4y ago
[deleted]
patrakov 4y ago
Let me share my (unpopular) opinion: whatever minimum mandated by the applicable laws, and nothing else. If you are not a bank, and don't have EU customers, it could as well be an empty checklist. If you need anything more, you are not a startup. Well, if you disagree, let me add one item to your checklist: know when to stop expanding it. Rationale: I have seen enough organizations with the checklist-based approach to security. In all of them, it had nothing to do with actual security, but with convincing customers that the organization is safe to deal with - even if it is in fact false. People responsible for filling in such questionnaires often had an outdated vision of the practices of the company. Also, once you allow any checklist in, or hire any so-called cybersecurity expert who is actually a checkbox-ticking expert, you will be under constant pressure to strengthen this "security posture" more and more, way beyond reasonable. Hypothetical example: this expert decides that you have to comply with Cyber Essentials, and one of the requirements is to install, on each laptop and desktop, an antivirus that can live-check all of the web pages loaded in browsers. But no such desktop-ready thing exists for Linux, and this expert will tell you to stop using Linux on desktops, thus leading to mass-resignation of developers. While the proper solution would have been "don't deal with the UK government".
hkgjjgjfjfjfjf 4y ago
archi42 4y ago
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.
_tk_ 4y ago
Giving security advice in a format like this is always a bit weird. You will never catch all interesting bits much less all the edge cases. On top of that Thomas Ptacek is watching your every move. As already noted, a tailored list for startups doesn't really exist. IMO, there are two approaches when it comes to establishing security in a Startup. You can either go the standard route or the checklist route. 1. Standard route: You hire a consultant, decide on a standard (preferably ISO27k) and go implementing. Costs a lot of money, takes a lot of time/energy, you will be happy about it in the future, if your company is not broke by then. The German Federal Office for Information Security has adapted the ISO27001 standard in the past and created the so called Core Protection methodology. You can find the details here: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Grundschutz/International/bsi-standard-2002_en_pdf.pdf?__blob=publicationFile&v=2 https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Grundsch... It's a nice compromise between adherence to the standard and pragmatism. As a Startup you basically want to protect two things: your IP and availability of your product. The core protection method allows you to specify a very narrow scope that you want to protect and helps you to develop protection requirements. 2. The checklist route: If standards are not your thing, I would advise you to take a look at CISA's "Cyber Essentials" checklist for Small and Midsize Businesses. If you have 90% of these things implemented - which should be very easy for a startup - you will have a better security posture than 90% of all other companies out there (if not more). https://www.cisa.gov/cyber-essentials https://www.cisa.gov/cyber-essentials
- baxtr 4y ago
  > As a Startup you basically want to protect two things: your IP and availability of your product. On what basis do you make this claim? I’m working in cyber and see the damage side in large companies. IP is never a thing. It’s mostly service / production availability and, with companies doing business in the US, data breaches (loss of PII).
  - bornfreddy 4y ago
    Also missing, from the top of my head: your customers' data, company reputation, trade secrets,...
fouadmatin 4y ago
We wrote up a starting five on our blog at Indent: https://indent.com/blog/security-for-startups-the-starting-five https://indent.com/blog/security-for-startups-the-starting-f... 1. Create a security policy — decide what does/doesn't matter 2. Train employees on security — just do the basic stuff, but all the time (strong passwords, 2FA) 3. Implement security measures — for what matters, take security very seriously 4. Use single sign-on — whether it's Google SSO/Okta/etc, you'll thank yourself later 5. Grant access on-demand — people generally don't need permanent access to sensitive systems, set up groups and grant people time-bounded roles
coleca 4y ago
In addition to the advice already commented, if you are using AWS I'd recommend checking out our recently released AWS Startup Security Baseline Prescriptive Guidance: https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-startup-security-baseline/welcome.html https://docs.aws.amazon.com/prescriptive-guidance/latest/aws... This is not a comprehensive checklist per se, but a minimum set of security controls to implement to help secure your AWS account and workloads running on AWS within your account.
deleted 4y ago
[deleted]
mikewarot 4y ago
If you're building a product, consider using capability based security.[1] A capability is an access token to a resource, and NOT a user account. Think of it as a $10 bill. If you pull a $10 capability from your wallet, you can't lose $1000 by accident, no matter how badly things go. Flickr makes it possible to give out a guest pass for photos, for example.[2] The nice thing about a guest pass is you can revoke it at any time. [1] - https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security [2] - https://www.flickrhelp.com/hc/en-us/articles/4404069601172-Create-or-delete-temporary-Guest-Passes-in-Flickr https://www.flickrhelp.com/hc/en-us/articles/4404069601172-C...
nokya 4y ago
By just looking at the vast variety of answers in this thread, I think we have a telltale sign of the magnitude of the problem, and the state of denial in which society has evolved. Whether a startup, a small company or a large corporation, there is at least one IT security standard in each developed country, if not an international standard (e.g., ISO27002 , NIST cybersecurity, etc.). Their role is exactly what they are called for: they tell whoever owns an IT system what should be done to protect it. Unless you're an academic doing research, or you have personally reached the limits of a standard in your organization, there is no reason to look elsewhere. Pull the standard from your country, or pull the ISO27002, and start working on your spreadsheet and assigning tasks :)
- tptacek 4y ago
  The idea that national security standards are the actual blueprint for running a security practice at a startup is risible.
comprambler 4y ago
Read the entire thread and didn’t see the obvious: #1. Living Asset Inventory (constantly updated automatically) #2. Intelligence on these Assets (can be mdm, but at least reporting of sysinfo, os update version, security version) #3. Automatic patching of both security software and os version. #4. Centralized identity management (Azure AD, other SAML options) with security intelligence builtin.
unixsheikh 4y ago
I am sorry, but if you need someone else to provide you with a list like that, you should NOT be doing this. It is the wrong approach on so many levels.
- faizshah 4y ago
  Maybe I should clarify why. I am a full stack engineer and I am familiar with the basic AppSec stuff you need to launch a service at a FAANG company. However I am not familiar with the basic IT Security stuff you should setup when forming a new company. When I was researching what I should setup for IT security the documentation began referencing things like DMARC, DNSSEC, DKIM etc. and I realized I don’t know what is the basic level of security I should setup. So I just want to know what is the basic security stuff an early stage company should setup before hiring their first security engineer. The answer to this question can’t be “you should NOT be doing this” because you should still need security even before your first security hire or before you can afford a security consultant.
Mandatum 4y ago
2FA is fine. Don't bother with VPN's if you're SaaS-based. Just take the zero-trust route with mandatory MFA everywhere, invest in Yubikeys for all employees and set up a SIEM box to ingress audit logs from your various systems. Setting up an Elastic box for this should be relatively straightforward. For many people it's easier to keep SIEM locally hosted (pulling data, no external access) and then periodically push encrypted backups offsite). You'll probably end up setting up business metrics monitoring from this eventually too, at least in the early days before you start the "data lake" approach. DNSSEC is a waste of time right now.
_8j50 4y ago
Others mention important things but go nowhere near as far as they should. I can list dozens of high level things you should have on that list, but I think the most important decision is at what point will you hire a dedicated career-security person? The earlier the better. You can have protected branches, pubkey auth everywhere with yubikeys and macs everywhere it all helps reduce noise but security architecture ensures there are no cracks in your defenses. These checklist solutions can do more harm than good by leaving you with the impression that you have a better security-posture and risk appettite than you actually do leading you to make catastrophic decisions. IT/OPs/Engineering folks who know enough security to be dangerous would say things like "but _____ defensive measure is there,that wouldn't work" or "if they got past all this then we have bigger issues anyways" and be dangerously wrong. 2FA with yubi? Cookie theft is now popular. SSH pubkey on a mac? Commodity multiplatform stealers in Rust and Golang of course are a thing and they include stealing private keys and sensitive files as a feature. MDM doesn't protect you against malware and SSO while still should be implemented makes cookie theft one working attack away from pwning all things the user has access to. Boring old things like segmentation, (good)logging and proactive monitoring (probably MSP for you at the start) are still top of the "list" and despite what pop-security personalities have you believe, not only do you need AV but you need a cross-platform good EDR as soon as possible as well as corporate VPNs and while gsuite is popular with startups, O365 has better security and DLP. I could go on but my point is you at least need a consultant at the begining and have a solid plan on when you will hire a proper security pro to architect things and make all the devs and engineers do things they disagree with passionately leading some to even leave lol.
- tptacek 4y ago
  O365 and DLP are absolutely not startup best practices. Almost nobody uses either. As I've noted elsewhere on the thread, the norm among startups is to make a first security hire somewhere between engineer #20 and #40. Pentesters usually get brought in after PMF, sometime around the "first version" of the product the startup settles on.
  - _8j50 4y ago
    "Almost nobody uses either." I am very aware, I noted that in my comment. Are you saying O365 and AIP are inferior than gsuite, if so I would like to hear why, I don't favor either I just haven't seen why. DLP is absolutley a foundational security practice, especially for a startup because they usually have some "secret sauce" and all it takes is one employee leaking that and most people that leak/sell-out just print or take the document with them, a starup maybe drowning in VC money but it all comes down crashing the moment you someone else does it better. As far as the security hire and pentesters, I don't particulary mind the norm so long as you made that decision and planned on it from the start. Also on O365, if you're a mac shop I still say it's better but for windows shops (as rare as that is at a startup) you must use AAD and it solves a lot of problems out of the box when you marry it with O365 and you don't have to worry about google banning you on a whim and crashing your business. I am all for best practices but those are different than monkey-see-moneky-do copying without critically reasoning and defining why that decision is best.
more_corn 4y ago
Require disk encryption and screen lock. Deploy SSO everywhere you can. Provide a password manager. No passwords in slack. If they show up they have to be rotated immediately. Create a simple security policy (and password policy) to let people know expectations. Create an onboarding and off boarding checklist. Create a BYOD policy (if people choose to have work coms on their phone) Require phone password, encryption and find my device. Prohibit password reuse. Buy people yubikes if they want em. Encourage 2fa Rotate credentials at most annually. Create a culture of blameless postmortems so people feel comfortable raising concerns early. Set up your cloud accounts with SSO. Secure your CI/CD system. It usually has the keys to the castle. Deploy or enable cred-scan, dep-scan, sast-scan in CI/CD Don’t allow public items in S3 buckets unless the bucket is explicitly public.
captn3m0 4y ago
- https://s3-eu-west-1.amazonaws.com/sqreen-assets/whitepapers/SaaS+CTO+Security+Checklist.pdf https://s3-eu-west-1.amazonaws.com/sqreen-assets/whitepapers... - https://www.goldfiglabs.com/guide/saas-cto-security-checklist/ https://www.goldfiglabs.com/guide/saas-cto-security-checklis...
westurner 4y ago
From https://news.ycombinator.com/item?id=30906310 https://news.ycombinator.com/item?id=30906310 : > "The SaaS CTO Security Checklist [Redux]" https://github.com/vikrum/SecurityChecklists https://github.com/vikrum/SecurityChecklists > "The Personal Infosec & Security Checklist" https://www.goldfiglabs.com/guide/personal-infosec-security-checklist/ https://www.goldfiglabs.com/guide/personal-infosec-security-... > "The DevOps Security Checklist Redux" https://www.goldfiglabs.com/guide/devops-security-checklist/ https://www.goldfiglabs.com/guide/devops-security-checklist/

133 points by faizshah 4y ago

Hi HN, Does anyone have a list of IT security stuff that you should setup for your early stage startup? Like for example DNSSEC, VPN, forcing employees to use 2-factor etc.

snowstormsun 4y ago

https://owasp.org/www-project-top-ten/ https://owasp.org/www-project-top-ten/ and the owasp's cheatsheets in general

PeterisP 4y ago

If you do proper 2FA, always change the default credentials (including dev/test/temporary systems!) and test the recovery of your backups you're probably above the median already. Logging turned on, and preferably centralized is also low-hanging fruit. For an early stage startup I feel that some unnecessary risks are caused by the lack of separation of privileges because a few people do have the rights to do everything. I'd recommend having your key people keep a separate account for privileged actions so that you're not reading your email with an account that has the access to the keys of the kingdom, that you're not doing stuff on your cloud provider with a user account that has the privileges to accidentally delete everything. Have the superuser accounts on all the third-party systems be something that you use rarely, make a limited account for your daily work.

dfc 4y ago

https://latacora.micro.blog/2020/03/12/the-soc-starting.html https://latacora.micro.blog/2020/03/12/the-soc-starting.html That is specifically written for startups that may have to do SOC2 compliance in the future. But it is a useful starting point for most people. #1: Single Sign-On #2: PRs, Protected Branches, and CI/CD #3: Centralized Logging #4: Terraform Or Something #5: CloudTrail And AssumeRole #6: MDM #7: VendorSec

jms703 4y ago
Came here to post this!
number6 4y ago
I am currently stuggeling setting up centralized logging; just can´t grok it. Logstash? Beats? Elastic Agent? Is ELK-Stack right in 2022? How do I get Logs out of Docker to Logstash? Do I? Seems I need to get my head around this...
- patrakov 4y ago
  Please take a look at Loki. It's more lightweight than the ELK stack.
- zie 4y ago
  Generally you will find lots of different solutions to make it all work right. None of them are "wrong" or "right", there are 2 pieces to logs: 1) Capturing them 2) Indexing/acting on them Most tools focus on one or the other, some focus on both. > Logstash? Beats? Elastic Agent? Is ELK-Stack right in 2022? Loki and Graylog solve both issues in an integrated way. logstash, beats and syslog tend to focus only on the 1st part, moving the lots to a central place. > How do I get Logs out of Docker to Logstash? Do I? Yes you want the logs from Docker jobs. You can use a sidecar, or you can have the Docker image ship the logs or if you are running k8s, Nomad, etc they might be able to do it for you. The more important thing is the 1st, getting them all to one host, in pretty much any format. Once you have them there, then you can worry about trying to make sense of them.
  - theblazehen 4y ago
    I'm pretty happy with Loki + promtail so far
    - number6 4y ago
      I will set it up next Day at work, thanks for the advice
      - alexjplant 4y ago
        If you do I strongly recommend storing the indices with the chunks[0] and configuring a hassle-free, scalable storage solution [1] up front. Migrating chunk storage after the fact is a royal pain. Do also note that the official Helm chart will only get you so far before you have to start horizontally scaling individual components [2]; depending upon your query and log volume you might want to scale these separately and the chart [3] doesn't support this. This GitHub issue [4] has some Kubernetes YAML examples if you need them. [0] https://grafana.com/docs/loki/latest/operations/storage/boltdb-shipper/ https://grafana.com/docs/loki/latest/operations/storage/bolt... [1] https://grafana.com/docs/loki/latest/operations/storage/#supported-stores https://grafana.com/docs/loki/latest/operations/storage/#sup... [2] https://grafana.com/docs/loki/latest/fundamentals/architecture/components/ https://grafana.com/docs/loki/latest/fundamentals/architectu... [3] https://github.com/grafana/helm-charts/blob/main/charts/loki/templates/statefulset.yaml https://github.com/grafana/helm-charts/blob/main/charts/loki... [4] https://github.com/grafana/loki/issues/643 https://github.com/grafana/loki/issues/643
pc86 4y ago
The most important (IMO) paragraph from that page: > If there is one thing to understand about SOC2 audits, it’s: SOC2 is about documentation, not reality. SOC2 audits are performed by accountants, not pentesters. You’ll tell your audit team what security things you try to do. They’ll call upon the four cardinal directions of ontology in a ceremony of shamanic accountancy. They’ll tell you those security things are just fine. Then they’ll give you a 52,000-line questionnaire called the Information Request List (IRL), based in some occult way on what you told them you’re doing. And you’ll fill it out. You’ll have a few meetings and then write them a check. They’ll put your company name on a report.
- gooseyman 4y ago
  First job after college was subbing in for a team doing a SOC2 audit. They sent me in to test AD. I googled AD before the client meeting to learn that it was this thing called Active Directory. They had really well documented controls and the screenshot of the AD settings they sent me looked great in my report. (Yup - all AD settings in one screenshot).
dyeje 4y ago
IMO 1, 5, and 6 are not appropriate for early stage startups (unless you’re making enterprise software). They’re going to slow you down, add unnecessary burn, and just generally not be value adds. You should be focused on making a product that people pay money for, not box checking for a hypothetical SOC2.
- tptacek 4y ago
  I wrote this list, several years ago. I've since had the pleasure of taking a fast-growing startup (Fly.io) through SOC2. (This list was based on my experience consulting with a bunch of large-ish startups while they were SOC2'ing, and interviewing peers). I would hold fast on #1 (Single Sign-On). Do SSO now. Make it one of the first security things you do. It's worth it on its own merits, and if you do it right, it makes things easier, not harder. My one-two punch for most startups would be Google SSO and Tailscale. If you're hosting in AWS, you basically have to turn CloudTrail on, which was my #5. It's not slowing you down; you just need the data collecting. You can't deploy on AWS and not have an audit trail; that's bananas. If I was writing that article over again, I'd strike #6 (MDM). It's fallen out of fashion to do endpoint security in SOC2; you should introduce endpoint security when you have the bandwidth to do it well. So: #1-5 and #7, I'd do right away. #6, I'd wait until after my first security hire.
  - dyeje 4y ago
    It’s a good list and I’ve referenced it a few times over the years. I misunderstood your intent on #5. I still think SSO is inappropriate because it’s going to bump you into enterprise tiers for random products when you need to be the most frugal with your burn. Going with 1Password or similar gets the job done. You 100% need SSO eventually and it does get harder to implement the longer you wait, but I still don’t think it’s worth it early. I think MDM is still a thing for SOC2, but my point is that most startups will not need a SOC2 immediately and folks should be mindful of what moves the needle security wise vs what auditors want.
    - tptacek 4y ago
      We just did a SOC2, and were encouraged not to do endpoint stuff in it. You can ask your auditors to require MDM, but you don't have to, and shouldn't. You can pick which apps to enroll in SSO; you don't have to pay the sso.tax on everything. Most of the time it's not material anyways.
throwawaymanbot 4y ago

r4vik 4y ago

It's all about good hygiene early. - MDM for laptops/phones, don't let people use their own devices. The point of MDM isn't to stop people installing their favourite IDE, the point of it is to make sure the device is patched and running latest OS. If you have a VPN (even AWS Client VPN supports this...) tie MDM together with device attestation so only patched machines can connect to your VPN. - Unified login, for a start up you can use Google workspace or even GitHub as your identity provider (this gets weird if you have non-devs but you can push it for a bit). Don't have more than one account/password for things, you just log into your google account then use OIDC/SAML to auth against internal apps. If you do this you probably don't need VPN. Use this to auth into AWS too. - Don't share accounts on SaaS services (e.g domain registrar), this will make rotating stuff when someone leaves a nightmare. If a service doesn't support teams or you don't want to pay for the enterprise version then it's OK for the CTO and 1 other person to have their own login. - Minimise/avoid static credentials for your infra (e.g. web server talking to postgres) prefer to use AWS Instance roles with short lived dynamic credentials. - Make sure network isolation is set up correctly, your Mongo db shouldn't be listening on the internet - Use 2fa but make sure it's WebAuthn/FIDO. Issue everyone with 2x security keys. People wipe / screw up their phones/TOTP authenticator apps far too much. - Centralised logging, make sure your apps can output logs to opensearch/datadog/whatever. Whenever a user performs an action make sure this gets logged. - Don't let people manage prod infrastructure without using Infrastructure as code tools (CDK/Pulumi/Terraform), best thing would be not to give people prod access and all changes have to go through CI - Make sure you know your product is down before your users start calling/emailing. Set up healhchecks.io / pingdom whatever.

dissent 4y ago
MDM for laptops? No thanks. It's a world of security theatre - the main purpose of which seems to be to stop me doing my job. Also it invariably means Windows.
- eswat 4y ago
  MDM doesn't have to be a heavy-handed thing and solutions exist for macOS at least. Even something that just makes sure the OS and critical apps always have the latest security patches - and ideally pushes those changes when it’s not disruptive to the host – can go a long way.

ross-sec-audio 4y ago

--- CIS Top 18: --- CIS have a top 18 critical security control checklist, which is pretty incredible. https://www.cisecurity.org/controls/cis-controls-list https://www.cisecurity.org/controls/cis-controls-list CIS Top 18 Version 8 works sequentially too, so you implement control 1 and it sets you up in a good place to then implement control 2, and so on. --- Cyber Essentials: --- The UK's Cyber Essentials scheme is a certification standard (but you can ignore that and just use it as a checklist if you'd like). It's designed for small to medium size organizations, and focused on getting the foundations right. This would be a useful place to start but it won't cover some of the specific threats and risks associated with software/app development. See @snowstormsun's comment about OWASP Top 10 for that. https://www.ncsc.gov.uk/cyberessentials/overview https://www.ncsc.gov.uk/cyberessentials/overview --- There's loads of other standards like this out there, that are free to use and are each focused on different security challenges etc. I've shared these two standards as they both setup a solid foundation.

tptacek 4y ago
This list is very general (it's about high-level controls, not actual tactics) and is geared towards enterprises, so there are things on it that definitely are not startup best-practices. For example: most startups don't do any serious network monitoring (even if they do operate monitorable networks, which isn't a given).
westurner 4y ago
https://dev-sec.io/baselines/ https://dev-sec.io/baselines/ has executable implementations of CIS and other guides

willfarrell 4y ago

OWASP has everything you need; SAMM for policies and procedures https://owasp.org/www-project-samm/ https://owasp.org/www-project-samm/ ASVS for your application https://owasp.org/www-project-application-security-verification-standard/ https://owasp.org/www-project-application-security-verificat...

Amedeemus 4y ago

I do not know of a go-to checklist but as I work in the industry, I hope I can provide some tips from experience. Any service that is needed for the day-to-day working of your business should be properly secured. You mention DNSSEC but it starts with the user accounts that are used to log in to your registrar, hosting provider, payment provider, any SaaS... Generate unique, strong passwords for every business related service. Use a password vault like keepass or a service like 1password for secure storage and ease of use. Multi-factor everything you can, and prefer to use an app or physical token over SMS-based multifactor. I have recommended Twilio Authy a lot due to the multi-device support and google authenticator compatibility. Use DNSSEC for your domain(s), enable SPF, DKIM and DMARC for your mail, set up TLS for your website(s). Depending your needs, cloudflare has some great options for the latter. Security of the endpoints and endusers greatly depends on wether your employees BYOD, what the network looks like and most of all, what you are protecting. I recommend to search for some public "acceptable use policy" or "security policy" documents, especially in the context of ISO27001 and create an own policy based on that, depending on your needs and environment. Even better than policy is proper training for employees on security hygiene, how to avoid phishing and if relevant, secure development. Ceate an open environment for employees to report potential issues or mistakes. Regarding secure development, OWASP is a great resource for anything application security.

tptacek 4y ago
You're recommending this startup do DNSSEC. Can you rattle off some pre-acquisition startups of any note that have DNSSEC-signed their domains? Slack, for instance, is DNSSEC-signed (signing infamously took them off the Internet for the better part of a day) --- because Salesforce, their acquirer, required it; they did the same to Heroku (which also suffered a DNS outage). My point is not so much to litigate DNSSEC itself (although I'll do that) as it is to establish the ground truth that DNSSEC-signing is not a norm among tech companies. It would be a particularly weird bit of ops overhead for a young startup to invest in. If you'd like some tips on how to quickly test whether a startup (or a large list of them) have signed their domains, I'm happy to help.
- Amedeemus 4y ago

paulschreiber 4y ago

Mandatory Yubikeys should be on your list.

dogman144 4y ago

this stage security program needs to make technical security decisions that have large risk management payoffs versus the effort involved. You also have to understand the accepted risks are huge, and you have to focus on risks that span infra, the enterprise, endpoints, and GRC. A narrow technical focus won’t help much. Outside of basic netsec for your app and “corporate network” (creatively defined for a remote startup), it’s worth focusing on decisions that do initial security hygiene that long term really helps but is hard to fix retroactively, and once in place it’s easier to build the exotic controls on top of. You should also not forget basic GRC capabilities, as a bulk of the “doing security” tasks can easily turn into passing vendor audits and RFPs because sales is big for a startup, so having a bank of security policies complete way ahead of time and knowing the way around frameworks like CIS or NIST CSF will save you a lot of work during a sales-stress period. So, in practice, I think getting these done early naturally leads to good decisions and a decent security program to start. - corporate IT: > seriously, make a large and vocal push to get off of personal computers and on to work laptops. Its worth burning some of your security capital for. All of the follow-on work you’ll do for security, to include sales support for the startup (so, you can tie this decision to revenue) gets undermined security-technically and passing audit-ally via work on personal computers. > password manager, or can get by for a while with in-browser password managers vs LastPass > secrets management: very early on, get a firm handle where the passwords/keys to production and service accounts are, store them in a shareable way (AWS secrets manager or shared LastPass), and don’t budge on this. They will too easily (and probably will anyway) end up all over developer computers and note apps. Eventually one will leak this way. By having a work computer, easier to guarantee safety around this loose secrets manager. By having them stored how I said, easy to find and rotate when they leak. > have 2Fa/MFA setup by default from the get go. Don’t make compromises on this > MDM/EDR: start trying to move towards this, but work computers are worth getting deployed prior to pushing for MDM. MDM or anti-virus or preferable EDR will show up as a requirement very soon via sales or audits. EDR can be surprisingly cheap for a small fleet of computers, so I’d look there and skip AV and table MDM. Also, these tools will generate alerts, so you’ll have to have a process in place to respond to the alerts. - Developer productivity > get the enterprise GitHub hardened very early on - know where the audit logs are, turn on alerts that GH has for free for compromised dependencies, and have a plan for API keys ending up in GH, yours or personal ones accidentally pushed to. Both will happen. > get a handle on what IDE extensions are installed, and have a firm line on what is not safe to install, and get a senior eng leader to verify and support this decision. Stuff like a random extension to connect and quickly test a prod DB via your IDE suddenly leads to a random malicious extension having your prod DB secrets and connection string. It’s not worth pursuing white/blacklists really, but it’s worth getting a list of really unsafe library types to use and make sure everyone knows why. - AWS > heavily support any impulse in the company to use IaC - cloudformation, terrsrorm, etc. this will get a lot of secure-by-default capabilities in place. > turn on guardduty across all accounts and start watching. I’d stay away from securityhub as it generates a lot of noise and it’s not worth knowing about until you have the means to fix it and other stuff is taken care of in this list. > build your cloud accounts under an AWS Organization or equivalent. If accounts start under an Org, it’s much easier to build and enforce blanket configs/tooling across all of them, which is needed for security. - incident response > build a shell plan for handling incidents. It’ll help everyone, to include non-security incidents like prod crashing. It’ll also save your butt in a security incident. What matters in them is good documentation and good processes, because if/when a security incident happens, being able to answer what you did and why/when is key as all that data surfaces to legal and/or media comms eventually. - compliance/GRC: > try to get a sales RFP or vendor audit doc and look what they ask for in security evals. Your sales team may totally be BS’ing these answers currently, forewarning. Figure out what’s asked, prepare those documents. - further ideas > where do I find someone to do this: Finding sec eng to take all this on could be hard. This is like a CISO in a box with a fraction or none of the usual funding and headcount. You could then hire a non-technical security lead, but that could turn into an advice/doom machine who isn’t helping fix tech. Sec eng or VP security, either way the salaries are high - $145k base and way up. A sec analyst, who is cheaper, won’t help at this point. So, my advice is pay up for a sec eng who is strong on infra, or pair a security-conscious IT and/or a security conscious devops/infra lead with a comp sci-ish college student with a cloud cert looking to break into security engineering. They’ll get their break, you’ll get someone who knows tech/security but won’t cost a ton and will take a job like this to get the resume bullet (security engineering is hard to break into), and you’ll have someone watching all this and a strong IT and infra eng to help guide them. > I want a framework to follow still: CIS benchmark or better NIST cybersecurity framework. I’d go for the latter. Focusing on CIS or similar can lead to a narrow IT security focus that doesn’t help with actually building a security program, which is what the startup needs. Edit - other advice ITT like leveraging SSO/Gsuite heavily and IAM roles over secrets are really sound.

zach_garwood 4y ago

My former employer, Havoc Shield, is a service to helps small businesses and startups establish a basic security posture: https://havocshield.com/ https://havocshield.com/

cols 4y ago

For application development, the SANS Web App Security Checklist is good: https://www.sans.org/cloud-security/securing-web-application-technologies/ https://www.sans.org/cloud-security/securing-web-application...

belter 4y ago

If you use Cloud, look first, at the best practices resources available from your Cloud provider.

tptacek 4y ago

Your startup should absolutely not be doing DNSSEC; virtually nobody does this, most especially at successful startups with security teams. This is a good example of why a good checklist like this would be useful; I wish I had one to offer.

cweagans 4y ago

Resources I know of that may be of interest: https://github.com/strongdm/comply https://github.com/strongdm/comply https://www.security4startups.com/ https://www.security4startups.com/

mattpallissard 4y ago

Shameless plug. I'm an independent consultant that can help guide infrastructure and devops decisions in early stage start ups. I've spent a lot of time in highly regulated industries. Feel free to reach out with any questions. contact at pallissard dot net.

deleted 4y ago

[deleted]

patrakov 4y ago

Let me share my (unpopular) opinion: whatever minimum mandated by the applicable laws, and nothing else. If you are not a bank, and don't have EU customers, it could as well be an empty checklist. If you need anything more, you are not a startup. Well, if you disagree, let me add one item to your checklist: know when to stop expanding it. Rationale: I have seen enough organizations with the checklist-based approach to security. In all of them, it had nothing to do with actual security, but with convincing customers that the organization is safe to deal with - even if it is in fact false. People responsible for filling in such questionnaires often had an outdated vision of the practices of the company. Also, once you allow any checklist in, or hire any so-called cybersecurity expert who is actually a checkbox-ticking expert, you will be under constant pressure to strengthen this "security posture" more and more, way beyond reasonable. Hypothetical example: this expert decides that you have to comply with Cyber Essentials, and one of the requirements is to install, on each laptop and desktop, an antivirus that can live-check all of the web pages loaded in browsers. But no such desktop-ready thing exists for Linux, and this expert will tell you to stop using Linux on desktops, thus leading to mass-resignation of developers. While the proper solution would have been "don't deal with the UK government".

hkgjjgjfjfjfjf 4y ago

archi42 4y ago

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.

_tk_ 4y ago

Giving security advice in a format like this is always a bit weird. You will never catch all interesting bits much less all the edge cases. On top of that Thomas Ptacek is watching your every move. As already noted, a tailored list for startups doesn't really exist. IMO, there are two approaches when it comes to establishing security in a Startup. You can either go the standard route or the checklist route. 1. Standard route: You hire a consultant, decide on a standard (preferably ISO27k) and go implementing. Costs a lot of money, takes a lot of time/energy, you will be happy about it in the future, if your company is not broke by then. The German Federal Office for Information Security has adapted the ISO27001 standard in the past and created the so called Core Protection methodology. You can find the details here: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Grundschutz/International/bsi-standard-2002_en_pdf.pdf?__blob=publicationFile&v=2 https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Grundsch... It's a nice compromise between adherence to the standard and pragmatism. As a Startup you basically want to protect two things: your IP and availability of your product. The core protection method allows you to specify a very narrow scope that you want to protect and helps you to develop protection requirements. 2. The checklist route: If standards are not your thing, I would advise you to take a look at CISA's "Cyber Essentials" checklist for Small and Midsize Businesses. If you have 90% of these things implemented - which should be very easy for a startup - you will have a better security posture than 90% of all other companies out there (if not more). https://www.cisa.gov/cyber-essentials https://www.cisa.gov/cyber-essentials

baxtr 4y ago
> As a Startup you basically want to protect two things: your IP and availability of your product. On what basis do you make this claim? I’m working in cyber and see the damage side in large companies. IP is never a thing. It’s mostly service / production availability and, with companies doing business in the US, data breaches (loss of PII).
- bornfreddy 4y ago
  Also missing, from the top of my head: your customers' data, company reputation, trade secrets,...

fouadmatin 4y ago

We wrote up a starting five on our blog at Indent: https://indent.com/blog/security-for-startups-the-starting-five https://indent.com/blog/security-for-startups-the-starting-f... 1. Create a security policy — decide what does/doesn't matter 2. Train employees on security — just do the basic stuff, but all the time (strong passwords, 2FA) 3. Implement security measures — for what matters, take security very seriously 4. Use single sign-on — whether it's Google SSO/Okta/etc, you'll thank yourself later 5. Grant access on-demand — people generally don't need permanent access to sensitive systems, set up groups and grant people time-bounded roles

coleca 4y ago

In addition to the advice already commented, if you are using AWS I'd recommend checking out our recently released AWS Startup Security Baseline Prescriptive Guidance: https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-startup-security-baseline/welcome.html https://docs.aws.amazon.com/prescriptive-guidance/latest/aws... This is not a comprehensive checklist per se, but a minimum set of security controls to implement to help secure your AWS account and workloads running on AWS within your account.

deleted 4y ago

[deleted]

mikewarot 4y ago

If you're building a product, consider using capability based security.[1] A capability is an access token to a resource, and NOT a user account. Think of it as a $10 bill. If you pull a $10 capability from your wallet, you can't lose $1000 by accident, no matter how badly things go. Flickr makes it possible to give out a guest pass for photos, for example.[2] The nice thing about a guest pass is you can revoke it at any time. [1] - https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security [2] - https://www.flickrhelp.com/hc/en-us/articles/4404069601172-Create-or-delete-temporary-Guest-Passes-in-Flickr https://www.flickrhelp.com/hc/en-us/articles/4404069601172-C...

nokya 4y ago

By just looking at the vast variety of answers in this thread, I think we have a telltale sign of the magnitude of the problem, and the state of denial in which society has evolved. Whether a startup, a small company or a large corporation, there is at least one IT security standard in each developed country, if not an international standard (e.g., ISO27002 , NIST cybersecurity, etc.). Their role is exactly what they are called for: they tell whoever owns an IT system what should be done to protect it. Unless you're an academic doing research, or you have personally reached the limits of a standard in your organization, there is no reason to look elsewhere. Pull the standard from your country, or pull the ISO27002, and start working on your spreadsheet and assigning tasks :)

tptacek 4y ago
The idea that national security standards are the actual blueprint for running a security practice at a startup is risible.

comprambler 4y ago

Read the entire thread and didn’t see the obvious: #1. Living Asset Inventory (constantly updated automatically) #2. Intelligence on these Assets (can be mdm, but at least reporting of sysinfo, os update version, security version) #3. Automatic patching of both security software and os version. #4. Centralized identity management (Azure AD, other SAML options) with security intelligence builtin.

unixsheikh 4y ago

I am sorry, but if you need someone else to provide you with a list like that, you should NOT be doing this. It is the wrong approach on so many levels.

faizshah 4y ago
Maybe I should clarify why. I am a full stack engineer and I am familiar with the basic AppSec stuff you need to launch a service at a FAANG company. However I am not familiar with the basic IT Security stuff you should setup when forming a new company. When I was researching what I should setup for IT security the documentation began referencing things like DMARC, DNSSEC, DKIM etc. and I realized I don’t know what is the basic level of security I should setup. So I just want to know what is the basic security stuff an early stage company should setup before hiring their first security engineer. The answer to this question can’t be “you should NOT be doing this” because you should still need security even before your first security hire or before you can afford a security consultant.

Mandatum 4y ago

2FA is fine. Don't bother with VPN's if you're SaaS-based. Just take the zero-trust route with mandatory MFA everywhere, invest in Yubikeys for all employees and set up a SIEM box to ingress audit logs from your various systems. Setting up an Elastic box for this should be relatively straightforward. For many people it's easier to keep SIEM locally hosted (pulling data, no external access) and then periodically push encrypted backups offsite). You'll probably end up setting up business metrics monitoring from this eventually too, at least in the early days before you start the "data lake" approach. DNSSEC is a waste of time right now.

_8j50 4y ago

Others mention important things but go nowhere near as far as they should. I can list dozens of high level things you should have on that list, but I think the most important decision is at what point will you hire a dedicated career-security person? The earlier the better. You can have protected branches, pubkey auth everywhere with yubikeys and macs everywhere it all helps reduce noise but security architecture ensures there are no cracks in your defenses. These checklist solutions can do more harm than good by leaving you with the impression that you have a better security-posture and risk appettite than you actually do leading you to make catastrophic decisions. IT/OPs/Engineering folks who know enough security to be dangerous would say things like "but _____ defensive measure is there,that wouldn't work" or "if they got past all this then we have bigger issues anyways" and be dangerously wrong. 2FA with yubi? Cookie theft is now popular. SSH pubkey on a mac? Commodity multiplatform stealers in Rust and Golang of course are a thing and they include stealing private keys and sensitive files as a feature. MDM doesn't protect you against malware and SSO while still should be implemented makes cookie theft one working attack away from pwning all things the user has access to. Boring old things like segmentation, (good)logging and proactive monitoring (probably MSP for you at the start) are still top of the "list" and despite what pop-security personalities have you believe, not only do you need AV but you need a cross-platform good EDR as soon as possible as well as corporate VPNs and while gsuite is popular with startups, O365 has better security and DLP. I could go on but my point is you at least need a consultant at the begining and have a solid plan on when you will hire a proper security pro to architect things and make all the devs and engineers do things they disagree with passionately leading some to even leave lol.

tptacek 4y ago
O365 and DLP are absolutely not startup best practices. Almost nobody uses either. As I've noted elsewhere on the thread, the norm among startups is to make a first security hire somewhere between engineer #20 and #40. Pentesters usually get brought in after PMF, sometime around the "first version" of the product the startup settles on.
- _8j50 4y ago
  "Almost nobody uses either." I am very aware, I noted that in my comment. Are you saying O365 and AIP are inferior than gsuite, if so I would like to hear why, I don't favor either I just haven't seen why. DLP is absolutley a foundational security practice, especially for a startup because they usually have some "secret sauce" and all it takes is one employee leaking that and most people that leak/sell-out just print or take the document with them, a starup maybe drowning in VC money but it all comes down crashing the moment you someone else does it better. As far as the security hire and pentesters, I don't particulary mind the norm so long as you made that decision and planned on it from the start. Also on O365, if you're a mac shop I still say it's better but for windows shops (as rare as that is at a startup) you must use AAD and it solves a lot of problems out of the box when you marry it with O365 and you don't have to worry about google banning you on a whim and crashing your business. I am all for best practices but those are different than monkey-see-moneky-do copying without critically reasoning and defining why that decision is best.

more_corn 4y ago

Require disk encryption and screen lock. Deploy SSO everywhere you can. Provide a password manager. No passwords in slack. If they show up they have to be rotated immediately. Create a simple security policy (and password policy) to let people know expectations. Create an onboarding and off boarding checklist. Create a BYOD policy (if people choose to have work coms on their phone) Require phone password, encryption and find my device. Prohibit password reuse. Buy people yubikes if they want em. Encourage 2fa Rotate credentials at most annually. Create a culture of blameless postmortems so people feel comfortable raising concerns early. Set up your cloud accounts with SSO. Secure your CI/CD system. It usually has the keys to the castle. Deploy or enable cred-scan, dep-scan, sast-scan in CI/CD Don’t allow public items in S3 buckets unless the bucket is explicitly public.

captn3m0 4y ago

- https://s3-eu-west-1.amazonaws.com/sqreen-assets/whitepapers/SaaS+CTO+Security+Checklist.pdf https://s3-eu-west-1.amazonaws.com/sqreen-assets/whitepapers... - https://www.goldfiglabs.com/guide/saas-cto-security-checklist/ https://www.goldfiglabs.com/guide/saas-cto-security-checklis...

westurner 4y ago

From https://news.ycombinator.com/item?id=30906310 https://news.ycombinator.com/item?id=30906310 : > "The SaaS CTO Security Checklist [Redux]" https://github.com/vikrum/SecurityChecklists https://github.com/vikrum/SecurityChecklists > "The Personal Infosec & Security Checklist" https://www.goldfiglabs.com/guide/personal-infosec-security-checklist/ https://www.goldfiglabs.com/guide/personal-infosec-security-... > "The DevOps Security Checklist Redux" https://www.goldfiglabs.com/guide/devops-security-checklist/ https://www.goldfiglabs.com/guide/devops-security-checklist/