Bulut Denetim Kayıtlarından BigQuery ve Chronicle SIEM ile Gerçek Zamanlı Tehdit Tespiti

Bulut ortamlarında güvenliği sağlamak, günümüzün karmaşık siber tehdit ortamında büyük bir zorluktur. Bu makale, Google Cloud Platform’daki denetim kayıtlarını BigQuery ile analiz ederek ve Chronicle SIEM ile gerçek zamanlı tehdit tespiti yaparak güvenlik duruşunuzu nasıl güçlendirebileceğinizi adım adım açıklıyor. Böylece, anormallikleri hızla belirleyip müdahale edebilirsiniz.

Bulut bilişim, işletmelerin çevikliğini ve ölçeklenebilirliğini artırırken, siber güvenlik cephesinde yeni ve karmaşık zorlukları da beraberinde getirmektedir. Geleneksel güvenlik duvarları ve uç nokta koruma sistemleri, artık dinamik ve dağıtık bulut ortamlarındaki tüm tehdit vektörlerini kapsamakta yetersiz kalmaktadır. Peki, bu uçsuz bucaksız dijital evrende güvenlik nasıl sağlanacak? İşte tam da bu noktada, bulut denetim kayıtları devreye giriyor. Denetim kayıtları, bulut kaynaklarınız üzerinde gerçekleşen her türlü aktivitenin, bir nevi “kara kutu” kaydı gibidir.

Bir sistem yöneticisinin kimlik doğrulama girişimi, bir kullanıcının veri indirme işlemi, bir servisin yapılandırma değişikliği veya şüpheli bir IP adresinden gelen bağlantı denemeleri… Tüm bu olaylar, denetim kayıtlarına işlenir. Bu kayıtlar, sadece yasal uyumluluk gereksinimlerini karşılamakla kalmaz, aynı zamanda potansiyel güvenlik ihlallerini, içeriden gelen tehditleri veya hatalı yapılandırmaları ortaya çıkarmak için paha biçilmez birer veri kaynağıdır. Ancak bu kayıtların hacmi, özellikle büyük ölçekli bulut dağıtımlarında, hızla petabayt seviyelerine ulaşabilir. Bu kadar büyük bir veri yığınını manuel olarak incelemek veya geleneksel araçlarla anlamlı içgörüler elde etmek neredeyse imkansızdır. Bu durum, bizi daha gelişmiş ve otomatikleştirilmiş çözümlere itiyor.

Güvenlik ekipleri, bulut ortamlarındaki her anı gözlemleyebilmek, anormallikleri gerçek zamanlı olarak tespit edebilmek ve proaktif önlemler alabilmek için güçlü analitik yeteneklere ihtiyaç duyarlar. Aksi takdirde, kritik bir olay, fark edilmeden saatler, günler hatta haftalarca sistemde kalabilir ve geri döndürülemez zararlara yol açabilir. Örneğin, yetkisiz bir kullanıcının ayrıcalıklarını yükseltmesi veya kritik bir veri tabanına erişmesi gibi olaylar, genellikle denetim kayıtlarında gizli kalır. Bu olayları hızla tespit etmek, bir siber saldırının yayılmasını durdurmak ve potansiyel veri ihlallerini önlemek için kritik öneme sahiptir. İşte bu nedenle, bulut denetim kayıtlarının toplanması, depolanması, analiz edilmesi ve bunlardan anlamlı güvenlik içgörülerinin çıkarılması, modern siber güvenlik stratejisinin temel taşlarından biridir. Google Cloud ekosisteminde BigQuery ve Chronicle SIEM gibi araçlar, bu zorlu görevi kolaylaştırmak için bir araya gelerek, siber güvenlik ekiplerine süper güçler kazandırır.

Temel Taşlar: BigQuery ve Chronicle SIEM Nedir ve Neden Birlikte Güçlüler?

Bulut güvenliği yolculuğumuzda, denetim kayıtlarını anlamlı içgörülere dönüştürmek için iki temel araca güveneceğiz: Google Cloud’un güçlü veri analizi platformu BigQuery ve gelişmiş güvenlik bilgi ve olay yönetimi (SIEM) çözümü Chronicle SIEM. Bu iki çözüm, bir araya geldiğinde, bulut ortamınızdaki siber tehditlere karşı eşsiz bir görünürlük ve tepki yeteneği sunar. Şimdi bu temel taşları daha yakından inceleyelim.

Google Cloud Audit Logs: Güvenlik Hikayenizin Başlangıcı

Google Cloud Audit Logs (Denetim Kayıtları), GCP ortamınızda gerçekleşen hemen her etkileşimin kapsamlı, denetlenebilir ve değişmez bir kaydını sunar. Bu kayıtlar, kimin, ne zaman, nerede ve hangi kaynaktan ne tür bir işlem yaptığını gösteren kritik bilgiler içerir. GCP, dört ana denetim kaydı türü sunar:

• Yönetici Etkinliği Denetim Kayıtları (Admin Activity Audit Logs): Yöneticiler tarafından yapılan yapılandırma değişiklikleri, kaynak oluşturma veya silme gibi tüm yönetimsel işlemleri kaydeder. Örneğin, bir sanal makinenin oluşturulması veya bir IAM politikasının değiştirilmesi. Bu kayıtlar, varsayılan olarak etkinleştirilmiştir ve ücret talep edilmez.
• Veri Erişimi Denetim Kayıtları (Data Access Audit Logs): Kullanıcıların ve hizmet hesaplarının verilerinize nasıl eriştiğini ve bunları değiştirdiğini gösterir. Örneğin, BigQuery tablolarına yapılan sorgular veya Cloud Storage nesnelerine erişimler. Bu kayıtlar varsayılan olarak kapalıdır ve etkinleştirilmesi gerekebilir; bazıları ücretli olabilir.
• Sistem Olayları Denetim Kayıtları (System Event Audit Logs): Google’ın kendi sistemleri tarafından GCP kaynaklarında yapılan değişiklikleri kaydeder. Örneğin, Compute Engine’deki bir sanal makinenin otomatik olarak yeniden başlatılması.
• Politika Reddi Denetim Kayıtları (Policy Denied Audit Logs): Bir kullanıcının veya hizmet hesabının, güvenlik politikaları nedeniyle bir eylemi gerçekleştiremediği durumlarda oluşur. Bu, yetkisiz erişim denemelerini tespit etmek için çok değerlidir.

Bu kayıtlar, bulut ortamınızdaki tüm olayların ayrıntılı bir kronolojisini sağlayarak, güvenlik analistlerinin “ne oldu, ne zaman oldu ve kim yaptı?” sorularına yanıt bulmalarına olanak tanır. Olay müdahalesi, adli analiz ve uyumluluk denetimleri için vazgeçilmez birer kaynaktır.

Büyük Veri Analizinde Yeni Nesil: BigQuery’nin Gücü Nedir?

Bulut denetim kayıtlarının hacmi akıl almaz boyutlara ulaştığında, geleneksel veri tabanları veya analitik araçlar yetersiz kalır. İşte tam bu noktada Google Cloud’un tam olarak yönetilen, sunucusuz ve son derece ölçeklenebilir veri ambarı BigQuery sahneye çıkar. BigQuery, petabaytlarca veriyi saniyeler içinde analiz edebilme yeteneğiyle öne çıkar.

BigQuery’nin temel özellikleri ve güvenlik operasyonları için sağladığı faydalar şunlardır:

• Sunucusuz Mimari: Altyapı yönetimi endişesi olmadan veri analizi yapmanızı sağlar. Ölçeklendirme Google tarafından otomatik olarak yönetilir.
• Yüksek Ölçeklenebilirlik: Onlarca terabayt veya petabayt boyutundaki veri kümelerini kolayca işleyebilir. Bu, uzun vadeli denetim kayıtlarını saklamak ve analiz etmek için idealdir.
• SQL Desteği: Standart SQL sözdizimini kullanarak karmaşık sorgular yazabilir, bu da veri analistlerinin ve güvenlik uzmanlarının kolayca adapte olmasını sağlar.
• Gerçek Zamanlı Analiz: Akış API’si sayesinde verileri gerçek zamanlı olarak alabilir ve neredeyse anında sorgulayabilirsiniz. Bu, anomali tespiti ve hızlı olay müdahalesi için kritiktir.
• BigQuery ML: Makine öğrenimi modellerini SQL kullanarak doğrudan BigQuery içinde oluşturmanıza ve çalıştırmanıza olanak tanır. Bu, anormal davranışları ve bilinmeyen tehditleri tespit etmek için güçlü bir araçtır.

BigQuery, güvenlik analistlerinin milyonlarca log kaydı arasında iğne aramak yerine, belirli tehdit göstergelerini hızla bulmalarına, korelasyonlar kurmalarına ve karmaşık saldırı senaryolarını aydınlatmalarına yardımcı olur.

Güvenlik Operasyonlarının Merkezi: Chronicle SIEM Neden Önemli?

Chronicle SIEM (Security Information and Event Management), Google Cloud’un siber güvenlik veri platformudur. Temel amacı, işletmelerin güvenlik verilerini petabayt ölçeğinde ve uygun maliyetle toplamasına, saklamasına ve analiz etmesine olanak tanımaktır. Geleneksel SIEM çözümlerinin karşılaştığı ölçek, maliyet ve performans sorunlarına çözüm sunar.

Chronicle SIEM’in güvenlik operasyonları için kilit avantajları:

• Petabayt Ölçeğinde Veri Alımı ve Saklama: Tüm güvenlik telemetrinizi (ağ akışları, DNS kayıtları, uç nokta logları, bulut denetim kayıtları vb.) maliyet etkin bir şekilde toplayabilir ve saklayabilir. Bu, “kaynak kısıtlamaları nedeniyle logları atmak” gibi kötü uygulamaları ortadan kaldırır.
• Yüksek Hızlı Arama: Büyük veri hacimlerinde bile saniyeler içinde arama yapabilmenizi sağlar, bu da olay müdahale sürelerini önemli ölçüde kısaltır.
• Gelişmiş Tehdit Algılama Motoru (YARA-L): Esnek YARA-L dilini kullanarak kendi özel algılama kurallarınızı yazmanıza olanak tanır. Bu sayede, bilinen ve bilinmeyen tehditleri proaktif olarak tespit edebilirsiniz.
• Tehdit İstihbaratı Entegrasyonu: Google’ın ve diğer üçüncü taraf tehdit istihbaratı kaynaklarıyla entegre olarak, şüpheli IP adreslerini, alan adlarını ve dosya hash’lerini otomatik olarak işaretler.
• İlişkilendirme ve Korelasyon: Farklı kaynaklardan gelen olayları otomatik olarak ilişkilendirerek, bir saldırının tüm aşamalarını bir arada görmenizi sağlar.

BigQuery, derinlemesine analitik yetenekleriyle bir “veri laboratuvarı” görevi görürken, Chronicle SIEM, tüm güvenlik verilerinizin toplandığı, analiz edildiği ve tehditlerin gerçek zamanlı olarak tespit edildiği “operasyonel güvenlik merkezi”dir. Bu iki araç, birleşerek, denetim kayıtlarından gerçek zamanlı tehdit tespiti için sağlam ve ölçeklenebilir bir omurga oluşturur. Bir sonraki bölümde, bu entegrasyonun adım adım nasıl kurulacağını inceleyeceğiz.

Adım Adım Entegrasyon: Denetim Kayıtlarını BigQuery’ye Nasıl Aktarırsınız?

Güvenlik verilerinin analiz edilebilmesi için öncelikle merkezi bir depoya aktarılması gerekir. Google Cloud Platform’da (GCP), denetim kayıtlarını BigQuery’ye aktarmanın en etkili yolu, Log Router’ı kullanmaktır. Log Router, GCP’deki çeşitli kaynaklardan gelen logları (denetim kayıtları dahil) filtrelemenizi, yönlendirmenizi ve depolamanızı sağlayan merkezi bir hizmettir. Bu bölümde, denetim kayıtlarınızı BigQuery’ye nasıl aktaracağınızı adım adım inceleyeceğiz.

Log Router ile BigQuery Veri Kümesi Oluşturma

Log Router (eski adıyla Log Sinks), belirli kriterlere uyan logları seçmenize ve bunları bir hedefe (örneğin BigQuery, Cloud Storage veya Pub/Sub) göndermenize olanak tanır. İşte adım adım süreç:

1. BigQuery Veri Kümesi Oluşturma: Öncelikle, denetim kayıtlarınızı depolayacağınız bir BigQuery veri kümesine ihtiyacınız var. Google Cloud Console’da BigQuery’ye gidin, projenizi seçin ve ardından “Veri Kümesi Oluştur” butonuna tıklayın. Veri kümenize anlamlı bir ad verin (örneğin, audit_logs), coğrafi konumunu seçin ve veri kümesinin ömrünü belirleyebilirsiniz.
2. Log Router Sink Oluşturma: Google Cloud Console’da “Logging” > “Log Router” bölümüne gidin. Burada, “Sink Oluştur” (Create Sink) butonuna tıklayın.
3. Sink Adı ve Açıklama: Sink’inize benzersiz bir ad verin (örneğin, audit-logs-to-bigquery) ve isteğe bağlı bir açıklama ekleyin.
4. Sink Hedefi: “Sink Hedefi” olarak “BigQuery veri kümesi” seçeneğini işaretleyin. Daha sonra, açılır menüden daha önce oluşturduğunuz audit_logs veri kümesini seçin.
5. Filtreleme: Bu adım kritik öneme sahiptir. Hangi logların BigQuery’ye gönderileceğini burada belirlersiniz. Tüm denetim kayıtlarını göndermek isteyebilirsiniz veya sadece belirli türdeki kayıtları (örneğin, yönetici etkinliği veya belirli bir hizmete ait kayıtlar) seçebilirsiniz. İşte bazı örnek filtreler:
• Tüm Denetim Kayıtlarını İçeren Temel Filtre:

  
  logName:"cloudaudit.googleapis.com"
                      

• Yönetici Etkinliği ve Veri Erişimi Denetim Kayıtlarını İçeren Filtre:

  
  logName:"cloudaudit.googleapis.com/activity" OR logName:"cloudaudit.googleapis.com/data_access"
                      

• Belirli Bir Projeden ve Belirli Bir Hizmetten Gelen Kayıtları Filtreleme (Örnek: Compute Engine):

  
  resource.type="gce_instance" AND protoPayload.serviceName="compute.googleapis.com"
                      

• Şüpheli Yöntem Çağrılarını Tespit Etmek İçin Gelişmiş Filtre (Örnek: IAM politikası değişikliği):

  
  protoPayload.methodName="google.iam.admin.v1.IAM.SetIAMPolicy" OR
  protoPayload.methodName="google.cloud.resourcemanager.v1.Projects.setIamPolicy"
                      

6. Sink Oluşturma: Son olarak, "Sink Oluştur" butonuna tıklayarak işlemi tamamlayın. Bu işlemden sonra, belirlenen filtreye uyan tüm yeni denetim kayıtları otomatik olarak BigQuery veri kümenize akmaya başlayacaktır.

BigQuery'de Veri Yapısı ve Optimizasyon İpuçları

Denetim kayıtlarınız BigQuery'ye aktarıldığında, her bir log kaydı bir JSON nesnesi olarak depolanır ve BigQuery, bu JSON verilerini otomatik olarak şemalandırır. Ancak, verimlilik ve maliyet açısından bazı optimizasyonlar yapmanız faydalı olacaktır:

• Partitioning (Bölümleme): Log verileri genellikle zaman damgasına (timestamp) göre sorgulanır. BigQuery tablolarını bir zaman damgası sütununa göre bölümlemek, sorgu performansını artırır ve sorgulanan veri miktarını azaltarak maliyetleri düşürür. Örneğin, timestamp sütununu kullanarak günlük veya saatlik bölümlemeler oluşturabilirsiniz.
• Clustering (Kümeleme): Bölümleme ile birlikte kümeleme kullanmak, sorguların daha da optimize edilmesine yardımcı olur. Genellikle, resource.type, protoPayload.methodName veya principalEmail gibi sıkça filtrelediğiniz sütunlara göre kümeleme yapabilirsiniz.
• Maliyet Optimizasyonu: BigQuery, sorgulanan veri miktarına göre ücretlendirildiğinden, verimli sorgular yazmak çok önemlidir. Sadece ihtiyacınız olan sütunları seçin (SELECT * kullanmaktan kaçının) ve sorgularınızı bölümleme ve kümeleme anahtarlarını içerecek şekilde optimize edin.

Örneğin, BigQuery'de denetim kayıtlarınızın nasıl görünebileceğine dair basitleştirilmiş bir SQL sorgusu:

SELECT
    timestamp,
    protoPayload.authenticationInfo.principalEmail AS user_email,
    protoPayload.methodName AS action,
    protoPayload.resourceName AS resource,
    resource.type AS resource_type,
    resource.labels.project_id AS project_id
FROM
    your_project_id.audit_logs.cloudaudit_googleapis_com_activity_* -- Bölümlenmiş tablo için joker karakter
WHERE
    _PARTITIONTIME BETWEEN TIMESTAMP('2023-10-01') AND TIMESTAMP('2023-10-02')
    AND protoPayload.methodName = 'v1.compute.instances.insert'
LIMIT 100;
    

Bu sorgu, belirli bir tarih aralığında Compute Engine örneği oluşturma eylemlerini listeler. protoPayload alanı, denetim kayıtlarının temel bilgi yükünü içerir ve genellikle derinlemesine analiz için en zengin veriyi barındırır.

Gerçek Zamanlı Tehdit Tespiti İçin BigQuery'de Analizler Nasıl Geliştirilir?

Denetim kayıtlarınızı BigQuery'ye başarıyla aktardıktan sonra, sıra bu büyük veri havuzunu aktif bir tehdit avı ve tespit aracına dönüştürmeye geliyor. BigQuery'nin güçlü SQL yetenekleri ve makine öğrenimi entegrasyonu (BigQuery ML), potansiyel güvenlik olaylarını ortaya çıkarmak için olağanüstü fırsatlar sunar. Bu bölümde, BigQuery'de şüpheli aktiviteleri tespit etmek için nasıl sorgular ve analizler geliştirebileceğinizi inceleyeceğiz.

Şüpheli Aktiviteleri Tespit Etmeye Yönelik SQL Sorguları

BigQuery'de tehdit tespiti, genellikle belirli kalıpları, eşikleri veya anormallikleri arayan iyi tanımlanmış SQL sorgularıyla başlar. İşte yaygın güvenlik senaryolarını tespit etmek için kullanabileceğiniz bazı örnek sorgular:

1. Alışılmadık Konumdan Yönetici Etkinliği Tespiti: Bir yöneticinin genellikle oturum açmadığı veya kaynak oluşturmadığı bir coğrafi konumdan gelen etkinlikler, hesap ele geçirme belirtisi olabilir.

SELECT
    timestamp,
    protoPayload.authenticationInfo.principalEmail AS user_email,
    protoPayload.methodName AS action,
    protoPayload.resourceName AS resource,
    jsonPayload.metadata.request.callerIp AS caller_ip,
    net.IP_TO_STRING(NET.IP_FROM_STRING(jsonPayload.metadata.request.callerIp)) AS caller_ip_string,
    FROM your_project_id.audit_logs.cloudaudit_googleapis_com_activity_*
WHERE
    _PARTITIONTIME BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY) AND CURRENT_TIMESTAMP()
    AND protoPayload.authenticationInfo.principalEmail IN ('admin@example.com', 'security@example.com') -- Hedef yöneticiler
    AND NOT REGEXP_CONTAINS(jsonPayload.metadata.request.callerIp, '^(192\\.168\\.|10\\.|172\\.(1[6-9]|2[0-9]|3[0-1])\\.)') -- İç IP'leri filtrele
    AND NOT EXISTS (
        SELECT 1
        FROM your_project_id.trusted_ips.admin_allowed_ips AS trusted -- Güvenilir IP'lerin olduğu bir tablo varsayalım
        WHERE trusted.ip = NET.IP_FROM_STRING(jsonPayload.metadata.request.callerIp)
    )
ORDER BY
    timestamp DESC;
        

Açıklama: Bu sorgu, son 7 gün içinde belirli yönetici e-postalarından gelen ve önceden tanımlanmış güvenilir IP adresleri listesinde bulunmayan IP'lerden kaynaklanan etkinlikleri arar. İç ağ IP aralıklarını da filtreleyerek dışarıdan gelen anormal bağlantıları hedefler.

2. Kısa Sürede Çok Sayıda Başarısız Oturum Açma Denemesi (Brute-Force Tespiti): Belirli bir kullanıcı veya hizmet hesabı için kısa bir zaman diliminde çok sayıda başarısız oturum açma girişimi, bir kaba kuvvet saldırısının göstergesi olabilir.

SELECT
    timestamp,
    protoPayload.authenticationInfo.principalEmail AS user_email,
    count(*) AS failed_attempts
FROM
    your_project_id.audit_logs.cloudaudit_googleapis_com_activity_*
WHERE
    _PARTITIONTIME BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR) AND CURRENT_TIMESTAMP()
    AND protoPayload.methodName = 'google.cloud.iam.v1.IAM.CheckPolicy' -- veya diğer kimlik doğrulama metodları
    AND protoPayload.status.code = 'PERMISSION_DENIED'
GROUP BY
    user_email, TIMESTAMP_TRUNC(timestamp, MINUTE)
HAVING
    failed_attempts > 5 -- 1 dakika içinde 5'ten fazla başarısız deneme
ORDER BY
    failed_attempts DESC;
        

Açıklama: Bu sorgu, son bir saat içinde, her bir dakika diliminde 5'ten fazla başarısız izin denemesi olan kullanıcıları bulur. Bu, bir hizmet hesabı veya kullanıcı hesabına yönelik kaba kuvvet saldırılarını tespit edebilir.

3. Büyük Ölçekli Kaynak Oluşturma veya Silme (Anormal Davranış Tespiti): Normal operasyonel kalıpların dışında ani ve büyük ölçekli sanal makine, depolama kovası veya diğer kaynakların oluşturulması/silinmesi, şüpheli aktiviteyi gösterebilir (örn. fidye yazılımı veya kaynak sömürüsü).

SELECT
    timestamp,
    protoPayload.authenticationInfo.principalEmail AS user_email,
    protoPayload.methodName AS action,
    COUNT(DISTINCT protoPayload.resourceName) AS distinct_resources_affected
FROM
    your_project_id.audit_logs.cloudaudit_googleapis_com_activity_*
WHERE
    _PARTITIONTIME BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 MINUTE) AND CURRENT_TIMESTAMP()
    AND protoPayload.methodName IN (
        'v1.compute.instances.insert',
        'v1.compute.disks.insert',
        'google.storage.v1.storage.objects.delete',
        'google.storage.v1.storage.buckets.delete'
    )
GROUP BY
    user_email, action, TIMESTAMP_TRUNC(timestamp, MINUTE)
HAVING
    distinct_resources_affected > 10 -- 30 dakika içinde 10'dan fazla farklı kaynak üzerinde işlem
ORDER BY
    distinct_resources_affected DESC;
        

Açıklama: Bu sorgu, son 30 dakika içinde 10'dan fazla farklı kaynağı etkileyen büyük ölçekli oluşturma veya silme işlemlerini arar. Bu, bir fidye yazılımının veri silmesi veya kripto madenciliği için yeni VM'ler oluşturulması gibi senaryoları işaret edebilir.

BigQuery ML ile Anormal Davranış Tespiti

Yukarıdaki SQL sorguları belirli kalıplara dayanırken, BigQuery ML (Makine Öğrenimi), verilerdeki gizli anomalileri ve normalden sapmaları tespit etmek için daha gelişmiş bir yaklaşım sunar. Kullanıcı davranış analizi veya zaman serisi anomalisi gibi senaryolarda BigQuery ML oldukça etkilidir.

Örneğin, bir kullanıcının BigQuery'de sorguladığı veri miktarının normalden fazla olup olmadığını tespit edebiliriz:

-- 1. Kullanıcı başına günlük sorgulanan bayt miktarını hesapla
CREATE OR REPLACE MODEL your_project_id.bqml_models.user_query_anomaly_model
OPTIONS(model_type='KMEANS', num_clusters=5, standardize_features=TRUE) AS
SELECT
    user_email,
    SUM(total_bytes_processed) AS total_bytes_queried_daily
FROM
    your_project_id.audit_logs.cloudaudit_googleapis_com_activity_*
WHERE
    _PARTITIONTIME BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY) AND CURRENT_TIMESTAMP()
    AND protoPayload.serviceName = 'bigquery.googleapis.com'
    AND protoPayload.methodName = 'google.cloud.bigquery.v2.JobService.Query'
GROUP BY
    user_email, DATE(timestamp);

-- 2. Yeni verilerle anomali tespiti yap (hangi kümeye ait olduğunu bul)
SELECT
    ML.PREDICT(
        (SELECT * FROM your_project_id.bqml_models.user_query_anomaly_model),
        (SELECT
            protoPayload.authenticationInfo.principalEmail AS user_email,
            SUM(total_bytes_processed) AS total_bytes_queried_daily
        FROM
            your_project_id.audit_logs.cloudaudit_googleapis_com_activity_*
        WHERE
            _PARTITIONTIME BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY) AND CURRENT_TIMESTAMP()
            AND protoPayload.serviceName = 'bigquery.googleapis.com'
            AND protoPayload.methodName = 'google.cloud.bigquery.v2.JobService.Query'
        GROUP BY
            user_email, DATE(timestamp)
        )
    ) AS predicted_cluster,
    user_email,
    total_bytes_queried_daily
FROM
    (SELECT
        protoPayload.authenticationInfo.principalEmail AS user_email,
        SUM(total_bytes_processed) AS total_bytes_queried_daily
    FROM
        your_project_id.audit_logs.cloudaudit_googleapis_com_activity_*
    WHERE
        _PARTITIONTIME BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY) AND CURRENT_TIMESTAMP()
        AND protoPayload.serviceName = 'bigquery.googleapis.com'
        AND protoPayload.methodName = 'google.cloud.bigquery.v2.JobService.Query'
    GROUP BY
        user_email, DATE(timestamp)
    ) AS daily_data
ORDER BY
    total_bytes_queried_daily DESC;
    

Açıklama: Bu örnek, K-Means kümeleme modelini kullanarak, kullanıcıların BigQuery'de günlük olarak sorguladığı veri miktarındaki anormallikleri tespit etmeye çalışır. Bir kullanıcının alışılmadık bir kümeye düşmesi, potansiyel bir veri sömürüsünü veya yetkisiz erişimi işaret edebilir. BigQuery ML, makine öğrenimi modelleme sürecini basitleştirerek güvenlik analistlerinin daha derinlemesine ve otomatik anomali tespiti yapmasına olanak tanır.

BigQuery'den Chronicle SIEM'e Veri Akışı ve YARA-L Kuralları Oluşturma

Şimdiye kadar denetim kayıtlarını BigQuery'ye aktarmayı ve burada derinlemesine analizler yapmayı öğrendik. Ancak gerçek zamanlı tehdit tespiti ve olay müdahalesi için bu içgörülerin bir güvenlik operasyonları merkezinde (SOC) hızlıca kullanılabilir olması gerekir. İşte burada Chronicle SIEM devreye girer. Genellikle Google Cloud Audit Logs, BigQuery'ye ek olarak doğrudan Chronicle SIEM'e de akıtılır. BigQuery ise daha çok derinlemesine avcılık, tarihi analiz ve kompleks korelasyonlar için kullanılır. Bu bölümde, BigQuery'den elde edilen analitik içgörüleri Chronicle SIEM'de nasıl değerlendireceğimizi ve YARA-L kuralları ile bu içgörüleri gerçek zamanlı algılamalara nasıl dönüştüreceğimizi inceleyeceğiz.

Verileri Chronicle SIEM'e Nasıl Aktarırsınız veya Değerlendirirsiniz?

GCP Audit Logs'ın doğrudan Chronicle SIEM'e gönderilmesi en yaygın ve önerilen yöntemdir. Bu sayede, loglar UDM (Unified Data Model) formatına dönüştürülür ve Chronicle'ın yüksek hızlı arama ve algılama yetenekleriyle hemen kullanılabilir hale gelir. Log Router kullanarak Audit Logs'ı BigQuery'ye aktardığınız gibi, aynı zamanda bir Pub/Sub konusuna da yönlendirebilir ve bu Pub/Sub konusunu Chronicle'a bağlayabilirsiniz. Ancak, çoğu durumda, GCP Audit Logs'ı Chronicle'a doğrudan bir kaynak olarak ekleyebilirsiniz.

Peki BigQuery'nin rolü ne? BigQuery, şunlar için kritik öneme sahiptir:

• Derinlemesine Tehdit Avcılığı: BigQuery'deki petabayt ölçekli veriler üzerinde karmaşık SQL sorguları çalıştırarak, Chronicle'ın gerçek zamanlı algılama kurallarının henüz kapsamadığı yeni veya gelişmekte olan tehditleri tespit edebilirsiniz.
• Anomali Tespiti ve Temel Çizgi Oluşturma: BigQuery ML kullanarak kullanıcıların, hizmet hesaplarının veya kaynakların normal davranış kalıplarını belirleyebilir, bu da Chronicle'da daha hassas anomali tabanlı kurallar yazmak için temel oluşturur.
• Olay Müdahalesi ve Adli Analiz: Bir güvenlik olayı meydana geldiğinde, BigQuery'deki kapsamlı log arşivi, olayın kök nedenini bulmak, yayılımını anlamak ve adli kanıt toplamak için paha biçilmezdir.
• Chronicle Kurallarını Geliştirme: BigQuery'de keşfettiğiniz yeni saldırı desenlerini veya IOC'leri (Indicator of Compromise), Chronicle SIEM'in algılama motorunda YARA-L kuralları olarak uygulayabilirsiniz.

Yani, BigQuery, Chronicle'a doğrudan anlık "alert" göndermekten ziyade, Chronicle'ın algılama yeteneklerini zenginleştiren "istihbarat" ve "kural geliştirme" platformu olarak işlev görür. Örneğin, BigQuery'de tespit ettiğiniz bir IP adresinden gelen anormal sayıda başarısız oturum açma girişimini bir IOC olarak alıp, bu IP'yi hedefleyen bir YARA-L kuralı oluşturabilirsiniz.

YARA-L Kuralları ile Gelişmiş Tehdit Tespiti

Chronicle SIEM'in kalbinde, güvenlik verilerinizde tehditleri tespit etmek için kullanılan YARA-L adlı güçlü bir algılama dili bulunur. YARA-L, özellikle gelişmiş tehditler (APT'ler), kötü amaçlı yazılımlar ve şüpheli davranışlar için kurallar yazmanıza olanak tanır. BigQuery'de yaptığınız analizlerden elde ettiğiniz içgörüleri YARA-L kurallarına dönüştürerek, Chronicle'ın gerçek zamanlı algılama yeteneklerini güçlendirebilirsiniz.

YARA-L kuralları temel olarak üç bölümden oluşur:

• Meta Bölümü: Kural hakkında bilgi (yazar, açıklama, referanslar).
• Events Bölümü: Algılamanın temelini oluşturan olayları tanımlar. Bu bölümde, Unified Data Model (UDM) alanlarını kullanarak log verilerini filtreleyebilirsiniz.
• Outcome Bölümü: Algılama tetiklendiğinde alınacak eylemleri veya döndürülecek bilgiyi tanımlar.

Örnek olarak, BigQuery'de tespit ettiğimiz "Alışılmadık Konumdan Yönetici Etkinliği" senaryosunu Chronicle SIEM'de bir YARA-L kuralına dönüştürelim. İlk adımda, güvenli kabul edilen ülkelerin veya IP aralıklarının bir listesini dış referans olarak kullanabiliriz.

rule unusual_admin_login_from_new_location {
  meta:
    author = "Your Security Team"
    description = "Detects admin logins from IP addresses not seen before for that user, potentially indicating account compromise."
    severity = "HIGH"
    reference = "BigQuery analysis: Unusual Admin Activity"

  events:
    $e.metadata.event_type = "USER_LOGIN"
    $e.metadata.product_object.labels["type"] = "GCP_AUDIT_LOG"
    $e.principal.user.email = /@yourdomain.com/ nocase // Etki alanınızı buraya ekleyin
    $e.principal.ip IN %unusual_admin_ip_list // Bu liste BigQuery analizinden gelebilir

  outcome:
    $e.metadata.vendor_name = "Google Cloud"
    $e.metadata.product_name = "Audit Logs"
    $e.detection.id = "UNUSUAL_ADMIN_LOGIN"
    $e.detection.description = "Admin login from an unusual IP address based on BigQuery historical analysis."

  // Bu kural, 'unusual_admin_ip_list' adında dinamik bir referans listesi kullanır.
  // Bu liste, BigQuery'de yapılan geçmiş analizlerden elde edilen ve bir kullanıcının daha önce hiç giriş yapmadığı IP adreslerini içerebilir.
  // Bu listenin Chronicle'a beslenmesi gerekmektedir (örneğin API veya feed aracılığıyla).
}
    

Açıklama: Bu YARA-L kuralı, GCP denetim kayıtlarından gelen "USER_LOGIN" türündeki olayları hedefler. Özellikle, unusual_admin_ip_list adlı bir referans listesindeki IP adreslerinden gelen ve tanımlanmış etki alanındaki yönetici e-postalarına ait oturum açma denemelerini yakalar. Bu unusual_admin_ip_list, BigQuery'de yapılan geçmiş analizlerden (bir kullanıcının belirli bir zaman diliminde hiç görülmemiş bir IP'den giriş yapması gibi) dinamik olarak oluşturulabilir ve Chronicle'a aktarılabilir. Bu dinamik listeler, BigQuery'nin analitik gücünü Chronicle'ın gerçek zamanlı algılama motoruyla birleştirmenin bir yoludur.

Uzman İpucu: Chronicle SIEM'de dinamik referans listeleri (threat intelligence feed'leri gibi) oluşturarak, BigQuery'den elde ettiğiniz karmaşık IOC'leri (şüpheli IP'ler, kullanıcılar, kaynak adları vb.) otomatik olarak bu listelere besleyebilir ve YARA-L kurallarınızı bu listeleri kullanarak daha esnek ve güncel hale getirebilirsiniz.

Vaka Analizi: Fidye Yazılımı Saldırısı Erken Tespiti

Gerçek dünya senaryolarında, bulut denetim kayıtları ve gelişmiş analiz araçları, bir saldırının erken aşamalarında tespit edilmesinde hayati rol oynar. Şimdi, kurgusal bir fidye yazılımı saldırısı senaryosunu ele alalım ve BigQuery ile Chronicle SIEM'in bu saldırıyı nasıl erken aşamada tespit edebileceğini inceleyelim.

Senaryo: Bir Hizmet Hesabının Ele Geçirilmesi ve Dosya Şifreleme Girişimi

Bir kuruluşun GCP ortamında çalışan bir hizmet hesabı (data-processor@your-project.iam.gserviceaccount.com), genellikle Cloud Storage'daki belirli kovalara okuma/yazma erişimi olan ve düzenli veri işleme görevlerini yerine getiren meşru bir hesaptır. Ancak bir saldırgan, bu hizmet hesabının kimlik bilgilerini (örneğin, bir GCE örneğindeki zafiyet veya yanlış yapılandırma yoluyla) ele geçirir.

Saldırgan, ele geçirdiği hizmet hesabını kullanarak aşağıdaki şüpheli eylemleri gerçekleştirmeye başlar:

1. Kuruluşun kritik veri içeren birden fazla Cloud Storage kovasına aynı anda erişim sağlamaya çalışır.
2. Bu kovalardaki dosyaları okuduktan kısa bir süre sonra, aynı hizmet hesabı bu dosyaları "delete" (silme) veya "update" (güncelleme - şifreleme ile eşdeğer) operasyonlarıyla değiştirmeye başlar.
3. Normalde erişmediği coğrafi bölgelerdeki veya farklı projelerdeki depolama kovalına erişmeye çalışır.

BigQuery ve Chronicle SIEM ile Erken Tespit

Bu senaryoda, BigQuery ve Chronicle SIEM'in birleşimi saldırıyı birden fazla aşamada tespit edebilir:

BigQuery ile Anomali Avcılığı ve Temel Çizgi Oluşturma:

BigQuery, uzun vadeli ve karmaşık kalıp analizleri için kullanılır. Güvenlik ekibi, hizmet hesaplarının geçmiş davranışlarını analiz ederek bir "normal" temel çizgi oluşturabilir:

• Normal Davranış Analizi: BigQuery, data-processor hizmet hesabının genellikle hangi Cloud Storage kovalarına, hangi bölgelerde ve ne sıklıkla eriştiğini belirlemek için geçmiş denetim kayıtlarını analiz edebilir.
• Anormal Erişim Kalıpları: Saldırı anında, BigQuery'deki bir sorgu, data-processor hesabının, normalde erişmediği coğrafi bölgelerden veya çok daha yüksek bir hızda, çok sayıda farklı kovaya eriştiğini tespit edebilir. Örneğin:

  
  SELECT
      timestamp,
      protoPayload.authenticationInfo.principalEmail AS service_account,
      protoPayload.methodName AS action,
      REGEXP_EXTRACT(protoPayload.resourceName, 'buckets/(.*?)/') AS bucket_name,
      COUNT(*) AS event_count
  FROM
      your_project_id.audit_logs.cloudaudit_googleapis_com_data_access_*
  WHERE
      _PARTITIONTIME BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR) AND CURRENT_TIMESTAMP()
      AND protoPayload.authenticationInfo.principalEmail = 'data-processor@your-project.iam.gserviceaccount.com'
      AND protoPayload.methodName IN ('google.storage.v1.storage.objects.get', 'google.storage.v1.storage.objects.update')
  GROUP BY
      service_account, action, bucket_name, TIMESTAMP_TRUNC(timestamp, MINUTE)
  HAVING
      event_count > 50 -- 1 dakika içinde belirli bir kovada 50'den fazla okuma/güncelleme
  ORDER BY
      event_count DESC;
              

  Bu sorgu, data-processor hesabının belirli bir kovada anormal sayıda okuma/güncelleme yapıp yapmadığını belirleyerek potansiyel bir saldırıyı işaret edebilir.

Chronicle SIEM ile Gerçek Zamanlı Algılama ve Korelasyon:

Chronicle SIEM, doğrudan Log Router'dan gelen gerçek zamanlı denetim kayıtlarını kullanarak anında algılama kuralları çalıştırır:

• Aşama 1: Anormal Kaynak Erişimi (BigQuery'den Alınan Bilgiyle): BigQuery'deki analizin "data-processor" hesabının normalde erişmediği "finance-data-backup" kovasına eriştiğini gösterdiğini varsayalım. Bu bilgiyle bir YARA-L kuralı oluşturulabilir.

  
  rule unusual_service_account_access_to_critical_bucket {
    meta:
      author = "Your SOC Team"
      description = "Detects unusual access by a service account to a critical Cloud Storage bucket."
      severity = "HIGH"
  
    events:
      $e.metadata.event_type = "STORAGE_OBJECT_ACCESS"
      $e.principal.user.email = "data-processor@your-project.iam.gserviceaccount.com"
      $e.target.resource.name = "finance-data-backup" // Kritik kova adı
      $e.principal.ip IN %unusual_access_ips // BigQuery'den beslenen anormal IP listesi
  
    outcome:
      $e.detection.id = "CRITICAL_BUCKET_UNUSUAL_ACCESS"
      $e.detection.description = "Service account 'data-processor' accessed critical bucket from unusual IP."
  }
              

  Bu kural, data-processor hesabının kritik bir kovaya erişmesini ve bu erişimin BigQuery tarafından anormal kabul edilen bir IP'den gelmesini izler.

• Aşama 2: Toplu Silme/Değiştirme (Şifreleme Göstergesi): Aynı hizmet hesabının, kısa bir süre içinde birden fazla dosyayı silme veya değiştirme (objects.update genellikle dosya içeriğinin değiştirilmesi, yani şifrelenmesi anlamına gelir) eylemini tespit eden bir YARA-L kuralı tetiklenir.

  
  rule ransomware_like_file_modification {
    meta:
      author = "Your SOC Team"
      description = "Detects rapid, large-scale file modification/deletion by a single service account, indicative of ransomware."
      severity = "CRITICAL"
      mitre_attack = "T1486 - Data Encrypted for Impact"
  
    events:
      $e.metadata.event_type = "STORAGE_OBJECT_CHANGE"
      $e.principal.user.email = "data-processor@your-project.iam.gserviceaccount.com"
      $e.target.resource.name = /^projects\/.*\/buckets\/.*\// // Herhangi bir kovayı hedefle
      $e.metadata.event_type = "STORAGE_OBJECT_CHANGE"
      $e.security_result.action = "ALLOW"
  
    match:
      // Aynı hizmet hesabı tarafından 5 dakika içinde 100'den fazla obje değişikliği
      $e.principal.user.email over 100 events in 5m by $e.principal.user.email
  
    outcome:
      $e.detection.id = "RANSOMWARE_SUSPICIOUS_ACTIVITY"
      $e.detection.description = "Service account 'data-processor' engaged in high-volume, rapid file modification/deletion, potential ransomware."
  }
              

  Bu kural, data-processor hizmet hesabının 5 dakika içinde 100'den fazla depolama objesini değiştirmesi durumunda bir alarm verir. Bu, fidye yazılımı benzeri davranışın güçlü bir göstergesidir.

Bu iki aşamalı yaklaşım sayesinde, saldırının ilk aşamalarındaki anormal erişim kalıpları BigQuery tarafından ortaya çıkarılırken, Chronicle SIEM, gerçek zamanlı olarak şüpheli dosya modifikasyonlarını tespit ederek anında bir alarm oluşturur. Güvenlik ekibi, Chronicle'ın entegre olay müdahale yetenekleri sayesinde hızla olaya müdahale edebilir, ele geçirilen hizmet hesabını devre dışı bırakabilir ve potansiyel veri kaybını en aza indirebilir.

İleri Düzey İpuçları ve En İyi Uygulamalar

BigQuery ve Chronicle SIEM ile güvenlik operasyonlarınızı bir üst seviyeye taşımak için bazı ileri düzey ipuçları ve en iyi uygulamalar şunlardır:

• BigQuery Sorgularını Otomatikleştirme: Tehdit avcılığı için geliştirdiğiniz BigQuery sorgularını manuel olarak çalıştırmak yerine, bunları otomatikleştirin. Google Cloud Scheduled Queries veya Cloud Functions kullanarak belirli aralıklarla (örneğin, her saat veya her gün) bu sorguları çalıştırabilir ve sonuçları bir Pub/Sub konusuna, Cloud Storage'a veya doğrudan Chronicle'a bir besleme olarak gönderebilirsiniz.
• Dinamik Tehdit Beslemeleri Oluşturma: BigQuery'de tespit ettiğiniz şüpheli IP adresleri, kullanıcı hesapları veya kaynak adları gibi göstergeleri (IOC'ler) dinamik listeler halinde dışa aktarın. Bu listeleri Chronicle SIEM'e veya diğer güvenlik araçlarınıza (örneğin, güvenlik duvarları, WAF'ler) besleyerek, algılama ve önleme yeteneklerinizi gerçek zamanlı olarak güncel tutun.
• BigQuery Maliyet Optimizasyonu: BigQuery'nin sorgu maliyetleri işlenen veri miktarına bağlı olduğundan, cost.googleapis.com API'si gibi araçları kullanarak BigQuery kullanımınızı izleyin. Özellikle sık çalıştırılan otomatik sorgularda, sadece gerekli sütunları seçmeye, bölümleme ve kümeleme kullanmaya özen gösterin. Gereksiz veya çok geniş tarih aralığı sorgularından kaçının.
• Siber Güvenlik SOAR (Security Orchestration, Automation and Response) Entegrasyonu: Chronicle SIEM'den gelen alarmları, Cloud Functions veya diğer entegrasyon araçları aracılığıyla bir SOAR platformuna ileterek olay müdahale süreçlerinizi otomatikleştirin. Bu, bir alarm tetiklendiğinde otomatik olarak soruşturma başlatma, kullanıcıyı kilitleme veya bir ağ segmentini izole etme gibi eylemleri tetikleyebilir.
• Kuralları Düzenli Olarak Gözden Geçirme ve Ayarlama: Tehdit ortamı sürekli değiştiğinden, hem BigQuery'deki analitik sorgularınızı hem de Chronicle SIEM'deki YARA-L kurallarınızı düzenli olarak gözden geçirin ve güncelleyin. Yanlış pozitifleri azaltmak ve yeni tehditleri kapsamak için sürekli ayarlamalar yapın.
• Kullanıcı ve Hizmet Hesabı Davranış Profilleri Oluşturma: BigQuery ML kullanarak kullanıcıların ve hizmet hesaplarının normal davranış kalıplarını öğrenin. Bu profillerden sapan herhangi bir aktiviteyi, Chronicle'da anomali tabanlı algılama kuralları ile hedefleyin.

Sonuç: Geleceğin Güvenlik Operasyonları

Bulut ortamlarının karmaşıklığı ve siber tehditlerin sürekli evrimi, geleneksel güvenlik yaklaşımlarının yetersiz kalmasına neden olmaktadır. Google Cloud Audit Logs'tan başlayarak, BigQuery'nin güçlü analitik yetenekleri ve Chronicle SIEM'in gerçek zamanlı algılama motoruyla birleşen entegre bir yaklaşım, kuruluşların siber güvenlik duruşunu önemli ölçüde güçlendirmektedir. Bu makalede adım adım açıkladığımız entegrasyon süreci, bulut kaynaklarınız üzerinde tam görünürlük sağlamanıza, anormal davranışları hızla tespit etmenize ve potansiyel tehditlere karşı proaktif bir şekilde müdahale etmenize olanak tanır.

BigQuery, petabaytlarca veriyi işleyebilme kapasitesiyle derinlemesine tehdit avcılığına ve karmaşık anomali tespitine olanak tanırken, Chronicle SIEM tüm güvenlik verilerinizi tek bir platformda birleştirerek, YARA-L kuralları ile gerçek zamanlı algılama ve olay müdahalesi sağlar. Bu sinerjik yaklaşım, güvenlik operasyon ekiplerinin daha hızlı, daha akıllı ve daha verimli çalışmasına yardımcı olur. Sonuç olarak, bu güçlü araçları etkin bir şekilde kullanarak, dijital varlıklarınızı daha iyi koruyabilir ve geleceğin güvenlik tehditlerine karşı daha dirençli olabilirsiniz.

Sıkça Sorulan Sorular

• BigQuery ve Chronicle SIEM birlikte kullanıldığında maliyetler nasıl yönetilir?

  Cevap: BigQuery maliyetleri genellikle depolama ve sorgulanan veri miktarına bağlıdır. Maliyetleri yönetmek için sorgularınızı optimize edin (yalnızca gerekli sütunları seçin, bölümleme ve kümeleme kullanın) ve kullanılmayan tabloları temizleyin. Chronicle SIEM ise veri alım hacmine göre fiyatlandırılır. İhtiyaç duymadığınız logları filtreleyerek veya daha az kritik logları daha uzun saklama süreleriyle BigQuery'ye yönlendirerek maliyetleri optimize edebilirsiniz. Ayrıca, GCP'nin maliyet yönetimi araçlarını kullanarak bütçe uyarıları ayarlamak önemlidir.

• BigQuery'deki tüm verileri Chronicle SIEM'e aktarmalı mıyım?

  Cevap: Genellikle hayır. Cloud Audit Logs gibi kritik güvenlik verileri hem BigQuery'ye hem de Chronicle SIEM'e doğrudan akıtılabilir. BigQuery, uzun süreli depolama, derinlemesine analitik ve makine öğrenimi tabanlı tehdit avcılığı için idealdir. Chronicle SIEM ise gerçek zamanlı algılama, olay korelasyonu ve olay müdahalesi için tasarlanmıştır. BigQuery'den elde ettiğiniz belirli içgörüleri (örn. şüpheli IP listeleri, anomali eşikleri) Chronicle'daki YARA-L kurallarınızı zenginleştirmek için kullanmanız daha verimlidir, tüm ham veriyi aktarmak yerine.

• YARA-L kuralları yazmak için herhangi bir programlama bilgisine sahip olmam gerekiyor mu?

  Cevap: YARA-L, güvenlik analistleri için tasarlanmış, okunması ve yazılması nispeten kolay bir dildir. Temel programlama mantığına aşina olmak faydalı olsa da, kapsamlı bir yazılım geliştirme bilgisi gerekmez. Google Cloud'un kapsamlı dokümantasyonu ve örnek kurallar, başlangıç seviyesindeki kullanıcıların bile etkili kurallar oluşturmasına yardımcı olabilir.

• BigQuery ML, sıfır gün (zero-day) tehditlerini tespit edebilir mi?

  Cevap: BigQuery ML, bilinmeyen veya "sıfır gün" tehditlerini doğrudan tespit etmekte zorlanabilir, çünkü bunlar için bilinen bir imza veya kalıp yoktur. Ancak, BigQuery ML'i kullanarak anormal davranışları (örneğin, bir kullanıcının veya hizmet hesabının normalden sapması) tespit edebilir. Bu tür anormallikler, sıfır gün saldırısının bir yan etkisi olabilir ve bu sayede saldırının belirtilerini fark etmenize yardımcı olabilir. Bu, imza tabanlı tespitten daha proaktif bir yaklaşımdır.

• Bu çözüm, diğer bulut sağlayıcılarının (AWS, Azure) denetim kayıtlarıyla da çalışır mı?

  Cevap: Bu makale Google Cloud Platform özelinde BigQuery ve Chronicle SIEM entegrasyonuna odaklanmıştır. Ancak Chronicle SIEM, diğer bulut sağlayıcılarından (AWS CloudTrail, Azure Monitor gibi) ve şirket içi sistemlerden gelen logları da alabilen bir platformdur. Bu logları da UDM'ye dönüştürerek analiz edebilir. BigQuery ise genellikle GCP ortamında en verimli şekilde çalışsa da, federated query özelliği ile diğer bulutlardaki veri kaynaklarına da erişebilir. Ancak entegrasyon detayları bulut sağlayıcısına göre değişiklik gösterecektir.