مقدمه
در NIST Risk Management Framework، مدیریت ریسک در سه لایه بههمپیوسته انجام میشود که هر کدام نقش مشخصی دارند.
Tier 1 (سطح سازمانی) جایی است که هیئتمدیره و مدیریت ارشد درباره ریسک تصمیمگیری میکنند. در این سطح، مأموریت، اهداف کلان، الزامات قانونی و سطح تحمل ریسک سازمان تعیین میشود. خروجی Tier 1 پاسخ به این سؤال است که سازمان «چه میزان ریسک و در چه حوزههایی» را میپذیرد. این تصمیمها مالکیت ریسک را مشخص میکنند و مبنای همه لایههای بعدی هستند.
Tier 2 (سطح مأموریت و فرآیندهای کسبوکار) وظیفه دارد تصمیمهای Tier 1 را به طراحی مأموریتها، فرآیندها و جریانهای اطلاعاتی ترجمه کند. در این لایه مشخص میشود ریسک دقیقاً در کدام مأموریتها متمرکز است و معماری سازمانی چگونه باید از آنها پشتیبانی کند.
Tier 3 (سطح سیستمها) جایی است که سیستمهای اطلاعاتی طراحی، پیادهسازی و ارزیابی میشوند. کنترلهای امنیتی انتخاب و اجرا میشوند تا الزامات تعریفشده در Tier 2 و ریسکپذیری Tier 1 را محقق کنند.
بحث در Tier 2
در چارچوب NIST Risk Management Framework (RMF)، تایر دوم Tier 2 نقطهای است که ریسک از سطح «تصمیمهای کلان حاکمیتی» خارج میشود و وارد دنیای واقعی عملیات سازمان میگردد؛ جایی که مأموریتها اجرا میشوند، فرآیندها شکل میگیرند و اطلاعات جریان پیدا میکند. اگر Tier 1 درباره «چه میزان ریسک قابل پذیرش است» تصمیم میگیرد، Tier 2 پاسخ میدهد که این ریسکپذیری چگونه باید در طراحی و اجرای مأموریتها و فرآیندهای کسبوکار منعکس شود.
Tier 2 نه یک لایه فنی است و نه صرفاً مدیریتی؛ بلکه لایهای معماریمحور است که تصمیمهای حاکمیتی را به ساختارهای عملیاتی قابل اجرا تبدیل میکند. شکست بسیاری از برنامههای امنیت و مدیریت ریسک دقیقاً در همین نقطه رخ میدهد؛ جایی که استراتژی وجود دارد، اما در فرآیندها «ترجمه» نشده است.
نکته کلیدی در Tier 2 این است که سازمان الزاماً یک موجودیت یکنواخت نیست. بسیاری از سازمانها چندین حوزه مأموریتی (Mission Areas) یا دامنه کسبوکاری دارند که هرکدام منطق، ریسک، حساسیت و معماری خاص خود را میطلبند. به همین دلیل NIST تصریح میکند که ممکن است یک سازمان چند Tier 2 موازی داشته باشد. این نگاه، مستقیماً به معماری سازمانی (Enterprise Architecture) گره میخورد؛ زیرا هر مأموریت، بهطور طبیعی به یک Segment Architecture یا Solution Architecture متفاوت نیاز دارد.
اولین فعالیت کلیدی در Tier 2، تعریف مأموریتهای اصلی و فرآیندهای کسبوکار است. این تعریف نباید صرفاً بر اساس ساختار سازمانی یا چارت باشد، بلکه باید بر اساس «آنچه واقعاً ارزش تولید میکند» انجام شود. بسیاری از فرآیندهای امنیتی زمانی ناکارآمد میشوند که از فرآیندهای رسمی مستند شده، نه فرآیندهای واقعی عملیاتی، محافظت میکنند. Tier 2 میخواهد بداند مأموریت چیست، چگونه اجرا میشود و کدام فرآیندها برای تحقق آن حیاتیاند.
پس از شناسایی مأموریتها، نوبت به اولویتبندی فرآیندها میرسد. همه فرآیندها ارزش یکسان ندارند و نباید بهطور یکسان محافظت شوند. اولویتبندی باید مستقیماً از اهداف Tier 1 تغذیه شود. اگر در Tier 1 سازمان اعلام کرده که تحمل ریسک برای توقف خدمت حیاتی بسیار پایین است، Tier 2 موظف است فرآیندهای مرتبط با تداوم خدمت را در بالاترین سطح اولویت قرار دهد. اینجاست که مدیریت ریسک از یک تمرین نظری به ابزاری برای تصمیمسازی تبدیل میشود.
یکی از مهمترین و در عین حال نادیدهگرفتهشدهترین وظایف Tier 2، تعیین اطلاعات موردنیاز برای اجرای مأموریتها و جریانهای اطلاعاتی است. امنیت اطلاعات بدون درک جریان اطلاعات معنا ندارد. Tier 2 مشخص میکند چه اطلاعاتی برای اجرای مأموریت ضروری است، این اطلاعات از کجا میآیند، به کجا میروند و چه تعاملات داخلی و خارجیای دارند. این دید، پایه تحلیلهای بعدی در Tier 3 است، اما خود یک تصمیم معماری و ریسکمحور در Tier 2 محسوب میشود.
در همین لایه است که استراتژی حفاظت اطلاعات سازمانگسترده شکل میگیرد. این استراتژی نه به معنای انتخاب کنترلهای فنی، بلکه به معنای تعیین اصول و الزامات سطح بالایی است که باید در فرآیندها تزریق شوند. برای مثال، تصمیم درباره اینکه «چه نوع اطلاعاتی میتوانند از مرز سازمان خارج شوند»، یا «کدام مأموریتها نیازمند جداسازی شدیدتر هستند»، تصمیمهای Tier 2 هستند، نه Tier 3. در Tier 2 مشخص میشود امنیت چگونه باید در طراحی فرآیندها دیده شود، نه اینکه دقیقاً چه ابزار یا کنترلی استفاده شود.
یکی از پیچیدهترین و حساسترین مباحث Tier 2، تعیین میزان اختیار (Autonomy) برای واحدهای زیرمجموعه در ارزیابی، پاسخ، پذیرش و پایش ریسک است. NIST بهوضوح میپذیرد که یک رویکرد کاملاً متمرکز همیشه کارآمد نیست. در سازمانهای بزرگ یا فدرالی، واحدهای زیرمجموعه اغلب دانش عملیاتی بهتری از ریسکهای خود دارند و سالهاست روشهای خاص خود را توسعه دادهاند. در چنین شرایطی، سازمان مادر ممکن است برای افزایش کارایی و کاهش هزینهها، اختیار بیشتری به آنها بدهد.
اما این اختیار یک شمشیر دو لبه است. اگر هر زیرمجموعه روش، معیار و زبان ریسک خاص خود را داشته باشد، سازمان در سطح کلان قادر به تجمیع، مقایسه و تصمیمگیری سازمانی نخواهد بود. به همین دلیل Tier 2 باید یک نقش ترجمهگر ایفا کند. حتی اگر واحدها آزاد باشند که روشهای خود را حفظ کنند، سازمان مادر باید چارچوبی تعریف کند که خروجیها به شکلی همسانسازی شوند که قابل مقایسه و قابل تجمیع باشند. این دقیقاً نقطهای است که معماری سازمانی و مدیریت ریسک به هم میرسند.
از نگاه یک متخصص ریسک، Tier 2 جایی است که بسیاری از سوءتفاهمها درباره «مالکیت ریسک» شکل میگیرد. Tier 2 تصمیم نمیگیرد که کدام کنترل دقیقاً پیادهسازی شود، اما تعیین میکند که چه کسی حق دارد ریسک را بپذیرد و در چه چارچوبی. اگر این مرزها شفاف نباشد، نتیجه یا تمرکز بیش از حد تصمیمگیری در مرکز است، یا رهاشدگی خطرناک در لایههای پایینتر.
در نهایت، Tier 2 ستون فقرات پیوند بین حاکمیت و اجراست. بدون Tier 2، لایه Tier 1 به مجموعهای از بیانیههای زیبا تبدیل میشود و Tier 3 به مجموعهای از کنترلهای فنی بدون جهت. Tier 2 تضمین میکند که ریسکپذیری سازمان، نه فقط در اسناد، بلکه در معماری مأموریتها، طراحی فرآیندها و جریان واقعی اطلاعات نهادینه شود.
اگر Tier 1 میگوید «چقدر ریسک میپذیریم»، Tier 2 پاسخ میدهد:
«این پذیرش ریسک، دقیقاً در کجای کسبوکار و چگونه زندگی میکند.»
و این، دقیقاً همان جایی است که مدیریت ریسک از شعار به قابلیت سازمانی تبدیل میشود.
مثال برای درک بهتر
فرض کنید یک سازمان ملی ارائهدهنده خدمات سلامت دیجیتال داریم که مأموریت آن «ارائه پایدار و امن خدمات درمانی آنلاین به شهروندان» است. این سازمان چند مأموریت کلیدی دارد: نسخهنویسی الکترونیکی، پرونده سلامت الکترونیک، ارتباط آنلاین پزشک و بیمار، و گزارشدهی به نهادهای حاکمیتی. در Tier 1، هیئتمدیره و مدیریت ارشد به این جمعبندی رسیدهاند که افشای دادههای سلامت شهروندان و توقف خدمات درمانی حتی برای چند ساعت، ریسک غیرقابل پذیرش است، اما در عوض برای توسعه قابلیتهای دیجیتال جدید و آزمایش سرویسهای نوآورانه، تحمل ریسک بیشتری وجود دارد. این تصمیمها در Tier 1 ثبت شدهاند، اما هنوز هیچچیز در دنیای واقعی عملیات تغییر نکرده است.
در این نقطه Tier 2 وارد عمل میشود. تیم معماری سازمانی و مدیریت ریسک مأمور میشود این ریسکپذیری را به طراحی مأموریتها و فرآیندهای واقعی ترجمه کند. اولین کاری که انجام میدهند، شکستن مأموریتهای کلان به فرآیندهای عملیاتی است. مثلاً مأموریت «نسخهنویسی الکترونیکی» به فرآیندهایی مانند احراز هویت پزشک، دسترسی به پرونده بیمار، ثبت نسخه، ارسال نسخه به داروخانه و ذخیرهسازی سوابق تقسیم میشود. هدف از این کار مستندسازی نیست؛ هدف این است که مشخص شود ریسک سازمان دقیقاً در کدام نقاط زندگی میکند.
پس از آن، Tier 2 به سراغ اولویتبندی میرود. چون در Tier 1 توقف خدمت درمانی غیرقابل پذیرش اعلام شده، فرآیندهایی که مستقیماً به ارائه خدمت به بیمار متصل هستند، در بالاترین سطح حساسیت قرار میگیرند. در مقابل، فرآیندهای تحلیلی که برای گزارشهای مدیریتی یا بهبودهای بلندمدت استفاده میشوند، اگرچه مهماند، اما تحمل ریسک بیشتری دارند. این تصمیم باعث میشود از همین لایه معماری مشخص شود کدام فرآیندها باید جداسازی شوند، کدامها نیاز به افزونگی دارند و کدامها میتوانند روی زیرساختهای مشترک اجرا شوند.
در ادامه، Tier 2 تمرکز خود را روی اطلاعات و جریانهای اطلاعاتی میگذارد. تیم متوجه میشود که دادههای سلامت بیماران بین اپلیکیشن موبایل، سامانه مرکزی، پزشکان، داروخانهها و نهادهای دولتی جابهجا میشود. تصمیم Tier 2 این نیست که از چه الگوریتم رمزنگاری استفاده شود، بلکه این است که چه نوع دادهای مجاز است از مرز سازمان خارج شود، کدام جریانها باید قابل ردیابی کامل باشند و کدام تعاملات باید به حداقل ممکن کاهش پیدا کنند. این تصمیمها بهطور مستقیم از ریسکپذیری Tier 1 تغذیه میشوند، اما در قالب معماری فرآیند و جریان داده بیان میشوند.
در همین مرحله، استراتژی حفاظت اطلاعات سازمانگسترده شکل میگیرد. برای مأموریتهای درمانی حیاتی تصمیم گرفته میشود که این مأموریتها باید از نظر معماری از سایر سرویسهای دیجیتال ایزوله باشند و در صورت بروز حادثه، بتوانند در حالت حداقلی اما پایدار به کار خود ادامه دهند. این تصمیمها هنوز فنی نیستند، اما Tier 3 را بهشدت جهتدهی میکنند. تیمهای فنی دیگر نمیتوانند معماریای طراحی کنند که این اصول را نقض کند.
از آنجا که سازمان چند مأموریت کاملاً متفاوت دارد، عملاً چند Tier 2 شکل میگیرد. مأموریت پرونده سلامت یک معماری سگمنت خاص خود را میخواهد، در حالی که مأموریت گزارشدهی حاکمیتی منطق متفاوتی دارد. Tier 2 این تنوع را یک مشکل نمیبیند، بلکه آن را لازمه معماری بالغ میداند، به شرطی که همه این سگمنتها به تصمیمهای Tier 1 وفادار بمانند.
در نهایت بحث اختیار مطرح میشود. برخی از واحدهای زیرمجموعه این سازمان سالهاست روشهای ارزیابی و مدیریت ریسک خودشان را دارند. سازمان مادر برای جلوگیری از دوبارهکاری و کاهش هزینه تصمیم میگیرد به آنها اختیار بدهد، اما Tier 2 یک شرط اساسی میگذارد: خروجی ارزیابی ریسک این واحدها باید به شکلی ارائه شود که در سطح سازمان قابل مقایسه و تجمیع باشد. بنابراین یک زبان مشترک ریسک تعریف میشود که بدون تحمیل روش واحد، امکان تصمیمگیری سازمانی را فراهم میکند.
در این سناریو، Tier 2 دقیقاً همان لایهای است که ریسکپذیری از یک تصمیم انتزاعی به یک واقعیت زنده در معماری مأموریتها تبدیل میشود. نه امنیت به تیم فنی رها شده و نه کسبوکار از مسئولیت ریسک شانه خالی کرده است. Tier 2 کاری میکند که وقتی حادثهای رخ میدهد، سازمان بداند چرا این معماری را انتخاب کرده و کدام ریسک را آگاهانه پذیرفته است.
دوره مدیر امنیت CISO آکادمی آموزش روزبه
