Keamanan informasi pembayaran nontunai bank. Bagian 8 - Model Ancaman yang Khas

Keamanan informasi pembayaran nontunai bank. Bagian 8 - Model Ancaman yang Khas
Tentang apa studinya?

Tautan ke bagian lain dari penelitian ini

Artikel ini melengkapi rangkaian publikasi yang ditujukan untuk memastikan keamanan informasi pembayaran nontunai bank. Di sini kita akan melihat model ancaman umum yang dimaksud model dasar:

PERINGATAN HABRO!!! Khabrovites yang terhormat, ini bukan postingan yang menghibur.
40+ halaman materi yang disembunyikan di bawah potongan dimaksudkan untuk itu membantu pekerjaan atau belajar orang yang berspesialisasi dalam perbankan atau keamanan informasi. Materi-materi ini merupakan produk akhir penelitian dan ditulis dengan nada yang kering dan formal. Intinya, ini adalah formulir untuk dokumen keamanan informasi internal.

Nah, tradisional - “penggunaan informasi dari artikel untuk tujuan ilegal dapat dihukum oleh hukum”. Bacaan produktif!


Informasi bagi pembaca yang sudah familiar dengan kajian yang dimulai dengan publikasi ini.

Tentang apa studinya?

Anda sedang membaca panduan untuk spesialis yang bertanggung jawab memastikan keamanan informasi pembayaran di bank.

Logika presentasi

Pada awalnya di 1 bagian и 2 bagian deskripsi objek yang dilindungi diberikan. Lalu masuk 3 bagian menjelaskan cara membangun sistem keamanan dan berbicara tentang perlunya membuat model ancaman. DI DALAM 4 bagian berbicara tentang model ancaman apa yang ada dan bagaimana mereka terbentuk. DI DALAM 5 bagian и 6 bagian Analisis serangan nyata disediakan. Часть 7 и Bagian 8 berisi deskripsi model ancaman, yang dibangun dengan mempertimbangkan informasi dari semua bagian sebelumnya.

MODEL ANCAMAN KHUSUS. KONEKSI JARINGAN

Objek perlindungan yang model ancaman (cakupannya) diterapkan

Objek perlindungan adalah data yang dikirimkan melalui koneksi jaringan yang beroperasi di jaringan data yang dibangun berdasarkan tumpukan TCP/IP.

Arsitektur

Keamanan informasi pembayaran nontunai bank. Bagian 8 - Model Ancaman yang Khas

Deskripsi elemen arsitektur:

  • "Node Akhir" — node bertukar informasi yang dilindungi.
  • "Node perantara" — elemen jaringan transmisi data: router, switch, server akses, server proxy, dan peralatan lainnya — yang melaluinya lalu lintas koneksi jaringan ditransmisikan. Secara umum, koneksi jaringan dapat berfungsi tanpa node perantara (langsung antar node akhir).

Ancaman keamanan tingkat atas

Penguraian

U1. Akses tidak sah ke data yang dikirimkan.
U2. Modifikasi tidak sah atas data yang dikirimkan.
U3. Pelanggaran kepenulisan data yang dikirimkan.

U1. Akses tidak sah ke data yang dikirimkan

Penguraian
U1.1. <…>, dilakukan pada node akhir atau perantara:
U1.1.1. <…> dengan membaca data saat berada di perangkat penyimpanan host:
U1.1.1.1. <…> dalam RAM.
Penjelasan untuk U1.1.1.1.
Misalnya, selama pemrosesan data oleh tumpukan jaringan host.

U1.1.1.2. <…> dalam memori non-volatil.
Penjelasan untuk U1.1.1.2.
Misalnya, saat menyimpan data yang dikirimkan dalam cache, file sementara, atau file swap.

U1.2. <…>, dilakukan pada node pihak ketiga dari jaringan data:
U1.2.1. <…> dengan metode menangkap semua paket yang tiba di antarmuka jaringan host:
Penjelasan untuk U1.2.1.
Penangkapan semua paket dilakukan dengan mengalihkan kartu jaringan ke mode promiscuous (mode promiscuous untuk adaptor kabel atau mode monitor untuk adaptor wi-fi).

U1.2.2. <…> dengan melakukan serangan man-in-the-middle (MiTM), tetapi tanpa mengubah data yang dikirimkan (tidak termasuk data layanan protokol jaringan).
U1.2.2.1. Tautan: “Model ancaman yang khas. Koneksi jaringan. U2. Modifikasi tidak sah atas data yang dikirimkan".

U1.3. <…>, dilakukan karena adanya kebocoran informasi melalui saluran teknis (TKUI) dari node fisik atau jalur komunikasi.

U1.4. <…>, dilakukan dengan memasang sarana teknis khusus (STS) pada simpul akhir atau perantara, yang dimaksudkan untuk pengumpulan informasi secara rahasia.

U2. Modifikasi tidak sah atas data yang dikirimkan

Penguraian
U2.1. <…>, dilakukan pada node akhir atau perantara:
U2.1.1. <…> dengan membaca dan membuat perubahan pada data saat berada di perangkat penyimpanan node:
U2.1.1.1. <…> dalam RAM:
U2.1.1.2. <…> dalam memori non-volatil:

U2.2. <…>, dilakukan pada node pihak ketiga dari jaringan transmisi data:
U2.2.1. <…> dengan melakukan serangan man-in-the-middle (MiTM) dan mengarahkan lalu lintas ke node penyerang:
U2.2.1.1. Koneksi fisik peralatan penyerang menyebabkan koneksi jaringan terputus.
U2.2.1.2. Melakukan serangan terhadap protokol jaringan:
U2.2.1.2.1. <…> pengelolaan jaringan lokal virtual (VLAN):
U2.2.1.2.1.1. VLAN melompat.
U2.2.1.2.1.2. Modifikasi pengaturan VLAN yang tidak sah pada switch atau router.
U2.2.1.2.2. <…> perutean lalu lintas:
U2.2.1.2.2.1. Modifikasi yang tidak sah dari tabel routing statis pada router.
U2.2.1.2.2.2. Pengumuman rute palsu oleh penyerang melalui protokol routing dinamis.
U2.2.1.2.3. <…> konfigurasi otomatis:
U2.2.1.2.3.1. DHCP nakal.
U2.2.1.2.3.2. WPAD nakal.
U2.2.1.2.4. <…> pengalamatan dan resolusi nama:
U2.2.1.2.4.1. spoofing ARP.
U2.2.1.2.4.2. DNS spoofing.
U2.2.1.2.4.3. Membuat perubahan tidak sah pada file nama host lokal (host, lmhosts, dll.)

U3. Pelanggaran hak cipta atas data yang dikirimkan

Penguraian
U3.1. Netralisasi mekanisme penentuan kepenulisan informasi dengan menunjukkan informasi palsu tentang penulis atau sumber data:
U3.1.1. Mengubah informasi tentang penulis yang terkandung dalam informasi yang dikirimkan.
U3.1.1.1. Netralisasi perlindungan kriptografi terhadap integritas dan kepenulisan data yang dikirimkan:
U3.1.1.1.1. Tautan: “Model ancaman yang khas. Sistem perlindungan informasi kriptografi.
U4. Pembuatan tanda tangan elektronik dari penandatangan yang sah berdasarkan data palsu"
.
U3.1.1.2. Netralisasi perlindungan hak cipta atas data yang dikirimkan, diterapkan menggunakan kode konfirmasi satu kali:
U3.1.1.2.1. Swap SIM.

U3.1.2. Mengubah informasi tentang sumber informasi yang dikirimkan:
U3.1.2.1. Spoofing IP.
U3.1.2.2. pemalsuan MAC.

MODEL ANCAMAN KHUSUS. SISTEM INFORMASI DIBANGUN BERDASARKAN ARSITEKTUR CLIENT-SERVER

Objek perlindungan yang model ancaman (cakupannya) diterapkan

Objek proteksinya adalah sistem informasi yang dibangun berdasarkan arsitektur client-server.

Arsitektur
Keamanan informasi pembayaran nontunai bank. Bagian 8 - Model Ancaman yang Khas

Deskripsi elemen arsitektur:

  • "Klien" – perangkat tempat bagian klien dari sistem informasi beroperasi.
  • "Server" – perangkat tempat bagian server dari sistem informasi beroperasi.
  • "Penyimpanan data" — bagian dari infrastruktur server suatu sistem informasi, yang dirancang untuk menyimpan data yang diproses oleh sistem informasi.
  • "Koneksi jaringan" — saluran pertukaran informasi antara Klien dan Server melewati jaringan data. Penjelasan lebih rinci tentang model elemen diberikan dalam “Model ancaman yang khas. Koneksi jaringan".

Pembatasan
Saat memodelkan suatu objek, batasan berikut ditetapkan:

  1. Pengguna berinteraksi dengan sistem informasi dalam periode waktu terbatas, yang disebut sesi kerja.
  2. Pada awal setiap sesi kerja, pengguna diidentifikasi, diautentikasi, dan diberi otorisasi.
  3. Semua informasi yang dilindungi disimpan di bagian server sistem informasi.

Ancaman keamanan tingkat atas

Penguraian
U1. Melakukan tindakan tidak sah oleh penyerang atas nama pengguna yang sah.
U2. Modifikasi yang tidak sah atas informasi yang dilindungi selama pemrosesannya oleh bagian server dari sistem informasi.

U1. Melakukan tindakan tidak sah oleh penyerang atas nama pengguna yang sah

Penjelasan
Biasanya dalam sistem informasi, tindakan dikorelasikan dengan pengguna yang melakukan tindakan tersebut menggunakan:

  1. log operasi sistem (log).
  2. atribut khusus objek data yang berisi informasi tentang pengguna yang membuat atau memodifikasinya.

Sehubungan dengan sesi kerja, ancaman ini dapat diuraikan menjadi:

  1. <…> dilakukan dalam sesi pengguna.
  2. <…> dieksekusi di luar sesi pengguna.

Sesi pengguna dapat dimulai:

  1. Oleh pengguna itu sendiri.
  2. Penjahat.

Pada tahap ini, dekomposisi menengah dari ancaman ini akan terlihat seperti ini:
U1.1. Tindakan tidak sah dilakukan dalam sesi pengguna:
U1.1.1. <…> dipasang oleh pengguna yang diserang.
U1.1.2. <…> dipasang oleh penyerang.
U1.2. Tindakan tidak sah dilakukan di luar sesi pengguna.

Dari sudut pandang objek infrastruktur informasi yang dapat dipengaruhi oleh penyerang, penguraian ancaman perantara akan terlihat seperti ini:

Item
Dekomposisi Ancaman

U1.1.1.
U1.1.2.
U1.2.

Klien
U1.1.1.1.
U1.1.2.1.

Koneksi jaringan
U1.1.1.2.

Server

U1.2.1.

Penguraian
U1.1. Tindakan tidak sah dilakukan dalam sesi pengguna:
U1.1.1. <…> dipasang oleh pengguna yang diserang:
U1.1.1.1. Para penyerang bertindak secara independen dari Klien:
U1.1.1.1.1 Para penyerang menggunakan alat akses sistem informasi standar:
У1.1.1.1.1.1. Penyerang menggunakan sarana input/output fisik Klien (keyboard, mouse, monitor, atau layar sentuh perangkat seluler):
U1.1.1.1.1.1.1. Penyerang beroperasi selama periode waktu ketika sesi aktif, fasilitas I/O tersedia, dan pengguna tidak hadir.
У1.1.1.1.1.2. Penyerang menggunakan alat administrasi jarak jauh (standar atau disediakan oleh kode berbahaya) untuk mengontrol Klien:
U1.1.1.1.1.2.1. Penyerang beroperasi selama periode waktu ketika sesi aktif, fasilitas I/O tersedia, dan pengguna tidak hadir.
U1.1.1.1.1.2.2. Para penyerang menggunakan alat administrasi jarak jauh, yang pengoperasiannya tidak terlihat oleh pengguna yang diserang.
U1.1.1.2. Penyerang mengganti data dalam koneksi jaringan antara Klien dan Server, memodifikasinya sedemikian rupa sehingga dianggap sebagai tindakan pengguna yang sah:
U1.1.1.2.1. Tautan: “Model ancaman yang khas. Koneksi jaringan. U2. Modifikasi tidak sah atas data yang dikirimkan".
U1.1.1.3. Para penyerang memaksa pengguna untuk melakukan tindakan yang mereka tentukan menggunakan metode rekayasa sosial.

У1.1.2 <…> dipasang oleh penyerang:
U1.1.2.1. Penyerang bertindak dari Klien (И):
U1.1.2.1.1. Para penyerang menetralisir sistem kontrol akses sistem informasi:
U1.1.2.1.1.1. Tautan: “Model ancaman yang khas. Sistem kontrol akses. U1. Pembuatan sesi yang tidak sah atas nama pengguna yang sah".
У1.1.2.1.2. Para penyerang menggunakan alat akses sistem informasi standar
U1.1.2.2. Penyerang beroperasi dari node lain di jaringan data, dari mana koneksi jaringan ke Server dapat dibuat (И):
U1.1.2.2.1. Para penyerang menetralisir sistem kontrol akses sistem informasi:
U1.1.2.2.1.1. Tautan: “Model ancaman yang khas. Sistem kontrol akses. U1. Pembuatan sesi yang tidak sah atas nama pengguna yang sah".
U1.1.2.2.2. Para penyerang menggunakan cara non-standar untuk mengakses sistem informasi.
Penjelasan U1.1.2.2.2.
Penyerang dapat menginstal klien standar sistem informasi pada node pihak ketiga atau dapat menggunakan perangkat lunak non-standar yang mengimplementasikan protokol pertukaran standar antara Klien dan Server.

U1.2 Tindakan tidak sah dilakukan di luar sesi pengguna.
U1.2.1 Penyerang melakukan tindakan tidak sah dan kemudian membuat perubahan tidak sah pada log operasi sistem informasi atau atribut khusus objek data, yang menunjukkan bahwa tindakan yang mereka lakukan dilakukan oleh pengguna yang sah.

U2. Modifikasi yang tidak sah atas informasi yang dilindungi selama pemrosesannya oleh bagian server dari sistem informasi

Penguraian
U2.1. Penyerang memodifikasi informasi yang dilindungi menggunakan alat sistem informasi standar dan melakukan ini atas nama pengguna yang sah.
U2.1.1. Tautan: “Model ancaman yang khas. Sebuah sistem informasi yang dibangun pada arsitektur client-server. U1. Melakukan tindakan tidak sah oleh penyerang atas nama pengguna yang sah".

U2.2. Penyerang mengubah informasi yang dilindungi dengan menggunakan mekanisme akses data yang tidak disediakan oleh operasi normal sistem informasi.
U2.2.1. Penyerang memodifikasi file yang berisi informasi yang dilindungi:
U2.2.1.1. <…>, menggunakan mekanisme penanganan file yang disediakan oleh sistem operasi.
U2.2.1.2. <…> dengan memprovokasi pemulihan file dari salinan cadangan modifikasi yang tidak sah.

U2.2.2. Penyerang memodifikasi informasi yang dilindungi yang disimpan dalam database (И):
U2.2.2.1. Penyerang menetralisir sistem kontrol akses DBMS:
U2.2.2.1.1. Tautan: “Model ancaman yang khas. Sistem kontrol akses. U1. Pembuatan sesi yang tidak sah atas nama pengguna yang sah".
U2.2.2.2. Penyerang memodifikasi informasi menggunakan antarmuka DBMS standar untuk mengakses data.

U2.3. Penyerang memodifikasi informasi yang dilindungi dengan modifikasi tidak sah dari algoritma operasi perangkat lunak yang memprosesnya.
U2.3.1. Kode sumber perangkat lunak dapat dimodifikasi.
U2.3.1. Kode mesin perangkat lunak dapat dimodifikasi.

U2.4. Penyerang memodifikasi informasi yang dilindungi dengan mengeksploitasi kerentanan dalam perangkat lunak sistem informasi.

U2.5. Penyerang mengubah informasi yang dilindungi ketika ditransfer antar komponen bagian server dari sistem informasi (misalnya, server database dan server aplikasi):
U2.5.1. Tautan: “Model ancaman yang khas. Koneksi jaringan. U2. Modifikasi tidak sah atas data yang dikirimkan".

MODEL ANCAMAN KHUSUS. SISTEM KONTROL AKSES

Objek perlindungan yang model ancaman (cakupannya) diterapkan

Objek perlindungan yang menerapkan model ancaman ini sesuai dengan objek perlindungan model ancaman: “Model ancaman tipikal. Sebuah sistem informasi yang dibangun di atas arsitektur client-server.”

Dalam model ancaman ini, sistem kontrol akses pengguna berarti komponen sistem informasi yang mengimplementasikan fungsi-fungsi berikut:

  1. Identifikasi pengguna.
  2. Otentikasi pengguna.
  3. Otorisasi pengguna.
  4. Mencatat tindakan pengguna.

Ancaman keamanan tingkat atas

Penguraian
U1. Pembuatan sesi yang tidak sah atas nama pengguna yang sah.
U2. Peningkatan hak pengguna yang tidak sah dalam suatu sistem informasi.

U1. Pembuatan sesi yang tidak sah atas nama pengguna yang sah

Penjelasan
Penguraian ancaman ini umumnya bergantung pada jenis sistem identifikasi dan otentikasi pengguna yang digunakan.

Dalam model ini, hanya sistem identifikasi dan otentikasi pengguna menggunakan login teks dan kata sandi yang akan dipertimbangkan. Dalam hal ini, kami berasumsi bahwa login pengguna adalah informasi publik yang diketahui penyerang.

Penguraian
U1.1. <…> karena kompromi kredensial:
U1.1.1. Para penyerang mengkompromikan kredensial pengguna saat menyimpannya.
Penjelasan U1.1.1.
Misalnya, kredensial dapat ditulis pada catatan tempel yang ditempel di monitor.

U1.1.2. Pengguna secara tidak sengaja atau jahat meneruskan detail akses kepada penyerang.
U1.1.2.1. Pengguna mengucapkan kredensialnya dengan keras saat mereka masuk.
U1.1.2.2. Pengguna dengan sengaja membagikan kredensialnya:
U1.1.2.2.1. <…> kepada rekan kerja.
Penjelasan U1.1.2.2.1.
Misalnya saja agar bisa menggantikannya saat sakit.

U1.1.2.2.2. <…> kepada kontraktor pemberi kerja yang melakukan pekerjaan pada objek infrastruktur informasi.
U1.1.2.2.3. <…> kepada pihak ketiga.
Penjelasan U1.1.2.2.3.
Salah satu, namun bukan satu-satunya pilihan untuk menerapkan ancaman ini adalah penggunaan metode rekayasa sosial oleh penyerang.

U1.1.3. Penyerang memilih kredensial menggunakan metode brute force:
U1.1.3.1. <…> menggunakan mekanisme akses standar.
U1.1.3.2. <…> menggunakan kode yang disadap sebelumnya (misalnya, hash kata sandi) untuk menyimpan kredensial.

U1.1.4. Para penyerang menggunakan kode berbahaya untuk mencegat kredensial pengguna.

U1.1.5. Penyerang mengekstrak kredensial dari koneksi jaringan antara Klien dan Server:
U1.1.5.1. Tautan: “Model ancaman yang khas. Koneksi jaringan. U1. Akses tidak sah ke data yang dikirimkan".

U1.1.6. Para penyerang mengekstrak kredensial dari catatan sistem pemantauan kerja:
U1.1.6.1. <…> sistem pengawasan video (jika penekanan tombol pada keyboard direkam selama pengoperasian).
U1.1.6.2. <…> sistem untuk memantau tindakan karyawan di depan komputer
Penjelasan U1.1.6.2.
Contoh dari sistem tersebut adalah Polisi Barang.

U1.1.7. Penyerang mengkompromikan kredensial pengguna karena kelemahan dalam proses transmisi.
Penjelasan U1.1.7.
Misalnya, mengirimkan password dalam bentuk teks jelas melalui email.

U1.1.8. Penyerang memperoleh kredensial dengan memantau sesi pengguna menggunakan sistem administrasi jarak jauh.

U1.1.9. Para penyerang memperoleh kredensial sebagai akibat dari kebocoran mereka melalui saluran teknis (TCUI):
U1.1.9.1. Para penyerang mengamati bagaimana pengguna memasukkan kredensial dari keyboard:
U1.1.9.1.1 Para penyerang berada di dekat pengguna dan melihat masuknya kredensial dengan mata kepala mereka sendiri.
Penjelasan U1.1.9.1.1
Kasus tersebut mencakup tindakan rekan kerja atau kasus ketika keyboard pengguna terlihat oleh pengunjung organisasi.

U1.1.9.1.2 Para penyerang menggunakan sarana teknis tambahan, seperti teropong atau kendaraan udara tak berawak, dan melihat masuknya kredensial melalui jendela.
U1.1.9.2. Penyerang mengekstrak kredensial dari komunikasi radio antara keyboard dan unit sistem komputer saat keduanya terhubung melalui antarmuka radio (misalnya, Bluetooth).
U1.1.9.3. Para penyerang mencegat kredensial dengan membocorkannya melalui saluran radiasi dan interferensi elektromagnetik palsu (PEMIN).
Penjelasan U1.1.9.3.
Contoh serangan di sini и di sini.

U1.1.9.4. Penyerang mencegat masuknya kredensial dari keyboard melalui penggunaan sarana teknis khusus (STS) yang dirancang untuk memperoleh informasi secara diam-diam.
Penjelasan U1.1.9.4.
contoh perangkat.

U1.1.9.5. Para penyerang mencegat masukan kredensial dari keyboard menggunakan
analisis sinyal Wi-Fi yang dimodulasi oleh proses penekanan tombol pengguna.
Penjelasan U1.1.9.5.
Contoh serangan.

U1.1.9.6. Para penyerang mencegat masukan kredensial dari keyboard dengan menganalisis suara penekanan tombol.
Penjelasan U1.1.9.6.
Contoh serangan.

U1.1.9.7. Para penyerang mencegat masuknya kredensial dari keyboard perangkat seluler dengan menganalisis pembacaan accelerometer.
Penjelasan U1.1.9.7.
Contoh serangan.

U1.1.10. <…>, sebelumnya disimpan di Klien.
Penjelasan U1.1.10.
Misalnya, pengguna dapat menyimpan login dan kata sandi di browser untuk mengakses situs tertentu.

U1.1.11. Penyerang membobol kredensial karena kelemahan dalam proses pencabutan akses pengguna.
Penjelasan U1.1.11.
Misalnya, setelah seorang pengguna dipecat, akunnya tetap tidak diblokir.

U1.2. <…> dengan mengeksploitasi kerentanan dalam sistem kontrol akses.

U2. Peningkatan hak pengguna yang tidak sah dalam sistem informasi

Penguraian
U2.1 <…> dengan membuat perubahan tidak sah pada data yang berisi informasi tentang hak istimewa pengguna.

U2.2 <…> melalui penggunaan kerentanan dalam sistem kontrol akses.

U2.3. <…> karena kekurangan dalam proses manajemen akses pengguna.
Penjelasan U2.3.
Contoh 1. Pengguna diberi lebih banyak akses untuk bekerja daripada yang dibutuhkannya untuk alasan bisnis.
Contoh 2: Setelah pengguna dipindahkan ke posisi lain, hak akses yang diberikan sebelumnya tidak dicabut.

MODEL ANCAMAN KHUSUS. MODUL INTEGRASI

Objek perlindungan yang model ancaman (cakupannya) diterapkan

Modul integrasi adalah sekumpulan objek infrastruktur informasi yang dirancang untuk mengatur pertukaran informasi antar sistem informasi.

Mengingat kenyataan bahwa dalam jaringan perusahaan tidak selalu mungkin untuk secara jelas memisahkan satu sistem informasi dari yang lain, modul integrasi juga dapat dianggap sebagai penghubung antar komponen dalam satu sistem informasi.

Arsitektur
Diagram umum modul integrasi terlihat seperti ini:

Keamanan informasi pembayaran nontunai bank. Bagian 8 - Model Ancaman yang Khas

Deskripsi elemen arsitektur:

  • "Server Pertukaran (JADI)" – suatu node/layanan/komponen suatu sistem informasi yang menjalankan fungsi pertukaran data dengan sistem informasi lain.
  • "Penengah" – sebuah node/layanan yang dirancang untuk mengatur interaksi antar sistem informasi, namun bukan bagian dari sistem tersebut.
    Contohnya "Perantara" mungkin ada layanan email, bus layanan perusahaan (bus layanan perusahaan/arsitektur SoA), server file pihak ketiga, dll. Secara umum, modul integrasi tidak boleh berisi “Perantara”.
  • "Perangkat lunak pengolah data" – seperangkat program yang mengimplementasikan protokol pertukaran data dan konversi format.
    Misalnya, mengubah data dari format UFEBS ke format ABS, mengubah status pesan selama transmisi, dll.
  • "Koneksi jaringan" sesuai dengan objek yang dijelaskan dalam model ancaman “Koneksi jaringan” standar. Beberapa koneksi jaringan yang ditunjukkan pada diagram di atas mungkin tidak ada.

Contoh modul integrasi

Skema 1. Integrasi ABS dan AWS KBR melalui server file pihak ketiga

Untuk melaksanakan pembayaran, pegawai bank yang berwenang mengunduh dokumen pembayaran elektronik dari sistem perbankan inti dan menyimpannya ke file (dalam formatnya sendiri, misalnya dump SQL) di folder jaringan (...SHARE) di server file. Kemudian file ini diubah menggunakan skrip konverter menjadi sekumpulan file dalam format UFEBS, yang kemudian dibaca oleh workstation CBD.
Setelah itu, karyawan yang berwenang - pengguna tempat kerja otomatis KBR - mengenkripsi dan menandatangani file yang diterima dan mengirimkannya ke sistem pembayaran Bank Rusia.

Ketika pembayaran diterima dari Bank Rusia, tempat kerja otomatis KBR mendekripsinya dan memeriksa tanda tangan elektronik, setelah itu mencatatnya dalam bentuk sekumpulan file dalam format UFEBS di server file. Sebelum mengimpor dokumen pembayaran ke ABS, dikonversi menggunakan skrip konverter dari format UFEBS ke format ABS.

Kami berasumsi bahwa dalam skema ini ABS beroperasi pada satu server fisik, stasiun kerja KBR beroperasi pada komputer khusus, dan skrip konverter berjalan pada server file.

Keamanan informasi pembayaran nontunai bank. Bagian 8 - Model Ancaman yang Khas

Korespondensi objek diagram yang dipertimbangkan dengan elemen model modul integrasi:
“Server pertukaran dari sisi ABS” – Server ABS.
“Server pertukaran dari sisi AWS KBR” – stasiun kerja komputer KBR.
"Penengah" – server file pihak ketiga.
"Perangkat lunak pengolah data" – skrip konverter.

Skema 2. Integrasi ABS dan AWS KBR saat menempatkan folder jaringan bersama dengan pembayaran di AWS KBR

Semuanya mirip dengan Skema 1, tetapi server file terpisah tidak digunakan; sebagai gantinya, folder jaringan (...SHARE) dengan dokumen pembayaran elektronik ditempatkan di komputer dengan stasiun kerja CBD. Skrip konverter juga berfungsi di stasiun kerja CBD.

Keamanan informasi pembayaran nontunai bank. Bagian 8 - Model Ancaman yang Khas

Korespondensi objek diagram yang dipertimbangkan dengan elemen model modul integrasi:
Mirip dengan Skema 1, tapi "Penengah" tidak digunakan.

Skema 3. Integrasi ABS dan tempat kerja otomatis KBR-N melalui IBM WebSphera MQ dan penandatanganan dokumen elektronik “di sisi ABS”

ABS beroperasi pada platform yang tidak didukung oleh CIPF SCAD Signature. Penandatanganan dokumen elektronik keluar dilakukan pada server khusus tanda tangan elektronik (ES Server). Server yang sama memeriksa tanda tangan elektronik pada dokumen yang masuk dari Bank Rusia.

ABS mengunggah file dengan dokumen pembayaran dalam formatnya sendiri ke Server ES.
Server ES, menggunakan skrip konverter, mengubah file menjadi pesan elektronik dalam format UFEBS, setelah itu pesan elektronik ditandatangani dan dikirim ke IBM WebSphere MQ.

Stasiun kerja KBR-N mengakses IBM WebSphere MQ dan menerima pesan pembayaran yang ditandatangani dari sana, setelah itu karyawan yang berwenang - pengguna stasiun kerja KBR - mengenkripsinya dan mengirimkannya ke sistem pembayaran Bank Rusia.

Ketika pembayaran diterima dari Bank Rusia, tempat kerja otomatis KBR-N mendekripsinya dan memverifikasi tanda tangan elektronik. Pembayaran yang berhasil diproses dalam bentuk pesan elektronik yang didekripsi dan ditandatangani dalam format UFEBS ditransfer ke IBM WebSphere MQ, yang kemudian diterima oleh Server Tanda Tangan Elektronik.

Server tanda tangan elektronik memverifikasi tanda tangan elektronik dari pembayaran yang diterima dan menyimpannya dalam file dalam format ABS. Setelah itu, karyawan yang berwenang - pengguna ABS - mengunggah file yang dihasilkan ke ABS dengan cara yang ditentukan.

Keamanan informasi pembayaran nontunai bank. Bagian 8 - Model Ancaman yang Khas

Korespondensi objek diagram yang dipertimbangkan dengan elemen model modul integrasi:
“Server pertukaran dari sisi ABS” – Server ABS.
“Server pertukaran dari sisi AWS KBR” — stasiun kerja komputer KBR.
"Penengah" – Server ES dan IBM WebSphere MQ.
"Perangkat lunak pengolah data" – pengonversi skrip, Tanda Tangan CIPF SCAD di Server ES.

Skema 4. Integrasi Server RBS dan sistem perbankan inti melalui API yang disediakan oleh server pertukaran khusus

Kami berasumsi bahwa bank menggunakan beberapa sistem perbankan jarak jauh (RBS):

  • "Internet Client-Bank" untuk perorangan (IKB FL);
  • "Internet Client-Bank" untuk badan hukum (IKB LE).

Untuk menjamin keamanan informasi, semua interaksi antara ABS dan sistem perbankan jarak jauh dilakukan melalui server pertukaran khusus yang beroperasi dalam kerangka sistem informasi ABS.

Selanjutnya kita akan membahas proses interaksi antara sistem RBS IKB LE dan ABS.
Server RBS, setelah menerima perintah pembayaran bersertifikat dari klien, harus membuat dokumen terkait di ABS berdasarkan itu. Untuk melakukan ini, dengan menggunakan API, ia mengirimkan informasi ke server pertukaran, yang kemudian memasukkan data ke dalam ABS.

Ketika saldo akun klien berubah, ABS menghasilkan pemberitahuan elektronik, yang dikirimkan ke server perbankan jarak jauh menggunakan server pertukaran.

Keamanan informasi pembayaran nontunai bank. Bagian 8 - Model Ancaman yang Khas

Korespondensi objek diagram yang dipertimbangkan dengan elemen model modul integrasi:
“Server pertukaran dari sisi RBS” – Server RBS IKB YUL.
“Server pertukaran dari sisi ABS” – server pertukaran.
"Penengah" - hilang.
"Perangkat lunak pengolah data" – Komponen Server RBS bertanggung jawab untuk menggunakan API server pertukaran, komponen server pertukaran bertanggung jawab untuk menggunakan API perbankan inti.

Ancaman keamanan tingkat atas

Penguraian
U1. Suntikan informasi palsu oleh penyerang melalui modul integrasi.

U1. Suntikan informasi palsu oleh penyerang melalui modul integrasi

Penguraian
U1.1. Modifikasi data sah yang tidak sah saat dikirimkan melalui koneksi jaringan:
Tautan U1.1.1: “Model ancaman yang khas. Koneksi jaringan. U2. Modifikasi tidak sah atas data yang dikirimkan".

U1.2. Transmisi data palsu melalui saluran komunikasi atas nama peserta pertukaran yang sah:
Tautan U1.1.2: “Model ancaman yang khas. Koneksi jaringan. U3. Pelanggaran hak cipta atas data yang dikirimkan".

U1.3. Modifikasi tidak sah atas data sah selama pemrosesannya di Server Exchange atau Perantara:
U1.3.1. Tautan: “Model ancaman yang khas. Sebuah sistem informasi yang dibangun pada arsitektur client-server. U2. Modifikasi yang tidak sah atas informasi yang dilindungi selama pemrosesannya oleh bagian server dari sistem informasi".

U1.4. Pembuatan data palsu di Server Exchange atau Perantara atas nama peserta pertukaran yang sah:
U1.4.1. Tautan: “Model ancaman yang khas. Sebuah sistem informasi yang dibangun pada arsitektur client-server. U1. Melakukan tindakan tidak sah oleh penyerang atas nama pengguna yang sah.”

U1.5. Modifikasi data yang tidak sah ketika diproses menggunakan perangkat lunak pengolah data:
U1.5.1. <…> karena penyerang membuat perubahan tidak sah pada pengaturan (konfigurasi) perangkat lunak pengolah data.
U1.5.2. <…> karena penyerang membuat perubahan tidak sah pada file yang dapat dieksekusi dari perangkat lunak pemrosesan data.
U1.5.3. <…> karena kontrol interaktif perangkat lunak pemrosesan data oleh penyerang.

MODEL ANCAMAN KHUSUS. SISTEM PERLINDUNGAN INFORMASI KRIPTOGRAFI

Objek perlindungan yang model ancaman (cakupannya) diterapkan

Objek perlindungannya adalah sistem perlindungan informasi kriptografi yang digunakan untuk menjamin keamanan sistem informasi.

Arsitektur
Dasar dari setiap sistem informasi adalah perangkat lunak aplikasi yang mengimplementasikan fungsionalitas targetnya.

Perlindungan kriptografi biasanya diimplementasikan dengan memanggil primitif kriptografi dari logika bisnis perangkat lunak aplikasi, yang terletak di perpustakaan khusus - inti kripto.

Kriptografi primitif mencakup fungsi kriptografi tingkat rendah, seperti:

  • mengenkripsi/mendekripsi blok data;
  • membuat/memverifikasi tanda tangan elektronik dari suatu blok data;
  • menghitung fungsi hash dari blok data;
  • menghasilkan/memuat/mengunggah informasi penting;
  • dan lain-lain

Logika bisnis perangkat lunak aplikasi mengimplementasikan fungsionalitas tingkat tinggi menggunakan primitif kriptografi:

  • mengenkripsi file menggunakan kunci penerima yang dipilih;
  • membuat koneksi jaringan yang aman;
  • memberitahukan hasil pemeriksaan tanda tangan elektronik;
  • dan seterusnya.

Interaksi logika bisnis dan inti kripto dapat dilakukan:

  • secara langsung, dengan logika bisnis memanggil primitif kriptografi dari perpustakaan dinamis kernel kripto (.DLL untuk Windows, .SO untuk Linux);
  • secara langsung, melalui antarmuka kriptografi - pembungkus, misalnya, MS Crypto API, Arsitektur Kriptografi Java, PKCS#11, dll. Dalam hal ini, logika bisnis mengakses antarmuka kripto, dan menerjemahkan panggilan ke inti kripto yang sesuai, yang di kasus ini disebut penyedia kripto. Penggunaan antarmuka kriptografi memungkinkan perangkat lunak aplikasi untuk mengabstraksi algoritma kriptografi tertentu dan menjadi lebih fleksibel.

Ada dua skema khas untuk mengatur inti kripto:

Skema 1 – Inti kripto monolitik
Keamanan informasi pembayaran nontunai bank. Bagian 8 - Model Ancaman yang Khas

Skema 2 – Pisahkan inti kripto
Keamanan informasi pembayaran nontunai bank. Bagian 8 - Model Ancaman yang Khas

Elemen diagram di atas dapat berupa modul perangkat lunak individual yang berjalan pada satu komputer, atau layanan jaringan yang berinteraksi dalam jaringan komputer.

Saat menggunakan sistem yang dibangun sesuai Skema 1, perangkat lunak aplikasi dan inti kripto beroperasi dalam satu lingkungan operasi untuk alat kripto (SFC), misalnya, pada komputer yang sama, menjalankan sistem operasi yang sama. Pengguna sistem, sebagai suatu peraturan, dapat menjalankan program lain, termasuk program yang berisi kode berbahaya, dalam lingkungan operasi yang sama. Dalam kondisi seperti itu, terdapat risiko kebocoran kunci kriptografi pribadi yang serius.

Untuk meminimalkan risiko, digunakan skema 2, di mana inti kripto dibagi menjadi dua bagian:

  1. Bagian pertama, bersama dengan perangkat lunak aplikasi, beroperasi di lingkungan yang tidak tepercaya di mana terdapat risiko infeksi kode berbahaya. Kami akan menyebut bagian ini sebagai “bagian perangkat lunak”.
  2. Bagian kedua berfungsi di lingkungan tepercaya pada perangkat khusus, yang berisi penyimpanan kunci pribadi. Mulai sekarang kami akan menyebut bagian ini “perangkat keras”.

Pembagian inti kripto menjadi bagian perangkat lunak dan perangkat keras sangat sewenang-wenang. Ada sistem di pasar yang dibangun sesuai dengan skema dengan inti kripto yang terbagi, tetapi bagian “perangkat keras” disajikan dalam bentuk gambar mesin virtual - HSM virtual (contoh).

Interaksi kedua bagian inti kripto terjadi sedemikian rupa sehingga kunci kriptografi pribadi tidak pernah ditransfer ke bagian perangkat lunak dan, karenanya, tidak dapat dicuri menggunakan kode berbahaya.

Antarmuka interaksi (API) dan kumpulan primitif kriptografi yang disediakan ke perangkat lunak aplikasi oleh inti kripto adalah sama dalam kedua kasus. Perbedaannya terletak pada cara penerapannya.

Jadi, ketika menggunakan skema dengan inti kripto yang terbagi, interaksi perangkat lunak dan perangkat keras dilakukan sesuai dengan prinsip berikut:

  1. Kriptografi primitif yang tidak memerlukan penggunaan kunci pribadi (misalnya, menghitung fungsi hash, memverifikasi tanda tangan elektronik, dll.) dilakukan oleh perangkat lunak.
  2. Kriptografi primitif yang menggunakan kunci pribadi (membuat tanda tangan elektronik, mendekripsi data, dll.) dilakukan oleh perangkat keras.

Mari kita ilustrasikan pekerjaan inti kripto yang terbagi menggunakan contoh pembuatan tanda tangan elektronik:

  1. Bagian perangkat lunak menghitung fungsi hash dari data yang ditandatangani dan mengirimkan nilai ini ke perangkat keras melalui saluran pertukaran antar inti kripto.
  2. Bagian perangkat keras, menggunakan kunci pribadi dan hash, menghasilkan nilai tanda tangan elektronik dan mengirimkannya ke bagian perangkat lunak melalui saluran pertukaran.
  3. Bagian perangkat lunak mengembalikan nilai yang diterima ke perangkat lunak aplikasi.

Fitur pengecekan kebenaran tanda tangan elektronik

Ketika pihak penerima menerima data yang ditandatangani secara elektronik, maka harus melakukan beberapa langkah verifikasi. Hasil positif dari pemeriksaan tanda tangan elektronik hanya dapat dicapai jika semua tahapan verifikasi berhasil diselesaikan.

Tahap 1. Pengendalian integritas data dan kepengarangan data.

Isi panggung. Tanda tangan elektronik dari data diverifikasi menggunakan algoritma kriptografi yang sesuai. Keberhasilan menyelesaikan tahap ini menunjukkan bahwa data belum diubah sejak ditandatangani, dan juga bahwa tanda tangan dibuat dengan kunci pribadi yang sesuai dengan kunci publik untuk memverifikasi tanda tangan elektronik.
Lokasi panggung: inti kripto.

Tahap 2. Pengendalian kepercayaan terhadap kunci publik penandatangan dan pengendalian masa berlaku kunci privat tanda tangan elektronik.
Isi panggung. Tahap ini terdiri dari dua subtahap perantara. Yang pertama adalah menentukan apakah kunci publik untuk memverifikasi tanda tangan elektronik dipercaya pada saat penandatanganan data. Yang kedua menentukan apakah kunci privat dari tanda tangan elektronik itu valid pada saat penandatanganan data. Secara umum, masa berlaku kunci ini mungkin tidak bersamaan (misalnya, untuk sertifikat kunci verifikasi tanda tangan elektronik yang memenuhi syarat). Metode untuk membangun kepercayaan terhadap kunci publik penandatangan ditentukan oleh aturan pengelolaan dokumen elektronik yang dianut oleh pihak-pihak yang berinteraksi.
Lokasi panggung: perangkat lunak aplikasi / inti kripto.

Tahap 3. Pengendalian kewenangan penandatangan.
Isi panggung. Sesuai dengan aturan pengelolaan dokumen elektronik yang ditetapkan, diperiksa apakah penandatangan berhak mengesahkan data yang dilindungi. Sebagai contoh, mari kita berikan situasi pelanggaran wewenang. Misalkan ada sebuah organisasi di mana semua karyawannya memiliki tanda tangan elektronik. Sistem pengelolaan dokumen elektronik internal menerima perintah dari manajer, tetapi ditandatangani dengan tanda tangan elektronik dari manajer gudang. Oleh karena itu, dokumen semacam itu tidak dapat dianggap sah.
Lokasi panggung: aplikasi perangkat lunak.

Asumsi yang dibuat ketika menggambarkan objek perlindungan

  1. Saluran transmisi informasi, dengan pengecualian saluran pertukaran kunci, juga melewati perangkat lunak aplikasi, API, dan inti kripto.
  2. Informasi tentang kepercayaan pada kunci publik dan (atau) sertifikat, serta informasi tentang kekuasaan pemilik kunci publik, ditempatkan di penyimpanan kunci publik.
  3. Perangkat lunak aplikasi bekerja dengan penyimpanan kunci publik melalui kernel kripto.

Contoh sistem informasi yang diproteksi menggunakan CIPF

Untuk mengilustrasikan diagram yang disajikan sebelumnya, mari kita pertimbangkan sistem informasi hipotetis dan soroti semua elemen struktural di dalamnya.

Deskripsi sistem informasi

Keamanan informasi pembayaran nontunai bank. Bagian 8 - Model Ancaman yang Khas

Kedua organisasi memutuskan untuk memperkenalkan manajemen dokumen elektronik (EDF) yang signifikan secara hukum di antara mereka. Untuk melakukan ini, mereka menandatangani perjanjian yang menetapkan bahwa dokumen akan dikirimkan melalui email, dan pada saat yang sama dokumen tersebut harus dienkripsi dan ditandatangani dengan tanda tangan elektronik yang memenuhi syarat. Program Office dari paket Microsoft Office 2016 harus digunakan sebagai alat untuk membuat dan memproses dokumen, dan CIPF CryptoPRO serta perangkat lunak enkripsi CryptoARM harus digunakan sebagai alat perlindungan kriptografi.

Deskripsi infrastruktur organisasi 1

Organisasi 1 memutuskan akan menginstal perangkat lunak CIPF CryptoPRO dan CryptoARM di stasiun kerja pengguna - komputer fisik. Kunci enkripsi dan tanda tangan elektronik akan disimpan di media kunci ruToken, beroperasi dalam mode kunci yang dapat diambil. Pengguna akan menyiapkan dokumen elektronik secara lokal di komputernya, kemudian mengenkripsi, menandatangani, dan mengirimkannya menggunakan klien email yang diinstal secara lokal.

Deskripsi infrastruktur organisasi 2

Organisasi 2 memutuskan untuk memindahkan fungsi enkripsi dan tanda tangan elektronik ke mesin virtual khusus. Dalam hal ini, semua operasi kriptografi akan dilakukan secara otomatis.

Untuk melakukan ini, dua folder jaringan diatur pada mesin virtual khusus: "...In", "...Out". File yang diterima dari rekanan dalam bentuk terbuka akan secara otomatis ditempatkan di folder jaringan “…Dalam”. File-file ini akan didekripsi dan tanda tangan elektronik akan diverifikasi.

Pengguna akan menempatkan file di folder “…Out” yang perlu dienkripsi, ditandatangani, dan dikirim ke pihak lawan. Pengguna akan menyiapkan sendiri file di stasiun kerjanya.
Untuk menjalankan fungsi enkripsi dan tanda tangan elektronik, CIPF CryptoPRO, perangkat lunak CryptoARM, dan klien email diinstal pada mesin virtual. Manajemen otomatis semua elemen mesin virtual akan dilakukan menggunakan skrip yang dikembangkan oleh administrator sistem. Pekerjaan skrip dicatat dalam file log.

Kunci kriptografi untuk tanda tangan elektronik akan ditempatkan pada token dengan kunci JaCarta Gost yang tidak dapat diambil, yang akan dihubungkan oleh pengguna ke komputer lokalnya.

Token akan diteruskan ke mesin virtual menggunakan perangkat lunak USB-over-IP khusus yang diinstal pada stasiun kerja pengguna dan pada mesin virtual.

Jam sistem pada stasiun kerja pengguna di organisasi 1 akan disesuaikan secara manual. Jam sistem mesin virtual khusus di Organisasi 2 akan disinkronkan dengan jam sistem hypervisor, yang selanjutnya akan disinkronkan melalui Internet dengan server waktu publik.

Identifikasi elemen struktural CIPF
Berdasarkan uraian infrastruktur TI di atas, kami akan menyoroti elemen struktural CIPF dan menuliskannya dalam sebuah tabel.

Tabel - Korespondensi elemen model CIPF dengan elemen sistem informasi

Nama Barang
Organisasi 1
Organisasi 2

Aplikasi perangkat lunak
perangkat lunak CryptoARM
perangkat lunak CryptoARM

Perangkat lunak bagian dari inti kripto
CIPF CryptoPRO CSP
CIPF CryptoPRO CSP

Perangkat keras inti kripto
Tidak
JaCarta gost

API
MS KriptoAPI
MS KriptoAPI

Penyimpanan Kunci Publik
Stasiun kerja pengguna:
- HDD;
- penyimpanan sertifikat Windows standar.
hipervisor:
- HDD.

Mesin virtual:
- HDD;
- penyimpanan sertifikat Windows standar.

Penyimpanan kunci pribadi
pembawa kunci ruToken beroperasi dalam mode kunci yang dapat diambil
Pembawa kunci JaCarta Gost beroperasi dalam mode kunci yang tidak dapat dilepas

Saluran pertukaran kunci publik
Stasiun kerja pengguna:
- RAM.

hipervisor:
- RAM.

Mesin virtual:
- RAM.

Saluran pertukaran kunci pribadi
Stasiun kerja pengguna:
— bus USB;
- RAM.
Tidak

Pertukaran saluran antar inti kripto
hilang (tidak ada perangkat keras inti kripto)
Stasiun kerja pengguna:
— bus USB;
- RAM;
— Modul perangkat lunak USB-over-IP;
- antarmuka jaringan.

Jaringan korporat organisasi 2.

hipervisor:
- RAM;
- antarmuka jaringan.

Mesin virtual:
— antarmuka jaringan;
- RAM;
— Modul perangkat lunak USB-over-IP.

Buka Saluran Data
Stasiun kerja pengguna:
— sarana masukan-keluaran;
- RAM;
- HDD.
Stasiun kerja pengguna:
— sarana masukan-keluaran;
- RAM;
- HDD;
- antarmuka jaringan.

Jaringan korporat organisasi 2.

hipervisor:
— antarmuka jaringan;
- RAM;
- HDD.

Mesin virtual:
— antarmuka jaringan;
- RAM;
- HDD.

Saluran pertukaran data yang aman
Internet.

Jaringan korporat organisasi 1.

Stasiun kerja pengguna:
- HDD;
- RAM;
- antarmuka jaringan.

Internet.

Jaringan korporat organisasi 2.

hipervisor:
— antarmuka jaringan;
- RAM;
- HDD.

Mesin virtual:
— antarmuka jaringan;
- RAM;
- HDD.

Saluran waktu
Stasiun kerja pengguna:
— sarana masukan-keluaran;
- RAM;
- pengatur waktu sistem.

Internet.
Jaringan korporat organisasi 2,

hipervisor:
— antarmuka jaringan;
- RAM;
- pengatur waktu sistem.

Mesin virtual:
- RAM;
- pengatur waktu sistem.

Kontrol saluran transmisi perintah
Stasiun kerja pengguna:
— sarana masukan-keluaran;
- RAM.

(Antarmuka pengguna grafis perangkat lunak CryptoARM)

Mesin virtual:
- RAM;
- HDD.

(Skrip otomatisasi)

Saluran untuk menerima hasil pekerjaan
Stasiun kerja pengguna:
— sarana masukan-keluaran;
- RAM.

(Antarmuka pengguna grafis perangkat lunak CryptoARM)

Mesin virtual:
- RAM;
- HDD.

(File log skrip otomatisasi)

Ancaman keamanan tingkat atas

Penjelasan

Asumsi yang dibuat ketika menguraikan ancaman:

  1. Algoritma kriptografi yang kuat digunakan.
  2. Algoritme kriptografi digunakan dengan aman dalam mode operasi yang benar (mis. ECB tidak digunakan untuk mengenkripsi data dalam jumlah besar, beban yang diizinkan pada kunci diperhitungkan, dll.).
  3. Penyerang mengetahui semua algoritma, protokol, dan kunci publik yang digunakan.
  4. Penyerang dapat membaca semua data terenkripsi.
  5. Penyerang dapat mereproduksi elemen perangkat lunak apa pun dalam sistem.

Penguraian

U1. Kompromi kunci kriptografi pribadi.
U2. Mengenkripsi data palsu atas nama pengirim yang sah.
U3. Dekripsi data terenkripsi oleh orang yang bukan penerima data yang sah (penyerang).
U4. Pembuatan tanda tangan elektronik dari penandatangan yang sah berdasarkan data palsu.
U5. Memperoleh hasil positif dari pemeriksaan tanda tangan elektronik terhadap data palsu.
U6. Kesalahan penerimaan dokumen elektronik untuk dieksekusi karena adanya permasalahan dalam penyelenggaraan aliran dokumen elektronik.
U7. Akses tidak sah ke data yang dilindungi selama pemrosesannya oleh CIPF.

U1. Kompromi kunci kriptografi pribadi

U1.1. Mengambil kunci pribadi dari penyimpanan kunci pribadi.

U1.2. Memperoleh kunci pribadi dari objek di lingkungan operasi alat kripto, yang mungkin menjadi tempat tinggalnya untuk sementara.
Penjelasan U1.2.

Objek yang dapat menyimpan kunci privat untuk sementara meliputi:

  1. RAM,
  2. berkas sementara,
  3. bertukar file,
  4. file hibernasi,
  5. file snapshot dari status "panas" mesin virtual, termasuk file isi RAM mesin virtual yang dijeda.

U1.2.1. Mengekstrak kunci pribadi dari RAM yang berfungsi dengan membekukan modul RAM, menghapusnya dan kemudian membaca data (serangan pembekuan).
Penjelasan U1.2.1.
Contoh serangan.

U1.3. Mendapatkan kunci pribadi dari saluran pertukaran kunci pribadi.
Penjelasan U1.3.
Contoh penerapan ancaman ini akan diberikan di bawah.

U1.4. Modifikasi inti kripto yang tidak sah, akibatnya kunci pribadi diketahui oleh penyerang.

U1.5. Kompromi kunci pribadi akibat penggunaan saluran kebocoran informasi teknis (TCIL).
Penjelasan U1.5.
Contoh serangan.

U1.6. Kompromi kunci pribadi sebagai akibat dari penggunaan sarana teknis khusus (STS) yang dirancang untuk mengambil informasi secara diam-diam (“bug”).

U1.7. Kompromi kunci pribadi selama penyimpanannya di luar CIPF.
Penjelasan U1.7.
Misalnya, pengguna menyimpan media kuncinya di laci desktop, sehingga media tersebut dapat dengan mudah diambil oleh penyerang.

U2. Mengenkripsi data palsu atas nama pengirim yang sah

Penjelasan
Ancaman ini dianggap hanya untuk skema enkripsi data dengan otentikasi pengirim. Contoh skema tersebut ditunjukkan dalam rekomendasi standardisasi R 1323565.1.004-2017 “Teknologi informasi. Perlindungan informasi kriptografi. Skema untuk menghasilkan kunci publik dengan otentikasi berdasarkan kunci publik". Untuk skema kriptografi lainnya, ancaman ini tidak ada, karena enkripsi dilakukan pada kunci publik penerima, dan umumnya diketahui oleh penyerang.

Penguraian
U2.1. Mengkompromikan kunci pribadi pengirim:
U2.1.1. Tautan: “Model ancaman yang khas. Sistem perlindungan informasi kriptografi.У1. Kompromi kunci kriptografi pribadi".

U2.2. Pergantian data masukan pada saluran pertukaran data terbuka.
Catatan U2.2.
Contoh penerapan ancaman ini diberikan di bawah ini. di sini и di sini.

U3. Dekripsi data terenkripsi oleh orang yang bukan penerima data yang sah (penyerang)

Penguraian
U3.1. Kompromi kunci pribadi penerima data terenkripsi.
Tautan U3.1.1: “Model ancaman yang khas. Sistem perlindungan informasi kriptografi. U1. Kompromi kunci kriptografi pribadi".

U3.2. Pergantian data terenkripsi dalam saluran pertukaran data yang aman.

U4. Membuat tanda tangan elektronik dari penandatangan yang sah dengan data palsu

Penguraian
U4.1. Kompromi kunci pribadi dari tanda tangan elektronik dari penandatangan yang sah.
Tautan U4.1.1: “Model ancaman yang khas. Sistem perlindungan informasi kriptografi. U1. Kompromi kunci kriptografi pribadi".

U4.2. Pergantian data yang ditandatangani dalam saluran pertukaran data terbuka.
Catatan U4.2.
Contoh penerapan ancaman ini diberikan di bawah ini. di sini и di sini.

U5. Memperoleh hasil positif dari pemeriksaan tanda tangan elektronik terhadap data palsu

Penguraian
U5.1. Penyerang mencegat pesan di saluran transmisi hasil kerja tentang hasil negatif dari pemeriksaan tanda tangan elektronik dan menggantinya dengan pesan dengan hasil positif.

U5.2. Penyerang menyerang kepercayaan dalam menandatangani sertifikat (SCRIPT - semua elemen wajib diisi):
U5.2.1. Penyerang menghasilkan kunci publik dan pribadi untuk tanda tangan elektronik. Jika sistem menggunakan sertifikat kunci tanda tangan elektronik, maka sistem akan menghasilkan sertifikat tanda tangan elektronik yang semirip mungkin dengan sertifikat pengirim data yang dituju yang pesannya ingin mereka palsukan.
U5.2.2. Penyerang membuat perubahan tanpa izin pada penyimpanan kunci publik, sehingga kunci publik tersebut menghasilkan tingkat kepercayaan dan otoritas yang diperlukan.
U5.2.3. Penyerang menandatangani data palsu dengan kunci tanda tangan elektronik yang dibuat sebelumnya dan memasukkannya ke saluran pertukaran data yang aman.

U5.3. Penyerang melakukan serangan menggunakan kunci tanda tangan elektronik yang sudah kadaluwarsa dari penandatangan yang sah (SCRIPT - semua elemen wajib diisi):
U5.3.1. Penyerang mengkompromikan kunci pribadi yang sudah kadaluarsa (saat ini tidak valid) dari tanda tangan elektronik pengirim yang sah.
U5.3.2. Penyerang mengganti waktu di saluran transmisi waktu dengan waktu di mana kunci yang disusupi masih valid.
U5.3.3. Penyerang menandatangani data palsu dengan kunci tanda tangan elektronik yang sebelumnya telah disusupi dan menyuntikkannya ke saluran pertukaran data yang aman.

U5.4. Penyerang melakukan serangan menggunakan kunci tanda tangan elektronik yang disusupi dari penandatangan yang sah (SCRIPT - semua elemen wajib diisi):
U5.4.1. Penyerang membuat salinan penyimpanan kunci publik.
U5.4.2. Para penyerang mengkompromikan kunci pribadi salah satu pengirim yang sah. Dia memperhatikan adanya kompromi, mencabut kunci, dan informasi tentang pencabutan kunci ditempatkan di penyimpanan kunci publik.
U5.4.3. Penyerang mengganti penyimpanan kunci publik dengan yang disalin sebelumnya.
U5.4.4. Penyerang menandatangani data palsu dengan kunci tanda tangan elektronik yang sebelumnya telah disusupi dan menyuntikkannya ke saluran pertukaran data yang aman.

U5.5. <…> karena adanya kesalahan dalam pelaksanaan verifikasi tanda tangan elektronik tahap 2 dan 3:
Penjelasan U5.5.
Contoh penerapan ancaman ini diberikan di bawah.

U5.5.1. Pengecekan kepercayaan terhadap sertifikat kunci tanda tangan elektronik hanya dengan adanya kepercayaan terhadap sertifikat yang ditandatangani, tanpa pemeriksaan CRL atau OCSP.
Penjelasan U5.5.1.
Contoh implementasi ancaman.

U5.5.2. Saat membangun rantai kepercayaan untuk suatu sertifikat, otoritas penerbit sertifikat tidak dianalisis
Penjelasan U5.5.2.
Contoh serangan terhadap sertifikat SSL/TLS.
Para penyerang membeli sertifikat sah untuk email mereka. Mereka kemudian membuat sertifikat situs palsu dan menandatanganinya dengan sertifikat mereka. Jika kredensial tidak diperiksa, maka ketika memeriksa rantai kepercayaan, itu akan menjadi benar, dan karenanya, sertifikat palsu juga akan benar.

U5.5.3. Saat membangun rantai kepercayaan sertifikat, sertifikat perantara tidak diperiksa untuk dicabut.

U5.5.4. CRL lebih jarang diperbarui dibandingkan yang dikeluarkan oleh otoritas sertifikasi.

U5.5.5. Keputusan untuk mempercayai tanda tangan elektronik dibuat sebelum tanggapan OCSP tentang status sertifikat diterima, dikirim atas permintaan yang dibuat lebih lambat dari waktu pembuatan tanda tangan atau lebih awal dari CRL berikutnya setelah tanda tangan dibuat.
Penjelasan U5.5.5.
Dalam peraturan sebagian besar CA, waktu pencabutan sertifikat dianggap sebagai waktu penerbitan CRL terdekat yang berisi informasi tentang pencabutan sertifikat.

U5.5.6. Saat menerima data yang ditandatangani, sertifikat milik pengirim tidak dicentang.
Penjelasan U5.5.6.
Contoh serangan. Sehubungan dengan sertifikat SSL: korespondensi alamat server yang dipanggil dengan nilai bidang CN dalam sertifikat mungkin tidak diperiksa.
Contoh serangan. Penyerang membobol kunci tanda tangan elektronik salah satu peserta sistem pembayaran. Setelah itu, mereka meretas jaringan peserta lain dan, atas namanya, mengirimkan dokumen pembayaran yang ditandatangani dengan kunci yang disusupi ke server penyelesaian sistem pembayaran. Jika server hanya menganalisis kepercayaan dan tidak memeriksa kepatuhannya, maka dokumen palsu akan dianggap sah.

U6. Kesalahan penerimaan dokumen elektronik untuk dieksekusi karena adanya permasalahan dalam penyelenggaraan aliran dokumen elektronik.

Penguraian
U6.1. Pihak penerima tidak mendeteksi adanya duplikasi dokumen yang diterima.
Penjelasan U6.1.
Contoh serangan. Penyerang dapat mencegat dokumen yang dikirimkan ke penerima, meskipun dokumen tersebut dilindungi kriptografi, dan kemudian berulang kali mengirimkannya melalui saluran transmisi data yang aman. Jika penerima tidak mengidentifikasi duplikatnya, maka semua dokumen yang diterima akan dianggap dan diproses sebagai dokumen yang berbeda.

U7. Akses tidak sah ke data yang dilindungi selama pemrosesannya oleh CIPF

Penguraian

U7.1. <…> karena kebocoran informasi melalui saluran samping (serangan saluran samping).
Penjelasan U7.1.
Contoh serangan.

U7.2. <…> karena netralisasi perlindungan terhadap akses tidak sah ke informasi yang diproses di CIPF:
U7.2.1. Pengoperasian CIPF yang melanggar persyaratan yang dijelaskan dalam dokumentasi CIPF.

U7.2.2. <…>, dilakukan karena adanya kerentanan pada:
U7.2.2.1. <…> sarana perlindungan terhadap akses tidak sah.
U7.2.2.2. <…> CIPF itu sendiri.
U7.2.2.3. <…> lingkungan pengoperasian alat kripto.

Contoh serangan

Skenario yang dibahas di bawah ini jelas mengandung kesalahan keamanan informasi dan hanya berfungsi untuk menggambarkan kemungkinan serangan.

Skenario 1. Contoh penerapan ancaman U2.2 dan U4.2.

Deskripsi objek
Keamanan informasi pembayaran nontunai bank. Bagian 8 - Model Ancaman yang Khas

Perangkat lunak AWS KBR dan CIPF SCAD Signature diinstal pada komputer fisik yang tidak terhubung ke jaringan komputer. FKN vdToken digunakan sebagai pembawa kunci dalam mode bekerja dengan kunci yang tidak dapat dilepas.

Peraturan penyelesaian mengasumsikan bahwa spesialis penyelesaian dari komputer kerjanya mengunduh pesan elektronik dalam teks yang jelas (skema stasiun kerja KBR lama) dari server file aman khusus, kemudian menuliskannya ke flash drive USB yang dapat ditransfer dan mentransfernya ke stasiun kerja KBR, di mana mereka dienkripsi dan ditandatangani. Setelah itu, spesialis mentransfer pesan elektronik yang aman ke media yang diasingkan, dan kemudian, melalui komputer kerjanya, menuliskannya ke server file, dari mana pesan tersebut dikirim ke UTA dan kemudian ke sistem pembayaran Bank Rusia.

Dalam hal ini, saluran untuk pertukaran data yang terbuka dan dilindungi akan mencakup: server file, komputer kerja spesialis, dan media yang diasingkan.

Menyerang
Penyerang yang tidak sah memasang sistem kendali jarak jauh pada komputer kerja spesialis dan, pada saat menulis perintah pembayaran (pesan elektronik) ke media yang diasingkan, mengganti konten salah satunya dalam teks yang jelas. Spesialis mentransfer perintah pembayaran ke stasiun kerja CBD, menandatangani dan mengenkripsinya tanpa memperhatikan substitusinya (misalnya, karena banyaknya perintah pembayaran dalam penerbangan, kelelahan, dll.). Setelah itu, perintah pembayaran palsu, setelah melewati rantai teknologi, memasuki sistem pembayaran Bank Rusia.

Skenario 2. Contoh penerapan ancaman U2.2 dan U4.2.

Deskripsi objek
Keamanan informasi pembayaran nontunai bank. Bagian 8 - Model Ancaman yang Khas

Komputer dengan stasiun kerja KBR yang terinstal, SCAD Signature, dan pembawa kunci FKN vdToken yang terhubung beroperasi di ruangan khusus tanpa akses dari personel.
Spesialis perhitungan terhubung ke stasiun kerja CBD dalam mode akses jarak jauh melalui protokol RDP.

Menyerang
Penyerang mencegat detail yang digunakan spesialis perhitungan untuk menghubungkan dan bekerja dengan stasiun kerja CBD (misalnya, melalui kode berbahaya di komputernya). Kemudian mereka terhubung atas namanya dan mengirimkan perintah pembayaran palsu ke sistem pembayaran Bank Rusia.

Skenario 3. Contoh implementasi ancaman U1.3.

Deskripsi objek
Keamanan informasi pembayaran nontunai bank. Bagian 8 - Model Ancaman yang Khas

Mari kita pertimbangkan salah satu opsi hipotetis untuk mengimplementasikan modul integrasi ABS-KBR untuk skema baru (AWS KBR-N), di mana tanda tangan elektronik dari dokumen keluar terjadi di sisi ABS. Dalam hal ini, kami akan berasumsi bahwa ABS beroperasi berdasarkan sistem operasi yang tidak didukung oleh CIPF SKAD Signature, dan karenanya, fungsi kriptografi ditransfer ke mesin virtual terpisah - integrasi "ABS-KBR" modul.
Token USB biasa yang beroperasi dalam mode kunci yang dapat diambil digunakan sebagai pembawa kunci. Saat menghubungkan media kunci ke hypervisor, ternyata tidak ada port USB gratis di sistem, sehingga diputuskan untuk menghubungkan token USB melalui hub USB jaringan, dan menginstal klien USB-over-IP di virtual mesin, yang akan berkomunikasi dengan hub.

Menyerang
Penyerang mencegat kunci pribadi tanda tangan elektronik dari saluran komunikasi antara hub USB dan hypervisor (data dikirimkan dalam bentuk teks yang jelas). Dengan memiliki kunci pribadi, penyerang membuat perintah pembayaran palsu, menandatanganinya dengan tanda tangan elektronik dan mengirimkannya ke tempat kerja otomatis KBR-N untuk dieksekusi.

Skenario 4. Contoh implementasi ancaman U5.5.

Deskripsi objek
Mari kita pertimbangkan rangkaian yang sama seperti pada skenario sebelumnya. Kami berasumsi bahwa pesan elektronik yang berasal dari stasiun kerja KBR-N berakhir di folder …SHAREIn, dan pesan yang dikirim ke stasiun kerja KBR-N dan selanjutnya ke sistem pembayaran Bank Rusia masuk ke …SHAREout.
Kami juga akan berasumsi bahwa ketika mengimplementasikan modul integrasi, daftar sertifikat yang dicabut diperbarui hanya ketika kunci kriptografi diterbitkan kembali, dan juga bahwa pesan elektronik yang diterima di folder …SHAREIn hanya diperiksa untuk kontrol integritas dan kontrol kepercayaan pada kunci publik dari tanda tangan elektronik.

Menyerang

Para penyerang, dengan menggunakan kunci yang dicuri dalam skenario sebelumnya, menandatangani perintah pembayaran palsu yang berisi informasi tentang penerimaan uang ke rekening klien penipu dan memasukkannya ke saluran pertukaran data yang aman. Karena tidak ada verifikasi bahwa perintah pembayaran ditandatangani oleh Bank Rusia, maka perintah tersebut diterima untuk dieksekusi.

Sumber: www.habr.com

Tambah komentar