Vendors have a responsibility to deliver products to the best of their “security” capacity. At the same time the vendor’s customer have a responsibility to push for security accountability. Huawei’s Customers share accountability for the lack of security capabilities and capacity.
Huawei responds to the DEFCON presentation ….
“We are aware of the media reports on security vulnerabilities in some small Huawei routers and are verifying these claims. Huawei adopts rigorous security strategies and policies to protect the network security of our customers and abides by industry standards and best practices in security risk and incident management. Huawei has established a robust response system to address product security gaps and vulnerabilities, working with our customers to immediately develop contingency plans for all identified security risks, and to resolve any incidents in the shortest possible time. In the interests of customer security, Huawei also calls on the industry to promptly report all product security risks to the solutions provider so that the vendor’s CERT team can work with the relevant parties to develop a solution and roll-out schedule.” – Huawei’s US PR Statement
Major Note: A Press statement is NOT an effective vehicle to restore confidence when someone finds a vulnerability with the product. Especially when the press release provides contradictory information. The press statement says to use psirt@huawei.com vs the NSIRT@huawei.com.
Who’s responsible for Huawei’s handling of the vulnerabilities disclosed at DEFCON? All would agree Huawei is the accountable party for vulnerabilities discovered in their products. Huawei has to have clear and effective vulnerability disclosure processes that allows for any organizations to know the following:
- Who to contact if you find a vulnerability in the product? (E-mails, phone numbers, and PGP keys)
- What will be done once the vulnerability is reported? (saying we’ll investigate is not enough in this environment of rampant cyber-crime and open cyber-warfare)
- How will information about the vulnerability be disclosed? (Public pages or private customer only pages work – but the policy needs to be public.)
The normal practice is for organization to have a “/security page” that contains this information. For example, www.microsoft.com/security, www.cisco.com/security, and www.yahoo.com/security point to pages that list the basic three requirements plus more specifics that apply to the organization’s unique characteristics. If Felix Lindner (also known as “FX”) and Gregor Kopf found a vulnerability on Microsoft, Cisco, or Yahoo resources, they would know who to contact, what to expect when they contact the security teams, and be able to point to the organization’s vulnerability disclosure process. With Huawei, none of this existed. It is an issue with Huawei, but it is also an issue with every service provider who buys equipment from Huawei.
I would assert that Huawei’s customers shares accountability for Huawei’s laze-fare vulnerability management. The service providers who evaluate, select, and deploy vendor’s equipment in their network are accountable for their network. These SPs depend on their vendors to do their part to assure resiliency and security in their network. But, these same SPs are the accountable to their customers – customers who depend on critical communications. The SPs cannot afford lame security approaches from their vendors. It is incumbent for the security team of a SPs to insure a major vendor (Huawei in this case) has the processes and procedures they require to safe guard their network. Vendor non-compliance means that many SPs are ignoring security in their network. 🙁
This is an easy problem to fix. Economics and purchasing power are the most powerful drivers for security improvements in the private industry. Huawei’s customers have a unique relationship – requiring Huawei provide the essentials of security vulnerability management which match the SP’s satisfaction.
As mentioned in the SP Security Workshops, every service provider must have the following information from each of their vendors:
- Public “Security” Page that list the 7*24 hour security contact for the vendor that includes their vulnerability process and disclosure procedures
- Clear and rational policy to update your software which is deemed vulnerable.
- Commitment from the vendor to actively participate in the industry wide security practices and organizations. For example, is the vendor part of www.first.org?
- Does the vendor use the Common Vulnerability Scoring System (CVSS) in their Security Advisories?
- Does the vendor use the Common Vulnerability Enumeration (CVE) in their vulnerability processes?
- Does the vendor write their security advisories in format that are useable by the service provider?
Network Operators – please add these to the requirement for purchase (RFP). Imaging the impact if every service provider includes these and other “vendor expectations for vulnerability management” to their RFPs. If you like this “RFP” approach, please review the International Organization for Standardization (ISO) work on responsible vulnerability disclosure. FIRST is working with the ISO working groups and has a good summary page here: http://www.first.org/vendor-sig/iso_activities
Recommended Service Provider Action: Pull from the FIRST, ISO, and other work to build your own RFP vulnerability disclosure requirements. All owners of network infrastructure have a role to pressure the industry to do their best to deliver secure code. The RFP power does impact behavior – setting expectations that produce results.
Need Security Advice?
If you find your organization needs help and worry about the FUD from the industry, reach out and ask for help. You can reach me at bgreene@senki.org. Start with the Operator’s Security Toolkit. It is the no-nonsense security for all Operators. It provides details to help them build more security resilient networks. In the meantime, stay connected to the Senki Community to get updates on new empowerment and security insights.