Panduan dokumentasi internal tentang keamanan informasi. Apa, bagaimana, dan mengapa

Dalam salah satu artikel kami sebelumnya, kami menyentuh masalah pembentukan seperangkat dokumen untuk penguji tentang perlindungan data pribadi. Kami memberikan tautan ke templat dokumen kami, tetapi berfokus pada topik dokumentasi keamanan informasi dengan sangat dangkal.

Dalam artikel ini, saya ingin mengungkapkan topik ini secara lebih rinci baik dalam konteks data pribadi pada khususnya, dan perlindungan informasi secara umum. Dokumen apa yang seharusnya ada pada operator, yang bersifat opsional. Dari mana permintaan dokumen ini atau itu berasal. Apa yang harus ditulis dalam dokumen dan apa yang tidak layak. Di bawah potongan banyak surat tentang hal ini.

Beberapa kata untuk membela keamanan "kertas"

Karena artikel ini akan fokus pada apa yang disebut keamanan "kertas", saya ingin segera menguraikan posisi kami pada bagian keamanan informasi ini.

Bagi banyak teknisi yang bekerja dengan "tangan" keamanan "kertas" ini sering menyebabkan penolakan dan pengabaian yang tajam. Namun, anehnya, ketika teknisi seperti itu dapat mengambil bagian baru dari perangkat keras atau perangkat lunak (dan kadang-kadang keduanya dalam satu produk), ia ingin berkenalan dengan dokumentasi untuk keajaiban teknologi ini.

Pembenaran yang paling umum untuk posisi penolakan semacam itu adalah bahwa semua dokumen ini dilakukan hanya untuk pertunjukan guna memenuhi persyaratan hukum, ini adalah buang-buang waktu, dokumen harus didukung, tetapi tidak ada yang akan melakukan ini, dll, dll.

Sayangnya, posisi ini tidak berdasar. Selama bertahun-tahun, baik di antara penjaga keamanan lokal dan di antara pemegang lisensi, integrator, dan pihak berkepentingan lainnya, praktik yang menyedihkan telah berkembang dengan cara yang sama dengan dokumen keamanan informasi. Akibatnya, lingkaran setan ditarik - dokumen dianggap tidak berguna karena diabaikan, dan pada gilirannya diabaikan karena tidak berguna.

Ini sebagian diperparah oleh fakta bahwa seringkali dokumen keamanan informasi ditulis oleh orang-orang yang jauh dari teknologi informasi. Lagi pula, bagaimana saya bisa menulis bagian tentang melindungi alat virtualisasi tanpa memahami cara kerja virtualisasi ini?

Untuk membalikkan situasi ini, perlu membuat dokumen yang baik, informatif dan bermanfaat. Pada saat yang sama, dokumen-dokumen ini harus mematuhi undang-undang perlindungan informasi yang berlaku. Mari kita lihat apa yang bisa dilakukan dengan semua ini.

Beberapa klarifikasi

Untuk memulainya, untuk menghilangkan pertanyaan dan dugaan yang tidak perlu, kami menganggap perlu untuk mengklarifikasi beberapa poin.

1. Dalam artikel ini kami hanya akan mempertimbangkan dokumen internal organisasi dan administrasi (selanjutnya disebut sebagai "ARD") untuk perlindungan informasi. Desain, sertifikasi, dan dokumen lainnya tidak akan dipertimbangkan.
2. Kami juga tidak akan mempertimbangkan model ancaman, meskipun templatnya ada di sini . Perkembangan model ancaman adalah cerita lain. Tulis di komentar - apakah Anda memerlukan manual tentang pengembangan model ancaman pada Habré?
3. Artikel ini akan bergantung pada set templat kami. Ini bukan semacam standar atau set yang diterima secara umum. Perangkat ini mencerminkan pendekatan kami yang murni terhadap pengembangan ARD. Karena undang-undang tersebut sering tidak menentukan sesuatu yang spesifik dalam hal ini, Anda mungkin memiliki pendapat sendiri tentang kelengkapan dan isi dokumen dan ini normal!
4. Mungkin ada kesalahan dan kesalahan ketik pada template. Kita sendiri senantiasa memperbaiki dan memperbaiki mereka.
5. Dalam konteks pemenuhan persyaratan, subjek data pribadi (152- dan by-law) dan sistem informasi negara (urutan 17 FSTEC) akan sangat terpengaruh. Selain itu, ada cerita lain dengan organisasi keuangan (persyaratan Bank Sentral Federasi Rusia) dan berbagai standar (ISO 2700x dan lainnya) - kami tidak akan mempertimbangkannya di sini.

Kelengkapan dokumen

Jika Anda mengandalkan undang-undang untuk melindungi informasi, ada sedikit yang mengatakan di mana tepatnya dokumen apa yang harus kami kembangkan, jadi kami harus mengandalkan berbagai petunjuk tidak langsung.

Misalnya, kami memberikan bagian 2 pasal 19 undang-undang No. 152-FZ "Tentang data pribadi". Teks polos akan menjadi teks hukum, dicetak miring - catatan penulis.

2. Keamanan data pribadi tercapai, khususnya:

1) penentuan ancaman terhadap keamanan data pribadi selama pemrosesan dalam sistem informasi data pribadi; (butuh model ancaman)

2) penerapan langkah-langkah organisasi dan teknis untuk memastikan keamanan data pribadi selama pemrosesan dalam sistem informasi data pribadi yang diperlukan untuk memenuhi persyaratan untuk perlindungan data pribadi, implementasi yang memastikan tingkat keamanan data pribadi yang ditetapkan oleh Pemerintah Federasi Rusia; (Langkah-langkah organisasi untuk sebagian besar adalah dokumen kami, ditambah di sini mereka mengirim kami untuk membaca lebih lanjut oleh-hukum)

3) dengan menggunakan prosedur untuk menilai kesesuaian fasilitas perlindungan informasi yang telah lulus dengan cara yang ditentukan;

4) evaluasi efektivitas tindakan yang diambil untuk memastikan keamanan data pribadi sebelum komisioning sistem informasi data pribadi;

5) dengan memperhatikan pembawa data akun mesin pribadi; (jelas Anda memerlukan semacam jurnal akuntansi dan aturan yang dikembangkan untuk akuntansi media mesin)

6) penemuan akses tidak sah ke data pribadi dan adopsi tindakan; (perlu untuk mengembangkan beberapa aturan untuk mendeteksi insiden dan menghilangkan konsekuensinya, mungkin perlu untuk menunjuk tim respon insiden)

7) pemulihan data pribadi yang dimodifikasi atau dimusnahkan karena akses yang tidak sah ke sana; (aturan cadangan dan kembalikan diperlukan)

8) penetapan aturan untuk akses ke data pribadi yang diproses dalam sistem informasi data pribadi, serta pendaftaran dan pencatatan semua tindakan yang dilakukan dengan data pribadi dalam sistem informasi data pribadi; (pengembangan sistem akses ke data dapat dilakukan berdasarkan peran dalam sistem, hanya perangkat lunak itu sendiri yang harus dapat mempertahankan log dari siapa yang digunakan untuk mengakses data apa)

9) kontrol atas tindakan yang diambil untuk memastikan keamanan data pribadi dan tingkat keamanan sistem informasi data pribadi. (kami membutuhkan rencana tertentu untuk pemantauan berkala, plus, mungkin, jurnal di mana hasil pemantauan tersebut akan dicatat)

Dengan contoh ini, kami ingin menunjukkan perbedaan: bagaimana undang-undang itu ditulis dan apa yang sebenarnya dituntut dari kita. Di sini kita tidak melihat persyaratan langsung "operator harus mengembangkan model ancaman", tetapi kebutuhan ini masih mengikuti dari teks 152-FZ, karena pemenuhan persyaratan apa pun didokumentasikan.

Lebih khusus lagi, FSTEC memberi tahu kita tentang kelengkapan dan isi ARD. Pada tahun 2014, regulator ini mengeluarkan dokumen metodologis, Tindakan Keamanan Informasi dalam Sistem Informasi Negara. Sebuah dokumen tanpa sarkasme sangat baik, jika Anda tidak memahami sesuatu dalam urutan penerapan langkah-langkah ke-17, ke-21 atau perintah-perintah FSTEC lainnya (ya, meskipun dokumen tersebut ditujukan untuk GIS, tetapi langkah-langkah untuk sebagian besar bertepatan dengan FSTEC), lihat ini dokumen mungkin menjadi lebih jelas.

Jadi, dalam dokumen ini, FSTEC secara lebih luas menguraikan langkah-langkah untuk memastikan keamanan informasi dan sangat sering Anda dapat menemukan teks seperti itu:

Aturan dan prosedur untuk identifikasi dan otentikasi pengguna diatur dalam dokumen organisasi dan administrasi untuk perlindungan informasi. (IAF.1)

Aturan dan prosedur untuk mengelola akun pengguna diatur dalam dokumen organisasi dan administrasi operator untuk melindungi informasi. (UPD.1)

Aturan dan prosedur untuk mengelola arus informasi diatur dalam dokumen organisasi dan administrasi operator untuk perlindungan informasi. (UPD.3)

Yah, sudah ada sesuatu, tetapi aturan dan prosedur ini adalah kereta keseluruhan.

Akibatnya, saya harus membungkam diri saya dengan piring yang menulis semua persyaratan dari semua dokumen dan membuat catatan dan catatan tentang pemenuhan, non-pemenuhan.



Gagasan utama dari bagian ini adalah ada serangkaian persyaratan dalam undang-undang tentang perlindungan informasi, implementasi banyak dari mereka perlu didokumentasikan. Apakah membuat dokumen terpisah untuk setiap persyaratan atau untuk menggabungkan semuanya menjadi satu "Kebijakan IS" besar terserah semua orang. Semua hal tambahan yang perlu kita daftarkan dalam dokumen tidak sesuai dengan persyaratan, tetapi berdasarkan kebutuhan praktis, ditambahkan tanpa masalah.

By the way, perhatikan bahwa dalam tabel dan dalam dokumen itu sendiri, beberapa bagian atau paragraf diberi label "K1" atau "K2 +". Ini berarti bahwa bagian atau paragraf diperlukan hanya untuk sistem informasi kelas 2 dan di atas atau untuk yang pertama (kelas maksimum). Semua yang tidak ditandai dilakukan di semua sistem informasi negara dan ISPD.

Juga jelas bahwa, misalnya, beberapa bagian atau bahkan seluruh dokumen dapat dihilangkan jika karakteristik struktural dan fungsional dari sistem informasi atau kondisi awal lainnya memerlukannya. Misalnya, kami menghapus ketentuan pengawasan video, jika tidak. Atau kami menghapus semua bagian yang terkait dengan perlindungan alat virtualisasi, jika tidak diterapkan.

Template kami dibagi menjadi 4 folder:

Umum - dokumen yang perlu dikembangkan untuk semua sistem (sebagaimana berlaku), apakah itu ISPDn, GIS, sistem kontrol proses otomatis atau objek KII.

Hanya GIS - dokumen untuk sistem informasi negara atau sistem informasi kota, hanya ada dokumen unik yang diperlukan untuk GIS dan MIS.

PD - dokumen tentang perlindungan data pribadi dan sesuai dengan undang-undang tentang perlindungan data pribadi. Jika, misalnya, kami memiliki GIS di mana data pribadi diproses, maka kami harus membuat dokumen dari semua folder.

CIPF - dokumen yang terkait dengan penggunaan alat kriptografi, diperlukan untuk implementasi dokumen peraturan FSB, dikembangkan untuk semua sistem yang menggunakan cara kriptografi bersertifikat untuk perlindungan informasi.

Mari kita pertimbangkan lebih detail dokumen-dokumen itu, dari mana asalnya dan persyaratan apa yang mereka penuhi.

Jenderal

01 Perintah pengangkatan orang yang bertanggung jawab dan instruksi kepada orang-orang ini

Pesanan ini menunjuk: orang yang bertanggung jawab untuk mengatur pemrosesan data pribadi dan administrator keamanan.

Kebutuhan untuk menunjuk yang pertama diatur oleh pasal 18.1 hukum federal:

1. Operator harus mengambil tindakan ... Tindakan tersebut dapat mencakup, tetapi tidak terbatas pada:

1) penunjukan oleh operator, yang merupakan badan hukum, dari orang yang bertanggung jawab untuk mengatur pemrosesan data pribadi;

Administrator Keamanan - kebutuhan untuk teman ini adalah karena, misalnya, klausul 9 dari FSTEC Pesanan No. 17:

Untuk memastikan perlindungan informasi yang terkandung dalam sistem informasi, operator menunjuk unit struktural atau pejabat (karyawan) yang bertanggung jawab atas perlindungan informasi.

Orang-orang ini berbeda dalam hal “bertanggung jawab” lebih di bagian kertas, dan “administrator” di bagian teknis.

Agar penanggung jawab dan administrator memahami tugas dan wewenang mereka, mereka berhak atas instruksi.

02 Memerintahkan penunjukan tim tanggapan insiden keamanan informasi (GRIIB) dan instruksi tanggapan

Singkatan dari SRIMS, meskipun sedikit konyol, tetapi cukup resmi, diperkenalkan oleh GOST R ISO / IEC TO 18044-2007 “Teknologi informasi. Metode dan alat keamanan. Manajemen Insiden Keamanan Informasi. "

Kebutuhan akan dokumen diperlukan oleh sejumlah dokumen peraturan. Misalnya, pasal 19 UU tentang Data Pribadi yang sama. Tetapi secara lebih rinci respon terhadap insiden diungkapkan dalam perintah FSTEC.

Pesanan FSTEC No. 17:

18.2. Dalam proses mengidentifikasi dan menanggapi insiden:

• identifikasi orang yang bertanggung jawab untuk mengidentifikasi insiden dan meresponsnya;
• deteksi dan identifikasi insiden, termasuk penolakan layanan, kegagalan (reboot) dalam pengoperasian perangkat keras, perangkat lunak dan alat perlindungan informasi, pelanggaran aturan kontrol akses, tindakan ilegal untuk mengumpulkan informasi, pengenalan program komputer jahat (virus) dan kejadian lainnya, menyebabkan insiden;
• memberi tahu orang yang bertanggung jawab untuk mengidentifikasi insiden secara tepat waktu dan meresponsnya, tentang terjadinya insiden dalam sistem informasi oleh pengguna dan administrator;
• analisis insiden, termasuk menentukan sumber dan penyebab insiden, serta menilai konsekuensinya;
• merencanakan dan mengambil langkah-langkah untuk menghilangkan insiden, termasuk pemulihan sistem informasi dan segmennya jika terjadi penolakan layanan atau setelah kegagalan, menghilangkan konsekuensi dari pelanggaran aturan kontrol akses, tindakan ilegal untuk mengumpulkan informasi, memperkenalkan program komputer berbahaya (virus) dan kejadian lainnya menyebabkan insiden;
• Merencanakan dan mengambil tindakan untuk mencegah terulangnya insiden.

Dokumen yang sama menutup sejumlah tindakan organisasi, misalnya, RSB.1 "Penentuan peristiwa keamanan yang akan direkam dan periode penyimpanannya" dan SSB.2 "Penentuan komposisi dan konten informasi tentang peristiwa keamanan yang akan didaftarkan". Semua hal ini dapat diindikasikan dalam instruksi respon kejadian agar tidak menghasilkan dokumen terpisah.

03 Panduan pengguna

Pembenaran hukum utama untuk kebutuhan instruksi semacam itu adalah semua tempat dalam undang-undang di mana ia mengatakan tentang menginstruksikan pengguna tentang masalah keamanan informasi. Misalnya, Bagian 1 Pasal 18.1 Undang-Undang tentang Data Pribadi:

6) pengenalan karyawan operator yang secara langsung memproses data pribadi dengan ketentuan undang-undang Federasi Rusia tentang data pribadi, termasuk persyaratan untuk perlindungan data pribadi, dokumen yang menetapkan kebijakan operator mengenai pemrosesan data pribadi, tindakan lokal dalam pemrosesan data pribadi, dan (atau) pelatihan karyawan ini.

Kebutuhan tidak langsung untuk dokumen semacam itu adalah pendaftaran hukum atas tanggung jawab pengguna untuk kemungkinan insiden keamanan informasi. Seperti yang diperlihatkan oleh praktik , dalam kasus di mana instruksi semacam itu tidak ada dan (atau) pengguna tidak mengenalnya, pengguna yang melanggar persyaratan IS kemungkinan besar tidak akan dimintai pertanggungjawaban.

Adapun dokumen itu sendiri, di sini kami memutuskan untuk tidak memuat pengguna dengan omong kosong bahwa mereka tidak perlu, membuat dokumen tidak terlalu sulit untuk dipahami dan berguna tidak hanya dalam kaitannya dengan keamanan informasi di perusahaan, tetapi juga dalam masalah keamanan informasi dalam kehidupan pribadi. Sebagai contoh, mereka menggambarkan metode rekayasa sosial dengan contoh.

05 Kebijakan Keamanan Informasi

Mungkin salah satu dokumen paling banyak dari seluruh set. Ingat di atas, kami menulis tentang dokumen "Langkah-langkah untuk melindungi informasi dalam SIG" dan tentang sejumlah besar "aturan dan prosedur" yang perlu ditulis dalam ARD? Sebenarnya, “Kebijakan IB” sebenarnya adalah kumpulan dari semua aturan dan prosedur tersebut.

Di sini, mungkin, ada baiknya berhenti pada kata "Politik". Kita sering diberitahu bahwa "Politik" kita terlalu ditargetkan, tetapi pada kenyataannya dokumen dengan nama itu harus lebih abstrak dan tingkat tinggi. Mungkin memang demikian, tetapi di sini sebagai petugas keamanan, pertama-tama, dengan latar belakang teknis, kata "Politik" dikaitkan, misalnya, dengan kebijakan grup dari domain tersebut, yang pada gilirannya terkait dengan aturan dan pengaturan khusus.

Sebenarnya, apa yang disebut sebagai dokumen itu tidak penting. Jika Anda tidak menyukai kata "Kebijakan", Anda dapat mengganti namanya menjadi "Aturan dan Prosedur untuk Keamanan Informasi." Ini bukan intinya. Hal utama adalah bahwa aturan dan prosedur ini harus sudah secara jelas dan spesifik dijabarkan dalam dokumen ini.

Kami akan berhenti di sini lebih terinci.

Jika Anda membuka dokumen dan mulai bekerja dengannya, Anda akan melihat bahwa di beberapa tempat tidak ada kekosongan teks tertentu, tetapi ada "Jelaskan" yang kering. Ini karena beberapa hal tidak dapat dijelaskan sehingga teks tersebut cocok untuk setidaknya setengah dari sistem informasi spesifik pada saat yang sama. Untuk setiap kasus, lebih baik untuk menggambarkan bagian ini secara terpisah. Itu sebabnya kami masih skeptis terhadap berbagai pengisi dokumen otomatis.

Dalam teks utama semuanya harus jelas secara keseluruhan, saya ingin membahas sedikit aplikasi.

Permintaan perubahan ke daftar pengguna

Tampaknya bagi banyak orang prosedur ini untuk melacak pengguna dan kredensial mereka dalam sistem yang sangat birokratis, namun, kami sering bertemu dengan situasi di mana pendekatan ini membantu untuk maju dalam penyelidikan insiden keamanan informasi. Misalnya, perlu untuk menetapkan kekuatan apa yang diberikan kepada pengguna pada awalnya. Ketika aplikasi dari aplikasi ke kebijakan IS dinaikkan, ternyata satu akun memiliki peningkatan otoritas yang tidak sah.

Dalam setiap kasus, tergantung pada masing-masing operator untuk memutuskan apakah akan melakukan prosedur pendaftaran pengguna atau tidak. Di sini, mungkin perlu disebutkan segera bahwa apa yang secara eksplisit dilakukan persis seperti yang dijelaskan dalam model kebijakan IS kami tidak diperlukan oleh tindakan legislatif apa pun. Templat dokumen kemungkinan besar merupakan opsi yang paling parah dan menyedihkan. Dan kemudian semua orang memutuskan untuk dirinya sendiri - di mana untuk melonggarkan mur, dan di mana untuk mengencangkan lebih.

Peraturan tentang pembatasan hak akses dan daftar orang

Diferensiasi hak akses pengguna merupakan ukuran yang jelas bagi administrator sistem mana pun. : .2 « (, , ), (, , ) », .4 « () , , » .

, .

. , , . . – , « » , « » , « » .



.3 « (, , , ) , , ».

, , , « ». , « » - . , .



.3 « () () ». , , .

, - . - - .

. , , .



. « 2 : , , ». , , , « , » .

10 .

( ), . , 2 19 « »:

, :

7) , ;

:

.4

. , , , .

, :

.3 , ,

06

: .2 « , , , , ».

, , , . ., . , , . , , «», , .

07 ...

2 – . 2 , .

: « , , , , ?». , – . , , , - . .

– , . , 1 18.1 « »:

1. … , , :

4) () , , , ;

08-14 ...

08-10 . :

• , , . .;
• (, , , . .);
• (, HDD, ).

. . , . , - . , , , 09 10 .

, . . .

, . . , , . .

01

, . , 17- « , ». , , , « ».

, .

02-03

. , , .

, , .

– , , .

04

17- , ( ) .

01

, , . , , . , . , - .

02

3 « » . , , , . . , .

, , , ( , ). .

03

, . , . , , , (, ). , .

04

! : « ?».

2 18.1 « »:

, , . , - , - , , , - .

, , . , , , .

05-06

, . : , , . , .

07

- , , , .

. . — , – . , , , , .

, . :

1. , ( — ), (), , , , , , .

2. , .

, . « » :

4) — ;

. , – , ( – ).

08

, , , , . , , . . .

09

. . , , . .

10

, . , 4 9 « ».

11

, , . - . , . , — , , .

12

, ( , ).

13

. – . , .

, . , , . ( 2001 ), - , , . , .

Kesimpulan

Kami berharap bahwa panduan kecil ini untuk dokumentasi internal tentang keamanan informasi akan bermanfaat. Mungkin itu ditulis agak berantakan, karena topiknya sangat luas, dan saya tidak ingin memperluas topik menjadi beberapa bagian. Jika kami melewatkan sesuatu dan memiliki pertanyaan tentang topik tersebut, kami akan menjawabnya di komentar. Dan, tentu saja, hal utama adalah jangan lupa bahwa yang dinyatakan dan dijelaskan dalam dokumen harus dieksekusi pada kenyataannya, maka dokumen tidak akan menjadi sampah sia-sia "untuk ditampilkan".