Four Compliance Frameworks, One Security Team. How Universities Can Stop Drowning in Regulatory Risk

Post Syndicated from Rapid7 original https://www.rapid7.com/blog/post/it-compliance-frameworks-for-universities-drowning-in-regulatory-risk

Most industries manage one major compliance framework. Universities might manage four simultaneously, each bringing with it unique requirements, enforcement mechanisms, and consequences for failure. Here’s what that actually looks like in practice.

In Part 1 of this series, we laid out the scale of the threat facing higher education: 4,388 cyberattacks per organization per week, a 24% year-over-year increase, and the fundamental architectural flaw of defending each campus independently. If the threat picture alone wasn’t enough to demand action, there’s a second crisis unfolding in parallel that is, if anything, more immediately consequential.

The regulatory environment for higher education has quietly become one of the most complex in any sector. Universities don’t just face the legal and reputational fallout of a data breach. They face simultaneous obligations under four distinct federal frameworks, each with its own definition of adequate security, its own reporting timelines, and its own set of penalties for non-compliance.

Managing those four frameworks across a single campus is hard. Managing them across a multi-campus system where each school operates its own IT environment, with its own tools, its own staff, and its own data governance practices, is a compounding nightmare that most institutions haven’t fully reckoned with yet.

Let’s walk through each framework from the ground-level.

FERPA: The 24-hour clock nobody talks about

The Family Educational Rights and Privacy Act (FERPA) has governed the privacy of student education records since 1974. Most university administrators are broadly familiar with it, whereby students have the right to access their own records, institutions have an obligation to protect those records from unauthorized disclosure, and violations can result in loss of federal funding.

Now, what has become far more operationally consequential in the age of sophisticated cyberattacks is the breach notification requirement for financial aid data.

When a breach compromises student financial aid information, institutions must notify the Department of Education’s Federal Student Aid office within 24 hours of discovering the incident. Not 72 hours, which is the standard under many commercial data breach frameworks. Not “as soon as practicable,” but twenty-four hours.

Think about what that timeline actually demands. A ransomware attack is discovered at 9 PM on a Friday. By 9 PM Saturday, your institution needs to have identified that student financial aid data was involved, determined the scope of the breach, and filed formal notification with federal regulators, while simultaneously managing the technical response, communicating with affected students and faculty, engaging legal counsel, and trying to figure out what else the attackers may have accessed.

That 24-hour window is not achievable through manual investigation. It requires automated detection capabilities that can identify the scope of a breach in real time, data classification that knows where financial aid information lives across your environment, and incident response processes that are tested, documented, and ready to execute under pressure at any hour of any day.

For most universities, especially those operating with fragmented, campus-by-campus security tooling, this capability simply doesn’t exist at the required level. The 24-hour clock starts ticking the moment you discover the breach. But in a complex, multi-campus environment, “discovery” often comes well after the actual compromise, and characterizing the scope of what was accessed can take days or weeks without unified visibility.

Repeated FERPA violations can result in loss of eligibility for federal student aid programs, a consequence that would be existential for most institutions.

GLBA: When a university becomes a financial institution

The Gramm-Leach-Bliley Act’s Safeguards Rule is probably the least intuitive compliance obligation for higher education administrators who don’t think of their institutions as financial entities. But universities have been clearly defined as financial institutions under GLBA since 2002, because they originate and service student loans and manage financial aid disbursements.

The Federal Trade Commission’s updated Safeguards Rule, which took full effect in 2023, significantly expanded the security requirements for covered institutions. Universities must now maintain a comprehensive written information security program that includes risk assessments, access controls, encryption, multi-factor authentication, incident response planning, and vendor oversight, all aligned to NIST 800-171.

More specifically, universities that handle Federal Tax Information (i.e. virtually every institution that processes FAFSA data) must treat that information as Controlled Unclassified Information. The CUI designation comes with its own set of handling requirements, access controls, and audit obligations that most institutions’ current security programs weren’t designed to address.

The incident reporting requirement under GLBA is particularly demanding. If a security event affects 500 or more consumers, institutions must provide notification to federal law enforcement immediately upon discovering the breach. In practice, regulators have interpreted “immediately” to mean within hours, not days. The operational requirement is essentially identical to FERPA’s 24-hour clock: you need to know what happened, who was affected, and what data was compromised before most human-driven investigation processes could possibly complete.

For multi-campus university systems, GLBA creates an additional structural challenge: financial aid data doesn’t necessarily stay within campus boundaries. Students who transfer between campuses within the same system carry their financial aid history with them. System-level financial aid administration often centralizes data from all campuses into shared databases. A breach that starts at one campus may quickly implicate financial aid data across the entire system. Moreover, the reporting obligation doesn’t scale by campus. If your system’s data is compromised, the institution as a whole is responsible for the response.

HIPAA: The healthcare dimension universities underestimate

The Health Insurance Portability and Accountability Act applies wherever protected health information is created, received, transmitted, or maintained. For universities, that means student health centers, counseling services, university hospitals, and any research program that involves human subjects data.

The size of this compliance surface is frequently underestimated. A mid-size university with a student health clinic, a counseling center, a physical therapy program, and a research lab conducting clinical trials is handling significant volumes of protected health information, often spanning across IT systems that were procured and managed by clinical departments independently of the central IT organization.

Under HIPAA, breaches affecting 500 or more individuals must be reported to the Department of Health and Human Services within 60 days of discovery, and affected individuals must be notified within the same timeframe. Breaches affecting 500 or more individuals in a single state also trigger media notification requirements. For institutions operating across multiple states, the geographic complexity multiplies quickly.

The HIPAA enforcement environment has become significantly more aggressive in recent years. The HHS Office for Civil Rights has levied multi-million dollar penalties against healthcare organizations with security programs that would be considered industry-standard in other sectors. Universities that have historically operated their health services with a degree of IT independence from the main campus security program are increasingly exposed.

The intersection of HIPAA with the multi-campus challenge is particularly acute. When a student health system shares infrastructure with academic IT, a breach that starts in the academic environment can propagate to health records, and the reporting obligations that apply to health data are more demanding than those for most other types of student information. Without unified visibility across all the environments where PHI might reside, institutions can’t even reliably determine whether a given incident triggers HIPAA notification requirements.

CMMC: The research funding stakes are getting higher

The Cybersecurity Maturity Model Certification framework was developed by the Department of Defense to ensure that contractors and subcontractors handling Controlled Unclassified Information meet a consistent baseline of cybersecurity practices. For most of its history, CMMC’s relevance to higher education was limited to a relatively small number of research universities with significant DoD contracts.

That’s changing. As the federal government has increased the scope and value of research contracts that involve sensitive national security applications — advanced materials, artificial intelligence, quantum computing, biotechnology — the number of universities with CMMC obligations has grown substantially. And the consequences of non-compliance are not administrative fines. They’re loss of contract eligibility. For research universities where federal funding constitutes a significant portion of total revenue, that exposure is existential.

CMMC Level 2 compliance requires demonstrating implementation of 110 security practices drawn from NIST 800-171, covering everything from access control and incident response to system and communications protection and risk assessment. At higher levels, institutions must undergo third-party assessment by a certified organization; there’s no self-certification option.

The practical challenge for universities is that research computing environments are often structurally separate from the main campus IT organization. Research labs build their own systems. Principal investigators make their own technology decisions. The research network may have evolved organically over decades without the kind of deliberate security architecture that CMMC requires. Bringing those environments into compliance while preserving the operational flexibility that researchers require is a genuinely difficult operational challenge.

The compounding reality: Four frameworks at once

The challenge isn’t just that each of these frameworks is demanding in its own right. It’s that they apply simultaneously, to the same institution, with overlapping (and sometimes conflicting) requirements and timelines.

A data breach at a large research university with a hospital and a student health center can simultaneously trigger FERPA notification obligations (24-hour window for financial aid data), GLBA notification requirements (immediate notification if 500+ consumers affected), HIPAA breach reporting (60 days, plus potential media notification), and CMMC incident reporting (if the affected systems touched CUI). Each notification goes to a different federal agency. Each has its own documentation requirements. Each creates its own legal exposure if the response is delayed, incomplete, or inaccurate.

Managing this in the aftermath of an active breach — while simultaneously running the technical response, communicating with campus leadership, engaging legal counsel, and trying to prevent further damage — is genuinely overwhelming. And it’s made dramatically more difficult when the security team doesn’t have unified visibility across the environments where all four categories of regulated data might reside.

This is the core operational argument for consolidated security in higher education. Not just the threat landscape. Not just the operational efficiency of managing fewer tools. The compliance exposure created by fragmented, campus-by-campus security program is a material risk that university boards and general counsels are only beginning to fully understand.

What compliance-ready security actually requires

Meeting these four frameworks simultaneously, across a multi-campus environment, with the speed that their reporting requirements demand, requires security capabilities that most university systems don’t currently have at the required level:

Automated detection that operates at machine speed. You cannot investigate your way to a 24-hour notification window. You need detection capabilities that identify the nature and scope of a breach in real time; not in the hours or days that manual investigation requires.

Unified data classification across all campuses. You cannot know whether a breach triggers FERPA, GLBA, HIPAA, or CMMC notification requirements unless you know where each category of regulated data lives, across every campus, every department, every research lab, and every shared service in the system.

Centralized compliance reporting that spans campus boundaries. Each campus maintaining its own compliance evidence, in its own format, with its own audit trails, makes system-level compliance reporting a manual, error-prone, and enormously time-consuming exercise. A breach that crosses campus boundaries requires a consolidated view of what happened, when, and to whose data.

Incident response processes that can execute at the required speed. The 24-hour clock doesn’t care that your legal team doesn’t work weekends. Pre-defined, pre-approved response playbooks that can be activated immediately are the only way to reliably meet notification deadlines that leave no room for deliberation.

The good news is that a security platform built for multi-campus university environments can address all of these requirements. And not as separate point solutions, but as integrated capabilities that support each other. In Part 3 of this series, we’ll look at exactly how that works and what it means for university security programs that are ready to move beyond the fragmented, campus-by-campus model.

Coming up in Part 3: The architecture, the open source intelligence advantage, the real-world outcomes, and why consolidated security isn’t just a better defense, but a smarter investment.

Rapid7 helps more than 11,000 organizations worldwide take command of their security. Learn more at rapid7.com/sled.

Развитието на маносферата и как избягах от нея

Post Syndicated from Димитри Захов original https://www.toest.bg/razvitieto-na-manosferata-i-kak-izbyagah-ot-neya/

Развитието на маносферата и как избягах от нея

Винаги ще помня 2022-ра като годината, когато за кратко станах част от пространството в интернет, което днес наричаме „маносферата“. Това беше годината, когато послания и идеологии, развиващи се до онзи момент в нишови форуми като 4Chan, достигнаха до мейнстрийма. 

Бях в осми клас.

Пандемията създаде особено благоприятна среда за съдържание, обещаващо на младите мъже обяснение на собствените им проблеми, както и начин да ги решат. Самотата и социалната изолация станаха част от живота на много млади хора тогава. Появи се терминът „епидемия на мъжката самота“. Според проучване на Western Oregon University шестима от десет мъже под 30 години не са в романтична връзка, а над половината от всички изследвани мъже са съгласни с твърдението „Никой не ме познава добре“. Локдаунът не създаде, но със сигурност влоши тези проблеми.

Маносферата продаваше „решението“ им.

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

Засмукването в маносферата започваше с нещо по-привлекателно – с идеята, че можеш да станеш по-силен, по-богат, по-уверен и по-успешен и така да се спасиш от самотата и от сегашния си живот, който не харесваш.

Червеното хапче

Двама от най-известните герои от този период бяха братята Тейт. Тогава те станаха популярни с две свои дейности – подкаст, в който споделяха изкривените си представи за мъжество (наред с други теми), и курс, наречен Hustler’s University (впоследствие прераснал в The Real World).

Развитието на маносферата и как избягах от нея
Карикатура на Андрю Тейт. Източник

Курсът беше ключът към възхода им. Потребителите получаваха достъп до сървър в Discord с различни възможности за правене на пари онлайн, сред които дропшипинг (онлайн продажби без физически инвентар от продукти), търговия с криптовалути и affiliate marketing… за самия курс. Схемата беше следната: правиш си фен профил на Тейт в Instagram, TikTok или YouTube, разпространяваш неговите мисли и печелиш комисиона от всеки потребител, записал се чрез твоя линк.

(Впрочем Костадин Костадинов наскоро направи нещо подобно – конкурс за рекламно видео от фенове с парична награда…)

Хиляди профили започнаха да разпространяват едно и също съдържание.

Самите братя се хвалят с факта, че сред потребителите в курса е имало и 13-годишни. Чрез фен профили на деца, надяващи се някой да цъкне на линка в bio-то им и това да им донесе 10 долара, посланията на Андрю Тейт и брат му Тристан стигнаха до екраните на всички момчета около мен. 

Някои от известните им цитати бяха чисто мотивационни. Двамата изглеждаха като успели мъже, които искат да обяснят как са постигнали успеха си. Показваха скъпи коли, говореха за дисциплина, пари и физическа форма. Част от казаното от тях дори можеше да звучи напълно нормално, ако се извади от контекста. Например Андрю Тейт неколкократно критикуваше измамите с „шиткойн“ криптовалути и NFT. Няколко години по-късно направи своя криптовалута.

Братята представяха на зрителите си скъпите си коли и високия си стандарт на живот. Но измежду тези послания прокарваха и женомразството, с което ги познаваме:

Жените не трябва да гласуват, защото не се интересуват от въпроси извън това как се ЧУВСТВАТ…

Виждали ли сте някога жена да се опитва да направи нещо компетентно?

Голяма част от другите инфлуенсъри в маносферата имаха подобна система – привличат зрители с нормални неща и след като изградят доверие, изразяват и по-екстремните си мнения.

Такъв беше и един от любимите ми създатели на съдържание тогава – Hamza Ahmed.

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

Развитието на маносферата и как избягах от нея
Карикатура на Хамза. Източник

Все още мисля, че в клиповете си даваше някои полезни съвети: да поддържаш по-добра хигиена, да се храниш здравословно и да спазваш режим. Бях част от неговия (безплатен) сървър в Discord – и честно казано, не се сещам за нищо негативно, което да споделя относно преживяванията ми там. Сървърът беше общност от много хора, които искат да усъвършенстват себе си. Споделяхме целите си за новата година, получавах добри съвети за фитнеса и се вдъхновявах от нещата, които постигат мои връстници.

Но за самия Хамза – от историите, които разказва, и от форматите, където говори без сценарий – започнах да придобивам усещането, че той е просто един изключително несигурен човек, който е получил някакво женско внимание, след като е започнал да тренира, и този факт стои в основата на целия му характер. Във видеата си представяше перфектния мъж с име Адонис (въведен от него образ, който прилича на Хамза повече, отколкото на зрителя) и го сравняваше с обикновения човек – своя потребител. Говореше за трансформацията си от героя Джефри, слаб мъж, който води заседнал начин на живот, изпълнен с пороци, към нещо близко до съответния Адонис. Хамза, разбира се, също продаваше курс/менторска програма/нещо си с името „Библиотеката на Адонис”.

Тази част на маносферата се идентифицира с червеното хапче (да, терминът е от „Матрицата“),

което означава да избереш суровата истина пред красивата илюзия. Посланията отговаряха на притесненията на много млади момчета, голяма част от които впоследствие пораснаха, помнейки ги.

Аз се върнах към нормалния си дневен ред още през 2023 г., когато осъзнах колко жалки бяха повечето инфлуенсъри, които гледах тогава. Те просто намираха несигурни момчета и им продаваха нереалистични желания по отношение на финансите и тялото, които уж можеш да постигнеш, ако се присъединиш към платени общности. При това тези инфлуенсъри не са нито бизнес експерти, нито треньори.

И не само аз стигнах до този извод. През втората половина на 2026 г. Хамза е доста по-малко релевантен, гледаемостта на видеата му спада значително, а братята Тейт са в затвора. Другите създатели от маносферата крещят все по-шумно своите послания на все по-малка, но по-радикална група.

Червената шапка

През 2024 г. в САЩ видяхме как един кандидат-президент легитимира маносферата и се опита да се пребори за нейните гласове. Доналд Тръмп и сектата MAGA искаха да спечелят доверието на младите мъже, които имат виждания, сходни с техните – anti-woke, „антисистемни“ и т.н.

Тръмп взе участие в подкасти, стриймове и други видове колаборация със създатели на съдържание от маносферата, сред които бяха близките до Тейт Ейдън Рос и NELK Boys, както и известни подкастъри с предимно мъжка дясна аудитория (но не задължително свързани с маносферата), като Джо Роган и Тио Вон. MAGA проникна и в онлайн общностите, където обикновено преобладават мъжете – за бойни спортове, видеоигри… Гласът на движението стигна до младите мъже, без да се налага те да се интересуват от политика.

Подкрепата за Тръмп действително отбеляза съществен ръст при младите мъже спрямо изборите през 2020 г. Но това за мен беше последният изстрел в сърцето – червеното хапче се политизира, много от фигурите от общностите на маносферата станаха просто говорители на MAGA, а друга част се продадоха на спонсори и промениха съдържанието си.

Черното хапче

Докато „червеното хапче“ ти казва, че за да си успешен с жените, трябва да си такъв и в живота, „черното хапче“ (blackpill, съкратено – BP) твърди, че просто трябва да имаш добър външен вид и че за хората, които изглеждат добре, всяка врата е отворена. И въпреки че redpill вълната умира, тази продължава да расте (по мои наблюдения).

Докато redpill беше разрушителен предимно за околните, looksmaxxing-ът (стремежът да изградиш по-добър външен вид като основен приоритет) е опасен за човека, който е част от съответните общности:

Развитието на маносферата и как избягах от нея
Пример за саморазрушителността на looksmaxxing-а. Източник: spodeli.net

Брейдън Питърс с прякор Clavicular е едно от знаковите лица на тази субкултура. Предполагам, че ако питате случаен осмокласник, ще знае кой е. Изглежда добре, но на каква цена?

Историята му започва от тийнейджърска възраст, когато е активен потребител във форума looksmax.org. Там споделя своите премеждия в опит да се „извиси“ от low tier normie (малко под средностатистически изглеждащ мъж) до Chad (използван във 4Chan термин за привлекателен мъж) в PSL скалата („обективно“ измерване на външния вид от 1 до 10, съответно от „подчовек“ до „Адам“ или „Ева“). Още от малък приема всякакви видове медикаменти, пептиди и добавки, сред които дори метамфетамини. Прогресът му във фитнеса се дължи колкото на тренировките, толкова и на анаболните стероиди, за които не крие, че злоупотребява с тях oт години.

Посланието на червеното хапче беше, че трябва да вложиш усилия и да си амбициозен, ако искаш да успееш. Представителите на неговата субкултура бяха преди всичко мотиватори – това им беше кукичката.

Но посланието нa Clavicular е, че за всичко има лесен начин –

не само той, а цялата общност активно промотира козметични операции на лицето и челюстта (наричат го hardmaxxing), макар да са наясно, че аудиторията им е предимно непълнолетна. Препоръчват и различни видове добавки, сред които пептиди, неразрешени за употреба от хора. Субкултурата им се подхранва изцяло от несигурността на тийнейджърите за външния им вид. Разбира се, продават се и курсове. Членство в Clavicular's Clan струва точно 39 щатски долара на месец (намалено от 49!).

И това пространство абсолютно е част от маносферата – изглежда, че идеалът в живота на Питърс е женското внимание – на партита, по много. Той също разглежда жените като някакъв предмет за купуване и продаване спрямо sexual market value на мъжа. Освен това, разбира се, е заявен антифеминист.

Неговата култура и вярвания не са изолирани само на Запад – наскоро ми попадна тази снимка на флаер за BP club в българско училище:

Развитието на маносферата и как избягах от нея
Снимка на флаера, публикувана в TikTok от ученик от 73. СОУ в София

Предполагам, читателю, че флаерът е направен с комедийна цел, но е достатъчно доказателство, че посланията на тази общност са популярни сред българските ученици.

В моите гимназиални години looksmaxxing-ът също съществуваше, но не беше отишъл толкова далеч. Съветите, които по-ранните гурута даваха, бяха една идея по-медицински издържани от bonesmashing-а (трошене на лицеви кости с тъпи предмети с цел разкрасяване) на Clavicular. И нихилизмът (посланието, че или си надарен, или се боцкай с игли, или се самоубий), който същинският BP изповядва, го нямаше – просто се даваха съвети как да изглеждаш по-добре, с по-малко идеология и с повече реклами на козметика. 

Винаги е имало луди гурута в интернет.

Но ако има нещо, което ме притеснява сега, това е, че blackpill културата окуражава младите момчета да разглеждат себе си като продукт или бизнес, който трябва да бъде оптимизиран. Езикът на blackpill е като от учебник по икономика: sexual market value („сексуална пазарна стойност“), ROI (return of investment – „възвръщане на инвестициите“, когато се говори за методи, като hardmaxing-ът, разбира се, е с най-добър резултат). Последователите на тази субкултура мерят връстниците в числа и потенциал, като постоянно гонят някакви „обективни“ показатели в нещо толкова субективно като атрактивността.

Третирайки себе си и потенциалните си партньори като стоки в търговски център, още от малки си създават деструктивна гледна точка за света. 

Който привикне да оценява себе си в числа, оценява и всичко останало по този начин. Един разговор с приятели вече е „губене на време“, ако не води до нищо измеримо. Приятелството изглежда като лоша сделка, а момичето, което ти харесва – като награда, която или заслужаваш, или не. 

Това е най-големият парадокс на цялата тази култура:

момчетата и младите мъже стигат до нея заради самотата и потребността си от близост, но инструментът, който получават, е точно този, който прави близостта невъзможна.

Аз излязох от маносферата не защото открих по-добра система, а защото започнах да правя неща, които не могат да се измерят. Тренирам, защото ми харесва. Говоря с приятели, без да очаквам да получа нещо от разговора. Губя време и не наричам това инвестиция в wellbeing. Всяка минута, прекарана в пътуване, хоби или слушане на музика е по-полезна от тази, в която стоиш пред огледалото и гледаш рецесиралата си мандибула. Или подготвяш дропшипинг сайт за китайски хранителни добавки.

Building an evidence-grounded agentic security operations harness on Cloudflare

Post Syndicated from Deanna Tran original https://blog.cloudflare.com/agentic-security-operations/

Security alerts rarely arrive one at a time. A single alert can cause a spike across the environment, requiring a human analyst to decide which alerts are related and what they mean. When multiple arrive at the same time, it can quickly overwhelm even a seasoned security analyst. Enter the alert paradox. Now, our built-in, multi-AI-agent security operations harness can handle more of this work at Cloudflare scale.

Our Cloudflare Managed Defense AI agent harness speeds up the process of gathering data, connecting and aggregating detections, and accounting for missing sources while new alerts continue to arrive. To further analyze context, we make use of the OpenAI Daybreak Defense Network and our partnership with Anthropic. Cloudflare uses approved OpenAI Daybreak and Anthropic models, including GPT-5.6 Cyber and Mythos, for deeper model-backed analysis. Initial analysis and scoring is done with Clef, Cloudflare’s open-source decision model.

Collecting evidence to understand what each alert means requires a lot of time. Even in a highly sophisticated Security Information and Event Management (SIEM), too much is still left for a human to review. Human analysts must gather data, connect and aggregate detections, and account for missing sources while new alerts continue to arrive.

Think about every time a human analyst reviews an alert: "Which should we silence? Which action should we take? Which alert should we ignore? Which should we resolve as false positives? Which should we resolve as true positives? Which should trigger our incident team?" We address this predicament with our AI agent strategy. Our approach reduces all of those questions and gives Managed Defense Analysts a quick and consolidated view, directly providing insight into related alerts, admitted evidence, visible gaps, and recommended next steps. The result: cutting back on the time needed to analyze, and creating a hyper focus on actually getting security alerts resolved and mitigations deployed.

Why a single agent fails

Our first prototype showed the limits of one general-purpose agent. We provided the AI agent the whole investigation. It produced useful analysis, but it also hallucinated claims the evidence did not support. Telemetry, detector descriptions, policies, and threat intelligence were flattened into one prompt, which caused their distinct roles to merge together.

We saw three recurring problems with our first single-shot AI agent harness:

  • Context became authority. A detection is a hypothesis, not proof that an exploit succeeded or an attack occurred. A broad AI agent can blur that distinction.
  • Scope drifted. An AI agent can query the wrong account, time range, or source. You can’t rely on a language model prompt to be a boundary.
  • Failure disappeared. If a lookup times out, the result may not distinguish "not checked" from "checked and not found."

To address these challenges we moved evidence collection and scope enforcement into application code, before model analysis begins.

Recon first, inference second

It's tempting to put an AI agent at every step. The front half of our harness has none.

Before we even call inference, deterministic code runs a fixed set of reconnaissance workflows with versioned API calls. It collects the customer's identity, detection history, traffic baseline, enforcement outcome, and network observations. Each piece of data is stored with its source, version, and timestamp.

Cloudflare sees both the request and the action applied to it. That lets the investigation connect the behavior that triggered an alert with both the control that fired and its outcome.

The fixed recon snapshot also makes evaluation reproducible. If AI agents fetch their own data, two runs may disagree because their inputs changed. Here, the same snapshot can be replayed, so differences between specialist AI agents’ findings come from interpretation rather than retrieval.

Filter noise early

Most alerts are not incidents. The same rule often fires repeatedly on a known traffic pattern, and paging Managed Defense Analysts every time makes it easier to miss a real security incident.

We needed a lightweight triage model to compare each alert with its reconnaissance data: Has this event been detected for the customer before? What did Managed Defense Analysts decide previously? Does the traffic look consistent with normal human behavior? Alerts scored with a high likelihood to be false positives skip analysis by the specialist AI agents.

Clef, running on Workers AI, was the perfect fit for this type of fast agentic reasoning. 

Known high-volume noise is deterministically classified as passive when it arrives. It remains available as context but does not enter the active queue.

Specialist AI agents handle the investigation

For alerts that need deeper review, a coordinator AI agent runs four specialist AI agents in parallel:

  • Traffic analysis reviews request behavior, historical changes, and enforcement.
  • Customer context reviews earlier alerts, dispositions, and Managed Defense Analysts’ decisions.
  • Global telemetry compares the activity with privacy-preserving Internet-wide signals.
  • Threat intelligence checks indicators already admitted to the alert or case.

A synthesis AI agent combines their typed findings into one advisory; it can’t fetch new evidence or choose a classification outside the approved vocabulary. Keeping each task narrow makes unsupported claims easier to catch, and recommendations easier to audit.

Global context without customer data

A security tool knows what happened inside the environment it is deployed in, but little about the world beyond it. Cloudflare compares an alert with patterns seen across its global network.

For example, an IP may be targeting one site, scanning thousands of sites, or appearing for the first time. Those patterns carry different weights. To preserve customer privacy, the global telemetry specialist works only with aggregates; it never receives another customer's individual records or identity.

This view combines features from Cloudflare's CDN, WAF, DDoS, Turnstile, Rate Limiting, and Cloudforce One threat intelligence. The synthesis AI agent weighs both global reputation and customer history. This ensures a globally common pattern can still be used on a per-customer basis, but does not automatically imply a widespread campaign for all customers.

History is evidence

Every evaluation is conscious of what came before it: the alert, the pattern, and which customer. The recon dossier records the alert's own track record including how many times this service alert has fired, how many of those were dispositioned as false positives, and what the Managed Defense Analyst concluded. An attack pattern that has been benign every time your Managed Defense Analysts have seen it is a very different object from the first sighting of something new, and the specialist AI agents are told which one they are looking at. Approved background context is retrieved from previous alerts and cases, so yesterday's conclusions are carried into today's decision, instead of being rebuilt from scratch.

Our system aggregates related alerts into a consolidated case. In each case, we store evidence, findings, and recommendations. Our system deterministically joins and correlates this data, but we leave it to a Managed Defense Analyst to confirm the actual scope. Over time, a case can connect network, application, and Zero Trust evidence together, while tracking the source of the evidence for additional context and reference purposes.

From evidence to decision

Before analysis, the system creates a versioned evidence package with the subject, scope, time anchor, admitted evidence, policy versions, sources, and coverage gaps. Specialists must cite items in that package. Application code checks that every citation exists, belongs to the investigation, and supports the attached claim. Invalid findings are corrected or recorded as limitations.

We lean on Clef a second time to score our evidence. Is the collected evidence enough for a decision? Does any of our collected evidence contradict? Based on this evidence, Clef picks from a deterministically reduced list of attack classifications and dispositions.

Cloudflare's developer platform runs this process. Application code on Workers admits evidence and validates results; Workflows coordinates each stage and saves completed work before the next begins, so a failed stage reuses evidence and findings that already passed validation instead of starting over. D1 keeps investigation and advisory state, R2 holds bounded context and evidence artifacts. Case-chat state persists in Durable Objects, uses Flue, and is enriched with AI Search.

Finally, an LLM-powered agent produces an advisory report using terms that Managed Defense Analysts already work with: affected surface, enforcement outcome, relevant controls, and next step. Managed Defense Analysts can inspect evidence, investigate further, revise the recommendation, or group alerts into a case. Application code fixes the customer scope before any model sees results, and gives each specialist only the evidence it needs. The model never receives authority to cross tenant boundaries or act for the Managed Defense Analysts.

Handling incomplete evidence

At network scale, a source will sometimes fail. A comparison may time out, metadata may be missing, or a threat intelligence lookup may return no match. The system keeps evidence already collected and records the gap.

The advisory distinguishes three states:

  • Not checked
  • Checked, with no matching result
  • Checked, with evidence supporting absence

If global telemetry is unavailable, the system can describe what is unusual for the customer but cannot say whether the pattern is widespread. When the evidence is insufficient, it makes no classification or disposition recommendation.

Remediation

A useful recommendation should lead to a solution, rather than a ticket. The advisory might suggest a rate limiting rule for an abusive path, a WAF custom rule for a signature, or a DDoS protection change. For fully managed customers, Managed Defense Analysts can apply the suggested rules; other customers will receive their recommendations in the dashboard and through their chosen alert path.

In the end, the Managed Defense Analyst remains responsible for the decision and any mitigation. Each alert and case includes the evidence behind the AI agent’s recommendation, which empowers the Managed Defense Analyst to reach a conclusion by accepting or updating the AI agent’s advice.

What comes next

Managed Defense Analysts remain responsible for judgment. The AI agent harness handles more of the repetitive work: assembling investigations, connecting related events, and showing the evidence behind each recommendation. Over the next few quarters, we plan to add a Custom Managed level with more flexibility for each organization.

We also plan to explore continuous AI agents that monitor Cloudflare traffic and surface patterns that fixed rules and thresholds may miss.

The early beta is available in Cloudflare Managed Defense for eligible application-security alerts and cases. If you already use Cloudflare WAF, DDoS protection, Magic Transit, or another supported product, talk to your enterprise account team about adding Managed Defense.

Part 1 – Cybersecurity journeys: I didn’t plan this

Post Syndicated from Shannon Brazil original https://aws.amazon.com/blogs/security/part-1-cybersecurity-journeys-i-didnt-plan-this/

If you’ve ever wondered whether your background qualifies you for a career in cybersecurity, you’re not alone — and you’re probably more prepared than you think.

My name is Shannon Brazil, and I work in security communications at Amazon Web Services (AWS). I have been in the security space for over a decade, and my own journey into it wasn’t exactly a straight line. I started in Statistics Canada helping people fill out export declaration forms over the phone, then got a college placement in IT, moved into Digital Forensics and Incident Response, and eventually found my way into the side of security that most people don’t think about: how we communicate about it, how we tell the stories, and how we help people understand what this work looks like from the inside.

Nearly every time I’m asked that “how do I get in?” question, my answer is different. Not because I’m making it up as I go, but because I try to make it relatable to the person asking. Every person I’ve met in this field started from a different and took a completely different road to get here. There is no checklist, no degree that unlocks the door, and no straight line.

I decided to create this series for Cybersecurity Awareness Month, however I didn’t want to write another “Top 10 Tips to Break Into Security” post. Instead, I interviewed with 11 security professionals across AWS, each from a different team and a different background, and asked them one basic question: how did you actually get here?

What came out of those conversations surprised me. The stories were funny, honest, sometimes hard to hear. Over the next four weeks, I will be sharing them in a four-part series, grouped by theme:

  1. I didn’t plan this (this post) explores the non-linear paths that brought people into security from places you wouldn’t expect.
  2. What even is this job?” dives into the lesser-known corners of security that most people don’t realize exist.
  3. The work behind the work pulls back the curtain on what the day-to-day looks like compared to what people imagine.
  4. What I’d tell myself wraps the series with advice, growth moments, and the kind of wisdom that only comes from having lived it.

Nearly every person I spoke to had a different story, but one thing kept coming up: nobody planned this. And that’s kind of the whole point. So let’s start there.

Mr. Robot and a box cutter

Justin Knight, Security Engineer

Justin Knight, Security Engineer

Justin Knight was packing boxes in an Amazon warehouse when his career in cybersecurity started. He just didn’t know it yet.

It was around 2015 or 2016, and he’d just started at Amazon, working fulfillment, scanning, packing, shipping, with no tech background and no degree in computer science. What he did have was a TV show.

“I saw Mr. Robot,” he told me, grinning. “And I was like, man, I want to do that.” I’ve heard a lot of origin stories in this field, but something about watching a fictional hacker-vigilante while surrounded by conveyor belts and cardboard, and deciding that’s the career for me, just felt different. Justin started teaching himself by turning YouTube into his classroom (Daniel Messler for the fundamentals, Stök for the hacker mindset, NetworkChuck for the energy), and spinning up a Kali Virtual Machine (a free operating system built for security testing) and diving into Hack the Box (an online platform where you practice cybersecurity kills by solving challenges) and TryHackMe labs (a beginner-friendly platform for learning cybersecurity through guided exercises), all while still packing boxes.

When an IT role opened up inside the warehouse, Justin jumped on it and started doing the tasks the team disliked the most: fixing broken laptop screens. He would proactively walk the floor looking for cracked displays before anyone even filed a ticket, replace printers (the silent soul-killer of every IT professional), and eventually became the “computer guy” while already looking for what was next.

Justin found a bug bounty role posted on LinkedIn, and even though he had no idea what bug bounty even was, he reached out anyway. The hiring manager had a one-on-one with him, saw the passion, and did something I’ve seen happen before but never gets old: he lowered the role level requirements to a lower seniority level so Justin could make the jump.

Four years later, Justin is still on that team. He just got back from DEFCON, his second time, where he met the very YouTubers who taught him everything he knows.

“I didn’t even know what bug bounty was until I joined the team.” —Justin Knight

What gets me about Justin’s story is that none of the traditional ingredients were there: no degree, no bootcamp, no network of security professionals opening doors. All Justin had was a show that lit a fire, a YouTube playlist, and the kind of curiosity that made him walk the warehouse floor looking for broken screens nobody asked him to fix.

The accidental investigator

Zlata Pavlova, Sr Intel Analyst

Zlata Pavlova, Sr Intel Analyst

If Justin’s story resonated with you, Zlata’s might hit even closer to home; she started with a marketing gig at a pen testing firm.

Zlata has a degree in political science. After school, she worked the kinds of jobs that have nothing to do with either politics or science: hospitality, restaurants, retail. At some point, she got interested in social media marketing, and that led to a contract with a small penetration testing (pen testing) firm. Not to do anything security-related, just to run their social media, maintain their website, and represent them at conferences. But something happened when she started spending time around people who think for a living. The pen testers, the red teamers, the people who look at a locked door and think “how would I get through that without the key?” Their energy was contagious.

“I had no idea that there’s actually a title or a role based on finding information online,” she said. “I didn’t know that could be transformed into a career.”

Zlata had always been good at sleuthing, finding things and connecting dots that other people missed. She just didn’t know there was a word for it: OSINT, or open source intelligence. Before long, she was supporting the red team’s operations, preparing phishing engagements and doing reconnaissance for physical security assessments, and eventually conducting the assessments herself. And then she found Trace Labs.

For those unfamiliar, Trace Labs runs capture-the-flag competitions focused on finding missing persons. Zlata started as a competitor, moved into judging, and then took it even further by volunteering with the National Child Protection Task Force, doing OSINT investigations on cases involving real victims.

One of those cases led to people being rescued and suspects being arrested. A political science major who took a marketing contract at a pen testing firm helped rescue real people from real danger, because she followed her curiosity into a field she didn’t even know existed.

“That was one of the biggest cases I personally worked on. Hearing that our efforts actually helped people being rescued and the bad guys arrested… that was really rewarding.” —Zlata Pavlova

Today, Zlata works on a technical risk team, bridging the gap between cybersecurity and physical security for executive protection. She came from a world where none of this was on the radar. And her advice for anyone feeling like they don’t belong?

“Impostor syndrome is real, but you belong here. Share what you learn. Don’t assume everyone already knows it. They might not.” —Zlata Pavlova

Access denied

Arman Sadri, Security Engineer

Arman Sadri, Security Engineer

Arman Sadri’s story starts in a place most cybersecurity career guides don’t typically cover: getting in trouble as a teenager.

As a teenager, Arman was into video games. Really into them. So into them that he ended up hacking into a major tech company and stealing hardware prototypes. He was 16, maybe 17. “I’m dumb. I’m a kid,” he told me, laughing about it now, but you could hear the weight of it in his voice. That experience taught him a lot, but it also left him terrified that no legitimate employer would ever give him a chance, especially not a Fortune 500 company.

He enrolled in Year Up, a program that pairs 6 months of college with 6 months of an internship, and did so well they had him teaching the classes. Amazon offered him a job before the internship even started, letting him skip ahead and start running. He landed in IT support (the help desk, the person who remotes into your computer when something breaks) and for a while, that was the job, but Arman had his sights set on security.

He applied to a mentorship program for aspiring security engineers and found himself on a 2-year waitlist, but he waited it out. When he finally got in, he met with a senior leader every week, showed what he could do, and coached the other mentees in the room. At the end of the program, there was a hiring challenge. No other candidate could complete it, and even after they extended it externally. Arman was the only one who finished.

Four months of silence went by before he got a response: “Hey, there’s this role opening up. I think you’d be a great fit.” The role didn’t exist before that conversation; they created it for him.

“If you knew by the 80th no it was a yes, you’d be so happy every time you got told no.” —Arman Sadri

What stays with me about Arman’s story is the refusal to let his past define his ceiling. He didn’t hide from it, he just outworked it. A 2-year waitlist, and he waited. A challenge nobody could finish, and he finished it. A role that didn’t exist, and now it does. And when I asked him what makes the biggest difference for someone trying to break in, he didn’t say certifications. He said: “What can I Google about your name and see? Show me what you’ve built. Show me the impact.”

The thread

These three stories share one thread: curiosity, persistence, and a willingness to start before feeling ready. If you’re looking for a place to begin:

In Part 2: What Even Is This Job?, we explore the roles most people don’t know exist in cybersecurity — and why that matters for your career.

Have your own unconventional path into security? Share your story on LinkedIn!

Shannon Brazil

Shannon is a senior security engineer, managing a team on the AWS Customer Incident Response Team (CIRT), specializing in digital forensics and cloud security investigations. Known in the community as AWSlady, she is passionate about security education and mentoring the next generation of defenders.

[$] Analyzing Rust programs with Charon

Post Syndicated from daroc original https://lwn.net/Articles/1097198/

Nadrieril is a long-time Rust contributor, and the maintainer of the rustc
pattern-matching infrastructure. During his involvement with Rust, he has
noticed a problem with the usability of the language: it is difficult to
automatically extract information from a Rust crate for use with other tooling.

The Charon project aims to fix that by providing a stable API for accessing
internal information from the Rust compiler.

[$] Evolving the LAVD scheduler from gaming to servers

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

The extensible scheduler class, which
enables the creation of custom CPU schedulers with BPF, has led to a burst
of innovation in this area; the
LAVD scheduler has, perhaps, been one of the most noteworthy schedulers
to emerge. Though it was originally designed
for gaming applications, the LAVD scheduler has since grown to serve
other types of workloads as well. At the 2026 edition of Kernel Recipes, Changwoo Min
and Gavin Guo presented an overview of this scheduler and how it has
evolved over time.

A new Raspberry Pi Desktop release is finally available for x86-64

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

Simon Long has announced
a long-awaited release of Raspberry Pi OS, based on Debian 13 (“trixie”),
for x86-64 systems.

We managed to find the time to update the Desktop for the Buster and Bullseye
releases of Debian, but then we all just got too busy with other things, and,
while we left the Bullseye version on the website for anyone who wanted it, we
simply didn’t have time to release any newer versions. But people kept on asking
for it – we get two or three emails every week asking when the PC Desktop will
be updated, and we haven’t had an answer, because we honestly didn’t know when
we might get a chance to do it. We’ve continually tried to allocate time to be
able to work on this, but it hasn’t been easy. […]

Earlier this year, we (or rather Serge) finally got the latest version of the
Desktop running on top of a Debian Trixie image. It’s now based on 64-bit Debian
(the amd64 architecture) rather than the older 32-bit version, as Debian itself
has stopped supporting 32-bit for PC architectures. This shouldn’t be a major
problem – most PCs made in the last 15 years or so will quite happily run the
64-bit version of Debian, as will most Intel-based Macs. (Debian support for
Apple Silicon is still experimental, so unfortunately those of you with the
latest and greatest shiny fruit products will not be able to run this.)

Security updates for Wednesday

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

Security updates have been issued by AlmaLinux (bind, dovecot, freerdp, kernel, mariadb-connector-c, mod_auth_openidc, nodejs22, nodejs:22, sudo, and vim), Debian (node-shell-quote, puma, rails, ruby-jwt, and suricata-update), Fedora (chromium, cockpit, flocq, freerdp, gappalib-coq, golang-x-mod, httpd, janus, libical, musescore, python3-docs, python3.14, python3.15, rocq, rocq-stdlib, tesseract, why3, and zenon), Mageia (srt and tor), Oracle (freerdp, kernel, libpcap, mariadb-connector-c, nodejs22, sudo, and vim), Red Hat (expat and grafana), Slackware (openssh), SUSE (chromium, docker-stable, firefox, jupyter-jupyterlab, libtcnative-1-0, tomcat, tomcat10, libtcnative-1-0, tomcat11, openexr, python310, python313-azure-storage-queue, python313-langchain-anthropic, python313-sglang, python313-Werkzeug, and valkey), and Ubuntu (fluidsynth, freerdp3, freetype, golang-1.18, golang-1.21, golang-1.24, gst-plugins-good1.0, libsoup2.4, libsoup3, libwebsockets, linux, linux-aws, linux-gcp, linux-gke, linux-ibm, linux-oracle, linux-realtime, linux-azure, linux-azure-fde, linux-nvidia-tegra, linux-oem-7.0, redis, sg3-utils, tesseract, and u-boot).

CVE-2026-21589: Critical unauthenticated arbitrary file access in Atlassian products

Post Syndicated from Rapid7 original https://www.rapid7.com/blog/post/etr-cve-2026-21589-critical-unauthenticated-arbitrary-file-access-in-atlassian-products

Overview

On October 5, 2026, Atlassian published a security advisory for CVE-2026-21589, a critical arbitrary file access vulnerability affecting eight products: Bitbucket Data Center, Confluence Data Center, Jira Service Management Data Center, Jira Software Data Center, Bamboo Data Center, Crowd Data Center, Crucible, and Fisheye. Atlassian assigned the vulnerability a CVSSv4 score of 9.3. An unauthenticated remote attacker who knows a target file’s exact name and path can access it within the application’s web root; the vulnerability does not provide directory listing or enumeration.

Atlassian’s advisory treats all versions before the applicable fixed releases as affected, including unsupported versions. Affected Atlassian Cloud products have already been patched, and no action is required from Cloud customers.

Detailed technical analysis and file-read proof-of-concept scripts are public, so Rapid7 recommends patching on an emergency basis, outside of normal patch cycles, and reviewing access logs for attempted exploitation.

Technical overview

NVD lists files or directories accessible to external parties (CWE-552) as the weakness associated with CVE-2026-21589.

On October 6, watchTowr Labs published a technical analysis based on comparisons of vulnerable and patched Jira, Confluence, and Bitbucket packages. Their analysis identified a path traversal vulnerability in Atlassian’s web-resource handling: double-colon (::) sequences can become path separators during request processing, allowing traversal components to reach the resource-loading code, resulting in the contents of arbitrary file being read back to an attacker.

Their testing could not traverse outside the Tomcat context, but could read files throughout the application web root. In an Atlassian Crowd deployment that had Jira configured, reading WEB-INF/classes/crowd.properties exposed application credentials. With network access to Crowd, they used those credentials to create a user and add it to jira-administrators; Crowd’s IP allowlisting can block this direct route.

Mitigation guidance

Organizations should upgrade each affected installation to a listed fixed version or the latest available version. Atlassian’s October 5 advisory lists the following fixed versions:

Product

Fixed versions

Bitbucket Data Center

9.4.26, 10.2.8, 10.5.1

Confluence Data Center

9.2.26, 10.2.19

Jira Service Management Data Center

5.12.40, 10.3.26, 11.3.12

Jira Software Data Center

9.12.40, 10.3.26, 11.3.12

Bamboo Data Center

10.2.24, 12.1.12

Crowd Data Center

6.3.7, 7.0.3, 7.1.7, 7.2.4

Crucible

4.9.15

Fisheye

4.9.15

Organizations unable to patch immediately should remove affected instances from the internet or otherwise restrict them from external network access. Atlassian provides a Web Application Firewall or proxy rule for all affected products, a Tomcat RewriteValve mitigation for Confluence, Jira Service Management, Jira Software, Bamboo, and Crowd, and a separate urlrewrite.xml rule for Bitbucket. These mitigations are limited and are not replacements for patching.

Rapid7 strongly recommends looking for signs of compromise even after the patch has been applied. Atlassian recommends URL-decoding each access-log request line up to twice, then searching for .. immediately adjacent to /, \, or ::. Alternatively, search raw logs with the vendor-supplied regex:

(?is).*(?:/|\\|::|%(?:25)*(?:2f|5c)|(?::|%(?:25)*3a){2})(?:\.|%(?:25)*2e){2}(?:/|\\|::|%(?:25)*(?:2f|5c)|(?::|%(?:25)*3a){2}|;|%(?:25)*3b|$).*

Public testing artifacts for Jira, Confluence, and Bitbucket include a Python file-read PoC and a Nuclei template. If investigation identifies access to protected configuration files, organizations should rotate exposed credentials and other secrets after containing the affected systems.

For the latest mitigation and investigation guidance, please refer to the vendor security advisory.

Rapid7 customers

Exposure Command, Vulnerability Management, and Nexpose

Exposure Command, Vulnerability Management, and Nexpose customers can assess exposure to CVE-2026-21589 with unauthenticated vulnerability checks on Jira Software Data Center expected to be available in the October 8 content release.

Updates

  • October 7, 2026: Initial publication.

Apple’s Verified Photography System

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/10/apples-verified-photography-system.html

Apple just released a system called “Reference Image.” It can verify the image is exactly as taken by an iPhone—new models only—without tying it to a specific iPhone or photographer. It can also verify that multiple images came from the same iPhone.

Other industry solutions require a photographer or institution to vouch for an image using their own credentials. We are concerned this puts some photographers, such as those operating in conflict zones, in a difficult position; it should not be necessary to forgo anonymity in order to prove image authenticity. We built Apple Reference Image to avoid using an explicit, public credential for photographers, and to avoid even implicit public association between different photos taken by the same sensor. The final reference image is instead signed by Apple’s signing service, after validation by PCC. That signature is backed by Apple’s strongest technical guarantees.

Our implementation also protects the confidentiality of the image itself, including from Apple. Merely capturing a reference image should never expose the actual pixels to Apple or anyone else. We achieve this through the exceptional privacy properties of PCC ­ the nodes themselves are architected so that not even Apple can access image data, just as Apple cannot see the information processed for Apple Intelligence in PCC. While the revocation service must maintain a private record of photo GUIDs and associated sensors to allow for revocation, it never has access to the image data, and does not allow for public access to this record. And as final revocation checks occur using on-device lists, a device never reveals to anyone which photo it’s looking at in order to find out whether it’s still valid.

The report makes for good reading; the details are interesting.

The ASOS incident: When attackers use the channels customers trust

Post Syndicated from Emma Burdett original https://www.rapid7.com/blog/post/it-asos-incident-attackers-using-channels-customers-trust

ASOS customers opened their phones to find a hostile push notification delivered through the retailer’s own app. The message claimed the company’s Snowflake environment had been compromised and directed ASOS to engage with the sender through Telegram. ASOS later confirmed to Sky News that an unauthorized customer notification had been sent and said it was investigating activity involving third-party platforms used to communicate with customers. The company also said basic personal information, including names and contact details, may have been accessed, while payment-card information and account passwords were not believed to be affected.

The attackers’ wider claims remain unverified, and Snowflake told Sky News that its investigation had found no compromise of the Snowflake platform at that point. Even without knowing the full route into ASOS’s environment, though, the notification raises a useful question for security teams: what happens when an attacker can communicate through a channel customers already trust?

When the message comes from the real app

Most security awareness advice assumes there will be something suspicious for the recipient to notice. The sender might be unfamiliar, the domain slightly wrong, or the request out of character. Those checks become much less useful when the message arrives through the genuine app sitting on someone’s phone.

Attackers have already been moving in this direction elsewhere. Rapid7 research into calendar-based phishing showed how malicious content can appear inside familiar workflows, while our earlier look at how social engineering is evolving explored the growing use of collaboration tools and other everyday platforms to make attacks feel routine.

The ASOS incident moves that problem into a customer-facing environment. Once an attacker has access to a system that can speak on behalf of a business, the trust built around that system can work in the attacker’s favor too.

“Let’s face it, an attacker would much rather borrow trust that already exists than spend time building their own. Our recent Zimbra research is a good example, because once you can impersonate a sender or edit a calendar from inside the platform, everything the victim checks lives in a system they have no reason to question. I can’t say how this one happened, but a notification coming out of a real app gives an attacker that same head start. There is no strange domain or unfamiliar sender to catch, so the activity can look a lot like a normal Tuesday afternoon.” Douglas McKee, Director, Vulnerability Intelligence at Rapid7

What suspicious activity looks like inside legitimate services

An attacker does not always need obviously malicious infrastructure to create damage. A legitimate account, integration, or SaaS platform used in an unexpected way can provide access to employees, customers, or partners while generating activity that may look relatively ordinary when viewed on its own.

If a customer communications service suddenly sends an unusual notification, the security team needs to understand what happened around it: who accessed the platform, whether credentials or permissions changed, which connected services were involved, and whether suspicious activity appeared elsewhere in the environment.

ASOS said the activity involved third-party platforms used for customer communications, while TechRadar reported that the claimed Snowflake connection could potentially have been indirect through services running on the platform rather than evidence of a compromise of Snowflake itself. That kind of environment can leave investigators working across several providers, identities, and systems before they have a complete picture of what happened.

MDR has to follow the activity across the environment

When attackers use legitimate identities, integrations, cloud services, or communication platforms, analysts need to connect behavior across systems rather than depend on a known-bad IP address or malware signature to tell the story. An unexpected authentication, a permission change, third-party access, or unusual activity from a customer-facing service may not be enough to raise the alarm independently, but the sequence can reveal a much clearer pattern.

A preemptive MDR approach brings those signals together across endpoints, identities, cloud environments, and other parts of the attack surface so analysts can investigate the activity in context. Businesses now rely on a growing number of SaaS services and external platforms that can act on their behalf, and although security teams may not operate every one of those systems directly, they still need to understand what access they hold, how they connect to the wider environment, and how misuse would surface.

That becomes particularly relevant when a third-party service can communicate externally in the organization’s name. Access to the platform is only part of the picture; teams also need visibility into how that access is being used and whether activity elsewhere suggests the account or integration has been compromised.

The first message can create a second wave of risk

A visible incident can give other attackers useful material. Once customers know something has happened, a phishing email or text offering an account update, refund, password reset, or security check immediately has a credible event behind it.

Rapid7 research into digital footprint exposure has shown how breached information can be combined with publicly available data to support more convincing phishing, impersonation, and fraud. Names and contact details may appear relatively limited compared with passwords or payment information, but they can still become valuable when combined with a real incident and a recognizable brand.

The investigation therefore has to support several decisions at once: understanding the technical scope, establishing which customer or business data may have been involved, working with third-party providers, assessing regulatory obligations, and preparing for the possibility that the incident will be reused in follow-on attacks.

As more customer communication moves through apps, SaaS platforms, automated workflows, and third-party services, security teams need visibility into how those channels are being used as well as who can access them. The earlier unusual activity can be connected across those systems, the more room analysts have to investigate and respond before a trusted channel becomes part of a much larger incident.

The collective thoughts of the interwebz