Anwendungssicherheit oder Einbetten von Sicherheit in die benutzerdefinierte Entwicklung. Persönliche Erfahrung bei AGIMA

Digitale Agenturen achten immer mehr auf die Sicherheit der Infrastruktur, in der sie sich entwickeln, und beginnen auch, die Anwendungssicherheit zu gewährleisten. Sie lesen wahrscheinlich über die Vielfalt und Kritikalität von Schwachstellen, Tools und Methoden zur Bereitstellung von Informationssicherheit. Aber wie wirkt sich das Ignorieren oder Sicherstellen der Anwendungssicherheit auf den benutzerdefinierten Entwicklungsprozess selbst aus?

Was ist in dem Artikel:

Wir werden nicht zum hundertsten Mal wiederholen, warum Sicherheit so wichtig ist, welche Schwachstellen bestehen oder wie das Rote Team das Blaue Team in einem anderen Kampf besiegt. Dies ist eine kurze Geschichte darüber, warum wir der benutzerdefinierten Entwicklung Sicherheit hinzugefügt haben und wie wir dies getan haben.

Für wen ist der Artikel?

Der Artikel kann für Projektmanager, technische Direktoren, Teamleiter und alle von Interesse sein, die sich irgendwie auf die Organisation von Anwendungsentwicklungsprozessen beziehen.

Haftungsausschluss:

Dieser Artikel ist kein Allheilmittel, sondern nur eine rein persönliche Meinung des Autors (Alexey Klinov, Leiter Informationssicherheit bei AGIMA).

Wie alles begann

AGIMA ist seit langem an der umfassenden Entwicklung von Qualitätskontrollverfahren und der QS-Abteilung beteiligt. Alle unsere Produkte werden zahlreichen internen Prüfungen unterzogen:

• Verwenden Sie Checklisten nach jeder Phase / jedem Sprint der Produktentwicklung.
• Wir decken geschäftskritische Funktionen mit einem Netzwerk von Autotests ab.
• Wir versuchen, den Code so weit wie möglich mit Unit-Tests abzudecken.
• Wir verwenden Code-Analysatoren, die den Standards entsprechen (zum Beispiel für PHP ist es PSR 0-4 usw.).
• Wir führen unbedingt Belastungstests durch.

Weitere Details zu unseren Prozessen finden Sie im Artikel . Aber warum haben wir beschlossen, eine weitere Testgrenze hinzuzufügen?

Vom Kunden

Viele Kunden suchen selbst nach Schwachstellen: Sie verwenden Instrumentenscanner oder führen Stifttests durch. Auf die eine oder andere Weise werden unser Code und unsere Projekte als Ganzes häufig vom Kunden einer Vielzahl von Prüfungen unterzogen.
Die Anzahl der Überprüfungen nahm zu, Berichte über die Ergebnisse von Instrumentenscans und Pen-Tests wurden immer häufiger. Das Studieren, Reproduzieren, Genehmigen und Beheben von Schwachstellen beanspruchte viele interne Ressourcen und konnte sich um Wochen verzögern.

Von Hand zu Hand, wenn jemand anderes ein Projekt entwickelte

Manchmal werden Projekte von einem anderen Auftragnehmer geerbt. Sie können sich im Vorverkaufszustand und „im Kampf“ befinden. Die Verantwortung für die Arbeit liegt bereits bei uns, und seltsamerweise auch der gesamte „Wagen“ mit Fehlern und Schwachstellen.
Wir haben vorgeschlagen, dass es effizienter und billiger ist, über eigenes Fachwissen zu verfügen.

Was ist im Weg?

Bei der Entwicklung konzentrieren wir uns auf die Qualität der Anwendung, die Geschwindigkeit ihrer Inbetriebnahme und die Kosten. Wenn Sie zusätzliche Elemente in Form einer Codeanalyse für Schwachstellen hinzufügen, wirkt sich eine weitere Testzeile oder ein weiterer Mitarbeiter auf diese Indikatoren aus. Angesichts der geringen Marge des Geschäfts ist dies für die kundenspezifische Entwicklung von entscheidender Bedeutung. Gleichzeitig sollte zur Optimierung der Kosten der Ansatz zur Sicherheitskontrolle von Produkten universell sein und auf alle Projekte angewendet werden. Aber Kunden sagen normalerweise nicht: "Machen Sie uns die gleiche Anwendung wie die Jungs dort, nur grün." Kunden wollen nicht nur ihr Design, sondern auch Funktionalität. Darüber hinaus hat jeder Unternehmensbereich seine eigenen Bedürfnisse: Die Anforderungen für Anwendungen im Finanzsektor, in der Medizin und im Einzelhandel sind unterschiedlich. Das Team und die Technologie bei jedem Projekt können sehr unterschiedlich sein.

Offensichtlich verbessert die Produktsicherheitskontrolle die Qualität. Aber wie wirkt sich die Sicherheitsanalyse auf die Kosten und den Zeitpunkt von Projekten aus?

Durch Hinzufügen einer zusätzlichen Überarbeitung des Codes zur Schätzung verteuern wir das Projekt zunächst und verlängern die Entwicklungszeit, genau wie bei anderen Testarten. Aber dieses Budget müsste immer noch ausgegeben werden, nur weniger systemisch und schmerzhafter. Tatsächlich ist das Produkt am Ausgang „sauberer“, was die technische Verschuldung verringert, die Notwendigkeit beseitigt, nach Pen-Tests viel Zeit und Ressourcen für die Verfeinerung aufzuwenden, und dementsprechend wird die Zeit für die Produktion des Produkts verkürzt.
In unserem Fall erwies sich die Implementierung der Sicherheitsanalyse unter Berücksichtigung des gesamten Projektzyklus als billiger und schneller. Die Kosten in einigen Projekten wurden auf 20% gesenkt, unter anderem durch die Verkürzung der Zeit zum Lokalisieren von Schwachstellen und deren Beseitigung, noch bevor der Code-Review-Teamleiter.
Es wurde beschlossen, den besten Weg zu finden, um Informationssicherheit in unseren Entwicklungsprozessen zu implementieren.

Erste Schritte

Unsere Ansicht zur Verbesserung der Anwendungssicherheit:



WAF- und DDoS-Schutz sind zusätzliche Schutzschichten auf dem Produkt. Und für unsere Zwecke benötigen wir einen Code-Analysator für Schwachstellen und einen Pen-Test.

Kleiner Würfel

Bei der Auswahl eines Analysegeräts haben wir bezahlte teure Produkte ausgeschlossen. Wir haben bei SonarQube angehalten - einem Analysegerät mit einer Shareware-Version. Es gibt auch eine Cloud-Version , aber die kostenlose Version macht die Projekte vollständig offen, was in unserem Fall nicht akzeptabel ist.
Daher zu starten - SonarQube Community Edition. Es unterstützt 15 Sprachen, darunter Java, JavaScript, C #, PHP und Python. Die Lösung ist recht schnell implementiert und verursacht keine besonderen Probleme. Eine ausführliche Anleitung trägt dazu bei.



Praktisches System zur Differenzierung von Rechten: Sie können eine Zugriffsmatrix für jedes Projekt erstellen.



Mit SonarQube können Sie die Dynamik des Projekts beobachten und den Verlauf der Analyse speichern. Wir selbst können für jedes Projekt einen Qualitätsschwellenwert festlegen, mit dem wir die Analyse für verschiedene Projekte optimieren können.





Wir haben das Produkt in mehreren Projekten getestet:

1. In aktuellen Projekten konnten mehrere nicht offensichtliche Sicherheitslücken entdeckt werden.
2. Die Implementierungszeit war minimal.
3. Wir haben sichergestellt, dass der Code im Rahmen von CI zur Überarbeitung zurückgegeben wird, um mögliche Schwachstellen anzuzeigen.

Wir haben entschieden, dass dies für unsere Bemühungen ausreicht.

Was weiter?

Für uns haben wir drei Ansätze identifiziert, die je nach Projekt und Kundenbedürfnissen variieren:

• Vollständige Integration in den Entwicklungsprozess (CI / CD).
• Sicherheitsüberprüfung an Kontrollpunkten.
• Situatives oder einmaliges Sicherheitsaudit.

Vollständige Integration in den Entwicklungsprozess

Wir haben die Lösung in GitLab integriert. Verwendete GitLab CI / CD, um den Start von Prüfungen zu automatisieren. Dies erforderte das kostenlose Sonar GitLab Plugin Plugin . Das System benachrichtigt Entwickler über Commits, bei denen die Überprüfung fehlschlägt, und fügt Kommentare hinzu, die den Problembereich beschreiben (Art der Sicherheitsanfälligkeit, Empfehlungen zur Behebung des Problems und andere).
Eines der Projekte implementierte die Integration mit Bitbucket und Bamboo. In diesem Fall wurden die kostenpflichtigen Plugins Sonar für Bamboo und Sonar für Bitbucket Server benötigt. Nach dem Testbetrieb war der Kunde bereit für zusätzliche Kosten, die Lösung passte perfekt in den technologischen Stack.



Die ideale Option ist, wenn die Fristen, das Budget und der Kunde es uns ermöglichen, unsere Sicherheitsprozesse in den täglichen Zyklus der Arbeit mit dem Code zu integrieren. In der Praxis stellte sich heraus, dass dieser Ansatz für die langfristige Entwicklung und Unterstützung von Projekten mit häufigen Veröffentlichungen relevant ist.

Checkpoint Security Audit

Für uns war dieser Ansatz optimal für Projekte, bei denen Veröffentlichungen selten sind, beispielsweise einmal im Quartal. Funktions- oder Produktanforderungen können sich während des Betriebs ändern. Wenn Sie sich aus Sicherheitsgründen ständig jede Codezeile ansehen, wird viel zusätzliche Zeit für die Teile des Produkts aufgewendet, die wir und der Kunde später ablehnen können.

Was beziehen wir uns auf Kontrollpunkte:

• Logischer Meilenstein in der Entwicklung von MVP.
• Veröffentlichung einer bestimmten Version des Produkts mit wichtigen Benutzerinteraktionsfunktionen.
• Eine bestimmte Version, ein Sprint oder eine Reihe von Sprints, die auch wichtige Funktionen für die Interaktion mit dem Benutzer bieten.

Bei Schlüsselprojekten haben wir begonnen, integrierte Analysen mit Sicherheitsüberprüfungen an Haltepunkten zu kombinieren. So identifizieren wir Schwachstellen, die während des Entwicklungsprozesses unbemerkt bleiben könnten.

Mit diesem Ansatz reduzieren wir die Anzahl der Iterationen des Debuggens, wenn das Produkt in den kommerziellen Betrieb versetzt wird. Wir bereiten einen gemeinsamen Pool von Korrekturen und Verbesserungen vor, der Funktionsfehler, Sicherheitslücken in der Informationssicherheit und Infrastrukturanforderungen umfasst.

Wir haben Statistiken zu Zeitkosten mit einem integrierten IS-Validierungsverfahren an und ohne Kontrollpunkte gesammelt. Wir haben nur Debugging- und Release-Aktivitäten in einer produktiven Umgebung gemessen.
Bei einem umfassenden Ansatz sind durchschnittlich zwei Iterationen des Debuggens erforderlich. Ihre Gesamtdauer beträgt ~ 15-20% der gesamten Entwicklungszeit.
Beim Verbinden von Dritten mit der Validierung der Informationssicherheit wurden durchschnittlich zwei Iterationen des funktionalen Debuggens und drei Iterationen des Debuggens von Sicherheitslücken / Infrastrukturanforderungen für die Informationssicherheit erhalten. Insgesamt betrug dies ~ 45% der gesamten Entwicklungszeit, ohne die Zeit, die Dritte nur auf unserer Seite verbracht haben.

Situatives oder einmaliges Sicherheitsaudit

Für einfache Projekte haben wir uns entschlossen, den Ansatz mit einer einmaligen Überprüfung der gesamten Codebasis vor der endgültigen Veröffentlichung anzuwenden. Die Landung reicht aus, um sie vor der Freigabe einmal zu überprüfen. Das Implementieren des Code-Scannens in einem Prozess oder das Durchführen von Zwischenprüfungen für solche Projekte ist teuer und sinnlos.

Außerdem wurde ein Situationsaudit für Projekte durchgeführt, die von anderen Entwicklern an uns übertragen wurden. Bevor wir mit der Weiterentwicklung fortfahren, minimieren wir die bestehende technische Verschuldung des Produkts. Danach legen wir fest, welchen Ansatz zur Sicherheitskontrolle wir bei der Weiterentwicklung des Projekts verwenden werden.

Dies ist das Ergebnis des Scannens eines Projekts, bei dem seit mehreren Jahren keine vollständige Prüfung auf Fehler und Sicherheit durchgeführt wurde:



Über 700 Schwachstellenartefakte! Wenn Sie alle Fehlalarme und geringfügigen Artefakte herausfiltern und nur Blocker und kritische Elemente übrig lassen, ist das Bild natürlich nicht so schrecklich. Aber das ist das Gepäck der technischen Schulden, das auf jeden Fall bearbeitet werden muss!



Wir ordnen die Schwachstellen ein und erstellen eine Roadmap, in der wir feststellen, wie viele Iterationen kritische Schwachstellen beseitigt werden müssen. Es hängt davon ab, welchen Code sie betreffen und welche Daten mithilfe dieser Sicherheitsanfälligkeiten abgerufen werden können. Wie wahrscheinlich ist es, dass ein Angreifer eine bestimmte Sicherheitsanfälligkeit ausnutzt?

In diesem Fall haben wir mehr als 200 Mannstunden damit verbracht, die gefundenen Schwachstellen zu „sichten“ und zu beseitigen, und erst danach haben wir mit der vollständigen Produktentwicklung begonnen. Manchmal ist es notwendig, solche Fälle zu lösen, da Unwissenheit viel teurer ist.

Wir haben hier nicht aufgehört:

• Analyse zu den meisten Projekten hinzugefügt.
• Die Tools zur Sicherheitskontrolle wurden durch appScreener von Rostelecom-Solar ergänzt.
• Manuelles Audit und Pen-Test für Schlüsselprojekte hinzugefügt.
• Einführung von Kriteriengruppen und Kritikalitätsstufen für die implementierte Funktionalität in Bezug auf die Auswirkungen auf die Anwendungssicherheit.

Und was dann?

Die Bemühungen zur Implementierung der Informationssicherheit in benutzerdefinierten Entwicklungsprozessen haben uns geholfen:

• Wir reduzieren das Reputationsrisiko sowohl für uns selbst als auch für unsere Kunden und minimieren so die Möglichkeit, unsere Anwendungen zu hacken.
• Nach Penetrationstests durch Drittanbieter haben wir die langen Phasen des Debuggens von Anwendungen fast verschwunden.
• Wir haben die Kompetenzen der Mitarbeiter im Bereich der Informationssicherheit erweitert und planen, uns weiter in diese Richtung zu bewegen: neue Sicherheitsführer zu entwickeln, unsere Wissensbasis zu erweitern, unsere Ansätze zu verfeinern und neue auszuprobieren.
• Wir haben einen hervorragenden Wettbewerbsvorteil gegenüber anderen Unternehmen erhalten, die kundenspezifische Entwicklungsdienste anbieten und nicht über Informationssicherheitskompetenzen verfügen.

Je mehr wir uns für die Verbesserung der Informationssicherheit einsetzen, desto mehr Wachstumspunkte sehen wir: Fügen Sie unseren Verfahrensprüfungen nicht nur TOP-10 OWASP und CWE / SANS hinzu, sondern beschleunigen Sie beispielsweise die Verfolgung von Sicherheitsbulletins oder bringen Sie unserem CI bei, den Sicherheitsleitfaden zu verwenden unsere Rahmenbedingungen.

Wir haben bereits unsere erste IB-Veranstaltung ( Rostelecom-Solar Business Dinner - AGIMA ) abgehalten , diesen Artikel geschrieben und planen, weiterhin neue Praktiken auf unseren Markt zu bringen, wie wir es in unserer Zeit mit adaptivem Design getan haben (siehe Adaptoz oder unser adaptives Wörterbuch) Design , veröffentlicht 2013) - damals begann dieser Trend bei uns und ist mittlerweile im Wesentlichen zum De-facto-Standard geworden. Wir wollen dasselbe mit der Informationssicherheit tun, weil "wenn Sie andere unterrichten, lernen Sie sich selbst".