Reading about how hackers are using SQL Server instances that are exposed on the internet AND have weak passwords to work into systems, I’m sitting here wondering why.
I get it. A pretty hefty majority of these were simply set up by people who didn’t know any better. Computers and databases are now so wonderfully easy, almost anyone can slap together a database server, and do. Simple ignorance leads them to misconfigure the systems and leave them exposed. So, while it’s hard to forgive this ignorance, it’s easy to understand.
I sincerely doubt we’ll ever be able to do much about it. I suppose if systems were designed to be secure from the moment of installation, that would help. Stuff like ElasticSearch having it’s development servers have zero security out of the box in order to ease development doesn’t help. Just the simple change that Microsoft made back in the day, actually requiring a password, any password, on install improved security. More can be done.
What About the Rest of You?
So, yes, ignorance plays a factor. Better security from the vendors would be a huge help (and by the way, here’s where the cloud can be awesome because, depending on the system, they are more secure out of the box). However, you know better and yet you have systems that are unsecure.
You know you do. You have a single login for all administration across the entire organization. You have simple passwords. You have SQL Injection vulnerabilities. You have unpatched servers or even servers that are long out of support. You have all these problems, and more, that you know about and yet you’re not fixing them.
I want to know why.
Please note, I’m not saying it’s your fault. I’m assuming outside issues. I’m simply curious what they are.
How and why is the organization preventing you from doing what you know is right?
Further, is there a way to turn this around?
I don’t have an answer for your today. Only questions. Please, respond in the comments. I’d love to hear what you have to say on this.
Application user account that is a db owner. This provides a path for the user account to be escalated to sa. Should someone find a sql injection vulnerability, this makes the difference between a single database being compromised and the whole server being compromised. None of the developers know why it “needs” db owner, but they will not allow this to be changed.
But why not? Again, not being critical here in any way. I’m just trying to understand what motivates people to stop the improvements.
The fear of breaking something. My argument is to test to verify that nothing has been broke. But, then the response is that they do not have a way to test everything to be completely confident that it will not break anything.
Darn. That’s going to be tough to introduce any kind of change, let alone important ones. Good luck!
Grant, Our servers were hit by the RYUK ransomware on Thanksgiving day 2018. The only reason we’re still in business is because I had instituted separate service accounts for the various SQL services. They had tried to shut down the SQL service but couldn’t, so our MDF, LDF files weren’t encrypted. We did not pay the ransom and spent the next 36 hours rebuilding all our servers from the ground up. We learned alot from that experience which helped us re-secure our environment. We now have Carbon Black continuously scanning for intrusions, which is a hassle but necessary. One of the things our security expert told me was that they had a list of file extensions that the RYUK virus was looking for to encrypt. .MDF & .LDF were in that list. As a consequence, I’ve renamed our database file extensions to .PZM, .PZL, .PZK & .PZT. SQL doesn’t care about the extension, only about the file header.
Wow! Sounds like you’re largely doing things right. This stuff is hard. And for fun, I like to create a database with a .DOC extension for newbies.