Zscaler Agentic SOC user isolate করতে পারে—মানুষের approval কোথায়?
Zscaler ৯ সেপ্টেম্বর ২০২৬-এ Agentic SOC ঘোষণা করে জানিয়েছে, সেবাটি বিশ্বজুড়ে উপলভ্য। Zscaler-এর আনুষ্ঠানিক ঘোষণায় আক্রান্ত ব্যবহারকারীকে বিচ্ছিন্ন করা, command-and-control যোগাযোগ বন্ধ করা এবং lateral movement রোধ করার মতো native inline containment-এর সক্ষমতা বর্ণনা করা হয়েছে।
একই তারিখে প্রকাশিত Security Today-এর প্রতিবেদনে triage, root-cause investigation, verdict ও response workflow শুরুর ক্ষমতার পাশাপাশি ওই containment action-গুলোও উল্লেখ করা হয়েছে। সরাসরি উত্তর হলো: Agentic SOC user isolation কার্যকর করতে পারে, কিন্তু প্রকাশিত তথ্য সব গ্রাহকের জন্য একটিমাত্র approval threshold নির্ধারণ করে না; স্বয়ংক্রিয় action-এর সীমা, অনুমোদনকারী ও rollback নীতি সংশ্লিষ্ট SOC-কেই স্থির করতে হবে।
Workflow-এর চার ধাপে ঝুঁকি এক নয়
Agentic SOC-এর কাজকে triage, investigation, verdict ও containment—চারটি সিদ্ধান্তসীমায় ভাগ করলে মানুষের হস্তক্ষেপ কোথায় দরকার, তা স্পষ্ট হয়। প্রথম তিন ধাপে alert সাজানো, প্রমাণ সমৃদ্ধ করা এবং সিদ্ধান্তের ভিত্তি তৈরি হয়; containment-এ ব্যবহারকারীর access বা network control বাস্তবে বদলে যায়। তাই একই confidence score বা automation rule দিয়ে চার ধাপ পরিচালনা করা সমান ঝুঁকির নয়।
Triage-এ সম্পর্কিত alert একত্র করা, identity, endpoint, cloud ও network signal মিলিয়ে অগ্রাধিকার দেওয়া যেতে পারে। উৎপাদন ব্যবস্থার control না বদলালে এর blast radius তুলনামূলক কম। তবু কোন alert বাদ পড়েছে, কোন grouping rule ও model version ব্যবহৃত হয়েছে এবং বিপরীত প্রমাণ ছিল কি না—এসব audit log-এ রাখা দরকার।
Investigation-এ timeline ও attack path তৈরি, asset criticality যোগ করা এবং decoy বা threat-intelligence signal মিলিয়ে দেখা স্বয়ংক্রিয় হতে পারে। এই পর্যায়ে agent-এর permission read-only রাখা এবং data source ও tenant boundary আগে থেকে বেঁধে দেওয়া জরুরি, যাতে অনুসন্ধান নীরবে enforcement action-এ পরিণত না হয়।
Verdict একটি সিদ্ধান্ত, কিন্তু action-এর অনুমতি নয়। “সম্ভবত আক্রান্ত” থেকে “containment প্রয়োজন” পর্যায়ে যাওয়ার সময় supporting ও contradictory evidence, পরিচয়ের গুরুত্ব এবং সম্ভাব্য ব্যবসায়িক প্রভাব analyst-এর সামনে দৃশ্যমান থাকা উচিত। Verdict এবং action authorization আলাদা audit event হলে পরে বোঝা যায়, ভুলটি বিশ্লেষণে হয়েছিল নাকি অনুমোদনে।
কোন action স্বয়ংক্রিয় হতে পারে
Automation-এর উপযোগিতা action-এর confidence-এর পাশাপাশি তার প্রভাব ও reversibility-এর ওপর নির্ভর করে। পরিচিত ক্ষতিকর URL, file বা source IP-তে স্বল্পমেয়াদি block—যদি একাধিক signal মেলে এবং playbook আগে থেকেই অনুমোদিত থাকে—সীমিত পরিসরে স্বয়ংক্রিয় করা যেতে পারে। প্রতিটি action-এর target, সর্বোচ্চ scope ও expiry নির্ধারিত না থাকলে ছোট block-ও দীর্ঘস্থায়ী disruption তৈরি করতে পারে।
পুরো user identity বিচ্ছিন্ন করা বেশি প্রভাবের সিদ্ধান্ত। এতে email, SaaS, production system বা প্রশাসনিক console-এ বৈধ প্রবেশও থেমে যেতে পারে। Privileged administrator, service account, shared identity কিংবা গুরুত্বপূর্ণ ব্যবসায়িক application-সংশ্লিষ্ট user-এর ক্ষেত্রে তাই recommendation বা approval-required action নিরাপদ প্রাথমিক অবস্থান।
একটি session বন্ধ করা, নির্দিষ্ট application-এর access আটকানো এবং পুরো identity isolate করা একই containment নয়। সম্ভাব্য ক্ষতি থামাতে সক্ষম সবচেয়ে সংকীর্ণ ও সময়সীমাবদ্ধ control বেছে নিলে blast radius কম থাকে। Confidence বেশি হলেও action-এর পরিসর বড় হলে মানুষের অনুমোদন বাদ দেওয়ার যুক্তি নিজে থেকেই তৈরি হয় না।
মানুষের approval কোথায় বসবে
Zscaler-এর Agentic SOC পণ্যবিবরণে মানুষের তত্ত্বাবধানে playbook চালানো অথবা confidence বাড়ার সঙ্গে পূর্ণ automation সক্রিয় করার বিকল্প রয়েছে; multi-step playbook Zscaler ও third-party control দিয়ে স্বয়ংক্রিয়ভাবে বা human approval নিয়ে চালানো যায়। একই পৃষ্ঠায় URL, file ও source IP block বা unblock করার native control এবং supporting ও contradictory evidence দেখানোর কথাও রয়েছে।
এই প্রকাশিত capability থেকে deployment-ready policy নিজে তৈরি হয় না। বাংলাদেশ ও ভারতের enterprise SOC-এর জন্য নিচের matrix একটি সম্পাদকীয় control model—Zscaler-এর ঘোষিত default configuration নয়:
- Triage: agent alert grouping ও priority দিতে পারে; queue owner হবেন analyst। কোনো enforcement হবে না, আর input, correlation rule, model version ও score সংরক্ষিত থাকবে।
- Investigation: read-only enrichment ও timeline স্বয়ংক্রিয় হতে পারে। Sensitive system-এ নতুন query, tenant-এর বাইরে access বা data export প্রতিষ্ঠানের data-access policy অনুযায়ী অনুমোদিত হবে।
- Verdict: কম confidence, পরস্পরবিরোধী প্রমাণ, critical identity বা গুরুত্বপূর্ণ application জড়িত থাকলে tier-two analyst অথবা incident commander সিদ্ধান্ত যাচাই করবেন।
- Containment: সংকীর্ণ, সময়সীমাবদ্ধ এবং সহজে ফেরানো যায়—এমন block pre-approved হতে পারে। পুরো user isolation, account disable, বিস্তৃত network restriction বা একাধিক third-party system বদলাতে স্পষ্ট মানব অনুমোদন থাকবে।
জরুরি ক্ষেত্রে approval-এর অপেক্ষা আক্রমণ ছড়ানোর সময় বাড়াতে পারে। সেই ব্যতিক্রমও আগে থেকে নীতিবদ্ধ হওয়া দরকার: কোন স্বাধীন signal একসঙ্গে মিলতে হবে, কোন পরিচয় automation-এর বাইরে থাকবে, action কতক্ষণ কার্যকর থাকবে এবং duty analyst কখন notification পাবেন। এটি agent-কে সীমাহীন অনুমতি দেওয়ার সমতুল্য নয়।
Rollback ছাড়া approval অসম্পূর্ণ
যে playbook containment চালাবে, সেটিতেই বিপরীত action ও দায়িত্ব নির্ধারিত থাকা উচিত। URL বা IP block-এর জন্য unblock, policy পরিবর্তনের জন্য আগের version পুনর্বহাল এবং user isolation-এর জন্য সংশ্লিষ্ট identity বা access control অনুযায়ী পুনরুদ্ধার-পথ দরকার। Vendor-এর প্রকাশিত উপকরণ কিছু block ও unblock capability জানায়, কিন্তু প্রতিটি গ্রাহকের identity stack-এ false positive-এর পর access ফেরানোর অভিন্ন পদ্ধতি দেয় না।
Third-party SOAR, EDR বা identity control একই entity-তে আলাদা action নিলে state conflict হতে পারে। কোন ব্যবস্থা system of record হবে, action ID কীভাবে পুনরাবৃত্তি ঠেকাবে এবং enforcement-এর আগে বর্তমান state কীভাবে যাচাই হবে—এসব playbook-এ লেখা থাকা দরকার। নইলে একটি control unblock করলেও অন্যটি user বা traffic আটকে রাখতে পারে।
Audit trail-এ agent-এর প্রস্তাব, verdict-এর প্রমাণ, অনুমোদনকারীর পরিচয়, কার্যকর API action, ফল এবং rollback আলাদা timestamp-সহ রাখা উচিত। শুধু incident-এর final status সংরক্ষণ করলে false positive, অসম্পূর্ণ rollback ও third-party conflict আলাদা করে শনাক্ত করা কঠিন হবে।
‘Machine speed’ এখনো ফলাফলের প্রমাণ নয়
“Machine speed” Zscaler-এর পণ্যের দাবি; এটি কোনো নির্দিষ্ট গ্রাহকের production ফল নয়। ঘোষণায় প্রযুক্তির availability ও capability বর্ণিত হয়েছে, কিন্তু precision, false-positive containment, mean time to contain, approval latency বা rollback time-এর তুলনামূলক customer benchmark প্রকাশ করা হয়নি। ফলে দ্রুততার দাবি যাচাই করতে deployment-নির্দিষ্ট পরিমাপ দরকার।
প্রথমে shadow mode-এ agent-এর recommendation ও analyst-এর সিদ্ধান্ত তুলনা করা যেতে পারে। পরে কম-প্রভাবের indicator বা সীমিত user group-এ সময়সীমাবদ্ধ automation চালিয়ে দেখা দরকার কতটি সিদ্ধান্ত সঠিক ছিল, কত বৈধ user বা business process বাধাগ্রস্ত হয়েছে এবং rollback সম্পূর্ণ হতে কত সময় লেগেছে। এগুলো বাস্তবায়ন-পরামর্শ; প্রকাশিত customer result নয়।
এখন পর্যন্ত নিশ্চিত অবস্থা হলো, ৯ সেপ্টেম্বর ২০২৬-এ ঘোষিত ও বিশ্বজুড়ে উপলভ্য Zscaler Agentic SOC আক্রান্ত user isolate এবং ক্ষতিকর যোগাযোগ block করার control সমর্থন করে; playbook মানুষ তত্ত্বাবধান করেও বা automation দিয়েও চালানো যায়। অমীমাংসিত অংশটি প্রতিষ্ঠানের governance: কোন action শুধু recommendation থাকবে, কোনটি pre-approved হবে এবং high-impact isolation অনুমোদন ও ফিরিয়ে দেওয়ার দায়িত্ব কার থাকবে।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।