“You never want the cure to be worse than the disease”.
Join us as we discuss the practical constraints around building incident play books:
- Lee Harris, MSSP & Cloud Pak for Security Sales Leader, EMEA, IBM
- Dr Alex Tarter, Chief Cyber Consultant & CTO, Thales
- James Todd, CTO - BT Security, BT
- Andy Grzes, CTA, Smarttech
Gentlemen, for the first question, for any given incident, how do you weigh up risk versus operational efficiency? That's Alex or James. Alex, would you like to go first?
For us, the balance is less. A balancing risk versus operational efficiency, for us, is really a question of timing. One of the hardest decisions you can make in any incident response is should you take an action, and does that action actually cause a worse impact than the disease? So you never want the cure to be worse than the disease, and that's especially true within critical environments where any sort of response which involves a loss of production or a loss of automation means a significant loss in revenue.
So for us, we really try and work with our customers to, before anything happens, to go through a reverse engineer from what are the unacceptable outcomes to how they could occur, what are the early warning signs, turning those into playbooks. But then, most importantly, not necessarily turning into a playbook, which just says, cool, when this happens, by default execute the response, but more in terms of when should you execute that response? So as much as possible, we're really trying to detect as early as possible through threat hunting, et cetera.
And then we're trying to buy the decision maker as much time as possible through techniques like deception, engaging with the attacker, trying to slow them down in order to buy the decision maker the time to know when is the best time to execute that response so much so that the response does not impact business operations?
Thank you. And, James, how about yourself?
Yeah. I think just building onto that, I think as an MSSP, we want to move more to being dynamic in protecting our customer environments, and doing that as near real time as possible. But to the point made previously is that we need to be cognizant of our ability to do that in a timely way versus our customers' acceptance of automation and the risk of being able to deploy that. And no two customer requirements are the same, so although the mitigating action we can describe at a very high level that we want to implement holistically, the way that we implement that or make recommendation for implementation is going-- needs to be cognizant of the customer's threshold or tolerance for automation and also the impact of the risk of deploying that control that is adverse to a number of services that they're currently running.
So doing something at scale as a CSP as well as an MSSP is something that we're keen on doing. So holistically being able to apply something within our telecommunications infrastructure that at least mitigates the effect of an attack whilst we inform our customers of more focused or surgical remedial action is something that we're taking into account as part of our managed security services as well as our global service provision.
Right. Thank you very much.