ReZa AdineH_Channel

A detection rule existing is not the same as a detection capability working. That distinction is the reason I built TID-CMM — the Threat-Informed Detection Capability Maturity Model. We often talk about MITRE ATT&CK coverage as if a mapped rule means a technique is covered. But consider a detection that: is mapped to the correct ATT&CK technique, is enabled in the SIEM, depends on telemetry that only reaches part of the environment, has never been tested against the actual behaviour, and targets an adversary that may not even be relevant to the organisation. Is that really coverage? I don't think it is. TID-CMM looks at detection capability as a connected system: Threat Intelligence → Threat Modeling → Telemetry → Detection Engineering → Adversarial Validation → Analytics & Hunting → Incident Response → Continuous Improvement The current model contains 8 domains and 58 sub-capabilities, scored from 0–5 with explicit evidence requirements. It also introduces something I consider particularly important: Validated Coverage. For an in-scope ATT&CK technique: 0 — No telemetry 1 — Telemetry exists 2 — Detection logic exists 3 — Detection has been validated by emulation And validation expires. A detection that worked eighteen months ago—before platform migrations, parser changes and rule modifications—should not automatically remain “proven” forever. I also deliberately added scoring constraints so an assessment cannot easily flatter itself. Detection Engineering cannot significantly outrun telemetry. High maturity claims require evidence. Validation limits what the rest of the model can credibly claim. And telemetry and detection should ultimately be driven by threat intelligence and threat modeling rather than by whichever content pack happens to be available. Everything is open and free to use. The site includes the interactive assessment, full white paper, assessment guide, scoring methodology, Excel workbook, worked example, ATT&CK datasets, machine-readable model, offline tool and API. https://tid-cmm.xyz/ If you work in Detection Engineering, SOC, Threat Intelligence, Purple Teaming, Incident Response or Security Architecture, I'd especially like your criticism. Don't tell me the model looks good. Tell me where it is wrong. #CyberSecurity #DetectionEngineering #MITREATTACK #SOC #ThreatIntelligence #PurpleTeam #IncidentResponse #TIDCMM

Hey guys, Six months ago, I published Version 1 of the UTIOM Framework. Today, I’m happy to share the next step: Version 1 of the UTIOM Assessment Toolkit, built directly around the model.The idea is simple: move from understanding the framework to actually assessing where your security operations stand today — and where there is room to improve.Give it a try and see where you are:👉 https://utiom.xyz If you have any questions, feedback, or even disagreements with the assessment approach, feel free to reach out to me directly.I’d be genuinely happy to help — and even happier to hear your thoughts and experiences.More to come. #UTIOM #CyberSecurity #SecurityOperations #SOC #ThreatDetection #IncidentResponse

UTIOM Framework v1.0 – Author Edition Unified Threat-Informed Operations Model After more than 15 years working in SOCs, Incident Response, and detection engineering, I finally wrote down the operating model I wish I had much earlier. I’m sharing UTIOM v1.0 (Unified Threat-Informed Operations Model) openly and for free. This is not: a vendor framework a tool comparison a compliance checklist UTIOM is an operating model for security operations that connects vision and strategy to threat modeling, detection engineering, and incident response, and treats SecOps as a living product, not a static function. The book reflects real-world experience: threat modeling with attack paths and coverage gaps visibility and detection engineered before incidents happen purple teaming and deception as validation, not theater incident response as a continuous system, not a phase It’s aligned with modern realities like NIST CSF 2.0, SOC maturity models, and DORA, but it’s not driven by compliance. It’s driven by outcomes.

خلاصهٔ گزارش بررسی مراکز عملیات امنیتی SANS – سال ۲۰۲۵ گزارش سالانه SANS دربارهٔ مراکز عملیات امنیتی (SOC) در سال ۲۰۲۵، نهمین نسخه از این نظرسنجی است که به بررسی ساختار، چالش‌ها، ابزارها و روندهای رایج در SOCها می‌پردازد. نکات کلیدی: ۸۵٪ از پاسخ‌دهندگان اعلام کردند که هشدارهای امنیتی از طریق EDR مهم‌ترین عامل شروع واکنش هستند. ۷۹٪ از SOCها به‌صورت ۲۴ ساعته و در ۷ روز هفته فعال هستند. ۶۲٪ از کارکنان SOC معتقدند که سازمانشان برای حفظ نیروهای توانمند تلاش کافی نمی‌کند. ۴۲٪ از تیم‌ها همهٔ داده‌ها را بدون برنامه‌ریزی مشخص در SIEM ذخیره می‌کنند. ۴۳٪ از مدیران استخدام، مهارت کار با SIEM را مهم‌ترین معیار فنی می‌دانند. استفاده از هوش مصنوعی و یادگیری ماشین رو به افزایش است، اما بیشتر به‌صورت پراکنده و بدون ادغام ساختاری انجام می‌شود. تجزیه و تحلیل تهدیدها (Threat Intelligence) عمدتاً برای واکنش به حادثه استفاده می‌شود و کمتر به شکل استراتژیک در تصمیم‌سازی کاربرد دارد. نتیجه‌گیری: در حالی‌که SOCها در پوشش‌دهی و ابزارهای پایه‌ای پیشرفت کرده‌اند، اما مشکلات اصلی همچنان پابرجاست: ضعف در نگه‌داشت نیروهای متخصص، عدم شفافیت بودجه، و نبود رویکردهای مهندسی‌شده در تشخیص تهدیدها. در عصر تهدیدات پیچیده، «بیشتر داده» کافی نیست باید به دنبال «تشخیص بهتر» بود.

برگرفته از بلاگهای قدیمی گارتنر این مفهوم ساده اما تاثیرگذاره: تا زمانی که ندونی قراره با دادهات دقیقاً چه کار کنی یا اون رو چطور به نمایش بذاری (چه به صورت آلارم، داشبورد، گزارش یا الگوریتم تحلیل رفتاری)، نباید وارد SIEMات بشه! به عبارت دیگه، ابزار SIEM تنها زمانی باید دادهای رو بپذیره که اون داده مستقیماً به یک هدف مشخص، یک گزارش تعریف شده یا حتی یک الگوریتم معنادار مرتبط باشه. نه اینکه فقط چون میتونیم، جمع آوریش کنیم. در این مدل، «هدف»ها نیازهای امنیتی رو مشخص میکنن، نیازها «موارد استفاده» (Use Case) میسازن، 🛠و این موارد، مشخص میکنن چه دادهای باید جمع آوری بشه. اما واقعیت اینه که اکثر سازمانها هنوز دارن با این رویکرد جلو میرن: «خب حالا که کلی لاگ جمع کردیم و SIEM هم داره کند میشه، چطوری ازش استفاده کنیم؟!» بله، همچنان مدل ورودی محور رایجه… 📍مثال: اگر هدفت اینه که تشخیص بدی آیا کاربرات سوءاستفادهی  احتمالی از دسترسی ها دارن یا نه (یا اینکه دسترسی ها دزدیده شده)، باید: تحلیل رفتار کاربر (UEBA) قوانین همبستگی ورودها و گزارشگیری از فعالیتهای دسترسی رو داشته باشی؛ بنابراین لاگهای مربوط به احراز هویت، از Syslog لینوکس گرفته تا Event Log ویندوز و VPN، همه باید طبق این هدف وارد SIEM بشن. تفاوت بزرگ اینجا با مدیریت لاگ عمومی (Log Management) مثل Hadoop یا Splunk اینه که در اونجا مدل ورودی محور خیلی خوب جواب میده. اونجا میتونی بگی "همه چی رو جمع کن، بعداً میبینیم به چه درد میخوره". ولی اگه همین کار رو با SIEM بکنی، احتمالاً داری با دست خودت یک کابوس کند و بیکارایی از دادههای بیربط (یا همون «داده-آشغال») بسازی. چرا مهمه؟ چون: هر خط لاگی که وارد SIEM میشه، «هزینه» داره! نه فقط از لحاظ منابع پردازشی، بلکه گاهاً واقعاً هزینه ی دلاری سنگینی به سیستم تحمیل میکنه. سیستمی که بتونه ۱۰۰ هزار رویداد در ثانیه تحلیل کنه، میتونه قیمتش به راحتی ۷ رقمی بشه. بله، مدل خروجی محور سخت تره. وسوسه همیشه هست که "فعلاً لاگ رو بگیر، بعداً یه فکری میکنیم". ولی توی واقعیت، خیلی وقتها "بعداً" هیچوقت نمیاد، یا بدتر از اون، اون SIEM هرگز از اون داده ها استفاده نمیکنه. ✅ راهکار؟ ترکیب هوشمندانه: مدیریت لاگ = ورودی محور تحلیل SIEM = خروجی محور حتی در معماریهای امروزی که SIEM خودش ماژول لاگ منیجمنت داره، باید این تفکیک حفظ بشه. مثلاً لاگ منیجر همه داده ها رو میگیره، ولی فقط بخشی از اونها وارد موتور تحلیل و داشبورد SIEM میشن. پس لطفاً قبل از اینکه اجازه بدی لاگی وارد SIEM بشه، دقیق فکر کن که قراره باهاش چه کار کنی!

To the Cybersecurity folks : I have some questions for you, How closely are we really tracking cyber threat movements? How prepared are we to face them? What percentage of these threats are actually targeting us? How secure are we truly? How confident are we in our ability to detect and understand them when they strike? And how capable are we of recovering and returning to normal? Have our organizational security strategies genuinely evolved in the right direction? Or are we just watching an aquarium full of colorful logs, without meaningful security operations behind them? It’s time to ask the hard questions. Think Smarter, Stay Secure Stayed tuned. 😉 #cybersecurity #threatdetection #incidentresponse #soc #threatintelligence #MinimalCyber #infosec #securitystrategy #ThreatInformed

Detection in 60 Seconds T1059.001 – PowerShell Abuse “Detection in 60 Seconds” T1059.001 – PowerShell Abuse Visual: Dark background + terminal with PowerShell prompt or blue glow ⚠️ Why It Matters Attackers often use PowerShell to: Download payloads Execute obfuscated scripts Move laterally Mimikatz, Cobalt Strike, and Empire love this technique. 🔍 Detection Logic Detect suspicious PowerShell usage via: EventCode=4104 (ScriptBlock logging) powershell.exe + long base64 command line Network connections made by PowerShell 💡 Sigma-like logic: process_name: powershell.exe AND command_line: "*-enc*" OR "*FromBase64String*" OR event_id: 4104 AND script_content: "*Invoke*" 💡 Pro Tip 🟧 Enable ScriptBlock logging (Event ID 4104) 🟧 Look for execution policy bypass 🟧 Watch for child processes like powershell -> rundll32 or powershell -> mshta ❓ Call to Action How do you baseline PowerShell usage in your environment?

Threat Intel Tip of the Day "Threat actors don’t break in, they log in." Stolen creds > brute force Session hijack > zero-day Focus on identity abuse, not just perimeter breaches. #MinimalCyber #SOC #ThreatInformed #ThreatIntelligence #CyberSecurity

🚨 New Threat: Mocha Manakin – Node.js Backdoor via Paste-and-Run A new attack method tricks users into copying fakeCAPTCHA PowerShell from a website dropping a stealthy backdoor called NodeInitRAT. 🧠 What it does: Delivered via fake CAPTCHA prompt Executes via PowerShell (no download) Installs Node.js RAT (NodeInitRAT) Establishes persistence + sends data via Cloudflare tunnels Enables remote command execution ⚠️ Possibly linked to Interlock ransomware groups. 🔍 Defenders, watch for: PowerShell from browser copy/paste Node.js processes modifying registry Unexpected Cloudflare tunnel traffic 🛡️ Threat Intelligence isn’t about feeds it’s about detecting intent. #CyberThreat #MochaManakin #NodeInitRAT #ThreatIntel #SOC #CyberDefense #TelegramCyberAlert

“Your detection rule isn’t intelligence. It’s a habit you wrote in YAML.” Detection without thought is just automation. Every rule you write should be tied to: A real threat path A modeled attacker technique A response plan Build intelligence, not just triggers. #MinimalCyber #ThreatIntel #DetectionEngineering #ThinkSmarterStaySecure

The future of SecOps isn’t just about AI. It’s about AI that understands how analysts think. Context. Timelines. Doubt. Mental bookmarks. Most current products are written for screens not for people who’ve ever stayed late to rule out a breach. AI can help. But first, it needs to observe the investigator. #MinimalCyber #RezaAdineh #ThinkSmarterStaySecure

https://www.linkedin.com/pulse/cyber-threat-profiling-understanding-different-actors-reza-adineh

Subscribe on LinkedIn https://www.linkedin.com/build-relation/newsletter-follow?entityUrn=7038140619654885376

https://redcanary.com/blog/rmm-software/

این لینک کمی قدیمیه ولی به نظرم خیلی گویا هست و جالب. از وسعت هستی. https://htwins.net/scale2/

SANS 2023 SOC Survey https://t.me/AdineHReZa

SOC Model Guide https://www.gartner.com/doc/reprints?id=1-2C6FPM26&ct=230103&st=sb

🔻 قدیمی ترین دانشگاه های جهان 🔹 دانشگاه بولونیا در ایتالیا با 935 سال قدمت، قدیمی ترین دانشگاه فعال جهان است •ecoinpic• @OfficialPersianTwitter

https://www.linkedin.com/pulse/cyber-threat-profiling-understanding-different-actors-reza-adineh/