Alexandra Svatikova bekerja sebagai pakar keamanan informasi di Odnoklassniki. Lebih dari 8 tahun yang lalu, ia beralih dari pengembangan di Jawa ke pengujian keamanan aplikasi.
Kami mewawancarainya di tempat kami berdiskusi:
- Apakah sulit bagi pengembang untuk beralih ke analisis aplikasi?
- perbedaan dalam kinerja pentester, peneliti dan analis;
- siklus hidup pengembangan keamanan atau SDLC;
- peran manusia dalam pencarian kerentanan;
- bagaimana dengan analisis keamanan di perusahaan lain.
Tidak akan ada hardcore dalam artikel ini - Anda dapat mengikutinya ke Heisenbug 2019 Moskow , di mana Alexandra akan berbicara tentang pengujian keamanan statis. Kami akan pergi ke laporannya di akhir pos, tetapi untuk sekarang, selamat datang di cat.
Masuk ke keamanan aplikasi tidak sesulit kedengarannya
"Untuk siapa kamu belajar?" Mengapa Anda terlibat dalam keamanan aplikasi?
- Saya mungkin bukan contoh untuk diikuti (tertawa) . Saya belajar sebagai programmer, dan sesuatu seperti "rekayasa perangkat lunak" ditulis dalam diploma. Dulu bekerja sebagai pengembang seluler, lalu beralih ke pengembangan web di Jawa. Setelah menemukan pekerjaan lain sebagai programmer Java, saya masuk ke tim yang berurusan dengan keamanan aplikasi - menjaga bagian keamanan terkait pengembangan. Ada proses yang terorganisir dengan baik, diformulasikan, dan mereka membutuhkan orang untuk melakukan tinjauan kode dan analisis statis. Oleh karena itu, mereka mencari programmer Java dan siap untuk mengajarinya keamanan. Tampaknya menarik bagi saya, jadi saya tetap tinggal.
- Apa yang Anda pikirkan, akankah Anda tinggal di daerah ini untuk waktu yang lama, atau akankah sesuatu mengikuti tahap ini lebih jauh?
- Saya pikir saya akan tinggal selamanya, karena saya telah menjadi analis keamanan aplikasi sejak 2011. Saya sudah memiliki pengalaman pengembangan yang kurang, ternyata. Programmer tidak boleh takut pada tugas rutin, memperbaiki bug, tetapi spesialis keamanan memiliki kekhususan yang berbeda, itu lebih menarik saya.
- Area tambahan apa yang dibandingkan dengan pengembangan konvensional yang harus Anda kuasai?
- Di awal karir saya, saya sedang menguji. Ini mengatur otak Anda dengan baik: Anda melihat sistem dalam bentuk bukan sekelompok kode, tetapi suatu organisme, yang dapat dipengaruhi dengan berbagai cara. Jadi penguji dan pengembang memiliki perbedaan dalam berpikir.
Sebagai contoh, 10-15 tahun yang lalu, diyakini bahwa penguji harus merusak sistem dan menemukan bug dengan cara apa pun. Profesional keamanan terkadang perlu memiliki sudut pandang yang sama. Jadi, Anda perlu memahami cara kerja sistem secara keseluruhan.
Beberapa pengembang terpaku pada detail: mereka tahu bagaimana bagian dari sistem bekerja, tetapi mereka tidak mengerti bagaimana semua itu berinteraksi. Misalnya, dia tahu bagaimana JS dijalankan di browser, tetapi pengembang tidak tahu bagaimana browser ini bekerja lebih jauh dan berkomunikasi dengan server, mengapa ini diatur seperti ini. Penguji harus melihat dari pandangan mata burung untuk menilai interkoneksi komponen, perubahan lemah atau kerentanan.
- Dan sesuatu rekayasa, misalnya, tumpukan jaringan, Anda harus belajar dari awal? Misalnya, bagaimana cara kerja JS, front, backing?
- Pada prinsipnya, saya sudah menjadi pengembang tumpukan penuh, jadi saya mengerti cara kerja backend dan frontend. Anda harus memiliki pandangan tertentu, tetapi memperdalam detail sudah tergantung pada apa yang Anda lakukan. Pengembang dan penguji yang sama, tergantung pada proyeknya, mengetahui beberapa hal sistem (misalnya, protokol jaringan) atau tahu lebih banyak tentang frontend. Itu tergantung keadaan.
- Seberapa realistiskah bagi Anda bahwa pengembang full-stack abstrak atau tester full-stack, yang terlibat dalam pemrograman, otomatisasi dan pengujian, akan pergi ke analisis aplikasi, yaitu, apa yang Anda lakukan?
- Mudah untuk tester. Pastikan Anda memiliki keterampilan pemrograman dan pahami bagaimana sistem dibangun dari dalam. Tapi tester yang bagus tanpa ini tidak ada lagi. Jika ini masalahnya, maka muncul pertanyaan tentang spesialisasi: dia perlu membaca tentang keamanan dan teknologi tertentu (misalnya, Android atau dukungan), yaitu, apa yang dia coba temukan kerentanannya.
Pengembang melihat partisipasi mereka dalam proses sedikit berbeda. Karena itu, bagi pengembang ini adalah revolusi, pandangan yang berbeda pada profesi. Penting bagi pengembang untuk melakukan sesuatu, tetapi akan sulit baginya untuk istirahat.
Pentester, pengamat, dan analis keamanan aplikasi: apa bedanya
- Seperti yang saya pahami, spesialisasi Anda terkait dengan pentester. Bagaimana perbandingan pentester dan peneliti kerentanan nol hari, atau apakah itu semua dicampur menjadi satu botol dan apakah benar-benar sulit untuk mengetahui siapa itu siapa?
- Tidak ada pembagian yang jelas ke dalam tulisan. Tapi saya akan memberi tahu Anda istilah apa yang digunakan partai.
Ada pengintai yang meneliti suatu produk, teknologi, protokol, server dalam upaya untuk menemukan masalah yang menarik. Menarik mengacu pada masalah yang sebelumnya tidak ditemukan, atau diidentifikasi di tempat yang tidak terduga, atau merupakan kombinasi kompleks dari masalah yang diketahui sebelumnya. Saya dapat mengatakan bahwa sebagai aturan, semua jenis kerentanan 0day ditemukan oleh pengintai.
Pentest adalah layanan. Anda memiliki sistem dan Anda ingin menemukan kerentanan. Tugas pentester adalah menembus sistem. Mereka tidak akan dapat menemukan semua masalah potensial. Misalnya, kerentanan dapat dikurangi dengan mekanisme keamanan lain di tingkat yang berbeda. Pentester akan mencari apa yang sebenarnya dieksploitasi, dan setelah itu akan mengeluarkan laporan dan pergi, karena ia tidak memiliki tugas untuk meningkatkan keamanan sistem atau menyiapkan proses pengembangan.
Ada juga keamanan aplikasi atau analitik keamanan produk. Sebaliknya, mereka melihat sistem dari dalam. Tugas mereka adalah membuat sistem aman. Ini berarti bahwa mereka memiliki informasi tentang sistem, dan itu bukan "kotak hitam" bagi mereka. Di sisi lain, mereka memberi peringkat masalah secara berbeda. Analis bahkan mempertimbangkan kerentanan yang tidak dapat dieksploitasi saat ini. Misalnya, ada lubang kritis di panel admin, dan jelas bahwa itu hanya dapat diakses dari jaringan internal, dan karena itu tidak terlalu menakutkan. Tetapi orang dalam memahami bahwa dalam keadaan tertentu hal yang mengerikan dapat terjadi.
Analis lebih fokus pada mendukung proses. Jika pentester menemukan 20 bug dan pergi, dan pengembang dalam proses memperbaiki bug melakukan hal yang sama, maka pentester tidak akan membantu di sini. Oleh karena itu, memahami jumlah kerentanan dalam sistem hanya akan relevan pada saat itu.
- Lalu analis keamanan aplikasi melakukan ini dalam proses, hari demi hari?
- Ya, dan pada saat yang sama, aktivitas diarahkan dalam dua arah. Di satu sisi, Anda perlu mencari kerentanan yang ada dan memerangi mereka. Di sisi lain, ada tugas untuk membuat sistem lebih aman.
Ini dapat didekati dengan berbagai cara. Misalnya, bangun proses pengembangan sehingga ada lebih sedikit kesalahan atau mereka cepat terdeteksi. Atau menerapkan mekanisme yang akan mengurangi risiko bahwa kerentanan akan jatuh ke dalam produksi. Ada beberapa cara untuk memastikan keamanan sistem.
- Jadi, pekerjaan analisis keamanan aplikasi terkait erat dengan tim dan proses pengembangan di dalam?
- Ya, seorang analis keamanan aplikasi harus mengajukan pertanyaan tentang proses pengembangan. SDLC (Secure Development LifeCycle) adalah kata kunci pertama yang ditemukan ketika membaca tentang keamanan aplikasi. Singkatnya, tujuan dari tindakan ini adalah untuk memastikan bahwa pertimbangan keamanan sistem diperhitungkan pada setiap tahap pengembangan. Dalam hal ini, tidak selalu spesialis keamanan yang terlibat dalam pelaksanaan tugas tertentu, kadang-kadang Anda dapat mendelegasikan ke anggota tim lainnya. Lagi pula, semakin cepat Anda menemukan masalah, semakin murah untuk memperbaikinya.
Pikiran manusia masih sangat diperlukan dalam menemukan kerentanan
- Masalah dengan produk dapat ditemukan pada tingkat spesifikasi, diskusi, prototipe, sketsa, ketika tidak ada satu baris kode pun. Tetapi masalah keamanan pada tahap apa yang memungkinkan untuk ditemukan? Dan mungkinkah menemukannya bahkan sebelum menulis kode?
- Tentu saja, karena ada masalah yang berkaitan langsung dengan bagaimana persyaratan dirumuskan. Biarkan saya memberi Anda contoh liar. Anda membuat formulir login, dan perancang memberi tahu Anda: "mari beri tahu pengguna kami bahwa mereka tidak hanya memasukkan kata sandi yang salah, tetapi mereka membuat kesalahan dalam huruf terakhir kata sandi mereka." Artinya, kata-kata dari persyaratan mungkin secara inheren tidak aman.
Juga, pada tahap TK, dapat diasumsikan bahwa sistem akan tunduk pada kerentanan tertentu, dan beberapa mekanisme perlindungan harus diterapkan. Jika Anda menggunakan formulir yang sama di situs, Anda harus membuat captcha untuk mencegah tebakan kata sandi. Oleh karena itu, poin-poin tersebut harus disebutkan dalam pengembangan arsitektur.
- Seberapa sering pengujian keamanan tertanam dalam proses CI / CD, dan apakah ini sulit? Yaitu, untuk dapat "menghancurkan" setiap pipa di Jenkins atau TeamCity, dan ada tahap terpisah di mana tes keamanan dijalankan. Seberapa nyata itu?
- Ada pedoman tentang SDLC yang sama, ada persyaratan regulator. Dengan demikian, perusahaan yang memiliki proses pengembangan yang matang mengimplementasikannya. Ada alat untuk mengotomatisasi bagian dari proses, tetapi rasio upaya dan hasilnya tergantung pada sifat proyek dan pada tahap pengembangan apa teknik ini mulai diterapkan.
Jika aplikasi ditulis dari awal, maka Anda dapat menawarkan untuk menggunakan analisa statis untuk menghindari instruksi yang meragukan dalam kode. Dan jika 10 tahun sebelum Anda menulis kode, dan Anda datang ke sana dengan alat Anda untuk uang gila, maka, tentu saja, Anda akan menemukan sedikit.
Semua alat otomatis memiliki masalah yang tidak mereka ketahui bagaimana sistem bekerja. Jika komponen individual dari sistem dapat diisolasi, maka dapat diuji dengan alat yang sudah jadi. Tetapi dalam sistem dengan banyak ketergantungan, pemindai otomatis dapat kehilangan informasi berharga.
Analisis keamanan di perusahaan lain
- Perusahaan mana atau proyek individu mana, menurut Anda, yang merupakan unggulan dalam analisis keamanan aplikasi, berdasarkan pidato perusahaan dan presentasi konferensi?
- Microsoft datang dengan implementasi SDLC, yang menjadi kanon. Tapi begini cara mereka bekerja di level terendah, alat apa yang digunakan, saya tidak tahu.
Facebook banyak menulis tentang bagaimana semuanya diatur secara teknis: bagaimana mereka memindai kode, menemukan kerentanan dalam sistem kerja, dll. Beberapa alat Facebook bahkan merupakan proyek sumber terbuka, sehingga Anda dapat menggali lebih dalam isi perutnya.
Jika kita mengambil perusahaan Rusia, maka Sberbank dengan menarik berbicara tentang bagaimana mereka meresmikan SDLC, mendokumentasikan prosesnya. Meskipun tim keamanan aplikasi mereka agak besar, itu tidak cukup untuk banyak pengembang. Oleh karena itu, mereka mendidik juara keamanan dalam tim, menaruh pengetahuan tentang keamanan di kepala mereka, dan dalam hal ini juara dapat mengibarkan bendera merah.
Yandex berbicara di konferensi tentang hal-hal keren seperti "cara meretas browser."
- Apakah realistis bahwa penguji setelah konferensi, di mana ia mendengar laporan tentang ancaman dan alat, akan mendapatkan efek signifikan setelah penerapannya? Misalnya, perusahaan akan membeli pemindai seharga $ 10.000 yang mencari lubang di pipa Jenkins. Atau apakah lebih penting untuk mengetahui mekanisme mengeksploitasi kerentanan untuk mengimplementasikan beberapa hal?
- Anda tidak dapat membeli pemindai seharga 10 ribu dolar (tertawa) . Jika kita berbicara tentang pencarian kerentanan, maka turun ke pengujian skenario tertentu. Skenario diambil dari koleksi pengetahuan umum.
Misalnya, OWASP (Proyek Keamanan Aplikasi Web Terbuka) menerbitkan panduan tentang cara melakukan pengujian keamanan, ulasan kode, dll. Misalnya, dalam Standar Verifikasi Keamanan Aplikasi OWASP ada tertulis tentang semua yang perlu diuji. Untuk membaca dokumen, tidak diperlukan pengetahuan khusus, cukup untuk mengetahui tentang aplikasi web, sehingga setiap penguji dapat mengatasinya.
Lembar standar dan cheat sudah cukup untuk menjalankan tes manual. Dikatakan jenis kerentanan apa yang ada dan bagaimana mencarinya. Beberapa pengujian tidak dapat dilakukan oleh pemindai standar dengan definisi: misalnya, yang terkait dengan pemeriksaan logika bisnis.
Di sisi lain, jika Anda perlu menemukan XSS, maka Anda perlu menambahkan tanda kutip, braket, dll di setiap parameter yang diubah. Dan jika ada 100 juta parameter dalam sistem, maka tugas tidak lagi layak. Tetapi alat otomatis akan baik-baik saja dengannya.
Tetapi ketika Anda memulai pemindai, mungkin ada tiga skenario:
- Alat ini mengeluarkan laporan di mana ada banyak bug yang dapat direproduksi dengan baik dan sedikit false positive (ideal, tetapi tidak mungkin).
- Laporan itu berisi 20 ribu temuan, yang sekitar 1% benar. Karena itu, Anda harus duduk dan menentukan apakah masalah sebenarnya.
- Alat tidak dapat memahami sesuatu dalam sistem, oleh karena itu, mengeluarkan laporan di mana semuanya baik-baik saja, tetapi tidak. Misalnya, saya tidak dapat mengkompilasi kode karena saya tidak dapat menemukan perpustakaan. Atau pemindai kerentanan yang membuat 10 permintaan, mengalami anti-banjir, dan tidak menerima respons dari server untuk jutaan permintaan lainnya.
Oleh karena itu, saya pikir penting untuk memahami bahwa pemindai “di bawah tenda” untuk memilih alat yang sesuai dengan tugas yang sedang diselesaikan dan mengevaluasi hasilnya secara memadai.
Alexander akan mengembangkan topik pilihan yang tepat dan penyetelan alat dalam laporannya tentang Heisenbug. Di sana dia akan berbicara tentang aplikasi dan kustomisasi SAST-solusi SonarQube dan Find Security Bugs untuk mencari kerentanan dalam proyeknya. Fitur apa yang disediakan alat ini “di luar kotak”? Dan bagaimana cara memperluas fungsi mereka sendiri? Sebagai contoh, pembicara akan mempertimbangkan kerentanan XSS dan IDOR.
Konferensi akan diadakan 5-6 Desember di Moskow.