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

There is a lot of advice in this thread that doesn't actually address your circumstances, or is just bad.

I recommend reading: 1. https://devd.me/log/posts/startup-security/ - relatively short and prescriptive 2. http://scrty.io/ - start with http://scrty.io/foundations + https://medium.com/starting-up-security/you-dont-need-a-chie... + https://medium.com/starting-up-security/starting-up-security...

First document every "near-miss" or risk you find.

Go make the exact same argument to your CEO, $XX million start-up flatlines with a single slip up.

Make it as easy as possible for your CEO to go to the company board, repeat the argument, and make an ask to shareholders for a loan to hire a security expert. Your self taught experience will help in finding the right person.

Befriend the new security person and learn everything they have to share.

1. Start thinking in terms of accepted risk. What is accepted risk? It's risk that you, evryone at the company, and its stakeholders are willing to accept failure because of.

For example, going out to buy milk at 3am inabrough neighborhood might not be accepted risk - the risk vs value is off.

To buy diapers in a 3am emergency? Yup.

To drive a car on the motorway is hella dangerous. Super risky when you think about it. But you can't not do it. (presumably/ So what do you do? You check your brakes, indicators, steering, etc bfore taking off. Get it to periodical checkups.

Then if it fails, you did your part, you did what you could. It's accepted risk.

It's at the point when you go "well, if I'm not gonna do that then I might as well stay in bed all day". You could get hit by a meteor going out your door you know.

If you declare something an accepted risk, accept no blame for it failing. it was accepted risk. not your falt that it happened, but it was you who decided that its accepted risk. It was your decision (but inform everyone). If you dont want to stand for the decision, defer it, or maybe you're in the wrong spot.

2. Then there is the concept of unknown unknowns. Talk to everybody in the company, make sure that noone sits on a domain or problem area you are totally unaware of. Survey/canvas the landscape, and report back to your superiors. Then drill down wherever necessary

Having built security programs at multiple companies, I can tell you it's not something as easy as one person cramming content for a day and then implementing with ease.

It's also unclear what outcome the business is looking for. If I had to guess, a big contract requires "security" and management wants to check that box the cheapest way possible.

If it's about first steps to improving security posture, and assuming you have a SAAS offering - then the first thing I'd do is start a bug bounty with hackerone or bugcrowd. It's the quickest way to both establish a feedback loop on security state, while also introducing a forcing function to prioritize fixing defects.

I wouldn't call myself a security person, but I do have a fair amount of experience implementing things downstream of the security organization, and sometimes outside of that context.

I think a reasonable place to start is something like the NIST Cybersecurity standard. In my limited experience, the NIST Cybersecurity standard deals more with _risk_ than it does with discrete technical guidance, but from their fairly comprehensive risk framework you can start to frame the technical problems in your environment through this risk lens.

Additionally, I'll recommend something that's maybe wrong (security folks jump in as needed), but I typically try to work outwards in when securing an environment. In the case you've got a web app or something, reduce the attack surface of the system externally as much as possible (closing ports/IP filtering on management ports/etc) and then work your way inwards.

Put another way, try to focus on bang for you buck until you have a dedicated a team. An obscure XSS that requires a strong working knowledge of the system is _very bad_, but if you also have port 22/SSH open to the world with a 5 char password, I'd figure that one out first. That's obviously an extreme example, but I think you get the point.

If you can get a budget for a security consultant/auditor to help put the policies and frameworks together, including conducting a baseline audit and identifying gaps, that would be a start.

While IT aspects are a big part of the security (patches, vuln assessments, access control, environment separation etc.,) there are quite a few policy, documentation, review and controls and people aspects etc., that are important in any infosec framework.

I would hire a security consulting firm to do the work for you. This is not the kind of thing you can learn overnight, or even in a short to medium timeframe. Countless startups have experienced security teams and yet were still breached - just do a quick google search. It's unrealistic to think an inexperienced engineer can do better.

You might take a look at the OWASP Software Assurance Maturity Model (SAMM) for guidance on prescriptive activities you can take to improve your security posture over time. [1] There is a toolkit available that you can use to evaluate your team(s) and establish a phased roadmap. [2]

The data you gather from the assessment can help you prioritize activities for your team/org as well as provide metrics for your leadership.

You can also resource your activities with some of the OSS available from OWASP as well as join any of the projects/discussions to learn more. [3] Feel free to DM for more.

1. https://owaspsamm.org/ 2. https://owaspsamm.org/assessment/ 3. https://owasp.org/

Look for VCSO (virtual security officer), an auditor, or start your SOC2 process. You'll get guidance from day 1 where the immediate holes are.

Also bear in mind that the audit that's coming is designed to help you, not break or hack you. It's a positive step to being more secure.

Congratulations!

>>[...] now I'm "responsible", of the cybersecurity of a 30 people startup/scale-up, on top of actually building/maintaining features.

>>[...] we're going to raise more money soon, but for now I'm +/- the only guy with cybersecurity experience.

>>We have huge clients, a big leak/hack would be [...] disastrous for a lot of people.

You've just outlined the business justification for you to be the defacto interim full-time CSO and drop/transition feature development duties "until the next round is raised, Soon (TM)". Have this (potentially difficult) conversation with your CEO today to help set up both yourself and the company for success, not failure.

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.

I would start with asking the auditors what they look for. They should be able to give you at least a broad checklist. They will probably try to hack into you if it is a red team.

Your huge customers should have a security standard for vendors. It is difficult to even start integrating with them if you don't pass some kind of assessment from them. If those were waived then you must have a hot product. You can also look at the standards for your customers and use those as a basis.

How do you deliver your product? If it is web based you have technical attack vectors. Do you have a safe and sanitized software delivery pipeline? A lot of web based SaaS pull from NPM, pip, etc... all of this software should be reviewed technically.

Where and how is customer data stored and transmitted. Is it encrypted at rest and in transit? Who controls passwords, are they hashed or is the it an Oauth integration?

Do you have internal controls (firewall, audit capability, permissions, separation of concerns, employee trainings, antivirus, backup procedures, ransomware procedures, disaster recovery policy) etc...

Good Luck!

Just quit. Or ask for a significant salary raise (something worth all the hassle you're gonna deal with). If something goes wrong (now, or in the future as a consequence of the actions you take now) then you'll be the responsible one... and when it comes to security, well, that's not fun.

There's some really great advice in the responses, much of it dealing with work practices, some with specific details, some with a more general perspective, usually oriented around risk, and economics. There are also comments relating to careers and career movement.

When I read this, I'm left with an overriding sense of panic, of concern, and of course, a willingness to do their best to save what sounds like an abysmal but unfortunately all-too-common situation.

I assume that almost nothing is documented, and any documentation is not up-to-date. I also assume that there are pockets of knowledge hidden within individuals or small teams, and that this knowledge is unlikely to be made known at any time when it could be useful. I have to also assume that, based on some similar-sounding experiences, management and finance feel they have already spent the associated budgets on dealing with developer delays and they aren't proactively engaged on the realities of security, despite daily news alerting everyone to the significant problems that exist, for developers, for companies and for end-users.

Don't do this alone. You can't, especially with your lack of experience. Offer to form a small, tight task-force to review at the broadest level, the areas of concern. Don't have a scale of priorities; it's either a problem, or it isn't currently a problem. This team isn't a place for beliefs and faith of approach; focus on reality and data. If you don't have data, you have a problem.

Make some simple statements on how to approach the problems. And you could consider some trivial steps like using Cloudflare to gain some control over basic website security issues.

And write down everything, ensuring clarity of organisation and structure. Make sure the task-force team do the same.

Identify sources of support and help. Reach out and don't delay.

Most importantly, your new role is to discover and manage the bad news. Good news has no place here...

And I would also take some personal time to review exit strategies, and an awareness of when you should need to make such a move...

You might consider starting with something like the CIS Controls Framework: https://www.cisecurity.org/controls/cis-controls-list.

I have security experience mainly in big companies, but this is the approach that I will take: start to prioritize the needs. I suggest to use a threat model methodology (STRIDE or PASTA are fine) to understand what are the main assets and the risks and start protecting them. When you have identified the key assets and the risks related to them, you can start thinking about security controls (not only technical, also from an organization perspective) to reduce them or accept them in agreement with the management and stakeholders.

Starting from scratch can be difficult, because you need to setup processes and policy, maybe you can ask help for a consultant company in the first steps.

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.

HackerOne and 2FA everything is biggest bang for the buck imho. A sensible approach to SOC 2 certification (the real security part, not the checkbox part) is good to fill in gaps and think about overall strategies.

I used to work at havocshield.com, which is sort of a walkthru service for organizational security. It's good for small companies in your situation, without any dedicated security staff.

Ping me, I’m the cofounder of scanrepeat.com, happy to chat

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.