Voice of the DBA

Tag: security

  • Losing The Security Game

    It’s sad some weeks to see reports of security issues at large companies. It’s also discouraging some times when clients or friends will talk about security issues they’ve had in their organization. What’s mostly disappointing is how easy many of these issues would have been to prevent with a little effort.

    Joey D’Antoni made some fun of this with his Data Breach Game. It’s a bingo card you can print out and use the next time you hear about an issue. My guess is most of us could win this in about a week with the general state of security in most places. Some of you might win this in a day with inside knowledge.

    This is poking a little fun at the poor security practices of many places. There’s a wider article about 9 poor security practices you can read, with some notes about what you should be doing instead. When you read it, you’ll wonder why hasn’t someone just made these simple changes and dramatically improved security? I have asked myself that many times when I’ve seen some environments.

    Ultimately, no one wants bad security, but we (as a group) often make poor choices because we’re in a hurry. We can, and should to better. All of the items on this list can be avoided, and should be. Even the complexities of SQL Injection can be fixed with a little code refactoring. No time or that’s too hard? You should be building software in a Compliant Database DevOps manner.

    I like the list, though I wish ElasticSearch where on there in number 6 with MongoDB. Too many breaches this year from people dropping that server on their network without a password because they need full text searching of data. Don’t make that mistake. Always, always, always set a password on data resources. Developer or partner complaints aren’t worth the risk of losing data from an unsecured server.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • More Network Restrictions

    This past year has seen quite a rise in ransomware attacks. Certainly some big ones (Baltimore, Florida) are reported in the media, but there are lots of smaller ones that don’t make the news. As I’ve been attending some events in the last couple months, I’ve talked to various people that disclose they’ve had ransomware issues. Most of those didn’t make the news, but the events did cause IT staffs to scramble, work long hours, and forgo other tasks that might be improving the organization or helping customers.

    We know that there will be attacks on our organizations in the future, and some of them may be successful. Almost everyone is regularly attacked, though most are repelled with simple firewalls and better coding to prevent SQL injection. There are other things we can do, and certainly other groups in IT that need to worry about systems, but I suspect we’ll start to see one more change in how we work.

    Recently I was accepted to speak at SQL Saturday Memphis and really enjoyed the trip. However, when practicing one of my demos early in the am, I had trouble connecting to some remote resources. It wasn’t obvious what the issue was, and since I wasn’t in control of the endpoint for demos, I worried that the instratructure had an issue. Not what you want to see on a Saturday before a demo.

    Eventually I narrowed this down to port 1433 being blocked. Not a big deal as I had a VPN, but certainly something to be concerned about for a database professional. However, then I thought about the ransomeware and other security issues many organizations have had. Maybe some restrictions are a good thing.

    I wrote about networking segmentation, as did Joey D’Antoni, and I think this is where we will move in the future. After the SQL Slammer worm, plenty of organizations changed networking policy to hide port UDP 1434, which was good. I think some have gotten lazy, and the security issues we are seeing today might change things.

    That’s going to mean less access for people to connect to machines. That also means we need to think about DevOps style automation pipelines for code. We need to learn more about how to let machines run scripts for us and limit access. That way if our machine is attacked, we won’t necessarily be able to spread the issues to servers. We’ll still have plenty of other machines that might get hacked, but hopefully we can protect our servers.

    Security has become a bigger part of the job for all IT pros, and certainly critical for database pros. I hope that most of you embrace more stringent security and not try to circumvent it. Use automation, proxies, and more to keep your systems secure. And if they don’t quite work as you’d want them to, learn how to adjust them and work with the system, not against it.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • 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.