Voice of the DBA

Category: Editorial

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

  • The First Rule

    A long time ago I read a book called The First Law. It’s a legal thriller, and I’d recommend it. It has nothing much to do with databases, but I was reminded of the book and the rules of any particular process when I saw a post called The First Database Rule.

    The post is from Seth Godin, who is really a marketing individual, but I do think his rule makes a lot of sense for clients. I also think that as both developers and database professionals, we forget that most of our clients would prefer to have our systems follow this rule: it should be as simple to fix an error as it is to make one.

    I’ve worked in many systems, and with many people, that expect data entry or loads to go perfectly. They expect things to work and want to blame the process, the person, the file, or something else when something doesn’t work well. What might be worse sometimes is that we expect some data in the database to be immutable, like a PK, assuming that clients will have and enter all the correct data at once. Most of us do allow changes in our databases, but we don’t make it easy, especially if it’s a piece of data like a primary key.

    This is one reason I dislike many natural keys as PKs. We make mistakes when we enter them. Heck, I’ve probably typed my name a million times on a computer keyboard, and I still make mistakes. Even in data entry forms. What’s worse, I have some auto-fill selections in my browser that are incorrect and I’ll select the wrong one at times.

    Fixing mistakes ought to be easy. We ought to expect that we will get data wrong. We’ll load it wrong, we’ll transform it wrong, and our DBAs will type corrections wrong. Design the system to account for mistakes and ensure that problems can be quickly fixed. Whether by a client or a sysadmin.

    Agility ought not to be just how quickly we can change the software. It needs to include the ability to change the data, which is the most important part.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • IT Staffer Fired

    In the early 2000s, it seemed that many companies were hit with a rash of virus attacks on their networks. Certainly the SQL Slammer worm affected many of us, and it was a memorable week for me. I returned from vacation to get a call late on Sunday night informing me of issues. I spent a long work working with network people and Microsoft to rid our (shut down) network of the worm, a difficult process with a wide deployment of MSDE instances installed in non-standard locations.

    Not long after this, we had another virus invade our network and shut down systems. This was due to a high level manager clicking on an attachment in email, which spread issues to (far too) many others inside the company. Another long night for me patching and cleaning systems, and one where I questioned how someone could be fooled.

    In the last year, a similar rash of incidents have spread around various organizations, this time with ransomware instead of viruses. One Florida city government was hit, with an IT worker being at fault for opening a document they received in email. The result? The city paid a ransom and the employee was fired.

    Is this fair? I’ve seen the Twitter mobs and rapid comment trolls condemning and praising both sides. It appears many people rightly think someone clicking on unknown attachments should be fired, while there is no shortage of others that understand that humans get fooled and termination is too harsh.

    Personally, I don’t know what to think. While most phishing and spam is poorly written, and I often check headers and easily see these notes for what they are. I have seen some very sophisticated and incredibly deceitful emails that might fool most of us.

    If you have a privileged account, you better be really careful about opening any attachments from email. You shouldn’t download pictures by default except from whitelisted senders, and you might even want to stop doing that. Who knows if your co-worker or business partner got fooled.

    It’s disconcerting though not unexpected. Perhaps this person was at fault, perhaps it was  mistake. Being fired is never fun, and all of us should be a little worried about this if we’re not careful.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Phishing Defenses

    I wrote recently about an attack on utility companies by crafting a clever email aimed at specific engineers. That could easily happen with software developers and IT pros, which is why I think it pays to be extra cautious when dealing with any communications that come from others. Whether emails appear to be from internal or external users, phishing is a real concern for those of us that have privileged access to systems, and it should continue to be a concern for the foreseeable future.

    I ran across an article that talks about some of the defenses that you can implement. Certainly education is key as one person noted in a comment on my previous article. They said their security department sends around pictures of phishing emails. That’s a good idea, but the volume might be overwhelming in today’s heavily probed environments. I think it would be easy for me to make a mistake after seeing too many examples and when I’m expecting some communication from someone and I get a phishing email on that topic. Still, educating users with privileged accounts know this is a regular occurrence is a good idea.

    I know in larger companies, there ought to be some group that knows about phishing issues in depth and centralizes information. Having a support channel (email, Slack, whatever) for people to contact when they have questions is a great idea. I know I do sometimes contact my IT group if I’ve gotten something that seems suspicious. Letting some central group manage reports and provide information also allows that group to help keep a list of sites that should be blocked more up to date. If someone is clicking through but there are blocks to prevent access to links, or even communication from trojans, this can mitigate some of the issues.

    Perhaps the best idea, however, is to ensure that backups are taking place and restores can be performed. We know this is critical for databases, but other types of data you use might be valuable as well. While I know that my Drop Box and One Drive folders might get hit with ransomware, I also know my subscription allows me to restore older versions, which hopefully would be un-encrypted.

    Security is a constant battle, and the criminals continue to come up with new attack techniques, often with success. Ensure you remain vigilant, educated, and help others in your organization to do so as well.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.