Responding to cyber vulnerabilities as a vendor is a lot like responding to diaper issues. No matter what, you are going to handle a lot of crap from both ends. As a vendor, all you want to do is clean it up, and move on with operation. But just like diapers, doing it wrong invites a smelly mess that everyone you invite over will comment on. And blaming the producer just isn’t realistic, because it happens whether you like it or not. Instead, change how you react, rather than trying to convince the producer to quit. At the S4 Conference this year, I presented on using the Microsoft Attack Surface Analyzer to critique protective relay programs. While not a ‘bloodbath’, the research brought to light some fundamental cyber issues with the development of these programs, and I picked two programs as showpieces in the presentation.
The two programs, Schweitzer Engineering Labs’ (SEL) AcSELerator and Schneider’s MiCOM S1 Studio, both demonstrated file permissions issues that made the installed system less secure. Additionally, Schneider had a service vulnerable to privilege escalation, due to the file permissions. The issues were swiftly found through the use of the Attack Surface Analyzer, and recommendations to fix were included. I reported these issues to the vendors, and worked through the process of giving them details.
Comparing and contrasting the responses allows me to comment on vendor response in general.
First off, the responses highlight a very real problem in vulnerability response; authority for cyber security response is rarely concentrated in one part of the organization, it is distributed out to the various business units. This usually reflects a lack of a top down approach to security, where individual units and groups can decide on a response based on their own judgement of risk. How would investors respond if the risk was from accounting practices, or safety, or diversity in the workplace instead of software development? That’s why authority to respond to those issues is held at the top level.
Second, vendors must recognize that their capability to respond scales with the size of their organization, and allocate resources to combat the scale. The responses provide a case study. SEL, a smaller company with a core product set and a generally flat organization, responded with timelines, actions, and full fix promises, generally considered the gold standard. On the other hand, Schneider is a massive holdings company with diverse business units, and it’s response was more legal and liability related. To me, this reflected an inability by the Schneider cyber security response folks to muster resources in time to meet the gold standard, which would not be an issue if they had the authority to muster those resources. The advantage is to the smaller company, unless action is taken to bring authority for response development up to a higher level, and push accountability down.
Third, don’t let the vulnerability researcher drive your process, and don’t try to manage him/her. I’m not saying minimize the researcher, because we have voices, but response is YOUR process. The researcher is not the problem, the vulnerability is the problem, so address the vulnerability. If your focus is to completely address the vulnerability, and not how the researcher responds to your response, you’ll do better than if you try to minimize your effort by divining how the researcher might react. Neither Schneider nor SEL attempted to manage me during this process, which I’m quite happy about (I really didn’t have much time to get managed that week).
Lastly, notification of users is a necessary step. Vulnerabilities in products are a vendor’s responsibility to recognize, triage, and fix, but the customer has a responsibility as well. Notification, with a discussion of the risk and possible mitigation measures, allows customers to identify vulnerable systems, and ensure they are protected. The need for notification to be prompt must be weighed against the need for accuracy as well. We’ve seen the reports where a fix turns out to not be a fix, which just increases effort over the entire process. Fundamentally, a vulnerability is a newly recognized defect. How do you normally let customers know of defects, and are you using that process for cyber security notification? SEL showed exactly how they were going to alert their users, but no such luck on the Schneider response.
Vulnerabilities happen, just don’t let them stink up the house. As always, questions, comments, and criticisms welcome below!
title image by Spigoo
Update: Removed the Vendor Responses, which were not professional for me to post. MT