Introducing the Orion Platform 2020.2.6 Service Release

Our latest service release is the third release this year, and like the previous two, it focuses on hardening and improving the resilience of the Orion® Platform.

Our work so far this year has been a product of our Secure by Design program, crafted to address the emerging threat landscape.

2020.2.4 was released in January 2021, and together with the new digital code-signing certificate provided all necessary security fixes for SUPERNOVA and SUNBURST, originally released in 2020.2.1 HF 2 (released December 15, 2020). 

2020.2.5 followed in March 2021 and included a cumulative set of security improvements for the platform and for individual products, as well as some dashboarding improvements.

This current 2020.2.6 service release includes fixes for CVEs listed for the platform and for specific products in the Release Notes. There’s also broad hardening work designed to improve the resilience of your Orion Platform deployment and to help keep you and your data safe.

Collectively, these three releases prioritized security and hardening, and reflect the investment we’re making in evolving towards a Secure by Design culture.

 Hardening Work

In addition to the changes in the product build process outlined on the Secure by Design resources page, the software development teams have focused in multiple areas of the product to proactively harden the Orion Platform. Some of those areas include:

User Authorization

We improved the internal handling of user credentials and certificates, and the operations users are authorized to perform based upon their role or identity. The scope of our work covers the Orion Platform and multiple Orion Platform product modules and helps to correctly limit views of management data to individuals authorized to access it.

Improving our handling of authorization helps give customers the confidence to surface the right data to the right user, and manage risks associated with credential provisioning.

Cross-Site Scripting

Cross-site scripting (XSS) attacks the integrity of a user’s connection with the Orion Platform and can result in the injection of malicious code designed to execute on either the client browser, or on the server. We addressed the specific mechanisms designed to mitigate the risks of XSS, spanning the Orion Platform, and multiple of its modules.

Focusing on improvements to help secure the user’s connection is designed to provide the confidence to distribute information appropriately to users across the company.

Data Validation

Our data validation work focused in several areas. We addressed improvements in how data inputs are handled to ensure their integrity, and to maintain their integrity as they are stored or retrieved from the database. We also focused on improving protections for the integrity of data from malicious or inadvertent injection attacks on the database.

Improving data validation helps administrators to be confident that the data stored in the system is accurate and helps reduce the risks of data corruption – malicious or inadvertent.

Secure Data in Motion

Securing data in motion can include communications over the network and communications between processes on a server. We focused on improving the security of data communicated internally, or externally from the Orion Platform.

Securing data in motion supports data validation by reducing the risks of data leakage or tampering as processes share data.

Third-Party Packages

Third-party code packages are used for some standard, commodity functions to help improve the efficiency and consistency of common operations needed in multiple areas of our code. Our focus in this area was to examine and mitigate potential issues.

Examining these third-party packages and mitigating issues as identified helps gives our user confidence we’ve made appropriate use of shared, common functions we closely audit for secure implementation.

API Hardening

Application Programming Interfaces (APIs) provide controlled programmatic access to data, and they require authentication and authorization to provide access. We’ve added resiliency and enforced strict controls on both internal APIs and those exposed externally for integration.

By hardening these interfaces, we can continue to confidently expose them—and expand their functionality to support flexible integrations—while constantly working to make them even more resilient.

Denial of Service Hardening

A denial-of-service attack compromises the ability of a tool to properly function, and to respond to the user. Here, our hardening efforts also focused on resiliency and improving the Orion Platform’s responsiveness under this type of attack.

By supporting the overall resilience of the Orion Platform, we help mitigate the impact of these types of direct attacks.

 

Summary

With the delivery of these three service releases, you can expect to see CVEs called out explicitly in our release notes, and we’ll continue to identify opportunities to improve security and harden the product.

You can also expect us to update our “What We’re Working On” roadmap postings with information about new product features in progress. We’ll shift towards balancing the delivery of new product features within the framework of our Secure by Design process and continue to deliver security improvements in our ongoing releases.

The Server & Application Monitor and Virtualization Manager products are both releasing new features; follow the links to learn more about those. The Orion Platform also includes some improvements that benefit all Orion Platform users—check those out at the links above.

 As usual, this service release is available immediately in your Customer Portal.

You can review the release notes through the Customer Portal or navigate from the Orion Platform Release Summary.

Anonymous

Top Comments

Parents
  • So, after upgrading I have several people in a Windows group being unable to login now. They are getting "Windows Account Not Authorized". Anyone else seen this, anyone know how to fix it?

  • Sadly, yes. Most of our staff is unable to login, since only a very small number of accounts are local and AD groups no longer work. I tried adding a few users with local accounts, but that failed initially, since there is a db entry for users that authenticated before and adding those results in a failure to change the account type. We used different accounts to work around that issue, but this is only a short term solution for a small amount of users.

  • BTW, you can go in the DB and delete the related rows so you can create the single users. I'm waiting for an AE to review my logs and hopefully fix the problem, but if that doesn't happen soon I am gonna have to bandaid this. I plan to export the 'Accounts' table and convert all the Windows Group users to single users. It will be huge pain to cleanup later and any new users will require account creation but nothing else I can do.

  • Support resolved my issue by having us enable LDAP via the Advanced Active Directory Setting. Not sure if that will help you but I thought I pass it along.

  • So, auth via MSAPI is broke or not supported anymore? Thanks for sharing this, I lost at least half a day on this issue...

    My concern about this "fix" is that the Advanced AD supports only one server. MSAPI typically uses whichever AD in the domain that answers... : could you confirm?

  • Once I looked into the db, I saw that all the accounts are essentially cached there. I testet by removing one and can confirm that you can add local users afterwards. I believe it might be possible to just change the account type to "convert" them to individual/local accounts, but I didn't try that.

  • Same here. It seems there were some security issues with the way group resolving worked when using msapi. To mitigate that, groups are no longer resolved when using msapi, which leads to the mentioned issue. 

    I can't be sure if this is a permanent thing, but at least it sounded like ldap is the way to go. This worked for us, but buyer beware: at the moment you can add only one ldap(s) endpoint to connect to. So if you have more than one dc/ldap server and plan to reboot, you should probably change the setting in solarwinds first, to make use of a different server and spare you some downtime while patching the dc.

Comment
  • Same here. It seems there were some security issues with the way group resolving worked when using msapi. To mitigate that, groups are no longer resolved when using msapi, which leads to the mentioned issue. 

    I can't be sure if this is a permanent thing, but at least it sounded like ldap is the way to go. This worked for us, but buyer beware: at the moment you can add only one ldap(s) endpoint to connect to. So if you have more than one dc/ldap server and plan to reboot, you should probably change the setting in solarwinds first, to make use of a different server and spare you some downtime while patching the dc.

Children
No Data
Unfiltered HTML