Stats: Disclosing Vulnerabilities Responsibility? Researcher or Manufacturer

By: John Honovich, Published on Mar 30, 2018

Getting prompt and appropriate information on vulnerabilities is important for integrators and end users to ensure that their systems are best protected and updated against exploits.

But who should disclose this? Cybersecurity researcher, Bashis, who has found vulnerabilities in numerous video surveillance products, recently asked this. We gathered 150+ integrator responses to see what they believe is the right answer.

A clear theme emerged: Integrators overwhelmingly believe manufacturers are responsible for announcing but almost equally are worried that manufacturers will avoid that responsibility.

Inside we examine the results and share detailed integrator feedback.

******* ****** *** *********** information ** *************** ** important *** *********** *** end ***** ** ****** that ***** ******* *** best ********* *** ******* against ********.

*** *** ****** ******** ****? Cybersecurity **********, ******, *** has ***** *************** ** numerous ***** ************ ********, recently ***** ****. ** gathered ***+ ********** ********* to *** **** **** believe ** *** ***** answer.

* ***** ***** *******: Integrators ************** ******* ************* are *********** *** ********** but ****** ******* *** worried **** ************* **** avoid **** **************.

****** ** ******* *** results *** ***** ******** integrator ********.

[***************]

Exec ******* - *****

*********** **** ******* ***** between ************* **********, *********** disclosing *** '****' **********:

Hiding ** *************

**** *********** ********* ******** that ************* *** ********* ** hide ** ******* ************* disclosures:

"** ***** ** **** if *** ************* ***, but **** ***** **** sugar **** *** ***** to ******** ***** ********* liability."
"*** ****** **** ******* it ** **** *** manufacturer ** **** **** almost ********* ***** ************ until **** *** **** it ** ***** ******."
"***** ************* *** ********, some ** *** ******* with ******* *** *** need ** **** ** paramount."
"************* ****** ** ******* to ***** ******** ******* pressure **** *** ********** going ******. ******** ** the **** *********."
"***** ** ******* **** frustrating **** ** **********'* standpoint **** * **** an ***** ** * customer ****** ** ** issue ****** * **** it **** *** ************. Then **** *** **** to *** ************ **** are ***** *** **** it ** *** ****** yet *** **** ** addressed ** *** **** firmware."
"************** ***** ** ** the ************, *** ** reality **** ***** **** it ** ***** ***** until ****** ** ****** due ** *** ******** impact **** *************** *** to *** **** ** the ******."
"* ******'* ***** *** manufacturers ** ** *********** about *************** ********** ***** their ********."
"************* ***'* ** ****** upon ******* *********** ******* them ** *****"

Researchers ********, ** ************ ** ***

******* ** *** ******* of ************'* ******, *** most ****** ********** ******** was **** *** ********** should ******** ** ** the ************ ******* ** do **:

"*** ************ ****** *** manufacturer ***** ** ******** it, **** *** ********** who ***** **!"
"** *** ************ *****'* respond *** **** **** the ***** **** *** researcher ****** **** ******* into ***** *** *****."
"************ ****** ** **, but ** **** *** “ethically **********” **** ** falls ** *** ********** to **** *** ************ to *** ******."
"** *** ************ **** not ******** ***** ** has **** *****, **** *** researcher ****** ***** * manufacturer ** ******** *** after * ***** ****** of **** **** *** disclose."
"*** **** ** ** the ************, *******, ** is **** ***** **** they ***'* ****** ******** the ************* ***** **** have ******* **. ********* it **** **** **** to *** ********** ** inform **** ****** ******* it ** * ***** like **** *** ***** to **** ** ****."
"*** ****** *** ***** it ****** ******* *** maker ** *** ******* and (********* ** *** nature ** *** *************) give **** ** *********** time ** ******* *** problem, **** ** ** action *****, *** ****** who ***** ** ****** make ******."
"** * ******* *****: the ************. ******* *** not * ******* *****, If * ************* ** discovered *** *** ************ will *** ***** *** or *** ** **** in *-* ****** *** researcher *** ***** ** should ******** **."
"** ****** ** *** manufacturers ********** ** ****** their ******* *** *** industry ** * ****** manner. ** **** ************ is *** ****, **** I ******* **** *** researcher *** ** ************** to ******* ***** ******** and **** **** ***** to *** ******."
"*** ************ *** * responsibility ** ***** *********** to ******** ************** **** may ****** ***** ****** networks. ** **** ** not ******* ** ** issue, ** ****** ** made ******."
"*** *** ****** **** be ******** *** *********** to ******* *** ***** and ************ ** *** same ****. ** *** repair *** *** ***** place, *** ********** ****** announce *** *******."
"********** ****** ****** *** manufacturer *** ** ************ does *** **** ** right ** ****** *** issue *********** **** ********** need ** *** **** so ****** **** *****."
"** *** ************ ******* does *** **** *** ethical ****** *** ******* to ******* ** *****'* exist, **** ** ** perfectly ********** *** *** researcher ** ***** ***** hand ************** **** **** shown *** *****, ******** disregard *** *** *********, or *** ********* **** plain ** *** *********** that **** **** *** willingly **** **************/****** *** their ******."

Both ********

**** *********** ********* **** 'both' ** '***' ****** announce *** ******** ** maximize *** *********** **** these ****** *** ***** out ** *********** *** users:

"****** ****, ** **** any ******** ****** **** should **** * ***** channel *** ******** *** announce ****** ******* *** loudly."
"****. ** ********* ***** both ** **** *** understand **** **** *****"
"****. ****** ************* ** researcher ********* *** *************, and *** ************ ******** how ** ******* ***** product."
"**** *** *********** *******. If *** **** ** a *************** ** * product ** ***** ** in *** **** ******** of ********* *** *** the ******* ** ** made ***** *********** ** cyber-security ******. ********** ****** inform *** ************ *** if ************ **** *** make ** ***** ** fixing *** ***** *********** then ********** **** ** out **** ** ****** area *****."
"****. *** *********** ****** contact *** ************ **** a **** **** ****** them **** ** *** the ************* *** **** announce *** ******** **** to ****** **. **** the ********** **** *** it ********, *** *********** will ****."
"* ***** ****. *** researcher ****** ******* ** to *** ****** *** the ************ *** *** larger ************** ** ********** their ******* *************** *** helping ** *** *** issues."
"****. *** *** ********** should ** *******, ** the ************'* ******** ******** of ******** ***** **** itself ** ********* (** non) **********."
"****. ** ***** ** a ****** ********. ************* can't ** ****** **** without *********** ******* **** in *****, *** ***** researches **** ********** * vulnerability ** **** * name *** **********."

Burden *** ***********

***** ** ** ************** why *********** ***** **** researchers ** ******** / disclose, **** *********** *** specialists ** *************, *** marketing ** ****** *********. Also, **** *** ***** this *** ** ************, so ** *** ** costly *** **** ********* for **** ** ********** such ***********.

Marketing ******** *** ************* *********

** *** ***** ****, cybersecurity ********* *** ******** that *********** *** ** great ********* *** **** (e.g., *****'* *** ** ******** Exploiting ************ *************, ****** / ********* ************* Dispute). **** **** ********** sophisticated ** ********* ***** they ********** ****** *** work **** ******* **** market ***** ******* ** get ***** ********* ******** articles. **** *** ** unfair ** **** *** manufacturers *** **** *** vulnerabilities *** * ******* for *********** *** **** need ** **** **** the ************ ** *** exaggerated ****** ** *** PR ********.

Challenging ********* *** ***

**********, *** ********* ** a *********** *** **** (1) **** ************* ********* to ******* ** **** problems, (*) *********** ******** to become ****** ********* *** (3) ************* ********* ******* for *************** ** ****** their *** *********.

Comments (11)

Jonathan Lewit

03/30/18 05:10pm

Another complication is the security through obscurity position. Just because a risk was found, doesn't necessarily mean anyone was exploiting it. What happens when the risk is identified before proper remedies can be put in place? Is that creating more risk by telgraphing weaknesses that otherwise may have gone unnoticed?

Coming from the manufacture side, I am a big advocate of the manufacturer stepping up and taking the lead. The critical need is to build trust with business partners and customers. Cyber security is a complex issue that requires all parties to work together. If anyone doubts the positive intentions of the other, the system breaks down pretty quickly.

bashis mcw

In reply to Jonathan Lewit | 03/30/18 06:00pm

security through obscurity position

Never been a good idea, and will never be either.

Just because a risk was found, doesn't necessarily mean anyone was exploiting it. What happens when the risk is identified before proper remedies can be put in place? Is that creating more risk by telgraphing weaknesses that otherwise may have gone unnoticed?

I can't be sure, but my guess is it has already been exploited in one way or another.

What I am saying (with very few exceptions) for the things I have found while researching (and still do), has been known for years of some people/organisations and even manufacture itself, I am not so naive that I think I'm the first one who find +5 or even +10 years backdoor and/or vulnerabilities.

I may be the first one who publicly disclose, but that is different thing.

Jonathan Lewit

In reply to bashis mcw | 03/30/18 06:29pm

I fully agree with the distaste for security through obscurity. Indeed I have lead several discussions around standardizing security practices, where this is often raised as a detractor.

Again, I think it comes back to trust and would try to lean towards being more proactive.

bashis mcw

In reply to Jonathan Lewit | 03/30/18 07:43pm

distaste for security through obscurity

I also feel that encrypted firmware is sort of 'security through obscurity', and every time i encounter encrypted firmware i ask myself 'what are you trying to hide that is so important that you need to encrypt the firmware?"

I don't see the point to encrypt firmware, unless it is within some point of protecting wrong firmware is uploaded to wrong device that potentially brick the device.

Again, I think it comes back to trust and would try to lean towards being more proactive.

Agree to certain point with you, but would like to know more what 'trust' and 'proactiveness' you mean?

Undisclosed

In reply to bashis mcw | 04/02/18 02:17pm

I think encryption as a mechanism to protect proprietary information or customer data is perfectly reasonable.

Encryption to protect your lame web server configuration because you can't read the apache httpd2 man page is not helpful.

I also think a proper security review needs to include access to many details proably including the firmware.

P.s. mystery meat browser plugins used to display camera video relate to this too..

Undisclosed #1

03/30/18 05:21pm

There should be a reward for the researchers time whether or not some take the initiative to provoke what seems to be safe or stumbling onto a curious mistake. Some of us cannot break habits and some of us cannot adopt new ones. Hopefully soon AI can look for anomalies in code and authentication standards and simply post the nature of how secure a location on a network performs. Think of the password strength bar, it changes colors the more complex your password, AI can do that and probably already does as it is obviously machines can farm us.

My general answer is, it depends on the mindset of the researcher to disclose what one has found and that could change on a day to day basis, emotion or caffeine level.

John Honovich

IPVM | In reply to Undisclosed #1 | 03/30/18 05:23pm

There should be a reward for the researchers time

I think there should be but who should give it? The party most interested are the manufacturers, but as the results above show, integrators are rightfully concerned that if the manufacturer rewards the researcher, they will tie that to the vulnerability not being disclosed at all.

bashis mcw

In reply to John Honovich | 03/30/18 05:51pm

John, what you are talking about here is NDA (Non Disclosure Agreement), quite common to be offered together with "award and/or potential work offer" when unearthing vulnerabilities and shared with manufacture.

I'm 100% against to sign any NDA, as once signed you are not independent anymore.

Besides, for the employer I actually _do_ work for, no need to force me to sign NDA as that comes naturally with the work for me.

bashis mcw

In reply to Undisclosed #1 | 03/30/18 06:23pm

My general answer is, it depends on the mindset of the researcher to disclose what one has found and that could change on a day to day basis, emotion or caffeine level.

It must be disclosed in my opinion, as it will help other researchers to assess the risk level, IDS/IPS can have updated signatures to catch these threats... etc.

Yes, it surely do come with additional risk to have devices compromised with noob / kiddies, or even sophisticated attackers, but I genuinely think Full Disclosure is the best option in general.

Undisclosed #1

In reply to bashis mcw | 04/02/18 01:35am

thank you bashis mcw. disclosure has many levels. a palace viewed from the outside may encompass the mind, however the internal reattribute struggles of the infrastructure may resemble that initial reaction to which you perceive.

Structures change, however I have caught public RFPs, BIDs, SOWs reduced to a single creator. Most of my criticism belongs to obvious yet oblivious changes by the designer.

Again, thank you Bashis. I know you see the internal store bought designs that only grasp vague encounters of cheerios with fruit.

Michael Glasser

04/01/18 09:46am

For those interested, here is some information on this topic. No endorsement implied.

"ISO/IEC 29147:2014 gives guidelines for the disclosure of potential vulnerabilities in products and online services. It details the methods a vendor should use to address issues related to vulnerability disclosure. ISO/IEC 29147:2014"

Hackerone - General Motors

Read this IPVM report for free.

This article is part of IPVM's 6,442 reports, 866 tests and is only available to members. To get a one-time preview of our work, enter your work email to access the full article.