Cybersecurity Patching in Context

10 minute read | Last updated 5-Sep-2019 |  Security, Vulnerabilities

Watch the episode on YouTube

Join the discussion on LinkedIn

Share on Twitter

Bad Robot Transcript

Morning, everybody. How you doing today in this episode of the show? We’re going to take a look at a really positive response to a software vulnerability. This week mulesoft which is actually now owned by Salesforce had a pretty bad software vulnerability in that happens now just to put this in context mulesoft is a middleware company essentially, they sell a service which helps you glue different systems together within those are Legacy on-premise Source a space systems and they helped do data transformation on connect events things like that, which you can see why it would fit really well in the Salesforce platform.

And that’s why Salesforce acquired them a couple years back to this a pretty important piece of software in most Enterprises either have a deployed and they can deploy as an on-premise version. Now, if you are well into the world of sass you may forget how much of a pain in the you-know-what on-premise software can be if there’s a critical software vulnerability you need to get customers aware of it.

They need to vent download it and perform their own upgrades as opposed to in a saucepan. System where that you are running the service and you can simply upgrade things behind the scenes and customers never need to know the steps to resolve it because you resolved it for them and you can just simply make them aware of any potential issue.

So has a bunch of these on-premise customers and they are in a critical space in a lot of these software Stacks. So when they had a software vulnerability they took what is unfortunately an extraordinary step and I say unfortunately because I think they should probably be standard practice for serious enough vulnerabilities now Catalan Timpano for reading for ZDNet had this story covered in he had a great way of portraying and a link to that article so that you can read it yourself.

I have been essentially he was saying that they were actually picking up the phone when reaching out to these customers. They sent an email to them to set up calls and then they just started dialing and setting up meetings with the customers to help explain the context of the issue in the steps that they The tech now he also actually got on a call and was immediately connected with the chief Technical and chief trust officer for me also had two of the senior most people from the company on the call with him explaining the issue and I don’t know if that’s what every customer got or simply mr.

Seem kind of got it because he was a journalist but the result is he is insane this company here realize that there was an issue that needed to be explained. It was important enough that people needed to address. So instead of just putting out an email or putting it up on the website or updating a dashboard.

They actually reach out to the customers and said hey here is the problem here is the steps to mitigate this problem and here’s the context in which this problem occurred and I think that is a great example. I think that should be done more often but one of the things that I wanted to really call it because it’s not always practical to necessarily call all of your customers, but what are the things that this approach really provides that I think is missing in the vast majority of Is context most the time we get these patches issued or vulnerabilities announced and we have a CVSs score and that gives you a relatively I need a reasonable idea of the severity of the potential impacts of you can get some of the details and you can start to grasp the issue with the challenges is applying it to your own situation is actually putting it in perspective How likely is it to be exploited? How easy is it to be exploited? The numbers don’t really tell you the story and that’s I think the number one challenge we have in patching a because most organizations don’t have a smooth patch process.

I know this is the number one issue in security and has been forever and put the realities most organizations can’t patch smoothly or quickly as a horrifying stock the other day and I put the source in a comment or isn’t overly here cuz I can’t remember off the top of my head but essentially was at after companies start patching within 90 days.

I’ve only covered just over 40% of the intended systems now, hopefully that’s prioritized by risk, but the reality is even three months after you started patching. You haven’t got full coverage cream and half covered yet. And that’s pretty typical really it’s a big people problem. It’s not so much as technology problem and it’s something that is a weak spot in security, but the because of this because of this challenge patching communication is critical because you need to know when it’s time to pull the alarm when it’s time to pull a break since they wait we need to deploy dispatch immediately.

The risk is high enough and I thought this approach for mulesoft was commendable. It was really tackle. That one weak spot of most disclosures for vulnerabilities or we just got to put it out there and say you figure it out contacts is missing contacts. What do you think hit me up online at Marcus theater, snow blowing as always by email me at Marquette.

CA, how do you handle patch management? How do you evaluate you notes or better question than patch management. How do you evaluate? What patches are actually important enough to pull the trigger to raise the alarm bells to get them pushed out there really really quickly. That’s a great question.

Let’s talk about that online. Hope your setup for fantastic day, and I’ll see you on the next episode of the show. Morning, everybody. How you doing today in this episode of the show? We’re going to take a look at a really positive response to a software vulnerability. This week mulesoft which is actually now owned by Salesforce had a pretty bad software vulnerability in that happens now just to put this in context mulesoft is a middleware company essentially, they sell a service which helps you glue different systems together within those are Legacy on-premise Source a space systems and they helped do data transformation on connect events things like that, which you can see why it would fit really well in the Salesforce platform.

And that’s why Salesforce acquired them a couple years back to this a pretty important piece of software in most Enterprises either have a deployed and they can deploy as an on-premise version. Now, if you are well into the world of sass you may forget how much of a pain in the you-know-what on-premise software can be if there’s a critical software vulnerability you need to get customers aware of it.

They need to vent download it and perform their own upgrades as opposed to in a saucepan. System where that you are running the service and you can simply upgrade things behind the scenes and customers never need to know the steps to resolve it because you resolved it for them and you can just simply make them aware of any potential issue.

So has a bunch of these on-premise customers and they are in a critical space in a lot of these software Stacks. So when they had a software vulnerability they took what is unfortunately an extraordinary step and I say unfortunately because I think they should probably be standard practice for serious enough vulnerabilities now Catalan Timpano for reading for ZDNet had this story covered in he had a great way of portraying and a link to that article so that you can read it yourself.

I have been essentially he was saying that they were actually picking up the phone when reaching out to these customers. They sent an email to them to set up calls and then they just started dialing and setting up meetings with the customers to help explain the context of the issue in the steps that they The tech now he also actually got on a call and was immediately connected with the chief Technical and chief trust officer for me also had two of the senior most people from the company on the call with him explaining the issue and I don’t know if that’s what every customer got or simply mr.

Seem kind of got it because he was a journalist but the result is he is insane this company here realize that there was an issue that needed to be explained. It was important enough that people needed to address. So instead of just putting out an email or putting it up on the website or updating a dashboard.

They actually reach out to the customers and said hey here is the problem here is the steps to mitigate this problem and here’s the context in which this problem occurred and I think that is a great example. I think that should be done more often but one of the things that I wanted to really call it because it’s not always practical to necessarily call all of your customers, but what are the things that this approach really provides that I think is missing in the vast majority of Is context most the time we get these patches issued or vulnerabilities announced and we have a CVSs score and that gives you a relatively I need a reasonable idea of the severity of the potential impacts of you can get some of the details and you can start to grasp the issue with the challenges is applying it to your own situation is actually putting it in perspective How likely is it to be exploited? How easy is it to be exploited? The numbers don’t really tell you the story and that’s I think the number one challenge we have in patching a because most organizations don’t have a smooth patch process.

I know this is the number one issue in security and has been forever and put the realities most organizations can’t patch smoothly or quickly as a horrifying stock the other day and I put the source in a comment or isn’t overly here cuz I can’t remember off the top of my head but essentially was at after companies start patching within 90 days.

I’ve only covered just over 40% of the intended systems now, hopefully that’s prioritized by risk, but the reality is even three months after you started patching. You haven’t got full coverage cream and half covered yet. And that’s pretty typical really it’s a big people problem. It’s not so much as technology problem and it’s something that is a weak spot in security, but the because of this because of this challenge patching communication is critical because you need to know when it’s time to pull the alarm when it’s time to pull a break since they wait we need to deploy dispatch immediately.

The risk is high enough and I thought this approach for mulesoft was commendable. It was really tackle. That one weak spot of most disclosures for vulnerabilities or we just got to put it out there and say you figure it out contacts is missing contacts. What do you think hit me up online at Marcus theater, snow blowing as always by email me at Marquette.

CA, how do you handle patch management? How do you evaluate you notes or better question than patch management. How do you evaluate? What patches are actually important enough to pull the trigger to raise the alarm bells to get them pushed out there really really quickly. That’s a great question.

Let’s talk about that online. Hope your setup for fantastic day, and I’ll see you on the next episode of the show.