Those my friends are, in my opinion, one of the single most wonderful things on earth, white chocolate macadamia nut cookies.
Now, you may not like those. So, picture your own, special, favorite indulgence. Not a common indulgence either. Something truly lovely and special. Something important to you.
Got it?
Good. Now, I want you to equate that indulgence, whatever it might be, with the fundamental security of your systems.
Let’s imagine for just a moment, that you’re developing a new system using the ElasticSearch database, one of the most popular data management systems on the planet right now. Did you know, by default, the basic and trial versions of ElasticSearch have security disabled? So, probably, if you’re in development, you started with a trial version. If you just moved that straight to production, as tons and tons of people do, I’ll bet you, you still don’t have security enabled. Don’t believe me?
Talk to BestWestern and AutoClerk
Do some web searches. There are so many breaches in and around ElasticSearch databases that have been exposed, without security, or with passwords that read “changeme”, it’s almost hilarious.
I don’t mean to pick on ElasticSearch here. There are all sorts of easily prevented data breaches. In fact, most data breaches don’t involve elaborate hacks using massively parallel video cards or raspberry pi. Nope, most of them are badly secured servers, inappropriate or missing passwords, fundamentals.
I’m begging you. Get the word out. Security is like a macadamia nut cookie. It’s a good thing. It’s on you because you’ve read this post. You now know. Go. Talk to the dev team. Talk to your admins. Talk to your managers. Implement changes. Get these systems locked down.
I’ve told the story before, but during the first DotCom boom, my employer was looking to acquire another company. I was asked to do some due diligence. I gave up after 15 minutes. And I only took that look because I had to look up syntax for something.
Basically I pinged their website. Got the IP.
Then tried to connect to SQL Server on that IP and one above and one below. SSMS (was it SSMS back then?) couldn’t, but the command line (was it SQLCMD back then) could. Back then SQL Server did not require a password. So, I tried the sa account without a password and I was in. And of course back then xp_cmdshell was enabled by default. I could have within 30 seconds made a local admin account and owned their box.
I recommended IF we bought them, we basically rebuild their systems from scratch because we had no way of knowing if they had already been compromised. We didn’t buy them. All because of the lack of a password.