Seek, başlangıçta olaylara müdahalesini geliştirmek için, ancak bunu tehdit avcılığı ve saldırı yolu haritalaması dahil daha proaktif faaliyetler için kullanmak amacıyla bulut tabanlı bir güvenlik veri gölü oluşturdu.
Bulut ve ürün güvenliği başkanı Andrew Bienert, geçen yılın sonunda AWS re:Invent’e, istihdam piyasasının, AWS tarafından genel olarak kullanıma sunulan nispeten yeni bir bulut hizmeti olan Amazon Security Lake’in “ilk yinelenmesine ve kullanımına” kaldığını söyledi. geçen yıl mayıs ayında.
Seek, hem yerel AWS hem de üçüncü taraf sayısız araç ve hizmetten alınan güvenlik günlüklerini ve olay verilerini bir araya getirmenin bir yolunu arıyordu.
Bienert, “Günümüzde güvenlik ekiplerinin yönetmesi beklenen günlük verilerinin miktarı durmaksızın artıyor” dedi.
“Sektörde sahip olduğumuz inanılmaz sayıda güvenlik aracı da bu sorunu daha da artırıyor.
“Bu, birden fazla çözümü yönetme zorunluluğumuzu besliyor [and] tüm verilerimizi yönetmenin farklı yolları. Örneğin bizim için VPC akış günlüklerimizle ilgilenmenin bir yolu var, CloudTrail için başka bir yol var ve EDR’mizle çalışma şeklimiz için de başka bir yol var. [endpoint detection and response] kütükler.
“Operasyon alanındaysanız veya bir analistseniz, her zaman farklı türdeki uygulamalarla çalışmak zorunda olmak, verilerin nerede olduğunu bilmek zorunda olmak bir yüktür. Tüm bu farklı hareketli parçaların her zaman bakımının da önemsiz olmayan bir maliyeti var.”
Bienert, AWS hizmetinin ön izlemesini yaptığında güvenlik odaklı bir veri gölü oluşturmak için Seek’in veri bilimcileriyle birlikte dahili olarak çalışmaların zaten devam ettiğini söyledi.
“Bu gerçekten çabalarımıza odaklanmamıza yardımcı oldu [around] Neye yönelik tasarladığımızı,” dedi Bienert.
Bienert, Seek’in “modüler ve esnek”, değerin “zaman içinde kademeli olarak” sağlanabileceği bir veri gölü oluşturmak için yola çıktığını söyledi.
Ayrıca ilk etapta olaylara müdahaleyi iyileştirmek için kullanılabilecek, ancak zaman geçtikçe güvenlikle ilgili olan ve olmayan diğer kullanım durumlarını da desteklemek için kullanılabilecek bir göl oluşturmak istedi.
Bienert, “Açıkçası temel yetenek, olaylara müdahaledir, ancak tehdit avlama yetenekleri ve tehdit tespitine doğru genişlemek, yüksek riskli kullanıcı davranışlarına bakmak ve ayrıca saldırı yolu haritalaması gibi faaliyetleri kolaylaştırmak istedik” dedi.
“Burada fark edeceğiniz şey, çok reaktif bir güvenlik kullanım senaryosu olan olay müdahalesinden artık daha proaktif kullanım senaryolarına doğru genişlediğimizi fark edeceksiniz.”
Ekibin zamanla “veri gölünde depolanan verilerin yalnızca güvenlik kullanım senaryolarını desteklemesi gerekmediğini” fark ettiğini de sözlerine ekledi.
“Bu verilerle işin diğer bölümlerine de değer katabileceğimizi düşündük.”
Şu ana kadar güvenlik veri gölü, VPC akış günlükleri, CloudTrail, AWS Security Hub ve DNS günlüklerinin yanı sıra CrowdStrike ve Netskope gibi bazı üçüncü taraf kaynaklar da dahil olmak üzere günlük verilerinin “desteklenen yerel AWS kaynaklarını” alacak şekilde ayarlandı.
Bienert, “Ayrıca, Karbon Siyahı günlüklerinin güvenlik gölüne alınması için kendi özel kaynağımızı oluşturmak amacıyla AWS Profesyonel Hizmetler ve Carbon Black ile birlikte çalıştık” dedi.
Okta, Proofpoint, GitHub “ve diğer dahili araçların yanı sıra ek DNS ve güvenlik duvarı günlüklerinden” veri getirme çabalarıyla birlikte alma çalışmaları devam ediyor.
“Biz şu anda [also] Splunk ile bir kavram kanıtını çalıştırıyor, Security Lake ile bu entegrasyonu deniyor ve bu sorguları test ediyor.”
Security Lake’in kullanım durumlarının genişletilmesine yardımcı olmak amacıyla, “iş bağlamı” verileri için Workday’den VirusTotal ve AbuseIPDB’ye kadar diğer yayınlar entegre edilecek şekilde ayarlandı.
Analistler Amazon Athena’yı kullanarak veri gölünde SQL sorguları çalıştırıyor.
Olay araştırmaları
Bienert, Security Lake’in yardımıyla araştırılan ve sonuçta iyi huylu olduğu anlaşılan iki olaya dikkat çekti.
Bir olayda göl, Amazon GuardDuty’nin “bir siteye izinsiz erişim olayı” tespitini araştırmak için kullanıldı. [production] Özel tehdit listelerimizden birindeki kötü niyetli bir IP arayandan gelen S3 paketi.”
Bienert, “Bir süre güvenlik alanında veya operasyonlarda ya da analist olarak çalışmış olan herkes için… sizi oturup farkına varmaya sevk eden belirli olaylar vardır” dedi. “Bu da onlardan biriydi.”
Bienert, paketin müşteri verilerini içerdiğini ancak kamuya açıklanmadığını söyledi: “Bunu biliyorduk çünkü bunun olmasını engelleyecek dahili kontrollerimiz var”.
Seek, tek tek günlükleri herhangi bir sonuç almadan inceledikten sonra, tehdidin iyi huylu olup olmadığını belirlemek için o zamanlar dört haftalık olan veri gölünü kullandı.
Bienert, “Tehdit listemizdeki IP adresinin bir süre önce yeniden tahsis edildiği ortaya çıktı ve bu nedenle bunu özel tehdit listemizden kaldırmak zorunda kaldık” dedi.
Bienert’in açıkladığı ikinci bir kullanım durumu, uzlaşma soruşturmasının bir göstergesiydi.
“Tanınmış bir APT’nin bize sağladığı bazı bilgiler vardı. [advanced persistent threat] bizimki gibi şirketleri hedef alıyordu ve bize gidip arama yapmamız için bir IP adresi verilmişti. Biz bunu bazı sistemlerimizde yaptık ve hiçbir sonuç alamadık” dedi.
“Arama yapmak için eski VPC akış günlüğü sistemimizi kullanmak yerine doğrudan Security Lake’e gittik. Bunun nedeni, bunun ‘samanlıkta iğne arama’ problemi olmasıydı ve birden fazla bölgede, 350’den fazla hesapta arama yapmamız gerekiyordu ve [in] değişken bir zaman penceresi.
“Security Lake bize oldukça hızlı bir şekilde ulaşmayı başardı. Hesaplarımızdan birinde çalışan ve bu kötü amaçlı IP ile iletişim kuran bir ana bilgisayarı tespit edebildik, bu da adli soruşturma başlattığımız anlamına geliyor.
“Bir kez daha iyi huylu olduğu ortaya çıktı, bu da bir şans çünkü bunun hakkında konuşabiliyorum. Daha sonra bu soruşturmayı sonlandırabildik.”