SIEM অপারেশনে ভূমিকা: একটি ব্যবহারিক Blue Team গাইড

Security Information and Event Management (SIEM) প্ল্যাটফর্মগুলি বেশিরভাগ Security Operations Centers (SOCs) এর কেন্দ্রে অবস্থান করে। এগুলি লগ সংগ্রহ করে, ইভেন্টগুলির সম্পর্ক স্থাপন করে এবং সতর্কতা পৃষ্ঠভূমি করে যা বিশ্লেষকদের triage এবং তদন্ত করতে হয়। এই গাইডটি মূল অপারেশনাল ওয়ার্কফ্লোর মধ্য দিয়ে যায় যাতে আপনি একজন SIEM বিশ্লেষকের মতো চিন্তা করতে শুরু করতে পারেন, আপনার সংস্থা যেকোনো প্ল্যাটফর্ম (Splunk, Elastic, Microsoft Sentinel, QRadar, ইত্যাদি) ব্যবহার করে না কেন।

একটি SIEM আসলে কী করে

এর মূলে, একটি SIEM তিনটি কাজ করে: endpoints, নেটওয়ার্ক ডিভাইস, অ্যাপ্লিকেশন এবং ক্লাউড সেবা থেকে লগ সংগ্রহ করা; সেই ডেটা একটি সামঞ্জস্যপূর্ণ স্কিমায় নর্মালাইজ করা; এবং alerts তৈরি করতে detection rules ব্যবহার করে ইভেন্টগুলির সম্পর্ক স্থাপন করা। বিশ্লেষকরা তখন সেই alerts একটি triage এবং investigation lifecycle এর মাধ্যমে কাজ করে। এই পাইপলাইনটি বোঝা আপনাকে ডেটা ভুল দেখাচ্ছে বা alerts হারিয়ে যাচ্ছে মনে হলে সমস্যা নির্ণয় করতে সাহায্য করে।

লগ সোর্স সেটআপ করা

কোনো detection logic গুরুত্বপূর্ণ হওয়ার আগে, আপনার নির্ভরযোগ্য ডেটা দরকার। সাধারণ সোর্সগুলির মধ্যে রয়েছে:

• Endpoint telemetry (EDR agents, Windows Event Logs via Sysmon)
• Network data (firewall logs, DNS queries, proxy logs, NetFlow)
• Authentication logs (Active Directory, VPN, SSO providers)
• Cloud audit logs (AWS CloudTrail, Azure Activity Logs, GCP Audit Logs)

নতুন সোর্স onboard করার সময়, timestamp accuracy যাচাই করুন, field parsing সঠিক তা নিশ্চিত করুন এবং ingestion volume প্রত্যাশিত baselines এর বিরুদ্ধে চেক করুন। একটি misconfigured parser নীরবে detections ভেঙে ফেলে কোনো ত্রুটি নিক্ষেপ না করেই, তাই নিয়মিত parsed fields এর বিরুদ্ধে raw events spot-check করুন।

Detection Rules লেখা এবং টিউন করা

বেশিরভাগ SIEMs কোনো ফর্মের correlation search বা detection rule syntax ব্যবহার করে। Splunk এর SPL এ একটি সরল উদাহরণ এর মতো দেখতে পারে:

index=auth sourcetype=windows EventCode=4625
| stats count by user, src_ip
| where count > 10

এটি 10টির বেশি failed logon attempts সহ অ্যাকাউন্টগুলিকে চিহ্নিত করে, একটি ক্লাসিক brute-force indicator। যখন rules তৈরি করেন:

1. সংকীর্ণভাবে শুরু করুন, তারপর false positive rate এর ভিত্তিতে বিস্তৃত করুন।
2. প্রতিটি rule কে একটি MITRE ATT&CK technique এ ম্যাপ করুন context এবং coverage tracking এর জন্য।
3. rule এর intent, expected data source, এবং পরিচিত false-positive scenarios ডকুমেন্ট করুন।
4. বাস্তবসম্মত thresholds সেট করুন — খুব সংবেদনশীল এবং বিশ্লেষকরা noise এ ডুবে যান; খুব loose এবং প্রকৃত threats ফসকে যায়।

Alert Triage Workflow

একবার একটি alert ফায়ার হয়, বিশ্লেষকের কাজ হল উত্তর দেওয়া: এটি কি malicious, এবং এটি escalation প্রয়োজন? একটি ব্যবহারিক triage checklist:

• Alert validate করুন — অন্তর্নিহিত ইভেন্ট আসলে ঘটেছে এবং parsing artifact ছিল না তা নিশ্চিত করুন।
• Context দিয়ে enrich করুন — asset criticality, user role, source IP এর geolocation, এবং একই host এর সম্পর্কিত recent alerts চেক করুন।
• Pattern জন্য চেক করুন — user, IP, বা hash এর উপর একটি বিস্তৃত সময় জানালা জুড়ে pivot করুন এটি isolated বা বিস্তৃত campaign এর অংশ তা দেখতে।
• Classify করুন — true positive, false positive, বা benign true positive (প্রকৃত activity, কিন্তু malicious নয়, যেমন একজন admin এর legitimate script)।
• Escalate বা close করুন — যেকোনো উপায়ে আপনার reasoning document করুন; closed alerts এখনও audit purposes এর জন্য স্পষ্ট justification দরকার।

কার্যকর Dashboards তৈরি করা

Dashboards নির্দিষ্ট operational প্রশ্নের উত্তর দেওয়া উচিত, শুধু প্রভাবশালী দেখতে হবে না। উপযোগী উদাহরণগুলি অন্তর্ভুক্ত করে:

• গত 24 ঘন্টায় শীর্ষ failed authentication sources
• Alert volume দ্বারা severity এবং analyst assignment
• Data source health (ingestion lag, drop-offs)
• Detection coverage mapped against ATT&CK tactics

Dashboard sprawl এড়িয়ে চলুন — একটি handful high-signal views বিশটি rarely-checked panels এর চেয়ে ভাল।

False Positive Fatigue পরিচালনা করা

Alert fatigue একটি SOC এ সবচেয়ে বড় operational risks এর মধ্যে একটি। এটি মোকাবেলা করুন দ্বারা:

• নিয়মিত closed alerts পর্যালোচনা করুন recurring false-positive patterns চিহ্নিত করতে।
• Known-benign activity suppress করুন documented exceptions দিয়ে (blanket rule disabling নয়)।
• Mean time to triage এবং mean time to respond metrics হিসাবে track করুন bottlenecks ধরতে।
• Detection rule review cycles rotate করুন যাতে stale, noisy rules refined বা retired হয়।

Documentation এবং Handoff

প্রতিটি investigation একটি paper trail ছেড়ে যাওয়া উচিত: কী alert trigger করেছে, কী check করা হয়েছে, কী সিদ্ধান্ত পৌঁছেছে, এবং যেকোনো follow-up actions। এটি shift handoffs, compliance audits, এবং analyst turnover survive করে institutional knowledge তৈরি করার জন্য গুরুত্বপূর্ণ। একটি সরল runbook template প্রতি alert type — investigation steps, escalation contacts, এবং expected evidence — চাপের অধীনে উল্লেখযোগ্য সময় বাঁচায়।

Hands-On Practice পাওয়া

SIEM fluency তৈরি করার দ্রুততম উপায় হল পুনরাবৃত্তি: sample logs ingest করুন, পরিচিত attack techniques এর বিরুদ্ধে একটি handful detection rules লিখুন, এবং সম্পূর্ণ triage cycle end to end practice করুন। বিনামূল্যের datasets এবং open-source SIEM stacks (যেমন Elastic Stack) এর জন্য এগুলি চমৎকার low-cost environments।

Blue team fundamentals এ গভীর যেতে প্রস্তুত? Log analysis, incident response workflows, এবং detection engineering এ সম্পর্কিত Korra Studio segments অন্বেষণ করুন আপনার SOC skill set তৈরি রাখতে।