Risiko dan Tindakan Pencegahan dalam Penggunaan Perpustakaan dalam Pembangunan Sistem Bisnis

Di era modern ini, komponen sistem yang disebut ‘perpustakaan’ atau ‘library’ telah menjadi hal yang penting dalam pembangunan sistem bisnis. Namun, penggunaan library juga memiliki risikonya. Menggunakan library tanpa memperhatikan risiko dapat memicu masalah, dan dalam kasus terburuk, bahkan dapat menimbulkan kerugian serius seperti kebocoran informasi. Artikel ini akan menjelaskan tentang risiko yang tersembunyi dalam penggunaan library dan cara mengatasinya.

Apa itu Library

Dalam pembangunan sistem bisnis, hampir tidak ada perusahaan IT yang membuat semua program yang dibutuhkan sendiri. Sebaliknya, mereka biasanya membangun fondasi dengan menggunakan “komponen perangkat lunak yang sudah jadi”, dan membuat bagian yang kurang sendiri. Komponen perangkat lunak ini disebut “library”. Fungsi umum biasanya dikembangkan dengan menggunakan library. Fungsi umum ini mencakup fitur seperti “fungsi login” atau “fungsi pengambilan data dari database”, yang sangat dibutuhkan di semua industri dan sistem di setiap negara. Untuk fitur yang sangat dibutuhkan ini, ada library yang sesuai. Di sisi lain, untuk fitur yang tidak umum, seperti memenuhi permintaan khusus pelanggan, perusahaan IT harus membuatnya sendiri karena tidak ada library yang sudah jadi.

Perlu dicatat, ada kata “framework” yang memiliki arti serupa dengan library. Ada juga kata “OSS” (Open Source Software). Dalam konteks sistem bisnis, OSS adalah komponen sistem dan sama dengan library yang disebutkan dalam artikel ini, tetapi mungkin lebih familiar. Namun, dalam artikel ini, kita akan menggunakan kata “library”.

Keuntungan dari Perpustakaan: Cepat dan Aman

Ada dua alasan mengapa perusahaan sistem lebih memprioritaskan penggunaan perpustakaan daripada membuat sendiri.

• Lebih cepat dibuat daripada membuat sendiri
• Keamanannya lebih tinggi daripada membuat sendiri

Menjadi lebih cepat adalah hal yang wajar jika menggunakan produk jadi, tetapi keunggulan lainnya adalah keamanan yang lebih tinggi. Alasannya adalah karena perpustakaan terkenal dikembangkan, diverifikasi, dan digunakan secara berkelanjutan di lingkungan produksi oleh insinyur dan perusahaan terbaik di seluruh dunia. Oleh karena itu, tindakan pencegahan terhadap metode serangan yang sudah diketahui telah diambil, dan pembaruan cepat dapat diharapkan bahkan jika metode serangan baru ditemukan. Sebaliknya, jika Anda mencoba membuatnya sendiri tanpa menggunakan perpustakaan, Anda mungkin perlu melibatkan tinjauan ahli untuk mempertimbangkan masalah keamanan, yang bisa memakan waktu. Dalam hal ini, mungkin akan ada biaya untuk meningkatkan keamanan. Karena berbagai alasan ini, penggunaan perpustakaan menjadi penting jika Anda ingin mengembangkan sistem dengan lebih cepat dan aman.

Apa Saja Kekurangan dari Perpustakaan (Library)?

Menggunakan perpustakaan (library) dapat memberikan manfaat besar bagi kedua belah pihak, pelanggan dan perusahaan sistem, karena memungkinkan pembuatan sistem yang cepat dan aman. Namun, penggunaan perpustakaan juga memiliki biaya tertentu. Selain itu, ada dilema bahwa jika tidak melakukan pembaruan, ada kemungkinan “kerentanan” akan bercampur, dan jika melakukan pembaruan, ada kemungkinan sistem tidak akan berfungsi.

Jika Tidak Diperbarui, Ada Kerentanan

Para penjahat yang berencana mencuri informasi pribadi, informasi kartu kredit, dan rahasia perusahaan, setiap hari mencari kelemahan keamanan dalam perpustakaan (termasuk semua perangkat lunak). Kelemahan keamanan ini disebut “kerentanan” dalam istilah IT. Ada banyak contoh di mana kerentanan yang tersembunyi dalam perpustakaan yang digunakan telah dieksploitasi dan menyebabkan kerugian. Misalnya, ada kasus di mana sekitar 200.000 informasi pelanggan bocor karena serangan pada kerentanan perpustakaan Struts2 yang digunakan di situs survei Kementerian Infrastruktur, Transportasi dan Pariwisata Jepang, dan kasus di mana situs penjualan tiket yang menggunakan Struts2 mungkin telah bocor 32.187 informasi kartu kredit. Ada juga kasus di mana kerentanan perpustakaan yang tidak diketahui pada saat pengiriman sistem ditemukan nantinya.

Ada Risiko Penghentian Sistem dalam Pembaruan

Di lapangan, mungkin ada kasus di mana pembaruan tidak dapat dilakukan meskipun ada kerentanan. Itu karena ada risiko bahwa sistem akan berhenti berfungsi sementara waktu karena pembaruan. Karena perpustakaan bukanlah program yang ditulis oleh perusahaan sistem, sangat sulit untuk sepenuhnya memahami isinya. Oleh karena itu, tidak mungkin sepenuhnya menghilangkan risiko seperti munculnya masalah yang tidak terduga dalam sistem karena pembaruan dan sistem berhenti berfungsi sementara waktu. Sebagai pelanggan, Anda mungkin merasa marah pada perusahaan sistem karena tidak memahami isi sistem yang disampaikan. Namun, kenyataannya adalah bahwa perpustakaan yang digunakan dalam sistem modern, baik dalam hal kualitas maupun kuantitas, bukanlah sesuatu yang dapat ditangani sepenuhnya oleh perusahaan sistem biasa. Misalnya, ada perpustakaan yang sangat populer untuk membangun antarmuka pengguna yang disebut “React”. Perpustakaan ini adalah produk yang sangat canggih yang dibuat oleh insinyur Facebook dalam hal kualitas, dan dalam hal kuantitas, jumlah baris kode adalah 195.486 (※1), yang sangat besar.

Kasus yang Menjadi Pengadilan Karena Kerentanan

Ada pertanyaan tentang siapa yang bertanggung jawab jika terjadi kerugian akibat kerentanan yang disebabkan oleh perpustakaan. Sebagai referensi, ada putusan Pengadilan Distrik Tokyo pada 23 Januari 2014 (Tahun 26 era Heisei). Penggugat telah mempercayakan pembangunan sistem penjualan kepada tergugat, sebuah perusahaan sistem. Namun, setelah sistem mulai beroperasi, informasi kartu kredit pengguna akhir bocor karena kerentanan sistem, dan penggugat menderita kerugian sekitar 32 juta yen karena harus meminta maaf dan melakukan investigasi, yang mengakibatkan perselisihan. Dalam kontrak yang ditandatangani oleh penggugat dan tergugat, ada klausa pembebasan yang menyatakan bahwa jika kerugian terjadi karena kelalaian tergugat, jumlah ganti rugi akan dibatasi hingga jumlah kontrak. Apakah klausa pembebasan ini dapat diterapkan atau tidak menjadi titik perdebatan. Putusan tersebut menyatakan bahwa tergugat memiliki kelalaian serius, dan jika ada kelalaian serius, klausa pembebasan tidak dapat diterapkan, dan tergugat diperintahkan untuk membayar ganti rugi melebihi jumlah kontrak.

Tergugat, sebagai perusahaan yang melakukan perencanaan sistem pengolahan informasi, pembuatan halaman web, pengembangan sistem bisnis, dll., Mengembangkan bisnis dengan memanfaatkan pengetahuan khusus tentang program, dan penggugat dapat dianggap telah menandatangani kontrak sistem ini dengan mempercayai pengetahuan khusus tersebut. Oleh karena itu, tingkat kewajiban hati-hati yang diharapkan dari tergugat dianggap cukup tinggi. Seperti yang telah disebutkan, jika tidak ada tindakan pencegahan terhadap serangan SQL Injection, adalah mungkin bagi pihak ketiga untuk melakukan serangan SQL Injection dan informasi pribadi dapat bocor dari database ini, yang dapat diprediksi oleh tergugat. Selain itu, Kementerian Ekonomi, Perdagangan dan Industri dan IPA telah memperingatkan bahwa serangan SQL Injection adalah metode serangan utama terhadap aplikasi web, dan mudah untuk memprediksi bahwa situasi tersebut dapat terjadi. Selain itu, dengan menggunakan mekanisme bind atau melakukan proses escape, hasil kebocoran ini dapat dihindari, dan tidak ada bukti yang menunjukkan bahwa banyak tenaga kerja atau biaya diperlukan untuk melakukan tindakan teknis untuk menghindari ini, jadi mudah untuk menghindari hasil ini. Oleh karena itu, dapat dikatakan bahwa tergugat memiliki kelalaian serius.

Pengadilan Distrik Tokyo, 23 Januari 2014

Penafsiran dari putusan ini dalam konteks kerentanan perpustakaan adalah deskripsi dalam dokumen berikut dari Yayasan Umum Pusat Informasi Perangkat Lunak.

Jika kita mendasarkan pada cara berpikir dalam putusan ini, bahkan jika kerugian terjadi pada pengguna karena bug (kerentanan, dll.) Dalam OSS, jika dapat diakui bahwa vendor telah mengabaikan penanganan kerentanan, sama seperti dalam kasus ini, aplikasi dari klausa pembebasan (klausa pembatasan tanggung jawab) dapat dibatasi, dan kemungkinan besar tidak dapat memperoleh efek pembebasan. Namun, jika Anda diserang segera setelah informasi penanganan kerentanan OSS dipublikasikan, kemungkinan tidak akan diakui kelalaian serius karena kemudahan menghindari hasilnya ditolak.

Kumpulan Q&A tentang Penggunaan OSS dan Berbagai Masalah Hukum di Era IoT [PDF] (halaman 84)

Dengan demikian, bahkan jika itu adalah kerentanan yang disebabkan oleh perpustakaan, jika itu adalah kerentanan yang diketahui dan mudah untuk memprediksi serangan, kemungkinan besar akan ditangani sebagai tanggung jawab perusahaan sistem.

Apa Langkah yang Lebih Realistis untuk Mengatasi Kerentanan?

Jika terjadi kebocoran informasi akibat kesengajaan atau kelalaian serius dari perusahaan sistem, secara hukum, kompensasi dapat diperoleh melalui tuntutan hukum. Namun, dari sudut pandang praktis, yang paling penting adalah mencegah kebocoran terjadi pada awalnya. Meskipun Anda menerima kompensasi melalui tuntutan hukum, kepercayaan dari pengguna akhir yang hilang karena kebocoran informasi tidak dapat dipulihkan. Untuk itu, dua hal berikut ini sangat penting:

1. Menyusun kontrak pemeliharaan, termasuk pembaruan perpustakaan
2. Diagnosis kerentanan

Menyusun Kontrak Pemeliharaan, Termasuk Pembaruan Perpustakaan

Dalam kontrak pembangunan sistem bisnis, ada kasus di mana hanya pengembangan yang didelegasikan dan kasus di mana pemeliharaan juga didelegasikan. Jika perusahaan Anda tidak memiliki ahli yang mampu melakukan pemeliharaan, maka tepat untuk membuat kontrak pemeliharaan. Dalam kontrak, Anda dapat mencegah masalah dengan meminta perusahaan sistem untuk mengambil tindakan terhadap kerentanan, termasuk pembaruan perpustakaan, dan dengan menjelaskan kewajiban respons perusahaan sistem dan kewajiban pembayaran pelanggan yang sesuai. Sementara perusahaan sistem diharuskan untuk merespons sebagai ahli, pelanggan juga perlu membuat kontrak yang membebankan biaya yang cukup untuk meminta bantuan dari ahli.

Diagnosis Kerentanan

Seiring bertambahnya volume data yang ditangani oleh sistem dan peningkatan permintaan terhadap UI setiap hari, jumlah kerentanan yang baru ditemukan terus meningkat. Oleh karena itu, ada situasi di mana sulit bagi perusahaan sistem sendiri untuk sepenuhnya mencegah kerentanan. Di sinilah diagnosis kerentanan menjadi penting. Menurut IPA, lebih dari 50% dari semua perusahaan, dan 80% dari perusahaan besar, telah melakukan diagnosis kerentanan.

Diagnosis kerentanan berkisar dari alat gratis hingga diagnosis manual yang mahal. Terutama ketika menangani informasi yang bocornya bisa fatal, akan sangat penting untuk mengalokasikan biaya yang cukup dan mengambil tindakan dengan mendelegasikan diagnosis kerentanan kepada perusahaan yang mengkhususkan diri dalam hal tersebut. Selain itu, karena kerentanan ditemukan setiap hari, penting untuk terus melakukan diagnosis kerentanan (P15) tidak hanya pada saat pengiriman, tetapi juga setelah pengiriman.

Ringkasan

Artikel ini telah menjelaskan tentang risiko yang terkait dengan penggunaan perpustakaan (library) dan cara untuk mengatasinya. Meskipun perpustakaan sangat berguna, ada risiko seperti kerentanan yang muncul jika tidak diperbarui dan kerugian seperti kebocoran informasi. Dari segi hukum, jika ada kelalaian serius dari perusahaan sistem, ada kemungkinan untuk menerima kompensasi atas kebocoran informasi, tetapi dalam praktiknya, penting untuk mengambil tindakan agar kebocoran informasi tidak terjadi sama sekali. Untuk itu, Anda harus sepakat tentang waktu kerja untuk pembaruan perpustakaan dan diagnosis kerentanan dalam kontrak. Jika Anda tidak menggunakan perpustakaan, hampir tidak mungkin mencapai standar yang diperlukan untuk kedua deadline dan fungsi. Untuk menikmati keuntungan dari perpustakaan sambil menghindari masalah, dianggap perlu untuk mencapai kesepakatan tentang biaya pembaruan dan tindakan terhadap kerentanan antara Anda dan perusahaan sistem. Untuk mencegah bisnis Anda menerima dampak fatal dari kebocoran informasi, penting untuk memberikan perhatian yang cukup terhadap keamanan, serta elemen-elemen seperti fungsi, tata letak layar, dan harga, sejak saat kontrak.