واقعیت دیگه اینه که استخدام فقط به دانش فنی محدود نمیشه شرکت‌ها معمولاً دنبال کسی هستن که بتونن مستندسازی کنن گزارش بنویسن و توی شیفت‌های کاری مسئولیت‌پذیر باشن ، با تیم ارتباط مؤثر داشته باشن و هنگام بروز حادثه آرام و منطقی تصمیم بگیرن این ویژگی‌ها گاهی به اندازه دانش فنی در موفقیت یک کارشناس SOC اهمیت دارن

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

تحلیل لایه‌ای بلوغ مدیریت ریسک سایبری بر مبنای چارچوب NIST CSF
در فرآیند پیاده‌سازی و ارزیابی سیستم‌های مدیریت امنیت اطلاعات، یکی از معیارهای کلیدی، سنجش میزان نهادینه‌شدگی فرآیندهای مدیریت ریسک در ساختار سازمان است. چارچوب مشهور NIST Cybersecurity Framework (CSF) این بلوغ را در قالب چهار سطح عملیاتی (Implementation Tiers) تعریف می‌کند که در ادامه به تفکیک به آن می‌پردازیم:

سطح ۱: جزئی‌محور یا واکنشی (Partial)
در این سطح، مدیریت ریسک سایبری فاقد هرگونه ساختار از پیش‌تعریف‌شده است. اقدامات امنیتی عمدتاً به‌صورت موردی، آنی و در واکنش به وقایع گذشته صورت می‌گیرد. آگاهی از ریسک در لایه‌های تاکتیکی (فنی) محدود شده و هیچ‌گونه هماهنگی کل‌نگر در سطح هیئت‌مدیره یا مدیریت ارشد برای تخصیص منابع مبتنی بر ریسک وجود ندارد. در این وضعیت، مستندات پراکنده و فاقد انسجام فرآیندی هستند.

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

سطح ۳: تکرارپذیر و نظام‌مند (Repeatable)
در این سطح حیاتی، مدیریت ریسک به یک سیاست رسمی و مصوب مبدل شده است. رویه‌ها مستند، مکتوب و برای تمامی ذی‌نفعان ابلاغ می‌شود. سازمان موفق به استقرار یک رویکرد واحد (Organization-wide) برای پایش و ارزیابی ریسک شده است. در این مرحله، فرآیندها قابلیت تکرارپذیری دارند و نتایج ارزیابی‌ها در دوره‌های زمانی مشخص (مثلاً فصلی) با همان استاندارد کیفی بازتولید می‌شوند.

سطح ۴: پویا و تطبیقی (Adaptive)
این بالاترین سطح بلوغ مدیریت ریسک محسوب می‌شود. سازمان نه‌تنها از رویه‌های ایستا پیروی می‌کند، بلکه با استفاده از شاخص‌های پیش‌بینی‌کننده (Indicators) و بازخورد حوادث گذشته (Lessons Learned)، به‌طور مستمر کنترل‌های خود را به‌روزرسانی می‌کند. در اینجا، سیاست‌ها و رویه‌ها نه بر اساس فرضیات اولیه، بلکه بر مبنای داده‌های عملیاتی و تهدیدات روز طراحی می‌شوند و سازمان قابلیت انطباق پذیری با سناریوهای تهدید جدید را به‌صورت خودکار و پویا دارد.

توجه داشته باشید که این سطوح یک نردبان صرفاً ترتیبی نیستند؛ بلکه سازمان‌ها بسته به ماهیت صنعت، حجم دارایی‌های اطلاعاتی و بودجه امنیتی، ممکن است ترکیبی از این سطوح را در بخش‌های مختلف خود تجربه کنند. هدف نهایی، حرکت به سمت "مدیریت ریسک مبتنی بر تصمیم‌گیری داده‌محور" است که در Tier 4 به اوج می‌رسد

نکته مهم در طراحی دامنه های Active Directory برای محیطهای SCADA و اتوماسیون صنعتی (ICS)

این روزها خیلی از همکاران وقتی صحبت از اکتیو دایرکتوری در OT میشه، یهو واکنش نشون میدن که مگه میشه؟! ولی واقعیت اینه که اصل ماجرا خود حضور AD نیست، بلکه چیدمانشه.

طبق تجربه و معماری استاندارد (لایه های پرپل)، دو تا مرز حیاتی داریم که باید رعایت بشن: یکی مرز بین شبکه بیزینس و شبکه صنعتی، و دیگری مرز بین لایه سوپروایزری و لایه کنترلرها.

قانون طلایی اینه که هیچوقت از دامنه سازمانی (همون ADای که کل شرکت روش کار میکنه) برای محیط عملیاتی استفاده نکنیم. به جاش، یه دامنه مجزا و کاملاً مستقل برای بخش OT تعریف میکنیم که حتی یه ذره رابطه اعتماد (Trust) با دامنه اصلی نداشته باشه.

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

و یه نکته فنی مهم: در مرز اجرایی بین لایه ۳ (سوپروایزری) و لایه ۱ و ۲ (کنترلرها)، دیگه خبری از ترافیک Kerberos یا NTLM نیست. اینجا همه چی با پروتکل‌های بومی خود اتوماسیون مثل Modbus یا DNP3 پیش میره و AD دیگه نقشی توی ارتباط با تجهیزات حیاتی نداره.

در نهایت اگر هم قرار باشه اطلاعاتی بین این دو دامنه (IT و OT) رد و بدل بشه، از راههای غیرمستقیم مثل ارسال لاگ یا RADIUS هست، نه اینکه دایرکتوری ها رو به هم وصل کنیم.

یه داستان واقعی از دل نیروگاهها: وقتی کرمی به نام کانفیکر (Conficker) صنعت برق رو لرزوند

شاید فکر کنید بدافزارها فقط مخصوص کامپیوترهای شخصی یا شبکههای اداری هستن، ولی بیایید برگردیم به سال ۲۰۰۸. اون موقع خیلی از شبکههای حیاتی، از جمله سیستمهای کنترلی صنعتی (ICS) توی نیروگاههای برق آمریکای شمالی، با یه مهمان ناخوانده به اسم «کرم کانفیکر» آشنا شدن.

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

چرا حذفش سخت بود؟
سیستمهای ICS برخلاف کامپیوترهای اداری، از سیستمعاملها، نرمافزارها و پروتکلهای خاص خودشون استفاده میکنن که اغلب بهروزرسانی امنیتی منظم ندارن. از طرفی، خاموش کردن یا راهاندازی مجدد این سیستمها کار سادهای نیست؛ چون مستقیماً روی فرایند تولید انرژی تأثیر میذاره

. به همین دلیل، پاکسازی کامل کانفیکر از این شبکه ها ماه ها طول کشید و خیلی از سازمان ها مجبور شدن بخش هایی از شبکه رو برای روزها یا هفته ها از مدار خارج کنن

اما مهمترین پیامد این ماجرا چی بود؟
این اتفاق عملاً تبدیل به نخستین زنگ هشدار جدی برای جداسازی شبکه های IT از OT (فناوری عملیاتی) شد. تا قبل از اون، خیلی ها فکر میکردن اتصال این دو شبکه به هم با رعایت چند فیلتر ساده کافیه، ولی کانفیکر نشون داد که یه بدافزار معمولی هم میتونه از دروازههای ساده عبور کنه و خودش رو به قلب زیرساختهای حیاتی برسونه.

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

💎 کتاب +CompTIA PenTest

📌 سال انتشار: 2027
📌 تعداد صفحات: 594

@iranopensource🌎

یه نقشهٔ کلی از الگوریتمهای رمزنگاری که توی هر سیستم امنیتی باهاشون سروکار داریم. از بخش Encryption شروع میکنیم که به دو شاخهٔ متقارن و نامتقارن تقسیم میشه. توی روش متقارن، رمزگذاری و رمزگشایی با یه کلید واحد انجام میشه، که مهمترین چالشش انتقال امن همون کلیده. اینجا الگوریتمهای جریانی مثل RC4، SEAL و WAKE رو داریم که داده رو بایت به بایت پردازش میکنن و برای ارتباطات لحظهای مناسب هستن، هرچند RC4 امروزه دیگه ضعیفه. در مقابل، الگوریتمهای بلوکی مثل DES، ۳DES، RC2، RC5، IDEA، Blowfish و در نهایت AES قرار دارن که داده رو به بلوکهای ثابت تقسیم و رمز میکنن، و AES امروزه به عنوان استاندارد طلایی با کلیدهای ۱۲۸، ۱۹۲ و ۲۵۶ بیت شناخته میشه و بقیه به مرور کنار گذاشته شدن. در سمت رمزنگاری نامتقارن، با دو کلید عمومی و خصوصی سروکار داریم که پایهش ریاضیات پیچیدهای مثل فاکتورگیری و لگاریتم گسستهست. اینجا Diffie-Hellman رو داریم که فقط برای تبادل کلید استفاده میشه، El Gamal که هم برای رمزنگاری و هم امضا کاربرد داره

، RSA که معروفترین الگوریتم نامتقارنه و بر پایهٔ فاکتورگیری اعداد بزرگ طراحی شده، و ECC که با کلید بسیار کوتاهتر امنیتی معادل RSA رو ارائه میده و برای دستگاههای محدود عالیه. بریم سراغ Hashing که یه فرآیند کاملاً یکطرفهست و از روی خروجیش نمیشه به دادهٔ اصلی رسید. اینجا MD2 و MD5 و SHA-0 و SHA-1 همگی قدیمی و شکسته شدن، در حالی که خانوادهٔ SHA-2 و SHA-3 استانداردهای فعلی و امن محسوب میشن و توی همهٔ پروتکلها استفاده میشن. MAC هم که ترکیبی از هش و کلید متقارنه، برای تأمین همزمان یکپارچگی و احراز اصالت پیام به کار میره که معروفترینش HMAC هست که روی SHA-2 یا SHA-3 سوار میشه. و در نهایت Digital Signatures که برای انکارناپذیری طراحی شدن و فرستنده نتونه پیام رو انکار کنه، با الگوریتمهایی مثل RSA Signature، DSA و ECDSA پیادهسازی میشن. در عمل، امروزه برای رمزنگاری دادهها از AES در حالت GCM استفاده میکنیم، برای تبادل کلید از Diffie-Hellman یا ECDH، برای امضا از ECDSA یا RSA-PSS، و برای یکپارچگی و احراز هویت از HMAC با SHA-256 یا SHA-3، و الگوریتمهای قدیمی مثل MD5، DES، RC4 و SHA-1 دیگه جایی توی سیستمهای امن امروزی ندارن و باید حتماً به سمت AES، SHA-2/3 و ECC مهاجرت کرد، ضمناً باید همیشه این رو در نظر داشت که خود الگوریتم به تنهایی کافی نیست و مدیریت کلید و پیادهسازی صحیح همونقدر اهمیت دارن.

با یک ارتقای ساده RAM، عملکرد سرورت چند برابر بهتر میشه

ارتقای RAM فقط اضافه کردن چند ماژول حافظه نیست؛ اگر اصولش رعایت نشه ممکنه با خطاهای Performance ناسازگاری RAM یا حتی Boot نشدن سرور مواجه بشید.

توی این ویدیو مراحل و نکات مهم ارتقای RAM روی سرورهای HP رو به صورت خلاصه نشون دادم .


@ModernLan

خیلی از بچه‌های اتوماسیون وقتی با Modbus کار می‌کنند، گاهی فکر می‌کنند این دو پروتکل با هم فرق اساسی دارند، اما در عمل، تفاوت‌شان به جای ساختار دستور، به نحوه بسته‌بندی و انتقال برمی‌گرده. بگذارید یک مثال عملی بزنم تا قضیه کامل دستتان بیاید. فرض کنید می‌خواهیم از یک PLC دو تا رجیستر هولدینگ با آدرس‌های ۷ و ۸ را بخوانیم، دستوری که در هر دو پروتکل کاملاً یکسان است و به شکل ۰۱ ۰۳ ۰۰۰۷ ۰۰۰۲ نوشته می‌شود، که این یعنی آدرس دستگاه ۱، کد دستور ۳ برای خواندن رجیسترهای هولدینگ، شروع از آدرس ۷ و تعداد ۲ رجیستر. این چهار بخش، چیزی است که به آن PDU یا واحد داده پروتکل می‌گوییم و هسته اصلی درخواست ما را تشکیل می‌دهد. حالا تفاوت از اینجا شروع می‌شود که این PDU را چطور به مقصد می‌فرستیم. در Modbus RTU که معمولاً روی خطوط سریال مثل RS485 کار می‌کند، به این PDU، اول یک آدرس ایستگاه اضافه می‌شود و در انتها هم دو بایت CRC برای تشخیص خطا، و تمام، بسته آماده ارسال از پورت سریال است،

اما در Modbus TCP ماجرا کاملاً فرق دارد، چون داده قرار است از شبکه Ethernet و با پروتکل TCP/IP عبور کند، به جای CRC، یک هدر ۶ بایتی به اسم MBAP به ابتدای PDU اضافه می‌شود که شامل Transaction ID است که مثلاً اینجا عدد ۳۷۵۲ را برای آن در نظر گرفته‌اند و کارش این است که در ارتباطات همزمان، مشخص کند هر پاسخ مربوط به کدام درخواست است، بعد Protocol ID که برای Modbus همیشه صفر است، سپس Length که تعداد بایت‌های باقی‌مانده از پیام را نشان می‌دهد و اینجا برابر با ۰۰۰۶ است، و در نهایت Unit ID که همان آدرس دستگاه یعنی ۰۱ است و در صورت عبور از گیت‌های سریال به کار می‌آید. حالا این بسته کامل که در تصویر به شکل ۳۷۵۲ ۰۰۰۰ ۰۰۰۶ ۰۱ ۰۳ ۰۰۰۷ ۰۰۰۲ دیده می‌شود، همان ADU یا واحد داده کاربردی در Modbus TCP محسوب می‌شود، اما کار به اینجا ختم نمی‌شود، چون این بسته باید توسط سیستمعامل، لایه به لایه آماده ارسال شود تا بتواند از شبکه عبور کند، اول هدر TCP به آن اضافه می‌شود تا ارتباط قابل اطمینانی بین دو طرف برقرار شود، بعد نوبت به هدر IP می‌رسد که آدرس مبدأ و مقصد را مشخص می‌کند، و در نهایت هدر Ethernet اضافه می‌شود تا بسته به یک فریم کامل تبدیل شود و روی کابل فیزیکی ارسال گردد، این روند لایه‌بندی دقیقاً در قسمت پایین تصویر به خوبی نشان داده شده، جایی که می‌بینید چطور از آن PDU ساده، کمکم هدرها به آن اضافه می‌شوند و در نهایت یک فریم کامل Ethernet تحویل لایه فیزیکی می‌شود، اما یک نکته خیلی مهم دیگر هم در این مقایسه وجود دارد که خیلی از تازه‌کارها از آن غافل می‌شوند، بحث ارسال همزمان یا Parallel Messaging است، در Modbus RTU به خاطر ماهیت نیمه‌دوطرفه و ترتیبی خطوط سریال، شما مجبور هستید درخواست‌ها را یکی پس از دیگری بفرستید و تا پاسخ نیاید، درخواست جدیدی نمی‌توانید ارسال کنید، اما در Modbus TCP به لطف وجود Transaction ID، می‌توانید چندین درخواست را پشت سر هم و بدون منتظر ماندن برای پاسخ هر یک، به شبکه بفرستید و بعداً با استفاده از همان Transaction ID، پاسخ هر کدام را به درخواست مربوطه نسبت دهید، این قابلیت باعث می‌شود سرعت و کارایی شبکه در سیستم‌های بزرگ با تعداد گره‌های بالا، به شکل محسوسی بهتر شود، و در نهایت، چیزی که این تصویر به زیبایی نشان می‌دهد این است که یک دستور ساده Modbus، در دو بستر متفاوت سریال و Ethernet، مسیرهای کاملاً متفاوتی را طی می‌کند، بدون اینکه کوچکترین تغییری در محتوای اصلی دستور ایجاد شود، و به همین دلیل است که ما مهندسین اتوماسیون می‌توانیم به راحتی پروتکل‌ها را بین این دو بستر جابجا کنیم و از هر دو در کنار هم استفاده کنیم، بدون اینکه نگران تغییر منطق برنامه یا ساختار داده‌هایمان باشیم، و این دقیقاً یکی از نقاط قوت استاندارد Modbus به حساب می‌آید.

فرق حمله به پسوردهای Plaintext با هش‌شده چیه؟

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

۱. حالت اول: حملات به پسوردهای Clear-Text (متن باز)
اینجا سیستم (یا مهاجم) مستقیماً به لیست پسوردهای ذخیره‌شده روی هارد یا دیتابیس دسترسی داره و این پسوردها کلاً بدون هیچ تغییری ذخیره شدن. مهاجم با خوندن فایل، مستقیم به رشته‌های پسورد می‌رسه. این یعنی Game Over کامل. دیگه نیازی به حدس زدن یا کرک کردن نیست؛ چون خود پسورد رو داره. این روش در سیستم‌های مدرن تقریباً منسوخ شده، ولی متأسفانه هنوز تو بعضی لاگ‌ها یا کانفیگ‌های اشتباهی دیده میشه.

۲. حالت دوم: حملات به پسوردهای Hashed (هش‌شده)
اینجا داستان فنی‌تر میشه. فرض کن مهاجم به دیتابیس دسترسی پیدا کرده، اما به‌جای پسورد، با یه رشته ثابت‌طول (مثلاً ۶۴ کاراکتری برای SHA-256) مواجهه که از الگوریتم‌های یک‌طرفه (همان Hashing algorithm که توی دیاگرام هست) تولید شده. اینجا مهاجم سه راه بیشتر نداره:

الف) حمله دیکشنری (Dictionary Attack):
مهاجم یه لیست بزرگ از کلمات رایج، پسوردهای لو رفته یا ترکیب‌های محتمل رو برمیداره، هر کدوم رو با همون الگوریتم هش (مثلاً MD5 یا SHA-1 یا بهترش bcrypt) هش می‌کنه و بعد خروجی رو با هش‌های داخل دیتابیس مقایسه می‌کنه. اگر تطابق پیدا شد، یعنی پسورد اصلی رو پیدا کرده.

ب) حمله Brute-Force (جست و جوی جامع ):
اینجا مهاجم به‌جای لیست کلمات، همه ترکیبات ممکن با طول مشخص (مثلاً از ۱ تا ۸ کاراکتر شامل حروف، اعداد و سمبل‌ها) رو تولید میکنه، هش‌شون رو محاسبه و با دیتابیس مقایسه میکنه. این روش از نظر محاسباتی سنگین‌تره، ولی هیچ‌وقت «شکست نمی‌خوره»؛ فقط زمان می‌بره

نکته حیاتی که توی دیاگرام مشخصه:
توی حمله به هش‌ها، مهاجم به خود پسورد دسترسی مستقیم نداره؛ بلکه با «تطابق دادن» (همون MATCHES که توی شکل هست) بین هش حاصل از حدس‌ها و هش‌های ذخیره‌شده، سعی میکنه پسورد رو پیدا کنه. این یعنی سرعت و سختی حمله کاملاً به الگوریتم هش بستگی داره.

اگر الگوریتم سریع باشه مثل MD5 یا SHA-1، مهاجم می‌تونه میلیون‌ها حدس در ثانیه بزنه (با GPU یا ASIC). اما اگر الگوریتم کند و مقاوم باشه مثل bcrypt با فاکتور هزینه (Cost Factor) بالا، یا Argon2 (برنده مسابقه هش پسورد)، هر حدس چندین میلی‌ثانیه یا حتی چند دهم ثانیه زمان می‌بره که عملاً حمله رو غیرعملی میکنه

🛡️ نگاهی به یک برد الکترونیکی در قلب تجهیزات امنیتی صنعتی
در این تصویر یک برد الکترونیکی رو می‌بینیم که از بخش‌های مختلفی مثل مدار تغذیه، قطعات پردازشی، ماژول‌های ارتباطی، رله‌ها و سیستم‌های حفاظتی تشکیل شده.
بخش تغذیه با استفاده از ترانس، سلف‌ها و خازن‌ها وظیفه تأمین برق پایدار برای قسمت‌های مختلف مدار رو داره؛ چون در سیستم‌های صنعتی حتی یک نوسان کوچک برق می‌تونه باعث اختلال در عملکرد تجهیزات کنترلی بشه.
قسمت پردازشی این برد وظیفه دریافت و پردازش اطلاعات،
اجرای دستورات و مدیریت ارتباطات رو بر عهده داره. در تجهیزات امنیتی صنعتی، همین بخش می‌تونه برای بررسی داده‌ها، ثبت اتفاقات و کنترل ارتباط بین تجهیزات مختلف استفاده بشه.
وجود ماژول‌های ارتباطی و مسیرهای جداگانه روی برد هم نشون می‌ده که این نوع طراحی برای ارتباط با شبکه‌ها و تجهیزات صنعتی مثل PLC، RTU و سیستم‌های SCADA ساخته می‌شه.
در دنیای امنیت صنعتی، محافظت فقط با نرم‌افزار انجام نمی‌شه؛ سخت‌افزار هم یکی از مهم‌ترین لایه‌های دفاعی برای جلوگیری از اختلال، دسترسی غیرمجاز و آسیب به زیرساخت‌های حیاتی محسوب می‌شه.
⚙️ پشت هر برد صنعتی، ترکیبی از مهندسی برق، کنترل و امنیت سایبری قرار گرفته است

#امنیت_صنعتی #ICS #SCADA #OTSecurity #PLC #CyberSecurity #IndustrialAutomation@pythonwithmedev