BAB II TINJAUAN PUSTAKA

(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]

(2)

Input Risk Assessment Activities Output Hardware, software,

system interfaces, data and information, people, system mission

System boundary, system function, system and data critically, system and data sensitivity

Step 1

System Characterization

History of system

attack Threat identification Step 2

Threat statement Step 3 Vulnerability Identification Step 4 Control analysis Step 5 Likelihood determination Step 6 Impact Analysis List of potential vulnerabilities Step 7 Risk determination Step 8 Control Recommendation Step 9 Results Documentation Data from intelligence

agencies, mass media.

List Of Current and Planned Control

Likelihood Rating

Mission impact analysis, Asset Criticality assessment,

Data Criticality, Data Sensitivity. Threat source Motivation,

Threat Capacity, Nature of Vulnerability,

Current Control. Current control, Planned Control

Risk And Associated Risk Level Impact Rating Likelihood of Threat exploitation, Magnitude of impact Recommended Control Risk Assessment Report

(3)

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, batasan-batasan 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),

(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.

(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 .

(6)

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 - Hacking

- Social engineering

- System intrusion, break-ins - Unauthorized system access Computer criminal Destruction of information

Illegal information disclosure Monetary gain Unauthorized data alteration

- Computer crime (e.g., cyber stalking)

- Fraudulent act (e.g., replay, impersonation, interception) - Information bribery

- Spoofing

- System intrusion

Terrorist Blackmail Destruction

Exploitation Revenge

- Bomb/Terrorism - Information warfare - System attack (e.g.,

distributed denial of service) - System penetration

(7)

Tabel II.1 (Lanjutan) Human threats [2]

Threat-Source Motivation Threat Actions

Industrial espionage (companies, foreign governments, other government interests)

Competitive advantage

Economic espionage - Economic exploitation - Information theft - Intrusion on personal privacy - Social engineering

- System penetration

- Unauthorized system access (access to classified, proprietary, and/or technology-related information) 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)

- 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.1.1.3 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,

(8)

Tabel II.2 Vulnerability/Threats Pairs [2]

Vulnerability Threat-Source Threat Action Terminated employees’ system

identifiers (ID) are not removed from the system

Terminated employees Dialing into the company’s network and accessing company proprietary data Company firewall allows inbound

telnet, and guest ID is enabled on XYZ server

Unauthorized users (e.g., hackers, terminated employees, computer criminals, terrorists)

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

Unauthorized users (e.g., hackers, disgruntled employees, computer criminals, terrorists)

Obtaining unauthorized access to sensitive system files based on known system vulnerabilities Data center uses water sprinklers

to suppress fire; tarpaulins to protect hardware and equipment from water damage are not in place

Fire, negligent persons 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.

(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

(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.

(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 - 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

Operational Security - 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 Technical Security - 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

(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.1.1.5 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,

(13)

Kemungkinan suatu potensi vulnerability dapat dikerjakan dengan dicoba melalui

threat-source 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]

(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,

(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.

Tabel II.5 Magnitude of Impact Definitions. [2] [8]

Magnitude of

Impact Impact Definition

High

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.

Medium

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. Low

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.

(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

mudah Membutuhkan waktu dan biaya

Tidak dapat digunakan untuk analisis cost-benefit Dapat digunakan untuk analisis cost-benefit Unsur subyektif relatif tinggi Unsur subyektif relatif rendah (lebih obyektif) II.1.1.7 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.

(17)

Tabel II.7 Risk-Level Matrix [2]

Impact

Threat Likelihood _{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)

Safeguard effectiveness High (3 ) Med (2 ) Lo w(1) none (0) High (3 ) Med (2 ) Lo w(1) none (0) High (3 ) Med (2 ) Lo w(1) none (0) 1 1 1 1 1 1 1 2 2 1 2 3 3 2 1 1 1 2 1 1 2 3 1 2 3 4 3 1 1 2 3 1 2 3 4 1 3 4 4 4 1 1 3 4 1 2 4 5 2 3 4 5 5 1 2 3 4 1 3 4 5 2 4 5 5 6 1 2 3 4 2 3 4 5 2 4 5 5 7 1 3 4 5 2 4 5 5 3 5 5 5 8 2 4 5 5 2 5 5 5 3 5 5 5 exposure rating 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

(18)

Tabel II.9 Risk Scale and Necessary Actions [2] [8]

Risk Level Risk Description and Necessary Actions

High

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.

Medium 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.

Low

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.1.1.8 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

(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.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.

(20)

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 IT-nya, karena setiap situasi/lingkungan dan objektif organisasi, mempunyai keunikan, pilihan yang digunakan untuk mengurangi resiko dan metode implementasinya dapat disesuaikan.

(21)

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.

(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.

(23)

Input Risk Mitigation Activities Output Risk level from the risk

assessment report _{Prioritize actions}Step 1 Action ranking from high _{to low}

Risk Assessment report Step 2 Evaluate recommended control option • Feasibility • Effectiveness List Of possible controls Step 4 Select Controls Step 5 Assign Responsibility Step 7

Implement Selected Controls

Cost-Benefit Analysis Selected Control List of responsible persons Safeguard implementation plan Step 3

Conduct Cost-benefit Analysis • Impact of not/of

implementing

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

Residual risk

(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]

(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.

(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.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.

(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.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 availability-nya untuk jangka waktu tertentu.

(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.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]

Level of impact resulting from a threat occurrence

Likelihood of occurrence _Low _Medium _High

Low 1 2 4

Medium 3 6 7

(29)

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,

(30)

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.

(31)

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 Description

0% Aset resistant terhadap threat 20% Kerusakan kecil

40% Tingkat kerusakan menengah, akan terjadi delay dalam pekerjaan 60% Tingkat kerusakan besar, pekerjaan sudah mengalami delay 80% Tingkat kerusakan besar, pekerjaan mengalami interupsi

100% 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;

(32)

• 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 langkah-langkah 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,

(33)

• 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

(34)

ARO tersendiri, akan lebih mudah jika melakukan perkiraan ALE secara langsung dengan

menggunakan data pada sub-babyang 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

(35)

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 Reference Source Threat/ Risk Description Risks ARO Loss Description

email Kabay nonproductive emails $4,000/worker** 115hrs /worker financial Vijayan credit card fraud $580/account:

SLE$7M/company financial Neumei-ster credit application info. $90/account:

SLE$2.7M/company financial CSI financial fraud ALE% : 6% financial CSI financial fraud 12% $4,632,000** information CSI transaction info. theft ALE% :12% 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 Denial of Service (DoS)

Amazon.com 200,000/hr to 300,000/hr : SLE laptop CSI theft of laptop 55% $ 89,000**

(36)

Tabel II.12 (Lanjutan) Data Utama [1] Risk Factor

Category Reference Source Threat/ Risk Description Risks ARO Loss Description

laptop Absolute

Protect theft of laptop 1 in 14 chance per life s n of l to network CSI sabotage of data 8% $ 541,000** network CSI active wiretapping 1% $0**

network Kensington gross revenue ALE%: 5.57% network Symantec NetBIOS availability 20%

overall Symantec virus protection *** 28% overall Symantec trojan protection *** 7% overall Kabay outside attacks 67%

overall Kabay outside attacks reported <1% reported overall Kabay attacks detected 4% reported overall Kabay attacks detected (rule ofthumb) approx. 10% overall Kabay attacks reported to authorities (rule

of thumb) <10%

overall CSI security breaches 90%

overall CSI attacks reported to authorities 34% reported overall CSI attacks not reported 56%

overall CSI not report/total incidents 62% overall CSI survey had companies @ $100M/yr

and higher

61%

overall CSI 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 benchmark of IT budget dedicated to security 3 - 5% of IT budget overall CSI virus attacks 85% $ 283,000** proprietary

info. PC Guardian trade secret for USA $2B /month proprietary

info. Kabay piracy of software sold on online auction 49% proprietary

info. CSI theft of proprietary data 20% $6,571,000** proprietary

info. ASIS theft of proprietary data 40%

system CSI unauthorized insider access 38% $ 300,000** telecom CSI telecom fraud 9% $ 22,000** telecom CSI eavesdropping 6% $1,205,000** Keterangan

* M = million, B = billion

** Data-data ini merupakan nilai ALE

(37)

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 Attitudes and best practices Companies

reporting Loss Incidents

Companies not reporting loss

incidents Information associated with new products and

services is vital to the success of our company 75 73

The internet, network, and computers and related technologies have created significant new threats to sensitive proprietary information

75 59 Only people with a need to know are given access to

sensitive information 40 75

Information security is a priority within our company 45 71

Physical security in my location is adequate to

safeguard sensitive documents 44 71