TUGAS 2 AUDIT TEKNOLOGI SISTEM INFORMASI (Chapter 9 Auditing Database)

AUDIT TEKNOLOGI SISTEM INFORMASI

Chapther 9 Auditing Database

Oleh :

1.    Birgita Juliana                   12114201

2.    Cynthia Fega P                  12114473

3.    Novy Hafsari                      18114104

4.    Risma Putri Fitrianti          19114514

5.    Rosyi Nurul Fatihah          19114822

6.    Tytha Chairunnisa             1A114915

Kelas 4KA41

Universitas Gunadarma

Karawaci

1.       Ruang lingkup audit yang akan kalian lakukan (apakah audit through the computer / audit around the computer) ?

Jawab : Ruang lingkup audit with computer

2.       Buat rencana audit (langkah-langkah/prosesnya) !

Jawab:

1.       Dapatkan versi database dan bandingkan dengan persyaratan kebijakan perusahaan Anda. Pastikan database menjalankan versi perangkat lunak database yang terus didukung vendor.

2.       Verifikasi bahwa kebijakan dan prosedur diterapkan untuk mengidentifikasi kapan patch tersedia dan untuk menerapkan patch. Pastikan semua patch yang disetujui dipasang sesuai dengan kebijakan pengelolaan basis data.

3.       Tentukan apakah sebuah standar build tersedia untuk database sistem baru dan apakah baseline tersebut memiliki pengaturan keamanan yang memadai. 

4.       Pastikan akses ke sistem operasi dibatasi dengan benar.

5.       Pastikan bahwa perizinan pada direktori tempat database terinstal, dan file database itu sendiri dibatasi dengan benar. 

6.       Pastikan bahwa hak akses pada kunci registri yang digunakan oleh database dibatasi dengan benar. 

7.       Meninjau dan mengevaluasi prosedur untuk membuat akun pengguna dan memastikan bahwa akun dibuat hanya dengan kebutuhan bisnis yang sah. Juga meninjau dan mengevaluasi proses untuk memastikan bahwa akun pengguna dihapus atau dinonaktifkan secara tepat waktu jika terjadi penghentian atau perubahan pekerjaan. 

8.       Periksa nama pengguna dan kata sandi default.

9.       Periksa password yang mudah ditebak. 

10.   Periksa kemampuan manajemen password yang diaktifkan.

11.   Verifikasi bahwa hak akses database diberikan atau dicabut dengan tepat untuk tingkat otorisasi yang diperlukan.

12.   Tinjau kembali perizinan database yang diberikan kepada individu dan bukan kelompok atau peran. 

13.   Pastikan bahwa hak akses database tidak secara implisit diberikan secara tidak benar.

14.   Meninjau SQL dinamis yang dijalankan dalam prosedur tersimpan.

15.   Pastikan akses tingkat baris ke data tabel benar dilaksanakan. 

16.   Cabut izin PUBLIK jika tidak diperlukan.

17.   Pastikan enkripsi jaringan diimplementasikan.

18.   Verifikasi bahwa enkripsi data saat istirahat diterapkan bila sesuai. 

19.   Verifikasi penggunaan audit database dan pemantauan aktivitas yang sesuai. 

20.   Mengevaluasi bagaimana kapasitas dikelola untuk lingkungan database untuk mendukung kebutuhan bisnis yang ada dan yang diantisipasi.

21.   Mengevaluasi bagaimana kinerja dikelola dan dipantau untuk lingkungan database untuk mendukung kebutuhan bisnis yang ada dan yang diantisipasi. 

3.       Tentukan isntrumen auditnya (alat auditnya) !

Jawab :

Alat berguna untuk mencari celah dan celah. Dua perspektif tentang pemindaian database untuk kerentanan dan tambalan biasa terjadi : mencari dan mendokumentasikan sebanyak mungkin kerentanan, dan untuk mengurangi kerentanan dan malah berfokus pada tambalan apa yang telah Anda instal. Pada akhir hari, Anda perlu tahu patch apa yang belum Anda terapkan dan Anda perlu mengidentifikasi kerentanan kritis dan konfigurasi yang salah.

Penting juga agar Anda memahami bahwa alat audit jaringan dan sistem operasi gagal total dalam membantu audit database. Kenapa ini? Database adalah binatang yang kompleks. Mereka memiliki sistem kontrol akses mereka sendiri, akun pengguna mereka sendiri dan menyampaikan kata-kata, subsistem audit mereka sendiri, dan bahkan protokol jaringan mereka sendiri. Pemindai generik sama sekali tidak memiliki keahlian untuk menyediakan lebih dari sekadar melihat sekilas database. 

Sejumlah alat, seperti berikut, khusus untuk membantu auditor menjalankan audit pada database:

Database Auditing Tool	Website
AppDetective oleh Application Security, Inc.	www.appsecinc.com
NGSAuditor dan NGSSquirrel oleh NGS Software, Ltd.	www.ngssoftware.com/home.aspx
ApexSQL Audit 2.12.99	http://www.freedownloadsapps.com/apexsql-audit/44750-download.html

Tools 1 dan 2 tidak dapat diakses.

4.       Cara penggunaan instrument audit tersebut

Jawab:

1.    Dapatkan versi database dan bandingkan dengan persyaratan kebijakan perusahaan Anda. Pastikan database menjalankan versi perangkat lunak database yang terus didukung vendor.

Bagaimana

Melalui percakapan dengan DBA dan tinjauan terhadap standar dan kebijakan TI, menentukan versi dan platform database apa yang direkomendasikan dan didukung oleh perpustakaan. Verifikasi dengan vendor database yang versi dan platformnya didukung dan apakah patch untuk masalah keamanan baru akan disediakan. Inventarisasi versi database yang dijalankan, dan periksa database apa pun yang termasuk dalam versi yang tidak didukung. Idealnya, agar database tetap diupgrade ke versi yang didukung. 

2.   Verifikasi bahwa kebijakan dan prosedur diterapkan untuk mengidentifikasi kapan patch tersedia dan untuk menerapkan patch. Pastikan semua patch yang disetujui dipasang sesuai dengan kebijakan pengelolaan basis data.

Bagaimana

Wawancara DBA untuk menentukan siapa yang meninjau saran dari vendor, langkah apa yang diambil untuk mempersiapkan patch, dan berapa lama patch diuji sebelum diterapkan ke database produksi. Mintalah untuk meninjau catatan dari siklus tambalan sebelumnya. 

Dapatkan informasi sebanyak mungkin tentang patch terbaru, dan tentukan cakupan kerentanan yang ditangani oleh patch. Bandingkan es patch yang tersedia dengan tambalan yang diterapkan pada database. Bicarakan dengan DBA tentang langkah-langkah yang diambil untuk mengurangi potensi risiko jika patch tidak diterapkan pada waktu yang tepat. Banyak DBA berusaha mengurangi kebutuhan untuk melakukan patch dengan menghapus komponen sistem yang mereka anggap memiliki kerentanan. Meskipun ini adalah praktik yang bagus karena mengurangi risiko keamanan, hal itu seharusnya tidak dapat diterima sebagai pengganti jangka panjang untuk patching.

Database menimbulkan dilema yang menarik berkaitan dengan patch untuk kebanyakan organisasi. Banyak database berjalan pada jadwal 24/7, sehingga tidak ada penyisihan downtime. Ini berarti tidak ada waktu yang tersedia untuk menurunkan database untuk menerapkan patch. 

Komplikasi utama lainnya untuk pemindaian database adalah pengujian beberapa tambalan baru biasanya merupakan proses 3 sampai 6 bulan. Database biasanya sangat penting sehingga tambalan tidak dapat diinstal tanpa pengujian menyeluruh. Dengan siklus patch kuartalan, pekerjaan penuh waktu DBA dengan mudah bisa menjadi ujian dan penerapan tambalan baru, dan ini kemungkinan akan menjadi pekerjaan penuh waktu bagi DBA yang bergerak maju, seperti tim orang saat ini yang didedikasikan untuk menambal Windows dan Unix sistem. 

Salah satu solusi untuk masalah downtime adalah penggunaan clustering. Di lingkungan yang berkerumun, satu simpul di cluster dapat diambil secara offline, dipatch, dan dibawa kembali secara online. Ini bisa berhasil, namun mengenalkan kompleksitas prosesnya. Terlepas dari solusinya, tambalan yang terkait dengan kelemahan pengendalian harus dipahami dan kelemahan pengendalian harus ditangani dengan tepat untuk melindungi database.

3.  Tentukan apakah sebuah standar build tersedia untuk database sistem baru dan apakah baseline tersebut memiliki pengaturan keamanan yang memadai. 

Bagaimana

Melalui wawancara dengan administrator sistem, tentukan metodologi yang digunakan untuk membangun dan menerapkan sistem baru. Jika menggunakan standar digunakan, pertimbangkan untuk mengaudit sistem yang baru dibuat menggunakan langkah-langkah dalam bab ini.

4.      Pastikan akses ke sistem operasi dibatasi dengan benar.

Bagaimana

Verifikasi dengan administrator bahwa semua akses ke sistem operasi dibatasi hanya untuk DBA. Verifikasi bahwa setiap akses shell terjadi melalui protokol yang aman, sebaiknya SSH. Periksa akun apapun pada sistem operasi yang harus dilepas.

5.    Pastikan bahwa perizinan pada direktori tempat database terinstal, dan file database itu sendiri dibatasi dengan benar. 

Bagaimana

Verifikasi bahwa perizinan pada direktori tempat database terinstal seungguh mungkin dan dimiliki oleh akun DBA yang sesuai. Sayangnya, beberapa fungsi database ditulis tanpa keamanan dalam pikiran, dan kita dapat mematahkan fungsi basis data dengan membuat perizinan file terlalu ketat. 

Di Windows, tindakan serupa harus dilakukan. Izin file pada direktori di mana database terinstal harus dibatasi pada hak akses akun yang dijalankan database. Pastikan pengguna "Semua orang" atau "Anonim" tidak memiliki izin pada file database. Selain itu, pastikan semua drive yang digunakan untuk menyimpan file database menggunakan NTFS.

Dalam situasi yang ideal, bahkan DBA tidak memerlukan izin pada file sistem operasi yang mendasarinya. Namun, mengingat kebutuhan DBA untuk bekerja dengan file database dan backup, patch database, dan menyelesaikan tugas lainnya, DBA akan membutuhkan beberapa akses ke file sistem operasi. Pengguna istimewa yang tidak memerlukan akses ke sistem op erasi seharusnya tidak diberi izin untuk melakukannya. 

Ambil daftar hak akses file pada semua file database dan direktori tempat mereka berada, baik dengan menghubungkan ke sistem operasi dan menarik informasi ini sendiri atau dengan mendapatkan informasi dari administrator. Tinjau daftar untuk menemukan hak istimewa yang berlebihan. Di Unix, periksalah bahwa perizinan ditetapkan tidak lebih permisif dari 770. Jika Anda mencabut semua izin untuk "Semua Orang", banyak program mungkin akan rusak, jadi hati-hati. Menetapkan keamanan yang ketat adalah tujuan yang baik, namun Anda mungkin harus menetapkan pengecualian terhadap kebijakan ini, dan pastikan untuk mendokumentasikan alasan pengecualian. Untuk Windows, pastikan bahwa izin tidak diberikan kepada "Semua orang." Praktik terbaik adalah memberikan izin kepada DBA yang memerlukan akses saja.

6.    Pastikan bahwa hak akses pada kunci registri yang digunakan oleh database dibatasi dengan benar. 

Bagaimana

Tinjau izin keamanan melalui Registry Editor, melalui utilitas baris perintah seperti GetDACL, atau denga n mendapatkan informasi dari administrator. Setelah mengambil daftar lengkap hak akses, tinjau ulang untuk memastikan tidak ada per misi yang berlebihan.

7. Meninjau dan mengevaluasi prosedur untuk membuat akun pengguna dan memastikan bahwa akun dibuat hanya dengan kebutuhan bisnis yang sah. Juga meninjau dan mengevaluasi proses untuk memastikan bahwa akun pengguna dihapus atau dinonaktifkan secara tepat waktu jika terjadi penghentian atau perubahan pekerjaan. 

Bagaimana

Wawancara administrator database, dan tinjau prosedur pembuatan akun. Proses ini harus mencakup beberapa bentuk verifikasi bahwa pengguna memiliki kebutuhan akses yang sah. Pastikan akses ke akun dan hak istimewa tingkat DBA diminimalkan. 

Tinjau contoh akun dan bukti bahwa akun disetujui dengan benar sebelum dibuat. Sebagai alternatif, ambil contoh akun dan validasikan mosi legiti mereka dengan menyelidiki dan memahami fungsi pekerjaan pemilik akun. Pastikan setiap pengguna di sistem memiliki akun penggunanya sendiri. Tidak ada akun tamu atau kelompok yang harus ada. Jika sejumlah besar akun database ada, tanyakan kebutuhannya. Aplikasi pengguna akhir umumnya harus mengakses database melalui aplikasi dan bukan dengan akses database langsung.

Juga tinjau proses penghapusan akun saat akses tidak lagi dibutuhkan. Proses ini bisa mencakup mekanisme penghitungan akun pengguna pada negara-negara terma dan perubahan pekerjaan. Prosesnya bisa mencakup tinjauan berkala dan validasi akun aktif oleh administrator sistem dan / atau manajer berpengetahuan lainnya. Dapatkan contoh akun, dan verifikasi bahwa mereka dimiliki oleh karyawan aktif dan posisi kerja karyawan tersebut tidak berubah sejak pembuatan akun.

8.     Periksa nama pengguna dan kata sandi default.

Bagaimana

Pastikan semua nama pengguna dan sandi default telah dihapus atau dikunci, atau bahwa kata sandinya telah diubah. Utilitas dan peralatan gratis dan komersial tersedia untuk memverifikasi ini.

9.     Periksa password yang mudah ditebak. 

Bagaimana

Jalankan tes kekuatan kata kunci pada hash kata sandi untuk menentukan apakah kata kunci mudah ditebak. Jika Anda mendeteksi kata kunci yang ditemukan dalam kamus atau dapat ditebak, berbicaralah dengan DBA tentang praktik penyadaran pengguna dan tentang menerapkan praktik pemeriksaan kekuatan kata kunci. Lihat langkah 10 untuk pengaturan konfigurasi sistem yang dapat membantu memperkuat kata sandi.

Kategori	Deskripsi
Default database password	Dibuat dalam database standar install. Bisa tergantung pada komponen terinstal dari database. Sebagian besar terbaru versi database telah menghilangkan database default password, tapi password default tetap menjadi perhatian serius pada perangkat lunak database versi lama.
Sample atau contoh password	Banyak contoh, contoh, dan demonstrasi baru atau fitur yang ada ditampilkan dalam skrip SQL yang disertakan pembuatan akun uji atau contoh.
Default Application Password	Bila Anda menginstal produk pihak ketiga di atas database, produk sering menginstal dan menjalankan menggunakan username dan password default untuk mengakses database. Ini diketahui hacker dan berfungsi sebagai umum rute akses
User-defined default password	Bila akun baru dibuat, kata sandi sering disetel ke nilai awal dan kemudian atur ulang pada penggunaan pertama. Masalah muncul saat akun dibuat namun tidak pernah diakses. Pastikan bahwa kata sandi yang diset pada akun baru acak, password yang kuat

10.  Periksa kemampuan manajemen password yang diaktifkan.

Bagaimana

Pilih nilai konfigurasi dari database. Pastikan setiap fitur pengelolaan password diaktifkan dan dikonfigurasi untuk nilai lingkungan yang sesuai dan sesuai dengan kebijakan perusahaan Anda. Anda perlu meninjau dokumentasi untuk platform database untuk menentukan fitur pengelolaan kata kunci yang tepat yang tersedia dan perintah yang diperlukan untuk melihatnya. 

11. Verifikasi bahwa hak akses database diberikan atau dicabut dengan tepat untuk tingkat otorisasi yang diperlukan.

Bagaimana

Bicara dengan administrator database untuk menentukan akun pengguna mana yang diperlukan untuk memiliki akses ke data apa. Beberapa administrator mungkin memerlukan akses, beberapa akun dapat digunakan oleh aplikasi web untuk mengakses data, dan beberapa akun mungkin digunakan oleh pekerjaan batch. Akun yang tidak memerlukan izin atau akses harus dikunci, dinonaktifkan, atau bahkan dihapus.

12. Tinjau kembali perizinan database yang diberikan kepada individu dan bukan kelompok atau peran. 

Bagaimana

Pilih daftar izin dari kamus database. Tinjau ulang izin yang diberikan ke akun atau pengguna. Periksa apakah hak istimewa diberikan pada peran atau kelompok. Pengguna individual Indi kemudian dapat diberi izin dengan menugaskan mereka ke peran atau kelompok sesuai kebutuhan. 

Anda juga perlu mendownload daftar peran / kelompok dan pengguna / akun untuk menghalangi saya yang diizinkan untuk diberikan. Daftar pengguna dan grup disimpan dalam kamus data.

13. Pastikan bahwa hak akses database tidak secara implisit diberikan secara tidak benar.

Bagaimana

Tinjau spesifikasi model izin untuk platform basis data dan verifikasi izin yang diwarisi dengan tepat. Juga tinjau hak istimewa sistem yang memungkinkan akses ke data, seperti SELECT ANY TABLE atau pemberian peran istimewa kepada pengguna. Izin dokumen yang secara implisit serta secara eksplisit diberikan untuk memastikan bahwa izin tidak diperbolehkan bila tidak sesuai. 

14. Meninjau SQL dinamis yang dijalankan dalam prosedur tersimpan.

Bagaimana

Dengan bantuan DBA, tinjau prosedur yang tersimpan, khusus mencari masalah seperti injeksi SQL atau bentuk SQL dinamis lainnya. Batasi penggunaan SQL dinamis dalam proses yang berjalan dengan hak istimewa yang tinggi. Selain itu, pastikan bahwa setiap dan semua akses ke prosedur tersimpan yang berjalan di bawah hak istimewa ditinggikan. 

Di lingkungan gudang data yang besar, auditor harus bekerja sama dengan DBA dan pemilik aplikasi untuk mengidentifikasi pengambilan contoh jalur kritis dan kemudian mencari SQL dinamis dalam prosedur tersimpan.

15.  Pastikan akses tingkat baris ke data tabel benar dilaksanakan. 

Bagaimana

Ini kemungkinan akan menjadi usaha bersama antara DBA dan pemilik aplikasi, terutama di lingkungan yang lebih besar. Diskusikan dengan administrator yang sesuai metode kontrol akses tingkat baris dalam database. Pastikan pengguna tidak dapat mengakses data dalam sebuah tabel tanpa otorisasi yang tepat jika pengguna mengelak dari aplikasi atau prosedur yang tersimpan memberikan akses. Akses database melalui akun pengguna untuk memverifikasi bahwa kemampuan "efektif" pengguna sesuai dengan keinginan. 

16.  Cabut izin PUBLIK jika tidak diperlukan.

Bagaimana

Mulailah dengan mengumpulkan daftar semua izin, sorot yang diberikan kepada PUBLIK. Diskusikan dengan DBA dimana prosedur dan fitur database digunakan atau mungkin digunakan di masa depan. Kemudian tentukan berapa besar risiko yang akan dikenalkan dengan mencabut izin dari objek yang jelas tidak dibutuhkan. Jika semua orang setuju untuk memiliki izin yang dicabut, masuk akal untuk mencabutnya. Selalu buat cadangan dan pro vide skrip undo yang dapat digunakan untuk mengembalikan setiap perubahan jika nanti Anda menentukan bahwa Anda memerlukan izin tersebut atau sesuatu yang tiba-tiba rusak. 

17.  Pastikan enkripsi jaringan diimplementasikan.

Bagaimana

Pastikan driver jaringan dan klien telah dikonfigurasi untuk mendukung penyandian lalu lintas jaringan menggunakan protokol seperti SSL. Verifikasi pengaturan pada klien dan database. Dalam beberapa kasus, Anda mungkin perlu mencicipi lalu lintas untuk menunjukkan enkripsi.

18.  Verifikasi bahwa enkripsi data saat istirahat diterapkan bila sesuai. 

Bagaimana

Verifikasi bahwa data yang harus dienkripsi terenkripsi dengan benar. Juga tinjau lokasi dimana kunci enkripsi disimpan, karena kekuatan enkripsi bergantung pada kekuatan perlindungan kunci enkripsi. Jika kunci enkripsi disimpan dengan data terenkripsi, penyerang dapat menumbangkan keamanan hanya dengan mengekstrak kunci enkripsi.

Periksa rencana pemulihan bencana untuk memastikan bahwa manajemen kunci enkripsi dikelompokkan sebagai komponen. Kesalahan yang Anda tidak ingin DBA Anda lakukan adalah menerapkan fitur enkripsi namun gagal memasukkan manajemen kunci dalam prosedur pencadangan. Gagal untuk mencadangkan kunci enkripsi dengan benar menghasilkan ketidakmampuan untuk memulihkan cadangan basis data. 

19. Verifikasi penggunaan audit database dan pemantauan aktivitas yang sesuai. 

Bagaimana

Audit dapat mengambil banyak bentuk:

• Audit akses dan otentikasi Tentukan siapa yang mengaksesnya sistem, kapan, dan bagaimana.

• Audit pengguna dan administrator Tentukan aktivitas apa yang dilakukan dalam database oleh pengguna dan administrator.

• Audit aktivitas mencurigakan Mengidentifikasi dan menandai curiga, tidak biasa, atau akses abnormal ke data sensitif atau sistem kritis.

• Kerentanan dan ancaman audit Mendeteksi kerentanan dalam database, danlalu pantau agar pengguna mencoba memanfaatkannya.

• Mengubah audit Menetapkan kebijakan dasar untuk database, konfigurasi, skema, pengguna, hak istimewa, dan struktur, dan kemudian menemukan dan melacak penyimpangan dari baseline itu.

Tinjau metode pemantauan yang diterapkan dengan DBA dan diskusikan sensitivitas data. Pemantauan aktivitas harus sesuai dengan nilai bisnis dari informasi yang tersimpan dalam database dan dengan kebijakan dan persyaratan orgaisasi.

Tinjau daftar data sensitif di database, dan verifikasi bahwa audit benar-benar dilakukan untuk data sensitif. Pertimbangkan untuk meninjau daftar transaksi sensitif untuk jangka waktu tertentu untuk menunjukkan kemampuan sistem pemantauan untuk mengaudit kejadian tersebut. 

20. Mengevaluasi bagaimana kapasitas dikelola untuk lingkungan database untuk mendukung kebutuhan bisnis yang ada dan yang diantisipasi.

Bagaimana

Verifikasi bahwa persyaratan kapasitas telah didokumentasikan dan disepakati bersama dengan pelanggan. Tinjau proses untuk memantau penggunaan kapasitas, perhatikan bila melebihi ambang tua yang ditentukan. Persyaratan dapat dievaluasi atau diambil sebagian oleh tim yang sama yang bertanggung jawab atas lingkungan penyimpanan. Evaluasi proses untuk merespons dan mengambil tindakan saat penggunaan kapasitas melebihi ambang batas yang ditetapkan. Diskusikan metode yang digunakan untuk menentukan persyaratan database saat ini dan perkiraan pertumbuhan. Tinjau kembali rencana pertumbuhan dengan administrator untuk memverifikasi bahwa perangkat keras dapat memenuhi persyaratan kinerja, persyaratan kelayakan, dan persyaratan fitur untuk mendukung infrastruktur dan pertumbuhan bisnis.

21.   Mengevaluasi bagaimana kinerja dikelola dan dipantau untuk lingkungan database untuk mendukung kebutuhan bisnis yang ada dan yang diantisipasi. 

Bagaimana

Tinjauan kinerja berkala berkala terhadap beban prosesor, memori, dan IO / lebar pita jaringan pada arsitektur basis data harus dilakukan untuk mengidentifikasi tekanan pada arsitektur. Verifikasi bahwa persyaratan kinerja telah didokumentasikan dan disepakati bersama dengan pelanggan. Tinjau proses untuk memantau kinerja dan mencatat saat kinerja berada di bawah ambang batas yang ditentukan. Evaluasi proses yang ada untuk merespons dan mengambil tindakan saat kinerja berada di bawah ambang batas yang ditetapkan. Diskusikan metode yang digunakan untuk menentukan persyaratan kinerja saat ini dan perubahan antisipasi.

Sumber

Chris, D. M. (2011). IT Auditing Using Control To Protect Information Assets. The Mc Graw Hill Companies.

http://www.freedownloadsapps.com/apexsql-audit/44750-download.html

AUDIT TEKNOLOGI SISTEM INFORMASI (Chapter 9 Auditing Database)

AUDIT TEKNOLOGI SISTEM INFORMASI

Chapther 9 Auditing Database

Kelompok 4

Anggota:

1.    Birgita Juliana                   12114201

2.    Cynthia Fega P                  12114473

3.    Novy Hafsari                      14114104

4.    Risma Putri Fitrianti          19114514

5.    Rosyi Nurul Fatihah          19114822

6.    Tytha Chairunnisa             1A114915

Kelas 4KA41

Universitas Gunadarma

Karawaci

1.    TEORI DAN KONSEP AUDITING

Teori dapat di klasifikasikan berdasarkan sifat menjadi dua, yaitu teori normatif, danteori deskriptif. Teori normatif merupakan teori yang seharusnya di laksanakan. Teorideskriptif merupakan teori yang sesungguhnya di laksanakan. Tidak seperti pada akuntansi, pada auditing tidak banyak orang yang berbicaratentang teori auditing sebagai lawan kata praktik auditing. Pada umumnya, orangmenganggap auditing hanya suatu rangkaian prosedur, metode dan teknik. Auditing tidaklebih dari pada sekedar suatu cara untuk melakukan sesuatu dengan sedikit penjelasan, uraian, rekonsiliasi, dan argumentasi. Meskipun demikian, telah di coba untuk meyakinkan perlunya suatu teori normatif pada auditing.  Professor R. K. Mautz dan H. A. Sh raf dengan bukunya “ The Philosophy of Auditing “, merupakan tokoh pertama yang melakukan usaha tersebut.Profesor C. W. Schandl pada tahun 1978 yang mengembangkan pemikiran dari Mautz dan Sharaf, mengemukakan elemen-elemen dasar teori adalah sebagai berikut :

1.    Postulat yaitu: Konsep dasar yang harus diterima tanpa perlu pembuktian. Sebagaisyarat penting dalam pengembangan disiplin, tidak perlu di periksa kebenaranyalagi, sebagai dasar pengambil kesimpulan,sebagai dasar membangun struktur teoridan bisa juga dimodifikasi sesuai perkembangan ilmu pengetahuan.

2.    Teori yaitu : Dalil yang diterangkan oleh postulat.

3.    Struktur yaitu : Komponen disiplin tertentu dan hubungan antar komponen tersebut.

4.    Prinsip yaitu : Kaidah-kaidah yang diterapkan dalam praktik

5.    Standar yaitu : Kualitas yang ditetapkan dalam hubungannya dengan praktik.

Menurut Lee dalam bukunya Corporate Audit Theory ada tiga kelompok postulat sebagai dasar teori dalam auditing yaitu :

1.    Postulat yang berkaitan dengan aspek keberadaan audit.

2.    Postulat yang berfokus pada tindakan auditor dan aspek perilaku.

3.    Postulat yang berfokus pada prosedur audit atau fungsional audit.

Teori Auditing merupakan tuntunan untuk melaksanakan audit yang bersifatnormatif. Konsep adalah abstraksi-abstraksi yang diturunkan dari pengalaman danobservasi, dan dirancang untuk memahami kesamaan-kesamaan di dalam suatu subyek, dan perbedaan perbedaannya dengan subyek yang lain. Standar Auditing adalah pengukurkualitas dan tujuan sehingga jarang berubah. sedangkan Prosedur Audit adalah metode-metode atau teknik teknik rinci untuk melaksanakan standar, sehingga prosedur akan berubah bila lingkungan auditnya berubah.

Menurut Mautz dan Sharaf  teori auditing tersusun atas lima konsep dasar,yaitu:

1. Bukti Tujuan memperoleh dan mengevaluasi bukti adalah untuk memperoleh pengertiansebagai dasar untuk memberikan kesimpulan atas pemeriksaan yang di tuangkan dalam pendapat auditor. Secara umum usaha untuk memperoleh bukti dilakukan dengan cara ,yaitu :

a)    Authoritarianisme, Bukti diperoleh berdasar informasi dari pihak lain. Misalnyaketerangan lisan manajemen dan karyawan, dan pihak luar lainnya, sertaketerangan lisan tertulis berupa doklumen. 

b)    Mistikisme, Bukti dihasilkan dari intuisi. Misalnya pemeriksaan buku besar, dan penelaahan terhadap keterangan dari pihak luar.

c)    Rasionalisasi, Merupakan pemikiran asumsi yang diterima. Misalnya penghitungan kembalioleh auditor, dan pengamatan terhadap pengendalianintern.

d)    Emperikisme, Merupakan pengalaman yang sering terjadi. Misalnya perhitungan dan pengujian secara fisik.

e)    Pragmatisme, Merupakan hasil praktik. Misalnya kejadian setelah tanggalselesainya pekerjaan lapangan.

2.       Kehati-hatian dalam pemeriksaan (due care)

Artinya melakukan pekerjaan dengan sangat hati-hati dan selalu mengindahkannorma-norma profesi dan norma moral yang berlaku. Konsep kehati-hatian yang diharapkan auditor yang bertanggung jawab. Dalam auditing tersebut sebagai prudent auditor. Tanggung jawab yang di maksud adalah tanggung jawab profesional dalam melaksanakantugasnya. Konsep ini lebih di kenal dengan konsep konservatif.

3.         Penyajian atau pengungkapan yang wajar.

Konsep ini menuntut adanya informasi laporan keuangan yang bebas (tidakmemihak), tidak bias, dan mencerminkan posisi keuangan,hasil operasi, dan aliran kas perusahaan. Konsep ini dijabarkan lagi dalam 3 sub konsep, yaitu :

·         Accounting Propriety : berhubungan dengan penerapan prinsip akuntansitertentu dalam kondisi tertentu.

·         Adequate Disclosure : berkaitan dengan jumlah dan luas pengungkapan atau penyajian informasi

·         Audit Obligation : berkaitan dengan kewajiban auditor untuk independen dalammemberikan pendapat.

1.      Independensi

Merupakan suatu sikap mental yang di miliki auditor untuk tidak memihak dalammelakukan audit. Masyarakat pengguna jasa audit memandang bahwa auditor akan independen terhadap laporan keuangan yang di periksa dan pembuat dan pemakai laporan keuangan. Jika posisi auditor terhadap kedua hal tersebut tidak independen maka hasil kerjaauditor menjadi tidak berarti sama sekali.

2.         Etika perilaku dalam auditing berkaitan dengan perilaku yang ideal seorang auditor profesional yang independen dalam melaksanakan audit.

2.    PROSES AUDIT

Dalam tahapan Risk Based Audit terdapat pada individual Audit. Dalam Individual audit terdapat tahap pelaksanaan AIBR yang merupakan tahapan lanjutan dari tahap perencanaan. Tahap ini merupakan tahap perkerjaan lapangan (field work) berupa audit individual atas Unit Layak Audit (ULA).

Tahapan Individual Audit, yaitu:

• ·        Perencanaan (Plan)

       Dalam tahap ini auditor melakukan perkenalan kepada perusahaan dan indutri klien.Proses pengenalan dan pengenalan bisa dilakukan dengan meeting dengan klien, diskusi vis telepon, melakukan riset mengenai industry, internal meeting dengan tim dan sebagainya. Tahap penting yang dilakukan di dalam tahap ini adalah penetuan materialistis. Secara sederhan meterialitas dapat dijelaskan sebagai besarnya penyimpangan dalam informasi akuntasi yang mana dalam kondisi tertentu bisa membuat pengguna laporan keuangan mengubah atau mempengaruhi pendapatnya jika penyimpangan tersebut diketahuinya. Tahapan dalam tahap perencanaan.

a.    Penetapan tujuan dan lingkup penugasan

b.    Pemahaman audit

c.    Identifikasi dan penilaian risiko

d.    Identifikasi pengendalian kunci

e.    Evaluasi pengendalian

f.     Penyusunan rencana pengujian

g.    Penyusunan program audit

h.    Pengalokasian sumber daya

• ·Pelaksanaan (Act)

Pada tahap ini auditor mengumpulkan informasi dan bukti-bukti yang kuat untuk melakukan prosedur audit. Pengumpulan infromasi dapat dilakukan melalui diskusi dengan klien, pengumpulan dan pengecekan data hardcopy dan softcopy dari klien dan sebagainya. Bilamana terdapat finding yang membutuhkan koreksi dalam buku, maka perlu didiskusikan pada klien. Tahapan pada tahap pelaksanaan :

a.    Pengujian dan pengumpulan bukti

b.    Evaluasi bukti dan pengambilan kesimpulan

c.    Pengembangan temuan dan rekomendasi

• ·         Pelaporan (Report)

Pada tahap ini dikumpulkan dan didapatkanlah Trial Balance per audit. Auditor memberikan sebuah laporan finding finding ( misalkan mengenai design internal control yang kurang baik)  dan memberikan rekomendasi kepada klien bagaimana memperbaikinya. Tahapan dalam tahap pelaporan :

a.    Penyampaian simpulan sementara

b.    Penyusunan laporan

c.    Distribusi laporan

d.    Monitoring tindak lanjut

3.    TEKNIK AUDIT DATABASE

           Dalam teknik audit database ini membahas bagaimana melakukan audit pada komponen berikut yang mempengaruhi operasional keamanan penyimpanan data, seperti :

• ·         Perizinan database
• ·         Keamanan sistem operasi
• ·         Fitur kekuatan dan manajemen kata sandi
• ·         Aktivitas pemantauan
• ·         Database enkripsi
• ·         Database kerentanan, integritas, dan proses patching

v  Database Audit Essentials

            Untuk mengaudit database secara efektif, memerlukan pemahaman dasar tentang bagaimana sebuah database bekerja. Pada awal tahun 1990an, aplikasi ditulis menggunakan model client-server, yang terdiri dari sebuah program desktop yang menghubungkan melalui jaringan langsung ke database back end. Ini disebut sebagai aplikasi two-tier. Pada akhir 1990an, aplikasi tiga tingkat menjadi norma. Model baru ini terdiri dari browser web yang terhubung ke aplikasi web tingkat menengah. Tingkat menengah kemudian dihubungkan dengan database backend. Aplikasi tiga tingkat merupakan langkah maju yang bagus. Ini berarti bahwa perangkat lunak khusus tidak perlu diinstal pada setiap workstation klien, dan pembaruan perangkat lunak dapat diterapkan ke server pusat. Klien bisa menjalankan sistem operasi yang mendukung browser dasar. Selain itu, dalam model tiga tingkat, mengamankan database jauh lebih sederhana.

Vendor Database Umum

        Biasanya, keterlibatan audit akan berfokus pada satu atau dua vendor database, seperti Oracle atau DB2. Namun, organisasi berukuran sedang atau besar biasanya akan menggunakan contoh dari banyak platform database yang berbeda.

·         Oracle

·         IBM

·         Mysql

·         Sybase

·         Miscrosoft

F        File program

          Database diimplementasikan sebagai sistem perangkat lunak, dan karena itu, ini terdiri dari seperangkat file sistem operasi inti. File-file ini termasuk file executable yang akan menjalankan sistem manajemen basis data. Ini juga mungkin berisi file program lain yang tidak dapat dieksekusi seperti file bantuan, sumber dan file include, file sampel, dan file penginstalan.

Configuration Values

     Database sangat bergantung pada pengaturan konfigurasi untuk menentukan bagaimana sistem beroperasi.

Nilai konfigurasi berada di berbagai tempat, termasuk yang berikut ini:

• ·         Pada file teks sistem operasi
• ·         Dalam file data
• ·         Pada Windows, tersimpan dalam registri
• ·         Di variabel lingkungan

Nilai konfigurasi digunakan untuk berbagai pengaturan, seperti ini:

• ·         Menetapkan jenis otentikasi atau model kepercayaan
• ·         Menetapkan kelompok mana yang merupakan administrator basis data
• ·         Menentukan fitur manajemen password
• ·         Menentukan mekanisme enkripsi yang digunakan oleh database

Memverifikasi integritas nilai konfigurasi merupakan komponen penting dari audit apapun.

Data File
Database perlu menyimpan data yang mereka pegang dalam file sistem operasi fisik yang typically terdiri dari serangkaian file. Format file biasanya milik, dan file data berisi informasi seperti berikut ini:
• Data disimpan
• Pointer dari satu bidang ke bidang berikutnya atau dari satu baris ke baris berikutnya
• Indeks data, termasuk petunjuk dari indeks ke data fisik

Client/Network Libraries

         Komponen penting dari setiap sistem database adalah klien. Biasanya, kliennya adalah terletak pada sistem remote dari database. Klien juga bisa terhubung dari lokal sistem, yang sering terjadi dengan proses batch. Agar klien dapat terhubung ke database, perpustakaan klien atau driver diperlukan pada mesin klien Ini biasanya terdiri dari satu set executable seperti DLL  dan objek bersama, serta API yang dapat digunakan klien untuk terhubung ke database. Perpustakaan klien sulit untuk dilindungi karena biasanya ada pada sistem jarak jauh dimana kontrol akses jauh lebih sulit untuk dipelihara. Namun, sangat penting untuk menjaga integritas driver klien di lokasi dari tempat administrator atau pengguna biasa sekalipun akan terhubung. 

            Salah satu kelemahan dalam model keamanan adalah integritas perpustakaan klien. Jika driver klien bisa dimanipulasi, kredensial bisa dicuri dengan cukup mudah. Klien driver dapat trojaned, atau bahkan sesuatu yang sederhana seperti keyboard logger pada sistem klien dapat menyebabkan kompromi database. 

Sistem Backup / Restore

            Backup adalah bagian yang sangat penting dari setiap platform database. Kegagalan dalam beberapa component database bukan pertanyaan jika tapi kapan. Backup berisi salinan database. Cadangan bisa ke file terpisah, ke tape, atau ke fasilitas penyimpanan lain. Data yang biasa dicuri, hilang, atau bocor melalui fasilitas backup. Backup seringkali dijamin dengan mengenkripsi data karena ditulis ke file atau dengan mengenkripsi keseluruhan file setelah ditulis.

Pernyataan SQL

            Pernyataan SQL digunakan untuk menarik data dari database. SQL dibangun di sekitar empat pernyataan inti:

 • SELECT, menampilkan subset data dari sebuah tabel

 • INSERT, tambahkan data baru ke sebuah tabel

 • UPDATE, mengubah data yang ada dalam sebuah tabel

 • DELETE, menghapus subset data dari sebuah tabel

Objek Database

• Tabel, menyimpan deretan data dalam satu atau lebih kolom.

• View, pernyataan SELECT di atas tabel atau tampilan lain yang dibuat  meja virtual. Tampilan bisa mengubah nomor atau urutan kolom, bisa di panggil  fungsi, dan bisa memanipulasi data dengan berbagai cara.

• Stored procedure / function, kode prosedural yang bisa dipanggil untuk dieksekusi fungsionalitas  kompleks dalam database. Fungsi mengembalikan nilai. Prosedur  jangan mengembalikan nilai Prosedur tersimpan sangat efisien untuk akses data.

• Trigger, kode prosedural yang dipanggil saat tabel dimodifikasi. Dapat digunakan untuk melakukan tindakan apapun, termasuk modifikasi pada tabel lainnya, bila ada data berubah.

• Indeks,  mekanisme untuk menyediakan pencarian data dengan cepat. Indeks itu rumit objek, dan tuning yang tepat sangat penting untuk kinerja database.

Kamus Data

     Database menyimpan metadata tentang dirinya sendiri, disebut kamus data atau kadang-kadang tabel sistem. Metadata memberitahu database tentang konfigurasi, setup, dan objeknya sendiri. Format kamus data bersifat statis. Metadata dalam kamus data dirancang untuk dimanipulasi.

v  Langkah Uji untuk Mengaudit Database

            Sebelum melakukan audit, diperlukan beberapa alat dasar yaitu harus memiliki daftar periksa item yang perlu diverifikasi. Mulailah dengan bertemu dan berdiskusi dengan administrator database (DBA). Jelas, DBA tidak akan senang dengan gagasan untuk diaudit. Oleh karena itu, lakukan yang terbaik untuk mendekati DBA dengan cara sesantai mungkin. Pastikan DBA mengerti bahwa Anda ada untuk membantu, tidak menghalangi, pekerjaannya.

            Kita akan menemukan dorongan balik pada apapun yang anda inginkan, bahkan dengan kemungkinan mempengaruhi ketersediaan database. Pertama kali Anda sebagai auditor menurunkan database, pekerjaan anda menjadi jauh lebih sulit. 

        Bersiaplah untuk mengoptimalkan waktu saat akan mengakses sistem. Pastikan bahwa akun yang diberikan pada sistem berjalan hanya dengan izin yang dibutuhkan. Segera setelah selesai dengan pekerjaan apa pun, mintalah DBA mengunci akun tersebut. Jangan hapus akun, cukup kunci sampai selesai melakukan audit secara resmi. Kemudian, jika perlu mengumpulkan lebih banyak informasi, DBA hanya bisa membuka akun daripada menciptakannya kembali. 

         Dengan menunjukkan DBA tingkat kewaspadaan ini dengan database, dia akan memberi izin profesional untuk melakukan pekerjaan kita. Berselisih dengan DBA dapat menghasilkan audit yang memberikan sedikit nilai bagi organisasi.

      Setelah dilengkapi dengan beberapa latar belakang tentang database, kami memerlukan sebuah rencana untuk melakukan audit. Banyak langkah yang tercakup di sini hampir sama dengan langkah-langkah yang akan Anda lakukan pada sistem operasi atau audit jaringan, namun harus ditempatkan dalam konteks basis data. Beberapa langkah unik untuk database :

Setup dan General Controls

1. Dapatkan versi database dan bandingkan dengan persyaratan kebijakan perusahaan kita. Pastikan database menjalankan versi perangkat lunak database yang terus didukung vendor.

2. Verifikasi bahwa kebijakan dan prosedur diterapkan untuk mengidentifikasi kapan patch tersedia dan untuk menerapkan patch. Pastikan semua tambalan yang disetujui dipasang sesuai dengan kebijakan pengelolaan basis data Anda.

3. Tentukan apakah sebuah standar build tersedia untuk yang baru sistem database dan apakah baseline tersebut memiliki pengaturan keamanan yang memadai. 

Keamanan Sistem Operasi

            Database yang tidak aman bisa digunakan untuk masuk ke sistem operasi. Sebaliknya, sistem operasi yang tidak aman bisa digunakan untuk masuk ke database. Mengunci satu tetapi tidak dengan kegagalan yang lain untuk memberikan keamanan yang tepat . Namun, database harus mendapatkan yang paling fokus karena database adalah target yang paling "berharga" di jaringan.

4. Pastikan akses ke sistem operasi dibatasi dengan benar.

5. Pastikan bahwa perizinan pada direktori tempat database terinstal, dan file database itu sendiri dibatasi dengan benar. 

6. Pastikan bahwa hak akses pada kunci registri yang digunakan oleh database dibatasi dengan benar. 

Manajemen Akun dan Perizinan

        Manajemen akun sulit pada level apapun hanya karena harus menyediakan dan menghapus pengguna pada waktu yang tepat. Menambahkan kompleksitas database, dan pembuatan akun, manajemen, otentikasi, otorisasi, dan audit bisa menjadi hal yang sulit. Tantangan mengelola akun ditambah dengan risiko inheren dari data sensitif yang biasanya tersimpan dalam database membuat bagian audit ini sangat penting. 

 7. Meninjau dan mengevaluasi prosedur untuk membuat akun pengguna dan memastikan bahwa akun dibuat hanya dengan kebutuhan bisnis yang sah. Juga meninjau dan mengevaluasi proses untuk memastikan bahwa akun pengguna dihapus atau dinonaktifkan secara tepat waktu jika terjadi penghentian atau perubahan pekerjaan. 

Kekuatan Password dan Fitur Manajemen

       Banyak platform database mempertahankan setting autentikasi mereka sendiri. Pastikan bahwa lulus kata-kata dan mekanisme otentikasi tidak menjadi link lemah dalam rantai. Menggunakan keamanan operasi terpadu untuk platform database mana pun memiliki banyak pro dan kontra.

Kelebihannya adalah sebagai berikut:

·        Otentikasi sistem operasi biasanya lebih kuat daripada database otentikasi.

·  Otentikasi sistem operasi biasanya mencakup lebih banyak kata sandi fitur manajemen

·         Fitur manajemen password lebih mungkin diterapkan di tingkat sistem operasi.

 Kontra adalah sebagai berikut:

• ·        Otentikasi ada di luar tangan DBA.
• ·       Pengguna dengan akun sistem operasi dapat mengakses sistem operasi database jika tidak dikonfigurasi dengan benar.

8. Periksa nama pengguna dan kata sandi default.

9. Periksa password yang mudah ditebak. 

10. Periksa kemampuan manajemen password yang diaktifkan.

Tinjau Keistimewaan Database (Review Database Privilege)

Hak istimewa database sedikit berbeda dengan hak akses sistem operasi. Keistimewaan dikelola dengan menggunakan pernyataan GRANT dan REVOKE. Pernyataan GRANT dapat digunakan secara selektif untuk memberikan izin, seperti SELECT, UPDATE, DELETE, atau EXECUTE.

11. Verifikasi bahwa hak akses database diberikan atau dicabut dengan tepat untuk tingkat otorisasi yang diperlukan.

12. Tinjau kembali perizinan database yang diberikan kepada individu dan bukan kelompok atau peran. 

13. Pastikan bahwa hak akses database tidak secara implisit diberikan secara tidak benar.

14. Meninjau SQL dinamis yang dijalankan dalam prosedur tersimpan.

15. Pastikan akses tingkat baris ke data tabel benar dilaksanakan. 

16. Cabut izin PUBLIK jika tidak diperlukan.

Enkripsi data

Enkripsi data diterapkan pada tiga area yang berbeda, atau negara bagian. Data bergerak menggambarkan data dalam transit di seluruh jaringan dan sering dienkripsi menggunakan protokol seperti Secure Sockets Layer (SSL). 

17. Pastikan enkripsi jaringan diimplementasikan.

18. Verifikasi bahwa enkripsi data saat istirahat diterapkan bila sesuai.

19. Verifikasi penggunaan audit database dan pemantauan aktivitas yang sesuai. 

20. Mengevaluasi bagaimana kapasitas dikelola untuk lingkungan database untuk mendukung kebutuhan bisnis yang ada dan yang diantisipasi.

21. Mengevaluasi bagaimana kinerja dikelola dan dipantau untuk lingkungan database untuk mendukung kebutuhan bisnis yang ada dan yang diantisipasi. 

Alat dan Teknologi

Meskipun dapat melakukan sebagian besar audit menggunakan metode manual, tetapi akan sering merasa terbantu untuk menggunakan seperangkat alat untuk melakukan tugas berulang atau teknis. Alat audit dan pemantauan dapat menyediakan bahan baku yang perlu dianalisis dan interpretasikan. Ini adalah nilai tambah yang dimiliki oleh seorang auditor saat menggunakan salah satu alat ini.

Auditing Tools

Alat berguna untuk mencari celah dan celah. Dua perspektif tentang pemindaian database untuk kerentanan dan tambalan biasa terjadi : mencari dan mendokumentasikan sebanyak mungkin kerentanan, dan untuk mengurangi kerentanan malah berfokus pada tambalan apa yang telah diinstal. Pada akhir hari, perlu tahu patch apa yang belum diterapkan dan perlu mengidentifikasi kerentanan kritis dan konfigurasi yang salah.

Monitoring Tools

      Banyak alat dirancang untuk membantu memantau aktivitas basis data. Sebagai auditor, memiliki pengaruh atas penggunaan alat ini untuk mencatat dan mendeteksi akses tidak sah atau berbahaya ke data sensitif. Perlu menentukan peraturan apa yang berlaku untuk database dan kemudian menerjemahkannya ke dalam item tertentu yang dapat diimplementasikan sebagai audit asli atau pemantauan aktivitas yang lebih mendalam. 

      Solusi pemantauan basis data mencakup pendekatan yang memonitor database dengan cara melihat jaringan atau dengan menggunakan klien yang terinstal di host. Beberapa solusi pemindaian menggunakan pendekatan hibrida yang menggabungkan kedua metode ini. 

Master Checklist

Berikut langkah-langkah yang tercantum di sini untuk mengaudit database.

Auditing Database

 Daftar Periksa untuk Database Audit

❑ 1. Dapatkan versi database dan bandingkan dengan persyaratan kebijakan. Verifikasi bahwa database menjalankan versi yang terus didukung vendor.

❑ 2. Verifikasi bahwa kebijakan dan prosedur tersedia untuk mengidentifikasi kapan tersedia patch dan untuk menerapkan patch. Pastikan semua tambalan yang disetujui dipasang sesuai database Anda kebijakan manajemen

❑ 3. Tentukan apakah standar build tersedia untuk sistem database baru dan apakahbaseline itu memiliki pengaturan keamanan yang memadai.

❑ 4. Pastikan akses ke sistem operasi dibatasi dengan benar.

❑ 5. Pastikan hak akses pada direktori tempat database terinstal, dan file database itu sendiri, benar dibatasi

❑ 6. Pastikan hak akses pada kunci registri yang digunakan oleh database benar terbatas.

Daftar Periksa untuk Database Audit

❑ 7. Mengkaji dan mengevaluasi prosedur pembuatan akun pengguna dan memastikan akun tersebut hanya dibuat bila ada kebutuhan bisnis yang sah. Juga tinjau dan evaluasi proses untuk memastikan bahwa akun dihapus atau dinonaktifkan secara tepat waktu di acara penghentian atau perubahan pekerjaan.

❑ 8. Periksa nama pengguna dan kata sandi default.

❑ 9. Periksa password yang mudah ditebak.

❑ 10. Periksa kemampuan manajemen password yang diaktifkan.

❑11. Verifikasi bahwa hak akses database diberikan atau dicabut secara tepat untuk tingkat otorisasi yang dibutuhkan

❑12. Tinjau kembali perizinan database yang diberikan kepada individu dan bukan kelompok atau peran.

❑ 13. Pastikan hak akses database tidak diberikan secara implisit.

❑ 14. Tinjau ulang SQL dinamis yang dieksekusi dalam prosedur tersimpan.

❑ 15. Pastikan bahwa akses tingkat tinggi ke data tabel diimplementasikan dengan benar.

❑ 16. Cabut izin PUBLIK jika tidak diperlukan.

❑ 17. Pastikan enkripsi jaringan diimplementasikan.

❑ 18. Pastikan enkripsi data saat istirahat diterapkan jika sesuai.

❑ 19. Verifikasi penggunaan audit database dan pemantauan aktivitas yang sesuai.

❑ 20. Mengevaluasi bagaimana kapasitas dikelola untuk lingkungan database untuk mendukung yang ada dan persyaratan bisnis yang diantisipasi.

❑ 21. Mengevaluasi bagaimana kinerja dikelola dan dimonitor untuk lingkungan database untuk mendukung kebutuhan bisnis yang ada dan yang diantisipasi.

4    REGULASI

Komunitas bisnis global terus mendorong peraturan dan undang-undang baru yang mempengaruhi dan meningkatkan tanggung jawab perusahaan untuk pengendalian internal.

Kelompok audit internal dan eksternal ditugaskan untuk meninjau proses bisnis dan prosedur untuk memastikan pengendalian yang tepat ada yang melindungi kepentingan bisnis dan konsumen. Sifat global bisnis dan teknologi mendorong kebutuhan akan standar dan peraturan yang mengatur bagaimana perusahaan bekerja sama dan bagaimana informasi dibagi. Kemitraan strategis dan kolaboratif telah berevolusi dengan badan-badan seperti International Organization of Standardization (ISO), International Electrotechnical Commission (IEC), International Telecommunication Union (ITU), dan Organisasi Perdagangan Dunia (WTO). Partisipasi dalam badan standar ini bersifat sukarela, dengan tujuan bersama untuk mempromosikan perdagangan global untuk semua negara.

Bangsa, industri, dan perusahaan memiliki kekhawatiran tentang kerahasiaan, integritas, dan ketersediaan informasi mereka. Standar dan undang- metode yang memastikan kekhawatiran undang adalah dua ini terpenuhi.

Dampak Regulatory terhadap Audit TI

Pertimbangkan Rantai Nilai Porter yang ditunjukkan pada Gambar 17-1. Masing-masing komponen fungsional bisnis saat ini terus menarik tuntutan kemitraan yang lebih tinggi pada organisasi TI untuk mendukung proses bisnis. Hubungan saling terkait antara kontrol TI dan fungsi bisnis pendukungnya telah menciptakan usaha besar untuk mengikat kontrol TI tertentu terhadap proses bisnis yang ada dan yang baru. Upaya tersebut terdiri dari pembuat undang-undang yang berusaha melindungi konsumen, layanan keuangan yang berusaha melindungi aset mereka, membantu penjual mencoba menjual lebih banyak produk, dan bisnis yang berusaha mematuhi persyaratan yang tampaknya berkembang dan tidak konsisten.

Asosiasi Internasional Auditor Internal (IIA) dan Asosiasi Audit dan Pengawasan Sistem Informasi Internasional (ISACA) menerbitkan panduan untuk membantu anggota kelompok audit internal dan eksternal ini dalam membangun kontrol umum dan proses audit.

1.    Sarbanes-Oxley Act dan Dewan Pengawas Akuntansi Perusahaan Publik

(PCAOB) diciptakan untuk memulihkan kepercayaan investor di pasar umum A.S. Tujuan utamanya adalah untuk meningkatkan tanggung jawab perusahaan, meningkatkan pengungkapan keuangan, dan mencegah kecurangan perusahaan dan akuntansi. Dengan demikian, kontrol yang diperlukan untuk kepatuhan terhadap fokus SOX pada kontrol kunci penting untuk memastikan kerahasiaan, integritas, dan ketersediaan data keuangan.

Dampak SOX terhadap Korporasi Publik

SOX mewajibkan eksekutif perusahaan untuk membuktikan kecukupan dan efektivitas pengendalian internal mereka terkait dengan transaksi dan pelaporan keuangan, termasuk pengendalian TI. Kontrol ini harus diaudit secara eksternal, dan sebuah pernyataan kontrol harus disertakan dalam laporan perusahaan tahunan yang diajukan ke Security and Exchange Commission (SEC). CEO perusahaan dan CFO sekarang dimintai pertanggungjawaban atas kualitas dan integritas informasi yang dihasilkan

SOX diminta untuk memeriksa risiko teknologi dan menguji semua kontrol secara menyeluruh. Ini berarti bahwa banyak manajer IS meminta panduan atau bantuan konsultasi untuk memastikan bahwa mereka mematuhi undang-undang yang baru. Karena budaya bisnis yang berbeda yang terlibat dalam korporasi global dan jumlah investor internasional di perusahaan berbasis A.S., komunitas TI global harus menyadari dampak audit keuangan terhadap pengoperasian departemen IS.

Dampak SOX terhadap Departemen IT

Bagi kebanyakan organisasi, layanan TI sekarang menjadi bagian penting dari proses pelaporan keuangan. Aplikasi dan layanan mendukung pembuatan, penyimpanan, pemrosesan, dan pelaporan transaksi keuangan. Kepatuhan SOX juga harus mencakup pengendalian penggunaan teknologi dalam penanganan data, pengolahan, dan pelaporan Departemen TI sekarang harus secara formal menangani perancangan, dokumentasi, implementasi, pengujian, pemantauan, dan pemeliharaan pengendalian internal TI.

Dampak Layanan Pihak Ketiga terhadap Kepatuhan SOX

Langkah-langkah pengendalian ditujukan untuk meninjau dan memantau kontrak dan prosedur yang ada untuk efektivitas dan kepatuhan mereka terhadap kebijakan organisasi. Pembubaran kontrak besar bisa berdampak signifikan terhadap pelaporan keuangan. Dengan demikian akan termasuk dalam panduan pengungkapan oleh petugas perusahaan.

Empat tujuan fungsional untuk mengaudit layanan pihak ketiga dan melakukan outsourcing sebagian besar kegiatan perusahaan yang relevan dengan perusahaan, anak perusahaan korporasi, dan perusahaan multinasional diringkas sebagai berikut:

·         Pernyataan kebijakan mengenai integritas data, ketersediaan, dan kerahasiaan ditentukan oleh manajemen senior dan harus dipelihara dan didukung oleh pengaturan outsource.

·         Persyaratan perlindungan aset harus didefinisikan dan dipahami dengan jelas prinsipal dalam perjanjian outsourcing

·         Tanggung jawab kustodian data dan informasi harus didefinisikan dengan baik dan sesuai dengan.

·         Tingkat layanan harus didefinisikan, terukur, dan dapat diterima oleh kedua belah pihak. Kegagalan untuk memenuhi kesepakatan tingkat layanan harus memiliki beberapa tindakan kompensasi. Tagihan dan faktur harus akurat dan biaya dalam jumlah yang dianggarkan.

Kontrol TI Tertentu yang Dibutuhkan untuk Kepatuhan SOX

Secara umum, kontrol TI berikut harus didokumentasikan dan dievaluasi seefektif sesuai dengan persyaratan SOX:

• Kontrol akses

Akses terhadap data keuangan dan "pribadi yang dilindungi" juga harus dibatasi pada orang-orang yang memiliki alasan bisnis yang sah untuk mengakses.

• Ubah control

Untuk memastikan akurasi, kelengkapan, dan integritas pelaporan keuangan, perusahaan harus memiliki proses pengendalian perubahan yang terdokumentasi dan efektif yang mencakup perubahan pada aplikasi keuangan, semua aplikasi antarmuka, sistem operasi yang mengendalikan server desktop dan host, alat produktivitas yang digunakan untuk membuat ringkasan. analisis, sistem manajemen database, dan jaringan.

Kontrol perubahan aplikasi keuangan merupakan perhatian yang jelas saat meninjau kontrol atas pelaporan keuangan. Seringkali, auditor kepatuhan belum menilai risiko pengendalian perubahan yang tidak memadai untuk sistem antarmuka, infrastruktur basis data, sistem operasi, sistem jaringan, atau konfigurasi perangkat keras. Bahkan kelompok internal IS mungkin tidak menyadari relevansi kontrol yang didokumentasikan dan ditegakkan di bidang ini terkait dengan kegiatan pelaporan keuangan. Analisis terbaru oleh pakar penilaian risiko telah menunjukkan bahwa metode kontrol perubahan yang tidak memadai dapat menyebabkan hilangnya integritas informasi dalam aplikasi keuangan dan sistem data. Risiko potensial meliputi pelaporan yang tidak akurat atau pelaporan yang tidak lengkap.

• Manajemen data

Manajemen data mencakup pengelolaan data logis dan fisik serta identifikasi dan perlindungan data penting, terutama data yang berkaitan dengan pemrosesan dan pelaporan keuangan.

Transfer Data Antar : Kesalahan yang ditemukan dalam proses ekstraksi, transformasi, dan unduhan harus dipisahkan, dilaporkan, dan dibersihkan dalam jangka waktu yang wajar untuk memastikan pelaporan keuangan yang akurat

Struktur Database : Kompatibilitas sistem manajemen basis data yang digunakan untuk menyimpan data keuangan itu penting. Jika data transaksional yang digunakan untuk pelaporan keuangan disimpan dalam struktur data yang berbeda, integritas penjumlahan, interpretasi, dan analisis dapat terancam. Jika struktur data yang berbeda diperlukan, maka kontrol kompensasi harus dilakukan untuk memvalidasi kompilasi data akhir.

Konsistensi Elemen Data : Banyak perusahaan menjalankan beberapa sistem akuntansi yang menggunakan terminologi yang berbeda untuk mewakili informasi yang sama atau terminologi yang sama untuk mewakili informasi yang berbeda. Oleh karena itu, file metadata dan kamus data harus digunakan untuk memastikan interpretasi yang konsisten terhadap elemen data utama.

Pengendalian Fisik Data  : Kontrol fisik data sangat penting bagi integritas pelaporan keuangan. Jika fasilitas di mana server, workstation, dan laporan hard copy berada tidak diamankan, maka tampilan atau perubahan yang tidak sah dapat membahayakan transaksi dan / atau data.

Cadangan data          Waktu dan frekuensi proses backup harus ditentukan oleh kebutuhan bisnis untuk pemulihan data jangka pendek dalam situasi bermasalah. Rencana pemulihan bencana dan kelanjutan bisnis bukanlah bagian yang melekat pada persyaratan terbaru untuk kepatuhan SOX namun sangat penting untuk ketahanan bisnis. Lihat Bab 4 untuk informasi tambahan tentang pemulihan bencana.

• Operasi TI

Kontrol operasi TI melampaui pengelolaan perangkat keras dan pusat data yang jelas. Sehubungan dengan akuisisi lingkungan TI, ada kontrol atas definisi, akuisisi, pemasangan, konfigurasi, integrasi, dan pemeliharaan infrastruktur TI.

Komponen perangkat lunak sistem operasi mencakup kontrol atas akuisisi, implementasi, konfigurasi, dan pemeliharaan perangkat lunak sistem operasi, sistem manajemen basis data, perangkat lunak middleware, perangkat lunak komunikasi jaringan, perangkat lunak keamanan, dan utilitas

• Operasi jaringan

Pengolahan tentang jaringan dalam sistem agar dapat melindungi dari ancaman penyerangan virus, warm, dan ancaman lainnya.

• Manajemen asset

Audit pengelolaan aset sebagian besar berkaitan dengan otorisasi, pengeluaran keuangan, dan depresiasi dan pelaporan yang tepat. pengelolaan aset yang dapat ditinjau meliputi persediaan, pelepasan aset, pengelolaan perubahan inventori aset, dan keseluruhan pemahaman tentang prosedur asset.

  

1   2. Gramm-Leach-Bliley Act

Undang-undang ini adalah Undang-Undang Modernisasi Jasa Keuangan. Tindakannya, yang lebih dikenal dengan Gramm-Leach-Bliley Act (GLBA), diarahkan terutama untuk memungkinkan fungsi dan hubungan yang diperluas di antara institusi keuangan. Undang-undang tersebut mencakup bagaimana dan dalam keadaan apa perusahaan induk bank dapat melakukan afiliasi baru dan terlibat dalam kegiatan yang sebelumnya dibatasi.

Dari perspektif dampak terhadap pengendalian internal, bagian GLBA Title V memberikan serangkaian peraturan khusus yang mengatur bagaimana informasi individual untuk pelanggan lembaga keuangan dapat dibagi. GLBA mensyaratkan bahwa perusahaan keuangan mengungkapkan kepada pelanggan tentang kebijakan dan praktik privasi lembaga tersebut. 

3.    California SB 1386

California SB 1386 adalah salah satu undang-undang negara yang paling awal dan pasti yang paling terlihat terkait dengan pelanggaran keamanan yang menyebabkan informasi pribadi diungkapkan.

Termasuk dalam undang-undang adalah definisi tentang apa yang dianggap sebagai informasi pribadi, metode untuk mengevaluasi apakah informasi telah diungkapkan secara tidak sah, dan persyaratan untuk pemberitahuan warga negara California.

2.    Undang-undang Portabilitas dan Akuntabilitas Asuransi Kesehatan tahun 1996

HIPAA adalah bagian undang-undang yang sangat besar dan kompleks. Tindakan tersebut mencakup dua bagian. Judul I memberikan jaminan kesehatan setelah karyawan kehilangan pekerjaan. Judul II membahas tindakan administratif yang dimaksudkan untuk menyederhanakan dan membakukan informasi kesehatan.

5.    Standard an Kerangka Kerja

Pada tahun 1970-an, kekhawatiran meningkatnya kebangkrutan perusahaan dan keruntuhan finansial mulai terjadi.  Dalam upaya untuk mencegah intervensi pemerintah, sebuah sektor swasta yang disebut Komite Organisasi Sponsoring (COSO) berinisiatif untuk meningkatkan kualitas pelaporan keuangan, dimulai pada tahun 1985. COSO meresmikan konsep pengendalian internal dan kerangka kerja pada tahun 1992.

COSO

Committee of Sponsoring Organizations of the Treadway Commission (COSO), adalah suatu inisiatif dari sector swasta yang dibentuk pada tahun 1985. Tujuan utamanya adalah untuk mengidentifikasi faktor-faktor yang menyebabkan penggelapan laporan keuangan dan membuat rekomendasi untuk mengurangi kejadian tersebut. COSO menerbitkan panduan formal pertama untuk pengendalian internal, pada tahun 1992.

Kerangka Pengendalian Terpadu Internal

Pengendalian internal terdiri dari lima komponen yang saling terkait:

• -       control environment adalah dasar bagi semua komponen pengendalian internal lainnya, memberikan struktur.
• -       Risk assessment adalah identifikasi dan analisis risiko yang relevan dengan pencapaian tujuan yang membentuk dasar penentuan bagaimana risikonya harus dikelola.
• -       Control activities adalah kebijakan dan prosedur yang membantu untuk memastikan arahan manajemen dan membantu untuk memastikan bahwa tindakan yang diperlukan diambil untuk mengatasi risiko.
• -       Information and Communicatio,  Menurut COSO, informasi harus diidentifikasi, ditangkap, dan dikomunikasikan.

-       Monitoring, sistem pengendalian internal perlu dipantau.

Konsep Kerangka Kerja Manajemen Risiko-Terpadu

Kerangka manajemen risiko perusahaan diarahkan untuk mencapai entitas tujuan, yang ditetapkan dalam empat kategori:

• -       Strategic,  Tujuan tingkat tinggi, selaras dengan dan mendukung misinya
• -       Operations, Efektif dan efisien penggunaan sumber dayanya
• -       Reporting, Reliabilitas pelaporan
• -       Compliance, Permohonan dengan hukum dan peraturan yang berlaku

Manajemen risiko perusahaan terdiri dari delapan komponen yang saling terkait. Berasal dari cara manajemen menjalankan perusahaan dan terintegrasi dengan manajemen proses.

• -        Internal environment
• -       Objective setting
• -       Event identification
• -       Risk assessment
• -        Risk response
• -       Control activities
• -       Information and communication
• -       Monitoring

COBIT

Control Objectives for Information and related Technology (COBIT) adalah sebuah control kerangka kerja TI yang diterbitkan oleh Information Technology Governance Institute (ITGI) pada tahun 1994 bekerja sama dengan ISACA.

ITIL

IT Infrastructure Library (ITIL) dikembangkan oleh pemerintah Inggris pada pertengahan- 1980an dan telah menjadi standar de facto untuk praktik terbaik dalam penyediaan infrastruktur TI manajemen dan pemberian layanan.

ISO 27001

Sejak didirikan pada tahun 1947, International Organization for Standardization (ISO) telah melakukannya menciptakan sejumlah standar untuk manajemen keamanan jaringan, pengembangan perangkat lunak, dan kontrol kualitas.

Kerangka dan Standar

Kerangka dan standar hanya menyediakan struktur dan panduan yang dibutuhkan agar organisasi menyesuaikan dengan kebutuhan spesifik. Kerangka dan standar berguna untuk:

-          membimbing tujuan pengendalian dan aktivitas pengendalian,

-          mengembangkan tata kelola, manajemen risiko, dan kepatuhan,

-          memberikan panduan kepada auditor untuk mendasarkan audit mereka.

Secara umum, kerangka kerja adalah seperangkat aturan dan gagasan konseptual yang menyediakan struktur ke situasi yang kompleks dan beragam. Meskipun kerangka kerja bersifat kaku dalam kerangkanya, namun tetap fleksibel.

6.    MANAJEMEN RESIKO

Hanya beberapa tahun yang lalu, firewall dan perangkat lunak antivirus adalah semua yang kebanyakan organisasi yang digunakan untuk mengurangi risiko. Dalam beberapa tahun terakhir, namun, ancaman lansekap telah berubah jauh. Hari ini, ancaman insider yang lebih jelas, ribuan varian malware sedang didistribusikan, dan pemerintah telah diberlakukan Undang-undang yang memerlukan pelaksanaan berbagai kontrol. Sebagai akibatnya, proses manajemen risiko formal sekarang harus menjadi bagian dari setiap IT audit program.

Manfaat manajemen resiko

Tidak diragukan lagi potensi manajemen risiko itu masih dengan baik dirahasiakan. Selama beberapa tahun, banyak organisasi telah meningkat efektivitas mereka kontrol IT atau dikurangi biaya mereka mempekerjakan praktik manajemen risiko dan risiko-analisis suara. Ketika manajemen memiliki pemandangan perwakilan organisasi itu eksposur, dapat mengarahkan sumberdaya yang sesuai untuk mengurangi bidang tertinggi risiko daripada menghabiskan sumber daya yang langka di daerah yang memberikan sedikit atau tidak ada pengembalian atas investasi (ROI). Hasil akhirnya adalah tingkat pengurangan risiko yang lebih tinggi untuk setiap dolar yang dihabiskan.

Manajemen risiko dari perspektif Eksekutif

Kebenaran adalah, bisnis adalah semua tentang risiko dan imbalan. Eksekutif diwajibkan untuk menimbang manfaat investasi dengan risiko yang terkait dengan mereka. Akibatnya, sebagian besar memiliki akan datang cukup mahir di mengukur risiko melalui analisis ROI, indikator kinerja utama dan berbagai alat analisis keuangan dan operasional lainnya. Akibatnya, beberapa jenis analisis keuangan biasanya diperlukan untuk membuat kasus busi-ness untuk investasi di kontrol tambahan.

Mengatasi risiko

Risiko dapat diatasi dalam tiga cara: menerima , mengurangi atau transfer. Metode yang tepat sepenuhnya tergantung pada nilai keuangan risiko versus investasi yang dibutuhkan untuk mengurangi ke tingkat yang dapat diterima atau transfer ke pihak ketiga

Risiko penerimaan

Nilai keuangan risiko ini sering lebih kecil dari biaya mengurangi atau memindahkannya. Dalam kasus ini, opsi paling masuk akal akan menerima risiko. Namun, jika organisasi-bantuan kepada memilih untuk menerima risiko, itu harus menunjukkan bahwa risiko memang dinilai dan dokumen alasan di balik keputusan.

Mitigasi risiko

Ketika risiko memiliki nilai keuangan yang signifikan, hal ini sering lebih sesuai untuk mengurangi risiko daripada menerimanya. Dengan beberapa pengecualian, biaya pelaksanaan dan mempertahankan-ing kontrol yang harus kurang dari nilai moneter risiko yang dikurangi. Kami menunjukkan bagaimana untuk menetapkan nilai moneter untuk risiko kemudian dalam bab ini.

Pengalihan risiko

Industri asuransi didasarkan pada risiko transferensi. Organisasi sering membeli asuransi untuk menutupi biaya pelanggaran keamanan atau kegagalan bencana system. Hal ini penting untuk dicatat bahwa perusahaan asuransi yang menawarkan jenis kebijakan sering memerlukan bahwa pemegang polis melaksanakan kontrol tertentu. Kegagalan untuk mematuhi persyaratan kontrol dapat meniadakan kebijakan.

Kuantitatif vs Analisis kualitatif risiko

Risiko dapat dianalisis dalam dua cara: kuantitatif dan kualitatif. Seperti apa pun, masing-masing memiliki kelebihan dan kekurangan. Dimana pendekatan kuantitatif adalah lebih objektif dan mengungkapkan risiko dalam istilah keuangan yang pengambil keputusan dapat lebih mudah membenarkan, itu juga lebih memakan waktu. Pendekatan kualitatif lebih cocok untuk pres-THT pemandangan bertingkat-tingkat risiko, tetapi hal ini dapat lebih subyektif dan oleh karena itu sulit untuk diperkuat.

Analisis kuantitatif risiko

Dengan sedikit pengecualian, baik yang berhubungan dengan sumber daya keuangan, fisik, atau teknologi, jenis risiko dapat dihitung dengan rumus universal yang sama. Risiko dapat didefinisikan oleh perhitungan berikut: risiko = aset nilai × ancaman × kerentanan.

Unsur-unsur risiko

Seperti yang Anda lihat dalam persamaan sebelumnya, risiko terdiri dari tiga unsur: nilai aset, ancaman dan kerentanan. Memperkirakan elemen-elemen ini dengan benar penting untuk menilai risiko secara akurat.

·         Assets (asset)

Biasanya digambarkan sebagai nilai moneter, aset dapat didefinisikan sebagai sesuatu yang layak untuk sebuah organisasi yang dapat rusak, terganggu, atau dihancurkan oleh tindakan disengaja atau tidak disengaja.

·         Threats (ancaman)

Ancaman dapat didefinisikan sebagai acara potensial yang, jika terwujud, akan menyebabkan dampak yang tidak diinginkan.

·         Vulnerabilities (kerentanan)

Kerentanan dapat didefinisikan sebagai ketiadaan atau kelemahan kumulatif kontrol melindungi-ing aset tertentu. Kerentanan diperkirakan sebagai persentase berdasarkan tingkat kontrol kelemahan.

Aplikasi praktis

Sekarang bahwa kita sudah didefinisikan bagaimana menganalisis risiko, kita dapat mulai memasukkannya ke dalam praktek. Berikut adalah beberapa contoh tentang bagaimana persamaan ini relevan dalam itu serta daerah lain.

Skenario risiko fisik

Pemerintah AS salam pusat komando dan kontrol di instalasi militer di Timur Tengah sangat penting untuk kemampuan untuk beroperasi di wilayah itu. Jika fasilitas ini hancur, itu mungkin akan menyebabkan hilangnya kehidupan (dalam fasilitas dan di bidang), merusak fasilitas itu sendiri, dan kemunduran untuk tujuan militer.

Dalam contoh ini, aset yang merupakan pusat komando dan kontrol. Nilai sebenarnya dari pusat komando dan kontrol termasuk kehidupan para prajurit yang akan terpengaruh, komando dan kontrol fasilitas itu sendiri, dan tujuan militer yang akan pergi tak terpenuhi dalam hal kerugian yang akan terjadi.

IT risiko skenario

IT audit Direktur Nasional pengecer telah menetapkan bahwa iklim hukum adalah chang-ing terkait dengan informasi kartu kredit yang dipercayakan perusahaan. Sampai sekarang, perusahaan tidak dianggap risiko pengungkapan informasi nasabah yang pribadi atau kredit-kartu-spesifik.

Analisis kuantitatif risiko dalam praktek

Jika Anda belum mulai mengidentifikasi ancaman organisasi Anda saat ini, ini akan menjadi berharga untuk melakukannya. Dari sana, mengidentifikasi ancaman baru dapat latihan mental sehari-hari. Sebagai bisnis atau perubahan teknologi, Anda harus bertanya, apa ancaman baru Apakah perubahan ini memperkenalkan? Jika menyadari, bagaimana ancaman ini mempengaruhi bisnis Anda? Ketika Anda mengidentifikasi ancaman yang signifikan dan ingin membuat bisnis pembenaran untuk pembelian kontrol tambahan, Anda dapat menggunakan perhitungan sebelumnya untuk mendukung kasus Anda.

Penyebab umum untuk ketidakakuratan

Kebanyakan analisis risiko berusaha hari ini mengakibatkan bottom-line perkiraan yang jauh dari sasaran. Sayangnya, ketika manajemen organisasi kehilangan iman dalam risiko informa-tion yang disajikan untuk itu, ia cenderung untuk mengabaikan sejumlah permintaan untuk mitigasi risiko investasi yang tidak proporsional. Manajemen tertarik berinvestasi sumber daya yang terbatas di daerah yang akan membuat uang organisasi atau akan menghemat uang organisasi. Ini adalah mengapa sangat penting bahwa Anda hadir analisis risiko yang padat setiap kali mendekati manajemen sumber daya tambahan. Berikut ini adalah penyebab paling umum dari risiko analisis ketidakakuratan.

Kegagalan untuk mengidentifikasi aset, ancaman, atau kerentanan

Penyebab paling umum dari ketidakakuratan dalam proses analisis risiko adalah kegagalan untuk mengidentifikasi aset, ancaman, dan kerentanan.

Estimasi tidak akurat

Sayangnya, cukup banyak estimasi terlibat dalam menganalisis risiko, yang membuatnya ilmu yang tepat. Banyak kesalahan dapat dikaitkan dengan fakta ini.

ASET Pendekatan tradisional untuk analisis risiko tidak memperhitungkan biaya yang diakibatkan dari kompromi yang di luar hilangnya aset itu sendiri.

Ancaman Tidak seperti aset atau kerentanan, ancaman adalah satu-satunya unsur persamaan analisis risiko yang selalu berasal dari nilai satu.

Kerentanan Seperti telah dibahas sebelumnya, kerentanan adalah tidak adanya atau kelemahan dalam kontrol kumulatif. Oleh karena itu, untuk mengidentifikasi kerentanan, kita harus memahami kekuatan kontrol. Risiko analisis kesalahan sering dibuat karena kekuatan kontrol tidak dievaluasi dengan benar atau kontrol kontrol kompensasi tidak diperhitungkan.

Analisis kualitatif risiko

Tidak seperti pendekatan kuantitatif analisis risiko, teknik analisis kualitatif risiko dapat memberikan tampilan tingkat tinggi menjadi risiko perusahaan. Dimana metode kuantitatif berfokus pada rumus, Analisis kualitatif risiko akan berfokus pada nilai-nilai seperti tinggi, menengah, dan rendah atau warna merah, kuning dan hijau untuk mengevaluasi risiko.

IT risiko manajemen siklus hidup

Seperti dengan kebanyakan metodologi, manajemen risiko, bila diterapkan dengan benar, mengambil pada karakteristik siklus kehidupanIni dapat dibagi menjadi beberapa fase, mulai dengan identifikasi informasi aset dan berpuncak dengan manajemen risiko residual. Tahap-tahap khusus adalah sebagai berikut:

·         Tahap 1 mengidentifikasi aset informasi.

·         Tahap 2 diukur dan memenuhi syarat ancaman.

·         Tahap 3 menilai kerentanan.

·         Tahap 4 Remediate kontrol kesenjangan.

·         Tahap 5 mengelola risiko residual.

Tahap 1 mengidentifikasi aset informasi.

Tahap pertama dalam siklus hidup manajemen risiko adalah untuk mengidentifikasi aset informasi organisasi. Untuk menjadi sukses, Anda harus menyelesaikan beberapa tugas:

·         menetapkan nilai-nilai kritis informasi.

·         Mengidentifikasi fungsi bisnis.

·         Peta informasi proses.

·         Mengidentifikasi aset informasi.

·         Menetapkan nilai-nilai kritis untuk aset informasi.

Tujuan dari tahap ini adalah untuk mengidentifikasi semua aset informasi dan menetapkan setiap informa-tion aset kritis nilai tinggi, sedang, atau rendah untuk kerahasiaan, integritas, dan ketersediaan persyaratan.

Tahap 2 diukur dan memenuhi syarat ancaman.

Informasi ancaman mempengaruhi organisasi melalui loyalitas merek berkurang, kehilangan sumber daya, biaya pemulihan, dan tindakan hukum dan peraturan. Ketika ancaman menyadari, biaya-biaya tersebut sering terhitung untuk karena mereka tidak diidentifikasi dengan baik.

Langkah berikutnya dalam siklus hidup manajemen risiko adalah untuk mengukur dan memenuhi syarat ancaman.

Fase siklus hidup manajemen risiko memerlukan langkah-langkah berikut: menilai bisnis ancaman.

·         Mengidentifikasi ancaman teknis, fisik, dan administrasi.

·         Mengukur dampak ancaman dan probabilitas.

·         Mengevaluasi arus proses untuk kelemahan.

·         Mengidentifikasi komponen proses ancaman.

Tahap 3 menilai kerentanan.

Pada fase ini, kita akan menilai kerentanan. Dalam memeriksa ancaman, common denominator adalah aset informasi, karena ancaman masing-masing terikat aset informasi. Ketika menilai kerentanan, di sisi lain, common denominator adalah proses informasi. Kami akan terlebih dahulu mengidentifikasi komponen proses kerentanan dan kemudian menggabungkan mereka untuk menentukan kerentanan proses kami. Proses kerentanan maka akan dikombinasikan untuk menentukan bisnis fungsi kerentanan.

Daripada bekerja dari atas ke bawah (dari fungsi bisnis untuk proses compo-nent), kami akan bekerja dari bawah ke dalam menilai kerentanan. Kita akan menggunakan langkah-langkah berikut dalam menganalisis kerentanan:

·         mengidentifikasi ada kontrol dalam hubungannya dengan ancaman.

·         Menentukan proses komponen kontrol kesenjangan.

·         Menggabungkan kontrol kesenjangan menjadi proses dan kemudian fungsi bisnis.

·         Mengkategorikan kesenjangan kontrol berdasarkan tingkat keparahan.

·         Menetapkan peringkat risiko.

Tahap 4 Remediate kontrol kesenjangan.

Pada titik ini, risiko kami harus dapat dikategorikan sebagai tinggi, menengah atau rendah. Pada awalnya, kita akan fokus pada mengurangi risiko paling parah, karena kita kemungkinan akan melihat kembali tertinggi pada investasi kami. Pada dasarnya, kita dapat mengurangi risiko lebih banyak dengan lebih sedikit uang. Kita akan menggunakan langkah-langkah berikut di kontrol kesenjangan remediasi:

·         Pilih control.

·         Menerapkan kontrol.

·         Memvalidasi kontrol baru.

·         Menghitung ulang penilaian risiko.

Tahap 5 mengelola risiko residual.

Risiko inheren dinamis di alam, terutama ancaman komponen risiko. Sebagai re-Gan, kita akan perlu untuk mengukur risiko terus-menerus dan berinvestasi dalam kontrol baru untuk merespon ancaman yang timbul. Tahap ini terdiri dari dua langkah:

·         membuat risiko dasar

·         menilai kembali risiko

Sumber :

Judul : Audit Berbasis Risiko

Disampaikan oleh : Embharri Manda Nasutian, SE, MM

Tahun 2016

Tgl 29 April 2016, Bogor

Didukung oleh : bpkp (Penikatan Kapasitas APIP Kemenristek dan Dikti dalam Melakukan Audit Berbasis Risiko)