So bleiben Sie 2023 in Sachen Sicherheit auf dem Laufenden

Sicherheit und Leistung sind die Eckpfeiler für jedes Projekt, jede Website, App und Komponente, die Sie entwickeln. Aber in dieser sich ständig verändernden Landschaft kann es schwierig sein, den Überblick über grundlegende Best Practices zu behalten und gleichzeitig innovativ zu sein.

Erfahren Sie in diesem Gespräch von Top-Technologen, wie sie im Jahr 2023 in Sachen Sicherheit und Leistung den Überblick behalten.

Lautsprecher:

• Ramadass Prabhakar, SVP und Chief Technology Officer bei WP Engine
• Lawrence Edmondson, CTO bei Barbarian
• Sergi Isasi, VP Product, Anwendungsleistung bei Cloudflare
• Tim Nash, WordPress-Sicherheitsberater bei timnash.co.uk
• Jimmy Squires, CTO bei space150

Transkript:

RAMADASS: Hallo zusammen. Willkommen zur vierten Ausgabe von Decode. Es war wunderbar, jedes Jahr den Zuwachs an Teilnehmern zu sehen. In den letzten Jahren hat sich die Sicherheitslandschaft in der gesamten Branche erheblich verändert. Wir haben regelmäßige Nachrichtenbulletins zu Sicherheitsverletzungen und Sicherheit gesehen, da ein Thema häufig in Diskussionen mit Kunden und Entwicklern gleichermaßen auftaucht. Deshalb haben wir heute eine fabelhafte Gruppe von Branchenexperten zusammengestellt, die sich leidenschaftlich für Sicherheit einsetzen und hier sind, um unsere Fragen zu beantworten und ihre Erkenntnisse mit uns zu teilen. Beginnen wir also mit einer kurzen Vorstellung unserer Diskussionsteilnehmer. Lawrence, rüber zu dir.

LAWRENCE EDMONDSON: Vielen Dank, dass Sie uns haben. Lawrence Edmondson hier, CTO von Barbarian. Barbarian ist eine Full-Service-Digitalagentur. Wir befinden uns in New York.

Ramadass: Danke, Lawrence. Zu dir, Sergi.

SERGI ISASI: Danke. Ich bin Produkt-VP bei Cloudflare. Cloudflare, wir entwickeln Produkte, die alles, was unsere Kunden und Partner, wie WPE, sicherer und schneller mit dem Internet verbinden, und ich bin in San Francisco.

MODERATOR: Danke, Sergi. Und Tim, rüber zu dir.

TIM NASH: Ich bin ein WordPress-Sicherheitsberater hier in Großbritannien. Und ich verbringe im Grunde mein Leben damit, Entwickler zu erschrecken.

MODERATOR: Danke. Und Jimmy.

JIMMY SQUIRES: Ja, danke. Ich bin bei Space 150, ebenfalls eine Full-Service-Digitalagentur aus Minneapolis und dort CTO.

MODERATOR: Vielen Dank, dass Sie sich bereit erklärt haben, heute an unserem Panel teilzunehmen. Daher möchte ich uns damit beginnen, über etwas Einzigartiges zu sprechen, das Sie heute in Ihrer Organisation oder in Ihren Teams im Bereich Sicherheit tun. Fangen wir also vielleicht mit Sergi an.

SERGI ISASI: Ja, ich werde Tims Intro spielen, wo er Entwicklern Angst macht. Wir versuchen bei Cloudflare unter anderem, unseren Kunden mehr Einblick in ihren Datenverkehr zu geben und den Betriebsaufwand zu verringern. Wenn Sie also in der Vergangenheit herausfinden wollten, was Ihr Netzwerk beeinträchtigen könnte, welche Angriffe Sie möglicherweise sehen, haben Sie eine WAF bereitgestellt, sie in den Protokollmodus versetzt und dann einen Sicherheitsanalysten beauftragt, sich die Protokolle anzusehen und sehen, was es erkannt hat. Und dafür gibt es heutzutage einfach viel weniger Ressourcen.

Daher konzentrieren wir uns in diesem Jahr darauf, unseren Kunden Einblicke in die Angriffe zu geben, die wir auf sie sehen, auch wenn sie nicht das Produkt verwenden, das diesen Angriff heute verhindern würde. So wissen sie, ob ihre Anwendung angegriffen wird oder allgemein in gutem Zustand ist. Und das ist unser Fokus für den Rest des Jahres, indem wir alle unsere Sicherheitsprodukte vorstellen und unsere Kunden wissen lassen, was möglicherweise oder tatsächlich in ihrem Netzwerk passiert und ob sie es blockieren möchten oder nicht.

MODERATOR: Wunderbar. Das klingt wirklich sehr stark. Ich freue mich darauf, mehr darüber zu hören. Also Tim, was ist mit dir?

TIM NASH: Ich arbeite also mit vielen verschiedenen Kunden, sowohl Agenturen, aber auch kleineren individuellen Websites. Und ich mache viele Code-Reviews und Site-Reviews. Und bis zu diesem Jahr habe ich keine Zunahme von Menschen gesehen, die sich tatsächlich so sehr darum kümmern, dass die Menschen ziemlich glücklich sind, eine Bewertung zu erhalten und einfach die Arbeit zu tun, die Sie ihnen sagen. Wenn Sie ihnen also eine Reihe von Empfehlungen geben, halten sie sich einfach daran. Aber wenn ich im nächsten Jahr wieder auf die Seite komme, gebe ich ihnen einfach einen weiteren Haufen Empfehlungen. Ich habe also in diesem letzten Jahr eine Veränderung gesehen, bei der sich die Leute tatsächlich genug darum kümmern, Fragen zu stellen. Und so wurden für mich Code-Audits in den großen, langen Zeile 6, 4, 2 dieser Datei weggeworfen, blah, muss so gemacht werden.

Ich habe all das losgeworden und habe wirklich begonnen, mich auf Bildung zu konzentrieren und habe erkannt, dass, um ehrlich zu sein, die meisten Menschen nicht sagen wollen, dass Sie diese Linie reparieren müssen, aber um gesagt zu bekommen, hier ist, wie man es repariert jede Zeile, die da entlang ist. Für mich lag die große Veränderung und der große Fokuswechsel also auf Bildung. Und das ist etwas, das branchenweit gilt. Ich denke, dieses Jahr sprechen immer mehr Leute über Sicherheit als letztes Jahr und immer mehr Leute aus den Vorjahren.

MODERATOR: Nein, das ist wunderbar. Ich mag diesen Fokus wirklich, sich von der Gabe des Fisches auf das Lehren zu verlagern, wie man den Fisch fängt. Das ist also wirklich–

TIM NASH: Ich habe versucht, diese Analogie um jeden Preis zu vermeiden, weil sie Klischee ist.

MODERATOR: Danke.

TIM NASH: einfach gut gemacht.

MODERATOR: In Ordnung, Jimmy.

JIMMY SQUIRES: Ja, ich denke, es gibt so viel, dass ich mich entschieden habe, mich auf eine wirklich bestimmte Sache zu konzentrieren, um auf diese Antwort zu sprechen. Und das schränkt Ihren Spielraum wirklich ein, wenn Sie es mit API-Token und -Zugriffen zu tun haben. Ich denke, die Verletzung des Heroku-GitHub-Repositorys im letzten Jahr war eine wirklich gute Erinnerung daran, dass Sie nur über so viele Dinge die Kontrolle haben. Wenn wir also mit unseren Entwicklern zusammenarbeiten, erinnern wir sie an die Bedeutung dieser bereichsbezogenen Zugriffsrichtlinie auf jeder Plattform oder jedem System, mit dem Sie arbeiten. Oft möchte ein Entwickler schon früh in der Entwicklung einen ziemlich breiten offenen Zugriff, nur um es einfacher zu machen. Und manchmal werden diese Dinge, die wir wahrscheinlich – alle schämen uns zuzugeben – nicht auf das Niveau heruntergezogen, das sie vor der Produktion haben sollten. Beginnen Sie also frühzeitig, wenn Sie diese Sicherheitsbereiche berücksichtigen.

MODERATOR: Danke, Jimmy. Und Lawrence, ich weiß, dass du auch viel mit Entwicklern arbeitest. Also, wonach suchen Sie alle an dieser Front?

LAWRENCE EDMONDSON: Ja, sicher. Nur um auf dem aufzubauen, was Jimmy gesagt hat, wir arbeiten natürlich beide in der Werbung. Ich denke also, dass wir viele der gleichen Herausforderungen sehen, wenn Sie in der Werbung arbeiten, verglichen mit der Arbeit in einem Produktumfeld. Für uns berühren wir viele verschiedene Technologien, viele verschiedene Tech-Stacks. Wir müssen technisch agnostisch sein. Was wir also sehen, ist, dass Verbraucher jetzt auf vielfältige Weise über mobile und soziale Netzwerke interagieren. Vor einigen Jahren war der Desktop das primäre Mittel für den Zugriff auf Websites und Inhalte. Jetzt ist es komplett umgedreht. Es ging von Desktop zu Mobile zu jetzt Social.

Daher müssen Ihre API-Schichten und Ihre Anwendungsschichten auf eine Weise gesperrt werden, die mit ein wenig gesunder Paranoia verbunden ist. Was wir also sehen, ist, dass das Angriffsspektrum wächst, also suchen wir ständig nach neuen Wegen, DevOps dazu zu bringen, wie Programmierer zu denken, damit sie die möglichen Arten von Angriffen verstehen. Das ist es also, was wir heute tun.

MODERATOR: Vielen Dank dafür. Und Sie haben erwähnt, wie der Angriffsvektor zunimmt. Und das ist etwas, was wir hier bei WP Engine haben und uns mehr damit beschäftigt haben, wie Sie einen Defense-in-Depth-Mechanismus einführen. Vertrauen Sie also nicht darauf, dass eine Schicht sicher ist. Und wie integrieren Sie das in die Art und Weise, wie Sie codieren und Software schreiben? Also danke dafür. Während Sie alle über den sich ändernden Trend gesprochen haben, der sich dort abspielt, Verstöße, die im vergangenen Jahr aufgetreten sind. Wenn Sie also auf das Jahr 2023 blicken, was sind einige der wichtigsten Themen oder Bedrohungen, denen Sie alle Aufmerksamkeit schenken? Und vielleicht, Sergi, kannst du uns anfangen. Ja.

SERGI ISASI: Sicher. Und das wird albern klingen, weil es 2023 ist und ich das Wort DDOS sagen werde, aber es ist immer noch eine Sache. Und es war wirklich eine interessante Veränderung in den letzten neun, zwölf Monaten in der DDOS-Welt. Volumetric ist heutzutage nicht wirklich ein DDOS-Vektor. Es gibt viel weniger Reflexion. Und aus der Perspektive eines Bedrohungsakteurs ist es einfacher, ein DDOS zu starten, weil Sie viele handelsübliche Tools haben, richtig? Wir sind fast wieder in den Tagen der Skript-TD, aber Sie müssen auch viel weniger kompromittierte Systeme angreifen. Wenn Sie also versuchen, nachzudenken, gibt es nicht viele Infrastrukturen, die von jemandem verwaltet werden, der sein System möglicherweise nicht gepatcht hat. Sie können also ein Paket nehmen und es auf 10 umstellen. Das ist nicht mehr wirklich wichtig.

Sie wechseln also zu Layer 7. Und Layer 7 ist teurer in der Einführung, da Sie viel CPU dafür benötigen, aber es ist auch viel teurer, es zu entschärfen. Wenn Sie also eine Art DDOS-Schutzsystem haben, müssen Sie die Verbindung tatsächlich akzeptieren, untersuchen und dann damit beginnen, sie zu löschen, im Gegensatz zu etwas, das Sie auf einer niedrigeren Ebene löschen könnten. Was wir gefunden haben und wir haben den größten gemeldeten Layer-7-DDOS erst im letzten Monat gemildert. Das große Thema bei diesen Angriffen sind leistungsfähigere Geräte.

Wenn Sie also an all die Dinge denken, die wir heutzutage zu Hause angeschlossen haben, ist der Prozessor dieses Geräts erheblich besser als noch vor drei oder vier Jahren. Ihre Kamera kann also viel mehr. Es hat also eine kräftigere CPU, selbst Ihr Router ist eigentlich eine ziemlich starke Maschine. Und jede Kompromittierung dieser Geräte kann einen großen, großen Angriff ermöglichen, zumal Sie, wenn Sie eines kompromittieren, jetzt im Grunde alle verbundenen Geräte kompromittieren.

Die andere Sache, über die wir heutzutage ein wenig sprechen, aber etwas leiser ist, ist, dass wir von kompromittierten Hardwaregeräten zu kompromittierten Konten bei Cloud-Diensten übergegangen sind. Cloud-Dienste haben praktisch unbegrenzte CPU. Wenn ich also Zugriff auf eine Reihe von Einzelpersonen oder Firmenkonten bekomme und in diesem Cloud-System alles drehen kann, was ich will, kann ich dann einen extrem großen Angriff starten. Und das sehen wir bei den rekordverdächtigen Angriffen. Also ja, 2023, immer noch DDOS, immer noch ein Ding, aber jetzt auf Schicht 7 gegenüber den unteren Schichten.

MODERATOR: Danke. Das ist beängstigend, aber gleichzeitig denke ich, dass es darauf hindeutet, wie wir unsere Sicherheitsprotokolle weiter verbessern und der Fokusbereich weiter wächst. Ich weiß, Lawrence, Sie und ich haben uns in der Vergangenheit über KI sowohl als Boom als auch als Bedrohung unterhalten. Ich würde gerne einige Ihrer Gedanken zur generativen KI hören und wie sich dies Ihrer Meinung nach tatsächlich auf die Sicherheitsoberfläche im Jahr 2023 auswirkt.

LAWRENCE EDMONDSON: Ich bin also sehr aufgeregt, sehr optimistisch in Bezug auf KI. Wir sind bei Barbarian, aber gleichzeitig ist es sehr beängstigend. Das Potenzial, dass so etwas wie ein chatGPT auf böswillige Weise verwendet wird. So könnten Sie beispielsweise Ihren Code von Chat GPT kommentieren lassen. Und es macht tatsächlich einen ziemlich anständigen Job, je nachdem, welche Sprache und wie chaotisch Ihr Code ist, es macht einen ziemlich guten Job. Ich denke, das nächste, was wir sehen werden, ist für Chat GPT – und dies könnte bereits im Gange sein, weil Chat GPT dies jeden Tag tut. Wie heute habe ich gerade gesehen, dass es in Slack antworten und Antworten in Slack finden kann.

Was die Sicherheit anbelangt, denke ich, dass Chat GPT als nächstes Exploits finden und den Code tatsächlich schreiben muss – bösartiger Code, um die gefundenen Schwachstellen wirklich auszunutzen. Wir sehen das also, besonders das Potenzial dafür im Gedächtnis. Speicherangriffe hinterlassen also nicht immer eine Signatur. Herkömmliche Viren und Virenscanner arbeiten also daran, nach Signaturen eines Angriffs zu suchen. Bei Speicherangriffen greifen Sie die Anwendung an. Sie machen so etwas wie einen Pufferüberlauf. Sie möchten die Anwendung zur Laufzeit kompromittieren. Ich denke, dass Chat GPT dazu bereit ist. Und ich denke, es ist nur eine Frage der Zeit, bis wir den ersten groß angelegten ChatGPT-Exploit sehen.

TIM NASH: Wie stellen Sie sich das konkret vor? Denn offensichtlich ist ChatGPT im Kern nur eine Reihe von API-Anforderungen an einen Server. Und Sie senden eine Anfrage, die besagt, hey, generieren Sie mir bösartigen Code. Es gibt es zurück. Ich meine, es gibt viele Leute, die bereits bösartigen Code generieren. Wie würden Sie das dann schlimmer machen als den bereits vorhandenen Schadcode?

LAWRENCE EDMONDSON: Das ist also genau das Richtige. Es gibt bereits ein großes Repository, aus dem Sie lernen können. Was ChatGPT also tut, sieht es tatsächlich aus – Sie müssen das Modell trainieren. Im Laufe der Zeit trainieren Ingenieure das Modell also, um zu erkennen, wenn jemand dies sagt, ist dies tatsächlich das, was er meint. Also Kontext verstehen. Es ist also genau das, aber auf eine andere Art und Weise. Es trainiert das Modell, um tatsächlich Code zu schreiben und was er tatsächlich bedeutet. Und einige Sprachen sind sehr einfach. Also PHP, ziemlich einfach, Code in PHP zu schreiben. Diese interpretierten Sprachen sind viel einfacher. Es ist viel chaotischer, aber im Vergleich zu etwas wie Java, das kompiliert werden muss, wissen Sie, was ich meine?

Ich denke, ein einfacher Weg, dies zu tun, wäre, ein Modell auf der Grundlage von chatGPT 3 zu erstellen, auf das Sie es tatsächlich trainieren – Sie kommen durch das Syntax-Zeug, Sie kommen durch alle grundlegenden Informatik-Dinge und dann nehmen Sie es einen Schritt nach oben und gehen Sie, OK, diese NPM-Pakete haben diese Exploits. Suchen Sie danach und finden Sie einen Weg, tatsächlich – sie haben diese Schwachstellen, es tut mir leid, und suchen Sie nach einer Möglichkeit, diese Schwachstellen auszunutzen. Ich garantiere es, wir sind nicht allzu weit davon entfernt, so etwas zu sehen.

MODERATOR: Danke, Lawrence. Ich denke, es ist ein sehr aufstrebender Bereich. Was in diesem Bereich interessant ist, ist, dass KI im Allgemeinen beides hat, wofür Sie es nutzen können, ob es darum geht, diese Signaturen tatsächlich zu verwenden, um zu verhindern, und daraus zu lernen, um zu sehen, wie Sie uns daran hindern können Schreiben von schlechtem oder anfälligem Code. Und zur gleichen Zeit, genau wie wir gesehen haben, dass die Leute darüber sprechen, hey, ich habe mein erstes Plug-in in fünf Minuten mit Chat GPT geschrieben, denke ich – ja, es geht eher darum, dass es den Leuten ermöglicht, ein wenig Malware zu erstellen Schneller? Aber ich denke, es hat beide Aspekte.

Es geht mehr darum, wie Sie weiterhin eines dieser Tools nutzen, um beim Schreiben von Code einfach besser zu werden, aber sichereren Code zu schreiben. Und ich weiß, Tim, das ist ein Bereich deiner Leidenschaft. Möchten Sie etwas mehr darüber sprechen, wie sich Secure Code Ihrer Meinung nach im Jahr 2023 entwickelt und was Sie in diesem Bereich tun?

TIM NASH: Nun, ich meine, Chat GPT ist in vielerlei Hinsicht ein gutes Beispiel dafür. Wenn ich an einen Angriffsvektor dachte, um ehrlich zu sein, dachte ich nicht daran, dass er Massenscans durchführt und ihn als schlechten Schauspieler mit vielen Dingen füttert. Ich dachte an den durchschnittlichen Codeentwickler, der versuchte, Zeit zu sparen und Dinge in Chat GPT einfütterte und wieder wegwarf und nicht unbedingt den gesamten Code, der geschrieben und produziert wurde, vollständig verstand und keine Tests geschrieben hatte geh damit. Das ist nur eine schnelle Sache, es ist nur ein schnelles Skript, es ist alles in Ordnung. Es kommt in die Produktion, es ist nicht in Ordnung und alles brennt.

Nun, das ist genau das Gleiche wie etwas, das jeder Entwickler jeden Tag tut, unabhängig davon. Chat GPT ändert das nicht, aber es ermöglicht es etwas einfacher. Es gibt – es gibt weniger Barrieren.

SERGI ISASI: Ja, also ist es nicht ganz dasselbe wie das Kopieren und Einfügen von Stack Overflow, worauf du dich, glaube ich, beziehst, Tim, was im Grunde alles ist, was ich für Code mache. Aber ich denke, es ist auf jeden Fall eine Effizienzsteigerung, sowohl im Positiven als auch im Negativen. Aber ich denke, es ermöglicht subtilere Änderungen und eine schnellere Ausnutzung von etwas, das mehr signaturbasierte Engines nicht wirklich einholen können. Wenn Sie also eine Erkennung durchführen, müssen Sie ein System haben, das sagt, ob dies etwas ähnelt, das ich in der Vergangenheit gesehen habe, im Gegensatz zu etwas, das ich in der Vergangenheit gesehen habe. Und das ist auf der Erkennungsseite auch wahrscheinlich am besten mit ML oder KI oder wie auch immer Sie es nennen wollen.

Wir haben das mit automatisiertem Datenverkehr auf Bots im Grunde gelernt. Der beste Weg, um zu lernen, wie sie die signaturbasierte Erkennung umgehen, ist ML. Aber Sie bewegen sich jetzt von, ich weiß absolut, dass das schlecht ist, zu, nun, es ist wahrscheinlich automatisiert oder sieht wahrscheinlich aus wie eine Signatur, die ich zuvor gesehen habe, aber keine genaue Übereinstimmung.

MODERATOR: Wunderbar. Danke schön. Danke, Sergi und Tim für diesen zusätzlichen Kontext. Unter unseren Teilnehmern haben wir also viele Entwickler und Agenturen, die heute hier anwesend sind. Und viele Leute denken darüber nach, Best Practices zu etablieren, zumal sich die Szenarien in Bezug auf Bedrohungsvektoren ändern. Was sind also einige Best Practices, die Sie empfehlen würden, wenn Sie eine Website, eine App oder eine Plattform erstellen oder gerade, wenn Sie mit einem neuen Projekt beginnen? Auf welche Dinge sollten die Leute also achten?

SERGI ISASI: Damit kann ich also anfangen. Es wäre mehr auf der Betriebsseite als auf der Entwicklungsseite. Ich denke, eines der Dinge, die wir hier predigen, ist, dass wir davon ausgehen, dass etwas Schlimmes passieren wird. Es kommt also ein Durchbruch, man kann sich nicht einfach davon überraschen lassen. Wahrscheinlich wird es irgendwann passieren. Und unser Schlüssel – also erstens, erstellen Sie ein Runbook dafür. Wenn es also passiert, wissen Sie, welche Personen Sie kontaktieren müssen und wie Ihre Reaktion aussehen wird, sowohl von der Erkennung als auch von der Reaktion, aber auch von der Kommunikation mit Ihren Kunden, wenn sie davon betroffen sind. Und an diesem Ende ist das, was wir bei Cloudflare meiner Meinung nach sehr gut machen und es war ein Teil unserer Marke, und ich denke, es hat uns sehr gut gedient, offen, offen und so kommunikativ wie möglich über alles zu sein das passierte.

Die Offenheit war sehr wichtig, um das Vertrauen der Kunden wiederherzustellen, wenn etwas passiert, sei es eine Softwareverletzung oder ein Fehler, den Sie in Bezug auf einen Vorfall gemacht haben. Sich dahinter zu verstecken ist nie der richtige Ruf.

MODERATOR: Ja.

JIMMY SQUIRES: Ich denke, wir haben noch etwas anderes – jetzt, wo alle offensichtlich remote arbeiten und besonders in den Entwicklungsteams, nimmt man sich zu Beginn eines Projekts tatsächlich die Zeit, um Whiteboarding und Architekturplanung durchzuführen. Es ist so einfach, direkt in die Anforderungen einzutauchen und Entwicklungsgeschichten zu schreiben, aber Zeit mit Ihren Kollegen zu verbringen, um herauszufordern, wie könnte dies ausgenutzt werden? Szenarien durchspielen. Wir planen viel Szenarios, was zu vielen guten Gesprächen darüber führt, wie wir verschiedene Teile der Anwendung abstützen wollen.

LAWRENCE EDMONDSON: Ich weiß nicht, ob es irgendjemand weiß, aber MPM ist tatsächlich das größte Repository für Shared – es ist ein einzelnes größtes Repository für Anwendungsbibliotheken, aber das bedeutet auch, dass es das größte Risiko darstellt. Wenn wir also NPM verwenden, wenn wir ein neues Projekt übernehmen, achten wir sehr darauf, sicherzustellen, dass wir uns die Schwachstellen ansehen, dass wir Versionen einschließen, die wir zum Prod pushen, bevor wir Wenn Sie ein Update durchführen, stellen wir sicher, dass es kompatibel, aber auch sehr sicher ist. Es gibt keine offenen Bedrohungen, weil wir gesehen haben, dass sich viele Schwachstellen durch NPM schleichen. Das ist also nur eine Sache, auf die Sie achten sollten.

TIM NASH: Ich denke, wir drehen alles herum.

JIMMY SQUIRES: Mach weiter, Tim.

TIM NASH: Ich denke, wir drehen das alles um die Idee herum, dass das Vertrauen in Entwicklungszyklen über Jahre hinweg wirklich vollständig gebrochen wird. Die Leute kommen erst jetzt dazu, es zu erkennen. Und wenn Sie beispielsweise ein PHP-Entwickler sind, der in WordPress arbeitet, sitzen Sie da und rufen Aktionen und Filter auf, aber Sie sollten diesen Aktionen und Filtern nicht vertrauen. Alle eingehenden Daten sollten Sie validieren, Sie sollten sie überprüfen. Es sollte desinfiziert werden. Aber wenn es aus der Datenbank kommt, sollten Sie ihm immer noch nicht vertrauen.

Auch wenn Sie diese Daten möglicherweise in die Datenbank eingegeben haben, sollten Sie den Daten, die herauskommen, nicht vertrauen. Wenn wir etwas an eine Bibliothek eines Drittanbieters weitergeben, sei es dieses NPM, dieses Composer-Paket oder nur ein anderes WordPress-Plugin, sobald es unsere Kontrolle verlässt, vertrauen wir ihm nicht mehr. Aber wenn es wieder hereinkommt, vertrauen wir ihm immer noch nicht, selbst wenn wir es überprüft haben. Und wenn Sie als Entwickler mit der Denkweise an den Start gehen, dass jedem Datenelement nicht vertraut werden sollte und dass es vollständig isoliert werden sollte und dass Sie an jedem bestimmten Punkt Sicherheitsüberprüfungen durchführen sollten, werden Sie auftauchen mit einem viel sichereren System. Sie könnten mit einem etwas langsameren System herauskommen. Sie könnten auf ein etwas frustrierenderes System stoßen, das viel mehr Tests erfordert, um sicherzustellen, dass das, was Sie tun, nicht tatsächlich mehr Probleme verursacht, als es hilft.

MODERATOR: Ja.

TIM NASH: Fügen Sie Komplikationen hinzu, aber am Ende haben Sie ein viel sichereres System. Und für die meisten Menschen ist es das, was sie wollen.

LAWRENCE EDMONDSON: Ja.

MODERATOR: Ja. Du hast absolut recht. Es geht darum, keinem anderen Codestück zu vertrauen, das durchkommt. Und zu dem, worüber Jimmy und Sergi gesprochen haben, geht es darum, einen Plan zu haben und aus einer Architekturperspektive oder aus einer betrieblichen Perspektive, aber all das in Ihre Gesamtpraxis einzubringen, egal ob es sich um sicherheitssichere Codierungsmechanismen handelt oder ob Sie ein Vorfall-Playbook haben. Also Tim, ich bin sehr daran interessiert, mehr von dir zu hören – du trainierst viel, du unterrichtest viel auf der ganzen Welt. Was sind einige häufige Fehler, die Sie sehen, wenn Leute anfangen, an Projekten zu arbeiten, oder Fehler, die Sie vielleicht gemacht haben, ich habe viele davon gemacht.

TIM NASH: Ich wollte sagen, ich bin mir ziemlich sicher, dass ich an jedem Fehler schuld bin, über den ich gleich sprechen werde. Und das Größte und Einfachste ist, ein netter Mensch zu sein. Die meisten Entwickler gehen von guter Absicht aus. Die meisten Leute gehen davon aus, dass Sie ihre Anwendung so verwenden werden, wie Sie ihre Anwendung geschrieben haben. Heutzutage schreiben wir oft keine Dokumentation, sodass der Benutzer überhaupt keine Ahnung hat, wie er die Anwendung verwenden soll, aber das ist ein anderes Problem. Ein schlechter Schauspieler kommt herein und nimmt jeden Fehler und geht, das ist kein Fehler, für einen schlechten Schauspieler ist das ein Feature. Das ist eine Gelegenheit. Es tut etwas, was der Entwickler nicht erwartet, daher gibt es einen möglichen Weg dorthin.

Und insgesamt sehen Sie etwas, das Sie immer wieder sehen, wenn Sie sagen, oh, schauen Sie, Sie haben eine Reihe von Komponententests. Oh toll. Aber Sie haben nur die positiven Dinge getestet, das Ergebnis, das Sie wollten. Sie haben nicht getestet, was passiert, wenn wir diese Grenzen überschreiten. Sie haben gerade getestet, ob das Ding nach den Wünschen Ihres Chefs funktioniert. Was Sie also wirklich haben, sind Akzeptanztests, dubiose Akzeptanztests. Und dann kommt es wieder auf alle Grundlagen an. Als Entwickler wird darauf verzichtet, den Dingen nicht zu vertrauen. Und wenn Sie insbesondere ein WordPress-Entwickler sind, hat WordPress tatsächlich einige wirklich gute Hilfsfunktionen, um all die Standard-Sicherheitsaufgaben zu erledigen, die wir von den Leuten verlangen.

Und es geht darum, sie zu erziehen und zu lernen, sie zu benutzen. Wenn ich Code-Reviews durchführe, sehe ich immer wieder die gleichen Probleme. Und wenn ich es einmal in einem Codestück sehe, sehe ich es 1.000 Mal in demselben Codesatz. Und es werden Dinge sein wie: „Ja, wir haben einfach zugelassen, dass irgendwelche alten Sachen auf der Seite erscheinen. Wir haben uns nicht die Mühe gemacht zu überprüfen, ob etwas drin war oder nicht. Ja, wir haben Sachen in die Datenbank geschrieben. Oh schau, es könnte wie eine SQL-Abfrage aussehen, vielleicht auch nicht.

All diese Dinge sind leicht zu beheben, und wir haben bereits die Tools zur Behebung bereitgestellt. Und der Grund, warum wir sie nicht reparieren, ist oft nicht einmal, dass die Leute nicht wissen, dass sie diese Dinge nicht zulassen sollten, wir werden einfach faul, wir erledigen die Dinge schnell, wir schnappen uns Code von Stack Overflow, Wir lassen Chat GPT Dinge für uns erledigen, wir überprüfen die Dinge nicht durch. Und viele Sicherheitsprobleme ergeben sich aus diesem Zustand, ich muss mich beeilen. Ich muss mich beeilen. Ich muss mich beeilen, ich muss das erledigen. Ich gehe weiter zum nächsten Ding, ich gehe weiter zum nächsten Ding.

Seltsamerweise geben viele Entwickler ihnen einfach die Zeit und den Raum und sagen, es ist in Ordnung, sich Zeit zu nehmen, um zu überprüfen, was Sie getan haben, damit Sie, wenn es schiefgeht – und in Fällen, in denen ich ins Spiel komme, Ich komme zurück und sage, nun, all diese Dinge und die Entwickler sehen verlegen aus. Sie gehen, ja, wir wissen das alles. Wir hatten einfach keine Zeit.

Also hoffen wir, den Leuten mehr Zeit zu geben und ihnen tatsächlich die Tools zu geben, die wir bereits haben, insbesondere innerhalb von WordPress. WordPress hat eine wirklich brillante Reihe von Hilfsfunktionen für die häufigsten Sicherheitsprobleme, die Sie in einem WordPress-Plugin oder -Design haben würden. Es geht also nur darum, diese zu lernen und dann die Zeit zu investieren, sie tatsächlich umzusetzen.

MODERATOR: Ja. Und das finde ich richtig mächtig, die Zeit investieren. In den meisten Fällen wissen Entwickler, was behoben werden muss. Also gib ihnen Zeit. Also ich mag diese Nachricht wirklich. Und Jimmy, ich weiß, dass Sie das in Ihren eigenen Arbeitsablauf in Ihrer Agentur eingebracht haben. Möchten Sie etwas mehr über die von Ihnen implementierten sicheren Workflow-Praktiken sprechen?

JIMMY SQUIRES: Ja, absolut. Und wirklich, es beginnt damit, etwas zu haben, von dem Sergi sagte, dass es einen Plan hat, tatsächlich Richtlinien und Standards zu haben, die Ihr Entwicklungsteam befolgen kann. Ich weiß, das klingt wahrscheinlich sehr einfach, aber ich habe viele Organisationen gesehen und von vielen Ingenieuren gehört, die wir im Laufe der Jahre eingestellt haben, dass es das nicht gibt. Am Arbeitsplatz, von dem sie kamen, gab es keine Organisation.

Was wir also gerne tun, ist, dass wir einen Standardsatz von Richtlinien haben, die alle unsere neuen Ingenieure von Anfang bis Ende durchlesen müssen. Es ist nicht so schwer, dass es nicht verbrauchbar ist. Wir halten es gerne in Markdown, also ist alles in einem Repository. Wir werden es wahrscheinlich irgendwann tatsächlich als Open Source veröffentlichen. Es gibt dort nichts, was wirklich proprietär ist, und dann ermutigen wir jeden, dazu beizutragen. Das ist eine Bitte an alle Ingenieure.

Also auch in unseren Richtlinien, bohren Sie Löcher hinein, wo wir etwas hinzufügen können, wo wir besser werden können, indem Sie das kontinuierlich erweitern. Aber Zeit damit zu verbringen, einige der grundlegenden Dinge wie OWASP, das ist eine wirklich alte Praxis, aber gehen Sie das mit Ihrer Anwendung durch, wenn Sie diese Dinge berücksichtigen. Es ist ungefähr das, was Tim gesagt hat, es bedeutet, sich wirklich die Zeit zu nehmen und es in Ordnung zu sein, sich die Zeit dafür zu nehmen. Ich wollte dem KI-Gespräch einen zusätzlichen Punkt hinzufügen. Das Gespräch mit einigen unserer Ingenieure letzte Woche hatte tatsächlich ein Ereignis. Das ist etwas, wofür wir Chat GPT verwenden, nämlich Unit-Tests. Nehmen Sie eine Funktion und untersuchen Sie sie auf interessante Weise. Wie können Sie so etwas wie Chat GPT nutzen, um einen Komponententest zu schreiben, bei dem Sie nicht der beste Autor dieses Komponententests sein werden, um Tims Punkt zu sagen. Hier denke ich, wo wir KI viel mehr präventiv einsetzen können.

LAWRENCE EDMONDSON: Ja. Was wir auf unserer Seite tun, ich denke, Checklisten und ein Playbook sind großartig. Wir verwenden automatisierte Tools wie SonarQube und haben wirklich Linting und solche Dinge, nur um die Qualität des Codes mit Linting zu erhöhen, aber wir verwenden SonarQube auch, um sicherzustellen, dass der Code sicherer ist, als wir suchen für Schwachstellen und ähnliches. Ich denke, dass es in einigen Sprachen einfacher ist als in anderen, Exploits zu finden, wie ich bereits erwähnt habe, nur wegen der Natur der Sprache. Und auch nur bei bestimmten Frameworks, bei denen die Qualität der Programmierer, die zu dieser Codebasis beitragen, normalerweise – wir sehen das normalerweise bei Open Source, wo es einfach so ist – viel Kopieren und Einfügen von Stack Overflow stattfindet, im Gegensatz zu Leuten, die tatsächlich studiert haben CS und wissen wirklich, was sie tun. Das ist also nur eine Sache, die ich gesehen habe.

TIM NASH: Ich denke, wir sollten darauf hinweisen, dass ich Stack OverFlow fast jeden Tag verwende, sicherlich für mich selbst. Und so sind wir alle schuldig. Es ist gut, darüber zu schimpfen, aber ich glaube nicht – ich meine, ich erinnere mich, als ich anfing zu programmieren. Ich bekam ein Magazin und tippte Code aus dem Magazin ein und drückte die Eingabetaste. Ich kann mir nicht vorstellen, dass das Web heute wirklich funktioniert, wenn wir immer noch dabei bleiben und keinen Stack Overflow oder ähnliches haben.

Sergi: Nein, es ist der Brandbeschleuniger. Und hoffentlich ist KI die nächste Stufe davon. Aber ja, es ist ein lustiges Meme.

MODERATOR: Danke. Also etwas verschieben. In der Branche gibt es eine Menge Dynamik rund um Headless und Headless-Implementierungen. Und wir haben heute auch in einigen unserer anderen Kanäle oder anderen Sitzungen gesehen, dass über Headless gesprochen wird. Als wir anfingen, mit Atlas bei WP Engine zu arbeiten, trafen wir uns mit vielen Entwicklern und Sicherheit war immer ein wichtiger Motivator. Wie sehen Sie die Sicherheit mit Headless? Und ich weiß, Jimmy, das ist ein Bereich, in dem Sie einige Projekte durchgeführt haben. Wir würden uns freuen, Ihre Meinung dazu zu erfahren.

JIMMY SQUIRES: Ja, wir arbeiten viel an Headless. Ich denke, fast alle unsere Projekte verfolgen derzeit wahrscheinlich einen Headless-Architekturansatz. Ich denke, ein paar Punkte möchte ich dazu sagen, da es um Sicherheit geht. Ich denke, der erste ist, dass Sie sich bei der Wahl einer Headless-Architektur am Anfang eher in das Open-Source-Lager versetzen. Und natürlich wird viel darüber diskutiert, was sicherer ist, Open Source oder Closed Source. Ich neige dazu, in das Lager der OSS-Projekte zu fallen, die von Natur aus sicherer sind. Sie wählen also Frameworks wie Next, WordPress, wo Sie eine riesige Community haben. Und das führt tendenziell zu mehr Sicherheit durch bloße Offenlegung.

Also ich denke das ist einer. Ich denke, das zweite ist so etwas wie Static Generation. Viele Websites und Produkte, die erstellt werden, benötigen also nicht die dynamische Natur eines großen, monolithischen Content-Management-Systems im herkömmlichen Sinne. Sie können so etwas wie Cloudflare nutzen und große Teile dieser Anwendung wirklich statisch generieren, wodurch Sie Ihren Fußabdruck für Vektoren und Exposition reduzieren. Wir sind also große Fans davon. Und dann bekommst du natürlich auch noch alle Performance-Vorteile. Das sind also nur ein paar Punkte, die ich zur Headless-Architektur ansprechen wollte. Aber aus Sicherheitsgründen gibt es noch viele weitere Gründe, warum es uns gefällt. Aber ich denke, das sind wahrscheinlich zwei der größten herausragenden Bereiche.

TIM NASH: Ich möchte mich einfach zurücklehnen und die Leute daran erinnern, dass da hinten immer noch ein Content-Management-System drin ist. Und das höre ich zu oft, Headless ist absolut sicher. Es ist wie, ja, aber diese exponierte WordPress-Instanz, die immer noch da ist, nur weil Sie sie nicht direkt von der Website aufrufen, ja, sie ist immer noch da auf admin.yoursite.com. Und Sie haben nicht – es gibt einen gewissen Glauben, dass, oh ja, nun, wir sind jetzt sicher, also müssen wir uns keine Sorgen machen, es auf dem neuesten Stand zu halten, weil es nicht die Website ist. Es ist wie, nein, nein, du brauchst immer noch all das Zeug, das du vorher gemacht hast, und jetzt haben wir auch die andere Seite.

Und ich meine, Headless ist ein großartiger Begriff, der für etwas steht, das es schon lange gibt und das viel Momentum bekommt, aber wir haben das gemacht, bevor WordPress eine REST-API hatte. Wir haben Inhalte von WordPress auf Dinge wie Jekyll verschoben, um zumindest eine statische Seite daraus zu machen. Und der ursprüngliche Grund dafür war, das WordPress-System oder Ihr Content-Management-System in Ihrem Netzwerk zu ändern. So könnten Sie es sperren und es vor dem großen, gruseligen Netz schützen.

Jetzt bekommen wir viele Hosting-Unternehmen, die Headless-Lösungen anbieten. And that infrastructure is now out in the cloud again. So we've sort of moved the big benefit for Headless. And we're slowly shifting it back into the public domain again, which seems like a very almost backwards move, but it's the only move for widespread adoption. So there's a balancing act we have there. But yeah, just a small little warning into the big space of keep the backend secure still. You can't just rely on it being–

TIM NASH: Just because something's got some HTML files at the front, the back end still needs to stay just as secure as before.

MODERATOR: Yeah, absolutely. I mean, Headless, by default, doesn't mean that everything is secure. It means that you have a different paradigm. And that's what I think I was interested in, looking at what practices that you bring in as you look at Headless infringers. So yeah, I think that's you're very apt in stating that you still have to secure both the CMS part, as well as the web part of it. So as we are wrapping up, what I would love to do is we have had a lot of good topics to talk about in here, but I would love to take like 10 seconds from each one of you to say that if there is one thing that our audience could do in these next two months after the end of the session, what would that be? What's your recommendation?

LAWRENCE EDMONDSON: I guess I'll start off. My recommendation would be very simple. Security should be everyone's business. I think a lot of times, security doesn't become a topic or consideration until there's a problem. If I were a developer, I would make sure that I am being very proactive in terms of taking the necessary steps. It's 2023, we shouldn't be storing anything in clear text.

Everything should be encrypted as much as you can. Use Hashicorp, encrypt your database and make sure that your keys are stored securely, or it's something that's not easily compromised. But that's what I would encourage folks to make sure that security is top of mind all the way throughout.

MODERATOR: Thank you, Lawrence. Sergi, what about you?

SERGIS ISASI: I would say get an inventory of what's exposed. Know what's on the internet and make sure that the proper– at least aware of what's there, if not fully protecting it.

MODERATOR: Thank you. And Jimmy?

JIMMY: Scenario planning. Take the time in your project to do the scenario planning and create those playbooks, both preventative and then reactive once something does happen, to Sergi's point earlier. What are your action steps for that? Take that time and the project will pay off dividends later.

MODERATOR: Wonderful. Danke schön. And Tim, bring us home.

TIM NASH: Oh, I want to reinforce what Lawrence said. Security is everybody's responsibility. Give people the time and space to actually do their jobs properly and you'll find that you will come out with a much more secure project.

MODERATOR: Thank you. Security is indeed everyone's responsibility. So thank you to our amazing panelists for taking the time today and also to everybody in the audience. Hope you enjoyed this session. Thank you and bye.