Apa yang diketahui oleh tim penanggap insiden kami setelah lima tahun berjuang melawan gurita

Perangkat dengan arsitektur tertanam, seperti perangkat jaringan, secara historis tidak menjadi prioritas utama dalam hal fitur keamanan, dan selama Pacific Rim, mereka menjadi subjek dari perlombaan senjata yang meningkat—suatu hal yang harus dipahami oleh tim biru, dan bukan hanya mereka yang ada di Sophos.

Berita baiknya adalah bahwa banyak prinsip yang ada sudah sangat cocok: Teknologi perangkat jaringan terbaru didasarkan pada OS yang sudah dipahami dengan baik, seperti varian Linux. Berita buruknya adalah beberapa prinsip tersebut mungkin perlu disesuaikan. Meskipun teknologi telah berkembang, masih ada proporsi tinggi perangkat di lapangan yang menjalankan arsitektur tertanam yang kuno dan tidak peka terhadap keamanan—terpasang di rak mengumpulkan debu.

Tentu saja, Sophos, sebagai perusahaan keamanan informasi, memiliki pandangan ganda terhadap keamanan dan respons; kami merespons tidak hanya insiden yang memengaruhi kami sebagai perusahaan, tetapi juga insiden yang memengaruhi produk dan layanan kami—”kami” yang dikirim ke dunia yang lebih luas. Oleh karena itu, proses respons insiden kami meluas di luar lingkungan perusahaan kami sendiri hingga infrastruktur yang kami terapkan untuk pelanggan kami. Ini adalah jenis pandangan ganda yang khusus, yang—kami harap—memberikan keuntungan dalam memikirkan bagaimana mengembangkan prinsip respons insiden untuk memenuhi kebutuhan saat ini.

Namun, untuk membuat sistem pandangan ganda ini berfungsi, diperlukan kerja sama erat antara kelompok yang mengembangkan produk kami dan kelompok yang bertugas merespons masalah keamanan yang berkaitan dengan produk tersebut, yaitu Tim Respons Insiden Keamanan Produk (PSIRT) kami. Karena tidak semua perusahaan memiliki (atau membutuhkan) PSIRT, sebelum kami membahas temuan kami, ada baiknya menjelaskan bagaimana PSIRT kami beroperasi.

Kehidupan di PSIRT Sophos

PSIRT kami memantau beberapa saluran untuk informasi tentang temuan baru di produk dan layanan Sophos. Misalnya, seperti yang kami sebutkan dalam artikel terbaru yang memberikan transparansi ke Sophos Intercept X (sebuah tindak lanjut mengeksplorasi arsitektur pembaruan konten kami), kami telah berpartisipasi dalam program bug bounty eksternal sejak 14 Desember 2017—ternyata, hampir setahun sebelum gelombang pertama dari apa yang menjadi Pacific Rim—dan menyambut perhatian dan peluang kolaboratif yang dibawanya. Kebijakan pengungkapan yang bertanggung jawab kami juga menawarkan ‘perlindungan’ bagi peneliti keamanan yang mengungkapkan temuan dengan itikad baik. Selain laporan eksternal, kami juga melakukan pengujian internal kami sendiri dan pemantauan sumber terbuka.

Ketika PSIRT menerima sebuah peristiwa keamanan, tim akan melakukan triase—mengonfirmasi, mengukur, mengkomunikasikan, dan melacak untuk memastikan respons kami proporsional, aman, dan memadai. Jika perlu, kami akan meningkatkan masalah ke Pusat Operasi Keamanan Global (GSOC) kami, yang beroperasi 24/7 dengan lebih dari selusin pos luar yang mengoordinasikan kasus.

PSIRT kami menggerakkan perbaikan, bekerja dengan ahli produk kami untuk menawarkan panduan teknis keamanan, dan bergerak menuju penyelesaian seiring dengan standar respons—memungkinkan pelanggan kami untuk mengelola risiko yang relevan secara efektif dan tepat waktu. Kami bertujuan untuk mengkomunikasikan hasil dengan jelas melalui pemberitahuan keamanan yang dapat ditindaklanjuti dan CVE yang komprehensif—termasuk skor CVSS, serta informasi tentang Common Weakness Enumeration (CWE) dan Common Attack Pattern Enumeration and Classification (CAPEC).

Selain merupakan praktik terbaik PSIRT secara umum, ini juga berhubungan dengan komitmen kami terhadap inisiatif CISA Secure by Design. Faktanya, Sophos adalah salah satu organisasi pertama yang berkomitmen pada janji inisiatif ini, dan Anda dapat melihat rincian janji khusus kami di sini. (Sebuah esai dari CEO kami, Joe Levy, membahas secara mendalam komitmen kami terhadap Secure by Design dan bagaimana, dengan segala yang kami pelajari dari Pacific Rim, kami bermaksud melanjutkan komitmen itu ke depan.)

Tentu saja, PSIRT yang baik tidak hanya menunggu laporan datang. Di latar belakang, selain melakukan pengujian dan riset kami sendiri, tim juga bekerja untuk mematangkan standar keamanan produk kami, kerangka kerja, dan pedoman; melakukan analisis akar penyebab; dan terus-menerus meningkatkan proses kami berdasarkan umpan balik dari pemangku kepentingan internal dan eksternal.

Semua tugas ini menginformasikan apa yang akan kami bahas dalam artikel ini, saat kami membahas apa yang kami pelajari dari iterasi dan perbaikan proses kami selama Pacific Rim. Kami akan membicarakan prinsip-prinsip—banyak di antaranya telah kami implementasikan atau sedang dalam proses implementasi—sebagai titik awal untuk percakapan lebih panjang di kalangan praktisi tentang bagaimana respons yang efektif dan dapat diskalakan terlihat dalam hal perangkat jaringan.

Apa yang Kami Pelajari

Telemetri

Semua dimulai dengan kemampuan untuk menangkap keadaan dan perubahan pada perangkat itu sendiri. Perangkat jaringan sering kali diabaikan sebagai perangkat dengan kekuatan tersendiri, karena peran mereka yang biasanya sebagai “pengangkut” lalu lintas jaringan yang tidak terlihat. Namun, perbedaan ini merupakan langkah penting untuk memberikan observabilitas pada perangkat—sesuatu yang penting untuk respons.

Tantangan utama:

  • Jalur jaringan vs jalur kontrol. Kami tidak ingin memantau jaringan Anda (jalur jaringan). Tidak sama sekali. Namun, kami ingin memantau perangkat yang mengelola jaringan Anda (jalur kontrol). Perbedaan ini sering kali bersifat logis, bukan material, tetapi telah menjadi perbedaan penting untuk memastikan kami dapat menjaga privasi pelanggan.
  • Ketersediaan sumber daya perangkat. Perangkat ini tetaplah perangkat kecil, dengan ketersediaan RAM dan CPU terbatas. Fungsi pemantauan telemetri harus disederhanakan untuk menghindari penurunan layanan yang tidak perlu bagi fungsi utama perangkat tersebut. (Namun demikian, kapasitas sumber daya telah meningkat dalam beberapa tahun terakhir—yang, sayangnya, berarti lebih mudah bagi penyerang untuk bersembunyi dalam kebisingan. Admin kurang mungkin untuk tidak sengaja menghapus penyerang dari perangkat dengan reboot keras yang tidak disengaja ketika mereka menyadari firewall berjalan lambat untuk seluruh jaringan, karena firewall modern dapat mentolerir perangkat lunak yang membengkak dan dengan demikian tidak menunjukkan distress yang sama.)
  • Penangkapan data yang bising. Perangkat jaringan dibangun dengan cara yang berbeda. Sementara folder /tmp mungkin relatif sepi di endpoint pengguna—dan layak dipantau secara aktif—hal ini bisa jauh lebih bising pada perangkat jaringan. Penyempurnaan sangat penting untuk memastikan telemetri tidak dibanjiri oleh kebisingan.

Streaming
Apakah deteksi terjadi di perangkat atau di danau data backend (lebih lanjut tentang ini di bawah), pasti akan ada titik di mana telemetri yang dikumpulkan harus dikirim dari perangkat. Meskipun banyak dari prinsip-prinsip ini telah didokumentasikan dengan baik untuk bidang pemantauan keamanan, ada tantangan unik bagi perangkat jaringan.

Tantangan utama:

  • Gangguan host / pengaturan NIC. Perangkat jaringan sudah sensitif terkait manajemen antarmuka jaringan dan bagaimana host itu sendiri memengaruhi lalu lintas yang dibawanya. Menambahkan saluran data tambahan sering kali memerlukan rekayasa ulang yang cukup besar. Pemilihan teknologi yang baik yang menyebabkan gangguan minimal sangat penting untuk memastikan adanya pemisahan antara respons dan operasi perangkat. OSQuery menonjol sebagai contoh teknologi yang dapat mendukung kueri hampir waktu nyata sambil mengurangi risiko dampak terhadap sumber daya.
  • Pengumpulan vs. seleksi. Pengumpulan seluruh lalu lintas jaringan pengguna adalah masalah privasi yang besar dan bentuk rekayasa deteksi yang sangat tidak efisien. “Memilih” data yang paling relevan menggunakan seperangkat aturan (yang dapat dibuat, diedit, diuji, dan diterapkan) adalah praktik standar untuk pengumpulan volume tinggi, tetapi memerlukan kriteria seleksi yang terdokumentasi dengan baik (dan diaudit) agar berhasil. Perbedaan ini juga memungkinkan penerapan kebijakan retensi yang bijaksana—lebih lama untuk data yang dipilih dan lebih pendek untuk data yang dikumpulkan.

Pencetus, tripwire, dan deteksi

Tahap berikutnya adalah membedakan sinyal dari kebisingan. Sebagai spesialis keamanan siber, kita sering diajarkan untuk mencari ketidakhadiran yang normal dan kehadiran yang abnormal—tetapi definisi keduanya sangat bervariasi dalam perangkat jaringan.

Tantangan utama:

  • Pilihan telemetri + pilihan streaming = titik buta. Menyadari untuk memilih subset pengumpulan, meskipun diperlukan, menciptakan celah yang perlu dievaluasi ulang secara terus-menerus. Mengecualikan /tmp dari pengumpulan mungkin merupakan langkah yang tepat untuk mengurangi kebisingan, tetapi meninggalkannya sebagai tempat yang sempurna untuk malware. Praktisi harus menemukan cara untuk memantau titik buta ini dengan “tripwire” granular yang lebih rendah, seperti pemantauan integritas file.
  • Menulis deteksi berdasarkan data yang dipilih. Meskipun memiliki subset data yang dipilih adalah awal yang baik, ini mungkin masih terlalu banyak kebisingan untuk diproses. Kami menemukan bahwa pada titik ini, praktik rekayasa deteksi dapat diterapkan pada data yang dipilih—idealnya dalam skema yang dinormalisasi bersama dengan telemetri keamanan lainnya, untuk mempromosikan pivoting.

Tindakan respons

Kami berbicara tentang infrastruktur jaringan inti, yang tidak merespons dengan baik terhadap taktik agresif. Sementara di endpoint pengguna kami mungkin tidak memikirkan apa-apa tentang menghentikan proses yang diduga nakal atau mengisolasi perangkat dari jaringan, melakukan salah satu dari tindakan tersebut pada perangkat jaringan bisa memiliki dampak ketersediaan yang katastropik pada jaringan pengguna. Dalam pengalaman kami, pada titik ini, beberapa pembatas yang jelas, menetapkan ekspektasi dan menghentikan aktivitas respons agar tidak memperburuk insiden, sangat membantu.

Tantangan utama:

  • Dampak ketersediaan jaringan. “Mematikannya dan menyalakannya lagi” terasa berbeda ketika kami berbicara tentang akses internet seluruh organisasi. Menerapkan tindakan respons—baik yang dapat diskalakan/otomatis atau tidak—harus diperlakukan sebagai perubahan bisnis yang sangat berdampak, dan harus mengikuti proses manajemen perubahan.
  • Jaringan vs jalur kontrol (lagi). Ini penting pada titik pengumpulan data, dan penting juga selama perbaikan. Mengetahui batas yurisdiksi antara penanggap dan pengguna jaringan sangat penting untuk memastikan adanya batas eksploitasi bagi tindakan respons, dan batas paparan untuk dampak negatif apapun.

Infrastruktur IT yang kuat adalah kunci produktivitas perusahaan. Dengan qfirewall Indonesia, Anda bisa mendapatkan solusi IT lengkap yang sesuai dengan kebutuhan Anda. iLogo Indonesia sebagai mitra terpercaya siap mengintegrasikan semuanya agar bisnis Anda tetap berjalan lancar dan aman.
Hubungi kami sekarang atau kunjungi qfirewall.id untuk informasi lebih lanjut!