Morning Read: Three Automation Mistakes You Should Avoid
Welcome to the Morning Read, a daily post where I recommend and discuss a white paper, blog post, chapter of a book, or some sort of text I find useful for DFIR analysts.
Today’s morning read is not something I’d normally suggest reading, but it has a lot of valuable lessons for DFIR analysts. Oddly enough, this article is also a bit of a juxtaposition. Today’s read is a sponsored post by Brocade over at NetworkWorld. Here’s the link:
There has never been a more pressing need to automate data center operations-including the network, storage, compute…www.networkworld.com
This article, while sponsored by Brocade encourages data centers to be wary of automation, and some things to consider before buying products and vendors. This article covers three distinct “lessons” which I’ll examine and provide analyst feedback on in the next section.
- Avoid trying to boil the ocean. I think this is a relevant lesson for DFIR analysts who are trying to do too much. While the article takes the approach of caution in automation, analysts should also avoid trying to “do too much, too soon, [which] is often a recipe for disaster”. Sometimes, DFIR analysis takes time. As nice as it would be to look at an entire enterprise in one motion, we have to understand what each node looks like first. Take it slow.
- Avoid becoming tool-dependent. If this concept is not applicable to DFIR analysts, then nothing is. To quote the article:
“Tools alone are never the answer. Instead, the best tools support a well-established strategy. Why does this happen? Oftentimes, a member of the team or a sub-team within the organization has had success with a tool and leverages past successes to justify using the tool for tasks outside its intended scope. In this instance, the deficiencies of the tool will ultimately dictate the strategy and tactics — unfortunately resulting in diminished outcomes.”
Too many times, I have worked with or encountered DFIR teams who are extremely tool dependent, to the point that they are losing “winnable” cases and missing artifacts. To someone investigating a three-year-old APT attack, this may sound kind of “meh”. But to someone looking to prove or disprove a crime, evidence cannot be missed. Casey Anthony?
- Avoid wearing vendor blinders. I think Brocade offers this point to remain fair and say that one vendor should not control your entire ecosystem, but I doubt they’d shy away from that kind of contract. However, the text is important. Similar to avoiding tool-dependence, DFIR analysts should also be evaluating multiple vendors consistently, and changing up if one is not working. The number of times I’ve heard “XYZ vendor is terrible, I can’t believe we’re using them”, and I find out ten minutes later I’m talking to the person in charge of purchasing!
It’s unrealistic to expect every shop to roll their own tools and live in a world of stress-free, minimal-support open source. Vendors are necessary. But make sure you are testing and evaluating vendors that fit within your strategy and company.
Thanks Brocade for a valuable article. I highly doubt that these were your intentions, however you’ve offered some good lessons that transcend simple data center management.