এই পর্বে যা শিখবেন
- রক্ষকেরা কেন প্রতিপক্ষের কাজের মডেল বানান, আর কোন প্রশ্নের উত্তর এতে মেলে
- Kill chain-এর সাত ধাপ আর প্রতিটি ধাপের প্রতিরক্ষা-ম্যাট্রিক্স
- ATT&CK-এর tactic, technique, sub-technique, procedure, mitigation আর detection-এর সম্পর্ক
- একটি detection-কে technique-এর সাথে মেলানো, coverage মাপা আর কোন gap আগে সারবেন তা ঠিক করা
- ATT&CK-কে চেকলিস্ট বানানোর বিপদ, আর AI-এর দেওয়া mapping যাচাইয়ের উপায়
১ · রক্ষক কেন প্রতিপক্ষের মানচিত্র আঁকেন
আপনার এলাকায় পরপর কয়েকটি বাড়িতে চুরি হলো। মহল্লার পাহারাদার দল দুইভাবে ভাবতে পারে। এক, প্রতিটি বাড়িতে আরও বড় তালা লাগানো। দুই, চোরের পুরো কাজটি বোঝা। চোর আগে কয়েকদিন গলি ঘুরে দেখে। তারপর যন্ত্রপাতি জোগাড় করে। রাতে গেট পার হয়, তালা ভাঙে, ভেতরে লুকিয়ে থাকে, বাইরের সঙ্গীর সাথে যোগাযোগ করে, শেষে আলমারি খালি করে।
দ্বিতীয় ভাবনায় পাহারাদার দেখেন, থামানোর জায়গা একটি নয়, সাতটি। গলিতে অচেনা মুখ দেখলে খাতায় লেখা যায়। গেটে আলো বসানো যায়। আলমারি আলাদা ঘরে রাখা যায়। চোরকে সবগুলো ধাপ পার হতে হয়, আর রক্ষকের দরকার যেকোনো এক জায়গায় তাকে থামানো। ডিজিটাল জগতেও এই চিন্তাটিই কাজ করে।
পর্ব ৪ (Threat modeling)-এ আপনি নিজের সিস্টেম থেকে শুরু করে দেখেছেন কোথায় কী ভুল হতে পারে। এই পর্বে দৃষ্টি ঘুরছে প্রতিপক্ষের দিকে। Threat আসলে কীভাবে এগোয়, সেই বাস্তব আচরণের মানচিত্র এখানে আঁকা হবে। মডেল বানালে রক্ষক চারটি প্রশ্নের উত্তর পান:
একই ভাষা
SOC analyst, প্রকৌশলী আর ব্যবস্থাপক একই শব্দে একই ঘটনা বোঝান। “অনেক বড় হ্যাক” বলার বদলে বলা যায় “C2 ধাপে ধরা পড়েছে”।
যোগাযোগকোথায় অন্ধ
কোন ধাপে আপনার চোখ আছে আর কোথায় নেই, তা দেখা যায়। এই ফাঁকের নাম detection gap.
মাপজোককোথায় বিনিয়োগ
সীমিত অর্থ আর লোকবল কোন প্রতিরক্ষায় আগে যাবে, তার যুক্তি মেলে।
অগ্রাধিকারঘটনার পর শিক্ষা
Incident-এর পর “কোন ধাপে থামানো যেত” প্রশ্নটি পরিষ্কার উত্তর দেয়।
উন্নতিসীমারেখা: এই পর্বে ধাপ আর technique-এর শুধু নাম ও ধরন আছে, সবসময় প্রতিরক্ষার সাথে। কোনো ধাপ কীভাবে করতে হয় তা এখানে নেই, থাকবেও না। অনুমতি ছাড়া কারও সিস্টেমে ঢোকা বা পরীক্ষা চালানো অপরাধ। আইনি দিক দেখুন পর্ব ৬-এ।
২ · Cyber Kill Chain — সাত ধাপের শিকল
“Kill chain” শব্দটি এসেছে সামরিক লক্ষ্যভেদ-নীতি থেকে। সেখানে find, fix, track, target, engage, assess, এই ক্রমের যেকোনো একটি আংটা ভাঙলে পুরো কাজ থেমে যায়। ২০১১ সালে Lockheed Martin-এর Eric Hutchins, Michael Cloppert আর Rohan Amin একটি গবেষণাপত্রে এই ধারণা network হামলায় আনেন। শিরোনাম ছিল “Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains”. তাঁদের লক্ষ্য ছিল দীর্ঘমেয়াদি, ধৈর্যশীল প্রতিপক্ষ, যাদের বলা হয় APT.
গবেষণাপত্রটির মূল আপত্তি ছিল প্রচলিত incident response নিয়ে। সেখানে ধরে নেওয়া হতো, সাড়া শুরু হবে সিস্টেম আক্রান্ত হওয়ার পরে। লেখকেরা বললেন, সাড়া আরও আগের ধাপে নেওয়া সম্ভব। তাঁদের ভাষায়, প্রতিপক্ষকে প্রতিটি ধাপ সফলভাবে পার হতে হয়, আর একটি প্রতিরোধই শিকল ভাঙতে পারে। “Cyber Kill Chain” এখন Lockheed Martin-এর নিবন্ধিত নাম, তবে ধারণাটি সবাই ব্যবহার করেন।
সাত ধাপ, প্রতিটির পাশে রক্ষকের কাজ
Kill chain stages mapped to defences
ধাপগুলোর নাম ইংরেজিতেই মনে রাখা ভালো, কারণ রিপোর্ট আর ইন্টারভিউতে এগুলোই চলে। Reconnaissance মানে লক্ষ্য সম্পর্কে খোঁজখবর। Weaponization মানে আক্রমণকারীর নিজের জায়গায় ক্ষতিকর জিনিস তৈরি। Delivery মানে সেটি লক্ষ্যে পৌঁছানো। Exploitation মানে কোনো vulnerability বা মানুষের ভুলের সুযোগে কোড চলা। Installation মানে টিকে থাকার ব্যবস্থা, যাকে বলে persistence. Command and Control (C2) মানে বাইরের নিয়ন্ত্রকের সাথে যোগাযোগ। আর Actions on Objectives মানে আসল লক্ষ্য পূরণ, যেমন তথ্য বের করে নেওয়া বা সিস্টেম নষ্ট করা।
এবার একটি পুরো কাল্পনিক ঘটনা দেখুন। একটি কাল্পনিক অনলাইন বাজারে হিসাব বিভাগকে লক্ষ্য করা হয়েছে। প্রতিটি ধাপে রক্ষকের হাতে কী সুযোগ ছিল, সেটিই আসল দেখার বিষয়। কারিগরি কৌশল এখানে নেই, শুধু ধারণা।
| ধাপ | |
| দিন | |
| রক্ষকের চোখ | |
| সুযোগের ব্যবহার | |
| অবস্থা |
- Reconnaissance. আক্রমণকারী প্রকাশ্য জায়গা থেকে হিসাব বিভাগের নাম-পদবি জানল। রক্ষকের সুযোগ সামান্য: ওয়েবসাইটে কর্মীদের সরাসরি email না রাখা, চাকরির বিজ্ঞপ্তিতে ভেতরের সফটওয়্যারের বিবরণ কম দেওয়া। বাজারটি এসব ভাবেনি।
- Weaponization. কাজটি আক্রমণকারীর নিজের জায়গায় হয়, তাই সরাসরি দেখা যায় না। পরোক্ষ সুযোগ একটিই: threat intelligence থেকে জানা, এই ধরনের দল সাধারণত কী দিয়ে আসে। ধাপটি মাপা না গেলেও ভাবা দরকার।
- Delivery. হিসাব বিভাগে একটি ভুয়া চালানের email এলো। Filter ধরতে পারেনি। দুজন কর্মী সন্দেহ করে রিপোর্ট করলেন, কিন্তু রিপোর্ট সারিতে পড়ে রইল। সুযোগ ছিল, প্রক্রিয়া দুর্বল ছিল। মানুষ সেন্সরের কাজ করেছেন, এটিই ভালো খবর।
- Exploitation. একজন কর্মী ফাইল খুললেন। অফিসের পুরোনো একটি সফটওয়্যারের জানা ত্রুটিতে কোড চলল। ঠিক করার update প্রকাশিত ছিল তিন সপ্তাহ আগে। সময়মতো patch হলে শিকল এখানেই ভাঙত।
- Installation. ল্যাপটপে টিকে থাকার ব্যবস্থা হলো। EDR একটি “নতুন autostart” সতর্কতা দিল, কিন্তু অগ্রাধিকার কম থাকায় পরের দিনের জন্য রয়ে গেল। ধরা পড়া আর সাড়া দেওয়া, দুটি আলাদা জিনিস।
- C2. ল্যাপটপটি একটি একেবারে নতুন domain-এর সাথে নিয়মিত বিরতিতে যোগাযোগ শুরু করল। DNS log-এ এই ছন্দ চোখে পড়ল। Analyst আগের দিনের EDR সতর্কতার সাথে মেলালেন। তদন্ত শুরু হলো, ল্যাপটপ network থেকে আলাদা করা হলো।
- Actions on Objectives. লক্ষ্য ছিল গ্রাহক ডেটাবেস। অফিস network আর ডেটাবেসের মাঝে segmentation ছিল, আর অ্যাকাউন্টটির অনুমতি কম ছিল। Audit log-এ একটি ব্যর্থ চেষ্টা দেখা গেল। ক্ষতির আগেই হামলা থামল।
- ঘটনার পর। দল পিছনের ধাপগুলো পুনর্গঠন করল: রিপোর্ট সারিতে নতুন নিয়ম, patch-এর সময়সীমা, autostart সতর্কতার অগ্রাধিকার বদল। গবেষণাপত্রের ভাষায় একে বলে detection-কে আগের ধাপে সরানো। এটিই kill chain-এর আসল লাভ।
৩ · প্রতিরক্ষা-ম্যাট্রিক্স — প্রতি ধাপে ছয় রকম কাজ
ধাপ জানলেই হবে না। প্রতিটি ধাপে রক্ষক কী কী করতে পারেন, সেটি একটি ছকে সাজানো যায়। মূল গবেষণাপত্রে একে বলা হয়েছে courses of action matrix. সারি হলো সাত ধাপ, কলাম হলো রক্ষকের কাজের ধরন।
Detect
দেখতে পাওয়া। ঘটছে কি না জানা।
Deny
ঢুকতেই না দেওয়া। কাজটি ঘটার আগেই আটকানো।
Disrupt
চলমান কাজ ভেঙে দেওয়া।
Degrade
কাজের গতি বা ফল কমিয়ে দেওয়া।
Deceive
ভুল পথে পাঠানো, ফাঁদ পাতা।
Contain
ক্ষতি একটি জায়গায় আটকে রাখা।
পরিভাষা নিয়ে সতর্কতা: ২০১১ সালের মূল ছকের ষষ্ঠ কলাম “Destroy”, যা মার্কিন প্রতিরক্ষা দপ্তরের information operations নীতি থেকে নেওয়া। মূল ছকে সেই কলাম ফাঁকা। পরের অনেক উপস্থাপনায় এই জায়গায় “Contain” ব্যবহার হয়, যা সাধারণ প্রতিষ্ঠানের জন্য বেশি বাস্তব। পরীক্ষায় কোন সংস্করণের কথা জানতে চাওয়া হচ্ছে, খেয়াল করুন। প্রতিপক্ষের সিস্টেমে পাল্টা হাত দেওয়া সাধারণ প্রতিষ্ঠানের বৈধ অধিকার নয়।
মূল ছকে কিছু সুন্দর উদাহরণ আছে। Exploitation ধাপে HIDS দেখে (detect), patch আটকায় (deny), memory সুরক্ষা ভেঙে দেয় (disrupt). C2 ধাপে tarpit গতি কমায় (degrade), আর DNS redirect ভুল পথে পাঠায় (deceive). নিচের ছকটি সেই ধারণার ওপর একটি আধুনিক উদাহরণ। এটি কোনো মানদণ্ড নয়, আর প্রতিটি ঘর পূরণ করাও লক্ষ্য নয়।
| ধাপ | Detect | Deny | Disrupt | Degrade | Deceive | Contain |
|---|---|---|---|---|---|---|
| Reconnaissance | Web log | প্রকাশ্য তথ্য কমানো | — | — | ভুয়া contact | — |
| Weaponization | Threat intel | — | — | — | — | — |
| Delivery | Filter, কর্মীর রিপোর্ট | DMARC, proxy নীতি | Inline scan | সন্দেহজনক email দেরিতে দেওয়া | — | Sandbox-এ খোলা |
| Exploitation | EDR, HIDS | Patch, hardening | Memory সুরক্ষা | — | — | App sandbox |
| Installation | EDR, file integrity | Allowlist, least privilege | Antivirus | — | — | Container সীমা |
| C2 | DNS log, NIDS | Egress নিয়ম | IPS | Tarpit | DNS redirect | যন্ত্র আলাদা করা |
| Actions on Objectives | Audit log, DLP | Least privilege, MFA | DLP-এর বাধা | গতি সীমা (QoS) | Honeypot | Segmentation |
ছকটির সবচেয়ে বড় লাভ ফাঁকা ঘর চোখে পড়া। আর একটি লাভ হিসাবের। ধরুন প্রতিটি ধাপে একটি হামলা থামার সম্ভাবনা জানা। সবগুলো স্বাধীন ধরলে শেষ ধাপে পৌঁছানোর সম্ভাবনা হলো:
এটি defense in depth-এর গাণিতিক ছবি। নিচের কোডের সংখ্যাগুলো ধরে নেওয়া, কোনো বাস্তব পরিমাপ নয়। চালিয়ে দেখুন, আর সংখ্যা বদলে আবার চালান।
// Toy numbers (assumed, not measured): the chance that a defence
// stops one intrusion at each stage, treated as independent.
const stages = [
['Reconnaissance', 0.05], ['Weaponization', 0.00], ['Delivery', 0.60],
['Exploitation', 0.40], ['Installation', 0.30], ['C2', 0.30],
['Actions on Obj.', 0.20],
];
function reach(list) {
return list.reduce((alive, [, stop]) => alive * (1 - stop), 1);
}
let alive = 1;
for (const [name, stop] of stages) {
alive *= 1 - stop;
console.log(name.padEnd(16), 'stop', stop.toFixed(2), ' still going', (alive * 100).toFixed(1) + '%');
}
// What if one stage improves by 0.10?
for (const i of [2, 5]) {
const better = stages.map((s, k) => (k === i ? [s[0], s[1] + 0.10] : s));
console.log('Add 0.10 at', stages[i][0].padEnd(9), '-> reach goal', (reach(better) * 100).toFixed(1) + '%');
}
// What if the email filter is absent?
const noFilter = stages.map(s => (s[0] === 'Delivery' ? [s[0], 0] : s));
console.log('No delivery control -> reach goal', (reach(noFilter) * 100).toFixed(1) + '%');আউটপুটের শেষে Actions on Obj. stop 0.20 still going 8.9%. অর্থাৎ ০.৯৫ × ১ × ০.৪ × ০.৬ × ০.৭ × ০.৭ × ০.৮ = ০.০৮৯, প্রতি ১০০টি চেষ্টায় প্রায় ৯টি সফল। Delivery-তে ০.১০ বাড়ালে ফল 6.7%, C2-তে একই ০.১০ বাড়ালে 7.7%. কারণ ০.৬০ থেকে ০.৭০ হলে অবশিষ্ট অংশ চার ভাগের এক ভাগ কমে, আর ০.৩০ থেকে ০.৪০ হলে সাত ভাগের এক ভাগ। Delivery-র নিয়ন্ত্রণ পুরো তুলে নিলে ফল লাফিয়ে 22.3%. একটি ধাপের ওপর কতটা নির্ভর করছেন, সেটি এই শেষ লাইনই বলে দেয়।
এই গুণ শুধু ধারণা দেয়। বাস্তবে ধাপগুলো স্বাধীন নয়। Filter পার হওয়া একটি যত্নে বানানো email হয়তো পরের ধাপেও বেশি সফল। প্রতিপক্ষও বদলায়, ব্যর্থ হলে আবার চেষ্টা করে। তাই “৯%” কোনো পূর্বাভাস নয়, তুলনার একটি মাপকাঠি মাত্র।
৪ · Kill chain-এর সীমা, আর তার পরের মডেল
মডেল মানে সরলীকরণ, তাই প্রতিটি মডেলের একটি সীমা থাকে। Kill chain-এর পরিচিত সমালোচনাগুলো জানা জরুরি:
- সীমানা-কেন্দ্রিক ভাবনা। মডেলটি ধরে নেয় হামলা বাইরে থেকে একটি সীমানা পেরিয়ে ভেতরে আসে। প্রথম ধাপগুলো আপনার network-এর বাইরে ঘটে, তাই সেখানে দেখা বা থামানো কঠিন।
- ভেতরের মানুষ। Insider threat-এ Reconnaissance, Delivery বা Installation দরকারই নাও হতে পারে। একজন অনুমোদিত কর্মী সরাসরি শেষ ধাপে থাকতে পারেন।
- Cloud আর পরিচয়-নির্ভর হামলা। চুরি হওয়া credential দিয়ে cloud console-এ ঢুকলে malware, Installation বা C2 ধাপই হয়তো নেই। Log-এ শুধু “বৈধ login” দেখা যায়। প্রতিরক্ষার কেন্দ্র তখন identity (পর্ব ১৬), least privilege আর audit log.
- সরল রেখা বনাম বাস্তব। বাস্তব হামলা ঘুরেফিরে চলে। আক্রমণকারী ভেতরে ঢুকে আবার খোঁজ নেয়, পাশের যন্ত্রে যায়। এই lateral movement মডেলটিতে আলাদা ধাপ নয়।
- Web আর supply chain. সরাসরি web app-এর ত্রুটি থেকে ডেটা বের হলে অনেক ধাপ এক হয়ে যায়। আর supply chain হামলায় Delivery আসে বিশ্বস্ত update-এর পথে।
তার মানে মডেলটি বাতিল নয়। ব্যবস্থাপনার কাছে একটি ঘটনা বোঝাতে এটি এখনো খুব ভালো। কিন্তু বিস্তারিত প্রতিরক্ষা পরিকল্পনায় আরও সূক্ষ্ম মানচিত্র লাগে।
দুটি পরিচিত সঙ্গী মডেল। Unified Kill Chain: Paul Pols ২০১৭ সালের ডিসেম্বরে Leiden University-র Cyber Security Academy-র Executive Master’s থিসিসে এটি প্রকাশ করেন, পরে white paper হালনাগাদ হয়। এটি Lockheed-এর মডেল আর ATT&CK জুড়ে ১৮টি ধাপ দেয়, তিন ভাগে: In (ঢোকা), Through (ভেতরে এগোনো), Out (লক্ষ্য পূরণ)। আর পথটি সরল রেখা নয়, বরং লুপ। Diamond Model: Caltagirone, Pendergast আর Betz (২০১৩) বলেন, প্রতিটি ঘটনার চারটি কোণ আছে: adversary, capability, infrastructure, victim. এটি ধাপ নয়, সম্পর্ক দেখায়। একই infrastructure দুটি ঘটনায় থাকলে তদন্ত এক কোণ থেকে অন্য কোণে এগোতে পারে। Kill chain ধাপ দেখায়, diamond দেখায় ঘটনার ভেতরের সম্পর্ক।
৫ · MITRE ATT&CK — বাস্তব আচরণের অভিধান
Kill chain যদি বড় রাস্তার মানচিত্র হয়, ATT&CK হলো প্রতিটি গলির তালিকা। পুরো নাম Adversarial Tactics, Techniques, and Common Knowledge. মার্কিন অলাভজনক প্রতিষ্ঠান MITRE ২০১৩ সালে Fort Meade Experiment নামের একটি গবেষণা-পরিবেশে এর কাজ শুরু করে, আর ২০১৫ সালে জনসমক্ষে আনে। মূল কথা: ভিত্তি হলো বাস্তবে দেখা আচরণ, প্রকাশিত রিপোর্ট থেকে নেওয়া। সব সম্ভাব্য কল্পনা নয়।
থানার পুরোনো রেজিস্টার খাতার কথা ভাবুন। সেখানে অপরাধীর নামের চেয়েও দামি তথ্য হলো কাজের ধরন: কোন দল রাতে আসে, কোন দল দুপুরে, কে তালা ভাঙে, কে ভুয়া পরিচয়ে ঢোকে। ATT&CK সেই খাতা, তবে সারা বিশ্বের প্রকাশিত ঘটনা থেকে বানানো। প্রত্যেক “ধরনের” পাশে লেখা থাকে কী দিয়ে ঠেকাবেন আর কীভাবে ধরবেন।
গঠনটি চার স্তরের। উদাহরণ হিসেবে দেখুন T1110.003:
ATT&CK-এর স্তর: “কেন” থেকে “ঠিক কীভাবে”
Tactic → Technique → Sub-technique → Procedure
- Tactic
TA0006কেন: credential পাওয়া - Technique
T1110কীভাবে: Brute Force - Sub-technique
T1110.003আরও নির্দিষ্ট: Password Spraying - Procedure
রিপোর্টকোনো দল বাস্তবে যেভাবে করেছে
- Tactic: আক্রমণকারীর সেই মুহূর্তের উদ্দেশ্য। যেমন Persistence, Lateral Movement.
- Technique: উদ্দেশ্য পূরণের ধরন। একটি technique একাধিক tactic-এ থাকতে পারে।
- Sub-technique: technique-এর আরও নির্দিষ্ট রূপ। ২০২০ সালের জুলাইয়ে v7-এ যোগ হয়েছে।
- Procedure: কোনো দল বা malware বাস্তবে যেভাবে কাজটি করেছে, রিপোর্টের উদ্ধৃতিসহ। এই তিনটির সংক্ষেপই TTP.
- Mitigation:
Mদিয়ে শুরু ID. যেমনM1032Multi-factor Authentication. - Detection: আগে পাতায় data source আর data component থাকত, অর্থাৎ কোন log বা telemetry দরকার। v18 থেকে এসেছে detection strategy (
DET) আর analytic (AN). Data component-এর হিসাব এখনো আছে।
ATT&CK-এর কয়েকটি আলাদা জগৎ আছে, যাকে বলে matrix. নিচের সংখ্যা ২০২৬ সালের ১৩ অক্টোবরে প্রকাশিত v20-এর, MITRE-এর পাতা থেকে নেওয়া। বছরে সাধারণত দুবার, এপ্রিল আর অক্টোবরের কাছাকাছি, বড় সংস্করণ আসে। তাই এই সংখ্যা মুখস্থ করবেন না, কাজের সময় attack.mitre.org মিলিয়ে নিন।
| Matrix | কী নিয়ে | Tactic | Technique | Sub-technique |
|---|---|---|---|---|
| Enterprise | Windows, Linux, macOS, cloud, identity, network | ১৫ | ২২৭ | ৪৭৯ |
| Mobile | Android আর iOS | ১২ | ৭৮ | ৪৭ |
| ICS | কারখানা, বিদ্যুৎ, পানির মতো শিল্প-নিয়ন্ত্রণ ব্যবস্থা | ১২ | ৭৮ | ২৬ |
v20-এ Enterprise-এর ১৫টি tactic হলো: Reconnaissance, Resource Development, Initial Access, Execution, Persistence, Privilege Escalation, Stealth, Defense Impairment, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, Impact. পুরোনো বই বা blog-এ “Defense Evasion” দেখলে অবাক হবেন না। ২০২৬ সালের এপ্রিলে v19 সেই tactic-কে Stealth আর Defense Impairment-এ ভাগ করেছে, শুধু Enterprise-এ। ICS-এ আবার আছে Inhibit Response Function আর Impair Process Control-এর মতো নিজস্ব tactic, কারণ সেখানে ক্ষতি মানে যন্ত্র বা প্রক্রিয়ার ক্ষতি।
আরও গভীরে: MITRE-এর “ATT&CK: Design and Philosophy” দলিলে কাঠামোর যুক্তি আছে। প্রতিরক্ষার দিকের সঙ্গী মানচিত্র হলো MITRE-এর D3FEND, আর AI সিস্টেমের জন্য আছে ATLAS. Center for Threat-Informed Defense-এর “Summiting the Pyramid” প্রকল্প একটি detection আক্রমণকারীর সহজ বদলে কতটা টিকে থাকে, তা মাপার চেষ্টা করে। সবগুলোরই সংস্করণ বদলায়, তাই মূল উৎস থেকে পড়ুন।
৬ · Pyramid of Pain — কোনটি ধরলে আক্রমণকারীর সবচেয়ে কষ্ট
বাজারের পকেটমারকে আপনি কীভাবে চিনবেন? লাল জামা দেখে? পরের দিন সে নীল জামা পরবে। কিন্তু তার ভিড়ে ঢোকার ধরন, সঙ্গীকে ইশারা, হাতের কৌশল, এগুলো রাতারাতি বদলায় না। ২০১৩ সালের মার্চে নিরাপত্তা-বিশেষজ্ঞ David Bianco এই ধারণাটিই একটি পিরামিডে আঁকেন। প্রশ্নটি ছিল: আপনি যে indicator ধরছেন, সেটি হারালে আক্রমণকারীর কতটা কষ্ট হয়?
Pyramid of Pain
David Bianco, ২০১৩ — নিচ থেকে ওপরে কষ্ট বাড়ে
এখন খরচের হিসাবটি ধাপে ধাপে দেখুন। সময়ের সংখ্যাগুলো বোঝার জন্য ধরে নেওয়া, মাপা তথ্য নয়। আসল বিষয় হলো ক্রমটি।
| স্তর | |
| Bianco-র লেবেল | |
| আক্রমণকারীর বদল | |
| ধরে নেওয়া সময় | |
| খরচের মিটার | |
| রক্ষকের পরিশ্রম |
- Hash value. ফাইলের আঙুলছাপ। মিলে গেলে নিশ্চিত, কিন্তু ফাইল সামান্য বদলালেই পুরো hash বদলে যায়। লাল জামার মতো। ধরা সহজ, হারানোও সহজ।
- IP address. Blocklist-এ দেওয়া সহজ, তবে আক্রমণকারীর নতুন ঠিকানা নিতে দেরি হয় না। ভুল করে শেয়ার করা ঠিকানা আটকালে বৈধ ব্যবহারকারীও আটকে যেতে পারেন।
- Domain name. নতুন domain নিতে একটু বেশি কাজ ও খরচ লাগে, তাই IP-এর চেয়ে সামান্য ভালো। DNS log থাকলে নজর রাখা সহজ।
- Network / host artifact. ব্যবহার করা যন্ত্রাংশের চিহ্ন, যেমন যোগাযোগের নির্দিষ্ট ধরন বা ফাইলের নামের ছাঁচ। এখানে আক্রমণকারীকে থামতে হয়, নিজের অভ্যাস বদলাতে হয়। Bianco এখান থেকেই বাস্তব কষ্ট শুরু হতে দেখেন।
- Tool. আক্রমণকারীর পরিচিত tool-এর আচরণ ধরতে পারলে তাকে নতুন tool খুঁজতে বা বানাতে হবে। সময় আর অর্থ দুটোই লাগে। আপনাকেও behaviour-ভিত্তিক detection লিখতে হয়।
- TTP. এখন আপনি আচরণ ধরছেন, টুল নয়। প্রতিপক্ষকে নতুন করে কাজের ধরন শিখতে হবে। বাজারের পকেটমারের হাতের কৌশল বদলানোর মতো। এটিই লক্ষ্য, তবে সবচেয়ে কঠিন, আর false positive-ও বেশি হতে পারে।
এবার একটি toy log-এ দুই রকম rule তুলনা করুন। IOC rule শুধু চেনা IP মেলায়। Behaviour rule দেখে একটি উৎস ১০ মিনিটে অন্তত ৫টি ভিন্ন অ্যাকাউন্টে ব্যর্থ হয়েছে কি না। সব ডেটা বানানো, সব ঠিকানা documentation range-এর। কোড শুধু log পড়ে সিদ্ধান্ত দেয়।
// Toy failed-login log. Addresses are documentation ranges.
const fails = (src, n, min) => Array.from({ length: n }, (_, i) =>
({ src, user: 'user' + (i + 1), min: min + i }));
const round1 = fails('203.0.113.7', 6, 0); // intrusion attempt
const round2 = fails('198.51.100.9', 6, 40); // same behaviour, new IP
const typo = [1, 2, 3].map(m => ({ src: '203.0.113.20', user: 'rina', min: m }));
const office = fails('198.51.100.50', 5, 70); // benign: shared office IP
const blocklist = new Set(['203.0.113.7']); // learned from round 1
const iocRule = log => [...new Set(log.filter(e => blocklist.has(e.src)).map(e => e.src))];
function behaviourRule(log, limit = 5, windowMin = 10) {
const hits = [];
for (const src of new Set(log.map(e => e.src))) {
const ev = log.filter(e => e.src === src);
const users = new Set(ev.map(e => e.user));
const span = Math.max(...ev.map(e => e.min)) - Math.min(...ev.map(e => e.min));
if (users.size >= limit && span <= windowMin) hits.push(src);
}
return hits;
}
const cases = { 'round 1': round1, 'round 2 new IP': round2, 'one user typo': typo, 'shared office': office };
console.log('case'.padEnd(16), 'IOC rule'.padEnd(10), 'behaviour rule');
for (const [name, log] of Object.entries(cases)) {
console.log(name.padEnd(16), String(iocRule(log).length).padEnd(10), behaviourRule(log).length);
}
const truth = ['203.0.113.7', '198.51.100.9']; // real attempts
const all = [...round1, ...round2, ...typo, ...office];
for (const [name, hits] of [['IOC', iocRule(all)], ['behaviour', behaviourRule(all)]]) {
const tp = hits.filter(h => truth.includes(h)).length;
console.log(name.padEnd(10), 'precision', (tp / hits.length).toFixed(2), 'recall', (tp / truth.length).toFixed(2));
}দ্বিতীয় চেষ্টায় IP বদলেছে, তাই round 2 new IP সারিতে IOC rule 0, আর behaviour rule 1. কিন্তু shared office সারিতে behaviour rule একটি নিরীহ অফিসকেও ধরেছে, এটি false positive. তাই শেষ দুই লাইনে IOC: precision 1.00 recall 0.50, আর behaviour: precision 0.67 recall 1.00. Precision = TP ÷ (TP + FP) = ২ ÷ ৩। Recall = TP ÷ (TP + FN) = ২ ÷ ২। ওপরে ওঠা মানে টেকসই detection, কিন্তু যাচাইয়ের খরচও বাড়া। আর একই উৎসের rule ছড়ানো উৎস দেখতে পাবে না, তাই প্রতিষ্ঠানজুড়ে মোট ব্যর্থতার হারও দেখা দরকার।
নিচের স্তর অকেজো নয়। সক্রিয় incident-এ চেনা hash আর IP দিয়ে দ্রুত আক্রান্ত যন্ত্র খুঁজে পাওয়া যায়। ভুল হলো শুধু সেখানেই থেমে থাকা। বিস্তারিত দেখবেন পর্ব ৫৭ (Threat intelligence) আর পর্ব ২৩ (IDS আর IPS)-এ।
৭ · একটি detection-কে technique-এর সাথে মেলানো
ATT&CK-এর হাতেকলমে ব্যবহার শুরু হয় এখান থেকে। আপনার SIEM বা EDR-এ একটি পর্যবেক্ষণ আছে। প্রশ্ন হলো, এটি মানচিত্রের কোন ঘরে পড়ে, আর পড়লে কী বাড়তি লাভ।
| প্রশ্ন | |
| উত্তর | |
| ATT&CK ID | |
| নিশ্চিততা |
- আগে তথ্য, পরে নাম। Log বলছে একটি উৎস থেকে পাঁচ মিনিটে ছয়টি ভিন্ন অ্যাকাউন্টে একটি করে ব্যর্থ login. ID বসানোর আগে পর্যবেক্ষণটি সাদা ভাষায় লিখে নিন।
- Tactic: কেন? এই আচরণ থেকে আক্রমণকারী কী পেতে চাইছে? একটি বৈধ অ্যাকাউন্টের পরিচয়। তাই Credential Access (
TA0006). - Technique: কীভাবে? অনুমান করে ঢোকার চেষ্টার ধরনকে ATT&CK বলে Brute Force (
T1110). ID-টি মুখস্থ নয়, পাতায় মিলিয়ে নিন। - Sub-technique. একটি অ্যাকাউন্টে বহুবার নয়, বহু অ্যাকাউন্টে অল্প করে, এই ধরনটি মেলে Password Spraying (
T1110.003)-র বর্ণনায়। প্রমাণ না থাকলে parent technique-এই থামুন। - পাতা থেকে প্রতিরক্ষা। Technique-এর পাতায় পাওয়া গেল Multi-factor Authentication (
M1032), Account Use Policies (M1036), Password Policies (M1027). Detection strategyDET0487-এও এই ধরনের ব্যর্থতার ছবি আছে। এখন শুধু “একটি rule” নয়, ঠেকানোর পরিকল্পনাও হলো। - Coverage বদল। আগে শুধু log ছিল (L). Rule লেখার পর ঘরটি হলো “alert আছে, test নেই” (A). পরীক্ষা না করা পর্যন্ত একে “tested” বলবেন না।
এই detection-টি Sigma ধাঁচে এমন হতে পারে। False positive কমানোর কৌশল পর্ব ৫৬-এ আছে।
title: Failed logon
name: failed_logon
status: experimental
logsource:
product: windows
service: security
detection:
selection:
EventID: 4625
condition: selection
---
title: One source fails on many accounts
status: experimental
correlation:
type: value_count
rules:
- failed_logon
group-by:
- IpAddress
timespan: 10m
condition:
field: TargetUserName
gte: 5
tags:
- attack.credential-access
- attack.t1110.003
level: mediumএটি উদাহরণ, চালানোর জন্য নয়। Field-এর নাম আপনার log source অনুযায়ী মিলিয়ে নিতে হবে। tags লাইনই rule-টিকে মানচিত্রের সাথে জুড়ে দেয়, ফলে পরে কোন technique-এ কয়টি rule আছে তা স্বয়ংক্রিয়ভাবে গোনা যায়।
৮ · Coverage map, gap বাছাই আর purple team
Detection coverage map হলো ATT&CK-এর ঘরগুলো রঙ করে দেখা, কোথায় আপনার চোখ আছে। MITRE-এর ATT&CK Navigator-এর মতো টুলে এটি আঁকা যায়। তবে একটি রং দিয়ে তিনটি আলাদা অবস্থা ঢেকে ফেলা বড় ভুল: log আছে, alert আছে, আর alert পরীক্ষা করে দেখা হয়েছে।
নিচের কোডে একটি কাল্পনিক প্রতিষ্ঠানের toy map আছে, সাতটি tactic-এ ৩২টি technique. প্রতিটি অক্ষর একটি technique-এর অবস্থা। এখানে কোনো tactic-এর পূর্ণ তালিকা নেই, শুধু ধারণার জন্য।
// Toy coverage data for a fictional company. One letter = one technique.
// T = alert tested, A = alert not tested, L = logs only, N = nothing
const map = {
'Initial Access': 'TTALNN',
'Execution': 'TALLN',
'Persistence': 'TALNNN',
'Credential Access': 'TLNN',
'Lateral Movement': 'ANNN',
'Exfiltration': 'LNN',
'Impact': 'TTLN',
};
const paint = { T: '#', A: '+', L: '.', N: '_' };
const count = (s, set) => [...s].filter(c => set.includes(c)).length;
const pct = (a, b) => String(Math.round(100 * a / b)).padStart(3) + '%';
console.log('tactic'.padEnd(18), 'heat'.padEnd(7), 'tested', 'alert', 'seen');
let total = 0, tested = 0, alert = 0, seen = 0;
for (const [tactic, s] of Object.entries(map)) {
const n = s.length, t = count(s, 'T'), a = count(s, 'TA'), v = count(s, 'TAL');
total += n; tested += t; alert += a; seen += v;
const heat = [...s].map(c => paint[c]).join('');
console.log(tactic.padEnd(18), heat.padEnd(7), pct(t, n).padStart(6), pct(a, n).padStart(5), pct(v, n).padStart(4));
}
console.log('ALL'.padEnd(18), String(total).padEnd(7), pct(tested, total).padStart(6),
pct(alert, total).padStart(5), pct(seen, total).padStart(4));
console.log('legend: # tested + untested alert . logs only _ nothing');শেষ সারি ALL 32 22% 34% 56%. অর্থাৎ ৩২টির মধ্যে ১৮টিতে কিছু একটা দেখা যায় (৫৬%), ১১টিতে alert আছে (৩৪%), কিন্তু পরীক্ষিত মাত্র ৭টি (২২%). একই প্রতিষ্ঠান চাইলে বলতে পারে “৫৬% coverage”, চাইলে “২২%”. এখন Credential Access #.__ 25% 25% 50% সারিটি দেখুন: চারটির মধ্যে দুটিতে কিছু দেখা যায়, কিন্তু পরীক্ষিত একটি। আর Lateral Movement ও Exfiltration-এ পরীক্ষিত 0%, যা মোট সংখ্যায় লুকিয়ে যায়। তাই সবসময় বলুন কোন সংজ্ঞায় কত, আর tactic ভাগ করে দেখান।
সব gap একসাথে সারানো যায় না। কোনটি আগে? সবচেয়ে কম শতাংশের tactic বেছে নেওয়া একটি ফাঁদ। তার চেয়ে ভালো প্রশ্ন: আমার মতো প্রতিষ্ঠানের বিরুদ্ধে কোন আচরণ বেশি দেখা যায়, ক্ষতি কত, log আছে কি, কাজটি কত বড়? নিচের সূত্রটি শুধু আলোচনা শুরুর একটি toy স্কোর, কোনো মানদণ্ড নয়।
// Which gap first? A toy score, not a standard:
// score = relevance x impact x dataReady / effortDays
// relevance, impact: 1 to 5. dataReady: 1 yes, 0.5 partial, 0 no log yet.
const gaps = [
{ gap: 'Password spraying', tactic: 'Credential Access', rel: 5, imp: 4, data: 1, days: 2 },
{ gap: 'Backup tampering', tactic: 'Impact', rel: 3, imp: 5, data: 1, days: 2 },
{ gap: 'Remote admin misuse', tactic: 'Lateral Movement', rel: 4, imp: 5, data: 0.5, days: 5 },
{ gap: 'Cloud upload spike', tactic: 'Exfiltration', rel: 3, imp: 5, data: 0.5, days: 4 },
{ gap: 'USB autorun', tactic: 'Initial Access', rel: 1, imp: 3, data: 1, days: 1 },
{ gap: 'Router firmware', tactic: 'Persistence', rel: 2, imp: 4, data: 0, days: 3 },
];
const score = g => (g.rel * g.imp * g.data) / g.days;
const ranked = [...gaps].sort((a, b) => score(b) - score(a));
console.log('rank', 'gap'.padEnd(21), 'tactic'.padEnd(18), 'score');
ranked.forEach((g, i) => {
console.log(String(i + 1).padEnd(4), g.gap.padEnd(21), g.tactic.padEnd(18), score(g).toFixed(2));
});
const noData = gaps.filter(g => g.data === 0).map(g => g.gap);
console.log('Fix logging first:', noData.join(', '));
// A week of work: 5 days. Take the ranked list while days remain.
let left = 5;
const plan = [];
for (const g of ranked) {
if (g.data > 0 && g.days <= left) { plan.push(g); left -= g.days; }
}
console.log('This week:', plan.map(g => g.gap).join(' + '), '| days left', left);প্রথম সারি 1 Password spraying Credential Access 10.00: ৫ × ৪ × ১ ÷ ২ = ১০। ছোট কাজে বেশি লাভ। Router firmware-এর স্কোর 0.00, কারণ log-ই নেই, তাই আউটপুট বলছে Fix logging first: Router firmware. আগে দেখা নিশ্চিত করতে হবে। শেষ লাইন This week: Password spraying + Backup tampering + USB autorun | days left 0. তৃতীয়টি নিয়ে আপনার মানবিক বিচার লাগবে: USB কাজটি ছোট বলেই ঢুকেছে, relevance মাত্র ১। সূত্র সিদ্ধান্ত দেয় না, আলোচনায় সাহায্য করে।
Purple team — রক্ষক আর অনুমোদিত পরীক্ষক এক টেবিলে
Red team অনুমতি নিয়ে প্রতিপক্ষের আচরণ অনুকরণ করে। Blue team ধরার চেষ্টা করে। Purple team কোনো আলাদা রং নয়, দুই দল মিলে কাজ করার একটি ধরন। লক্ষ্য কাউকে হারানো নয়, ঘরটি সত্যিই সবুজ করা। পুরো কাজের সীমা লিখিত অনুমতিতে বাঁধা থাকে (পর্ব ৫০)।
| ধাপ | |
| ঘরের অক্ষর | |
| Log এলো? | |
| Alert এলো? | |
| Credential Access-এ tested |
- লক্ষ্য বাছাই। Gap তালিকার প্রথম নাম Password Spraying নেওয়া হলো। ঘরটি এখন L: log আছে, alert নেই।
- লিখিত অনুমতি। কোন পরিবেশ, কোন পরীক্ষামূলক অ্যাকাউন্ট, কোন সময়, কে দায়িত্বে, কখন থামতে হবে, সব লিখিত ও অনুমোদিত। বাস্তব গ্রাহক বা কর্মীর অ্যাকাউন্ট scope-এর বাইরে।
- Rule তৈরি। Blue team ওপরের ধাঁচের rule বসাল। ঘরটি A হলো: alert আছে, কিন্তু পরীক্ষিত নয়।
- নিয়ন্ত্রিত পরীক্ষা। অনুমোদিত পরীক্ষক শুধু পরীক্ষামূলক অ্যাকাউন্টে কয়েকটি ইচ্ছাকৃত ব্যর্থ login করলেন। Log এলো, alert এলো না। পরীক্ষা ছাড়া এই ফাঁক অজানা থাকত।
- ত্রুটি সংশোধন। দেখা গেল rule-এ field-এর নাম ভুল ছিল, log-এ নামটি অন্য। ঠিক করা হলো। এমন ছোট ভুলই “সবুজ” ঘরকে মিথ্যা করে দেয়।
- পুনঃপরীক্ষা। এবার ৪ মিনিটে alert এলো, playbook-ও চলল। ঘরটি T হলো। Credential Access-এ পরীক্ষিত ঘর ১/৪ থেকে ২/৪, আর মোট ৭/৩২ থেকে ৮/৩২ = ২৫%. ফলাফল দিনসহ লিখে রাখা হলো, কারণ log source বদলালে আবার পরীক্ষা লাগবে।
চেকলিস্ট বানালে যে বিপদ
| ফাঁদ | কেন ভুল | ভালো অভ্যাস |
|---|---|---|
| “১০০% সবুজ” লক্ষ্য | একটি technique-এর বহু রূপ আছে, একটি rule সব ধরে না | গুরুত্বপূর্ণ technique-এ গভীরতা মাপা |
| সবকিছুতে alert | Discovery-র অনেক কাজ প্রশাসকও করেন, ফলে alert-এর বন্যা | কোনোটি alert, কোনোটি hunting-এর জন্য রাখা |
| Vendor-এর লোগো দেখে সবুজ | পণ্য কেনা মানে আপনার পরিবেশে চালু ও পরীক্ষিত নয় | নিজের পরিবেশে পরীক্ষা |
| মানচিত্রই পুরো জগৎ | ATT&CK প্রকাশিত আচরণের ওপর দাঁড়ানো, নতুন ধরন আগে নেই | Threat model আর threat hunting পাশে রাখা |
| Attribution-এর লোভ | একই technique বহু দল ব্যবহার করে | “কে” নয়, “কী হচ্ছে” আগে |
| পুরোনো mapping | সংস্করণ বদলায়, যেমন Defense Evasion-এর ভাগ | Version লিখে রাখা, বছরে অন্তত দুবার দেখা |
পরীক্ষা ও ইন্টারভিউতে: Kill chain-এর ধাপগুলো কী? Reconnaissance, Weaponization, Delivery, Exploitation, Installation, C2, Actions on Objectives. Tactic আর technique-এর পার্থক্য? Tactic হলো কেন, technique হলো কীভাবে। ATT&CK কি vulnerability তালিকা? না, সেটি CVE-এর কাজ। ATT&CK আচরণের তালিকা। Pyramid of Pain-এর শীর্ষে কী? TTP. Purple team কী? অনুমোদিত আক্রমণ-অনুকরণ আর detection মিলিয়ে একসাথে কাজ, লক্ষ্য প্রতিরক্ষা উন্নত করা।
৯ · AI-এর যুগে মানচিত্র আঁকা
AI কয়েক সেকেন্ডে একটি incident রিপোর্টকে ATT&CK technique-এ ভাগ করে দিতে পারে, rule-এর খসড়াও দিতে পারে। এটি কাজের সহায়ক, কিন্তু এই ক্ষেত্রে তার ভুলও সূক্ষ্ম। ভুল ID দেখতে ঠিক সঠিক ID-র মতোই। পুরোনো সংস্করণের tactic, যেমন Defense Evasion, সে নির্দ্বিধায় লিখে দিতে পারে। একটি alert triage-এ অতিরিক্ত আত্মবিশ্বাসী উত্তরও দিতে পারে।
| AI-এর ভুল | কেন ক্ষতিকর | যাচাইয়ের উপায় |
|---|---|---|
| বানানো technique ID বা CVE নম্বর | রিপোর্টে ভুল তথ্য, ভুল পথে তদন্ত | প্রতিটি ID attack.mitre.org-এ খোলা |
| পুরোনো version-এর নাম | Mapping ভেঙে যায় | Version উল্লেখ করে যাচাই |
| প্রমাণ ছাড়া নির্দিষ্ট sub-technique | মিথ্যা নিশ্চয়তা | Log-এর লাইন দেখিয়ে যুক্তি চাওয়া |
| Alert “নিরীহ” বলে দেওয়া | আসল হামলা বাদ পড়তে পারে | Triage-এর সিদ্ধান্ত মানুষের হাতে |
| False positive কমাতে rule-এ বড় ব্যতিক্রম | Detection অন্ধ হয়ে যায় | Diff দেখা, পুনঃপরীক্ষা |
AI-কে রক্ষকের সহায়ক হিসেবে ব্যবহার করুন। আসল IP, ইউজারনেম, গ্রাহকের তথ্য বা token কখনো prompt-এ দেবেন না; আগে মুছে বা বদলে নিন।
AI-এর mapping হাতে পেলে — চেকলিস্ট
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিয়ে নিজে কিছুক্ষণ ভাবুন, তারপর “→ উত্তর” চাপুন।
প্র ০১“রক্ষকের একবার সফল হলেই চলে” — kill chain-এর এই দাবি কি প্রচলিত “আক্রমণকারীর একবার সফল হলেই চলে” কথাটির বিপরীত?
নিরাপত্তা জগতে একটি পুরোনো হতাশার কথা আছে: রক্ষককে সব দরজা পাহারা দিতে হয়, আক্রমণকারীর দরকার একটি খোলা দরজা। ২০১১ সালের গবেষণাপত্র এই ভাবনাকে উল্টে দেখে। লেখকেরা বলেন, একটি পূর্ণাঙ্গ হামলা বহু ধাপের কাজ, আর একটি প্রতিরোধই শিকল ভাঙতে পারে। তাঁদের দাবি ছিল, এই পথে রক্ষকও আক্রমণকারীর ওপর সুবিধা পেতে পারেন।
দুটি কথাই আংশিক সত্য, কারণ দুটি আলাদা জিনিসের কথা বলে। “একটি খোলা দরজা” কথাটি প্রথম ঢোকার ক্ষেত্রে সত্য। আর “একটি ভাঙা আংটা” কথাটি পুরো লক্ষ্যপূরণের ক্ষেত্রে সত্য। Phishing-এ একজন কর্মী ভুল করলেই হয়তো একটি ল্যাপটপ যাবে। কিন্তু গ্রাহকের ডেটা পেতে আরও অনেক কাজ বাকি।
গবেষণাপত্রের একটি সুন্দর উদাহরণ আছে। একই প্রচারণার তিনটি চেষ্টা, ডিসেম্বর, মার্চ আর জুনে। ডিসেম্বরে একটি নতুন zero-day এলেও আগের ধাপে email আটকে যায়। মার্চে প্রতিপক্ষ অন্য ধাপ বদলায়, কিন্তু পুরোনো exploit-ই ব্যবহার করে। অর্থাৎ zero-day একটি ধাপের পরিবর্তন মাত্র; বাকি ধাপে পুনরাবৃত্তি থাকলে সেটিই রক্ষকের সুযোগ। তবে সীমা আছে। একবার থামলেও প্রতিপক্ষ আবার আসবে, শিখবে। “একবার” তাই চিরকালের জন্য নয়, ওই একটি চেষ্টার জন্য। একই সাথে, শেষের ধাপে ধরা পড়লে আগে কী হয়েছে তা জানা এবং বন্ধ করা দরকার, নইলে একই পথে আবার ফিরে আসবে।
মূল উপলব্ধি: আক্রমণকারীর সুবিধা প্রথম ধাপে, রক্ষকের সুবিধা পুরো শিকলে। প্রতিরক্ষা মানে একটি দেয়াল নয়, পরপর অনেকগুলো সুযোগ তৈরি করা, আর প্রতিপক্ষের পুনরাবৃত্তিকে নিজের শক্তিতে বদলে ফেলা।
প্র ০২SolarWinds (২০২০) kill chain-এর কোন দুর্বলতা দেখায়, আর তখন রক্ষকের হাতে কী ছিল?
২০২০ সালের ডিসেম্বরে প্রকাশিত রিপোর্ট অনুযায়ী SolarWinds-এর Orion সফটওয়্যারের বৈধ update-এর ভেতরে ক্ষতিকর কোড পাওয়া যায়। মার্কিন সরকারি সংস্থা CISA জরুরি নির্দেশ জারি করে। নিরাপত্তা প্রতিষ্ঠান FireEye নিজের ঘটনা তদন্ত করতে গিয়েই এটি সামনে আনে।
Kill chain-এর দৃষ্টিতে এখানে Delivery ধাপটি অস্বস্তিকর। প্রচলিত ছকে email filter আর proxy-র কাজ ছিল বাইরের জিনিস ঠেকানো। এখানে জিনিসটি এসেছে বিশ্বস্ত সরবরাহকারীর স্বাক্ষরিত update হয়ে। সীমানা-কেন্দ্রিক ভাবনায় এই পথ “বৈধ”। Weaponization ধাপটিও আক্রমণকারীর নিজের জায়গায় নয়, সরবরাহকারীর build পরিবেশে ঘটেছে বলে রিপোর্টে বলা হয়।
তাহলে কি মডেল ব্যর্থ? পুরোপুরি নয়। ATT&CK-এ Supply Chain Compromise একটি technique, আর পরের আচরণগুলো অন্য ঘরে পড়ে। সুযোগ ছিল পরের ধাপে: server থেকে অস্বাভাবিক বাইরের যোগাযোগ, identity-র অস্বাভাবিক ব্যবহার, least privilege. প্রতিরক্ষার শিক্ষাগুলো পরে সাধারণ চর্চায় আসে: monitoring সফটওয়্যারের মতো উচ্চ-অধিকারের টুলের বাইরের যোগাযোগ সীমিত করা, সরবরাহকারীর ঝুঁকি যাচাই, build পরিবেশের সুরক্ষা। আক্রমণের পুনর্গঠন নয়, এই শিক্ষাটুকুই আমাদের দরকার। একটি ছোট প্রতিষ্ঠানও নিজেকে এই প্রশ্ন করতে পারে: আমাদের সবচেয়ে বেশি অধিকারের সফটওয়্যারটি যদি কাল থেকে বিশ্বাসযোগ্য না থাকে, তাহলে আমরা কীভাবে জানব, আর ক্ষতি কতদূর ছড়াবে? বিস্তারিত পর্ব ৪৮ (Supply chain নিরাপত্তা) আর পর্ব ৬৫-তে।
মূল উপলব্ধি: “ভেতরের” বা “বিশ্বস্ত” কোনো জিনিসকে প্রমাণ ছাড়া নিরাপদ ধরা বিপদ। মানচিত্র যত ভালোই হোক, তার অনুমানগুলো প্রশ্ন করতে হয়। প্রতিটি মডেলের পাশে লিখে রাখুন: এটি কী ধরে নিচ্ছে? Kill chain ধরে নেয় বাইরের জিনিস সন্দেহজনক আর ভেতরের জিনিস চেনা। যেখানে এই অনুমান খাটে না, সেখানে প্রতিরক্ষা সরিয়ে নিতে হয় পরের ধাপে, অর্থাৎ অধিকার সীমিত করা, যোগাযোগ দেখা আর অস্বাভাবিক আচরণ ধরায়।
প্র ০৩Hash আর IP যদি এত সহজে বদলানো যায়, threat intelligence ফিডে এত IOC থাকে কেন? এগুলো কি সময় নষ্ট?
Pyramid of Pain প্রায়ই ভুল বোঝা হয়। ২০১৩ সালে David Bianco দেখিয়েছিলেন, indicator-এর প্রশ্ন শুধু “নির্ভুল কি না” নয়, “প্রতিপক্ষের কতটা ক্ষতি করে”। তিনি বলেননি নিচের স্তর ফেলে দিন।
Hash-এর একটি গুণ আছে যা ওপরের স্তরে নেই: প্রায় শূন্য false positive. মিলে গেলে ফাইলটি ঠিক সেটিই। সক্রিয় incident-এ এটি অমূল্য। একটি আক্রান্ত যন্ত্রে পাওয়া ফাইলের hash দিয়ে কয়েক মিনিটে পুরো প্রতিষ্ঠান খুঁজে দেখা যায়, আর কয়টি যন্ত্র আক্রান্ত তা জানা যায়। একে বলে scoping. একইভাবে, চেনা ক্ষতিকর IP থেকে সংযোগ পুরোনো log-এ খুঁজলে জানা যায় ঘটনাটি কবে শুরু। আর Log4Shell-এর মতো জরুরি পরিস্থিতিতে, যখন সবাই patch নিয়ে ব্যস্ত, IOC ক্ষণিকের বর্ম হতে পারে।
২০১১ সালের গবেষণাপত্রও indicator-কে atomic, computed আর behavioral, এই তিন ভাগে ভাগ করে, এবং দেখায় অর্থনৈতিক কারণে প্রতিপক্ষ tool আর infrastructure পুনরায় ব্যবহার করে। তাই নিম্ন স্তরের সূচকও কখনো কখনো কাজে লাগে।
সমস্যা হয় তিন জায়গায়। ফিডের মেয়াদ না দেখা; পুরোনো IP আজ হয়তো নিরীহ কারও। অন্ধভাবে block করা; শেয়ার করা cloud ঠিকানায় বৈধ সেবা বন্ধ হতে পারে। আর শুধু IOC-তে ভরসা করে “আমরা threat intelligence করছি” ভাবা। প্রতিটি IOC-এর সাথে তাই উৎস, তারিখ আর মেয়াদ রাখা ভালো। কোন IOC কতদিন কাজে লেগেছে, সেটিও মেপে দেখা যায়। যে ফিড থেকে কখনো কোনো সত্যিকার ঘটনা ধরা পড়েনি, তা রাখার যুক্তি প্রশ্ন করা উচিত।
মূল উপলব্ধি: নিচের স্তর দ্রুত ও নিশ্চিত, ওপরের স্তর টেকসই। ভালো দল দুটোই ব্যবহার করে, প্রতিটিকে তার কাজে। IOC খোঁজার জন্য, TTP ধরার জন্য। পর্ব ৫৭-এ এই ভাগ আরও পরিষ্কার হবে।
প্র ০৪ATT&CK-এ ১০০% coverage কি সম্ভব, এবং সেটি চাওয়া কি ভালো?
শুনতে লক্ষ্যটি আকর্ষণীয়, বোর্ড-মিটিংয়ের স্লাইডে আরও আকর্ষণীয়। কিন্তু সংখ্যাগুলো দেখুন। v20-এ শুধু Enterprise-এই ২২৭টি technique আর ৪৭৯টি sub-technique. প্রতিটির একাধিক procedure আছে, আর প্রতি ছয় মাসে তালিকা বদলায়।
প্রথম সমস্যা অর্থের। একটি ঘরে একটি rule থাকলেই ঘরটি সবুজ, অথচ ওই technique-এর অন্য procedure হয়তো ধরা পড়ে না। “Detection আছে” আর “বেশিরভাগ রূপ ধরা পড়ে” এক কথা নয়। দ্বিতীয় সমস্যা গোলমালের। Discovery ধরনের অনেক technique সাধারণ প্রশাসকের দৈনন্দিন কাজের সাথে মেলে। সবগুলোতে alert বসালে analyst-রা ক্লান্ত হয়ে পড়বেন, আর আসল alert হারিয়ে যাবে। তৃতীয় সমস্যা গুরুত্বের। সব ঘরের ওজন সমান নয়। আপনার প্রতিষ্ঠানে যে platform নেই, সেই ঘর ভরে লাভ নেই। আর কিছু ঘরে শুধু prevention-ই যুক্তিসঙ্গত, যেমন আপনার network-এর বাইরে ঘটা Resource Development.
MITRE নিজেও ATT&CK-কে পূর্ণাঙ্গ তালিকা বা স্কোরকার্ড হিসেবে নয়, বরং আচরণের জ্ঞানভান্ডার হিসেবে তুলে ধরে। মূল্যায়নেও vendor-কে “স্কোর” দেওয়ার চেয়ে আচরণ দেখানোর দিকে জোর আসে, যদিও বিপণনে তা প্রায়ই নম্বর হয়ে যায়। ভালো দল তাই threat intelligence থেকে নিজের জন্য গুরুত্বপূর্ণ ছোট তালিকা বানায়, সেখানে গভীরতা বাড়ায়, পরীক্ষা করে, আর দিন লিখে রাখে। পরীক্ষার ফল চিরকাল টেকে না। Log source বদলালে বা সফটওয়্যার update হলে একটি সবুজ ঘর নীরবে অকেজো হতে পারে, তাই পুরোনো পরীক্ষার তারিখ নিজেই একটি ঝুঁকির সংকেত।
মূল উপলব্ধি: মাপকাঠি লক্ষ্য হয়ে গেলে সে আর ভালো মাপকাঠি থাকে না। প্রশ্নটি “কত শতাংশ?” নয়, “আমাদের গুরুত্বপূর্ণ আচরণগুলো পরীক্ষিতভাবে ধরা পড়ে কি?” ২২% পরীক্ষিত, ৮০% অপরীক্ষিত সবুজের চেয়ে অনেক সৎ সংখ্যা।
প্র ০৫v19-এ Defense Evasion ভেঙে Stealth আর Defense Impairment হলো। একটি কাঠামো বদলালে রক্ষকের কী করা উচিত?
ATT&CK জীবন্ত দলিল, পাথরে খোদাই নয়। ইতিহাসে আগেও বড় বদল এসেছে। ২০১৯ সালের এপ্রিলে v4-এ Impact tactic যোগ হয়। ২০২০ সালের জুলাইয়ে sub-technique আসে। একই বছর অক্টোবরে v8-এ PRE-ATT&CK একীভূত হয়ে Reconnaissance আর Resource Development tactic হয়। Unified Kill Chain-ও এই বদল মেনে নিজের নাম হালনাগাদ করেছে। ২০২৬ সালের এপ্রিলে v19 দীর্ঘদিনের Defense Evasion-কে দুই ভাগ করে, আর MITRE-এর হালনাগাদ পাতা এটিকে ওই সংস্করণের বড় পরিবর্তনগুলোর একটি বলে উল্লেখ করেছে।
রক্ষকের জন্য এর ব্যবহারিক মানে কী? আপনার SIEM rule-এর tag, coverage map, রিপোর্ট টেমপ্লেট, playbook, সবখানে পুরোনো নাম থাকতে পারে। স্বয়ংক্রিয় গণনা পুরোনো নাম না চিনলে একটি tactic হঠাৎ “শূন্য” দেখাতে পারে, অথচ detection বদলায়নি। আবার পুরোনো ID নতুন নামের সাথে যুক্ত থাকলে (Stealth পেয়েছে TA0005) বিভ্রান্তি আরও বাড়ে।
তাই কিছু অভ্যাস জরুরি। প্রতিটি mapping-এ version লিখুন। MITRE-এর changelog পড়ে সংস্করণ বদলের ছোট পরিকল্পনা করুন, হুট করে সব বদলাবেন না। Rule-এর tag ID-ভিত্তিক হোক, তবে একটি রূপান্তর-সারণি রাখুন। পুরোনো রিপোর্ট বদলাবেন না, বরং সেদিনের version-সহ রেখে দিন, কারণ সেগুলো ঐতিহাসিক রেকর্ড।
ধারণাগত লাভও আছে। “লুকিয়ে থাকা” আর “প্রতিরক্ষা নষ্ট করা” আসলে আলাদা আচরণ। দ্বিতীয়টি প্রায়ই অনেক বেশি স্পষ্ট চিহ্ন রেখে যায়, যেমন EDR বন্ধ হওয়া বা log থেমে যাওয়া। এগুলোর জন্য উচ্চ-অগ্রাধিকারের alert রাখা অর্থবহ।
মূল উপলব্ধি: কাঠামো মানচিত্র, আসল ভূখণ্ড নয়। মানচিত্র আপডেট হবেই। ভালো দল আগে থেকে সেই বদলের জন্য প্রস্তুত থাকে, আর প্রতিটি দাবির পাশে তারিখ ও সংস্করণ লিখে রাখে।
অনুশীলন
হিসাব, বিশ্লেষণ, পূর্বানুমান আর সমালোচনা। Code block-এ নিজে সংখ্যা বদলে মিলিয়ে নিতে পারেন।
-
হিসাব করুন: একটি toy মডেলে তিনটি ধাপে থামার সম্ভাবনা ০.৫০, ০.৪০ আর ০.২৫, স্বাধীন ধরে নিন। (ক) লক্ষ্যে পৌঁছানোর সম্ভাবনা কত? (খ) ১০০টি চেষ্টায় গড়ে কয়টি সফল? (গ) দ্বিতীয় ধাপের মান ০.৬০ করলে কত?
(ক) ০.৫০ × ০.৬০ × ০.৭৫ = ০.২২৫, অর্থাৎ ২২.৫%. (খ) গড়ে ২২.৫টি। (গ) ০.৫০ × ০.৪০ × ০.৭৫ = ০.১৫, অর্থাৎ ১৫%. একটি ধাপ উন্নত করায় সফল চেষ্টা এক-তৃতীয়াংশ কমল। মনে রাখবেন, স্বাধীনতার অনুমান বাস্তবে পুরোপুরি খাটে না।
-
মানচিত্রে বসান: তিনটি পর্যবেক্ষণের kill chain ধাপ আর ATT&CK Enterprise tactic বলুন, সাথে একটি প্রতিরক্ষা। (ক) একটি ল্যাপটপ নিয়মিত বিরতিতে একটি একেবারে নতুন domain-এর সাথে যোগাযোগ করছে। (খ) Backup সার্ভারের snapshot হঠাৎ মুছে যাচ্ছে। (গ) একজন বৈধ কর্মীর অ্যাকাউন্ট থেকে রাতে অস্বাভাবিক পরিমাণ ডেটা cloud storage-এ যাচ্ছে।
(ক) ধাপ C2; tactic Command and Control; প্রতিরক্ষা DNS log নজরদারি, egress নিয়ম, যন্ত্র আলাদা করা।
(খ) ধাপ Actions on Objectives; tactic Impact, প্রেক্ষিত অনুযায়ী Defense Impairment-ও ভাবা যায়; প্রতিরক্ষা immutable backup, আলাদা admin পরিচয়, মুছে ফেলার alert (পর্ব ৩৪)।
(গ) ধাপ Actions on Objectives; tactic Exfiltration; প্রতিরক্ষা DLP, least privilege, অস্বাভাবিকতার সতর্কতা। লক্ষ করুন, ভেতরের মানুষ হলে আগের ধাপগুলো নাও থাকতে পারে। Kill chain এখানে দুর্বল, ATT&CK তুলনায় বেশি কাজে লাগে।
-
আউটপুট অনুমান করুন:
rule_resilience.js-এbehaviourRule-এরlimit = 5বদলেlimit = 6করলেshared officeসারি আর শেষ লাইন কী হবে? আরlimit = 7করলে শেষ লাইন কী? আগে ভাবুন, তারপর চালান।limit = 6: অফিসে ব্যবহারকারী ৫ জন, তাই ওই সারিতে behaviour rule
0. দুটি আসল চেষ্টায় ৬টি করে অ্যাকাউন্ট, তাই দুটোই ধরা পড়ে। শেষ লাইনbehaviour precision 1.00 recall 1.00.limit = 7: কিছুই ধরা পড়ে না।
hitsখালি, তাই precision-এ ০ ÷ ০ হয়ে আসেprecision NaN recall 0.00. শিক্ষা: এই ছোট নমুনায় ৬ নিখুঁত মনে হলেও আসল চেষ্টাটি ৫টি অ্যাকাউন্টে হলে ধরা পড়ত না। Threshold বেশি বাড়ালে recall পড়ে, আর কম হলে precision পড়ে। -
সমালোচনা করুন: একজন ব্যবস্থাপক বললেন, “আমাদের ATT&CK coverage ৮০%, পণ্যের dashboard-এ সব সবুজ, তাই এই বছর নিরাপত্তায় নতুন কিছু লাগবে না।” ব্যবস্থাপককে সম্মান রেখে আপনি কোন চারটি প্রশ্ন করবেন? একটি ভালো পরিবর্তিত মাপকাঠিও প্রস্তাব করুন।
প্রশ্নগুলো হতে পারে: (১) ৮০% মানে কী, log, alert, না পরীক্ষিত alert? (২) কোন version আর কোন platform-এর ওপর হিসাব? (৩) আমাদের প্রতিষ্ঠানের সবচেয়ে সম্ভাব্য হামলার আচরণগুলো কি এই ৮০%-এর ভেতরে? (৪) শেষ কবে নিজের পরিবেশে অনুমোদিত পরীক্ষা হয়েছে, আর alert পেলে সাড়া দিতে কতক্ষণ লাগে?
ভালো মাপকাঠি: “গুরুত্বপূর্ণ ২০টি technique-এর কতটি গত ৬ মাসে পরীক্ষিত”, সাথে পরীক্ষায় alert আসার গড় সময়। Detection-এর পাশে prevention আর response-ও আলাদা দেখানো উচিত।
নিজেকে যাচাই করুন
ভুল হলে কারণসহ ব্যাখ্যা পাবেন, আবার চেষ্টাও করতে পারবেন।
ক্রমPyramid of Pain-এর স্তরগুলো সাজান: সবচেয়ে কম কষ্ট থেকে সবচেয়ে বেশি কষ্ট (▲▼ চেপে সরান)
- Hash values
- IP addresses
- Domain names
- Network / host artifacts
- Tools
- TTPs
Lockheed Martin Cyber Kill Chain-এ আক্রান্ত যন্ত্র বাইরের নিয়ন্ত্রকের সাথে যোগাযোগ করে কোন ধাপে?
- Delivery
- Installation
- Command and Control
- Weaponization
MITRE ATT&CK-এ tactic বলতে কী বোঝায়?
- কোনো নির্দিষ্ট দল বাস্তবে যেভাবে কাজ করেছে
- আক্রমণকারীর সেই মুহূর্তের উদ্দেশ্য
- Software-এর জানা ত্রুটির নম্বর
- একটি প্রতিরক্ষা-ব্যবস্থার নাম
কোনটি Cyber Kill Chain-এর একটি পরিচিত সীমাবদ্ধতা?
- এটি হামলার পরের ধাপ ছাড়া কিছু দেখে না
- এতে সাতটির বেশি ধাপ আছে বলে মনে রাখা কঠিন
- এটি শুধু cloud পরিবেশের জন্য বানানো
- Insider threat মডেলটিতে ভালোভাবে ধরা পড়ে না
একটি দল শুধু ক্ষতিকর IP-এর blocklist হালনাগাদ করে। Pyramid of Pain অনুযায়ী প্রতিপক্ষের ওপর এর প্রভাব কেমন?
- প্রতিপক্ষকে নতুন আচরণ শিখতে হয়
- প্রভাব কম, কারণ প্রতিপক্ষ সহজেই ঠিকানা বদলাতে পারে
- কোনো ক্ষেত্রেই কোনো কাজে লাগে না
- সব হামলা স্থায়ীভাবে বন্ধ হয়
একটি কাল্পনিক প্রতিষ্ঠানের ২০টি গুরুত্বপূর্ণ technique-এর মধ্যে ৫টিতে পরীক্ষিত alert, আরও ৭টিতে অপরীক্ষিত alert, আর ৩টিতে শুধু log আছে। পরীক্ষিত coverage কত?
- ২৫%
- ৬০%
- ৭৫%
- ৩৫%
Purple team চর্চার মূল লক্ষ্য কোনটি?
- Blue team-এর ভুল ধরে শাস্তি দেওয়া
- অনুমতি ছাড়াই বাস্তব পরিবেশে হঠাৎ পরীক্ষা চালানো
- অনুমোদিত পরীক্ষা ও detection মিলিয়ে ফাঁক খুঁজে সারানো
- Coverage map-এ যত বেশি সম্ভব ঘর সবুজ করা
শব্দকোষ
লেখার মধ্যে ডটেড দাগ দেওয়া শব্দে মাউস রাখুন বা চাপুন, অর্থ দেখাবে। এই পর্বের সব নতুন শব্দ এখানে একসাথে:
মনে রাখুন
- Kill chain-এর সাত ধাপ: Reconnaissance, Weaponization, Delivery, Exploitation, Installation, C2, Actions on Objectives. প্রতিটি ধাপ রক্ষকের একটি সুযোগ।
- প্রতি ধাপে ভাবুন: detect, deny, disrupt, degrade, deceive, contain. ফাঁকা ঘরই আপনার পরের কাজ।
- ATT&CK: tactic কেন, technique কীভাবে, procedure বাস্তবে কেমন। Version সবসময় লিখুন।
- Pyramid of Pain: IOC দ্রুত, TTP টেকসই। দুটোই দরকার, প্রতিটি নিজের কাজে।
- Coverage মানে পরীক্ষিত আচরণ, সবুজ রং নয়। হামলার মানচিত্র ব্যবহার করুন প্রতিরক্ষার জন্য, লিখিত অনুমতির ভেতরে।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- পর্ব ০৬ · আইন আর নৈতিকতা — অনুমতি, দায়িত্বশীল প্রকাশ আর বাংলাদেশের আইনপরবর্তী পর্বকোনটি বৈধ, কোনটি অপরাধ, আর লিখিত অনুমতি কেন জরুরি।
- সাইবার নিরাপত্তা · কোর্স হোম৮০টি পর্বপুরো কোর্সের রোডম্যাপ, কোন পর্ব কখন।
- Network নিরাপত্তার ভিত্তিপাশের ট্র্যাকFirewall, egress আর network-এর সাধারণ প্রতিরক্ষা।
- Centralized loggingপাশের ট্র্যাকDetection-এর কাঁচামাল, log এক জায়গায় আনা।
- Incident managementপাশের ট্র্যাকধরা পড়ার পর দল কীভাবে সাড়া দেয়।