Vor kurzem wurde ich für den Silver Bullet-Podcast interviewt, der von Gary McGraw moderiert wird. Darin sprach ich über die Vorteile der Industrie gegenüber der akademischen Forschung, warum es nicht trivial war, ein Unternehmen in Europa zu gründen und wohin sich die Application Security-Branche in Zukunft entwickeln wird.

Es war zwar nie meine Absicht, ein Unternehmen zu gründen, aber ich habe es getan, weil ich gesehen habe, dass zu viele Unternehmen mit dem gleichen Problem zu kämpfen haben: Das Schreiben von sicherem Code ist für die meisten Entwickler eine Herausforderung. Wir haben eine ganze Branche, die sich darauf konzentriert, Sicherheitsprobleme im Code zu finden, und diese Probleme häufen sich einfach an.

Es gibt nur sehr wenige Lösungen, die tatsächlich darauf ausgerichtet sind, Organisationen und deren Entwicklungsteam effizient zu unterstützen, die sich mit der Behebung der gefundenen Probleme abmühen, und noch weniger darauf, zu verhindern, dass weitere Probleme in den Code eingebracht werden. Immer mehr Organisationen werden sich dieses Teufelskreises bewusst und erkennen, dass ihr Entwicklungsteam von Anfang an für das Schreiben von sicherem Code geschult und mit den entsprechenden Tools und Prozessen ausgestattet werden muss, um dies zu ermöglichen.

Wenn Sie mehr darüber wissen wollen, wie Gary McGraw und ich die Zukunft der Branche sehen, hören Sie sich den Silver Bullet-Podcast an!

Show 139: Matias Madou diskutiert über Schulungen zur sicheren Entwicklung und Forschung im Bereich Software-Sicherheitstests

https://www.synopsys.com/software-integrity/resources/podcasts/show-139.html

Wenn ich Sie fragen würde, wie viel es kosten würde, nur eine Zeile Computercode in einem Gerät zu ändern, das bereits in Betrieb ist, welche Zahl würde Ihnen einfallen? Ein paar hundert Dollar? Vielleicht Tausende?

Laut Aviation Today kostet es eine Million Dollar für eine kommerzielle Fluggesellschaft, eine Codezeile in ihren Flugzeugen zu aktualisieren. Für so beträchtliche Kosten bräuchten sie wahrscheinlich einen zwingenden Grund, um die erforderlichen Schritte für ein Update ihrer Flugzeugsysteme zu unternehmen, was mich wirklich zum Nachdenken über eine Reihe von Faktoren brachte.

Aufschlüsselung der Kosten

Der Artikel beschreibt zwar nicht, wie sich die Kosten von 1 Million Dollar zusammensetzen, aber ich denke, es ist eine realistische Zahl. Ich bin kein Experte speziell für Software-Updates bei Fluggesellschaften, aber ich kann ein paar der Schritte erahnen, die die Fluggesellschaft in dieser Situation unternehmen muss.

Zunächst muss die Fluggesellschaft einen Fehler oder eine Schwachstelle entdecken, die das Update erforderlich macht. Das zitierte Beispiel besteht aus einer Untersuchung, die vom U.S. Department of Homeland Security (DHS) an einer Boeing 757 durchgeführt wurde. Die Ergebnisse - ein Remote-Hack nach nur zwei Tagen Arbeit - sind für jede Fluggesellschaft mehr als überzeugend genug, um zur Kenntnis genommen zu werden.

Von dort aus müssen die Softwareentwickler die Ergebnisse analysieren, neuen Code schreiben und diesen in einer sicheren Umgebung testen, um sicherzustellen, dass das Problem behoben ist. Jetzt kommt der knifflige Teil. Die Fluggesellschaft muss jedes anfällige oder fehlerhafte Flugzeug am Boden halten, den neuen Code anwenden, ihn testen, um sicherzustellen, dass er mit diesem speziellen Flugzeug funktioniert, und dann den Plan für den kommerziellen Flug erneut zertifizieren.

Laut airfleets.net hat Southwest Airlines derzeit 499 Flugzeuge vom Typ Boeing 737-700 in ihrer Flotte. Bedenken Sie die Zeit- und Geldinvestitionen, die entstehen, wenn eine Sicherheitslücke in diesem speziellen Flugzeugmodell auftaucht.

Nicht nur eine Herausforderung für Fluggesellschaften

Es ist klar, dass Fluggesellschaften ein großes Interesse daran haben sollten, von Anfang an solide und sichere Kodierungsprinzipien anzuwenden. Nachdem ich kurz darüber nachgedacht hatte, konnte ich mir zahlreiche Branchen und Situationen vorstellen, in denen ähnliche Kosten anfallen könnten. Anstatt sich Sorgen über Flugzeuge zu machen, die aufgrund einer gehackten Sicherheitslücke vom Himmel fallen, was ist mit medizinischen Geräten wie Herzschrittmachern? Wie viel kostet es, eine halbe Million lebensrettender Elektronikteile zurückzurufen und zu aktualisieren?

In der Automobilindustrie hören wir immer wieder Gerüchte und Sicherheitsbedenken über selbstfahrende Autos. Doch selbst unsere "typischen" Fahrzeuge sind mehr denn je auf die Konnektivität mit dem Internet angewiesen, was direkt zu einigen beunruhigenden - wenn auch unterhaltsamen - Sicherheitsbedenken führt.

Es ist eine einfache Tatsache, dass es viel mehr Geld, Aufwand und Zeit kostet, Geräte oder Systeme zu aktualisieren, nachdem sie in einer Produktionsumgebung freigegeben wurden oder bevor sie in Serie produziert wurden, als Sicherheit in den ursprünglichen Entwicklungsprozess einzubauen. Dennoch werden jeden Tag neue vermeidbare Softwarefehler und Cybersicherheitslücken entdeckt, was die Notwendigkeit für Unternehmen unterstreicht, nach Wegen zu suchen, um sichere Softwareentwicklung in ihre Entwicklungskultur einzubauen.

Die Kosten für die Änderung einer Code-Zeile in einem Avionikgerät belaufen sich auf 1 Million Dollar, und die Implementierung dauert ein Jahr. Für Southwest Airlines, deren Flotte auf der 737 von Boeing basiert, wäre es der "Bankrott", wenn eine Cyber-Schwachstelle speziell die Systeme an Bord der 737 betreffen würde

‍

Der Schwerpunkt der meisten Diskussionen über Cybersicherheit bezieht sich auf den Schutz von Geld, Ruf und Informationen. In Finanzinstituten geht es oft um die Bedrohung der persönlichen oder Unternehmensfinanzen. In der Telekommunikationsbranche geht es eher um persönliche Identitätsinformationen oder den Diebstahl geistigen Eigentums. Auf Regierungsebene ist Cyber-Spionage eine relativ einfache und kostengünstige Möglichkeit, an hochwertige Informationen zu gelangen.

Die Gefahren von Cyberangriffen auf die physische Infrastruktur, einschließlich SCADA (Supervisory Control and Data Acquisition) und ICS (Industrial Control Systems), sind jedoch sehr real, wachsen und sind beängstigend, wie ein aktueller Artikel der New York Times über einen Angriff auf ein petrochemisches Unternehmen mit einer Anlage in Saudi-Arabien erklärt.

Im Öl- und Gassektor können Angriffe auf die Cybersicherheit zu Explosionen führen. Lange Zeit waren diese Anlagen nicht mit Netzwerken verbunden, aber jetzt sind sie im Interesse der Einfachheit der Verwaltung alle gefährlich verbunden. Die Wahrscheinlichkeit, dass diese Anlagen angegriffen werden - und zwar erfolgreich - ist jetzt viel höher. Diese Anwendungen wurden NICHT mit Blick auf die Sicherheit entwickelt, denn es war nicht die Absicht, sie mit dem Internet zu verbinden.

Der NYT-Artikel beschreibt einen Angriff, der nicht nur darauf abzielte, Daten zu zerstören oder die Anlage herunterzufahren, sondern auch den Betrieb der Firma zu sabotieren und eine Explosion auszulösen, die wahrscheinlich andere Menschen schädigen würde. Die Ermittler sagten, das Einzige, was eine Explosion verhinderte, war "ein Fehler im Computercode der Angreifer", von dem sie glauben, dass die Hacker ihn "wahrscheinlich inzwischen behoben haben". Die Ermittler glauben, dass es "nur eine Frage der Zeit" ist, bis sie die gleiche Technik erfolgreich gegen ein anderes Unternehmen einsetzen.

Softwareentwickler werden zu wichtigen Architekten, die den Erfolg und die Sicherheit vieler öffentlicher und privater Organisationen untermauern. Es gibt kein größeres Beispiel als in der Öl- und Gasindustrie. Es ist wichtiger denn je, dass sie die Auswirkungen ihrer Arbeit auf die Sicherheit besser kennen und lernen, sicher zu programmieren, egal welche Sprache oder Frameworks sie verwenden.

Wenn Sie sehen möchten, wie Entwickler etwas über Sicherheit lernen können, um zum Schutz kritischer Infrastrukturen beizutragen, spielen Sie die folgende Herausforderung:

https://portal.securecodewarrior.com/#/simple-flow/web/injection/oscmd/cpp/vanilla

Das einzige, was eine Explosion verhinderte, war ein Fehler im Computercode der Angreifer, sagten die Ermittler.

https://www.nytimes.com/2018/03/15/technology/saudi-arabia-hacks-cyberattacks.html

Der Cyberangriff war nicht darauf ausgelegt, einfach nur Daten zu zerstören oder die Anlage herunterzufahren, glauben die Ermittler. Es war beabsichtigt, eine Explosion auszulösen. https://t.co/kQqcAhoW01

" The New York Times (@nytimes) March 15, 2018

Ein Cyberangriff in Saudi-Arabien hatte ein tödliches Ziel. Experten fürchten einen weiteren Versuch. https://t.co/q9UdicR7dv

" Colin Wright (@colinismyname) March 22, 2018

Der Angriff war eine gefährliche Eskalation im internationalen Hacking, da gesichtslose Gegner sowohl den Willen als auch die Fähigkeit demonstrierten, schweren physischen Schaden anzurichten. https://t.co/G8bBCteouZ#CyberSecurity #NetworkMonitoring

" Elitery Indonesia (@eliterydc) March 22, 2018

Ein kürzlich gescheiterter #Cyberangriff auf ein saudi-arabisches Petrochemie-Unternehmen hatte ein tödliches Ziel. Dieser @NYTimes-Artikel erklärt mehr: https://t.co/3g8oDuPijm pic.twitter.com/MfSqrXSd9u

" Symantec EMEA (@SymantecEMEA) March 21, 2018

Auf einem Langstreckenflug habe ich kürzlich die Gelegenheit genutzt, um eine, offen gesagt, wahnsinnige Menge an Podcast-Episoden zu verschlingen. Mit so vielen verschiedenen Serien auf dem Laufenden zu bleiben, bedeutet, dass ich nie zu wenig zu hören habe, mit fesselnder - wenn auch einseitiger - Konversation, die nur eine Berührung meines Telefondisplays entfernt ist.

Schließlich landete ich bei einer Folge des Podcasts für wahre Verbrechen, Casefile. Diese dramatische, schonungslose Serie (komplett mit einem bedrohlich klingenden und namenlosen Moderator) beschäftigt sich mit einem Thema, das selbst die sachkundigsten und versiertesten Technologen fasziniert: das Deep Web und der katastrophale Aufstieg der Schmuggel-Website Silk Road. Aufgeteilt in zwei Teile, hätten diejenigen, die mit dem Aufstieg und Fall von Silk Road vertraut sind, zweifellos die Nachrichten über den Fall verfolgt, aber der Podcast enthüllt jedes kleine Detail in einer köstlichen, mitreißenden Erzählung.

Die Seidenstraße: Lektionen aus dem Deep-Web-Kerker

Wenn Sie mit den Vorgängen auf der Silk Road nicht vertraut sind, lautet die Kurzfassung, dass ein Mann eine Handelswebsite im Deep Web aufgebaut hat, die vor den neugierigen Augen der Öffentlichkeit verborgen und ohne den Einsatz spezieller Software - dem Tor-Browser, um genau zu sein - nicht einsehbar ist. Die Seite bot zunächst nur seine selbst gezüchteten Magic Mushrooms an, explodierte aber praktisch über Nacht mit Verkäufern, die alles von Hardcore-Drogen über illegale Waffen bis hin zu gestohlenen Kreditkartendaten anboten. Sie können sich hier auf den neuesten Stand bringen. Der Schöpfer und Administrator der Seite trug das von der Prinzessin Braut inspirierte Pseudonym Dread Pirate Roberts. Er war jeder, er war niemand. Alle Benutzer handelten mit einer wahren Fülle an illegalen Gütern, und sie taten dies völlig anonym (und verschafften Bitcoin damit einen Ruf als bevorzugte Währung für Drogendealer; ein Moniker, den es gerade erst zu erschüttern beginnt).

Doch das Anti-Establishment-Experiment von Dread Pirate Roberts war eine Bestie für sich. Bald warben Auftragskiller für ihre Dienste. Böse Menschen taten böse Dinge... und er war berauscht von seinem neugewonnenen unergründlichen Reichtum. Er versuchte sogar, die Dienste eines Auftragskillers in Anspruch zu nehmen, um einen ehemaligen Angestellten loszuwerden. Langer Rede kurzer Sinn, dies war eine von vielen unüberlegten Entscheidungen, die sein Verderben herbeiführten. Er wurde als Ross Ulbricht enttarnt und verrottet derzeit in einer US-Gefängniszelle, wo er eine doppelte lebenslange Haftstrafe plus vierzig Jahre ohne die Möglichkeit der Bewährung verbüßt.

Aber, wie wurde er erwischt, wenn alles völlig privat und anonym war?

Nun, um es ganz offen zu sagen: Er war ein ziemlich beschissener Programmierer. Die Seidenstraßen-Website selbst war wie ein alter, leckgeschlagener Kahn, der im Ozean festsaß. In Anbetracht der Tatsache, dass es sich um ein Zentrum illegaler Aktivitäten handelte (und all der Daten, die hinter diesen Aktivitäten standen), war sie überhaupt nicht sicher; sie war eine leichte Beute, die nur darauf wartete, von einem opportunistischen Hacker ausgenutzt zu werden. Um fair zu sein, wenn man das Mastermind eines riesigen, illegalen Drogenhandelsgeschäfts ist, ist es wahrscheinlich nicht einfach, kompetente Mitarbeiter zu finden, die sich auf diese Operation einlassen wollen. Er machte auch keinen Hehl aus seiner Kompetenzlücke - er postete sogar unter seinem richtigen Namen auf Stack Overflow (ja, das ist sein Benutzerkonto) und bat um Hilfe, um den Code seiner Seite richtig zu konfigurieren, damit er sich mit Curl in PHP mit Tor verbinden kann. Er änderte seinen echten Namen in den Handle "frosty" weniger als eine Minute nach dem Posting, aber das hat offensichtlich nicht geholfen... in der Tat hat es wahrscheinlich weiteren Schaden angerichtet: der Verschlüsselungsschlüssel auf dem Silk Road Server endete mit der Teilzeichenkette "frosty@frosty", was ihn weiter verwickelte, als das FBI Wind von seiner Spur bekam.

Trotz eines so großen Vorstoßes für die Privatsphäre, mit verschlüsselten Nachrichten, Währung und explizite Anweisungen zur Sicherung der Schmuggelware selbst in Transit und Lieferung, die Website war nicht die undurchdringliche Festung der libertären Fantasie, die Ulbricht vielleicht vorgestellt haben. Diejenigen mit den Fähigkeiten (lesen: Programmierer vom FBI beschäftigt) langsam, aber sicher, entwirrt es alles zu offenbaren ... einschließlich der Identitäten von Tausenden von Menschen, die auf der Website transacted. Es ist möglich, dass diejenigen, die vor vielen Jahren unanständige Waren gekauft haben, irgendwann vom langen Arm des Gesetzes an die Tür geklopft werden, wie dieser Typ in Deutschland. Igitt.

Das FBI veröffentlicht Dokumentation skizziert, wie sie in der Lage waren, Silk Road zu durchdringen, mit der allgemeinen Erklärung, dass der Nutzung einer IP-Adresse Leck. Eine Fehlkonfiguration der Silk-Road-Login-Seite verriet die IP-Adresse und damit den physischen Standort der Server, ohne dass ein heimtückisches Hacken erforderlich war. Ein Anfängerfehler, um sicher zu sein, und eine, die schließlich führte das FBI direkt zu Ross Ulbricht.

Es gibt Spekulationen, dass diese Schwachstelle - wenn es sie denn gäbe - schon lange vor diesem Zeitpunkt von einem der vielen Sicherheitsexperten, die die Seite überwachen, entdeckt worden wäre. Nik Cubrilovic, ein australischer Sicherheitsberater, behauptet in einem Interview mit WIRED, dass er einfach nicht vorhanden war:

"Es ist unmöglich, dass man mit einer Tor-Seite verbunden ist und die Adresse eines Servers sieht, der kein Tor-Knoten ist. Die Art und Weise, wie sie versuchen, eine Jury oder einen Richter glauben zu lassen, dass es passiert ist, macht technisch einfach keinen Sinn."

Cubrilovic deutet dann an, dass die Informationen durch illegale Hacking-Praktiken erlangt worden sein könnten. Diese Praxis scheint SQL-Injektion zu sein, ein unbewiesenes Gerücht, das seitdem auf vielen Seiten als plausible Methode der Extraktion diskutiert wurde.

Die Gesetzmäßigkeiten rund um die Taktik des FBI sind eine völlig separate Diskussion. Die Tatsache, dass die Informationen überhaupt erlangt werden konnten, ist ein Hinweis auf die schlechten Sicherheitspraktiken von Silk Road, trotz des allgemeinen Benutzerverständnisses, dass die Seite "privat" ist. Wenn Privatsphäre mit Sicherheit verwechselt wird, erhöht sich mit Sicherheit die Möglichkeit, Schwachstellen zu entdecken.

Es besteht auch die Möglichkeit, dass die Seite immer noch laufen würde (in ihrer ursprünglichen Form, jedenfalls; sie wurde mehrmals wiederbelebt, und es gibt sogar noch größere Seiten wie sie, die gerade in Betrieb sind), wenn Ross Ulbricht die Unterscheidung zwischen Privatsphäre und Sicherheit gemacht hätte und aktiv daran gearbeitet hätte, beides zu gewährleisten, bevor sie zu einer riesigen Wärmelampe wurde, die jeden widerwärtigen Gauner mit leicht überdurchschnittlichen technischen Kenntnissen auf dem Planeten anlockte. Stattdessen wurden der private Club und all seine Geheimnisse in dem Moment enthüllt, als jemand einen Weg fand, die Tür zu öffnen.

Sie sind kein Drogenbaron, also warum sollte Sie das interessieren?

Der Verlust von Silk Road und die Inhaftierung seines Gründers ist keine traurige, mitfühlende Geschichte, sondern eine faszinierende Fallstudie über die nuancierten Unterschiede zwischen Privatsphäre und echter, robuster Site-Sicherheit. Es gibt viele legitime Vorgänge, bei denen Transaktionen und Informationen vertraulich behandelt werden müssen - man denke nur an digitalisierte Krankenakten oder sogar an die Millionen von Kreditkartennummern, die eine große Bank besitzt -, aber wenn sie nicht auch durch eine eiserne Softwareentwicklung gesichert sind, könnten diese Informationen von einem Angreifer abgegriffen werden (und ironischerweise auf einer Website wie Silk Road landen). Privatsphäre gibt es nicht ohne Sicherheit.

Die Guten, wie Sie, könnten Software haben, die anfällig für SQL-Injection-Angriffe und andere Schwachstellen aus den OWASP Top 10 ist, daher ist es wichtig, dass diese vorbereitet und effizient entschärft werden. Wenn Entwickler von Anfang an in sicherem Code geschult werden, werden diese Schwachstellen nicht das Licht der Welt erblicken. Es ist unerlässlich, dass sich Unternehmen auf die Sicherheit konzentrieren und ihre Entwicklerteams zu sicherem Code befähigen. Wir zeigen Ihnen, wie Sie das auf spielerische und messbare Weise tun können. Sind Sie bereit?

Rund um den Globus wandeln sich die Unternehmen. Mit einem starken Fokus auf Digital-First-Business ist es fair zu sagen, dass die meisten Organisationen in der Tat Software-Unternehmen sind. Große Unternehmen zählen riesige Entwicklungsteams zu ihren Mitarbeitern, die mit der konstanten Entwicklung und Bereitstellung von Funktionen in einer agilen DevOps-Umgebung beauftragt sind. Diese Funktionsbereitstellung muss mit dem Innovationstempo und den Kundenerwartungen Schritt halten, sodass Sicherheit allzu oft eher als Hindernis denn als Notwendigkeit angesehen wird. Da unsere Abhängigkeit von Software jedoch so hoch ist wie nie zuvor (und damit auch unsere Anfälligkeit für potenzielle Cybersecurity-Verletzungen und -Risiken), kann dieses Szenario nicht weiter bestehen.

Die Sicherheitsteams werden nicht größer, und selbst wenn sie es könnten, ist das Fachwissen Mangelware. Verhältnisse von 1:100+ sind einfach nicht genug. Eigene Sicherheitsexperten können nicht als einzige Lösung zur Bekämpfung des Cyber-Bedrohungsproblems gesehen werden.

Unser Webinar, präsentiert von Secure Code Warrior's Director (Americas) Stephen Allor und Russ Wolfe, Dean of Cybersecurity bei Capital One, geht detailliert auf die aktuellen Probleme ein, mit denen DevOps konfrontiert ist, und was Finanzinstitute wie Capital One tun, um ihre Entwicklungsteams für sicheres Coding zu engagieren und zu schulen, eine positive Sicherheitskultur effektiv zu fördern und erfolgreich "nach links zu wechseln".

Sie werden entdecken:

• Wenn Sie ein Opfer des "schwarzen Lochs" für Sicherheitswissen sind
• Warum die Sicherheit vor Jahrzehnten robuster war als heute
• Die traditionelle Einstellung zu AppSec als Compliance-"Checkbox" und warum dies bestenfalls oberflächlich ist
• Der Grund, warum Qualitätsbewertungen für Anwendungen die Sicherheit als Teil des Benchmarks einbeziehen müssen; eine unsichere Anwendung kann nicht als hochwertig angesehen werden, unabhängig von ihrem Design oder ihren Funktionen
• Warum die Industrie Software-Sicherheit nicht in die Denkweise und Kultur des durchschnittlichen Entwicklers eingebaut hat (und warum sich das ändern muss)
• Wie der Mangel an gemeinsamen Fähigkeiten zur sicheren Programmierung dafür sorgt, dass immer wieder die gleichen Schwachstellen auftreten
• Warum Tools zum Scannen von Anwendungen nicht jede Schwachstelle finden und warum es sinnvoller ist, sie durch den Einsatz ausreichend geschulter Sicherheitsingenieure/-entwickler zu vermeiden
• Das Problem der zunehmenden Sicherheitslücken in Software und deren Ursache
• Warum sich die Herangehensweise, nicht der Schüler, ändern muss, um eine echte Risikominderung zu erreichen
• Warum die meisten Sicherheitsschulungen die Stärken von Entwicklern nicht ausspielen und welche Art von Training sie benötigen, um sich auszuzeichnen
• Die Gründe, warum die Compliance und die Build-Erwartungen in der Software-Entwicklung hinter anderen Bereichen der Technik zurückbleiben, und wie wir die Lösung für dieses Problem vorantreiben
• Wie Russ Wolfe und sein Team bei Capital One ein Zertifizierungsprogramm entwickelt haben, das auf unterhaltsamen, spielerischen Schulungen basiert, bei denen die Entwickler engagiert bleiben, mit echtem Quellcode lernen und Benchmarks für Best Practices im Bereich Sicherheit erreichen
• Wie dieses Zertifizierungsprogramm die Teilnahme, das Behalten von Informationen und kontinuierliches Lernen fördert
• Wie Anreize den Entwicklern helfen, die Trainingsstufen zu durchlaufen und sich schnell und in Übereinstimmung mit den wichtigsten Sicherheitsrichtlinien weiterzubilden
• Wie Bewertungen dabei helfen, Sicherheits-Champions zu identifizieren und das Schulungsengagement zu fördern.

Schauen Sie sich jetzt unser Webinar(On-Demand)an und entdecken Sie die Vorteile eines Linksrucks und die Befähigung von Entwicklern mit den Werkzeugen und dem Wissen, um von Anfang an sicher zu programmieren, mit dem Fokus auf positive Sicherheitspraktiken.

Erfahren Sie, was Finanzinstitute wie Capital One tun, um ihre Entwicklungsteams für sicheres Coding zu begeistern und weiterzubilden, eine positive Sicherheitskultur effektiv zu fördern und erfolgreich "nach links" zu wechseln

Vielleicht sind wir ein klein wenig voreingenommen, aber hier bei Secure Code Warrior sind wir der Meinung, dass eine Karriere in der Softwareentwicklung und im Ingenieurwesen ein aufregender, lohnender Weg für jeden Einzelnen ist (und er wird jeden Tag größer!).

Am 23. Juni ist der Internationale Tag der Frau im Ingenieurwesen. Zur Feier des Tages haben wir uns mit Lucy T*, einer leitenden Entwicklerin bei einem der größten Telekommunikationsunternehmen im asiatisch-pazifischen Raum, zusammengesetzt, um mehr über ihre Erfahrungen, ihre Karriere und ihre Zukunftspläne zu erfahren. Lucy T* ist eine enthusiastische und kluge Person, deren Fachwissen sich über mehr als ein Jahrzehnt erstreckt - über mehrere Sprachen, Plattformen und Projekte hinweg. Ihr Arbeitsplatz spiegelt ihr technologisches Können wider: Ein selbstgebautes High-End-Gaming-Rig und ein 3D-Drucker sind das Herzstück ihres Maschinenraums.

Auf die Frage nach ihren Anfängen in der Software-Entwicklung antwortet sie mit einem schiefen Lächeln: "Ich bin durch Zufall dazu gekommen. Ich habe an der Uni mit Design angefangen und dann festgestellt, dass es nicht so war, wie ich es mir vorgestellt hatte, also habe ich es abgebrochen. Ich kämpfte damit, etwas zu finden, das mir genug Spaß macht, um es beruflich zu machen, und dachte mir, na ja, Computer haben mir schon immer gefallen, mein Vater arbeitet mit Computern. Ich werde ein Informatik-Studium machen und sehen, wie es läuft. Ich entdeckte, dass mir das tatsächlich sehr viel Spaß macht. Ich dachte, ich würde in einer Art Infrastruktur- oder Service-Support-Karriere enden, und bekam dann eine Entwicklungsmöglichkeit in einem Graduiertenprogramm. Wie sich herausstellte, war das genau das, was ich wollte." In der Regel ist Lucy kein großer Glückspilz. Sie ist sehr logisch und ein akribischer Planer und denkt über diesen glücklichen Zufall nach, wohl wissend um die Ironie.

Nach mehr als zehn Jahren drehen sich ihre täglichen Aufgaben hauptsächlich um spezialisierte Projektarbeit, die Unterstützung großer Systeme bei der Implementierung neuer Funktionen und der Behebung von Fehlern. Bei Tausenden von Anwendern, die sich täglich auf ihren Plattformen bewegen, ist sie oft in Rufbereitschaft, um Patches schnell zu implementieren und die Kollegen bei der Suche nach praktikablen Lösungen zu unterstützen: "Wenn wir ein großes Projekt haben, das die Einführung einer ganz neuen Funktionalität in das System beinhaltet, kann es schwierig werden. Es ist von größter Wichtigkeit, den bestehenden Dienst am Laufen zu halten, aber auch der allgemeine Support, z. B. wenn es darum geht, den Benutzern zu erklären, wie eine neue Funktion auszuführen ist, spielt eine Rolle."

Ihre Tätigkeit und ihre Fähigkeiten erfordern oft, dass sie zwischen Plattformen und Sprachen wechselt, um mehrere Projekte gut zu unterstützen. Ihr Hintergrund umfasst sechs Jahre .NET-Entwicklung in C#, aber seitdem hat sie sich auch mit JavaScript, Java und mehreren plattformspezifischen APIs beschäftigt. Wenn man sie nach ihren Favoriten fragt, seufzt sie tief und stützt ihr Kinn in die Hand. "Was ich am meisten schätze, ist die Flexibilität. Das ist es, was an JavaScript hervorsticht, jetzt, wo ich es von Tag zu Tag benutze. Ich muss allerdings sagen, dass ich Java absolut hasse, was lustig ist, weil die Leute mir sagen, dass C# wie Java ist ... das ist es nicht, überhaupt nicht. Java ist so ziemlich scheiße." Sie bricht in Gelächter aus und verscheucht ihre riesige Plüschkatze von der Couch. Ihre Unverblümtheit ist erfrischend.

Lucys Seniorität im Team kann auch bedeuten, dass sie diejenige ist, die sich für den Sicherheitsaspekt ihres Jobs einsetzt, vor allem gegenüber frischgebackenen Absolventen oder Junior-Entwicklern, die in der Herde willkommen geheißen werden: "In meinem Bereich ist Sicherheit natürlich eine große Priorität. Niemand will eine sehr teure Geldstrafe wegen der Preisgabe von Daten. Die Organisationen sind sich der sensiblen Informationen, der persönlich identifizierbaren Informationen und all dieser Dinge sehr bewusst. In meinem derzeitigen IT-Team ist es wichtig, dass die Dinge, die wir entwickeln, aus der Sicherheitsperspektive richtig abgesichert sind. Nur die richtigen Leute sollten diese Daten sehen, auf diese Daten zugreifen und keine unangemessenen Berechtigungen haben, wie z. B. Bearbeiten statt nur Lesen. Ich mache es zu einer Priorität, dies bei jedem, der neu ins Team kommt, zu betonen."

Wir haben Lucy durch die Secure Code Warrior Plattform-Demo geführt, die sie mit beeindruckender Leichtigkeit meisterte: "Mir gefällt, dass dies sehr spezifisch für die Programmiersprache ist. courses Ich finde, dass die meisten Sicherheitsschulungen, die ich in der Vergangenheit unternommen habe, sehr stark auf die organisatorische Ebene ausgerichtet sind: "Oh, sei vorsichtig, welche Art von Daten du preisgibst", im Gegensatz zu der Frage: "Nun, was mache ich in meinem täglichen Leben, und was kann ich aus dieser Perspektive tatsächlich tun?" Das sieht nach einer großartigen Möglichkeit aus, von einem Anfänger bis hin zu erfahreneren Programmierern zu erfahren, was sie in ihrem täglichen Arbeitsleben tun können, um die Dinge sicherer zu machen."

Unser Gespräch dreht sich um den Internationalen Tag der Frau im Ingenieurwesen, und wir bitten sie, über die Herausforderungen nachzudenken, denen sie als Frau in einem so männerdominierten Bereich begegnet ist, wenn überhaupt. Sie ist eindeutig in ihrem Element, wenn es um Software-Entwicklung geht - und auch hochqualifiziert - aber sie findet, dass bestimmte Aufgaben immer noch an ihr vorbeigehen: "Ich denke, die größte Herausforderung ist nicht so sehr, dass die Männer annehmen, man sei nicht technikaffin - das war für mich nie ein Problem. Das war für mich nie ein Problem. Es ist eher die Annahme, dass man als Frau auch gut in der Kommunikation ist oder dass man zu diesen kommunikationsbasierten Fähigkeiten neigt. Soft Skills, Dokumentation, all diese Dinge. Ich habe definitiv manchmal festgestellt, dass ich mit Dokumentationsarbeit oder mit dem Management einer Kundenbeziehung feststeckte, obwohl das nicht Teil meiner Jobbeschreibung war, nur weil mein Manager annahm, dass ich als Frau besser darin wäre." Ihr ansteckendes Lachen kocht wieder über. "Der Umgang mit Menschen macht mir nicht so viel Spaß, wie alle annehmen!"

In unserer Forschung haben wir herausgefunden, dass vielen Entwicklerinnen ein Unterstützungsnetzwerk in ihrer Karriere fehlt, insbesondere durch weibliche Mentoren. Lucy hat - zumindest derzeit - das Gefühl, dass sie von Managern und Kollegen unterstützt wird, um sich zu entfalten: "Ich denke, ich bin im Moment in einem unterstützenden Team. Ich habe unterstützende Manager, ich habe Mentoren. Wenn ich bei etwas nicht weiterkomme, habe ich Leute, mit denen ich reden kann, um entweder sofortige Hilfe für ein Projekt zu bekommen oder sogar Hilfe für die Karriere, z. B. wo ich in Zukunft hingehen kann. Wohin jemand in meiner Position in ein paar Jahren streben könnte, Karriereziele, solche Dinge."

Hätte sie die gleiche Antwort auch schon früher in ihrer Karriere gegeben? "Ich würde auf jeden Fall nicht sagen, dass dies ein Indikator für meine Erfahrung vor, sagen wir, sieben Jahren war. Wenn ich darüber nachdenke, war es manchmal ziemlich einsam."

Frauen, die eine Karriere in der Softwareentwicklung anstreben, möchte Lucy mit Leidenschaft ermutigen. Auf die Frage, ob sie einen besonderen Rat habe, setzte sie sich in ihrem Stuhl nach vorne, ein Bild der Ernsthaftigkeit: "Einfach ausgedrückt: Unterschätzen Sie sich nicht. Suchen Sie nach anderen Menschen in Ihrer Position und nach anderen Frauen in der gleichen Karriere, wenn Sie können. Nur um andere Menschen in einem ähnlichen Umfeld kennenzulernen, um zu wissen, dass Sie nicht allein sind und dass die Dinge, die Sie erleben, ganz normal sind. Auf diese Weise lernen Sie vielleicht eher, Ihre eigenen Fähigkeiten zu schätzen, und erkennen, dass die Leute, die sagen: "Ja, ich kann das hervorragend", in Wirklichkeit auf dem gleichen Niveau sind wie Sie. Sie sind nur besser darin, zu sagen, dass sie es können, oder sie sind bereit zu sagen: "Ja, du solltest mir eine Chance geben. "Wenn du hart arbeitest, dich auf dem Laufenden hältst, garantiere ich dir, dass du genauso gut bist wie sie. Nehmen Sie es und laufen Sie damit."

Initiativen wie Code First: Girls, die sich zum Ziel gesetzt haben, bis 2020 20.000 Frauen das Programmieren beizubringen, tragen dazu bei, das Profil der Softwareentwicklung als mögliche Karriere für Frauen zu schärfen und eröffnen Möglichkeiten, die sonst vielleicht nicht in Betracht gezogen worden wären.

Matias Madou, Mitbegründer und CTO vonSecure Code Warrior , setzt sich ebenfalls leidenschaftlich für das Wachstum von Frauen in der Branche ein: "Als Tech-Startup ist es nicht einfach, einen vielfältigen Pool an Talenten anzuziehen, die bereit sind, harte Arbeit und viele Stunden zu investieren, um unserer Mission zu folgen, Entwickler zu stärken. In den letzten sechs Monaten haben wir acht unglaubliche Frauen sowohl in Management- als auch in Geschäftspositionen eingestellt. Unser Ingenieurteam besteht aus etwa neun verschiedenen Nationalitäten und ich glaube fest daran, dass Vielfalt zu Kreativität und mehr Einfühlungsvermögen führt. Wir setzen uns dafür ein, dass unser Team ein Ort ist, an dem sich Frauen entfalten können."

(Und wenn Sie schon dabei sind: Wenn Sie ein Entwickler sind, der nach einer neuen Gelegenheit sucht, sind wir immer auf der Suche nach talentierten Programmierern, die sich dem Team Awesome anschließen möchten! Schauen Sie sich unsere Karriereseite an.)

* Lucy T. ist ein Pseudonym, um ihre Identität als sichere Entwicklungsfachkraft in einem großen Unternehmen zu schützen. Sie stimmte diesem Interview unter der Bedingung der Anonymität zu.

Ich dachte, ich würde in einer Art Infrastruktur- oder Service-Support-Karriere landen, und bekam dann eine Entwicklungsmöglichkeit in einem Graduiertenprogramm. Wie sich herausstellte, war das genau das, was ich brauchte.

Je nach Anwendung kann der Prozess der Serialisierung ständig stattfinden. Der Begriff wird immer dann verwendet, wenn Datenstrukturen oder Objektzustände in ein Format übersetzt werden, das gespeichert oder eventuell als Kommunikation versendet werden kann. Die Deserialisierung ist das Gegenteil dieses Prozesses, wobei die nun strukturierten Daten wieder in das Objekt oder den Datenstring zurückverwandelt werden, der sie vor der Speicherung waren.

Eine unsichere Deserialisierung kann immer dann auftreten, wenn eine Anwendung die zu deserialisierenden Daten als vertrauenswürdig behandelt. Wenn ein Benutzer in der Lage ist, die neu rekonstruierten Daten zu ändern, kann er alle Arten von böswilligen Aktivitäten durchführen, z. B. Code-Injektionen, Denial-of-Service-Angriffe oder einfach die Daten ändern, um sich selbst einen Vorteil innerhalb der Anwendung zu verschaffen, z. B. den Preis eines Objekts zu senken oder seine Privilegien zu erhöhen.

In dieser Folge lernen wir:

• Wie Angreifer eine unsichere Deserialisierung ausnutzen können
• Warum unsichere Deserialisierung gefährlich ist
• Techniken, die diese Sicherheitslücke beheben können.

Wie nutzen Angreifer eine unsichere Deserialisierung aus?

Heutzutage ist das beliebteste Datenformat für die Serialisierung von Daten JSON, obwohl XML an zweiter Stelle steht. Etliche Programmiersprachen bieten auch ihre eigenen Methoden zur Serialisierung von Daten an, die oft mehr Funktionen als JSON oder XML enthalten. In jedem Fall kann es zu Problemen kommen, wenn Entwickler Anwendungen so programmieren, dass sie deserialisierte Daten als vertrauenswürdige Eingaben behandeln, anstatt dem alten Mantra aus anderen Blogs in dieser Reihe zu folgen, nämlich: "Traue niemals Benutzereingaben!"

Benutzereingaben sind niemals vertrauenswürdig, da der Benutzer Code in diese Zeichenfolgen einfügen kann, der versehentlich vom empfangenden Server ausgeführt werden könnte. Und da auch auf deserialisierte Rohdaten manchmal zugegriffen werden kann und diese ausgenutzt werden können, müssen sie in die gleiche nicht vertrauenswürdige Kategorie fallen.

Wenn z. B. eine Forenanwendung die PHP-Objektserialisierung verwendet, um ein Cookie zu speichern, das die Identifikation und die Rolle eines Benutzers enthält, dann kann dieses manipuliert werden. Ein böswilliger Benutzer könnte stattdessen seine "Benutzer"-Rolle in "Admin" ändern. Oder er kann die vom Datenstring bereitgestellte Öffnung nutzen, um Code einzuschleusen, der vom Server bei der Verarbeitung der "vertrauenswürdigen" Daten fehlinterpretiert und ausgeführt werden könnte.

Warum ist unsichere Deserialisierung gefährlich?

Es stimmt, dass diese Art des Angriffs ein gewisses Maß an Geschicklichkeit seitens des Hackers erfordert, und manchmal auch Versuch und Irrtum, während der Angreifer lernt, welche Arten von Code oder Exploits der Server aus seinen manipulierten, deserialisierten Daten akzeptiert. Nichtsdestotrotz ist dies eine häufig ausgenutzte Schwachstelle, weil sie Hackern, die geschickt genug sind, sie zu nutzen, potenzielle Macht verleiht.

Je nachdem, wie die deserialisierten Daten verwendet werden sollen, kann eine beliebige Anzahl von Angriffen, darunter viele, die wir in früheren Blogs behandelt haben, eingesetzt werden. Eine unsichere Deserialisierung kann ein Einfallstor für entfernte Cross-Code-Injection, Cross-Site-Scripting, Denial-of-Service, Hijacking der Zugriffssteuerung und natürlich SQL- und XML-Injection-Angriffe sein. Im Grunde genommen wird ein Startpunkt eröffnet, alle zu deserialisierenden Daten werden als vertrauenswürdig deklariert und die Angreifer können versuchen, sie auszunutzen.

Beseitigung der unsicheren Deserialisierung

Das Sicherste, was Unternehmen tun können, um unsichere Deserialisierung zu verhindern, ist, Anwendungen davon abzuhalten, deserialisierte Daten zu akzeptieren. Das mag jedoch nicht möglich oder realistisch sein, aber keine Sorge, denn es gibt andere Techniken, die zur Verteidigung gegen diese Art von Angriff eingesetzt werden können.

Wenn möglich, können die Daten z. B. auf numerische Werte bereinigt werden. Dies könnte einen Exploit zwar nicht vollständig verhindern, würde aber das Auftreten von Code-Injektionen verhindern. Noch besser wäre es, einfach eine Form der Integritätsprüfung für deserialisierte Daten zu verlangen, z. B. eine digitale Signatur, die sicherstellen könnte, dass die Datenstrings nicht manipuliert wurden. Und alle Deserialisierungsprozesse sollten isoliert und in einer Umgebung mit niedrigen Privilegien ausgeführt werden.

Sobald Sie diese Schutzvorkehrungen getroffen haben, sollten Sie alle fehlgeschlagenen Deserialisierungsversuche sowie die Netzwerkaktivitäten von Containern oder Servern, die Daten deserialisieren, protokollieren. Wenn ein Benutzer mehr als ein paar Deserialisierungsfehler in den Protokollen auslöst, ist das ein guter Hinweis darauf, dass es sich entweder um einen böswilligen Insider handelt oder dass seine Anmeldedaten gehackt oder gestohlen wurden. Sie könnten sogar Dinge wie automatische Sperrungen für Benutzer in Betracht ziehen, die ständig Deserialisierungsfehler auslösen.

Welches dieser Tools Sie auch immer zur Bekämpfung unsicherer Deserialisierung einsetzen, denken Sie daran, dass es sich im Kern um Daten handelt, die von einem Benutzer berührt oder manipuliert worden sein könnten. Vertrauen Sie niemals darauf.

Weitere Informationen zur Verwendung von Komponenten mit bekannten Sicherheitslücken

Als weitere Lektüre können Sie einen Blick darauf werfen, was OWASP über unsichere Deserialisierung sagt. Sie können Ihr neu erworbenes Verteidigungswissen auch mit dem kostenlosen Showcase der Plattform Secure Code Warrior testen, die Cybersecurity-Teams zu den ultimativen Cyber-Kriegern ausbildet. Um mehr über die Beseitigung dieser Schwachstelle und eine Schurkengalerie anderer Bedrohungen zu erfahren, besuchen Sie den BlogSecure Code Warrior .

Es tut mir leid, ich muss eine schlechte Nachricht überbringen.

Die traditionelle Ausbildung ist tot.

Nun, okay, das ist es nicht... aber es sollte es wahrscheinlich sein. Immer wieder haben Studien gezeigt, dass es eine der ineffektivsten Arten ist, Menschen in ein Klassenzimmer zu stecken, um etwas Neues zu lernen, eine Compliance-Aufgabe abzuhaken oder sich umschulen zu lassen. Und wenn es um Unternehmensschulungen geht, werden diese Statistiken nicht besser. Die Harvard Business Review veröffentlichte eine Studie über die Effektivität von Präsenztrainings für Neueinstellungen in großen Unternehmen und stellte fest, dass diese Lernmethode im Durchschnitt acht bis zwölf Monate benötigt, um neue Mitarbeiter auf den neuesten Stand zu bringen und produktiv zu machen. Das ist eine sehr lange Zeit, um die Fähigkeiten einer Person voll auszuschöpfen (und eine lange Zeit, um sich einzugewöhnen, wenn man der neue Mitarbeiter ist). Heutzutage haben die meisten Unternehmen nicht so viel Zeit; zwangsläufig wird an allen Ecken und Enden gespart, die Mitarbeiter erhalten nicht das Training, das sie brauchen, und dem Unternehmen entgeht eine Menge Wert, der viel früher erreicht werden könnte.

Es ist wirklich erstaunlich, dass viele Unternehmen immer noch auf Klassenzimmer, trockene Lehrbücher und langweilige Videotrainings setzen, um ihre besten und klügsten Köpfe mit den besten Praktiken oder neuen Initiativen des Unternehmens vertraut zu machen, vor allem, wenn es eine viel bessere, ansprechendere und wertvollere Art zu lernen gibt: kontextbezogenes Training. Es hat sich herausgestellt, dass wir Menschen Informationen viel besser behalten, wenn wir neue Ideen und Prozesse in die Hand nehmen.

Nun, wenn es um Entwickler geht, sind wir ein besonderer Haufen. Aus meiner eigenen Erfahrung als Entwickler kann ich sagen, dass traditionelle Schulungen nicht gerade meine Welt in Brand setzen. Entwickler neigen dazu, kreative, einfallsreiche Problemlöser zu sein, die viel lieber die Tools benutzen, als in einem Klassenzimmer belehrt zu werden, oder vor endlosen Videos eines sprechenden Kopfes zu sitzen, wenn sie versuchen, neue Informationen zu lernen. Wenn man sich die Sicherheitsschulung im Speziellen ansieht, scheint es in der aktuellen Landschaft eine klare Diskrepanz zu geben: Entwickler versäumen es, häufige Schwachstellen in ihrem Code zu beheben, was dazu führt, dass sich AppSec-Profis die Haare raufen, wenn sie immer wieder mit denselben, leicht zu behebenden Problemen konfrontiert werden. Die Beziehung zwischen diesen Teams ist angespannt, und die Entwickler erhalten nicht die richtigen Tools und Schulungen, um sich mit den Best Practices für sichere Entwicklung zu beschäftigen. Ihr Hauptziel ist die Funktionserstellung, aber angesichts der rapide steigenden Cyberrisiken für jedes Unternehmen können wir es uns einfach nicht mehr leisten, Sicherheitswissen zu ignorieren und zu vernachlässigen.

Und das Beste daran? Wenn Entwickler sicherheitsbewusst sind, verschwinden diese häufigen Schwachstellen allmählich. Das Risiko wird reduziert, ebenso wie die Kosten für die Behebung von Fehlern im Spätstadium (und AppSec verliert nicht mehr reihenweise die Haare).

Wie sieht also die Einbindung von Entwicklern mit kontextbezogenem Training genau aus?

Beispiele aus der realen Welt sind lächerlich mächtig.

Stellen Sie sich vor, wir müssten alle das Autofahren lernen, indem wir uns Videos auf YouTube ansehen. Während Sie die allgemeine Idee bekommen können, wie ein Auto funktioniert, sowie die Abfolge von Ereignissen, die eingeleitet wird, um Sie entlang der Straße zu bewegen, wäre es praktisch unmöglich, das Fahren gut zu lernen, bis Sie in ein Auto springen und es persönlich ausprobieren.

Ein kontextbezogenes Training ist deshalb so wertvoll, weil es den Kursteilnehmer auf den Fahrersitz des zu vermittelnden Stoffes setzt. Wenn man einen realen Kontext für etwas hat, macht es das Lernen viel ansprechender und sinnvoller.

Wenn es um sichere Codierung geht, kann sich jeder ein Video ansehen und die Grundlagen der SQL-Injektion verstehen, aber die Feinheiten der tatsächlichen Problemlösung werden leicht vergessen, wenn Fristen drohen und die Lieferung von Funktionen Priorität hat. Wenn es jedoch möglich wäre, reale Code-Beispiele zu überprüfen, die Injektion zu identifizieren und sie als Teil einer Trainingsübung zu beheben, ist das für den Arbeitsalltag eines Entwicklers viel besser anwendbar als der Versuch, einseitige Informationen zu behalten. Es ist auch für einen Entwickler besser nachvollziehbar, wenn er Code sieht, der dem ähnelt, was er normalerweise schreibt, wird er aufstehen und aufpassen.

Auf der Secure Code Warrior Plattform haben wir das sichere Codetraining gamifiziert und bieten eine Vielzahl von Herausforderungen in mehreren Sprachen und Frameworks. Das System regt zum wiederholten Spielen an und ist vor allem sofort anpassbar, um die richtige Umgebung für echtes kontextbezogenes Lernen zu bieten.

Wissen bereitstellen, wenn es am nützlichsten ist

Nach der kontextuellen Lerntheorie findet effektives Lernen nur dann statt, wenn die Schüler neue Informationen oder neues Wissen so verarbeiten, dass es für sie innerhalb ihres eigenen individuellen Bezugsrahmens Sinn macht.

Stellen Sie sich vor, ein Entwickler erhält eine Liste von Sicherheitslücken aus Bug Bounty-Programmen, SAST-Tools oder Bug-Tracking-Software. Sie sind vielleicht perplex - sogar überwältigt - wenn sie noch nie auf diese Schwachstellen gestoßen sind. Was noch schlimmer ist: Die meisten Berichte sind für Anwendungssicherheitsexperten und nicht für Entwickler gedacht. Die Informationen in den Berichten sind schwer zu analysieren und enthalten oft allgemeine Ratschläge, die für einen Entwickler nicht direkt anwendbar sind.

Vor kurzem haben wir die Möglichkeit hinzugefügt, direkt auf praktische Schulungen zu Schwachstellen aus Bug-Bounty-Programmen, SAST-Tools, Bug-Tracking-Software und Penetrationstest-Berichten zu verlinken. Entwickler können sofort die Grundlagen verstehen und gute Coding-Rezepte für ihr jeweiliges Framework lernen.

Diese Art des Lernens stellt sicher, dass Entwickler Wissen und Training zu Konzepten erhalten, wenn sie am relevantesten sind, und es ist viel wahrscheinlicher, dass sie diese Informationen auf lange Sicht behalten.

Schnellere Ergebnisse, weniger Störung, glücklichere Camper.

Bei jedem Training ist ein unmittelbarer Zusammenhang mit Ihren täglichen Aktivitäten viel wirkungsvoller, als wenn Sie versuchen, etwas Allgemeines auf Ihre Arbeit anzuwenden. Sie verbringen weniger Zeit im "Lernmodus" oder - noch schlimmer - Sie müssen weniger Dinge durchgehen, die Sie bereits "gelernt" haben, wenn Sie eine Antwort auf etwas brauchen.

Eines der Prinzipien des kontextuellen Trainings ist die Fähigkeit, auf Wissen aufzubauen, so dass jede Komponente des Trainings die vorherige ergänzt, was einen schrittweisen Prozess ermöglicht, der den Teilnehmern einen Weg zur Beherrschung bietet. Auch dies ist etwas, das wir auf unserer Plattform unterstützen, mit einem Gurtsystem, das dem in einem Karate-Dojo ähnelt. Jeder fängt mit dem weißen Gürtel an, bevor er nach den notwendigen Trainingsstunden und der Teilnahme an tournament den begehrten schwarzen Gürtel oder die Stufe "Sicherheitschampion" erreicht. Es ist ein unterhaltsamer Ansatz mit realem Wert und praktischer Anwendung.

Möchten Sie die besten Talente an sich binden und sie sicherheitsbewusst halten? Geben Sie ihnen die Werkzeuge für den Erfolg.

Es ist eine bedauerliche Tatsache, dass sicherheitsbewusste Entwickler und AppSec-Spezialisten im Moment eine knappe (aber wichtige) Ressource sind. Sie sind auch notorisch schwer zu halten.

Cybrary führte 2018 eine Umfrage unter 3100 IT- und Sicherheitsexperten durch und stellte fest, dass ein Schlüsselelement für die Bindung wertvoller Mitarbeiter die Investition in ihre Ausbildung ist. Die Ergebnisse zeigen, dass Unternehmen, die Tools und Schulungen zur Förderung der internen Sicherheitskompetenzen anbieten, 60 % mehr Sicherheitsexperten an sich binden konnten als Unternehmen, die dies nicht taten, und satte 65 % der Befragten bevorzugten praktische Schulungen. Ziemlich klasse, oder?

Die Umfrageergebnisse lieferten jedoch auch eine ziemlich alarmierende Enthüllung: 80 % der Befragten fühlen sich nicht ausreichend vorbereitet, um ihre Organisation gegen Cyber-Bedrohungen zu verteidigen. Diese Bedrohungen werden nicht verschwinden, und das richtige Training zur Bekämpfung des wachsenden Risikos von kostspieligen Datenverletzungen und Angriffen ist jetzt mehr denn je erforderlich. Und, na ja, ich bin vielleicht voreingenommen, aber die Plattform von Secure Code Warrior könnte das Werkzeug sein, das Sie brauchen, um eine positive Sicherheitskultur zu entfachen, Entwickler mit dem kontextbezogenen Training, das sie lieben, weiterzubilden und zu unterstützen und Ihr Unternehmen vor den bösen Jungs zu schützen. Fordern Sie eine Demo an und wir zeigen Ihnen mehr.

Die Offenlegung sensibler Daten war in den letzten Jahren für einige der bekanntesten und folgenreichsten Datenschutzverletzungen verantwortlich, wie z. B. die katastrophale Verletzung bei Marriott, bei der über 300 Millionen Kundendaten gestohlen wurden, und weitere 150 Millionen, als Equifax angegriffen wurde. Es ist ein mittleres Maß an Raffinesse erforderlich und manchmal auch eine spezielle Ausrüstung auf Seiten des Angreifers, aber in vielen Fällen ist es für einen Hacker nicht übermäßig schwer, es durchzuziehen, und es gibt Tools, um einige der Angriffsfunktionen zu automatisieren.

Die Offenlegung sensibler Daten tritt immer dann auf, wenn Informationen, die nur für eine autorisierte Ansicht bestimmt sind, in einem unverschlüsselten, ungeschützten oder schwach geschützten Zustand einer unbefugten Person zugänglich gemacht werden. Meistens handelt es sich dabei um Daten, die Hacker stehlen wollen, wie z. B. Kreditkartennummern, Benutzeridentifikationen, Geschäftsgeheimnisse und persönliche Informationen, die durch Gesetze und Branchenvorschriften geschützt sein könnten.

Hacker können sensible Informationen stehlen, wenn sie unverschlüsselt gespeichert sind oder indem sie indirekt das Verschlüsselungsschema angreifen. Anstatt zu versuchen, starke Verschlüsselung direkt zu entschlüsseln, stehlen sie stattdessen Kryptoschlüssel oder greifen Daten an, wenn sie in einen unverschlüsselten Zustand versetzt werden, z. B. wenn sie für den Transport vorbereitet werden.

In dieser Folge lernen wir:

• Wie Angreifer die Offenlegung sensibler Daten auslösen können
• Warum die Offenlegung sensibler Daten so gefährlich ist
• Techniken, die diese Sicherheitslücke beheben können.

Wie nutzen Angreifer die Offenlegung sensibler Daten aus?

Die Offenlegung sensibler Daten geschieht normalerweise, wenn Websites keine starke Ende-zu-Ende-Verschlüsselung zum Schutz der Daten verwenden oder wenn es ausnutzbare Schwachstellen im Schutzschema gibt. Es kann auch passieren, wenn die verwendete Verschlüsselung besonders schwach oder veraltet ist.

Hacker werden oft versuchen, Wege zu finden, um die Verschlüsselung zu umgehen, wenn sie nicht überall eingesetzt wird. Wenn beispielsweise eine Benutzeridentitätsdatenbank Informationen in einem verschlüsselten Zustand speichert, diese aber automatisch entschlüsselt, wenn sie abgerufen werden, könnte ein Hacker einen der bereits in diesen Blogs behandelten Angriffe wie SQL- oder XML-Injection nutzen, um die Datenbank anzuweisen, den Entschlüsselungsprozess durchzuführen. Dann wären die Daten für den Hacker entschlüsselt, ohne dass er zusätzlichen Aufwand betreiben müsste. Warum sollte man versuchen, eine Stahltür aufzubrechen, wenn man einfach den Schlüssel stehlen kann?

Schwache Verschlüsselung ist ebenfalls ein Problem. Wenn zum Beispiel Kreditkarten mit einem veralteten Verschlüsselungsschema gespeichert werden, könnte es ein Problem sein, wenn ein Hacker in der Lage ist, etwas wie eine lokale Dateieinschlussschwachstelle zu nutzen, um die gesamte Datenbank auf seinen Computer zu ziehen. Wenn die erfassten Daten mit einer starken Verschlüsselung wie AES-256 Bit geschützt wurden, wäre es viel schwieriger, sie zu knacken, wenn sie in den Besitz eines Hackers gelangen. Wenn jedoch eine schwächere oder veraltete Verschlüsselung verwendet wird, wie z. B. der ältere DES-Standard, dann kann ein Hacker mit spezieller Ausrüstung, wie z. B. einem Rack mit Grafikverarbeitungseinheiten (GPUs), diese einsetzen, um die Verschlüsselung in relativ kurzer Zeit zu knacken.

Warum ist die Offenlegung sensibler Daten gefährlich?

Die Offenlegung sensibler Daten ist gefährlich, weil dadurch unbefugte Benutzer geschützte Informationen sehen können. Wenn die Daten nicht wichtig wären, würden sie nicht geschützt werden, so dass jede Verletzung dieses Schutzes zu Problemen führen wird. Das ist keine Situation, mit der sich ein Unternehmen konfrontiert sehen möchte.

Wie viel Ärger eine Enthüllung sensibler Daten verursachen kann, hängt von der Art der Daten ab, die enthüllt werden. Wenn Benutzer- oder Kennwortdaten gestohlen werden, könnten diese für weitere Angriffe auf das System verwendet werden. Die Offenlegung persönlicher Daten könnte Benutzer sekundären Angriffen wie Identitätsdiebstahl oder Phishing aussetzen. Unternehmen könnten sich sogar durch hohe Geldstrafen und behördliche Maßnahmen gefährdet sehen, wenn die offengelegten Daten durch Gesetze wie den Health Insurance Portability and Accountability Act (HIPAA) in den USA oder die General Data Protection Regulation (GDPR) in Europa gesetzlich geschützt sind.

Eliminierung der Gefährdung sensibler Daten

Die Verhinderung der Offenlegung sensibler Daten beginnt mit der Sicherstellung einer starken, aktuellen und durchgängigen Verschlüsselung sensibler Daten in einem Unternehmen. Dies umfasst sowohl Daten im Ruhezustand als auch während der Übertragung. Es reicht nicht aus, sensible Daten zu verschlüsseln, während sie im Speicher liegen. Wenn sie vor der Verwendung oder vor dem Transport unverschlüsselt sind, können sie durch einen sekundären Angriff, der einen Server dazu bringt, sie zu entschlüsseln, offengelegt werden.

Daten im Transit sollten immer mit Transport Layer Security (TLS) geschützt werden, um eine Aufdeckung durch Man-in-the-Middle- oder andere Angriffe auf bewegte Daten zu verhindern. Und sensible Daten sollten niemals irgendwo im Netzwerk zwischengespeichert werden. Sensible Daten sollten entweder mit starker Verschlüsselung im Speicher liegen oder mit TLS-Schutz gesendet werden, damit Angreifer keine Schwachstellen ausnutzen können.

Machen Sie schließlich eine Bestandsaufnahme der Arten von sensiblen Daten, die von Ihrer Organisation geschützt werden. Wenn es für Ihre Organisation keinen Grund gibt, solche Daten zu speichern, dann entsorgen Sie sie. Warum sollten Sie sich potentiellem Ärger aussetzen, ohne einen möglichen Nutzen zu haben? Daten, die nicht von einer Organisation verwaltet werden, können auch nicht von ihr gestohlen werden.

Weitere Informationen zum Umgang mit sensiblen Daten

Als weitere Lektüre können Sie einen Blick darauf werfen, was OWASP über die Exposition sensibler Daten sagt. Sie können Ihr neu erworbenes Verteidigungswissen auch mit der kostenlosen Demo der Secure Code Warrior Plattform testen, die Cybersecurity-Teams zu den ultimativen Cyber-Kriegern ausbildet. Um mehr über die Beseitigung dieser Schwachstelle und eine Schurkengalerie anderer Bedrohungen zu erfahren, besuchen Sie den BlogSecure Code Warrior .