چند هفته پیش دربارهٔ Project Glasswing نوشتیم و تجربیاتمان را از وقتی که مدلهای مرز-سایبری (cyber frontier models) را روی کد خودمان نشانه گرفتیم، مطرح کردیم. از آن زمان متوجه شدیم بخش از مطلب که بیشترین تأثیر را داشته، این ادعاست که معماری اطراف یک آسیبپذیری معمولاً مهمتر از سرعت انتشار پچ است. ⚡
در گفتگوهایمان با CISOs و تیمهای امنیتی، سؤالاتی تکراری مطرح شد: معماری ما واقعاً چه شکلی است؟ باید چه چیزهایی را مانیتور کنیم؟ از کجا شروع کنیم؟ و Cloudflare چطور میتواند کمک کند؟ 🔍
قبل از ورود به جزئیات: معماری که پایین توضیح میدهیم تا حد زیادی بر پایهٔ محصولات خود Cloudflare ساخته شده، چون تیم امنیتی ما مشتری صفر (customer zero) برای محصولاتی است که توسعه میدهیم. استک Cloudflare همین الان جلوِ کدها، کارکنان و اپلیکیشنهای مشتریان ما قرار دارد. اگر مشتری Cloudflare هستید، هر لایهٔ زیر برای شما امروز در دسترس است. اگر نیستید، اصول کلی برای هر استکی که ساختهاید قابل اعمال است. 🧩
چیزی که یک cyber frontier model واقعاً تغییر میدهد
در پست قبلی نشان دادیم که مدلی مثل Mythos چگونه تایملاین مهاجم را تغییر میدهد. چنین مدلی میتواند آسیبپذیریها را پیدا کند، زنجیرهٔ exploit را تحلیل کند و proof-of-conceptهای کارا تولید کند — خیلی سریعتر از مدلهای قبلی. اگرچه شکل کلی یک نفوذ تغییر نمیکند — reconnaissance، initial access، lateral movement، persistence و exfiltration هنوز باید اتفاق بیفتند — تفاوت در سرعت و مقیاس است. وقتی مدلها به سمت وب باز هدایت شوند، میتوانند میوههای کمدردسر را سریع کشف و هدفگیری کنند. در مقابلِ هدفهای سختشده، مدل هنوز باید پروب کند، سازگار شود و اغلب نویز بیشتری نسبت به یک اپراتور انسانی محتاط تولید میکند. ⚠️
قبلاً discovery، ساخت زنجیرهٔ exploit و تولید PoC محدودیتهای اصلی برای ساخت یک حملهٔ کارا بودند. یک frontier model اکنون هر سه را در کسری از زمان انجام میدهد. کاری که قبلاً آهسته و روشمند بود، الان سریع و بیتفکیک شده است. 🚀
هرچند AI سرعت عرضهٔ کد را برای تیمهای توسعه (از جمله تیمهای ما) بالا برده، کار تیم امنیت همان فشردگی را تجربه نکرده است. مهاجم فقط به یک شکاف نیاز دارد، اما تیم امنیت باید همهٔ شکافها را پیدا و ببندد. نوشتن یک اصلاح، regression testing و انتشار بدون خراب کردن اجزای پیرامونی محدودیتهایی دارد که AI حذفشان نمیکند. این را از تجربهٔ تلخ یاد گرفتیم وقتی به یک AI coding assistant اجازه دادیم خودش پچ بنویسد: بعضی پچها مشکل اصلی را رفع کردند ولی چیز دیگری که کد به آن وابسته بود را شکستند. 🧪
با افزایش توانایی این مدلها، تمرکز تهدیدی ما به سه نکته کلیدی خلاصه میشود که هر کدام در معماری بعدی نقشآفرین هستند:
اول: سرعت کشف. frontier models جستجو در بدنههای بزرگ کد عمومی (از جمله کتابخانههای open-source) را آسانتر میکنند. این به این معنی نیست که هر باگ کتابخانه exploitable است، یا که بیشتر آسیبپذیریها در کتابخانهها قرار دارند؛ قابل exploit بودن وابسته به نحوهٔ استفاده از کد، رسیدن ورودیِ کنترلشده توسط مهاجم به مسیر آسیبپذیر، و محافظتهای پیرامونی است. اما کتابخانهها و فریمورکهای پر استفاده یک سطح حملهٔ مشترک ایجاد میکنند که مهاجمان میتوانند در مقیاس مطالعه کنند. وقتی یک آسیبپذیری واقعی و دسترسیپذیر آنجا وجود داشته باشد، مدل میتواند سریعتر از مِینتینرها و مدافعان، مسیرهای exploit ممکن را پیدا کند و PoC تولید کند. فاصلهٔ زمانی بین کشف یک آسیبپذیری توسط مهاجم و آگاهی مدافعان چیزی است که ما را نگران میکند — اگر شما این مدلها را روی کد خود اجرا نمیکنید، عاقلانه است فرض کنید دیگران این کار را میکنند. 🔎
دوم: حجم و تطبیق exploitها. یک مدل میتواند هزاران واریانت از یک exploit تولید کند و reconnaissance را در همان مقیاس انجام دهد. این حجم به مهاجم برتری میدهد، اما لزوماً او را از detections مبتنی بر signature عبور نمیدهد. بسیاری از واریانتها امضای زیربنایی یکسانی دارند، بنابراین قانونی که اولین را بگیرد بقیه را هم خواهد گرفت. راهِ عبور، adaptation است: مدل با probing یاد میگیرد چه چیزهایی مسدود میشود و payload را بازنویسی میکند تا از قوانین عبور کند. 🛠️
سوم: تاثیر وقتی که آسیبپذیری اجتنابناپذیرانه exploited شود. هیچ معماری همهچیز را نمیگیرد. بعد از بهرهبرداری، سؤال ما این است: با یک هویت، یک مسیر یا یک credential، مهاجم تا کجا میتواند برود قبل از اینکه چیزی آنها را متوقف کند؟ اگر پاسخ «هرجای دلخواه» باشد، مشکل صرفاً خودِ آسیبپذیری نبود؛ معماری پیرامونی مشکل بود. 🧭
قابلیت ویژهٔ Cloudflare: visibility
ما حدود یک پنجم ترافیک وب جهان را میبینیم و این ترافیک به ما در زمان واقعی میگوید کدام payloadها در حال تغییرند، کدام الگوها رشد میکنند و ابزارهای مهاجم به کجا حرکت میکنند. دو تیم این visibility را به دفاع تبدیل میکنند.
اول Cloudforce One است: تیم threat intelligence، research و operations که در دل سازمان امنیت Cloudflare قرار دارد. آنها آنچه را در شبکه میبینیم به insights تبدیل میکنند تا بقیهٔ استک بر اساس آن عمل کند: adversaries ردیابیشده، کمپینهای نوظهور و indicators of compromise (IOCs). چالش اصلی این کار هرگز تشخیص اینکه چه چیزی malicious است نبود — بلکه تأخیر در mitigation بود. دانشِ تهدید جدید معمولاً باید از گزارش تهدید وارد یک feed شود و سپس به دفاع یک شرکت برسد تا قابل استفاده برای بلاک باشد. مهاجمان یاد گرفتهاند سریعتر از این حرکت کنند. شبکهٔ ما این فاصله را میبندد: مشتریان Cloudflare میتوانند Cloudforce One threat intelligence را مستقیماً داخل WAF برای بلاک ترافیک پرخطر استفاده کنند. 🛡️
دوم تیمی است که موتور WAF را مدیریت میکند: managed rulesets که جلوی پروپرِتیهای خودمان اجرا میشوند و برای همهٔ مشتریان در دسترساند، ML پشت WAF Attack Score، و روابطی که گاهی اجازه میدهد قبل از انتشار عمومی یک CVE، قاعدهای را منتشر کنیم. این تیم جهانی است و سریع حرکت میکند، تا چند ساعت بعد از ظهور یک PoC قاعده منتشر میکند. وقتی یک detection پیاده شد، در کمتر از 30 ثانیه به کل شبکهٔ ما و به همهٔ مشتریان میرسد. مثال اخیر React2Shell: یک managed WAF rule از پروپرِتیهای ما و دیگران ساعتها قبل از advisory رسمی محافظت میکرد. ⏱️
آنچه که امتیازات (scores) بر امضاها (signatures) ترجیح داده میشود
دفاعهای مبتنی بر signature برای دنیایی ساخته شده بودند که exploits نوین نادر و واریانتها هفتهها طول میکشید. SLA کلاسیک Cloudflare از PoC تا rule زنده معمولاً 12 ساعت بوده است. با ظهور frontier models، این کافی نیست. کشفها باید پیش از پیدایش CVE قابل شناسایی باشند. به همین دلیل است که detectionهای مبتنی بر ML را جلوتر از WAF سنتی signature-based لایهبندی میکنیم. 🤖
مدل ML روی حجم بزرگی از ترافیک حملهٔ گذشته آموزش داده شده و واریانتهای جدید را قبل از عمومی شدن تشخیص میدهد. یک SQL injection یا RCE نو معمولاً فقط بازآرایی از اشکال حملهای است که مدل قبلاً دیده، حتی اگر exploit خاص جدید باشد. ما مدل را روی هر درخواست اجرا میکنیم و یک WAF Attack Score بین 1 تا 99 اختصاص میدهیم، بر اساس شباهت درخواست به اشکال حملهٔ زیرین، نه بر اساس لیست signatureهای شناختهشده. هرچه score کمتر باشد، رفتار ما تهاجمیتر است و آن score تعیین میکند که درخواست عبور کند یا خیر. رویکرد مشابهی را برای AI prompts با AI Security for Apps به کار میبریم: بهجای چک کردن هر پرامپت مقابل لیستی از پرامپتهای مخرب، ارزیابی میکنیم چقدر پرامپت شبیه یک حملهٔ واقعی است. 🎯
معماری اطراف آسیبپذیری
این قابلیتها تنها وقتی اهمیت دارند که در جلوی یک اپلیکیشن چیده شوند، و اولین لایهٔ ما در دفاع-در-عمق WAF است. هر چیزی که با یک الگوی شناختهشدهٔ بد مطابقت داشته باشد قبل از رسیدن به اپلیکیشن حذف میشود؛ این کار ترافیک واضح را پاک میکند و اجازه میدهد لایههای تخصصیتر پایینتر روی چیزی که باقی میماند تمرکز کنند. در سطح API، ما از یک مدل positive security استفاده میکنیم که با API Shield اجرا میشود. بهجای حدس زدن همهٔ درخواستهای مخرب، تعریف میکنیم که یک درخواست معتبر به هر API چه شکلی است — از تعریف خودِ API یا از یادگیری بر اساس ترافیک واقعی — و هر چیزی که با آن تطابق نداشته باشد عبور نمیکند. این مزیت frontier AI را خنثی میکند: چون فقط ترافیک تاییدشده را مجاز میدانیم، تولید هزاران واریانت حمله معمولاً برای عبور ناکام میماند. 🧱
معماری لایهای Cloudflare
Bot Management ترافیک پروبینگ را در شبکهٔ ما قبل از اینکه frontier models بتوانند یک نقشه بسازند، میگیرد. این لایه هر درخواست را بر اساس احتمال خودکار بودن امتیازدهی میکند، با استفاده از سیگنالهای مشترک در سراسر شبکه: رفتار کلاینت، اینکه آیا شبیه یک مرورگر واقعی است یا خیر، و اینکه آیا اتصال با یک الگوی شناختهشدهٔ بد مطابقت دارد. یک حمله تنها زمانی موفق میشود که یک نقطهٔ نرم پیدا کند. 🕵️♂️
Zero Trust Network Access برای هر اپلیکیشن داخلی به کار میرود. اعتماد ضمنی به داخل شبکه با هویت و سیاستِ صریحِ per-request برای هر کارمند که به هر ابزار دسترسی دارد، جایگزین شده است. ارزش این رویکرد وقتی مشخص شد که یکی از مهندسانمان ابزاری را با پیکربندی نادرست منتشر کرد: یک شبکهٔ مسطح همه چیز را در همان segment در معرض قرار میداد، اما در استقرار ما، افشا تا همان ابزار متوقف شد. بعداً Require Access Protection را ساختیم تا اپلیکیشنهای تازهراهاندازیشده یا پیکربندیشدهنادرست قبل از داشتن policy دسترسی، قابل reach نباشند. 🔐
IdP Federation باعث میشود این وضعیت secure-by-default باشد و تجربهٔ single sign-on و اعتماد متقابل بین سیستمها را فراهم کند، طوری که کنترلِ دسترسی مرکزی و قاعدهمندی سادهتر شود. 👥
جمعبندی کوتاه برای تیمهای DevOps و SRE
خلاصهٔ عملی برای شما که مدیر یا مهندس عملیات و Reliability هستید: مدلهای frontier سرعت و حجمِ کشف و exploitation را افزایش میدهند، بنابراین باید بیشتر روی معماری پیرامونی سرمایهگذاری کنید نه فقط روی سرعت پچ. لایهبندی دفاعی شامل: visibility شبکه، WAF با ML-based scoring، positive security برای APIها (API Shield)، Bot Management، و Zero Trust برای دسترسیهای داخلی—اینها ترکیبی هستند که احتمالِ موفقیت مهاجم را به شدت کم میکنند. اگر میخواهید از هر نقطهٔ ورودی تا حد امکان محافظت کنید، از دیدنی بودن حملهها در سطح شبکه شروع کنید، قبل از اینکه به امضاها تکیه کنید، و همیشه فرض کنید مدلها دارند کد و dependencyهای شما را میخوانند. 💡
