I blogged about why Ops needs to be involved in cybersecurity decisions, and I blogged about how to remove the perceived barriers to doing so. But, what are the actual outcomes, or deliverables, that Ops’ participation should be driving? How should we be participating in risk mitigation through cybersecurity? Leaving aside the decisions around the technology solutions your organization will implement (for now), I put forward that Ops is an integral and distinct part of your Incident Response plan – before, during, and after a breach.
My peers have written about the steps to take after a hack with IT in mind – now it’s my turn. To include in your Incident Response plan, here are five specific activities that Operations teams are well-suited to owning and delivering in collaboration with technical stakeholders.
Assembly & Enablement of the IR Team (Logistics)
I have mentioned previously how IT people and Ops people think differently; specifically, that IT folks are often very thorough but not always very organized. As such, I posit that it’s an Ops person you want to actively assemble and organize your response team during an attack. What actually happens will depend on the time and place the attack occurs, determining whether your IR team is already in the office, or available. Unfortunately, you can’t control when at attack happens, and I’m told that hackers know to strike at choice moments when your in-house responders are unlikely to be available or even aware of the alerts, making their assembly at the right moment essential.
One of the things Ops can help with before a breach is working with IT to ensure responders are able to work remotely. Ops should also help determine which stakeholders are on the list, backups in their absence, and documenting and maintaining the best ways to get in touch with them. Keeping this information up to date is integral; imagine being unable to contact responders during a breach, or worse, having names on the list who are no longer with the company. Ops is also well-suited to creating and managing the checklists to validate whether your plan is being maintained, and take corrective action if it is not.
Coordinating and Communicating
While some details specific to the attack will need to be customized, it’s easy for operations to ensure that various attack scenarios (provided by your security team, or IT team if you don’t have one) are planned for, and that templated communications are prepared before the breach. This makes notifying end-users and senior stakeholders easier during the breach. This may not sound like the top priority (and it won’t be for the technical stakeholders who are busy responding), but each step in your IR plan needs to happen as quickly as possible – seconds matter. Failing to communicate that end-users shouldn’t click on a zero-day-malware-laden email could result in broader spread and greater damage.
Let’s face it – the last thing your IT team will be thinking about during this is who to report it to, or the legal implications for your company. They just want systems and data back to a normal state, so that business can resume. Your coordination of capturing details and getting them to the right people, ensuring that legal is involved to assess privacy implications, or liaise with law enforcement, are integral to ensuring IT can focus on fixing the problem, quickly.
Conducting a Fire Drill
Having a plan is great, but if your people are getting through it for the first time when you’ve been breached, you risk your team learning as they go, potentially making mistakes. Ops can mitigate the risk of a sub-optimal response by coordinating drills before you get hacked. Don’t leave this as one-and-done – just as you would for a non-cybersecurity incident (a literal fire drill for example), drills should be conducted regularly, and be either notified or a surprise. They should evolve with input from the team, and by addressing the lessons learned from previous drills and breaches.
There are providers who can assist you with this; our Virtual CISO service has enabled drills for many of our MDR clients. Other options are usually offered as ‘penetration testing’ (which we also provide).
Accounting for Extended Working Hours
When I talk about damage control during a breach (especially one that my peers would call an “Advanced Persistent Threat”) your incident response team may be in the office dealing with the situation into the wee hours of the morning. Operations ability to plan for practical considerations of feeding, transporting, and accommodating the team through this scenario is well-placed during this stressful period. Seriously – having pizza gift cards and taxi chits on-hand can make a surprising difference. By ensuring it is in the plan before a breach, and that the plan is adhered to during the breach, you’re removing one more barrier from your technical people solving the problem.
It’s easy to forget that with all the cybersecurity technology at play, it’s ultimately people who will be responding to this incident. Our own service includes a combination of people, platform, and process.
Post-Breach Organizational Change
Experiencing a breach can motivate senior leadership to implement changes, and ascribe resources to achieve them. Working closely with your IT, security, and organizational development teams to collect feedback and initiate projects is where Ops can really shine. New policies, procedures, training, technology and projects can all result from a breach – each can be improved by learning from the incident. Include a debrief in your IR plan, with mandatory attendance of specific stakeholders. Collaboration is required to get the most of it, as it’s only with widely sourced input that Ops can evoke such change successfully. As with any project, regular meetings to evaluate progress and ensure your Champion/Sponsor are still participating will be beneficial. This will help maintain focus once the “excitement” of the incident has passed.
You may be saying that some of this is just common sense. You may believe that it doesn’t require documentation and planning. But the fact is that a breach is one of the most stressful scenarios a business can undergo, given the existential threat it poses. Any loose ends you can secure before you’re within that storm helps mitigate the risk of things not getting done, not getting done quickly enough, or not getting communicated when they are done.
Your organization may have dictated that IT is responsible for this, and therefore Ops’ involvement is precluded. Just because IT is doing it now, doesn’t mean they’ll be able to maintain these efforts during a breach. Give them the time they need to put out the fire! Sure, these steps might happen organically; but what if they don’t? And, what if their absence impacts how quickly the responders were able to act? What if that means the hackers were able to access a privileged user, who has access to the most sensitive data (my peers would call this the “crown jewels”). These risks shouldn’t be left to chance, or to the governance of a team who doesn’t normally think in this way.
By getting involved early, you ensure that the role of Operations is proactive, and likely to assist in dealing with issues when they arise – before it is about damage control. Yes, it will take time to prepare for this, and may only save a few minutes during the actual incident… but a few minutes could be the difference between a contained breach, and a catastrophic one.