Wie balanciert ein SaaS-Startup-CTO Entwicklungsgeschwindigkeit und Sicherheit?

Erkenntnisse aus früheren SaaS-Unternehmen

In einem typischen SaaS-Startup steht das Entwicklerteam unter hohem Druck, neue Funktionen zu liefern. Man hat in der Regel besser finanzierte Wettbewerber, das Vertriebsteam, das nach einer letzten Funktion fragt, um den Deal abzuschließen, und das Kundensupport-Team, das einen Bugfix anfordert. Es kann schwierig sein, Sicherheit zu priorisieren, es sei denn, ein größerer Unternehmenskunde fordert es oder Ihr Vorstand setzt es von oben durch.

In den meisten Startups steht Ihnen möglicherweise keine vollständige Palette an Tech-Profilen zur Verfügung: Sie haben vielleicht noch keinen Vollzeit-Produktmanager, Sie haben wahrscheinlich keinen Vollzeit-Sicherheitschef in Ihrem Entwicklungsteam. Ein Entwicklungsteam, das unter Lieferdruck steht, wird gezwungen sein, viele Abstriche zu machen, selbst wenn es um Sicherheit geht.

Ich war CTO von drei SaaS-Startups in der Frühphase. (Teamleader, Officient & Futureproofed) Im Folgenden habe ich meine Erkenntnisse aus diesen früheren Erfahrungen mit SaaS-Unternehmen dargelegt.

Vermeiden Sie es, das Rad neu zu erfinden

Ein gutes Beispiel: Bauen Sie kein Login-System mit Passwörtern. Ja, Sie könnten es in wenigen Tagen erstellen, aber die Kosten für die Wartung und das Hinzufügen erweiterter Schutzfunktionen in der Zukunft wären sehr hoch. Erwägen Sie die Verwendung eines Logins über Single Sign-On wie Gmail oder nutzen Sie einen Dienst wie Auth0.com. Sie erhalten nicht nur ein reibungsloseres, funktionsreicheres Login-Erlebnis, sondern müssen sich auch keine Sorgen mehr um eine ganze Klasse von Login-bezogenen Sicherheitsaspekten machen (Brute-Forcing, geleakte Benutzerdaten in Drittanbieterdiensten, Vermeidung und Erkennung von Account-Takeover-Angriffen, Validierung von E-Mail-Adressen, Logging...).

Letztendlich, wenn Sie den richtigen Anbieter wählen, reduzieren Sie nicht nur Ihre Angriffsfläche, sondern gewinnen auch Zeit, die für wertvollere Funktionen aufgewendet werden kann.

Weitere großartige Beispiele, die Ihnen Wochen oder Monate sparen könnten, sind:

• Speichern Sie keine Kreditkartendaten, sondern nutzen Sie Dienste wie Stripe, Mollie oder Chargebee
• Betreiben Sie komplexe Software wie MySQL, PostgreSQL oder ElasticSearch nicht selbst. Nutzen Sie Managed Cloud Services wie RDS.
• Bauen Sie keine eigenen Logging-Systeme. Nutzen Sie Systeme wie Sentry oder Papertrail (und protokollieren Sie dort keine sensiblen Daten).
• Betreiben Sie keine eigenen E-Mail- (SMTP-)Server, sondern nutzen Sie einen Managed Service wie Sendgrid oder Mailgun
• Bauen Sie keine WebSocket-Server, nutzen Sie Managed Services wie Pusher.com.
• Bauen Sie kein eigenes Feature-Flagging-System, nutzen Sie einen Dienst wie Launchdarkly.
• Bauen Sie keine eigene Kalenderintegration, nutzen Sie ein Tool wie cronofy.com.
• Beim Erstellen von Integrationen im Allgemeinen sollten Sie nach Unified APIs in diesem Bereich suchen, wie z. B. Apideck.

Investieren Sie etwas Zeit in ein Krisenkommunikations-Setup

Stellen Sie sicher, dass Sie Tools eingerichtet haben, wie z. B. eine Chat-Anwendung, um mit Ihren Kunden zu sprechen, oder besser noch, eine verwaltete Statusseite oder einen Twitter-Account, über den Sie Probleme kommunizieren können. Falls etwas Schlimmes passiert, ist es eine gute Praxis, den Rest Ihres Unternehmens in die Lage zu versetzen, mit Ihren Kunden zu kommunizieren, während Sie sich während einer Krise auf die Behebung des Problems konzentrieren.

Globale Leitplanken hinzufügen

Sie überprüfen wahrscheinlich Pull Requests Ihrer Entwickelnden, großartig! Es ist eine ziemliche Aufgabe, sie auf Wartbarkeit, Performance und Funktionalität zu überprüfen. Haben Sie auch Zeit, sie auf Sicherheit zu überprüfen? Sicherlich können Sie einige Risiken abdecken, aber es ist gut, einige Risiken durch das Hinzufügen von Schutzmechanismen und globaler Konfiguration beiseitezuschieben.

Manchmal hat man Glück und es gibt globale Korrekturen für spezifische Probleme.

• Wenn Sie NodeJS verwenden und sich nicht mit Prototype Pollution auseinandersetzen möchten, sollten Sie den Prototyp einfrieren, um diese Art von Angriffen app-weit zu deaktivieren. Aikido kann automatisch einen Pull Request erstellen, der dies für Sie erledigt.
• Wenn Sie SQL verwenden und Angst vor SQL-Injection-Angriffen haben (was Sie sollten), können Sie eine WAF (wie AWS WAF) oder RASP (wie Datadogs App Security) für app-weiten Schutz verwenden.
• Wenn Sie viele XSS-Angriffe entdecken, können Sie einen Großteil davon wahrscheinlich durch die Einführung einer sehr strengen CSP-Richtlinie im Browser eliminieren.
• Wenn Sie viele ausgehende Anfragen basierend auf Kundeneingaben durchführen, könnten Sie anfällig für SSRF-Angriffe sein. Auch wenn es schwierig sein mag, dies vollständig zu blockieren, können Sie Schäden mindern, indem Sie sicherstellen, dass es nicht zu etwas Schlimmerem führen kann (wie einem IMDSv1-Angriff auf IAM-Anmeldeinformationen in AWS). Aikido überwacht dies standardmäßig in Ihrer AWS Cloud.
• Beim Umgang mit Objektspeichern kann das Vermeiden spezifischer Funktionstypen wie Pickle, XML, (De-)Serialisierung in Java und PHP und stattdessen die Wahl einfacher Speicheroptionen wie JSON viele typische Exploits im Zusammenhang mit unsicherer Deserialisierung verhindern. Aikido überwacht diese Art von Funktionen standardmäßig in Ihrer Codebasis.
• Wenn Sie einen CDN oder Caching-Mechanismen verwenden, nutzen Sie separate Domains für Ihre statischen Assets mit separaten CDN-Konfigurationen, um alle Arten von Cache-Poisoning-Angriffen zu vermeiden (ChatGPT ist kürzlich in diese Falle getappt).

Bilden Sie Ihre Entwickelnde mit diesem einfachen Trick weiter

Es gibt einen einfachen Hack (Wortspiel beabsichtigt), den Sie in Ihren Prozessen implementieren können. Eine schnelle Frage, die Sie dem Dev-Team während der Sprintplanung stellen können:

Wie kann die Funktionalität, die wir entwickeln, gehackt werden? (und wie können wir das verhindern)

Auch wenn das Entwicklerteam nicht jedes potenzielle Missbrauchsszenario antizipieren kann, ist diese Methodik extrem einfach zu skalieren. Es ist ein kleiner zusätzlicher Schritt, der Entwickelnde dazu ermutigt, Sicherheitsaspekte zu prüfen, bevor sie mit der eigentlichen Entwicklungsarbeit beginnen.

Prioritäten für verschiedene Teile Ihrer Codebasis zuweisen

Nicht alles wird ein so großes Ziel für Hacker sein. Schlüsselkomponenten, die sie gerne angreifen, sind:

• Zahlungssysteme, Wallets, Kreditsysteme
• Funktionalität, die sich mit teuren APIs wie SMS, VoIP (z. B. Twilio) verbindet
• Passwort-Reset, Login-Systeme, Benutzereinladungen
• Exportfunktionen wie PDF-, Excel-Exporte, die riskante Operationen ausführen könnten
• Alles, was mit Datei- und Bild-Uploads zu tun hat
• Funktionen, die konzeptbedingt ausgehende Anfragen tätigen, wie z. B. Webhooks
• Jede Art von Funktion, die E-Mails versendet, insbesondere mit personalisierten Inhalten

PS: Aikido kann Ihnen helfen, sich auf die wichtigsten Repositories in Ihrem Startup-Universum zu konzentrieren, indem es jeder Codebasis Risikostufen zuweist.

Vergessen Sie den menschlichen Aspekt nicht.

Als CTO in einem kleinen Startup sind Sie normalerweise auch für die operative Sicherheit zuständig. Stellen Sie Ihrem Team die Mittel zur Verfügung, um ihre Konten zu sichern. Stellen Sie sicher, dass sie Hardware-Yubikeys oder Software-Apps für 2FA verwenden und dies, wenn möglich, durchsetzen. Tools wie Gmail ermöglichen die Durchsetzung dessen. Es ist eine hervorragende erste Verteidigungslinie gegen Phishing-Angriffe.

Es ist schwierig, mit Sicherheitspraktiken auf dem neuesten Stand zu bleiben.

Es ist schwierig, sich über neue Arten von Software-Angriffen zu informieren. Es ist schon schwer genug, Updates für die von Ihnen verwendeten Sprachen (Python, Node, Go,..) oder OS-Patches oder beliebte Exploits in Open-Source-Paketen zu verfolgen. Spezifische Angriffe werden mit der Zeit populärer, daher lohnt es sich, die Trends zu verfolgen. Nachdem Aikido beispielsweise im letzten Jahr einen Anstieg von Subdomain-Takeover-Angriffen festgestellt hatte, führte es ein Subdomain-Takeover-Überwachungstool ein, um dieses Risiko zu verhindern und die Überwachung dieser DNS-Einträge zu automatisieren.

Automatisieren Sie es einfach

In meinen früheren Unternehmen versuchten wir, ein höheres Sicherheitsniveau zu erreichen, indem eine Sicherheitsperson einen Kalender mit wiederkehrenden Sicherheitsaufgaben erstellte. Jedes Quartal eine Zugriffsprüfung für alle Apps durchführen. Alle paar Wochen einen Scan nach geleakten Secrets im Code durchführen, jeden Freitag die CVEs von Open-Source-Paketen bereinigen, gelegentlich einen SAST-Scan durchführen, monatlich die DNS-Einträge auf Subdomain-Takeovers überprüfen,... Die Ergebnisse dieser Aufgaben waren schwer zu triagieren und für Entwickelnde umsetzbar zu machen. Schlimmer noch, als diese Person das Unternehmen verließ, war es für andere schwierig, diese Aufgaben zu übernehmen, da sie viel spezifisches Wissen erforderten.

Hier begann die Idee von Aikido zu wachsen. Wir brauchten eine Lösung, die all das oben Genannte automatisiert, das Rauschen herausfiltert und die Aufgaben Ihren Entwickelnde in Slack oder Jira präsentiert.

Beginnen Sie noch heute mit Aikido, Ihren Code und Ihre Cloud zu scannen. Melden Sie sich hier an und beginnen Sie kostenlos mit dem Scannen.