Kejanggalan Situng KPU

Aplikasi
*Front end

Aplikasi front end sepertinya ssudah dilengkapi dengan sistem constraint dan validasi. Hal ini tercermin dari adanya pola terstruktur dimana jika ada penambahan di satu pihak maka akan diikuti dengan pengurangan di pihak lain. Jumlah suara antara Paslon 01 + suara paslon 02 + suara tidak sah = jumlah pengguna hak pilih. Dalam konteks ini jumlah pengguna hak pilih menjadi validator atas total penjumlahan suara paslon 01 dan suara paslon 02.

Dengan adanya validator pengguna hak pilih seharusnya bisa dipastikan isian harus balance. Mungkin yang perlu dipastikan adalah jumlah pengguna hak pilih ini apakah given dari KPU pusat sehingga tidak bisa diubah atau justru hasil penjumlahan otomatis sebagaimana sudah dijelaskan di atas.

Aku
*Back end database

Dengan asumsi aplikasi front end sudah dilengkapi dengan validasi dan constraint, mestinya tidak mungkin ada data yang tidak balance masuk ke sistem. Ternyata ada cukup banyak data yang tidak balance berhasil masuk ke sistem. Dalam situasi seperti ini hal yang sangat logis terjadi adalah ada orang internal KPU yang melakukan injeksi data langsung ke database atau istilah kekiniannya disebut input via back door. Jadi tidak melalui front end aplikasi yg sdh ada validasi dan constraint tadi.

Pertanyaannya, mungkinkah aplikasi sebesar dan sepenting Situng ini tidak dilengkapi dengan pengaman di database? Rasanya tidak masuk akal jika aplikasi Situng tidak dilengkapi dengan trigger dan store procedure untuk menjadi penjaga gawang dalam validasi data agar balance. Mengapa tidak masuk akal? Dengan menggunakan trigger dan store procedure ini, akan bisa mencegah kondisi tidak balance baik yg dilakukan via front end maupun yg diinjeksi langsung ke database. Fungsi ini juga bisa diperluas misalkan untuk mencegah agar data tidak bisa masuk ke sistem jika tidak ada upload form C1 sebagaimana yang dilansir banyak pihak bahwa ada data tanpa C1 bisa masuk ke Situng KPU.

Besar dugaan kami, Situng KPU sebenarnya sudah dilengkapi dengan pengaman di database. Hanya saja dinonaktifkan, agar bisa dilakukan injeksi data langsung ke database. Cilakanya, imudah-mudahan karena lupa- si yang melakukan injeksi langsung ke database tidak mensinkronkan jumlah suara 01 + jumlah suara 02 + suara tidak sah dengan jumlah pengguna hak pilih agar balance.

Kenapa kami katakan mudah-mudahan karena lupa, karena kalau itu disengaja maka potensi kecurangan berarti memang sudah didisain dari awal. Mengapa demikian? Karena kalau pengaman di database tadi (dalam bentuk trigger atau store procedure) diaktifkan kembali, maka sisa suara yang tidak balance tadi harus ditambahkan ke salah satu Paslon agar kondisi balance terjadi sehingga bisa disimpan ke dalam sistem. Dengan demikian terjadi banyak potensi kecurangan dari mulai penggelembungan suara di satu pihak dan pengurangan suara di pihak lain serta penambahan selisih suara (agar kondisi balance bisa terjaga) kepada salah satu Paslon.

Tinggal persoalannya kepada siapa penguasa back end database akan berpihak. Mudah-mudahan bukan seperti ini kejadiannya.

*Audit Trail

Audit trail adalah fitur untuk mengetahui siapa melakukan apa, kapan dan apa yang dilakukan. Agak janggal jika dikatakan aplikasi sepenting Situng tidak dilengkapi fitur audit trail. Dengan mengaktifkan fitur ini akan bisa diketahui siapa saja yang melakukan penggelembungan suara di satu pihak dan pengurangan suara kepada pihak lain. Dari data tersebut bisa dikembangkan apa motifnya, polanya dan lain-lain.

SOP

Dengan melihat fenomena yang ada, disamping melihat ke aplikasi dan back end database, rasanya ada hal lain yang tidak kalah penting yang memicu berbagai persoalan seputar Situng yaitu SOP (standard operating procedure) yang terkesan 'ditabrak'.

Berikut adalah analisis kami terkait dengan SOP:

*Approval data entri

Untuk aplikasi sepenting Situng, rasanya aneh jika tidak ada supervisi atas entri data. Seharusnya apa yang dientri oleh operator tidak boleh langsung tayang, namun harus ada approval dari pihak yang berwenang bahwa data yang diinput sudah benar, oleh karenanya boleh tayang. Yang terjadi saat ini terkesan apa yang diinput bisa langsung tayang. Ketika dikomplain baru dikatakan sebagai salah input. Kalau memang ada mekanisme approval, apakah KPU akan berani mengatakan salah input lagi?

*Approval akses langsung ke database

Dengan adanya data yang tidak balance bisa masuk ke sistem yang mengindikasikan adanya orang internal yang injeksi langsung ke database, rasanya perlu dipertanyakan apakah tidak ada log aksesnya?

Apakah tidak ada SOP terkait akses langsung ke database? Mengapa hal tersebut bisa terjadi? Sebegitu pentingnya kah akses langsung ke database ini? Bagaimana pertanggung jawabannya?

*Tanpa upload form C1 harusnya tidak bisa masuk ke sistem

Hal yang marak juga belakangan ini adalah ketiadaan form C1 namun data bisa masuk ke sistem. Lalu yang jadi rujukan verifikasinya apa?

*Format C1 harusnya dibikin secure. Di kondisi sekarang ini, seharusnya security form C1 bisa dilakukan berlapis, tidak hanya mengandalkan hologram doang misalnya

Adalah hal yang jamak jika seandainya form C1 dilengkapi dengan QR code misalnya. Dengan QR code kita bisa menerapkan security berlapis-lapis, sehingga dugaan adanya form C1 baru misalnya akan dengan sangat mudah bisa ditepis. Demikian juga rekayasa-rekayasa lain seputar keaslian form C1 akan relatif mudah dideteksi.

*Data yang sudah fix mestinya tidak bisa diubah-ubah lagi. Kalaupun diperlukan diubah, harus dapat persetujuan otoritas yang paling tinggi

Help Desk

Rasanya instansi sebesar KPU apalagi menyangkut hajat hidup orang banyak seperti hajatan pemilu ini, KPU perlu memiliki help desk yang tangguh yang bisa merespons komplain dan keluhan masyarakat. Besarnya animo masyarakat dalam mencermati Situng ini perlu dijembatani oleh tim help desk yang tangguh.

Beberapa kondisi di atas kalau tidak segera diatasi akan makin memperparah keadaan. Semakin banyak data yang diinput, potensi ketidakvalidan data akan makin besar.

Oleh karena itu saran kepada KPU, hentikan sementara input data ke Situng. Audit internal atas sistem yang ada. Buat trigger & store procedure di back end database untuk pengaman jika belum ada. Kalau sudah ada, evaluasi algoritma di trigger & store procedure-nya. Rasanya tidak butuh algoritma yang njlimet untuk perhitungan Situng. Sepanjang pengalaman kami dalam develop sistem kemungkinan butuh 1-3 harian untuk evaluasi ini. Selanjutnya lakukan data cleansing khususnya data yang tidak balance dan yang tidak memiliki form C1. Setelah fix, bisa diteruskan input data ke Situng. Kalau perlu perbanyak dukungan help desk untuk menampung komplain dan perbaikan data atas komplain yang diberikan oleh masyarakat. Apalagi jika help desk ini dilengkapi aplikasi untuk mengajukan komplain yang terconnect langsung dengan database Situng. Dengan demikian jika hasil validasi ok, tinggal jalankan query untuk mengeksekusinya. Nggak susah kok bikin help desk demikian.

Yang terakhir yang tidak kalah penting adalah aktifkan fitur audit trail jika memang sudah ada. Kalau belum ada, segera buat. Nggak butuh lama kok bikin fitur ini. Akan lebih baik jika fitur audit trail ini dibuat di-back end database, karena akan bisa juga berfungsi untuk deteksi jika ada hacking ke database dimana informasi tadi bisa diteruskan kepada para pihak yang berkepentingan.

Kepada masyarakat umum, mari kita dorong KPU untuk bebenah. Kasih tenggat waktu kepada KPU untuk bebenah. Kalau tidak juga dilakukan, rasanya tidak ada kata yang lebih tepat utk mendorong dilakukannya audit forensik atas sistem IT KPU. Kondisi seperti yang sudah dilukiskan di atas, jika tidak dilakukan pembenahan akan menimbulkan konflik yang berkepanjangan, apalagi terkait dengan hajat hidup orang banyak seperti pemilu kali ini. Dengan audit forensik ini sekaligus akan bisa menepis tuduhan adanya kecurangan secara terstruktur, sistemik dan masif. Agar bisa dilakukan audit forensik ini, public pressure dirasa akan lebih efektif.

Munawar
Pakar IT tinggal di Depok.