Jak być na bieżąco z zabezpieczeniami w 2023 r

Bezpieczeństwo i wydajność to podstawa każdego opracowywanego projektu, witryny, aplikacji i komponentu. Jednak w tym ciągle zmieniającym się krajobrazie może być wyzwaniem pozostawanie na bieżąco z podstawowymi najlepszymi praktykami, a jednocześnie wprowadzanie innowacji.

W tej rozmowie posłuchaj najlepszych technologów, jak dbają o bezpieczeństwo i wydajność w 2023 roku.

Głośniki:

• Ramadass Prabhakar, starszy wiceprezes i dyrektor ds. technologii w WP Engine
• Lawrence Edmondson, CTO w firmie Barbarian
• Sergi Isasi, wiceprezes ds. produktów, wydajność aplikacji w Cloudflare
• Tim Nash, konsultant ds. bezpieczeństwa WordPress w timnash.co.uk
• Jimmy Squires, dyrektor techniczny w space150

Transkrypcja:

RAMADASS: Witam wszystkich. Witamy w czwartej edycji Decode. Wspaniale było widzieć wzrost liczby uczestników każdego roku. W ciągu ostatnich kilku lat nastąpiła znacząca zmiana w krajobrazie bezpieczeństwa w całej branży. Widzieliśmy regularne biuletyny informacyjne dotyczące naruszeń bezpieczeństwa i bezpieczeństwa jako tematu, który często pojawia się w dyskusjach zarówno z klientami, jak i programistami. Dlatego dzisiaj zgromadziliśmy wspaniałą grupę ekspertów branżowych, którzy pasjonują się bezpieczeństwem i są tutaj, aby odpowiedzieć na nasze pytania i podzielić się z nami swoją wiedzą. Zacznijmy więc od krótkiego przedstawienia naszych panelistów. Lawrence, do ciebie.

LAWRENCE EDMONDSON: Dziękuję bardzo za przyjęcie nas. Tu Lawrence Edmondson, CTO w Barbarian. Barbarian to agencja digital oferująca pełen zakres usług. Znajdujemy się w Nowym Jorku.

RAMADASS: Dziękuję, Lawrence. Do ciebie, Sergi.

SERGI ISASI: Dzięki. Jestem wiceprezesem produktu w Cloudflare. Cloudflare tworzymy produkty, które sprawiają, że nasi klienci i partnerzy, tacy jak WPE, łączą się z Internetem bezpieczniej i szybciej, a ja jestem w San Francisco.

MODERATOR: Dziękuję, Sergi. I Tim, do ciebie.

TIM NASH: Jestem konsultantem bezpieczeństwa WordPress tutaj w Wielkiej Brytanii. I w zasadzie spędzam życie na straszeniu programistów.

MODERATOR: Dziękuję. I Jimmy'ego.

JIMMY SQUIRES: Tak, dziękuję. Pracuję w Space 150, także agencji cyfrowej oferującej pełen zakres usług z Minneapolis i tamtejszego CTO.

MODERATOR: Dziękujemy, że zgodziłeś się być dzisiaj na naszym panelu. Chciałbym więc zacząć od omówienia czegoś wyjątkowego, co robicie dzisiaj w dziedzinie bezpieczeństwa w swojej organizacji lub w swoich zespołach. Więc może zacznijmy od Sergiego.

SERGI ISASI: Tak, zagram intro Tima, w którym straszy programistów. Jedną z rzeczy, które staramy się robić częściej w Cloudflare, jest zapewnienie naszym klientom lepszego wglądu w ich ruch i zmniejszenie obciążenia operacyjnego. Tak więc historycznie, jeśli chciałbyś dowiedzieć się, co może mieć wpływ na twoją sieć, co może cię zaatakować, wdrożyłbyś WAF, przestawiłbyś go w tryb dziennika, a następnie poprosiłbyś analityka bezpieczeństwa o przejrzenie dzienników i zobacz co wykrył I jest po prostu o wiele mniej zasobów, aby to zrobić w dzisiejszych czasach.

Dlatego naszym celem na ten rok jest zapewnienie naszym klientom wglądu w ataki, które na nich obserwujemy, nawet jeśli nie używają oni produktu, który dziś zapobiegłby temu atakowi. Dzięki temu mogą wiedzieć, czy ich aplikacja jest atakowana lub ogólnie w dobrym stanie. I na tym skupiamy się przez pozostałą część roku, wprowadzając wszystkie nasze produkty zabezpieczające i informując naszych klientów o tym, co może się dziać lub co faktycznie dzieje się w ich sieci i czy chcą to zablokować.

MODERATOR: Cudownie. To brzmi naprawdę potężnie. Nie mogę się doczekać, aby usłyszeć więcej na ten temat. Więc Tim, a co z tobą?

TIM NASH: Pracuję więc z wieloma różnymi klientami, zarówno agencjami, jak i mniejszymi indywidualnymi stronami internetowymi. I robię wiele recenzji kodu i recenzji witryn. Aż do tego roku nie widziałem wzrostu liczby ludzi, którym naprawdę zależy na tak bardzo, że ludzie są całkiem szczęśliwi, gdy otrzymują recenzję i po prostu wykonują pracę, którą im każesz. Więc jeśli dasz im kilka rekomendacji, po prostu je wykonają. Ale jeśli wrócę na stronę w przyszłym roku, dam im tylko kolejną garść rekomendacji. Tak więc bardzo dużo widziałem zmianę w tym ostatnim roku, kiedy ludzie naprawdę troszczyli się na tyle, by zadawać pytania. I tak dla mnie audyty kodu zostały wyrzucone w dużym, długim tutaj wierszu 6, 4, 2 tego pliku, bla, trzeba to zrobić w ten sposób.

Pozbyłem się tego wszystkiego i naprawdę zacząłem koncentrować się na edukacji i zdałem sobie sprawę, że, szczerze mówiąc, większość ludzi nie chce, żeby im powiedziano, trzeba naprawić tę linię, ale żeby im powiedziano, oto jak to naprawić każda linia, która tam jest. Tak więc dla mnie wielka zmiana i duża zmiana ukierunkowana była na edukację. I to jest coś, co dotyczy całej branży. Myślę, że w tym roku coraz więcej osób mówi o bezpieczeństwie niż w zeszłym i coraz więcej w poprzednich latach.

MODERATOR: Nie, to wspaniale. Naprawdę podoba mi się to skupienie się na przechodzeniu od dawania ci ryb do uczenia cię, jak łowić ryby. Więc to naprawdę-

TIM NASH: Za wszelką cenę starałem się uniknąć tej analogii za bycie frazesem.

MODERATOR: Dziękuję.

TIM NASH: po prostu dobrze zrobione.

MODERATOR: W porządku, Jimmy.

JIMMY SQUIRES: Tak, myślę, że jest tego tak dużo, że postanowiłem skupić się na jednej konkretnej rzeczy do omówienia w tej odpowiedzi. A to naprawdę ogranicza twój zakres, gdy masz do czynienia z tokenami API i dostępem. Myślę, że włamanie do repozytorium Heroku w GitHub w zeszłym roku było naprawdę dobrym przypomnieniem, że masz kontrolę tylko nad tak wieloma rzeczami. Kiedy więc pracujemy z naszymi programistami, przypominamy im o znaczeniu zasad dostępu o ograniczonym zakresie na dowolnej platformie lub systemie, z którym pracujesz. Wiele razy programista naprawdę chce dość szerokiego otwartego dostępu na wczesnym etapie rozwoju, tylko dla ułatwienia. A czasami rzeczy, do których prawdopodobnie wszyscy wstydzimy się przyznać, nie są dokręcane do poziomu, w jakim powinny być przed produkcją. Więc zaczynając wcześnie, naprawdę biorąc pod uwagę te zakresy bezpieczeństwa.

MODERATOR: Dziękuję, Jimmy. I Lawrence, wiem, że dużo pracujesz również z programistami. Więc po co wszyscy patrzycie z przodu?

LAWRENCE EDMONDSON: Tak, jasne. Aby oprzeć się na tym, co powiedział Jimmy, na pewno obaj pracujemy w reklamie. Myślę więc, że widzimy wiele takich samych wyzwań, gdy pracujesz w reklamie i pracujesz w środowisku produktowym. Jeśli chodzi o nas, dotykamy wielu różnych technologii, wielu różnych stosów technologii. Musimy być technicznie agnostykami. Widzimy więc, że konsumenci angażują się teraz na wiele sposobów za pośrednictwem urządzeń mobilnych i społeczności. Kilka lat temu komputer był głównym sposobem uzyskiwania dostępu do witryn i treści. Teraz jest całkowicie odwrócony. Przeszedł od komputerów stacjonarnych do urządzeń mobilnych, a teraz do mediów społecznościowych.

Dlatego twoje warstwy API i warstwy aplikacji muszą być zablokowane w sposób, który wiąże się z odrobiną zdrowej paranoi. Widzimy więc, że spektrum ataków rośnie, dlatego nieustannie szukamy nowych sposobów, aby DevOps myśleli jak programiści, aby rozumieli możliwe sposoby na włamania. Więc to jest coś, co robimy dzisiaj.

MODERATOR: Dziękuję za to. Wspomniałeś, jak rośnie wektor ataku. I to jest coś, co mamy tutaj, w WP Engine, przyjrzeliśmy się więcej temu, jak przyjąć mechanizm obrony w głąb. Więc nie ufaj żadnej warstwie, że jest bezpieczna. Jak więc włączyć to do sposobu, w jaki kodujesz i piszesz oprogramowanie. Więc dziękuję za to. Jak wszyscy mówiliście o zmieniającym się trendzie, który się tam dzieje, naruszeniach, które miały miejsce w zeszłym roku. Patrząc na rok 2023, jakie są główne tematy lub zagrożenia, na które wszyscy zwracacie uwagę? I może, Sergi, możesz zacząć od nas. Tak.

SERGI ISASI: Jasne. I to zabrzmi głupio, bo jest rok 2023 i powiem słowo DDOS, ale to wciąż coś. I to była naprawdę interesująca zmiana w ciągu ostatnich 9, 12 miesięcy w świecie DDOS. Wolumetryczny nie jest obecnie wektorem DDOS. Dużo mniej refleksji. A z punktu widzenia cyberprzestępcy łatwiej jest uruchomić atak DDOS, ponieważ masz do dyspozycji wiele gotowych narzędzi, prawda? Niemal wróciliśmy do dni TD skryptów, ale masz też o wiele mniej zainfekowanych systemów do zaatakowania. Więc jeśli próbujesz się zastanowić, nie ma zbyt wielu infrastruktur zarządzanych przez kogoś, kto mógł nie załatać swojego systemu, więc możesz wziąć jeden pakiet i zmienić go na 10. To już naprawdę nie jest ważne.

Przechodzą więc do warstwy 7. Uruchomienie warstwy 7 jest droższe, ponieważ wymaga do tego dużo procesora, ale jest też dużo droższe w łagodzeniu. Więc jeśli masz jakiś system ochrony DDOS, faktycznie musisz zaakceptować połączenie, zbadać je, a następnie zacząć je upuszczać w porównaniu z czymś, co możesz upuścić na niższą warstwę. Co znaleźliśmy i co złagodziliśmy w przypadku największego zgłoszonego DDOS warstwy 7 tylko w zeszłym miesiącu. Głównym tematem tych ataków są potężniejsze urządzenia.

Więc jeśli pomyślisz o wszystkich rzeczach, które podłączyliśmy w domu w tych dniach, procesor w tym urządzeniu jest znacznie lepszy niż jeszcze trzy lub cztery lata temu. Twój aparat potrafi znacznie więcej. Ma więc mocniejszy procesor, nawet twoje routery są w rzeczywistości dość mocną maszyną. A każdy kompromis w tych urządzeniach może pozwolić na duży, duży atak, zwłaszcza że jeśli naruszysz jedno, narazisz teraz zasadniczo wszystkie z nich, które są połączone.

Inną rzeczą, o której trochę rozmawiamy w tych dniach, ale jest trochę ciszej, jest to, że przeszliśmy od zaatakowanych urządzeń sprzętowych do zaatakowanych kont w usługach w chmurze. Usługi w chmurze mają faktycznie nieograniczony procesor. Więc jeśli mogę uzyskać dostęp do wielu kont osób fizycznych lub firm i uruchomić cokolwiek chcę w tym systemie chmurowym, mogę wtedy przeprowadzić bardzo duży atak. I to właśnie obserwujemy w rekordowych atakach. Więc tak, 2023, wciąż DDOS, wciąż coś, ale teraz na warstwie 7 w porównaniu z niższymi warstwami.

MODERATOR: Dziękuję. To przerażające, ale jednocześnie myślę, że wskazuje to na to, w jaki sposób nadal ulepszamy nasze protokoły bezpieczeństwa, a obszar zainteresowania nadal się rozwija. Wiem, Lawrence, rozmawialiśmy w przeszłości o sztucznej inteligencji jako o boomie i zagrożeniu. Chciałbym usłyszeć kilka twoich przemyśleń na temat generatywnej sztucznej inteligencji i tego, jak widzisz, że faktycznie wpływa to na obszar bezpieczeństwa w 2023 roku.

LAWRENCE EDMONDSON: Jestem więc bardzo podekscytowany i optymistycznie nastawiony do sztucznej inteligencji. Jesteśmy w Barbarzyńcy, ale jednocześnie jest to bardzo przerażające. Potencjał czegoś takiego jak chatGPT jest wykorzystywany w złośliwy sposób. Na przykład możesz poprosić GPT na czacie o komentowanie Twojego kodu. I faktycznie wykonuje całkiem przyzwoitą robotę, w zależności od języka i bałaganu w kodzie, wykonuje całkiem dobrą robotę. Myślę więc, że następną rzeczą, którą zobaczymy, będzie Czat GPT – i może to już być w toku, ponieważ każdego dnia Czat GPT to robi. Tak jak dzisiaj, właśnie zobaczyłem, że jest w stanie odpowiedzieć w Slack i znaleźć odpowiedzi w Slack.

Myślę więc, że następną rzeczą, jeśli chodzi o bezpieczeństwo, w Chat GPT jest znalezienie exploitów przez Chat GPT i faktyczne zapisanie kodu – złośliwego kodu, aby naprawdę wykorzystać znalezione słabości. Widzimy to, zwłaszcza potencjał tego w pamięci. Więc ataki na pamięć nie pozostawiają śladu przez cały czas. Tak więc tradycyjne wirusy i skanery antywirusowe pracują nad wyszukiwaniem sygnatur ataku. W ramach ataków na pamięć atakujesz aplikację. Robisz coś w rodzaju przepełnienia bufora. Chcesz skompromitować aplikację w czasie wykonywania. Myślę, że Chat GPT jest do tego gotowy. I myślę, że to tylko kwestia czasu, kiedy zobaczymy pierwszy exploit na ChatGPT na dużą skalę.

TIM NASH: Jak wyobrażałbyś sobie, że faktycznie tak się dzieje? Ponieważ oczywiście ChatGPT, w swej istocie, to tylko zestaw żądań API do serwera. I wysyłasz żądanie, które mówi: hej, wygeneruj dla mnie złośliwy kod. Zwraca to z powrotem. To znaczy, jest mnóstwo ludzi, którzy już generują złośliwy kod. Jak więc chcesz to zrobić, aby było gorsze niż złośliwy kod, który już istnieje?

LAWRENCE EDMONDSON: A więc dokładnie o to chodzi. Istnieje już duże repozytorium, z którego można się uczyć. Więc ChatGPT, to, co robi, tak naprawdę patrzy – musisz wytrenować model. Z biegiem czasu inżynierowie szkolą model, aby rozpoznawał, kiedy ktoś to mówi, tak naprawdę ma to na myśli. Więc zrozum kontekst. Czyli dokładnie tak, ale w inny sposób. Szkoli model, aby faktycznie pisał kod i co to właściwie oznacza. A niektóre języki są bardzo łatwe. Więc PHP, dość łatwo napisać kod w PHP. Te języki interpretowane są o wiele łatwiejsze. Jest to o wiele bardziej chaotyczne, ale w przeciwieństwie do robienia czegoś w stylu Java, które musi zostać skompilowane, wiesz, co mam na myśli?

Myślę więc, że łatwym sposobem na zrobienie tego byłoby stworzenie modelu opartego na chatGPT 3, w którym faktycznie go trenujesz - przechodzisz przez składnię, przechodzisz przez wszystkie podstawowe rzeczy z informatyki, a potem to robisz krok w górę i gotowe, OK, te pakiety NPM mają te exploity. Poszukaj go i znajdź sposób, aby rzeczywiście – mają te luki, przepraszam, i poszukaj sposobu na wykorzystanie tych luk. Gwarantuję, że nie jesteśmy zbyt daleko od zobaczenia czegoś takiego.

MODERATOR: Dziękuję, Lawrence. Myślę, że to bardzo rozwijający się obszar. Interesujące w tej przestrzeni jest to, że ogólnie rzecz biorąc, sztuczna inteligencja ma równowagę między tym, do czego można ją wykorzystać, niezależnie od tego, czy faktycznie używa się tych sygnatur, aby zapobiegać, i uczyć się na jej podstawie, aby zobaczyć, jak możesz nas powstrzymać pisanie słabego kodu lub podatnego na ataki kodu. A jednocześnie, podobnie jak widzieliśmy, jak ludzie rozmawiają o tym, hej, napisałem swoją pierwszą wtyczkę w ciągu pięciu minut z GPT na czacie, myślę – tak, bardziej chodzi o to, czy to zaczyna umożliwiać ludziom trochę tworzenie złośliwego oprogramowania szybciej? Ale myślę, że ma to obydwa aspekty.

Bardziej chodzi o to, jak nadal wykorzystywać którekolwiek z tych narzędzi, aby po prostu lepiej pisać kod, ale pisać bardziej bezpieczny kod. I wiem, Tim, że to dla ciebie obszar pasji. Czy chciałbyś porozmawiać trochę więcej o tym, jak widzisz ewolucję bezpiecznego kodu w 2023 roku i co robisz w tej przestrzeni?

TIM NASH: Cóż, pod wieloma względami Chat GPT jest tego dobrym przykładem. Jeśli myślałem o wektorze ataku, będę szczery, nie myślałem o masowym skanowaniu, karmieniu go wieloma rzeczami jako złym aktorem. Myślałem o tym jako o przeciętnym twórcy kodu, który próbował zaoszczędzić czas i wprowadzał rzeczy do Chat GPT i wyrzucał je i niekoniecznie w pełni rozumiał cały kod, który jest pisany, tworzony, nie napisał żadnych testów do idź z tym. To tylko szybka rzecz, to tylko szybki skrypt, wszystko jest w porządku. Dostaje się do produkcji, nie jest w porządku i wszystko się pali.

Teraz jest to dokładnie to samo, co każdy programista robi każdego dnia, niezależnie od tego. Czat GPT tego nie zmienia, ale umożliwia to nieco łatwiej. Daje – jest mniej barier.

SERGI ISASI: Tak, więc to nie do końca to samo, co kopiowanie i wklejanie ze Stack Overflow, do czego chyba się odwołujesz, Tim, czyli w zasadzie wszystko, co robię dla kodu. Ale myślę, że na pewno jest to wzrost wydajności, zarówno pozytywny, jak i negatywny. Ale myślę, że pozwala to na bardziej subtelne zmiany i szybsze wykorzystanie czegoś, czego silnik oparty na sygnaturach nie jest w stanie dogonić. Więc naprawdę, kiedy przeprowadzasz wykrywanie, potrzebujesz systemu, który mówi, czy to wygląda podobnie do czegoś, co widziałem w przeszłości, w przeciwieństwie do bezpośredniego dopasowania do czegoś, co widziałem w przeszłości. I to jest właściwie po stronie wykrywania, prawdopodobnie najlepiej obsługiwane przez ML lub AI, czy jakkolwiek chcesz to nazwać.

Nauczyliśmy się tego dzięki zautomatyzowanemu ruchowi, wiesz, zasadniczo botom. Najlepszym sposobem, aby dowiedzieć się, jak radzą sobie z wykrywaniem opartym na sygnaturach, jest uczenie maszynowe. Ale teraz przechodzisz od, absolutnie wiem, że to jest złe, do, cóż, prawdopodobnie zostanie zautomatyzowane lub prawdopodobnie będzie wyglądać jak podpis, który widziałem wcześniej, ale nie jest to dokładne dopasowanie.

MODERATOR: Cudownie. Dziękuję. Dzięki, Sergi i Tim za ten dodatkowy kontekst. Tak więc wśród naszych uczestników jest wielu programistów i agencji, które są tu dzisiaj obecne. Wiele osób myśli o ustanowieniu najlepszych praktyk, zwłaszcza że scenariusze zmieniają się pod względem wektorów zagrożeń. Jakie są więc najlepsze praktyki, które poleciłbyś podczas tworzenia witryny, aplikacji lub platformy lub gdy zaczynasz nowy projekt. Na co więc ludzie powinni zwracać uwagę?

SERGI ISASI: Więc mogę zacząć. Byłoby to bardziej po stronie operacyjnej niż rozwojowej. Myślę, że jedną z rzeczy, które tutaj głosimy, jest założenie, że wydarzy się coś złego. A więc nadchodzi wyłom, nie możesz tak po prostu być nim zaskoczonym. Możliwe, że kiedyś to nastąpi. A nasz klucz – więc po pierwsze, stwórz do tego księgę startową. Więc kiedy to się stanie, wiedz, z którymi osobami się skontaktować i jaka będzie twoja reakcja, zarówno od wykrycia, jak i odpowiedzi, ale także komunikuj się z klientami, jeśli ich to dotyczy. Pod tym względem rzecz, którą, jak sądzę, robimy bardzo dobrze w Cloudflare i jest to część naszej marki i myślę, że bardzo nam to służyło, to bycie szczerym, otwartym i tak komunikatywnym, jak to tylko możliwe, o czymkolwiek to się stało.

Otwartość była kluczem do przywrócenia zaufania klientów, gdy coś się wydarzy, niezależnie od tego, czy jest to naruszenie oprogramowania, czy jakiś błąd, który popełniłeś w związku z incydentem. Ukrywanie się za tym nigdy nie jest właściwym wyborem.

MODERATOR: Tak.

JIMMY SQUIRES: Myślę, że jest jeszcze coś innego – teraz, gdy wszyscy są oczywiście zdalni, a zwłaszcza w zespołach programistów, poświęcamy czas na początku projektu na wykonanie tablicy i planowanie architektoniczne. Tak łatwo jest zagłębić się w wymagania i zrzucić historie z rozwoju, ale spędzanie czasu z rówieśnikami, aby rzucić wyzwanie, jak można to wykorzystać? Przejrzyj scenariusze. Planujemy wiele scenariuszy, które prowadzą do wielu dobrych rozmów na temat tego, jak chcemy wzmocnić różne części aplikacji.

LAWRENCE EDMONDSON: Nie wiem, czy ktoś o tym wie, ale MPM jest w rzeczywistości największym repozytorium współdzielonych — to największe pojedyncze repozytorium bibliotek aplikacji, ale oznacza to również największe ryzyko. Tak więc jedną rzeczą, której jesteśmy bardzo świadomi, podejmując nowy projekt, jeśli używamy NPM, jest upewnienie się, że patrzymy na luki w zabezpieczeniach, że blokujemy wersje, które chcemy wyprodukować, zanim przeprowadzamy aktualizację, upewniamy się, że jest ona kompatybilna, ale także bardzo bezpieczna. Nie ma otwartych zagrożeń, ponieważ widzieliśmy wiele luk w zabezpieczeniach NPM. Więc to tylko jedna rzecz, na którą należy zwrócić uwagę.

TIM NASH: Myślę, że zapętlamy to dookoła.

JIMMY SQUIRES: Śmiało, Tim.

TIM NASH: Myślę, że zapętlamy to wszystko wokół idei, że tak naprawdę zaufanie jest całkowicie łamane w cyklach rozwojowych od lat. Ludzie dopiero teraz zaczynają to sobie uświadamiać. A jeśli jesteś programistą PHP pracującym na przykład w WordPressie, siedzisz tam, wywołując akcje i filtry, ale nie powinieneś ufać tym akcjom i filtrom. Wszelkie dane, które nadchodzą, powinniście zatwierdzać, powinniście to sprawdzać. Należy go zdezynfekować. Ale kiedy wychodzi z bazy danych, nadal nie powinieneś mu ufać.

Nawet jeśli umieściłeś te dane w bazie danych, nie powinieneś ufać danym, które wychodzą. Jeśli przekazujemy coś do biblioteki strony trzeciej, czy to NPM, czy to ten pakiet kompozytora, czy po prostu kolejna wtyczka WordPress, natychmiast opuszcza to naszą kontrolę i nie ufamy jej ponownie. Ale kiedy wraca, nawet jeśli to sprawdziliśmy, nadal mu nie ufamy. A jeśli jako programista wejdziesz z takim nastawieniem, że nie należy ufać każdej cząstce danych i należy ją całkowicie odizolować, a także przeprowadzać kontrole bezpieczeństwa w każdym danym momencie, dojdziesz do wniosku, że z dużo bezpieczniejszym systemem. Możesz wyjść z nieco wolniejszym systemem. Możesz natknąć się na nieco bardziej frustrujący system, który wymaga znacznie więcej testów, aby upewnić się, że to, co robisz, nie powoduje więcej problemów niż pomaga.

MODERATOR: Tak.

TIM NASH: Dodaj komplikacje, ale otrzymasz dużo bezpieczniejszy system. I dla większości ludzi właśnie tego chcą.

LAWRENCE EDMONDSON: Tak.

MODERATOR: Tak. Masz całkowitą rację. Chodzi o to, aby nie ufać żadnemu innemu fragmentowi kodu, który przechodzi. A o czym rozmawiali Jimmy i Sergi, to posiadanie planu z perspektywy architektury lub z perspektywy operacyjnej, ale połączenie tego wszystkiego w ogólną praktykę, niezależnie od tego, czy chodzi o mechanizmy bezpiecznego kodowania bezpieczeństwa, czy o podręcznik incydentów. Więc Tim, jestem bardzo zainteresowany, aby usłyszeć więcej od ciebie – dużo trenujesz, dużo nauczasz na całym świecie. Jakie są typowe błędy, które widzisz, gdy ludzie zaczynają pracować nad projektami, lub błędy, które mogłeś popełnić, popełniłem ich wiele.

TIM NASH: Chciałem powiedzieć, że jestem prawie pewien, że jestem winny każdego błędu, o którym mam zamiar mówić. A największym i najprostszym jest bycie miłą osobą. Większość programistów zakłada dobre intencje. Większość ludzi zakłada, że ​​zamierzasz używać ich aplikacji tak, jak napisałeś ich aplikację. Teraz dość często nie piszemy dokumentacji, więc użytkownik w ogóle nie ma pojęcia, jak korzystać z aplikacji, ale to osobna kwestia. Zły aktor wejdzie, weźmie każdy błąd i odejdzie, to nie jest błąd, dla złego aktora to cecha. To okazja. Robi coś, czego deweloper się nie spodziewa, dlatego istnieje potencjalna droga do tego.

I ogólnie rzecz biorąc, coś, co widzisz raz po raz, kiedy mówisz, och, spójrz, masz zestaw testów jednostkowych. Świetnie. Ale przetestowałeś tylko pozytywne rzeczy, wynik, którego chciałeś. Nie sprawdziłeś, co się stanie, jeśli wyjdziemy poza te granice. Właśnie przetestowałeś, aby upewnić się, że wszystko działa zgodnie z wymaganiami twojego szefa. Więc to, co naprawdę masz, to testy akceptacyjne, wątpliwe testy akceptacyjne. A potem wraca do wszystkich podstaw. Jako programista, jest to poparte tym, nie ufaj rzeczom. A jeśli jesteś w szczególności programistą WordPress, WordPress ma naprawdę dobre funkcje pomocnicze do wykonywania wszelkiego rodzaju standardowych rzeczy związanych z bezpieczeństwem, o które prosimy ludzi.

A chodzi o edukację i naukę korzystania z nich. Kiedy robię recenzje kodu, w kółko widzę te same problemy. A jeśli zobaczę to raz w fragmencie kodu, zobaczę to 1000 razy w tym samym zestawie kodu. I będą to rzeczy w stylu: no cóż, po prostu zezwoliliśmy na pojawianie się starych rzeczy na stronie. Nie zawracaliśmy sobie głowy sprawdzaniem, czy coś tam jest. Tak, umieszczamy rzeczy w bazie danych. Och, spójrz, może to wyglądać jak zapytanie SQL, może nie.

Wszystkie tego rodzaju rzeczy można łatwo naprawić, a my już daliśmy narzędzia do naprawy. A powodem, dla którego ich nie naprawiamy, często nie jest nawet to, że ludzie nie wiedzą, że nie powinni dopuścić do takich rzeczy, po prostu stajemy się leniwi, robimy rzeczy szybko, pobieramy kod ze Stack Overflow, namawiamy Czat GPT, aby coś dla nas robił, nie sprawdzamy wszystkiego. I wiele problemów związanych z bezpieczeństwem wynika z tego stanu, muszę się spieszyć. Muszę się spieszyć. Muszę się spieszyć, muszę to załatwić. Przechodzę do następnej rzeczy, przechodzę do następnej rzeczy.

Tak dziwnie, dla wielu programistów, właściwie po prostu dając im czas i przestrzeń i mówiąc, że można poświęcić trochę czasu, aby faktycznie sprawdzić, co zrobiłeś, aby kiedy to się skończy - i w przypadkach, w których wchodzę do gry, Wracam i mówię, cóż, wszystkie te rzeczy i programiści wyglądają na zakłopotanych. Idą, tak, wiemy to wszystko. Po prostu nie mieliśmy czasu.

Miejmy nadzieję, że dając ludziom więcej czasu i faktycznie dając im narzędzia, które już mamy, szczególnie w WordPress. WordPress ma naprawdę genialny zestaw funkcji pomocniczych dla najczęstszych problemów z bezpieczeństwem, które można napotkać we wtyczce lub motywie WordPress. Więc chodzi tylko o nauczenie się ich, a następnie zainwestowanie czasu w faktyczne ich wdrożenie.

MODERATOR: Tak. I myślę, że to naprawdę potężne, zainwestuj czas. Najczęściej programiści wiedzą, co należy naprawić. Więc daj im czas. Więc naprawdę podoba mi się ta wiadomość. I Jimmy, wiem, że wprowadziłeś to do własnego przepływu pracy w swojej agencji. Chcesz porozmawiać nieco więcej o praktykach bezpiecznego przepływu pracy, które wdrożyłeś?

JIMMY SQUIRES: Tak, absolutnie. I tak naprawdę zaczyna się od posiadania czegoś, co według Sergi jest planem, a właściwie wytycznymi i standardami, których zespół programistów ma przestrzegać. Wiem, że to brzmi prawdopodobnie bardzo prosto, ale widziałem wiele organizacji i słyszałem od wielu inżynierów, których zatrudnialiśmy przez lata, że ​​one nie istniały. W miejscu pracy, z którego pochodzili, nie było organizacji.

Więc to, co lubimy robić, to mieć standardowy zestaw wytycznych, z którymi wszyscy nasi nowi inżynierowie muszą zapoznać się od początku do końca. Nie jest tak ciężki, że nie nadaje się do spożycia. Lubimy przechowywać to w markdown, więc wszystko jest w repozytorium. Prawdopodobnie w pewnym momencie otworzymy źródło. Nie ma tam nic, co byłoby naprawdę zastrzeżone, dlatego zachęcamy wszystkich do współtworzenia tego. To pytanie do wszystkich inżynierów.

Więc nawet w naszych wytycznych rób dziury w miejscach, w których możemy coś dodać, gdzie możemy być lepsi, stale to zwiększając. Ale spędzanie czasu z niektórymi podstawowymi rzeczami, takimi jak OWASP, to naprawdę stara praktyka, ale przechodzenie przez to z twoją aplikacją, biorąc pod uwagę te rzeczy. To trochę tak, jak powiedział Tim, to naprawdę wymaga czasu i jest w porządku, aby poświęcić na to czas. Chciałem dodać jeszcze jeden punkt z powrotem do rozmowy AI. Rozmowa z kilkoma naszymi inżynierami w zeszłym tygodniu rzeczywiście miała miejsce. To jest coś, do czego używamy Czatu GPT, tak naprawdę do testów jednostkowych. Biorąc funkcję i eksplorując ją w interesujący sposób, jak możesz wykorzystać coś takiego jak Chat GPT do napisania testu jednostkowego, w którym nie będziesz najlepszym autorem tego testu jednostkowego, do punktu Tima. Myślę, że w tym miejscu możemy znacznie bardziej wykorzystać sztuczną inteligencję w sposób zapobiegawczy.

LAWRENCE EDMONDSON: Tak. To, co robimy po naszej stronie, myślę, że listy kontrolne i podręcznik są świetne. Używamy zautomatyzowanych narzędzi, takich jak SonarQube, i naprawdę stosujemy linting i tym podobne rzeczy, tylko po to, aby podnieść jakość kodu za pomocą lintingu, ale używamy również SonarQube, aby upewnić się, że kod jest bezpieczniejszy, że szukamy za luki w zabezpieczeniach i takie tam. Myślę, że w niektórych językach łatwiej niż w innych znaleźć exploity, jak wspomniałem wcześniej, tylko ze względu na naturę języka. A także tylko niektóre frameworki, w których zazwyczaj jakość koderów, którzy przyczyniają się do tej bazy kodu – zwykle widzimy to w przypadku Open Source, gdzie jest tak po prostu – dzieje się dużo kopiowania i wklejania przepełnienia stosu, w przeciwieństwie do ludzi, którzy faktycznie studiowali CS i naprawdę wiedzą, co robią. Więc to tylko jedna rzecz, którą widziałem.

TIM NASH: Wydaje mi się, że powinniśmy zaznaczyć, z pewnością dla mnie, że używam Stack OverFlow prawie codziennie. I tak wszyscy jesteśmy temu winni. Dobrze jest na to narzekać, ale nie sądzę – to znaczy pamiętam, kiedy po raz pierwszy zacząłem kodować. Dostałem magazyn i wpisywałem kod z magazynu i naciskałem Enter. Nie wyobrażam sobie, aby sieć naprawdę działała dzisiaj, gdybyśmy nadal to robili i nie mieli przepełnienia stosu lub podobnego.

Sergi: Nie, to przyspieszacz. I miejmy nadzieję, że sztuczna inteligencja jest kolejnym etapem tego. Ale tak, to zabawny mem.

MODERATOR: Dziękuję. Więc trochę się przesunie. W branży wdrożeń Headless i Headless dzieje się dużo. Widzieliśmy również w niektórych naszych innych kanałach dzisiejsze lub inne sesje mówiące o Headless. Więc kiedy zaczęliśmy pracować z Atlasem w WP Engine, spotkaliśmy się z wieloma programistami, a bezpieczeństwo zawsze było kluczowym czynnikiem motywującym. Jak więc postrzegasz bezpieczeństwo w Headless? I wiem, Jimmy, że jest to obszar, w którym zrobiłeś wokół niego kilka projektów. Chcielibyśmy poznać Twoje zdanie na ten temat.

JIMMY SQUIRES: Tak, dużo pracujemy w Headless. Myślę, że prawie wszystkie nasze projekty w tym momencie prawdopodobnie opierają się na architekturze Headless. Myślę, że chcę poruszyć kilka kwestii związanych z bezpieczeństwem. Myślę więc, że po pierwsze, wybierając architekturę Headless, na początku stawiasz się bardziej w obozie open source. I oczywiście toczy się wiele dyskusji na temat tego, co jest bardziej bezpieczne, otwarte lub zamknięte źródło. Zwykle zaliczam się do obozu projektów OSS, które są z natury bardziej bezpieczne. Więc wybierasz frameworki takie jak Next, WordPress, gdzie masz ogromną społeczność. A to zwykle zapewnia większe bezpieczeństwo poprzez samą ekspozycję.

Więc myślę, że to jeden. Myślę, że drugie to coś w rodzaju generowania statycznego. Tak więc wiele stron internetowych i produktów, które są budowane, nie potrzebuje dynamicznego charakteru dużego zarządzania treścią, monolitycznego systemu w tradycyjnym tego słowa znaczeniu. Możesz wykorzystać coś takiego jak Cloudflare i naprawdę statycznie generować duże części tej aplikacji, zmniejszając w ten sposób ślad dla wektorów i ekspozycji. Więc jesteśmy wielkimi fanami tego. A potem, oczywiście, zyskujesz dzięki temu wszystkie korzyści związane z wydajnością. To tylko kilka punktów, które chciałem poruszyć na temat architektury Headless. Ale z punktu widzenia bezpieczeństwa jest o wiele więcej powodów, dla których to lubimy. Ale myślę, że to prawdopodobnie dwa najbardziej wyróżniające się obszary.

TIM NASH: Chciałbym po prostu cofnąć się i przypomnieć ludziom, że z tyłu nadal istnieje system zarządzania treścią. Zbyt często słyszę, że Headless jest całkowicie bezpieczny. To tak, ale ta odsłonięta instancja WordPressa, która wciąż tam siedzi, tylko dlatego, że nie wywołujesz jej bezpośrednio ze strony internetowej, tak, wciąż tam jest na stronie admin.yoursite.com. A ty nie – istnieje pewne przekonanie, że, o tak, cóż, jesteśmy teraz bezpieczni, więc nie musimy się martwić o aktualizowanie, ponieważ to nie jest strona internetowa. To jest tak, że nie, nie, nadal potrzebujesz wszystkich rzeczy, które robiłeś wcześniej, a teraz mamy też drugą stronę.

Mam na myśli, że Headless to świetne określenie na coś, co istnieje od dłuższego czasu i nabiera rozpędu, ale robiliśmy to jeszcze zanim WordPress miał REST API. Wypychaliśmy treści z WordPressa do rzeczy takich jak Jekyll, aby uzyskać przynajmniej statyczną stronę. Pierwotnym powodem tego było zróżnicowanie systemu WordPress lub systemu zarządzania treścią w sieci. Więc możesz go zablokować i trzymać z dala od wielkiej, przerażającej sieci.

Teraz otrzymujemy wiele firm hostingowych, które dostarczają rozwiązania Headless. 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. Dziękuję. 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.