Loncat ke konten utama
Kembali ke Blog

Perspektif Industri

Berfokus pada Orang yang Tepat

10 November 2022

Oleh Jim Beno - Direktur Pengalaman Pengguna, Skyhigh Security

Sebagai perusahaan keamanan, pengguna produk kami biasanya bekerja di organisasi Keamanan Informasi (InfoSec). Namun, semakin lama, kami menemukan bahwa fitur-fitur Security Service Edge (SSE) kami menargetkan pengguna di luar tim keamanan: sebagian besar di bidang Teknologi Informasi (TI), tetapi juga di bidang Teknik/Operasi. Mereka adalah orang-orang yang mengembangkan dan menerapkan aplikasi di cloud, mengontrol akses ke aplikasi tersebut, dan memastikan kinerja jaringan.

Setidaknya ada empat alur kerja atau fitur utama SSE yang menargetkan peran di luar organisasi keamanan:

  • Memberikan Akses ke Aplikasi - Ketika perusahaan mengalihkan lebih banyak infrastruktur mereka ke cloud publik, mereka perlu mengontrol akses ke aplikasi yang dihosting di sana. Solusi Zero Trust Network Access (ZTNA) kami menyediakan kemampuan ini. Mengelola kebijakan akses ini, dan menanggapi permintaan akses dari karyawan, bukanlah tugas dari Security Operations Center (SOC). Ini adalah tanggung jawab yang dimiliki oleh TI dan Help Desk TI.
  • Mengelola Kebijakan Firewall - Dengan semua infrastruktur ini di cloud publik, untuk keamanan, perusahaan perlu mengontrol akses tidak hanya dengan menentukan "siapa" yang dapat menggunakan aplikasi ini - tetapi juga "bagaimana" - rincian protokol, port, perangkat, lokasi, dan lain-lain.
  • Pemantauan Pengalaman Digital - Dengan lokasi kantor yang tersebar di seluruh dunia dan banyak orang yang bekerja dari rumah, tidak dapat dipungkiri bahwa beberapa karyawan akan mengalami masalah dalam mengakses aplikasi atau layanan. Mengidentifikasi cakupan dan sumber masalah ini bisa menjadi mimpi buruk. Saat panggilan Help Desk TI masuk, tim keamanan tidak akan mengangkat telepon.
  • Memperbaiki Kesalahan Konfigurasi & Kerentanan - Di dalam IT dan Teknik, berbagai tim mungkin membangun aplikasi di Amazon Web Services (AWS), Google Cloud Platform (GCP), atau Microsoft Azure. Tugas kami adalah membantu perusahaan mengamankan aplikasi ini, baik Arsitek TI yang bertanggung jawab atas infrastruktur cloud mereka, pemilik akun yang mengembangkan dan mengonfigurasi aplikasi, atau personel DevOps / DevSecOps yang menerapkannya. Jika kami mendeteksi kerentanan atau kesalahan konfigurasi, tim keamanan tidak memiliki "kunci kastil" untuk memperbaikinya - kami harus menyampaikan masalah ini kepada pemilik TI atau Teknik yang dapat membuat perubahan.

Menciptakan Persona

Di Skyhigh Security, kami memiliki peneliti pengguna yang berdedikasi yang bertugas untuk memahami pelanggan dan menghasilkan wawasan yang menginformasikan persyaratan dan desain produk. Untuk setiap kemampuan produk baru, kami perlu memastikan bahwa kami menargetkan pengguna yang tepat, dan mempelajari semua yang kami bisa tentang mereka: Apa yang memotivasi mereka? Tugas apa yang mereka lakukan? Aplikasi atau sistem apa yang mereka gunakan? Bagaimana mereka berkolaborasi dengan orang lain? Apa masalah utama mereka?

Kami mulai dengan mengajukan pertanyaan-pertanyaan ini kepada anggota tim internal dalam manajemen produk dan penjualan. Kami akan sering mengadakan sesi kerja dan mencatat pengetahuan kolektif kami di papan tulis virtual. Setelah kami mengetahui peran pekerjaan apa yang akan ditargetkan, kami akan mewawancarai pelanggan dan mengamati bagaimana mereka bekerja. Setelah beberapa sesi ini, beberapa tema umum akan mulai muncul. Kami kemudian mensintesis semua wawasan dengan menciptakan karakter fiksi - "persona" - yang menjadi titik fokus untuk menulis kasus penggunaan dan desain.

Memperkenalkan Fred dan Kawika

Akhir-akhir ini, para peneliti kami telah menyelidiki dua persona baru yang bertanggung jawab atas pemantauan pengalaman digital dan kebijakan firewall: "Fred" yang bekerja di bagian Help Desk TI, dan "Kawika", Admin Jaringan. Berikut adalah beberapa wawasan yang kami pelajari dari duo dinamis ini:

  • Kawika bertanggung jawab atas kinerja jaringan. Ketika semuanya berjalan dengan baik, hidup terasa menyenangkan. Namun ketika terjadi masalah, dia harus meninggalkan semuanya dan langsung bertindak. Untuk menghindari hal ini, dia ingin secara proaktif memantau aplikasi penting di jaringan - dia tidak bisa menunggu banyak tiket masalah masuk.
  • Serupa dengan SOC, TI memiliki tingkatan yang berbeda untuk menangani masalah dukungan. Ketika seorang karyawan mengalami masalah saat mengakses aplikasi, mereka akan membuka tiket yang ditangani oleh meja bantuan TI. Ini berarti Fred akan menjadi orang pertama yang akan menyelidiki masalah tersebut. Dia memiliki buku pedoman untuk memandunya dalam memecahkan masalah. Jika terlihat seperti masalah jaringan, maka dia akan meneruskannya ke tim Jaringan. Sekarang giliran Kawika.
  • Mendiagnosis masalah jaringan tidaklah mudah. Arsitektur jaringan sangat kompleks. Ketika mengakses layanan cloud, lalu lintas dari perangkat karyawan melintasi banyak jaringan yang berbeda. Ada banyak variabel yang bisa memengaruhi performa, dan kondisinya bisa berubah seiring waktu. Untuk menyelidiki masalah ini, Kawika harus menggunakan banyak alat dan konsol untuk mendapatkan informasi yang dibutuhkannya.
Lembar data persona untuk Kawika, Admin Jaringan

Menghindari Ambiguitas

Semua wawasan ini dirangkum dalam lembar data satu halaman yang kami buat untuk Fred, Kawika, dan rekan-rekan mereka. Kami juga mengadakan sesi pelatihan untuk memperkenalkan persona kepada tim lintas fungsi. Ketika kami mendengar manajer produk dan teknisi menyebut nama persona, kami tahu bahwa kami telah melakukan pekerjaan kami!

Setiap alur desain UX di Figma dimulai dengan artboard yang menunjukkan persona target dan kasus penggunaan. Dengan cara ini, semua orang berada di halaman yang sama dan kita menghindari referensi yang ambigu untuk "admin" atau "arsitek keamanan". Jika kita sedang meninjau desain dan seseorang mempertanyakan persona target, itu bagus! Kami menyambut baik diskusi itu. Faktanya, itulah bagaimana Fred dan Kawika muncul.

Tidak ada yang lebih buruk daripada merancang dan membangun fitur baru, hanya untuk mengetahui setelah fitur tersebut dirilis bahwa asumsi Anda tentang target pengguna salah. Hal ini dapat memiliki implikasi yang signifikan pada alur kerja dan memerlukan perombakan total. Jauh lebih baik berinvestasi dalam riset pengguna di awal untuk memvalidasi asumsi Anda, dan memastikan Anda tepat sasaran.

Kembali ke Blog