এই পর্বে যা শিখবেন
- Port, TCP, DNS, HTTP, TLS আর Windows ও Linux log-এর প্রশ্নের সংক্ষিপ্ত, যুক্তিসহ উত্তর দেওয়া
- নমুনা log থেকে কী ঘটেছে তা বের করা, আর কী প্রমাণ হয়নি তা-ও বলা
- সাতটি alert পরিস্থিতিতে আগে কী দেখবেন, কী দেখলে মত বদলাবে, আর কখন escalate করবেন
- Detection rule-এর ধারণা বলা, আর ঘটনাকে MITRE ATT&CK-এ মেলানো
- চাকরির অভিজ্ঞতা ছাড়াও সততার সাথে নিজের দক্ষতা দেখানো, আর STAR-এ আচরণগত উত্তর গোছানো
এই পাতার ডেটা সম্পর্কে: সব log, নাম, সময় আর ঠিকানা বানানো। ঠিকানাগুলো নথির জন্য সংরক্ষিত পরিসরের (203.0.113.0/24, 198.51.100.0/24), আর ডোমেইন example.com ধরনের। চলার যোগ্য ব্লকগুলো শুধু নিজের ভেতরের নমুনা পড়ে, কোনো আসল system ছোঁয় না। তাদের আউটপুট আসলেই চালিয়ে নেওয়া। প্রশ্নগুলো কোনো নির্দিষ্ট প্রতিষ্ঠান বা পরীক্ষা থেকে নেওয়া নয়। এ ধরনের প্রশ্ন প্রায়ই আসে, তবে আপনার ইন্টারভিউ ভিন্ন হতে পারে।
মহল্লার পাহারাদার নিয়োগের সময় কেউ শুধু জিজ্ঞেস করেন না, “তালা কত রকম হয়?” জিজ্ঞেস করেন, “রাত দুইটায় গলির শেষ বাড়ির গেট খোলা দেখলেন। কী করবেন? কাকে ডাকবেন? কখন ভাববেন, ব্যাপারটি কিছুই নয়?” SOC ইন্টারভিউও অনেকটা তেমন। সংজ্ঞা দরকার, তবে আসল কথা হলো সন্দেহের মুখে আপনি কীভাবে ভাবেন।
১ · SOC ইন্টারভিউতে কী দেখা হয়
রিভিশন: পর্ব ৬০ · SOC পরিচালনা, পর্ব ৫৫ · নিরাপত্তার log, পর্ব ৬১ · Incident response
সাধারণত এই ইন্টারভিউতে পাঁচটি জিনিস পরখ করা হয়। ধরন প্রতিষ্ঠান ভেদে আলাদা হতে পারে, কারণ SOC-এর আকার আর দায়িত্ব সবখানে এক নয়।
| যা দেখা হয় | কীভাবে দেখা হয় | দুর্বল উত্তর | ভালো উত্তর |
|---|---|---|---|
| ভিত্তি | Port, handshake, DNS, event ID | মুখস্থ তালিকা | তথ্যটি log-এ কোথায় দেখা যায়, তাও বলা |
| Log পড়া | কয়েকটি লাইন দেখিয়ে “কী হলো?” | এক লাইন দেখেই রায় | সময়রেখা, তারপর অনুমান আর প্রমাণ আলাদা |
| Triage-এর বিচার | “এই alert এলে আগে কী করবেন?” | সোজা account বন্ধ বা সোজা close | প্রসঙ্গ, প্রভাব, আর মত বদলানোর শর্ত |
| যোগাযোগ | Note লেখা, handover, escalate করা | “সন্দেহজনক লাগছে” | কী দেখেছি, কী দেখিনি, কেন পাঠাচ্ছি |
| সততা ও সীমা | “জানেন না, তখন?”, অনুমতির প্রশ্ন | বানিয়ে বলা, নিজের ক্ষমতার বাইরে কাজ | “জানি না, এভাবে জানব”, আর অনুমতি ছাড়া হাত না দেওয়া |
সব পরিস্থিতির জন্য একটি কাঠামো হাতে রাখুন। এটি ছাড়া উত্তর এলোমেলো হয়, আর এটি থাকলে অচেনা alert-এও কথা গুছিয়ে বলা যায়।
চার প্রশ্নের triage কাঠামো
What I see, what I check first, what would change my mind, the decision
Verdict তিন রকম (পর্ব ৬০): true positive মানে আসল ক্ষতিকর ঘটনা, false positive মানে rule ভুল করেছে, আর benign positive মানে rule ঠিক ধরেছে, কিন্তু কাজটি অনুমোদিত। এই ভাগ ইন্টারভিউতে মুখে রাখুন।
প্র ১“SOC analyst সারাদিন কী করেন?” — এক মিনিটে বলুন। (সহজ)
উত্তর: সতর্কতা দেখেন, আসল না ভুল তা বোঝেন, প্রসঙ্গ জোড়েন, আর প্রমাণসহ সিদ্ধান্ত লেখেন। পথটি হলো triage, enrichment, তদন্ত, escalation, closure. Alert নিজে প্রমাণ নয়, শুধু একটি সন্দেহ। সাথে shift-এর handover আর rule-এর ফিডব্যাকও কাজের অংশ।
ফলো-আপ: “Severity আর priority?” — Severity বলে ঘটনা সত্যি হলে কতটা গুরুতর। Priority বলে কোনটি আগে ধরা হবে, আর তাতে সম্পদের গুরুত্ব যোগ হয়।
প্র ২যে প্রশ্নের উত্তর জানেন না, সেখানে কী বলবেন? (সহজ)
উত্তর: তিন অংশে: যা জানি, যা জানি না, কীভাবে জানব। যেমন: “এই event ID-টি মনে নেই। জানি এটি Security log-এর, তাই Microsoft-এর নথি দেখে নিশ্চিত হব, আর নিজের lab-এ ঘটনাটি ঘটিয়ে দেখব।” SOC-এ বানিয়ে বলার দাম অনেক, কারণ আপনার note দেখে অন্যজন সিদ্ধান্ত নেন।
প্র ৩False positive আর benign positive আলাদা করা কেন জরুরি? (মাঝারি)
উত্তর: সমাধান আলাদা বলে। False positive হলে rule-এর যুক্তি ভুল, তাই rule ঠিক করতে হয়। Benign positive হলে rule ঠিক ছিল, যেমন IT দলের অনুমোদিত স্ক্রিপ্ট, তাই মেয়াদসহ ব্যতিক্রম লিখতে হয়। দুটিকে এক বললে rule হয় অকারণে দুর্বল হয়, নয়তো একই আওয়াজ বারবার আসে।
ফলো-আপ: “False negative?” — ঘটনা ঘটেছে, alert আসেনি। Queue-তে এটি দেখা যায় না, তাই মহড়া আর threat hunting লাগে।
২ · ভিত্তির drill — port, TCP, DNS, HTTP আর TLS
রিভিশন: পর্ব ২১, পর্ব ২৪, পর্ব ২৬, পর্ব ১২, TCP সংযোগ, DNS, HTTP, Networking ইন্টারভিউ
এখানে প্রতিটি উত্তরের সাথে একটি বাড়তি বাক্য যোগ করুন: “এটি log-এ এভাবে দেখা যায়।” এতেই নেটওয়ার্কের ক্লাসের উত্তর SOC-এর উত্তর হয়ে ওঠে।
| Port | সেবা | Transport | SOC-এর চোখে |
|---|---|---|---|
| 22 | SSH | TCP | বাইরে খোলা থাকলে ব্যর্থ login-এর ভিড় |
| 25 | SMTP | TCP | সাধারণ PC থেকে সরাসরি গেলে অস্বাভাবিক |
| 53 | DNS | UDP, TCP | Resolver ছাড়া সরাসরি বাইরে গেলে দেখুন |
| 80, 443 | HTTP, HTTPS | TCP; HTTP/3 UDP 443 | ৪৪৩-এ যা যায়, সবই web নয় |
| 88 | Kerberos | TCP, UDP | Domain controller-এর দিকে স্বাভাবিক |
| 123 | NTP | UDP | ঘড়ি মিললে তবেই সময়রেখা মেলে |
| 389, 636 | LDAP, LDAPS | TCP | অস্বাভাবিক যন্ত্র থেকে বড় query দেখুন |
| 445 | SMB | TCP | PC থেকে PC-তে হলে lateral movement-এর প্রশ্ন |
| 3389 | RDP | TCP, UDP | Logon type 10-এর সাথে মিলিয়ে দেখুন |
| 3306, 5432 | MySQL, PostgreSQL | TCP | Internet থেকে সরাসরি পৌঁছালে ভুল সেটআপ |
এবার দেখুন, একজন কর্মী একটি HTTPS সাইট খুললে কোন log কী দেখে। প্রশ্নটি এ রকম হতে পারে: “portal.example.com খোলার সময় নেটওয়ার্কে কী ঘটে, আর আপনি কোন log-এ কী পাবেন?” সব সারি বানানো।
| স্তর | |
| কে দেখে | |
| বিষয়বস্তু দেখা যায়? |
- DNS. যন্ত্র আগে নাম থেকে ঠিকানা জানে। সাধারণ DNS-এ resolver-এর log বলে কে কোন নাম চেয়েছে। DNS over HTTPS ব্যবহার হলে এই log নিজের resolver-এ না-ও আসতে পারে।
ttl=300মানে উত্তর ৩০০ সেকেন্ড মনে রাখা যাবে। - TCP handshake. SYN, SYN-ACK, ACK. তিনটি মিললে সংযোগ হয়েছে। শুধু SYN থাকলে উত্তর আসেনি। SYN-এর পরে RST এলে ওই port-এ কেউ শুনছে না।
- NAT. ভেতরের
10.0.4.21বাইরে198.51.100.5হয়ে গেল। তাই বাইরের log-এর একটি ঠিকানা মানে একজন মানুষ নয়। ভেতরের যন্ত্র জানতে সময় আর port ধরে NAT log মেলাতে হয়। - TLS. TLS 1.3-এ certificate-ও এনক্রিপ্ট করা থাকে, তাই বাইরের sensor সেটি দেখে না। ClientHello-র SNI-তে নাম খোলা থাকে, যদি না Encrypted Client Hello ব্যবহার হয়।
- HTTP. Path, status আর user দেখা যায় শুধু সেখানে, যেখানে TLS খোলে: server, reverse proxy বা অনুমোদিত proxy. নিচের দুটি প্রশ্নে এর ব্যবহার দেখবেন।
- শেষ. লেখা না দেখলেও পরিমাণ, সময় আর ছন্দ দেখা যায়। এনক্রিপ্ট করা ট্রাফিকেও তাই SOC অন্ধ নয়। অংশ ৬-এর beaconing এই ধারণার ওপরই দাঁড়িয়ে।
প্র ৪TCP আর UDP-র পার্থক্য কী? DNS কেন দুটোই ব্যবহার করে? (সহজ)
উত্তর: TCP আগে সংযোগ গড়ে, ক্রম আর পুনঃপ্রেরণ সামলায়। UDP সংযোগ ছাড়াই পাঠায়, তাই দ্রুত আর হালকা। DNS-এর ছোট প্রশ্নে সাধারণত UDP যথেষ্ট। উত্তর বড় হলে বা zone transfer-এ TCP লাগে। তাই firewall-এ TCP 53 বন্ধ করলে কিছু সাধারণ DNS কাজও ভাঙতে পারে।
ফলো-আপ: “UDP-তে উৎস ঠিকানা কতটা বিশ্বাসযোগ্য?” — কম। Handshake নেই, তাই জাল ঠিকানা সহজ। এই কারণেই পর্ব ২৮-এর reflection হয়।
প্র ৫Flow log-এ দেখলেন শুধু SYN, কোনো SYN-ACK নেই। অন্য সারিতে SYN-এর পরে RST. দুটির মানে কী? (সহজ)
উত্তর: প্রথমটিতে উত্তরই আসেনি: firewall ফেলে দিচ্ছে, পথ নেই, অথবা host বন্ধ। দ্বিতীয়টিতে host বেঁচে আছে, কিন্তু ওই port-এ কেউ শুনছে না। এক উৎস থেকে অল্প সময়ে অনেক port-এ এমন সারি এলে সেটি scan-এর লক্ষণ হতে পারে। তবে নিজের vulnerability scanner-ও এমন করে, তাই আগে অনুমোদিত scanner-এর তালিকা দেখুন।
প্র ৬DNS log থেকে আপনি কী কী সন্দেহ করতে পারেন? (মাঝারি)
উত্তর: চারটি সাধারণ চিহ্ন। নতুন বা বিরল ডোমেইন, যা এক-দুটি যন্ত্রই চায়। অল্প সময়ে অনেক NXDOMAIN, মানে নাম নেই, যা অনেক সময় ভুল config-ও হয়। একই ডোমেইনের নিচে বহু লম্বা, এলোমেলো subdomain, যা DNS দিয়ে তথ্য পাঠানোর চিহ্ন হতে পারে। আর নিয়মিত ছন্দে একই নাম চাওয়া। প্রতিটির নিরীহ ব্যাখ্যাও আছে, যেমন CDN আর antivirus-এর অদ্ভুত নাম।
ফলো-আপ: “Resolver সব দেখে?” — না। DNS over HTTPS বা সরাসরি বাইরের resolver ব্যবহার হলে দেখে না। তাই নীতিতে অনুমোদিত resolver ঠিক করে দেওয়া হয়।
প্র ৭৪০১ আর ৪০৩-এর পার্থক্য কী? কোন HTTP status একসাথে দেখলে আপনার ভ্রু কুঁচকাবে? (সহজ)
উত্তর: ৪০১: পরিচয় প্রমাণ হয়নি। ৪০৩: পরিচয় জানা, কিন্তু অনুমতি নেই। এক উৎস থেকে অনেক ৪০১-এর পরে একটি ২০০ মানে login অনুমানের প্রশ্ন। অনেক ৪০৪ মানে অচেনা path খোঁজা হতে পারে। ৪০৩-এর পরে ক্রমিক id-তে ২০০ এলে পর্ব ৩৮-এর access control-এর প্রশ্ন আসে।
ফলো-আপ: “Log-এর User-Agent বিশ্বাস করবেন?” — না। Client নিজে লেখে। X-Forwarded-For-ও শুধু নিজের proxy বসালে তবেই বিশ্বাসযোগ্য।
প্র ৮সাইটে তালা চিহ্ন আছে। তাহলে কি সাইটটি নিরাপদ? TLS কী দেয়, কী দেয় না? (সহজ)
উত্তর: TLS পথের গোপনীয়তা আর অখণ্ডতা দেয়, আর server-এর নামের প্রমাণ দেয়। সাইটের মালিক সৎ, এমন প্রমাণ দেয় না। একটি নকল সাইটও নিজের ডোমেইনের জন্য certificate পেতে পারে। তাই phishing-এর পাতায়ও তালা থাকতে পারে, আর ডোমেইনটিই আসল প্রশ্ন (পর্ব ৫৩)।
ফলো-আপ: “এনক্রিপ্ট করা ট্রাফিকে SOC কী পায়?” — নাম, ঠিকানা, পরিমাণ, সময়, ছন্দ। এ ছাড়া endpoint-এ EDR আর প্রতিষ্ঠানের অনুমোদিত proxy.
প্র ৯Encoding, encryption আর hashing-এর পার্থক্য কী? Log-এ Base64 দেখলে কী ভাববেন? (সহজ)
উত্তর: Encoding শুধু রূপ বদলায়, চাবি লাগে না। Encryption চাবি ছাড়া পড়া যায় না, আর চাবি দিয়ে ফেরানো যায়। Hash একমুখী, মূল লেখা ফেরানোর জন্য নয়, অখণ্ডতা যাচাইয়ের জন্য। Base64 গোপনীয়তা দেয় না। Process-এর command line-এ লম্বা Base64 থাকলে সেটি একটি সংকেত, রায় নয়। অনেক বৈধ management টুলও এমন করে।
প্র ১০203.0.113.50 থেকে ব্যর্থ login এসেছে। আপনি কি বলতে পারেন, একজন মানুষ এটি করছেন? (মাঝারি)
উত্তর: না। NAT, VPN বা mobile network-এর একটি ঠিকানার পেছনে বহু মানুষ থাকতে পারেন, আর একজন মানুষ বহু ঠিকানা ব্যবহার করতে পারেন। IP-র reputation সাহায্য করে, তবে মালিকানা প্রমাণ করে না। তাই বলি “এই উৎস”, “এই মানুষ” নয়। ঘড়িও দেখি: কোন log UTC-তে, কোনটি +0600-তে। ছয় ঘণ্টার ভুলে পুরো সময়রেখা উল্টে যেতে পারে।
৩ · Windows আর Linux log — event ID, logon type, auth log
রিভিশন: পর্ব ৩১, পর্ব ৩০, পর্ব ৫৫, পর্ব ৫৯, পর্ব ৬৪
নিচের event ID-গুলো কোর্সে যেভাবে শেখানো হয়েছে, সেভাবেই আছে। সংখ্যা মুখস্থের চেয়ে বড় কথা: কোনটি কিসের প্রশ্ন তোলে। মনে না এলে সৎভাবে বলুন, আর ঘটনার ধরন বলুন।
| Event ID | অর্থ | SOC-এর প্রশ্ন |
|---|---|---|
4624 / 4625 | Logon সফল / ব্যর্থ | Logon type কী, উৎস কোথায়, কোন account? |
4672 | নতুন logon-এ বিশেষ অধিকার | এই যন্ত্রে admin logon কি স্বাভাবিক? |
4648 | স্পষ্ট credential দিয়ে logon চেষ্টা | এই জোড়া কি অচেনা? |
4688 | Process তৈরি | Parent কে, command line কী? (Audit নীতি লাগে) |
4768 / 4769 | Kerberos TGT / service ticket চাওয়া | হার আর encryption type অস্বাভাবিক কি? |
4776 | DC credential যাচাই করল | NTLM কোথায় এখনো চলছে? |
4720 | User account তৈরি | Change ticket আছে? |
4728 / 4732 / 4756 | Global / local / universal group-এ সদস্য যোগ | কোন দল, কে যোগ করলেন, অনুমোদন আছে? |
4697 / 7045 | Service install | নতুন service কি প্রত্যাশিত? |
4698 | Scheduled task তৈরি (audit চালু থাকলে) | কে বানাল, কী চালাবে? |
4719 / 1102 | Audit নীতি বদল / audit log মোছা | দুটিই উচ্চ-সংকেত। কে, কেন? |
| Sysmon 1 | Process তৈরি, Sysmon-এর log-এ | Hash আর parent-সহ বিস্তারিত |
| Logon type | অর্থ | কোথায় মনে রাখবেন |
|---|---|---|
| 2 | যন্ত্রের সামনে বসে | সাধারণ PC-তে স্বাভাবিক, server-এ কম |
| 3 | Network, যেমন file share | সংখ্যায় অনেক; উৎস দেখুন |
| 4, 5 | Batch, service | Scheduled task আর service-এর account |
| 10 | Remote Desktop | Port 3389-এর সাথে মেলান |
| Linux-এ কোথায় | কী পাবেন |
|---|---|
/var/log/auth.log | Debian ধাঁচে SSH, sudo, PAM |
/var/log/secure | Red Hat ধাঁচে একই তথ্য |
journalctl | systemd journal |
| auditd-এর log | নিয়ম ধরে process আর ফাইলের ঘটনা |
প্র ১১4625 অনেকগুলো এলো। Logon type আর sub-status কেন দেখবেন? (মাঝারি)
উত্তর: Logon type বলে পথটি কী: type 3 network, type 10 RDP. Sub-status বলে কেন ব্যর্থ: 0xC000006A ভুল password, 0xC0000064 account নেই, 0xC0000234 account locked, আর 0xC000015B এই logon type অনুমোদিত নয়। একই account-এ বহু ভুল password এক গল্প। বহু account-এ অল্প করে ব্যর্থতা আরেক গল্প, যাকে password spraying বলে।
ফলো-আপ: “যে service-এর password পুরোনো, সে-ও এমন করে?” — হ্যাঁ। তাই একই ছন্দে, একই যন্ত্র থেকে এলে আগে service account আর task দেখি।
প্র ১২4688 আছে, কিন্তু command line ফাঁকা। কেন? (মাঝারি)
উত্তর: Process creation audit চালু থাকলেও command line আলাদা নীতিতে চালু করতে হয়। নইলে শুধু process-এর নাম আসে। শিক্ষা হলো: detection লেখার আগে দেখুন log আসলেই আছে কি না। Command line-এ গোপন মানও ঢুকতে পারে, তাই log-এর পড়ার অনুমতিও সীমিত রাখতে হয়।
প্র ১৩1102 এলো, মানে Security log মোছা হয়েছে। প্রথমে কী করবেন? (মাঝারি)
উত্তর: এটি বড় সংকেত, কারণ বৈধ কারণ বিরল। প্রথমে SIEM-এ ওই যন্ত্রের আগের log দেখি, কারণ যা আগেই পাঠানো হয়েছে তা যন্ত্রে মুছলেও কেন্দ্রে থাকে। কে মুছেছেন তা event-এই থাকে। Change ticket খুঁজি। না পেলে escalate করি। এই কারণেই log যন্ত্রের বাইরে পাঠানো হয় (পর্ব ৫৫)।
ফলো-আপ: “কোনো alert নেই, মানে সব ঠিক?” — না। উৎস নিজে চুপ হয়ে গেলেও কোনো alert আসে না। তাই log না আসার ওপরও একটি নজরদারি লাগে।
প্র ১৪এই লাইনটি পড়ুন: Failed password for invalid user test from 203.0.113.50 port 51124 ssh2. কী বুঝলেন? (সহজ)
উত্তর: SSH-তে password login ব্যর্থ। invalid user মানে test নামে কোনো account এই যন্ত্রে নেই। উৎস ওই ঠিকানা। একা এই লাইন বড় কিছু নয়, বাইরে খোলা SSH-তে এমন ভিড় লেগেই থাকে। আসল প্রশ্ন: একই উৎস থেকে পরে কোনো Accepted আছে কি? Username বাইরের মানুষের লেখা, তাই log-পড়ার script-এ field শেষ থেকে গোনা নিরাপদ (পর্ব ৫৫)।
৪ · Log পড়ার drill — নমুনা দেখে বলুন কী ঘটেছে
রিভিশন: পর্ব ৫৫, পর্ব ৬৪, পর্ব ৩৮, পর্ব ৫৮
এই অংশে ইন্টারভিউয়ার সাধারণত কয়েকটি লাইন দেখিয়ে চুপ করে থাকেন। তিনটি অভ্যাস কাজে দেয়। আগে সময়রেখা বানান। তারপর জোরে বলুন “এটি দেখছি” আর “এটি অনুমান করছি”। শেষে বলুন, কী প্রমাণ হয়নি।
প্রতিটি ব্লক চালানোর আগে log-টি নিজে পড়ুন, আর প্রশ্নগুলোর উত্তর খাতায় লিখুন। এই কমান্ডগুলো শুধু নিজের যন্ত্রের log, বা যে log পড়ার অনুমতি আপনার আছে, তাতেই ব্যবহার করবেন।
Drill ১ · একটি Linux server-এর auth log
আপনার প্রশ্ন: (ক) কোন উৎস সন্দেহজনক? (খ) কোন account সফলভাবে ব্যবহৃত হলো, কখন? (গ) তার পরের কাজ কী? (ঘ) ঘটনাটি এখনো চলছে বলে মনে হয় কেন?
export LC_ALL=C
cd "$(mktemp -d)"
# Fixed practice sample. Names and addresses are invented.
cat > auth.log <<'EOF'
Oct 30 21:40:02 app-2 sshd[811]: Accepted publickey for mitu from 198.51.100.14 port 50210 ssh2
Oct 30 21:52:11 app-2 sshd[840]: Failed password for mitu from 198.51.100.14 port 50233 ssh2
Oct 30 23:07:41 app-2 sshd[902]: Failed password for invalid user oracle from 203.0.113.77 port 41001 ssh2
Oct 30 23:07:43 app-2 sshd[903]: Failed password for invalid user deploy from 203.0.113.77 port 41003 ssh2
Oct 30 23:07:46 app-2 sshd[904]: Failed password for sohel from 203.0.113.77 port 41006 ssh2
Oct 30 23:07:49 app-2 sshd[905]: Failed password for sohel from 203.0.113.77 port 41009 ssh2
Oct 30 23:07:52 app-2 sshd[906]: Failed password for sohel from 203.0.113.77 port 41012 ssh2
Oct 30 23:08:20 app-2 sshd[910]: Accepted password for sohel from 203.0.113.77 port 41020 ssh2
Oct 30 23:09:02 app-2 sudo: sohel : TTY=pts/2 ; PWD=/home/sohel ; USER=root ; COMMAND=/usr/bin/useradd -m svc-backup2
Oct 30 23:09:40 app-2 sudo: sohel : TTY=pts/2 ; PWD=/home/sohel ; USER=root ; COMMAND=/usr/bin/tar czf /tmp/d.tgz /srv/orders
Oct 30 23:15:12 app-2 sshd[931]: Accepted password for svc-backup2 from 203.0.113.77 port 41055 ssh2
EOF
echo "== failures by source =="
awk '/sshd.*Failed password/ {print $(NF-3)}' auth.log | sort | uniq -c | sort -k1,1nr
echo "== success from a source that failed before =="
awk '/sshd.*Failed password/ {bad[$(NF-3)]++}
/sshd.*Accepted/ && ($(NF-3) in bad) {
print $3, $9, $7, "from", $(NF-3), "after", bad[$(NF-3)], "failures"}' auth.log
echo "== what happened after the success =="
awk '$3 >= "23:08:20" && /sudo:/ {split($0, a, "COMMAND="); print $3, a[2]}' auth.log
echo "== accounts used by 203.0.113.77 =="
grep 'Accepted' auth.log | grep -F '203.0.113.77' | awk '{print $9}' | sort -u== failures by source ==
5 203.0.113.77
1 198.51.100.14
== success from a source that failed before ==
23:08:20 sohel password from 203.0.113.77 after 5 failures
23:15:12 svc-backup2 password from 203.0.113.77 after 5 failures
== what happened after the success ==
23:09:02 /usr/bin/useradd -m svc-backup2
23:09:40 /usr/bin/tar czf /tmp/d.tgz /srv/orders
== accounts used by 203.0.113.77 ==
sohel
svc-backup2যা দেখছি: 203.0.113.77 থেকে ১১ সেকেন্ডে ৫টি ব্যর্থতা (২৩:০৭:৪১ থেকে ২৩:০৭:৫২), তিনটি নামে। ২৩:০৮:২০-এ sohel password দিয়ে সফল। ৪২ সেকেন্ড পরে sudo দিয়ে নতুন account, আরও ৩৮ সেকেন্ড পরে orders ডেটার archive. ২৩:১৫:১২-এ একই উৎস নতুন account দিয়েই ঢুকল।
অনুমান: account দখল, আর ফেরার পথ তৈরি। শেষ লাইনই (ঘ)-এর উত্তর: নতুন account ব্যবহার শুরু হয়ে গেছে। প্রমাণ হয়নি: /tmp/d.tgz বাইরে গেছে কি না, এই log তা বলে না। Flow log দেখতে হবে। আর mitu-র একটি ব্যর্থতা সাধারণ ভুল টাইপিং মনে হয়, কারণ উৎস তার চেনা, আর আগে সফল login আছে।
Drill ২ · একটি web app-এর access log
আপনার প্রশ্ন: (ক) কোন উৎসে ৪০১-এর ভিড়? (খ) কোন account-এ শেষে login হলো? (গ) তারপর সে কী করল, কোনটি আটকাল, কোনটি আটকাল না? (ঘ) এই log-এর একটি দুর্বলতা বলুন। Log-এর শেষের ঘরটি এই নমুনার app-এর নিজের, প্রমিত নয়।
export LC_ALL=C
cd "$(mktemp -d)"
# Fixed practice sample of a fictional shop. No real site or person.
cat > access.log <<'EOF'
198.51.100.31 - - [30/Oct/2026:10:02:01 +0600] "POST /api/login HTTP/1.1" 200 310 "user=rina"
198.51.100.31 - - [30/Oct/2026:10:02:09 +0600] "GET /api/orders/me HTTP/1.1" 200 2100 "user=rina"
203.0.113.40 - - [30/Oct/2026:10:03:00 +0600] "POST /api/login HTTP/1.1" 401 96 "user=-"
203.0.113.40 - - [30/Oct/2026:10:03:01 +0600] "POST /api/login HTTP/1.1" 401 96 "user=-"
203.0.113.40 - - [30/Oct/2026:10:03:02 +0600] "POST /api/login HTTP/1.1" 401 96 "user=-"
203.0.113.40 - - [30/Oct/2026:10:03:03 +0600] "POST /api/login HTTP/1.1" 401 96 "user=-"
203.0.113.40 - - [30/Oct/2026:10:03:04 +0600] "POST /api/login HTTP/1.1" 401 96 "user=-"
203.0.113.40 - - [30/Oct/2026:10:03:05 +0600] "POST /api/login HTTP/1.1" 401 96 "user=-"
203.0.113.40 - - [30/Oct/2026:10:03:06 +0600] "POST /api/login HTTP/1.1" 200 310 "user=tuhin"
203.0.113.40 - - [30/Oct/2026:10:03:20 +0600] "GET /api/orders/me HTTP/1.1" 200 2100 "user=tuhin"
203.0.113.40 - - [30/Oct/2026:10:03:41 +0600] "GET /api/orders/export HTTP/1.1" 403 120 "user=tuhin"
203.0.113.40 - - [30/Oct/2026:10:03:55 +0600] "GET /api/orders/1043 HTTP/1.1" 200 800 "user=tuhin"
203.0.113.40 - - [30/Oct/2026:10:03:56 +0600] "GET /api/orders/1044 HTTP/1.1" 200 800 "user=tuhin"
203.0.113.40 - - [30/Oct/2026:10:03:57 +0600] "GET /api/orders/1045 HTTP/1.1" 200 800 "user=tuhin"
198.51.100.31 - - [30/Oct/2026:10:04:30 +0600] "GET /api/products HTTP/1.1" 200 1500 "user=rina"
EOF
echo "== requests per source and status =="
awk '{print $1, $9}' access.log | sort | uniq -c | sort -k2,2 -k3,3
echo "== first 200 login after 401s =="
awk '$7 == "/api/login" && $9 == 401 {f[$1]++}
$7 == "/api/login" && $9 == 200 && f[$1] {
print substr($4, 14), $1, $11, "after", f[$1], "401s"; exit}' access.log
echo "== paths after that login, source 203.0.113.40 =="
awk -v s=203.0.113.40 '$1 == s && $7 != "/api/login" {print substr($4, 14), $9, $7}' access.log
echo "== order ids read, one user =="
awk '$7 ~ /^\/api\/orders\/[0-9]+$/ && $9 == 200 {split($7, p, "/"); print $11, p[4]}' access.log== requests per source and status ==
3 198.51.100.31 200
5 203.0.113.40 200
6 203.0.113.40 401
1 203.0.113.40 403
== first 200 login after 401s ==
10:03:06 203.0.113.40 "user=tuhin" after 6 401s
== paths after that login, source 203.0.113.40 ==
10:03:20 200 /api/orders/me
10:03:41 403 /api/orders/export
10:03:55 200 /api/orders/1043
10:03:56 200 /api/orders/1044
10:03:57 200 /api/orders/1045
== order ids read, one user ==
"user=tuhin" 1043
"user=tuhin" 1044
"user=tuhin" 1045ছয় সেকেন্ডের মধ্যে ৬টি 401, তারপর tuhin-এ 200. এর পরে /export ঠিকই ৪০৩ পেল, মানে সেই দরজা কাজ করছে। কিন্তু ক্রমিক 1043, 1044, 1045 তিনটিতেই ২০০. এখানে দুটি আলাদা প্রশ্ন: account কি দখল হয়েছে, আর এই order-গুলো কি tuhin-এর নিজের? নিজের না হলে এটি পর্ব ৩৮-এর object-স্তরের অনুমতির ত্রুটি, যা app দলকে জানাতে হবে।
(ঘ)-এর উত্তর: ব্যর্থ login-এ user=-, তাই ৪০১-গুলো এক account-এ, না অনেক account-এ, তা বলা যায় না। অর্থাৎ brute force আর credential stuffing আলাদা করা যাচ্ছে না। ব্যর্থ login-এ username রাখুন, তবে কখনো password নয়।
Drill ৩ · একটি Windows যন্ত্রের সময়রেখা
আপনার প্রশ্ন: প্রতিটি event ID-র অর্থ আগে নিজে বলুন, তারপর চালান। ঘটনাগুলো কি একই গল্প? শেষ সারিটি কি সেই গল্পের অংশ?
// Windows Security events on a fictional host. Invented data, no real logs.
const MEANING = {
4625: 'logon failed', 4624: 'logon ok', 4672: 'special privileges',
4688: 'process created', 4720: 'user created', 4732: 'added to local group',
1102: 'audit log cleared',
};
const ev = [
{ t: '01:12:04', id: 4625, d: 'nadia, type 10 from 203.0.113.9' },
{ t: '01:12:11', id: 4625, d: 'nadia, type 10 from 203.0.113.9' },
{ t: '01:12:19', id: 4624, d: 'nadia, type 10 from 203.0.113.9' },
{ t: '01:12:19', id: 4672, d: 'nadia, admin rights on this logon' },
{ t: '01:13:40', id: 4688, d: 'nadia, cmd.exe from explorer.exe' },
{ t: '01:14:02', id: 4720, d: 'nadia made user helpdesk9' },
{ t: '01:14:10', id: 4732, d: 'nadia put helpdesk9 in Administrators' },
{ t: '01:19:55', id: 1102, d: 'nadia cleared the Security log' },
{ t: '08:02:15', id: 4624, d: 'nadia, type 2 at the console' },
];
for (const e of ev) console.log(`${e.t} ${e.id} ${MEANING[e.id].padEnd(21)} ${e.d}`);
// Chain check: each step must come after the one before it.
const chain = [4625, 4624, 4720, 4732, 1102];
const seen = [];
for (const e of ev) {
if (seen.length < chain.length && e.id === chain[seen.length]) seen.push(e.t);
}
const sec = s => s.split(':').reduce((a, b) => a * 60 + Number(b), 0);
const span = sec(seen[seen.length - 1]) - sec(seen[0]);
console.log(`chain ${seen.length}/${chain.length} steps, ${seen[0]} to ${seen.at(-1)}, ${span} s`);01:12:04 4625 logon failed nadia, type 10 from 203.0.113.9
01:12:11 4625 logon failed nadia, type 10 from 203.0.113.9
01:12:19 4624 logon ok nadia, type 10 from 203.0.113.9
01:12:19 4672 special privileges nadia, admin rights on this logon
01:13:40 4688 process created nadia, cmd.exe from explorer.exe
01:14:02 4720 user created nadia made user helpdesk9
01:14:10 4732 added to local group nadia put helpdesk9 in Administrators
01:19:55 1102 audit log cleared nadia cleared the Security log
08:02:15 4624 logon ok nadia, type 2 at the console
chain 5/5 steps, 01:12:04 to 01:19:55, 471 s৪৭১ সেকেন্ড, মানে ৭ মিনিট ৫১ সেকেন্ডে পাঁচটি ধাপ: ব্যর্থতা, RDP-তে সফল, নতুন user, admin দলে যোগ, log মোছা। একই account সব করেছে, তাই account-টিই প্রশ্ন, মানুষটি নয়। সকাল ৮টার type 2 সম্ভবত আসল কর্মী, নিজের ডেস্কে। এটি তাঁকে ফোনে যাচাইয়ের সুযোগ, তবে তিনিই সব করেছেন, এমন প্রমাণ নয়। 1102-এর পরে যন্ত্রের log অসম্পূর্ণ, তাই বাকি খোঁজ SIEM-এ।
প্র ১৫Log দেখে সময়রেখা বানাতে গিয়ে কোন তিনটি ভুল সবচেয়ে বেশি হয়? (মাঝারি)
উত্তর: (১) Time zone মেলানো হয় না। অনেক SIEM UTC দেখায়, অনেক server স্থানীয় সময় লেখে। (২) Syslog-এর পুরোনো ধাঁচে বছর থাকে না, তাই পুরোনো ফাইল ভুল বছরে বসে। (৩) ঘড়ির অমিল ধরা হয় না, তাই কারণের আগে ফল দেখা যায়। সমাধান: সব UTC-তে, NTP চালু, আর প্রতিটি সারিতে উৎসের নাম (পর্ব ৫৫)।
প্র ১৬Drill ১-এর ঘটনায় আপনি কি নিজে /tmp/d.tgz মুছে দেবেন? (মাঝারি)
৫ · Triage পরিস্থিতি — পরিচয়ের তিনটি alert
রিভিশন: পর্ব ১৫, পর্ব ১৬, পর্ব ২০, পর্ব ৫৬, পর্ব ৬০
প্রতিটি পরিস্থিতিতে উত্তরটি একই ছাঁচে: আগে কী দেখব, কী দেখলে মত বদলাবে, আর escalate না close. কে কী করতে পারবেন তা প্রতিষ্ঠানের playbook-এ লেখা থাকে। ইন্টারভিউতে বলুন, “আমার ক্ষমতা আর playbook অনুযায়ী”, কারণ junior analyst একা সব বন্ধ করে দেন না।
পরিস্থিতি ১ · অনেক ব্যর্থ login, তারপর সাফল্য
Alert এলো: app-2-তে sohel, ৫টি ব্যর্থতার পরে সফল। Drill ১-এর ঘটনাটিই এবার analyst-এর চোখে দেখুন। প্রতি ধাপে থেমে বলুন, আপনি হলে পরের ধাপে কী দেখতেন।
| প্রশ্ন | |
| Priority | |
| ধারণা | |
| মালিক |
- কী দেখছি। শুধু তথ্য বলুন। Alert প্রমাণ নয়। Priority স্বয়ংক্রিয়ভাবে P3. প্রথম প্রশ্ন: আসল, না ভুল টাইপিং?
- পরিসর। এক উৎস, তিনটি নাম, এক server. দুটি নাম এই যন্ত্রে নেই-ই। একজন কর্মীর ভুল টাইপিং এমন হয় না, তবে এটুকুতে এখনো রায় নয়।
- Baseline. তিনি ৯০ দিনে শুধু key দিয়ে, চেনা পরিসর থেকে ঢুকেছেন। আজ password আর অচেনা উৎস। দুটি নতুন জিনিস একসাথে। তাই P2.
- পরের কাজ। Pivoting: এখান থেকে পাশের তথ্যে যাওয়া। ৪২ সেকেন্ডে নতুন account, তারপর ডেটার archive, আর নতুন account-এ login. তাই P1.
- আলাদা পথে যাচাই। ফোনে, চ্যাটে নয়, কারণ দখল হওয়া account-এর চ্যাট বিশ্বাসযোগ্য নয়। তিনি জানালেন ঘুমাচ্ছিলেন। তিনি অনুমোদিত কাজ করছিলেন জানালে ধারণা উল্টে যেত, তবে নতুন account-এর ব্যাখ্যা তবুও লাগত।
- সিদ্ধান্ত। Escalate. নিজের ক্ষমতার বাইরের কাজ অনুরোধ হিসেবে যায়: session বন্ধ, দুটি account lock, ফাইল সংরক্ষণ। Note-এ লেখা: কী দেখিনি (ফাইল বাইরে গেছে কি না)।
- ফিডব্যাক। ঘটনা বন্ধ হলে শিক্ষা যায় rule আর hardening-এ: admin-এর SSH-তে password বন্ধ, আর “নতুন উৎস থেকে প্রথম password login” একটি নতুন detection.
প্র ১৭পরিস্থিতি ১: ব্যর্থ login-এর পরে সাফল্য। মডেল উত্তর দিন। (মাঝারি)
আগে কী দেখব: কতগুলো ব্যর্থতা, কতগুলো account, উৎস কোথায়, এই account-এর স্বাভাবিক উৎস আর পদ্ধতি কী, সফল login-এর পরে কী হলো, MFA ছিল কি না।
কী দেখলে মত বদলাবে: নিরীহ দিকে: চেনা যন্ত্র, চেনা সময়, একটি account, ছুটি শেষে password ভুলে যাওয়া, আর পরে সাধারণ কাজ। বিপদের দিকে: নতুন উৎস, বহু account, সফল হওয়ার পরপরই account বানানো, অনুমতি বদলানো, ডেটা গোছানো।
Escalate না close: ব্যবহারকারী আলাদা পথে নিশ্চিত করলে, আর পরের কাজ নিরীহ হলে কারণ লিখে close. সন্দেহজনক পরের কাজ, বা ব্যবহারকারী অস্বীকার করলে escalate.
পরিস্থিতি ২ · Impossible travel
একই account দুই দূরের স্থান থেকে অল্প সময়ে sign in করলে impossible travel alert আসে। হিসাবটি সরল: দূরত্ব ÷ সময়। নিচের ৯০০ km/h একটি ধরে নেওয়া সীমা, আর শহরের স্থানাঙ্ক মোটামুটি। আগে অনুমান করুন: sohel-এর সারিটি কেন “possible” হবে?
// Impossible-travel check on invented sign-ins. Simulated times, in minutes.
const toRad = d => d * Math.PI / 180;
function km(a, b) { // great-circle distance (haversine)
const R = 6371, dLat = toRad(b.lat - a.lat), dLon = toRad(b.lon - a.lon);
const h = Math.sin(dLat / 2) ** 2 +
Math.cos(toRad(a.lat)) * Math.cos(toRad(b.lat)) * Math.sin(dLon / 2) ** 2;
return 2 * R * Math.asin(Math.sqrt(h));
}
const DHAKA = { name: 'Dhaka', lat: 23.81, lon: 90.41 };
const CTG = { name: 'Chattogram', lat: 22.36, lon: 91.78 };
const SG = { name: 'Singapore', lat: 1.35, lon: 103.82 };
const FRA = { name: 'Frankfurt', lat: 50.11, lon: 8.68 };
const MAX_KMH = 900; // assumed: a fast passenger flight
const VPN_EXITS = new Set(['Singapore']); // assumed: our own VPN exit
const cases = [
{ user: 'rina', a: DHAKA, b: CTG, mins: 60 },
{ user: 'tuhin', a: DHAKA, b: FRA, mins: 45 },
{ user: 'mitu', a: DHAKA, b: SG, mins: 10 },
{ user: 'sohel', a: DHAKA, b: FRA, mins: 600 },
];
for (const c of cases) {
const d = km(c.a, c.b), speed = d / (c.mins / 60);
let v = speed > MAX_KMH ? 'IMPOSSIBLE' : 'possible';
if (v === 'IMPOSSIBLE' && VPN_EXITS.has(c.b.name)) v = 'check VPN first';
console.log(`${c.user.padEnd(6)} ${c.a.name} > ${c.b.name.padEnd(10)} ` +
`${d.toFixed(0).padStart(5)} km in ${String(c.mins).padStart(3)} min = ` +
`${speed.toFixed(0).padStart(5)} km/h ${v}`);
}rina Dhaka > Chattogram 214 km in 60 min = 214 km/h possible
tuhin Dhaka > Frankfurt 7426 km in 45 min = 9902 km/h IMPOSSIBLE
mitu Dhaka > Singapore 2885 km in 10 min = 17310 km/h check VPN first
sohel Dhaka > Frankfurt 7426 km in 600 min = 743 km/h possibletuhin-এর সারিতে ঘণ্টায় প্রায় ৯,৯০০ km, যা সম্ভব নয়। mitu-র গতিও অসম্ভব, কিন্তু Singapore এখানে প্রতিষ্ঠানের নিজের VPN-এর বের হওয়ার পথ ধরা হয়েছে। তাই আগে VPN log. sohel ১০ ঘণ্টায় ৭,৪২৬ km, প্রায় ৭৪৩ km/h, যা flight-এ সম্ভব। “সম্ভব” মানে নিরাপদ নয়। সেখানে দেখতে হবে তিনি সত্যিই ভ্রমণে কি না। গতি শুধু প্রথম ছাঁকনি।
প্র ১৮পরিস্থিতি ২: Impossible travel. মডেল উত্তর দিন। (মাঝারি)
আগে কী দেখব: দুটি login-এর উৎস, VPN বা অনুমোদিত proxy-র ঠিকানা কি না, যন্ত্র চেনা কি না, MFA কীভাবে পার হলো, IP-র অবস্থানের তথ্য কতটা নির্ভরযোগ্য, আর account-টি কতটা সংবেদনশীল।
কী দেখলে মত বদলাবে: নিরীহ দিকে: নিজের VPN, cloud proxy, mobile network-এর দূরের gateway, একই যন্ত্র আর চেনা session. বিপদের দিকে: নতুন যন্ত্র, নতুন inbox rule, MFA-র নতুন পদ্ধতি যোগ, বারবার MFA অনুরোধ (MFA fatigue), বড় ডাউনলোড।
Escalate না close: পরিচিত VPN প্রমাণ হলে benign positive হিসেবে close, আর rule-এ সেই ব্যতিক্রম মেয়াদসহ। নতুন যন্ত্র আর অচেনা কাজ থাকলে escalate. সেখানে session বাতিল, password বদল আর MFA পরীক্ষা, playbook অনুযায়ী।
ফলো-আপ: “Password বদলালেই হলো?” — না। পুরোনো session চলতে পারে। তাই session revoke, আর ফেরার দরজা খোঁজা (পর্ব ৫৩)।
পরিস্থিতি ৩ · নতুন admin account
প্র ১৯পরিস্থিতি ৩: 4720 আর তারপর 4732: নতুন account Administrators দলে। মডেল উত্তর দিন। (মাঝারি)
আগে কী দেখব: কে করলেন, কোন যন্ত্রে, change ticket আছে কি, ওই admin-এর login নিজে স্বাভাবিক কি, account-এর নাম প্রতিষ্ঠানের নিয়মে পড়ে কি, আর account-টি এরপর কোথায় ব্যবহার হলো।
কী দেখলে মত বদলাবে: নিরীহ দিকে: মিলে যাওয়া ticket, চেনা admin, কাজের সময়, নির্দিষ্ট মেয়াদ। বিপদের দিকে: ticket নেই, রাতের সময়, service account দিয়ে করা, first-seen কর্তা, অল্প পরে সদস্য সরানো, কিংবা 1102.
Escalate না close: Ticket মিললে close, ticket নম্বর লিখে। না মিললে ওই account-কে নিরীহ ধরা হয় না: admin-এর সাথে আলাদা পথে কথা, আর সাথে সাথে escalate. Domain Admins-এর মতো দলে হলে priority সবচেয়ে ওপরে।
ফলো-আপ: “Ticket নম্বর দেওয়া আছে, তবে?” — নম্বরটি আছে কি না, আর এই কাজের জন্য কি না, মিলিয়ে দেখি। ভুয়া নম্বরও দেওয়া যায়।
৬ · Triage পরিস্থিতি — endpoint, network আর মানুষের চারটি alert
রিভিশন: পর্ব ৫৯, পর্ব ৫৮, পর্ব ৩৩, পর্ব ৩৪, পর্ব ৫৩
পরিস্থিতি ৪ · সন্দেহজনক process tree
EDR alert: pc-31-এ powershell.exe. PowerShell নিজে কোনো অপরাধ নয়, IT কর্মীরা প্রতিদিন চালান। এটিই living off the land-এর সমস্যা। বিচার হয় প্রসঙ্গ দিয়ে, মানে process tree দিয়ে। নিচের গাছটি বানানো।
powershell.exe -enc <long text omitted>
explorer.exe └─ outlook.exe └─ winword.exe invoice_oct.docm └─ powershell.exe 10:14:07
powershell.exe ├─ file write ...\AppData\Local\Temp\upd.dat ├─ network 203.0.113.50:443 first seen today └─ schtasks.exe new task 10:14:31
mail gateway : invoice_oct.docm in 14 mailboxes EDR search : 203.0.113.50 from 2 hosts (pc-31, pc-44) mail log : attachment opened on 2 hosts
Verdict : True positive, high confidence Asked : network isolation of pc-31, pc-44 (playbook) Asked : purge mail from 14 mailboxes Not done: no files deleted, machines left powered on Unknown : what the task runs; whether accounts were reused
- Alert. শুধু process-এর নাম আর লম্বা encoded লেখা। এটি সংকেত, রায় নয়। Management টুলও এমন করে।
- Parent. Word থেকে PowerShell. Document app সাধারণত shell চালায় না। আর ফাইলটি mail থেকে এসেছে। এখানেই সন্দেহ জোরালো হলো। Parent যদি অনুমোদিত management agent হতো, তবে মত বদলাত।
- Child. ফাইল লেখা, আজই প্রথম দেখা ঠিকানা, আর
schtasks.exe, মানে সম্ভবত ফিরে আসার পথ, যাকে persistence বলে। এক সূত্রে তিনটি চিহ্ন। - পরিসর। এক যন্ত্র ধরে থেমে গেলে ভুল। একই ফাইল ১৪টি mailbox-এ, আর দুটি যন্ত্র সেই ঠিকানায় গেছে। ঘটনা এখন একটি PC-র নয়।
- সিদ্ধান্ত। Escalate, আর playbook অনুযায়ী network থেকে আলাদা করা। যন্ত্র বন্ধ করা হয়নি, কারণ memory-র প্রমাণ হারায়। “Unknown” লাইনটি পরের জনের সময় বাঁচায়।
প্র ২০পরিস্থিতি ৪: Process tree-র alert. মডেল উত্তর দিন। (মাঝারি)
আগে কী দেখব: Parent আর grandparent, command line, user, যন্ত্রের গুরুত্ব, ফাইলের hash আর উৎস, child process, নতুন network সংযোগ, persistence-এর চিহ্ন।
কী দেখলে মত বদলাবে: নিরীহ দিকে: অনুমোদিত management agent, IT-র পরিচিত signed script, পরিবর্তনের ticket, আগে বহুবার দেখা একই জোড়া। বিপদের দিকে: document app বা web server থেকে shell, আগে না দেখা ঠিকানা, নতুন task বা service.
Escalate না close: Baseline-এ মেলা আর ticket থাকলে কারণ লিখে close. Mail attachment থেকে শুরু হয়ে network আর persistence থাকলে escalate আর playbook অনুযায়ী isolate.
ফলো-আপ: “যন্ত্র বন্ধ করে দেবেন?” — না, network থেকে আলাদা করব। বন্ধ করলে memory হারায়। “Isolate-এর ক্ষতি?” — ব্যবহারকারীর কাজ থামে। তাই payment server হলে সিদ্ধান্ত service-এর মালিকের সাথে হয়।
পরিস্থিতি ৫ · Beaconing
স্বয়ংক্রিয় program প্রায় সমান বিরতিতে যোগাযোগ করে, আর মানুষ অনিয়মিত browse করেন। পর্ব ৫৮-এর মাপ CV = standard deviation ÷ mean. প্রথম দুটি সারি সেই পর্বের বিরতি। নিচের সীমাগুলো ধরে নেওয়া। অনুমান করুন: তৃতীয় সারির CV সবচেয়ে কম হলে কি সেটি সবচেয়ে বিপজ্জনক?
// Beaconing check on invented gaps between connections, in seconds.
// CV = standard deviation / mean. Near zero means very regular.
const flows = [
{ pair: 'pc-17 > 203.0.113.50', gaps: [300, 301, 299, 300, 300, 301, 299, 300],
hosts: 1, ageDays: 3 },
{ pair: 'pc-05 > 198.51.100.20', gaps: [12, 340, 45, 1800, 7, 620, 95, 210],
hosts: 40, ageDays: 900 },
{ pair: 'all > updates.example.com', gaps: [3600, 3601, 3599, 3600, 3602, 3600],
hosts: 180, ageDays: 1500 },
];
const mean = a => a.reduce((s, x) => s + x, 0) / a.length;
const sd = a => {
const m = mean(a);
return Math.sqrt(a.reduce((s, x) => s + (x - m) ** 2, 0) / a.length);
};
for (const f of flows) {
const m = mean(f.gaps), cv = sd(f.gaps) / m;
const regular = cv < 0.1;
const rare = f.hosts <= 2 && f.ageDays < 30; // assumed cut-offs
const lead = regular && rare ? 'INVESTIGATE'
: regular ? 'regular, likely known' : 'not regular';
console.log(`${f.pair.padEnd(27)} mean ${m.toFixed(1).padStart(6)} ` +
`cv ${cv.toFixed(3)} hosts ${String(f.hosts).padStart(3)} ` +
`age ${String(f.ageDays).padStart(4)}d ${lead}`);
}pc-17 > 203.0.113.50 mean 300.0 cv 0.002 hosts 1 age 3d INVESTIGATE
pc-05 > 198.51.100.20 mean 391.1 cv 1.450 hosts 40 age 900d not regular
all > updates.example.com mean 3600.3 cv 0.000 hosts 180 age 1500d regular, likely knownতৃতীয় সারির CV সবচেয়ে কম, প্রায় শূন্য, তবু সেটি software update: ১৮০টি যন্ত্র, ১,৫০০ দিনের পুরোনো গন্তব্য। প্রথম সারি নিয়মিত, এক যন্ত্র, মাত্র ৩ দিনের ঠিকানা, তাই সেটিই আগে। শিক্ষা: ছন্দ একা রায় দেয় না, ছন্দের সাথে বিরলতা লাগে। ছন্দ না থাকলেও নির্দোষ বলা যায় না, কারণ ক্ষতিকর যোগাযোগ সবসময় নিখুঁত ছন্দে চলে না।
প্র ২১পরিস্থিতি ৫: Beaconing. মডেল উত্তর দিন। (মাঝারি)
আগে কী দেখব: কোন process যোগাযোগ করছে (EDR), গন্তব্য কত পুরোনো, কতগুলো যন্ত্র সেখানে যায়, বিরতি আর প্রতিবারের পরিমাণ, DNS-এ নামটি কী, threat intelligence-এ কিছু আছে কি।
কী দেখলে মত বদলাবে: নিরীহ দিকে: update, antivirus, NTP, health check, signature করা চেনা app, বহু যন্ত্র একই গন্তব্যে। বিপদের দিকে: অচেনা process, নতুন ডোমেইন, এক-দুটি যন্ত্র, আউটগোয়িং পরিমাণ বাড়া।
Escalate না close: চেনা সেবা প্রমাণ হলে close, আর সেই গন্তব্য তালিকায়। অচেনা process আর নতুন গন্তব্য হলে escalate. সম্ভাব্য C2 ধরে নিয়ে অন্য যন্ত্রেও খোঁজ।
পরিস্থিতি ৬ · একজন কর্মীর phishing report
প্র ২২পরিস্থিতি ৬: “এই mail-টি অদ্ভুত লাগছে”, একজন কর্মী report করলেন। মডেল উত্তর দিন। (মাঝারি)
আগে কী দেখব: পূর্ণ header, SPF, DKIM, DMARC-এর ফল, আসল প্রেরকের ডোমেইন, link-এর মালিক ডোমেইন, attachment-এর sandbox ফল। তারপর পরিসর: কতজনের কাছে গেছে, কতজন click করেছেন, কেউ তথ্য দিয়েছেন কি না।
কী দেখলে মত বদলাবে: নিরীহ দিকে: প্রমাণিত vendor, প্রত্যাশিত মার্কেটিং mail, অনুমোদিত phishing simulation. বিপদের দিকে: কাছাকাছি নামের ডোমেইন, login-এর নকল পাতা, টাকা পাঠানোর জরুরি অনুরোধ, যাকে BEC বলে। মনে রাখুন, DMARC পাস করলেই mail নিরাপদ নয়, দখল হওয়া আসল account থেকেও আসতে পারে।
Escalate না close: কেউ click করেননি, আর mail সরানো গেছে: নিজেই শেষ করা যায়, যদি playbook দেয়। কেউ তথ্য দিয়েছেন, বা attachment চালিয়েছেন: escalate, password reset, session revoke, আর inbox rule পরীক্ষা। যিনি report করলেন, তাঁকে ফল জানান। তিনি আপনার সেরা sensor.
ফলো-আপ: “সবার inbox থেকে কীভাবে সরাবেন?” — আগে dry run. Subject ধরে সব মুছলে বৈধ mail-ও যায়। প্রেরক আর URL ধরে খুঁজে quarantine-এ পাঠান, মুছে নয় (পর্ব ৫৩)।
পরিস্থিতি ৭ · গণহারে ফাইল বদল
File server-এ হঠাৎ বহু ফাইল বদলাচ্ছে বা rename হচ্ছে। এটি ransomware-এর শেষ ধাপ হতে পারে, আবার sync বা migration-ও। এখানে সেকেন্ডের দাম। নিচের সীমা ৩০০ একটি ধরে নেওয়া মান, আর syncagent.exe এই প্রতিষ্ঠানের চেনা টুল। আগে অনুমান করুন: কোন মিনিটে প্রথম ALERT আসবে? তার আগে কি সংকেত ছিল?
export LC_ALL=C
cd "$(mktemp -d)"
# Fixed sample of a file-audit export: minute,user,process,action,count
# Invented data. No real files are touched here.
cat > file_audit.csv <<'EOF'
02:10,rumi,excel.exe,write,3
02:10,svc-sync,syncagent.exe,write,410
02:11,svc-sync,syncagent.exe,write,395
02:11,rumi,excel.exe,write,2
02:12,svc-sync,syncagent.exe,write,402
02:13,tania,update7.exe,rename,38
02:13,tania,update7.exe,write,41
02:14,tania,update7.exe,rename,620
02:14,tania,update7.exe,write,655
02:15,tania,update7.exe,rename,890
02:15,tania,update7.exe,write,902
02:15,tania,update7.exe,canary-touch,1
EOF
LIMIT=300; ALLOW='syncagent.exe'
echo "== changes per minute, per process =="
awk -F, '{c[$1" "$2" "$3] += $5} END {for (k in c) print k, c[k]}' file_audit.csv | sort
echo "== over the limit of $LIMIT per minute =="
awk -F, -v lim="$LIMIT" -v ok="$ALLOW" '
{c[$1" "$2" "$3] += $5; p[$1" "$2" "$3] = $3}
END {for (k in c) if (c[k] > lim) print k, c[k], (p[k] == ok ? "known sync, check quietly" : "ALERT")}' file_audit.csv | sort
echo "== canary file touched =="
awk -F, '$4 == "canary-touch" {print $1, $2, $3}' file_audit.csv
echo "== renames by process =="
awk -F, '$4 == "rename" {r[$3] += $5} END {for (p in r) print p, r[p]}' file_audit.csv== changes per minute, per process ==
02:10 rumi excel.exe 3
02:10 svc-sync syncagent.exe 410
02:11 rumi excel.exe 2
02:11 svc-sync syncagent.exe 395
02:12 svc-sync syncagent.exe 402
02:13 tania update7.exe 79
02:14 tania update7.exe 1275
02:15 tania update7.exe 1793
== over the limit of 300 per minute ==
02:10 svc-sync syncagent.exe 410 known sync, check quietly
02:11 svc-sync syncagent.exe 395 known sync, check quietly
02:12 svc-sync syncagent.exe 402 known sync, check quietly
02:14 tania update7.exe 1275 ALERT
02:15 tania update7.exe 1793 ALERT
== canary file touched ==
02:15 tania update7.exe
== renames by process ==
update7.exe 1548০২:১৪-এ প্রথম ALERT. ০২:১৩-এ মাত্র ৭৯টি বদল ছিল, সীমার অনেক নিচে, অথচ তখনই ভুল process-এর হাতে ৩৮টি rename হচ্ছিল। syncagent.exe সংখ্যায় বেশি হলেও শুধু লেখে, rename করে না, আর চেনা। আর canary file ছোঁয়া সংখ্যার ওপর নির্ভর করে না: এক স্পর্শই যথেষ্ট সংকেত, যদিও indexing বা antivirus-ও ছুঁতে পারে। Threshold-এর ফাঁদ এখানেই: সীমা কম হলে sync-এ বাজবে, বেশি হলে আপনি হাজার ফাইল হারিয়ে জানবেন।
প্র ২৩পরিস্থিতি ৭: গণহারে ফাইল বদল। মডেল উত্তর দিন। (মাঝারি)
আগে কী দেখব: কোন process, কোন user, কোন যন্ত্র থেকে, write নাকি rename, ফাইলের নতুন extension, ফাইল খোলা যায় কি, shadow copy মোছার চিহ্ন, backup job ঠিক আছে কি, change ticket বা migration আছে কি।
কী দেখলে মত বদলাবে: নিরীহ দিকে: চেনা signed sync টুল, ঘোষিত migration, service account, নির্দিষ্ট ফোল্ডার। বিপদের দিকে: অচেনা process, সাধারণ user-এর account, ফাইল server-এর অনেক share, canary ছোঁয়া, একই সময়ে T1490-এর মতো ফেরার পথ বন্ধের চিহ্ন।
Escalate না close: এখানে অপেক্ষা নয়। সন্দেহ জোরালো হলেই সঙ্গে সঙ্গে escalate, incident ঘোষণার পথে, আর playbook অনুযায়ী উৎস যন্ত্র আলাদা, share থেকে সেই account-এর সংযোগ বন্ধ। প্রমাণ রাখুন, আর ফেরা যায় এমন কাজ আগে। Backup আলাদা রাখুন, যাতে তাতে হাত না পড়ে।
ফলো-আপ: “ভুল alarm হলে দাম?” — এক ঘণ্টার ব্যবসায়িক বিরতি। আসল হলে দাম অনেক বেশি। এই অসমতা আগে থেকেই playbook-এ লেখা থাকলে রাত ২টায় তর্ক লাগে না। Ransomware-এর পুরো পথ পর্ব ৩৪-এ।
৭ · Detection rule আর MITRE ATT&CK
রিভিশন: পর্ব ৫৬, পর্ব ৫, পর্ব ৫৭, পর্ব ৫৮
Junior ভূমিকায় সাধারণত পুরো rule লিখতে হয় না, তবে ভাবনাটি বলতে পারা অনেক বড় সুবিধা। একটি ভালো detection ধারণায় ছয়টি অংশ থাকে: কোন আচরণ, কোন log, কী শর্ত, কোন নিরীহ ঘটনা মিলবে, কীভাবে test হবে, আর বাজলে কে কী করবেন।
পরিস্থিতি ৪-এর আচরণ Sigma-র ধাঁচে এমন হতে পারে। এটি উদাহরণ, YAML হিসেবে parse করে দেখা, তবে কোনো SIEM-এ চালানো হয়নি।
title: Office App Starts a Shell (teaching example)
id: 6f1c2d84-9b3e-4a57-8c10-e2d7a4b95c36
status: test
description: A document application started a command shell.
author: ABCL TECH course example
date: 2026-10-31
tags:
- attack.execution
- attack.t1059.001
logsource:
category: process_creation
product: windows
detection:
selection:
ParentImage|endswith:
- '\winword.exe'
- '\excel.exe'
Image|endswith:
- '\powershell.exe'
- '\cmd.exe'
condition: selection
falsepositives:
- An approved add-in or macro tool that starts a shell
level: highপ্র ২৪“ব্যর্থ login-এর পরে সাফল্য” rule কীভাবে বানাবেন? মুখে ধারণাটি বলুন। (মাঝারি)
উত্তর: দুটি base ঘটনা: 4625 আর 4624, logon type 3 ও 10, স্থানীয় ঘটনা বাদ। প্রথম গণনা: এক উৎস থেকে ৫ মিনিটে ৫ বা তার বেশি ব্যর্থতা। তারপর ক্রম: ১০ মিনিটের মধ্যে একই উৎস থেকে সাফল্য। এটি পর্ব ৫৬-এর নকশা। সংখ্যাগুলো শুরুর অনুমান, নিজের log দেখে ঠিক করতে হয়।
কী ধরে না: ধীর চেষ্টা, বহু ঠিকানা থেকে ছড়ানো চেষ্টা, আর এক চেষ্টাতেই সঠিক password. এই সীমা নিজে থেকে বললে উত্তর শক্ত হয়।
এবার rule-এর সীমা সংখ্যায় দেখি। নিচের ৮টি সারির উত্তর আগে থেকে জানা, আর ডেটা বানানো। Precision = TP ÷ (TP + FP), মানে যত alert, তার কতটি আসল। Recall = TP ÷ (TP + FN), মানে যত আসল ঘটনা, তার কতটি ধরা পড়ল। অনুমান করুন: কোন সীমায় দুটোর ভারসাম্য ভালো?
// Test a threshold rule on labelled toy data. Each row is one source in a
// 5-minute window: fails = failed logons, ok = followed by a success,
// bad = the true answer, written by the test author.
const rows = [
{ src: 'a', fails: 3, ok: true, bad: false }, // user mistyped
{ src: 'b', fails: 4, ok: true, bad: false }, // user after holiday
{ src: 'c', fails: 5, ok: true, bad: true },
{ src: 'd', fails: 6, ok: true, bad: false }, // old saved password
{ src: 'e', fails: 7, ok: true, bad: true },
{ src: 'f', fails: 9, ok: true, bad: true },
{ src: 'g', fails: 12, ok: false, bad: false }, // blocked, no success
{ src: 'h', fails: 2, ok: true, bad: true }, // slow and careful
];
function score(n) {
const fired = rows.filter(r => r.fails >= n && r.ok);
const tp = fired.filter(r => r.bad).length;
const fp = fired.length - tp;
const fn = rows.filter(r => r.bad).length - tp;
const p = tp + fp ? tp / (tp + fp) : 0, q = tp + fn ? tp / (tp + fn) : 0;
console.log(`n>=${n} alerts=${fired.length} TP=${tp} FP=${fp} FN=${fn} ` +
`precision=${p.toFixed(2)} recall=${q.toFixed(2)}`);
}
[2, 3, 5, 7, 10].forEach(score);
// Base rate: a rule with good rates can still bring mostly false alerts.
const events = 10000, realPerDay = 2, catchRate = 0.9, falseRate = 0.01;
const hit = realPerDay * catchRate;
const noise = (events - realPerDay) * falseRate;
console.log(`events=${events} real=${realPerDay}: true alerts ${hit.toFixed(1)}, ` +
`false alerts ${noise.toFixed(1)}, precision ${(hit / (hit + noise)).toFixed(3)}`);n>=2 alerts=7 TP=4 FP=3 FN=0 precision=0.57 recall=1.00
n>=3 alerts=6 TP=3 FP=3 FN=1 precision=0.50 recall=0.75
n>=5 alerts=4 TP=3 FP=1 FN=1 precision=0.75 recall=0.75
n>=7 alerts=2 TP=2 FP=0 FN=2 precision=1.00 recall=0.50
n>=10 alerts=0 TP=0 FP=0 FN=4 precision=0.00 recall=0.00
events=10000 real=2: true alerts 1.8, false alerts 100.0, precision 0.018n>=2-এ সব আসল ঘটনা ধরা পড়ে, তবে ৭টি alert-এর ৩টি মিথ্যা। n>=7-এ মিথ্যা শূন্য, কিন্তু অর্ধেক ঘটনা ফসকে যায়। n>=10-এ precision 0.00 আসলে “কোনো alert নেই”, ভালো ফল নয়। n>=5-এ দুটোই 0.75. তবে ৮টি নমুনায় মিল মানে শুধু এই ডেটায় মিল। শেষ লাইনটি base rate-এর ফাঁদ: দিনে ১০,০০০ ঘটনায় আসল মাত্র ২টি। ধরার হার ৯০% আর ভুলের হার মাত্র ১% হলেও ১.৮টি সত্য alert-এর পাশে প্রায় ১০০টি মিথ্যা, precision 0.018. এজন্যই alert fatigue হয়।
প্র ২৫একটি rule দিনে ২০০ বার বাজে, প্রায় সবই মিথ্যা। কী করবেন? (মাঝারি)
উত্তর: বন্ধ না করে আগে মাপি। ৩০টি alert-এর নমুনা পড়ে দেখি, কোন কারণে সবচেয়ে বেশি বাজছে। হয়তো কারণটি একটি service account. তখন শর্ত নির্দিষ্ট করি, প্রসঙ্গ জুড়ি, আর দরকারে মেয়াদসহ ব্যতিক্রম লিখি। বদলের পরে পুরোনো সত্য ঘটনাগুলো এখনো ধরা পড়ে কি না, test করি। পুরো rule বন্ধ করলে আওয়াজ কমে, কিন্তু recall-ও যায়।
ফলো-আপ: “ব্যতিক্রমে মেয়াদ কেন?” — কারণ পুরোনো ব্যতিক্রম নিজেই একটি অন্ধ জায়গা হয়ে থাকে।
প্র ২৬IP-ভিত্তিক rule আর আচরণভিত্তিক rule: কোনটি বেশিদিন কাজে লাগে? (মাঝারি)
উত্তর: সাধারণত আচরণভিত্তিক। IOC যেমন IP বা hash সহজে বদলায়, তাই দ্রুত পুরোনো হয়। TTP বদলানো অনেক কঠিন। পর্ব ৫-এর Pyramid of Pain এই কথাটিই বলে। তবে IOC বাদ নয়: চলমান ঘটনায় পুরোনো log-এ খুঁজতে এটি খুব দ্রুত। দুটির কাজ আলাদা।
ATT&CK-এ মেলানো
MITRE ATT&CK-এর tactic বলে “কেন” (লক্ষ্য), আর technique বলে “কীভাবে”. নিচের ছকে সাতটি পরিস্থিতি। v20 অনুযায়ী T1078 চারটি tactic-এ পড়ে: Initial Access, Persistence, Privilege Escalation আর Stealth, আর নিচের ছকে শুধু প্রধান ব্যবহারটি লেখা। পুরোনো লেখায় “Defense Evasion” দেখলে মনে রাখবেন, v19 সেটিকে Stealth আর Defense Impairment-এ ভাগ করেছে। ID মুখস্থ নয়, attack.mitre.org-এ মিলিয়ে নিন।
| পরিস্থিতি | Technique | Tactic | প্রধান log | মত বদলানোর মূল প্রশ্ন |
|---|---|---|---|---|
| ১ · ব্যর্থতার পরে সাফল্য | T1110, পরে T1078 | Credential Access, Initial Access | 4625, 4624, auth log | সাফল্যের পরে কী হলো? |
| ২ · Impossible travel | T1078 | Initial Access | IdP sign-in log | VPN, না নতুন যন্ত্র? |
| ৩ · নতুন admin | T1136, T1098 | Persistence, Privilege Escalation | 4720, 4728, 4732 | অনুমোদিত ticket আছে? |
| ৪ · Process tree | T1566.001, T1204.002, T1059.001 | Initial Access, Execution | EDR, Sysmon 1, 4688 | Parent কে? |
| ৫ · Beaconing | T1071.001 | Command and Control | Proxy, DNS, flow | কোন process, কত বিরল? |
| ৬ · Phishing report | T1566 | Initial Access | Mail gateway, proxy | কেউ তথ্য দিয়েছেন? |
| ৭ · গণহারে বদল | T1486, T1490 | Impact | File audit, EDR | কোন process, ঘোষিত কাজ? |
প্র ২৭ATT&CK-এ ঘটনা মেলালে SOC-এর কী লাভ? কোন ভুল এড়াবেন? (মাঝারি)
উত্তর: তিন লাভ: একই ভাষায় কথা বলা, কোন আচরণে detection নেই তা দেখা (detection gap), আর পরের সম্ভাব্য ধাপ নিয়ে ভাবা। ভুল দুটি। এক, ঘরে সবুজ রং মানেই সুরক্ষিত নয়: একটি rule থাকা মানে পুরো technique ধরা নয়। দুই, mapping রায় নয়: কোনো ঘটনা T1059-এ মিললেই সেটি ক্ষতিকর নয়, কারণ বৈধ কাজও একই আচরণ করে।
প্র ২৮Precision বাড়াতে গিয়ে recall পড়লে কোনটি রাখবেন? (কঠিন)
উত্তর: ক্ষতি আর খরচ দেখে। Ransomware-এর সংকেত বা Domain Admins-এ নতুন সদস্যে একটি ঘটনা ফসকানোর দাম খুব বেশি, তাই বেশি recall, কিছু আওয়াজ মেনে। সাধারণ ঘটনায় queue ভরে গেলে analyst আসল alert-ই দেখেন না, তাই precision বেশি। মাঝের পথ: একই সংকেত কম priority-তে দৈনিক দেখা, অথবা অন্য সংকেতের সাথে জুড়ে তবেই বাজানো।
৮ · নকল ইন্টারভিউ — একটি পূর্ণ সংলাপ
রিভিশন: পর্ব ৬০, পর্ব ৬১, পর্ব ৬২
নিচের সংলাপ কাল্পনিক, ধরন দেখানোর জন্য। আগে ইন্টারভিউয়ারের লাইনগুলো পড়ে নিজে উত্তর দিন, তারপর প্রার্থীর উত্তর দেখুন। প্রার্থী নিখুঁত নন, আর সেটিই শেখার জায়গা।
| কে | কথা |
|---|---|
| ইন্টারভিউয়ার | সকাল ৯টা। Alert: finance-এর rina ঢাকা থেকে login করার ৩০ মিনিট পরে Frankfurt থেকে login. আগে কী দেখবেন? |
| প্রার্থী | আগে তথ্য মিলিয়ে নেব। দুটি login-এর উৎস, যন্ত্র, MFA, আর Frankfurt-এর ঠিকানাটি আমাদের VPN বা কোনো cloud proxy কি না। Finance বলে priority একটু বেশি রাখব। |
| ইন্টারভিউয়ার | ঠিকানাটি VPN নয়। যন্ত্র নতুন। MFA পার হয়েছে। এখন? |
| প্রার্থী | MFA পার হওয়ায় আমি নিশ্চিন্ত হচ্ছি না। ব্যবহারকারী ভুলে অনুরোধে সায় দিতে পারেন, বা session চুরি হতে পারে। Login-এর পরে কী হলো দেখব: inbox rule, ফাইল ডাউনলোড, MFA-তে নতুন পদ্ধতি। |
| ইন্টারভিউয়ার | একটি নতুন inbox rule পেলেন: “invoice” শব্দের mail একটি ফোল্ডারে সরে যায়। কী ভাবছেন? |
| প্রার্থী | এটি বড় সংকেত। কেউ হয়তো টাকার mail লুকিয়ে BEC চালাতে চাইছেন। এখন আমি escalate করব, আর ফোনে rina-র সাথে কথা বলব। Mail বা চ্যাটে নয়, কারণ account-টিই সন্দেহের মধ্যে। |
| ইন্টারভিউয়ার | আপনি কি নিজে password reset করবেন? |
| প্রার্থী | Playbook আর আমার ক্ষমতা যা বলে। অনুমতি থাকলে session revoke আর reset, তবে আগে rule আর log-এর প্রমাণ রেখে। নইলে Tier 2-কে পরিষ্কার অনুরোধ করব। |
| ইন্টারভিউয়ার | এই ধরনের কাজ ATT&CK-এ কোথায় পড়ে? |
| প্রার্থী | Login-টি Valid Accounts, T1078. Inbox rule-এর ID আমার মনে নেই। Technique-এর নাম Email Hiding Rules জাতীয় কিছু, তবে নিশ্চিত নই। আমি ATT&CK-এর সাইটে মিলিয়ে নিতাম। |
| ইন্টারভিউয়ার | পরে জানা গেল rina সত্যিই Frankfurt-এ, আর রিপোর্টের জন্য rule বানিয়েছেন। আপনার সময় নষ্ট? |
| প্রার্থী | না। প্রমাণ দেখে escalate করা ঠিক ছিল। Frankfurt-এর অংশ benign positive. তবে তিনি Frankfurt-এ থাকলে ঢাকার login-টি কার? সেটি না জানা পর্যন্ত case বন্ধ করব না। ভ্রমণের খবর আগে পাওয়ার পথ থাকলেও ভালো হতো। |
| ইন্টারভিউয়ার | শেষ প্রশ্ন। পুরোটি তিন লাইনের handover note-এ বলুন। |
| প্রার্থী | কী হয়েছে: rina-র account, দুই শহর, ৩০ মিনিট, নতুন যন্ত্র, নতুন inbox rule. কী করা হয়েছে: ফোনে নিশ্চিত, ভ্রমণ সত্যি, rule তাঁর নিজের। বাকি: ঢাকার login কার, সেটি এখনই IT-র সাথে মেলানো, তাই case খোলা। |
| মাপকাঠি | ০ · দুর্বল | ২ · ভালো |
|---|---|---|
| পদ্ধতি | এলোমেলো তালিকা | চার প্রশ্নের কাঠামো |
| প্রমাণ | অনুমান তথ্যের মতো বলা | দেখা আর অনুমান আলাদা |
| মত বদলানো | নতুন তথ্যেও একই কথা | নতুন তথ্যে ধারণা বদলায় |
| সীমা | সব নিজে বন্ধ করে দেওয়া | Playbook আর অনুমতি মেনে |
| সততা | ID বানিয়ে বলা | “নিশ্চিত নই”, আর যাচাইয়ের পথ |
| যোগাযোগ | লম্বা গল্প | ছোট, পরিষ্কার note |
প্র ২৯সংলাপের প্রার্থীর সবচেয়ে ভালো তিনটি মুহূর্ত কোনগুলো? কোথায় উন্নতি সম্ভব? (মাঝারি)
ভালো: MFA পার হওয়া দেখে নিশ্চিন্ত না হওয়া। ফোনে আলাদা পথে যাচাই। আর ID মনে না থাকায় বানিয়ে না বলা।
উন্নতি: শুরুতেই বলা যেত, “ঢাকার login-টিও প্রশ্নের মধ্যে”, কারণ দুটির একটিই আসল হতে পারে। ফোনে কথা বলার সময় ব্যবহারকারীর পরিচয় কীভাবে যাচাই করবেন, তা-ও বলা যেত। মনে রাখুন, ATT&CK ID ভুলে যাওয়া দুর্বলতা নয়, বানানো ID দুর্বলতা। নামটি এখানে ঠিকই ছিল: Email Hiding Rules, T1564.008, যা এখন Stealth tactic-এ পড়ে।
প্র ৩০ইন্টারভিউয়ার বললেন, “আপনি ভুল।” তখন কী করবেন? (সহজ)
উত্তর: কখনো আপনি সত্যিই ভুল, কখনো এটি চাপের পরীক্ষা। তর্ক নয়, আবার সোজা হার মানাও নয়। জিজ্ঞেস করুন, “কোন অংশে? আমি এই প্রমাণের ভিত্তিতে বলেছিলাম।” নতুন তথ্য পেলে মত বদলান, আর না পেলে শান্তভাবে যুক্তি বলুন। Incident-এর ঘরেও একই আচরণ দরকার।
৯ · চাকরির অভিজ্ঞতা ছাড়া নিজেকে দেখানো
রিভিশন: পর্ব ৭৫ · ক্যাপস্টোন, পর্ব ৬ · আইন আর নৈতিকতা, পর্ব ৬০
“আপনার তো অভিজ্ঞতা নেই” শুনলে তর্ক করবেন না। অভিজ্ঞতার বদলে প্রমাণ দেখান: আপনি কী বানিয়েছেন, কী ভেঙেছে, কী শিখেছেন। নিচের প্রতিটি কাজ আইনের ভেতরে থেকে করা যায়।
নিজের home lab
নিজের কম্পিউটারে একটি Windows আর একটি Linux virtual machine, বাইরের network থেকে আলাদা। Sysmon বা auditd চালু করে log একটি খোলা SIEM-এ পাঠান।
নিজের যন্ত্র, নিজের networkনিজে ঘটনা ঘটানো
নিজের VM-এ ভুল password দিন, user বানান, দলে যোগ করুন, scheduled task বানান। তারপর log-এ খুঁজে একটি rule লিখুন। এভাবেই 4625, 4720 আর 4732 চোখে দেখা হয়।
Attack টুল লাগে নাঅনুমোদিত অনুশীলন
Blue team ধরনের CTF আর প্রকাশিত নমুনা log নিয়ে তদন্তের অনুশীলন। আয়োজকের নিয়ম আর দেওয়া লক্ষ্যই সীমা।
নিয়ম আগে পড়ুনলেখা
Triage note, ছোট playbook, ৫টি rule আর তার test. ক্যাপস্টোন-এর কাজ গুছিয়ে লিখুন। নিয়োগকর্তা যা পড়তে পারেন, সেটিই প্রমাণ।
পড়ার মতো portfolioসীমা: অন্যের network বা website-এ “শেখার জন্য” কিছু চালাবেন না। ভালো উদ্দেশ্য অনুমতির বিকল্প নয়, আর অনুমতি ছাড়া প্রবেশ অপরাধ হতে পারে (পর্ব ৬)। আগের অফিসের log, গ্রাহকের তথ্য বা ভেতরের নথি portfolio-তে কখনো দেবেন না। এটি আইনি পরামর্শ নয়।
ক্যাপস্টোনের কাজ এক পাতায় এভাবে লিখতে পারেন। “তাজা বাজার” কোর্সের কাল্পনিক প্রতিষ্ঠান, তাই সেটি পরিষ্কার করে বলুন:
Project: Security programme for a fictional online market (course capstone)
Why : To practise moving from risk to detection on one small system
Did : Threat model, risk register, 5 detection ideas with planted-event tests
Result : One rule at 5 failures missed a slow case; I changed the window and
re-tested on sample data only
Limit : Not run in production; numbers are assumed
Learned: A rule is not done until someone has written what to do when it firesওপরের নমুনার ফলাফলের লাইনটি আপনার নিজের কাজ অনুযায়ী বদলাবেন। যা করেননি, তা লিখবেন না। এবার triage note অনুশীলন করি। নিচের checker শুধু ঘরগুলো দেখে, লেখার মান দেখে না। Drill ১-এর ওপর একটি দুর্বল note দেওয়া আছে। চালিয়ে দেখুন, তারপর নিজের note বসিয়ে আবার চালান।
// Check a triage note. Paste your own practice note and run again.
const note = `
What: failed logons then success for sohel on app-2, 23:08
Seen: 5 failures from 203.0.113.77, then a password login
Seen: sudo useradd and tar right after
Verdict: looks bad
`;
const NEED = ['What', 'Seen', 'Asked', 'Not checked', 'Verdict', 'Why', 'Next'];
const lines = note.trim().split('\n');
const has = k => lines.some(l => l.toLowerCase().startsWith(k.toLowerCase() + ':'));
let gaps = 0;
for (const k of NEED) {
const ok = has(k);
if (!ok) gaps++;
console.log(`${ok ? 'ok ' : 'MISSING'} ${k}`);
}
const vague = ['looks bad', 'suspicious', 'seems fine', 'checked'];
for (const l of lines) {
for (const w of vague) {
if (l.toLowerCase().includes(w)) {
console.log(`VAGUE "${l}": say what evidence, and how sure`);
gaps++;
}
}
}
console.log(gaps ? `${gaps} fix(es) before handover` : 'ready for handover');ok What
ok Seen
MISSING Asked
MISSING Not checked
ok Verdict
MISSING Why
MISSING Next
VAGUE "Verdict: looks bad": say what evidence, and how sure
5 fix(es) before handover“Looks bad” কোনো verdict নয়, তাই VAGUE ধরা পড়ল। সবচেয়ে বড় ফাঁক Not checked: পরের জন জানেন না কী দেখা হয়নি। উন্নত note-এ লিখুন: Verdict: True positive, high confidence, Not checked: outbound flow for /tmp/d.tgz, Why: account takeover, I cannot lock accounts. কোনো ঘর ফাঁকা না থাকা ভালো note-এর প্রমাণ নয়, শুধু শুরু। Note-এর ঘরগুলো পর্ব ৬০-এর নমুনা থেকে নেওয়া।
প্র ৩১“আপনার কোনো SOC অভিজ্ঞতা নেই। কেন আপনাকে নেব?” (মাঝারি)
উত্তর: সত্যি কথা দিয়ে শুরু, তারপর প্রমাণ। “Production SOC-এ কাজ করিনি। তবে নিজের lab-এ Windows আর Linux থেকে log একটি SIEM-এ নিয়েছি, পাঁচটি rule লিখে নিজের ঘটানো ঘটনায় test করেছি, আর একটি rule কেন ভুল বাজছিল তা খুঁজে ঠিক করেছি। Note-গুলো আপনাকে দেখাতে পারি।” Helpdesk, system administration বা সফটওয়্যারের কাজ থাকলে তা যোগ করুন, কারণ সেখানে log, ticket আর মানুষের সাথে কথা বলার অভ্যাস আছে।
প্র ৩২“আপনি কি কখনো কোনো সাইটে নিজের দক্ষতা পরীক্ষা করেছেন?” এই প্রশ্নে কী বলবেন? (সহজ)
উত্তর: সীমাটি পরিষ্কার করে বলুন: “শুধু নিজের lab-এ, অথবা আয়োজকের অনুমতি দেওয়া প্ল্যাটফর্মে। অনুমতি ছাড়া কোথাও করিনি।” এই প্রশ্ন আপনার নৈতিকতা মাপে, কারণ SOC-এ আপনার হাতে মানুষের অনেক তথ্য থাকবে। কোনো ত্রুটি চোখে পড়লে আপনি কী করতেন, তাও বলুন: পরীক্ষা না চালিয়ে দায়িত্বশীলভাবে জানাতেন (পর্ব ৬)।
১০ · আচরণগত প্রশ্ন, আপনার প্রশ্ন আর শেষ রিভিশন
রিভিশন: পর্ব ৬০, পর্ব ৫৪, পর্ব ৬৬, Incident management
আচরণগত প্রশ্নে STAR কাঠামো কাজে দেয়: Situation (পরিস্থিতি), Task (আপনার দায়িত্ব), Action (আপনি নিজে কী করলেন), Result (ফল, পারলে সংখ্যায়)। শেষে একটি শেখা। নিচের গল্পগুলো কাল্পনিক, শুধু কাঠামো দেখানোর জন্য। ইন্টারভিউতে নিজের সত্যি ঘটনা বলুন। অভিজ্ঞতা না থাকলে পড়াশোনা, প্রকল্প বা দলের কাজের গল্পও চলে। বানানো গল্প দুটি ফলো-আপেই ভেঙে পড়ে।
প্র ৩৩“আপনার একটি ভুলের কথা বলুন।” (কাল্পনিক উত্তর) (মাঝারি)
উত্তর: কাল্পনিক উদাহরণ। S: “আমার lab প্রকল্পে একটি নতুন rule চালু করেছিলাম।” T: “ব্যর্থ login ধরার দায়িত্ব ছিল আমার।” A: “আমি শুধু আসল ঘটনায় test করেছিলাম, নিরীহ ঘটনায় নয়। বন্ধু দেখালেন, তাঁর ভুল টাইপিংয়েও বাজছে। আমি ভুল মেনে নিরীহ নমুনা যোগ করলাম।” R: “Rule-এ সীমা বদলালাম, আর প্রতিটি rule-এর জন্য দুই রকম test নিয়ম করলাম।”
দেখুন: দোষ অন্যের ঘাড়ে নেই, শেষে অভ্যাসের বদল।
প্র ৩৪“চাপের মধ্যে একই সাথে অনেক কাজ এলে কী করেন?” (কাল্পনিক উত্তর) (মাঝারি)
উত্তর: কাল্পনিক উদাহরণ। S: “একটি দলীয় প্রকল্পের শেষ দিনে তিনটি সমস্যা একসাথে এলো।” T: “আমি দলের সমন্বয়ে ছিলাম।” A: “প্রভাব দেখে ক্রম ঠিক করলাম, প্রত্যেককে একটি করে কাজ দিলাম, আর যেটি পারছিলাম না, তা বলে সাহায্য চাইলাম।” R: “গুরুত্বপূর্ণ দুটি সময়মতো শেষ হলো, তৃতীয়টি পরে জানিয়ে শেষ করলাম।”
SOC-এর সাথে মিল টানুন: এটিই queue-তে priority বেছে নেওয়া, আর সময়মতো escalate করা।
প্র ৩৫“রাতের shift-এ আপনি একা, আর একটি alert বুঝতে পারছেন না।” কী করবেন? (সহজ)
উত্তর: Playbook খুলব, প্রভাব মাপব, যা দেখেছি লিখব, আর সময়সীমার মধ্যে on-call-কে ডাকব। জানি না বলে চুপ থাকা সবচেয়ে বিপজ্জনক। ভুল alarm-এ ডাকলে সামান্য খরচ, আসল ঘটনা চেপে রাখলে অনেক বড়। পরদিন playbook-এর ফাঁক পূরণ করব।
প্র ৩৬“একজন সিনিয়র বললেন alert বন্ধ করে দিন, কিন্তু আপনার সন্দেহ যায়নি।” কী করবেন? (মাঝারি)
উত্তর: সম্মানের সাথে আমার প্রমাণ দেখাব, আর জিজ্ঞেস করব কোন তথ্য আমি দেখিনি। তিনি হয়তো প্রসঙ্গ জানেন। তবু সিদ্ধান্ত তাঁর হলে note-এ লিখব কে, কেন বন্ধ করলেন, আর কোন সন্দেহ বাকি। নিয়মের পথে আরও ওপরে তোলাও সম্ভব, যদি ঝুঁকি বড় হয়। উদ্দেশ্য জেতা নয়, ঘটনাটি ঠিকভাবে রেকর্ডে থাকা।
ইন্টারভিউয়ারকে আপনার প্রশ্ন
- Junior analyst নিজে কোন কাজ করতে পারেন, আর কোনটিতে অনুমোদন লাগে?
- Shift কীভাবে চলে, আর handover কীভাবে হয়?
- একটি false positive থেকে rule বদলাতে কতদিন লাগে, আর কে করেন?
- Alert-এর চাপ দল কীভাবে সামলায়?
- প্রথম ৯০ দিনে একজন নতুন analyst-এর কাছে কী প্রত্যাশা?
মডিউল ধরে দ্রুত রিভিশন
প্রতিটি মডিউলের একটি করে প্রশ্ন, যা SOC-এর চোখে দেখা। উত্তর না এলে পাশের পর্ব পড়ুন।
| মডিউল | নিজেকে জিজ্ঞেস করুন | পর্ব |
|---|---|---|
| ১ · ভিত্তি | Threat, vulnerability আর risk আলাদা করে বলতে পারি? | ২, ৫, ৬ |
| ২ · Cryptography | Log-এ MD5 hash দেখলে তার সীমা কী? | ৯, ১২ |
| ৩ · Identity | MFA কোন ধরনের চুরি থামায় না? | ১৬, ১৭, ২০ |
| ৪ · Network | IDS-এর false positive কীভাবে কমাব? | ২৩, ২৪, ২৬ |
| ৫ · Endpoint | KEV-তে থাকা CVE আগে কেন? | ২৯, ৩১, ৩২ |
| ৬ · Web | WAF-এর log-এ alert মানেই কি app আপস? | ৩৭, ৩৯, ৪৪ |
| ৭ · নিরাপদ software | Pentest-এর ঘটনা SOC কীভাবে আলাদা করবে? | ৫০, ৪৮ |
| ৮ · মানুষ | দোষারোপ করলে report কেন কমে? | ৫২, ৫৪ |
| ৯ · Detection | MTTD-র ফাঁদ কী? | ৫৬, ৫৯, ৬০ |
| ১০ · Incident | Containment আর eradication-এর পার্থক্য কী? | ৬১, ৬২, ৬৩ |
| ১১ · Governance | Log রাখার মেয়াদ কে ঠিক করেন? | ৬৭, ৭০ |
| ১২ · Cloud | Cloud-এ login-এর log কোথায়? | ৭২, ৭৪, ৭৫ |
শেষ সাত দিনের পরিকল্পনা
দিনে ঘণ্টা দুয়েক ধরে সাজানো। নিজের সময় অনুযায়ী বদলে নিন। প্রতিদিন উত্তর জোরে বলুন।
| দিন | কাজ | শেষে যা পারবেন |
|---|---|---|
| ১ | অংশ ২, port আর handshake | HTTPS visit-এর ৬ স্তর মুখে বলা |
| ২ | অংশ ৩, event ID, auth log | Event টেবিল না দেখে ঘটনার ধরন বলা |
| ৩ | অংশ ৪, তিনটি drill | নিজের সময়রেখা, দেখা আর অনুমান আলাদা |
| ৪ | অংশ ৫ ও ৬, সাত পরিস্থিতি | প্রতিটি দুই মিনিটে চার প্রশ্নে |
| ৫ | অংশ ৭, rule আর ATT&CK | একটি rule-এর ধারণা, সীমা, আর mapping |
| ৬ | অংশ ৯, ১০, নিজের ২টি STAR গল্প, note | “অভিজ্ঞতা নেই”-এর সৎ উত্তর |
| ৭ | বন্ধুর সাথে অংশ ৮-এর মতো নকল ইন্টারভিউ | ৩০ মিনিটের কথোপকথন, নিজের নম্বর |
আগের দিন সন্ধ্যায় নতুন কিছু শিখবেন না। আপনি কোনো vendor certificate-এর পথে থাকলে তার syllabus আলাদা, আর এই কোর্স একা তার পূর্ণ প্রস্তুতির দাবি করে না।
AI-এর যুগে SOC ইন্টারভিউর প্রস্তুতি
AI একজন ধৈর্যশীল নকল ইন্টারভিউয়ার হতে পারে। তবে সে প্রায়ই নেই এমন CVE আর event ID বানায়, পুরোনো পরামর্শ দেয়, ভুল ATT&CK ID বলে, আর একটি log দেখে অতিরিক্ত আত্মবিশ্বাসে রায় দেয়। Prompt-এ আসল log, নাম, IP বা ticket দিলে তথ্য ফাঁস হতে পারে। Live ইন্টারভিউতে AI ব্যবহারের নিয়ম আগে জেনে নিন, আর ভাঙবেন না।
AI-কে উত্তর লিখতে না বলে আপনাকে চেপে ধরতে বলুন। কোনো অফিসের আসল ডেটা দেবেন না।
নিজেকে যাচাই করুন
ভুল হলে কারণসহ ব্যাখ্যা পাবেন, আবার চেষ্টাও করতে পারবেন।
ক্রমএকটি alert এলে SOC analyst-এর ভালো কাজের ধাপগুলো সঠিক ক্রমে সাজান (▲▼ চেপে সরান)
- Alert-এ কী লেখা আছে, শুধু তথ্য পড়া
- User, যন্ত্র আর আগে-পরের প্রসঙ্গ জোড়া
- কী দেখলে মত বদলাবে, তা যাচাই করা
- Verdict ঠিক করে escalate বা close করা
- Note লেখা আর rule-এ ফিডব্যাক দেওয়া
(সহজ) একটি Windows server-এর Security log-এ 4624 event, logon type 10. এর অর্থ কী?
- Remote Desktop-এ ব্যর্থ logon
- Remote Desktop-এ সফল logon
- File share-এ সফল network logon
- একটি service চালু হলো
(সহজ) Flow log-এ দেখা গেল, একটি যন্ত্র একটি port-এ SYN পাঠাল, আর উত্তরে RST এলো। সবচেয়ে যুক্তিসঙ্গত ব্যাখ্যা কোনটি?
- TCP সংযোগ সফলভাবে হয়েছে
- Host বন্ধ, তাই কোনো উত্তর যায়নি
- TLS certificate-এর মেয়াদ শেষ
- Host সাড়া দিচ্ছে, কিন্তু ওই port-এ কেউ শুনছে না
(মাঝারি) একটি Windows যন্ত্রে 1102 event এলো, মানে audit log মোছা হয়েছে। Analyst-এর ভালো প্রথম কাজ কোনটি?
- SIEM-এ ওই যন্ত্রের আগের log দেখা, আর change ticket খোঁজা
- যন্ত্রটি সঙ্গে সঙ্গে বন্ধ করে দেওয়া
- Disk ভরে গেছে ধরে নিয়ে উপেক্ষা করা
- যন্ত্রের লোকাল log পড়ে দোষী ঠিক করা
(সহজ) IT দলের ঘোষিত ও অনুমোদিত একটি scan একটি detection rule বাজিয়ে দিল। Rule-এর যুক্তি ঠিকই ছিল। এই alert-এর verdict কী?
- True positive
- False positive
- Benign positive
- False negative
(মাঝারি) EDR alert: একটি PC-তে powershell.exe, command line-এ লম্বা encoded লেখা। কোন তথ্য আপনার মত সবচেয়ে বেশি বদলাতে পারে?
- Parent process কে, আর তার পরে কী হলো
- PowerShell-এর version কত
- PC-র মালিকের নাম কী
- Command line-এর দৈর্ঘ্য ঠিক কত অক্ষর
(সহজ) একই account দুটি শহর থেকে ৩০ মিনিটের ব্যবধানে sign in করল। শহর দুটির দূরত্ব ৬,০০০ km. ধরে নেওয়া সীমা ৯০০ km/h. হিসাব অনুযায়ী গতি কত, আর সিদ্ধান্ত কী?
- ২০০ km/h, স্বাভাবিক
- ১২,০০০ km/h, সীমার ওপরে; আগে VPN আর যন্ত্র দেখা
- ৩,০০০ km/h, account দখল প্রমাণিত
- ৬,০০০ km/h, সঙ্গে সঙ্গে close
(মাঝারি) দুটি সংযোগ: A-র বিরতির CV 0.002, ১টি যন্ত্র, গন্তব্য ৩ দিনের পুরোনো। B-র CV 0.000, ১৮০টি যন্ত্র, গন্তব্য ১,৫০০ দিনের পুরোনো। কোনটি আগে তদন্ত করবেন?
- B, কারণ তার CV সবচেয়ে কম
- দুটিই সমান, কারণ দুটোই নিয়মিত
- কোনোটিই না, কারণ নিয়মিত সংযোগ সবসময় নিরীহ
- A, কারণ নিয়মিততার সাথে বিরল আর নতুন গন্তব্য মিলেছে
(মাঝারি) একটি rule-এর পরীক্ষায় TP = 6, FP = 2, FN = 3. Precision আর recall কত?
- Precision 0.75, recall 0.67
- Precision 0.67, recall 0.75
- Precision 0.67, recall 0.67
- Precision 0.55, recall 0.55
(কঠিন) দিনে ১০,০০০ ঘটনার মধ্যে ২টি আসল ক্ষতিকর। একটি rule আসল ঘটনার ৯০% ধরে, আর নিরীহ ঘটনার ১%-এ ভুল করে বাজে। Precision প্রায় কত?
- ৯০%
- ৯৯%
- ৫০%
- ১.৮%
(মাঝারি) একজন কর্মী একটি সন্দেহজনক mail report করলেন। Header-এ SPF, DKIM আর DMARC সব pass. এ থেকে কী বলা যায়?
- Mail নিরাপদ, তাই close করা যায়
- ডোমেইনের সাথে মিল আছে, কিন্তু mail ক্ষতিকর হতে পারে
- এটি নিশ্চিতভাবে phishing
- Header-এর ফল ইন্টারভিউতে অপ্রাসঙ্গিক
(মাঝারি) একটি PC থেকে file share-এর বহু ফাইল দ্রুত rename হচ্ছে। Process অচেনা, canary file-ও ছোঁয়া হয়েছে। Playbook অনুমতি দেয়। কোন কাজটি সবচেয়ে ভালো?
- PC-র বিদ্যুৎ বন্ধ করে দেওয়া
- সকাল পর্যন্ত অপেক্ষা করে IT-কে জানানো
- PC-কে network থেকে আলাদা করা, আর সঙ্গে সঙ্গে escalate
- বদলে যাওয়া ফাইলগুলো নিজে মুছে ফেলা
(মাঝারি) Windows-এ একটি নতুন account বানানো হলো, আর সেটি Administrators দলে গেল। MITRE ATT&CK-এ কোন মিলটি সবচেয়ে ঠিক?
T1486, ImpactT1071, Command and ControlT1136আরT1098, PersistenceT1566, Initial Access
(সহজ) একজন শিক্ষার্থী SOC-এর জন্য হাতে-কলমে অনুশীলন করতে চান। কোন পথটি আইনি আর নিরাপদ?
- নিজের কম্পিউটারের আলাদা virtual machine-এ ঘটনা ঘটিয়ে log পড়া
- চেনা একটি দোকানের সাইটে দুর্বলতা খোঁজা
- আগের অফিসের আসল log বাড়িতে এনে অনুশীলন
- বিশ্ববিদ্যালয়ের network-এ লুকিয়ে traffic ধরা
শব্দকোষ
লেখার মধ্যে ডটেড দাগ দেওয়া শব্দে মাউস রাখুন বা চাপুন — অর্থ দেখাবে। এই পর্বের সব শব্দ এখানে একসাথে:
মনে রাখুন
- Alert প্রমাণ নয়, সন্দেহ। উত্তর দিন চার প্রশ্নে: কী দেখছি, আগে কী দেখব, কী দেখলে মত বদলাবে, escalate না close.
- ভিত্তির উত্তরে যোগ করুন: এটি log-এ কীভাবে দেখা যায়। IP মানে একজন মানুষ নয়, আর ঘড়ি মিললে তবেই গল্প মেলে।
- Log পড়ায় আগে সময়রেখা, তারপর দেখা আর অনুমান আলাদা, শেষে কী প্রমাণ হয়নি।
- Rule-এর সীমা নিজে বলুন। Precision, recall আর base rate জানলে আওয়াজের কারণ বোঝা যায়। ATT&CK ভাষা দেয়, রায় নয়।
- অভিজ্ঞতা না থাকলে নিজের lab, note আর সৎ STAR গল্প। অনুমতি ছাড়া কোথাও কিছু নয়, আর “নিশ্চিত নই” বলতে ভয় নয়।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- পর্ব ৮০ · Security engineer ইন্টারভিউ — নকশা, secure coding, cloud আর আচরণগত প্রশ্নপরবর্তী পর্বনকশা, secure coding, cloud আর আচরণগত প্রশ্নের প্রস্তুতি।
- পর্ব ৬০ · SOC পরিচালনামূল পর্বTier, triage, playbook, metric আর note-এর নমুনা।
- পর্ব ৫৬ · SIEM আর detection ruleগভীরে যানSigma, correlation আর tuning-এর পূর্ণ আলোচনা।
- পর্ব ৭৫ · ক্যাপস্টোনPortfolioযে প্রকল্প লিখে আপনি অভিজ্ঞতার প্রমাণ দেবেন।
- সাইবার নিরাপত্তা · কোর্স হোম৮০টি পর্বপুরো কোর্সের রোডম্যাপ।
- Networking ইন্টারভিউপাশের ট্র্যাকNetwork-এর প্রশ্নে আরও গভীর অনুশীলন।
- Centralized loggingপাশের ট্র্যাকLog কীভাবে এক জায়গায় আসে, চালানোর দিক থেকে।