Incident Response is primarily a procedural sport — and there are opportunities for both generalists and specialists in specific technologies to participate.

But programming itself (beyond scripting like PowerShell and Python for data gathering and analysis) isn’t often needed. https://twitter.com/joeynoname/status/1341191518200147968

With that said, the more tools at your disposal, the more versatile of an IR *consultant* you can be — more effective in more environments — but most ppl doing IR aren’t consultants, their env is a little more static, and they should focus on learning their surrounds, not coding.

This thread assumes the title isn’t “IR Engineer”. Very few companies have this role, I’d expect mostly only the upper crust separate IR engineering from SOC engineering.

More important than coding skills in #DFIR:

> using the right toolsets
> pre-planning
> after-action/lessons learned integrations
> overall incident management
> data gathering & analysis
> chain of custody
> validating assumptions & being aware of analyst bias
> reporting

Threat hunting as an activity cycle allows you to model the IR process entirely within the SOC.

1. Gather & analyze data
2. Characterize network or system activity of interest — what is this process? Is it legitimate within our business?
3. Develop detections & adjust alerting

Being able to develop a rapid understanding of what may be a very poorly documented system or network is important.

Also critical: having an understanding of common system internals / network architectures and determining what forensically relevant data may exist in each system.

If there is ONE technology type you need to have a decent level of competence with when doing Incident Response, it is the most common data and file formats (e.g. xlsx, csv, json, sql, db, eml/msg, exe, jar, msi, cab, pdf, docx...)

Safe handling and basic analysis.

I don't know if I worded that well, but as I said earlier in the thread, you need to know how to look at what's interesting.

#DFIR