Tarihsel olarak baktığımızda güvenlik CI / CD yolculuğunun dışında bırakılmış bir konu olmuştur. Manuel güvenlik değerlendirmelerine, tehdit modelleme ve tehdit avlama gibi uygulamalı alıştırmalara ve üçüncü taraflı sızma testlerine güvendik hep. Bunlar, olgun bir ürün güvenliği yaşam döngüsünde her zaman yeri olacak önemli etkinliklerdir, ancak düzenli değişikliklere ve otomatik testlere dayanan çevik bir teslimat modeline entegre edilmeleri giderek zorlaşmaktadır. Modern mühendislik ve güvenlik ekipleri arasındaki sürtüşmenin çoğu, bu empedans uyumsuzluğundan kaynaklanmaktadır.
Bu nedenle, Güvenlik ve Mühendislik’in birlikte daha verimli çalışmasını sağlamak için, güvenlik işini sürekli teslimata (CD) entegre etmek gerekir. Doğru kurgulandığında, Güvenlik ve Mühendislik, halihazırda CI’da bulunan aynı test suitindeki güvenlik sorunlarını kapsayan otomatik kontroller üretmek için birlikte çalışır. Sonuç olarak, teslimatlar ritmini korur, ürünün güvenliği garanti altına alınır ve en önemlisi, güvenli kod üretmek için Güvenlik ve Mühendisliğin çatışmadan ziyade işbirliği yaptığı bir yer sağlanmış olur.
Peki pratikte bu nasıl işler? Her kuruluş farklıdır, ancak Güvenlik ve Mühendislik, kuruluşları için sürekli bir entegrasyon ve otomasyon pipeline’ı oluştururken geçirdikleri tipik bir yol haritası vardır:
Kademe 1: Güvenlik sorunları bulur; Mühendislik onları düzeltir.
Kademe 2: Güvenlik ve Mühendislik, test senaryoları ve iyileştirmeler üretmek için işbirliği yapar.
Kademe 3: Sorun çözüldükten sonra, Güvenlik ve Mühendislik, sistemik düzeltmeleri bulmak ve kontroller geliştirmek için işbirliği yapar.
Kademe 4: Güvenlik ve Mühendislik artık proaktif olarak yeni sorun sınıfları arar ve gerçek bir sorun oluşmadan önce sistemik kontroller oluşturur.
Bu yazının geri kalanında, hassas token’ları log’a kaydetmeyle ilgili bir sorunu sistematik olarak düzelten bir ekip hakkında bir örnekleme ile bu aşamaların her birini inceleyeceğiz.
1. Güvenlik sorunları bulur; Mühendislik onları düzeltir.
Bu malesef günümüz kurulum ve kuruluşlarının operasyon sağladı bir yöntem. Takımlar birlikte çalışmıyor: Güvenlik, bir köşede güvenlik açıklarını tespit etmeye çalışıyor ve daha da kötüsü bir istismar oluşmasını bekliyor. Ve bu tarz bir senaryoda durumu Mühendislik’e taşıyarak (umarız), sorunun çözülmesini talep ediyor.
Şimdi örnek çalışmamıza gelelim ve bunun pratikte ne kadar tehlikeli olduğunu görelim. Yetişmekte olan bir ekibin bu güvenlik sorununu bulduğunu hayal edin: “SQLAlchemy hata ayıklama logu açık ve hassas token’lar loglara kaydediliyor”. Sorun, SQLAlchemy’nin token değerini log’a kaydetmesini engelleyen özel bir ObfuscatedString sütunu kullanan akıllıca bir teknikle düzeltildi. Yani, ObfuscatedString değeri aslında token sütunundaki değer ile değiştirildi. Öyleyse problem çözüldü değil mi?
Aslında ilk aşamada her ne kadar sorun çözülmüş gibi görünse de bu yöntem beraberinde yeni problemler getiriyor;
- Doğrulama: Mühendislik bu düzeltmeyi yeni geçtiyse, sorunun gerçekten çözüldüğünü nasıl doğrularız? Genellikle belirli bir olgunluk düzeyinde, Güvenlik ekibi düzeltmeyi manuel olarak doğrular, ancak bu hatalara açıktır. Buna ek olarak, bu işleyiş yavaştır; düzeltme işe yaramadıysa veya eksikse, döngü kendini tekrar etmelidir.
- Regresyon: Bir süre sonra başka bir mühendis bu ObfuscatedString metodunu anlamazsa, sorunu yeniden ortaya çıkaracak şekilde geri döndürülebilir veya değiştirilebilir. Peki bunun olacağını nasıl anlayabiliriz? (spoiler: bir sonraki bölümde ele alacağımız otomatik testler ile)
- Bu tek seferlik mi yoksa sistematik bir sorun mu? Başka bir yerde kaydedilebilecek başka hassas değerler de var mı?
- Fikir Ayrılığı: En önemlisi, bu iş akışı, Güvenlik ve Mühendislik arasındaki çatışmaya uygun koşulları oluşturur. Mühendislik için Güvenliğin sadece onlara iş yaratıyormuş gibi hissetmelerine veya Güvenliğin göz ardı edilmiş ya da sorunları çözmek için yeterli know-how’a sahip olmadıklarını hissedebileceği bir dinamik yaratır. Güvenlik düzeltmenin yazılmasına yardımcı olduğunda bile, herhangi bir sağlam doğrulama veya sistemik analizin olmaması, bu sorunla veya benzer bir sorunla daha sonra geri gelmeleri gerekeceği anlamına gelir ve sonuç olarak her iki taraf da buna kızacaktır.
2. Güvenlik ve Mühendislik, test senaryoları ve iyileştirmeler üretmek için işbirliği yapar.
Olgunluk merdivenindeki -giderek daha yaygın hale gelen- bir sonraki basamak: Güvenlik ve Mühendislik, yalnızca bir güvenlik sorununu çözmek yerine, bir test senaryosu (ve genellikle düzeltmeyi) oluşturmak için işbirliği yapacaktır. Yukarıdaki örnekle birlikte, bir ObfuscatedString sütunuyla bir test modeli kuran, bazı logları yakalayan ve değerin doğru şekilde gizlendiğini doğrulayan bir test senaryosu yazabiliriz.
Bu nispeten basit ekleme ile, daha önce yaşadığımız bir dizi sorunu düzeltir:
- Doğrulama: Test durumu başarılı olursa, güvenlik sorununun çözüldüğünden emin olabiliriz.
- Regresyon: Bu test senaryosu, test suitimizin bir parçası olduğu için, geri çekilirse test senaryosu başarısız olur ve onu üretime yeniden dahil etme riskini almayız.
- İşbirliği: Güvenlik ve Mühendislik artık birlikte daha yakın çalışıyor ve her iki ekibin de bunu “kendi sorunu” olarak değil, “sorunumuz” ve “çözümümüz” olarak görme şansını artırıyor.
AMA: Hala bu sorunun başka bir yerde ortaya çıkıp çıkmadığına veya tüm sorun sınıfı için herhangi bir bütünsel çözüm olup olmadığına dair herhangi bir anlayışa sahip değiliz. Dolayısıyla, kaçınılmaz olarak başka bir yerde benzer bir sorun ortaya çıktığında, muhtemelen tekrar kan kaybederiz. Ve bu da, birlikte iyi çalışan Güvenlik / Mühendislik için bile çok zararlı olabilecek türden bir kızgınlık üretmeye devam edecek.
3. Sistemik düzeltmeleri bulmak ve kontroller geliştirmek
O halde bir sonraki adım, Güvenlik ve Mühendislik’in sistemik sorunları ve düzeltmeleri bulmak için birlikte çalışmasıdır. Ancak belirli bir düzeltme yapıldıktan sonra, Güvenlik ve Mühendislik, bunun sistematik bir sorun olup olmadığını anlamak için bir araya gelir. Eğer öyleyse, bir kontrol veya düzeltme geliştirmeye çalışırlar.
Ancak çoğu zaman sistemik düzeltmeler daha karmaşıktır. Bir güvenlik açığı sınıfını ortadan kaldıran basit bir drop-in değişimi yoktur. Bu hassas log kaydı sorunu için de geçerlidir: Değişkenlerin ne zaman hassas olduğunu sihirli bir şekilde bilen ve onları gizleyen herhangi bir log kaydı modülümüz yoktur.
Statik Kaynak Kodu Analizi tarama araçları tam olarak burada devreye girer. Olgun bir ürün güvenliği iş akışının müthiş önemli bir parçasıdırlar. Geleneksel test uygulamaları – birim testleri, entegrasyon testleri vb. – belirli güvenlik sorunlarını yeniden oluşturmak ve bunların düzeltilmesini sağlamak için harikadır. Ancak, güvenlik sorunlarının tüm sınıflarını keşfetmekte zorlanırlar ve bu, kod tarayıcılarının sağladığı büyük bir avantajdır.
Bu noktada oldukça iyi bir konumdayız. İlgili sorunlar için yeni kod sürekli olarak taranır ve bulunduklarında sağlam bir şekilde düzeltilir. Güvenlik ve Mühendislik, artık iyi bir şekilde otomatikleştirilmiş olan bu çalışma üzerinde işbirliği yapabilirler.
Derlemeleri yeni denetimlerle aniden engellemek (senktron taramalar) yalnızca kuruluşunuzdaki çatışmayı artıracaksa, Mühendisliği engellemeyen ve yalnızca Güvenliğe bildiren denetimleri (asenkron taramalar) uygulayabilirsiniz. Ortaya çıkan sorunlar için Güvenlik, hem belirli hem de sistemik düzeltmeler üzerinde işbirliği yapmak için Mühendislik ile görüşmelere başlayabilir. Kontrol her iki taraf için de tatmin edici olduğunda, daha fazla sorunu engellemek için genişletilebilir.
Takımların (elbette) anlaşamamaları için hala ihtimaller var, ancak en yaygın sorunlu noktaların bazılarını kaldırdık (doğrulama, regresyon, fikir ayrılığı).
4. İşbirliğine dayalı proaktif keşif
Son adım, sorunların keşfedilmesi için proaktif olarak birlikte çalışmaktır. Proaktif keşif gerçekleştiren bir Güvenlik kuruluşu, aşağıdaki süreçlerin bir kısmını veya tamamını içerir:
- Sağlam bir tehdit avlama aktivitesi uygulamak.
- Konferansları (örn. Black Hat, DEF CON, OWASP), önde gelen araştırmacıları, sosyal medyayı veya haber bültenlerini takip ederek yeni istismar teknikleri, güvenlik açığı sınıfları ve CVE’ler dahil olmak üzere güvenlik araştırmalarındaki en son gelişmelerden haberdar olmak.
- Mühendislik Odaklı Risk Sızma Testi – Mühendisler kod tabanını iyi bilirler ve genellikle sorunların nerede gizlenebileceğine dair hipotezlere sahiptirler. Güvenlik testçilerinin araştırması için yerler önerebilir ve sorunları bulmak için bunu kullanabilirler.
- Ve elbette, yukarıdakilerin sonuçlarını otomatik kontrollere ve testlere dönüştürmek.
- Burada söylenecek çok şey var. Anahtar kelime, sistemik düzeltmelerin son derece önemli olmasıdır. Sorunların tekrar etmesini önlemek, Güvenliği proaktif keşfe odaklanma özgürlüğüne kavuşturur. Bu, Güvenliği kurumsal güvenliğin geliştirilmesinde aktif bir role taşır.
Son Sözler
Ekibiniz bu modelde nerede uyuyor? Kademe 1’deyseniz, güvenlik ekibinin test senaryoları ekleyerek güvenlikle ilgili düzeltmeler hakkında bilgi paylaşımı sağlayacak bir seviye oluşturmasını deneyebilirsiniz. Bu küçük değişikliğin bile ne kadar etkili olabileceğine şaşıracaksınız. Güvenlik ve Mühendisliğin işbirliği içinde çalışmasını sağlamak, güvenlik duruşunuzda büyük kazançlar sağlayacaktır.
Bu zaten uygulanıyorsa, ancak sistemik düzeltmelere geçmeyi denemediyseniz, 3. kademeye ulaşmanın ne kadar kolay olacağına şaşıracağınızı düşünüyorum. Güvenlik araçları, tek tek düzeltmelerden sistem düzeltmelerine ve denetimlere geçmenin kolay olduğu bir noktaya ulaştı. Statik Kod Analizi araçlarının mevcut CI / CD pipeline’larına entegre edilmesi giderek daha kolay hale geliyor. Kaynak kodunu iyileştirebilme yeteneği ile birleştiğinde, sorunları sistematik olarak ortadan kaldırmak herhangi bir Güvenlik ekibinin elindedir.
Mehmet Türker
Technical Account Manager & Cyber Security Engineer
Endpoint Bilgi Teknolojileri Güvenliği ArGe A.Ş – 2022
LinkedIn