Voice of the DBA

Tag: security

  • Beware, More Ransomware is Coming

    Criminals seem to take advantage of anything that will allow them to gain more money, power, or notoriety. It seems in the last year that ransomware has become more prevalent and widespread in all sorts of organizations, though a number of governments have had high profile attacks. They’ve often paid the ransom, with the help of insurers.

    While that might seem like the most expedient way to get back to working, it can be a problem, as this article points out. It can often be more expensive, in time and currency, to combat an attack than to pay a deductable and have the insurer cover the rest. When insurers start to pay for the attacks, then it provides an incentive for more attacks, especially similar attacks at governments or other corporate divisions where the security (or lack thereof) might be similar.

    This also can influence more organizations to purchase insurance, which might be part of the reason insurance companies are happy to pay out the policy. I expect that insurers can’t pay all policies, so I would hope they would start to require more proactive security measures and policies to prevent attacks against some companies. In fact, I hold out hope that insurance, not government, will drive more companies and organizations to implement better security practices.

    The downside is that sometimes paying the ransom doesn’t get the keys to decrypt files. In fact, I suspect that it’s as likely that the criminals don’t have the key as they just make a mistake in their “customer service” effort to provide the key. All sorts of organizations have trouble providing the right keys at times to customers, so I’d expect this happens to criminals as well. I also wouldn’t be surprised if some criminals aim to exact a second ransom, perhaps devised to be just below the insurance policy limit, before providing a key.

    The takeaway for most data professionals here is that we want to be very careful with our data, especially our backups. While others might lose their data to encryption, it behooves us to severely limit access to backup files to prevent a rogue account accessing them, and certainly we would want to to air gap backups wherever possible. If we find out that systems are encrypted, at least we can recover our data on new hardware. If our application code is likewise held in another system, like GitHub or BitBucket, then we might even get back to work quicker, at least for our data-driven applications.

    Security continues to be an increasing part of the data professionals job. As a way to ensure your career continues to advance and grow, pay attention to how well you secure your organization’s data.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Grounded

    Technology has brought some challenges to travel. There is the bomb threat, of which I have no way to gauge how much of a potential problem this is on a daily basis. Certainly security at airports has changed over the years, and there is better scanning technology, but would anyone really be able to detect a bomb in a bag? Do we check all bags? I doubt anyone does, but perhaps I’m wrong. Either way, I hope this isn’t anything I need to worry about in my travels.

    I do carry electronics, usually a laptop, though sometimes two, along with the various supporting plugs and wires for charging it and my mobile. There was a time when I thought about getting a BRIX for demos, but with the requirements that security might make me turn it on, I decided not to get one. These days, with all the cloud options, I’m less worried about carrying a large amount of hardware, but I still need a laptop. When I saw a story about laptops being banned from flights, I wondered what I’d do.

    In this case, Macbooks are supposedly being banned if they have a certain battery issue. This came about quickly, and it’s likely that there were some business people in the middle of a trip when the ban was announced. That might have prevented them from flying, which would be quite a hassle. I remember when the Note was banned from some flights. I never met anyone that was inconvenienced, and likely plenty of people flew with their devices hidden in bags, so perhaps it wasn’t a big deal.

    I wonder about two things here. One, are we building new devices and technology that aren’t designed well from a safety standpoint? Most of us don’t have large servers in our offices anymore, so we might not care, but our other devices, which we use to get work done, perhaps might not be robust. In that case, I hope that businesses might have programs to help employees quickly replace devices if there are issues. Being on call and not having a device would be a nightmare.

    The other item is one I wonder about both for software and hardware. Do we make it easy enough to know what version of a device we have? I’ve owned Macbooks, and trying to determine what model you have is a chore. I can’t imagine that TSA or other security agencies could actually a) determine if you had a banned device, and b) know if you’ve had it repaired.

    I’d hate to think that companies will just build devices without making it easy to understand which generation of a device you own. This can already be a problem in not only computers, but other products like autos, where changes might be implemented in the middle of a model year. With the move to cloud and other rented software, are we going to have issues here? Azure SQL Database hasn’t changed the version in some time, despite there being changes to the code.

    Maybe it doesn’t matter, especially if old features don’t disappear. It does seem like something that we ought to do a better job of tracking, especially as it can be easy for us to have a model, but tag on a version number to easily allow a user to discern one from the other.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Protecting Code

    There are so many data breaches taking place, that it’s hard to keep track of them. While I rarely find my email in any of the breaches loaded into haveibeenpwned.com, I do see Mr. Hunt regularly loading more data sets into the database. I don’t know how many you’ve been a part of, but I certainly hope you know, and I hope you’ve changed shared passwords and updated accounts.

    While we do need to protect data, we also need to ensure that we protect our code, as that might be where the vulnerabilities lie that others might discover. While I’m not a big fan of encrypting or hiding the code in a database from customers, I certainly don’t want that code, or the application code, to be visible to outsiders, especially potential hackers.

    While your team might not be are careless as the Boeing research team, I’d hope that you don’t expose your code on the Internet, as they did. Perhaps more importantly, I hope no one does a Black Hat talk about potential issues in your code. A researcher did this to Boeing, talking about potentially being able to jump from a customer network and application to a more privileged one to the command and control network. Boeing denies this is possible, and I’m not worried about my future Dreamliner flights, but I think Boeing should do more publicly here. Let the researcher have a few days on a plane and truly pen test the software.

    I’ve seen lots of “hidden” features in software that administrators use to get work done. I’ve seen sloppily written tooling that solves a problem and isn’t intended for general use. I’ve also see far too many of these features “discovered” by ordinary users. Even assuming your internal network is completely free of malicious users is a bad idea. We’ve seen plenty of viruses and trojan software that can be used maliciously.

    We don’t want to lock our networks and applications so tightly that we create impediments to work, but we certainly can do better jobs in limiting access, keeping tight privileges, ensuring administrative accounts are protected and more. Those might be hard to get done today, but you certainly can prevent simple things, like securing your VCS. Don’t use public places like GitHub, or ensure you have private repositories that only your organization can see. It’s not perfect, but it does stop the researchers and lazy criminals that are just scanning for easy targets on the Internet.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Don’t Get On This Page

    The GDPR has been in effect for over a year. While the press has died down a little, outside of a few record fines, there is still plenty of activity. At Redgate, we have customers that still worry about compliance and are doing their best to ensure they properly handle and secure data. It’s a tough job, but one that many organizations need to continue to focus on.

    And there’s a good reason. Who among you would want their boss to come talk to them about mishandling data? Who wants their boss to come after reading this page, with your organization and fine listed? I’m guessing most of us would prefer to not be on that page, or at least not want our boss to know.

    There have been a lot of fines handed out, though most are relatively small. Still, every amount spent towards a fine is money that could be used for shareholders, investment, or even better security and systems to prevent future issues.

    What’s interesting is that many of these fines aren’t for data breaches, but rather for other issues. There are some security issues (unauthorized access), and some inappropriate storage. There are also quite a few consent fines, where data is used without the appropriate permissions from the data subjects.

    I find the list interesting, and I hope this is the type of thing that does drive change in organizations. Many of these fines might easily be eliminated with a few process and procedure changes and adding some security to prevent unauthorized access. While some companies might be willing to pay fines, I expect that subsequent amounts will rise, and it behooves organizations to change both their behavioral and technical practices.

    This might be building archival processes, which would be one of the few ways that might reduce the amount of data that we need to manage and query. Hopefully, something that might improve performance for your clients.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.