Voice of the DBA

Tag: security

  • Attacks Using Attacks

    Not too long ago I wrote about a security failure from an AI company, Evisort, that had a development database exposed on the Internet. There were reports of customer information being exposed and initially it appeared the Evisort was being negligent by putting an  ElasticSearch database with no password on the Internet. They were, but this might not have been a problem for customers.

    In an update, Evisorts dispute any customer data was exposed and they’ve updated security. They’ve hired consultants to help them and they are investigating and reviewing all documents that were exposed. They’ve offered to talk with any customers, and it appears they are taking this event seriously.

    So, was there really a breach? I don’t know. I have no firsthand knowledge of the actual data, and I haven’t seen anything that indicates Evisort is covering up data loss. Perhaps they are, but perhaps someone was just seeking to imply there was a breach. Doing so is an attack on Evisort, not with data, but with information.

    This might have been sent to a reporter to cause Evisort issues. Perhaps the issue was publicized to win a deal for a competitor that was near completion by making Evisort appear negligent. Perhaps this was an attempt to prevent Evisort from getting any more funding or reduce the value of the company.

    There are all sorts of attacks that occur on companies. Some of these are to get data to sell. Some might be to create bad press. Some might be to influence the value of the company or perhaps cost them customers. The attacks are often aimed to accomplish some secondary goal: reduce share price, interrupt funding, influence customers to stop doing business, or even to make competitors look more valuable or desirable.

    These are attacks on a company using some sort of other attack, like a hack of some sort.

    The world is becoming more and more scary for data professionals. We have to be increasingly diligent, and not only be able to protect data, but prove we are protecting it. With the swift and strong reaction of many in social media, it behooves us to take extra precautions and ensure we have evidence of our taking precautions ready to dispute any misleading account. More importantly, we ought to know how to react if we do actually lose data. Think about this ahead of time, as you might not have time to so once an event actually occurs.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • The Problem with Users

    I think Troy Hunt is an incredible thinker. His view and work to improve security in infrastructure and applications is incredible and valuable. I think the focus on better passwords and the implications of data breaches has grown in the world, perhaps due to Troy’s work with https://haveibeenpwned.com/. Plenty of non technical people know about the site, and more than a few government officials.

    Recently I read a piece from Mr. Hunt on passwords and why they will continue to exist for some time. I agree that the understanding and convenience of passwords makes them a tool that will remain widely deployed for some time. I like the additional verification from Google and other sites with a text or message on a phone for MFA (multi-factor authentication), and would love to see that in SQL Server, but this doesn’t eliminate the need for passwords. It just adds to them.

    The idea of password has a parallel in database development as well. One of the most basic things that we do as data professionals is fix problems on our systems. We do this in various ways, but I’d bet almost every organization has an individual that has made a change in a live, production database. Why? Because it’s easy and it needs to be done sometimes to fix code, data, or something else quickly. We know it’s not ideal, but it works.

    I try to talk about compliant Database DevOps, about having a process, the need for evaluating code and data changes, about limiting access to production, about ensuring every statement is tested elsewhere, about even masking/anonymizing/generating data in dev/test environments. Most of us know these are good ideas, and likely quite a few of us would like to adopt them. Why don’t we? Part of it is the ease with which we get things done. Another part is the success that we have with our current process.

    We fix things, we add indexes, we correct typos in code, we adjust our deployment to succeed, even though the scripts had problems. We roll forward constantly, coding by the seat of our pants, and for the most part our organizations continue to function well. Brent Ozar’s recent survey on production data in development shows that in some cases there isn’t a security risk, but quite a few times expediency and troubleshooting mean we work in production or copy data.

    I still think DevOps is the better way to move development forward. At Redgate, we have a suite of tools that help you smooth database development to reduce mistakes and problems. Not because you can’t be successful the way you are, but because you can go faster, make more experiments and changes, and deploy on demand rather than as a special event. We help you save time, which should translate into your highly paid staff spending time on creative new solutions, not fixing tedious problems. We even expect you’ll do things in production, which is why DLM Dashboard was built.

    We’re not the only vendor doing this. Plenty of others are trying to help you build a smoother database DevOps process, including Microsoft. Most expert software developers know that DevOps is a better way to build software that focuses and takes advantage of the creativity of your developers, while reducing the time spent on non-creative work. I, and many others, feel that the database needs to be a part of this to be as successful as we can be.

  • Ransomware and DevOps

    Ransomware.

    A scary topic and one attack that is apparently more common than I suspected. Before you go further, if you haven’t restored a database backup in the last month, stop and go verify your DR plan works. That’s one of the overconfident issues facing lots of government and businesses. While this might not help your entire organization, at least you’ll have some confidence in your process and that you can recover a database.

    This is a great article from Ars Technica and worth reading: A take of two cities: Why ransomware will just get worse. I’d recommend you read it and think about a few things. First, do you have insurance because things (or substitute your own word here) happen? Second, have you really tested a DR plan for some sort of software issue like this? You might think about a way to restore systems in an air-gapped manner that prevents them from re-triggering encryption from a remote source, or maybe even in a scenario where you reset dates/times to prevent timer triggered issues. If you don’t think you need to, read this article as well.

    Perhaps the bigger issue is are you actually patching and updating systems? Too many organizations can’t, don’t, or won’t. The former means you aren’t sourcing software properly. Either you’re using vendors with poor practices or have a poor development process. Organizations that don’t or won’t bother prioritizing patching, especially security issues, are likely those that will have issues as more criminals spread and use ransomware and other attacks for profit. Software and environments continue to be more complex, which means that the less you ensure the system is patched, the more likelihood there is of a vulnerability in your environment.

    DevOps and the cloud PaaS/SaaS platforms are attractive for a few reasons. One is that the platforms are constantly kept up to date, forcing you to move along with them. SaaS cloud vendors know this and are constantly patching and updating their software in order to keep it running. DevOps asks that we always have the ability to release, that we have the ability to patch on demand, not only at certain intervals. This is something I try to emphasize when talking about DevOps. It isn’t necessarily about velocity, but it is about being able to release when you need to, whether that’s today or next month. This is especially important for security issues.

    I have had hope for a long time that insurance would drive software to higher quality, and I still do. With the attacks and issues of ransomware, and who knows what other techniques that will be developed, I still believe more companies will buy insurance. I then hope, because of selfish motives, the insurance companies will require frequent patching, regular vendor certification of new platform versions, and better development processes. If insurance drives DevOps, I’m all for it, but I’d prefer you decide to adopt it yourself and start making changes today.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • The Road to Better Data Handling

    Recently I was on an internal communication thread with multiple people at Redgate Software. We have various ways to keep our (semi-) distributed teams in touch with one another and handle issues. While email works, I think many people like Slack better for quick discussions. I appreciate that as a remote worker since I’m not around to hear a conversation around a desk. To be fair, with a busy staff, others often aren’t as well, so a thread in Slack often saves details others can see later.

    In any case, we had some issue. I don’t know if this was a product issue with a customer or a communication item for our marketing group. No matter what it was, we had someone mention they could help if the first poster would provide details. The next message that I saw was great. It said something along the lines of

    “Please do not post email details in Slack.”

    A gentle reminder, but one that was needed. It’s great that we want to help others and work through problems, but in many companies we’ve played far too fast and loose with data. Not necessarily technical people, but often our customers have. Many of them will put sensitive information in “notes” fields in our databases. It’s a hassle when we want to work with data that hasn’t been put in a normalized space and must extract it somehow.

    It’s also a source of data leakage. While we might appreciate saving a quick note, these aren’t secured communications, and more importantly, they provide yet another attack vector for problems if we lost control of the backups, archives, etc. Even worse, we could have gotten a request to remove emails and we now have another security risk with the email email searchable in old Slack messages.

    This is likely a bit of an extreme example, but still a place where data handling should be better. We have secure systems for tickets or issues where we can store data. Or we can reference their information in another way. I’ve started doing this in GitHub, where we often log issues for SQLServerCentral users. Rather than putting in an email, I’ll put a user ID or other identifier. If the user wants to delete their account, I don’t want their email floating around anywhere it isn’t required.

    While it might be a bit more hassle to be careful with personal information, I think it’s much better than treating it as unimportant and potentially having it disclosed in some security incident. Whether it’s my email, tax ID number, or credit card, I’d want my own data handled carefully and am trying to do the same for others.

    Steve Jones

    Listen to the podcast at Libsyn