Anda di halaman 1dari 174

UNIVERSITAS INDONESIA

AUDIT SISTEM INFORMASI PADA APLIKASI MANAJEMEN DATA PESERTA DENGAN PENDEKATAN COBIT 4.1 DAN FISCAM: STUDI KASUS PT TASPEN (PERSERO)

KARYA AKHIR

Dewi Puspasari 0806482951

FAKULTAS ILMU KOMPUTER PROGRAM STUDI MAGISTER TEKNOLOGI INFORMASI JAKARTA JULI 2010

UNIVERSITAS INDONESIA

AUDIT SISTEM INFORMASI PADA APLIKASI MANAJEMEN DATA PESERTA DENGAN PENDEKATAN COBIT 4.1 DAN FISCAM: STUDI KASUS PT TASPEN (PERSERO)

KARYA AKHIR Diajukan sebagai salah satu syarat untuk memperoleh gelar Magister Teknologi Informasi

Dewi Puspasari 0806482951

FAKULTAS ILMU KOMPUTER PROGRAM STUDI MAGISTER TEKNOLOGI INFORMASI JAKARTA JULI 2010

HALAMAN PERNYATAAN ORISINALITAS

Karya Akhir ini adalah hasil karya sendiri, dan semua sumber baik yang dikutip maupun dirujuk telah saya nyatakan dengan benar

Nama NPM Tanda Tangan Tanggal

: Dewi Puspasari : 0806482951 : : 14 Juli 2010

ii

HALAMAN PENGESAHAN

Karya Akhir ini diajukan oleh: Nama : NPM : Program Studi : Judul Karya Akhir :

Dewi Puspasari 0806482951 Magister Teknologi Informasi Audit Sistem Informasi pada Aplikasi Manajemen Data Peserta dengan Pendekatan COBIT 4.1 dan FISCAM: Studi Kasus PT Taspen (Persero)

Telah berhasil dipertahankan di hadapan Dewan Penguji dan diterima sebagai bagian persyaratan yang diperlukan untuk memperoleh gelar Magister Teknologi Informasi pada Program Studi Magister Teknologi Informasi, Fakultas Ilmu Komputer, Universitas Indonesia.

DEWAN PENGUJI

Pembimbing : Budi Yuwono, Ph.D Pembimbing : Ivano Aviandi, Msc Penguji Penguji : Bob Hardian, Ph.D : Dr. Achmad Nizar Hidayanto

( ( ( (

) ) ) )

Ditetapkan di : Jakarta Tanggal : 14 Juli 2010

iii

KATA PENGANTAR

Terima kasih dan puji syukur saya panjatkan kepada Tuhan Yang Maha Kuasa atas limpahan berkahnya saya dapat menyelesaikan karya akhir ini yang bertajuk Audit Sistem Informasi pada Aplikasi Manajemen Data Peserta dengan Pendekatan COBIT 4.1 dan FISCAM: Studi Kasus PT Taspen (Persero).

Saya sadar karya akhir ini tidak akan selesai tanpa bantuan dan dukungan dari beberapa pihak. Karena itu dalam kesempatan ini saya ingin mengucapkan terima kasih kepada: (1) Bapak Budi Yuwono selaku dosen pembimbing yang telah meluangkan waktu, energi, dan pikiran untuk membimbing, dan mengarahkan saya selama proses penelitian dan penyusunan karya akhir ini. (2) Bapak Ivano Aviandi selaku dosen pembimbing dan dosen pengajar Manajemen Risiko yang membuka mata saya pentingnya manajemen risiko dan keamanan TI dalam suatu organisasi. (3) Bapak Sopian dari Bagian Aplikasi Bisnis Inti Divisi Teknologi Informasi PT Taspen (Persero) yang meluangkan waktunya untuk menjawab pertanyaan dan menjelaskan dengan detil apabila saya kurang paham. (4) Bapak Suryanto dari Bagian Sistem Operasi Divisi Teknologi Informasi PT Taspen (Persero) yang bersedia meminjamkan dokumen-dokumen perusahaan sebagai bahan referensi penulisan karya akhir ini. (5) Bapak Ibram, Bambang, Jafar, Yanrizal, Dina, dan rekan-rekan di Bagian Data Divisi Pelayanan PT Taspen (Persero) yang meluangkan waktunya untuk menjawab pertanyaan serta memberikan dokumen-dokumen yang saya perlukan dalam karya akhir ini. (6) Mundiyati, Fuji, Lina, dan Peter dari Divisi Teknologi Informasi PT Taspen (Persero) yang membantu melengkapi deskripsi aplikasi. (7) Segenap staf dan dosen di Magister Teknologi Informasi Fakultas Ilmu Komputer Universitas Indonesia. iv

(8) Mama, Papa, Mas Ari, Mbak Yanti, dan Mas Ovi yang selalu memberikan dukungan dan menyemangati saya. (9) Rekan-rekan angkatan 2009F yang selalu menyemangati saya, terutama Arief Bandung, Anda Nugroho, Eko Rudiyanto, dan Indra Adhitya. (10) Serta berbagai pihak yang telah membantu penulis yang tidak dapat disebutkan satu persatu. Semoga Tuhan membalas semua kebaikan rekan-rekan yang telah membantu.

Saya sadar penulisan karya akhir ini masih jauh dari sempurna. Oleh karena itu saya dengan senang hati menerima saran dan kritik guna penyempurnaan penelitian ini. Akhir kata, saya berharap karya akhir ini bermanfaat bagi pengembangan ilmu, baik di dunia bisnis maupun di dunia teknologi informasi.

Jakarta, Juli 2010

Dewi Puspasari

HALAMAN PERNYATAAN PERSETUJUAN PUBLIKASI KARYA AKHIR UNTUK KEPENTINGAN AKADEMIS Sebagai sivitas akademik Universitas Indonesia, saya yang bertanda tangan di bawah ini:

Nama NPM Departemen

: Dewi Puspasari : 0806482951 :

Program Studi : Magister Teknologi Informasi Fakultas Jenis Karya : Ilmu Komputer : Skripsi/Tesis/Disertasi

Demi pengembangan ilmu pengetahuan, menyetujui untuk memberikan kepada Universitas Indonesia Hak Bebas Royalti Nonekslusif (Non-exclusive RoyaltyFree Right) atas karya ilmiah saya yang berjudul : Audit Sistem Informasi pada Aplikasi Manajemen Data Peserta dengan Pendekatan COBIT 4.1 dan FISCAM: Studi Kasus PT Taspen (Persero).

Beserta perangkat yang ada (jika diperlukan). Dengan Hak Bebas Royalti Nonekskutif ini Universitas Indonesia berhak menyimpan, mengalihmedia/formatkan, mengelola dalam bentuk pangkalan data (database). Merawat dan

mempublikasikan karya akhir saya tanpa meminta izin dari saya selama tetap mencantumkan saya sebagai penulis/pencipta dan sebagai pemilik Hak Cipta.

Demikian pernyataan ini saya buat dengan sebenarnya. Dibuat di : Jakarta

Pada tanggal : 14 Juli 2010

Yang menyatakan,

(Dewi Puspasari)

vi

ABSTRAK

Nama Program Studi Judul Karya Akhir

: Dewi Puspasari : Magister Teknologi Informasi : Audit Sistem Informasi pada Aplikasi Modul Manajemen Data Peserta dengan Pendekatan COBIT 4.1dan FISCAM: Studi Kasus PT Taspen (Persero)

Data merupakan urat nadi perusahaan. Pentingnya data ini disadari oleh Taspen. Tanpa data peserta Taspen tidak akan dapat beroperasi. Data juga menjadi obyek audit BPK dan mendapat status disclaimer pada laporan keuangan 2006 dan 2007 karena dianggap tidak akurat. Lemahnya kontrol penanganan data juga masih menjadi temuan pada audit BPK pada tahun 2009. Namun, meski sudah ada upaya untuk meningkatkan keakurasian data, hingga saat ini belum ada panduan maupun kajian mengenai penyebab integritas data yang lemah, apakah dari segi aplikasi, keamanan sistem, proses bisnis, ataupun manajemen perubahan yang kurang baik. Maka dari itu penelitian ini berfokus pada audit penerapan kontrol untuk memastikan integritas data dengan pendekatan COBIT 4.1 dan menggunakan panduan audit FISCAM yang dipublikasikan GAO. Ada enam kontrol yang menjadi fokus COBIT 4.1 yang mendukung manajemen integritas yaitu PO2, PO9, AI6, DS5, DS11, dan DS12. Sedangkan kontrol FISCAM terdiri dari kontrol aplikasi secara umum, proses bisnis, antarmuka, dan manajemen data. Pemetaan kontrol-kontrol kontrol COBIT 4.1 dan FISCAM menghasilkan output yang memuat kelemahan dan kontribusi tiap area kontrol. Tiap area kontrol yang masih lemah diberikan rekomendasi untuk meningkatkan manajemen integritas. Dari penelitian ini dapat diketahui bahwa Taspen baru menerapkan 53 persen kontrol penerapan sistem informasi untuk memastikan integritas data. Area kontrol penerapan sistem informasi tersebut yang terlemah yaitu manajemen risiko (PO9), 69,7 persen belum diterapkan. Sebaliknya, kontrol yang telah sebagian besar diaplikasikan adalah manajemen perubahan (AI6) sebesar 67,9 persen. Dari total 117 rekomendasi untuk meningkatkan manajemen integritas pada area-area kontrol yang masih lemah, 47 item di antaranya diprioritaskan untuk mengatasi temuan audit BPK tahun 2009. Kata Kunci: audit, data, GAO, COBIT4.1. FISCAM, BPK xv + 159 halaman; 30 gambar; 10 tabel; 3 lampiran Daftar Pustaka 14 (2001 2009)

vii
Universitas Indonesia

ABSTRACT

Name Study Program Title

: Dewi Puspasari : Magister Teknologi Informasi : System Information Audit on Participant Data Management Application with FISCAM and COBIT 4.1 Approach: Case Study at PT Taspen (Persero)

Data is like blood of the company. The importance of this data is realized by Taspen. Without participant data, Taspen will not be able to operate. The data also becomes the object of audit board and got a disclaimer on the status of financial statements in 2006 and 2007 because it was considered inaccurate. The weakness of data manage control also still become the BPK finding in 2009. However, despite existing efforts to improve the accuracy of data, until now there has been no guidelines or studies about the causes of poor data integrity, whether in terms of applications, security systems, or change management that are less good. Therefore this study focuses on the implementation of audit controls to ensure integrity of data with the published COBIT 4.1 and FISCAM audit guideline that published by GAO. There are six COBIT 4.1 controls to support integrity management, PO2, PO9, AI6, DS5, DS11, and DS12. While FISCAM controls are general application control, business processes, interfaces, and data management. Mapping controls in FISCAM to COBIT 1.4 control deliver output that contains the weaknesses and the contribution of each control area. Each control area is still weak, given the recommendation to improve the integrity management. From this research, it is known that Taspen has just applied 53 percent of information system implementation control to ensure data integrity. The weakest control area of information system implementation is risk management (PO9), 69.7 percent have not yet applied. In contrast, the control that has been largely applied is management of change (AI6), 67.9 percent. Of the total 117 recommendations to improve the integrity management control on areas that are still weak, the 47 items of which are prioritized to solve the BPK audit findings in 2009. Keywords: audit, data, GAO, COBIT 4.1. FISCAM, BPK xv + 159 pages; 30 figures; 10 tables; 3 attachments Bibliography 14 (2001 2009)

viii
Universitas Indonesia

DAFTAR ISI

HALAMAN JUDUL .............................................................................................. i LEMBAR PENGESAHAN..iii KATA PENGANTAR .......................................................................................... iv LEMBAR PERSETUJUAN PUBLIKASI KARYA ILMIAH..vi ABSTRAK ........................................................................................................... vii DAFTAR ISI ......................................................................................................... ix DAFTAR GAMBAR ............................................................................................ xi DAFTAR GRAFIK ............................................................................................. xii DAFTAR TABEL .............................................................................................. xiii DAFTAR LAMPIRAN ...................................................................................... xiv BAB 1 ..................................................................................................................... 1 PENDAHULUAN .................................................................................................. 1 1.1 Latar Belakang ......................................................................................... 1 1.2 Rumusan Masalah .................................................................................... 2 1.3 Tujuan ....................................................................................................... 3 1.4 Telaah Karya Akhir Sebelumnya ............................................................. 3 1.5 Manfaat ..................................................................................................... 4 1.6 Ruang Lingkup Penelitian ........................................................................ 4 1.7 Sistematika Penulisan ............................................................................... 4 BAB 2 ..................................................................................................................... 6 TINJAUAN PUSTAKA ........................................................................................ 6 2.1 Audit Sistem Informasi ............................................................................ 6 2.1.1 Tujuan .............................................................................................. 7 2.1.2 Tahapan Audit .................................................................................. 7 2.2 Panduan Audit .............................................................................................. 9 2.2.1 COBIT ............................................................................................ 9 2.2.2 FISCAM ....................................................................................... 33 2.2.3 Perbandingan dengan Framework Audit Lainnya ........................ 35 2.3 Metode Penelitian Kuantitatif dan Kualitatif ............................................ 36 BAB 3 ................................................................................................................... 39 METODOLOGI PENELITIAN ........................................................................ 39 3.1 Observasi dan Penentuan Area Penelitian .............................................. 40 3.2 Studi Literatur ......................................................................................... 40 3.3 Pemilihan Control Objective pada COBIT 4.1 dan FISCAM ................ 40 3.4 Wawancara dengan Panduan FISCAM dan Pengumpulan Referensi .... 40 3.5 Rekapitulasi Hasil Wawancara ............................................................... 41 3.6 Identifikasi Kelemahan Kontrol dan Penyusunan Rekomendasi ........... 41 3.7 Pemetaan terhadap Hasil Temuan Audit BPK dan Penyusunan Rekomendasi Prioritas ............................................................................ 42 BAB 4 ................................................................................................................... 43 PROFIL PERUSAHAAN ................................................................................... 43 4.1 Sejarah .................................................................................................... 43 4.2 Struktur Organisasi ................................................................................. 44 4.3 Budaya Perusahaan ................................................................................. 44 ix
Universitas Indonesia

4.3.1 Visi Perusahaan........................................................................ 45 4.3.2 Misi Perusahaan ....................................................................... 45 4.4 Sasaran Korporasi ................................................................................... 46 4.5 Strategi Korporasi ................................................................................... 47 4.6 Portofolio Bisnis Taspen ........................................................................ 48 4.6.1 Program Tabungan Hari Tua ................................................... 48 4.6.2 Program Pensiun ...................................................................... 49 4.6.3 Transaksi Bisnis Taspen .......................................................... 50 4.7 Profil Aplikasi Bisnis Inti ....................................................................... 52 4.7.1 Sejarah ..................................................................................... 53 4.7.2 Deskripsi .................................................................................. 53 4.7.3 Struktur Organisasi Pengembangan Sistem ACB .................... 58 BAB 5 ................................................................................................................... 60 ANALISIS DAN PEMBAHASAN ..................................................................... 60 5.1 Analisis Data Peserta Taspen ................................................................. 60 5.2 Analisis dengan Pendekatan COBIT 4.1 dan FISCAM ......................... 68 BAB 6 ................................................................................................................. 128 KESIMPULAN DAN SARAN ......................................................................... 128 6.1 Kesimpulan ........................................................................................... 128 6.2 Saran ..................................................................................................... 128 DAFTAR PUSTAKA ........................................................................................ 130

x
Universitas Indonesia

DAFTAR GAMBAR

Gambar 2.1 : Empat Domain COBIT .................................................................. 10 Gambar 2.2 : Standar Informasi, Jenis dan Fokus Area yang Didukung PO2 ..... 13 Gambar 2.3 : Input dan Output PO2 .................................................................... 13 Gambar 2.4 : Sasaran Metrik PO2 ....................................................................... 14 Gambar 2.5 : Standar Informasi, Jenis dan Fokus Area yang Didukung PO9 ..... 17 Gambar 2.6 : Input dan Output PO9 .................................................................... 17 Gambar 2.7 : Sasaran Metrik PO9 ....................................................................... 18 Gambar 2.8 : Standar Informasi, Jenis dan Fokus Area yang Didukung AI6 ...... 20 Gambar 2.9 : Input dan Output AI6 ..................................................................... 21 Gambar 2.10: Sasaran Metrik AI6 ........................................................................ 21 Gambar 2.11: Standar Informasi, Jenis dan Fokus Area yang Didukung DS5 ..... 25 Gambar 2.12: Input dan Output DS5 .................................................................... 26 Gambar 2.13: Sasaran Metrik DS5 ....................................................................... 26 Gambar 2.14: Standar Informasi, Jenis dan Fokus Area yang Didukung DS11 ... 29 Gambar 2.15: Input dan Output DS11 .................................................................. 29 Gambar 2.16: Sasaran Metrik DS11 ..................................................................... 30 Gambar 2.17: Standar Informasi, Jenis dan Fokus Area yang Didukung DS12 ... 32 Gambar 2.18: Input dan Output DS12 .................................................................. 32 Gambar 2.19: Sasaran Metrik DS12 ..................................................................... 33 Gambar 3.1 : Alur Penyusunan Karya Akhir ....................................................... 39 Gambar 4.1 : Struktur Organisasi Taspen ............................................................ 44 Gambar 4.2 : Konsep DBMS Terdistribusi .......................................................... 53 Gambar 4.3 : Topologi Jaringan untuk Aplikasi Core Business .......................... 54 Gambar 4.4 : Tampilan Muka Aplikasi Core Business........................................ 55 Gambar 4.5 : Tampilan Submodul Pemeliharaan Data Peserta Aktif .................. 56 Gambar 4.6 : Halaman Pemeliharaan Data Peserta ............................................. 56 Gambar 4.7 : Perpindahan Halaman Pemeliharaan Data Peserta ........................ 57 Gambar 4.8 : Submodul Pemeliharaan Data Keluarga ........................................ 57 Gambar 4.9 : Halaman Pemeliharaan Data Keluarga .......................................... 58 Gambar 4.10: Struktur Organisasi Divisi TI di Taspen ........................................ 59

xi
Universitas Indonesia

DAFTAR GRAFIK

Grafik 5.1: Kontribusi Tiap Control Objective COBIT 4.1 dalam Mendukung Manajemen Integritas Data .............................................................. 94 Grafik 5.2: Perbandingan yang Sudah Diterapkan dan Belum Diterapkan Dalam Tiap control objective COBIT 4.1 ................................................... 95

xii
Universitas Indonesia

DAFTAR TABEL

Tabel 2.1: Perbandingan Tiap Framework Audit ................................................. 35 Tabel 2.2: Perbedaan Metode Kualitatif dan Kuantitatif ...................................... 36 Tabel 5.1: Rekapitulasi Data Invalid Kondisi Bulan Maret 2010 ......................... 62 Tabel 5.2: Rangkuman Jumlah Temuan Draft Notisi Audit BPK RI pada KCU/KC Bulan Desember 2009 ........................................................ 64 Tabel 5.3: Pemetaan Kontrol COBIT 4.1 dengan Kontrol FISCAM .................... 68 Tabel 5.4: Rekapitulasi Hasil Wawancara dengan Pendekatan FISCAM ............ 69 Tabel 5.5: Hasil Rekapitulasi Kontrol FISCAM terhadap Control Objective COBIT 4.1 ........................................................................................... 87 Tabel 5.6: Rekapitulasi Penerapan Kontrol Integritas Data .................................. 94 Tabel 5.7: Rekomendasi untuk Memastikan Integritas Data ................................ 95 Tabel 5.8: Rekomendasi untuk Temuan Audit BPK-RI pada KCU/KC Bulan Desember 2009 .................................................................................. 114

xiii
Universitas Indonesia

DAFTAR LAMPIRAN

LAMPIRAN 1: DAFTAR PERTANYAAN BERDASARKAN FISCAM ... 131 LAMPIRAN 2: DAFTAR PERTANYAAN TAMBAHAN ........................... 139 LAMPIRAN 3: HASIL TRANSKRIP WAWANCARA ............................... 140

xiv
Universitas Indonesia

BAB 1 PENDAHULUAN

Bagian ini memaparkan tentang latar belakang, rumusan masalah, tujuan, manfaat, dan ruang lingkup penulisan serta sistematika penulisan dari penelitian ini.

1.1 Latar Belakang PT Taspen (Persero) telah mewarnai dunia perasuransian sosial di Indonesia selama 46 tahun. Pada usianya yang telah matang Taspen sadar bahwa kepercayaan publik dan pemerintah merupakan kunci keeksisan dan kesuksesan. Kepercayaan ini dapat dipertahankan dengan memberikan pelayanan yang berkualitas kepada peserta. Sedangkan tingkat kepercayaan dari pemerintah sebagai pemegang saham yaitu tingkat kualitas manajemen data dan premi para peserta.

Di Taspen, data peserta yang terdiri dari peserta aktif dan pensiunan bukan hanya sebagai aset, namun juga jantung bisnis perusahaan. Karena tanpa data, maka Taspen tidak dapat beroperasi. Kedua jenis data ini berasal dari pihak eksternal. Sehingga keakurasian dan kemutakhiran data merupakan isyu yang penting. Data peserta menjadi penting karena berkaitan dengan nominal, yaitu premi peserta, besaran dana untuk diinvestasikan dan jumlah dana APBN yang dikucurkan untuk membayar Tabungan Hari Tua (THT) dan uang pensiun. Apabila tidak ada manajemen yang baik, maka data ini dapat disalahgunakan untuk kepentingan pihak tertentu.

Pengelolaan data peserta menjadi perhatian manajemen Taspen sejak diterimanya status disclaimer dari Badan Pemeriksa Keuangan RI pada tahun 2006 dan 2007. Poin utama dari ditetapkannya status tersebut karena data peserta dianggap tidak akurat pada tahun 2006 dan 2007.

1
Universitas Indonesia

Atas temuan hasil audit tersebut manajemen Taspen melakukan beberapa tindakan. Namun, atas hasil tindakan tersebut manajemen belum pernah melakukan pengukuran keefektifannya sebagai solusi dalam menyelesaikan permasalahan tersebut. Karena itu, hingga Desember 2009 integritas data masih menjadi sorotan BPK dan manajemen.

Audit sistem informasi di Indonesia masih merupakan bidang yang baru di Indonesia. Rata-rata perusahaan atau organisasi yang sudah mencapai kemapanan proses yang telah melakukannya, seperti bank umum dan Telkom.

Ada berbagai panduan dalam mengaudit sistem informasi. Best practices yang umum digunakan adalah COBIT dan ISO 27001. Pendekatan lainnya adalah FISCAM yang dikeluarkan oleh US General Accounting Office (GAO). Dari hasil audit tersebut dapat dilakukan evaluasi item mana saja yang perlu dibenahi dan langkah-langkah yang perlu diambil untuk perbaikan penerapan sistem informasi di organisasi tersebut. 1.2 Rumusan Masalah Permasalahan utama dalam penelitian ini yaitu kesulitan yang dihadapi oleh Taspen dalam penerapan kontrol sistem informasi untuk memastikan integritas data dalam manajemen data peserta. Diperlukan suatu framework yang dapat dijadikan sebagai bahan evaluasi untuk mengatasi permasalahan tersebut. Untuk itu, penelitian ini ditujukan untuk menjawab research question sebagai berikut: 1. Bagaimana penerapan kontrol sistem informasi di Taspen untuk mencapai integritas data? 2. Apa saja langkah-langkah perbaikan agar integritas data di Taspen terjamin? 3. Apakah langkah-langkah perbaikan telah dapat mengatasi hasil temuan audit BPK?

2
Universitas Indonesia

1.3 Tujuan Berdasarkan permasalahan penelitian yang telah diungkapkan sebelumnya, maka tujuan dari penyusunan karya akhir ini sebagai berikut: a. Mengetahui penerapan kontrol sistem informasi dalam manajemen data peserta di PT Taspen (Persero) untuk mencapai integritas data. b. Mengetahui langkah-langkah perbaikan agar integritas data dalam manajemen data peserta di PT Taspen (Persero) terjamin. c. Mengetahui apakah langkah-langkah perbaikan telah dapat mengatasi hasil temuan audit BPK. 1.4 Telaah Karya Akhir Sebelumnya Topik tentang audit sistem informasi belum banyak dikaji di Magister Teknologi Informasi. Dua di antara beberapa topik penelitian tentang audit sistem informasi yaitu audit untuk keamanan informasi di Mobile Internet Services Company dan audit untuk mengevaluasi manajemen teknologi informasi di Universitas XYZ.

Topik pertama berfokus pada mengacu network security dengan standar ISO/IEC 17799:2000. Hasil analisis berupa rekomendasi-rekomendasi peningkatan, perancangan ulang, maupun solusi-solusi lain untuk

mendapatkan infrastruktur information security yang handal. Sedangkan topik kedua mengevaluasi kinerja TI secara umum dengan menggunakan 210 detailed control objective pada COBIT. Hasil analisis berupa temuan untuk perbaikan manajemen TI yang lebih baik.

Sementara pada penelitian ini berfokus pada pencapaian integritas data pada aplikasi manajemen peserta, dari segi kontrol keamanan, proses bisnis, kontrol antarmuka, dan kontrol manajemen data. Pendekatan yang digunakan adalah FISCAM dan COBIT 4.1. Hasil analisis nantinya berupa kelemahankelemahan kontrol untuk perbaikan manajemen data peserta yang lebih baik.

3
Universitas Indonesia

1.5 Manfaat Manfaat yang diharapkan dari penelitian ini adalah: a. Memberikan panduan bagaimana melakukan langkah-langkah untuk memastikan integritas data pada manajemen data peserta di PT Taspen (Persero) dengan pendekatan FISCAM dan COBIT 4.1. b. Memberikan sebuah model kerangka kerja penerapan manajemen data peserta yang terjamin integritasnya sesuai dengan ketentuan pemerintah.

1.6 Ruang Lingkup Penelitian Ruang lingkup penelitian ini yaitu manajemen data peserta berupa data peserta aktif dan pensiunan pada PT Taspen (Persero). Adapun aplikasi core business yang digunakan untuk manajemen data peserta berada pada kantor pusat dan kantor-kantor cabang. Aplikasi core business yang menjadi fokus penelitian ini adalah modul manajemen data peserta, tidak termasuk modul keuangan seperti modul pembayaran klim.

1.7 Sistematika Penulisan Penulisan karya akhir ini menggunakan sistematika penulisan sebagai berikut: 1. BAB 1 : PENDAHULUAN Bab ini berisi latar belakang masalah, rumusan masalah, tujuan, telaah dari karya akhir-karya akhir sebelumnya yang sejenis, manfaat penelitian, ruang lingkup penelitian, dan sistematika penulisan. 2. BAB 2 : TINJAUAN PUSTAKA Bab ini memuat tinjauan teori-teori yang digunakan penulis sebagai referensi dalam menyusun karya akhir ini. 3. BAB 3: METODOLOGI PENELITIAN Bab ini menjelaskan langkah-langkah dan teknik analisis yang digunakan dalam penelitian dan penyusunan karya akhir ini. 4. BAB 4 : PROFIL PERUSAHAAN Bab ini memuat profil PT Taspen (persero) dan deskripsi tentang aplikasi core business modul manajemen data peserta.

4
Universitas Indonesia

5. BAB 5: ANALISIS DAN REKOMENDASI Bab ini berisikan analisis dan interpretasi manajemen data peserta di PT Taspen (Persero) dengan pendekatan FISCAM dan COBIT 4.1, serta rekomendasi untuk meningkatkan integritas data, termasuk rekomendasi untuk menangani temuan audit BPK. 6. BAB 6: KESIMPULAN DAN SARAN Bab ini memuat kesimpulan dan saran dari analisis dan kajian yang telah dilakukan.

5
Universitas Indonesia

BAB 2 TINJAUAN PUSTAKA

Bab berikut menjelaskan tentang landasan teori yang digunakan sebagai referensi dan teknik analisis.

2.1 Audit Sistem Informasi 3 Audit sistem informasi mulai banyak dilakukan di organisasi dan perusahaan karena ketergantungan perusahaan terhadap komputer untuk pemrosesan data, pemeliharaan dan pelaporan informasi semakin meningkat. Keandalan data dan sistem informasi menjadi perhatian utama auditor, termasuk kontrol internal dari sistem tersebut. Selain untuk efisiensi, tujuannya untuk mengurangi risiko kerugian karena kesalahan, manipulasi, tindakan illegal lainnya, serta insiden yang menyebabkan sistem menjadi tidak tersedia [General Accounting Office, 2009]. 4 Definisi audit sistem informasi yaitu proses pengumpulan dan penilaian bukti untuk menentukan apakah sistem komputer perusahaan mampu mengamankan harta, memelihara kebenaran data, dan mampu menuju tujuan perusahaan secara efektif [Gondodiyoto & Hendarti, 2006]. Audit sistem informasi memberikan evaluasi yang bersifat independen atas kebijakan, prosedur, standar, pengukuran, dan praktik untuk menjaga/mencegah informasi yang bersifat elektronik dari kehilangan, kerusakan, penelusuran yang tak disengaja dan sebagainya [NSAA & GAO, 2001].

Audit SI secara umum mencakup hal-hal sebagai berikut: meninjau lingkungan dan fisik, administrasi sistem, software aplikasi, keamanan jaringan, kontinuitas bisnis, dan integritas data [Gondodiyoto & Hendarti, 2006].

6
Universitas Indonesia

2.1.1 Tujuan Tujuan audit sistem informasi untuk meninjau dan memberikan umpan balik, menjamin, dan melakukan rekomendasi mengenai tiga hal sebagai berikut ketersediaan (availability), kerahasiaan (confidentiality), dan integritas.

Detail tentang tujuan audit sistem informasi dijelaskan Gondodiyoto & Hendarti, 2006, sebagai berikut: 1. Untuk mengidentifikasi sistem yang ada baik yang ada pada tiap divisi/unit/departemen ataupun yang digunakan menyeluruh. 2. Untuk dapat lebih memahami seberapa besar sistem informasi mendukung kebutuhan strategis perusahaan, operasi perusahaan, mendukung kegiatan operasional departemen/unit/divisi, kelompok kerja maupun para petugas dalam melaksanakan kegiatannya. 3. Untuk mengetahui pada bidang atau area mana, fungsi, kegiatan atau business process yang didukung dengan sistem serta teknologi informasi yang ada. 4. Untuk menganalisis tingkat pentingnya data/informasi yang

dihasilkan oleh sistem dalam rangka mendukung kebutuhan para pemakaiannya. 5. Untuk mengetahui keterkaitan antara sistem pengolahan dan transfer informasi. 6. Untuk mengidentifikasi apakah ada kesenjangan antara sistem dan kebutuhan. 7. Untuk membuat peta dari alur informasi yang ada.

2.1.2 Tahapan Audit Tahapan audit sistem informasi menurut Weber, 1999, terdiri dari perencanaan audit, pengujian pengendalian, pengujian substantive, dan penyelesaian audit. [Gondodiyoto & Hendarti, 2006]

7
Universitas Indonesia

Sementara berdasarkan CISA Review Manual, 2009, ada beberapa langkah dalam perencanaan audit: 1. Memahami misi organisasi, sasaran, tujuan, dan proses-proses, termasuk informasi dan kebutuhan pengolahan, seperti ketersediaan, integritas, keamanan dan teknologi bisnis, serta kerahasiaan informasi. 2. Mengidentifikasi konten organisasi, seperti kebijakan, standar, panduan, prosedur, dan struktur organisasi. 3. Menampilkan analisis risiko untuk membantu merancang rencana audit. 4. Meninjau kontrol internal berkaitan dengan teknologi informasi. 5. Merancang ruang lingkup dan sasaran audit. 6. Menyusun pendekatan audit berdasarkan strategi audit. 7. Menyediakan SDM untuk melakukan audit. 8. Menentukan kebutuhan logistik.

Sedangkan untuk mendapatkan gambaran tentang bisnis dan organisasi maka auditor sistem informasi perlu melakukan hal-hal sebagai berikut: 1. Melakukan tur fasilitas organisasi. 2. Membaca laporan tahunan, laporan analisis keuangan independen, dan publikasi organisasi. 3. Meninjau strategi jangka panjang bisnis dan TI. 4. Melakukan wawancara ke narasumber utama untuk memahami isyu bisnis. 5. Meninjau laporan audit sebelumnya atau laporan yang berkaitan dengan TI. 6. Mengidentifikasi regulasi yang spesifik yang diterapkan pada TI. 7. Mengidentifikasi fungsi TI atau yang berkaitan yang di-outsourced.

8
Universitas Indonesia

2.2 Panduan Audit Ada beberapa panduan audit yang umum digunakan, seperti COSO, COBIT, IT-IL, dan ISO 27001. Dalam karya akhir ini menggunakan pendekatan framework COBIT 4.1 dengan panduan pertanyaan dari FISCAM yang dipublikasikan US GAO.

2.2.1 COBIT Control Objectives for Information and Related Technology (COBIT) diperkenalkan pada tahun 1996 oleh The Information System Audit and Control Foundation. Pada tahun 1998 IT Governance Institute (ITGI) berdiri dengan tujuan untuk memimpin riset pada area vital pada tatakelola teknologi informasi. Fokus utamanya pada framework COBIT, proses, tujuan kontrol, dan model kematangan. Pada tahun yang sama The Information System Audit and Control Foundation dan ITGI melebur menjadi satu entitas dan mempublikasikan COBIT edisi ketiga pada tahun 2000 dan diikuti versi keempat pada tahun 2005.

Dalam situsnya, ITGI mengumumkan bahwa framework COBIT memudahkan Chief Information Officer (CIO) membantu stakeholder memahami proses teknologi informasi dan layanan, serta secara mudah berintegrasi dengan standar lain seperti ITIL, ISO 27002, dan COSO. Stakeholder juga dapat menggunakan COBIT sebagai instrumen untuk mengelola informasi yang disediakan teknologi informasi untuk mendukung proses bisnis.

Kontrol COBIT terdiri dari empat domain yang meliputi sebuah siklus manajemen TI. Keempat domain tersebut dapat dilihat pada gambar 2.1. Tiap-tiap kontrol mendukung standar informasi, yaitu standar kualitas (efektif dan efisien), standar keamanan (confidentiality, integritas, dan ketersediaan (availability)), dan fiduciary requirement (kepatuhan dan reliabilitas).

9
Universitas Indonesia

10

Gambar 2.1: Empat Domain COBIT (COBIT 4.1, IT Governance Institute, 2007)

Dalam penulisan karya akhir ini ada enam kontrol yang mendukung integritas data. Yaitu PO2, PO9, AI6, DS5, DS11, dan DS12.

Penjelasan tiap-tiap kontrol sebagai berikut: 2.2.1.1 PO2 (Menentukan Arsitektur Informasi) Fungsi sistem informasi menyusun dan meng-update model informasi bisnis serta menentukan sistem yang tepat untuk mengoptimalkan penggunaan informasi. Hal ini meliputi 10
Universitas Indonesia

11

pengembangan kamus data (data dictionary) dengan data syntax rules, data classification scheme, dan level keamanan (security level) organisasi. Proses ini bertujuan meningkatkan kualitas pembuatan keputusan manajemen dengan memastikan informasi yang tersedia merasionalisasi aman dan terpercaya daya sistem serta memudahkan untuk

sumber

informasi

menyelaraskan dengan strategi bisnis. Proses-proses TI ini juga diperlukan untuk meningkatkan akuntabilitas dengan integritas dan keamanan data serta meningkatkan efektivitas dan kontrol pembagian informasi melalui aplikasi dan entitas.

Kontrol proses TI melalui penentuan arsitektur informasi. Hal ini dipenuhi dengan kelincahan (agile) dalam merespon kebutuhan, untuk menyediakan informasi yang konsisten dan terpercaya serta untuk menyelaraskan aplikasi yang terintegrasi ke dalam proses-proses bisnis. PO2 berfokus pada pembuatan model data enterprises yang meliputi data classification scheme untuk memastikan integritas dan kekonsistensian seluruh data. Hal ini tercapai dengan memastikan keakurasian arsitektur informasi dan model data, menentukan kepemilikan data,

mengklasifikasikan informasi menggunakan skema klasifikasi yang telah disepakati. PO2 kemudian diukur dengan jumlah elemen data terduplikasi/redundan (persen), jumlah aplikasi yang tidak menggunakan metodologi arsitektur informasi yang digunakan perusahaan (persen), dan frekuensi aktivitas validasi data

PO2 terdiri dari: 1. PO2.1 : Model Arsitektur Informasi Organisasi (Enterprise Information Architecture Model) Menyusun dan memelihara model informasi organisasi untuk memudahkan pengembangan aplikasi dan aktivitas

11
Universitas Indonesia

12

pendukung keputusan, konsisten dengan IT plan yang telah dideskripsikan dalam PO1. Model tersebut seharusnya memfasilitasi kreasi optimal, penggunaan bersama informasi oleh bisnis namun tetap terpelihara integritas, fleksibel, fungsional, efektif biaya, tepat waktu, aman, dan mudah diperbaiki. 2. PO2.2 Kamus Data Organisasi (Enterprise Data Dictionary) dan Data Syntax Rules Memelihara enterprise data dictionary yang meliputi data syntax rules. Data dictionary seharusnya memudahkan penggunaan bersama elemen data di antara aplikasi dan sistem, mendukung pemahaman bersama data oleh user bisnis dan TI dan mencegah terbentuknya elemen data yang tidak tepat. 3. PO2.3 Data Classification Scheme Menyusun skema klasifikasi (classification scheme) yang diterapkan oleh organisasi berdasarkan kekritisan dan sensitivitas data organisasi (misal: public, confidential, top secret). Skema ini terdiri dari kepemilikan data, definisi level keamanan, dan kontrol proteksi; deskripsi singkat tentang retensi data dan kebutuhan pemusnahan, kekritisan dan sensitivitas. Hal ini menjadi dasar untuk mengaplikasikan kontrol seperti kontrol akses, pengarsipan, dan enkripsi. 4. PO2.4: Manajemen Integritas ( Integrity Management) Mendefinisikan dan menerapkan prosedur untuk memastikan integritas dan kekonsistensian semua data yang tersimpan dalam formulir elektronik, seperti database, data warehouse, dan data archives.

12
Universitas Indonesia

13

Gambar 2.2: Standar Informasi, Jenis dan Fokus Area yang Didukung PO2 (COBIT 4.1, IT Governance Institute, 2007)

Dengan menerapkan PO2 maka akan meningkatkan efisiensi dan integritas. Selain itu juga akan meningkatkan efektivitas dan kerahasiaan (confidentiality). PO2 berfokus pada aplikasi dan informasi. Sasaran proses ini terutama mendukung strategic alignment. Selain itu, juga mendukung risk dan resource management.

Gambar 2.3: Input dan Output PO2 (COBIT 4.1, IT Governance Institute, 2007)

PO2 menjadi input DS5, DS10, dan DS12 yang akan dibahas dalam sub bab berikutnya.

13
Universitas Indonesia

14

Gambar 2.4: Sasaran Metrik PO2 (COBIT 4.1, IT Governance Institute, 2007)

2.2.1.2 PO9 (Pengukuran dan Pengelolaan Risiko TI) Framework manajemen risiko disusun dan dipelihara

(maintained). Framework mendokumentasikan level risiko TI yang telah disepakati dan bersifat umum, strategi mitigasi, dan risiko yang masih tersisa (residual risk). Segala yang berdampak pada tujuan organisasi yang disebabkan peristiwa yang tidak terencana diidentifikasi, dianalisis, dan diukur. Strategi mitigasi risiko diadopsi untuk meminimalkan residual risk ke level yang masih diterima. Hasil pengukuran mudah dipahami oleh stakeholder dan diwujudkan dalam terminologi keuangan, untuk memudahkan stakeholder menyelaraskan risiko dengan level toleransi yang diterima.

PO9 mengkontrol proses mengukur dan memelihara risiko TI. Proses ini mencapai kebutuhan bisnis akan TI dengan menganalisis dan mengkomunikasikan risiko TI dan dampaknya bagi proses bisnis dan 14
Universitas Indonesia

sasaran.

PO9

berfokus

pada

15

pengembangan framework manajemen risiko yang terintegrasi dalam framework manajemen risiko operasional dan bisnis, pengukuran risiko (risk assessment), mitigasi risiko, dan pengkomunikasian residual risk. Hal tersebut tercapai dengan memastikan manajemen risiko termuat dalam proses manajemen baik internal maupun eksternal dan secara konsisten diterapkan, melaksanakan pengukuran risiko, merekomendasikan, dan mengkomunikasikan rencana aksi risk remediation.

Implementasi PO9 diukur dengan seberapa besar (persen) sasaran TI yang kritis tercakup dalam pengukuran risiko (risk assessment), identifikasi risiko TI yang kritis dengan rencana aksinya (persen), dan seberapa banyak (persen) rencana aksi manajemen risiko disetujui untuk diterapkan.

PO9 terdiri dari: 1. PO9.1: Framework Manajemen Risiko TI (IT Risk Management Framework) Menyusun framework manajemen risiko TI yang selaras dengan framework manajemen risiko organisasi. 2. PO9.2: Penyusunan Konteks Risiko (Establishment of Risk Context) Menyusun konteks dalam framework pengukuran risiko (risk assessment) yang diterapkan untuk memastikan hasil yang tepat. Hal ini seharusnya mencangkup konteks internal dan eksternal untuk tiap-tiap pengukuran risiko (risk

assessment), sasaran pengukuran, dan kriteria dimana risiko dievaluasi. 3. PO9.3: Identifikasi Even ( Event Identification) Identifikasi even (ancaman realistis yang mengeksploitasi kelemahan secara signifikan) yang berdampak negatif pada sasaran atau operasi organisasi, termasuk bisnis, regulator,

15
Universitas Indonesia

16

hukum, teknologi, rekan dagang, sumber daya manusia, dan aspek operasional. Selanjutnya, menentukan dampak dan menjaga informasi tersebut, merekam, dan menjaga risiko yang relevan dalam pencatatan risiko (risk registry). 4. PO9.4: Pengukuran Risiko (Risk Assessment) Menilai berdasarkan probabilitas dan dampak risiko-risiko yang teridentifikasi. Menggunakan metode kualitatif dan kuantitatif. Probabilitas dan dampak yang berasosiasi dengan residual risk seharusnya ditentukan masing-masing, per kategori berdasarkan portofolio. 5. PO9.5: Respon Risiko (Risk Response) Mengembangkan dan memelihara desain proses respon risiko untuk memastikan kontrol yang efektif biaya dalam mitigasi risiko secara berkelanjutan. Proses respon risiko seharusnya penghindaran, penentuan mengidentifikasi reduksi, strategi risiko seperti

pembagian jawab yang

atau

penerimaan, dan

tanggung

berasosiasi,

mempertimbangkan level toleransi risiko. 6. PO9.6: Pemeliharaan dan Pengawasan Rencana Aksi Risiko (Maintenance and Monitoring of a Risk Action Plan) Memprioritaskan dan merencanakan aktivitas kontrol di semua level untuk mengimplementasikan respon risiko yang teridentifikasi sebagai kewajiban, termasuk identifikasi biaya, manfaat, dan tanggung jawab untuk eksekusi. Mendapatkan persetujuan untuk aksi yang

direkomendasikan dan menerima residual risk, serta memastikan aksi dimiliki oleh pemilik proses. Monitor pelaksanaan dari rencana dan melaporkan segala deviasi ke manajemen senior.

16
Universitas Indonesia

17

Gambar 2.5: Standar Informasi, Jenis dan Fokus Area yang Didukung PO9 (COBIT 4.1, IT Governance Institute, 2007)

Dengan menerapkan PO9 maka akan memelihara kerahasiaan integritas, dan ketersediaan. Selain itu juga akan meningkatkan efektivitas,efisiensi, kepatuhan (compliance), dan kepercayaan (realiability). PO9 berfokus pada aplikasi, informasi,

infrastruktur, dan SDM. Sasaran proses ini terutama mendukung strategic alignment dan risk management.

Gambar 2.6: Input dan Output PO9 (COBIT 4.1, IT Governance Institute, 2007)

Dari gambar 2.6 terlihat bahwa PO9 mendapat input dari DS5. Namun, PO9 juga menjadi inputan bagi AI6, DS5, dan DS12.

17
Universitas Indonesia

18

Gambar 2.7: Sasaran Metrik PO9 (COBIT 4.1, IT Governance Institute, 2007)

2.2.1.3 AI6 (Manajemen Perubahan) Semua perubahan, termasuk pemeliharaan darurat, dan patches, berhubungan dengan infrastruktur dan aplikasi, dalam

lingkungan produksi secara formal dikelola dalam tata cara terkontrol (controlled manner). Perubahan (termasuk prosedur, proses, sistem, dan parameter sistem) dicatat (logged), diukur, dan diotorisasi sebelum diimplementasikan, dan ditinjau berdasarkan hasil yang diharapkan. Hal ini memastikan mitigasi risiko dari dampak negatif pada kestabilan atau integritas lingkungan produksi.

AI6 mengontrol proses TI dalam hal manajemen perubahan untuk menyelaraskan kebutuhan bisnis dengan strategi bisnis, selagi mengurangi cacat pengantaran layanan dan solusi serta kerja ulang (rework). Fokus AI6 yaitu mengontrol pengukuran dampak, otorisasi, dan implementasi semua perubahan dari

18
Universitas Indonesia

19

infrastruktur TI, aplikasi, dan solusi teknik, meminimalkan kesalahan karena spesifikasi permintaan yang tidak komplet, dan menghentikan implementasi karena perubahan yang tidak terotorisasi.

Keberhasilan

AI6

tercapai

dengan

mendefinisikan

dan

mengkomunikasikan prosedur perubahan, termasuk perubahan darurat. Mengukur, memprioritaskan dan mengotorisasi

perubahan, serta menelusuri status dan melaporkan perubahan.

AI6 diukur dengan jumlah kesalahan data atau rusak karena spesifikasi yang tidak akurat atau pengukuran dampak yang tidak komplet, jumlah aplikasi atau infrastruktur yang dikerjakan ulang disebabkan spesifikasi perubahan yang tidak cukup, jumlah (persen) perubahan yang mengikuti proses kontrol perubahan secara formal.

AI6 terdiri dari: 1. AI6.1: Perubahan Standar dan Prosedur (Change Standards and Procedures) Menata prosedur manajemen perubahan secara formal untuk menangani sikap yang terstandar (standardised manner) semua permintaan (termasuk pemeliharaan dan patches) untuk mengubah aplikasi, prosedur, proses, sistem, dan parameter sistem, serta platform yang mendasarinya. 2. AI6.2: Pengukuran Dampak, Prioritasi, dan Otorisasi (Impact Assessment, Prioritisation and Authorisation) Mengukur semua permintaan perubahan secara terstruktur untuk menentukan dampak Memastikan sistem bahwa operasi dan

fungsionalitasnya.

perubahan

terkategorisasi, terprioritasi, dan terotorisasi.

19
Universitas Indonesia

20

3. AI6.3: Perubahan Darurat (Emergency Changes) Menyusun proses untuk mendefinisikan, menghidupkan, menguji, mendokumentasikan, mengukur/menilai, dan

mengotorisasi perubahan darurat yang tidak mengikuti proses perubahan yang telah disusun. 4. AI6.4 Perubahan Penelusuran Status dan Pelaporan

(Change Status Tracking and Reporting) Menyusun penelusuran dan sistem pelaporan yang untuk ditolak,

mendokumentasikan

perubahan

mengkomunikasikan status yang disetujui dan perubahan yang masih dalam proses, serta perubahan yang telah komplet. Memastikan bahwa perubahan yang disetujui diterapkan sesuai rencana. 5. AI6.5 : Change Closure dan Dokumentasi Kapanpun perubahan terimplementasi, update sistem yang berasosiasi dan dokumentasi user, serta prosedur yang melandasinya.

Gambar 2.8: Standar Informasi, Jenis dan Fokus Area yang Didukung AI6
(COBIT 4.1, IT Governance Institute, 2007)

Dengan menerapkan AI6 maka akan memelihara efektivitas, efisiensi, integritas, dan ketersediaan. Selain itu juga akan meningkatkan kepercayaan (realiability). AI6 berfokus pada aplikasi, informasi, infrastruktur, dan SDM. Sasaran proses ini terutama mendukung value delivery. Selain itu mendukung resource management.

20
Universitas Indonesia

21

Gambar 2.9: Input dan Output AI6 (COBIT 4.1, IT Governance Institute, 2007)

Dari gambar 2.9 terlihat bahwa AI6 mendapat input dari PO9 dan DS5.

Gambar 2.10: Sasaran Metrik AI6 (COBIT 4.1, IT Governance Institute, 2007)

2.2.1.4 DS5 (Memastikan Keamanan Sistem) Kebutuhan untuk menjaga integritas informasi dan melindungi aset TI memerlukan proses manajemen keamanan. Proses ini meliputi penyusunan dan memelihara peranan-peranan

keamanan (security roles) serta tanggung jawab, kebijakan, standar, dan prosedur. Manajemen keamanan juga mencakup

21
Universitas Indonesia

22

pengawasan keamanan dan ujicoba secara periodik, serta mengimplementasikan aksi perbaikan untuk kelemahan

kekurangan atau insiden/bencana. Manajemen keamanan yang efektif melindungi semua aset TI untuk meminimalkan dampak bisnis terhadap kelemahan keamanan dan insiden.

DS5 mengontrol proses untuk memastikan keamanan sistem. Tujuannya memelihara integritas informasi dan infrastruktur pemrosesan, serta meminimalkan dampak kelemahan keamanan dan insiden. Sasaran proses DS5 berfokus pada mendefinisikan kebijakan keamanan TI, rencana dan prosedur, serta

pengawasan, deteksi, pelaporan, dan mengatasi kelemahan keamanan dan insiden.

Keberhasilan pelaksanaan DS5 tercapai dengan pemahaman kebutuhan keamanan, kelemahan, dan ancaman; mengelola identitas user dan otorisasi dalam prosedur standar, ujicoba keamanan secara reguler. Hal ini terukur dengan jumlah insiden yang merusak reputasi organisasi terhadap publik, jumlah sistem dimana kebutuhan keamanan tidak sesuai, dan jumlah pelanggaran konflik tugas.

DS5 terdiri dari: 1. DS5: Manajemen Keamanan TI (Management of IT Security) Manajemen keamanan TI pada level organisasi yang tertinggi sehingga tindakan manajemen keamanan selaras dengan kebutuhan bisnis. Menerjemahkan bisnis, risiko, dan kepatuhan (compliance) ke dalam rencana keamanan TI secara keseluruhan, dengan mempertimbangkan

infrastruktur TI dan budaya keamanan.

22
Universitas Indonesia

23

2. DS5.2: Rencana Keamanan TI (IT Security Plan) Memastikan rencana diimplementasikan dalam prosedur dan kebijakan keamanan bersama-sama investasi yang tepat dalam layanan, personel, software, dan hardware.

Mengkomunikasikan kebijakan dan prosedur keamanan kepada stakeholder dan user. 3. DS5.3 : Manajemen Identitas (Identity Management) Memastikan semua user (internal, eksternal, dan temporer) dan aktivitas mereka dalam sistem TI (bisnis, aplikasi, lingkungan TI, operasi sistem, pengembangan, dan

pemeliharaan) secara unik teridentifikasi. Memudahkan user mengidentifikasi melalui mekanisme otentikasi.

Mengkonfirmasi bahwa hak akses pengguna ke sistem dan data sesuai dengan yang ditetapkan, kebutuhan bisnis yang didokumentasikan, dan kebutuhan kerja yang melekat pada identitas pengguna. Memastikan bahwa hak akses pengguna diminta oleh manajemen pengguna, disetujui oleh pemilik sistem dan diimplementasikan oleh penanggung jawab keamanan. Memelihara identitas pengguna dan hak akses dalam repositori pusat. Menyebarkan langkah-langkah teknis yang efektif biaya dan pengukuran prosedural, dan menjaganya agar terus update dalam membuat identifikasi user, implementasi otentikasi, dan memaksakan hak akses. 4. DS5.4: Manajemen Akun User (User Account Management) Menempatkan permintaan, penyusunan, penerbitan,

penangguhan, pemodifikasian, dan penutupan akun user serta hak-hak user yang berkaitan dengan rangkaian prosedur manajemen akun user. Termasuk, prosedur persetujuan yang menguraikan data atau pemilik sistem pemberian hak akses. Prosedur ini harus berlaku untuk semua user, termasuk administrator (hak akses) dan user internal dan eksternal, untuk normal dan kasus-kasus

23
Universitas Indonesia

24

darurat. Hak dan kewajiban relatif terhadap akses ke sistem organisasi dan informasi seharusnya dicantumkan dalam kontrak kerja semua jenis user. Berikutnya, melakukan peninjauan manajemen secara teratur setiap akun dan hak yang berhubungan. 5. DS5.5: Ujicoba Keamanan, Penjagaan, dan Pemantauan (Security Testing, Surveillance and Monitoring) Menguji dan memantau implementasi keamanan TI dalam langkah yang proaktif. Keamanan TI seharusnya ditinjau secara periodik untuk memastikan landasan keamanan informasi organisasi yang disetujui yang dipelihara. Logging dan fungsi pemantauan akan memudahkan untuk

pencegahan awal dan/atau pendeteksi dan sewaktu-waktu melaporkan aktivitas yang tidak seperti biasanya/abnormal yang perlu diperhatikan. 6. DS5.6: Definisi Insiden Keamanan (Security Incident Definition) Mendefinisikan secara jelas dan mengkomunikasikan karakteristik dari insiden keamanan yang potensial sehingga dapat diklasifikasikan dan diperlakukan dengan baik oleh peristiwa dan proses manajemen masalah. 7. DS5.7: Proteksi Teknologi Keamanan (Protection of Security Technology) Membuat teknologi keamanan tahan terhadap gangguan, dan tidak mengungkapkan dokumentasi keamanan yang tidak perlu. 8. DS5.8: Manajemen Kunci Kriptografi (Cryptographic Key Management) Menentukan bahwa kebijakan dan prosedur sesuai untuk mengatur perubahan, pembatalan, penghancuran, distribusi, sertifikasi, penyimpanan, memasuki, penggunaan, dan pengarsipan kunci kriptografi untuk memastikan

24
Universitas Indonesia

25

perlindungan kunci terhadap modifikasi dan pengungkapan yang tidak sah. 9. DS5.9: Pencegahan Software Berbahaya, Deteksi, dan Perbaikan (Malicious Software Prevention, Detection and Correction) Memasang pencegahan, pendeteksi, dan langkah-langkah perbaikan yang sesuai (terutama patch keamanan yang upto-date dan pengendalian virus) di seluruh organisasi untuk melindungi sistem informasi dan teknologi dari malware (seperti virus, worm, spyware, dan spam). 10. DS5.10 : Jaringan Keamanan (Network Security) Menggunakan teknik keamanan dan prosedur manajemen yang terkait (misalnya, firewall, peralatan keamanan, segmentasi jaringan, dan deteksi gangguan) untuk

mengotorisasi akses dan kontrol arus informasi dari dan ke jaringan. 11. DS5.11: Pertukaran Data Sensitif (Exchange of Sensitive Data) Pertukaran data transaksi sensitif hanya melalui jalur terpercaya atau media dengan kontrol untuk menyediakan keaslian konten, bukti pengiriman, bukti penerimaan, dan non-repudiation.

Gambar 2.11: Standar Informasi, Jenis dan Fokus Area yang Didukung DS5
(COBIT 4.1, IT Governance Institute, 2007)

Dengan menerapkan DS5 maka akan memelihara kerahasiaan dan integritas. Selain itu juga akan meningkatkan ketersediaan 25
Universitas Indonesia

26

(availability), kepatuhan, dan kepercayaan (realiability). DS5 berfokus pada aplikasi, informasi, infrastruktur, dan SDM. Sasaran proses ini terutama mendukung risk management.

Gambar 2.12: Input dan Output DS5 (COBIT 4.1, IT Governance Institute, 2007)

Dari gambar 2.6 terlihat bahwa DS5 mendapat input dari PO2 dan PO9. Namun, DS5 juga menjadi inputan bagi AI6, PO9, dan DS11.

Gambar 2.13: Sasaran Metrik DS5 (COBIT 4.1, IT Governance Institute, 2007)

26
Universitas Indonesia

27

2.2.1.5 DS11 (Mengelola Data) Manajemen data yang efektif memerlukan identifikasi

persyaratan data. Proses pengelolaan data juga mencakup pembentukan prosedur yang efektif untuk mengelola media library, backup, dan pemulihan data, serta media pembuangan yang tepat. Pengelolaan data yang efektif membantu

memastikan kualitas, ketepatan waktu, dan ketersediaan data bisnis.

Proses TI dikontrol dengan mengelola data yang membantu mengoptimalkan penggunaan informasi dan memastikan

informasi tersedia seperti yang dibutuhkan. DS11 berfokus pada pemeliharaan kelengkapan, keakuratan, ketersediaan, dan perlindungan data. Keberhasilan proses ini tercapai dengan melakukan backup daya dan ujicoba proses pemulihan, memelihara penyimpanan data onsite dan offsite, serta pembuangan data dan peralatan secara aman.

Proses ini diukur dengan tingkat kepuasan user dengan ketersediaan data (persen), tingkat pemulihan data yang berhasil (persen), dan jumlah insiden dimana data sensitif diambil setelah media dibuang.

DS11 terdiri dari: 1. DS11.1: Persyaratan Bisnis untuk Manajemen Data

(Business Requirements for Data Management) Melakukan verifikasi bahwa semua data yang diharapkan untuk pengolahan diterima dan diproses secara lengkap, akurat, dan tepat waktu, serta seluruh output yang dikirim sesuai dengan kebutuhan bisnis, mendukung restart, dan pengolahan kebutuhan.

27
Universitas Indonesia

28

2. DS11.2: Penyimpanan dan Pengaturan Retensi (Storage and Retention Arrangements) Menetapkan dan menerapkan prosedur untuk penyimpanan data secara efektif dan efisien, retensi, serta pengarsipan untuk memenuhi tujuan bisnis, kebijakan keamanan organisasi, dan persyaratan peraturan. 3. DS11.3: Sistem Manajemen Media Library (Media Library Management System) Menetapkan dan menerapkan prosedur untuk menjaga inventarisasi media penyimpanan dan pengarsipan untuk memastikan kegunaan (usability) dan integritas. 4. DS11.4: Pembuangan (Disposal) Menetapkan dan menerapkan prosedur untuk memastikan bahwa persyaratan bisnis untuk perlindungan data sensitif dan software terpenuhi ketika data dan perangkat keras dibuang atau dialihkan. 5. DS11.5: Backup dan Pemulihan Sistem (Backup and Restoration) Menetapkan dan menerapkan prosedur untuk backup dan pemulihan sistem, aplikasi, data, dan dokumentasi sesuai dengan kebutuhan bisnis dan rencana kesinambungan. 6. DS11.6: Persyaratan Keamanan untuk Manajemen Data (Security Requirements for Data Management) Menetapkan dan mengimplementasikan kebijakan dan prosedur untuk mengidentifikasi dan menerapkan

persyaratan keamanan yang berlaku untuk penerimaan, pengolahan, penyimpanan, dan output data untuk memenuhi tujuan bisnis, kebijakan keamanan organisasi, dan peraturan.

28
Universitas Indonesia

29

Gambar 2.14: Standar Informasi, Jenis dan Fokus Area yang Didukung DS11
(COBIT 4.1, IT Governance Institute, 2007)

Dengan menerapkan DS11 maka akan memelihara integritas, dan kepercayaan. DS11 berfokus pada informasi. Sasaran proses ini terutama mendukung value delivery, resource management, dan risk management.

Gambar 2.15: Input dan Output DS11 (COBIT 4.1, IT Governance Institute, 2007)

Dari gambar 2.15 terlihat bahwa DS11 mendapat input dari PO2 dan DS5.

29
Universitas Indonesia

30

Gambar 2.16: Sasaran Metrik DS11 (COBIT 4.1, IT Governance Institute, 2007)

2.2.1.6 DS12 (Mengelola Lingkungan Fisik) Perlindungan untuk peralatan komputer dan personel

memerlukan fasilitas fisik yang didesain dan dikelola dengan baik. Proses pengelolaan lingkungan fisik meliputi aktivitas mendefinisikan persyaratan lokasi fisik, memilih fasilitas yang sesuai, dan perancangan proses yang efektif untuk mengawasi faktor-faktor lingkungan serta mengelola akses fisik.

Manajemen yang efektif dari lingkungan fisik mengurangi gangguan bisnis dari kerusakan peralatan komputer dan personel.

DS12

melakukan

kontrol

proses

TI

seperti

mengelola

lingkungan fisik untuk melindungi aset komputer dan data bisnis untuk meminimalkan risiko gangguan bisnis. DS12 berfokus pada menyediakan dan memelihara lingkungan fisik yang cocok untuk melindungi aset TI dari akses, kerusakan, atau pencurian.

30
Universitas Indonesia

31

Proses ini tercapai dengan mengimplementasikan pengukuran keamanan fisik, menyeleksi, dan mengelola fasilitas. DS12 diukur dengan jumlah downtime karena insiden lingkungan fisik, jumlah insiden karena pelanggaran atau kegagalan keamanan, serta frekuensi pengukuran dan peninjauan risiko fisik.

DS12 terdiri dari: 1. DS12.1: Memilih dan Tata Letak Situs (Site Selection and Layout) Mendefinisikan dan memilih situs fisik untuk peralatan IT yang mendukung strategi teknologi terkait dengan strategi bisnis. Pemilihan dan desain tata letak situs harus memperhitungkan risiko yang terkait dengan bencana alam dan buatan manusia, sementara mempertimbangkan undangundang dan peraturan yang relevan, seperti peraturan keselamatan dan kesehatan tenaga kerja. 2. S12.2: Langkah-langkah Keamanan Fisik (Physical Security Measures) Menetapkan dan menerapkan langkah-langkah keamanan fisik sesuai dengan kebutuhan bisnis untuk mengamankan lokasi dan aset fisik. Langkah-langkah keamanan fisik harus mampu mencegah secara efektif, mendeteksi, dan

mengurangi risiko yang berkaitan dengan pencurian, suhu, api, asap, air, getaran, teror, vandalisme, pemadaman listrik, bahan kimia, atau bahan peledak. 3. S12.3: Akses Fisik (Physical Access) Menetapkan dan menerapkan prosedur untuk memberikan, membatasi, dan mencabut akses ke lokasi, bangunan dan area sesuai dengan kebutuhan bisnis, termasuk kondisi darurat. Akses ke lokasi, bangunan, dan area harus

31
Universitas Indonesia

32

terotorisasi, tercatat, dan terpantau. Hal ini seharusnya berlaku untuk semua orang yang memasuki tempat, termasuk staf, staf temporer, klien, vendor, pengunjung, atau pihak ketiga lainnya. 4. DS12.4: Perlindungan Terhadap Faktor Lingkungan

(Protection Against Environmental Factors) Mendesain dan menerapkan langkah-langkah untuk

perlindungan terhadap faktor lingkungan. Meng-install peralatan dan perangkat khusus untuk memantau dan mengontrol lingkungan. 5. DS12.5 : Manajemen Fasilitas Fisik (Physical Facilities Management) Mengelola fasilitas, termasuk tenaga dan peralatan

komunikasi, sesuai dengan hukum dan peraturan, kebutuhan bisnis dan teknik, spesifikasi vendor, serta petunjuk keselamatan dan kesehatan.

Gambar 2.17: Standar Informasi, Jenis dan Fokus Area yang Didukung DS12 (COBIT 4.1, IT Governance Institute, 2007)

Dengan menerapkan

DS12

maka akan memelihara integritas dan

ketersediaan. DS12 berfokus infrastruktur. Sasaran proses ini terutama mendukung risk management dan resource management.

Gambar 2.18: Input dan Output DS12 (COBIT 4.1, IT Governance Institute, 2007)

32
Universitas Indonesia

33

Dari gambar 2.6 terlihat bahwa PO9 mendapat input dari DS5. Namun, PO9 juga menjadi inputan bagi AI6, DS5, dan DS12.

Gambar 2.19: Sasaran Metrik DS12 (COBIT 4.1, IT Governance Institute, 2007)

2.2.2 FISCAM Federal Information System Control Audit Manual (FISCAM) menyajikan suatu metodologi untuk melakukan audit kontrol sistem informasi pada pemerintah federal dan instansi pemerintah berdasarkan standar profesional. Panduan audit kontrol sistem informasi ini dipublikasikan oleh US General Accounting Office (GAO). Metodologi yang digunakan untuk mengevaluasi kontrol dalam sistem meliputi kontrol umum pada tingkat entitas atau instalasi, kontrol umum seperti yang diterapkan pada aplikasi yang diperiksa misalnya sistem penggajian, dan aplikasi kontrol yang merupakan kontrol atas masukan, pengolahan, dan output data yang terkait dengan aplikasi individu.

33
Universitas Indonesia

34

Kontrol umum merupakan kebijakan dan prosedur yang berlaku untuk semua bagian dari entitas sistem informasi dan membantu memastikan mereka berlaku secara benar. Contohnya, pengamanan data, melindungi program aplikasi komputer, melindungi sistem perangkat lunak dari penyusup, dan memastikan keberlangsungan sistem apabila terjadi interupsi yang tidak diperkirakan. Efektivitas kontrol umum adalah penentu efektivitas kontrol aplikasi karena bisa terjadi manipulasi atau modifikasi.

Sedangkan kontrol aplikasi berhubungan dengan aplikasi individu. Mereka membantu memastikan transaksi valid, terotorisasi secara benar dan secara lengkap dan akurat diproses dan dilaporkan. Kontrol aplikasi terdiri dari teknik kontrol yang terprogram seperti edit otomatis dan panduan tindak lanjut seperti tinjauan laporan yang mengidentifikasi item yang tidak umum atau ditolak. Kedua kontrol tersebut harus efektif

Ada enam kategori kontrol umum yang perlu diperhatikan para auditor: 1. Manajemen dan perencanaan program keamanan organisasi, yaitu menyediakan framework dan siklus aktivitas untuk manajemen risiko, membangun kebijakan keamanan, membagi tanggung jawab, dan mengawasi kelemahan komputer berkaitan dengan kontrol. 2. Kontrol akses, berkaitan dengan pembatasan penggunaan sumber daya komputer meliputi data, program, peralatan,dan fasilitas, termasuk perlindungan dari adanya penyusup. 3. Kontrol perubahan dan pengembangan software aplikasi, yakni melindungi software aplikasi yang eksis dari adanya modifikasi yang tidak terotorisasi. 4. Kontrol software sistem, berkaitan dengan pembatasan dan pengawasan terhadap program dan file yang sensitif melalui monitoring terhadap hardware dan aplikasi yang didukung oleh sistem.

34
Universitas Indonesia

35

5. Pemisahan tugas, berkaitan dengan kebijakan, prosedur, dan struktur organisasi sehingga setiap individu tidak terjadi rangkap jabatan yang membuat ia mampu memodifikasi aplikasi atau data dengan tidak terotorisasi. 6. Kontrol kontinuitas layanan, untuk memastikan bahwa operasi bisnis yang kritis tetap berjalan meski terjadi interupsi, termasuk tetap terlindunginya data yang sensitif.

Sementara untuk mengetahui efektivitas kontrol integritas suatu sistem, selain kontrol umum, FISCAM juga melakukan audit kontrol proses bisnis, kontrol antarmuka, dan kontrol manajemen data.

2.2.3 Perbandingan dengan Framework Audit Lainnya Ada beragam framework audit selain COBIT yang banyak diaplikasikan oleh organisasi di berbagai negara, seperti COSO, IT-IL, dan ISO 27001. Setiap framework di atas memiliki latar belakang pembentukan dan area kontrol masing-masing seperti pada tabel 2.1

Tabel 2.1: Perbandingan Tiap Framework Audit

Komponen Pembanding Singkatan dari

COSO The Committee of Sponsoring Organizations of The Treadway Commission. Untuk menghindari terjadinya fraud atas laporan keuangan.

COBIT Control Objectives of Information and Related Technology. Untuk memberikan serangkaian langkah-langkah umum , indikator, proses, dan praktek terbaik dalam memaksimalkan penggunaan TI.

IT-IL IT Infrastructure Library.

ISO 27001 -

Latar Belakang Pembentukan Standar

Untuk membentuk proses TI standar dalam lembaga pemerintahan.

Adanya kebutuhan akan manajemen keamanan informasi.

35
Universitas Indonesia

36

Komponen Pembanding Poin-poin Utama

COSO COSO memiliki lima, Komponen yaitu: 1. Lingkungan Pengendalian, 2. Penilaian risiko, 3. Aktivitas pengendalian, 4. Informasi dan komunikasi, 5. Monitoring

COBIT COBIT memiliki empat domain, yaitu :plan and organize, (acquire and implement), deliver and support, monitor and evaluate.

IT-IL ITIL tediri dari lima topik: strategi layanan, desain layanna,, transisi layanan, operasi layanna dan peningkatan layanan secara berkelanjutan.

ISO 27001 ISO 27001 terdiri dari lima aspek: a. Security requirements of system. b. Security in application system. c. Cryptographic control d. Security of system files e. Security in development and support process Manajemen keamanan informasi

Fokus

Laporan keuangan yang bebas dari fraud

Tata kelola TI yang baik.

Kualitas layanan (efektif dan efisien)

2.3 Metode Penelitian Kuantitatif dan Kualitatif Secara dikotomi dikenal dua jenis metode penelitian yaitu kuantitatif dan kualitatif. Masing-masing metode, gaya, dan asumsi sendiri. Perbedaan antara metode kualitatif dan kuantitatif menurut Neil (2007) seperti yang terlihat dalam tabel di bawah ini:

Tabel 2.2: Perbedaan Metode Kualitatif dan Kuantitatif (http://wilderdom.com/research)

Kualitatif Tujuannya lengkap, deskripsinya detail.

Kuantitatif Tujuannya untuk mengklasifikasikan fitur, menghitungnya, dan mendesain model statistik untuk menjelaskan apa yang diobservasi.

Periset mungkin hanya tahu secara kasar apa yang dia cari. Direkomendasikan dilakukan selama fase awal dari proyek riset. Desain tidak menekankan studi tertentu, namun mengalir. Peneliti menggunakan instrumen pengumpulan data.

Periset mengetahui secara jelas dan mendalam apa yang dia cari. Direkomendasikan dilakukan selama fase lanjut dari proyek riset. Semua aspek dari studi secara hati-hati disusun sebelum data dikumpulkan. Peneliti menggunakan alat seperti kuesioner atau alat untuk mengumpulkan data numerik.

36
Universitas Indonesia

37

Kualitatif Data terdiri dari daftar kata, gambar, dan obyek. Subyektif, intepretasi individu dari sebuah even adalah penting misal observasi partisipasi user, wawancara mendalam dll. Data kualitatif lebih kaya, namun memakan waktu dan tidak dapat digeneralisasi. Peneliti cenderung menjadi subyektif dan tidak memisahkan dari subyek .

Kuantitatif Data terdiri dari daftar angka dan statistik.

Obyektif, mencari pengukuran dan analisis dari target secara presisi misal survei user, kuesioner dll.

Data kualitatif lebih efisien, dapat digunakan untuk menguji hipotesis tapi mungkin melewatkan detail kontekstual. Peneliti cenderung untuk tetap menjaga obyektifitas, terpisah dari subyek.

Sumber data dari dua metode penelitian tersebut juga berbeda. Metode kualitatif menggunakan studi pustaka, observasi, atau wawancara. Sedangkan metode kuantitatif mengumpulkan data berhubungan dengan angka dan segala sesuatu yang dapat diukur, misalnya dengan survei dan kuesioner.

Tahapan metode kuantitatif diawali dengan pengumpulan data; verifikasi, validasi, dan perekaman; dan analisis. Hasil analisis berupa pengolahan hasil statistik, tabel, dan grafik.

Baik metode kuesioner maupun wawancara terdiri dari dua jenis daftar pertanyaan, dapat berupa pertanyaan tertutup (close-ended question) atau terbuka (open-ended question). Perbedaannya terletak pada terbatas/tidaknya jawaban yang disediakan penanya. Apabila terdapat pembatasan jawaban, misal ya atau tidak atau penggunaan skala Likert maka disebut pertanyaan tertutup.

Berbeda dengan pertanyaan tertutup, pertanyaan terbuka memperbolehkan responden menjawab sesuai pemikirannya tanpa pembatasan. Pertanyaan terbuka bermanfaat untuk menggali isyu sensitif dan menginvestigasi topiktopik yang berhubungan dengan tindakan dan praktik kerja. Sedangkan pertanyaan tertutup cocok untuk topik yang faktual dan umum. Selain itu,

37
Universitas Indonesia

38

pengolahan hasil pertanyaan tertutup jauh lebih mudah dan cepat dibandingkan kuesioner pertanyaan terbuka.

38
Universitas Indonesia

BAB 3 METODOLOGI PENELITIAN

Bab ini menjelaskan tentang metodologi yang digunakan penulis dalam menyusun karya akhir. Metologi penelitian seperti yang terlihat pada gambar di bawah ini:
Observasi

Studi literatur

Pemilihan control objective COBIT 4.1

Pemetaan control objective COBIT 4.1 dengan FISCAM

Wawancara dengan panduan FISCAM

Pengumpulan dokumen/referensi

Rekapitulasi hasil wawancara

Identifikasi kelemahan kontrol Penyusunan rekomendasi

Pemetaan terhadap temuan audit BPK 2009

Rekomendasi prioritas

Gambar 3.1: Alur Penyusunan Karya Akhir

39
Universitas Indonesia

40

Penjelasan alur dalam gambar di atas sebagai berikut: 3.1 Observasi dan Penentuan Area Penelitian Langkah penelitian karya akhir ini diawali dengan melakukan observasi untuk menentukan area penelitian dan mendefinisikan rumusan masalah. Observasi ini dilakukan dengan menganalisis hasil temuan audit BPK Desember 2009.

3.2 Studi Literatur Selanjutnya, dilakukan studi literatur dari jurnal, buku, dan standar-standar yang diacu dalam penelitian ini, serta dokumen-dokumen perusahaan seperti laporan manajemen, temuan audit BPK Desember 2009, dan contoh laporan monitoring kinerja kantor-kantor cabang.

3.3 Pemilihan Control Objective pada COBIT 4.1 dan FISCAM Dari hasil studi literatur tersebut, penulis memilih menggunakan COBIT 4.1 dengan butir-butir pertanyaan dalam FISCAM. Ada enam control objective dalam COBIT 4.1 yang digunakan dalam penelitian ini, yaitu PO2, PO9, AI6, DS5, DS11, dan DS12. Keenam kontrol tersebut berperan penting dalam memastikan integritas data. Selanjutnya penulis menggunakan butir pertanyaan dalam FISCAM karena lebih detail dan bersifat teknis. Satu kontrol dalam COBIT 4.1 terdiri dari beberapa butir pertanyaan dalam FISCAM.

3.4 Wawancara dengan Panduan FISCAM dan Pengumpulan Referensi Pada tahapan ini penulis melakukan wawancara dengan pertanyaan semi terbuka. Pertanyaan pendahuluan dilakukan dengan pemilik proses bisnis, Manajer Utama Divisi Pelayanan Yuwono Basuki dan Manajer Data Divisi Pelayanan Ibram Jaya Putra, sebagai narasumber. Wawancara pendahuluan ini bertujuan untuk mendapatkan gambaran tentang manajemen data peserta di Taspen.

40
Universitas Indonesia

41

Wawancara tahap pertama ini dengan menggunakan teknik pertanyaan semi terbuka, dengan jawaban tiap pertanyaan tidak dibatasi. Wawancara tahap berikutnya dengan menggunakan panduan audit dari Fiscam, yaitu total 162 pertanyaan yang terbagi dalam empat bidang, kontrol umum, proses bisnis, proses antarmuka (interface), dan siste, manajemen data. Wawancara semi terbuka ini dilakukan kepada tiga narasumber: Manajer Aplikasi Core Business Sopian, Manajer Sistem Operasi Suryanto, dan administrator keamanan Fuji Widya.

Untuk memperjelas bagian proses bisnis, penulis melakukan wawancara dengan 30 pertanyaan terbuka kepada dua administrator data di Divisi Pelayanan, yaitu Jafar dan Yanrizal. Sebelum menjabat administrator data, keduanya menjadi staf entri data peserta masing-masing di kantor cabang Banda Aceh dan Malang.

Seiring dengan wawancara, penulis melakukan pengumpulan bukti referensi yang terkait dengan hasil wawancara. Apabila hasil wawancara dan bukti dokumen tidak sama, maka penulis menggunakan acuan dari dokumen.

3.5 Rekapitulasi Hasil Wawancara Hasil wawancara dan referensi tersebut kemudian direkap berdasarkan tiaptiap kontrol pada COBIT 4.1 untuk mengetahui area-area kontrol yang masih lemah dalam mendukung integritas manajemen data.

3.6 Identifikasi Kelemahan Kontrol dan Penyusunan Rekomendasi Dari hasil pemetaan tersebut dapat terlihat kelemahan-kelemahan kontrol dari empat bidang FISCAM terhadap enam kontrol COBIT 4.1. Dari kelemahankelemahan kontrol tersebut kemudian disusun rekomendasi berdasarkan panduan FISCAM.

41
Universitas Indonesia

42

3.7 Pemetaan terhadap Hasil Temuan Audit BPK dan Penyusunan Rekomendasi Prioritas Dari hasil rekomendasi tersebut dilakukan pemetaan terhadap hasil temuan audit BPK. Hasilnya adalah rekomendasi prioritas untuk membantu menyelesaikan permasalahan dari hasil temuan audit BPK.

42
Universitas Indonesia

BAB 4 PROFIL PERUSAHAAN

Bab ini menjelaskan tentang profil perusahaan yang menjadi studi kasus penelitian ini, serta profil aplikasi core business modul manajemen data peserta yang menjadi fokus penelitian ini.

4.1 Sejarah PT Dana Tabungan dan Asuransi Pegawai Negeri (Persero) atau yang biasa dikenal dengan Taspen berdiri pada tanggal 17 April 1963 dan berkantor pusat di Jalan Letjend Suprapto No 45, Cempaka Putih, Jakarta Pusat. Sejak berdiri hingga sekarang mengalami beberapa kali perubahan status badan hukum, mulai dari perusahaan negara (1963), perusahaan umum (1969), dan sejak tahun 1981 menjadi perusahaan perseroan dan salah satu Badan Umum Milik Negara (BUMN) yang bergerak di bidang asuransi sosial.

Pada awal berdiri Taspen hanya mengelola Tabungan Hari Tua (THT) dan asuransi kematian bagi Pegawai Negeri Sipil (PNS) dan pegawai BUMN. THT adalah pesangon yang dibayarkan sekaligus ketika PNS dan pegawai BUMN memasuki masa purnabhakti. Baru pada tahun 1987 Pemerintah memberikan amanah untuk membayarkan pensiunan kepada seluruh PNS, pejabat negara, veteran, dan pensiunan ABRI yang purnabhakti sebelum April 1989.

Sebelum mengelola pensiun, Taspen hanya memiliki satu gedung. Baru pada tahun 1987 Taspen membuka cabang untuk menangani pembayaran pensiunan PNS daerah mulai dari Nusa Tenggara, wilayah Sumatera, JawaMadura, Kalimantan, Sulawesi, Maluku, Irian Jaya hingga terakhir di Pangkal Pinang, Ternate, dan Gorontalo pada tahun 1990. Selanjutnya, pada tahun 2009 Taspen membuka kantor cabang baru di Mamuju, Manokwari, dan Tanjung Pinang. Total ada 45 kantor cabang, enam di antaranya kantor

43
Universitas Indonesia

44

cabang utama, dengan jumlah peserta terdiri dari 2.107.737 pensiunan dan 4.214.749 peserta aktif.

4.2 Struktur Organisasi Taspen terdiri dari lima direktorat yang tiap-tiap direktorat di bawah pimpinan direktur. Selain dewan direksi Taspen memiliki dewan komisaris dan komite audit.

Sedangkan tiap-tiap kantor cabang Taspen dipimpin oleh kepala cabang yang struktur organisasinya dibedakan menjadi empat, kantor cabang utama, kantor cabang tipe A, kantor cabang tipe B, dan kantor cabang tipe C. Perbedaan tipe-tipe kantor cabang berdasarkan luas wilayah dan jumlah peserta yang dilayani.

Gambar 4.1: Struktur Organisasi Taspen

4.3 Budaya Perusahaan Budaya Taspen tercermin dalam dalam penjabaran visi, misi, nilai-nilai utama, motto pelayanan, dan target layanan. Visi dan misi bersifat dinamis mengikuti perkembangan eksternal. Dari tahun 2004-2009 terjadi dua kali perubahan visi misi, yaitu tahun 2004 dan 2008.

44
Universitas Indonesia

45

Perubahan visi misi pada tahun 2008 disebabkan karena adanya krisis kepercayaan dari Kementerian Pendayagunaan Aparatur Negara dan Kementerian BUMN terkait dengan kasus Bank Mandiri 2007 dan hasil audit BPK berupa status disclaimer. Untuk memupuk kembali kepercayaan stakeholder dan mengembalikan kepercayaan diri, Taspen meluncurkan secara resmi visi misi baru pada Agustus 2008 pada saat Rapat Kerja Nasional di Bogor.

4.3.1 Visi Perusahaan Visi Taspen yaitu Menjadi pengelola dana pensiun dan THT serta jaminan sosial lainnya yang terpercaya. Makna visi tersebut adalah: 1. Menjadi pengelola dana pensiun dan THT serta jaminan sosial lainnya Ruang lingkup usaha Taspen adalah menyelenggarakan program THT (termasuk asuransi kematian), dana pensiun (termasuk Uang Duka Wafat), program kesejahteraan PNS serta program jaminan sosial lainnya. 2. Terpercaya" Taspen menjadi pilihan peserta dan stakeholder lainnya dengan kinerja yang bersih dan sehat. 3. Bersih Taspen beroperasi dengan menerapkan tata kelola perusahaan yang baik (Good Corporate Governance). 4. Sehat Adanya peningkatan kinerja yang berkesinambungan pada bidang keuangan maupun nonkeuangan. 4.3.2 Misi Perusahaan Misi Taspen yakni Mewujudkan manfaat dan pelayanan yang semakin baik bagi peserta dan stakeholder lainnya secara profesional dan akuntabel, berlandaskan integritas, dan etika yang tinggi.

45
Universitas Indonesia

46

Makna Misi Taspen sebagai berikut: 1. "Manfaat dan pelayanan yang semakin baik..." Untuk memenuhi harapan peserta yang semakin tinggi, Taspen berupaya meningkatkan nilai manfaat dan pelayanan secara optimal. 2. Profesional Taspen bekerja dengan terampil dan mampu memberikan solusi dengan 5 Tepat (tepat orang, tepat waktu, tepat jumlah, tepat tempat, dan tepat administrasi) didukung dengan SDM yang memiliki integritas dan kompetensi yang tinggi. 3. Akuntabel Taspen dalam melaksanakan pekerjaan berdasarkan sistem dan prosedur kerja yang dapat dipertanggungjawabkan. 4. Integritas Taspen senantiasa konsisten dalam memegang amanah, jujur, dan melaksanakan janji sesuai visi dan misi perusahaan. 5. Etika Taspen melayani peserta dan keluarganya dengan ramah, rendah hati, santun, sabar, dan manusiawi. 4.4 Sasaran Korporasi Adapun sasaran korporasi Taspen sebagai berikut: 1. Ruang lingkup dan payung hukum yang jelas berdasarkan UU No 40 Tahun 2004 tentang Sistem Jaminan Sosial Nasional (SJSN). 2. Terbitnya Peraturan Pemerintah tentang Iuran Pemberi Kerja PNS. 3. Seluruh unit kerja telah melaksanakan Good Corporate Governance (GCG). 4. Implementasi manajemen risiko tahun 2010. 5. Peningkatan manfaat THT kepada peserta. 6. Kinerja perusahaan berdasarkan KPI "sehat sekali" pada tahun 2013. 7. Kualitas akurasi data sebesar 95% pada 2009 menjadi 98% pada 2013. 8. Peningkatan kepuasan pelanggan dengan indeks sebesar 70% pada tahun 2009 menjadi 90% pada tahun 2014. 46
Universitas Indonesia

47

9. Pertumbuhan hasil investasi tiap tahun rata-rata sebesar 24,79%. 10. Memaksimumkan nilai pemegang saham pada tahun 2009 sebesar Rp28,94 triliun menjadi Rp81,09 triliun pada tahun 2013. 11. Efektivitas penyelesaian keluhan peserta dari dua hari pada tahun 2009 menjadi satu hari pada tahun 2013. 12. Penerapan aplikasi secara optimal, bertahap berdasarkan skala prioritas dan komprehensif.

4.5 Strategi Korporasi Untuk mencapai visi, misi, dan sasaran perusahaan, maka ditetapkan strategi perusahaan yang meliputi: 1. Mengadopsi UU No 40 tahun 2004 dan mendorong terbitnya UU Badan Penyelenggara Jaminan Sosial (BPJS). 2. Mengupayakan terbitnya Anggaran Dasar (AD) Taspen sesuai dengan UU No 40 Tahun 2004 dan peraturan perundangan tentang iuran pemerintah selaku pemberi kerja. 3. Melakukan aliansi strategis dengan kementerian PAN, Departemen Keuangan, dan Kementerian Negara BUMN serta BKN. 4. Melakukan koordinasi secara proaktif serta mengajukan usulan bentuk dan program kesejahteraaan PNS ke Tim RUU BPJS Menkokesra berdasarkan persetujuan Kementerian BUMN. 5. Meningkatkan kualitas dan akurasi data berbasis tepat waktu, tepat data, tepat biaya dan no waste. 6. Menerapkan indeks kepuasan pelanggan. 7. Mengupayakan pertumbuhan Return on Asset (ROA) di atas target RKA. 8. Meningkatkan pendapatan iuran. 9. Meningkatkan upaya pengendalian biaya operasional perusahaan. 10. Meningkatkan hasil investasi. 11. Melaksanakan pengelolaan perusahaan secara profesional dan berpegang teguh pada prinsip-prinsip GCG. 12. Melakukan assessment GCG secara berkala. 13. Mengajukan usulan kenaikan manfaat THT ke Kementerian Keuangan.

47
Universitas Indonesia

48

14. Membangun dan mengimplementasikan risk management pada Standard Operating Procedure (SOP). 15. Mengupayakan unfunded liability masuk ke dalam APBN 2009. 16. Meningkatkan kualitas SDM berbasis kompetensi melalui pendidikan dan pelatihan rutin yang berkesinambungan.

4.6 Portofolio Bisnis Taspen Ada dua jenis bisnis inti Taspen, yaitu transaksi-transaksi yang berkaitan dengan program THT dan transaksi-transaksi yang berhubungan dengan program pensiun. 4.6.1 Program Tabungan Hari Tua Meliputi asuransi dwiguna, nilai tunai THT, dan asuransi kematian bagi PNS, pejabat negara dan pegawai BUMN, di antaranya Perum KAI, Perum Perhutani, Perum Damri, Perum Pegadaian, Perum Garam, PT Telkom (Persero), PD Pasir Putih, PT TABA Bukit Asam (Persero), dan PT Pengerukan Indonesia (Persero). 1. Asuransi Dwiguna Pesangon yang diberikan secara lumpsum pada peserta yang berhenti karena pensiun, meninggal dunia sebelum diberhentikan dengan hak pensiun atau berhenti karena sebab-sebab lain. 2. Nilai Tunai THT Manfaat yang diberikan kepada peserta apabila mengundurkan diri sebagai peserta program THT. 3. Asuransi Kematian Manfaat yang didapat peserta apabila peserta, istri/suami dan anak meninggal dunia. 4. Peserta Peserta program THT yaitu: a. PNS (tidak termasuk PNS di lingkungan Departemen Hankam). b. Pejabat negara. c. Pegawai BUMN/BUMD yang terdaftar.

48
Universitas Indonesia

49

5. Masa Kepesertaan Masa kepesertaan program THT sebagai berikut: a. Sejak diangkat sebagai calon pegawai/pegawai tetap/pejabat negara. b. Bagi PNS yang diangkat sebelum 1 Juli 1961 dihitung sejak 1 Juli 1961. c. Bagi PNS daerah Propinsi Irian Jaya yang diangkat sebelum 1 Januari 1971, dihitung sejak Januari 1971. d. Bagi eks PNS Propinsi Timor Timur yang diangkat sebelum 1 April 1979, dihitung sejak April 1979. e. Bagi pegawai BUMN/BUMD/BHMN sesuai dengan perjanjian kerja sama masing-masing. 4.6.2 Program Pensiun Meliputi pembayaran uang pensiun/tunjangan bulanan, nilai tunai pensiun, tunjangan veteran, dan uang duka wafat. 1. Uang Pensiun Manfaat yang diberikan tiap bulan kepada peserta dan bisa diteruskan ke istri dan anak di bawah 21 tahun apabila peserta meninggal dunia. 2. Nilai Tunai Pensiun Manfaat yang diberikan kepada peserta apabila mengundurkan diri sebagai peserta program pensiun. 3. Tunjangan Veteran Manfaat yang diberikan tiap bulan kepada veteran dan bisa diteruskan ke istri apabila peserta meninggal dunia. 4. Uang Duka Wafat Manfaat yang diberikan kepada ahli waris apabila peserta program pensiun meninggal dunia. 5. Peserta Program Pensiun Para peserta program pensiun yaitu: a. Pegawai negeri sipil pusat dan daerah otonom.

49
Universitas Indonesia

50

b. Pejabat negara. c. Anggota ABRI yang dinas dan pensiun sebelum 1 April 1989 d. Anggota veteran dan PKRI/KNIP e. Pegawai KAI 6. Jenis Pensiun Jenis pensiun Taspen sebagai berikut: a. Diri pensiun yang bersangkutan b. Janda/duda/yatim-piatu pensiunan c. Orang tua (bagi PNS yang tewas dan tidak meninggalkan isteri/suami/anak). 4.6.3 Transaksi Bisnis Taspen Transaksi Bisnis yang dilakukan Taspen di antaranya sebagai berikut: 1. Pendaftaran Peserta Baru Proses pendaftaran peserta baru baik pada program pensiun maupun THT Taspen dilakukan di tiap-tiap kantor cabang. Tiap individu datang ke kantor cabang Taspen atau secara batch (manual) dari Badan Kepegawaian Daerah atau Pemda. 2. Penerimaan premi peserta dan pencatatannya Proses penerimaan dana premi dari peserta, serta mekanisme pencatatannya di divisi perbendaharaan. 3. Pengelolaan dana peserta (manajemen investasi) Kegiatan mengivestasikan dana yang dihimpun dari peserta program Taspen untuk mendapatkan keuntungan bagi perusahaan dilakukan di kantor pusat. 4. Pembayaran klim asuransi kematian dan THT Pembayaran klim asuransi kematian dan THT yang telah jatuh tempo. 5. Pembayaran uang pensiun dan uang duka wafat Pembayaran uang pensiun bagi peserta program dan pembayaran uang duka jika ada peserta yang meninggal dunia.

50
Universitas Indonesia

51

6. Peremajaan data peserta Pengkinian data peserta program Taspen terkait adanya

pengunduran diri, PNS yang telah purnabhakti, PNS yang meninggal, naik golongan dan lain-lain. Ada dua jenis peremajaan data, data peserta aktif, dan peserta pensiun.

Untuk peserta aktif dari PNS pusat, Taspen bekerja sama dengan Direktorat Jenderal Perbendaharaan Negara (DJPBN). Dirjen ini membawahi 178 Kantor Pelayanan Perbendaharaan Negara (KPPN) yang tersebar di seluruh Indonesia. Melalui KPPN inilah kantor-kantor cabang Taspen berinteraksi untuk melakukan rekonsiliasi data berdasarkan soft copy daftar gaji tiap bulan. Sedangkan untuk PNS DO, Taspen bekerja sama dengan pemerintah daerah setempat dan Direktorat Sistem Perbendaharaan yang juga di bawah DJPBN. Kondisi saat ini tiap Pemda memberikan data gaji PNS DO dua kali dalam setahun bergantung pada lokasi tiap-tiap Pemda.

Selain

dengan

KPPN,

Pemda,

dan

Direktorat

Sistem

Perbendaharaan, Taspen bekerja sama dengan BKN dalam peremajaan data, seperti input CPNS dan statusnya. Taspen mengambil data ke BKN tiap tiga bulan.

Sementara untuk data penerima pensiun dan tunjangan veteran, dilakukan dengan pengiriman surat pengesahan tanda bukti diri setiap dua tahun sekali ke rumah-rumah pensiunan. Sedangkan untuk peserta BUMN, data berasal dari instansi masing-masing. Demikian pula peremajaan data, dilakukan dengan berkoordinasi dengan instansi masing-masing.

51
Universitas Indonesia

52

7. Permintaan mutasi kantor cabang dan kantor bayar Proses memindahkan keanggotaan peserta dari sebuah cabang Taspen ke cabang lainnya, serta melayani permintaan pemindahan kantor bayar bagi peserta program yang pindah domisili. 8. Prediksi aktuaria Mengetahui simulasi perhitungan pembayaran manfaat THT dan pensiun berdasarkan perhitungan aktuaria. 4.7 Profil Aplikasi Bisnis Inti 4.7.1 Sejarah Aplikasi bisnis inti (core business) lahir untuk memenuhi tuntutan program transformasi Taspen di bidang infrastruktur. Tujuan dari pengembangan aplikasi core business (ACB) ini yaitu agar data bisa diakses secara sentral dan online oleh kantor pusat. Tujuan berikutnya yakni klim peserta dapat diproses dan disajikan secara on time dan real time [Prasojo & Rachmat, 2008].

ACB dikembangkan mulai tahun 2005 selama empat bulan. Pengembangan aplikasi ini dilakukan dengan metode Joint Application Development pengembangan (JAD). aplikasi Metode yang JAD merujuk pada metode antara

dilakukan

bersama-sama

konsultan pengembang dan user. Go live ACB dilakukan bertahap pada tahun 2005-2007. Implementasi pertama dilakukan pada bulan September 2005 di wilayah Taspen Cabang Utama Semarang. Berlanjut ke beberapa kantor cabang utama, hingga terakhir di wilayah Taspen Cabang Utama Medan dan Taspen Cabang Utama Makassar pada 12 April 2007.

Sebelumnya, Taspen telah memiliki aplikasi core business, yaitu recital, yang berbentuk console. Sayangnya, aplikasi ini tidak mencakup keseluruhan core business Taspen sehingga beberapa kantor cabang mengembangkan aplikasi tersebut sesuai kebutuhan mereka pada menu sistem pengembangan daerah. Akibatnya, aplikasi kantor 52
Universitas Indonesia

53

cabang satu dengan lainnya tidak standar. Agar aplikasi ini berlaku standar di seluruh kantor cabang dan prosesnya tidak dapat dimanipulasi maka Taspen segera memulai proyek ACB. 4.7.2 Deskripsi Aplikasi core business dikembangkan dengan menggunakan bahasa pemrograman Visual Age Smalltalk. Sistem manajemen database-nya (Database Management System) menggunakan DB2 dan servernya yang ada di masing-masing kantor cabang utama menggunakan IBM AS400 p series.

Sistem database yang digunakan untuk ACB

merupakan sistem

database terdistribusi, yang dideskripsikan menurut Conolly dan Begg, 2005, sebagai kumpulan shared data yang terintegrasi secara logis, dimana secara fisik terdistribusi melalui node-node jaringan. Database yang awalnya berada di tiap-tiap kantor cabang dipindahkan ke kantor cabang utama, misalnya KCU Semarang menyimpan database KCU Semarang, KC Purwokerto, KC Pekalongan, dan KC DKI Yogyakarta. Jadi Taspen memiliki enam server database untuk ACB.

.
Gambar 4.2: Konsep DBMS Terdistribusi (Addison Wesley, 2005)

Aplikasi ini selain dapat diakses melalui Local Area Network (LAN) dan Wide Area Network (WAN), juga dapat melalui Virtual Private Network 53
Universitas Indonesia

54

(VPN). Penggunaan VPN ini untuk para administrator sistem dan harus didaftarkan terlebih dahulu. Karena lalu lintas data melalui LAN, WAN, dan VPN maka diperlukan kontrol keamanan dengan firewall dan demilitarized zone (DMZ). Topologi jaringan seperti yang terlihat pada gambar berikut.

Gambar

Gambar 4.3: Topologi Jaringan untuk Aplikasi Core Business (Dokumen Taspen, 2009)

Aplikasi bisnis inti terdiri dari beberapa modul. Modul utama adalah modul manajemen data peserta. Modul ini terkait dengan modul pembayaran klim, modul perhitungan akturia, dan modul investasi. Modul manajemen data peserta terdiri dari beberapa submodul seperti submodul

54
Universitas Indonesia

55

penginputan data baru, mutasi data peserta, data keluarga mutasi cabang, dan pemeliharaan gaji.

Berikut beberapa tampilan antarmuka aplikasi core business modul manajemen data peserta.

Gambar 4.4: Tampilan Muka Aplikasi Core Business

Ketika user telah menginputkan username dan password maka akan terlihat tampilan seperti pada gambar 4.4.

55
Universitas Indonesia

56

Gambar 4.5: Tampilan Submodul Pemeliharaan Data Peserta Aktif

Pilih menu Data Peserta dan Pemeliharaan Data seperti pada gambar 4.5 lalu muncul halaman Pemeliharaan Data Peserta seperti pada gambar 4.6.

Gambar 4.6: Halaman Pemeliharaan Data Peserta

56
Universitas Indonesia

57 Pada field No Taspen setelah diisi dan diklik maka akan muncul halaman seperti pada gambar 4.7.

Gambar 4.7: Perpindahan Halaman Pemeliharaan Data Peserta

Contoh submodul lainnya dalam modul manajemen data peserta adalah submodul Pemeliharaan Data Keluarga seperti pada gambar 4.8.

Gambar 4.8: Submodul Pemeliharaan Data Keluarga

57
Universitas Indonesia

58

Pilih menu Pemeliharaan Data Tambahan dan Keluarga lalu muncul halaman Pemeliharaan Data Keluarga seperti pada gambar 4.9.

Gambar 4.9: Halaman Pemeliharaan Data Keluarga

4.7.3 Struktur Organisasi Pengembangan Sistem ACB Sistem aplikasi bisnis inti merupakan bagian tersendiri dalam struktur organisasi Divisi Teknologi Informasi di PT Taspen (Persero) seperti pada gambar di bawah ini dalam menjalankan kegiatan operasinya, bagian aplikasi bisnis inti dipimpin oleh manajer dengan sembilan staf yang masing-masing bertindak sebagai programmer dan administrator database, sekaligus administrator sistem aplikasi tersebut.

Manajer sistem aplikasi bisnis inti memiliki tanggung jawab dalam hal perencanaan, pengkoordinasian, pengembangan, dan pengendalian sistem aplikasi bisnis inti; pembuatan dokumentasi setiap terjadi penambahan pengembangan atau perubahan aplikasi; pemeliharaan pemeliharaan dan dan

integrasi

antaraplikasi;

pengembangan data dictionary; dan pembuatan laporan secara berkala. Untuk keamanan sistem, kontrol jaringan, dan setting database, bagian

58
Universitas Indonesia

59

aplikasi bisnis inti berkoordinasi dengan bagian jaringan komputer dan komunikasi data serta bagian sistem operasi.
Manajer Utama Divisi Teknologi Informasi

Manajer Sistem Aplikasi Bisnis Inti

Manajer Sistem Operasi

Manajer Jaringan Komputer dan Komunikasi Data

Manajer Sistem Aplikasi Pendukung

Fungsional:
- System Analyst - Administrator Database - Administrator Sistem - System Network

- Application Programmer - Network Programmer

Gambar 4.10: Struktur Organisasi Divisi TI di Taspen

59
Universitas Indonesia

BAB 5 ANALISIS DAN PEMBAHASAN

Bab ini memaparkan hasil analisis dari hasil wawancara dan studi literatur, serta menguraikan rekomendasi untuk tiap kelemahan kontrol dan rekomendasi untuk tiap temuan hasil audit BPK RI.

5.1 Analisis Data Peserta Taspen Peran data peserta di Taspen memegang kunci bisnis karena dengan data tersebut dapat dipergunakan sebagai sumber informasi untuk menganalisis kebenaran iuran peserta, menghitung kewajiban manfaat polis masa depan, memperkirakan beban klim, menetapkan besaran investasi, dan untuk pelaporan. Untuk mengantisipasi hal tersebut manajemen mencanangkan tahun 2008 sebagai tahun data dengan target akurasi sebesar 93 persen. Kebijakan ini tertuang pada Instruksi Direksi No. 03/Dir/2008.

Selanjutnya pada rencana jangka panjang perusahaan (2009-2013) Direksi menetapkan sasaran korporasi dengan kualitas akurasi data sebesar 95% pada 2009 menjadi 98% pada 2013. Untuk mendukung hal tersebut Bagian Data Divisi Pelayanan melakukan monitoring tiap bulan. Monitoring kinerja kantor cabang di antaranya laporan keberadaan data invalid untuk peserta aktif dan peserta pensiun serta perbandingan jumlah data peserta dengan database. Contoh hasil laporan seperti pada tabel tentang rekapitulasi data invalid kondisi bulan Maret 2010.

Dari tabel tersebut terlihat bahwa Taspen Cabang Yogyakarta mendapat peringkat pertama dari 45 kantor cabang. Total data invalid sebanyak 419 buah dari 92.255 peserta aktif atau keakurasian 99,55%, terdiri dari 12 data yang belum menggunakan tabel gaji pokok 2009, 7 data peserta di atas batas usia pensiun, 1 data peserta yang masuk kerja di bawah 17 tahun, 4 data yang perlu dikonfirmasi ke instansi, 144 data satuan kerja yang tidak ada di tabel,

60
Universitas Indonesia

61

dan 249 NIP yang sama. Urutan terendah dipegang Taspen Cabang Manokwari dengan keakurasian data mencapai 66,75%.

Kemudian, pada hasil audit yang dilaporkan BPK pada Desember 2009, keakurasian data menjadi salah satu catatan dengan total 28 item. Ada sembilan kantor cabang utama/kantor cabang yang mendapat sorotan, yaitu kantor cabang utama Medan, Bandung, Semarang, Surabaya, Makassar, Jakarta, serta kantor cabang Bogor, Pontianak, dan Mataram dengan 136.907 total data invalid. Kantor cabang yang paling banyak memiliki data invalid adalah kantor cabang Pontianak.

Sedangkan untuk jenis data invalid, paling banyak karena belum ter-update dan karena NIP sama nama lain (Nisanala). Masing-masing sebesar 69.384 dan 40.114 data. Sedangkan permasalahan rekonsiliasi dan perolehan dokumentasi rekapitulasi penyelesaian proses data gaji yang pada periode sebelumnya menjadi temuan, tahun 2009 sudah tidak ada kejadian lagi.

61
Universitas Indonesia

62

Tabel 5.1: Rekapitulasi Data Invalid Kondisi Bulan Maret 2010 (Dokumen Taspen, 2010) JENIS INVALID JUMLA H DATA GAPO K < 2009 > BUP (4) 7 2 0 3 3 20 50 4 30 0 16 27 0 2 19 16 10 3 0 USIA STATUS PEG 22 6) 1 1 0 0 2 7 0 3 8 6 0 6 10 1 2 2 5 0 0 4 66 0 10 0 13 2 150 1 0 0 0 0 104 16 7 442 19 592 INV ALID SATKER (7) 144 0 0 1 0 2 3 1 0 1 2 2 0 0 1 2 9 0 0 THN UPD < 2009 THN MUT < 2008 (9) 0 0 0 0 0 0 1 2 0 0 3 3 2 0 0 0 0 1 0 (10) 0 13 146 39 10 478 75 165 353 259 559 1,074 160 774 129 964 1,331 15 95 (11) 249 308 411 195 655 213 670 1,003 157 723 368 744 974 416 423 799 984 270 501 (12) 419 416 597 401 674 762 806 1,378 561 1,011 1,020 1,869 1,164 1,387 668 1,865 3,108 402 1,238 (13)=(2)(12) 91,836 84,274 113,970 70,949 89,156 78,584 80,341 135,739 55,020 94,473 90,886 151,084 89,301 104,729 50,324 120,933 200,310 25,634 75,059 (14)=(1 3)/(2) 99.55% 99.51% 99.48% 99.44% 99.25% 99.04% 99.01% 99.00% 98.99% 98.94% 98.89% 98.78% 98.71% 98.69% 98.69% 98.48% 98.47% 98.46% 98.38% (15) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 DATA TAR TOTAL NIS INVALID TOTAL VALID % VALID RANKING

NMCABANG

MASUK

(1) Yogyakarta Kediri Kupang M adiun Malang Palu Cirebon Palembang Ambon Denpasar Banjarmasin Banda Aceh Pontianak Purwokerto Bukittinggi Bandar Lampung Bandung Pangkalpinang Tasikmalaya

(2) 92,255 84,690 114,567 71,350 89,830 79,346 81,147 137,117 55,581 95,484 91,906 152,953 90,465 106,116 50,992 122,798 203,418 26,036 76,297

(3) 12 24 32 5 4 19 4 28 8 5 17 9 11 90 71 68 108 72 18

5)

(8) 2 2 8 148 0 10 1 22 4 17 55 4 7 0 7 7 219 22 32

62
Universitas Indonesia

63

Lanjutan tabel 5.1


NMCABANG Bogor Pekanbaru Medan Serang Surabaya Jember Mataram Pekalongan Bengkulu Semarang Makassar Samarinda Padang Pematang Siantar Palangkaraya Tanjungpinang Jambi Gorontalo Kendari Manado Jakarta Mamuju Jayapura Ternate Manokwari JUMLAH JUMLA H 144,653 93,273 138,049 93,867 214,035 61,057 89,419 75,921 56,754 195,702 191,277 93,092 85,564 97,468 69,758 29,867 76,535 30,172 73,374 73,853 276,890 27,194 68,389 34,085 26,943 4,345,137 GAPO K 240 20 196 8 3 4 639 86 11 788 372 721 1,458 1,616 1,421 24 1,103 987 2,449 3,362 3,795 2,025 6,378 3,815 8,433 40,607 USIA BUP 15 102 179 11 11 1 6 0 0 10 102 128 14 165 2 36 88 15 289 154 2,200 57 88 11 16 3,942 USIA MASUK 3 1 3 2 7 7 5 1 0 8 7 1 1 0 3 11 0 0 43 5 16 1 5 4 1 197 PEG 22 283 13 458 695 0 19 424 1 0 573 136 1 97 125 0 555 2 12 278 6 5528 218 80 126 391 11449 SAT KER 211 7 7 52 3 3 2 0 0 654 2 6 5 113 0 24 1 86 211 4 189 5 88 56 45 1,948 THN UPD 66 43 26 21 229 86 61 1 1 675 32 176 696 803 431 8 939 144 1,299 2,376 5,519 2 3,704 3,068 15 20,988 THN MUT 3 4 0 0 0 0 1 0 0 646 0 0 0 96 3 1 13 2 274 0 27 0 6 2 0 1,091 TAR 494 525 38 492 1,002 774 351 1,592 3 2,080 3,684 2,141 979 1,133 1,115 684 657 118 139 181 7,221 1,039 404 39 179 34,879 NIS 1,199 1,005 1,734 597 3,348 425 504 273 1,547 853 2,337 360 409 413 594 191 1,151 327 1,403 506 1,241 278 518 482 149 32,387 INVALID 2,514 1,720 2,641 1,878 4,603 1,319 1,993 1,954 1,562 6,287 6,672 3,534 3,659 4,464 3,569 1,534 3,954 1,691 6,385 6,594 25,736 3,625 11,271 7,603 9,229 147,488 VALID %VA LID 98.26% 98.16% 98.09% 98.00% 97.85% 97.84% 97.77% 97.43% 97.25% 96.79% 96.51% 96.20% 95.72% 95.42% 94.88% 94.86% 94.83% 94.40% 91.30% 91.07% 90.71% 86.67% 83.52% 77.69% 65.75% 96.61% RAN KING 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45

142,139 91,553 135,408 91,989 209,432 59,738 87,426 73,967 55,192 189,415 184,605 89,558 81,905 93,004 66,189 28,333 72,581 28,481 66,989 67,259 251,154 23,569 57,118 26,482 17,714 4,197,649

63
Universitas Indonesia

64

Tabel 5.2: Rangkuman Jumlah Temuan Draft Notisi Audit BPK RI pada KCU/KC Bulan Desember 2009 (Dokumen Taspen, 2009) KANTOR CABANG UTAMA/ KANTOR CABANG No I. 1 2 3 PERMASALAHAN MDN DATA PESERTA PROGRAM THT Duplikasi NIP. NIP salah Data sudah mengajukan klaim pensiun/PMK dan status masih aktif 4 5 6 Kode satker salah/tidak ada pada tabel Data perlu dikonfirmasi Data dengan gaji pokok salah/tidak ada pada tabel 0 0 0 0 20 0 0 0 0 130.257 0 0 0 2 0 BDG 200.903 4 0 0 0 1.095 SMG 192.229 0 19 1 67 0 SBY 210.276 0 0 0 0 18 MKS 216.962 0 12 6 2.599 4.680 BGR 147.550 234 0 0 0 0 PTK 88.119 0 0 0 0 0 MTR 86.629 0 0 0 0 0 JKT 231.136 0 4.850 898 647 8.223

Data dengan tanggal lahir kosong

Kode status pegawai 20 yaitu peserta Non Aktif/Usia melebihi Batas Usia Pensiun (BUP) dan belum mengajukan perubahan statusnya. 107 399 0 0 0 0 0 0 0

64
Universitas Indonesia

65

Lanjutan tabel 5.2


PTK NO 9 PERMASALAHAN Isian dalam field TMT Gaji Pokok dan nilai gaji pokok dalam field Gapok untuk PNS dengan status pegawai tetap tidak sama dengan gaji pokok 1 Januari 2009. 10 11 12 13 14 15. 16. Kode satker kosong. Tidak ada record (TAR) di Taspen. TAR pindah cabang. Belum terupdate. Pensiun, meninggal, keluar (PMK). NIP sama nama lain (Nisanala). Usia peserta>dari BUP dan status masih aktif. 17. Usia masuk menjadi peserta <18 tahun atau >46 tahun (non pejabat Negara). 18. 19. Tidak termutasi selama 3 tahun. Tidak ter up date selama 2 tahun dari current date. 20. Data peserta dengan gapok 0. 136 9.616 0 0 0 238 0 0 167 86 323 629 6 207 0 5.424 381 15.478 0 2.813 163 0 3.545 364 0 0 843 363 0 7.054 0 0 0 4.365 1.831 3.688 228 115 2.028 0 48 1.355 0 432 162 1.499 0 102 0 0 0 0 0 0 0 0 218 8.707 2.647 53.054 0 31.599 3.019 0 16 0 0 0 0 0 0 0 MDN BDG SMG SBY MKS BGR MTR JKT

0 0 0 1

3 0 0 0

312 6 1 0

318 0 0 0

0 0 0 0

0 0 0 0

0 0 0 0

0 0 0 0

1.018 3.264 0 0

65
Universitas Indonesia

66

Lanjutan tabel 5.2


NO 21. PERMASALAHAN Belum merekonsiliasi data secara rutin setiap 6 bulan (Januari dan Juli) dengan Pemerintah Kota, Pemerintah Kabupaten, BUMN/D dan Instansi Vertika.l 22. Tidak memperoleh dokumentasi Rekap Penyelesaian Proses Daftar Gaji secara lengkap untuk setiap bulan data gaji dari Pemda yang di upload Taspen. 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 MDN BDG SMG SBY MKS BGR PTK MTR JKT

23.

Terdapat selisih data peserta dari Rekap Hasil Proses Daftar Gaji antara database peserta PT Taspen dan Daftar Gaji yang diperoleh dari Pemda dan KPPN. 0 0 0 0 16.099 0 0 2.046 0

24 25

Gaji Pokok bukan gaji pokok tahun 2009. Nilai THP tidak sesuai hasil perhitungan.

0 0

0 0

0 0

0 0

0 0

0 0

0 0

0 0

17.297 1.466

JUMLAH INVALID

10.100

2.935

24.665

5.451

36.670

7.696

2.195

2.046

136.907

PROSENTASE INVALID

7,75

1,46

12,83

2,59

16,90

5,22

2,49

2,36

59,23

66
Universitas Indonesia

67

Lanjutan tabel 5.2


N O II. 1. 2. DATA PESERTA PROGRAM PENSIUN Tanggal lahir dalam database salah. Terdapat Nomor Induk Pegawai (NIP) berstatus Non NIP dan Non NRP. 3. Terdapat peserta pensiun yang telah meninggal sejak tahun 2000 s.d. 2009 namun dalam status JAD kosong atau stop mulai 1 Januari 2010. 4. Kesalahan input tanggal lahir pensiun (usia < 25 tahun). 5. Pensiun pokok (100%) tidak ada di tabel pensiun pokok. 54 rec. 21 rec. 9 rec. 1.511 rec. 11 pens. 5 pens. 14 pens. 3 pens. PERMASALAHAN MDN BDG SMG SBY MKS BGR PTK MTR JKT

67
Universitas Indonesia

68

5.2 Analisis dengan Pendekatan COBIT 4.1 dan FISCAM Dari permasalahan-permasalahan hasil temuan audit BPK RI bulan Desember 2009 dan tindakan-tindakan yang telah dilakukan manajemen Taspen, maka penulis melakukan audit dengan menggunakan framework COBIT 4.1 dengan butir-butir pertanyaan dalam FISCAM seperti pada tabel 5.3.
Tabel 5.3: Pemetaan Kontrol COBIT 4.1 dengan Kontrol FISCAM Kontrol COBIT PO2 KONTROL FISCAM AS-3.5.2, BP-1.1.1, BP-1.5.1, BP-1.5.2 , BP-1.5.3, BP-1.6.1, BP-2.3.2, BP2.4.2, BP-2.4.3, BP-2.4.4, BP-2.5.1, BP-2.9.1, BP-3.1.1, BP-3.2.2, BP-3.2.3, BP-3.3.3, BP-4.1.1, BP-4.1.2, BP-4.2.1, BP-4.2.2, BP-4.2.3, BP-4.3.1, BP4.3.2, BP-4.4.1, BP-4.4.2, BP-4.5.1, IN-1.1, IN-1.2.1, IN-1.2.2, IN-2.1.1, IN-2.2.2, IN-2.2.3, IN-2.3.1, IN-2.4.1, IN-2.5.1, IN-2.5.2, IN-2.6.1, DA1.1.1, DA-1.1.3. DA-1.3.1 AS-1.2.1, AS-1.3.1, AS-1.5.3, AS-1.6.1, AS-1.6.2, AS-1.6.3, AS-1.6.4, AS3.1.1, AS-3.2.1, AS-3.8.1, AS-3.9.1, AS-3.13.1, AS-4.1.1, AS-4.1.2, AS4.4.1, AS-4.4.3, AS-4.5.1, AS-4.5.2, AS-5.1.1, AS-5.1.2, AS-5.1.3, AS5.2.1, AS-5.2.2, AS-5.2.3, AS-5.3.1, AS-5.3.2, AS-5.3.3, AS-5.4.1, AS_5.4.2, AS-5.4.4, BP-4.4.1, BP-4.4.3 AS-3.2.1, AS-3.3.1, AS-3.4.1, AS-3.5.1, AS-3.5.3, AS-3.5.4, AS-3.5.5, AS3.5.6A-, AS-3.5.7, AS-3.5.8-AS-3.5.9, AS-3.6.1, AS-3.7.1, AS-3.11.1, AS3.12.1, AS-3.14.1, BP-1.5.2,BP-1.5.3, BP-2.2.3, BP-4.2.2, BP-4.4.2, BP4.4.4. , BP-4.6.1, BP-4.6.2 AS-1.1A, AS-1.2.2, AS-1.1.3, AS-1.2.1, AS-1.3.2, AS-1.4.1, AS-1.4.2,AS1.5.1, AS-1.5.2, AS-1.5.3, AS-1.5.4 AS-1.6.1, AS-1.6.2, AS-1.6.3, AS-1.6.4, AS-1.7.1, AS-1.7.2, AS-2.1.1, AS-2.2.1, AS-2.3.1, AS-2.3.2, AS-2.3.3, AS2.3.4, AS-2.4.1, AS-2.4.2, AS-2.4.3, AS-2.5.1, AS-2.6.1, AS-2.6.2, AS2.6.3, AS-2.6.4, AS-2.6.5, AS-2.6.6, AS-2.7.1, AS-2.8.1, AS-2.9.1, AS2.10.1, AS-3.1.1, AS-3.6.3, AS-3.8.1, AS-3.10.1, AS-4.1.1, AS-4.2.1, AS4.3.1, AS-4.4.1, AS-4.4.2, AS-4.4.3, AS-4.5.1, AS-4.5.2, AS-4.5.3, BP1.5.2, BP-2.7.2, BP-2.8.1,BP-2.9.3, BP-2.9.4, BP-3.1.1, BP-3.2.1, BP-3.2.3, BP-3.4.1, BP_3.5.1, BP-3.5.2, BP-4.4.2, BP-4.7.1, IN-2.2.2, IN-2.5.3, DA1.2.1, DA-1.2.2, DA-1.3.2 AS-5.2.1, AS-5.2.3, BP-1.1.1, BP-1.2.1, BP-1.3.1, BP-1.4.1, BP1.5.1, BP1.6.1, BP-1.7.1, BP-1.8.1, BP-2.1.1, BP-2.2.1, BP-2.2.2, BP-2.2.3, BP2.3.1, BP-2.3.2, BP-2.4.1, BP-2.4.2, BP-2.4.3, BP-2.4.4, BP-2.5.1, BP-2.6.1, Bp-2.7.1, BP-2.7.2, BP-2.8.1, BP-2.9.1, Bp-2.9.2, BP-2.9.3, BP-2.9.4, BP3.1.1, BP-3.2.1, BP-3.2.2, BP-3.3.1, BP-3.3.2, BP-3.3.3, BP-3.4.1, BP_3.5.1, BP-3.5.2, BP-4.1.1, BP-4.1.2, BP-4.2.1, BP-4.2.2, BP-4.2.3, BP4.3.1, BP-4.3.2, BP-4.4.1, BP-4.4.2, BP-4.4.4, BP-4.6.1, BP-4.6.2, BP-4.7.1, DA-1.1.1, DA-1.1.2, DA-1.2.1, DA-1.3.1 AS-2.11.1, DA-1.1.1

PO9

AI6

DS5

DS11

DS12

Kemudian, sesuai dengan metodologi yang telah dipaparkan dalam bab sebelumnya, penulis melakukan wawancara kepada beberapa responden, yaitu manajer aplikasi bisnis inti (core business), manajer sistem operasi, administrator jaringan yang merangkap sebagai administrator keamanan,

68
Universitas Indonesia

69

programmer yang sekaligus administrator sistem ACB, dan staf bagian data di Divisi Pelayanan.

Panduan audit dengan menggunakan FISCAM terdiri dari 162 pertanyaan yang mencakup empat kategori kontrol, yaitu kontrol aplikasi secara umum (application level general control), kontrol proses bisnis (business process control), kontrol antarmuka (interface control), dan manajemen data (data manage). Dari hasil wawancara dengan 162 pertanyaan FISCAM, penulis melakukan rekapitulasi hasil wawancara seperti pada tabel di bawah ini.
Tabel 5.4: Rekapitulasi Hasil Wawancara dengan Pendekatan FISCAM No A AS-1 AS1.1.A Pernyataan Kontrol Aplikasi Secara Umum (Application Level General Controls) Implementasi manajemen keamanan aplikasi yang efektif. Apakah rencana keamanan aplikasi yang komprehensif telah disusun dan didokumentasikan? Rencana keamanan ini meliputi: a. Deskripsi aplikasi. b. Level risiko aplikasi. Jawa ban Penjelasan

Ya Tidak

c. Pemilik aplikasi. d. Personel yang bertanggung jawab terhadap keamanan aplikasi.

Ya Ya

Divisi Perencanaan dan Pengembangan Bisnis telah melakukan pengkajian tentang business impact analysis. Salah satu poin menyebutkan aplikasi manajemen data merupakan bisnis inti (core business) perusahaan yang tidak boleh mati lebih dari 8 jam. (level risiko tinggi). Namun deskripsi ini belum diinputkan ke dalam rencana keamanan aplikasi ACB modul manajemen data peserta karena pengkajian ini dilakukan pada tahun 2009. Pemilik aplikasi adalah Divisi Pelayanan. Dalam kebijakan keamanan TI secara umum (IT Security Policy Tahun 2007 berdasarkan SK: No-24/DIR/2006 tanggal 30 Juli 2006) menyebutkan struktur tim. Salah satunya bagian keamanan aplikasi, bertanggung jawab untuk melakukan pengawasan operasional dan pengembangan aplikasi yang sesuai dengan aturan keamanan informasi. Namun realitanya fungsi ini tidak ada. Keamanan secara umum dikelola oleh bagian jaringan Divisi TI. Tidak ada

69
Universitas Indonesia

70

e. Interkoneksi aplikasi/sharing informasi. f. Deskripsi semua kontrol yang telah ada atau sedang direncanakan termasuk bagaimana kontrol diimplementasikan atau akan diimplementasikan. g. Pendekatan dan prosedur meliputi desain keamanan dan proses up grade. h. Proses untuk menyusun peranan keamanan (security roles). i. Kebijakan administrasi keamanan secara umum termasuk penyusunan dan pemeliharaan perangkat pengamanan yang berlaku. j. Identifikasi transaksi yang sensitif dalam setiap modul fungsional. k. Identifikasi pemisahan tugas (segregation of duties) yang berisiko tinggi.

Ya Tidak

personel yang secara spesifik menangani keamanan aplikasi ACB modul manajemen data peserta. Output modul aplikasi ini menjadi input modul aplikasi lainnya. Kontrol aplikasi belum komplet terdokumentasi.

Ya

Mengikuti kebijakan keamanan TI secara umum. Mengikuti kebijakan keamanan TI secara umum. Mengikuti kebijakan keamanan TI secara umum.

Ya Ya

Ya

Tidak

l.

Peranan dan tanggung jawab dari organisasi keamanan yang mendukung sistem dengan memperhatikan pemisahan tugas (segregation of duties). m. Prosedur uji coba keamanan.

Ya

Transaksi dalam aplikasi ini yang sensitif berkaitan dengan uang. Misal, ubah masa kerja dan gaji pokok. Poin ini tidak ada dalam kebijakan keamanan TI organisasi. Fungsi tugas di Divisi TI ditentukan oleh kebijakan SDM bukan berdasarkan analisis kebutuhan untuk manajemen data. Mengikuti kebijakan keamanan TI secara umum.

Ya

n. o.

p. q.

Koordinasi dengan kebijakan keamanan organisasi. Prosedur untuk akses darurat ke sistem produksi, termasuk akses untuk meng-update program dalam produksi, update langsung database, dan modifikasi pilihan (option) perubahan sistem. Setting parameter sistem sesuai dengan kebijakan perusahaan. Prosedur kontrol akses memperhatikan penggunaan sistem untuk critical user IDs.

Ya Ya

Ada dalam kebijakan keamanan TI secara umum namun belum pernah dilakukan. Keamanan aplikasi mengikuti kebijakan keamanan TI secara umum. Keamanan aplikasi mengikuti kebijakan keamanan TI secara umum.

Ya Ya

AS- a. 1.1.2

Apakah akun sensitif diidentifikasi untuk tiap proses bisnis atau subproses dan hak akses keamanan yang penting terdefinisi dan disetujui?

Ya

AS- a.

Apakah hak akses disusun untuk

Ya

Mengikuti kebijakan keamanan TI secara umum. Ada dalam IT Security Policy 2007 dan Sesuai dengan prosedur kerja Divisi TI: TAS/STI/PK/11 tentang Create User dan Hak Akses Aplikasi. Akun sensitif berkaitan dengan transaksi sensitif, yaitu pengisian/perubahan data yang berkaitan uang. Administrator di tiap kantor cabang menentukan tingkatan hak akses untuk petugas administrasi data. Administrator di tiap kantor cabang

70
Universitas Indonesia

71

1.1.3

AS1.2.1

AS1.3.1 AS1.3.2

membatasi user dari mengeksekusi transaksi yang tidak sesuai dalam aplikasi melalui menu atau layar? a. Apakah risiko keamanan diukur dari segi aplikasi dan sistem pendukung dalam setiap periodik atau setiap kali aplikasi atau sistem pendukung secara signifikan berubah? b. Apakah pengukuran risiko, validasi, dan persetujuan manajemen itu didokumentasikan dan dipelihara? c. Apakah pengukuran risiko secara tepat terdapat pada rencana keamanan aplikasi? Apakah pemilik proses bisnis menerima risiko dan menyetujui kebijakan dan prosedur? Apakah kebijakan dan prosedur keamanan aplikasi? a. Terdokumentasi. b. Memperhatikan kebutuhan keamanan proses bisnis. c. Memperhatikan pemisahan aktivitas user aplikasi dengan aktivitas administrator sistem.

yang menentukan tingkatan hak akses untuk petugas administrasi data. Tidak Poin risiko ada dalam kebijakan keamanan namun belum terealisasi.

Tidak

Ya

Tidak

Belum dilakukan secara formal. Baru dilakukan pengkajian oleh Divisi Renbang. Ada dalam kebijakan keamanan organisasi secara umum, namun belum terealisasi. Hasil pengkajian oleh Divisi Renbang belum dikomunikasikan secara formal ke Divisi Pelayanan. Mengikuti kebijakan keamanan TI secara umum. Kebijakan keamanan tersebut tidak menyebutkan tentang kebutuhan keamanan proses bisnis. Dalam kebijakan keamanan TI memuat perbedaan hak akses level user dan level administrator sistem. Dalam SOP juga tertera prosedur kerja di Divisi TI: TASP/STI/PK/11 tentang Create User dan Hak Akses Aplikasi. Belum secara terformalisasi dikomunikasikan meski organisasi telah memiliki kebijakan keamanan TI sejak tahun 2007.

Ya Tidak

Ya

AS1.4.1

AS1.4.2

Apakah perusahaan memiliki proses yang efektif untuk mengkomunikasikan kebijakan keamanan aplikasi kepada pemilik aplikasi dan user dan memastikan bahwa mereka memiliki kesadaran akan kebijakan tersebut. Kebijakan personel berkaitan dengan aplikasi secara tepat menempatkan keamanan serta pemilik aplikasi dan user memiliki pengalaman dan training yang memadai?

Tidak

Tidak

AS1.5.1

Apakah kebijakan keamanan aplikasi dan rencana prosedur ujicoba disusun dan didokumentasikan?

Ya

AS1.5.2 AS1.5.3

Apakah kontrol keamanan yang berhubungan dengan aplikasi utama (major) diuji minimal setahun sekali? Apakah frekuensi dan lingkup uji coba proporsional dengan risiko dan kekritisan aplikasi bagi misi organisasi?

Tidak

Tidak

Pemilik aplikasi dan user mendapatkan training untuk mengoperasikan aplikasi. Namun, tentang keamanan tidak diberikan/disosialisasikan secara formal, meskipun organisasi memiliki kebijakan keamanan yang memuat tentang kesadaran user sebagai bagian dari kebijakan keamanan TI. Kebijakan keamanan aplikasi mengikuti kebijakan keamanan organisasi, tidak spesifik diatur dalam bab tertentu. Sedangkan rencana prosedur ujicoba keamanan ada dalam kebijakan keamanan TI meski belum diterapkan. Pengujian kontrol keamanan tidak dilakukan tiap tahun, hanya sesuai kebutuhan. Mengingat fungsi aplikasi yang penting, belum dilakukan ujicoba yang proporsional, hanya berdasar kebutuhan.

71
Universitas Indonesia

72

AS1.5.4

Kepatuhan dan laporan dari unsur kepatuhan merupakan bagian dari program keamanan organisasi?

Tidak

AS1.6.1

Apakah manajemen memiliki proses untuk mengkoreksi kelemahan keamanan?

Ya

AS1.6.2

Apakah manajemen menginisiasi langkah awal untuk mengkoreksi kelemahan keamanan. Apakah rencana aksi (action plans) dan milestone terdokumentasi dan komplet?

Ya

AS1.6.3

AS1.6.4

Apakah kelemahan dianalisis melalui aplikasi (analisis mungkin diperluas hingga menyangkut downstream, upstream, dan segala sesuatu yang berkaitan dengan aplikasi) dan aksi korektif yang tepat diimplementasikan? Apakah tindakan aksi korektif diuji setelah diimplementasikan dan dipantau secara periodik? Apakah kebijakan dan prosedur yang berhubungan dengan aktivitas provider pihak ketiga terdiri dari: a. Kepatuhan aplikasi dengan kebutuhan keamanan perusahaan. b. Monitoring kepatuhan sesuai dengan persyaratan regulator.

Tidak

Selain kebijakan internal, tidak ada perundangan yang diikuti untuk program keamanan organisasi. Barubaru ini saja ada audit BPK yang menyinggung tentang integritas data. Namun secara formal belum ada di program keamanan organisasi . Belum ada best practices yang diikuti dalam kebijakan keamanan. Organisasi juga belum memiliki framework manajemen risiko TI. Dalam kebijakan keamanan TI terdapat bab yang mengatur tentang risiko termasuk analisis celah keamanan dan memperbaikinya. Namun, ketentuan ini belum diterapkan. Kelemahan keamanan aplikasi tidak dievaluasi secara periodik, melainkan jika ada permasalahan atau laporan dari petugas data. Sesuai dengan kebijakan keamanan TI perlu dilakukan pengukuran risiko termasuk analisis celah keamanan dan memperbaikinya. Meski tidak secara eksplisit organisasi menerapkan hal tersebut, namun sejak pertengahan 2009 diadakan evaluasi aplikasi ACB modul manajemen data peserta dengan mengadakan forum bersama para petugas dan admin manajemen data peserta. Dalam forum tersebut dibahas kelemahan aplikasi dari segi kontrol dan sebagainya dan langkah-langkah untuk memperbaikinya. Rencana tersebut kemudian didokumentasikan dan menjadi dasar dalam menentukan perbaikan. Ketika agenda perbaikan belum selesai, maka dilanjutkan dalam plan of action 2010 di Divisi TI. Belum ada analisis kekurangan dengan tools lain. Namun, aksi korektif yang tepat diimplementasikan.

Tidak Belum ada pemantauan secara periodik, kecuali jika ada kasus atau laporan.

AS1.7.1

Tidak Tidak

Belum ada poin tentang aktivitas provider pihak ketiga dalam kebijakan keamanan perusahaan. Hanya berdasarkan kebijakan internal dan petunjuk hasil audit BPK.

72
Universitas Indonesia

73

AS1.7.2 AS-2 AS2.1.1

Apakah ada proses untuk memantau kepatuhan provider pihak ketiga dengan persyaratan regulasi perusahaan? Implementasi kontrol akses aplikasi yang efektif. Apakah batasan aplikasi diidentifikasikan dalam rencana keamanan? Batasan aplikasi apakah cukup aman?

Tidak

Tidak ada proses formal untuk memantau kepatuhan provider pihak ketiga.

Tidak

AS2.2.1

Apakah identifikasi dan autentikasi unik untuk setiap user? Setiap user harus memasukkan user dan password untuk mendapatkan akses aplikasi? Apakah perusahaan memiliki prosedur formal dan proses untuk memberikan user sebuah akses ke aplikasi? Kebijakan dan prosedur tersebut meliputi: a. Menerima password.

Tidak

Deskripsi komplet tentang aplikasi ACB modul manajemen data belum ada, sehingga identifikasi batasan aplikasi sesuai dengan pemahaman personel keamanan ketika menyusun rencana keamanan. Tentang keamanan, sejauh ini belum ada serangan yang mengarah langsung ke aplikasi, namun evaluasi hanya berdasarkan kebutuhan. Untuk level user, setiap user memiliki akun masing-masing. Namun, untuk administrator sistem dan administrator di bagian data Divisi Pelayanan, menggunakan akun bersama.

AS2.3.1

Ya

b. Mengubah dan mereset password.

Ya

c. Penanganan kehilangan password.

Ya

AS2.3.2

a. Apakah aplikasi mengunci akun user setelah beberapa kali berusaha masuk dengan password yang salah?

Tidak

b. Apakah aplikasi secara otomatis mereset akun user setelah periode waktu yang spesifik atau

Tidak

Pihak yang berwenang memberikan akses dan menentukan hak akses adalah kepala seksi/bagian data. Ketika memberikan akun dan password, user bersangkutan diminta mengubah password . Hal ini juga terdapat dalam prosedur kerja: TAS/STI/PK/11 tentang Create User dan Hak Akses Aplikasi. Untuk mengubah password adalah hak tiap-tiap user. Namun, untuk mereset adalah tugas admin di tiap-tiap cabang berdasarkan permintaan user. Sedangkan permintaan reset dari admin di tiap cabang ke administrator sistem harus melalui permintaan tertulis. Untuk level user di kantor cabang hanya mengkomunikasikan ke admin cabang. Namun, untuk permintaan dari admin cabang ke admin sistem harus melalui permintaan tertulis. Kontrol belum komplet. User bisa memasukkan password berulang kali. Setelah dua kali kesalahan login, user masih tetap bisa masuk. Namun, tidak dapat masuk ke proses aplikasi, hanya dapat masuk ke tampilan menu utama. Perlu bantuan administrator untuk mereset akun.

73
Universitas Indonesia

74

AS2.3.3 AS2.3.4 AS2.4.1

memerlukan administrator untuk mereset akun? c. Apabila user mendiamkan aplikasi atau sesi user tidak aktif, apakah aplikasi secara otomatis me-log off akun user? Apakah tiap user aplikasi hanya memiliki satu akun? Apakah multiple log on terkontrol dan terpantau? Apakah sebelum user mendapatkan akun user dan password untuk aplikasi, akses level user diotorisasi oleh manajer dan administrator aplikasi? Apakah pemilik secara periodik meninjau akses untuk memastikan sistem berjalan baik? Apakah akses terbatas bagi tiap individu sesuai dengan tujuan bisnis (hak minimal) ? Apakah perusahaan mengimplementasikan rencana keamanan dan proses untuk: a. Identifikasi dan otorisasi user b. Kontrol akses user c. Penggunaaan digital signature d. Larangan akses langsung bagi publik ke data produksi e. Kepatuhan dengan FISMA dan NIST

Tidak

User tetap bisa masuk ke sesi tersebut meskipun aplikasi tidak aktif dalam beberapa waktu. Untuk bagian data, di Divisi Pelayanan menggunakan akun bersama. Multiple log on yang ada hanya dikontrol dan dipantau sesuai kebutuhan. Akun user dan password diotorisasi oleh admin cabang. Hal ini juga sesuai dengan TAS/STI/PK/11 tentang Create User dan Hak Akses Aplikasi. Sesuai kebutuhan untuk penelusuran kesalahan penginputan data. Admin cabang menentukan sejauh mana user bisa mengakses modulmodul dalam aplikasi.

Tidak Tidak

Ya

AS2.4.2 AS2.4.3 AS2.5.1

Tidak

Ya

Ya Tidak Tidak Tidak Tidak Ya

AS2.6.1 AS2.6.2 AS2.6.3

AS2.6.4

AS2.6.5

Apakah pemilik mengidentifikasi transaksi atau aktivitas sensitif dari proses bisnis? Apakah pemilik mengotorisasi user untuk memiliki akses pada aktivitas/transaksi sensitif? Apakah administrator keamanan meninjau otorisasi akses user aplikasi untuk mengakses transaksi sensitif dan mendiskusikan otorisasi yang mencurigakan pada pemilik? Apakah pemilik secara periodik meninjau akses ke transaksi/aktivitas sensitif dan memastikannya berjalan baik? Apakah akun individu yang tidak aktif dan telah keluar disable atau dihapus dalam kurun waktu tertentu?

Ya

Sesuai TAS/STI/PK/11 tentang Create User dan Hak Akses Aplikasi. Tidak dilakukan secara periodik. Belum dilakukan. Belum ada larangan formal untuk akses langsung ke data produksi. Organisasi tidak mengikuti FISMA dan NIST. Transaksi atau aktivitas sensitif seperti mengubah masa kerja peserta karena berkaitan dengan nominal. Sesuai dengan hak akses yang diberikan oleh kabid/kasi tiap kantor cabang. Ditinjau setelah ada kejadian/transaksi yang abnormal.

Tidak

Tidak

Ditinjau setelah ada kejadian/transaksi yang abnormal.

Ya

Penghapusan akun secara manual. Belum ada ketentuan tentang berapa lama akun harus dihapus setelah tidak aktif/keluar. Penghapusan user oleh kepala seksi/kepala bidang tiap-tiap kantor cabang. Sesuai hak akses user.

AS2.6.6

Apakah akses ke transaksi sensitif dibatasi untuk individu dengan tujuan bisnis yang valid (hak minimal)

Ya

74
Universitas Indonesia

75

AS2.7.1

2.8.1

AS2.9.1 AS2.10.1

AS2.11.1

a. Apakah organisasi mengidentifikasi sumber daya (resources) aplikasi yang sensitif ? b. Apakah akses ke sumber daya aplikasi sensitif terbatas hanya bagi user yang tepat? c. Apakah data aplikasi yang sensitif terenkripsi? Apakah kebijakan dan prosedur disusun untuk memastikan audit keamanan aplikasi dan monitoring efektif Apakah logging dan parameter lain diset untuk memberitahu apabila terjadi pelanggaran keamanan? a. Apakah exception dan pelanggaran diidentifikasi dan diagendakan (dilog)? b. Apakah laporan exception ditinjau oleh administrator keamanan? c. Apakah jika terjadi exception ada tindakan? a. Apakah kontrol fisik terintegrasi secara korporasi dan kontrol level sistem? b. Apakah sumber daya aplikasi sensitif untuk akses fisik teridentifikasi? c. Apakah ada keamanan fisik untuk sumber daya aplikasi sensitif? Implementasi manajemen konfigurasi aplikasi yang efektif. Apakah kebijakan dan prosedur disusun untuk manajemen konfigurasi aplikasi?

Ya

Aplikasi yang berhubungan dengan keuangan.

Ya

Disetujui oleh atasannya sebelum mendapat akses tersebut. Belum terenkripsi. Belum ada prosedur tentang audit keamanan meski di dalam Kebijakan Keamanan TI 2007 tercantum. Belum ada.

Tidak Tidak

Tidak

Tidak

Belum ada logging untuk pelanggaran dan exception. Peninjauan dilakukan setelah ada pelanggaran yang merugikan. Belum ada prosedur untuk menangani exception. Kontrol fisik dan level sistem terintegrasi secara korporasi. Namun, belum dilakukan pengukuran risiko (risk assessment). Untuk menuju data center menggunakan password dan hanya satu pintu.

Tidak Tidak Ya

Ya Ya

AS-3 AS3.1.1

Ya

AS3.2.1 AS3.3.1

AS3.4.1

Apakah organisasi memelihara informasi pada konfigurasi aplikasi saat ini? Apakah metodologi SDLC dikembangkan: a. Menyediakan pendekatan terstruktur konsisten dengan konsep dan praktik yang diterima, termasuk keterlibatan user dalam proses. b. Terdokumentasi untuk menyediakan bantuan bagi staf dengan keahlian dan pengalaman yang berbeda. c. Menyediakan perangkat untuk mengontrol perubahan kebutuhan yang terjadi setelah sistem diimplementasikan. d. Menyangkut kebutuhan dokumentasi. Apakah formulir permintaan perubahan digunakan untuk permintaan dokumen dan proyek yang berkaitan?

Ya

Kebijakan keamanan TI mengatur tentang manajemen konfigurasi aplikasi. Hal ini tercantum dalam prosedur kerja: TAS/STI/PK/09 tentang Pemasangan Perangkat Teknologi Informasi Konfigurasi aplikasi didokumentasikan

Ya

User terlibat dalam User Acceptance Test (UAT).

Ya Ya

Ada dokumentasi. Ada formulir permintaan perubahan yang harus disetujui oleh pemilik aplikasi.

Ya Ya

Harus ada permintaan resmi dari manajemen senior.

75
Universitas Indonesia

76

AS3.4.2 AS3.5.1

AS3.5.2 AS3.5.3

AS3.5.4

3.5.5

AS3.5.6A AS3.5.7 AS3.5.8

AS3.5.9

Apakah permintaan perubahan harus disetujui oleh user sistem dan staf TI? Apakah standar rencana ujicoba dikembangkan untuk semua level uji coba yang mendefinisikan tanggung jawab tiap pihak (user, analis sistem, programmer, auditor, penyelia kualitas (quality control), dan library control? Apakah spesifikasi sistem detail disiapkan oleh programmer dan ditinjau oleh supervisor programmer? Apakah perubahan software didokumentasikan sehingga dapat ditelusuri untuk otorisasi hingga kode final? Apakah rencana ujicoba yang didokumentasikan dan disetujui menyebutkan tanggung jawab tiap-tiap pihak yang terlibat? Apakah unit, integrasi, dan ujicoba sistem dilakukan dan disetujui: a. Berdasarkan rencana uji coba b. Menerapkan kondisi valid dan invalid? Apakah ujicoba transaksi dan data yang dilaksanakan telah mewakili transaksi dan kondisi yang beragam? Apakah hasil ujicoba ditinjau dan didokumentasikan? Apakah perubahan program yang telah dipindahkan ke produksi terdokumentasi serta disetujui oleh user dan manajemen pengembangan sistem? Apakah dokumentasi selalu update ketika sistem dimodifikasi atau sistem baru diimplementasikan?

Ya Tidak Tidak melibatkan auditor. Quality control berasal dari user. Tugas library control digabung dengan programmer.

Ya

Ya

Dokumentasi belum lengkap, baru saat ini dokumentasi digiatkan.

Ya

Ya Ya Ya

Ya Berupa laporan output. Ya Dokumentasi baru digiatkan saat-saat ini berupa screenshoot baris program. Ya Dokumentasi baru digiatkan saat-saat ini, namun masih berfokus pada interface dan hardware specification. Baru-baru ini baru dilakukan screenshoot baris-baris program dengan menggunakan istilah versi nol, dan seterusnya. Untuk pengembangan baris program, library lama otomatis ditimpa dengan yang baru. Belum ada pemisahan.

AS3.6.1

AS3.6.2 AS3.6.3

AS3.7.1

Apakah library berada di tempat yang terpisah untuk pengembangan program dan pemeliharaan, uji coba serta program produksi? Apakah source code dipisah dengan library? Apakah akses ke seluruh program, termasuk kode produksi, source code, dan kopi ekstra program dilindungi oleh software kontrol akses dan fitur sistem operasi? a. Apakah kelompok user independen dan programmer mengawasi pergerakan program dan data antara library? b. Apakah sebelum dan sesudah citra kode program dibandingkan untuk

Tidak

Ya Ya

Tidak Hanya apabila terjadi masalah.

Ya Ada screenshoot baris program, versi

76
Universitas Indonesia

77

AS3.8.1

AS3.9.1

memastikan hanya perubahan yang disetujui yang diimplementasikan? Apakah akun user untuk peran dalam aplikasi didesain dan disetujui manajemen untuk menyediakan akses yang tepat dan mencegah user yang tidak terotorisasi untuk mengeksekusi transaksi kritis dalam produksi yang mengubah fungsi aplikasi? a. Apakah perubahan kode program aplikasi dan tabel dibatasi dan ditolak dalam lingkungan produksi? b. Semua perubahan yang dibuat menggunakan proses kontrol perubahan yang disetujui? c. Apakah akses user ke kode program aplikasi dan tabel disediakan hanya untuk user ID darurat? Apakah desain keamanan mempertimbangkan transaksi administrator (sistem) yang sensitif dan membatasi user untuk mengakses transaksi tersebut? a. Apakah prosedur disusun untuk memastikan program utama dan perubahan tabel dipantau oleh penanggung jawab yang tidak memiliki wewenang untuk mengubah otorisasi? b. Apakah prosedur menyediakan laporan detail/log to run, kriteria valuasi spesifik, dan frekuensi penilaian (assessment)? Apakah kepatuhan terhadap proses manajemen perubahan dan perubahan untuk mengkonfigurasi obyek dan program secara periodik diukur? Apakah organisasi mengikuti proses yang efektif untuk mengidentifikasi kelemahan dalam aplikasi dan mengupdate-nya? Apakah organisasi mengikuti proses yang efektif untuk secara tepat mendokumentasikan dokumen, uji coba, dan perubahan darurat yang disetujui? Pengawasan pemisahan akses user aplikasi untuk mencegah konflik transaksi dan aktivitas. Apakah pemilik memiliki identifikasi aktivitas dan transaksi yang tidak cocok dan mendokumentasikannya dalam matriks pemisahan tugas? Apakah pemilik mempertimbangkan risiko dengan mengijinkan adanya

nol, versi satu dan seterusnya. Ada hak akses bagi programmer yang sekaligus admin sistem. Namun, akun ini di-share oleh beberapa programmer/admin sistem. Ketika programmer masuk, maka yang ter-log hanya akun tersebut, identitas programmer tidak diketahui. Untuk aplikasi tidak dipisahkan antara lingkungan produksi dan pengembangan. Baru di database saja, terjadi pemisahan. Menggunakan formulir pengajuan perubahan yang ditandatangi pimpinan unit pemilik aplikasi dan TI. Hanya programmer/admin sistem yang bisa mengaksesnya.

Ya

Tidak

Ya

Ya

AS3.10.1

Ya

Dengan kontrol hak akses.

AS3.11.1

Tidak Penanggung jawab eksis dapat mengubah otorisasi.

Tidak Belum komplet.

AS3.12.1

Tidak Kepatuhan diukur sesuai kebutuhan.

AS3.13.1

Ya

Mulai pertengahan 2009 diadakan pertemuan seluruh user dari kantor cabang se-Indonesia untuk membahas kesulitan atau kelemahan aplikasi ini. Sehingga, bisa diadakan perbaikan. Belum komplet, baru digiatkan pada tahun ini.

AS3.14.1

Ya

AS-4

AS4.1.1

Tidak

Belum ada pemisahan tugas antara programmer, analis sistem, dan admin sistem. Belum ada pengukuran risiko secara formal.

AS4.1.2

Tidak

77
Universitas Indonesia

78

AS4.2.1 AS4.3.1 AS4.4.1

AS4.4.2

AS4.4.3

AS4.5.1

AS4.5.2 AS4.5.3 AS-5 AS5.1.1

konflik kepentingan user? Apakah user dicegah oleh aplikasi dari kemungkinan mengakses transaksi yang tidak sesuai dengan haknya? Apakah administrator keamanan tidak memiliki hak untuk menginput dan menyetujui transaksi? Apakah pemilik aplikasi mengotorisasi user untuk memiliki akses ke transaksi/aktvitas yang menyebabkan terjadi konflik tugas, namun sesuai kebutuhan bisnis? Apakah administrator keamanan meninjau otorisasi akses user aplikasi untuk menghindari konflik kepentingan dan mendiskusikan otorisasi yang meragukan dengan pemilik? Apakah pemilik aplikasi secara periodik meninjau akses untuk mengidentifikasi konflik kepentingan yang tidak terotorisasi dan mengetahui apakah konflik kepentingan yang ada masih sesuai? Apakah pemilik proses telah mengidentifikasi konflik kepentingan yang dapat eksis, peranannya dan useruser yang konflik? Apakah kontrol pengawasan yang didokumentasikan memuat konflik yang dimitigasi oleh kontrol? Apakah manajemen telah mendokumentasikan bukti dari pemantauan yang efektif ? Implementasi perencanaan darurat untuk aplikasi yang efektif. Apakah manajemen menentukan aplikasi yang memiliki fungsi kritis dan apa saja sumber daya TI (data dan program) untuk aplikasi tersebut?

Ya

Dengan adanya kontrol hak akses.

Ya

Ya

Tidak

Jika ada peristiwa yang berdampak negatif pada aplikasi.

Tidak

Peninjauan dilakukan jika ada peristiwa yang berdampak negatif pada aplikasi.

Tidak

Belum dilakukan pengkajian.

Tidak

Belum ada dokumentasi.

Tidak

Belum ada dokumentasi.

Tidak

AS5.1.2

Apakah telah dilakukan identifikasi dampak dari gangguan terhadap aplikasi dan berapa lama aplikasi boleh berhenti?

Tidak

AS5.1.3 AS5.2.1 AS5.2.2

Apakah ada penyusunan prioritas pemulihan untuk membantu menentukan strategi pemulihan? Apakah file backup dari data aplikasi utama dibuat berdasarkan ketentuan? Apakah program aplikasi yang eksis memiliki kopi dan dapat digunakan

Tidak

Pernah dilakukan kajian oleh Divisi Perencanaan dan Pengembangan Bisnis, namun belum lengkap hingga ke sumber daya TI, serta belum dikomunikasikan secara formal untuk ditindaklanjuti. Tahun lalu pernah dilakukan jajak pendapat ke 50 responden tentang aplikasi kritis, dan modul peserta salah satunya. Responden paling banyak memilih 8 jam. Namun, kajian ini masih belum komplet dan belum dikomunikasikan secara formal untuk ditindaklanjuti. Belum ada petunjuk yang baku.

Ya

Ya

Ada di prosedur kerja Divisi TI di TAS/STI/PK/04 tentang Back Up Sistem dan Database. Full back up otomatis dilakukan seminggu sekali, dan adapula back up

78
Universitas Indonesia

79

sewaktu-waktu? AS5.2.3 Apakah file backup dari data aplikasi dan program terlindungi di tempat yang aman dan dapat digunakan untuk kondisi darurat? Apakah ada ada rencana darurat untuk aplikasi secara periodik? Apakah rencana darurat untuk aplikasi tergabung dalam disaster recovery plan, business continuity plan), dan business resumption plan)? Tidak

harian. Back up manual dilakukan apabila back up otomatis gagal. Belum ada disaster recovery center. Server ada di tiap-tiap kantor cabang utama.

AS5.3.1 AS5.3.2

Tidak Tidak

Masih dalam kajian Divisi Renbang, belum komplet dan belum dijalankan. Belum lengkap. Saat ini Taspen memiliki TAS/STI/PK/10 tentang Contingency Plan Apabila Server Mati (Divisi TI) dan TASP/LY/PK/19 tentang Contingency Plan (Divisi Pelayanan). Contingency plan yang telah ada masih belum lengkap, hanya memuat langkah-langkah yang dilakukan apabila server mati dan apabila terjadi bencana di kantor cabang. Namun, belum memuat langkah-langkah apabila back up database dan sistem di kantor cabang utama atau di kantor pusat musnah. Organisasi hingga saat ini belum memiliki DRP, BCP, dan business resumption plan.

AS5.3.3

AS5.4.1 AS5.4.2

AS5.4.3 AS5.4.4

Apakah operasi darurat menyediakan lingkungan kontrol yang efektif dengan membatasi dan mengawasi akses user untuk data aplikasi dan program, meliputi: a. User teridentifikasi dan terautentikasi. b. User secara tepat terotorisasi sebelum melakukan transaksi sensitif. c. Audit dan monitoring kemampuan beroperasi. Apakah rencana darurat aplikasi secara periodik diuji termasuk simulasi bencana? Apakah area berikut termasuk dalam ujicoba rencana darurat? a. Pemulihan sistem dengan platform yang berbeda dari media backup. b. Ada koordinasi antar tim perbaikan. c. Konektivitas internal dan eksternal. d. Kinerja sistem dengan perangkat alternatif. e. Restorasi operasi normal. f. Prosedur pemberitahuan. Apakah hasil ujicoba terdokumentasi dan dilaporkan sebagai pembelajaran dan diberikan ke manajemen senior? Apakah rencana darurat dan perjanjian yang berkaitan serta persiapan dapat

Ya Ya

Tidak Tidak

Belum dilakukan secara berkala. Belum pernah dilakukan ujicoba rencana darurat.

Tidak Tidak Tidak Tidak Tidak Tidak Tidak

Belum pernah dilakukan ujicoba .rencana darurat.

Belum pernah dilakukan ujicoba rencana darurat. Belum pernah dilakukan.

Tidak

79
Universitas Indonesia

80

disesuaikan untuk memperbaiki kekurangan selama ujicoba? B BP-1 BP1.1.1 Kontrol Proses Bisnis (Business Process Control) Input data transaksi komplet, akurat, valid, dan rahasia (confidential). Apakah ada SOP tentang manajemen data yang memuat: strategi data transaksi, desain data, data definition, standar kualitas data, kepemilikan, dan prosedur pengawasan? Apakah ada prosedur untuk menjamin semua input aplikasi telah terotorisasi, diterima untuk diproses, dan ada penanggung jawabnya? Dan apakah kekurangan dokumen asal/sumber atau file input telah diidentifikasi dan diinvestigasi? Beberapa prosedur umumnya terdiri dari satu atau beberapa prosedur: batch total, sequence checking, rekonsiliasi, dan control total Apakah ada prosedur yang diimplementasikan untuk akses kontrol bagi application input routines dan media input fisik (kosong dan lengkap) ? Apakah prosedur terdokumentasi eksis untuk memvalidasi data input sebelum masuk dalam sistem? Apakah edit yang sesuai digunakan untuk memastikan data valid dan terekam dalam format yang benar? Meliputi: a. Otorisasi atau kode yang disepakati. b. Kontrol format field. c. Kontrol field yang diperlukan.

Ya

Ada di SOP Administrasi Data Peserta sesuai SK-48/DIR/2008.

BP1.2.1

Tidak

Setahun dua kali ada rekonsiliasi antara Taspen dengan penyedia data. Selain itu, juga dilakukan control total untuk data yang diinputkan. Namun, realitanya rekonsiliasi ini belum rutin dilakukan dan masih terdapat selisih data peserta dari rekap hasil proses daftar gaji antara database organisasi dan yang diperoleh dari Pemda

BP1.3.1

Ya

Ada. Media input fisik rata-rata hanya berupa flash disk dan compact disk.

BP1.4.1 BP1.5.1

Ya

SOP tersebut digunakan di kantor pusat dan seluruh kantor cabang Taspen.

Ya Tidak Tidak

Kontrol belum berfungsi dengan baik. Masih ada NIP yang salah. Kontrol belum berfungsi dengan baik. Ada field yang salah atau kosong tetap bisa masuk ke sistem, seperti tanggal lahir kosong, gaji pokok salah. Kontrol belum berfungsi dengan baik. NIP dan tanggal lahir tidak sinkron bisa masuk dalam sistem. Kontrol belum berfungsi dengan baik. Ada peserta yang usianya kurang dari 18 tahun dan ada gaji pokok nilainya nol. Kontrol belum berfungsi dengan baik. Nilai THP tidak sesuai dengan hasil perhitungan. Kontrol belum berfungsi dengan baik. NIP masih terduplikasi.

d. Pembatasan. e. Kombinasi yang valid dari nilai field data yang berkaitan. f. Cek kisaran.

Ya Tidak

Tidak

g. Akurasi matematis.

Tidak

h. Pencocokan file master. i. Kontrol proses duplikat. j. Balancing control.

Ya Tidak Ya

80
Universitas Indonesia

81

BP1.5.2

a. Apakah perubahan dan validasi override dibatasi untuk user terotorisasi? b. Apakah ada prosedur untuk memantau override dan memelihara override log? Apakah prosedur pemeliharaan tabel termasuk edit dan kontrol validasi untuk membantu memastikan hanya perubahan yang valid yang dilakukan pada tabel data? a. Apakah parameter dan toleransi dikonfigurasi serta kondisi error dan pesan telah didefinisikan? b. Manajemen meninjau ulang batasan dalam menginputkan data dan memvalidasi bahwa data akurat dan tepat secara reguler. a. Apakah prosedur ada untuk memastikan bahwa semua input dalam aplikasi telah diterima untuk diproses dan dicek kebenarannya? b. Apakah semua input yang kurang dari dokumen sumber telah diidentifikasikan dan diinvestigasi? Apakah kesalahan input data teridentifikasi dalam laporan kesalahan serta diperbaiki untuk diinputkan kembali? Pemrosesan data transaksi lengkap, akurat, valid, dan rahasia (confidential). a. Apakah aplikasi memproses data yang masuk secara otomatis dan standar? b. Apakah ada dokumentasi desain proses yang eksis untuk memvalidasi dan tujuan kontrol perubahan? c. Apakah versi yang digunakan dalam aplikasi, data, dan file yang akan diproses tersebut tepat dan sesuai kondisi saat ini? a. Apakah sistem memiliki log transaksi untuk memastikan seluruh transaksi terproses dengan baik? b. Apakah sistem dapat mengidentifikasi transaksi yang tidak komplet? Apakah ada prosedur untuk mengidentifikasi dan meninjau proses transaksi yang tidak komplet, menganalisanya, dan mengambil tindakan yang tepat? Apakah prosedur eksis untuk memantau

Ya

Tidak

Perubahan dan override biasanya setelah ada evaluasi dan atas perintah atasan. Tidak ada log khusus override, hanya berdasarkan log login dan log transaksi. Ada warning jika data tidak valid.

BP1.5.3

Ya

BP1.6.1

Ya

Tidak

Bila diperlukan saja.

BP1.7.1

Ya

Ada dalam prosedur kerja: TAS/ADP/PK/01 tentang Peremajaan Data Peserta Secara Interaktif. Dokumen yang kurang dikonfirmasikan ke penyedia data (instansi, KPPN, Pemda dan sebagainya).

Ya

BP1.8.1

Ya

BP-2 BP2.1.1

Ya

Ya

Ya

Ada warning ketika membuka aplikasi tersebut bahwa ada versi terbaru dari aplikasi.

BP2.2.1

Ya

Tidak

BP2.2.2

Ya

BP-

Ya

Kontrol belum komplet, sehingga jika ada transaksi yang tidak komplet tetap bisa masuk ke sistem. Ya, pada instruksi kerja nomor TAS/ADP/IK/02/05 tentang Analisis Listing Invalid Hasil Proses Data Gaji. Serta formulir kerja nomor TAS/ADP/FK/02/06 tentang Agenda Konfirmasi Data. Untuk override data invalid maka

81
Universitas Indonesia

82

2.2.3

overrides yang diterapkan dalam proses transaksi?

BP2.3.1

Apakah ada dokumentasi pemrosesan dan posting condition (parameter dan toleransi), termasuk kesalahan sistem serta memuat langkah-langkah jika kondisi tersebut tidak terpenuhi? Apakah manajemen meninjau secara reguler batasan untuk memvalidasi keakuratan dan ketepatan? Apakah aplikasi menampilkan edit secara online dan cek validasi data yang sedang diproses? Apakah prosedur sistem memberikan pesan kesalahan atau warning? Apakah transaksi yang salah ditolak atau didiamkan hingga diperbaiki? Apakah aplikasi mengkomunikasikan kesalahan pemrosesan pada user secara online ? Apakah transaksi terotorisasi? Apakah ada rekonsiliasi secara periodik dan exception ditangani secara tepat?

Ya

berdasarkan instruksi kerja nomor TAS/ADP/IK/02/15 tentang Proses Insert Data TAR dan Nisanala dari Perekaman Gaji Manual. Ya, pada bagian SOP Administrasi Data Peserta: TAS/CHR/01 tentang Standard Karakteristik Data dan instruksi kerja nomor TAS/ADP/IK/02/05 tentang Analisis Listing Invalid Hasil Proses Data Gaji.

BP2.3.2 BP2.4.1 BP2.4.2 BP2.4.3 BP2.4.4 BP2.5.1 BP2.6.1

Ya Ya Aplikasi menampilkan proses edit dan memberikan warning jika data invalid.

Ya Ya Namun karena kontrol belum lengkap, maka masih ada transaksi yang salah tetap bisa masuk dalam sistem.

Ya

Ya Tidak Tiap enam bulan ada rekonsiliasi antara Taspen dan penyedia data (KPPN, Pemda, BKN dan sebagainya), juga ada konfirmasi untuk data-data yang invalid. Namun, exception belum ditangani secara tepat. Petugas penginput data dibekali training SOP dan buku petunjuk. Ada log login dan transaksi. Belum ada proses enkripsi.

BP2.7.1 BP2.7.2 BP2.8.1

BP2.9.1

Apakah kebijakan dan prosedur diikuti oleh user? Apakah kontrol pemrosesan oleh user cukup memenuhi? Apakah manajemen mengimplementasikan kontrol yang sesuai untuk melindungi kerahasiaan data selama pemrosesan? Apakah manajemen memiliki prosedur untuk rekonsiliasi input data dengan data yang diproses aplikasi? a. Apakah ada prosedur pemantauan untuk mengetahui data yang ditambahkan atau dimodifikasi selama proses? b. Apakah log audit sistem ditinjau untuk exception? Apakah manajemen memelihara log proses dan log itu ditinjau untuk aktivitas yang abnormal dan tidak terotorisasi? Apakah prosedur eksis untuk memantau override pada transaksi, termasuk pemeliharaan override log?

Ya Ya Tidak

Ya

BP2.9.2

Ya

Tidak Tidak

Dengan kontrol input dan TAS/ADP/IK/02/09 tentang Pencetakan Laporan Rekon Data (Lampiran 6A). Sesuai dengan TAS/ADP/FK/02/16 Daftar Data NISANALA dan TASS/ADP/FK/02/21 Rekap Hasil Proses Data Gaji. Ditinjau sesuai kebutuhan. Ditinjau jika ada permasalahan.

BP2.9.3

BP2.9.4

Tidak

Tidak ada override log.

82
Universitas Indonesia

83

BP-3 BP3.1.1

Output data transaksi komplet, akurat, valid, dan rahasia (confidential). Apakah manajemen telah menyusun strategi pelaporan yang meliputi? a. Konten dan ketersediaan yang konsisten dengan kebutuhan user b. Kesensitifan dan kerahasiaan data c. Akses user untuk data output

Ya Tidak Ya

BP3.2.1

Apakah manajemen memiliki prosedur untuk memastikan konten dan ketersediaan output dan data konsisten dengan kebutuhan user, aturan sensitivitas, dan kerahasiaan data serta akses user yang valid?

Tidak

BP3.2.2

Apakah manajemen memiliki prosedur untuk memantau replikasi data output yang digunakan dalam laporan manajemen atau media lain di luar organisasi?

Ya

Sesuai dengan TAS/ADP/PK/17 tentang Penyajian Data Peserta yaitu memuat tentang user yang berhak melakukan rekap, sedangkan bagi unit lain yang memerlukan harus mengirim surat dan teragendakan dalam Agenda Penyajian Data Peserta (TAS/ADP/FK/17/01) . Namun, prosedur kerja ini belum membahas tentang penggolongan data yang sensitif dan rahasia secara formal. Ada instruksi kerja: TAS/ADP/IK/02/01 tentang Meneliti Kebenaran Data Namun, belum ada prosedur kerja yang memuat aturan sensitivitas dan kerahasiaan data. Sementara tentang akses user ada di TAS/STI/PK/11 tentang Create User dan Hak Akses Aplikasi yang dimiliki Divisi TI. Sesuai dengan TAS/ADP/PK/17 tentang Penyajian Data Peserta yaitu memuat tentang user yang berhak melakukan rekap, sedangkan bagi unit lain yang memerlukan harus mengirim surat dan teragendakan dalam Agenda Penyajian Data Peserta (TAS/ADP/FK/17/01) . Harus ada surat permohonan.

BP3.2.3

BP3.3.1 BP3.3.2

BP3.3.3 BP3.4.1

Apakah akses user untuk data output selaras dengan peran user dan kerahasiaan /sensitivitas informasi? Apakah manajemen memiliki laporan utama untuk menelusuri hasil pemrosesan? Apakah manajemen telah mendokumentasikan prosedur: a. Meninjau hasil proses b. Monitor override, termasuk pemeliharaan override log? Apakah ada prosedur untuk meninjau data output kritis atau laporan kontrol? Apakah laporan output untuk kepatuhan dengan hukum serta regulasi akurat dan lengkap?

Ya

Ya

Ya Tidak Ya Tidak

Belum ada pemeliharaan override log

BP3.5.1 BP3.5.2

Apakah akses untuk laporan terbatas bagi user? Apakah user memiliki tingkatan akses untuk membaca laporan

Ya

Ya

Organisasi menargetkan 98% keakuratan data tercapai, namun belum semua kantor cabang memenuhi. Selain itu, masih ada data yang tidak valid dan masih menjadi catatan oleh BPK. Selain staf data di Kantor Pusat, unit lain boleh meminta laporan dengan surat yang disetujui atasan. Jika user memiliki hak baca maka bisa membaca laporan. Penentuan hak akses ini dilakukan oleh Kabid/Kasi di

83
Universitas Indonesia

84

kantor cabang masing-masing. BP-4 BP4.1.1 BP4.1.2 Pengaturan data master dan pemeliharaan cukup terkontrol. Apakah semua entri terisi untuk field utama? Apakah nilai null atau invalid tidak diterima?

Ya Tidak

NIK tidak boleh kosong. Nilai null diperbolehkan untuk field tertentu, terutama untuk peserta BUMN. Namun dalam realitanya, tanggal lahir bisa null. Ruang lingkup karya akhir ini hanya ke modul manajemen data, tidak sampai ke proses klim. Belum ada kebijakan dan prosedur tersebut. Di SOP Divisi Pelayanan hanya memuat perubahan untuk penambahan atau pengurangan tabel wilayah (TAS/ADP/PK/18 tentang Pemeliharaan Tabel). TAS/ADP/PK/18 tentang Pemeliharaan Tabel menyebutkan permintaan perubahan user harus melalui surat dan diketahui kepala bidang/seksi bersangkutan serta dokumen pendukung berkekuatan hukum. Di SOP belum ada penjelasan apabila perubahan hanya bisa untuk non key field. Ditinjau apabila ada permasalahan belum secara reguler.

BP4.1.3 BP4.2.1

Untuk aplikasi keuangan, apakah akun aset, utang terdefinisi dengan jelas? Apakah kebijakan dan prosedur disusun untuk manajemen konfigurasi data master dimana memuat aturan perubahan yang menjelaskan field data yang tetap? Apakah perubahan pada desain data master disetujui oleh pihak yang tepat?

Tidak

BP4.2.2

Ya

BP4.2.3 BP4.3.1

Apakah perubahan rekaman data master dibatasi untuk non-key-field? Apakah data master ditinjau secara periodik, penggandaan teridentifikasi dan dihilangkan, serta data yang tidak digunakan diblok? Apakah ada kontrol otomatis yang mencegah duplikasi perekaman? Apakah kebijakan dan prosedur untuk pemeliharaan data master terdokumentasi dan meliputi: a. Persyaratan persetujuan. b. Kriteria kualitas data. c. Kepemilikan data. d. Dokumen pendukung. e. Prosedur back up saat bencana atau data korup. f. Kebijakan arsip. Apakah proses pemeliharaan data master meliputi permintaan perubahan format dan disetujui pemilik data. Apakah konflik tugas dipertimbangkan sebelum memberikan akses untuk transaksi data master? Laporan edit ditinjau oleh pemilik data secara periodik untuk meninjau data master baru dan perubahan pada data master yang eksis? Apakah ada prosedur rekonsiliasi secara periodik untuk memastikan data konsisten antarmodul aplikasi yang

Tidak

Tidak

BP4.3.2 BP4.4.1

Ya

Ya Ya Ya Ya Tidak Ya Ya

Kebijakan dan prosedur pemeliharaan data master belum lengkap.

BP4.4.2 BP4.4.3 BP4.4.4

Sesuai prosedur TAS/ADP/PK/18 tentang Pemeliharaan Tabel. Belum ada analisis tentang konflik tugas. Ada laporan ke pemilik dan user yang meminta tentang tabel baru sesuai TAS/ADP/PK/18 tentang Pemeliharaan Tabel. Hasil output modul peserta akan menjadi input modul keuangan, aktuaria, dan investasi.

Tidak

Ya

BP4.5.1

Ya

84
Universitas Indonesia

85

BP4.6.1

berbeda? Apakah kebijakan dan prosedur data master membutuhkan pemilik data untuk membuat, menghapus dan mengubah data master serta perubahan lainnya? Apakah pemilik data memantau perubahan desain data master dan menyetujui serta memonitor perubahan secara periodik? Apakah manajemen mengimplementasikan kontrol yang cukup untuk melindungi data master yang penting? Kontrol Antarmuka (Interface Control) Implementasi desain dan strategi antarmuka yang efektif Apakah ada strategi antarmuka (interface) untuk tiap-tiap antarmuka yang meliputi metode antarmuka, data field dalam antarmuka, kontrol untuk memastikan kelengkapan dan keakuratan antarmuka, jadwal (schedule), penanggung jawab, kebutuhan system balancing, dan kebutuhan keamanan? Apakah ada desain antarmuka untuk tiap-tiap antarmuka yang meliputi spesifikasi yang tepat berdasarkan kebutuhan bisnis, terdiri dari validasi dan perubahan; kepemilikan proses antarmuka; metode komunikasi dan koreksi kesalahan? a. Apakah ada tabel pemetaan yang digunakan untuk mengkonversi data dari sistem sumber (source system) ke sistem sasaran (target system)? b. Apakah ada kontrol untuk memastikan tabel pemetaan hanya berubah ketika ada otorisasi dan data historis tetap tersimpan dengan tabel pemetaan sebelumnya? Implementasi prosedur pemrosesan antarmuka yang efektif a. Apakah prosedur yang ada memiliki daftar yang lengkap tentang cara berjalan antarmuka, waktu proses antarmuka, bagaimana prosesnya, dan bagaimana rekonsiliasi? b. Apakah waktu proses antarmuka ditentukan dan diikuti? c. Apakah ada pemberitahuan untuk memastikan file terkirim dari

Ya

Sesuai SOP: TAS/ADP/PK/18 tentang Pemeliharaan Tabel.

BP4.6.2

Tidak

Sesuai kebutuhan.

BP4.7.1

Tidak

Belum ada enkripsi.

C IN-1 IN-1.1

Tidak

Strategi antarmuka ada namun belum didokumentasikan. Kebutuhan system balancing dan kebutuhan keamanan belum didefinisikan.

IN1.2.1

Ya

Desain antarmuka ada meski belum didokumentasikan secara komplet.

IN1.2.2

Ya

Ada.

Ya

Perubahan tabel pemetaan hanya dapat dilakukan oleh IT support (administrator sistem) berdasarkan kebutuhan bisnis secara formal.

IN-2 IN-21.1

Tidak

Belum lengkap, waktu proses belum didefinisikan.

Tidak Ya

Tidak ada standar bergantung bandwith masing-masing

85
Universitas Indonesia

86

sistem sumber/asal ke sistem sasaran (target system)? IN-22.1 Apakah ada personel yang ditugaskan untuk proses antarmuka dan mengkoreksi kesalahan dari sistem asal ke sistem target? Apakah file-file yang dihasilkan dari antarmuka aplikasi (sumber dan target) aman dari akses dan atau modifikasi yang tidak terotorisasi ? Apakah user yang memproses antarmuka dapat memantau status antarmuka tersebut? Apakah rekonsiliasi dilakukan antara aplikasi sumber dan target untuk memastikan antarmuka lengkap dan akurat? Apakah ada log untuk proses antarmuka seperti error dan exception? Apakah laporan ini dievaluasi oleh manajemen secara berkala? Apakah fasilitas koreksi dan kesalahan digunakan untuk menelusuri kesalahan yang telah terkoreksi dalam data antarmuka? Apakah ada mekanisme untuk memberitahu user apabila data ditolak? Pesan ini berulang kali muncul hingga data dikoreksi? Apakah ada audit trail untuk mengidentifikasi dan mem-follow up kesalahan antarmuka? Apakah file-file antarmuka secara otomatis terarsip atau terhapus dari lingkungan produksi setelah diproses? Kontrol Sistem Manajemen Data (Data Management System Controls) Implementasi strategi dan desain sistem manajemen data yang efektif. Apakah lokasi fisik dan logis (untuk konektivitas) dari penyimpanan data dan fungsi retrieval sudah tepat? Apakah ada pemisahan antara sistem manajemen data produksi dan data non produksi (untuk uji coba dan pengembangan)? Apakah database schema konsisten dengan kontrol akses? Apakah ada sistem logging untuk mengidentifikasi aktivitas sistem dan akses data? Apakah ada kontrol yang secara real time memberitahukan apabila ada Tidak Belum ada personel yang khusus menangani antarmuka. Hal ini dikerjakan oleh administrator sistem yang merangkap sebagai programmer.

IN-22.2

Ya

IN-22.3 IN-23.1

Tidak Ya Ujicoba oleh pemilik sistem (Divisi Pelayanan).

IN-24.1

Ya

IN-25.1

Ya

IN-25.2

Ya

IN-25.3 IN-26.1

Ya

Ya

D DA-1 DA1.1.1

Tidak

Belum ada dokumentasi fisik tentang desain data, termasuk lokasi fisik dan logis.

DA1.1.2

Ya

DA1.1.3 DA1.2.1 DA1.2.2

Ya Ya Tidak Peringatan hanya apabila user belum secara komplet mengisi field-field

86
Universitas Indonesia

87

DA1.3.1 DA1.3-2

aktivitas abnormal? Apakah ada kontrol apabila data yang dimasukkan tidak valid dan tidak komplet? Apakah ada kontrol untuk membatasi akses dalam mengkonfigurasi sistem ini?

Tidak

wajib. Ada alert message, namun kontrol belum lengkap.

Ya

Penulis kemudian melakukan pemetaan dari tabel rekapitulasi hasil wawancara dengan panduan FISCAM terhadap control objective dalam COBIT 4.1 seperti pada tabel 5.5
Tabel 5.5: Hasil Rekapitulasi Kontrol FISCAM terhadap Control Objective COBIT4.1 No FISCAM AS-1: Implementasi manajemen keamanan aplikasi. AS-1.1A:Rencana keamanan aplikasi. AS-1.2.2: Identifikasi akun sensitif. AS-1.1.3: Pembatasan akses transaksi. AS-1.2.1: Pengukuran risiko. AS-1.3.1: Persetujuan risiko dari pemilik proses bisnis. AS-1.3.2: Kebijakan dan prosedur keamanan aplikasi. AS-1.4.1: Proses pengkomunikasian kebijakan keamanan. AS-1.4.2: Sosialisasi keamanan TI. AS-1.5.1: Pendokumentasian kebijakan keamanan aplikasi dan rencana prosedur ujicoba. AS-1.5.2: Ujicoba kontrol keamanan aplikasi secara periodik. AS-1.5.3: Frekuensi ujicoba terkait dengan risiko. AS-1.5.4: Kepatuhan terhadap regulasi menjadi bagian dari program keamanan organisasi. AS-1.6.1: Proses koreksi kelemahan keamanan aplikasi. AS-1.6.2: Inisiasi manajemen mengkoreksi kelemahan keamanan aplikasi. AS-1.6.3: Analisa kelemahan keamanan oleh aplikasi/tools. AS-1.6.4 : Pemantauan aksi korektif. P02 P09 Proses COBIT AI6 DS5 DS 11 DS 12 Ya Tidak

1 2 3 4 5 6 7

v v v v v v

14 v v 1

2 v 1 v

v v

8 9

v v

v v

10 11 12

v v v v

v v v

13 14

v v

v v

v v

15 16

v v

v v

v v

87
Universitas Indonesia

88

N O 17

FISCAM AS-1.7.1: Kebijakan dan prosedur keamanan dengan aktivitas pihak ketiga. AS-1.7.2: Proses memantau kepantauan provder pihak ketiga. AS-2: Implementasi kontrol akses aplikasi. AS-2.1.1: Batasan aplikasi dalam rencana keamanan. AS-2.2.1: Identifikasi dan autentikasi unik bagi setiap user. AS-2.3.1: Prosedur formal memberikan akses. AS-2.3.2: Kegagalan login. AS-2.3.3: Satu akun untuk satu user. AS-2.3.4: Pemantauan multiple log on. AS-2.4.1: Otorisasi akses level user. AS-2.4.2: Peninjauan akses secara periodik. AS-2.4.3: Akses terbatas bagi tiap individu. AS-2.5.1: Implementasi rencana keamanan dan proses. AS-2.6.1: Identifikasi transaksi/aktivitas sensitif. AS-2.6.2: Otorisasi user untuk akses aktivitas sensitif. AS-2.6.3: Peninjauan otoritas akses user ke aktivitas sensitif oleh administrator keamanan. AS-2.6.4: Peninjauan otoritas akses user ke aktivitas sensitif oleh administrator pemilik. AS-2.6.5: Terminasi akun inaktif. AS-2.6.6: hak individu ke akses aktivitas sensitif. AS-2.7.1: Sumber daya aplikasi sensitif telah cukup aman. AS-2.8.1: Kebijakan dan prosedur untuk audit keamanan. AS-2.9.1: Deteksi pelanggaran keamanan. AS-2.10.1: Laporan pelanggaran. AS-2.11.1: Kontrol fisik aplikasi. AS-3: Implementasi Manajemen Kofigurasi Aplikasi AS-3.1.1: Manajemen konfigurasi aplikasi. AS-3.2.1: Pemeliharaan informasi pada konfigurasi aplikasi. AS-3.3.1: Pengembangan metodologi SDLC.

P02

P09

AI6

DS5 v

DS 11

DS 12

Ya

Tidak v

18

19 20 21 22 23 24 25 26

v v v v v v v v v v

V v

v v v

27 28 29 30 31

v v v v v

v 1 v v v 4

32

33 34 35 36 37 38 39

v v v v v v v

v v 2 1 v v v v

40 41 42

v v v v

v v v

88
Universitas Indonesia

89

N O 43 44 45

FISCAM AS-3.4.1: Penggunaan formulir permintaan perubahan. AS-3.4.2: Persetujuan permintaan perubahan. AS-3.5.1: Tanggung jawab tiap pihak dalam standar rencana ujicoba AS-3.5.2: Spesifikasi sistem detail. AS-3.5.3: Dokumentasi perubahan software AS-3.5.4: Dokumentasi tanggung jawab personel dalam rencana ujicoba. AS-3.5.5: Ujicoba unit, integrasi, dan sistem. AS-3.5.6A: Ujicoba transaksi dan data. AS-3.5.7: Dokumentasi hasil ujicoba. AS-3.5.8: Dokumentasi perubahan program ke lingkungan produksi. AS-3.5.9: Dokumentasi perubahan sistem. AS-3.6.1: Pemisahan library. AS-3.6.2: Source code dipisah dengan library. AS-3.6.3: Akses ke seluruh program. AS-3.7.1: Pergerakan program dan data. AS-3.8.1: Otorisasi akun user dalam mengubah fungsi aplikasi. AS-3.9.1: Perubahan kode program. AS-3.10.1: Batasan administrator sistem. AS-3.11.1: Prosedur pemantauan perubahan. AS-3.12.1: Pengukuran kepatuhan terhadap proses manajemen perubahan. AS-3.13.1: Identifikasi kelemahan aplikasi. AS-3.14.1: Dokumentasi perubahan darurat. AS-4: Pemisahan akses user aplikasi. AS-4.1.1: Identifikasi aktivitas dan transaksi yang tidak cocok. AS-4.1.2: Risiko konflik kepentingan user. AS-4.2.1: Kontrol aplikasi mengakses transaksi yang tidak sesuai hak akses.

P02

P09

AI6 v v v

DS5

DS 11

DS 12

Ya v v

Tidak

46 47 48

v v v

v v v

49 50 51 52 53 54 55 56 57 58 59 60 61 62

v v v v v v v v v v v v v v v

v v v v v v v v 1 v 2 v 1 1

v v

63 64

v v

v v

65 66 67

v v

v v

89
Universitas Indonesia

90

N O 68

FISCAM AS-4.3.1: Batasan administrator keamanan dalam mengakses transaksi. AS-4.4.1: Otorisasi user yang memiliki konflik tugas. AS-4.4.2: Peninjauan oleh admin keamanan terhadap otorisasi akses user aplikasi. AS-4.4.3: Peninjauan akses untuk menghindari konflik kepentingan. AS-4.5.1: Identifikasi konflik kepentingan. AS-4.5.2: Mitigasi konflik oleh kontrol. AS-4.5.3: Bukti pemantauan yang efektif. AS-5: Implementasi perencanaan darurat. AS-5.1.1: Identifikasi aplikasi berfungsi kritis. AS-5.1.2: Identifikasi dampak dari gangguan. AS-5.1.3: Strategi pemulihan. AS-5.2.1: Ketentuan file backup dari data aplikasi utama. AS-5.2.2: Kopi program aplikasi yang eksis. AS-5.2.3: Keamanan file backup dari data aplikasi dan program. AS-5.3.1: Rencana darurat aplikasi. AS-5.3.2: Rencana darurat aplikasi dalam DRP, BCP, dan business resumption plan. AS-5.3.3: Lingkungan kontrol yang efektif untuk operasi darurat. AS-5.4.1: Pengujian rencana darurat aplikasi. AS-5.4.2: Ujicoba rencana darurat. AS-5.4.3: Dokumentasi hasil ujicoba rencana darurat. AS-5.4.4: Tindakan memperbaiki kekurangan selama ujicoba rencana darurat. Kontrol Proses Bisnis BP-1: Input data transaksi komplet, akurat, valid, dan rahasia. BP-1. 1.1: Prosedur manajemen data. BP-1-2.1: Prosedur untuk menjamin semua input aplikasi terotorisasi. BP-1.3.1: Prosedur untuk akses kontrol input aplikasi.

P02

P09

AI6

DS5 v

DS 11

DS 12

Ya v

Tidak

69 70

v v

v v

71 72 73 74

v v v

v v v v

v v v v

75 76 77 78 79 80 81 82

v v v v v v v v v

v v v v v v v v v

83 84 85 86

v v v v

1 v v v

87

1 2 3

v v v

v v v

90
Universitas Indonesia

91

N O 4 5 6 7 8 9 10

FISCAM BP-1.4.1: Prosedur validasi data input. BP-1.5.1: Kontrol validitas data BP-1.5.2: Perubahan dan validasi override. BP-1.5.3: Prosedur pemeliharaan tabel. BP-1.6.1: Konfigurasi parameter dan toleransi. BP-1.7.1: Prosedur memastikan kebenaran dan kekurangan input. BP-1.8.1: Identifikasi kesalahan input. BP-2: Pemrosesan data transaksi lengkap, akurat, valid, dan rahasia (confidential). BP-2.1.1: Standar pemrosesan data. BP-2.2.1: Logging transaksi. BP-2.2.2: Prosedur identifikasi dan meninjau proses transaksi yang tidak komplet. BP-2.2.3: Pemantauan override. BP-2.3.1: Dokumentasi pemrosesan dan kesalahan sistem. BP-2.3.2: Batasan validasi keakuratan. BP-2.4.1: Edit dan cek validasi data online. BP-2.4.2: Pesan kesalahan pada sistem. BP-2.4.3: Perbaikan transaksi yang salah. BP-2.4.4: Komunikasi kesalahan pemrosesan. BP-2.5.1: Otorisasi transaksi. BP-2.6.1: Rekonsiliasi secara periodik. BP-2.7.1: Kepatuhan user terhadap kebijakan dan prosedur. BP-2.7.2: Kontrol pemrosesan user. BP-2.8.1: Perlindungan data selama pemrosesan. BP-2.9.1: Rekonsiliasi input data dengan data yang terproses dalam aplikasi. BP-2.9.2: Prosedur pemantauan untuk mengetahui penambahan/modifikasi data. BP-2.9.3: Peninjauan log proses. BP-2.9.4: Pemantauan override log. BP-3: Output data transaksi komplet, akurat, valid, dan rahasia (confidential). BP-3.1.1: Strategi pelaporan.

P02

P09

AI6

DS5

DS 11 v v

DS 12

Ya v 5 1 v 1 v v

Tidak

v v v v v v

5 1

v v v v

11 12 13

v v v

v v 1

14 15 16 17 18 19 20 21 22 23 24 25 26

v v v v

v v v v v v v v v v v v v

v v v v

v v v v v v v v v v v

27

28 29

v v

v v

v v

30

91
Universitas Indonesia

92

N O 31

FISCAM BP-3.2.1: Prosedur untuk memastikan konten dan ketersediaan output dan data konsisten dengan kebutuhan user. BP-3.2.2: Prosedur untuk memantau replikasi data output. BP-3.2.3: Kerahasiaan informasi dan akses user. BP-3.3.1: Laporan utama untuk menelusuri hasil pemrosesan. BP-3.3.2: Prosedur peninjauan hasil proses. BP-3.3.3: Prosedur meninjau data output kritis. BP-3.4.1: Laporan output untuk kepatuhan dengan hukum. BP-3.5.1: Batasan akses laporan. BP-3.5.2: Tingkatan akses membaca laporan. BP-4: Pengaturan data master. BP-4.1.1: Pengisian field utama. BP-4.1.2: Pengisian nilai null dan invalid. BP-4.1.3: Pendefinisian akun asetutang. BP-4.2.1: Field data yang tetap. BP-4.2.2: Perubahan pada desain data master. BP-4.2.3: Pembatasan untuk nonkey-field. BP-4.3.1: Peninjauan data master. BP-4.3.2: Duplikasi perekaman. BP-4.4.1: Kebijakan dan prosedur pemeliharaan data master. BP-4.4.2: Permintaan perubahan format data master. BP-4.4.3: Pertimbangan konflik tugas sebelum memberikan akses. BP-4.4.4: Peninjauan laporan perubahan. BP-4.5.1: Prosedur rekonsiliasi antarmodul aplikasi. BP-4.6.1: Persetujan pemilik data untuk merubah data master. BP-4.6.2: Pemantauan perubahan desain data master. BP-4.7.1: Kontrol perlindungan data master yang penting. Kontrol Antarmuka IN-1: Implementasi desain dan strategi antarmuka. IN-1.1: Strategi antarmuka. IN-1.2.1: Desain antarmuka.

P02 v

P09

AI6

DS5 v

DS 11 v

DS 12

Ya

Tidak v

32 33 34 35 36 37 38 39

v v v

v v

v v v v v v v v v v

v 1 v v v v 1

40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55

v v v v v v v v v v v v v v v -

v v v v v v v v v v v v -

v v v v v v v 4 v v v v 1

v v v

v v v

1 2

v v

v v

92
Universitas Indonesia

93

N O 3 4 5 6 7 8 9 10 11 12 13

FISCAM IN-1.2.2: Kontrol tabel pemetaan. IN-2:Implementasi prosedur pemrosesan antarmuka. IN-2-1.1: Cara berjalan antarmuka. IN-2-2.1: Penanggung jawab proses antarmuka. IN-2-2.2: Keamanan file hasil antarmuka. IN-2-2.3: Status antarmuka. IN-2-3.1: Rekonsiliasi antara aplikasi sumber dan target. IN-2-4.1: Log antarmuka. IN-2-5.1: Penelusuran kesalahan dalam data antarmuka. IN-2-5.2: Mekanisme penolakan data. IN-2-5.3:Audit trail untuk identifikasi kesalahan. IN-2-6.1: File antarmuka terarsip/terhapus. Kontrol Sistem Manajemen Data Implementansi strategi dan desain sistem manajemen data. DA-1.1.1: Lokasi penyimpanan data. DA-1.1.2: Pemisahan data. DA-1.1.3: Database schema. DA-1.2.1: Logging aktivitas sistem dan akses data. DA-1.2.2: Kontrol aktivitas abnormal. DA-1.3.1: Kontrol data tidak valid. DA-1.3-2: Kontrol akses.

P02 v

P09

AI6

DS5

DS 11

DS 12

Ya v

Tidak

v v v v v v v v v v v

2 v

v v v v v v v v

1 2 3 4 5 6 7

v v

v v v v

v v v v v v v

v v v

Dari pernyataan dalam FISCAM di atas, beberapa item di antaranya terdiri dari beberapa butir pernyataan. Ada di antaranya yang telah dilaksanakan, selebihnya belum dijalankan. Karena itu penulis menambahkan kolom paling kiri berisi Ya dan Tidak, berapa banyak butir dari pernyataan tersebut yang sudah dijalankan dan belum dijalankan. Selanjutnya, kolom Ya dan Tidak ini masuk dalam kontribusi belum diterapkan, agar menjadi catatan untuk ditindaklanjuti dalam rekomendasi nantinya.

Langkah berikutnya, dari hasil pemetaan kontrol FISCAM terhadap kontrol COBIT 4.1 dilakukan rekapitulasi seperti pada tabel 5.6.

93
Universitas Indonesia

94

Tabel 5.6: Rekapitulasi Penerapan Kontrol Integritas Data N o 1 2 3 4 5 6 COBIT PO2 PO9 AI6 D5 D11 D12 Ya 25 (62,5%) 10 (30,3%) 19 (67,9%) 27 (47,4%) 34(60,7%) 1(50%) 116 Tidak 10 (25%) 20 (60,6%) 6 (21,4%) 23(40,4%) 15(26,8%) 1(50%) 75 Ya dan Tidak 5 (12,5%) 3 (9,1%) 3(10,7%) 7(12,2%) 7(12,5%) 0 25 Total Pernyataan 40 (18,5%) 33 (15,3%) 28(13%) 57(26,4%) 56(25,9%) 2 (0,9%) 216 Kontribusi Penerapan 11,57% 4.63% 8.80% 12.50% 15.74% 0.46% 53.7% Kontribusi Belum Diterapkan 6.94% 10.65% 4.17% 13.89% 10.19% 0.46% 46.3%

Seperti yang terlihat pada tabel rekapitulasi, total penerapan keenam control objective COBIT 4.1 baru 53,7%. Control objective COBIT yang masih menjadi pekerjaan rumah sebesar 46,3%. Sementara kontribusi tiap control objective COBIT 4.1 dalam mendukung manajemen integritas data seperti pada grafik 5.1. Dari grafik 5.1 terlihat bahwa DS5 (memastikan keamanan sistem) paling dominan dalam menjaga integritas data (26,39%) disusul dengan D11(mengelola data) sebesar 25,93% dan PO2 (menentukan desain arsitektur informasi) sebesar 18,52%.

Grafik 5.1: Kontribusi Tiap Control Objective COBIT 4.1 dalam Mendukung Manajemen Integritas Data

Selanjutnya pada diagram batang di bawah diketahui bahwa AI6 tentang manajemen perubahan telah sebagian besar diterapkan yaitu 67,9% dari seluruh proses yang ada dalam AI6. Sedangkan kontrol yang belum banyak diterapkan adalah manajemen risiko (PO9) sebesar 69,7 persen.

94
Universitas Indonesia

95

Grafik 5.2: Perbandingan yang Sudah Diterapkan dan Belum Diterapkan Dalam Tiap control objective COBIT 4.1

Dari kelemahan-kelemahan kontrol hasil pemetaan FISCAM terhadap kontrol COBIT 4.1 maka dilakukan rekomendasi untuk memperbaiki kelemahankelamahan tersebut, sehingga integritas data pada periode tahun berikutnya lebih terjamin. Rekomendasi tersebut dapat dilihat pada tabel di bawah ini.
Tabel 5.7: Rekomendasi untuk Memastikan Integritas Data N O PERNYATAAN PO2 Format Data. BP-1.5.1 Kontrol format field. BP-1.5.1(b) KONDISI EKSIS REKOMENDASI

Kontrol belum berfungsi dengan baik. Masih ada NIP yang salah. Kontrol belum berfungsi dengan baik. Ada field yang salah atau kosong tetap bisa masuk ke sistem, seperti tanggal lahir kosong, gaji pokok salah. Kontrol belum berfungsi dengan baik. NIP dan tanggal lahir tidak sinkron bisa masuk dalam sistem. Kontrol belum berfungsi dengan baik. Ada peserta yang usianya kurang dari 18 tahun dan ada gaji pokok nilainya nol.

Evaluasi format dan perbaikan kontrol.

Kontrol field yang diperlukan. BP-1.5.1(c)

Penambahan field seperti kode satker dan perbaikan kontrol.

Kombinasi yang valid dari nilai field data yang berkaitan.BP-1.5.1(e)

Perbaikan kontrol antara dua atau lebih field sehingga keduanya konsisten.

Cek kisaran. BP-1.5.1(f)

Evaluasi kontrol cek kisaran eksis dan dilakukan perbaikan kontrol.

95
Universitas Indonesia

96

N O 5

PERNYATAAN Akurasi matematis. BP-1.5.1(g)

KONDISI EKSIS Kontrol belum berfungsi dengan baik. Nilai THP tidak sesuai dengan hasil perhitungan. Kontrol belum berfungsi dengan baik. NIP masih terduplikasi.

REKOMENDASI Evaluasi rumus perhitungan dan baris program, selanjutnya perbaikan kontrol. Evaluasi kontrol proses duplikat dan dilakukan perbaikan kontrol.

Kontrol proses duplikat.BP-1.5.1(i) Konfigurasi parameter dan toleransi. BP-1.6.1 Peninjauan batasan dalam menginputkan data dan memvalidasi bahwa data akurat dan tepat secara reguler. BP-1.6.1(b) Strategi pelaporan. BP-3.1.1 Sensitivitas dan kerahasiaan data. BP-3.1.1 (b)

Bila diperlukan saja.

Divisi Pelayanan dan Divisi TI meninjau batasan dalam menginputkan data dan memvalidasi bahwa data akurat dan tepat secara regular.

Prosedur untuk memastikan konten dan ketersediaan output dan data konsisten dengan kebutuhan user. BP-3.2.1

10

Pengisian nilai null dan invalid. BP-4.1.2

11

Field data yang tetap. BP-4.2.1

TAS/ADP/PK/17 tentang Penyajian Data Peserta belum membahas tentang penggolongan data yang sensitif dan rahasia secara formal. Hal ini sebenarnya telah ada dalam kebijakan keamanan TI 2007 dan termasuk dalam tahapan manajemen risiko TI, hanya belum diimplementasikan dan belum dibuatkan prosedurnya Ada instruksi kerja: TAS/ADP/IK/02/01 tentang Meneliti Kebenaran Data Namun, belum ada prosedur kerja yang memuat aturan sensitivitas dan kerahasiaan data. Sementara tentang akses user ada di TAS/STI/PK/11 tentang Create User dan Hak Akses Aplikasi yang dimiliki Divisi TI. Nilai null diperbolehkan untuk field tertentu, terutama untuk peserta BUMN. Namun dalam realitanya, tanggal lahir bisa null. Belum ada kebijakan dan prosedur tersebut. Di SOP Divisi Pelayanan hanya memuat perubahan untuk penambahan atau pengurangan tabel wilayah (TAS/ADP/PK/18 tentang Pemeliharaan Tabel).

Divisi Pelayanan dan Divisi TI menambahkan poin dalam SOP tentang klasifikasi data organisasi (publik, sensitif, confidential dll).. Hasil klasifikasi data ini didokumentasikan dan ditinjau secara periodik.

Divisi Pelayanan dan Divisi TI menambahkan poin dalam SOP tentang klasifikasi data organisasi (publik, sensitif, confidential dll). Hasil klasifikasi data ini dokumentasikan dan ditinjau secara periodik.

Divisi Pelayanan dan Divisi TI meninjau non key field yang boleh bernilai null.

Divisi Pelayanan dan Divisi TI menambahkan ketentuan tentang field data yang tetap dalam prosedur kerja TAS/ADP/PK/18 tentang Pemeliharaan Tabel.

96
Universitas Indonesia

97

N O 12

PERNYATAAN Pembatasan untuk nonkey-field. BP-4.2.3

KONDISI EKSIS Di SOP belum ada penjelasan apabila perubahan hanya bisa untuk non key field.

REKOMENDASI Divisi Pelayanan dan Divisi TI menambahkan ketentuan tentang field data mana saja yang dapat diubah dalam prosedur kerja TAS/ADP/PK/18 tentang Pemeliharaan Tabel. Divisi TI meninjau data master secara periodik dan memastikan perubahan terotorisasi. Divisi TI mendokumentasikan strategi antarmuka dan mendefinisikan kebutuhan system balancing dan kebutuhan keamanan.

13

Peninjauan data master. BP-4.3.1

Ditinjau apabila ada permasalahan belum secara reguler.

14

Strategi antarmuka. IN1.1

Strategi antarmuka ada namun belum didokumentasikan. Kebutuhan system balancing dan kebutuhan keamanan belum didefinisikan.

Cara berjalan antarmuka. IN-2-1.1 15 Daftar yang lengkap tentang cara berjalan antarmuka, waktu proses antarmuka, proses, dan rekonsiliasi. IN-2-1.1(a) Kepatuhan waktu proses antarmuka. IN-2-1.1(b) Divisi TI melengkapi daftar tentang antarmuka, termasuk mendefisikan waktu proses.

Belum lengkap, waktu proses belum didefinisikan.

16

Tidak ada standar bergantung bandwith masing-masing kantor cabang.

Divisi TI menetapkan waktu proses antarmuka dengan bandwith yang standar di tiaptiap kantor cabang. Divisi TI menunjuk penanggung jawab proses antarmuka, sehingga jika terjadi permasalahan dapat ditanggulangi lebih cepat dan terdokumentasi dengan baik. Divisi TI menambahkan kontrol sehingga user dapat mengetahui jika antarmuka putus atau sistem down. Divisi TI segera melakukan dokumentasi tentang desain data sehingga jika ada perubahan atau ada permasalahan dapat ditelusuri. Termasuk, lokasi penyimpanan sehingga data benar-benar aman dari insiden bencana atau manusia.

17

Penanggung jawab proses antarmuka. IN-2-2.1

Belum ada personel yang khusus menangani antarmuka. Hal ini dikerjakan oleh administrator sistem yang merangkap sebagai programmer. User tidak dapat mengetahui status antarmuka.

18

Status antarmuka. IN-22.3

19

Lokasi penyimpanan data. DA-1.1.1

Belum ada dokumentasi fisik tentang desain data

97
Universitas Indonesia

98

N O 20

PERNYATAAN Kontrol data tidak valid. DA-1.3.11

KONDISI EKSIS Ada alert message, namun kontrol belum lengkap.

REKOMENDASI Divisi Pelayanan dan Divisi TI meninjau kontrol data eksis dan memperbaikinya agar isian data valid.

PO9 Pengukuran Risiko. AS-1.2.1 Pengukuran risiko secara periodik. AS-1.2.1 (a)

Poin risiko ada dalam kebijakan keamanan namun belum terealisasi.

Divisi Pelayanan, TI, dan Renbang menambahkan prosedur kerja tentang pengukuran risiko TI dalam Standard Operating Procedure (SOP). Selanjutnya, melakukan pengukuran risiko secara periodik sesuai SOP. Hasil kajian Divisi Renbang menjadi landasan proses pengukuran risiko TI yang sudah ditetapkan dalam prosedur kerja yang baru. Hasil kajian dikomunikasikan secara formal ke Divisi Pelayanan dan menjadi landasan penyusunan kebijakan dan prosedur manajemen risiko TI. Langkah selanjutnya setelah organisasi memiliki kebijakan dan prosedur manajemen risiko TI, yaitu melakukan ujicoba keamanan terutama aplikasi yang berisiko tinggi seperti ACB modul manajemen data peserta. Divisi TI menggunakan tools untuk menganalisis kelemahan keamanan aplikasi agar lebih akurat. Divisi TI memantau aksi korektif terhadap kelemahan keamanan aplikasi secara periodik. Divisi Pelayanan, Divisi TI, dan Renbang Bisnis melakukan kajian terhadap tugas-tugas yang berisiko mengalami konflik tugas seperti analis sistem dan admin sistem. Hal ini juga terkait dengan framework manajemen risiko TI.

Pemeliharaan dokumentasi pengukuran risiko. AS-1.2.1 (b)

Belum dilakukan secara formal. Baru dilakukan pengkajian oleh Divisi Renbang. Hasil pengkajian oleh Divisi Renbang belum dikomunikasikan secara formal ke Divisi Pelayanan.

Persetujuan risiko dari pemilik proses bisnis. AS-1.3.1

Frekuensi ujicoba terkait dengan risiko. AS-1.5.3

Mengingat fungsi aplikasi yang penting, belum dilakukan ujicoba yang proporsional, hanya berdasar kebutuhan.

Analisa kelemahan keamanan oleh aplikasi/tools. AS-1.6.3

Pemantauan aksi korektif. AS-1.6.4

Belum ada analisis kelemahan aplikasi dengan tools lain. Namun, aksi korektif yang tepat diimplementasikan. Belum ada pemantauan secara periodik, kecuali jika ada kasus atau laporan. Belum ada pemisahan tugas antara programmer, analis sistem, dan admin sistem.

Identifikasi aktivitas dan transaksi yang tidak cocok. AS-4.1.1

98
Universitas Indonesia

99

N O 8

PERNYATAAN Risiko konflik kepentingan user. AS4.1.2

KONDISI EKSIS Belum ada pengukuran risiko secara formal.

REKOMENDASI Divisi Pelayanan, TI, dan Renbang Bisnis melakukan kajian terhadap tugas-tugas yang berisiko mengalami konflik tugas seperti analis sistem dan admin sistem. Hal ini terkait dengan framework manajemen risiko TI.

Kebijakan dan prosedur pemeliharaan data master. BP-4.4.1 Prosedur backup saat bencana atau data korup.

10

Peninjauan akses untuk menghindari konflik kepentingan. AS-4.4.3

Organisasi memiliki prosedur kerja TAS/STI/PK/10 Contingency Plan tentang Apabila Server Mati Tidak Dapat Diakses. Namun, belum memuat prosedur backup saat bencana atau data korup. Peninjauan dilakukan jika ada peristiwa yang berdampak negatif pada aplikasi.

Divisi Pelayanan, TI, dan Renbang menambahkan poin tentang prosedur backup saat bencana atau data korup pada prosedur kerja tersebut.

11

Identifikasi konflik kepentingan. AS-4.5.1

Belum dilakukan pengkajian.

12

Mitigasi konflik oleh kontrol. AS-4.5.2

Belum ada dokumentasi.

13

Identifikasi aplikasi berfungsi kritis. AS-5.1.1

Pernah dilakukan kajian oleh Divisi Perencanaan dan Pengembangan Bisnis, namun belum lengkap hingga ke sumber daya TI, serta belum dikomunikasikan secara formal untuk ditindaklanjuti. Tahun lalu pernah dilakukan jajak pendapat ke 50 responden tentang aplikasi kritis, dan aplikasi modul peserta salah satunya. Responden paling banyak memilih 8 jam sebagai waktu

14

Identifikasi dampak dari gangguan. AS-5.1.2

Divisi Pelayanan dan TI meninjau secara periodik akses-akses untuk mengetahui jika ada fungsi yang berisiko mengalami konflik tugas yang tidak terotorisasi. Divisi Pelayanan, TI, dan Renbang melakukan pengkajian untuk mengidentifikasi konflik kepentingan yang dapat eksis, peranannya, dan user-user yang konflik. Divisi Pelayanan mengetatkan pengawasan terhadap user yang memiliki konflik tugas. Konflik ini bisa dimitigasi dengan kontrol melalui fungsi persetujuan dari atasan terlebih dahulu. Divisi TI meninjau dan melengkapi hasil kajian Divisi Renbang Bisnis. Selanjutnya, menjadi acuan dalam menyusun kerangka kerja manajemen risiko TI, termasuk di dalamnya kontrol atau tindakan-tindakan untuk memitigasi risiko. Divisi Ti dan Divisi Pelayanan meninjau hasil kajian Divisi Renbang. Selanjutnya, mengidentifikasi gangguan apa saja yang kemungkinan dialami aplikasi dan kerugian jika aplikasi

99
Universitas Indonesia

100

N O

PERNYATAAN

KONDISI EKSIS toleransi maksimal aplikasi down. Namun, kajian ini masih belum komplet dan belum dikomunikasikan secara formal untuk ditindaklanjuti. Belum ada petunjuk yang baku.

REKOMENDASI down lebih dari 8 jam.

15

Strategi pemulihan. AS5.1.3

Divisi Ti dan Pelayanan menentukan prioritas pemulihan apabila terjadi insiden pada aplikasi modul manajemen data peserta. Divisi TI, Pelayanan dan Renbang menyusun prosedur tentang rencana darurat aplikasi. Prosedur ini diujicobakan dan dditinjau secara periodik. Divisi TI, Pelayanan, dan Renbang segera melengkapi prosedur kerja tentang Contingency Plan yang telah ada dan melakukan ujicoba secara periodik. Contingency Plan ini menjadi salah satu inputan dalam menyusun DRP, BCP, dan business resumption plan seperti yang telah tercantum dalam Kebijakan Keamanan TI 2007.

16

Rencana darurat aplikasi. AS-5.3.1

Masih dalam kajian Divisi Renbang, belum komplet dan belum dijalankan.

17

Rencana darurat aplikasi dalam DRP, BCP, dan business resumption plan. AS-5.3.2

Belum lengkap. Saat ini organisasi memiliki TAS/STI/PK/10 Contingency Plan Apabila Server Mati (Divisi TI) dan TASP/LY/PK/19 Contingency Plan (Divisi Pelayanan). Contingency plan yang telah ada masih belum lengkap, hanya memuat langkahlangkah yang dilakukan apabila server mati dan apabila terjadi bencana di kantor cabang. Namun, belum memuat langkah-langkah apabila backup database dan sistem di kantor cabang utama atau di kantor pusat musnah. Organisasi hingga saat ini belum memiliki DRP, BCP, dan business resumption plan.

Lingkungan kontrol yang efektif untuk operasi darurat. AS-5.3.3 18 Audit dan monitoring kemampuan beroperasi. AS-5.3.3(c) Belum dilakukan secara berkala. Divisi TI mengundang pihak eksternal untuk melakukan audit dan monitoring kemampuan beroperasi aplikasi secara periodik, minimal tiga tahun sekali. Sehingga, celah keamanan atau kelemahan sistem dapat diidentifikasi sebelum tereksploitasi.

100
Universitas Indonesia

101

N O 19

PERNYATAAN Pengujian rencana darurat aplikasi. AS-5.4.1

KONDISI EKSIS Belum pernah dilakukan ujicoba rencana darurat.

REKOMENDASI Divisi TI, Pelayanan, dan Renbang melakukan ujicoba rencana darurat, mendokumentasikan hasil dari ujicoba tersebut dan melakukan tindakan perbaikan apabila diketemukan kelemahan dalam aplikasi Rencana ujicoba rencana darurat yang akan dilakukan Divisi TI, Pelayanan, dan Renbang meliputi: a. Pemulihan sistem dengan platform yang berbeda dari media backup. b. Ada koordinasi antar tim perbaikan. c. Konektivitas internal dan eksternal. d. Kinerja sistem dengan perangkat alternatif. e. Restorasi operasi normal. f. Prosedur pemberitahuan. Setelah melakukan ujicoba rencana darurat, hasilnya dibuat berita acara dan didokumentasikan. Apabila ada rencana perbaikan maka para penanggung jawabnya juga dicantumkan beserta tenggat waktu pelaksanaannya. Apabila diketemukan celah keamanan dan kelemahan aplikasi dalam ujicoba rencana darurat maka tindakan perbaikannya harus didokumentasikan dan memuat penanggung jawab, tugasnya masing-masing, dan tenggat waktu dari tiap tugas tersebut. Divisi Pelayanan dan Divisi TI mempertimbangkan konflik tugas yang berisiko sebelum memberikan akses untuk transaksi data master.

20

Ujicoba rencana darurat. AS-5.4.2

Belum pernah dilakukan ujicoba rencana darurat.

21

Dokumentasi hasil ujicoba rencana darurat. AS-5.4.3

Belum pernah dilakukan ujicoba rencana darurat.

22

Tindakan memperbaiki kekurangan selama ujicoba rencana darurat. AS-5.4.4

Belum pernah dilakukan.

23

Pertimbangan konflik tugas sebelum memberikan akses. BP4.4.3

Belum ada analisis tentang konflik tugas.

101
Universitas Indonesia

102

N O 1

PERNYATAAN AI6 Tanggung jawab tiap pihak dalam standar rencana ujicoba aplikasi. AS-3.5.1

KONDISI EKSIS

REKOMENDASI

Tidak melibatkan auditor. Quality control berasal dari user. Tugas library control digabung dengan programmer.

Divisi TI dan Pelayanan melakukan identifikasi pihakpihak yang dilibatkan dalam standar rencana ujicoba aplikasi, termasuk melibatkan auditor. Hal ini sebaiknya disusun dalam prosedur rencana ujicoba aplikasi. Divisai TI perlu melakukan pemisahan library, yaitu untuk pengembangan program dan pemeliharaan, uji coba serta program produksi. Hal ini untuk memudahkan pengontrolan dan penelusuran perubahan pada library yang berkaitan dengan aplikasi.

AS-3.6.1: Pemisahan library.

Untuk pengembangan baris program, library lama otomatis ditimpa dengan yang baru. Belum ada pemisahan.

Pergerakan program dan data. AS-3.7.1 Kelompok user independen dan programmer mengawasi pergerakan program dan data antara library. AS3.7.1 (a)

Hanya apabila terjadi masalah.

Divisi TI menunjuk seorang programmer dan personel yang tidak memiliki otorisasi untuk mengawasi pergerakan program dan data antara library agar tidak terjadi perubahan antara tiga hal tersebut yang tidak terotorisasi. Lebih baik lagi apabila programmer tersebut memiliki dokumentasi yang selalu update tentang perubahan program, data, dan library, terutama untuk produksi dan .pengembangan.

AS-3.9.1: Perubahan kode program. Perubahan kode program aplikasi dan tabel dibatasi dan ditolak dalam lingkungan produksi. AS3.9.1(a)

Untuk aplikasi tidak dipisahkan antara lingkungan produksi dan pengembangan. Baru di database saja, terjadi pemisahan.

Divisi TI melakukan pemisahan antara kode program di lingkungan produksi dan pengembangan dan melakukan pengawasan terhadap pergerakan dari pengembangan ke produksi agar tidak terjadi perubahan yang tidak terotorisasi.

102
Universitas Indonesia

103

N O 5

PERNYATAAN Prosedur pemantauan perubahan. AS-3.11.1

KONDISI EKSIS Penanggung jawab eksis dapat mengubah otorisasi.

REKOMENDASI Divisi TI menunjuk programmer dan personel yang tidak dapat mengubah otorisasi untuk memantau perubahan program dan tabel. Selanjutnya, Divisi TI menyediakan laporan detail/log to run, kriteria valuasi spesifik, dan frekuensi penilaian (assessment) yang didokumentasikan dan dievaluasi secara periodik.

Perubahan dan validasi override. BP-1.5.2 Prosedur untuk memonitor override dan memelihara override log. BP-1.5.2 (b)

Tidak ada log khusus override, hanya berdasarkan log login dan log transaksi.

Divisi TI membuat override log atau membuat prosedur untuk memonitor override dengan kertas kerja yang ditandatangani atasan. Divisi Pelayanan bersamasama Divisi TI memantau perubahan desain data master dan menyetujui serta memonitor perubahan secara periodik.

Pemantauan perubahan desain data master. BP4.6.2

Sesuai kebutuhan.

DS5 Manajemen keamanan aplikasi. AS-1.1.A Level risiko aplikasi. AS1.1.A (b)

Deskripsi semua kontrol yang telah ada atau sedang direncanakan termasuk bagaimana kontrol diimplementasikan atau akan diimplementasikan. AS-1.1.A (f)

Divisi Perencanaan dan Pengembangan Bisnis telah melakukan pengkajian tentang business impact analysis. Salah satu poin menyebutkan aplikasi manajemen data merupakan bisnis inti (core business) perusahaan yang tidak boleh mati lebih dari 8 jam. (level risiko tinggi). Namun deskripsi ini belum diinputkan ke dalam rencana keamanan aplikasi ACB modul manajemen data peserta karena pengkajian ini dilakukan pada tahun 2009. Kontrol aplikasi belum komplet terdokumentasi.

Hasil kajian Divisi Renbang Bisnis menjadi input pembuatan kebijakan manajemen risiko TI dan diintegrasikan dalam rencana keamanan aplikasi pada khususnya, dan rencana keamanan organisasi pada umumnya.

Divisi TI Bagian Aplikasi Bisnis Inti melengkapi dokumentasi tentang kontrol aplikasi ACB modul manajemen data peserta.

103
Universitas Indonesia

104

N O 3

PERNYATAAN Identifikasi pemisahan tugas (segregation of duties) yang berisiko tinggi. AS-1.1.A (k)

KONDISI EKSIS Poin ini tidak ada dalam kebijakan keamanan TI organisasi. Fungsi tugas di Divisi TI ditentukan oleh kebijakan SDM bukan berdasarkan analisis kebutuhan untuk manajemen data.

REKOMENDASI Divisi TI dan Renbang melakukan kajian tentang deskripsi tugas tiap personel yang dimungkinkan terjadi konflik. Fungsi yang konflik tersebut selanjutnya dilakukan oleh dua atau lebih personel.

Kebijakan dan prosedur keamanan aplikasi. AS1.3.2 4 Memperhatikan kebutuhan keamanan proses bisnis. AS1.3.2(b) Proses pengkomunikasian kebijakan keamanan.AS1.4.1 Kebijakan keamanan tidak menyebutkan tentang kebutuhan keamanan proses bisnis. Belum secara terformalisasi dikomunikasikan meski organisasi telah memiliki kebijakan keamanan TI sejak tahun 2007. Divisi Pelayanan, TI, dan Renbang menambahkan poin tentang kebutuhan keamanan proses bisnis dalam SOP. Kebijakan keamanan TI yang ada dikaji kembali dan memasukkan unsur kewajiban user untuk mendukung keamanan TI. Selanjutnya poin keamanan aplikasi ini ditambahkan dalam SOP. Setelah kebijakan TI lengkap memuat kewajiban user, serta dibuat prosedur kerjanya, maka langkah selanjutnya yaitu mensosialisasikan kebijakan dan prosedur tersebut. Bisa melalui marquee pada situs internal organisasi seperti Document Management System (DMS), atau di halaman depan aplikasi ACB. Setelah prosedur keamanan aplikasi disusun, maka dilakukan ujicoba kontrol keamanan aplikasi secara periodik sesuai prosedur. Setelah prosedur keamanan aplikasi disusun, maka dilakukan ujicoba kontrol keamanan aplikasi secara periodik sesuai prosedur. Mengingat fungsi aplikasi ACB modul manajemen data sangat penting, maka frekuensi ujicoba dilakukan 1-2 kali dalam setahun.

Sosialisasi keamanan TI. AS-1.4.2

Pemilik aplikasi dan user mendapatkan training untuk mengoperasikan aplikasi. Namun, tentang keamanan tidak diberikan/disosialisasikan secara formal, meskipun organisasi memiliki kebijakan keamanan yang memuat tentang kesadaran user sebagai bagian dari kebijakan keamanan TI. Pengujian kontrol keamanan tidak dilakukan tiap tahun, hanya sesuai kebutuhan.

Ujicoba kontrol keamanan aplikasi secara periodik. AS-1.5.2

Frekuensi ujicoba terkait dengan risiko. AS-1.5.3

Mengingat fungsi aplikasi yang penting, belum dilakukan ujicoba yang proporsional, hanya berdasar kebutuhan.

104
Universitas Indonesia

105

N O 9

PERNYATAAN Kepatuhan terhadap regulasi menjadi bagian dari program keamanan organisasi. AS-1.5.4

KONDISI EKSIS Selain kebijakan internal, tidak ada perundangan yang diikuti untuk program keamanan organisasi. Barubaru ini saja ada audit BPK yang menyinggung tentang integritas data. Namun secara formal belum ada di program keamanan organisasi . Belum ada best practices yang diikuti dalam kebijakan keamanan. Organisasi juga belum memiliki framework manajemen risiko TI. Belum ada analisa kekurangan dengan tools lain. Namun, aksi korektif yang tepat diimplementasikan. Belum ada pemantauan secara periodik, kecuali jika ada kasus atau laporan.

REKOMENDASI Divisi Ti dan Renbang melakukan pengkajian best practices yang sesuai dengan kebutuhan organisasi. Misal COBIT atau ISO 27001 tentang Information Security Management System (ISMS).

10

Analisa kelemahan keamanan oleh aplikasi/tools. AS-1.6.3

11

Pemantauan aksi korektif. AS-1.6.4

Divisi TI menggunakan tools untuk menganalisis kelemahanataupun celah keamanan aplikasi agar lebih akurat. Divisi TI memantau aksi korektif terhadap celah keamanan aplikasi secara periodik dan menambahkan kontrol apabila terbukti ada kelemahan keamanan.

12

13

Kebijakan dan prosedur keamanan dengan aktivitas pihak ketiga. AS-1.7.1 Proses memantau kepantauan provider pihak ketiga. AS-1.7.2

Tidak ada proses formal untuk memantau kepatuhan provider pihak ketiga.

14

Batasan aplikasi dalam rencana keamanan. AS2.1.1

15

Identifikasi dan autentikasi unik bagi setiap user. AS-2.2.1

Deskripsi komplet tentang aplikasi manajemen data peserta belum ada, sehingga identifikasi batasan aplikasi sesuai dengan pemahaman personel keamanan ketika menyusun rencana keamanan. Tentang keamanan, sejauh ini belum ada serangan yang mengarah langsung ke aplikasi, namun evaluasi hanya berdasarkan kebutuhan. Untuk level user, setiap user memiliki akun masingmasing. Namun, untuk administrator sistem dan administrator di bagian data Divisi Pelayanan, menggunakan akun bersama.

Divisi TI memantau kepatuhan provider pihak ketiga terhadap kebijakan keamanan TI organisasi dan memberikan sanksi apabila terbukti melanggar. Divisi TI menambahkan deskripsi detail tentang aplikasi yang masuk dalam lampiran atau bab tersendiri dalam kebijakan keamanan TI organisasi.

Divisi Pelayanan memberikan akun ke setiap administrator di bagian data. Agar setiap terjadi perubahan ataupun akses ke aktivitas sensitif dapat dicatat dan diketahui identitas si administrator.

105
Universitas Indonesia

106

N O 16

PERNYATAAN Kegagalan login. AS2.3.2

KONDISI EKSIS Kontrol belum komplet. User bisa memasukkan password berulang kali. Namun, setelah dua kali kesalahan login, user masih tetap bisa masuk. Namun, tidak dapat masuk ke proses aplikasi, hanya dapat masuk ke tampilan menu utama. Perlu bantuan administrator untuk mereset akun setelah periode waktu yang spesifik. User tetap bisa masuk ke sesi tersebut meskipun aplikasi tidak aktif dalam beberapa waktu.

REKOMENDASI Divisi TI meninjau segala kelemahan keamanan atau kontrol yang belum diterapkan. Terutama untuk login. Sebaiknya untuk kegagalan login hanya bisa dilakukan tiga kali, setelah itu aplikasi tidak bisa diakses, dengan memberikan alert pilihan ke user apakah user mau mereset password atau tidak. Jika Ya maka sistem mengirimkan password secara acak melalui email user. Kegagalan login ini ditinjau secara periodik terutama untuk login dengan hak akses ke aktivitas sensitif. Agar risiko terminimalisasi, Divisi TI menambahkan kontrol, agar aplikasi memaksa user untuk mengupdate akun(password) setiap enam bulan sekali. Divisi TI juga menambahkan kontrol dalam aplikasi agar aplikasi secara otomatif melog off akun user apabila user mendiamkan aplikasi atau sesi user tidak aktif Divisi Pelayanan memberikan akun ke setiap administrator di bagian data. Agar setiap terjadi perubahan ataupun akses ke aktivitas sensitif dapat dicatat dan diketahui identitas si administrator. Divisi TI memantau secara periodik multiple log on, dimana 1 user memiliki beberapa akun, atau 1 akun digunakan oleh beberapa user. Divisi Pelayanan dan TI secara periodik meninjau akses untuk memastikan sistem berjalan baik.

17

Satu akun untuk satu user. AS-2.3.3

Untuk bagian data, di Divisi Pelayanan menggunakan akun bersama.

18

Pemantauan multiple log on. AS-2.3.4

Multiple log on yang ada hanya dikontrol dan dipantau sesuai kebutuhan.

19

Peninjauan akses secara periodik. AS-2.4.2

Sesuai kebutuhan untuk penelusuran kesalahan penginputan data.

20

Implementasi rencana keamanan dan proses. AS-2.5.1 Kontrol akses user. AS2.5.1(b)

Tidak dilakukan secara periodik.

Divisi Pelayanan dan TI secara periodik meninjau akses untuk memastikan sistem berjalan baik.

106
Universitas Indonesia

107

N O 21

PERNYATAAN Penggunaaan digital signature. AS-2.5.1(c)

KONDISI EKSIS Belum dilakukan.

REKOMENDASI Divisi TI menerapkan penggunaan digital signature sesuai dengan IT plan organisasi untuk melindungi keamanan dan integritas data. Divisi TI dan Pelayanan menambahkan larangan akses langsung bagi publik ke data produksi dalam prosedur kerja. Federal Information Security Management Act (FISMA) dan National Institute of Standards and Technology (NIST) tidak diikuti oleh organisasi. Namun, organisasi bisa mengkaji best practices yang mengglobal seperti COBIT, ISO 27001, dan IT-IL. Administrator keamanan secara periodik meninjau otoritas akses user ke aktivitas sensitif untuk memastikan sistem berjalan baik. Selain oleh administrator keamaanan, peninjauan otoritas akses user ke aktivitas sensistif untuk memastikan sistem berjalan baik, dilakukan oleh Divisi Pelayanan. Sebab, Divisi Pelayanan sebagai pemilik aplikasi dan proses yang berhak memberikan hak akses ke setiap user.

22

Larangan akses langsung bagi publik ke data produksi. AS-2.5.1(cd)

Belum ada larangan formal untuk akses langsung ke data produksi.

23

Kepatuhan dengan FISMA dan NIST. AS2.5.1 (e)

Organisasi tidak mengikuti FISMA dan NIST.

24

Peninjauan otoritas akses user ke aktivitas sensitif oleh administrator keamanan. AS-2.6.3 Peninjauan otoritas akses user ke aktivitas sensitif oleh administrator pemilik. AS-2.6.4

Ditinjau setelah ada kejadian/transaksi yang abnormal.

25

Ditinjau setelah ada kejadian/transaksi yang abnormal.

26

27

Sumber daya aplikasi sensitif telah cukup aman. AS-2.7.1 Data aplikasi yang sensitif terenkripsi. AS2.7.1(c)

Belum terenkripsi.

28

Kebijakan dan prosedur untuk audit keamanan. AS-2.8.1

Belum ada prosedur tentang audit keamanan meski di dalam Kebijakan Keamanan TI 2007 tercantum.

Divisi TI menerapkan sistem enkripsi dalam data aplikasi untuk keamanan dan integritas data. Hal ini juga sesuai dengan Kebijakan Keamanan TI 2007. Divisi TI menerapkan audit keamanan secara periodik dan menyusun prosedur sesuai dengan Kebijakan Keamanan TI 2007.

107
Universitas Indonesia

108

N O 29

PERNYATAAN Deteksi pelanggaran keamanan. AS-2.9.1

KONDISI EKSIS Belum ada.

REKOMENDASI Detektor pelanggaran keamanan di firewall sudah ada. Namun, untuk deteksi pelanggaran keamanan aplikasi Divisi TI mengagendakan segala pelanggaran dan exception serta mendokumentasikan dan meninjaunya secara periodik. Divisi TI, Pelayanan, dan Renbang mengkaji dan menyusun prosedur untuk menangani exception. Divisi TI dan Pelayanan menyusun matriks pemisahan tugas sehingga dapat diketahui personel yang mengalami konflik tugas. Hal ini untuk mengidentifikasi aktivitas dan transaksi yang tidak cocok berkaitan dengan konflik tugas tersebut. Administrator keamanan meninjau secara periodik terhadap akses user aplikasi yang memiliki konflik tugas dan mencocokkannya dengan akses user sebelumnya. Apabila ada aktivitas yang mencurigakan berkaitan dengan akses tersebut maka didiskusikan dengan Divisi Pelayanan. Divisi Pelayanan secara periodik meninjau akses untuk mengidentifikasi konflik kepentingan yang tidak terotorisasi dan mengetahui apakah konflik tugas yang ada masih sesuai/sama dengan sebelumnya. Divisi Pelayanan mengidentifikasi konflik tugas yang masih ada dan melakukan tindakan bersama-sama dengan Divisi TI dan Renbang agar konflik tersebut tidak ada lagi pada masa akan datang.

30

Laporan pelanggaran. AS-2.10.1

Belum ada logging untuk pelanggaran dan exception. Peninjauan laporan exception dilakukan setelah ada pelanggaran yang merugikan. Belum ada prosedur untuk menangani exception.

31

Identifikasi aktivitas dan transaksi yang tidak cocok. AS-4.1.1

Belum ada pemisahan tugas antara programmer, analis sistem, dan admin sistem.

32

Peninjauan oleh admin keamanan terhadap otorisasi akses user aplikasi. AS-4.4.2

Jika ada peristiwa yang berdampak negatif pada aplikasi.

33

Peninjauan akses untuk menghindari konflik kepentingan. AS-4.4.3

Jika ada peristiwa yang berdampak negatif pada aplikasi.

34

Identifikasi konflik kepentingan. AS-4.5.1

Belum dilakukan pengkajian.

108
Universitas Indonesia

109

N O 35

PERNYATAAN Mitigasi konflik oleh kontrol. AS-4.5.2

KONDISI EKSIS Belum ada dokumentasi.

REKOMENDASI Apabila konflik itu sulit atau belum dapat dihindari maka perlu adanya penambahan kontrol secara manual ataupun secara elektronik, misal persetujuan atasan, setiap user yang memiliki konflik tugas tersebut melakukan aktivitas ke transaksi yang sensitif atau melakukan perubahan. Hal ini kemudian didokumentasikan dalam kontrol pengawasan yang saat ini belum terdokumentasi. Divisi TI dan Pelayanan mendokumentasikan hasil pemantauan terhadap akses user, ujicoba aplikasi, ujicoba rencana darurat dan perubahan terhadap aplikasi.

36

Bukti pemantauan yang efektif. AS-4.5.3

Belum ada dokumentasi.

37

Perubahan dan validasi override. BP-1.5.2 Prosedur untuk memantau override dan memelihara override log. BP-1.5.2(b) Perlindungan data selama pemrosesan. BP-2.8.1

Tidak ada log khusus override, hanya berdasarkan log login dan log transaksi.

38

Belum ada proses enkripsi.

39

Peninjauan log proses. BP-2.9.3

Ditinjau jika ada permasalahan.

Divisi TI membuat override log atau membuat prosedur untuk memonitor override dengan kertas kerja yang ditandatangi atasan. Divisi TI menerapkan sistem enkripsi dalam data aplikasi untuk keamanan dan integritas data. Hal ini juga sesuai dengan Kebijakan Keamanan TI 2007. Administrator keamanan dan Divisi Pelayanan meninjau log untuk mengetahui apabila terjadi exception yang tidak terotorisasi. Administrator keamanan dan Divisi Pelayanan memantau override pada transaksi, termasuk memelihara override log

40

Pemantauan override log. BP-2.9.4

Tidak ada override log.

Strategi pelaporan. BP3.1.1

109
Universitas Indonesia

110

N O 41

PERNYATAAN Kesensitifan dan kerahasiaan data. BP3.1.1 (b)

KONDISI EKSIS Sesuai dengan TAS/ADP/PK/17 tentang Penyajian Data Peserta yaitu memuat tentang user yang berhak melakukan rekap, sedangkan bagi unit lain yang memerlukan harus mengirim surat dan teragendakan dalam Agenda Penyajian Data Peserta (TAS/ADP/FK/17/01) . Namun, prosedur kerja ini belum membahas tentang penggolongan data yang sensitif dan rahasia secara formal.

REKOMENDASI Divisi Pelayanan dan Divisi TI menambahkan poin dalam SOP tentang klasifikasi data organisasi (publik, sensitif, confidential dll).. Hasil klasifikasi data ini didokumentasikan dan ditinjau secara periodik.

42

Prosedur untuk memastikan konten dan ketersediaan output dan data konsisten dengan kebutuhan user. BP-3.2.1

Divisi Pelayanan dan Divisi TI menambahkan poin dalam SOP tentang klasifikasi data organisasi (publik, sensitif, confidential dll).. Hasil klasifikasi data ini dokumentasikan dan ditinjau secara periodik. Divisi Pelayanan mengetatkan pemantauan agar target 98% keakuratan data tercapai di semua kantor cabang. Hal ini juga menjadi unsur kepatuhan kepada pemerintah apabila tidak ada temuan dari BPK tentang adanya data yang tidak valid. Divisi Pelayanan dan Divisi TI mempertimbangkan konflik tugas yang berisiko sebelum memberikan akses untuk transaksi data master.

43

Laporan output untuk kepatuhan dengan hukum. BP-3.4.1

44

Pertimbangan konflik tugas sebelum memberikan akses. BP4.4.3

45

Kontrol perlindungan data master yang penting. BP-4.7.1

Ada instruksi kerja: TAS/ADP/IK/02/01 tentang Meneliti Kebenaran Data Namun, belum ada prosedur kerja yang memuat aturan sensitivitas dan kerahasiaan data. Sementara tentang akses user ada di TAS/STI/PK/11 tentang Create User dan Hak Akses Aplikasi yang dimiliki Divisi TI. Belum ada enkripsi.

46

Kontrol aktivitas abnormal. DA-1.2.2

Peringatan hanya apabila user belum secara komplet mengisi field-field wajib.

Divisi TI mengimplementasikan kontrol yang cukup untuk melindungi data master yang penting. Misalnya dengan melakukan enkripsi. Divisi TI menambahkan kontrol pada aplikasi sehingga dapat terdeteksi jika ada aktivitas yang abnormal.

110
Universitas Indonesia

111

N O 1

PERNYATAAN DS11 Prosedur untuk menjamin semua input aplikasi terotorisasi. BP-1-2.1

KONDISI EKSIS

REKOMENDASI

Setahun dua kali ada rekonsiliasi antara Taspen dengan penyedia data. Selain itu, juga dilakukan control total untuk data yang diinputkan. Namun, realitanya rekonsiliasi ini belum rutin dilakukan dan masih terdapat selisih data peserta dari rekap hasil proses daftar gaji antara database organisasi dan yang diperoleh dari Pemda-KPPN.

Rekonsiliasi antara Taspen dan Pemda-KPPN dilaksanakan secara rutin, enam bulan sekali. Prosedur seperti batch total dan control total diterapkan dalam penginputan data, agar jumlah data sumber sama dengan data yang masuk dalam sistem.

Format Data. BP-1.5.1 Kontrol format field. BP-1.5.1(b)

Kontrol belum berfungsi dengan baik. Masih ada NIP yang salah. Kontrol belum berfungsi dengan baik. Ada field yang salah atau kosong tetap bisa masuk ke sistem, seperti tanggal lahir kosong, gaji pokok salah. Kontrol belum berfungsi dengan baik. NIP dan tanggal lahir tidak sinkron bisa masuk dalam sistem. Kontrol belum berfungsi dengan baik. Ada peserta yang usianya kurang dari 18 tahun dan ada gaji pokok nilainya nol. Kontrol belum berfungsi dengan baik. Nilai THP tidak sesuai dengan hasil perhitungan. Kontrol belum berfungsi dengan baik. NIP masih terduplikasi.

Evaluasi format dan perbaikan kontrol.

Kontrol field yang diperlukan. BP-1.5. (c)

Penambahan field seperti kode satker dan perbaikan kontrol.

Kombinasi yang valid dari nilai field data yang berkaitan. BP-1.5.1(e)

Perbaikan kontrol antara dua atau lebih field sehingga keduanya konsisten.

Cek kisaran. BP-1.5.1(f)

Evaluasi kontrol cek kisaran eksis dan dilakukan perbaikan kontrol.

Akurasi matematis. BP1.5.1(g)

Evaluasi rumus perhitungan dan baris program, selanjutnya perbaikan kontrol.

Kontrol proses duplikat.BP-1.5.1(i)

Evaluasi kontrol proses duplikat dan dilakukan perbaikan kontrol.

Sistem memproses transaksi dengan baik. BP-2.2.1 Identifikasi transaksi yang tidak komplet. BP2.2.1(b)

Kontrol belum komplet, sehingga jika ada transaksi yang tidak komplet tetap bisa masuk ke sistem.

Evaluasi kontrol eksis dan perbaikan kontrol.

111
Universitas Indonesia

112

N O 9

PERNYATAAN Rekonsiliasi secara periodik. BP-2.6.1

KONDISI EKSIS Tiap enam bulan ada rekonsiliasi antara Taspen dan penyedia data (KPPN, Pemda, BKN dan sebagainya), juga ada konfirmasi untuk data-data yang invalid. Namun belum rutin dilaksanakan. Belum ada proses enkripsi.

REKOMENDASI Rekonsiliasi antara Taspen dan Pemda-KPPN dilaksanakan secara rutin, enam bulan sekali.

10

Perlindungan data selama pemrosesan. BP-2.8.1

Divisi TI menerapkan sistem enkripsi dalam data aplikasi untuk keamanan dan integritas data. Hal ini juga sesuai dengan Kebijakan Keamanan TI 2007.

11

12

Prosedur pemantauan untuk mengetahui penambahan/modifikasi data. BP-2.9.2 Peninjauan log audit sistem untuk exception. BP-2.9.2(b)

Ditinjau sesuai kebutuhan.

13

Peninjauan log proses. BP-2.9.3

Ditinjau jika ada permasalahan.

14

Pemantauan override log. BP-2.9.4

Tidak ada override log.

Divisi Ti dan pelayanan meninjau secara periodik log untuk mengetahui jika ada exception tanpa sepengetahuan. Administrator keamanan dan Divisi Pelayanan meninjau log untuk mengetahui apabila terjadi exception yang tidak terotorisasi. Administrator keamanan dan Divisi Pelayanan memantau override pada transaksi, termasuk memelihara override log.

15

Strategi pelaporan. BP3.1.1 Kesensitifan dan kerahasiaan data. BP3.1.1(b)

Sesuai dengan TAS/ADP/PK/17 tentang Penyajian Data Peserta yaitu memuat tentang user yang berhak melakukan rekap, sedangkan bagi unit lain yang memerlukan harus mengirim surat dan teragendakan dalam Agenda Penyajian Data Peserta (TAS/ADP/FK/17/01) . Namun, prosedur kerja ini belum membahas tentang penggolongan data yang sensitif dan rahasia secara formal.

Divisi Pelayanan dan Divisi TI menambahkan poin dalam SOP tentang klasifikasi data organisasi (publik, sensitif, confidential dll).. Hasil klasifikasi data ini didokumentasikan dan ditinjau secara periodik.

112
Universitas Indonesia

113

N O 16

PERNYATAAN Prosedur untuk memastikan konten dan ketersediaan output dan data konsisten dengan kebutuhan user. BP-3.2.1

KONDISI EKSIS

REKOMENDASI Divisi Pelayanan dan Divisi TI menambahkan poin dalam SOP tentang klasifikasi data organisasi (publik, sensitif, confidential dll).. Hasil klasifikasi data ini dokumentasikan dan ditinjau secara periodik.

17

Prosedur peninjauan hasil proses. BP-3.3.2 Monitor override, termasuk pemeliharaan override log. BP-3.3.2(b)

Belum ada pemeliharaan override log

Divisi TI, Pelayanan, dan Renbang menyusun prosedur untuk melakukan pemantauan override dan memelihara override log. Divisi Pelayanan mengetatkan pemantauan agar target 98% keakuratan data tercapai di semua kantor cabang. Hal ini juga menjadi unsur kepatuhan kepada pemerintah apabila tidak ada temuan dari BPK tentang adanya data yang tidak valid. Divisi Pelayanan dan Divisi TI meninjau non key field yang boleh bernilai null.

18

Laporan output untuk kepatuhan dengan hukum. BP-3.4.1

Taspen menargetkan 98% keakuratan data tercapai, namun belum semua kantor cabang memenuhi. Selain itu, masih ada data yang tidak valid dan masih menjadi catatan oleh BPK.

19

Pengisian nilai null dan invalid. BP-4.1.2

Nilai null diperbolehkan untuk field tertentu, terutama untuk peserta BUMN. Namun dalam realitanya, tanggal lahir bisa null. Belum ada kebijakan dan prosedur tersebut. Di SOP Divisi Pelayanan hanya memuat perubahan untuk penambahan atau pengurangan tabel wilayah (TAS/ADP/PK/18 tentang Pemeliharaan Tabel). Di SOP belum ada penjelasan apabila perubahan hanya bisa untuk non key field.

20

Field data yang tetap. BP-4.2.1

Divisi Pelayanan dan Divisi TI menambahkan ketentuan tentang field data yang tetap dalam prosedur kerja TAS/ADP/PK/18 tentang Pemeliharaan Tabel.

21

Pembatasan untuk nonkey-field. BP-4.2.3

Divisi Pelayanan dan Divisi TI menambahkan ketentuan tentang field data mana saja yang dapat diubah dalam prosedur kerja TAS/ADP/PK/18 tentang Pemeliharaan Tabel. Divisi TI meninjau data master secara periodik dan memastikan perubahan terotorisasi.

22

Peninjauan data master. BP-4.3.1

Ditinjau apabila ada permasalahan belum secara reguler.

113
Universitas Indonesia

114

N O 23

PERNYATAAN Kebijakan dan prosedur pemeliharaan data master. BP-4.4.1 Prosedur backup saat bencana atau data korup. BP-4.4.1(e)

KONDISI EKSIS

REKOMENDASI

24

Belum ada prosedur backup data bencana.

25

Kontrol perlindungan data master yang penting. BP-4.7.1

Belum ada enkripsi.

26

Lokasi penyimpanan data. DA-1.1.1

Belum ada dokumentasi fisik tentang desain data.

27

Kontrol data tidak valid. DA-1.3.1

Ada alert message, namun kontrol belum lengkap.

Divisi Pelayanan, TI, dan Renbang menambahkan poin tentang prosedur backup saat bencana atau data korup pada prosedur kerja tersebut. Divisi Ti mengimplementasikan kontrol yang cukup untuk melindungi data master yang penting. Misalnya dengan melakukan enkripsi. Divisi Ti segera melakukan dokumentasi desain data secara detail, termasuk strategi data. Divisi Pelayanan dan Divisi TI meninjau kontrol data eksis dan memperbaikinya agar isian data valid.

DS12 Lokasi penyimpanan data. DA-1.1.1

Belum ada dokumentasi.

Divisi TI mendokumentasikan lokasi-lokasi data center di kantor pusat maupun kantor cabang utama, termasuk penyimpanan semua backup

Dari daftar rekomendasi di atas maka dilakukan pemetaaan dengan temuan audit BPK-RI pada bulan Desember 2009. Hasil pemetaan ini adalah rekomendasi prioritas untuk membantu menemukan solusi penyelesaian temuan audit tersebut. Rekomendasi tiap permasalahan dapat dilihat pada tabel di bawah ini.
Tabel 5.8: Rekomendasi untuk Temuan Audit BPK-RI pada KCU/KC Bulan Desember 2009 No I 1 Permasalahan Data Peserta Program Duplikasi NIP. Kontrol proses duplikat.BP-1.5.1(i) Peninjauan batasan dalam menginputkan data dan memvalidasi bahwa data akurat dan tepat secara reguler. BP-1.6.1(b) Field data yang tetap. BP-4.2.1 PO2-6 DS11-7 PO2-7 Proses Rekomendasi

PO2-11

114
Universitas Indonesia

115

No

Permasalahan

Proses Peninjauan data master. BP-4.3.1 Kontrol data tidak valid. DA-1.3.1 Audit dan monitoring kemampuan beroperasi. AS-5.3.3(c) Kelompok user independen dan programmer mengawasi pergerakan program dan data antara library. AS-3.7.1 (a) Perubahan kode program aplikasi dan tabel dibatasi dan ditolak dalam lingkungan produksi. AS-3.9.1(a) Prosedur pemantauan perubahan. AS-3.11.1 Pemantauan perubahan desain data master. BP-4.6.2 Deskripsi semua kontrol yang telah ada atau sedang direncanakan termasuk bagaimana kontrol diimplementasikan atau akan diimplementasikan. AS-1.1.A (f) Kontrol format field. BP-1.5.1(b) Peninjauan batasan dalam menginputkan data dan memvalidasi bahwa data akurat dan tepat secara reguler. BP-1.6.1(b) Kontrol data tidak valid. DA-1.3.1 Audit dan monitoring kemampuan beroperasi. AS-5.3.3(c) Kelompok user independen dan programmer mengawasi pergerakan program dan data antara library. AS-3.7.1 (a) Perubahan kode program aplikasi dan tabel dibatasi dan ditolak dalam lingkungan produksi. AS-3.9.1(a) Prosedur pemantauan perubahan. AS-3.11.1 Pemantauan perubahan desain data master. BP-4.6.2 Deskripsi semua kontrol yang telah ada atau sedang direncanakan termasuk bagaimana kontrol diimplementasikan atau akan diimplementasikan. AS-1.1.A (f) Rekonsiliasi secara periodik. BP-2.6.1

Rekomendasi PO2-13 PO2-20 PO9-18 AI6-3

AI6-4

AI6-5 AI6-7 DS5-2

NIP salah.

PO2-1 DS11-2 PO2-7

PO2-20 PO9-3 AI6-3

AI6-4

AI6-5 AI6-7 DS5-2

DS11-9

Data sudah mengajukan klaim pensiun/PMK dan status masih aktif.

Kombinasi yang valid dari nilai field data yang berkaitan.BP-1.5.1(e) Peninjauan batasan dalam menginputkan data dan memvalidasi bahwa data akurat dan tepat secara reguler. BP-1.6.1(b) Peninjauan data master. BP-4.3.1 Lokasi penyimpanan data. DA-1.1.1

PO2-3 DS11-4 PO2-7

Kontrol data tidak valid. DA-1.3.11 Identifikasi aktivitas dan transaksi yang tidak cocok. AS-4.1.1 Risiko konflik kepentingan user. AS-4.1.2

PO2-13 PO2-19 DS11-26 DS12-1 PO2-20 PO9-7 PO9-8

115
Universitas Indonesia

116

No

Permasalahan

Proses Peninjauan akses untuk menghindari konflik kepentingan. AS-4.4.3 Mitigasi konflik oleh kontrol. AS-4.5.2 Audit dan monitoring kemampuan beroperasi. AS-5.3.3(c) Kelompok user independen dan programmer mengawasi pergerakan program dan data antara library. AS-3.7.1 (a) Perubahan kode program aplikasi dan tabel dibatasi dan ditolak dalam lingkungan produksi. AS-3.9.1(a) Prosedur pemantauan perubahan. AS-3.11.1 Pemantauan perubahan desain data master. BP-4.6.2 Deskripsi semua kontrol yang telah ada atau sedang direncanakan termasuk bagaimana kontrol diimplementasikan atau akan diimplementasikan. AS-1.1.A (f) Identifikasi pemisahan tugas (segregation of duties) yang berisiko tinggi. AS-1.1.A (k) Peninjauan akses secara periodik. AS-2.4.2 Peninjauan otoritas akses user ke aktivitas sensitif oleh administrator pemilik. AS-2.6.4 Peninjauan oleh admin keamanan terhadap otorisasi akses user aplikasi. AS-4.4.2 Prosedur untuk memantau override dan memelihara override log. BP-1.5.2(b) Peninjauan log proses. BP-2.9.3 Pemantauan override log. BP-2.9.4 Kontrol aktivitas abnormal. DA-1.2.2 Monitor override, termasuk pemeliharaan override log. BP-3.3.2(b) Kontrol data tidak valid. DA-1.3.1

Rekomendasi PO9-10 DS5-33 PO9-12 DS5-35 PO9-18 AI6-3

AI6-4

AI6-5 AI6-7 DS5-2

DS5-3 DS5-19 DS5-25 DS5-32 DS5-7 DS5-39 DS11-13 DS5-40 DS11-14 DS5-46 DS11-17 DS11-27

Kode satker salah/tidak ada pada tabel.

Kontrol field yang diperlukan. BP-1.5.1(c) Peninjauan batasan dalam menginputkan data dan memvalidasi bahwa data akurat dan tepat secara reguler. BP-1.6.1(b) Kontrol data tidak valid. DA-1.3.1 Audit dan monitoring kemampuan beroperasi. AS-5.3.3(c) Kelompok user independen dan programmer mengawasi pergerakan program dan data antara library. AS-3.7.1 (a) Perubahan kode program aplikasi dan tabel dibatasi dan ditolak dalam lingkungan produksi. AS-3.9.1(a) Prosedur pemantauan perubahan. AS-3.11.1 Pemantauan perubahan desain data master.

PO2-2 DS11-3 PO2-7

PO2-20 PO9-18 AI6-3

AI6-4

AI6-5 AI6-7

116
Universitas Indonesia

117

No

Permasalahan

Proses BP-4.6.2 Deskripsi semua kontrol yang telah ada atau sedang direncanakan termasuk bagaimana kontrol diimplementasikan atau akan diimplementasikan. AS-1.1.A (f) Rekonsiliasi secara periodik. BP-2.6.1 Prosedur untuk menjamin semua input aplikasi terotorisasi. BP-1-2.1 Rekonsiliasi secara periodik. BP-2.6.1 Kontrol field yang diperlukan. BP-1.5.1(c) Peninjauan batasan dalam menginputkan data dan memvalidasi bahwa data akurat dan tepat secara reguler. BP-1.6.1(b) Kontrol data tidak valid. DA-1.3.1 Audit dan monitoring kemampuan beroperasi. AS-5.3.3(c) Kelompok user independen dan programmer mengawasi pergerakan program dan data antara library. AS-3.7.1 (a) Perubahan kode program aplikasi dan tabel dibatasi dan ditolak dalam lingkungan produksi. AS-3.9.1(a) Prosedur pemantauan perubahan. AS-3.11.1 Pemantauan perubahan desain data master. BP-4.6.2 Deskripsi semua kontrol yang telah ada atau sedang direncanakan termasuk bagaimana kontrol diimplementasikan atau akan diimplementasikan. AS-1.1.A (f) Rekonsiliasi secara periodik. BP-2.6.1 Kombinasi yang valid dari nilai field data yang berkaitan.BP-1.5.1(e) Pengisian nilai null dan invalid. BP-4.1.2 Peninjauan batasan dalam menginputkan data dan memvalidasi bahwa data akurat dan tepat secara reguler. BP-1.6.1(b) Kontrol data tidak valid. DA-1.3.1 Audit dan monitoring kemampuan beroperasi. AS-5.3.3(c) Kelompok user independen dan programmer mengawasi pergerakan program dan data antara library. AS-3.7.1 (a) Perubahan kode program aplikasi dan tabel dibatasi dan ditolak dalam lingkungan produksi. AS-3.9.1(a) Prosedur pemantauan perubahan. AS-3.11.1 Pemantauan perubahan desain data master. BP-4.6.2 Deskripsi semua kontrol yang telah ada atau sedang direncanakan termasuk bagaimana kontrol diimplementasikan atau akan

Rekomendasi DS5-2

5 Data perlu dikonfirmasi (kode stapeg 21 dan 22). 6 Data dengan gaji pokok salah/tidak ada pada tabel.

DS11-9 DS11-1 DS11-9 PO2-2 DS11-3 PO2-7

PO2-20 PO9-18 AI6-3

AI6-4

AI6-5 AI6-7 DS5-2

7 Data dengan tanggal lahir kosong.

DS11-9 PO2-3 DS11-4 PO2-10 PO2-7

PO2-20 PO9-18 AI6-3

AI6-4

AI6--5 AI6-7 DS5-2

117
Universitas Indonesia

118

No

Permasalahan

Proses diimplementasikan. AS-1.1.A (f) Rekonsiliasi secara periodik. BP-2.6.1 Kombinasi yang valid dari nilai field data yang berkaitan.BP-1.5.1(e) Peninjauan batasan dalam menginputkan data dan memvalidasi bahwa data akurat dan tepat secara reguler. BP-1.6.1(b) Kontrol data tidak valid. DA-1.3.1 Audit dan monitoring kemampuan beroperasi. AS-5.3.3(c) Kelompok user independen dan programmer mengawasi pergerakan program dan data antara library. AS-3.7.1 (a) Perubahan kode program aplikasi dan tabel dibatasi dan ditolak dalam lingkungan produksi. AS-3.9.1(a) Prosedur pemantauan perubahan. AS-3.11.1 Pemantauan perubahan desain data master. BP-4.6.2 Deskripsi semua kontrol yang telah ada atau sedang direncanakan termasuk bagaimana kontrol diimplementasikan atau akan diimplementasikan. AS-1.1.A (f) Rekonsiliasi secara periodik. BP-2.6.1 Kombinasi yang valid dari nilai field data yang berkaitan.BP-1.5.1(e) Peninjauan batasan dalam menginputkan data dan memvalidasi bahwa data akurat dan tepat secara reguler. BP-1.6.1(b) Kontrol data tidak valid. DA-1.3.1 Audit dan monitoring kemampuan beroperasi. AS-5.3.3(c) Kelompok user independen dan programmer mengawasi pergerakan program dan data antara library. AS-3.7.1 (a) Perubahan kode program aplikasi dan tabel dibatasi dan ditolak dalam lingkungan produksi. AS-3.9.1(a) Prosedur pemantauan perubahan. AS-3.11.1 Pemantauan perubahan desain data master. BP-4.6.2 Deskripsi semua kontrol yang telah ada atau sedang direncanakan termasuk bagaimana kontrol diimplementasikan atau akan diimplementasikan. AS-1.1.A (f) Rekonsiliasi secara periodik. BP-2.6.1 Kontrol field yang diperlukan. BP-1.5.1(c) Peninjauan batasan dalam menginputkan data dan memvalidasi bahwa data akurat dan tepat secara reguler. BP-1.6.1(b) Kontrol data tidak valid. DA-1.3.1

Rekomendasi DS11-9 PO2-3 DS11-4 PO2-7

Kode Status Pegawai 20 yaitu peserta Non Aktif/Usia melebihi Batas Usia Pensiun (BUP) dan belum mengajukan perubahan statusnya.

PO2-20 PO9-3 AI6-3

AI6-4

AI6-5 AI6-7 DS5-2

9 Isian dalam field TMT Gaji Pokok dan nilai gaji pokok dalam field Gapok untuk Kode Kelompok 1 (PNS) dengan status pegawai tetap (Kd Stapeg 4) tidak sama dengan gaji pokok 1 Januari 2009.

DS11-9 PO2-3 DS11-4 PO2-7

PO2-20 PO9-3 AI6-3

AI6-4

AI6-5 AI6-7 DS5-2

10 Kode Satker kosong.

DS11-9 PO2-2 DS11-3 PO2-7

PO2-20

118
Universitas Indonesia

119

No

Permasalahan

Proses Audit dan monitoring kemampuan beroperasi. AS-5.3.3(c) Kelompok user independen dan programmer mengawasi pergerakan program dan data antara library. AS-3.7.1 (a) Perubahan kode program aplikasi dan tabel dibatasi dan ditolak dalam lingkungan produksi. AS-3.9.1(a) Prosedur pemantauan perubahan. AS-3.11.1 Pemantauan perubahan desain data master. BP-4.6.2 Deskripsi semua kontrol yang telah ada atau sedang direncanakan termasuk bagaimana kontrol diimplementasikan atau akan diimplementasikan. AS-1.1.A (f) Rekonsiliasi secara periodik. BP-2.6.1 Rekonsiliasi secara periodik. BP-2.6.1 Prosedur untuk menjamin semua input aplikasi terotorisasi. BP-1-2.1 Peninjauan data master. BP-4.3.1 Peninjauan data master. BP-4.3.1 Rekonsiliasi secara periodik. BP-2.6.1 Prosedur untuk menjamin semua input aplikasi terotorisasi. BP-1-2.1 Kontrol data tidak valid. DA-1.3.1 Audit dan monitoring kemampuan beroperasi. AS-5.3.3(c) Kelompok user independen dan programmer mengawasi pergerakan program dan data antara library. AS-3.7.1 (a) Perubahan kode program aplikasi dan tabel dibatasi dan ditolak dalam lingkungan produksi. AS-3.9.1(a) Prosedur pemantauan perubahan. AS-3.11.1 Pemantauan perubahan desain data master. BP-4.6.2 Deskripsi semua kontrol yang telah ada atau sedang direncanakan termasuk bagaimana kontrol diimplementasikan atau akan diimplementasikan. AS-1.1.A (f) Peninjauan data master. BP-4.3.1 Rekonsiliasi secara periodik. BP-2.6.1 Prosedur untuk menjamin semua input aplikasi terotorisasi. BP-1-2.1 Kontrol data tidak valid. DA-1.3.1 Audit dan monitoring kemampuan beroperasi. AS-5.3.3(c) Kelompok user independen dan programmer mengawasi pergerakan program dan data antara library. AS-3.7.1 (a) Perubahan kode program aplikasi dan tabel dibatasi dan ditolak dalam lingkungan

Rekomendasi PO9-18 AI6-3

AI6-4

AI6-5 AI6-7 DS5-2

11 Tidak Ada Record (TAR) di Taspen. 12 TAR pindah cabang.

DS11-9 DS11-9 DS11-1 PO2-13 PO2-13 DS11-9 DS11-1 PO2-20 PO9-18 AI6-3

AI6-4

AI6-5 AI6-7 DS5-2

13

Belum ter-update.

PO2-13 DS11-9 DS11-1 PO2-20 PO9-18 AI6-3

AI6-4

119
Universitas Indonesia

120

No

Permasalahan

Proses produksi. AS-3.9.1(a) Prosedur pemantauan perubahan. AS-3.11.1 Pemantauan perubahan desain data master. BP-4.6.2 Deskripsi semua kontrol yang telah ada atau sedang direncanakan termasuk bagaimana kontrol diimplementasikan atau akan diimplementasikan. AS-1.1.A (f) Peninjauan data master. BP-4.3.1 Rekonsiliasi secara periodik. BP-2.6.1 Prosedur untuk menjamin semua input aplikasi terotorisasi. BP-1-2.1 Kontrol data tidak valid. DA-1.3.1 Audit dan monitoring kemampuan beroperasi. AS-5.3.3(c) Kelompok user independen dan programmer mengawasi pergerakan program dan data antara library. AS-3.7.1 (a) Perubahan kode program aplikasi dan tabel dibatasi dan ditolak dalam lingkungan produksi. AS-3.9.1(a) Prosedur pemantauan perubahan. AS-3.11.1 Pemantauan perubahan desain data master. BP-4.6.2 Deskripsi semua kontrol yang telah ada atau sedang direncanakan termasuk bagaimana kontrol diimplementasikan atau akan diimplementasikan. AS-1.1.A (f) Kontrol proses duplikat.BP-1.5.1(i) Peninjauan batasan dalam menginputkan data dan memvalidasi bahwa data akurat dan tepat secara reguler. BP-1.6.1(b) Field data yang tetap. BP-4.2.1 Peninjauan data master. BP-4.3.1 Kontrol data tidak valid. DA-1.3.1 Audit dan monitoring kemampuan beroperasi. AS-5.3.3(c) Kelompok user independen dan programmer mengawasi pergerakan program dan data antara library. AS-3.7.1 (a) Perubahan kode program aplikasi dan tabel dibatasi dan ditolak dalam lingkungan produksi. AS-3.9.1(a) Prosedur pemantauan perubahan. AS-3.11.1 Pemantauan perubahan desain data master. BP-4.6.2 Deskripsi semua kontrol yang telah ada atau sedang direncanakan termasuk bagaimana kontrol diimplementasikan atau akan diimplementasikan. AS-1.1.A (f) Rekonsiliasi secara periodik. BP-2.6.1

Rekomendasi AI6-5 AI6-7 DS5-2

14

PMK (Pensiun Meninggal/Keluar).

PO2-13 DS11-9 DS11-1 PO2-20 PO9-18 AI6-3

AI6-4

AI6-5 AI6-7 DS5-2

15

NIP Sama Nama Lain (Nisanala).

PO2-6 DS11-7 PO2-7

PO2-11 PO2-13 PO2-20 PO9-18 AI6-3

AI6-4

AI6-5 AI6-7 DS5-2

DS11-9

120
Universitas Indonesia

121

No

Permasalahan

Proses Prosedur untuk menjamin semua input aplikasi terotorisasi. BP-1-2.1

Rekomendasi DS11-1

16

Usia peserta > dari BUP dan status masih aktif.

Cek kisaran. BP-1.5.1(f) Kombinasi yang valid dari nilai field data yang berkaitan.BP-1.5.1(e) Peninjauan batasan dalam menginputkan data dan memvalidasi bahwa data akurat dan tepat secara reguler. BP-1.6.1(b) Kontrol data tidak valid. DA-1.3.1 Audit dan monitoring kemampuan beroperasi. AS-5.3.3(c) Kelompok user independen dan programmer mengawasi pergerakan program dan data antara library. AS-3.7.1 (a) Perubahan kode program aplikasi dan tabel dibatasi dan ditolak dalam lingkungan produksi. AS-3.9.1(a) Prosedur pemantauan perubahan. AS-3.11.1 Pemantauan perubahan desain data master. BP-4.6.2 Deskripsi semua kontrol yang telah ada atau sedang direncanakan termasuk bagaimana kontrol diimplementasikan atau akan diimplementasikan. AS-1.1.A (f) Rekonsiliasi secara periodik. BP-2.6.1 Cek kisaran. BP-1.5.1(f) Kombinasi yang valid dari nilai field data yang berkaitan.BP-1.5.1(e) Peninjauan batasan dalam menginputkan data dan memvalidasi bahwa data akurat dan tepat secara reguler. BP-1.6.1(b) Peninjauan data master. BP-4.3.1 Lokasi penyimpanan data. DA-1.1.1

PO2-4 DS11-5 PO2-3 DS11-4 PO2-7

PO2-20 PO9-18 AI6-3

AI6-4

AI6-5 AI6-7 DS5-2

17 Usia masuk menjadi peserta <18 tahun atau >46 tahun (non pejabat Negara).

DS11-9 PO2-4 DS11-5 PO2-3 DS11-4 PO2-7 PO2-13 PO2-19 DS11-26 DS12-1 PO2-20 PO9-7 PO9-8 PO9-10 DS5-33 PO9-12 DS5-35 PO9-18 AI6-3

Kontrol data tidak valid. DA-1.3.1 Identifikasi aktivitas dan transaksi yang tidak cocok. AS-4.1.1 Risiko konflik kepentingan user. AS-4.1.2 Peninjauan akses untuk menghindari konflik kepentingan. AS-4.4.3 Mitigasi konflik oleh kontrol. AS-4.5.2 Audit dan monitoring kemampuan beroperasi. AS-5.3.3(c) Kelompok user independen dan programmer mengawasi pergerakan program dan data antara library. AS-3.7.1 (a) Perubahan kode program aplikasi dan tabel dibatasi dan ditolak dalam lingkungan produksi. AS-3.9.1(a)

AI6-4

121
Universitas Indonesia

122

No

Permasalahan

Proses Prosedur pemantauan perubahan. AS-3.11.1 Pemantauan perubahan desain data master. BP-4.6.2 Deskripsi semua kontrol yang telah ada atau sedang direncanakan termasuk bagaimana kontrol diimplementasikan atau akan diimplementasikan. AS-1.1.A (f) Identifikasi pemisahan tugas (segregation of duties) yang berisiko tinggi. AS-1.1.A (k) Peninjauan akses secara periodik. AS-2.4.2 Peninjauan otoritas akses user ke aktivitas sensitif oleh administrator pemilik. AS-2.6.4 Peninjauan oleh admin keamanan terhadap otorisasi akses user aplikasi. AS-4.4.2 Prosedur untuk memantau override dan memelihara override log. BP-1.5.2(b) Peninjauan log proses. BP-2.9.3 Pemantauan override log. BP-2.9.4 Kontrol aktivitas abnormal. DA-1.2.2 Monitor override, termasuk pemeliharaan override log. BP-3.3.2(b) Kontrol data tidak valid. DA-1.3.1 Prosedur untuk menjamin semua input aplikasi terotorisasi. BP-1-2.1 Rekonsiliasi secara periodik. BP-2.6.1 Peninjauan data master. BP-4.3.1 Kontrol data tidak valid. DA-1.3.1 Audit dan monitoring kemampuan beroperasi. AS-5.3.3(c) Deskripsi semua kontrol yang telah ada atau sedang direncanakan termasuk bagaimana kontrol diimplementasikan atau akan diimplementasikan. AS-1.1.A (f) Prosedur untuk menjamin semua input aplikasi terotorisasi. BP-1-2.1 Rekonsiliasi secara periodik. BP-2.6.1 Peninjauan data master. BP-4.3.1 Kontrol data tidak valid. DA-1.3.1 Audit dan monitoring kemampuan beroperasi. AS-5.3.3(c) Deskripsi semua kontrol yang telah ada atau sedang direncanakan termasuk bagaimana kontrol diimplementasikan atau akan diimplementasikan. AS-1.1.A (f) Cek kisaran. BP-1.5.1(f) Kombinasi yang valid dari nilai field data yang berkaitan.BP-1.5.1(e) Pengisian nilai null dan invalid. BP-4.1.2 Peninjauan batasan dalam menginputkan

Rekomendasi AI6-5 AI6-7 DS5-2

DS5-3 DS5-19 DS5-25 DS5-32 DS5-7 DS5-39 DS11-13 DS5-40 DS11-14 DS5-46 DS11-17 DS11-27 DS11-1 DS11-9 PO2-13 PO2-20 PO9-18 DS5-2

18

Tidak termutasi selama 3 tahun dari current date.

19

Tidak ter update selama 2 tahun dari current date.

DS11-1 DS11-9 PO2-13 PO2-20 PO9-18 DS5-2

20

Data peserta dengan gapok nol.

PO2-4 DS11-5 PO2-3 DS11-4 PO2-10 PO2-7

122
Universitas Indonesia

123

No

Permasalahan

Proses data dan memvalidasi bahwa data akurat dan tepat secara reguler. BP-1.6.1(b) Kontrol data tidak valid. DA-1.3.1 Audit dan monitoring kemampuan beroperasi. AS-5.3.3(c) Kelompok user independen dan programmer mengawasi pergerakan program dan data antara library. AS-3.7.1 (a) Perubahan kode program aplikasi dan tabel dibatasi dan ditolak dalam lingkungan produksi. AS-3.9.1(a) Prosedur pemantauan perubahan. AS-3.11.1 Pemantauan perubahan desain data master. BP-4.6.2 Deskripsi semua kontrol yang telah ada atau sedang direncanakan termasuk bagaimana kontrol diimplementasikan atau akan diimplementasikan. AS-1.1.A (f) Rekonsiliasi secara periodik. BP-2.6.1 Prosedur untuk menjamin semua input aplikasi terotorisasi. BP-1-2.1 Rekonsiliasi secara periodik. BP-2.6.1

Rekomendasi

PO2-20 PO9-18 AI6-3

AI6-4

AI6-5 AI6-7 DS5-2 DS11-9

21 Terdapat selisih data peserta dari Rekap Hasil Proses Daftar Gaji antara database peserta PT Taspen dengan Daftar Gaji yang diperoleh dari Pemda dan KPPN. Gaji Pokok bukan gaji pokok tahun 2009.

DS11-1 DS11-9

22

Kontrol field yang diperlukan. BP-1.5.1(c) Peninjauan batasan dalam menginputkan data dan memvalidasi bahwa data akurat dan tepat secara reguler. BP-1.6.1(b) Kontrol data tidak valid. DA-1.3.1 Audit dan monitoring kemampuan beroperasi. AS-5.3.3(c) Kelompok user independen dan programmer mengawasi pergerakan program dan data antara library. AS-3.7.1 (a) Perubahan kode program aplikasi dan tabel dibatasi dan ditolak dalam lingkungan produksi. AS-3.9.1(a) Prosedur pemantauan perubahan. AS-3.11.1 Pemantauan perubahan desain data master. BP-4.6.2 Deskripsi semua kontrol yang telah ada atau sedang direncanakan termasuk bagaimana kontrol diimplementasikan atau akan diimplementasikan. AS-1.1.A (f) Cek kisaran. BP-1.5.1(f) Kombinasi yang valid dari nilai field data yang berkaitan.BP-1.5.1(e) Peninjauan batasan dalam menginputkan

PO2-2 DS11-3 PO2-7

PO2-20 PO9-18 AI6-3

AI6-4

AI6-5 AI6-7 DS5-2

23

Nilai THP tidak sesuai hasil perhitungan.

PO2-4 DS11-5 PO2-3 DS11-4 PO2-7

123
Universitas Indonesia

124

No

Permasalahan

Proses data dan memvalidasi bahwa data akurat dan tepat secara reguler. BP-1.6.1(b) Peninjauan data master. BP-4.3.1 Lokasi penyimpanan data. DA-1.1.1

Rekomendasi

Kontrol data tidak valid. DA-1.3.1 Identifikasi aktivitas dan transaksi yang tidak cocok. AS-4.1.1 Risiko konflik kepentingan user. AS-4.1.2 Peninjauan akses untuk menghindari konflik kepentingan. AS-4.4.3 Mitigasi konflik oleh kontrol. AS-4.5.2 Audit dan monitoring kemampuan beroperasi. AS-5.3.3(c) Kelompok user independen dan programmer mengawasi pergerakan program dan data antara library. AS-3.7.1 (a) Perubahan kode program aplikasi dan tabel dibatasi dan ditolak dalam lingkungan produksi. AS-3.9.1(a) Prosedur pemantauan perubahan. AS-3.11.1 Pemantauan perubahan desain data master. BP-4.6.2 Deskripsi semua kontrol yang telah ada atau sedang direncanakan termasuk bagaimana kontrol diimplementasikan atau akan diimplementasikan. AS-1.1.A (f) Identifikasi pemisahan tugas (segregation of duties) yang berisiko tinggi. AS-1.1.A (k) Peninjauan akses secara periodik. AS-2.4.2 Peninjauan otoritas akses user ke aktivitas sensitif oleh administrator pemilik. AS-2.6.4 Peninjauan oleh admin keamanan terhadap otorisasi akses user aplikasi. AS-4.4.2 Prosedur untuk memantau override dan memelihara override log. BP-1.5.2(b) Peninjauan log proses. BP-2.9.3 Pemantauan override log. BP-2.9.4 Kontrol aktivitas abnormal. DA-1.2.2 Monitor override, termasuk pemeliharaan override log. BP-3.3.2(b) Kontrol data tidak valid. DA-1.3.1

PO2-13 PO2-19 DS11-26 DS12-1 PO2-20 PO9-7 PO9-8 PO9-10 DS5-33 PO9-12 DS5-35 PO9-18 AI6-3

AI6-4

AI6-5 AI6-7 DS5-2

DS5-3 DS5-19 DS5-25 DS5-32 DS5-7 DS5-39 DS11-13 DS5-40 DS11-14 DS5-46 DS11-17 DS11-27

II.

DATA PESERTA PROGRAM PENSIUN Tanggal lahir dalam database salah. Kombinasi yang valid dari nilai field data yang berkaitan.BP-1.5.1(e) Kontrol format field. BP-1.5.1(b) PO2-3 DS11-4 PO2-1 DS11-2

1.

124
Universitas Indonesia

125

No

Permasalahan

Proses Peninjauan batasan dalam menginputkan data dan memvalidasi bahwa data akurat dan tepat secara reguler. BP-1.6.1(b) Kontrol data tidak valid. DA-1.3.1 Audit dan monitoring kemampuan beroperasi. AS-5.3.3(c) Kelompok user independen dan programmer mengawasi pergerakan program dan data antara library. AS-3.7.1 (a) Perubahan kode program aplikasi dan tabel dibatasi dan ditolak dalam lingkungan produksi. AS-3.9.1(a) Prosedur pemantauan perubahan. AS-3.11.1 Pemantauan perubahan desain data master. BP-4.6.2 Deskripsi semua kontrol yang telah ada atau sedang direncanakan termasuk bagaimana kontrol diimplementasikan atau akan diimplementasikan. AS-1.1.A (f) Rekonsiliasi secara periodik. BP-2.6.1 Kontrol field yang diperlukan. BP-1.5.1(c) Peninjauan batasan dalam menginputkan data dan memvalidasi bahwa data akurat dan tepat secara reguler. BP-1.6.1(b) Kontrol data tidak valid. DA-1.3.1 Audit dan monitoring kemampuan beroperasi. AS-5.3.3(c) Kelompok user independen dan programmer mengawasi pergerakan program dan data antara library. AS-3.7.1 (a) Perubahan kode program aplikasi dan tabel dibatasi dan ditolak dalam lingkungan produksi. AS-3.9.1(a) Prosedur pemantauan perubahan. AS-3.11.1 Pemantauan perubahan desain data master. BP-4.6.2 Deskripsi semua kontrol yang telah ada atau sedang direncanakan termasuk bagaimana kontrol diimplementasikan atau akan diimplementasikan. AS-1.1.A (f) Rekonsiliasi secara periodik. BP-2.6. Kombinasi yang valid dari nilai field data yang berkaitan.BP-1.5.1(e) Peninjauan batasan dalam menginputkan data dan memvalidasi bahwa data akurat dan tepat secara reguler. BP-1.6.1(b) Peninjauan data master. BP-4.3.1 Lokasi penyimpanan data. DA-1.1.1

Rekomendasi PO2-7

PO2-20 PO9-3 AI6-3

AI6-4

AI6-5 AI6-7 DS5-2

2. Terdapat Nomor Induk Pegawai (NIP) berstatus Non NIP dan Non NRP.

DS11-9 PO2-2 DS11-3 PO2-7

PO2-20 PO9-18 AI6-3

AI6-4

AI6-5 AI6-7 DS5-2

3. Terdapat peserta pensiun yang telah meninggal sejak tahun 2000 s.d. 2009 namun dalam status JAD kosong atau stop mulai 1 Januari 2010

DS11-9 PO2-3 DS11-4 PO2-7

Kontrol data tidak valid. DA-1.3.1

PO2-13 PO2-19 DS11-26 DS12-1 PO2-20

125
Universitas Indonesia

126

No

Permasalahan

Proses Identifikasi aktivitas dan transaksi yang tidak cocok. AS-4.1.1 Risiko konflik kepentingan user. AS-4.1.2 Peninjauan akses untuk menghindari konflik kepentingan. AS-4.4.3 Mitigasi konflik oleh kontrol. AS-4.5.2 Audit dan monitoring kemampuan beroperasi. AS-5.3.3(c) Kelompok user independen dan programmer mengawasi pergerakan program dan data antara library. AS-3.7.1 (a) Perubahan kode program aplikasi dan tabel dibatasi dan ditolak dalam lingkungan produksi. AS-3.9.1(a) Prosedur pemantauan perubahan. AS-3.11.1 Pemantauan perubahan desain data master. BP-4.6.2 Deskripsi semua kontrol yang telah ada atau sedang direncanakan termasuk bagaimana kontrol diimplementasikan atau akan diimplementasikan. AS-1.1.A (f) Identifikasi pemisahan tugas (segregation of duties) yang berisiko tinggi. AS-1.1.A (k) Peninjauan akses secara periodik. AS-2.4.2 Peninjauan otoritas akses user ke aktivitas sensitif oleh administrator pemilik. AS-2.6.4 Peninjauan oleh admin keamanan terhadap otorisasi akses user aplikasi. AS-4.4.2 Prosedur untuk memantau override dan memelihara override log. BP-1.5.2(b) Peninjauan log proses. BP-2.9.3 Pemantauan override log. BP-2.9.4 Kontrol aktivitas abnormal. DA-1.2.2 Monitor override, termasuk pemeliharaan override log. BP-3.3.2(b) Kontrol data tidak valid. DA-1.3.1

Rekomendasi PO9-7 PO9-8 PO9-10 DS5-33 PO9-12 DS5-35 PO9-18 AI6-3

AI6-4

AI6-5 AI6-7 DS5-2

DS5-3 DS5-19 DS5-25 DS5-32 DS5-7 DS5-39 DS11-13 DS5-40 DS11-14 DS5-46 DS11-17 DS11-27

4.

Kesalahan input tanggal lahir pensiun (usia < 25 tahun).

Cek kisaran. BP-1.5.1(f) Kombinasi yang valid dari nilai field data yang berkaitan.BP-1.5.1(e) Peninjauan batasan dalam menginputkan data dan memvalidasi bahwa data akurat dan tepat secara reguler. BP-1.6.1(b) Kontrol data tidak valid. DA-1.3.1 Audit dan monitoring kemampuan beroperasi. AS-5.3.3(c) Kelompok user independen dan programmer mengawasi pergerakan program dan data antara library. AS-3.7.1 (a)

PO2-4 DS11-5 PO2-3 DS11-4 PO2-7

PO2-20 PO9-18 AI6-3

126
Universitas Indonesia

127

No

Permasalahan

Proses Perubahan kode program aplikasi dan tabel dibatasi dan ditolak dalam lingkungan produksi. AS-3.9.1(a) Prosedur pemantauan perubahan. AS-3.11.1 Pemantauan perubahan desain data master. BP-4.6.2 Deskripsi semua kontrol yang telah ada atau sedang direncanakan termasuk bagaimana kontrol diimplementasikan atau akan diimplementasikan. AS-1.1.A (f) Rekonsiliasi secara periodik. BP-2.6.1 Kontrol field yang diperlukan. BP-1.5.1(c) Peninjauan batasan dalam menginputkan data dan memvalidasi bahwa data akurat dan tepat secara reguler. BP-1.6.1(b) Kontrol data tidak valid. DA-1.3.1 Audit dan monitoring kemampuan beroperasi. AS-5.3.3(c) Kelompok user independen dan programmer mengawasi pergerakan program dan data antara library. AS-3.7.1 (a) Perubahan kode program aplikasi dan tabel dibatasi dan ditolak dalam lingkungan produksi. AS-3.9.1(a) Prosedur pemantauan perubahan. AS-3.11.1 Pemantauan perubahan desain data master. BP-4.6.2 Deskripsi semua kontrol yang telah ada atau sedang direncanakan termasuk bagaimana kontrol diimplementasikan atau akan diimplementasikan. AS-1.1.A (f) Rekonsiliasi secara periodik. BP-2.6.1

Rekomendasi AI6-4

AI6-5 AI6-7 DS5-2

5.

Pensiun pokok (100%) tidak ada di tabel pensiun pokok.

DS11-9 PO2-2 DS11-3 PO2-7

PO2-20 PO9-18 AI6-3

AI6-4

AI6-5 AI6-7 DS5-2

DS11-9

127
Universitas Indonesia

BAB 6 KESIMPULAN DAN SARAN

Bab ini menjelaskan kesimpulan dan saran dari penyusunan karya akhir ini.

6.1 Kesimpulan Kesimpulan dari penelitian ini sebagai berikut: 1. Penerapan kontrol penerapan sistem informasi pada PT Taspen (Persero) untuk menjamin integritas data pada manajemen data peserta dengan pendekatan FISCAM dan COBIT 4.1 masih sebesar 53,7 persen. 2. Kategori kontrol pada FISCAM meliputi kontrol umum (application control general), proses bisnis, proses antarmuka (interface), dan manajemen data. Sedangkan pada COBIT 4.1 terdiri dari PO2 (menentukan desain arsitektur informasi), PO9 (manajemen risiko), AI6 (manajemen perubahan), DS5 (memastikan keamanan sistem), DS11 (mengelola data), dan DS12 (mengelola keamanan fisik). 3. Kontrol penerapan SI untuk memastikan integritas manajemen data yang paling bagus adalah kontrol manajemen perubahan (AI6) sebesar 67,9 persen. Sedangkan kontrol yang belum banyak diterapkan adalah manajemen risiko (PO9) sebesar 69,7 persen. 4. Total 117 rekomendasi untuk meningkatkan integritas data pada area kontrol yang masih lemah. Dari total rekomendasi tersebut, 47 item di antaranya diprioritaskan untuk menyelesaikan temuan hasil audit BPK tahun 2009. 5. Semua rekomendasi dengan pendekatan FISCAM dapat menjawab semua temuan hasil audit BPK tahun 2009. 6.2 Saran Saran yang penulis berikan untuk organisasi tempat studi kasus dilakukan dan bagi peneliti untuk kasus-kasus serupa sebagai berikut:

128
Universitas Indonesia

129

1. PT Taspen (Persero) sebaiknya menerapkan dan mensosialisasikan, kebijakan keamanan kepada seluruh karyawan, serta memperbaruinya berdasarkan level risiko yang ditolerir oleh pihak Taspen. 2. Prosedur kerja yang telah terangkum dalam SOP sebaiknya dijalankan dan ditinjau secara periodik dan dilakukan audit oleh auditor internal. Apabila dimungkinkan dikaitkan dengan key performance indicator. 3. PT Taspen (Persero) sebaiknya menjadikan kegiatan peninjauan dan evaluasi sebagai bagian dari penyempurnaan sistem ke depan. 4. Desain aplikasi dan segala perubahan sebaiknya didokumentasikan untuk membantu menelusuri perubahan. 5. Pemisahan tugas (segregation of duties) seharusnya menjadi salah satu perhatian manajemen TI untuk meminimalkan risiko. Salah satunya dengan melakukan rotasi kerja tiap enam bulan. 6. Manajemen PT Taspen (Persero) menjadikan business continuity plan sebagai salah satu program kerja yang perlu segera diimplementasikan. 7. Hasil penelitian ini dapat digunakan untuk kasus-kasus serupa, yaitu untuk permasalahan integritas data di dalam sistem.

129
Universitas Indonesia

DAFTAR PUSTAKA

[1]

Connoly, Thomas & Begg, Caroline.(2005). Database system. (4rd ed.). Boston: Addison Wesley.

[2]

Fitrianah, Devi. (2007). Audit SI/TI dengan kerangka kerja COBIT untuk evaluasi manajemen TI di universitas XYZ.

[3]

Gondodiyoto, Sanyoto & Hendarti, Henny. (2006). Audit sistem informasi. Jakarta: Mitra Wacana Media.

[4] [5] [6] [7]

ISACA. (2009). CISA review manual 2009. IT Governance Institute. (2007). CobiT 4.1 IT Governance Institute. (2007). Mapping of ITIL v3 with CobiT 4.1 Kurniawan, Eko. (2003). Audit, analisa, dan perancangan infrastruktur network security studi kasus: mobile internet services company.

[8]

National State Auditors Association and the U. S. General Accounting Office. (2001). Management planning guide for information systems security auditing. http://www.gao.gov/special.pubs/mgmtpln.pdf

[9]

Neil, James. (2007). Qualitative versus quantitative research: key points in a classic debate. Desember, 1, 2009. http://wilderdom.com/research.

[10]

Prasojo, Eko & Sujana Rachmat. (2008, Januari). Mengenal Lebih Jauh SAP dan JAD. Media Taspen, p9-10.

[11] [12]

PT Taspen (Persero). (2009). Rencana jangka panjang 2009-2013. Taspen Corporate Website. 12 Februari 2010.

http://www.taspen.com/profil. [13] US General Accounting Office. (2009). Federal Information System Controls Audit Manual. [14] Winata, Surya Dedi dkk. (2009). Perbandingan antara COBIT, COSO, Sarbanes Oxley Act, Basel II, ISO 17799.

130
Universitas Indonesia

LAMPIRAN 1: DAFTAR PERTANYAAN BERDASARKAN FISCAM


Topik terbagi empat, kontrol aplikasi secara umum, proses bisnis, antarmuka (interface) dan data. Jawab Ya dan Tidak

A. Kontrol Aplikasi Secara Umum 1. Apakah rencana keamanan aplikasi yang konprehensif telah dikembangkan dan didokumentasikan? Topik meliputi: a. Deskripsi dan identifikasi aplikasi b. Level risiko aplikasi c. Kepemilikan aplikasi d. Orang yang bertanggung jawab terhadap keamanan aplikasi e. Interkoneksi aplikasi/sharing informasi f. Deskripsi semua kontrol yang telah ada atau sedang direncanakan termasuk bagaimana kontrol diimplementasikan atau akan diimplementasikan g. Pendekatan dan prosedur desain keamanan dan proses upgrade h. Proses untuk mengembangkan peranan (roles) keamanan i. Kebijakan administrasi keamanan secara umum termasuk pemeliharaan dan pengembangan ongoing peranan (role) keamanan j. Identifikasi transaksi yang sensitif dalam setiap modul fungsional k. Identifikasi risiko tinggi untuk kasus pemisahan tugas (segregasi of duties) l. Peranan dan tanggung jawab keamanan organisasi yang didukung oleh sistem dengan memperhatikan pemisahan tugas m. Prosedur uji coba keamanan n. Koorinasi dengan kebijakan keamanan lingkup entitas o. Prosedur untuk akses darurat pada sistem produksi, termasuk akses untuk menguupdate program dalam produksi, update langsung database dan modifikasi option perubahan sistem p. Setting parameter sistem, patuh dengan kebijakan entitywide agency q. Prosedur kontrol akses untuk penggunaan sistem untuk critical user IDs AS-1.1.1A 2. Apakah akun sensitif diidentifikasi untuk tiap proses bisnis atau subproses dan hak akses keamanan yang penting terdefinisi dan disetujui? AS-1.2.2 3. Apakah hak akses dikembangkan untuk membatasi user dari mengeksekusi transaksi yang tidak cocok dari aplikasi melalui menu atau layar? AS-1.1.3 4. Apakah risiko keamanan dinilai untuk aplikasi dan sistem pendukung untuk setiap periodic atau setiap aplikasi atau sistem pendukung secara signifikan berubah? Apakah hasil penilaian itu terdokumentasi dan termasuk dalam rencana keamanan aplikasi? AS1.2.1 5. Apakah pemilik proses bisnis menerima risiko dan menyetujui kebijakan dan prosedur? AS-1.3.1 6. Apakah kebijakan dan prosedur? a. Terdokumentasi b. Sesuai dengan kebutuhan kemanan proses bisnis 7. Mempertimbangkan pemisahan aktivitas user aplikasi dari aktivitas administrator sistem AS-1.3.2 8. Apakah entitas memiliki proses yang efektif untuk mengkomunikasikan kebijakan keamanan aplikasi kepada pemilik aplikasi dan user dan menyakinkan bahwa mereka memiliki kesadaran berupa kebijakan AS-1.4.1 9. Apakah user memiliki pengalaman dan pengetahuan yang cukup tentang keamanan aplikasi?AS-1.4.2 10. Apakah kebijakan keamanan aplikasi dan rencana tes prosedur dikembangkan dan didokumentasikan?AS-1.5.1 11. Apakah kontrol kemanan yang berhubungan dengan aplikasi utama/mayor diuji minimal setahu sekali? AS-1.5.2

131
Universitas Indonesia

132

(lanjutan) 12. Apakah frekuensi dan lingkup uji coba seusi dengan risiko dan kepentingan aplikasi dari misi perusahaan? AS-1.5.3 13. Kepatuhan dan laporan dari kepatuhan merupakan bagian dari program keamanan entitas/perusahaan? AS-1.5.4 14. Apakah manajemen memiliki proses untuk mengkoreksi kelemahan/ AS-1.6.1 15. Apakah manajemen menginisiasi langkah awal untuk mengkoreksi kekurangan. Apakah rencana aksi dan milestone terdokmentasi dan lengkap? AS-1.6.2 16. Apakah kekurangan dianalisa melalui aplikasi (analisis mungkin diperpanjang untuk downstream, upstream dan segala sesuatu berkaitan dengan aplikasi) dan aksi korektif diimplementasikan? AS-1.6.4 17. Apakah kebijakan dan prosedur yang berhubungan dengan aktivitas pihak ketiga disusundan terdiri dari: a. Kepatuhan aplikasi dengan kebutuhan keamanan perusahaan b. Monitoring kepatuhan dengan persyaratan regulator AS-1.7.1 18. Apakah ada proses untuk memonitor kepatuhanprovider pihak ketiga dengan persyaratan regulasi perusahaan? AS-1.7.2 19. Apakah batasan aplikasi diidentifikasikan dalam rencana keamanan? Batasan aplikasi apakah cukup aman? AS-2.1.1 20. Apakah identifikasi dan autentikasi unik untuk setiap user? Setiap user harus memasukkan user dan password untuk emndapatkan akses aplikasi?AS-2.2.1 21. Apakah perusahaan memiliki prosedur formal dan proses untuk memberikan user sebuah akses ke aplikasi? Kebijakan dan prosedur tersebut meliputi: d. Menerima password e. Merubah dan mereset password f. Penanganan kehilangan password AS-2.3.1 22. Apakah aplikasi mengunci akun user setelah beberapa kali berusaha masuk dengan password yang salah? Apakah aplikasi secara otomatis mereset akun user setelah periode waktu yang spesifik atau mmerlukan administrator untuk mereset akun? Apakah user mendiamkan aplikasi atau sesi user tidak aktif, apakah aplikasi secara otomatis me-log off akun user?AS-2.3.2 23. Apakah tiap user aplikasi hanya memiliki satu akun? AS-2.3.3 24. Apakah multiple log on terkontrol dan termonitor? AS-2.3.4 25. Apakah sebelum user mendapatkan akun user dam password untuk aplikasi, aksel level user diotorisasi oleh manajer dan administrator aplikasi? AS-2.4.1 26. Apakah pemilik secara periodic melakukan review akses untuk menyakinkan sistem berjalan baik? AS-2.4.2 27. Apakah akses terbatas bagi individu dengan tujuan bisnis yang valid (hak minimal) ? AS2.4.3 28. Apakah perusahaan mengimplementasikan rencana keamanan dan proses untuk: a. Identifikasi dan otorisasi user b. Kontrol akses bagi hak user yang terbatas (baca, tulis, hapus) c. Penggunaaan digital signature d. Larangan akases langsung oleh umum pada data produksi e. Kepatuhan dengan FISMA dan NIST (regulasi) AS-2.5.1 29. Apakah pemilik mengidentifikasi transaksi sensitive atau aktivitas dari proses bisnis? AS2.6.1 30. Apakah pemilik mengotorisasi user untuk memiliki akses pada aktivitas/transaksi sensistif? AS-2.6.2 31. Apakah administrator keamanan melakukan review otorisasi akses user aplikasi untuk mengakses transaksi sensitive dan mendiskusikan otorisasi yang menimbulkan tanda tanya pada pemilik?AS-2.6.3 32. Apakah pemilik secara periodic me-review akses ke transaksi/aktivitas sensitif dan memastikannya berjalan baik? AS-2.6.4 33. Apakah akun individu yang tidak aktif dan terminasi disable atau dihilangkan dalam waktu tertentu?AS-2.6.5 34. Apakah akses ke transaksi sesnsitif dibatasi untuk individu dengan tujuan bisnis yang valid (hak minimal)? AS-2.6.6

132
Universitas Indonesia

133

(lanjutan) 35. Apakah organisasi mengidentifikasi sumber daya (resources) aplikasi yang sensitif? Apakah akses ke sumber daya aplikasi sensitive terbatas bagi user yang tepat? Apakah data aplikasi yang sensistif terenkripsi? AS-2.7.1 36. Apakah kebijakan dan prosedur dibuat untuk memastikan audit keamanan aplikasi dan monitoring efektif?AS-2.8.1 37. Apakah logging dan parameter lain diset untuk memberitahu apabila terjadi pelanggaran keamanan?AS-2.9.1 38. Apakah exception dan gangguan diidentifikasi dan diagendakan (dilog)? Apakah laporan exception ditinjau oleh administrator keamanan? Apakah jika terjadi exception ada tindakan? AS-2.10.1 39. Apakah kontrol fisik terintegrasi secara korporasi dan dengan kontrol level sistem? Apakah sumber daya aplikasi sensitif teridentifikasi dan kemanan fisik yang tepat? AS2.11.1 40. Apakah kebijakan dan prosedur disusun untuk manajemen konfigurasi aplikasi? AS-3.1.1 41. Apakah organisasi menjaga informasi pada konfigurasi aplikasi saat ini?AS-3.2.1 42. Apakah metodologi SDLC dikembangkan: c. Menyediakan pendekatan terstruktur konsisten dengan konsep dan praktik yang diterima, termasuk keterlibatan user dalam proses d. Terdokumentasi untuk menyediakan bantuan bagi staf dengan keahlian dan pengalaman yang berbeda e. Menyediakan perangkat untuk mengontrol perubahan kebutuhan yang terjadi setelah sistem diimplementasikan f. Menyangkut kebutuhan dokumentasi AS-3.3.1 43. Apakah formulir permintaan perubahan digunakan untuk permintaan dokumen dan proyek yang berkaitan? AS-3.4.1 44. Apakah permintaan perubahan harus disetujui oleh user sistem dan staf TI?AS-3.4.2 45. Apakah standar rencana uji coba dikembangkan untuk semua level uji coba yang mendefisikan tanggung jawab tiap pihak (user, analis sistem, programmer, auditor, penyelia kualitas dan library control? AS-3.5.1 46. Apakah spesifikasi sistem detil disiapkan oleh programmer dan ditinjau oleh supervisor programmer? AS-3.5.2 47. Apakah perubahan software didokumentasikan sehingga dapat ditelusuri untuk otorisasi hingga kode final? AS-3.5.3 48. Apakah rencana uji coba yang didokumentasikan dan disetujui menyebukan tanggung jawab tiap-tiap pihak yang terlibat? AS-3.5.4 49. Apakah unit, intergrasi dan uji coba testing dilakukan dan disetujui: a. Berdasarkan rencana uji coba b. Menerapkan kondisi valid dan ivalid? AS-3.5.5 50. Apakah uji coba yang dilaksanakan telah mewakili transaksi dan kondisi yang beragam? AS-3.5.6A 51. Apakah hasil tes ditinjau dan didokumentasikan?AS-3.5.7 52. Apakah perubahan program yang telah dipindahkan ke produksi terdokumentasi dan disetujui oleh user dan manajemen pengembangan sistem? AS-3.5.8 53. Apakah dokumentasi selalu update ketika sistem dimodifikasi atau sistem baru diimplementasikan? AS-3.5.9 54. Apakah library berada di tempat yang terpisah untuk pengembangan program dan pemeliharaan, uji coba dan program produksi? AS-3.6.1 55. Apakah source code dipisah dengan library? AS-3.6.2 56. Apakah akses ke seluruh program, termasuk kode produksi, source code, dan kopi extra program dilindungi oleh software kontrol akses dan fitur sistem operasi? AS-3.6.2 57. Apakah kelompok user independen dan programmer mengawasi pergerakan program dan data antara library? Apakah sebelum dan sesudah citra kode program dibandingkan untuk memastikan hanya perubahan yang disetujui yang diimplementasikan? AS-3.7.1 58. Apakah akun user untuk peran dalam aplikasi didesain dan disetujui manajemen untuk menyediakan akses yang tepat dan melindungi dari user yang tidak terotorisasi dari mengekseskusi produksi yang merubah fungsi aplikasi? AS-3.8.1

133
Universitas Indonesia

134

(lanjutan) 59. Apakah perubahan kode program aplikasi dan tabel dibatasi dan ditolak dalam lingkungan produksi. Semua perubahan yang dibuat menggunakan proses kontrol perubahan yang disetujui? Apakah akses user ke kode program aplikasi dan tabel disediakan hanya untuk user ID darurat? AS-3.9.1 60. Apakah desain keamanan mempertimbangkan transaksi administrasi sistem sensitive dan membatasi user untuk mengakses transaksi tersebut? AS-3.10.1 61. Apakah prosedur dibuat untuk memastikan program kunci dan perubahan tabel diawasi oleh penanggung jawab yang tidak memiliki wewenang untuk mengubah otorisasi? Apakah prosedur menyediakan laporan detil/log to run, kriteria valuasi spesifik dan frekuensi penilaian? AS-3.11 62. Apakah kepatuhan terhadap proses manajemen perubahan dan perubahan untuk mengkonfigurasi obyek dan program secara periodik dinilai? AS-3.12.1 63. Apakah organisasi mengikuti proses yang efektif untuk mengidentifikasi celah dalam aplikasi dan meng-up datenya? AS-3.13.1 64. Apakah organisasi mengikuti proses yang efektif untuk secara tepat mendokumentasikan dokumen, uji coba dan perubahan darurat yang disetujui? AS-3.14.1 65. Apakah pemilik memiliki identifikasi aktivitas dan transaksi yang tidak cocok dan mendokumentasikannya dalam matriks pemisahan tugas? AS-4.1.1 66. Apakah pemilik mempertimbangkan risiko dengan mengijinkan adanya konflik kepentingan user? AS-4.1.2 67. Apakah user dijaga oleh aplikasi dari kemungkinan mengakses transaksi yang tidak sesuai dengan haknya? AS-4.2.1 68. Apakah administrator keamanan tidak memiliki hak untuk emnginput dan menyetujui transaksi? AS-4.3.1 69. Apakah pemilik mengotorisasi user untuk memiliki akses yang menyebabkan terjadi konflik tugas namun sesuai kebutuhan bisnis? AS-4.4.1 70. Apakah administrator keamanan meninjau otorisasi akses user aplikasi untuk menghindari konflik kepentingan dan mendiskusikan otorisasi yang masih tanda tanya dengan pemilik? AS-4.4.2 71. Apakah pemilik secara periodik meninjau akses untuk mengidentifikasi konflik kepentingan dan apakah masih ada konflik kepentingan? AS-4.4.3 72. Apakah pemilik proses telah mengidentifikasi konflik kepentingan yang dapat eksis serta peranan dan user yang konflik? AS-4.5.1 73. Apakah kontrol monitoring terdokumentasi memuat koflik yang dimitigasi oleh kontrol? AS-4.5.2 74. Apakah manajemen telah mendokumentasikan bukti dari pengawasan yang efektif ? AS4.5.3 75. Apakah aplikasi memiliki fungsi kritis dan apa saja sumber daya TI (data dan program untuk aplikasi tersebut)? AS-5.1.1 76. Apakah telah dilakukan identifikasi dampak dari gangguan terhadap aplikasi? AS-5.1.2 77. Apakah ada prioritas perbaikan untuk membantu menentukan strategi perbaikan (recovery)? AS-5.1.3 78. Apakah file backup dari data aplikasi kunci dibuat? AS-5.2.1 79. Apakah program aplikasi yang eksis memiliki kopi dan dapat digunakan? AS-5.2.2 80. Apakah file backup dari data aplikasi dan program terlindungi untuk kondisi darurat? AS5.2.3 81. Apakah ada ada rencana darurat untuk aplikasi? AS-5.3.1 82. Apakah rencana darurat untuk aplikasi ini tergabung dalam DRP, kelangsungan bisnis dan business resumption plans? AS-5.3.2 83. Apakah operasi darurat menyediakan lingkungan kontrol yang efektif dengan membatasi dan mengawasi akses user untuk data aplikasi dan program, meliputi a. User teridentifikasi dan terautentikasi b. User secara tepat terototisasi sebelum melakukan transaksi sensitive c. Audit dan monitoring kemampuan beroperasi AS-5.3.3 84. Apakah rencana darurat aplikasi secara periodic diuji termasuk simulasi bencana? AS5.4.1

134
Universitas Indonesia

135

(lanjutan) 85. Apakah area berikut termasuk dalam rencana darurat? a. Perbaikan sistem dengan platform yang berbeda dari media backup b. Ada koordinasi antar tim perbaikan c. Konentivitas internal dan eksternal d. Kinerja sistem dengan perangkat alternative e. Restorasi operasi normal f. Prosedur pemberitahuan 5.4.2 86. Apakah hasil uji coba terdokumentasi dan dilaporkan sebagai pembelajaran dan diberikan ke manajamen senior? As-5.4.3 87. Apakah rencana darurat dan perjanjian yang berkaitan serta persiapan dapat disesuaikan untuk mengatasi kelemahan selama uji coba? AS-5.4.4 B. Kontrol Proses Bisnis 1. Apakah ada SOP tentang manajemen data? (strategi data transaksi, desain data, data definition, standar kualitas data, kepemilikan dan prosedur monitoring?Apabila ada apakah selalu ada evaluasi? BP-1.1.1 2. Apakah ada prosedur untuk menjamin semua input aplikasi telah terotorisasi, diterima untuk diproses, dan ada penanggung jawab? Dan apakah kekurangan dokumen asal/sumber atau file input telah diidentifikasi dan diinvestigasi? Beberapa prosedur umumnya terdiri dari: o Batch tota; o Sequence checking o Rekonsiliasi o Control total BP-1-2.1 3. Apakah prosedur yang diimplementasikan untuk akses kontrol bagi application input routines dan media input fisik (kosong dan lengkap) ? BP-1.3 4. Apakah prosedur yang telah disetujui untuk memvalidasi data input sebelum masuk dalam sistem terdokumentasi?Apakah prosedur persetujuan diikuti untuk input data? BP1.4.1 5. Aopakah edit yang tepat digunakan untuk memastikan data valid dan terekam dalam format yang benar? Meliputi: a. Otorisasi atau kode yang disetujui b. Kontrol format field c. Kontrol field yang diperlukan d. Pembatasan e. Kombinasi yang valid dari nilai dield data yang berkaitan f. Cek kisaran g. Akurasi matematis h. Pencocokan file master i. Kontrol proses duplikat j. Balancing control BP-1.5.1 6. Apakah perubahan dan validasi override dibatasi untuk user tertentu? Apakah ada prosedur untuk memonitor override dan memasukkannya dalam log? BP-1.5.2 7. Apakah prosedur pemeliharaan tabel termasuk edit dan kontrol validasi membantu memastikan perubahan yang dibuat pada tabel data? BP-1.5.3 8. Apakah parameter dan toleransi yang dikonfigurasi dan kondisi error dan pesan telah didefinisikan dan ditinjau oleh manajemen? BP-1.6.1 9. Apakah prosedur telah disusun untuk memastikan bahwa semua input dalam aplikasi telah diterima untuk diproses dan dicek kebenarannya? Dan semua yang kurang dari dokumen sumber telah diidentifikasikan dan diinvestigasi? BP-1.7.1 10. Apakah kesalahan input data teridentifikasi dan dilaporkan serta diperbaiki untuk dimasukkan kembali? BP-1.8.1 11. Apakah aplikasi memproses data yang masuk secara otomatis dam standar?Apakah dokumentasi desain proses yang eksis ada untuk memvalidasi dan tujuan kontrol

135
Universitas Indonesia

136

12.

13. 14. 15.

16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30.

31.

32. 33. 34. 35.

36. 37. 38. 39. 40. 41.

(lanjutan) perubahan? Apakah versi yang digunakan dalam aplikasi, data dan file merupakan yang terbaru?BP-2.1.1 Apakah sistem memiliki log transaksi untuk memastikan seluruh transaksi terproses dengan baik? Apakah sistem dapat mengidentifikasi transaksi yang tidak komplit? BP2.2.1 Apakah ada prosedur untuk mengidentifikasi dan meninjau eksekusi transaksi yang tidak komplit, menganalisasnya dan mengambil langkah yang tepat?BP-2.2.2 Apakah prosedur eksis untuk monitor overrides dalam proses transaksi? BP-2.2.3 Apakah ada dokumen yang memproses dan menjelaskan kondisi (parameter dan toleransi) yang dikonfigurasi, termasuk kesalahan sistem dan aksi jika kondisi tersebut tidak terpenuhi? BP-2.3.1 Apakah manajemen meninjau secara regular pembatasan untuk memvalidasi keakuratan? BP-2.3.2 Apakah aplikasi menampilkan edit secara online dan cek validasi data yang sedang diproses?BP-2.4.1 Apakah prosedur sistem memberikan pesan kesalahan atau warning? BP-2.4.2 Apakah transaksi yang salah ditolak atau didiamkan hingga diperbaiki? BP-2.4.3 Apakah aplikasi mengkomunikasikan kesalahan pemrosesan pada user secara online atau melalui laporan exception? BP-2.4.4 Apakah transaksi terotorisasi? BP-2.5.1 Apakah ada rekonsiliasi secara periodic dan exception ditangani secara tepat? BP-2.6.1 Apakah kebijakan dan prosedur untuk pemrosesan oleh user terimplementasi? BP-2.7.1 Apakah kontrol pemrosesan oleh user cukup memenuhi? BP-2.7.2 Apakah manajemen mengimplementasikan kontrol yang cukup untuk melindungi data yang penting selama pemrosesan? BP-2.8.1 Apakah manajemen memiliki prosedur untuk rekonsiliasi input data dengan data yang diperoses aplikasi? BP-2.9.1 Apakah ada monitoring prosedur untuk mengetahui data yang ditambahkan atau dimodifikasi selama proses? Apakah log audit sistem ditinjau untuk exception? BP-2.9.2 Apakah manajemen memelihara log proses dan log itu di-review untuk aktivitas yang tidak biasa dan tidak terotorisasi? BP-2.9.3 Apakah prosedur eksis untuk memonitor override pada transaksi, termasuk pemeliharaan override log? BP-2.9.4 Apakah manajemen telah mengembangkan strategi pelaporan yang meliputi? a. Konten dan ketersediaan yang konsisten dengan kebutuhan user b. Data sensistif dan konfiden (penting) c. Akses user untuk data output BP-3.1.1 Apakah manajemen memiliki prosedur untuk memastikan konten dan ketersediaan output dan data konsisten dengan kebutuhan user, aturan sensitivitas dan kepentingan data juga akses user yang valid? BP-3.2.1 Apakah manajemen memiliki prosedur untuk memonitor replikasi data output yang digunakan dalam laporan manajemen atau media lain di luar organisasi? BP-3.2.2 Apakah akses user untuk data output selaras dengan peran user dan kepentingan/sensistivitas informasi? BP-3.2.3 Apakah manajemen memiliki laporan utama untuk menelusuri hasil proses? BP-3.3.1 Apakah manajemen telah mendokumentasikan prosedur: a. Meninjau hasil proses yang diaplikasikan b. Monitor override transaksi, termasuk pemeliharaan override log? BP-3.3.2 Apakah prosedur digunakan untuk meninjau data output kritis atau laporan kontrol? BP3.3.3 Apakah laporan output untuk kepatuhan dengan hukum dan regulasi akurat dan lengkap? BP-3.4.1 Apakah akses untuk laporan terbatas bagi user? BP-3.5.1 Apakah user memiliki tingkatan akses untuk membaca laporan?BP-3.5.2 Apakah semua entri terisi? BP-4.1.1 Apakah nilai null atau invalid tidak diterima? BP-1.4.2

136
Universitas Indonesia

137

(lanjutan) 42. Untuk aplikasi financia, apakah akun aset, utang terdefinisi dengan jelas? BP-4.1.3 43. Apakah kebijakan dan prosedur disusun untuk manajemen konfigurasi data master dimana memuat aturan perubahan yang menjelaskan field data yang tetap? BP-4.2.1 44. Apakah perubahan pada desain data master disetujui oleh personel yang tepat? BP-4.2.2 45. Apakah perubahan rekaman data master dibatasi untuk non-key-field? BP-4.2.3 46. Apakah data master ditinjau periodic, penggandaan teridentifikasi dan dihilangkan, serta data yang tidak digunakan diblok? BP-4.3.1 47. Apakah ada kontrol yang otomatis memberitahukan jika ada duplikasi perekaman? BP4.3.2 48. Apakah kebijakan dan prosedur untuk pemeliharaan data master terdokumentasi dan meliputi: a. Persyaratan persetujuan b. Kriteria kualitas data c. Kepemilikan data d. Dokumen pendukung e. Prosedur back up saat bencana atau data korup f. Kebijakan arsip BP-4.4.1 49. Apakah proses pemeliharaan data meliputi permintaan perubahan format dan disetujui pemilik data? BP-4.4.2 50. Apakah konflik kepentingan diatasi sebelum memberikan akses untuk transaksi data master? BP-4.4.3 51. Laporan edit ditinjau oleh pemilik data secara periodic untuk meninjau data master baru dan perubahan pada data master yang eksis? BP-4.4.4 52. Apakah ada prosedur rekonsiliasi secara periodic untuk memastikan data konsisten antara modul aplikasi yang berbeda? BP-4.5.1 53. Apakah kebijakan dan prosedur data master membutuhkan pemilik data untuk membuat, menghapus dan mengubah data master serta perubahan lainnya? Bp-4.6.1 54. Apakah pemilik data memonitor perubahan desain data master dan menyetujui serta memonitor perubahan secara periodic? Bp-4.6.2 55. Apakah manajemen mengimplementasikan kontrol yang cukup untuk melindungi data master yang penting? BP-4.7.1 C. Interface 1. Apakah ada strategi interface (antarmuka) untuk tiap-tiap antarmuka yang meliputi metode antarmuka, data field, kontrol untuk memastikan kelengkapan dan akurasi antarmuka, jadwal, penanggung jawab, system balancing requirements, dan kebutuhan keamanan IN-1.1 2. Apakah ada desain antarmuka untuk tiap-tiap antarmuka yang meliputi spesifikasi yang tepat berdasarkan kebutuhan bisnis, terdiri dari validasi dan perubahan; kepemilikan proses antarmuka; metode komunikasi dan koreksi kesalahan IN-1.2.1 3. Apakah ada tabel pemetaan yang digunakan untuk mengkonversi data dari sistem sumber? Apakah ada kontrol untuk memastikan tabel pemetaan hanya berubah ketika ada otorisasi dan data historis tetap tersimpan dengan tabel pemetaan sebelumnya? IN-1.2.2 4. Apabila tabel pemetaan tidak digunakan, apakah perubahan dan validasi ada di sistem sumber/asal? IN-1-2.3 5. Apakah prosedur yang ada memiliki daftar yang lengkap tentang cara berjalan antarmuka, waktu proses antarmuka, bagaimana prosesnya dan bagaimana rekonsiliasi? Jika interkoneksi sistem digunakan, apakah prosedur memenuhi kebutuhan untuk perjanjian interkoneksi keamanan dan MoU? Apakah waktu proses antarmuka ditentukan dan diikuti? Apakah ada pemberitahuan untuk memastikan file terkirim dari sistem sumber/asal ke sistem target?(ada handshake sehingga file tidak hilang) IN-2-1.1 6. Apakah ada orang yang ditugaskan untuk proses antarmuka dan koreksi kesalahan dan apakah tercatat? Jika antarmuka melibatkan media elektronis, adakah melibatkan staf teknis khusus? IN-22.1

137
Universitas Indonesia

138

7.

8. 9. 10. 11. 12. 13. 14.

(lanjutan) Apakah file-file yang dihasilkan dari aplikasi antarmuka (sumber dan target) aman dari akses/modifikasi yang tidak terotorisasi ? Apakah ada keamanan antarmuka dan petugas yang ditunjuk? IN-2-2.2 Apakah user yang memproses antarmuka dapat memonitor status antarmuka tersebut? IN2-2.3 Apakah rekonsiliasi dilakukan antara aplikasi sumber dan target untuk memastikan antarmuka lengkap dan akurat? (lihat laporan rekonsiliasi) IN-2-3.1 Apakah ada log untuk proses antarmuka seperti error dan exception? Apakah laporan ini dievaluasi oleh manajemen? IN-2-4.1 Apakah ada fasilitas koreksi dan kesalahan digunakan untuk menelusuri koreksi kesalahan dalam data antarmuka? IN-2-5.1 Apakah ada mekanisme untuk memberitahu user apabila data ditolak? Pesan ini berulang kali muncul hingga data dikoreksi IN-2-5.2 Apakah ada audit trail untuk mengidentifikasi dan mem-follow up kesalahan antarmuka? IN-2-5.3 Apakah file antarmuka secara otomatis terarsip atau terhapus dari lingkungan produksi setelah diproses? IN-2-6.1

D. Data 1. Bagaimana desain dan strategi sistem manajemen data di Taspen? 2. Apakah Taspen menerapkan kriptografi untuk kemanan data peserta?DA-1.1.1 3. Apakah ada pemisahan antara data produksi dan data non produksi (untuk testing dan pengembangan)?DA-1.1.2 4. Apakah database schema konsisten dengan kontrol akses? DA-1.1.3 5. Adakah pembatasan akses dan pembedaan grup untuk mengakses? Kalau ya, sebutkan. DA-1.1.3 6. Apakah ada sistem logging setiap ada aktivitas di sistem manajemen data maupun di database? DA-1.2.1 7. Apakah ada kontrol yang secara real time memberitahukan apabila ada aktivitas abnormal? DA-1.2.2 8. Apakah ada kontrol apabila data yang dimasukkan tidak valid dan tidak komplet? DA1.3.1? 9. Apakah data dari sistem ini sebelum digunakan sistem lain telah melalui verifikasi? DA1.3.1? 10. Apakah ada kontrol untuk membatasi akses dalam mengkonfigurasi sistem ini?DA-1.3-2

138
Universitas Indonesia

139

LAMPIRAN 2: DAFTAR PERTANYAAN TAMBAHAN


Draft pertanyaan ini dilakukan kepada staf bagian data di Divisi Pelayanan untuk mengetahui proses di lapangan. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. Apa saja jenis data peserta di Taspen Siapa saja penyedia data Taspen? Siapa sajakah yang mengakses aplikasi manajemen data?(staf/atasan) Berapa jumlah SDM administrasi data di tiap-tiap KCU/KC? Siapakah yang memberikan akun/login? Apa saja jenis aksesnya ? (misal user, admin, super admin) Apakah login tersebut dicatat oleh kantor pusat atau diadministrasikan di tiap-tiap kantor cabang? Apakah login karyawan yang sudah mutasi/pensiun dihapuskan atau masih ada di database? Apakah administrasi login dievaluasi oleh bagian data? Apa saja jenis aplikasi untuk manajemen data? Modul untuk ACB manajemen data apa saja? Siapa saja yang menginput/mengupdate data peserta? Apakah mereka ditraining terlebih dahulu sebelum menjadi staf data? Apakah mereka memiliki panduan untuk mengisi/mengupdate data? Bagaimana jika mereka mengalami kesulitan ketika menginput data? Bagaimana cara mengetahui ada kesalahan antara database Taspen dan database peserta?...(B2) Kapan dilakukan? Bagaimana cara mengetahui ada kesalahan antara database sumber dengan database yang dimasukkan? Kapan dilakukan? Apa penyebab kesalahan penginputan data? Apakah akar permasalahannya dicatat, ditelusuri dan dicari solusinya? Apakah data yang akan diinputkan divalidasi terlebih dahulu sebelum dimasukkan ke database Taspen? PNSP atau PNS DO Apakah ada warning jika isian inputan belum lengkap? Apakah nilai null diperbolehkan? Apakah ada kontrol format tiap field? Misal untuk NIK harus 13 digit Apakah sistem otomatis keluar bila user gagal login selama tiga kali? Apakah user bisa melakukan reset password bila ia lupa password? Jika tidak, bagaimana caranya? Berapa lama kira-kira prosesnya? Apakah ada pesan apabila user melakukan duplikasi/menginput lebih dari sekali? Apakah perubahan data master bisa dilakukan? Dan apakah bisa semua field atau yang selain key field? Misal NIK tidak bisa diubah Apabila ada penghapusan atau perubahan data master, harus ada surat pengajuan? Apakah data yang telah inaktif disimpan atau dimusnahkan? (Pensiun punah) Apakah ada log transaksi di sistem? Misal user menambahkan atau mengupdate transaksi? (B12) Apakah logging itu dievaluasi oleh bagian data? Apabila ada versi terbaru dari aplikasi apakah diujicoba dulu oleh orang data? Bagaimana sosialisasinya ke cabang-cabang? Apakah warning/pesan/kontrol penginputan itu dikaji oleh orang data bekerja sama dengan TI? Dan apakah dilakukan evaluasi? Apakah ada evaluasi sistem oleh orang data? Siapa saja yang bisa mengakses laporan data? Apakah ada tingkatan akses untuk membaca laporan? Apakah pernah ada transaksi yang mencurigakan? Apakah pernah ada pelanggaran hukum yang terkait dengan kerugian keuangan?

139
Universitas Indonesia

140

LAMPIRAN 3: HASIL TRANSKRIP WAWANCARA


Wawancara I Narasumber Tempat : Waktu

Yuwono Basuki (Manajer Utama Divisi Pelayanan), Ibram Jaya Putra (Manajer Data) Ruang Manajer Utama Divisi Pelayanan 15 Maret 2010, pukul 08.00 09.15 WIB

Untuk input data peserta, Taspen bekerja sama dengan pihak mana saja? Yuwono Data peserta ada dua yaitu PNS Pusat dan PNS Daerah Otonom (DO). Untuk PNS pusat, Taspen bekerja sama dengan Direktorat Jenderal Perbendaharaan Negara (DJPBN). Dirjen ini membawahi 178 Kantor Pelayanan Perbendaharaan Negara (KPPN) yang tersebar di seluruh Indonesia. Melalui KPPN inilah kantor-kantor cabang Taspen berinteraksi untuk melakukan rekonsiliasi data berdasarkan soft copy daftar gaji tiap bulan. Sedangkan untuk PNS DO, Taspen bekerja sama dengan pemerintah daerah setempat dan Direktorat Sistem Perbendaharaan yang juga di bawah DJPBN. Kondisi eksis yaitu tiap Pemda memberikan data gaji PNS DO dua kali dalam setahun bergantung pada lokasi tiap-tiap Pemda. Apakah Taspen juga bekerja sama dengan Badan Kepegawaian Negara untuk peremajaan data? Ibram BKN dan Taspen juga bekerja sama dalam peremajaan data, seperti input CPNS dan statusnya. Taspen mengambil data ke BKN tiap triwulanan. Biasanya kesenjangan data antara BKN dan Taspen adalah tidak ada record karena CPNS belum didaftarkan sebagai peserta Taspen. Bagaimana metode pengelolaan dan pengolahan data peserta agar data tersebut reliable, akurat, tepat waktu dan terintegrasi? Yuwono Agar kualitas data semakin baik dan deviasi data semakin menurun, Taspen melakukan koordinasi dan sosialisasi dengan KPPN. Hingga saat ini telah tiga kantor cabang utama yang selesai melakukan rakor, yaitu wilayah KCU Makassar, KCU Medan, dan KCU Semarang. Yang belum tinggal wilayah KCU Bandung, KCU Jakarta, dan KCU Surabaya. Ibram Setelah dilakukan pencocokan data milik di tiga wilayah KCU Taspen dan KPPN, deviasi menurun. Jika toleransi deviasi Taspen ditetapkan 5 persen maka hingga saat ini telah tercapai tiga persen. Suatu hal yang membanggakan mengingat sifat data PNS Pusat yang dinamis, karena mobilitasnya tinggi. Karena itu sulit sekali mencapai 100 persen. Yuwono Sedangkan untuk PNS DO, saat ini Direktorat Sistem Perbendaharaan tengah mengembangkan aplikasi database yang nantinya akan dibagikan secara cuma-cuma ke tiap Pemda. Dengan adanya aplikasi ini nantinya semua atribut menjadi standar dan memudahkan matching data milik Pemda dan Taspen. Targetnya Bulan April 2010 mulai diimplementasikan.

Ibram Saat ini untuk mengetahui kualitas data tiap kantor cabang, kami melakukan monitoring. Istilahnya rapor tiap bulan. Di situ disebutkan tingkat validitas data tiap-tiap cabang dan peringkat validitas data tiap-tiap kantor cabang. Untuk PNS DO kami klasifikasikan perolehan data peserta menjadi tiga, mudah, sulit dan sangat sulit. Ini biar lebih fair. Memang belum ada reward dan punishment bagi kantor cabang yang peringkatnya paling tinggi dan yang peringkatnya paling rendah. Penilaiannya hanya ada di sistem manajemen kinerja bagi mereka yang memasukkan indikator pencapaian ini di tugas pokoknya. Punishment nyata mungkin beban moral saja, mengapa kantor cabang lain bisa, mereka tidak bisa.

140
Universitas Indonesia

141

(lanjutan) Bagaimana model arsitektur database peserta Taspen saat ini? Ibram Saat ini Taspen menggunakan sistem database terdistribusi. Server database ada di tiap-tiap kantor cabang utama. Data yang ada di kantor cabang utama ini setiap akhir bulan dilakukan cut off dan di-back up ke kantor pusat. Jadi belum dilakukan replikasi secara otomatis. Kekurangan sistem ini yaitu database di kantor pusat tidak terbaru dan masih ditemui data-data invalid dari kantor cabang. Rencananya akan diimplementasikan sistem database tersentral. Untuk menuju ke sana, akan dilakukan database terdistribusi dengan sistem replikasi, sehingga kondisi database di kantor pusat sama dengan di kantor cabang. Pilot project-nya yaitu di Taspen Cabang Utama Semarang. Sekarang masih dilakukan pembersihan data. Setelah tahap tersebut selesai akan dilakukan implementasi sistem replikasi. Apabila KCU Semarang sukses akan dilanjutkan lima KCU lainnya. Setelah semua KCU telah mengimplementasikan sistem replikasi, nantinya akan dilakukan database tersentralisasi. Server database hanya ada satu di kantor pusat dan satu backup di DRP yang akan dibangun. Wawancara II : Narasumber Jabatan Tanggal Tempat

: Sopian : Manajer Aplikasi Bisnis Inti/Core Business) : 20 April 2010 (pukul 09.00-10.00 WIB) : Ruang Manajer Aplikasi Bisnis Inti Taspen Kantor Pusat Blok A Lantai 3.

JAD mulai go live tahun berapa? Go live-nya bertahap, mulai tahun 2005-2007. Yang pertama pada bulan September 2005 di dua kantor cabang, KCU Semarang dan KC Jogja. Berlanjut, hingga terakhir di wilayah KCU Medan dan Makassar pada 12 April 2007 Sebelumnya pakai apa Pak? Sebelum pake recital.modelnya text file, bukan GUI. Latar belakang apa dari Recital berganti ke JAD? Teknologi recital zaman itu sudah dianggap ketinggalan. Apa sudah nggak bisa dikembangkan lagi aplikasinya? Saya kurang tahu persis, di satu sisi, vendor perwakilannya di Indonesia sudah nggak ada. Jadi kalau ada sesuatu permsalahan sudah tidak bisa membantu. Bagaimana proses membuat aplikasi JAD? Disebut JAD karena pembuatannya bekerja sama dengan konsultan. Nama resminya adalah aplikasi core business. Bagaimana proses merancang database saat itu? Rancang database bareng-bareng dengan konsultan. Konsultan yang lebih tahu desain database, sedangkan dari sisi Taspen yang lebih tahu proses bisnisnya. Dari segi tampilan bagaimana Pak? Kebanyakan orang Taspen, karena orang konsultan hanya meng-guide. Database, rancangannya memakai apa DFD atau apa, Pak? Konsultan, Pak Herlan, dulu menggunakan Bachman. Namun, software-nya cuma ada di komputer dia, dan dia tidak memiliki installer-nya. Lalu maintence database-nya gimana Pak? Sebenarnya desain tersebut bisa diakses database lain, itu desain awalnya saja. Schema databasenya di sana, hubungannya per tabel seperti apa juga ada di sana.

141
Universitas Indonesia

142

(lanjutan) Untuk database, programming dan servernya sendiri menggunakan apa Pak untuk aplikasi ini? Programming-nya menggunakan Visual Age Smaltalk. Database-nya menggunakan DB2. Servernya di masing-masing KCU menggunakan IBM AS400 p Series.. Kalau misalkan kita perlu laporan Kantor Cabang Jogja maka prosenya bagaimana Pak? Di kantor pusat database-nya tidak ada, maka harus lari dulu ke database kantor cabang utama Semarang. Tapi sekarang database di kantor pusat ada, dengan mulai diadakannya server replikasi, sehingga data di KCU Semarang, yang menjadi pilot project sistem replikasi ini, ada di kantor pusat juga. Ini yang sekarang dinamakan sistem database konsolidasi. Kalau misalkan ada mutasi pegawai dari malang maka entrinya langsung ke kantor cabang utama Surabaya? Ya, karena server ada di tiap KCU. Secara real time atau batch? Kalau dari sananya sih real time. Tapi perpindahan data dari KCU ke kantor pusat ada jadwalnya nantinya, apabila replikasi sudah diterapkan ke semua KCU. Bagaimana database KCU Semarang setelah go live? Apa yang di sana berubah,di sini langsung berubah. Apakah ada perubahan proses bisnis? Tidak ada, itu kan cuma me-link-kan database KCU Semarang dengan di sini. Jadi bila di sana dihapus maka di sini juga dihapus. Tapi Bapak bilang tidak real time ya? Iya sekarang masih terjadwal, nanti kami evaluasi, apakah tetap terjadwal atau real time. Itu cuma perubahan setting pada level database, mau real time atau batch. Kita memerlukan bandwith berapa, rata-rata transaksi per hari berapa, perlu pengkajian karena ada tujuh database dari tujuh KCU. Struktur organisasi TI secara khusus di tempat Bapak bagaimana? Secara struktur tidak punya bawahan. Bawahan cuma pelaksana. Tapi secara fungsi, saya mengkoordinasi para fungsional. Secara khusus saya belum menerapkan fungsi-fungsi secara khusus. Seseorang khusus menangani ini. Semua harus memahami. Jadi kalau ada permasalahan di kantor cabang, semua harus bisa melakukan perbaikan dan analisa. Di sini pelaksananya ada sembilan. Desi, Tatan, Doso, Frans, Hanik, Diana, Natasha, Mundiyati, dan Harmadi. SOP manajemen database ada nggak Pak?Cara input dll? Tata kerjanya ada di pelayanan karena yang punya sistem adalah pelayanan. Desain database peserta sudah didokumentasikan? Ada yang dipajang di sini, tapi buku khusus atau dokumentasi secara hardcopy belum dilakukan. Kalau ada perubahan? Misal user minta penambahan kolom baru? Kalau user pendekatannya tidak seperti itu, hanya minta sesuai kebutuhan, kita yang menjabarkan apakah kita cukup menggunakan informasi yang sudah ada tanpa mengubah struktur, tabel misalnya. Tapi kalau harus untuk menambahkan satu kolom, ya terpaksa melakukan perubahan. Daftar tabel dan isi serta fungsinya kami sudah punya, tapi link-nya antar tabel satu dengan tabel lainnya belum ada. Skemanya belum ada. Kalau ada perubahan, baru daftar ini di-update. Admin database-nya siapa Pak? Semua berfungsi jadi admin. Loginnya satu atau bagaimana Pak? Ya satu, menggunakan login super user. Di sini yang menurut saya agak berbahaya.

142
Universitas Indonesia

143

(lanjutan) Kalau di sini ada logging tentang aktivitas pengguna Pak? Di sini ada, siapa mengerjakan apa itu tercatat. Namun di DB2 ini saya susah melakukan trace untuk penghapusan karena secara fisik hilang. Sementara dulu ketika menggunakan Recital atau Fox Pro, database secara fisik masih ada, hanya status atau kodenya berbeda. Baru setelah melakukan perintah tertentu maka benar-benar hilang. Di DB2 ini langsung hilang. Mungkin bisa dilihat dengan log file yang berbetuk text. Akses untuk database apa saja Pak? Kalau super user bisa semuanya, ia memegang root. Setelah itu baru user biasa. Kalau di cabang, petugas input levelnya apa Pak? Dia punya user masing-masing, nggak ada akun bersama. Kalau dari sisi user, semua user. Tapi di cabang ada pejabat yang menentukan hak akses, si A bisa sampai ke menu mana aja. Pejabat punya login sendiri dan punya wewenang untuk memilah-milah hak akses bagi para bawahannya. Tidak ada istilahnya, seperti admin gitu. Dia user biasa yang punya kelebihan. Kita delegasikan ke cabang, kita malah nggak tahu orang ini punya hak akses apa saja. Laporan keluhan ada Pak? Cabang ini tidak bisa ngentri atau bagaimana? Laporannya sebenarnya sudah kita rancang, namun belum berjalan dengan baik. Rencananya nanti ada sistem help desk agar tercatat. JAD modul peserta itu hubungannya dengan modul apa saja Pak? Semuanya di kantor cabang berkaitan, seperti modul hasil perhitungan klim menjadi dasar pembayaran di keuangan. Waktu UAT bagaimana Pak?masih ada bug atau error kah? UAT kami lakukan,. Error masih ada saat itu. Program develop sendiri itu sih never ending. Kalau sistem keamanan aplikasi bagaimana Pak? Selain menggunakan hak akses? Apakah ada enkripsi? Saya kurang tahu. Enkripsi seharusnya ada, kan riskan jika tidak ada. Saya terus terang tidak tahu persis, coba nanti tanya Pak Suryanto atau Pak Indra Cahya. Selain menggunakan desktop, aplikasi ini apakah bisa diakses melalui VPN? Bisa. Developer diberi fasilitas sehingga bebannya masuk beban kantor. Kalau saya lebih sering menggunakan telepon daripada modem. Akunnya untuk VPN masing-masing, didaftar, jadi bisa mengerjakan di rumah dengan menggunakan laptop. Di sini saya lihat sudah tidak ada desktop melainkan laptop, apakah aplikasinya di-install ke laptop masing-masing? Secara fisik di-install tapi kode program nya ada di server, kita melakukan link dulu ke sana. Apabila misalkan saya berlaku jahat dan mencuri laptop Bapak serta mengetahui password Bapak, itu berarti tidak aman? Ya, itu sudah tidak aman. Baru masalah. Pak apakah di Taspen sudah tersertifikasi ISO 27001 tentang keamanan? Belum. Rencananya menggunakan security policy yang dibuat sendiri menggunakan standar internasional. Sudah dibuat SK-nya. Namun, kita tidak bersertifikasi. Permasalahan apa yang selama ini yang masih sering dikeluhkan user? Lambat itu saja. Banyak faktor penyebabnya bukan hanya permasalahan bandwith. Bisa juga terjadi karena virus. Virus di cabang cukup signifikan.

143
Universitas Indonesia

144

(lanjutan) Di komputernya apakah tidak ada antivirus? Ada, namun sudah kadaluarsa tidak di update. Untuk saat ini penanganan virus belum terpusat, baru di tingkat kesadaran masing-masing untuk meng-update-nya. Farm server di tengah ruangan itu ya Pak? Bagaimana sistem keamanannya? Ada, dengan password. Namun, belum ada satpam. Kalau misalkan di Jakarta atau KCU gempa bumi, bagaimana Pak dengan server database dan server aplikasinya? Ya berakhir. Sebab, Taspen belum memiliki DRC. Sementara replikasi masih dijalankan untuk KCU Semarang. Untuk KCU Semarang jika ada crash maka datanya masih ada di kantor pusat, hanya beda sehari karena jadwal replikasinya sore hari. Bukannya DRC sudah ada dalam IT Plan? Saat ini manajemen masih beranggapan DRC itu suatu pemborosan. Kalau idle, memang tidak ada fungsinya. Namun, jika suatu saat terjadi crash maka akan sangat bermanfaat. Bagaimana dengan manajemen back up-nya Pak? Back up-nya tiap hari. Pakai media tape dan hard disk. Sekarang saya akan bertanya dengan menggunakan daftar pertanyaan dalam FISCAM. Pertanyaan pertama berkisar tentang desain database dan strategi manajemen database? Ada tidak Pak? Kalau untuk desain sudah ada, tapi stratego manajemen database Divisi TI belum ada, mungkin di Divisi Pelayanan. Hal ini bergantung pada kebutuhan user, inginnya seperti apa. Dari situlah kami bisa melakukan kajian apa yang harus dilakukan. Bagaimana dengan kriptografi? Seperti enkripsi, public key infrastruktur? Kalau di programming nggak ada. Belum tahu untuk transmit data. Asumsi saya seharusnya ada. Adakah pemisahan antara database produksi dan nonproduksi? Ada Apakah ada kontrol akses? Ya, tapi untuk admin digunakan akun bersama. Apakah ada pembatasan akses dan pembedaan grup? Ada, ada grup admin. Apakah sistem logging ada di aplikasi maupun di database? Ada, kalau untuk baca saja tidak tercatat, tapi untuk update tercatat? Apakah ada kontrol yang secara real time memberitahukan jika ada pelanggaran? Tidak ada di sisi aplikasi. Apakah muncul warning jika data yang dimasukkan tidak valid? Ada, bentuknya seperti alert dan message. Apakah data ini telah valid sebelum masuk ke aplikasi lainnya? Sudah. Apakah berlaku sistem bypass/exception? Tidak ada.

144
Universitas Indonesia

145

(lanjutan) Aplikasi kan termasuk aset, apakah ada yang pernyataan bahwa aplikasi ACB itu merupakan aset? Ya Level risiko, apakah aplikasi ini termasuk risiko tinggi atau bagaimana? Divisi Renbang pernah melakukan kajian ini. Kalau pemilik aplikasinya, siapa Pak? Kalau secara aplikasi itu Divisi TI, tapi pemilik sistemnya Divisi Pelayanan. Adakah orang yang bertanggung jawab terhadap keamanan aplikasi? Belum ada. Adakah Interkoneksi aplikasi? Ada. Deskripsi semua kontrol, misal kontrol input. Apakah didokumentasikan? Validitas ada di aplikasi, dokumentasi atas kesahihan data ada di Divisi Pelayanan. Tapi dokumentasi atas kontrol aplikasi belum ada. Desain keamanan, proses upgrade, adakah? Coba tanya Pak Suryanto. Apakah ada kontrol hak akses untuk transaksi sensitif? Ada. Apakah ada pemisahan tugas? Tidak. Apakah pernah ada dokumentasi ujicoba keamanan aplikasi? Belum ada secara khusus, tapi ada untuk level organisasi. Bagaimana untuk perubahan jika ada kondisi darurat, apakah langsung ke sistem produksi dan ada prosedurnya? Belum pernah dilakukan, tapi seharusnya nantinya tertuang ada di DRP. Apakah ada ketentuan tentang parameter sistem? Sebenarnya masih meraba-raba, apakah setting parameter sudah benar atau belum. Kalau untuk database, setting parameter-nya menurut saya masih belum ideal, performance-nya belum optimal. Jika kondisi darurat, kontrol aksesnya seperti apa? Mungkin seperti kasus Padang kemarin. Tidak ada bypass, prosedur berjalan seperti biasa. Cuma dari sisi jaringan. Dari Lintasartha berpindah ke Telkom. Apakah ada pendefinisian akun sensitif? Tidak Apakah ada laporan pernah ada penyusup dan dilakukan evaluasi? Coba tanya ke Pak Indra. Apakah Divisi Pelayanan sebagai pemilik proses mengetahui level risiko aplikasi? Ya, tapi belum ada DRP. Apakah ada kebijakan dan prosedur tentang keamanan? Ada

145
Universitas Indonesia

146

(lanjutan) Apakah Divisi TI sudah menyampaikan ke Divisi Pelayanan tentang kebijakan keamanan? Dari sisi ini cuma menyampaikan UAT. Apakah user pernah diberi training tentang keamanan? Kalau training keamanan belum, tapi training lebih ke fungsi aplikasi. Apalah ada kebijakan seperti perubahan password? Kalau hal ini belum dikomunikasikan ke user, tapi dokumentasinya ada.

Wawancara III : Narasumber : Sopian Jabatan : Manajer Aplikasi Bisnis Inti/Core Business) Tanggal : 23 April 2010 (pukul 09.00-10.00 WIB) Tempat : Ruang Manajer Aplikasi Bisnis Inti Taspen Kantor Pusat Blok A Lantai 3. Interface (Antamuka) Bagaimana strategi pengisian field? Sudah sesuaikah antara kebutuhan user dan interface? User yang menyatakan itu sudah sesuai kebutuhan atau tidak. Sepertinya sudah. Dokumennya ada kan Pak tentang desain interface waktu itu? Nggak ada waktu itu, langsung membuat. Karena waktu membangun diburu oleh waktu. Setelah jadi baru didokumentasikan. Belajarnya saja hanya dua minggu dan jadinya empat bulan, tanpa tidur. Kerjanya sampai jam 2-3 pagi. Menginap di kantor. Waktu itu timnya sekitar 10 dari kantor pusat dan 4 orang dari kantor cabang. Proses antarmuka seperti apa?Metode komunikasinya seperti apa?Apakah didokumentasikan perpindahan interface? Ada di buku petunjuk. Bagaimana dengan tabel pemetaan aplikasi? Missal kita kerja sama dengan Pemda, mereka punya kode tersendiri lalu kita terjemahkan sesuai dengan kebutuhan aplikasi. Kalau seperti itu ada, dan didokumentasikan. Bagaimana dengan log? Yang sifatnya historis seperti nama tidak kita historiskan karena sifatnya permanen. Model tabelnya itu ada Pak? Ada, konversi dari kolom ini menuju ini. Cara berjalan interface ada berapa lama perpindahannya? Pernah diukur? Belum pernah diukur. Dari window ke window sih cepat, tapi yang jadi masalah itu bila melakukan proses, link ke database-nya. Perhitungan rata-ratanya? Belum, mungkin bisa diukur sendiri dengan melihat proses di bawah, mulai awal sampai selesai. Standar antarmuka? Belum ada. Filenya itu dari satu modul maka pindah ke modul lain, apakah sudah ada kepastian datanya sudah diterima?tidak sampai datanya hilang? Seharusnya sudah. Tapi dari sisi proses, misal klim. Ada customer service, penelitian, DPP untuk updating-nya, perhitungan klim (PK), verifikasi dan PK untuk agenda, keuangan-cetak voucher, terakhir keuangan-kasir. Seharusnya ada urutan antar proses tersebut. Dia boleh mengerjakan ini

146
Universitas Indonesia

147

(lanjutan) setelah proses sebelumnya selesai. Namun ada satu kondisi, menurut saya itu kesalahan user, dia sudah sampai proses keuangan, tapi karena ada informasi yang salah maka dia kembalikan ke satu titik, setelah itu prose situ beku. Di keuangan tidak bisa dipanggil karena minimal prosesnya 6, tapi di situ cuma 3. Jadi seolah-olah transaksi tadi tidak ada. Jadi harus proses ulang lagi, ke 4,5,6. Masih dimungkinkan untuk proses bolak-balik, misal gapok salah, salah entri. Data yang mau siap cetak ada kepastian data selesai dikirim, seperti message untuk memastikan? Ya, ada. Apakah Bapak memiliki anak buah yang bertanggung jawab apabila terjadi perubahan antarmuka?Untuk dokumentasi, perubahan permintaan user untuk antarmuka? Prosesnya belum sempurna. Nantinya, jika ada permintaan user maka akan terpusat ke sistem help desk, selanjutnya manajer yang menentukan siapa yang mengerjakan dan berapa lama durasinya. Nanti ada admin help desk, keluhan ini maka akan lari kemana. Jika antarmuka melibatkan media elektronik apakah melibatkan staf teknis? Selain media komputer? Tidak ada selain media komputer. Aman dari akses yang tidak terotorisasi? Kalau dapat akun harus ada permintaan terlebih dulu ke KCU, ke bagian SI masing-masing. Untuk hak akses yang agak riskan, sejauh dia diberi hak akses oleh atasan maka dia bisa mengakses sesuai hak yang diberikan tersebut. Apakah di KCU punya daftar hak akses? Kalau hard copy tidak ada, tapi di sistem kelihatan. Siapapun, pejabat bisa melihatnya, user ini aksesnya sejauh mana. Misal Pak Rochim bisa masuk ke fungsi penelitian dll. Apa pernah ada akun yang aneh? Tidak bisa, karena kita yang meng-create akun. Apakah user dibatasi hanya bisa mengakses saat hari kerja atau bagaimana? Tidak, Sabtu Minggu pun juga bisa. Tidak dibatasi. Kan tercatat di log sistem. Kalau ada perubahan maka kelihatan. Apakah data sumber pernah dicocokkan dengan data hasil proses? Ya., yang kerja sama dengan Pemda. Setiap tiga bulan dilakukan rekon data. Kalau ada kesalahan-kesalahan, apakah ada log? Ada seperti kesalahan input. Untuk exception apakah ada di aplikasi ini Pak? Kalau itu bergantung pada proses bisnisnya. Tapi ada warning dulu, baru kemudian bisa jalan. Contohnya seperti ini proses pengajuan uang duka wafat. Orangnya sudah meninggal, maka tabel wafatnya terisi. Dengan demikian jika ada pengajuan atas nama orang ini maka sistem memberitahu, orang ini sudah wafat. Warning saja, tapi setelah itu bergantung user, dilanjutkan atau tidak. Lho kok bisa lanjut kalau kasusnya seperti itu? Itu menghasilkan suatu proses. Misal di DPP diisi tanggal wafat, terus berjalan. Ada sesuatu yang salah, lalu kembali karena orangnya wafat. Untuk peringatan saja. Usernya yang menentukan proses ini lanjut atau tidak, bukan otomatis oleh sistem. Pengisian field itu sudah ada pilihan, apa harus ngetik? Nama masih harus ngetik. Kalau kode-kode tidak.

147
Universitas Indonesia

148

(lanjutan) Pesan-pesan kesalahan ada ya Pak? Ada. Kalau penelusuran untuk kekonsistenan seperti pangkat dengan gaji pokok itu dilengkapi dengan kontrol warning. Mekanisme jika data ditolak, apakah warning-nya muncul terus sampai data diperbaiki? Tergantung, ada tiga kali pengisian, ada yang tidak dibatasi. Bergantung pada waktu orang itu bikin. Yang dibatasi terutama untuk penerimaan klim, sebanyak tiga kali langsung keluar. Apakah ada evaluasi sistem? Kita biasa memanggil orang cabang sebagai pengguna sistem seluruh KC untuk mewakili seluruh fungsi. Apa saja kendala yang dihadapinya?

Itu terdokumentasi ya Pak? Iya. Apakah bila satu proses selesai maka terarsip secara otomatis?ter-log? Kalau dihapus benarbenar dihapus? Ya, langsung terarsip. Kalau di DB2 kalau terhapus ya otomatis langsung terhapus. Kembali ke kontrol umum nomor 11. Apakah kontrol keamanan yang berhubungan dengan aplikasi utama diuji setahun sekali? Misalnya pura-pura nge-hack, ada orang yang memasukkan password bolak-balik? Belum pernah. Apakah frekuensi ujicoba sebanding dengan risiko aplikasi? Jawabannya juga belum. Apakah ada laporan tentang keamanan, login bolak-balik gagal? Kalau di aplikasi ini, loginnya tak terbatas. Tiga kali atau lebih tetap muncul. Tapi kalau tidak salah, aplikasi kalau sekali salah login maka tidak bisa jalan. Ada yang bisa proses, ada yang tidak bisa proses.Yang bisa itu proses evaluasi saja, bukan proses yang vital. Tapi laporannya untuk ujicoba keamanan atau ada penyusup di sini belum ada. Apabila ada kelemahan apakah ada proses untuk memperbaiki kelemahan? Belum. Tapi secara nonformal sudah ada, jadi kami kumpulkan para user di suatu formal, lalu di situ diungkapkan kendala atau kekurangan sistem lalu diperbaiki. Tapi bisa juga berdasarkan informasi user pada saat tertentu dan setelah kami analisis kami ada kesalahan, ya kami koreksi saat itu juga. Apakah manajemen menginisiasi perbaikan kelemahan? Ya. Langkah-langkahnya ada Pak, untuk memperbaiki kelemahan? Ada. Di saya ada, sebelum dan sesudah program diperbaiki itu didokumentasikan. Apakah kelemahan diperiksa oleh tools atau software lain? Belum ada. Apakah ada prosedur yang berkaitan dengan pihak ketiga? Kalau pihak ketiga seperti Pemda tidak bisa masuk ke sistem kita. Kalau KPPN, standar tabelnya sudah sesuai dengan tabel kita. Kalau dengan Pemda, kita perlu matching tabel dulu, karena modelnya bervariasi. Dengan software, kita lakukan matching data mana yang sesuai dan mana yang kurang. Yang kurang maka dilakukan konfirmasi. Kalau KPPN setiap bulan datanya bisa dikirim via e-mail. KPPN itu PNS Pusat, Kalau Pemda yang PNS DO. KPPN dan Pemda itu rekap

148
Universitas Indonesia

149

(lanjutan) daftar gaji. Kalau BKN itu berhubungan dengan PNS Pusat untuk membandingkan dengan pangkat, nama yang benar. Tapi data kita dengan BKN juga masih banyak selisih. Apakah akun vendor masih ada di aplikasi? Tidak ada, dulu menggunakan akun kita. Mereka tidak punya akun sendiri. Apakah aplikasi ACB telahmemiliki peringkat risiko? Belum. Apakah ada identifikasi user? Ada Apakah ada prosedur formal untuk pemberian hak akses? Ada, kalau di cabang user meminta akun ke SI di tiap KCU. Baru pejabat di kantor cabang masing-masing yang menentukan hak akses anak buahnya masing-masing. Kalau di kantor pusat ke Divisi TI langsung. Kalau di TI pakai super user. Kalau perubahan atau mereset password, prosesnya bagaimana Pak? Sudah ada di sistem.Kita imbau seringkali untuk mengubah password, tapi kewajiban mengubah password secara periodik belum ada. Kalau kehilangan password, prosesnya bagaimana? Kalau seperti itu, maka lapor ke Bagian Sistem Informasi di KCU. Diberi standarnya, maka yang bersangkutan diminta untuk mengubahnya sendiri. Apakah login terkunci bila gagal? Kalau untuk message belum ada, tapi secara proses menurut saya sudah terkunci. Kalau user mendiamkan aplikasi, apakah aplikasi kemudian meminta login lagi? Tidak. Tetap bisa digunakan. Apakah satu user hanya memiliki satu akun? Ya, pasti satu akun.

Wawancara IV: Narasumber Jabatan Tanggal Tempat

: Fuji Widya : Staf Jaringan Divisi TI : 23 April 2010 : Ruang Kerja Bagian Jaringan Divisi TI, Taspen Kantor Pusat Blok A Lantai 3.

Apakah ada staf yang khusus menangani keamanan untuk aplikasi ACB? Tidak ada. Hal itu dilakukan secara korporat. Apakah Taspen pernah melakukan ujicoba keamanan untuk aplikasi ACB? Belum pernah. Apakah pernah ada penyusup atau serangan yang mengarah pada aplikasi ACB? Kalau ke jaringan pernah ada. Tapi kalau langsung mengarah ke aplikasi, belum pernah. Apakah pernah mengundang pihak eksternal untuk menguji keamanan aplikasi? Kalau itu selama saya bekerja di sini, 3 tahun, sepertinya belum pernah. Atau mungkin dulu pernah dilakukan, tapi saya tidak tahu.

149
Universitas Indonesia

150

(lanjutan) Tidak ada dokumentasinya? Saya tidak tahu.

Wawancara V : Narasumber Jabatan Tanggal Tempat

: Jafar dan Yanrizal. : Staf Bagian Data di Divisi Pelayanan : 10 Mei 2010 (pukul 14.00 - 15.00 WIB) : Ruang Kerja Bagian Data, Taspen Kantor Pusat Blok B Lantai 3.

Kalau jenis data peserta di Taspen itu apa saja? Yan: Ada tiga kelompok, PNS Pusat, PNS Daerah Otonom, dan BUMN. Kalau veteran itu masuk apa? Yan : Itu bukan peserta aktif, itu peserta pensiun. Jafar : Itu penerima tunjangan, tapi masuk kategori pensiun bukan THT. Yang input database itu juga untuk penginputan pembayaran. Ada SK pensiun kita rekam per KCU. Kalau penyedia data itu siapa saja? Jafar: KPPN untuk Pusat dan Pemda untuk PNS DO. Yan: BKN itu sebagai pembanding data yang diperoleh dari instansi. Yang diyakini paling benar itu data BKN. Kalau yang bisa mengakses aplikasi manajemen data itu siapa saja? Jafar: kalau untuk display, staf keuangan bisa lihat, tidak bisa menginput. Kaseksi/Kabag Bagian Data bisa menginput? Jafar: Bisa. Berapa jumlah petugas data di tiap KCU/KC ? Jafar: Kami tidak punya, bisa dilihat di Divisi SDM. Ada perbandingan idealnya berapa jumlah petugas data dibanding jumlah data yang ia olah. Siapa yang bisa memberikan login ke petugas data? Jafar: Atasannya , Kaseksi/Kabag Data Peserta Ada surat untuk permintaan login? Jafar: Tidak ada.kalau hak akses sesuai unitnya masing-masing. Tingkatan user di kantor cabang apa saja Pak? Jafar User untuk petugas data dan admin untuk kabag. Siapa saja yang punya login itu terdaftar? Jafar: otomatis tercatat pada sistem. Kalau terdokumentasi secara hard copy tidak ada. Dulu Pak Yan kan jadi petugas data di Malang, apakah akun di Malang sudah terhapus? Yan: Sudah, terhapus. Berapa lama setelah Bapak mutasi ke kantor pusat? Yan: Setelah pindah maka akun yang lama dihapus. Di Pusat apakah bisa mengetahui siapa saja yang sedang login dan transaksi? Yan: Ya.

150
Universitas Indonesia

151

(lanjutan) Apakah pernah dievaluasi login tersebut? Jafar: Jika ada permasalahan baru dicek, siapa yang melakukannya. Apakah aplikasi manajemen data, selain ACB ada yang lain? Jafar: Kalau tambahan itu ada, namanya konsolidasi. Seperti aplikasi upload gaji. Kalau tahu ada kesalahan NIP, itu by sistem? Jafar: Ya, ada pesan. Bahkan sekarang sudah ada pembanding, kecuali NIP-nya belum ada. Dia akan mengecek ke seluruh Indonesia. Jika input lagi maka sudah ada message. Yan: Contoh pesannya: Harus melakukan proses mutasi kantor cabang, jika NIP-nya ada di kantor cabang lain. Kalau input data di bagian data apa bisa? Yan: Bisa. Di sini semua bisa. Tapi pengiputan data di Bagian Data atas dasar pemintaan oleh kantor cabang. Ada surat. Jafar: Kita Cuma bisa nginput data pembanding seperti BKN. Ketika menjadi staf data di cabang apakah dilakukan training terlebih dahulu? Yan: Ada semacam pengenalan ACB. Panduannya juga ada. Ketika mengalami ksulitan penginputan data, bagaimana Pak? Yan: Saya lihat kesulitannya terlebih dahulu. Kalau selama ini untuk penginputan data, kesulitannya tidak ada. Sifatnya operator. Jafar: Mungkin kesulitannya seperti tidak bisa input NIP karena sudah ada yang menggunakan. Solusinya seperti apa. Lalu data di BKN-nya tidak ada. Mengetahui antara database Taspen dan KPPN, apakah ada rekonsiliasi? Jafar: Ada. Rekonsiliasinya per semester. Yan: Ada SK Direksi menyatakan rekonsiliasi minimal setahun dua kali. Data-data yang tidak sama saja yang direkon, bisa selesai satu hari atau berhari-hari jika banyak. Rekonnya cepat, penyelesaiannya yang mungkin lama. Harus didokumentasikan lalu dicari solusi untuk mengatasi permasalahan tersebut. Gap yang terjadi biasanya berupa apa Pak? Jafar: data yang tidak ada di kita, atau data yang tidak di Pemda. Mereka salah input NIP atau ada pegawai yang sudah dimutasi. Bagaimana mengetahui data yang kita masukkan benar? Yan: Kita ada evaluasi data. Jika jumlah data yang dimasukkan 2000 maka yang ada di sistem harus sama. Jika beda, kita telusuri selisihnya. Biasanya penyebab kesalahan penginputan data di kantor cabang itu apa Pak? Jafar: Human error, mungkin lelah atau kurang teliti. Satu hari bisa memasukkan berapa? Jafar: Tergantung, respon time kadang pengaruh.Bisa sampai ribuan, biasanya banyak jika ada penginputan data baru seperti ada CPNS. Apakah pernah dievaluasi penyebab kesalahan penginputan itu Pak? Jafar: Ada, tiap bulan. Jika permasalahan human error, apakah ada tindak lanjut? Yan: kita lihat permasalahannya dulu. Jika permasalahannya itu karena invalid maka yang dilakukan harus mencari, misal satker itu.Tapi tidak ke personal-nya.

151
Universitas Indonesia

152

(lanjutan) Jika isian data tidak lengkap ada warning? Jafar: Ya Jika diisi nol? Jafar: Tidak mau. Kalau NIP kurang langsung ada warning? Jafar: Ya. Kalau gagal login tetap bisa masuk? Yan: Tidak masalah, asal kemudian ingat. Kalau Bapak lupa password, bagaimana? Jafar: Lapor ke Kabid kalau passwordnya lupa. Kalau ada user menginputkan lebih dari dua kali, misal NIP? Jafar: Tidak bisa. Kalau NIP bisa diubah? Jafar: Kalau kesalahan tidak bisa dihapus, maka dibuat laporan secara internal terlebih dahulu. Bila ada penghapusan NIP harus ada pengajuan? Yan: Ada berita acara penghapusan. Tidak bisa di-update langsung. Untuk pensiun punah ada warning jika ada transaksi? Jafar: Ya, dilengkapi dengan kode stop. Apakah di sistem ada logging? Jafar: Posisi terakhir yang mengerjakan pembaharuan pada data. Kalau sebelumnya tidak ada. Ada perubahan di aplikasi ACB apakah ada ujicoba? Jafar: Ya, ada berita acara termasuk perubahan SOP-nya nanti. Kontrol di aplikasi apakah ada evaluasi? Jafar: Ada jika ada masukan dari cabang. Kita telaah baru diputuskan penyelesainnya. Tapi evaluasinya belum secara periodic. Laporan data siapa saja yang bisa melihat? Jafar: bagian data kantor pusat dan kepala cabang bisa melihat. Ada telaah untuk transaksi yang aneh? Jafar: Biasanya ada informasi dari kantor cabang setelah ada keanehan, baru ditelaah. Kita menunggu laporan, tidak secara berkala. Apakah ada penyalahgunaan hak akses? Jafar: Pernah ada manipulasi. NIP itu sudah diajukan dan terbayar, jadi ketika orang yang asli mengajukan klaim sudah tidak bisa.

Wawancara V : Narasumber Jabatan Tanggal Tempat

: Sopian : Manajer Aplikasi Bisnis Inti/Core Business) : 14 Mei 2010 (pukul 09.00-10.50 WIB) : Ruang Manajer Aplikasi Bisnis Inti Taspen Kantor Pusat Blok A Lantai 3.

Apakah administrator keamanan pernah mengevaluasi akun yang misterius? Belum pernah.

152
Universitas Indonesia

153

(lanjutan) Apakah pernah pemilik aplikasi meninjau akses aplikasi? Belum pernah. Karena sudah didelegasikan ke para pejabat kantor cabang untuk pemberian hak akses. Yang menghilangkan hak akses itu pejabat kantor cabang? Ya, tapi tidak secara otomatis dan tidak ada ketentuan harus dihapus selama berapa hari. Seharusnya setelah ia menduduki posisi yang baru, akunnya sudah dihapus. Apakah ini dicek secara periodik? Kalau saya kurang tahu. Kalau mutasi internal mungkin ya, kalau antar kantor cabang saya kurang tahu. Apakah hanya akun tertentu saja yang bisa mengakses akun sensitif? Ya. Apakah data aplikasi yang sensitif sudah diekripsi? Kalau ini tanya ke jaringan Apakah ada audit keamanan aplikasi? Pernah dilakukan oleh Auditindo. Coba konfirmasi ke Pak Suryanto. Apakah sistem memberitahu jika ada pelanggaran keamanan? Tidak ada. Jika error karena kontrol kurang pas bisa juga karena human error. Apakah keamanannya teintegrasi dengan keamanan sistem korporat? Ya. Untuk konfigurasi aplikasi apakah ada prosedurnya? Seperti setting database. Ada Dokumen tentang konfigurasi itu apakah tidak semua orang bisa lihat? Ya. Pembuatan aplikasi ada keterlibatan user? Iya. Saat UAT user juga dilibatkan. Berita acaranya ada. Kalau ada perubahan kebutuhan, apakah juga tercatat? Jika secara prosedural ada perubahan maka harus tertulis. Dokumentasinya perubahan ada ya Pak? Biasanya dokumentasi output. Dari input menjadi output data seperti apa. Waktu rencana ujicoba melibatkan programmer, auditor, dan user? Ya, selain auditor. Bagian quality control secara formal belum ada. Waktu itu quality control ya user sendiri. Kalau library control ada Pak? Itu masing-masing programmer. Spesifikasi sistem seperti penambahan library ada supervisornya? Ada, yaitu saya. Perubahan aplikasi didokumentasikan sampai jadi? Ya. Ada skenario untuk ujicoba aplikasi, dengan kondisi valid dan invalid? Ya.

153
Universitas Indonesia

154

(lanjutan) Hasil ujicoba ada? Ada Apakah ada pemisahan antara sistem produksi dan pengembangan? Kalau di sisi aplikasi tidak dipilah antara produksi dan pengembangan, tapi kalau dari segi database terpisahkan antara produksi dan pengembangan. Apakah pengembangan ke satu cabang dulu? Biasanya dilakukan di sini dengan database develop. Setelah itu baru pemilik sistem yang memilih ujicoba kemana. Jika sukses maka dialihkan ke database produksi. Jika prosesnya berulang-ulang maka tinggal diujicoba di kantor pusat saja, terus langsung diimplementasikan ke kantor-kantor cabang. Apakah library ditaruh di tempat terpisah? Kalau untuk pemrograman tidak, database iya. Bagaimana dengan source code, apakah juga terpisah? Tidak. Langsung ke produksi. Hanya dialamatkan ke database develop. Backup untuk sourcecode mingguan. Siapa saja yang bisa mengakses program itu tercatat oleh sistem? Ya. Apakah kopi ekstra program dilindungi oleh kontrol akses? Tidak ada. Apakah pergerakan perubahan program ada penanggung jawab yang membandingkan? Kalau programnya berubah, misal versi nol, versi satu ada didokumentasikan. Programnya ada di satu wadah dan diakses ramai-ramai secara simultan, tapi yang disetujui yang terakhir. Secara sistem dimungkinkan. Siapa yang mengotorisasi perubahan program? Saya. Perubahan program itu mekanismenya seperti apa? Kalau secara bisnis proses yang berubah maka harus ada permintaan tertulis dari pemilik sistem. Bagaimana jika perubahannya dalam kondisi darurat? Mekanisme tidak berubah, waktunya yang ditambah. Apakah hak akses disebutkan dalam kebijakan keamanan? Ya, ada dalam kebijakan keamanan. Apakah prosedur untuk perubahan tabel ditinjau oleh pemilik sistem? Itu wewenang bagian data Divisi Pelayanan. Bagian saya hanya untuk perubahan data definition dll. Berapa kali Bapak melakukan evaluasi desain tabel? Sepanjang ada kebutuhan. Secara periodik apakah dilakukan identifikasi celah-celah keamanan? Sepanjang ada waktu. Jika ada aktivitas/transaksi yang tidak cocok, apakah pernah dievaluasi? Tidak, susah untuk mengkontrolnya, saya biasanya mengontrol di aplikasi. Saya biasanya meminta untuk membuat catatan secara manual, siapa yang mengubah.

154
Universitas Indonesia

155

(lanjutan) Apakah ada pemisahan tugas seperti programmer aplikasi tidak bisa mengubah dari sisi database, dan sebaliknya? Saat ini belum, semuanya bertindak sebagai administrator. Apakah Bapak mempertimbangkan risiko konflik kepentingan? Risiko ada, tinggal meminimalkan saja dengan catatan manual setiap ada perubahan. Apakah administrator kemanan tidak bisa melakukan input data? Tidak. Apa user bisa mengakses database produksi? Kalau dari sisi kabid SI bisa mengakses database, ini sulit dikontrol. Apakah masih ada konflik kepentingan? Ya. Apakah Bapak telah mengidentifikasi konflik kepentingan yang bisa muncul? Ke depannya Kabid SI akan dilebur, tidak ada. Karena arahannya nanti sentralisasi. Apakah hak akses terdokumentasi?Admin itu bisa melakukan apa saja, user apa saja? Tidak ada. Apakah ada bukti manajemen telah melakukan pengawasan yang efektif? Belum ada. Apakah kekritisan aplikasi diukur? Belum. Berapa jam boleh down? Belum disusun, nanti ada di DRC. Apakah ada identifikasi dampak dari gangguan? Belum, ada di DRC nantinya. Kalau yang kemarin seperti di Padang itu by case. Prosedurnya belum formal.pernah di KCU data rusak, yang dilakukan, kita menunggu hingga database KCU pulih. Jika sehari tidak bisa, maka database dialihkan ke database kantor pusat sementara di KCU Semarang diperbaiki.Setelah selesai juga belum didokumentasikan. Kalau untuk serangan hack seperti Dos? Belum pernah ada. Langkah prioritasnya apakah ada? Belum ada Untuk backup? Ya, kami ada backup, ada yang pakai tape dan harddisk. Backup per hari, ada yang jam 3, tergantung setting tiap KC. Untuk aplikasi ada backup-nya. Tapi tape-nya di kantor cabang ratarata juga ada di tempat sama. Jadi jika ada gempa, tape-nya juga rusak, kecuali disimpan di harddisk. Bagaimana jika platform berbeda untuk kondisi darurat? Saya kurang tahu. Belum pernah mengalami. Ada koordinasi untuk kondisi darurat? Ya

155
Universitas Indonesia

156

(lanjutan) Bagaimana jika aplikasi dipasang pada perangkatnya yang beda dengan yang biasa dipakai, apakah bisa? Sepertinya tidak masalah. Apakah ada prosedur pemberitahuan bencana? Belum. Sekarang ke proses bisnis. Apakah ada SOP tentang manajemen data apakah memuat tentang strategi data? Desain data, data definition ada. Ini ada di dokumentasi tapi bukan di SOP. Kalau prosedur monitoring ada di SOP. Evaluasi juga ada di SOP. Juga rekonsiliasi. Selain rekonsiliasi, untuk mengetahui data input dan output sudah benar apa saja prosedurnya? Ada, yaitu kontrol total. Apakah media inputnya itu ada standar? Seperti pakai harddisk, menggunakan excel dan lainlain? Ada. Apakah ada kontrol untuk field-field tertentu? Ada. Apakah data yang ditimpa ada pencatatan (ter-log)? Tidak ada. Ada data yang sifatnya historical seperti gaji. Ini akan tersimpan. Kalau yang statis itu nimpuk. Seperti nama peserta dari Aji jadi Abi, yang Aji langsung tertimpa. Tapi log tidak terpelihara selamanya. Tergantung pada setting pada sistem. Apakah ada prosedur pemeliharaan tabel? Untuk level konten dan schema, siapa penanggung jawabnya? Tidak ada. Apakah kontrol pernah ditinjau? Evaluasi secara rutin tidak ada, tapi berdasar kebutuhan. Apakah ada prosedur untuk memastikan semua input itu valid? Ya, harus. Apabila ada kesalahan input ada warning-nya, diperbaiki dan dimasukkan kembali? Ya. Apakah setiap aplikasi yang ada di tiap KC itu sudah merupakan versi terbaru? Ada dua, wajib dan tidak diambil. Wajib itu menyangkut financial, ada perhitungan yang salah. Namun, jika cuma format yang berubah, tidak ada kewajiban. Namun, ada warning, kalau di kantor pusat ada versi terbaru. Kalau saya wajibkan, aplikasi tidak bisa jalan. Ahrus di-install dulu. Apakah ada log transaksi? Ya. Apakah sistem bisa mengidentifikasi input yang tidak komplet? Ada. Apakah ada pengisian yang tidak komplet, apakah ada warning? Ya. Untuk override adakah log? Ya di sistem, untuk nama langsung tertimpa.

156
Universitas Indonesia

157

(lanjutan) Apakah ada dokumentasi untuk perubahan aplikasi? Ya. Apakah manajemen meninjau pembatasan atau kontrol? Ya sesuai kebutuhan. Apakah transaksi yang salah ditolak dan didiamkan hingga diperbaiki? Ya. Apakah transaksi terotorisasi sebelum masuk ke sistem? Jika memiliki hak akses maka langsung masuk ke sistem. Apakah rekonsiliasi ada? Ya. Apakah ada kewajiban user mengikuti prosedur? Ya, ada SOP dan buku panduan. Apakah kontrol untuk user sudah memenuhi? Ya Apakah ada enkripsi? Coba tanya ke Pak Suryanto. Apakah ada evaluasi untuk override? Tidak, petugas data harus yakin sebelum melakukan override. Untuk override log adakah? Tidak. Akses user untuk data produsi bisakah? Tergantung pemberian hak akses. Jika laporan diberikan ke pihak lain adakah prosedurnya? Coba tanya ke Divisi Pelayanan. Kita sendiri tidak pernah memberikan data langsung ke pihak eksternal.ada permintaan tertulis. Apakah manajemen punya laporan tentang output-output yang tidak sesuai? Ya Apakah manajemen telah meninjau hasil aplikasi? Ada di formulir kerja. Apakah ada peninjauan untuk log-log atau transaksi yang abnormal? Ya. Ada mekanisme untuk memvalidasi kekonsistenan antara tabel satu ke tabel yang lain. Apakah ada ketentuan dari pihak eksternal yang menyatakan data harus akurat? Seharusnya ada. Mereka mengeluarkan batas toleransi. Apakah semua entri harus terisi dalam suatu proses? Ada yang boleh kosong. Nilai null berlaku untuk apa saja? Yang bukan nonfieldkey. Untuk PNS ada THP I dan THP II, tapi tidak untuk BUMN, jadi BUMN boleh null.

157
Universitas Indonesia

158

(lanjutan) Apakah akun aset terdefinisi dengan jelas? Tidak. Kalau utang pensiunan ada ke negara. Misal SK pensiun terlambat maka ia makan gaji aktifnya, keterlanjuran bayar. Apakah jika ada konfigurasi seperti schema. Ada dokumentasinya kah? Tidak. Kalau penambahan tabel baru ada. Bagaimana dengan perubahan data master. Siapa yang bisa mengaksesnya? Hanya saya. Kalau NIP bisa berubah? Tidak. Kalau nama bukan key, jadi bisa berubah. Kalau ada duplikasi bagaimana? Jika ada nopen sama nama beda maka dianalisa, dengan melakukan rekonsiliasi. Apakah ada retensi data? Tidak, hilang jika dihapus. Kalau ada permintaan perubahan format tabel? Itu harus diubah secara struktur database dan harus ada permintaan tertulis. Bagaimana dengan konflik kepentingan untuk perubahan data master. Adakah? Sepanjang dia punya login untuk masuk bisa, tapi secara fungsi tidak ada. Apakah ada laporan perubahan data master? Ada. Perubahan seperti format NIK kemudian disampaikan lagi ke Divisi Pelayanan. Apakah jika dihapus maka harus minta ijin? Tidak, cabang masing-masing yang melakukannya. Apakah data master terenkripsi? Saya kurang tahu Wawancara VI Narasumber Jabatan Tempat Waktu

: : : :

Suryanto Manajer Sistem Operasi Ruang Manajer Sistem Operasi, Taspen Gedung Blok A Lantai 3 8 Juni 2010, pukul 11.10 11.40 WIB

Apakah Taspen memiliki kebijakan keamanan? Ada. Taspen punya IT Security Policy yang disusun pada tahun 2007. Apakah kebijakan ini disusun oleh Taspen? Tidak, namun oleh bantuan konsultan dari Auditindo. Apakah kebijakan keamanan ini telah diterapkan? Belum sepenuhnya. Apakah kebijakan keamanan ini telah disosialisasikan ke karyawan Taspen? Belum. Apakah ada kebijakan keamanan aplikasi core business? Kalau secara khusus tidak ada, bergabung dengan kebijakan keamanan korporat.

158
Universitas Indonesia

159

(lanjutan) Apakah pernah ada tes penetrasi untuk aplikasi ACB? Belum. Apakah ada enkripsi untuk data master aplikasi ACB? Kalau di jaringan ada, tapi untuk di database belum diterapkan.

159
Universitas Indonesia