Attack Surface Reduction (ASR) Kural Kimlikleri (GUID) ile Politika Yapılandırması

Intune admin center’da bir ASR kuralını Block moduna aldığınızda ekranda gördüğünüz isim aslında sadece bir arayüz etiketi. Cihaz tarafında, Windows Event Log’da, Advanced Hunting’de ve Policy CSP’nin kendisinde bu kurallar isimle değil GUID ile tanımlanıyor. “Office uygulamalarının çocuk process oluşturması” dediğinizde bu Intune’da bir görüntü; cihazın registry’sinde, Get-MpPreference çıktısında ve DeviceEvents tablosunda karşılığı d4f940ab-401b-4efc-aadc-ad5f3c50688a GUID’i.

Bu fark, kural genel ayar seviyesinde kaldığı sürece önemli değil. Ama bir false positive’i teşhis ederken, custom OMA-URI ile ASR’yi Policy CSP üzerinden ayarlarken veya belirli bir kural için exclusion sözdizimini doğru yazmaya çalışırken GUID bilgisi zorunlu hale geliyor. Bu yazıda genel ASR kurulumuna girmiyorum, doğrudan kural GUID’lerine, custom OMA-URI ile GUID üzerinden ayarlamaya, per-rule exclusion sözdizimine ve false positive teşhisinde GUID’in nasıl kullanılacağına odaklanıyorum.

Kural İsimleri Neden GUID’e İniyor?

Policy CSP’nin AttackSurfaceReductionRules node’u kuralları isimle değil GUID ile taşıyor; değer formatı GUID=mod şeklinde. Cihaz tarafında Get-MpPreference komutunun döndürdüğü AttackSurfaceReductionRules_Ids dizisi de aynı GUID’leri listeliyor. Windows Event Viewer’daki Defender Operational log kayıtlarında ve Microsoft Defender portalındaki Advanced Hunting DeviceEvents tablosunun ActionType alanında da kural adı değil, o kurala özel bir action type string’i görüyorsunuz; bu string de dolaylı olarak GUID’e karşılık geliyor.

Intune admin center’daki Settings Catalog tabanlı Attack surface reduction rules profili, arka planda bu GUID’leri kullanıcıya göstermeden işliyor. Sorun, cihaz tarafında bir davranışı incelemeniz gerektiğinde başlıyor: log’daki veya Advanced Hunting’deki kaydı hangi kuralın ürettiğini anlamak için GUID’i veya action type’ı bilmeniz gerekiyor.

ASR Kural GUID’leri

Aşağıdaki tablo güncel 19 ASR kuralının tamamını, Microsoft Intune’daki resmi kural adını ve GUID’ini içeriyor. Üç kural (tablonun ilk üç satırı) Microsoft’un standart koruma kuralları olarak tanımladığı, çoğu ortamda test etmeden doğrudan Block moduna alınabilecek kurallar.

Custom OMA-URI ile ASR Kurallarını GUID Üzerinden Ayarlama

Endpoint security ASR policy’si (Settings Catalog) önerilen yöntem, ama bazı senaryolarda kuralları doğrudan Policy CSP üzerinden, custom OMA-URI profiliyle ayarlamak isteyebilirsiniz: örneğin registry’de tam olarak hangi değerin yazıldığını denetlemek, birden fazla MDM çözümü arasında tutarlı bir CSP tabanlı yapı kurmak veya bir kuralı bilinçli olarak Not configured (5) değerine sabitleyip diğer policy’lerle çakışma riskini azaltmak istediğinizde.

Bunun için kullanılan node AttackSurfaceReductionRules. OMA-URI ve değer formatı şöyle:

OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Defender/AttackSurfaceReductionRules
Data type: String
Değer formatı: GUID1=Mod1|GUID2=Mod2|...|GUIDN=ModN

Mod kodları şöyle: 0 Off, 1 Block, 2 Audit, 5 Not configured, 6 Warn. Örneğin LSASS kuralını Block’a, Office child process kuralını Audit’e, obfuscated script ve ransomware kurallarını Block’a almak isterseniz değer şöyle görünür:

9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2=1|d4f940ab-401b-4efc-aadc-ad5f3c50688a=2|5beb7efe-fd9a-4556-801d-275e5ffc04cc=1|c1db55ab-c21a-4637-bb3f-a12568109d35=1

Bu profili oluşturmak için Intune admin center > Devices > Windows > Configuration > Create > New Policy, profil tipi olarak Templates > Custom seçilir. Configuration settings sekmesinde Add ile yukarıdaki OMA-URI ve değer eklenir. Değerde boşluk bırakılmaması gerekiyor; bir GUID’i yanlış yazmak ya da fazladan boşluk eklemek o satırın sessizce yok sayılmasına yol açabiliyor, herhangi bir hata mesajı çıkmıyor.

Global Exclusion: AttackSurfaceReductionOnlyExclusions OMA-URI

Global exclusion listesi de custom OMA-URI ile ayarlanabiliyor. Node AttackSurfaceReductionOnlyExclusions, değer formatı ise yol tabanlı, GUID içermiyor:

OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Defender/AttackSurfaceReductionOnlyExclusions
Değer formatı: Path1=0|Path2=0|...|PathN=0

C:\Program Files\LOBApp\LOBApp.exe=0|C:\ProgramData\Vendor\Tool.exe=0

Bu exclusion cihaza atanan tüm ASR kurallarına birden uygulanıyor; belirli bir GUID’e bağlı değil. Tek bir kuralla ilgili bir false positive için bu global yöntem gereğinden fazla geniş kapsıyor.

Per-Rule Exclusion Sözdizimi: GUID Neden Buradan Kaçınılmaz

Burada işler biraz farklı işliyor. Per-rule exclusion, yani bir path’i sadece belirli bir GUID için hariç tutma, Policy CSP’de bağımsız bir OMA-URI node’u olarak yayınlanmıyor. Microsoft’un kendi dokümantasyonu bunu açıkça belirtiyor: per-rule exclusion’lar sadece Group Policy ve Intune’daki endpoint security policy’leri (Settings Catalog) üzerinden destekleniyor. Elinizde AttackSurfaceReductionRules ve AttackSurfaceReductionOnlyExclusions dışında, GUID bazlı bir exclusion node’u custom OMA-URI listesinde yok.

Group Policy tarafında bu ayarın gerçek sözdizimi görünür durumda: Apply a list of exclusions to specific attack surface reduction (ASR) rules ayarında value name alanına kuralın GUID’i, value alanına ise Path1\ProcessName1>Path2\ProcessName2>... formatında, > karakteriyle ayrılmış yol listesi giriliyor. Yani gerçek sözdizimi tam olarak “GUID = exclusion path” mantığında, sadece bunu bir custom OMA-URI’ye elle yazamıyorsunuz.

Intune tarafında aynı mekanizma ASR Only Per Rule Exclusions olarak karşınıza çıkıyor. Bir kuralı Settings Catalog tabanlı Attack surface reduction rules profilinde Not configured dışında bir moda ayarladığınızda bu alan otomatik görünüyor ve orada girdiğiniz path’ler sadece o tek GUID için geçerli oluyor. Portal, GUID eşlemesini sizin adınıza yapıyor; siz sadece hangi kuralın altına path eklediğinizi seçiyorsunuz.

Hangi Kurallar Standart Dosya Exclusion’ını Görmezden Geliyor?

Bir path’i Defender Antivirus’ün standart dosya/klasör exclusion listesine eklemek her ASR kuralı için işe yaramıyor. Aşağıdaki kurallar Microsoft Defender Antivirus’ün standart exclusion’larını honor etmiyor; bunlar için sadece global ASR exclusion veya per-rule ASR exclusion geçerli:

• LSASS’tan kimlik bilgisi çalınmasını engelleme (9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2)
• WMI event subscription üzerinden kalıcılığı engelleme (e6db77e5-3df2-4cf1-b95a-636979351e5b)
• Adobe Reader’ın child process oluşturmasını engelleme (7674ba52-37eb-4a4f-a9a1-f0f9a1619a2c)
• Office uygulamalarının executable content oluşturmasını engelleme (3b576869-a4ec-4529-8536-b80a7769e899)
• Office uygulamalarının başka process’lere kod enjekte etmesini engelleme (75668c1f-73b5-4cf0-bb93-3ecf5cb7cc84)
• Office iletişim uygulamasının (Outlook) child process oluşturmasını engelleme (26190899-1602-49e8-8b27-eb1d0a1ce869)
• PSExec ve WMI komutlarından kaynaklanan process oluşturmayı engelleme (d1e49aac-8f56-4280-b9ba-993a6d77406c)

Bu yedi kural için bir uygulamayı sadece Defender’ın normal exclusion listesine eklemek yeterli olmuyor; aynı path’i ayrıca global ASR exclusion veya o kurala özel per-rule exclusion olarak da eklemeniz gerekiyor. Bu ayrımı bilmemek, “exclusion ekledim ama hâlâ engelleniyor” şeklindeki en yaygın şikayetin nedeni.

False Positive Teşhisinde GUID ve Advanced Hunting Action Type

Bir kuralı Audit veya Block modunda çalıştırırken belirli bir GUID’in ürettiği olayları izole etmek istediğinizde, DeviceEvents tablosundaki ActionType alanı GUID’e göre değişen, kurala özel bir string taşıyor. Aşağıdaki tabloda sık kullanılan birkaç kuralın GUID’i ve karşılık gelen action type’ları var:

Bir kuralla ilgili şüpheli engellemeleri incelemek için bu action type’ı doğrudan filtreye koyabilirsiniz:

DeviceEvents
| where ActionType == "AsrLsassCredentialTheftAudited"
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, FolderPath
| order by Timestamp desc

Bu sorgu Advanced Hunting’de o tek kuralın ürettiği tüm olayları getiriyor; hangi process’in LSASS’a erişmeye çalıştığını, hangi dosyanın tetiklediğini doğrudan görüyorsunuz. Genel ActionType startswith "Asr" sorgusuna kıyasla burada tek bir kurala odaklanmak, çok sayıda kuralın aynı anda Audit modunda çalıştığı ortamlarda sinyali çok daha net ayırıyor.

Bir Cihazda Tek Bir GUID’in Modunu Doğrulama

Tüm kural listesini dökmek yerine tek bir GUID’in cihazda gerçekten hangi modda olduğunu görmek istediğinizde şu komut yeterli:

$guid = '9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2'
$p = Get-MpPreference
$index = $p.AttackSurfaceReductionRules_Ids.IndexOf($guid)
if ($index -ge 0) { $p.AttackSurfaceReductionRules_Actions[$index] } else { 'GUID cihazda tanımlı değil' }

Dönen değer 1 ise Block, 2 ise Audit, 6 ise Warn, 0 ise Off anlamına geliyor. GUID listede hiç yoksa o kural cihaza hiç ulaşmamış demektir; bu durumda sorun kuralın davranışında değil, policy’nin assignment veya delivery aşamasında aranmalı.

Hangi Yöntemi Ne Zaman Kullanmalı

Kural modlarını topluca yönetmek ve per-rule exclusion ihtiyacınız varsa endpoint security ASR policy’si hâlâ doğru yer; per-rule exclusion alanı orada otomatik açılıyor ve GUID eşlemesiyle uğraşmanıza gerek kalmıyor. Custom OMA-URI ile GUID üzerinden ayarlama, asıl olarak cihazdaki registry değerini tam olarak neyin belirlediğini doğrulamak istediğinizde, birden fazla MDM aracını aynı Policy CSP üzerinden tutarlı yönetmeniz gerektiğinde veya bir kuralı bilinçli olarak Not configured’a sabitlemek istediğinizde anlamlı. Per-rule exclusion’ı custom OMA-URI ile çözmeye çalışmak zaman kaybı; o node zaten yayınlanmıyor.