Vulnerability Disclosure Program Part 1

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

8 hours 10 minutes
Video Transcription
Hi, I'm Matthew Clark. This is less than 6.4 vulnerability disclosure programs. Part one.
You've designed a popular product, and there's a steady demand. Ford. And what's more, you're pretty sure that it's secure. Congratulations. Then the unthinkable happens. One afternoon, after returning from lunch, you receive an email. Ah customer informs you that they've discovered an undocumented port open on your device.
They crafted some special packets and were able to make the product behave
in an abnormal way.
Maybe the device crashed, or maybe the device gave them rude access.
Or maybe the device displayed a Eriko that gave them a little too much information. Or maybe they were able to access customer data in the cloud. Now that you're aware of the incident,
what is your team going to do to address it? In this lesson, we'll take a look at vulnerability disclosures and discuss what happens next and why we need the vulnerabilities closure program.
We'll identify different points of view and discuss immediate takeaways and look at the example from the news. So let's get started.
But you thought you had designed to secure product. How could there be an open port on it Well, the truth of the matter is, regardless of how secure you think a product is,
are the interfaces are or the application has been designed or the back end servers have been secured or the Web pages have encoded, or how many times you've checked to make sure that the A P I key wasn't in the source code. Something is bound to happen
because there's no such thing as a perfect security. So plan for it.
What are you going to do in that? Email comes because it will come.
So let's walk through this imaginary scenario and try to predict what different types of questions different groups of people in the organization might have.
Let's start with the product engineers because they they're gonna be closest to the issue and vital to understanding the true nature of the disclosure.
So they're gonna ask questions like, can they recreate the air? What was the patch level of the device?
Did they tamper with the physical properties of the device?
Did they intercept network communication to in order Thio determine this or what were the environmental conditions that were occurring at the time of the error
and what kind of questions might the lawyers asked. Oh, my goodness. Were we breached? Was what data was access. Was the data exfiltrate ID?
Where were the customers located? Because we have reporting requirements. Have we started our incident response plan yet?
Did the customer opt in to our software Click through agreement?
Were we following our data? Attention policy. Should we bring in external counsel? Does cyber insurance cover this?
What senior management gonna say? Oh, my goodness. Where we reached?
What? Do we have a plan for addressing this? Do we have the right resource is in place? Has this been reported external yet?
And do we see this coming? And why weren't we prepared
those previous questions or just things that I came up with off the top of my head, based off of previous interactions with different groups of individuals?
But what would your frontline individuals say if the communication came to them instead of in an email to you?
Well, customer support might ask questions like, did you reboot? Can you repeat your question? Because I don't see anything in the documentation here about this issue,
or I don't know how to report a security vulnerability can you hold, please? Why? I talk to my supervisor.
So what are some of our immediate takeaways? Well, the first one is that we should be prepared. If you're going to sell I o. T devices and provided service, then you need to be prepared for the eventual notification, because it's not a matter of if, but when someone will contact you and they're gonna want to know that you have a process.
This is similar to programs and policies that you already have in place, like incident management, vulnerability management, bug tracking and resolution.
But there's also so much more to this, you're no longer in control of the narrative. When someone reaches out to you about an issue,
you're forced to be reactive toe whatever happens, and you can choose to do that in several different ways. You can choose to go after the security researcher, as if finding a vulnerability in your product is somehow their fault.
Or you can choose to ignore it. That never seems to have really good long term effects.
In the case of a former CEO of Equifax, you could blame the entire event on a single unnamed I T. Guy That's always a very admirable trade to have in a leader,
or you could choose toe, meet it head on, and this is where we're going to focus on. How do you develop a plan and a process toe Handle? Vulnerability disclosures.
Because this demands a coordinated response, success is not just having these elements in place. Sure, you need a vulnerability management and bug tracking and incident response, and they generally work great apart. But you now you need them toe work great together, and the biggest advantage that you have
is to have a process already defined,
practiced and ready to G O.
The last thing you want is, too, for the frontline employees not to know how to handle these. Because that leaves there's security researcher with little direction on how to report them
and requires them to work harder to get the proper knowledge into the right hands. So the first step for companies wishing to set this process up is that they must have a valid intake process. You shouldn't expect a security researcher to be clairvoyant. They shouldn't have to be a mind reader to figure out how you'd like to be notified
and This isn't a penetration test exercise, either.
They shouldn't have to goto linked in together open source intelligence on how your company is organized.
Here's an article by Mary Branscomb for ceo dot com. Mary, by the way, is a great reporter, a great writer
in her CEO dot com article. How to Handle Security Vulnerability Reports Mary told of an experience of Troy Hunt. Have I been pond dot com ad?
When trying to contact an organization about sensitive data that was publicly available?
Troy said Quote, It's often very difficult just to get in touch with the company in the first place. Even the big ones. I'm going through multiple data breaches and I just can't get The Contact's email was bouncing, even though who is contact information for their domain was bouncing.
In the article, Troy goes on to say that the slow responses air not uncommon even for a larger organizations because they lack of process for how they will deal with the incident.
Read this article and I put a link to in the Resource is it's really good.
So my question to you is how would you do this? And we're gonna answer that in the next lesson.
That's it for this lesson. In this lesson, we began our journey into the mysterious world of vulnerability disclosure
we took. We looked at different points of view, including engineering and legal and senior management, and the front lines aboard and our takeaways were that we needed to be more proactive. We need to have a coordinated response. And we ask ourselves, Why is this so hard that even the large companies are struggling with this
and we'll talk about how to resolve it in our next lessons?
I'll see you next time.
Up Next