Secure Coding - Tantangan dalam Keamanan Informasi

• Kerentanan keamanan dalam kode
• Kode sumber terbuka dan serangan rantai pasokan
• Kontrol keamanan informasi 8.28 Pengkodean yang aman
• Prinsip-prinsip pengkodean yang aman
• Kesimpulan
• Revisi ISO 27001: Apa arti pembaruan untuk sertifikasi Anda?
• DQS - Meningkatkan Keamanan secara sederhana.

Kerentanan keamanan dalam kode

Perangkat lunak sistem operasi, perangkat lunak aplikasi, atau firmware dalam sistem tertanam adalah komponen dasar dari infrastruktur digital apa pun. Namun, meningkatnya percepatan dan tekanan tenggat waktu dalam proyek digitalisasi sering kali menyebabkan pengabaian aspek keamanan informasi yang sangat penting. Persyaratan pengembangan perangkat lunak biasanya berpusat pada fungsi dan menekankan aspek konstruktif, sehingga pandangan destruktif tentang potensi kerentanan keamanan sebagian besar bertentangan secara diametris dengan tujuan pengembangan yang sebenarnya: banyak programmer juga tidak memiliki pandangan yang terstruktur dan tajam tentang keamanan siber.

Dalam kondisi seperti ini, tim pengembangan mengalami kesulitan untuk terus meninjau dan secara konsisten mengamankan pengkodean perangkat lunak mereka, sebagaimana dibuktikan dengan banyaknya kerentanan yang diterbitkan oleh MITRE Corporation nirlaba setiap tahun dalam daftar CVE (Kerentanan dan Eksposur Umum). Patch keamanan reguler dari produsen perangkat lunak yang terkenal sekalipun merupakan indikator dari tugas berat untuk menutup bug yang berkaitan dengan keamanan, apalagi mengidentifikasi mereka bahkan sebelum diluncurkan ke pasar.

Kode Open Source - kasus khusus

Ketika mengkodekan perangkat lunak yang dikembangkan sendiri, para pemrogram suka menggunakan pustaka dan modul sumber terbuka. Keuntungan praktisnya sangat jelas: Jika Anda tidak perlu menemukan kembali roda berulang kali, Anda mendapatkan keuntungan dari dorongan teknologi ini, pengembangan yang cepat, biaya pengembangan yang lebih rendah, lebih banyak transparansi melalui kode sumber terbuka, dan interoperabilitas yang lebih tinggi melalui standar dan antarmuka terbuka.

Juga sering dikatakan bahwa kode dari sumber terbuka menawarkan tingkat keamanan yang tinggi karena kode tersebut telah divalidasi oleh banyak pengguna dan kecerdasan kawanan dari komunitas sumber terbuka memungkinkan perbaikan bug yang cepat dan efisien.

Dalam praktiknya, kepercayaan ini sekarang harus dievaluasi dengan cara yang berbeda dan kritis. Contoh paling serius adalah kerentanan keamanan zero-day Log4Shell dalam pustaka pencatatan yang banyak digunakan Log4J untuk aplikasi Java, yang ditemukan pada November 2021. Anda mungkin pernah mendengar tentang tingkat peringatan merah yang dikeluarkan oleh Kantor Federal Jerman untuk Keamanan Informasi (BSI) untuk Log4Shell. Pustaka Log4J, yang didistribusikan sebagai standar semu yang berfungsi dengan andal melalui Apache Foundation, telah memantapkan dirinya di banyak sistem sejak 2013 - termasuk layanan web terkenal seperti Amazon AWS.

Kompleksitas pustaka yang dikembangkan dengan baik dan juga dipelihara ini secara implisit menyediakan fungsionalitas yang kuat yang sering kali tidak disadari oleh pengembang yang mengimpor dalam pengembangan baru gabungannya sendiri, tetapi dapat dieksploitasi oleh penyerang.

Faktor ketidakamanan lain dari komponen open source adalah apa yang disebut dengan serangan rantai pasokan, yaitu kerentanan yang disengaja oleh aktor jahat yang berpura-pura menjadi bagian dari komunitas open source dan membantu pengembangan kode. Kerentanan seperti itu merupakan cara yang sangat efisien bagi peretas untuk menyerang sejumlah besar organisasi pengguna hilir. Maka, tidak heran jika vektor serangan ini berkembang pesat: studi Sonatype mendiagnosis peningkatan 650% saat membandingkan tahun 2020 dan 2021.

Kontrol keamanan informasi 8.28 pengkodean yang aman

Untuk melindungi proses pengembangan perangkat lunak secara tepat waktu, Organisasi Internasional untuk Standardisasi (ISO - komite ISO / IEC JTC 1 / SC 27) telah memasukkan "Pengkodean Aman" sebagai kontrol baru 8.28 dalam standar ISO / IEC 27002 dan ISO / IEC 27001: 2022 yang baru, Lampiran A. Tujuan dari tindakan teknis untuk pengkodean yang aman adalah perlindungan preventif perangkat lunak.

Tingkat keamanan minimum dibuat sejak tahap penulisan berdasarkan peraturan prosedural, sehingga meminimalkan jumlah potensi kerentanan keamanan dalam perangkat lunak. Kerangka kerja peraturan untuk pembuatan kode yang aman harus diterapkan secara menyeluruh baik untuk kode program perusahaan sendiri maupun untuk perangkat lunak dari pihak ketiga dan sumber sumber terbuka. Prinsip-prinsip penting untuk penerapannya adalah Security by Design dan Least Privilege, yang juga harus dipertimbangkan dalam pengkodean.

Prinsip-prinsip pengkodean yang aman

Langkah 8.28 membahas apa yang disebut prinsip-prinsip pengkodean yang aman beberapa kali. Panduan mengenai hal ini disediakan oleh banyak organisasi dan lembaga yang secara teratur mengeluarkan panduan dan praktik terbaik untuk penyandian yang aman. Ini termasuk, misalnya, Praktik Pengkodean Aman dari OWASP Foundation, Standar Pengkodean Aman dari Tim Tanggap Darurat Komputer (CERT) dari Software Engineering Institute (SEI), dan katalog tindakan BSI Jerman untuk keamanan aplikasi web. Meskipun sumbernya berbeda, penjabarannya menunjukkan banyak kesamaan, misalnya terkait poin-poin berikut ini:

• Validasi input data
• Mengamankan otentikasi dan manajemen kata sandi
• Kontrol akses yang aman
• Kode yang sederhana dan transparan
• Langkah-langkah dan komponen kriptografi yang teruji secara berkelanjutan
• Penanganan dan pencatatan kesalahan
• Perlindungan data
• Pemodelan ancaman

Dalam standar ISO/ISO 27002:2022, tindakan yang direkomendasikan untuk Kontrol 8.28 dibagi menjadi tiga bagian, "Perencanaan dan prapengkodean," "Selama pengkodean," dan "Verifikasi dan pemeliharaan," yang isi intinya diuraikan di bawah ini.

Perencanaan dan pengkodean awal

Baik pengembangan kode baru maupun penggunaan ulang kode memerlukan penerapan prinsip-prinsip pengkodean yang aman - terlepas dari apakah kode tersebut ditulis untuk perangkat lunak internal atau untuk produk dan layanan eksternal. Hal ini memerlukan evaluasi ekspektasi khusus organisasi dan definisi prinsip-prinsip yang diakui sebelumnya. Selain itu, tindakan yang direkomendasikan untuk perencanaan dan pengkodean awal mempertimbangkan praktik pengkodean umum dan historis yang diketahui dan kesalahan yang dapat menyebabkan kerentanan.

Konfigurasi alat pengembangan, seperti berbasis aturan dalam lingkungan pengembangan terintegrasi (IDE), harus menegakkan pembuatan kode yang aman. Yang cukup penting adalah kualifikasi pengembang dan keakraban mereka dengan arsitektur yang aman dan standar pemrograman. Penyertaan keahlian keamanan informasi dalam tim pengembangan tidak perlu diragukan lagi.

Selama proses pengkodean

Selama proses pengkodean, praktik pengkodean dan teknik pemrograman terstruktur memainkan peran utama, dengan mempertimbangkan kasus penggunaan spesifik dan kebutuhan keamanannya. Teknik desain yang tidak aman - misalnya, kata sandi yang dikodekan dengan keras - harus secara konsisten dilarang. Kode harus didokumentasikan dan ditinjau secara memadai untuk menghilangkan bug terkait keamanan. Peninjauan kode harus dilakukan selama dan setelah pengembangan, melalui pengujian keamanan aplikasi statis (SAST) atau yang serupa. Metode pengujian statis mendukung pendekatan shift left ("uji lebih awal dan sering") dengan menggeser ke kiri dalam siklus hidup dengan menguji kode yang terlihat untuk kesesuaian dengan aturan lebih awal.

Hal ini memungkinkan identifikasi awal kode yang tercemar, koneksi ke file atau kelas objek tertentu, atau celah tingkat aplikasi yang dapat disalahgunakan untuk interaksi tanpa disadari dengan program pihak ketiga sebagai kerentanan yang dapat dieksploitasi. Sebelum perangkat lunak dioperasikan, Control 8.28 memerlukan evaluasi permukaan serangan dan penerapan prinsip hak istimewa terkecil. Analisis yang dilakukan terhadap kesalahan pemrograman yang paling umum dan dokumentasi koreksinya harus dievaluasi.

Verifikasi dan pemeliharaan

Bahkan setelah perangkat lunak telah ditayangkan, topik pengkodean yang aman tetap relevan. Hal ini termasuk pembaruan yang aman serta pemeriksaan kerentanan yang diketahui dalam kode. Selain itu, kesalahan dan serangan yang dicurigai harus didokumentasikan sehingga penyesuaian yang diperlukan dapat segera dilakukan. Bagaimanapun, akses yang tidak sah ke kode sumber harus dapat dicegah dengan alat yang sesuai.

Kode Open Source

Di bidang verifikasi dan pemeliharaan, Langkah 8.28 juga mencantumkan instruksi eksplisit untuk penggunaan alat dan pustaka eksternal, seperti perangkat lunak sumber terbuka. Komponen kode ini harus dikelola, diperbarui, dan dipelihara dalam inventaris. Hal ini dapat dilakukan, misalnya, melalui Bill of Material (BOM) Perangkat Lunak. SBOM adalah catatan formal dan terstruktur dari paket dan pustaka perangkat lunak serta hubungannya satu sama lain dan di dalam rantai pasokan, khususnya untuk melacak kode yang digunakan kembali dan komponen sumber terbuka. SBOM mendukung pemeliharaan perangkat lunak dan pembaruan keamanan yang ditargetkan.

Kesimpulan

Kode yang aman adalah fondasi dasar untuk menghentikan potensi serangan. Control 8.28 yang baru mempertimbangkan wawasan yang sudah lama ada ini dan meningkatkan peran kunci dari pengkodean yang aman dalam hal pentingnya untuk keamanan informasi. Namun, karena langkah ini terdiri dari sejumlah besar rekomendasi tindakan yang terperinci dan secara teknis menuntut, implementasinya akan melibatkan tingkat upaya yang relatif tinggi - hal ini harus diperhitungkan sejak tahap perencanaan.

Dengan pandangan profesional dari para auditor kami yang berpengalaman, kami mendukung Anda dalam penerapan tindakan yang sesuai. Dengan keahlian audit dan sertifikasi kami selama lebih dari 35 tahun, kami adalah mitra ideal Anda dan dengan senang hati akan membantu Anda dengan topik keamanan informasi dan sertifikasi sesuai dengan standar ISO/IEC 27001:2022.

Revisi ISO 27001: Apa arti pembaruan untuk sertifikasi Anda?

ISO/IEC 27001:2022 diterbitkan pada tanggal 25 Oktober 2022. Hal ini menghasilkan tenggat waktu dan kerangka waktu berikut bagi pengguna untuk melakukan transisi:

Tanggal terakhir untuk audit awal/sertifikasi ulang menurut ISO 27001:2013 yang "lama"

• Setelah 30 April 2024, DQS akan melakukan audit awal dan sertifikasi ulang hanya sesuai dengan standar baru ISO/IEC 27001:2022

Transisi semua sertifikat yang ada sesuai dengan ISO/IEC 27001:2013 yang "lama" ke ISO/IEC 27001:2022 yang baru

• Ada masa transisi selama 3 tahun mulai dari 31 Oktober 2022
• Sertifikat yang diterbitkan menurut ISO/IEC 27001:2013 atau DIN EN ISO/IEC 27001:2017 berlaku hingga paling lambat 31 Oktober 2025, atau harus ditarik pada tanggal tersebut.

DQS: Simply Leveraging Security.

Karena masa transisi, perusahaan memiliki waktu yang cukup untuk menyesuaikan ISMS mereka sesuai dengan persyaratan baru dan mendapatkan sertifikasi. Namun, durasi dan upaya dari seluruh proses perubahan tidak boleh diremehkan - terutama jika Anda tidak memiliki personel khusus yang memadai. Jika Anda ingin berada di sisi yang aman, Anda harus menangani masalah ini lebih cepat daripada nanti dan memanggil spesialis berpengalaman jika perlu.

Sebagai ahli audit dan sertifikasi dengan pengalaman lebih dari 35 tahun, kami dengan senang hati membantu Anda mengevaluasi status Anda saat ini, mungkin sebagai bagian dari audit delta. Cari tahu dari banyak auditor berpengalaman kami tentang perubahan yang paling penting dan relevansinya bagi organisasi Anda. Bersama-sama kita akan mendiskusikan potensi Anda untuk peningkatan dan mendukung Anda sampai Anda menerima sertifikat baru Anda. Manfaatkan kompetensi kami dalam keamanan informasi! Kami tunggu kabar dari Anda.