Category: IoT

Incentive Policy for Coordinated Vulnerability Disclosure

Assessment

For the past ten years or so, organizations have been trying to implement operational policies to avoid “Full Disclosure” reports or “Open Bug Bounty” whose methods are not that good in terms of honesty and responsibility.

Speaking of responsibility, you may be familiar with the notion of “Responsible Disclosure” and you wonder how it differs from the concept of Coordinated Vulnerability Disclosure?

The concept of responsible disclosure has too often been at the root of endless discussions:

On the one hand the vendors denounce “Disclosing a vulnerability without providing patches is not responsible”.
and the other, “Don’t fix this vulnerability as quickly as possible is not responsible”, say security researchers.

During this precious time when both sides argue, the system concerned is at the opponent’s mercy.

In order to move towards greater efficiency and to get out of sterile debates, it is therefore important to avoid speaking of “responsible disclosure”. This is why many organizations advocate the concept of “Coordinated Vulnerability Disclosure” (CVD) in order to promote and strengthen cooperation between the various actors in cybersecurity, all of whom have a common goal: Make the Internet safer.

Coordinated Vulnerability Disclosure

Coordinated Vulnerability Disclosure

Theory & Definitions

Coordinated Vulnerability Disclosure (CVD) is a process aimed at reducing risk and ultimately mitigating potential damage caused by a vulnerability affecting an information system. CVD is a process that cannot be reduced to the deployment of a patch or publication of a report, even though these events are indicators of the efficiency of cooperation.

A bounty bug platform such as Bountyfactory.io facilitates this process by encouraging the cooperation of thousands of security experts and organizations.
Cooperation: it is a key element of Cyber Governance.

Guillaume Vassault Houlière | YesWeHack CEO

Coordinated Vulnerability Disclosure is therefore the process of collecting information from Security Researchers, coordinating the sharing of this information among actors, and disclosing the existence of vulnerabilities (software or even hardware) and their mitigation measures to various stakeholders, including the public.

Coordinated Vulnerability Disclosure significantly increases the likelihood of success of any vulnerability response process. Contributions are often vulnerability reports written by security researchers.

CVD reports for a product (software or hardware) typically include patches as well as vulnerability report documentation or recordings in a vulnerability database.

NB: many operational vulnerabilities can be corrected by the operator and do not necessarily result in public disclosure.

Vulnerability disclosure is a process by which vendors and people who discover vulnerabilities can work collaboratively to find solutions that reduce the risks associated with a vulnerability.

ISO/IEC 29147 standard defining Vulnerability Disclosure

This process includes actions such as the reporting, coordination and publication of information on one vulnerability, its mitigation or, ideally, its remediation.

Let’s zoom in the concept :

Principles:

  • Reduce the risk of damage
  • Believe in good deeds, believe in good Samaritans
  • Avoid randomness
  • Boost cooperation
  • Follow the code of ethics
  • Learn from the OODA loop
  • Consider CVD as a process navigating between the “best” and the “worst”.

Goals:

  • Ensure that identified vulnerabilities are – well – addressed;
  • Reduce the risk of vulnerability;
  • Provide users with sufficient information to assess the risks associated with the vulnerabilities of their systems;

StakeHolders:

Coordinated Vulnerability Disclosure commonly begins with the detection of a vulnerability and ends with the deployment of patches or mitigation.

Therefore, several actors are involved in the CVD process:

  • Security researcher – the person or organization that identifies vulnerability.
  • Reporter – the person or organization who notifies the vendor
  • Vendor – the individual or organization that created or maintains the product that is vulnerable
  • System Administrator – an individual or organization that must implement a corrective action or take other corrective actions.
  • Coordinator – an individual or organization that facilitates the coordinated response process

Steps:

  • Discovery – Someone discovers a vulnerability in a product.
  • Report – The product vendor or a third party coordinator receives a vulnerability report.
  • Qualification – The recipient of a report validates it to ensure its accuracy before prioritizing it for further action.
  • Remediation – A remediation plan (ideally a software patch) is developed and tested.
  • Public Awareness – Vulnerability and corrective measures are disclosed to the public.
  • Deployment – Corrective measures are applied to the systems concerned.

The reporting step is important because it requires the creation of secure channels to ensure that transmitted information is not intercepted by a third party.

However, there are some obstacles within the process:

  • No vendor contact available – This may occur because a contact could not be found or because the contact is not reactive.
  • Termination of cooperation – participants in the CVD process may have other priorities that attract their attention.
  • Information leakage – Whether intentional or unintentional, information for a small group of actors can be passed on to others who are not involved in the CVD process.
  • Independent Discovery – Any vulnerability that can be found by one individual can be found by another, and not everyone will tell you about it.
  • Active Exploitation – Evidence that a vulnerability is being actively exploited by adversaries requires accelerating the CVD process to reduce users’ exposure to risk.
  • Communication is deteriorating – CVD is a process of coordinating human activities. As such, its success depends on the quality of the relationships between the participants.
  • Marketing – In some cases, vulnerabilities can be used as a marketing tool. This is not always conducive to the smooth running of the CVD process.

To sum up:

Vulnerability disclosure practices are no longer restricted to web applications. The Internet of Things and the constellation of SCADA systems, connected health devices, CCTV, Connected cars, etc. have become so dependent on software and the Internet that they increase the exposure perimeter and will inevitably be exposed to new attacks.

The Coordinated Vulnerability Disclosure is a major ally to federate the largest number of cyberspace actors and stimulate the exchange of knowledge to ensure both security and privacy protection by design.

By encouraging cooperation, CVD will enable all stakeholders not only to defend their common information assets but also to fight more effectively against the black market and the resale of Zerodays.

*

The set is now planted, so let’s switch from theory to practice.

Security.txt: the promising RFC!

In order to respond to the lack of contacts available to disclose a vulnerability on a website, security researcher EdOverflow, well inspired by the role of the famous robots. txt, suggested since the beginning of August 2017 to include in each website the file security.txt as a reference file containing the procedure to be followed to disclose more effectively to the editor of a site a bug, a vulnerability.

This approach has the merit of establishing clear guidelines for security researchers on how to report security issues and allows bug bounty programs to use them as a basis for defining the attack perimeter for future researchers.

[Edit] Where should I put the security.txt file?

The security.txt file should be placed under the /.well-known/ path (/.well-known/security.txt) [RFC5785].

*

Bug Bounty as part of your disclosure policy

As part of agile development on their own products, more and more vendors are choosing to be proactive by stimulating and cooperating with IT researchers:

  • by relying on in-house resources and expertise;
  • by contracting directly with external researchers;
  • via a platform that will connect researchers and one vendor. The latter will therefore pay for the result and will be able to choose between various options such as program management or even patch management if its internal resources are not sufficient.

NB: The creation and long-term implementation of a Bug Bounty program is considered as an indicator of the maturity of publishers’ E-governance in terms of vulnerability.

Since 2013, YesWeHack has been developing tools that greatly facilitate the implementation of an incentive policy for CVD.

YesWeHack, its community and ecosystem of services enable organizations and IT security researchers to better cooperate.

Thanks to the tools developed by YesWeHack, beneficiary organizations can more easily overcome the obstacles encountered by their CVD policy. In addition, organizations gain reputation by demonstrating their appetite and willingness for continuously improving their systems.

Bountyfactory.io as the first European platform of Bug bounty.

Differentiating criteria

  • Cooperation with European partners and providers as a matter of sovereignty.
  • Legal and technical infrastructure that meets the highest security requirements.
  • Security and confidentiality of communications based on encryption and compliance with ISO standards.
  • Securing financial transactions between organizations and security researchers.
  • Payment platform compliant with European anti-money laundering and anti-terrorist financing arrangements.
  • Support throughout the entire process: from the drafting of the program to assistance with corrective measures.
  • Operational ranking of the best researchers: Management of a security research community.
  • Reactivity that enables the best researchers to be mobilized in record time.
  • Ability to organize different types of Bounty bug programs (Private / Public / In situ / Hardware and/or Software).

Give it a try ! Register on BountyFactory.io

What should I do if a product does not offer Bug Bounty or Security.txt?

Zerodisclo.com

Zerodisclo.com

A simple and effective tool to avoid full disclosure of vulnerabilities in the wild.

It is important to note that some products (software or hardware) do not have their own Bug Bounty program. Thus, it is difficult for a security researcher to report a vulnerability to a vendor. Not all countries have a law allowing this kind of practice, as is the purpose of Article 47 of the Law for a Digital Republic initiated by ANSSI.

YesWeHack has created Zerodisclo.com to facilitate the escalation of vulnerabilities in a secure and even anonymous way and put in touch the different actors working for a safer Internet.

Thanks to Zerodisclo several obstacles are removed: no login, anonymization of the report via the Tor (.onion) network and mandatory and automatic encryption of the report content with the public PGP key of the CERT chosen.

The list of CERTs included in ZeroDisclo.com

Please find below the infographic of ZeroDisclo.com

The Internet of Elevators, of Cars, of Weapons !

lift

Have you ever watched The Lift ? A Dutch horror movie by director Dick Maas about an intelligent ( or smart ?) and murderous elevator starting a killing spree. (Source : wikipedia)

Scary, isn’t it ?

Beyond fiction, the film “The Lift” aimed at questioning technology, systems you can not regain control over.

Nowadays, we are told about the benefits of design thinking, internet of things and their tremendous power in terms of digital and economic development… Oh wait.

Unfortunately, the Internet of Things is driven by marketing ravenous hyenas and very few IoT companies are inspired by – what we could call – the Security Design Thinking.

nebula_of-things

Today, within the Internet of Things, Auto Industry has to struggle to prevent itself from being hacked both by criminals and by their inner blind appetite for market at the expense of their duty in the field of security.

Imagine the antithesis of the legendary film “Rebel without a cause” where the hero no longer rides a car as a symbol of freedom but he’s the prisoner of a runaway wagon.

The revelations concerning the recent fraud on the behalf of  Volkswagen – by the way VW is not an isolated case – highlighted what is at stake in terms of security in the fabulous world of the Internet of Cars.

Before reaching the point of no return, Cars companies and end users should deeply consider the following thoughts :

  • Cars like drones and planes are not harmless devices

In terms of security and safety, Auto and aeronautics industries have to be exemplary and they constantly have to improve again and again their technology, their protocol. Unlike many devices of the Internet of things, cars and planes are massive vehicles. They can cause real and serious damages when they are out of control. They unfortunately can be used as weapons. Therefore, smart and connected cars could be potential massive killing machines.

  • Millions of cars as One Botnet

Like any device of the Internet of things, a car can be pirated and subject to a botnet. In this case, a huge number of cars can be orchestrated as one  and only system driven by just one freak, Remember Skynet ! Needless to say that a terrorist attack could be coordinated via this kind of botnet.

  • Top priority : Privacy and Security By Design

IoT companies seem far from tackling the highly critical issue : How to secure the entire chain of their business including their precious customers (known as end users), their reputation, their data.

The Internet of Cars could be, somehow, a strong ally for security (reducing car accidents) and environmental issues (reducing the CO² emissions footprint) but Automakers don’t seem to prioritize acutely despite some attempts like the Automotive Cybersecurity Best Practices.

Auto industry has to embrace privacy and security by design, they must think and implement these concepts before moving on to the unbridled production of hackable products.

Examples of compromised connected cars are legions such as Tesla, Range Rover etc.

To address these concerns and data compliance issues, car manufacturers need to address privacy and security issues and legislative requirements at the design stage – and not as an afterthought – and, in the EU at least, will need to develop technological solutions to empower individuals to track and manage their own data.
Privacy by design – essential for the growth of the Internet of Things? by Taylor Wessing

  • The vital need for an offline button.

In case of emergency, every single connected car should be provided with a kill-switch feature meaning at any time one could switch a smart car from a full connected mode to a full manual and off-line mode including the old-school and reliable steering wheel.

  • Fighting the diktat of Obsolescence

Tackling the issue of Obsolescence is highly relevant especially when the world is facing the global climate change. Beyond security, Car Manufacturers have to improve the reputation of their products and thus adapt their marketing policy by promoting the sustainable quality of their vehicles.

  • The fallacious comfort of voice controlling, key-less and wireless features

Internet of Things is a constellation of connected devices, it requires user-friendly innovation to  improve its appropriation by speaking human beings. It turns out to be clear that voice controlling, key-less and wireless features are to be core parts of IoT UX namely User experience.

That Generalization of wireless and key-less features is a real curse for it is exposing more and more IoT and therefore smart cars to encryption_is_not_a_crimecriminals. There are numerous testimonies asserting that thieves use cloning electronic tools to illegally open and drive cars. Those kind of tools can -easily- capture and reproduce voice spectrum, wireless signal and so on and so forth. Therefore, Encryption and physical tokens are still good layers of security for Multi-factor authentication (MFA).

Indeed, it has been said that multi-factor authentication is the worst form of security except all those other forms that have been tried from time to time. – The Churchill Way of IT security 🙂

  • Security is a continuous process

First, Security through obscurity is no cure because it hides potential and critical bugs.

Definitely, Car Industry should strengthen its proof of concept by testing continuously the robustness of their technology. Open Source code enables companies to improve their protocol.

By Open Sourcing and submitting the code to communities (IT security Experts, hackers, FLOSS developers) AutoMakers will increase significantly the degree of their products’ security,  especially thanks to bug bounty programs.

There was a landmark : for the first time in the history of automotive, Fiat-Chrysler did invite hackers to test their cars in the framework of bug bounty programs with clear boundaries made of legal, financial norms such as BountyFactory.io

To sum up, Car industry has to find its Way within the IT security experience by questioning itself  and applying the OODA loop scheme.

the Way is not an end but a process, a journey… The connections, the insights that flow from examining the world in different ways, from different perspectives, from routinely examining the opposite proposition, were what were important. The key is mental agility.
– John Boyd

ooda-loop-1-1(Source : The Tao of Boyd: How to Master the OODA Loop )

Powered by WordPress & Theme by Anders Norén