Response and development are different

Software development involves making a careful plan, then implementing that plan with intense bouts of concentration.

A software developer that’s interrupted every ten minutes by an incident report is not effective. Your software developers need to understand the incident response process, without actually being subjected to the unpredictability of incident response itself.

Filtering

An incident response team is like a filter: taking data and reports in, processing and refining them, and then producing high-quality, verified information that goes out to other teams and constituents.

Although this process is integral to CSIRTs, managing data can feel like doing your taxes: necessary, but painful. To be an effective security team, you need to be effective with your data.

Repetition

While some incident reports are exciting and unique, the majority are not. The bulk of what CSIRTs handle is repetitive: malware infections, phishing sites, port scans.

One problem this leads to is burnout. You and your team want to investigate new threats, not handle the same incidents every day. There’s nothing that saps creativity among a sharp security team faster than repetition.

Using software, we can automate away as much tedium as possible. Your team is left to do what they’re good at - focus on the new and interesting.

Special environmental constraints

The most important asset you own as a CSIRT is your name and its reputation. You’re careful to protect that asset by protecting the sensitive information you handle.

Software interlaced with third party web service dependencies isn’t for everyone. You want to know you can strictly control, verify, and rely on your environment. You may need to trust it to the point where it’s not connected to any external networks at all.

This creates some unique software development challenges that require special understanding.

Built for the needs of CSIRTs

What CSIRTs do is quite specialised: not everyone understands the mindset that security folks have. To ask someone to build a system for you, you need to explain CSIRT operations 101. How do phishing sites work? What are the tell-tale signs that a site is fake? How do drive by downloads work? What protocols do botnet C&Cs often use?

Wouldn’t it be good if your software developers already had this baseline of understanding?

We understand the needs of IR teams, because we’ve had those same needs before. Monitoring systems need to consider non-attribution. Dangerous artifacts like malware should be stored safely. System access should be compartmentalised, using encryption or signing as appropriate.

Working with us lets you skip over the explanations about what it is you do, and get down to solving problems.