Kurucular için Kevin Mitnick'in sosyal mühendislik dersleri

Güvenlik hatalarının sıklıkla “birisi yanlış yaptı” gibi görünmesinin nedeni

İhlal haber olduğunda çoğu zaman basit gelir: biri yanlış bağlantıya tıkladı, bir şifre paylaşıldı ya da yanlış bir istek onaylandı. Bu nadiren tüm hikayedir.

Çoğu güvenlik hatası, dağınık bir iş akışında normal insan güveninin başlaması ve hatayı erken yakalayacak koruma mekanizmalarının eksik olmasıyla ortaya çıkar.

İnsanlar genellikle yardım etmeye çalışır. Bir ekip arkadaşı bir lansmanı engellemek istemez, destek sinirli bir müşteriyi sakinleştirmek ister, finans bir faturayı son tarihten önce ödemek ister. Saldırganlar tam da bu anlara odaklanır. Süreç belirsiz ve erişim genişse, inandırıcı bir mesaj gerçek zarara dönüşebilir.

Sosyal mühendislik, bir kişiyi saldırganın işini yapmaya ikna etmenin süslü adıdır. Genellikle şöyle görünür:

• Kullandığınız bir araca benzeyen sahte bir giriş sayfası
• Birini çalışma alanına veya repo'ya ekleme için “acil” Slack ya da e-posta isteği
• Erişimini kaybettiğini iddia eden tedarikçi, yeni işe alınan veya yönetici kılığında bir arayan

Bu derin hacking, kötü amaçlı yazılım analizi veya egzotik açıklarla ilgili değildir. Kolay zaferleri azaltacak pratik kurucu hamleleriyle ilgilidir: daha sıkı erişim, daha iyi görünürlük ve patlama alanını sınırlayan varsayılanlar.

Amaç takımınızı yavaşlatmak değil. Güvenli yolu en kolay yol yapmak. İzinler sınırlı, eylemler kaydedilmiş ve riskli ayarlar kapalıysa, aynı insan hatası şirket çapında bir krize değil küçük bir olaya dönüşür.

Kevin Mitnick'in bize saldırıların insan tarafı hakkında öğrettikleri

Kevin Mitnick, sihirli açıklar yazdığı için değil, normal ve zeki insanları kandırmanın ne kadar kolay olduğunu gösterdiği için ünlü oldu. Hikayesi, aldatma, ikna ve ekiplerin meşgulken göz ardı ettiği prosedür boşluklarını ortaya koydu.

Çıkarım basit: saldırganlar nadiren en zor hedefle başlamaz. Şirketinize giriş için en kolay yolu ararlar ve bu yol genellikle acele eden, yardımsever veya “normal” ne demek olduğunu bilmeyen bir kişidir.

Bu aynı zamanda yaygın bir efsaneyi de aydınlatır. Birçok ihlal “deha işi kod kırma” değildir. Daha sık olarak temel hatalar: yeniden kullanılan parolalar, paylaşılan hesaplar, hiç kaldırılmamış izinler veya adımı atlamaya zorlanan biri.

Kurucular şirketi bir kaleye çevirmeden zararı azaltabilir. Paranoya gerekmez. Bir yanlış kararın tam bir ihlale dönüşmesini engelleyecek koruma hatlarına ihtiyacınız var.

Pek çok sosyal mühendislik zaferini engelleyen üç kontrol:

• Asgari ayrıcalık: insanlar şu an yaptıkları iş için sadece ihtiyaç duydukları erişimi alır
• Denetim izleri: anahtar eylemler kaydedilir, böylece tuhaf etkinlikler göze çarpar
• Daha güvenli varsayılanlar: yeni araçlar ve hesaplar başlangıçta kısıtlı olur, gerektiğinde açılır

Bunlar kasıtlı olarak sıkıcıdır. Sıkıcılık manipulasyonu engeller.

Sosyal mühendislik gündelik startup işine nerede sızar

Mitnick'in dersleri kurucular için önemlidir çünkü “saldırı” genellikle normal bir güne benzer: biri yardıma ihtiyaç duyar, bir şey acildir ve işlerin ilerlemesini istersiniz.

Çoğu aksaklık yardım anlarında olur. “Kilitlendim, şifremi sıfırlar mısın?” “Demo öncesi drive'a erişemiyorum.” “Bu müşterinin faturasını bugün değiştirmemiz gerekiyor.” Bunların hiçbiri tek başına şüpheli değildir.

Küçük ekipler ayrıca onayları gayri resmi yollarla verir. Erişim DM'lerde, kısa bir çağrıda veya koridorda verilen bir sözle verilir. Hız kendi başına sorun değildir. Sorun süreç "mesajı ilk gören yapar" haline geldiğinde başlar. Sosyal mühendislerin saydığı tam da budur.

Bazı roller daha çok hedeflenir çünkü hızlıca “evet” diyebilirler: kurucular ve yöneticiler, finans, destek, DevOps veya BT yöneticileri ve e-posta, bulut veya kod barındırmada yönetici haklarına sahip herkes.

Basit bir örnek: Gece geç saatte bir “yüklenici” kurucuya üretim erişimi ister: “lansman sorununu düzeltmek için geçici erişim verin.” Kurucu yardım etmek ister, talebi DevOps'a iletir ve istek ikinci bir kontrolden geçmeden onaylanır.

Hızı koruyun ama koruma hatları ekleyin: kimliği ikinci bir kanalda doğrulayın, yazılı talepleri tek bir yerde zorunlu kılın ve “acil” erişim için net kurallar belirleyin ki aciliyet güvenliğin önüne geçmesin.

Gerçek kök neden: süreç boşlukları ve eksik koruma hatları

Birçok startup güvenlik hatası şifreleme kırılmasıyla olmaz. Normal bir iş akışında delikler olduğunda ve kötü bir isteği, acele onayı veya kapatılması gereken eski hesabı yakalayacak bir şey olmadığında meydana gelir.

Süreç boşlukları genelde zararın sizi vurduğu güne kadar görünmez:

• Sahiplik belirsizdir, kim onaylamalı bilinmez
• Doğrulama atlanır, bu yüzden bir Slack mesajı kanıt sayılır
• Offboarding “sonra hallederiz” şeklindedir, bu yüzden eski izinler kalır

Araç eksiklikleri hataları pahalı hale getirir. Paylaşılan hesaplar kim ne yaptı gizler. İzinler zamanla karmaşıklaşır. Merkezi loglar yoksa, bir “hop”un kaza mı yoksa daha kötü bir şeyin provasımı olduğunu anlayamazsınız.

Kültür son itkiyi verebilir. “Herkese güveniyoruz” sağlıklıdır, ama sessizce “hiç doğrulamıyoruz” haline dönüşebilir. Nazik bir ekip sosyal mühendisliğin tam hedefidir çünkü nezaket ve hız varsayılan olur.

Basit koruma hatları en büyük delikleri ekibinizi yormadan kapatır:

• Her kritik alan için bir sahibi atayın (üretim dağıtımları, faturalama, veri dışa aktarımları)
• Yüksek riskli işlemler için ikinci bir kontrol zorunlu kılın (yeni admin, veritabanı erişimi, alan adı değişiklikleri)
• Önemli hiçbir şey için paylaşılan girişleri yasaklayın
• Tek sayfalık bir offboarding kontrol listesi kullanın ve aynı gün uygulayın

Tek yanlış onay iyi teknik güvenliği atlatabilir. Biri “geçici erişim” için konuşabiliyorsa, güçlü bir parola politikası sizi kurtarmaz.

Asgari ayrıcalık: en basit kontrol, en büyük getiri

Asgari ayrıcalık basit bir kuraldır: insanlara o anda yaptıkları iş için asgari erişimi verin, daha fazlasını vermeyin. Birçok sosyal mühendislik saldırısı, saldırganların zaten var olan erişimi kullanmasını sağlamak için kimseyi kandırması üzerine çalışır.

Başlangıç olarak erişimi görünür kılın. Genç bir şirkette izinler sessizce büyür ve sonunda “herkes her şeyi yapabiliyor” hale gelir. Bir saat ayırın ve kimlerin büyük kovalara erişebildiğini yazın: üretim, faturalama, kullanıcı verisi, iç yönetici araçları, bulut hesapları ve kod dağıtabilen veya dışa aktarabilen her şey.

Sonra erişimi birkaç net rolle azaltın. Mükemmel politika dili gerekmez. İşinize uyan varsayılanlara ihtiyacınız var, örneğin:

• Admin: nadiren kullanılan küçük bir sahip grubu
• Geliştirici: staging'e dağıtım, sınırlı üretim işlemleri
• Destek: gerekeni görür, toplu dışa aktarma yok
• Finans: sadece faturalama ve ödemeler
• Salt okunur: denetçiler veya danışmanlar

Hassas görevler için kalıcı “ola ki” admin'den kaçının. Zaman sınırlı yükseltme kullanın: otomatik sona eren geçici haklar.

Offboarding asgari ayrıcalığın sıklıkla bozulduğu yerdir. Birisi ayrıldığında veya rolü değiştiğinde erişimi aynı gün kaldırın. Paylaşılan sırlarınız varsa (paylaşılan parolalar, ekip API anahtarları), hemen döndürün. Geniş izinlere sahip eski bir hesap tüm güvenlik kararlarınızı boşa çıkarabilir.

Denetim izleri: eylemleri görünür kılın ki hatalar erken yakalansın

Denetim izi, kimin neyi ne zaman ve nereden yaptığına dair bir kayıttır. Belirsiz “bir şey oldu”yu eyleme geçirilebilir bir zaman çizelgesine çevirir. Ayrıca davranışı değiştirir: eylemler görünür olduğunda insanlar daha dikkatli olur.

Küçük bir dizi yüksek değerli olayı kaydederek başlayın. Sadece birkaçını yakalayacaksanız, erişimi hızla değiştirebilen veya veriyi hareket ettirebilen olaylara odaklanın:

• Oturum açmalar ve başarısız oturum açmalar (varsa cihaz ve konum sinyalleri dahil)
• İzin ve rol değişiklikleri
• Veri dışa aktarımları ve toplu indirmeler
• Fatura ve ödeme ayarı değişiklikleri
• Dağıtımlar ve üretim yapılandırma değişiklikleri

Süre saklama penceresini hızınıza göre belirleyin. Birçok startup hızlı sistemler için 30–90 gün tutar, faturalama ve yönetim işlemleri için daha uzun.

Burada sahiplik önemlidir. Haftada 10 dakikalık hafif bir inceleme yapacak bir kişiyi atayın, örneğin admin değişikliklerini ve dışa aktarımları kontrol etsin.

Uyarılar sessiz ama keskin olmalı. Düzensiz birçok bildirime göre, birkaç yüksek riskli tetik daha etkilidir: yeni admin oluşturuldu, izin genişletildi, alışılmadık dışa aktarma, yeni bir ülkeden giriş, fatura e-postası değişti.

Gizlilik sınırlarına saygı gösterin. Eylemleri ve meta verileri (hesap, zaman damgası, IP, cihaz, uç nokta) kaydedin; hassas içeriği değil. Loglara kimlerin erişebileceğini üretim erişimine uyguladığınız özenle sınırlayın.

Daha güvenli varsayılanlar: bir yanlış karardan zarar azaltma

“Daha güvenli varsayılanlar”, biri yanlış bir şeye tıkladığında, yanlış bir mesaja güvendiğinde veya çok hızlı hareket ettiğinde zararı sınırlayan başlangıç ayarlarıdır. Çoğu olay filmvari hackler değil; baskı altındaki normal işler yanlış yöne itilir.

İyi bir varsayılan, insanların yorgun, meşgul ve bazen aldatılabilir olduklarını varsayar. Güvenli yolu kolay yol yapar.

Hızlı geri dönüş sağlayan varsayılanlar:

• Tüm hesaplar için MFA zorunlu, opt-out yok
• Yeni kullanıcılar düşük izinle başlar, ihtiyaç oldukça daha fazla verilir
• Veri dışa aktarımları varsayılan olarak devre dışı veya küçük bir grupla sınırlı
• “Anında admin”i engellemek için admin atamalarında onay adımı gerektirin
• Paylaşılan erişimi kaldırın (paylaşılan admin girişleri yok, API anahtarları sohbet araçlarına yapıştırılmasın)

En çok zarar verebilecek eylemlere basit “emin misiniz?” desenleri ekleyin. Ödemeler, izin değişiklikleri ve büyük dışa aktarmalar iki adım kullanmalı: onay artı ikinci faktör veya ikinci onaylayıcı.

Gerçekçi bir anı hayal edin: bir kurucu Slack'te finansmış gibi görünen bir mesaj alır ve “bordroyu düzeltmek için hızlıca admin ver” der. Eğer varsayılan düşük izinse ve admin atamaları ikinci onay gerektiriyorsa, en kötü sonuç başarısız bir talep olur, bir ihlal değil.

Bu varsayılanları neden olduğunu basit bir dilde yazın. İnsanlar nedenini anladığında, son tarih geldiğinde bunları aşma eğiliminde daha az olurlar.

Kurucuların gerçekten uygulayabileceği adım adım 30 günlük plan

Kurucu dostu güvenlik planları her şeyi bir anda düzeltmeye çalıştığında başarısız olur. Daha iyi yaklaşım, tek bir kişinin yapabileceğini azaltmak, riskli eylemleri görünür kılmak ve sadece önemli yerlerde sürtünme eklemektir.

Hafta hafta (30 gün)

Gün 1–7: Gerçekten önemli olanı belirleyin. “Taç mücevherlerinizi” yazın: müşteri verisi, para hareket eden herhangi bir şey, üretim erişimi ve varlığınızın anahtarları (alan adları, e-posta, uygulama mağazaları). Tek sayfada tutun.

Gün 8–14: Roller tanımlayın ve erişimi sıkılaştırın. Çalışma şeklinize uyan 3–5 rol seçin (Kurucu, Mühendis, Destek, Finans, Yüklenici). Her role yalnızca ihtiyaç duydukları erişimi verin. Birisi ekstra erişim istiyorsa, zaman sınırlı yapın.

Gün 15–21: Kimlik doğrulama temellerini düzeltin. E-mail, parola yöneticisi, bulut ve ödeme sistemleriyle başlayarak her yerde MFA'yı açın. Paylaşılan hesapları ve genel girişleri kaldırın. Bir araç paylaşımı zorunlu kılıyorsa, onu risk olarak değerlendirin ve değiştirmeyi düşünün.

Gün 22–30: Görünürlük ve onaylar ekleyin. Kritik eylemler için logları etkinleştirin ve gerçek anlamda kontrol ettiğiniz tek bir yere yönlendirin. En riskli hareketler için iki kişilik onay ekleyin (para hareketi, üretim veri dışa aktarımları, alan adı değişiklikleri).

Başlangıçta uyarıları minimal tutun:

• Yeni admin eklendi
• MFA devre dışı bırakıldı
• Büyük veri dışa aktarımı veya yedek indirme
• Alan adı veya DNS değişikliği
• Ödeme hedefi güncellendi

Gün 30'dan sonra iki tekrarlayan takvim öğesi ekleyin: aylık erişim incelemesi (kim neye sahip ve neden) ve üç aylık offboarding tatbikatı (erişimi hızlıca tamamen kaldırabiliyor musunuz, token ve cihazlar dahil?).

Koder.ai (koder.ai) gibi platformlarda hızlı ürün inşa ediyorsanız, dışa aktarmalar, dağıtımlar ve özel alan adlarını da taç mücevher eylemler olarak kabul edin. Erken onaylar ve loglama ekleyin; aceleyle yapılan bir değişikliği geri almak için snapshot ve rollback kullanın.

Ekipleri açıkta bırakan yaygın tuzaklar

Çoğu startup güvenlik sorunu zeki hackler değildir. Hızlı hareket ederken normal hissettiren alışkanlıklardır ve bir mesaj ya da tıklama yanlışsa pahalı hale gelir.

Yaygın bir tuzak admin erişimini varsayılan yapmakdır. Anlık olarak daha hızlıdır ama her ele geçirilen hesap bir master anahtara dönüşür. Aynı desen paylaşılan kimlik bilgileri, asla kaldırılmayan “geçici” erişimler ve yüklenicilere çalışanlarla aynı izinlerin verilmesinde görülür.

Başka bir tuzak doğrulamadan acil talepleri onaylamaktır. Saldırganlar sıklıkla bir kurucu, yeni bir çalışan veya tedarikçi gibi davranır ve istisna talep etmek için e-posta, sohbet veya telefon kullanır. Süreciniz “acil sound ediyorsa hemen yap” ise, biri taklit edildiğinde hiçbir hız kesiciniz yoktur.

Eğitim yardımcı olur, ama tek başına bir kontrol değildir. İş akışı hız yerine kontrolleri ödüllendiriyorsa, insanlar meşgul olduklarında dersi atlar.

Loglamayı da yanlış yapmak kolaydır. Ekipler ya çok az toplar ya da her şeyi toplar sonra hiç bakmaz. Gürültülü uyarılar insanları göz ardı etmeye alıştırır. Önemli olan, gerçekten inceleyip harekete geçebileceğiniz küçük bir olay setidir.

Üretim dışı riskleri unutmayın. Staging ortamları, destek panoları, analiz dışa aktarımları ve kopyalanmış veritabanları genellikle zayıf kontrollerle gerçek müşteri verisi barındırır.

Düzeltmeye değer beş kırmızı bayrak:

• Çoğu hesap için admin erişim varsayılan
• Erişim talepleri sohbet ortamında ikinci kanal doğrulaması olmadan onaylanıyor
• “Güvenlik eğitimi” var ama günlük süreç değişmedi
• Loglar var ama haftalık inceleme ve takip sahibi yok
• Staging ve destek araçları gerçek veriyi ya da geniş erişimi ekstra korumadan kullanıyor

Hızlı kontrol listesi: bu hafta çalıştırılacak beş kontrol

Saldırganların konuşarak içeri girmesi gerekmez; küçük süreç boşlukları bunu kolaylaştırır. Bu beş kontrol birkaç saat alır, tam bir güvenlik projesi değil.

• Admin erişimini kısa ve güncel tutun. Önemli araçlarda kimlerin admin haklarına sahip olduğunu listeleyin. Günlük ihtiyacı olmayanları kaldırın ve geçici adminleri net bir bitiş tarihiyle zaman kutusuna alın.
• MFA önemli yerlerde açık olsun. E-posta, kaynak kontrol, bulut hesapları ve faturalama ile ilişkili her şeyde çok faktörlü kimlik doğrulama isteyin. Kurtarma seçeneklerini de kontrol edin (yedek kodlar, kurtarma e-postası), çünkü ele geçirme genellikle oradan başlar.
• Girişler ve izin değişiklikleri görünür olsun. Oturum açmalar, yeni API anahtarları, rol değişiklikleri ve başarısız oturum artışları kaydedildiğinden emin olun. Bu olayları haftada iki kez tarayacak birini atayın, 10 dakika bile olsa.
• Yüksek riskli işlemler ikinci gözü gerektirir. Ödemeler, veri dışa aktarımları, fatura detayları değiştirme ve admin verme için ekstra onay adımı ekleyin.
• Offboarding aynı gün çalışsın. Hangi öğelerin anında kaldırılacağını (hesaplar, tokenlar, paylaşılan parolalar) ve hangilerinin döndürüleceğini (API anahtarları, SSH anahtarları, veritabanı kimlik bilgileri) yazın.

Hızla oluşturup dağıtabilen araçlarla çalışıyorsanız, bu koruma hatları daha da önem kazanır çünkü bir ele geçirilmiş hesap kodu, veriyi ve üretimi dakikalar içinde etkileyebilir.

Örnek senaryo: acil erişim isteği nasıl bir ihlale dönüşür

Saat 18:20, demo öncesi gece vakti. Ekip sohbeti bir mesajla çalıyor: “Merhaba, ödeme hatası üzerinde çalışan yeni yükleniciyim. Üretim erişimi verir misiniz? 20 dakikada halledeceğim.” İsim geçen hafta bir başlıkta bahsedildiği için tanıdık geliyor.

Güvensiz yol (çoğunlukla böyle olur)

Bir kurucu demoyu kurtarmak ister, bu yüzden sohbet üzerinden admin erişimi verir. Bilet yok, yazılı kapsam yok, zaman limiti yok ve kişinin kim olduğu kontrol edilmedi.

Dakikalar içinde hesap müşteri verilerini çeker, yeni bir API anahtarı oluşturur ve kalıcılık için ikinci bir kullanıcı ekler. Sonradan bir şey bozulursa ekip bunun bir hata mı, aceleyle yapılan bir değişiklik mi yoksa kötü niyetli bir hareket mi olduğunu anlayamaz.

Daha güvenli yol (aynı hız, daha az risk)

“Admin” vermek yerine hatayı düzeltebilecek en küçük rolü ve sadece kısa bir süre için verin. Basit bir kural: erişim değişiklikleri her zaman aynı yol üzerinden yapılır, stresliyken bile.

Pratikte:

• Kısa bir ticket oluşturun; yapılacak görev ve zaman penceresini belirtin
• “Sadece dağıtım” veya “logları oku” gibi rol tabanlı izinler kullanın, tam üretim admini değil
• İsteği yapan olmayan bir onaylayıcı zorunlu kılın
• Otomatik sona eren zaman sınırlı yükseltme kullanın
• Her erişim iznini ve her hassas eylemi kaydedin

Denetim izleriyle hızlıca şu soruların cevabını alabilirsiniz: kim onayladı, ne zaman başladı, neye dokunuldu ve yeni anahtar veya kullanıcı oluşturuldu mu. Uyarıları basit tutun: ayrıcalıklı rol verildiğinde, kimlik bilgisi oluşturulduğunda veya erişim yeni bir konum/cihazdan kullanıldığında ekibi bildir.

Bu senaryoyu “Acil erişim isteği” adlı tek sayfalık iç playbook'unuza yazın. Tam adımları, kimlerin onaylayabileceğini ve neyin kaydedileceğini listeleyin. Ardından bir kez uygulayın, böylece en güvenli yol aynı zamanda en kolay yol olur.

Sonraki adımlar: güvenliği çalışma şeklinizin bir parçası haline getirin

Mitnick'in en kullanışlı dersi “daha akıllı çalışanlar” değil. Günlük işleri şekillendirerek aceleyle verilen bir kararın şirket çapında bir probleme dönüşmesini engellemektir.

En çok zarar verebilecek anları isimlendirerek başlayın. Kısa bir yüksek riskli eylem listesi yazın, sonra her biri için bir ek kontrol ekleyin. İnsanların gerçekten uygulayacağı kadar küçük tutun.

Sorunları erken yakalayan küçük alışkanlıklar inşa edin

İki tekrarlayan inceleme seçin ve takvime koyun. Tutarlılık büyük, tek seferlik temizlikten daha etkilidir.

Aylık bir erişim incelemesi yapın: kimde admin, fatura, üretim ve veritabanı erişimi var? Haftalık log incelemesi yapın: yeni adminler, yeni API anahtarları, toplu dışa aktarımlar ve başarısız oturum artışlarını tarayın. İstisnaları da izleyin: geçici erişimlerin her birinin bir bitiş tarihi olsun.

Onboarding ve offboarding'i sıkıcı ve otomatik hale getirin. Kısa bir kontrol listesi ve net bir sahip, klasik startup sorununu önler: eski yükleniciler, unutulmuş stajyer hesapları ve hizmet hesaplarının aylar sonra hala erişiminin olması.

Dahili araçlar inşa ediyorsanız daha güvenli varsayılanlar seçin

Müşteri verisine veya paraya dokunan bir araç yayınlarken varsayılan yapılandırma güvenlik belgesinden daha önemlidir. İlk günden net roller hedefleyin: dışa aktaramayan bir görüntüleyici rolü, izinleri değiştiremeyen bir editör rolü ve gerçekten gerektiğinde admin.

Hızlı geri dönüş sağlayan varsayılanlar:

• Yeni kullanıcılar yönetici yerine en düşük rolden başlar
• Dışa aktarma, silme ve izin değişiklikleri ikinci onay veya onay adımı gerektirir
• Her hassas eylem kim, ne ve ne zaman bilgisiyle bir denetim olayı oluşturur
• Geri alma için snapshot ve rollback hazır

Koder.ai (koder.ai) üzerinden uygulama oluşturup dağıtıyorsanız aynı mantığı orada da uygulayın: admin erişimini sıkı tutun, dağıtımları ve dışa aktarmaları kaydedin ve aceleyle yapılan değişiklikleri geri almak için snapshot/rollback kullanın.

Vurgulayarak bitirelim: bir istek acilse ve erişimi değiştiriyorsa, ikinci kanaldan doğrulanana kadar şüpheli muamelesi yapın.