UNIVERSITAS INDONESIA PERANCANGAN PEDOMAN KEAMANAN PENGEMBANGAN APLIKASI : STUDI KASUS PT. APLIKANUSA LINTASARTA KARYA AKHIR

UNIVERSITAS INDONESIA

PERANCANGAN PEDOMAN KEAMANAN PENGEMBANGAN APLIKASI : STUDI KASUS PT. APLIKANUSA LINTASARTA

KARYA AKHIR

SUWARNO PRIBADI 1106122120

FAKULTAS ILMU KOMPUTER PROGRAM STUDI MAGISTER TEKNOLOGI INFORMASI JAKARTA JULI 2013

Perancangan pedoman..., Suwarno Pribadi, FIKOM UI, 2013.

UNIVERSITAS INDONESIA

PERANCANGAN PEDOMAN KEAMANAN PENGEMBANGAN APLIKASI : STUDI KASUS PT. APLIKANUSA LINTASARTA

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

SUWARNO PRIBADI 1106122120

FAKULTAS ILMU KOMPUTER PROGRAM STUDI MAGISTER TEKNOLOGI INFORMASI JAKARTA JULI 2013




KATA PENGANTAR DAN UCAPAN TERIMA KASIH

Puji syukur saya panjatkan kepada Allah SWT, atas berkat rahmat-Nya saya bisa menyelesaikan Karya Akhir ini. Karya Akhir ini dibuat dalam rangka menyelesaikan studi dan memperoleh gelar Magister Teknologi Informasi dari Fakultas Ilmu Komputer Universitas Indonesia. Ucapan terima kasih saya haturkan kepada : 1. Bpk. Ivano dan Bpk. Rizal selaku pembimbing karya akhir ini. 2. PT. Aplikanusa Lintasarta yang telah mendanai biaya kuliah saya dan menjadi tempat studi kasus. Terutama Ibu Yosi selaku GM IT dan rekanrekan di IT Development dan IT Operations yang telah menyediakan waktunya dalam proses pengumpulan data. 3. Rahmawati, Sarah dan Zan, isteri dan anak-anak tercinta yang telah sabar mendukung ayahanda melaksanakan dan menyelesaikan tugas kuliah selama 2 tahun. 4. Orang tua yang telah memberikan dukungan moral dalam penyelesaian kuliah ini. 5. Para Pengajar Fasilkom yang telah memberikan sumbangsih ilmunya yang bermanfaat bagi saya dalam nuansa ilmu maupun pekerjaan dan staf akademik yang telah memberikan layanan yang baik selama kegiatan perkuliahan. Semoga Allah SWT dapat membalas kebaikan semua pihak yang telah membantu saya menyelesaikan studi ini dan semoga karya akhir ini dapat bermanfaat bagi perkembangan ilmu maupun pihak yang membutuhkan.

Depok 8 Juli 2013

Penulis

iv



ABSTRAK

Nama : Suwarno Pribadi Program Studi : Magister Teknologi Informasi Judul : Perancangan Pedoman Keamanan Pengembangan Aplikasi : Studi Kasus PT. Aplikanusa Lintasarta Aplikasi berbasis web dengan kemudahan fitur yang ditawarkan bagi user membuat perusahaan-perusahaan menggunakannya sebagai aplikasi penunjang bisnis mereka. Namun dibalik kemudahan itu, aplikasi ini memiliki celah keamanan berupa suatu kerawanan yang dapat dieksploitasi apabila tidak ditangani dengan baik. Faktor keamanan suatu aplikasi harus diperhatikan tidak hanya saat aplikasi tersebut beroperasi, tapi sudah dimulai sejak aplikasi tersebut masih dalam proses pengembangan. Tidak adanya pedoman keamanan yang dapat dijadikan acuan dalam proses pengembangan aplikasi dapat berakibat pada kurangnya kualitas keamanan aplikasi yang akan dihasilkan. Penelitian ini berusaha menunjukkan suatu proses perancangan pedoman keamanan pengembangan aplikasi berbasis web studi kasus pada perusahaan industri telekomunikasi yang memiliki strategi mengembangkan sendiri aplikasi-aplikasi berbasis web sebagai penunjang bisnisnya. Proses diawali dengan kajian risiko keamanan aplikasi berbasis web dalam proses pengembangan aplikasi yang sudah ada dalam perusahaan tersebut. Dilanjutkan dengan pemilihan kontrol-kontrol untuk mengendalikan risiko hasil kajian tadi. Kajian risiko menggunakan kerangka kerja yang sudah dibakukan di perusahaan dan dikombinasikan dengan kerangka kerja kajian risiko dan kontrol standar dari OWASP dan NIST. Hasil yang diharapkan berupa pedoman keamanan pengembangan aplikasi berbasis web yang sesuai untuk lingkungan studi kasus tersebut.

Kata Kunci : Pedoman Keamanan Aplikasi, OWASP, NIST XII + 57 Halaman; 5 Gambar; 24 Tabel; 5 Lampiran

vi

Universitas Indonesia


ABSTRACT

Name Study Program Title

: : :

Suwarno Pribadi Magister Teknologi Informasi Development Of Application Development Security Guideline : Case Study PT. Aplikanusa Lintasarta

Web base application with the rich fitur that can be offered to the user has motivate many companies to use it as a business application platform. But behind the simplicity, this application has a security vulnerability that can be exploited if not handled properly. Safety factor of the application must be considered not only when the application is in operation, but has started since the application is still under development. The absence of security guidelines that can be used as a reference in the application development process can result in a lack of quality security application that will be generated. This study attempted to show a security guideline development process of designing a web-based application on a case study of the telecommunication industry company who have their own strategies to develop web-based applications to support its business. The process begins with the assessment of security risks in web based application development process existing applications within the enterprise. Followed by the selection of controls to control risk assessment results earlier. Using a risk assessment framework that has been standardized across the enterprise and combined with the framework of risk assessment and control of the OWASP and NIST standards. Results are expected in the form of security guideline fort web-based application development environment in the case study.

Keywords: Guideline for Application Security, OWASP, NIST XII + 57 Pages; 5 Figures; 24 Tables; 5 Attachment

vii



DAFTAR ISI

HALAMAN JUDUL……………………………………………..…………….….i HALAMAN PERNYATAAN ORISINALITAS……………….………………...ii HALAMAN PENGESAHAN ……………………………………………….......iii KATA PENGANTAR …………………………………………………………...iv HALAMAN PERNYATAAN PERSETUJUAN PUBLIKASI KARYA AKHIR UNTUK KEPENTINGAN AKADEMIS ...………………………...…..v ABSTRAK ………………………………………………...…..………………....vi DAFTAR ISI ……………………………………………….……..…………….viii DAFTAR GAMBAR ……………………………………….…………………….x DAFTAR TABEL …………………………………………..…………………....xi BAB 1 PENDAHULUAN .. ............................................................................... 1 1.1 Latar Belakang Masalah ....................................................................... 1 1.2 Identifikasi Masalah dan Pertanyaan Penelitian................................... 2 1.2.1 Faktor Teknologi .................................................................................. 2 1.2.2 Faktor Manusia..................................................................................... 3 1.2.3 Faktor Proses ........................................................................................ 4 1.2.3.1 Proses Operasional dan Pemeliharaan Aplikasi ................................... 4 1.2.3.2 Proses Pengembangan Aplikasi ........................................................... 4 1.3 Ruang Lingkup Penelitian .................................................................... 5 1.4 Tujuan Penelitian.................................................................................. 6 1.5 Manfaat Penelitian................................................................................ 6 1.5.1 Manfaat Akademis ............................................................................... 6 1.5.2 Manfaat Praktis .................................................................................... 6 1.6 Sistematika Penulisan........................................................................... 6 BAB 2 STUDI LITERATUR ............................................................................. 8 2.1 2.1.1 2.1.2 2.1.3 2.1.3.1 2.1.3.2 2.1.4 2.1.4.1 2.1.4.2 2.2 2.2.1 2.3

Landasan Teori ..................................................................................... 8 Ancaman Keamanan Pengembangan Aplikasi Web ........................... 8 Definisi Kebijakan, Standar, Pedoman dan Prosedur .......................... 9 Proses Pembuatan Kebijakan Keamanan Informasi........................... 10 Kerangka Kerja ISO 27001 ................................................................ 10 Kerangka Kerja NIST......................................................................... 10 Best-Practise Pedoman Keamanan Pengembangan Aplikasi ............. 12 OWASP .............................................................................................. 12 NIST ................................................................................................... 13 Penelitian Sebelumnya ....................................................................... 13 Pengembangan Kebijakan dan Pedoman Keamanan Informasi ......... 13 Kerangka Berpikir Penelitian ............................................................. 15

BAB 3 METODOLOGI PENELITIAN .......................................................... 16 3.1 3.2 3.3

Pengumpulan Data ............................................................................. 17 Penilaian Risiko.................................................................................. 18 Pemilihan Kontrol .............................................................................. 19 viii



BAB 4 PROFIL PERUSAHAAN.................................................................... 21 4.1 4.2 4.3

Struktur Organisasi ............................................................................. 21 Struktur Organisasi Teknologi Informasi ........................................... 21 Proses Bisnis Pengembangan Aplikasi .............................................. 23

BAB 5 DATA DAN ANALISA ....................................................................... 24 5.1 5.2 5.3 5.4 5.5

Karakteristik Sistem Aplikasi di Divisi TI Lintasarta ........................ 24 Profil Risiko Ancaman dan Kerawanan ............................................. 24 Hasil Analisa Gap dengan Kontrol Saat Ini ....................................... 26 Pemilihan Rekomendasi Kontrol Baru............................................... 37 Draft Dokumen Pedoman Keamanan Pengembangan Aplikasi Web 45

BAB 6 KESIMPULAN DAN SARAN ............................................................. 54 6.1 6.2

Kesimpulan......................................................................................... 54 Saran ................................................................................................... 54

DAFTAR PUSTAKA ........................................................................................ 56 LAMPIRAN

ix



DAFTAR GAMBAR

Gambar 1.1 Gambar 2.1 Gambar 2.2 Gambar 3.1 Gambar 4.1

Diagram Tulang Ikan ………………………………………….2 Hirarki Hubungan Kebijakan, Standar, Pedoman dan Prosedur ………………………………………………………………….9 Kerangka Berpikir Penelitian ………………...………………15 Langkah-Langkah Penelitian ………………………………...16 Struktur Organisasi TI PT. Aplikanusa Lintasarta …...........…22

x



DAFTAR TABEL

Tabel 2.1 OWASP 10 Ancaman Aplikasi Web ...................................................... 8 Tabel 2.2 Langkah-Langkah Penilaian Risiko NIST ............................................ 11 Tabel 2.3 Rangkuman Penelitian Sebelumnya...................................................... 14 Tabel 3.1 Langkah-Langkah Pembuatan Pedoman ............................................... 18 Tabel 5.1 Hasil Penilaian Tingkat Risiko Inheren OWASP 10 Ancaman Keamanan Aplikasi Web ...................................................................... 25 Tabel 5.2 Hasil Penilaian Risiko Inheren Kerawanan Proses Pengembangan Aplikasi Berdasarkan Self-Assessment Guide NIST 800-26 ............... 25 Tabel 5.3 Jumlah Ancaman Kerawanan Berdasarkan Tingkat Risiko Residual ... 27 Tabel 5.4 Risk Register Kerawanan Teknis Pengembangan Aplikasi Lintasarta . 29 Tabel 5.5 Risk Register Kerawanan Proses Pengembangan Aplikasi Lintasarta . 34 Tabel 5.6 Pemetaan Ancaman Kerawanan dengan Rekomendasi Kontrol Baru .. 38 Tabel 5.7 Pemetaan Kontrol Baru dengan Dokumen Pedoman............................ 46 Tabel Lampiran 1.1 Rekapitulasi Tingkat Risiko Inheren OWASP .................... 59 Tabel Lampiran 1.2 Kemungkinan dan Dampak OWASP .................................. 60 Tabel Lampiran 1.3 Matrik Risiko OWASP ........................................................ 60 Tabel Lampiran 1.4 Rekapitulasi Tingkat Risiko Residual OWASP (Kontrol Saat Ini) ........................................................................................................ 61 Tabel Lampiran 1.5 Rekapitulasi Tingkat Risiko Harapan OWASP (Kontrol Baru) ..................................................................................................... 62 Tabel Lampiran 1. 6 Self Assessment Identifikasi Faktor Kecenderungan Agen Ancaman Keamanan Aplikasi .............................................................. 63 Tabel Lampiran 1. 7 Self Assessment Identifikasi Faktor Kerawanan Keamanan Aplikasi................................................................................................. 77 Tabel Lampiran 1. 8 Self Assessment Identifikasi Dampak Teknis Faktor Kerawanan Keamanan Aplikasi ........................................................... 89 Tabel Lampiran 1. 9 Self Assessment Identifikasi Dampak Bisnis Faktor Kerawanan Keamanan Aplikasi ......................................................... 100 Tabel Lampiran 1. 10 Identifikasi Tingkat Risiko Hasil Self Assessment NIST SP 800-26 ........................................................................................... 109 Tabel Lampiran 1. 11 Tingkat Dampak Risiko Lintasarta ................................ 111 Tabel Lampiran 1. 12 Tingkat Kemungkinan Risiko Lintasarta........................ 111 Tabel Lampiran 1. 13 Tingkat Kategori Risiko Lintasarta ................................ 112

xi



BAB 1 PENDAHULUAN

1.1 Latar Belakang Masalah Sebagai suatu pemain di industri telekomunikasi yang terus beradaptasi dengan kondisi bisnisnya, PT. Aplikanusa Lintasarta, memiliki strategi mengembangkan sendiri aplikasi untuk mendukung kegiatan bisnis mereka yang unik. Aplikasi yang telah dibangun adalah aplikasi untuk kegiatan operasional jasa (produksi, penanganan gangguan dan pemeliharaan jasa Datacom dan VAS), billing, keuangan, procurement dan inventory, serta sumber daya manusia. Aplikasiaplikasi tersebut berbasis web dengan platform teknologi yang beragam. Mayoritas adalah aplikasi berbasis script ASP 3.0, setelahnya ASP.net dan sebagian kecil berbasis PHP dan Java (PT. Aplikanusa Lintasarta, IT Strategic Plan 2011-2015, 2011). Aplikasi tersebut di atas masih terus dikembangkan oleh bagian IT Development & Business Process sesuai dengan dokumen IT Strategic Plan (PT. Aplikanusa Lintasarta, Dokumen Katalog Software, 2011) mengikuti kebutuhan bisnis perusahaan. Dalam dokumen IT Strategic Plan tahun 2013-2018, keamanan sistem TI menjadi suatu prinsip TI baru yang harus diterapkan. Hal ini dibutuhkan untuk memastikan bahwa kebijakan keamanan informasi yang telah diterapkan perusahaan tetap selaras dengan pengembangan aplikasi TI. Akan tetapi prinsip TI tersebut saat ini belum diterjemahkan ke dalam pedoman yang dapat digunakan dalam pekerjaan yang berkaitan dengan pengembangan aplikasi perusahaan. Artinya walaupun pengembangan aplikasi telah memiliki prosedur standar (PT. Aplikanusa Lintasarta, Prosedur Permintaan dan Pengadaan Software, 2012) namun prosedur tersebut belum dibuat berdasarkan pedoman keamanan pengembangan aplikasi yang diturunkan dari prinsip TI seperti yang dimaksud karena pedomannya sendiri belum pernah dibuat. Data perusahaan menunjukkan telah terjadi pelanggaran yang disebabkan kurang amannya aplikasi web yang dikembangkan oleh perusahaan. Pada bulan Maret 1



2

tahun 2012 berdasarkan laporan internal audit telah ditemukan kasus pelanggaran oleh pengguna dengan memanfaatkan celah keamanan di aplikasi berbasis web perusahaan. Kasus ini terjadi akibat pengguna memanfaatkan halaman web untuk admin yang tidak memiliki pengecekan dan memiliki manajemen sesi yang buruk. Sehingga pengguna dengan role biasa bisa masuk ke dalam aplikasi yang diperuntukan bagi admin. 1.2 Identifikasi Masalah dan Pertanyaan Penelitian Dari uraian pada bagian 1.1 dijelaskan bahwa sesuai dengan dokumen TI Strategic Plan yang baru, keamanan sistem TI menjadi suatu Prinsip TI yang harus dipenuhi. Salah satu sistem TI yang dimaksud adalah aplikasi perusahaan. Sementara data menunjukkan adanya pelanggaran yang terjadi akibat aplikasi yang tidak aman. Ada beberapa faktor yang menyebabkan aplikasi menjadi tidak aman yang ditunjukan oleh diagram sebagai berikut :

Celah keamanan di aplikasi Celah keamanan di Server Celah keamanan di Jaringan

Tidak ada pedoman keamanan pengembangan Aplikasi

Teknologi

Manusia Kurangnya awareness Kurangnya Kompetensi

Aplikasi Tidak Aman

Pengembangan Aplikasi Operasional dan Pemeliharaan Aplikasi

Proses

Gambar 1.1 Diagram Tulang Ikan 1.2.1

Faktor Teknologi

Keamanan aplikasi dapat dipengaruhi faktor teknologi seperti celah keamanan bawaan di platform aplikasi, celah keamanan di platform sistem operasi server



3

yang digunakan, maupun celah keamanan di jaringan yang menghubungan server dengan server atau server dengan client. Berdasarkan dokumen Risk Register yang dimiliki divisi TI (PT. Aplikanusa Lintasarta, Dokumen Risk Register Divisi IT, 2012)

aplikasi, server dan jaringan termasuk aset informasi yang dimiliki

perusahaan dan telah dilakukan kajian risiko untuk mengatasi celah kerawanannya yang menghasilkan program kerja dan prosedur rutin disertai dengan pedoman keamanannya. Program kerja dan prosedur rutin ini diaudit setiap semester baik oleh bagian audit internal maupun konsultan audit eksternal sesuai dengan sertifikasi keamanan informasi yang dimiliki yaitu ISO 27001 termasuk kegiatan uji penetrasi terhadap server dan jaringan LAN yang disediakan TI. Selama ini tidak ada catatan temuan mayor berkaitan dengan celah keamanan di server maupun jaringan. Temuan yang terjadi pada bagian masalah sebelumnya merupakan celah kerawanan di disain aplikasi bukan pada platform yang digunakan oleh aplikasi tersebut, bukan pula karena platform sistem operasi ataupun penetrasi di level jaringan. Jadi celah keamanan tersebut tercipta saat aplikasi dalam proses pengembangan. Artinya penyebab aplikasi tidak aman dari faktor teknologi dapat dikendalikan jika proses pengembangan aplikasi tersebut dapat dipastikan menghasilkan aplikasi yang aman. 1.2.2

Faktor Manusia

Pengembangan aplikasi di PT. Aplikanusa Lintasarta dilaksanakan oleh bagian IT Development & Business Process dengan menyewa tenaga ahli dari rekanan dengan kriteria kompetensi yang sudah ditentukan oleh TI Lintasarta sebelumnya. Rekanan sesuai prosedur akan menandatangani non disclosure aggreement mengenai keamanan informasi di Lintasarta dan tenaga ahli rekanan yang pertama kali bekerja sama dengan Lintasarta sesuai prosedur baku wajib diberikan sosialiasi mengenai kebijakan keamanan informasi Lintasarta. Jadi seharusnya faktor kurangnya kompetensi bisa diatasi dengan menyewa tenaga ahli dengan kemampuan yang dibutuhkan dan faktor awareness telah diatasi dengan kewajiban sosialisasi tersebut.



4

1.2.3

Faktor Proses

1.2.3.1 Proses Operasional dan Pemeliharaan Aplikasi Operasional sistem TI Lintasarta berada di bawah tanggung jawab bagian IT Operations. Bagian IT Operations telah memiliki dan menjalankan prosedurprosedur yang sudah dibakukan terkait kebijakan keamanan informasi TI dan telah memiliki pedoman keamanan yaitu dokumen Kebijakan Keamanan TI yang berisi seperti pengaturan hak akses, standarisasi password, pengelolaan server, penanganan virus, dan manajemen perubahan TI. Ada pula prosedur terkait dengan pemeliharaan jaringan, dan DRC sistem TI. Server-server perusahaan dipelihara secara rutin seperti pelaksanaan update patch dan pemantauan kapasitas dan performansi. Setiap bulan juga dilakukan vulnerability scan pada server dengan aplikasi Nesus, sementara untuk keamanan client selain anti virus ada juga aplikasi LAN Desk Desktop Management untuk mengendalikan apa yang bisa diinstall dan dijalankan oleh user pada PC atau Notebook kerjanya. Operasional sistem TI juga diaudit rutin 2 kali setahun oleh auditor eksternal dan internal masing-masing untuk lingkup kualitas mutu ISO 9000 dan keamanan informasi ISO 27001. Dengan demikian faktor teknologi server dan jaringan, serta proses operasional dan pemeliharaan aplikasi telah memiliki kontrol-kontrol yang dirasa cukup untuk mengatasi keamanan aplikasi. 1.2.3.2 Proses Pengembangan Aplikasi Celah keamanan aplikasi menjadi suatu faktor kerawanan yang tereksploitasi pada kasus pelanggaran pada bagian masalah di atas. Celah keamanan ini lebih lanjut sebenarnya dapat diidentifikasi pada saat proses pengembangan aplikasi tersebut masih berjalan. Namun ternyata untuk kondisi saat ini belum ada suatu acuan atau pedoman yang memandu proses pengembangan aplikasi untuk melakukan kontrol atas ancaman keamanan aplikasi apa saja yang harus diperhatikan di setiap tahapan pengembangan tersebut. Hal ini dimungkinkan karena kajian risiko kebijakan keamanan TI yang dilakukan sebelumnya adalah kajian risiko berbasis aset sehingga kurang maksimal menggali potensi ancaman dari sudut proses pengembangan aplikasi.



5

Selanjutnya, untuk menyatakan aplikasi perusahaan sudah memenuhi prinsip IT mengenai keamanan dibutuhkan suatu standar atau kriteria mengenai keamanan aplikasi. Kriteria ini layaknya menjadi suatu syarat kebutuhan dalam pengembangan aplikasi. Dan untuk memastikan pengembangan aplikasi dalam prosesnya berhasil membuat aplikasi yang mampu memenuhi kriteria keamanan tersebut dibutuhkan suatu pedoman yang harus dipatuhi dalam proses pengembangan aplikasi. Sementara saat ini dokumen pedoman keamanan aplikasi masih belum ada. Oleh karenanya dibutuhkan dokumen pedoman keamanan aplikasi yang dapat dijadikan acuan dalam pengembangan aplikasi maupun proses QC saat aplikasi akan dioperasionalkan. Sesuai paparan di atas Penulis berargumentasi bahwa mayoritas permasalahan ketidakamanan aplikasi untuk kondisi Lintasarta disebabkan oleh aplikasi yang tidak aman yang tercipta melalui proses pengembangan aplikasi yang tidak memiliki pedoman keamanan pengembangan aplikasi. Karena selain proses pengembangan aplikasi, ternyata faktor teknologi, manusia serta proses operasional dan pemeliharaan telah memiliki kontrol-kontrol berdasarkan prosedur rutin maupun program kerja yang dibuat berdasarkan kajian risiko sesuai sertifikasi ISO 27001. Selanjutnya pertanyaan penelitian yang penulis ajukan untuk mencari solusi atas permasalahan tersebut adalah : “Pedoman keamanan pengembangan aplikasi seperti apakah yang sesuai untuk mendukung pengembangan aplikasi berbasis web pada PT. Aplikanusa Lintasarta ?” 1.3 Ruang Lingkup Penelitian Dalam melakukan penulisan ini, penulis mengambil studi kasus di PT. Aplikanusa Lintasarta. Lingkup penelitian terbatas pada pembuatan pedoman keamanan pengembangan aplikasi bukan pada implementasi, audit, monitoring dan perubahannya. Penelitian juga dibatasi hanya pada pedoman untuk kegiatan pengembangan aplikasi bukan pada tahapan operasional aplikasinya.



6

1.4 Tujuan Penelitian Penelitian ini bertujuan untuk menyusun pedoman keamanan pengembangan aplikasi yang dapat menjawab pertanyaan penelitian dan mengatasi permasalahan yang telah dijelaskan dalam bagian identifikasi masalah. 1.5 Manfaat Penelitian Manfaat dari penelitian ini adalah sebagai berikut : 1.5.1

Manfaat Akademis

Penelitian ini diharapkan dapat menjadi tambahan referensi di bidang keamanan aplikasi berbasis WEB. 1.5.2

Manfaat Praktis

Dokumen pedoman keamanan pengembangan aplikasi yang dihasilkan nantinya diharapkan dapat menjadi masukan sebagai dokumen yang dapat dijadikan standar keamanan pengembangan aplikasi berbasis web di PT. Aplikanusa Lintasarta. Atau pada perusahaan dengan industri dan strategi pengembangan aplikasi internal sejenis. 1.6 Sistematika Penulisan Dalam penyusunan proposal penelitian ini penulis membagi tulisan ke dalam 3 bab sebagai berikut : Bab 1 adalah bagian pendahulan berisikan penjelasan latar belakang beserta dengan

data

yang

mendukung

munculnya

permasalahan,

identifikasi

permasalahan dan pertanyaan penelitian, tujuan penelitian, manfaat penelitian dan sistematika dari penulisan. Bab 2 adalah Studi literatur, bagian yang berisikan berbagai teori yang digunakan untuk mendukung penelitian ini. Pada bagian ini akan diuraikan teori mengenai hal-hal pokok mengenai keamanan informasi, keamanan aplikasi, dan pembuatan pedoman keamanan aplikasi. Kemudian akan diuraikan studi-studi sebelumnya mengenai pembuatan kebijakan atau pedoman keamanan informasi, dan keamanan aplikasi berbasis web. Selanjutnya penulis akan membuat kerangka



7

konseptual untuk penelitian ini yang dibangun berdasarkan landasan teori dan studi literatur yang telah diuraikan. Bab 3 adalah bagian yang berisi penjelasan metodologi atau langkah-langkah sistematis yang penulis lakukan dalam penelitian ini, teknik pengambilan data dan bagaimana cara analisis kondisi saat ini untuk mendapatkan kajian manajemen risiko sehingga diperoleh kontrol yang tepat untuk digunakan menjadi pedoman keamanan pengembangan aplikasi. Bab 4 adalah bagian yang berisi penjelasan mengenai profil perusahaan tempat Penulis melakukan studi kasus. Bab 5 adalah bagian mengenai pembahasan data yang berhasil dikumpulkan sesuai dengan metode yang telah dijelaskan pada Bab 3, serta analisa dan hasil yang diperoleh karya akhir ini. Bab 6 berisi kesimpulan dan saran dari karya akhir ini.



BAB 2 STUDI LITERATUR

2.1 Landasan Teori 2.1.1

Ancaman Keamanan Pengembangan Aplikasi Web

Whitman (2012) dalam bukunya menyebutkan terdapat 20 ancaman keamanan dalam proses pengembangan aplikasi secara umum. Sementara OWASP (2010) berdasarkan tingkat ancamannya menyebutkan 10 ancaman dalam keamanan aplikasi yang secara spesifik dalam lingkup aplikasi berbasis web. Sesuai dengan topik karya akhir ini lingkup ancaman yang dimaksud adalah untuk aplikasi web dan proses pengembangannya. Identifikasi ancaman perlu dikaitkan dengan kerawanan sehingga bisa dilihat sebagai suatu faktor risiko. Selanjutnya dapat dilakukan kajian melalui kerangka kerja kajian risiko untuk memperoleh kontrolkontrol yang tepat atas risiko tersebut. Ancaman apa yang perlu dinyatakan sebagai faktor risiko tergantung dari proses kajian threat assessment yang sesuai dengan situasi dan kondisi dari organisasi tersebut. Tabel 2. 1 OWASP 10 Ancaman Aplikasi Web

Ancaman

No 1

Injeksi SQL

2

Cross Site Scripting (XSS)

3

Otentikasi dan Manajemen Sessi yang Buruk

4

Referensi Obyek Langsung yang tidak aman

5

Cross Site Request Forgery (CSRF)

6

Kesalahan Konfigurasi keamanan

7

Penyimpanan Kriptografi yang tidak aman

8

Gagal membatasi akses URL

9

Perlindungan Lapisan Transport yang tidak cukup

10

Redirection dan Forward yang tidak divalidasi

Sumber : (OWASP, 2010)

8



9

2.1.2

Definisi Kebijakan, Standar, Pedoman dan Prosedur

Secara definisi, dalam konteks keamanan informasi, (SANS, 2013) (Johnson, 2009) kebijakan (policy) adalah dokumen yang menyatakan kebutuhan atau aturan yang spesifik yang harus dilaksanakan. Dalam hal keamanan informasi, biasanya kebijakan berupa poin-poin spesifik yang melingkupi area tertentu. Sedangkan Standar adalah sekumpulan kebutuhan spesifik suatu sistem atau prosedur yang harus dipenuhi oleh semua orang seperti contohnya panjang minimal karakter password email. Pedoman (guidelines) adalah sekumpulan panduan spesifik atas suatu

sistem

atau

prosedur

berdasarkan

best-practise

yang

sangat

direkomendasikan untuk dilaksanakan. Sedangkan prosedur adalah instruksi langkah demi langkah agar para pekerja dapat melakukan pekerjaannya sesuai dengan kebijakan, standar dan pedoman. Secara hirarki hubungan antara kebijakan, standar, pedoman dan prosedur adalah sebagai berikut (Johnson, 2009) dimana kebijakan berada pada hirarki paling atas untuk dipatuhi dan menjadi dasar pembuatan dokumen di bawahnya.

Kebijakan

Standar

Pedoman

Prosedur

Gambar 2.1 Hirarki Hubungan Kebijakan, Standar, Pedoman dan Prosedur Sumber : (SANS, 2013)

Pada PT. Aplikanusa Lintasarta saat tulisan ini dibuat telah memiliki kebijakan keamanan informasi secara korporasi dan prosedur untuk pengembangan aplikasi. Namun yang belum ada adalah standar kriteria keamanan aplikasi dan pedoman Universitas Indonesia


10

keamanan pengembangan aplikasinya. Prosedur pengembangan aplikasi yang ada saat ini kurang efektif mengatasi risiko keamanan aplikasi karena dibuat dan dilaksanakan tanpa adanya pedoman keamanan pengembangan aplikasi. 2.1.3

Proses Pembuatan Kebijakan Keamanan Informasi

2.1.3.1 Kerangka Kerja ISO 27001 Berdasarkan hirarki pada Gambar 1, pedoman walau lebih spesifik akan tetapi tetap harus selaras dengan kebijakan keamanan informasi. Agar dapat selaras, pembuatan pedoman dapat mengadopsi langkah-langkah pembuatan kebijakan keamanan informasi organisasi tersebut. PT. Aplikanusa Lintasarta mengadopsi ISO 27001 dalam proses pembuatan kebijakan keamanan informasi. Langkahlangkah dalam melakukan penilaian risiko sudah dibakukan melalui prosedur pedoman manajemen risiko keamanan informasi perusahaan (PT. Aplikanusa Lintasarta, Pedoman Manajemen Risiko Keamanan Informasi, 2012).Proses pembuatan pedoman keamanan pengembangan aplikasi bila dipetakan ke dalam proses pembuatan kebijakan keamanan informasi termasuk dalam tahapan perencanaan (Plan). Lintasarta telah memiliki pedoman untuk kegiatan ini. Pembuatan dokumen pedoman keamanan aplikasi dalam karya akhir ini akan mengikuti pedoman manajemen risiko dari Lintasarta untuk memastikan bahwa dokumen yang dibuat selaras dengan kebijakan keamanan informasi dari PT. Aplikanusa Lintasarta. 2.1.3.2 Kerangka Kerja NIST National Institute of Standards and Technology (NIST) merupakan salah satu lembaga yang menerbitkan standar pedoman manajemen risiko untuk sistem TI (Stoneburnner, 2002)

dengan kode dokumen SP 800-30. Pada prinsipnya

dokumen SP 800-30 membagi proses manajemen risiko ke dalam 3 proses yang saling berkesinambungan yaitu proses penilaian risiko, proses pengurangan risiko dan proses evaluasi dan penilaian. Fokus pada penulisan ini adalah pada proses penilaian risiko dimana dalam proses ini terdapat sembilan langkah seperti pada tabel berikut ini.



11

Tabel 2. 2 Langkah-Langkah Penilaian Risiko NIST

No

1

2

3

Input

Proses

Output

Mengetahui

Informasi

Ruang lingkup

karakteristik sistem TI

hardware,

sistem, fungsi

software, antar

sistem, tingkat

muka sistem, data

kritikalitas sistem

dan informasi,

dan data, tingkat

manusia, dan misi

sensitivitas sistem

sistem

dan data.

Mengidentifikasikan

Data mengenai

Pernyataan ancaman

ancaman yang dapat

serangan terhadap

menyerang sistem TI

sistem

Mengidentifikasikan

Laporan dari

Daftar dari potensi

kerawanan pada

penilaian risiko

kerawanan

sistem TI.

sebelumnya, laporan audit, kebutuhan keamanan, hasil dari uji keamanan

4

5

Menganalisa Kontrol

Kontrol yang ada

Daftar kontrol yang

saat ini

ada saat ini dan

Kontrol yang

kontrol yang

direncanakan

direncanakan

Penentuan tingkat

Motivasi dari

Tingkat

kecenderungan

sumber ancaman,

kecenderungan

kapasitas ancaman,

ancaman

kerawanan alami, kontrol yang ada saat ini



12

Tabel 2.2 (sambungan) 6

Melakukan analisa

Analisa dampak

dampak

terhadap misi,

Tingkat Dampak

penilaian tingkat kritikalitas aset, tingkat kritikalitas data, tingkat sensivitas data

7

Penentuan level

Kecenderungan dari

Risiko dan tingkat

risiko

eksploitasi ancaman,

risiko yang terkait

besaran dari dampak, kesesuaian dari kontrol yang direncanakan atau yang ada saat ini

8

Rekomendasi kontrol

-

Kontrol yang direkomendasikan

untuk mengurangi risiko

9

Dokumentasi hasil

-

Laporan Penilaian

dalam bentuk laporan

2.1.4

Risiko

Best-Practise Pedoman Keamanan Pengembangan Aplikasi

2.1.4.1 OWASP “Open Web Application Security Project (OWASP) adalah sebuah komunitas terbuka yang bertujuan untuk memberdayakan organisasi dalam mengembangkan, membeli, dan memelihara aplikasi yang dapat dipercaya keamanannya” (OWASP, 2009). OWASP Application Security Verification Standard (ASVS) merupakan pedoman

best-practise

yang

mendefinisikan

persyaratan

verifikasi

dan

dokumentasi yang dikelompokan berdasarkan ruang lingkup dan tingkat keketatannya. Standar ini dapat digunakan untuk membangun tingkat kepercayaan terhadap keamanan aplikasi Web. Dalam kaitannya dengan ancaman keamanan



13

aplikasi web (OWASP, 2010), OWASP memiliki metodologi penilaian risiko yang sudah terstandarisasi dan menjadi best practise yaitu Pemeringkat Risiko OWASP (OWASP, 2013) yang dapat digunakan untuk menentukan tingkat risiko dari ancaman keamanan aplikasi berbasis web tersebut sesuai dengan karakteristik lingkungan suatu organisasi. 2.1.4.2 NIST NIST memilik standar dokumen kontrol untuk mengendalikan ancaman dan kerawanan dari suatu sistem TI yaitu dokumen NIST Special Publication 800-53 (NIST, 2012). Kontrol-kontrol yang ada di dalamnya dapat digunakan sesuai kebutuhan situasi dan kondisi dari sistem TI suatu organisasi. Dalam penelitian ini penulis akan menggunakan kontrol-kontrol yang berkaitan dengan proses pengembangan aplikasi sesuai dengan lingkup dari penelitian ini. 2.2 Penelitian Sebelumnya 2.2.1

Pengembangan Kebijakan dan Pedoman Keamanan Informasi

Pengembangan kebijakan keamanan informasi dengan kerangka kerja ISO 27001 (Fajar, 2007) dimulai dengan melihat perbedaan antara harapan dengan kondisi yang saat itu ada. Harapan dapat digali dari keinginan pemangku kepentingan di organisasi seperti pemenuhan persyaratan regulasi ataupun kebutuhan yang sifatnya komersial. Selanjutnya dapat ditentukan ruang lingkup, dan tujuan dari kebijakan yang akan dibangun. Kemudian dilakukan kajian risiko dengan mengidentifikasikan aset, ancaman, kerawanan, tingkat risiko. Sehingga diperoleh suatu hasil kajian analisa risiko disertai dengan kontrol-kontrol yang diperlukan untuk mengendalikan risiko tersebut. Kerangka kerja ISO 27001 yang berbasis aset akan menyulitkan perancangan pedoman keamanan yang penulis akan bangun karena penulis akan melakukan analisa atas suatu proses pengembangan aplikasi bukan aset. Sementara itu, Silitonga (2012) melakukan perancangan manajemen risiko dengan mengidentifikasikan ancaman dan kerawanan dengan memanfaatkan self-assessment checklist dari dokumen NIST 800-26 (NIST, 2001) kemudian menyusun matriks penilaian risiko untuk menilai tingkat risiko atas masing-masing ancaman dan kerawanan yang telah diidentifikasikan. Selanjutnya kerawanan tersebut dipetakan terhadap kontrol-kontrol yang ada pada dokumen Universitas Indonesia


14

kontrol standar keamanan informasi NIST 800-53 (NIST, 2012) dan menjadikannya sebagai suatu rekomendasi kontrol. Dalam hal ini penulis dapat mengkombinasikan metode identifikasi ancaman dan kerawanan serta pemetaan kontrol menggunakan kerangka NIST namun matriks penilaian risikonya dapat menggunakan yang sudah ada dari pedoman manajemen risiko Lintasarta yang berbasis ISO 27001. Berikut ini rangkuman dari penelitian sebelumnya mengenai pembuatan kebijakan dan pedoman keamanan informasi :

Tabel 2. 3 Rangkuman Penelitian Sebelumnya Penelitian Kerangka

Masukan

Proses

Keluaran

Kajian Risiko :

1. Kajian

1. Identifikasi

analisa

Kerja

Fajar

ISO 27001

2007

1. Harapan pemangku kepentingan 2. Ruang Lingkup dan Tujuan

risiko

aset 2. Identifikasi

2. Kontrol

ancaman

yang diperlukan

3. Identifikasi

(ISO 27000

Kerawanan

Annex A)

4. Penentuan

3. Kebijakan

tingkat risiko

Silitonga

NIST 800-

2012

30

1. Harapan Pemangku kepentingan

Kajian Risiko :

1. Kajian

1. Penentuan

Analisa

tingkat

Risiko

risiko atas

2. Kontrol

Ancaman

ancaman

yang

dan

dan

diperlukan

kerawanan

kerawanan

2. Identifikasi

dengan self

3. Kebijakan

2. Pemetaan



15

Tabel 2.3 (Sambungan)

assessment

kerawanan

checklist NIST SP dengan kontrol 800-26

yang diperlukan dari standar dokumen kontrol NIST SP 800-53

2.3 Kerangka Berpikir Penelitian Dari landasan teori dan penelitian sebelumnya, penulis mengambil kerangka berpikir penelitian seperti ditunjukan oleh Gambar 2.2. Kontrol Standar : • OWASP Top 10 dan ASVS • NIST SP 80053

Identifikasi ancaman : • OWASP Top 10 Threat Web Application Security • Self Assessment Guide NIST 800-26

Gap Analysis Kebutuhan dan Harapan Pemangku Kepentingan

Kontrol yang telah ada : • Kebijakan Keamanan TI Perusahaan • Pedoman Manajemen Risiko Perusahaan • Prosedur Pengembangan Aplikasi • Standar Dokumen SDLC

Rekomendasi Kontrol Baru

Risk Assessment Pedoman

Gambar 2.2 Kerangka Berpikir Penelitian



BAB 3 METODOLOGI PENELITIAN

Berikut ini adalah langkah-langkah penelitian yang akan penulis lakukan :

1. Melakukan Perumusan Permasalahan

2. Melakukan Studi Literatur dan Penyusunan Kerangka Teoritis Penelitian

3. Melakukan Pengumpulan data Data Sekunder : dokumen bisnis proses pengembangan aplikasi, dokumen IT Strategic Plan, Kebijakan Keamanan Informasi Data Primer : Wawancara Pejabat berwenang dan diskusi fokus grup.

5. Menyusun draft Pedoman Kemanan Pengembangan Aplikasi TI

4. Melakukan Penilaian Risiko Pengembangan Aplikasi Perusahaan

6. Melakukan Validasi draft

7. Memperoleh Hasil Final, kesimpulan dan rekomendasi

Gambar 3.1 Langkah-Langkah Penelitian

16



17

Penulis

melakukan

perumusan

masalah

dengan

melakukan

identifikasi

permasalahan guna mencari akar masalah dengan memanfaatkan diagram tulang ikan hingga mendapatkan pertanyaan penelitian. Dari pertanyaan penelitian ini penulis akan melakukan studi literatur dari referensi serta penelitian sebelumnya untuk dapat membuat kerangka teoritis penelitian yang sesuai dengan studi kasus penelitian yang dibuat. 3.1 Pengumpulan Data Setelah kerangka teoritis penelitian berhasil disusun, penulis akan melakukan proses pengumpulan data dari nara sumber dan juga dokumen-dokumen perusahaan tempat penulis melakukan studi kasus. Nara sumber yang akan diwawancarai adalah General Manager TI, Manager TI dan Assisstant Manager TI. Data yang diharapkan dari wawancara adalah mengetahui kondisi TI terkini yang berkaitan dengan keamanan aplikasi, mengetahui harapan dan keinginan dari pemangku kepentingan. Selanjutnya

Penulis

akan

melakukan

pengumpulan

data

untuk

mengidentifikasikan ancaman-ancaman dan kerawanan yang dianggap paling mempengaruhi aplikasi yang ada saat ini, serta mengidentifikasikan risiko-risiko yang ada serta kontrol-kontrol apa yang saat ini sudah ada. Identifikasi ancaman dan kerawanan dilakukan melalui 2 pendekatan : a. Identifikasi ancaman dari sudut pandang teknis menggunakan masukan dari OWASP Top 10 Risk, yang berisi sepuluh ancaman untuk aplikasi berbasis web. Kemudian tingkat risiko dari ancaman tersebut dinilai menggunakan metode Pemeringkat Risiko OWASP yang diperoleh datanya melalui diskusi fokus grup bersama tim TI Lintasarta sehingga diperoleh tingkat risiko dari masing-masing ancaman tersebut untuk kondisi di Lintasarta. b. Identifikasi ancaman dari sudut pandang proses menggunakan dokumen Self Assessment Guide NIST SP 800-26 dengan memilih domain pertanyaan yang berhubungan dengan pengembangan aplikasi. Domain pertanyaan yang dipilih adalah : Daur Hidup Perangkat Lunak



18

(A-9), Dokumentasi (A-36), Sosialisasi, Pelatihan dan Pendidikan (A38), kemudian yang berkaitan dengan hal teknis namun tetap dilingkup pengembangan : Identifikasi dan Otentikasi (A-43), Kontrol Akses Logikal (A-46) dan Jejak Audit (A-50). Kusioner diisi oleh pihak yang bertanggung jawab dalam pengembangan aplikasi di Lintasarta. Kemudian ancaman dan kerawanan yang tersaring dinilai tingkat risikonya menggunakan pedoman manajemen risiko Lintasarta. 3.2 Penilaian Risiko Selanjutnya Penulis akan menyusun dokumen penilaian risiko berdasarkan Pedoman Manajemen Risiko Lintasarta serta melakukan gap analysis apakah kontrol yang ada telah mampu menurunkan tingkat risiko yang telah diidentifikasikan dari langkah sebelumnya. Jika tingkat risiko masih belum memenuhi syarat untuk dapat diterima maka akan direkomendasikan kontrol-kontrol baru. Untuk ancaman dan kerawanan teknis yang diturunkan dari OWASP Top 10 Risk, kontrol baru akan mengacu pada kontrol-kontrol yang ada pada dokumen OWASP Top 10 Risk dan OWASP ASVS. Sedangkan kontrol baru untuk ancaman dan kerawanan proses pengembangan yang diturunkan dari NIST self assessment guide akan mengacu pada dokumen Security and Privacy Control NIST SP 800-53 (NIST, 2012). Kontrol baru tersebut selanjutnya akan menjadi bagian dalam kebijakan yang ada dalam draft pedoman keamanan pengembangan aplikasi untuk TI Lintasarta. Berikut ini adalah rangkuman langkah-langkah yang dilakukan Penulis untuk kegiatan penilaian risiko sampai dengan pembuatan pedoman : Tabel 3. 1 Langkah-Langkah Pembuatan Pedoman

Output

No

Langkah

Input

1

Identifikasi ancaman dan kerawanan keamanan pengembangan aplikasi Penentuan tingkat Risiko

• OWASP Top 10 • Studi Risk Literatur • Self Assessment Guide NIST SP • Diskusi 800-26 grup • Daftar Ancaman • Diskusi dan Kerawanan grup • OWASP Risk

2

Metode

Daftar ancaman dan kerawanan

Ancaman dan tingkat risikonya



19

No

Langkah

Tabel 3.1 (Sambungan) Metode Input

Output

Rating Methodology • Pedoman Manajemen Risiko Lintasarta

3

Analisa Gap

4

Rekomendasi kontrol baru untuk mengendalikan risiko residual berprofil tidak rendah

5

Penyusunan Draft Pedoman Keamanan Pengembangan Aplikasi

• Ancaman dan Tingkat Risikonya • Prosedur pengembangan Aplikasi yang ada • Dokumen standar SDLC yang ada • Kebijakan keamanan TI yang ada • Risiko Residual yang berprofil tidak rendah • OWASP Top 10 Risk dan OWASP ASVS • NIST SP 800-53 • Kontrol baru yang direkomendasikan

Diskusi grup

Risiko Residual yang berprofil tidak rendah

• Studi literatur • Diskusi grup

Kontrol baru dan program kerja

• Studi literatur • Validasi melalui presentasi pada pejabat TI Lintasarta

Draft Pedoman Keamanan Pengembangan Aplikasi yang telah divalidasi

3.3 Pemilihan Kontrol Guna mendapatkan rekomendasi kontrol yang diperlukan penulis melakukan studi literatur pada dokumen dari OWASP dan NIST yang berhubungan dengan ancaman tersebut. Untuk kontrol yang berkaitan dengan ancaman teknis penulis mencari kontrol yang sesuai dengan ancaman dari OWASP Top 10 Risk dan OWASP ASVS. Sedangkan untuk kontrol yang berkaitan dengan proses pengembangan aplikasi penulis mencari rekomendasi kontrol dari dokumen NIST SP 800 – 53. Kontrol yang dipilih adalah kontrol yang berkaitan dengan proses pengembangan aplikasi sesuai dengan lingkup dari karya akhir ini.



20

Pada dokumen NIST SP 800-53 bagian 3 dijelaskan cara memilih kontrol, pertama dengan menentukan karakteristik dari sistem apakah dampak rendah, dampak moderat atau dampak tinggi. Rendah, moderat dan tinggi ditentukan dari dampak sistem tersebut terhadap tujuan keamanan informasi yaitu Kerahasiaan, Integritas dan Ketersediaan informasi. Dampak rendah berarti sistem tersebut hanya berdampak rendah atas ketiga tujuan di atas. Moderat artinya jika salah satu dari tujuan diatas berdampak moderate, selain itu tidak ada yang lebih dari moderat. Dampak Tinggi jika sistem bisa memberikan dampak yang tinggi atas salah satu tujuan keamanan informasi tersebut (NIST, 2012, hal:23). Kemudian temukan baseline control untuk karakteristik sistem tersebut. Selanjutnya kustomisasi kontrol sesuai dengan situasi dan kondisi organisasi dengan memperhatikan ruang lingkup kebijakan yang akan dibuat, identifikasi initial security control baselines atau kontrol prioritas. Sesuai dengan lingkup kebijakan yang dibuat yaitu proses pengembangan aplikasi maka kontrol yang dipilih adalah kontrol dalam lingkup pengembangan aplikasi. Kontrol-kontrol ini juga sudah terpetakan ke dalam kontrol ISO 27001 Annex A untuk memastikan bahwa kontrol yang dipilih sudah sesuai dengan sertifikasi ISO 27001 milik perusahaan (NIST, 2013, tabel H-1).



BAB 4 PROFIL PERUSAHAAN

PT. Aplikanusa Lintasarta adalah perusahaan yang bergerak sebagai penyedia layanan telekomunikasi dengan wilayah layanan meliputi seluruh Indonesia. Pelanggan korporasi berjumlah lebih dari 1.700 perusahaan dan memiliki lebih dari 19.000 jaringan yang dilayani oleh kantor pelayanan yang berada di 44 kota. 4.1 Struktur Organisasi PT. Aplikanusa Lintasarta memiliki 5 Direktorat, yaitu : a. Office Of President Directorate yang dipimpin oleh President Director yang sekaligus sebagai pemimpin perusahaan. Membawahi Divisi Corporate Secretary, bagian Internal Audit yang memiliki tanggung jawab pengawasan internal, bagian Enterprise Risiliance sebagai fungsi manajemen risiko perusahaan. b. Datacom Directorate, dipimpin oleh Data Com Director

yang

membawahi 2 Divisi Sales, 1 Divisi Marketing untuk layanan komunikasi Data dan Customer Care. c. VAS & IT Directorate, dipimpin oleh VAS & IT Director membawahi divisi pengembangan produk, pengembangan bisnis, dan divisi operasi jasa VAS dan IT. d. Network & Operation Directorate, dipimpin oleh Network & Operation Director yang membawahi 3 Divisi Regional (Barat, Tengah dan Timur), divisi Service & Delivery dan Network & Operation. e. Corporate Service Directorate, dipimpin oleh Corporate Service Director yang membawahi divisi Finance, Human Capital Management dan Procurement. 4.2 Struktur Organisasi Teknologi Informasi Fungsi TI perusahaan berada pada Divisi Vas Operation & IT yang dipimpin oleh seorang General Manager. Divisi ini berada di bawah direktorat VAS & IT yang dipimpin oleh seorang direktur bidang. Tanggung jawab TI di divisi ini terbagi

21



22

menjadi dua besar yaitu pekerjaan pengembangan dan pekerjaan operasional. Fungsi pengembangan TI berada pada bagian IT Development & Business Process sedangkan pekerjaan operasional di bagian IT Operations. Pekerjaan pengembangan meliputi pengembangan aplikasi untuk melayani proses bisnis internal perusahaan. Sedangkan pekerjaan operasional meliputi pemeliharaan infrastruktur TI, helpdesk TI dan pemeliharaan aplikasi. Fungsi operasi juga terlibat dalam kegiatan pengembangan aplikasi dalam hal melakukan peninjauan disain, development test, dan quality control test. Dalam hal keamanan informasi bagian IT Operations yang bertanggung jawab terhadap keamanan infrastruktur jaringan, server dan aplikasi yang operasional. Struktur organisasi yang menjalankan fungsi TI perusahaan digambarkan melalui bagan berikut ini.

VAS & IT DIRECTORATE

VAS Operation & IT Division

IT Development & Business Process Department

IT Operations Department

IT Development Sub Department

IT Infrastructure Sub Department

Business Process Sub Department

Application Operation & Maintenance Sub Department

Gambar 4.1 Struktur Organisasi TI PT. Aplikanusa Lintasarta



23

4.3 Proses Bisnis Pengembangan Aplikasi Proses bisnis pengembangan aplikasi di Lintasarta telah memiliki prosedur yang baku (PT. Aplikanusa Lintasarta, Prosedur Permintaan dan Pengadaan Software, 2012) seperti yang dapat dilihat pada bagan Lampiran 5. Selain prosedur, Lintasarta juga sudah memiliki standar dokumen pengembangan aplikasi yang formal (PT. Aplikanusa Lintasarta, Software Development Life Cycle, 2012). Terkait dengan prosedur pengembangan aplikasi tersebut, dokumen Kerangka Acuan Kerja (KAK) sebagai dokumen Request For Proposal (RFP) tidak termasuk dalam dokumen SDLC. Yang termasuk dalam dokumen SDLC adalah : dokumen Business Requirement Spesification (BRS), Project Plan (PP), Functional Requirement Spesification (FRS), Design Detil Spesification (DDS). Prosedur pengembangan aplikasi, dokumen KAK dan dokumen SDLC saat ini menjadi kontrol baku proses pengembangan aplikasi di Lintasarta dan akan dijadikan masukan dalam proses analisa di karya akhir ini.



BAB 5 DATA DAN ANALISA

5.1 Karakteristik Sistem Aplikasi di Divisi TI Lintasarta Berdasarkan hasil wawancara dengan VAS Operation & IT Division General Manager dapat diketahui bahwa karakteristik sistem TI adalah sistem yang memberikan dukungan penting bagi bisnis perusahaan. Dan harapan dari GM IT adalah aplikasi dapat menjaga kerahasiaan, integritas dan ketersediaan informasi perusahaan karena semua data bisnis perusahaan tersimpan melalui aplikasi. Selain itu Lintasarta juga telah memiliki kebijakan keamanan informasi korporasi, kebijakan keamanan TI dan prosedur pengembangan aplikasi serta standar dokumen formal SDLC. Namun pedoman keamanan pengembangan aplikasi masih belum ada, dan dinyatakan dibutuhkan. Dari sini dapat disimpulkan bahwa karateristik sistem aplikasi web TI adalah sistem berdampak tinggi seperti yang disebutkan pada bagian 3.3. dan kontrol pedoman keamanan pengembangan aplikasi

yang dipilih dan direkomendasikan nantinya adalah kontrol yang

digunakan untuk sistem berdampak tinggi. 5.2 Profil Risiko Ancaman dan Kerawanan Setelah melalui studi literatur dan diskusi melalui fokus grup untuk mengidentifikasikan ancaman dan kerawanan serta penentuan tingkat risikonya sebagai mana disebutkan dalam langkah 1 dan 2 pada Tabel 3.1. Penulis memperoleh data profil risiko dari ancaman yang diidentifikasikan sebagai berikut. Tabel 5.1 menunjukan hasil penilaian tingkat risiko inheren, yaitu risiko sebelum dianalisa terhadap kontrol yang ada saat ini, untuk 10 ancaman keamanan aplikasi web OWASP berdasarkan metodologi pemeringkat risiko OWASP untuk kondisi di Lintasarta. Matriks ancaman, kerawanan dan tingkat risiko, serta data hasil pembahasan pemeringkat risiko OWASP dengan tim TI Lintasarta dapat dilihat pada Lampiran 1.

24



25

Tabel 5. 1 Hasil Penilaian Tingkat Risiko Inheren OWASP 10 Ancaman Keamanan Aplikasi Web Faktor

Dampak

Kemungkinan

Bisnis

Kesalahan Konfigurasi Keamanan Penyimpanan Kriptografi yang 7 tidak aman Kegagalan membatasi akses 8 url

Tinggi (7) Tinggi (6,375) Tinggi (7) Tinggi (6,375) Sedang (5,25) Tinggi (6,75) Sedang (3,375) Sedang (5,375)

Tinggi (7) Sedang (5,25) Sedang (5,25) Sedang (5,25) Sedang (3) Sedang (4,75) Sedang (4) Sedang (5,25)

9

Perlindungan yang tidak cukup pada layer transport

Sedang (3,5)

Tinggi (6)

Tinggi

10

Redirect dan Forward yang tidak divalidasi

Tinggi (6)

Sedang (3)

Tinggi

No

Ancaman

1 Injeksi SQL

2 Cross-Site Scripting

Otentikasi dan Pengelolaan Sesi yang buruk Referensi Obyek Langsung 4 yang tidak aman

3

5 Cross-Site Request Forgery

6

Tingkat Risiko

Kritis

Tinggi

Tinggi

Tinggi

Sedang

Tinggi

Sedang

Sedang

Sedangkan Tabel 5.2 menunjukkan hasil penilaian risiko inheren untuk ancaman kerawanan yang teridentifikasi melalui self- assessment NIST 800-26 dengan metodologi pemeringkat risiko berdasarkan pedoman manajemen risiko PT. Aplikanusa Lintasarta. Matriks ancaman kerawanan, kemungkinan dan tingkat risiko berdasarkan pedoman manajemen risiko Lintasarta dapat dilihat pada Lampiran 1. Data kuisioner hasil Self-Assessment dapat dilihat pada Lampiran 2. Tabel 5. 2 Hasil Penilaian Risiko Inheren Kerawanan Proses Pengembangan Aplikasi Berdasarkan Self-Assessment Guide NIST 800-26

No

Ancaman dan Kerawanan (NIST SP 800-26)

Tingkat Kemungkinan

Nilai

Tingkat dampak

Tingkat Risiko

Nilai



26

1

2

3

4

5

Kebutuhan keamanan belum diidentifikasikan saat disain sistem Kontrol keamanan dengan evaluasi dan prosedur uji yang terkait dengannya belum dibuat Kebutuhan keamanan dan prosedur evaluasi / uji keamanan belum ada dalam dokumen RFP Ujicoba khusus terhadap standar kontrol keamanan belum dilakukan dan didokumentasikan pada fase implementasi Kewajiban akan penyelenggaraan pelatihan atau sosialisasi untuk penyegaran akan kebijakan standar keamanan pengembangan aplikasi belum dibakukan

Kritis

5

Tinggi

4

Kritis

Kritis

5

Tinggi

4

Kritis

Kritis

5

Tinggi

4

Kritis

Kritis

5

Tinggi

4

Kritis

Kritis

5

Sedang

3

Tinggi

5.3 Hasil Analisa Gap dengan Kontrol Saat Ini Selanjutnya setelah dilakukan pemetaan dengan kontrol yang ada saat ini risiko inherent ancaman teknis yang terdapat pada Tabel 5.1 berubah menjadi risko residual seperti terlihat pada Table 5.4. Pada tabel tersebut dapat dilihat bahwa masih ada ancaman kerawanan yang memiliki profil kritis, tinggi dan sedang, selain yang berubah menjadi rendah. Demikian juga untuk risiko inheren dari ancaman yang bersifat proses pada Tabel 5.2 setelah dipetakan dengan kontrol yang ada saat ini menjadi risiko residual pada Tabel 5.5 ternyata hasilnya masih ada ancaman kerawanan yang memiliki profil kritis, tinggi dan tidak ada yang berubah menjadi rendah.



27

Tabel 5. 3 Jumlah Ancaman Kerawanan Berdasarkan Tingkat Risiko Residual

1

Tingkat Risiko Residual Kritis

2

Tinggi

2

3

Sedang

4

4

Rendah

5

No

Jumlah Ancaman Kerawanan 4

Secara total dapat dilihat bahwa dari 15

ancaman

kerawanan

yang

teridentifikasikan, dengan kontrol yang ada hanya 5 yang dapat diturunkan risikonya menjadi rendah. ini menunjukan kontrol yang ada masih belum cukup tepat dan tidak efektif untuk menjaga keamanan pengembangan aplikasi. Sesuai dengan prosedur pedoman manajemen risiko keamanan informasi Lintasarta ambang batas risiko yang diterima untuk keamanan informasi adalah risiko rendah (PT. Aplikanusa Lintasarta, Prosedur Permintaan dan Pengadaan Software, 2012, hal.10). Dari Tabel 5.3 dapat dilihat jumlah kerawanan dikelompokan berdasarkan tingkat risiko residual, yang tingkat risiko residualnya rendah atau bisa diterima hanya 5 sisanya masih tidak bisa diterima. Maka diperlukan rekomendasi kontrol baru yang dapat menurunkan tingkat risiko sampai kepada level rendah atau kepada tingkat yang dapat diterima. Hasil analisa gap menunjukan kontrol-kontrol yang ada saat ini tidak bisa menurunkan tingkat risiko karena tidak sesuai dengan ancamannya ataupun jika sudah sesuai ternyata tidak konsisten untuk dilaksanakan. Untuk kontrol yang tidak konsisten dilaksanakan lebih lanjut diketahui karena memang tidak ada aturan yang memaksanya menjadi suatu yang wajib untuk dilaksanakan. Seperti penggunaan tool pemrograman yang sudah memiliki built in validasi data input yang dapat melakukan sanitasi injeksi SQL ternyata tidak konsisten digunakan untuk setiap pengembang aplikasi karena tidak ada aturan yang mewajibkan persyaratan tersebut. Sedangkan kontrol yang tidak sesuai terjadi karena memang pembuatan kontrol tersebut belum memperhatikan faktor ancaman keamanan aplikasi web. Prosedur pengembangan aplikasi dan dokumen SDLC perusahaan Universitas Indonesia


28

sebagai kontrol yang ada saat ini dibuat tanpa ada pedoman keamanan pengembangan aplikasi yang dibangun berdasarkan analisa risiko ancaman keamanan aplikasi. Artinya sangat mungkin prosedur dan dokumen formal SDLC dibuat tanpa memperhatikan faktor ancaman dan kerawanan keamanan aplikasi.



29

Tabel 5. 4 Risk Register Kerawanan Teknis Pengembangan Aplikasi Lintasarta

Deskripsi Risiko RISIKO INHEREN

ANCAMAN

DAMPAK RISIKO

No Ancaman Kelemahan

Keterangan

Dampak

KemungProfil kinan

1 Injeksi SQL

Injeksi SQL dapat Tinggi Tinggi Input aplikasi masih rentan (7) merusak data pada (7) terhadap database serangan injeksi SQL


Belum ada proses verifikasi khusus terhadap bahaya CSS

Serangan CSS dapat membuat orang tak berhak mengambil sesi pengguna lain, mengakses data dan melakukan perubahan data

TINDAKAN SAAT INI ATAU KONTROL SAAT INI UNTUK MENGELOLA RISIKO

Pengendalian yang ada

Kelayakan Penerapan

RISIKO RESIDUAL

Efektifitas Dampak

KemungProfil kinan

Tidak Kurang Tinggi Sedang Tinggi Tepat Kritis Pengembangan aplikasi menggunakan perangkat Sasaran Konsisten Efektif (7) (5,5) lunak yang sudah memiliki validasi otomatis atas injeksi sql untuk setiap obyek input Tepat Konsisten Efektif Sedang Tinggi Tinggi Kebijakan keamanan Rendah Rendah Rendah Sasaran informasi mengatur (5,25) (6,375) (1,75) (1,75) akses ke komputer pengguna dan aplikasi yang dapat diinstal di komputer pengguna, medeteksi jika ada yang membuat server web ilegal



30

Tabel 5.4 (Sambungan) Deskripsi Risiko RISIKO INHEREN

ANCAMAN

DAMPAK RISIKO

No Ancaman

KemungProfil kinan

Kelemahan

Keterangan

Dampak

3 Otentikasi dan Pengelolaan Sesi yang buruk

Aplikasi yang tidak otomatis Logout ketika tidak digunakan

Aplikasi dapat digunakan oleh Orang yang tidak berhak

Sedang Tinggi (5,25) (7)

4 Referensi Obyek Langsung yang tidak aman

Akses link halaman web terhadap file yang diupload melalui aplikasi tidak melakukan pengecekan sesi user dan hak aksesnya

History URL dapat digunakan user yang tak berhak untuk mengakses file dan menggantiganti parameternya untuk mengakses lebih banyak file



Tinggi Login aplikasi memanfaatkan login domain dengan aturan password kuat. Kebijakan keamanan informasi mewajibkan aplikasi untuk Logout dan menghapus sesi user jika 10 menit tidak digunakan dan diverifikasi dalam standar QC Aplikasi. Akses ke ruangan kerja dibatasi dengan penggunaan Kartu Identitas Karyawan terbatas. Sedang Tinggi Tinggi Menu akses aplikasi dibatasi hanya untuk (5,25) (6,375) user yang berhak. Permintaan akses menu suatu aplikasi melalui persetujuan pimpinan telah diatur dalam prosedur IT Change Management

Kelayakan Penerapan

RISIKO RESIDUAL

Efektifitas Dampak

KemungProfil kinan

Tepat Sasaran

Konsisten Efektif

Rendah Rendah Rendah (1,75) (2,375)

Kurang Tepat

Konsisten Kurang Efektif

Sedang Sedang Sedang (3,75) (5,375)



31


ANCAMAN

DAMPAK RISIKO

No Ancaman

5 Cross-Site Request Forgery

6 Kesalahan Konfigurasi Keamanan

7 Penyimpanan Kriptografi yang tidak aman

Dampak

KemungProfil kinan


Kelemahan

Keterangan

Persetujuan atas suatu permintaan di aplikasi diinformasikan oleh sistem melalui email kepada pejabat yang berwenang dengan suatu link yang dapat diklik untuk disetujui atau tidak disetujui Belum ada standar keamanan konfigurasi server web aplikasi yang baku

Sedang Sedang Sedang Setiap permintaan Perubahan Kurang parameter pada Tepat persetujuan yang (3) (5,25) email permintaan diarahkan dari link persetujuan dapat eksternal, aplikasi wajib membuat pejabat melakukan otentikasi yang berwenang keabsahan login dan tidak menyadari memeriksa otorisasi hak telah membuat penggunanya keputusan yang tidak sesuai dengan yang dinginkannya

nama file source code atau file yang diunggah pengguna termasuk file rahasia bisa terlihat

Sedang Tinggi (4,75) (6,75)

Penggunaan single sign on. Satu user name dan password untuk mengakses

Jika user name dan password dapat diketahui oleh orang lain, seluruh akses aplikasi yang

Sedang Sedang Sedang User name dan Password terintegrasi (4) (3,75) dengan user domain berbasis Microsoft Windows. Kebijakan keamanan informasi


Kelayakan Penerapan

Kurang Tinggi Prosedur baku Tepat pemeliharaan server aplikasi seperti penggunaan anti virus, backup dan vulnerability test level OS sudah ada dan rutin dijalankan.

Tepat Sasaran

RISIKO RESIDUAL

Efektifitas Dampak

KemungProfil kinan


Sedang Sedang Sedang (3) (4,5)


Sedang Sedang Sedang (4,75) (5)

Konsisten Efektif

Rendah Rendah Rendah (2,25) (2,5)



32


ANCAMAN

DAMPAK RISIKO


Keterangan

Dampak

KemungProfil kinan



termasuk di dalamnya seluruh aplikasi dimiliki pengguna pengelolaan password tersebut dapat sudah ada. diretas oleh pihak yang tak bertanggung jawab 8 Kegagalan Sedang Sedang Sedang Aplikasi melakukan URL yang tidak akses admin dimiliki pengguna (5,25) (5,375) membatasi otentikasi dan terkendali yang tidak berhak akses url memeriksa otorisasi dari memudahkan pengguna pada halaman pengguna login yang terintegrasi mengubah dengan domain controler parameter user name dari user biasa menjadi seorang admin, setelah berhasil login dengan user biasa 9 Perlindungan user name dan Jika bisa di tap Tinggi Sedang Tinggi Jaringan LAN server yang tidak password (6) (3,5) dan LAN user terpisah oleh orang yang cukup pada database dikirim tak berhak, akses dan akses fisiknya layer transport dari server web ke database dan dibatasi. Kebijakan ke server keamanan informasi perubahannya mengenai daftar database melalui dapat dilakukan software yang legal orang tersebut jaringan untuk diinstal dikelola dengan aplikasi dekstop

Kelayakan Penerapan

RISIKO RESIDUAL

Efektifitas Dampak

KemungProfil kinan

Kurang Tepat


Sedang Sedang Sedang (4,5) (5,125)

Tepat Sasaran


Sedang Rendah Rendah (4,75) (2,375)



33


ANCAMAN

DAMPAK RISIKO


Keterangan

Dampak

KemungProfil kinan



Kelayakan Penerapan

RISIKO RESIDUAL

Efektifitas Dampak

KemungProfil kinan

management terpusat sehingga instalasi tools untuk sniffing dapat dibatasi

10 Redirect dan Forward yang tidak divalidasi

aplikasi single sign on memanfaatkan redirect dan forward untuk berpindah antar aplikasi, penyerang dapat merubah parameter halaman web menjadi suatu halaman web berbahaya yang menginstalasi mailware atau virus ke para pengguna

Data rahasia atau data pribadi dikomputer pengguna dapat dieksploitasi

Sedang Tinggi (3) (6)

Tepat Tinggi Kebijakan keamanan informasi mewajibkan Sasaran penggunaan anti virus dan dipaksa melalui aplikasi manajemen dekstop. Kebijakan keamanan informasi mengatur akses ke komputer pengguna dan aplikasi yang dapat diinstal di komputer pengguna

Konsisten Efektif

Rendah Sedang Rendah (1) (3,125)



34

Tabel 5. 5 Risk Register Kerawanan Proses Pengembangan Aplikasi Lintasarta

Deskripsi Risiko RISIKO INHEREN

ANCAMAN

DAMPAK RISIKO


1 Kebutuhan Tidak ada keamanan belum panduan dalam diidentifikasikan fase konstruksi saat disain untuk memenuhi sistem aspek keamanan aplikasi yang dibutuhkan

2 Kontrol keamanan dengan evaluasi dan prosedur uji yang terkait dengannya belum dibuat

Tidak ada panduan dalam fase ujicoba untuk memenuhi aspek keamanan aplikasi yang dibutuhkan

Keterangan

Dampak

Tinggi Aplikasi (4) dibangun tanpa memperhatikan kebutuhan aspek keamanannya.

aplikasi tidak diujicoba terhadap suatu kontrol keamanan tertentu

Tinggi (4)

KemungProfil kinan



Kritis Kritis Setiap proses disain diverifikasi dengan (5) pengendalian Berita Acara Disain yang harus ditandatangani oleh Pihak Pengguna, Pihak TI dan Pengembang untuk memastikan disain sistem sudah memenuhi kebutuhan pengguna (Prosedur Pengadaan Software TI) Kritis Kritis Setiap proses ujicoba dilakukan berdasarkan (5) skenario ujicoba yang dibuat berdasarkan dokumen BRS dan FRS (Dokumen SDLC Lintasarta) . Setiap kegiatan ujicoba ditandatangani oleh Pengguna, TI Lintasarta, dan Pengembang untuk

Kelayakan Penerapan

RISIKO RESIDUAL

Efektifitas Dampak

KemungProfil kinan

Lemah

Selalu Diterapkan

Tidak Efektif

Tinggi Tinggi (4) (4)

Kritis

Lemah

Selalu Diterapkan

Tidak Efektif


Kritis



35


ANCAMAN

DAMPAK RISIKO


3 Kebutuhan Tidak ada keamanan dan kebutuhan prosedur keamanan evaluasi / uji aplikasi yang keamanan belum diidentifikasikan ada dalam dalam dokumen dokumen RFP RFP 4 Ujicoba khusus Ujicoba khusus terhadap standar kontrol kontrol keamanan keamanan belum aplikasi tidak dilakukan dan dilakukan dalam didokumentasik fase implementasi an pada fase pengembangan implementasi aplikasi

Keterangan

Dampak

Lalai memperhatikan kebutuhan keamanan aplikasi

Tinggi (4)

permasalahan keamanan aplikasi dapat terjadi saat aplikasi beroperasional di server produksi

Tinggi (4)

KemungProfil kinan



memastikan setiap skenario ujicoba sudah dilaksanakan dengan hasil yang sesuai dengan yang diharapkan. (Prosedur Pengadaan Software TI) Kritis Kritis Sudah ada standar dokumen RFP. Dokumen (5) RFP ditandatangani oleh Pimpinan TI berdasarkan kewenangan anggaran

Kritis Kritis Setiap proses ujicoba dilakukan berdasarkan (5) skenario ujicoba yang dibuat berdasarkan dokumen BRS dan FRS (Dokumen SDLC Lintasarta) . Setiap kegiatan ujicoba ditandatangani oleh Pengguna, TI Lintasarta, dan Pengembang untuk memastikan setiap skenario ujicoba sudah

Kelayakan Penerapan

RISIKO RESIDUAL

Efektifitas Dampak

KemungProfil kinan

Lemah

Selalu Diterapkan

Tidak Efektif

Tinggi (4)

Kritis (5)

Kritis

Lemah

Selalu Diterapkan

Tidak Efektif


Kritis



36


ANCAMAN

DAMPAK RISIKO


Keterangan

Dampak

KemungProfil kinan



Kelayakan Penerapan

RISIKO RESIDUAL

Efektifitas Dampak

KemungProfil kinan

dilaksanakan dengan hasil yang sesuai dengan yang diharapkan. (Prosedur Pengadaan Software TI)

5 Kewajiban akan penyelenggaraan pelatihan atau sosialisasi untuk penyegaran akan kebijakan standar keamanan pengem-bangan aplikasi belum dibakukan

Tidak ada prosedur yang mewajibkan melakukan sosialisasi mengenai standar keamanan pengembangan aplikasi secara berkala

Sedang Kritis Tingg setiap rekanan baru dan Kurangnya Lemah (3) (5) i karyawan baru sosialisasi dapat diwajibkan untuk menyebabkan memperoleh sosialisasi standar pedoman mengenai kebijakan tidak dijalankan, keamanan informasi terutama jika perusahaan dan ada karyawan menandatangani baru ataupun rekanan baru. dokumen NDA mengenai kerahasiaan informasi

Selalu Diterapkan

Tidak Efektif

Sedang Tinggi Tinggi (3) (4)



37

5.4 Pemilihan Rekomendasi Kontrol Baru Dari analisa gap dibagian 5.3 dapat diketahui bahwa Lintasarta membutuhkan adanya rekomendasi kontrol baru untuk menurunkan tingkat risiko dari ancaman dan kerawanan yang berhasil diidentifikasikan. Pada bagian akan dibahas pemilihan rekomendasi kontrol baru tersebut. Melalui langkah-langkah seperti yang disebutkan di bagian 3.3. dapat diperoleh rekomendasi kontrol baru untuk menurunkan tingkat risiko yang dimaksud. Hasil analisa penilaian risiko berdasarkan rekomendasi kontrol yang baru dapat dilihat pada Lampiran 1. Terlihat bahwa dengan kontrol baru risiko residual dapat diturunkan sehingga seluruh ancaman menjadi bernilai risiko harapan rendah. Selanjutnya kontrol baru tersebut digunakan menjadi isi dari dokumen pedoman keamanan pengembangan aplikasi. Pemetaan risiko yang belum bernilai risiko rendah dengan kontrol baru, dan rencana program kerja serta target waktu penyelesaiannya dapat dilihat pada Tabel 5.6. Selanjutnya bila ditelaah lebih jauh kontrol-kontrol baru tersebut ternyata tidak hanya

menjadi

dasar

pembuatan

draft

dokumen

pedoman

keamanan

pengembangan aplikasi tapi juga berdampak pada perubahan isi beberapa dokumen SDLC perusahaan. Dokumen yang berubah adalah dokumen Kerangka Acuan Kerja (KAK), dokumen perencanaan proyek (Project Plan), dokumen Business Requirement Spesification (BRS), dokumen Design Detil Spesification (DDS). Persyaratan keamanan atas dokumen-dokumen SDLC tersebut dijelaskan dalam dokumen draft Pedoman Keamanan Pengembangan Aplikasi Web Lintasarta seperti yang terdapat pada Lampiran 4 , sedangkan template dokumen SDLC yang telah direvisi berada pada bagian lampiran dokumen pedoman tersebut.



38

Tabel 5. 6 Pemetaan Ancaman Kerawanan dengan Rekomendasi Kontrol Baru

DAMPAK RISIKO

Rencana Mitigasi

RISK

MITIGATION

Penanggung Jawab

Batas Waktu

Program Kerja

No

Ancaman

Kelemahan

Keterangan

1

Injeksi SQL

Input aplikasi masih rentan terhadap serangan injeksi SQL

Injeksi SQL dapat merusak data pada database

2

Cross-Site Scripting

Belum ada proses verifikasi khusus terhadap bahaya CSS

Serangan CSS dapat membuat orang tak berhak mengambil sesi pengguna lain, mengakses data dan melakukan perubahan data

Mitigasi / Terima / Transfer Mitigasi

Rekomendasi & Pengendalian Baru

Penanggung Jawab

1. Standarisasi Penggunaan Tools Pemrograman yang dapat mengendalikan ancaman injeksi SQL baik untuk vendor ataupun internal , 2. Memasukan kegiatan verifikasi keamanan aplikasi untuk ancaman injeksi SQL dalam setiap kegiatan ujicoba aplikasi yang sedang dikembangkan dan akan dioperasionalkan

IT Development

M4 Jul 2013

Pembuatan standar pedoman keamanan pengembangan aplikasi

Terima



39

Tabel 5.6 (Sambungan) DAMPAK RISIKO

Rencana Mitigasi

RISK

MITIGATION

Penanggung Jawab

Batas Waktu

Program Kerja

No

Ancaman

Kelemahan

Keterangan

3

Otentikasi dan Pengelolaan Sesi yang buruk

Aplikasi yang tidak otomatis Logout ketika tidak digunakan

Aplikasi dapat digunakan oleh Orang yang tidak berhak

4


Akses link halaman web terhadap file yang diupload melalui aplikasi tidak melakukan pengecekan sesi user dan hak aksesnya

History URL dapat digunakan user yang tak berhak untuk mengakses file dan menggantiganti parameternya untuk mengakses lebih banyak file

Mitigasi / Terima / Transfer Terima

Mitigasi


Penanggung Jawab

1. Aplikasi harus melakukan IT otentikasi hak akses user terhadap Development halaman web yang mengakses referensi obyek (file atau gambar) 2. Penggunaan referensi obyek tidak langsung untuk menghindari perubahan parameter URL secara manual oleh pengguna

M4 Jul 2013




40


Rencana Mitigasi

RISK

MITIGATION

Penanggung Jawab

Batas Waktu

Program Kerja

No

Ancaman

Kelemahan

Keterangan

Perubahan parameter pada email permintaan persetujuan dapat membuat pejabat yang berwenang tidak menyadari telah membuat keputusan yang tidak sesuai dengan yang dinginkannya nama file source code atau file yang diunggah pengguna termasuk file rahasia bisa terlihat

5

Cross-Site Request Forgery

Persetujuan atas suatu permintaan di aplikasi diinformasikan oleh sistem melalui email kepada pejabat yang berwenang dengan suatu link yang dapat diklik untuk disetujui atau tidak disetujui

6

Kesalahan Konfigurasi Keamanan

Belum ada standar keamanan konfigurasi server web aplikasi yang baku

Mitigasi / Terima / Transfer Mitigasi

Mitigasi


Penanggung Jawab

1. Penggunaan token unik untuk setiap URL permintaan persetujuan yang dikirimkan melalui suatu email yang kode parameternya tidak mudah dipahami user. 2. Adanya konfirmasi kembali dari sistem atas data yang berhasil / gagal dicatat oleh sistem atas tindakan yang dilakukan oleh pengguna

IT Development

M4 Jul 2013


Standar konfigurasi server web aplikasi yang telah memperhatikan faktor keamanan dari ancaman serangan

IT Development

M4 Jul 2013




41


Rencana Mitigasi

RISK

MITIGATION

Penanggung Jawab

Batas Waktu

Program Kerja

No

Ancaman

Kelemahan

7


Penggunaan single sign on. Satu user name dan password untuk mengakses seluruh aplikasi

8

Kegagalan membatasi akses url

URL yang tidak terkendali memudahkan pengguna mengubah parameter user name dari user biasa menjadi seorang admin, setelah berhasil login dengan user biasa

Keterangan

Jika user name dan password dapat diketahui oleh orang lain, seluruh akses aplikasi yang dimiliki pengguna tersebut dapat diretas oleh pihak yang tak bertanggung jawab akses admin dimiliki pengguna yang tidak berhak


Mitigasi


Penanggung Jawab

Setiap halaman web harus diotentikasi dan diotorisasi berdasarkan peran (Role) yang diperiksa berdasarkan sesi login, bukan berdasarkan halaman URL

IT Development

M4 Jul 2013




42


Rencana Mitigasi

RISK

MITIGATION

Penanggung Jawab

Batas Waktu

Program Kerja

No

Ancaman

Kelemahan

Keterangan

9


user name dan password database dikirim dari server web ke server database melalui jaringan

Jika bisa di tap oleh orang yang tak berhak, akses ke database dan perubahannya dapat dilakukan orang tersebut

10


aplikasi single sign on memanfaatkan redirect dan forward untuk berpindah antar aplikasi, penyerang dapat merubah parameter halaman web menjadi suatu halaman web berbahaya yang menginstalasi mailware atau virus ke para pengguna

Data rahasia atau data pribadi di komputer pengguna dapat dieksploitasi



Penanggung Jawab

Terima



43


No

ANCAMAN

PENGENDALIA N RISIKO

KONTROL BARU

Penanggung Jawab

Batas Waktu

Program Kerja

Mitigasi / Terima / Transfer


PIC

11

Kebutuhan keamanan belum diidentifikasikan saat disain sistem

Mitigasi

Kebutuhan keamanan aplikasi menjadi satu bagian yang wajib untuk dibuat dan diidentifikasikan dalam dokumen kebutuhan aplikasi, dan dokumen disain aplikasi. (NIST SP 800-53 Control SA-2, SA-3, SA-15)

IT Development

M4 Jul 2013

Perubahan dokumen SDLC Lintasarta : Dokumen Business Requirement Spesification (BRS), Functional Requirement Spesification (FRS), dan Design Detail Spesification (DDS)

12

Kontrol keamanan dengan evaluasi dan prosedur uji yang terkait dengannya belum dibuat

Mitigasi

Pembuatan standar kontrol keamanan aplikasi yang perlu diperhatikan dalam kegiatan ujicoba aplikasi (NIST SP 800-53 Control SA-3, SA-15)

IT Development

M4 Jul 2013

Pembuatan standar pedomanan keamanan pengembangan aplikasi

13

Kebutuhan keamanan dan prosedur evaluasi / uji keamanan belum ada dalam dokumen RFP

Mitigasi

Standar dokumen RFP harus mencantumkan identifikasi akan kebutuhan keamanan aplikasi yang akan dibuat (NIST SP 800-53 Control SA-4)

IT Development

M4 Jul 2013

Perbaikan standar dokumen RFP



44


No

ANCAMAN

PENGENDALIA N RISIKO

KONTROL BARU

Penanggung Jawab

Batas Waktu

Program Kerja

Mitigasi / Terima / Transfer


PIC

14

Ujicoba khusus terhadap standar kontrol keamanan belum dilakukan dan didokumentasikan pada fase implementasi

Mitigasi

Skenario ujicoba keamanan aplikasi dibuat berdasarkan standar kontrol keamanan aplikasi yang telah dibakukan serta kebutuhan keamanan aplikasi yang diidentifikasikan dalam dokumen BRS dan FRS. (NIST SP 800-53 Control SA-11)

IT Development

M4 Jul 2013

Perubahan prosedur pengadaan software TI. Perubahan dokumen SDLC Lintasarta. Perubahan dokumen standar QC software TI.

15

Kewajiban akan penyelenggaraan pelatihan atau sosialisasi untuk penyegaran akan kebijakan standar keamanan pengembangan aplikasi belum dibakukan

Mitigasi

Sosialisasi mengenai standar keamanan pengembangan aplikasi wajib dilakukan bagi rekanan dan karyawan baru di bagian IT Development dan Sosialisasi secara berkala wajib masuk ke dalam program kerja tahunan IT Development. (NIST SP 800-53 Control AT-1, AT-2, AT-3)

IT Development

M4 Jul 2013

Pembuatan standar pedomanan keamanan pengembangan aplikasi



45

5.5 Draft Dokumen Pedoman Keamanan Pengembangan Aplikasi Web Draft dokumen Pedoman Keamanan Pengembangan Aplikasi Web disusun berdasarkan rekomendasi kontrol yang dipilih sesuai dengan kebutuhan dari perusahaan. Pemetaan kontrol-kontrol baru yang diperlukan dengan isi dari dokumen pedoman dijelaskan pada Tabel 5.7. Dokumen terdiri dari 3 bagian : a. Bagian Awal terdiri dari : halaman judul, lembar pengesahan, lembar informasi dokumen, daftar isi. b. Bagian Isi terdiri dari : •

Pengantar, menjelaskan latar belakang dibutuhkannya dokumen, tujuan pembuatan dokumen, pengguna dari dokumen, kebijakan umum dan ruang lingkup yang diatur oleh pedoman ini.

•

Peran dan Tanggung Jawab pihak-pihak yang diatur oleh dokumen pedoman ini untuk memastikan pedoman dijalankan.

•

Pedoman Keamanan Proses Pengembangan Aplikasi, menjelaskan pedoman-pedoman yang harus diikuti dalam proses pembuatan Kerangka Acuan Kerja, dokumen Project Plan, BRS, FRS, kegiatan disain, konstruksi, ujicoba dan sosialisasi aplikasi.

•

Pedoman Keamanan Teknis Pengembangan Aplikasi, menjelaskan pedoman-pedoman teknis yang harus diikuti dalam proses pengembangan aplikasi seperti aturan validasi data input, otentikasi, otorisasi, konfigurasi web server, manajemen sesi, penanganan data rahasia, dan penanganan exception.

•

Sanksi, menjelaskan pengenaan sanksi atas kelalaian mengikuti pedoman ini.

c. Bagian Lampiran terdiri dari dokumen lampiran yang berisi template dokumen KAK dan SDLC yang telah direvisi.



46

Tabel 5. 7 Pemetaan Kontrol Baru dengan Dokumen Pedoman No

Rekomendasi kontrol baru

1

Standarisasi Penggunaan Tools Pemrogramman yang dapat mengendalikan ancaman injeksi SQL baik untuk vendor ataupun internal

2

Memasukan kegiatan verifikasi keamanan aplikasi untuk ancaman injeksi SQL dalam setiap kegiatan ujicoba aplikasi yang sedang dikembangkan dan akan dioperasionalkan Aplikasi harus melakukan otentikasi dan otorisasi hak akses user terhadap halaman web yang mengakses referensi obyek (file atau gambar)

OWASP Top 10 Risk

OWASP ASVS V.2.1

Untuk mengakses semua halaman web dan sumber daya, dibutuhkan otentikasi, kecuali memang ditujukan kepada publik

PKPA 4.3.2

Penggunaan referensi obyek tidak langsung untuk menghindari perubahan parameter URL secara manual oleh pengguna

OWASP Top 10 Risk

Gunakan referensi obyek tidak langsung per pengguna atau sesi. Hal ini mencegah penyerang langsung mengarah ke sumber daya tidak terotorisasi

PKPA 4.7

3

4

Kontrol Standar OWASP Top 10 Risk

Keterangan Kontrol Standar

Kontrol dokumen PKPA 3.4.3

Penggunaan API / Interpreter yang aman , standar yang dibawa oleh tool pemrograman yang aman.

Validasi data input PKPA 4.1 Skenario ujicoba yang mengevaluasi hasil konstruksi PKPA 3.5.2 aplikasi berdasarkan pedoman keamanan aplikasi PKPA 4.1 harus dibuat dan dilaksanakan oleh fungsi audit.



47

Tabel 5.7 (Sambungan) No


5

Penggunaan token unik terenkripsi untuk setiap URL permintaan persetujuan yang dikirimkan melalui suatu email yang kode parameternya tidak mudah dipahami user. Adanya konfirmasi kembali dari sistem atas data yang berhasil / gagal dicatat oleh sistem atas tindakan yang dilakukan oleh pengguna

6

7

Standar konfigurasi server web aplikasi yang telah memperhatikan faktor keamanan dari ancaman serangan

Kontrol Standar OWASP Top 10 Risk


OWASP ASVS V.8.5

Pastikan pencatatan kontrol keamanan menyediakan kemampuan untuk mencatat peristiwa keberhasilan dan kegagalan yang diidentifikasi sebagai catatan yang terkait keamanan.

OWASP Top 10 Risk

PKPA 4.10 Arsitektur aplikasi yang kuat yang menyediakan pemisahan dan keamanan yang tegas antar komponen

Penggunaan token unik terenkripsi untuk setiap URL permintaan persetujuan yang dikirimkan melalui suatu email yang kode parameternya tidak mudah dipahami user.

Kontrol dokumen PKPA 4.11

PKPA 4.11

Menjalankan scan dan melakukan audit secara periodik untuk membantu mendeteksi kesalahan konfigurasi atau patch yang hilang di masa mendatang.

8

Setiap halaman web harus diotentikasi dan diotorisasi berdasarkan peran (Role) yang diperiksa berdasarkan sesi login, bukan berdasarkan halaman URL

OWASP ASVS V.2.1

Untuk mengakses semua halaman web dan sumber daya, dibutuhkan otentikasi, kecuali memang ditujukan kepada publik

PKPA 4.3



48



9

Kebutuhan keamanan aplikasi menjadi satu bagian yang wajib untuk dibuat dan diidentifikasikan dalam dokumen kebutuhan aplikasi, dan dokumen disain aplikasi.

Kontrol Standar NIST SP 80053 Contrrol SA-1

NIST SP 80053 Contrrol SA-2


1. Organisasi mengembangkan, melaksanakan, melakukan peninjauan dan pembaruan terhadap : • Kebijakan formal dan terdokumentasi untuk proses akuisisi sistem dan layanan yang telah memasukan pertimbangan keamanan informasi yang mencakup tujuan, lingkup, peran, tanggung jawab, komitmen manajemen, kordinasi kerja antar unit dalam organisasi serta kepatuhan. • Prosedur formal dan terdokumentasikan untuk memfasilitasi implementasi kebijakan di atas. 1. Menentukan kebutuhan keamanan informasi untuk sistem informasi dalam suatu misi atau bisnis. 2. Menentukan, mendefinisikan dan mengalokasikan sumber daya yang diperlukan untuk menjaga sistem informasi sebagai bagian dari rencana modal dan proses pengendalian investasi. 3. Menentukan fungsi Security Officer dalam organisasi pemrograman / proyek dan semua sumber daya telah direncanakan untuk memastikan fungsi keamanan bisa terlaksana.

Kontrol dokumen PKPA 3.1.1.A

PKPA 3.2.1.A.1

PKPA 3.2.1.A.3

PKPA 3.1.1.B



49






1. Organisasi mengelola sistem informasi menggunakan System Development Life Cycle (SDLC) yang terdokumentasikan dan sejalan dengan pertimbangan keamanan informasi. 2. Tentukan dan dokumentasikan peran dan tanggung jawab keamanan informasi dalam SDLC. 3. Tentukan individu-individu yang memiliki peran dan tanggung jawab dalam keamanan informasi dan integrasikan proses manajemen risiko organisasi ke dalam aktivitas SDLC.

1. Organisasi mensyaratkan pengembang sistem informasi untuk mematuhi proses pengembangan yang terdokumentasikan, yaitu : a. Secara jelas menuliskan kebutuhan keamanan b. Mengidentifikasikan standar dan perangkat lunak pengembangan yang digunakan dalam proses pengembangan dan mendokumentasikan secara spesifik pilihanpilihan dan konfigurasi perangkat lunak yang digunakan dalam pengembangan sistem informasi. 2. Melakukan peninjauan terhadap proses pengembangan, standar, perangkat dan pilihan-


PKPA 2

PKPA 3.2.1.A.4

PKPA 3.2.1.B

PKPA 3.2.1.B.3

PKPA 1.5.6



50

No


Kontrol Standar

Tabel 5.7 (Sambungan) Keterangan Kontrol Standar

Kontrol dokumen

pilihan serta konfigurasi dari perangkat untuk memastikan bahwa proses, standar, perangkat dan pilihan-pilihan konfigurasi yang dipilih akan memenuhi kebutuhan keamanan organisasi.

10

Pembuatan standar kontrol keamanan aplikasi yang perlu diperhatikan dalam kegiatan ujicoba aplikasi (NIST SP 80053 Control SA-15)


1. Organisasi mensyaratkan pengembang sistem informasi untuk mematuhi proses pengembangan yang terdokumentasikan, yaitu : a. Secara jelas menuliskan kebutuhan keamanan b. Mengidentifikasikan standar dan perangkat lunak pengembangan yang digunakan dalam proses pengembangan dan mendokumentasikan secara spesifik pilihanpilihan dan konfigurasi perangkat lunak yang digunakan dalam pengembangan sistem informasi. 2. Melakukan peninjauan terhadap proses pengembangan, standar, perangkat dan pilihanpilihan serta konfigurasi dari perangkat untuk memastikan bahwa proses, standar, perangkat dan pilihan-pilihan konfigurasi yang dipilih akan memenuhi kebutuhan keamanan organisasi.

PKPA 3.2.1.B

PKPA 3.2.1.B.3

PKPA 1.5.6



51



11

Standar dokumen RFP harus mencantumkan identifikasi akan kebutuhan keamanan aplikasi yang akan dibuat (NIST SP 800-53 Control SA-4)

12

Skenario ujicoba keamanan aplikasi dibuat berdasarkan standar kontrol keamanan aplikasi yang telah dibakukan serta kebutuhan keamanan aplikasi yang diidentifikasikan dalam dokumen BRS dan FRS. (NIST SP 800-53 Control SA-11)




Organisasi mensyaratkan agar pengembang sistem informasi melakukan :

Organisasi memasukan kebutuhan-kebutuhan, keterangan, dan kriteria berikut ini, baik secara terang atau melalui suatu referensi di dalam kontrak pengadaan sistem informasi sesuai dengan hukum perundangan, peraturan pemerintah, kebijakan, peraturan, standar, pedoman dan misi bisnis organisasi. a. Kebutuhan fungsional keamanan b. Kebutuhan jaminan keamanan c. Kebutuhan dokumentasi terkait keamanan d. Deskripsi lingkungan pengembangan sistem informasi dan lingkungan saat sistem di operasionalkan. e. Syarat ujiterima.

Kontrol dokumen PKPA 3.1.1.A

PKPA 3.5.1

1. Membuat dan melaksanakan uji keamanan dan rencana evaluasi yang mengakomdasi pengujian atau evaluasi : a. Sampai kedalaman (pilihan): i. Properti fungsional yang berkaitan dengan keamanan ii. Disain level tinggi Universitas Indonesia


52


13


Kontrol Standar

Sosialisasi mengenai standar keamanan pengembangan aplikasi wajib dilakukan bagi rekanan dan karyawan baru di bagian IT Development dan Sosialisasi secara berkala wajib masuk ke dalam program kerja tahunan IT Development. (NIST SP 800-53 Control AT-1, AT-2, AT-3)


Kontrol dokumen

iii. Disain level rendah iv. Representasi implementasi (kode sumber) b. Sampai tingkat ketelitian (pilihan) : i. Pengujian (pilihan) : uji unit, uji integrasi, system. Membuat bukti pelaksanaan rencana pengujian atau evaluasi dan hasil dari pengujian dan evaluasi tersebut. NIST SP 800- Organisasi mengembangkan, menyebarluaskan dan 53 Control AT- melakukan tinjauan dan pembaruan : a. Kebijakan pelatihan dan sosialisasi keamanan 1 yang formal dan terdokumentasikan yang mencatat tujuan, lingkup, peran, tanggung jawab, komitmen manajemen, kordinasi antar entitas organisasi dan kepatuhan. b. Prosedur formal dan terdokumentasikan yang memfasilitasi implementasi dari kebijakan pelatihan dan sosialisasi keamanan serta kontrol yang berkaitan dengan pelatihan dan sosialisasi keamanan tersebut.

PKPA 3.6.1.1



53



Kontrol Standar NIST SP 80053 Control AT2


Organisasi menyediakan sosialisasi dasar mengenai keamanan informasi kepada pengguna (termasuk manager, eksekutif senior dan rekanan pengembang) : a. Sebagai bagian dari pelatihan pertama pengguna baru. b. Ketika dibutuhkan oleh perubahan sistem. c. Pengulangan berkala.

NIST SP 800- Organisasi menyediakan pelatihan keamanan 53 Control AT- informasi berbasis peran kepada pengguna sistem informasi : 3 a. Sebelum diberikan akses ke dalam sistem informasi dalam tugas kerjanya. b. Ketika dibutuhkan saat ada perubahan sistem. c. Dilakukan secara berkala.


PKPA 3.6.1



BAB 6 KESIMPULAN DAN SARAN

6.1 Kesimpulan Kesimpulan dari karya akhir ini adalah : 1. Penyusunan pedoman keamanan pengembangan aplikasi web untuk PT. Aplikanusa Lintasarta dilakukan dengan melakukan penilaian risiko untuk memperoleh kontrol atas ancaman dan kerawanan baik dalam proses pengembangannya maupun ancaman dan kerawanan terhadap aplikasi web yang dimiliki perusahaan. 2. Penyusunan pedoman keamanan pengembangan aplikasi web untuk PT. Aplikanusa Lintasarta telah dilakukan dengan menggunakan penilaian risiko berbasis OWASP dan NIST yang dikombinasikan dengan prosedur pedoman manajemen risiko dari Lintasarta. 3. Pedoman keamanan tersebut berisi kumpulan kontrol yang dipilih dari kontrol standar OWASP dan NIST sesuai dengan identifikasi ancaman kerawanan serta penilaian risiko atas situasi dan kondisi pengembangan aplikasi web di Lintasarta. 6.2 Saran Saran yang dapat disampaikan Penulis melalui karya akhir ini adalah : 1. Saran untuk PT. Aplikanusa Lintasrta. a. Pedoman keamanan pengembangan aplikasi web ini masih perlu disempurnakan dengan dilengkapi beberapa dokumen template untuk kegiatan implementasi aplikasi saat pertama kali operasional. Seperti template check list setting keamanan aplikasi yang akan dioperasionalkan. Hal ini tidak penulis buat dikarenakan diluar lingkup dari karya akhir ini yang hanya membatasi pada proses pengembangan aplikasi web saja.

54



55

b. Selanjutnya pedoman keamanan ini dapat digabungkan menjadi salah satu bagian dari dokumen pengembangan aplikasi yaitu dokumen SDLC Lintasarta. 2. Saran untuk penelitian berikutnya. Karya akhir ini masih dapat dilanjutkan dengan penelitian mengenai tingkat efektivitas atas pelaksanaan pedoman keamanan ini apakah benar secara nyata setelah dijalankan dapat menurunkan tingkat risiko dan dampak

dari

ancaman

keamanan

dan

kerawanan

yang

telah

diidentifikasikan sebelumnya.



DAFTAR PUSTAKA

Fajar Kurnia, Aries. (2007). Perencanaan Kebijakan Keamanan Informasi Berdasarkan Information Security Management System [ISMS] ISO 27001 studi kasus Bank XYZ. MTI UI. Johnson, Paul. (2009, 3 Februari). What are Policies, Standards, Guidelines and Procedures ?. 17 Februari 2013. http://mindfulsecurity.com/2009/02/03/ policiesstandards-and-guidelines. NIST .(2001). NIST Special Publication 800-26 : Security Self-Assessment Guide for Information Technology System. NIST .(2012). NIST Special Publication 800-53 revision 4 : Security and Privacy Controls for Federal Information Systems and Organizations. NIST. OWASP (2009). OWASP application security verification standard 2009 : Web Application Standard Release - versi Bahasa Indonesia. OWASP OWASP. (2010). Top Ten Most Critical Web Application Security Risk – 2010. OWASP OWASP (2013). OWASP Risk Rating Methodology. 1 Maret 2013. https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology PT. Aplikanusa Lintasarta. (2011). Dokumen Katalog Software IT. PT. Aplikanusa Lintasarta. (2011). IT Strategic Plan 2011-2015. PT. Aplikanusa Lintasarta. (2010). Software Development Life Cycle 1.3. PT. Aplikanusa Lintasarta. (2012). Prosedur Permintaan dan Pengadaan Software. PT. Aplikanusa Lintasarta. (2012). Pedoman Manajemen Resiko Keamanan Informasi. PT. Aplikanusa Lintasarta. (2013). IT Strategic Plan 2013-2018. SANS. (2013) . Introduction to the SANS Security Policy Project. 17 Februari 2013. http://www.sans.org/security-resources/policies/#name. Silitonga, Vinicio Vasquera. (2012). Perancangan Manajemen Risiko pada PT. XYZ dengan menggunakan metode NIST 800-30. MTI UI. Stoneburnner. (2002). NIST Spesical Publication 800-30 : Risk Management Guide for Information Technology Systems. NIST 56



57

Whitman, M. (2012). Principles Of Information Security (3 rd ed.). Course Technology.



LAMPIRAN 1 : Tabel-Tabel Analisa Risiko dan Kontrol

58



59

Tabel Lampiran 1. 1 Rekapitulasi Tingkat Risiko Inheren OWASP

No

Agen Ancaman (A)

Ancaman

1 Injeksi SQL


Kerawanan (B)

Faktor Kemungkinan C = (A+B)/2

Dampak Teknis

Dampak Bisnis

Tingkat Risiko

5.75

8.25

7

7.5

7

Kritis

5

7.75

6.375

3.75

5.25

Tinggi

Otentikasi dan Pengelolaan Sesi yang buruk Referensi Obyek Langsung yang tidak 4 aman 5 Cross-Site Request Forgery

6.5

7.5

7

5.5

5.25

Tinggi

6.25

6.5

6.375

4

5.25

Tinggi

4.25

6.25

5.25

4.25

3

Sedang


5.25

8.25

6.75

7

4.75

Tinggi

3

3.75

3.375

5.5

4

Sedang

5.75

5

5.375

7

5.25

Sedang

4.5

2.5

3.5

7.5

6

Tinggi

5.25

6.75

6

3.25

3

Tinggi

3

7 Penyimpanan Kriptografi yang tidak aman

8 Kegagalan membatasi akses url

9

10





60

Tabel Lampiran 1. 2 Kemungkinan dan Dampak OWASP Status Nilai

Batas Bawah

Rendah Sedang Tinggi

Batas Atas

Kode Warna

0 <3 3 <6 6 9


Tabel Lampiran 1. 3 Matrik Risiko OWASP Matrik Risiko

Dampak

Tinggi Sedang Rendah

Rendah Sedang Rendah Rendah

Kebolehjadian Sedang Tinggi Sedang Rendah

Tinggi Kritis Tinggi sedang




61

Tabel Lampiran 1. 4 Rekapitulasi Tingkat Risiko Residual OWASP (Kontrol Saat Ini)

No

Agen Ancaman (A)

Ancaman

Kerawanan (B)

Faktor Kemungkina n (A+B)/2

Dampak Teknis

Dampak Bisnis

Tingkat Risiko

1 Injeksi SQL

5.75

5.25

5.5

7.5

7

Tinggi


1.75

1.75

1.75

2.25

1.75

Rendah

2.75

2

2.375

2.75

1.75

Rendah

6.25

4.5

5.375

4

3.75

Sedang

4.25

4.75

4.5

4.25

3

Sedang

5.25

4.75

5

3.75

4.75

Sedang

2.5

2.5

2.5

1.75

2.25

Rendah

5.75

4.5

5.125

6.5

4.5

Sedang

2.75

2

2.375

0.25

4.75

Rendah

2.5

3.75

3.125

1.75

1

Rendah

Otentikasi dan Pengelolaan Sesi yang buruk Referensi Obyek Langsung yang tidak 4 aman 5 Cross-Site Request Forgery

3


7


8 Kegagalan membatasi akses url

9

10





62

Tabel Lampiran 1. 5 Rekapitulasi Tingkat Risiko Harapan OWASP (Kontrol Baru)

No Ancaman 1 Injeksi SQL

Agen Ancaman (A) 2.5

Kerawanan (B) 2.75


1.75

3

4

5

6

7

8

9

10

Otentikasi dan Pengelolaan Sesi yang buruk Referensi Obyek Langsung yang tidak aman Cross-Site Request Forgery Kesalahan Konfigurasi Keamanan Penyimpanan Kriptografi yang tidak aman Kegagalan membatasi akses url Perlindungan yang tidak cukup pada layer transport Redirect dan Forward yang tidak divalidasi

Faktor Kemungkin an (A+B)/2 2.625

Dampa k Teknis 1.75

Dampa k Bisnis 2.75

Tingkat Risiko Rendah

Keterangan

1.75

1.75

2.25

1.75

Rendah

Sama dengan tingkat risiko residualnya

2.75

2

2.375

2.75

1.75

Rendah


2.5

2.5

2.5

1.75

1.75

Rendah

1

2.75

1.875

1.75

1.75

Rendah

1.75

2.75

2.25

2.25

1.75

Rendah

2.5

2.5

2.5

1.75

2.25

Rendah

2.25

2.5

2.375

1.75

2.25

Rendah

2.75

2

2.375

0.25

4.75

Rendah


2.5

3.75

3.125

1.75

1

Rendah





63

Tabel Lampiran 1. 6 Self Assessment Identifikasi Faktor Kecenderungan Agen Ancaman Keamanan Aplikasi Sumber : (OWASP 2013) telah diolah kembali

Faktor Inheren No

1

Ancaman (Top 10 OWASP)

Injeksi SQL

Faktor Agen Ancaman

Tingkat Kebolehjadian (likelyhood)

Motivasi

Peluang

Faktor Harapan (dengan kontrol baru)

N P1

Kemampuan yang dibutuhkan Agen Ancaman

Faktor Residual (dengan kontrol saat ini)

P1xN

Ratarata

P2

5.75

P2xN

P3

0

0

1

0

0

3

0

0

0

4

0

Beberapa kemampuan Teknis

6

0

0

0

Tidak ada kemampuan teknis

9

0

0

0

Tidak bisa diaplikasikan Reward sangat rendah atau tidak ada

0

0

0

0

1

0

0

0

Kemungkinan memiliki Reward

4

0

0

0

Reward Tinggi Membutuhkan akses penuh dan mahal Membutuhkan akses atau sumber daya khusus

9

1

1

9

1

1

0

0

4

4

1

4

1

5.75

P3xN

Tidak bisa diaplikasikan Memiliki kemampuan meretas keamanan Kemampuan Jaringan dan Pemrogramman Pengguna Komputer Tingkat Lanjut

4

0

Ratarata

0

1

2.5

1

9

1

9

0

1

0

4

Ratarata

0 Universitas Indonesia


64

Table Lampiran 1.6 (Sambungan) Faktor Residual (dengan kontrol saat ini)

Faktor Inheren No


Faktor Agen Ancaman


Ukuran Populasi

2


N P1

Hanya membutuhkan sedikit akses atau sumber daya Tidak membutuhkan akses atau sumber daya


Motivasi


P1xN

Ratarata

P2

P2xN

Ratarata

P3

P3xN

7

0

0

0

9

0

0

0

Tidak bisa diaplikasikan

0

0

0

Administrator Sistem

2

0

0

0

Pengguna Intranet

4

0

0

0

Rekanan pengembang

5

0

0

0

User terotentikasi

6

6

0

Pengguna Internet Anonymous

9

0

0

0


0

0

1

0

1

6

1

5

0

1.75

1

0

0

1

0

3

0

0

4

0

0

0


6

0

0

0


9

0

0

0


0

0

0

0

3

1

1

1

Ratarata

2.75



65

Table Lampiran 1.6 (Sambungan) Faktor Inheren No


Faktor Agen Ancaman

Ukuran Populasi

Otentikasi dan Pengelolaan

Kemampuan yang dibutuhkan


N P1

Peluang

3



P1xN

Reward sangat rendah atau tidak ada

1

0


4

0

Reward Tinggi Membutuhkan akses penuh dan mahal Membutuhkan akses atau sumber daya khusus Hanya membutuhkan sedikit akses atau sumber daya Tidak membutuhkan akses atau sumber daya

9

1

Ratarata

1

9

0

0

P2

1

P2xN

Ratarata

P3

P3xN

0

0

4

0

0

1

9

0

1

0

4

0

0

7

0

0

0

9

0

0

0


0

0

0

0


2

0

Pengguna Intranet

4

Rekanan pengembang

4

1

1

2

1

2

4

0

0

5

0

0

0

User terotentikasi

6

0

0

0


9

0

0

0

Tidak bisa diaplikasikan Memiliki kemampuan meretas keamanan

1

0

0

1

0

6.5

1

0

0

2.75

Ratarata

-

-

-

-



66



Sesi yang buruk

Faktor Agen Ancaman


Motivasi

Peluang

Ukuran Populasi

Kemampuan Jaringan dan Pemrogramman Pengguna Komputer Tingkat Lanjut


N P1

Agen Ancaman


P1xN

Ratarata

P2

P2xN

Ratarata

P3

P3xN

3

0

0

-

-

4

0

0

-

-


6

0

0

-

-


9

9

0

-

-


0

0

0

-

-

1

0

0

-

-


4

0

0

-

-


9

1

9

1

9

-

-

0

1

0

-

-

4

0

-

-

7

0

0

-

-

9

0

0

-

-


0

0

0

-

-


2

0

2

-

-

Pengguna Intranet

4

0

-

-

1

0

4

1

1

1

4

Ratarata



67


4



Faktor Agen Ancaman


Motivasi

Peluang


N P1



P1xN

Ratarata

P2

P2xN

Ratarata

P3

P3xN

Rekanan pengembang

5

0

0

-

-

User terotentikasi

6

0

0

-

-


9

0

0

-

-

6.25

0

0

1

0

0

3

0

0

0

4

0

0

0


6

6

0


9

0

0

0


0

0

0

0

1

0

0

0


4

0

0

0


9

1

1

9

1

1

0

0

4

6

0

0


1

4

1

6.25

1

2.5

1

9

1

9

0

1

0

4

Ratarata

0



68



Faktor Agen Ancaman


Ukuran Populasi

5



Motivasi


N P1



P1xN

Ratarata

P2

P2xN

Ratarata

P3

P3xN

7

0

0

0

9

0

0

0


0

0

0


2

0

0

0

Pengguna Intranet

4

0

0

0

Rekanan pengembang

5

0

0

0

User terotentikasi

6

6

0


9

0

0

0


0

0

1

0

4


1

6

4.25

0

0

0

1

0

0

0

6

0

0

0


9

0

0

0


0

0

0

0

Reward sangat rendah atau tidak

1

1

1

1

1

1

1

1

0

1

1

4.25

0

3

3

3

1

1

Ratarata



69



Faktor Agen Ancaman




N P1

P1xN

Ratarata

P2

P2xN

Ratarata

P3

P3xN

Ratarata

ada

Peluang

Ukuran Populasi

6


Kemampuan yang dibutuhkan Agen


4

0

0

0


9

0

0

0

0

0

0

4

0

0

0

7

0

9

0

0

0


0

0

0

0


2

0

0

Pengguna Intranet

4

0

0

0

Rekanan pengembang

5

0

0

0

User terotentikasi

6

6

0


9

0

0

7

1

1

7

1

6

1

0

5.25


0

0

0

1

0

0

Kemampuan Jaringan dan

3

0

0

1

1

5.25

0

2

0

1

1.75

1



70



Faktor Agen Ancaman

Ancaman

Motivasi

Peluang

Ukuran Populasi




N P1

P1xN

1

4

Ratarata

Ratarata

P2

P2xN

1

4

0

P3

P3xN

Ratarata

Pemrogramman

Pengguna Komputer Tingkat Lanjut

4


6

0

0

0


9

0

0

0


0

0

0

0

1

0

0

0


4

0

0


9

1

1

0

0

4

9

1

4

9

0

1

1

4

0

1

0

4

0

7

0

0

0

9

0

0

0


0

0

0

0


2

0

0

Pengguna Intranet

4

1

4

1

4

1

2

0



71

Table Lampiran 1.6 (Sambungan) Faktor Residual (dengan kontrol saat ini)

Faktor Inheren No

7



Faktor Agen Ancaman


N P1


Motivasi

Peluang


P1xN

Ratarata

P2

P2xN

Ratarata

P3

P3xN

Rekanan pengembang

5

0

0

0

User terotentikasi

6

0

0

0


9

0

0

0


0

1

0

1

1

3

-

-

1

-

-

0

1

2.5

3

0

0

-

-

4

0

0

-

-


6

0

0

-

-


9

0

0

-

-


0

0

0

-

-

1

0

0

-

-


4

0

0

-

-


9

1

9

1

9

-

-

0

1

0

1

0

-

-

0

-

-

4

0

Ratarata



72



Faktor Agen Ancaman


Ukuran Populasi

8



Motivasi


N P1



P1xN

Ratarata

P2

P2xN

Ratarata

P3

P3xN

7

0

0

-

-

9

0

0

-

-


0

0

0

-

-


2

2

0

-

-

Pengguna Intranet

4

0

0

-

-

Rekanan pengembang

5

0

0

-

-

User terotentikasi

6

0

0

-

-


9

0

0

-

-


0

0

1

0

1

0

0

0

3

0

0

0

4

0

0

0


6

6

0


9

0

0

0


0

0

0

0

Reward sangat rendah atau tidak

1

0

0

0

1

1

6

1

5.75

0

1

5.75

Ratarata

2.25



73



Faktor Agen Ancaman




N P1

P1xN

Ratarata

P2

P2xN

Ratarata

P3

P3xN

Ratarata

ada

Peluang

Ukuran Populasi

9

Perlindungan yang tidak cukup pada layer

Kemampuan yang dibutuhkan Agen


4


9

0

1

9

1

0

0

4

0

1

4

1

0

9

1

9

0

1

0

4

0

7

0

0

0

9

0

0

0


0

0

0


2

0

0

0

Pengguna Intranet

4

4

0

Rekanan pengembang

5

0

0

0

User terotentikasi

6

0

0

0


9

0

0

0

1

4


0

0

1

0

Kemampuan Jaringan dan

3

3

1

1

4.5

1

0

1

2.75

0

-

-

0

-

-

0

-



74



transport

Faktor Agen Ancaman


Motivasi

Peluang

Ukuran Populasi


N P1

Ancaman


P1xN

Ratarata

P2

P2xN

Ratarata

P3

P3xN

Ratarata

Pemrogramman

Pengguna Komputer Tingkat Lanjut

4

0

0

-

-


6

0

0

-

-


9

0

0

-

-


0

0

0

-

-

1

0

0

-

-


4

0

0

-

-


9

9

1

9

-

-

0

1

0

-

-

4

0

-

-

7

0

0

-

-

9

0

0

-

-


0

0

0

-

-


2

2

-

-

Pengguna Intranet

4

0

-

-

1

0

4

1

1

2

1

0



75


10



Faktor Agen Ancaman


Motivasi

Peluang


N P1



P1xN

Ratarata

P2

P2xN

Ratarata

P3

P3xN

Rekanan pengembang

5

0

0

-

-

User terotentikasi

6

0

0

-

-


9

0

0

-

-

-

-

5.25


0

0

1

0

0

-

-

3

0

0

-

-

4

0

-

-


6

0

0

-

-


9

0

0

-

-


0

0

0

-

-

1

0

0

-

-


4

4

-

-


9

0

0

-

-

0

0

0

-

-

4

0

4

-

-

4

1

1

4

1

1

1

0

2.5

Ratarata



76



Faktor Agen Ancaman



N P1

P1xN

1

7

9


Ratarata

P2

P2xN

Ratarata

P3

P3xN

0

-

-

0

0

-

-

0

0

0

-

-


2

0

2

-

-

Pengguna Intranet

4

0

0

-

-

Rekanan pengembang

5

0

0

-

-

User terotentikasi

6

6

0

-

-


9

0

0

-

-


Ukuran Populasi


7

1

1

Ratarata



77

Tabel Lampiran 1. 7 Self Assessment Identifikasi Faktor Kerawanan Keamanan Aplikasi Sumber : (OWASP 2013) telah diolah kembali

No


Faktor Inheren Faktor Kerawanan

Tingkat Kerawanan

Injeksi SQL

Kemudahan untuk ditemukan

Kemudahan untuk dieksploitasi

Kesadaran (Awareness)


N

P1

1


P1xN

Tidak bisa diaplikasikan Secara praktis tidak memungkinkan

0

0

1

0

Sulit

3

0

Mudah

7

Perangkat Otomatis tersedia

9

Ratarata

P2

8.25

P2xN

Ratarata

0

5.25

P3

P3xN

0

Ratarata

2.75

1

1

0

1

3

0

0

0

0

9

0

1

0

1


0

0

0

Secara Teori

1

0

0

0

Sulit

3

0

3

0

Mudah

5

0

0

0


9

9

0

0

Tidak diaplikasikan

0

0

0

1

1

0

0

1

Tidak diketahui

1

0

0

Disembunyikan

4

0

0

0

Cukup Jelas

6

6

0

1

6

1

1



78

Table Lampiran 1.7 (Sambungan)

No



Tingkat Kerawanan

2



Ratarata

P2

P2xN

Ratarata

P3

P3xN

7

0

0

0

Tidak diaplikasikan

0

0

0

0

Deteksi aktif di level aplikasi

1

0

0

0

Ada log dan review

3

0

0

0

Ada Log saja

8

0

0

Tidak ada Log

9


0

1

1


0

1.75

-

9

-

1

5


9

0

-

0

-

-

0

-

-

0

-

-

0

-

-

0

-

-

0

0

-

-

9

0

-

-

0

-

-

9

0

1

0

0

1

-

3

1

0

1

Mudah

0

-

0

3


0

1

9

0

0

7

9

Sulit

7.75

Ratarata

-


Secara Teori

1

9

0

3

Mudah

Kesadaran

P1xN

Diketahui oleh Publik (diluar perusahaan)

Sulit



N

P1

Deteksi Penyusup


0



79


No



Tingkat Kerawanan

(Awareness)

Tidak diketahui

1

Tersembunyi

4

Cukup Jelas Diketahui oleh Publik (diluar perusahaan)

Deteksi Penyusup





P1xN

Ratarata

P2

P2xN

0

1

6

1

4

0

Ratarata

P3

P3xN

0

-

-

4

-

-

0

-

-

7

0

0

0

1

0

1

0

-

0

-

-

0

-

-

-

Ada log dan review

3

0

0

Ada Log saja

8

0

0

-

-

0

-

-

0

-

-


9

1

0

9

0

7.5

1

2

1

0

0

-

Sulit

3

0

0

-

Mudah

7

0

0

-

-


9

9

0

-

-

0

-

-

-

-


Ratarata

-

-

Tidak ada Log



N

P1

3


0

1

0

1

Secara Teori

1

0

0

-

Sulit

3

0

0

-

-



80


No



Tingkat Kerawanan


Deteksi Penyusup

Mudah

5


9


1

Tersembunyi

4


6




1

0

Tidak diketahui



N

P1

4


P1xN

Ratarata

P2xN

Ratarata

P3

P3xN

0

0

-

-

9

0

-

-

0

-

-

0

0

-

-

4

0

-

-

0

0

-

-

1

0

1

P2

Ratarata

7

0

0

1

Ada log dan review

3

Ada Log saja

8

Tidak ada Log

9

0

0

0

0

1

1

8

0


0

0

1

0

Sulit

3

0

Mudah

7


9

6.5

-

0

-

-

0

-

-

0

-

-

8

-

-

0

-

-

0

4.5

0

2.5

1

1

0

1

3

0

7

0

0

0

0

0

1



81


No



Tingkat Kerawanan


Deteksi Penyusup

5




N

P1



P1xN

Ratarata

P2

P2xN

Ratarata

P3

1

P3xN


0

0

0

Secara Teori

1

0

0

0

Sulit

3

0

3

0

Mudah

5

5

0

0


9

0

0

0


0

0

0

1

Tidak diketahui

1

0

Tersembunyi

4

0


6

1

0

0

1

0

1

4

0

6

0

0

7

0

0

0


0

0

0

0


1

0

0

0

Ada log dan review

3

0

0

1

Ada Log saja

8

1

Tidak ada Log

9

0


0

0

1

1

8

0

1

8

0

6.25

0

Ratarata

8

0

4.75

0

2.75

1 1

0

0

1



82


No



Tingkat Kerawanan


Deteksi Penyusup


N

P1



P1xN

P2

P2xN

P3

P3xN

0

0

0

0

9

0

3

0

Mudah

7


9

1

Ratarata

3

Sulit

1

Ratarata

0

1


0

0

0

Secara Teori

1

0

0

0

Sulit

3

3

0

Mudah

5

0

0

0


9

0

0

0


0

0

0

0

Tidak diketahui

1

0

0

Tersembunyi

4


6

1

3

1

1

0

0

0

0

7

0

0

0


0

0

0

0


1

0

0

0

Ada log dan review

3

0

0

0

Ada Log saja

8

0

0

Tidak ada Log

9

1

4

9

1

1

0

4

1

1

9

Ratarata

0

1



83


No



Tingkat Kerawanan





Deteksi Penyusup


N

P1

6


P1xN


0

0

1

0

Sulit

3

0

Mudah

7


9


Ratarata

P2

8.25

P2xN

Ratarata

0

4.75

P3

P3xN

0

Ratarata

2.75

1 0

1

3

0

0

0

0

9

0

0

0

0

0

0

Secara Teori

1

0

0

Sulit

3

0

Mudah

5


9


1

1

1

3

0

0

0

0

9

0

0

0

0

0

0

Tidak diketahui

1

0

0

Tersembunyi

4

0


6

1

1

1

1

4

0

6

0

0

7

0

0

0


0

0

0

0


1

0

0

0

1

1

1



84


No



Tingkat Kerawanan

Penyimpana n Kriptografi yang tidak aman



Ratarata

P2

P2xN

3

0

0

Ada Log saja

8

0

0

Tidak ada Log

9

3.75

P3

P3xN

1

8

9

0

Ratarata

0

0

2.5

-

-

0

1

1

-

3

0

-

7

0

0

-

-

9

0

0

-

-

0

-

-

0

0

-

-

3

0

-

-

0

0

-

-

0

-

-

0

-

-

1

-

-

0

-

-

0

-

-

0

-

-


1

0

Secara Teori

1

Sulit

3

Mudah

5

0

1

9


0

Tidak diketahui

1

Tersembunyi

4

Diketahui oleh Publik (diluar

0

1

Mudah

Cukup Jelas

1

9

Ratarata

-

3


1

0

Sulit



P1xN

Ada log dan review



N

P1

7


6

7

1

0

0

1

1

1

0

0

0

-



85


No




Tingkat Kerawanan


N

P1

P1xN

Ratarata

P2

P2xN

Ratarata

P3

P3xN

0

-

-

0

-

-

0

-

-

8

-

-

0

-

-

Ratarata

perusahaan)

Deteksi Penyusup



Ada log dan review

8





0

0

1

0

3

Ada Log saja

8

Tidak ada Log

9


0

Sulit

3

Mudah

7


9

0

1

1

8

0

0

5

0

4.5

0

1

0

1

3

0

0

0

0

0

0

0

1

3

1

0

1


0

0

0

Secara Teori

1

0

0

0

Sulit

3

0

3

0

Mudah

5

5

0

0


9

0

0

0


0

0

0

Tidak diketahui

2.5

1

1

1

1

0

0

0

0

1



86


No



Tingkat Kerawanan

Deteksi Penyusup

Perlindunga n yang tidak cukup pada layer transport


P1xN

Ratarata

P2

P2xN

P3

P3xN

0

0

0

0

7

0

0

0


0

0

0

0


1

0

0

0

Ada log dan review

3

0

0

4


6

Ada Log saja

8

Tidak ada Log

9


1

1

1

Ratarata

4

Tersembunyi

Sulit



N

P1

9


4

1

8

0

0

0

1

8

8

0

0

2.5

0

0

2

-

-

1

3

0

0

1

3

1

-

3

-

-

-

Mudah

7

0

0

-


9

0

0

-

-

0

-

-

0

-

-

3

-

-

0

-

-


Secara Teori

Ratarata

0

0

1

Sulit

3

Mudah

5

0

0

1

1

5



87


No



Tingkat Kerawanan



Tidak diketahui

Deteksi Penyusup


P2xN

0

1

1

1

Ratarata

P3

P3xN

0

-

-

0

-

-

1

-

-

-

-

4

0

0


6

0

0

-

7

0

0


0

0

0

-

-

1

-

-

0

-

-

-

1

1

3

1

1

0

-

Ada Log saja

8

0

0

Tidak ada Log

9

0

0

-

-

0

-

-


0

0

6.75

3.75

1

Mudah

7


9

0

0

0

3


Ratarata

-

-

Sulit

Kemudahan

P2

0

0

1

Ratarata

Disembunyikan

Ada log dan review


9

P1xN

-


10


N

P1



3

-

7

0

-

-

0

0

-

-

0

-

-

0

1

-

-

1

0



88


No



Tingkat Kerawanan


1

0

Sulit

3

0

5

1

Ratarata

P2

P2xN

1

5

Ratarata

P3

P3xN

0

-

-

3

-

-

0

-

-

-


9

0

0

-


0

0

0

-

-

Tidak diketahui

1

0

1

-

-

0

-

-

0

-

-

Disembunyikan


Deteksi Penyusup

P1xN

Secara Teori

Mudah


N

P1

untuk dieksploitasi


4

6

1

0

1

6

7

0

0

-


0

0

0

-


1

0

0

-

-

Ada log dan review

3

0

0

-

-

8

-

-

0

-

-

Ada Log saja

Tidak ada Log

Ratarata

8

9

0

1

1

9

-



89

Tabel Lampiran 1. 8 Self Assessment Identifikasi Dampak Teknis Faktor Kerawanan Keamanan Aplikasi Sumber : (OWASP 2013) telah diolah kembali

No

1


Injeksi SQL


Faktor Inheren Dampak Teknis

Tingkat Dampak

N

P1

Pelanggaran Akan Kerahasiaan

Pelanggaran akan Integritas data

Pelanggaran akan Availabilitas

P1xN

Ratarata

P2

7.5

P2xN

0


Ratarata

P3

7.5

1

P3xN

0

Tidak diaplikasikan

0

0

Minimal data tidak sensitif terungkap

2

0

0

0

Ekstensif data tidak sensitif terungkap

6

0

0

0

Ekstensif data kritikal terungkap

7

7

0

Seluruh data terungkap

9

0

0

0


0

0

0

Minimal data sedikit rusak

1

0

0

0

Minimal data rusak serius

3

0

0

0

Ekstensif data yang sedikit rusak

5

0

0

0

Ekstensif data yang rusak serius

7

0

0

0

Seluruh data rusak total

9

9

0


0

0

0

Minimal layanan sekunder terganggu

1

0

0

0

Minimal layanan primer terganggu

5

0

0

0

Ekstensif layanan primer terganggu

7

7

0

Seluruh layanan terhenti

9

0

0

1

1

1

7

9

7

0

1

1

1

1

1

Ratarata

1.75

0

0



90


No




N

P1

Pelanggaran akan akuntabilitas

2

Tingkat Dampak




P1xN

Ratarata


P2

P2xN

Ratarata


P3

P3xN

Tidak bisa diaplikasikan serangan dapat secara penuh di runut pada individu serangan mungkin dapat dirunut pada individu Serangan sepenuhnya tak bisa di runut (anonymous)

0

0

0

0

1

0

0

0

9

0

Tidak diaplikasikan

0

0


2

0


6


7


7

1

1

7

7

1

0

3.75

7

0

-

-

0

-

-

6

-

-

0

0

-

-

9

0

0

-

-


0

0

0

-

-


1

1

-

-


3

0

0

-

-


5

0

0

-

-


7

0

0

-

-


9

0

0

-

-


0

0

0

-

-


1

1

-

-


5

0

-

-

1

1

1

6

1

1

0

0

1

1

1

Ratarata

2.25



91


No


Dampak Teknis

Otentikasi dan Pengelolaa n Sesi yang buruk

Tingkat Dampak

N

P1


3


Faktor Inheren



Pelanggaran

P1xN

Ratarata

P2

P2xN

Ratarata


P3

P3xN


7

0

0

-

-


9

0

0

-

-


0

0

0

-

-

1

0

1

-

-

0

-

-

0

-

-

-

-

2

-

-

7

1

9

1

7

0

5.5

0

2.75

Tidak diaplikasikan

0

0


2

0


6

0

0

-

-


7

7

0

-

-


9

0

0

-

-


0

0

0

-

-


1

0

0

-

-


3

3

-

-


5

0

0

-

-


7

0

0

-

-


9

0

0

-

-


0

0

0

-

-

1

1

3

1

1

Ratarata



92


No


Dampak Teknis



Tingkat Dampak

N

P1

akan Availabilitas

4


Faktor Inheren



P1xN

Ratarata

P2

P2xN

Ratarata


P3

P3xN

0

-

-

5

-

-

0

0

-

-

9

0

0

-

-

0

0

0

-

-

1

0

1

-

-

0

-

-

0

-

-

1

0


1


5


7



7

0

1

1

9

1

5

1

7

0

4

0

4

Tidak diaplikasikan

0

0


2

0

0

0


6

0

0

0


7

7

0


9

0

0

0


0

0

0


1


3



1

7

1

0

0

0

0

5

0

0

0

7

0

0

0

1

1.75

0

1

1

1

1

Ratarata



93


No





N

P1


5

Tingkat Dampak



P1xN

Ratarata


P2

P2xN


9

0

0


0

0

0


1


5


P3

P3xN

1

0

0

0

0

0

7

0

0

0


9

0

0

0


0

0

0

0

1

0

0

0

7

1

9

Tidak diaplikasikan

0


2


6


1

1

7

0

7

1

0

0

4.25

0

0

4.25

1

0

0

0

0

0

7

0

0

0


9

0

0

0


0

0

0


1

0

0

0


3

3

0

1

2

3

1

7

2

1

1

Ratarata

0

1

1

1

Ratarata


1

1.75

0



94


No


Dampak Teknis


Kesalahan Konfiguras i Keamanan

Tingkat Dampak

N

P1


6


Faktor Inheren


Pelanggaran

P1xN

Ratarata

P2

P2xN

Ratarata


P3

P3xN


5

0

0

0


7

0

0

0


9

0

0

0


0

0

0


1

0

0

0


5

5

0


7

0

0

0


9

0

0

0


0

0

0

0

1

0

0

0

7

1

1

9

1

5

1

7

1

7

1

0

0

7

0

0

7

0

3.75

0

Tidak diaplikasikan

0

0


2

0

0


6

0

0

0


7

7

0


9

0

0

0


0

0

0

1

7

1

Ratarata

1

1

2.25

2

0



95


No


Dampak Teknis



Penyimpan an Kriptografi yang tidak aman

Tingkat Dampak

N

P1

akan Integritas data

7


Faktor Inheren


P1xN

Ratarata

Ratarata


P2

P2xN

1

1

0

P3

P3xN


1

0


3

0

0

0


5

0

0

0


7

7

0

0


9

0

0

0


0

0


1

0

0

0


5

0

0

0


7

7

0

0


9

0

0

0


0

0

0

0

1

0

0

0

7

1

1

1

9

1

1

7

1

7

1

0

0

5.5

0

0

-

-

0

0

-

-

7

0

-

-

0


2

0


6


7

0

7

-

0

1

0

-

Tidak diaplikasikan

1

0

Ratarata

1.75



96


No


Dampak Teknis



Kegagalan membatasi

Tingkat Dampak

N

P1


8


Faktor Inheren

Pelanggaran Akan

P1xN

Ratarata

P2

P2xN

Ratarata


P3

P3xN

0

-

-

0

-

-

0

0

-

-

3

0

-

-

5

0

0

-

-


7

0

0

-

-


9

0

0

-

-


0

0

0

-

-


1

0

0

-

-


5

5

0

-

-


7

0

0

-

-


9

0

0

-

-


0

0

0

-

-

1

0

0

-

-

7

-

-

0

-

-

1

0


9

0


0

0


1


3


7

9

1

1

1

1

1

1

7

0

Tidak diaplikasikan

0

0


2

0

7

0

0

6.5

Ratarata

1.75



97


No


akses url


Tingkat Dampak

N

P1

Kerahasiaan




P1xN

Ratarata


P2

P2xN

Ratarata


P3

P3xN

0

0

7

0

0

0

0

0

0

0


1

0

0

0


3

0

0

0


5

0

0

0


7

7

0


9

0

0

0


0

0

0


1

0

0

0


5

5

0


7

0

0

0


9

0

0

0


0

0

0

0

1

0

0

0

7

0


6


7


9


9

0

1

1

1

1

7

1

7

5

9

1

1

1

7

0

1

1

1

Ratarata

0

0

7



98


No

9


Perlindung an yang tidak cukup pada layer transport



Tingkat Dampak

N

P1





P1xN

Ratarata

P2

P2xN

7.5

1

0


Ratarata

P3

0.25

-

-

P3xN

Tidak diaplikasikan

0

0


2

0

0

-

-


6

0

0

-

-


7

0

0

-

-


9

9

0

-

-


0

0

0

-

-


1

0

0

-

-


3

0

0

-

-


5

0

0

-

-


7

7

0

-

-


9

0

0

-

-


0

0

0

-

-


1

0

0

-

-


5

0

0

-

-


7

7

0

-

-


9

0

0

-

-

Tidak bisa diaplikasikan serangan dapat secara penuh di runut pada individu

0

0

0

-

-

1

0

1

-

-

serangan mungkin dapat dirunut pada

7

0

-

-

1

1

1

1

7

1

1

1

Ratarata



99


No



Tingkat Dampak

N

P1

P1xN

Ratarata


P2

P2xN

Ratarata


P3

P3xN

Ratarata

individu

Serangan sepenuhnya tak bisa di runut (anonymous)

10





Pelanggaran

9

Tidak diaplikasikan

0


2


0

0

0

3.25

1

0

1.75

-

-

-

-

2

0

-

-

6

0

0

-

-


7

0

0

-

-


9

0

0

-

-


0

0

0

-

-


1

0

0

-

-


3

3

0

-

-


5

0

0

-

-


7

0

0

-

-


9

0

0

-

-


0

0

0

-

-


1

1

0

-

-


5

0

0

-

-


7

0

0

-

-


9

0

0

-

-


0

0

0

-

-

1

1

1

1

1



100


No




Tingkat Dampak

N

P1

akan akuntabilitas

serangan dapat secara penuh di runut pada individu serangan mungkin dapat dirunut pada individu Serangan sepenuhnya tak bisa di runut (anonymous)

P1xN

1

7

Ratarata

P2

0

1

1

7

9

0

P2xN

Ratarata


P3

P3xN

0

-

-

7

-

-

0

-

-

Ratarata

Tabel Lampiran 1. 9 Self Assessment Identifikasi Dampak Bisnis Faktor Kerawanan Keamanan Aplikasi Sumber : (OWASP 2013) telah diolah kembali

No

1


Injeksi SQL


Faktor Inheren Dampak Bisnis

Tingkat Dampak

N

P1

Kerugian Financial

P1xN

Lebih kecil dari biaya untuk memperbaiki faktor kerawanannya

1

0

Berdampak sedikit pada keuntungan tahunan

3

0

Ratarata

7

P2

P2xN

0

0

Ratarata


P3

7

P3xN

0

1

Ratarata

2.75

3



101


No



Kerusakan Reputasi

Pelanggaran akan Kepatuhan (compliance)

Pelanggaran Privasi

2


Kerugian Financial

Kerusakan

Tingkat Dampak

N

P1

P1xN

1

7

Ratarata


Ratarata


P2

P2xN

1

7

0

0

P3

P3xN

Berdampak signifikan pada keuntungan tahunan, kerusakan data billing dapat menyebabkan

7

Menyebabkan kebangkrutan

9

0

0

Berdampak minimal

1

0

0

Kehilangan pelanggan besar

4

0

0

0

Kehilangan Kepercayaan

5

0

0

0

Kerusakan Brand Perusahaan

9

9

0

Pelanggaran Minor

2

0

0

Pelanggaran Yang Sangat Jelas

5

0

0

0

Berprofil tinggi

7

7

0

Satu individu

3

0

0

ratusan orang

5

ribuang orang

7

0

0

0

jutaan orang Lebih kecil dari biaya untuk memperbaiki faktor kerawanannya

9

0

0

0

1

0


3

0

Berdampak signifikan pada keuntungan tahunan

7


Berdampak minimal

1

1

9

1

7

1

0

1

5

1

1

1

5

1.75

2

5

-

0

-

-

7

0

-

-

9

0

0

-

-

1

0

1

-

-

1

1

1

1

-

1

5.25

1

Ratarata



102


No



Reputasi


Pelanggaran Privasi

3


Kerugian Financial

Kerusakan Reputasi

Pelanggaran

Tingkat Dampak

N

P1

P1xN

1

4

Ratarata


P2

P2xN

Ratarata


P3

P3xN

0

-

-


4


5

0

0

-

-


9

0

0

-

-

Pelanggaran Minor

2

0

2

-

-


5

5

0

-

-

Berprofil tinggi

7

0

0

-

-

Satu individu

3

0

3

-

-

ratusan orang

5

5

0

-

-

ribuang orang

7

0

0

-

-


9

0

0

-

-

1

0

-

-


3

0

0

-

-


7

7

0

-

-


9

0

0

-

-

Berdampak minimal

1

0

1

-

-


4

4

0

-

-


5

0

0

-

-


9

0

0

-

-

Pelanggaran Minor

2

0

2

-

-

1

1

1

1

1

1

5.25

1

1

1

1

1.75

Ratarata



103


No



akan Kepatuhan (compliance) Pelanggaran Privasi

4


Kerugian Financial

Kerusakan Reputasi


Pelanggaran Privasi

Tingkat Dampak

N

P1

P1xN

1

5

Ratarata


P2

P2xN

Ratarata


P3

P3xN

0

-

-

0

-

-

3

-

-

5

0

-

-


5

Berprofil tinggi

7

0

Satu individu

3

0

ratusan orang

5

ribuang orang

7

0

0

-

-


9

0

0

-

-

1

0

1

1


3

0


7


1

1

5.25

0

3

0

7

0

0

9

0

0

0

Berdampak minimal

1

0

0


4


5


1

0

0

0

9

0

0

0

Pelanggaran Minor

2

0

0


5

Berprofil tinggi

7

0

Satu individu

3

0

ratusan orang

5

1

5

5

1

1

1

2

5

0

0

0

3

0

1

1.75

1

0

1

1

1

4

1

4

1

3.75

Ratarata

3

0



104


No

5



Dampak Bisnis

Kerugian Financial


Pelanggaran Privasi

Kesalahan Konfigurasi

Tingkat Dampak

N

P1

Kerusakan Reputasi

6


Faktor Inheren

Kerugian Financial

P1xN

Ratarata

P2

P2xN

Ratarata


P3

P3xN

ribuang orang

7

0

0

0


9

0

0

0

1

0


3


7


9

Berdampak minimal

1


4

0

0

0


5

0

0

0


9

0

0

0

Pelanggaran Minor

2

0

0


5

Berprofil tinggi

7

Satu individu

3

ratusan orang

5

0

0

0

ribuang orang

7

0

0

0


9

0

0

0

1

0

1

1

1

3

3

0

1

1

1

3

0

0

0

0

0

0

0

1

1

5

1

0

1

3

3

1

4.75

1

1

1

2

0

0

0

0

1

4.75

1

1.75

1

5

3

Ratarata

3

1

1.75



105


No


Dampak Bisnis

Kerusakan Reputasi


Pelanggaran Privasi


Tingkat Dampak

N

P1

Keamanan

7


Faktor Inheren

Kerugian Financial

Kerusakan


3


7


9

Berdampak minimal

1


4


5


P1xN

Ratarata

P2

0

1

1

P2xN

Ratarata


P3

P3xN

0

0

7

0

0

0

0

0

0

7

1

1

1

4

0

0

0

0

9

0

0

0

Pelanggaran Minor

2

0

0


5

Berprofil tinggi

7

Satu individu

3

ratusan orang

5

0

0

0

ribuang orang

7

0

0

0


9

0

0

0

1

0


3


7


9

Berdampak minimal

1

1

4

1

5

1

0

1

1

1

3

1

4

1

2

5

0

0

0

3

-

3

-

-

0

0

-

-

0

0

-

-

1

-

-

1

1

1

2.25

3

-

3

0

1

Ratarata



106


No




Pelanggaran Privasi


N

P1

Reputasi

8

Tingkat Dampak

Kerugian Financial

Kerusakan Reputasi

Pelanggaran

P1xN

Ratarata


P2

P2xN

Ratarata


P3

P3xN


4

0

0

-

-


5

0

0

-

-


9

0

0

-

-

Pelanggaran Minor

2

0

2

-

-


5

0

0

-

-

Berprofil tinggi

7

7

0

-

-

Satu individu

3

3

-

-

ratusan orang

5

5

0

-

-

ribuang orang

7

0

0

-

-


9

0

0

-

-

1

0

1

1


3

0


7


9

Berdampak minimal

1


4


5


Pelanggaran Minor

1

1

0

1

1

1

1

5.25

0

4.5

0

0

7

0

0

0

0

0

0

7

4

1

1

1

0

0

0

0

9

0

0

0

2

0

2

1

2.25

1

4

1

Ratarata

2



107


No


Dampak Bisnis

akan Kepatuhan (compliance) Pelanggaran Privasi

9



Faktor Inheren

Kerugian Financial

Kerusakan Reputasi


Pelanggaran Privasi

Tingkat Dampak

N

Ratarata

Ratarata


P1

P1xN

1

5

0

0

P2

P2xN

P3

P3xN


5

Berprofil tinggi

7

0

0

0

Satu individu

3

0

0

0

ratusan orang

5

ribuang orang

7

0

0

0


9

0

0

0

1

0


3

0


7


9

Berdampak minimal

1

5

1

0

-

-

7

-

-

0

0

-

-

1

0

0

-

-


4

0

0

-

-


5

5

-

-


9

0

0

-

-

Pelanggaran Minor

2

0

2

-

-


5

0

0

-

-

Berprofil tinggi

7

7

0

-

-

Satu individu

3

0

0

-

-

ratusan orang

5

5

-

-

1

1

1

5

5

1

1

1

1

4.75

5

-

7

0

1

-

1

6

5

Ratarata

0



108


No

10





Tingkat Dampak

N

P1

Kerugian Financial

Kerusakan Reputasi


Pelanggaran Privasi

P1xN

Ratarata

P2

P2xN

Ratarata


P3

P3xN

ribuang orang

7

0

0

-

-


9

0

0

-

-

-

-


3

0

0

-

-


7

0

0

-

-


9

0

0

-

-

Berdampak minimal

1

1

-

-


4

0

0

-

-


5

0

0

-

-


9

0

0

-

-

Pelanggaran Minor

2

0

2

-

-


5

5

0

-

-

Berprofil tinggi

7

0

0

-

-

Satu individu

3

0

3

-

-

ratusan orang

5

5

0

-

-

ribuang orang

7

0

0

-

-

jutaan orang

9

0

0

-

-

1

1

1

1

1

1

3

1

1

1

1

1

1

1

Ratarata



109

Tabel Lampiran 1. 10 Identifikasi Tingkat Risiko Hasil Self Assessment NIST SP 800-26 No

Ancaman dan Kerawanan

Risiko Inheren

Tingkat Kemungkinan Ket.

N

Tingkat dampak Ket.

N

Tingkat Risiko Ket.

Risiko Residual (dengan kontrol yang ada saat ini) Tingkat Tingkat Tingkat Kemungkinan dampak Risiko Ket.

N

Ket.

N

Ket.

Tingkat Risiko Harapan (dengan kontrol baru) Tingkat Tingkat Tingkat Kemungkina dampak Risiko n Ket.

N

Ket.

N

Ket.

1

Kebutuhan keamanan belum diidentifikasikan saat disain sistem

Kritis

5

Tinggi

4

Kritis

Tinggi

4

Tinggi

4

Kritis

Jarang

1

Rendah

2

Rendah

2

Kontrol keamanan dengan evaluasi dan prosedur uji yang terkait dengannya belum dibuat

Kritis

5

Tinggi

4

Kritis

Tinggi

4

Tinggi

4

Kritis

Jarang

1

Rendah

2

Rendah

3

Kebutuhan keamanan dan prosedur evaluasi / uji keamanan belum ada dalam dokumen RFP

Kritis

5

Tinggi

4

Kritis

Kritis

5

Tinggi

4

Kritis

Jarang

1

Rendah

2

Rendah

4

Ujicoba khusus terhadap standar kontrol keamanan belum dilakukan dan didokumentasikan pada fase implementasi

Kritis

5

Tinggi

4

Kritis

Tinggi

4

Tinggi

4

Kritis

Jarang

1

Rendah

2

Rendah



110

Tabel Lampiran 1.10 (Sambungan) No

Ancaman dan Kerawanan

Risiko Inheren

Tingkat Kemungkinan Ket.

5

Kewajiban akan penyelenggaraan pelatihan atau sosialisasi untuk penyegaran akan kebijakan standar keamanan pengembangan aplikasi belum dibakukan

Kritis

Tingkat dampak

N

Ket.

N

5

Sedang

3

Tingkat Risiko Ket.

Tinggi

Risiko Residual (dengan kontrol yang ada saat ini) Tingkat Tingkat Tingkat Kemungkinan dampak Risiko Ket.

Tinggi

N

Ket.

4

Sedang

N

3

Ket.

Tinggi

Tingkat Risiko Harapan (dengan kontrol baru) Tingkat Tingkat Tingkat Kemungkina dampak Risiko n Ket.

Jarang

N

Ket.

1

Rendah

N

Ket.

2

Rendah



111

Tabel Lampiran 1. 11 Tingkat Dampak Risiko Lintasarta

Penjelasan Dampak Risiko

Luar Biasa

Tinggi Sedang

Rendah

Keterangan Berdampak serius terhadap kelangsungan perusahaan Dapat menyebabkan kerugian/kerusakan bernilai tinggi tanpa mempengaruhi kelangsungan perusahaan Dapat menyebabkan kerugian/kerusakan Dapat menyebabkan kerugian bernilai rendah dan dapat diterima oleh perusahaan Dampak yang timbul dapat diabaikan

NIlai 5

Tingkat Dampak

Kritis

4

3 2

Tinggi Sedang

Rendah

1 dapat diabaikan

Dapat Diabaikan

Tabel Lampiran 1. 12 Tingkat Kemungkinan Risiko Lintasarta

Penjelasan Kemungkinan Hampir Pasti Sering Kadang-Kadang Mungkin Jarang

Definisi

Setiap bulan Setiap 3 bulan Setiap tahun Antara 1-3 tahun > 3 tahun

Nilai 5 4 3 2 1

Tingkat Kemungkinan Kritis Tinggi Sedang Rendah dapat diabaikan



112

Tabel Lampiran 1. 13 Tingkat Kategori Risiko Lintasarta

Dampak Risiko

Jarang

Tingkat Kemungkinan KadangMungkin Kadang Sering

Hampir Pasti

Luar Biasa

Tinggi

Tinggi

Kritis

Kritis

Kritis

Tinggi Sedang

Sedang Sedang

Tinggi Sedang

Tinggi Tinggi

Kritis Tinggi

Kritis Tinggi

Rendah Dapat Diabaikan

Rendah

Rendah

Sedang

Sedang

Tinggi

Rendah

Rendah

Rendah

Sedang

Sedang

Sumber : (PT. Aplikanusa Lintasarta, 2012)



LAMPIRAN 2 : Data Self Assessment NIST SP 800-26 Lintasarta

113



114

Kuisioner Sistem

Nama Sistem, Judul,

Pengembangan Aplikasi Web PT. Aplikanusa Lintasarta

dan identifikasi unik

Nama Penilai

Ahmad Fikri ( Assisstant Manager IT Development)

Tanggal Evaluasi

2 April 2013

Tanda Tangan



115

Karakteristik Sistem

Criticality Of System

Category Of Sensitivity (High, Medium, Low)

Confidentiality

High

Integrity

High

Availability

High

1. Siklus Hidup Seperti aspek-aspek lain dalam sistem TI, keamanan sebaiknya dikelola jika direncanakan sepanjang siklus hidup sistem TI. Ada banyak model untuk siklus hidup sistem TI tetapi kebanyakan mengandung lima tahap dasar : inisiasi, pembangunan/perolehan, implementasi, operasi, dan pembuangan. Pertanyaan berikut diatur menurut dua elemen penting. Tingkat untuk masing-masing elemen penting yang harus ditentukan berdasarkan jawaban atas pertanyaan bawahan.



116

Tujuan Kontrol Spesifik dan Teknik

Kebjaksanaan

Prosedur

Diimplementasikan

Siklus Hidup

Elemen Kritis : Apakah pengembangan metodologi siklus hidup sistem telah

Ya

Ya

Ya

dikembangkan ?


Kebjaksanaan

Prosedur

Diimplementasikan

Fase Inisiasi

3.1.1 Apakah sensitivitas sistem ditentukan ?

Ya

Tidak

Tidak

Ya

Ya

Ya

Tidak

Tidak

Tidak

3.1.2 Apakah dokumen kasus bisnis mendokumentasikan sumber daya yang diperlukan untuk mengamankan sistem yang memadai ?

3.1.3 Apakah dewan peninjau investasi memastikan permintaan investasi meliputi sumber daya keamanan yang dibutuhkan?



117


3.1.4 Apakah otorisasi untuk modifikasi perangkat lunak

Kebjaksanaan

Prosedur

Diimplementasikan

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Tidak

Tidak

Ya

Tidak

Tidak

Ya

Ya

Ya

Ya

Ya

Ya

didokumentasi dan dipelihara?

3.1.5 Apakah permintaan anggaran meliputi sumber daya keamanan yang diperlukan untuk sistem?

Fase Pembangunan/Akuisisi

3.1.6 Selama desain sistem,apakah persyaratan keamanan sudah diidentifikasi?

3.1.7 Apakah suatu peniaian resiko awal dilakukan untuk menentukan persyaratan keamanan?

3.1.8 Apakah ada perjanjian tertulis dengan petugas program pada kontrol keamanan yang dipekerjakan dan resikonya?

3.1.9 Apakah kontrol keamanan konsisten dengan bagian integral dari arsitektur TI



118


3.1.10 Apakah kontrol keamanan yang sesuai dengan evaluasi

Kebjaksanaan

Prosedur

Diimplementasikan

Ya

Tidak

Tidak

Tidak

Tidak

Tidak

Ya

Ya

Ya

Ya

ya

Ya

terkait dan prosedur pengujian dibuat sebelum aksi pengadaan?

3.1.11 Apakah dokumen permohonan (permintaan untuk proposal) meliputi persyaratan keamanan dan prosedur evaluasi/uji keamanan?

3.1.12 Apakah persyaratan dalam dokumen mengizinkan pembauran kontrol keamanan ketika ancaman baru/kerentanan teridentifikasi dan teknologi baru diimplementasikan

Tahap Implementasi

3.2 Elemen kritis : Apakah perubahan dikendalikan pengujan untuk persetujuan akhir?



119


32.1 Apakah tinjauan desain dan tes sistem yang dijalankan

Kebjaksanaan

Prosedur

Diimplementasikan

Ya

Ya

Ya

3.2.2 Apakah hasil tes didokumentasikan?

Ya

Ya

Ya

3.2.3 Apakah uji sertifikasi keamanan kontrol dilakukan dan

Ya

Tidak

Tidak

Ya

Tidak

Tidak

Ya

Tidak

Tidak

Ya

Ya

Ya

sebelum menempatkan sistem produksi?

didokumentasikan?

3.2.4 Jika kontrol kemanan ditambahkan sejak pembangunan, Apakah dokumentasi sistem dimodifikasi untuk memasukkan kontrol itu ?

3.2.5 Jika kontrol kemanan ditambahkan sejak pembangunan apakah kontrol tersebut telah diuji dan disertifikasi ulang ?

3.2.6 Apakah aplikasi mengalami evaluasi teknis untuk memastikan bahwa itu memenuhi hukum yang berlaku federal,peraturan,kebijakan,pedoman,dan standar?



120


3.2.7 Apakah sistem telah menulis otorisasi untuk beroperasi baik

Kebjaksanaan

Ya

Prosedur

Ya

Diimplementasikan

Ya

secara sementara dengan tindakan korektif yang direncanakan atau otorisasi penuh?

2. Dokumentasi Dokumentasi berisi deskripsi perangkat keras, perangkat lunak, kebijakan, standar, prosedur dan keputusan terkait sistem dan merumuskan kontrol keamanan sistem. Saat menjawab apakah ada prosedur untuk setiap tujuan kontrol, pertanyaan harus diungkapkan “apakah ada prosedur untuk memastikan dokumentasi diperoleh dan dipelihara?”. Pertanyaan berikut diatur menurut dua elemen penting. Tingkat untuk masing-masing elemen penting yang harus ditentukan berdasarkan jawaban atas pertanyaan-pertanyaan di bawah ini.

Tujuan Pengendalian Spesifik dan Teknik

Kebijakan

Prosedur

Penerapan

Dokumentasi

12.1 Elemen Kritis: Apakah ada dokumenasi yang memadai yang menjelaskan bagaimana Universitas Indonesia


121


Kebijakan

Prosedur

Penerapan

perangkat lunak/perangkat keras akan digunakan?

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

12.1.1 Apakah vendor menyediakan dokumen perangkat lunak yang dibeli?

12.1.2 Apakah vendor menyediakan dokumen perangkat keras yang dibeli?

12.1.3 Apakah ada dokumentasi untuk aplikasi yang dibuat sendiri ?

12.1.4 Apakah ada diagram jaringan dan dokumentasi di set up router dan switch?

12.1.5 Apakah ada prosedur pengujian perangkat lunak dan perangkat keras dan hasilnya ?

12.1.6 Apakah ada prosedur operasi standar untuk semua area topik yang tercakup dalam dokumen ini?

12.1.7 Apakah ada buku petunjuk?



122


Kebijakan

Prosedur

Penerapan

12.1.8 Apakah ada prosedur darurat?

Ya

Ya

Ya

12.1.9 Apakah ada prosedur cadangan?

Ya

Ya

Ya

Ya

Ya

Ya

12.2.1 Apakah ada rencana keamanan sistem?

Ya

Ya

Ya

12.2.2 Apakah ada sebuah perencanaan darurat (contigency plan) ?

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

12.2 Elemen Penting: Apakah ada keamanan formal dan prosedur operasional didokumentasikan?

12.2.3 Apakah ada kesepakatan tentang bagaimana data dibagi antara sistem yang saling ditulis?

12.2.4 Apakah ada laporan penilaian risiko ?

12.2.5 Apakah ada sertifikasi dan dokumen akreditasi dan laporan otorisasi sistem untuk memproses?



123

3. Kesadaran Keamanan, dan Pelatihan Orang merupakan faktor penting dalam memastikan keamanan sistem omputer dan sumber daya informasi yang berharga. Kesadaran keamanan, pelatihan, dan pendidikan meningkatkan keamanan dengan meningkatkan kesadaran akan kebutuhan untuk melindungi sumber daya sistem. Selain itu, pelatihan mengembangkan keterampilan dan pengetahuan sehingga pengguna komputer dapat melakukan pekerjaan mereka lebih aman dan membangun pengetahuan yang mendalam. Pertanyaan-pertanyaan berikut diatur menurut dua tingkat elemen. Penting untuk masing-masing elemen harus ditentukan berdasarkan jawaban atas pertanyaan-pertanyaan di bawah ini. Tujuan Kontrol Spesifik dan Teknik

Kebjaksanaan

Prosedur

Diimplementasikan

Ya

Ya

Ya

13.1.1 Apakah karyawan menerima salinan aturan perilaku?

Ya

Ya

Ya

13.1.2 Apakah pelatihan karyawan dan pengembangan professional

Ya

Ya

Ya

Kesadaran Keamanan, Pelatihan dan pendidikan

13.1 Elemen Kritis : Apakah karyawan telah menerima pelatihan yang memadai untuk memenuhi tanggung jawab keamanan mereka?

didokumentasikan dan dipantau?



124

13.1.3 Apakah ada pelatihan penyegaran wajib tahunan?

13.1.4 Apakah metode yang digunakan untuk membuat karyawan

Tidak

Tidak

Tidak

Ya

Ya

Ya

Ya

Ya

Ya

menyadari keamanan, yaitu poster,buku kecil.

13.1.5 Apakah karyawan menerima salinan atau memiliki akses mudah untuk prosedur dan kebijakan keamanan oragnisasi ?

Pengawasan Teknis Kontrol teknis fokus pada kontrol keamanan bahwa sistem komputer dijalankan. Kontrol dapat membeikan perlindungan otomatis untuk akses yang tidak sah atau penyalahgunaan dan memfasilitasi deteksi pelanggaran keamanan dan persyaratan keamanan dan dukungan untuk aplikasi data. 15. Identifikasi dan Otentifikasi Identifikasi dan otentikasi adalah langkah teknis yang mencegah orang yang tidak berhak (atau proses yang tidak sah) dari memasuki sistem TI. Akses kontrol biasanya memutuhkan bahwa sistem dapat mengidentifikasi dan membedakan antara pemakai. Pertanyaan di bawah ini diatur menurut dua elemen untuk setiap tingkat elemen harus berdasarkan jawaban atas pertanyaan-pertanyaan berikut :



125

Tujuan Pengendalian Spesifik dan Teknis

Kebijakan

Prosedur

Implementasi

Ya

Ya

Ya

Ya

Ya

Identifikasi dan otentikasi

15.1 Elemen Kritis : Apakah pengguna individual dikonfirmasi melalui password,token atau perangkat lain?

15.1.1 Apakah daftar saat ini dipertahankan dan disetujui pengguna resmi

Ya

dan akses mereka?

15.1.3 Apakah skrip akses dengan password tertanam dilarang?

Ya

Ya

Ya

15.1.4 Apakah akses darurat dan sementara berwenang?

Ya

Ya

Ya

15.1.5 Apakah file pribadi sesuai dengan account pengguna untuk

Ya

Ya

Ya

Ya

Ya

Ya

memastikan

bahwa

individu

dihentikan

atau

dialihkan

tidak

mempertahankan akses sistem?

15.1.6 Apakah password berubah setidaknya setiap Sembilan puluh hari atau lebih awal jika diperlukan?



126

15.1.7 Apakah password yang unik dan sulit ditebak (contoh : password

Ya

Ya

Ya

Ya

Ya

Ya

15.1.9 Apakah password tidak ditampilkan ketika masuk sistem?

Ya

Ya

Ya

15.1.10 Apakah ada prosedur untuk menangani password yang hilang?

Ya

Ya

Ya

15.1.11 Apakah password telah didistribusikan dengan aman dan

Ya

Ya

Ya

Ya

Ya

Ya

15.1.13 Apakah password yang diberikan segera diganti?

Ya

Ya

Ya

15.1.14 Apakah ada batasan untuk jumlah usaha akses tidak sah yang

Ya

Ya

Ya

memerlukan alfanumerik,huruf besar/kecil dan karakter khusus) ?

15.1.8 Apakah identiti pengguna aktif dimatikan setekah waktu yang ditentukan?

pengguna informasi tidak mengungkapkan password mereka ke siapa pun (rekayasa sosial)?

15.1.12

Apakah

password

dikirim

dan

disimpan

meggunakan

protokol/algoritma yang aman?

mungkin terjadi ?



127

15.2 Elemen Kritis : Apakah kontrol akses menegakkan pemisahan tugas?

15.2.1 Apakah sistem berkorelasi tindakan dengan pengguna?

Ya

Ya

Ya

15.2.2 Apakah pemilik otorisasi akses secara berkala mengevaluasi data

Ya

Ya

Ya

mereka tetap sesuai?

16. Kontrol Akses Logis Kontrol akses logis adalah mekanisme berbasis sistem yang digunakan untuk ditunjuk siapa atau apa yang memiliki akses ke sumber daya sistem tertentu dan jenis transaksi dan fungsinya yang permitted. Pertanyaan berikut diatur menurut tiga tingkat unsure. Penting untuk masing-masing unsure harus ditentukan berdasarkan jawaban atas pertanyaan di bawah ini. Tujuan Pengendalian Spesifik dan Teknis

Kebijakan

Prosedur

Implementasi

Kontrol Akses Logis



128

16.1 Elemen Kritis :

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Apakah kontrol akses logis membatasi pengguna untuk transaksi dan fungsi yang berwenang?

16.1.1Dapatkah kontrol keamanan mendeteksi upaya akses tidak sah?

16.1.2 Apakah ada perangkat lunak kontrol akses yang mencegah seseorang dari memiliki semua otoritas atau akses informasi yang diperlukan untuk memunginkan aktifitas penipuan tanpa kolusi?

16.1.3 Apakah akses ke perangkat lunak keamanan dibatasi untuk administrator keamanan?

16.1.4 Apakah workstation memutuskan hubungan atau screensaver mengunci sistem setelah setelah jangka waktu tertentu tidak aktif?

16.1.5 Apakah account pengguna non aktif dipantau



129

dan dihapus bila tidak diperlukan?

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

Ya

16.1.6 Apakah label keamanan internal (konvensi penamaan) digunakan untuk mengontrol akses ke jeis informasi tertentu atau file?

16.1.9

Apakah

akses

terbatas

pada

filre

pada

pandangan logis atau lapangan?



LAMPIRAN 3 : Data Transkrip Wawancara GM IT Lintasarta

130



131

Data Informasi Nara Sumber General Manager IT

Tujuan : -

Mengetahui Karakteristik Aplikasi berbasis WEB Lintasarta

-

Mengetahui proses pengembangan aplikasi berbasis WEB di Lintasarta

-

Mengetahui Kondisi Keamanan Aplikasi berbasis WEB Lintasarta

-

Mengetahui tujuan / harapan GM IT dalam pembuatan pedoman keamanan pengembangan aplikasi web Lintasarta

Daftar Pertanyaan. 1. Bagaimana kondisi terkini mengenai hubungana aplikasi berbasis WEB Lintasarta dengan operasional PT. Aplikanusa Lintasarta. Apakah system aplikasi yang dibuat IT sangat penting dalam mendukung bisnis perusahaan ? Jawab Ya, IT membuat aplikasi untuk mendukung bisnis perusahaan 2. Bagaimana proses pengembangan Aplikasi berbasis WEB di Lintasarta saat ini dan rencana ke depan, apakah membuat sendiri atau dengan membeli aplikasi paket. Jawab : Dari Kultur Lintasarta yang membutuhkan suatu solusi yang unik sesuai dengan kebutuhan bisnisnya maka IT Lintasarta masih memiliki strategi untuk mengembangkan sendiri aplikasi backoffice-nya. 3. Apakah di Lintasarta sudah ada prosedur baku untuk pengembangan aplikasi berbasis web ? Jawab : Untuk pengembangan apliasi secara umum sudah ada, namun spesifikasi lebih detail. 4. Apakah prosedur tersebut dijalankan dan dimonitor pelaksanaannya ? Jawab :



132

Ya, dimonitor dengan baik karena salah satu syarat ISO. Dan IT juga memiliki standar untuk IT Change Management. 5. Apakah prosedur pengembangan aplikasi WEB tersebut dan standar dokumen yang dikeluarkan sudah memperhatikan keamanan aplikasi berbasis WEB ? Jawab : Secara umum sudah, namun harus di review lebih.detil apakah betul sudah bisa memiliki standar keamanan yang baik. Infrastruktur IT Operation juga sudah menerapkan beberapa standar keamanan. 6. Apakah sudah ada pedoman mengenai keamanan apllikasi berbasis WEB yang digunakan dalam proses pengembangan aplikasi berbasis WEB di Lintasarta ? Jawab : Belum ada 7. Apakah

Lintasarta

membutuhkan

suatu

pedoman

keamanan

pengembangan aplikasi berbasis WEB ? Jawab : Ya, tentu 8. Pedoman seperti apakah yang diharapkan oleh IT Lintasarta ? Jawab : Pedoman yang dapat menjaga aplikasi tersebut tetap bisa memberikan SLA sesuai kebutuhan user. Serta dapat menjaga prinsi CIA (Confidentiality, Integrity, Accountability – Penulis). Dimana CIA dapat diterjemahkan dalam standar keamanan pengembangan tersebut. Comply dengan ISO 27001 serta pengembangan aplikasi. 9. Apakah pernah ada masalah pelanggaran yang memanfaatkan celah keamanan aplikasi berbasis WEB yang digunakan di Lintasarta sampai dengan saat ini. Jawab : Pernah



133

10. Apakah pelanggaran yang dilakukan memberikan dampak cukup serius. Jawab : Iya, orang yang tidak berhak menggunakan aplikasi tersebut

Nama Tanggal Tanda tangan

: : :

Yosi Widhayanti 5 April 2013



LAMPIRAN 4 : Draft Pedoman Keamanan Pengembangan Aplikasi Web

134



135

Pedoman Keamanan Pengembangan Aplikasi Web IT Ver. Draft

Jun 2013


136

KOLOM PENGESAHAN :

Disusun Oleh : NO.

NAMA

JABATAN

1.

Suwarno Pribadi

Senior Advisor

TANDA TANGAN

TANGGAL

TANDA TANGAN

TANGGAL

TANDA TANGAN

TANGGAL

Diperiksa Oleh :

NO.

NAMA

JABATAN

1.

Ahmad Fikri

IT Development Assistant Manager

2.

Azis Budi Prasetyo

IT Development & Business Process Manager

Disetujui Oleh :

NO.

NAMA

JABATAN

1.

Yosi Widhayanti

VAS Operations & IT General Manager

DISTRIBUSI KEPADA :

IT Development & Business Process Department IT Operations Department


137

KOLOM STEMPEL


138

Dokumen Detail

Versi Status Nama Dokumen File disimpan dalam bentuk Total Halaman Total Lampiran Digunakan di Unit kerja Dibuat Tanggal Release

Dokumen

: : : : : : : : :

Draft Draft Pedoman Keamanan Pengembangan Aplikasi Web Lintasarta Microsoft Word Format 16 Halaman 5 Lampiran IT Development & Business Process

Referensi Versi

Pemilik

OWASP Top Ten Risk

2010

OWASP

NIST SP 800 – 53 OWASP asvs Improving Web Application Security : Threat & Countermeasures

2012 2009

NIST OWASP

Tanggal Release

Versi

Juni 2003

Histori Perubahan Perubahan

Microsoft MSDN

Yang Merubah


139

DAFTAR ISI 1. PENGANTAR ................................................................................................ 140 1.1. 1.2. 1.3. 1.4. 1.5. 1.6.

Definisi.............................................................................................................. 140 Latar Belakang ............................................................................................... 141 Tujuan ............................................................................................................... 141 Pengguna Dokumen ...................................................................................... 141 Kebijakan Umum ........................................................................................... 141 Ruang Lingkup ............................................................................................... 142

2. PERAN DAN TANGGUNG JAWAB ...................................................................... 142 3. PEDOMAN KEAMANAN PROSES PENGEMBANGAN ............................... 144 3.1. 3.2. 3.3. 3.4. 3.5. 3.6.

Pembuatan Kerangka Acuan Kerja dan Perencanaan Proyek ........ 144 Fase Identifikasi Kebutuhan Bisnis dan Fungsional ........................... 145 Fase Disain Aplikasi ..................................................................................... 147 Fase Konstruksi Aplikasi ............................................................................. 149 Fase Ujicoba ................................................................................................... 150 Sosialisasi dan Pelatihan Keamanan Aplikasi...................................... 151

4. PEDOMAN KEAMANAN TEKNIS PENGEMBANGAN APLIKASI ..... 152 5. SANKSI .............................................................................................................. 155 6.DAFTAR LAMPIRAN ...................................................................................... 156


140

1. PENGANTAR Pedoman keamanan pengembangan aplikasi web disusun sebagai satu kesatuan yang selaras dengan kebijakan keamanan informasi perusahaan. 1.1. Definisi Keamanan informasi adalah bentuk pengamanan informasi perusahaan dari segala bentuk ancaman yang bertujuan meminimalkan resiko bisnis dan menjamin kelangsungan bisnis perusahaan. Keamanan informasi dibangun sejalan dengan bisnis perusahaan dengan menerapkan beberapa fungsi kontrol, diantaranya adalah kontrol terhadap kebijakan, prosedur, struktur organisasi, penggunaan aset hardware dan software (fasilitas Information Technology). Secara definisi, dalam konteks keamanan informasi, kebijakan (policy) adalah dokumen yang menyatakan kebutuhan atau aturan yang spesifik yang harus dilaksanakan. Dalam hal keamanan informasi, biasanya kebijakan berupa poin-poin spesifik yang melingkupi area tertentu. Sedangkan Standar adalah sekumpulan kebutuhan spesifik suatu sistem atau prosedur yang harus dipenuhi oleh semua orang seperti contohnya panjang minimal karakter password email. Pedoman (guidelines) adalah sekumpulan panduan spesifik atas suatu sistem atau prosedur berdasarkan best-practise yang sangat direkomendasikan untuk dilaksanakan. Sedangkan prosedur adalah instruksi langkah demi langkah agar para pekerja dapat melakukan pekerjaannya sesuai dengan kebijakan, standar dan pedoman. Secara hirarki hubungan antara kebijakan, standar, pedoman dan prosedur adalah sebagai berikut dimana kebijakan berada pada hirarki paling atas untuk dipatuhi dan menjadi dasar pembuatan dokumen di bawahnya.

Kebijakan

Standar

Pedoman

Prosedur

Gambar 1. Hirarki hubungan Kebijakan, standar, pedoman dan prosedur


141

1.2. Latar Belakang Pedoman keamanan pengembangan aplikasi web dibutuhkan karena permasalahan keamanan aplikasi yang muncul ketika aplikasi telah beroperasional dikarenakan tidak adanya kontrol-kontrol yang dilakukan saat proses pengembangan aplikasi tersebut yang dapat meminimalisir risiko pelanggaran keamanan. 1.3. Tujuan 1. Menjamin kelangsungan bisnis perusahan. 2. Menjamin terlaksananya kebijakan keamanan informasi yang berkaitan dengan Kerahasiaan (Confidentiality), Keutuhan (Integrity) dan Ketersediaan (Availability) dalam kegiatan pengembangan aplikasi berbasis WEB. 1.4. Pengguna Dokumen Dokumen ini diperuntukkan bagi : 1. Pengembang internal aplikasi perusahaan. 2. Vendor dan rekanan Pengembang yang terdaftar dalam daftar rekanan Lintasarta. 3. Penanggung jawab aplikasi dan administrator server di bagian operasional. 4. Pengguna aplikasi internal perusahaan. 1.5. Kebijakan Umum Pedoman ini berisi petunjuk pelaksanaan pengembangan aplikasi berbasis web dalam rangka menjaga keamanan informasi dan menjamin semua fungsi kontrol berjalan sesuai dengan aturan yang berlaku. Pedoman ini merupakan pelengkap dari Kebijakan Keamanan TI perusahaan, Prosedur Permintaan dan Pengadaan Software TI, dan standar SDLC Aplikasi perusahaan. Pedoman umum terkait dengan Keamanan Pengembangan Aplikasi : 1. Aplikasi perusahaan termasuk dalam fasilitas infrastruktur IT yang dimiliki oleh perusahaan, sehingga perusahaan berhak untuk mengatur penggunaan fasilitas tersebut dengan memberikan hak akses, mencabut, menutup sementara hak akses. 2. Proses pengembangan aplikasi harus dilakukan sesuai prosedur pengembangan aplikasi yang telah disahkan perusahaan, selain menghasilkan aplikasi juga menghasilkan dokumen-dokumen SDLC formal yang menjadi kontrol atas pelaksanaan prosedur tersebut. 3. Prosedur pengembangan aplikasi formal dibuat harus dengan mempertimbangkan control-kontrol keamanan informasi yang


142

dibutuhkan perusahaan sesuai dengan kebijakan keamanan informasi maupun pedoman manajemen risiko perusahaan. 4. Para pengembang internal maupun rekanan wajib untuk mengikuti pedoman keamanan pengembangan aplikasi yang telah ditetapkan. 5. Setiap pelanggaran terhadap pedoman yang telah ditetapkan akan dikenakan sanksi sesuai dengan ketentuan yang berlaku di perusahaan. 6. Pedoman, prosedur pengembangan aplikasi, standar dokumen SDLC akan ditinjau ulang setiap tahun untuk melihat apakah diperlukan perubahan atau tidak sesuai dengan kebutuhan. 1.6. Ruang Lingkup Ruang Lingkup Pedoman Keamanan Pengembangan Aplikasi web mencakup : 1.6.1. Proses Pengembangan Aplikasi 1. Pembuatan Kerangka Acuan Kerja (KAK) dan Perencanaan Proyek 2. Fase Identifikasi kebutuhan bisnis dan Fungsional 3. Fase Disain Aplikasi 4. Fase Konstruksi Aplikasi 5. Fase Ujicoba 6. Pelatihan dan Sosialisasi 1.6.2. Pedoman Teknis 1. Validasi data input 2. Otentikasi 3. Otorisasi 4. Data Sensitif / Rahasia 5. Manajemen Sesi 6. Kriptograpi 7. Manipulasi Parameter 8. Exception handling 9. Log dan Audit 10. Konfigurasi web server 1.6.4. Sanksi

2.

Peran dan Tanggung Jawab

Keamanan pengembangan aplikasi menjadi tanggung jawab semua pihak yang terlibat dalam kegiatan dan proses pengembangan aplikasi. Manajemen perusahaan melalui divisi IT berkomitmen untuk dapat membuat, melaksanakan dan melakukan tinjauan


143

atas pedoman keamanan pengembangan aplikasi yang sejalan dengan kebijakan keamanan informasi yang telah dimiliki. Berikut ini adalah peran dan tanggung jawab dalam pelaksanaan pedoman keamanan pengembangan aplikasi :

No

1

Fungsi Jabatan Divisi / Umum Lintasarta Bagian Lintasarta Vas Operation General Pengesahan & IT Manager dokumen

2

IT Development & Business Process

Manager

Pembuat dokumen

3

IT Development Assistant Manager

Assisstant Manager

Pelaksana pedoman dan Pelaksana sosialisasi pedoman

3

IT Development & Business Process

System Analyst dan System Engineer

Pelaksana pedoman di tiap proyek

4

IT Operation

System Analyst

Pengawas pelaksanaan pedoman

5

Rekanan Pengembang

-

Pelaksana pedoman

6

Pengguna Aplikasi

Uraian Kerja

Mengesahkan dokumen pedoman keamanan pengembangan aplikasi baru maupun revisi. Membuat, memelihara, melaksanakan pedoman keamanan pengembangan aplikasi di unit kerjanya, serta meninjau pedoman tersebut secara berkala. Melaksanakan pedoman keamanan pengembangan aplikasi dalam proses pengembangan aplikasi. Mengadakan pelatihan bagi karyawan atau rekanan baru, dan sosialisasi ulang berkala pada karyawan atau rekanan perusahaan. Karyawan dan rekanan dimaksud adalah karyawan dan rekanan pengembang aplikasi. Melaksanakan pedoman keamanan pengembangan aplikasi dalam proses SDLC. Melakukan pengawasan rekanan dalam pelaksanaan pedoman keamanan pengembangan aplikasi. Melakukan pengawasan pelaksanaan pedoman keamanan pengembangan aplikasi yang dilaksanakan oleh unit IT Development melalui proses Review dan Quality Control. Melakukan sosialisasi dan pelatihan mengenai keamanan aplikasi kepada pengguna secara berkala. Melaksanakan pedoman keamanan pengembangan aplikasi dalam mengerjakan proyek pengembangan aplikasi. Mengikuti pelatihan atau sosialisasi mengenai keamanan aplikasi sesuai dengan otoritas dan hak akses masing-masing.


144

Audit Officer

Memberikan masukan mengenai kebutuhan keamanan aplikasi dari sudut pandang fungsi bisnis dalam pembuatan dokumen SDLC. Audit fungsi Melakukan fungsi audit terhadap pelaksana kegiatan pelaksanaan pedoman dan dan pengawasan pedoman keamanan pengawas pengembangan aplikasi yang pedoman dilakukan oleh divisi TI.

7

Internal Audit

3.

Pedoman Keamanan Proses Pengembangan Aplikasi

3.1. Pembuatan Kerangka Acuan Kerja dan Perencanaan Proyek

No

3.1.1

Kebijakan

Perihal

Pedoman Umum

A.

Dokumen Kerangka Acuan Kerja : Dokumen Kerangka Acuan Kerja harus berisikan bagian yang secara jelas menyebutkan : a. Kebutuhan fungsional keamanan aplikasi b. Kebutuhan jaminan keamanan aplikasi c. Kebutuhan dokumentasi terkait keamanan aplikasi d. Deskripsi lingkungan pengembangan sistem informasi dan lingkungan saat sistem di operasionalkan. e. Syarat ujiterima keamanan aplikasi

B.

Dokumen Perencanaan Proyek : Dokumen Perencanaan proyek harus berisikan bagian yang secara jelas menyebutkan : a. Tahapan pekerjaan peninjauan terkait keamanan aplikasi melalui pemeriksaan dokumen formal SDLC maupun pelaksanaan skenario ujicoba khusus untuk keamanan aplikasi. b. Ada pihak yang secara jelas ditunjuk sebagai Security Officer yang bertugas melakukan peninjauan dan audit atas pelaksanaan kegiatan diatas. c. Bagian yang memastikan bahwa rencana pekerjaan yang berhubungan dengan pemenuhan kebutuhan maupun standard


145

No

Kebijakan

Perihal

C.

pedoman keamanan aplikasi memiliki sumber daya tenaga ahli, waktu dan dana yang cukup dan memadai. Contoh Dokumen : Contoh format dokumen KAK dapat dilihat pada bagian Lampiran 1, kode dokumen KAK. Contoh format dokumen Perencanaan Proyek dapat dilihat pada Lampiran 2 kode dokumen PP.

3.1.2. Prosedur

A. Prosedur Pembuatan KAK 1. Dokumen KAK suatu proyek aplikasi IT dibuat berdasarkan adanya program kerja IT yang telah disetujui oleh perusahaan. 2. Bagian IT Development and Business Process membuat dokumen KAK bersama dengan inisiator dan calon pengguna dari kebutuhan IT tersebut setelah rencana program kerja dan anggaran disahkan perusahaan. 3. Dokumen ditinjau oleh System Analyst di IT Operations untuk memeriksa apakah memenuhi persyaratan dokumen pedoman keamanan. 4. Dokumen KAK ditinjau dan disahkan oleh pimpinan inisiator, pimpinan calon pengguna dan pimpinan IT untuk menunjukan komitmen pelaksanaan isi KAK. 5. Dokumen KAK menjadi acuan dalam kegiatan pengadaan barang dan jasa untuk proyek aplikasi dan menjadi acuan juga dalam proses SDLC dari aplikasi itu sendiri.

3.2. Fase Identifikasi Kebutuhan Bisnis dan Fungsional

No

3.2.1

Perihal

Pedoman Umum

Kebijakan

A. Identifikasi kebutuhan bisnis 1. Dokumen kebutuhan bisnis (Business Requirement Spesification, BRS) wajib mencantumkan bagian khusus mengenai persyaratan keamanan aplikasi dari sisi bisnis pengguna. 2. Pembagian peran (application role) antar pengguna harus di definisikan dengan jelas dengan menggunakan kaidah pemisahan fungsi tugas (segregation of duty). 3. Mendefinisikan sumber daya yang dibutuhkan untuk


146

No

Kebijakan

Perihal

4.

melaksanakan standar keamanan yang diperlukan oleh aplikasi dan juga yang dibutuhkan dalam proses pengembangannya. Menerapkan manajemen risiko untuk mengidentifikasikan ancaman keamanan, kemungkinan dan dampak yang berkaitan dengan penggunaan aplikasi.

B. Identifikasi kebutuhan Fungsional 1. Dokumen kebutuhan fungsional (Functional Requirement Spesification, FRS) wajib mencantumkan bagian khusus mengenai persyaratan keamanan aplikasi dari sisi functional aplikasi. 2. Pembagian hak akses, fungsi antar menu berbasis role pengguna harus di definisikan dengan jelas dengan menggunakan kaidah pemisahan fungsi tugas (segregation of duty). 3. Mendefinisikan persyaratan ujicoba fungsional khusus untuk kebutuhan keamanan aplikasi, termasuk di dalamnya standar tool yang digunakan untuk pengembangan, untuk melakukan ujicoba keamanan, mekanisme, skenario dan standar kelulusannya. 4. Mendefinisikan sumber daya yang dibutuhkan untuk melaksanakan standar keamanan yang diperlukan oleh aplikasi dan juga yang dibutuhkan dalam proses pengembangannya. 5. Menerapkan manajemen risiko untuk mengidentifikasikan ancaman keamanan, kemungkinan dan dampak yang berkaitan dengan penggunaan aplikasi dari sudut pandang teknis. C. Contoh Dokumen : Contoh format dokumen BRS dapat dilihat pada bagian lampiran 3 dokumen ini. Sedangkan contoh dokumen FRS dapat dilihat pada bagian lampiran 4.

3.2.2. Prosedur

A. Pembuatan Dokumen BRS dan FRS 1. Dokumen BRS suatu proyek aplikasi IT dibuat berdasarkan adanya program kerja IT yang telah disetujui oleh perusahaan atau dokumen KAK. 2. Bagian IT Development and Business Process membuat dokumen BRS bersama dengan inisiator dan calon pengguna dari kebutuhan IT tersebut setelah rencana program kerja dan anggaran disahkan


147

No

Kebijakan

Perihal

perusahaan. 3. Dokumen ditinjau oleh System Analyst di IT Operations untuk memeriksa apakah memenuhi persyaratan dokumen pedoman keamanan. 4. Dokumen BRS ditinjau dan disahkan oleh pimpinan inisiator, pimpinan calon pengguna dan pimpinan IT untuk menunjukan komitmen pelaksanaan isi BRS. 5. Dokumen BRS menjadi acuan dalam kegiatan pembuatan kebutuhan fungsional, disain sistem, serta konstruksi aplikasi. B. Revisi Dokumen BRS dan FRS 1. Dokumen BRS dapat direvisi jika dalam perkembangannya terjadi perubahan lingkup aplikasi ataupun kebutuhan bisnis. 2. Perubahan dokumen BRS harus tercatat dan terdokumentasikan melalui versi dan bagian historis dokumen. 3. Perubahan dokumen ditinjau dan disahkan oleh pimpinan inisiator, pimpinan calon pengguna dan pimpinan IT.

3.3. Fase Disain Aplikasi

No

3.3.1

Kebijakan

Perihal

Pedoman Umum

Kebijakan Umum : 1. Disain aplikasi wajib mengakomodasi kebutuhan keamanan yang didefinisikan dalam dokumen BRS dan FRS. Disain aplikasi ditinjau oleh unit IT Operations untuk memastikan kesesuaian dengan kebutuhan persyaratan keamanan dalam BRS dan FRS. 2. Disain sistem aplikasi dibuat harus dengan memperhatikan ancaman-ancaman serangan yang mungkin terjadi pada titik-titik yang digambarkan dalam arsitektur berikut ini.


148

No

Perihal

Kebijakan

Sumber : Microsoft Juni 2003

Contoh Dokumen : Contoh format dokumen Disain dapat dilihat pada bagian lampiran 5 dokumen ini.

3.3.2. Prosedur

A. Review Disain 1. Pengembang yang telah menyelesaikan fase konstruksi melaporkan kepada fungsi IT Development. 2. Sesuai jadwal yang telah ditentukan IT Operation sebagai fungsi peninjau akan melakukan review konstruksi. 3. Review disain dilakukan oleh System Analyst bagian IT Operations. 4. Hasil review didokumentasikan dalam dokumen review konstruksi. B. Pembuatan Disain 1. Disain suatu proyek aplikasi IT dibuat berdasarkan dokumen BRS dan FRS. 2. Pengembang membuat dokumen Disain bersama dengan unit IT Development berdasarkan format dokumen yang baku dan berlaku. 3. Disain aplikasi ditinjau oleh unit IT Operations, jika lulus maka selanjutnya disahkan oleh pimpinan


149

No

Kebijakan

Perihal

inisiator, pimpinan calon pengguna dan pimpinan IT untuk menunjukan komitmen pelaksanaan isi disain tersebut. 4. Dokumen Disain menjadi acuan dalam kegiatan konstruksi aplikasi dan ujicoba. C. Revisi Dokumen Disain 1. Dokumen Disain dapat direvisi jika dalam perkembangannya terjadi perubahan lingkup aplikasi ataupun kebutuhan bisnis. 2. Perubahan dokumen disain harus tercatat dan terdokumentasikan melalui versi dan bagian historis dokumen. 3. Perubahan dokumen ditinjau oleh unit IT Operations dan disahkan oleh pimpinan inisiator, pimpinan calon pengguna dan pimpinan IT.

3.4. Fase Konstruksi Aplikasi

No

Perihal

1

Pedoman Umum

2.

Prosedur

Kebijakan

Kebijakan Umum : 1. Pengembang harus mematuhi standar keamanan aplikasi dan standar Quality Control dalam melakukan konstruksi aplikasi. 2. Pengembangan aplikasi harus mematuhi persyaratan keamanan yang telah ditentukan dalam dokumen disain aplikasi. 3. Pengembang harus menggunakan standar tool pemrograman yang telah disahkan oleh IT Development sebagai tools yang telah memiliki fungsi validasi keamanan standar. 4. Hasil konstruksi harus ditinjau oleh fungsi audit untuk memastikan pekerjaan yang dilakukan telah sesuai dengan persyaratan keamanan aplikasi. Review Konstruksi 1. Pengembang yang telah menyelesaikan fase konstruksi mempersiapkan review konstruksi. 2. Sesuai jadwal yang telah ditentukan System Analyst bagian IT Operation sebagai fungsi peninjau akan melakukan review konstruksi dengan panduan standar keamanan aplikasi dan standar quality control SDLC. 3. Hasil review konstruksi disahkan oleh fungsi


150

No

Kebijakan

Perihal

peninjau. 4. Hasil review didokumentasikan dalam dokumen review konstruksi. Setiap temuan diidentifikasikan dan ditindaklanjuti dengan perbaikan dan review ulang.

3.5. Fase Ujicoba

No

1

2.

Kebijakan

Perihal

Pedoman Umum

Prosedur

Kebijakan Umum : 1. Pengembang harus membuat skenario ujicoba khusus yang mengevaluasi persyaratan keamanan yang ditentukan dalam dokumen BRS dan FRS. 2. Skenario ujicoba yang mengevaluasi hasil konstruksi aplikasi berdasarkan pedoman keamanan aplikasi harus dibuat dan dilaksanakan oleh fungsi audit. 3. Skenario ujicoba berisi standar yang harus dipenuhi untuk setiap skenario. 4. Hasil ujicoba didokumentasikan dan ditindaklanjuti jika masih ditemukan ketidaksesuaian dengan standar yang telah ditentukan. A. Development Test 1. Pengembang yang telah menyelesaikan fase konstruksi mempersiapkan development test. 2. Sesuai jadwal yang telah ditentukan System Analyst bagian IT Operation sebagai fungsi peninjau akan melakukan review konstruksi dengan panduan dokumen disain. 3. Hasil development test disahkan oleh fungsi peninjau. 4. Hasil development test didokumentasikan dalam dokumen development test. Setiap temuan diidentifikasikan dan ditindaklanjuti dengan perbaikan dan test ulang.


151

3.6. Sosialisasi dan Pelatihan Keamanan Aplikasi

No

1

2

Kebijakan

Perihal

Pedoman Umum

Prosedur

Kebijakan Umum : 1. Pengembang aplikasi baik internal maupun rekanan wajib memperoleh pelatihan dan sosialisasi mengenai kebijakan keamanan informasi, pedoman keamanan pengembangan aplikasi, dan standar SDLC perusahaan. Pelatihan dan sosialisasi dilakukan : 2. Sosialisasi / Pelatihan awal untuk karyawan dan rekanan baru. 3. Sosialisasi / Pelatihan pengulangan berkala 1 tahun sekali. 4. Pengguna aplikasi selain diberikan pelatihan mengenai penggunaan aplikasi juga diberikan pelatihan dasar mengenai keamanan aplikasi yang berkaitan dengan hak akses dan pekerjaannya tersebut. 5. Setiap kegiatan pelatihan keamanan pengembangan aplikasi maupun keamanan dasar aplikasi didokumentasikan dalam laporan kegiatan pelatihan. 6. Pelatihan awal harus diberikan kepada pengembang internal ataupun rekanan sebelum melakukan pekerjaannya. 7. Pelatihan bagi pengguna harus diberikan kepada pengguna sebelum hak akses kepada aplikasi digunakan oleh pengguna tersebut. 8. Pelatihan harus dilakukan kembali ketika ada perubahan sistem yang merubah cara penggunaan atau terjadi revisi dalam dokumen pedoman ini. A. Prosedur pelaksanaan pelatihan bagi pengembang 1. IT Development mendata karyawan baru yang bertugas sebagai pengembang aplikasi dan rekanan pengembang baru serta karyawan rekanan yang telah lebih dari 1 tahun belum memperoleh sosialisasi ulang untuk didaftarkan dalam jadwal sosialisasi dan pelatihan awal pengembang. 2. IT Development mengadakan sosialisasi kebijakan keamanan informasi, pedoman keamanan pengembangan aplikasi dan standar SDLC pada karyawan dan rekanan baru. 3. IT Development melakukan evaluasi atas hasil pelatihan dengan melakukan tes tertulis kepada para peserta. 4. IT Development membuat laporan pelaksanaan pelatihan.


152

No

Kebijakan

Perihal

B.

Prosedur pelaksanaan pelatihan bagi pengguna

a.

IT Development membuat silabus dan materi pelatihan dasar keamanan aplikasi yang akan dioperasionalkan. IT Development mendata peserta yang akan diberikan pelatihan dan sosialisasi. IT Development menyelenggarakan pelatihan dan sosialisasi, diakhiri dengan tes evaluasi bagi peserta. Untuk pengulangan pelatihan secara berkala dilaksanakan oleh IT Operations.

b. c. d.

4. PEDOMAN KEAMANAN TEKNIS PENGEMBANGAN APLIKASI

Sumber : Microsoft Juni 2003

Kategori No 4.1 Validasi data input

1. 2. 3. 4.

Pedoman Asumsikan seluruh masukan adalah malicious. Gunakan validasi input tersentralisasi. Jangan tergantung pada validasi di sisi client (javascript) gunakan juga validasi di sisi server. Batasi hanya data yang diinginkan yang dapat dimasukan oleh pengguna tentukan filter yang hanya


153

No

Kategori

4.2 Otentikasi

4.3 Otorisasi

4.4 Data Sensitif / Rahasia

4.5 Manajemen Sesi

Pedoman menerima data yang diinginkan, tolak dan sanitasi data masukan. 5. Validasi tipe, panjang, format dan rentang dari data.

1. Kelompokan halaman situs berdasarkan akses anonim, akses teridentifikasi, dan akses terotentikasi. 2. Gunakan aturan password sesuai kebijakan keamanan TI. 3. Gunakan masa berlaku password dan penonaktifan akun user. 4. Jangan simpan credentials user di database gunakan domain controler. Enkripsi saluran komunikasi ketika mengirimkan informasi user name dan password gunakan https. 1. Terapkan whitelist untuk webserver dan application server yang bisa mengakses sql request ke database server. 2. Halaman yang diidentifikasikan untuk akses terotentikasi selalu memvalidasi user session di server dan hak aksesnya terhadap halaman tersebut, bukan sekedar masa berlaku sesinya saja kecuali jika memang ditujukan untuk publik. 3. Batasi akses Aplikasi ke system level resources server seperti files, folders, registry keys, Active Directory objects, database objects, event logs dan sebagainya. 4. Gunakan Windows Access List untuk membatasi user apa yang bisa mengakses resource dan operasi apa yang bisa dilakukannya. 1. Tidak boleh menyimpan dan mengirimkan data user dan password database dalam plain text. 2. Gunakan secure communication (SSL) ketika mengirimkan user dan password database. 1. Batasi masa hidup / berlaku session. 2. Enkripsi isi dari cookies untuk otentikasi. 3. Lindungi session state dari akses yang tak terotorisasi atau pencurian sesi. 4. Memastikan bahwa sesi ditutup ketika pengguna log out 5. Pastikan bahwa sesi mengalami timeout setelah tidak aktif selama jangka waktu tertentu. 6. Pastikan bahwa semua halaman yang membutuhkan otentikasi untuk diakses, memiliki tautan untuk logout. 7. Pastikan bahwa nomor sesi tidak pernah diungkapkan


154

No

Kategori

Pedoman selain di header cookie, khususnya di URL, pesan error, atau log. Ini termasuk memastikan bahwa aplikasi tidak memperbolehkan penulisan ulang session cookies melalui URL. 8. Pastikan bahwa nomor sesi tidak pernah diungkapkan selain di header cookie, khususnya di URL, pesan error, atau log. Ini termasuk memastikan bahwa aplikasi tidak memperbolehkan penulisan ulang session cookies melalui URL. 9. Pastikan bahwa ID session diubah setiap kali login dan setiap otentikasi ulang. 10. Pastikan bahwa sesi id berubah atau dibersihkan pada saat logout. 11. Memastikan bahwa id sesi yang diakui sebagai sah oleh aplikasi adalah hanya id yang dihasilkan oleh framework aplikasi. 12. Pastikan bahwa token sesi yang telah terotentikasi cukup panjang dan acak untuk bertahan dari jenis serangan yang sering terjadi berdasarkan ancamanancaman di lingkungan.

Bila menggunakan kriptograpi, tidak boleh mengembangkan sendiri gunakan platform dari tools yang sudah disahkan oleh IT Development. 4.7 Manipulasi 1. Jangan mempercayai field yang dapat dimanipulasi Parameter oleh client (query strings, form fields, cookies, atau HTTP headers). 2. Validasi semua nilai parameter yang dikirim oleh client. 4.8 Exception handling 1. Gunakan exception handling yang terstruktur untuk memudahkan penambahan maupun pencarian masalah. 2. Jangan menampilkan pesan kesalahan secara detil dari server. 3. Jangan mencatat log data pribadi seperti password. 4.9 Log dan Audit 1. Aplikasi harus memiliki fungsi audit dan log minimal pada fungsi login dan akses page. 2. Aplikasi harus dapat mencatat setiap login aplikasi yang sukses dan yang gagal, kapan, siapa usernya, dari IP berapa dan nama komputernya. 3. Aplikasi harus bisa mencatat user, kapan, IP dan nama computer dari setiap sesi user yang mencoba mengakses halaman yang tidak diberikan hak akses untuknya.

4.6 Kriptograpi


155

Kategori No 4.10 Konfigurasi web server

4.11 Proses persetujuan (approval) melalui tautan email

5.

Pedoman 1. Hapus atau disable akun yang tak digunakan 2. Disable Akun Guest 3. Ganti nama akun administrator 4. Disable akun IUSR (default akun internet anonim) 5. Buat akun web anonim sendiri secara custom. 6. Gunakan kebijakan password yang kuat. 7. Disable anonymous logons. 8. Batasi remote logons. 9. Hapus virtual direktori berikut yang terinstal sebagai contoh : IISSamples, IISAdmin, IISHelp,dan Scripts. 10. Disable setelan Parent Path untuk menghindari serangan direktori traversal. 11. Tidak boleh memasang protokol yang plain text dan berbahaya secara bawaan seperti : Telnet, Post Office Protocol (POP3), Simple Mail Transfer Protocol (SMTP), and File Transfer Protocol (FTP) 1. Penggunaan token unik terenkripsi untuk setiap URL permintaan persetujuan yang dikirimkan melalui suatu email yang kode parameternya tidak mudah dipahami user. 2. Adanya konfirmasi kembali dari sistem atas data yang berhasil / gagal dicatat oleh sistem atas tindakan yang dilakukan oleh pengguna 3. Pastikan pencatatan kontrol keamanan menyediakan kemampuan untuk mencatat peristiwa keberhasilan dan kegagalan yang diidentifikasi sebagai yang terkait keamanan. 4. Permintaan email persetujuan tidak boleh menggunakan alamat email pemohon sebagai pengirim, harus menggunakan alamat email akun dari sistem aplikasi

SANKSI Rekanan atau Karyawan yang melakukan pelanggaran dari pedoman ini dengan sengaja akan dikenakan sanksi. Sanksi berlaku baik kepada pengembang aplikasi (bagian IT Development & Business Process) maupun bagian yang melakukan pemeriksaan pelaksanaan pedoman (bagian IT Operations) :


156

1.

Pelanggaran pertama : a. Karyawan. Karyawan yang dengan sengaja lalai dalam mematuhi pedoman keamanan pengembangan aplikasi ini, seperti sengaja tidak menggunakan tools pemrograman standar yang telah disahkan IT Development akan diberikan peringatan lisan sesuai peraturan pelanggaran kerja di Perusahaan.

b. Rekanan Rekanan yang dengan sengaja lalai dalam mematuhi pedoman keamanan pengembangan aplikasi ini akan diberikan peringatan tertulis dari IT Development.

2.

Pelanggaran kedua : a. Karyawan. Karyawan yang dengan sengaja lalai kembali untuk kali kedua dalam mematuhi pedoman keamanan pengembangan aplikasi ini, akan diberikan peringatan tertulis sesuai peraturan pelanggaran kerja di Perusahaan dengan komitmen untuk tidak mengulangi kelalaiannya.

b. Rekanan Rekanan yang dengan sengaja lalai kembali untuk kali kedua dalam mematuhi pedoman keamanan pengembangan aplikasi ini, IT Development akan memberikan rekomendasi penghentian sementara semua proses order pengadaan kepada rekanan yang bersangkutan sampai jangka waktu 3 bulan. Dan bagian Procurement akan memberikan peringatan tertulis pertama kepada rekanan tersebut.

6.

Daftar Lampiran 1. 2. 3. 4. 5.

Lampiran 1 : Template Kerangka Acuan Kerja Lampiran 2 : Template Project Plan Lampiran 3 : Template dokumen Business Requirement Spesification (BRS) Lampiran 4 : Template dokumen Functional Requirement Spesification (FRS) Lampiran 5 : Template dokumen Design Detil Spesification (DDS)


157 Lampiran 1

KERANGKA ACUAN KERJA

Nama Proyek:

Nama Proyek

Versi

:

Tanggal Release

:

Disusun Oleh

:


158 DAFTAR ISI

LEMBAR PERSETUJUAN ................................................................................................159 B A G I A N 1 P E N D A H U L U A N .............................................................................160 1.1 1.2 1.3 1.4

TUJUAN....................................................................................................................160 RUANG LINGKUP TANGGUNG JAWAB ......................................................................160 KEBUTUHAN SISTEM ...............................................................................................160 KONDISI SAAT INI ....................................................................................................160

B A G I A N 2 K E B U T U H A N P R O Y E K .............................................................161 2.1 2.2 2.3 2.4 2.5 2.6

KEBUTUHAN UMUM ................................................................................................161 WAKTU PELAKSANAAN ...........................................................................................161 KEBUTUHAN TENAGA AHLI .....................................................................................161 KEBUTUHAN SISTEM APLIKASI ................................................................................162 KEBUTUHAN PEMBUATAN LAPORAN .......................................................................162 KEBUTUHAN PERSYARATAN KEAMANAN APLIKASI..................................................162

B A G I A N 3 P E N T A H A P A N P R O Y E K .........................................................162 3.1 3.1.1 3.1.2 3.1.3 3.1.4 3.1.5 3.1.6 3.2 3.3

TAHAPAN KEGIATAN ...............................................................................................162 Tahap Penyusunan Kebutuhan Pengguna........................................................... 162 Tahap Disain ....................................................................................................... 162 Tahap Konstruksi ................................................................................................ 163 Tahap Testing ...................................................................................................... 163 Tahap Implementasi ............................................................................................ 163 Tahap Operasional.............................................................................................. 164 DELIVERABLES ........................................................................................................164 RUANG LINGKUP GARANSI ......................................................................................165


159

Lembar Persetujuan Dibuat Oleh

Disetujui Oleh


160

PENDAHULUAN

Penjelasan mengenai latar belakang kebutuhan project ini

Tujuan -

Penjelasan mengenai tujuan project

Ruang Lingkup Tanggung Jawab Ruang lingkup tanggung jawab dalam pengembangan aplikasi untuk memenuhi kebutuhan Lintasarta,: •

•

Pihak Lintasarta bertanggung jawab sebagai: o

Pemilik proyek.

o

Manajer Proyek

o

Counterpart bagi rekanan

o

Nara sumber resmi

o

Penyedia informasi yang dibutuhkan rekanan

Pihak Rekanan bertanggung jawab terhadap : o

Perencana dan Pelaksana manajemen proyek bersama Lintasarta

o

Pelaksana pengembangan sistem

o

Pembuatan laporan progress selama pengembangan

o

Penyediaan dokumentasi hasil pengembangan (Teknis maupun tidak)

o

Pelaksana implementasi system

o

Pemeliharaan system selama masa garansi

Selain itu rekanan wajib menjaga kerahasiaan data dan informasi yang dimiliki oleh Lintasarta selama periode pengembangan (akan dicover dalam Non-Disclosure Agreement).

Kebutuhan Sistem Secara umum menjelaskan kebutuhan Aplikasi yang akan dikembangkan dan karakteristiknya

Kondisi Saat Ini Kondisi aplikasi dan lingkungannya as it is Tabel 1 Aplikasi Eksisting


161 APPLICATION ON SERVER

FRONT END

APLIKASI

DATABASE

KEBUTUHAN PROYEK

Bagian ini berisi uraian kebutuhan Lintasarta untuk proyek pengembangan aplikasi operasional terkait dengan kebutuhan umum, kebutuhan pembuatan aplikasi dan kebutuhan pembuatan laporan.

Kebutuhan Umum Kebutuhan umum proyek yang ditawarkan kepada Peserta meliputi : 1. Pembuatan Manajemen Proyek untuk pengembangan aplikasi 2. Pengembangan sampai dengan Implementasi aplikasi 3. Penyelenggaraan pelatihan dan alih teknologi ke pihak Lintasarta 4. Penyediaan dokumen proyek, dokumen teknis, buku manual dan source code dari aplikasi yang dikembangkan untuk diberikan kepada Lintasarta.

Waktu Pelaksanaan Penjelasan target lama waktu pelaksanaan project

Kebutuhan Tenaga Ahli No

Tenaga Ahli

1

Project manager (Pengalaman minimal 5 thn)

2

System Analyst (Pengalaman minimal 5 thn)

3

Programmer asp klasik (Pengalaman minimal 3 thn), dengan masa garansi

4

Programmer asp klasik (Pengalaman minimal 3 thn)

5

Technical Writer (Pengalaman minimal 1 thn)

Man Hours

Man Days

Waktu (bulan)

Jumlah

Programmer diharapkan menggunakan software code charge dalam pengembangan aplikasinya.


162

Kebutuhan Sistem Aplikasi Menjelaskan kebutuhan pengembangan aplikasi per proses bisnis.

Kebutuhan Pembuatan Laporan Kebutuhan Pembuatan Laporan adalah kebutuhan untuk pengeluaran data dari sistem dan penampilan data tersebut dalam format yang sesuai kebutuhan user.

Kebutuhan persyaratan keamanan aplikasi Menjelaskan kebutuhan persyaratan keamanan aplikasi yang harus dipenuhi oleh pengembang.

PENTAHAPAN PROYEK

Tahapan Kegiatan

Tahap Penyusunan Kebutuhan Pengguna Pada tahap ini rekanan melakukan pengumpulan kebutuhan user atas aplikasi yang akan dikembangkan, untuk dirumuskan sebagai user requirement yang akan menjadi acuan dalam pengembangan aplikasi. Pada tahapan ini rekanan diharapkan dapat menggali secara lengkap semua kebutuhan user serta menjelaskan jika terdapat kebutuhan user yang tidak dapat diakomodasi. Termasuk identifikasi kebutuhan keamanan aplikasi dan skenario evaluasi dan ujicobanya.

Dari tahap ini dihasilkan Berita Acara Spesifikasi Software yang disetujui oleh Lintasarta dan Rekanan yang menjadi acuan dalam implementasi fungsionalitas sistem.

Tahap Disain Pada tahap disain pihak rekanan melakukan perencangan aplikasi sesuai dengan kebutuhan user yang telah terdefinisi pada tahap sebelumnya. Perancangan yang dilakukan mencakup perancangan modul-modul yang akan dibangun, perancangan database yang akan digunakan, dan perancangan antarmuka sistem.

Perancangan database yang dimaksud adalah database untuk penyimpanan data yang dibutuhkan untuk menyimpang data permohonan jaringan.

Dari tahap ini dihasilkan Berita Acara Design Software yang disetujui oleh Lintasarta dan Rekanan.


163

Tahap Konstruksi Pada tahap ini dilakukan konstruksi berdasarkan design system yang telah dibuat pada tahap sebelumnya. Proses konstruksi sistem dilakukan dengan memperhatikan efisiensi dan performansi sistem.

Dari tahap ini dihasilkan installastion disc yang sudah teruji proses instalasinya dan siap diujicobakan oleh user, serta dokumen risalah review konstruksi. Pengembang wajib mengikuti pedoman keamanan pengembangan aplikasi Lintasarta.

Tahap Testing Pada tahap ini dilakukan uji coba aplikasi yang mencakup: 1. Kesesuaian dengan kebutuhan user yang telah dijabarkan 2. Integrasi dengan aplikasi eksisting, apakah data yang ditampilkan sesuai dengan data yang diinput pada aplikasi baru 3. Load test untuk menguji beban aplikasi dan response time baik dari intranet maupun dari internet

Pada tahap ini terdapat dokumen yang menjadi acuan dalam proses testing, dimana kelengkapan proses pengujian yang terdapat pada dokumen tersebut sudah disetujui oleh user. Jika aplikasi telah lolos proses pengujian, terdapat Berita Acara Uji Terima Software yang disetujui oleh Lintasarta dan Rekanan.

Tahap Implementasi Pada tahap ini rekanan melakukan implementasi system pada server operasional, serta pelatihan sistem kepada user. Untuk memastikan kelancaran sistem yang telah diimplemetasikan, terdapat proses monitoring implementasi sistem dimana rekanan bertanggung jawab untuk melakukan perbaikan jika terdapat bugs.

Dari tahap ini dihasilkan Berita Acara Serah Terima Software dan User Manual sistem. Setelah disetujuinnya Berita Acara Serah Terima Software, rekanan wajib memberikan garansi pekerjaan yang telah dilakukan.


164 Tahap Operasional Pada tahap ini system sudah berjalan dengan baik, dan tidak terdapat bugs yang harus diperbaiki. Jika kondisi tersebut sudah terpenuhi maka dibuatlah Berita Acara Operasional Software.

Deliverables Pekerjaan

Lintasarta

Rekanan

Spesifikasi kebutuhan Dokumen : Berita Acara Spesifikasi Software

TTP/SOP Lintasarta yang terkait dengan aplikasi yang akan dikembangkan.

Project Brief : memberikan gambaran kebutuhan Lintasarta berkenaan dengan pengembangan aplikasi

Design Sistem Dokumen : Berita Acara Design Software

Konfigurasi Sistem Eksisting

Konfigurasi pengembangan aplikasi baik secara logik maupun fisik

Konstruksi Dokumen : Risalah Review Konstruksi Software, Source Code dan Installation Disc.

•

Akses ke database, infrastuktur

•

Coding (Programming)

•

Aplikasi

•

Counter part subsistem yang direview

•

Database

Materi review

•

Materi review

•

Testing Aplikasi/Sistem Dokumen : Berita Acara Uji Terima Software.

•

Counter part

•

Materi UAT

•

Sign Off UAT oleh user

Implementasi Dokumen : Berita Acara Serah Terima Software

•

Counter part

•

Materi integrasi

•

Business Requirement Specification

Materi UAT

Dokumentasi Pengembangan (developer manual): •

Functional Requirement Specification

•

Architecture Requirement Specification

•

Detail Design Specification

•

Acceptence Test Specification

•

Skenario Implementasi

• Source code Dokumentasi Pengguna: •

Trouble shooting

•

User Manual

• FAQ Pelatihan Tim Pengembangan: •

Arsitektur sistem

•

Arsitektur database

• API usage Pelatihan Tim Operasional: •

Trouble handling and trouble shooting

•

Bug handling

•

Integrasi data

•

Interkoneksi ke sistem existing


165 Lintasarta

Pekerjaan

Operasional Dokumen : Berita Acara Operasional Software

Rekanan

Dokumentasi Pemeliharaan : •

Bug reporting

•

System maintenance

Ruang Lingkup Garansi Menjelaskan ruanglingkup masa garansi, seperti : Rekanan wajib memberikan garansi dengan mengacu pada spesifikasi pekerjaan yang diberikan (tidak merubah desain dan spesifikasi pekerjaan). Ruang lingkup garansi yang menjadi tanggung jawab rekanan adalah sebagai berikut: 1. Perbaikan aplikasi karena kesalahan program (bug) untuk modul, report, fungsi, dan proses yang tidak teridentifikasi ketika serah terima dilakukan. 2. Tuning performansi apabila performansi sistem dirasakan tidak optimal apabila dibandingkan dengan kapasitas infrastruktur yang ada berdasarkan standar performansi yang telah disepakati. 3. Recovery karena terjadinya kerusakan pada aplikasi/crash (kondisional). 4. Perubahan minor yang tidak mengubah spesifikasi pekerjaan (bukan penambahan atau perubahan aplikasi karena kebutuhan bisnis proses). 5. Bantuan operasional dan panduan pemakaian aplikasi. 6. Standby on site di kantor Lintasarta lokasi Menara Thamrin : Y bulan pertama di dalam masa garansi. On call untuk : X bulan berikutnya 7. SLA waktu perbaikan apabila ditemukan gangguan yang disebabkan oleh kesalahan aplikasi adalah maksimum 1 hari di lokasi Menara Thamrin apabila disepakati bersama bahwa perbaikan harus dilakukan on site. Khusus untuk modul-modul yang krusial, perbaikan harus diselesaikan pada hari yang sama.


166 Lampiran 2 Dokumen Project Plan

NAMA PROYEK : <SEBUTKAN NAMA PROYEK>

Versi / Release

:

Tanggal

:

Disusun Oleh :


167 REVIEW dan Persetujuan ( User ) Review

Nama :

Tanggal : ____/___/____

Jabatan : Bagian :

( ____________________ )

Nama :

Tanggal : ____/___/____

Jabatan : Bagian :

( ____________________ )

Tanggal : ____/___/____

Nama : Jabatan : Bagian :

( ____________________ )

Tanggal : ____/___/____


( ____________________ )

Tanggal : ____/___/____


( ____________________ )

( TI )

Persetujuan

Nama :

Tanggal : ____/___/____

Jabatan :

( ____________________ )

Bagian :

Nama :

Tanggal : ____/___/____

Jabatan : Manager Bagian :

( ____________________ )

Nama :

Tanggal : ____/___/____

Jabatan : General Manager Divisi : Teknologi Informasi

( ____________________ )


168 Pendahuluan Jelaskan pada bagian ini tujuan dari penulisan dokumen ini, dan pihak yang diharapkan membaca dokumen ini. Tuliskan dalam satu paragraf singkat (5-8 baris).

Referensi Document Name

Version

Author

Form Permintaan Pekerjaan TI

Feasibility Analysis

Project Work Statement

Dokumen Prosedur Bisnis Terkait

Nota Dinas / SK

Dokumen dari sistem lain yang terkait

*) minimal adalah FPPTI, Feasibility Analysis, dan PWS. Dokumen lain adalah dokumen pendukung yang menguatkan perencanaan proyek.

Histori Revisi Tanggal Jun 2013

Versi 1.4

Catatan Revisi

Penyusun

Penambahan bagian 3.1 Tugas dan Suwarno Tanggung jawab pada Struktur Pribadi Organisasi proyek mewajibkan bagian yang secara jelas menyebutkan penunjukan security officer. Penambahan bagian 5 Jadwal tahapan harus memasukan kegiatan peninjauan dan evaluasi terhadap pedoman keamanan pengembangan aplikasi yang menjadi tanggung jawab Security Officer.


169

1 Executive Summary 1.1

Deskripsi Umum Proyek

Diisi dengan deskripsi umum proyek, dijabarkan dalam penjelasan umum dan tujuan yang ingin dicapai dari implementasi project ini. Untuk mempermudah, Deskripsi umum proyek dapat diambil dari dokumen PWS dan Feasibility Analysis.

1.2

Tahapan Utama

Diisi dengan tahapan tahapan utama dari proyek yang akan dijalankan, dan hasil yang diharapkan untuk dicapai untuk setiap tahapan.

1.3

Resiko

Yang dimaksud dengan resiko adalah hal-hal yang apabila terjadi dapat mengakibatkan tidak tercapainya sebagian atau seluruh tujuan proyek. Resiko dinyatakan dalam bentuk :

Kejadian

Kemungkinan

Dampak Biaya

Dampak thd waktu


170

2 Pendahuluan 2.1

Tujuan

Diisi dengan tujuan, dinyatakan dalam kalimat yang menjelaskan mengapa proyek ini dibutuhkan, kebutuhan bisnis yang dipenuhi dengan adanya proyek ini, dan keuntungan yang dapat dicapai dengan implementasi proyek ini. Dapat diambil dari dokumen PWS maupun Feasibility Analysis.

2.2

Strategi / Methodologi

Jelaskan mengenai pendekatan yang diambil untuk menyelesaikan proyek ini, misalnya metode yang digunakan (Joint Application Development, XP, dll), strategi pengerjaan (outsource bagian2 tertentu, dll)

2.3

Ruang Lingkup

Jelaskan mengenai ruang lingkup pekerjaan yang termasuk dalam proyek ini, meliputi : - hal-hal yang dicakup - hal-hal yang tidak dicakup - Batasan-batasan yang harus diikuti. Yang dicantumkan disini adalah pendetilan dari scopes yang ada pada dokumen PWS.

2.4

Deliverables

Jelaskan mengenai hasil yang diharapkan dari pengerjaan proyek ini meliputi : - Hasil Akhir - Hasil Antara - Hasil pendukung (dokumentasi, training, petunjuk operasional). Yang dicantumkan disini adalah pendetilan dari deliverables yang ada pada dokumen PWS.

2.5

Integrasi Sistem

Jelaskan secara umum mengenai antarmuka eksternal yang : - digunakan oleh sistem lain untuk mengakses sistem yang akan dikembangkan - digunakan untuk mengakses sistem eksternal Yang dimaksud sebagai antarmuka disini adalah titik-titik integrasi antar sistem.

2.6

Standart (Project Specific)

Jelaskan mengenai standar-standar yang akan diacu dalam pelaksanaan proyek ini.


171

3 Struktur Organisasi Proyek 3.1

Tugas & Tanggung jawab

Jelaskan mengenai tugas dan tanggung jawab dari Tim Pelaksana Proyek dan pihak-pihak lain (steering committee, dll) yang terkait dengan proyek ini. Selain itu harus disebutkan juga Tugas dan Tanggung jawab yang berkaitan dengan peninjauan dan evaluasi keamanan aplikasi.

3.2

Struktur Organisasi Tim

Jelaskan mengenai struktur organisasi tim dan personil yang terkait. Harus disebutkan secara jelas pihak yang ditunjuk sebagai security officer.

3.3

Review dan Laporan

Jelaskan mengenai proses review dan reports yang digunakan untuk proses pemantauan kemajuan pelaksanaan proyek

4 Kebutuhan sumber daya dan biaya 4.1

SDM

Berisi daftar nama SDM, bagian dan kemampuan/skill masing-masing SDM, kapan dan berapa lama SDM tersebut dibutuhkan untuk proyek ini.

Unallocated requirements should be highlighted.

4.2

Perangkat

Berisi daftar seluruh perangkat yang dibutuhkan oleh proyek ini sejak dimulai proyek sampai dengan fase implementasi, dengan menyebutkan pada fase apa perangkat tersebut dibutuhkan (system testing, acceptance dan cut over).

Menyebutkan status data yang rencananya akan digunakan dalam pengembangan system untuk memastikan dan mencatat historis bahwa data yang digunakan adalah data yang benar dengan posisi yang dibutuhkan.

Penggunaan Server


172

Kegunaan

Nama Server

Alamat IP

Keterangan

Server Pengembangan

Server Testing Server Operasional

Status Data

Data

Copy from

Status Tanggal

Aplikasi Database Data Excel

4.3

Perangkat Voice dan Data (optional)

Jelaskan kebutuhan jumlah dan jenis perangkat voice dan data yang dibutuhkan oleh proyek ini

4.4

Fasilitas Pendukung (optional)

Daftar fasilitas pendukung dan jumlah kebutuhan, diantaranya kebutuhan peralatan kantor, telp, dll dan durasi lama pemakaian

5

JADWAL

Berisi jadwal proyek yang terdiri dari daftar kegiatan utama, ketergantuan antar kegiatan serta target mulai dan target selesai. Jadwal tahapan harus memasukan kegiatan peninjauan dan evaluasi terhadap pedoman keamanan pengembangan aplikasi yang menjadi tanggung jawab Security Officer.


173

6 Resiko Proyek(project Risk) dan Kontingensi Plan Merupakan pendetilan dari resiko-resiko yang mungkin muncul dan Contingency Plan terkait dengan resiko tersebut. Berikut adalah guideline mengenai resiko-resiko yang umum muncul pada saat implementasi sistem TI.

Kejadian

Probabiliti

Dampak Biaya

Dampak Waktu

Ruang Lingkup Terjadi penambahan kebutuhan yang mengakibatkan penambahan waktu

Terjadi perubahan spesifikasi/ruang lingkup yang harus diakomodasi oleh sistem

Terjadi penambahan kebutuhan/spesifikasi tanpa melalui jalur change management yang baku

Personil Tim Personil penting dari tim pelaksana proyek tidak available pada saat dibutuhkan

Personil dengan kemampuan teknis penting tidak available pada saat dibutuhkan

Terjadi pengurangan staff pada tim pelaksana proyek

User Counterpart dari sisi user tidak available pada saat yang dijadwalkan

Proses pengambilan keputusan dan kesepakatan oleh user tidak dapat dilakukan secara cepat

Feedback hasil review terhadap deliverables tidak diterima oleh tim


Tingkat

174 sesuai dengan jadwal Personil user yang betul-betul memahami proses bisnis/sistem digantikan dengan personil lain yang kurang begitu paham

Teknis Teknologi yang digunakan memiliki keterbatasan teknis yang dapat menghambat pelaksanaan proyek

Salah satu komponen teknologi yang digunakan tidak dapat diintegrasikan dengan mudah

Penggunaan teknologi baru yang belum begitu dipahami

Perangkat Perangkat yang dibutuhkan tidak available pada saat yang direncanankan

Akses ke perangkat tertentu terbatas dan menghambat pelaksanaan proyek

Terjadi kerusakan perangkat Fisik Terjadi force majeur yang mengakibatkan kehancuran lokasi kerja/sistem

Komputer yang digunakan untuk pengembangan terkena virus / kehilangan data

Salah satu anggota tim pelaksana proyek membocorkan informasi rahasia kepada kompetitor

Implementasi Response Time dari sistem tidak


175 memenuhi harapan user Kebutuhan kapasitas sistem melebihi kapasitas yang tersedia saat ini

Sistem yang dideliver tidak mampu memenuhi kebutuhan fungsional yang diharapkan

Probabilitas dibuat dalam kategori High, Medium, dan Low Impact dibuat dalam kategori High, Medium, dan Low Tingkat Resiko dibuat dalam kategori Extreme, High, Medium, Low, Minimal.

Gunakan table berikut untuk melakukan kategorisasi resiko

Probability

Impact (time or Cost)

High Medium Low

High

Medium

Low

Extreme

High

Medium

High

Medium

Low

Medium

Low

Minimal


176 Lampiran 3 Dokumen Business Requirement Spesification

NAMA PROYEK : <SEBUTKAN NAMA PROYEK >

Versi

:

Tanggal

:

Disusun Oleh :


177 Disusun :

Nama

Tanggal : ____/___/____

:

Jabatan : Bagian :

( ____________________ )

Nama

Tanggal : ____/___/____

:

Jabatan : Bagian :

( ____________________ )

Review dan Persetujuan (User) Review

Nama

Tanggal : ____/___/____

:

Jabatan : Bagian :

( ____________________ )

Nama

Tanggal : ____/___/____

:

Jabatan : Bagian :

( ____________________ )

( TI dan Organisasi )

Persetujuan

Nama

:

Tanggal : ____/___/____

Jabatan : Bagian :

( ____________________ )

Nama

Tanggal : ____/___/____

:

Jabatan : Manager IT Bagian :

( ____________________ )

Nama

Tanggal : ____/___/____

:

Jabatan : General Manager IT Bagian :

( ____________________ )



Referensi Nama Dokumen

Penyusun

Versi




Project Plan


Nota Dinas / SK


*) dokumen yang direfernsikan disini minimal adalah FPPTI, Feasibility Analysis, PWS, dan Project Plan. Dokumen lain adalah dokumen pendukung yang menguatkan perencanaan proyek.

Histori Revisi Tanggal

Jun 2013

Versi

1.4

Catatan Revisi

Penambahan bagian 4.5 kebutuhan keamanan aplikasi

Penyusun

Suwarno Pribadi


179

BAB 1 Executive Summary Bagian ini berisi penjelasan singkat mengenai business requirement dari sistem yang akan dikembangkan. Pada awal pembentukan dokumen, biasanya bagian ini belum dapat dibuat dengan baik. Lengkapi bagian ini setelah bagian lain dokumen BRS ini selesai dibuat. Detil yang harus tercakup dalam bagian ini adalah : -

Fitur Umum yang disupport oleh sistem (lebih detil dari PWS) Batasan umum


180

BAB 2 Pendahuluan 2.1

Latar Belakang & Tujuan

Tuliskan latar belakang kebutuhan bisnis yang menjelaskan perlunya pelaksanaan/implementasi sistem TI terkait. Jelaskan pula tujuan, intended reader dan struktur umum pembahasan yang tercakup dalam dokumen BRS ini.

2.2

Ruang Lingkup

Tuliskan dampak yang diharapkan dari implementasi proyek terkait, termasuk juga dampaknya terhadap sistem eksisting.

2.3

Pengguna system

Sebutkan satu persatu business user yang akan menggunakan sistem terkait, dan lingkungan operasional yang akan mereka gunakan.

2.4

Tujuan Bisnis & Target

Jelaskan kepentingan tiap user terhadap sistem yang akan dikembangkan serta target implementasi untuk setiap user/fitur. Tuliskan dalam format berikut :

User

Tujuan

Tgl Kebutuhan

Tahapan

yang dimaksud dengan tahapan adalah jadwal perencanaan proyek dimana kebutuhan user sudah dapat dipenuhi (dimapping ke jadwal tahapan pelaksanaan proyek).

ASUMSI Sebutkan satu persatu asumsi yang digunakan dalam penyusunan business requirement ini sebutkan tanggal-tanggal penting (target peluncuran produk, dll)., volume transaksi, jumlah user, dan topologi jaringan yang digunakan. Nyatakan dalam bentuk tabel terstrukstur.

Sebutkan pula asumsi proses bisnis /aturan yang berpengaruh signifikan terhadap proses pelaksanaan proyek TI.


181

BAB 3 Fungsionality System Bagian ini merupakan inti dari dokumen Business Requirement Specification, yang berisi gambaran kebutuhan user secara detil, dan terkodifikasi untuk memudahkan cross reference pada dokumen lainnya. Hal-hal yang dicantumkan pada bagian ini akan dikembangkan ke level lebih detil dan lebih teknis pada dokumen Functional Requirement Specification. Bagian ini merupakan pengganti dokumen User Requirement Specification pada proses SDLC terdahulu.

3.1

Top Level Diagram

Gambarkan posisi sistem yang akan dibangun dalam peta aplikasi eksisting (IT Application Map Lintasarta). Gambarkan pula hubungan antar sistem dalam bentuk diagram.

3.2

Flow proses

Gambarkan proses-proses utama yang akan disupport oleh sistem (dalam bentuk Process Flow Diagram). Jelaskan secara detil user yang terlibat, dan beri kode. Process flow ini harus sesuai dengan Proses Bisnis baku yang berlaku kecuali jika memang prosedurnya belum ada.

Proses utama

Deskripsi

PJ

P01

3.3

Definisi proses

Dari kodifikasi proses diatas, tuliskan penjelasan dari setiap proses dalam bentuk use case diagram dan penjelasannya. Nyatakan secara jelas pelaku, invarian, pre-requisites, input yang diharapkan, output, dan kesepakatan format masukan/keluaran.

3.4

External Interfaces (optional)

Tuliskan semua pihak, bagian/divisi dan sistem lain yang terkait dengan implementasi proyek ini.


182

BAB 4 Lingkungan Operasional 4.1

Lingkungan User

Jelaskan lingkungan opearsoinal penguna dan performansi yang diharapkan dari sistem yang akan dibangun. Gambarkan pula tingkat kemahiran user yang diharapkan untuk dapat mengoperasikan sistem dengan baik. Lakukan identifikasi yang bertujuan untuk memudahkan proses desain, dan sesuai dengan tingkat pengalaman user, petugas operasional, dan proses pemeliharaan sistem.

4.2

Antar Muka

Jelaskan mengenai kebutuhan spesifik antarmuka penguna, filosofi antarmuka yang digunakan, sesuai dengan kebutuhan pengguna. (Misalnya penggunaan alat khusus seperti barcode, touch screen, OCR, dll). Sebutkan pula apabila dibutuhkan online-help, dan online training manual.

4.3

Pemeliharaan

Jelaskan kebutuhan untuk proses pemecahan masalah dan pencarian root cause.

4.4

Pertumbuhan dan kebutuhan mendatang

Jelaskan proyeksi pertumbuhan User, Data, Jumlah Transaksi, Kebutuhan Bandwidth, dan informasi lainnya terkait dengan perkembangan penggunaan sistem ini.

4.5

Kebutuhan Keamanan Aplikasi

Jelaskan standar sistem keamanan yang akan digunakan dalam implementasi sistem TI ini. Jelaskan kebutuhan keamanan aplikasi dari sudut pandang bisnis. Seperti : 1. Apakah ada data yang secara bisnis harus dilindungi, dan bagaimanan perlakuannya. 2. Regulasi dan kepatutan atas suatu standar tertentu yang harus dipenuhi. 3. Kebutuhan pemisahan pekerjaan (segregation of duty). 4. Identifikasi akan ancaman, peluang dan dampak atas kebutuhan keamanan aplikasi tersebut namun belum mengidentifikasikan kontrolnya (kontrol akan diidentifikasikan pada bagian FRS)


183 Lampiran 4 Dokumen Functional Requirement Spesification


Versi

:

Tanggal

:


184 Disusun :

Nama

Tanggal : ____/___/____

:

Jabatan : Bagian :

Nama

( ____________________ )

Tanggal : ____/___/____

:

Jabatan : Bagian :

( ____________________ )


Nama

:

Tanggal : ____/___/____

Jabatan : Bagian :

Nama

:

( ____________________ )

Tanggal : ____/___/____

Jabatan : Bagian :

Nama

:

( ____________________ )

Tanggal : ____/___/____

Jabatan : Bagian :

Nama

:

( ____________________ )

Tanggal : ____/___/____

Jabatan : Bagian :

( ____________________ )

( TI )

Persetujuan

Nama

:

Tanggal : ____/___/____

Jabatan : Bagian :

( ____________________ )


185 Nama

:

Tanggal : ____/___/____

Jabatan : Bagian :

Nama

:

( ____________________ )

Tanggal : ____/___/____

Jabatan : Bagian :

( ____________________ )




Versi

Penyusun




Project Plan



Nota Dinas / SK


*) dokumen yang direferensikan disini minimal adalah FPPTI, Feasibility Analysis, PWS, Project Plan dan Business Requirement Specification. Dokumen lain adalah dokumen pendukung yang dapat membangu proses analisis dan desain.

Revision History Date

Jun 2013

Version

1.4

Revision Notes

Author

Penambahan bagian 4.5 kebutuhan keamanan aplikasi

Suwarno Pribadi


187

Bab 1 Gambaran Sistem 1.1

Pendahuluan

Tuliskan dengan jelas dan tegas tujuan dari pembentukan dokumen FRS ini. Contohnya

“ Dokumen Functional Requirement Specification ini dibuat dengan tujuan agar pihak-pihak yang berkepentingan terhadap proyek ini dapat mengetahui dengan jelas rancangan sistem yang akan dibangun. Dokumen ini juga ditujuan sebagai kontrak antara Divisi IT dan Divisi/Bagian lain yang terkait tentang fitur-fitur yang akan diimplementasikan pada sistem. Diharapkan fungsionalitas yang dicantumkan pada dokumen ini tidak bersifat ambigu. Halhal yang tidak dicantumkan pada dokumen ini berarti tidak akan diimplementasikan pada sistem. “

Tuliskan pula pihak-pihak yang diharapkan membaca dokumen ini. Perlu diingat bahwa dokumen ini ditandatangani oleh user terkait.

1.2

Gambaran proyek

Tuliskan tujuan gambaran umum dari proyek (dapat diambl dari PWS)

1.3

Tujuan

Jelaskan keuntungan yang didapat dari pelaksanaan proyek ini (dapat diambil dari PWS).


188

BAB 2 Ruang Lingkup Fungsionalitas Cantumkan fungsionalitas yang termasuk dalam ruang lingkup sistem yang akan dikembangkan.

Batasan Cantumkan secara detil batasan-batasan yang diambil dalam pelaksanaan proyek ini, terutama. Kebutuhan yang mungkin diperlukan dikemudian hari, tetapi tidak termasuk dalam ruang lingkup sistem yang akan dikembangkan saat ini. - Proses bisnis/kebutuhan bisnis yang tidak termasuk ruang lingkup proyek ini. Cantumkan pula apabila ada variasi pada pendekatan yang diambil, jika dibandingkan dengan standar SDLC. -

User Daftar user dan tanggung jawabnya. Dan daftar seluruh user dari business unit yang terkait langsung pada implementasi proyek.

Implementasi Gambarkan arsitektur sistem yang akan dikembangkan.

Fungsi-fungsi utama Berisi tentang fungsi-fungsi atau modul yang akan dikembangkan pada sistem ini

Kode Fungsional Modul

Modul / Fungsi

Penjelasan

Kode Proses

F-01

Create trouble ticket

Mengakomodir Proses … , proses … dan ….

P.01, P.04

Flow Diagrams Context Diagram Gambarkan Context Diagram (DFD level 0) dari sistem yang akan dibangun, dan berikan penjelasan apabila diperlukan.


189 Data Flow Diagram - Top Level Data Flow Diagram - Detail Level 1

Process Definition untuk seluruh element dari fungsionalitas Tuliskan penjelasan detil dari DFD Detail Level 1 (bagian 2.5.3), serta cross referencenya dengan proses yang sudah didefinisikan pada Business Requirement Specification. Untuk setiap proses dilakukan identifikasi resiko konsistensi data. Untuk proses yang dinilai memiliki resiko konsistensi data, akan diberi identifikasi khusus, dan akan dijelaskan lebih detil pada dokumen DDS. Definisi Proses Jelaskan definisi proses DFD level 1 di disini Control Data Pada bagian ini dituliskan dalam bentuk tabel, proses-proses yang dinilai memiliki resiko konsistensi data. Setiap proses diberi kode kontrol data, dan akan dijelaskan mekanisme kontrolnya pada DDS.

Kode Proses

Nama Proses

P.01

Kode Control Data

Deskripsi

DC-01

Berisi rangkuman resiko inkonsistensi data dari proses yang terkait. Dituliskan dalam bentuk : Resiko : Control :

Data Definition dan analisa Tuliskan data dictionary, yang diambil dari data yang tertulis pada DFD. Data definition and analysis tidak dijabarkan dalam bentuk tabel fisik database/ER-D.

Laporan Dokumentasi seluruh laporan termasuk frekuensi, tipe dan daftar distribusi yang dibutuhkan oleh system


190

Dokumentasi Daftar seluruh dokumen yang dibutuhkan yang tidak secara spesifik disebutkan dalam metodologi SDLC..


191

BAB 3 Kebutuhan Operasional Tuliskan secara mendetil pada bagian ini tentang spesifikasi antarmuka yang digunakan dan tingkat performansi yang diharapkan, dalam bentuk yang lebih detil dari penjelasan yang ada pada BRS, dengan memuat mapping ke fungsional fitur.

3.1.

Kemudahan penggunaan

Berisi pendetilan dari item yang sama pada BRS

3.2.

Performansi and Reliability

Berisi pendetilan dari dari item yang sama pada BRS

3.3.

Capacity


3.4.



3.5.

Kebutuhan keamanan Aplikasi

Berisi pendetilan dari dari item yang sama pada BRS, dan pada standar security Lintasarta. Serta kebutuhan keamanan yang sifatnya fungsional, seperti identifikasi site page yang perlu identifikasi, otentikasi dan otorisasi atau bersifat public anonym. Mengidentifikasikan secara lebih detil antara ancaman, risiko dan kontrol yang ada saat ini serta gap analysisnya. Mengidentifikasikan secara detil kebutuhan keamanan untuk fungsi : 1. Manajemen User 2. Otentikasi dan Otorisasi modul user 3. Penanganan data rahasia (bila ada)

BAB 4 Strategi implementasi Tuliskan secara jelas mengenai kebutuhan pada saat implementasi sistem nantinya, termasuk didalmnya informasi mengenai -

Migrasi Konsep implementas (pararel run, cut off) Instalasi Client / Instalasi Software Pendukung Integrasi dengan sistem eksisting Instalasi Terminal Server Contigency plan bila terjadi masalah


192 LAMPIRAN 4 Dokumen Functional Requirement Spesification


Versi

:

Tanggal

:


Disusun :

Nama

:

Tanggal : ____/___/____

Jabatan : Bagian :

( ____________________ )


Nama

:

Tanggal : ____/___/____

Jabatan : Bagian :

Nama

( ____________________ )

Tanggal : ____/___/____

:

Jabatan : Bagian :

( ____________________ )

( TI )

Persetujuan

Nama

:

Tanggal : ____/___/____

Jabatan : Bagian :

Nama

( ____________________ )

Tanggal : ____/___/____

:


Nama

( ____________________ )

:

Tanggal : ____/___/____


( ____________________ )

193



194

Pendahuluan Jelaskan pada bagian ini tujuan dari penulisan dokumen ini, dan pihak yang diharapkan membaca dokumen ini. Tuliskan dalam satu paragraf singkat (5-8 baris).


Versi

Penyusun




Project Plan



Nota Dinas / SK


*) dokumen yang direferensikan disini minimal adalah FPPTI, Feasibility Analysis, PWS, Project Plan dan Business Requirement Specification. Dokumen lain adalah dokumen pendukung yang dapat membangu proses analisis dan desain.

Revision History Date

Version

Revision Notes


Author

195

Bab 1 Gambaran Sistem 1.4

Pendahuluan

Tuliskan dengan jelas dan tegas tujuan dari pembentukan dokumen FRS ini. Contohnya

“ Dokumen Functional Requirement Specification ini dibuat dengan tujuan agar pihakpihak yang berkepentingan terhadap proyek ini dapat mengetahui dengan jelas rancangan sistem yang akan dibangun. Dokumen ini juga ditujuan sebagai kontrak antara Divisi IT dan Divisi/Bagian lain yang terkait tentang fitur-fitur yang akan diimplementasikan pada sistem. Diharapkan fungsionalitas yang dicantumkan pada dokumen ini tidak bersifat ambigu. Hal-hal yang tidak dicantumkan pada dokumen ini berarti tidak akan diimplementasikan pada sistem. “

Tuliskan pula pihak-pihak yang diharapkan membaca dokumen ini. Perlu diingat bahwa dokumen ini ditandatangani oleh user terkait.

1.5

Gambaran proyek

Tuliskan tujuan gambaran umum dari proyek (dapat diambl dari PWS)

1.6

Tujuan

Jelaskan keuntungan yang didapat dari pelaksanaan proyek ini (dapat diambil dari PWS).


196

BAB 2 Ruang Lingkup Fungsionalitas Cantumkan fungsionalitas yang termasuk dalam ruang lingkup sistem yang akan dikembangkan.

Batasan Cantumkan secara detil batasan-batasan yang diambil dalam pelaksanaan proyek ini, terutama. Kebutuhan yang mungkin diperlukan dikemudian hari, tetapi tidak termasuk dalam ruang lingkup sistem yang akan dikembangkan saat ini. - Proses bisnis/kebutuhan bisnis yang tidak termasuk ruang lingkup proyek ini. Cantumkan pula apabila ada variasi pada pendekatan yang diambil, jika dibandingkan dengan standar SDLC. -

User Daftar user dan tanggung jawabnya. Dan daftar seluruh user dari business unit yang terkait langsung pada implementasi proyek.

Implementasi Gambarkan arsitektur sistem yang akan dikembangkan.

Fungsi-fungsi utama Berisi tentang fungsi-fungsi atau modul yang akan dikembangkan pada sistem ini

Kode Fungsional Modul

Modul / Fungsi

Penjelasan

Kode Proses

F-01

Create trouble ticket

Mengakomodir Proses … , proses … dan ….

P.01, P.04

Flow Diagrams Context Diagram Gambarkan Context Diagram (DFD level 0) dari sistem yang akan dibangun, dan berikan penjelasan apabila diperlukan.


197

Data Flow Diagram - Top Level Data Flow Diagram - Detail Level 1

Process Definition untuk seluruh element dari fungsionalitas Tuliskan penjelasan detil dari DFD Detail Level 1 (bagian 2.5.3), serta cross referencenya dengan proses yang sudah didefinisikan pada Business Requirement Specification. Untuk setiap proses dilakukan identifikasi resiko konsistensi data. Untuk proses yang dinilai memiliki resiko konsistensi data, akan diberi identifikasi khusus, dan akan dijelaskan lebih detil pada dokumen DDS. Definisi Proses Jelaskan definisi proses DFD level 1 di disini Control Data Pada bagian ini dituliskan dalam bentuk tabel, proses-proses yang dinilai memiliki resiko konsistensi data. Setiap proses diberi kode kontrol data, dan akan dijelaskan mekanisme kontrolnya pada DDS.

Kode Proses

Nama Proses

P.01

Kode Control Data

Deskripsi

DC-01

Berisi rangkuman resiko inkonsistensi data dari proses yang terkait. Dituliskan dalam bentuk : Resiko : Control :

Data Definition dan analisa Tuliskan data dictionary, yang diambil dari data yang tertulis pada DFD. Data definition and analysis tidak dijabarkan dalam bentuk tabel fisik database/ER-D.

Laporan Dokumentasi seluruh laporan termasuk frekuensi, tipe dan daftar distribusi yang dibutuhkan oleh system


198

Dokumentasi Daftar seluruh dokumen yang dibutuhkan yang tidak secara spesifik disebutkan dalam metodologi SDLC..

BAB 3 Kebutuhan Operasional Tuliskan secara mendetil pada bagian ini tentang spesifikasi antarmuka yang digunakan dan tingkat performansi yang diharapkan, dalam bentuk yang lebih detil dari penjelasan yang ada pada BRS, dengan memuat mapping ke fungsional fitur.

3.6.

Kemudahan penggunaan

Berisi pendetilan dari item yang sama pada BRS

3.7.

Performansi and Reliability


3.8.

Capacity


3.9.



3.10. Kebutuhan keamanan Aplikasi Berisi pendetilan dari dari item yang sama pada BRS, dan pada standar security Lintasarta. Serta kebutuhan keamanan yang sifatnya fungsional, seperti identifikasi site page yang perlu identifikasi, otentikasi dan otorisasi atau bersifat public anonym. Mengidentifikasikan secara lebih detil antara ancaman, risiko dan kontrol yang ada saat ini serta gap analysisnya. Mengidentifikasikan secara detil kebutuhan keamanan untuk fungsi : 4. Manajemen User 5. Otentikasi dan Otorisasi modul user 6. Penanganan data rahasia (bila ada)

BAB 4 Strategi implementasi Tuliskan secara jelas mengenai kebutuhan pada saat implementasi sistem nantinya, termasuk didalmnya informasi mengenai -

Migrasi Konsep implementas (pararel run, cut off) Instalasi Client / Instalasi Software Pendukung Integrasi dengan sistem eksisting Instalasi Terminal Server

LAMPIRAN 5


199

Dokumen Design Detil Spesification


Versi

:

Tanggal

:


200

Disusun :

Nama

Tanggal : ____/___/____

:

Jabatan : Bagian :

Nama

( ____________________ )

:

Tanggal : ____/___/____

Jabatan : Bagian :

( ____________________ )

Review dan Persetujuan ( User dan Operasi TI ) Review

Nama

Tanggal : ____/___/____

:

Jabatan : Bagian :

Nama

( ____________________ )

Tanggal : ____/___/____

:

Jabatan : Bagian :

( ____________________ )

( TI )

Persetujuan

Nama

Tanggal : ____/___/____

:


Nama

( ____________________ )

:

Tanggal : ____/___/____


( ____________________ )


201

Pendahuluan Jelaskan pada bagian ini tujuan dari penulisan dokumen ini, dan pihak yang diharapkan membaca dokumen ini. Tuliskan dalam satu paragraf singkat (5-8 baris).

Referensi Versi

Nama Dokumen

Penyusun




Project Plan


Nota Dinas / SK


*) dokumen yang direfernsikan disini minimal adalah FPPTI, Feasibility Analysis, PWS, dan Project Plan. Dokumen lain adalah dokumen pendukung yang menguatkan perencanaan proyek.

History Revisi Tanggal

Jun 2013

Catatan Revisi

Versi

1.4

Penambahan bagian 5.6 Security Control Aplikasi

Pada bagian ini dijelaskan secara khusus disain untuk control aplikasi seperti yaitu : -

-

-

Management User (pendaftaran dan hak akses user) Log Aplikasi (mekanisme logging setiap akses yang dilakukan oleh user) Pendetilan kebutuhan keamanan sesuai dokumen BRS dan FRS menjadi level disain.


Penyusun

Suwarno Pribadi

202

BAB 1

Pendahuluan

Latar Belakang & Tujuan Tuliskan latar belakang kebutuhan bisnis yang menjelaskan perlunya pelaksanaan/implementasi sistem TI terkait. Jelaskan pula tujuan, intended reader dan struktur umum pembahasan yang tercakup dalam dokumen DDS ini.

Ruang Lingkup Tuliskan ruang lingkup pembahasan dari dokumen ini. Cantumkan keterangan apabila dokumen ini merupakan bagian dari set dokumen yang lain (Contoh: Dokumen design dipisahkan untuk tiap modul utama dari aplikasi).

User Sebutkan satu persatu business user yang akan menggunakan sistem terkait, dan lingkungan operasional yang akan mereka gunakan.

Referensi Sebutkan satu persatu referensi yang dikunakan dalam penyusunan dokumen ini. Cantumkan pula apabila ada penggunaan istilah-istilah khusus, ataupun istilah umum yang bermakna ganda.

Methodologi, Tool dan Teknik Khusus (Optional) Jelaskan Metodologi / Software Tools / Teknik Khusus, yang digunakan dalam melakukan penyusunan dokumen DDS ini. Cantumkan pula hal-hal yang perlu diperhatikan apabila dikemudian hari akan dilakukan perubahan teknis terhadap dokumen ini.

Kebijakan dan Prosedur (Optional) Jelaskan aturan / prosedur yang dianut dalam penyusunan dokumen DDS ini. Tuliskan juga apabila ada batasan-batasan khusus yang harus diikuti dalam penyusunan dokumen.

BAB 2 Penjelasan Design 2.1.

Latar Belakang

Jelaskan latar belakang yang relevan dengan desain yang dibuat dalam dokumen ini

2.2.

Penjelasan Sistem Migrasi

Jelaskan langkah-langkah yang harus dijalankan dalam proses migrasi dari sistem eksisting ke sistem yang sedang di kembangkan.

2.3.

Gambaran sistem aplikasi (termasuk Proses saat ini dan rencana)

Jelaskan mengenai gambaran sistem yang akan dikembangkan, setelah dilakukan analisa terhadap kebutuhan sistem.


203

2.4.

Asumsi

Tuliskan asumsi-asumsi yang diambil dalam melakukan proses desain

Table 1 Asumsi-asumsi

No

Asumsi

2.5.

Aturan/Kesepakatan (Optional)

Dampak

Tuliskan aturan/kesepakatan yang mempengaruhi proses desain secara keseluruhan.

Table 2 Ketergantungan

No

Ketergantungan

Tindak Lanjut


204

BAB 3 Ruang Lingkup 3.1.

Harapan user & Performansi sistem

Tuliskan hasil yang diharapkan uleh user dengan adanya implementasi sistem. Tuliskan pula ukuran performansi sistem yang diharapkan.

3.2.

Ketergantungan dg sistem eksternal dg (optional)

Tuliskan dalam bentuk tabel ketergantungan sistem yang sedang dikembangkan, dengan sistem lainnya (eksisting maupun parallel development).

Table 3 Ketergantungan dengan sistem eksternal

No

Sistem Eksternal

Ketergantungan


205

BAB 4 Disain Sistem Bagian ini merupakan inti dari dokumen Detail Design Specification. Fokus penjelasan pada bagian ini adalah arsitektur sistem dan interaksinya dengan sistem lain

4.1.

Arsitektur

4.1.1. Sistem Arsitektur Gambarkan secara detail desain arsitektur sistem yang digunakan, termasuk juga konfigurasi hardware/software, data access, network access dan hubungan dengan aplikasi lain. Jika memungkinkan, digambarkan dalam satu gambaran umum, yang kemudian didetilkan lagi dalam beberapa gambaran sub arsitektur sistem. Jika diperlukan, jelaskan arsitektur sistem dalam beberapa sudut pandang yang relevan. 4.1.2. Alternatif Jelaskan alternatif arsitektur sistem yang telah dipertimbangkan, beserta analisa terhadap tiap alternatif. 4.1.3. Interaksi Tuliskan komponen-komponen utama dalam sistem, dan interaksi yang terjadi antar komponen tersebut.

4.2.

Sistem Antarmuka (Internal System Interface)

Pada bagian ini tuliskan : -

4.3.

Gambaran antarmuka yang digunakan oleh sistem untuk berinterkasi dengan sistem lain. Penjelasan rinci mengenai Service (Function, Method, dll) , Tipe/Format Data, exceptions, aturan yang digunakan untuk tiap interface

External System Interface

Pada bagian ini tuliskan : -

Gambaran antarmuka yang digunakan oleh sistem lain untuk berinterkasi dengan ini. Penjelasan rinci mengenai Service (Function, Method, dll) , Tipe/Format Data, exceptions, aturan yang digunakan untuk tiap interface


206

BAB 5 Desain Detil Bagian ini merupakan penjelasan detail dari dokumen desain, dengan fokus penjelasan pada cara kerja internal sistem. Penjelasan mengenai bagian-bagian sistem harus tetap selaras dengan desain arsitektur sistem.

5.1.

Fungsionalitas Modul

Pada bagian ini : -

Gambarkan fungsionalitas modul Tuliskan pembagian modul/sub modul berdasarkan kelompok fungsinya, dalam bentuk tabular

. Tabel 4 Pembagian Fungsional Modul

Kode

Modul

Proses

F.01

Identifikasi

P.01

F.02

Create Ticket

P.01, P.02

F.03

Dispatch

P.01

5.2.

Pembagian Modul

Control Data

Deskripsi

DC-01, DC02

Tuliskan pembagian modul secara fisik. Yang dimaksud sebagai fisik modul disini adalah implementasi fisik dari modul, dapat berupa file, database package, dll. Dituliskan dalam bentuk tabel dengan kolom: Sub Aplikasi, Modul, Nama File, Functional Module.

Tabel 5 Pembagian fisik modul

Kode

Sub Aplikasi / Modul

M.01

Modul Aduan (Helpdesk)

Nama File

Fungsionalitas modul

F.01 ,F.02, F03


207

5.3.

Penjelasan Detil modul

Deskripsi detail agar modul dapat diprogram. Dibuat sesuai dengan jenis proses. Jika perlu, dilengkapi dengan algoritma atau pernyataan SQL-like (untuk aplikasi berbasis data). Algoritma yang ditulis harus cukup jelas untuk dapat diprogram, tetapi bukan merupakan kode program. Yang penting, dengan rancangan ini, kode program dapat dibuat. Pada bagian ini dituliskan dan dijelaskan ER Diagram per modul untuk modul yang sederhana, atau dibuat per layar pada bagian 5.3.1 jika modul tersebut sangat kompleks.

5.3.1.

Deskripsi layar / layout

Sketsa layar dilengkapi dengan objek-objek yang didalamnya. Awali dengan Daftar Layar, dan kemudian penjelasan detail dari tiap layar. Table 6 Daftar Layar

Kode

Modul

Nama layar

Layar 1 Nama Layar

Insert Screen Design Here

Deskripsi Object : Kode

Nama Obyek

Tipe

Desripsi


208

Algoritma : Tuliskan algoritma/lojik yang harus dibuat terkait dengan interaksi dengan layar 5.3.2.

Deskripsi proses

Berisi penjelasan untuk proses-proses yang tidak mengandung interaksi. Awali dengan Daftar Proses yang akan dibuat detilnya, kemudian jelaskan secara detail tiap-tiap proses Tabel 7 Daftar Proses

Kode

Modul

Nama Proses

Proses 1 Nama Proses Name :

Descriptio n:

Input Data :

Field Name

Data Type & Size

Description

Outout Data :

Field Name

Data Type & Size

Description


209

Algoritma :

Proses 2 Nama Proses Name :

Descriptio n:

Input Data :

Field Name

Data Type & Size

Description

Outout Data :

Field Name

Data Type & Size

Description

Algoritma :

5.3.3.

Deskripsi laporan

Untuk Modul yang berisi laporan, berisi detail tentang Layout Laporan, Deskripsi Masukan, dan Algoritma Pembentukan Laporan.


210

5.4.

Control Data

Pada bagian ini dituliskan penjelasan detail dari setiap proses yang memiliki resiko inkonsistensi data. 5.4.1.

DC-xxx..n

Deskripsi

Kode :

DC-XXXX

Persyaratan Valid

Mekanisme Pengecekan & Deteksi

Pencatatan Insiden

Proses Penanganan Insiden

5.5.

Deskripsi data

Pada bagian ini -

-

Name :

Tuliskan spesifikasi data (table, views, snapshots, dll) yang digunakan. Spesifikasi meliputi Nama, Jenis, Perkiraan Volume Data ,Perkiraan Laju Pertumbuhan Data, Constraint Integrity, Primary Key. Spesifikasi dapat berupa script dump dari database

Type :

Primary Key :

Constraint :

Volume :

Growth:


211

Descriptio n:

5.6.

Field Name

Data Type & Size

Description

Security Control Aplikasi

Pada bagian ini dijelaskan secara khusus disain untuk control aplikasi seperti yaitu : -

Management User (pendaftaran dan hak akses user) Log Aplikasi (mekanisme logging setiap akses yang dilakukan oleh user) Pendetilan kebutuhan keamanan sesuai dokumen BRS dan FRS menjadi level disain.


212

6. Disain lain yang dibutuhkan 6.1.

Modul konversi (Optional)

Gambarkan program yang digunakan untuk import, convert atau migrasi data.

6.2. Archive and Purge Modules (Optional) Jelaskan apabila ada fungsi-fungsi khusus, seperti purge atau archiving.

6.3 Disain Backup dan Recovery (Optional) Jelaskan proses backup dan restore data apabila ada kerusakan / kehilangan data.

6.4. Security Jelaskan security yang digunakan, misalnya bila menggunakan NT, jelaskan IIS security, Secure Socket Layers, etc. if applicable. Jelaskan mekanisme management akses user.

6.5.

Batch Jobs (Optional)

Jelaskan bila ada job yang digunakan untuk Describe any jobs that will run regularly to perform batch based commands.

6.6.

Performance dan Response Time

Jelaskan bagaimana melakukan disain agar response tim lebih baik. Termasuk penggunaan Store Prosedure, de-normalisasi data (jika ada), konfiruasi server (size, memory, etc), teknik programming, penggunaan tools database sepert SQL Oracle Explain plain dan SQL Server show Plan..

6.7.

Ketergantungan pada Platform tertentu dan Instalasi

Jelaskan instalasi/setup proses dimana user harus menggunakan platform tertentu seperti (Windows 98, XP, NT dll)..

6.8.

Deskripsi lokasi / waktu

Jelaskan tentang lokasi dan format tgl/jam (mis DD/MM/YYYY) yang digunakan.

6.9.

Modul/program Lain (optional)

Jelaskan macam2 modul/program lain yang terkait dengan pengembangan sistem ini

6.10. Lisensi Jelaskan lisensi yang digunakan pada system/program aplikasi.


LAMPIRAN 5 : Diagram Prosedur Pengembangan Aplikasi Lintasarta

213



214



User

IT Operations

PERMINTAAN DAN PENGADAAN SOFTWARE IT Development

215


216


217

Nama Dokumen :Diagram Prosedur Permintaan Pengadaaan Software Kode Dokumen

21.User Requirement A

:DP-LAP-S2-ITS-006

22. Menentukan pelaksana pekerjaan

Versi Dokumen : 1.0

Halaman / Jumlah Halaman : 1 / 5

Tanggal Berlaku : 03 Mei 2012

Label : Internal

D

IT Operations

QC BAUTS

BAOS

23.Analisa kebutuhan user & Desain

24. Pengembangan Software (konstruksi)

25.Testing & QC

26. Implementasi

25.Testing & QC

26. Implementasi

27.Evaluasi

Risalah Review Konstruksi Software

Other Department

PERMINTAAN DAN PENGADAAN SOFTWARE

Dilakukan internal

21.User Requirement


218


UNIVERSITAS INDONESIA PERANCANGAN PEDOMAN KEAMANAN PENGEMBANGAN APLIKASI : STUDI KASUS PT. APLIKANUSA LINTASARTA KARYA AKHIR

Recommend Documents