Laporan Kemajuan
pada CVE Initiative
Robert Martin, Steven Christey, and David Baker
Kerentanan dan Eksposur umum (CVE) adalah upaya berbasis masyarakat internasional, termasuk industri, pemerintah, dan akademisi, yang bekerja untuk menciptakan mekanisme
pengorganisasian untuk membuat mengidentifikasi, menemukan, dan memperbaiki produk perangkat lunak kerentanan lebih cepat dan efisien. Beberapa tahun yang lalu, kita masing-masing dihadapkan dengan hiruk-pikuk penamaan metode untuk mendefinisikan masalah keamanan individu dalam perangkat lunak. Hal ini membuat sulit untuk menilai, mengelola, dan memperbaiki kerentanan dan eksposur saat menggunakan berbagai layanan kerentanan, alat, dan database bersama dengan pemasok perangkat lunak 'pengumuman update dan alert. Misalnya, Bukti 70.1 menunjukkan bagaimana pada tahun 1998 masing-masing dari organisasi terkemuka selusin digunakan nama yang berbeda untuk merujuk sama terkenal kerentanan dalam program phf buku telepon CGI. Kebingungan seperti membuat sulit untuk memahami yang kerentanan suatu organisasi yang dihadapi dan mana yang masing-masing alat cari (atau tidak mencari). Kemudian, untuk mendapatkan fix untuk kerentanan diidentifikasi, pengguna masih harus mencari tahu apa nama kerentanan atau paparan ditugaskan oleh pemasok perangkat lunak mereka.
Didorong oleh keinginan untuk mengembangkan gambaran yang terintegrasi dari apa yang terjadi pada jaringan perusahaan, dan ketika mencoba untuk benar penelitian pilihan untuk memilih beberapa alat keamanan jaringan baru, yang disebut MITRE korporasi. (http://www.mitre.org) mulai merancang sebuah metode untuk memilah-milah ini penamaan kerentanan kebingungan. Pendekatan ini melibatkan penciptaan daftar referensi terpadu kerentanan dan eksposur nama yang dipetakan ke item setara dalam setiap alat dan basis data. Pada bulan Januari 1999, MITRE disajikan kertas di 2 Workshop Penelitian dengan Database Kerentanan Keamanan di Universitas Purdue. diuraikan konsep dan pendekatan untuk apa saat ini dikenal sebagai kerentanan umum dan Eksposur Initiative
(http://cve.mitre.org). Produk utama dari Inisiatif ini adalah CVE Daftar, daftar referensi nama standar untuk kerentanan dan eksposur.
CVE Daftar dibayangkan sebagai mekanisme sederhana untuk menghubungkan database-kerentanan terkait, peralatan, dan konsep. Hal itu diyakini penting bagi masyarakat keamanan informasi setuju dengan pendekatan CVE dan mulai menggabungkan nama umum menjadi berbagai produk dan layanan mereka. Oleh karena itu, peran CVE ini terbatas dengan sebuah jembatan logis untuk
menghindari bersaing dengan usaha komersial yang ada dan masa depan. Meskipun nama CVE itu sendiri adalah sederhana dalam konsep, tidak akan ada yang sederhana tentang pelaksanaan CVE Initiative. Untuk menjadi sukses, semua informasi kerentanan yang ada harus diperiksa dan
yang sama. Kemudian, deskripsi yang unik dan konsisten untuk setiap masalah harus dibuat, dan para pemimpin teknis komunitas keamanan informasi harus dibawa bersama-sama untuk menyepakati deskripsi. CVE Daftar harus secara luas didistribusikan untuk vendor komersial dan peneliti untuk mengadopsi itu. Sebuah kompatibilitas CVE proses evaluasi harus dirancang untuk memverifikasi klaim vendor dukungan untuk nama CVE dalam produk dan layanan, dan kebijakan harus dibuat untuk mendorong penggunaan CVE-kompatibel produk. CVE Initiative juga harus menjadi upaya berkelanjutan karena kerentanan baru selalu menjadi ditemukan, dan pada tingkat meningkat. Akhirnya, CVE Initiative harus mencakup partisipasi internasional di kedua mereka membantu dengan perkembangan Daftar CVE, dan oleh komunitas vendor dan lainnya organisasi yang menggunakan nama-nama umum dalam produk dan layanan mereka.
BUKTI 70.1 Kerentanan Menara Babel 1998
Organisasi Kerentanan
AXENT (sekarang Symantec) phf CGI memungkinkan eksekusi perintah remote
BindView # 107 - cgi-phf
bugtraq Serangan PHF - permainan bagi seluruh keluarga
CERIAS http_escshellcmd
Cert CA-96.06.cgi_example_code
Cisco Systems HTTP - cgi-phf
CyberSafe Jaringan: serangan HTTP "phf"
DARPA 0x00000025 = HTTP serangan PHF
IBM ERS ERS-SVA-E01-1996: 002,1
ISS http - cgi-phf
Symantec # 180 HTTP server contoh CGI kode kompromi http server
SecurityFocus # 629 - phf Remote Command Execution Vulnerability
Untuk memandu berbagai aspek CVE Initiative untuk memungkinkan adopsi Daftar CVE sebagai umum
mekanisme untuk mengacu pada kerentanan dan eksposur, CVE telah membagi lima bidang tertentu kegiatan yang ditargetkan, meliputi:
1. Uniknya penamaan terkenal setiap publik tentang kerentanan keamanan informasi dan eksposur.
2. Menyuntikkan nama CVE dalam penasehat keamanan .
3. Membangun penggunaan CVE dalam produk keamanan informasi sebagai praktek umum 4. Memiliki penggunaan CVE menyerap pedoman kebijakan tentang metodologi dan pembelian,
termasuk sebagai persyaratan untuk kemampuan baru, dan memperkenalkan CVE ke pelatihan, pendidikan, dan praktik saran terbaik .
5. Pengembang perangkat lunak komersial meyakinkan untuk menggunakan nama CVE di situs fix-it dan mekanisme pembaruan.
Implementasi CVE Initiative
Setelah respon positif dari Purdue CERIAS Workshop, MITRE dibentuk Dewan CVE Editorial di Mei 1999 dengan 12 pemasok dan penelitian organisasi komersial, yang bekerja untuk mencapai kesepakatan pada Daftar CVE awal dengan MITRE sebagai moderator. Selama waktu yang sama, tim MITRE bekerja untuk mengembangkan publik Web situs untuk menjadi tuan rumah Daftar CVE, diskusi arsip Dewan Editorial, dan tuan rumah deklarasi vendor niat untuk membuat produk CVE-kompatibel. CVE Initiative adalah publik diresmikan pada September 1999. pembukaan termasuk daftar awal dari 321 entri, teleconference press release, dan stan CVE yang dikelola dengan Anggota Dewan Redaksi pada konferensi teknis SANS 1999. Itu adalah pesan yang sangat kuat untuk peserta untuk melihat booth CVE dikelola oleh bersaing vendor komersial bekerja sama untuk memecahkan masalah industri. Ada audiens yang besar dari administrator sistem dan spesialis keamanan yang hadir, yang telah berurusan dengan masalah yang sama yang memotivasi penciptaan CVE Initiative.
Sebagai volume informasi kerentanan yang masuk meningkat untuk kedua isu-isu baru dan warisan, MITRE membentuk tim konten untuk membantu dengan pekerjaan menghasilkan konten CVE. Peran dan tanggung jawab Dewan Editorial yang diformalkan. MITRE bekerja dengan vendor untuk menempatkan nama CVE di advisories keamanan kerentanan diumumkan, dan bekerja dengan Dewan Pertimbangan CVE Senior untuk mengembangkan kebijakan merekomendasikan penggunaan produk dan jasa CVE-kompatibel dan untuk menemukan cara-cara pendanaan CVE Inisiatif untuk jangka panjang. Sejak awal, MITRE telah mempromosikan CVE Initiative dan di berbagai tempat, termasuk tuan stan di pameran dagang industri, wawancara dengan media, penerbitan CVEfocused artikel dalam jurnal nasional dan internasional, menyajikan pembicaraan CVE-terfokus dalam forum publik dan konferensi.
Daftar CVE
CVE Initiative telah harus mengatasi banyak perspektif yang berbeda, keinginan, dan
kebutuhan seperti yang berkembang CVE yang Daftar. Nama-nama umum dalam Daftar CVE
adalah hasil dari diskusi yang terbuka dan kolaboratif CVE yang Dewan Editorial (diskusi lebih
dalam Dewan dapat ditemukan kemudian dalam bab ini), bersama dengan berbagai mendukung
dan memfasilitasi kegiatan oleh MITRE dan lain-lain. Dengan dukungan MITRE ini, Dewan
mengidentifikasi yang kerentanan atau eksposur untuk memasukkan dalam Daftar CVE dan
setuju pada nama umum, deskripsi, dan referensi untuk setiap entri. MITRE mempertahankan
Daftar CVE dan situs Web, moderat diskusi Dewan Redaksi, analisis materi yang disampaikan,
dan memberikan bimbingan selama proses untuk memastikan bahwa CVE tetap obyektif
dan terus melayani kepentingan publik.
Calon CVE vs Entri CVE
diterima menjadi CVE, angka-angka ini menjadi entri CVE. Sebagai contoh, jumlah kandidat sebelumnya akan memiliki akhirnya Jumlah CVE dari CVE-1999-0067, di mana "BISA" awalan diganti dengan "CVE" awalan. Tugas dari sejumlah kandidat bukan jaminan bahwa itu akan menjadi entri CVE resmi.
Sumber data dan Perluasan Daftar CVE
Sepanjang kehidupan Daftar CVE, MITRE mengandalkan sumber data lainnya untuk
mengidentifikasi kerentanan. Sebagai Hasilnya, MITRE dapat berkonsentrasi pada merancang nama standar, bukan "menciptakan kembali roda" dan melakukan penelitian yang diperlukan untuk menemukan laporan kerentanan awal. Sebelum CVE dirilis ke publik di September 1999, sebuah "rancangan CVE" diciptakan dan disampaikan kepada Dewan Editorial untuk umpan balik. ISS, L-3 Keamanan (kemudian diakuisisi oleh Symantec), SANS, dan Netect (kemudian diakuisisi oleh BindView) memberikan informasi yang digunakan untuk membantu menciptakan rancangan CVE. Data juga diambil dari sumber-sumber lain, termasuk Bugtraq dan NTBugtraq
posting, CERT, dan alat-alat keamanan seperti NAI ini seperti polisi komputer Scanner, Cisco NetSonar, dan AXENT NetRecon.
Pada bulan November 1999, dua bulan setelah versi pertama dari Daftar CVE dibuat tersedia, MITRE bertanya Anggota Dewan Editorial untuk memberikan "top 100" daftar kerentanan yang harus di CVE Daftar, yang menghasilkan lebih dari 800 pengajuan. Berkontribusi organisasi yang Purdue CERIAS, ISS, Harris, BindView, Hiverworld (kemudian nCircle), Cisco, L-3 Keamanan (kemudian diakuisisi oleh Symantec), dan AXENT (kemudian diakuisisi oleh Symantec). Pada saat ini, MITRE juga mulai mengolah kerentanan baru ditemukan, menggunakan periodik ringkasan kerentanan diterbitkan oleh
SecurityFocus, Network Computing / SANS, ISS, dan Infrastruktur Nasional Pusat Perlindungan (NIPC).
Untuk mengelola volume kerentanan yang diajukan, MITRE mulai mengembangkan pengajuan pencocokan dan perbaikan proses yang dijelaskan kemudian dalam bab ini.
Pada musim panas tahun 2000, Mitre lagi berusaha untuk memperluas Daftar CVE untuk
menyertakan lebih tua "warisan" masalah yang tidak dalam rancangan CVE asli, kali ini menerima salinan dari database kerentanan dari sepuluh organisasi - total sekitar 8400 kiriman. Kontributor yang AXENT (sekarang Symantec), BindView, Harris Corporation, Cisco Systems, Pusat Purdue University untuk Pendidikan dan Penelitian di Informasi dan Keamanan (CERIAS), Hiverworld (sekarang nCircle),
SecurityFocus, Internet Security Systems (ISS), Jaringan Associates, L3 (sekarang Symantec), dan Proyek Nessus. Kontribusi ini dibuat sementara baru masalah ditemukan juga sedang diproses secara paralel. Pada tahun berikutnya, MITRE diperluas dukungannya staf dan meningkatkan proses dan utilitas untuk menangani peningkatan volume informasi.
tingkat abstraksi. Penelitian dan analisis MITRE saat ini sedang fokus pada Windowsbased porsi masalah konfigurasi ini.
Sisanya 900 kiriman warisan membentuk dasar dari 563 calon CVE yang diusulkan ke Dewan pada September 2001. Sejumlah kecil pengajuan dari November 1999 masih tetap, sebagian besar karena kurangnya informasi yang cukup untuk membuat calon.
Sementara MITRE memproses pengajuan warisan yang tersisa dan melakukan penelitian latar belakang yang diperlukan, terus menerima antara 400 dan 600 pengajuan baru per bulan dari ISS, SecurityFocus, Neohapsis, dan Infrastruktur Nasional Perlindungan Center. Setiap bulan, tambahan 20 sampai 70 calon tertentu yang milik sebelum kerentanan baru atau paparan dikenal publik, dengan jumlah calon kemudian dimasukkan di penjual dan komunitas keamanan alert anggota dan nasihat.
Karena ada penekanan meningkat pada menciptakan calon warisan selama musim panas 2001, backlog kiriman untuk isu terbaru yang dikembangkan. Calon isu-isu tersebut itu harus dibuat pada awal tahun 2002, dan proses tambahan sedang dilaksanakan untuk menghindari backlog tersebut di masa depan. Salah satu jalan yang menjadi diupayakan untuk mengatasi masalah ini adalah keterlibatan aktif dari vendor dan peneliti untuk memasukkan calon CVE nama dalam nasihat awal mereka dan alert. Untuk saat ini, berbagai individu dan organisasi telah memesan lebih dari 870 nomor calon untuk digunakan dalam pengumuman publik kerentanan, termasuk ISS, IBM, Rain Forest Puppy, @ Stake, Microsoft, BindView, NAI, CERT / CC, SGI, eEye, COMPAQ, Ernst & Young, CISCO, Cepat 7, NSFOCUS, Sanctum, Alcatel, EnGarde Aman Linux, Caldera, Red Hat, SecurityFocus, main hakim sendiri. com, Cert-IST, Mandrake Linux, Debian, Foundstone, Apple, iDefense, HP, Symantec, DHS / NIPC, KDE e. V., Beyond Keamanan Ltd, Digital Defense Inc., Core-ST, The OpenPKG Project, Corsaire, The FreeBSD Proyek, dan Gentoo Linux.
Pertumbuhan Daftar CVE sejak Inception
beberapa 6.036 kerentanan unik bernama dan eksposur, yang meliputi saat CVE Daftar, baru-baru ini ditambahkan calon warisan, dan generasi yang sedang berlangsung dari calon baru dari penemuan-penemuan terbaru.
Proses Membangun Daftar CVE: The Stage Submission : Tahap 1
Proses review CVE dibagi menjadi tiga tahap: (1) tahap pengajuan awal, (2) tahap kandidat, dan (3) tahap entri. MITRE bertanggung jawab untuk tahap pengajuan tetapi tergantung pada data sumber untuk pengiriman. Dewan Redaksi berbagi tanggung jawab untuk tahap kandidat dan masuk, meskipun tahap entri terutama dikelola oleh MITRE sebagai bagian dari perawatan CVE normal.
Tim konten
Untuk proyek CVE, MITRE memiliki tim konten yang utama tugas adalah untuk menganalisis, penelitian, dan proses kiriman kerentanan yang masuk dari sumber data CVE itu, mengubah pengajuan menjadi kandidat. CVE Editor, yang pada akhirnya bertanggung jawab untuk semua konten CVE, memimpin tim.
Tahap konversi
Selama tahap pengajuan, MITRE ini CVE Content Team, yang terdiri dari analis keamanan MITRE dan peneliti, mengumpulkan informasi mentah dari berbagai sumber, misalnya, berbagai anggota Dewan yang memiliki tersedia MITRE dengan database mereka, atau penerbit ringkasan kerentanan mingguan. Setiap item yang terpisah di sumber data (biasanya catatan dari kerentanan tunggal) kemudian
oleh program otomatis. setiap pengajuan termasuk pengenal yang unik yang digunakan oleh sumber data asli.
Tahap pencocokan
Setelah fase konversi ini, setiap pengiriman target otomatis dicocokkan semua kiriman lainnya, kandidat, dan entri menggunakan teknik pencarian informasi. Pencocokan didasarkan terutama pada kata kunci yang diekstrak dari deskripsi pengajuan ini, referensi, dan judul singkat. Kata kunci yang berbobot sesuai untuk seberapa sering mereka muncul, yang umumnya memberikan preferensi untuk jarang melihat hal seperti produk dan nama penjual dan rincian kerentanan spesifik. Pencocokan kata kunci tidak sepenuhnya akurat, karena mungkin ada variasi ejaan istilah penting seperti nama produk, atau istilah anomali dapat diberikan lebih besar Berat dari manusia akan menggunakan. Pertandingan terdekat untuk pengajuan sasaran (biasanya sepuluh) kemudian disajikan untuk anggota tim konten, yang mengidentifikasi yang kiriman menggambarkan masalah yang sama (atau set yang sama
erat terkait masalah) sebagai penyerahan sasaran.
Setelah pencocokan selesai, semua kiriman terkait digabungkan menjadi kelompok penyerahan, yang dapat mencakup setiap calon atau entri yang ditemukan selama cocok. Setiap kelompok
mengidentifikasi kerentanan tunggal atau kelompok kerentanan terkait erat. Kelompok-kelompok ini kemudian diproses di fase berikutnya, yang disebut "perbaikan."
Tahap perbaikan
Biasanya, anggota tim konten ditugaskan batch dari 20 atau lebih kelompok pengajuan, yang biasanya mencakup baik duplikat kiriman dan isu-isu baru.
Selama perbaikan, anggota tim analisis kelompok pengajuan dan menentukan apakah satu atau lebih dari pengajuan mengidentifikasi item CVE ada. Jika demikian, maka analis mencatat referensi tambahan yang berada di pengajuan baru, tapi tidak item CVE yang ada, sehingga referensi CVE item yang ada dapat menjadi diperpanjang.
Jika ada pengajuan dari kelompok yang tidak menggambarkan item CVE ada, maka anggota tim membuat penilaian berikut:
untuk memutuskan apakah calon harus dibuat, Terapkan CVE keputusan konten.
untuk memutuskan berapa banyak kandidat harus diciptakan,Terapkan keputusan konten CVE. (Keputusan Konten yang tercakup dalam bagian selanjutnya.)
Untuk masing-masing kandidat yang akan dibuat, analis melakukan hal berikut:
Mendaftar referensi terkait dengan menggunakan format referensi kanonik CVE. Membuat deskripsi.
Menentukan apakah ada pengakuan vendor. Mengidentifikasi keputusan konten yang terkait.
beberapa atribut lainnya. Ini Informasi digunakan untuk set sekelompok calon kemudian dalam proses, atau untuk memberikan surat suara disesuaikan individu anggota Dewan Editorial.
Mengidentifikasi kata kunci yang dapat membantu dalam pencocokan kemudian pengajuan (serta pencarian situs Web CVE ini mesin). Biasanya, kata kunci yang termasuk ejaan alternatif atau istilah yang tidak eksplisit diperlukan untuk deskripsi.
Mengidentifikasi alasan-alasan untuk pengakuan dan konten keputusan dalam "analisis" bagian.
Dalam beberapa kasus, seorang analis dapat memilih untuk menunda analisis dari kelompok pengajuan (atau sebagian kelompok) ketika sebuah masalah adalah luar biasa kompleks atau jika individu lain yang perlu dikonsultasikan.
Pengajuan perbaikan adalah hambatan karena analisis mendalam kadang-kadang diperlukan untuk memahami melaporkan masalah, menerapkan keputusan konten, menemukan penjual pengakuan, penelitian referensi, dan menulis deskripsi. Penyempitan ini terutama sulit bagi analis baru karena ada sejumlah besar detail dan latar belakang pengetahuan yang diperlukan sebelum analis menjadi nyaman dan produktif dalam melakukan perbaikan.
Tahap editing
Setelah perbaikan, ulasan pekerjaan analis CVE Editor, kadang-kadang membuat modifikasi untuk mengikuti Gaya CVE, memastikan bahwa keputusan konten CVE sedang diikuti, atau melakukan penelitian lanjutan. Kadang-kadang, kiriman dapat ditambahkan atau dihapus dari kelompok
penyempurnaan. Editor menyediakan umpan balik untuk analis untuk tujuan pelatihan atau untuk mengangkat isu-isu tertentu. Karena pencocokan pengajuan mungkin tidak selalu menemukan semua kiriman terkait, biasanya karena inkonsistensi ejaan seluruh kiriman, Editor dapat menggabungkan beberapa kelompok perbaikan yang dihasilkan oleh analis yang berbeda.
Editor kemudian memproses kelompok perbaikan yang dihasilkan. Nomor calon baru ditugaskan ke kelompok yang mengidentifikasi isu-isu baru ("tugas" fase dalam tahap kandidat).
Setelah tugas kandidat, masing-masing sumber data disediakan dengan backmap dari pengajuan mereka ke terkait item CVE (apakah baru dibuat kandidat, atau calon yang ada atau entri). Backmap yang bisa mengurangi jumlah usaha sumber data perlu dilakukan untuk menjaga pemetaan untuk CVE. Setelah backmaps untuk calon dihasilkan, pengiriman terkait dikeluarkan dari kolam pengajuan. Selain backmaps, tipe baru peta disebut sebagai "gapmap" juga disediakan untuk informasi sumber. Gapmap mengidentifikasi calon yang baru dibuat yang tidak ditemukan di asli sumber data yang set kiriman, yang dapat membuat sumber menyadari masalah keamanan tambahan yang mereka tidak melihat
sebelumnya.
Proses Membangun Daftar CVE: Bagian Calon: Tahap 2
Tahap Tugas
Calon biasanya dibuat dalam satu dari tiga cara: mereka disempurnakan oleh tim konten menggunakan pengajuan dari sumber data CVE; mereka dilindungi oleh sebuah organisasi atau individu yang menggunakannya ketika pertama kali mengumumkan masalah baru; atau mereka diciptakan "out-of-band" oleh CVE Editor, biasanya untuk segera membuat calon untuk
baru, isu penting yang sedang banyak dilaporkan.
Tahap Proposal
CVE Editor mengatur calon ke dalam kelompok 20 sampai 50 kandidat. Untuk masalah baru, cluster yang biasanya dikelompokkan oleh tanggal pengumuman umum perdana calon. Untuk masalah warisan, cluster dapat dibuat sesuai dengan kriteria lain yang membuat cluster lebih mudah dikelola bagi anggota Dewan Editorial, seperti UNIX. Cluster calon kemudian diusulkan kepada Dewan untuk meninjau dan voting.
Tahap Voting
Editorial anggota Dewan ulasan diusulkan calon, mendaftarkan umpan balik mereka dengan suara dan opsional komentar. Orang termasuk MENERIMA, MENGUBAH (menandakan perlunya perubahan kecil), TOLAK, menyusun kembali (menandakan perlunya perubahan besar), PENGKAJIAN (anggota aktif meninjau calon tapi tidak tidak memiliki suara siap), dan noop (tidak ada pendapat). Seorang anggota Dewan dapat MENERIMA atau MENGUBAH calon jika :
telah diakui oleh vendor,
masalah telah direplikasi oleh anggota Dewan suara,
masalah telah dilaporkan atau direplikasi oleh seseorang siapa trust anggota, atau
ada independenkonfirmasi dari pihak lain. MITRE sedang mempertimbangkan apakah sudah
cukup untuk menetapkan kebenaran dari kandidat. Salah satu isu yang belum terselesaikan adalah bagaimana menangani calon "permanen" yang mungkin nyata tetapi tidak pernah menerima penilaian yang positif yang cukup untuk diterima sebagai entri resmi.
Tahap Modifikasi
Tahap Keputusan Sementara
CVE Editor memutuskan bila ditinjau dari calon selesai atau telah terhenti. Editor tunggal dapat menerima atau menolak suara, kemudian memberikan anggota Dewan yang "panggilan terakhir" kesempatan untuk posting akhir komentar atau keberatan (setidaknya empat hari kerja). Jika ada komentar atau keberatan yang luas yang membutuhkan suara tambahan, kandidat dapat kembali ke fase modifikasi.
Akhir Tahap Keputusan
Jika CVE Editor menentukan bahwa tidak ada alasan yang cukup ada untuk mengubah suara dibuat dalam Interim Keputusan, maka keputusan tersebut menjadi final. Jika calon diterima, Editor mengumumkan kepada semua Dewan anggota yang kandidat akan ditempatkan ke CVE, dan
mengidentifikasi nama CVE yang akan ditugaskan ke masukan baru. Jika calon ditolak, Editor mencatat alasan penolakan.
Proses Membangun Daftar CVE: Masuk Tahap: Tahap 3 dari 3
Tahap Publikasi
Jika calon telah diterima, calon diubah nasuk dengan mengubah nama dari CAN-YYYY-NNNN untuk CVE-YYYY-NNNN dan menghapus catatan suara. Entri baru kemudian ditambahkan ke versi berikutnya dari Daftar CVE.
Tahap modifikasi
Masukan mungkin perlu dimodifikasi dengan cara sederhana, misalnya, untuk memperjelas deskripsi atau menambahkan lebih referensi. (Informasi lebih lanjut tentang ini muncul dalam bagian berikut.)
Modifikasi dan Penghapusan dalam Daftar CVE dan Modifikasi Calon
Daftar
Kebanyakan calon dan entri dimodifikasi dengan menambahkan referensi yang lebih (seperti penyedia tambahan nasihat), atau melalui perubahan kecil ke deskripsi (seperti memperbaiki kesalahan ketik dan mengklarifikasi masalah ini). modifikasi calon biasanya tidak secara eksplisit disampaikan kepada Dewan Editorial atau masyarakat, karena jumlah dan frekuensi perubahan yang terjadi. Untuk entri, Dewan Editorial diberitahu tentang modifikasi dasar setidaknya empat bisnis hari sebelum versi CVE baru ditargetkan untuk penciptaan.
Untuk pengguna CVE yang ingin melacak perubahan dalam Daftar CVE, MITRE memberikan "laporan perbedaan versi" yang rinci yang entri telah berubah, dan bagaimana mereka telah berubah, antara dua versi. Karena berbagai alasan, kemampuan ini tidak dibuat tersedia untuk calon, tetapi proyek Cassandra yang dipimpin oleh Purdue CERIAS sekarang menawarkan sebuah laporan monitoring
Beberapa modifikasi mungkin substansial. Sebagai contoh, seorang calon mungkin perlu dipecah menjadi beberapa item, atau beberapa kandidat mungkin perlu digabung menjadi satu item (menyusun kembali). Hal ini akan terjadi jika keputusan konten tidak diterapkan dengan benar ketika calon pertama kali dibuat, atau jika pasukan informasi baru perubahan tersebut. Di beberapa kasus, perombakan mungkin diperlukan untuk masuk. Prosedur untuk membentuk kembali calon dan entri belum telah sepenuhnya didefinisikan, karena sebagian besar dari perubahan ini adalah karena keputusan konten yang belum selesai belum. Namun, setidaknya, prosedur membentuk kembali calon atau entri akan mencakup penggabungan dari beberapa jenis pointer ke depan yang akan pergi dari setiap item perombakan ke "dikoreksi" item.
Dalam kasus lain, deskripsi dan / atau set referensi mungkin cukup jelas bahwa item tersebut bisa muncul untuk menggambarkan lebih dari satu kerentanan yang berbeda. Hal ini terjadi lebih sering pada hari-hari awal CVE ketika utilitas referensi di deconflicting masalah serupa, dan pentingnya memiliki rincian yang diperlukan dalam deskripsi, tidak sepenuhnya dipahami. Deskripsi jelas dan referensi yang hilang dapat menyebabkan pemetaan kesalahan dalam produk dan layanan CVE kompatibel. Advisories keamanan penjual dengan informasi yang tidak jelas ini tantangan khusus: masalah ini mungkin nyata (jika vendor tidak akan melaporkan hal itu), tetapi masalah sudah bisa diidentifikasi dalam item CVE berbeda. Konsultasi dengan vendor dapat menjernihkan ambiguitas, tetapi tidak selalu mungkin atau layak.
Penghapusan
Mungkin ada beberapa alasan mengapa calon atau entri harus "dihapus" dari daftar yang terkait, termasuk:
Jika itu adalah duplikat item CVE lain
Jika analisis lebih lanjut menunjukkan bahwa kerentanan tidak ada (misalnya, laporan asli tidak
benar)
Jika item perlu Disusun kembali
Reservation calon dan Otoritas calon Numbering
Calon reservasi memungkinkan peneliti bertanggung jawab, vendor, dan tim respon insiden menyertakan calon angka dalam pengumuman umum perdana kerentanan. Ini memastikan bahwa sejumlah kandidat langsung tersedia untuk semua pengguna CVE dan membuatnya lebih mudah untuk melacak kerentanan dari waktu ke waktu. Proses dasar adalah:
1. Ada permintaan untuk satu atau lebih calon nomor urut
2. memberikan nomor kepada pemohon dan cadangan jumlah kandidat MITRE, dan menciptakan "Kekosongan," calon bebas konten di situs Web CVE.
3. jumlah pemohon berbagi kandidat dengan semua pihak yang terlibat pengungkapan. 4. jumlah pemohon termasuk kandidat dalam penasehat kerentanan.
5. masyarakat membuat calon Pemohon dan memberitahukan MITRE. 6. situs Web CVE untuk memberikan calon rincian Update di MITRE. 7. MITRE mengusulkan calon kepada Dewan Editorial.
Jika calon yang tersedia dalam masalah ini tidak pernah dipublikasikan, calon akan dihapus. ini disebut sebagai "melepaskan" kandidat. Karena calon tidak pernah terpublik dalam beberapa kasus, calon tidak pernah ditugaskan untuk kerentanan tertentu.
Calon Penomoran Pihak berwenang
Calon Penomoran Pihak berwenang (CNA) adalah organisasi yang mendistribusikan nomor calon CVE ke peneliti dan vendor teknologi informasi untuk dimasukkan dalam pertama kali pengumuman publik baru kerentanan, tanpa melibatkan langsung MITRE dalam rincian kerentanan tertentu. Pada saat dibutuhkan dasar, MITRE menyediakan CNA dengan kolam nomor untuk menetapkan calon CNA.
CNA dapat membantu CVE Initiative dalam beberapa cara. Ketika mereka berfungsi sebagai perantara antara kerentanan peneliti dan vendor yang terkena, mereka dapat memberikan sejumlah kandidat tanpa memberitahukan MITRE dari kerentanan, yang mengurangi risiko pengungkapan disengaja informasi kerentanan. mereka meningkatkan ruang lingkup dan visibilitas calon CVE dengan menyediakan jalur akses tambahan bagi para peneliti dan vendor untuk mendapatkan nomor kandidat. Mereka dapat memanfaatkan hubungan kerja yang ada dengan para peneliti dan vendor, yang pihak yang terkena dampak mungkin tidak terbentuk dengan MITRE. Jika mereka sudah merupakan bagian integral dari normal proses dimana kerentanan diungkapkan, partisipasi mereka mencegah penambahan pihak lain (yaitu, MITRE) dari campur dengan proses yang menyebabkan atau penundaan lebih lanjut. Akhirnya, partisipasi mereka mengurangi MITRE dari beberapa tugas yang berpotensi padat karya, yang memungkinkan untuk mendedikasikan sumber daya untuk aspek-aspek lain dari CVE yang perlu
perhatian.
Persyaratan untuk menjadi CNA
Sebuah CNA harus menjadi vendor perangkat lunak utama dengan basis pengguna yang signifikan dan penasehat keamanan kemampuan didirikan, atau didirikan pihak ketiga yang biasanya bertindak sebagai antarmuka netral antara peneliti dan vendor. MITRE juga berfungsi sebagai CNA dalam kapasitas terbatas.
Tugas CNA
CNA konsisten harus menerapkan didokumentasikannya keputusan konten CVE (dengan pengecualian dibuat untuk kehalusan teknis atau dokumentasi lengkap). Mereka juga harus
mengkoordinasikan pertukaran nomor calon di pihak semua yang terlibat (vendor, peneliti, tim tanggap, dll) untuk mengurangi risiko memproduksi duplikat nomor calon. CNA harus memberitahu MITRE ketika calon telah diumumkan secara terbuka. Karena praktek pengungkapan berdampak langsung terhadap keakuratan CVE, CNA harus merekomendasikan praktik terbaik dalam kerentanan pengungkapan kedua peneliti dan penjual. Sebuah CNA harus memverifikasi bahwa kerentanan dilaporkan belum memiliki kandidat nomor yang telah diberi CVE.
MITRE bekerja untuk meningkatkan jumlah CNA. Beberapa tantangan terbesar termasuk mendidik CNA tentang keputusan konten dan menentukan proses untuk bertukar nomor calon di beberapa pihak, terutama jika cadangan lebih dari satu pihak kandidat dari MITRE.
Komunikasi dari CNA ke MITRE
Seri berikut komunikasi terjadi antara CNA dan MITRE:
1. CNA meminta kolam nomor calon.
2. CNA mengumumkan publikasi calon baru, yang memungkinkan MITRE untuk memperbarui calon Informasi di situs Web CVE.
3. CNA mungkin perlu berkonsultasi dengan MITRE mengenai keputusan konten CVE. 4. CNA memberitahukan MITRE diduga pelanggaran dari proses CVE oleh para peneliti. 5. CNA memberitahukan MITRE dan pihak lain ketika duplikat calon terdeteksi.
Metode utama komunikasi adalah melalui e-mail, meskipun diskusi telepon terkadang diperlukan bila masalah ini sangat kompleks sehubungan dengan keputusan konten CVE atau sifat kerentanan.
pihak ketiga CNA juga harus menjaga kesadaran semua vendor dan CNA yang memanfaatkan nomor calon. Karena pihak ketiga mungkin mendapatkan keuntungan kompetitif dengan awalnya memberikan untuk penonton nomor kandidat terbatas (di luar peneliti dan vendor), CNA tidak harus menerbitkan nomor calon CVE dengan cara yang mungkin dapat memberikan keuntungan ekonomi, teknis, atau politik atas pesaingnya.
Vendor CNA harus jelas mengiklankan titik keamanan mereka dari kontak. Mereka harus memberikan calon untuk pihak lain yang terkena dampak (misalnya, vendor lain, peneliti, atau tim respon). Mereka harus menyertakan calon angka dalam nasihat mereka sendiri. Mereka hanya bisa menggunakan kolam renang mereka calon untuk kerentanan dalam produk mereka sendiri. Mereka harus menerapkan keputusan konten CVE untuk menentukan jumlah yang tepat dari calon untuk menetapkan,
Vendor Penghubung
Seperti yang bisa dilihat oleh persyaratan untuk CNA, sumber daya dapat intensif dan secara teknis sulit untuk bertindak sebagai CNA. Banyak vendor mungkin ingin berpartisipasi dengan baik dalam CVE Initiative tetapi tidak memiliki kemampuan atau keinginan untuk bertindak sebagai CNA. Sebuah penghubung penjual dapat bekerja dengan CNA lain untuk memperoleh atau memverifikasi calon CVE di produk penghubung sendiri, dan termasuk nomor kandidat dalam nasihat-nya.
Tanggung Jawab Peneliti
Peneliti harus memesan calon kerentanan tertentu dari hanya satu CNA. Jika perangkat lunak yang terkena dampak Vendor adalah CNA, maka peneliti harus mendapatkan calon dari vendor. Peneliti perlu memberikan CNA dengan rincian yang cukup untuk CNA untuk menerapkan keputusan konten CVE. Peneliti harus mengkoordinasikan pertukaran jumlah calon di semua pihak yang terlibat. Akhirnya, peneliti harus menyertakan jumlah calon dalam penasehat dan mempublikasikan informasi melalui saluran diandalkan dikenal (vendor atau tim respon), atau saluran umum dikenal dengan peer review (seperti Bugtraq atau NTBugtraq).
Peneliti bisa mempengaruhi proses pemesanan dalam beberapa cara yang berbeda yang dapat mempengaruhi kualitas keseluruhan CVE. Misalnya, proses pengungkapan peneliti mungkin sering mengakibatkan duplikat calon (misalnya dengan menolak untuk bekerja dengan vendor). Peneliti mungkin sering mempublikasikan isu-isu yang ditemukan untuk menjadi palsu atau lebih rawan kesalahan untuk menyebabkan calon terkait untuk ditolak oleh Editorial Dewan. Ini adalah tanggung jawab MITRE dan CNA untuk mengidentifikasi dan mengatasi pelanggaran tersebut.
Keputusan konten
Keputusan konten CVE adalah pedoman yang digunakan untuk memastikan bahwa CVE item dibuat secara konsisten, independen yang melakukan penciptaan. Ada dua jenis utama dari keputusan konten: inklusi dan abstraksi. Keputusan konten inklusi menentukan apakah kerentanan atau paparan harus pergi ke CVE. Keputusan konten abstraksi menentukan tingkat abstraksi (tingkat detail) di mana kerentanan harus dijelaskan (misalnya, apakah masalah keamanan khusus harus diberikan satu calon atau lima kandidat).
BUKTI 70,3 SF-LOC dan SF-EXEC Konten Keputusan
CD: SF-LOC: beberapa kelemahan keamanan yang sama dieksekusi, tapi mungkin dalam baris kode
yang berbeda
CD: SF-EXEC: beberapa executable menunjukkan masalah yang sama
CD: SF-LOC hanya berlaku ketika mungkin ada beberapa bug yang muncul dalam executable yang sama (modulo basis kode, yaitu, semua "ps"
executable di UNIX diperlakukan sama).
CD: SF-EXEC hanya berlaku ketika ada beberapa executable dalam paket yang sama yang
menunjukkan masalah yang sama.
SPLIT (membuat kasus terpisah) antara masalah dari berbagai jenis (misalnya, buffer overflow
dibandingkan masalah symlink).
"Paket yang sama" pada dasarnya berarti "executable paket yang melakukan fungsi terkait
yang tidak didistribusikan secara terpisah. "
SPLIT antara masalah dari jenis yang sama jika Masalah X muncul dalam beberapa versi masalah
Y itu tidak.
Microsoft Word dan PowerPoint tidak dalam paket yang sama (mereka dapat diinstal secara terpisah).
Set program executable yang mendukung kemampuan lpd di UNIX adalah paket yang sama.
Gabung masalah dari jenis yang sama dalam versi yang sama. Secara eksplisit daftar masalah
yang berbeda dalam deskripsi.
SPLIT ketika masalah dari berbagai jenis. SPLIT ketika masalah dalam versi yang berbeda (untuk beberapa definisi "versi" yang secara efektif
menjelaskan paket).
MERGE ketika masalah adalah dari jenis yang sama. secara eksplisit
mengidentifikasi terpisah terpengaruh "komponen" atau executable di
paket.
Data dinormalisasi dapat lebih mudah direplikasi, dan keputusan konten CVE membantu untuk memastikan bahwa data dinormalisasi dengan cara diprediksi.
Dua yang paling umum digunakan keputusan konten (CD) akan ditampilkan di pameran 70,3. Mereka juga menyoroti beberapa perbedaan yang paling umum di seluruh sumber informasi kerentanan. CD ini direvisi berkali-kali selama periode satu tahun setengah, tapi mereka stabil pada awal tahun 2001 ketika mereka memodifikasi untuk membuat kurang sensitifnya kerentanan terhadap jumlah informasi yang tersedia. Dari seorang akademisi perspektif, pendekatan ini tidak optimal tetapi ini membuktikan menjadi berulang dan kurang cenderung menyebabkan calon menjadi split atau bergabung ketika informasi baru menjadi tersedia setelah analisis awal telah dilakukan.
CD: SF-LOC kurang sensitif terhadap kurangnya informasi rinci seperti kode sumber, eksploitasi, atau serangan jejak. Namun, masih sensitif terhadap perubahan versi informasi. Masalah yang terjadi di perpustakaan menimbulkan tantangan khusus untuk keputusan konten ini karena mereka bisa dipamerkan di beberapa titik dalam executable yang sama, atau dalam banyak executables yang berbeda. Pada akhirnya, sementara CD ini dimaksudkan untuk meminimalkan jumlah informasi diperlukan untuk memproduksi hasil, itu masih tergantung pada sumber informasi penting seperti vendor produk rentan.
Dewan Editorial CVE
Dewan Redaksi CVE termasuk spesialis keamanan informasi terkemuka dari berbagai informasi organisasi keamanan terkait di seluruh dunia, termasuk vendor keamanan-alat komersial, akademik dan lembaga penelitian, dan lembaga pemerintah. MITRE mengundang pakar keamanan informasi lain untuk berpartisipasi pada dasar yang dibutuhkan, berdasarkan rekomendasi dari anggota Dewan lain atau identifikasi MITRE sendiri kesenjangan dalam representasi saat ini. Arsip pertemuan Dewan dan diskusi yang tersedia untuk umum di situs Web CVE.
Anggota Dewan Editorial memiliki peran yang berbeda dan tugas dalam mendukung CVE Initiative. Ada empat peran: anggota Teknis, penghubung, advokat, dan anggota emeritus. Setiap anggota Dewan memiliki satu Peran utama tetapi dapat mengambil peran lain. Anggota teknis berpartisipasi dalam penciptaan, desain, review, pemeliharaan, dan aplikasi dari Daftar CVE. Liaisons mewakili konstituen yang signifikan, terkait dengan atau dipengaruhi oleh CVE, di daerah yang tidak selalu memiliki
perwakilan teknis di Dewan. Dalam beberapa kasus, penghubung dapat mewakili suatu organisasi, yang mungkin termasuk vendor perangkat lunak. Advokat aktif mendukung atau mempromosikan CVE dalam mode sangat terlihat. Peran ini disediakan bagi para pemimpin dihormati dalam keamanan masyarakat yang membantu membawa kredibilitas Initiative CVE dan memberikan CVE jangkauan yang lebih luas di luar keamanan masyarakat. Anggota emeritus yang sebelumnya aktif dan berpengaruh dalam Initiative CVE dan diakui untuk kontribusi signifikan mereka.
Anggota dewan harus memenuhi tingkat minimum usaha untuk tugas-tugas yang mereka lakukan, yang bervariasi . Jika anggota Dewan berpartisipasi dalam banyak tugas, maka sesuai harapan minimum untuk setiap individu Tugas dapat diturunkan. Semua anggota melakukan konsultasi dan kesadaran tugas. Konsultasi termasuk berpartisipasi dalam pertemuan Dewan, atau diskusi tentang isu-isu ad hoc terkait dengan konten CVE atau proses Dewan Redaksi seperti konten keputusan, keanggotaan Dewan, atau kompatibilitas CVE. Kesadaran termasuk berpartisipasi dalam pertemuan Dewan atau membaca ringkasan pertemuan, dan secara teratur membaca posting di milis Editorial Dewan.
Banyak anggota juga melakukan penjangkauan dengan aktif mempromosikan CVE dan mendidik masyarakat tentang hal itu, atau memperkenalkan berbagai kontak ke CVE Initiative. Kadang-kadang, beberapa anggota Dewan berpartisipasi dalam kegiatan yang dilakukan dalam konteks Dewan, tetapi tidak secara langsung berhubungan dengan CVE.
Anggota teknis secara teratur melakukan salah satu atau lebih dari tugas-tugas berikut:
Voting.Tugas utama bagi sebagian besar anggota teknis adalah untuk meninjau, mengomentari, dan suara pada CVE calon yang diusulkan kepada Dewan Editorial. Beberapa anggota memilih secara teratur. Lainnya memilih pada ad hoc dasar (misalnya, ketika ada upaya untuk mencapai tujuan konten tertentu).
Penyedia konten. Beberapa anggota Dewan memberikan database kerentanan mereka terhadap MITRE untuk konversi menjadi calon, yang menjamin bahwa konten CVE selengkap mungkin. Lainnya secara aktif terlibat di calon reservasi. Lainnya mungkin CNA, yang berwenang untuk menetapkan nomor calon CVE untuk masalah keamanan sebelum mereka dipublikasikan.
CIEL. Anggota berpartisipasi dalam review dan pengembangan Common Intrusion Daftar Event
Liaisons melakukan satu atau lebih dari tugas-tugas berikut:
Pendidikan masyarakat. Penghubung harus mendidik masyarakat tentang CVE.
Pendidikan. Penghubung harus mendidik Dewan Editorial tentang kebutuhan dan kepentingan untuk CVE.
Voting. Jika anggota adalah penghubung vendor perangkat lunak, anggota harus memilih pada
calon yang terkait dengan produk vendor.
Liaisons dapat melakukan tugas-tugas teknis lainnya.
Sebuah penghubung yang mewakili konstituen di luar suatu organisasi harus terlihat dan aktif dalam masyarakat konstituen penghubung . Sebuah penghubung yang mewakili suatu organisasi harus mampu secara efektif berkomunikasi dengan bagian-bagian yang relevan dari organisasi itu. Penghubung vendor perangkat lunak harus mampu efektif berkomunikasi dengan keamanan dan pengembangan produk tim vendor.
Tugas Advokat termasuk mendukung CVE untuk konstituen yang akan mendapatkan keuntungan, membina komunikasi yang lebih baik antara konstituen, berpartisipasi dalam kegiatan Dewan Editorial (terutama dalam keputusan yang berkaitan dengan Struktur dewan dan kegiatan strategis), dan konsultasi bila diperlukan.
Membimbing Arah CVE: Dewan Penasihat Senior CVE
CVE Senior Advisory Council didirikan untuk memastikan bahwa CVE Initiative menerima sponsor - Termasuk pendanaan dan bimbingan - dibutuhkan untuk memaksimalkan efektivitas CVE dalam mendukung pemerintah upaya untuk meningkatkan kemampuan bangsa untuk mengidentifikasi dan menanggapi kerentanan dan jaminan informasi serangan atau masalah. CVE Senior Dewan Penasehat terdiri dari eksekutif senior di Pemerintah AS lembaga, banyak yang memberikan (atau disediakan) dana untuk CVE.
Dewan memberikan perencanaan bisnis pengawasan dan prioritas CVE baru dan layanan terkait, membahas CVE dan implikasi kebijakan keamanan terkait untuk pemerintah federal, dan
mengidentifikasi bahan dan sumber yang mungkin berguna bagi CIO pemerintah dan manajer senior.
Dewan mempromosikan adopsi CVE pada tingkat strategis; bekerja untuk menjamin pendanaan untuk inti CVE kegiatan dalam jangka panjang, termasuk penjangkauan ke organisasi pemerintah dan lembaga; dan bertindak sebagai katalis untuk CVE dan kegiatan yang terkait. Dewan juga membawa ke CVE wawasan pada kebutuhan masyarakat dan daerah yang mungkin baru untuk layanan-CVE terkait.
Keanggotaan dewan diperluas ke eksekutif senior dari organisasi-organisasi pemerintah yang
Kerentanan database Scanner SoftwareVendor
Alerts IDS Signature database
Nasihat keamanan dan E-Email
kerentanan Situs Web dan
database
Software vendor patch dan update
BUKTI 70,4 Silang melalui Daftar CVE.
Salah satu peran utama Dewan adalah untuk memberikan bimbingan strategis untuk arah CVE. Sebagai contoh, Dewan telah mendorong MITRE melibatkan berbagai Berbagi Informasi dan Analisis Pusat (ISACs) lebih dekat di CVE, melakukan penjangkauan ke organisasi-organisasi besar di luar industri keamanan, mendefinisikan tujuan kualitatif, dan lebih berkonsentrasi pada menangani kebutuhan segmen IDS dari industri keamanan-alat dengan sehubungan dengan CVE.
Kompatibilitas CVE
Premis dasar dari Daftar CVE adalah bahwa ada satu nama untuk kerentanan atau paparan. Sebuah CVE-kompatibel produk atau jasa harus memahami nama-nama CVE untuk kerentanan dan memungkinkan pengguna untuk berinteraksi dengan produk atau jasa dalam hal nama-nama CVE. Ini tidak berarti bahwa produk atau jasa hanya menggunakan Nama CVE untuk kerentanan, melainkan bahwa selain label asli sendiri untuk kerentanan, menyadari dari nama CVE untuk kerentanan itu. Dukungan ini untuk nama CVE adalah pusat konsep CVE kompatibilitas. Alat CVE-kompatibel, situs Web, database, atau layanan harus menggunakan nama CVE dengan cara yang memungkinkan pengguna untuk menghubungkan informasi dengan repositori lainnya, peralatan, dan jasa yang juga menggunakan nama CVE, seperti yang ditunjukkan pada bukti 70,4.
Penggunaan Kompatibilitas CVE
Mengintegrasikan layanan kerentanan, database, situs Web, dan alat-alat yang menggabungkan nama CVE akan memberikan organisasi dengan cakupan yang lebih lengkap dan efisien dari masalah
Hal ini juga memungkinkan untuk menentukan dengan tepat kerentanan dan eksposur ditutupi oleh masing-masing CVE compatible alat atau layanan karena Daftar CVE memberikan dasar untuk perbandingan. Setelah menentukan dari CVE entri berlaku untuk platform, sistem operasi, dan paket perangkat lunak komersial, sebuah organisasi dapat membandingkan bagian ini dari Daftar CVE untuk cakupan alat tertentu atau layanan.
Jaringan dan perdagangan keamanan jurnal sudah mengacu CVE nama dukungan sebagai fitur yang diinginkan di review produk dan perbandingan scanner dan perangkat IDS. Demikian pula, Institut Nasional untuk Ilmu dan Teknologi (NIST) telah menerbitkan rekomendasi untuk semua lembaga dan layanan pemerintah federal untuk penggunaan produk dan jasa bila memungkinkan CVE-kompatibel; dan pada bulan Februari 2003, Departemen Pertahanan mengeluarkan Directive 8.500,2, Informasi Assurance (IA) Instruksi Implementasi, yang menyatakan bahwa, "Untuk meningkatkan interoperabilitas, preferensi diberikan kepada alat yang mengungkapkan kerentanan dalam kerentanan umum
dan Eksposur (CVE) konvensi penamaan. "
Sama seperti jenis lain dari produk keamanan informasi cenderung berfokus pada fungsi inti tertentu atau kemampuan, Platform, atau jenis masalah, berbagai produk, layanan, dan repositori yang berusaha untuk memenuhi CVE yang persyaratan kompatibilitas akan fokus pada bagian yang berbeda dari Daftar CVE. Sebagai contoh, beberapa kesepakatan dengan UNIX sementara yang lain fokus pada Windows NT; dan beberapa fokus pada kerentanan berbasis jaringan atau berbasis host. Pengguna harus
mengevaluasi item CVE-kompatibel terhadap kebutuhan spesifik organisasi mereka dalam hal platform dan cakupan produk perangkat lunak.
Persyaratan Kompatibilitas CVE
Pada intinya, kompatibilitas CVE melibatkan empat persyaratan dasar:
1. Pelanggan dapat menggunakan nama CVE untuk menanyakan tentang ruang lingkup, konten, atau cakupan, dan kemudian menerima informasi terkait apapun.
2. Pelanggan dapat memperoleh output yang mencakup semua nama CVE terkait.
3. Pemilik item membuat upaya yang baik untuk memastikan bahwa pemetaan item dari unsur-unsur sendiri untuk nama CVE tetap seakurat Daftar CVE dan bahwa item kompatibel diperbarui dari waktu ke waktu.
4. Dokumentasi standar termasuk deskripsi kompatibilitas CVE dan rincian tentang bagaimana pelanggan dapat menggunakan-CVE terkait fungsi alat mereka, database, situs Web, atau layanan.
Secara umum, vendor diberikan fleksibilitas untuk menerapkan persyaratan dalam berbagai cara. Pengguna kemudian dapat menentukan fitur atau implementasi yang paling cocok dengan kebutuhan mereka.
Proses Evaluasi Kompatibilitas CVE
Pendekatan MITRE untuk mendirikan kompatibilitas produk atau jasa melibatkan dua tahap.
Web situs. tahap proses kompatibilitas telah berlaku sejak Oktober 1999, ketika CVE mulai Initiative, dan dapat dilakukan dengan sangat cepat. Itu membuat vendor menyadari harapan tingkat tinggi untuk CVE kompatibilitas dan menetapkan saluran komunikasi yang tepat antara MITRE dan organisasi.
Ketika organisasi percaya bahwa produk atau jasa telah memperoleh kepatuhan penuh dengan CVE persyaratan kompatibilitas, maka dapat meminta peninjauan formal dan evaluasi, yang dimulai tahap kedua. Dalam perkembangannya selama setahun terakhir, proses formal ini memiliki "program branding" dan logo untuk menunjukkan sukses penyelesaian evaluasi kompatibilitas. Komponen utama dari fase ini membutuhkan rincian spesifik tentang bagaimana sebuah organisasi wajib telah memenuhi setiap persyaratan kompatibilitas CVE. Organisasi harus menyelesaikan diperpanjang "Persyaratan Kompatibilitas CVE Formulir Evaluasi," yang memerlukan tanda tangan dari perwakilan resmi dari organisasi yang mengajukan. Selain itu, organisasi menyediakan MITRE dengan dokumentasi user-CVE terkait untuk produk atau jasa.
Pernyataan dan dokumen organisasi dievaluasi, dan MITRE mengatur untuk memverifikasi keakuratan pemetaan antara nama-nama CVE dan penyimpanan data yang mendasari organisasi. Setelah
menyelesaikan review, formulir evaluasi rinci organisasi dan pernyataan mendukung akan diposting di Web CVE situs untuk digunakan meninjau publik, bersama dengan persetujuan MITRE dengan
pernyataan organisasi. MITRE kemudian menyediakan organisasi dengan khusus logo CVE-kompatibel dan secara resmi memberikan organisasi izin untuk menggunakan logo CVE-kompatibel dan istilah "CVE-kompatibel."
MITRE mulai melakukan pengujian internal untuk tahap kedua dari proses penilaian kompatibilitas CVE pada bulan Februari 2002. "beta test" kemudian dilakukan dengan sejumlah organisasi kecil di jangka waktu Apr-Sep, diikuti dengan roll-out publik pada tanggal 7 Mei 2003.
Pertumbuhan Produk dan Layanan CVE-Kompatibel
Daftar organisasi menyatakan produk dan jasa CVE-kompatibel terus berkembang dan dalam lingkup internasional. Pada pertengahan Mei 2003, 84 organisasi telah membuat deklarasi kompatibilitas. Untuk sebuah Daftar saat ini, kunjungi situs Web CVE (http://cve.mitre.org/compatible/).
Jumlah produk dan jasa yang bekerja menuju kompatibilitas CVE telah tumbuh secara signifikan lembur. Pada bulan Oktober 1999, 15 produk dimaksudkan untuk menjadi CVE-kompatibel; enam bulan
kemudian, jumlahnya telah dua kali lipat menjadi 30, dan melebihi 50 pada bulan Juli 2001. Setelah peningkatan aktivitas dalam beberapa bulan terakhir, ada 126 produk atau jasa dalam perjalanan ke CVE kompatibilitas pada pertengahan Mei 2003; 56 organisasi lain yang bekerja pada deklarasi untuk 121 produk atau layanan tambahan.
Tantangan dan Peluang
Tantangan dalam Skema Penamaan
Skema penamaan saat ini memungkinkan manusia dengan mudah membedakan antara calon CVE dan entri (CANYYYY- NNNN vs CVE-YYYY-NNNN). Perbedaan ini dipilih di awal CVE Initiative, sebagian didasarkan pada bagaimana nama ditangani di bidang lain. Namun, nama-nama CVE biasanya tidak dianggap atom dalam operasi pengolahan data, dan dengan demikian mereka tidak dapat ditemukan dengan mudah oleh mekanisme pencarian. Juga, berbeda kandidat dan CVE skema penomoran menyebabkan pemeliharaan dan masalah pencarian.
Mesin pencarian dapat memisahkan nama menjadi tiga istilah yang berbeda (CAN, YYYY, NNNN) karena tanda hubung kadang-kadang dianggap sebagai pemisah kata, yang dapat membuat sulit untuk dengan mudah menemukan informasi di Internet menggunakan nama CVE. Dalam kasus lain, mesin pencari mungkin perlu dimodifikasi untuk mengutip bagian dari tanda hubung Nama CVE. Akhirnya, pengkodean tahun dalam nama dapat menyebabkan beberapa masalah dengan penyalahgunaan, seperti halnya belum tentu mencerminkan tahun di mana kerentanan pertama kali dipublikasikan. Selain itu, nomor urut dalam nama mungkin merupakan kebocoran informasi kecil jika sejumlah kandidat dicadangkan untuk masalah lama sebelum masalah ini diketahui publik.
Perbedaan antara nama calon dan nama entri CVE bisa sulit untuk dikelola. Sebagai contoh, ketika seorang calon menjadi entri resmi, semua vendor CVE-kompatibel perlu memperbarui database mereka untuk mengkonversi jumlah calon nomor CVE. Selain itu, pengguna mungkin masih mencari jumlah calon bukan jumlah CVE; dan beberapa produk CVE-kompatibel atau layanan mungkin tidak menemukan entri CVE terkait jika pengguna menggunakan jumlah kandidat dalam pencarian. Menghindari masalah ini, setiap produk CVE-kompatibel atau layanan akan perlu untuk mengimplementasikan fungsi khusus. Beberapa bisa menghilangkan CVE- prefiks langsung, tapi ini mencegah pengguna mengetahui apakah item tersebut adalah calon atau entri. Situs Web CVE menangani perbedaan ini fleksibel, tetapi
membutuhkan kode khusus. Banyak alat CVE-kompatibel yang tidak fleksibel, dan kemampuan seperti itu tidak diperlukan karena kompatibilitas CVE tidak memerlukan penggunaan kandidat.
Lingkup Daftar CVE
Ruang lingkup Daftar CVE telah dibahas dan diperdebatkan berkali-kali selama evolusi CVE. Diskusi umumnya difokuskan pada dua pertanyaan:
1. Apa jenis masalah keamanan yang termasuk dalam daftar?
2. Apa jenis informasi yang disertakan pada setiap masalah, dan apa format informasi CVE?
Kerentanan dan eksposur dalam perangkat lunak beta (CD: EX-BETA). Jenis kerentanan
diharapkan dilaporkan cukup sering, tapi kadang-kadang berpendapat bahwa perangkat lunak beta. Secara umum, seperti kerentanan dikecualikan dari CVE, dengan pengecualian berikut: (1) jika perangkat lunak di seluruh distribusi, atau (2) jika perangkat lunak secara konsisten dirilis dalam versi beta bukan versi akhir (misalnya, program ICQ).
Kerentanan dan eksposur layanan online seperti layanan surat berbasis web gratis, online
banking, dan E-commerce, dll (CD: EX-ONLINE-SVC). Masalah tersebut biasanya ditangani dengan memperbaiki server tunggal, oleh penyedia layanan, dan tidak memerlukan tindakan apapun oleh pelanggan.
Masalah dalam klien jaringan yang menyebabkan layanan yang cakupannya terbatas pada klien,
yang dapat diatasi dengan me-restart klien, dan yang hanya dapat dimanfaatkan oleh serangan pasif (CD: EXCLIENT- DOS). Sebagai contoh, jika browser Web tidak bisa menangani urutan karakter tertentu, tetapi Masalah hanya dapat dipicu oleh menarik pengguna untuk
mengunjungi situs Web tertentu dan hanya menyebabkan klien kecelakaan, maka masalah tidak akan ditambahkan ke CVE.
Kode berbahaya seperti virus, worm, dan Trojan horse (kategori ini tidak termasuk backdoors
yang sengaja dimasukkan oleh pengembang). Secara teknis, kehadiran memenuhi perangkat lunak tersebut berbahaya Definisi CVE tentang kerentanan. Namun, mencoba untuk
mengidentifikasi dan katalog semua kode berbahaya akan memperluas ukuran signifikan CVE, sehingga tidak dapat digunakan banyak orang. Selain itu, diyakini yang mendefinisikan nama standar untuk malware sebaiknya diserahkan kepada anti virus.
Isu yang terkait dengan pelanggaran kebijakan keamanan. Kebijakan seperti panjang password
minimum dan password kadaluarsa, disetujui jasa, dan kesesuaian dengan versi software tertentu berbeda-beda di masing-masing perusahaan, sehingga sulit untuk membuat item CVE yang mencoba untuk menangkap kebijakan tersebut. Konfigurasi tidak aman sering jatuh dalam bagiani ini.
Isu belum tentu terbukti "dieksploitasi. "Sebagai contoh, banyak vendor Linux merilis konsultan
untuk masalah yang mungkin memiliki implikasi keamanan, bahkan jika mengeksploitasi tidak diketahui keberadaannya. Hal ini sering terjadi dengan buffer overflows, kerentanan format string, dan kesalahan signedness.
Mengatasi Kebutuhan IDS Tools dengan CIEL
Banyak kejadian yang terdeteksi oleh IDS tidak memiliki hubungan yang jelas dengan kerentanan atau eksposur, termasuk pemetaan port, decode protokol, gagal memeriksa integritas biner, dan tanda tangan serangan generik. Untuk kasus di mana sebuah acara tumpang tindih CVE (misalnya, upaya untuk mengeksploitasi kerentanan tertentu), deskripsi CVE fokus pada sifat dari masalah keamanan sebagai lawan bagaimana mungkin dimanfaatkan. Sejumlah Editorial Anggota dewan dan orang lain yang terlibat dalam pekerjaan IDS telah menyatakan keinginan untuk memiliki CVE mencakup semua peristiwa IDS.
MITRE sedang membangun sebuah daftar rancangan untuk kegiatan IDS, disebut sebagai CIEL (Common Intrusion Daftar Event, disebut "segel"), yang kadang-kadang informal digambarkan sebagai "CVE untuk deteksi intrusi." Hal ini dimaksudkan untuk menyediakan skema penamaan untuk semua acara jaringan atau berbasis host yang mungkin berguna dalam mendeteksi penyusup kegiatan, tetapi tidak secara langsung berhubungan dengan item CVE. MITRE memantau upaya IETF Intrusion Kelompok Kerja Detection (IDWG) untuk mengidentifikasi daerah-daerah tumpang tindih dengan CIEL. The IDWG adalah menangani lebih besar kebutuhan untuk pertukaran informasi di IDSes, tapi CIEL dapat digunakan untuk memenuhi kebutuhan IDWG untuk nama serangan umum.
Beberapa asumsi akan membimbing pengembangan CIEL: ada lebih banyak jenis kegiatan IDS dari kerentanan, ada lebih banyak variasi di IDS dalam tingkat abstraksi (atau tingkat detail) daripada ada di scanner kerentanan dan database, dan tidak banyak yang terdefinisi dengan baik dan terminologi umum diterima di area IDS.
Pada awal tahun 2002, Mitre menciptakan kelompok kerja CIEL bawah Dewan CVE Editorial. Diskusi diadakan pada milis terpisah. Pada tulisan ini, MITRE masih mengembangkan Dewan Editorial untuk menyertakan lainnya anggota kelompok kerja CIEL.
Mengelola Risiko dengan Kompatibilitas CVE
Peningkatan produk dan layanan CVE-kompatibel dapat mengubah cara organisasi menggunakan alat-alat keamanan dan sumber data untuk mengatasi postur keamanan operasional mereka. Sebagai contoh, sebuah organisasi dapat menggunakan CVEcompatible produk dan jasa untuk meningkatkan respon terhadap saran keamanan. Nasihat CVE-kompatibel termasuk entri yang dapat memeriksa kerentanan CVE scanner, dan IDS dapat diperiksa sesuai tanda tangan serangan untuk kerentanan yang dijelaskan dalam penasehat. Penggabungan nama CVE dan CVEcompatible produk dan jasa memberikan proses yang lebih terstruktur dan dapat diprediksi untuk penanganan nasihat daripada kebanyakan organisasi.
keamanan Internet yang paling umum-kritis dan termasuk 125 nama CVE. Terbaru top-20 daftar sekarang termasuk 242 nama CVE.
Selain itu, seperti yang ditunjukkan pada Exhibit 70,5, produk dan jasa yang kompatibel dapat digunakan oleh suatu organisasi untuk memeriksa serangan berkelanjutan dengan sistem IDS CVE-kompatibel-nya. Dalam IDS CVE-kompatibel, kerentanan spesifik yang rentan terhadap serangan terdeteksi disediakan sebagai bagian dari laporan serangan. Informasi In dapat dibandingkan terhadap kerentanan
pemindaian terbaru oleh scanner CVE-kompatibel untuk menentukan apakah perusahaan memiliki salah satu kerentanan atau eksposur yang dapat dimanfaatkan oleh serangan itu. Jika tidak, database CVE-kompatibel memperbaiki pada vendor produk perangkat lunak atau situs Web kerentanan dapat mengidentifikasi lokasi untuk memperbaiki entri CVE,jika ada.
Selain itu, untuk membangun atau mempertahankan pelanggan sistem suatu organisasi, nasihat CVE-kompatibel dan pengumuman dapat membantu secara langsung mengidentifikasi kebutuhan untuk perbaikan software dari vendor komersial sistem tersebut. Untuk masalah keamanan di perangkat lunak yang didistribusikan oleh beberapa vendor, nama CVE dapat membantu pengguna menentukan kapan konsultasi yang berbeda mengacu pada kerentanan yang sama.
Ringkasan Kemajuan
Berikut adalah salah satu cara untuk melihat kemajuan terhadap strategi CVE:
CVE secara bertahap mendekati tujuan unik penamaan dikenal publik keamanan yang relevan
kesalahan perangkat lunak. Lebih dari setengah dari semua kesalahan perangkat lunak yang dikenal sekarang baik disertakan pada CVE yang Daftar atau berada di bawah ulasan.
Nama CVE sekarang secara teratur termasuk oleh kelompok yang cukup besar dari organisasi,
termasuk ISS, IBM, Rain Forest Puppy, @ Stake, Microsoft, BindView, NAI, CERT / CC, SGI, eEye, COMPAQ, Ernst & Young, CISCO, cepat 7, NSFOCUS, Sanctum, Alcatel, EnGarde Aman Linux, Caldera, Red Hat, SecurityFocus, VIGILANTe.com, Cert-IST, Mandrake Linux, Debian, Foundstone, Apple, iDefense, HP, Symantec, DHS / NIPC, KDE e. V., Beyond Keamanan Ltd, Digital Defense Inc., Core-ST, The Open- PKG Proyek, Corsaire, The FreeBSD Project, dan Gentoo Linux.
Penggunaan CVE dalam produk dan layanan keamanan informasi sekarang berdiri di lebih dari
240 yang tersedia atau dalam pembangunan, dengan lebih yang diumumkan secara berkala.
Penggunaan CVE telah dimasukkan dalam rekomendasi terbaru dari Departemen Pertahanan AS,
yang mengikuti rekomendasi sebelumnya dari National Institut Sains dan Teknologi (NIST).
Berbagai jurnal perdagangan sudah mulai menggunakan dukungan untuk nama CVE sebagai review item dalam artikel.
Selama tiga tahun berturut-turut, bimbingan SANS Sepuluh / Top Twenty (sekarang ikut
dikeluarkan oleh Federal Bureau Investigasi [FBI] sudah termasuk nama CVE.
CVE E-newsletter berlangganan oleh lebih dari 4000 organisasi yang berbeda dari lebih dari 90 negara di seluruh dunia, dan situs Web CVE sedang dikunjungi dari individu di lebih dari 125 negara secara teratur.
Dari selusin perusahaan telah dibahas dengan beberapa mempertimbangkan untuk
menambahkan dukungan nama CVE situs fix-it dan mekanisme pembaruan.
Pengakuan
Peran dan tanggung Jawab Informasi Sistem Security Officer
Carl Burney, CISSP
Informasi merupakan aset utama suatu organisasi. Seperti halnya aset utama, kerugiannya dapat memiliki dampak negatif pada keunggulan kompetitif organisasi di pasar, kehilangan pangsa pasar, dan menjadi potensi kewajiban kepada pemegang saham atau mitra bisnis. Informasi penting melindungi aset organisasi lain, seperti aset tanaman (yaitu, peralatan dan struktur fisik) dan aset tidak berwujud (misalnya, hak cipta atau kekayaan intelektual). petugas keamanan sistem informasi (ISSO) yang menetapkan program keamanan informasi untuk membantu menjamin perlindungan informasi organisasi.
Petugas keamanan sistem informasi adalah titik fokus utama untuk semua hal yang melibatkan keamanan informasi. Dengan demikian, ISSO akan:
1. Membangun program keamanan informasi termasuk: Rencana keamanan informasi, kebijakan, standar, pedoman, dan pelatihan.
2. Menyarankan manajemen pada semua masalah keamanan informasi.
3. Memberikan saran dan bantuan pada semua hal yang melibatkan keamanan informasi.
Peran Sistem Informasi Security Officer
Ada banyak peran keamanan yang berbeda dalam suatu organisasi selain keamanan sistem informasi petugas, seperti:
1. spesialis Jaringan keamanan 2. spesialis keamanan database 3. spesialis keamanan internet 4. spesialis keamanan e-bisnis
5. Spesialis infrastruktur pedoman publik 6. Spesialis forensic
7. manajer risiko
Masing-masing peran ini adalah di daerah yang khusus dari area keamanan informasi dan memiliki tanggung jawab tertentu tetapi terbatas. Namun, peran ISSO untuk bertanggung jawab atas keamanan informasi seluruh upaya dalam organisasi. Dengan demikian, ISSO memiliki banyak tanggung jawab yang luas, melintasi semua lini organisasi, untuk memastikan perlindungan informasi organisasi.
Policies, Standards, Guidelines, and Rules Laporan Akses kontrol manajemen risiko
Audit dan review software Keamanan / hardware
Pengujian manajemen konfigurasi
perencanaan kontingensi Pelatihan
hak cipta Sistem akuisisi
Insiden respon System pengembangan
Personil keamanan Sertifikasi / akreditasi
Keamanan fisik pengecualian
Tanggung Jawab Sistem Informasi Security Officer
Sebagai individu dengan tanggung jawab utama untuk keamanan informasi dalam organisasi, ISSO akan berinteraksi dengan anggota lain dari organisasi dalam segala hal yang melibatkan keamanan informasi, meliputi:
1. Mengembangkan, melaksanakan, dan mengelola program keamanan informasi. 2. Pastikan bahwa ada sumber daya yang memadai untuk menerapkan dan memelihara
informasi biaya-efektif program keamanan.
3. Bekerja sama dengan departemen yang berbeda pada masalah keamanan informasi, seperti: - Departemen keamanan akses fisik, insiden keamanan, pelanggaran keamanan, dll - Personil departemen pada pemeriksaan latar belakang, terminasi karena pelanggaran
keamanan, dll
- Departemen audit laporan audit yang melibatkan keamanan informasi dan korektif apapun yang dihasilkan
tindakan
4. Memberikan saran dan bantuan mengenai keamanan informasi sensitif dan pengolahan informasi tersebut.
5. Memberikan saran dan bantuan kepada kelompok usaha untuk memastikan bahwa keamanan informasi awal ditujukan dalam semua proyek dan program.
6. Membangun keamanan informasi komite koordinasi untuk mengatasi masalah organisasi yang luas yang melibatkan informasi masalah keamanan dan kekhawatiran.
7. menyediakan anggota komite penasihat teknis.
8. Mengonsultasikan dengan menyarankan manajemen senior pada semua insiden yang berhubungan dengan keamanan informasi utama atau pelanggaran.
9. Menyediakan manajemen senior negara dengan laporan tahunan keamanan informasi.
Kebijakan, Standar, Pedoman, dan Aturan
Mengembangkan dan mengeluarkan kebijakan keamanan, standar, pedoman, dan aturan. Memastikan bahwa kebijakan keamanan, standar, pedoman, dan aturan tepat melindungi
semua informasi yang dikumpulkan, diproses, dikirimkan, disimpan, atau disebarluaskan.
Ulasan (dan merevisi jika perlu) keamanan kebijakan, standar, pedoman, dan aturan secara periodik.
menenentukan konsekuensi atas pelanggaran kebijakan yang ditetapkan, standar, pedoman, dan
aturan.
Memastikan bahwa semua kontrak dengan vendor, kontraktor, dll termasuk klausul bahwa
vendor atau kontraktor harus mematuhi kebijakan organisasi keamanan, standar, pedoman, dan aturan, dan bertanggung jawab atas kerugian akibat melanggar kebijakan, standar, pedoman, dan aturan.
Kontrol Akses
Memastikan bahwa akses ke semua sistem informasi terkendali.
Memastikan bahwa akses kontrol untuk setiap sistem informasi yang sepadan dengan tingkat
resiko, ditentukan oleh penilaian risiko.
Memastikan akses kontrol menutupi akses dari pekerja rumah, akses dial-in, koneksi dari Internet, dan akses publik.
Memastikan bahwa kontrol akses tambahan ditambahkan untuk sistem informasi yang
memungkinkan akses publik.
Audit Dan Ulasan
Membangun program untuk melakukan tinjauan periodik dan evaluasi dari kontrol keamanan di
setiap sistem, baik secara berkala dan ketika sistem mengalami modifikasi signifikan.
Pastikan Audit log periodik dan semua catatan audit diarsipkan untuk referensi di masa mendatang.
Bekerja sama dengan tim audit dalam melibatkan sistem informasi.
Memastikan sejauh mana audit dan ulasan yang melibatkan sistem informasi dengan tingkat
risiko yang sepadan, ditentukan oleh penilaian risiko.
Manajemen konfigurasi
Memonitor catatan manajemen konfigurasi untuk memastikan bahwa menerapkan perubahan
tidak kompromi atau menurunkan keamanan dan tidak melanggar kebijakan keamanan yang ada.
Perencanaan kontingensi
Pastikan bahwa rencana darurat dikembangkan, dipertahankan dalam status up-to-date, dan diuji setidaknya per tahun.
Pastikan bahwa rencana kontinjensi menyediakan layanan cukup untuk memenuhi kebutuhan
minimal pengguna sistem dan menyediakan kontinuitas yang memadai operasi.
Memastikan bahwa informasi yang didukung dan disimpan off-site.
Hak Cipta
Menetapkan kebijakan terhadap duplikasi ilegal hak cipta perangkat lunak.
Memastikan persediaan dipertahankan untuk perangkat lunak resmi masing-masing sistem informasi / hukum.
Memastikan bahwa semua sistem secara berkala diaudit untuk perangkat lunak ilegal.
Respon Insiden
Menetapkan titik pusat kontak untuk semua insiden atau pelanggaran yang berhubungan
dengan keamanan informasi.
Menyebarluaskan informasi tentang kerentanan dan ancaman umum.
Membangun dan menyebarkan titik kontak untuk melaporkan insiden yang berhubungan
dengan keamanan informasi atau pelanggaran.
Menanggapi dan menyelidiki semua insiden atau pelanggaran yang berhubungan dengan
keamanan informasi, memelihara catatan, dan menyiapkan laporan.
Melaporkan semua insiden yang berhubungan dengan keamanan informasi utama atau pelanggaran kepada manajemen senior.
Memberitahu dan bekerja sama dengan departemen hukum ketika diduga insiden melibatkan
kriminal atau kegiatan penipuan.
Memastikan pedoman disediakan untuk orang-orang yang diduga melakukan insiden melibatkan kriminal atau kegiatan penipuan, meliputi:
- Pengumpulan dan identifikasi bukti - Lacak balak bukti
- bukti Penyimpanan
Menerapkan kebijakan keamanan personil yang mencakup semua individu dengan akses ke
sistem informasi atau memiliki akses ke data dari sistem tersebut. Jelas menggambarkan tanggung jawab dan harapan untuk semua individu.
Memastikan semua sistem informasi kepegawaian dan pengguna memiliki izin keamanan yang
tepat, otorisasi, dan kebutuhan-untuk-tahu, jika diperlukan.
Memastikan setiap sistem informasi memiliki seorang yang mempunyai pengetahuan tentang
keamanan informasi, ditugaskan tanggung jawab untuk keamanan sistem itu.
Pastikan semua proses penting menggunakan pemisahan tugas untuk memastikan satu orang tidak bisa menumbangkan kritis proses.
Melaksanakan rotasi pekerjaan periodik untuk posisi yang dipilih untuk memastikan bahwa
pemegang pekerjaannya belum ditumbangkan sistem.
Pastikan pengguna hanya diberikan hak-hak akses yang diperlukan untuk melakukan tugas mereka ditugaskan (yaitu, setidaknya hak istimewa).
Keamanan fisik
Menjamin keamanan fisik yang memadai disediakan untuk semua sistem informasi dan semua komponen.
Pastikan semua bagian komputer dan jaringan / komunikasi peralatan ruangan disimpan secara
aman, dengan akses oleh petugas yang berwenang saja.
Laporan
Menerapkan sistem pelaporan, meliputi:
- Menginformasikan manajemen senior dari semua insiden keamanan informasi terkait atau pelanggaran besar.
- Sebuah Informasi Laporan Keamanan Tahunan Negara
- Laporan lain yang diperlukan (yaitu, untuk organisasi federal:. OMB EDARAN NO A 130, Manajemen Sumber Informasi Federal)
Manajemen risiko
Menetapkan program manajemen risiko untuk mengidentifikasi dan mengukur semua risiko, ancaman, dan kerentanan untuk sistem informasi organisasi dan data.
Memberlakukan analisis resiko secara periodik untuk mempertahankan perlindungan yang tepat
dari informasi.
Pastikan bahwa semua perlindungan keamanan hemat biaya dan sepadan dengan risiko identifikasi dan kerusakan yang dihasilkan jika informasi itu hilang, benar diakses, atau tidak benar dimodifikasi.
Keamanan Perangkat Keras / Perangkat Lunak
Pastikan keamanan perangkat lunak dan perangkat keras (yaitu, anti-virus perangkat lunak,
intrusi deteksi perangkat lunak, firewall, dll) yang dioperasikan oleh tenaga terlatih, dipelihara dengan baik, dan terus diperbarui.
Pengujian
Memastikan bahwa semua fitur keamanan, fungsi, dan kontrol diuji secara berkala, dan hasil tes didokumentasikan dan dipelihara.
Pastikan sistem informasi baru (hardware dan software) yang diuji untuk memverifikasi bahwa
sistem memenuhi didokumentasikan spesifikasi keamanan dan tidak melanggar kebijakan keamanan yang ada.
Pelatihan
Memastikan bahwa semua personel wajib menerima pelatihan berkala di keamanan informasi
dan diterima praktek keamanan informasi.
Memastikan bahwa semua karyawan baru menerima pengarahan keamanan informasi sebagai bagian dari Proses indoktrinasi karyawan baru.
Memastikan bahwa semua personel sistem informasi diberikan pelatihan keamanan informasi
yang tepat untuk sistem dengan mana mereka bekerja.
Pastikan bahwa semua pelatihan keamanan informasi disesuaikan dengan apa yang pengguna perlu tahu tentang spesifik sistem informasi dengan tempat mereka bekerja.
Pastikan bahwa pelatihan keamanan informasi saat ini tetap dengan mengevaluasi secara
berkala dan memperbarui pelatihan.
Sistem Akuisisi
Memastikan bahwa persyaratan keamanan yang sesuai termasuk dalam spesifikasi untuk akuisisi
sistem Informasi.
