The recent hacks via SolarWinds’ Orion Network Management Software(NMS), was the result of a Supply Chain hack. Companies were “hacked” because their NMS supplier was hacked. The hack on that supplier (SolarWinds), altered the files that customers (users of the NMS) would use to update their systems.
The update’s files were not altered - their certificates were valid. But rather some of the source files used to build those updates.
This brings me to the question of a software supplier’s responsibilities. Not in just what they supply, but what they recommend from third party sites.
I just watched the Epicor Webinar on Technical Tips and Tricks. One part was on SQL maintenance, and referenced Epicor’s KB0075000 (" SQL ADMIN - index maintenance best practices for Epicor ERP"), which includes links to a SQL script to download. The KB then instructs you to run the script on your DB. The links to the script (there are two, each with a different URL), are both external to Epicor.
The first link just references a filename - maintenancesolution.sql. which when clicked tries to open http://maintenancesolution.sql/. Which results in Website not found, Server IP address not found. Currently, a domain name can not end with .sql. But if it could, someone could get that domain name and the switch the SQL script with one of their own.
The second link - https://ola.hallengren.com/scripts/MaintenanceSolution.sql is a direct download. Doesn’t take you to that websites page for you to do any verification of who you’re downloading from. Even if you did get sent to a landing page, who knows what is in that script.
Epicor really should have a copy on their website, that they control, to make sure it hasn’t been altered in anyway. Instead the KB says to go get this file from some other website, and blindly run it on your SQL server. I understand that they want to provide the original author with the credit, but hot linking to another website seems awfully risky. Especially when the link is for code(the SQL script) to be run at an elevated level on a critical system (your SQL instance).
I thought you were watching the Webex that was on Tuesday about Performance Tuning and stuff which was presented by everyone but John Friend… so I left 10 minutes in.
I was. And in that webex they said to go to the KB article.
That Webex was crap. It touched on (and saying “touched on” is being very generous) DB maintenance and the Performance Tool. Basically could have a slide like:
SQL DB Maintenance
It’s a good thing to do
there’s info on the net about it
Performance Tool
It can do a lot
You should run it.
Neither went into how to actually do those things with any great detail.
That would pose two issues for Epicor. They would be providing the file so if there is something wrong with it they are more liable than just recommending you download and run it. Second if Ola updates their scripts how is Epicor to know and manage the.
PS we use the Ola scripts and have since 2013 love them. That was an Nathan special
I’ll throw my lawyer hat on here and say that the KB is not a “recommendation”, but rather instructions for maintaining their product’s performance.
And as for Epicor managing changes by Ola, this is the very point. If Ola changes the script, Epicor should review the changes before blindly telling it’s users to blindly use them. What if a bad actor changes the files on Ola’s server?
My main point is that there are ways in which software suppliers - whether commercial products like Orion, or freeware like Ola provides - are part of your overall security analysis.
I don’t think Epicor should have to do anything with it. There are dozens of ways to handle what the Ola scripts do and each company should be responsible for their own DBA and what they put on their systems.
They are trying to be helpful in that KB for folks that aren’t DBAs Ola makes it easy. For larger companies I would argue it’s a horrible solution, for smaller a great one, but it is a solution regardless of efficacy.
Jose yelled at me once and said keep it pro bro! 
