Bagaimana kami menutup kerentanan di OS Astra Linux Edisi Khusus

Tidak ada sistem operasi tanpa kerentanan - satu-satunya pertanyaan adalah seberapa efektif pengembang mengidentifikasi dan menutupnya. Tidak terkecuali Astra Linux Special Edition kami: kami terus-menerus memeriksa dan menguji kode untuk kesalahan, pelanggaran logika, bug lain dan dengan cepat memperbaikinya. Kalau tidak, FSTEC Rusia tidak akan memiliki sertifikasi Astra Linux untuk memproses data yang merupakan rahasia negara. Tetapi kami akan berbicara tentang sertifikasi secara lebih rinci di pos lain. Dan dalam hal ini kita akan berbicara tentang bagaimana kerentanan Astra Linux diorganisasikan dan bagaimana ancaman keamanan informasi berinteraksi dengan bank data domestik.


Foto: Leonhard Foeger / Reuters

Pendekatan pertama, arsitektur

Untuk meningkatkan keamanan OS, kami menggunakan dua pendekatan. Yang pertama, arsitektur , adalah kita mengembangkan dan mengimplementasikan berbagai alat perlindungan informasi pada tahap desain. Alat-alat ini membentuk kompleks alat pelindung (KSZ) , yang mengimplementasikan fungsi keamanan. Dengan bantuan KSZ, kami berusaha memastikan bahwa sistem tersebut telah meminimalkan risiko ancaman potensial secara default.


Arsitektur Suite Keamanan Edisi Khusus Astra LInux

Elemen kunci KSZ adalah monitor panggilan , yang dirancang untuk mencegah akses tidak sah dan perubahan komponen yang dilindungi dari sistem. Monitor menyediakan kontrol akses yang bersifat diskresioner, berbasis peran, dan wajib, serta pemantauan integritas wajib.

Apa itu pemantauan integritas wajib ? Mari kita ilustrasikan dengan sebuah contoh. Komponen utama OS adalah kernel. Oleh karena itu, kami berkewajiban untuk menyediakan runtime paling aman di sistem operasi itu sendiri untuk mengurangi jumlah metode yang mungkin untuk menyerang kernel.

Untuk melakukan ini, kami menerapkan pemantauan integritas wajib dalam sistem operasi, karena itu kami mengelompokkan OS dengan berbagai subsistem sehingga memecah satu subsistem tidak mempengaruhi kinerja yang lain. Jika pengguna OS yang tidak terjangkau (tingkat integritas 0) atau subsistem jaringan (tingkat integritas 1), sistem virtualisasi (tingkat integritas 2), antarmuka grafis (tingkat integritas 8), atau komponen lain diretas, ini tidak akan mengharuskan mendiskreditkan seluruh KSZ (tingkat integritas). 63).

Perlu dicatat bahwa level-level ini tidak hierarkis, yaitu, mereka tidak terletak satu di atas yang lain dan sepenuhnya terisolasi satu sama lain dalam hal kemungkinan hak menulis. Monitor akses menentukan aksesori suatu objek ke tingkat integritas satu atau lainnya oleh bitmask.



Sehingga level integritas tidak dianggap sebagai hierarkis - yaitu, misalnya, "level 8 memiliki hak lebih dari level 2", yang salah - masing-masing level mendapatkan namanya. Jadi, misalnya, tingkat integritas kedelapan disebut "Server Grafis", tingkat integritas maksimum yang mungkin dari administrator dalam sistem adalah "Tinggi", dan tingkat nol integritas (pengguna) adalah "Rendah".

Monitor panggilan, yang dijelaskan dalam artikel kami sebelumnya, mengontrol dan menghilangkan kemungkinan pengaruh pada setiap proses lainnya dengan label berbagai tingkat integritas.

Dengan demikian, sistem operasi menerima seperangkat aturan tentang cara mengisolasi proses sistem dari satu sama lain, dan sekarang memahami proses mana, bahkan yang diluncurkan oleh pengguna dengan hak istimewa tinggi, tidak memiliki hak untuk menulis ke proses atau file lain.

Oleh karena itu, jika sebagai akibat dari eksploitasi kerentanan (termasuk zero day), penyerang mendapatkan kendali atas suatu proses dalam sistem dan meningkatkan otoritasnya kepada pengguna yang memiliki hak istimewa (misalnya, root), tanda integritasnya akan tetap sama, dan karenanya, ia tidak akan menerima kemampuan untuk memengaruhi proses sistem, mengubah pengaturan atau menyembunyikan keberadaan Anda di sistem.


Prinsip operasi tingkat integritas yang terisolasi

Dengan demikian, tidak seluruh sistem operasi menjadi target yang signifikan bagi penyerang, tetapi hanya kernel yang mengeras dan monitor akses paling ringkas, yang sudah secara signifikan mengurangi permukaan serangan.

Selain wajib, ada juga kontrol integritas yang dinamis dan regulasi. Mereka digunakan untuk mengecualikan peluncuran dan penggunaan perangkat lunak pihak ketiga atau tidak dipercaya, serta pemeriksaan berkala terhadap integritas sistem.

Kontrol dinamis menghitung dan memverifikasi tanda tangan digital elektronik dari file yang dapat dieksekusi pada saat peluncurannya. Jika tidak ada EDS atau jika tidak benar, peluncuran program akan ditolak. Sampai batas tertentu, ini merupakan implementasi dari konsep daftar putih, tetapi melalui penggunaan hierarki kunci yang dikeluarkan untuk pengembang perangkat lunak.


Bekerja dengan kontrol integritas dinamis

Kontrol rutin memeriksa integritas dan imutabilitas file kunci untuk suatu sistem dengan membandingkan checksum mereka dengan nilai referensi. Ini bisa berupa file konfigurasi, atau yang lainnya.

Dengan demikian, OS menggunakan perlindungan berlapis terhadap kerentanan dalam aplikasi dan penggantiannya, sehingga meminimalkan kerusakan dari ancaman keamanan, termasuk yang menggunakan kerentanan zero-day.

Yang kedua, pendekatan proses

Seiring dengan arsitekturnya, kami secara bersamaan menggunakan pendekatan proses : kami terus-menerus mengidentifikasi dan mengumpulkan informasi tentang kerentanan, bekerja melalui informasi ini dan mentransfer hasilnya ke bank data kerentanan Rusia FSTEC. Jadi kami mempersiapkan dan merilis pembaruan OS yang dijadwalkan dan operasional. Kami mencari kerentanan baik di sumber terbuka maupun secara mandiri - terutama di bagian perangkat lunak yang kami kembangkan sendiri. Kami mendapatkan banyak informasi dari mitra yang terlibat dalam penelitian serupa - menguji dan mempelajari keamanan sistem operasi.


Manajemen Kerentanan

Studi keamanan terutama dilakukan sehubungan dengan komponen yang merupakan bagian dari Edisi Khusus Astra Linux (Smolensk). Pada saat yang sama, kerentanan juga ditutup untuk Astra Linux Common Edition, baik sebagai bagian dari pembaruan keamanan dan sebagai bagian dari pembaruan yang dijadwalkan untuk komponen sistem.

Segera setelah kami menerima informasi tentang kerentanan, kami memeriksa seberapa relevannya bagi pengguna kami. Jika kerentanannya tidak kritis, maka kami akan menjelaskannya dalam terbitan buletin keamanan berikutnya di situs web resmi. Pemberitahuan tentang masalah surat suara dikirimkan kepada pengguna melalui email, alamat yang harus ditunjukkan dalam perjanjian lisensi. Untuk kerentanan kritis, pedoman dikeluarkan selama beberapa hari : bagaimana Anda bisa memperbaikinya sendiri tanpa menunggu pembaruan keamanan kumulatif. Dalam daftar buletin keamanan, mereka ditandai dengan huruf MD (arah metodis).

Kerentanan adalah contoh yang baik di sini, informasi tentang yang diterbitkan di sini di Habré. Ngomong-ngomong, penulis artikel ini tidak menghubungi kami sebelumnya dan tidak memberitahukan sebelumnya bahwa ia telah mengidentifikasi kerentanan ini dan sedang mempersiapkan materi. Sebagai ilustrasi, kami memutuskan untuk mengutip waktu pengerjaan kerentanan sejak saat teks diposting di sumber daya.

Jadi, pada malam hari, jam 4 pagi, pada 9 Juli 2019, artikel itu sendiri diterbitkan, bahwa ketika memanipulasi ukuran layar mesin virtual, Anda dapat melihat jendela di bawah kunci layar.

Perlu dicatat bahwa untuk mengeksploitasi kerentanan yang ditunjukkan pada video, Anda perlu melakukan sejumlah langkah tambahan: pertama-tama Anda harus menginstal paket tambahan pada mesin virtual Astra Linux, dan kemudian pada mesin tamu, yang bertanggung jawab untuk mengubah resolusi mesin virtual dengan cepat, tetapi tidak adalah bagian dari sistem operasi bersertifikat.

Pada 10 Juli 2019, informasi kerentanan dipublikasikan di FSTEC BDU. Tingkat keparahan kerentanan didefinisikan sebagai sedang (skor dasar untuk metrik CVSS 2.0 adalah 4.9, untuk metrik CVSS 3.0 - 4).

Pada 12 Juli, kami menerbitkan buletin keamanan No. 20190712SE16MD untuk Astra Linux Edisi Khusus versi 1.6 dan buletin keamanan No. 20190712SE15MD untuk Astra Linux Edisi Khusus versi 1.5. Pembaruan keamanan serupa diterima oleh Astra Linux Common Edition.

Dengan demikian, kurang dari 4 hari telah berlalu sejak publikasi informasi tentang kerentanan tingkat menengah terhadap pelepasan tambalan untuk semua versi Astra Linux (di mana virtualisasi dimungkinkan).


Skema Pembaruan Langsung untuk Astra Linux

Paling tidak sekali seperempat, kami merilis pembaruan keamanan - pembaruan operasional yang menghilangkan kerentanan yang sebelumnya tidak diketahui, termasuk perangkat lunak aplikasi, perpustakaan dan fungsi OS yang tidak menerapkan persyaratan keamanan. Jika ancaman keamanan yang diterapkan menggunakan kerentanan tidak dapat dikesampingkan dengan langkah-langkah kompensasi, pekerjaan sedang dilakukan untuk menyelesaikan OS. Setelah selesai pengembangan dan pengujian pembaruan keamanan, situs web juga menerbitkan buletin dan pembaruan itu sendiri. Dalam enam bulan pertama 2019, dua pembaruan kumulatif untuk Astra Linux Edisi Khusus versi 1.6 dirilis, mencakup ratusan kerentanan berbeda. Sekarang yang ketiga sedang dipersiapkan untuk dirilis.

Akhirnya, kami secara aktif berinteraksi dengan komunitas pengembang:

• Kami menginformasikan dalam bugtracker proyek tentang kesalahan yang terdeteksi sendiri;
  
• kami mentransfer ke koreksi kekurangan yang sudah jadi dari proyek, ditutup oleh kami;
  
• kami menghimbau masyarakat untuk membantu menghilangkan kekurangan - pengetahuan tentang logika program memungkinkan Anda untuk mendapatkan urutan koreksi yang lebih cepat lebih cepat daripada rekayasa balik yang dilakukan sendiri;
  
• Kami menggunakan dan memasukkan dalam pembaruan kami semua perbaikan yang dikeluarkan komunitas. Kami memahami bahwa dengan demikian meningkatkan kualitas produk. Pada saat yang sama, kami menerapkan metode pengendalian dan pengembangan kepercayaan, yang dijelaskan dalam artikel sebelumnya .
  

Keterbukaan itu penting

Karena OS kami disertifikasi oleh FSTEC Rusia, kami pertama-tama menambahkan informasi tentang kerentanan yang ditemukan di Bank Data Ancaman Keamanan Informasi (DBU) FSTEC untuk publikasi resmi: jika Anda pergi ke DBU , Anda akan menemukan informasi tentang lebih dari 350 kerentanan tetap di berbagai versi Astra Linux serta informasi rinci tentang mereka.



Dengan demikian, kami memastikan keterbukaan dalam bekerja. Berkat ini, pengguna - termasuk regulator - dapat sedikit banyak yakin bahwa keselamatan memang terkendali. Tidak cukup untuk mendapatkan pembaruan, Anda perlu memahami kerentanan spesifik apa yang ditutup.

Sejauh ini, pendekatan arsitektur dan proses kami untuk menjaga keamanan OS sepenuhnya dibenarkan - kami berhasil mempertahankan tingkat keamanan yang tinggi untuk sistem informasi dengan OS Astra Edisi Khusus Linux. Dan membuka akses ke informasi tentang kerentanan melalui panel kontrol FSTEC meningkatkan tingkat kepercayaan pada produk kami.

Kami akan dengan senang hati menjawab pertanyaan tentang keamanan sistem kami di komentar. Juga, jika Anda tertarik untuk mempelajari sesuatu yang baru tentang sistem, tinggalkan keinginan Anda - kami akan mempertimbangkannya saat bekerja lebih jauh dengan blog.