
Siber Pandemi devam ediyor. SolarWinds Orion yazılımına yerleştirilen arka kapıyı kullanarak, bu yazılımı kullanan 18.000 kuruma sızabilme imkanı bulan siber korsanlar faaliyetlerine devam ediyor. Her gün yeni gelişmeler duyuyoruz, daha da duymaya devam edeceğiz. Bir linkedin paylaşımına da yaptığım yorumda bu vakadan çıkartılacak dersleri konuşmamız gerektiğini dile getirmiştim. Benim çağrım çok rağbet görmedi ancak sağ olsun SANS bu konuda bir etkinlik yaptı. 1 saat 40 dakika süren etkinlikte konunun uzmanları Solarwinds vakasından alınacak dersler ile ilgili vakanın neden ve nasıl gerçekleştiği ile ilgili çok değerli paylaşımlarda bulundular. Etkinlikten kendime çıkardığım notlar, izleyip benim gibi not alan varsa lütfen yorumlar bölümüne eklesin.
Red Canary’de istihbarat direktörü olarak çalışan Katie Nickels sunumundan. SolarWinds vakasından öğrenilen önemli konular;
Birden fazla güvenlik ihlalini içeriyor
Saldırılardan etkilenen kurumlar;
- Fire Eye
- SolarWinds
- Palo Alto
- U.S. devlet kurumları
- Cisco
- Mimecast
ve diğerleri. Her geçen gün bu listeye eklenecek bir çok yeni kurum ortaya çıkıyor…
İsimlere değil tehdite odaklanın
Vakalara verilen isimler;
- Solorigate – Microsoft
- SolarStorm – Palo Alto
Cluster ve grup isimleri;
- UNC2452 – FireEye
- Derka Halo – Volexity
- StellarParticle – CrowdStrike
Hiçbir isim saldırıyla ilişkilendirilen bir ülkenin ismini içermiyor!
Vakada adı geçen zararlı yazılımlar;
- SUNSPOT
- SUNBURST
- TEARDROP
- Raindrop
- SUPERNOVA
- COSMICGALE
Bu şekilde farklı isimler farklı anlamlar kullanmak konuya odaklanmayı zorlaştırıyor. Bunun yerine saldırı kaynağının ismini kullanmak gerçek tehdidi anlamak için daha uygun olur.
Tehdit modelleme her bir kuruma göre farklılık gösterir
Her bir kurum faaliyet alanına göre yüz yüze kalacağı tehditlerde farklılık gösterecektir. Örneğin bir yazılım geliştirme şirketi ile bir bulut hizmet sağlayıcısı şirketini etkileyecek tehditler farklılık gösterecektir. SolarWinds vakasında ortaya çıkan saldırıları bu gözle analiz etmeli ve size özel tehdit modelinizi oluşturmalısınız.
Tehdit Modelleme konusu siber tehditlere hazırlık anlamında kurumlara önemli bir yaklaşım sağlamaktadır. Her kurum hatta kurumlar içindeki farklı iş birimleri kendi tehdit modellerini oluşturmalılar. Hatta bireysel olarak bizlerin de bir tehdit modelinin olması gerekir. Bu konuda detaylı bilgiye şu adresten bakabilirsiniz.
CISA tehdit avı bölümünde, Siber Savunma Koordinatörü olarak çalışan Mark Bristow sunumundan
SolarWinds vakasından alınacak önemli dersler
- Sabırlı, ve çok donanımlı bir saldırganın işi
- Saldırgan, tedarik zincirindeki ve kimlik yönetimi sürecindeki bir zayıflığı kullanmış. Özellikle kimlik yönetimi ele geçirildikten sonra saldırganların yakalanmasının mümkün olmadığı belirtiliyor.
- Mark saldırının konunun sadece SolarWinds ile sınırlı olmadığını belirtiyor
- Saldırıda tedarik zinciri dışı yöntemlerde kullanılmış
- Saldırının tespiti ve nasıl takip edileceğinin çok zor olduğu ve olay müdahale ekiplerinin işlerinin daha da kompleks hale geldiğini belirtiyor Mark. Burada kritik bir konu “Olay müdahale ekipleri alınacak aksiyonlarla ilgili iletişimi yine klasik BT altyapıları üzerinden yapıyorlarsa örneğin eposta, saldırganlar zaten herkesin elektronik postalarını okuyabildikleri için müdahale yöntemleri ve aksiyonlarla ilgili anında haberdar olabiliyorlar. Bu nedenle bu tip durumlarda daha önce hiç kullanılmayan ve güvenli olduğuna inandığınız bir iletişim kanalı kullanmamızı öneriyor.
Olayın tarihçesi
Tarihçede görüleceği gibi; saldırganların SolarWinds yazılımına ilk erişimleri 4 Ağustos 2019 tarihinde gerçekleşiyor. Saldırganların zararlı yazılımı SolarWinds Orion yazılımı için enjekte etmeleri ile olayın tespit edilip duyurulması arasında 4 aydan uzun bir süre geçiyor.
Mark özellikle yazılım firmalarına çok güvendiğimizi ve hiç bir güvenlik kontrolünden geçirmeden yüzlerce hatta binlerce yazılım şu anda şirketlerin altyapısında çalışıyor. SolarWinds vakasına benzer bir vakanın başka yazılımlarda olmadığını kim iddia edebilir? Bu nedenle bir yazılım alındığında olabildiğince farklı güvenlik testlerinden geçirilmesi gerekiyor.
Kimlik (Identity) her şeydir
Firewall (ateş duvarı) öldü. Kimliğin yeni sınır (perimeter) olduğunu belirtiyor Mark. Özellikle kimlik yönetimi kapsamında kullandığımız sistem ve süreçlerin güvenliğinin sağlanması konusunda; kimlik yönetim sistemlerine yetkisiz erişimlerden uzak tutmalı ve saldırganlardan gizlenmesi gerektiğinin altını çiziyor.
Ayrıca kurumunuzda kimlik yönetimi sistemini çok değerli bir mücevhere benzetebilirsiniz. Bu mücevheri kötü niyetli kişilerin erişiminden korumak için neler yapabilirsiniz düşünün. Sadece bu sistemlere özel bir tehdit modeli oluşturmakla başlayabilirsiniz mesela! Ayrıca Zero Trust ve SDP başlıklı yazımızı okumanızı öneririm.
Yakalamak için fırsatlar
Bu tür saldırıları nasıl yakalayabiliriz? Nasıl anlayabiliriz kurumumuz içerisinde sistemlerin uygulamaların ele geçirildiğini?
- Ağ trafiğinizde bir baz oluşturup bu baz dan olası sapmaları takip edip sorgulayabilirsiniz. Örneğin daha önce bir ülkeye hiç bir erişim yokken bir anda bir erişim yapılmaya başlanmışsa bu bir anomalidir ve detaylıca izlenmelidir.
- Ayrıca kullanıcı davranışları için de bir baz oluşturup burada olan anomalileri takip edebilirsiniz.
- Yetkili bir kullanıcı daha önce hiç sisteme girmediği bir zamanda sisteme girmeye çalışıyorsa bunu anlamalısınız.
- Bir kullanıcı 5 dakika önce Ankara dan sisteme VPN ile girmiş. 5 dakika sonra aynı şekilde İstanbul’dan sisteme girmiş ise, şüphelenmelisiniz.
- Daha önce hiç bir adrese gönderilmemiş bir mail gönderilmiş ve bu adres de farklı bir ülkedeyse,…
gibi bir çok anomaliyi takip ederek bu tür saldırılardan haberdar olabilirsiniz.
Sorulması gereken kritik sorular
- Kime güvendiğinizi biliyor musunuz? En son ne zaman doğruladınız?
- Sistem ve uygulamalarınıza erişimlerin görünürlüğü yeterli mi? Tüm erişim denemelerini görüyor musunuz?
- Eğer ana ağınız ele geçirildi ise, çalışabiliyor musunuz?
- En son felaketten kurtarma denemesi yaptınız?
Olay müdahale doğrular, yanlışlar
SANS’in kıdemli eğitmenlerinden Mike Murr’un sunumundan notlar;
Mike sunumunda SolarWinds vakasından etkilenen kurumlarda olay müdahale sürecinde en iyi ve en kötü organizasyonel yaklaşımları analiz ediyor. Kötü yaklaşımlar;
- Biz de SolarWinds çalışmıyor! (Peki tedarik zincirinde birisi SolarWinds kullanıyorsa? Olaydan etkilenen kurumların %30’u SolarWinds kullanmıyor!)
- Problemi yok sayma! Bizi neden hedeflesinler? SolarWinds güncellemesini almadık!
- Olayın kapsamının yeterince belirlenememesi. Yamaları uyguladık artık güvendeyiz! Zararlı kaynak alan adlarını blokladık!

SolarWinds bizde çalışmıyor şeklinde olayı ele alan birisinin yukardaki resme bakması yeterli olacaktır. Siz de yok ama iş ortağınızda, müşterinizde,… olabilir.
Bakış açınızı değiştirin
- Artık sorumlu olduğunuz risk kapsamı sadece kurum ağı sınırları değil. İçinde bulunduğunuz direkt yada dolaylı etkileşimde olduğunuz ekosistem artık risk kapsamınız!
- Bu ekosistem de bulunan kurumların barındırdıkları hangi veriler sizin de sorumluluğunuzda?
- İş sürekliliğinizi etkileyecek nedenleri biliyor musunuz? Örneğin hammadde tedariği yaptığınız bir iş ortağınızın başına bir olay gelirse iş sürekliliğiniz nasıl devam edecek?
- İmkansız görünen senaryoları bulun ve test edin.
- Kurumsal süreçler saldırı altında, hepsini gözden geçirin. Özellikle yetkili kullanıcı erişim süreci ve yönetimini mercek altına alın.
- Dijital ortamınıza hakim olun. Donanım ve yazılım envanteri, versiyonlar, konfigürasyonları hakkında mutlaka güncel bilgilere anında erişebilme imkanınız olsun.
- Günlük kayıtları (Log) çok önemli, özellikle DNS erişimleri mutlaka kayıt altına alın ve değiştirilemez bir şekilde saklayın ve benzer bir olay durumunda bu kayıtlara erişebileceğinizden emin olun.
SANS eğitmenlerinden Dr. Johannes Ulrich’in sunumundan;
Hepsi bir arada
SolarWinds vakasında daha önce saldırganların tek tek kullandığı aşağıda listelenen bazı saldırı türlerinin tamamı kullanılmış.
- İleri düzey düşman teknikleri
- Tedarik zinciri ağı kullanımı
- İçerde uzun süre bekleme
- Birden fazla kurumun etkilenmesi
Yazılım geliştirme ortamınızı koruyun
Dr. Ulrich özellikle yazılım geliştirme sürecindeki tedarik ağının altını çiziyor. Yazılım geliştirme sürecinde onlarca farklı yazılım kullanıyoruz, bunların güvenli olup olmadığını nasıl anlıyoruz? Sizin geliştirdiğiniz yazılımı kullanan kurum yada kişilerin de güvenliklerinden sorumlusunuz.
- Yazılım geliştirme sürecinde kullandığınız tüm araçları listeleyin ve bunların güvenli olduklarından emin olun
- Yazdığınız kodları canlı kullanıma almadan mutlaka statik güvenlik kod analizlerini yapın
- Kullandığınız 3.Parti araçların kodlarının güvenliğinden emin olun
- Güvenli kod geliştirme sürecinizi gözden geçirin, yoksa oluşturun. Her satır koda güvenlik testinden geçsin
Dijital tarihte bu çapta ve bu kadar geniş etki yaratan bir saldırı olmadığını biliyoruz. Ancak bundan sonra benzer saldırılara hazırlıklı olun. Birileri bu vakada kullanılan yöntemleri kopyalayacaktır!
Etkinliği izlemek isterseniz bu adresten izleyebilirsiniz…