نقل از کاربری که ۳۶ میلیون تومان وجه رایج رو تقدیم مدلی کرده که طی دو روز مصرف توکنش لیمیت میشه ..!

#Claude

چند وقت پیش داشتم یه دیتا دامپ رو بررسی میکردم که به یه نکته جالب برخوردم. توی تصویر بالا، یک سری دامپ و Watch از آدرسهای ۰x۱ تا ۰x۵۷ گرفتم. اولین چیزی که جلب توجه میکنه، الگوی افزایشی صرفاً عددی نیست، بلکه با دقت به دادههایی که به تابع PRGA پاس داده شدن، یه موضوع کلیدی کشف میشه. توی معماری RC4 و الگوریتمهای مبتنی بر جریان کلید، ورودی PRGA تعیینکننده جهت عملیاته. اگر ورودیها کلید یا IV باشن، خروجی باید کاملاً شبهتصادفی باشه، اما اینجا خروجیها ساختار مشخص و معناداری دارن. با بررسی مقادیر ورودی ۱ تا ۵۷ و مقایسه با خروجیهای متناظر، متوجه میشیم که دادههای ورودی دقیقاً همون Ciphertext هستن، چون خروجیهای به دست اومده الگویی غیرتصادفی دارن که قابل تفسیر بهعنوان Plaintext هستن. به عبارت دیگه، اگه سیستم در حالت رمزنگاری بود، ورودی PRGA میبایست کلید یا IV میبود و خروجی بایستی کاملاً رندوم میرفت، ولی اینجا خروجیها بازگشت به متن اصلی رو نشون میدن. در نتیجه، سیستم در حال Decryption هست، نه Encryption و دادههای Watch درواقع همون خروجی PRGA هستن که متن آشکار رو تشکیل میدن. این روش یه راه جانبی جالب برای تشخیص جهت عملیات رمز

توی ادامه بررسی، رفتم سراغ سکشن .s7b2 داخل Ghidra. اولین چیزی که نظرمو جلب کرد، چندتا لوکیشن لیبل‌گذاری شده بود که یکی از اونا مستقیماً به دیتای رمز شده (Encrypted Config) اشاره میکرد. اما سه تا لیبل دیگه هم اونجا بودن که هدفشون مشخص نبود. با کمی جلوتر رفتن و دنبال کردن جریان، متوجه شدم که یه HW Breakpoint روی تابع رمزگشایی RC4 تنظیم شده و وقتی breakpoint میخوره، میتونیم ببینیم که دادهها چطور پردازش میشن. اینجا بود که ارتباط بین این لیبلها مشخص شد: دو تا از اون سه لیبل باقی مونده، یکی به کلید RC4 اشاره داره و اون یکی هم به سایز دیتای رمز شده. پس ساختار کلی به این صورته: یه سکشن خاص حاوی دیتای رمز شده، یه کلید RC4 در جای دیگه، یه سایز مشخص برای دیتا، و در نهایت تابع رمزگشایی که همه اینارو کنار هم میذاره و دیتا رو به حالت اصلی برمیگردونه. این روش نشون میده که چطور با تحلیل استاتیک و داینامیک همزمان، میتونیم اجزای یک رمزنگاری جریانی رو در بدافزارها شناسایی کنیم و بفهمیم که دادهها چطور محافظت میشن و چطور باید اونا رو رمزگشایی کرد.

یه نمونه‌ی اجرایی اومد دستم به اسم raas.exe. توی x32dbg لودش کردم و ScyllaHide رو هم فعال کردم. همون ابتدای کار، توی Entry Point، یه CALL به تابع 402BD6 توی افست 40125E می‌زد. بعدش مقدار EAX رو چک می‌کرد، اگر غیرصفر بود می‌رفت 4013BE و ExitProcess می‌زد. یعنی اگه اون تابع تشخیص می‌داد محیط دیباگه، برنامه خودش رو می‌کشت.

رفتم سراغ تابع، با Step Into رفتم توش و با Step Over جلو رفتم تا رسیدم به 402C16 که نوشته بود call eax. اونجا مشخص شد که EAX رو GetProcAddress پر کرده بوده و توی ECX اشاره‌گر به رشته‌ی "BlockInput" بوده. یعنی با یه رزول پویا اومده بود تابع BlockInput رو گیر آورده، بدون اینکه توی IAT دربیاد.

BlockInput ورودی ماوس و کیبورد رو برای بقیه برنامه‌ها قطع می‌کنه. اینجا با PUSH 1 فعالش کرده بود. یه تکنیک رایج توی بدافزارها که نمی‌ذاره تحلیلگر راحت کار کنه. ولی با تموم شدن فرآیند یا Ctrl+Alt+Del برطرف می‌شه.

جالب اینجاست که استاتیک با Ghidra اینو نمی‌تونستم ببینم، چون اسم تابع رو موقع اجرا رزول می‌کرد. تحلیل دینامیک اینجا خیلی کمک کرد و بی‌سرمایه‌وقت اضافی به ته ماجرا رسیدم.

زبان سیگما یک استاندارد متن‌باز برای توصیف قواعد تشخیص تهدید در لاگ‌هاست که قابلیت ترجمه به فرمت‌های بومی SIEMهایی نظیر Splunk، Elasticsearch، QRadar و ArcSight را دارد و هدف آن یکپارچه‌سازی و اشتراک‌گذاری الگوهای حمله است. هر قاعده از سه بخش اجباری تشکیل می‌شود: عنوان (۱ تا ۲۵۶ کاراکتر، بدون شروع با "Detect")، منبع لاگ شامل Category (نوع لاگ)، Product (بستر عملیاتی) و Service (سرویس خاص) و در موارد پیچیده Definition، و بخش تشخیص با شرط Condition که ترکیبی از شناسه‌های رویداد، عبارات منظم یا مقادیر هش است. فیلدهای اختیاری شامل ID، Status، Description، Author، References، Fields، Falsepositives، Level و Tags (برای نگاشت به MITRE ATT&CK) هستند. نمونه قاعده CertUtil با عنوان Suspicious Certutil Command، وضعیت experimental، توضیحات مرتبط با زیردستور decode و ارجاع به منابع معتبر، نشان‌دهنده کاربرد عملی در شناسایی ابزارهای دوگانه‌سود است. مزایای اصلی شامل خودکارسازی جستجوی تهدید، استقلال از فروشنده، دقت بالا و قابلیت شخصی‌سازی است.

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

شناسایی نوع سیستم فایل یکی از اقدامات پایه‌ای در مدیریت ذخیره‌سازی و تحلیل امنیتی محسوب می‌شود و روش‌های آن بسته به دسترسی به سیستم به دو شاخه پاسخ‌دهی زنده و بررسی آف‌لاین تقسیم می‌گردد. در حالت دسترسی زنده، سه دستور اصلی کاربرد دارند: دستور lsblk -f که اطلاعات ساختاریافته‌ای از تمام بلاک‌دستگاه‌ها شامل نوع سیستم فایل، UUID، اندازه و نقطه‌اتصال را به صورت ستون‌بندی و خوانا نمایش می‌دهد و در سیستم‌هایی مانند CentOS به وضوح پارتیشن‌های xfs برای /boot و ریشه و همچنین حضور LVM2_member را مشخص می‌کند؛ دستور df -Th که علاوه بر نوع سیستم فایل، اطلاعات استفاده از دیسک مانند فضای کل، استفاده‌شده، موجود و درصد استفاده را به همراه نقطه‌اتصال هر پارتیشن نشان می‌دهد، اما در سیستم‌های دارای سرویس‌هایی مانند Docker خروجی آن شلوغ شده و تشخیص نوع اصلی سیستم فایل را دشوار می‌سازد، در حالی که در همین شرایط lsblk -f خروجی تمیزتری ارائه کرده و به عنوان مثال در سیستم اوبونتو به روشنی بخش بوت را از نوع FAT32 و سیستم فایل اصلی را EXT4 معرفی می‌کند؛

و دستور cat /etc/fstab که فایل شامل اطلاعات سیستم فایل‌های ثابت mount شونده در زمان بوت را نمایش داده و در سیستم‌های زنده نمای کلی از پارتیشن‌های دائمی و نوع آن‌ها ارائه می‌دهد. در حالت بررسی آف‌لاین یا Deadbox Forensics که به Image دیسک دسترسی وجود دارد، معمولاً از دستور cat /etc/fstab بر روی Image مونت‌شده استفاده می‌شود تا جدول سیستم فایل بررسی گردد و این روش حتی در صورت عدم اجرای سیستم عامل نیز قابل انجام است و اطلاعات دقیقی از نوع و نقاط اتصال پارتیشن‌ها در اختیار تحلیلگر قرار می‌دهد. از مقایسه این روش‌ها برمی‌آید که lsblk -f به دلیل خروجی ساختاریافته و سطح پایین‌تر هسته، گزینه اولیه در پاسخ‌دهی زنده محسوب می‌شود؛ df -Th برای تحلیل فضای مصرفی و شناسایی سریع نقاط اتصال مفید است هرچند در محیط‌های مجازی‌سازی شده نویز ایجاد می‌کند؛ و cat /etc/fstab در هر دو حالت زنده و مرده نمای پایداری از سیستم فایل‌های دائمی ارائه می‌دهد که برای تأیید تنظیمات و تحلیل پس از حمله حیاتی است و ترکیب این سه روش، شناسایی کامل نوع سیستم فایل از xfs و ext4 تا FAT32 و LVM را با دقت بالا ممکن می‌سازد و برای عملیات‌هایی نظیر بازیابی داده، تحلیل بدافزار و مهندسی معکوس زیرساخت ضروری می‌باشد.

بررسی فاجعه امنیتی Equifax در سال ۲۰۱۷ همچنان یکی از تلخترین و در عین حال آموزنده ترین نمونه های شکست در زنجیره مدیریت امنیت سایبری محسوب میشود؛ پروندهای که در آن یک آسیبپذیری شناخته شده با نمره خطر ۱۰ از ۱۰، به دلیل مجموعهای از خطاهای ساده اما زنجیروار، به فاجعه بارترین نقض داده های تاریخ تبدیل شد. ماجرا از سیستم تحت وب ACIS شروع شد، اپلیکیشنی که کاربران برای اعتراض به اطلاعات نادرست گزارش اعتباری خود از آن استفاده میکردند و شامل دو وبسرور، دو اپلیکیشن سرور و سه دیتابیس پشتیبان بود. در مارس ۲۰۱۷، بنیاد Apache آسیبپذیری بحرانی CVE-2017-5638 را در فریمورک Struts اعلام کرد که به مهاجم اجازه میداد بدون نیاز به احراز هویت، به سادگی کد دلخواه خود را روی سرور اجرا کند و کنترل کامل سیستم را در دست بگیرد. باوجود هشدار جدی US-CERT و تأکید بر لزوم وصله زنی ظرف ۴۸ ساعت، تیم امنیت Equifax طی یک اسکن سطحی، این آسیب پذیری را پیدا نکرد، چون اسکنر را روی ریشه دایرکتوری اجرا کرده بودند درحالیکه فایلهای Struts در زیرشاخهای دیگر قرار داشت و اسکن بعدی روی ۹۵۸ آیپی عمومی هم هیچ نتیجهای دربرنداشت.

مهاجمان اگرچه احتمالاً از همان روزهای اول افشا از وجود این روزنه باخبر شدند، اما تا دو ماه بعد یعنی مه ۲۰۱۷ دست نگه داشتند و سپس با بهره برداری از همان نقطه کور، حدود ۳۰ وب شل را روی سرورها آپلود کردند تا دسترسی دائمی و پنهان برای خود ایجاد کنند و اینجاست که دومین اشتباه بزرگ نمایان شد؛ نبود هرگونه سیستم پایش یکپارچگی فایل ها باعث شد نصب ده ها فایل مشکوک ماه ها بی درنگ بماند و مهاجم بدون کوچکترین مزاحمتی به کندوکاو در شبکه و استخراج اطلاعات حساس بیش از ۱۴۷ میلیون نفر بپردازد. این پرونده به خوبی ثابت میکند که در امنیت سایبری، داشتن ابزارهای گران قیمت یا تدوین سیاست های سنگین کافی نیست، بلکه اجرای دقیق فرایندها، پیکربندی درست اسکن ها، و داشتن سیستم های مانیتورینگ پیوسته است که میتواند یک تیم را از پرتگاه سقوط نجات دهد و غفلت از هرکدام از این حلقه ها، کل زنجیره را به شکستی جبران ناپذیر تبدیل میکند.

بیشتر چیز هایی که امروز به اسم network programming میشناسیم، ریشه‌ شون برمیگرده به 4.2BSD جایی که برای اولین بار شبکه به عنوان یک مفهوم خیلی آشنا دیده شد. ایده این بود که اگه بتونی با فایل حرف بزنی، باید بتونی با شبکه هم دقیقاً به همون شکل حرف بزنی. همین نگاه ساده باعث شد read و write بشن هسته‌ ارتباطات شبکه ای در یونیکس.

همه‌ چیز از ()socket شروع میشه این فراخوانی در واقع هیچ ارتباطی رو برقرار نمیکنه، فقط از کرنل میخوای یه اندپوینت خام بهت بده. چیزی شبیه باز کردن یک فایل، با این تفاوت که هنوز نه آدرسی داره و نه مقصدی. فقط یه فایل دیسکریپتور تحویل میگیری که قراره بعدا معنای شبکه‌ای پیدا کنه.

بعد از اون باید به این اندپوینت هویت بدی. اینجاست که ساختار sockaddr_in میاد وسط وقتی میگی IPv4 هست، پورت 8081 رو میخوام و روی همه‌ اینترفیس‌ ها گوش بده، در واقع داری به کرنل میگی این فایل قراره نماینده‌ کدوم نقطه از شبکه باشه. با ()bind این هویت به سوکت چسبونده میشه. هنوز هیچ ارتباطی وجود نداره، فقط آدرس رزرو شده.

.تا اینجا سوکت فقط میدونه کیه، نه اینکه چه کاری باید بکنه. ()listen دقیقاً همین‌ جا معنی پیدا میکنه با این فراخوانی، سوکت از حالت عادی خارج میشه و وارد حالت گوش دادن میشه. یعنی کرنل شروع میکنه به گرفتن SYN ها، صف اتصال درست میکنه و آماده میشه برای اینکه کسی واقعاً وصل بشه. این لحظه‌ ایه که برنامه از «یه فایل معمولی» تبدیل میشه به «یه سرور»

وقتی کلاینتی وصل میشه، ()accept صدا زده میشه. نکته‌ خیلی مهم اینه که ()accept همون سوکت قبلی رو برنمیگردونه. یک file descriptor جدید ساخته میشه که نماینده‌ی دقیقاً همون اتصال مشخصه. سوکت اصلی همچنان فقط گوش میده. این جدا شدن listening socket از connected socket یکی از پایه‌ای ترین مفاهیم TCP server هاس و خیلی‌ ها دقیقاً همین‌ جا گیج میشن نمیدونن...

از این به بعد دیگه هیچ چیز خاصی وجود نداره. ارتباط برقرار شده و فقط با یک file descriptor در ارتباطی ()read میکنی دیتا میاد. ()write میکنی دیتا میره. نه تابع خاص شبکه، نه تفاوت مفهومی با فایل. همون چیزی که 4.2BSD کانسپتش رو از اول میخواست همینه

سمت کلاینت هم داستان کوتاه‌ تره ولی همون استراکچر رو داره. ()socket ساخته میشه، با ()connect به یک آدرس مشخص وصل میشه، و بعدش همه‌ چیز دوباره به read و write ختم میشه. ()connect در واقع فقط handshake TCP رو کامل میکنه و به اون file descriptor معنی اتصال میده همین.

جذابش رو ما تو لینوکس epoll رو داریم که حالا بماند برای بحث آینده. :)
⚝

تو شبکه مفاهیم شمالی – جنوبی و شرقی – غربی فقط جهت ترافیک نیستن در واقع دو طرز فکر کاملا متفاوت تو دیزاین زیرساخت رو نشون میدن ترافیک شمالی – جنوبی همون تصویریه که همه مون با اون آشنایم کاربر یا سیستم بیرونی که از اینترنت وارد میشه از چند لایه‌ امنیتی عبور میکنه و به سرویس میرسه این مسیر واضحه مرز داره نقطه‌ کنترل داره و به همین دلیل هم سال ها تمرکز اصلی امنیت و طراحی روی اون بوده/هستش ولی این فقط بخش کوچیکی از واقعیت شبکه‌ های امروزیه

تو معماری های مدرن اون چیزی که سیستم رو واقعا زنده نگه میداره ترافیک شرقی – غربیه ارتباطاتی که بی وقفه داخل کلاستر، بین سرویس ها، دیتابیس ها، کش ها و کامپوننت ها جریان داره این ترافیک معمولا دیده نمیشه، لاگ و متریک درستی ندارن و اغلب بر پایه‌ اعتماد ضمنی طراحی شده همین موضوع باعث میشه بیشترین خرابی ها، بیشترین latency های غیرمنتظره و سناریوهای امنیتی دقیقا از همین مسیر شکل بگیرن وقتی یه سرویس کند میشه وقتی retry ها زنجیره‌ ای از آب در میان یا وقتی یه کامپوننت کامپرومایز میشه مسیر تخریب در واقع از شرق به غربه

تفاوت اصلی اینجاس که شمالی – جنوبی درباره‌ محافظت از ورودیه اما شرقی – غربی درباره‌ کنترل رفتار داخلی سیستمه در اولی سوال اینه که چه کسی وارد میشه در دومی، اینه که هر سرویس دقیقا با کی؟ چرا؟ و چگونه؟ صحبت میکنه به همین دلیل مفاهیمی مثل zero trust، mtls، network policy و سرویس مش اهمیت پیدا میکنه اینا به عنوان پاسخ طبیعی به واقعیت ترافیک داخلییه

اگه شبکه رو فقط با نگاه شمالی – جنوبی طراحی کنیم شاید سیستم امن به نظر برسه ولی در عمل شکننده در میاد معماری به بلوغ رسیده جایی درست میشه که شرق – غرب به همون اندازه‌ ورودی اینترنت جدی گرفته بشه چون آینده‌ پایداری، امنیت و مقیاس‌ پذیری سیستم ها درون ارتباطات داخلی رقم میخوره

این نقشه یک دیاگرام تک‌خطی از سیستم توزیع برق صنعتی با برند زیمنس مربوط به یک کنسرن تولیدی روسیه است. ساختار کلی شامل چندین واحد مجزا به نام "Молновый комбинат" است که هر واحد دارای دو ورودی برق جداگانه (Ввод1 و Ввод2)، چهار مصرف‌کننده مجزا (Потребитель 01 تا 04) و چهار خط تولید (Продукция 01 تا 04) میباشد. همچنین بخش جداگانه‌ای برای تولید بخار و آب گرم (ТЭ/ЭВ в горючей воде и паре) با یک ورودی آماده‌به‌کار (Стоячее воды) در نظر گرفته شده است. از منظر امنیت سایبری سطح ICS، اولین آسیب‌پذیری قابل شناسایی عدم وجود مکانیزم سنکرون‌سازی بین دو ورودی است که در صورت افت ولتاژ یا تغییر فاز، منطق سوئیچ خودکار (ATS) ممکن است دچار نوسان شده و قطعی ناخواسته ایجاد کند. دومین ضعف ساختاری، وابستگی کامل کارگاه شماره ۲ به کارگاه شماره ۱ بدون ورودی مستقل است که این نقطه را به یک Single Point of Failure تبدیل میکند به طوری که هر گونه حمله یا خرابی در کارگاه ۱ مستقیماً کل کارگاه ۲ را از مدار خارج میسازد

سومین مسئله، عدم جداسازی فیزیکی شبکه بین بخش برق و بخش بخار است که هر دو از یک سوئیچ صنعتی مشترک تغذیه میشوند و این امکان را برای مهاجم فراهم میکند که از طریق نفوذ به شبکه بخار (که معمولاً از پروتکل Modbus/TCP استفاده میکند) به شبکه برق دسترسی پیدا کند. برای رفع این موارد، اقدامات عملی شامل تفکیک VLAN با ACL سخت‌افزاری بین ورودی‌ها و مصرف‌کننده‌ها، فعال‌سازی امضای دیجیتال برای فرامین نوشتن در حافظه PLCهای سری S7-1500 زیمنس، نصب ثبت‌کننده رویداد صنعتی از نوع SEL-2440 یا معادل آن برای پایش پیوسته فرکانس و ولتاژ، و تغییر توپولوژی از حالت دو ورودی موازی به حلقه افزونه با پروتکل PRP پیشنهاد میشود. همچنین در سطح نرم‌افزار، یک اسکریپت مانیتورینگ ساده با پایتون میتواند افت همزمان هر دو ورودی را تشخیص داده و هشدار قطعی قریب‌الوقوع را صادر کند که در محیط شبیه‌سازی با اعمال نویز تصادفی ±۵ ولت بر روی هر دو فیدر، آستانه هشدار روی ۱۹۰ ولت تنظیم میشود. این تحلیل مبتنی بر استاندارد ISA-99 (IEC 62443) و راهنمای NIST SP 800-82 است

در Kerberos، بعد از اینکه کاربر نام کاربری و رمز عبورش را وارد می‌کند، رمز عبور مستقیماً روی شبکه ارسال نمی‌شود. کلاینت از روی رمز عبور یک کلید رمزنگاری تولید می‌کند و درخواست AS-REQ را به KDC می‌فرستد. اگر احراز هویت موفق باشد، KDC در پاسخ AS-REP را همراه با Ticket Granting Ticket (TGT) ارسال می‌کند. این TGT با کلید حساب krbtgt رمز شده و فقط KDC قادر به خواندن و اعتبارسنجی آن است. داخل TGT اطلاعاتی مانند نام کاربر، SID، گروه‌های امنیتی، زمان اعتبار، Session Key و همچنین PAC (Privilege Attribute Certificate) قرار دارد که شامل اطلاعات دسترسی و مجوزهای کاربر است. پس از دریافت TGT، کاربر برای هر سرویس دیگر نیازی به ارسال مجدد رمز عبور ندارد و با ارسال TGS-REQ به KDC، یک Service Ticket مخصوص همان سرویس دریافت می‌کند. این مکانیزم علاوه بر پیاده‌سازی Single Sign-On (SSO)، امنیت را نیز افزایش می‌دهد؛ زیرا رمز عبور هرگز بین سرویس‌ها جابه‌جا نمی‌شود. همچنین به دلیل اینکه اعتبار TGT به حساب krbtgt وابسته است، محافظت از این حساب اهمیت بسیار بالایی دارد

و در صورت افشای کلید آن، امکان ایجاد Golden Ticket برای دور زدن فرآیند احراز هویت وجود خواهد داشت.

یکی از رایج‌ترین معماری‌های شبکه‌های صنعتی را بر اساس مدل Purdue نشان می‌دهد. در این مدل، تجهیزات و سیستم‌های کنترلی در چند لایه مجزا قرار می‌گیرند تا هم مدیریت شبکه ساده‌تر باشد و هم امنیت به شکل بهتری تأمین شود. در پایین‌ترین لایه (Level 0) خودِ فرآیند صنعتی قرار دارد؛ یعنی تجهیزاتی مثل ربات‌ها، خطوط تولید، مخازن و ماشین‌آلات. یک لایه بالاتر (Level 1) سنسورها، عملگرها، درایوها و ماژول‌های I/O قرار دارند که اطلاعات را از فرآیند جمع‌آوری کرده و فرمان‌های کنترلی را اجرا می‌کنند. در Level 2، PLCها، HMIها و کنترلرهای هر خط تولید قرار گرفته‌اند و وظیفه کنترل و مانیتورینگ هر بخش از کارخانه را بر عهده دارند. در بالاترین لایه این تصویر (Level 3) نیز سرورهای SCADA، Historian، ایستگاه‌های مهندسی و سرویس‌های پشتیبان کارخانه قرار دارند که مدیریت و نظارت بر کل سایت را انجام می‌دهند.

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