Denken Sie an das letzte Mal, als Sie bei der Arbeit waren, vielleicht in einem Software-Projektteam, das an einer unmöglichen Deadline arbeitet. Und dann kommt Ihr Vorgesetzter daher und sagt, dass Sie eine obligatorische Sicherheitsschulung absolvieren müssen, die Sie zusätzlich zu allem anderen in Ihren Arbeitstag einbauen müssen.

Sie wissen es, und Sie wissen es. Es ist eine riesige PITA, aber aus Compliance-Gründen werden Sie einige langweilige Schulungsvideos im Hintergrund abspielen, während Sie weiter programmieren, sich in beide Aufgaben ein- und ausschalten und keiner von beiden Ihre volle Aufmerksamkeit widmen. Dies ist ein häufiges Szenario; es ist äußerst störend und verschwendet die Zeit aller Beteiligten. Die meisten Sicherheitsschulungen sind zu allgemein gehalten, und es ist leicht, etwas zu ignorieren, das ohne wirklichen Wert in den Arbeitstag hinein- und wieder heraushüpft.

Als Unternehmen ist es unser Ziel, Ihnen eine bessere, effektivere Art von Sicherheitstraining zu bieten. Dies ist aus dem Wissen geboren, wie es ist, wenn man von dem, was das AppSec-Team einem sagt, was wichtig ist, abgehalten wird, wenn jede Ihrer Prioritäten falsch ausgerichtet ist. Interessant ist jedoch, dass wir angefangen haben, darüber nachzudenken, was wir tun können, um die Barriere zu verringern, um ein Training zu bekommen, wenn Sie es brauchen - selbst mit unserer vollständigen Plattform sind ein paar Schritte involviert, die Sie von Ihrer Arbeit wegbringen, in Momenten, in denen Sie noch einen hilfreichen Anstoß brauchen, aber keinen Konzentrationsblock für eine Trainingssitzung aufbringen können.

Wir haben uns angeschaut, wie Micro-Learning nahtlos in Ihren Workflow, in die IDE oder den Issue Tracker, implementiert werden kann. Und das ist, was wir herausgefunden haben:

Dies basiert auf Just-in-Time (JiT)-Prinzipien, bei denen Ihnen das richtige Wissen zur richtigen Zeit zur Verfügung gestellt wird, damit es sofort effektiv und nützlich ist. Es ist das Gegenteil des "Just-in-Case"-Ansatzes beim Lernen, der oft zu einem Zustand der Informationsüberflutung führt, der wertvolle Zeit und den Kopf für die Erstellung von Funktionen wegnimmt.

Qualitativ hochwertiger Code ist sicherer Code, und wenn Sie einen nicht-invasiven Sicherheits-Sidekick brauchen, mit dem Sie gelegentlich zusammenarbeiten, dann könnte es sich für Sie lohnen, eine Testfahrt damit zu machen.

Beseitigen Sie die Barrieren, und bringen Sie die Schulung zu Ihnen.

Cybersecurity mag für einige von Interesse sein, aber nicht für jeden. Und niemand sollte erwarten, dass Entwickler zu Sicherheitsexperten werden - das bleibt immer noch die Aufgabe von spezialisierten AppSec-Teams. Dennoch werden sicherheitsbewusste Entwickler für ihre Fähigkeiten und den Schutz, den sie Unternehmen schon bei der Code-Erstellung bieten können, geschätzt. Es ist eine sehr gefragte Position, und Sie können die Grundlagen im Laufe der Zeit mit kontextbezogenem Micro-Learning aufbauen.

Wenn Sie nun an integrierte Schulungen denken, die eher wie Clippy(möge er in Frieden ruhen) sind, dann ist es wichtig zu wissen, dass im Fall von Secure Code Warrior die Integrationen von Entwicklern für Entwickler erstellt werden, sodass der Irritationsfaktor berücksichtigt und ausgelöscht wurde.

Schauen wir es uns in Aktion an:

Secure Code Warrior für Github untersucht den Code auf Common Weakness Enumeration (CWE) oder OWASP-Referenzen in den Labels, dem Issue-Titel und dem Body von Issues, um kontextbezogene Just-in-Time-Schulungen anzuzeigen. Wenn ein Verweis auf eine Schwachstelle gefunden wird, wird ein Kommentar zu dem Issue gepostet, um eine schnelle Lösung und die Vermeidung von wiederkehrenden Schwachstellen zu unterstützen. Es wird in das Problem integriert, ohne dass Ihr Prozess unterbrochen wird oder Sie für eine Lösung durch Reifen springen müssen.

Und wenn Sie Jira verwenden, ist der Prozess ähnlich:

Nun, für die etablierten sicherheitsbewussten Superstars ist es wichtig, sich daran zu erinnern, dass es nicht allein an Ihnen liegt, die Magie geschehen zu lassen. Sie brauchen Unterstützung, Training und einen Grund, Sicherheit ernst zu nehmen und in Ihren eigenen Arbeitsablauf zu integrieren. Glücklicherweise ist dies alles Teil eines funktionierenden DevSecOps-Prozesses, und viele Unternehmen nehmen dies bereits zur Kenntnis. Warum nicht einen Vorsprung bekommen?

Laden Sie sie jetzt herunter, und lassen Sie uns wissen, was Sie davon halten.

In den letzten Jahren scheint es, dass Software-Ingenieure auf der ganzen Welt nicht genug von Rust bekommen können. Diese relativ neue, von Mozilla entwickelte Systemprogrammiersprache hat die Herzen der Stack Overflow-Gemeinschaft erobert - und als eine Kohorte, die keine Dummheiten duldet, ist es an der Zeit, dass wir alle aufhorchen, wenn sie etwas fünf Jahre hintereinander zur"beliebtesten Programmiersprache" wählt.

Die Programmiersprache Rust enthält bekannte und funktionale Elemente aus häufig verwendeten Sprachen und arbeitet nach einer anderen Philosophie, die Komplexität beseitigt und gleichzeitig Leistung und Sicherheit einführt. Es ist eine Lernkurve, und viele Entwickler haben nicht die Möglichkeit, viel damit zu spielen - nur 5,1 % der auf Stack Overflow befragten Personen nutzten sie häufig. Abgesehen davon lässt sich jedoch nicht leugnen, dass es sich um eine aufregende Sprache handelt, die im Vergleich zu ihren Vorgängern wie C und C++ über viel mehr Sicherheitspotenzial verfügt. Die Masseneinführung wird einige Veränderungen erfordern, sowohl in Bezug auf das Verhalten als auch auf die Technologie... aber im Moment erregt sie noch die Aufmerksamkeit von Entwicklern auf theoretischer Ebene.  

... aber Moment, wir müssen noch eine weitere Sache beleuchten: Es ist wichtig zu erwähnen, dass Rust eine Programmiersprache ist, die der Speichersicherheit und der Ausmerzung von Sicherheitsfehlern, die mit häufigen Speicherverwaltungsproblemen verbunden sind, Priorität einräumt. Diese sind eine große Sache (und verursachen zweifellos mehr als nur ein paar AppSec-Teams Migräne), aber sie sind nicht die einzigen Herausforderungen, denen wir bei der sicheren Programmierung gegenüberstehen.

Was genau wird durch Rust verhindert? Und wo gibt es noch Lücken in der Sicherheitslandschaft? Lassen Sie uns das neueste Programmier-Einhorn auspacken:

Die neue Grenze der modernen, speichersicheren Systemprogrammierung

Das Forschungs- und Entwicklungsteam von Mozilla hat an einigen unglaublichen Projekten gearbeitet, und die Investition in die Rust-Programmierung als Open-Source-Vorreiter ist keine Ausnahme. Das Einführungsvideo gibt einen Einblick in das Ethos des Teams, wobei das Hauptthema klar herausgestellt wird: Der derzeitige Ansatz zur Softwaresicherheit ist mangelhaft, und Rust wurde entwickelt, um einen Großteil dieses Problems zu lösen.

Das scheint zu simpel zu sein, zumal wir jeden Tag mit enormen Datenschutzverletzungen konfrontiert werden - wie bei dem jüngsten schrecklichen Vorfall bei EasyJet. Millionen von Datensätzen werden häufig kompromittiert, fast immer durch eine Schwachstelle in einer Webanwendung, eine falsche Sicherheitskonfiguration oder einen Phishing-Angriff, und Sprachen wie C++ gibt es schon seit Jahrzehnten. Die Zeit hat jedoch nicht ausgereicht, um sie so weit zu beherrschen, dass die besten Praktiken für eine sichere Programmierung umgesetzt werden können. Warum sollte das bei Rust anders sein? Neue Sprachen sind schon früher auf den Markt gekommen, und es ist nicht so, dass sie einen Weg gefunden hätten, allgemeine Schwachstellen auszumerzen oder sicherzustellen, dass jeder geschriebene Code beim Kompilieren auf magische Weise perfekt ist.

So einfach das Konzept auch sein mag, manchmal sind es die einfachen Antworten, die komplexe Fragen überwinden. Rust ist im wahrsten Sinne des Wortes eine Revolution in der speichersicheren Systemprogrammierung, die in vielerlei Hinsicht hält, was sie verspricht... und sie rettet sicherlich den Speck von Entwicklern, die anfällig dafür sind, Fehler einzuführen, die große Probleme verursachen können, wenn sie unentdeckt bleiben. Java, C, C++ und sogar neuere Sprachen wie Kotlin und Golang sind für den sicherheitsunbewussten Entwickler ziemlich unversöhnlich. Bei diesen gibt es keine eingebauten Warnungen, keine besonderen Anzeichen dafür, dass die großartige Funktion, die gerade kompiliert wurde, einen Sicherheits-Gremlin unter der Haube versteckt hat.

Also, lassen Sie uns tiefer graben:

Was macht Rust so sicher?

Typischerweise hat ein Entwickler das primäre Ziel, Funktionen zu erstellen und sicherzustellen, dass sie funktional und benutzerfreundlich sind - vielleicht sogar Quellen des Stolzes, die er gerne in seinem Lebenslauf vorzeigen würde. Es ist völlig normal, dass ein Entwickler eine großartige Software erstellt, sie ausliefert und sich dem nächsten großen Projekt zuwendet. An diesem Punkt suchen Sicherheitsteams nach Schwachstellen, und wenn diese gefunden werden, kann es sein, dass die "fertige" Anwendung an das Team zurückgeschickt wird, um ein Hotfix zu erhalten. Das Problem kann einfach sein, oder es kann völlig außerhalb des vernünftigen Rahmens für einen Entwickler liegen, um es zu beheben.

Das Problem ist, dass die Sicherheitslücken oberflächlich betrachtet überhaupt nicht offensichtlich waren, und wenn Scannen, Testen und manuelle Codeüberprüfung sie nicht aufspüren, dann kann ein Angreifer dieses kleine Zeitfenster potenziell nutzen, um den Fehler auszunutzen.

Rust versucht zu verhindern, dass viele Schwachstellen überhaupt erst in den Code gelangen: Es wird einfach nicht kompiliert, wenn es Syntaxfehler oder andere Speichersicherheitsfehler gibt, die während des gesamten SDLCs Produktionsprobleme verursachen. Dies ist speichersichere Programmierung per Design, die sicherstellt, dass es keinen Zugriff auf ungültigen Speicher gibt (egal wie die Software ausgeführt wird). Und angesichts der Tatsache, dass 70 % aller Sicherheitsprobleme auf Probleme in der Speicherverwaltung zurückzuführen sind, ist dies eine große Leistung.

Rost wird angezeigt und verhindert:

• Pufferüberlauf
• Verwendung nach freier
• Doppelfrei
• Null-Zeiger-Dereferenz
• Verwendung von nicht initialisiertem Speicher

Wenn wir einen Rust-Codeschnipsel mit C++ vergleichen, wird deutlich, dass der eine standardmäßig sicher ist. Sehen Sie sich dieses Beispiel eines Pufferüberlauf-Bugs an:

#include <iostream></iostream>
#include <string.h></string.h>
int main( void ) {
char a[3] = "12";
char b[4]= "123";
strcpy(a, b); // buffer overflow as len of b is greater than a
std::cout << a << "; " << b << std::endl;
}

Vs.

pub fn main() {
let mut a: [char; 2] = [1, 2];
let b: [char; 3] = [1, 2, 3];
a.copy_from_slice(&b);
}

Rust gibt eine Sicherheitswarnung aus und gerät beim Erreichen der copy_from_slice-Funktion zur Laufzeit in Panik, um einen Pufferüberlauf zu verhindern, aber nicht zur Kompilierzeit.

In diesem Sinne ist es eine der "Start Left"-Sprachen. Sie wird Fehler hervorheben und den Entwicklern die richtige Art und Weise beibringen, Code zu schreiben, um die Einführung von speicherbezogenen Sicherheitsfehlern zu vermeiden, so dass die Einhaltung von Fristen davon abhängt, dass der Programmierer aufpasst, Korrekturen vornimmt und dem Lieferpfad treu bleibt.

Der Ansatz dieser Sprache scheint einfach zu sein, aber es wäre eine unglaubliche Leistung gewesen, sie mit dieser mächtigen Logik zum Laufen zu bringen, und sie macht es auch. Aus der Sicherheitsperspektive ist Rust ein riesiger Sprung nach vorn... wenn nur mehr Menschen es verwenden würden. Unternehmen wie Dropbox leisten Pionierarbeit bei der Verwendung von Rust in großen Unternehmen, und das ist großartig zu sehen. Aber es gibt noch mehr zu bedenken, bevor wir zu dem Schluss kommen, dass die Akzeptanz das einzige ist, was uns von einer sichereren Zukunft abhält.

Die Rust-Abrechnung.

Es gibt ein paar kleine (okay, große) Probleme, nämlich, dass die Programmierung in Rust mehr Flexibilität bietet, um Fehler einzuführen, als es vielleicht den Anschein hat. Es wird die wichtigen OWASP Top 10 Schwachstellen nicht beheben, die weiterhin zu Sicherheitslücken, Verzögerungen und einer allgemeinen Kultur unsicherer Programmiertechniken führen. Es gibt auch so etwas wie eine Engel- und Teufel-Dynamik, oder, wie es allgemein bekannt ist: Sicheres Rust vs. Unsicheres Rust.

Wie in der offiziellen Dokumentation erklärt wird, ist Safe Rust die "wahre" Form von Rust, und Unsafe Rust enthält Funktionen, die als "definitiv nicht sicher" gelten, obwohl sie manchmal notwendig sind - zum Beispiel, wenn eine Integration mit etwas in einer anderen Sprache erforderlich ist. Aber auch bei Unsafe Rust ist die Liste der zusätzlichen Funktionalitäten noch begrenzt. In Unsafe Rust ist es möglich, innerhalb von unsicheren Blöcken Folgendes zu tun:

• Dereferenzierung von Rohzeigern
• Aufrufen unsicherer Funktionen (einschließlich C-Funktionen, Compiler-Intrinsics und dem Raw Allocator)
• Unsichere Traits implementieren
• Statik mutieren
• Zugriffsfelder von Unions.

Auch im sogenannten "unsicheren" Modus funktioniert eine der Superkräfte der Rust-Programmierung: der "Borrow Checker". Er verhindert im Allgemeinen Speicherprobleme, Kollisionen bei parallelen Berechnungen und viele andere Fehler durch statische Code-Analyse, und diese Analyse wird in einem unsicheren Block immer noch Prüfungen vornehmen - es erfordert nur viel mehr Arbeit, unsichere Konstrukte zu schreiben, ohne dass der Compiler in bestimmten Situationen mit einer Anleitung eingreift.

Für die meisten erfahrenen Entwickler scheint dies kein großes Problem zu sein - schließlich sind wir dafür bekannt, zu tüfteln, um das Beste aus unseren Anwendungen herauszuholen und einige coolere Funktionen zu eröffnen -, aber es öffnet möglicherweise ein schwarzes Loch, das zu ernsthaften Fehlkonfigurationen und Sicherheitslücken führen kann: undefiniertes Verhalten. Die Programmierung in Rust (selbst bei unsicherer Verwendung) schließt die Möglichkeiten von Sicherheitslücken im Vergleich zu C oder C++ ziemlich gut ein, aber der Aufruf von undefiniertem Verhalten kann ein Risiko darstellen.

Ist dies das Ende des Vertrauens in die entwicklergeführte sichere Kodierung?

Erinnern Sie sich, als ich vorhin sagte, dass Rust Komponenten von bekannten Sprachen enthält? Eine der größten Sicherheitsschwachstellen von Rust ist, dass es Komponenten bekannter Sprachen enthält - nämlich C.

Rust ist immer noch eine "sichere Programmiersprache", aber auch hier ist die Einführung eines Benutzers der Punkt, an dem die Dinge aus dem Ruder laufen können. Der Entwickler kann es immer noch so anpassen, dass es ohne Fehlermeldung läuft (ein attraktiver Vorschlag, da dies mehr Fähigkeiten freischaltet), und im Wesentlichen können Entwickler sogar im sicheren Zustand so "unsicher" sein, wie sie wollen, weil sie eine Schicht von Anleitung und Schutz haben, bevor die Dinge wirklich birnenförmig werden können.

Und beide oben genannten Szenarien werden gefährlicher, je tiefer wir eintauchen, da die Ergebnisse von Rust denen von Scanning-Tools ähneln - so wie es kein SAST/DAST/RAST/IAST-Tool der Schweizer Armee gibt, das jede Schwachstelle, jeden Angriffsvektor und jedes Problem aufspürt, gibt es auch Rust nicht. Selbst mit Rust können einige Schwachstellen immer noch recht einfach eingeführt werden.

Das Risiko undefinierten Verhaltens bei der Verwendung von unsicherem Rust hat das Potenzial, Integer-Überlauf-Probleme auszulösen, während im Allgemeinen sogar die sicheren Konfigurationen menschliche Fehler bei Sicherheitsfehlkonfigurationen, Geschäftslogik oder der Verwendung von Komponenten mit bekannten Schwachstellen nicht verhindern können. Diese Probleme stellen immer noch eine sehr reale Bedrohung dar, wenn sie nicht gepatcht werden, und in einer "vermeintlich sicheren" Umgebung wie echtem Rust kann dies sogar zu einem selbstgefälligen Verhalten führen, wenn ein Programmierer glaubt, dass alle wichtigen Probleme trotzdem erkannt werden.

Ich habe festgestellt, dass Rust einem Mentor in der Programmierung nicht unähnlich ist - ein erfahrener Ingenieur, der sich die Zeit genommen hat, sich mit einem weniger erfahrenen Programmierer zusammenzusetzen, seine Arbeit zu überprüfen und ihm potenzielle Fehler zu zeigen, ihn auf Effizienzsteigerungen hinzuweisen und in einigen Fällen sicherzustellen, dass die Arbeit nicht kompiliert wird, bevor sie nicht richtig ist. Für Rust-Programmierer ist es jedoch weitaus besser, die Theorie zu lernen und sich selbst zu bewährten Verfahren zu verpflichten, denn der Mentor könnte die Schürze abnehmen, und Sie wollen nicht hängen gelassen werden.

Sind Sie bereit, gängige Rust-Schwachstellen zu finden und zu beheben, und zwar sofort? Spielen Sie die Herausforderung.

Nun, das war's (vorerst). Wir haben das Ende unserer Infrastructure as Code-Serie erreicht. Wir hoffen, Sie hatten Spaß beim Bezwingen von Sicherheitsproblemen in Docker, Ansible, Kubernetes, Terraform und CloudFormation. Bevor wir uns jedoch verabschieden, müssen Sie noch eine weitere Schwachstelle meistern: Fehler in der Geschäftslogik.

Denken Sie, Sie sind jetzt bereit, Ihre Fähigkeiten zu testen? Versuchen Sie die letzte spielerische Herausforderung:

Wenn Ihnen noch ein paar Dinge unklar sind, lesen Sie weiter:

Die Schwachstellen, auf die wir uns heute konzentrieren wollen, sind Schwachstellen in der Geschäftslogik. Diese können auftreten, wenn Programmierer die Regeln der Geschäftslogik nicht ordnungsgemäß implementieren, so dass ihre Anwendungen für verschiedene Arten von Angriffen anfällig sind, falls ein böswilliger Benutzer sie ausnutzen möchte. Je nach dem Zweck und der Funktionalität, die in einer Anwendung implementiert sind, kann ein Fehler in der Geschäftslogik die Ausweitung von Privilegien, die unsachgemäße Nutzung von Ressourcen oder eine Reihe von unbeabsichtigten Geschäftsprozessen ermöglichen.

Im Gegensatz zu vielen anderen Schwachstellen kann die fehlerhafte Implementierung von Geschäftslogikregeln überraschend subtil sein. Sie erfordern besondere Wachsamkeit, um sicherzustellen, dass sie sich nicht in Anwendungen und Code einschleichen.

Was sind einige Beispiele für Fehler in der Geschäftslogik?

Als Beispiel dafür, wie einfach es sein kann, Fehler in der Geschäftslogik zu verursachen, betrachten Sie das folgende Beispiel aus einer Docker-Umgebung, die mit einer Docker Compose-Datei definiert wurde. Um Container auf die Ausführung von Funktionen vorzubereiten, könnte ein Entwickler eine Standard-Ressourcenrichtlinie verwenden, die in der Docker Compose-Datei definiert ist, wie im folgenden Beispiel:

einsatz:
ressourcen:
limits:
cpus: "0.5"
reservierungen:
cpus: "0.5"

Das sieht zwar oberflächlich betrachtet gut aus, aber diese Ressourcenrichtlinie für Container schränkt die Ressourcennutzung nicht richtig ein. Ein Angreifer könnte den Fehler in der Geschäftslogik ausnutzen, um einen Denial-of-Service-Angriff (DoS) durchzuführen.

Um zu verhindern, dass Benutzer zu viele Ressourcen in Anspruch nehmen, könnte ein Entwickler versuchen, besser zu definieren, was jeder Container unterstützen kann. Der neue Code könnte also eine Platzierungsbeschränkung enthalten:

einsatz:
ressourcen:
limits:
cpus: "0.5"
reservations:
cpus: "0.5"
placement:
constraints:
- "node.labels.limit_cpu == 100M"
- "node.labels.limit_memory == 0.5"

Auf den ersten Blick sieht es so aus, als würde dies den Fehler in der Geschäftslogik beheben. Die neue Platzierungsbeschränkung wirkt sich jedoch nicht auf das Limit der Ressourcennutzung für den Docker-Containerdienst aus. Sie wird nur verwendet, um einen Knoten für die Planung des Containers auszuwählen. In diesem Fall ist ein DoS-Angriff immer noch möglich. Der Angreifer müsste zuerst einen Docker-Container kompromittieren, könnte dann aber unbegrenzt Ressourcen verbrauchen.

Wie Sie sehen können, kann das Nachdenken über Fehler in der Geschäftslogik und das Programmieren, um diese zu beseitigen, ein kniffliges Unterfangen sein.

Eliminieren von Fehlern in der Geschäftslogik

Bei Fehlern in der Geschäftslogik kommt es darauf an, zu wissen, dass sie existieren. Sie müssen wachsam sein, um sie aus Ihrer Umgebung herauszuhalten, während neuer Code geschrieben wird. Geschäftsregeln und Best Practices sollten in allen Phasen des Anwendungsentwicklungsprozesses, einschließlich Entwurf, Implementierung und Test, klar definiert und überprüft werden.

Um z. B. zu verhindern, dass ein Fehler in der Geschäftslogik einen DoS-Angriff wie im obigen Beispiel ermöglicht, besteht eine bewährte Methode darin, die Menge der Ressourcen zu begrenzen, die jeder von Ihnen erstellte Docker-Container verwenden kann. Insbesondere muss im Abschnitt "Limits" die Anzahl der CPUs und die Menge des Arbeitsspeichers angegeben werden, die ein Docker-Container verwenden kann. Ein Beispiel wäre:

einsatz:
ressourcen:
limits:
cpus: "0.5"
speicher: 100M
reservierungen:
cpus: "0.5"
memory: 50M

Die Verwendung von Code wie dem obigen Beispiel als Richtlinie würde einen wichtigen Fehler in der Geschäftslogik aus der Umgebung entfernen und DoS-Angriffe verhindern. Dies würde selbst dann funktionieren, wenn ein Angreifer einen der Docker-Container kompromittieren würde. In diesem Fall wäre der Angreifer immer noch nicht in der Lage, sein Standbein zu nutzen, um Ressourcen zu verbrauchen.

Die Bedrohungsmodellierung kann hilfreich sein, indem sie definiert, wie verschiedene Angriffe ablaufen und sicherstellt, dass Geschäftslogikregeln verwendet werden, um sie zu verhindern und einzuschränken. Das Testen auf Basis von Compliance-Regeln und bekannten Missbrauchsfällen könnte ebenfalls hilfreich sein, um Fehler in der Geschäftslogik zu erkennen, die durch die Maschen schlüpfen.

Geschäftslogikfehler gehören zu den subtilsten Schwachstellen, die sich in Anwendungen einschleichen können, sind aber nicht weniger gefährlich als andere, bekanntere Risiken. Wenn Sie wissen, wie sie auftreten können, und Best Practices anwenden, können Sie sie während der Anwendungsentwicklung aus Ihrer Umgebung heraushalten und sicherstellen, dass sie nie in eine Produktionsumgebung gelangen, wo sie von Angreifern missbraucht werden können, die sehr genau wissen, wie man sie ausnutzt.

Schauen Sie sich die Secure Code Warrior Blog-Seiten, um weitere Einblicke in diese Schwachstelle zu erhalten und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen anderer Sicherheitslücken schützen können. Sie können auch eine Demo dieser IaC-Herausforderung auf der Schulungsplattform Secure Code Warrior ausprobieren, um alle Ihre Cybersecurity-Fähigkeiten zu schärfen und auf dem neuesten Stand zu halten.

Wir nähern uns dem Ende unserer Infrastructure as Code-Serie, aber es war großartig, Entwicklern wie Ihnen auf ihrer IaC-Sicherheitsreise zu helfen.

Haben Sie die Herausforderungen gespielt? Wie ist Ihr Ergebnis bis jetzt? Bevor wir loslegen, wollen wir sehen, wie viel Sie bereits über die Fallstricke bei der Verwendung von Komponenten aus nicht vertrauenswürdigen Quellen wissen:

Haben Sie noch etwas zu tun? Lesen Sie weiter:

Das Verhalten, das eine Schwachstelle hervorruft, auf das wir uns heute konzentrieren werden, ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen, eine scheinbar harmlose Praxis, die große Probleme verursacht. Die Verwendung von Open-Source-Code und -Ressourcen hat viele Vorteile. Im Allgemeinen ermöglicht es Experten, ihre Ideen, ihre Arbeit und sogar fertigen Code zu Repositories wie GitHub beizusteuern, damit sie von anderen genutzt werden können, die sich darum bemühen, dass sich ein Programm oder eine App richtig verhält. Die Verwendung von fertigem Code zur Regelung von Programmfunktionen erspart es Entwicklern, das Rad jedes Mal neu erfinden zu müssen, wenn sie eine neue Anwendung erstellen müssen.

Die Verwendung von Codeschnipseln aus unzuverlässigen, ungeprüften oder sogar potenziell gefährlichen Quellen birgt jedoch ein großes Risiko. Tatsächlich ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen einer der häufigsten Wege, auf dem sich größere und kleinere Sicherheitslücken in ansonsten sichere Anwendungen einschleichen. Manchmal werden diese Schwachstellen versehentlich von ihren Erstellern herbeigeführt. Es gab auch schon Fälle, in denen bösartiger Code von potenziellen Angreifern geschrieben wurde. Der Code wird dann weitergegeben, in der Hoffnung, Opfer zu umgarnen, die ihn in ihre Anwendungen einbauen.

Warum ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen gefährlich?

Nehmen wir an, ein Entwickler hat es eilig und muss eine Anwendung, die er entwickelt, konfigurieren. Das kann ein kniffliger Prozess sein. Anstatt also viel Zeit damit zu verbringen, jede mögliche Konfiguration auszuarbeiten, macht er eine Google-Suche und findet jemanden, der bereits eine scheinbar perfekte Konfigurationsdatei fertiggestellt hat. Auch wenn der Entwickler nichts über die Person weiß, die den Code geschrieben hat, ist es relativ einfach, ihn zu einer neuen Anwendung hinzuzufügen. Es kann in der Docker-Umgebung mit zwei Zeilen erfolgen:

RUN cd /etc/apache2/sites-available/ && \
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf

Jetzt zieht das Docker-Image die Konfigurationsdatei eines Drittanbieters dynamisch ein. Und selbst wenn die Datei zu diesem Zeitpunkt getestet und für in Ordnung befunden wird, bedeutet die Tatsache, dass der Zeiger nun in den Code der neuen Anwendung eingebettet ist, dass eine permanente Abhängigkeit vorhanden ist. Tage, Wochen oder Monate später könnte die Datei vom ursprünglichen Autor oder einem Angreifer, der das Code-Repository kompromittiert hat, geändert werden. Plötzlich kann die freigegebene Konfigurationsdatei der Anwendung sagen, dass sie sich ganz anders verhalten soll als beabsichtigt, was möglicherweise unbefugten Benutzern Zugriff gewährt oder sogar direkt Daten stiehlt und exfiltriert.

Bessere Nutzung gemeinsamer Ressourcen

Wenn Ihre Organisation die Verwendung von Code aus externen Quellen zulässt, müssen Prozesse eingerichtet werden, um sicherzustellen, dass dies sicher geschieht. Wenn Sie fremden Code für eine mögliche Verwendung evaluieren, achten Sie darauf, dass Sie Komponenten aus offiziellen Quellen nur über sichere Links beziehen. Und selbst dann sollten Sie niemals eine Verbindung zu einer externen Quelle herstellen, um diesen Code einzuholen, da dies den Prozess Ihrer Kontrolle entzieht. Stattdessen sollte genehmigter Code in eine sichere Bibliothek eingebracht werden und nur von diesem geschützten Ort aus verwendet werden. In einer Docker-Umgebung würde der Code also wie folgt aussehen:

COPY src/config/default-ssl.conf /etc/apache2/sites-available/

Anstatt sich auf entfernte Konfigurationsdateien von Drittanbietern zu verlassen, würde dies stattdessen auf eine lokale Kopie dieser Dateien setzen. Dies verhindert, dass unerwartete oder böswillige Änderungen vorgenommen werden.

Zusätzlich zur Verwendung einer sicheren Code-Bibliothek sollte ein Patch-Management-Prozess eingerichtet werden, um Komponenten während des gesamten Software-Lebenszyklus kontinuierlich zu überwachen. Alle client- und serverseitigen Komponenten sollten außerdem mit Tools wie NVD oder CVE auf Sicherheitswarnungen überprüft werden. Schließlich sollten alle nicht genutzten oder unnötigen Abhängigkeiten und Funktionen entfernt werden, die möglicherweise mit dem externen Code einhergehen.

Wenn Sie diese Schritte befolgen, können Entwickler externe Ressourcen sicherer nutzen, ohne versehentlich Schwachstellen in ihre Anwendungen und ihren Code einzubringen.

Schauen Sie sich die Secure Code Warrior Blog-Seiten, um weitere Einblicke in diese Schwachstelle zu erhalten und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen anderer Sicherheitslücken schützen können. Sie können auch eine Demo der IaC-Herausforderungen auf der Schulungsplattform Secure Code Warrior ausprobieren, um alle Ihre Cybersecurity-Fähigkeiten zu schärfen und auf dem neuesten Stand zu halten.

Ein Entwickler in seinem natürlichen Lebensraum wird oft in einem Zustand tiefer Konzentration gesichtet, während er unter Zeitdruck fantastische Funktionen programmiert. Das Erstellen von Funktionen ist oft unser liebster Teil der Arbeit, und tatsächlich ist es das grundlegende Ergebnis des Softwareentwicklungslebenszyklus (SDLC).

Doch wie wir bereits besprochen haben, geben viele von uns immer noch den Funktionen den Vorrang vor den Best Practices für die Sicherheit. Schließlich ist es in den meisten Organisationen so eingerichtet, dass es die Aufgabe von jemand anderem ist, und eine angemessene Sicherheitsschulung für uns ist begrenzt. Penetrationstests und Scanning-Tools für die statische Analyse (besser bekannt als SAST) sind nur ein Teil des Gesamtprozesses zur Minderung von Sicherheitsrisiken und arbeiten ziemlich unabhängig von dem, was wir tun... bis der Code für Hotfixes zu uns zurückkommt, natürlich.

Und genau in diesem Moment denken viele Entwickler:"Hassen mich die Pentester?".

Diese Interaktionen definieren oft ein Team, eine Kultur. Das Beunruhigende ist, dass der Mangel an Kommunikation, Verständnis und allgemeiner Zusammenarbeit zu Spannungen geführt hat, zumindest auf der Seite der Entwickler. Denken Sie darüber nach: Stellen Sie sich vor, Sie haben ein paar hundert Stunden damit verbracht, eine wunderbare Statue zu formen, und dann kommt jemand mit einem Hammer daher und fängt an, Teile davon zu zerschlagen, nachdem er Ihnen gesagt hat, dass das Fundament nicht in Ordnung ist. Das ist die wahrgenommene Dynamik zwischen einem Tester und einem Entwickler - letzterer lässt seine Software-Lieblinge von einem Außenstehenden abschlachten, der sich nicht mit ihnen durch den Prozess gearbeitet hat; stattdessen hat er die Arbeitslast verlängert und die Zufriedenheit mit der Auslieferung des Codes verzögert.

Da ich vor langer Zeit in den Sicherheitsbereich gewechselt bin, kann ich beide Seiten der Geschichte sehen. Und nein, Pentester hassen keine Entwickler. Der Pentester ist höchstwahrscheinlich überarbeitet und steht unter einer Menge Druck. Daher nimmt ein ständiger Strom von gewöhnlichen Sicherheitsfehlern, die recht einfach auf Code-Ebene behoben werden könnten, Zeit, Ressourcen und den Kopf von den wirklich ernsten Problemen weg.

Ich habe Pentester immer als eine Art von Eltern gesehen. Sie wollen, dass man gut abschneidet, und wenn man es nicht tut, sind sie nicht sauer, nur enttäuscht.

Nun, da ich Ihnen dieses (vielleicht etwas unfaire) Bild in den Kopf gesetzt habe, lassen Sie uns das ein wenig tiefer ergründen. Was hat diese Weltanschauung unter Entwicklern verursacht?

"Natürlich werde ich defensiv; sie sagen mir, wie ich meinen Job machen soll!"

Niemand mag das Gefühl, dass er schlechte Arbeit geleistet hat oder dass jemand seine Arbeit nicht mag. Leider kann es sich für Entwickler wie ein Zeugnis anfühlen, wenn sie die Ergebnisse der statischen Analyse und des Pentests zurückbekommen. Sie haben schlechte Noten bekommen, aber am Ende des Tages bewerten ihre Chefs sie nach den Funktionen, die sie gebaut haben, und der Zeit, die sie dafür gebraucht haben, und nicht danach, ob es anfällige Elemente in der Software gab oder nicht.

Für den armen Pentester ist das ein Fall von "don't shoot the messenger". Es ist nichts persönliches - sie sind damit beauftragt, Fehler zu finden, und sie haben sie gefunden. Zugegeben, auf einer persönlichen Ebene, sind vielleicht einige Pentester mürrischer als andere, aber sie sind nicht darauf aus (oder sollten es nicht sein), die Entwickler Teams zu kreuzigen. Es wäre viel einfacher für beide Teams, wenn sie auf der gleichen Seite wären, was die beste Sicherheitspraxis ausmacht. Und von den Entwicklern wird nicht erwartet, dass sie perfekt sind; realistisch betrachtet, ist das Test-Team dazu da, sie vor der Auslieferung von anfälligem Code zu schützen.

"Sie haben mir gesagt, dass ich all diese kleinen Probleme beheben soll, wissen sie nicht, dass es höhere Prioritäten gibt? Und warum helfen sie mir nicht, sie zu beheben, wenn sie sich so sehr sorgen?"

Es ist wahr - die höchste Priorität eines Entwicklers wird immer die Erstellung von Funktionen sein, und in dieser verrückten Welt der schnellen Digitalisierung muss dies mit Geschwindigkeit geschehen. Während einige Programmierer ein persönliches Interesse an Sicherheit und sicherer Codierung haben, ist die allgemeine Stimmung, dass Sicherheit "das Problem von jemand anderem" ist, was unweigerlich Pentester einschließt.

Die meisten häufigen Schwachstellen sind in der Tat geringfügig zu beheben - sobald sie bekannt sind, sind die Korrekturen für Dinge wie Cross-Site-Scripting (XSS) und SQL-Injection einfach auszuführen... das Problem ist, dass viele Entwickler gar nicht merken, dass sie sie überhaupt einführen, und diese scheinbar geringfügigen Probleme sind das kleine Zeitfenster, das ein Angreifer braucht, um einem Unternehmen verheerende Probleme zu bereiten. Laut Akamai machten SQL-Injection-Schwachstellen zwischen November 2017 und März 2019 65 % aller webbasierten Angriffsvektoren aus. Für eine Schwachstelle, für die es seit mehr als zwanzig Jahren einen bekannten Fix gibt, ist das eine ernüchternde Statistik.

Einige Pentest-Teams helfen bei der Behebung von Sicherheitsfehlern, aber andere liefern einen Bericht mit den schlechten Nachrichten und erwarten von den Entwicklern, dass sie Hotfixes abarbeiten, auch wenn sie zu dem Zeitpunkt, an dem dies geschieht, bereits zu einem anderen Projekt gewechselt haben. Und in manchen Fällen wird das Entwicklungsteam mit einem Bericht konfrontiert, der Fehler enthält, die sie nicht beheben können (oder von denen man nicht erwarten sollte, dass sie behoben werden) - es muss trotzdem ein Teil der Ergebnisse sein, und wieder, nicht persönlich genommen werden.

Der "goldene Mittelweg" hierfür wäre, dass Pentester, Sicherheitspersonal und Entwicklungsleiter eher in einer Mentorenrolle agieren, um sicherzustellen, dass das Team über das verfügt, was es in Bezug auf effektive Schulungen und Tools benötigt, um den einzelnen Programmierern die beste Chance zu geben, erfolgreich zu sein und von Beginn des SDLC an sicher zu programmieren. Beide Teams sollten sich wirklich auf halbem Weg treffen, um sicherzustellen, dass die Sicherheit von Anfang an berücksichtigt wird, als Teil einer gesunden DevSecOps-Praxis.

"Ich habe viel bessere Sicherheitskenntnisse, als man mir zugesteht; diese Berichte sind meist falsch positiv oder nicht wichtig".

Die statische Analyse ist ein Element des Sicherheitsprozesses im SDLC, und Scan-Tools für die statische Analyse (SAST) spielen eine grundlegende Rolle. Und ja, falsch-positive Ergebnisse sind ein Problem bei diesen und anderen Arten von Scannern (DAST/IAST/RAST). Es ist ein Ärgernis in einem ohnehin schon langsamen Prozess, der manuelles Code-Review erfordert und sowohl Entwickler als auch Pentester unter Druck setzt. Die Pentesting-Mitarbeiter haben sich die Zeit genommen, akribisch benutzerdefinierte Regeln aufzustellen, um ungenaue Messwerte zu vermeiden und unternehmensspezifische Anleitungen zur Verfügung zu stellen, dennoch schlüpfen einige falsche Messwerte durch und landen vor einem kopfschüttelnden Entwickler.

Dieser Prozess ist nicht perfekt, aber das andere Problem ist, dass viele Entwickler nicht genug Wissen haben, um viele häufige Schwachstellen auf einer konsistenten Basis zu entschärfen. Da Sicherheitstrainings in der Hochschulausbildung selten sind und das Training am Arbeitsplatz in seiner Effektivität variiert, ist es naheliegend, dass auch eine gewisse Selbstüberschätzung im Spiel ist (und es ist nicht ihre Schuld - wir als Industrie müssen sie besser mit dem ausstatten, was sie brauchen).

"Ich wusste nicht, dass diese Anwendung getestet werden würde, aber jetzt stecke ich mit den Aufgaben zur Behebung fest".

Manchmal wird von überlasteten Ingenieuren angenommen, dass die Pentester nur in den Startlöchern stehen und auf den richtigen Moment warten, um eine Anwendung zu testen und dem Entwicklungsteam in die Parade zu fahren. Sie testen zu viel, sie sind pingelig, sie verursachen zusätzliche Arbeit.

Das einzige Problem dabei ist, dass auch sie überarbeitet sind (sogar noch mehr - der Fachkräftemangel im Bereich Cybersicherheit ist katastrophal und wird immer schlimmer) und einfach nicht die Zeit haben, ohne Grund zu testen. Sie sind nicht die alleinigen Entscheidungsträger bei der Priorisierung von Tests; es könnte von der Unternehmensleitung, einem Kunden, als Teil eines Sicherheitsaudits oder sogar als Ergebnis eines Bug Bounty-Programms bestimmt worden sein.

Für einen Entwickler ist es ärgerlich, wenn er aus einem laufenden Sprint für die Erstellung von Funktionen abgezogen wird, um an Sicherheitskorrekturen zu arbeiten - besonders wenn es nicht seine Arbeit ist. Vielleicht hat ein früheres Team das letzte Update durchgeführt, oder ein anderer Anbieter. Wie auch immer, Sicherheit ist das Problem von jedem. Das bedeutet nicht, dass jeder Entwickler die Verantwortung für Sicherheitsprobleme übernehmen muss, als ob er sie alle selbst gemacht hätte, aber sie müssen mitmachen, wenn es darum geht, dass Sicherheit eine gemeinsame Verantwortung ist.

Wohin von hier aus?

Manchmal reicht eine Änderung der Denkweise aus, um bei der Lösung eines Problems einen bedeutenden Schritt voranzukommen. Wir haben über die eher frostige Reaktion eines Entwicklers auf ungünstige Pentestergebnisse gesprochen, aber was wäre, wenn sie es in eine Herausforderung verwandeln könnten? Vielleicht könnten sie den Pentester als einen freundlichen Konkurrenten betrachten; jemanden, den sie in ihrem eigenen Spiel schlagen können. Schließlich wird ein sicherheitsbewusster Entwickler, der häufige Fehler beim Schreiben von Code beseitigen kann, seine Arbeit sehr viel schwieriger machen. Im Gegensatz dazu wird ein Entwickler, der keinen Fokus auf Sicherheit legt, von seinem Pentester-Kollegen umfassend besiegt werden, wenn dieser seine Software leicht brechen kann.

Pentester und Entwickler harmonieren vielleicht nicht immer zu 100 % miteinander, aber ihre Beziehung kann erheblich verbessert werden, wenn ein Unternehmen die Sicherheit als Hauptpriorität behandelt und die Teams mit dem richtigen Wissen und den richtigen Tools ausstattet, um erfolgreich zu sein - insbesondere die Entwickler. Es kommt darauf an, ob eine unternehmensweite, positive Sicherheitskultur eine Priorität ist, und wenn wir den (derzeit) aussichtslosen Kampf gegen verbreitete Schwachstellen bekämpfen wollen, sollte sie das unbedingt sein.

Eine Version dieses Artikels erschien in TFIR. Er wurde hier aktualisiert und syndiziert.

Man sagt, Veränderung sei die einzige Konstante im Leben, aber das Jahr 2020 hat für viele auf der ganzen Welt eine echte Bewährungsprobe gebracht. Die globale COVID-19-Pandemie hat uns gezwungen, auf einer tiefen Ebene darüber nachzudenken, wie wir uns verbinden. Selbstisolation, soziale Distanzierung - das waren einige der Anpassungen, die wir in der physischen Welt vorgenommen haben, und trotz der Tatsache, dass so viele von uns so viel Zeit online verbringen, ist es ein ganz anderes Szenario, keine andere Wahl zu haben, wenn es darum geht, zu kommunizieren und, wenn möglich, zu arbeiten. Es ist gleichzeitig eine Tragödie und ein Erwachen.

Wie bei vielen Tech-Unternehmen ist flexibles Arbeiten für uns nicht neu und das Arbeiten von zu Hause aus gehört zu den Vorteilen des Jobs. Schon "früh", im Jahr 2009, habe ich von Belgien aus für Unternehmen im Silicon Valley gearbeitet. Damals war die Technologie noch nicht so weit fortgeschritten, aber es war trotzdem machbar. Aber selbst für uns jetzt war es eine Umstellung, jedes einzelne Teammitglied bis auf Weiteres von zu Hause aus arbeiten zu lassen. Ich habe so viele Unternehmen gesehen, die diese Entscheidung ebenfalls getroffen haben, darunter auch viele, die nicht so gut auf das Management einer Remote-Belegschaft vorbereitet waren wie andere.

Ob das Unbehagen nun von den Unbekannten einer neuen Arbeitsweise kommt, von ein wenig Misstrauen oder vielleicht davon, nicht an Remote-Arbeit zu "glauben", ich finde, dass Unternehmen, die sich dagegen sträuben, dazu neigen, in Bezug auf die Gewinnung von Top-Talenten, die Aufrechterhaltung der globalen Reichweite und offen gesagt, mit der Zeit zu gehen, zurückzufallen. Die derzeitige Krise hat vielen keine andere Wahl gelassen, als auf Remote Workforce zu setzen, denn die Alternative wäre ein kompletter Stillstand des Geschäfts inmitten eines chaotischen Wirtschaftsklimas.

Wenn es etwas Positives gibt, das wir aus dieser Tragödie mitnehmen können, dann ist es, dass die Menschen die Vorteile einer digitalen Belegschaft erkannt haben und die unzähligen Möglichkeiten, wie ein Team zusammenarbeiten kann, obwohl es nicht physisch zusammen ist. Und die Cybersicherheitsbranche ist eine Branche, die von einem "work-anywhere, always-on"-Ansatz wirklich profitieren kann.

Angreifer haben sich nicht abgeschottet - sie sind reichlich aktiv und nutzen diese Krise aus, indem sie die weltweite Panik und Unsicherheit nutzen, um Cyberangriffe auf medizinische Einrichtungen durchzuführen. In einer Situation wie dieser ist es nicht weit hergeholt, einen Anstieg von Cyberangriffen zu sehen - insbesondere von Ransomware. Es ist schließlich Diebstahl, um in wirtschaftlich unsicheren Zeiten zu überleben. Das macht es nicht in Ordnung, und es bleibt die Tatsache, dass wir immer noch überall, wo es eine Internetverbindung gibt, arbeiten, trainieren und gegen Cyberangriffe kämpfen können.

Die Zukunft ist flexibel, und so können wir - und die gesamte Cybersicherheitsbranche - sie jetzt und in Zukunft gestalten:

Access-anywhere-Produkte sind universell und wertvoll

Vor jeder Art von erzwungener Quarantäne-Situation mussten globale Teams noch einen Weg finden, bei Bedarf zusammenzuarbeiten. Erschwingliche Telefonkonferenzen debütierten im selben Jahr wie die Rolling Stones (1964) - und zweifellos hatten diese frühen Anwender die gleichen "Bist du da? "Nein, mach du weiter" Probleme, mit denen wir heute konfrontiert sind, auch wenn wir uns gegenseitig auf Video sehen können).

Im Jahr 2020 ist die digitale Kommunikationstechnologie ein enormer Teil der Multi-Billionen-Dollar-ICT-Branche, wobei Cloud-native, mobile und soziale Plattformen dominieren und die alte Technologie ersetzen. Innovationen wie Slack, Zoom und Discord haben dafür gesorgt, dass wir mehr denn je miteinander verbunden sind, insbesondere bei der Arbeit. Und Kommunikation ist nur ein Aspekt der Geschichte.

Digitale Dienste, die überall mit einer Internetverbindung zugänglich sind, on-demand, die ein Grundbedürfnis erfüllen - sei es eine Verbindung, Unterhaltung, Produktivität - sind Teil unserer flexiblen Zukunft. Als Kunden streben wir selbst nach Hyper-Personalisierung, und als Unternehmen wollen wir ein persönliches, digitales Erlebnis bieten, das unabhängig vom Ort des Zugriffs dieselbe kompromisslose Qualität aufweist.

In jeder Branche werden täglich webbasierte Anwendungen entwickelt, um Prozesse zu rationalisieren, die bestehenden Lebens- und Arbeitsweisen zu revolutionieren und Probleme zu lösen, von denen wir vielleicht gar nicht wussten, dass wir sie haben. Wir sind noch lange nicht an der Spitze der Cybersicherheits-Tools und -Schulungen angelangt, auf die bei Bedarf zugegriffen werden kann, und zwar auf eine Art und Weise, die für den Benutzer ansprechend und nützlich ist, mit einem greifbaren Nutzen für das Unternehmen.

Entwickler schätzen Flexibilität bei ihrer täglichen Arbeit, und unser Fokus auf praktische, sichere Codierungsschulungen, die Spaß machen, sowie auf die Integration von Arbeitsabläufen wurde mit Blick auf diese Endbenutzer entwickelt. Die Tools sollten mühelos in die Hand genommen werden können, damit das wertvolle Training nicht als lästige Pflicht angesehen wird. Da die Cybersicherheitsbranche ein so großes Spielfeld ist, ist die Zeit reif für Innovationen in verschiedenen Angriffs- und Verteidigungsbereichen, in denen sicherheitsorientierte Methoden wie DevSecOps auch dann noch gedeihen können, wenn jeder zu Hause ist. Es geht um Zusammenarbeit und eine durchdachte Suite von Tools für jedes Teammitglied, damit es seine Arbeit unabhängig von seinem physischen Standort effektiv erledigen kann.

Training, wenn Sie es am meisten brauchen (oder wenn Sie Ihren Tag umstellen wollen)

Ein Vorteil des flexiblen Arbeitens ist, dass der Weg ins Büro an den Tagen, an denen Sie Aufgaben von zu Hause aus erledigen, wegfällt. Für manche könnte das etwa zwei Stunden an hochwertiger, konzentrierter Zeit zurückgewinnen. In einer idealen Welt hätten alle Mitarbeiter in ihrer normalen Arbeitszeit Zeit, um zu lernen und ihre Fähigkeiten weiterzuentwickeln, und dies kann in der richtigen Remote-Umgebung viel leichter bewältigt werden. Das kommt Ihren Remote-Superstars zugute, die sich durch weiteres Lernen herausgefordert und unterstützt fühlen können.

Da sich die Cybersicherheitslandschaft sekündlich ändert, sind regelmäßige Schulungen ein Muss, um mit potenziellen Bedrohungen, die das Unternehmen betreffen könnten, Schritt zu halten. Und umfassende, messbare Schulungen, die auf die Bedürfnisse des Unternehmens zugeschnitten sind, sind ein großer Schritt in die richtige Richtung. Dies waren einige der Kernfaktoren bei der Gestaltung der Plattform Secure Code Warrior ; wir wollten Schulungen, auf die man überall zugreifen kann, genau dann, wenn man sie braucht, in der Entwicklungssprache und dem Framework der Wahl des Benutzers.

Entwickler haben ein angespanntes Verhältnis zur Sicherheit, und in vielerlei Hinsicht wurden sie nicht spezifisch genug angesprochen, um sich richtig mit den Best Practices der Sicherheit auseinanderzusetzen. Dies ist auch wichtig, um sicherzustellen, dass Offshore-Teams und Zulieferer ebenfalls ein angemessenes Sicherheitsbewusstsein haben, insbesondere wenn sie an der Software eines Unternehmens basteln.

Das Engagement und die Weiterbildung Ihrer Mitarbeiter mit Schulungen, die dem Unternehmen helfen (ganz zu schweigen von ihrer eigenen Karriere), ist ein sehr effektiver Klebstoff, wenn es darum geht, Ihre besten und loyalsten Talente zu halten... eine absolute Notwendigkeit, da wir mit einem anhaltenden Fachkräftemangel im Bereich Cybersecurity konfrontiert sind.

Remote-Arbeitskräfte können befähigt, produktiv und sicher sein

Es ist eine ziemlich altmodische Position, dass man von neun bis fünf in einem Büro sichtbar sein muss, um produktiv zu sein. Und doch arbeiten so viele Unternehmen (sogar einige der neuen, aufregenden) immer noch mit dieser Vorstellung im Kopf. Es herrscht ein tiefes Misstrauen gegenüber der eigenen Belegschaft, als ob die bloße Andeutung, von zu Hause aus zu arbeiten, dazu führt, dass sie sich vorstellen, dass ihre Teams in ihrer Unterwäsche spielen, anstatt ihre Arbeit zu erledigen.

Entweder das, oder sie haben einfach noch nicht den Schritt in eine praktikable Fernarbeit gewagt.

Natürlich müssen die Teammitglieder beweisen, dass sie ihre Produktivität auch zu Hause aufrechterhalten können, indem sie Leistung zeigen, aber Sie müssen Ihrer Kohorte die beste Chance geben, auch außerhalb des Büros erfolgreich zu sein. Fragen Sie sich selbst:

• Haben sie die passende Hardware?
• Haben Sie tatsächlich eines dieser großartigen Kommunikationswerkzeuge implementiert, über die wir zuvor gesprochen haben?
• Haben Sie sichergestellt, dass jeder Manager sich regelmäßig bei seinem Team meldet und digital präsent ist, mit regelmäßigen Stand-ups?
• Haben Sie über Produktivitäts-Tools nachgedacht, um den Überblick über Projekte zu behalten und jedem Teammitglied bei der Erledigung von Aufgaben eine Richtung, Zielsetzung und ein Gefühl der Erfüllung zu geben?

Im aktuellen Klima standen viele Unternehmen vor der Entscheidung, den Betrieb aus der Ferne zu führen oder ganz zu schließen. Einige Unternehmen, die sich für die Umstellung auf eine dezentrale Belegschaft entschieden haben, waren vielleicht nicht ganz so gut vorbereitet, und es ist möglich, dass es noch einige Macken auszubügeln gibt... aber der Elefant im Raum ist, dass diese Unternehmen sich wahrscheinlich auch einigen Sicherheitsrisiken aussetzen.

Vermeiden von Sicherheitsfehlern in Remote-Arbeitsumgebungen

Es gibt mehrere Bedrohungsvektoren zu berücksichtigen, da die Mitarbeiter wahrscheinlich in ihrem eigenen Netzwerk arbeiten und möglicherweise eine Reihe von Geräten für den Zugriff auf Firmenkonten verwenden, von denen jedes seine eigenen Sicherheitsanforderungen hat, die möglicherweise in Kraft sind oder nicht.

In Situationen, in denen Mitarbeiter an entfernten Standorten arbeiten, erhält jeder tendenziell mehr E-Mails und muss sich zudem mit verschiedenen Logins, Systemen und Einstellungen auseinandersetzen. Es ist nur allzu leicht, dass sozial konstruierte Angriffe und Malware auf einer Reihe von Geräten, die nicht in den Bereich der internen Sicherheit fallen, durch die Maschen schlüpfen. Dies ist kein Grund, die Remote-Arbeit aufzugeben, sondern eine einmalige Gelegenheit, aus der Praxis zu lernen und sie für die Zukunft so robust wie möglich zu machen. Und in sicherheitsorientierten Organisationen ist dies eine gute Gelegenheit, Prozesse zu überprüfen und "sein eigenes Hundefutter zu essen", wenn es um Best Practices im Bereich Sicherheit für alle geht.

Apropos Fehler: Es ist auch wichtig, Ihren Remote-Arbeitsbereich auf potenzielle Gefahren zu prüfen... vor allem für Ihren Stolz, wie dieses arme Paar. Die Moral von der Geschichte: Stellen Sie sicher, dass jeder bei einem Videoanruf eine Hose trägt.

Cyberangriffe hören nicht auf, nur weil wir uns in einer Krise befinden

Es ist zutiefst erschütternd, die Auswirkungen von COVID-19 auf der ganzen Welt zu sehen, und jetzt ist mehr denn je die Zeit, an einem Strang zu ziehen und an andere Menschen in dieser globalen Gesundheitskrise zu denken. Die Sache ist die, dass die Angreifer diese weit verbreitete Angst und Pandemie aktiv ausnutzen, vielleicht aus Verzweiflung, um Essen auf den Tisch zu bringen. Wir als Gesellschaft sind in dieser Zeit unglaublich verwundbar.

Einrichtungen des Gesundheitswesens, darunter auch ein Testzentrum für Impfstoffe, wurden mit Ransomware und DDoS-Angriffen heimgesucht, ganz zu schweigen von denen, die versuchen, abgelenkte und überlastete Finanz- und Regierungsorganisationen auszunutzen, indem sie Phishing- und Malware-Kampagnen gegen sie starten. Eine weitere drohende Gefahr betrifft den Impfstoff selbst; es wurde berichtet, dass die Trump-Administration einer deutschen Firma hohe Geldsummen angeboten hat, um einen COVID-19-Impfstoff für die ausschließliche Verwendung durch die USA zu entwickeln. Die Impfstoffdaten sind möglicherweise die wertvollsten Informationen, die es derzeit auf der Erde gibt, was für einen Angreifer ein sehr attraktives Kopfgeld darstellen würde.

Dies ist eine allzu aktuelle Erinnerung daran, dass, während wir uns selbst von der sehr realen Bedrohung durch einen physischen Virus isolieren, auch unser digitaler Herzschlag angegriffen wird. Das Sicherheitsbewusstsein ist in jeder Organisation von größter Bedeutung, und auf jeder Ebene sollten angemessene Schulungen angeboten werden - selbst Maßnahmen wie die Durchsetzung der Verwendung von Passwortverwaltungstools und das Erkennen von Phishing-E-Mails sind hilfreich.

Und wenn es um Entwickler geht, sind sie die erste Verteidigungslinie bei der Absicherung des aktiv im Unternehmen produzierten Codes. Sie können zusammen mit Ihrem AppSec-Team ein wertvoller Aktivposten sein, wenn es darum geht, weiteren Schmerz durch einen Cyberangriff zu vermeiden, indem sie die durch häufige Schwachstellen geschaffenen Hintertüren schließen.

Unternehmen, die digital innovativ sind, können größere Stürme überstehen

Ein äußerst unglückliches Nebenprodukt der Massensperre war der wirtschaftliche Abschwung, der viele Menschen in den am härtesten betroffenen Sektoren aus ihren Jobs zwang. Das alles hat sich ziemlich plötzlich zugespitzt, und es ist eine Erfahrung, die viele von uns wahrscheinlich noch nicht in ihrem Leben gemacht haben.

Zwar ist nicht jedes Digital Native Business ein automatischer Rezessionsbuster (bei weitem nicht), aber von Natur aus sind Unternehmen, die im digitalen Bereich tätig sind, weitaus agiler, anpassungsfähiger und nachhaltiger, wenn selbst die widrigsten Umstände eintreten.

Unser Unternehmen kann effizient und effektiv mit einer dezentralen Belegschaft betrieben werden, und das ist ein zusätzlicher Schutz für unser geschätztes Team und die Kunden, die sie ebenfalls unterstützen. Wir betrachten praktikable, sichere Code-Schulungen als einen wesentlichen Bestandteil moderner Unternehmen, und wenn wir ausgewählt werden, können wir liefern und bei Bedarf umschwenken. Viele Unternehmen haben aufgrund der Art der Produkte oder Dienstleistungen, die sie verkaufen, nicht den gleichen Luxus, aber es kann eine positive Überraschung für sie sein, zu untersuchen, wo Prozesse digitalisiert, zukunftssicher und so bedarfsgerecht wie möglich gemacht werden können, selbst in den traditionellsten Bereichen.

Neue Wege zur Verbindung zu finden ist eine positive Herausforderung, kein Hindernis

Es ist ein bisschen dramatisch, aber ich fühle mich an das berühmte Zitat aus Jurassic Park erinnert, wo Dr. Ian Malcolm sagt: "Das Leben findet einen Weg". Das tut es wirklich, und das hat sich bei unserer unternehmensweiten Umstellung auf Remote-Arbeit sehr deutlich gezeigt. Teams, die vorher nicht viel miteinander zu tun hatten, entdecken jetzt gemeinsame Interessen in gelegentlichen Watercooler-Chats, Online-Bürospielen und einer gemeinsamen Spotify-Playlist für das gesamte Büro. Es gibt immer einen Weg, eine sinnvolle Beziehung aufzubauen, und mein Rat ist, die Teams dies erkunden und organisch damit wachsen zu lassen.

Für unsere Kunden war es großartig zu sehen, dass ihr Engagement für die Verbesserung der sicheren Programmierfähigkeiten unter den Entwicklern jegliche Probleme bei der Fernarbeit überwunden hat. Sie haben unsere tournaments Funktion genutzt, und während diese normalerweise persönlich mit ein wenig Fanfare durchgeführt werden, haben ihre virtuellen Versionen ein gesundes Engagement, einen freundlichen Wettbewerb und eine ausgezeichnete (produktive) Ablenkung von den täglichen Aktivitäten, die normalerweise alleine durchgeführt werden, gefördert. Ähnlich wie Videospiele heute ein viel sozialeres Ereignis sind als früher, fördert diese Art von Training am Arbeitsplatz die Verbindung nicht nur mit dem Kursmaterial, sondern auch mit den anderen Teilnehmern. Und es ist für jeden verfügbar, überall. Als Sicherheitsfanatiker bin ich definitiv voreingenommen, aber hey, das ist so gut wie jeder andere Zeitpunkt, um die Liebe zu sicherem Coding unter Entwicklern zu fördern. Sie sind alle Sicherheits-Superhelden im Wartestand, und es ist an der Zeit, Ihre Frontlinien auf die unterhaltsamste Art und Weise zu verstärken.

Eine Version dieses Artikels erschien in DevOps.de. Er wurde für die Syndizierung hier aktualisiert und enthält interaktive Links zu Schwachstellenherausforderungen.

Ich denke, wir alle können uns an ein Ereignis aus der jüngeren Vergangenheit erinnern, bei dem jemand in einem Meeting oder auf einer Konferenz Probleme mit der Präsentationstechnik hatte. Das passiert so oft, dass man fast schon eine klobige Erfahrung erwartet, zumindest am Anfang. Es ist daher keine Überraschung, dass die nahtlose App von ClickShare bei den Endanwendern sofort beliebt war. Für sie gibt es nichts Einfacheres als eine ClickShare-Anwendung zu verwenden, um eine Präsentation von ihrem Laptop, Tablet oder Smartphone auf eine große Leinwand oder einen Konferenzraumprojektor zu übertragen. Der in Belgien ansässige Anbieter von digitaler Projektions- und Bildtechnologie Barco hat seine Automatisierungsplattform so konzipiert, dass sie auf diese Weise funktioniert, und die großen Unternehmen haben das Konzept angenommen. FutureSource Consulting beziffert den Marktanteil von Barco im Bereich Konferenztechnologie auf 29 %, mit einer Integration in 40 % aller Fortune-1.000-Unternehmen.

Als Forscher von F-Secure im Dezember aufdeckten, dass die scheinbar harmlose Automatisierungsplattform mit Sicherheitslücken gespickt war, ging ein Ruck durch die Geschäftswelt. Die aufgedeckten Sicherheitslücken sind kritischer Natur und könnten potenziell jede Menge bösartige Aktivitäten ermöglichen.

Die Forscher demonstrierten, wie die Schwachstellen es Remote-Benutzern ermöglichen könnten, aktive Präsentationen auszuspähen, Hintertüren in sichere Netzwerke zu schaffen oder sogar einen Spyware-Verteilungsserver zu konfigurieren, der jeden Benutzer infiziert, der sich mit einem Barco-Gerät verbindet. Plötzlich sahen sich Unternehmen mit der Aussicht konfrontiert, ernsthafte Sicherheitsprobleme direkt in den Konferenzräumen und Büros ihrer Organisation installiert zu haben. Und aufgrund der Art der Schwachstellen konnte ein einziges kompromittiertes Gerät einen netzwerkweiten Einbruch unterstützen.

"Ein Angreifer, der ein Gerät erfolgreich kompromittiert hat, erhält die Möglichkeit, es zu entschlüsseln und gültige verschlüsselte Bilder für jedes beliebige Gerät zu erstellen, egal ob innerhalb einer Familie oder familienübergreifend", schreiben die Verantwortlichen von F-Secure in ihrem Bericht. "Außerdem kann ein solcher Angreifer Zugriff auf sensible Daten im Ruhezustand erhalten, wie z. B. den konfigurierten Wi-Fi-PSK und Zertifikate."

Barco hat sehr proaktiv Patches und Fixes für die in seinen Produkten gefundenen Sicherheitslücken herausgegeben. Der Sicherheitsanbieter Tenable hat kürzlich einen Bericht veröffentlicht, der 15 Schwachstellen in acht Präsentationstools, einschließlich Barco, aufzeigt. Seit Februar hat nur Barco aktiv Fixes bereitgestellt.

Obwohl einige der Barco-Schwachstellen Hardware-Änderungen erfordern (und diese zu implementieren ein Alptraum sein wird, wenn ein Unternehmen in diesem Ausmaß handelt, um sie überhaupt zu sichern), können viele von ihnen mit Software-Patches korrigiert werden. Das gibt den meisten Unternehmensanwendern einen scheinbar guten Plan, um ihre unmittelbaren Probleme zu beheben, aber sie sind jetzt kaum im Reinen. Die Probleme mit Barco sind nur die Spitze des Eisbergs, wenn es um den Umgang mit Sicherheitslücken in bekannten Hard- und Softwareprodukten geht.

Die Wurzel des Problems

Nun, da die unmittelbaren Probleme gelöst sind, müssen wir uns fragen, wie Geräte mit schwerwiegenden Sicherheitslücken in Tausenden von Konferenzräumen weltweit gelandet sind, oder warum sie überhaupt so schlecht konzipiert und programmiert wurden. Es ist ja nicht so, dass das F-Secure-Team Zero-Day- oder bisher unbekannte Schwachstellen aufgedeckt hätte. Zehn der in den Barco-Produkten entdeckten Schwachstellen standen im Zusammenhang mit bekannten, weit verbreiteten Sicherheitslücken wie Code-Injection-Angriffen. Für die meisten gab es bereits CVE-Kennungen (Common Vulnerabilities and Exposures).

Wie konnten also jahrzehntealte CVEs in moderne Präsentationstools codiert oder sogar fest verdrahtet werden? Die einzig mögliche Antwort ist, dass die Entwickler entweder nichts von ihnen wussten oder dass die Sicherheit bei der Entwicklung der Barco-Geräte keine Priorität hatte. Leider ist dies eine häufige Situation, und sicherlich nicht nur bei den Barco-Teams.

Der beste Zeitpunkt, um eine Schwachstelle zu beheben, ist während der Entwicklung einer Anwendung, lange bevor sie an die Benutzer ausgeliefert wird. Der schlechteste (und teuerste) Zeitpunkt ist, nachdem ein Produkt bereitgestellt wurde oder nachdem es von Angreifern ausgenutzt wurde. Dies kann eine harte Lektion sein, und eine, die Barco sicherlich lernen wird, da sein einst undurchdringlicher Marktanteil nach diesem Sicherheitsfiasko einen Einbruch erleidet.

Die Verlagerung von Sicherheitskorrekturen zurück in den Entwicklungsprozess ist nicht einfach, aber notwendig in der heutigen Welt, in der selbst scheinbar einfache Geräte wie Präsentationstools sowohl überraschend komplex als auch mit allem anderen vernetzt sind. In dieser Umgebung muss Sicherheit zu einer organisatorischen Best Practice werden. Es spielt keine Rolle, ob ein Unternehmen Apps für soziale Medien programmiert oder intelligente Toaster herstellt, Sicherheit muss in jeder Facette einer Organisation berücksichtigt werden.

Das Ziel der DevSecOps-Bewegung ist es, bewährte Sicherheitspraktiken zu priorisieren und sie zu einer gemeinsamen Verantwortung zu machen. Dazu ist ein Kulturwandel ebenso notwendig wie alles andere. Die neue Denkweise muss sein, dass die Bereitstellung eines funktionierenden Produkts mit Sicherheitslücken genauso ein Fehler ist wie die Erstellung eines Produkts, das seine Hauptfunktion nicht erfüllen kann.

In einer gesunden DevSecOps-Umgebung sollte jeder, der mit Software in Berührung kommt, sicherheitsbewusst sein, wobei die Entwickler relevante und häufige Schulungen erhalten, um zu vermeiden, dass sie katastrophale Fehler in ihre Arbeit einbringen. Hätten die Teams, die für Barco arbeiteten, Sicherheit als gemeinsame Verantwortung betrachtet, hätte es auf keinen Fall eine so große Sammlung von Schwachstellen, einschließlich jahrzehntealter CVEs, in ihre Präsentationstools geschafft.

Der sichere Weg nach vorn

Niemand möchte der nächste Barco sein, der erklären muss, warum bekannte Sicherheitslücken über seine Geräte in Tausende von Unternehmensnetzwerken auf der ganzen Welt verbreitet wurden. Um dieses Schicksal zu vermeiden, sollten Unternehmen, die Software oder intelligente Hardware entwickeln, der Sicherheit sofort Priorität einräumen, sowohl als gemeinsame Verantwortung als auch als organisatorische Best Practice. Die Schaffung eines gesunden DevSecOps-Programms wird Zeit in Anspruch nehmen und wahrscheinlich auch einen Kulturwandel erfordern, aber die Ergebnisse werden die Mühe mehr als wert sein. Robuste DevSecOps können Schwachstellen ausmerzen, lange bevor sie Probleme verursachen.

Für Unternehmen, die Produkte und Software kaufen, ist es in ihrem besten Interesse, Firmen zu unterstützen, die DevSecOps eingeführt haben. Auf diese Weise können sie sicherstellen, dass die von ihnen erworbenen Geräte und Software keine tickenden Zeitbomben sind, die darauf warten, von immer geschickteren Angreifern ausgenutzt zu werden.

Schauen Sie sich die Secure Code Warrior Blog-Seiten, um weitere Einblicke in DevSecOps zu erhalten und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen von Sicherheitslücken und Schwachstellen schützen können.

Möchten Sie einen tiefen Einblick in die Sicherheitsprobleme bei Barco erhalten?

Spielen Sie diese gamifizierten Herausforderungen auf:

• OS-Befehlsinjektion in C
• Entfernte Code-Injektion in C
• Pufferüberlauf in C
• Remote File Upload in C
• Anmeldeinformationen im Klartext in C gespeichert.

Die Bedrohungen für die Cybersicherheit sind heutzutage allgegenwärtig und unerbittlich. Es ist so schlimm geworden, dass der Versuch, mit ihnen Schritt zu halten, nachdem Programme bereitgestellt wurden, fast unmöglich geworden ist. Stattdessen setzen kluge Unternehmen auf das Konzept "Infrastructure as Code", bei dem Entwickler bereits während der Erstellung von Anwendungen zu deren Sicherheit beitragen. In dieser Serie geht es darum, Sie auf die Sicherheit vorzubereiten, damit Sie die Schritte verstehen, die Sie als Entwickler unternehmen können, um mit der Bereitstellung einer sicheren Infrastruktur als Code in Ihrer eigenen Organisation zu beginnen.

Sicherheitsfehlkonfigurationen, insbesondere solche der Sorte "falsche Berechtigungen", treten am häufigsten auf, wenn ein Entwickler einen neuen Benutzer anlegt oder einer Anwendung als Werkzeug Berechtigungen erteilt, um eine Aufgabe zu erfüllen. Dies könnte zum Beispiel geschehen, um Informationen aus einer Datenbank zu sammeln. Wenn jedoch die Berechtigungen für den neuen Benutzer zu hoch angesetzt oder nicht standardmäßig für die jeweilige Aufgabe konfiguriert sind, kann dies eine ernsthafte Schwachstelle in den Code einbringen.

Bevor wir dazu kommen, testen Sie doch gleich mal Ihre Fähigkeiten. Versuchen Sie, einige unzulässige Berechtigungsschwachstellen zu finden und zu beheben:

Wie haben Sie abgeschnitten? Lassen Sie uns ein wenig tiefer graben:

Einem Benutzer oder einer Anwendung volle Rechte zu geben oder sich einfach nicht die Mühe zu machen, zu definieren, was der neue Benutzer tun können soll und welche Verhaltensweisen eingeschränkt sind, ist sicherlich der schnellste Weg, um neuen Code einzuführen. Und wenn alles perfekt läuft, wird die Anwendung diese Berechtigungen nutzen, um die ihr zugewiesene Aufgabe zu erfüllen. Die Gefahr besteht darin, dass ein Hacker diesen Prozess entdeckt und dann den Benutzer kompromittiert. Auch wenn der Benutzer erstellt wurde, um eine bestimmte Funktion für eine bestimmte Anwendung zu erfüllen, kann er, wenn er kompromittiert wurde, einem Angreifer ermöglichen, andere Anwendungen, Daten oder sogar das Netzwerk zu gefährden.

Wie werden Sicherheitsfehlkonfigurationen ausgenutzt?

Um die Gefahr zu veranschaulichen, lassen Sie uns einen Blick darauf werfen, wie eine häufige Aufgabe manchmal innerhalb der Docker-Cloud-Umgebung kodiert wird. Nehmen wir an, dass ein Entwickler den Prometheus MySQL Exporter-Dienst verwendet, um Informationen aus einer Datenbank zu sammeln. Der einfachste Weg, dies zu ermöglichen, besteht darin, dem Exporter die Berechtigung zum Zugriff auf die Datenbank zu erteilen. Der Code könnte also etwa so aussehen:

FROM mysql:latest
COPY ./scripts/create_users.sh /docker-entrypoint-initdb.d/
USER 999
CREATE USER exporter@% IDENTIFIED BY $EXPORTER_PASSWORD;
GRANT ALL ON *.* TO exporter@%;
GRANT SELECT ON performance_schema.* TO exporter@%;

Dies würde sicherlich dafür sorgen, dass der Exporteur seine Aufgabe erfüllen kann. Da die Berechtigungen jedoch nicht definiert sind, hat der Exporteur tatsächlich die Möglichkeit, fast alles zu tun. Natürlich würde der Exporteur selbst niemals außerhalb seiner programmierten Verhaltensweisen handeln. Was würde aber passieren, wenn ein Angreifer in der Lage wäre, den Exporter-Dienst zu kompromittieren? In diesem Fall könnte der Angreifer, da ihm volle Rechte eingeräumt wurden, alle Arten von nicht autorisierten Aufgaben mit dem SQL-Dienst durchführen.

Sichern und Beseitigen von unzulässigen Berechtigungen

Auch hier wenden wir uns dem Konzept der Infrastruktur als Code zu. Wenn Sie die Sicherheit in Ihre Anwendungen codieren, während diese erstellt werden, dann wird das Netzwerk immer auf einer viel besseren Gesamtbasis stehen, wenn es um Cybersicherheit geht.

Wenn ein Entwickler im obigen Docker-Beispiel möchte, dass der Prometheus-MySQL-Exporter eine Datenbank abfragen kann, dann kann er das sicherer machen, indem er definiert, was er dürfen soll. Ein gutes Beispiel hierfür wäre:

FROM mysql:latest
COPY ./scripts/create_users.sh /docker-entrypoint-initdb.d/
USER 999
CREATE USER exporter@% IDENTIFIED BY $EXPORTER_PASSWORD;
GRANT PROCESS, REPLICATION CLIENT ON *.* TO exporter@%;
GRANT SELECT ON performance_schema.* TO exporter@%;

In diesem Fall hat der für den Prometheus-MySQL-Exporter-Dienst konfigurierte MySQL-Benutzer nur eingeschränkte Rechte für den MySQL-Dienst. Insbesondere sind nur die Berechtigungen PROCESS und REPLICATION CLIENT erlaubt. Dies würde einen böswilligen Benutzer daran hindern, einen kompromittierten Prometheus-MySQL-Exporter-Dienst auszunutzen.

Die Einschränkung von Berechtigungen auf Code-Ebene kann sicherstellen, dass Benutzer und Anwendungen nur genügend Berechtigungen für die jeweilige Aufgabe haben. Und das kann einen großen Beitrag zur Sicherung Ihrer Netzwerke und zur Umsetzung des Konzepts "Infrastruktur als Code" leisten.

Besuchen Sie die Secure Code Warrior Blog-Seiten, um mehr über diese Schwachstelle zu erfahren und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Folgen anderer Sicherheitslücken schützen können. Sie können auch unseren Showcase der Schulungsplattform Secure Code Warrior ausprobieren, um alle Ihre Cybersecurity-Fähigkeiten zu verfeinern und auf dem neuesten Stand zu halten.

Wenn Sie ein Entwickler sind, der mehr über die Schritte erfahren möchte, die Sie unternehmen können, um mit der Bereitstellung einer sicheren Infrastruktur als Code (IaC) in Ihrem Unternehmen zu beginnen, dann sind Sie hier genau richtig. Dies ist das nächste Kapitel unserer IaC-Reihe, das Sie in die Best Practices für IaC-Sicherheit einführen soll.

Bevor wir beginnen, wie sind Sie mit der Herausforderung aus der letzten Folge zurechtgekommen? Wenn Sie die unsichere Kryptografie beherrschen, lassen Sie uns sehen, wie Sie mit dem unzureichenden Schutz der Transportschicht zurechtkommen, bevor wir uns den Details widmen:

Möchten Sie mehr erfahren und eine perfekte Punktzahl erreichen? Lesen Sie weiter:

In unserem letzten Artikel haben wir darüber gesprochen, wie wichtig eine sichere Verschlüsselung ist, um alle wichtigen oder persönlichen Daten zu schützen, die von Anwendungen und Programmen gespeichert werden. Wenn Sie über eine starke Verschlüsselung verfügen, fungiert sie als perfekte letzte Verteidigungslinie. Selbst wenn ein Angreifer in der Lage ist, diese Daten zu stehlen, sind die in diesen Dateien gespeicherten Informationen geschützt, wenn sie stark verschlüsselt sind.

Der Schutz von Daten im Ruhezustand ist jedoch nur ein Teil einer vollständigen Datenverteidigung. Wann immer gültige Benutzer auf geschützte Daten zugreifen müssen, müssen diese an sie gesendet werden. Gelegentlich werden Anwendungen auch Daten mit anderen Programmen als Teil einer Gesamtarbeitslast austauschen. Wenn die Transportschicht nicht geschützt ist, ist sie sowohl für das Ausspähen von außen als auch für unautorisierte interne Zugriffe anfällig. Daher kann ein unzureichender Schutz der Transportschicht zu ernsthaften Problemen führen.

Es ist ein weit verbreitetes Problem. Die Sicherheitsorganisation OWASP unterhält sogar eine ganze Seite über unzureichenden Transportschichtschutz.

Warum ist ein unzureichender Schutz der Transportschicht gefährlich?

Wenn Sie Ihre Transportschichten nicht ausreichend schützen, ist es für geschickte Hacker relativ einfach, Informationen, die zwischen Ihren Benutzern und Ihren Anwendungen fließen, mit Techniken wie Man-in-the-Middle-Angriffen abzufangen. Der wahrscheinlich gefährlichste Aspekt dieser Art von Schnüffelei ist, dass sie für interne Cybersicherheitsplattformen oder Scans fast völlig unsichtbar ist, da sie außerhalb Ihres Netzwerks und Ihrer Kontrolle stattfindet.

Zum Beispiel in einer Docker-Umgebung, in der ein Nginx-Dienst bereitgestellt wird:

services:
nginx:
image: localhost:5000/scw_nginx
build: ./nginx
secrets:
- nginx_cert
- nginx_key
volumes:
- type: bind
source: ./nginx/nginx.conf
target: /etc/nginx/nginx.conf
read_only: yes
ports:
- 80:8443
networks:
- frontend
deploy:
restart_policy: *default-restart_policy
resources: *default-resources_policy

Die Nginx-Dienstkonfiguration verschlüsselt oder schützt die Verbindung nicht, wodurch alle über die Verbindung ausgetauschten Informationen anfällig für eine Vielzahl von Angriffen oder Schnüffeleien sind.

server {
       server_name scw-dev-blog.org;
       listen 8443;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
       }
   }

Oftmals ist das erste Signal, dass jemand in Ihren Transportschichten schnüffelt, wenn eine große Anzahl gestohlener Benutzerpasswörter in nachfolgenden Angriffen verwendet wird. Wenn andere Daten wie Kundeninformationen, Finanzdaten oder wichtige Firmengeheimnisse über eine unsichere Transportschicht gestohlen werden, merken Sie vielleicht nicht einmal, dass Sie kompromittiert wurden.

Und es ist nicht nur die Transportschicht zwischen Benutzern und Anwendungen, die geschützt werden muss. Am Backend kommunizieren viele Anwendungen untereinander und mit Servern, die weiter hinten in der Workflow-Kette stehen. Diese interne Kommunikation ist zwar in der Regel nicht anfällig für das Ausspähen von außen, kann aber Daten für Benutzer offenlegen, die zwar Zugang zum Netzwerk haben, aber nicht autorisiert sind, bestimmte streng geschützte oder sensible Informationen einzusehen.

Ordnungsgemäße Sicherung der Transportschichten für vollständigen Datenschutz

Der Schutz von Transportschichten wird am besten während der Erstellung von Anwendungen vorgenommen. Dieser Prozess beginnt damit, eine sichere Backend-Infrastruktur zu haben. Für Websites sollte alles über HTTPS erfolgen. Mischen Sie niemals HTTP- und HTTPS-Infrastruktur. Sie sollten Ihre Websites sogar so einstellen, dass ungesicherte HTTP-Anfragen automatisch an die HTTPS-Infrastruktur weitergeleitet werden.

In dem Beispiel von oben wäre eine korrekte Methode zum Schutz der Transportschicht folgende:

server {
       server_name scw-dev-blog.org;
       listen 8443 ssl;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
       }
   }

In diesem Beispiel sind alle Verbindungen mit dem Nginx-Dienst stark verschlüsselt. Der Server-Abschnitt der Nginx-Konfiguration enthält nur listen 8443 ssl , um SSL zum Schutz der Verbindungen zu erzwingen.

Um Ihre Daten vor Insider-Bedrohungen zu schützen, sollten Entwickler ein starkes Transportschicht-Verschlüsselungsprotokoll wie TLS 1.2 verwenden. Sobald Sie TLS 1.2 oder ein gleichwertiges Protokoll einsetzen, sollten schwächere Protokolle wie SSL v2 vollständig aus Ihrer Infrastruktur entfernt und automatisch von der Verwendung ausgeschlossen werden.

Und denken Sie immer daran, dass die Absicherung einer Anwendung erst dann vollständig ist, wenn sowohl die Daten im Ruhezustand als auch die Transportschichten ausreichend geschützt sind. Auf diese Weise können Sie einen vollständigen Ende-zu-Ende-Schutz für Daten sowohl intern als auch bei der Weitergabe an autorisierte externe Benutzer gewährleisten.
Besuchen Sie die Secure Code Warrior Blog-Seiten, um mehr über diese Schwachstelle zu erfahren und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Folgen anderer Sicherheitslücken schützen können. Sie können auch eine Demo der Schulungsplattform Secure Code Warrior ausprobieren, um alle Ihre Cybersecurity-Kenntnisse zu schärfen und auf dem neuesten Stand zu halten.