https://virgool.ir/feed/@roozbehnoroozifa2026-11-10 18:46:35https://files.virgool.ir/upload/users/4366555/avatar/oOSiYk.pnghttps://virgool.ir/@roozbehnoroozihttps://virgool.ir/@roozbehnoroozi/اتهام-مبهم-محرومیت-واقعی-اخلاق-اعتبارسنجی-نیرو-در-صنعت-امنیت-اطلاعات-zcntdpq7pajiاکنون که سالهای سال کارکرده و از کنترل های متعدد گذشته ام و درحالی‌که درحال استخدام نیروها هستم یک نکته ذهنم را مشغول کرده : حد بک گراند چک چیست و حرف دیگران چقدر در مورد مصاحبه شونده باید مورد اتکا قرار گیرد .مقاله را با این ایده شروع میکنم که امنیت اطلاعات حرفه ای است که می‌توان با یک حرف، فردی را از عرش به فرش رساند و یا برعکس او را به مسندی رساند که شاید شایسته آن نباشد و یا او را آنچنان خوار و خفیف کرد که خدایمان فقط میتواند از عذاب آن دنیا نجات‌مان دهد. گاهی آینده شغلی یک نفر با یک ارزیابی رسمی یا گزارش مستند تغییر نمی‌کند؛ با یک جمله تغییر می‌کند: «به او اعتماد نکن؛ مسائلی دارد.»مدیری در آستانه استخدام یک کارشناس امنیت، این جمله را از یکی از آشنایان حرفه‌ای یا مدیر پیشین او می‌شنود. وقتی توضیح بیشتری می‌خواهد، پاسخ می‌گیرد: «نمی‌توانم وارد جزئیات شوم؛ فقط مراقب باش.»مدیر استخدام‌کننده اکنون با مسئله‌ای دشوار روبه‌روست. اگر هشدار را نادیده بگیرد، نگران امنیت سازمان است. اگر آن را مبنای تصمیم قرار دهد، ممکن است فرصت شغلی فردی را بر اساس ادعایی از او بگیرد که حتی امکان بررسی آن فراهم نشده است. متقاضی نیز شاید هرگز نفهمد چه چیزی درباره‌اش گفته شده، چرا کنار گذاشته شده و چگونه می‌تواند از خود دفاع کند.مسئله این مقاله همین فاصله است: فاصله میان ابهام در ادعا و قطعیت در پیامد.این بحث، دعوت به کنارگذاشتن اعتبارسنجی نیست. پرسش این است که اعتبارسنجی چگونه باید انجام شود تا هم از سازمان محافظت کند و هم به ابزاری برای انتقال خصومت، تثبیت شایعه و محروم‌کردن افراد تبدیل نشود.وقتی واژه «امنیتی» وزن یک ادعا را تغییر می‌دهددر صنعت امنیت اطلاعات، اعتماد اهمیت ویژه‌ای دارد. بعضی نقش‌ها با دسترسی به زیرساخت‌های حساس، اطلاعات محرمانه، حساب‌های ممتاز و جزئیات آسیب‌پذیری‌ها همراه‌اند. طبیعی است که مدیران درباره صلاحیت حرفه‌ای و درستکاری متقاضیان حساس باشند.اما همین حساسیت، مسئولیت گوینده و شنونده یک هشدار را بیشتر می‌کند.عبارت «در مستندسازی ضعیف است» معمولاً پرسش‌هایی درباره کیفیت کار ایجاد می‌کند. عبارت «مشکل امنیتی دارد» ممکن است ذهن شنونده را به سمت سوءاستفاده از دسترسی، افشای اطلاعات یا رفتار مخرب ببرد؛ حتی اگر گوینده هیچ‌کدام را صریحاً نگفته باشد.در چنین وضعیتی، شنونده ممکن است خلأ اطلاعات را با بدترین احتمال پر کند. یک اختلاف کاری، ضعف فنی یا ناسازگاری شخصی، در مسیر نقل‌شدن به تردیدی درباره امانت‌داری فرد تبدیل می‌شود.برچسب امنیتی، جای توضیح دقیق را نمی‌گیرد. هرچه یک واژه ظرفیت بیشتری برای آسیب‌زدن به اعتبار فرد دارد، استفاده از آن به دقت بیشتری نیاز دارد.همه مشکلات، از یک جنس نیستندکارشناسی ممکن است از نظر فنی ضعیف باشد، اما درستکار و قابل آموزش باشد. فردی ممکن است متخصص باشد، ولی همکاری تیمی دشواری داشته باشد. شخص دیگری ممکن است با مدیر خود اختلاف جدی پیدا کرده باشد، بدون آنکه تخلفی مرتکب شده باشد. در مقابل، ممکن است فردی واقعاً از دسترسی خود سوءاستفاده کرده باشد.این وضعیت‌ها پاسخ‌های یکسانی نمی‌خواهند.وقتی همه آن‌ها در عبارت‌هایی مانند «مسئله دارد»، «قابل اعتماد نیست» یا «حتی کار ساده هم نمی‌شود به او سپرد» خلاصه می‌شوند، امکان تصمیم‌گیری دقیق از بین می‌رود.مدیری که قرار است درباره استخدام تصمیم بگیرد، باید بداند نگرانی دقیقاً چیست: توانایی انجام کار؟ مسئولیت‌پذیری؟ رعایت محرمانگی؟ رفتار با همکاران؟ یا سوءاستفاده مشخص از اختیار؟همچنین باید روشن شود که گوینده شاهد مستقیم یک رفتار بوده، از دیگران شنیده یا صرفاً برداشت شخصی خود را بیان می‌کند. مشاهده، تفسیر و شنیده، ارزش یکسانی ندارند.مدیر قبلی؛ منبع مهم، اما نیازمند ارزیابیمدیر پیشین ممکن است اطلاعات بسیار ارزشمندی داشته باشد. او احتمالاً رفتار فرد را زیر فشار، کیفیت تحویل کار، نحوه مواجهه با اشتباه و میزان رعایت تعهدات دیده است. حذف این منبع می‌تواند اعتبارسنجی را ناقص کند.بااین‌حال، مدیر قبلی نیز مانند هر منبع انسانی دیگری، دیدگاهی محدود و احتمالاً منافعی در موضوع دارد. ممکن است ارزیابی او دقیق و منصفانه باشد؛ ممکن است خروج کارمند، اختلاف بر سر حقوق، تعارض مدیریتی یا تجربه‌ای ناخوشایند بر قضاوتش اثر گذاشته باشد.همین ملاحظه درباره روایت متقاضی هم برقرار است. اینکه فرد می‌گوید «مدیر قبلی با من مشکل داشت»، به‌تنهایی ادعای مدیر را بی‌اعتبار نمی‌کند.روش منصفانه، شنیدن روایت‌ها و بررسی مستقل آن‌هاست. پرسش مفید این نیست که «کدام طرف را بیشتر می‌شناسم؟» بلکه این است که «کدام بخش از گفته‌ها مشخص، مرتبط و قابل بررسی است؟»مرز اطلاع‌گیری و اجازه‌گرفتندر بعضی روابط حرفه‌ای، تماس با مدیر قبلی نوعی احترام تلقی می‌شود. این تماس می‌تواند مفید باشد، اما باید هدف آن روشن بماند: دریافت اطلاعات برای تصمیم بهتر.این فرایند نباید به این تصور تبدیل شود که مدیر پیشین درباره آینده شغلی کارکنان سابق خود حق تأیید یا رد دائمی دارد.البته تعهدات معتبر قراردادی، وضعیت همکاری فعلی و حقوق طرفین باید جداگانه بررسی شوند. اما از منظر اخلاق حرفه‌ای، ناراحتی از خروج یک نیرو، به‌خودی‌خود مبنای سلب فرصت‌های بعدی او نیست.همچنین استخدام‌کننده نباید فوریت جذب نیرو یا شناخت قبلی را جایگزین بررسی کند. آشنایی می‌تواند بخشی از شناخت باشد؛ برای یک نقش حساس، همچنان باید صلاحیت، سوابق و تناسب دسترسی‌ها ارزیابی شوند.«محرمانه است» چه چیزی را اثبات می‌کند؟گاهی محدودیت در ارائه جزئیات واقعی و موجه است. ممکن است موضوع به اطلاعات مشتری، حریم خصوصی دیگران یا بررسی جاری یک رخداد مربوط باشد. نمی‌توان انتظار داشت هر مدرکی در اختیار هر پرسش‌کننده‌ای قرار گیرد.اما محرمانگی، صحت ادعا را خودبه‌خود اثبات نمی‌کند.اگر نگرانی جدی است، باید تا حد امکان راهی برای بررسی کنترل‌شده آن پیدا شود: ارائه شرح محدود واقعه، حذف مشخصات حساس، مراجعه به مرجع دارای صلاحیت یا بررسی توسط فردی مستقل که مجاز به دریافت اطلاعات است.اگر چنین امکانی وجود ندارد، محدودیت شواهد باید در تصمیم منعکس شود. جمله «نمی‌توانم توضیح بدهم» نباید در ذهن شنونده به «پس حتماً موضوع بسیار خطرناکی است» ترجمه شود.محرمانگی باید از اطلاعات حساس محافظت کند؛ نباید ادعا را از هرگونه پرسش مصون سازد.از هشدار اولیه تا محرومیت ماندگارفرض کنیم مدیری بر اساس یک هشدار مبهم از استخدام فردی صرف‌نظر کند. مدتی بعد، مدیر دیگری از او درباره همان فرد می‌پرسد و پاسخ می‌شنود: «ما هم بررسی کردیم و جذبش نکردیم.»اکنون تصمیم اول، ظاهری شبیه تأیید مستقل پیدا کرده است؛ درحالی‌که شاید هر دو قضاوت به همان ادعای اولیه برگردند.تکرار، جای تعدد شواهد را می‌گیرد. فرد با چند منبع مستقل مواجه نیست؛ با پژواک یک گفته مواجه است.این چرخه می‌تواند از مرز یک سازمان عبور کند. به‌ویژه وقتی فرد از وجود ادعا بی‌اطلاع باشد، راهی برای تصحیح آن ندارد. محرومیت نیز ممکن است به شکل رد صریح ظاهر نشود؛ سکوت، قطع مذاکره یا کنارگذاشتن نام او از فهرست نامزدها کافی است.چنین آسیبی فقط متوجه متقاضی نیست. سازمان هم ممکن است نیروی مناسبی را از دست بدهد و فرایند استخدامش تحت تأثیر روابط غیررسمی قرار گیرد.آیا احتیاط همیشه تصمیم اخلاقی‌تری است؟مدیر ممکن است بگوید: «وقتی تردید وجود دارد، چرا ریسک کنم؟»این پرسش مشروع است. سازمان مجبور نیست هر متقاضی را استخدام کند و نبود مدرک علیه یک فرد، تضمین صلاحیت او نیست. تصمیم استخدام نیز به تناسب نقش، توانایی و عوامل متعدد دیگری وابسته است.اما احتیاط شکل‌های مختلفی دارد. می‌توان بررسی را تکمیل کرد، ارزیابی عملی انجام داد، دسترسی اولیه را محدود کرد یا تصمیم را تا روشن‌شدن موضوع به تعویق انداخت.کنارگذاشتن فرد نیز در برخی شرایط می‌تواند تصمیم مدیریتی قابل دفاعی باشد؛ اما نباید بدون پشتوانه به دیگران منتقل شود که او «فاقد امانت‌داری» یا «دارای مشکل امنیتی» است.میان «برای این نقش به اطمینان کافی نرسیدیم» و «این فرد قابل اعتماد نیست» فاصله زیادی وجود دارد. اولی محدودیت تصمیم ما را بیان می‌کند؛ دومی حکمی درباره شخصیت و اعتبار دیگری صادر می‌کند.اعتبارسنجی منصفانه چگونه انجام می‌شود؟اعتبارسنجی زمانی قابل دفاع‌تر است که پرسش‌های آن به شغل مربوط، منابعش متنوع و نتیجه‌گیری‌هایش متناسب با شواهد باشد.اگر نگرانی مطرح شد، باید درباره رفتار مشخص پرسید: چه اتفاقی افتاده؟ چه زمانی؟ انتظار سازمان چه بوده؟ پیامد چه بوده؟ آیا توضیح فرد شنیده شده است؟در کنار مدیر قبلی، می‌توان با رعایت محرمانگی و هماهنگی مناسب، از منابع دیگری مانند همکار، سرپرست پروژه یا ارزیابی عملکرد استفاده کرد. هدف جمع‌آوری نظر منفی بیشتر نیست؛ هدف فهم دقیق‌تر موضوع است.در ادعاهای مؤثر بر تصمیم، فرصت پاسخ‌گویی نیز اهمیت دارد. لازم نیست اطلاعات حساس دیگران افشا شود، اما فرد باید تا حد ممکن بداند چه نگرانی مشخصی وجود دارد تا بتواند توضیح یا مدرک مرتبط ارائه کند.اطلاعات این فرایند هم باید فقط در اختیار کسانی قرار گیرد که برای تصمیم به آن نیاز دارند. اعتبارسنجی نباید به بهانه‌ای برای گردش داستان‌های تأییدنشده در شبکه حرفه‌ای تبدیل شود.امنیت سازمان به کیفیت کنترل‌ها هم وابسته استهیچ سابقه درخشان یا توصیه‌نامه مثبتی، ریسک انسانی را به صفر نمی‌رساند. همان‌طور که یک ادعای منفی نیز به‌تنهایی رفتار آینده را پیش‌بینی نمی‌کند.بنابراین امنیت سازمان باید بر کنترل‌های متناسب تکیه کند: حداقل دسترسی، تفکیک وظایف، تأیید تغییرات حساس، ثبت و بازبینی فعالیت‌ها و فرایند روشن خروج کارکنان.اگر یک استخدام نامناسب بتواند بدون مانع به خسارتی بزرگ منجر شود، علاوه بر کیفیت جذب، باید طراحی دسترسی‌ها و نظارت سازمان نیز بررسی شود.اعتماد حرفه‌ای باید با مشاهده عملکرد و افزایش مسئولیت رشد کند. اعتبارسنجی یکی از ورودی‌های این فرایند است؛ جایگزین حکمرانی امنیت نیست.حق اصلاح و امکان بازسازی اعتبارحتی وقتی یک خطا اثبات شده، ارزیابی منصفانه به همان نقطه متوقف نمی‌شود. شدت رفتار، عمدی‌بودن، تکرار، ارتباط با شغل جدید، گذشت زمان و اقدامات اصلاحی اهمیت دارند.اشتباه قابل آموزش، تصمیم نادرست زیر فشار و سوءاستفاده عمدی از دسترسی، وزن یکسانی ندارند. در موارد جدی، محدودیت شغلی ممکن است ضروری باشد؛ اما دامنه آن باید متناسب با خطر و شواهد بماند.وقتی ادعایی نادرست از آب درمی‌آید نیز مسئولیت با سکوت پایان نمی‌یابد. اگر اطلاعات نادرست به تصمیم‌گیرندگانی منتقل شده، اصلاح آن نزد همان افراد بخشی از مسئولیت اخلاقی است.اعتبار حرفه‌ای نباید چنان آسان آسیب ببیند و چنان دشوار ترمیم شود که حتی روشن‌شدن حقیقت هم اثری نداشته باشد.مسئولیت ما در برابر جمله‌ای که نقل می‌کنیماین نوشته ادعای فراگیری یک رفتار در سراسر صنعت امنیت ایران را ندارد. هدف، هشدار درباره خطری است که باید در روابط حرفه‌ای خود نسبت به آن حساس باشیم: تبدیل اختلاف، برداشت یا شنیده به داوری سنگین درباره صلاحیت انسان‌ها.پیش از گفتن یا پذیرفتن جمله «فلانی مسائلی دارد»، باید مکث کنیم. دقیقاً چه می‌دانیم؟ از کجا می‌دانیم؟ چه بخشی برداشت ماست؟ آیا موضوع به شغل مربوط است؟ و آیا فرد امکان پاسخ‌گویی داشته است؟اخلاق حرفه‌ای زمانی معنا پیدا می‌کند که هم امنیت سازمان را جدی بگیریم و هم قدرت کلمات خود را در تغییر زندگی دیگران.هشدار مسئولانه به تصمیم بهتر کمک می‌کند؛ ادعای مبهم ممکن است فقط ترس را منتقل کند. وظیفه ما این است که پیش از تبدیل ترس به محرومیت، برای روشن‌شدن حقیقت تلاش کنیم.روزبه نوروزیروزبه نوروزیThu, 22 Oct 2026 17:24:46 +0330https://virgool.ir/@roozbehnoroozi/وقتی-مهاجم-عبور-می-کند-آیا-soc-شکست-خورده-است-از-red-teaming-تا-معماری-کشف-بلوغ-عملیاتی-و-مسئولیت-پذیری-امنیتی-eccwwx9usmhtنگاهی انتقادی به تفاوت Security Effectiveness، SOC Maturity و Contractual Accountability از منظر ISSAP و ISSMPمقدمه: یک نتیجه، دو قضاوت متفاوتتصور کنید سازمانی پس از ماه‌ها سرمایه‌گذاری روی مرکز عملیات امنیت (SOC)، تصمیم می‌گیرد اثربخشی آن را از طریق یک عملیات Red Teaming ارزیابی کند. تیم قرمز با مجوز رسمی، سناریویی چندمرحله‌ای را آغاز می‌کند، از کنترل‌های امنیتی عبور می‌کند، به دارایی حساس سازمان دسترسی پیدا می‌کند و در نهایت به هدف توافق‌شده می‌رسد.در تمام این مدت، SOC هیچ هشدار مؤثری تولید نکرده است.در جلسه ارزیابی، مدیر امنیت با اطمینان اعلام می‌کند:«ما برای سنجش بلوغ SOC عملیات Red Team اجرا کردیم. مهاجم به هدف رسید و SOC متوجه نشد. بنابراین SOC ما بالغ نیست.»اما معمار امنیت حاضر در جلسه سؤال متفاوتی مطرح می‌کند:«پیش از آنکه درباره بلوغ SOC قضاوت کنیم، آیا بررسی کرده‌ایم که این حمله اصولاً در محدوده مشاهده‌پذیری SOC قرار داشته است؟»در نگاه اول، پرسش دوم ممکن است توجیهی برای شکست SOC به نظر برسد. مگر قرار نیست SOC تهدیدات را شناسایی کند؟ مگر هدف Red Teaming سنجش توانایی سازمان در برابر مهاجم واقعی نیست؟اما این اختلاف‌نظر، ما را به یکی از مسائل بنیادین معماری و مدیریت امنیت می‌رساند:آیا موفقیت مهاجم، اثبات شکست SOC است؟ و آیا شکست SOC، لزوماً نشانه پایین‌بودن بلوغ آن است؟پاسخ به این دو سؤال، برخلاف تصور اولیه، یکسان نیست.۱. چرا اصلاً از Red Teaming برای ارزیابی SOC استفاده می‌کنیم؟در ارزیابی‌های سنتی امنیت، تمرکز غالباً بر شناسایی آسیب‌پذیری‌ها، ضعف‌های پیکربندی و کنترل‌های ناکارآمد بوده است. اما شناسایی آسیب‌پذیری الزاماً نشان نمی‌دهد که یک مهاجم واقعی تا چه اندازه می‌تواند در محیط سازمان پیشروی کند.Red Teaming این مسئله را از زاویه دیگری بررسی می‌کند.به‌جای آنکه صرفاً بپرسیم «چه آسیب‌پذیری‌هایی وجود دارد؟»، می‌پرسیم:«آیا مهاجم می‌تواند با ترکیب ضعف‌های فنی، انسانی و فرایندی به هدف مشخصی برسد؟»این تغییر نگاه، ارزیابی امنیت را از بررسی کنترل‌های منفرد به سنجش مقاومت دفاع در برابر یک زنجیره حمله نزدیک می‌کند.اما نکته مهمی وجود دارد: Red Teaming و SOC Validation مترادف نیستند.عملیات Red Team ممکن است توانایی مهاجم در عبور از کنترل‌های پیشگیرانه، سوءاستفاده از هویت، حرکت جانبی و دستیابی به دارایی‌های حساس را ارزیابی کند. در مقابل، اعتبارسنجی SOC به‌طور مشخص بر مشاهده، کشف، تحلیل، ارجاع و پاسخ به رفتارهای مهاجم تمرکز دارد.این دو فعالیت می‌توانند در یک تمرین مشترک اجرا شوند، اما الزاماً یک هدف ارزیابی ندارند.همین تفاوت، منشأ اختلاف دو دیدگاه اصلی مقاله است.۲. دیدگاه اول: نتیجه نهایی مهم است؛ مهاجم موفق شده استطرفداران رویکرد Outcome-Based Security معتقدند امنیت باید بر اساس پیامد واقعی ارزیابی شود، نه صرفاً وجود فناوری‌ها و کنترل‌ها.از این منظر، سازمان ممکن است بهترین SIEM، پیشرفته‌ترین EDR، صدها Detection Rule و مجموعه‌ای از تحلیلگران آموزش‌دیده را داشته باشد؛ اما اگر مهاجم بتواند بدون شناسایی مؤثر به اطلاعات حساس دسترسی پیدا کند، این سرمایه‌گذاری‌ها نتوانسته‌اند مانع تحقق سناریوی تهدید شوند.این استدلال از یک اصل مدیریتی مهم دفاع می‌کند:وجود کنترل امنیتی، معادل اثربخشی آن نیست.برای مدیر ارشد امنیت، مهم نیست چند Rule در SIEM فعال است؛ مهم این است که آیا سازمان می‌تواند تهدیدات مهم را در زمان مناسب شناسایی و مهار کند.این دیدگاه سه نقطه قوت دارد.نخست، از تبدیل امنیت به مجموعه‌ای از شاخص‌های ظاهری جلوگیری می‌کند. تعداد هشدارها، تعداد Use Caseها و حجم لاگ‌ها به‌تنهایی اثربخشی دفاع را اثبات نمی‌کنند.دوم، سازمان را وادار می‌کند به‌جای ارزیابی ابزارهای منفرد، کل زنجیره دفاع را بررسی کند.سوم، با منطق مهاجم سازگار است. مهاجم خود را به ساختار سازمانی، مرز واحدهای عملیاتی یا فهرست Use Caseهای تعریف‌شده محدود نمی‌کند.اما آیا این استدلال برای قضاوت درباره بلوغ SOC کافی است؟۳. نقد دیدگاه اول: آیا هر شکست دفاعی، شکست SOC است؟فرض کنید مهاجم از طریق یک سامانه SaaS که هیچ لاگی از آن به SOC ارسال نمی‌شود، به اطلاعات حساس دسترسی پیدا کند.هیچ رویدادی در SIEM ثبت نشده، EDR روی آن سامانه مستقر نیست و هیچ منبع Telemetry دیگری نیز رفتار مهاجم را منعکس نمی‌کند.در چنین شرایطی، SOC از چه داده‌ای باید برای شناسایی حمله استفاده کند؟این پرسش به یکی از اصول بنیادین Detection Engineering اشاره می‌کند:Detection بدون سیگنال قابل مشاهده و قابل تفسیر، قابل اتکا نیست.البته نبود لاگ یک سامانه الزاماً به معنای ناممکن‌بودن کشف نیست؛ ممکن است رفتار مهاجم در Identity Provider، DNS، Proxy یا سایر منابع داده آثار قابل مشاهده‌ای بر جای گذاشته باشد.اما اگر هیچ سیگنال مرتبطی در دسترس نباشد، انتظار کشف از SOC فاقد مبنای فنی است.اینجا باید میان سه مفهوم تمایز قائل شویم:Security Failure: دفاع سازمان در جلوگیری از تحقق هدف مهاجم موفق نبوده است.Detection Failure: رفتار مهاجم قابل مشاهده بوده، اما سازوکار کشف نتوانسته آن را به‌درستی شناسایی کند.Architecture Failure: معماری امنیت اساساً مشاهده‌پذیری کافی برای شناسایی رفتار موردنظر را فراهم نکرده است.این سه مفهوم ممکن است هم‌زمان رخ دهند، اما الزاماً یکسان نیستند.برای مثال، اگر SOC از سامانه‌ای هیچ داده‌ای دریافت نمی‌کند، نمی‌توان بدون بررسی مسئولیت طراحی معماری، شکست را مستقیماً به تحلیلگران نسبت داد.بااین‌حال، این استدلال هنوز یک ضعف جدی دارد.اگر SOC مسئول شناسایی شکاف‌های مشاهده‌پذیری بوده، آیا می‌تواند نبود Telemetry را بهانه کند؟پاسخ به این سؤال، ما را به دیدگاه دوم می‌رساند.۴. دیدگاه دوم: به‌جای نتیجه حمله، قابلیت‌های دفاع را ارزیابی کنیمرویکرد Capability-Based Validation پیشنهاد می‌کند که برای قضاوت درباره SOC، زنجیره عملیاتی کشف و پاسخ را به اجزای مستقل تقسیم کنیم.هر مرحله، یک قابلیت مستقل و قابل ارزیابی است.ممکن است داده مربوط به حمله دریافت شده باشد، اما Detection Rule مناسبی وجود نداشته باشد. ممکن است Rule هشدار تولید کرده باشد، اما تحلیلگر آن را False Positive تشخیص داده باشد. یا شاید تحلیلگر به‌درستی حمله را شناسایی کرده، اما فرایند Escalation آن‌قدر کند بوده که مهاجم پیش از اقدام دفاعی به هدف رسیده است.در هر سه حالت، نتیجه نهایی می‌تواند موفقیت مهاجم باشد؛ اما علت شکست و راهکار اصلاح کاملاً متفاوت است.این همان نقطه‌ای است که تفکر معماری اهمیت پیدا می‌کند.معمار امنیت صرفاً نمی‌پرسد «آیا حمله کشف شد؟» بلکه می‌خواهد بداند چه نیازمندی‌هایی تعریف شده‌اند، کدام منابع داده آن‌ها را پشتیبانی می‌کنند و آیا طراحی موجود می‌تواند قابلیت موردانتظار را فراهم کند.این نگاه با فلسفه ISSAP سازگار است: اعتبارسنجی طراحی پیش از آنکه صرفاً به نتیجه نهایی وابسته باشد، باید به الزامات، فرضیات، محدودیت‌ها و شواهد معماری متکی باشد.۵. نقد دیدگاه دوم: آیا محدوده قرارداد می‌تواند به پناهگاه ضعف امنیت تبدیل شود؟حالا باید همین دیدگاه را نیز به چالش بکشیم.فرض کنید پیمانکار SOC ادعا می‌کند:«ما فقط مسئول مانیتورینگ منابعی هستیم که در قرارداد ذکر شده‌اند. حمله از منبع دیگری عبور کرده، بنابراین مسئولیتی نداریم.»آیا این پاسخ قابل قبول است؟از منظر قراردادی، پاسخ به دامنه تعهدات بستگی دارد. اما از منظر بلوغ امنیتی، موضوع پیچیده‌تر است.یک SOC بالغ نباید صرفاً مصرف‌کننده منفعل لاگ‌ها باشد. انتظار می‌رود متناسب با مأموریت و اختیارات خود، بتواند شکاف‌های Detection Coverage را شناسایی کند، نیازمندی‌های جدید Telemetry را پیشنهاد دهد، از Threat Intelligence برای توسعه Use Case استفاده کند و از یافته‌های Threat Hunting برای بهبود توان کشف بهره ببرد.اگر پیمانکار مسئول طراحی و بهبود معماری مانیتورینگ نیز باشد، نادیده‌گرفتن یک نقطه کور مهم می‌تواند شکست همان پیمانکار محسوب شود.بنابراین باید میان دو گزاره تفاوت قائل شویم:«SOC امکان کشف این حمله را نداشت.»و:«SOC هیچ مسئولیتی در قبال نبود قابلیت کشف این حمله نداشت.»گزاره اول ممکن است از نظر فنی درست باشد؛ اما گزاره دوم نیازمند بررسی قرارداد، مسئولیت‌های معماری، اختیار تغییرات، گزارش ریسک و تصمیم‌های کارفرماست.محدودیت فنی، لزوماً رفع‌کننده مسئولیت مدیریتی یا معماری نیست.این دقیقاً نقطه اتصال تفکر ISSAP و ISSMP است.۶. سناریوی عملی: پنج رفتار مهاجم و پنج نتیجه متفاوتیک سازمان مالی را تصور کنید که SOC آن توسط پیمانکار MSSP اداره می‌شود.Red Team مأموریت دارد در یک تمرین کنترل‌شده، با استفاده از دارایی‌های مجاز و داده‌های آزمایشی، دستیابی به یک هدف حساس را شبیه‌سازی کند.در طول عملیات، پنج رفتار ثبت می‌شود:در نهایت Red Team به هدف توافق‌شده می‌رسد.اکنون سه نفر نتایج را بررسی می‌کنند.مدیر امنیت می‌گوید: «دفاع سازمان در جلوگیری از دستیابی مهاجم به هدف شکست خورده است.»این قضاوت درباره نتیجه تمرین درست است.معمار امنیت می‌گوید: «باید مشخص کنیم چرا داده‌های SaaS در معماری مانیتورینگ وجود نداشته‌اند و آیا منابع جایگزین می‌توانستند رفتار مهاجم را آشکار کنند.»این قضاوت به دنبال علت معماری شکست است.مدیر SOC می‌گوید: «باید بفهمیم چرا Kerberoasting کشف نشده و چرا هشدار EDR به‌موقع ارجاع نشده است.»این قضاوت بر عملکرد قابلیت‌های کشف و عملیات تمرکز دارد.هیچ‌کدام از این سه نفر الزاماً اشتباه نمی‌کنند. آن‌ها سه سطح متفاوت از یک مسئله را تحلیل می‌کنند.اما برای قضاوت درباره پیمانکار، یک پرسش چهارم نیز ضروری است:چه کسی مسئول طراحی پوشش SaaS، تأمین دسترسی به لاگ‌ها، توسعه Use Case و اجرای فرایند Escalation بوده است؟اگر پیمانکار مسئول شناسایی شکاف‌های معماری بوده و این نقطه کور را هرگز گزارش نکرده، ممکن است در انجام تعهدات خود کوتاهی کرده باشد.اما اگر پیمانکار شکاف را مستند کرده، ریسک آن را اعلام کرده و کارفرما به دلایل مالی یا عملیاتی با اصلاح آن مخالفت کرده باشد، مسئولیت باید متفاوت ارزیابی شود.البته پذیرش ریسک توسط کارفرما، خودِ ریسک امنیتی را از بین نمی‌برد.این تمایز میان وجود ریسک، مالکیت ریسک و مسئولیت اجرای کنترل برای قضاوت منصفانه ضروری است.۷. چرا Red Teaming به‌تنهایی بلوغ SOC را اثبات نمی‌کند؟یکی از خطاهای رایج، یکسان‌انگاشتن Maturity و Effectiveness است.بلوغ به میزان ساختاریافتگی، تکرارپذیری، مدیریت‌پذیری و بهبود مستمر قابلیت‌ها اشاره دارد. اثربخشی نشان می‌دهد این قابلیت‌ها در یک شرایط مشخص تا چه اندازه به نتیجه موردانتظار رسیده‌اند.برای مثال، ممکن است SOC دارای فرایندهای مستند، مدیریت تغییر، Detection Lifecycle، آموزش تحلیلگران و معیارهای عملکرد باشد، اما در برابر یک تکنیک جدید شکست بخورد.آیا این شکست، تمام شواهد بلوغ آن را بی‌اعتبار می‌کند؟خیر.در مقابل، SOC دیگری ممکن است فاقد فرایندهای ساختاریافته باشد، اما یک تحلیلگر باتجربه به‌صورت اتفاقی حمله را کشف و متوقف کند.آیا این موفقیت نشان‌دهنده بلوغ بالای SOC است؟باز هم خیر.موفقیت در یک سناریو، اثربخشی در همان سناریو را نشان می‌دهد. برای سنجش بلوغ، باید پایداری و تکرارپذیری قابلیت‌ها نیز ارزیابی شود.به همین دلیل، یک Red Team Exercise منفرد، هرچند ارزشمند، نباید جایگزین ارزیابی جامع بلوغ SOC شود.۸. مدل پیشنهادی: سه محور مستقل برای ارزیابیبرای جلوگیری از قضاوت‌های شتاب‌زده، می‌توان ارزیابی را در سه محور انجام داد.Security Effectivenessآیا دفاع سازمان توانست در برابر رفتار و هدف مهاجم عملکرد مؤثری داشته باشد؟ معیارهایی مانند دستیابی مهاجم به هدف، زمان کشف، زمان مهار و میزان اثر حمله در این محور بررسی می‌شوند.SOC Maturityآیا قابلیت‌های SOC ساختاریافته، قابل اندازه‌گیری، تکرارپذیر و در حال بهبود هستند؟ کیفیت فرایندها، نیروی انسانی، فناوری، Detection Engineering و مدیریت دانش در این محور قرار می‌گیرند.Contractual Accountabilityچه کسی مسئول طراحی، پیاده‌سازی، بهره‌برداری و اصلاح قابلیت‌های شکست‌خورده بوده است؟ قرارداد، RACI، اختیارات، محدودیت‌ها و ریسک‌های پذیرفته‌شده در این محور بررسی می‌شوند.این مدل، یک چارچوب تحلیلی پیشنهادی است، نه یک استاندارد رسمی بلوغ SOC.مزیت آن این است که مانع تبدیل یک نتیجه فنی به قضاوتی کلی و غیرقابل دفاع می‌شود.۹. چگونه Red Teaming را به ابزار معتبر پذیرش SOC تبدیل کنیم؟در پروژه‌های استقرار SOC، می‌توان از Adversary Emulation & SOC Detection Validation به‌عنوان بخشی از آزمون پذیرش استفاده کرد؛ مشروط بر اینکه قواعد ارزیابی پیش از اجرا مشخص شده باشند.برای مثال، باید معلوم باشد کدام رفتارهای مهاجم در دامنه آزمون قرار دارند، چه Telemetry موردانتظار است، چه زمانی برای کشف و ارجاع قابل قبول است و در صورت نبود داده، مسئولیت شناسایی و رفع شکاف بر عهده چه کسی قرار دارد.همچنین باید میان سه وضعیت تفاوت گذاشت: حمله‌ای که کشف شده، حمله‌ای که قابل کشف بوده اما کشف نشده و حمله‌ای که اساساً مشاهده‌پذیری لازم برای کشف آن وجود نداشته است.برای حالت سوم نیز باید مشخص شود نبود مشاهده‌پذیری، یک محدودیت پذیرفته‌شده بوده یا نقصی در اجرای تعهدات معماری.در چنین مدلی، نرخ کشف اهمیت دارد؛ اما نباید تنها معیار قبولی باشد. کیفیت تحلیل، زمان ارجاع، اقدامات پاسخ، پوشش داده و قابلیت بازآزمایی نیز باید بررسی شوند.از همه مهم‌تر، موفقیت Red Team نباید به‌صورت خودکار به شکست قراردادی پیمانکار تبدیل شود؛ همان‌طور که کشف چند تکنیک نیز نباید به‌تنهایی مبنای تأیید نهایی SOC باشد.ارزیابی معتبر، علاوه بر نتیجه، باید شواهد و علت نتیجه را نیز بررسی کند.۱۰. نتیجه‌گیری: سؤال درست، مهم‌تر از پاسخ سریع استاختلاف میان رویکرد Outcome-Based و Capability-Based در واقع تعارضی حل‌نشدنی نیست؛ بلکه حاصل نگاه‌کردن به مسئله از دو سطح متفاوت است.دیدگاه نخست به ما یادآوری می‌کند که امنیت باید در برابر تهدید واقعی مؤثر باشد، نه صرفاً روی کاغذ.دیدگاه دوم هشدار می‌دهد که بدون شناخت معماری، داده‌ها و مسئولیت‌ها، نمی‌توان علت شکست را به‌درستی تشخیص داد.اگر صرفاً نتیجه حمله را ببینیم، ممکن است مسئولیت را اشتباه تعیین کنیم.اگر صرفاً قابلیت‌های فنی را ببینیم، ممکن است از شکست واقعی دفاع سازمان غافل شویم.بنابراین سؤال اصلی نباید فقط این باشد که «آیا مهاجم موفق شد؟»باید بپرسیم:مهاجم چگونه موفق شد، کدام قابلیت دفاعی شکست خورد، چرا شکست خورد و چه کسی مسئول اصلاح آن است؟این تغییر پرسش، نقطه عبور از ارزیابی سطحی امنیت به تفکر معماری و مدیریتی است.از تفکر معمار امنیت تا تفکر مدیر امنیتاین بحث نمونه‌ای از مسائلی است که در آموزش پیشرفته امنیت باید فراتر از تعاریف و ابزارها بررسی شوند.در مسیر ISSAP، یاد می‌گیریم چگونه معماری امنیت را بر اساس تهدیدات، نیازمندی‌های مشاهده‌پذیری، کنترل‌های دفاعی و اعتبارسنجی طراحی تحلیل کنیم.در مسیر ISSMP، همان مسئله را از منظر مدیریت ریسک، بلوغ قابلیت‌ها، اثربخشی سرمایه‌گذاری امنیتی، حاکمیت و مسئولیت‌پذیری بررسی می‌کنیم.در دوره‌های تخصصی ISSAP و ISSMP آکادمی روزبه تلاش می‌کنیم چنین سناریوهایی را به فرصتی برای تقویت استدلال معماری، تفکر نقادانه و تصمیم‌گیری مدیریتی تبدیل کنیم؛ زیرا دانش حرفه‌ای امنیت تنها دانستن پاسخ‌ها نیست، بلکه توانایی طرح پرسش‌های درست و دفاع از تصمیم‌ها بر پایه شواهد است.آکادمی روزبه | آموزش امنیت از دانش فنی تا تفکر معماری و مدیریتیروزبه نوروزیروزبه نوروزیSat, 17 Oct 2026 22:11:24 +0330https://virgool.ir/@roozbehnoroozi/bitlocker-network-unlock-w1bfbq3ejbwnچگونه مایکروسافت امنیت دیسک را با مدیریت خودکار سازمان سازگار کرد؟رمزنگاری دیسک زمانی در سازمان موفق است که علاوه بر حفاظت اطلاعات، امکان نگهداری و مدیریت دستگاه‌ها را نیز فراهم کند. یکی از چالش‌های BitLocker، استفاده از حالت TPM + PIN است: دستگاه پیش از راه‌اندازی ویندوز از کاربر PIN می‌خواهد. این کنترل برای حفاظت هنگام دسترسی فیزیکی مفید است، اما پس از ری‌استارت شبانه یا اخذ به روز رسانی، رایانه می‌تواند پشت صفحه درخواست PIN متوقف بماند. مایکروسافت برای پاسخ به این مشکل، قابلیت Network Unlock را با Windows 10 و Windows Server 2019 معرفی کرد.فرض کنید سازمانی پانصد رایانه دارد و واحد فناوری اطلاعات، به‌روزرسانی‌های امنیتی را نیمه‌شب نصب می‌کند. نصب بعضی پچ‌ها به ری‌استارت نیاز دارد. اگر دستگاه‌ها منتظر PIN بمانند، ابزار مدیریت دیگر نمی‌تواند مراحل بعدی را در ویندوز اجرا کند. صبح نیز کاربران با فرایندی نیمه‌تمام مواجه می‌شوند. مسئله مدیر فناوری اطلاعات، انتخاب میان دو نیاز است: حفاظت در برابر دسترسی فیزیکی و اجرای عملیات بدون حضور کاربر. معماری مناسب باید برای هر دو نیاز، مسیر مشخص داشته باشد.Network Unlock این امکان را فراهم می‌کند که دستگاه واجد شرایط، هنگام اتصال به شبکه کابلی سازمان، قفل درایو سیستم‌عامل را خودکار باز کند. این قابلیت یک Key Protector اضافی است؛ یعنی مسیر دیگری برای دسترسی به کلیدهای لازم فراهم می‌کند. رمزنگاری دیسک حذف نمی‌شود و PIN نیز از پیکربندی معمول کنار نمی‌رود. اگر سرویس شبکه در دسترس نباشد، BitLocker معمولاً به محافظ TPM + PIN برمی‌گردد و کاربر باید PIN را وارد کند.پیش از استفاده، زیرساخت آماده می‌شود. دستگاه به TPM و UEFI دارای قابلیت DHCP نیاز دارد. در شبکه، سرور DHCP و سرور Windows Deployment Services یا WDS همراه با قابلیت Network Unlock قرار می‌گیرند. یک گواهی X.509 نیز ایجاد می‌شود؛ کلید خصوصی روی سرور می‌ماند و گواهی عمومی از طریق Group Policy به دستگاه‌ها می‌رسد. نقش WDS در این سناریو، پاسخ‌دادن به درخواست بازکردن قفل است؛ قرار نیست برای هر بوت، سیستم‌عامل جدیدی روی دستگاه نصب کند.فرایند با روشن‌شدن دستگاه آغاز می‌شود. ابتدا Windows Boot Manager وجود محافظ Network Unlock را تشخیص می‌دهد. چون ویندوز هنوز اجرا نشده، ارتباط شبکه از طریق قابلیت‌های UEFI انجام می‌شود. دستگاه با DHCP آدرس IPv4 می‌گیرد و سپس درخواست مخصوصی ارسال می‌کند. این درخواست شامل یک کلید واسط شبکه ۲۵۶ بیتی و یک کلید نشست AES-256 است؛ اطلاعات حساس با کلید عمومی RSA گواهی سرور محافظت شده‌اند. بنابراین گرفتن آدرس IP، به‌تنهایی اجازه بازکردن درایو را ایجاد نمی‌کند.در مرحله بعد، افزونه Network Unlock روی WDS درخواست را شناسایی می‌کند و با کلید خصوصی RSA آن را باز می‌کند. سرور، کلید واسط شبکه را با کلید نشست رمز کرده و در پاسخ مخصوص DHCP برمی‌گرداند. دستگاه پاسخ را باز می‌کند و کلید دریافت‌شده را با کلید واسط محلی دیگری ترکیب می‌کند که تنها با کمک TPM قابل بازیابی است. حاصل این ترکیب، برای ایجاد کلید لازم جهت بازکردن حجم استفاده می‌شود و بوت ادامه می‌یابد. این تبادل، تمام ترافیک DHCP را رمزنگاری نمی‌کند.از دید معماری، ارزش این طراحی در وابسته‌کردن مسیر خودکار به همکاری دستگاه و سرویس سازمانی است. سرور، PIN کاربر را ارسال نمی‌کند و این فرایند نیز مراجعه به Active Directory برای دریافت رمز بازیابی نیست. تحلیل معماری نشان می‌دهد که سازمان عملاً بخشی از تصمیم بازکردن قفل را به زیرساخت شبکه واگذار کرده است؛ بنابراین محدوده دسترسی به این زیرساخت باید با حساسیت اطلاعات دستگاه‌ها متناسب باشد.این انتخاب پیامدهای عملی دارد. معمار امنیت باید مشخص کند کدام شبکه‌ها امکان استفاده از سرویس را دارند، چه کسانی سرور و کلید خصوصی را مدیریت می‌کنند و هنگام خرابی چه روالی اجرا می‌شود. مایکروسافت امکان محدودکردن پاسخ‌دهی به زیرشبکه‌های مشخص را فراهم کرده است. در عیب‌یابی نیز اتصال کابلی، تنظیمات UEFI، DHCP، گواهی‌ها و دسترسی به WDS اهمیت دارند.برای ارزیابی موفقیت، صرف مشاهده یک بوت خودکار کافی نیست. سازمان باید سناریوی داخل شبکه، خارج شبکه و قطع سرویس را آزمایش کند. همچنین باید بداند چه تعداد دستگاه پس از به‌روزرسانی آماده کار می‌شوند و چه تعداد به دخالت انسانی نیاز دارند. برای آموزش ISSAP، این مثال نشان می‌دهد که یک تصمیم امنیتی چگونه بر عملیات اثر می‌گذارد: معمار باید مسیر مجاز، مرز اعتماد، رفتار هنگام شکست و مسئولیت نگهداری را هم‌زمان طراحی کند؛ حتی وقتی قابلیت فنی از قبل آماده است.روزبه نوروزیروزبه نوروزیTue, 13 Oct 2026 23:32:17 +0330https://virgool.ir/@roozbehnoroozi/چرا-به-issap-نیاز-داریم-از-شناخت-امنیت-تا-معماری-تصمیم-های-حیاتی-rlf6anyoyr4mسازمانی را تصور کنید که فایروال قدرتمند، سامانه تشخیص تهدید، احراز هویت چندعاملی و تجهیزات پشتیبان دارد؛ اما با قطع یک سرویس مرکزی، بخش بزرگی از فعالیتش متوقف می‌شود. یا مجموعه‌ای که اطلاعاتش رمزگذاری شده، ولی مدیر زیرساخت می‌تواند هم به داده‌ها، هم به کلیدهای رمزنگاری و هم به نسخه‌های پشتیبان دسترسی داشته باشد. در این شرایط، مشکل لزوماً کمبود ابزار نیست؛ مشکل در ارتباط میان اجزا، توزیع اختیارات و تصمیم‌هایی است که هنگام طراحی گرفته شده‌اند. اینجاست که اهمیت معماری امنیت و تخصصی مانند ISSAP آشکار می‌شود.ISSAP مخفف Information Systems Security Architecture Professional و گواهی تخصصی ISC2 در حوزه معماری امنیت سیستم‌های اطلاعاتی است. این گواهی بر توانایی طراحی راهکارهای امنیتی و ارائه مشاوره مبتنی بر ریسک برای تحقق اهداف سازمان تمرکز دارد. معمار امنیت باید نیازهای کسب‌وکار، سیاست‌ها، محدودیت‌ها و الزامات سازمان را به ساختاری تبدیل کند که بتوان آن را پیاده‌سازی، ارزیابی و اداره کرد. بنابراین، موضوع ISSAP فراتر از شناخت قابلیت‌های محصولات است؛ مسئله اصلی، طراحی رابطه میان امنیت و عملکرد سازمان است. ISSAPالبته عبارت «چرا ISSAP لازم شده است؟» به معنای اجباری‌بودن این مدرک برای همه متخصصان امنیت نیست. سازمان‌ها به توانمندی معماری امنیت نیاز دارند؛ ISSAP یکی از مسیرهای معتبر برای سامان‌دادن و ارزیابی دانش مرتبط با این توانمندی است. داشتن مدرک، به‌تنهایی کیفیت طراحی را تضمین نمی‌کند. تجربه، قدرت تحلیل، شناخت زیرساخت و توانایی گفت‌وگو با ذی‌نفعان نیز ضروری‌اند. ارزش واقعی این مسیر زمانی روشن می‌شود که آموخته‌ها در تصمیم‌های واقعی پروژه به کار گرفته شوند.یکی از دلایل افزایش اهمیت معماری امنیت، پیچیدگی محیط‌های فناوری است. امروز یک خدمت سازمانی ممکن است به شبکه، مجازی‌سازی، ذخیره‌سازی، سرویس هویت، پایگاه داده، API و چند پیمانکار وابسته باشد. هر تیم می‌تواند جزء خود را درست تنظیم کند، اما حاصل کار همچنان آسیب‌پذیر باشد. برای مثال، شبکه مدیریت از شبکه کاربران جدا شده است، ولی سامانه پشتیبان‌گیری با همان حساب‌های مدیریتی محیط اصلی اداره می‌شود. در نتیجه، تصرف یک هویت ممتاز می‌تواند هم تولید و هم بازیابی را تهدید کند. معمار باید این وابستگی مشترک را پیش از حادثه تشخیص دهد.دلیل دیگر، محدودیت نگاه محصول‌محور است. خرید تجهیزات امنیتی معمولاً پاسخ ملموسی به نگرانی مدیران به نظر می‌رسد؛ اما محصول نمی‌تواند به‌جای سازمان درباره مرز اعتماد، مالکیت داده یا ریسک پذیرفتنی تصمیم بگیرد. فایروال زمانی مؤثر است که بدانیم چه ارتباطی باید برقرار باشد و چرا. سامانه مدیریت دسترسی ممتاز زمانی ارزش ایجاد می‌کند که چرخه اعطای دسترسی، تأیید، نظارت و لغو آن تعریف شده باشد. معماری امنیت کمک می‌کند انتخاب ابزار از نیاز مشخص و طراحی منسجم پیروی کند.در همین نقطه، تفاوت تمرکز CISSP و ISSAP روشن‌تر می‌شود. CISSP دامنه گسترده‌ای از دانش امنیت را پوشش می‌دهد و مباحث تحلیلی و معماری نیز در آن وجود دارند. ISSAP تمرکز تخصصی‌تری بر طراحی و ارزیابی معماری امنیت دارد. این تفاوت را نباید به «حفظیات در برابر تحلیل» یا صرفاً دشوارترشدن سؤال‌ها تقلیل داد. در مسیر معماری، متخصص باید نشان دهد چگونه یک اصل امنیتی را در محیطی با محدودیت بودجه، وابستگی فنی، الزام قراردادی و نیاز عملیاتی به تصمیمی قابل دفاع تبدیل می‌کند.برای نمونه، شرکتی سامانه سفارش‌گیری خود را در دو مرکز داده اجرا می‌کند. تمام درخواست‌های مجوز به یک سرویس مرکزی تصمیم‌گیری دسترسی، یعنی PDP، ارسال می‌شوند. پیشنهاد امنیتی این است که هنگام قطع ارتباط با PDP، درخواست‌ها رد شوند. این رفتار می‌تواند از دسترسی بدون تأیید جلوگیری کند، اما اگر همه عملیات یکسان در نظر گرفته شوند، قطع ارتباط ممکن است سفارش‌گیری را نیز متوقف کند. از طرف دیگر، اجازه ادامه همه عملیات با مجوزهای قدیمی می‌تواند تغییر غیرمجاز اطلاعات حساس را ممکن سازد.مسئله معماری، تعریف رفتار متناسب با حساسیت عملیات است. شاید برای سفارش‌های عادی بتوان تصمیم‌گیری محلی را با سیاست معتبر، عمر محدود، سقف عملیات و ثبت کامل رخدادها طراحی کرد. در مقابل، تغییر حساب بانکی مشتری باید تا دریافت تأیید معتبر و به‌روز متوقف شود. این طراحی نیز خودکار و بدون بررسی قابل قبول نیست: اگر دسترسی کاربر در مرکز دیگر لغو شده باشد چه می‌شود؟ سیاست محلی چه زمانی منقضی می‌شود؟ پس از بازگشت ارتباط، وضعیت چگونه تطبیق داده خواهد شد؟ پاسخ این پرسش‌ها، کیفیت معماری را مشخص می‌کند.همین نوع تحلیل در زیرساخت مجازی نیز کاربرد دارد. جداسازی ترافیک ماشین‌های مجازی، مدیریت، ذخیره‌سازی و جابه‌جایی ماشین‌ها نقطه شروع مناسبی است؛ اما معمار باید دامنه اثر تصرف هر بخش را بررسی کند. آیا دسترسی به کنسول مدیریت، امکان تغییر شبکه و اتصال دیسک ماشین‌ها را فراهم می‌کند؟ آیا نسخه پشتیبان در همان قلمرو اعتماد قرار دارد؟ آیا حساب اضطراری هنگام اختلال سرویس هویت قابل استفاده است و استفاده از آن ثبت می‌شود؟ امنیت معماری از بررسی ارتباط این تصمیم‌ها با یکدیگر حاصل می‌شود.ISSAP همچنین به پیوند امنیت با حاکمیت و ریسک توجه دارد. تصمیم معماری باید مشخص کند چه دارایی‌ای محافظت می‌شود، چه تهدیدی مطرح است، چه محدودیتی وجود دارد و چه ریسکی باقی می‌ماند. اگر سازمان برای ادامه خدمت، استفاده موقت از سیاست محلی را می‌پذیرد، این پذیرش باید آگاهانه، محدود و مستند باشد. معمار پیشنهاد و پیامدهای آن را توضیح می‌دهد؛ مالک مسئول کسب‌وکار درباره پذیرش ریسک تصمیم می‌گیرد. چنین رویکردی مانع می‌شود استثناهای موقت، بی‌سر‌وصدا به وضعیت دائمی تبدیل شوند.در سرفصل رسمی جاری ISSAP، چهار حوزه اصلی مطرح‌اند: حاکمیت، ریسک و انطباق؛ مدل‌سازی معماری امنیت؛ امنیت زیرساخت و سیستم؛ و معماری مدیریت هویت و دسترسی. این ترکیب نشان می‌دهد معماری امنیت هم به الزامات سازمانی توجه دارد و هم به طراحی فنی. ارزیابی گزینه‌های جایگزین، اعتبارسنجی طراحی و بررسی شکاف‌ها نیز در این چارچوب جای دارند. بنابراین، ترسیم یک نمودار زیبا کافی نیست؛ باید بتوان نشان داد طراحی، نیازها و شرایط خرابی را چگونه پاسخ می‌دهد. این مسیر برای متخصصانی اهمیت ویژه دارد که مسئولیتشان از اجرای کنترل‌ها به انتخاب و دفاع از طراحی گسترش یافته است: معماران زیرساخت، متخصصان ارشد امنیت، مشاوران و مدیران فنی. پرسش‌های آنان دیگر فقط درباره تنظیم یک قابلیت نیست؛ درباره پیامد تصمیم در کل سامانه است. آیا کنترل پیشنهادی وابستگی خطرناکی ایجاد می‌کند؟ آیا بازیابی واقعاً مستقل است؟ آیا رشد سامانه، مدل اعتماد را تغییر خواهد داد؟نیاز به ISSAP را می‌توان در همین مسئولیت دید: سازمان به افرادی نیاز دارد که اصول امنیت را به تصمیم‌های هماهنگ، آزمون‌پذیر و قابل توضیح تبدیل کنند. ارزش این تخصص در تعداد اصطلاحات یا محصولات شناخته‌شده خلاصه نمی‌شود؛ در توانایی پیش‌بینی پیامدها، مقایسه گزینه‌ها و طراحی امنیتی است که در شرایط واقعی، همراه با کسب‌وکار دوام بیاورد.روزبه نوروزیروزبه نوروزیMon, 12 Oct 2026 09:07:48 +0330https://virgool.ir/@roozbehnoroozi/تفاوت-cissp-و-issap-از-شناخت-اصول-تا-طراحی-معماری-با-مثال-sc5kimme3o5sتفاوت CISSP و ISSAP را می‌توان در یک تصمیم واقعی دید: وقتی یک کنترل امنیتی درست، ممکن است کسب‌وکار را متوقف کند.فرض کنید سامانه سفارش‌گیری شرکتی در دو مرکز داده فعال است. برای یکسان‌سازی مجوزهای دسترسی، تمام درخواست‌ها به یک سرویس مرکزی تصمیم‌گیری مجوز یا PDP ارسال می‌شوند. تیم امنیت پیشنهاد می‌کند اگر این سرویس در دسترس نبود، درخواست‌ها رد شوند؛ همان رویکرد Fail-closed.این پیشنهاد از منظر جلوگیری از دسترسی غیرمجاز منطقی است. اما کسب‌وکار الزام دارد هنگام قطع ارتباط بین مراکز، سفارش‌گیری ادامه پیدا کند. در مقابل، تغییر حساب بانکی مشتری باید فقط با مجوز معتبر و به‌روز انجام شود؛ حتی اگر این عملیات به تأخیر بیفتد.ISSAPاینجا شناخت اصل امنیتی کافی نیست. معمار باید تصمیم بگیرد کدام عملیات، با چه محدودیت‌هایی و تحت چه شرایطی ادامه پیدا کند.یک طراحی مناسب می‌تواند تصمیم‌گیری مجوز را در هر مرکز مستقر کند، سیاست‌ها را به‌صورت مرکزی مدیریت و نسخه‌بندی کند و برای سفارش‌های عادی، استفاده محدود از سیاست معتبر محلی را مجاز بداند. عملیات حساس، مانند تغییر حساب بانکی، هنگام نبود امکان تأیید مجوز به‌روز متوقف می‌شود.در CISSP، مفاهیمی مانند کمترین دسترسی، دسترس‌پذیری، مدیریت ریسک و رفتار امن هنگام خرابی بررسی می‌شوند. ISSAP تمرکز عمیق‌تری بر تبدیل این اصول به معماری دارد:وابستگی‌ها کجا هستند؟ سیاست‌ها چگونه توزیع می‌شوند؟ مجوزها چه زمانی منقضی می‌شوند؟ طراحی چگونه آزموده می‌شود؟🟢دوره CISSP نیز تحلیلی و دارای مباحث معماری است و تفاوت با ISSAP صرفاً دشواری بیشتر سؤال‌ها نیست.🟣دوره ISSAP شما را به بررسی پیامدهای یک تصمیم در کل سامانه دعوت می‌کند؛ تصمیمی که باید هم امنیت را حفظ کند و هم نیاز کسب‌وکار را پاسخ دهد.✨️بنا به درخواست هموطنان داخل و خارج از کشور ، دوره ISSAP را انشالله در زمستان برگزار میکنم 09902857290روزبه نوروزیروزبه نوروزیMon, 12 Oct 2026 09:02:02 +0330https://virgool.ir/@roozbehnoroozi/وقتی-نقد-حرفه-ای-به-ایرادگیری-دائمی-تبدیل-می-شود-etzdaafppp3wبررسی جامع رفتار منتقدانه در فضای امنیت سایبری با افرادی مواجه می‌شویم که بخش زیادی از فعالیت حرفه‌ای خود را به یافتن، برجسته‌کردن و انتشار اشتباهات دیگران اختصاص می‌دهند. آن‌ها کوچک‌ترین ضعف فنی، اشتباه نگارشی، تصمیم مدیریتی یا نقص یک محصول را به‌سرعت در شبکه‌های اجتماعی منتشر می‌کنند و گاهی مسئله‌ای محدود را چنان بازنمایی می‌کنند که گویی یک فاجعه امنیتی رخ داده است. مشاهده این رفتار، پرسش مهمی ایجاد می‌کند: آیا چنین رویکردی نشانه دقت و تعهد حرفه‌ای است یا بیشتر از نیاز به جلب توجه، نمایش تخصص و تخریب دیگران سرچشمه می‌گیرد؟پاسخ ساده‌ای وجود ندارد. نمی‌توان همه منتقدان را با یک انگیزه یا تیپ شخصیتی توضیح داد. نقد می‌تواند بسیار ارزشمند و حتی ضروری باشد؛ اما شیوه بیان، میزان تناسب، شواهد، زمان انتشار و هدف منتقد تعیین می‌کند که با نقد حرفه‌ای مواجهیم یا ایرادگیری نمایشی. ذهن امنیتی برای پیداکردن نقص آموزش دیده استبخشی از این رفتار، محصول ماهیت حرفه امنیت سایبری است. متخصص امنیت آموزش می‌بیند که به ظاهر سالم سیستم‌ها اعتماد نکند، فرضیات را به چالش بکشد، استثناها را پیدا کند و همواره سناریوی شکست را در نظر بگیرد. مهندس امنیت باید بپرسد اگر کنترل دسترسی دور زده شود، نسخه پشتیبان از بین برود، حساب مدیریتی تصاحب شود یا یک تأمین‌کننده آلوده باشد، چه اتفاقی خواهد افتاد؟این ذهنیت برای کشف آسیب‌پذیری و پیشگیری از حمله ضروری است. سازمان‌ها به افرادی نیاز دارند که ضعف‌هایی را ببینند که دیگران از کنارشان عبور می‌کنند. مشکل زمانی آغاز می‌شود که این الگوی فکری از محیط تحلیل فنی به تمام روابط حرفه‌ای و اجتماعی فرد منتقل شود. در این حالت، شخص دیگر فقط سیستم را با نگاه انتقادی بررسی نمی‌کند؛ بلکه همکار، مدیر، فروشنده و حتی کل صنعت را نیز صرفاً از دریچه نقص، خطا و شکست می‌بیند.این وضعیت را می‌توان نوعی «تغییر شکل حرفه‌ای» دانست؛ یعنی مهارتی که در جای خود ارزشمند است، به تدریج به عادت غالب ذهنی تبدیل می‌شود. متخصصی که دائماً به دنبال تهدید است ممکن است توانایی مشاهده پیشرفت، محدودیت منابع، ملاحظات اجرایی و تلاش‌های موفق دیگران را از دست بدهد. چرا محتوای منفی بیشتر دیده می‌شود؟یکی از عوامل مهم، سوگیری منفی است. ذهن انسان به‌طور طبیعی به تهدید، خطر، شکست و خبر بد بیشتر از رویدادهای عادی یا موفقیت‌ها توجه می‌کند. جمله «این سازمان یک فرایند امنیتی را با موفقیت اجرا کرد» معمولاً کمتر از جمله «فاجعه امنیتی دیگری که مدیران پنهان کردند» توجه می‌گیرد.شبکه‌های اجتماعی این گرایش را تقویت می‌کنند. محتوای انتقادی، افشاگرانه و خشم‌آفرین معمولاً بازدید، بازنشر و واکنش بیشتری ایجاد می‌کند. در نتیجه، فرد به‌تدریج یاد می‌گیرد که هرچه لحن تندتر، عنوان هیجان‌انگیزتر و اتهام بزرگ‌تر باشد، بیشتر دیده خواهد شد. این همان اقتصاد توجه است؛ محیطی که الزاماً دقیق‌ترین تحلیل را پاداش نمی‌دهد، بلکه اغلب واکنش‌برانگیزترین روایت را برجسته می‌کند.ممکن است شخص در ابتدا با نیت آموزشی مطلبی انتقادی منتشر کند، اما پس از دریافت توجه و تأیید اجتماعی، به‌تدریج هویت حرفه‌ای خود را بر همین الگو بنا کند. مخاطبان نیز از او انتظار دارند دائماً یک ضعف جدید، رسوایی تازه یا مقصر دیگری معرفی کند. در چنین شرایطی، نقد از یک ابزار تخصصی به محصول رسانه‌ای تبدیل می‌شود. نمایش صلاحیت از طریق خطای دیگرانپیداکردن اشتباه دیگران یکی از سریع‌ترین روش‌های نمایش دانش است. ساختن یک سامانه امن، طراحی معماری مناسب، اجرای پروژه و نگهداری آن ممکن است ماه‌ها زمان ببرد و نتیجه‌اش نیز برای عموم قابل مشاهده نباشد. در مقابل، پیداکردن یک اشتباه و انتشار آن می‌تواند در چند ساعت هزاران بازدید ایجاد کند.برخی افراد از طریق پایین‌آوردن اعتبار دیگران تلاش می‌کنند جایگاه خود را بالاتر نشان دهند. پیام پنهان بعضی از انتقادها این است: «آن‌ها این اشتباه را مرتکب شدند، اما من آن‌قدر متخصص هستم که آن را تشخیص دادم.» این شیوه جایگاه‌سازی، به‌خصوص زمانی جذاب می‌شود که فرد تجربه ساختن، اختیار تصمیم‌گیری یا کارنامه اجرایی قابل توجهی نداشته باشد.کار اجرایی با محدودیت همراه است. بودجه محدود، کمبود نیرو، سامانه‌های قدیمی، مقاومت سازمانی، الزامات کسب‌وکار و پنجره‌های کوتاه تغییر، تصمیم‌های امنیتی را پیچیده می‌کنند. کسی که مسئولیت اجرا را تجربه نکرده، ممکن است تصور کند هر نقصی ناشی از نادانی یا بی‌مسئولیتی است. درحالی‌که بسیاری از تصمیم‌ها حاصل پذیرش آگاهانه یک ریسک، محدودیت منابع یا انتخاب میان چند گزینه نامطلوب هستند. آیا این رفتار یک اختلال روان‌شناختی است؟نسبت‌دادن این رفتار به یک اختلال روان‌شناختی یا تیپ شخصیتی مشخص، بدون ارزیابی تخصصی، صحیح نیست. از روی چند پست تند یا انتقادی نمی‌توان درباره سلامت روان یا شخصیت فرد حکم صادر کرد. بااین‌حال، برخی ویژگی‌ها می‌توانند احتمال این رفتار را افزایش دهند؛ از جمله بدبینی، توافق‌پذیری پایین، نیاز شدید به تأیید، احساس برتری، حساسیت زیاد به خطای دیگران یا ناکامی حرفه‌ای.گاهی انتقاد دائمی مکانیسمی برای جبران احساس نادیده‌گرفته‌شدن است. فرد ممکن است احساس کند دانش او در سازمان دیده نمی‌شود، اختیار اصلاح ندارد یا دیگران به توصیه‌هایش توجه نمی‌کنند. در نتیجه، شبکه اجتماعی به مکانی برای کسب قدرت، تأیید و اعتبار تبدیل می‌شود.بااین‌حال، لازم است میان انگیزه احتمالی و قضاوت قطعی تفاوت بگذاریم. ممکن است یک منتقد تند واقعاً نگران منافع عمومی باشد؛ همان‌طور که ممکن است فردی با ادبیات آرام نیز هدفی غیرحرفه‌ای داشته باشد. معیار اصلی باید روش، شواهد و پیامد رفتار باشد، نه حدس درباره شخصیت فرد. این الگو مختص امنیت سایبری نیستایرادگیری نمایشی در بسیاری از حوزه‌ها دیده می‌شود. در سیاست، افراد با افشای خطای رقبا کسب اعتبار می‌کنند. در دانشگاه، برخی پژوهشگران بیشتر با تخریب کار دیگران شناخته می‌شوند تا ارائه نظریه جدید. در پزشکی، مهندسی، مدیریت، هنر و ورزش نیز افرادی وجود دارند که هویت حرفه‌ای خود را بر نقد دائمی بنا کرده‌اند.بااین‌حال، امنیت سایبری زمینه مساعدتری برای این رفتار فراهم می‌کند. یافتن نقص واقعاً بخشی از شغل متخصص امنیت است، شکست‌ها ممکن است پیامدهای جدی داشته باشند و بسیاری از مخاطبان نیز توانایی ارزیابی فنی ادعاها را ندارند. بنابراین منتقد می‌تواند یک ضعف محدود را با واژگانی مانند «فاجعه»، «نفوذ کامل»، «رسوایی امنیتی» یا «نابودی زیرساخت» توصیف کند، بدون آنکه مخاطب بتواند شدت واقعی خطر را تشخیص دهد. مرز نقد حرفه‌ای و ایرادگیری نمایشینقد حرفه‌ای به شواهد متکی است و شدت مسئله را متناسب با ریسک واقعی بیان می‌کند. منتقد حرفه‌ای میان یک ضعف نظری، پیکربندی نامناسب و آسیب‌پذیری قابل بهره‌برداری تفاوت قائل می‌شود. او پیش از انتشار عمومی، در صورت امکان، مسئول یا تولیدکننده مربوط را مطلع می‌کند و فرصت مناسبی برای بررسی و اصلاح در نظر می‌گیرد.در مقابل، ایرادگیری نمایشی معمولاً بر حدس، بزرگ‌نمایی و قضاوت عجولانه استوار است. هر نقصی به‌عنوان یک بحران معرفی می‌شود و پیش از آنکه موضوع از مسیر مسئولانه بررسی شود، در شبکه‌های اجتماعی انتشار می‌یابد. در این رویکرد، معرفی مقصر از ارائه راه‌حل مهم‌تر است.منتقد حرفه‌ای محدودیت‌های اجرا را می‌فهمد و راه‌حل متناسب پیشنهاد می‌کند. او نمی‌گوید «چرا همه‌چیز را فوراً عوض نکردید؟»، بلکه هزینه، ریسک اختلال، اولویت‌های کسب‌وکار و توان تیم را نیز بررسی می‌کند. هدف او کاهش ریسک است، نه اثبات برتری شخصی.در امنیت سایبری، افشای مسئولانه اهمیت ویژه‌ای دارد. انتشار جزئیات یک آسیب‌پذیری پیش از آماده‌شدن اصلاحیه ممکن است مهاجمان را راهنمایی کند. بنابراین گاهی خودِ انتشار عجولانه، ریسکی بزرگ‌تر از ضعف اولیه ایجاد می‌کند. آیا سخن‌گفتن از ضعف‌ها غیراخلاقی است؟قطعاً خیر. سکوت درباره یک آسیب‌پذیری جدی، فساد، پنهان‌کاری یا خطری که می‌تواند به مردم آسیب بزند نیز ممکن است غیراخلاقی باشد. جامعه امنیت به پژوهشگران و منتقدانی نیاز دارد که در برابر ادعاهای نادرست و اقدامات پرخطر سکوت نکنند.مسئله، اصل نقد نیست؛ بلکه نیت، روش، تناسب، زمان و پیامد آن است. متخصص مسئول پیش از انتشار عمومی از خود می‌پرسد: آیا شواهد کافی دارم؟ آیا شدت ادعای من با خطر واقعی متناسب است؟ آیا مسئول مربوط فرصت بررسی و اصلاح داشته است؟ آیا انتشار عمومی موجب کاهش ریسک می‌شود یا فقط هیجان، ترس و آسیب اعتباری ایجاد می‌کند؟ آیا اطلاعات منتشرشده ممکن است مورد سوءاستفاده مهاجمان قرار گیرد؟ آیا در کنار نقد، مسیر اصلاحی نیز ارائه کرده‌ام؟ خطر ایرادگیری دائمی برای خود فردتمرکز مداوم بر خطاها فقط به دیگران آسیب نمی‌زند؛ بلکه می‌تواند ذهن و هویت حرفه‌ای خود فرد را نیز فرسوده کند. کسی که دائماً ضعف‌ها را می‌بیند ممکن است به بدبینی حرفه‌ای، فرسودگی، نگاه صفر و یکی و احساس برتری دانشی دچار شود. او به‌تدریج به‌جای پرسیدن «چگونه این وضعیت را بهتر کنیم؟» می‌پرسد «چه کسی اشتباه کرده است؟»در این مرحله، تخصص از ابزاری برای ساختن به وسیله‌ای برای قضاوت تبدیل می‌شود. چنین فردی ممکن است در شبکه اجتماعی مخاطب فراوانی پیدا کند، اما در همکاری تیمی، مدیریت پروژه و ایجاد تغییر پایدار موفق نباشد؛ زیرا سازمان‌ها فقط به کسی که ایراد را پیدا می‌کند نیاز ندارند. آن‌ها به متخصصی نیاز دارند که ریسک را اولویت‌بندی کند، محدودیت‌ها را بفهمد، راه‌حل قابل اجرا پیشنهاد دهد و مسئولیت نتیجه را نیز بپذیرد. بلوغ حرفه‌ای یعنی دیدن نقص و کمک به اصلاح آنمعیار بلوغ یک متخصص امنیت، تعداد ایرادهایی نیست که پیدا می‌کند. ارزش واقعی او در توانایی تشخیص درست ریسک، بیان مسئولانه مسئله، پیشنهاد راه‌حل متناسب و همراهی با اجرای اصلاحات مشخص می‌شود.منتقد خوب برای هر صنعت ضروری است، اما متخصص ارزشمندتر کسی است که علاوه بر دیدن نقص، پیچیدگی اجرا را نیز درک کند. نقد حرفه‌ای باید به تصمیم بهتر، کاهش ریسک و یادگیری جمعی منجر شود. اگر نتیجه نقد فقط تحقیر، ترس، نمایش تخصص یا تخریب اعتبار دیگران باشد، احتمالاً از هدف اصلی امنیت فاصله گرفته‌ایم.امنیت سایبری بیش از آنکه به قاضی نیاز داشته باشد، به سازنده نیاز دارد؛ متخصصی که ضعف را می‌بیند، آن را منصفانه توضیح می‌دهد و برای ساختن وضعیت بهتر نیز مسئولیت می‌پذیرد.روزبه نوروزیروزبه نوروزیMon, 21 Sep 2026 15:37:19 +0330https://virgool.ir/@roozbehnoroozi/sbom-و-استانداردهای-cyclonedx-و-spdx-شناسنامه-ای-برای-امنیت-زنجیره-تأمین-نرم-افزار-twqqlyh3idynمقدمهنرم‌افزارهای امروزی معمولاً به‌طور کامل در داخل یک سازمان تولید نمی‌شوند. حتی یک برنامه نسبتاً ساده ممکن است از ده‌ها یا صدها کتابخانه متن‌باز، بسته تجاری، چارچوب نرم‌افزاری، تصویر کانتینر و سرویس خارجی استفاده کند. این وابستگی‌ها سرعت توسعه را افزایش می‌دهند، اما هم‌زمان سطح حمله و ریسک زنجیره تأمین نرم‌افزار را نیز گسترش می‌دهند.فرض کنید یک آسیب‌پذیری بحرانی مانند Log4Shell منتشر می‌شود. اولین پرسش مدیر امنیت این است: «آیا از مؤلفه آسیب‌پذیر Log4j استفاده می‌کنیم؟» پاسخ‌دادن به این پرسش در سازمانی با صدها سامانه، بدون داشتن فهرست دقیق اجزای نرم‌افزاری، ممکن است روزها یا هفته‌ها زمان ببرد. Software Bill of Materials یا SBOM برای حل همین مسئله مطرح شده است.SBOM را می‌توان «صورت‌مواد نرم‌افزار» یا «فهرست اجزای تشکیل‌دهنده نرم‌افزار» دانست. همان‌طور که برچسب یک محصول غذایی مواد تشکیل‌دهنده آن را مشخص می‌کند، SBOM نیز نشان می‌دهد یک محصول نرم‌افزاری از چه مؤلفه‌ها، نسخه‌ها و وابستگی‌هایی ساخته شده است. CycloneDX و SPDX دو استاندارد مهم برای تولید، تبادل و پردازش این اطلاعات هستند.SBOM دقیقاً چیست؟SBOM یک سند ساخت‌یافته و ماشین‌خوان است که اجزای تشکیل‌دهنده یک نرم‌افزار و روابط میان آن‌ها را ثبت می‌کند. این سند می‌تواند شامل موارد زیر باشد:* نام و نسخه هر مؤلفه* تولیدکننده یا تأمین‌کننده مؤلفه* کتابخانه‌ها و بسته‌های متن‌باز یا تجاری* وابستگی‌های مستقیم و غیرمستقیم* مجوزهای نرم‌افزاری* شناسه‌هایی مانند Package URL یا PURL و CPE* هش رمزنگاری فایل‌ها و بسته‌ها* منشأ یا سابقه تولید مؤلفه* زمان و ابزار تولید SBOM* اطلاعات آسیب‌پذیری یا وضعیت تأثیرپذیری* روابط میان نرم‌افزار، سرویس‌ها، تصاویر کانتینر و سایر دارایی‌هابرای مثال، ممکن است یک برنامه مستقیماً از یک کتابخانه احراز هویت استفاده کند، اما همان کتابخانه به چند بسته دیگر وابسته باشد. این بسته‌های غیرمستقیم نیز می‌توانند آسیب‌پذیر باشند. بنابراین یک SBOM مناسب نباید فقط وابستگی‌های سطح اول را نشان دهد؛ بلکه تا حد امکان باید ساختار وابستگی‌های انتقالی را نیز ثبت کند.نکته مهم این است که SBOM به‌تنهایی ابزار اسکن آسیب‌پذیری نیست. وجود نام یک مؤلفه در SBOM الزاماً به معنی آسیب‌پذیربودن محصول نیست. SBOM اطلاعات پایه را فراهم می‌کند تا ابزارهای تحلیل ترکیب نرم‌افزار، سامانه‌های مدیریت آسیب‌پذیری و تیم‌های SOC بتوانند آن را با پایگاه‌های اطلاعاتی CVE و سایر منابع اطلاعات تهدید مقایسه کنند.چرا سازمان‌ها به SBOM نیاز دارند؟اولین کاربرد SBOM ایجاد شفافیت است. بسیاری از سازمان‌ها می‌دانند چه برنامه‌هایی دارند، اما نمی‌دانند در داخل آن برنامه‌ها چه کتابخانه‌ها و بسته‌هایی استفاده شده است. این وضعیت مانند آن است که سازمان فهرست ساختمان‌های خود را داشته باشد، اما از تجهیزات و مواد موجود در آن‌ها اطلاعی نداشته باشد.کاربرد دوم، پاسخ سریع به آسیب‌پذیری‌هاست. هنگامی که یک CVE جدید منتشر می‌شود، سازمان می‌تواند مخزن SBOMهای خود را جست‌وجو کند و مشخص سازد کدام محصولات احتمالاً از مؤلفه آسیب‌پذیر استفاده کرده‌اند. این قابلیت زمان تحلیل اثر را از چند روز به چند دقیقه کاهش می‌دهد.کاربرد سوم، مدیریت ریسک تأمین‌کنندگان است. سازمان می‌تواند در قراردادهای خرید نرم‌افزار از پیمانکار یا فروشنده بخواهد برای هر نسخه محصول، SBOM معتبر تحویل دهد. در این حالت، SBOM یکی از اقلام تحویلی امنیتی محصول خواهد بود و امکان ارزیابی وابستگی‌ها، مجوزها و ریسک‌های محصول را فراهم می‌کند.SBOM در مدیریت مجوزهای نرم‌افزاری نیز اهمیت دارد. استفاده ناخواسته از بسته‌ای با مجوز ناسازگار می‌تواند برای سازمان تبعات حقوقی و مالی ایجاد کند. علاوه بر این، SBOM به تیم پاسخ‌گویی به رخداد، مدیریت تغییر، انطباق، ممیزی و DevSecOps کمک می‌کند.استاندارد CycloneDXCycloneDX یک استاندارد باز برای نمایش اطلاعات زنجیره تأمین است که فعالیت آن با تمرکز جدی بر امنیت نرم‌افزار و اکوسیستم OWASP آغاز شد. این استاندارد به‌گونه‌ای طراحی شده است که بتواند اجزای نرم‌افزار، سخت‌افزار، سرویس‌ها، وابستگی‌ها، آسیب‌پذیری‌ها و اطلاعات مرتبط با قابلیت بهره‌برداری از آسیب‌پذیری را نمایش دهد.نسخه جاری معرفی‌شده در مستندات رسمی، CycloneDX 1.7 است. این استاندارد علاوه بر پروژه OWASP، به‌عنوان استاندارد ECMA-424 نیز توسعه یافته و قالب‌های JSON، XML و Protocol Buffers را پشتیبانی می‌کند. مدل آن ماژولار و توسعه‌پذیر است و می‌تواند اطلاعات مربوط به نرم‌افزار، سخت‌افزار، مدل‌های یادگیری ماشین، تنظیمات عملیاتی، سرویس‌ها و وابستگی‌های آن‌ها را ثبت کند.یکی از نقاط قوت CycloneDX، تناسب آن با فرایندهای DevSecOps است. سازمان می‌تواند هنگام Build یا Release، به‌صورت خودکار SBOM تولید کند و آن را همراه محصول یا در یک مخزن مرکزی نگه دارد. سپس سامانه‌هایی مانند Dependency-Track می‌توانند این اطلاعات را دریافت کرده و وابستگی‌ها را به‌صورت پیوسته از نظر آسیب‌پذیری بررسی کنند.CycloneDX فقط نام و نسخه کتابخانه‌ها را نمایش نمی‌دهد. این استاندارد قابلیت ثبت گراف وابستگی‌ها، سرویس‌های خارجی، APIها، نقاط پایانی، روش‌های احراز هویت، مرزهای اعتماد، طبقه‌بندی داده و جریان اطلاعات را نیز دارد. این قابلیت‌ها برای تحلیل معماری و تهدید اهمیت زیادی دارند.قابلیت مهم دیگر CycloneDX پشتیبانی از VEX یا Vulnerability Exploitability eXchange است. VEX مشخص می‌کند آیا یک محصول واقعاً تحت تأثیر یک آسیب‌پذیری شناخته‌شده قرار دارد یا خیر. ممکن است یک کتابخانه آسیب‌پذیر در محصول وجود داشته باشد، اما تابع آسیب‌پذیر آن فراخوانی نشود یا کنترل‌های جبرانی مانع بهره‌برداری باشند. VEX اجازه می‌دهد تولیدکننده وضعیت‌هایی مانند «تأثیرپذیر»، «تأثیرناپذیر»، «در حال بررسی» یا «اصلاح‌شده» را همراه با دلیل اعلام کند.استاندارد SPDXSPDX مخفف Software Package Data Exchange است. این استاندارد در ابتدا با تمرکز بر شناسایی بسته‌های نرم‌افزاری، مجوزهای متن‌باز، حقوق مالکیت و تبادل اطلاعات مربوط به انطباق مجوزها شکل گرفت. SPDX تحت حمایت Linux Foundation توسعه یافته و به استاندارد بین‌المللی ISO/IEC 5962:2021 تبدیل شده است.نسخه جاری معرفی‌شده در وب‌سایت رسمی SPDX، نسخه 3.0 است. معماری این نسخه نسبت به نسل‌های قبلی توسعه یافته و حوزه‌هایی مانند نرم‌افزار، امنیت، سرویس‌ها، زنجیره تأمین، سخت‌افزار، داده، هوش مصنوعی، فرایند Build و مجوزها را پوشش می‌دهد. بنابراین نباید SPDX را صرفاً یک قالب مدیریت مجوز دانست، هرچند مدیریت مجوز و مالکیت همچنان یکی از نقاط قوت اصلی آن است.SPDX می‌تواند اطلاعات بسته، فایل، نسخه، هش، پدیدآورنده، تأمین‌کننده، مجوز اعلام‌شده، مجوز شناسایی‌شده، حق تکثیر و روابط میان اجزا را ثبت کند. فهرست استاندارد شناسه‌های مجوز SPDX نیز باعث شده است ابزارها و سازمان‌های مختلف بتوانند مجوزهای نرم‌افزاری را با نام‌گذاری یکسان بیان کنند.برای نمونه، به‌جای اینکه یک ابزار از عبارت «Apache License Version 2» و ابزار دیگر از عبارت «Apache 2» استفاده کند، هر دو می‌توانند شناسه استاندارد Apache-2.0 را به کار ببرند. این استانداردسازی، پردازش خودکار و کنترل سازگاری مجوزها را ساده‌تر می‌کند.SPDX برای سازمان‌هایی که علاوه بر امنیت، نگرانی جدی درباره مالکیت فکری، استفاده از متن‌باز، تعهدات توزیع و انطباق حقوقی دارند، انتخاب مهمی است. شرکت‌های تولیدکننده نرم‌افزار، تجهیزات و محصولات توکار می‌توانند از آن برای مستندسازی ترکیب محصول و اثبات فرایندهای Due Diligence استفاده کنند.مقایسه CycloneDX و SPDXتفاوت این دو استاندارد را نباید با این عبارت ساده‌سازی کرد که «CycloneDX برای امنیت است و SPDX فقط برای مجوزهای نرم‌افزاری». هر دو استاندارد اکنون قابلیت‌های گسترده‌ای برای مدیریت زنجیره تأمین نرم‌افزار دارند؛ اما پیشینه، نقاط تمرکز و اکوسیستم ابزارهای آن‌ها متفاوت است.CycloneDX با محوریت امنیت نرم‌افزار و در اکوسیستم OWASP شکل گرفته و اکنون با استاندارد ECMA-424 شناخته می‌شود. تمرکز سنتی آن بر شناسایی مؤلفه‌ها، نمایش وابستگی‌های مستقیم و انتقالی، ثبت آسیب‌پذیری‌ها و یکپارچگی با فرایندهای DevSecOps است. این استاندارد از قالب‌های JSON، XML و Protobuf پشتیبانی می‌کند و استفاده از آن در خطوط CI/CD، سامانه‌های مدیریت آسیب‌پذیری و عملیات امنیت بسیار رایج است.یکی از نقاط قوت CycloneDX، پشتیبانی یکپارچه از VEX است. VEX مشخص می‌کند که آیا یک محصول عملاً تحت تأثیر آسیب‌پذیری ثبت‌شده در یکی از اجزای خود قرار دارد یا خیر. به همین دلیل، CycloneDX برای تیم‌های SOC، DevSecOps و مدیریت آسیب‌پذیری انتخاب مناسبی محسوب می‌شود.در مقابل، SPDX با حمایت Linux Foundation و با تمرکز اولیه بر نرم‌افزارهای متن‌باز، مجوزها، حقوق مالکیت فکری و انطباق توسعه یافته است. این استاندارد با عنوان ISO/IEC 5962:2021 به رسمیت شناخته شده و در تبادل رسمی اطلاعات بسته‌های نرم‌افزاری، ثبت مجوزها و مدیریت تعهدات حقوقی کاربرد گسترده‌ای دارد. SPDX نیز قابلیت ثبت اطلاعات امنیتی و زنجیره تأمین را دارد و در نسخه‌های جدید، حوزه‌هایی مانند امنیت، سرویس‌ها، داده، سخت‌افزار و هوش مصنوعی را پوشش می‌دهد.بنابراین، انتخاب میان این دو باید براساس نیاز سازمان انجام شود. اگر هدف اصلی تحلیل امنیتی، پایش مؤلفه‌ها، یکپارچه‌سازی با سامانه‌های مدیریت آسیب‌پذیری و استفاده از VEX باشد، CycloneDX معمولاً انتخاب طبیعی‌تری است. اگر مدیریت مجوزها، مالکیت فکری، انطباق حقوقی و تبادل اطلاعات میان تأمین‌کنندگان اولویت داشته باشد، SPDX مزیت برجسته‌تری دارد. سازمان‌های بزرگ نیز می‌توانند هر دو استاندارد را بپذیرند یا اطلاعات را با استفاده از ابزارهای مناسب میان آن‌ها تبدیل کنند.ارتباط SBOM با SCA، اسکن آسیب‌پذیری و VEXSBOM با Software Composition Analysis یا SCA مرتبط است، اما این دو یکسان نیستند. SCA فرایند یا ابزاری است که کد، فایل‌های Build، بسته‌ها یا تصاویر کانتینر را بررسی می‌کند تا مؤلفه‌های متن‌باز، مجوزها و آسیب‌پذیری‌ها را شناسایی کند. خروجی یک ابزار SCA می‌تواند یک SBOM در قالب CycloneDX یا SPDX باشد.اسکن آسیب‌پذیری نیز SBOM نیست. اسکنر، دارایی یا مؤلفه را با اطلاعات آسیب‌پذیری مقایسه می‌کند؛ درحالی‌که SBOM موجودی و روابط مؤلفه‌ها را ارائه می‌دهد. به بیان ساده، SBOM می‌گوید «چه چیزی داریم»، پایگاه CVE می‌گوید «چه مشکلی شناخته شده است» و ابزار مدیریت آسیب‌پذیری مشخص می‌کند «کدام مشکل در کدام دارایی وجود دارد».VEX نیز مکمل SBOM است. SBOM ممکن است نشان دهد نسخه‌ای آسیب‌پذیر از یک کتابخانه در محصول وجود دارد، اما VEX توضیح می‌دهد آیا شرایط بهره‌برداری از آسیب‌پذیری در آن محصول وجود دارد یا خیر. این تفکیک به کاهش هشدارهای کاذب و اولویت‌بندی بهتر اصلاحات کمک می‌کند.کاربرد SBOM برای SOC و مدیریت امنیتدر یک SOC بالغ، SBOM می‌تواند بخشی از فرایند مدیریت تهدید و رخداد باشد. برای مثال، پس از انتشار یک آسیب‌پذیری بحرانی، تیم اطلاعات تهدید شناسه مؤلفه و نسخه‌های آسیب‌پذیر را استخراج می‌کند. سپس مخزن SBOM جست‌وجو می‌شود تا برنامه‌های وابسته شناسایی شوند. نتایج براساس اهمیت کسب‌وکاری سامانه، مواجهه با اینترنت، امکان بهره‌برداری، وجود کنترل جبرانی و اطلاعات VEX اولویت‌بندی می‌شوند.در مرحله بعد، تیکت اصلاح برای مالک سامانه ایجاد می‌شود و SOC می‌تواند تا زمان نصب وصله، قواعد تشخیص، محدودسازی دسترسی یا پایش ویژه تعریف کند. در این مدل، SBOM حلقه ارتباط میان توسعه، عملیات، مدیریت آسیب‌پذیری و SOC است.از منظر CISSP، این موضوع با چند قلمرو دانشی ارتباط دارد: مدیریت دارایی، امنیت توسعه نرم‌افزار، مدیریت ریسک تأمین‌کننده، مدیریت آسیب‌پذیری، پاسخ‌گویی به رخداد، کنترل تغییر و انطباق. دریافت SBOM از فروشنده نمونه‌ای از Due Diligence است و پایش مداوم آن می‌تواند بخشی از Due Care سازمان باشد.محدودیت‌ها و ریسک‌های SBOMداشتن SBOM به‌تنهایی امنیت ایجاد نمی‌کند. اگر SBOM ناقص، قدیمی یا نادرست باشد، تصمیم‌های مبتنی بر آن نیز اشتباه خواهند بود. مهم‌ترین چالش، کامل‌بودن فهرست وابستگی‌های انتقالی و مؤلفه‌هایی است که در زمان اجرا یا از مخازن خارجی بارگذاری می‌شوند.مشکل دیگر، تفاوت نام‌گذاری مؤلفه‌هاست. ممکن است یک بسته با چند نام یا شناسه ثبت شود و ارتباط آن با CVE به‌درستی برقرار نشود. استفاده از شناسه‌هایی مانند PURL، هش و CPE می‌تواند این مشکل را کاهش دهد.SBOM ممکن است اطلاعات حساس معماری را نیز افشا کند. مهاجم با مشاهده نسخه‌ها و وابستگی‌ها می‌تواند اهداف مناسب‌تری انتخاب کند. بنابراین دسترسی به SBOM باید براساس طبقه‌بندی اطلاعات، نیاز کاری و مفاد قرارداد کنترل شود.اصالت و تمامیت SBOM نیز مهم است. اگر فروشنده بتواند سند را بدون امکان تشخیص تغییر دهد، اعتماد به آن محدود خواهد بود. امضای دیجیتال، ثبت منشأ، تولید خودکار در خط Build و نگهداری در مخزن کنترل‌شده می‌تواند قابلیت اعتماد را افزایش دهد.نقشه راه پیشنهادی پیاده‌سازیسازمان ابتدا باید دامنه و مالکیت فرایند را تعیین کند. بهتر است کار با سامانه‌های حیاتی، اینترنتی و محصولات تأمین‌کنندگان پرریسک آغاز شود. سپس یک سیاست مشخص شود که چه محصولاتی باید SBOM داشته باشند، چه قالب‌هایی پذیرفته می‌شوند و برای هر نسخه محصول چه زمانی باید سند جدید تولید شود.در مرحله بعد، تولید SBOM باید در CI/CD یا فرایند Build خودکار شود. تولید دستی معمولاً باعث قدیمی‌شدن و خطای انسانی می‌شود. SBOM تولیدشده باید اعتبارسنجی، امضا و در مخزن مرکزی ثبت شود و با CMDB، سامانه مدیریت آسیب‌پذیری، SOC و فرایند خرید ارتباط داشته باشد.برای تأمین‌کنندگان نیز باید الزامات قراردادی تعریف شود؛ از جمله قالب، حداقل فیلدها، پوشش وابستگی‌های انتقالی، زمان تحویل، الزام به به‌روزرسانی، اعلام آسیب‌پذیری و ارائه VEX.شاخص‌های مناسب برای سنجش بلوغ این برنامه عبارت‌اند از:* درصد سامانه‌های حیاتی دارای SBOM معتبر* میزان تازگی SBOMها* درصد پوشش وابستگی‌های مستقیم و انتقالی* زمان لازم برای تحلیل اثر یک CVE جدید* درصد تأمین‌کنندگان منطبق با الزامات* تعداد مؤلفه‌های آسیب‌پذیر حل‌نشده* درصد SBOMهای امضاشده و اعتبارسنجی‌شدهجمع‌بندیSBOM صرفاً یک فایل یا الزام قراردادی نیست؛ بلکه زیرساخت اطلاعاتی تصمیم‌گیری درباره ریسک نرم‌افزار است. این سند به سازمان اجازه می‌دهد اجزای پنهان محصولات را بشناسد، اثر آسیب‌پذیری‌های جدید را سریع‌تر تحلیل کند، ریسک تأمین‌کنندگان را بسنجد و انطباق امنیتی و حقوقی را بهبود دهد.CycloneDX و SPDX دو رویکرد رقیب و درعین‌حال مکمل برای استانداردسازی این اطلاعات هستند. CycloneDX با اکوسیستم امنیت، DevSecOps، VEX و پایش وابستگی‌ها پیوند نزدیکی دارد؛ درحالی‌که SPDX در حوزه مجوزها، مالکیت فکری و تبادل رسمی اطلاعات سابقه و قدرت ویژه‌ای دارد. بااین‌حال، هر دو استاندارد اکنون دامنه‌ای فراتر از خاستگاه اولیه خود پیدا کرده‌اند.ارزش واقعی SBOM زمانی ایجاد می‌شود که تولید آن خودکار، اطلاعاتش به‌روز و قابل اعتماد، و خروجی آن به فرایندهای عملیاتی متصل باشد. SBOM بدون پایش، تحلیل، VEX و فرایند اصلاح، تنها یک موجودی ایستا است؛ اما SBOM یکپارچه با SOC، CI/CD، مدیریت آسیب‌پذیری و مدیریت تأمین‌کننده می‌تواند به یکی از پایه‌های اصلی امنیت زنجیره تأمین نرم‌افزار تبدیل شود.** دوره CISSP آکادمی روزبه و شرکت هامون روزبه نوروزیروزبه نوروزیMon, 21 Sep 2026 11:45:21 +0330https://virgool.ir/@roozbehnoroozi/چرا-risk-based-alerting-در-splunk-enterprise-security-ایجاد-شد-rtzrdc35qqy0یکی از بزرگ‌ترین مشکلات مراکز عملیات امنیت، کمبود هشدار نیست؛ بلکه تولید بیش‌ازحد هشدارهایی است که بسیاری از آن‌ها به‌تنهایی ارزش عملیاتی چندانی ندارند. در معماری سنتی SIEM، هر Correlation Search در صورت مشاهده یک رفتار مشکوک می‌تواند مستقیماً یک Alert یا Notable Event ایجاد کند. در نتیجه، تحلیلگر SOC با تعداد زیادی هشدار روبه‌رو می‌شود که هرکدام فقط بخش کوچکی از رفتار مهاجم را نشان می‌دهند.یک ورود ناموفق، اجرای PowerShell، اتصال به یک IP ناشناس، ایجاد Process جدید یا تغییر Registry ممکن است به‌تنهایی حمله محسوب نشود. بااین‌حال، اگر برای تمام این رفتارها هشدار مستقل ساخته شود، صف کاری تحلیلگران به‌سرعت شلوغ خواهد شد. پیامد چنین وضعیتی Alert Fatigue، افزایش زمان بررسی، نادیده‌ماندن هشدارهای مهم و کاهش اعتماد تحلیلگران به سامانه SIEM است.Splunk برای پاسخ به این مسئله، رویکرد Risk-Based Alerting یا RBA را توسعه داد. فلسفه اصلی RBA این است که هر رفتار مشکوک نباید فوراً به یک هشدار قابل‌رسیدگی تبدیل شود. رفتارهای مشکوک ابتدا باید به موجودیت مرتبط با خود نسبت داده شوند، امتیاز ریسک دریافت کنند و در طول زمان در کنار یکدیگر قرار گیرند. هنگامی که مجموعه این رفتارها سطح معنی‌داری از ریسک را ایجاد کرد، Splunk یک Finding یا هشدار با اطمینان بیشتر تولید می‌کند.مشکل مدل سنتی Alertingدر مدل سنتی، منطق بسیاری از Detectionها حالتی دودویی دارد: اگر شرط برقرار شد، Alert ایجاد شود و اگر برقرار نشد، هیچ اقدامی صورت نگیرد. برای مثال، اگر PowerShell با پارامتر رمزگذاری‌شده اجرا شد، یک Notable Event ساخته می‌شود.اما در دنیای واقعی، استفاده از PowerShell الزاماً مخرب نیست. مدیران سیستم، ابزارهای مدیریتی و نرم‌افزارهای سازمانی نیز ممکن است از آن استفاده کنند. بنابراین تحلیلگر باید هر بار هشدار را باز کند، اطلاعات جانبی را به دست آورد و مشروع یا مخرب‌بودن فعالیت را تعیین کند.از طرف دیگر، مهاجمان حرفه‌ای معمولاً در یک رویداد آشکار نمی‌شوند. آن‌ها مجموعه‌ای از اقدامات نسبتاً ضعیف، پراکنده و گاهی مشروع‌نما انجام می‌دهند. ممکن است مهاجم ابتدا از یک کشور غیرمعمول وارد حساب شود، سپس PowerShell اجرا کند، اطلاعات Active Directory را جمع‌آوری کند و در نهایت به یک سرور حساس متصل شود. هر رفتار به‌تنهایی ممکن است برای اعلام Incident کافی نباشد، اما ترکیب آن‌ها داستان متفاوتی را نشان می‌دهد.تغییر تمرکز از Alert به EntityRBA تمرکز را از «رویداد مشکوک» به «موجودیت در معرض ریسک» منتقل می‌کند. این موجودیت که در Splunk با مفاهیمی مانند Entity یا Risk Object شناخته می‌شود، می‌تواند یک کاربر، سیستم، سرور، IP، حساب سرویس یا دارایی دیگر باشد.وقتی Detection یک رفتار مشکوک را شناسایی می‌کند، به‌جای اینکه الزاماً یک هشدار نهایی بسازد، امتیازی به موجودیت مرتبط اختصاص می‌دهد. برای مثال:* ورود از موقعیت جغرافیایی غیرمعمول: ۲۰ امتیاز* اجرای PowerShell رمزگذاری‌شده: ۳۰ امتیاز* دسترسی غیرعادی به فایل حساس: ۲۵ امتیاز* غیرفعال‌کردن EDR: ۵۰ امتیازاگر تمام این رفتارها به کاربر Ali یا سیستم PC-21 مربوط باشند، امتیازات و شواهد پیرامون همان موجودیت تجمیع می‌شوند. اکنون تحلیلگر با چهار هشدار جداگانه و بدون ارتباط روبه‌رو نیست؛ بلکه یک موجودیت را مشاهده می‌کند که چند رفتار مشکوک مرتبط انجام داده و ریسک آن به سطح قابل‌توجهی رسیده است.این تغییر نگرش بسیار مهم است. مهاجم ممکن است ابزار، IP، روش اجرا یا بدافزار خود را تغییر دهد، اما برای رسیدن به هدف مجبور است روی هویت‌ها، سیستم‌ها و داده‌های سازمان اثر بگذارد. RBA تلاش می‌کند همین اثر تجمعی را آشکار کند.Intermediate Finding چیست؟در نسخه‌های جدید Splunk ES، نتایج اولیه Detectionهای مبتنی بر ریسک معمولاً به‌صورت Intermediate Finding ثبت می‌شوند. Intermediate Finding را می‌توان یک «قطعه شواهد» دانست؛ یعنی رفتاری که مشکوک است، اما شاید به‌تنهایی برای اعلام یک حادثه امنیتی کافی نباشد.این یافته‌ها همراه با اطلاعاتی مانند Entity، نوع Entity، Risk Score، Detection، زمان وقوع و نگاشت MITRE ATT&CK ثبت می‌شوند. Finding-Based Detection می‌تواند این یافته‌های میانی را در یک بازه زمانی تجمیع کند. اگر شرایطی مانند عبور مجموع Risk Score از یک آستانه، وقوع چند تکنیک متفاوت یا مشارکت یک دارایی حساس برقرار شود، Finding مهم‌تری برای بررسی تحلیلگر ساخته خواهد شد.بنابراین، RBA Detectionهای کوچک را حذف نمی‌کند؛ بلکه نقش آن‌ها را تغییر می‌دهد. آن‌ها به‌جای ایجاد مستقیم صدها هشدار، شواهدی تولید می‌کنند که در کنار یکدیگر تصویر حمله را کامل می‌سازند.کاهش Alert Fatigue و افزایش Fidelityیکی از اهداف اصلی RBA کاهش تعداد Alertهایی است که مستقیماً وارد Analyst Queue می‌شوند. البته کاهش تعداد هشدار نباید با کاهش قابلیت کشف اشتباه گرفته شود. RBA می‌تواند تعداد بیشتری از رفتارهای ضعیف را ثبت کند، بدون آنکه برای هرکدام Ticket یا Incident مستقلی بسازد.برای مثال، یک Detection با False Positive نسبتاً زیاد شاید در مدل سنتی غیرفعال شود؛ زیرا صف SOC را شلوغ می‌کند. در RBA همان Detection می‌تواند با Risk Score پایین فعال باقی بماند. اگر رفتار موردنظر در کنار فعالیت‌های مشکوک دیگر قرار گرفت، ارزش آن افزایش پیدا می‌کند. در نتیجه، داده کشف از بین نمی‌رود، اما تحلیلگر فقط زمانی درگیر می‌شود که مجموعه شواهد به سطح معنی‌داری رسیده باشد.به این ترتیب، Fidelity هشدار نهایی افزایش می‌یابد. منظور از Fidelity، میزان اعتمادپذیری و قابلیت اقدام روی هشدار است. Finding حاصل از چند رفتار مرتبط معمولاً نسبت به Alert حاصل از یک رویداد منفرد، زمینه و اعتبار بیشتری دارد.واردکردن اهمیت دارایی و هویت در Detectionشدت فنی یک رویداد همیشه برابر با ریسک تجاری آن نیست. اجرای یک ابزار مدیریتی روی سیستم آزمایشگاهی با اجرای همان ابزار روی Domain Controller یا سرور مالی ارزش یکسانی ندارد. همچنین رفتار مشکوک یک کاربر عادی با رفتار مشابه مدیر دامنه نباید به یک شکل اولویت‌بندی شود.RBA اجازه می‌دهد اطلاعات Asset و Identity، حساسیت سیستم، سطح دسترسی کاربر و سایر عوامل زمینه‌ای در ارزیابی ریسک مؤثر باشند. Risk Factorها می‌توانند امتیاز یک رفتار را براساس Context افزایش یا کاهش دهند. بنابراین، اولویت‌بندی از شدت فنی صرف فاصله می‌گیرد و به ریسک واقعی سازمان نزدیک‌تر می‌شود.Risk Score احتمال حمله نیستیک اشتباه رایج این است که Risk Score را معادل درصد احتمال حمله بدانیم. امتیاز ۸۰ به این معنا نیست که با احتمال ۸۰ درصد حمله رخ داده است. Risk Score یک معیار نسبی برای مقایسه، تجمیع و اولویت‌بندی موجودیت‌هاست.سازمان باید این امتیازات را براساس شدت رفتار، اطمینان Detection، ارزش دارایی، سطح دسترسی هویت و پیامد احتمالی تنظیم کند. اگر امتیازها بدون روش مشخص تعیین شوند، RBA به یک بازی عددی تبدیل خواهد شد. همچنین تعیین یک آستانه ثابت برای تمام کاربران، سیستم‌ها و سناریوها معمولاً طراحی مناسبی نیست.ارتباط RBA با Risk Timeline و Threat Topologyپس از جمع‌شدن Risk Eventها، ابزارهایی مانند Risk Timeline به تحلیلگر نشان می‌دهند که ریسک یک موجودیت در طول زمان چگونه افزایش یافته و چه رفتارهایی در شکل‌گیری آن نقش داشته‌اند.Threat Topology نیز ارتباط میان Entityهای مختلف و Threat Object مشترک را نمایش می‌دهد. برای مثال، ممکن است یک کاربر و چند سیستم با File Hash مخرب یکسان مرتبط باشند. این تصویر به تحلیلگر کمک می‌کند دامنه حادثه را سریع‌تر تشخیص دهد و متوجه شود یک تهدید از چه کاربران و سیستم‌هایی عبور کرده است.شرط موفقیت RBARBA صرفاً با فعال‌کردن چند قابلیت در Splunk موفق نمی‌شود. سازمان به Detectionهای معتبر، داده‌های نرمال‌شده، Asset and Identity Context، روش امتیازدهی مستند، بازه‌های زمانی مناسب و فرایند مستمر Tuning نیاز دارد.همچنین باید مشخص شود کدام رفتارها صرفاً Risk Event تولید می‌کنند و کدام رفتارهای قطعی، مانند غیرفعال‌کردن EDR روی یک سرور حیاتی، باید بدون انتظار برای تجمع امتیاز فوراً هشدار ایجاد کنند. بنابراین RBA جایگزین تمام هشدارهای قطعی نیست؛ بلکه مکمل آن‌ها و روشی برای مدیریت رفتارهای مبهم و چندمرحله‌ای است.در نهایت، RBA ایجاد شد تا SIEM از یک «کارخانه تولید Alert» به سامانه‌ای برای بازسازی، اولویت‌بندی و روایت داستان حمله تبدیل شود. ارزش واقعی آن در جمع‌کردن شواهد ضعیف، افزودن Context و تمرکز تحلیلگر بر موجودیت‌هایی است که رفتارهای متعدد و معناداری از خود نشان داده‌اند.بهترین توصیف برای RBA شاید این باشد:هر رفتار مشکوک یک Incident نیست؛ اما هر رفتار مشکوک می‌تواند قطعه‌ای از پازل یک Incident باشد.روزبه نوروزیروزبه نوروزیSun, 06 Sep 2026 22:40:38 +0330https://virgool.ir/@roozbehnoroozi/کشف-persistence-در-linux-چرا-cron-و-systemd-باید-زیر-ذره-بین-soc-باشند-imb9d4hwvaiqیکی از اشتباهات رایج در Incident Response این است که تصور کنیم با متوقف کردن یک Process مخرب، حادثه پایان یافته است. فرض کنید روی یک Linux Server پردازشی ناشناس مشاهده می‌شود که به یک IP خارجی متصل است. تیم SOC پردازش را Kill می‌کند، فایل مخرب را حذف می‌کند و حتی Password حساب کاربری را تغییر می‌دهد. چند دقیقه یا چند ساعت بعد، همان Process دوباره ظاهر می‌شود.در چنین شرایطی سؤال مهم دیگر این نیست که «این Process چیست؟» بلکه باید پرسید:چه چیزی این Process را دوباره اجرا کرده است؟اینجاست که مفهوم Persistence اهمیت پیدا می‌کند.Persistence مجموعه تکنیک‌هایی است که مهاجم برای حفظ دسترسی خود پس از Restart، Logout، تغییر Password، متوقف شدن Process یا حتی بخشی از اقدامات Incident Response استفاده می‌کند.در Linux، مهاجم الزاماً به Rootkit پیچیده نیاز ندارد. بسیاری از قابلیت‌هایی که مدیران سیستم برای Automation استفاده می‌کنند، می‌توانند برای Persistence نیز مورد سوءاستفاده قرار گیرند. دو نمونه بسیار مهم آن‌ها Cron و systemd هستند.چرا ابزارهای قانونی برای مهاجم جذاب‌اند؟یکی از اصول مهم Detection Engineering این است که ابزار مورد استفاده مهاجم الزاماً مخرب نیست.Cron برای اجرای زمان‌بندی‌شده وظایف طراحی شده است. Backup، پاک‌سازی فایل‌های موقت، اجرای اسکریپت‌های مدیریتی و بسیاری از فعالیت‌های روزمره با Cron انجام می‌شوند.systemd نیز در بسیاری از توزیع‌های جدید Linux مسئول مدیریت Serviceها، Timerها و بخش مهمی از Startup سیستم است.مشکل زمانی ایجاد می‌شود که مهاجم از همین امکانات قانونی برای اجرای Payload استفاده کند.برای مثال مهاجم می‌تواند کاری کند که یک اسکریپت مخرب هر پنج دقیقه اجرا شود. حتی اگر تحلیلگر Process مربوط به Malware را متوقف کند، Cron چند دقیقه بعد آن را دوباره اجرا خواهد کرد.در systemd نیز مهاجم می‌تواند Serviceای ایجاد کند که هنگام Boot اجرا شود یا در صورت متوقف شدن Process، مجدداً آن را راه‌اندازی کند.بنابراین:Malware Process → Killلزوماً به معنی پایان Incident نیست.ممکن است زنجیره واقعی این باشد:Cron/systemd → Script → Malware → Network Connectionاگر فقط آخرین حلقه زنجیره حذف شود، Persistence همچنان باقی مانده است.اولین محل بررسی: systemd Servicesدر Incident Response یکی از اولین اقدامات می‌تواند بررسی Serviceهای موجود باشد.برای مشاهده Unit Fileهای مربوط به Serviceها می‌توان از دستور زیر استفاده کرد:systemctl list-unit-files --type=serviceاما وجود یک Service ناشناس به تنهایی اثبات‌کننده حمله نیست. سرورهای Production معمولاً تعداد زیادی Service متعلق به Applicationها، Agentهای Monitoring، Backup، Security و ابزارهای مدیریتی دارند.اگر Service مشکوکی پیدا شد، باید محتوای واقعی آن بررسی شود:systemctl status suspicious.serviceو سپس:systemctl cat suspicious.serviceیکی از مهم‌ترین قسمت‌هایی که باید بررسی شود ExecStart است.ExecStart مشخص می‌کند Service در واقع چه Binary یا Scriptی را اجرا می‌کند.برای مثال ممکن است نام Service ظاهراً طبیعی باشد:system-update.serviceاما درون آن ببینیم:ExecStart=/tmp/.cache/updateاینجا نام Service اهمیت چندانی ندارد؛ Execution Path بسیار مهم‌تر است.اجرای Service از مسیرهایی مانند /tmp، /dev/shm یا Hidden Directoryهای غیرمعمول باید بررسی شود، زیرا این مسیرها معمولاً محل اجرای دائمی Serviceهای Production نیستند.اهمیت systemd Timerفقط Serviceها را نباید بررسی کرد. systemd قابلیت Timer نیز دارد که می‌تواند رفتاری مشابه Scheduled Task ایجاد کند.برای مشاهده Timerها می‌توان از دستور زیر استفاده کرد:systemctl list-timers --allفرض کنید یک Timer ناشناس هر سه دقیقه یک Service را اجرا می‌کند. تیم SOC Process ایجادشده را Kill می‌کند، اما Timer همچنان فعال است و چند دقیقه بعد Process دوباره ایجاد می‌شود.بنابراین در Investigation باید رابطه زیر را پیدا کنیم:Timer → Service → ExecStart → Script/Binary → Network Activityاین زنجیره برای Detection Engineering بسیار ارزشمندتر از مشاهده صرف یک Process است.Cron؛ Persistence ساده اما مؤثرCron یکی از قدیمی‌ترین و در عین حال مؤثرترین روش‌های Automation در Linux است.کاربر می‌تواند با دستور زیر Cron Jobهای خودش را مشاهده کند:crontab -lAdministrator نیز می‌تواند Cron Job کاربر دیگری را بررسی کند:crontab -u username -lاما بررسی فقط User Crontab کافی نیست. مسیرهای System-wide نیز باید بررسی شوند، از جمله/etc/crontab/etc/cron.d//etc/cron.daily//etc/cron.hourly//etc/cron.weekly//etc/cron.monthly/اگر یک Cron Job به Scriptی اشاره می‌کند، نباید فوراً آن Script را اجرا کرد. ابتدا باید محتوا و زنجیره اجرای آن بررسی شود.ممکن است Cron فقط یک Script را اجرا کند و آن Script نیز Binary دیگری را راه‌اندازی کند که در نهایت با زیرساخت مهاجم ارتباط برقرار می‌کند. بنابراین تحلیل باید تا انتهای Execution Chain ادامه پیدا کند.مشکل اصلی SOC: همه Cron Jobها مشکوک نیستنداینجا یکی از مهم‌ترین چالش‌های Detection Engineering ظاهر می‌شود.اگر برای هر Cron Job یا systemd Service یک Alert ایجاد کنیم، SOC با حجم بزرگی از False Positive مواجه خواهد شد.Backup Server ممکن است ده‌ها Scheduled Job داشته باشد. Database Server ممکن است مرتباً Maintenance Task اجرا کند. Monitoring Agent ممکن است Serviceهای خاص خودش را داشته باشد.بنابراین Detection نباید بر این منطق ساخته شود:Cron Exists → Alertبلکه بهتر است بگوییم:Cron/Systemd + Abnormal Context → Alertاین همان جایی است که Baseline اهمیت پیدا می‌کند.SOC باید بداند چه Serviceها، Timerها و Cron Jobهایی روی یک Server مشخص طبیعی هستند.چه رفتارهایی مشکوک‌تر هستند؟چند نشانه می‌توانند Risk Score را افزایش دهند:ایجاد Service جدیدی که قبلاً در Baseline وجود نداشته است؛Serviceای که Binary آن از /tmp یا /dev/shm اجرا می‌شود؛Cron Job جدید متعلق به Service Accountای که معمولاً Scheduled Task ندارد؛Timerای که با فاصله زمانی بسیار کوتاه اجرا می‌شود؛Serviceای که بلافاصله بعد از اجرا Connection خارجی ایجاد می‌کند؛تغییر غیرمنتظره در فایل‌های systemd یا Crontab؛اجرای Script یا Binary با Privilege بالا بدون توجیه عملیاتی.هیچ‌کدام از این موارد به تنهایی اثبات حمله نیستند، اما ترکیب چند مورد می‌تواند Detection بسیار قدرتمندی ایجاد کند.Detection Engineering برای Cron و systemdاز منظر SOC بهتر است به جای یک Rule، چند لایه Detection طراحی شود.Detection 1 – ایجاد یا تغییر systemd Unitمانیتور کردن تغییرات در مسیرهایی مانند:/etc/systemd/system/و سایر مسیرهای Unit File.اگر فایل Service جدیدی ایجاد شد، باید مشخص شود چه Process و Userای آن را ایجاد کرده است.Detection 2 – تغییر Cron Configurationتغییر فایل‌های Crontab یا ایجاد فایل جدید در /etc/cron.d/ می‌تواند Event مهمی باشد.باز هم Context تعیین‌کننده است. اگر تغییر توسط Configuration Management مورد تأیید انجام شده باشد طبیعی است؛ اما اگر Web Server Process باعث ایجاد Cron Job شده باشد، موضوع کاملاً متفاوت است.Detection 3 – اجرای Service از مسیر غیرعادییک Rule رفتاری می‌تواند بررسی کند:systemd → executable in /tmp or /dev/shmاین رفتار در بسیاری از محیط‌ها بسیار غیرمعمول است و ارزش Investigation بالایی دارد.Detection 4 – ارتباط شبکه‌ای پس از اجرای ServiceDetection قوی‌تر زمانی شکل می‌گیرد که Telemetryهای مختلف Correlate شوند:New systemd serviceNew ProcessOutbound Connectionاگر این سه رویداد در فاصله زمانی کوتاهی رخ دهند، احتمال فعالیت مخرب بسیار بیشتر می‌شود.File Integrity Monitoring چه کمکی می‌کند؟یکی از بهترین ابزارها برای کشف چنین تغییراتی File Integrity Monitoring یا FIM است.به جای اینکه تحلیلگر مرتباً مسیرهای Cron و systemd را بررسی کند، می‌توان تغییرات مسیرهای حساس را مانیتور کرد.برای مثال:/etc/systemd/system//etc/crontab/etc/cron.d/و سایر مسیرهای حساس.راهکارهایی مانند Wazuh، auditd و محصولات EDR می‌توانند بخشی از این Visibility را فراهم کنند.اما FIM به تنهایی کافی نیست.FIM می‌گوید«این فایل تغییر کرد.»Detection Engineering باید سؤال بعدی را پاسخ دهد:«چه کسی، با چه Processی، در چه زمانی و با چه نتیجه‌ای آن را تغییر داد؟»این تفاوت Monitoring ساده با Detection Engineering است.قبل از حذف Artifact، Evidence را حفظ کنیدیکی از نکات بسیار مهم Incident Response این است که به محض مشاهده Cron Job یا Service مشکوک آن را حذف نکنیم.ابتدا باید Evidence جمع‌آوری شود.برای مثال:مالک فایل چه کسی است؟Permission فایل چیست؟چه زمانی ایجاد یا تغییر کرده است؟Hash فایل چیست؟چه Commandی اجرا می‌شود؟آیا همین Hash روی Serverهای دیگری وجود دارد؟Service با چه Privilegeای اجرا می‌شود؟آیا Connection خارجی ایجاد کرده است؟برای مشاهده History یک Service نیز می‌توان از Journal استفاده کرد:journalctl -u suspicious.serviceاین اطلاعات می‌تواند برای ساخت Timeline حادثه بسیار مهم باشد.حذف سریع Artifact ممکن است بخشی از Evidence را از بین ببرد.Persistence معمولاً فقط یک Artifact نیستاگر مهاجم توانسته یک Root-owned systemd Service ایجاد کند، مسئله بسیار بزرگ‌تر از همان Service است.باید پرسید:مهاجم چگونه توانسته این Service را ایجاد کند؟ممکن است Credential سرقت شده باشد، Privilege Escalation رخ داده باشد یا آسیب‌پذیری دیگری مورد سوءاستفاده قرار گرفته باشد.بنابراین زنجیره Investigation می‌تواند چنین باشد:Initial AccessPrivilege EscalationPersistenceCommand ExecutionCommand & Controlاگر فقط Persistence حذف شود اما Initial Access همچنان باز باشد، مهاجم می‌تواند دوباره وارد سیستم شود.چرا حذف Persistence به معنی Recovery نیست؟فرض کنید SOC Cron Job مخرب را پیدا و حذف کرده است.آیا Incident تمام شده؟ خیر.Credentialهای در معرض خطر باید Rotate شوند. سیستم‌های دیگر باید برای Artifact مشابه بررسی شوند. Network Connectionها باید تحلیل شوند و Initial Access مشخص شود.اگر شواهد نشان دهد مهاجم Root Access داشته و تیم Incident Response نتواند با اطمینان مشخص کند چه تغییراتی انجام شده است، اعتماد به سیستم بسیار دشوار می‌شود.در چنین شرایطی، Rebuild کردن سیستم از یک Known-Good State ممکن است از پاک‌سازی دستی امن‌تر باشد.یک سناریوی Detection برای SOCفرض کنید روی یک Web Server لینوکسی، FIM ایجاد فایل زیر را گزارش می‌کند:/etc/systemd/system/update-check.serviceچند ثانیه بعد Service فعال می‌شود.EDR مشاهده می‌کند:systemd → /tmp/.updateو Process ایجادشده به یک IP اینترنتی روی Port 443 متصل می‌شود.هر Event به تنهایی شاید توضیحی داشته باشد، اما Correlation آن‌ها داستان متفاوتی ایجاد می‌کند:Systemd Unit CreationExecution from /tmpRoot ProcessOutbound ConnectionUnknown Destinationاینجا SIEM می‌تواند به جای تولید چهار Alert مستقل، یک Detection با Risk بالا ایجاد کند.این همان فلسفه Behavior-based Detection است.نتیجه‌گیریمهم‌ترین درس Persistence در Linux این است که مهاجم همیشه به Malware پیچیده نیاز ندارد. گاهی ابزارهایی که Administrator هر روز برای مدیریت سیستم استفاده می‌کند، بهترین ابزار مهاجم هستند.Cron، systemd Service و systemd Timer ذاتاً مخرب نیستند. آنچه اهمیت دارد Context، Baseline و Execution Chain است.SOC بالغ نباید فقط بپرسد«چه Process مخربی اجرا شده است؟»بلکه باید بپرسد:«چه چیزی باعث اجرای آن شده و اگر Process را Kill کنیم، چه چیزی آن را دوباره برمی‌گرداند؟»به همین دلیل Detection Persistence باید ترکیبی از Process Monitoring، File Integrity Monitoring، Audit Logs، systemd Journal، Network Telemetry و SIEM Correlation باشد.و شاید مهم‌ترین اصل Incident Response در این سناریو این باشد:Process را Kill کردن، Persistence را از بین نمی‌برد.تا زمانی که مکانیزم اجرای مجدد شناسایی نشده باشد، مهاجم ممکن است همچنان راه بازگشت داشته باشد.روزبه نوروزیروزبه نوروزیTue, 11 Aug 2026 13:54:13 +0330https://virgool.ir/@roozbehnoroozi/آشنایی-با-رشته-مهندسی-کشف-تهدید-x5sufdiqq1nqدرس Detection Engineering از CVE-2018-8440؛ چرا ALPC مهم‌تر از آن چیزی است که فکر می‌کنیم؟وقتی از مکانیزم‌های ارتباط بین پردازش‌ها (IPC) در ویندوز صحبت می‌شود، اغلب متخصصان امنیت به Named Pipe فکر می‌کنند. دلیل آن هم روشن است؛ Named Pipe در بسیاری از ابزارهای تهاجمی مانند Cobalt Strike، PsExec و برخی بدافزارها به‌کار می‌رود و Sysmon نیز رویدادهای مشخصی برای آن تولید می‌کند. اما در لایه‌های عمیق‌تر ویندوز، مکانیزم دیگری وجود دارد که کمتر دیده می‌شود و در عین حال نقشی حیاتی در عملکرد سیستم‌عامل دارد: Advanced Local Procedure Call (ALPC).ALPC کانال ارتباطی داخلی ویندوز برای تبادل پیام بین سرویس‌ها، پردازش‌های کاربری و حتی مؤلفه‌های کرنل است. بسیاری از سرویس‌های حیاتی ویندوز برای سرعت و کارایی بیشتر از ALPC استفاده می‌کنند. به همین دلیل، اگر در این مکانیزم نقصی امنیتی وجود داشته باشد، پیامد آن معمولاً بسیار جدی خواهد بود.یکی از مشهورترین نمونه‌های تاریخی، آسیب‌پذیری CVE-2018-8440 بود که در سال ۲۰۱۸ توسط پژوهشگری با نام مستعار SandboxEscaper افشا شد. این آسیب‌پذیری مربوط به نحوه تعامل Windows Task Scheduler با ALPC بود. مشکل اصلی این بود که یک کاربر با سطح دسترسی عادی می‌توانست از طریق فراخوانی‌های خاص ALPC، مجوزهای فایل‌های سیستمی را تغییر دهد و در نهایت کد خود را با سطح دسترسی SYSTEM اجرا کند. این یک نمونه کلاسیک از Local Privilege Escalation (LPE) بود؛ یعنی مهاجم پس از به‌دست آوردن دسترسی اولیه، بدون دانستن رمز عبور مدیر یا سوءاستفاده از آسیب‌پذیری کرنل، کنترل کامل سیستم را به دست می‌آورد.نکته جالب اینجاست که تنها چند روز پس از انتشار عمومی این آسیب‌پذیری، گروه مهاجمی با نام PowerPool آن را در حملات واقعی به کار گرفت. آن‌ها حتی از همان کد منتشرشده استفاده نکردند، بلکه نسخه اختصاصی خود را توسعه دادند. این اتفاق نشان داد که فاصله میان انتشار یک آسیب‌پذیری و تبدیل آن به سلاح عملیاتی می‌تواند بسیار کوتاه باشد.اما این مثال از دیدگاه Detection Engineering حتی از خود آسیب‌پذیری مهم‌تر است.بسیاری از تحلیلگران SOC هنگام شنیدن نام ALPC، اولین سؤالشان این است: کدام Event ID آن را نشان می‌دهد؟ پاسخ ناامیدکننده است؛ برخلاف Named Pipe که Sysmon برای ایجاد و اتصال Pipe رویدادهای مستقلی دارد، ALPC چنین لاگ مستقیمی تولید نمی‌کند. بنابراین اگر Detection Engineer بخواهد صرفاً بر اساس مشاهده ALPC حمله را کشف کند، تقریباً شکست خواهد خورد.اینجاست که فلسفه Detection Engineering تغییر می‌کند.Detection Engineer به جای تمرکز بر ابزار یا API، بر رفتار مهاجم تمرکز می‌کند. در سناریوی CVE-2018-8440، مهم نیست که مهاجم از ALPC استفاده کرده یا از مکانیزم دیگری؛ مهم این است که در پایان زنجیره حمله، رفتارهای غیرعادی رخ می‌دهد.برای مثال:یک پردازش با سطح دسترسی معمولی ناگهان باعث اجرای فرآیندی با سطح SYSTEM می‌شود.پردازش‌هایی مانند cmd.exe، powershell.exe یا rundll32.exe توسط یک فرآیند غیرمنتظره و با سطح SYSTEM اجرا می‌شوند.فایل‌ها یا تنظیمات مربوط به Task Scheduler به‌طور غیرعادی تغییر می‌کنند.زنجیره Parent-Child Process با الگوهای معمول ویندوز سازگار نیست.EDR تغییر ناگهانی Integrity Level یا Token را گزارش می‌کند.بنابراین Detection واقعی نه بر اساس مشاهده ALPC، بلکه بر اساس همبستگی چندین منبع داده انجام می‌شود. این همان تفاوت اساسی میان یک Rule ساده و یک Detection حرفه‌ای است.فرض کنید مهاجم از یک آسیب‌پذیری ALPC استفاده کرده است. اگر Rule شما فقط به دنبال API خاصی باشد، با تغییر نسخه ویندوز یا روش اکسپلویت احتمالاً دیگر کار نخواهد کرد. اما اگر Rule شما بر پایه رفتارهایی مانند ارتقای غیرمنتظره سطح دسترسی، ایجاد فرآیندهای SYSTEM، تغییرات حساس در فایل‌های سیستمی و زنجیره غیرعادی اجرای پردازش‌ها طراحی شده باشد، حتی اگر روش سوءاستفاده تغییر کند، Detection همچنان معتبر خواهد بود.این دقیقاً همان فلسفه‌ای است که امروز در Detection Engineering مدرن دنبال می‌شود؛ یعنی تشخیص رفتار، نه تشخیص ابزار.به همین دلیل در SOCهای بالغ، Detection Engineer تنها نویسنده Rule نیست. او ابتدا تکنیک مهاجم را مطالعه می‌کند، سپس Telemetryهای موجود را بررسی می‌کند، شکاف‌های مشاهده‌پذیری (Visibility Gaps) را شناسایی می‌کند و در نهایت Detectionهایی طراحی می‌کند که در برابر تغییر ابزار یا IOC مقاوم باشند.ماجرای CVE-2018-8440 یک درس مهم دیگر نیز دارد. بسیاری از سازمان‌ها تصور می‌کنند اگر Event مستقیمی برای یک فناوری وجود نداشته باشد، امکان Detection نیز وجود ندارد. اما واقعیت این است که در بسیاری از حملات پیشرفته، مهم‌ترین بخش حمله اصلاً لاگ تولید نمی‌کند. هنر Detection Engineer این است که از روی اثرات جانبی، زنجیره حمله را بازسازی کند.به همین دلیل است که امروزه Detection Engineering بیش از آنکه یک مهارت در نوشتن Rule باشد، علم طراحی قابلیت تشخیص (Detection Capability Design) محسوب می‌شود. متخصص این حوزه به‌جای پرسیدن «این حمله چه Event IDای دارد؟» سؤال مهم‌تری می‌پرسد:«اگر مهاجم این تکنیک را اجرا کند، چه رفتارهایی در سیستم باقی می‌ماند که بتوان آن‌ها را با اطمینان تشخیص داد؟»همین تغییر زاویه نگاه، Detection Engineering را به یکی از تخصصی‌ترین و ارزشمندترین گرایش‌های امنیت سایبری در SOCهای مدرن تبدیل کرده است.تفاوت نقش‌های L1 تا L3 با Threat Detection EngineerSOC Analyst L1اولین خط دفاع SOC است.Alertها را پایش، دسته‌بندی و اعتبارسنجی اولیه می‌کند.وظیفه اصلی او تشخیص اولیه و Escalation رخدادها است.SOC Analyst L2رخدادهای ارجاع‌شده از L1 را به‌صورت فنی تحلیل می‌کند.علت حمله، دامنه آلودگی و اقدامات مهار اولیه را بررسی می‌کند.با لاگ‌ها، EDR و شواهد فنی کار می‌کند.SOC Analyst L3 / Threat Hunterبه‌دنبال حملاتی می‌گردد که هنوز Alert تولید نکرده‌اند.رفتار مهاجم، TTPها و ریشه حادثه را تحلیل می‌کند.خروجی او معمولاً فرضیه‌های شکار تهدید و پیشنهادهای بهبود Detection است.Threat Detection Engineerبرخلاف سه نقش قبلی، تمرکز او روی Incident نیست، بلکه روی ساخت قابلیت تشخیص است.Detection Ruleها را طراحی، توسعه، تست، اعتبارسنجی و بهینه‌سازی می‌کند.Detection Coverage را اندازه‌گیری کرده و شکاف‌های تشخیص را شناسایی می‌کند.از روش‌هایی مانند Detection as Code، Sigma، Git، Purple Team و MITRE ATT&CK برای توسعه Detectionها استفاده می‌کند.تفاوت اساسیتحلیلگران L1 تا L3 با Alertهایی که امروز تولید شده‌اند کار می‌کنند.اما Threat Detection Engineer کاری می‌کند که Alertهای فردا دقیق‌تر، سریع‌تر و با خطای کمتر تولید شوند.به همین دلیل، امروزه در SOCهای پیشرفته، Threat Detection Engineering یک گرایش تخصصی مستقل محسوب می‌شود؛ نقشی که بین Threat Hunting، مهندسی SIEM و معماری SOC قرار می‌گیرد و مسئول ارتقای مستمر توان تشخیص سازمان است.روزبه نوروزیروزبه نوروزیTue, 07 Jul 2026 02:34:56 +0330https://virgool.ir/@roozbehnoroozi/چهارچوبی-برای-تریاژنقدی-بر-کتاب-pbd0ondru9uzفراتر از یک الرت قرمز: چارچوبی جامع برای تریاژ در SOCنقدی بر کتاب زیر چرا تریاژ ساده نیست؟بسیاری از تحلیل‌گران تازه‌کار در SOC تصور می‌کنند تریاژ یعنی نگاه کردن به «شدت» یک الرت و تصمیم‌گیری بر اساس همان یک عدد. اما واقعیت میدان عملیاتی چیز دیگری می‌گوید: یک سازمان در روز ممکن است هزاران الرت دریافت کند، در حالی که منابع انسانی و زمانی تیم امنیت محدود است. تریاژ در حقیقت یک فرایند تصمیم‌گیری چندبعدی است، نه یک فیلتر تک‌متغیره. اگر این فرایند را به چهار معیار ساده تقلیل دهیم - شدت تهدید، همراستایی سازمانی، پوشش شناسایی، و وجود اکسپلویت فعال - بخش بزرگی از واقعیت را نادیده گرفته‌ایم. در این مقاله، یک چارچوب هفت‌بعدی تکمیلی معرفی می‌کنیم که می‌تواند مبنای طراحی سیاست‌های Escalation در یک SOC یا یک قرارداد MSSP باشد.بعد اول: بحرانی بودن دارایی (Asset Criticality)اولین نکته‌ای که در چارچوب‌های ابتدایی فراموش می‌شود این است که شدت یک تهدید بدون در نظر گرفتن جایگاه دارایی درگیر، معنای عملیاتی ندارد. یک اکسپلویت فعال با شدت بحرانی روی یک سرور تستی که ایزوله شده، اهمیت عملیاتی بسیار کمتری نسبت به یک الرت با شدت متوسط روی یک Domain Controller یا یک سیستم Core Banking دارد. به همین دلیل، هر چارچوب تریاژ باید یک لایه‌ی مستقل برای رتبه‌بندی دارایی‌ها داشته باشد؛ لایه‌ای که پیش از ورود الرت به فرایند تصمیم‌گیری، وزن آن را تعیین می‌کند.بعد دوم: سطح اطمینان (Confidence Level)هر مکانیزم شناسایی، از یک قانون Sigma گرفته تا یک مدل رفتاری در SIEM، دارای نرخی از False Positive است. یک الرت با شدت بالا اما با منبع پرنویز، نباید همان اولویتی را بگیرد که یک الرت با شواهد Correlation‌شده از چند منبع مستقل دریافت می‌کند. نادیده گرفتن این بعد باعث می‌شود تیم SOC دچار پدیده‌ای به نام «خستگی الرت» شود؛ جایی که تحلیل‌گران به مرور نسبت به هشدارهای پرتکرار و کم‌دقت بی‌تفاوت می‌شوند، و این دقیقاً همان نقطه‌ای است که یک تهدید واقعی می‌تواند در میان نویز گم شود.بعد سوم: شعاع انفجار (Blast Radius)وجود یک اکسپلویت فعال به‌تنهایی نمی‌گوید که تهدید تا کجا می‌تواند گسترش پیدا کند. باید پرسید: اگر این فعالیت مهار نشود، پتانسیل حرکت جانبی آن چقدر است؟ سرقت اطلاعات هویتی از یک ایستگاه کاری عادی، بار ریسکی بسیار متفاوتی نسبت به همان رخداد روی یک Jump Server متصل به سگمنت مالی دارد. تحلیل شعاع انفجار نیازمند شناخت معماری شبکه و نقشه‌ی ارتباطات بین سیستمی است، نه صرفاً بررسی یک رخداد منفرد.بعد چهارم: حساسیت داده و الزامات قانونیوقتی داده‌ی درگیر در یک رخداد شامل اطلاعات هویتی افراد، داده‌های مالی، یا اطلاعاتی است که تحت الزامات نظارتی مانند ISO 27001 یا مقررات نهادهای ناظر بانکی قرار دارد، حتی یک تهدید با شدت متوسط باید در اولویت بالاتری قرار گیرد. این دقیقاً همان نقطه‌ای است که مفهوم حقوقی Due Care وارد تصمیم فنی می‌شود: سازمان نه‌تنها باید تهدید را بشناسد، بلکه باید نشان دهد که برای کاهش آن اقدام کافی و مستمر انجام داده است.بعد پنجم: زمان حضور مهاجم (Dwell Time)یک تهدید که چند دقیقه پیش آغاز شده، از منظر پاسخ‌گویی با تهدیدی که مهاجم چند روز است در آن Persistence برقرار کرده، تفاوت اساسی دارد. هرچه Dwell Time بیشتر باشد، احتمال آن‌که مهاجم مسیرهای جایگزین برای حفظ دسترسی ایجاد کرده باشد بالاتر می‌رود. به همین دلیل، SLA پاسخ‌گویی باید بر اساس این بعد نیز تنظیم شود، نه فقط بر اساس شدت اولیه‌ی الرت.بعد ششم: کنترل‌های جبرانی موجوداگر یک رخداد به‌طور همزمان توسط یک کنترل جبرانی فعال، مانند Segmentation شبکه یا بلاک خودکار EDR، پوشش داده شده باشد، اولویت عملیاتی آن به‌طور طبیعی کاهش می‌یابد؛ چرا که Impact واقعی از قبل محدود شده است. این بعد اهمیت زیادی دارد چون از تخصیص نادرست منابع به رخدادهایی که در عمل قبلاً کنترل شده‌اند جلوگیری می‌کند.بعد هفتم: زمینه‌ی نیت و اسناد مهاجم (Threat Actor Attribution)آخرین بعد، شاید ظریف‌ترین آن‌هاست. زمانی که الگوی رفتاری یک رخداد با تاکتیک‌ها و تکنیک‌های یک گروه شناخته‌شده تطابق دارد، حتی در غیاب شواهد فنی قطعی، باید سطح تریاژ به‌صورت دستی افزایش یابد. این همان نقطه‌ای است که زمینه‌ی ژئوپلیتیکی و اطلاعاتی وارد یک تصمیم صرفاً فنی می‌شود؛ رخدادی که در نگاه اول یک الرت معمولی به نظر می‌رسد، ممکن است بخشی از یک عملیات هدفمند و از پیش برنامه‌ریزی‌شده باشد.ترکیب ابعاد در یک ماتریس عملیاتیبرای آنکه این هفت بعد قابل استفاده در عمل باشند، باید آن‌ها را در یک ماتریس دوبعدی ترکیب کرد: محور «تأثیر» (که از ترکیب شدت تهدید، بحرانی بودن دارایی، شعاع انفجار و حساسیت داده به دست می‌آید) و محور «قطعیت» (که از ترکیب سطح اطمینان، پوشش شناسایی و زمینه‌ی اسناد مهاجم شکل می‌گیرد). هر رخداد بر اساس موقعیتش در این ماتریس، در یکی از سطوح Escalation مانند Standard، High یا Critical قرار می‌گیرد. چنین رویکردی، برخلاف چارچوب‌های چهاربعدی ساده، امکان تصمیم‌گیری قابل دفاع و مستندسازی‌شده را برای تیم امنیت فراهم می‌کند؛ چیزی که هم در حسابرسی‌های داخلی و هم در دفاع حقوقی از تصمیمات SOC اهمیت حیاتی دارد.جمع‌بندیتریاژ در امنیت سایبری، برخلاف تصور رایج، یک فرایند خطی و تک‌بعدی نیست. سازمان‌هایی که تریاژ را تنها بر اساس شدت تهدید یا وجود اکسپلویت فعال طراحی می‌کنند، در عمل ریسک تخصیص نادرست منابع را می‌پذیرند. یک چارچوب بالغ، دارایی، اعتماد به شواهد، پتانسیل گسترش، الزامات قانونی، زمان، کنترل‌های موجود، و زمینه‌ی مهاجم را هم‌زمان در نظر می‌گیرد. برای دانشجویانی که قصد ورود به حوزه‌ی عملیات امنیت را دارند، درک این چندبعدی بودن، نخستین گام برای تبدیل شدن از یک تحلیل‌گر سطح یک به یک تصمیم‌گیرنده‌ی راهبردی در SOC است.روزبه نوروزیروزبه نوروزیSun, 05 Jul 2026 21:12:40 +0330https://virgool.ir/@roozbehnoroozi/معماری-escalation-در-mssp-چرا-شدت-رخداد-باید-مهم-تر-از-نوع-قرارداد-باشد-fy2q1gab6m94یکی از حساس‌ترین و در عین حال کمتر مورد توجه قرارگرفته‌ترین بخش‌های ارائه خدمات Managed Security Service Provider (MSSP)، طراحی فرآیند Incident Escalation است. بسیاری از شرکت‌ها سرمایه‌گذاری قابل توجهی روی SIEM، XDR، SOAR، Threat Intelligence و Detection Engineering انجام می‌دهند، اما زمانی که یک رخداد واقعی شناسایی می‌شود، مشخص نیست چه کسی، در چه زمانی، از چه طریقی و با چه اختیاراتی باید تصمیم‌گیری کند. در عمل، شکست بسیاری از عملیات‌های امنیتی نه به دلیل ضعف فناوری، بلکه به دلیل ضعف در فرآیند تشدید رخداد و واکنش رخ می‌دهد.یکی از اشتباهات رایج در طراحی خدمات MSSP، وابسته کردن فرآیند Escalation به سطح قرارداد مشتری است. برای مثال، تصور می‌شود مشتری Premium باید تماس تلفنی دریافت کند اما مشتری Standard تنها یک تیکت یا ایمیل دریافت کند. این رویکرد از منظر مدیریت ریسک قابل دفاع نیست؛ زیرا مهاجم به نوع قرارداد مشتری توجهی ندارد. اگر نشانه‌های باج‌افزار، تصاحب Domain Admin یا خروج گسترده اطلاعات مشاهده شود، تأخیر در اطلاع‌رسانی می‌تواند خسارت‌هایی ایجاد کند که چندین برابر ارزش کل قرارداد باشد.به همین دلیل، اصل معماری باید بر این پایه استوار باشد که شدت رخداد (Severity) تعیین‌کننده مسیر Escalation باشد، نه ارزش مالی قرارداد یا سطح خدمات خریداری‌شده. تفاوت قراردادها می‌تواند در تعداد گزارش‌ها، ساعات پشتیبانی، زمان پاسخ کارشناسان، خدمات Threat Hunting یا Incident Response باشد، اما در رخدادهای بحرانی، همه مشتریان باید از سریع‌ترین فرآیند اطلاع‌رسانی بهره‌مند شوند.برای تحقق این هدف، می‌توان یک معماری سه‌لایه برای Escalation طراحی کرد.در Tier 1 رخدادهای با شدت پایین و متوسط مدیریت می‌شوند. این دسته شامل هشدارهایی است که هنوز شواهد کافی برای اثبات نفوذ وجود ندارد یا اثر تجاری آن‌ها محدود است. اطلاع‌رسانی از طریق سامانه تیکتینگ و ایمیل انجام می‌شود و پاسخ‌گویی مطابق SLA قرارداد خواهد بود. مسئولیت این سطح معمولاً بر عهده تحلیلگر شیفت است و نیازی به فعال‌سازی مدیر عملیات یا تماس خارج از ساعات اداری وجود ندارد.در Tier 2 وضعیت متفاوت می‌شود. مشاهده نشانه‌هایی مانند Privilege Escalation موفق، ارتباط تأییدشده با زیرساخت فرماندهی و کنترل (C2)، اجرای ابزارهای شناخته‌شده مهاجمان، یا همبستگی چندین IOC مستقل، احتمال وقوع یک Incident واقعی را افزایش می‌دهد. در این مرحله، علاوه بر ثبت تیکت، تماس تلفنی با نماینده اصلی مشتری انجام می‌شود؛ حتی اگر رخداد در نیمه‌شب یا تعطیلات رخ داده باشد. در صورت عدم پاسخ، تماس با نماینده دوم، ارسال پیامک و ایمیل انجام شده و تمام تلاش‌ها با ثبت دقیق زمان مستندسازی می‌شوند. مدیریت این سطح باید توسط Shift Lead یا Incident Manager انجام شود تا تصمیم‌گیری تنها بر عهده تحلیلگر شیفت نباشد.اما مهم‌ترین بخش معماری، Tier 3 است؛ جایی که سازمان با یک بحران امنیتی واقعی مواجه است. آغاز عملیات باج‌افزار، حرکت جانبی گسترده، تصاحب حساب‌های دارای دسترسی مدیریتی، تخریب سرویس‌های حیاتی یا خروج انبوه اطلاعات، نمونه‌هایی از این سطح هستند. در چنین شرایطی، تماس تلفنی باید به صورت هم‌زمان با حداقل دو نفر از فهرست Escalation مشتری برقرار شود. تجربه بسیاری از مراکز عملیات امنیت نشان داده است که تماس ترتیبی با افراد، به‌ویژه در ساعات غیراداری، باعث از دست رفتن دقایق ارزشمند می‌شود. تماس موازی احتمال برقراری ارتباط را افزایش داده و زمان واکنش را کاهش می‌دهد.یکی از مهم‌ترین چالش‌های MSSP در این مرحله، مسئله اختیار اقدام (Authority to Act) است. بسیاری از شرکت‌ها رخداد را شناسایی می‌کنند اما از ترس مسئولیت حقوقی، هیچ اقدامی انجام نمی‌دهند و منتظر تأیید مشتری می‌مانند. در مقابل، برخی نیز بدون مجوز اقدام به ایزوله‌سازی سیستم یا مسدودسازی سرویس می‌کنند و بعداً با اعتراض مشتری مواجه می‌شوند. راه‌حل این تعارض، تعریف Pre-Authorized Emergency Action در قرارداد است. در این مدل، مشتری از همان ابتدا اجازه انجام مجموعه‌ای از اقدامات محدود و مشخص مانند ایزوله کردن یک Endpoint، غیرفعال کردن یک حساب کاربری آلوده یا مسدودسازی ارتباط با یک IP مخرب را صادر می‌کند. بنابراین در زمان بحران، تصمیم‌گیری جدیدی انجام نمی‌شود و MSSP صرفاً اختیار از پیش توافق‌شده را اجرا می‌کند.البته طراحی چنین فرآیندی نیز بدون چالش نیست. نخستین چالش، تعریف صحیح Severity است. اگر معیارها بیش از حد حساس باشند، تعداد زیادی رخداد به اشتباه در Tier 3 قرار می‌گیرند و تیم عملیات با هشدارهای اضطراری مکرر مواجه می‌شود؛ پدیده‌ای که به مرور موجب Alert Fatigue و کاهش حساسیت کارشناسان خواهد شد. از سوی دیگر، اگر معیارها بیش از حد سخت‌گیرانه باشند، ممکن است رخدادهای واقعی دیر تشخیص داده شوند. بنابراین Severity باید بر اساس تحلیل ریسک، دارایی‌های حیاتی، تجربیات گذشته و نیازهای هر مشتری تنظیم شود.چالش دوم، در دسترس نبودن افراد مسئول مشتری است. در بسیاری از رخدادهای واقعی، SOC موفق به شناسایی حمله شده اما هیچ‌یک از افراد معرفی‌شده پاسخگو نبوده‌اند. تغییر شماره تماس، جابه‌جایی مدیران، مرخصی یا خروج کارکنان از سازمان از دلایل رایج این مشکل است. به همین دلیل، فهرست Escalation باید حداقل هر سه ماه یک‌بار بازبینی و صحت اطلاعات آن تأیید شود.چالش سوم، مستندسازی دقیق است. عبارت «تماس گرفته شد» در گزارش حادثه ارزش حقوقی چندانی ندارد. در مقابل، ثبت ساعت دقیق تماس، مدت زمان، شماره مقصد، نتیجه تماس، نام فرد پاسخ‌دهنده و روش‌های جایگزین اطلاع‌رسانی، در صورت بروز اختلافات قراردادی یا بررسی‌های حقوقی، به یکی از مهم‌ترین مستندات تبدیل می‌شود.چالش چهارم، تفاوت مسئولیت میان MSSP و تیم پاسخگویی مشتری است. MSSP مسئول تشخیص، تحلیل، اطلاع‌رسانی و در برخی قراردادها اجرای اقدامات اولیه است؛ اما مسئولیت نهایی مدیریت کسب‌وکار، پذیرش ریسک و تصمیمات کلان همچنان بر عهده مشتری باقی می‌ماند. مرزبندی دقیق این مسئولیت‌ها باید در قرارداد، RACI Matrix و Runbookهای عملیاتی به‌صورت شفاف تعریف شود تا در زمان بحران هیچ ابهامی وجود نداشته باشد.چالش پنجم، هماهنگی بین فناوری و فرآیند است. بسیاری از سازمان‌ها ابزارهای پیشرفته‌ای مانند SIEM، SOAR و XDR را خریداری می‌کنند، اما فرآیند Escalation همچنان به تماس دستی، پیام‌رسان‌های شخصی یا تصمیمات فردی وابسته است. بلوغ واقعی زمانی ایجاد می‌شود که فناوری، فرآیند و نیروی انسانی در کنار یکدیگر عمل کنند؛ به‌گونه‌ای که ایجاد Incident با Severity بحرانی، به‌صورت خودکار زنجیره اطلاع‌رسانی، ثبت مستندات، فعال‌سازی تیم Incident Response و اجرای اقدامات از پیش مجاز را آغاز کند.در نهایت، بلوغ یک MSSP تنها با تعداد Ruleهای تشخیصی یا ابزارهای امنیتی سنجیده نمی‌شود؛ بلکه توانایی مدیریت دقایق نخست یک بحران، مهم‌ترین معیار ارزیابی آن است. تجربه نشان داده است که در بسیاری از حملات بزرگ، فاصله میان یک رخداد قابل مهار و یک فاجعه سازمانی، تنها چند دقیقه بوده است. طراحی یک معماری استاندارد برای Escalation، مبتنی بر شدت رخداد، همراه با تعریف اختیارات از پیش توافق‌شده، مستندسازی دقیق، بازبینی دوره‌ای اطلاعات تماس و تعیین شفاف مسئولیت‌ها، می‌تواند این فاصله را به نفع سازمان کاهش دهد. این رویکرد علاوه بر افزایش تاب‌آوری سایبری، از منظر حقوقی، قراردادی و اعتباری نیز جایگاه MSSP را به‌عنوان یک شریک حرفه‌ای و قابل اعتماد تقویت خواهد کرد.روزبه نوروزیروزبه نوروزیTue, 30 Jun 2026 21:55:18 +0330https://virgool.ir/@roozbehnoroozi/ابزاری-ماندگار-mimikatz-rdowfxmnpzuqMimikatz هیچ مرزی را نمی‌شکند؛ فقط نشان می‌دهد مرز کجا تمام شده استچرا قدرتمندترین ابزار استخراج Credential در ویندوز، نه یک Exploit، بلکه یک طراحی استهر چند سال یک‌بار، یک ابزار امنیتی جدید معرفی می‌شود که وعده می‌دهد محافظت در برابر mimikatz را حل کرده است. هر بار، چند ماه بعد، یک تکنیک bypass جدید منتشر می‌شود و چرخه از نو شروع می‌شود. این الگوی تکرارشونده یک سوال عمیق‌تر را مطرح می‌کند: آیا واقعاً در تلاش برای رفع یک باگ هستیم، یا داریم سعی می‌کنیم چیزی را اصلاح کنیم که از همان ابتدا بخشی از طراحی بوده؟پاسخ این مقاله، دومی است. و فهم این تفاوت، نه‌فقط یک نکته‌ی فنی، بلکه یک تغییر زاویه‌ی دید استراتژیک در معماری امنیت سازمانی است.Mimikatz چه کاری انجام نمی‌دهدنقطه‌ی شروع درست، نه این است که mimikatz چه می‌کند، بلکه این است که چه کاری نمی‌کند. Mimikatz هیچ آسیب‌پذیری نرم‌افزاری (CVE) را exploit نمی‌کند. هیچ buffer overflow یا memory corruption ای در کار نیست. کاری که این ابزار انجام می‌دهد، خواندن داده‌ای است که سیستم‌عامل، با اجازه‌ی خودش، آن را در حافظه نگه داشته است.پروسه‌ی LSASS (Local Security Authority Subsystem Service) در ویندوز، وظیفه دارد credential کاربران (هش پسورد NTLM، Kerberos ticket، و در شرایطی پسورد به‌صورت reversibly-encrypted) را برای پشتیبانی از Single Sign-On نگه دارد. این یک ویژگی است، نه یک عیب: بدون آن، کاربر باید در هر اتصال به هر منبع شبکه دوباره احراز هویت کند. mimikatz صرفاً این حافظه را - وقتی مجوز کافی برای خوانش آن وجود دارد - می‌خواند.این جمله کلید کل بحث است: mimikatz نیاز به همان سطح دسترسی‌ای دارد که خود ویندوز برای این کار تعریف کرده است.مرزی که مایکروسافت رسماً اعلام کرده وجود ندارداینجاست که می‌رسیم به سوال اصلی این مقاله: چرا مایکروسافت تلاش جدی برای بستن کامل این مسیر نمی‌کند؟پاسخ رسمی، و شاید برای بسیاری غیرمنتظره، این است: مایکروسافت به‌طور رسمی اعلام کرده که هیچ مرز امنیتی (Security Boundary) بین سطح Administrator و سطح SYSTEM در ویندوز وجود ندارد. این یعنی از نگاه معماری ویندوز، لحظه‌ای که یک مهاجم به دسترسی Local Administrator می‌رسد، از نظر مایکروسافت بازی از قبل تمام شده است - نه به این معنا که سیستم دیگر قابل دفاع نیست، بلکه به این معنا که از این نقطه به بعد، هر کاری که مهاجم انجام دهد (از جمله خواندن حافظه‌ی LSASS) دیگر یک نقض مرز محسوب نمی‌شود، چون خود مرز، دقیقاً همان‌جا کشیده شده بود.به زبان ساده‌تر: مرزی که ویندوز واقعاً از آن دفاع می‌کند، مرز بین کاربر عادی و Administrator است؛ نه مرز بین Administrator و همه‌ی دانشی که سیستم درباره‌ی هویت‌ها دارد. وقتی مهاجم از مرز اول عبور کرد، مرز دوم - از نگاه طراحی - دیگر وجود ندارد که نقض شود.این دقیقاً همان دلیلی است که توضیح می‌دهد چرا، صرف‌نظر از این‌که Credential Guard یا LSA Protection چقدر قوی‌تر شوند، تکنیک‌های جایگزین (مثل DCSync، Golden Ticket، یا حمله به درایورهای آسیب‌پذیر برای دور زدن این محافظت‌ها) همیشه راهی پیدا می‌کنند. این محافظت‌ها مرز را سخت‌تر می‌کنند، اما مرزی که از نظر طراحی اصلاً تعریف نشده را نمی‌توان واقعاً بسته کرد.چرا این طراحی، یک انتخاب آگاهانه بود - نه یک خطااین طراحی محصول یک trade-off قدیمی و آگاهانه است که از دوران NTLM و معماری دامنه‌ی ویندوز (Active Directory) به ارث رسیده:کارایی در برابر ایزولاسیون کامل: اگر هر درخواست احراز هویت نیاز به ارتباط مستقیم با Domain Controller داشت (بدون cache کردن credential در سطح local)، عملکرد شبکه به‌شدت کند می‌شد.سازگاری با گذشته (Backward Compatibility): میلیون‌ها سیستم و اپلیکیشن سازمانی روی این مدل اعتماد بنا شده‌اند؛ تغییر بنیادی آن یعنی شکستن سازگاری با دهه‌ها زیرساخت موجود.فرض بنیادی امنیت ویندوز کلاسیک: فرض اصلی این بود که اگر کسی به Administrator رسیده، او دیگر دشمن نیست، بلکه مدیر سیستم است. این فرض در دنیای امروز (با ransomware، APT، و insider threat) دیگر معتبر نیست، اما معماری پایه‌ای هنوز همان است.به بیان دیگر، mimikatz محصول جانبی یک تصمیم معماری است که سال‌ها قبل از وجود mimikatz گرفته شده بود؛ بنژامین دلپی فقط این تصمیم را قابل‌مشاهده کرد، آن را نساخت.پیامد استراتژیک: جنگیدن با نتیجه به‌جای جنگیدن با علتاین درک، یک تغییر مهم در اولویت‌بندی دفاعی ایجاد می‌کند. اگر فرض کنیم mimikatz یک «باگ» است، استراتژی منطقی این می‌شود: محصول بهتر بخریم تا mimikatz را تشخیص دهد و بلاک کند. اما اگر بپذیریم mimikatz نتیجه‌ی یک مرز اعتماد است که از قبل تعریف شده، استراتژی درست تغییر می‌کند: تمرکز باید روی این باشد که مهاجم هرگز به آن مرز (دسترسی Administrator) نرسد، یا اگر رسید، شعاع آسیب (Blast Radius) محدود بماند.این یعنی در عمل:مدل سرپرستی لایه‌بندی‌شده (Tiered Administration): هیچ Administrator سطح Domain نباید روی سیستم‌های کاربر عادی لاگین کند - این دقیقاً همان مسیری است که credential dumping را به یک تهدید سراسری تبدیل می‌کند.Just-in-Time و Just-Enough Administration: دسترسی Admin باید موقت، محدود به وظیفه، و قابل audit باشد - نه یک حالت دائمی.Privileged Access Management (PAM): جداسازی کامل حساب‌های privileged از فعالیت روزمره.Credential Guard به‌عنوان یک لایه‌ی تکمیلی، نه راه‌حل نهایی: این ابزار هزینه‌ی حمله را بالا می‌برد، اما مرز بنیادی را تغییر نمی‌دهد.فرض «Assume Breach»: به‌جای امیدواری به این‌که هیچ‌وقت مهاجم به Admin نمی‌رسد، باید معماری به‌گونه‌ای طراحی شود که حتی در صورت رسیدن، lateral movement و privilege escalation به سرعت محدود و شناسایی شود.جمع‌بندیMimikatz از بین نمی‌رود، چون چیزی نیست که بتوان «از بین برد». این ابزار، آینه‌ای است که یک حقیقت معماری قدیمی در ویندوز را نشان می‌دهد: مرز امنیتی واقعی، جایی است که مایکروسافت رسماً آن را تعریف کرده - یعنی مرز ورود به سطح Administrator - نه جایی که کاربران یا فروشندگان امنیتی فکر می‌کنند باید باشد. تا زمانی که سازمان‌ها این مرز را به‌عنوان نقطه‌ی اصلی دفاع نبینند و منابع را به‌جای «شکار mimikatz» به «جلوگیری از رسیدن به آن مرز» تخصیص ندهند، این چرخه‌ی بی‌پایان تشخیص و bypass ادامه خواهد داشت.سوال درست هرگز «چگونه mimikatz را متوقف کنیم؟» نبوده است؛ سوال درست همیشه این بوده: «چرا اجازه دادیم مهاجم به نقطه‌ای برسد که اصلاً نیازی به مهارت خاصی برای دیدن همه‌چیز نداشته باشد؟»روزبه نوروزیروزبه نوروزیWed, 24 Jun 2026 21:05:03 +0330https://virgool.ir/@roozbehnoroozi/خودکفایی-سایبری-و-استقلال-دیجیتال-از-حرف-تا-عمل-afcfwrey7igzتنش‌های ژئوپلیتیکی سال‌های اخیر یک سؤال مهم را پیش روی بسیاری از کشورها قرار داده است: وقتی بخش بزرگی از سیستم‌عامل‌ها، تجهیزات شبکه، سرویس‌های ابری و محصولات امنیت سایبری توسط شرکت‌هایی تولید می‌شوند که تحت قوانین و سیاست‌های چند کشور محدود قرار دارند، آیا یک کشور باید همه محصولات فناوری اطلاعات و امنیت خود را به‌صورت بومی تولید کند یا راهکار منطقی‌تری وجود دارد؟پاسخ این سؤال، برخلاف تصور رایج، یک «بله» یا «خیر» ساده نیست. تجربه جهانی نشان می‌دهد که خودکفایی صددرصدی در فناوری اطلاعات تقریباً غیرممکن است. حتی کشورهایی مانند چین با سرمایه‌گذاری‌های چند صد میلیارد دلاری و روسیه پس از تحریم‌های گسترده، همچنان در برخی لایه‌های فناوری به اکوسیستم جهانی وابسته هستند. دلیل آن نیز روشن است؛ توسعه یک سیستم‌عامل، آنتی‌ویروس، EDR، پایگاه داده یا پردازنده تنها به نوشتن کد محدود نمی‌شود و به هزاران کتابخانه متن‌باز، کامپایلرها، ابزارهای توسعه، استانداردها و زنجیره تأمین جهانی وابسته است. بنابراین مفهوم خودکفایی کامل بیش از آنکه یک هدف عملی باشد، یک آرمان ایده‌آل است.از سوی دیگر، نگرانی درباره وابستگی به محصولات خارجی نیز کاملاً واقعی است. سیستم‌عامل‌ها، سرویس‌های ابری و محصولات امنیتی مدرن دارای مکانیزم‌های به‌روزرسانی، تله‌متری و ارتباطات گسترده هستند و در سطح امنیت ملی، این موضوع به‌عنوان یک ریسک بالقوه شناخته می‌شود. به همین دلیل مفاهیمی مانند Digital Sovereignty یا حاکمیت دیجیتال امروز در اروپا، چین، هند و بسیاری از کشورهای دیگر به یکی از موضوعات اصلی سیاست‌گذاری تبدیل شده است.اما راهکار چیست؟بهترین رویکرد، حرکت از مفهوم خودکفایی مطلق به سمت استقلال راهبردی است. یعنی فناوری‌ها بر اساس میزان حساسیت لایه‌بندی شوند. زیرساخت‌های حیاتی مانند سامانه‌های نظامی، انرژی، بانک مرکزی و مخابرات باید تا حد امکان تحت کنترل داخلی و قابل ممیزی باشند، حتی اگر هزینه بیشتری داشته باشند. در مقابل، برای بسیاری از سازمان‌های خصوصی و کاربردهای عمومی، استفاده از محصولات بین‌المللی معتبر با مدیریت ریسک مناسب منطقی‌تر و اقتصادی‌تر است.نکته مهم دیگر، تکیه بر اکوسیستم متن‌باز است. امنیت واقعی تنها به داخلی بودن وابسته نیست، بلکه به قابلیت ممیزی و شفافیت بستگی دارد. یک محصول Open Source که کد آن قابل بررسی، Fork و توسعه مستقل باشد، در بسیاری از موارد می‌تواند از یک محصول بومی اما Closed Source قابل اعتمادتر باشد و وابستگی به یک فروشنده خاص را نیز کاهش دهد.همچنین تنوع‌بخشی به تأمین‌کنندگان اهمیت زیادی دارد. وابستگی کامل به یک کشور یا یک Vendor، صرف‌نظر از اینکه آمریکایی، اروپایی یا داخلی باشد، ریسک تمرکز ایجاد می‌کند. استفاده از محصولات متنوع از کشورهای مختلف، همراه با استانداردهای باز و معماری قابل جایگزینی، تاب‌آوری سایبری را افزایش می‌دهد.در نهایت، هدف نباید ساختن همه چیز باشد، بلکه باید توانایی کنترل، ممیزی، توسعه و جایگزینی فناوری در زمان نیاز ایجاد شود. کشوری که بتواند در لایه‌های حیاتی تصمیم مستقل بگیرد، از فناوری متن‌باز بهره ببرد، زنجیره تأمین خود را متنوع کند و در حوزه‌های کلیدی سرمایه‌گذاری بلندمدت داشته باشد، به استقلال دیجیتال نزدیک‌تر است؛ استقلالی که نه بر پایه انزوا، بلکه بر پایه تنوع، شفافیت، رقابت و توانمندی داخلی شکل می‌گیرد. این رویکرد از نظر فنی، اقتصادی و امنیتی، واقع‌بینانه‌ترین مسیر برای کاهش ریسک‌های ژئوپلیتیکی در دنیای امروز است.روزبه نوروزیروزبه نوروزیWed, 24 Jun 2026 12:56:34 +0330https://virgool.ir/@roozbehnoroozi/روایتی-از-یک-بررسی-فارنزیک-و-احتمال-image-tampering-d1uolhzlyfxeهفته خوبی شروع شد؛ با یک بررسی فارنزیک نسبتاً چالش‌برانگیز که از همان ابتدا نشانه‌هایی از یک رخداد غیرمعمول در آن دیده می‌شد. همان‌طور که معمولاً در تحلیل‌های فارنزیک اتفاق می‌افتد، در نگاه اول همه‌چیز واضح و قطعی نبود. شواهد اولیه پراکنده بودند، بعضی Artifactها با هم هم‌خوانی داشتند و برخی دیگر، تصویر متفاوتی از رفتار سیستم نشان می‌دادند. همین ناهماهنگی‌ها باعث شد بررسی را با دقت بیشتری ادامه دهیم و فرضیه‌های مختلفی را درباره نحوه اجرای پردازش‌ها و احتمال دستکاری در Image اجرایی آن‌ها مطرح کنیم.در جریان این بررسی، تمرکز اصلی روی مقایسه میان Artifactهای دیسک، رفتار Processها و Timeline سیستم قرار گرفت. در یک رخداد عادی، انتظار می‌رود میان فایل‌های موجود روی دیسک، زمان ایجاد یا تغییر آن‌ها، اجرای پردازش‌ها و لاگ‌های مربوط به سیستم‌عامل، نوعی همبستگی منطقی وجود داشته باشد. برای مثال، زمانی که یک فایل اجرایی روی دیسک ایجاد یا اصلاح می‌شود و سپس به‌عنوان یک Process اجرا می‌گردد، معمولاً ردپاهای آن در چند نقطه مختلف سیستم قابل مشاهده است. اما در این پرونده، برخی از این روابط به شکل مورد انتظار دیده نمی‌شد.در Timeline سیستم، بازه‌هایی وجود داشت که در نزدیکی زمان ایجاد یا اجرای برخی Processها، تغییرات غیرعادی روی فایل‌های مرتبط مشاهده شده بود. این تغییرات از نظر زمانی با فعالیت Processها هم‌پوشانی داشتند، اما ترتیب رویدادها و نوع Artifactهای ایجادشده، با یک اجرای معمولی و ساده مطابقت کامل نداشت. همین موضوع احتمال استفاده از تکنیک‌هایی را مطرح کرد که در دسته کلی Process Manipulation یا دستکاری پردازش قرار می‌گیرند؛ تکنیک‌هایی که هدف آن‌ها پنهان‌سازی رفتار واقعی کد مخرب، دورزدن ابزارهای امنیتی یا ایجاد ابهام در تحلیل فارنزیک است.یکی از فرضیه‌هایی که در این بررسی مطرح شد، احتمال استفاده از تکنیک‌های مرتبط با Image Tampering بود. در این نوع تکنیک‌ها، مهاجم تلاش می‌کند ارتباط قابل اعتماد میان فایل اجرایی روی دیسک و Imageای که در حافظه به‌عنوان Process اجرا شده است را دچار اختلال کند. به بیان ساده‌تر، ممکن است آنچه روی دیسک دیده می‌شود، الزاماً همان چیزی نباشد که در زمان اجرا در حافظه فعال بوده است. این مسئله برای تحلیلگران امنیتی بسیار مهم است؛ زیرا بسیاری از ابزارهای دفاعی و فارنزیکی برای تشخیص رفتار مشکوک، میان فایل روی دیسک، امضای آن، هش فایل، مسیر اجرا و رفتار Runtime ارتباط برقرار می‌کنند.در این پرونده، شواهد اولیه نشان می‌داد که میان Artifactهای موجود روی دیسک و رفتار اجرایی Processها همبستگی کامل وجود ندارد. این عدم همبستگی به‌تنهایی برای اعلام قطعی استفاده از یک تکنیک خاص کافی نیست، اما از نظر تحلیلی نمی‌توان آن را نادیده گرفت. در فارنزیک، یکی از خطاهای رایج این است که تحلیلگر با مشاهده یک نشانه، خیلی زود به یک نتیجه قطعی برسد. در حالی که رویکرد درست، ساختن فرضیه، آزمون شواهد و سپس رد یا تأیید تدریجی آن‌هاست. به همین دلیل، در این مرحله صرفاً می‌توان گفت الگوهای مشاهده‌شده با برخی تکنیک‌های شناخته‌شده مانند Process Herpaderping، Process Hollowing یا سایر روش‌های Process Manipulation همخوانی نسبی دارند.تکنیک Process Hollowing یکی از روش‌های شناخته‌شده در اجرای کد مخرب در قالب یک Process ظاهراً معتبر است. در این روش، معمولاً یک Process قانونی ایجاد می‌شود، سپس محتوای اصلی آن در حافظه دستکاری شده و کد دیگری جایگزین می‌گردد. نتیجه این است که در ظاهر، سیستم یک Process شناخته‌شده و معتبر را نشان می‌دهد، اما آنچه واقعاً در حافظه اجرا می‌شود، می‌تواند با فایل اصلی روی دیسک تفاوت داشته باشد. همین تفاوت میان ظاهر Process و محتوای واقعی آن، تحلیل را پیچیده‌تر می‌کند.در مقابل، Process Herpaderping رویکرد متفاوتی دارد و بیشتر بر ایجاد ابهام در ارتباط میان فایل روی دیسک و Image اجراشده تمرکز می‌کند. در این تکنیک، مهاجم تلاش می‌کند در زمان‌بندی میان ایجاد فایل، اجرای Process و تغییر یا جایگزینی محتوای فایل روی دیسک اختلال ایجاد کند. نتیجه این است که ابزارهای امنیتی ممکن است هنگام بررسی فایل روی دیسک، چیزی متفاوت از آنچه واقعاً برای ایجاد Process استفاده شده است مشاهده کنند. از دید فارنزیک، این نوع رفتار می‌تواند باعث ایجاد اختلاف میان Timeline، Artifactهای فایل‌سیستم و داده‌های مربوط به Process شود.البته باید تأکید کرد که مشاهده چنین ناهماهنگی‌هایی الزاماً به معنای وقوع قطعی Herpaderping یا Hollowing نیست. گاهی رفتار برخی نرم‌افزارهای قانونی، به‌روزرسانی‌ها، ابزارهای مدیریتی یا حتی مکانیزم‌های محافظتی محصولات امنیتی نیز می‌توانند Artifactهایی ایجاد کنند که در نگاه اول غیرعادی به نظر برسند. به همین دلیل، تحلیل باید با دقت و با در نظر گرفتن زمینه عملیاتی سیستم انجام شود. اینکه سیستم چه نقشی داشته، چه نرم‌افزارهایی روی آن فعال بوده‌اند، چه سیاست‌های امنیتی اعمال شده و چه فعالیت‌هایی در همان بازه زمانی در شبکه رخ داده، همگی در نتیجه‌گیری نهایی اثرگذار هستند.در بررسی انجام‌شده، یکی از نقاط مهم، Correlation دقیق Timeline بود. Timeline در فارنزیک فقط فهرستی از زمان‌ها نیست؛ بلکه روایت رخداد است. اگر این روایت به‌درستی ساخته شود، می‌تواند نشان دهد که کدام فایل ابتدا ایجاد شده، چه زمانی تغییر کرده، چه Processهایی در همان بازه فعال شده‌اند، چه ارتباطات شبکه‌ای برقرار شده، چه کلیدهای رجیستری تغییر کرده‌اند و کدام لاگ‌های امنیتی با این فعالیت‌ها هم‌زمان بوده‌اند. در پرونده‌هایی که احتمال Process Manipulation وجود دارد، دقت زمانی اهمیت دوچندان پیدا می‌کند؛ زیرا گاهی فاصله میان ایجاد، اجرا و تغییر فایل‌ها بسیار کوتاه است.از طرف دیگر، بررسی صرف Artifactهای دیسک برای رسیدن به نتیجه قطعی کافی نیست. در چنین مواردی، Memory Artifactها نقش بسیار مهمی دارند. حافظه می‌تواند اطلاعاتی را نشان دهد که روی دیسک دیگر قابل مشاهده نیستند یا عمداً تغییر داده شده‌اند. بررسی ساختار Process در حافظه، ماژول‌های بارگذاری‌شده، Threadها، نواحی حافظه با مجوزهای اجرایی، اختلاف میان Image روی دیسک و محتوای حافظه، Handleها و ارتباطات شبکه‌ای فعال می‌تواند به روشن‌تر شدن موضوع کمک کند. اگر Processای در ظاهر به یک فایل مشخص روی دیسک اشاره کند، اما بخش‌هایی از حافظه آن با Image اصلی همخوان نباشد، این موضوع می‌تواند نشانه مهمی برای ادامه تحلیل باشد.همچنین بررسی Telemetryهای Process اهمیت بالایی دارد. داده‌هایی مانند Parent Process، Command Line، مسیر Image، Hash فایل در زمان اجرا، امضای دیجیتال، زمان ایجاد Process، رفتار فرزندزایی، دسترسی به فایل‌ها، تغییرات رجیستری و ارتباطات شبکه‌ای می‌توانند تصویر دقیق‌تری از رفتار واقعی ارائه دهند. اگر این Telemetryها از منابع مختلف مانند EDR، Sysmon، SIEM و لاگ‌های سیستم‌عامل جمع‌آوری شده باشند، امکان مقایسه و اعتبارسنجی متقابل فراهم می‌شود. در این نوع پرونده‌ها، یک منبع داده به‌تنهایی معمولاً کافی نیست و ارزش اصلی در همبستگی چندمنبعی داده‌هاست.نکته مهم دیگری که در این بررسی مورد توجه قرار گرفت، پرهیز از انتساب زودهنگام بود. در تحلیل رخدادهای سایبری، به‌ویژه زمانی که تکنیک‌های پیشرفته مطرح می‌شوند، وسوسه زیادی وجود دارد که سریعاً رخداد را به یک تکنیک مشخص یا حتی یک گروه تهدید خاص نسبت دهیم. اما تحلیل حرفه‌ای نیازمند احتیاط است. تا زمانی که شواهد کافی از حافظه، لاگ‌ها، رفتار Process و Timeline به‌دست نیامده باشد، بهتر است نتیجه‌گیری در سطح «احتمال» یا «همخوانی نسبی با الگوهای شناخته‌شده» باقی بماند.بر اساس شواهد فعلی، توصیه من انجام بررسی عمیق‌تر در سه محور اصلی بود: نخست، تحلیل دقیق Memory Artifactها برای شناسایی هرگونه اختلاف میان Image اجرایی در حافظه و فایل متناظر روی دیسک؛ دوم، جمع‌آوری و بررسی کامل Telemetryهای Process از منابع امنیتی موجود؛ و سوم، بازسازی دقیق Timeline رخداد با تمرکز بر توالی ایجاد، اجرا، تغییر و حذف فایل‌ها. این سه محور می‌توانند در کنار هم، امکان رد یا تأیید فرضیه Image Tampering را فراهم کنند.جمع‌بندی این بررسی تا این مرحله این است که با یک رخداد ساده و خطی مواجه نیستیم. ناهماهنگی میان شواهد دیسک، رفتار Processها و Timeline سیستم، نشانه‌ای است که باید جدی گرفته شود. هرچند هنوز نمی‌توان با قطعیت از به‌کارگیری یک تکنیک خاص صحبت کرد، اما الگوهای مشاهده‌شده ارزش بررسی عمیق‌تر را دارند و می‌توانند به کشف یک روش پنهان‌کارانه در اجرای کد یا دورزدن مکانیزم‌های تشخیص منجر شوند.هفته با چنین پرونده‌ای شروع شد؛ پرونده‌ای که بار دیگر یادآوری کرد در فارنزیک، جزئیات کوچک می‌توانند مسیر تحلیل را تغییر دهند. گاهی یک اختلاف زمانی، یک Artifact ناقص یا یک رفتار غیرمنتظره در Process، همان سرنخی است که پشت آن یک تکنیک پیچیده پنهان شده است.روزبه نوروزیروزبه نوروزیFri, 12 Jun 2026 22:13:35 +0330https://virgool.ir/@roozbehnoroozi/پیشنهاد-هایی-به-افتای-ریاست-جمهوری-کشور-از-تصمیم-جدید-cisa-aoh4z8lfnitsتصمیم جدید CISA برای بازنویسی الزامات مدیریت وصله‌های امنیتی، صرفاً کاهش زمان نصب Patch از ۱۵ روز به ۳ روز نیست؛ بلکه نشانه تغییر یک پارادایم مهم در مدیریت آسیب‌پذیری است. این تغییر می‌تواند برای افتا نیز الهام‌بخش باشد. ۱. عبور از Patch Everything به Patch Smarterسال‌ها بسیاری از سازمان‌ها تلاش کردند همه آسیب‌پذیری‌ها را با یک فوریت یکسان رفع کنند. اما CISA پذیرفته است که در عصر هوش مصنوعی، این رویکرد عملی نیست. بر این اساس، آسیب‌پذیری‌ها بر اساس ریسک واقعی اولویت‌بندی می‌شوند. ۲. ایجاد نسخه ایرانی KEVیکی از مهم‌ترین درس‌ها، توسعه یک فهرست ملی آسیب‌پذیری‌های مورد سوءاستفاده مشابه KEV است؛ فهرستی که بر اساس تهدیدات واقعی علیه زیرساخت‌های کشور به‌روزرسانی شود و به دستگاه‌ها بگوید کدام CVEها باید فوراً اصلاح شوند. ۳. توجه به قابلیت بهره‌برداری خودکار توسط AIسازمان CISA برای نخستین بار، قابلیت خودکارسازی حمله را به‌عنوان معیار اولویت‌بندی وارد کرده است. یعنی اگر یک آسیب‌پذیری به کمک AI بتواند در مقیاس وسیع و بدون دخالت زیاد انسان مورد سوءاستفاده قرار گیرد، باید سریع‌تر رفع شود. ۴. الزام به تحلیل فارنزیکنکته مهم دیگر این است که وصله کردن کافی نیست. در آسیب‌پذیری‌های بحرانی، دستگاه‌ها باید بررسی کنند آیا پیش از نصب وصله، نشانه‌ای از نفوذ وجود داشته است یا خیر. این موضوع می‌تواند به الزامی برای انجام Forensic Triage در زیرساخت‌های حیاتی کشور تبدیل شود. ۵. دارایی‌محوری به جای CVE محوریتمام آسیب‌پذیری‌ها ارزش یکسان ندارند. آسیب‌پذیری یک سامانه اینترنتی حیاتی با آسیب‌پذیری یک سیستم آزمایشگاهی داخلی متفاوت است. بنابراین طبقه‌بندی دارایی‌ها باید مبنای زمان‌بندی اصلاح قرار گیرد.۶. استانداردسازی برچسب‌گذاری دارایی‌هاسازمان CISA اعلام کرده است که برای دارایی‌ها Schema استاندارد منتشر خواهد کرد. این موضوع می‌تواند افتا را به سمت ایجاد یک مدل ملی طبقه‌بندی دارایی‌ها و یکپارچه‌سازی CMDB سازمان‌های حیاتی سوق دهد. ۷. حرکت به سمت Exposure Managementشاید مهم‌ترین پیام این تصمیم آن باشد که دوران Vulnerability Management سنتی رو به پایان است. در آینده، سؤال اصلی این نیست که "چند آسیب‌پذیری داریم؟" بلکه این است که "کدام آسیب‌پذیری روی کدام دارایی حیاتی، با چه احتمال بهره‌برداری و چه اثر عملیاتی، بیشترین خطر را ایجاد می‌کند؟"در واقع، اگر بخواهیم پیام اصلی این تحول را در یک جمله خلاصه کنیم، باید گفت: عصر هوش مصنوعی، مدیریت آسیب‌پذیری را از یک فعالیت مبتنی بر شمارش CVEها به یک فرآیند مبتنی بر ریسک، زمینه عملیاتی و سرعت تصمیم‌گیری تبدیل کرده است. شاید زمان آن رسیده باشد که افتا نیز از «مدیریت وصله» به سمت «مدیریت مواجهه سایبری ملی» حرکت کند.منبع CISAروزبه نوروزیروزبه نوروزیFri, 12 Jun 2026 21:56:07 +0330https://virgool.ir/@roozbehnoroozi/ایده-ای-برای-پایش-در-soc-ریسک-نشست-و-اسپلانک-hvcz92fby8gbبسیاری از SOCها هنوز امنیت هویت را به پایش ورودهای موفق و ناموفق محدود می‌کنند. اما در عصر سرقت Cookie، سوءاستفاده از Tokenها و حملات Account Takeover، ورود موفق دیگر به معنای اعتماد کامل نیست.یکی از رویکردهای نوین در امنیت هویت، ارزیابی مستمر ریسک نشست (Continuous Session Risk Assessment) است. در این مدل، پس از ورود کاربر، رفتار نشست به‌صورت مداوم تحلیل می‌شود. آیا کاربر از دستگاهی ناشناس متصل شده است؟ آیا موقعیت جغرافیایی او به‌طور ناگهانی تغییر کرده است؟ آیا حجم دانلود داده‌ها غیرعادی است؟ آیا الگوی فعالیت او با رفتار تاریخی‌اش همخوانی دارد؟در Splunk Enterprise Security می‌توان با استفاده از قابلیت Risk-Based Alerting، برای رویدادهای مشکوک مرتبط با User، Host یا سایر Risk Objectها امتیاز ریسک تعریف و آن‌ها را تجمیع کرد. این قابلیت به‌صورت ذاتی یک موتور ریسک نشست نیست، اما زیرساخت لازم را برای پیاده‌سازی چنین رویکردی فراهم می‌کند.آنچه این روزها ذهن مرا درگیر کرده، بررسی این موضوع است که آیا می‌توان با ترکیب لاگ‌های هویت، وب، پروکسی و SSO، به سؤالاتی مانند این پاسخ داد: این Cookie متعلق به کدام نشست است؟ آیا این همان مرورگر قبلی است؟ آیا نشانه‌ای از سرقت Token وجود دارد؟شاید در دنیای امروز، مهم‌ترین سؤال دیگر این نباشد که چه کسی وارد شد؟ بلکه این باشد که: آیا هنوز می‌توان به این نشست اعتماد کرد؟آیا شما تا امروز در پیاده‌سازی Splunk به این مرحله رسیده‌اید؟ و به نظر شما، محدودیت داده‌ها و منابع تا چه حد اجازه تحقق چنین ایده‌ای را می‌دهند؟روزبه نوروزیروزبه نوروزیFri, 12 Jun 2026 21:54:33 +0330https://virgool.ir/@roozbehnoroozi/نقش-عوامل-مختلف-دفاعی-در-زمانه-ظهور-فناوری-های-حمله-مبتنی-بر-هوش-مصنوعی-fr9f7piviqm4یک نگاه انتقادی به امنیت سایبری در عصر مهاجمان تقویت‌شده با AIسال‌ها صنعت امنیت سایبری بر این فرض بنا شده بود که اگر ابزارهای دفاعی بیشتری خریداری کنیم، امنیت بیشتری خواهیم داشت. فایروال‌ها، EDRها، SIEMها، IDSها، WAFها و ده‌ها محصول دیگر به سازمان‌ها فروخته شدند؛ اما ظهور فناوری‌های حمله مبتنی بر هوش مصنوعی یک سؤال جدی ایجاد کرده است: آیا مدل فعلی دفاع سایبری هنوز کار می‌کند؟واقعیت این است که AI الزاماً حملات جدیدی خلق نکرده؛ بلکه اقتصاد حمله را تغییر داده است. امروز مهاجم می‌تواند سریع‌تر کدنویسی کند، سریع‌تر شناسایی کند، سریع‌تر اصلاح کند و سریع‌تر مقیاس بگیرد. این تغییر سرعت، مهم‌ترین مسئله عصر جدید است. افسانه ابزار دفاعی به‌عنوان ناجییکی از بزرگ‌ترین مشکلات امنیت مدرن، وابستگی بیش از حد به محصولات امنیتی است. بسیاری از سازمان‌ها تصور می‌کنند خرید EDR یا XDR به معنی حل مسئله کشف تهدید است. اما واقعیت بسیار پیچیده‌تر است.ابزارها تنها Sensor هستند؛ آنچه اهمیت دارد، نحوه استفاده از داده‌های آن‌هاست.اگر سازمانی هزاران Endpoint مجهز به EDR داشته باشد اما:* Detection Engineering نداشته باشد* Use Case مناسب نداشته باشد* Incident Response بالغ نداشته باشد* Threat Hunting نداشته باشددر عمل فقط حجم عظیمی از Telemetry تولید کرده است.هوش مصنوعی این ضعف را آشکارتر کرده است؛ زیرا مهاجم اکنون می‌تواند سریع‌تر از گذشته رفتار خود را تغییر دهد. آیا EDR دیگر ارزش دارد؟پاسخ کوتاه: بله.پاسخ دقیق‌تر: بله، اما نه به شکلی که قبلاً فکر می‌کردیم.EDR هنوز دید ارزشمندی از:* Process Creation* Memory Behavior* Command Line* Registry Changes* User Context* Process Treeفراهم می‌کند.اما مشکل اینجاست که بسیاری از حملات مدرن دیگر صرفاً Malware محور نیستند.Living off the Land، سوءاستفاده از ابزارهای قانونی، حملات Identity محور، Abuse سرویس‌های Cloud و حملات Fileless باعث شده‌اند که داشتن Visibility دیگر معادل داشتن Detection نباشد.بنابراین EDR نمرده است؛ بلکه از قهرمان اصلی به یکی از اجزای اکوسیستم دفاعی تبدیل شده است.هاردنینگ؛ قهرمان فراموش‌شدهدر سال‌های اخیر صنعت امنیت بیشتر بر Detection تمرکز کرده تا Prevention.اما ظهور AI یک سؤال سخت مطرح می‌کند:اگر مهاجم بتواند هزاران Variant جدید بسازد، آیا منطقی نیست ابتدا سطح حمله را کوچک کنیم؟سازمانی که:* Local Admin Everywhere دارد* PowerShell نامحدود دارد* Segmentation ضعیف دارد* Credential Hygiene ضعیف داردعملاً EDR را مجبور می‌کند هر روز بجنگد.هاردنینگ جذاب نیست و داشبورد رنگی ندارد ودموی بازاریابی ندارد.اما هنوز یکی از مؤثرترین روش‌های کاهش ریسک است. مقوله Detection Engineeng مهم‌تر از Detection Product شده استدر گذشته بسیاری از سازمان‌ها به دنبال Signatureهای بیشتر بودند.امروز سؤال باید عوض شود.به جای:«چگونه Mimikatz را کشف کنیم؟»باید پرسید:چگونه Credential Access Behavior را کشف کنیم؟به جای:چگونه ransomware.exe را پیدا کنیم؟باید پرسید:«چگونه رفتار Encryption + Discovery + Privilege Escalation را پیدا کنیم؟»AI باعث شده Detection Engineering از یک فعالیت جانبی به یک قابلیت حیاتی تبدیل شود. مشکل واقعی: بحران سرعتبزرگ‌ترین مزیت AI برای مهاجم، کیفیت نیست؛ سرعت است.قبلاً:Recon > Development > Test > Fixممکن بود هفته‌ها طول بکشد.امروز:Recon > AI Prompt > Generate > Revise > Deployممکن است ساعت‌ها طول بکشد.این تغییر باعث شده:MTTD اهمیت بیشتری پیدا کند.MTTR اهمیت بیشتری پیدا کند.Automation اهمیت بیشتری پیدا کند.سازمانی که Incident Response آن چند روز طول بکشد، حتی با بهترین ابزارها نیز آسیب‌پذیر خواهد بود. Threat Hunting؛ لوکس یا ضرورت؟سال‌ها Threat Hunting در بسیاری از سازمان‌ها به عنوان فعالیتی لوکس دیده می‌شد.اما اگر مهاجم بتواند سریع‌تر Variant تولید کند و Signatureها را دور بزند، Hunting دیگر انتخاب نیست.مشکل اینجاست:بسیاری از Huntingها هنوز:* IOC محور هستند* Rule محور هستند* Dashboard محور هستنددر حالی که مهاجم AI محور، رفتارش سریع‌تر از Ruleها تغییر می‌کند.بنابراین Hunting باید:* Hypothesis Driven شود* Behavior Centric شود* Data Driven شود نقش Identity در دفاع مدرنبسیاری از سازمان‌ها هنوز Endpoint-centric فکر می‌کنند.در حالی که مهاجمان مدت‌هاست Identity-centric شده‌اند.وقتی:* Credential Theft* Session Hijacking* OAuth Abuse* Token Theftرشد می‌کند، تمرکز صرف بر Endpoint اشتباه است.هویت به تدریج به مرکز دفاع تبدیل می‌شود. آیا XDR پاسخ نهایی است؟بسیاری XDR را پاسخ مشکلات EDR معرفی می‌کنند.اما باید محتاط بود.XDR اگر صرفاً«جمع کردن Telemetry بیشتر»باشد، مشکل حل نمی‌شود.مسئله اصلی همچنان:* Correlation* Context* Prioritization* Responseاست.XDR بدون Detection Maturity می‌تواند فقط نسخه گران‌تر EDR باشد.نقش انسان؛ حذف یا تغییر؟بحث رایج این است که AI جای تحلیلگران امنیت را می‌گیرد.اما احتمالاً سؤال درست این است:آیا تحلیلگری که از AI استفاده نکند حذف می‌شود؟به نظر می‌رسد مدل آینده چیزی شبیه این باشد:Human + Automation + Agentsنه Human Aloneنه AI Aloneسازمان‌هایی که این ترکیب را نسازند، احتمالاً با افزایش سرعت حملات دچار مشکل خواهند شد. جمع‌بندیهوش مصنوعی باعث نشده ابزارهای دفاعی بی‌ارزش شوند؛ بلکه ضعف‌های آن‌ها را آشکارتر کرده است.EDR هنوز لازم است.SIEM هنوز لازم است.Threat Hunting هنوز لازم است.اما هیچ‌کدام به‌تنهایی کافی نیستند.دفاع مدرن دیگر مسابقه خرید ابزار نیست.مسابقه ساختن اکوسیستم دفاعی است.شاید مهم‌ترین سؤال امروز این نباشد که:«چه ابزاری بخریم؟»بلکه این باشد:«چقدر سریع می‌توانیم ببینیم، بفهمیم و واکنش نشان دهیم؟»روزبه نوروزیروزبه نوروزیFri, 05 Jun 2026 21:03:07 +0330https://virgool.ir/@roozbehnoroozi/دستورالعمل-برپایی-معماری-detection-engineering-و-مدیریت-detection-مبتنی-بر-git-در-soc-xgrquxpblzm7 طراح: روزبه نوروزی واحد MSSP شرکت پیشگامان فناوری اطلاعات هامون 1. هدف سنداین سند با هدف طراحی و استقرار معماری استاندارد مدیریت Detectionها در SOC مبتنی بر Splunk Enterprise Security تدوین شده است. معماری ارائه‌شده تلاش می‌کند عملیات Detection Management را از مدل سنتی و وابسته به GUI به سمت یک ساختار مهندسی‌شده، Version-Controlled و قابل Audit هدایت نماید.این رویکرد در راستای مفاهیم زیر طراحی شده است:* Detection as Code* Detection Engineering* Controlled Deployment* Security Content Lifecycle Management 2. ضرورت پیاده‌سازیدر بسیاری از SOCهای سنتی، Ruleها و Correlation Searchها مستقیماً در محیط GUI ساخته و ویرایش می‌شوند. این مدل در محیط‌های Enterprise دارای چالش‌های زیر است:* نبود Version Control* دشواری Rollback* نبود Detection QA* وابستگی شدید به افراد* نبود Change Tracking* ایجاد Drift بین محیط‌های مختلف* دشواری Audit و Compliance* نبود فرآیند استاندارد Release Managementبا افزایش حجم Detection Content و پیچیدگی Threatها، استفاده از معماری Detection Engineering ضروری می‌شود. 3. معماری کلان پیشنهادیمعماری پیشنهادی واحد MSSP شرکت هامون به‌صورت زیر طراحی می‌شودDetection Analyst▼Internal Git Server (Gitea)▼Detection Repository▼Review & Approval Workflow▼Splunk App Packaging▼SH Deployer▼splunk apply shcluster-bundle▼Search Head Cluster▼Splunk Enterprise Security 4. اجزای معماری 4-1. Git Server داخلیبه‌منظور نگهداری و Version Control محتوای امنیتی، یک Git Server داخلی در شبکه سازمان راه‌اندازی می‌شود.پیشنهاد واحد MSSP:* Gitea* GitLab CEدر محیط‌های Air-Gap نیز قابل استفاده هستند. 4-2. Detection Repositoryتمام Detection Content داخل Repository مرکزی ذخیره می‌شود.5. استاندارد توسعه Detectionهر Detection باید شامل موارد زیر باشد:* SPL Query* Severity* MITRE ATT&CK Mapping* Data Source* Detection Logic* False Positive Consideration* Response Action* Naming Convention* Cron Scheduleنمونه Detection:[Suspicious PowerShell Download]search = index=wineventlog EventCode=4688 CommandLine="*Invoke-WebRequest*"cron_schedule = */5 * * * *alert_type = number of events 6. فرآیند توسعه Detection مرحله 1 : Clone Repositorybashgit clone http://gitea/splunk-detections مرحله 2 : توسعه Detectionتحلیلگر Detection جدید را در فایل‌های مربوطه ایجاد یا اصلاح می‌کند. مرحله 3 : Commit Changesgit add .git commit -m "Added PowerShell Detection" مرحله 4 : Push به Git Servergit push 7. فرآیند Review و QAتمام Detectionها باید قبل از ورود به Production مورد بررسی قرار گیرند.موارد بررسی:* صحت SPL* نرخ احتمالی False Positive* Naming Convention* MITRE ATT&CK Mapping* Performance Impact* Detection Coverage* Duplicate Detection CheckReview توسط:* SOC Lead* Detection Engineering Team* Threat Hunting Teamانجام می‌شود. 8. Splunk App Packagingتمام Detectionها در قالب Splunk App مدیریت می‌شوند.مزایا:* Version Control* Standardized Deployment* Rollback Capability* Drift Reduction* Consistent Configuration Management 9. انتقال Detection به Splunkپس از Approval، App به SH Deployer منتقل می‌شود:scp -r TA_detection_engineering deployer:/opt/splunk/etc/shcluster/apps/ 10. Deploy به Search Head Clusterروی SH Deployer:splunk apply shcluster-bundleدر این مرحله:* App روی تمام Search Headها Sync می‌شود* Detectionها فعال می‌شوند* Configurationها هماهنگ می‌شوند 11. Detection Testing و Validationپیشنهاد می‌شود Detectionها با ابزارهای زیر اعتبارسنجی شوند:* Atomic Red Team* Caldera* Prelude Operatorاهداف:* Detection Validation* ATT&CK Coverage Testing* False Positive Analysis* Regression Testing 12. مزایای معماری پیشنهادیاین معماری باعث ایجاد قابلیت‌های زیر می‌شود:* Detection Versioning* Controlled Change Management* Centralized Knowledge Management* Detection QA* استانداردسازی Deployment* کاهش وابستگی به افراد* افزایش Auditability* بهبود Detection Lifecycle* کاهش Configuration Drift* افزایش بلوغ SOC 13. نتیجه‌گیریمعماری Detection Engineering مبتنی بر Git و Splunk App Packaging، SOC را از مدل سنتی Alert Monitoring به سمت یک ساختار Engineering-Driven هدایت می‌کند.در این رویکرد:* Detectionها مانند Software مدیریت می‌شوند* تغییرات قابل کنترل و ممیزی هستند* Release Management استاندارد می‌شود* Detection Quality بهبود می‌یابد* عملیات SOC مقیاس‌پذیرتر و پایدارتر می‌شوداین معماری یکی از الزامات کلیدی SOCهای بالغ و MSSPهای مدرن محسوب می‌شود.روزبه نوروزیروزبه نوروزیFri, 22 May 2026 11:42:33 +0330https://virgool.ir/@roozbehnoroozi/همه-چیز-فانی-است-پس-چرا-تلاش-کنیم-fnt6p8jgtasvخداوند در قرآن می‌فرمایدكُلُّ مَنْ عَلَيْهَا فَانٍ ۝ وَيَبْقَىٰ وَجْهُ رَبِّكَ ذُو الْجَلَالِ وَالْإِكْرَامِ«هر که بر روی زمین است فانی می‌شود،و تنها ذاتِ باشکوه و بزرگوار پروردگارت باقی می‌ماند.»سوره: سوره الرحمنشماره آیات: ۲۶ و ۲۷ قرآن کریمگاهی انسان در میانه زندگی، ناگهان با یک حقیقت ساده اما سنگین روبه‌رو می‌شود: هیچ‌چیز ماندگار نیست. جوانی می‌گذرد، قدرت تغییر می‌کند، ثروت جابه‌جا می‌شود، آدم‌ها می‌آیند و می‌روند، و حتی چیزهایی که روزی تصور می‌کردیم ستون‌های ثابت زندگی ما هستند، ممکن است در چند لحظه فرو بریزند. شاید به همین دلیل است که برخی از عمیق‌ترین آیات و اندیشه‌های تاریخ، انسان را به فکر درباره «فانی بودن» جهان و خودش دعوت کرده‌اند. اما سؤال اصلی اینجاست: اگر همه‌چیز گذراست، پس چه چیزی واقعاً ارزش چنگ‌زدن دارد؟بیشتر انسان‌ها بخش بزرگی از زندگی خود را صرف نگه‌داشتن چیزهایی می‌کنند که ذاتاً ناپایدارند. ما به موقعیت شغلی، اعتبار اجتماعی، دارایی، روابط، یا حتی تصویری که از خودمان ساخته‌ایم وابسته می‌شویم. مشکل این وابستگی‌ها فقط از دست رفتنشان نیست؛ بلکه این است که انسان کم‌کم هویت خود را با آن‌ها اشتباه می‌گیرد. وقتی ثروت، قدرت، یا تأیید دیگران تبدیل به تعریف «خود» شود، از دست رفتن آن‌ها فقط یک فقدان ساده نیست؛ بلکه نوعی فروپاشی درونی ایجاد می‌کند.عرفان اسلامی دقیقاً در همین نقطه وارد می‌شود. عارفان نمی‌گویند دنیا بی‌ارزش است یا انسان نباید زندگی کند، بسازد، تلاش کند یا لذت ببرد. آن‌ها بیشتر هشدار می‌دهند که نباید میان «داشتن» و «بودن» اشتباه کرد. دارایی‌ها، موقعیت‌ها و موفقیت‌ها می‌توانند بخشی از زندگی باشند، اما نباید تبدیل به مرکز هویت انسان شوند. زیرا هرچه بیرونی و موقتی باشد، دیر یا زود تغییر می‌کند.در بسیاری از متون عرفانی، مفهوم «فنا» به معنای نابودی صرف نیست؛ بلکه نوعی بیداری است. یعنی انسان بفهمد که بسیاری از چیزهایی که با اضطراب حفظشان می‌کند، در اصل سایه‌هایی گذرا هستند. این نگاه قرار نیست انسان را افسرده یا بی‌انگیزه کند؛ برعکس، می‌تواند او را آزادتر کند. وقتی انسان بداند هیچ‌چیز را برای همیشه مالک نیست، شاید مهربان‌تر زندگی کند، کمتر دچار غرور شود، و ارزش لحظه‌ها را بیشتر بفهمد.از سوی دیگر، فلسفه مدرن هم به شکلی متفاوت به همین نتیجه رسیده است. بسیاری از متفکران معتقد بودند که دقیقاً چون زندگی کوتاه و ناپایدار است، معنا پیدا می‌کند. اگر همه‌چیز ابدی بود، شاید عشق، دوستی، فرصت‌ها و حتی انتخاب‌های ما ارزش خود را از دست می‌دادند. محدود بودن زمان است که به زندگی عمق می‌دهد. انسان چون می‌داند فرصت محدودی دارد، می‌تواند تصمیم بگیرد چگونه زندگی کند و چه اثری بر جهان اطرافش بگذارد.شاید به همین دلیل، پاسخ این پرسش که «چه چیزی ارزش چنگ‌زدن دارد؟» در نهایت به سمت چیزهایی می‌رود که کمتر قابل خریدن یا مالک شدن هستند. آگاهی، یادگیری، عشق، مهربانی، صداقت، معنا، و اثری که انسان در زندگی دیگران باقی می‌گذارد، از جنس چیزهایی نیستند که با گذر زمان به‌سادگی نابود شوند. ممکن است خود انسان روزی از این جهان برود، اما اثر رفتار، دانش، محبت یا حتی یک جمله امیدبخش او، در ذهن و زندگی دیگران ادامه پیدا کند.شاید انسان هیچ‌گاه نتواند جلوی فناپذیری جهان را بگیرد، اما می‌تواند انتخاب کند که در این فرصت کوتاه، به چه چیزی دل ببندد. بعضی چیزها فقط برای مدتی کوتاه در اختیار ما هستند؛ اما بعضی تجربه‌ها و ارزش‌ها، حتی اگر ناپیدا باشند، عمیق‌تر و ماندگارتر از هر دارایی ظاهری‌اند. شاید هنر واقعی زندگی همین باشد: اینکه انسان بداند چه چیزهایی را باید در آغوش گرفت، و چه چیزهایی را باید با آرامش، روزی رها کرد.روزبه نوروزیروزبه نوروزیThu, 21 May 2026 00:20:18 +0330