Mistakes happen; that’s just a part of life. This chapter will provide an overview of common mistakes I have made in mappings and detections, as well as areas where I’ve seen others make mistakes. That way, you can learn from our shortcomings and implement mappings the right way.
The chapter will cover the following topics:
Mistakes happen, and we all know this. It could be an implementation that doesn’t work, a lack of knowledge or direction, or a simple mistake that happened purely by accident. The problem is mistakes can have consequences of different sizes, and you don’t typically know what the consequences are until they’ve already occurred. Hopefully, you can learn from some of the mistakes made in our past and use this to make your organization more secure.
For the first example, I think of times when I have tried to overextend resources to cover as many controls as possible, even when it wasn’t likely to be successful. It was a common practice for a while to review any areas and try to implement detection, mitigation, and security controls without thinking of the consequences for the organization, and in the long run, that was an important lesson to learn. It might have started small with over-portioning user...
Creating alerts is part of any security operations center (SOC) team’s responsibilities. That allows them to use Yara, Splunk Processing Language (SPL), Suricata, and so on, whatever language makes sense for the tools that your organization uses. I can also guarantee that anyone who has ever worked in a SOC can relate to having alerts that were created that just generate a large number of false positives and can quickly become tiresome to triage, or that, due to ineffective filtering on alerts, become quite complicated due to having more information than is needed. A few alerts come to mind, but the first one is an alert for periodic beaconing, which can be indicative of an infected system sending a ping out to a C2 server. This alert would/could map to the following techniques in MITRE:
Mistakes regarding implementation and detection are bound to happen; not only have they already occurred but they will continue. The key is to learn from those mistakes, and you can then use that to be more prepared for the next implementation or learn to be more efficient when creating detections. You also shouldn’t be ashamed to talk about failed projects because you can use that to get feedback and helpful suggestions from other industry professionals. Many times in my career, I’ll talk through a particularly tough task and use my network to help talk through ideas.
In the next chapter, we’ll discuss the alerts that, in my experience, have provided the most value. We’ll also talk through ways to measure the efficacy of alerts and set up feedback loops to identify what alerts need to be improved.
© 2023 Packt Publishing Limited All Rights Reserved
