this stage security program needs to make technical security decisions that have large risk management payoffs versus the effort involved. You also have to unde

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.