DE{CODE}: Dbanie o bezpieczeństwo witryn WordPress w obliczu rosnącej liczby globalnych cyberataków

Dołącz do ekspertów z WP Engine i Cloudflare podczas tej poświęconej bezpieczeństwu sesji na temat blokowania witryn internetowych. Dyskusja podkreśla najnowsze trendy cyberataków wraz z konkretnymi przykładami tego, jak WP Engine chroni Twoje witryny. Deweloperzy odejdą z przejrzystą listą kontrolną kroków, które należy wykonać, aby zabezpieczyć swoje witryny.

Slajdy sesji

Transkrypcja pełnego tekstu

ERIC JONES : Witamy w DE{CODE} i dziękujemy za dołączenie do tego, co zapowiada się na niesamowitą sesję grupową. Nazywam się Eric Jones i jestem wiceprezesem ds. marketingu korporacyjnego w WP Engine. Nie mógłbym być bardziej podekscytowany moderowaniem dzisiejszej dyskusji między Joe Sullivanem, dyrektorem ds. bezpieczeństwa Cloudflare, a Brentem Stackhousem, wiceprezesem ds.

Nasza dyskusja, Zabezpieczanie witryn WordPress w obliczu wzrostu globalnych ataków cybernetycznych, nie mogłaby być bardziej na czasie, biorąc pod uwagę, że cyberataki nie tylko rosną, ale są rekordowo wysokie. Joe, może zaczniemy od ciebie? Chciałbym usłyszeć z szerokiej perspektywy makro, jakie trendy obserwujesz w krajobrazie cyberbezpieczeństwa.

JOE SULLIVAN : Jasne. Cieszę się, że mogę wskoczyć. Dziękuję za zaproszenie mnie do tej rozmowy. też bardzo nie mogę się doczekać. Myślę, że obecnie w świecie bezpieczeństwa istnieją dwa megatrendy. Numer jeden jest o wiele ważniejszy w oczach świata.

Więc zanim przejdziemy do technicznej strony i rzeczywistych wyzwań, przed którymi stoimy każdego dnia, warto poświęcić chwilę, aby przyjrzeć się, jak bardzo świat bezpieczeństwa ewoluował od czasu, gdy razem z Brentem rozpoczęliśmy ten zawód, ponieważ powiedziałeś, dekady temu.

Bezpieczeństwo nie jest już zespołem ani koncepcją siedzącą w kącie organizacji. Jest centralnym elementem wszystkiego, co robimy. Dyrektorzy generalni są pociągnięci do odpowiedzialności. Zarządy zadają trudne pytania. Inwestorzy venture capital nie wniosą wkładu, jeśli nie zobaczą odpowiedniego poziomu inwestycji.

A co ważniejsze, nasi klienci i konsumenci oraz nabywcy biznesowi naszych produktów wymagają od nas znacznie więcej. I to jest dla mnie najważniejszy trend i powód, dla którego prowadzimy tę rozmowę. Ma to znaczenie dla każdego programisty w każdym aspekcie jego pracy.

Wracając do tego, co faktycznie dzieje się w świecie bezpieczeństwa, wcale nie jest łatwiej. A wyzwania po prostu nadchodzą do nas. Jeśli zwracasz uwagę na nagłówki gazet, widziałeś w ciągu ostatnich kilku dni wzrost liczby programów ransomware. to naprawdę straszne.

Oprogramowanie ransomware zmieniło grę pod względem bezpieczeństwa, ponieważ przeszło od kradzieży niektórych danych lub ujawnienia czegoś światu do zamknięcia firmy. I tak cała koncepcja znaczenia bezpieczeństwa została spotęgowana przez to ryzyko, pomysł, że możemy obudzić się rano i nie być w stanie włączyć naszych laptopów, nie uruchomić naszej strony internetowej. To naprawdę straszne.

Również sprawy geopolityczne zaczynają naprawdę wpływać na nas wszystkich. Sytuacja na Ukrainie nie ogranicza się do świata fizycznego. Obecnie jest to mocno związane z cybernetycznym kontekstem. I to się rozlewa, by wpłynąć na resztę z nas. Tak więc wydarzenia geopolityczne, które mają miejsce w świecie fizycznym, mają implikacje techniczne dla tych z nas, którzy próbują prowadzić firmy działające w Internecie.

I myślę, że trzecią rzeczą, o której chciałbym wspomnieć z technicznego punktu widzenia, jest to, że nie żyjemy w światach własnego kodu. Żyjemy w światach, które są połączeniem oprogramowania i kodu, które razem reprezentują organizację.

I tak w bezpieczeństwie używamy terminu łańcuch dostaw, aby mówić o całym tym innym kodzie i innych aplikacjach oraz o wszystkim, co staje się częścią naszej tożsamości jako firmy. Na przykład, kiedy ostatnio pojawiły się historie o tym, że Okta została naruszona, nie chodziło tylko o to, czy Okta została naruszona. Chodziło o to, czy moja firma i wszystkie inne firmy korzystające z Okty są zagrożone.

A moich klientów nie obchodziła Okta. Dbali o to, jak nas wykorzystają, a jakie kontrole wdrożyliśmy, aby zmniejszyć ryzyko narażenia Okta na szwank? Więc po prostu dużo się teraz dzieje. I to jest dobry czas na tę rozmowę.

ERIC JONES: Joe, jako dodatkowe pytanie, co sądzisz o ustaleniu priorytetów dla wszystkich tych konkretnych wyzwań, które masz i które ma każda organizacja zajmująca się bezpieczeństwem?

JOE SULLIVAN: Jasne. Myślę, że to jest ostateczne pytanie. Gdybyśmy mieli nieograniczony budżet i nieograniczoną liczbę ludzi, którzy mogliby wykonać tę pracę, moglibyśmy zrobić to wszystko. Ale tak nie jest w żadnej organizacji na żadnym etapie jej rozwoju.

Dlatego zawsze jesteśmy w trakcie ustalania priorytetów. Powiedziałbym więc, że najpierw musisz ustalić priorytety dla podstaw. To szokujące, jak duży procent kompromisów wynika z błędów w podstawach.

Jako profesjonaliści w dziedzinie bezpieczeństwa uwielbiamy zagłębiać się w ataki zero-day lub O-day i przyglądać się tej naprawdę skomplikowanej rzeczy. Ale w 90% przypadków kompromisy wynikają z e-maili phishingowych lub kogoś, kto zdecydował się użyć tego samego hasła, którego użył w osobistej witrynie internetowej, która została naruszona, i nie włączył uwierzytelniania wieloskładnikowego.

W wielu przypadkach dysponujemy narzędziami, aby dobrze wykonać podstawowe czynności, ale nie poświęcamy czasu na ich wdrożenie.

ERIC JONES: Tak, myślę, że dotykasz kluczowego punktu bezpieczeństwa, prawda? Że to coś, za co wszyscy jesteśmy odpowiedzialni. To wspólna odpowiedzialność całej organizacji. To nie żyje tylko w zespole bezpieczeństwa. Żyje z każdym pracownikiem w konkretnej firmie.

Brent, zwracając się do ciebie, z perspektywy WordPressa, co jest takie samo, co jest inne w WordPressie i jakie są największe luki, które widzisz w krajobrazie?

BRENT STACKHOUSE : Dzięki, Eric, i dzięki za zaproszenie mnie. Doceń dzielenie czasu z Joe. On wie dużo rzeczy. Byliśmy kilka razy w okolicy bloku. To jest fascynujące.

WordPress na wiele sposobów – wiadomości są ogólnie dobre w tym sensie, że WordPress Core różni się od wszystkich wtyczek i motywów oraz innych rzeczy w ekosystemie WordPress. WordPress Core nadal jest solidny i odporny na typowe ataki.

Tak więc WordPress sam w sobie jest dobrą, stabilną, mocną platformą, z której klienci powinni czuć się komfortowo w niemal każdym kontekście. Wyzwanie leży głównie po stronie wtyczek, gdzie wordpress.org lub ci główni programiści nie mają nic wspólnego z większością wtyczek i motywów.

A zmienność jakości kodu, podobna do aplikacji, które dostaniesz w Google Play Store lub coś w tym stylu, nie są one napisane przez, jak właśnie mówiłem, Google. Te wtyczki i motywy nie są napisane przez WordPressa i może to być wszystko, od pojedynczego programisty po zespół. Ślad tych wtyczek lub motywów może być bardzo mały lub bardzo duży. Mogą mieć dobrą historię łatania rzeczy szybko lub nie.

I tak to zależy. Tak więc, gdy popularność WordPressa i ekosystemu rośnie, można założyć, że osoby atakujące będą nadal zwiększać swoje wysiłki, ponieważ atakujący idą tam, gdzie są pieniądze, podobnie jak w przypadku systemu Windows, który ma więcej złośliwego oprogramowania niż ogólnie komputerów Mac. To dlatego, że tam jest ślad i tam są pieniądze.

Tak więc WordPress nie jest inny, a wraz ze wzrostem popularności można oczekiwać, że osoby atakujące będą robić to, co robią. Dobrą wiadomością jest to, że w porównaniu z tym, kiedy cztery lata temu uruchomiłem WP Engine, ekosystem jest znacznie zdrowszy.

Twórcy wtyczek, twórcy motywów są bardziej świadomi, że otrzymają informacje od badaczy bezpieczeństwa lub innych osób zauważających luki w zabezpieczeniach. I większość z nich odpowiedzialnie buduje te mięśnie, aby mogli bardzo, bardzo szybko odwrócić łaty.

Więc rzeczy mają się dużo lepiej niż kiedyś. Cztery lata temu wielu programistów było zaskoczonych, gdy pojawiały się luki w zabezpieczeniach, a oni nie działali tak szybko ani nie byli w stanie zaspokoić potrzeb swoich klientów w zakresie regularnego łatania.

Wszyscy jako konsumenci technologii jesteśmy przyzwyczajeni do, cytując bez cytatu, „Patch Tuesday” lub naszych regularnych aktualizacji od Apple i tak dalej. Nie dziwią nas więc luki w zabezpieczeniach. Bylibyśmy jednak bardzo zdziwieni, gdyby ten producent nie załatał czegoś odpowiedzialnie i szybko.

Tak więc ekosystem WordPress jest ogólnie zdrowszy niż, jak sądzę, cztery lata temu. Ponownie, WordPress Core jest świetny, ale myślę, że wtyczki i motywy ogólnie nadążają. Więc to całkiem pozytyw.

ERIC JONES: Aby dwukrotnie kliknąć coś, co powiedziałeś o WordPress Core, o co chodzi z samą naturą oprogramowania open source, które może pomóc w rozwiązaniu tego problemu związanego z bezpieczeństwem? Ponieważ myślę, że to jedno z tych nieporozumień i mitów, które krążą, że w jakiś sposób oprogramowanie open source nie jest zasadniczo bezpieczne.

BRENT STACKHOUSE: Cóż, to świetne pytanie. I byłbym zainteresowany przemyśleniami Joe na ten temat. I nie chcę cię wyzywać, Eric, ale jestem wystarczająco dorosły. Widziałem, co rozumiemy pod pojęciem open source, które zmieniło się z biegiem czasu.

W tamtych czasach open source były bardzo dobrze znanymi projektami, takimi jak Apache, OpenSSH lub Linux i tym podobne, więc kiedy mówimy wtedy o otwartym oprogramowaniu, zazwyczaj tak właśnie myśleliśmy odnosi się do.

I tak, było wiele drugorzędnych, trzeciorzędnych, mniejszych projektów, które nie były tak dobrze utrzymane itp. Myślę, że przez otwarte oprogramowanie rozumiemy praktycznie wszystko, co znajduje się w GitHub, każdy, kto publikuje tam wszystko, co ktokolwiek inny może chwycić.

Mówisz o bibliotekach, bardzo małym kodzie, o którym każdy mógłby powiedzieć, och, wygląda świetnie w oparciu o jego funkcje, że zamierzamy to włączyć. Porozmawiam trochę później, jak Joe wspomniał o problemach z łańcuchem dostaw. Omówię trochę później wyzwania specyficzne dla programistów w zakresie ograniczania ryzyka łańcucha dostaw.

Ponieważ open source – wracam myślami do twojego pytania, Eric, o WordPress. To wspaniale, że źródło jest dostępne. Wiele osób na to patrzy. Myślę, że tak jest również w przeszłości z Apache i podobnymi rzeczami. Wszystko, co jest powszechnie używane, będzie przedmiotem wielu analiz zarówno ze strony dobrych, jak i złych facetów i myślę, że to dobra rzecz. Bezpieczeństwo poprzez zaciemnienie nigdy nie było dobrą praktyką. A więc posiadanie kodu jest świetne.

Jednak odpowiedź na pytanie, czy otwarte oprogramowanie jest równe lepszemu bezpieczeństwu niż zamkniętemu lub odwrotnie, jest trudna. Ponieważ dosłownie są to jabłka i pomarańcze. Myślę, że WordPress jako zespół wykonał świetną robotę, używając innych danych wejściowych niż ich własna inteligencja, takich jak program nagród za błędy. WordPress Core robi to od lat. Myślę, że to mądre.

Bez wątpienia mają niezrzeszonych badaczy, którzy regularnie przesyłają im swoje odkrycia. Inteligentne zespoły wykorzystują te dane wejściowe i postępują właściwie. Jestem pewien, że sami przechodzą testy pióra itp. Robimy więc podobne rzeczy w WP Engine, ale to coś w rodzaju kursu.

Joe, masz jakieś przemyślenia na ten temat? Przepraszam, że przejmuję kontrolę, Eric, ale…

ERIC JONES: Nie, to jest idealne.

JOE SULLIVAN: Myślę, że dużo trafiłeś w najwyższe punkty. Kiedy myślę o oprogramowaniu typu open source – kiedy myślę o oprogramowaniu z dowolnego źródła, myślę, że musimy je ocenić, zanim umieścimy je w naszym środowisku. Czasami oprogramowanie open source będzie lepszym wyborem niż coś, co jest zastrzeżone. Bo wiesz co? Światło słoneczne zabija infekcję.

A w przypadku wielu programów open source jest to, że patrzy na nie wiele innych osób. Myślę, że ogólnie rzecz biorąc, w świecie bezpieczeństwa nie radzimy sobie wystarczająco dobrze, wszyscy siedzimy w naszych małych zespołach i rogach i próbujemy sami wszystko rozwiązać.

Zaangażowanie społeczności to dobra rzecz. Przejrzystość i dialog na temat zagrożeń związanych z poszczególnymi elementami oprogramowania to dobra rzecz. I idzie nam to coraz lepiej. Twój przykład programu bug bounty to kolejny sposób na zapewnienie przejrzystości i zaproszenie osób trzecich do szukania dziur.

Oprogramowanie typu open source ma wiele osób, które się temu przyglądają, gdy mówimy o najczęściej używanych i najważniejszych elementach oprogramowania typu open source. Ale w ten sam sposób nie wziąłbym po prostu kodu z GitHub i nie wrzucił go do mojego produktu bez dokładnej analizy.

Powiedziałbym również, że musisz zachować taką samą ostrożność, kupując licencję na oprogramowanie, które jest zastrzeżone. Nadal musisz spojrzeć na to, kto to robi, jakie mają praktyki i jak solidne jest to.

BRENT STACKHOUSE: Tak, wiele z nich dotyczy – i jest to określenie dla maniaków ryzyka – ale o pewności. Jaką pewność możemy uzyskać dla wszystkiego, co robimy w sensie technicznym, jak bezpieczne jest, gdy wykonamy A, B, C. A wiele zapewnień, w zależności od sytuacji z zamkniętym źródłem, jest trudniejsze do zdobycia.

W otwartym kodzie źródłowym możesz łatwiej zorientować się, kto co zrobił, aby sprawdzić kod. Z zamkniętym źródłem jest trochę trudniej. Musisz użyć pośrednich danych wejściowych, które pokazują, że ta firma z biegiem czasu stosowała dobre praktyki bezpieczeństwa itp.

Ale tak, zdobywanie gwarancji jest ostatecznie tym, co próbujesz zrobić podczas wdrażania, używając ogólnie dowolnej technologii. Dzięki.

ERIC JONES: A więc, jeśli chodzi o programistów, którzy tam pracują, jakie są te konkretne gwarancje, których oboje szukacie w firmach? Jeśli te projekty lub części oprogramowania mają te rzeczy, to uważacie je za dobre, za nieco bardziej bezpieczne, niż mogłyby być w innym przypadku.

BRENT STACKHOUSE: Czy chcesz odpowiedź WordPress? Puszczę Joe, jeśli chcesz zacząć ogólnie.

ERIC JONES: Tak, Joe, gdybyś mógł przedstawić szeroką perspektywę, a następnie, Brent, możesz przedstawić bardziej szczegółową perspektywę WordPress.

JOE SULLIVAN: Tak, więc z miejsca, w którym siedzę, myślę o tym pytaniu jako kupujący i jako sprzedawca, ponieważ pracuję w Cloudflare, gdzie ludzie wdrażają nasze produkty. A pytanie numer jeden, które zadaje każdy klient Cloudflare przed wdrożeniem Cloudflare, brzmi: czy powinienem ufać Cloudflare? Ponieważ siedzimy przed ich całym biznesem. A to naprawdę ryzykowne miejsce dla kogoś, chyba że mu ufasz.

Ale ja również, ponieważ rozwijamy się i musimy budować nasze produkty, polegamy również na firmach zewnętrznych. I tak jestem na końcu odpowiedzi na trudne pytania i jestem na końcu zadania trudnych pytań.

I spójrz, nikt z nas nie ma czasu ani zasobów, aby wejść i przeprowadzić audyt za każdym razem, gdy będziemy pracować z osobą trzecią. Nie mamy wystarczająco dużych zespołów. Nie mamy ustawionych umiejętności. Dlatego zaczynamy od certyfikatów bezpieczeństwa jako koncepcji, która ma tutaj znaczenie.

Kiedy mówię o certyfikatach, mam na myśli takie rzeczy jak SOC 2, SOC 2 Type II, takie jak WP Engine, ISO 27001 lub PCI. Kiedy słyszysz te słowa i certyfikaty, powinieneś pomyśleć, że strona trzecia zastosowała uznany zestaw standardów, aby wejść do tej firmy i przeprowadzić audyt i ocenić, czy spełnia ona wszystkie kontrole w tym obszarze.

I tak każdy z nas – Cloudflare ma raport SOC 2 Type II, którym może się podzielić. WP Engine ma raport SOC 2 Type II, który możemy udostępnić. A miła rzecz w tym, że kiedy mówię o typie II, oznacza to, że nie był to tylko audyt w określonym momencie. To był dłuższy okres czasu.

Na przykład w przypadku naszego SOC 2 typu II oznacza to, że w ciągu ostatniego roku, w dowolnym momencie w tym czasie, dla którego istnieje ta certyfikacja, przestrzegaliśmy tych minimalnych środków kontroli bezpieczeństwa. Tak często klientowi to wystarcza. Na przykład, och, ta firma ma SOC 2 Type II. OK, zaufam im.

Ale wtedy możesz chcieć kopać trochę głębiej w oparciu o konkretną implementację. Kiedy myślę o zakupie produktu, myślę nie tylko o jakości kodu, ale także o tym, jak integruje się on z moim środowiskiem.

A więc coś, co ma dla mnie duże znaczenie, to uwierzytelnianie. Czy mogę zintegrować to z moim jednokrotnym logowaniem, aby móc zarządzać, kto w mojej organizacji i poza nią ma do niego dostęp? Ponieważ stąd, jak powiedziałem wcześniej, bierze się duży procent problemów związanych z bezpieczeństwem.

Więc chcesz wybrać produkty takie jak WP Engine, gdzie możesz zintegrować je z SSO i pozwolić bezpieczeństwu przejść przez narzędzia bez konieczności wykonywania wielu praktycznych prac. Więc dla mnie są to certyfikaty plus połączenie wszystkiego innego, czego chcesz dla swojego konkretnego środowiska.

ERIC JONES: I, Brent, zwracając pytanie, jak myślisz o tym w kontekście WordPressa?

BRENT STACKHOUSE: Tak, myślę, że to świetnie. Kiedy ludzie myślą o rozszerzeniu ekosystemu WordPress, że tak powiem, za pomocą wtyczek i motywów, należy zwrócić uwagę na kilka rzeczy, nawet z kontekstu biznesowego lub warstwy biznesowej, jak popularny jest dany fragment kodu, wtyczka lub temat? Czy mogę zobaczyć w ich dzienniku zmian, że regularnie aktualizują, w tym aktualizacje zabezpieczeń?

Są to bardzo jakościowe miary lub dane wejściowe, ale nadal są istotne. Zazwyczaj programiści wtyczek lub twórcy motywów, którzy mają duży zasięg – mają wielu klientów – mają coś do stracenia i zyskania, że ​​tak powiem, utrzymując dobrze lub nie dobrze swój kod, w zależności od tego, w jaki sposób chce to odwrócić. I tak po prostu wybieranie tych najbardziej popularnych na wszystko, czego potrzebujesz, jest generalnie dobrą praktyką.

Na poziomie programisty możesz zastosować większą kontrolę, że tak powiem. Możesz użyć statycznych narzędzi bezpieczeństwa aplikacji dla danej wtyczki. Czy prawdopodobnie znajdziesz coś, czego nie znalazł inny badacz bezpieczeństwa? Być może nie, ale nadal dobrym pomysłem jest przeprowadzenie tych rzeczy przez dowolne narzędzia. Istnieje wiele bezpłatnych narzędzi typu open source, a nawet narzędzi komercyjnych z bardzo niskimi kosztami lub bezpłatnymi licencjami, które umożliwiają uzyskanie większej pewności co do kodu, którego używasz w swoim środowisku.

Joe poruszył jedną rzecz, o której też trochę z tobą porozmawiam, że WP Engine jest zarówno konsumentem kodu, jak i producentem, więc jesteśmy także usługodawcą i bardzo martwimy się o integralność naszego kompleksowe wysiłki rozwojowe. I jest to ciągłe wyzwanie.

Tak więc jedną z rzeczy dla naszych programistów prowadzących witryny WordPress jest to, że powinni być świadomi, miejmy nadzieję, kontekstu ich organizacji dotyczącego ryzyka. Na przykład w jakim pionie się znajdują? Jaka jest tolerancja organizacji na złe rzeczy? Niektóre sektory lub organizacje są znacznie bardziej podatne na ataki DDoS itp.

Więc myśląc o tym i potencjalnie kodując te rzeczy, nie możesz kodować DDoS, ale z pewnością możesz być tego świadomy i ujawnić to. Myślę, że jest to bardzo ważne dla programistów, którzy postępują właściwie.

ERIC JONES: Zmieniając trochę biegi i mając na celu przedstawienie kilku bardzo konkretnych zaleceń, Joe, z perspektywy bezpieczeństwa na wysokim poziomie, co poleciłbyś właścicielom witryn, aby pomogli wzmocnić swoje bezpieczeństwo?

JOE SULLIVAN: Tak, myślę o tym tak, że uncja profilaktyki jest warta funta leczenia. A w kontekście bezpieczeństwa oznacza to wybranie odpowiednich narzędzi i platform, których będziesz używać przed rozpoczęciem, zamiast próbować coś zbudować, a teraz zastanówmy się, jak dodamy do tego zabezpieczenia.

Tak więc, kiedy wybierasz platformy, kiedy wybierasz narzędzia, kiedy wybierasz kod, od samego początku chcesz o tym myśleć z myślą o bezpieczeństwie. Tak więc, jak powiedziałem, jeśli możesz sprawić, by zabezpieczenia działały automatycznie za pomocą wybranych przez ciebie narzędzi, znajdziesz się w dużo lepszym miejscu, niż gdybyś musiał zatrudniać ludzi, którzy przychodziliby z boku i robili kilka audytów, a następnie spróbować naprawić wszystko, podczas gdy statek płynie przez ocean.

Nie możesz tak załatać. A więc dla mnie zawsze szukam, co mogę wyciągnąć z pudełka z punktu widzenia bezpieczeństwa? Jakie ustawienia są dostępne dla mnie? A jeśli wezmę podstawy bezpieczeństwa, myślę, że jest tylko kilka obszarów.

Dla mnie numerem jeden jest zawsze zarządzanie tożsamością i dostępem. Dlatego od samego początku mówiłem o możliwości zintegrowania pojedynczego logowania. Gdybym zakładał firmę, jedną z pierwszych rzeczy, które wybrałbym, byłaby właściwa konfiguracja jednokrotnego logowania, która będzie skalować się wraz z moją organizacją. I zawsze starałabym się wybierać produkty, które będą się z nim integrować.

Drugą rzeczą, o której bym pomyślał, to OK, będę miał mnóstwo kodu skierowanego do Internetu. Jak oprzeć się atakom z Internetu? Czy będę musiał przejść przez moje – Brent wspomniał o atakach typu „odmowa usługi”.

Czy muszę osobiście wymyślić, jak mieć moduły równoważenia obciążenia i zarządzać tym wszystkim oraz kupować produkty takie jak Cloudflare? A może jest wbudowany w platformę, którą kupuję, więc nie muszę myśleć o bezpieczeństwie. Wiem, że jest już tam wbudowany i tak dalej. Więc metodycznie przeglądałem moich pracowników oraz zarządzanie tożsamością i dostępem, kod internetowy.

A potem, podobnie jak trzeci filar, prawdopodobnie – o którym tak naprawdę tutaj nie mówimy – to jak skonfigurować laptopy i tym podobne rzeczy?

ERIC JONES: I, Brent, może przechodząc do ciebie, jakie są konkretne rzeczy, o których programiści WordPress powinni pomyśleć, aby zbudować najbezpieczniejsze witryny, jakie tylko mogą?

BRENT STACKHOUSE: Tak, moja pierwsza odpowiedź brzmi: to interesujące. Wiele z tego, o czym mówimy, to decyzja o tym, kiedy budować, a kiedy kupować. Czy zamierzasz tworzyć własne wtyczki i wszystkie rzeczy, które chcesz zrobić, aby rozszerzyć swój ekosystem WordPress? A może zamierzasz kupić, że tak powiem, nawet jeśli jest za darmo?

Ale myślę, że dotyczy to również Joe i mnie, w tym sensie, że konsumujemy kod innych ludzi za pośrednictwem GitHub lub innego mechanizmu i moglibyśmy zatrudnić programistów i zrobić to wszystko od zera. Lub możemy użyć czegoś, co ktoś już zrobił.

A po co odtwarzać koło, skoro nie trzeba? Ale jak w takim razie uzyskać pewność, że używany kod jest w dobrym stanie? Wracając konkretnie do WordPressa, myślę, że jest kilka rzeczy – jest to prawdopodobnie zdrowy rozsądek dla odbiorców programistów, ale i tak to powiemy. Kiedy kodujesz, pisz bezpiecznie, co oznacza, że ​​wiesz, co próbujesz zrobić. Spróbuj ograniczyć to, co próbujesz zrobić, pod względem twoich funkcji, wszelkiego rodzaju rzeczy.

Ale pamiętaj o OWASP Top 10. OWASP Top 10 jest chyba dobrze znane naszej publiczności. Ale znowu, podstawy są ważne, o czym Joe wspomniał wcześniej, więc podstawy dla programistów z pewnością obejmują OWASP Top 10.

A następnie użyj jednego z tych statycznych narzędzi bezpieczeństwa aplikacji, o których wspomniałem, które są bardzo dobre przed wdrożeniem lub podczas wdrażania. Można to zrobić automagicznie, że tak powiem. I upewnij się, że kod, który tam wysyłasz, jest rzeczywiście w całkiem dobrym stanie i że nie ma żadnych znanych oczywistych luk w zabezpieczeniach twojego własnego kodu, jeśli opracowujesz kod niestandardowy.

Trzecia rzecz wiąże się z kwestią łańcucha dostaw, o której mówiliśmy. A GitHub ma kilka bezpłatnych funkcji, które mogą faktycznie powiedzieć ci, kiedy twoje zależności nadrzędne mają znane luki w zabezpieczeniach. Tak więc Dependabot, bot zależności, to świetna rzecz, którą zapewnia GitHub, i absolutnie powinieneś mieć to włączone w swoich repozytoriach. I może faktycznie automatycznie tworzyć PR. A potem będziesz mieć możliwość scalenia tego, jeśli uważasz, że potrzebujesz, aby twoje zależności nadrzędne przynajmniej nie miały żadnych znanych luk w zabezpieczeniach.

Przypuszczalnie cały kod zawiera błędy, nawet gdy go wysyłasz, i ma podzbiór, który prawdopodobnie dotyczy błędów bezpieczeństwa, ale przynajmniej musimy uniknąć oczywistych wyzwań, o których Joe wspomniał wcześniej. Nie chcemy dostać się do gazet, ponieważ pomijamy oczywistości. Na przykład, hej, powinieneś coś załatać. Więc tak, to są trzy rzeczy, o których myślę, że programiści powinni pamiętać, aby trzymać się z dala od ognia, że ​​tak powiem.

ERIC JONES: Myślę, że pytanie do was obojga brzmi: jakie rzeczy, które widzicie schodzące ze szczupaka, nie są teraz na radarze? A jakie są rzeczy, o których ludzie, programiści, właściciele witryn powinni myśleć, a nie myślą teraz? I to jest pytanie otwarte dla każdego z was.

BRENT STACKHOUSE: Cóż, tak, chcę się wtrącić, ponieważ Joe odpowiedział wcześniej na sprawę Okty. Więc ta konkretna grupa – to jest interesujące. Więc już to widzieliśmy. Więc nie mogę nawet powiedzieć, że to prawie spada na szczupaka.

Ale grupa, która eksplodowała Okta, a także inne wielkie nazwiska, których nie musimy wymieniać w tym podcaście lub w tym wywiadzie, używają przede wszystkim bardzo, bardzo interesujących technik socjotechnicznych, w ogóle niezbyt technicznych ataków.

Więc może programiści nie są podatni na tego rodzaju atak. To zależy od organizacji i miejsca, w którym programista pasuje. Ale z pewnością każdy, kto działa jako personel IT lub osoba mająca dostęp do zasobów, że tak powiem, dla danej organizacji, może równie dobrze stać się celem ataków socjotechnicznych.

Więc to jest coś, o czym nie lubimy rozmawiać, ponieważ nie możemy tego tak po prostu technicznie naprawić. Ale ludzie szczerze nadal są słabym punktem. Przechodzenie przez frontowe drzwi, jak to nazywamy, co oznacza atak z zewnątrz, jest często technicznie trudniejsze i wymaga więcej pracy dla atakujących. A czasami lub często przechodzą ataki socjotechniczne. Phishing jest nadal bardzo, bardzo skuteczny niezależnie od medium.

Myślę więc, że jest to coś, co wciąż stanowi wyzwanie. A organizacje prawdopodobnie nie poświęcają na to swojego czasu tak bardzo, jak powinny.

JOE SULLIVAN: Tak, myślę, że innym sposobem wyrażenia tego, co Brent powiedział nieco innym głosem, jest to, że tak naprawdę nie chcę, aby programiści spędzali dużo czasu z kryształową kulą, próbując przewidzieć następny problem z bezpieczeństwem. Ważniejsze jest opanowanie podstaw.

A te podstawy zajmą się większością następnej wielkiej rzeczy, cokolwiek by to nie było. Tytułem przykładu wspomniałem, że nastąpiła fundamentalna zmiana w zakresie pojawienia się oprogramowania ransomware. Doprowadził firmy do zastoju w sposób, w jaki cyberprzestępczość nigdy wcześniej tego nie zrobiła.

Ale to nie jest tak, że wychodzisz i kupujesz produkt do blokowania oprogramowania ransomware. Wracasz i robisz dokładnie te same rzeczy, które powinieneś już robić, aby poradzić sobie z wcześniejszymi zagrożeniami. Co to jest ransomware? To złośliwe oprogramowanie, które zostaje umieszczone w twoim środowisku.

Cóż, za każdym razem, gdy intruz dostaje się do twojego środowiska, jest źle. Mamy więc do tego prawo — jeśli po prostu skupimy się na obwodzie i nie pozwolimy, aby nasi pracownicy zostali narażeni na szwank lub nasz kod został narażony na szwank, nie będziemy musieli zajmować się oprogramowaniem ransomware.

Zamiast więc siedzieć i martwić się o kolejne oprogramowanie ransomware, po prostu skup się na podstawach. I niech reszta z nas w świecie bezpieczeństwa spekuluje na temat przyszłości.

ERIC JONES: Joe i Brent, bardzo dziękuję za dzisiejszą perspektywę, poświęcony czas i dzisiejsze rady. Tyle do przemyślenia na temat prawidłowego zrozumienia podstaw, znaczenia przejrzystości, tego, czego szukać z perspektywy ubezpieczenia.

A potem być może najważniejszą rzeczą jest to, że bezpieczeństwo nigdy nie powinno być refleksją. Musisz go wbudować od samego początku. Zachęcam wszystkich, jeśli chcesz dowiedzieć się więcej o ofertach bezpieczeństwa WP Engine lub Cloudflare, sprawdź nasze strony internetowe. I oczywiście w WP Engine mamy mnóstwo informacji o bezpieczeństwie dostępnych dla wszystkich w naszym Centrum zasobów, jeśli interesuje Cię konkretna perspektywa WordPress. Tak więc jeszcze raz dziękuję wszystkim, którzy dzisiaj dołączyli do nas, za poświęcony czas i dołączenie do nas dzisiaj.