این خبر، بخش چهارم مقاله مربوط به امنیت پروتکل IEC 60870-5-104 است که توسط واحد تخصصی آگاهیبخشی سایبر صنعتی شرکت پیشگامان امن آرمان(امان) ارائه شده است.جهت دسترسی به بخشهای قبلی این مقاله به انتهای همین صفحه مراجعه نمایید. مراجع این مقاله فنی در انتهای این خبر درج شده اند و در صورت استفاده از مطالب این مقاله لازم است به مراجع مذکور ارجاع داده شود.
در این بخش قصد داریم تا بر اساس اسناد مرجع برخی راهکارهای امن سازی مرحله طراحی IEC 60870-5-104 را بررسی کنیم؛ قاعدتاً شناخت مسائل درگیر در این بخش به ما کمک میکند تا برخی راهحلهای امن سازی IEC 60870-5-104 و پروتکلهای مشابه را در مرحله طراحی بهتر بیاموزیم و چنانچه قصد داشته باشیم در آینده درزمینهی امن سازی پروتکلهای کنترل صنعتی، بومیسازی امن آنها و ارائه پروتکل کنترل صنعتی جدید امن فعالیت کنیم بتوانیم الگوهای مناسبی برای این حوزه پژوهشی و صنعتی داشته باشیم.
با توجه به اسناد انتشاریافته کنونی در این حوزه راهحلهایی برای پیشگیری از حملات فنی جعل هویت، دستکاری غیرمجاز، ارسال مجدد پیام، شنود (صرفاً در مورد مبادله کلیدهای رمزنگاری) و ممانعت از خدمات ارائهشده است که در ادامه بهاختصار به آنها میپردازیم. در حوزه استانداردها و الزامات امنیتی مرتبط با پروتکلهای مبتنی بر استانداردهای IEC 60870 یکی از مراکز فعال، کمیسیون IEC است. کارگروه 15 IEC مجموعهای از استانداردهای امنیتی را بهمنظور ارتقاء اطمینانپذیری و امنیت زیرساختهای اطلاعاتی منتشر کرده است [19]. عمده الزامات و ملاحظات امن سازی این بخش که با در نظر گرفتن پارامترهای عملکردی و پایداری گردآوری و تهیهشده است مبتنی بر استاندارد IEC/TS 62351 است که یک سند مشخصات فنی میباشد و از سوی کمیته فنی 57 تهیهشده است.
از میان مجموعه استانداردهای منتشرشده در قالب IEC/TS 62351 دو استاندارد خاص از این مجموعه با شمارههای 62351-5 [20] و 62351-3 [21] در ارتباط با پروتکل IEC 60870-5-104 میباشند؛ البته این بدین معنا نیست که این دو استاندارد خاص صرفاً برای IEC 60870-5-104 ارائهشده باشند. استاندارد IEC/ST 62351 تنها بر احراز اصالت لایه کاربرد و مسائل امنیتی ناشی از این استناد تمرکز دارد. سایر دغدغههای امنیتی، خصوصاً حفاظت در برابر حملات صورت گرفته بهواسطه انسان با بهکارگیری تکنیکهای رمزنگاری، خارج از قلمرو این استاندارد میباشند.
1-1- مسائل درگیر در طراحی مکانیزم احراز اصالت
در این استاندارد با مبنا قراردادن مکانیزم احراز اصالت، مسائل درگیر در طراحی مکانیزم را موارد مطرح مینماید که ذیلاً به اهم آنها اشاره میکنیم:
1-1-1- ارتباطات نامتقارن[1]
در IEC 60870-5-104 یک ایستگاه کنترلکننده و یک ایستگاه تحت کنترل وجود دارد که هر یک نقشها، مسئولیتها، دستورالعملها و قالبهای مختلفی برای پیام دارند. بهویژه، ایستگاه کنترلکننده در بسیاری از موارد مسئولیت کنترل جریان و دسترسی رسانهای را بر عهده دارد. وجود ایستگاههای تحت کنترل و کنترل شونده دو تأثیر بر طراحی مکانیزم احراز اصالت دارد:
- قالب پیام در هر مسیر متفاوت بوده، حتی درصورتیکه کارکردها مشابه باشند.
- توزیع کلید از این بابت ساده میشود که آنها همیشه از سوی ایستگاههای کنترلکننده صادر میشوند.
1-1-2- مبتنی بر پیام بودن[2]
IEC 60870-5-104 یک پروتکل مبتنی بر پیام میباشد؛ این بدان معناست که احراز اصالت باید بر اساس پیامها صورت گیرد، نه بر اساس زمان شروع جریان دادهها یا زمان بعدازآن.
1-1-3- دنبالهی اعداد ضعیف یا فقدان دنباله اعداد
یکی از تکنیکهای رایج امنیتی برای رسیدگی به تهدید ارسال مجدد پیام درج یک عدد دنبالهای در پیام است. این عدد شرایط حملهکننده را برای جا زدن خود بهصورت کاربر قانونی بهواسطه کپیبرداری از یک پیام موجود را سخت مینماید. IEC 60870-5-104 اگرچه دارای فیلد SQ است اما کاربرد این فیلد با آنچه در این بخش مدنظر است متفاوت بوده و محدودیت دارد؛ بنابراین در طراحی امن پروتکلهایی نظیر IEC 60870-5-104 باید مکانیزم دنباله عددی مناسب و دیگر داده مکانیزمهای وابسته به زمان را برای حافظت در برابر حملات ارسال مجدد پیام در نظر گرفته شود.
1-1-4- توان پردازش محدود
فقدان توان پردازش بالا در بسیاری از سیستم های کنترل صنعتی یکی از نگرانیهای اصلی طراحی برای پروتکلهای نظیر IEC 60870-5-104 میباشد. این نیاز طراحی الزاماً بر مکانیزم احراز اصالت تأثیرگذار است؛ نگرانی به این دلیل افزایش پیدا مینماید که بسیاری از این دستگاهها ماشینهای تک پردازنده میباشند؛ بنابراین حمله ممانعت از خدمات نهتنها بر قابلیت ارتباطی این دستگاهها تأثیر دارد، بلکه بر کارکردهای آنها بهعنوان کنترل الکتریکی، حفاظتی و نظارت نیز تأثیر دارد؛ بنابراین استفاده از مکانیزمهای امنیتی مانند رمزنگاری کلید عمومی و استفاده از کلیدهایی با اندازه بزرگ که به توان پردازش بالایی نیاز دارند تا جای ممکن اجتناب شده است.
1-1-5- پهنای باند محدود
میزان محدود پهنای باند موجود در شبکههای کنترل صنعتی یکی دیگر از نگرانیهای اصلی طراحی پروتکلهایی نظیر IEC 60870-5-104 میباشد؛ بنابراین، مکانیزم احراز اصالت نباید سربار زیادی را به پروتکلهای تحت تأثیر اضافه نماید. اندازه چالش[3] و دادههای احراز اصالت ازاینرو محدودشده و تا جای ممکن در حالی انتقال داده میشود که سطحی مناسب از امنیت را در برمیگیرد.
1-1-6- عدم دسترسی به سرور احراز اصالت
ماهیت شبکههای کنترل صنعتی که پروتکل IEC 60870-5-104 و سایر پروتکلهای مشابه در آنها منتشر میشوند به اینگونه است که ایستگاههای کنترلکننده اغلب تنها دستگاهی میباشند که بهوسیله آن با ایستگاههای تحت کنترل قابلیت برقراری ارتباط دارند. درصورتیکه دسترسی به دیگر شبکهها وجود داشته باشد، این دسترسی اغلب از طریق ایستگاه کنترلکننده انجام میگیرد. تأثیر این مسئله بر مکانیزم احراز اصالت این است که هر سیستم ای که بهراستی آزمایی[4] برخط[5] اعتبار امنیتی ایستگاه کنترلکننده بهواسطه سیستم شخص ثالث[6] نیاز داشته باشد، غیرعملی میباشد.
1-1-7- چکسام محدود
همانطور که در بخش 3-1-4- توضیح داده شد راهکارهای کنترل صحت مورد انتخاب برای IEC 60870-5-104 بهمنظور حفاظت در برابر نویز تصادفی طراحیشده است، نه حملات موردنظر؛ صحت IEC 60870-5-104 به راهکارهای تأمین صحت لایههای پایین در EPA بستگی دارد. ازآنجاییکه IEC 60870-5-104 یک پروتکل لایه کاربرد و لایه فرآیند کاربر میباشد و از سویی استاندارد منبع [20] صرفاً به بحث در مورد مکانیزم لایه کاربردی میپردازد، نمیتواند به اندازههای کافی تضمینکننده صحت حداقل در لایه کاربرد باشد.
1-1-8- سایتهای از راه دور[7]
دستگاههایی که را پیادهسازی مینمایند اغلب در مناطقی واقع میباشند که فاصله جغرافیایی آنها از یکدیگر دور بوده و دسترسی به آنها هزینه بالایی دارد؛ بنابراین تا جایی که امکان داشته باشد، مکانیزمهای امنیتی ازجمله احراز اصالت توصیه میشود شامل روشهای بهروزرسانی اعتبار به شکل از راه دور باشد.
1-1-9- رسانه غیرقابل اطمینان[8]
IEC 60870-5-104 اغلب در رسانههای غیرقابل اطمینان به کار گرفته میشوند. در طراحی مکانیزمهای امنیتی مانند احراز اصالت توصیه میشود، شرایط خطا را نیز زمانی که عدم اطمینان در رسانه وجود دارد مدنظر قرار گیرد. برای مثال، از دست رفتن یک پیام امنیتی واحد الزاماً به معنای یک حمله نیست.
1-2- مکانیزم طراحی امن
مکانیزم احراز اصالت بر اساس دو مفهوم طراحی میشود:
- پروتکل چالش و پاسخ.
- مفهوم MAC[9] که هر دو ایستگاه کنترلکننده و کنترل شونده بر اساس ASDU یا پیام پروتکل محاسبه میشود، باید احراز اصالت شوند.
مکانیزم احراز اصالتی که در استاندارد [20] شرح دادهشده است بر اساس مفهوم چالش و پاسخ طراحیشده است؛ این مفهوم به دلایل زیر اعمالشده است:
- این مفهوم مسئولیت امنیت در دستگاهی را که نیاز به احراز اصالت دارد فراهم میکند و در شبکههای متنوعی مانند شبکههای کنترل صنعتی شرایط کاربردی مناسبی را فراهم میسازد.
- این مفهوم امکان داشتن ارتباط غیر امن را در صورت لزوم ممکن مینماید و پهنای باند و نیازهای پردازشی را در این شرایط کاهش میدهد.
دیاگرامهای شکل (5) نشانگر نمونه دنباله پیامهایی است که مکانیزم چالش و پاسخ یک ASDU حیاتی را به تصویر میکشد. چالش ممکن است بهوسیله ایستگاه کنترلکننده یا تحت کنترل شروع شود. ازآنجاییکه پروتکلهای سری استاندارد IEC 60870-5 عموماً نامتقارن میباشند، این بدان معناست که قالب حقیقی چالش و پیامهای پاسخ تا حدودی در مسیرهای نظارت و کنترل متفاوت میباشند.
IEC 60870-5-104 ممکن است عملیات الزامی دیگری را نیز تعریف نماید. بهمنظور حفاظت در برابر حملات ارسال مجدد پیام، پیام چالش حاوی دادههایی میباشد که بهصورت تصادفی هر زمان که چالشی صادر میشود، تغییر مینماید. چالشگر در پیام چالش مشخص مینماید که الگوریتم MAC برای پاسخگو به پاسخ به این چالش چگونه باشد. ایستگاه تحت کنترل یا کنترلکننده که چالش را دریافت مینماید باید قبل از اینکه ارتباطات ادامه داشته باشد، پاسخ دهد. پاسخگو الگوریتم MAC تعیینشده در پیام چالش را برای تولید پاسخ اجرا مینماید. کلید نشست مشترک که برای هر دو ایستگاه شناختهشده است یک بخش لاینفک از محاسبه به شمار میرود.
در زمان دریافت پاسخ، چالشگر محاسبات مشابه را رویدادههای مورداستفاده از سوی پاسخگو اعمال مینماید. درصورتیکه نتیجه مطابقت داشته باشد، چالشگر ادامه ارتباط را اجازه میدهد برای کاهش استفاده از پهنای باند یک مد تهاجمی[10] نیز میتوان طراحی کرد، پاسخگو یک عملیات حیاتی[11]را امتحان مینماید و ممکن است بهصورت اختیاری چالش را پیشبینی کرده و مقدار MAC را در ASDU مشابه که حفاظتشده است ارسال نماید. شکل (6) نشانگر احراز اصالت ASDU کلیدی با بهرهگیری از مد تهاجمی موفق میباشد.
استاندارد [20] استفاده از کلیدهای از پیش مشترک را بهعنوان پیشفرض امکانپذیر مینماید. این اصلی مشخص مینماید که بسیاری از تجهیزات کنترل صنعتی برای مدیریت اعتبار امنیتی به شیوهای پیچیدهتر آماده نمیباشد، ولی نیاز به حداقل سطح حفاظتی دارند. این استاندارد همچنین روشهای اختیاری برای تغییر کلیدهای از پیش مشترک به شکل از راه دور را با بهرهگیری از رمزنگاری کلید عمومی متقارن یا نامتقارن فراهم مینماید.
استاندارد [20] از اصول امنیتی محرمانگی پیشرو عالی[12] تبعیت مینماید که در IEC/ST 62351-2 [22] تعریفشده است. استفاده از کلیدهای رمزنگاری و نحوه بهروزرسانی آنها در مکانیزم احراز اصالت اهمیت ویژهای دارد که در استانداردهای مرجع کلیدهای نشست مسیر نظارت، نشست مسیر کنترل، بهروزرسانی، گواهی مرجع[13] (اختیاری)، خصوصی مرجع، عمومی مرجع، خصوصی کاربر، عمومی کاربر، خصوصی ایستگاه تحت کنترل، عمومی ایستگاه تحت کنترل در طراحی در نظر گرفتهشدهاند. در کمترین سطح، کلیدها بهوسیله ایستگاه کنترلشده و کنترلکننده مدیریت میشوند. فرآیند مدیریت کلید بهصورت اختیاری میتواند به کمک شخص ثالث مورد اعتماد صورت گیرد. جهت مطالعه اطلاعات تکمیلی در مورد مدیریت و متعلقات آنها میتوان به [20] و IEC-62351-9 [23] مراجعه کرد. بهعنوانمثال در شکل (7) نمایی سطح بالا از تعامل بین مرجع و ایستگاهها در فرآیند توزیع کلید را مشاهده میکنیم.
بهمنظور پیادهسازی مکانیزمهای ارائهشده نیاز بهاضافه کردن مواردی به استاندارد [24] هستیم. در ادامه بر اساس استاندارد [25] اقدام به معرفی برخی از این موارد میکنیم. مقادیری که باید در فیلد علت انتقال (COT) اضافه شود و شرح مختصری از هر یک در جدول (3) آورده شده است. هدف از اضافه کردن سه مقدار جدید 14، 15 و 16، تجهیز پروتکل هدف به مکانیزمهای احراز اصالت است چراکه به دلیل اهمیت این مقوله، استفاده از کلیدهای رمزنگاری و نحوه بهروزرسانی آنها در استاندارد [25] مورد توجه ویژهای قرار گرفته است. مقادیر یادشده در فیلد علت انتقال به گیرنده پیام وضعیت احراز اصالت، نگهداری کلید نشست و نگهداری کلید نقش کاربر را مشخص میکند.
مقادیری که باید در فیلد شناسه نوع اضافه شود و شرح مختصری از هر یک در جدول (4) آورده شده است. مقادیر بیانشده در جدول (4) مشخص میکند که با توجه به نیازمندیهای متفاوت پیامها در ارتباطات امن و بر اساس نوع تعامل بین طرفین ارتباطات، از چه نوع شناسهای باید استفاده شود.
مقدار جدید | علت انتقال |
---|---|
14 | احراز اصالت |
15 | نگهداری کلید نشست احراز اصالت |
16 | نگهداری نقش کاربر و کلید بهروزرسانی |
شایانذکر است که استاندارد IEC62351 اگرچه مکانیزمهای امنیتی مطلوبی برای ارتقاء امنیت فراهم میکند اما این استاندارد جهت ارتقاء امنیت تمرکز ویژهای بر روی لایه کاربرد دارد، ازاینرو باید به این نکته توجه داشت که در صورت پیادهسازی کامل استاندارد IEC62351 نمیتوان امنیت بالایی در همه لایهها توقع داشت [26]. باید به این نکته توجه کرد که بهمنظور تقویت مکانیزمهای امنیتی مرجع [20] میتوان از سایر استانداردهای خانواده IEC62351 مانند استاندارد [21] جهت افزایش مکانیزمهای محرمانگی یا صحت در ASDUهای استفاده کرد.
در عمل شاهد این هستیم که برخی شرکتهای تولیدکننده تجهیزات صنعتی برخی مکانیزمهای امنیتی را در سطح تجهیزات خود پیادهسازی نمودهاند که بتوان دادههای پروتکلهایی مانند IEC 60870-5-104 که فاقد مکانیزم امنیتیاند را از درون کانالهایی امن ارسال نمود؛ در صورت استفاده ازاینگونه راهحلهای امنیتی باید توجه داشت که مخاطرات امنیتی پروتکل IEC 60870-5-104 از بین نمیرود بلکه صرفاً از پروتکل IEC 60870-5-104 به مخاطرات امنیتی کانال مورداستفاده و پروتکلهای امنی که آن کانال استفاده میکند منتقل میشوند.
جهت مشاهده بخش های دیگر این مقاله بر روی بخش مورد نظر کلیک نمایید:
- بخش 1: معرفی اجمالی پروتکل IEC 60870-5-104
- بخش 2: برخی کارهای انجام شده در حوزه امنیت پروتکل IEC 60870-5-104
- بخش 3: شناسایی اجمالی تهدیدات و آسیبپذیریها پروتکل IEC 60870-5-104
- بخش 4: راهکارهای امن سازی در مرحله طراحی پروتکل IEC 60870-5-104
- بخش 5: بستر آزمایش و ارزیابی امنیت پروتکل IEC 60870-5-104 و نتیجه گیری
جهت مشاهده منابع معرفی شده در این بخش، به مقاله اصلی این خبر که توسط یکی از متخصصین شرکت پیشگامان امن آرمان(امان) در مجله معتبر منادی امنیت فضای تولید و تبادل اطلاعات(افتا) به چاپ رسیده است مراجعه نمایید. همچنین میتوان به کتاب مرجع این مقاله نیز مراجعه نمود.
- شناسایی چالشهای امنیتی پروتکل IEC ۶۰۸۷۰-۵-۱۰۴ و بررسی راهکارهای موجود. مجله منادی امنیت فضای تولید و تبادل اطلاعات(افتا). ۱. ۱۳۹۷; ۷ (۲) :۱۵-۳۰
- کتاب پروتکل کنترل صنعتیIEC 60870-5-104 از منظر امنیت سایبری ، ۱۳۹۶
[1] Asymmetric
[2] Message-Oriented
[3] Challenge
[4] Verification
[5] Online
[6] Third Party
[7] Remote Sites
[8] Unreliable
[9] Message Authentication Code
[10] Aggressive Mode
[11] Critical
[12] Perfect Forward Secrecy
[13] Authority Certification Key