بررسی سرعت در SOC

مقوله Red Teaming یکی از مؤثرترین روش‌ها برای افزایش بلوغ SOC و بهبود سرعت کشف تهدیدات است. بسیاری از SOCها دارای Rule و Alert هستند، اما تنها در زمان شبیه‌سازی حملات واقعی مشخص می‌شود که Detectionها تا چه حد کارآمدند. Red Team با اجرای تکنیک‌های واقعی مهاجمان، ضعف‌های Visibility، کمبود Telemetry، ضعف Correlation و Blind Spotهای سازمان را آشکار می‌کند. این فرآیند باعث بهبود Detection Engineering، کاهش False Negative و افزایش دقت Threat Hunting می‌شود. همچنین تحلیلگران SOC با مشاهده رفتار واقعی مهاجم، درک عمیق‌تری از Attack Chain، رفتارهای مشکوک و روش‌های سریع‌تر شناسایی و پاسخ به حوادث پیدا می‌کنند.

در روز دوشنبه در ایسمینار از تجربه ۱۵ سال کار فنی بنده به نتایج خوبی خواهیم رسید .

👆دستورالعمل برپایی معماری Detection Engineering و مدیریت Detection مبتنی بر Git در SOC

تهیه شده توسط واحد MSSP شرکت هامون

جزئیات در لینک زیر

#MSSP #SOC #SOC_as_a_Service

لینک مقاله رو میتونید اینجا ببینید
https://vrgl.ir/F6Cif

پروژه جاری که با اسپلانک مدیریت میکنم رو سوئیچ کردم رو مبحث Detection as code . ترند بازار جهانی هست ، لذا گفتم منم اونو در پروژه های کشور پیاده کنم
#تجربه

براتون در دو بخش توضیح میدم

بخش اول :Detection as Code در Splunk: از مدیریت دستی تا مدیریت مهندسی‌شده

در بسیاری از SOCها، Ruleها، Correlation Searchها و Dashboardهای Splunk مستقیماً از طریق GUI ساخته و ویرایش می‌شوند. این روش هنوز رایج است، اما در محیط‌های بزرگ می‌تواند مشکلاتی مانند دشواری در ردگیری تغییرات، Rollback، کنترل کیفیت و انتقال منظم بین محیط‌های Dev، Test و Prod ایجاد کند.

در SOCهای بالغ‌تر، رویکرد Detection as Code به‌تدریج استفاده می‌شود. در این مدل، محتوای تشخیص مانند یک دارایی نرم‌افزاری مدیریت می‌شود. SPL Queryها، Metadata، Severity، Data Source، Mapping به MITRE ATT&CK و Response Action می‌توانند در Git Repository نگهداری شوند.

این کار باعث می‌شود تغییرات قابل بررسی، قابل بازگشت و قابل ممیزی باشند. همچنین تیم‌ها می‌توانند قبل از اعمال تغییرات در محیط عملیاتی، آن‌ها را Peer Review و Test کنند.

استفاده از Sigma نیز می‌تواند کمک کند Detectionها تا حدی مستقل‌تر از Vendor طراحی شوند، هرچند تبدیل Sigma به SPL همیشه نیازمند بررسی، تنظیم و اعتبارسنجی انسانی است.
اینو در سه هفته ی اخیر شروع کردم

اگر #تجربه ای بود به اشتراک میگذارم

✅در ادامه تجربه ام با اسپلانک در Detection as code بخش دوم تجربه رو مینویسم.


بخش دوم : Detection Testing و CI/CD در Splunk

در SOCهای پیشرفته، نوشتن Detection پایان کار نیست. هر Detection باید از نظر منطق، کیفیت داده، کارایی، نرخ خطای مثبت و قابلیت اجرا در محیط واقعی بررسی شود. به همین دلیل، برخی تیم‌ها از روش‌هایی الهام‌گرفته از مهندسی نرم‌افزار مانند Testing و CI/CD استفاده می‌کنند.

در این رویکرد، وقتی Detection جدیدی در Git ثبت می‌شود، می‌توان مراحلی مانند Lint Check، بررسی ساختار Rule، اعتبارسنجی Metadata، بررسی Mapping به ATT&CK و تست SPL را اجرا کرد. سپس Rule ابتدا در محیط Dev یا Test Splunk بررسی و پس از تأیید به Production منتقل می‌شود.

ابزارهایی مانند Atomic Red Team، Caldera و Prelude Operator نیز می‌توانند برای شبیه‌سازی رفتار مهاجم و ارزیابی عملکرد Detectionها استفاده شوند. البته این تست‌ها معادل کامل Unit Test نرم‌افزار نیستند، چون کیفیت Telemetry و رفتار واقعی مهاجم همیشه متغیر است.

بنابراین، Detection as Code یک جایگزین کامل برای تحلیلگر نیست؛ بلکه روشی برای استانداردسازی، کنترل کیفیت و بهبود مستمر عملیات SOC است.
با این حال در اجرا فعلا به مشکلاتی بر خوردم که کل پایپ لاین هنوز فول عملیاتی نشده

در هفته های آینده از #تجربه ام در Detection as code بیشتر مینویسم .

به امید بالغ شدن SOC های کشور

ابزار OpenClaw یک Agent مبتنی بر هوش مصنوعی است که برخلاف Chatbotهای سنتی، فقط پاسخ تولید نمی‌کند بلکه می‌تواند «عمل» نیز انجام دهد. به بیان ساده، اگر ChatGPT شبیه یک مشاور باشد، OpenClaw بیشتر شبیه یک دستیار اجرایی است که می‌تواند فایل‌ها را بخواند، دستورات اجرا کند، مرورگر را کنترل کند، APIها را فراخوانی کند و وظایف چندمرحله‌ای را به‌صورت خودکار انجام دهد.

معماری OpenClaw معمولاً از چند بخش تشکیل می‌شود: مدل زبانی (LLM)، موتور تصمیم‌گیری، حافظه بلندمدت، ابزارها (Tools) و محیط اجرا. این ساختار باعث می‌شود Agent بتواند وظایف پیچیده را برنامه‌ریزی و اجرا کند.

اهمیت OpenClaw صرفاً به‌دلیل قابلیت‌های آن نیست؛ بلکه به‌دلیل ریسک‌های امنیتی آن نیز مورد توجه قرار گرفته است. وقتی یک Agent به فایل‌ها، Shell، ایمیل، مرورگر و سرویس‌های مختلف دسترسی دارد، حملاتی مانند Prompt Injection، Memory Poisoning و Tool Abuse می‌توانند از یک پاسخ اشتباه فراتر رفته و به اقدامات اشتباه منجر شوند.

به همین دلیل، در طراحی Agentهای مدرن، مفاهیمی مانند Least Privilege، Human Approval، Logging، Monitoring و Sandbox اهمیت بسیار زیادی پیدا می‌کنند.

نکته ای در کانفیگ UTM هایی چون فورتی گیت
برای ارتقای عملکرد SOC

چرا Context و Performance در تنظیم IPS مهم‌تر از فعال‌سازی ساده هستند؟


یکی از اشتباهات رایج در پیاده‌سازی IPS این است که سازمان‌ها تصور می‌کنند فعال‌سازی تعداد بیشتری Signature به معنای امنیت بیشتر است، درحالی‌که Context محیط اهمیت بسیار بالاتری دارد. به‌عنوان مثال، اگر سازمان هیچ Linux Server نداشته باشد، فعال‌سازی Signatureهای Exploit مرتبط با Linux ممکن است صرفاً باعث افزایش مصرف منابع و تولید Alertهای غیرضروری شود. IPS باید متناسب با دارایی‌ها، سرویس‌ها، سیستم‌عامل‌ها و معماری واقعی سازمان طراحی شود.

از طرف دیگر، Performance یکی از مهم‌ترین چالش‌های عملیاتی IPS است. IPS به‌صورت ذاتی پردازش‌بر است و ترکیب آن با SSL Inspection، Antivirus و Application Control می‌تواند فشار قابل‌توجهی بر تجهیزات وارد کند. همچنین تفاوت Flow Mode و Proxy Mode می‌تواند تأثیر مستقیمی بر Latency و Throughput داشته باشد. به همین دلیل، Sizing صحیح، Capacity Planning و طراحی Profile مناسب، نقش کلیدی در موفقیت عملیاتی IPS دارند.

#آکادمی_روزبه
#MSSP #هامون

چرا TOGAF برای طراحی SOC و MSSP اهمیت دارد؟

#تجربه

بسیاری از سازمان‌ها تصور می‌کنند ساخت SOC صرفاً به خرید SIEM، استقرار EDR و استخدام تحلیلگر محدود می‌شود؛ درحالی‌که مشکل اصلی بسیاری از SOCها، نبود معماری و هم‌راستایی با کسب‌وکار است. TOGAF به‌عنوان یک Enterprise Architecture Framework کمک می‌کند SOC صرفاً به‌عنوان مجموعه‌ای از ابزارها دیده نشود، بلکه به‌عنوان یک Capability سازمانی طراحی شود.

استاندارد TOGAF باعث می‌شود طراحی SOC از چهار زاویه Business، Data، Application و Technology انجام شود. این رویکرد کمک می‌کند نیازهای کسب‌وکار، الزامات امنیتی، جریان داده‌ها، فرآیندها و فناوری‌ها به‌صورت یکپارچه طراحی شوند.

همچنین TOGAF در Capability Mapping، طراحی Roadmap بلوغ، تعریف Target Architecture و جلوگیری از ساخت SOCهای جزیره‌ای بسیار مؤثر است. اگرچه TOGAF ابزار Detection Engineering یا Framework عملیاتی SOC نیست، اما برای معماران امنیت، طراحان MSSP، مدیران امنیت و مشاوران، یک ابزار ارزشمند برای طراحی صحیح و مقیاس‌پذیر SOC محسوب می‌شود.

مشکلات شایع Parsing لاگ‌های ویندوز در اسپلانک
بسیاری از مشکلات SOCها از مرحله Detection شروع نمی‌شود؛ بلکه از Data Quality و Parsing اشتباه لاگ‌ها آغاز می‌شود. یکی از رایج‌ترین مشکلات، تنظیم نادرست Sourcetype است که باعث می‌شود Field Extraction و Detectionها به‌درستی کار نکنند. انتخاب بین فرمت XML و Classic Event Format نیز اهمیت زیادی دارد؛ XML معمولاً ساختاریافته‌تر است و برای Detection مناسب‌تر عمل می‌کند.
یکی دیگر از مشکلات رایج، شکست در استخراج فیلدها است؛ به‌طوری‌که اطلاعاتی مانند User، Process Name یا Logon Type ممکن است به‌درستی Parse نشوند. مشکلات Timestamp نیز می‌توانند زمان واقعی رخداد را با زمان نمایش داده‌شده در Dashboard متفاوت کنند.
در محیط‌های چندزبانه، Localization نیز چالش مهمی است؛ زیرا تغییر زبان سیستم‌ها می‌تواند Regexها و Detection Content را خراب کند. همچنین Event Loss ناشی از Queue Full، مشکلات Forwarder یا Permissionها می‌تواند باعث از دست رفتن لاگ‌های حیاتی شود.
#MSSP #تجربه #هامون
👇👇

برخی Eventها نیز حجم زیادی از داده تولید می‌کنند و باعث افزایش EPS و هزینه لایسنس می‌شوند. به همین دلیل، رویکرد صحیح معمولاً این است:
Collection > Parsing > Validation >CIM > Detection
زیرا در SOC، کیفیت داده تقریباً نیمی از موفقیت Detection است.

خبر امروز
دوستانی که از اینترنت قطع بودید و یا سیستم وصله کردن ندارید بدانید:

چندین آسیب‌پذیری جدید در 7-Zip کشف شده که می‌توانند به مهاجم اجازه دهند از طریق فایل‌های فشرده دستکاری‌شده، کد مخرب اجرا کند. این ضعف‌ها عمدتاً به نحوه پردازش Symbolic Linkها، Parsing فایل‌های ZIP و Handlerهای آرشیو مربوط هستند. در برخی سناریوها، تنها باز کردن یا Extract کردن یک فایل آلوده می‌تواند منجر به نوشتن فایل خارج از مسیر مورد انتظار و در نهایت Remote Code Execution شود. مشکل بزرگ‌تر این است که 7-Zip مکانیزم Auto Update ندارد و بسیاری از سیستم‌ها هنوز نسخه‌های آسیب‌پذیر را اجرا می‌کنند. توصیه اصلی، به‌روزرسانی فوری به نسخه‌های جدید و اجتناب از باز کردن فایل‌های فشرده ناشناس است

🔴نکته: با حضور هوش مصنوعی ، این آسیب پذیری بسرعت دارای اکسپلویت شده و خیلی سریعتر از آنچه تصورش را بکنید علیه شما استفاده خواهد شد.


راهکار: راه اندازی مدیریت وصله به کمک Desktop central

https://gbhackers.com/multiple-7-zip-vulnerabilities-arbitrary-code-execution/

ثبت نام فقط از طریق بله به شماره 09902857290

🔴خطر و راهکار کشف
روش کشف استفاده از آسیب پذیری مطرح در لینک زیر

در صورت استفاده مهاجم از آسیب پذیری لینک زیر ، اینها رو در SOC خواهیم دید
✴️
Many CLDAP Requests
High Volume UDP/389
Unknown Source → DC
✴️
lsass.exe crash
Unexpected reboot
Netlogon failure
✴️
DC reboot
Service interruption
Authentication failures
✅️
index=network dest_port=389 protocol=udp
| stats count by src_ip dest_ip
| where count > 100

⚫️اولویت دفاع
Patch Domain Controllerها
مانیتور UDP/389
مانیتور Crash / Reboot DC
Network Segmentation
انجام Hunt روی Netlogon anomalies

این از آن دسته CVEهاست که اگر سازمان Splunk ES، SOC یا MSSP دارد، نباید صرفاً Vulnerability Management بماند؛ باید Detection Use Case هم داشته باشد.

#MSSP #هامون


https://github.com/0xABCD01/CVE-2026-41089

آیا EDR مرده است؟

هر چند وقت یک‌بار با ظهور فناوری‌های جدید، این سؤال دوباره مطرح می‌شود: آیا EDR دیگر کارایی ندارد؟ پاسخ کوتاه این است: خیر؛ اما نقش آن تغییر کرده است.

سال‌ها قبل، داشتن EDR برای بسیاری از سازمان‌ها یک مزیت رقابتی محسوب می‌شد، اما امروز تقریباً به یک الزام پایه تبدیل شده است. مهاجمان مدرن، مخصوصاً با کمک AI، بهتر از گذشته می‌دانند EDR چگونه کار می‌کند، چگونه از دید آن پنهان شوند و چگونه از ابزارهای قانونی سیستم برای حمله استفاده کنند.

مشکل اصلی این نیست که EDR ضعیف شده؛ مشکل این است که بسیاری انتظار دارند EDR به‌تنهایی امنیت ایجاد کند.

امروز EDR بیشتر شبیه یک Sensor قدرتمند است؛ نه یک راهکار کامل. Detection Engineering، Hardening، Threat Hunting، Telemetry مناسب و Incident Response سریع، همان بخش‌هایی هستند که EDR را ارزشمند می‌کنند.

بنابراین EDR نمرده است؛ بلکه از قهرمان اصلی به "بخشی از یک اکوسیستم دفاعی" تبدیل شده است.

تماس در بله 09902857290

OWASP Code review guide 2.0

آیا GPS یک کانال مخفی نظامی دارد؟


خلاصه مطلب مندرج در لینک زیر زبان ساده:

پژوهشگری به نام Steven Murdoch و تیمش بخشی از پیام‌های ناوبری GPS را بررسی کرده‌اند.
این بخش شامل ۱۷۶ بیت داده است که در مستندات رسمی GPS فقط به‌عنوان محتوای اختیاری (Discretionary Content) معرفی شده و کاربرد مشخصی برای آن اعلام نشده است.
آن‌ها بیش از ۱۲ میلیون نمونه پیام GPS را از سال ۲۰۰۷ تا ژانویه ۲۰۲۶ تحلیل کردند.
نتیجه تحلیل آماری نشان داد که این داده‌ها شبیه اطلاعات رمزنگاری‌شده رفتار می‌کنند و تصادفی نیستند.
نکته جالب‌تر اینکه در ۲۶ مه ۲۰۱۱ تمام ماهواره‌های فعال GPS تقریباً هم‌زمان از ارسال الگوهای آزمایشی ساده (0xAA) به ارسال این داده‌های مبهم تغییر کرده‌اند.
این تاریخ با اسناد منتشرشده مربوط به OTAD (Over-The-Air Distribution) هم‌زمان است؛ روشی که برای ارسال از راه دور کلیدهای رمزنگاری به تجهیزات نظامی استفاده می‌شود.

آیا این یعنی GPS یک «کانال مخفی» نظامی دارد؟

هنوز خیر. پژوهشگران فقط گفته‌اند که این داده‌ها احتمالاً کاربرد رمزنگاری دارند و ممکن است برای توزیع کلیدهای امنیتی استفاده شوند. اما هیچ نهاد رسمی آمریکایی این موضوع را تأیید یا رد نکرده است.


نکته امنیتی جالب

این موضوع یادآوری می‌کند که بسیاری از زیرساخت‌های حیاتی، علاوه بر کارکرد عمومی، ممکن است دارای قابلیت‌های امنیتی یا مدیریتی مستندنشده باشند. البته تا این لحظه، این یافته بیشتر یک فرضیه علمی مبتنی بر تحلیل آماری قوی است و نه مدرکی قطعی از وجود یک کانال مخفی در GPS.



https://andreafortuna.org/2026/06/09/gps-numbers-station/

هرجا SOC دست من باشد ، سه اقدام فوری انجام می‌دهم:

#تجربه

استخراج کامل Driver Inventory از تمام Endpointها؛
تطبیق هفتگی با LOLDrivers و Microsoft Blocklist؛
ساخت Use Case برای کشف بارگذاری Driverهای مشکوک در SIEM.

** حد و اندازه این عملیات به بلوغ سازمان هدف وابسته است

پیشنهاد هایی به افتای ریاست جمهوری کشور از تصمیم جدید CISA

تصمیم جدید CISA برای بازنویسی الزامات مدیریت وصله‌های امنیتی، صرفاً کاهش زمان نصب Patch از ۱۵ روز به ۳ روز نیست؛ بلکه نشانه تغییر یک پارادایم مهم در مدیریت آسیب‌پذیری است. این تغییر می‌تواند برای افتا نیز الهام‌بخش باشد.

۱. عبور از Patch Everything به Patch Smarter

سال‌ها بسیاری از سازمان‌ها تلاش کردند همه آسیب‌پذیری‌ها را با یک فوریت یکسان رفع کنند. اما CISA پذیرفته است که در عصر هوش مصنوعی، این رویکرد عملی نیست. بر این اساس، آسیب‌پذیری‌ها بر اساس ریسک واقعی اولویت‌بندی می‌شوند.

۲. ایجاد نسخه ایرانی KEV

یکی از مهم‌ترین درس‌ها، توسعه یک فهرست ملی آسیب‌پذیری‌های مورد سوءاستفاده مشابه KEV است؛ فهرستی که بر اساس تهدیدات واقعی علیه زیرساخت‌های کشور به‌روزرسانی شود و به دستگاه‌ها بگوید کدام CVEها باید فوراً اصلاح شوند.

۳. توجه به قابلیت بهره‌برداری خودکار توسط AI

سازمان CISA برای نخستین بار، قابلیت خودکارسازی حمله را به‌عنوان معیار اولویت‌بندی وارد کرده است. یعنی اگر یک آسیب‌پذیری به کمک AI بتواند در مقیاس وسیع و بدون دخالت زیاد انسان مورد سوءاستفاده قرار گیرد، باید سریع‌تر رفع شود.

۴. الزام به تحلیل فارنزیک

نکته مهم دیگر این است که وصله کردن کافی نیست. در آسیب‌پذیری‌های بحرانی، دستگاه‌ها باید بررسی کنند آیا پیش از نصب وصله، نشانه‌ای از نفوذ وجود داشته است یا خیر. این موضوع می‌تواند به الزامی برای انجام Forensic Triage در زیرساخت‌های حیاتی کشور تبدیل شود.

۵. دارایی‌محوری به جای CVE محوری

تمام آسیب‌پذیری‌ها ارزش یکسان ندارند. آسیب‌پذیری یک سامانه اینترنتی حیاتی با آسیب‌پذیری یک سیستم آزمایشگاهی داخلی متفاوت است. بنابراین طبقه‌بندی دارایی‌ها باید مبنای زمان‌بندی اصلاح قرار گیرد.

۶. استانداردسازی برچسب‌گذاری دارایی‌ها

سازمان CISA اعلام کرده است که برای دارایی‌ها Schema استاندارد منتشر خواهد کرد. این موضوع می‌تواند افتا را به سمت ایجاد یک مدل ملی طبقه‌بندی دارایی‌ها و یکپارچه‌سازی CMDB سازمان‌های حیاتی سوق دهد.

۷. حرکت به سمت Exposure Management

شاید مهم‌ترین پیام این تصمیم آن باشد که دوران Vulnerability Management سنتی رو به پایان است. در آینده، سؤال اصلی این نیست که "چند آسیب‌پذیری داریم؟" بلکه این است که "کدام آسیب‌پذیری روی کدام دارایی حیاتی، با چه احتمال بهره‌برداری و چه اثر عملیاتی، بیشترین خطر را ایجاد می‌کند؟"

در واقع، اگر بخواهیم پیام اصلی این تحول را در یک جمله خلاصه کنیم، باید گفت: عصر هوش مصنوعی، مدیریت آسیب‌پذیری را از یک فعالیت مبتنی بر شمارش CVEها به یک فرآیند مبتنی بر ریسک، زمینه عملیاتی و سرعت تصمیم‌گیری تبدیل کرده است. شاید زمان آن رسیده باشد که افتا نیز از «مدیریت وصله» به سمت «مدیریت مواجهه سایبری ملی» حرکت کند.

https://www.darkreading.com/cyber-risk/cisa-rewrites-federal-patching-requirements-ai-threat-era?utm_campaign=Oktopost-2025-09+Native+Posts&utm_content=Oktopost-LinkedIn&utm_medium=social&utm_source=LinkedIn

👆👆بیش از 9 سال با اسپلانک در آکادمی روزبه


حدود ۹ سال پیش شروع نگارش در مورد splunk را در آکادمی روزبه داشتیم و کلاسهای متعددی برگزار شد
و
پیرو آن در آن زمان کتاب اسپلانک چاپ شد

مدل‌های Mythos-Class؛ آغاز عصر جدید در امنیت سایبری

در دو دهه گذشته، فناوری‌هایی مانند تراشه‌های پیشرفته، سامانه‌های رمزنگاری نظامی و تجهیزات سایبری تهاجمی به عنوان دارایی‌های راهبردی کشورها شناخته می‌شدند. اکنون نسل جدید مدل‌های هوش مصنوعی موسوم به Mythos-Class نیز در حال پیوستن به همین دسته هستند. دلیل این موضوع تنها قدرت پردازشی یا توانایی تولید محتوا نیست؛ بلکه ظرفیت این مدل‌ها برای تحلیل، تصمیم‌گیری و تولید دانش تخصصی در حوزه‌هایی مانند امنیت سایبری است.
برخلاف نسل‌های پیشین هوش مصنوعی که عمدتاً نقش دستیار را ایفا می‌کردند، مدل‌های جدید قادرند حجم عظیمی از داده‌های امنیتی را تحلیل کرده، فرضیه‌های هانتینگ تولید کنند، قواعد تشخیص حمله را بنویسند و حتی در کشف آسیب‌پذیری‌های ناشناخته مشارکت داشته باشند. این قابلیت‌ها باعث شده است مرز میان ابزار تحلیل و تحلیلگر امنیتی به تدریج کمرنگ شود.
برای مراکز عملیات امنیت ، تیم‌های Threat Hunting و متخصصان DFIR، مهم‌ترین تحول ناشی از این فناوری، ظهور مفهوم همکار تحلیلی دیجیتال است. در چنین مدلی، هوش مصنوعی نه تنها داده‌ها را جمع‌آوری و طبقه‌بندی می‌کند، بلکه می‌تواند زنجیره حمله را بازسازی کرده، رفتار مهاجم را تفسیر کند و پیشنهادهای عملیاتی ارائه دهد. این موضوع می‌تواند زمان تشخیص و پاسخ به حوادث را از چند روز به چند ساعت یا حتی چند دقیقه کاهش دهد.
با این حال، همین توانایی‌ها ماهیتی دوگانه دارند. مدلی که قادر به کشف آسیب‌پذیری برای اهداف دفاعی است، می‌تواند در اختیار مهاجمان نیز به ابزاری برای توسعه حملات پیچیده تبدیل شود. به همین دلیل دولت‌ها و نهادهای امنیتی به این فناوری‌ها با دیدگاهی مشابه فناوری‌های راهبردی و صادرات‌محور نگاه می‌کنند.
به نظر می‌رسد در آینده نزدیک، مزیت رقابتی سازمان‌ها دیگر تنها در اختیار داشتن داده یا ابزارهای امنیتی نخواهد بود، بلکه در میزان دسترسی و بهره‌برداری مؤثر از مدل‌های هوش مصنوعی پیشرفته‌ای خواهد بود که می‌توانند نقش یک تحلیلگر خبره را در مقیاس وسیع ایفا کنند.

https://edition.cnn.com/2026/06/13/business/anthropic-mythos-model-national-security
لینک خبر ممانعت دولت آمریکا از دسترسی به برخی مدل‌های هوش مصنوعی

این مستند با عنوان «Software Bill of Materials for AI — Minimum Elements»، یک راهنمای تخصصی است که توسط نهادهای امنیت سایبری کشورهای عضو G7 و اتحادیه اروپا تدوین شده است. هدف اصلی این سند، ارتقای شفافیت در سیستم‌های هوش مصنوعی از طریق استانداردسازی «فهرست اجزای نرم‌افزاری» (SBOM) است.

از آنجا که هوش مصنوعی پیچیدگی‌های خاصی دارد، این سند مشخص می‌کند که توسعه‌دهندگان باید چه اطلاعات حداقلی (Minimum Elements) را درباره مدل‌ها، داده‌های آموزشی و اجزای سازنده سیستم خود مستند کنند. این کار به سازمان‌ها و کسب‌وکارها کمک می‌کند تا زنجیره تأمین نرم‌افزاری خود را بهتر درک کنند، آسیب‌پذیری‌های امنیتی را سریع‌تر شناسایی نمایند و ریسک‌های سایبری مرتبط با AI را مدیریت کنند.

اگرچه این راهنما یک الزام قانونی اجباری نیست، اما به عنوان یک چارچوب مرجع جهانی برای افزایش اعتماد، امنیت و مسئولیت‌پذیری در چرخه حیات محصولات هوش مصنوعی عمل می‌کند و به شرکت‌ها کمک می‌کند تا استانداردهای جهانی ایمنی را رعایت کنند.