E-posta güvenliği ve kimlik avına karşı koruma alanındaki siber güvenlik uzmanları için 2024’ün başlangıcı bir evrimin başlangıcı oldu.
Ocak ayında, şirketlerin e-posta devleri Google ve Yahoo tarafından verilen talimatların uygulanmasına hazırlanmasıyla birlikte, alan adlarını dolandırıcılar tarafından yapılan sahtecilikten korumaya yönelik e-posta standardının (Alan Adı Tabanlı Mesaj Kimlik Doğrulaması, Raporlama ve Uygunluk veya DMARC) benimsenmesi başladı. DMARC, bir e-postanın belirli bir kuruluş adına mesaj göndermeye yetkili bir sunucudan gelip gelmediğini belirlemek için alan adı kaydını ve diğer e-posta odaklı güvenlik teknolojilerini kullanır.
Ancak üç ay sonra, DMARC’nin benimsenmesindeki artış zaten azalmaya başlıyor ve birçok şirket, DMARC’yi karantinaya almak ve hatta mesajları reddetmek yerine sorunları işaretleyecek şekilde ayarlamak gibi yalnızca alan adlarının en minimum yapılandırmasını tamamladı.
Tehdit istihbaratı sağlayıcısı Red Sift’in CEO’su Rahul Powar, ne yazık ki birçok kuruluş, DMARC’nin yanlış yapılması halinde kritik e-posta hizmetlerini bozabilecek başka bir güvenlik kontrolü olduğundan endişe duymaya devam ediyor.
“Birçok kuruluş, eğer giderlerse ve bir DMARC politikası uygularlarsa ve bu doğru değilse, büyük bir pazarlama kampanyası gibi iş için gerçekten önemli olan bir şeyi engelleyebileceklerinden veya CEO’nun e-postasının ulaşmayacağından haklı olarak endişe duyuyor doğru gelen kutusu” diyor. “Yanlış anlaşılma endişesi var.”
Nisan sonu itibarıyla, yaklaşık 7,9 milyon alan adının bir tür DMARC kaydı (sarı) var, ancak yalnızca %32’si BIMI’ye hazır (yeşil). Kaynak: BIMIRadar.com
Bununla birlikte, DMARC’nin ve Sender Policy Framework (SPF) ile DomainKeys Identified Mail’in (DKIM) temel teknolojilerinin, Google Workspace gibi bir üçüncü taraf hizmet aracılığıyla basit bir e-posta altyapısına sahip olan küçük veya orta ölçekli işletmeler için kurulumu zor değildir. veya Microsoft 365. Bununla birlikte, daha eski sistemler varsa veya alt alan adlarını kullanan bazı segmentasyonlar varsa, servis sağlayıcı EasyDMARC’ın kurucu ortağı ve CEO’su Gerasim Hovhannisyan, yapılandırmanın karmaşık ve hızlı hale gelebileceğini söylüyor.
“Eski sistemleriniz ve birden fazla gönderme kaynağınız ve altyapınız olduğunda sorun ortaya çıkıyor” diyor. “E-posta kimlik doğrulama dağıtımı sırasında yalnızca şirketler değil, orta ölçekli pazar da büyük sorunlarla karşılaşabilir. Bunu yapmak ilk bakışta basit veya kolaydır, ancak yanlış bir şey yaparsanız tamamen geçerli e-postalar reddedilecektir.”
Kuruluşunuz için DMARC’yi ayarlarken aklınızda bulundurmanız gerekenler aşağıda açıklanmıştır.
1. SPF Alıcıları Onaylanmamış Kaynaklardan Gelen E-postalara Karşı Uyarır
Bir kuruluşun kurması gereken ilk DNS kaydı, bir dize olan SPF’dir. IP adreslerini ve alan adlarını listeler Alan adına e-posta göndermeye yetkili posta sunucularının sayısı. Bu kayıt genellikle alan adı sağlayıcınız veya e-posta barındırma sağlayıcınız aracılığıyla ayarlanır.
Tipik bir SPF kaydı bir DNS TXT kaydıdır ve şöyle görünür:
v=spf1 ip4:192.168.1.1 ip4:192.168.2.1 include:example.com -all
“v=spf1” dizeyi bir SPF kaydı olarak belirtir ve tüm SPF kayıtları için gereklidir. “IP4” alanları, alan adına e-posta göndermesine izin verilen IP adreslerini listeler ve eğik çizgi gösterimini kullanan ağ adreslerini içerebilir. “Include” etiketi, alan adı için e-posta gönderme yetkisine sahip üçüncü taraf alan adlarını listelerken “-all” bayrağı, diğer alan adlarından hiçbirine izin verilmediğini belirtir. “~tümü” gibi diğer değişkenler de mümkündür ve diğer alan adlarından gelen postalara izin verildiğini ancak güvenli değil olarak işaretlendiğini belirtirken, “+tümü” herhangi bir sunucunun alan adına e-posta göndermesine izin verir.
SPF kaydı iyi bir ilk adım olsa da, Spam gönderenler istismar edebilir Google’ınki gibi ortak bir üçüncü taraf sunucusu kullanan diğer kuruluşların, bu sunucuyu kullanan diğer tüm kuruluşlar adına e-posta gönderme yetkisine sahip olacağı gerçeği.
2. DKIM, E-posta Mesajlarını Doğrulamak için PKI’yı Kullanıyor
DKIM, aynı e-posta sunucusunda birden fazla kiracı bulunması sorununu çözüyor ve e-posta doğrulamasını da ekliyor. DKIM seçici ve anahtarı e-posta sağlayıcınız tarafından oluşturuldu ve ardından DNS servis sağlayıcınıza TXT kaydı olarak kaydolun.
Tipik bir DKIM kaydı, ” gibi bir seçiciye (ada) sahip bir DNS TXT kaydıdır.[third party]._domainkey” ve şu değere sahiptir:
v=DKIM1; k=rsa; p={public key string}
“v=DKIM1″‘, TXT dizesini bir DKIM kaydı olarak belirtir ve tüm DKIM kayıtları için gereklidir. “k=rsa”, genel anahtar verileri için kullanılan şifreleme türünü belirtir; RSA varsayılandır ve Edwards eğrisi Dijital İmza Algoritması (EdDSA) gibi diğer değerlere de izin verilir. “p=” etiketi, e-posta servis sağlayıcısı tarafından oluşturulan genel anahtar verilerini içerir.
EasyDMARC’dan Hovannisyan, herhangi bir genel anahtar şifreleme altyapısında olduğu gibi, kuruluşların etki alanı altyapılarının anahtarlarını düzenli olarak değiştirdiğinden emin olmaları gerektiğini söylüyor.
“Diğerleri için şifre yönetim sistemlerimiz veya dönüşümlü şifrelerimiz var [types of] anahtarlar, ancak bunu DKIM anahtarlarıyla yapmıyoruz” diyor. “Bu, yerinde olması gereken bir şey ve bir şeyin kırılabileceği her durumda, bir uyarı almanız gerekir.”
3. DMARC, E-posta Alıcılarına Yönelik Politikalar Oluşturur
DMARC, SPF ve DKIM’in önceden belirlenmiş denetimlerini kullanır ve bir kuruluşun e-posta politikasını belirtir; kuruluşa gelen e-postalar için değil, kuruluş adına gönderildiğini iddia eden e-postalar için. Kuruluşlar bir DMARC kaydı belirtin, iki avantaj elde edin: Alıcı sunucuya, kimlik doğrulaması başarısız olan bir e-postayla ne yapması gerektiğini söyleyebilir (örneğin, teslimata izin verme, mesajı karantinaya alma veya reddetme gibi) ve alıcı sunucuyu, etki alanına gönderilen tüm mesajlar hakkında rapor oluşturmaya yönlendirebilirler.
Sonuç olarak, DMARC kullanan bir kuruluş, alan adının ve markasının yetkisiz taraflarca nasıl kullanıldığına dair görünürlük kazanır.
Tipik bir DMARC kaydı, ‘_DMARC’ ve aşağıdakiler gibi çeşitli alanları içeren bir dize olan bir değere sahip bir DNS TXT kaydıdır:
v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:[email protected]
Bu örnekte, “v=DMARC1” gerekli tanımlayıcıdır; hem SPF hem de DKIM için kimlik doğrulama politikaları “aspf=s” ve “adkim=s” etiketleriyle belirtildiği gibi katı olarak ayarlanmıştır ve DMARC raporları üçüncü taraf bir sağlayıcıdaki kuruluşa özel bir e-postaya gönderilir. Bu durumda politika reddetme şeklinde ayarlanır ancak şirketler raporlamaya erişim kazanmak için ‘hiçbiri’ politikasıyla başlayabilir ve bir “karantina” politikasına geçebilir.
4. DMARC Raporlarınızı Düzenli Olarak Kontrol Edin ve Kayıtları Koruyun
DMARC politikası oluşturmak oldukça basittir ancak eklenen bilgilerin e-posta güvenliği ve marka koruma programının parçası olarak kullanılması bir uyarı mekanizması ve düzenli gözetim gerektirir. Hovannisyan, şirketlerin çoğunlukla “hiçbiri” politikasıyla DNS’lerine geçerli bir DMARC kaydı ekleyeceklerini ve daha sonra eklenen tehdit istihbaratını unutacaklarını söylüyor.
“DMARC’lerle ilgili en büyük hatalardan biri [a company saying] bir kez bittiğinde, daha fazla bir şey yapmama gerek kalmayacak” diyor.
Bunun yerine, şirketlerin “hiçbiri” ile başlayıp hızla “karantinaya” ve ardından son olarak “katı”ya geçerek farklı politikalar izlemesi gerekiyor.
Küçük şirketler için DMARC’nin yönetimi kolay olsa da, büyük kuruluşlar büyük olasılıkla e-posta altyapısının yapılandırmasını yönetmek ve eklenen özelliklerden yararlanmak için bir hizmeti benimsemek isteyecektir.
Red Sift’ten Powar, “Temel olarak etki alanınızda bir Google veya Office 365’e sahip olduğunuz küçük bir dağıtım için bu oldukça basit” diyor. “Demek istediğim, spesifikasyon oldukça basit, ancak biraz karmaşıklık eklediğinizde – bir pazarlama departmanını, bir İK departmanını veya belki bir satın alma departmanını dahil etmeye başladığınızda – çok sayıda gönderen bulacaksınız. aniden altyapınızdan çıkmaya başlıyor.”
5. Güveni Artırmak İçin BIMI’yi Düşünün
Son olarak şirketlerin, e-posta mesajlarına daha fazla güven kazandırmaya yardımcı olabilecek dördüncü bir standardı var. Mesaj Tanımlaması için Marka Göstergeleri veya BIMI standardı, şirketlerin logolarını e-posta istemcilerinde kullanmak üzere kaydetmelerine olanak tanır, ancak bu ancak DMARC politikaları için maksimum düzeyde katılık benimsendikten sonra mümkündür.
neredeyse büyük kuruluşların dörtte üçü (%73) DMARC’nin en temel sürümünü benimsemiş olsa da, en katı standartları uygulayan kuruluşların payı ülkeye göre önemli ölçüde farklılık göstermektedir: Amerika Birleşik Devletleri’ndeki şirketlerin %77’si katı bir politikaya sahipken, Almanya’da yalnızca %40 ve Japonya’da %15’tir. göre yapmak Tehdit istihbaratı sağlayıcısı Red Sift’ten gelen veriler. Tüm alan adlarından yalnızca %3’ünün BIMI’ye hazır olduğu kabul ediliyor ancak 7,9 milyon DMARC özellikli alanın %32’sinin BIMI’yi benimsemek için yeterince katı politikaları var. BIMIRadar izleme sitesine göre.