Cara Tetap Terjaga di Tahun 2023

Keamanan dan kinerja adalah landasan untuk setiap proyek, situs, aplikasi, dan komponen yang Anda kembangkan. Namun dalam lanskap yang terus berubah ini, mungkin sulit untuk tetap mengikuti praktik terbaik fundamental, sekaligus berinovasi.

Dalam percakapan ini, dengarkan dari para teknolog terkemuka tentang bagaimana mereka tetap di atas keamanan dan kinerja pada tahun 2023.

Pembicara:

• Ramadass Prabhakar, SVP dan Chief Technology Officer di WP Engine
• Lawrence Edmondson, CTO di Barbarian
• Sergi Isasi, Produk VP, Performa Aplikasi di Cloudflare
• Tim Nash, Konsultan Keamanan WordPress di timnash.co.uk
• Jimmy Squires, CTO di space150

Salinan:

RAMADASS: Halo semuanya. Selamat datang di Decode edisi keempat. Sungguh luar biasa melihat pertumbuhan peserta setiap tahun. Selama beberapa tahun terakhir, telah terjadi perubahan signifikan dalam lanskap keamanan di seluruh industri. Kami telah melihat buletin berita reguler tentang pelanggaran keamanan dan keamanan sebagai topik yang sering muncul dalam diskusi dengan pelanggan dan pengembang. Jadi hari ini, kami telah mengumpulkan sekelompok pakar industri luar biasa yang sangat menyukai keamanan dan hadir untuk menjawab pertanyaan kami dan berbagi pembelajaran mereka dengan kami. Jadi mari kita mulai dengan pengenalan singkat kepada panelis kita. Lawrence, untukmu.

LAWRENCE EDMONDSON: Terima kasih banyak telah mengundang kami. Lawrence Edmondson di sini, CTO dari Barbarian. Barbarian adalah agen digital layanan penuh. Kami berlokasi di New York.

RAMADASS: Terima kasih, Lawrence. Kepadamu, Sergi.

SERGI ISASI: Terima kasih. Saya seorang VP produk di Cloudflare. Cloudflare, kami membangun produk yang membuat pelanggan dan mitra kami, seperti WPE, terhubung ke internet lebih aman dan lebih cepat dan saya berada di San Francisco.

MODERATOR: Terima kasih, Sergi. Dan Tim, untukmu.

TIM NASH: Saya seorang konsultan keamanan WordPress di Inggris. Dan saya pada dasarnya menghabiskan hidup saya untuk menakut-nakuti pengembang.

MODERATOR: Terima kasih. Dan Jimmy.

JIMMY SQUIRES: Ya, terima kasih. Saya bersama Space 150, juga agen digital layanan lengkap dari Minneapolis dan CTO di sana.

MODERATOR: Terima kasih telah setuju untuk hadir di panel kami hari ini. Jadi saya ingin memulai dengan berbicara tentang sesuatu yang unik yang Anda lakukan dalam keamanan hari ini di dalam organisasi Anda, atau di dalam tim Anda. Jadi mungkin mari kita mulai dengan Sergi.

SERGI ISASI: Ya, saya akan memainkan intro Tim, di mana dia menakuti pengembang. Salah satu hal yang kami coba lakukan lebih banyak di Cloudflare adalah memberi pelanggan kami lebih banyak wawasan tentang lalu lintas mereka dan mengurangi beban operasional. Jadi secara historis, jika Anda ingin menemukan apa yang mungkin memengaruhi jaringan Anda, serangan apa yang mungkin Anda lihat, Anda akan menggunakan WAF, Anda akan memasukkannya ke mode log dan Anda kemudian akan meminta analis keamanan melihat log dan melihat apa yang terdeteksi. Dan ada lebih sedikit sumber daya untuk melakukannya akhir-akhir ini.

Jadi fokus kami untuk tahun ini adalah memberikan wawasan kepada pelanggan kami tentang serangan yang kami lihat pada mereka, bahkan jika mereka tidak menggunakan produk yang akan mencegah serangan itu hari ini. Sehingga mereka dapat mengetahui apakah atau aplikasi mereka sedang diserang, atau secara umum dalam kondisi baik. Dan itulah fokus kami untuk sisa tahun ini, memperkenalkan semua produk keamanan kami dan memberi tahu pelanggan kami apa yang mungkin terjadi atau apa yang sebenarnya terjadi di jaringan mereka dan apakah mereka ingin memblokirnya atau tidak.

MODERATOR: Luar biasa. Kedengarannya sangat kuat. Saya menantikan untuk mendengar lebih banyak tentang itu. Jadi Tim, bagaimana dengan dirimu sendiri?

TIM NASH: Jadi saya bekerja dengan banyak klien berbeda, baik agensi, tetapi juga situs web individu yang lebih kecil. Dan saya melakukan banyak review kode dan review situs. Dan hingga tahun ini, saya belum melihat pertumbuhan orang yang benar-benar peduli sehingga orang cukup senang mendapatkan ulasan dan hanya melakukan pekerjaan yang Anda perintahkan. Jadi jika Anda memberi mereka banyak rekomendasi, mereka akan mengikutinya. Tapi kemudian jika saya kembali ke situs itu tahun depan, saya hanya memberi mereka banyak rekomendasi. Jadi saya telah melihat banyak perubahan dalam tahun terakhir ini dari orang-orang yang benar-benar cukup peduli untuk mengajukan pertanyaan. Jadi bagi saya, audit kode telah dibuang di baris besar, panjang di sini 6, 4, 2 dari file ini, bla, perlu dilakukan seperti ini.

Saya telah menyingkirkan semua itu dan benar-benar mulai berfokus pada pendidikan dan menyadari bahwa, sejujurnya, yang diinginkan kebanyakan orang bukanlah diberitahu, Anda harus memperbaiki baris ini, tetapi untuk diberi tahu, inilah cara memperbaikinya setiap baris yang ada di sana. Jadi bagi saya, perubahan besar dan perubahan fokus besar adalah ke arah pendidikan. Dan ini adalah sesuatu yang mencakup seluruh industri. Saya pikir semakin banyak orang berbicara tentang keamanan tahun ini daripada tahun lalu dan semakin banyak dari tahun-tahun sebelumnya.

MODERATOR: Tidak, itu luar biasa. Saya sangat suka fokus beralih dari memberi Anda ikan menjadi mengajari Anda cara menangkap ikan. Jadi itu benar-

TIM NASH: Saya berusaha menghindari analogi itu dengan segala cara karena dianggap klise.

MODERATOR: Terima kasih.

TIM NASH: bagus sekali.

MODERATOR: Baiklah, Jimmy.

JIMMY SQUIRES: Ya, saya pikir ada begitu banyak, saya memutuskan untuk fokus pada satu hal yang sangat spesifik untuk dibicarakan untuk jawaban ini. Dan itu benar-benar membatasi ruang lingkup Anda saat Anda berurusan dengan token dan akses API. Saya pikir pelanggaran repositori Heroku, GitHub tahun lalu adalah pengingat yang sangat bagus bahwa Anda hanya mengendalikan banyak hal. Jadi saat kami bekerja dengan pengembang kami, ingatkan mereka pentingnya kebijakan akses terbatas pada platform atau sistem apa pun yang mungkin Anda gunakan. Sering kali, pengembang benar-benar menginginkan akses terbuka yang cukup luas di awal pengembangan hanya untuk kemudahan. Dan kadang-kadang hal-hal yang mungkin kita semua malu untuk akui itu tidak diperketat ke tingkat yang seharusnya sebelum produksi. Jadi mulailah lebih awal dengan benar-benar mempertimbangkan cakupan keamanan tersebut.

MODERATOR: Terima kasih, Jimmy. Dan Lawrence, saya tahu Anda juga banyak bekerja dengan pengembang. Jadi apa yang kalian semua cari di depan itu?

LAWRENCE EDMONDSON: Ya, tentu. Hanya untuk mengembangkan apa yang dikatakan Jimmy, tentu saja, kami berdua bekerja di bidang periklanan. Jadi menurut saya kita melihat banyak tantangan yang sama saat Anda bekerja di periklanan versus bekerja di lingkungan produk. Bagi kami, kami menyentuh banyak teknologi berbeda, banyak kumpulan teknologi berbeda. Secara teknis kita harus agnostik. Jadi yang kami lihat adalah konsumen terlibat dalam berbagai cara sekarang melalui seluler dan sosial. Beberapa tahun yang lalu, desktop adalah sarana utama untuk mengakses situs dan konten. Sekarang benar-benar terbalik. Itu beralih dari desktop ke seluler, sekarang, sosial.

Jadi karena itu, lapisan API Anda dan lapisan aplikasi Anda harus dikunci dengan cara yang memiliki sedikit paranoia sehat yang terkait dengannya. Jadi yang kami lihat adalah spektrum serangan berkembang sehingga kami terus mencari cara baru untuk membuat DevOps berpikir seperti pemrogram sehingga mereka memahami cara yang mungkin untuk dilanggar. Jadi itulah yang kami lakukan hari ini.

MODERATOR: Terima kasih untuk itu. Dan Anda menyebutkan bagaimana vektor serangan meningkat. Dan itu adalah sesuatu yang kami miliki di sini, di WP Engine, telah melihat lebih banyak dari bagaimana Anda mengadopsi mekanisme pertahanan secara mendalam. Jadi jangan percaya lapisan apa pun untuk aman. Jadi bagaimana Anda memasukkannya ke dalam cara Anda membuat kode dan cara Anda menulis perangkat lunak. Jadi terimakasih untuk itu. Seperti yang Anda semua bicarakan tentang tren perubahan yang terjadi di sana, pelanggaran yang terjadi dalam setahun terakhir ini. Jadi saat Anda melihat tahun 2023, apa saja tema atau ancaman utama yang Anda semua perhatikan? Dan mungkin, Sergi, Anda bisa memulai kami. Ya.

SERGI ISASI: Tentu. Dan ini akan terdengar konyol karena ini tahun 2023 dan saya akan mengucapkan kata DDOS, tapi tetap saja. Dan itu benar-benar merupakan perubahan yang menarik dalam sembilan, 12 bulan terakhir di dunia DDOS. Volumetrik bukanlah vektor DDOS saat ini. Ada jauh lebih sedikit refleksi. Dan dari sudut pandang aktor ancaman, meluncurkan DDOS lebih mudah karena Anda memiliki banyak alat siap pakai, bukan? Kami hampir kembali ke hari skrip TD, tetapi Anda juga memiliki lebih sedikit sistem yang disusupi untuk diserang. Jadi jika Anda mencoba melakukan refleksi, tidak banyak infrastruktur yang dikelola oleh seseorang yang mungkin belum menambal sistemnya, jadi Anda dapat mengambil satu paket dan mengubahnya menjadi 10. Itu bukan hal yang penting lagi.

Jadi mereka pindah ke lapisan 7. Dan lapisan 7 lebih mahal untuk diluncurkan karena Anda membutuhkan banyak CPU untuk melakukannya, tetapi juga jauh lebih mahal untuk dikurangi. Jadi jika Anda memiliki semacam sistem perlindungan DDOS, Anda benar-benar harus menerima koneksi, memeriksanya, lalu mulai menjatuhkannya versus sesuatu yang dapat Anda jatuhkan di lapisan bawah. Apa yang kami temukan dan kami memitigasi DDOS Lapisan 7 terbesar yang dilaporkan bulan lalu dalam catatan. Tema besar pada serangan tersebut adalah perangkat yang lebih kuat.

Jadi jika Anda memikirkan tentang semua hal yang telah kami pasang di rumah akhir-akhir ini, prosesor pada perangkat tersebut jauh lebih baik daripada tiga atau empat tahun yang lalu. Jadi kamera Anda melakukan lebih banyak lagi. Jadi ada CPU yang lebih kuat, bahkan router Anda sebenarnya adalah mesin yang cukup kuat. Dan penyusupan apa pun ke perangkat tersebut dapat memungkinkan terjadinya serangan yang sangat besar, terutama karena, jika Anda menyusupkan satu, pada dasarnya Anda mengkompromikan semua yang terhubung.

Hal lain yang sedikit kami bicarakan akhir-akhir ini, tetapi sedikit lebih sepi adalah, kami telah beralih dari perangkat keras yang disusupi ke akun yang disusupi di layanan cloud. Layanan cloud memiliki CPU yang tidak terbatas secara efektif. Jadi jika saya bisa mendapatkan akses ke sejumlah akun individu atau perusahaan dan memutar apa pun yang saya inginkan di sistem cloud itu, saya kemudian dapat meluncurkan serangan yang sangat besar. Dan itulah yang kami lihat pada serangan pemecah rekor. Jadi ya, 2023, masih DDOS, masih ada, tapi sekarang di lapisan 7 versus lapisan bawah.

MODERATOR: Terima kasih. Itu menakutkan, tetapi juga pada saat yang sama, menurut saya ini menunjukkan bagaimana kami terus meningkatkan protokol keamanan kami dan area fokus terus berkembang. Saya tahu, Lawrence, Anda dan saya telah mengobrol di masa lalu tentang AI sebagai ledakan dan ancaman. Saya ingin mendengar beberapa pemikiran Anda tentang AI generatif dan bagaimana Anda melihatnya benar-benar memengaruhi area permukaan keamanan pada tahun 2023.

LAWRENCE EDMONDSON: Jadi saya sangat bersemangat, sangat bersemangat tentang AI. Kami berada di Barbar, tetapi pada saat yang sama, itu sangat menakutkan. Potensi sesuatu seperti chatGPT digunakan dengan cara jahat. Misalnya, Anda dapat membuat Chat GPT mengomentari kode Anda. Dan itu sebenarnya melakukan pekerjaan yang cukup baik, tergantung pada bahasa apa dan seberapa berantakan kode Anda, itu melakukan pekerjaan yang cukup bagus. Jadi hal berikutnya, menurut saya, kita akan lihat adalah untuk Chat GPT– dan ini mungkin sudah berjalan karena setiap hari, sepertinya, Chat GPT melakukan ini. Seperti hari ini, saya baru saja melihatnya dapat merespons di Slack dan menemukan jawaban di Slack.

Jadi menurut saya hal berikutnya, dalam hal keamanan, di Chat GPT adalah membuat Chat GPT menemukan eksploit dan benar-benar menulis kode ke– kode berbahaya untuk benar-benar mengeksploitasi kelemahan yang ditemukannya. Jadi kami melihat itu, terutama potensi untuk itu dalam ingatan. Jadi serangan memori tidak selalu meninggalkan tanda tangan. Jadi virus tradisional dan pemindai virus, mereka bekerja mencari tanda tangan serangan. Dalam serangan memori, Anda menyerang aplikasi. Anda melakukan sesuatu seperti buffer overflow. Anda ingin mengkompromikan aplikasi saat runtime. Saya pikir saya pikir Chat GPT sebenarnya siap untuk melakukan itu. Dan saya pikir itu hanya masalah waktu sampai kita melihat eksploitasi ChatGPT skala besar pertama terjadi.

TIM NASH: Bagaimana Anda membayangkan hal itu benar-benar terjadi? Karena jelas ChatGPT, pada intinya, hanyalah sekumpulan permintaan API ke server. Dan Anda mengirimkan permintaan yang mengatakan, hei, buatkan saya beberapa kode berbahaya. Ini mengembalikannya kembali. Maksud saya, sudah banyak orang yang membuat kode berbahaya. Bagaimana Anda kemudian membuatnya menjadi lebih buruk daripada kode berbahaya yang sudah ada?

LAWRENCE EDMONDSON: Jadi itu persisnya. Sudah ada repositori besar untuk dipelajari. Jadi ChatGPT, apa fungsinya, sebenarnya terlihat– Anda harus melatih modelnya. Jadi seiring waktu, para insinyur melatih model untuk mengenali ketika seseorang mengatakan ini, ini sebenarnya yang mereka maksud. Jadi pahami konteksnya. Jadi persis seperti itu, tetapi dengan cara yang berbeda. Ini melatih model untuk benar-benar menulis kode dan apa artinya sebenarnya. Dan beberapa bahasa sangat mudah. Jadi PHP, cukup mudah untuk menulis kode di PHP. Bahasa yang ditafsirkan ini jauh lebih mudah. Ini jauh lebih berantakan, tetapi dibandingkan melakukan sesuatu seperti Java, yang harus dikompilasi, Anda tahu maksud saya?

Jadi menurut saya cara mudah untuk melakukannya adalah dengan membuat model berdasarkan chatGPT 3 yang sebenarnya, Anda melatihnya untuk benar-benar– Anda melewati hal-hal sintaksis, Anda mempelajari semua hal ilmu komputer dasar dan kemudian Anda mengambilnya selangkah lebih maju, oke, paket NPM ini memiliki eksploit ini. Cari dan cari cara untuk benar-benar– mereka memiliki kerentanan ini, maaf, dan cari cara untuk mengeksploitasi kerentanan tersebut. Saya jamin, kita tidak terlalu jauh dari melihat hal seperti itu terjadi.

MODERATOR: Terima kasih, Lawrence. Saya pikir ini adalah area yang sangat baru lahir. Yang menarik di ruang ini adalah bahwa dengan AI, secara umum, ia memiliki keseimbangan dari apa yang dapat Anda manfaatkan, apakah benar-benar menggunakan tanda tangan ini untuk mencegah dan belajar darinya untuk melihat bagaimana Anda dapat mencegah kami dari menulis kode yang buruk atau kode yang rentan. Dan pada saat yang sama, seperti yang telah kita lihat yang dibicarakan orang, hei, saya menulis plugin pertama saya dalam lima menit dengan Chat GPT, menurut saya– ya, ini lebih tentang apakah ini mulai memungkinkan orang untuk membuat malware sedikit lebih cepat? Tapi saya pikir itu punya kedua aspek itu.

Ini lebih tentang bagaimana Anda terus memanfaatkan salah satu alat ini untuk menjadi lebih baik dalam menulis kode, tetapi menulis kode yang lebih aman. Dan saya tahu, Tim, itu adalah bidang yang Anda sukai. Apakah Anda ingin berbicara lebih banyak tentang bagaimana Anda melihat Kode Aman berkembang pada tahun 2023 dan apa yang Anda lakukan di ruang itu?

TIM NASH: Maksud saya, dalam banyak hal Chat GPT adalah contoh yang bagus untuk itu. Jika saya memikirkan vektor serangan, saya akan jujur, saya tidak berpikir untuk melakukan pemindaian massal, memberinya banyak hal sebagai aktor yang buruk. Saya menganggapnya sebagai pengembang kode rata-rata yang mencoba menghemat waktu dan memasukkan barang ke dalam Chat GPT dan membuangnya dan belum tentu sepenuhnya memahami semua kode yang sedang ditulis, diproduksi, belum menulis tes apa pun untuk pergi dengan itu. Ini hanya hal yang cepat, ini hanya skrip cepat, semuanya baik-baik saja. Itu masuk ke produksi, tidak baik dan semuanya terbakar.

Sekarang ini persis sama dengan sesuatu yang dilakukan setiap pengembang setiap hari, terlepas dari itu. Obrolan GPT tidak mengubah itu, tetapi mengaktifkannya sedikit lebih mudah. Itu memang memberi– ada lebih sedikit hambatan.

SERGI ISASI: Ya, jadi tidak persis sama dengan menyalin dan menempel dari seperti Stack Overflow, yang menurut saya adalah yang Anda maksud, Tim, yang pada dasarnya hanya saya lakukan untuk kode. Tapi saya pikir ini adalah peningkatan efisiensi, baik untuk positif maupun negatif. Tapi saya pikir itu memungkinkan untuk perubahan yang lebih halus dan eksploitasi lebih cepat dari sesuatu yang lebih dari mesin berbasis tanda tangan tidak bisa benar-benar mengejar. Jadi Anda benar-benar saat melakukan pendeteksian, perlu memiliki sistem yang mengatakan, apakah ini terlihat mirip dengan sesuatu yang pernah saya lihat di masa lalu, berbeda dengan pencocokan langsung dengan sesuatu yang pernah saya lihat di masa lalu. Dan itu sebenarnya di sisi deteksi juga mungkin paling baik disajikan dengan ML atau AI atau apa pun yang Anda ingin menyebutnya.

Kami telah mempelajari bahwa dengan lalu lintas otomatis aktif, Anda tahu, pada dasarnya bot. Cara terbaik untuk mempelajari cara mereka menyiasati deteksi berbasis tanda tangan adalah dengan ML. Tapi Anda sekarang beralih dari, saya benar-benar tahu bahwa ini buruk, ke, yah, kemungkinan besar otomatis, atau mungkin terlihat seperti tanda tangan yang pernah saya lihat sebelumnya, tetapi tidak sama persis.

MODERATOR: Luar biasa. Terima kasih. Terima kasih, Sergi dan Tim untuk konteks tambahan itu. Jadi di antara peserta kami, kami memiliki banyak pengembang dan agensi yang hadir di sini hari ini. Dan banyak orang berpikir untuk membangun praktik terbaik, terutama karena skenario berubah dalam hal vektor ancaman. Jadi, apa saja praktik terbaik yang akan Anda rekomendasikan saat membuat situs, aplikasi, atau platform, atau saat Anda memulai proyek baru. Jadi, apa saja hal-hal yang harus diwaspadai oleh orang-orang?

SERGI ISASI: Jadi saya bisa memulainya. Itu akan lebih pada sisi operasional daripada sisi pengembangan. Saya pikir salah satu hal yang kami khotbahkan di sini adalah, satu, berasumsi bahwa sesuatu yang buruk akan terjadi. Jadi pelanggaran akan datang, Anda tidak bisa begitu saja dikejutkan olehnya. Itu mungkin terjadi di beberapa titik. Dan kunci kami– jadi, satu, buat buku lari untuk itu. Jadi ketika itu terjadi, ketahuilah individu mana yang harus dihubungi dan apa tanggapan Anda, baik dari deteksi dan tanggapan, tetapi juga berkomunikasi dengan pelanggan Anda jika hal itu memengaruhi mereka. Dan pada akhirnya, hal yang kami, menurut saya, lakukan dengan sangat baik di Cloudflare dan itu telah menjadi bagian dari merek kami dan menurut saya itu sangat membantu kami adalah bersikap terbuka, terbuka, dan sekomunikatif mungkin tentang apa pun. yang terjadi.

Keterbukaan telah menjadi kunci untuk membangun kembali kepercayaan dengan pelanggan ketika sesuatu benar-benar terjadi, apakah itu pelanggaran perangkat lunak atau kesalahan yang Anda buat dalam suatu insiden. Bersembunyi di baliknya bukanlah keputusan yang tepat.

MODERATOR: Yap.

JIMMY SQUIRES: Saya pikir ada hal lain yang juga kami miliki– sekarang semua orang jelas jauh dan terutama di tim pengembangan, sebenarnya meluangkan waktu pada awal proyek untuk melakukan perencanaan papan tulis dan arsitektur. Sangat mudah untuk menyelami persyaratan dan membuat cerita pengembangan, tetapi menghabiskan waktu bersama rekan Anda untuk menantang bagaimana hal ini dapat dieksploitasi? Jalankan melalui skenario. Kami melakukan banyak perencanaan skenario yang mengarah ke banyak percakapan yang baik dengan, bagaimana kami ingin menopang bagian aplikasi yang berbeda.

LAWRENCE EDMONDSON: Dan hanya tentang itu, saya tidak tahu apakah ada yang tahu, tetapi MPM sebenarnya adalah repositori terbesar dari shared– ini adalah satu-satunya repositori perpustakaan aplikasi terbesar di luar sana, tetapi itu berarti itu juga menimbulkan risiko terbesar. Jadi satu hal yang sangat kami sadari saat mengerjakan proyek baru jika kami menggunakan NPM adalah memastikan bahwa kami melihat kerentanannya, bahwa kami mengunci versi yang kami dorong untuk diproduksi, sebelum kami sedang melakukan pembaruan, kami memastikan bahwa itu adalah sesuatu yang kompatibel, tetapi juga sangat aman. Tidak ada ancaman terbuka karena kami telah melihat banyak kerentanan merayap melalui NPM. Jadi itu hanya satu hal yang harus diwaspadai.

TIM NASH: Saya pikir kita mengulang semuanya.

JIMMY SQUIRES: Silakan, Tim.

TIM NASH: Saya pikir kami memutarbalikkan ini ke gagasan bahwa, sungguh, kepercayaan benar-benar rusak dalam siklus pengembangan selama bertahun-tahun. Orang-orang baru menyadarinya sekarang. Dan jika Anda seorang pengembang PHP yang bekerja di WordPress misalnya, Anda duduk di sana memanggil tindakan dan filter, tetapi Anda tidak boleh mempercayai tindakan dan filter tersebut. Setiap data yang masuk, Anda harus memvalidasi, Anda harus memeriksanya. Itu harus dibersihkan. Tetapi ketika itu keluar dari database, Anda tetap tidak boleh mempercayainya.

Meskipun Anda mungkin telah memasukkan data tersebut ke dalam database, Anda tidak boleh mempercayai data yang keluar. Jika kami meneruskan sesuatu ke pustaka pihak ketiga, baik itu NPM, baik itu paket komposer, atau hanya plugin WordPress lainnya, segera itu meninggalkan kendali kami, kami tidak mempercayainya lagi. Tetapi ketika masuk kembali, bahkan jika kami sudah memeriksanya, kami tetap tidak mempercayainya. Dan jika Anda masuk dengan pola pikir itu, sebagai pengembang, bahwa setiap bagian data tidak boleh dipercaya dan harus diisolasi sepenuhnya dan Anda harus melakukan pemeriksaan keamanan di setiap titik tertentu, Anda akan muncul dengan sistem yang jauh lebih aman. Anda mungkin keluar dengan sistem yang sedikit lebih lambat. Anda mungkin menemukan sistem yang sedikit lebih membuat frustrasi, dan yang membutuhkan lebih banyak pengujian untuk memastikan bahwa apa yang Anda lakukan sebenarnya tidak menyebabkan lebih banyak masalah daripada membantu.

MODERATOR: Ya.

TIM NASH: Menambah kerumitan, tetapi Anda berakhir dengan sistem yang jauh lebih aman. Dan bagi kebanyakan orang, itulah yang mereka inginkan.

LAWRENCE EDMONDSON: Ya.

MODERATOR: Ya. Anda benar sekali. Ini tentang tidak mempercayai bagian kode lain yang datang. Dan untuk apa yang Jimmy dan Sergi bicarakan, itu memiliki rencana dan dari perspektif arsitektur, atau dari perspektif operasional, tetapi menyatukan semua itu ke dalam praktik Anda secara keseluruhan, apakah itu seperti mekanisme pengkodean keamanan yang aman atau apakah memiliki buku pedoman insiden. Jadi Tim, saya sangat tertarik untuk mendengar lebih banyak dari Anda di sekitar– Anda melakukan banyak pelatihan, Anda melakukan banyak pengajaran di seluruh dunia. Apa saja kesalahan umum yang Anda lihat saat orang mulai mengerjakan proyek, atau kesalahan yang mungkin Anda buat, saya sering melakukannya.

TIM NASH: Tadinya saya akan mengatakan, saya cukup yakin bahwa saya bersalah atas setiap kesalahan yang akan saya bicarakan. Dan yang terbesar dan paling sederhana adalah menjadi orang baik. Sebagian besar pengembang menganggap niat baik. Kebanyakan orang beranggapan bahwa Anda akan menggunakan aplikasi mereka sebagaimana Anda menulis aplikasi mereka. Sekarang cukup sering, kami tidak menulis dokumentasi sehingga pengguna tidak tahu bagaimana cara menggunakan aplikasi, tapi itu masalah tersendiri. Seorang aktor yang buruk akan masuk dan mengambil bug apa pun dan pergi, itu bukan bug, untuk aktor yang buruk, itu adalah sebuah fitur. Itu kesempatan. Itu melakukan sesuatu yang tidak diharapkan pengembang, oleh karena itu, ada rute potensial ke sana.

Dan secara keseluruhan, sesuatu yang Anda lihat berkali-kali, saat Anda berkata, oh, lihat, Anda memiliki serangkaian pengujian unit. Oh bagus. Tapi Anda hanya menguji hal-hal positif, hasil yang Anda inginkan. Anda belum menguji apa yang terjadi jika kita keluar dari batasan ini. Anda baru saja menguji untuk memastikan semuanya bekerja sesuai dengan keinginan atasan Anda. Jadi yang Anda miliki sebenarnya adalah tes penerimaan, tes penerimaan yang meragukan. Dan kemudian kembali ke semua dasar-dasarnya. Sebagai pengembang, ini didukung oleh ini, jangan percayai hal-hal. Dan jika Anda seorang pengembang WordPress khususnya, WordPress sebenarnya memiliki beberapa fungsi pembantu yang sangat bagus untuk melakukan semua hal keamanan standar yang kami minta agar dilakukan orang.

Dan ini tentang mendidik dan belajar menggunakannya. Saat saya melakukan tinjauan kode, berulang kali saya akan melihat masalah yang sama. Dan jika saya melihatnya sekali dalam sepotong kode, saya akan melihatnya 1.000 kali dalam kumpulan kode yang sama. Dan itu akan menjadi hal-hal seperti, yah, kami hanya mengizinkan barang lama muncul di halaman. Kami tidak repot-repot memeriksa apakah ada sesuatu di sana atau tidak. Ya, kami memasukkan barang ke dalam database. Oh, lihat, ini mungkin terlihat seperti kueri SQL, mungkin juga tidak.

Semua hal semacam ini mudah diperbaiki dan kami telah memberikan alat untuk memperbaikinya. Dan alasan kami tidak memperbaikinya seringkali bukan karena orang tidak tahu bahwa mereka seharusnya tidak membiarkan hal ini terjadi, hanya saja kami malas, kami melakukan sesuatu dengan cepat, kami mengambil kode dari Stack Overflow, kami membuat Obrolan GPT melakukan hal-hal untuk kami, kami tidak memeriksa semuanya. Dan banyak masalah keamanan berasal dari keadaan ini, saya harus buru-buru. Saya harus buru-buru. Aku harus buru-buru, aku harus menyelesaikan ini. Saya pindah ke hal berikutnya, saya pindah ke hal berikutnya.

Anehnya, bagi banyak pengembang, sebenarnya hanya memberi mereka waktu dan ruang dan berkata, tidak apa-apa meluangkan waktu untuk benar-benar memeriksa apa yang telah Anda lakukan sehingga ketika turun– dan dalam kasus di mana saya ikut bermain, Saya kembali dan berkata, semua hal ini dan para pengembang terlihat malu-malu. Mereka pergi, ya, kami tahu semua ini. Kami hanya tidak punya waktu.

Jadi mudah-mudahan, memberi orang lebih banyak waktu dan benar-benar memberi mereka alat, yang sudah kami dapatkan khususnya di dalam WordPress. WordPress memiliki serangkaian fungsi pembantu yang sangat brilian untuk sebagian besar masalah keamanan umum yang Anda alami di plugin atau tema WordPress. Jadi ini hanya tentang mempelajarinya dan kemudian menginvestasikan waktu untuk benar-benar menerapkannya.

MODERATOR: Ya. Dan saya pikir itu sangat ampuh, investasikan waktu. Paling sering, pengembang tahu apa yang perlu diperbaiki. Jadi beri mereka waktu. Jadi saya sangat suka pesan itu. Dan Jimmy, saya tahu Anda telah memasukkan ini ke dalam alur kerja Anda sendiri di agensi Anda. Anda ingin berbicara lebih banyak tentang praktik alur kerja aman yang Anda terapkan?

JIMMY SQUIRES: Ya, tentu saja. Dan sungguh, itu dimulai dengan hanya memiliki sesuatu yang dikatakan Sergi adalah memiliki rencana, benar-benar memiliki pedoman dan standar untuk diikuti oleh tim pengembangan Anda. Saya tahu kedengarannya mungkin sangat mendasar, tetapi saya telah melihat banyak organisasi dan mendengar dari banyak insinyur yang kami pekerjakan selama bertahun-tahun bahwa organisasi itu tidak ada. Tidak ada organisasi di tempat kerja mereka berasal.

Jadi yang ingin kami lakukan adalah kami memiliki seperangkat pedoman standar, semua teknisi baru kami perlu membacanya dari atas ke bawah. Tidak terlalu berat sehingga tidak dapat dikonsumsi. Kami ingin menyimpannya dalam penurunan harga, jadi semuanya ada di repositori. Kami mungkin akan benar-benar membuka sumbernya di beberapa titik. Tidak ada apa pun di sana yang benar-benar eksklusif, lalu kami mendorong semua orang untuk berkontribusi di dalamnya. Itu permintaan untuk semua insinyur.

Jadi, bahkan dalam pedoman kami, buat lubang di mana kami dapat menambahkan, di mana kami bisa menjadi lebih baik, terus kembangkan itu. Tetapi menghabiskan waktu dengan itu, beberapa hal dasar seperti OWASP, itu adalah praktik yang sangat lama, tetapi melakukannya dengan aplikasi Anda, dengan mempertimbangkan hal-hal itu. Seperti yang dikatakan Tim, benar-benar meluangkan waktu dan baik-baik saja untuk meluangkan waktu dengan itu. Saya ingin menambahkan satu poin ekstra ke percakapan AI. Berbicara dengan beberapa teknisi kami minggu lalu sebenarnya ada acara. Itu adalah sesuatu yang kami gunakan untuk Chat GPT sebenarnya adalah pengujian unit. Mengambil fungsi dan menjelajahinya dengan cara yang menarik, bagaimana Anda dapat memanfaatkan sesuatu seperti Chat GPT untuk menulis pengujian unit di mana Anda tidak akan menjadi penulis terbaik dari pengujian unit tersebut, menurut pendapat Tim. Di situlah saya pikir di mana kita dapat memanfaatkan AI lebih banyak dengan cara pencegahan.

LAWRENCE EDMONDSON: Ya. Apa yang kami lakukan di pihak kami, saya pikir daftar periksa dan memiliki pedoman itu bagus. Kami menggunakan alat otomatis seperti SonarQube dan benar-benar menerapkan linting dan hal-hal seperti itu, hanya untuk meningkatkan kualitas kode dengan linting, tetapi juga menggunakan SonarQube untuk memastikan bahwa kode lebih aman, yang kami cari untuk kerentanan dan hal-hal seperti itu. Saya pikir beberapa bahasa lebih mudah daripada yang lain untuk menemukan eksploit, seperti yang saya sebutkan sebelumnya, hanya karena sifat bahasanya. Dan juga hanya kerangka kerja tertentu di mana kualitas pembuat kode yang berkontribusi pada basis kode biasanya– kita biasanya melihat ini dengan Open Source, di mana itu seperti– ada banyak penyalinan dan penempelan Stack Overflow terjadi, versus orang yang benar-benar telah mempelajarinya CS dan benar-benar tahu apa yang mereka lakukan. Jadi itu hanya satu hal yang saya lihat.

TIM NASH: Saya rasa kami harus menunjukkan, tentunya untuk diri saya sendiri, saya menggunakan Stack OverFlow hampir setiap hari. Jadi kita semua bersalah karenanya. Itu bagus untuk dicermati, tapi saya tidak berpikir– maksud saya, saya ingat ketika saya pertama kali mulai membuat kode. Saya mendapat majalah dan sedang mengetik kode dari majalah dan menekan Enter. Saya tidak dapat membayangkan web benar-benar berfungsi hari ini jika kami masih melakukan itu dan tidak memiliki Stack Overflow, atau serupa.

Sergi: Tidak, itu akseleratornya. Dan mudah-mudahan, AI adalah tahap selanjutnya dari itu. Tapi ya, itu adalah meme yang menyenangkan.

MODERATOR: Terima kasih. Jadi bergeser sedikit. Ada banyak momentum yang terjadi di industri seputar implementasi Headless dan Headless. Dan kami juga telah melihat di beberapa saluran kami yang lain hari ini atau sesi lain membicarakan tentang Headless. Jadi saat kami mulai bekerja dengan Atlas di WP Engine, kami bertemu dengan banyak developer dan keamanan selalu menjadi motivator utama. Jadi bagaimana Anda melihat keamanan dengan Headless? Dan saya tahu, Jimmy, ini adalah area di mana Anda telah melakukan beberapa proyek di sekitarnya. Kami ingin mendapatkan pendapat Anda tentang itu.

JIMMY SQUIRES: Ya, kami melakukan banyak pekerjaan di Headless. Saya pikir hampir semua proyek kami pada saat ini mungkin menggunakan pendekatan arsitektur Tanpa Kepala. Saya pikir beberapa poin yang ingin saya sampaikan, karena berkaitan dengan keamanan. Jadi saya pikir yang pertama adalah ketika Anda memilih arsitektur Headless, Anda umumnya menempatkan diri Anda lebih banyak di kamp open source pada awalnya. Dan ada banyak perdebatan, tentu saja, tentang mana yang lebih aman, open source atau closed source. Saya cenderung jatuh di kubu proyek OSS yang pada dasarnya lebih aman. Jadi Anda memilih kerangka kerja seperti Berikutnya, WordPress, tempat Anda memiliki komunitas raksasa. Dan itu cenderung memberikan keamanan lebih melalui paparan saja.

Jadi saya pikir itu salah satunya. Saya pikir yang kedua adalah sesuatu seperti Static Generation. Begitu banyak situs web dan produk yang dibuat, Anda tidak memerlukan sifat dinamis dari manajemen konten yang besar, sistem monolitik dalam pengertian tradisional. Anda dapat memanfaatkan sesuatu seperti Cloudflare dan benar-benar menghasilkan sebagian besar aplikasi itu secara statis, sehingga mengurangi jejak Anda untuk vektor dan eksposur. Jadi kami penggemar berat itu. Dan kemudian, tentu saja, Anda juga mendapatkan semua manfaat kinerjanya. Jadi itu hanya beberapa poin yang ingin saya sampaikan pada arsitektur Headless. Tetapi banyak lagi alasan dari sudut pandang keamanan yang kami sukai. Tapi saya pikir itu mungkin dua area paling menonjol.

TIM NASH: Saya hanya ingin mengingatkan orang-orang bahwa masih ada sistem manajemen konten di belakang sana. Dan itu terlalu sering saya dengar, Headless benar-benar aman. Ini seperti, ya, tetapi contoh WordPress yang terbuka itu masih ada di sana, hanya karena Anda tidak langsung memanggilnya dari situs web, ya, itu masih ada di admin.yoursite.com. Dan Anda belum– ada keyakinan tertentu bahwa, oh ya, kami aman sekarang jadi kami tidak perlu khawatir untuk selalu memperbaruinya karena ini bukan situs webnya. Ini seperti, tidak, tidak, Anda masih membutuhkan semua hal yang Anda lakukan sebelumnya dan sekarang kami juga memiliki sisi lain.

Dan maksud saya, Headless adalah istilah yang bagus untuk sesuatu yang telah ada sejak lama dan mendapatkan banyak momentum, tetapi kami melakukan ini sebelum WordPress memiliki REST API. Kami mendorong konten dari WordPress ke hal-hal seperti Jekyll untuk mendapatkan setidaknya situs statis darinya. Dan alasan asli untuk melakukan itu adalah untuk memvariasikan sistem WordPress atau sistem manajemen konten Anda di dalam jaringan Anda. Jadi Anda bisa menguncinya dan menyimpannya dari web yang besar dan menakutkan.

Sekarang kami mendapatkan banyak perusahaan hosting yang menyediakan solusi 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. Terima kasih. 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.