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)

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.

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.

 

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.

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?

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..

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.

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.

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.

 

 

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.

 

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.

 

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.

Already a member? Login here | Join now

Related Reports

Dahua Critical Cloud Vulnerabilities on May 12, 2020
Dahua has acknowledged a series of cloud vulnerabilities that researcher...
Use Access Control Logs To Constrain Coronavirus on Apr 09, 2020
Access control users have included capabilities that are not commonly used...
Vintra Presents FulcrumAI on Jul 02, 2020
Vintra presented its FulcrumAI object recognition and mask detection offering...
Defendry Presents AI Active Shooter Security System on Jul 14, 2020
Defendry presented its Active Shooter security system at the May 2020 IPVM...
Vulnerability Directory For Access Credentials on Feb 20, 2020
Knowing which access credentials are insecure can be difficult to see,...
Milestone Presents XProtect On AWS on May 04, 2020
Milestone presented its XProtect on AWS offering at the April 2020 IPVM New...
Video Surveillance Architecture 101 on Feb 18, 2020
Video surveillance can be designed and deployed in a number of ways. This 101...
VSaaS 101 on Mar 25, 2020
Video Surveillance as a Service (VSaaS) is the common industry term for cloud...
FLIR Presents Dual Spectrum High Security Focused PTZ on May 01, 2020
FLIR presented its Elara DX-Series bispectral, visible and thermal, PTZ...
Asylon Presents All-Weather Automated Security Drones on Jun 18, 2020
Asylon presented its All-Weather Automated Security Drone, the DroneCore, at...
ISS Presents Face As A Credential and UVSS on Apr 30, 2020
ISS presented its security platform, including access control integration,...
Access Control Online Show July 2020 - On-Demand Recording of 45+ Manufacturers Presentations on Jul 30, 2020
The show featured 48 Access Control presentations, all now recorded and...
Video Surveillance 101 Book Released on Jul 07, 2020
IPVM's unique introduction to video surveillance series is now available as a...
Convergint Coronavirus Cuts on Mar 25, 2020
One of the world's largest security integrators, Convergint, has made a major...
SafeZone Tech Presents AI Gunfire Detection on Jun 15, 2020
Safe Zone presented its AI gunfire sensor the May 2020 IPVM Startups...

Recent Reports

Dahua Taunts Australian Government, Continues To Sell Illegal Fever Cameras on Aug 10, 2020
Dahua is effectively taunting the Australian government by continuing to sell...
HID Releases VertX Replacement Aero on Aug 10, 2020
HID is replacing two established and broadly supported types of access...
NDAA Compliant Video Surveillance Whitelist on Aug 10, 2020
This report aggregates video surveillance products that manufacturers have...
Telpo China Temperature Tablets Tested on Aug 10, 2020
The provider for overseas companies ranging from Canon Singapore to US'...
Dangerous Hikvision Fever Camera Showcased by Chilean City on Aug 07, 2020
Deploying a fever camera outdoors, in the rain, with no black body, is...
"Grand Slam" For Pelco's PE Firm, A Risk For Motorola on Aug 07, 2020
The word "Pelco" and "grand slam" have not been said together for many years....
FLIR Stock Falls, Admits 'Decelerating' Demand For Temperature Screening on Aug 07, 2020
Is the boom going to bust for temperature screening? FLIR disappointed...
VSaaS Will Hurt Integrators on Aug 06, 2020
VSaaS will hurt integrators, there is no question about that. How much...
Dogs For Coronavirus Screening Examined on Aug 06, 2020
While thermal temperature screening is the surveillance industry's most...
ADT Slides Back, Disappointing Results, Poor Commercial Performance on Aug 06, 2020
While ADT had an incredible start to the week, driven by the Google...
AHJ / Authority Having Jurisdiction Tutorial on Aug 06, 2020
One of the most powerful yet often underappreciated characters in all...
SIA Coaches Sellers on NDAA 889B Blacklist Workarounds on Aug 05, 2020
Last month SIA demanded that NDAA 899B "must be delayed". Now that they have...
ADI Returns To Growth, Back To 'Pre-COVID Levels' on Aug 05, 2020
While ADI was hit hard in April, with revenue declining 21%, the company's...
Exposing Fever Tablet Suppliers and 40+ Relabelers on Aug 05, 2020
IPVM has found 40+ USA and EU companies relabeling fever tablets designed,...
Indian Government Restricts PRC Manufacturers From Public Projects on Aug 04, 2020
In a move that mirrors the U.S. government’s ban on Dahua and Hikvision...