Abonnieren Sie unseren NEWSLETTER

Global Security Mag: Stellen Sie bitte kurz ihr Unternehmen vor

Ich habe meine beiden Mitgründer Kennedy und Ihsan vor etwa 6 Jahren am Hasso-Plattner-Institut kennengelernt, die beiden waren im Bereich Cybersecurity, ich im Design Thinking. Vor 2 Jahren haben wir etwas im akademischen Bereich gefunden, das sich auf die Wirklichkeit übertragen lässt. Es geht dabei um Compliance-Regularien und das, was Hacker im Public-Cloud-Bereich tun. Mitigant ist entstanden, um diese Lücke etwas zu schließen. Wir haben ausgelotet, ob es für unsere Idee einen Markt gibt, wir haben uns mit Firmen darüber unterhalten, wie sie mit Sicherheit klarkommen und ob das für sie ein einfaches Thema ist. Die Antwort war klar ‚nein‘. Sicherheitspersonal ist kaum vorhanden. Das Betreiben von Cloud-Services über aws oder Microsoft Azure geht noch, DevOps-Personal findet man. Securitypersonal hingegen ist sehr teuer und kaum zu finden. Und da setzen wir an. Wir haben uns noch Thomas Fricke, als Experten für Kubernetes-Security ins Boot geholt und letztes Jahr beschlossen, eine Firma zu gründen. Nach einer Investitionsrunde haben wir dann unser Produkt entwickelt. Unser Team ist sehr breit und divers aufgestellt. Kennedy kommt aus Nigeria, Ihsan aus Indonesien, wir haben viele sehr gute Programmierer aus Nigeria, einen VX-Designer aus Indonesien und einen aus der Ukraine. Fachkräftemangel ist natürlich trotzdem ein Thema. Wir suchen gerade deutschlandweit, präferiert im Berliner Raum. Dennoch sind wir von Anfang des Jahres von 0-13 Mitarbeiter gewachsen.

GSM: Was stellen Sie auf der it-sa vor?

Unser Produkt folgt dem Prinzip Detect, Secure, verify.
ZumThema Detect: Wir scannen einmal pro Tag die Infrastruktur und machen noch 2 Mal einen Snapshot. Warum machen wir das? Beim Thema Cloud ist ja eine der Herausforderungen die Sicherheit, klar, aber auch der Drift. Eine Cloud kann ja je nach Bedarf kleiner oder größer werden. Unsere Drift-Analyse basiert auf einem Hack, der vor ein paar Jahren gegen Tesla gelaufen ist. Da ist ein Hacker in einen Kubernetes-Cluster vorgedrungen und hat dort Bitcoinmining gemacht. Für mittelständische Unternehmen, die wir anvisieren, kann das der Unterschied zwischen einer monatlichen Zahlung von 5.000 € oder 50.000 € sein. Von daher ist die Driftanalyse wichtig, um die Infrastruktur abzubilden.

Im Secure-Bereich ist es so, dass wir Standards anwenden können, d.h. wir können anzeigen, wie die Infrastruktur im Bezug auf einen Standard aussieht. Wir machen in dem Moment keinen Audit, sondern wir schauen uns an, wie die Infrastruktur aussieht und helfen den Unternehmen im Standard zu bleiben. Sonst gibt es einmal im Jahr die Testung und dann fangen alle 4 Wochen vorher an zu überlegen: Wo sind meine Daten?

Der letzte Punkt ist Verify. Das ist das Security Chaos Engineering bei uns. Da haben wir die Möglichkeit, die Infrastruktur anzugreifen. Warum ist das so wichtig? Viele Hacks passieren, weil ein Unternehmen denkt, es hätte alle Einstellungen gemacht. Aber erst wenn der Hacker dich gehackt hat, weißt du, welche du nicht gemacht hast. Normalerweise macht man Pentests, das ist auch gut, aber der hält für 2-3 Wochen, und dann ist das schon wieder überholt. Wir haben die Möglichkeit, in einer Testumgebung z.B. eine Ransomware-Attacke zu machen und eine Übersicht zu liefern. Mithilfe der Erkenntnisse kann dann eine Cloud resilienter und abgehärteter erzeugt werden.

Das sind die 3 Komponenten: Detect, secure, verify. Damit geben wir unseren Kunden die Möglichkeit ihre Cloud-Infrastruktur sicherheitstechnisch abzuhärten.

GSM: Was sind die Stärken Ihrer Software?

Wir suchen ja eher kleinere Kunden. Die gucken erstmal, was gibt mir Amazon. Amazon hat den Security-Hub. Vom Feature-Set her sind wir ähnlich. Beim Security-Hub brauche ich für die Einrichtung allerdings 2-3 Stunden und muss mehrere Services einklinken. Auch bekomme ich nicht so einfach eine gute Übersicht über meine Infrastruktur. Bei unserem Produkt brauche ich mit ein bisschen Hintergrundwissen 10 Minuten. In unserem Dashboard stecken 2 Jahre Arbeit, es ist sehr einfach aufgebaut und einfach zu verstehen. Wenn ich mir einen Fehler anschaue, bekomme ich sofort eine Übersicht. Die Art des Fehlers, eine Anweisung, wie ich Abhilfe schaffen kann, und das Command. Wir haben lediglich Leserechte beim Kunden, keine Schreibrechte. Wir verändern nichts. Bei Amazon kriegt man diese einfache Übersicht nicht so einfach, die Drift-Analyse gibt es nicht und die Möglichkeit anzugreifen auch nicht.

Technisch gesehen hat Amazon eine Schnittstelle, die sich Security Inspector nennt und auf Third Party Software wie uns ausgerichtet ist. Da knüpfen wir an und fragen den S3 ‚Bist du öffentlich?‘ Der sagt: ‚Ja ich bin öffentlich.‘ Dann gucken wir und stellen fest, dass die Standards sagen, du solltest diesen nicht öffentlich einrichten. So wird die Compliance anhand der entsprechenden Standards geprüft. Also bei Amazon ist z.B. ist die interne well-architected-Framework ganz wichtig, für die meisten Fintechs wäre es z.B. PCI-DSS, also der Kreditkartenstandard. Unsere Übersicht zeigt dann zum Beispiel 4 Controls, also 4 Services, die gescheitert sind, davon zwei unterschiedliche S3. Also eine relativ schnelle Übersicht. Wir wollen mit unserer Software vor allem Tech Leads, DevOps und CISOs erreichen.

GSM: Was ist Ihre Message an unsere Leser?

Sicherheit ist nichts, was ich einmal im Jahr mache, sondern etwas, das ich kontinuierlich betreiben muss und auf das ich achten muss. Das heißt nicht, dass ich mich jeden Tag damit beschäftigen muss, aber ich muss Zeit dafür finden. Wenn das Kind schon in den Brunnen gefallen ist, kann man natürlich auch reagieren und reagiert dann meist schneller aber dann geht es auch schon um einen anderen Schmerz.