1954 tarihli “Ben Efsaneyim” romanı, modern zombi ve vampir türünün gelişmesinde önemli bir rol oynadı. Ana karakter Robert Neville’in bildiği kadarıyla, diğer herkesi “vampirlere” dönüştüren salgından kurtulan son kişi o (yine de bizim zombi olarak düşündüğümüz şeylere daha çok benziyorlar). Romanın ayırt edici özelliklerinden biri, hastalığın arkasındaki bilimsel açıklama ve beraberindeki biyolojik düzeltmeydi.
Bunun API’lerle nasıl bir ilişkisi var? İki tehlikeli API türü Zombiler ve Gölgelerdir. Bu düşmanların nasıl ciddi sorunlar oluşturduğundan ve – Neville’in bulduğu gibi – sihirli olmayan, rasyonel, mantıklı ve makul düzeltmelerin nasıl olduğundan bahsedelim.
Zombiler ve Gölgeler
Bir zombi API’si, bir kuruluş tarafından terk edilmiş, kalıcı ve unutulmuş bir API’dir. Bir gölge (aka Rogue) API, oluşturulmuş ancak hiçbir zaman belgelenmemiş bir kurumsal API’dir, bu nedenle kuruluş tarafından bilinmemektedir. İkisi benzer çünkü güncelleme, koruma veya kaldırma için resmi envanterde yer almadıkları için güvenlik, uyumluluk ve mahremiyet açısından ciddi bir sorumluluk teşkil ediyorlar.
Aradaki fark, zombi API’sinin bir zamanlar kuruluş tarafından onaylanması, gölge API’sinin ise hiçbir zaman resmi olarak onaylanmamasıdır. Hangisinin daha kötü olduğu, büyük ölçüde API’nin nasıl kullanıldığına ve nerede bulunduğuna bağlıdır. Dahili ve test API’lerine dışarıdan erişmek daha zor olabilir, ancak dahili olarak 7/24 aktif erişime sahip bir tehdit aktörü tarafından bir dahili gölge API oluşturulduysa, dahili gölge halka açık zombiden çok daha büyük bir tehdittir. kimsenin keşfetmediği.
Yakın zamanda yapılan bir anket, zombi API’sinin API güvenlik endişeleri listesinin başında geldiğini ve “%54’ünün yüksek endişe kaynağı olduğunu gösterdiğini” gösterdi. Gölge API’ler, ankete katılanlar için daha az endişe verici görünse de, bu onların kurumsal risk iştahını yansıtıyor olabilir.
Oyun oynamak
Kendi Maceranı Seç ® serisini hatırlıyor musun? (Yolunuzu Seçin ® hatırladığım başka bir tanesiydi) Uzun zaman oldu ve birkaç yıl önce Infosec Enstitüsü “Zombie Invasion” oyununu yaratarak bilgi güvenliğini oyunlaştırdı. O zamandan beri “Derin Uzay Tehlikesi” ne taşındı. (Kişi kendi hikayesini de tasarlayabilir)
API geliştirme sırasında Güvenli Yazılım Geliştirme Yaşam Döngüsünü izlemenin önemini ve bunun zombi ve gölge API’leri nasıl azaltabileceğini veya bunlara nasıl izin verebileceğini ele alan, kendi oluşturduğumuz kısa bir hikayeyi deneyelim. Her iki API riskiyle başa çıkmak için Zombie’yi Shadow ile değiştirebilirsiniz.
Zombi Saldırısı: Kodunuzu Güvenceye Alın veya Sonuçlarla Yüzleşin!
Hayat kurtarabilecek kritik bir proje üzerinde çalışan bir yazılım geliştiricisisiniz. İnsanların kendilerini bir zombi kıyametine karşı savunmalarına yardımcı olacak bir uygulama oluşturmakla görevlendirildiniz. Kodunuzun güvenli olduğundan ve saldırıya uğramadığından emin olmak için Güvenli Yazılım Geliştirme Yaşam Döngüsü (SSDL) belgesini izlemelisiniz. Ancak, SSDL’ye uymazsanız kodunuz, onu kendi kötü amaçları için kullanmak isteyen saldırganlara karşı savunmasız olabilir.
Bölüm 1: Projenin Başlangıcı
Projeye yeni atandınız. Yapıyor musun:
- a) Kodlamaya başlamadan önce SSDL belgesini okumak ve anlamak için biraz zaman ayırın (2. Bölüme gidin)
- b) SSDL belgesini okumadan hemen kodlamaya başlayın (Bölüm 3’e gidin)
Bölüm 2: SSDL’yi takip edin
SSDL belgesini okudunuz ve yönergeleri izlemeye başladınız. Güvenli kodlama uygulamalarını kullanır, güvenlik testleri gerçekleştirir ve erişim kontrolleri uygularsınız. Yapıyor musun:
- a) Kodunuzu güvenlik açıklarına karşı sürekli olarak izleyin (4. Bölüme gidin)
- b) SSDL’yi takip etmenin çok fazla iş olduğunu düşünün ve takip etmeyi bırakın (Bölüm 3’e gidin)
Bölüm 3: SSDL’yi Yoksay
SSDL belgesini takip etmeden kodlamaya başlıyorsunuz. Zaman kazanmak için kısayolları kullanırsınız ve herhangi bir güvenlik testi yapmazsınız. Sonuç olarak, kodunuz saldırılara karşı savunmasızdır. Yapıyor musun:
- a) Hatanızın farkına varın ve SSDL’yi takip etmek için Bölüm 2’ye geri dönün (Bölüm 2’ye gidin)
- b) Güvenlik risklerini göz ardı ederek kodlamanıza devam edin (Bölüm 5’e gidin)
Bölüm 4: Kodunuzu Güvenli Hale Getirin
Kodunuz güvende ve sisteminizi hacklemeye çalışan potansiyel bir saldırgan tespit ettiniz. Yapıyor musun:
- a) Saldırıyı güvenlik ekibine bildirin ve sorunu çözmek için onlarla birlikte çalışın (6. Bölüme gidin)
- b) Saldırıyı görmezden gelin ve geçmesini umun (Bölüm 5’e gidin)
Bölüm 5: Saldırı Gerçekleşiyor
Saldırgan, kodunuzdaki güvenlik açıklarından yararlanır ve sisteme erişim sağlar. Saldırgan, uygulamanızı kendi kötü amaçları için kullanarak kaosa ve yıkıma neden olur. Saldırıyı durduramadınız ve eylemlerinizin sonuçlarıyla yüzleşmeniz gerekiyor.
Bölüm 6: Saldırıya Karşı Savunma
Saldırgana karşı savunma yapmak için güvenlik ekibiyle birlikte çalışırsınız. Kodunuzdaki güvenlik açıklarını düzeltir ve ek güvenlik önlemleri uygularsınız. Saldırıya karşı başarılı bir şekilde savunma yaptınız ve saldırganın herhangi bir zarar vermesini engellediniz.
Düzeltme: Çarpışma Testi
Önden çarpma, yandan çarpma, direk, devrilme – bunlar, araç çarpma testleri için gerçekleştirilen birçok testten sadece birkaçıdır. Otomobilleri sürüşü daha güvenli hale getirmek için çok fazla kaynak harcanıyor. Testler kusursuz mu? Diğer tüm testlerde olduğu gibi çarpışma testi mankenleri de tarihsel olarak 5’9″, 170 lbs olan ve ortalama bir kadını (yaklaşık 5 inç daha kısa) dikkate almayan ortalama Amerikalı erkekleri temel almıştır. Testler iyileştirilebilse de bu, testlerin kullanışlılığını azaltmaz.
API’lerin güvenliğini sağlamakla aynı şey. Hiçbir test API’si tüm senaryoları kapsamaz, ancak bazı testler hiç test yapmamaktan çok daha iyidir.
API’lerinizi kilitlenme testi yapın, ancak miyop bir yaklaşımdan kaçının. Bazı testler iyi olsa da, süreç iyileştirilmelidir. Kaizen, üretim ve TQM (Toplam Kalite Yönetimi) için tasarlanırken, API tasarımı, geliştirmesi ve testine uygulanabilen popüler bir kavramdır. Herhangi bir iyileştirme yöntemi olmaksızın, test etme hızla bir tür tembellik haline gelir ve daha fazla risk getirir.
Gömülü hazine
Herhangi bir güvenlik programında olduğu gibi, birincil etkinlik varlık envanteridir – sahip olduğunuzu bilmediğiniz bir şeyi koruyamazsınız. Tıpkı altın madenciliği gibi, unutulmuş ve bilinmeyen API’leri aramak kaynak açısından yoğun olabilir, ancak müşterilerinizin size emanet ettiği paha biçilmez kaynakları koruyabilmeniz ve daha da önemlisi bir tanesini koruyabilmeniz açısından elde edeceğiniz sonuçlara değecektir. en önemli varlıklarınızdan biri: itibarınız.
Yazar hakkında:
Ross Moore, Geçiş Yolları ile Siber Güvenlik Destek Analistidir. ISO 27001 ve SOC 2 Tip 2 uygulama ve bakım tecrübesine sahiptir. Ross, 20 yılı aşkın BT ve Güvenlik deneyimi boyunca üretim, sağlık, emlak, işletme sigortası ve teknoloji sektörlerindeki şirketler için çeşitli operasyonlarda ve bilgi güvenliği rollerinde hizmet vermiştir. (ISC)2’nin SSCP’sine, CompTIA’nın Pentest+ ve Security+ sertifikalarına, WGU’dan Siber Güvenlik ve Bilgi Güvencesi alanında lisans derecesine sahiptir.