مخاطر جانب ثالث از ابتدا تا انتها: واژهنامهای عملی
تفکیک واضح مدیریت ریسک جانب ثالث از ابتدا تا انتها، شامل بارگذاری، نظارت مستمر، پاسخ به حادثه، و خروج از سیستم.
ریسک جانب ثالث در امضای قرارداد یا تکمیل پرسشنامه پایان نمییابد. "از ابتدا تا انتها" به معنای برخورد با ریسک فروشنده به عنوان یک چرخهی زندگی است: از لحظهای که تامینکنندهای را در نظر میگیرید، تا طول کل رابطه، تا روزی که ارتباط را قطع کنید و دسترسیشان را لغو کنید. اکثر تخلفات مرتبط با فروشندگان به این دلیل رخ میدهند که سازمانها ریسک را در یک مرحله (معمولاً بارگذاری) مدیریت میکنند و بقیه را فراموش میکنند.
آنچه که پوششدهی از ابتدا تا انتها واقعاً شامل میشود
یک برنامه کامل ریسک جانب ثالث چهار مرحله متمایز را شامل میشود که هر کدام کنترلهای خود را دارند:
- تحقیق و انتخاب - پیش از اینکه چیزی امضا کنید، وضعیت امنیتی فروشنده را ارزیابی کنید. این شامل بررسی گزارشهای SOC 2، گواهیهای ISO 27001، خلاصههای آزمون نفوذ، و فهرست تامینکنندگان فرعی آنها است (ریسک جانب چهارم در اینجا مخفی است).
- بارگذاری و قرارداد - تعریف شرایط مدیریت دادهها، جدولزمانی اطلاعرسانی تخلف، بند حق بازرسی، و محدوده دسترسی در خود قرارداد، نه فقط در یک پرسشنامه جانبی.
- نظارت مستمر - بررسیهای مستمر یا دورهای: اسکن سطح حمله، سرویسهای رتبهبندی امنیتی (BitSight، SecurityScorecard)، بررسی سرعت رفع آسیبپذیری، و ارزیابی مجدد زمانی که فروشنده تامینکنندگان فرعی را تغییر دهد یا با حادثه مواجه شود.
- خروج و خاتمه - لغو کلیدهای API، دسترسی VPN، اعتبارات مشترک، و تأیید حذف یا بازگشت دادهها براساس قرارداد.
اکثر برنامهها در مرحله 1 و 2 قوی هستند و در مرحله 3 و 4 ضعیف. یک فروشندهای که در 2022 با ریسک پایین ارزیابی شده بود، ممکن است در 2024 با نرمافزار بدون رفعشده کار کند، و کسی آن را بررسی نکرده است زیرا پرسشنامه یک درز یکبار مصرف بود.
چرا مرحله نظارت مستمر جایی است که برنامهها شکست میخورند
پرسشنامههای بارگذاری یک عکسفوری هستند. آنها به شما میگویند امنیت فروشنده در روزی که فرم را پر کردند چه شکلی داشت. سطح حمله هر هفته تغییر میکند. سطل S3 آشکار شدهی فروشنده، گواهی TLS منقضی شده، CVE جدید افشا شدهی نرمافزاری که اجرا میکند — هیچ کدام در یک پرسشنامه SIG یا CAIQ نقطهای نشان نمیدهند.
برنامههای از ابتدا تا انتها این مسئله را با حل میکنند:
- طبقهبندی - هر فروشندهای نیاز به بررسی مشابه ندارد. یک پروسسور حقوق و دستمزد با دسترسی به اطلاعات شناسایی شخصی نسبت به فروشنده تأمین لوازم دفتری بررسی عمیقتر و مکررتری دریافت میکند. طبقهبندی براساس حساسیت داده و دسترسی سیستم، نه ارزش دلار قرارداد.
- نظارت خودکار بر سطح حمله - ابزارهایی که به طور مستمر زیرساخت روبهروی عمومی فروشنده را برای پورتهای باز، گواهیهای منقضی شده، اعتبارات درز شده در سایتهای paste، و ذخیرهسازی ابری آشکار اسکن میکنند.
- ارزیابی مجدد براساس رویداد - یک فروشنده را بلافاصله پس از یک تخلف عمومیشده، ادغام/خریداری، یا تغییر محصول قابلتوجه مجدداً بررسی کنید، نه انتظار برای چرخه تجدید سالانه.
مسئله دسترسی که کسی خوب ردیابی نمیکند
اینجا شکافی است که دائماً در پسسوزهای حادثه ظاهر میشود: فروشندگان دسترسی را طی زمان جمع میکنند و کسی آن را هرس نمیکند. یک پیمانکاری که برای یک پروژه سه ماهه به دسترسی VPN نیاز داشت، هنوز هم هجده ماه بعد اعتبارات معتبری دارد. کلید API یک شریک통합 هرگز پس از آزمایش اولیه محدود نشد.
مدیریت ریسک از ابتدا تا انتها نیاز به موجودی دسترسی مرتبط با وضعیت چرخهی زندگی فروشنده، نه فقط یک فهرست دارایی IT دارد. هنگامی که رابطه فروشنده پایان مییابد، کسی نیاز به یک چکلیست دارد: ورودیهای SSO/SAML را لغو کنید، کلیدهای API مشترک را تغییر دهید، از فهرستهای مجاز فایروال و VPCها حذف کنید، گواهیهای تخریب داده را تأیید کنید. پرش از این مرحله این است که فروشندگان سابق به عنوان بردار دسترسی اولیه در حادثه سالها پس از پایان قرارداد ظاهر میشوند.
چارچوب عملی برای اعمال این هفته
اگر یک برنامه ریسک جانب ثالث را ساخته یا بازرسی میکنید، ابتدا این شکافها را بررسی کنید:
- آیا یک مدل طبقهبندی مستند وجود دارد، یا هر فروشندهای صرفنظر از سطح دسترسی یک پرسشنامه مشابه دریافت میکند؟
- آیا نظارت مستمر دارید، یا فقط بررسی در زمان تجدید؟
- آیا یک چکلیست خروج رسمی وجود دارد که شامل لغو اعتبارات و تأیید داده است؟
- آیا برنامه پاسخ حادثه شما به صراحت حادثههای ناشی از جانب ثالث را پوشش میدهد، از جمله اینکه چه کسی کسی را آگاه میکند و در چه جدولزمانی؟
- آیا جانب چهارم (فروشندگان فروشندگان شما) را ردیابی میکنید، یا دید به قرارداد مستقیم متوقف میشود؟
چارچوبهای مانند NIST SP 800-161 و ISO 27036 ساختار را به این میدهند، اما انضباط واقعی از برخورد با ریسک فروشنده به عنوان یک فرآیند مستمر متعلق به یک تیم خاص، نه یک کادر انطباقپذیری پر شدهی سالانه به دست میآید.
برای اطلاعات بیشتر در مورد ساخت آن، بخشهای Korra Studio را در مورد چارچوبهای ریسک فروشنده، مدیریت چرخهی زندگی کنترل دسترسی، و برنامهریزی پاسخ حادثه در Blue Team بررسی کنید.
با کمک هوش مصنوعی نوشتهشده، بازبینی و منتشرشده توسط Michal Pilch (CISSP)، Korra Studio.
این یکی از یادداشتهای پایگاه دانش Korra Studio است — پلتفرم هر موضوع را با مربی یکبهیک جفت میکند.
شروع رایگانarrow_forward