Introduction
The Security Development Lifecycle at OSIsoft results in more secure code with fewer vulnerabilities. However, software without a single potential vulnerability or security hole does not exist in the real world. Inevitably, new vulnerabilities affecting OSIsoft products will appear over time. Preparing a response process is essential in any plan of action prior to customers being affected. OSIsoft’s policy on ethical disclosure is a foundation of core values to guide this response process.
What is ethical disclosure?
Vulnerability disclosure is the practice of publishing information related to a security vulnerability found in software. The purpose for such a disclosure is to inform the customer of the potential risks, so that they can take actions to minimize the effects of the vulnerability.
The question of whether or not to disclose a newly-found vulnerability is one of the most sensitive decisions a software provider can make. As a trusted provider, we want to inform customers of issues that could impact their operations. However, releasing too much information about a vulnerability too quickly could potentially result in an intruder using it to gain an upper hand against customers. This policy and the
values outlined in the policy documents how OSIsoft balances these two extremes.
Goals for ethical disclosures
1. Communicate in a predictable manner to customers
OSIsoft strives to publish regular security bulletins in coordination with Microsoft Patch Tuesday (usually the 2nd Tuesday of each month). Releasing security bulletins on a regular schedule minimizes the need for the customer to constantly monitor for security issues on OSIsoft product deployment. The customer knows when to check for updated information about possible vulnerabilities, allowing the customer to plan for such updates at their convenience. The bulletin schedule and release cycle coordinated approach provides a natural planning window for a security bulletin and release of product security updates.
2. Empower our customers, not would-be attackers
Security bulletins and associated product documentation will provide information useful for managing cyber risk while avoiding sensitive details potentially useful to attackers. In practice, this is more difficult than it sounds. Oftentimes, those unfamiliar with cyber security intrusion methods cannot easily identify when too much information has been provided. OSIsoft strives to carefully research and evaluate each vulnerability against potential risk to make a determination about reporting to the public. When in doubt, we have, and will continue to, seek professional review by industry security experts.
3. Explain what is happening
Security bulletins are a result of much research and careful evaluation to explain each security vulnerability as accurately as possible with the existing information at that time. In essence, how bad is it? How will the customer reading the bulletin know if they are affected? What can the reader do to protect their deployment? Situational awareness is taken into account, including: information about how the issue was discovered, whether a fix or workaround is available, and the level of exploit activity (when applicable). Such context helps customers assess urgency and develop an action plan. This is the basic goal of each bulletin: to equip and empower the user. Most security updates are handled by our customers as regularly scheduled work items; however, OSIsoft will strive to communicate its informed option on the particular urgency of any given security issue.
4. Communicate what is important
Not all products are as ubiquitous as others. While information about vulnerabilities in widely-used PI System components will be handled with more importance; severity, active exploitation, or requests by regulators are factors that increase the importance of a security bulletin, regardless of the relative use of the OSIsoft Product(s) affected. Our preference for formal vulnerability disclosure to the security community includes professional coordination by The US Department of
Homeland Security – Cybersecurity and Infrastructure Security Agency (CISA). Public media and the trade press are inappropriate forums for vulnerability disclosure.
Core values regarding disclosure of vulnerabilities
- OSIsoft commits, first and foremost, to doing no harm when it comes to the disclosure of security vulnerabilities. The primary consideration for each published security bulletin is whether releasing it has a realistic possibility of inadvertently harming our customers. A YES answer runs counter to our core values and we do not report the vulnerability in its current state. This tenet shows our commitment of making all decisions in cyber security matters with our relationship with each customer in mind.
- We strive to empower our customers with timely and actionable information with the goal of helping them make informed decisions regarding security around their implementation of our software. One path to this is informing customers about security vulnerabilities, including how regular software updates can address those vulnerabilities. As is the case in health and medicine, preventative maintenance through applying regular updates is often more effective and less resource intensive than fixes and workarounds.
- Security is based upon trust. Customers need open and transparent information about security around OSIsoft products to better protect themselves, and OSIsoft is committed to providing the appropriate information to maintain such trust.
Philosophy on self-reporting vulnerabilities
OSIsoft takes pride in being a leader when it comes to self-reporting internally discovered security vulnerabilities to CISA, the customer base, and to the public. Each vulnerability goes through a thorough process to determine whether to disclose publicly. One of the most important factors for disclosure is the Common Vulnerability Score (CVSS), which gives an idea of the severity and potential harm. These scores are used to categorize vulnerabilities into Low, Medium, High and
Critical categories as a metric to use in evaluating each and every disclosure. Another is the impact to our customers, determined by careful analysis and research to understand the context and appropriateness of a disclosure in the overall scheme of the product deployment.
Why do we self-report vulnerabilities?
- To put the focus on the customer. Our primary goal is to secure our customers’ implementation of our software.
- To make it easier for our customers to find all vulnerability information in one location, CISA, on a regular schedule.
When warranted by analysis, we will report our vulnerabilities to CISA typically sixty days after a software update addresses the issues. This reinforces our primary goal: first and foremost, do no harm when it comes to disclosure of vulnerabilities.
Corporate policy on ethical disclosure
This policy applies to software code vulnerabilities in
general accordance with ISO/IEC 29147 standards and the domain specific Common
Industrial Control System Vulnerability Disclosure Framework developed by the
US Department of Homeland Security Industrial Control Systems Joint Working
Group.
- OSIsoft will only disclose a vulnerability when the disclosure includes actionable information such as a way to fix or remediate the issue.
- OSIsoft will never disclose any details of the vulnerability that could lead to the development of an exploit of the vulnerability.
- Disclosure of vulnerabilities are released as Security Bulletins, Release Notes, Tech Support Notes, Knowledge Base Articles, and Advisories through the Support Website.
How does OSIsoft respond differently to different types of vulnerabilities?
An Incident Response Plan process is activated to evaluate the vulnerability and determine if it meets the most basic criteria for an escalated response. An incident commander is assigned to coordinate response activities including escalation to executive leadership for critical issues affecting released products.
OSIsoft then takes three different approaches responding to a vulnerability, depending on who found it, how severe the potential exploit may be, and other compounding factors. The list of approaches differ in communication methodology, as follows:
1. OSIsoft internally discovers a vulnerability in the PI System
The remediation plan is generated including security bulletins for high and medium level issues. Availability of actionable information such as general release of a product update or avoidance procedure shall be communicated. Advance notice is provided to customer and partner channel stakeholders followed by general availability and coordinated disclosure with CISA (or equivalent public service) when OSIsoft decides that a wider audience is warranted after careful analysis.
2. Third-party discovers a vulnerability in the PI System
OSIsoft encourages vulnerability reports from third parties and strives to maintain regular communication with the third party during incident response phases including reproduction of the issue, root cause triage, impact assessment, remediation plan, and confirmation of fix as appropriate. Disclosure plans are generated in collaboration with the 3rd party. OSIsoft favors coordinated disclosure with actionable information such as general release of a product update or avoidance procedure. Acknowledgement of third party discovery is subject to consent.
3. Actively-exploited vulnerability in the PI System
OSIsoft will actively engage all partners and customers with recommended defenses, mitigations, and guidance on vulnerabilities that are already known to the public and might be open to exploitation. It is important to note that for this type of situation, OSIsoft will engage with customers immediately and will not wait to follow the regular cycle of patch or software release. Additionally, regularly scheduled software updates addressing vulnerabilities will be provided to the customer when available. Senior leadership within the company will be involved to ensure rapid and effective resolution of the vulnerability.
(Last revised March 05, 2020)