ICS Response: ইন্ডাস্ট্রিয়াল কন্ট্রোল সিস্টেমে সাইবার হামলার পর দ্রুত করণীয়!

প্রথমেই বুঝতে হবে ICS environment-এর core characteristic-গুলো IT environment থেকে কীভাবে আলাদা। IT-তে CIA Triad-এর priority order হলো Confidentiality, Integrity, Availability। কিন্তু OT-তে এটি উল্টে যায় — Availability সবার আগে, তারপর Integrity, এবং সবশেষে Confidentiality।

কারণটা স্পষ্ট। একটি database server কয়েক মিনিট অফলাইন থাকলে business impact হবে, কিন্তু একটি power plant-এর control system দশ সেকেন্ড অফলাইন থাকলে regional blackout বা equipment destruction ঘটতে পারে। তাই ICS incident response-এ "system shutdown" সবসময় সঠিক সিদ্ধান্ত নয়।

ICS environment-এ বহু legacy device রয়েছে যেগুলো ২০-৩০ বছর পুরোনো। এগুলোর built-in security control প্রায় নেই, এবং অনেক সময় simple network probe-ই এগুলোকে crash করিয়ে দিতে পারে। এই সংবেদনশীলতা incident response procedure-কে অত্যন্ত সতর্কতার সাথে design করতে বাধ্য করে।

Purdue Reference Model অনুসারে ICS network কয়েকটি level-এ বিভক্ত — Level 0 (physical process), Level 1 (basic control), Level 2 (area supervision), Level 3 (operations management), Level 3.5 (DMZ), এবং Level 4/5 (enterprise IT)। প্রতিটি level-এর jeopardy এবং response strategy ভিন্ন।

Traditional IT incident response-এ প্রথম পদক্ষেপ সাধারণত affected system-কে isolate করা — network থেকে disconnect করে দেওয়া। কিন্তু একটি live PLC বা DCS controller disconnect করলে production line বন্ধ হতে পারে, রাসায়নিক প্রক্রিয়া অস্থিতিশীল হয়ে বিস্ফোরণ ঘটাতে পারে, বা সবচেয়ে খারাপ ক্ষেত্রে human life-এ ঝুঁকি তৈরি হতে পারে।

Forensic data collection-এও পার্থক্য আছে। IT system-এ আমরা সাধারণত memory dump, disk image, এবং network capture নেই। কিন্তু একটি active PLC-এর memory dump নেওয়া তার operation-কে disrupt করতে পারে। অনেক industrial protocol-এ debug feature নেই যা forensic data সংগ্রহ সহজ করবে।

Communication channel-ও আলাদা। ICS environment-এ Modbus, DNP3, OPC, Profinet, এবং অন্যান্য specialized protocol ব্যবহৃত হয় যেগুলোর জন্য specialized monitoring tool প্রয়োজন। Wireshark-এর সাধারণ knowledge এখানে যথেষ্ট নয়।

Response team-এর composition-ও ভিন্ন। IT incident response-এ security analyst, sysadmin, এবং network engineer যথেষ্ট। কিন্তু ICS-এ এই team-এর সাথে process engineer, control system engineer, এবং safety officer-ও থাকতে হবে। সিদ্ধান্ত নেওয়ার সময় প্রতিটি action-এর process impact বিবেচনা করা অপরিহার্য।

Stuxnet (২০১০) ICS attack-এর জগতে একটি যুগান্তকারী মাইলফলক। ইরানের Natanz nuclear facility-তে Siemens PLC-কে টার্গেট করে centrifuge-গুলোকে ধ্বংস করেছিল। এই attack প্রমাণ করেছিল যে cyber weapon physical destruction-এর সক্ষমতা রাখে। তাদের response-এর সবচেয়ে বড় চ্যালেঞ্জ ছিল ম্যালওয়্যারটি detect করতে অনেক সময় লেগেছিল — আক্রমণ শুরু হওয়ার অনেক পরে।

Industroyer/CrashOverride (২০১৬) ইউক্রেনের power grid-এ ব্যবহৃত হয়েছিল এবং কয়েক ঘণ্টার জন্য বিদ্যুৎ বন্ধ করেছিল। এই ম্যালওয়্যার specifically IEC 61850 এবং IEC 60870-5-101/104 protocol-এ designed ছিল। Response team-কে ম্যানুয়ালি substation operate করতে হয়েছিল digital control restore করার সময়।

TRISI/TRITON (২০১৭) সৌদি আরবের একটি petrochemical plant-এর Triconex Safety Instrumented System-কে attack করেছিল। এই attack বিশেষভাবে ভয়াবহ ছিল কারণ এটি safety system-কে disable করার চেষ্টা করেছিল, যা accidents-এর সম্ভাবনা বহুগুণ বাড়িয়ে দেয়। Response-এ প্রায় সম্পূর্ণ plant shutdown করতে হয়েছিল।

Colonial Pipeline ransomware (২০২১) যদিও primarily IT system-কে affect করেছিল, কিন্তু precautionary measure হিসেবে OT operation বন্ধ করতে হয়েছিল। এর ফলে পূর্ব মার্কিন যুক্তরাষ্ট্রে fuel shortage তৈরি হয়েছিল।

এই প্রতিটি ঘটনা থেকে গুরুত্বপূর্ণ শিক্ষা হলো — ICS incident response-এ technical action-এর পাশাপাশি operational continuity এবং human safety সর্বোচ্চ priority।

NIST SP 800-61 IT incident response-এর জন্য standard framework, কিন্তু ICS-এর জন্য NIST SP 800-82 আরো প্রাসঙ্গিক। এর Lifecycle চারটি প্রধান ধাপে বিভক্ত।

Preparation ধাপ সবচেয়ে গুরুত্বপূর্ণ এবং সবচেয়ে underrated। এই ধাপে comprehensive asset inventory তৈরি করা, network architecture document করা, normal baseline establish করা, এবং playbook প্রস্তুত করা অন্তর্ভুক্ত। OT environment-এ অনেক সময় basic inventory-ও থাকে না — কোন PLC কোথায় আছে, কী firmware-এ চলছে, কার সাথে communicate করে — এই তথ্য incident-এর সময় না জানলে response সম্ভব নয়।

Detection and Analysis ধাপে anomaly identify করা এবং তার scope বোঝা হয়। OT-এ traditional SIEM-এর পাশাপাশি specialized OT-aware solution যেমন Claroty, Dragos, এবং Nozomi Networks ব্যবহার করতে হয়। এই tools industrial protocol decode করতে পারে এবং process-level anomaly শনাক্ত করতে পারে।

Containment, Eradication, and Recovery — এই ধাপে বিশেষ সতর্কতা প্রয়োজন। Containment strategy-গুলো process-aware হতে হবে। কখনো segmentation-ই যথেষ্ট, কখনো manual operation mode-এ স্যুইচ করতে হয়। Eradication-এর সময় malware remove করার পাশাপাশি root cause address করতে হয়। Recovery-তে শুধু system restore নয়, complete process validation দরকার যে সবকিছু safely operate করছে।

Post-Incident Activity-তে lessons learned document করা, playbook update করা, এবং stakeholder-দের সাথে communication অন্তর্ভুক্ত। OT incident-এ regulatory reporting (যেমন NERC-CIP, CISA reporting) একটি বড় অংশ।

একটি ICS cyber incident-এর প্রথম 24 ঘণ্টা সবচেয়ে গুরুত্বপূর্ণ। প্রথম পদক্ষেপ হলো incident response team activate করা, যেখানে IT security, OT engineering, plant operation, safety, legal, এবং communication লোকজন থাকবেন।

দ্বিতীয়ত, একটি initial assessment করুন। কোন system affected, কী indicator দেখা যাচ্ছে, এবং process safety-তে immediate risk আছে কিনা। এই assessment-এর ভিত্তিতে initial containment decision নেওয়া হবে।

তৃতীয়ত, "Do No Harm" নীতি মেনে চলুন। অনিশ্চিত হলে কোনো aggressive action না নেওয়াই ভালো। PLC reboot, network disconnect, বা configuration change — সবই potentially process disruption ঘটাতে পারে।

চতুর্থত, evidence preservation শুরু করুন। Available log সংগ্রহ করুন (firewall, IDS, SIEM, jump server), network traffic capture চালু রাখুন, এবং affected workstation থেকে memory dump নিন (যেগুলো operationally critical নয়)।

পঞ্চমত, communication channel সুরক্ষিত রাখুন। যদি email বা corporate chat compromised হতে পারে, তবে out-of-band channel ব্যবহার করুন। Plant phone, signal app, বা physical meeting — যেটি practical।

ষষ্ঠত, executive এবং regulator-দের appropriate update দিন। অনেক jurisdiction-এ critical infrastructure incident-এ specific reporting timeline থাকে — যেমন CISA-এর CIRCIA এর অধীনে 72 hour-এ report করতে হবে।

OT forensics-এর জন্য specialized approach দরকার। Network traffic capture সবচেয়ে valuable evidence কারণ এটি non-intrusive এবং industrial protocol-এর details দেখায়। SPAN port বা TAP-এর মাধ্যমে passive capture চালু রাখুন।

PLC এবং HMI-এর জন্য vendor-specific tool দরকার। Siemens TIA Portal, Rockwell Studio 5000, Schneider Unity Pro — এসব tool-এর মাধ্যমে PLC program এবং configuration extract করা যায়। কিন্তু এই কাজ trained engineer-কে দিয়ে করানো উচিত যাতে accidentally কোনো parameter পরিবর্তন না হয়।

Engineering workstation-এ সাধারণত backup file, project file, এবং communication log থাকে যা attacker-এর activity reveal করতে পারে। এই workstation-গুলো high-value forensic target।

Historian database শুধু process data নয়, অনেক system এর সাথে operator action এবং alarm log-ও রাখে। এই data কে attacker manipulate করেছে কিনা যাচাই করা অপরিহার্য।

Modern OT environment-এ packet capture একটি common challenge — কারণ industrial protocol সাধারণত encrypted নয়, কিন্তু high-speed environment-এ পুরো traffic capture করা impractical। তাই strategic point-এ continuous capture চালু রাখা best practice।

Recovery-এর প্রথম step হলো confirmed clean backup থেকে restoration। কিন্তু OT-তে "clean backup" নিশ্চিত করা কঠিন কারণ অনেক system-এ regular backup নেই, এবং historical backup-ও compromised থাকতে পারে।

Restoration-এর process step-by-step হওয়া উচিত। প্রথমে DMZ এবং historian, তারপর HMI, তারপর engineering workstation, এবং সবশেষে controller level। প্রতিটি step-এর পর verification এবং monitoring।

Process validation extremely critical। সব system technically restored হলেও process safely operate করছে কিনা সেটা control engineer-দের verify করতে হবে। কখনো কখনো initial run কে reduced capacity-তে করা হয় যাতে কোনো issue থাকলে immediately detect হয়।

PLC এবং safety system-এর firmware re-flash করা সর্বোত্তম, কিন্তু এটি plant shutdown প্রয়োজন করে। যেখানে possible, golden image থেকে complete restore নিন।

Cybersecurity strengthening-কে recovery-এর integral অংশ হিসেবে দেখুন। শুধু পূর্বের state-এ ফিরে যাওয়া যথেষ্ট নয় — যে gap-এর কারণে breach হয়েছিল, সেটা address করতে হবে। Network segmentation strengthening, access control improvement, এবং monitoring enhancement।

Preparedness-ই সবচেয়ে কার্যকর response strategy। প্রথমত, comprehensive asset inventory maintain করুন। প্রতিটি OT device-এর IP, MAC, firmware version, vendor, এবং business owner document করুন।

দ্বিতীয়ত, network segmentation কঠোরভাবে enforce করুন। IT এবং OT-এর মাঝে DMZ থাকতে হবে, এবং OT-এর ভেতরেও Purdue level অনুসারে segmentation থাকা উচিত।

তৃতীয়ত, regular tabletop exercise চালান। বিভিন্ন scenario-এর জন্য team-এর response practice করান। Real incident-এর সময় communication breakdown এড়ানোর এটাই সর্বোত্তম উপায়।

চতুর্থত, threat intelligence subscribe করুন। ICS-CERT, Dragos, Mandiant-এর threat intel আপনার threat landscape সম্পর্কে নিয়মিত আপডেট দেবে।

পঞ্চমত, vendor relationship build করুন। সিদ্ধান্তমূলক সময়ে Siemens, Schneider, Rockwell, GE-এর মতো vendor-এর সাহায্য অমূল্য। তাদের emergency support contract maintain করুন।

ষষ্ঠত, backup এবং recovery procedure regularly test করুন। untested backup মূলত কোনো backup-ই নয়।