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
Input Hardware, software, system interfaces, data and information, people, system mission
Risk Assessment Activities Step 1 System Characterization
Output 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
II.1.1.1
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
•
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
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
II.1.1.2
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
Computer criminal
-
Destruction of information Illegal information disclosure Monetary gain Unauthorized data alteration Blackmail Destruction Exploitation Revenge -
Terrorist
-
14
Hacking Social engineering System intrusion, break-ins Unauthorized system access 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
Tabel II.1 (Lanjutan) Human threats [2]
Threat-Source
Motivation
Threat Actions
Industrial espionage (companies, foreign governments, other government interests)
Competitive advantage Economic espionage
-
Insiders (poorly trained, disgruntled, malicious, negligent, dishonest, or terminated employees)
Curiosity Ego Intelligence Monetary gain Revenge Unintentional errors and omissions (e.g., data entry error, programming error)
-
II.1.1.3
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
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
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
Terminated employees
Dialing into the company’s network and accessing company proprietary data Using telnet to XYZ server and browsing system files with the guest ID
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
Unauthorized users (e.g., hackers, terminated employees, computer criminals, terrorists) Unauthorized users (e.g., hackers, disgruntled employees, computer criminals, terrorists) Fire, negligent persons
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
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
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
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.1.1.4
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
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.1.1.5
Likelihood Determination
Untuk memperoleh skor likelihood dari potensi vulnerability, secara keseluruhan dapat dikerjakan
dengan
mencoba
menggabungkan
ancaman
mempertimbangkan faktor sebagai berikut: [2] •
Motivasi threat-source dan kemampuannya,
•
Vulnerability dari faktor alam,
•
Keberadaan dan efektivitas pengendalian secara langsung.
20
lingkungan,
dengan
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
The threat-source is highly motivated and sufficiently capable, and controls to prevent the vulnerability from being exercised are ineffective.
Medium
The threat-source is motivated and capable, but controls are in place that may impede successful exercise of the vulnerability.
Low
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.1.1.6
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
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
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. Tabel II.5 Magnitude of Impact Definitions. [2] [8] Magnitude of Impact
High
Medium Low
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
Tabel II.6 Perbedaan kualitatif dan kuantitatif [8] Kualitatif Langkah pertama dalam analisis resiko Menggunakan pendekatan non-matematis Relatif mudah dihitung dan sederhana Relatif mudah digunakan, dijelaskan dan lebih mudah Tidak dapat digunakan untuk analisis cost-benefit Unsur subyektif relatif tinggi
II.1.1.7
Kuantitatif Biasanya merupakan lanjutan dari analisis resiko kualitatif Menggunakan pendekatan matematis Relatif perhitungannya lebih kompleks Membutuhkan waktu dan biaya Dapat digunakan untuk analisis cost-benefit Unsur subyektif relatif rendah (lebih obyektif)
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
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
8
Risk Scale: High ( >50 to 100); Medium ( >10 to 50); Low (1 to 10)
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]
Safeguard effectiveness
none(0)
High(3)
Med(2)
Low(1)
none(0)
High(3)
Med(2)
Low(1)
none(0)
High(3)
Low(1)
Medium(2)
Med(2)
Low(1) High(3)
exposure rating
Vulnerability level
1 2 3 4 5 6 7 8
1 1 1 1 1 1 1 2
1 1 1 1 2 2 3 4
1 1 2 3 3 3 4 5
1 2 3 4 4 4 5 5
1 1 1 1 1 2 2 2
1 1 2 2 3 3 4 5
2 2 3 4 4 4 5 5
2 3 4 5 5 5 5 5
1 1 1 2 2 2 3 3
2 2 3 3 4 4 5 5
3 3 4 4 5 5 5 5
3 4 4 5 5 5 5 5
9
2
5
5
5
2
5
5
5
3
5
5
5
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
Tabel II.9 Risk Scale and Necessary Actions [2] [8] Risk Level
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.
High
Medium Low
II.1.1.8
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.
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
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.1.1.9
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
II.1.2.1
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
II.1.2.2
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
•
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
menghilangkan resiko tersebut.
30
tingkat
resiko,
tetapi
tidak
dapat
Input
Risk Mitigation Activities
Risk level from the risk assessment report
Step 1 Prioritize actions
Output Action ranking from high to low
Step 2 Evaluate recommended control option
Risk Assessment report
List Of possible controls
• Feasibility • Effectiveness
Step 3 Conduct Cost-benefit Analysis
Cost-Benefit Analysis
• Impact of not/of implementing
Step 4 Select Controls
Step 5 Assign Responsibility
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
Step 7 Implement Selected Controls
Gambar II.2 Proses Risk Mitigation [2]
31
Selected Control
List of responsible persons
Safeguard implementation plan
Residual risk
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
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
•
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.2.1.1
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.2.1.2
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
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.2.1.3
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.2.1.4
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
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.2.1.5
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.2.1.6
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] Likelihood of occurrence
Level of impact resulting from a threat occurrence Low Medium High
Low
1
2
4
Medium
3
6
7
High
5
8
9
36
II.2.1.7
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.2.1.8
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
II.2.1.9
Residual Risk
Di dalam proses residual risk, pemilihan safeguard dilakukan untuk menurunkan level resiko menuju level yang dapat diterima (acceptable level), Proses penurunan level tersebut bersifat iteratif. Pada proses penilaian resiko untuk residual risk, langkah-langkah yang dilakukan sama dengan proses yang dijelaskan pada sub-bab sebelumnya, mengenai pengukuran resiko. II.2.2
Analisis Resiko Kuantitatif Dan Perhitungannya
Berikut ini, merupakan penjelasan mengenai prosedur yang dilakukan pada analisis resiko secara kuantitatif dan rumusan perhitungannnya. II.2.2.1
Prosedur Analisis Resiko
Langkah-langkah untuk melakukan analisis resiko kuantitatif adalah sebagai berikut. [1] a. Lakukan suatu studi perkiraan resiko untuk menentukan faktor-faktor resiko. b. Berdasarkan faktor-faktor resiko tersebut di atas, tentukan nilai dari asset yang mempunyai resiko (Tangible Assets dan Intangible Assets). c. Tentukan pendekatan berdasarkan prosedur yang ada pada perusahaan, dalam melaporkan kerugian ketika melakukan penilaian keamanan di perusahaan. Sebagai referensinya, dapat menggunakan data mengenai informasi kepemilikan di dalam tabel II.13 dalam membuat penyesuaian dari perkiraan-perkiraan secara kuantitatif untuk analisis resikonya. d. Perkirakan Annualized Rate of Occurrence (ARO) untuk setiap faktor resiko. e. Tentukan countermeasures yang diperlukan untuk mengantisipasi masing-masing faktor resiko. f. Tentukan Annualized Loss Expectancy (ALE) untuk setiap faktor resiko. Dengan catatan bahwa, ARO untuk ALE setelah implementasi countermeasures, mempunyai kemungkinan tidak selalu sama dengan nol. g. Melakukan analisis safeguard cost/benefit dengan menghitung perbedaan antara ALE sebelum menerapkan countermeasure dengan ALE setelah menerapkan countermeasure.
38
h. Berdasarkan analisis pada langkah f dan g, tentukan Return On Investment dengan menggunakan Internal Rate of Return (IRR). Untuk penjelasan IRR, dapat dilihat pada sub bab mengenai perhitungan analisis resiko secara kuantitatif. i. Hasilnya adalah suatu sajian ringkas pada manajemen untuk ditinjau ulang. Metodologi yang digunakan dapat serupa dengan karakteristik permohonan untuk modal proyek engineering. II.2.2.2
Perhitungan Analisis Resiko
Variabel kunci dan persamaan yang dipergunakan untuk melaksanakan suatu analisis resiko kuantitatif adalah sebagai berikut. [1][2][8] •
Exposure Factor (EF) = Persentase suatu asset loss yang disebabkan oleh identifikasi threat yang ranges-nya antara 0% sampai 100%. Tabel berikut ini, dapat digunakan untuk memperkirakan nilai exposure factor. Tabel II.11 Estimasi Nilai EF
Value 0% 20% 40% 60% 80% 100%
•
Description Aset resistant terhadap threat Kerusakan kecil Tingkat kerusakan menengah, akan terjadi delay dalam pekerjaan Tingkat kerusakan besar, pekerjaan sudah mengalami delay Tingkat kerusakan besar, pekerjaan mengalami interupsi Kerusakan fatal, pekerjaan terhenti dan sistem membutuhkan total replacement
Single Loss Expectancy (SLE) adalah nilai kerugian terhadap asset bila sebuah resiko yang teridentifikasi terjadi. SLE = Asset Value x Exposure factor, misalnya 1,000,000 @ 20% kemungkinannya = 200,000
•
Annualized Rate of Occurrence (ARO) adalah perkiraan atau estimasi frekuensi sebuah resiko yang dapat terjadi dalam setahun. Misalnya: o Jika suatu threat terjadi sebanyak 10 kali dalam 1 tahun, maka ARO yang terjadi adalah 10; o Jika pemutusan listrik terjadi 12 kali dalam 1 tahun, maka ARO yang terjadi adalah 12; o Jika suatu threat terjadi sebanyak 1 kali dalam 10 tahun, maka ARO yang terjadi adalah 1/10; o Jika pencurian terjadi sebanyak 1 kali dalam 4 tahun, maka ARO yang terjadi adalah 1/4;
39
•
Annualized Loss Expectancy (ALE) adalah nilai estimasi kerugian pertahun terhadap asset, jika sebuah resiko yang teridentifikasi terjadi. ALE = Single Loss Expectancy x Annualized Rate of Occurrence;
•
Safeguard cost/benefit analysis adalah analisis cost/benefit terhadap langkahlangkah penanganan resiko yang telah dimiliki, bagi setiap resiko yang teridentifikasi. Nilai safeguard suatu perusahaan/organisasi = (ALE sebelum implemantasi safeguard) – (ALE setelah implementasi safeguard) – (biaya tahunan safeguard).
II.2.2.3
Pemberian Nilai Untuk Tangible Dan Intangible Asset
Berikut ini adalah salah satu metode untuk memperoleh perkiraan-perkiraan pada Tangible Assets. [1] a. Bertanya kepada site controller atau IT manager untuk informasi biaya, mengenai existing equipment, software, dan hardware. b. Melakukan riset perilaku di Internet, untuk mempertegas atau membandingkan persamaan suatu sistem. Tentukan usia dari Tangible Assets yang ada, dan menghitung nilai yang termasuk biaya penyusutan. c. Mencari modal-modal proyek yang sebelumnya berisi informasi biaya awal, yaitu dengan melakukan kembali penyesuaian yang perlu dilakukan, berdasarkan pada penyusutan. d. Ketika menentukan seluruh penggantian biaya karena kegagalan total, pastikan untuk memasukkan didalamnya biaya-biaya yang berhubungan dengan : -
biaya instalasi,
-
biaya troubleshooting,
-
tambahkan 10% untuk biaya lain-lain ,
-
hilangkan jasa bisnis pada outside customers,
-
hilangkan jasa bisnis pada internal employees.
Karakteristik dari Intangible Assets yang cenderung mengganggu sistem informasi adalah sebagai berikut : [1] •
Financial data,
•
R & D research data,
40
•
Goodwill,
•
sales information,
•
marketing research,
•
engineering blueprints and specifications,
•
trade secrets and know-how,
•
computer software.
Terdapat dua karakteristik pendekatan untuk menentukan penilaian Intangible Asset, yaitu sebai berikut. [1] •
Cost Approach: Melakukan pencarian untuk menilai satu market value asset yang cukup jelas, diperhitungkan juga penyusutannya. Hal ini dikenal juga sebagai cost of replacement. Penyusutan karena penggunaan secara fisik, secara fungsional dan perekonomian yang sudah tidak berlaku, harus semua dipertimbangkan dengan seksama. Pendekatan biaya yang tidak secara langsung mempertimbangkan jumlah dari pencapaian manfaat ekonomi atau periode waktu di mana assets akan dilanjutkan. Suatu pendekatan biaya pada umumnya digunakan untuk valuing trade secrets dan know-how.
•
Income Approach: Pusat perhatiannya pada kemampuan income-producing properti intelektual. Nilai itu diukur oleh nilai saat ini dari manfaat ekonomi yang menghubungkan pada keberadaan asset. Ketika kondisi ekonomi tidak dalam keadaan baik, maka pendekatan pendapatan/income mengarah ke suatu penilaian aktiva yang relatif rendah. Karakteristik pendekatan ini, cocok untuk penilaian-penilaian hak paten, merek dagang, software komputer, dan hak cipta.
Dengan selalu menggunakan kedua pendekatan tersebut di atas, pergunakanlah Cost Approach sebagai metoda yang utama, dan karakteristik yang kedua sebagai suatu penentuan kepastian dalam mempergunakan suatu kebijakan. [1] II.2.2.4
Cara Lain Memperkirakan Threat Dan Risk Untuk ALE
Setelah dilakukan penilaian vulnerability dan analisis threat, langkah selanjutnya adalah mengukur elemen resiko. Pada tahap ini, tidak perlu dilakukan perhitungan EF, SLE dan
41
ARO tersendiri, akan lebih mudah jika melakukan perkiraan ALE secara langsung dengan menggunakan data pada sub-bab yang menjelaskan data analisis resiko (tabel II.12). Perlu dilakukan pengaturan tingkatan nomor, dari 1 sampai dengan 10 untuk ukuran kritikal, sebagai faktor koreksi dalam perkiraan resiko yang diperoleh dari tabel II.12. Langkah ini perlu dilakukan, dikarenakan data yang terdapat pada tabel tersebut adalah data umum yang tidak mempertimbangkan perbedaan tingkatan kritis suatu resiko pada setiap organisasi Pergunakan slide rule pada Gambar II.4, untuk menentukan pencocokan adjustment factor dengan severity rangking yang dipilih sebelumnya. Langkah ini dilakukan, dengan alasan untuk meng-konversi nomor tingkat resiko menjadi suatu nilai yang dapat dipergunakan untuk menghitung ALE, dengan rumusan sebagai berikut: ALEcorrected = ALEtable x Adjustment Factor x Size Correction
Gambar II.4 Konversi Tingkat Resiko [1]
II.2.2.5
Data Referensi Analisis Resiko
Sebagai referensi data pada analisis resiko ini, dipergunakan suatu tabel data utama dan data informasi kepemilikan, dengan tujuan agar mempunyai perbandingan dengan kasus analisis resiko yang dibuat. a. Tabel Data Utama Tabel ini merupakan hasil kompilasi dari hasil study dan survey pada industri. Berisikan berbagai macam aspek yang berbeda dari framework keamanan resiko. Dengan menggunakan tabel tersebut, dapat diperkirakan ARO, SLE dan nilai ALE untuk beberapa faktor resiko yang umum. Untuk menggunakan tabel ini, pertama-tama, cocokkan spesifikasi faktor resiko yang memenuhi suatu analisis resikonya. Kedua, identifikasi resiko yang dihubungkan ARO dan data kerugian. Kolom "risk ARO" di dalam tabel berisikan ARO dalam format persentase. Dengan kata lain, 12% dalam kolom "risk ARO" adalah sama dengan 0.12
42
untuk ARO. Kolom "Loss description" berisikan data ALE atau SLE yang tergantung pada suatu situasi. Sebagai tambahan, kata "reported" dalam kolom "Loss Description" menunjukkan bahwa kuantitas yang diperlihatkan adalah jumlah tahunan yang benar-benar dilaporkan pada pemegang otoritas. Oleh karena itu, terdapat suatu implikasi bahwa, pelanggaran keamanan yang nyata, harus lebih dari daftar nilai "reported" dalam kolom ini, karena banyak pelanggaran keamanan yang tidak dideteksi atau tidak dilaporkan. Sebagai kesimpulannya,
diperbolehkan
untuk
menambahkan
"correction
factor"
ketika
menggunakan beberapa data yang diperkenalkan dalam tabel ini untuk memperkirakan ALE. Untuk ALE% yang diperlihatkan pada kolom "Loss description", definisinya adalah ALE% = ALE / Asset Value. Tabel II.12 Data Utama [1] Risk Factor Category email
Reference Source Kabay
Threat/ Risk Description
Risks ARO
financial
Vijayan
credit card fraud
financial
Neumei-ster
credit application info.
financial
CSI
financial fraud
financial
CSI
financial fraud
information
CSI
transaction info. theft
internet
Symantec
web browser privacy
51%
internet
CSI
insiders abuse of access
78%
$ 536,000**
internet
CSI
Denial of Service (DoS)
40%
$ 297,000**
internet
Stephens
laptop
CSI
Denial of Service (DoS) Amazon.com theft of laptop
55%
200,000/hr to 300,000/hr : SLE $ 89,000**
nonproductive emails
$4,000/worker** 115hrs /worker $580/account: SLE$7M/company $90/account: SLE$2.7M/company ALE% : 6% 12%
43
Loss Description
$4,632,000** ALE% :12%
Risk Factor Category laptop network
Reference Source Absolute Protect CSI
network
Tabel II.12 (Lanjutan) Data Utama [1] Threat/ Risk Description Risks ARO theft of laptop
Loss Description
sabotage of data
8%
1 in 14 chance per life s n of l to $ 541,000**
CSI
active wiretapping
1%
$0**
network
Kensington
gross revenue
network
Symantec
NetBIOS availability
20%
overall
Symantec
virus protection ***
28%
overall
Symantec
trojan protection ***
7%
overall
Kabay
outside attacks
overall
Kabay
outside attacks reported
<1% reported
overall
Kabay
attacks detected
4% reported
overall
Kabay
attacks detected (rule ofthumb)
approx. 10%
overall
Kabay
<10%
overall
CSI
attacks reported to authorities (rule of thumb) security breaches
overall
CSI
attacks reported to authorities
34% reported
overall
CSI
attacks not reported
56%
overall
CSI
not report/total incidents
62%
overall
CSI
61%
overall
CSI
survey had companies @ $100M/yr and higher system penetration
40%
$ 226,000**
overall
CSI
security breach losses
42%
$ 2M /company**
overall
Kensington
unprotected data
60%
overall
Pescatore
insider attack on system
70%
overall
pwcglobal. com CSI
benchmark of IT budget dedicated to security virus attacks
proprietary info. proprietary info. proprietary info. proprietary info. system
PC Guardian
trade secret for USA
Kabay
49%
CSI
piracy of software sold on online auction theft of proprietary data
ASIS
theft of proprietary data
40%
CSI
unauthorized insider access
38%
telecom
CSI
telecom fraud
9%
$ 22,000**
telecom
CSI
eavesdropping
6%
$1,205,000**
overall
ALE%: 5.57%
67%
Keterangan * M = million, B = billion ** Data-data ini merupakan nilai ALE *** Sudah diterapkan pada sistem yang telah mempunyai software anti virus
44
90%
3 - 5% of IT budget 85%
$ 283,000** $2B /month
20%
$6,571,000**
$ 300,000**
b.
Data Informasi Kepemilikan
Untuk rincian tentang statistik, dalam hubungannya dengan kerugian informasi kepemilikan, laporan survey ASIS 2002 merupakan sumber informasi yang baik untuk referensi. Pada tabel ini, diperlihatkan perbedaan dalam attitudes dan “best practices” organisasi untuk keamanan sistem informasi berdasarkan pada laporan peristiwa kerugian. Tabel II.13 Hasil Survey Pendapat [1]
Percent Companies Companies not reporting Loss reporting loss Incidents incidents
Attitudes and best practices Information associated with new products and services is vital to the success of our company The internet, network, and computers and related technologies have created significant new threats to sensitive proprietary information Only people with a need to know are given access to sensitive information Information security is a priority within our company Physical security in my location is adequate to safeguard sensitive documents We require to use screen savers or server password to protect computer system when unattended Our company’s policies/guidelines concerning safeguarding sensitive/proprietary information are fit for the purposes for which they were intended Non-disclosure agreements are effectively used in our company Management is concerned about information loss and takes necessary precautions Sensitive information is not seriously at risk in our organization Our company has effective information system security procedures Our company has not discovered vulnerabilities to electronic means of information gathering during assessment of offices and meeting rooms. Our company has not discovered vulnerabilities to electronic means of information gathering during assessment of telecommunications cables and equipment
45
75
73
75
59
40
75
45
71
44
71
47
66
42
69
49
60
36
67
31
66
38
64
49
58
47
53
