VULNERABILITY DISCLOSURE?

DailyPost 834

VULNERABILITY DISCLOSURE?

If you go through two three levels below what normal cognition can take care, we reach a level where we find most of the objectivity compromised or there is a clear cut effort to remain indifferent or evade the whole issue altogether. Even worst is when the disclosure is evaded. So is the case with vulnerability disclosure in the IT domain. This case pertains to one of the biggest vulnerabilities of all time. This pertains to Intel, the discovery was devastating. This has happened a year back but transparency still remains a frozen concept.

The vulnerability was a design level flaw that could slow down every processor globally, lacking any perfect fix short of a gut redesign. No major tech company would remain unaffected. It ranged from Amazon’s server farms to the chipmakers like Intel & ARM. But the secondary problem emanating out of it is the core issue; “how do keep a flaw this big a secret long enough for everyone involved to fix it?” Security world has its nuances and the mechanics of disclosure is a knot which nobody has been able to entangle. It leads to complications of various types – either way. It is very difficult to fathom out the damage instantaneously or in a short time and to put remedial action in place perfectly.

The convention is pretty straight. “Whenever a researcher finds a bug, the custom is to give vendors a few months to fix the problem before it goes public and bad guys have a chance to exploit it.” Nobody knows the progression of damage. As the bugs moves to affect more and more companies and more and more products, the mechanics of it’s non-disclosure becomes more and more complex. More and more people have to be informed of the issue, the patch / software needs to be developed as a surreptitious one and has to pushed to the machines required. It is finally a multi-party coordination which broke down in the case of Meltdown & Spectre. The end result was that the secret was out in the open before anybody was ready for it.

The problem with this approach is that some crucial impact making groups are kept out of the loop. The initial report recommending CPU replacement was not the right & a doable solution. Carnegie Mellon’s CERT division was out of the picture. Dorman of CERT changed the recommendation to simply installing patches.

TIMING VULNERABILITY DISCLOSURE IS A CATCH 22 SITUATION.

Sanjay Sahay

Leave a Comment

Your email address will not be published. Required fields are marked *


The reCAPTCHA verification period has expired. Please reload the page.

Scroll to Top