Membangun Program Keamanan dari Nol

Dipekerjakan sebagai orang pertama di bidang keamanan di sebuah perusahaan adalah jenis chaos yang spesifik. Tidak ada antrian ticket, tidak ada tooling yang sudah ditetapkan, dan biasanya tidak ada lini anggaran yang menunggu Anda. Berikut adalah peta kasar tentang bagaimana 90-180 hari pertama biasanya berjalan, dan apa yang benar-benar menggerakkan jarum versus apa yang hanya terasa produktif.

Apa yang "tidak ada" biasanya berarti

Ketika orang mengatakan perusahaan tidak memiliki fungsi keamanan, mereka jarang berarti zero controls. Mereka berarti tidak ada dedicated owner. Engineering mungkin telah mengaktifkan beberapa kebijakan AWS IAM dasar, IT memiliki beberapa antivirus yang di-roll out melalui MDM tool, dan seseorang di finance memiliki pendapat tentang SOC 2 karena seorang customer menanyakannya. Pekerjaan pertama Anda adalah inventory, bukan implementation. Sebelum menulis satu kebijakan pun, cari tahu apa yang sudah berjalan: cloud accounts (dan berapa banyak yang tidak ada orang yang ingat pernah membuat), SaaS tools dengan admin access ke source code, dan apakah ada single source of truth untuk employee offboarding. Spreadsheet baik-baik saja untuk ini. Platform GRC bukan prioritas saat ini.

30 hari pertama: visibility daripada control

Tahan keinginan untuk menulis acceptable use policy di minggu pertama. Tidak ada orang yang akan membacanya dan itu tidak akan menghentikan risiko yang sebenarnya. Sebagai gantinya, dapatkan visibility ke dalam tiga hal:

• Identity: tarik daftar pengguna lengkap dari identity provider Anda (Okta, Google Workspace, Azure AD) dan cross-reference terhadap daftar active employee dari HR. Anda akan menemukan ghost accounts.
• Cloud footprint: jalankan sesuatu seperti aws organizations list-accounts jika Anda menggunakan AWS, atau periksa GCP's Asset Inventory, untuk melihat berapa banyak environments yang ada versus berapa banyak yang dapat diingat siapa pun dari memori.
• Code dan secrets exposure: jalankan gitleaks detect atau trufflehog filesystem . terhadap repo utama Anda. Menemukan hardcoded API key dalam commit history dari dua tahun lalu hampir dijamin dan itu adalah cara cepat untuk menunjukkan value.

Dokumentasikan temuan, tetapi jangan ubah ini menjadi laporan 40 halaman yang tidak ada orang buka. Ringkasan risiko satu halaman dengan lima bullet points dibaca oleh CTO. PDF panjang tidak.

Memilih tiga control pertama Anda

Dengan tidak ada headcount dan tidak ada budget tooling, Anda tidak dapat melakukan semuanya sekaligus. Urutan operasi yang cenderung bekerja:

1. MFA di mana pun belum ada, dimulai dengan identity provider, kemudian GitHub/GitLab, kemudian cloud consoles. Ini saja menutup jalur account-takeover yang paling umum.
2. Centralized logging untuk cloud dan auth events. Bahkan free tier dari SIEM-adjacent tool, atau hanya mengirim CloudTrail/GCP audit logs ke bucket dengan retention, lebih baik daripada tidak memiliki apa pun ketika incident terjadi.
3. Rencana incident response tertulis, singkat, bahkan jika itu dua halaman: siapa yang di-page, siapa yang berbicara dengan customers, siapa yang memiliki authority untuk menutup sesuatu. Tidak ada orang yang ingat untuk membangun ini sampai hari mereka membutuhkannya, dan pada saat itu terlambat.

Perhatikan tidak ada dari ini yang memerlukan kontrak vendor besar. Mereka memerlukan keputusan dan follow-through.

Mendapatkan buy-in tanpa lini anggaran keamanan

Cara tercepat untuk kehilangan kredibilitas sebagai first security hire adalah menunjukkan dengan wishlist tools sebelum menunjukkan hasil apa pun. Sebagai gantinya, ikat setiap permintaan ke sesuatu yang concrete: "kami menemukan tiga IAM users dengan unrotated access keys dari 2021" lebih baik daripada "kami membutuhkan CSPM tool." Frame requests dalam hal engineering dan finance sudah peduli: reduced blast radius, faster audits, fewer 2 a.m. pages. Jika perusahaan mengejar SOC 2 atau ISO 27001, deadline compliance itu sering menjadi leverage point terbaik Anda untuk mendapatkan resources, bahkan jika compliance sendiri bukan tujuannya.

Kesalahan umum di tahun pertama

Membeli platform mahal (SIEM, EDR, CSPM) sebelum Anda memiliki process atau headcount untuk benar-benar mengoperasikannya adalah pemborosan budget awal yang paling umum. Tool $50k yang tidak ada orang tune menghasilkan noise, bukan detection. Begitu juga, menulis kebijakan yang disalin dari template tanpa menyesuaikannya dengan cara perusahaan benar-benar bekerja menjamin mereka diabaikan pertama kali seseorang membutuhkan exception. Dan mencoba memiliki semuanya sendiri melampaui enam bulan pertama adalah jalur burnout; pada saat ada traction, hire berikutnya biasanya harus seseorang yang dapat memiliki detection dan response sehingga Anda dapat terus membangun program structure.

Keamanan dari nol adalah sebagian besar tentang sequencing: lihat apa yang ada, tutup gap yang paling keras, bangun cukup proses sehingga keputusan tidak mengandalkan memori Anda, dan perluas dari sana.

Jika jenis program building level ground ini menarik Anda, Korra Studio memiliki segmen terkait pada incident response fundamentals dan cloud security posture yang cocok dengan yang ini.