Ask HN: I'm now responsible of the security of a scaleup, how do I handle this?

Based on my experience in top-down implementation of NIST cybersecurity framework, the holy grail (alongside their 800-37 RMF) is the lesser-known 800-65. Provides guidance on how to fund enterprise cybersecurity programs. The document itself is considered to be phased out, not because it is obsolete, but because government agencies were not up to the task.

SP 800-37 Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy https://csrc.nist.gov/publications/detail/sp/800-37/rev-2/fi...

SP 800-65 Integrating IT Security into the Capital Planning and Investment Control Process https://csrc.nist.gov/publications/detail/sp/800-65/archive/...

It's hard to give specific advice without knowing what your cybersecurity experience is.

But I'd make sure the boss knows going into the audit the company is going to have its ass handed to them. But that's actually a good thing. Having a good pentest/audit will give you an idea of where to start.

If you can get funding, get Nessus and Burp Suite Pro. Burp Suite is best used if you have a good understanding of web app pentesting and can manually do stuff, but the automated scans are pretty decent too. Automated scans will pick up stuff that's usually easy to remediate and will thwart low-effort threats and/or script kiddies.

If you can't get money for Nessus, OpenVAS can work. But if it were me and I couldn't get money for a Burp license, I'd pay for it out of my pocket.

Also take time to understand what the upcoming audit is going to look for. If you understand the controls, you can go look how to implement those controls. And once the audit comes back, the audit should help you prioritize remediation.

Someone suggested a SOC2 audit. Depending on how this audit goes, I think that's a good idea. Or at least try to adhere to the controls within SOC2, if you're not going to get the audit itself.

ITProTv has some good security stuff. I'd review it if you have the time and/or inclination. It's a little basic, but solid basics are necessary.

Security is not first and foremost a technical problem. It is a resource attribution problem. That is the most important thing to understand about security.

It is a resource problem because security is only a cost that is used to hedge against the possibility of future losses which means there is always alignment towards a minimum possible investment in security.

This means a security person's primary purpose is to first estimate the cost of a security breach and then lobby for appropriate resources. Listing out the ways security can fail and associating a cost for each is vastly more important than the technical work of security itself.

You are that minimum investment, so you are the security scapegoat when things go wrong. You need to make sure that responsibility for security failure is always associated with your management because ultimately they control the resources applied to security. If management is not able or willing to hire a security expert who can speak authoritatively on the topic, that is on management, that is not on you.

From a technical perspective:

Security can be divided into ~3 major areas. Corp security, infra security, product security (later on incident response, fraud/abuse, and internal pen testing).

Corp security is sufficiently complicated that it probably needs to be a hat worn by the person administrating employee computers until a person devoted to corporate security (or internal administration) can be hired. The attack surface of corporate networks is too large to be handled by one person. This means whoever manages account creation for corporate e-mail or whoever purchases hardware on behalf of the company for employees needs to be responsible for security of said accounts, that employees computers are reasonably monitored and secure, and that phishing is generally not a fruitful endeavor.

Infra and product security are inter-related enough that one person can wear that hat for a while. Absolutely set up a bug bounty program. Lots of links here seem reasonable for hardening or understanding attacks.

Inventory the valuable things your company has. Customer data? Build signing keys? Encryption keys? Business bank account? Internal communications? Keeping an inventory of the things an attacker would want is first.

After developing your threat model, define your border. What is the ingress and egress to all of your systems. What has a public IP? What services listen externally? What websites does your company have accounts with? This is your attack surface.

Once you have defined what can be taken, how much damage it will cause, and the attack surface you need to secure, you are ready to have a conversation about appropriate investment in security. Then you can worry about hardening/defense and then you can worry about defense in depth.

> Doesn't "CSO" come with potential for personal liability in worst-case scenarios?

Depends on your definition of worse-case scenario, but generally no. Otherwise no one would be dumb enough to take that job.

Personal liability is not impossible of course, here's the recent example that made headlines: https://www.justice.gov/usao-ndca/pr/former-chief-security-o...

But "obstruction of justice" and "misprision of felony" is not something that just happens to you by accident.

Similar situation as you . . . StartUp ScaleUp . . . about 30 people we only had two devs (me and the CTO) when we went through our first security audit.

The firm doing the pen test and audit only had a few recommendations no issues were found.

They said we did way better than most fortune 500 companies they test/audit.

If you're using a popular framework and follow best practices you might do better than you think.