Integrasi Aspek Keamanan dalam RPL

Berikut adalah beberapa usulan untuk mengintegrasikan kebutuhan keamanan dengan proses pengembangan perangkat lunak.
1. Menyatukan aspek keamanan dengan rekayasa sistem
Pada saat sistem analis menganalisis dan mendesain sistem, analis keamanan harus mengembangkan desain keamanan. Untuk selanjutnya sumber daya yang ada dibangun dengan kombinasi desain sistem dengan desain keamanan.
2. Menyatukan aspek keamanan dengan system requirement
Ketika kebutuhan keamanan dipertimbangkan selama daur hidup pengembangan sistem, maka hal menjadi cenderung pada penentuan daftar keamanan sistem seperti manajemen password, firewall, pendeteksian virus dsb. Padahal hal ini bukan merupakan kebutuhan keamanan tapi merupakan mekanisme implementasi yang digunakan untuk memenuhi kebutuhan keamanan secara implisit, misalnya untuk pembatasan akses. Hasilnya adalah, kebutuhan keamanan yang khusus untuk sistem dan perlindungan terhadap suatu layanan dan sumber daya seringkali dilupakan. Sebagai tambahan, perspektif penyerang tidak dipertimbangkan. Untuk itu diperlukan pendekatan sistematik dalam manajemen kebutuhan keamanan akan mencegah permasalahan daftar keamanan sistem dan mengubahnya pada perspektif penyerang.
Program CERT pada Software Engineering Institute's telah mengembangkan sebuah metodologi untuk membangun keamanan sejak awal pada daur hidup pengembangan sistem yang disebut Security Quality Requirements Engineering (SQUARE).
Hasil analisis kebutuhan melalui metodologi SQUARE dengan menganalisis komponen fungsionalitas keamanan yang dideskripsikan pada CC part 2 digunakan sebagai dasar untuk membuat SFR ( Security Functional Requirement ) sebagai pelengkap SRS( Software Requirement Specification ). SFR yang merupakan bagian dari Protection Profile merupakan Security target yang menggambarkan kebutuhan pengguna dalam aspek keamanan.
3. Menyatukan aspek keamanan dengan model sistem
Pengembang perangkat lunak menggunakan model sejak proses awal siklus pengembangan software untuk meningkatkan kualitas artifact dokumen requirement. Kecenderungan yang ada adalah menggunakan model berorientasi obyek ( UML ). Salah satu riset yang dilakukan oleh komunitas software dan keamanan adalah mengadopsi dan mengembangkan standar, misalnya : UML untuk memodelkan fitur keamanan seperti privacy, integrity, access control dsb. Keuntungan yang bisa didapatkan adalah : 1 ) Menyatukan desain sistem dan kebijakan keamanan, 2) Modularitas ( melalui encapsulation) dan reuse ( melalui pewarisan ) dalam representasi kebijakan, 3) Mengembangkan tool standar saat ini untuk aktivits analisis dan desain( forward engineering ) sebagaimana analisis legacy systems( reverse engineering ).
Tantangan utama adalah mengembangkan sintaks dan semantik standar seperti UML untuk menangani permasalah keamanan. Riset untuk mengembangkan tools dan proses untuk menyatukan desain sistem dan kebijakan keamanan dipercayai mampu menghasilkan sistem yang lebih efektif memenuhi kebutuhan pengguna dan aman.
4. Menyatukan aspek keamanan dengan desain sistem
Desain system dilakukan dengan dua pendekatan, yakni : 1) Penggunaan Security Design Pattern, 2) Penggunaan Aspect Oriented Programming( AOP ).
• Penggunaan Security Design Pattern
Design pattern merupakan suatu cara untuk mengidentifikasi dan memberikan solusi terhadap permasalahan desain yang berulang-ulang terjadi pada pemrograman berorientasi obyek. Joseph Yoder and Jeffrey Barcalow adalah yang pertama kali mengadaptasi pendekatan design pattern pada pemgembangan perangkat lunak. Format yang digunakan adalah template design pattern yang dibuat oleh Gang of Four. Berikut adalah security design pattern : 1) Single Access Point : menyediakan sebuah modul keamanan dan satu cara untuk log in ke dalam sistem, 2) Check Point : manajemen pemeriksaan keamanan, 3) Roles : manajemen penggunan dengan security privileges, 4) Session : lokalisasi informasi global pada lingkungan banyak pengguna, 5) Full View with Errors: penyediaan sebuah view penuh kepada pengguna dan menampilkan exceptions ketika diperlukan, 6) Limited View : hanya memperbolehkan pengguna untuk melihat apa yang diperbolehkan untuk mereka, 7) Secure Access Layer: mengintegrasikan keamanan aplikasi dengan keamanan level yang lebih rendah( missal : jaringan ).
Sangat dimungkinkan di kemudian hari untuk menambah katalog security design pattern seiring dengan berkembangnya kesadaran akan integrasi aspek keamanan pada desain perangkat lunak.
• Penggunaan Aspect Oriented Programming( AOP )
Penggunaan aspect-oriented programming dapat digunakan untuk memisahkan permasalahan keamanan dalam sistem yang kompleks. Ide aspect-oriented programming adalah beberapa aspek dari kode secara alami adalah modular, seperti penyimpanan data yang dapat ditempatkan dalam basis data.

Sementara yang lain( biasanya non fungsionalitas ) seperti performansi tersebar( scattered ) pada kode. Dengan memisahkan kode yang tersebar dengan cara mengkodingkan dan mengisolasi terpusat dalam aspect-aspect maka memudahkan dalam manajemen kode ( aspect ) dan pengembangan sistem.

5. Menyatukan aspek keamanan dengan pengujian sistem
Pengujian aspek keamanan menggunakan EAL sesuai dengan tingkat EAL yang diterapkan dalam pembangunan perangkat lunak. Secara teknis, dapat digunakan pendekatan pengujian unit secara otomatis dengan menggunakan framework N-unit testing.

Catatan :
CC : Common Criteria, merupakan salah satu standar aspek keamanan dalam produk TI

Framework Design Guidelines

Sumber : diskusi milist RPL-IF IT Telkom oleh Yudi Maryanto :

Ada beberapa panduan bagus dalam medesain framework di buku Framework Design Guidelines:
1.Gunakan Aggregate Component untuk menyederhanakan public interface pada skenario yang paling sering digunakan.

2. Pegang teguh prinsip "Make the top scenarios easy and the rest is possible". Jadi meskipun public interface kita sederhana untuk skenario yang paling umum, developer yang butuh skenario yang lebih rumit bisa mengeksplore lebih jauh framework kita.

3. Usahakan framework yang kita buat bersifat "Self Documenting". Pada skenario yang paling umum, usahakan developer tidak perlu melihat dokumentasi untuk melakukannya. Hal ini bisa dicapai dengan penamaan kelas dan method yang intuitif.

4. Buat framework kita konsisten sehingga jika developer telah menguasai sebagian framework kita, pengetahuan tersebut tetap bisa dipakai dalam mempelajari bagian lain dari framework kita.

5. Usahakan jangan mengekspose design pattern untuk public interface pada skenario yang paling umum. Konsep-konsep OOAD, design pattern, dll cocok diterapkan untuk detail implementasi framework kita tapi kurang cocok untuk public interface karena cenderun akan memperumit interface yang pada akhirnya akan membuat frustasi developer.

UML : state of the art

Dalam pengembangan perangkat lunak digunakan pemodelan perangkat lunak sejak requirement sampai testing. Saat ini standar pemodelan yang banyak digunakan adalah UML seiring dengan banyak digunakan pendekatan berorientasi obyek dalam pambuatan perangkat lunak.

Namun UML dipandang masih mempunyai kekurangan karena masih terdapatnya kekurangan dalam meng-generate kode program secara komplit. Kenapa hal ini terjadi? Dalam analisis yang saya coba lakukan, hal ini karena kurangnya cara memodelkan aspek kelakuan internal perangkat lunak untuk dipetakan ke dalam kode program. Seperti yang kita ketahui, diagram UML yang dapat menghasilkan kode hanyalah diagram class, namun itupun hanya baru sebatas kerangka kodennya saja dan tidak bisa meng-generate badan program-nya.

Untuk itu diperlukan cara dalam memodelkan pengembangan perangkat lunak yang memungkinkan dihasilkannya kode program secara komplit.

Bersambung......

UML : state of the art

Dalam pengembangan perangkat lunak digunakan pemodelan perangkat lunak sejak requirement sampai testing. Saat ini standar pemodelan yang banyak digunakan adalah UML seiring dengan banyak digunakan pendekatan berorientasi obyek dalam pambuatan perangkat lunak.

Namun UML dipandang masih mempunyai kekurangan karena masih terdapatnya kekurangan dalam meng-generate kode program secara komplit. Kenapa hal ini terjadi? Dalam analisis yang saya coba lakukan, hal ini karena kurangnya cara memodelkan aspek kelakuan internal perangkat lunak untuk dipetakan ke dalam kode program. Seperti yang kita ketahui, diagram UML yang dapat menghasilkan kode hanyalah diagram class, namun itupun hanya baru sebatas kerangka kodennya saja dan tidak bisa meng-generate badan program-nya.

Untuk itu diperlukan cara dalam memodelkan pengembangan perangkat lunak yang memungkinkan dihasilkannya kode program secara komplit.

Bersambung......

Pabrik Software

Istilah ini tidak lazim. Namun bukan berarti tidak ada. Istilah di dunia software-nya adalah : Software Product Line atau Software Factory.

Kenapa istilah ini tidak lazim? Karena sampai saat ini pembuatan software secara luas bukanlah suatu hasil proses pabrikasi. Apa maksudnya? Bagaimana dgn 'product' suatu software house, misalnya?

Satu jawaban singkat, karakteristik dan prosesnyalah yg mrpkan pembedanya.

More, but to be continued

Berbedalah

Bismillah,
Aktivitas dlm kehidupan yg lalu, sekarang dan yang datang.
Dari yg gitu-gitu, selalu saja. Sampai dengan luar biasa dan sepanjang masa.
Terus apa bedanya? Padahal khan, ama Allah sudah dikasih kesempatan yang sama. Mesti ada sesuatu yang membikin beda. Apa ya?
Mimpi = visi & misi
Strategi & Taktik
Kebiasaan
Yuk, mulailah dengan membedakan!
Jangan sampai merugi.

Always blogging?

Sangat sulit utk menulis blog scr kontinyu. Jika tidak karena kesibukan, maka komitmen adalah yg mjd ganjalan.

Sebetulnya menulis blog adl mudah, jadikan ia sebagaimana kebutuhan berkomunikasi spt halnya : email dan sms. Dan sbtulnya emang mudah karena ada PDA. Intinya adl : stay connected!

Code generator

Ide untuk menghasilkan code tanpa harus menulis code sudah banyak dan beberapa sudah terwujud. Untuk ini kita bisa melihat pencapaian Model Driven Architecture dan juga pendekatan Generative Programming.

Namun permasalah dalam dua pendekatan diatas adalah masih adanya kendala kompleksitas sistem yang akan diubah menjadi kode dan kemudahan dalam pemakaian tools.

Hal ini sudah sering kita jumpai dan tergambar dalam penggunaan tools yang menawarkan konsep wizards dibandingkan dengan menulis kode dari awal. Keduanya mempunyai kelebihan dan kekurangannya.

Terakhir, masih terdapat beberapa tema yang terbuka dalam Code Generator yang masih dapat dikembangkan dan ditemukan.

2 suggestion learning english

2 suggestion learning english :
1. Reading and speaking loudly english writing
2. Writing your idea in english
1st suggestion to make we speak fluently.
2nd suggestion to apply english grammar

thanks for miss Flo

Most valuable asset in 21st century

is knowledge and educated worker.
According to Peter Drucker, Management Challenger for the 21th Century : "Knowledge have become asset for economic development, replacing unchangable resource nature. Because unchangable source nature can be depreciated, indeed they can result nature destruction that can ended in man suffering".

Above opinion is interesting, because in October 2007, Forbes mag release American richest people, Bill Gates is first, Larry Ellison is 4th. And in top 10, there was change that in 5th position, Google founder, Sergey Brin and Larry Page enter in the list. This change have change paradigm that richest man is not only mining, automotive and conventional people.

Knowledge have become non phisically renewable resource. IT people use knowledge smartly as renewable resource.

All above is quoted from Kompas in October 2007.

Finally evidence show that people knowledge is the most valuable asset.

state : try to write

I'm back

Ya, saya putusin untuk kembali menulis blog
Tadinya saya berpikir menulis blog akan menyita tenaga, waktu dan pikiran
Tapi saya sadari saya salah
Berikut beberapa alasannya :
1. Anda adalah apa yang anda tulis, jadi kalo ndak pernah nulis, anda bukan apa-apa di dunia maya
2. Tidak harus panjang, RSS mengajarkan hal ini, lebih dari RSS adalah cara pemberitaan http://slashdot.org/
3. Membikin ciri tema dalam penulisan

So, i decide to choose software engineering matters in my writing

See you in my next writing

IT, good or bad thing?

Well,
IT sudah mengubah segalanya.
Salah satu yang mau saya sorotin adalah secara pribadi [ not perusahaan, negara etc ]kita termasuk yang mengambil keuntungan atau malah rugi?
Saya akan membahas berdasar prinsip-prinsip yang saya ketahui tentang IT :

1. Prinsip eksistensi
Mau ndak mau jika anda setidaknya membaca blogger ini maka anda pengguna IT yang aktif. Tahukah anda, ada study yang mengatakan bahwa di dunia maya, eksistensi anda ditunjukkan oleh tulisan anda, email anda dan sejenisnya?

2. Tools
Saya tidak tahu anda menggunakan IT untuk apa? Kerja? Study? Have Fun? Apapun itu saya akan mengatakan IT adalah tool yang selalu saja mempunyai dua sisi. Good side and Bad side. How many times you take benefit from it?

3. Information age
Masa revolusi industri yang ditandai dengan eksplorasi alam telah berganti dengan eksplorasi terhadap informasi, harus kita sadari bahwa informasi menentukan jalannya pekerjaan sehari, menjadi senjata strategis dalam persaingan dan bahkan memanipulasi kehidupan.

Tema yang berat, sudah ah...
Terakhir...
I hope that information can become wise knowledge.
I hope that all people in the earth can access information equally.

Kerendahan hati profesi

It's all about emotional thing, tentang gengsi
Sometimes dalam profesi qta, qta merasa yang paling hebat dan tentu saja paling benar
Namun apakah seperti itu?

Saya dalam profesi IT merasa yang paling benar
Melupakan basic condition, yaitu qta adalah manusia
Ya, manusia adalah tempatnya sombong dan juga kekurangan menyatu

Kadang kita merasa software, desain, argumen qta yang paling benar
Tapi qta lupa, mungkin masih ada bug...
Mungkin masih ada requirement dan pertimbangan desain yang belum kita capture
Dan mungkin saja kita salah menggunakan teori dalam argumen kita

lastly, to wrong is human nature
ya kita mentoleransi kesalahan ( mau dibaca kemungkinan kesalahan dan kekurangan juga boleh )
tapi, kita tetap profesional dan kritis dan mau belajar terus

Selamat menerima kenyataan
Terus belajar

Dan have a nice weekend

IT Governance

Sebetulnya pengen nulis juga mengenai Software Engineering, behind the scene, but keingatan oleh Handi yang pernah bertanya ttg IT Gov, ya udah sekarang bahas dulu IT Gov.

Dalam perkuliahan S2 di Dep. EL or IF ITB marak dilakukan pembahasan or kajian mengenai IT Governance, yang in Indonesian is Tata Kelola TI.
Apa itu Tata Kelola TI?

Well akan lebih menjelaskan melihat definisi dari Cotrol, yakni : "The Policies, Procedures, Practices and Organizational Structures, Designed to Provide Reasonable Assurance that Business Objectives will be Achieved and that Undesired Events will be Prevented or Detected or Corrected " [ taken from Cobit Document ].

Dan diakhiri dengan definisi IT Control Objective : '" A Statement of the desired result or purpose to be achieved by implementing control procedure in a particular IT activity".

Nah kurang lebih IT Gov itu sebagai Framework suatu organisasi yang activity-nya didukung oleh oleh TI agar efektif dan efisien ( bayangin investasi TI yang dikeluarin dan resiko-nya!!! ).

Sebetulnya masih kurang, tapi diasumsikan yang baca orang IT, jadi bisa googling sendiri dengan keyword : IT Governance, Cobit dan sejenisnya.


BAB IV Analisa :)
Apa pentingnya kita tahu IT Gov ( kalo gak tahu berarti kita kurang komprehensif dalam memandang dunia IT )?
1. Bahwasanya dunia TI, itu bukan hanya semata aplikasi doang, namun ada yang namanya Sistem Informasi or ada yang nyebut Teknologi Informasi
2. Aplikasi itu hidup untuk mendukung suatu proses bisnis, so kita harus aware terhadap hubungan antara IT dan bisnis
3. Agar harmonis maka IT dan bisnis harus align atau selaras atau harmonis
4. Dan agar langgeng maka hubungan IT yang mendukung bisnis itu harus ada kontrol or kendali

BAB V Simpulan dan Saran
Simpulan :: Alangkah anehnya kalo kit dipimpin oleh orang yang tidak ngerti TI secara komprehensif [ asumsi pekerjaan anda di bidang TI ]. Kalo mo yang lebih dramatis lagi adalah, alangkah super aneh kalo anda dipimpin oleh orang yang tidak sekolah TI.

Saran :: Mungkin saja saya salah dalam mengambil Simpulan :)

the return [ CMM ]

Well, it've been a year when i last write blog.
Akhir-akhir ini saya teringat atas konsep yang dikemukan oleh seorang psikolog bahwa salah satu cara untuk melepaskan beban adalah dengan menuliskan atau bercerita dengan orang lain. And i choose 2nd option to write, i can take advantage to exercise writing too.

Coz i teach Software Engineering, many of my writing will be influenced by my knowledge in SE, it's funny when knowing that many thing i can use on my understanding in SE.

Sebagai salah satu contohnya adalah bagaimana kita dapat mengambil pelajaran dari SW Process ( Capabality Maturity Model ). Can u image that life is like software, it's complicated and full of uncertain thing ( including risk, quality etc ).

Based on CMM, there are 5 level of maturity, from :
1. non existent
2. initial/ad hoc
3. repeatable but intuitive
4. defined process\4. managed and measurable
5. optimised
So where are u in?

In SE, process define quality. In life, i think the same.....

Dana

World is flat

Rabu, 13 Juli yang lalu ada seminar khusus dosen STT di Jur. IF
Pengisi adalah Sigit P. Jarot dari Nokia Jepang, pakar CDMA, orang Indo yang s1, s2, s3 dan kerja di Jepang.

Selalu aja ada yang menarik ndengerin orang2 kayak gini ngomong ( ntar Agustus ada Iko atau Ino, org Indo Phd, juga yang kerja di NTT yang akan ngomongin soal Data Mining ).

Karena kebetulan yang hadir banyakan orang Industri dan IF, dosen EL-nya cuman satu, jadi materi yang dibawakan lebih kaya nuansa Teknologi Informasinya.

Temanya adalah The World is Flat, sebuah buku karangan Thomas L. Friedman.
( url : www.thomaslfriedman.com/worldisflat.htm ). Diterangkan bahwa terdapat 10 hal yang mempengaruhi globalisasi, a.l : runtuhnya tembok berlin, go publicnya Netscape/browser, informing ( googling ), out source, offshore, open source, work flow, supply chain, in source dan ada yang lupa.

Kurang lebih dengan globalisasi, kita sebagai bangsa Indonesia dengan kekurangan yang ada harusnya dapat mengambil manfaat, karena dengan kompetisi yang global, ndak peduli orang Jepang, India, China, Amrik atau Eropa asalkan kita dapat bersaing maka kita sejajar dengan mereka.

Dan jangan anti dengan globalisasi ( tentu saja yang jelek2 kita ndak setuju, misalnya : perdagangan bebas yang merugikan posisi Indonesia ), karena globalisasi kayaknya bakalan akan jalan, ntah kita setuju or not, dan kita bersaing or not?

The World is flat, tahu sendiri khan, tentu saja hal ini dimungkinkan karena TI dan Telekomunikasi.

Teori2 :
1. Telekomunikasi mengarah ke : mobility, broadband, kecepatan
2. Kenapa kita makai 3g atau 4g ( ngimpi kali yeeee :) : kata mas Sigit sih, karena sifat telekomunikasi yang natural, maka 3g atau 4g nantinya akan menjawab sifat natural dalam berkomunikasi, pakai video dsb.

Terakhir, asyik juga ya kerja di lembaga riset, karena selain kita tetap belajar kita juga belajar teknologi baru.

Second system effect != chaos

Sangat menarik untuk mengaitkan antara kehidupan dengan engineering/science bahkan software engineering ataupun computer science termasuk dalam hal ini.

Second system effect adalah salah satu essay dari Mythical Man Month. Secara garis besar second system effect berkaitan dengan permasalahan dengan pengembangan dari sistem yang sudah ada, miriplah dengan pembuatan versi baru.

Hal tersebut tentu bermasalah karena selain mempertimbangkan system lama,timbul masalah berkaitan dengan mentalitas yang ada yang merasa bahwa ahli yang ada sudah berpengalaman, namun perlu diingat bahwa sistem baru bukanlah sistem lama, namun sistem yang comply dengan sistem lama namun mempunyai kompleksitas yang lebih.

Kalau kita lihat demikian juga dengan kehidupan, setiap rangkain kejadian dapat kita tarik benang merah dengan masa lampau namun perubahan itu harus terjadi, tentu saja untuk kemajuan...

To wrong is human's nature

Untuk itulah manusia diberi kesempatan...
Untuk memperbaiki kesalahan...
Dan juga untuk menabung dan berperilaku dalam mencegah kesalahan...

Kesempatan selalu datang untuk memperbaiki
Namun tidaklah mudah, kadang-kadang untuk memperbaiki
Karena apa yang akan kita lakukan sangat dipengaruhi oleh pemahaman dan apa yang kita lakukan...

Ibaratnya seorang pendekar, maka refleknya adalah jurus
Jurus adalah denyut napasnya...

Ya Allah berilah hamba pemahaman dan amal yang continue...

Trigered by some event and accident had happened this day, Tuesday, June 28th 2005

The Mythical Man-Month

Apaan tuh?
Itu adalah buku yang berisi essay tentang Software Engineering yang dikarang oleh Frederick P. Brooks, JR.

Di kelas Proyek RPL semester genap 2004/2005 sudah dipresentasikan bab 1 s.d. 6 dari 19 bab yang ada Anniversary Edition ( per 1995 buku ini dah anniversay ke-20 th ). Buku ini ( dan bab yang ada di dalamnya ) dinobatkan sebagai salah satu buku yang berpengaruh terhadap Computer Science.

Kayaknya kehidupan buku ini berisi pengalaman, kegagalan dan lesson learned dari pengarang buku ini agar proyek manajemen RPL di kemudian hari dapat mengambil pelajaran dari buku ini.

Kutipan dari wikipedia ( http://en.wikipedia.org/wiki/The_Mythical_Man-Month ) ::
Many software professionals have lamented the fact that 30 years after the book's first publication they are still working on projects whose managers are still making the mistakes that Brooks identifies. When challenged with this in 2004, Brooks stated with characteristic modest humour: "They call this book the Bible of Software Engineering... and that's because everybody reads it but nobody does anything about it!" :::

Untuk pertama kali

Terinspirasi oleh Awan, my eks pal at STT Telkom...
Padahal sudah sejak dari dulu tahu ada blogger,
anyway gak ada kata terlambat untuk memulai yang baik...

Well, setelah lulus s1 dan bekerja, aku hampir menganggap CS ( computer science ) is hanya gitu-gitu aja, analisaku karena aku terjebak dalam rutinitas kerjaan kantor...

Trus aku mutusin kembali ke kampus untuk menjadi dosen.
Since than, my way to see CS was turn 180*...
Karena harus belajar dan semakin lama aku belajar dan mendalami suatu obyek, i see thing that i think i want to see it before, well my journey rebegin again...

Aku melihat seni dalam CS sedikit demi sedikit....