A rule mapped to MITRE is not the same as real coverage

This gets attention alot so wanted to share something i have experinece working in SOCs, especially in larger/financial sectors. a lot of teams say they have coverage for a MITRE technique because there is a rule somewhere that maps to it. but to me, that is not really coverage. there is a big difference between: we have a tuned alert that actually works and an analyst will look at we have the data, but no alert, so we only find it if someone hunts for it we don’t have the data at all the problem is a lot of orgs report #2 as “covered” because a log source exists or because some old rule is mapped to ATT&CK. but if it never fires, fires too much, or nobody trusts it, then it’s not really coverage. few gaps i noticed through out my experience: Valid accounts / T1078 almost every serious incident uses legit creds at some point. this is hard to detect with simple rules. you need baseline and behavior, not just “login success from X.” Defense evasion / disabling tools if someone can stop EDR, disable logging, or weakin controls without a strong alert, that’s a serious gap. and this is more common than people admit. New account creation / T1136 this one is funny because the event is usually there. Windows 4720 is not hard to collect. but many places still don’t alert properly on risky account creation, especially when it happens outside normal admin process. i think the fix is not complicated, but it requires honesty. when we say “covered,” we should mean.. does the data exist? does the detection work? is it tuned? will an analyst actually see it? is there a response step tied to it? otherwise we are just building a nice ATT&CK heatmap for leadership that looks better but not real. curious what techniques others keep seeing as marked as “Coeverd” but not ready in real world? submitted by /u/Ok_Attitude9264 [link] [comments]Technical Information Security Content & DiscussionRead More