DE{CODE}: Schutz Ihrer WordPress-Sites inmitten einer Zunahme globaler Cyberangriffe

Schließen Sie sich Experten von WP Engine und Cloudflare an dieser sicherheitsspezifischen Sitzung an, in der erklärt wird, wie Sie Ihre Websites sperren können. Die Diskussion beleuchtet aktuelle Cyberangriffstrends zusammen mit konkreten Beispielen, wie WP Engine Ihre Websites schützt. Entwickler erhalten eine klare Checkliste mit Schritten, die sie zum Sichern ihrer Websites ergreifen müssen.

Sitzungsfolien

Vollständige Textabschrift

ERIC JONES : Willkommen bei DE{CODE} und vielen Dank für Ihre Teilnahme an einer vielversprechenden Breakout-Session. Mein Name ist Eric Jones und ich bin der VP of Corporate Marketing hier bei WP Engine. Ich könnte nicht aufgeregter sein, heute diese Diskussion zwischen Joe Sullivan, dem Chief Security Officer von Cloudflare, und Brent Stackhouse, dem Vice President of Security für WP Engine, zu moderieren, die zusammen über jahrzehntelange Erfahrung im Bereich Sicherheit verfügen.

Unsere Diskussion, Keeping Your WordPress Sites Safe Inmitten A Rise in Global Cybersecurity Attacks, könnte nicht aktueller sein, wenn man bedenkt, dass Cyber-Angriffe nicht nur auf dem Vormarsch sind, sondern auch Rekorde brechen. Joe, warum fangen wir nicht mit dir an? Ich würde gerne aus einer breiten Makroperspektive hören, welche Trends Sie in der Cybersicherheitslandschaft sehen.

JOE SULLIVAN : Sicher. Ich springe gerne ein. Danke, dass Sie mich zu diesem Gespräch eingeladen haben. Ich freue mich auch sehr darauf. Ich denke, es gibt derzeit zwei Megatrends in der Welt der Sicherheit. Nummer eins ist, dass es in den Augen der Welt viel wichtiger ist.

Bevor wir also zur technischen Seite und den tatsächlichen Herausforderungen kommen, denen wir tagein, tagaus gegenüberstehen, lohnt es sich, sich einen Moment Zeit zu nehmen, um sich anzusehen, wie sehr sich die Welt der Sicherheit entwickelt hat, seit Brent und ich in diesem Beruf begonnen haben, als Sie sagten, vor Jahrzehnten.

Sicherheit ist kein Team oder Konzept mehr, das in der Ecke einer Organisation sitzt. Es ist von zentraler Bedeutung für alles, was wir tun. CEOs werden zur Rechenschaft gezogen. Boards stellen harte Fragen. Risikokapitalgeber werden keinen Beitrag leisten, es sei denn, sie sehen das richtige Investitionsniveau.

Und was noch wichtiger ist, unsere Kunden und Verbraucher und gewerblichen Käufer unserer Produkte verlangen viel mehr von uns. Und das ist für mich der wichtigste Trend und warum wir dieses Gespräch führen. Es ist für jeden Entwickler in jedem Aspekt seiner Arbeit von Bedeutung.

Wenn wir uns also den tatsächlichen Ereignissen in der Welt der Sicherheit zuwenden, wird es nicht einfacher. Und die Herausforderungen kommen immer wieder auf uns zu. Wenn Sie auf die Schlagzeilen achten, haben Sie den Aufstieg von Ransomware erst in letzter Zeit miterlebt. Es ist wirklich beängstigend.

Ransomware hat das Spiel in Bezug auf die Sicherheit verändert, weil es vom Diebstahl einiger Daten oder der Offenlegung von etwas der Welt bis hin zur Schließung Ihres Unternehmens reichte. Und so wurde das gesamte Konzept der Bedeutung von Sicherheit durch dieses Risiko vergrößert, die Idee, dass wir morgens aufwachen und unsere Laptops nicht einschalten und unsere Website nicht zum Laufen bringen könnten. Das ist wirklich beängstigend.

Auch geopolitische Dinge beginnen sich wirklich auf uns alle auszuwirken. Die Situation in der Ukraine ist nicht in der physischen Welt enthalten. Es ist gerade stark im Cyber-Kontext. Und es schwappt über und wirkt sich auf den Rest von uns aus. Geopolitische Ereignisse, die sich in der physischen Welt ereignen, haben also technische Auswirkungen auf diejenigen von uns, die versuchen, Geschäfte im Internet zu betreiben.

Und ich denke, die dritte Sache, die ich aus technischer Sicht erwähnen möchte, ist, dass wir nicht in Welten unseres eigenen Codes leben. Wir leben in Welten, die eine Verschmelzung von Software und Code sind, die zusammenkommen, um eine Organisation darzustellen.

Und so verwenden wir im Sicherheitsbereich den Begriff Lieferkette, um über all diesen anderen Code und andere Anwendungen und alles zu sprechen, was Teil unserer Identität als Unternehmen wird. Als es beispielsweise kürzlich Berichte über die Kompromittierung von Okta gab, ging es nicht nur darum, ob Okta kompromittiert wurde. Es ging darum, ob mein Unternehmen und alle anderen Unternehmen, die Okta verwenden, kompromittiert sind.

Und meine Kunden interessierten sich nicht für Okta. Sie kümmerten sich um ihre Verwendung von uns, und welche Kontrollen hatten wir, um das Risiko einer Kompromittierung von Okta zu mindern? Es ist also gerade sehr viel los. Und es ist eine gute Zeit, dieses Gespräch zu führen.

ERIC JONES: Joe, nur als Folgefrage, wie denkst du über die Priorisierung all dieser spezifischen Herausforderungen, die du hast und die jede Sicherheitsorganisation hat?

JOE SULLIVAN: Sicher. Ich denke, das ist die ultimative Frage. Wenn wir ein unbegrenztes Budget und unbegrenzt viele Leute hätten, die die Arbeit erledigen könnten, könnten wir alles tun. Aber das ist nicht die Realität in irgendeiner Organisation in irgendeinem Stadium ihrer Entwicklung.

Wir sind also immer im Prozess der Priorisierung. Ich würde also sagen, dass Sie zuerst die Grundlagen priorisieren müssen. Es ist schockierend, wie viel Prozent der Kompromisse aus Fehlern in den Grundlagen resultieren.

Als Sicherheitsexperten gehen wir gerne auf Zero-Day- oder O-Day-Angriffe ein und schauen uns diese wirklich komplizierte Sache an. Aber in 90 % der Fälle stammen die Kompromittierungen von Phishing-E-Mails oder von jemandem, der sich dafür entscheidet, dasselbe Passwort zu verwenden, das er auf einer kompromittierten persönlichen Website verwendet hat, und die Multifaktor-Authentifizierung nicht aktiviert.

Oft haben wir tatsächlich die Werkzeuge, um die Grundlagen gut zu machen, aber wir nehmen uns nicht die Zeit, sie umzusetzen.

ERIC JONES: Ja, ich denke, Sie treffen auf einen entscheidenden Sicherheitspunkt, richtig? Dass es etwas ist, wofür wir alle verantwortlich sind. Es ist eine gemeinsame Verantwortung für die gesamte Organisation. Es lebt nicht nur innerhalb des Sicherheitsteams. Es lebt mit jedem einzelnen Mitarbeiter eines bestimmten Unternehmens.

Brent, zu dir gewandt, was ist aus WordPress-Perspektive gleich, was ist anders in WordPress und was sind einige der größten Schwachstellen, die du in der Landschaft siehst?

BRENT STACKHOUSE : Danke, Eric, und danke für die Einladung. Schätzen Sie die gemeinsame Zeit mit Joe. Er weiß eine Menge Sachen. Wir sind ein paar Mal um den Block gefahren. Das ist also faszinierend.

WordPress in vielerlei Hinsicht – die Nachrichten sind im Allgemeinen gut in dem Sinne, dass sich WordPress Core von allen Plugins und Themes und anderen Dingen im WordPress-Ökosystem unterscheidet. WordPress Core ist weiterhin robust und widerstandsfähig gegen häufige Angriffe.

WordPress selbst ist also eine gute, stabile und starke Plattform, mit der sich Kunden im Allgemeinen in nahezu jedem Kontext wohl fühlen sollten. Die Herausforderung liegt hauptsächlich auf der Plugin-Seite, wo wordpress.org oder diese Core-Entwickler im Allgemeinen nichts mit den meisten Plugins und Themes zu tun haben.

Und die Variabilität der Codequalität, ähnlich wie bei Apps, die Sie im Play Store von Google oder ähnlichem erhalten, diese werden nicht von Google geschrieben, wie ich gerade sagte. Sie werden nicht von WordPress geschrieben, diese Plugins und Themes, und es kann alles sein, von einem einzelnen Entwickler bis hin zu einem Team. Der Footprint dieser Plugins oder Themes kann sehr klein bis sehr groß sein. Sie können eine gute Vorgeschichte haben, Dinge schnell zu patchen oder nicht.

Und so kommt es darauf an. Da WordPress also immer beliebter wird und das Ökosystem immer beliebter wird, können Sie davon ausgehen, dass Angreifer ihre Bemühungen weiter verstärken werden, weil Angreifer dorthin gehen, wo das Geld ist, ähnlich wie aus dem Grund, warum Windows im Allgemeinen mehr Malware als Macs hat. Denn dort ist der Fußabdruck und dort ist das Geld.

WordPress ist also nicht anders, und da es immer beliebter wird, können Sie davon ausgehen, dass die Angreifer weiterhin das tun, was es tut. Die gute Nachricht ist, dass das Ökosystem im Vergleich zu dem Zeitpunkt, als ich vor vier Jahren mit der WP-Engine begonnen habe, weitgehend gesünder ist.

Plugin-Entwickler und Theme-Entwickler sind sich eher bewusst, dass sie Beiträge von Sicherheitsforschern oder anderen Personen erhalten, die Schwachstellen feststellen. Und die meisten von ihnen bauen diesen Muskel verantwortungsbewusst auf, damit sie Patches sehr, sehr schnell umdrehen können.

Also vieles besser als früher. Vor vier Jahren waren viele Entwickler überrascht, als Sicherheitslücken auftauchten, und sie waren nicht wirklich so schnell oder in der Lage, die Anforderungen ihrer Kunden in Bezug auf regelmäßiges Patchen zu erfüllen.

Wir alle als Technologiekonsumenten sind an den „Patch Tuesday“ oder unsere regelmäßigen Updates von Apple und so weiter gewöhnt. Wir sind also nicht überrascht über Sicherheitslücken. Wir wären jedoch sehr überrascht, wenn dieser Anbieter etwas nicht verantwortungsvoll und schnell patchen würde.

Das WordPress-Ökosystem ist also im Allgemeinen gesünder als vor vier Jahren, denke ich. Auch hier ist WordPress Core großartig, aber die Plugins und Themes halten meiner Meinung nach im Allgemeinen Schritt. Das ist also durchaus positiv.

ERIC JONES: Nur um auf etwas zu doppelklicken, das Sie über WordPress Core gesagt haben, was ist es mit der Natur von Open-Source-Software, die vielleicht bei diesem Problem hilft, dass sie sicher ist? Weil ich denke, das ist einer dieser Missverständnisse und Mythen, die da draußen sind, dass Open-Source-Software irgendwie nicht grundsätzlich sicher ist.

BRENT STACKHOUSE: Nun, das ist eine großartige Frage. Und mich würde Joes Meinung dazu interessieren. Und um dich nicht zu ärgern, Eric, aber ich bin alt genug. Ich habe gesehen, dass sich das, was wir unter Open Source verstehen, im Laufe der Zeit ziemlich verändert hat.

Open Source war damals sehr bekannte Projekte wie Apache oder, sagen wir, OpenSSH, oder, sagen wir, Linux und solche Dinge, und wenn wir damals Open Source sagten, waren wir das normalerweise in Bezug auf.

Und, ja, es gab viele sekundäre, tertiäre, was auch immer kleinere Projekte da draußen, die nicht annähernd so gut gewartet wurden, etc. Ich denke, wir meinen mit Open Source praktisch alles, was in GitHub ist, jeder, der irgendetwas da draußen postet, irgendjemand sonst kann greifen.

Sie sprechen von Bibliotheken, sehr kleinem Code, von dem jeder sagen könnte, oh, das sieht großartig aus, basierend auf seinen Funktionen, das werden wir einbauen. Und ich werde ein bisschen später sprechen, wie Joe angedeutet hat, mit Lieferkettenproblemen. Ich werde etwas später auf die entwicklerspezifischen Herausforderungen in Bezug auf die Risikominderung in der Lieferkette eingehen.

Weil Open Source – ich denke an deine Frage zu WordPress zurück, Eric. Toll, dass es Quellen gibt. Viele Leute schauen darauf. Ich denke, das war damals mit Apache und solchen Dingen auch so. Alles, was auf breiter Basis verwendet wird, wird sowohl von den Guten als auch von den Bösen genau unter die Lupe genommen, und ich denke, das ist eine gute Sache. Sicherheit durch Verschleierung war noch nie eine gute Praxis. Es ist großartig, den Code da draußen zu haben.

Aber Open Source gleich besserer Sicherheit als Closed oder umgekehrt ist eine schwer zu beantwortende Frage. Weil sie buchstäblich Äpfel und Birnen sind. Ich denke, dass WordPress als Team großartige Arbeit geleistet hat, indem es andere Eingaben als seine eigene Intelligenz verwendet hat, wie z. B. die Verwendung eines Bug-Bounty-Programms. WordPress Core macht das seit Jahren. Ich denke, das ist klug.

Sie haben zweifellos unabhängige Forscher, die sie regelmäßig mit ihren Ergebnissen anpingen. Und intelligente Teams nehmen diese Eingaben und tun das Richtige. Ich bin mir sicher, dass sie sich selbst Pen-Tests unterziehen usw. Also machen wir bei WP Engine ähnliche Dinge, aber das ist sozusagen selbstverständlich.

Joe, irgendwelche Gedanken dazu? Tut mir leid, dass ich das übernehme, Eric, aber –

ERIC JONES: Nein, das ist perfekt.

JOE SULLIVAN: Ich denke, Sie haben viele Höhepunkte erreicht. Wenn ich an Open-Source-Software denke – wenn ich an Software aus beliebigen Quellen denke, denke ich, dass wir sie bewerten müssen, bevor wir sie in unsere Umgebung einsetzen. Und manchmal ist Open-Source-Software die bessere Wahl als etwas, das proprietär ist. Weil weißt du was? Sonnenlicht tötet Infektionen ab.

Und was wir mit viel Open-Source-Software machen, ist, dass sich auch viele andere Leute damit beschäftigen. Ich denke, das ist etwas in der Welt der Sicherheit im Allgemeinen, das wir nicht gut genug machen, wenn wir alle in unseren kleinen Teams und Ecken sitzen und versuchen, alles selbst zu lösen.

Es ist eine gute Sache, die Community einzubeziehen. Transparenz und Dialog über Risiken in Bezug auf bestimmte Softwarekomponenten sind eine gute Sache. Und wir werden immer besser darin. Ihr Beispiel eines Bug-Bounty-Programms ist eine weitere Möglichkeit, Transparenz zu schaffen und Dritte einzuladen, Löcher zu stechen.

Open-Source-Software wird von vielen Leuten betrachtet, wenn wir über die am häufigsten verwendeten und wichtigsten Teile von Open-Source-Software sprechen. Aber genauso würde ich mir nicht einfach Code von GitHub holen und ihn in mein Produkt einfügen, ohne ihn wirklich zu prüfen.

Ich würde auch sagen, dass Sie die gleiche Vorsicht walten lassen müssen, wenn Sie eine Lizenz für proprietäre Software erwerben. Sie müssen sich immer noch ansehen, wer es herstellt, welche Praktiken sie haben und wie robust es ist.

BRENT STACKHOUSE: Ja, vieles dreht sich um – und das ist ein Begriff für Risiko-Nerds –, aber um Sicherheit. Welche Zusicherung können wir für alles, was wir tun, im technischen Sinne gewinnen, wie sicher sind wir, wenn wir A, B, C tun? Und viele Zusicherungen, abhängig von der Situation mit Closed Source, sind schwieriger zu bekommen.

In Open Source können Sie leichter ein besseres Gefühl dafür bekommen, wer was getan hat, um den Code zu überprüfen. Bei Closed Source ist es etwas kniffliger. Sie müssen indirekte Eingaben verwenden, die zeigen, dass dieses Unternehmen im Laufe der Zeit gute Sicherheitspraktiken angewendet hat usw.

Aber ja, Zusicherungen zu erhalten, ist letztendlich das, was Sie zu tun versuchen, wenn Sie bereitstellen, egal welche Technologie im Allgemeinen verwendet wird. Danke.

ERIC JONES: Also, für die Entwickler da draußen, was sind diese spezifischen Zusicherungen, nach denen Sie beide in Unternehmen suchen? Wenn diese Projekte oder Softwareteile diese Dinge haben, halten Sie sie für gut, für ein bisschen sicherer, als sie es sonst sein könnten.

BRENT STACKHOUSE: Möchten Sie eine WordPress-Antwort? Ich lasse Joe gehen, wenn Sie allgemein anfangen wollen.

ERIC JONES: Ja, Joe, wenn Sie vielleicht eine breite Perspektive bieten könnten, und dann, Brent, könnten Sie die spezifischere WordPress-Perspektive bieten.

JOE SULLIVAN: Ja, also, von meinem Platz aus denke ich über diese Frage als Käufer und als Verkäufer nach, weil ich bei Cloudflare arbeite, wo Leute unsere Produkte implementieren. Und die wichtigste Frage, die sich jeder Cloudflare-Kunde stellt, bevor er Cloudflare implementiert, lautet: Soll ich Cloudflare vertrauen? Weil wir vor ihrem gesamten Geschäft sitzen. Und das ist ein wirklich riskanter Ort, um jemanden unterzubringen, es sei denn, Sie vertrauen ihm.

Aber ich bin auch auf Dritte angewiesen, weil wir wachsen und unsere Produkte entwickeln müssen. Und so bin ich auf der empfangenden Seite der schwierigen Fragen, und ich bin auf der fragenden Seite der schwierigen Fragen.

Und sehen Sie, keiner von uns hat die Zeit oder die Ressourcen, jedes Mal, wenn wir mit einem Dritten zusammenarbeiten, hinzugehen und zu prüfen. Wir haben nicht genug Teams. Wir haben nicht die Fähigkeiten dazu. Wir beginnen also mit den Sicherheitszertifizierungen als einem Konzept, auf das es hier ankommt.

Wenn ich Zertifizierungen sage, meine ich Dinge wie einen SOC 2, einen SOC 2 Typ II wie WP Engine oder ISO 27001 oder PCI. Wenn Sie diese Worte und Zertifizierungen hören, sollten Sie denken, dass ein Dritter eine anerkannte Reihe von Standards verwendet hat, um dieses Unternehmen zu prüfen und zu bewerten, ob es alle Kontrollen für diesen Bereich erfüllt.

Und so hat jeder von uns – Cloudflare einen SOC 2 Typ II-Bericht, den wir teilen können. WP Engine hat einen SOC 2 Typ II-Bericht, den wir teilen können. Und das Schöne daran, wenn ich Typ II sage, bedeutet das, dass es sich nicht nur um eine Prüfung zu einem bestimmten Zeitpunkt handelte. Es war eine längere Zeit.

Bei unserem SOC 2 Typ II bedeutet dies beispielsweise, dass wir im letzten Jahr zu jedem Zeitpunkt während des Zeitraums, für den diese Zertifizierung besteht, diese Mindestsicherheitskontrollen eingehalten haben. So oft ist das genug für einen Kunden. Oh, diese Firma hat einen SOC 2 Typ II. OK, ich werde ihnen vertrauen.

Aber dann möchten Sie vielleicht ein wenig tiefer graben, basierend auf Ihrer spezifischen Implementierung. Wenn ich also über den Kauf eines Produkts nachdenke, denke ich nicht nur an die Qualität des Codes, sondern auch daran, wie er sich in meine Umgebung integriert.

Daher ist mir die Authentifizierung sehr wichtig. Kann ich das in meine einmalige Anmeldung integrieren, sodass ich verwalten kann, wer innerhalb und außerhalb meiner Organisation darauf zugreifen kann? Denn von dort kommt, wie ich bereits sagte, ein großer Prozentsatz der Sicherheitsprobleme.

Sie möchten sich also für Produkte wie WP Engine entscheiden, bei denen Sie es in Ihr SSO integrieren und die Sicherheit durch die Tools laufen lassen können, ohne dass Sie viel praktische Arbeit leisten müssen. Für mich sind es also Zertifizierungen plus die Kombination aus allem anderen, was Sie für Ihre spezifische Umgebung wünschen.

ERIC JONES: Und, Brent, um die Frage an dich zurückzugeben, wie denkst du darüber in einem WordPress-Kontext?

BRENT STACKHOUSE: Ja, ich finde das großartig. Wenn Leute sozusagen das WordPress-Ökosystem erweitern möchten, indem sie Plugins und Themes verwenden, gibt es ein paar Dinge, auf die man nur aus einem geschäftlichen Kontext oder einer geschäftlichen Ebene achten sollte, wie beliebt ist dieses bestimmte Stück Code, Plugin oder Thema? Und kann ich in ihrem Änderungsprotokoll sehen, dass sie regelmäßig aktualisieren, auch für Sicherheitsupdates?

Das sind sehr qualitative Maßnahmen oder Eingaben, aber sie sind immer noch relevant. Typischerweise haben Plugin-Entwickler oder Theme-Entwickler, die einen großen Fußabdruck haben – sie haben viele Kunden – sie haben sozusagen etwas zu verlieren und zu gewinnen, indem sie ihren Code gut oder nicht gut pflegen, je nachdem, wie Sie es tun möchte das umdrehen. Daher ist es im Allgemeinen eine gute Praxis, sich für das, was Sie brauchen, einfach für die gängigsten zu entscheiden.

Auf Entwicklerebene können Sie sozusagen mehr Kontrolle ausüben. Sie können statische Anwendungssicherheitstools für ein bestimmtes Plugin verwenden. Werden Sie wahrscheinlich etwas finden, das ein anderer Sicherheitsforscher nicht hat? Vielleicht nicht, aber es ist trotzdem eine gute Idee, diese Dinge durch Ihre Werkzeuge laufen zu lassen. Und es gibt viele kostenlose Open-Source-Tools oder sogar kommerzielle Tools mit sehr niedrigen Kosten oder kostenlosen Lizenzen, mit denen Sie eine bessere Gewissheit über den Code erhalten, den Sie in Ihrer Umgebung verwenden.

Eine Sache, die Joe angesprochen hat und auf die ich auch ein wenig mit Ihnen sprechen werde, ist, dass WP Engine sowohl ein Konsument von Code als auch ein Produzent ist, und daher sind wir auch ein Dienstleister und sehr besorgt über die Integrität unseres Codes End-to-End-Entwicklungsbemühungen. Und es ist eine ständige Herausforderung.

Eines der Dinge für unsere Entwickler da draußen, die WordPress-Sites betreiben, ist, dass sie sich hoffentlich des Risikokontexts ihrer Organisation bewusst sein sollten. In welcher Branche sind sie zum Beispiel? Wie viel Toleranz hat die Organisation für schlechte Dinge, die passieren? Bestimmte Sektoren oder Organisationen sind viel anfälliger für Dinge wie DDoS-Angriffe usw.

Wenn Sie also darüber nachdenken und möglicherweise für diese Dinge codieren, können Sie nicht für DDoS codieren, aber Sie können sich dessen sicherlich bewusst sein und das aufdecken. Ich denke, es ist sehr wichtig, dass Entwickler das Richtige tun.

ERIC JONES: Ich schalte ein wenig um, und mit dem Ziel, einige sehr spezifische Empfehlungen zu geben, Joe, was würden Sie Website-Eigentümern aus einer hochrangigen Sicherheitsperspektive empfehlen, um ihre Sicherheit zu stärken?

JOE SULLIVAN: Ja, so wie ich darüber denke, ist eine Unze Prävention besser als ein Pfund Heilung. Und im Sicherheitskontext bedeutet das, dass Sie die richtigen Tools und Plattformen auswählen, die Sie verwenden werden, bevor Sie beginnen, anstatt zu versuchen, etwas zu bauen, und jetzt lassen Sie uns herausfinden, wie wir die Sicherheit darauf aufbauen.

Wenn Sie also Plattformen, Tools und Code auswählen, sollten Sie von Anfang an auf Sicherheit achten. Und wie ich schon sagte, wenn Sie die Sicherheit durch die von Ihnen gewählten Tools automatisch durchführen lassen, werden Sie an einer viel besseren Stelle stehen, als wenn Sie Leute einstellen müssen, die nebenbei kommen und etwas tun Reihe von Audits, und versuchen Sie dann, alles zu reparieren, während das Schiff durch den Ozean kreuzt.

So kann man das nicht patchen. Und so suche ich für mich immer danach, was ich vom Sicherheitsstandpunkt aus der Box bekomme? Welche Einstellungen gibt es für mich? Und wenn ich die Grundlagen der Sicherheit nehme, denke ich, dass es eigentlich nur ein paar Bereiche gibt.

Nummer eins ist für mich immer das Identitäts- und Zugriffsmanagement. Deshalb habe ich von Anfang an über die Möglichkeit gesprochen, Single Sign-On zu integrieren. Wenn ich ein Unternehmen gründen würde, würde ich als Erstes das richtige Single-Sign-On-Setup auswählen, das mit meiner Organisation skaliert. Und ich würde immer versuchen, Produkte auszuwählen, die sich damit integrieren lassen.

Das zweite, woran ich denken würde, ist, OK, ich werde eine Menge Code haben, der dem Internet gegenübersteht. Wie wehre ich Angriffe aus dem Internet ab? Muss ich mich an meine – Brent erwähnte Denial-of-Service-Angriffe halten?

Muss ich persönlich herausfinden, wie ich Load Balancer haben und all das verwalten und Produkte wie Cloudflare kaufen kann? Oder ist es in eine Plattform integriert, die ich kaufe, damit ich nicht über Sicherheit nachdenken muss. Ich weiß, dass es bereits dort eingebaut ist, und so weiter. Also würde ich meine Mitarbeiter und das Identitäts- und Zugriffsmanagement, den mit dem Internet verbundenen Code, methodisch durchgehen.

Und dann ist die dritte Säule wahrscheinlich – von der wir hier nicht wirklich reden – wie stelle ich die Laptops und solche Sachen auf?

ERIC JONES: Und, Brent, vielleicht zu Ihnen rüberkommend, was sind einige spezifische Dinge, über die WordPress-Entwickler nachdenken sollten, um die sichersten Websites zu erstellen, die sie können?

BRENT STACKHOUSE: Ja, meine erste Reaktion ist, dass es interessant ist. Vieles, worüber wir sprechen, ist eine Entscheidung darüber, wann gebaut oder gekauft werden soll. Werden Sie Ihre eigenen Plugins und all die Dinge erstellen, die Sie tun möchten, um Ihr WordPress-Ökosystem zu erweitern? Oder wirst du sozusagen kaufen, auch wenn es kostenlos ist?

Aber das trifft, denke ich, auch auf Joe und mich zu, in dem Sinne, dass wir den Code anderer Leute über GitHub oder einen anderen Mechanismus konsumieren, und wir könnten möglicherweise Entwickler einstellen und das alles von Grund auf neu machen. Oder wir können etwas verwenden, das jemand anderes bereits getan hat.

Und warum das Rad nachbauen, wenn es nicht sein muss? Aber wie erhalten Sie dann die Gewissheit, dass der von Ihnen verwendete Code in gutem Zustand ist? Also zurück zu WordPress speziell, ich denke, es gibt ein paar Dinge – das ist wahrscheinlich der gesunde Menschenverstand für ein Entwicklerpublikum, aber wir sagen es trotzdem. Wenn Sie codieren, codieren Sie sicher, d. h. wissen Sie, was Sie zu tun versuchen. Versuchen Sie, das, was Sie zu tun versuchen, in Bezug auf Ihre Funktionen oder all diese Dinge einzugrenzen.

Aber behalte die OWASP Top 10 im Hinterkopf. OWASP Top 10 ist unserem Publikum wahrscheinlich gut bekannt. Aber auch hier sind die Grundlagen wichtig, wie Joe bereits angedeutet hat, und daher gehören zu den Grundlagen für Entwickler sicherlich die OWASP Top 10.

Und dann verwenden Sie eines dieser statischen Anwendungssicherheitstools, die ich erwähnt habe und die vor der Bereitstellung oder während der Bereitstellung sehr gut sind. Sie können es sozusagen automatisch tun. Und stellen Sie sicher, dass der Code, den Sie dorthin senden, tatsächlich in einem ziemlich guten Zustand ist und dass es keine bekannten offensichtlichen Schwachstellen mit Ihrem eigenen Code gibt, wenn Sie benutzerdefinierten Code entwickeln.

Die dritte Sache knüpft an das Problem der Lieferkette an, über das wir gesprochen haben. Und GitHub hat einige kostenlose Funktionen, die Ihnen tatsächlich sagen können, wenn Ihre Upstream-Abhängigkeiten bekannte Schwachstellen aufweisen. Dependabot, ein Abhängigkeits-Bot, ist also eine großartige Sache, die GitHub bereitstellt, und Sie sollten das unbedingt in Ihren Repos aktiviert haben. Und es kann tatsächlich PRs automatisch erstellen. Und dann haben Sie die Möglichkeit, das zusammenzuführen, wenn Sie glauben, dass dies erforderlich ist, damit Ihre Upstream-Abhängigkeiten zumindest keine bekannten Schwachstellen aufweisen.

Vermutlich hat jeder Code Fehler, selbst wenn Sie ihn ausliefern, und eine Teilmenge davon sind wahrscheinlich Sicherheitsfehler, aber zumindest müssen wir die offensichtlichen Herausforderungen vermeiden, auf die Joe zuvor angespielt hat. Wir wollen nicht in die Zeitungen kommen, weil uns das Offensichtliche entgeht. Wie, hey, du solltest Dinge patchen. Also, ja, das sind drei Dinge, die Entwickler meiner Meinung nach beachten sollten, um sich sozusagen aus dem Feuer herauszuhalten.

ERIC JONES: Ich denke, die Frage für Sie beide ist, was sind die Dinge, die Sie den Hecht herunterkommen sehen, die derzeit nicht ganz auf dem Radar sind? Und was sind die Dinge, über die Leute, Entwickler und Websitebesitzer nachdenken sollten, die sie jetzt nicht tun? Und das ist eine Frage, die für jeden von Ihnen offen ist.

BRENT STACKHOUSE: Nun, ja, ich möchte einspringen, weil Joe vorhin auf die Okta-Sache geantwortet hat. Also diese bestimmte Gruppe – das ist interessant. Also wir haben es schon gesehen. Ich kann also nicht einmal sagen, dass dies fast den Hecht herunterkommt.

Aber die Gruppe, die Okta explodierte, und auch andere große Namen, die wir in diesem Podcast oder diesem Interview nicht unbedingt erwähnen müssen, verwenden in erster Linie sehr, sehr interessante Social-Engineering-Techniken, überhaupt keine sehr technischen Angriffe.

Daher sind Entwickler möglicherweise nicht anfällig für diese Art von Angriffen. Es hängt von der Organisation ab und davon, wo dieser Entwickler hineinpasst. Aber sicherlich könnte jeder, der als IT-Mitarbeiter oder sozusagen als Person mit Zugriff auf Assets für eine bestimmte Organisation fungiert, sehr gut Ziel von Social-Engineering-Angriffen werden.

Das ist etwas, worüber wir nicht gerne sprechen, weil wir es nicht einfach technisch beheben können. Aber der Mensch bleibt ehrlich gesagt weiterhin die Schwachstelle. Durch die Haustür zu gehen, wie wir es nennen, also ein Angriff von außen, das ist oft technisch schwieriger und mehr Arbeit für Angreifer. Und manchmal oder oft werden sie Social-Engineering-Angriffen ausgesetzt. Phishing ist immer noch sehr, sehr effektiv, egal über welches Medium.

Ich denke, das ist etwas, das sich immer noch als Herausforderung herausstellt. Und Organisationen konzentrieren ihre Zeit wahrscheinlich nicht annähernd so sehr darauf, wie sie sollten.

JOE SULLIVAN: Ja, ich denke, eine andere Art zu sagen, was Brent mit etwas anderer Stimme gesagt hat, ist, dass ich eigentlich nicht möchte, dass Entwickler viel Zeit mit einer Kristallkugel verbringen und versuchen, das nächste Sicherheitsproblem vorherzusehen. Es ist wichtiger, die Grundlagen richtig zu machen.

Und diese Grundlagen werden sich um die meisten der nächsten großen Dinge kümmern, was auch immer es ist. Und als Beispiel habe ich erwähnt, dass es eine grundlegende Veränderung in Bezug auf das Aufkommen von Ransomware gegeben hat. Es hat Unternehmen in einer Weise lahmgelegt, wie es Cyberkriminalität noch nie zuvor getan hat.

Aber es ist nicht so, dass Sie losgehen und ein Produkt kaufen, um Ransomware zu blockieren. Sie gehen zurück und tun genau die gleichen Dinge, die Sie bereits hätten tun sollen, um mit den vorherigen Bedrohungen fertig zu werden. Was ist Ransomware? Es handelt sich um bösartige Software, die in Ihrer Umgebung platziert wird.

Nun, jedes Mal, wenn ein Eindringling in Ihre Umgebung eindringt, ist es schlimm. Wir haben also das Recht – wenn wir uns nur weiterhin auf den Perimeter konzentrieren und nicht zulassen, dass unsere Mitarbeiter oder unser Code kompromittiert werden, müssen wir uns nicht mit Ransomware auseinandersetzen.

Anstatt also herumzusitzen und sich Gedanken über die nächste Ransomware zu machen, konzentrieren Sie sich einfach weiter auf die Grundlagen. Und lassen Sie den Rest von uns in der Welt der Sicherheit über die Zukunft spekulieren.

ERIC JONES: Joe und Brent, vielen Dank für Ihre Perspektive, Ihre Zeit und Ihren Rat heute. So viel zum Nachdenken über die richtigen Grundlagen, die Bedeutung von Transparenz, worauf man aus Sicht einer Versicherung achten sollte.

Und dann ist vielleicht das Wichtigste von allem, dass Sicherheit niemals ein nachträglicher Gedanke sein sollte. Sie müssen es von Anfang an einbauen. Ich ermutige alle, wenn Sie daran interessiert sind, mehr über die Sicherheitsangebote von WP Engine oder Cloudflare zu erfahren, besuchen Sie bitte unsere Websites. Und natürlich haben wir bei WP Engine eine Fülle von Sicherheitsinformationen, die allen in unserem Ressourcenzentrum zur Verfügung stehen, wenn Sie an einer bestimmten WordPress-Perspektive interessiert sind. Nochmals vielen Dank an alle, die sich heute eingeschaltet haben, dass Sie Ihre Zeit aufgewendet haben und heute zu uns gekommen sind.