Security updates for Wednesday

Post Syndicated from jzb original https://lwn.net/Articles/1005163/

Security updates have been issued by Arch Linux (rsync), Debian (rsync), Fedora (perl-Net-OAuth and redis), Red Hat (ipa, raptor2, rsync, and tuned), Slackware (rsync), SUSE (apache2-mod_jk, git, kernel, rclone, rsync, and webkit2gtk3), and Ubuntu (git, linux-azure-5.4, pdns, pdns-recursor, python-django, rlottie, and rsync).

Видео конкурс “По силни от думите” възпитава в хуманизъм

Post Syndicated from Екип на Биволъ original https://bivol.bg/video-concurs_alef.html

сряда 15 януари 2025


Младежи от три средни училища се включиха в конкурса “По-силни от думите”, организиран от Център за еврейско-българско сътрудничество “Алеф”, в рамките на инициативата „Толерантност срещу омразата – прилагане ценностите на…

Материалът Видео конкурс “По силни от думите” възпитава в хуманизъм е публикуван за пръв път на Bivol!.

Научната етика в Силициевата долина. Измамата „Теранос“

Post Syndicated from original https://www.toest.bg/nauchnata-etika-v-silitsievata-dolina-izmamata-theranos/

Научната етика в Силициевата долина. Измамата „Теранос“

Въпреки че „Теранос“ е оценена на 9 млрд. долара и съществува в продължение на 15 години, тя приключва дейността си без постигнат научен успех, а през 2022 и 2023 г. основателката ѝ Елизабет Холмс и нейният съдружник и главен оперативен директор на компанията Рамеш Балвани са осъдени съответно на над 11 и над 12 години затвор за измама на инвеститорите и пациентите.

Коя е Елизабет Холмс

Елизабет Холмс е родена през 1984 г. в столицата на САЩ – Вашингтон. Баща ѝ e вицепрезидент на енергийна компания, която фалира след скандал със счетоводни измами. Майка ѝ работи за правителството като политически съветник в Капитолия. Елизабет е наполовина датчанка, а прапрапрадядо ѝ е имигрант с еврейско-унгарски произход и през далечната 1868 година основава все още съществуващата компания за мая за хляб Fleischmann’s Yeast.

Елизабет Холмс завършва гимназията St. John’s School в Хюстън. Родителите ѝ я записват на частни уроци по мандарин, а след това посещава и лятната програма по мандарин в Станфордския университет.

През 2002 г. Холмс започва да изучава инженерна химия в Станфорд и работи като студент изследовател и лабораторен асистент. В края на първи курс е част от екипа на лаборатория към Геномния институт в Сингапур и участва в изследването на вируса SARS-CoV-1, като събира кръвни проби.

През 2004 г. напуска Станфорд и използва парите за обучението си за финансиране на компания, свързана с разработването на технологии в сферата на здравеопазването.

Компанията „Теранос“

Едва на 19 години, през 2003-та Елизабет Холмс основава компанията „Теранос“ (името произхожда от английските думи за терапия – therapy, и диагноза – diagnosis). Мисията ѝ е да промени здравната система и да даде възможност на пациентите да се грижат за здравето си по по-достъпен начин. Страхът на Холмс от игли води до разработването на технология, с която могат да се извършат редица диагностични тестове с малко количество кръв, взета от убождане на пръста.

Рамеш Балвани – Съни става част от „Теранос“ през 2009 г. Преди това е работил за добре известни технологични компании, като Lotus Software, Microsoft (в отдел „Продажби“) и CommerceBid.com. Впоследствие става ясно, че Балвани е упражнявал контрол върху служителите чрез лични нападки и заплахи, държейки отделните звена в пълно неведение за работата на колегите им заради страха си от индустриален шпионаж.

„Теранос“ има претенции, че предлага кръвни изследвания на най-ниски цени, като пациентите дават само няколко капки кръв в т.нар. нанотейнер. Компанията разработва патентовано устройство за извършване на изследванията, наречено Едисън. Революционните обещания за промяна в здравната система и медийният интерес увеличават интереса на инвеститорите и през 2014 г. „Теранос“ е оценена на 9 млрд. долара.

Изглежда, че компанията е успешна, но всъщност има множество затруднения по пътя на усъвършенстване на технологията, без която е невъзможно да постигне целта си да предоставя многобройни диагностични тестове наведнъж. Не са публикувани никакви резултати, с които технологията ѝ да може да се сравни с вече установени и одобрени за диагностика технологии и да се оценят точността, качеството и ефективността на „Едисън“.

Скептични експерти посочват, че количеството кръв, необходимо за изследванията, не е достатъчно за извършването на множество тестове и за получаване на коректен резултат. С времето става напълно ясно, че е абсолютно невъзможно теоретичният начин на работа на технологията да се приложи на практика и не представлява невероятен научен пробив – съответно обещанията на компанията са напразни. Двама учени (Тейлър Шулц и Ерика Чънг) от компанията решават да изобличат „Теранос“, като разкриват, че компанията фалшифицира научни процедури и резултати.

Измамата „Теранос“ и научната етика

„Теранос“ работи в т.нар. научен вакуум според Джон Кариру, автор на книгата Bad Blood, в която се разглежда историята на Елизабет Холмс. Компанията обещава да трансформира здравните грижи, тестват се множество пациенти, но не са открити доказателства, че продуктите, които произвежда, са сигурни и безопасни. Липсва и ясно обяснение как работи технологията. Няма повторяемост на изследванията върху разработените устройства, която е задължителна част от доказателствата за ефективността и приложимостта им. Не са били изнасяни презентации на научни конференции. Служителите са максимално изолирани един от друг, а текучеството на кадри е голямо. Работи се в страх. 

Учените от „Теранос“, изразяващи гласно притесненията си, са уволнявани и задължавани да подписват споразумения, че няма да разкриват фирмени тайни, в противен случай ще се наложи да се изправят пред съда. Иън Гибонс, биохимик и молекулярен биолог, се самоубива ден преди да свидетелства в съдебен процес за технологията, която компанията използва. Организацията се е основавала на безразсъдство, наивност, ласкателство и потайност. Научната етика, която очевидно липсва при „Теранос“, изисква открити проучвания, стриктни правила при тестване, възпроизводимост на резултатите, прозрачност и споделяне на новите открития.

Присъдата на Елизабет Холмс

Първите обвинения, повдигнати срещу Елизабет Холмс през 2018 г., са за измама на инвеститорите и на пациентите, използвали услугите на компанията. През 2022 г. тя е осъдена на 11 години и 3 месеца затвор за измама на инвеститорите, а по обвиненията за измама на пациенти е оправдана. От 27 април 2023 г. Елизабет Холмс излежава присъдата си ефективно в щатски затвор.

По време на отделен съдебен процес Балвани е осъден на 12 години и 11 месеца затвор за измама на инвеститорите и застрашаване на здравето на пациентите.

Бъдещето на науката в Силициевата долина

Провалът на „Теранос“ повдига много въпроси и един от тях категорично е дали е редно стартъп компании в Силициевата долина да се занимават с медицински научни изследвания.

В същото време извън Силициевата долина се постига голям напредък в сферата на медицинската диагностика: автоматизиране на клинични анализи, откриване на биомаркери, въвеждане на метаболомика и изкуствен интелект. За здравеопазването в световен мащаб е изключително важно финансовата подкрепа да не секва, инвестициите да не спират, а с тях и желанието за нови технологии.

В Силициевата долина важи правилото Fake it till you make it („Прави се, че си успял, докато не успееш наистина“), компаниите се чувстват задължени да рекламират продуктите си още преди да са създадени, и да дават предварителни нереалистични обещания. Този подход не работи в сферата на медицината и науката. Изводите от провала на „Теранос“ са, че научната общност трябва да държи отговорни технологичните компании, да разглежда доказателствата и да показва възникналите проблеми. Само така инвеститорите, мениджърите на здравни системи и политиците ще имат по-ясен поглед върху нещата.

Заглавно изображение: Елизабет Холмс, основателка и главна изпълнителна директорка на „Теранос“, и Джонатан Шибър от TechCrunch по време на TechCrunch Disrupt в Сан Франциско. Септември, 2014 г. Източник: TechCrunch / Creative Commons

Patch Tuesday – January 2025

Post Syndicated from Adam Barnett original https://blog.rapid7.com/2025/01/14/patch-tuesday-january-2025/

Patch Tuesday - January 2025

Microsoft is addressing 161 vulnerabilities this January 2025 Patch Tuesday. Microsoft has evidence of in-the-wild exploitation and/or public disclosure for eight of the vulnerabilities published today, with three listed on CISA KEV. This is now the fourth consecutive month where Microsoft has published zero-day vulnerabilities on Patch Tuesday without evaluating any of them as critical severity at time of publication. Today also sees the publication of nine critical remote code execution (RCE) vulnerabilities. Unusually, Microsoft has not yet published any browser vulnerabilities this month.

Access: triple zero-day RCE

Today sees the publication of three very similar zero-day Microsoft Access vulnerabilities: CVE-2025-21366, CVE-2025-21395, and CVE-2025-21186. In each case, Microsoft notes public disclosure, but does not claim evidence of exploitation in the wild. Successful exploitation leads to code execution via heap-based buffer overflow, and requires that an attacker convince the user to download and open a malicious file.

Curiously, in each case, one portion of the advisory FAQ describes the update protection as “blocking potentially malicious extensions from being sent in an email”, but the remainder of the advisory doesn’t clarify how this would prevent malicious activity. Typically, patches provide protection by blocking malicious files upon receipt of a malicious email attachment, rather than preventing a malicious attachment from being sent in the first place, since an attacker is free to send whatever they like from any system they control.

The FAQ does mention that users who would otherwise have interacted with a malicious attachment will instead receive a notification that there was an attachment but “it cannot be accessed”, which is perhaps the best play on words we’ve seen from MSRC in a while.

Hyper-V NT Kernel Integration VSP: triple zero-day EoP

Microsoft is addressing a trio of related Windows Hyper-V NT Kernel Integration VSP elevation of privilege vulnerabilities today: CVE-2025-21333, CVE-2025-21334, and CVE-2025-21335. Microsoft is aware of exploitation in the wild for all three, as seen on both the Microsoft advisories and CISA KEV. In each case, exploitation leads to SYSTEM privileges. The advisories are short on additional detail, beyond a brief acknowledgement of Anonymous — presumably an undisclosed party, rather than the hacktivist collective — on CVE-2025-21333.

While we can sometimes infer context from prior examples, in this case there aren’t any; there is no mention of Hyper-V NT Kernel Integration VSP in any vulnerability published by Microsoft, at least as far back as 2017. If we look back five years, CVE-2020-16885 does describe an elevation of privilege vulnerability in the Windows storage VSP driver, but there isn’t a lot to go on there either.

The Virtualization Service Provider (VSP) resides in the root partition of a Hyper-V instance, and provides synthetic device support to child partitions over the Virtual Machine Bus (VMBus): it’s the foundation of how Hyper-V allows the child partition to trick itself into thinking that it’s a real computer. Given that the entire thing is a security boundary, it’s perhaps surprising that no Hyper-V NT Kernel Integration VSP vulnerabilities have been acknowledged by Microsoft until today, but it won’t be at all shocking if more now emerge.

The advisories published today do not clarify whether the elevation of privilege is only to SYSTEM within the child partition, but container escape specialists will surely be hunting for exploits in this area.

Windows Themes: zero-day NTLM disclosure

Many enterprise users or even admins may not think about Windows Themes very often, but consider CVE-2025-21308: a spoofing vulnerability where successful exploitation leads to improper disclosure of an NTLM hash, which allows an attacker to impersonate the user from whom it was acquired. Microsoft does not have evidence of in-the-wild exploitation, but does note public disclosure.

The advisory FAQ dances around the exploitation methodology without explaining; what we learn is that once an attacker had somehow delivered a malicious file to the target system, a user would need to manipulate the malicious file, but not necessarily click or open it. Without further detail, we can only speculate, but it’s plausible that simply opening a folder containing the file in Windows Explorer — including the Downloads folder — or inserting a USB drive, would be enough to trigger the vulnerability and see your NTLM hash leak silently for collection by the threat actor.

Some good news: Microsoft has removed NTLMv1 support from Windows 11 24H2 and Server 2025 onwards. Less good: it has been a whole two months since Microsoft last patched a zero-day NTLM disclosure vulnerability; that flaw was within MSHTML/Trident, and Windows 11 24H2 and Server 2025 were still vulnerable, since NTLMv2 is still supported across the board.

On the advisory for CVE-2025-21308, Microsoft does link to documents describing a mitigation technique: restricting NTLM traffic. This is certainly worth a look, since a representative of reporting research organization 0patch has confirmed that NTLMv2 is affected by CVE-2025-21308.

Windows Installer: zero-day EoP

Installing or updating software often requires elevated privileges, and researchers and threat actors have known this for a long time. The advisory for CVE-2025-21275 doesn’t weigh us down with lengthy explanations, it simply says that successful exploitation leads to SYSTEM privileges. Microsoft is aware of public disclosure of this vulnerability, but not in-the-wild exploitation.

CVE-2025-21275 is the latest in a long line of Windows Installer elevation of privilege vulnerabilities; Microsoft has now published 37 Windows Installer elevation of privilege vulnerabilities in total since the start of 2020, although only five of those have been zero-days, with only CVE-2024-38014 known by Microsoft to have been exploited prior to publication in September 2024.

PGM: critical RCE

Microsoft’s in-house research teams are a reliable source of vulnerability discovery in Microsoft products, and today we get patches for the self-discovered CVE-2025-21307, a critical RCE in the Windows Reliable Multicast Transport Driver (RMCAST) with a CVSSv3 base score of 9.8. The vulnerability is only exploitable on a system where a program is listening on a Pragmatic General Multicast (PGM) port.

In 2025, you might very well expect that any service that a major commercial operating system exposes to the network would provide at least some form of authentication capability, but if so, prepare to be disappointed by the Windows implementation of PGM. The concept was first described in RFC 3208, which was published in 2001 in an Experimental state and stayed that way. As Microsoft themselves put it, “the PGM specification [RFC3208] is ambiguous in a number of areas”.

Given the lack of required user interaction and remote attack vector for CVE-2025-21307, it’s well worth asking yourself: does our firewall allow a PGM receiver to receive inbound traffic from the public internet? If so, the second-best time to prevent that is right now.

OLE: critical RCE

Outlook admins who force their users to read emails in plain text only can skip this paragraph, but everyone else should be aware of CVE-2025-21298, a Windows Object Linking and Embedding (OLE) critical RCE with a CVSSv3 base score of 9.8. The eternal threat of the malicious inbound email finds expression again here; just previewing the wrong email in Outlook is all it takes for an attacker to achieve code execution in the context of the user. All versions of Windows receive a patch.

Microsoft lifecycle update

In Microsoft product lifecycle news, Visual Studio 2022 17.6 LTSC receives its last update today.

Summary Charts

Patch Tuesday - January 2025
Patch Tuesday - January 2025
Patch Tuesday - January 2025
Windows Telephony Service looming large this month

Summary tables

Azure vulnerabilities

CVE Title Exploited? Publicly disclosed? CVSSv3 base score
CVE-2025-21380 Azure Marketplace SaaS Resources Information Disclosure Vulnerability No No 8.8
CVE-2025-21403 On-Premises Data Gateway Information Disclosure Vulnerability No No 6.4

Developer Tools vulnerabilities

CVE Title Exploited? Publicly disclosed? CVSSv3 base score
CVE-2025-21178 Visual Studio Remote Code Execution Vulnerability No No 8.8
CVE-2025-21176 .NET, .NET Framework, and Visual Studio Remote Code Execution Vulnerability No No 8.8
CVE-2025-21172 .NET and Visual Studio Remote Code Execution Vulnerability No No 7.5
CVE-2025-21171 .NET Remote Code Execution Vulnerability No No 7.5
CVE-2024-50338 GitHub: CVE-2024-50338 Malformed URL allows information disclosure through git-credential-manager No No 7.4
CVE-2025-21405 Visual Studio Elevation of Privilege Vulnerability No No 7.3
CVE-2025-21173 .NET Elevation of Privilege Vulnerability No No 7.3

ESU Windows vulnerabilities

CVE Title Exploited? Publicly disclosed? CVSSv3 base score
CVE-2025-21307 Windows Reliable Multicast Transport Driver (RMCAST) Remote Code Execution Vulnerability No No 9.8
CVE-2025-21298 Windows OLE Remote Code Execution Vulnerability No No 9.8
CVE-2025-21411 Windows Telephony Service Remote Code Execution Vulnerability No No 8.8
CVE-2025-21413 Windows Telephony Service Remote Code Execution Vulnerability No No 8.8
CVE-2025-21233 Windows Telephony Service Remote Code Execution Vulnerability No No 8.8
CVE-2025-21236 Windows Telephony Service Remote Code Execution Vulnerability No No 8.8
CVE-2025-21237 Windows Telephony Service Remote Code Execution Vulnerability No No 8.8
CVE-2025-21243 Windows Telephony Service Remote Code Execution Vulnerability No No 8.8
CVE-2025-21244 Windows Telephony Service Remote Code Execution Vulnerability No No 8.8
CVE-2025-21252 Windows Telephony Service Remote Code Execution Vulnerability No No 8.8
CVE-2025-21266 Windows Telephony Service Remote Code Execution Vulnerability No No 8.8
CVE-2025-21282 Windows Telephony Service Remote Code Execution Vulnerability No No 8.8
CVE-2025-21302 Windows Telephony Service Remote Code Execution Vulnerability No No 8.8
CVE-2025-21303 Windows Telephony Service Remote Code Execution Vulnerability No No 8.8
CVE-2025-21306 Windows Telephony Service Remote Code Execution Vulnerability No No 8.8
CVE-2025-21273 Windows Telephony Service Remote Code Execution Vulnerability No No 8.8
CVE-2025-21286 Windows Telephony Service Remote Code Execution Vulnerability No No 8.8
CVE-2025-21305 Windows Telephony Service Remote Code Execution Vulnerability No No 8.8
CVE-2025-21339 Windows Telephony Service Remote Code Execution Vulnerability No No 8.8
CVE-2025-21246 Windows Telephony Service Remote Code Execution Vulnerability No No 8.8
CVE-2025-21417 Windows Telephony Service Remote Code Execution Vulnerability No No 8.8
CVE-2025-21250 Windows Telephony Service Remote Code Execution Vulnerability No No 8.8
CVE-2025-21240 Windows Telephony Service Remote Code Execution Vulnerability No No 8.8
CVE-2025-21238 Windows Telephony Service Remote Code Execution Vulnerability No No 8.8
CVE-2025-21223 Windows Telephony Service Remote Code Execution Vulnerability No No 8.8
CVE-2025-21409 Windows Telephony Service Remote Code Execution Vulnerability No No 8.8
CVE-2025-21245 Windows Telephony Service Remote Code Execution Vulnerability No No 8.8
CVE-2025-21293 Active Directory Domain Services Elevation of Privilege Vulnerability No No 8.8
CVE-2025-21297 Windows Remote Desktop Services Remote Code Execution Vulnerability No No 8.1
CVE-2025-21309 Windows Remote Desktop Services Remote Code Execution Vulnerability No No 8.1
CVE-2025-21295 SPNEGO Extended Negotiation (NEGOEX) Security Mechanism Remote Code Execution Vulnerability No No 8.1
CVE-2025-21294 Microsoft Digest Authentication Remote Code Execution Vulnerability No No 8.1
CVE-2025-21287 Windows Installer Elevation of Privilege Vulnerability No No 7.8
CVE-2025-21378 Windows CSC Service Elevation of Privilege Vulnerability No No 7.8
CVE-2025-21281 Microsoft COM for Windows Elevation of Privilege Vulnerability No No 7.8
CVE-2025-21389 Windows upnphost.dll Denial of Service Vulnerability No No 7.5
CVE-2025-21300 Windows upnphost.dll Denial of Service Vulnerability No No 7.5
CVE-2025-21276 Windows MapUrlToZone Denial of Service Vulnerability No No 7.5
CVE-2025-21218 Windows Kerberos Denial of Service Vulnerability No No 7.5
CVE-2025-21220 Microsoft Message Queuing Information Disclosure Vulnerability No No 7.5
CVE-2025-21251 Microsoft Message Queuing (MSMQ) Denial of Service Vulnerability No No 7.5
CVE-2025-21270 Microsoft Message Queuing (MSMQ) Denial of Service Vulnerability No No 7.5
CVE-2025-21277 Microsoft Message Queuing (MSMQ) Denial of Service Vulnerability No No 7.5
CVE-2025-21285 Microsoft Message Queuing (MSMQ) Denial of Service Vulnerability No No 7.5
CVE-2025-21289 Microsoft Message Queuing (MSMQ) Denial of Service Vulnerability No No 7.5
CVE-2025-21290 Microsoft Message Queuing (MSMQ) Denial of Service Vulnerability No No 7.5
CVE-2025-21230 Microsoft Message Queuing (MSMQ) Denial of Service Vulnerability No No 7.5
CVE-2025-21231 IP Helper Denial of Service Vulnerability No No 7.5
CVE-2025-21296 BranchCache Remote Code Execution Vulnerability No No 7.5
CVE-2025-21331 Windows Installer Elevation of Privilege Vulnerability No No 7.3
CVE-2025-21211 Secure Boot Security Feature Bypass Vulnerability No No 6.8
CVE-2024-7344 Cert CC: CVE-2024-7344 Howyar Taiwan Secure Boot Bypass No No 6.7
CVE-2025-21249 Windows Digital Media Elevation of Privilege Vulnerability No No 6.6
CVE-2025-21255 Windows Digital Media Elevation of Privilege Vulnerability No No 6.6
CVE-2025-21258 Windows Digital Media Elevation of Privilege Vulnerability No No 6.6
CVE-2025-21260 Windows Digital Media Elevation of Privilege Vulnerability No No 6.6
CVE-2025-21263 Windows Digital Media Elevation of Privilege Vulnerability No No 6.6
CVE-2025-21265 Windows Digital Media Elevation of Privilege Vulnerability No No 6.6
CVE-2025-21327 Windows Digital Media Elevation of Privilege Vulnerability No No 6.6
CVE-2025-21341 Windows Digital Media Elevation of Privilege Vulnerability No No 6.6
CVE-2025-21226 Windows Digital Media Elevation of Privilege Vulnerability No No 6.6
CVE-2025-21227 Windows Digital Media Elevation of Privilege Vulnerability No No 6.6
CVE-2025-21228 Windows Digital Media Elevation of Privilege Vulnerability No No 6.6
CVE-2025-21229 Windows Digital Media Elevation of Privilege Vulnerability No No 6.6
CVE-2025-21232 Windows Digital Media Elevation of Privilege Vulnerability No No 6.6
CVE-2025-21256 Windows Digital Media Elevation of Privilege Vulnerability No No 6.6
CVE-2025-21261 Windows Digital Media Elevation of Privilege Vulnerability No No 6.6
CVE-2025-21310 Windows Digital Media Elevation of Privilege Vulnerability No No 6.6
CVE-2025-21324 Windows Digital Media Elevation of Privilege Vulnerability No No 6.6
CVE-2025-21308 Windows Themes Spoofing Vulnerability No Yes 6.5
CVE-2025-21217 Windows NTLM Spoofing Vulnerability No No 6.5
CVE-2025-21272 Windows COM Server Information Disclosure Vulnerability No No 6.5
CVE-2025-21288 Windows COM Server Information Disclosure Vulnerability No No 6.5
CVE-2025-21278 Windows Remote Desktop Gateway (RD Gateway) Denial of Service Vulnerability No No 6.2
CVE-2025-21242 Windows Kerberos Information Disclosure Vulnerability No No 5.9
CVE-2025-21336 Windows Cryptographic Information Disclosure Vulnerability No No 5.6
CVE-2025-21316 Windows Kernel Memory Information Disclosure Vulnerability No No 5.5
CVE-2025-21318 Windows Kernel Memory Information Disclosure Vulnerability No No 5.5
CVE-2025-21319 Windows Kernel Memory Information Disclosure Vulnerability No No 5.5
CVE-2025-21320 Windows Kernel Memory Information Disclosure Vulnerability No No 5.5
CVE-2025-21321 Windows Kernel Memory Information Disclosure Vulnerability No No 5.5
CVE-2025-21274 Windows Event Tracing Denial of Service Vulnerability No No 5.5
CVE-2025-21374 Windows CSC Service Information Disclosure Vulnerability No No 5.5
CVE-2025-21215 Secure Boot Security Feature Bypass Vulnerability No No 4.6
CVE-2025-21213 Secure Boot Security Feature Bypass Vulnerability No No 4.6
CVE-2025-21269 Windows HTML Platforms Security Feature Bypass Vulnerability No No 4.3
CVE-2025-21268 MapUrlToZone Security Feature Bypass Vulnerability No No 4.3
CVE-2025-21329 MapUrlToZone Security Feature Bypass Vulnerability No No 4.3
CVE-2025-21328 MapUrlToZone Security Feature Bypass Vulnerability No No 4.3
CVE-2025-21189 MapUrlToZone Security Feature Bypass Vulnerability No No 4.3
CVE-2025-21332 MapUrlToZone Security Feature Bypass Vulnerability No No 4.3
CVE-2025-21210 Windows BitLocker Information Disclosure Vulnerability No No 4.2
CVE-2025-21214 Windows BitLocker Information Disclosure Vulnerability No No 4.2
CVE-2025-21312 Windows Smart Card Reader Information Disclosure Vulnerability No No 2.4

ESU Windows Microsoft Office vulnerabilities

CVE Title Exploited? Publicly disclosed? CVSSv3 base score
CVE-2025-21338 GDI+ Remote Code Execution Vulnerability No No 7.8

Microsoft Dynamics vulnerabilities

CVE Title Exploited? Publicly disclosed? CVSSv3 base score
CVE-2025-21187 Microsoft Power Automate Remote Code Execution Vulnerability No No 7.8

Microsoft Office vulnerabilities

CVE Title Exploited? Publicly disclosed? CVSSv3 base score
CVE-2025-21385 Microsoft Purview Information Disclosure Vulnerability No No 8.8
CVE-2025-21363 Microsoft Word Remote Code Execution Vulnerability No No 7.8
CVE-2025-21344 Microsoft SharePoint Server Remote Code Execution Vulnerability No No 7.8
CVE-2025-21361 Microsoft Outlook Remote Code Execution Vulnerability No No 7.8
CVE-2025-21345 Microsoft Office Visio Remote Code Execution Vulnerability No No 7.8
CVE-2025-21356 Microsoft Office Visio Remote Code Execution Vulnerability No No 7.8
CVE-2025-21365 Microsoft Office Remote Code Execution Vulnerability No No 7.8
CVE-2025-21402 Microsoft Office OneNote Remote Code Execution Vulnerability No No 7.8
CVE-2025-21364 Microsoft Excel Security Feature Bypass Vulnerability No No 7.8
CVE-2025-21354 Microsoft Excel Remote Code Execution Vulnerability No No 7.8
CVE-2025-21362 Microsoft Excel Remote Code Execution Vulnerability No No 7.8
CVE-2025-21360 Microsoft AutoUpdate (MAU) Elevation of Privilege Vulnerability No No 7.8
CVE-2025-21366 Microsoft Access Remote Code Execution Vulnerability No Yes 7.8
CVE-2025-21395 Microsoft Access Remote Code Execution Vulnerability No Yes 7.8
CVE-2025-21186 Microsoft Access Remote Code Execution Vulnerability No Yes 7.8
CVE-2025-21348 Microsoft SharePoint Server Remote Code Execution Vulnerability No No 7.2
CVE-2025-21346 Microsoft Office Security Feature Bypass Vulnerability No No 7.1
CVE-2025-21357 Microsoft Outlook Remote Code Execution Vulnerability No No 6.7
CVE-2025-21393 Microsoft SharePoint Server Spoofing Vulnerability No No 6.3

Windows vulnerabilities

CVE Title Exploited? Publicly disclosed? CVSSv3 base score
CVE-2025-21311 Windows NTLM V1 Elevation of Privilege Vulnerability No No 9.8
CVE-2025-21239 Windows Telephony Service Remote Code Execution Vulnerability No No 8.8
CVE-2025-21241 Windows Telephony Service Remote Code Execution Vulnerability No No 8.8
CVE-2025-21248 Windows Telephony Service Remote Code Execution Vulnerability No No 8.8
CVE-2025-21292 Windows Search Service Elevation of Privilege Vulnerability No No 8.8
CVE-2025-21291 Windows Direct Show Remote Code Execution Vulnerability No No 8.8
CVE-2025-21224 Windows Line Printer Daemon (LPD) Service Remote Code Execution Vulnerability No No 8.1
CVE-2025-21370 Windows Virtualization-Based Security (VBS) Enclave Elevation of Privilege Vulnerability No No 7.8
CVE-2025-21234 Windows PrintWorkflowUserSvc Elevation of Privilege Vulnerability No No 7.8
CVE-2025-21235 Windows PrintWorkflowUserSvc Elevation of Privilege Vulnerability No No 7.8
CVE-2025-21335 Windows Hyper-V NT Kernel Integration VSP Elevation of Privilege Vulnerability Yes No 7.8
CVE-2025-21333 Windows Hyper-V NT Kernel Integration VSP Elevation of Privilege Vulnerability Yes No 7.8
CVE-2025-21334 Windows Hyper-V NT Kernel Integration VSP Elevation of Privilege Vulnerability Yes No 7.8
CVE-2025-21382 Windows Graphics Component Elevation of Privilege Vulnerability No No 7.8
CVE-2025-21271 Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability No No 7.8
CVE-2025-21275 Windows App Package Installer Elevation of Privilege Vulnerability No Yes 7.8
CVE-2025-21304 Microsoft DWM Core Library Elevation of Privilege Vulnerability No No 7.8
CVE-2025-21315 Microsoft Brokering File System Elevation of Privilege Vulnerability No No 7.8
CVE-2025-21372 Microsoft Brokering File System Elevation of Privilege Vulnerability No No 7.8
CVE-2025-21326 Internet Explorer Remote Code Execution Vulnerability No No 7.8
CVE-2025-21343 Windows Web Threat Defense User Service Information Disclosure Vulnerability No No 7.5
CVE-2025-21330 Windows Remote Desktop Services Denial of Service Vulnerability No No 7.5
CVE-2025-21207 Windows Connected Devices Platform Service (Cdpsvc) Denial of Service Vulnerability No No 7.5
CVE-2025-21299 Windows Kerberos Security Feature Bypass Vulnerability No No 7.1
CVE-2025-21314 Windows SmartScreen Spoofing Vulnerability No No 6.5
CVE-2025-21313 Windows Security Account Manager (SAM) Denial of Service Vulnerability No No 6.5
CVE-2025-21301 Windows Geolocation Service Information Disclosure Vulnerability No No 6.5
CVE-2025-21193 Active Directory Federation Server Spoofing Vulnerability No No 6.5
CVE-2025-21202 Windows Recovery Environment Agent Elevation of Privilege Vulnerability No No 6.1
CVE-2025-21225 Windows Remote Desktop Gateway (RD Gateway) Denial of Service Vulnerability No No 5.9
CVE-2025-21257 Windows WLAN AutoConfig Service Information Disclosure Vulnerability No No 5.5
CVE-2025-21340 Windows Virtualization-Based Security (VBS) Security Feature Bypass Vulnerability No No 5.5
CVE-2025-21280 Windows Virtual Trusted Platform Module Denial of Service Vulnerability No No 5.5
CVE-2025-21284 Windows Virtual Trusted Platform Module Denial of Service Vulnerability No No 5.5
CVE-2025-21317 Windows Kernel Memory Information Disclosure Vulnerability No No 5.5
CVE-2025-21323 Windows Kernel Memory Information Disclosure Vulnerability No No 5.5
CVE-2025-21219 MapUrlToZone Security Feature Bypass Vulnerability No No 4.3

AWS achieves HDS certification for 24 AWS Regions

Post Syndicated from Tea Jioshvili original https://aws.amazon.com/blogs/security/aws-achieves-hds-certification-for-24-aws-regions/

Amazon Web Services (AWS) is pleased to announce a successful completion of the Health Data Hosting (Hébergeur de Données de Santé, HDS) certification audit, and renewal of the HDS certification for 24 AWS Regions.

The Agence du Numérique en Santé (ANS), the French governmental agency for health, introduced the HDS certification to strengthen the security and protection of personal health data. By achieving this certification, AWS demonstrates our continuous commitment to adhere to the heightened expectations for cloud service providers.

The following 24 Regions are in scope for this certification:

  • US East (Ohio)
  • US East (N. Virginia)
  • US West (N. California)
  • US West (Oregon)
  • Asia Pacific (Hong Kong)
  • Asia Pacific (Hyderabad)
  • Asia Pacific (Jakarta)
  • Asia Pacific (Mumbai)
  • Asia Pacific (Osaka)
  • Asia Pacific (Seoul)
  • Asia Pacific (Singapore)
  • Asia Pacific (Sydney)
  • Asia Pacific (Tokyo)
  • Canada (Central)
  • Europe (Frankfurt)
  • Europe (Ireland)
  • Europe (London)
  • Europe (Milan)
  • Europe (Paris)
  • Europe (Stockholm)
  • Europe (Zurich)
  • Israel (Tel Aviv)
  • Middle East (UAE)
  • South America (São Paulo)

The HDS certification demonstrates that AWS provides a framework for technical and governance measures to secure and protect personal health data according to HDS requirements. Our customers who handle personal health data can continue to manage their workloads in HDS-certified Regions with confidence.

Independent third-party auditors evaluated and certified AWS on January 13th, 2025. The HDS Certificate of Compliance demonstrating AWS compliance status is available on the Agence du Numérique en Santé (ANS) website and on AWS Artifact. AWS Artifact is a self-service portal for on-demand access to AWS compliance reports. Sign in to AWS Artifact in the AWS Management Console, or learn more at Getting Started with AWS Artifact.

For up-to-date information, see the AWS Compliance Programs page and choose HDS.

AWS strives to continuously meet your architectural and regulatory needs. If you have questions or feedback about HDS compliance, reach out to your AWS account team.

To learn more about our compliance and security programs, see AWS Compliance Programs. As always, we value your feedback and questions; reach out to the AWS Compliance team through the Contact Us page.

If you have feedback about this post, submit comments in the Comments section below.

Tea Jioshvili

Tea Jioshvili

Tea is a Security Assurance Manager at AWS, based in Berlin, Germany. She leads various third-party audit programs across Europe. She previously worked in security assurance and compliance, business continuity, and operational risk management in the financial industry for multiple years.

The people should own the town square (Mastodon Blog)

Post Syndicated from jzb original https://lwn.net/Articles/1005007/

The Mastodon project has announced
that founder Eugen Rochko will be transferring “key Mastodon
ecosystem and platform components (including name and copyrights,
among other assets)
” to a new non-profit organization:

Practically Mastodon will remain headquartered in and operate from
Europe primarily. We will continue day-to-day operations through the
Mastodon GmbH for-profit entity, which will become wholly owned by the
new European not-for-profit entity. The Mastodon GmbH entity
automatically became a for-profit as a result of its charitable status
being stripped
away in Germany
. The existing US-based non-profit entity, the
501(c)(3), will continue to function as a fundraising hub.

[…] We are in the process of a phased transition. First we are
establishing a new legal home for Mastodon and transferring ownership
and stewardship. We are taking the time to select the appropriate
jurisdiction and structure in Europe. Then we will determine which
other (subsidiary) legal structures are needed to support operations
and sustainability.

Rochko has, naturally, also posted
about the transition
on Mastodon.social.

[$] The slow death of TuxFamily

Post Syndicated from jzb original https://lwn.net/Articles/1004988/

TuxFamily is a
French free-software-hosting service that has been in operation since
1999. It is a non-profit that accepts “any project
released under a free license
“, whether that is a software license
or a free-content license, such as CC-BY-SA. It is also,
unfortunately, slowly dying due to hardware failures and lack of
interest. For example, the site’s download servers are currently
offline with no plan to restore them.

Juicebox recruits Amazon OpenSearch Service for improved talent search

Post Syndicated from Ishan Gupta original https://aws.amazon.com/blogs/big-data/juicebox-recruits-amazon-opensearch-service-for-improved-talent-search/

This post is cowritten by Ishan Gupta, Co-Founder and Chief Technology Officer, Juicebox.

Juicebox is an AI-powered talent sourcing search engine, using advanced natural language models to help recruiters identify the best candidates from a vast dataset of over 800 million profiles. At the core of this functionality is Amazon OpenSearch Service, which provides the backbone for Juicebox’s powerful search infrastructure, enabling a seamless combination of traditional full-text search methods with modern, cutting-edge semantic search capabilities.

In this post, we share how Juicebox uses OpenSearch Service for improved search.

Challenges in recruiting search

Recruiting search engines traditionally rely on simple Boolean or keyword-based searches. These methods aren’t effective in capturing the nuance and intent behind complex queries, often leading to large volumes of irrelevant results. Recruiters spend unnecessary time filtering through these results, a process that is both time-consuming and inefficient.

In addition, recruiting search engines often struggle to scale with large datasets, creating latency issues and performance bottlenecks as more data is indexed. At Juicebox, with a database growing to more than 1 billion documents and millions of profiles being searched per minute, we needed a solution that could not only handle massive-scale data ingestion and querying, but also support contextual understanding of complex queries.

Solution overview

The following diagram illustrates the solution architecture.

OpenSearch Service securely unlocks real-time search, monitoring, and analysis of business and operational data for use cases like application monitoring, log analytics, observability, and website search. You send search documents to OpenSearch Service and retrieve them with search queries that match text and vector embeddings for fast, relevant results.

At Juicebox, we solved five challenges with Amazon OpenSearch Service, which we discuss in the following sections.

Problem 1: High latency in candidate search

Initially, we faced significant delays in returning search results due to the scale of our dataset, especially for complex semantic queries that require deep contextual understanding. Other full-text search engines couldn’t meet our requirements for speed or relevance when it came to understanding recruiter intent behind each search.

Solution: BM25 for fast, accurate full-text search

The OpenSearch Service BM25 algorithm quickly proved invaluable by allowing Juicebox to optimize full-text search performance while maintaining accuracy. Through keyword relevance scoring, BM25 helps rank profiles based on the likelihood that they match the recruiter’s query. This optimization reduced our average query latency from around 700 milliseconds to 250 milliseconds, allowing recruiters to retrieve relevant profiles much faster than our previous search implementation.

With BM25, we observed a nearly threefold reduction in latency for keyword-based searches, improving the overall search experience for our users.

Problem 2: Matching intent, not just keywords

In recruiting, exact keyword matching can often lead to missing out on qualified candidates. A recruiter looking for “data scientists with NLP experience” might miss candidates with “machine learning” in their profiles, even though they have the right expertise.

Solution: k-NN-powered vector search for semantic understanding

To address this, Juicebox uses k-nearest neighbor (k-NN) vector search. Vector embeddings allow the system to understand the context behind recruiter queries and match candidates based on semantic meaning, not just keyword matches. We maintain a billion-scale vector search index that is capable of performing low-latency k-NN search, thanks to OpenSearch Service optimizations like product quantization capabilities. The neural search capability allowed us to build a Retrieval Augmented Generation (RAG) pipeline for embedding natural language queries before searching. OpenSearch Service allows us to optimize algorithm hyperparameters for Hidden Navigable Small Worlds (HNSW) like m, ef_search, and ef_construction. This enabled us to achieve our target latency, recall, and cost goals.

Semantic search, powered by k-NN, allowed us to surface 35% more relevant candidates compared to keyword-only searches for complex queries. The speed of these searches was still fast and accurate, with vectorized queries achieving a 0.9+ recall.

Problem 3: Difficulty in benchmarking machine learning models

There are several key performance indicators (KPIs) that measure the success of your search. When you use vector embeddings, you have a number of choices to make when selecting the model, fine-tuning the model, and choosing the hyperparameters to use. You need to benchmark your solution to make sure that you’re getting the right latency, cost, and especially accuracy. Benchmarking machine learning (ML) models for recall and performance is challenging due to the vast number of fast-evolving models available (such as MTEB leaderboard on Hugging Face). We faced difficulties in selecting and measuring models accurately while making sure we performed well across large-scale datasets.

Solution: Exact k-NN with scoring script in OpenSearch Service

Juicebox used exact k-NN with scoring script features to address these challenges. This feature allows for precise benchmarking by executing brute-force nearest neighbor searches and applying filters to a subset of vectors, making sure that recall metrics are accurate. Model testing was streamlined using the wide range of pre-trained models and ML connectors (integrated with Amazon Bedrock and Amazon SageMaker) provided by OpenSearch Service. The flexibility of applying filtering and custom scoring scripts helped us evaluate multiple models across high-dimensional datasets with confidence.

Juicebox was able to measure model performance with fine-grained control, achieving 0.9+ recall. The use of exact k-NN allowed Juicebox to benchmark faster and reliably, even on billion-scale data, providing the confidence needed for model selection.

Problem 4: Lack of data-driven insights

Recruiters need to not only find candidates, but also gain insights into broader talent industry trends. Analyzing hundreds of millions of profiles to identify trends in skills, geographies, and industries was computationally intensive. Most other search engines that support full-text search or k-NN search didn’t support aggregations.

Solution: Advanced aggregations with OpenSearch Service

The powerful aggregation features of OpenSearch Service allowed us to build Talent Insights, a feature that provides recruiters with actionable insights from aggregated data. By performing large-scale aggregations across millions of profiles, we identified key skills and hiring trends, and helped clients adjust their sourcing strategies.

Aggregation queries now run on over 100 million profiles and return results in under 800 milliseconds, allowing recruiters to generate insights instantly.

Problem 5: Streamlining data ingestion and indexing

Juicebox ingests data continuously from multiple sources across the web, reaching terabytes of new data per month. We needed a robust data pipeline to ingest, index, and query this data at scale without performance degradation.

Solution: Scalable data ingestion with Amazon OpenSearch Ingestion pipelines

Using Amazon OpenSearch Ingestion, we implemented scalable pipelines. This allowed us to efficiently process and index hundreds of millions of profiles every month without worrying about pipeline failures or system bottlenecks. We used AWS Glue to preprocess data from multiple sources, chunk it for optimal processing, and feed it into our indexing pipeline.

Conclusion

In this post, we shared how Juicebox uses OpenSearch Service for improved search. We can now index hundreds of millions of profiles per month, keeping our data fresh and up to date, while maintaining real-time availability for searches.


About the authors

Ishan Gupta is the Co-Founder and CTO of Juicebox, an AI-powered recruiting software startup backed by top Silicon Valley investors including Y Combinator, Nat Friedman, and Daniel Gross. He has built search products used by thousands of customers to recruit talent for their teams.

Jon Handler is the Director of Solutions Architecture for Search Services at Amazon Web Services, based in Palo Alto, CA. Jon works closely with OpenSearch and Amazon OpenSearch Service, providing help and guidance to a broad range of customers who have search and log analytics workloads for OpenSearch. Prior to joining AWS, Jon’s career as a software developer included four years of coding a large-scale, eCommerce search engine. Jon holds a Bachelor of the Arts from the University of Pennsylvania, and a Master of Science and a Ph. D. in Computer Science and Artificial Intelligence from Northwestern University.

[$] Modifying another process’s system calls

Post Syndicated from corbet original https://lwn.net/Articles/1004455/

The ptrace()
system call allows a suitably privileged process to modify another in a
large number of ways. Among other things, ptrace() can intercept
system calls and make changes to them, but such operations can be fiddly
and architecture-dependent. This patch series from
Dmitry Levin
seeks to improve that situation by adding a new
ptrace() operation to make changes to another process’s system
calls in an architecture-independent manner.

Disaster Recovery 101: Hot vs. Warm vs. Cold DR Sites

Post Syndicated from Kari Rivas original https://www.backblaze.com/blog/disaster-recovery-101-hot-vs-warm-vs-cold-dr-sites/

A decorative image showing a hot and a cold temperature gauge overlaying patterned images that show drives and data centers.

It goes without saying (but I will say it anyway) that having a disaster recovery (DR) site is essential to protecting business continuity (BC) in the face of disasters both big and small. However, even for large enterprises, building and maintaining a separate physical facility to store data copies can be cost prohibitive, and it may not make sense operationally. 

DR sites differ according to the availability of data for retrieval and by type of ownership (e.g., fully owned or colocated). In recent years, public cloud has also emerged as a viable DR “site”—meaning that backups, production data, and/or virtualized infrastructure can be effectively housed in the cloud. 

In this blog, I’ll examine the primary differences and pros and cons between various types of DR sites, and I’ll outline the most important criteria for deciding on the right DR setup for your business.

Proprietary ownership vs. colocation

If your business is able to fully invest in owning a DR site, the obvious upsides are greater control over security and infrastructure. But owning and operating your own site may still not be the most ideal option, given the staffing and expertise required. For many businesses, it doesn’t make sense to invest in owning and operating a data center when that’s not your area of expertise. 

That’s why many businesses opt for colocation. It can be a great option for adhering to your DR strategy and your expense limits. However, you must be careful to thoroughly vet the location and provider. Here are a few important points to consider:

  • Performance: You should understand what kind of equipment is used at the DR site, as well as what kind of durability and availability you can expect. Ensure that the available infrastructure can meet your required recovery time objectives (RTO) and recovery point objectives (RPO)—that is, the maximum amount of downtime your business can withstand and the maximum amount of data your organization can tolerate losing, respectively.
  • Security: A trustworthy provider should be staffed 24/7/365. Learn how the data center is protected. Are there cameras? Biometric security? How does the data center protect against things like fire and power loss?
  • Proximity: A data center that’s down the street from your primary location will offer no protection in the case of a regional disaster like wildfire or tornado—events that are unfortunately becoming more and more common. Ideally, you should choose a location that is far from your production facility. This is where the public cloud naturally fits in—but more on that in a bit.
  • Scalability: Gauge how much data you currently need to store as well as how much you expect to grow in the near future. Find out how much capacity the DR site can support and choose a site that can accommodate your planned growth.
  • Costs: Get a complete view of your total cost of ownership. This not only includes one time costs to get started and ongoing monthly or yearly expenses, but also potential costs for things like additional support or any capacity you may need to add in the middle of a contract period.
  • Compliance: Consider what compliance requirements your business must support. Some data centers are SOC 2 compliant; some are not. It’s also important to check your cyber insurance policy requirements. Many policies may require that you keep data backups in a facility that is far from your own. This is exactly the requirement that brought telco AcenTek to Backblaze.

Meeting cyber insurance requirements with the cloud

In order to satisfy cyber insurance policy requirements, AcenTek’s backups needed to be off-site and geographically distant from their own data centers. Backblaze offered a critical feature—immutability and certification as a Veeam Ready Object partner—as well as geographic distance from AcenTek’s own data centers to meet the requirements and protect AcenTek’s business.

Read the Full Story ➔ 

Hot, warm, and cold DR sites: Choosing the right strategy

Recovery sites are often referred to by temperature (hot, warm, cold) to describe the speed and importance of applications and data in those protected sites. The ideal DR site temperature depends on your organization’s budget, risk tolerance, and RTOs. Businesses with critical systems requiring near-instantaneous recovery might opt for a hot site. Others might find a warm site or even a cold site a more cost-effective option for less time-sensitive systems.

Hot, warm, and cold: Choosing the right DR site temperature

Hot site Warm site Cold site
Description A fully functional replica of your primary production resources, constantly maintained and ready for immediate failover in the cloud or to a secondary on-premises site. A pre-configured cloud recovery site or hybrid recovery with hardware and software infrastructure. Requires some manual intervention (e.g., software installation) before becoming operational. A basic physical facility with essential infrastructure (power, cooling, and network connectivity) requiring significant configuration and installation before use. May also include cold cloud storage.
Pros Fastest recovery times due to the site’s constant readiness. A balance between cost and recovery time. Faster than cold sites, but slower than hot sites. Most cost-effective option, requiring minimal ongoing maintenance.
Cons This is the most expensive option due to the need for complete infrastructure replication. Still requires some manual setup, potentially delaying recovery time. Longest recovery times due to the extensive configuration and installation needed. Or, in the case of cold cloud storage—the time required to retrieve your data.
Example RTO goal times RTO <15 minutes RTO <24 hours RTO >24 hours

Public cloud as virtual DR site

Traditionally, DR for large enterprises would involve building a physical site to support RTO objectives. It’s important to note that building or buying a dedicated DR site might not be the most cost-effective option for all backups. Instead, cloud storage offers a compelling solution specifically for backups, even if you have your own physical DR site.

Why Backblaze works for DR

Cloud storage from a specialized provider like Backblaze is generally more affordable and scalable than on-premises storage solutions or off-site DR facilities, making it a great fit for this purpose. Backblaze offers always hot storage with 3x free egress, meaning data can be immediately recovered when needed without surprise egress bills. In this way, Backblaze B2 Cloud Storage constitutes a virtualized hot DR site.

Learn More ➔ 

Cold cloud storage considerations

While some consider cold cloud storage to be the most cost-effective solution, the cost savings of cold storage are often entirely negated by its long retrieval time and egress charges—so much so that it no longer becomes a viable disaster recovery option.

Evaluating cloud storage providers

In a way, you can consider the public cloud very similarly to a colocated DR site. All the same questions apply when choosing between cloud storage providers (CSPs):

  • Performance: What durability, reliability, and availability does the CSP offer? What kind of throughput do you get on a proof of concept?
  • Security: Does the CSP staff their data centers 24/7/365? What security processes and procedures are in place?
  • Proximity: Where are the CSP’s data centers located? Choose one that offers good geographic separation from your production facility while ensuring you can still meet your RTO with latency considered.
  • Scalability: Cloud storage naturally offers infinite scalability, but it’s vitally important to ask your CSP how they handle things like capacity overages or the need to purchase additional capacity. Some CSPs will charge you excessive fees when you go over capacity, or they may require you to switch to a different pricing model if you need additional storage space in the middle of a contract period.
  • Costs: Again, you need a complete view of your TCO. Watch out for things like minimum retention periods, egress charges, and other hidden fees.
  • Compliance: Be careful of CSPs that claim they’re SOC 2 compliant. Sometimes the CSP operates in SOC 2 compliant data centers but the company is not SOC 2 compliant itself. That difference may be meaningful to your company or your own compliance requirements.

Ultimately, you must carefully balance business requirements for RTO and RPO with DR investment costs. Businesses located in likely disaster areas like tornado alley, earthquake-prone zones, or coastal areas are well served by the additional investment in DR infrastructure. But even if your company has its own DR site, public cloud can be a beneficial supplement to your own DR infrastructure.

The post Disaster Recovery 101: Hot vs. Warm vs. Cold DR Sites appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

The collective thoughts of the interwebz