BAB II TINJAUAN PUSTAKA

Transkripsi

1 BAB II TINJAUAN PUSTAKA II.1 Manajemen Resiko Teknologi Informasi Manajemen resiko meliputi tiga proses: [2] 1. Risk Assessment, 2. Risk Mitigation, 3. Evaluation and Assessment. Manajemen resiko adalah proses yang dilakukan oleh para manajer IT untuk menyeimbangkan kegiatan operasional dan pengeluaran biaya keuangan, dalam mencapai keuntungan dengan melindungi sistem IT dan data yang mendukung misi organisasinya. II.1.1. Risk Assessment Penilaian resiko (Risk Assesment) merupakan proses yang pertama di dalam metodologi manajemen resiko. Organisasi menggunakan penilaian resiko untuk menentukan tingkat ancaman yang potensial dan resiko yang berhubungan dengan suatu sistim IT seluruh SDLC-nya (System Development Life Cycle). Keluaran/hasil dari proses ini membantu ke arah mengidentifikasi kendali yang sesuai untuk mengurangi atau menghapuskan resiko sepanjang/ketika proses peringanan resiko (risk mitigation). Untuk menentukan kemungkinan (likelihood) suatu peristiwa/kejadian masa depan yang kurang baik, ancaman (threats) pada suatu sistem IT harus dianalisis bersama dengan vulnerability yang potensial dan pengendalian pada tempatnya untuk sistem IT. Metodologi Penilaian Resiko meliputi sembilan langkah-langkah utama (Gambar II.1), sebagai berikut. [2] 9

2 Input Risk Assessment Activities Output Hardware, software, system interfaces, data and information, people, system mission Step 1 System Characterization System boundary, system function, system and data critically, system and data sensitivity History of system attack Step 2 Threat identification Threat statement Data from intelligence agencies, mass media. Step 3 Vulnerability Identification List of potential vulnerabilities Current control, Planned Control Step 4 Control analysis List Of Current and Planned Control Threat source Motivation, Threat Capacity, Nature of Vulnerability, Current Control. Step 5 Likelihood determination Likelihood Rating Mission impact analysis, Asset Criticality assessment, Data Criticality, Data Sensitivity. Step 6 Impact Analysis Impact Rating Likelihood of Threat exploitation, Magnitude of impact Step 7 Risk determination Risk And Associated Risk Level Step 8 Control Recommendation Recommended Control Step 9 Results Documentation Risk Assessment Report Gambar II.1 Proses Risk Assessment [2] 10

3 II System Characterization Di dalam memperkirakan penilaian resiko untuk suatu sistem IT, langkah yang pertama adalah menggambarkan lingkup usahanya (scope of the effort). Pada langkah ini, batasanbatasan dari IT mulai diidentifikasi, bersama dengan sumber daya dan informasi yang menjadi dasar sistemnya. Karakter suatu sistem IT dikenali, untuk menetapkan ruang lingkup usaha penilaian resiko, menggambarkan batasan-batasan otorisasi operasional, dan menyediakan informasi yang penting untuk menjelaskan resiko, contohnya: hardware, software, konektifitas sistem, dan divisi yang bertanggung jawab atau dukungan personilnya. System-Related Information Identifikasi resiko untuk suatu sistem IT memerlukan suatu pemahaman mengenai situasi pemrosesan sistem. Saat melakukan penilaian resiko harus dikumpulkan informasi yang terkait dengan sistem, pada umumnya digolongkan sebagai berikut. Hardware. Software. System interfaces, misalnya: internal dan external connectivity. Data dan informasi. Personil yang mendukung dan pengguna sistem IT. Misi suatu sistem, misalnya: proses-proses yang dilakukan oleh sistem IT. Sistem dan data kritis (bersifat penting dan bernilai bagi organisasi). Sistem dan data sensitif (tingkatan proteksi yang diperlukan untuk memelihara sistem dan integritas, ketersediaan, serta kerahasiahaan data, CIA). Beberapa informasi tambahan yang berhubungan dengan situasi operasional yang meliputi sistem IT dan datanya, misalnya: Kebutuhan fungsional sistem IT, Para pengguna sistem, misalnya teknisi pendukung sistem IT, pengguna aplikasi sistem IT yang melaksanakan fungsi bisnis, Kebijakan Keamanan Sistem yang mengatur sistem IT (kebijakan organisasi, hukum, praktisi industri), Arsitektur Keamanan Sistem, 11

4 Aliran Topologi Jaringan, misalnya Diagram Jaringan, Perlindungan penyimpanan informasi yang melindungi sistem dan ketersediaan data, integritas, serta kerahasiaan, Alir informasi yang mempunyai relasi pada sistem IT, misalnya system interface, aliran sistem input dan output, Kendali teknis yang digunakan untuk sistem IT, misalnya built-in atau produk keamanan pendukukung autentikasi dan identifikasi, audit, perlindungan informasi residual, metode enkripsi, Manajemen pengendalian yang digunakan untuk sistem IT, misalnya: peraturan tentang perilaku, keamanan perencanaan, Kendali operasional yang digunakan untuk sistem IT, misalnya: keamanan personil, backup, pemeliharaan sistem, Phisik lingkungan keamanan sistem IT, misalnya: keamanan fasilitas, kebijakan pusat data, Keamanan lingkungan yang diterapkan untuk sistem IT yang memproses lingkungan, misalnya: kendali untuk kelembaban air, polusi, temperatur, dan bahan-kimia, Untuk suatu sistem dalam proses inisiasi atau tahap disain, informasi sistem dapat diperoleh dari disain atau dokumentasi kebutuhan. Untuk suatu sistem IT dalam proses pengembangan, diperlukan kunci penggambaran aturan keamanan dan atribut perencanaan untuk masa depan sistem IT. Dokumen disain sistem dan rencana keamanan sistem dapat menyediakan informasi yang bermanfaat untuk keamanan dari suatu sistem IT dalam proses pengembangannya. Untuk suatu sistem operasional IT, data yang dikumpulkan tentang sistem IT, mencakup data pada konektifitas konfigurasi sistem dan prosedur yang tidak didokumentasikan. Oleh karena itu, uraian sistem dapat didasarkan pada keamanan yang disajikan berdasarkan infrastruktur atau pada perencanaan keamanan masa depan untuk sistem IT. 12

5 Information-Gathering Techniques Berikut ini adalah teknik yang dapat digunakan untuk mengumpulkan informasi, yang relevan pada sistem IT dalam batasan operasionalnya, terdiri dari hal-hal berikut. Questionnaire. Untuk mengumpulkan informasi yang relevan, penilaian resiko personil dapat dikembangkan dengan suatu daftar pertanyaan mengenai manajemen dan perencanaan kendali operasional atau penggunaan sistem IT. Daftar pertanyaan ini harus disebarkan pada teknisi dan personil manajemen non-teknis yang mendisain atau mendukung sistem IT. Daftar pertanyaan dapat juga digunakan pada saat berkunjung pada organisasi dan melakukan wawancara. On-site Interviews. Wawancara dengan pendukung sistem IT dan personil manajemen dapat memungkinkan personil penilaian resiko untuk mengumpulkan informasi yang bermanfaat tentang sistem IT, misalnya: bagaimana sistem dioperasikan dan diatur. Kunjungan di tempat juga mengijinkan personil penilaian resiko untuk mengamati dan mengumpulkan informasi tentang phisik, lingkungan, dan keamanan operasional sistem IT. Karena sistem masih dalam tahap disain, kunjungan di tempat dapat melakukan "face-to-face" pengumpulan data dan dapat menyediakan kesempatan untuk mengevaluasi lingkungan phisik dimana IT sistem akan beroperasi. Document Review. Dokumentasi kebijakan (dokumentasi legislatif, direksi), dokumentasi sistem (panduan penggunaan sistem, sistem manual administratif, disain sistem dan dokumentasi kebutuhan), dan dokumentasi yang terkait dengan keamanan (laporan audit, laporan penilaian resiko, hasil percobaan sistem, perencanaan keamanan sistem, kebijakan keamanan) dapat menyediakan informasi yang baik tentang pengendalian keamanan yang digunakan dan perencanaan untuk sistem IT. Suatu misi organisasi berdampak pada analisis atau penilaian aset kritis yang menyediakan informasi mengenai sistem dan data kritis/sensitif. Use of Automated Scanning Tool. Metoda teknis proaktif dapat digunakan untuk mengumpulkan informasi sistem secara efisien. Sebagai contoh, suatu alat pemetaan jaringan dapat mengidentifikasi pelayanan yang sedang diberjalan pada suatu perusahaan besar dan menyediakan suatu cara yang cepat untuk membangun profil individu dari target sistem IT. 13

6 II Threat Identification Ancaman merupakan potensi untuk suatu threat-source tertentu terjadi pada suatu vulnerability, sebagai trigger eksploitasi kelemahan yang disengaja ataupun tidak disengaja. Threat-source tidak akan menghasilkan resiko jika tidak ada vulnerability yang digunakan. Threat-Source Identification, tujuan dari langkah ini adalah untuk mengidentifikasi potensi dari threat-sources dan penyusunan suatu daftar yang memaparkan ancaman potensi threat-sources sehingga dapat diterapkan pada sistem IT yang dievaluasi. Suatu threat-source digambarkan sebagai keadaan atau peristiwa dengan potensi yang menyebabkan kerusakan pada suatu IT sistem. Pada umumnya, threat-sources berasal dari alam, manusia, atau lingkungan. Motivation and Threat Actions, pada Tabel II.1, diuraikan suatu ikhtisar dari sekian banyak ancaman umum untuk manusia yang terjadi pada saat ini, dan tindakan ancaman yang diakibatkan serangannya. Tabel II.1 Human threats [2] Threat-Source Motivation Threat Actions Hacker, cracker Challenge, Ego, Rebellion - Hacking - Social engineering - System intrusion, break-ins - Unauthorized system access Computer criminal Terrorist Destruction of information Illegal information disclosure Monetary gain Unauthorized data alteration Blackmail Destruction Exploitation Revenge - Computer crime (e.g., cyber stalking) - Fraudulent act (e.g., replay, impersonation, interception) - Information bribery - Spoofing - System intrusion - Bomb/Terrorism - Information warfare - System attack (e.g., distributed denial of service) - System penetration - System tampering 14

7 Tabel II.1 (Lanjutan) Human threats [2] Threat-Source Motivation Threat Actions Industrial espionage (companies, foreign governments, other government interests) Insiders (poorly trained, disgruntled, malicious, negligent, dishonest, or terminated employees) Competitive advantage Economic espionage Curiosity Ego Intelligence Monetary gain Revenge Unintentional errors and omissions (e.g., data entry error, programming error) - Economic exploitation - Information theft - Intrusion on personal privacy - Social engineering - System penetration - Unauthorized system access (access to classified, proprietary, and/or technology-related information) - Assault on an employee - Blackmail - Browsing of proprietary information - Computer abuse - Fraud and theft - Information bribery - Input of falsified, corrupted data - Interception - Malicious code (e.g., virus, logic bomb, Trojan horse) - Sale of personal information - System bugs - System intrusion - System sabotage - Unauthorized system access II Vulnerability Identification Analisis suatu ancaman pada suatu sistem IT harus meliputi suatu analisis hubungan vulnerability dengan sistem lingkungannya. Tujuan dari langkah ini untuk mengembangkan daftar rincian vulnerability (kekurangan atau kelemahan) yang dapat dieksploitasi atau dimanfaatkan oleh potensi threat-sources. Lihat contoh vulnerability pada Table II.2. Untuk identifikasi vulnerability, dilakukan beberapa tinjauan, yaitu: [2] Vulnerability Sources, System Security Testing, Development off Security Requirements Checklist. 15

8 Tabel II.2 Vulnerability/Threats Pairs [2] Vulnerability Threat-Source Threat Action Terminated employees system identifiers (ID) are not removed from the system Company firewall allows inbound telnet, and guest ID is enabled on XYZ server The vendor has identified flaws in the security design of the system; however, new patches have not been applied to the system Data center uses water sprinklers to suppress fire; tarpaulins to protect hardware and equipment from water damage are not in place Terminated employees Unauthorized users (e.g., hackers, terminated employees, computer criminals, terrorists) Unauthorized users (e.g., hackers, disgruntled employees, computer criminals, terrorists) Fire, negligent persons Dialing into the company s network and accessing company proprietary data Using telnet to XYZ server and browsing system files with the guest ID Obtaining unauthorized access to sensitive system files based on known system vulnerabilities Water sprinklers being turned on in the data center Metode yang direkomendasikan untuk mengidentifikasi sistem vulnerability adalah penggunaan sumber vulnerability, pencapaian dari pengujian sisten keamanan, dan pengembangan suatu daftar nama kebutuhan keamanan. Haruslah dicatat bahwa akan terdapat jenis vulnerability dan metode yang diperlukan untuk menentukan keberadaan vulnerability, seperti berikut ini. Jika sistem IT belum dirancang, maka pencarian untuk vulnerability seharusnya difokuskan pada kebijakan keamanan organisasinya, perencanaan prosedur keamanan serta definisi kebutuhan dari suatu sistem, dan analisis produk keamanan pengembangnya. (Misalnya, laporan-laporan resmi organisasi - white papers). Jika sistem IT sedang diimplemantasikan, maka identifikasi vulnerability seharusnya diperluas untuk meliputi informasi yang lebih spesifik, seperti gambaran model perencanaan keamanan di dalam dokementasi disain keamanan dan tes hasil sertifikasi sistem serta evaluasinya. Jika sistem IT sudah beroperasi, maka proses mengidentifikasi vulnerability seharusnya meliputi suatu analisis model keamanan sistem IT serta pengendalian keamanannya, mengenai teknis dan cara yang digunakan untuk melindungi sistem. 16

9 a. Vulnerability Sources Teknis dan non teknis vulnerability berhubungan dengan suatu proses situasi lingkungan sistem IT dapat diidentifikasi melalui teknik pengumpulan informasi. Dokumentasi sumber daya vulnerability seharusnya mempertimbangkan suatu analisis vulnerability dengan seksama, diantaranya sebagai berikut. Dokumentasi penilaian resiko yang ada sebelumnya, dari sistem IT yang diperkirakan. Laporan audit sistem IT, laporan ketidaksesuaian sistem, laporan tinjauan ulang keamanan, dan laporan tes sistem serta laporan evaluasi. Daftar nama vulnerability, seperti basis data vulnerability. Suatu rekomendasi/saran keamanan. Rekomendasi/saran dari vendor. Analisis keamanan sistem software. b. System Security Testing Metode proaktif, memanfaatkan pengujian sistem, dapat digunakan untuk mengidentifikasi sistem vulnerability secara efisien, tergantung dari kepentingan sistem IT dan sumber daya yang tersedia. Misalnya, pengalokasian dana, teknologi yang tersedia, orang-orang dengan keahlian untuk melakukan tes tersebut. Metode tes meliputi: Automated vulnerabili-ty scanning tool, Security test and evaluation (ST&E), Penetration testing. Automated vulnerability scanning tool digunakan untuk meneliti group of hosts atau suatu jaringan. Misalnya, sistem yang mengijinkan melakukan File Transfer Protocol (FTP) tanpa identitas/nama, melakukan sendmail relaying. Sebagian dari potensi vulnerability yang dikenali oleh automated scanning tool tidak akan menghadirkan vulnerability yang nyata dalam konteks lingkungan system. Sebagai contoh, sebagian dari scanning tool ini menilai potensi vulnerability tanpa mempertimbangkan kebutuhan dan lingkungan lokasinya. Metode ini dapat menghasilkan kesalahan dalam menentukan vulnerability. 17

10 ST & E merupakan teknik lain yang dapat digunakan mengidentifikasi vulnerability sistem IT ketika melakukan penilaian resiko. Hal ini meliputi pengembangan dan eksekusi dari perencaan pengujian (pengujian prosedur dan hasil pengujian yang diharapkan). Tujuan pengujian keamanan sistem adalah menguji efektifitas pengendalian keamanan dari suatu sistem IT sebagai penerapan pada suatu lingkungan operasional. Sasarannya adalah untuk memastikan bahwa penggabungan dapat dilakukan antara spesifikasi keamanan untuk software-hardware dengan implementasi keamanan pada organisasinya atau dengan standar industri. Penetration testing dapat digunakan untuk menyeimbangkan tinjauan ulang dari pengendalian keamanan dan memastikan bahwa perbedaan sistem IT akan dijamin keamanannya. Penetration testing, ketika dioperasikan dalam proses penilaian resiko, dapat digunakan untuk menilai suatu kemampuannya sistem IT untuk bertahan pada siklus keamanan sistem. Sasarannya adalah untuk menguji sitem IT dari sudut pandang suatu threat-source dan untuk mengidentifikasi potensi kegagalan di dalam perencanaan perlindungan sistem IT. Hasil dari jenis pengujian pilihan keamanan ini akan membantu untuk mengidentifikasikan suatu vulnerability sistem c. Development off Security Requirements Checklist Pada langkah ini, personel penilai resiko melakukan penentuan untuk melakukan kombinasi antara kebutuhan keamanan yang diterapkan untuk sistem IT dan pengguna sistemnya dengan pengendalian keamanan yang direncanakannya. Secara khusus, kebutuhan keamanan sisten dapat disajikan dalam bentuk tabel, dengan setiap kebutuhannya yang disertai penjelasan disain sistem serta implementasinya, atau ketidakcukupan kebutuhan pengendalian keamanannya. Suatu daftar nama (checklist) kebutuhan keamanan yang berisikan standar keamanan dasar yang baku, dapat digunakan secara sistematis untuk mengevaluasi dan mengidentifikasi vulnerability (personil, software, informasi), prosedur non otomatisasi, proses, dan perpindahan informasi yang direlasikan sistem IT dengan area keamanan sebagai berikut: Management, Operational, Technical. 18

11 Tabel II.3 merupakan daftar usulan kriteria keamanan yang digunakan untuk mengidentifikasi suatu vulnerability sistem IT pada setiap area keamanan. Tabel II.3 Security Criteria [2] Security Area Security Criteria Management Security Operational Security Technical Security - Assignment of responsibilities - Continuity of support - Incident response capability - Periodic review of security controls - Personnel clearance and background investigations - Risk assessment - Security and technical training - Separation of duties - System authorization and reauthorization - System or application security plan - Control of air-borne contaminants (smoke, dust, chemicals) - Controls to ensure the quality of the electrical power supply - Data media access and disposal - External data distribution and labeling - Facility protection (e.g., computer room, data center, office) - Humidity control - Temperature control - Workstations, laptops, and stand-alone personal computers - Communications (e.g., dial-in, system interconnection, routers) - Cryptography - Discretionary access control - Identification and authentication - Intrusion detection - Object reuse - System audit Hasil dari proses ini adalah daftar nama kebutuhan keamanan. Sumber yang dapat digunakan dalam menyusun "checklist", tetapi hal ini bukan suatu batasan, mengikuti regulasi keamanan pemerintahan dan sumber, dapat juga digunakan pada lingkungan proses sistem IT. Hasil dari checklist (questionnaire) dapat digunakan sebagai masukan untuk suatu evaluasi keberhasilan dan kegagalan. Proses ini mengidentifikasi sistem, proses dan prosedur dalam menyajikan potensi vulnerability. II Control Analysis Sasaran dari langkah ini adalah untuk menganalisis pengendalian yang telah diimplementasikan, atau direncanakan untuk implementasi oleh organisasi dengan memperkecil atau menghapuskan likelihood (probability) penggunaan ancaman suatu vulnerability sistem. 19

12 a. Control Methods Pengendalian keamanan meliputi penggunaan metode teknis dan non teknis. Pengendalian teknis melindungi pengintegrasian dalam hardware komputer, software, atau firmware (mekanisme akses pengendalian, identifikasi/mekanisme autentikasi, metode enkripsi, software pendeteksi gangguan). Pengendalian non teknis mengatur dan mengendalikan operasional, seperti kebijakan keamanan, prosedur operasional serta personil, fisik dan keamanan lingkungan. b. Control Categories Kategori pengendalian untuk metode kendali teknis dan non teknis, lebih lanjut dapat digolongkan sebagai tindakan preventive atau detective. Pengendalian preventive dapat menghalangi usaha melakukan pelanggaran kebijakan, seperti: pengendalian sebagai penyelenggaraan akses pengendalian, enkripsi, dan autentikasi. Pengendalian detective memperingatkan pelanggaran atau percobaan pelanggaran kebijakan keamanan, seperti pengendalian sebagai audit trails, metode pendeteksian gangguan, dan checksums. c. Control Analysis Technique Checklist kebutuhan keamanan dapat digunakan untuk kegagalan validasi keamanan seperti yang dilakukan pada checklist keberhasilan. Oleh karena itu, penting untuk memperbaharui checklist yang mencerminkan perubahan dalam suatu pengendalian lingkungan organisasinya, untuk memastikan kebenaran checklist-nya (perubahan kebijakan keamanan, metode, dan kebutuhan). II Likelihood Determination Untuk memperoleh skor likelihood dari potensi vulnerability, secara keseluruhan dapat dikerjakan dengan mencoba menggabungkan ancaman lingkungan, dengan mempertimbangkan faktor sebagai berikut: [2] Motivasi threat-source dan kemampuannya, Vulnerability dari faktor alam, Keberadaan dan efektivitas pengendalian secara langsung. 20

13 Kemungkinan suatu potensi vulnerability dapat dikerjakan dengan dicoba melalui threatsource yang digambarkan dengan tingkatan high, medium, atau low. Tabel II.4 menggambarkan ketiga tingkatan dari likelihood tersebut. Tabel II.4 Likelihood Definitions [2] [8] Likelihood Level Likelihood Definition High Medium Low The threat-source is highly motivated and sufficiently capable, and controls to prevent the vulnerability from being exercised are ineffective. The threat-source is motivated and capable, but controls are in place that may impede successful exercise of the vulnerability. The threat-source lacks motivation or capability, or controls are in place to prevent, or at least significantly impede, the vulnerability from being exercised. II Impact Analysis Langkah utama berikutnya di dalam mengukur tingkat resiko adalah menentukan dampak yang kurang baik, sebagai hasil implementasi suatu ancaman dari vulnerability. Sebelum memulai analisis dampak, diperlukan suatu kegiatan untuk memperoleh informasi, seperti yang telah dibahas mengenai karakteristik sistem (langkah pertama risk assestment) : System mission, misalnya: proses yang dilakukan oleh sistem IT, System and data criticality, misalnya: suatu nilai sistem yang mempunyai arti penting bagi suatu organisasi, System and data sensitivity. Informasi ini dapat diperoleh dari dokumentasi organisasi yang ada, seperti laporan yang berdampak pada misi atau laporan penilaian suatu aset yang kritis. Analisis dampak pada suatu misi (pada beberapa organisasi dikenal dengan business impact analysis atau BIA), prioritas tingkatan dampaknya berhubungan dengan asset informasi suatu organisasi, berdasarkan pada penilaian secara kualitatif atau kuantitatif dengan mengukur sensitif atau kritis suatu asset. Jika dokumentasi ini belum ada atau penilaian untuk asset IT organisasi tidak dilakukan, maka sistem dan data yang diperlukan dapat ditentukan berdasarkan tingkatan dari tingkat kebutuhan perlindungan untuk memelihara sistem dan ketersediaan, integritas, serta kerahasiaan data (CIA). [2] [19] 21

14 Dengan mengabaikan metode yang digunakan untuk menentukan suatu sistem IT dan data yang diperlukan, pemilik sistem dan informasi adalah penanggung jawab dalam menentukan tingkatan dampak untuk sistem dan informasinya. Sebagai konsekuensinya, dalam menganalisis dampak, pendekatan yang sesuai adalah dengan mewawancarai pemilik sistem dan informasinya. Oleh karena itu, dampak yang kurang baik untuk suatu peristiwa keamanan dapat dijelaskan dengan kerugian atau penurunan, kombinasinya berdasarkan tiga aspek tujuan keamanan, yaitu: integritas, ketersediaan, dan kerahasiaan. Berikut ini merupakan penjelasan mengenai uraian ringkas setiap tujuan keamanan dan konsekuensi/dampak yang dihindarinya (CIA): [2] [19]. Loss of Confidentiality. Sistem dan kerahasiaan data mengacu pada perlindungan informasi dari kebocoran informasi. Dampak dari hal ini dapat merugikan organisasi. Jika tidak diantisipasi dari dampak ini, maka dapat terjadi kehilangan kepercayaan publik terhadap organisasi tersebut. Loss of Integrity. Sistem dan integritas data mengacu pada kebutuhan untuk melindungi informasi dari modifikasi yang tidak boleh dilakukan. Integritas akan hilang jika modifikasi tersebut terjadi pada data atau sistem IT, baik disengaja ataupun tidak disengaja. Jika kerusakan/hilangnya sistem tidak diperbaiki, maka keberlanjutan penggunaan sistem atau data tersebut dapat mengakibatkan ketidaktepatan, fraud (penipuan), atau pengambilan keputusan yang salah. Oleh karena semua pertimbangan ini, kerusakan atau hilangnya integritas dapat mengurangi jaminan suatu sistem IT Loss of Availability. Jika suatu mission-critical sistem IT tidak tersedia pada enduser, maka misinya organisasi ada kemungkinan sudah terpengaruh dengan hilangnya kemampuan sistem dan efektivitas operasional, sebagai contoh: terjadi hilangnya waktu produktif, sehingga menjadi penghalang enduser untuk mencapai fungsinya di dalam mendukung misi organisasi. Beberapa dampak yang bersifat tangible dapat diukur secara kuantitatif dalam lost revenue, biaya perbaikan sistem, atau tingkatan dari usaha untuk memperbaiki masalah, yang disebabkan oleh tindakan dari suatu ancaman. Beberapa dampak (misalnya: 22

15 hilangnya kepercayaan publik, hilangnya kredibilitas dan keuntungan dari organisasi) tidak dapat diukur secara spesifik dengan besaran satuan, tetapi dapat digambarkan ke dalam dampak dengan ukuran high, medium,dan low. Secara umum tulisan ini hanya menggambarkan kategori kualitatif (dampak high, medium, dan low). Lihat Tabel II.5. Magnitude of Impact High Medium Low Tabel II.5 Magnitude of Impact Definitions. [2] [8] Impact Definition Exercise of the vulnerability (1) may result in the highly costly loss of major tangible assets or resources; (2) may significantly violate, harm, or impede an organization s mission, reputation, or interest; or (3) may result in human death or serious injury. Exercise of the vulnerability (1) may result in the costly loss of tangible assets or resources; (2) may violate, harm, or impede an organization s mission, reputation, or interest; or (3) may result in human injury. Exercise of the vulnerability (1) may result in the loss of some tangible assets or resources or (2) may noticeably affect an organization s mission, reputation, or interest. Quantitative versus Qualitative Assessment Dari sekian banyak cara yang dapat digunakan untuk menganalisis resiko, terdapat dua metode dasar yang dapat digunakan yaitu penilaian secara kualitatif dan kuantitatif. Di dalam melaksanakan analisis dampak, harus mempertimbangkan hasil keuntungan dan kerugian dari penilaian kualitatif dengan kuantitatif. Keuntungan yang utama dari analisis dampak secara kualitatif adalah prioritas resiko dan identifikasi area untuk meningkatkan pemulihan dengan merujuk langsung pada vulnerability. Kerugian dari analisis kualitatif adalah tidak menghasilkan pengukuran yang dapat menghitung spesifikasi besaran dari dampaknya, oleh karena itu pembuatan analisis cost-benefit mengenai rekomendasi pengendalian sulit dipulihkan. Keuntungan yang utama dari analisis dampak kuantitatif adalah menghasilkan suatu pengukuran besaran dampak yang dapat dipakai dalam analisis cost-benefit pada rekomendasi pengendalian. Sedangkan kerugiannya tergantung dari cakupan ketidakjelasan kuantitatif yang digunakan, sehingga harus melakukan perkiraan secara kualitatif. Tabel II.6 berikut ini, menunjukkan perbedaan, kelebihan maupun kekurangan antara kedua metode tersebut. 23

16 Tabel II.6 Perbedaan kualitatif dan kuantitatif [8] Kualitatif Kuantitatif Langkah pertama dalam analisis resiko Biasanya merupakan lanjutan dari analisis resiko kualitatif Menggunakan pendekatan non-matematis Menggunakan pendekatan matematis Relatif mudah dihitung dan sederhana Relatif perhitungannya lebih kompleks Relatif mudah digunakan, dijelaskan dan lebih Membutuhkan waktu dan biaya mudah Tidak dapat digunakan untuk analisis cost-benefit Dapat digunakan untuk analisis cost-benefit Unsur subyektif relatif tinggi Unsur subyektif relatif rendah (lebih obyektif) II Risk Determination Tujuan langkah ini adalah untuk menilai tingkatan pengambilan resiko pada sistem IT. Untuk mengukur resiko maka suatu risk scale and a risk-level matrix harus dikembangkan. Risk-Level Matrix. Penentuan akhir dari misi resiko diperoleh dari perkalian antara tingkatan penilaian kemungkinan ancaman dan dampak dari ancaman. Pada Tabel II.7, diperlihatkan bagaimana keseluruhan kemungkinan tingkatan resiko ditentukan berdasarkan pada masukan dari kemungkinan ancaman dan kategori dampak dari ancaman. Pada matriks tersebut, merupakan matriks 3x3 untuk kemungkinan ancaman (high, medium, dan low) dan dampak dari ancaman (high, medium, dan low). Tergantung pada lokasi kebutuhan dari penilaian resiko yang diinginkan, pada beberapa lokasi dapat menggunakan matriks 4x4 atau 5x5. Pada contoh matrik Tabel II.7, diperlihatkan bagaimana keseluruhan tingkat resiko untuk high, medium, dan low diperoleh. Penentuan dari tingkat resiko atau evaluasi ini bersifat subkektif. Dasar pemikiran untuk pertimbangan ini dapat dijelaskan dalam kaitannya dengan kemungkinan penilaian untuk setiap tingkatan kemungkinan ancaman dan penilaian evaluasi untuk setiap tingkatan dari dampaknya. Contohnya: Kemungkinan penilaian untuk setiap tingkat kemungkinan ancaman adalah 1 untuk high, 0.5 untuk medium dan 0.1 untuk low, Pengalokasian nilai untuk setiap tingkatan dampak adalah 100 untuk high, 50 untuk medium, dam 10 untuk low. 24

17 Tabel II.7 Risk-Level Matrix [2] Threat Likelihood Impact Low (10) Medium (50) High (100) High (1.0) Low 10 X 1.0 = 10 Medium 50 X 1.0 = 50 High 100 X 1.0 = 100 Medium (0.5) Low 10 X 0.5 = 5 Medium 50 X 0.5 = 25 Medium 100 X 0.5 = 50 Low (0.1) Low 10 X 0.1 = 1 Low 50 X 0.1 = 5 Low 100 X 0.1 = 10 Risk Scale: High ( >50 to 100); Medium ( >10 to 50); Low (1 to 10) 8 Dengan mengembangkan risk scale and a risk-level matrix, pengukuran resiko dapat juga dilakukan berdasarkan exposure rating, vulnerability level, dan safeguard effectiveness.[8] Pada Tabel II.8, penentuan resiko dilakukan secara conservative dengan vulnerability level lebih berperan terhadap perubahan tingkat resiko, jika dibandingkan dengan safeguard effectiveness. Tabel II.8 Pengembangan Risk-Level Matrix [8] Vulnerability level Low(1) Medium(2) High(3) exposure rating Safeguard effectiveness High(3) Med(2) Low(1) none(0) High(3) Med(2) Low(1) none(0) High(3) Med(2) Low(1) none(0) Description of Risk Level. Pada Tabel II.8 dijelaskan tingkatan resiko untuk matrix di atas. Skala resiko ini (skor high, medium, dan low) menguraikan tingkatan atau derajat resiko pada suatu sistem IT, fasilitas atau prosedur dapat dijadikan arahan jika memberikan vulnerability. Skala resikonya juga menguraikan tindakan manajemen senior, pembuat misi, yang harus memperkirakan untuk setiap tingkatan resiko menjadi low. 25

18 Tabel II.9 Risk Scale and Necessary Actions [2] [8] Risk Level High Medium Low Risk Description and Necessary Actions If an observation or finding is evaluated as a high risk, there is a strong need for corrective measures. An existing system may continue to operate, but a corrective action plan must be put in place as soon as possible. If an observation is rated as medium risk, corrective actions are needed and a plan must be developed to incorporate these actions within a reasonable period of time. If an observation is described as low risk, the system s organization must determine whether corrective actions are still required or decide to accept the risk. II Control Recommendations Ketika proses ini berlangsung, pengendalian dapat mengurangi atau menghapuskan resiko yang dikenali, sebagai penyesuaian operasional organisasi yang dilakukan. Sasaran yang direkomendasikan sebagai pengendali adalah mengurangi tingkatan pengambilan resiko pada sistem IT dan datanya, sehingga menjadi suatu tingkatan yang dapat diterima. Faktor-faktor berikut ini harus dipertimbangkan dalam merekomendasikan kendali dan solusi alternatif untuk memperkecil atau menghapuskan resiko yang ada: Efektivitas dari pilihan yang direkomendasikan, misalnya kecocokan sistem, Perundang-undangan dan peraturan, Kebijakan organisasi, Dampak operasional, Keamanan dan keandalan. Rekomendasi pengendalian adalah hasil dari proses penilaian resiko yang menyediakan masukan dalam proses mengurangi resiko, ketika rekomendasi prosedur serta pengendalian teknik keamanan dievaluasi, diprioritaskan, dan diterapkan. Sebagai catatan, bahwa tidak semua pengendalian yang direkomendasikan dapat diterapkan untuk mengurangi kerugian. Untuk menentukan hal-hal yang diperlukan dan sesuai dengan suatu spesifikasi organisasi, analisis cost-benefit, seharusnya dilaksanakan rekomendasi pengendalian yang diusulkan. Hal ini diperlukan untuk menunjukkan bahwa biaya-biaya yang menerapkan pengendalian dapat dibenarkan/disetujui dengan pengurangan di dalam tingkatan pengambilan resiko. Sebagai tambahan, dampak 26

19 operasional yang mempengaruhi pada pencapaian sistem dan kelayakan kebutuhan teknis yang diterima pengguna, mengenai pilihan rekomendasi, seharusnya dievaluasi secara hati-hati selama proses peringan resiko berlangsung. II Results Documentation Setelah resiko penilaian diselesaikan (threat-sources dan vulnerabilities sudah diidentifikasi, resiko sudah dinilai, dan menyajikan kendali yang direkomendasikan), hasilnya harus didokumentasi dalam suatu laporan atau uraian singkat. Laporan penilaian resiko adalah suatu laporan manajemen yang memberikan bantuan untuk manajemen senior, membuat misi organisasi, membuat keputusan untuk suatu kebijakan, membuat prosedur, anggaran, dan sistem operasional serta perubahan manajemen. Tidak sama dengan suatu audit atau laporan investigasi, yang mencari suatu pelanggaran, laporan penilaian resiko tidak harus menjelaskan cara/metode dengan jelas, tetapi laporan ini dijadikan sebagai pendekatan analitis dan sistematis untuk memperkirakan resiko sedemikian rupa, sehingga manajemen senior akan memahami suatu resiko dan mengalokasikan sumber daya untuk mengurangi serta memperbaiki potensi kerugian. Oleh karena alasan ini, sebagian orang lebih menyukai untuk menggunakan pasangan threat/vulnerabililty sebagai pengganti observasi untuk pencarian resiko dalam laporan penilaian resiko. II.1.2. Risk Mitigation Risk Mitigation merupakan proses manajemen resiko kedua yang melibatkan prioritizing, evaluating, dan implementing rekomendasi pengendalian penyesuaian risk-reducing dari proses penilaian resiko. Umumnya, untuk dapat menghilangkan semua resiko pada suatu skenario tidak mungkin dilakukan, hal ini merupakan tanggung jawab dari manajemen senior serta fungsionalnya dan para manajer bisnis untuk menggunakan least-cost, untuk membuat pendekatan dan menerapkan pengendalian yang paling sesuai pada misi organisasi, sehingga dampaknya dapat diterima atau disesuaikan dengan sumber daya organisasi dan misinya. 27

20 II Risk Mitigation Options Risk Mitigation merupakan suatu metodologi sistematis yang digunakan oleh manajemen senior untuk mengurangi resiko dari misi yang dibuat. Hal ini dapat dicapai melalui beberapa pilihan, sebagai berikut. Risk Assumption. Menerima potensi resiko dan melanjutkan operasional sistem IT atau menerapkan pengendalian untuk menurunkan resiko menjadi suatu tingkatan yang dapat diterima. Risk Avoidance. Menghindari resiko dengan melakukan penghapusan penyebab resiko dan konsekuensinya, Misalnya, membatalkan fungsi tertentu pada sistem atau menutup sistemnya, ketika terdapat resiko yang dikenali. Risk Limitation. Membatasi resiko dengan menerapkan pengendalian untuk memperkecil dampak yang kurang baik dari efek ancaman suatu vulnerability. Misalnya, preventive, detective controls. Risk Planning. Mengatur resiko dengan mengembangkan suatu rencana risk mitigation, yang implementasinya diprioritaskan dan pengendalian dalam pemeliharaan. Research and Acknowledgment. Menurunkan resiko kerugian dengan cara mengetahui vulnerability/kelemahan dan meneliti pengendaliannya untuk memperbaiki vulnerability. Risk Transference. Memindahkan resiko dengan menggunakan suatu pilihan, untuk mengganti kerugian, seperti pembelian asuransi. Tujuan dan misi dari suatu organisasi harus mempertimbangkan dalam memilih risk mitigation apapun. Jika terjadi kesulitan untuk mengenali semua resiko, maka prioritas seharusnya diberikan pada threat dan vulnerability yang mempunyai potensi dampak pada misi. Hal ini, juga dilakukan dalam melindungi suatu misi organisasi dan sistem ITnya, karena setiap situasi/lingkungan dan objektif organisasi, mempunyai keunikan, pilihan yang digunakan untuk mengurangi resiko dan metode implementasinya dapat disesuaikan. 28

21 II Approach For Control Implementation Penerapan aturan yang diambil untuk tindakan pengendalian, yaitu dengan menangani resiko yang terbesar dan dikerjakan sebaik-baiknya, melalui biaya risk mitigation paling rendah serta dampak yang minimal dengan menggunakan kemampuan misi organisasinya. Metodologi risk mitigation berikut ini, menjelaskan pendekatan untuk implementasi pengendalian. (lihat Gambar II.2): [2] Prioritize Actions Berdasarkan pada tingkatan resiko yang diperkenalkan dalam laporan penilaian resiko, maka tindakan implementasi lebih diprioritaskan. Dalam mengalokasikan sumber daya, prioritas paling tinggi seharusnya diberikan pada resiko yang tinggi (resiko dengan tingkatan very high atau high). Vulnerability/threat akan memerlukan tindakan pengkoreksian untuk melindungi suatu organisasi dan misinya. Evaluate Recommended Control Options Pada rekomendasi pengendalian dalam proses penilaian resiko, tidak ada satupun yang dapat sesuai untuk suatu sistem IT dan spesifikasi organisasi. Pada langkah ini, dilakukan analisis kelayakan (compatibility, user acceptance) dan efektifitas (tingkatan perlindungan dan tingkat peringanan resiko), serta pemilihan pengendalian rekomendasi. Sasarannya adalah untuk memilih rekomendasi pengendalian yang paling sesuai untuk memperkecill resiko. Conduct Cost-Benefit Analysis Untuk membantu manajemen di dalam membuat keputusan dan untuk mengidentifikasi pengendalian cost-effective, maka suatu analisis cost-benefit dilakukan. Select Control Berdasarkan hasil dari analisis cost-benefit, manajemen menentukan pengendalian yang lebih cost-effective untuk memperkecil resiko pada misi organisasinya. Pemilihan pengendalian seharusnya merupakan kombinasi dari teknis, operasional, dan unsur-unsur pengendalian manajemen untuk memastikan keamanan yang cukup pada sistem IT dan organisasi. 29

22 Assign Responsibility Penempatan orang (personil tetap atau kontrak) yang mempunyai penyesuaian keahlian dan skill-sets untuk menerapkan pengendalian yang dipilih dan bertanggungjawab dalam penugasannya. Develop a Safeguard Implementation Plan Pada langkah ini, suatu rencana implementasi safeguard dilakukan pengembangannya. Perencanaan seharusnya berisi informasi sebagai berikut. - Resiko (vulnerability/threat) dan hubungan tingkatan resiko (output laporan penilaian resiko). - Rekomendasi Pengendalian (output laporan penilaian resiko). - Prioritas tindakan (dengan prioritas tingkat resiko yang very high dan high). - Pengendalian pemilihan rencana (berdasarkan kelayakan, efektivitas, manfaat untuk organisasi, dan biayanya). - Sumber daya yang diperlukan untuk menerapkan pengendalian rencana yang terpilih. - Daftar dari tanggung jawab tim dan staf. - Start date untuk implementasi. - Target tanggal penyelesaian untuk implementasi. - Kebutuhan Pemeliharaan. Prioritaskan rencana implementasi perlindungan, dan permulaan suatu proyek serta tanggal target penyelesaian. Hal ini akan membantu dan mempercepat proses risk mitigation. Implement Selected Controls Tergantung pada situasi yang terjadi pada individunya, pengendalian yang diimplementasikan, dapat menurunkan tingkat resiko, tetapi tidak dapat menghilangkan resiko tersebut. 30

23 Input Risk Mitigation Activities Output Risk level from the risk assessment report Step 1 Prioritize actions Action ranking from high to low Risk Assessment report Step 2 Evaluate recommended control option Feasibility Effectiveness List Of possible controls Step 3 Conduct Cost-benefit Analysis Impact of not/of implementing Cost-Benefit Analysis Step 4 Select Controls Selected Control Step 5 Assign Responsibility List of responsible persons Step 6 Defelop safeguard Implementation Plan Risk and associated Risk Levels Prioritized Actions Recommended Control Selected planned Controls Responsible Persons Start date Target completion date Maintenance requierements Safeguard implementation plan Step 7 Implement Selected Controls Residual risk Gambar II.2 Proses Risk Mitigation [2] 31

24 II.1.3. Evaluation and Assessment Pada umumnya, di dalam suatu organisasi, secara terus menerus network diperluas dan diperbaharui, komponen diubah dan aplikasi software-nya diganti atau diperbaharui dengan versi yang lebih baru. Perubahan ini berarti bahwa, resiko baru akan timbul dan resiko yang sebelumnya dikurangi, akan menjadi suatu perhatian. Demikian seterusnya, sehingga manajemen resiko akan berkesinambungan dan berkembang. Manajemen resiko seharusnya diselenggarakan dan terintergrasi dengan SDLC untuk sistem IT, bukan dikarenakan untuk kepentingan hukum atau regulasi, melainkan suatu good practice dan dukungan bisnis organisasi secara objektif atau berdasarkan misi. Keberhasilan (keys for success) program manajemen resiko berdasarkan hal berikut. [2] 1. Komitmen manajemen senior. 2. Keikutsertaan dan dukungan yang penuh dari tim IT. 3. Kemampuan dari tim risk assessment yang harus mempunyai keahlian untuk menerapkan metodologi risk assesement pada suatu sistem, mengidentifikasi misi dari resiko dan safeguards yang cost-effective untuk memenuhi kebutuhan organisasi. 4. Kesadaran dan kerjasama dari anggota masyarakat pengguna, yang harus mengikuti prosedur dan mematuhi pengendalian yang diiterapkan untuk melindungi misi organisasinya. 5. Suatu evaluasi yang berkesinambungan dan penilaian dari misi resiko yang terkait dengan IT. II.2 Metode Analisis Resiko Jawaban yang menjelaskan mengenai pengeluaran keuangan, dipergunakan untuk memperbaiki keamanan suatu organisasi, merupakan makna yang pertama untuk suatu analisis resiko. Terdapat dua jenis dasar analisis resiko dalam melakukan pertimbangan yaitu: analisis resiko kuantitatif dan analisis resiko kualitatif. Analisis resiko kuantitatif, mencoba untuk memberikan nilai moneter secara obyektif pada suatu komponen, dari penaksiran resiko itu, dan untuk penilaian atas kerugian yang potensial. Sebaliknya, suatu analisis resiko yang kualitatif adalah analisis berbasis suatu skenario. [10] 32

25 Meskipun suatu analisis resiko secara kualitatif, relatif dapat lebih mudah untuk dilakukan, tetapi analisis resiko secara kuantitatif menawarkan beberapa keuntungan, sebagai berikut. [1] Lebih banyak obyektifitas dalam penilaiannya. Sebagai instrumental penjualan yang lebih tangguh untuk manajemen. Penawaran-penawaran dari suatu proposal, mengarah pada proyeksi cost/benefit. Dapat di-set dengan baik, untuk memenuhi kebutuhan tentang situasi-situasi yang spesifik. Dapat juga dimodifikasi untuk kesesuaian dengan kebutuhan dari industri yang spesifik. Sangat sedikit kecenderungan yang akan menimbulkan perselisihan paham, selama melakukan tinjauan ulang manajemen. Analisis sering berasal dari beberapa fakta yang tidak dapat dibantah. Untuk melakukan suatu analisis resiko secara kuantitatif, perlu untuk ditentukan hubungan suatu nilai dari kerugian-kerugian potensial dengan proses yang tertunda, kerusakan properti, atau data. Kemudian perlu dilakukan perkiraan kemungkinan kejadian dari kegagalan resiko. Sehingga pada akhirnya dapat diperhitungkan perkiraan kerugian pertahunnya.[10] II.2.1 Analisis Resiko Kualitatif Dan Perhitungannya Terdapat tiga aspek kombinasi berdasarkan tujuan keamanan, yaitu: integritas, ketersediaan, dan kerahasiaan. (CIA). Berikut ini merupakan penjelasan mengenai uraian ringkas setiap tujuan keamanan, yang terkait dengan analisis resiko untuk tesis ini, yaitu sebahai berikut. Confidentiality. Sistem dan kerahasiaan data mengacu pada perlindungan informasi dari kebocoran informasi. Integrity. Sistem dan integritas data mengacu pada kebutuhan untuk melindungi informasi dari modifikasi yang tidak boleh dilakukan. Integritas akan hilang jika modifikasi tersebut terjadi pada data atau sistem IT, baik disengaja ataupun tidak disengaja. 33

26 Availability. Jika suatu mission-critical sistem IT tidak tersedia pada enduser, maka misinya organisasi ada kemungkinan sudah terpengaruh dengan hilangnya kemampuan sistem dan efektivitas operasional. Gambar II.3 CIA Triad [19] II Identifikasi dan Valuasi Asset Setelah dilakukan identifikasi asset (lihat penjelasan mengenai karateristik sistem), langkah selanjutnya adalah memberikan penilaian dengan suatu metode valuasi sederhana yang mempunyai indikasi terhadap loss asset. Skala untuk penilaiannya menggunakan kualitatif rangking sebagai berikut: [8] High = 3, Medium = 2, Low = 1. II Identifikasi dan Valuasi Vulnerability Teknis dan non teknis vulnerability berhubungan dengan suatu proses situasi lingkungan sistem IT dapat diidentifikasi melalui teknik pengumpulan informasi. Dokumentasi sumber daya vulnerability seharusnya mempertimbangkan suatu analisis vulnerability dengan seksama. Setelah dilakukan identifikasi vulnerability (lihat penjelasan mengenai karateristik sistem), langkah selanjutnya adalah memberikan penilaian dengan suatu metode valuasi sederhana yang mempunyai indikasi terhadap loss asset. Skala untuk penilaiannya menggunakan kualitatif rangking sebagai berikut: [8] High = 3, Medium = 2, Low = 1. 34

27 Valuasi utuk vulnerability tersebut di atas berhubungan dengan safeguard yang ada pada suatu sistem. Jika safeguard yang tersedia efektif maka level vulnerability-nya semakin rendah. II Threat Assesment Ancaman merupakan potensi untuk suatu threat-source tertentu terjadi pada suatu vulnerability, sebagai trigger eksploitasi kelemahan yang disengaja ataupun tidak disengaja. Threat tidak akan menghasilkan resiko jika tidak ada vulnerability yang digunakan. Secara umum threat dapat dikelompokkan menjadi tiga kategori: [2] [8] Nature, threat ini disebabkan oleh faktor alam yang dapat menyebabkan sistem mengalami gangguan (disruption) bahkan dapat terjadi penghentian (interruption) sistem, Accidental, threat ini terjadi karena faktor kecelakaan (ketidaksengajaan), Deliberate, threat ini terjadi karena unsur kesengajaan. II Estimasi Potential Impact Setelah asset diidentifikasi, kemudian dilakukan estimasi yang diakibatkan jika suatu threat berhasil menyerang asset. Berikut ini merupakan beberapa potential impact yang dapat mengakibatkan suatu dampak terhadap asset, yaitu: [8] Disclosure, kegagalan dalam melindungi kerahasiaan yang mengakibatkan kehilangan confidentiality, sehingga berdampak terhadap hilangnya kredibilitas suatu organisasi, Modification, dampak ini dapat mengakibatkan suatu resource kehilangan integrity-nya, sehingga resource-nya tidak dapat berjalan sesuai dengan skenarionya, Loss/Destruction, dampak ini mengakibatkan suatu resource kehilangan secara fisik untuk availability-nya, sehingga diperlukan replacement, Interruption, dampak ini mengakibatkan suatu resource kehilangan availabilitynya untuk jangka waktu tertentu. 35

28 Valuasi potential impact dapat dilakukan dengan memberikan suatu skala sebagai berikut. [2][8] High business impact = 3, jika mempengaruhi sebagian besar komponen sistem, serta kerugian yang dihasilkan cukup besar hingga membutuhkan replacement suatu komponen. Medium business impact = 2, jika mempengaruhi lebih dari satu elemen sistem atau komponen, serta kerugian yang diakibatkan bersifat moderate. Low business impact = 1, jika pengaruhnya sedikit atau hanya satu elemen sistem, serta kerugian yang diakibatkan sifatnya kecil. II Likelihood of Threat Occurrence Likelihood of Threat Occurrence merupakan banyaknya kemungkinan suatu threat terjadi dalam suatu periode waktu. Hal ini dapat ditentukan berdasarkan pengalaman suatu organisasi atau badan independent yang memantau suatu statistik insiden/kejadian. Dalam menentukan skala nilai ini, dilakukan dengan proses yang sangat subyektif. Rating kualitatif tersebut yaitu: [8] High = 3, berkisar antara 71% sampai dengan 100%, Medium = 2, berkisar antara 31% sampai dengan 70%, High = 1, berkisar antara 1% sampai dengan 30%. II Exposure Rating Exposure rating mempunyai skala 1 sampai 9 yang dihasilkan dari asosiasi antara level impact dan likelihood of threat occurrence. Exposure rating tidak menunjukkan suatu vulnerability ataupun safeguard, sehingga bukan merupakan level suatu resiko. Dalam Tabel II.10, diperlihatkan exposure rating berdasarkan likelihood of occurrence dan level impact. Tabel II.10 Exposure Rating [8] Level of impact resulting from a threat occurrence Likelihood of occurrence Low Medium High Low Medium High

29 II Pengukuran Resiko Ukuran dari suatu resiko berasal dari kombinasi antara exposure rating, level vulnerability, dan tingkat efektifitas safeguard. Secara sederhana, pengukuran resiko secara kualitatif dilakukan dengan memberikan skala high, medium, dan low. Pengukuran resiko dengan skala tersebut memiliki kekurangan, yaitu untuk resiko dengan exposure, vulnerability, dan safeguard yang bernilai high, akan memiliki hasil yang sama dengan resiko untuk exposure, vulnerability, dan safeguard yang bernilai low. Oleh karena itu, untuk tingkatan pengukuran resiko diberikan lima skala, yaitu: [8] High = 5, Moderately high = 4, Medium = 3, Low = 2, Very low = 1. Pada Tabel II.8, penentuan resiko dilakukan secara conservative dengan vulnerability level lebih berperan terhadap perubahan tingkat resiko, jika dibandingkan dengan safeguard effectiveness. II Safeguard Safeguard digunakan untuk mengidentifikasi mekanisme, service, atau prosedur yang dapat mencegah atau mengurangi terjadinya threat yang dapat mengeksploitasi vulnerability. Secara fungsional, safeguard berhubungan dengan area confidentiality, integrity, dan available. Tingkatan safeguard diukur bedasarkan empat kategori, yaitu: [8] Level 3 = high, jika kemungkinan suatu vulnerability yang tereksploitasi oleh threat, dengan tinggi dapat dikurangi, Level 2 = medium, jika kemungkinan suatu vulnerability yang terekploitasi oleh threat, dapat dikurangi secara moderate, Level 1 = low, jika kemungkinan suatu vulnerability yang terekploitasi oleh threat hanya, dapat sedikit di-reduce, Level 0 = none, tidak ada safeguard. 37