بخش سوم:
برای افزایش مقیاس کامپیوترهای کوانتومی مبتنی بر یون‌های به دام افتاده،محققان باید از تله‌های سطحی کوچکتر استفاده کنند،در این تله‌ها،یون‌ها توسط میدان‌های الکتریکی که توسط الکترودهای نازک طلایی روی سطح تراشه ایجاد می‌شوند،در بالای تراشه معلق می‌شوند.این تله سطحی، که موضوع مقاله‌ای در سال ۲۰۲۱ توسط محققان موسسه ملی استاندارد و فناوری در بولدر، کلرادو بود،دارای یک آشکارساز فوتونی یکپارچه(نقطه سیاه کوچک در مرکز تراشه)است که برای اندازه‌گیری وضعیت یون‌های بریلیوم که به عنوان کیوبیت عمل می‌کنند،استفاده می‌شود.
#فیزیک_اتمی
#کامپیوتر_کوانتومی
#مکانیک_کوانتومی

بخش چهارم:
راه‌اندازی یک کامپیوتر کوانتومی مبتنی بر اتم‌های خنثی،نیازمند سیستم‌های لیزری متعددی است که برای جابجایی،به دام انداختن،اندازه‌گیری و دستکاری اتم‌هایی که به عنوان کیوبیت عمل می‌کنند،استفاده می‌شوند.این عکس از یک میز نوری در آزمایشگاه اتم‌های خنثی دانشگاه هاروارد،تعدادی از آینه‌ها،لنزها،فیبرهای نوری و حسگرها را نشان می‌دهد که همراه با سایر اجزا،برای هدایت،تقسیم و تثبیت پرتوهای لیزر استفاده می‌شوند.
#فیزیک_اتمی
#کامپیوتر_کوانتومی
#مکانیک_کوانتومی@pythonwithmedev

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

🔹 در این کارگاه با این موضوعات آشنا می‌شوید:
▪️ معماری مدل FAIR و نگاه متفاوت آن به ریسک
▪️ تحلیل تهدیدها و عوامل مؤثر بر وقوع زیان
▪️ محاسبه فراوانی رویدادهای زیان‌بار
▪️ اندازه‌گیری میزان خسارت
▪️ شبیه‌سازی مونت کارلو و تحلیل کمی ریسک

👤 مدرس: دکتر سعید کاظم‌پوریان
(پژوهشگر و متخصص حوزه مدیریت امنیت اطلاعات و ریسک سایبری)

📅 زمان برگزاری: ۱۵ مهر | ساعت ۹ صبح
⏱️ مدت: ۷ ساعت
📍 شیوه برگزاری: حضوری

🎁 تخفیف ویژه برای شرکت‌های دانش‌بنیان و تیم‌های نوپا
⚠️ ظرفیت کارگاه محدود است

👇 ثبت‌نام و اطلاعات بیشتر:
🔗 https://evnd.co/0HMHW

🌐 TEXAHUB.IR
📣 کانال تلگرام آکادمی فن‌افزا:
@fanafza_academy

این تصویر دقیقاً از اون فضاهاییه که چند تا لایه از اتوماسیون صنعتی و OT رو می‌شه هم‌زمان توش دید. پشت سیستم، نمای HMI/SCADA رو داریم که کل فرآیند رو به‌صورت گرافیکی نشون می‌ده؛ مسیرهای فرآیندی، تجهیزات، مخازن و وضعیت بخش‌هایی مثل Cooling Water و Reactor قابل مشاهده‌ست. جلوی تصویر هم Siemens TIA Portal بازه و برنامه‌ی PLC داره بررسی می‌شه؛ یعنی اینجا فقط بحث مانیتورینگ نیست، عملاً منطق کنترلی سیستم هم در حال بررسی و کاره.
چیزی که برای من جذابه اینه که این دو تصویر در واقع دو طرف یک سیستم واحدن؛ پشت صحنه PLC تصمیم‌های کنترلی رو اجرا می‌کنه و HMI/SCADA هم نتیجه و وضعیت فرآیند رو به اپراتور نشون می‌ده. از دید امنیت OT، دقیقاً همین ارتباط خیلی مهمه؛ چون باید بدونیم ارتباط بین Engineering Station، PLC، شبکه صنعتی و HMI/SCADA چطور برقرار شده، چه کسی بهش دسترسی داره و اگر تغییری در منطق PLC یا داده‌های فرآیند ایجاد بشه، چطور می‌شه اون رو تشخیص داد.

توی چنین محیطی دیگه امنیت فقط «فایروال و آنتی‌ویروس» نیست؛ بحث Segmentation، Access Control، مانیتورینگ ترافیک صنعتی، مدیریت Assetها، ثبت رویدادها، حفاظت از پروژه‌های PLC و تشخیص تغییرات غیرمجاز در Logic مطرحه. چیزی که همیشه برام مهمه اینه که توی OT باید هم‌زمان شبکه و فرآیند فیزیکی رو ببینیم؛ چون پشت همین چندتا خط و بلوک برنامه، یک فرآیند واقعی در حال اجراست و یک تغییر دیجیتال می‌تونه در نهایت اثر خودش رو روی دنیای فیزیکی بذاره.

اینجا دقیقاً جاییه که امنیت سایبری از دنیای IT خارج می‌شه و با مهندسی کنترل و فرآیند واقعی گره می‌خوره.

اینجا برای من صرفاً بازدید از یک مجموعه صنعتی نبود چیزی که واقعاً برام ارزش داشت، دیدن و تحلیل کردن معماری واقعی یک زیرساخت OT در مقیاس صنعتی از زاویه امنیت بود. وقتی وارد چنین محیطی می‌شی، دیگه نمی‌تونی شبکه رو مثل یک شبکه IT معمولی ببینی؛ باید بفهمی هر Asset دقیقاً چه نقشی در فرآیند داره، کدوم مسیرهای ارتباطی واقعاً ضروری هستن، کجاهای معماری باید از هم تفکیک بشن و چه ارتباطی بین لایه‌های Field، Control، Supervisory و Engineering وجود داره. بخشی از تجربه‌ای که اینجا برای من شکل گرفت، کار روی Asset Inventory و شناخت Dependencyهای بین تجهیزات، بررسی معماری شبکه و Trust Boundaryها، تحلیل مسیرهای ارتباطی بین PLC، HMI، Engineering Station و سرورهای کنترلی، بررسی رفتار پروتکل‌های صنعتی و ایجاد Baseline برای ارتباطات مجاز بود. چیزی که در محیط واقعی خیلی زود متوجهش می‌شی اینه که نمی‌تونی با منطق IT بیای داخل OT و انتظار داشته باشی همه‌چیز جواب بده؛ اینجا هر تغییر باید با درنظرگرفتن Availability، زمان‌بندی فرآیند، وابستگی تجهیزات و حتی پیامد فیزیکی اون تغییر انجام بشه.

یکی از بخش‌های مهم تجربه برای من، نگاه کردن به سیستم از دید Detection و Incident Response در OT بود یعنی اگر یک Engineering Station رفتار غیرعادی داشته باشه، اگر یک Asset با مقصدی که در Baseline شبکه نبوده ارتباط برقرار کنه، اگر Logic یک کنترلر بدون Change کنترل‌شده تغییر کنه یا الگوی ترافیک یک تجهیز از رفتار معمول خودش فاصله بگیره، چطور باید این تغییر رو تشخیص داد و بدون اینکه خود سیستم مانیتورینگ یا فرآیند صنعتی رو مختل کنیم، منشأ اتفاق رو پیدا کنیم. اینجا بود که برای من مفاهیمی مثل Passive Monitoring، Network Baseline، Anomaly Detection، Change Management، Zone & Conduit، Least Privilege و OT Incident Response از اصطلاحات تئوری تبدیل شدن به مسئله واقعی مهندسی. مهم‌تر از همه، یاد گرفتم در یک زیرساخت صنعتی همیشه سؤال اصلی این نیست که «چطور سیستم رو امن‌تر کنیم؟»؛ سؤال حرفه‌ای‌تر اینه که چطور سطح حمله رو کم کنیم، بدون اینکه قابلیت کنترل، ایمنی و تداوم فرآیند رو قربانی کنیم. این جنس تجربه برای من ارزشمندتر از صدها ساعت کار آزمایشگاهی بود؛ چون اینجا هر تصمیم امنیتی باید هم‌زمان از فیلتر شبکه، کنترل، فرآیند، مهندسی و ریسک عملیاتی عبور کنه. این دقیقاً همون جاییه که فهم واقعی من از امنیت OT شکل گرفت؛ جایی که دیگه Packet فقط Packet نیست، یک PLC فقط یک کامپیوتر صنعتی نیست و یک تغییر کوچک در شبکه می‌تونه بخشی از یک فرآیند فیزیکی بزرگ‌تر رو تحت تأثیر قرار بده.

اگر بخوام کل مسیرم رو از اول تا امروز، با بحث بازار کار و درآمد همون‌طوری تعریف کنم که خودم تعریف می‌کنم، داستان برای من اینه من از اول با هدف اینکه صرفاً متخصص امنیت بشم وارد این مسیر نشدم. رشته دانشگاهی من مهندسی انرژی بود و اتفاقاً همین رشته باعث شد از همون اول با سیستم‌های انرژی، فرآیندهای صنعتی و زیرساخت‌های واقعی درگیر بشم. ولی هم‌زمان علاقه‌ام به کامپیوتر و شبکه باعث شد برم سمت Linux، Network، سیستم‌عامل، Cybersecurity و تحلیل ترافیک و کم‌کم فهمیدم نقطه‌ای که واقعاً برای من جذابه جاییه که این دو دنیا به هم می‌رسن یعنی جایی که یک شبکه کامپیوتری دیگه فقط شبکه نیست و پشتش یک فرآیند صنعتی واقعی قرار داره. از همین‌جا وارد ICS، SCADA، PLC، HMI، Industrial Networks و OT Security شدم و شروع کردم معماری سیستم‌های کنترل رو از پایه فهمیدن؛ اینکه Field Level چیه، Control Level چطور کار می‌کنه، PLC چه نقشی داره، HMI و SCADA چطور با کنترلرها ارتباط می‌گیرن، پروتکل‌های صنعتی چطور رفتار می‌کنن و مهم‌تر از همه، اگر امنیت این زنجیره دچار مشکل بشه، اثرش فقط روی یک کامپیوتر نیست و می‌تونه به یک فرآیند فیزیکی واقعی برسه. بعد مسیرم جدی‌تر شد و رفتم سمت Asset Discovery، Network Segmentation، Zone & Conduit، Access Control، Passive Monitoring، Industrial Protocol Analysis، Detection، Incident Response و Security Architecture برای محیط‌های OT؛ یعنی کم‌کم از امنیت یک سیستم رسیدم به امنیت یک زیرساخت. چیزی که برای من اینجا خیلی مهم بود این بود که تجربه واقعی بهم یاد داد OT رو نمی‌شه با ذهنیت صرفاً IT مدیریت کرد اینجا Availability، Safety و Process Integrity اهمیت حیاتی دارن و هر تغییر امنیتی باید بدون آسیب زدن به فرآیند انجام بشه. بعدتر همین مسیر باعث شد علاقه‌ام به زیرساخت‌های انرژی، Smart Grid، Microgrid، Digital Twin و در نهایت سیستم‌های پیچیده‌تر انرژی و هسته‌ای هم جدی‌تر بشه یعنی به جای اینکه مهندسی انرژی رو کنار بذارم، اون رو با Computer و Cybersecurity ترکیب کردم و دقیقاً از همین ترکیب برای خودم یک حوزه تخصصی ساختم. بازار کار هم دقیقاً همین‌جا جالب می‌شه، چون من دیگه خودم رو صرفاً در بازار Cybersecurity عمومی نمی‌بینم مسیرهایی مثل OT/ICS Security Engineer، Industrial Cybersecurity Engineer، OT Security Architect، SCADA Security Engineer، Industrial Cybersecurity Consultant، OT Incident Response، Security Engineer برای زیرساخت‌های انرژی و Critical Infrastructure برام تعریف می‌شن. بازار ۲۰۲۶ هم نشون می‌ده که این تخصص واقعاً یک حوزه مستقل و رو به رشد شده؛ برای نمونه، یک گزارش بازار برای آلمان رشد تقاضای OT/ICS Security Engineer رو حدود ۱۸٪ نسبت به سال قبل گزارش کرده و Median حقوق این نقش رو حدود €88K ناخالص سالانه آورده، البته این‌ها داده‌های بازار هستن و نه تضمین حقوق یک فرد مشخص. در آلمان، داده Jobvector در سپتامبر ۲۰۲۶ میانگین حقوق OT Security رو حدود €60.5K ناخالص سالانه و بازه گزارش‌شده برای متخصصان رو حدود €59.7K تا €70K اعلام کرده؛ اختلاف این اعداد با Benchmarkهای Senior به خاطر تفاوت سطح شغلی، نمونه آماری و تعریف نقش‌هاست. در Benchmark دیگری برای ۲۰۲۶، نقش Senior OT Security Engineer در آلمان حدود €90K تا €122K در برلین، €98K تا €132K در مونیخ و €95K تا €128K در فرانکفورت گزارش شده؛ این اعداد حقوق پایه و indicative هستن و Bonus و مزایای جانبی رو شامل نمی‌شن. حتی در هلند، یک موقعیت واقعی OT Cyber Security Officer برای زیرساخت و SCADA در سپتامبر ۲۰۲۶ بازه €5,000 تا €7,000 ناخالص ماهانه گذاشته بود. یعنی هرچی از سطح General Cybersecurity فاصله می‌گیری و وارد جایی می‌شی که باید هم Cybersecurity بفهمی، هم Automation، هم Industrial Network، هم فرآیند انرژی و هم محدودیت‌های OT، تخصصت کمیاب‌تر و بازارش تخصصی‌تر می‌شه؛ البته در مقابل، مسئولیت هم خیلی بالاتر می‌ره. برای همین من این مسیر رو این‌طوری می‌بینم: مهندسی انرژی پایه فهم فرآیند رو به من داد، کامپیوتر ابزار تحلیل رو داد، امنیت به من نگاه دفاعی داد، شبکه صنعتی منو وارد دنیای OT کرد و تجربه محیط واقعی بهم یاد داد چطور این‌ها رو کنار هم قرار بدم. نتیجه‌اش برای من فقط یک عنوان شغلی نیست؛ یک پروفایل بین‌رشته‌ایه که می‌تونه در شرکت‌های انرژی، نیروگاه‌ها، اتوماسیون صنعتی، تولید، صنایع فرآیندی، زیرساخت‌های حیاتی، مشاوره امنیت و پروژه‌های Industrial Digitalization استفاده بشه.

حتی آگهی‌های واقعی فعلی هم دقیقاً ترکیبی از PLC، SCADA، Industrial Networks و ISA/IEC 62443 رو کنار OT Cybersecurity می‌خوان و چیزی که برای خودم مهم‌تر از عدد حقوقه اینه که من از مهندسی انرژی وارد امنیت نشدم که رشته قبلیم رو کنار بذارم؛ برعکس، سعی کردم از ترکیب این دو یک تخصص بسازم که هم مهندسی فرآیند رو بفهمه، هم زبان شبکه و امنیت رو. برای همین اگر کسی ازم بپرسه چطور وارد این مسیر شدی و چرا ادامه‌اش دادی جوابم اینه من دنبال یک شغل ساده‌تر نرفتم رفتم سراغ جایی که دو تا دنیای سخت، یعنی مهندسی صنعتی و امنیت سایبری، به هم می‌رسن. هرچی جلوتر رفتم، سخت‌تر شد، ولی دقیقاً به همین دلیل ارزش تخصصش برای من بیشتر شد

یک آسیب‌پذیری مهم در TDengine TSDB با شناسه CVE-2026-42542 کشف شده که می‌تواند باعث ایجاد اختلال از راه دور در سرویس شود. TDengine یک پایگاه‌داده توزیع‌شده سری زمانی است که در حوزه‌هایی مثل Industrial IoT، انرژی، تله‌متری صنعتی و سیستم‌های مانیتورینگ برای دریافت، ذخیره و پردازش داده‌های تجهیزات استفاده می‌شود.

این آسیب‌پذیری با امتیاز CVSS 7.5 و شناسه CWE-191 مربوط به یک Integer Overflow در تابع "uvConnMayGetUserInfo()" از کامپوننت "taosd" است. مشکل هنگام پردازش پروتکل RPC اختصاصی TDengine و قبل از مرحله احراز هویت رخ می‌دهد؛ یعنی مهاجم بدون داشتن نام کاربری، رمز عبور یا Session فعال، تنها با ارسال یک Packet RPC دستکاری‌شده می‌تواند باعث Crash شدن پردازش "taosd" و در نتیجه ایجاد Denial of Service شود.

نسخه‌های 3.4.0.0 تا 3.4.1.5 تحت تأثیر این آسیب‌پذیری هستند و این مشکل در نسخه 3.4.1.6 برطرف شده است. طبق گزارش Ridge Security، تاکنون شواهدی از سوءاستفاده واقعی از این آسیب‌پذیری وجود ندارد، اما یک نمونه PoC برای اثبات امکان حمله توسعه داده شده است.

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

راهکار اصلی، بروزرسانی TDengine به نسخه 3.4.1.6 یا بالاتر، محدودسازی دسترسی شبکه به سرویس، جداسازی مناسب شبکه‌های صنعتی و پایش ترافیک غیرعادی RPC است.

منابع:
TDengine Security Advisory:
https://docs.tdengine.com/security-guide/security-advisories/

Ridge Security Technical Analysis:
https://ridgesecurity.ai/blog/one-packet-can-take-down-the-database-behind-industrial-operations-ridge-security-discovers-cve-2026-42542/

سیستم تشخیص نفوذ (IDS) برای اینترنت صنعتی اشیاء (IIoT) بر روی خانواده‌های جدیدی از حملات مورد آزمایش قرار گرفت.

محققان یک سیستم تشخیص نفوذ (IDS) برای اینترنت صنعتی اشیاء (IIoT) ارائه دادند که دو مکانیسم تشخیص حمله را با هم ترکیب می‌کند. مکانیسم اول، انواع شناخته‌شده از حملات را طبقه‌بندی می‌کند، در حالی که مکانیسم دوم تلاش می‌کند تا ترافیکی را شناسایی کند که شبیه داده‌های موجود در مجموعه آموزشی نباشد. این سیستم بر اساس یک طرح آزمایش شد که در آن یک کل خانواده از حملات از مجموعه آموزشی حذف شده و فقط در مرحله تست ظاهر می‌شد.

آزمایش اصلی بر روی X-IIoTID انجام شد. این یک مجموعه داده‌ی باز برای تحقیق در مورد حملات در محیط IIoT است که شامل 820,834 رکورد از فعالیت‌های عادی و مخرب است. این مجموعه داده شامل داده‌های ترافیک شبکه، گزارش‌های سیستم و برنامه‌ها، استفاده از منابع دستگاه‌ها و رویدادهای IDS است. این مجموعه داده شامل فعالیت‌هایی مانند شناسایی، بهره‌برداری از آسیب‌پذیری‌ها، حرکت جانبی، خواندن رجیستر‌های Modbus، دستکاری داده‌ها، باج‌افزار و سایر سناریوها است.

مدل ترکیبی، نتایجی بهتر از هر یک از آشکارسازها به صورت جداگانه و همچنین دو روش رایج برای شناسایی ناهنجاری‌ها، یعنی Isolation Forest (که با جداسازی آماری رکوردهای غیرعادی از مجموعه‌ی اصلی داده‌ها، آن‌ها را شناسایی می‌کند) و One-Class SVM (که بر روی یک کلاس، معمولاً ترافیک عادی، آموزش داده می‌شود و اشیاء بسیار متفاوت را به عنوان ناهنجاری علامت‌گذاری می‌کند)، به دست آورد. این تفاوت‌ها از نظر آماری معنادار بودند (p <0.001). حجم مدل کمتر از 2 مگابایت بود و پردازش یک رکورد کمتر از 1 میلی‌ثانیه طول می‌کشید.

به طور جداگانه، مدل بر روی ToN-IoT، مجموعه‌ی داده UNSW Canberra که شامل ترافیک شبکه، داده‌های تله‌متری دستگاه‌های IoT/IIoT و رویدادهای Windows و Linux است، آموزش داده شد و سپس بدون آموزش اضافی، بر روی X-IIoTID آزمایش شد. در این آزمایش، کارایی کلی تقریباً تصادفی بود و روش ترکیب آشکارسازها بین دو مجموعه داده، قابل انتقال نبود. آزمایش‌ها بر روی مجموعه‌های داده انجام شد، نه در یک سیستم کنترل صنعتی واقعی.

منبع: Zhimin Ren, Yi Bao, Adaptive Fusion of Closed-World and Open-Set Detectors for Zero-Day Attack Generalization in Industrial IoT Intrusion Detection
https://doi.org/10.1007/s10586-026-06631-7

🛡️ CVE-2026-8065 | BDU:2026-15878

یکی از آسیب‌پذیری‌های مهم اخیر در حوزه OT/ICS مربوط به کنترل‌کننده‌های Hitachi Energy RTU500 سری CMU منتشر شده؛ جایی که یک ضعف در احراز هویت برای عملکرد حیاتی باعث میشه مهاجم از راه دور، بدون نیاز به احراز هویت، به قابلیت Firmware Update دسترسی پیدا کنه.

در سناریوی سوءاستفاده، امکان ارسال درخواست مخرب و بارگذاری Firmware دلخواه روی تجهیز وجود داره؛ موضوعی که می‌تونه یکپارچگی و در دسترس بودن RTU رو تحت تأثیر قرار بده و در محیط‌های صنعتی و زیرساخت‌های انرژی، اهمیت خیلی بالایی داره. شدت این آسیب‌پذیری Critical و CVSS 9.1 اعلام شده.

نسخه‌های قدیمی RTU500 CMU که در محدوده 11.x و قبل‌تر قرار دارن تحت تأثیر گزارش‌های سازنده هستن و Hitachi Energy توصیه کرده به نسخه‌های پشتیبانی‌شده ارتقا داده بشن؛ از جمله 12.7.8 یا 13.9.1 یا آخرین نسخه موجود.

نکته مهم برای محیط‌های OT اینه که اینجا فقط بحث یک Web Vulnerability معمولی نیست؛ وقتی یک RTU در زنجیره کنترل و اتوماسیون زیرساخت قرار داره، دستکاری Firmware می‌تونه مستقیماً روی Availability و Integrity تجهیز اثر بذاره. 🔴⚙️

📌 CVE: CVE-2026-8065
📌 BDU: BDU:2026-15878
📌 CWE: CWE-306 — Missing Authentication for Critical Function
📌 Severity: Critical | CVSS 9.1

🔗 توصیه رسمی Hitachi Energy: "Security Advisory – RTU500" (https://publisher.hitachienergy.com/preview?DocumentID=8DBD000251&LanguageCode=en&DocumentPartId=&Action=Launch&utm_source=chatgpt.com)

🔻 وقتی شبکه برق فقط یک مسئله الکتریکی نیست؛ پای امنیت سایبری هم وسط است
این تصویر مربوط به شبکه استاندارد IEEE 39-Bus هست؛ مدلی که برای بررسی و شبیه‌سازی رفتار شبکه‌های قدرت استفاده می‌شه. در نگاه اول، چیزی که می‌بینیم مجموعه‌ای از شینه‌ها، خطوط انتقال و ژنراتورهاست؛ اما وقتی همین شبکه رو از دید امنیت سیستم‌های کنترل صنعتی بررسی کنیم، موضوع کمی متفاوت می‌شه.
در زیرساخت‌های حیاتی، شبکه برق فقط از تجهیزات الکتریکی تشکیل نشده. بخش مهمی از عملکرد اون به سامانه‌های کنترل، تجهیزات اندازه‌گیری، ارتباطات صنعتی و سیستم‌های نظارتی مثل SCADA وابسته است. اطلاعاتی که از سطح میدان جمع‌آوری می‌شن، به مرکز کنترل می‌رسن و مبنای تصمیم‌گیری اپراتور یا الگوریتم‌های کنترلی قرار می‌گیرن.

حالا فرض کنید بخشی از این اطلاعات دست‌کاری بشه یا داده‌ای نادرست به سامانه کنترل برسه. مسئله دیگه صرفاً یک خطای نرم‌افزاری یا اختلال در ارتباطات نیست؛ باید بررسی کرد که این اتفاق چه اثری روی وضعیت واقعی شبکه، تصمیم‌های کنترلی و در نهایت پایداری سیستم می‌ذاره.
اینجاست که مفهوم Cyber-Physical Security اهمیت پیدا می‌کنه؛ جایی که امنیت سایبری رو نمی‌شه جدا از رفتار فیزیکی فرایند بررسی کرد. برای مثال، مدل IEEE 39-Bus می‌تونه بستری برای مطالعه اثر حملات تزریق داده جعلی، ارزیابی روش‌های تشخیص ناهنجاری و بررسی ارتباط بین داده‌های اندازه‌گیری و وضعیت واقعی شبکه باشه.
البته خود این نمودار یک مدل الکتریکیه، نه نقشه شبکه ارتباطی یا سامانه SCADA. برای تحلیل کامل امنیتی، باید مدل شبکه قدرت رو با معماری کنترل و ارتباطات صنعتی ترکیب کرد تا بشه اثر یک سناریوی سایبری رو در کنار پیامدهای فیزیکی اون ارزیابی کرد.
به نظرم یکی از نکات مهم در امنیت زیرساخت‌های حیاتی همین‌جاست؛ اینکه صرفاً امن بودن تجهیزات یا شبکه ارتباطی کافی نیست. باید بدونیم اگر داده‌ای تغییر کرد، ارتباطی مختل شد یا یک فرمان غیرمنتظره صادر شد، فرایند صنعتی چه واکنشی نشون می‌ده.
در امنیت OT، هدف فقط شناسایی حمله نیست؛ مهم اینه که بفهمیم حمله چه اثری روی فرایند واقعی می‌ذاره.
#ICS_Security #OT_Security #SCADA #PowerGrid #CyberPhysicalSecurity

بیمه تکمیلی هم داره.
محل سکونت هم بهتون میدن.
حقوقشم مناسبه. اگر سمت سیرجان هستید از دست ندید.

یکی از سناریوهای مهم توی امنیت سایبری شبکه‌های برق، حملاتیه که هدفشون لزوماً از کار انداختن تجهیزات نیست، بلکه دست‌کاری داده‌هایی هست که سیستم بر اساسشون وضعیت شبکه رو تحلیل می‌کنه. این تصویر دو راهبرد TSDA و BLIA رو در چند مرحله نشون می‌ده که طی اون‌ها خطوط انتقال، نقاط تولید و مسیرهای مختلف شبکه بررسی می‌شن تا اثر حمله و شرایط نهایی شبکه مشخص بشه. بخش مهم ماجرا، حملات FDI یا تزریق داده جعلیه؛ جایی که مهاجم می‌تونه داده‌های اندازه‌گیری رو طوری دست‌کاری کنه که سامانه کنترل و پایش، وضعیت شبکه رو متفاوت از واقعیت ببینه. اصطلاح Targeted Line هم به خط انتقال هدف‌گذاری‌شده در این سناریو اشاره داره. حالا اهمیت این موضوع برای امنیت ICS/SCADA چیه؟ اینکه توی زیرساخت‌های حیاتی، صرفاً سالم بودن تجهیزات و برقرار بودن ارتباطات به معنی امن بودن سیستم نیست. اگه داده‌های ورودی قابل اعتماد نباشن، حتی یک سامانه کنترل سالم هم ممکنه بر اساس اطلاعات اشتباه تصمیم بگیره. به همین دلیل، امنیت شبکه‌های صنعتی فقط محدود به فایروال، تفکیک شبکه و کنترل دسترسی نیست

اعتبارسنجی داده‌ها، تحلیل رفتار فرایند فیزیکی، تشخیص ناهنجاری و مقایسه وضعیت محاسبه‌شده با وضعیت واقعی شبکه هم اهمیت اساسی دارن. البته برای تفسیر دقیق جزئیات دو راهبرد TSDA و BLIA و معنای همه مراحل، باید به مقاله اصلی مراجعه کرد؛ چون خود تصویر به‌تنهایی تمام فرضیات و سازوکارهای روش‌ها رو مشخص نمی‌کنه. در نهایت، توی امنیت زیرساخت‌های حیاتی، گاهی خطر واقعی از جایی شروع می‌شه که همه‌چیز روی مانیتور عادی به نظر می‌رسه، اما داده‌هایی که این تصویر رو ساخته‌ان، دیگه قابل اعتماد نیستن. 🔐⚡