پیوند به بخش های دیگر مطالعه
- (شما اینجا هستید)
این مقاله چرخه انتشارات اختصاص داده شده به تضمین امنیت اطلاعات پرداخت های غیر نقدی بانکی را تکمیل می کند. در اینجا ما به مدل های تهدید عمومی اشاره می کنیم :
- .
- .
- .
- .
هشدار !!! خبرویان عزیز، این پست جالبی نیست.
بیش از 40 صفحه از مواد پنهان شده در زیر برش فراخوانی می شود کمک در کار یا تحصیل افرادی که در بانکداری یا امنیت اطلاعات تخصص دارند. این مطالب محصول نهایی مطالعه است و با لحن رسمی خشک نوشته شده است. در واقع، این موارد خالی برای اسناد داخلی در مورد امنیت اطلاعات هستند.خب سنتی «استفاده از اطلاعات مقاله برای مقاصد غیرقانونی مجازات قانونی دارد». خواندن سازنده!
اطلاعاتی برای خوانندگانی که مطالعه را با این نشریه شروع می‌کنند.
مطالعه در مورد چیست
شما در حال خواندن راهنمای متخصصی هستید که مسئول تضمین امنیت اطلاعات پرداخت ها در بانک است.
منطق ارائه
در ابتدا در и شرح موضوع حفاظت داده شده است. سپس در نحوه ساخت یک سیستم حفاظتی را می گوید و در مورد نیاز به ایجاد یک مدل تهدید صحبت می کند. که در این نشان می دهد که مدل های تهدید چیست و چگونه شکل می گیرند. که در и تجزیه و تحلیل حملات واقعی داده شده است. и شامل توصیفی از مدل تهدید ساخته شده با در نظر گرفتن اطلاعات تمام قسمت های قبلی است.
مدل تهدیدات معمولی. اتصال شبکه
شی حفاظتی که مدل تهدید برای آن اعمال می شود (محدوده)
هدف حفاظت، داده هایی است که از طریق یک اتصال شبکه که در شبکه های داده ساخته شده بر اساس پشته TCP/IP کار می کند، منتقل می شود.
معماری
شرح عناصر معماری:
- "گره های پایانی" - گره هایی که اطلاعات محافظت شده را مبادله می کنند.
- "گره های میانی" - عناصر شبکه انتقال داده: روترها، سوئیچ ها، سرورهای دسترسی، سرورهای پروکسی و سایر تجهیزات - که از طریق آنها ترافیک اتصال شبکه منتقل می شود. به طور کلی، یک اتصال شبکه می تواند بدون گره های میانی (مستقیم بین گره های انتهایی) کار کند.
تهدیدات امنیتی سطح بالا
تجزیه
U1. دسترسی غیرمجاز به داده های ارسال شده
U2. تغییر غیرمجاز داده های ارسال شده
U3. نقض حق نویسندگی داده های ارسال شده.
U1. دسترسی غیرمجاز به داده های ارسال شده
تجزیه
U1.1. <...>، بر روی گره های نهایی یا میانی انجام می شود:
U1.1.1. <…> با خواندن داده ها در حالی که در دستگاه های ذخیره سازی گره هستند:
U1.1.1.1. <…> در رم.
توضیحات نسخه 1.1.1.1.
به عنوان مثال، در هنگام پردازش داده ها توسط پشته شبکه گره.
U1.1.1.2. <…> در حافظه غیر فرار.
توضیحات نسخه 1.1.1.2.
به عنوان مثال، هنگام ذخیره داده های ارسال شده در حافظه پنهان، فایل های موقت یا فایل های صفحه بندی.
Y1.2. <…> روی گره های شبکه داده شخص ثالث انجام می شود:
U1.2.1. <...> با گرفتن تمام بسته هایی که روی رابط شبکه گره قرار می گیرند:
توضیحات نسخه 1.2.1.
همه بسته‌ها با تغییر کارت شبکه به حالت بی‌وقفه (حالت غیرقانونی برای آداپتورهای سیمی یا حالت مانیتور برای آداپتورهای Wi-Fi) ضبط می‌شوند.
U1.2.2. <…> با انجام حملات Man-in-the-Middle (MiTM)، اما بدون تغییر داده های ارسال شده (بدون احتساب داده های سرویس پروتکل های شبکه).
Y1.2.2.1. ارتباط دادن: .
Y1.3. <...>، به دلیل نشت اطلاعات از طریق کانال های فنی (TCUI) از گره های فیزیکی یا خطوط ارتباطی انجام می شود.
U1.4. <...>، برای نصب ابزارهای فنی ویژه (STS) بر روی گره های نهایی یا میانی، که برای حذف پنهان اطلاعات در نظر گرفته شده است، انجام می شود.
U2. تغییر غیرمجاز داده های ارسال شده
تجزیه
Y2.1. <...>، بر روی گره های نهایی یا میانی انجام می شود:
Y2.1.1. <...> با خواندن و اصلاح داده ها در حالی که در دستگاه های ذخیره سازی گره ها هستند:
Y2.1.1.1. <...> در رم:
Y2.1.1.2. <…> در حافظه غیر فرار:
Y2.2. <...> روی گره های شبکه داده شخص ثالث انجام می شود:
U2.2.1. <…> با انجام حملات Man-in-the-Middle (MiTM) و هدایت ترافیک به میزبان مخرب:
Y2.2.1.1. اتصال فیزیکی تجهیزات مهاجمان برای قطع اتصال شبکه.
Y2.2.1.2. اجرای حملات به پروتکل های شبکه:
Y2.2.1.2.1. <…> مدیریت شبکه محلی مجازی (VLAN):
Y2.2.1.2.1.1. .
Y2.2.1.2.1.2. تغییر غیرمجاز تنظیمات VLAN روی سوئیچ ها یا روترها.
Y2.2.1.2.2. <…> مسیریابی ترافیک:
Y2.2.1.2.2.1. تغییر غیرمجاز جداول مسیریابی استاتیک روترها.
Y2.2.1.2.2.2. اعلام مسیرهای جعلی توسط مهاجمان از طریق پروتکل های مسیریابی پویا.
Y2.2.1.2.3. <…> پیکربندی خودکار:
Y2.2.1.2.3.1. .
Y2.2.1.2.3.2. .
Y2.2.1.2.4. <…> آدرس دهی و تفکیک نام:
Y2.2.1.2.4.1. .
Y2.2.1.2.4.2. .
Y2.2.1.2.4.3. ایجاد تغییرات غیرمجاز در فایل‌های نام میزبان محلی (هاست، lmhost و غیره)
U3. نقض حق نویسندگی داده های ارسال شده
تجزیه
Y3.1. خنثی سازی مکانیسم های تعیین نویسندگی اطلاعات با نشان دادن اطلاعات نادرست در مورد نویسنده یا منبع داده:
Y3.1.1. تغییر اطلاعات مربوط به نویسنده موجود در اطلاعات ارسال شده.
Y3.1.1.1. خنثی سازی حفاظت رمزنگاری از یکپارچگی و تألیف داده های ارسال شده:
Y3.1.1.1.1. ارتباط دادن: .
Y3.1.1.2. خنثی سازی حفاظت از تألیف داده های ارسالی، با استفاده از کدهای تأیید یک بار مصرف اجرا شده است:
Y3.1.1.2.1. .
Y3.1.2. تغییر اطلاعات در مورد منبع اطلاعات ارسال شده:
Y3.1.2.1. .
Y3.1.2.2. .
مدل تهدیدات معمولی. سیستم اطلاعاتی ساخته شده بر اساس معماری مشتری-سرور
شی حفاظتی که مدل تهدید برای آن اعمال می شود (محدوده)
هدف حفاظت یک سیستم اطلاعاتی است که بر اساس معماری مشتری-سرور ساخته شده است.
معماری
شرح عناصر معماری:
- "مشتری" - دستگاهی که بخش مشتری از سیستم اطلاعاتی بر روی آن کار می کند.
- "سرور" - دستگاهی که قسمت سرور سیستم اطلاعاتی روی آن کار می کند.
- "فروشگاه داده" - بخشی از زیرساخت سرور سیستم اطلاعاتی که برای ذخیره داده های پردازش شده توسط سیستم اطلاعاتی طراحی شده است.
- "اتصال شبکه" - یک کانال تبادل اطلاعات بین مشتری و سرور که از شبکه انتقال داده عبور می کند. برای توضیح دقیق‌تر مدل المان، نگاه کنید .
محدودیت
هنگام مدل سازی یک شی، محدودیت های زیر تعیین می شود:
- کاربر در بازه های زمانی محدودی که جلسات کاری نامیده می شود، با سیستم اطلاعات تعامل می کند.
- در ابتدای هر جلسه، کاربر شناسایی، احراز هویت و مجاز می شود.
- تمام اطلاعات محافظت شده در قسمت سرور سیستم اطلاعات ذخیره می شود.
تهدیدات امنیتی سطح بالا
تجزیه
U1. مهاجمانی که اقدامات غیرمجاز را از طرف یک کاربر قانونی انجام می دهند.
U2. تغییر غیرمجاز اطلاعات محافظت شده در طول پردازش آن توسط بخش سرور سیستم اطلاعاتی.
U1. مهاجمانی که اقدامات غیرمجاز را از طرف یک کاربر قانونی انجام می دهند
توضیحات
معمولاً در سیستم های اطلاعاتی، ارتباط اقدامات با کاربری که آنها را انجام داده است با استفاده از موارد زیر انجام می شود:
- سیاهههای مربوط به سیستم (logs).
- ویژگی های خاص اشیاء داده حاوی اطلاعاتی در مورد کاربری که آنها را ایجاد یا تغییر داده است.
در رابطه با یک جلسه کاری، این تهدید را می توان به موارد زیر تقسیم کرد:
- <…> در جلسه کاربر انجام شد.
- <…> خارج از جلسه کاربر انجام می شود.
یک جلسه کاربر را می توان آغاز کرد:
- توسط خود کاربر
- مزاحمان.
در این مرحله، تجزیه میانی این تهدید به این صورت خواهد بود:
U1.1. اقدامات غیرمجاز انجام شده در جلسه کاربر:
U1.1.1. <…> توسط کاربر مورد حمله تنظیم شده است.
U1.1.2. <…> توسط مهاجمان نصب شده است.
Y1.2. اقدامات غیرمجاز خارج از جلسه کاربر انجام شد.
از نقطه نظر اشیاء زیرساخت اطلاعاتی که می توانند توسط متجاوزان تحت تأثیر قرار گیرند، تجزیه تهدیدهای میانی به این صورت خواهد بود:
آیتم ها
تجزیه تهدید
Y1.1.1.
Y1.1.2.
Y1.2.
مشتری
Y1.1.1.1.
Y1.1.2.1.
اتصال شبکه
Y1.1.1.2.
سرور
Y1.2.1.
تجزیه
U1.1. اقدامات غیرمجاز انجام شده در جلسه کاربر:
U1.1.1. <…> تنظیم شده توسط کاربر مورد حمله:
U1.1.1.1. مهاجمان به طور مستقل از مشتری عمل کردند:
U1.1.1.1.1 مهاجمان از ابزارهای استاندارد دسترسی به سیستم اطلاعاتی استفاده می کردند:
Y1.1.1.1.1.1. مهاجمان از وسایل ورودی/خروجی فیزیکی مشتری (صفحه کلید، ماوس، مانیتور یا صفحه لمسی یک دستگاه تلفن همراه) استفاده کردند:
Y1.1.1.1.1.1.1. مهاجمان در دوره‌های زمانی که جلسه فعال است، امکانات ورودی/خروجی در دسترس است و کاربر دور است، عمل می‌کنند.
Y1.1.1.1.1.2. مهاجمان از ابزارهای مدیریت راه دور (استاندارد یا ارائه شده توسط کد مخرب) برای مدیریت کلاینت استفاده کردند:
Y1.1.1.1.1.2.1. مهاجمان در دوره‌های زمانی که جلسه فعال است، امکانات ورودی/خروجی در دسترس است و کاربر دور است، عمل می‌کنند.
Y1.1.1.1.1.2.2. مهاجمان از ابزارهای مدیریت از راه دور استفاده کردند که عملکرد آنها برای کاربر مورد حمله نامرئی است.
U1.1.1.2. مهاجمان داده های موجود در اتصال شبکه بین مشتری و سرور را جعل کرده و آنها را به گونه ای تغییر دادند که به عنوان اقدامات یک کاربر قانونی تلقی شود:
Y1.1.1.2.1. ارتباط دادن: .
U1.1.1.3. مهاجمان کاربر را مجبور کردند تا با استفاده از روش های مهندسی اجتماعی اقداماتی را که مشخص کرده اند انجام دهد.
U1.1.2 <…> توسط مهاجمان تنظیم شده است:
Y1.1.2.1. مهاجمان از مشتری (И):
Y1.1.2.1.1. مهاجمان سیستم کنترل دسترسی سیستم اطلاعاتی را خنثی کردند:
Y1.1.2.1.1.1. ارتباط دادن: .
Y1.1.2.1.2. بدکاران از ابزارهای منظم دسترسی به سیستم اطلاعاتی استفاده می کردند
U1.1.2.2. مهاجمان از سایر گره‌های شبکه انتقال داده عمل می‌کنند که از آنها امکان برقراری ارتباط شبکه با سرور وجود دارد.И):
Y1.1.2.2.1. مهاجمان سیستم کنترل دسترسی سیستم اطلاعاتی را خنثی کردند:
Y1.1.2.2.1.1. ارتباط دادن: .
Y1.1.2.2.2. مهاجمان از ابزارهای غیر استاندارد برای دسترسی به سیستم اطلاعاتی استفاده کردند.
توضیحات Y1.1.2.2.2.
مهاجمان می‌توانند یک کلاینت سیستم اطلاعاتی معمولی را روی یک گره شخص ثالث نصب کنند یا می‌توانند از نرم‌افزار غیر استانداردی استفاده کنند که پروتکل‌های تبادل استاندارد بین کلاینت و سرور را پیاده‌سازی می‌کند.
P1.2 اقدامات غیرمجاز انجام شده در خارج از جلسه کاربر.
S1.2.1 مهاجمان اقدامات غیرمجاز انجام دادند و سپس تغییرات غیرمجاز را در گزارش‌های سیستم اطلاعاتی یا ویژگی‌های خاص اشیاء داده ایجاد کردند، که نشان می‌دهد اقداماتی که انجام داده‌اند توسط یک کاربر قانونی انجام شده است.
U2. تغییر غیرمجاز اطلاعات محافظت شده در طول پردازش آن توسط بخش سرور سیستم اطلاعاتی
تجزیه
Y2.1. مهاجمان اطلاعات محافظت شده را با استفاده از ابزارهای استاندارد سیستم اطلاعاتی اصلاح می کنند و این کار را از طرف یک کاربر قانونی انجام می دهند.
Y2.1.1. ارتباط دادن: .
Y2.2. مهاجمان اطلاعات محافظت شده را با استفاده از مکانیسم‌های دسترسی به داده‌ها که توسط عملکرد منظم سیستم اطلاعاتی پیش‌بینی نشده‌اند، اصلاح می‌کنند.
U2.2.1. مهاجمان فایل های حاوی اطلاعات محافظت شده را تغییر می دهند:
Y2.2.1.1. <…> با استفاده از مکانیسم های دستکاری فایل ارائه شده توسط سیستم عامل.
Y2.2.1.2. <...> با تحریک بازیابی فایل ها از یک نسخه پشتیبان اصلاح شده غیرمجاز.
U2.2.2. Malefactor ها اطلاعات محافظت شده ذخیره شده در پایگاه داده را تغییر می دهند (И):
Y2.2.2.1. مهاجمان سیستم کنترل دسترسی DBMS را خنثی می کنند:
Y2.2.2.1.1. ارتباط دادن: .
Y2.2.2.2. مهاجمان اطلاعات را با استفاده از رابط های استاندارد DBMS برای دسترسی به داده ها تغییر می دهند.
Y2.3. عوامل مخرب اطلاعات محافظت شده را با اصلاح غیرمجاز الگوریتم های کار نرم افزار پردازش آن تغییر می دهند.
Y2.3.1. تغییراتی در کد منبع نرم افزار انجام می شود.
Y2.3.1. تغییراتی در کد ماشین نرم افزار انجام می شود.
Y2.4. مهاجمان با سوء استفاده از آسیب پذیری ها در نرم افزار سیستم اطلاعات، اطلاعات محافظت شده را اصلاح می کنند.
Y2.5. مهاجمان اطلاعات محافظت شده را هنگامی که بین اجزای بخش سرور سیستم اطلاعاتی (مثلاً سرور پایگاه داده و سرور برنامه) منتقل می شود، تغییر می دهند.
Y2.5.1. ارتباط دادن: .
مدل تهدیدات معمولی. سیستم کنترل دسترسی
شی حفاظتی که مدل تهدید برای آن اعمال می شود (محدوده)
شی حفاظتی که این مدل تهدید برای آن اعمال می شود، مطابق با هدف حفاظتی مدل تهدید است: «مدل تهدید معمولی. یک سیستم اطلاعاتی که بر اساس معماری مشتری-سرور ساخته شده است.
سیستم کنترل دسترسی کاربر در این مدل تهدید به عنوان یک جزء سیستم اطلاعاتی درک می شود که عملکردهای زیر را اجرا می کند:
- شناسایی کاربر
- احراز هویت کاربر
- مجوزهای کاربر
- ثبت اقدامات کاربر
تهدیدات امنیتی سطح بالا
تجزیه
U1. ایجاد غیرمجاز یک جلسه از طرف یک کاربر قانونی.
U2. افزایش غیرمجاز امتیازات کاربر در سیستم اطلاعاتی.
U1. ایجاد جلسه غیرمجاز از طرف یک کاربر قانونی
توضیحات
تجزیه این تهدید در حالت کلی به نوع سیستم های شناسایی و احراز هویت کاربر مورد استفاده بستگی دارد.
در این مدل تنها سیستم شناسایی و احراز هویت کاربر با استفاده از لاگین متنی و رمز عبور در نظر گرفته خواهد شد. در این مورد، فرض می کنیم که ورود کاربر، اطلاعات عمومی شناخته شده توسط مهاجمان است.
تجزیه
U1.1. <…> با به خطر انداختن اعتبارنامه ها:
U1.1.1. مهاجمان اعتبار کاربر را در حین ذخیره سازی به خطر انداختند.
توضیحات Y1.1.1.
به عنوان مثال، اعتبارنامه ها را می توان روی یک یادداشت چسبناک که روی مانیتور چسبانده شده است، نوشت.
U1.1.2. کاربر به طور تصادفی یا مخرب جزئیات دسترسی را در اختیار مهاجمان قرار داد.
Y1.1.2.1. کاربر هنگام ورود، اعتبارنامه را با صدای بلند بیان کرد.
U1.1.2.2. کاربر به طور عمدی اعتبار خود را ارسال کرد:
Y1.1.2.2.1. <…> همکاران در محل کار.
توضیحات Y1.1.2.2.1.
مثلاً برای اینکه آن را با یک دوره بیماری جایگزین کنند.
Y1.1.2.2.2. <…> به طرف مقابل کارفرما که روی اشیاء زیرساخت اطلاعاتی کار می کند.
Y1.1.2.2.3. <…> به اشخاص ثالث.
توضیحات Y1.1.2.2.3.
یکی، اما نه تنها راه برای اجرای این تهدید، استفاده از روش های مهندسی اجتماعی توسط مهاجمان است.
U1.1.3. مهاجمان مدارک را به صورت بی رحمانه تحمیل کردند:
Y1.1.3.1. <…> با استفاده از مکانیسم های دسترسی منظم.
U1.1.3.2. <...> توسط کدهایی که قبلاً رهگیری شده بودند (مثلاً هش رمز عبور) برای ذخیره اعتبار.
U1.1.4. مهاجمان از کدهای مخرب برای رهگیری اطلاعات کاربری کاربر استفاده کردند.
U1.1.5. مهاجمان اعتبار را از یک اتصال شبکه بین مشتری و سرور استخراج کردند:
Y1.1.5.1. ارتباط دادن: .
U1.1.6. مهاجمان اعتبارنامه هایی را از سوابق سیستم های نظارت بر کار استخراج کردند:
U1.1.6.1. <…> سیستم های نظارت تصویری (در صورتی که ضربه های کلید روی صفحه کلید در حین کار ضبط شده باشد).
U1.1.6.2. سیستم های <…> برای نظارت بر اعمال کارکنان در رایانه
توضیحات Y1.1.6.2.
نمونه ای از چنین سیستمی است .
U1.1.7. مهاجمان به دلیل نقص در فرآیند انتقال، اعتبار کاربر را به خطر انداختند.
توضیحات Y1.1.7.
به عنوان مثال، انتقال رمزهای عبور به صورت متن واضح از طریق ایمیل.
U1.1.8. مهاجمان با نظارت بر جلسه کاربر با استفاده از سیستم های مدیریت از راه دور، اعتبارنامه ها را دریافت کردند.
U1.1.9. مهاجمان اعتبارنامه ها را در نتیجه نشت آنها از طریق کانال های فنی (TCUE) استخراج کردند:
U1.1.9.1. مهاجمان از نحوه وارد کردن اعتبار کاربر از صفحه کلید جاسوسی کردند:
E1.1.9.1.1 مهاجمان در مجاورت کاربر قرار داشتند و با چشمان خود ورود اطلاعات را مشاهده کردند.
C1.1.9.1.1 توضیحات
چنین مواردی شامل اقدامات همکاران در محل کار یا مواردی است که صفحه کلید کاربر برای بازدیدکنندگان سازمان قابل مشاهده است.
E1.1.9.1.2 مهاجمان از وسایل فنی اضافی مانند دوربین دوچشمی یا هواپیمای بدون سرنشین استفاده کردند و ورود مدارک را از پنجره مشاهده کردند.
U1.1.9.2. مهاجمان در صورتی که از طریق رابط رادیویی (مثلاً بلوتوث) وصل شده باشند، اعتبارنامه ها را از سوابق تبادل رادیویی بین صفحه کلید و واحد سیستم رایانه استخراج می کردند.
U1.1.9.3. مهاجمان اعتبارنامه ها را با نشت آنها از طریق کانال تشعشعات الکترومغناطیسی جعلی و پیکاپ ها (PEMIN) رهگیری کردند.
توضیحات Y1.1.9.3.
نمونه های حمله и .
U1.1.9.4. مهاجم با استفاده از ابزارهای فنی ویژه (STS) که برای حذف مخفیانه اطلاعات طراحی شده بود، ورودی اعتبارنامه ها را از صفحه کلید رهگیری کرد.
توضیحات Y1.1.9.4.
نمونه .
U1.1.9.5. مهاجمان با استفاده از ورودی اعتبارنامه ها از صفحه کلید رهگیری کردند
تجزیه و تحلیل سیگنال Wi-Fi که توسط فرآیند فشار دادن کلیدها توسط کاربر مدوله شده است.
توضیحات Y1.1.9.5.
مثال .
U1.1.9.6. مهاجمان با تجزیه و تحلیل صداهای ضربه‌های کلید، ورودی اطلاعات را از صفحه کلید رهگیری کردند.
توضیحات Y1.1.9.6.
مثال .
U1.1.9.7. مهاجمان با تجزیه و تحلیل خوانش‌های شتاب‌سنج، ورودی اعتبارنامه‌ها را از صفحه کلید یک دستگاه تلفن همراه رهگیری کردند.
توضیحات Y1.1.9.7.
مثال .
U1.1.10. <...> قبلاً در Client ذخیره شده است.
توضیحات Y1.1.10.
به عنوان مثال، یک کاربر می تواند نام کاربری و رمز عبور را در مرورگر ذخیره کند تا به یک سایت خاص دسترسی پیدا کند.
U1.1.11. مهاجمان اعتبارنامه ها را به دلیل نقص در فرآیند لغو دسترسی کاربر به خطر انداختند.
توضیحات Y1.1.11.
به عنوان مثال، پس از اخراج یک کاربر، حساب های او مسدود نشدند.
Y1.2. <…> با بهره برداری از آسیب پذیری ها در سیستم کنترل دسترسی.
U2. افزایش غیرمجاز امتیازات کاربر در سیستم اطلاعاتی
تجزیه
P2.1 <...> با ایجاد تغییرات غیرمجاز در داده های حاوی اطلاعات مربوط به امتیازات کاربر.
U2.2 <…> با بهره برداری از آسیب پذیری ها در سیستم کنترل دسترسی.
Y2.3. <…> به دلیل نقص در فرآیند کنترل دسترسی کاربر.
توضیحات Y2.3.
مثال 1. به یک کاربر به دلیل نیازهای رسمی بیش از آنچه نیاز داشت به کار دسترسی پیدا کرد.
مثال 2: پس از انتقال کاربر به موقعیت دیگری، حقوق دسترسی قبلاً اعطا شده لغو نشد.
مدل تهدیدات معمولی. ماژول ادغام
شی حفاظتی که مدل تهدید برای آن اعمال می شود (محدوده)
ماژول یکپارچه سازی - مجموعه ای از اشیاء زیرساخت اطلاعاتی طراحی شده برای سازماندهی تبادل اطلاعات بین سیستم های اطلاعاتی.
با در نظر گرفتن این واقعیت که در شبکه های شرکتی همیشه نمی توان به طور واضح یک سیستم اطلاعاتی را از دیگری جدا کرد، ماژول یکپارچه سازی را می توان به عنوان پیوند بین اجزای یک سیستم اطلاعاتی نیز در نظر گرفت.
معماری
طرح کلی ماژول ادغام به صورت زیر است:
شرح عناصر معماری:
- "سرور تبادل (CO)" - یک گره / سرویس / جزء یک سیستم اطلاعاتی که وظیفه تبادل داده با یک سیستم اطلاعاتی دیگر را انجام می دهد.
- "میانجی" - یک گره / سرویس طراحی شده برای سازماندهی تعامل بین سیستم های اطلاعاتی، اما نه بخشی از آنها.
مثال ها "واسطه ها" می تواند خدمات ایمیل، گذرگاه خدمات سازمانی / معماری SoA، سرورهای فایل شخص ثالث و غیره باشد. به طور کلی، ماژول ادغام ممکن است حاوی "واسطه" نباشد. - "نرم افزار پردازش داده" - مجموعه ای از برنامه ها که پروتکل های تبادل داده و تبدیل فرمت را پیاده سازی می کند.
به عنوان مثال، تبدیل داده ها از فرمت UFEBS به فرمت ABS، تغییر وضعیت پیام در حین انتقال و غیره. - "اتصال شبکه" مطابق با شی توصیف شده در مدل تهدید معمولی "اتصال شبکه". برخی از اتصالات شبکه از اتصالات ارائه شده در نمودار بالا ممکن است نباشند.
نمونه هایی از ماژول های یکپارچه سازی
طرح 1. یکپارچه سازی ABS و AWP KBR از طریق یک سرور فایل شخص ثالث
برای انجام پرداخت ها، یک کارمند مجاز بانک اسناد پرداخت الکترونیکی را از ABS بارگذاری می کند و آنها را در یک فایل (با فرمت خود، به عنوان مثال، SQL dump) در پوشه شبکه (...SHARE) سرور فایل ذخیره می کند. سپس این فایل با استفاده از یک اسکریپت مبدل به مجموعه ای از فایل ها در فرمت UFEBS تبدیل می شود که سپس توسط CBD AWP خوانده می شود.
پس از آن، یک کارمند مجاز - کاربر AWS CBD - فایل دریافتی را رمزگذاری و امضا می کند و آنها را به سیستم پرداخت بانک روسیه ارسال می کند.
پس از دریافت پرداخت ها از بانک روسیه، AWP CBR آنها را رمزگشایی می کند و امضای الکترونیکی را بررسی می کند و پس از آن آنها را به عنوان مجموعه ای از فایل ها در قالب UFEBS در سرور فایل می نویسد. قبل از وارد کردن اسناد پرداخت به ABS، آنها با استفاده از یک مبدل اسکریپت از فرمت UFEBS به فرمت ABS تبدیل می شوند.
ما فرض می کنیم که در این طرح، ABS روی یک سرور فیزیکی کار می کند، ایستگاه کاری CBD روی یک کامپیوتر اختصاصی کار می کند، و مبدل اسکریپت روی یک سرور فایل کار می کند.
مطابقت اشیاء طرح در نظر گرفته شده با عناصر مدل ماژول ادغام:
"تبادل سرورها از سمت ABS" - سرور ABS
"تبادل سرورها از سمت AWP KBR" - ایستگاه کاری کامپیوتر KBR.
"میانجی" - سرور فایل شخص ثالث
"نرم افزار پردازش داده" - مبدل اسکریپت
طرح 2. ادغام ABS و AWS KBR هنگام قرار دادن یک پوشه شبکه مشترک با پرداخت در AWS KBR
همه چیز شبیه طرح 1 است، اما از یک سرور فایل جداگانه استفاده نمی‌شود؛ در عوض، یک پوشه شبکه (…SHARE) با اسناد پرداخت الکترونیکی روی رایانه‌ای با AWS CBD قرار دارد. مبدل اسکریپت همچنین روی AWP CBD کار می کند.
مطابقت اشیاء طرح در نظر گرفته شده با عناصر مدل ماژول ادغام:
مشابه طرح 1، اما "میانجی" استفاده نشده.
طرح 3. ادغام ABS و AWS KBR-N از طریق IBM WebSphera MQ و امضای اسناد الکترونیکی "در سمت ABS"
ABS روی پلت فرمی کار می کند که توسط CIPF SKAD Signature پشتیبانی نمی شود. اسناد الکترونیکی خروجی بر روی یک سرور امضای الکترونیکی ویژه (ES Server) امضا می شوند. همان سرور امضای الکترونیکی را در اسناد دریافتی از بانک روسیه تأیید می کند.
ABS فایلی را با اسناد پرداخت در قالب خاص خود به سرور ES آپلود می کند.
سرور ES با استفاده از یک اسکریپت مبدل، فایل را به پیام های الکترونیکی در قالب UFEBS تبدیل می کند، پس از آن پیام های الکترونیکی امضا شده و به IBM WebSphere MQ منتقل می شود.
AWS KBR-N به IBM WebSphere MQ دسترسی پیدا می کند و پیام های پرداخت امضا شده را از آنجا دریافت می کند، پس از آن یک کارمند مجاز - کاربر AWS KBR - آنها را رمزگذاری کرده و به سیستم پرداخت بانک روسیه می فرستد.
پس از دریافت پرداخت ها از بانک روسیه، AWP KBR-N آنها را رمزگشایی می کند و امضای الکترونیکی را تأیید می کند. پرداخت‌های پردازش شده با موفقیت در قالب پیام‌های الکترونیکی رمزگشایی و امضا شده در قالب UFEBS به IBM WebSphere MQ منتقل می‌شوند و از آنجا توسط سرور ES دریافت می‌شوند.
سرور ES امضای الکترونیکی پرداخت های دریافتی را تأیید می کند و آنها را در یک فایل با فرمت ABS ذخیره می کند. پس از آن، یک کارمند مجاز - کاربر ABS - فایل حاصل را به روش مقرر در ABS آپلود می کند.
مطابقت اشیاء طرح در نظر گرفته شده با عناصر مدل ماژول ادغام:
"سرور تبادل از سمت ABS" - سرور ABS
"سرور تبادل از سمت AWP KBR" - ایستگاه کاری کامپیوتر KBR.
"میانجی" - سرور ES و IBM WebSphere MQ.
"نرم افزار پردازش داده" – مبدل اسکریپت، امضای CIPF SCAD در سرور ES.
طرح 4. یکپارچه سازی سرور RBS و ABS از طریق API ارائه شده توسط یک سرور تبادل اختصاصی
ما فرض می کنیم که بانک از چندین سیستم بانکداری راه دور (RBS) استفاده می کند:
- "اینترنت مشتری-بانک" برای افراد (ICB FL)؛
- "اینترنت مشتری-بانک" برای اشخاص حقوقی (ICB LE).
به منظور اطمینان از امنیت اطلاعات، تمام تعاملات ABS با سیستم های RB از طریق یک سرور تبادل اختصاصی که در چارچوب سیستم اطلاعاتی ABS کار می کند انجام می شود.
در مرحله بعد، ما روند تعامل سیستم RBS ICB LE با ABS را در نظر خواهیم گرفت.
سرور RBS با دریافت یک دستور پرداخت معتبر از مشتری، باید یک سند مناسب در ABS بر اساس آن ایجاد کند. برای انجام این کار، با استفاده از API، اطلاعات را به سرور تبادل منتقل می کند که به نوبه خود داده ها را به ABS وارد می کند.
هنگامی که موجودی حساب مشتری تغییر می کند، ABS اعلان های الکترونیکی ایجاد می کند که با استفاده از سرور تبادل به سرور RBS منتقل می شود.
مطابقت اشیاء طرح در نظر گرفته شده با عناصر مدل ماژول ادغام:
"تبادل سرور از RBS" – سرور RBS IKB YUL.
"سرور تبادل از سمت ABS" - سرور تبادل
"میانجی" - گم شده
"نرم افزار پردازش داده" – اجزای سرور RB مسئول استفاده از API سرور تبادل، اجزای سرور مبادله مسئول استفاده از ABS ABS.
تهدیدات امنیتی سطح بالا
تجزیه
U1. معرفی اطلاعات نادرست توسط عوامل بدخواه از طریق ماژول یکپارچه سازی.
U1. معرفی اطلاعات نادرست توسط مهاجمان از طریق ماژول یکپارچه سازی
تجزیه
U1.1. اصلاح غیرمجاز داده های قانونی در حین انتقال آن از طریق اتصالات شبکه:
لینک U1.1.1: .
Y1.2. انتقال داده های نادرست از طریق کانال های ارتباطی از طرف یک شرکت کننده قانونی تبادل:
لینک U1.1.2: .
Y1.3. تغییر غیرمجاز داده های قانونی در طول پردازش آنها در سرورهای Exchange یا واسطه:
Y1.3.1. ارتباط دادن: .
U1.4. ایجاد داده های جعلی در سرورهای Exchange یا واسطه از طرف یک شرکت کننده قانونی تبادل:
Y1.4.1. ارتباط دادن:
Y1.5. اصلاح غیرمجاز داده ها در حین پردازش آنها با استفاده از نرم افزار پردازش داده:
U1.5.1. <…> به دلیل ایجاد تغییرات غیرمجاز توسط مزاحمان در تنظیمات (پیکربندی) نرم افزار پردازش داده.
U1.5.2. <…> به دلیل ایجاد تغییرات غیرمجاز توسط مزاحمان در فایل های اجرایی نرم افزار پردازش داده.
U1.5.3. <...> به دلیل کنترل تعاملی نرم افزار پردازش داده توسط مهاجمان.
مدل تهدیدات معمولی. سیستم حفاظت از اطلاعات رمزنگاری
شی حفاظتی که مدل تهدید برای آن اعمال می شود (محدوده)
هدف حفاظت، سیستم حفاظت اطلاعات رمزنگاری است که برای تضمین امنیت سیستم اطلاعاتی استفاده می شود.
معماری
اساس هر سیستم اطلاعاتی نرم افزار (نرم افزار) کاربردی است که عملکرد هدف خود را پیاده سازی می کند.
حفاظت رمزنگاری در این مورد معمولاً با فراخوانی رمزهای اولیه از منطق تجاری نرم افزار کاربردی که در کتابخانه های تخصصی - کریپتو کرنل ها قرار دارند، اجرا می شود.
رمزنگاری های اولیه شامل توابع رمزنگاری سطح پایین مانند:
- رمزگذاری/رمزگشایی بلوک داده؛
- امضای الکترونیکی بلوک داده را ایجاد / تأیید کنید.
- محاسبه تابع هش بلوک داده؛
- اطلاعات کلیدی را تولید / آپلود / بارگذاری کنید.
- غیره
منطق تجاری نرم افزار کاربردی، با استفاده از رمزنگاری های اولیه، یک عملکرد سطح بالاتر را پیاده سازی می کند:
- فایل را با کلیدهای گیرندگان انتخاب شده رمزگذاری کنید.
- ایجاد یک اتصال شبکه ایمن؛
- در مورد نتایج تأیید امضای الکترونیکی اطلاع دهید.
- و غیره
تعامل منطق تجاری و کریپتو هسته را می توان انجام داد:
- به طور مستقیم، با فراخوانی رمزنگاری های اولیه از کتابخانه های پویا کریپتوکرنل (.DLL - برای ویندوز، .SO - برای لینوکس) توسط منطق تجاری.
- به طور مستقیم، از طریق رابط های رمزنگاری - wrapper ها، به عنوان مثال، MS Crypto API، Java Cryptography Architecture، PKCS # 11، و غیره. در این مورد، منطق تجاری به رابط رمزنگاری اشاره دارد و تماس را به هسته رمزنگاری مربوطه ترجمه می کند. در این مورد ارائه دهنده رمزنگاری نامیده می شود. استفاده از رابط های رمزنگاری به نرم افزارهای کاربردی اجازه می دهد تا از الگوریتم های رمزنگاری خاص انتزاع کرده و انعطاف پذیرتر باشند.
دو طرح معمولی برای سازماندهی یک کریپتوکر وجود دارد:
طرح 1 - کریپتو هسته یکپارچه
طرح 2 - هسته رمزنگاری را تقسیم کنید
عناصر موجود در نمودارهای بالا می‌توانند ماژول‌های نرم‌افزار جداگانه‌ای باشند که روی یک رایانه اجرا می‌شوند، یا خدمات شبکه‌ای که در یک شبکه رایانه‌ای در تعامل هستند.
هنگام استفاده از سیستم‌هایی که طبق طرح 1 ساخته شده‌اند، نرم‌افزار کاربردی و هسته رمزنگاری در یک محیط واحد برای عملکرد یک ابزار رمزنگاری (CFC) کار می‌کنند، به عنوان مثال، روی یک رایانه که همان سیستم عامل را اجرا می‌کند. کاربر سیستم، به عنوان یک قاعده، می تواند برنامه های دیگری را در همان محیط عملیاتی اجرا کند، از جمله برنامه هایی که حاوی کدهای مخرب هستند. در چنین شرایطی، خطر جدی نشت کلیدهای رمزنگاری خصوصی وجود دارد.
برای به حداقل رساندن خطر، از طرح 2 استفاده می شود که در آن کریپتوکور به دو بخش تقسیم می شود:
- قسمت اول به همراه نرم افزار کاربردی در محیطی غیر قابل اعتماد اجرا می شود که خطر آلودگی به بدافزار وجود دارد. ما این بخش را "بخش نرم افزاری" می نامیم.
- بخش دوم در یک محیط قابل اعتماد روی یک دستگاه اختصاصی که حاوی یک فروشگاه کلید خصوصی است کار می کند. از این به بعد از این قسمت به عنوان "بخش سخت افزاری" یاد می کنیم.
تقسیم کریپتو کرنل به بخش های نرم افزاری و سخت افزاری بسیار مشروط است. سیستم هایی در بازار وجود دارد که طبق این طرح با یک هسته رمزنگاری تقسیم شده ساخته شده اند ، اما بخش "سخت افزار" آن به عنوان تصویر ماشین مجازی - HSM مجازی ().
تعامل هر دو بخش کریپتوکور به گونه‌ای اتفاق می‌افتد که کلیدهای رمزنگاری خصوصی هرگز به بخش نرم‌افزار منتقل نمی‌شوند و بر این اساس، با استفاده از کدهای مخرب قابل سرقت نیستند.
رابط تعامل (API) و مجموعه ای از رمزنگاری های اولیه ارائه شده به نرم افزار کاربردی توسط cryptocore در هر دو مورد یکسان است. تفاوت در نحوه اجرای آنها نهفته است.
بنابراین، هنگام استفاده از یک طرح با یک کریپتوکر تقسیم شده، تعامل بین نرم افزار و سخت افزار بر اساس اصل زیر انجام می شود:
- رمزهای اولیه رمزنگاری که نیازی به استفاده از کلید خصوصی ندارند (مثلاً محاسبه تابع هش، تأیید امضای الکترونیکی و غیره) توسط نرم افزار انجام می شود.
- رمزنگاری های اولیه که از کلید خصوصی استفاده می کنند (ایجاد امضای الکترونیکی، رمزگشایی داده ها و غیره) توسط سخت افزار انجام می شود.
بیایید عملکرد یک کریپتوکور تقسیم شده را با استفاده از مثال ایجاد یک امضای الکترونیکی نشان دهیم:
- بخش نرم افزار عملکرد هش داده های امضا شده را محاسبه می کند و این مقدار را از طریق کانال تبادل بین هسته های رمزنگاری به سخت افزار منتقل می کند.
- بخش سخت افزاری با استفاده از کلید خصوصی و هش، ارزش امضای الکترونیکی را تولید کرده و از طریق کانال تبادل به بخش نرم افزاری منتقل می کند.
- قسمت نرم افزار مقدار دریافتی را به نرم افزار کاربردی برمی گرداند.
ویژگی های بررسی صحت امضای الکترونیکی
هنگامی که طرف دریافت کننده داده های امضا شده با امضای الکترونیکی را دریافت می کند، باید چندین مرحله تأیید را انجام دهد. نتیجه مثبت تأیید یک امضای الکترونیکی تنها در صورتی حاصل می شود که تمام مراحل تأیید با موفقیت انجام شود.
مرحله 1. کنترل یکپارچگی داده ها و تألیف داده ها.
محتوای صحنه. امضای الکترونیکی داده ها طبق الگوریتم رمزنگاری مربوطه تأیید می شود. تکمیل موفقیت آمیز این مرحله نشان می دهد که داده ها از زمان امضای آنها تغییر نکرده اند و امضا با یک کلید خصوصی مربوط به کلید عمومی برای تأیید امضای الکترونیکی انجام شده است.
محل اجرای صحنه: کریپتوکرنل
مرحله 2. کنترل اعتماد به کلید عمومی امضاکننده و کنترل مدت اعتبار کلید خصوصی امضای الکترونیکی.
محتوای صحنه. این مرحله از دو مرحله فرعی میانی تشکیل شده است. اولین مورد مشخص می کند که آیا کلید عمومی برای تأیید امضای الکترونیکی در زمان امضای داده مورد اعتماد بوده است یا خیر. مورد دوم مشخص می کند که آیا کلید خصوصی امضای الکترونیکی در زمان امضای داده ها معتبر بوده است یا خیر. در حالت کلی، دوره های اعتبار این کلیدها ممکن است مطابقت نداشته باشد (به عنوان مثال، برای گواهی های واجد شرایط کلیدهای تأیید امضای الکترونیکی). روش های ایجاد اعتماد به کلید عمومی امضاکننده توسط قوانین مدیریت اسناد الکترونیکی اتخاذ شده توسط طرفین در حال تعامل تعیین می شود.
محل اجرای صحنه: نرم افزار کاربردی / کریپتو کرنل.
مرحله 3. کنترل اختیارات امضاکننده.
محتوای صحنه. مطابق با قوانین تعیین شده مدیریت اسناد الکترونیکی، بررسی می شود که آیا امضاکننده حق تأیید داده های محافظت شده را داشته است یا خیر. مثلاً وضعیت نقض اختیار را در نظر بگیرید. فرض کنید سازمانی وجود دارد که همه کارکنان آن دارای امضای الکترونیکی هستند. سامانه مدیریت اسناد الکترونیکی داخلی از رئیس سفارش دریافت می کند اما با امضای الکترونیکی مدیر انبار امضا می شود. بر این اساس نمی توان چنین سندی را مشروع دانست.
محل اجرای صحنه: نرم افزار کاربردی.
مفروضاتی که هنگام توصیف هدف حفاظتی انجام می شود
- کانال‌های انتقال اطلاعات، به استثنای کانال‌های تبادل کلید، از نرم‌افزارهای کاربردی، API و هسته‌های رمزنگاری نیز عبور می‌کنند.
- اطلاعات مربوط به اعتماد به کلیدهای عمومی و (یا) گواهی ها، و همچنین اطلاعات مربوط به اختیارات صاحبان کلید عمومی، در فروشگاه کلید عمومی قرار می گیرد.
- نرم افزار کاربردی با ذخیره سازی کلید عمومی از طریق کریپتو کرنل کار می کند.
نمونه ای از یک سیستم اطلاعاتی محافظت شده با CIPF
برای نشان دادن طرح های ارائه شده قبلی، یک سیستم اطلاعاتی فرضی را در نظر بگیرید و تمام عناصر ساختاری روی آن را انتخاب کنید.
توضیحات سیستم اطلاعاتی
این دو سازمان تصمیم گرفتند مدیریت اسناد الکترونیکی الزام آور قانونی (EDF) را بین خود معرفی کنند. برای این کار آنها قراردادی منعقد کردند که در آن اعلام کردند که اسناد از طریق ایمیل ارسال می شود و در عین حال باید رمزگذاری شده و با امضای الکترونیکی واجد شرایط امضا شود. به عنوان وسیله ای برای ایجاد و پردازش اسناد، برنامه های آفیس از بسته مایکروسافت آفیس 2016 و به عنوان ابزاری برای محافظت رمزنگاری - CIPF CryptoPRO و نرم افزار رمزگذاری CryptoARM باید استفاده شود.
شرح زیرساخت های سازمان 1
سازمان 1 تصمیم گرفت که نرم افزار CryptoPRO CIPF و CryptoARM را روی ایستگاه کاری کاربر نصب کند - یک رایانه فیزیکی. کلیدهای رمزگذاری و امضای الکترونیکی در حامل کلید ruToken که در حالت کلید قابل بازیابی کار می کند ذخیره می شود. کاربر اسناد الکترونیکی را به صورت محلی در رایانه خود آماده می کند، پس از آن با استفاده از یک سرویس گیرنده پست الکترونیکی نصب شده محلی، رمزگذاری، امضا و ارسال می شود.
شرح زیرساخت های سازمان 2
سازمان 2 تصمیم گرفت تا عملکردهای رمزگذاری و امضای الکترونیکی را به یک ماشین مجازی اختصاصی منتقل کند. در این حالت کلیه عملیات رمزنگاری به صورت خودکار انجام خواهد شد.
برای انجام این کار، دو پوشه شبکه بر روی یک ماشین مجازی اختصاصی سازماندهی شده اند: "…In"، "...Out". فایل های دریافت شده از طرف مقابل به صورت باز به طور خودکار در پوشه شبکه "...In" قرار می گیرند. این فایل‌ها رمزگشایی شده و امضای الکترونیکی روی آنها تایید می‌شود.
در پوشه «…Out»، کاربر فایل‌هایی را قرار می‌دهد که باید رمزگذاری، امضا و برای طرف مقابل ارسال شوند. کاربر خود فایل ها را در ایستگاه کاری خود آماده می کند.
برای انجام عملیات رمزگذاری و امضای الکترونیکی، نرم افزار CryptoPRO CIPF، نرم افزار CryptoARM و یک سرویس گیرنده ایمیل بر روی ماشین مجازی نصب شده است. مدیریت خودکار تمام عناصر ماشین مجازی با استفاده از اسکریپت های توسعه یافته توسط مدیران سیستم انجام خواهد شد. کار اسکریپت ها در فایل های گزارش (log) ثبت می شود.
کلیدهای رمزنگاری امضای الکترونیکی روی یک توکن با یک کلید غیر قابل بازیابی JaCarta GOST قرار می گیرد که کاربر آن را به رایانه محلی خود متصل می کند.
توکن با استفاده از نرم افزار تخصصی USB-over-IP که در ایستگاه کاری کاربر و روی ماشین مجازی نصب شده است، به ماشین مجازی ارسال می شود.
ساعت سیستم در ایستگاه کاری کاربر در سازمان 1 به صورت دستی تنظیم می شود. ساعت سیستم ماشین مجازی اختصاصی در سازمان 2 با ساعت سیستم Hypervisor همگام می شود که به نوبه خود از طریق اینترنت با سرورهای عمومی همگام می شود.
تخصیص عناصر ساختاری CIPF
بر اساس توضیحات فوق در مورد زیرساخت فناوری اطلاعات، عناصر ساختاری CIPF را مشخص کرده و آنها را در جدولی یادداشت می کنیم.
جدول - مطابقت عناصر مدل CIPF با عناصر سیستم های اطلاعاتی
نام مورد
سازمان 1
سازمان 2
نرم افزار کاربردی
نرم افزار CryptoARM
نرم افزار CryptoARM
بخش نرم افزاری کریپتوکرنل
CIPF CryptoPRO CSP
CIPF CryptoPRO CSP
بخش سخت افزاری کریپتوکرنل
بدون
JaCarta GOST
API
MS CryptoAPI
MS CryptoAPI
ذخیره سازی کلید عمومی
ایستگاه کاری کاربر:
- HDD؛
- فروشگاه گواهی استاندارد ویندوز.
هایپروایزر:
- HDD
ماشین مجازی:
- HDD؛
- فروشگاه گواهی استاندارد ویندوز.
ذخیره سازی کلید خصوصی
حامل کلید ruToken در حالت کلید قابل استخراج کار می کند
حامل کلید JaCarta GOST که در حالت کلید غیر قابل بازیابی کار می کند
کانال تبادل کلید عمومی
ایستگاه کاری کاربر:
- رم.
هایپروایزر:
- رم.
ماشین مجازی:
- رم.
کانال تعویض کلید خصوصی
ایستگاه کاری کاربر:
- اتوبوس USB؛
- رم.
بدون
کانال تبادل بین هسته های رمزنگاری شده
وجود ندارد (بدون سخت افزار cryptocore)
ایستگاه کاری کاربر:
- اتوبوس USB؛
- رم؛
- ماژول نرم افزار USB-over-IP.
- رابط شبکه.
شبکه شرکتی سازمان 2.
هایپروایزر:
- رم؛
- رابط شبکه.
ماشین مجازی:
- رابط شبکه؛
- رم؛
- ماژول نرم افزار USB-over-IP.
باز کردن کانال تبادل داده
ایستگاه کاری کاربر:
- وسایل ورودی-خروجی؛
- رم؛
- HDD
ایستگاه کاری کاربر:
- وسایل ورودی-خروجی؛
- رم؛
- HDD؛
- رابط شبکه.
شبکه شرکتی سازمان 2.
هایپروایزر:
- رابط شبکه؛
- رم؛
- HDD
ماشین مجازی:
- رابط شبکه؛
- رم؛
- HDD
کانال تبادل اطلاعات امن
اینترنت می باشد.
شبکه شرکتی سازمان 1.
ایستگاه کاری کاربر:
- HDD؛
- رم؛
- رابط شبکه.
اینترنت می باشد.
شبکه شرکتی سازمان 2.
هایپروایزر:
- رابط شبکه؛
- رم؛
- HDD
ماشین مجازی:
- رابط شبکه؛
- رم؛
- HDD
کانال زمان
ایستگاه کاری کاربر:
- وسایل ورودی-خروجی؛
- رم؛
- تایمر سیستم
اینترنت می باشد.
شبکه شرکتی سازمان 2،
هایپروایزر:
- رابط شبکه؛
- رم؛
- تایمر سیستم
ماشین مجازی:
- رم؛
- تایمر سیستم
کنترل کانال انتقال فرمان
ایستگاه کاری کاربر:
- وسایل ورودی-خروجی؛
- رم.
(GUI نرم افزار CryptoARM)
ماشین مجازی:
- رم؛
- HDD
(اسکریپت های خودکار)
کانال دریافت نتایج کار
ایستگاه کاری کاربر:
- وسایل ورودی-خروجی؛
- رم.
(GUI نرم افزار CryptoARM)
ماشین مجازی:
- رم؛
- HDD
(فایل های گزارش برای اسکریپت های اتوماسیون)
تهدیدات امنیتی سطح بالا
توضیحات
مفروضات مطرح شده در تجزیه تهدیدها:
- از الگوریتم های رمزنگاری قوی استفاده می شود.
- الگوریتم های رمزنگاری به طور ایمن در حالت های عملکرد صحیح استفاده می شوند (به عنوان مثال، برای رمزگذاری مقادیر زیادی داده اعمال نمی شود، بار مجاز روی کلید در نظر گرفته می شود و غیره).
- بدخواهان همه الگوریتم ها، پروتکل ها و کلیدهای عمومی استفاده شده را می شناسند.
- مهاجمان به تمام داده های رمزگذاری شده دسترسی دارند.
- مهاجمان قادر به بازتولید هر عنصر برنامه در سیستم هستند.
تجزیه
U1. به خطر انداختن کلیدهای رمزنگاری خصوصی
U2. رمزگذاری داده های جعلی از طرف یک فرستنده قانونی.
U3. رمزگشایی داده های رمزگذاری شده توسط افرادی که دریافت کنندگان قانونی داده ها نیستند (مزاحمین).
U4. ایجاد امضای الکترونیکی امضاکننده قانونی تحت داده های نادرست.
U5. اخذ نتیجه مثبت از بررسی امضای الکترونیکی داده های نادرست.
U6. پذیرش اشتباه اسناد الکترونیکی برای اجرا به دلیل اشکال در سازمان مدیریت اسناد الکترونیکی.
U7. دسترسی غیرمجاز به داده های محافظت شده در طول پردازش آنها توسط CIPF.
U1. به خطر انداختن کلیدهای رمزنگاری خصوصی
U1.1. کلید خصوصی را از فروشگاه کلید خصوصی دریافت کنید.
Y1.2. دریافت یک کلید خصوصی از اشیاء محیط عملکرد ابزار رمزنگاری که می تواند به طور موقت در آن قرار گیرد.
توضیحات Y1.2.
اشیایی که می توانند به طور موقت یک کلید خصوصی را ذخیره کنند عبارتند از:
- رم،
- فایل های موقت،
- فایل های صفحه بندی،
- فایل های خواب زمستانی،
- فایل‌های فوری از وضعیت «گرم» ماشین‌های مجازی، از جمله فایل‌های محتوای RAM ماشین‌های مجازی که موقتاً متوقف شده‌اند.
U1.2.1. بازیابی کلیدهای خصوصی از رم در حال کار با فریز کردن ماژول های رم، استخراج آنها و سپس خواندن داده ها (حمله فریز).
توضیحات Y1.2.1.
مثال .
Y1.3. دریافت کلید خصوصی از کانال تبادل کلید خصوصی.
توضیحات Y1.3.
نمونه ای از اجرای این تهدید آورده خواهد شد .
Y1.4. تغییر غیرمجاز هسته رمزنگاری که در نتیجه کلیدهای خصوصی برای مهاجمان شناخته می شود.
Y1.5. به خطر افتادن کلید خصوصی در نتیجه استفاده از کانال های فنی نشت اطلاعات (TCLE).
توضیحات Y1.5.
مثال .
U1.6. به خطر افتادن کلید خصوصی در نتیجه استفاده از ابزار فنی ویژه (STS) که برای بازیابی مخفی اطلاعات ("اشکالات") طراحی شده است.
Y1.7. به خطر افتادن کلیدهای خصوصی در حین ذخیره سازی آنها در خارج از CIPF.
توضیحات Y1.7.
به عنوان مثال، یک کاربر رسانه های کلیدی خود را در یک کشوی دسکتاپ نگه می دارد، که می تواند به راحتی توسط متجاوزان بازیابی شود.
U2. رمزگذاری داده های جعلی از طرف یک فرستنده قانونی
توضیحات
این تهدید فقط برای طرح های رمزگذاری داده با احراز هویت فرستنده در نظر گرفته می شود. نمونه هایی از چنین طرح هایی در توصیه های استاندارد سازی ذکر شده است. . برای دیگر طرح‌های رمزنگاری، این تهدید وجود ندارد، زیرا رمزگذاری روی کلیدهای عمومی گیرنده انجام می‌شود و معمولاً مهاجمان آنها را می‌شناسند.
تجزیه
U2.1. به خطر انداختن کلید خصوصی فرستنده:
Y2.1.1. ارتباط دادن: .
Y2.2. جایگزینی داده های ورودی در کانال تبادل داده باز.
یادداشت U2.2.
نمونه هایی از اجرای این تهدید در زیر آورده شده است. и .
U3. رمزگشایی داده های رمزگذاری شده توسط افرادی که دریافت کنندگان قانونی داده ها نیستند (مزاحمین)
تجزیه
Y3.1. به خطر انداختن کلیدهای خصوصی گیرنده داده های رمزگذاری شده.
لینک U3.1.1: .
Y3.2. جایگزینی داده های رمزگذاری شده در یک کانال تبادل اطلاعات امن.
U4. ایجاد امضای الکترونیکی امضاکننده قانونی تحت داده های نادرست
تجزیه
Y4.1. به خطر انداختن کلیدهای خصوصی امضای الکترونیکی یک امضاکننده قانونی.
لینک U4.1.1: .
Y4.2. جایگزینی داده های امضا شده در کانال تبادل داده باز.
توجه U4.2.
نمونه هایی از اجرای این تهدید در زیر آورده شده است. и .
U5. اخذ نتیجه مثبت از بررسی امضای الکترونیکی داده های نادرست
تجزیه
Y5.1. بدخواهان پیام نتیجه منفی بررسی امضای الکترونیکی را در کانال انتقال نتایج کار رهگیری می کنند و آن را با پیام با نتیجه مثبت جایگزین می کنند.
Y5.2. مهاجمان به اعتماد در امضای گواهی ها حمله می کنند (سناریو - همه عناصر مورد نیاز است):
Y5.2.1. مهاجمان یک کلید عمومی و خصوصی برای امضای الکترونیکی تولید می کنند. اگر سیستم از گواهینامه‌های کلید امضای الکترونیکی استفاده کند، گواهی امضای الکترونیکی را تولید می‌کند که تا حد امکان مشابه گواهی فرستنده ادعایی داده‌هایی است که پیامش را می‌خواهند جعل کنند.
U5.2.2. مهاجمان تغییرات غیرمجاز در فروشگاه کلید عمومی ایجاد می‌کنند و به کلید عمومی تولید شده توسط آنها سطح اعتماد و اختیار لازم را می‌دهند.
Y5.2.3. مهاجمان داده های جعلی را با یک کلید امضای الکترونیکی که قبلاً تولید شده بود امضا می کنند و آن را در یک کانال تبادل اطلاعات امن جاسازی می کنند.
Y5.3. مهاجمان با استفاده از کلیدهای امضای الکترونیکی منقضی شده یک امضاکننده قانونی حمله را انجام می دهند (سناریو - همه عناصر مورد نیاز است):
Y5.3.1. مهاجمان کلیدهای خصوصی منقضی شده (در حال حاضر معتبر نیستند) امضای الکترونیکی فرستنده قانونی را به خطر می اندازند.
Y5.3.2. مهاجمان زمان را در کانال انتقال زمان با زمانی که کلیدهای در معرض خطر هنوز معتبر بودند جایگزین می کنند.
Y5.3.3. مهاجمان داده های جعلی را با یک کلید امضای الکترونیکی که قبلاً به خطر افتاده امضا می کنند و آن را در یک کانال تبادل اطلاعات امن جاسازی می کنند.
Y5.4. مهاجمان حمله ای را با استفاده از کلیدهای امضای الکترونیکی در معرض خطر یک امضاکننده قانونی انجام می دهند (سناریو - همه عناصر مورد نیاز است):
Y5.4.1. مهاجمان یک کپی از فروشگاه کلید عمومی می سازند.
Y5.4.2. مهاجمان کلیدهای خصوصی یکی از فرستنده های قانونی را به خطر می اندازند. او متوجه سازش می شود، کلیدها را باطل می کند، اطلاعات مربوط به ابطال کلید در فروشگاه کلید عمومی قرار می گیرد.
Y5.4.3. مهاجمان فروشگاه کلید عمومی را با مواردی که قبلاً کپی شده بود جایگزین می کنند.
Y5.4.4. مهاجمان داده های جعلی را با یک کلید امضای الکترونیکی که قبلاً به خطر افتاده امضا می کنند و آن را در یک کانال تبادل اطلاعات امن جاسازی می کنند.
U5.5. <...> به دلیل وجود خطا در اجرای مراحل 2 و 3 تأیید امضای الکترونیکی:
توضیحات Y5.5.
نمونه ای از اجرای این تهدید آورده شده است .
U5.5.1. تأیید اعتماد به گواهینامه کلید امضای الکترونیکی تنها با وجود اعتماد در گواهینامه ای که با آن امضا شده است، بدون بررسی CRL یا OCSP.
توضیحات Y5.5.1.
مثال پیاده سازی .
U5.5.2. هنگام ایجاد یک زنجیره اعتماد برای یک گواهی، اختیار صدور گواهی تجزیه و تحلیل نمی شود
توضیحات Y5.5.2.
نمونه ای از حمله به گواهینامه های SSL/TLS.
مهاجمان یک گواهی نامه قانونی برای ایمیل خود خریداری کردند. آنها سپس یک گواهی وب سایت تقلبی ساختند و آن را با گواهی خود امضا کردند. اگر بررسی اعتبار انجام نشود، هنگام بررسی زنجیره اعتماد، درست است و بر این اساس، گواهی تقلب نیز صحیح خواهد بود.
Y5.5.3. هنگام ساخت یک زنجیره اعتماد گواهی، گواهینامه های میانی برای ابطال بررسی نمی شوند.
Y5.5.4. CRL ها کمتر از صدور مجوز توسط مرجع به روز می شوند.
U5.5.5. تصمیم به اعتماد به امضای الکترونیکی قبل از دریافت پاسخ OCSP در مورد وضعیت گواهی گرفته می‌شود، پس از درخواستی که دیرتر از زمان تولید امضا یا زودتر از درخواست بعدی پس از دریافت امضای CRL ارسال می‌شود.
توضیحات Y5.5.5.
در مقررات اکثر CA، زمان ابطال گواهی به عنوان زمان صدور نزدیکترین CRL حاوی اطلاعات مربوط به ابطال گواهی در نظر گرفته می شود.
U5.5.6. پس از دریافت اطلاعات امضا شده، مالکیت گواهی توسط فرستنده تأیید نمی شود.
توضیحات Y5.5.6.
نمونه حمله برای گواهی‌های SSL، ممکن است بررسی نکند که آیا آدرس سرور فراخوانی شده با مقدار فیلد CN در گواهی مطابقت دارد یا خیر.
نمونه حمله مهاجمان کلیدهای امضای الکترونیکی یکی از شرکت کنندگان در سیستم پرداخت را به خطر انداختند. پس از آن، شبکه یکی دیگر از شرکت‌کنندگان را هک کردند و از طرف او، اسناد پرداخت امضا شده با کلیدهای مخدوش را به سرور تسویه حساب سیستم پرداخت ارسال کردند. اگر سرور فقط اعتماد را تجزیه و تحلیل کند و انطباق را بررسی نکند، اسناد تقلبی مشروع تلقی خواهند شد.
U6. پذیرش اشتباه اسناد الکترونیکی برای اجرا به دلیل اشکال در سازمان مدیریت اسناد الکترونیکی.
تجزیه
U6.1. طرف دریافت کننده کپی مدارک دریافتی را تشخیص نمی دهد.
توضیحات Y6.1.
نمونه حمله بدخواهان می توانند سندی را که به گیرنده منتقل می شود، حتی اگر از نظر رمزنگاری محافظت شده باشد، رهگیری کرده و سپس آن را به طور مکرر به کانال انتقال داده امن ارسال کنند. اگر گیرنده موارد تکراری را تشخیص ندهد، تمام اسناد دریافتی به عنوان اسناد مختلف درک و پردازش می شوند.
U7. دسترسی غیرمجاز به داده های محافظت شده در طول پردازش آنها توسط CIPF
تجزیه
Y7.1. <…> به دلیل نشت اطلاعات از طریق کانال های شخص ثالث (حمله کانال جانبی).
توضیحات Y7.1.
مثال .
U7.2. <...> به دلیل خنثی سازی حفاظت در برابر دسترسی غیرمجاز به اطلاعات پردازش شده در CIPF:
Y7.2.1. عملیات CIPF با نقض الزامات شرح داده شده در اسناد CIPF.
Y7.2.2. <…> به دلیل وجود آسیب‌پذیری‌ها در:
Y7.2.2.1. <…> وسیله ای برای محافظت در برابر دسترسی غیرمجاز.
Y7.2.2.2. <…> خود CIPF.
Y7.2.2.3. <...> محیطی برای عملکرد ابزار رمزنگاری.
نمونه های حمله
سناریوهای مورد بحث در زیر آشکارا حاوی خطاهایی در سازماندهی امنیت اطلاعات هستند و فقط برای نشان دادن حملات احتمالی عمل می کنند.
سناریو 1. نمونه ای از اجرای تهدیدات U2.2 و U4.2.
شرح شی
نرم افزار ARM KBR و CIPF SCAD Signature روی یک کامپیوتر فیزیکی که به شبکه کامپیوتری متصل نیست نصب می شود. FKN vdToken به عنوان یک حامل کلید در حالت عملکرد با یک کلید غیر قابل بازیابی استفاده می شود.
مقررات تسویه حساب فرض می کند که متخصص تسویه حساب از رایانه کاری خود پیام های الکترونیکی را به صورت متن واضح (طرح KBR AWS قدیمی) از یک سرور فایل امن خاص دانلود می کند، سپس آنها را روی یک درایو فلش USB قابل جابجایی می نویسد و به KBR AWP منتقل می کند. ، جایی که رمزگذاری می شوند و علامت می دهند. پس از آن، متخصص پیام های الکترونیکی امن را به یک رسانه قابل انتقال منتقل می کند و سپس از طریق رایانه کاری خود، آنها را به یک سرور فایل می نویسد، از آنجا به UTA و سپس به سیستم پرداخت بانک روسیه می رسد.
در این حالت، کانال های تبادل داده های باز و ایمن شامل: سرور فایل، رایانه کاری متخصص و رسانه قابل انتقال خواهد بود.
حمله
مهاجمان غیرمجاز یک سیستم کنترل از راه دور را روی رایانه کار متخصص نصب می‌کنند و در زمان ثبت سفارش‌های پرداخت (پیام‌های الکترونیکی) بر روی رسانه قابل انتقال، آشکارا محتویات یکی از آنها را جایگزین می‌کنند. متخصص دستورات پرداخت را به AWS KBR منتقل می کند، بدون توجه به تعویض (مثلاً به دلیل تعداد زیاد دستورات پرداخت در پرواز، خستگی و غیره) آنها را امضا و رمزگذاری می کند. پس از آن، دستور پرداخت جعلی، با عبور از زنجیره فناوری، وارد سیستم پرداخت بانک روسیه می شود.
سناریو 2. نمونه ای از اجرای تهدیدات U2.2 و U4.2.
شرح شی
رایانه با AWS KBR، امضای SKAD و حامل کلید متصل FKN vdToken در یک اتاق اختصاصی بدون دسترسی کارکنان کار می کند.
متخصص تسویه حساب به AWS KBR در حالت دسترسی از راه دور از طریق پروتکل RDP متصل می شود.
حمله
مهاجمان جزئیات را رهگیری می کنند که با استفاده از آن متخصص تسویه حساب با محل کار خودکار KBR متصل می شود و با آن کار می کند (مثلاً به دلیل کد مخرب در رایانه خود). سپس از طرف او وصل می شوند و دستور پرداخت جعلی را به سیستم پرداخت بانک روسیه ارسال می کنند.
سناریو 3. نمونه ای از اجرای تهدید U1.3.
شرح شی
اجازه دهید یکی از گزینه های فرضی را برای اجرای ماژول های یکپارچه سازی ABS-KBR برای طرح جدید (ARM KBR-N) در نظر بگیریم، که در آن امضای الکترونیکی اسناد خروجی در سمت ABS رخ می دهد. در عین حال، ما فرض می کنیم که ABS بر اساس سیستم عاملی کار می کند که توسط امضای CIPF SKAD پشتیبانی نمی شود، و بر این اساس، عملکرد رمزنگاری بر روی یک ماشین مجازی جداگانه - ماژول یکپارچه سازی ABS-CBR قرار می گیرد. .
یک توکن USB معمولی که در حالت کلید قابل جابجایی کار می کند به عنوان حامل کلید استفاده می شود. هنگامی که حامل کلید به هایپروایزر متصل شد، مشخص شد که هیچ پورت USB رایگان در سیستم وجود ندارد، بنابراین تصمیم گرفته شد که رمز USB را از طریق یک هاب USB شبکه متصل کرده و یک کلاینت USB-over-IP را روی دستگاه نصب کنید. ماشین مجازی که با هاب ارتباط برقرار می کند.
حمله
مهاجمان کلید خصوصی امضای الکترونیکی را از کانال ارتباطی بین هاب USB و هایپروایزر رهگیری کردند (داده ها به صورت متن واضح منتقل شدند). مهاجمان با داشتن یک کلید خصوصی، یک دستور پرداخت جعلی ایجاد کردند، آن را با امضای الکترونیکی امضا کردند و برای اجرا به محل کار خودکار KBR-N فرستادند.
سناریو 4. نمونه ای از اجرای تهدیدات U5.5.
شرح شی
همان مدار سناریوی قبلی را در نظر بگیرید. فرض می‌کنیم که ایمیل‌هایی که از ایستگاه کاری KBR-N می‌آیند به پوشه …SHAREIn ختم می‌شوند و آنهایی که به ایستگاه کاری KBR-N و سپس به سیستم پرداخت بانک روسیه ارسال می‌شوند به …SHAREout می‌روند.
همچنین فرض می‌کنیم که هنگام پیاده‌سازی ماژول یکپارچه‌سازی، فهرست گواهی‌های باطل شده تنها زمانی به‌روزرسانی می‌شوند که کلیدهای رمزنگاری مجدداً منتشر شوند، و همچنین پیام‌های الکترونیکی دریافت‌شده در پوشه …SHAREIn فقط برای کنترل یکپارچگی و کنترل اعتماد به کلید عمومی بررسی می‌شوند. امضای الکترونیکی
حمله
مهاجمان با استفاده از کلیدهای به سرقت رفته در سناریوی قبلی، دستور پرداخت جعلی حاوی اطلاعات دریافت پول در حساب یک مشتری کلاهبردار را امضا کردند و آن را به یک کانال تبادل اطلاعات امن معرفی کردند. از آنجایی که تأییدیه ای مبنی بر امضای دستور پرداخت توسط بانک روسیه وجود ندارد، برای اجرا پذیرفته می شود.
منبع: www.habr.com