MITRE Coverage and Detection - 1 of 3

MITRE Coverage and Detection - 1 of 3

Like many security professionals, I am a fan of the MITRE ATT&CK framework. My affection is a bit unique though as I look at it through the eyes of a content developer/blue team defender. Before the MITRE framework was released, there wasn't an industry standard framework to reference. I called upon my super-powers as a SME with years of experience and conversations with business leaders to understand what was important to them- and then I wrote content that ensured I was protecting the most valuable business assets from the most probable security threats- and I believe that was a laudable approach.... but defending it against auditors was always a roll of the dice. How many detection rules are enough? How to you know when you have a gap? How do you show improvement over time? The MITRE framework helps address these issues. For example, if I have very little content around the lateral movement techniques, I can clearly know that. I can now make assignments to develop detection content around the missing techniques... and show the improved coverage over time.

With that stage set, I'm going to go back ever so slightly and call out some of the obvious things so we are all on the same page. To say a given technique is "covered" can never really be true for a certain number of techniques. As just one example, consider T1048 - Exfiltration Over Alternative Protocol. I'm not going to pretend that I could possibly write a detection rule or even multiple rules that would detect every possible way an attacker might exfiltrate data over an alternative protocol- there are simply too many ways to abuse this. What I CAN do though, is implement detection rules that offer detection for attackers in this space. For example, suppose I baseline the expected protocols used by the systems in my network and then alert on anomalies from similar systems or new protocols. It is trivial for certain detection engines to say system SQL.ACME.COM is attempting an outbound SSH connection and it has never done that before. So if we can agree we may never cover a given technique at 100%, I can make the statement that it IS fair to say that I have ZERO detections for a given tactic, my content is highly deficient... And we are no better if we don't have metrics around our content to know what our level of coverage is.

So let me interrupt this flow right now with one VERY SIMPLE question: What percentage of the MITRE attack framework techniques do you have detection rules for? Drop a note in the comments below if it isn't self-evident how to measure this. Anyway, if you can't answer this one question, you have work to do! In another article, i'll share HOW to actually implement this coverage yourself, but for today i'm simply convincing you should be able to answer this question and strive for significant coverage of the entire framework.

For a reference point to measure yourself when you know the answer, while LogicHub is not a SIEM and is not intended to replace a SIEM, it does have a library of more than 700 detection rules offering detection capabilities for than 80% of the MITRE attack techniques. This 80% number might be higher, but there are a number of techniques that aren't practical to monitor at scale- and even MITRE acknowledges that (as one example, consider T1109 (Component Firmware) where MITRE says "... this technique may be difficult to detect since malicious activity is taking place on system components possibly outside the purview of OS security and integrity mechanisms." When you start to implement this coverage, you are going to discover that 80% coverage is exceptionally great coverage!

I'll be entirely transparent... the reality is you can absolutely have your SIEM content developers sit down and write the same detection rules we have implemented in our own product- in fact, follow me on LinkedIn because I plan to make my next article a step-by-step overview of how to do this yourself if you are so inclined. What you'll find though is that by the time you have them do this, it is going to take THOUSANDS of man-hours to develop this yourself. For insanely simple math, say your developers can implement 1 rule every 3 hours- in order to achieve equal coverage of the 700 rules we already have, that would be 2,100 hours- at 40 hrs/week, that's 52 weeks.... a YEAR of development time doing nothing but straight dedicated content development for detections- and in addition to the time, the costs of an in-house developer- or even worse outsourcing to a contract company- will be in the hundreds of thousands of dollars!

By comparison, LogicHub invested in the development staff to create this detection content inside our platform. It started as a library of content for our own MDR service, but the company realized it could be used for multiple customers- even those that want detection content only. For example, suppose that I as the LogicHub content developer write a detection rule to baseline the network protocols observed by a Palo Alto Firewall and the systems that are communicating- and subsequently trigger detection indicator if a new protocol is observed. I write that rule one time, but I can deploy it across multiple customers. In other words, there is an economy of scale that allows LogicHub to produce and offer their content library at a small fraction of the cost it costs you to develop the same detection coverage internally by your own staff.

That's not to say you don't need your own content developers! I repeat my earlier statement, LogicHub is not a SIEM and is not intended to replace SIEM solutions. What LogicHub does do is offer an amazing automation and detection engine with a library of pre-built detection rules covering a HUGE percentage of the MITRE ATT&CK framework leaving YOUR developers free to focus on those detections that are unique to your business.

So here's my call to action-

STEP 1) contact your SIEM developers, your MSSP, your MDR service... whoever manages your detection and just ask them what percentage of the MITRE techniques do they have detections for.

STEP 2) *IF* you can even get that answer at all, ask what it would take to get to 80% coverage (in terms of time and financial cost).

STEP 3) Visit LogicHub.com to get a zero obligation comparison to see what our service offers. I assure you on my reputation as a 15 year security SME, you will be shocked!

For those that don't want to do these 3 steps but still want to tackle MITRE coverage in-house, stay tuned because i plan for my next article to give you an implementation guide for those DIY'ers.


要查看或添加评论,请登录

Anthony Morris的更多文章

社区洞察

其他会员也浏览了