Hal buruk bisa terjadi kapan saja.
Perusahaan diretas karena tidak ada cara yang jelas bagi peneliti keamanan untuk memberi tahu mereka tentang kerentanan keamanan atau kebocoran data.
Atau mungkin, tidak sepenuhnya jelas siapa yang harus mendapatkan laporan ketika akses jarak jauh ke jaringan internal perusahaan dijual di bawah tanah kejahatan siber.
Dalam upaya untuk meminimalisasikan kasus ini, semakin banyak perusahaan besar yang menggunakan “Security.txt,” yaitu standar Internet baru yang direkomendasi dapat membantu perusahaan untuk menggambarkan praktik dan preferensi pengungkapan kerentanan mereka.

Ide di balik Security.txt sangat mudah.
Perusahaan menempatkan file bernama security.txt di tempat yang dapat diprediksi seperti example.com/security.txt atau example.com/.well-known/security.txt.
Apa yang ada pada file security.txt agak bervariasi, tetapi sebagian besar menyertakan tautan ke informasi mengenai kebijakan pengungkapan kerentanan entitas dan alamat email kontak.
File security.txt yang disediakan oleh USAA, misalnya menyertakan tautan ke program bug bounty-nya; alamat email untuk mengungkapkan hal-hal terkait keamanan, kunci enkripsi publik dan kebijakan pengungkapan kerentanannya, bahkan tautan ke halaman di mana USAA berterima kasih kepada para peneliti yang telah melaporkan masalah keamanan siber yang penting.
Pengungkapan security.txt lainnya kurang detail, seperti dalam kasus HCA Healthcare, yang mencantumkan alamat email kontak dan tautan ke kebijakan “pengungkapan yang bertanggung jawab” HCA.
Seperti USAA dan banyak perusahaan lain yang telah menerbitkan file security.txt, HCA Healthcare juga menyertakan tautan ke informasi tentang lowongan pekerjaan keamanan TI di perusahaan tersebut.
Memiliki file security.txt dapat mempermudah perusahaan untuk merespons ancaman keamanan aktif.
Misalnya, baru saja pagi ini sumber tepercaya meneruskan kepada kami, kredensial VPN untuk pengecer pakaian besar yang dicuri oleh malware dan tersedia untuk penjahat siber.
Tidak menemukan file security.txt di situs pengecer menggunakan gotsecuritytxt.com (yang memeriksa domain untuk keberadaan file kontak ini), KrebsonSecurity mengirimkan peringatan ke alamat email “security@” untuk domain pengecer.
Banyak perusahaan lama yang secara tidak resmi menggunakan (jika tidak diiklankan) alamat email security@[companydomain] untuk menerima laporan tentang insiden atau kerentanan keamanan.
Mungkin pengecer khusus ini juga melakukannya pada satu titik, namun pesannya dikembalikan dengan catatan yang mengatakan bahwa email telah diblokir.
KrebsOnSecurity juga mengirim pesan ke chief information officer (CIO) pengecer, satu-satunya orang pada posisi tingkat C di pengecer yang berada di jaringan LinkedIn langsung.
Namun, kita masih tidak tahu apakah ada yang membacanya.
Meskipun security.txt belum menjadi standar Internet resmi seperti yang disetujui oleh Internet Engineering Task Force (IETF), prinsip dasarnya sejauh ini telah diadopsi oleh setidaknya 8% dari perusahaan Fortune 100.
Menurut ulasan, nama domain terbaru untuk perusahaan Fortune 100 melalui gotsecuritytxt.com, itu termasuk Alphabet, Amazon, Facebook, HCA Healthcare, Kroger, Procter & Gamble, USAA dan Walmart.
Mungkin ada alasan bagus lainnya untuk menggabungkan kontak keamanan dan informasi pelaporan kerentanan di satu tempat yang dapat diprediksi.
Alex Holden, pendiri perusahaan konsultan Hold Security yang berbasis di Milwaukee, mengatakan tidak jarang peretas mengalami masalah dalam mendapatkan perhatian dari orang yang tepat dalam perusahaan yang baru mereka retas.
“Dalam sebuah kasus ransomware, peretas akan mencoba menghubungi perusahaan dengan tuntutan mereka,” kata Holden. “Kita tidak tahu seberapa sering pesan mereka tertangkap dalam filter, dihapus, diblokir atau diabaikan.”
Apakah Kita akan Menggunakan File Security.txt?
Jadi, jika security.txt sangat hebat, mengapa belum banyak perusahaan yang menggunakannya?
Tampaknya menyiapkan file security.txt cenderung mengundang volume spam yang cukup tinggi.
Sebagian besar junk email ini berasal dari penguji penetrasi (yang menunjuk diri sendiri), tanpa undangan, untuk menjalankan alat penemuan kerentanan otomatis, kemudian mengirimkan laporan yang dihasilkan dengan harapan untuk mengamankan keterlibatan konsultasi atau biaya bug.
Dinamika ini merupakan topik utama dari diskusi Berita Peretas di security.txt.
Dimana sejumlah pembaca menceritakan pengalaman mereka yang dibanjiri dengan laporan pemindaian kerentanan berkualitas rendah sehingga menjadi sulit untuk menemukan laporan yang benar-benar layak untuk ditindaklanjuti lebih lanjut.
Edwin “EdOverflow” Foudil, rekan penulis standar notifikasi yang diusulkan, mengakui bahwa laporan junk adalah kelemahan utama bagi perusahaan yang menawarkan file security.txt.
“Ini sebenarnya dinyatakan dalam spesifikasi itu sendiri dan sangat penting untuk menyoroti bahwa perusahaan yang menerapkan ini akan kebanjiran,” kata Foudil kepada KrebsOnSecurity.
“Salah satu alasan program bug bounty berhasil adalah karena mereka pada dasarnya adalah saringan spam . Tetapi, terlepas dari pendekatan apa yang kita gunakan, kita akan dibanjiri dengan laporan-laporan yang buruk dan di bawah standar ini.”
Seringkali laporan kerentanan di bawah standar ini berasal dari individu yang telah memindai seluruh Internet untuk satu atau dua kerentanan keamanan, kemudian mencoba menghubungi semua perusahaan yang rentan sekaligus dengan cara semi-otomatis.
Untungnya, kata Foudil, banyak dari laporan gangguan ini dapat diabaikan atau dikelompokkan dengan membuat filter yang mencari pesan berisi kata kunci yang biasa ditemukan dalam pemindaian kerentanan otomatis.
Foudil mengatakan, terlepas dari tantangan spam, dia mendengar umpan balik yang luar biasa dari sejumlah universitas yang telah menerapkan security.txt.
“Ini merupakan kesuksesan luar biasa dengan universitas yang cenderung memiliki banyak sistem warisan yang lebih tua,” katanya. “Dalam konteks itu, kami telah melihat banyak sekali laporan berharga.”
Foudil mengatakan dia senang bahwa delapan dari perusahaan Fortune 100 telah menerapkan security.txt, meskipun belum disetujui sebagai standar IETF.
Jika security.txt disetujui, ia berharap dapat meluangkan lebih banyak waktu untuk mempromosikan manfaatnya.
“Saya tidak mencoba menghasilkan uang dari hal ini, yang muncul setelah mengobrol dengan beberapa orang di DEFCON [konferensi keamanan tahunan di Las Vegas] yang berjuang untuk melaporkan masalah keamanan kepada vendor,” kata Foudil.
“Alasan utama saya tidak berusaha untuk mempromosikannya sekarang adalah karena itu belum menjadi standar resmi.” Lanjut Foudil.
Sudahkah perusahaan kita mempertimbangkan atau menerapkan security.txt?
Recent Comments