Profesyonel aktivitelerinin bir parçası olarak, geliştiriciler, sızma testçileri ve güvenlik uzmanları, Vulnerability Management (VM), (Secure) SDLC gibi süreçlerle uğraşmak zorundadır.
Bu cümlelerin altında, kullanıcıları farklı olsa da iç içe geçmiş çeşitli uygulama ve araç takımları vardır.
Teknolojik ilerleme, altyapı ve yazılım güvenliğini analiz etmek için bir aracın bir kişinin yerini alabileceği noktaya henüz ulaşmadı.
Bunun neden böyle olduğunu ve kişinin hangi sorunlarla yüzleşmesi gerektiğini anlamak ilginç.
süreçler
Güvenlik Açığı Yönetimi süreci, altyapı güvenliğini ve yama yönetimini sürekli olarak izlemek için tasarlanmıştır.
Güvenli SDLC süreci ("güvenli geliştirme döngüsü"), geliştirme ve çalıştırma sırasında uygulama güvenliğini sürdürmek için tasarlanmıştır.
Bu süreçlerin benzer bir kısmı Güvenlik Açığı Değerlendirme sürecidir - güvenlik açığı değerlendirmesi, güvenlik açığı taraması.
VM ve SDLC içinde tarama arasındaki temel fark, ilk durumda amaç, üçüncü taraf yazılımlarda veya bir yapılandırmada bilinen güvenlik açıklarını bulmaktır. Örneğin, eski bir Windows sürümü veya SNMP için varsayılan topluluk dizesi.
İkinci durumda amaç, yalnızca üçüncü taraf bileşenlerdeki (bağımlılıklar) değil, öncelikle yeni ürünün kodundaki güvenlik açıklarını tespit etmektir.
Bu durum araçlarda ve yaklaşımlarda farklılıklara yol açmaktadır. Kanımca, bir uygulamada yeni güvenlik açıkları bulma görevi çok daha ilginç, çünkü bu sürüm parmak izi alma, afiş toplama, şifre kaba kuvveti vb.
Uygulama güvenlik açıklarının yüksek kaliteli otomatik taraması, uygulamanın anlamını, amacını ve belirli tehditleri dikkate alan algoritmalar gerektirir.
Altyapı tarayıcısı genellikle bir zamanlayıcı ile değiştirilebilir. . Mesele şu ki, altyapınızı örneğin bir aydır güncellemediyseniz, tamamen istatistiksel olarak savunmasız kabul edebilirsiniz.
Araçlar
Güvenlik analizinin yanı sıra tarama, kara kutu veya beyaz kutu olarak gerçekleştirilebilir.
Kara kutu
Kara kutu taramasıyla, araç, kullanıcıların onunla çalıştığı aynı arabirimler aracılığıyla hizmetle çalışabilmelidir.
Altyapı tarayıcıları (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose, vb.) açık ağ bağlantı noktalarını arar, "afişler" toplar, yüklü yazılım sürümlerini belirler ve bu sürümlerdeki güvenlik açıkları hakkında bilgi tabanlarında arama yapar. Ayrıca, varsayılan parolalar veya verilere genel erişim, zayıf SSL şifreleri vb. gibi yapılandırma hatalarını da tespit etmeye çalışırlar.
Web uygulama tarayıcıları (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, vb.) ayrıca bilinen bileşenleri ve bunların sürümlerini (örn. CMS, çerçeveler, JS kitaplıkları) algılayabilir. Ana tarama adımları tarama ve bulanıklaştırmadır.
Tarama sırasında tarayıcı, mevcut uygulama arayüzleri ve HTTP parametreleri hakkında bilgi toplar. Bulanıklaştırma sırasında, tespit edilen tüm parametreler, bir hatayı tetiklemek ve bir güvenlik açığını tespit etmek için mutasyona uğramış veya üretilmiş verilerle değiştirilir.
Bu tür uygulama tarayıcıları, sırasıyla Dinamik ve Etkileşimli Uygulama Güvenlik Testi olmak üzere DAST ve IAST sınıflarına aittir.
Beyaz kutu
Beyaz kutu tarama ile daha fazla fark vardır.
VM sürecinin bir parçası olarak, tarayıcılara (Vulners, Incsecurity Couch, Vuls, Tenable Nessus, vb.) genellikle kimliği doğrulanmış bir tarama gerçekleştirerek sistemlere erişim verilir. Böylece tarayıcı, kurulu paket sürümlerini ve yapılandırma parametrelerini ağ hizmeti afişlerinden tahmin etmeden doğrudan sistemden indirebilir.
Tarama daha doğru ve eksiksizdir.
Uygulamaların beyaz kutu taramasından (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs, vb.) bahsedersek, o zaman genellikle statik kod analizinden ve ilgili SAST sınıfı araçların - Statik Uygulama Güvenliği Testi - kullanımından bahsediyoruz.
Sorunları
Taramayla ilgili birçok sorun var! Tarama ve güvenli geliştirme süreçleri oluşturmak için bir hizmet sağlamanın bir parçası olarak ve ayrıca güvenlik analizi çalışması yürütürken çoğuyla kişisel olarak ilgilenmem gerekiyor.
Çeşitli şirketlerde mühendisler ve bilgi güvenliği hizmetleri başkanları ile yapılan görüşmelerle de onaylanan 3 ana sorun grubunu seçeceğim.
Web Uygulaması Tarama Sorunları
- Uygulama zorluğu. Tarayıcıların etkin olabilmesi için devreye alınması, yapılandırılması, her uygulama için özelleştirilmesi, taramalar için bir test ortamı tahsis edilmesi ve CI/CD sürecinde uygulanması gerekir. Aksi takdirde, yalnızca yanlış pozitifler veren işe yaramaz bir resmi prosedür olacaktır.
- Tarama süresi. Tarayıcılar, 2019'da bile, arabirimleri tekilleştirme konusunda kötü bir iş çıkarıyor ve bunlardan aynı kod sorumlu olmasına rağmen, farklı olduklarını düşünerek, her biri 10 parametreli bin sayfayı günlerce tarayabilir. Aynı zamanda, geliştirme döngüsü içinde üretime dağıtım kararı hızlı bir şekilde verilmelidir.
- Zayıf tavsiyeler. Tarayıcılar oldukça genel önerilerde bulunur ve bir geliştiricinin onlardan risk düzeyini nasıl azaltacağını ve en önemlisi, bunun hemen yapılması gerekip gerekmediğini veya henüz korkutucu olmadığını onlardan hızlı bir şekilde anlaması her zaman mümkün değildir.
- Uygulama üzerinde yıkıcı etki. Tarayıcılar bir uygulamada kolayca DoS saldırısı gerçekleştirebilir ve ayrıca çok sayıda varlık oluşturabilir veya mevcut olanları değiştirebilir (örneğin, bir blogda on binlerce yorum oluşturabilir), bu nedenle düşüncesizce bir tarama çalıştırmamalısınız. ürün.
- Zayıf güvenlik açığı algılama kalitesi. Tarayıcılar genellikle sabit bir dizi yük kullanır ve bilinen uygulama davranışlarına uymayan bir güvenlik açığını kolayca gözden kaçırabilir.
- Tarayıcı, uygulamanın işlevlerini anlamıyor. Tarayıcıların kendileri "İnternet bankası", "ödeme", "yorum" un ne olduğunu bilmiyorlar. Onlar için yalnızca bağlantılar ve parametreler vardır, bu nedenle çok büyük bir olası iş mantığı güvenlik açıkları katmanı tamamen ortaya çıkarılmış halde kalır, çifte silme yapmayı, diğer kişilerin verilerini kimliğe göre gözetlemeyi veya yuvarlama yoluyla bakiyeyi tamamlamayı tahmin etmezler.
- Sayfa semantiğinin tarayıcı tarafından yanlış anlaşılması. Tarayıcılar SSS'yi okuyamazlar, captcha'ları tanıyamazlar, nasıl kaydolacaklarını ve sonra yeniden oturum açacaklarını, "çıkış"a tıklayamayacağınızı ve parametre değerlerini değiştirirken istekleri nasıl imzalayacaklarını tahmin edemezler. Sonuç olarak, uygulamanın çoğu hiç taranmamış kalabilir.
Kaynak Kodu Tarama Sorunları
- Yanlış pozitifler. Statik analiz, birçok tavizi içeren karmaşık bir görevdir. Genellikle doğruluktan ödün vermeniz gerekir ve pahalı kurumsal tarayıcılar bile çok sayıda yanlış pozitif verir.
- Uygulama zorluğu. Statik analizin doğruluğunu ve eksiksizliğini artırmak için tarama kurallarını iyileştirmek gerekir ve bu kuralları yazmak çok zaman alabilir. Bazen koddaki tüm yerleri bir tür hata ile bulmak ve düzeltmek, bu tür durumları tespit etmek için bir kural yazmaktan daha kolaydır.
- Bağımlılık desteği eksikliği. Büyük projeler, programlama dilinin yeteneklerini genişleten çok sayıda kitaplığa ve çerçeveye bağlıdır. Tarayıcının bilgi tabanında bu çerçevelerdeki tehlikeli yerler ("lavabolar") hakkında bilgi yoksa, bu bir kör nokta haline gelir ve tarayıcı kodu bile anlamaz.
- Tarama süresi. Koddaki güvenlik açıklarını bulmak, algoritmalar açısından da zor bir iştir. Bu nedenle, süreç gecikebilir ve önemli bilgi işlem kaynakları gerektirebilir.
- Düşük kapsama alanı. Kaynak tüketimine ve tarama süresine rağmen, SAST araçları geliştiricilerinin yine de tavizler vermesi ve bir programın içinde olabileceği tüm durumları analiz etmesi gerekmez.
- Tekrarlanabilirlik bulma. Bir güvenlik açığına yol açan belirli hatta ve çağrı yığınına işaret etmek harikadır, ancak aslında çoğu zaman tarayıcı harici bir güvenlik açığı olup olmadığını kontrol etmek için yeterli bilgi sağlamaz. Ne de olsa kusur, saldırganın ulaşamadığı ölü kodda da olabilir.
Altyapı Tarama Sorunları
- Yetersiz envanter. Büyük altyapılarda, özellikle de coğrafi olarak ayrı olanlarda, hangi ana bilgisayarların taranacağını anlamak genellikle en zor şeydir. Diğer bir deyişle tarama görevi, varlık yönetimi görevi ile yakından ilişkilidir.
- Kötü önceliklendirme. Ağ tarayıcıları genellikle pratikte yararlanılamayan, ancak resmi olarak risk düzeyleri yüksek olan kusurlarla birçok sonuç üretir. Tüketici, yorumlanması zor bir rapor alır ve önce neyin düzeltilmesi gerektiği net değildir.
- Zayıf tavsiyeler. Tarayıcı bilgi tabanı genellikle güvenlik açığı ve bunun nasıl düzeltileceği hakkında yalnızca çok genel bilgiler içerir, bu nedenle yöneticilerin kendilerini Google ile donatması gerekir. Düzeltmek için belirli bir komut verebilen beyaz kutu tarayıcılarda durum biraz daha iyi
- El yapımı. Altyapılar birçok düğüme sahip olabilir, bu da potansiyel olarak çok sayıda kusur olduğu anlamına gelir ve raporların her yinelemede manuel olarak ayrıştırılması ve analiz edilmesi gerekir.
- Kötü kapsama. Altyapı taramasının kalitesi doğrudan güvenlik açıkları ve yazılım sürümleri hakkındaki bilgi tabanının boyutuna bağlıdır. nerede, , pazar liderleri bile kapsamlı bir bilgi tabanına sahip değildir ve ücretsiz çözümlerin veritabanlarında liderlerin sahip olmadığı birçok bilgi vardır.
- Yama ile ilgili sorunlar. Çoğu zaman, altyapı güvenlik açıklarına yama uygulamak, bir paketi güncellemek veya bir yapılandırma dosyasını değiştirmektir. Buradaki en büyük sorun, sistemin, özellikle de eski olanın, bir güncelleme sonucunda öngörülemez şekilde davranabilmesidir. Hatta üretimde canlı bir altyapı üzerinde entegrasyon testleri yapmanız gerekecek.
yaklaşımlar
Bu nasıl olabilir?
Aşağıdaki bölümlerde örnekler ve bu sorunların çoğuyla nasıl başa çıkılacağı hakkında daha fazla ayrıntıya gireceğim, ancak şimdilik çalışabileceğiniz ana alanları göstereceğim:
- Çeşitli tarama araçlarının toplanması. Çoklu tarayıcıların doğru kullanımı ile bilgi tabanında ve algılama kalitesinde önemli bir artış sağlanabilir. Tek tek çalışan tüm tarayıcıların toplamından daha fazla güvenlik açığı bulabilir, risk düzeyini daha doğru bir şekilde değerlendirebilir ve daha fazla öneride bulunabilirsiniz.
- SAST ve DAST entegrasyonu. Aralarında bilgi paylaşarak DAST kapsamını ve SAST doğruluğunu artırmak mümkündür. Kaynaktan mevcut rotalar hakkında bilgi alabilir ve DAST yardımıyla güvenlik açığının dışarıdan görünüp görünmediğini kontrol edebilirsiniz.
- Makine Öğrenimi™. 2015 yılında ben (ve ) tarayıcılara bir bilgisayar korsanı sezgisi vermek ve tarayıcıları hızlandırmak için istatistiklerin kullanılması hakkında. Bu kesinlikle gelecekte otomatikleştirilmiş güvenlik analizinin geliştirilmesi için bir besindir.
- Otomatik testler ve OpenAPI ile son entegrasyon. CI/CD ardışık düzeni içinde, HTTP proxy'leri olarak çalışan araçlara ve HTTP üzerinden çalışan işlevsel testlere dayalı bir tarama süreci oluşturmak mümkündür. OpenAPI/Swagger testleri ve sözleşmeleri, tarayıcıya veri akışlarıyla ilgili eksik bilgileri verecek, uygulamanın çeşitli durumlarda taranmasını mümkün kılacaktır.
- Doğru konfigürasyon. Her uygulama ve altyapı için, arayüzlerin sayısı ve niteliği, kullanılan teknolojiler dikkate alınarak uygun bir tarama profili oluşturmanız gerekir.
- Tarayıcı özelleştirmesi. Genellikle bir uygulama, tarayıcı değiştirilmeden taranamaz. Bir örnek, her talebin imzalanması gereken bir ödeme ağ geçididir. Tarayıcılar, ağ geçidi protokolüne bir bağlayıcı yazmadan, yanlış bir imzaya sahip istekleri akılsızca gagalar. Ayrıca, belirli bir kusur türü için özel tarayıcılar yazmak da gereklidir.
- Risk yönetimi. Çeşitli tarayıcıların kullanımı ve Varlık Yönetimi ve Tehdit Yönetimi gibi harici sistemlerle entegrasyon, risk düzeyini değerlendirmek için birden çok parametrenin kullanılmasına olanak tanıyacak ve böylece yönetim, geliştirmenin veya altyapının mevcut güvenlik durumunun yeterli bir resmini elde edebilecektir.
Bizi izlemeye devam edin ve güvenlik açığı taramasını bozalım!
Kaynak: habr.com