13
BAB 2
LANDASAN TEORI
2.1 Manajemen Risiko
Menurut COSO ERM(2004) , risk management (manajemen risiko) dapat
diartikan sebagai ‘a process, effected by an entity’s board of directors,
management and other personnel, applied in strategy setting and across the
enterprise, designed to identify potential events that may affect the entity,
manage risk to be within its risk appetite, and provide reasonable assurance
regarding the achievement of entity objectives.’
Dari definisi risk management diatas dapat kita artikan menjadi beberapa
bagian yaitu :
a. On going process
Risk management dilaksanakan secara terus menerus dan dimonitor
secara berkala. Risk management bukanlah suatu kegiatan yang
dilakukan sesekali (one time event).
b. Effected by people
Risk management ditentukan oleh pihak-pihak yang berada di
lingkungan organisasi. Untuk lingkungan institusi Pemerintah, risk
management dirumuskan oleh pimpinan dan pegawai institusi/departemen
yang bersangkutan.
14
c. Applied in strategy setting
Risk management telah disusun sejak dari perumusan strategi
organisasi oleh manajemen puncak organisasi. Dengan penggunaan risk
management, strategi yang disiapkan disesuaikan dengan risiko yang
dihadapi oleh masing-masing bagian/unit dari organisasi.
d. Applied across the enterprise
Strategi yang telah dipilih berdasarkan risk management
diaplikasikan dalam kegiatan operasional, dan mencakup seluruh
bagian/unit pada organisasi. Mengingat risiko masing-masing bagian
berbeda, maka penerapan risk management berdasarkan penentuan risiko
oleh masing - masing bagian.
e. Designed to identify potential events
Risk management dirancang untuk mengidentifikasi kejadian atau
keadaan yang secara potensial menyebabkan terganggunya
pencapaian tujuan organisasi.
f. Provide reasonable assurance
Risiko yang dikelola dengan tepat dan wajar akan menyediakan
jaminan bahwa kegiatan dan pelayanan oleh organisasi dapat berlangsung
secara optimal.
15
g. Geared to achieve objectives
Risk management diharapkan dapat menjadi pedoman bagi
organisasi dalam mencapai tujuan yang telah ditentukan.
2.1.1 Fungsi-Fungsi Pokok Manajemen Risiko
Menurut Djojosoedarso (2005, p14) , fungsi pokok manajemen risiko
terdiri dari:
1. Menemukan Kerugian Potensial
Artinya berupaya untuk menemukan atau mengidentifikasi seluruh
risiko murni yang dihadapi perusahaan, yang meliputi:
a. Kerusakan fisik dari harta kekayaan perusahaan.
b. Kehilangan pendapatan atau kerugian lainnya akibat terganggunya
operasi perusahaan.
c. Kerugian akibat adanya tuntutan hukuman dari pihak lain.
d. Kerugian-kerugian yang timbul karena penipuan, tindakan-tindakan
kriminal lainnya, tidak jujurnya karyawan.
e. Kerugian-kerugian yang timbul akibat karyawan kunci (keymen)
meninggal dunia, sakit atau cacat.
16
2. Mengevaluasi Kerugian Potensial
Artinya melakukan evaluasi dan penilaian terhadap semua kerugian
potensial yang dihadapi oleh perusahaan. Evaluasi dan penilaian ini akan
meliputi perkiraan mengenai:
a. Besarnya kemungkinan frekuensi terjadinya kerugian artinya
memperkirakan jumlah kemungkinan terjadinya kerugian selama suatu
periode tertentu atau berapa kali terjadinya kerugian tersebut selama
suatu periode tertentu.
b. Besarnya bahaya dari tiap-tiap kerugian, artinya menilai besarnya
kerugian yang diderita, yang biasanya dikaitkan dengan besarnya
pengaruh kerugian tersebut, terutama terhadap kondisi financial
perusahaan.
3. Memilih teknis/cara yang tepat atau menentukan suatu kombinasi dari
teknik-teknik yang tepat guna menanggulangi kerugian.
Pada pokoknya ada empat cara yang dapat dipaki untuk menanggulangi
risiko, yaitu mengurangi kesempatan terjadinya kerugian, meretensi,
mengasuransikan, dan meghindari. Di mana tugas dari manajer risiko adalah
memilih satu cara yang paling tepat untuk menanggulangi suatu risiko atau
memilih suatu kombinasu dari cara-cara yang paling tepat untuk
menanggulangi risiko.
17
2.1.2 Risiko
Menurut Djojosoedarso (2003, p2), menguraikan pengertian risiko dari
beberapa ahli, yaitu: (1) menurut Arthur Williams dan Richard, M.H, risiko
adalah suatu variasi dari hasil-hasil yang dapat terjadi selama periode tertentu-
tertentu; (2) menurut A.Abas Salim, risiko adalah ketidakpastian (uncertainty)
yang mungkin melahirkan peristiwa kerugian (loss); (3) menurut Soekarto, risiko
adalah ketidakpastian atas terjadinya suatu peristiwa (4) menurut Herman
Darmawi, risiko merupakan penyebaran/penyimpangan hasil aktual dari hasil
yang diharapkan. Atau diartikan risiko adalah probabilitas sesuatu hasil/outcome
yang berbeda dengan yang diharapkan.
Definisi-definisi tersebut dapat disimpulkan bahwa risiko selalu
dihubungkan dengan kemungkinan terjadinya sesuatu yang merugikan yang tidak
diduga/tidak diinginkan.
2.1.3 Bentuk-Bentuk Risiko
Menurut Djojosoedarso (2005, p3-p4), risiko dapat dibedakan dengan
berbagai macam cara antara lain:
1. Menurut sifatnya risiko dapat dibedakan kedalam:
a. Risiko yang tidak disengaja (risiko murni) adalah risiko yang apabila
terjadi tentu menimbulkan kerugian dan terjadinya tanpa disengaja;
misalnya risiko terjadinya kebakaran, bencana alam, pencurian,
penggelapan, pengacauan, dan sebagainya.
18
b. Risiko yang disengaja (risiko spekulatif) adalah risiko yang disengaja
ditimbulkan oleh yang bersangkutan, agar terjadinya ketidakpastian
memberikan keuntungan kepadanya, misalnya risiko utang-piutang,
perjudian, perdagangan berjangka (hedging), dan sebagainya.
c. Risiko fundamental adalah risiko yang penyebabnya tidak dapat
dilimpahkan kepada seseorang dan yang menderita tidak hanya satu atau
beberapa orang saja, tetapi banyak orang, seperti banjir, angin topan, dan
sebagainya.
d. Risiko khusus adalah risiko yang bersumber pada peristiwa yang mandiri
dan umumnya mudah diketahui penyebabnya, seperti kapal kandas,
pesawat jatuh, tabrakan mobil, dan sebagainya.
e. Risiko dinamis adalah risiko yang timbul karena perkembangan dan
kemajuan (dinamika) masyarakat di bidang ekonomi, ilmu dan teknologi,
seperti risiko keuangan dan risiko penerbangan luar angkasa.
Kebalikannya adalah risiko statis, contohnya seperti risiko hari tua dan
juga risiko kematian.
2. Dapat tidaknya risiko tersebut dialihkan kepada pihak lain, maka risiko
dapat dibedakan kedalam:
a. Risiko yang dapat dialihkan kepada pihak lain, dengan
mempertanggungkan suatu objek yang mana akan terkena risiko
kepada perusahaan asuransi, dengan membayar sejumlah premi
asuransi.
19
b. Risiko yang tidak dapat dialihkan kepada pihak lain (tidak dapat
diasuransikan); umumnya meliputi semua jenis risiko spekulatif
3. Menurut sumber/penyebab timbulnya, risiko dapat dibedakan ke dalam:
a. Risiko intern yaitu risiko yang berasal dari dalam perusahaan itu
sendiri, seperti kerusakan aktiva karena ulah karyawan, kecelakaan
kerja, kesalahan manajemen dan sebagainya.
b. Risiko ekstern yaitu risiko yang berasal dari luar perusahaan, seperti
risiko pencurian, penipuan, persaingan, fluktuasi harga, perubahan
kebijakan pemerintah, dan sebagainya.
2.1.4 Penanggulangan Risiko
Menurut Djojosoedarso (2005, p4), upaya-upaya untuk menanggulangi
risiko harus selalu dilakukan, sehingga kerugian dapat dihindari atau
diminimumkan. Sesuai dengan sifat dan objek yang terkena risiko, ada beberapa
cara yang dapat dilakukan perusahaan untuk meminimumkan risiko kerugian,
antara lain:
1. Melakukan pencegahan dan pengurangan terhadap kemungkinan terjadinya
peristiwa yang menimbulkan kerugian.
2. Melakukan retensi, artinya mentolerir membiarkan terjadinya kerugian, dan
untuk mencegah terganggunya operasi perusahaan akibat kerugian tersebut
disediakan sejumlah dana untuk menanggulanginya.
20
3. Melakukan pengendalian terhadap risiko.
4. Mengalihkan/memindahkan risiko kepada pihak lain.
2.2 Proses Manajemen Risiko
Pemahaman risk management memungkinkan manajemen untuk terlibat
secara efektif dalam menghadapi uncertainty dengan risiko dan peluang yang
berhubungan dan meningkatkan kemampuan organisasi untuk memberikan nilai
tambah. Menurut COSO ERM(2004), proses manajemen risiko dapat dibagi ke
dalam 8 komponen (tahap). Sebagaimana dijelaskan pada Gambar 3, komponen-
komponen dari risiko dapat dijelaskan sebagai
berikut:
Gambar 2.1 Risk Management Model Coso
21
1. Internal environment (Lingkungan internal)
Komponen ini berkaitan dengan lingkungan dimana instansi
Pemerintah berada dan beroperasi. Cakupannya adalah risk-management
philosophy (kultur manajemen tentang risiko), integrity (integritas), risk-
perspective (perspektif terhadap risiko), risk-appetite (selera atau
penerimaan terhadap risiko), ethical values (nilai moral), struktur
organisasi, dan pendelegasian wewenang.
2. Objective setting (Penentuan tujuan)
Manajemen harus menetapkan objectives (tujuan-tujuan) dari
organisasi agar dapat mengidentifikasi, mengakses, dan mengelola risiko.
Objective dapat diklasifikasikan menjadi strategic objective dan activity
objective. Strategic objective di instansi Pemerintah berhubungan dengan
pencapaian dan peningkatan kinerja instansi dalam jangka menengah dan
panjang, dan merupakan implementasi dari visi dan misi instansi tersebut.
Sementara itu, activity objective dapat dipilah menjadi 3 kategori, yaitu (1)
operations objectives; (2) reporting objectives; dan (3) compliance
objectives.
Sumber daya manusia (SDM) yang dimiliki organisasi yang ada pada
seluruh divisi dan bagian haruslah dilibatkan dan mengerti risiko yang
dihadapi. Penglibatan tersebut terkait dengan pandangan bahwa setiap
pejabat/pegawai adalah pemilik dari risiko. Demikian pula, dalam
penentuan tujuan organisasi, hendaknya menggunakan pendekatan
22
SMART , dan ditentukan risk appetite and risk tolerance (variasi dari
tujuan yang dapat diterima)
Risk tolerance dapat diartikan sebagai variation dalam pencapaian
objective yang dapat diterima oleh manajemen. Dalam penerapan
pelayanan pajak modern seperti pengiriman SPT WP secara elektronik,
diperkirakan 80% Wajib Pajak (WP) Besar akan
mengimplementasikannya. Bila ditentukan risk tolerance sebesar 10%,
dalam hal 72% WP Besar telah melaksanakannya, berarti tujuan
penyediaan fasilitas tersebut telah terpenuhi. Disamping itu, terdapat pula
aktivitas suatu organisasi seperti peluncuran roket berawak dengan risk
tolerance adalah 0%.
3. Event identification (Identifikasi risiko)
Komponen ini mengidentifikasi kejadian-kejadian potensial baik
yang terjadi di lingkungan internal maupun eksternal organisasi yang
mempengaruhi strategi atau pencapaian tujuan dari organisasi. Kejadian
tersebut bisa berdampak positif (opportunities), namun dapat pula
sebaliknya atau negative (risks).
Terdapat 4 model dalam identifikasi risiko, yaitu (1) Exposure
analysis; (2) Environmental analysis; (3) Threat scenario; (4)
Brainstorming questions. Salah satu model, yaitu exposure analysis,
mencoba mengidentifikasi risiko dari sumber daya organisasi yang meliputi
financial assets seperti kas dan simpanan di bank, physical assets seperti
23
tanah dan bangunan, human assets yang mencakup pengetahuan dan
keahlian, dan intangible assets seperti reputasi dan penguasaan informasi.
Atas setiap sumber daya yang dimiliki organisasi dilakukan penilaian risiko
kehilangan dan risiko penurunan (lihat Tabel 2.1).
Tabel 2.1 Tabel Identifikasi Risiko pada Barang Modal
Size, type, portability,
location (STPL)
Lost Risk Risk Value
Kecil, bernilai, dan
portable
Pencurian, kebakaran,
handling
Handling
Besar, bernilai,
portable
Pencurian, kebakaran,
handling
Handling, dust, fluktuasi
power
Besar, bernilai, tidak
portable
Kebakaran, handling Handling, dust, fluktuasi
power
4. Risk assessment (Penilaian risiko)
Komponen ini menilai sejauhmana dampak dari events (kejadian atau
keadaan) dapat mengganggu pencapaian dari objectives. Besarnya dampak
dapat diketahui dari inherent dan residual risk, dan dapat dianalisis dalam
dua perspektif, yaitu: likelihood (kecenderungan atau peluang) dan
impact/consequence (besaran dari terealisirnya risiko). Dengan demikian,
besarnya risiko atas setiap kegiatan organisasi merupakan perkalian antara
likelihood dan consequence.
Penilaian risiko dapat menggunakan dua teknik, yaitu: (1) qualitative
techniques; dan (2) quantitative techniques. Qualitative techniques
24
menggunakan beberapa tools seperti self-assessment (low, medium, high),
questionnaires, dan internal audit reviews. Sementara itu, quantitative
techniques data berbentuk angka yang diperoleh dari tools seperti
probability based, non-probabilistic models (optimalkan hanya asumsi
consequence), dan benchmarking.
Sebagaimana dijelaskan pada Gambar 2.2, penilaian risiko atas setiap
aktivitas organisasi akan menghasilkan informasi berupa peta dan angka
risiko. Aktivitas yang paling kecil risikonya ada pada aktivitas a dan e, dan
aktivitas yang paling berisiko tinggi dengan kemungkinan terjadi tinggi ada
pada aktivitas d. Sedangkan aktivitas c, walaupun memiliki dampak yang
besar, namun memiliki risiko terjadi yang rendah.
Gambar 2.2 Map & Quantify Risk
25
Yang perlu dicermati adalah events relationships atau hubungan antar
kejadian/keadaan. Events yang terpisah mungkin memiliki risiko kecil.
Namun, bila digabungkan bisa menjadi signifikan. Demikian pula, risiko
yang mempengaruhi banyak business units perlu dikelompokkan dalam
common event categories, dan dinilai secara aggregate.
5. Risk response (Sikap atas risiko)
Organisasi harus menentukan sikap atas hasil penilaian risiko. Risk
response dari organisasi dapat berupa: (1) avoidance, yaitu dihentikannya
aktivitas atau pelayanan yang menyebabkan risiko; (2) reduction, yaitu
mengambil langkah-langkah mengurangi likelihood atau impact dari risiko;
(3) sharing, yaitu mengalihkan atau menanggung bersama risiko atau
sebagian dari risiko dengan pihak lain; (4) acceptance, yaitu menerima
risiko yang terjadi (biasanya risiko yang kecil), dan tidak ada upaya khusus
yang dilakukan. Strategi dalam memilih risiko dijelaskan pada Gambar 2.3
Gambar 2.3 Strategy for Managing Risk
26
Dalam memilih sikap (response), perlu dipertimbangkan faktor-faktor
seperti pengaruh tiap response terhadap risk likelihood dan impact,
response yang optimal sehingga bersinergi dengan pemenuhan risk appetite
and tolerances, analis cost versus benefits, dan kemungkinan peluang
(opportunities) yang dapat timbul dari setiap risk response.
6. Control activities (Aktifitas-aktifitas pengendalian)
Komponen ini berperanan dalam penyusunan kebijakan-kebijakan
(policies) dan prosedur-prosedur untuk menjamin risk response terlaksana
dengan efektif. Aktifitas pengendalian memerlukan lingkungan
pengendalian yang meliputi: (1) integritas dan nilai etika; (2) kompetensi;
(3) kebijakan dan praktik-praktik SDM; (4) budaya organisasi; (5) filosofi
dan gaya kepemimpinan manajemen; (6) struktur organisasi; dan (7)
wewenang dan tanggung jawab.
Dari pemahaman atas lingkungan pengendalian, dapat ditentukan
jenis dan aktifitas pengendalian. Terdapat beberapa jenis pengendalian,
diantaranya adalah preventive, detective, corrective, dan directive.
Sementara aktifitas pengendalian berupa: (1) pembuatan kebijakan dan
prosedur; (2) pengamanan kekayaan organisasi; (3) delegasi wewenang dan
pemisahan fungsi; dan (4) supervisi atasan. Aktifitas pengendalian
hendaknya terintegrasi dengan manajemen risiko sehingga pengalokasian
sumber daya yang dimiliki organisasi dapat menjadi optimal.
27
7. Information and communication (Informasi dan komunikasi)
Fokus dari komponen ini adalah menyampaikan informasi yang
relevan kepada pihak terkait melalui media komunikasi yang sesuai.
Faktor-faktor yang perlu diperhatikan dalam penyampaiaan informasi dan
komunikasi adalah kualitas informasi, arah komunikasi, dan alat
komunikasi.
Informasi yang disajikan tergantung dari kualitas informasi yang
ingin disampaikan, dan kualitas informasi dapat dipilah menjadi: (1)
appropriate; (2) timely; (3) current; (4) accurate; dan (5) accessible. Arah
komunikasi dapat bersifat internal dan eksternal. Sedangkan alat
komunikasi berupa diantaranya manual, memo, buletin, dan pesan-pesan
melalui media elektronis.
8. Monitoring
Monitoring dapat dilaksanakan baik secara terus menerus (ongoing)
maupun terpisah (separate evaluation). Aktifitas monitoring ongoing
tercermin pada aktivitas supervisi, rekonsiliasi, dan aktivitas rutin lainnya.
Monitoring terpisah biasanya dilakukan untuk penugasan tertentu
(kasuistis). Pada monitoring ini ditentukan scope tugas, frekuensi, proses
evaluasi metodologi, dokumentasi, dan action plan.
Pada proses monitoring, perlu dicermati adanya kendala seperti
reporting deficiencies, yaitu pelaporan yang tidak lengkap atau bahkan
28
berlebihan (tidak relevan). Kendala ini timbul dari berbagai faktor seperti
sumber informasi, materi pelaporan, pihak yang disampaikan laporan, dan
arahan bagi pelaporan.
2.3 Teknologi Informasi
Indrajit(2000,p6)
Teknologi informasi adalah suatu teknologi yang berhubungan dengan
pengolahan data menjadi informasi dan proses penyaluran data / informasi
tersebut dalam batas-batas ruang dan waktu
Thompson dan Baril (2003, p3)
Teknologi informasi adalah perangkat keras dan perangkat lunak yang
dikemas sebagai suatu alat untuk menangkap, menyimpan, memproses,
dan menghasilkan digital.
Haag, Cummings, dan McCubbrey (2005, p14) .
Teknologi informasi adalah computer apa saja yang berbasis perangkat
yang digunakan orang (people) untuk berkerja dengan informasi dan
mendukung informasi dan kebutuhan proses informasi dari sebuah organisasi
Jadi pengertian teknologi informasi adalah alat yang berupa hardware,
software, dan jaringan komunikasi yang mendukung aktifitas dari sebuah sistem
informasi
29
2.4 Risiko Teknologi Informasi
Teknologi informasi mempunyai risiko yang tidak dapat dihindari.
Dengan mengetahui risiko-risiko yang ada pada teknologi informasi, perusahaan
dapat mengenal lebih jauh risiko-risiko dan kerugian yang ditimbulkan.
2.4.1 Tahap Manajemen Risiko Teknologi Informasi
Menurut Jordan dan Silcock (2005, p62), jalan kehidupan manajemen
risiko terdiri dari beberapa tahap berikut, ditempatkan dengan cara yang berbeda
untuk jenis risiko yang berbeda:
1. Pengenalan/penemuan-menaruh risiko teknologi informasi pada radar
manajemen.
2. Penilaian/analisis-mengerti risiko informasi teknologi dalam konteks tas
surat keseluruhan risiko informasi teknologi dan menilai kemungkinan
munculnya dan pengaruhnya pada bisnis.
3. Perawatan-menentukan pilihan terbaik dari beberapa langkah tindakan yang
memungkinkan untuk mengatasi risiko, merencanakan, dan
menyelesaikan tindakan yang diperlukan.
4. Pengamatan dan peninjauan-menindak lanjuti untuk memastikan apa yang
direnacakan itu dikerjakan dan mengerti perubahan yang ada pada tas
surat risiko teknologi informasi.
30
2.4.2 Kategori Risiko Teknologi Informasi
Menurut Hughes(2006) “...Information technology risks either concern
the potential loss of information and its recovery, or they concern the ongoing
usage of information. They fall into the following six major categories
1. Security.
Risk that information is altered or used by nonauthorized people.
This includes computer crimes, internal breaches and cyberterrorism.
2. Availability.
Risk that data is not accessible, such as after a system failure, due to
human error, configuration changes, lack of redundancy in architectures
or other causes.
3. Recoverability.
The risk that necessary information cannot be recovered in sufficient
time after a security or availability incident such as hardware and/or
software failure, external threats or natural disasters.
4. Performance.
The risk that information is not provided when it is needed thanks to
distributed architectures, peak demand and heterogeneity in the IT
landscape.
31
5. Scalability.
The risk that business growth, provisioning bottlenecks and siloed
architectures make it impossible to handle major new applications and
businesses cost effectively.
6. Compliance.
Risk that the management or usage of information violates regulatory
requirements. The culprits here include government regulations, corporate
governance guidelines and internal policies...”
1. Keamanan
Risiko yang informasinya diubah atau digunakam oleh orang yang
tidak berotoritas. Ini termasuk kejahatan computer, kebocoran internal dan
terorisme cyber.
2. Ketersediaan
Risiko yang datanya tidak dapat diakses, seperti setelah kegagalan
sistem, karena kesalahan manusia, perubahan konfigurasi, kurangnya
pengurangan arsitektur atau akibat lainnya.
3. Daya Pulih
Risiko di mana informasi yang diperlukan tidak dapat dipulihkan
dalam waktu yang cukup setelah sebuah kejadian keamanan atau
32
ketersediaan seperti kegagalan perangkat lunak atau keras, ancaman
eksternal, atau bencana alam
4. Performa
Risiko di mana informasi tidak tersedia saat diperlukan yang
diakibatkan oleh arsitektur terdistribusi, permintaan yang tinggi dan
topografi informasi teknologi yang beragam.
5. Daya Skala
Risiko yang perkembangan bisnis, pengaturan bottleneck, dan bentuk
arsitekturnya membuatnya tidak mungkin menangani banyak aplikasi baru
dan biaya bisnis efektif.
6. Ketaatan
Risiko yang manajemen atau penggunaan informasinya melanggar
keperluan regulator. Yang dipersalahkan dalam hal ini mencakup regulasi
pemerintah panduan pengaturan korporat dan kebijakan internal.
2.4.3 Kelas – Kelas Risiko Teknologi Informasi
Menurut Jordan dan Silcock (2005, p49), risiko-risiko teknologi
didefinisikan dalam 7 kelas, dimana pada setiap kasus, teknologi informasi dapat
juga melakukan kesalahan, tetapi konsekuensi-konsekuensinya dapat berakibat
negatif bagi bisnis.
33
Kelas – kelas risiko antara lain adalah:
1. Projects – failing to deliver
Risiko ini bersangkutan dengan gagalnya suatu proyek TI. Beberapa
contoh dari gagalnya penyampaian proyek adalah: menyelesaikan proyek
yang ada telat/tidak pada waktunya, sumber daya dan biaya yang
dikonsumsi dalam penyelesaian proyek besar sehingga tidak efisien,
mengganggu proses bisnis selama proses implementasi, dan juga fungsi
dari proyek tidak sesuai dengan keinginan dari yang diharapkan user.
2. IT Service continuity-when business operations go off the air
Risiko ini berhubungan dengan pelayanan TI yang ketinggalan jaman
dan tidak dapat diandalkan sehingga menggangu proses bisnis yang sedang
berjalan. Biasanya berhubungan dengan sistem operasional dan produksi
perusahaan serta kemampuan mereka untuk meyediakan kebutuhan dari
user.
3. Information assets – failing to protect and preserve
Risiko ini berhubungan khusus dengan kerusakan, kehilangan, dan
eksploitasi aset informasi yang ada dalam sistem. Dampaknya biar sangat
fatal bagi perusahaan, contohnya informasi yang penting bisa dicuri oleh
perusahaam kompetitor, detail dari kartu kredit dapat dilihat oleh pihak
yang tidak berwenang, sehingga dengan demikian akan merusak hubungan
antara pelanggan dengan perusahaan. Ini tentunya akan sangat merugikan.
34
4. Service providers and vendors – breaks in the IT value chain
Risiko ini berhubungan dengan kemampuan dari provider dan
vendor. Bila mereka gagal dalam meyediakan pelayanan yang baik bagi
kita, maka akan berdampak signifikan bagi sistem TI perusahaan. Dampak
lainnya behubungan dengan dampak jangka panjang seperti kekurangan
dalam penyediaan layanan TI bagi user perusahaan tersebut.
5. Applications – flaky systems
Risiko ini berhubungan dengan kegagalan aplikasi TI yang
diterapkan. Aplikasi biasanya berinteraksi dengan user dan dalam suatu
perusahaan biasanya terdapat kombinasi antara software paket software
buatan yang diintegrasikan menjadi satu.
6. Infrastructure – shaky foundations
Risiko ini berhubungan dengan kegagalan dalam infrastruktur TI.
Infrastruktur adalah suatu nama yang umum bagi computer maupun
jaringan yang sedang dipakai dan berjalan di perusahaan tersebut. Di dalam
infrastruktur juga termasuk software, seperti sistem operasi dan sistem
database management.
Kegagalan infrastruktur TI bisa bersifat permanen, ketika suatu
komponen terbakar, dicuri, rusak maupun konekso jaringannya sedang
putus, maka dampak dari kegagalan tersebut bergantung dari ketahanan
sistem yang ada. Apabila terdapat sistem yang sudang tidak kompatibel
35
dengan model yang baru, mana sistem tersebut perlu diganti. Apabila risiko
ini dapat ditangani secara rutin, maka itu merupakan suatu perencanaan
jangka panjang yang baik.
7. Strategic and emergent – disabled by IT
Risiko ini berhububgan dengan kemampuan TI untuk
memberitahukan strategi bisnis yang dilakukan. Dampak pelaksanaan
bisnis secara luas. Risiko merupakan kemampuan dari perusahaan untuk
terus bergerak maju kearah visi strategi. Untuk tetap kompetitif diperlukan
kemajuan TI untuk dipahami dan dicocokkan dengan potensi kesempatan
eksploitasi bagi bisnis.
2.4.4 Langkah Pemecahan Risiko Teknologi Informasi
Menurut Jordan dan Silcock (2005, p7), ada tiga langkah kunci dalam
membuat risiko informasi teknologi berjalan, antara lain adalah:
1. Penempatan kepemimpinan dan manajemen yang tepat pada tempatnya
melalui teknologi informasi dan kerangka cara pengaturan risiko.
2. Penggabungan cara anda mengurus risiko informasi teknologi dengan
mengadopsi sebuah pendekatan manajemen tas surat yang proaktif.
3. Pengaturan kompleksitas dengan secara aktif mengatur setiap jenis risiko
informasi teknologi.
36
2.5 Komponen Teknologi Informasi
Menurut Haag, Cummings, dan McCubbrey (2005, p15), ada 2 kategori
dasar dalam teknologi yaitu hardware, software.
1. Hardware (HW)
Menurut O’Brein (2005, p.702), Hardware adalah (1) mesin dan
media; (2) perlengkapan fisik, kebalikan dari program komputer atau
metode penggunaan; (3) peralatan mekanis, magnetis, elektrik, elektronik,
atau optikal.
Disimpulkan bahwa hardware adalah peralatan fisik yang membentuk
suatu sistem komputer dan segala perlengkapan yang berhubungan
dengannya. Hardware dibagi menjadi 6 kategori, yaitu:
a. Input device
Input divice adalah peralatan yang digunakan untuk memasukan
informasi dan perintah yang terdiri dari keyboard, mouse, touch screen,
game controller, dan bar code reader.
b. Output device
Output device adalah peralatan yang digunakan untuk melihat,
mendengar, atau sebaliknya mengenali hasil dari permintaan proses
informasi yang terdiri dari printer, monitor, dan speaker. Storage divice
adalah peralatan yang digunakan untuk menyimpan informasi yang
37
digunakan di lain waktu terdiri atas hard disk, flash memory card, dan
DVD.
c. CPU
CPU adalah hardware yang mengartikan dan menjalankan sistem dan
instruksi-instruksi aplikasi software dan mengatur pengoperasian dari
keseluruhan hardware.
d. RAM
RAM adalah sebuah kawasan sementara untuk informasi yang
bekerja seperti halnya system, dan instruksi aplikasi software yang
dibutuhkan oleh CPU sekarang ini.
e. Telecommunications divice
Telecommunications divice peralatan yang digunakan untuk
mengirim dan menerima informasi dari orang atau komputer lain dalam
satu jaringan, contohnya modem.
f. Connecting divice
Connecting divice termasuk hal-hal seperti terminal paralel yang
menghubungkan printer, kabel penghubung yang menghubungkan printer
ke terminal paralel dan peralatan penghubung internal yang sebagian besar
termasuk alat pengantar untuk perjalanan informasi dari saru bagian
hardware ke bagian lainnya.
38
2. Software (SW)
Menurut O’Brein (2005, p.713), Software adalah program dan
prosedur komputer yang berkaitan dengan operasi sistem informasi.
Ada 2 tipe utama software, yaitu application dan system. Application
software memungkinkan untuk menyelesaikan masalah-masalah spesifik
atau menampilkan tugas-tugas spesifik. System software yaitu menangani
tugas-tugas spesifik untuk mengelola teknologi dan mengatur interaksi dari
keseluruhan peralatan teknologi.
Di dalam system software ditemukan operating system software dan
utility software. Operating system software adalah software sistem yang
mengendalikan software aplikasi dan mengelola bagaimana peralatan
hardware bekerja bersama-sama. Utility Software adalah software yang
menyediakan tambahan fungsionalitas untuk mengoperasikan sistem
software, seperti antivirus software, screen savers, disk optimization
software.
2.6 Keuntungan Management risiko TI
Menurut Erik(2009) “...The IT risk management process has four chief
benefits: it creates a scope for IT risk assessments; it allows for the assessment of
key risk indicators; it provides the basis for automation; and it creates the ability
to baseline risks.
39
Consider first the availability of an IT scope for risk assessments. Often,
the basis for executing a risk assessment - the list of IT objects to be assessed - is
either unavailable or unreliable because it is out of date or incomplete. This is
the IT scope of the assessment without which risk cannot be assessed. The IT
scope needs to contain sufficient detail for assessing risk - usually an inventory
of applications, how they support the business, how they are related (what
information flows between them) and their internal architecture, depending on
how the assessment is to be executed and the objective of the assessment.
But this is exactly the information that constitutes the current architecture
description that enterprise architecture and IT strategic planning teams use. A
good enterprise architecture practice will have this available, up-to-date and
actualized as changes to project plans and the IT landscape occur.
The first conclusion is that the IT scope for risk assessments may already
be in place and, by making it available to IT risk management projects, much
time and effort can be saved. Indeed, typically 15% of assessment costs may go
into initially documenting the IT scope. But if this vital architecture is not
available, establishing and maintaining it will give both IT planners and IT risk
managers an essential tool with which to work.
This reuse of basic information on the IT landscape and how it supports
the business is a logical and efficient thing to do, but may face challenges.
Cultural differences between IT planners and IT risk teams, along with different
understandings of what makes up an application, can be barriers to achieving
40
this goal, but they are barriers that need to be overcome. The different parts of IT
and business need to have a common view of the IT landscape to be able to
effectively plan programs and manage risk.
To establish and maintain the IT scope, organizations require both the
information on the IT scope and processes in place to ensure its accuracy. They
also require a tool that can maintain it. Such tools offer important features such
as workflow support, quality monitors and wizards to ensure that the IT scope is
maintained and up to date. But they also offer other features that support the IT
risk management effort.
Most notably they deliver the ability to assess key risk indicators for
objects of the IT infrastructure and abstract them to the business architecture,
providing business managers with statements on the risk exposure to processes,
organizations and capabilities. This second benefit is essential to understanding
the impacts of changes to the IT infrastructure on the risk posture of the business
- or to highlight the risks of leaving IT as it is. This type of tool support also
reduces risk management costs as abstracting key risk indicators to the business
level is, if done manually, time consuming and error prone.
The third benefit provided by having an established and maintained IT
scope from the enterprise architecture and IT planning teams is that it provides
the basis for automation. Business rule-based surveying capabilities provides the
IT risk management project with the ability to automatically send risk assessment
surveys as required to the right person (or group) for each and every facet of the
41
IT scope. Further benefits include the ability to assign deputies in absence of the
responsible person and to monitor the assessment escalating the issue when the
people responsible for assessing objects do not respond in time.
Consolidation and evaluation of the responses in the root further reduces
the manual effort involved. This leads not only to direct cost savings, but is also
more reliable than consolidating spreadsheets - by which errors are easily made.
Additionally, being supported by such tools makes it easier to convince external
auditors that the risk assessment has been done with the necessary due diligence,
potentially reducing the cost of the audit.
The last benefit considered here is the ability to baseline risks. This is
typically the goal of a mature IT risk management discipline. Currently, risk
assessments are generally done according to the audit cycle. This, however,
means that organizations are running risk assessments more often than
necessary. More importandy, this also means that in the gap between risk
assessments, new risks may be introduced to the organization without anyone's
knowledge due to the lack of risk assessment in IT planning procedures...”
Proses manajemen risiko TI memiliki 4 keuntungan utama: Membuat
ruang lingkup untuk pengukuran risiko TI; Memungkinkan untuk melakukan
pengukuran dengan indikator risiko utama; Menyediakan dasar otomatisasi; dan
membuat kemampuan untuk risiko dasar.
Pertimbangan pertama adalah ketersediaan ruang lingkup TI untuk
pengukuran risiko. Sering kali, dasar untuk melaksanakan pengukuran risiko -
42
daftar objek TI yang akan dinilai - adalah baik tidak tersedia atau tidak dapat
diandalkan karena sudah ketinggalan zaman atau tidak lengkap. Ruang lingkup
pengukuran TI tanpa risiko tidak dapat dinilai. Ruang lingkup TI harus berisi
detail yang cukup untuk menilai risiko - biasanya inventarisasi aplikasi,
bagaimana mereka mendukung bisnis, bagaimana mereka terkait (apa arus
informasi di antara mereka) dan arsitektur internal mereka, tergantung pada
bagaimana pengukuran itu harus dilaksanakan dan tujuan pengukuran.
Tapi inilah informasi yang merupakan gambaran arsitektur saat ini bahwa
arsitektur enterprise dan tim perencanaan strategis TI digunakan. Sebuah praktik
perusahaan yang baik akan memiliki arsitektur ini tersedia, up-to-date dan
teraktualisasikan sebagai perubahan pada rencana proyek dan lanskap TI terjadi.
Kesimpulan pertama adalah bahwa ruang lingkup TI untuk pengukuran
risiko mungkin sudah tersedia dan, dengan membuatnya tersedia dengan risiko
manajemen proyek, maka akan menghemat banyak waktu dan tenaga. Memang,
biasanya 15% dari biaya pengukuran biasanya masuk ke mendokumentasikan
ruang lingkup IT. Tapi ini penting, kalau arsitektur tidak tersedia, membangun
dan mempertahankannya akan memberikan dampak, baik pada perencana TI
maupun manajer risiko sebagai alat kerja TI yang penting
Penggunaan kembali informasi dasar pada pandangan TI ini dan
bagaimana mendukung bisnis adalah hal yang logis dan efisien untuk dilakukan,
tetapi mungkin akan menemui beberapa hambatan / tantangan. Budaya
perbedaan antara perencana TI dan tim risiko TI, serta pengertian yang berbeda
43
mengenai apa yang diperlukan untuk membuat aplikasi, dapat menjadi hambatan
untuk mencapai tujuan ini, tetapi hal tersebut merupakan hambatan yang perlu
diatasi. Bagian-bagian yang berbeda antara TI dan bisnis harus memiliki
pandangan umum dari pandangan TI untuk dapat merencanakan program secara
efektif dan mengelola risiko.
Untuk membangun dan memelihara ruang lingkup TI, organisasi
nemerlukan baik ruang lingkup TI dan proses yang tepat untuk memasikan
akurasinya. Mereka juga memerlukan alat yang dapat mempertahankannya.
Beberapa alat – alat menawarkan fitur yang membantu alur kerja, monitor
kualitas dan pengaturan untuk memastikan bahwa ruang lingkup TI
dipertahankan dan up to date. Tapi alat – alat tersebut juga menawarkan fitur
fitur lain yang mendukung upaya risiko manajemen
Manfaat ketiga yang tersedia dengan mendirikankan dan memelihara
ruang lingkup TI dari arsitektur enterprise dan tim perencanaan TI adalah untuk
menyediakan dasar untuk otomatisasi. Aturan bisnis dasar mensurvei
kemampuan menyediakan proyek risiko manajemen TI dengan kemampuant
untuk secara otomatis mengirim survey pengukuran risiko yang dibutuhkan
kepada orang yang tepat (atau kelompok yang tepat) untuk setiap dan semuasegi
dari ruang lingkup TI. Manfaat yang lebih lanjut termasuk kemampuan untuk
menetapkan deputi saat tidak adanya orang yang bertanggung jawab dan
memonitor peningkatan pengukuran untuk mengukur objek yang tidak merespon
tepat
44
Konsolidasi dan evaluasi respon pada akar lebih lanjut mengurangi upaya
manual yang terlibat. Hal ini menyebabkan tidak hanya untuk penghematan biaya
langsung, tetapi juga lebih handal daripada mengkonsolidasi spreadsheet - karena
kesalahan yang dapat dengan mudah dilakukan. Selain itu, juga didukung oleh
alat tersebut sehingga membuatnya lebih mudah untuk meyakinkan auditor
eksternal bahwa pengukuran risiko telah dilakukan sesuai dengan yang
diperlukan sesuai dengan jadual, yang berpotensi mengurangi biaya audit
Manfaat terakhir yang dipertimbangkan di sini adalah kemampuan untuk
menggaris bawahi risiko. Hal ini biasanya merupakan sasaran dari disiplin
manajemen risiko TI dewasa ini. Saat ini, penilaian risiko pada umumnya
dilakukan sesuai dengan siklus audit. Namun, hal ini berarti bahwa organisasi
menjalankan pengukuran risiko yang lebih sering daripada yang dibutuhkan.
Yang lebih penting, ini juga berarti bahwa dalam jarak antara pengukuran risiko,
risiko baru mungkin muncul dalam organisasi tanpa sepengetahuan siapapun
karena kurangnya penilaian risiko dalam prosedur perencanaan TI.
2.6.1 Metode Pengukuran Risiko Teknologi Informasi
Menurut Maulana dan Supangkat (2006, p121) , terdapat banyak metode
yang bisa digunakan dalam penerapan manajemen risiko teknologi informasi,
diantaranya menggunakan metode OCTAVE (Operationally Critical Threat,
Asset, and Vulnerability Evaluation ), COBIT (Control Objectives for
Information and Related Technology), NIST Special Publication 800-30
45
2.6.1.1 COBIT
COBIT (Control Objectives for Information and Related Technology)
merupakan standard yang dikeluarkan oleh ITGI (The IT Governance Institute)
Menurut Maulana dan Supangkat (2006,p122),COBIT merupakan suatu
koleksi dokumen dan framework yang diklasifikasikan dan secara umum
diterima sebagai best practice untuk tata kelola (IT Governance), kontrol dan
jaminan TI Referensi perihal manajemen risiko secara khusus dibahas pada
proses PO9 dalam COBIT. Proses-proses yang lain juga menjelaskan tentang
manajemen risiko namun tidak terlalu detil.
Gambar 2.4 Framework Manajemen Risiko COBIT
Risiko adalah segala hal yang mungkin berdampak pada kemampuan
organisasi dalam mencapai tujuan-tujuannya.
46
Framework manajemen risiko TI dengan menggunakan COBIT (gambar
diatas) terdiri dari :
1. Penetapan Objektif
Kriteria informasi dari COBIT dapat digunakan sebagai dasar dalam
mendefinisikan objektif TI.
Terdapat tujuh kriteria informasi dari COBIT yaitu :
a. Effectiveness
b. efficiency
c. confidentiality
d. integrity
e. availability
f. compliance
g. reliability.
47
2. Identifikasi Risiko
Tabel 2.2 Tabel Kejadian yang Mengganggu Pencapaian Objektif
Perusahaan
Identifikasi risiko merupakan proses untuk mengetahui risiko. Sumber
risiko bisa berasal dari :
•Manusia, proses dan teknologi
•Internal (dari dalam perusahaan) dan eksternal(dari luar perusahaan)
•Bencana (hazard), ketidakpastian (uncertainty) dan kesempatan
(opportunity).
Dari ketiga sumber risiko tersebut dapat diketahui kejadian-kejadian yang
dapat mengganggu perusahaan dalam mencapai objektifnya (tabel diatas)
48
3. PenilaianRisiko
Proses untuk menilai seberapa sering risiko terjadi atau seberapa besar
dampak dari risiko
Dampak risiko terhadap bisnis (business impact) bisa berupa : dampak
terhadap financial, menurunnya reputasi disebabkan sistem yang tidak
aman, terhentinya operasi bisnis, kegagalan aset yang dapat dinilai (sistem
dan data), dan penundaan proses pengambilan keputusan.
Sedangkan kecenderungan (likelihood) terjadinya risiko dapat disebabkan
oleh sifat alami dari bisnis, struktur dan budaya organisasi, sifat alami dari
sistem (tertutup atau terbuka, teknologi baru dan lama), dan kendali-
kendali yang ada. Proses penilaian risiko bisa berupa risiko yang tidak
dapat dipisahkan (inherent risks) dan sisa risiko (residual risks).
Tabel 2.3 Tingkatan besarnya dampak risiko dan frekuensi terjadinya resiko
49
4. Respon Risiko
Untuk melakukan respon terhadap risiko adalah dengan menerapkan
kontrol objektif yang sesuai dalam melakukan manajemen risiko. Jika sisa
risiko masih melebihi risiko yang dapat diterima (acceptable risks), maka
diperlukan respon risiko tambahan. Proses-proses pada framework COBIT
(dari 34 Control Objectives) yang sesuai untuk manajemen risiko adalah :
a. PO1 (Define a Stretegic IT Plan) dan PO9 (Assess and Manage Risks)
b. AI6 (Manages Change)
c. DS5 (Ensure System and Security) dan DS11 (Manage Data)
d. ME1 (Monitor and Evaluate IT Performance)
5. Monitor Risiko
Setiap langkah dimonitor untuk menjamin bahwa risiko dan respon
berjalan sepanjang waktu.
50
2.6.1.2 NIST Special Publication 800-30
GAMBAR 2.5 Proses-Proses Manajemen Risiko
NIST (National Institute of Standard and Technology) mengeluarkan
rekomendasi melalui publikasi khusus 800-30 tentang Risk Management Guide
for Information Technology System.
51
Proses Penilaian Risiko (Risk Assessment):
Gambar 2.6 NIST SP 800-30 Risk Assessment Process
52
STEP-1 : System Characterization
In assessing risks for an IT system, the first step is to define the scope of
the effort. In this step, the boundaries of the IT system are identified, along
with the resources and the information that constitute the system.
Characterizing an IT system establishes the scope of the risk assessment
effort, delineates the operational authorization (or accreditation) boundaries,
and provides information (e.g., hardware, software, system connectivity, and
responsible division or support personnel) essential to defining the risk.
The methodology described in this document can be applied to
assessments of single or multiple, interrelated systems. In the latter case, it is
important that the domain of interest and all interfaces and dependencies be
well defined prior to applying the methodology.
System-Related Information
Identifying risk for an IT system requires a keen understanding of the
system’s processing environment. The person or persons who conduct the risk
assessment must therefore first collect system-related information, which is
usually classified as follows:
a. Hardware
b. Software
c. System interface ( internal and external connectivity)
d. Data and Information
53
e. Person who support and use the IT system.
f. System mission
g. System and data critically.
h.System and data sensitivity Functional Requirements Of IT
i. Users Of The system
j. System security policies governing the IT system.
k. System security Architecture
l. Current Network Topology
m. information Storage Protection that safeguards system and data
availability, integrity, confidentiality.
n. Flow of Information
Output from Step 1 : Characterization of the IT system assessed, a good
picture of the IT system environment, and delineation of system boundary
STEP-2 : Threat Identification
A threat is the potential for a particular threat-source to successfully
exercise a particular vulnerability. A vulnerability is a weakness that can be
accidentally triggered or intentionally exploited. A threat-source does not
present a risk when there is no vulnerability that can be exercised. In
54
determining the likelihood of a threat, one must consider threat-sources,
potential vulnerabilities , and existing controls
Threat-Source Identification
The goal of this step is to identify the potential threat-sources and
compile a threat statement listing potential threat-sources that are applicable
to the IT system being evaluated. A threat-source is defined as any
circumstance or event with the potential to cause harm to an IT system. The
common threatsources can be natural, human, or environmental. In assessing
threat-sources, it is important to consider all potential threat-sources that
could cause harm to an IT system and its processing environment.
For example, although the threat statement for an IT system located in a
desert may no include “natural flood” because of the low likelihood of such
an event’s occurring, environmental threats such as a bursting pipe can
quickly flood a computer room and cause damage to an organization’s IT
assets and resources. Humans can be threat-sources through intentional acts,
such as deliberate attacks by malicious persons or disgruntled employees, or
unintentional acts, such as negligence and errors A deliberate attack can be
either (1) a malicious attempt to gain unauthorized access to an IT system
(e.g., via password guessing) in order to compromise system and data
integrity, availability, or confidentiality or (2) a benign, but nonetheless
purposeful, attempt to circumvent system security. One example of the latter
55
type of deliberate attack is a programmer’s writing a Trojan horse program to
bypass system security in order to “get the job done.”
Threat Source identification:
1. Natural Threats.
2. Human Threats
3. Evironmental Threats
Motivation and Threat Actions
Motivation and the resources for carrying out an attack make humans
potentially dangerous threat-sources. Table 2.4 presents an overview of many
of today’s common human threats, their possible motivations, and the
methods or threat actions by which they might carry out an attack. This
information will be useful to organizations studying their human threat
environments and customizing their human threat statements. In addition,
reviews of the history of system breakins; security violation reports; incident
reports; and interviews with the system administrators, help desk personnel,
and user community during information gathering will help identify human
threat-sources that have the potential to harm an IT system and its data and
that may be a concern where a vulnerability exists.
56
Tabel 2.4 Tabel Human Threats, Motivation and Action
Human threats Motivation Action
Hacker, cracker Challenge
Ego
Rebellion
• Hacking
• Social engineering
• System intrusion, break-ins
•Unauthorizedsystem 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
• System tampering
Industrial
espionage
Competitive advantage
Economic espionage
• Economic exploitation
• Information theft
57
(companies,
foreign
governments,
other
government
interests)
• 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
58
information
• System bugs
• System intrusion
• System sabotage
•Unauthorized system access
Output from Step 2 : A threat statement containing a list of threat-sources that
could exploit system vulnerabilities
STEP-3 : Vulnerability identification
- Vulnerability merupakan kelemahan sistem yang mengakibatkan terjadinya
pelanggaran keamanan.
- Vulnerability resource
- Dokumen risk asessment yang pernah ada.
- Vulnerability list
Tabel 2.5 Security Criteria
Management Security • Assignment of responsibilities
• Continuity of support
• Incident response capability
• Periodic review of security controls
• Personnel clearance and background
59
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
60
• Identification and authentication
• Intrusion detection
• Object reuse
• System audit
Output from Step 3 : A list of the system vulnerabilities (observations)7 that
could be exercised by the potential threat-sources
STEP -4 : Control Analysis
The goal of this step is to analyze the controls that have been
implemented, or are planned for implementation, by the organization to
minimize or eliminate the likelihood (or probability) of a threat’s exercising a
system vulnerability. To derive an overall likelihood rating that indicates the
probability that a potential vulnerability may be exercised within the construct
of the associated threat environment (Step 5 below), the implementation of
current or planned controls must be considered. For example, a vulnerability
(e.g., system or procedural weakness) is not likely to be exercised or the
likelihood is low if there is a low level of threat-source interest or capability
or if there are effective security controls that can eliminate, or reduce the
magnitude of, harm., respectively, discuss control methods, control
categories, and the control analysis technique.
Control Methods
61
Security controls encompass the use of technical and nontechnical
methods. Technical controls are safeguards that are incorporated into
computer hardware, software, or firmware (e.g., access control mechanisms,
identification and authentication mechanisms, encryption methods, intrusion
detection software). Nontechnical controls are management and operational
controls, such as security policies; operational procedures; and personnel,
physical, and environmental security.
Control Categories
The control categories for both technical and nontechnical control
methods can be further classified as either preventive or detective. These two
subcategories are explained as follows:
• Preventive controls inhibit attempts to violate security policy and
include such controls as access control enforcement, encryption, and
authentication.
• Detective controls warn of violations or attempted violations of security
policy and include such controls as audit trails, intrusion detection
methods, and checksums.
Control Analysis Technique
development of a security requirements checklist or use of an available
checklist will be helpful in analyzing controls in an efficient and systematic
manner. The security requirements checklist can be used to validate security
62
noncompliance as well as compliance. Therefore, it is essential to update such
checklists to reflect changes in an organization’s control environment (e.g.,
changes in security policies, methods, and requirements) to ensure the
checklist’s validity.
Output from Step 4 : List of current or planned controls used for the IT system
to mitigate the likelihood of a vulnerability’s being exercised and reduce the
impact of such an adverse event
STEP-5 : Likelihood determination
To derive an overall likelihood rating that indicates the probability that a
potential vulnerability may be exercised within the construct of the associated
threat environment, the following governing factors must be considered:
• Threat-source motivation and capability
• Nature of the vulnerability
• Existence and effectiveness of current controls.
The likelihood that a potential vulnerability could be exercised by a given
threat-source can be described as high, medium, or low. Table 2.6 below
describes these three likelihood levels.
63
Tabel 2.6 Likelihood Detemination
Likelihood Level Likelihood Definition
High
(1.0)
The threat-source is highly motivated and sufficiently
capable, and controls to
prevent the vulnerability from being exercised are
ineffective.
Medium
(0.5)
The threat-source is motivated and capable, but
controls are in place that may
impede successful exercise of the vulnerability.
Low
(0.1)
The threat-source lacks motivation or capability, or
controls are in place to
prevent, or at least significantly impede, the
vulnerability from being exercised.
Output from Step 5 : Likelihood rating (High, Medium, Low)
STEP-6 : Impact Analysis
A successful threat exercise of a vulnerability. Before beginning the
impact analysis, it is necessary to obtain the following necessary information
as discussed in
a. System mission (e.g., the processes performed by the IT system)
64
b. System and data criticality (e.g., the system’s value or importance to an
organization)
c. System and data sensitivity. Therefore, the adverse impact of a security
event can be described in terms of loss or degradation of any, or a
combination of any, of the following three security goals: integrity,
availability, and confidentiality. The following list provides a brief
description of each security goal and the consequence (or impact) of its
not being met:
d. Loss of Integrity. System and data integrity refers to the requirement that
information be protected from improper modification. Integrity is lost if
unauthorized changes are made to the data or IT system by either
intentional or accidental acts. If the loss of system or data integrity is not
corrected, continued use of the contaminated system or corrupted data
could result in inaccuracy, fraud, or erroneous decisions. Also, violation
of integrity may be the first step in a successful attack against system
availability or confidentiality. For all these reasons, loss of integrity
reduces the assurance of an IT system.
e. Loss of Availability. If a mission-critical IT system is unavailable to its
end users, the organization’s mission may be affected. Loss of system
functionality and operational effectiveness, for example, may result in
loss of productive time, thus impeding the end users’ performance of their
functions in supporting the organization’s mission.
65
f. Loss of Confidentiality. System and data confidentiality refers to the
protection of information from unauthorized disclosure. The impact of
unauthorized disclosure of confidential information can range from the
jeopardizing of national security to the disclosure of Privacy Act data.
Unauthorized, unanticipated, or unintentional disclosure could result in
loss of public confidence, embarrassment, or legal action against the
organization.
Tabel 2.7 Magnitude of Impact
Magnitude of impact Impact Definition
High
(100)
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;
(3) may result in human death or serious injury.
Medium
(50)
Exercise of the vulnerability
(1) may result in the costly loss of tangible assets or resources;
(2) may violate, harm, or impede an organization’
Low
(10)
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
Output from Step 6 : Magnitude of impact (High, Medium, or Low)
66
STEP-7 : Risk Determination
Likelihood (e.g., probability) and threat impact. Table 2.8 below shows
how the overall risk ratings might be determined based on inputs from the
threat likelihood and threat impact categories. The matrix below is a 3 x 3
matrix of threat likelihood (High, Medium, and Low) and threat impact (High,
Medium, and Low). Depending on the site’s requirements and the granularity
of risk assessment desired, some sites may use a 4 x 4 or a 5 x 5 matrix. The
latter can include a Very Low /Very High threat likelihood and a Very
Low/Very High threat impact to generate a Very Low/Very High risk level. A
“Very High” risk level may require possible system shutdown or stopping of
all IT system integration and testing efforts.
The sample matrix in Table 2.8 shows how the overall risk levels of High,
Medium, and Low are derived. The determination of these risk levels or
ratings may be subjective. The rationale for this justification can be explained
in terms of the probability assigned for each threat likelihood level and a
value assigned for each impact level. For example use quantitative risk
assestmen:
The probability assigned for each threat likelihood level is 1.0 for High,
0.5 for Medium, 0.1 for Low .
The value assigned for each impact level is 100 for High, 50 for Medium,
and 10 for low
67
Tabel 2.8 Risk determination
Threat Likelihood
Impact
Low (10)
Medium (50)
High (100)
High (1.0) Low 10 X 1.0 = 10
Medium 50 X 1.0 = 50
High 100 X 1.0 = 100
Medium (0.5) Low 10 X 0.5 = 5
Medium 50 X 0.5 = 25
Medium 100 X 0.5 = 50
Low (0.1) Low 10 X 0.1 = 1
Low 50 X 0.1 = 5
Low 100 X 0.1 = 10
Risk Scale: High ( >50 to 100); Medium ( >10 to 50); Low (1 to 10)
Tabel 2.9 Risk Scale & Necessary Action
Risk Level
.
Risk Description and Necessary Actions
High
(100)
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
(50)
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.
68
Low
(10)
If an observation is described as low risk, the system’s DAA must
determine whether corrective actions are still required or decide to
accept the risk
Output dari Step 7 : Risk level (High, Medium, Low)
STEP- 8 : Control Recommendations
During this step of the process, controls that could mitigate or eliminate
the identified risks, as appropriate to the organization’s operations, are
provided. The goal of the recommended controls is to reduce the level of risk
to the IT system and its data to an acceptable level. The following factors
should be considered in recommending controls and alternative solutions to
minimize or eliminate identified risks:
a. Effectiveness of recommended options (e.g., system compatibility)
b. Legislation and regulation
c. Organizational policy
d. Operational impact
e. Safety and reliability.
The control recommendations are the results of the risk assessment
process and provide input to the risk mitigation process, during which the
recommended procedural and technical security controls are evaluated,
69
prioritized, and implemented. It should be noted that not all possible
recommended controls can be implemented to reduce loss.
To determine which ones are required and appropriate for a specific
organization, a cost-benefit analysis , should be conducted for the proposed
recommended controls, to demonstrate that the costs of implementing the
controls can be justified by the reduction in the level of risk. In addition, the
operational impact (e.g., effect on system performance) and feasibility (e.g.,
technical requirements, user acceptance) of introducing the recommended
option should be evaluated carefully during the risk mitigation process.
Output from Step 8 : Recommendation of control(s) and alternative solutions
to mitigate risk
STEP -9 : Results Documentation
Once the risk assessment has been completed (threat-sources and
vulnerabilities identified, risks assessed, and recommended controls
provided), the results should be documented in an official report or briefing.
A risk assessment report is a management report that helps senior
management, the mission owners, make decisions on policy, procedural,
budget, and system operational and management changes. Unlike an audit or
investigation report, which looks for wrongdoing, a risk assessment report
should not be presented in an accusatory manner but as a systematic and
analytical approach to assessing risk so that senior management will
understand the risks and allocate resources to reduce and correct potential
70
losses. For this reason, some people prefer to address the threat/vulnerability
pairs as bservations instead of findings in the risk assessment report.
Appendix B provides a suggested outline for the risk assessment report.
Output from Step -9 : Risk assessment report that describes the threats and
vulnerabilities, measures the risk, and provides recommendations for control
implementation
Menurut SANS Institute(2006) Based on NIST sp800-30 There are 2
methode to identify risk assessment :
a. Quantitative Risk Assessment
Quantitative risk assessment draws upon methodologies used by
financial institutions and insurance companies. By assigning values to
information, systems, business processes, recovery costs, etc., impact,
and therefore risk, can be measured in terms of direct and indirect costs.
Typically, it is not cost-effective to perform a quantitative risk
assessment for an IT system, due to the relative difficulty of obtaining
accurate and complete information. However, if the information is
deemed reliable, a qualitative risk assessment is an extremely powerful
tool to communicate risk to all level of management.
Quantitative risk measurement is the standard way of measuring
risk in many fields, such as insurance, but it is not commonly used to
measure risk in information systems. Two of the reasons claimed for this
are 1) the difficulties in identifying and assigning a value to assets, and
71
2) the lack of statistical information that would make it possible to
determine frequency. Thus, most of the risk assessment tools that are used
today for information systems are measurements of qualitative risk.
b. Qualitative Risk Assessment
Qualitative risk assessments assume that there is already a great
degree of uncertainty in the likelihood and impact values and defines
them, and thus risk, in somewhat subjective or qualitative terms. Similar
to the issues in quantitative risk assessment, the great difficulty in
qualitative risk assessment is defining the likelihood and impact values.
Moreover, these values need to be defined in a manner that allows the
same scales to be consistently used across multiple risk assessments.
The results of qualitative risk assessments are inherently more
difficult to concisely communicate to management. Qualitative risk
assessments typically give risk results of “High”, “Moderate” and
“Low”. However, by providing the impact and likelihood definition
tables and
the description of the impact, it is possible to adequately communicate
the assessment to the organization’s management
72
2.6.1.3 OCTAVE
Gambar 2.7 Information Security Risk Management Framework
Framework manajemen risiko (gambar 2.7) menggunakan pendekatan
OCTAVE(Operationally Critical Threat, Asset, and Vulnerability Evaluation )
Menurut Maulana dan Supangkat (2006,p124-p125), framework
manajemen risiko menggunakan pendekatan OCTAVE-S sebagai berikut :
1.Identifikasi
Identifikasi merupakan proses transformasi ketidakpastian dan isu
tentang seberapa baik asset organisasi dilindungi dari risiko. Tugas yang harus
dilakukan adalah identifikasi profil risiko (aset kritis, ancaman terhadap aset,
kebutuhan keamanan untuk aset kritis, deskripsi tentang dampak risiko pada
73
organisasi, dan komponen infrastruktur utama yang berhubungan dengan aset
kritis) dan identifikasi informasi organisasi (kebijakan, praktek dan prosedur
keamanan, kelemahan teknologi dan kelemahan organisasi saat ini).
2.Analisa
Analisa merupakan proses untuk memproyeksikan bagaimana risiko-
risiko ekstensif dan bagaimana menggunakan proyeksi tersebut untuk
membuat skala prioritas. Tugas dalam proses analisa adalah melakukan
evaluasi risiko (Nilai-nilai untuk mengukur risiko- dampak dan peluang) dan
skala prioritas risiko (pendekatan pengurangan risiko, menerima atau
mengurangi risiko)
3.Perencanaan
Perencanaan merupakan proses untuk menentukan aksi-aksi yang
akan diambil untuk meningkatkan postur dan perlindungan keamanan aset
kritis tersebut. Langkah dalam perencanaan adalah mengembangkan strategi
proteksi, rencana mitigasi risiko, rencana aksi, budget, jadwal, kriteria sukses,
ukuran-ukuran untuk monitor rencana aksi, dan penugasab personil untuk
implementasi rencana aksi.
4. Implementasi
Implementasi merupakan proses untuk melaksanakan aksi yang
direncanakan untuk meningkatkan keamanan sistem berdasarkan jadwal dan
74
kriteria sukses yang didefinisikan selama perencanaan risiko. Implementasi
menghubungkan antara perencanaan dengan monitor dan kontrol.
5. Monitor
Proses ini memonitor jejak rencana aksi untuk menentukan status saat
ini dan meninjau ulang data organisasi sebagai tanda adanya risiko baru dan
perubahan risiko yang ada. Langkah dalam proses monitor adalah melakukan
eksekusi rencana aksi secara lengkap, mengambil data (data untuk melihat
jalur rencana aksi terkini, data tentang indikator risiko utama) dan laporan-
laporan terkini dan indikator risiko utama.
6. Kontrol
Mengontrol risiko adalah proses yang didesain agar personil
melakukan penyesuaian rencana aksi dan menentukan apakah merubah
kondisi organisasi akan menyebabkan timbulnya risiko baru. Langkah dalam
proses monitor risiko adalah analisa data (analisa laporan terkini dan analisa
indikator risiko), membuat keputusan (keputusan tentang rencana aksi dan
keputusan tentang identifikasi risiko baru), dan melakukan eksekusi keputusan
(mengkomunikasikan keputusan, mengimplementasikan perubahan rencana
aksi, dan memulai aktifitas identifikasi risiko).
Tahapan, Proses, dan Aktivitas OCTAVE-S
Menurut Alberts et al. (2005, p5), OCTAVE-S berdasar pada 3 tahap
yang dideskripsikan dalam kriteria OCTAVE, meskipun nomor dan urutan
75
kegiatan berbeda dari metode OCTAVE yang digunakan. Bagian ini memberikan
tinjauan singkat atas tahapan, proses, dan kegiatan OCTAVE-S.
Tahap satu adalah sebuah evaluasi dari aspek organisasi. Selama dalam
tahap ini, tim analisis menggambarkan kriteria dampak evaluasi yang akan
digunakan nantinya untuk mengevaluasi risiko. Hal ini juga mengindentifikasi
asset-aset organisasi saat ini. Dimana pada tahap ini terdiri atas 2 proses, yaitu
identifikasi informasi organisasi dan membuat profil ancaman serta memiliki
enam aktivitas.
Tahap kedua yaitu tim analisis melakukan peninjuan ulang level tinggi
dari perhitungan infrastruktur organisasi, yang berfokus pada keamanan yang di
pertimbangkan pemelihara dari infrastruktur. Tahap ini memiliki satu proses
yaitu memeriksa perhitungan infrastruktur dalam kaitannya dengan asset yang
kritis dimana terdapat aktivitas.
Selama tahap ketiga, tim analisis mengidentifikasi risiko dari asset kritis
organisasi dan memutuskan apa yang harus dilakukan mengenainya. Berdasarkan
analisis dari kumpulan informasi, tim membuat strategi perlindungan untuk
organisai dan rencana mitigasi risiko yang ditujukan padaaset kritis. Tahap ini
terdiri atas 2 proses, yaitu identifiksai dan analisis risiko serta mengembangkan
strategi perlindungan dan rencana mitigasi, di mana proses ini memiliki delapan
aktivitas
76
Hasil OCTAVE-S
Menurut Alberts et al. (2005, p6), selama mengevaluasi OCTAVE-S, tim
analisis melihat keamanan dari beberapa perspektif, memastikan bahwa
rekomendasi yang dicapai sesuai dengan keseimbangan berdasarkan kebutuhan
organisasi.
Hasil utama dari OCTAVE-S, yaitu:
a. Strategi perlindungan organisasi yang luas: Perlindungan strategi menguraikan
secara arah organisasi dengan mematuhi praktek keamanan informasi.
b. Rencana mitigasi risiko: Rencana ini dimaksudkan untuk menguraikan risiko
asset kritis untuk meningkatkan praktek keamanan yang dipilih.
c. Daftar tindakan: Termasuk tindakan jangka pendek yang dibutuhkan untuk
menunjukkan kelemahan yang spesifik.
Hasil OCTAVE-S yang berguna lainnya, yaitu:
1. Daftar informasi penting terkait dengan asset yang mendukung tujuan bisnis
dan sasaran organisasi.
2. Hasil survey menunjukkan sejauh mana organisasi mengikuti praktek
keamanan yang baik.
3. Profil risiko untuk setiap asset kritis menggambarkan jarak antara risiko
terhadap asset.