Aşağıda müzik çalar yok mu? Dinlemek direkt olarak Soundcloud'da.

DOUG.  Parola yöneticisi çatlakları, oturum açma hataları ve Kraliçe I. Elizabeth ile İskoç Kraliçesi Mary… tabii ki!

Hepsi ve daha fazlası Naked Security podcast'inde.

[MÜZİKAL MODEM]

Podcast'e hoş geldiniz millet.

Ben Doug Aamoth'um; o Paul Ducklin'dir.

Paul, nasılsın?

ÖRDEK.  Wow!

16. yüzyıl bilgi teknolojisi kafatasları, Naked Security podcast'i Douglas ile buluşuyor.

Sabırsızlanıyorum

DOUG.  Açıkçası, evet… buna birazdan geleceğiz.

Ama önce, her zaman olduğu gibi, Tech History'de Bu Hafta, 28 Mayıs 1987'de çevrimiçi hizmet sağlayıcısı CompuServe, Graphics Interchange Format veya GIF [HARD G] adında küçük bir şey yayınladı.

Eski bilgisayar ağlarının sınırlı bant genişliği ve depolama kapasitelerinde renkli görüntüleri desteklemek için CompuServe'de bir mühendis olan (bu arada, "jif" olarak telaffuz edildiğine yemin eden) müteveffa Steve Wilhite tarafından geliştirildi.

İlk sürüm olan GIF 87a, maksimum 256 rengi destekledi; basit animasyonları gösterme yeteneği ve farklı bilgisayar sistemlerinde yaygın desteği nedeniyle hızla popülerlik kazandı.

Teşekkürler, Bay Wilhite.

ÖRDEK.  Bize ne bıraktı, Douglas?

Web animasyonları ve kelimenin "grafikler" [HARD G] veya "zürafalar" [SOFT G] olarak mı telaffuz edildiğine dair tartışmalar.

DOUG.  Aynen öyle. [GÜLER]

ÖRDEK.  Buna "giff" [HARD G] diyemem.

DOUG.  Aynı!

Bunu not edelim ve heyecan verici hikayemize geçelim…

...Kraliçe I. Elizabeth, İskoç Kraliçesi Mary ve bir adam hakkında iki tarafı da oynamak fidye yazılımı dolandırıcıları ve işvereni Paul arasında.

Fidye yazılımı hikayeleri: Gerçekten Ortadaki Adam'a neden olan MitM saldırısı

ÖRDEK.  [GÜLER] Hikayenin sonundan başlayalım.

Temel olarak, İngiltere'deki Oxfordshire'daki bir teknoloji şirketine yönelik bir fidye yazılımı saldırısıydı.

(Bu değil… Sophos'un bulunduğu Abingdon-on-Thames'in 15 km yukarısında, Oxford'da bir şirketti.)

Fidye yazılımı tarafından vurulduktan sonra, tahmin edebileceğiniz gibi, verilerini geri almak için Bitcoin ödeme talebiyle karşılaştılar.

Ve, bu hikaye gibi, elimizde bir birkaç hafta önceBununla başa çıkmalarına yardım etmesi gereken kendi savunma ekiplerinden biri, bir Ortadaki Adam saldırısı olan "Bir MiTM çalıştıracağım" diye düşündü.

Biliyorum ki, cinsiyetçi dilden kaçınmak ve bu günlerde her zaman bir insan (ortada genellikle bir bilgisayar) olmadığı gerçeğini yansıtmak için…

…Naked Security'de şimdi "Ortadaki Manipülatör" yazıyorum.

Ama bu kelimenin tam anlamıyla ortadaki bir adamdı.

Basitçe söylemek gerekirse Doug, sahtekarın e-posta adresine benzeyen bir tür yazım hatası e-posta hesabı kullanarak işverenine evden e-posta göndermeye başlamayı başardı.

Konuyu ele geçirdi ve geçmiş e-posta izlerindeki Bitcoin adresini değiştirdi, çünkü üst düzey yöneticilerin e-posta hesaplarına erişimi vardı…

...ve temelde bir ortadaki adam olarak müzakere etmeye başladı.

Şimdi sahtekarla bireysel olarak pazarlık ettiğini ve sonra bu pazarlığı işverenine devrettiğini hayal edin.

Tüm ödülü alıp kaçıp işverenine "Hey, bil bakalım ne oldu, dolandırıcılar bizi kandırdı" mı demeyi umuyordu, yoksa dolandırıcılarla kendi tarafında pazarlık mı yapmak istediğini bilmiyoruz. işvereni diğer tarafta.

Çünkü şirket içindeki korkuyu ve dehşeti artırmak için söylenecek doğru/yanlış her şeyi biliyordu.

Yani amacı temelde fidye yazılımı ödemesini ele geçirmekti.

Doug, her şey biraz ters gitti çünkü ne yazık ki kendisi ve neyse ki işvereni ve kolluk kuvvetleri için şirket ödeme yapmamaya karar verdi.

DOUG.  [GÜLER] Hmmmm!

ÖRDEK.  Yani çalacağı ve sonra kesip kaçacağı bir Bitcoin yoktu.

Ayrıca, izlerini pek iyi saklamadığı ve e-posta günlüklerine yasa dışı erişiminin ortaya çıktığı görülüyor.

Belli ki polislerin ona yaklaştığını biliyordu, çünkü evdeki bilgisayar ve telefonlarındaki hileli verileri silmeye çalıştı.

Ancak bunlara el konuldu ve veriler kurtarıldı.

Dava bir şekilde beş yıl sürdü ve sonunda, tam mahkemeye çıkmak üzereyken, açıkça dayanacak bir ayağı olmadığına karar verdi ve suçunu kabul etti.

İşte burada, Doug.

Kelimenin tam anlamıyla ortadaki adam saldırısı!

DOUG.  Tamam, yani 2023'te her şey yolunda ve güzel…

...ama bizi al 1580'lere dön, Paul.

İskoç Kraliçesi Mary ve Kraliçe Elizabeth I ne olacak?

ÖRDEK.  Dürüst olmak gerekirse, bunun ortadaki adam saldırısını tüm o yıllar öncesine giderek açıklamanın harika bir yolu olduğunu düşündüm.

Çünkü, ünlü olarak, Kraliçe Elizabeth ve kuzeni İskoç Kraliçesi Mary, dini ve siyasi düşmanlardı.

Elizabeth, İngiltere Kraliçesi idi; Mary taht talip oldu.

Böylece, Mary fiilen ev hapsinde tutuldu.

Mary bir tür lüks içinde yaşıyordu ama bir kaleye kapatılmıştı ve aslında kuzenine karşı komplo kuruyordu ama bunu kanıtlayamıyorlardı.

Ve Mary şatoya teslim edilen bira fıçılarının tıpalarına doldurulmuş mesajlar gönderip alıyordu.

Görünüşe göre, bu durumda, ortadaki adam uyumlu bir bira tedarikçisiydi ve mesajları Mary onları almadan önce silecek, böylece kopyalanabilecekti.

Ve Mary'nin şifresiyle şifrelenmiş, ince değişikliklerle, genel anlamda sonunda Mary'yi muhtemelen yazması gerekenden daha fazlasını yazmaya ikna eden yedek mesajlar eklerdi.

Bu yüzden sadece diğer komplocuların isimlerini vermekle kalmadı, aynı zamanda Kraliçe Elizabeth'e suikast planını onayladığını da belirtti.

O zamanlar daha zor zamanlardı… ve o günlerde İngiltere'de kesinlikle ölüm cezası vardı ve Mary yargılandı ve idam edildi.

Tarihteki en iyi 10 kırık şifreli metin

DOUG.  Tamam, dinleyen herkes için, bu podcast'in asansör konuşması, "Siber güvenlik haberleri ve tavsiyeleri ve biraz tarih serpiştirmesi".

Bugünkü ortadaki adamımıza geri dönelim.

Hakkında konuştuk başka bir içeriden tehdit tıpkı bunun gibi çok uzun zaman önce değil.

Yani bunun bir kalıp mı yoksa sadece bir tesadüf mü olduğunu görmek ilginç olurdu.

Ancak kendinizi bu tür saldırılara karşı korumak için yapabileceğiniz bazı şeylerden bahsettik, o yüzden bunları hızlıca tekrar gözden geçirelim.

İle başlayan: Böl ve fethet, bu da temelde "Şirketteki tek bir kişiye her şeye sınırsız erişim izni vermeyin" anlamına geliyor Paul.

ÖRDEK.  Evet.

DOUG.  Ve sonra elimizde: Değişmez günlükleri tut, bu durumda olmuş gibi görünüyordu, değil mi?

ÖRDEK.  Evet.

Görünüşe göre bu davadaki kilit kanıt unsuru, üst düzey yöneticilerin e-postalarını araştırıp değiştirmesi ve bunu saklayamamasıydı.

Yani, diğer kanıtlar olmasa bile, özellikle fidye yazılımı müzakereleri ve Bitcoin adresleriyle ilgili e-postaları karıştırdığını hayal edin, ekstra şüpheli olurdu.

DOUG.  Tamam, sonunda: Daima ölçün, asla varsaymayın.

ÖRDEK.  Aslında!

DOUG.  Sonunda iyi adamlar kazandı… beş yıl sürdü ama biz başardık.

Bir sonraki hikayemize geçelim.

Web güvenlik şirketi, uygulama oluşturma araç setinde bir oturum açma hatası bulur.

Hata hızlı ve şeffaf bir şekilde düzeltildi, yani bu güzel… ama biraz var hikayenin devamı, tabii ki Paul.

Ciddi Güvenlik: Doğrulama hayati önem taşır – bir OAUTH oturum açma hatasının incelenmesi

ÖRDEK.  Evet.

Bu, SALT adlı bir web kodlama güvenlik analizi şirketidir (umarım orada doğru terminolojiyi seçmişimdir) ve Expo adlı bir uygulama oluşturma araç setinde bir kimlik doğrulama güvenlik açığı buldular.

Ve kalplerini korusun, Expo OAUTH denen bir şeyi destekliyor, Açık Yetkilendirme sistem.

Bu, “Biliyor musun, kendimiz için şifre güvenliğini nasıl yapacağımızı öğrenmeye çalışmakla uğraşmak istemiyoruz” diye karar vermiş bir web sitesine girdiğinizde kullanılan sistem türüdür. Yapacağımız şey, 'Google ile giriş yap, Facebook ile giriş yap' diyeceğiz” gibi bir şey.

Ve fikir şu ki, kabaca konuşursak, Facebook veya Google veya ana akım hizmet her ne ise onunla iletişime geçersiniz ve "Hey, size bir şeyler vermek istiyorum. example.com X yapma izni.”

Yani, Facebook veya Google veya her neyse, kimliğinizi doğrular ve sonra şöyle der: "Tamam, işte karşı uca verebileceğiniz sihirli bir kod, 'Sizi kontrol ettik; bizimle kimlik doğrulaması yaptınız ve bu sizin kimlik doğrulama jetonunuz."

Ardından, diğer uç bağımsız olarak Facebook, Google veya her neyse, o belirtecin sizin adınıza verildiğinden emin olmak için kontrol edebilir.

Yani bu, siteye hiçbir zaman herhangi bir şifre vermeniz gerekmediği anlamına gelir… İsterseniz, gerçek kimlik doğrulama bölümünü sizin için yapması için Facebook veya Google'ı birlikte seçersiniz.

Butik bir web sitesiyseniz ve “Kendi kriptografimi örmeyeceğim” diye düşünüyorsanız harika bir fikir.

Yani, bu OAUTH'ta bir hata değil.

Bu sadece bir gözden kaçırma; Expo'nun OAUTH sürecini uygulamasında unutulan bir şey.

Ve kabaca konuşursak, Doug, bu böyle gider.

Expo kodu, Facebook ile kimlik doğrulaması yapmak için gereken tüm parametreleri içeren dev bir URL oluşturur ve ardından son sihirli erişim belirtecinin nereye gönderilmesi gerektiğine karar verir.

Bu nedenle, teorik olarak, kendi URL'nizi oluşturduysanız veya URL'yi değiştirebildiyseniz, bu sihirli kimlik doğrulama belirtecinin nihayet gönderildiği yeri değiştirebilirsiniz.

Ancak kullanıcıyı kandıramazsınız çünkü “Uygulama şu adreste: URL-here Facebook hesabınıza giriş yapmanızı istiyor. Buna tamamen güveniyor musunuz ve buna izin vermek mi istiyorsunuz? Evet veya hayır?"

Ancak iş Facebook'tan, Google'dan veya her neyse yetkilendirme kodunu alıp bu "dönüş URL'sine" iletme noktasına geldiğinde, Expo kodu gerçekten tıklayıp tıklamadığınızı kontrol etmez. Yes onay iletişim kutusunda.

Diyaloğu aktif olarak gördüyseniz ve tıkladıysanız No, o zaman saldırının gerçekleşmesini engellersiniz.

Ancak, esasen, bu "açılamadı".

Diyaloğu hiç görmediyseniz, yani tıklanacak bir şey olduğunu bile anlamazsanız ve hiçbir şey yapmazsanız ve ardından saldırganlar daha fazla JavaScript ile bir sonraki URL ziyaretini kendileri tetiklerler...

…o zaman sistem çalışırdı.

Ve işe yaramasının nedeni, süper gizli yetkilendirme kodunun gönderileceği sihirli "dönüş URL'sinin", Expo'nun daha sonra *siz tıklamadan önce kullanması için bir web tanımlama bilgisine ayarlanmış olmasıdır. Yes iletişim kutusunda*.

Daha sonra, bu "dönüş URL'si" tanımlama bilgisinin varlığı, dilerseniz, diyalog kutusunu görmüş olmanız ve devam etmeye karar vermiş olmanız gerektiğinin kanıtı olarak alınmıştır.

Oysa gerçekte durum böyle değildi.

Bu yüzden büyük bir sürçme, bardak ve dudağın arasındaydı, Douglas.

DOUG.  Pekala, şundan başlayarak bazı ipuçlarımız var: Bu hatayı bildirmeye ve ifşa etmeye gelince, bu bir ders kitabı vakasıydı.

Bunu neredeyse tam olarak böyle yapmalısın, Paul.

Her şey olması gerektiği gibi çalıştı, bu yüzden bu, bunun mümkün olan en iyi şekilde nasıl yapılacağına dair harika bir örnek.

ÖRDEK.  Naked Security üzerine yazmak istememin ana nedenlerinden biri de buydu.

SALT, böceği bulan insanlar…

..buldular; sorumlu bir şekilde ifşa ettiler; tam anlamıyla saatler içinde sorunu çözen Expo ile çalıştılar.

Bu yüzden, bir bug olmasına, bir kodlama hatası olmasına rağmen, SALT'ın "Biliyor musun, Expo çalışanları ile çalışmak mutlak bir zevkti" demesine yol açtı.

Ardından SALT bir CVE almaya başladı ve "Hey, hata şimdi düzeltildi, bu yüzden iki gün sonra bununla ilgili büyük bir PR sıçraması yapabiliriz" demek yerine, gerçekten yazacakları üç ay ileri bir tarih belirlediler. bulgularını toplar ve eğitim raporlarını yazarlar.

Son dakikada yakalanmaları ihtimaline karşı acil PR amaçları için aceleye getirmek yerine, bunu sadece dolandırıcılar bulmadan düzeltilebilmesi için sorumlu bir şekilde bildirmekle kalmadılar (ve kimsenin bu güvenlik açığını kötüye kullandığına dair bir kanıt yok), sonra da Expo'nun oraya gitmesi ve müşterileriyle iletişim kurması için biraz hareket alanı sağladı.

DOUG.  Ve sonra elbette, bunun hakkında biraz konuştuk: Kimlik doğrulama kontrollerinizin başarısız olduğundan emin olun.

Birisi yok sayarsa veya iptal ederse çalışmaya devam etmeyeceğinden emin olun.

Ancak buradaki daha büyük sorun şu: Asla kendi müşteri tarafı kodunuzun doğrulama sürecinin kontrolünde olacağını varsaymayın.

ÖRDEK.  Sizi bu OAUTH sürecinden geçirmek için Expo tarafından sağlanan JavaScript kodunun tam sürecini izlediyseniz, sorun olmazdı.

Ancak kodlarından kaçınırsanız ve açılır pencereyi atlamak veya iptal etmek de dahil olmak üzere kendi JavaScript'inizle bağlantıları tetiklerseniz, o zaman kazandınız.

İstemci kodunuzu atlamak, bir saldırganın düşüneceği ilk şeydir.

DOUG.  Pekala, son fakat en az değil: Aktif olarak kullanmadığınız zamanlarda web hesaplarından çıkış yapın.

Bu her yerde iyi bir tavsiye.

ÖRDEK.  Bunu Naked Security podcast'inde her zaman söylüyoruz ve uzun yıllar.

Çevrimiçi güvenlik için 3 basit adım

Popüler olmayan bir tavsiye çünkü insanlara "Hey, neden tarayıcınızı çıkışta tüm çerezleri temizleyecek şekilde ayarlamıyorsunuz?"

Düşünürseniz, bu özel durumda… oturum açmanın Facebook hesabınız üzerinden yapıldığını varsayalım; Facebook aracılığıyla OAUTH.

Facebook'tan çıkış yaptıysanız, bir saldırgan hangi JavaScript ihanetini denerse denesin (Expo açılır penceresini ve tüm bu şeyleri yok ederek), Facebook ile kimlik doğrulama işlemi başarılı olmaz çünkü Facebook, "Hey, bu kişinin onları doğrulamamı istiyor. Şu anda giriş yapmamışlar.”

Böylece her zaman ve kaçınılmaz olarak o noktada Facebook oturum açma açılır penceresini görürsünüz: "Şimdi oturum açmanız gerekiyor."

Ve bu hileyi hemen ortadan kaldırırdı.

DOUG.  Tamam çok iyi.

Ve günün son hikayemiz: Panik yapmayın, ama görünüşe göre açık kaynak şifre yöneticisi KeePass'ın ana şifresini kırmanın bir yolu var.

Ama yine de paniğe kapılmayın, çünkü bu bir çok daha karmaşık göründüğünden daha fazla, Paul.

Gerçekten birinin makinesinin kontrolüne sahip olmalısınız.

Ciddi Güvenlik: KeePass "ana parola kırma" ve ondan öğrenebileceklerimiz

ÖRDEK.  Yapmalısın.

Bunu izlemek istiyorsanız, CVE-2023-32784.

Bu büyüleyici bir böcek ve ben bir çeşit yazdım magnum opus Naked Security ile ilgili şu başlıklı stil makalesi: KeePass 'ana şifre kırma' ve bundan öğrenebileceklerimiz.

Bu nedenle, C tipi bellek tahsisi, komut dosyası dili tipi bellek tahsisi ve son olarak C# veya .NET tarafından yönetilen dizeler… sistem tarafından yönetilen bellek tahsisi konularına giren bu makaleyi bozmayacağım.

Ben sadece bu durumda araştırmacının ne keşfettiğini anlatacağım.

Yaptıkları şey... geçici de olsa bellekte ana parolayı bulmanın ne kadar kolay olabileceğine dair kanıt bulmak için KeePass koduna ve KeePass bellek dökümlerine baktılar.

Ya dakikalar, saatler veya günler sonra oradaysa?

Ya ana parola, siz bilgisayarınızı yeniden başlattıktan sonra bile hâlâ ortalıkta, belki de diskteki takas dosyanızda duruyorsa?

Bu yüzden KeePass'i kurdum ve kendime 16 karakterlik, tamamı büyük harflerden oluşan bir şifre verdim, böylece şifreyi hafızamda bulursam tanıması kolay olacaktı.

Ve bakın, hiçbir noktada ana parolamı bellekte buldum: bir ASCII dizesi olarak değil; Windows geniş karakter (UTF-16)) dizesi olarak değil.

Harika!

Ancak bu araştırmacının fark ettiği şey, şifrenizi KeePass'e yazdığınızda ortaya çıkıyor... Ben ona "Unicode blob karakteri" diyeceğim, sırf size göstermek için, evet, bir tuşa bastınız ve bu nedenle size göstermek için kaç karakter yazdığınız.

Böylece, parolanızı yazarken blob [●], blob-blob [●●], blob-blob-blob [●●●] dizesini ve benim durumumda 16 blob'a kadar her şeyi görürsünüz.

Pekala, bu leke dizileri bir güvenlik riski oluşturacak gibi görünmüyor, bu yüzden belki de "yönetilen dizeler" olarak yönetilmeleri için .NET çalışma zamanına bırakılıyorlardı ve daha sonra bellekte dolaşabiliyorlardı...

…ve temizlenmeyin çünkü "Hey, onlar sadece lekeler."

Görünen o ki, size 250 MB'lık muazzam bir şey sağlayan bir KeePass bellek dökümü yaparsanız ve blob-blob, blob-blob-blob vb. (herhangi bir sayıda blob) gibi dizgiler ararsanız, iki blob, sonra üç blob, sonra dört blob, sonra beş blob göreceğiniz bir yığın bellek dökümü… ve benim durumumda, 16 bloba kadar.

Ardından, isterseniz "yanlışlıkla meydana gelen damla karakterlerin" bu rastgele koleksiyonunu alacaksınız.

Başka bir deyişle, gerçek şifrenizi vermeseler bile, sadece bu blob dizelerini aramak, şifrenizin uzunluğunu sızdıracaktır.

Bununla birlikte, durum daha da ilginç hale geliyor, çünkü bu araştırmacının merak ettiği şey şu: "Ya bellekteki bu blob dizilerinin yakınındaki veriler bir şekilde parolayı yazdığınız tek tek karakterlere bağlıysa?"

Öyleyse, bellek dökümü dosyasını incelerseniz ve sadece iki blob, üç blob/dört blob aramak yerine daha fazlasını yapsanız…

…şifrede olduğunu düşündüğünüz bir karakterin izlediği bir dizi leke mi arıyorsunuz?

Yani, benim durumumda, sadece A'dan Z'ye karakterleri arıyordum çünkü şifrede bunun olduğunu biliyordum.

Herhangi bir leke dizisini ve ardından bir ASCII karakteri arıyorum.

Bil bakalım ne oldu Doug?

Parolamın üçüncü karakterini takip eden iki damla alıyorum; üç leke ve ardından parolamın dördüncü karakteri; 15 adede kadar blob, hemen ardından şifremdeki 16. karakter.

DOUG.  Evet, bu yazıda çılgın bir görsel var!

Ben de takip ediyordum... biraz teknikleşiyordu ve birdenbire "Vay be! Bu bir şifreye benziyor!”

ÖRDEK.  Temel olarak, şifrenizin tek tek karakterleri bellekte serbest bir şekilde dağılmış gibi, ancak ASCII karakterlerini temsil eden karakterler, siz onu yazarken aslında şifrenizin bir parçasıydı…

…sanki üzerlerine parlak bir zar yapıştırılmış gibi.

Dolayısıyla, bu blob dizileri yanlışlıkla parolanızdaki karakterleri işaretlemek için bir etiketleme mekanizması görevi görür.

Ve gerçekten, hikayeden alınacak ders şu ki, hiçbir şey beklemediğiniz şekillerde hafızadan dışarı sızabilir ve bilgili bir kod gözden geçiren bile fark etmeyebilir.

Bu yüzden büyüleyici bir okuma ve güvenli kod yazmanın düşündüğünüzden çok daha zor olabileceğini harika bir hatırlatma.

Ve daha da önemlisi, güvenli kodu incelemek, kaliteyi güvence altına almak ve test etmek daha da zor olabilir…

…çünkü kafanızın önünde, arkasında ve yanlarında gözleriniz olmalı ve gerçekten bir saldırgan gibi düşünmeli ve kesinlikle yapabildiğiniz her yerde sızdırılmış sırları aramaya çalışmalısınız.

DOUG.  , Tamam check it out, madesecurity.sophos.com adresindedir.

Ve şovumuzda güneş batmaya başladığında, okuyucularımızdan birinden haber almanın zamanı geldi.

Naked Security dinleyicisi Chang, bir önceki podcast'te (bu benim en sevdiğim yorumlardan biri, Paul), şu yorumu yapıyor:

Orada. Yaptım. Neredeyse iki yıl art arda dinledikten sonra, tüm Naked Security podcast bölümlerini dinlemeyi bitirdim. Tamamen kapıldım.

Uzun süredir devam eden Chet Chat ile başlayarak başından beri keyif aldım; sonra Birleşik Krallık ekibine; "Oh hayır! Sırada It's Kim” vardı; sonra nihayet günümüzün “Teknoloji Tarihinde Bu Hafta”ya ulaştım.

Ne gülmek!

Teşekkürler Chang!

Tüm bölümleri art arda yazdığına inanamıyorum, ama hepimiz (umarım sıra dışı konuşmuyorum) bunu çok takdir ediyoruz.

ÖRDEK.  Gerçekten çok, Doug!

İnsanların yalnızca dinlediğini değil, aynı zamanda podcast'leri yararlı bulduğunu ve bunun siber güvenlik hakkında daha fazla şey öğrenmelerine ve biraz da olsa oyunlarını yükseltmelerine yardımcı olduğunu bilmek güzel.

Çünkü bence, daha önce birçok kez söylediğim gibi, siber güvenlik oyunumuzu birazcık yükseltirsek, o zaman dolandırıcıları uzak tutmak için bir veya iki şirket, bir veya iki kuruluş, bir veya iki şirketten çok daha fazlasını yaparız. iki kişi büyük çaba sarf etti, ancak geri kalanımız geride kalıyor.

DOUG.  Kesinlikle!

Bunu gönderdiğin için tekrar çok teşekkür ederim Chang.

Gerçekten minnettarız.

Ve göndermek istediğiniz ilginç bir hikayeniz, yorumunuz veya sorunuz varsa, onu podcast'te okumayı çok isteriz.

Tips@sophos.com adresine e-posta gönderebilir, makalelerimizden herhangi biri hakkında yorum yapabilir veya sosyal medyadan bize ulaşabilirsiniz: @nakedsecurity.

Bugünkü programımız bu; dinlediğiniz için çok teşekkürler.

Paul Ducklin için, ben Doug Aamoth, bir dahaki sefere kadar size şunu hatırlatıyorum...

HER İKİSİ DE.  Güvende kalın!

[MÜZİKAL MODEM]