Alexandra Svatikova arbeitet als Informationssicherheitsexpertin bei Odnoklassniki. Vor über 8 Jahren wechselte sie von der Java-Entwicklung zum Testen der Anwendungssicherheit.
Wir haben sie interviewt, wo wir besprochen haben:
- Fällt es Entwicklern schwer, auf Application Analytics umzusteigen?
- Unterschiede in der Leistung des Pentesters, des Reschers und des Analytikers;
- Sicherheitsentwicklungslebenszyklus oder SDLC;
- die Rolle des Menschen bei der Suche nach Schwachstellen;
- Wie sieht es mit der Sicherheitsanalyse in anderen Unternehmen aus?
In diesem Artikel wird es keinen Hardcore geben - Sie können ihm bis zum Heisenbug 2019 in Moskau folgen, wo Alexandra über statische Sicherheitstests spricht. Wir werden am Ende des Beitrags zu ihrem Bericht übergehen, aber vorerst sind wir bei cat willkommen.
Das Anmelden bei Application Security ist nicht so schwierig, wie es sich anhört
"Für wen hast du studiert?" Warum haben Sie sich mit Anwendungssicherheit befasst?
- Ich bin wahrscheinlich kein Vorbild (lacht) . Ich habe als Programmierer studiert und so etwas wie "Software Engineering" ist im Diplom geschrieben. Arbeitete zuerst als mobiler Entwickler und wechselte dann zur Webentwicklung in Java. Nachdem ich einen anderen Job als Java-Programmierer gefunden hatte, stieg ich in das Team ein, das sich mit Anwendungssicherheit befasst - und den sicherheitsrelevanten Teil der Entwicklung beibehielt. Es gab einen gut organisierten, formulierten Prozess, und sie brauchten Mitarbeiter, die Codeüberprüfungen und statische Analysegeräte durchführten. Dementsprechend suchten sie einen Java-Programmierer und waren bereit, ihm Sicherheit beizubringen. Es schien mir interessant, also blieb ich.
- Was denkst du, wirst du noch lange in dieser Gegend bleiben, oder wird etwas dieser Etappe folgen?
- Ich denke, dass ich für immer bleiben werde, da ich seit 2011 ein Analyst für Anwendungssicherheit bin. Ich habe bereits weniger Entwicklungserfahrung, wie sich herausstellt. Der Programmierer sollte keine Angst vor Routineaufgaben haben, Fehler beheben, und der Sicherheitsspezialist hat eine andere Besonderheit, das zieht mich mehr an.
- Welche zusätzlichen Bereiche im Vergleich zur konventionellen Entwicklung mussten Sie beherrschen?
- Zu Beginn meiner Karriere habe ich getestet. Es bringt Ihr Gehirn in Schwung: Sie sehen das System nicht in Form einer Reihe von Codes, sondern in Form eines Organismus, der auf unterschiedliche Weise beeinflusst werden kann. Tester und Entwickler denken also anders.
Zum Beispiel wurde vor 10-15 Jahren angenommen, dass Tester das System zerstören und den Fehler auf irgendeine Weise finden sollten. Sicherheitsexperten müssen manchmal einen ähnlichen Standpunkt vertreten. Sie müssen also verstehen, wie das System als Ganzes funktioniert.
Einige Entwickler sind auf die Details fixiert: Sie wissen, wie ein Teil des Systems funktioniert, aber sie verstehen nicht, wie alles zusammenwirkt. Zum Beispiel weiß er, wie JS in einem Browser ausgeführt wird, aber der Entwickler weiß nicht, wie dieser Browser weiter funktioniert und kommuniziert mit dem Server, warum dies so angeordnet ist. Der Tester muss aus der Vogelperspektive schauen, um die Zusammenhänge der Komponenten, schwache Änderungen oder Schwachstellen zu beurteilen.
- Und was Technik, zum Beispiel Netzwerk-Stacks, mussten Sie von Grund auf lernen? Wie funktioniert beispielsweise JS, Front, Backing?
- Im Prinzip war ich bereits ein Full-Stack-Entwickler, daher verstehe ich, wie das Backend und das Frontend funktionieren. Sie müssen einen bestimmten Ausblick haben, aber die Vertiefung der Details hängt bereits davon ab, was Sie tun. Dieselben Entwickler und Tester kennen sich je nach Projekt mit bestimmten Systemaspekten aus (z. B. Netzwerkprotokollen) oder kennen sich mit dem Frontend besser aus. Das hängt von den Umständen ab.
- Wie realistisch erscheint es Ihnen, wenn ein abstrakter Full-Stack-Entwickler oder ein Full-Stack-Tester, der sich mit Programmierung, Automatisierung und Test beschäftigt, die Analyse von Anwendungen durchführt, das heißt, was machen Sie?
- Es ist einfach für einen Tester. Vergewissern Sie sich, dass Sie über Programmierkenntnisse verfügen und wissen, wie das System von innen aufgebaut ist. Aber einen guten Tester ohne diesen gibt es nicht mehr. Wenn dies der Fall ist, stellt sich die Frage nach der Spezialisierung: Er muss etwas über Sicherheit und bestimmte Technologien (z. B. Android oder Backing) lesen, das heißt, in denen er nach Sicherheitslücken sucht.
Entwickler sehen ihre Beteiligung am Prozess etwas anders. Für den Entwickler ist dies daher eine Revolution, ein anderer Blick auf den Beruf. Es ist wichtig für den Entwickler, dass etwas funktioniert, aber es wird schwierig für ihn, zu brechen.
Pentester, Rescher und Application Security Analyst: Was ist der Unterschied?
- Soweit ich weiß, haben Sie sich auf Pentester spezialisiert. Wie vergleichen sich Pentester und Zero-Day-Vulnerability-Forscher, oder ist alles in einer Flasche zusammengefasst, und ist es wirklich schwierig, herauszufinden, wer wer ist?
- Es gibt keine klare Einteilung in Posten. Aber ich sage Ihnen, welche Begriffe die Partei verwendet.
Es gibt Scouts, die nach einem Produkt, einer Technologie, einem Protokoll oder einem Server suchen, um ein interessantes Problem zu finden. Interessant bezieht sich auf ein Problem, das zuvor nicht gefunden oder an einem unerwarteten Ort identifiziert wurde, oder es ist eine komplexe Kombination von zuvor bekannten Problemen. Ich kann sagen, dass in der Regel alle möglichen 0-Tage-Sicherheitslücken von Scouts gefunden werden.
Pentest ist ein Service. Sie haben ein System und möchten Schwachstellen finden. Die Aufgabe der Pentester ist es, in das System einzudringen. Sie werden nicht alle potenziellen Probleme finden können. Beispielsweise kann eine Sicherheitsanfälligkeit durch andere Sicherheitsmechanismen auf verschiedenen Ebenen gemindert werden. Pentester wird nach dem suchen, was tatsächlich ausgenutzt wird, und anschließend einen Bericht erstellen und verlassen, da es nicht die Aufgabe hat, die Sicherheit des Systems zu erhöhen oder die Entwicklungsprozesse anzupassen.
Es gibt auch Anwendungssicherheits- oder Produktsicherheitsanalysen. Sie betrachten das System im Gegenteil von innen. Ihre Aufgabe ist es, das System sicher zu machen. Dies bedeutet, dass sie Informationen über das System haben, und es ist keine "Black Box" für sie. Andererseits stufen sie Probleme unterschiedlich ein. Analysten betrachten sogar Schwachstellen, die derzeit nicht ausgenutzt werden können. Es gibt zum Beispiel eine kritische Lücke im Admin-Bereich, und es ist klar, dass nur über das interne Netzwerk darauf zugegriffen werden kann. Daher ist dies nicht sehr beängstigend. Aber der Insider weiß, dass unter bestimmten Umständen etwas Schreckliches passieren kann.
Analysten konzentrieren sich mehr auf die Unterstützung des Prozesses. Wenn die Pentester 20 Bugs finden und verlassen und die Entwickler bei der Behebung von Bugs dasselbe tun, werden die Pentester hier nicht weiterhelfen. Daher ist das Verständnis der Anzahl der Schwachstellen im System nur zu diesem Zeitpunkt relevant.
- Tut dies der Anwendungssicherheitsanalytiker dann Tag für Tag?
- Ja, und gleichzeitig ist die Tätigkeit in zwei Richtungen gerichtet. Einerseits müssen Sie nach vorhandenen Schwachstellen suchen und diese bekämpfen. Andererseits ist es eine Aufgabe, das System sicherer zu machen.
Dies kann auf verschiedene Arten angegangen werden. Erstellen Sie den Entwicklungsprozess beispielsweise so, dass weniger Fehler auftreten oder diese schnell erkannt werden. Oder implementieren Sie Mechanismen, die das Risiko verringern, dass die Sicherheitsanfälligkeit in die Produktion fällt. Es gibt verschiedene Möglichkeiten, die Systemsicherheit zu gewährleisten.
- Die Arbeit der Application Security Analytics ist also eng mit den Teams und dem Entwicklungsprozess verbunden?
- Ja, ein Analyst für Anwendungssicherheit sollte eine Frage zum Entwicklungsprozess stellen. SDLC (Secure Development LifeCycle) ist das erste Schlagwort zum Thema Anwendungssicherheit. Kurz gesagt, das Ziel dieser Maßnahmen besteht darin, sicherzustellen, dass in jedem Entwicklungsstadium Überlegungen zur Systemsicherheit berücksichtigt werden. In diesem Fall ist nicht immer ein Sicherheitsspezialist mit der Ausführung bestimmter Aufgaben befasst. Manchmal können Sie sie an andere Teammitglieder delegieren. Denn je früher Sie ein Problem finden, desto billiger ist es, es zu beheben.
Der menschliche Geist ist immer noch unverzichtbar, um Schwachstellen zu finden
- Probleme mit dem Produkt können auf der Ebene der Spezifikation, der Diskussion, des Prototyps und der Skizze gefunden werden, wenn keine einzige Codezeile vorhanden ist. Aber Sicherheitsfragen in welchem Stadium wird es möglich zu finden? Und ist es möglich, sie schon vor dem Schreiben des Codes zu finden?
- Natürlich, weil es Probleme gibt, die direkt mit der Formulierung der Anforderungen zusammenhängen. Lassen Sie mich Ihnen ein wildes Beispiel geben. Sie erstellen ein Anmeldeformular, und der Designer sagt Ihnen: "Und lassen Sie unsere Benutzer sagen, dass sie nicht nur das falsche Passwort eingegeben haben, sondern im letzten Buchstaben ihres Passworts einen Fehler gemacht haben." Das heißt, der Wortlaut der Anforderung kann von Natur aus unsicher sein.
In der Phase von TK kann davon ausgegangen werden, dass das System bestimmten Schwachstellen unterliegt und einige Schutzmechanismen implementiert werden müssen. Wenn Sie auf der Website dasselbe Formular verwenden, müssen Sie auf jeden Fall ein Captcha erstellen, um das Erraten des Kennworts zu verhindern. Daher sollten solche Punkte bei der Entwicklung der Architektur erwähnt werden.
- Wie oft sind Sicherheitstests in CI / CD-Prozesse eingebettet, und ist dies schwierig? Das heißt, um eine Pipeline in Jenkins oder TeamCity „abreißen“ zu können, und es gab eine separate Phase, in der Sicherheitstests durchgeführt wurden. Wie echt ist es?
- Es gibt Richtlinien zum selben SDLC, es gibt Anforderungen an die Aufsichtsbehörden. Unternehmen, die einen ausgereiften Entwicklungsprozess haben, implementieren sie entsprechend. Es gibt Werkzeuge zur Automatisierung eines Teils des Prozesses, aber das Verhältnis von Aufwand und Ergebnis hängt von der Art des Projekts und davon ab, in welchem Entwicklungsstadium die Implementierung dieser Techniken begonnen hat.
Wenn die Anwendung von Grund auf neu geschrieben wurde, können Sie die Verwendung eines statischen Analysators anbieten, um zweifelhafte Anweisungen im Code zu vermeiden. Und wenn Sie vor 10 Jahren den Code geschrieben haben und mit Ihrem Werkzeug für verrücktes Geld dorthin gekommen sind, werden Sie natürlich ein wenig finden.
Alle automatischen Werkzeuge haben das Problem, dass sie nicht sofort wissen, wie das System funktioniert. Wenn eine einzelne Komponente des Systems isoliert werden kann, kann sie mit vorgefertigten Werkzeugen getestet werden. In einem System mit vielen Abhängigkeiten können automatische Scanner jedoch wertvolle Informationen verlieren.
Sicherheitsanalysen in anderen Unternehmen
- Welches Unternehmen oder welches Einzelprojekt ist Ihrer Meinung nach das Flaggschiff in der Anwendungssicherheitsanalyse, basierend auf Firmenreden und Konferenzpräsentationen?
- Microsoft entwickelte die Implementierung von SDLC, die zum Kanon wurde. Aber ich weiß nicht, wie sie auf der niedrigsten Ebene funktionieren, welche Tools verwendet werden.
Facebook schreibt viel darüber, wie alles technisch organisiert ist: wie sie Code scannen, Schwachstellen in funktionierenden Systemen finden usw. Bei einigen Facebook-Tools handelt es sich sogar um Open-Source-Projekte.
Wenn wir russische Unternehmen nehmen, dann hat die Sberbank interessanterweise darüber gesprochen, wie sie SDLC formalisiert haben, und den Prozess dokumentiert. Obwohl das Team für Anwendungssicherheit ziemlich groß ist, reicht es vielen Entwicklern nicht aus. Aus diesem Grund bilden sie Sicherheitschampions in Teams aus, üben ein gewisses Sicherheitswissen aus und können in diesem Fall eine rote Fahne hissen.
Yandex spricht auf Konferenzen über coole Dinge wie "Wie man einen Browser hackt".
- Ist es realistisch, dass der Tester nach der Konferenz, als er einen Bericht über Bedrohungen und Tools hörte, nach deren Implementierung einen signifikanten Effekt erzielt? Zum Beispiel wird ein Unternehmen einen Scanner für 10.000 US-Dollar kaufen, der nach Löchern in der Jenkins-Pipeline sucht. Oder ist es wichtiger, die Mechanismen der Ausnutzung von Schwachstellen zu kennen, um einige Dinge zu implementieren?
- Sie können keinen Scanner für zehntausend Dollar kaufen (lacht) . Wenn wir über die Suche nach Schwachstellen sprechen, kommt es darauf an, bestimmte Szenarien zu testen. Szenarien werden aus allgemein bekannten Sammlungen entnommen.
Beispielsweise veröffentlicht OWASP (Open Web Application Security Project) Anleitungen zur Durchführung von Sicherheitstests, Codeüberprüfungen usw. Beispielsweise wird in OWASP Application Security Verification Standard über alles geschrieben, was getestet werden muss. Zum Lesen des Dokuments sind keine besonderen Kenntnisse erforderlich. Es reicht aus, Webanwendungen zu kennen, damit jeder Tester damit umgehen kann.
Die Standard- und Spickzettel reichen aus, um manuelle Tests durchzuführen. Hier steht, welche Arten von Sicherheitslücken existieren und wie man sie sucht. Einige Tests können per Definition nicht von Standard-Scannern durchgeführt werden, z. B. solche, die sich auf die Überprüfung der Geschäftslogik beziehen.
Wenn Sie jedoch XSS suchen müssen, müssen Sie jedem geänderten Parameter ein Anführungszeichen, eine Klammer usw. hinzufügen. Wenn das System 100 Millionen Parameter enthält, ist die Aufgabe nicht mehr ausführbar. Aber automatisierte Werkzeuge werden mit ihr gut auskommen.
Beim Starten des Scanners können jedoch drei Szenarien auftreten:
- Das Tool hat einen Bericht veröffentlicht, in dem es viele gut reproduzierbare Fehler und ein wenig falsch positive Fehler gibt (ideal, aber unwahrscheinlich).
- Der Bericht enthält 20.000 Funde, von denen etwa 1% wahr sind. Daher muss man sitzen und feststellen, ob die wirklichen Probleme vorliegen.
- Das Tool konnte etwas im System nicht verstehen, daher gab es einen Bericht aus, in dem alles in Ordnung ist, aber es ist nicht. Zum Beispiel konnte ich den Code nicht kompilieren, weil ich die Bibliothek nicht finden konnte. Oder handelt es sich um einen Schwachstellenscanner, der 10 Anfragen gestellt hat, auf Anti-Flood gestoßen ist und vom Server keine Antwort auf die verbleibenden Millionen Anfragen erhalten hat.
Aus diesem Grund ist es wichtig zu verstehen, dass sich der Scanner „unter der Haube“ befindet, um das der zu lösenden Aufgabe entsprechende Werkzeug auszuwählen und das Ergebnis angemessen auszuwerten.
Alexander wird das Thema der richtigen Auswahl und Optimierung von Werkzeugen in seinem Bericht über Heisenbug behandeln. Dort wird sie über die Anwendung und Anpassung von SAST-Lösungen SonarQube und Find Security Bugs sprechen, um nach Schwachstellen in ihrem Projekt zu suchen. Welche Funktionen bieten diese Tools "out of the box"? Und wie kann man die Funktionalität selbst erweitern? Als Beispiel wird der Redner die Sicherheitslücken von XSS und IDOR betrachten.
Die Konferenz findet vom 5. bis 6. Dezember in Moskau statt.