Join Paul Ducklin and SolCyber CTO David Emerson as they talk about outsourcing, SOC response, and cybersecurity dialog (the human sort!) in TALES FROM THE SOC.
If the media player above doesn’t work in your browser,
try clicking here to listen in a new browser tab.
Find TALES FROM THE SOC on Apple Podcasts, Audible, Spotify, Podbean, or via our RSS feed if you use your own audio app.
Or download this episode as an MP3 file and listen offline in any audio or video player.
[FX: PHONE DIALS]
[FX: PHONE RINGS, PICKS UP]
ETHEREAL VOICE. Hello, caller.
Get ready for TALES FROM THE SOC.
[FX: DRAMATIC CHORD]
DUCK. Welcome back, everybody, to TALES FROM THE SOC.
I am Paul Ducklin, joined by David Emerson, CTO and Head of Operations at SolCyber.
Hello, David.
DAVID. Hey there.
DUCK. David, the topic for this episode is very broad and surprisingly deep, but something that people often ignore when they’re thinking about outsourcing security.
And that is: SOC Response.
How much of the decision-making about how you should respond in the event of an incident should you outsource?
DAVID. Well, we’ve talked a lot in the past about whether or not you can outsource cybersecurity effectively, whether or not you should outsource, or what functions of a business you should outsource.
And I think it is without a question that one can outsource cybersecurity effectively, just as one can outsource contract review, or accounting, or any number of services that exist to support businesses – things that are not core competencies of that business.
But it is more nuanced than simply “outsourcing or not outsourcing” cybersecurity, in the sense that when one decides to outsource cybersecurity, there is still a decision tree of, “What do we do when something is found?”
What functions are actually core competencies that must be secured in ways that a third party provider could never possibly provide?
And that’s really, I think, the topic today.
What are those nuances you have to think about once you’ve made a decision to outsource your cybersecurity?
DUCK. If you’re a business like a bakery, or you have a fleet of trucks that do deliveries for your customers, clearly cybersecurity is something that is a bit of a distraction if you have to worry about all the details all the time.
But there are inevitably going to be some things, if either there is an attack the nature of which is uncertain, or if there is a response that could actually stop your business operating just as severely as ransomware could if you just pull the plug on everything right away…
…where you still want to be involved, essentially, in that decision-making process.
You’re looking to outsource the technical expertise.
You’re looking to have advice from real experts on tap at a moment’s notice.
But you don’t necessarily, to use the legal analogy, want someone who will just blindly sign all your contracts for you without consulting you first.
DAVID. And if you take the baker as an example, there is this slug of activities that every business has in common.
I think of it as the “shackles of the quotidian.”
DUCK. I’m smiling because I know you’re a fan of James Joyce, and it sounds rather Joycean.
But I don’t think it is, is it?
DAVID. No. [LAUGHS]
DUCK. It’s an Emersonism! [LAUGHTER]
DAVID. Yes, it’s an Emersonism.
Those are the things that every business must do.
And the baker does them too, if the baker’s properly securing their organization.
And that’s running an anti-malware suite; that’s analyzing events that are occurring in the various common systems of the organization like Active Directory, or Exchange, or O365.
And third-party services are very good at those, because they are common to every business.
They’re things that profiles of normal and anomalous behavior can be built about.
But do I know anything about, let’s say, internet-enabled mixing machines in a bakery?
I don’t!
I might be able to take their logs, but even then, how do I know who is supposed to be using the mixing machine and who isn’t?
When the mixing machine is supposed to be receiving an update?
I don’t know those things.
To build custom rules around them – though in some cases it is possible – is often not the answer.
A lot of times, if you have that kind of exposure, even as a baker, you need to realize, “OK, well, I’ve decided to go with internet connected mixing machines, and my third-party cybersecurity vendor, is it going to be able to help me respond to an incident on the mixing machines?”
It’s not going to be possible.
They might be able to take the telemetry, but even then, they wouldn’t know what to do with it.
That’s really going to be beyond the scope of the third party.
So it’s important to differentiate between those activities.
DUCK. Now, you could bring those activities in scope, couldn’t you?
DAVID. You could.
It is possible to drag those things into scope, but they’re going to be unwilling participants in that dragging.
And I think you’d probably end up spending more money compelling a third party to learn enough to do those things for you than you would to admit that you’ve freed some of your engineers, or some of your other operators, from the shackles of the quotidian by hiring this third party.
And they now have an increment of time which can be better spent on esoteric or bespoke activities, right?
DUCK. Yes.
DAVID. They can now focus on what that mixer is doing, and when it should be updated, because they’re actually an engineer now, not a SOC analyst abused into being an engineer or an engineer abused into being a SOC analyst.
DUCK. So they are an operational analyst, if you like.
DAVID. Right.
DUCK. They’re not focused entirely on security operations, knowing that the details of gathering and processing the security information is being done by somebody else, but that there are always going to be some findings for which their interpretation and their response will be important.
DAVID. Yes, and there are many ways to solve this problem.
They aren’t always finding someone to do a thing.
Sometimes they are architectural.
Maybe you could admit to yourself that there’s no third party that will successfully analyze the data coming out of your internet-enabled mixers at your bakery.
And maybe you come to the conclusion that instead of hiring an engineer, or instead of making that someone’s job who’s already got a day job, you just don’t need internet-enabled mixers.
It’s possible.
We have customers that have significant shop floor footprints in manufacturing industries.
And they simply decide to disable some of the functionalities that would represent vulnerability.
And sometimes they do so at our advice.
DUCK. So you’re providing the operational security analysis that exposes the potential risks, helping them make the decision.
And that decision might be, “Let’s not use that feature.”
DAVID. Yes, exactly.
DUCK. Because you don’t need everything turned on, do you?
DAVID. No, you definitely don’t.
To use an example that we have from one of our customers, there’s a device that tests a product that they make.
And that device runs Windows XP.
DUCK. Oooooooh!
DAVID. And it’s made in Switzerland.
And there’s nothing anyone can do about that.
That device simply was made in 1998 or whatever, and it still works.
There’s nothing wrong with it.
It tests the devices that they manufacture just fine.
But that device should not be on a network, full stop.
When we investigated with the customer whether or not they should be swapping that device out for something more modern, they found that nothing more modern exists which would not ruin them in terms of cost.
That’s fine – sometimes you end up in that situation.
Instead of worrying about trying to secure that device, they’ve simply removed it from the network.
And it hasn’t really hurt the performance of the device, which itself is a standalone utility on the shop floor.
You have to make our architectural decisions like that sometimes.
What would have been really foolhardy would be to say, “OK, I want to find a third party that can support this thing from 1998.”
“And we are, come hell or high water, going to be connecting it to the network and sending its logs to some kind of third party that we’re going to train.”
Maybe you could have done that.
But I’ll bet it would cost as much as, if not more than, simply upgrading it or disconnecting it from the network and deciding that you don’t need to have that element, which is so vulnerable, in your architecture.
DUCK. And this applies, doesn’t it, not only to companies that aren’t really IT businesses in their own right?
You could be, for example, a software engineering company where your goal is to produce an update and ship software.
And as you say, you want somebody to get rid of those “shackles of the quotidian” so that your engineers can focus on building an effective production environment, providing competitive stuff in the code.
Allowing someone else to decide how your production environment works in an environment like that could be a bit of an exercise in futility, couldn’t it?
Particularly if part of your business model is to be reactive and responsive.
DAVID. Yes.
A lot of production stacks, if we go with the software development example…
A lot of production stacks contain things which are unique to the business and would not be easily understood by a third party, and which may even be a core competency.
So for example, if you run an e-commerce business, you might have a system that tracks ad revenue by source; the performance of Google ads versus Facebook ad versus Reddit versus whatever.
That might be custom-written by you in a way that is effective for your platform.
You probably can’t send those logs to a third party and expect them to make heads or tails of it.
Maybe you can send the nginx web logs.
But then you get into all kinds of questions like insider threats.
Is there any possibility that a third party could divine that Sally is not supposed to have the same access as Jill?
No, we really can’t, in a custom solution like that.
Or at least it would not be easy to do so.
If you did that, you would probably be spending more money on the third party, and on the effort to train them up, than simply saying, “OK, we have freed our engineers from worrying about CrowdStrike, and SentinelOne, and CloudFlare WAF.”
“All of these things are common, and they are sent to the MSSP for analysis, which is a third party.”
“And so our engineers can now turn their attention to things that drive revenue at our business, which is specific to the business.”
I don’t really think it’s a difficult problem to characterize.
I think the reality is it’s a difficult problem to actually effectively compute internally.
You have to manage your organization and know what it is you do that is unique to your business.
DUCK. David, I guess the flip side of that are people who think, “We’re going to outsource the cybersecurity part of IT.”
“We know there are all sorts of logs that we do collect.”
“We know there are all sorts of logs we could collect, but we haven’t been sure about.”
“What we’re going to do is, now we’ve paid someone else to do it, we’re just going to turn everything on, flood their data lake, and presumably they will filter out the important stuff from there.”
You might be just doing something that you simply don’t need to, and giving away data that really your customers wouldn’t expect you to share with anyone, even a security provider.
DAVID. It’s possible.
I suppose that hypothetical problem exists.
I can’t admit to having seen that in the wild.
I’m not dismissing the possibility that you should be thinking about what logs you send.
I’m just saying that, realistically, our problem is typically wishful thinking and not sending *any* logs, or sending some logs and thinking you sent all the logs when you didn’t.
In many cases, to be totally honest, our customers send a completely appropriate number of logs, and that appropriate number isn’t all that great because they don’t want to be billed for us ingesting and doing nothing with their business intelligence pipeline.
Probably the vast majority of customers realize that they should not be sending us non-security data.
And part of that is because we’re active in telling our customers, “Don’t send us non-security data.”
Now, we do have some products on the horizon, which are data pipeline management, and those products essentially allow us to ingest anything at reasonable, competitive costs so that you’re not paying security analytics prices for your BI data that you’re ingesting.
And then we shuttle the data that is in scope for analytics over to our analytics tools at greater cost.
So everything gets ingested at X per unit – per gigabyte per day, or something like that.
And then some tiny subset of that gets shunted over to cybersecurity analytics and gets analyzed at X plus some extra cost.
That’s something that will be valuable for folks who do have the problem you’re describing, which is trying to collect everything, because it allows you to manage your pipeline, to some extent, for cost and potentially for exposure to storage risk.
But realistically, it’s often not an actual issue because customers either aren’t sending the data they ought to be sending, aren’t understanding what they ought to be sending, or simply are doing their job and sending the appropriate amount because it would cost them too much to do otherwise.
DUCK. So it’s almost sounds as though part of SOC response by a third party company like SolCyber should be the preparatory work, and the continual review of what you are getting.
To make sure that it is sufficient and useful, but, by the same token, that you’re not collecting things that don’t really help from a security point of view, and just provide, if not a data leakage risk, some kind of background noise that gets in the way.
Because it seems a lot of people do collect non-sensitive data in huge amounts, and then never get round to looking at it.
And if you’re going to do that, there’s no point in collecting it in the first place, is there?
It’s like having a backup that you don’t know how to restore.
Don’t bother making it!
You’ll save yourself a fortune in disk, or tape, or SSD costs.
DAVID. I’ve seen that kind of cargo-cult behavior before.
DUCK. [LAUGHS]
DAVID. The reason you have a third party that you trust is because it does become a dialog.
If someone starts spamming us with firewall logs in debug mode, it isn’t going to be long before either they get a monthly report, or someone in the SOC notices the volume, and they basically get a phone call from us that says, “Hey, it’s not reasonable to be sending this many logs – we’re doing nothing with them.”
We really are active in trying to curate that.
Now, if you’re not an active partner, as a customer, in curating those at our advice, or in curating those when we say, “Hey, we believe the volume is too high.”
“We don’t even know what these things are, so we don’t have advice for you, but take a look at it.”
You’re either going to receive a big bill or you’re going to have a low effectiveness.
And that’s just the nature of third party response.
DUCK. So part of a deal with SolCyber is a regular review process to make sure that you are collecting necessary and sufficient amounts of data, and that you have a well-agreed way in which you will deal with it.
DAVID. Absolutely.
That is a cornerstone of our service.
DUCK. So, presumably, part of that could include a customer saying, “Look, if there’s an attack of this sort, say a ransomware attack, then we will essentially pre-authorize you to jump in and act very strictly, possibly even doing some kind of precautionary disconnect.”
“But for the most part, what we would expect you to do is to help us make the right decisions, if necessary in an emergency, for the bespoke parts of our business.”
DAVID. Yes.
Even in the context of a very tactical response like that, where you’re almost the boots on the ground…
If you were a customer of ours and your laptop were infected with some kind of ransomware – that’s a very ordinary device, infected with a very ordinary payload.
We would not really hesitate to shut your laptop down, to disconnect it from the network, to prevent the propagation of that particular malicious code.
It’s a lot grayer when that machine is, let’s say, an Exchange server, or when that machine is something that is a web server of provenance unknown.
DUCK. [LAUGHING] I think the word you’re looking for, David, is…
DAVID. Yes, right! [LAUGHTER]
DUCK. No, sorry, only kidding. [LAUGHS]
DAVID. But you don’t feel good as a third party operator, you cannot feel good, pressing the “network remove” button on something that contains that kind of operational impact implicit in its function, or sometimes on ambiguous payloads.
We’ve had payloads that look like Excel macros gone wild, and sometimes it’s highly ambiguous.
Is this just a spreadsheet that the CFO’s been tossing around for 15 years, and she wrote a macro that sounded great at the time, but now is seen as a virus?
So that’s the kind of gray area you sometimes see in terms of the tactical response, but the important one there is production.
It is very easy to respond to commodity enterprise devices being infected with commodity malice.
It is very difficult to respond to nation state level subtle attacks, or in infrastructures that just are production critical and no third party is going to be responsible for shutting down your email.
DUCK. It’s one thing to pull the plug on an individual’s laptop, and maybe they have to spend an hour not working, and they can go and have a coffee instead.
DAVID. Right.
DUCK. It’s very different to say, “I’m going to pull the plug on this cloud-based rack of VMWare servers that are actually serving the web content, the e-commerce payment processing, and the order fulfillment for the entire business.”
DAVID. Yes, huge difference!
DUCK. It might be appropriate to do that, but you don’t want to seem so proactive that you basically are your own worst DDoS, if you like. [LAUGHS]
DAVID. Nonetheless, assuming that we were wrong in both of those cases: we cut a laptop off and actually it wasn’t a malicious payload, or we cut an entire e-commerce platform off and it wasn’t a malicious payload.
The impact is simply vastly different.
One of those things is, “Oops, sorry,” and move on.
The other of those things is the potential of real liability, and you won’t get a third party to sign up for that.
DUCK. Do you think a lot of people still think of the idea of cybersecurity outsourcing or MSSP engagement as primarily about saving money?
Or do you think that people are starting to recognize that it’s the time that you can save to focus on your real business that sometimes matters much, much more, even though you probably save a lot of money as well, just from simple operational efficiencies?
DAVID. I think the conversation almost always starts with money.
I really do; I don’t know if that’s a cynical view.
I think the renewal often comes from operational efficiency.
I think, in the renewal, the customer now realizes that these duties aren’t the duties of their team anymore.
These “shackles of the quotidian” have been lifted from their team, and their team can do other things.
That still is a monetary saving, but it becomes an operational efficiency question once you’ve got an MSSP.
And so I often get the sense that prospects, non-customers, who are considering purchasing our service are attracted by the savings; are attracted by the money.
And I think that when they’ve been on-boarded, when they’ve been attracted by that, and they realize what it means to not have to analyze SentinelOne alerts anymore, then they realize, “OK, our engineers are now more efficient.”
“These engineers, which we are paying significant sums of money, aren’t responding to something that SolCyber can do at a much greater scale and much lower effective cost.”
I think the renewal comes from a place of efficiency, and I think the initial purchase often comes from a place of just simple cash savings.
DUCK. So David, to finish up, do you want to say something about how customers should expect their MSSP to engage on that human front?
How do you go about getting that working better, so that they can become a more secure operation, not just technically, but also socially, culturally, and from the human side?
DAVID. Everything that we’ve talked about today is available as a conversation, as an architectural conversation, to any customer of SolCyber.
One of the things that you should expect of your MSSP is that they engage with you – on both the things they’re good at and the things they’re not good at.
Not that they do the things they’re not good at, but that they call out with you in the room, “Hey, you’re sending us this internet-enabled dough mixer data, and we have no clue what it does, and even if we understood what these logs said, we still wouldn’t know what the operational expectations of the internet-enabled dough mixer are.”
That’s a conversation that a good MSSP will have with you, and it may not end in the answer you want.
That conversation might end with, “Stop sending us internet-enabled dough mixer logs.”
It makes no sense: you’re paying money, and we’re not analyzing them, right?
Maybe that’s not the answer you wanted, but it’s the conversation you needed to have.
It’s really important that you expect that if you’re a MSSP.
It is something we strive to do at SolCyber,
It’s part of our on-boarding; it’s part of our maintenance operations, quarterly reports, and so on.
Our engineers are always available to our customers to have those discussions.
It can be something as simple as, “Hey, I think my log volume’s kind of high – how can I reduce logging?”
Or it could be something as complicated as the internet-enabled dough mixer.
DUCK. I think another example that we’ve spoken about in a previous podcast is when we were talking about mobile device security, and you described this checklist of things you can do, which has 23 or 24 items on it.
But very few businesses will either need or want to do all 24.
And the important thing is to make sure, if you’re going to do 14 of them, that you pick the right 14 now, and in three months’ time, you go and look and see if some of them are unnecessary, or some of them should be changed.
In other words, cybersecurity really is a journey, and not a destination, isn’t it?
And when you bring an MSSP onboard, you should expect help with that journey, not assume that, “Well, *we’ve* reached a destination, and we’ll leave the journey entirely to the service provider.”
DAVID. Absolutely.
You are on this journey with the MSSP.
You should expect that they engage with you, but you also need to have a high standard of engagement for yourself.
It cannot just be “Sign the paperwork, walk away, and assume that your internet-enabled dough mixers are doing great.”
DUCK. David, thank you so much for your time.
It’s great to hear your thoughtfulness, and your willingness to confront those answers that sometimes are difficult for customers to accept.
But, like I said, it is a journey and not a destination.
If people are interested in finding out how SolCyber can make that journey easier and cheaper for them, where should they go?
DAVID. solcyber.com… or solcyber.com/blog and start reading! [LAUGHS]
DUCK. Yes, as an author for solcyber.com/blog, I’d love you to go there. {LAUGHING]
There are some great articles!
They’re not sales-schpiel pieces – they are intended as community engagement that will help us all do a better job, because this matters for everybody.
So, thanks so much to everybody who tuned in and listened.
Please subscribe to the podcast if you haven’t already.
Like us, and share us on social media.
And remember…
Until next time, stay secure.
Catch up now, or subscribe to find out about new episodes as soon as they come out. Find us on Apple Podcasts, Audible, Spotify, Podbean, or via our RSS feed if you use your own audio app.
Learn more about our mobile security solution that goes beyond traditional MDM (mobile device management) software, and offers active on-device protection that’s more like the EDR (endpoint detection and response) tools you are used to on laptops, desktops and servers:
By subscribing you agree to our Privacy Policy and provide consent to receive updates from our company.
