Prevención en la era de la superficie de ataque infinita

Eine Version dieses Artikels erschien in der SD-Zeiten. Es wurde hier aktualisiert und syndiziert.

‍

Wenn wir über Fortschritt sprechen, steht in der Regel der digitale Fortschritt im Vordergrund der Konversation. Wir wollen, dass alles besser, schneller, bequemer und leistungsfähiger ist, und das mit weniger Geld, Zeit und Risiko. In den meisten Fällen werden diese „unmöglichen“ Ziele irgendwann erreicht; es kann mehrere Jahre und mehrere Versionen dauern (und ein Team von Entwicklern, die einen Coup starten könnten, wenn sie gebeten werden, beim Feature-Design umzuschalten) noch ein verdammtes Mal), aber jeden Tag verändert Code die Welt.

Mit einer großen Softwareerweiterung geht jedoch auch eine große Verantwortung einher, und die Realität ist, dass wir aus Sicherheitsgründen einfach nicht bereit sind, uns damit zu befassen. Softwareentwicklung ist keine Insel mehr, und wenn wir alle Aspekte des softwaregestützten Risikos berücksichtigen — von der Cloud über eingebettete Systeme in Geräten und Fahrzeugen bis hin zu unserer kritischen Infrastruktur, ganz zu schweigen von den APIs, die alles verbinden —, ist die Angriffsfläche grenzenlos und außer Kontrolle geraten.

Wir können keine magische Zeit erwarten, in der jede Codezeile von erfahrenen Sicherheitsexperten akribisch überprüft wird - Diese Qualifikationslücke wird sich in absehbarer Zeit nicht schließen - aber wir können als Branche einen ganzheitlicheren Ansatz für die Sicherheit auf Codeebene verfolgen.

Lassen Sie uns untersuchen, wie wir diese unendliche Angriffsfläche mit den zur Verfügung stehenden Tools in den Griff bekommen können:

Seien Sie realistisch in Bezug auf das Ausmaß des Geschäftsrisikos (und was Sie bereit sind zu akzeptieren)

Perfekte Sicherheit ist nicht nachhaltig, aber auch nicht, eine Augenbinde aufzusetzen und so zu tun, als wäre alles blau. Wir wissen bereits, dass Unternehmen wissentlich anfälligen Code versenden, und es ist klar, dass dies ein kalkuliertes Risiko ist, das auf der Zeit basiert, in der neue Funktionen und Produkte auf den Markt gebracht werden.

Schnelle Sicherheit ist eine Herausforderung, insbesondere an Orten, an denen DevSecOps nicht die Standardentwicklungsmethode ist. Wir müssen uns jedoch nur die neuesten ansehen Log4Shell-Exploit um herauszufinden, wie relativ kleine Sicherheitsprobleme im Code Möglichkeiten für einen erfolgreichen Angriff eröffnet haben, und um zu erkennen, dass die Folgen dieser kalkulierten Risiken für den Versand von Code mit geringerer Qualität weitaus größer sein könnten als erwartet.

Machen Sie sich damit vertraut, ein Freak für (Zutritts-) Kontrollen zu sein

Eine alarmierende Anzahl kostspieliger Datenschutzverletzungen wird durch schlecht konfigurierte Cloud-Speicherumgebungen verursacht, und das Risiko, dass vertrauliche Daten aufgrund von Fehlern bei der Zugriffskontrolle gefährdet werden, verfolgt die Sicherheitsteams in den meisten Unternehmen weiterhin.

Im Jahr 2019 hat das Fortune-500-Unternehmen First American Financial Corp. habe das auf die harte Tour herausgefunden. Ein Authentifizierungsfehler, der relativ einfach zu beheben war, führte zur Offenlegung von über 800 Millionen Datensätzen, darunter Kontoauszüge, Hypothekenverträge und Lichtbildausweise. Ihre Dokumentenlinks erforderten keine Benutzeridentifikation oder Anmeldung, sodass sie für jeden mit einem Webbrowser zugänglich waren. Schlimmer noch, sie wurden mit fortlaufenden Nummern protokolliert, was bedeutet, dass eine einfache Änderung der Nummer im Link einen neuen Datensatz enthüllte.

Dieses Sicherheitsproblem wurde intern identifiziert, bevor es in den Medien enthülltDas Versäumnis, das Problem ordnungsgemäß als Sicherheitsproblem mit hohem Risiko einzustufen, und das Versäumnis, es der Geschäftsleitung zur dringenden Behebung zu melden, führte jedoch zu einem Fallout, mit dem bis heute umgegangen wird.

Es gibt einen Grund, warum eine kaputte Zugangskontrolle jetzt ganz oben auf der OWASP Top 10: Es ist so alltäglich wie Dreck, und Entwickler benötigen ein verifiziertes Sicherheitsbewusstsein und praktische Fähigkeiten, um die Best Practices rund um Authentifizierung und Rechte in ihren eigenen Builds zu nutzen und sicherzustellen, dass Kontrollen und Maßnahmen zum Schutz vertraulicher Daten getroffen werden.

Die Art der APIs macht sie besonders relevant und knifflig. Sie sind von Natur aus sehr gesprächig mit anderen Anwendungen, und Entwicklungsteams sollten alle potenziellen Zugangspunkte im Blick haben. Schließlich können sie unbekannte Variablen und Anwendungsfälle nicht berücksichtigen, um sicherere Software bereitzustellen.

Analysieren Sie Ihr Sicherheitsprogramm: Wie viel Wert wird auf Prävention gelegt?

Es macht Sinn, dass ein großer Teil eines Sicherheitsprogramms der Reaktion und Reaktion auf Vorfälle gewidmet ist, aber vielen Unternehmen fehlt eine wertvolle Risikominimierung, da sie nicht alle verfügbaren Ressourcen nutzen, um einen Sicherheitsvorfall von vornherein zu verhindern.

Sicher, es gibt umfassende Stapel von Sicherheitstools, die bei der Aufdeckung problematischer Fehler helfen, aber fast 50% der Unternehmen gaben zu, dass ein Versandcode, von dem sie wussten, dass er anfällig war. Zeitbeschränkungen, die Komplexität der Tools und der Mangel an geschulten Experten, die auf die Berichterstattung reagieren, tragen zu einem im Wesentlichen kalkulierten Risiko bei. Die Tatsache, dass Code in der Cloud, in Anwendungen, in API-Funktionen, eingebetteten Systemen, Bibliotheken und einer ständig wachsenden Technologielandschaft gesichert werden muss, stellt jedoch sicher, dass wir mit dem aktuellen Ansatz immer einen Schritt hinterherhinken.

Sicherheitslücken sind ein vom Menschen verursachtes Problem, und wir können nicht erwarten, dass Roboter die ganze Behebung für uns erledigen. Wenn Ihre Entwicklungskohorte nicht effektiv weitergebildet wird — nicht nur ein jährliches Seminar, sondern geeignete Schulungsbausteine —, dann laufen Sie immer Gefahr, minderwertigen Code als Standard zu akzeptieren, und das damit verbundene Sicherheitsrisiko.

Haben Sie die Bereitschaft Ihrer Entwickler überschätzt?

Entwickler werden selten nach ihren Fähigkeiten zur sicheren Codierung bewertet, und das ist nicht ihre Priorität (und in vielen Fällen auch kein KPI). Sie können nicht die Sündenbock für schlechte Sicherheitspraktiken sein, wenn ihnen nicht ein besserer Weg aufgezeigt oder gesagt wird, dass dies ein Maßstab für ihren Erfolg ist.

Allzu oft wird in Unternehmen jedoch davon ausgegangen, dass die bereitgestellten Leitlinien das Entwicklungsteam effektiv darauf vorbereitet haben, allgemeine Sicherheitsrisiken zu minimieren. Abhängig von der Schulung und ihrem Bewusstsein für die Anwendung bewährter Sicherheitsmethoden sind sie möglicherweise nicht darauf vorbereitet, die erwünschte erste Verteidigungslinie zu sein (und zu verhindern, dass endlose Fehler die Pentest-Berichte verstopfen).

Im Idealfall werden Lernpfade mit zunehmender Komplexität abgeschlossen und die daraus resultierenden Fähigkeiten verifiziert, um sicherzustellen, dass sie für den Entwickler in der realen Welt tatsächlich funktionieren. Dazu ist jedoch ein kultureller Standard erforderlich, bei dem Entwickler von Anfang an berücksichtigt und korrekt befähigt werden. Wenn wir als Branche in die Wildnis gehen, um diese riesige Codelandschaft zu verteidigen, die wir selbst erstellt haben, brauchen wir jede Hilfe, die wir bekommen können... und es liegt mehr direkt vor uns, als wir denken.