"In IT and Operations, they learned how to do this decades ago. It's about time in security we learned to do this too."
Sebastian Avarvarei, Director for Security Advisory Services Europe at Wolters Kluwer discusses the value to the business of reducing risk, with Chad McDonald, CISO, Digital.ai and Dr Paul Lewis, Senior Director of Cloud Security, Elsevier. Hosted by Hosted by Thom Langford, Founder, TL(2) Security.
View the full Webinar here.
In the presentation was only 30% of companies measure the value from their software. And case question was how do you demonstrate the cost stroke opportunity of reducing these risks? So I think it is very clearly tied together. You know, how do you start to show a Euro, Pound, Dollar value of what value to the business when, what, only a 1/3 of us can actually seem to have any kind of success at it?
So it's largely subjective, quite frankly. I've looked at some ways to do this in a more quantitative way and they all lead back to applying foundation of subjective guessing, if you will. Or informed guessing.
Finger in the air.
Exactly. Typically, where I'll start to understanding where my assets are, and part of a building a security programme is doing a business impact analysis for you disaster recovery, business continuity, and so forth. What you'll get out of that is some very clear revenue streams. How much things that are quantifiable. How much a business line brings in, or a particular product brings in.
There's also things like reputational damage from outages, from a hack, things that you may have to get from, say, the marketing department or a few different groups. In other words, if we were hacked today, and/or the business were unavailable for a week, a month, a year, hopefully not a month or a year, but if a product were unavailable for a week, how would that impact your market? How would that impact downstream sales pipeline?
And you'll be able to get a number back, but it's again, it's largely subjective. But then you can start to put some borders around what the value of a particular asset is. Whether that's a set of personal information or whether that's some particular piece of IP that you develop. You can put borders around that. And again, you never want to spend more than a value of what the asset is worth, typically, to protect it. So it sort of sets an upper limit on what you should spend.
I think the way you approach it is divided into buckets, learning from other people's mistake and learning from your mistakes. On the phone, the first case is, there are actually not frameworks out there that help you, which still is a bit of a guesstimate, but you have some guiding rails on how to estimate the impact and then try to apply it. And you actually speak with your own business people, with your finance guys, or if this would happen to us, how much would it cost us? These are the kind of conversations that you do need to have.
But also learn how to learn from your mistakes. Everybody has big and small incidents from time to time. When you have an incident as a CISO or as a security guy, don't stop at, OK, we fixed it. We're done. Moving on.
No, we fixed it. We solved the problem. Let's do the post mortem. Let's make a very detailed analysis of how much did this cost us. Go to the finance guys, talk with them. Count the number of hours that people have spent on that incident. Talk with the communication and marketing people, how much did this cost us in terms of market impact? Then put all that information together in preservation and do management presentations until they're sick and tired of you. Do that have so they know how much it actually the cost you as an organisation for that incident.
And let's be honest, incident is not something that we don't have. Even if they're not the big ones, in any incident, follow it up and use it. We all know, some of the best security programmes in the industry have started after a security incident. Let's use that to our advantage and make it clear, we are not looking for somebody to blame.
We are just looking to quantify and then to learn from those mistakes and to see what can we do better next time. This is the kind of conversation that we need to have, And. It's not even something new. In IT and Operations, they learned to do this decades ago. It's about time we learn to do it in security too.