Optimize and transform your business today
Challenges, Opportunities and Strategies for Integrating IIoT
We're reconstructing the ways you can get things done with OSIsoft.
OSIsoft Brings PI System to Amazon Web Services
What We Do
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
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?
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
How does OSIsoft respond differently to different types of vulnerabilities?
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)