سامانه‌های ITS دیگر شبکه‌های بسته‌ای نیستند که فقط چند کنترلر و یک مرکز مدیریت داشته باشند. دوربین، تابلو پیام متغیر، کنترلر چراغ، حسگر، تجهیزات V2X، سرور، API و دسترسی پیمانکار به هم متصل شده‌اند. این اتصال قابلیت عملیاتی ایجاد می‌کند، اما سطح حمله را هم بزرگ‌تر می‌کند. امنیت در چنین محیطی باید هم اطلاعات را محافظت کند و هم از تداوم عملکرد ترافیکی مراقبت کند.

USDOT برای ITS یک Cybersecurity Framework Profile مبتنی بر چارچوب NIST توسعه داده است تا اهداف مأموریتی حمل‌ونقل به فعالیت‌های امنیتی ترجمه شوند. NIST CSF 2.0 نیز امنیت را در شش تابع Govern، Identify، Protect، Detect، Respond و Recover سازمان می‌دهد. ارزش این چارچوب‌ها در این است که امنیت را از فهرست ابزارها به فرآیند مدیریت ریسک تبدیل می‌کنند.

اول دارایی و مأموریت را بشناسید

نمی‌توان از چیزی که نمی‌شناسیم محافظت کرد. فهرست دارایی باید شامل مدل تجهیز، نسخه نرم‌افزار، آدرس شبکه، محل نصب، مالک عملیاتی، تاریخ پایان پشتیبانی و وابستگی‌های آن باشد. در ITS، یک دوربین ممکن است به سرور ضبط، سامانه تحلیل، شبکه مخابرات و حساب پیمانکار وابسته باشد؛ بنابراین فقط ثبت شماره سریال کافی نیست.

بعد باید اهمیت مأموریتی مشخص شود. قطع تابلو اطلاع‌رسانی با تغییر غیرمجاز فرمان چراغ یک اثر ندارد. طبقه‌بندی بر اساس پیامد کمک می‌کند منابع امنیتی به نقاط حساس‌تر برسند. همچنین برای هر دارایی باید «حالت امن» تعریف شود: در خرابی یا حمله، سامانه چگونه به وضعیتی می‌رود که کمترین خطر عملیاتی را ایجاد کند؟

دارایی، وصله و نشست‌های مدیریتی باید قابل مشاهده و پیگیری باشند.

امنیت در خرید و قرارداد

بخشی از ریسک قبل از نصب ایجاد می‌شود. اسناد خرید باید درباره حساب‌های مدیریتی، روش به‌روزرسانی، رمزنگاری، ثبت لاگ، API، گزارش آسیب‌پذیری و دوره پشتیبانی سؤال روشن داشته باشند. «محصول امن است» معیار قابل آزمون نیست؛ قابلیت‌های امنیتی باید به الزام قابل تحویل تبدیل شوند.

همچنین باید مشخص باشد در پایان قرارداد چه اتفاقی برای حساب پیمانکار، گواهی‌ها، داده‌های نگهداری‌شده و ابزار دسترسی می‌افتد. خروج یک پیمانکار نباید حساب فعال یا دروازه‌ای ناشناخته در شبکه باقی بگذارد.

مدل تهدید، زنجیره تأمین و تغییر امن

کنترل‌های امنیتی زمانی ارزش دارند که به تهدیدهای واقعی سامانه مرتبط شوند. مدل تهدید برای ITS باید دارایی‌های حیاتی، مسیرهای دسترسی، نقش‌های انسانی و پیامدهای عملیاتی را کنار هم بگذارد. برای نمونه، دستکاری یک تابلو پیام متغیر، از دسترس خارج‌شدن ارتباط مرکز با کنترلر یا سرقت حساب پیمانکار آثار یکسانی ندارند. تحلیل سناریویی کمک می‌کند مشخص شود کجا تفکیک شبکه، احراز هویت قوی، ثبت لاگ یا محدودیت فرمان باید اولویت بیشتری داشته باشد. در سامانه‌های OT معیار فقط محرمانگی نیست؛ ایمنی و تداوم خدمت اغلب وزن بیشتری دارند.

زنجیره تأمین بخش مهمی از ریسک است. تجهیزات میدانی معمولاً سال‌ها در سرویس می‌مانند و نرم‌افزار، Firmware و کتابخانه‌های آن‌ها از چند تأمین‌کننده می‌آید. در خرید باید دوره پشتیبانی امنیتی، روش اعلام آسیب‌پذیری، امضای به‌روزرسانی، فهرست اجزای نرم‌افزاری در صورت امکان و فرآیند پایان پشتیبانی روشن باشد. تجهیزی که پس از چند سال دیگر وصله نمی‌شود باید از ابتدا مسیر جایگزینی یا کنترل جبرانی داشته باشد؛ وگرنه یک خرید ارزان می‌تواند بدهی امنیتی بلندمدت ایجاد کند.

تغییرات عملیاتی نیز نیازمند کنترل هستند. به‌روزرسانی Firmware، تغییر Rule فایروال یا فعال‌کردن دسترسی راه‌دور باید با درخواست تغییر، آزمون، ثبت فرد انجام‌دهنده و برنامه بازگشت همراه باشد. برای اجزای حساس بهتر است حالت امن یا Safe State تعریف شود: اگر ارتباط یا سرویس امنیتی مختل شد، تجهیز به چه رفتار کنترل‌شده‌ای برگردد؟ این نگاه امنیت را از مجموعه‌ای از ابزارها به یک قابلیت مهندسی‌شده برای حفظ خدمت و بازیابی تبدیل می‌کند.

تمرین حادثه، تداوم خدمت و سنجش آمادگی

برنامه پاسخ به حادثه اگر فقط به‌صورت سند باقی بماند، در زمان بحران ارزش محدودی دارد. تمرین Tabletop می‌تواند سناریوهایی مانند از دسترس خارج‌شدن مرکز، سوءاستفاده از حساب راه‌دور، آلودگی یک ایستگاه کاری یا اختلال ارتباط با تجهیزات میدانی را بدون ایجاد خطر واقعی مرور کند. تیم فنی، بهره‌بردار، مدیریت و پیمانکار در این تمرین مشخص می‌کنند چه کسی تصمیم می‌گیرد، کدام ارتباط باید قطع شود، چه شواهدی حفظ می‌شود و خدمت حداقلی چگونه ادامه پیدا می‌کند.

شاخص آمادگی نیز باید عملیاتی باشد: زمان کشف، زمان مهار، زمان بازیابی، درصد دارایی‌های دارای مالک مشخص، سهم دسترسی‌های راه‌دور با MFA، سن تجهیزات خارج از پشتیبانی و تعداد تغییرات بدون ثبت. این اعداد جای ارزیابی ریسک را نمی‌گیرند، اما روند را قابل مشاهده می‌کنند. هدف امنیت ITS صفرکردن همه خطرها نیست؛ هدف این است که خطرهای مهم شناخته، کنترل و در صورت وقوع حادثه، سامانه بتواند با اثر محدود و مسیر بازیابی روشن به خدمت بازگردد. نتیجه هر تمرین نیز باید به اقدام قابل پیگیری تبدیل شود؛ مالک اقدام، مهلت اصلاح و آزمون مجدد مشخص باشد تا شکاف شناسایی‌شده در جلسه بعد دوباره به همان شکل تکرار نشود.

جمع‌بندی

امنیت ITS مجموعه‌ای از خرید ابزارهای امنیتی نیست. موجودی دارایی، معماری شبکه، هویت، کنترل تغییر، پایش، پاسخ و چرخه عمر باید به‌عنوان یک سیستم واحد دیده شوند. چارچوب‌های NIST و پروفایل ITS کمک می‌کنند این فعالیت‌ها بر اساس مأموریت و ریسک اولویت‌بندی شوند.

هدف نهایی این است که حتی هنگام نقص یا حمله، شهر بتواند عملکرد حیاتی را در وضعیت قابل کنترل نگه دارد و مسیر بازیابی روشن داشته باشد. امنیت خوب در ITS باید هم برای تیم IT قابل فهم باشد و هم برای مهندس ترافیک و بهره‌بردار میدان.