Device Guard teknolojisini Code Integrety politikaları sayesinde birleştirilmiş bir koruma kalkanı oluşturmakta ve korumuş olduğu Windows 10 bilgisayar üzerinde Kernel Mode ve User Mode olmak üzere iki farklı platform üzerinee korumasını gerçekleştirebilmektedir. User mode platformu üzerinde gerçekleştirmiş olduğu koruma özelliklerini Audit Mode makalesi içinde inceledik. Bu makalemiz içinde User Mode içinde Enforced Mode yapılandırmasını ve Kernel Mode yapılandırması için temel gereksinimleri paylaşacağız.
Device Guard teknolojisini Kernel Mode yani işletim sisteminin çekirdeğini ve bunun ötesinde çalışmış olduğu bilgisayarın donanımının sahip olduğu firmware ve ilk açılış bölümü olan boot bölümünü koruyabilmektedir. Bu korumayı gerçekleştirebilmemiz için bir takım donanımsal gereksinimlere ihtiyacımız bulunmaktadır ve PC OEM requirements for Device Guard and Credential Guard makalesi içinde paylaşılmaktadır.
Device Guard requirements for baseline protections inceleyeceğiz.
64-bit CPU.
Device Guard teknolojisi VBS yani vitulization base securty kullanmakta ve Windows Hypervisor un temel gereksinimi olan 64 bit CPU zorunlu koşmaktadır. Günümüz bilgisayarları neredeyse bu gereksinimi karşılamaktadır.
CPU virtualization extensions Plus extended page tables
Virtulization extension özelliği VT-x (Intel) ve AMD-V olarak bilinir ve Second Level Address Translation (SLAT) olarak adlandırılırlar. Bu özellik yapılandırıldığı zaman kazanacak olduğumuz güvenlik daha önce belirttiğimiz gibi Kernel Mode ile İşletim sistemi bir-birlerinden izole esilmiş bir şekilde çalışacaktır ve vaat edilen sıfır gün koruması bu izolasyon ile birlikte sağlanacaktır.
UEFI firmware version 2.3.1.c or higher with UEFI Secure Boot
Device Guard yapılandırılmış olan cihazının ilk açılması sırasında yetkilendirilmiş kodlar ile açılmasını kontrol etmektedir. Bu özellik aktif edildiği zaman Rootkitler i engelleyebilmektedir. Device Guard yeni bir teknoloji ve bu özelliğe sahip atakları engellemek pek mümkün olmadığı veya zor olduğu düşünülebilir.
Özgür ansiklopediden almış olduğumuz bilgiler şunu söylemekte;
“Rootkit’in gerçekte hangi dosyaları değiştirdiği, Kernel’a hangi modülü yüklediği, dosya sisteminin neresinde kayıtlı olduğu, hangi ağ servisi üzerinde dinleme yaparak uygun komutla harekete geçeceğini tespit etmek güçtür.”
Ama artık Windows işletim sistemlerinde mümkün olduğunu görebilmekteyiz. Bu özelliği aktif duruma getirebilmemiz için Hardware Compatibility Specification for Systems for Windows 10, version 1607 makalesi içinde belirtilen donanım gereksinimlerini tamamlamış olmamız gerekmektedir.
Secure firmware update process
UEDI Firmware deki gibi firmware (aygıtın yazılımı zaten) kısıtlı olsa bile bir işletim sistemine sahip ve patch güncelleştirilmesi, yükseltme işlemlerinde aynı UEFI Secure Booy özelliğindeki gibi sistemi Rootkitler den koruyabilmektedir. Donanım gereksinimi UEFI Secure Boot ile aynıdır.
HVCI Compatible Drivers
Hypervisor Code Integrity özelliği ile sürücülerin kod bütünlüğünü sağlamış olabiliyoruz. Kernel mode içinde sadece kod bütünlüğü sağlanmış sürücüler çalışabilecektir. Kernel içinde herhangi bir malware çalışmayacağı gibi koruma bütünlüğünü, direncini arttıracaktır.
Risk altında bulunan potansiyel API lerin listesine Driver compatibility with Device Guard in Windows 10 adresinden öğrenebilirsiniz.
Windows Operating System
Bu özellikleri kullanabileceğimiz işletim sistemleri Windows 10 Enterprise, Windows 10 Education, Windows 2016 Server ve Windows Enterprise IoT sürümleridir.
İsmi ve özellikleri donanımsal gereksinimleri işaret etmiş olsa bile Device Guard teknolojisini sanal platform içinde kullanabilmekteyiz. Sanal platform gereksinimi Hyper-V Platformları için Gen2 sanal makine olması temel şarttır.
Baseline protections başlığı altında paylaşmış olduğumuz seçenekleri Device Guard için geliştirilen Set-RuleOption Power Shell komutları ile aktif ve pasif duruma getirebiliyoruz
Makalenin bundan önceki bölümlerinde yapmış olduğumuz işlemler sadece Audit Mode ile ilgiliydi ve Device Guard sadece olayları izliyor ve olaylara karşı günlük tutuyordur. Bizler artık Enforce Mode ile eylem yapmasını istiyoruz.
Eyleme geçmeden önce oluşturmuş olduğumuz Merge Policy’ sini kontrol ediyoruz. Baseline protections bölümünde bahsettiğimiz ve Set-Ruleoption içinde aktif ve pasif duruma getirebileceğimiz rule seçenekleri xml içinde bulunmakta.
Yukarıdaki komut ile Option 3 siliyoruz. Bir önceki ekran görüntüsüne dikkatli bakarsanız bu option 3 ün Audit mode olduğunu görebileceksiniz ve Enable durumda.
Set-RuleOption –option 3 –FilePath C:\MergePolicy.xml -delete
Yukarıdaki komut ile oluşturmuş olduğumuz MergePolicy.xml datası içinde option3 siliyoruz yani audit modu ve policy içinde otomatik olarak Enforce mod devreye girmiş olacaktır.
Komut sadece xml içindeki veriyi değiştiriyor. Xml değiştirmemekte. Sonrasında daha önce yaptığımız gibi merge policy dosyasını bin dosya formatina ve bin formatinida yeni sertifika almak üzere komutlarımızı çalıştırıyoruz.
Device Guard uygulanmış bilgisayarlarımız yeni sertifikamızı aldıktan sonra Enforced mod altında çalışacaktır.
CodeIntegrity politikalarımızı sıfırlıyoruz ve testlerimize başlıyoruz.
Bilgisayarımız daha önce imzaladığımız 7zip uygulamasını başarılı bir şekilde yüklerken imzalamadığımız winrar uygulaması için hata verdi ve yükleme yapmamıza müsaade etmedi.
Audit Moda sadece izleme ve olay günlüğüne kayıt alırken Enforce Mode kuralları uyguluyor.
Code Integrety olay günlüklerine baktığımız zaman Event ID 3077 olay günlüğünü görebilmekteyiz.
option 3 parametresini Set-RuleOption –option 3 –FilePath C:\MergePolicy.xml olarak değiştirdiğimiz zaman ve sonrasında tekrardan bin ve sertifikanın baştan oluşturma komutları sonrasında Enfoced Mode türünden Audit Mode geri dönüş yapabilmekteyiz.
