Kluge Unternehmen setzen auf das Konzept "Infrastruktur als Code", und es sind Entwickler wie Sie, die einen wichtigen Beitrag zur Erstellung von sicherem Code leisten können, auch außerhalb der Erstellung einer Anwendung. Der Weg dorthin mag zunächst lang erscheinen, aber er lohnt sich, wenn Sie sich von Ihren Mitstreitern abheben wollen.

Bevor wir mit dem nächsten Kapitel unserer aktuellen "Coders Conquer Security"-Serie beginnen, möchte ich Sie einladen, eine gamifizierte Herausforderung zur Schwachstelle bei der Speicherung sensibler Daten zu spielen; spielen Sie jetzt und wählen Sie zwischen Kubernetes, Terraform, Ansible, Docker oder CloudFormation:

Wie war das? Wenn Ihr Wissen etwas Arbeit braucht, lesen Sie weiter:

Heutzutage ist die Verschlüsselung von kritischen Daten wie Passwörtern, persönlichen Informationen und Finanzdaten im Ruhezustand ein Eckpfeiler jeder Cybersicherheitsverteidigung. In vielerlei Hinsicht fungiert sie sowohl als letzte Verteidigungslinie als auch als eine der besten Arten des Schutzes. Denn selbst wenn ein Angreifer in der Lage ist, andere Verteidigungsmaßnahmen zu durchbrechen und an kritische Dateien zu gelangen, solange diese ordnungsgemäß gehasht und gespeichert sind, wird ihm das nicht viel nützen.

Dies dient auch als solider sekundärer Schutz gegen böswillige Insider, da verschlüsselte Dateien separate Schlüssel oder Passwörter vom Rest des Netzwerks haben können. In diesem Fall könnte jemand wie ein Systemadministrator oder ein Hacker, der die Anmeldeinformationen eines Administrators kompromittiert hat, in der Lage sein, ein geschütztes Verzeichnis zu durchsuchen, aber dennoch nicht in der Lage sein, die verschlüsselten Dateien, die er dort findet, zu entsperren, wenn der Verschlüsselungsschlüssel an anderer Stelle gespeichert ist.

Natürlich beruhen alle Verschlüsselungsschutzmethoden auf starken Verschlüsselungsstandards, die selbst von den leistungsfähigsten Computern nicht geknackt werden können.

Warum ist unsichere Kryptographie gefährlich?

Wenn es um Computertechnologie geht, stehen die Fähigkeit, starke Verschlüsselungsalgorithmen zu erstellen, und die Fähigkeit, sie zu brechen, seit langem im Wettbewerb. Bereits 1977 entwickelte die US-Regierung den Data Encryption Standard (DES), einen 56-Bit-Algorithmus, der damals angesichts der relativen Leistungsfähigkeit von Computern als sicher galt.

Aber Computer entwickelten sich weiter, und die Menschen fanden Wege, sie gemeinsam zu vernetzen, um ihre Leistung noch weiter zu steigern. 1999 gelang es der Electronic Frontier Foundation in Zusammenarbeit mit Distributed.net, die Verschlüsselung eines DES-geschützten Dokuments in nur 22 Stunden öffentlich zu knacken. Plötzlich war jedes Dokument, das durch DES-Verschlüsselung geschützt war, nicht mehr sicher.

Ob Sie es glauben oder nicht, einige Organisationen schützen ihre kritischen Dateien immer noch mit dem DES-Algorithmus oder mit einem ähnlich schwachen Verschlüsselungsschutz. Und während 1999 ein verteiltes Netzwerk nötig war, um die 56-Bit-Verschlüsselung zu knacken, kann das heute fast jeder ausreichend leistungsfähige Einzelplatzrechner mit etwas Zeit schaffen. Hacker haben auch spezielle Cracking-Maschinen entwickelt, die aus einer Reihe von Grafikprozessor-Einheiten (GPUs) bestehen. Diese GPUs sind außerordentlich gut in dieser Aufgabe, sind relativ kostengünstig zu beschaffen und lokal zu vernetzen.

Wenn Sie sich heute dafür entscheiden, Ihre kritischen Dateien mit einem unsicheren oder schwachen kryptografischen Algorithmus zu schützen, dann wird es nicht lange dauern, bis die meisten Hacker diese Dateien aufbrechen und lesbar machen können. Wenn Sie von einer Datenpanne betroffen sind, dann müssen Sie davon ausgehen, dass die Dateien irgendwann kompromittiert werden, wenn sie nicht ausreichend geschützt waren.

Der folgende Kubernetes-Codeausschnitt verwendet zum Beispiel einen schwachen Verschlüsselungsalgorithmus, um die Informationen auf der Ebene des NGINX-Ingress-Controllers zu schützen:

apiVersion: v1
kind: ConfigMap
metadata:
name: nginx-load-balancer-conf
namespace: kube-system
data:
ssl-ciphers: DES-CBC3-SHA
ssl-protocols: "TLSv1.2"

In diesem Beispiel wurde zum Schutz der Informationen die DES-Chiffriersuite verwendet. Ein Angreifer könnte sie jedoch leicht entschlüsseln und auf sensible Informationen zugreifen.

Es wird empfohlen, starke Verschlüsselungsalgorithmen zu verwenden. Im folgenden Kubernetes-Beispiel wurden starke Verschlüsselungssuiten verwendet, um die Informationen auf der Ebene des NGINX-Ingress-Controllers zu schützen:

apiVersion: v1
kind: ConfigMap
metadata:
name: nginx-load-balancer-conf
namespace: kube-system
data:
ssl-ciphers: |
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:
ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:
ECDHE-RSA-AES128-SHA256
ssl-protocols: "TLSv1.2"

In diesem Beispiel wurde eine starke Suite von Chiffren verwendet, um zu verhindern, dass Angreifer potenziellen Zugriff auf sensible Informationen erhalten.

Schutz kritischer Informationen mit starker Verschlüsselung

Heute ist eine starke Verschlüsselung verfügbar, die nahezu unknackbar ist. Im Jahr 2001 hat das National Institute of Standards and Technology (NIST) eine neue Verschlüsselungstechnologie entwickelt, die DES ersetzen soll. Sie wird Advanced Encryption Standard (AES) genannt und verwendet drei verschiedene Schlüssellängen, entweder 128, 192 oder 256 Bit. Die 256-Bit-AES-Verschlüsselung ist die sicherste, obwohl alle drei beim heutigen Stand der Technik als nahezu unknackbar gelten. Tests mit Supercomputern haben ergeben, dass es Tausende von Jahren konstanter Arbeit erfordern würde, um die meisten AES-geschützten Dokumente zu knacken.

Um kritische Dateien richtig zu schützen, sollten Entwickler sie zunächst identifizieren. Es ist nicht notwendig, alles in einem Netzwerk zu verschlüsseln, da dies den Betrieb durch den ständigen Ver- und Entschlüsselungsprozess verlangsamen könnte. Aber kritische Dateien wie Personalakten, Kundendaten und Finanzinformationen müssen angemessen geschützt werden. Im Grunde ist es ein Balanceakt zwischen Sicherheit und einem funktionierenden System.

Und diese Daten sollten nach einem der AES-Standards verschlüsselt sein, sogar mit einer 256-Bit-Verschlüsselung für wirklich kritische Informationen, die niemals in die falschen Hände geraten sollten.

Eine weitere Sache, die zu berücksichtigen ist, ist die Tatsache, dass das Hinzufügen von Verschlüsselung wie das Hinzufügen von mehr Passwörtern zu einer Website ist. Das bedeutet, dass autorisierte Benutzer den Überblick über die Verschlüsselungsschlüssel behalten müssen. Um zu verhindern, dass dies zu einem Engpass im Arbeitsablauf wird, sollten Sie die Implementierung einer Schlüsselverwaltungsplattform in Betracht ziehen, um diese Schlüssel im Auge zu behalten und sie sicher aufzubewahren. Und selbst wenn Sie keine zentrale Schlüsselverwaltung verwenden, sollten Sie sicherstellen, dass alle Schlüssel und Passwörter geschützt sind, um zu gewährleisten, dass unbefugte Benutzer keinen Zugriff auf Ihre sichersten Datentresore haben.

Schauen Sie sich 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 Auswirkungen anderer Sicherheitslücken schützen können. Sie können auch eine Demo einer IaC-Herausforderung innerhalb der Schulungsplattform Secure Code Warrior ausprobieren, um alle Ihre Cybersecurity-Fähigkeiten zu verfeinern und auf dem neuesten Stand zu halten.

Wie sieht es mit der Bereitstellung von sicherer Infrastruktur als Code in Ihrem eigenen Unternehmen aus? Es könnte eine gewisse Lernkurve sein, aber das Erlernen der Grundlagen ist eine großartige Chance, Ihre Fähigkeiten zu verbessern, sich von Ihren Kollegen abzuheben und mehr Endbenutzerdaten sicher zu halten.

Bevor wir mit dem nächsten Kapitel unserer aktuellen "Coders Conquer Security"-Serie beginnen, möchte ich Sie einladen, eine gamifizierte Herausforderung zur Schwachstelle bei der Speicherung sensibler Daten zu spielen; spielen Sie jetzt und wählen Sie zwischen Kubernetes, Terraform, Ansible, Docker oder CloudFormation:

Wie war das? Wenn Ihr Wissen etwas Arbeit braucht, lesen Sie weiter:

Der Schlüssel zu den meisten Computersicherheiten liegt heutzutage in Passwörtern. Selbst wenn andere Sicherheitsmethoden eingesetzt werden, wie z. B. Zwei-Faktor-Authentifizierung oder Biometrie, verwenden die meisten Unternehmen immer noch passwortbasierte Sicherheit als ein Element ihres Schutzes. In vielen Unternehmen werden ausschließlich Passwörter verwendet.

Wir verwenden Passwörter so oft, dass wir sogar Regeln haben, wie sie zu erstellen sind. Dies soll sie weniger anfällig für Brute-Force-Angriffe oder sogar wildes Raten machen. Natürlich verwenden einige Leute immer noch schwache Passwörter, wie ein aktueller Bericht von NordPass zeigt. Es ist schwer zu glauben, dass Menschen im Jahr 2020 immer noch 12345 sowie einen Haufen anderer erratbarer Wörter wie Schokolade, Passwort und Gott verwenden, um ihre sensibelsten Daten zu schützen.

Es wird immer diejenigen geben, denen es egal ist, starke Passwörter zu verwenden, aber die meisten professionellen Organisationen zwingen die Benutzer, ihre Zugangswörter oder -phrasen auf bestimmte Weise zu gestalten. Wir alle kennen inzwischen die Regeln: Passwörter müssen mindestens acht Zeichen lang sein und aus Groß- und Kleinbuchstaben bestehen, wobei mindestens eine Zahl und ein Sonderzeichen erforderlich sind.

Das Schlimme daran ist, dass selbst wenn Benutzer die Regeln für die Erstellung der stärksten Arten von Kennwörtern einhalten, es möglicherweise nichts nützt, wenn sie alle im Klartext gespeichert sind. Das Passwort 12345 ist genauso schlecht wie Nuts53!SpiKe&Dog12, wenn ein Hacker die gesamte Passwortdatei lesen kann.

Warum ist das Speichern von Kennwörtern im Klartext gefährlich?

Das Speichern von Passwörtern im Klartext ist schlecht, weil es sowohl das System als auch die Benutzer gefährdet. Wenn ein Hacker in der Lage wäre, jedes einzelne Kennwort für den Zugriff auf ein System zu finden und zu lesen, wäre das natürlich eine Katastrophe. Er könnte einfach einen Benutzer mit Administrator-Zugangsdaten finden und das gesamte System oder die Website gefährden. Und da sie korrekte Benutzernamen und Passwörter verwenden würden, kann es sein, dass die interne Sicherheit das Eindringen nicht oder erst lange nachdem der Schaden entstanden ist, bemerkt.

Die Tatsache, dass es Angreifern leicht gemacht wird, im Klartext gespeicherte Passwörter zu stehlen, schadet auch den Benutzern, da viele Leute Passwörter wiederverwenden. Weil wir das Erstellen von Passwörtern so schwierig gemacht haben, greifen viele Leute auf die Wiederverwendung von Passwörtern zurück, die sie sich für mehrere Websites merken können. Wenn ein Angreifer eine Kennwortdatei kompromittiert, wird er mit ziemlicher Sicherheit versuchen, mit demselben Namen und Kennwort auf andere Systeme zuzugreifen, was die Benutzer einem großen Risiko von Folgedelikten aussetzt.

Es ist relativ einfach, Passwörter versehentlich im Klartext zu speichern oder nicht zu erkennen, dass dies später zu großen Problemen führen kann. Der folgende Code ist zum Beispiel eine gängige Methode zum Speichern von Passwörtern bei der Definition einer AWS-Ressource mit Terraform-Vorlagen:

resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "s3.cr3t.admin.p2ss"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}

In diesem Beispiel wird das Passwort, das zur Verwaltung der MySQL-Datenbankinstanz in AWS verwendet wird, im Klartext gespeichert. Das bedeutet, dass jeder mit Zugriff auf das Quellcode-Repository es lesen oder sogar kopieren könnte.

Der Schutz von Passwörtern variiert je nach Framework, aber es gibt Schutzmethoden für jede Plattform. Zum Beispiel kann das MySQL-Passwort in einem sicheren Speicher wie AWS Secrets Manager gespeichert werden:

resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "${data.aws_secretsmanager_secret_version.password.secret_string}"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}

In diesem Beispiel erhält die Terraform-Vorlage das Passwort vom AWS Secrets Manager Service und es wird niemals im Klartext in Vorlagendateien gespeichert.

Schutz von Passwörtern durch Vermeidung von Klartextspeicherung

Passwörter sind die Schlüssel zu Ihrem Königreich und sollten niemals im Klartext gespeichert werden. Selbst die internen Mitarbeiter einer Organisation sollten keinen Zugriff auf ein großes, ungeschütztes Repository von Passwörtern haben, und dies sollte auch kein akzeptiertes Geschäftsprotokoll sein (es gibt heutzutage viele Passwort-Manager, die eine verschlüsselte Freigabe von Zugangsdaten ermöglichen - keine Ausreden!) Es besteht auch die Gefahr, dass böswillige Insider Dateien ausspähen und sich Zugang verschaffen, wo sie nicht hingehören.

Und bei einem Angriff von außen, stellen Sie sich nur den doppelten Hammer vor, der möglich ist, wenn eine Hintertür zu Ihrer Datenbank durch etwas so einfaches wie eine SQL-Injection-Schwachstelle gefunden wird, und sie auch noch Zugriff auf das Verzeichnis erhalten, in dem die Passwörter gespeichert sind. Denken Sie, dass dies zu viele fehlerbehaftete Schritte sind, um zum Erfolg zu führen? Traurigerweise passierte genau dieses Szenario bei Sonys Einbruch 2011. Über eine Million Kundenpasswörter wurden im Klartext gespeichert, und die Hackergruppe Lulzsec erlangte durch einen gewöhnlichen SQL-Injection-Angriff Zugriff auf diese und noch viel mehr.

Alle Passwörter sollten durch die im unterstützenden Framework verfügbaren Schutzmechanismen geschützt werden. Für Terraform sollten Passwörter niemals in Vorlagendateien gespeichert werden. Es wird empfohlen, einen sicheren Speicher wie AWS Secrets Manager oder Azure Key Vault zu verwenden, je nach Infrastrukturanbieter.

Benutzer zu zwingen, sichere Passwörter zu erstellen, ist eine gute Idee, aber dann müssen Sie auch Ihren Teil am Backend tun. Wenn Sie Passwörter nicht im Klartext speichern, tragen Sie viel zum Schutz Ihrer Benutzer und Ihrer Systeme bei. Die Hauptgefahr bei der Speicherung von Klartext-Passwörtern ist die schlechte Zugriffskontrolle; im Grunde kann jeder sie sehen. Es ist zwingend erforderlich (besonders in einer IaC-Umgebung, wo plötzlich mehr Leute Zugang zu sensiblen Informationen haben), dass sie angemessen gehasht werden und nur diejenigen, die unbedingt Zugang benötigen, diesen auch erhalten.

Schauen Sie sich 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 Auswirkungen anderer Sicherheitslücken und Schwachstellen schützen können. Sie können auch eine Demo-IaC-Herausforderung innerhalb der Schulungsplattform Secure Code Warrior ausprobieren, um alle Ihre Cybersecurity-Fähigkeiten zu verfeinern und auf dem neuesten Stand zu halten.

Jeder, der schon einmal in der Softwareproduktion gearbeitet hat, kennt wahrscheinlich die Spannungen, die entstehen können, wenn es um die Berücksichtigung von Sicherheit geht, meist zwischen Entwicklern und den Sicherheitsspezialisten, die ihren Code unter die Lupe nehmen.

Früher war es nicht unüblich, dass das Entwicklungsteam den Code so spät wie möglich auslieferte, und damit absichtlich das Zeitfenster verkürzte, in dem die Sicherheitsgurus nach Schwachstellen suchen konnten - schließlich verzögerte das die Veröffentlichung, wenn etwas nicht in Ordnung war, und es gab bereits den Wunsch, weiterzumachen und mit dem Bau der nächsten tollen Funktion zu beginnen. Das hatte jedoch einen negativen Effekt, denn wenn der Code schließlich geprüft wurde - manchmal nachdem bereits ein externer Verstoß stattgefunden hatte - kam der Code immer noch zu den Entwicklern zurück, ihre Software-Babys wurden immer noch vom Sicherheitsteam als hässlich bezeichnet, und sie mussten alles stehen und liegen lassen, um den Code zu reparieren, den sie vor Monaten zuletzt angefasst hatten.

Diese Dysfunktion besteht auch heute noch, aber es gibt ein riesiges Problem: Es wird viel mehr Code entwickelt, und die Gesellschaft ist im Falle von Datenverletzungen einem viel größeren Risiko ausgesetzt. Wir haben keine Zeit mehr, diese uralte Schlacht weiter zu führen, und im Jahr 2020 ist es an der Zeit, dass wir uns alle auf dieselbe Seite gegen die Bösewichte schlagen.

Wir müssen ein Stadium erreichen, in dem Sicherheit als eine gemeinsame Verantwortung im gesamten Unternehmen und im gesamten SDLC gesehen wird. Dies ist sicherlich möglich, wenn Sie sich zu einer vollwertigen, hochgradig unterstützenden DevSecOps-Umgebung verpflichten. Und wenn Sie das Sicherheitsfeuer in Ihrem Entwicklungsteam mit dem richtigen Training und den richtigen Tools entfachen, sind sie nicht nur eine mächtige Kraft bei der Beseitigung von Fehlern, sondern entlasten auch die Sicherheitsspezialisten, die zu lange zu dünn gesät waren.

Ich würde mich freuen, wenn Sie sich eines meiner letzten Webinare ansehen würden: "How to put the "Sec" in DevOps":

Dies war Teil des AllTheTalks 24-Stunden-Gipfeltreffens, und es wirft einen tiefen Blick hinein:

• Warum ältere Entwicklungsmethodiken Best Practice im Bereich Sicherheit so viel schwieriger machen
• Warum DevSecOps der letzte Schrei ist, wenn es darum geht, gängige Sicherheitslücken zu schließen
• Wie Sicherheit als gemeinsame Verantwortung in einer Organisation aussieht
• Wie Sie Entwickler in die Lage versetzen können, sicheren Code mit Vertrauen auszuliefern, ohne das zu opfern, was sie lieben (Hinweis: es ist das Entwickeln großartiger Funktionen).

Wir sehen uns dort!

Die Bedrohungen für die Cybersicherheit sind heutzutage allgegenwärtig und unerbittlich. Je mehr Facetten unseres Lebens digitalisiert werden, desto mehr steht für Cyberkriminelle auf dem Spiel - es gibt zu viel Code, den es zu schützen gilt, und private Daten sind zu wertvoll. Und, nun ja, der Versuch, mit jedem Aspekt der Angriffsfläche Schritt zu halten und sie zu verteidigen, nachdem die Programme bereitgestellt wurden, ist fast unmöglich geworden.

Es gibt Ansätze, die einige dieser Symptome lindern können, und einer davon ist offensichtlich, wenn kluge Organisationen das Konzept von Infrastructure as Code (IaC) annehmen. Natürlich gibt es, wie bei jeder Entwicklung, einige Sicherheitsfallen, die es zu umschiffen gilt. Und da die Entwickler an dem Code arbeiten, der die lebenswichtige Infrastruktur für den Betrieb der Anwendungen generiert, ist das Sicherheitsbewusstsein in jeder Phase des Prozesses entscheidend.

Wie genau würde ein Entwickler, der neu in einer Cloud-Server-Umgebung ist, vorgehen, um sich fortzubilden, die Grundlagen zu erlernen und mit erhöhtem Sicherheitsbewusstsein an den Build heranzugehen? Wir haben die nächste "Coders Conquer Security"-Reihe ins Leben gerufen, um häufige IaC-Schwachstellen zu beheben. In den nächsten Blogs werden wir uns auf Schritte konzentrieren, die Sie als Entwickler unternehmen können, um mit der Bereitstellung einer sicheren Infrastruktur als Code in Ihrem eigenen Unternehmen zu beginnen.

Fangen wir an.

Es gibt eine Fabel aus dem alten amerikanischen Westen über einen Mann, der paranoid war, dass Banditen sein Gehöft angreifen und ausrauben würden. Um dies zu kompensieren, investierte er in alle möglichen Sicherheitsmaßnahmen, wie z. B. den Einbau einer extrastarken Eingangstür, das Vernageln aller Fenster und die Aufbewahrung vieler Gewehre in unmittelbarer Nähe. Trotzdem wurde er eines Nachts im Schlaf ausgeraubt, weil er vergessen hatte, die Seitentür zu verschließen. Die Banditen fanden einfach die deaktivierte Sicherung und nutzten die Situation schnell aus.

Mit deaktivierten Sicherheitsfunktionen in Ihrer Infrastruktur verhält es sich ähnlich. Selbst wenn Ihr Netzwerk über eine starke Sicherheitsinfrastruktur verfügt, nützt es sehr wenig, wenn Elemente deaktiviert wurden.

Lassen Sie mich eine Herausforderung stellen, bevor wir eintauchen:

Besuchen Sie den obigen Link, und Sie werden zu unserer gamifizierten Trainingsplattform transportiert, wo Sie jetzt versuchen können, eine deaktivierte Sicherheitsfunktion zu überwinden. (Achtung! Es öffnet sich in Kubernetes, aber verwenden Sie das Dropdown-Menü und Sie können zwischen Docker, CloudFormation, Terraform und Ansible wählen).

Wie haben Sie abgeschnitten? Wenn Sie noch etwas Arbeit vor sich haben, lesen Sie weiter:

Sicherheitsfunktionen können aus verschiedenen Gründen deaktiviert werden. Bei einigen Anwendungen und Frameworks sind sie möglicherweise standardmäßig deaktiviert und müssen erst eingeschaltet werden, um zu funktionieren. Es ist auch möglich, dass Administratoren bestimmte Sicherheitsfunktionen deaktiviert haben, um bestimmte Aufgaben leichter ausführen zu können, ohne ständig herausgefordert oder blockiert zu werden (z. B. ein AWS S3-Bucket öffentlich machen). Nach Abschluss ihrer Arbeit vergessen sie vielleicht, diese deaktivierten Funktionen wieder zu aktivieren. Sie könnten es auch vorziehen, sie ausgeschaltet zu lassen, um ihre Arbeit in Zukunft einfacher zu machen.

Warum deaktivierte Sicherheitsfunktionen so gefährlich sind

Eine oder mehrere deaktivierte Sicherheitsfunktionen zu haben, ist aus mehreren Gründen schlecht. Zum einen wurde die Sicherheitsfunktion in die Infrastrukturressourcen integriert, um sie vor einem bekannten Exploit, einer Bedrohung oder einer Schwachstelle zu schützen. Wenn sie deaktiviert ist, kann sie Ihre Ressourcen nicht mehr schützen.

Angreifer werden immer zuerst versuchen, leicht ausnutzbare Schwachstellen zu finden und können sogar ein Skript verwenden, um gängige Schwachstellen durchzuspielen. Es ist nicht unähnlich einem Dieb, der alle Autos in einer Straße überprüft, um zu sehen, ob irgendwelche Türen unverschlossen sind, was viel einfacher ist, als ein Fenster einzuschlagen. Hacker könnten überrascht sein, wenn sie feststellen, dass eine gängige Sicherheitsabwehr inaktiv ist. Aber wenn das passiert, wird es nicht lange dauern, bis sie es ausnutzen.

Zweitens: Gute Sicherheitsmaßnahmen zu haben und sie dann zu deaktivieren, schafft ein falsches Gefühl von Sicherheit. Administratoren denken vielleicht, dass sie vor allgemeinen Bedrohungen geschützt sind, wenn sie nicht wissen, dass jemand diese Verteidigungsmaßnahmen deaktiviert hat.

Als Beispiel dafür, wie ein Angreifer eine deaktivierte Sicherheitsfunktion ausnutzen könnte, betrachten Sie die AWS S3-Sicherheitsfunktion "block public access". Mit Amazon S3 block public access können Kontoadministratoren und Bucket-Besitzer ganz einfach zentralisierte Kontrollen einrichten, um den öffentlichen Zugriff auf ihre Amazon S3-Ressourcen zu beschränken. Einige Administratoren, die auf Probleme beim Zugriff auf den S3-Bucket stoßen, entscheiden sich jedoch dafür, diesen öffentlich zu machen, um die Aufgabe so schnell wie möglich zu erledigen. Wenn sie vergessen, diese Sicherheitsfunktion zu aktivieren, hat ein Angreifer vollständigen Zugriff auf die in diesem S3-Bucket gespeicherten Informationen, was nicht nur zur Offenlegung von Informationen führt, sondern auch zusätzliche Kosten aufgrund von Datenübertragungsgebühren verursacht.

Lassen Sie uns einige reale Codes vergleichen; sehen Sie sich diese CloudFormation-Schnipsel an:

Verwundbar:

CorporateBucket:
Type: AWS::S3::Bucket
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: false
BlockPublicPolicy: false
IgnorePublicAcls: false
RestrictPublicBuckets: false
VersioningConfiguration:
Status: Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: "AES256"

Sicher:

CorporateBucket:
Type: AWS::S3::Bucket
Eigenschaften:
PublicAccessBlockConfiguration:
BlockPublicAcls: true
BlockPublicPolicy: true
IgnorePublicAcls: true
RestrictPublicBuckets: true
VersioningConfiguration:
Status: Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: "AES256"

Verhindern von deaktivierten Sicherheitsfunktionen

Zu verhindern, dass deaktivierte Sicherheitsfunktionen Ihrem Unternehmen Schaden zufügen, ist ebenso eine Frage der Richtlinie wie der Praxis. Es sollte eine feste Richtlinie geben, die besagt, dass Sicherheitsfunktionen nur unter ganz bestimmten Umständen deaktiviert werden sollten. Vorfälle, in denen Funktionen vorübergehend deaktiviert werden müssen, um an einem Problem zu arbeiten oder Anwendungen zu aktualisieren, sollten protokolliert werden. Nach Abschluss der erforderlichen Arbeiten sollten die Funktionen überprüft werden, um sicherzustellen, dass sie vollständig reaktiviert wurden.

Wenn eine Sicherheitsfunktion dauerhaft deaktiviert werden muss, um den Betrieb zu rationalisieren, sollten für die betroffenen Daten andere Schutzmechanismen vorgesehen werden, um sicherzustellen, dass Hacker nicht in der Lage sind, auf die Daten zuzugreifen, wenn der Standardschutz nicht vorhanden ist. Wenn eine benötigte Schutzfunktion deaktiviert wurde, ist es nur eine Frage der Zeit, bis ein Angreifer diese unverschlossene Tür findet und die Situation ausnutzt.

Lernen Sie mehr, fordern Sie sich selbst heraus:

Schauen Sie sich die Secure Code Warrior Blog-Seiten, um weitere Informationen über diese Sicherheitslücke zu erhalten und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen anderer Sicherheitslücken und Schwachstellen schützen können.

Sind Sie bereit, diese Schwachstelle zu finden und zu beheben, nachdem Sie diesen Beitrag gelesen haben? Es ist an der Zeit,eine gamifizierte IaC-Sicherheitsherausforderung auf der Plattform Secure Code Warrior auszuprobieren, um alle Ihre Cybersecurity-Fähigkeiten zu verfeinern und auf dem neuesten Stand zu halten.

Dies ist eine wöchentliche Serie, die sich mit den acht wichtigsten Infrastructure as Code-Schwachstellen befasst; schauen Sie nächste Woche wieder vorbei, um mehr zu erfahren!

Es ist Zeit für den nächsten Teil unserer "Infrastructure as Code"-Reihe, die Blogs, die Entwickler wie Sie auf eine ganz neue Ebene des Sicherheitsbewusstseins bringen, wenn Sie eine sichere Infrastruktur in Ihrer eigenen Organisation bereitstellen.

Ach, übrigens... wie ist es Ihnen mit der Herausforderung der Sicherheitsfehlkonfiguration im vorherigen Blog ergangen? Wenn Sie jetzt eine Schwachstelle in der Zugriffskontrolle auf Funktionsebene beheben möchten, gehen Sie auf die Plattform:

(Der Link oben führt Sie zur Kubernetes-Herausforderung, aber sobald Sie auf der Plattform sind, können Sie im Dropdown-Menü auch Ansible, CloudFormation, Terraform oder Docker auswählen. Sie haben die Wahl.)

Fast jede Anwendung, die heute eingesetzt wird, verfügt über eine Art Zugriffskontrollmechanismus, der prüft, ob ein Benutzer die Berechtigung hat, die angeforderten Funktionen auszuführen oder nicht. Das ist so ziemlich der Grundstein für gute Sicherheit und Funktionalität bei der Erstellung einer Anwendung. Tatsächlich benötigen alle Webanwendungen Zugriffskontrollen, um Benutzern mit unterschiedlichen Berechtigungen die Nutzung des Programms zu ermöglichen.

Probleme können jedoch auftreten, wenn dieselben Überprüfungsfunktionen für die Zugriffskontrolle nicht auf der Infrastrukturebene durchgeführt werden oder falsch konfiguriert sind. Ohne eine perfekt funktionierende Zugriffskontrolle auf Infrastrukturebene öffnet sich ein ganzes Unternehmen für Hacker, die diese Schwachstelle als Einfallstor für unerlaubtes Schnüffeln oder einen vollständigen Angriff nutzen können.

Tatsächlich ist das Ausnutzen von Schwachstellen in der Zugriffskontrolle durch fehlende oder falsch konfigurierte Funktionen extrem einfach. Angreifer müssen nicht einmal übermäßig geschickt sein. Sie müssen nur wissen, welche Befehle Funktionen innerhalb des Frameworks, das die Anwendung unterstützt, ausführen. Wenn sie das wissen, ist es nur eine Frage von Versuch und Irrtum. Sie können ständig Anfragen stellen, die nicht erlaubt sein sollten, und sobald eine erfolgreich ist, könnte die anvisierte Website, Anwendung, der Server oder sogar das gesamte Netzwerk gefährdet sein.

Wie funktionieren Exploits für fehlende Funktionslevel-Zugriffskontrolle?

Es gibt einige Möglichkeiten, wie sich Zugriffskontrollen auf Funktionsebene in einer Organisation einschleichen können. Zum Beispiel kann der Zugriff auf Funktionsebene einer Anwendung überlassen werden und nicht von der zugrunde liegenden Infrastruktur überprüft werden. Oder die Zugriffskontrolle auf Infrastrukturebene kann falsch konfiguriert sein. In manchen Fällen gehen Administratoren davon aus, dass nicht autorisierte Benutzer nicht wissen, wie sie auf Infrastrukturressourcen zugreifen können, die nur für Benutzer höherer Ebenen zugänglich sein sollten, und verwenden ein "Security by Obscurity"-Modell, das nur selten funktioniert.

Als Beispiel für "Security by Obscurity" ist die folgende URL wahrscheinlich anfällig für Angriffe:

http://companywebsite.com/app/NormalUserHomepage

Wenn ein authentifizierter Benutzer eine Technik namens Forced URL Browsing anwendet, könnte er versuchen, eine Seite zu erreichen, die nur Administratoren angezeigt wird. Ein Beispiel könnte sein:

http://companywebsite.com/app/AdminPages

Wenn es keine serverseitige Überprüfung gibt, wird ihnen einfach die Admin-Seite angezeigt (wenn ihr Name mit der Anfrage übereinstimmt) und sie haben dann Zugriff auf alle zusätzlichen Funktionen, die Administratoren von der neuen Seite aus ausführen. Wenn der Server dem Angreifer einen "Seite nicht gefunden"-Fehler zurückgibt, kann er es einfach weiter versuchen, bis er herausfindet, welchen Namen die Admin-Seite hat.

Für Angreifer ist das Ausnutzen fehlender Zugriffskontrollen auf Funktionsebene ein ähnlicher Prozess. Anstatt zu versuchen, nicht autorisierte Seiten zu durchsuchen, senden sie stattdessen Funktionsanforderungen. Sie könnten zum Beispiel versuchen, einen neuen Benutzer mit Administratorrechten zu erstellen. Ihre Anfrage würde also je nach Framework etwa so aussehen:

POST/action/createuser name=hacker&pw=password&role=admin

Wenn keine Zugriffssteuerung auf Funktionsebene vorhanden ist, wäre das obige Beispiel erfolgreich und ein neues Administratorkonto würde erstellt werden. Sobald sich der Angreifer wieder als neuer Administrator anmeldet, hätte er denselben Zugriff und dieselben Berechtigungen wie jeder andere Administrator in diesem Netzwerk oder auf diesem Server.

Die Lösung für fehlende Zugriffskontrollen auf Funktionsebene

Da es für Angreifer so einfach ist, Schwachstellen in der Zugriffskontrolle auf Funktionsebene auszunutzen, ist es von entscheidender Bedeutung, dass sie gefunden, behoben und verhindert werden. Zum Glück ist dies mit etwas Know-how und einer grundlegenden Sicherheitsschulung für Infrastructure as Code nicht allzu schwierig.

Der wichtigste Schutz besteht in der Implementierung einer rollenbasierten Autorisierung auf der Infrastrukturebene. Vertrauen Sie niemals darauf, dass Anwendungen diese Funktion übernehmen. Selbst wenn sie das tun, stellt eine infrastrukturseitige Autorisierung sicher, dass nichts übersehen wird. Idealerweise sollte die Autorisierung von einer zentralen Stelle kommen (z. B. AWS IAM, Azure IAM usw.), die in die Routine Ihrer Organisation integriert ist und auf jede neue Anwendung angewendet wird. Diese Autorisierungsprozesse können aus dem Framework selbst oder einer beliebigen Anzahl von einfach zu verwendenden externen Modulen stammen.

Schließlich sollte Ihre Organisation das Konzept der geringsten Berechtigung übernehmen. Alle Aktionen und Funktionen sollten standardmäßig verweigert werden, wobei der Autorisierungsprozess verwendet wird, um gültigen Benutzern die Erlaubnis zu geben, das zu tun, was sie brauchen. Sie sollten nur so viel Berechtigung erhalten, dass sie die erforderliche Funktion ausführen können, und auch nur so lange wie nötig.

Fehlende Zugriffskontrollen auf Funktionsebene können verheerend sein. Aber zum Glück können Sie dieses Problem leicht verhindern, indem Sie gute Autorisierungspraktiken auf Infrastrukturebene in Ihre Organisation einbauen.

Denken Sie, Sie sind bereit, einen Fehler in der Zugriffskontrolle in freier Wildbahn zu erkennen? Vergleichen Sie diese Docker-Code-Schnipsel; einer verwundbar, einer sicher:

Verwundbar:

FROM quay.io/prometheus/busybox:latest
ARG VERSION=0.12.1
ARG FILENAME=mysqld_exporter-${VERSION}.linux-amd64
ARG URL=https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$VERSION/$FILENAME.tar.gz && \
   tar -xvf $FILENAME.tar.gz && \
   mv $FILENAME/mysqld_exporter /bin/mysqld_exporter
COPY .my.cnf /home/.my.cnf
COPY ./scripts/entrypoint.sh ~/entrypoint.sh
USER root
EXPOSE 9104
ENTRYPOINT  [ "sh", "~/entrypoint.sh" ]
CMD  [ "/bin/mysqld_exporter" ]

Sicher:

FROM quay.io/prometheus/busybox:latest
ARG VERSION=0.12.1
ARG FILENAME=mysqld_exporter-${VERSION}.linux-amd64
ARG URL=https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$VERSION/$FILENAME.tar.gz && \
   tar -xvf $FILENAME.tar.gz && \
   mv $FILENAME/mysqld_exporter /bin/mysqld_exporter
COPY .my.cnf /home/.my.cnf
COPY ./scripts/entrypoint.sh ~/entrypoint.sh
USER nobody
EXPOSE 9104
ENTRYPOINT  [ "sh", "~/entrypoint.sh" ]
CMD  [ "/bin/mysqld_exporter" ]

Mehr lernen, sich selbst herausfordern

Schauen Sie sich die Secure Code Warrior Blog-Seiten, um weitere Informationen über diese Sicherheitslücke zu erhalten und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen anderer Sicherheitslücken und Schwachstellen schützen können.

Und falls Sie es verpasst haben, können Sie auf der Plattform Secure Code Warrior eine gamifizierte IaC-Sicherheits-Challenge ausprobieren, um Ihre Cybersecurity-Fähigkeiten zu verfeinern und auf dem neuesten Stand zu halten.

Bleiben Sie dran für das nächste Kapitel!

Dies ist Teil 2 einer Miniserie über PCI-DSS-Compliance innerhalb einer Organisation. In diesem abschließenden Kapitel gehen wir darauf ein, wie CTOs und CISOs bei der Verringerung des Cyber-Risikos von der Spitze aus führen und den Prozess nahtlos und erfolgreich gestalten können... und vielleicht auch ein bisschen Spaß für Entwickler. (Haben Sie Teil 1 verpasst? Lesen Sie ihn hier und erfahren Sie, wie AppSec-Spezialisten diese Chance für bessere Sicherheitsergebnisse ergreifen können).

PCI-DSS-Best-Practice ist zweifellos eine geteilte Verantwortung, aber CISOs und CTOs können ihren beträchtlichen Einfluss nutzen, um ein gedeihliches, positives Sicherheitsprogramm von oben zu gestalten. Sie sind das Aushängeschild für das Vertrauen in die Cybersicherheit und die damit verbundene Stimmung bei den Endbenutzern. Eine frühzeitige Sensibilisierung hat einen starken "Trickle-Down"-Effekt und hilft Entwicklern und AppSec-Experten, das Wissen, die Tools und die Unterstützung zu erhalten, die sie benötigen, um zu einer robusten Sicherheitslage im Unternehmen beizutragen.

Es ist wichtig, die Vorschriften einzuhalten, aber wenn jeder mit dem "Warum" einverstanden ist, Ergebnisse sieht und auf die richtige Weise gefördert wird, kann ein Programm über die Gesetzgebung hinausgehen und zur zweiten Natur werden.

CTOs und CISOs haben die Aufgabe, gegenseitiges Vertrauen zu schaffen

Waren Sie in letzter Zeit auf einer Website und haben zweimal darüber nachgedacht, ob Sie Ihre Kreditkartendaten aushändigen sollten? Sofern es sich nicht um die skizzenhaft aussehende Web-App handelt, die die Online-Bestellung für Ihren örtlichen Pizzaladen durchführt, ist dies wahrscheinlich nicht etwas, das Sie sehr oft erleben, insbesondere nicht bei großen Unternehmen und bekannten Namen im Online-Handel.

Es sei denn, sie geben eine Datenpanne bekannt, natürlich.

Der globale Beherbergungsgigant Marriott hat soeben den zweiten Einbruch innerhalb von drei Jahren bekannt gegeben, der zum Diebstahl von 5,2 Millionen Kundendaten führte. Dieses Mal scheint es noch nicht so, als ob Zahlungsinformationen Teil des Raubes waren, obwohl der katastrophale Einbruch im Jahr 2018 dafür gesorgt hat; 383 Millionen Kunden wurden kompromittiert, wobei 5 Millionen unverschlüsselte Passnummern sowie 8 Millionen Kreditkartennummern gestohlen wurden.

Wenn das Vertrauen der Kunden in die Marke Marriott nicht schon so niedrig wäre, wie es nur sein kann, würde ich sagen, dass es bald den Tiefpunkt erreicht hat. Dies ist die Art von Dingen, die CISOs nachts wach hält, da sie sich wie leichte Beute im Krieg gegen Cyber-Bedrohungen fühlen. Schauen Sie sich nur Equifax, Yahoo, Sony, Target an - das sind nur einige große Namen, die großflächige Sicherheitsverletzungen erlitten haben, die Milliarden von gestohlenen Datensätzen, Hunderte von Milliarden Dollar an Schaden und kundenförmige Löcher in ihre wirtschaftlichen Herzen gestanzt haben. Es ist eine Katastrophe für das Unternehmen (Target meldete einen Gewinneinbruch von 440 Millionen Dollar im Quartal nach dem Einbruch von 2014), und obwohl einzelne Personen in der Regel nicht dafür verantwortlich gemacht werden - schließlich sollte Softwaresicherheit eine gemeinsame Verantwortung sein -, ist es etwas, das man nicht unbedingt in einem ansonsten glänzenden Lebenslauf sehen möchte, wenn man zufällig zu dieser Zeit für diese Organisationen arbeitet.

Der Verzicht auf ein robustes Sicherheitsprogramm zur Erreichung der Compliance in einem Unternehmen, das mit Zahlungen, sensiblen Daten und dem immateriellen Gold der positiven Kundenstimmung zu tun hat, ist ein Indikator für ein Unternehmen, das nicht nur gefährdet ist, sondern auch ernsthaft hinter der Innovation zurückbleibt.

Jeder sollte sich um Vertrauensfragen in der Beziehung Kunde/Organisation kümmern.

Abgesehen von dem Stress und dem Unheil, dem die IT-, Entwicklungs- und Sicherheitsabteilungen nach einer Sicherheitsverletzung ausgesetzt sind, ist der Faktor Vertrauen ein wichtiges Element für den langfristigen Erfolg eines neueren Unternehmens oder das weitere Wachstum eines etablierten Unternehmens. Das Offensichtliche, was Sie zu verlieren drohen, ist Ihr Job, sollte das Unternehmen aufgrund des verlorenen Vertrauens mit einem wirtschaftlichen Abschwung konfrontiert werden.

Die PCI-DSS-Vorschriften nehmen Unternehmen in die Pflicht - und wie oben erwähnt, hat das Ignorieren dieser gut durchdachten Pläne enorme Auswirkungen -, aber sie sind nur so gut wie das Sicherheitsprogramm, das eingerichtet wurde, und die Mitarbeiter, die darin arbeiten. Wenn Sie sie ernst nehmen, aufmerksam bleiben und ein Beispiel für andere geben, dann heben Sie sich auf eine sehr positive Art und Weise ab.

Achtsamkeit ist alles.

Ein fehlendes Security-Awareness-Programm wird die meisten Versuche, PCI-konform zu bleiben, nahezu nutzlos machen. Organisationsweite Security Awareness bildet den kritischsten Teil der Best-Practice-Richtlinien; sie bieten sogar eigene Trainingsmodule dazu an, wie dies in funktionsübergreifenden Rollen umgesetzt werden kann und wie dies in Unternehmen aussieht, die es richtig machen.

Auf dem Weg zu DevSecOps als aktuellem Goldstandard in der sicheren Softwareentwicklung - bei dem Sicherheit als gemeinsame Verantwortung grundlegend ist - müssen Unternehmen die Zeit, das Geld und den Aufwand aufwenden, um sicherzustellen, dass jeder, einschließlich Anbieter und Auftragnehmer, sicherheitsbewusst ist und Best Practices befolgt.

Ein sicherheitsbewusster Entwickler ist ein regelkonformer Entwickler (und der Weg dahin muss nicht langweilig sein)

Wenn es darum geht, ein "zertifizierter" PCI-DSS-konformer Entwickler zu werden, gibt es nicht viele offensichtliche Möglichkeiten. Und warum? Wahrscheinlich, weil es keine "One-and-Done"-Übung sein kann.

Die OWASP-Organisation ist eine der besten auf dem Planeten, wenn es darum geht, zu lernen, wie man häufige Schwachstellen vereitelt, und ihre Top 10 ist offiziell in den PCI-DSS-Richtlinien für Entwickler aufgeführt. Sicherheit im Blick zu behalten und die Fähigkeiten zu verfeinern, erfordert jedoch Zeit und kontinuierliche Bemühungen. Und niemand möchte, dass dies uninspiriert und eine Verschwendung von Mühe ist.

Eine positive Sicherheitskultur ist kein "nice to have" in einer Organisation; wenn sie die Sicherheit ernst nehmen, dann muss sie Teil des Unternehmensalltags sein.

Entwickler stehen an vorderster Front, wenn es darum geht, Schwachstellen zu beseitigen. Erhalten sie die Unterstützung, die Tools und das Training, um ihren Teil des Sicherheitsdeals bei der PCI-DSS-Compliance einzuhalten?

Die Wahrheit ist, dass das richtige Training nahtloser ist; es sollte sich nicht wie eine Vorlesung anfühlen, und es sollte für die tägliche Arbeit höchst relevant sein. Und diese Art von praktischem Training ist eine Möglichkeit zur Weiterbildung - ein Karriereschritt, der nur Vorteile für Entwickler hat, die es ernst damit meinen, Schwachstellen zu stoppen und mit dem Rest des Teams zusammenzuarbeiten, um einen höheren Standard des Codes zu produzieren.

Möchten Sie Ihre Fähigkeiten im sicheren Programmieren gleich testen? Wählen Sie Ihre Mission.

Dies ist Teil 1 einer zweiteiligen Serie über erfolgreiche PCI-DSS-Compliance innerhalb einer Organisation. In diesem Kapitel erläutern wir, wie AppSec-Spezialisten eng mit Entwicklungsmanagern zusammenarbeiten können, um Entwickler zu befähigen, das SSDLC zu stärken und konkrete Ergebnisse aus der allgemeinen Gesetzgebung zu erzielen.

Das Wort "Compliance" ist nicht sehr aufregend. Es ist formell, trocken, direktiv... sogar ein wenig restriktiv in seinem Ton. Wenn es eine Farbe hätte, wäre sie beige. Und, nun ja, es scheint im Widerspruch zu jeder Art von kreativem Umfeld oder Innovation zu stehen.

Als Entwickler habe ich die Erfahrung gemacht, dass "compliant zu sein" in der Regel bedeutet, (vertikal) einige Richtlinien durchzulesen oder sich eine Präsentation anzusehen, bevor man sich wieder der Programmierung von Funktionen widmet und sich auf die Erstellung von Software konzentriert, die die Kunden nutzen und lieben werden. Jeder behält, was er im Moment kann (und versucht, immer das Richtige zu tun), aber Compliance-Richtlinien - insbesondere solche, die sich auf bewährte Sicherheitspraktiken beziehen - werden in der Regel nicht mit Entwicklern als Zielgruppe geschrieben, und alle erforderlichen Maßnahmen können unklar sein. In diesem Szenario ist es nur allzu leicht, einfach bei den aktuellen Zielen zu bleiben.

Die Sache ist die: Sichere Softwareentwicklung ist nicht länger ein "nice to have" in jedem Unternehmen; sie ist (oder sollte) in jedem Unternehmen an erster Stelle stehen... und wenn sie große Mengen an sensiblen Kundendaten enthält, dann ist das Unternehmen reif für die Ernte, wenn es um Cyberattacken geht. Entwickler sind die ersten, die mit dem Code in Berührung kommen und sollten daher genauso wie der Rest des Teams in alle Maßnahmen zur Einhaltung von Sicherheitsvorschriften eingebunden werden.

Aber, warten Sie... hören Sie mir zu. Das bedeutet nicht, dass jeder ein Sklave starrer, kreativitätsfreier Entwicklung und Software-Ergebnisse werden muss. Es bedeutet, dass das Unternehmen die Möglichkeit und die Macht hat, gemeinsam einen höheren Standard von Code zu schaffen. Ganz langsam holt die Welt die Tatsache ein, dass Entwickler bisher nicht gerade die richtigen Werkzeuge zur Verfügung hatten, um Sicherheit zu einer Priorität zu machen (und isolierte Sicherheitsspezialisten können die Verantwortung nicht allein schultern). Da sich die Branche jedoch auf eine DevSecOps-Zukunft zubewegt, in der Sicherheit eine gemeinsame Verantwortung ist, können sie dazu beitragen, den Strom wiederkehrender Schwachstellen einzudämmen, wenn sie für den Erfolg eingerichtet werden.

Die PCI-DSS-Richtlinien decken die Einhaltung der Online-Sicherheit für Kartenzahlungs-Gateways ab - ein Service, den die meisten von uns regelmäßig nutzen. Diese Richtlinien sind weltweit anwendbar und sie haben tatsächlich im Detail beschrieben, was Entwickler tun müssen, um die Standards in Übereinstimmung mit ihren Mandaten zu halten, neben mehreren Compliance-Dokumenten über Aspekte des eCommerce-Geschäfts.

Datenschutzverletzungen sind ein beängstigendes, rufschädigendes Risiko, das sich Unternehmen nicht leisten können. Cyber Security Ventures geht davon aus, dass im Jahr 2021 täglich eine Zero-Day-Verletzung auftreten wird - ein Problem, das jeder im Softwareentwicklungsprozess bekämpfen kann.

Lassen Sie uns die PCI-DSS-Empfehlungen aufschlüsseln, und wie sie im Team funktionieren können:

Hallo, AppSec- und Compliance-Teams: Nicht alle Entwicklerschulungen sind gleich

Entwickler in großen (oder auch kleinen) Organisationen haben selten einen großen Einfluss auf die Ausbildung, die sie on-the-job erhalten. Um Star-Mitarbeiter zu halten, bieten einige Unternehmen zwar umfassende Programme an, aber diese sind immer noch weniger verbreitet, als sie sein sollten. Ein Bedarf an Sicherheitsschulungen stellt eine großartige Gelegenheit dar, nicht nur die organisatorische Compliance einzuleiten, ohne alle zu langweilen, sondern auch damit zu beginnen, etwaige frostige Beziehungen mit dem Entwicklungsteam aufzuwärmen.

In Bezug auf die PCI-Konformität sind die Richtlinien der Organisation sehr spezifisch, was die Ergebnisse angeht, die sie von jeder Software erwartet, die mit Zahlungsgateways arbeitet. Unter anderem sollen die Anwendungen gehärtet sein (wichtig, um die Einspeisung von bösartigem Code oder Manipulationen zu vereiteln), es soll ein Minimum an Privilegien und ein umfassendes Bewusstsein für häufige Schwachstellen vorhanden sein. Alle Mitarbeiter, die mit Karteninhaberdaten arbeiten, müssen angemessen geschult werden, und für Entwickler kann diese Schulung über Erfolg oder Misserfolg beim Schreiben von sicherem Code von Anfang an entscheiden.

Das offizielle Dokument " Best Practices for Maintaining PCI-DSS Compliance" (Best Practices für die Aufrechterhaltung der PCI-DSS-Compliance ) enthält einige direkte Konzepte rund um das Sicherheitsbewusstsein, die Bedürfnisse von Entwicklern und entsprechende Schulungen, wie z. B.:

Urheberrecht © 2006 - 2020 PCI Security Standards Council, LLC. Alle Rechte vorbehalten.

Dies gibt einen Einblick in das spezifische, tiefgehende Training, das erforderlich ist, um Entwickler mit den notwendigen Fähigkeiten auszustatten, aber es zeigt immer noch nicht auf, dass bestimmte Arten von Bildungslösungen effektiver sind als andere. Der PCI-DSS Guide for Developers wird etwas direkter und nennt die OWASP Top 10 als einen Maßstab für das Erlernen des Auffindens und Behebens der häufigsten Schwachstellen sowie einige Zertifizierungsprogramme.

Aber... hier ist der Haken. Wie Sie zweifelsohne von verschiedenen Arbeitsplatzschulungen und Compliance-Initiativen wissen, können diese in Bezug auf Qualität und zukünftigen Erfolg stark variieren. Und wenn es um Entwickler geht, scheinen so viele Trainingsprogramme für sichere Programmierung nicht auf unsere Bedürfnisse, Arbeitsweisen oder sogar unsere tägliche Arbeit in irgendeiner sinnvollen Weise einzugehen. In diesem Szenario ist nicht jede Schulung gleich, und nicht jede Schulung führt zu einer sichereren Software. Das ist natürlich das genaue Gegenteil des gewünschten Ergebnisses und wird den Stress der eigenen Arbeit nicht in nennenswertem Umfang reduzieren. Wenn Sie die Belastung reduzieren und verhindern wollen, dass häufige Sicherheitslücken zu potenziellen Katastrophen führen, müssen Sie eine Brücke bauen.

Überbrückung der Qualifikationslücke im Sicherheitsbereich mit technischen Managern an Ihrer Seite

Die direkte Zusammenarbeit mit den technischen Managern, um eine Lösung zu finden, die zweckdienlich ist und gleichzeitig von den Leuten angenommen wird, die sie tatsächlich durchführen müssen, ist ein schneller Weg zu positiven Sicherheitsergebnissen. Sie haben einen direkteren Einblick in ihr eigenes Team und können etwaige Blockaden ansprechen, die das Compliance-Training bisher erschwert haben (abgesehen davon, dass es meistens keine gute Erfahrung ist).

Schulungen im Klassenzimmer, Video-on-Demand und einmalige Übungen machen es sehr schwierig, auf dem neuesten Stand zu bleiben; dies sind statische Lösungen, die nicht mit der sich ständig verändernden Landschaft der Cybersicherheitsbranche Schritt halten können. Es ist wichtig, mit ihnen zusammenzuarbeiten und praktikable Optionen anzubieten, die das gemeinsame Ziel aller Beteiligten erreichen: sicherer und konformer Code.

Wie sieht also eine gute Ausbildung aus? Es macht sehr wenig Sinn, sicheres Programmieren durch große, einmalige Informationshäppchen zu lernen. Ein mundgerechter, schrittweiser Lernprozess macht es viel einfacher, sich daran zu erinnern und es im Kontext anzuwenden, und es muss unbedingt in den Sprachen und Frameworks sein, die jeden Tag verwendet werden. Ich persönlich möchte herausgefordert werden, und ich möchte einen Zweck für meine Bemühungen sehen - wir sind alle so schon beschäftigt genug, oder?

Um die oben beschriebenen PCI-DSS-Best-Practices einzuhalten, müssen Manager je nach gewählter Lösung möglicherweise einen Flickenteppich aus verschiedenen courses zusammensetzen, um alle Sprachen und Frameworks abzudecken, die im gesamten Unternehmen verwendet werden - und dann wird es sehr unübersichtlich, ganz zu schweigen davon, dass es für AppSec- und Compliance-Teams schwierig ist, die Auswirkungen auf die Sicherheit und die Reduzierung von Schwachstellen in der Software zu bewerten. Arbeiten Sie zusammen, um die richtige Lösung zu finden, anstatt auf der Jagd nach einem schnellen Ergebnis in die falsche Option zu stürzen. Andernfalls könnten Sie mit einer Frankenstein-Schulungslösung enden... und das sieht sehr beängstigend aus.

Vielen Dank, dass Sie sich den ersten Teil dieser PCI-DSS-Miniserie angesehen haben. Im letzten Kapitel werden wir erörtern, wie CISOs und CTOs diesen Kulturwandel unterstützen, Teams befähigen und wie die Sicherheitsfront - Ihre Entwickler-Kohorte - PCI-DSS-Bewusstsein und Compliance zu ihrem Vorteil nutzen können.

Ähnlich wie die Technologie selbst entwickeln sich auch die Werkzeuge, Techniken und optimalen Prozesse für die Entwicklung von Code schnell weiter. Wir Menschen haben ein unstillbares Bedürfnis nach mehr Software, mehr Features, mehr Funktionalität... und wir wollen es schneller als je zuvor, qualitativ hochwertiger und obendrein: sicher. Noch vor ein paar Jahren war die agile Entwicklung das nächste große Ding, mit dem man große Arbeitspakete in kleinere Stücke aufteilen und sich schnell an die schnellen Feedback-Zyklen des Kunden anpassen konnte. Davor war die Wasserfall-Methode der König des Hügels.

Während viele Menschen und Organisationen von Waterfall zu Agile übergehen - und noch sind nicht alle so weit, seien wir ehrlich - stoßen sie bereits auf ein neues Problem: Entwicklungsteams und ihre operativen Gegenstücke arbeiten immer noch in Silos. Wie können in dieser Umgebung kleine Teams, die agil arbeiten, das Versprechen einer schnelleren Bereitstellung und einer schnelleren Lieferung einlösen?

DevOps, eine Wortschöpfung aus Development und Operations, wurde geschaffen, um die Funktionen von Entwicklern und Betriebsteams bei der Erstellung neuer Software zusammenzuführen. Im Wesentlichen sollte dies den Entwicklern helfen, die Verantwortung dafür zu übernehmen, Dinge in die Produktion zu bringen, anstatt sie über den Zaun zu werfen und dem Betriebsteam zu überlassen.

Sie können sicherlich schneller liefern - sogar ein paar Mal pro Tag -, was Agile entgegenzukommen scheint. Allerdings schafft DevOps immer noch ein großes, gemischtes Team aus Ingenieuren und Betriebspersonal, das in der Realität vielleicht nicht so agil ausgerichtet ist. Letztendlich ist es am besten, DevOps als eine Weiterentwicklung von Agile zu betrachten, da die Methoden in vielerlei Hinsicht ähnlich sind und sich in ihren Unterschieden ergänzen. DevOps fördert eine automatisierte, kontinuierliche Integrations- und Deployment-Pipeline, die für häufige Releases unerlässlich ist, aber auf Teamebene nicht ausreicht - und hier kommt Agile ins Spiel. Agile ermöglicht es Teams, insbesondere kleinen Teams, mit diesen schnellen Releases und sich ändernden Anforderungen Schritt zu halten, während sie gleichzeitig bei der Sache bleiben und zusammenarbeiten. Es scheint sicherlich ideal zu sein - und der Prozess kann Teams auf dem Weg zum Endziel halten - aber es ist nicht ohne Probleme.

Software, die mit DevOps-Best-Practice erstellt wurde, hat immer noch das Potenzial, beim ersten Bosskampf zu stolpern: dem Sicherheitsteam. Wenn der Code von traditionellen/Wasserfall-AppSec-Spezialisten untersucht wird, entweder mit Tools oder durch komplexe manuelle Überprüfung, finden sie oft inakzeptable Risiken und Schwachstellen, die dann im Nachhinein behoben werden müssen. Der Prozess der nachträglichen Behebung von Sicherheitslücken in fertigen Apps ist weder schnell noch einfach... und er ist für das Unternehmen viel teurer.

Wenn sich die Welt also nach Wasserfall, Agile und jetzt DevOps weiterentwickelt, was ist dann die Lösung? Und welche Rolle spielen Sie als Entwickler, um mit diesen Veränderungen im Ansatz Schritt zu halten?

Entwicklungstechniken befinden sich in einem ständigen Prozess der Evolution, aber zum Glück ist diese hier keine so große Veränderung. Unternehmen müssen nur das "Sec" in "DevOps" einfügen... und so wurde DevSecOps geboren. Ein primäres Ziel von DevSecOps ist es, Barrieren abzubauen und die Zusammenarbeit zwischen Entwicklungs-, Betriebs- und - nicht zuletzt - Sicherheitsteams zu öffnen. DevSecOps hat sich sowohl zu einer Software-Engineering-Taktik als auch zu einer Kultur entwickelt, die die Automatisierung und Überwachung der Sicherheit während des gesamten Softwareentwicklungszyklus befürwortet.

Dies mag wie ein weiterer Prozess auf Organisationsebene erscheinen, vielleicht einer mit "zu vielen Köchen", wenn es um einen Entwickler mit einer langen Liste von zu erstellenden Funktionen geht. Die DevSecOps-Methodik eröffnet jedoch eine Chance für sicherheitsbewusste Entwickler, wirklich zu glänzen.

Die strahlende Zukunft von DevSecOps

Also, warum sollte ein Programmierer ein DevSecOps-Ingenieur werden wollen? Vielleicht haben Sie schon etwas Erfahrung mit DevOps (oder sogar Agile), möchten aber den nächsten Schritt machen, um DevSecOps zu beherrschen. Zunächst einmal ist es gut zu wissen, dass dies ein sehr kluger Schritt ist, und zwar nicht nur im Bestreben, die Welt vor kostspieligen Cyberangriffen sicher zu machen. Experten sagen, dass die Nachfrage nach talentiertem Cybersecurity-Personal sprunghaft ansteigt und kein Ende in Sicht ist. Diejenigen, die DevSecOps beherrschen, können eine lange und profitable Karriere erwarten.

Die Jobsicherheit für DevSecOps-Ingenieure ist sogar noch sicherer, denn im Gegensatz zu traditionellen Cybersecurity-Taktiken wie Schwachstellen-Scans mit einer Reihe von softwarebasierten Tools erfordert DevSecOps Mitarbeiter, die wissen, wie man Sicherheit beim Programmieren implementiert. Wie die Analysten von Booz, Allen und Hamilton in ihrem Blog mit dem Titel " 5 Myths of Adopting DevSecOps " feststellten , wollen und brauchen Unternehmen DevSecOps, können es aber nicht einfach kaufen. DevSecOps ist eine Methodik, die es funktionsübergreifenden Teams ermöglicht, Technologien zu integrieren und während des gesamten Lebenszyklus der Softwareentwicklung zusammenzuarbeiten, und das erfordert qualifizierte Mitarbeiter, Change Management und ein fortlaufendes Engagement mehrerer Interessengruppen.

Laut Booz, Allen and Hamilton können Unternehmen Apps und Tools kaufen, die bei bestimmten Aspekten von DevSecOps helfen, wie z. B. Software für das Release-Management, "aber es sind wirklich Ihre Delivery-Teams, die es umsetzen." Sie sind diejenigen, die die kontinuierliche Verbesserung vorantreiben, die DevSecOps und sein Kultur- und Paradigmenwechsel bieten.

Unternehmen können ein praktikables DevSecOps-Programm nicht "kaufen". Es muss mit einer Reihe von Tools, firmeneigenem Wissen und Anleitungen aufgebaut und gepflegt werden, die die Sicherheitskultur verbessern und gleichzeitig wirtschaftlich sinnvoll sind. Das ist nicht einfach, aber bei weitem nicht unmöglich.

Wie Sie der DevSecOps-Bewegung in den Arsch treten können

Einer der ersten Schritte auf dem Weg zum DevSecOps-Ingenieur ist die Erkenntnis, dass es sich dabei ebenso sehr um eine Kultur wie um eine Reihe von Techniken handelt. Es erfordert den Willen, Sicherheit als Teil jedes Codes zu implementieren, den Sie erstellen, und den Wunsch, Ihre Organisation proaktiv zu schützen, indem Sie aktiv nach Sicherheitslücken und Schwachstellen suchen, während Sie programmieren, und diese beheben, lange bevor sie in die Produktion gelangen. Die meisten DevSecOps-Ingenieure nehmen ihren Beruf und ihre Fähigkeiten sehr ernst. Die professionelle DevSecOps-Organisation hat sogar ein Manifest, das ihre Überzeugungen festhält.

Das Manifest ist etwas schwerfällig, denn Manifeste sind selten leichte Lektüre. Aber im Kern stehen ein paar Wahrheiten, die alle großen DevSecOps-Ingenieure verinnerlichen sollten, wie z. B.:

• Erkennen Sie, dass das Anwendungssicherheitsteam Ihr Verbündeter ist. In den meisten Unternehmen sind die AppSec-Spezialisten mit den Entwicklern verfeindet, da diese immer wieder fertigen Code für mehr Arbeit zurückschicken. AppSec-Teams haben oft auch nicht viel Liebe für die Entwickler, da sie durch das Einbringen von allgemeinen Sicherheitsfehlern den fertigen Code davon abhalten können, in Produktion zu gehen. Ein kluger DevSecOps-Ingenieur wird jedoch erkennen, dass die Ziele der Sicherheitsteams letztlich die gleichen sind wie die der Entwickler und Coder. Sie müssen nicht die besten Freunde sein, aber eine ruhige und kollaborative Arbeitsbeziehung zu bilden, ist entscheidend für den Erfolg.
• Üben und verfeinern Sie Ihre sicheren Codierungstechniken. Wenn Sie Möglichkeiten finden, wie Apps angreifbar sind, während sie noch entwickelt werden, dann kann das Schließen dieser Schlupflöcher zukünftige Hacker aufhalten. Natürlich erfordert dies sowohl ein Verständnis der Schwachstellen als auch die Tools, die helfen, diese zu beheben. Die Blog-Seiten vonSecure Code Warrior geben Ihnen einen Einblick in die häufigsten und gefährlichsten Schwachstellen sowie praktische Ratschläge und Herausforderungen, mit denen Sie Ihr Wissen testen können. Der wichtigste Aspekt ist, dass Sie sich das Thema Sicherheit immer vor Augen halten und sich Zeit für mundgerechte Schulungen nehmen, die Ihnen dabei helfen, Ihr vorhandenes Wissen auszubauen. Es ist üblich, dass die Interaktionen eines Entwicklers mit der Sicherheit ziemlich unauffällig - sogar negativ - sind, aber die Weiterbildung im Bereich Sicherheit ist ein großartiger Karriereschritt und muss keine lästige Pflicht sein.
• Nicht vergessen: DevSecOps-Superstars tragen zu einer positiven Sicherheitskultur in ihrer Organisation bei. Anstatt sich auf die Ziele der Vergangenheit zu konzentrieren, wie z. B. die schnelle Bereitstellung von Apps ungeachtet ihrer inhärenten Probleme, ist es wichtig, das Finden und Beheben von Schwachstellen im Entwicklungscode zur obersten Priorität zu machen. Sicherheit muss als Aufgabe für alle angesehen werden, und jeder sollte an der Bewunderung und den Belohnungen teilhaben, die sich aus der Bereitstellung effektiver und hochsicherer Anwendungen ergeben - und zwar jedes Mal.

Sie können dabei helfen, eine unglaubliche Sicherheitskultur in Ihrem Unternehmen zu kultivieren, indem Sie sich von Anfang an für sicheres Coding und bewährte Sicherheitspraktiken einsetzen, Schulungslösungen empfehlen und dafür sorgen, dass kein Programmierer in der schnelllebigen Welt von DevSecOps zurückgelassen wird, der alle Hände voll zu tun hat. Der einzige gute Code ist sicherer Code, und qualifizierte, sicherheitsbewusste Entwickler sind wichtige Teile des Puzzles. Die persönlichen und beruflichen Belohnungen sind die Mühe auf jeden Fall wert, und angesichts der Milliarden von persönlichen Datensätzen, die jedes Jahr kompromittiert werden (Tendenz steigend), brauchen wir Sie. Nehmen Sie Ihren Platz an der Front ein und helfen Sie, die bösen Jungs in unserer digitalen Welt abzuwehren.

Matias Madou, Ph.D. ist der CTO und Mitbegründer von Secure Code Warrior. Er ist ein Sicherheitsexperte, langjähriger Entwickler und Fortnite-Junkie.

Es gibt eine bekannte Theorie, dass Kakerlaken im Grunde alles überleben können - sogar eine Atomexplosion. Obwohl diese Theorie nur bis zu einem gewissen Punkt wahr ist, macht ihr einfacher Körperaufbau sie für ihre Größe extrem widerstandsfähig und unter den meisten Bedingungen schwer auszurotten.

Ich habe nachgedacht... wenn Kakerlaken ein Äquivalent in der digitalen Welt hätten, dann müssten es SQL-Injection (SQLi)-Schwachstellen im Code sein. Diese Schwachstelle ist seit mehr als zwanzig Jahren bekannt, dennoch werden Unternehmen immer wieder Opfer davon. Der weit verbreitete, kostspielige Angriff auf Target war das Ergebnis von SQL-Injection, ebenso wie ein Fall von Wahl-Hacking in Illinois, bei dem 200.000 Wählerdaten offengelegt wurden, was das FBI dazu veranlasste, allen IT-Administratoren zu empfehlen, ihre Sicherheitspraktiken schnell zu verbessern.

Der Hacker Intelligence Initiative Report von Imperva zeigte, dass zwischen 2005 und 2011 SQLi-Angriffe bei 83 % aller gemeldeten Datenverletzungen verwendet wurden. Heute sind Injektionsschwachstellen nach wie vor die Bedrohung Nummer eins in der OWASP Top 10. Sie sind relativ einfach, aber sie wollen einfach nicht verschwinden.

Es erscheint lächerlich, dass dieselbe Schwachstelle immer noch in einer beträchtlichen Anzahl von Anwendungssicherheitsscans auftaucht. Wir wissen, wie sie funktioniert, und wir wissen, wie man sie stoppen kann. Wie ist das möglich? Die Wahrheit ist, dass unsere Softwaresicherheit noch sehr viel Raum für Verbesserungen hat.

Der State of Software Security Report von Veracode - basierend auf 400.000 Anwendungsscans im Jahr 2017 " enthüllte eine alarmierende Statistik: Nur 30 % der Anwendungen bestanden die OWASP Top 10-Richtlinie. Dies war in den letzten fünf Jahren ein durchgängiges Thema, wobei SQL-Injections in fast 1 von 3 neu gescannten Anwendungen auftraten. Dies ist ein Beweis für ein endemisches Problem; wir lernen nicht aus unseren Fehlern, und CISOs scheinen einen schweren Stand zu haben, wenn es darum geht, genügend Sicherheitstalente zu beschaffen. Typischerweise ist das Verhältnis von AppSec-Spezialisten zu Entwicklern ein unzureichendes 1:100.

Warum ist die Software-Sicherheit auf Lebenserhaltung?

Es ist kein Geheimnis, dass spezialisierte Sicherheitstalente knapp sind, aber wir müssen auch die Tatsache berücksichtigen, dass Entwickler Probleme nicht beheben, wenn sie entstehen, und ganz offensichtlich schlecht ausgerüstet sind, um Schwachstellen gar nicht erst einzuführen. In demselben Veracode-Bericht wurde enthüllt, dass es für nur 14,4 % aller Entwicklungsschwachstellen dokumentierte Abhilfemaßnahmen gab. Mit anderen Worten: Die meisten Schwachstellen wurden ohne Entwicklungsabschwächung eingereicht. Weniger als ein Drittel der Schwachstellen wurden in den ersten 90 Tagen geschlossen, und 42 % der Schwachstellen wurden nie innerhalb der Entwicklungszeit geschlossen.

Ich spreche ständig mit Sicherheitsexperten, CISOs und CEOs, und anekdotisch habe ich festgestellt, dass viele Unternehmen von der Anzahl der gefundenen Schwachstellen, die nicht entschärft werden können, so frustriert sind (zusätzlich zu der Geißel, die als False Positives bekannt ist), dass sie das Scannen nach diesen Schwachstellen ganz einstellen, die Finger kreuzen und auf das Beste hoffen.

Warum lassen AppSec-Profis dies geschehen?

Machen Sie keinen Fehler: AppSec-Mitarbeiter sind sich der Probleme im Code schmerzlich bewusst. Schließlich ist das eine ihrer Kernkompetenzen, die sie zu einer so wertvollen Teamressource macht. Allerdings werden sie oft durch mehrere Faktoren behindert.

Zum Beispiel wird ein AppSec-Manager ein Problem finden und den Entwickler fragen: "Können Sie den Code reparieren?". Die Antwort auf diese wichtige Frage ist von Unternehmen zu Unternehmen unterschiedlich, aber in der Regel sind die Entwickler so sehr damit beschäftigt, strenge Feature-Delivery-Sprints einzuhalten, dass sie einfach nicht die Zeit haben, diese Probleme zu beheben, und auch keine anständigen Tools, die ihnen dabei helfen. AppSec-Profis selbst können zwar Schwachstellen identifizieren, haben aber oft nicht die Fähigkeiten und/oder den Zugang, um sie an Ort und Stelle zu beheben.

Wir müssen auch erkennen, dass es für jedes Problem einen Prozess gibt, in dem eine Lösung gefunden, implementiert und dann getestet werden muss. Selbst für das kleinste Problem, das im Code gefunden wird, ist der Zeitaufwand zur Behebung immens, ganz zu schweigen von den benötigten Ressourcen. Es gibt über 700 Schwachstellen, die in Software eingeschleust werden können, und es ist für eine einzelne Person schlicht unmöglich, sich gegen alle zu verteidigen. Aus diesem Grund halten sich die meisten Unternehmen nur an die OWASP Top 10. Die ganze Zeit über entwickeln die Entwickler neue Funktionen, und im Gegenzug führen sie immer wieder Schwachstellen in den Code ein, den sie schreiben.

Was ist die Lösung?

Die einfache Tatsache ist, dass wir unseren Entwicklern nicht die Werkzeuge und das Training geben, um einen sicheren Kodierungserfolg zu fördern. Es gibt keine Vorschriften, die Unternehmen dazu zwingen, dafür zu sorgen, dass Entwickler über angemessene Sicherheitskenntnisse verfügen, und es ist eine traurige Realität, dass die meisten Universitäten und Praktika junge Entwickler auch nicht darauf vorbereiten, sicher zu programmieren.

Wenn jemand ein Flugzeug fliegen möchte, gibt es einen sehr strengen Prozess, der Ausbildung, praktische Erfahrung, medizinische Checks, Sicherheitswissen und Prüfungen sicherstellt, bevor er fliegen kann. Niemand würde es wagen, sich vorzustellen, dass er ohne diese umfangreiche Vorbereitung und Validierung der Fähigkeiten in den Himmel losgelassen wird, doch genau das passiert tagtäglich beim Schreiben von Code.  

Wir müssen die Zeit aufwenden, um Entwickler im Schreiben von sicherem Code zu schulen. In der heutigen Welt, in der die Softwareentwicklung schnelllebig ist und gute Entwickler und Sicherheitsexperten Mangelware sind, scheint dies jedoch nie eine Priorität zu sein. Es ist an der Zeit, dass wir die Konversation ändern.

Eine kürzliche Schlagzeile des Weltwirtschaftsforums schrie: "Es gibt keine digitale Wirtschaft ohne Sicherheit", und der begleitende Inhalt argumentiert, dass Sicherheit ein zentraler Bestandteil jeder Strategie zur digitalen Transformation sein muss. "Sicherheit ist das, was Unternehmen schützt und es ihnen ermöglicht, innovativ zu sein und neue Produkte und Dienstleistungen zu entwickeln. Über eine defensive Rolle hinaus bietet Sicherheit den Unternehmen einen strategischen Wachstumsvorteil."

Die Verbesserung von Fähigkeiten und Ergebnissen im Bereich der sicheren Codierung wird Unternehmen eine zusätzliche Ebene des Cyber-Schutzes bieten und sie dabei unterstützen, besseren und schnelleren Code zu erstellen. Entwickler müssen keine Sicherheitsexperten werden, aber sie müssen positiv und praktisch dazu befähigt werden, die erste Verteidigungslinie gegen Cyberangriffe zu sein. Entwickler können die nächsten Sicherheits- und Innovationshelden sein. Sie sind sehr kluge Menschen, sie sind kreative Problemlöser und im Allgemeinen sehr daran interessiert, ihre Fähigkeiten auszubauen. Nutzen Sie ihre Stärken mit der spezialisierten Ausbildung, die sie verdienen, und verpflichten Sie sich zu einem höheren Software-Sicherheitsstandard. Lesen Sie unser Whitepaper, um mehr darüber zu erfahren.

Wenn jemand ein Flugzeug fliegen möchte, gibt es einen sehr strengen Prozess, der Ausbildung, praktische Erfahrung, medizinische Checks, Sicherheitswissen und Prüfungen sicherstellt, bevor er fliegen kann. Niemand würde es wagen, sich vorzustellen, dass er ohne diese umfangreiche Vorbereitung und Validierung der Fähigkeiten in den Himmel losgelassen wird, doch genau das passiert tagtäglich beim Schreiben von Code.