Seit wir 2015 mit unserer Mission begannen, lag unser Fokus immer darauf, Entwicklern unterhaltsame, relevante und ansprechende Schulungen zu sicherem Coding zu ermöglichen. Wir haben schon lange erkannt, wie wichtig es ist, Entwicklern das Wissen und die Werkzeuge an die Hand zu geben, um Best Practices für die Sicherheit zu verstehen, warum sie wichtig sind und wie sie helfen können, Software vor bösartigen Angriffen zu schützen, während der Code geschrieben wird.

Sicherheitsschulungen sind jedoch kein neues Konzept. Wir waren sicher nicht die Ersten, die diese Initiative ergriffen haben, und angemessene Sicherheitsmaßnahmen sind in der Software-Entwicklung schon seit langem ein Thema. Sicherlich sind einige Arten von Schulungen effektiver als andere, aber der Zugang zu einer gewissen Sicherheitsausbildung ist relativ leicht zu finden, vor allem heutzutage.

... also warum zum Teufel haben wir so viele Datenverletzungen? Im September wurden allein im Jahr 2019 über vier Milliarden Datensätze durch mehrere Cyberangriffe offengelegt.

Viele Unternehmen kämpfen derzeit einen aussichtslosen Kampf, um unsere zunehmend wertvollen Daten sicher zu halten. Es ist CISOs und CIOs auf der ganzen Welt überdeutlich geworden, dass "nach links verschieben" immer noch zu spät ist. Wir müssen links mit der Sicherheit im SDLC beginnen, und das bedeutet, dass Entwickler über ausreichendes Sicherheitswissen verfügen müssen, um Fehler zu beheben, lange bevor der Code committed wird, geschweige denn an die Öffentlichkeit gelangt.

AppSec-Spezialisten können nicht die einzigen Torwächter für Sicherheitswissen sein.

In der Vergangenheit war Softwaresicherheit die Domäne einer ganz bestimmten Gruppe von cleveren Geeks, die so gut wie keinen Kontakt zu den Ingenieuren hatten, die den Code schrieben. Es war ihre Aufgabe, unsicheren Code zu testen, zu brechen und zu verhindern, dass er das Licht der Welt erblickt. Wenn sich ihre Wege doch einmal kreuzten, war es wahrscheinlich, dass der Sicherheitsspezialist auf Fehler im Code hinwies... etwas, das garantiert einen frostigen Empfang von dem Entwickler bekam, der an der Erstellung des Codes gearbeitet hatte.

Spulen Sie in die heutige Zeit vor, und die Situation ist so ziemlich die gleiche, nur dass jetzt viel mehr auf dem Spiel steht. Nahezu jeder Aspekt unseres Lebens ist digitalisiert... alles von Fotoalben in sozialen Medien, medizinischen Daten, Bankgeschäften und unseren wertvollsten Ausweisdokumenten. Es war eine Sache, meist offline, eigenständige Software und Betriebssysteme zu schützen. Es ist eine ganz andere Sache, sich gegen Bedrohungen von Milliarden von Codezeilen verteidigen zu müssen, bei denen Hunderte von Millionen von Benutzern potenziell gefährdet sind. Es steht einfach zu viel auf dem Spiel, als dass eine Gruppe von Spezialisten die volle Verantwortung übernehmen könnte, und deshalb müssen wir die Kluft zwischen AppSec und dem Entwicklungsteam überbrücken. Sie müssen zusammenarbeiten, ihr Wissen teilen und als eine geschlossene, sicherheitsbewusste Einheit agieren.

Es gibt nur ein Problem dabei: Entwickler haben selten die Möglichkeit, sichere Programmierkenntnisse auf sinnvolle Weise zu erlernen. Die meisten Hochschulausbildungen gehen kaum auf Best Practices im Bereich Sicherheit ein, und die Qualität der Ausbildung am Arbeitsplatz variiert stark.

Ist es da ein Wunder, dass wir jeden zweiten Tag riesige Sicherheitsverletzungen erleben? Laden Sie unsere AppSec-Checkliste herunter.

‍

Eine "Lizenz zum Coden".

Trotz der düsteren aktuellen Lage bin ich optimistisch, was die Zukunft der Sicherheit angeht. Es liegt eine Veränderung in der Luft, und ich bin so ermutigt durch die immense Anzahl von Organisationen, die sichere Kodierung gerade jetzt ernst nehmen.

Es wird immer deutlicher, dass Entwickler Zugang zu den richtigen Tools und Kenntnissen benötigen, um Sicherheitsrisiken zu minimieren, und dass eine gedeihliche Kultur des Sicherheitsbewusstseins im Kampf gegen Datenschutzverletzungen entscheidend ist. Wenn Entwickler bereits beim Schreiben des Codes die Verantwortung für die Sicherheit übernehmen, wird es für Angreifer weitaus weniger ein Kinderspiel, einfache Fehler auszunutzen und sich die Schlüssel zum Schloss zu verschaffen.

Es war schon immer so, dass einige Entwickler sicherheitsbewusster sind als andere, und das stellt eine echte Herausforderung für Unternehmen dar. Während interne Entwicklungsteams oft über ein gewisses Maß an Schulung und Kompetenzüberwachung verfügen, wird das Wasser sehr trübe, wenn Sie Auftragnehmer, Freiberufler und Hochschulabsolventen in den Mix einbeziehen. Handeln sie mit einem Sicherheitsdenken? Können sie uralte Schwachstellen wie Cross-Site-Scripting, die es schon seit Jahrzehnten gibt, erfolgreich vermeiden? Es ist schwer zu sagen, und doch werden sie oft auf wichtige Teile einer Softwareentwicklung losgelassen. Igitt.

Glücklicherweise sehen wir eine Zunahme von nicht verhandelbaren Standards für Entwickler. Zum Beispiel verwenden einige Organisationen Secure Code Warrior als Werkzeug, um Entwicklungsfähigkeiten zu bewerten und eine "Lizenz zum Coden" auszustellen. Ohne das Bestehen grundlegender sicherer Kodierungsprüfungen können sie nicht an Projekten arbeiten. Dies ist von unschätzbarem Wert, wenn es darum geht, Absolventen und Praktikanten zu helfen, ihre Sicherheitskenntnisse auf den neuesten Stand zu bringen und gleichzeitig ein Gefühl dafür zu vermitteln, wie wichtig es ist, sicher zu programmieren. Schließlich muss Sicherheit ein Synonym für Qualität sein, wenn es um Software geht.

Die außerschulische Ausbildung rückt die Hochschulen ins Rampenlicht.

Um die Diskussion über sicheres Coding zu verändern, braucht es mehr als einen Artikel hier, eine Grundsatzrede dort. Es muss eine gemeinschaftsweite Bewegung sein, und es ist großartig zu sehen, dass so viele hochrangige Unternehmen Notiz davon nehmen und Sicherheitsprogramme auf hohem Niveau nach einem beneidenswerten Standard aufbauen. Ein solches Unternehmen ist HSBC, dessen formidables Programm sicherstellt, dass junge Absolventen und neue Mitarbeiter so schnell wie möglich den "Start links" machen. Als Leiter der Technologie-Akademie von HSBC Indien hat Sekhar Babu Tatavarti eine gründliche Sicherheitsschulung für unabdingbar gehalten:

"Bei HSBC Technology wollten wir sicherstellen, dass unsere Entwickler-Community die Bedeutung von sicherem Coding versteht, um die Bank vor Sicherheitslücken zu schützen. In unserem diesjährigen Trainingsprogramm für Hochschulabsolventen sahen wir eine große Chance, die jungen Leute aufzufangen und sie in die Lage zu versetzen, die besten Praktiken für sicheres Coding selbst zu erlernen und zu verinnerlichen, bevor sie in ihren jeweiligen Projekten mit dem Coding beginnen.  

Wir haben die Plattform Secure Code Warrior wegen ihrer wunderbaren Gamification-Methode zum Lernen für die Grads gewählt, und sie haben unsere Erwartungen nicht enttäuscht. Wir freuen uns, dass jeder von ihnen mit Begeisterung an der tournament teilgenommen und zusätzlich die White Belt-Zertifizierung in verschiedenen Technologien absolviert hat", sagte er.

Immer mehr Unternehmen, wie z. B. HSBC, erkennen, dass sichere Programmierfähigkeiten auf Entwicklerebene unerlässlich sind. Dies hat dazu geführt, dass die Hochschulausbildung als Ganzes in Frage gestellt wird. CISOs und CIOs beginnen sich zu fragen, warum frischgebackene Ingenieure ihre Ausbildung ohne solides Sicherheitstraining abschließen.

Innovation im tertiären Bildungsbereich.

Während sichere Kodierung ein obligatorischer Bestandteil des Software-Engineerings auf tertiärer Ebene werden muss, sind einige Universitäten führend bei der Bereitstellung von erstklassigem Training und der Priorisierung von Sicherheit als Teil des Entwicklungsprozesses von Anfang an, anstatt als Domäne der knappen AppSec-Spezialisten vor Ort.

An der University of Queensland in Australien macht Professor Ryan Ko große Fortschritte bei der Vorbereitung der nächsten Welle von Entwicklern, die uns vor dem unvermeidlichen Ansturm von Cyberangriffen schützen sollen:

"Die meisten Software-Schwachstellen werden in der Kodierungsphase eingeführt. Wenn wir also an der Quelle (d. h. beim Programmierer) ansetzen können, wären wir in der Lage, die meisten der immer wiederkehrenden Probleme, die heute in der CVE-Liste aufgeführt sind, auszumerzen. Da Software das Leben und den Lebensunterhalt der meisten Menschen in unserer modernen Gesellschaft beeinflusst, haben die Universitäten und Ausbildungseinrichtungen eine moralische und soziale Verantwortung, allen angehenden Programmierern beizubringen, wie man sicher programmiert", sagte er.

Dies ist eine aufregende Entwicklung gegenüber dem Standard courses, der nur sehr wenig in Bezug auf ein signifikantes Sicherheitsbewusstsein und -wissen bietet. Und dies ist ein "Virus", den ich gerne weiter verbreiten würde. Zu meiner Freude infiziert auch die Macquarie University ihre Studenten mit einer auf Sicherheit ausgerichteten Denkweise, dank der Bemühungen von Personen wie Christophe Doche:

"Der 2016 ins Leben gerufene Optus Macquarie University Cyber Security Hub ist die erste Initiative dieser Art in Australien, die Akademiker aus den Bereichen Informationssicherheit, Wirtschaft, Kriminologie, Nachrichtendienst, Recht und Psychologie mit Cybersecurity-Experten aus Industrie und Regierung verbindet.

Unser Ziel ist es, Australien durch Bildung, Forschung und Partnerschaften als weltweit führendes Land im Bereich Cybersicherheit zu positionieren. Ein wichtiger Aspekt dabei ist, die gut dokumentierte Qualifikationslücke im Bereich Cybersicherheit zu schließen. Prognosen zeigen, dass im Jahr 2022 weltweit höchstwahrscheinlich 1,8 Millionen Stellen nicht besetzt werden können.

Um diese Qualifikationslücke zu schließen, bedarf es eines mehrgleisigen Ansatzes, der sowohl die Weiterbildung und Umschulung der vorhandenen Arbeitskräfte als auch die Ausbildung einer neuen Generation von Cybersicherheitsspezialisten umfasst", sagte er.

Ihr Ansatz ist unglaublich: Sie bieten hoch motivierendes, präzises Lernen, das hilft, Lücken zwischen Abteilungen zu überbrücken und ein florierendes Sicherheitsbewusstsein zu schaffen. Sie nutzen die Vorteile von Microlearning in ihrer Strategie und bieten gamifizierte, mundgerechte Lernmodule mit einer hohen Rate an Behalten, Engagement und Wiederholung. Ich bin besonders stolz darauf, dass wir ihnen helfen können, ihre Studenten kreativ einzubinden:

"Ein hervorragendes Beispiel für dieses Engagement ist die Partnerschaft mit Secure Code warrior. Nach einer tournament , die von Secure Code Warrior und dem Cyber Security Hub im August 2019 organisiert wurde, prüfen wir nun die Einbettung der Plattform Secure Code Warrior in unseren Lehrplan, insbesondere in unserer neuen Einheit zur Entwicklung sicherer Anwendungen", so Christophe.

Initiativen wie die der Macquarie University und der University of Queensland sind echte Pioniere für sicheres Coding im Bildungsbereich. Unser Ziel als AppSec-Experten, Entwickler und als breitere Sicherheits-Community muss es sein, Sicherheit in alles einzubauen, was wir tun, und unser Engagement fortzusetzen, links zu beginnen.

Am 3. September nahmen ich und einige Mitglieder des Teams an einer großartigen Konferenz zur Verleihung von Sicherheitspreisen teil, die von CSO Australia ausgerichtet wurde. Die Women in Security Awards 2019, eine der ersten ihrer Art in Australien, waren ein unglaublicher Höhepunkt für einige der angesehensten Sicherheitsexperten der Branche. Es war eine Feier der weiblichen Beiträge in der Cybersicherheit sowie eine dringend benötigte Plattform, um das unglaubliche Talent und die Innovationen von Frauen zu präsentieren, die oft außerhalb des Rampenlichts stehen und daran arbeiten, einen erstaunlichen Job zu machen.

Es erfüllt mich mit großem Stolz zu sagen, dass Secure Code Warrior's VP of Customer Success (a.k.a. Chief Awesome), Fatemah Beydoun, ein wesentlicher Bestandteil dieses Tages war. Sie präsentierte ihren Vortrag " Mentoring for the future: How we can all do better in fostering female cybersecurity talent " vor einem sehr aufgeschlossenen Publikum. Obwohl zwölf Minuten nicht annähernd genug Zeit sind, um ihren langjährigen Einfluss auf uns und die gesamte Cybersicherheitsbranche darzustellen, hat sie entscheidende positive Veränderungen gesehen (um nicht zu sagen, vorangetrieben).

Ein umfassenderer Ansatz.

"Als ich meine Karriere in dieser Branche begann", so Fatemah, "war ich eine der wenigen Frauen in den Teams, in denen ich eingesetzt wurde. Viele der Networking-Möglichkeiten waren ebenfalls männerzentriert, was es mir erschwerte, mitzumachen, die richtigen Leute zu treffen und den entscheidenden Wert für das Unternehmen zu demonstrieren. Ich habe versucht, diese Dynamik zu ändern und wenn möglich einen inklusiveren Raum zu schaffen.

Ich besuchte zum Beispiel oft Branchenveranstaltungen und stellte fest, dass viele Firmenstände Werbemodelle einsetzten, um die Aufmerksamkeit auf ihre Stände zu lenken. Das ist in der Theorie in Ordnung, aber ich wurde oft ignoriert, da ich eindeutig nicht der Zielmarkt war. Zu Beginn meiner Karriere war ich für die Durchführung von Veranstaltungen verantwortlich und schwor mir, dass wir uns inklusivere und unterhaltsamere Wege einfallen lassen könnten, um auf unsere eigenen Angebote aufmerksam zu machen", sagt sie.

Fatemah und ich arbeiten schon lange zusammen, und sie hat sich immer für Inklusion und Vielfalt in den Unternehmen eingesetzt, in denen wir tätig waren. Das hat immer zu mehr Wegen für Frauen im Team, zur Anerkennung wichtiger Beiträge und zu einer Kohorte geführt, die durch unterschiedliche Ansätze, Meinungen und Lebenswege gestärkt wird.

"Natürlich will niemand die Alibifrau sein", sagte Fatemah. "Das Problem kann jedoch sein, dass einige weniger vielfältige Führungsteams dazu neigen, den Staffelstab an diejenigen weiterzugeben, die ihnen ähnlich sind und mit denen sie sich auf einer persönlichen Ebene identifizieren können. Dieselben Führungskräfte könnten von einer Frau profitieren, die aufgrund ihrer Verdienste und Fähigkeiten einen Beitrag leistet, aber oft ist es schwer für sie, einen Einblick zu bekommen. Wenn den Führungskräften bewusst gemacht wird, welche Stärken Vielfalt mit sich bringen kann (und das geht über das Geschlecht hinaus), sind sie oft bereit, diese Wege zu schaffen und Frauen zu fördern, die bereit, willens und fähig sind, einen großartigen Job für ihr Unternehmen zu machen", sagte sie.

Flexibilität am Arbeitsplatz: Schlüsselfaktoren für den Erfolg.

Als ich mein eigenes Unternehmen gründete, lernte ich sehr schnell, dass die beste Arbeit geleistet wird, wenn die Teammitglieder den Raum zum Atmen haben. Flexibilität ist für jeden wichtig, aber Maßnahmen, die berufstätige Familien unterstützen, können entscheidend sein, um wichtige Talente zu halten.

Eine der ersten Richtlinien, die hier eingeführt wurde, war die "Infant-At-Work-Policy", die es frischgebackenen Müttern ermöglicht, früher an ihren Arbeitsplatz zurückzukehren, da sie die nötige Flexibilität für Termine und die Möglichkeit haben, Säuglinge mit zur Arbeit zu bringen, ohne ein Urteil befürchten zu müssen.

"Ich wollte mich nicht zwischen dem Muttersein und meiner Karriere entscheiden, und die Möglichkeit, meinen kleinen Sohn mit zur Arbeit zu bringen, war ein so positiver Schritt, dass ich mich unterstützt und geschätzt fühlte", sagt Fatemah. "Meine Fähigkeiten verschwinden nicht nach der Geburt, und als Gründungsmitglied eines Startups, nun ja, man will einfach wieder einsteigen!"

Sie hat sogar mit ABC News über die Vorteile von flexibler Arbeit gesprochen:

Haben Sie eine blühende Mentorenkultur?

Um eine große Karriere zu starten und den Schwung beizubehalten, ist es eine gute Idee, einen Mentor zu haben. In vielen IT-, Cybersecurity- und männerdominierten Bereichen gibt es ein ziemliches Ungleichgewicht von Frauen in Führungspositionen im Vergleich zu Männern, sodass es eine kleine Herausforderung sein kann.

Während es für Frauen wichtig ist, "sich selbst" in Führungspositionen zu sehen, können auch Männer dazu beitragen, indem sie die klugen Frauen in ihren Teams fördern und ihnen, wenn möglich, als Mentoren zur Seite stehen.

"Führungsteams können einen enormen Einfluss auf die Diversifizierung in einem Unternehmen haben und sicherstellen, dass außergewöhnliche Frauen die Anerkennung und die Karrierewege bekommen, die sie genauso verdienen wie alle anderen. Ich habe dies bei Jetstars Head of Cyber Security, Yvette Lejins, in Aktion gesehen. Sie ist eine Verfechterin von Frauen und hat durch ihren eigenen Erfolg und ihre harte Arbeit anderen Frauen geholfen, das Selbstvertrauen zu entwickeln, um nach oben zu streben", sagte Fatemah.

So wie es aussieht, hat Secure Code Warrior gerade das Erreichen von 100 Mitarbeitern gefeiert. Ich bin stolz darauf, dass wir einen Frauenanteil von über 50 % im gesamten Unternehmen haben, und Fatemah ist ein außergewöhnliches Vorbild und Mentor für alle.

Alle Unternehmen können eine immense Stärke in der Diversifizierung ihrer Teams finden. Eine Reihe von Meinungen, aus verschiedenen Lebensbereichen, kann die geheime Zutat sein, die benötigt wird, um gute Ideen in großartige Ideen zu verwandeln. Wie immer gilt: Gemeinsam sind wir alle stärker.

Die Softwaresicherheitsbranche ist nicht gerade für ihre warmen und flauschigen Gefühle, skurrilen Beobachtungen und Lebenskommentare bekannt, aber vielleicht finde ich mich mit zunehmendem Alter dabei wieder, über den Einfluss nachzudenken, den wir alle in der Welt haben können. Und das kann einen positiven Ripple-Effekt haben, der weit über die Grenzen der Cybersicherheit hinausgeht.

Dank der Anregung eines Teammitglieds haben wir das Programm "Warriors Give Back" unternehmensweit eingeführt. Diese Initiative wurde entwickelt, um uns in den Geist des "Zurückgebens" an die Gemeinden um uns herum zu versetzen, indem wir aktiv als Team daran arbeiten, die Welt ein kleines bisschen heller zu machen.

Während es für viele von uns eine unglaubliche Gelegenheit war, als ein vereintes Team zusammenzuwachsen, war dies ein einzigartiger Moment, um einen Schritt zurückzutreten, das Land zu überblicken und mit neuer Klarheit zu sehen, was wirklich wichtig ist. Jeder, der in einem Startup arbeitet, wird Ihnen sagen, dass es superhektisch sein kann, mit nicht viel Auszeit... es ist lohnend, anstrengend und aufregend zugleich. Wenn Sie jedoch Ihr Geschäft leben und atmen, kann es allzu leicht sein, das Leben um Sie herum auszuschließen.

Eine Kraft für das Gute.

Das Wichtigste, was wir zu erreichen hofften, war, etwas unmittelbar Nützliches für die Gemeinschaft zu tun, nicht nur für ein paar Fotos zu posieren, um uns selbst auf die Schulter zu klopfen. Es ging darum, unser Privileg anzuerkennen und mit Dankbarkeit zu handeln. Jeder, in jeder Branche, könnte ein bisschen mehr davon gebrauchen. Schließlich kann man nie zu viel guten Willen verbreiten oder zu bescheiden bleiben.

Für unsere Auftaktveranstaltung beschlossen wir, gemeinsam Fahrräder für unterprivilegierte Kinder im Rahmen des Programms "Bikes for Tykes " zu bauen. Ich bin mir sicher, dass wir auf diesen Tag mit schönen Erinnerungen an unsere gemeinsamen mechanischen Fähigkeiten (oder deren Fehlen) und vielen Lachern zurückblicken werden, aber der Funke des Glücks, der neun ganz besonderen Kindern in einer Zeit gebracht wurde, in der sie es am meisten brauchten, ist eine Belohnung, die weit über den materiellen Aspekt eines brandneuen Fahrrads hinausgeht. Diese Veranstaltung war eine kleine Geste unsererseits, aber ich hoffe, dass sie für eine kleine Weile ihre Probleme vergessen und einfach nur genießen konnten, Kinder zu sein.

Zurückgeben, mehr bekommen.

Ein altes Sprichwort lautet in etwa: "Freundlichkeit ist ein Geschenk, das sich jeder leisten kann". Das ist sehr wahr, aber eine Sache, die die Cybersicherheits-Community im Besonderen gut zu machen scheint, ist die Fülle an kostenlosem Wissensaustausch und Online-Ressourcen, die den Menschen helfen, zu verstehen, zu lernen und zu erforschen. Natürlich widmen Organisationen wie OWASP so viel Zeit, um uns alle sicherer zu machen, und ich erlebe ständig die Bereitschaft anderer, bei der Beantwortung von Fragen nach Veranstaltungspräsentationen und -veranstaltungen zu helfen. Ich denke, wenn wir alle mehr geben würden, würden wir feststellen, dass es sich letztendlich zehnfach auszahlt.  

Wir werden unser Bestreben fortsetzen, etwas zurückzugeben, so wie es viele andere großartige Unternehmen auf der ganzen Welt tun. Lassen Sie uns eine Kraft für positive Veränderungen sein, egal wo wir sind.

(Psst: unsere Bibliothek von Lernressourcen für Entwickler ist immer für Sie geöffnet).

Die jüngsten Berichte über den jugendlichen Sicherheitsforscher Bill Demirkapi, der große Schwachstellen in der von seiner Schule verwendeten Software aufdeckte, weckten sicherlich einige Erinnerungen. Ich erinnere mich daran, wie ich als neugieriges Kind die Haube von Software öffnete, um einen Blick darunter zu werfen und zu sehen, wie alles funktioniert - und noch wichtiger - ob ich es knacken kann. Seit Jahrzehnten bemühen sich Software-Ingenieure um eine kontinuierliche Verbesserung und Verstärkung ihrer Produkte, und die Sicherheits-Community (auch wenn sie manchmal etwas frech vorgeht) spielt eine wichtige Rolle bei der Entdeckung von Fehlern und potenziellen Katastrophen, hoffentlich bevor ein Bösewicht das Gleiche tut.

Das Problem hier ist jedoch, dass er als Reaktion auf seine Entdeckungen eine kleine Suspendierung von der Schule trug. Und das kam erst, nachdem er alle Möglichkeiten ausgeschöpft hatte, das Unternehmen(Follett Corporation) privat zu kontaktieren, und sich schließlich für eine ziemlich öffentliche Explosion entschied, um sich und seine Fähigkeit, in ihr System einzubrechen, zu identifizieren. Seine wiederholten Versuche, die Follett Corporation auf ethische Weise zu warnen, blieben ohne Antwort, während die Software weiterhin angreifbar blieb und Berge von Schülerdaten ziemlich leicht offengelegt werden konnten, da ein Großteil davon unverschlüsselt war.

Er jagte auch Bugs in der Software einer anderen Firma: Blackboard. Während die Daten von Blackboard zumindest verschlüsselt waren, hätten potenzielle Angreifer eindringen und Millionen weiterer Datensätze abgreifen können. Sowohl diese Software als auch das Produkt von Follett waren an seiner Schule im Einsatz.

Die Erzählung vom "bösen Hacker" ist problematisch.

Demirkapi präsentierte seine Erkenntnisse auf der diesjährigen DEF CON, wobei die boshafteren Details seiner Possen den Beifall der Menge fanden. Und das zu Recht - obwohl er anfangs in der Kritik stand und viele Hürden überwinden musste, um seine Entdeckungen anerkannt zu bekommen, war die Follett Corporation Berichten zufolge dankbar für seine Bemühungen und folgte seinem Rat, was letztendlich dazu führte, dass sie ihre Software sicherer machten und die Krise abwendeten, eine weitere Statistik für Datenverletzungen zu werden. Außerdem wird er nach seinem Schulabschluss das Rochester Institute of Technology besuchen. Es ist also klar, dass er auf dem richtigen Weg ist, ein gefragter Sicherheitsspezialist zu werden.

Als Sicherheitsexperte fällt es mir schwer, mich nicht darüber zu ärgern, wie diese Situation gehandhabt wurde. Obwohl in diesem Fall alles gut ausgeht, wurde er anfangs wie ein lästiges Skript-Kiddie behandelt, das seine Nase in Dinge steckt, die es nicht betrifft. Bei einer Google-Suche nach dem Vorfall finden sich Artikel, die ihn als "Hacker" bezeichnen (was ihn in den Augen des Sicherheitslaien in vielerlei Hinsicht zum Bösewicht macht), obwohl seine Herangehensweise (und die vieler anderer) dazu beiträgt, dass unsere Daten sicher sind.

Wir brauchen neugierige, clevere und sicherheitsbewusste Menschen, die unter die Haube schauen, und wir brauchen das viel öfter. Bis Juli wurden allein in diesem Jahr mehr als vier Milliarden Datensätze durch böswillige Datenverletzungen offengelegt. Dank des Einbruchs bei der Mode- und Lifestyle-Marke Poshmark im August können Sie möglicherweise weitere fünfzig Millionen zu dieser Zahl hinzufügen.

Wir machen die gleichen Fehler, und noch beunruhigender ist, dass es sich oft um einfache Schwachstellen handelt, die uns immer wieder zum Stolpern bringen.

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

Wie WIRED berichtet, wurden Blackboards Community Engagement Software und Folletts Student Information System von Demirkapi gefunden, um gängige Sicherheitsfehler wie Cross-Site Scripting (XSS) und SQL Injection zu enthalten, die beide seit den 1990er Jahren Haare auf der Zunge von Sicherheitsspezialisten sind. Wir haben ihre Existenz für eine wirklich lange Zeit ertragen, und ähnlich wie Hypercolor-T-Shirts und Disketten sollten sie mittlerweile eine ferne Erinnerung sein.

Aber das sind sie nicht, und es ist klar, dass nicht genug Entwickler ein angemessenes Sicherheitsbewusstsein an den Tag legen, um die Einschleusung dieser Schwachstellen in ihren Code zu verhindern. Scanning-Tools und manuelle Code-Reviews können nur so viel tun, und es gibt weitaus komplexere Sicherheitsprobleme als XSS und SQL-Injection, bei denen diese teuren und zeitaufwendigen Maßnahmen besser eingesetzt werden könnten.

Leute wie Bill Demirkapi sollten Entwickler dazu inspirieren, einen höheren Standard für Code zu schaffen; mit nur 17 Jahren brach er in zwei hochfrequentierte Systeme ein, indem er Bedrohungsvektoren ausnutzte, die hätten erkannt und korrigiert werden müssen, bevor der Code überhaupt festgelegt wurde.

Gamification: Der Schlüssel zum Engagement?

Ich habe viel darüber geschrieben, warum Entwickler sich kaum mit Sicherheit beschäftigen, und die kurze Antwort ist, dass weder auf organisatorischer noch auf Ausbildungsebene 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 motivieren, es weiter zu versuchen, beginnen diese lästigen Relikte von Sicherheitslücken aus der Software zu verschwinden, die wir verwenden.

Demirkapi hat offensichtlich ein außerschulisches Interesse an Sicherheit und hat sich die Zeit genommen, zu lernen, wie man Malware zurückentwickelt, Schwachstellen entdeckt und, nun ja, Dinge knackt, die von außen nicht kaputt aussehen. In einem Gespräch mit VICE (und über seine DEF CON-Folien) machte er jedoch eine interessante Aussage zu seiner Selbsterziehung... er hat sie gamifiziert:

Mit dem Ziel, etwas in der Software meiner Schule zu finden, war es eine unterhaltsame "spielerische" Art, mir selbst einen bedeutenden Teil der Penetrationstests beizubringen. Obwohl ich meine Nachforschungen mit der Absicht begann, mehr zu lernen, fand ich am Ende heraus, dass die Dinge viel schlimmer waren, als ich erwartet hatte", sagte er.

Nicht jeder Entwickler wird sich auf Sicherheit spezialisieren wollen, aber jeder Entwickler sollte die Möglichkeit haben, sich ein Sicherheitsbewusstsein anzueignen, wobei die Grundlagen quasi als "Lizenz zum Coden" innerhalb einer Organisation dienen, insbesondere bei denjenigen, die die Kontrolle über Massen 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 versuchen, Schaden anzurichten.

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

Obwohl VxWorks dem Durchschnittsverbraucher nicht gerade ein Begriff ist, profitieren viele Menschen wie Sie und ich jeden Tag von diesem Softwareprodukt. Als das weltweit beliebteste Echtzeit-Betriebssystem (RTOS) ist es das Arbeitspferd, auf das wir uns (stellvertretend) verlassen, um Unternehmensnetzwerke und Firewalls, Schnittstellen in der Luft- und Raumfahrt, Industrieanlagen und sogar einige medizinische Geräte zu betreiben, um nur einige Anwendungen seiner weitverbreiteten Nutzung zu nennen.

Und jetzt sind wir mit der Möglichkeit konfrontiert, dass Hunderte Millionen, wenn nicht Milliarden, dieser Geräte mit mindestens elf Sicherheitslücken kompromittiert sind. Der Chief Security Architect von Wind River, Arlen Baker, hat diese Zahl in einem Artikel von SearchSecurity bestritten und verraten, dass der genaue Umfang unbestätigt ist und nicht als so hoch angesehen wird. Trotzdem wissen wir bereits, dass Datenschutzverletzungen und Angriffe ständig passieren, aber dies ist die nächste Stufe: Die bestätigten Schwachstellen sind relativ einfach auszunutzen, wobei viele die Tür öffnen und Angreifern erlauben, Geräte durch die Übertragung von Netzwerkpaketen aus der Ferne zu kontrollieren.

Wind River hat natürlich eine Reihe von Fixes und Patches für betroffene Kunden und Mitarbeiter veröffentlicht. Das Problem liegt in der schieren Anzahl der Geräte, die das Patch-Update benötigen - ähnlich wie Thanos die Welt mit einem Fingerschnippen beendet, ist es unvermeidlich, dass viele Geräte für lange Zeit ungepatcht und damit angreifbar bleiben werden.

Die Sicherheitsfirma Armis stand hinter dieser gigantischen Entdeckung und nannte ihre Ergebnisse URGENT/11. Sie haben ihn als ernsthaft eingestuft, zweifellos aufgrund der Leichtigkeit des Angriffs über mehrere Vektoren und des Potenzials für eine umfassende Infektion. Die Erstellung und Verbreitung eines Wurms in Software, die von MRT-Scannern und VOIP-Produkten bis hin zu Zugnetzwerken und Verkehrsampeln reicht, ist durchaus möglich.

Ist es Zeit für Panik?

Als jemand, der das Sicherheitsbewusstsein zu einer wichtigen Aufgabe in seinem Leben gemacht hat, sehe ich tagtäglich eine Menge potenzieller Sicherheitsprobleme. Ich würde den größten Teil meines Tages in Hysterie verbringen, wenn ich mir erlauben würde, zu sehr in Panik zu verfallen (schließlich möchte ich mich lieber der Aufgabe widmen, aufzuklären und bei der Behebung der Bugs zu helfen!) Das Ausmaß des URGENT/11-Fundes ist jedoch ziemlich erschreckend. Von den elf gefundenen Schwachstellen werden sechs als kritisch eingestuft. Wie The Hacker News feststellt, existieren diese Fehler in Geräten, auf denen VxWorks seit Version 6.5 läuft (mit Ausnahme der Versionen, die für die Zertifizierung entwickelt wurden, einschließlich VxWorks 653 und VxWorks Cert Edition), was bedeutet, dass einige lebenswichtige Technologien schon seit über einem Jahrzehnt von Angriffen auf Geräte bedroht sind. Nicht jedes Gerät ist für alle elf Schwachstellen anfällig (und einige können nur ausgenutzt werden, wenn sich der Angreifer im selben LAB-Subnetz befindet), aber selbst ein mittelmäßiger Hacker braucht nur ein kleines Zeitfenster.

Es ist wichtig anzumerken, dass Wind River schnell gehandelt und detaillierte Ratschläge zur Entschärfung der Probleme gegeben hat, ebenso wie Armis. Und das VxWorks RTOS ist so weit verbreitet , weil es so zuverlässig ist und hohe Werte bei den Software-Sicherheitsvorschriften erreicht - typischerweise kümmern sich Bug-Bounty-Jäger nicht allzu sehr darum. Wie auch immer, Sicherheitsfirmen und Wind River können nur so viel tun, um das Problem zu lösen... es liegt in der Hand des Endanwenders, Patches herunterzuladen, Sicherheitshinweise zu beherzigen und seine eigenen Geräte zu verstärken, und genau da wird es knifflig.

Vielleicht müssen wir noch nicht in Panik verfallen, aber es könnte ein Dorf brauchen, um diese Bestie in die Schranken zu weisen.

Die URGENT/11-Schwachstellen erklärt

Zu diesem Zeitpunkt könnte jedes Gerät, das mit dem kompromittierten VxWorks TCP/IP IPnet-Stack seit Version 6.5 verbunden ist, von mindestens einem der URGENT/11 betroffen sein. (Eine vollständige Liste der CVEs von Wind River finden Sie hier).

In den meisten Fällen ermöglichen diese Schwachstellen die Remote-Code-Ausführung (RCE) und Denial-of-Service-Angriffe, wobei einige auch zur Preisgabe von Informationen und zu Problemen mit der Geschäftslogik führen können. Die Remote-Code-Ausführung ist in diesem Fall besonders heikel, da ein Angreifer die Kontrolle über ein Gerät übernehmen kann, ohne dass der Endbenutzer eingreifen muss. Niemand muss versehentlich auf etwas Verdächtiges klicken, etwas herunterladen oder seine Daten eingeben... Das macht VxWorks-Geräte in hohem Maße "wurmbar" und der Angriff kann ein automatisiertes Eigenleben entwickeln. Erinnern Sie sich an den WannaCry-Wurm von EternalBlue? URGENT/11 hat ein ähnliches, aber noch verheerenderes Potenzial, uns weltweit Kopfschmerzen zu bereiten.

Was können wir dagegen tun?

Nun, zum Zeitpunkt des Schreibens sind die Folgen von URGENT/11 noch nicht bekannt. Die Medien haben die Branche darauf aufmerksam gemacht, und Wind River bietet den Betroffenen eindeutig Unterstützung an. In den kommenden Monaten wird sich zeigen, ob Angreifer diese bekannten Schwachstellen auf sinnvolle Weise ausnutzen werden, aber in der Zwischenzeit besteht die offensichtliche Lösung darin, die zahlreichen Ratschläge zu beherzigen und alle relevanten Geräte in Ihrer Umgebung zu patchen.

Langfristig bleibt es die gleiche Mission: Jeder muss es besser machen, wenn es um die Software-Sicherheit geht. Die URGENT/11 CVEs sind im Allgemeinen beunruhigend einfache Hintertüren, durch die man gehen kann, und die Tatsache, dass sie viele Jahre lang unentdeckt blieben, ist ein Zeugnis dafür, dass die allgemeine Besorgnis und das Bewusstsein in der Branche recht gering sind.

Jeder Entwickler hat die Chance, seinen Teil beizutragen, und sie brauchen die Unterstützung, um zu lernen, wie man Code von Beginn der Produktion an sichert. Die einflussreichen Teams um sie herum, jeder von AppSec bis zur C-Suite, können sicherstellen, dass eine positive Sicherheitskultur an jedem Software-Touchpoint im Unternehmen gedeiht.

Möchten Sie Ihr eigenes Sicherheitsbewusstsein testen? Unsere gamifizierte Plattform kann Ihnen echte Code-Herausforderungen bieten, ähnlich wie einige der in URGENT/11 entdeckten. Probieren Sie sie aus und sehen Sie, wie Sie abschneiden:

• Heap-Überlauf beim Parsen von DHCP-Offer/ACK in ipdhcpc (CVE-2019-12257)
  Speicherkorruption - Heap-Überlauf
• TCP-Verbindungs-DoS über missgestaltete TCP-Optionen (CVE-2019-12258)
  Unzureichender Schutz der Transportschicht - ungeschützter Transport sensibler Informationen
• Logische Schwachstelle in der IPv4-Zuweisung durch den DHCP-Client ipdhcpc (CVE-2019-12264)
  Fehler in der Geschäftslogik
• DoS über NULL-Dereferenz im IGMP-Parsing (CVE-2019-12259)
  Speicherkorruption - Null-Dereferenz
• IGMP-Informationsleck über IGMPv3-spezifischen Mitgliedschaftsbericht (CVE-2019-12265)
  Gefährdung von Informationen - Gefährdung sensibler Daten

Eine Version dieses Artikels erschien auf DevOps.de; er wurde neu betitelt und aktualisiert, um neue Informationen aufzunehmen.

Während CISOs und CIOs die wenig beneidenswerte Position haben, den Löwenanteil der Verantwortung für die Softwaresicherheit zu übernehmen, insbesondere im Falle einer peinlichen Verletzung der Unternehmensdaten, bietet sich ihnen auch eine einzigartige Chance von zunehmender Relevanz: Sie sind die neuen Innovatoren, und sie können mit dem richtigen Ansatz sehr einflussreich sein. Jede Organisation auf der Welt, sowohl öffentliche als auch kommerzielle, kämpft darum, ihren Marktanteil in einer sich schnell digitalisierenden Welt zu halten (und zu gewinnen). Kunden erwarten ein nahtloses Online-Erlebnis sowohl von bisherigen als auch von zukünftigen Produkten, und ein "digital-first"-Geschäftsansatz wird zur Pflicht. Denn wenn diese Erwartungen nicht erfüllt werden, steht mit ziemlicher Sicherheit ein Konkurrent bereit, um die Gelegenheit zu ergreifen.

Was bedeutet das also für den modernen CISO oder CIO? Natürlich bedeutet es, dass sie Teams von Entwicklern beschäftigen, die Zeile für Zeile des Codes erstellen, der ihr digitales Produkt oder ihre Dienstleistung ausmacht. Cybersicherheit ist zwar schon seit vielen Jahren ein wichtiges Thema, wird aber zu einem immer größeren Risikofaktor, da immer mehr Geschäftsvorgänge online und im Visier von Angreifern durchgeführt werden. Die Auswirkungen einer Sicherheitslücke sind enorm, aber ein Ausstieg aus der Digitalisierung ist keine Option.

Kreative CISOs und CIOs befinden sich in einer erstklassigen Position, um gemeinsam mit ihren AppSec- und Entwicklungsteams den Weg in unsere digitale Zukunft weiter zu schmieden. Sie werden zweifellos die langfristige Innovation von Unternehmen, Behörden und öffentlichen Diensten im Internet gestalten, aber sie tragen die schwere Verantwortung, die Balance zwischen schnellen Markteinführungszielen, hoher Softwarequalität und der Minderung von Sicherheitsrisiken zu halten.

Dieses Gleichgewicht ist bis heute immens schwer zu erreichen. Es hat zu Entwicklungsteams geführt, die oft fragmentiert sind und sich in erster Linie auf die Bereitstellung von Features und Funktionen konzentrieren, ohne sich Gedanken über die Schwachstellen zu machen, die sie in dem Code, den sie so schnell produzieren, verursachen könnten. AppSec-Spezialisten beheben ständig die gleichen Fehler, während die Gefahr eines Einbruchs durch eine relativ einfache Hintertür, die offen gelassen wird, groß ist.

Wenn unsere Daten sicher bleiben sollen, müssen CISOs und CIOs bei der Art und Weise, wie ihre Teams zusammenarbeiten, kreativ werden und eine Kultur der positiven Sicherheit und gemeinsamen Verantwortung von oben nach unten schaffen. Schauen Sie sich nur die katastrophalen Folgen an, die Marriott aufgrund des Datenschutzverstoßes 2018 zu tragen hatte: Eine GDPR-Strafe von über 123 Millionen US-Dollar, mehr als 500 Millionen gestohlene Datensätze und ein ramponierter Ruf in Sachen Sicherheit. Dieses Desaster ist zu einem großen Teil auf unsichere Kodierungspraktiken zurückzuführen, denn bereits 2014 wurden SQL-Injection-Schwachstellen auf den Servern von Starwoods aufgedeckt, einem Unternehmen, das 2016 von Marriott übernommen wurde. Deren anschließende Nutzung der Software blieb aus Sicht der Anwendungssicherheit offensichtlich ungeprüft. Dies gab böswilligen Angreifern mehrere Jahre lang die Möglichkeit, auf Daten zuzugreifen und sich diese anzueignen, während andere Schwachstellen, wie z. B. schwache Passwörter, im Laufe der Zeit weitere Löcher zum Ausnutzen hinterließen.

CIOs und CISOs müssen den Zustand ihres eigenen Software-Sicherheitsklimas sehr genau betrachten. Wie sicherheitsbewusst ist der durchschnittliche Entwickler? Wie gut arbeiten die AppSec- und Entwicklungsteams zusammen? Es gibt kein Patentrezept, aber an der Kultur, dem Training und dem Support kann gearbeitet und verbessert werden. Entwicklungsteams können sich von der ersten Risikolinie für Datenschutzverletzungen im Unternehmen zu den Sicherheits-Superhelden wandeln, die schlechten Code stoppen, bevor er überhaupt in Produktion geht.

Gesundheitscheck für sichere Kodierung: Ist Ihre auf Lebenserhaltung?

Wo passt Ihr eigenes Entwicklungsteam hin? Ich habe diese Checkliste für sichere Kodierung erstellt, um CIOs und CISOs dabei zu helfen, herauszufinden, ob ihre Entwicklungsteams wirklich dafür gerüstet sind, sichere Kodierungs-Champions zu sein und mit schnellerem, besserem und sichererem Code zu Innovationen beizutragen (oder ob Sie tatsächlich eine Überholung des Sicherheitsprogramms benötigen):

1. Wie unterstützend ist der Rest Ihrer C-Suite? Verstehen sie, dass traditionelle Netzwerksicherheit nicht mehr ausreicht?

In der Zukunft der Software ist die Absicherung der Netzwerkebene mit veralteten Sicherheitsmaßnahmen einfach nicht gut genug (und, seien wir ehrlich, ist ohnehin selten erfolgreich), selbst gegen semiprofessionelle Hacker. Neben vielen übereinstimmenden Berichten zitiert der "2017 Data Breach Investigations Report" von Verizon, dass erschütternde 35 Prozent der heutigen Datenschutzverletzungen durch Schwachstellen in Webanwendungen verursacht werden.

Die Sicherheit von Webanwendungen ist genauso wichtig wie die Netzwerksicherheit. Wenn Sie dies ignorieren und es versäumen, die grundlegende Schutzschicht von AppSec-Maßnahmen einzuplanen und zu installieren, könnten Sie einem Einbruch Tür und Tor öffnen.

2. Schalten Sie weit genug nach links, und tun Sie es früh genug?

Der derzeitige Ansatz für die Anwendungssicherheit ist recht toollastig und konzentriert sich darauf, sich im Lebenszyklus der Softwareentwicklung (SDLC) von rechts nach links zu bewegen. Dies erkennt per Definition und Design an, dass der Prozess fehlerhaft ist und unterstützt ein Erkennungs- und Reaktionsergebnis. Sicherheitsteams suchen und entdecken Schwachstellen in bereits geschriebenem Code und reagieren, um den übergebenen Code zu korrigieren, anstatt sicherzustellen, dass er bei der Erstellung fehlerfrei ist. Laut dem National Institute of Standards and Technology(NIST) ist es 30-mal teurer, Schwachstellen in festgeschriebenem Code zu erkennen und zu beheben, als sie zu verhindern, während sie in der IDE geschrieben werden. Dabei sind die Verzögerungen bei der Produktion, die doppelte Bearbeitung und die Zeit, die für die Behebung derselben bekannten Sicherheitsprobleme immer wieder aufgewendet wird, noch nicht einmal eingerechnet.

Eine wirklich robuste Sicherheitskultur besteht darauf, bei den Entwicklern selbst anzufangen und sie zu Sicherheits-Champions zu inspirieren, während sie dem Entwicklungsteam die richtigen Tools und Schulungen geben, um zu wachsen und mit einem sicheren Coding-Mindset zu handeln. Der Schwerpunkt liegt auf der kontinuierlichen Selbstentwicklung und dem Training ihrer Problemlösungsfähigkeiten, damit sie die erste Verteidigungslinie in ihrem Unternehmen sein können und häufige Schwachstellen von vornherein verhindern.

3. Bemühen Sie sich, praktische Sicherheitskompetenzen aufzubauen, oder füttern Sie nur einseitiges Wissen?

Die überwiegende Mehrheit der Sicherheitsschulungslösungen (online und CBT) konzentriert sich auf den Aufbau von Wissen statt auf praktische Fähigkeiten, die sich direkt auf ihre Arbeit beziehen. Damit Entwickler aufblühen und sich für das Schreiben von sicherem Code engagieren können, brauchen sie regelmäßigen Zugang zu kontextbezogenem, praxisnahem Lernen, das sie aktiv dazu ermutigt, sich weiterzubilden und ihre Fähigkeiten in einer realen Umgebung zu entwickeln. Sie müssen über kürzlich identifizierte Schwachstellen lernen, mit echten Codebeispielen, und in ihren bevorzugten Sprachen und Frameworks arbeiten können. Diese Lernerfahrung hilft ihnen effektiv dabei, zu verstehen, wie sie bekannte Schwachstellen in dem Code, an dem sie im Rahmen ihrer Arbeit aktiv arbeiten, lokalisieren, identifizieren und beheben können.

Es gibt zwar viele sachkundige Lehrer und jede Menge Informationen über die Behebung von Sicherheitslücken, aber das Durchblättern von Lehrbüchern oder das Anschauen von stundenlangen Videos scheitert daran, den Verstand vieler kreativer, problemlösungsorientierter Entwickler anzusprechen, und wenn die ständige Flut von Datenschutzverletzungen ein Hinweis darauf ist, bleibt es weitgehend unwirksam, zu verhindern, dass Sicherheitslücken in den Code gelangen.

4. Messen Sie Ihre Fähigkeiten zur sicheren Codierung mit Echtzeitmetriken?

Ein wichtiger Schritt, um sicherzustellen, dass innerhalb eines Entwicklungsteams eine sicherheitsorientierte Denkweise aufgebaut wird, ist das Sammeln und Überprüfen von Beweisen. Dies sollte keine Annahme oder ein Ratespiel sein: Entweder sind die Entwickler sicherheitsorientiert oder nicht.

Metriken sollen den Entwicklern und ihrer Organisation beweisen, dass sich ihre harte Arbeit auszahlt und sich ihre individuellen sicheren Programmierfähigkeiten verbessern. Man kann nicht verbessern, was man nicht messen kann. Es sollte relevante Bewertungen geben und diese sollten dabei helfen, den Fortschritt Ihrer Entwicklungsteams in Echtzeit zu identifizieren sowie ihre Stärken und Schwächen bei der sicheren Codierung für eine kontinuierliche Verbesserung zu benchmarken.

Allzu oft werden Sicherheitsschulungen zu einer "Tick-the-Box"-Übung für Unternehmen, ohne dass darauf geachtet wird, dass diese Schulungen effektiv sind, dass man sich mit ihnen beschäftigt oder sie sogar behält.

5. Verwenden Ihre ausgelagerten Anbieter robuste sichere Kodierungstechniken?

Viele Unternehmen entscheiden sich dafür, Entwicklungsarbeiten an Drittanbieter zu vergeben. Unabhängig davon, ob es sich um On- oder Offshore-Agenturen handelt, sind deren allgemeine Fähigkeiten und Praktiken im Bereich der sicheren Codierung für den Kunden ein relatives Geheimnis. Im besten Fall ist die einzige Form der Zusicherung, die ein Unternehmen in Bezug auf die Sicherheit erhält, eine Aussage im Vertrag, die verlangt, dass das zu liefernde Produkt "sicher" sein muss. Nur sehr wenige Unternehmen ergreifen Maßnahmen, um die Fähigkeiten dieser Entwicklungsfirmen im Vorfeld zu überprüfen, so dass das Risiko besteht, dass eine Software geliefert wird, die zwar wie vereinbart funktioniert, aber ohne solide sichere Kodierungspraktiken erstellt worden ist. Schlimmer noch: Wenn sich das einkaufende Unternehmen der inhärenten Sicherheitslücken in der Anwendung nicht bewusst ist, läuft es Gefahr, angreifbare Software in die freie Wildbahn zu schicken.

Das häufigste Szenario ist, dass alle Schwachstellen von dedizierten Sicherheitsspezialisten gefunden werden (Personen, die schwer zu finden und mit hohen Kosten verbunden sind), Sie mit einer Verzögerung Ihres Go-Live-Datums und möglichen Vertragsdiskussionen darüber konfrontiert werden, wer für die Behebung dieser Sicherheitsschwächen zahlen muss. Wenn Sie jedoch im Vorfeld klug vorgehen und die Fähigkeiten der Entwickler, die Ihre nächste Anwendung erstellen sollen, in Bezug auf die Anwendungssicherheit einschätzen, sparen Sie sich eine Menge potenzieller Verzögerungen, Frustration und Geld.

6. Kennen Ihre Entwickler die am häufigsten ausgenutzten Sicherheitsschwachstellen?

Mehr als 85 Prozent der ausgenutzten Schwachstellen in Webanwendungen werden auf nur 10 bekannte Schwachstellen zurückgeführt - die OWASP Top 10. Ihre Anwendungssicherheitsschulung muss mindestens diese und viele weitere Schwachstellenarten abdecken. Die Trainingsherausforderungen, mit denen Ihre Entwickler konfrontiert werden, müssen regelmäßig überarbeitet und aktualisiert werden, mit neuen Herausforderungen für entweder neue Coding-Frameworks oder neue Schwachstellenarten.

Präzises Training mit realen Szenarien für sichere Kodierung sollte der Standard sein; vages Allgemeinwissen ist einfach nicht effektiv. (Sie fragen sich, wie diese sicheren Codierungsszenarien aussehen könnten? Schauen Sie sich unsere Blog-Serie Coders Conquer Security an; in jedem Beitrag gibt es eine spielbare Herausforderung).

7. Haben Sie interne Sicherheits-Champions?

Jede entwicklungslastige Organisation sollte in einen Security Champion investieren - jemanden, der die Verantwortung für die Aufrechterhaltung eines hohen Sicherheitsstandards innerhalb des Entwicklerteams übernimmt. Ihr Zweck ist es, eine Anlaufstelle für alle zu sein, die Fragen zur Sicherheit haben, und der Hauptverfechter für die Einhaltung von Best Practices im Bereich Sicherheit zu sein.

Sie sind ein wichtiger Teil des Puzzles der Sicherheitskultur; ein großartiger Sicherheits-Champion kann den Schwung von intensiven Schulungen aufrechterhalten, sicherstellen, dass alle Teammitglieder das haben, was sie brauchen, und sich weiterhin für Unterstützung einsetzen.

8. Haben Sie in Tools für Ihre Entwickler investiert, um die sichere Kodierung zu erleichtern?

Wenn in Ihrem Unternehmen eine agile Entwicklung praktiziert wird oder Sie mit häufigen Aktualisierungen der vom Unternehmen erstellten Anwendungen konfrontiert sind, ist die Automatisierung von Teilen der Sicherheit eine der einzigen Möglichkeiten, mit dem rasanten Tempo und dem Arbeitsvolumen Schritt zu halten.

In jeder Phase des SDLC gibt es Tools, die als Berater, Qualitäts-Torwächter oder Erkennungswerkzeug dienen. Darüber hinaus führen einige Tools automatisierte Tests über den Code aus und simulieren Hacking-Versuche, sobald die Software in Produktion ist. Alle haben ihre eigenen Vorteile und Herausforderungen, und keines kann eine hundertprozentige Garantie bieten, dass keine Sicherheitsbedrohungen in der Anwendung existieren. Die wichtigste Präventivmaßnahme, die Sie anwenden können, ist, dass je früher Sie die Schwachstelle erkennen, desto schneller und kostengünstiger ist es, sie mit den geringsten Auswirkungen auf Ihr Unternehmen zu beheben.

Der nächste Schritt für vorausschauende CISOs

Wie hat Ihr Unternehmen also die oben genannte Checkliste erfüllt?

Während CISOs und CIOs im Wesentlichen gezwungen sind, ihre Unternehmens-DevOps- und DecSecOps-Fähigkeiten aggressiv aufzubauen, bedeutet das nicht, dass keine Zeit bleibt, um die richtigen Tools und Schulungen in den Teams zu berücksichtigen und zu implementieren. Sichere Coding-Fähigkeiten werden eine Waffe "und kein Hindernis" für Innovationen sein, und ein Verzicht darauf könnte die absolute Zerstörung der Unternehmensreputation und der Daten bedeuten. Diese Fähigkeiten stellen kritische Fähigkeiten und eine viel billigere langfristige Lösung dar, um Schwachstellen zu reduzieren und das Risiko zu mindern.

Ein brillanter, innovativer CISO hat die Macht, eine gesunde Sicherheitskultur von oben nach unten zu orchestrieren; stellen Sie sicher, dass Ihre Mitarbeiter das haben, was sie brauchen, um Best Practices im Bereich Sicherheit effektiv auszuführen.

Pieter Danhieux ist ein Sicherheitsexperte und Mitbegründer von Secure Code Warrior.

Eine Version dieses Artikels wurde ursprünglich veröffentlicht in Digital Transactions Magazin.

In diesem Jahr hat das PCI Security Standards Council eine komplett neue Reihe von Software-Sicherheitsrichtlinien als Teil des PCI Software Security Framework veröffentlicht. Dieses Update zielt darauf ab, die Best Practices für Software-Sicherheit mit der modernen Software-Entwicklung in Einklang zu bringen. Es ist eine fantastische Initiative, die anerkennt, wie sich dieser Prozess im Laufe der Zeit verändert hat und ein Überdenken der Sicherheitsstandards erfordert, die lange vor der rasanten Digitalisierung eines Großteils unseres Lebens festgelegt wurden.

Dies ist ein klarer Beweis dafür, dass sich unsere Branche stärker mit der Idee anpassungsfähiger Richtlinien auseinandersetzt - Richtlinien, die sich mit unseren sich ändernden Bedürfnissen weiterentwickeln - sowie mit den Anforderungen einer Cybersicherheitslandschaft, die sehr schnell außer Kontrolle geraten könnte, wenn wir in unseren sicheren Entwicklungsprozessen weiterhin nachlässig sind. Da das PCI Security Standards Council als Dachverband der Banken- und Finanzbranche fungiert (d. h. die Sicherheitsstandards für die Software festlegt, der wir vertrauen, um unser Geld, unsere Kreditkarten, unsere Online-Transaktionen und unsere Kassengeschäfte zu schützen), trägt es natürlich ein großes Risiko und hat eine große Motivation, dieses zu verringern.

Während diese Standards sicherlich eine Verbesserung gegenüber der Vorgängerversion darstellen und ein Stück weit dazu beitragen, die Lücke zu schließen, die wir in der schnellen, innovativen Funktionsentwicklung haben, die auch die Sicherheit als Teil ihrer Gesamtqualität priorisiert assessment, ist es eine etwas enttäuschende Realität, festzustellen, dass wir noch einen langen Weg vor uns haben.

Nein, das ist kein "bah, humbug!", das ich dieser Initiative entgegenbringe. Tatsache ist, dass diese neuen Sicherheitsrichtlinien uns einfach nicht weit genug nach links rücken.

Wir waren immer noch auf das Testen fixiert (und haben zu spät getestet).

Ein eklatantes Problem, das ich beim PCI Security Standards Framework gefunden habe, ist die offensichtliche Abhängigkeit vom Testen. Natürlich muss Software immer noch getestet werden (und der SAST/DAST/IAST-Prozess hat immer noch seinen Platz), aber wir tappen immer noch in dieselbe Falle und erwarten ein anderes Ergebnis.

Wer schreibt Zeile für Zeile Code, um die Software zu erstellen, die wir kennen, lieben und der wir vertrauen? Software-Entwickler.

Wer hat die wenig beneidenswerte Position, diesen Code zu testen, entweder mit Scanning-Tools oder manuellem Code-Review? AppSec-Spezialisten.

Was entdecken diese Spezialisten immer wieder? Die gleichen Fehler, die uns schon seit Jahrzehnten plagen. Einfache Dinge, von denen wir schon seit Jahren wissen, wie sie zu beheben sind: SQL-Injection, Cross-Site-Scripting, Schwachstellen in der Sitzungsverwaltung... für diese Leute ist es wie der Murmeltiertag. Sie haben ihre Zeit damit verbracht, Code-Verletzungen zu finden und zu beheben, die die Entwickler selbst schon seit Jahren beheben können, nur dass die Sicherheit in ihrem Prozess keine Priorität hat ", vor allem jetzt, im Zeitalter der agilen Entwicklung, wo die Bereitstellung von Funktionen im Vordergrund steht und die Sicherheit der Grinch ist, der den kreativen Prozess und den Triumph der Projektfertigstellung stiehlt.

Dies ist keine negative assessment eines der beiden Teams; Entwickler und AppSec-Experten haben beide extrem wichtige Aufgaben zu erledigen, aber sie kommen sich weiterhin gegenseitig in die Quere. Diese Situation verewigt nur einen fehlerhaften SDLC, in dem Entwickler mit wenig Sicherheitsbewusstsein in einer negativen Sicherheitskultur arbeiten und unsicheren Code produzieren, der dann lange nach seiner Entstehung gescannt, bewertet und behoben werden muss. AppSec hat kaum Zeit, die wirklich komplexen Probleme zu beheben, weil sie so sehr mit den kleinen wiederkehrenden Problemen beschäftigt sind, die für ein Unternehmen immer noch eine Katastrophe bedeuten können, wenn sie nicht behoben werden.

Wir verschwenden Zeit, Geld und Ressourcen, wenn wir zulassen, dass Testen das Allheilmittel für Sicherheitsschwächen im Code ist. Und mit massiven Datenschutzverletzungen jeden zweiten Tag, funktioniert diese Methode offensichtlich nicht optimal, wenn überhaupt. Diese neuen Standards bewerten immer noch einen Endproduktzustand (vielleicht unter der Annahme, dass alle Entwickler sicherheitsbewusst sind, was nicht der Fall ist): nämlich einen, der bereits gebaut ist. Dies ist die teuerste und schwierigste Phase, um Fehler zu beheben; es ist so, als würde man ein schickes, neues Haus bauen, nur um am selben Tag, an dem man einzieht, ein Sicherheitsteam hinzuzuziehen, um es auf mögliche Gefahren zu überprüfen. Wenn etwas mit dem Fundament nicht in Ordnung ist, stellen Sie sich den Zeitaufwand, die Kosten und das Kopfzerbrechen vor, die nötig sind, um diesen Bereich zu erreichen und die Probleme überhaupt anzugehen. Oft ist es einfacher und billiger, einfach noch einmal von vorne anzufangen (und was für ein völlig unbefriedigender Prozess das für jeden ist, der die erste Version gebaut hat).

Wir müssen unbedingt von Grund auf arbeiten: indem wir das Entwicklungsteam mit Best Practices für die Sicherheit vertraut machen, sie mit dem Wissen ausstatten, um effizient sicher zu programmieren, und zusätzlich eine positive Sicherheitskultur an jedem Arbeitsplatz schaffen und pflegen.

Ist es eine Lernkurve? Ja, das ist es. Ist es unmöglich? Definitiv nicht. Und es muss keine langweilige Plackerei sein. Trainingsmethoden, die direkt an die kreativen, problemlösenden Eigenschaften der Entwickler appellieren, haben im Banken- und Finanzsektor bereits immensen Erfolg gehabt, wenn man Russ Wolfes Erfahrung bei Capital One glauben darf.

Wir sind immer noch auf der Suche nach dem perfekten "End-Zustand".

Wenn Sie die aktualisierten PCI-Sicherheitsstandards in dem Kontext betrachten, für den sie gedacht sind, also - Ihr fertiges, benutzerfertiges Finanzprodukt muss diesen Best Practices für optimale Sicherheit und Schutz folgen, dann sind sie absolut in Ordnung. Meiner Meinung nach hätte jedoch jedes einzelne Unternehmen - ob im Finanzbereich oder anderswo - die besten Chancen, einen Software-Endzustand zu erreichen, der sowohl für die Qualität der Funktionen als auch für einen hohen Sicherheitsstandard repräsentativ ist, wenn sie nur einen Schritt zurücktreten und erkennen würden, dass es viel effizienter ist, dies von Beginn des Zyklus an zu tun.

Der perfekte Endzustand? Sie wissen schon, der, der eintritt, wenn ein Produkt gescannt und manuell überprüft wird und perfekt und fehlerfrei herauskommt? Wir sind immer noch auf der Suche danach. Zum jetzigen Zeitpunkt ist es ein Einhorn.

Warum ist es so schwer fassbar? Es gibt eine Reihe von Faktoren:

• Man verlässt sich auf Scanning-Tools, doch sie sind nicht immer effektiv. Falschmeldungen sind ein frustrierendes, zeitraubendes Nebenprodukt ihrer Verwendung, ebenso wie die Tatsache, dass DAST/SAST/PCI-Scans selbst zusammen einfach nicht jede mögliche Schwachstelle in der Code-Basis identifizieren und aufdecken können. Sicher, sie geben Ihnen vielleicht Entwarnung, aber suchen sie wirklich nach allem? Ein Angreifer braucht nur eine Schwachstelle auszunutzen, um auf etwas zuzugreifen, von dem Sie glauben, dass es geschützt ist.
• Die Entwickler machen immer wieder die gleichen Fehler. Es gibt keine Wissensverteilung zwischen Entwicklern rund um das Thema Sicherheit und keine "sicheren Code-Rezepte" (gute, sichere Codemuster), die bekannt und dokumentiert sind.
• Es wird kein Wert auf den Aufbau einer kollaborativen, positiven Sicherheitskultur gelegt.
• Entwickler müssen mit den richtigen Werkzeugen ausgestattet werden, um Sicherheit in die Produkte einzubauen, die sie schreiben, ohne ihre kreativen Prozesse und agilen Entwicklungsmethoden zu stören.

Diese Richtlinien sind eine aussagekräftige Checkliste für die Sicherheitsstandards, die Software einhalten sollte, aber der beste Prozess, um Software in diesen Zustand zu bringen, steht zur Debatte.

Wir haben keine unsichere Software, weil es an Scannern fehlt, wir haben unsichere Software, weil den Entwicklern keine einfach zu bedienenden, leicht verständlichen Sicherheitstools zur Verfügung gestellt werden, die sie anleiten.

Wir befinden uns gerade in einer Zeit der Evolution. Software-Sicherheit im Allgemeinen war viele Jahre lang optional. Heute ist sie im Grunde obligatorisch - vor allem für die Hüter sensibler Informationen (Finanzen, Medizin, Sozialversicherung... Sie verstehen schon).

Das PCI Security Standards Council hilft dabei, den Maßstab zu setzen, aber ich würde es gerne sehen, wenn sie - bei all ihrem Ansehen und Einfluss in der Branche - darauf hinarbeiten würden, praktische Richtlinien für Entwickler einzubauen, mit einem Schwerpunkt auf angemessenen und positiven Schulungen und Tools. Im Moment gibt es keinen Druck für Unternehmen, dafür zu sorgen, dass ihre Entwicklungsteams sicherheitsbewusst und konform sind, noch verstehen viele Entwickler das Ausmaß dieser kleinen, leicht zu behebenden Fehler, wenn sie von denen ausgenutzt werden, die Schaden anrichten wollen.

Wie bei allem, was im Leben von Wert ist, braucht es wirklich ein Dorf, um eine Veränderung herbeizuführen. Und die Veränderung, die in der Luft liegt, wird uns (hoffentlich) alle weiter nach links fegen.

Es scheint fast komisch, dass wir im Jahr 2019 über die Arbeit mit einer Computersprache sprechen, die 1959 erfunden wurde. Es gibt heutzutage nicht allzu viele Seminare oder Kongresse, die sich der Kunst widmen, klassische Singer-Nähmaschinen neu einzufädeln oder die Ölwanne an einem Chevrolet Parkwood oder einer Triumph Herald auszutauschen. Die meisten dieser in die Jahre gekommenen Werkzeuge haben längst ausgedient und sind durch neue und effizientere Modelle ersetzt worden. Doch hier im Technologieland, das im Vergleich zu anderen Branchen als hochmodern gilt, arbeiten wir immer noch mit Sprachen wie COBOL, das etwa zur gleichen Zeit veröffentlicht wurde.

Dafür gibt es natürlich sehr gute Gründe. Die Common Business Oriented Language (COBOL) mag 60 Jahre alt sein, aber sie war so gut konstruiert, dass sie auch heute noch relevant und weit verbreitet ist.

COBOL wurde als relativ einfache Möglichkeit geschaffen, mit Hilfe von einfacher Sprache, gruppiert in spezifischen Sätzen und Syntax, Backend-Systeme zu programmieren, um mathematische und formelhafte Aufgaben auszuführen. Warum ist es heute noch aktuell? Ganz einfach: Sie ist sehr gut in ihrem Job. In gewisser Weise ist sie ein Teil der Computerstruktur für viele Mainframe- und Kernsysteme in so unterschiedlichen Branchen wie dem Finanzsektor und der Fertigung geworden.

Im Laufe der Jahre wurde COBOL immer wieder aktualisiert, vor allem im Jahr 2002, als es in eine objektorientierte Sprache umgewandelt wurde, um die Programmierung neuer Anwendungen etwas flüssiger zu gestalten. Aber im Großen und Ganzen ist COBOL heute noch das, was es damals war: ein unbesungener Held und ein Arbeitspferd unter den Programmiersprachen, das im Backend arbeitet und viele moderne Mainframe-Anwendungen unterstützt.

Wie sicher ist COBOL?

Leider gab es bei der Entwicklung von COBOL noch nicht viele Sicherheitsüberlegungen. Zum Beispiel haben viele COBOL-Anwendungen ein Passwortprogramm, das sie schützt, aber sie sind fast nie gegen Dinge wie Brute-Force-Schutz gehärtet, um ein Knacken zu verhindern. In Verbindung mit der Tatsache, dass viele moderne Sicherheitstools, die den Netzwerkverkehr überwachen, nicht wissen, wie sie mit Funktionen innerhalb von Programmen, die in Geschäftssprachen wie COBOL geschrieben wurden, umgehen oder diese auswerten können, haben Sie ein echtes Problem, das nur darauf wartet, zu passieren. Nicht wenige moderne Einbrüche waren erfolgreich, weil es an einer Sicherheitsaufsicht für Systeme mit klassischen Computersprachen mangelte. Im Jahr 2015 wurden die Daten von mehr als vier Millionen US-Bundesangestellten offengelegt, als das Office of Personnel Management (OPM) gehackt wurde, wobei die Schuld auf die Verwendung von COBOL zurückgeführt wurde, da man nicht in der Lage war, moderne Sicherheitsmaßnahmen für ein solch archaisches System zu implementieren.

Vor Jahren wurde die Sicherheit von einer Armee von Programmierern gewährleistet, die COBOL und andere heiße Sprachen der Zeit kannten. Damals, in den 1960er Jahren, war COBOL so etwas wie das heutige Java oder .Net, und diejenigen, die sich damit auskannten, waren die Rockstars ihrer Abteilungen. Im Jahr 2019 sind diese Leute wahrscheinlich längst im Ruhestand, auch wenn die Systeme, die sie geschützt haben, es nicht sind.

Erweiterung von COBOLs Verteidigungslinien

Nicht wenige dieser sogenannten Graubärte wurden als Auftragnehmer in ihre Organisationen zurückgebracht, um dieselben Großrechner zu verteidigen, an denen sie zuvor gearbeitet hatten. An mehr als nur ein paar Orten existierten sie als eine Art Anomalie: eine geheime Kabale alternder Zauberer in irgendeiner hinteren Ecke des Büros, deren seltsame Kleidung (breite Krawatten und dreiteilige Anzüge) und seltsam höfliche Umgangsformen nicht ganz zu all den modernen Hipstern mit Skinny Jeans und Dutt passten. Dennoch waren sie absolut notwendig, denn nur wenige moderne Programmierer schleudern Code in COBOL und anderen alten Sprachen. Leider schwinden auch diese letzten Wächter der Zauberer dahin, geben schließlich den Geist auf und ziehen nach Boca Raton, um einen echten Ruhestand zu genießen.

Daher gibt es einen dringenden Bedarf an Leuten, die ältere Sprachen und die darin enthaltenen Sicherheitslücken verstehen. Selbst wenn jüngere Leute nicht wissen, wie man Code in klassischen Sprachen schreibt, sollten sie zumindest verstehen, wie sie funktionieren und welche potenziellen Schwachstellen sie aufweisen. Denn während die COBOL-Entwicklung relativ statisch geblieben ist, haben sich die Bedrohungen für Netzwerke ständig weiterentwickelt. Der Versuch, uralte, vor sechzig Jahren programmierte Cybersicherheitstechniken wie die erwähnte COBOL-Passwortanwendung zur Verteidigung eines Mainframes gegen moderne Angreifer einzusetzen, gleicht dem Einsatz einer Phalanx von Speerträgern gegen ein Platoon von Space Marines - ohne ein hollywoodreifes Wunder wird es schlecht für die Typen mit den Speeren ausgehen.

Egal ob alt oder neu, es muss auch sicher sein.

Deshalb glauben wir an die Bedeutung eines fortgeschrittenen Trainingssystems, das eine breite Palette von Programmiersprachen und Frameworks abdeckt. Sehen Sie, eines der eklatanten Probleme mit vielen Sicherheitsschulungen ist, dass die Informationen einfach zu allgemein sind, oder schlimmer noch - völlig irrelevant für die tägliche Arbeit des Entwicklers, der daran teilnimmt. Einen halben Tag damit zu verbringen, etwas über Schwachstellen zu lernen, die nur für Java gelten, wird einem COBOL-Entwickler nicht helfen, sein System zu verstärken, und es verewigt nur die Idee von "Sicherheit" als eine Abhak-Übung, die man vergessen kann, sobald der obligatorische Kurs abgeschlossen ist. Ich möchte hinzufügen, dass die Schulung von jemandem in Java-Sicherheitsfehlern nicht immer für einen Java-Spring-Entwickler anwendbar ist. Sicheres Coding ist einfach in jeder Sprache anders, sogar bis zur Framework-Ebene.

In unserer Mission, alle Entwickler zu befähigen, Sicherheits-Superhelden zu werden, werden wir eine gültige Computersprache nicht übersehen, die immer noch bei einigen der weltweit am meisten angegriffenen und kritischen Einrichtungen im Einsatz ist. Bei der Erkundung unserer Plattform finden Sie moderne, praxisnahe Herausforderungen und Schulungen zu COBOL, die neben einigen der modernsten Programmiertools angeboten werden, die heute verfügbar sind, wie z. B. Googles Golang. Diese Flexibilität stellt sicher, dass das Training für den Einzelnen relevant und kontextbezogen ist, indem es seine Arbeitsumgebung für maximales Engagement und Effektivität nachahmt. Schließlich ist der Aufbau einer robusten Sicherheitskultur das A und O im Kampf gegen Cyber-Bedrohungen, daher sollte das Training praxisnah sein (und natürlich Spaß machen!).

Wir wollen, dass unsere Branche so weit kommt, dass es keine Rolle mehr spielt, ob Sicherheitsbedrohungen gegen Systeme mit veralteten Sprachen oder gegen die modernsten Mobilitäts-Apps gerichtet sind. Wir wollen, dass jeder Entwickler mit den besten Informationen über diese Schwachstellen, die Tools und Techniken, die von Angreifern verwendet werden, um sie auszunutzen, und wie man sie kaltblütig stoppen kann, ausgestattet ist. Wir werden im Angesicht von Cybersecurity-Bedrohungen niemals aufgeben oder nachgeben. Unabhängig davon, wie modern die Bedrohungen oder Schwachstellen sind oder wie lange sie zurückliegen, können Sie sich immer an Secure Code Warrior um zu lernen, wie man sie besiegen kann, jedes Mal.

PS: Denken Sie, dass eine alte Sprache der Anfälligkeit für SQL-Injection entgeht? Denken Sie anders. Versuchen Sie, eine solche in COBOL zu finden und zu beheben, und zwar jetzt.

Ursprünglich veröffentlicht in Informationszeitalter. Dies ist eine aktualisierte Version, die die Positionierung rund um Wind River Systems laufende Sicherheitsunterstützung für ihr Echtzeit-Betriebssystemprodukt VxWorks korrigiert.

Ein kürzlich veröffentlichter Bericht des britischen Huawei Cyber Security Evaluation Centre identifizierte große Sicherheitsprobleme innerhalb der Softwareentwicklungsprozesse von Huawei. Während sich ein Großteil der Nachrichten über diesen kritischen Bericht auf nicht behobene Probleme aus dem Vorjahr konzentriert, ist das gefährlichere und übersehene Problem der eindeutige Mangel an sicheren Codierungsrichtlinien und -praktiken, die von Huawei eingesetzt werden. Aber das ist ein Problem, das behoben werden kann.

Die Nachrichten für den chinesischen Telekommunikationsriesen Huawei werden immer schlechter. Während die Vereinigten Staaten das Unternehmen von zukünftigen Regierungsaufträgen ausgeschlossen haben, hat Großbritannien die Tatsache, dass viele der zugrundeliegenden Fehler in den Geräten und dem Code von Huawei behebbar sind, eher akzeptiert. Das Vereinigte Königreich richtete 2010 das Huawei Cyber Security Evaluation Centre (HCSEC) ein, um Sicherheitsprobleme in Huawei-Produkten zu bewerten und zu beheben und einen jährlichen Bericht darüber zu erstellen. Dieses Jahr war der Bericht jedoch besonders vernichtend.

Ein Großteil des Fokus auf den HCSEC-Bericht 2019 in den Nachrichten bezog sich auf die Tatsache, dass fast keine Sicherheitsmängel aus dem Vorjahr behoben wurden. Dazu gehört die Verwendung einer älteren Version des Echtzeit-Betriebssystems VxWorks von Wind River, die bald das Ende ihrer Lebensdauer erreichen wird. Huawei hat zwar versprochen, dieses Problem zu beheben (und sie erhalten laufenden Support von Wind River Systems), aber es bleibt eine Kernkomponente in einem Großteil der britischen Telekommunikationsinfrastruktur.

Ein kritischer Faktor, der von den meisten Mainstream-Medien übersehen worden zu sein scheint, besteht in einem möglicherweise grundlegend gestörten Prozess innerhalb der Entwicklung und des Einsatzes neuer Software und Hardware des Unternehmens. Der Bericht stellt "signifikante technische Probleme" mit der Art und Weise fest, wie Huawei seine internen Entwicklungsmethoden handhabt.

Schauen wir uns einige Beispiele für diese technischen Probleme an, die im Bericht beschrieben werden. Es muss gesagt werden, dass eines der besten Dinge, die Huawei getan hat, die Erstellung von Richtlinien zur sicheren Kodierung war, um seine Ingenieure und Programmierer bei der Bereitstellung von neuem Code zu unterstützen. Diese Richtlinien decken ein breites Spektrum an Best Practices ab, wie z. B. die Verwendung bekannter sicherer Versionen von Systemfunktionen und Prozessen aus vertrauenswürdigen Bibliotheken und auf keinen Fall Varianten mit bekannten Sicherheitslücken. Das ist in der Theorie eine tolle Sache, aber eine reale Auswertung eines Produktionssystems von Huawei in Großbritannien ergab, dass diese Richtlinien entweder nie an die Programmierer kommuniziert, von ihnen ignoriert oder einfach nicht durchgesetzt wurden.

Der Bericht untersuchte bestimmte Speicherverarbeitungsfunktionen in öffentlich zugänglichen Anwendungen, in diesem Fall eine Reihe von Message Boards, in denen Benutzer als Funktion des Programms aufgefordert wurden, Eingaben hinzuzufügen. Da Benutzereingabebereiche niemals als "vertrauenswürdig" behandelt werden sollten, wurde erwartet, dass diese Bereiche gemäß den internen Richtlinien von Huawei nur sicheren Code enthalten würden. Konkret untersuchten die Tester den direkten Aufruf der speicherverarbeitenden Funktionen memcpy(), strcpy() und sprintf() in diesen Produktionssystemen, die seit 1988 dafür bekannt sind, dass sie potenziell zu schweren Sicherheitsproblemen wie Pufferüberläufen führen können.

Schockierenderweise gab es 5.000 direkte Aufrufe von 17 bekannten sicheren memcpy()-Funktionen, aber auch 600 Verwendungen von 12 unsicheren Varianten. Bei den anderen Funktionen war es in etwa das gleiche Verhältnis. Es gab 1.400 sichere strcpy()-Aufrufe, aber auch 400 unsichere mit bekannten Schwachstellen. Und es wurden 2.000 sichere Verwendungen von sprintf() gefunden im Vergleich zu 200 unsicheren. Obwohl es gut ist, dass die meisten Verwendungen dieser Funktionen sicher waren, bleiben immer noch etwa 20% des gesamten Codes anfällig für bekannte Angriffe. Das ist eine riesige Angriffsfläche, die zudem nur die direkten Aufrufe der drei Speicherbehandlungsfunktionen berücksichtigt, nicht aber deren indirekte Verwendung über Funktionszeiger. Obwohl die Prüfer nur diese speziellen Funktionen betrachtet haben, ist es unwahrscheinlich, dass die drei ausgewählten Speicherbehandlungsfunktionen die einzigen mit Problemen sind.

Es ist zwar gut, dass Huawei einen Best-Practice-Leitfaden für seine Programmierer erstellt hat, aber es ist klar, dass noch mehr getan werden muss. Es ist ein Schritt, die Sicherheitserwartungen zu umreißen, aber sie sind nur dann effektiv, wenn diese Richtlinien aktiv befolgt werden und die Entwicklergruppe damit vertraut ist. Huawei könnte erhebliche Fortschritte bei der Verbesserung der Sicherheit machen, wenn sie sich verpflichten würden, ihre Programmierer effektiv zu schulen und nicht nur die Grundlagen zur Befolgung der internen Huawei-Richtlinien zu überfliegen. Sie müssen den zusätzlichen Schritt wagen und zeigen, wie man generell sicherer programmiert. Die Programmierer müssen ausreichend in guten (sicheren) und schlechten (unsicheren) Codierungsmustern geschult werden und die Verantwortung erhalten, das zu praktizieren, was ihr Unternehmen predigt, und zwar jedes Mal.

Viele der spezifischen Codierungsprobleme, die im HCSEC-Bericht beschrieben werden, werden als Teil der Plattform angesprochen und durchgesetzt. Secure Code Warrior Plattform angesprochen und durchgesetzt, die Programmierer und Cybersecurity-Teams darin schult, stets sicheren Code einzusetzen und zu pflegen. Konzepte wie niemals auf Benutzereingaben zu vertrauen, immer Funktionen aus etablierten Bibliotheken zu ziehen, alle Eingaben zu bereinigen, bevor sie an einen Server weitergegeben werden und viele andere sichere Kodierungspraktiken werden innerhalb der Plattform ständig demonstriert. Wir gehen auch auf sehr spezifische Schwachstellen ein und zeigen Schritt für Schritt, wie man sie vermeiden und entschärfen kann.

Zusätzlich zu geschicktem Training könnten Unternehmen wie Huawei DevSecOps-Lösungen nutzen. Es fügt Echtzeit-Coaching direkt in der IDE hinzu und verwendet sichere Coding-Rezepte, die an die Sicherheitsrichtlinien des Unternehmens angepasst sind und als Sous-Chef des Entwicklers in der Coding-"Küche" fungieren, während sie ihren Code schreiben. Ein solcher Ansatz könnte Huawei-Programmierern aller Qualifikationsstufen dabei helfen, besseren Code zu schreiben und potenzielle Schwachstellen zu erkennen, während gleichzeitig die Sicherheitsexperten von Huawei ein "Kochbuch" mit Rezepten erstellen können, die ihre Richtlinien einhalten und bei der Ausführung von Befehlen helfen.

Eine zentrale Lehre aus den Problemen von Huawei sollte sein, dass die Erstellung von Richtlinien für sichere Kodierung bedeutungslos ist, wenn die Programmierer sie nicht kennen oder einfach nicht wissen, wie sie gute Kodierungspraktiken befolgen sollen. In diesem Fall entpuppten sich die internen Best-Practices-Richtlinien als Huawei-eigenes zhilaohu; das, was der Westeneinen "Papiertiger" nennen würde. Es war ein Dokument mit viel Stil, aber ohne Substanz. Um ihm echten Biss zu verleihen, wären die richtigen praktischen Tools und ein tatsächliches Schulungsprogramm erforderlich, eines, das einen praktischen Ansatz verfolgt und kontinuierliches Wissen und Fähigkeiten aufbaut.