Re: [Last-Call] Last Call: <draft-foudil-securitytxt-08.txt> (A Method for Web Security Policies) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

 

I thought I’d provide some feedback as we wrote a report in 2018 assessing the state of vulnerability disclosure in consumer products[1]. We assessed 331 IoT companies selling the most popular devices in major shops and websites across the world. The original research found that <10% had any mechanism for security researchers to contact them. We recently re-ran that work in order to see what progress had been made in 2019 and I thought I could add some additional context to this based on our current research which is about to be published by the IoT Security Foundation. In this year’s review, we looked at additional factors – for example:

 

·      The usage by companies of a /security page or a redirect to their actual security page, 4.2% (14)
·      Companies with a security.txt file located at <domain>/.well-known/security.txt, 0.9% (3)

 

This illustrates that of the companies we surveyed, there is a very low awareness (but some) of the concept of security.txt in that location as well as some limited awareness of the need to redirect /security to help security researchers. In general we found that the situation is still very poor but slightly improving and we expect that to significantly improve based on various governments’ efforts to promote vulnerability disclosure policy and reporting mechanism adoption by, particularly IoT companies.

 

We wrote a tool to automatically check whether the security.txt exists and this in itself was useful and expedited our theoretical ability to contact the companies if we wanted to. For many researchers being able to quickly wget this file will be very beneficial to them. I have one concern (and I have seen this already happen) which is that some companies will stop using a /security web page or other public facing security contact and essentially ‘hide’ in security.txt. This work should not supplant a /security page but should be hand-in-hand with it. This would create a technical barrier for submitting security reports – for example the security report last year by a young boy against Apple’s Facetime would probably have not got through (rejection is a separate issue!).

 

I should also add that in many cases where I’ve wanted to contact companies in the mobile industry, they have not used a security@ email address. This could be to avoid spam or it could just simply be that the address was already being used (I know this is the case in a couple of companies, in the same way as /security). In some cases however, very obscure email addresses have been used for no obvious logical reason. I have dealt with a couple of cases where I’ve had to facilitate researchers by just getting the email address in the first place.

 

In the overall context of a lack of security in IoT companies, I think any strengthening of the mechanisms by which security researchers can contact companies is welcomed. I hope that this proposal will be adopted by many, including governments who are recommending that companies implement CVD for IoT. The concerns raised about the security.txt file being hijacked are valid but in my view the same situation exists for any /security page too currently.

 

Therefore, I strongly support the proposal with the amendments already raised by a number of people on this list and will happily push this into the mobile and IoT industries once it is published.

 

[1] Understanding the Contemporary Use of Vulnerability Disclosure in Consumer IoT Products https://www.iotsecurityfoundation..org/wp-content/uploads/2018/11/Vulnerability-Disclosure-Design-v4.pdf

 

Thanks,

 

 

David.

___________________________________________________________________

David Rogers MBE

Chief Executive Officer

david.rogers@xxxxxxxxxxxxxxxxx

Copper Horse

Web: https://www.copperhorse.co.uk

Twitter: https://twitter.com/drogersuk (@drogersuk)

___________________________________________________________________

 

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux