For today's #CyberSecurityAwarenessMonth post, I want to talk about the difficulties that need to be addressed with public threat data.

As an MDR company, we at @Deepwatch know that simply ingesting unfiltered public threat feed data into a SIEM as searches is a great way to run up your false positive rate by orders of magnitude. We also know that malicious actors have the same access to those threat feeds that you do, and they look to see if their tactics are being reported on so they can pivot (when possible)

Because of these drawbacks, here are some suggestions to maximize your value from threat feed data:

• Curate the data before you use it for searching. Picking out higher quality feed data, and validating it has relevance in your environment will help you minimize the busy work of false positives.
• To aid in curating that data consider industry specific feeds and commercially available feeds. These may not solve your curation problems, but they can help reduce it.
• Recognize that by the time you get that publicly available data it may be stale. Search weeks back as you can reasonably in your security data/logs for matches on these IOCs, not just the past 24 hours or just "going forward."

Even with these drawbacks, external data about threats is critical to supporting a #CyberResilient organization.

For #CyberSecurityAwarenessMonth, I'd like to bring up a trend that concerns me. I'll call it the #ShinyObject trend. Security programs need to be built on fundamentals, built on a solid base that is flexible and thoroughly prepared to address threats. A #CyberResilient security program is focused on reducing risk. But the Shiny Object based program is focused on "the threat of the day" (not even the threat of the week or month anymore, they come too fast).

Even worse, when we see organizational leaders expect a new answer from their security team every time a new headline on "CEO Doomsday Weekly" website and then asks "are we protected from <insert shiny object>?" we show that:

1. Leadership doesn't have faith that our program is resilient
2. We haven't helped them understand our program's resilience

I think this problem exists for us in our personal lives as well: we focus on "oh no, I better patch today because of <insert shiny object>" vs. "I'm doing my routine patching that is part of how I keep my systems safe." (assuming we patch at all)

Don't fall into this trap.