Incident Response: Building Automation

Incident response is at the heart of any organization. Built from the service desk up, it’s a key skill that reflects on how effectively your team handles unplanned events. For normal day to day, the focus is often on restoring availability or supporting users with localized issues, however for Security it’s a little bit different. Within Security, each Incident or events needs to be handled correctly, regardless if false-positives, in large quantities, or “assumed legitimate”. Unfortunately each event can’t be ignored regardless of resource or time. The reason being is that, it only takes the attackers to be successful once and who knows what that one success will result in. This stress or responsibility can really drive a team to fatigue, or stress related illness as it’s a big burden to carry on your shoulders. This stress can also develop as being under stress, causes mistakes which only increases the stress levels further.

Incidents are unplanned, so despite having playbooks and runbooks, emotion can have a lot of involvement as the responders is only as good as what they were doing at the time of detection. If deep in logs or on the phone to a user, a serious incident means that we drop everything to respond, which sort of means ignoring what you were doing (Easier said than done). They may also be going from some personal issues, troubles during the activity, which again will change the outcome. We are only human after all.

This is were automation comes in. With all these complications and factors at play, you want the team to have as much information as possible at the time of reviewing the alert. You also want to remove the emotion aspect as much as possible and allow a ‘bot’ to handle certain activities. With the information clearly defined on alert, the responder should be able to review if this is an actual threat and what priority. Additional steps should also be presented and made available if they need greater insight. Automation should bring all of this to the table, and take this manual burden or findings away from the initial stage.

Step 1 is obviously to define runbooks or playbooks and highlight problems. The runbooks and playbooks should be both heavily defined however have a summary or bullet point page for the responders to actually follow. What I mean by that is that the meat and detail should be reviewed when available to help the team understand the process as a whole. This shouldn’t be read during an active incident as it’s too lengthy. Instead there should be a set of clear and simple “steps” or bullet points that can be read during an active incident to stay on the right path. This should derive from the detailed document as to keep consistency. If the short doc says one thing and the detailed says another, the short document will be the only followed document (Due to frequent use).

Defining and creating these isn’t a quick task, so “highlighting problems” may bring quick wins forward. This being: “too much manual process around X”, “not knowing for X incidents” or “not knowing where to look to access the risk of X”. This can even be as simple as raising a ticket on detection. Tools nowadays have integration points, so ticket creation may be an automation element that reduces time. It may sound simple, but doing something like this:

• Keeps consistency of tickets.
• Ensures one is created for audit or tracking purposes.
• Allows the responders to just get on with it.

It may also be to provide links, or guidance to them so that they don’t have to go looking. Detections and alerts are normally built into each security tool, however it’s the where and what that often differs. Once spend time reviewing, you can then look to tools to enrich or assist the alert further. Below is a simple example of how using Microsoft Power Automate can add adaptive cards to provide responders quicker methods for accessing risk:

This is a flow I built that reviews the detections and pulls apart the key information. It looks to see if it was blocked, the type of threat, the hash and the filename. With this, it creates an adaptive card to provide “responsive” tasks for the responder to use. The example here showing if they want to review the risk score of the sha256 hash. Under the guidance section, you can outline clear steps for the responder to follow. The more complex your flows become, the more dynamic the information can be. The more time you spend/invest here, the less time your team can be spending later.

Starting with the enrichment of alerts, may spark further questions such as can I actually do X prior to the alert. This is where reviewing your tools comes into play. Security tools nowadays, do have orchestration and automation aspects for the user, so it’s about reviewing and seeing how they fit into your playbooks. CrowdStrike for example has Fusion Workflows which allows admins to build playbooks within the portal.

If for example you want to enrich, notify and action based on a series of conditions, than spending time building these out will again save you time later on. It may also help increase posture, as no tool is perfect. It’s the problem when supplying a product to all. Often they have to find a balance of usability out of the box, over secure defaults. Microsoft is a perfect example of that. Your endpoint may not block LOLBins for example as they are used day-to-day. You may have an internal policy that does limit LOLBins so it’s best to enforce via a tool (rather than just words on paper).

The possibilities are not limited to the tools you have and it’s all about what you want from it. Having someone with curiosity always helps, and spending time on automation can pay off later down the line. Cost shouldn’t also be a factor as there is plenty of open source tools out there that can match the premium. Often the automation is already included in what you pay, it’s just not being fully utilized. Incidents won’t stop and the stress will continue to fluctuate however removing long manual tasks or providing context to stay in check may ease the burden if not make life that little bit easier.