Voice of the DBA

Category: Editorial

  • No-so-smart Contracts

    Perhaps the best quote I’ve seen in a long time: “These kinds of attacks are common in smart contracts because many developers do not put in the legwork to define security properties for their code…” I’m sure that this would apply to many kinds of software, not just smart contracts.

    This is from an article on a hacker that stole money by altering a smart contract. In this case, tokens used to replace parts of the contract overwrote other tokens, which allowed a smart hacker to change prices and make more money. Or steal it, with a contract change, I don’t know that theft is actually the correct term.

    The wider issue here is poor developer practices, and really, not listening to the results of security audits and making changes in code. Maybe they listened to the audits and hadn’t completed the work. There were some critical issues, and some remediation, but not enough in this case.

    Building security into software is hard. The threat landscape changes and hackers are incredibly creative. It is hard for developers to keep up, but it is important, especially where there are finances involved. There are tools to perform security assessments and automated pen-testing. Everyone ought to use these, and more importantly, management should take security more seriously. If they don’t, they deserve some sort of penalty.

    The problem for many of us is that we can raise issues, but we are powerless to do anything. We can change jobs, but that’s not practical all the time. We can continue to raise awareness, but that can be detrimental to our careers. After all, management will get tired of us repeating ourselves at some point.

    Mostly what we get to do is worry. We worry that the company will get penalized, which can affect our employment. We can worry that management will blame us for an issue they didn’t allow us to fix or give us the tools to detect. We can worry management will blame us for not knowing about an issue as well.

    I believe we ought to have more focus on security, but I’m not sure what that means or how to achieve this in a practical sense. I don’t even know how we’re set up regulations and penalties for such a complex situation.

    Mostly I’m just sad for the state of software security.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Acknowledging Success

    Today is the Redgate annual award event, and I’m honored to be hosting again. I’ve been asked a few times, and I used to look forward to the gathering in Cambridge followed by our annual Christmas party. Last year this was virtual, as it is this year, so I’m hosting again from my home office. Not what I had hoped would happen, but I’ll have some fun. Last year I had a number of shirt changes between my parts, and I may do that again.

    I know there are often annual sales awards in many companies, usually with some vacation or prize being given out, but not a lot outside of the sales department. In most of my jobs, we’ve usually had some sort of holiday party, but nothing else for most employees.

    As we approach the end of the year, I wonder if you find your organization doing any sort of recognition for your work this year? Or maybe highlighting those that have gone above and beyond what is expected? At Redgate, we have nominations in various categories. Some are sales-oriented, but we have an open award category as well as an ingeniously simple one. We’ve had people or groups from different parts of the company win that one.

    I think that recognition of effort and work accomplished is important for the morale and motivation of employees. When management recognizes people for their hard work and lets other employees have input into the process, you build a better team of people working together. Even when we aren’t the winners, we can appreciate the effort that others put into improving the organization.

    My view is that few too few in the management of organizations appreciate the value of employees, especially the knowledge workers. Replacing people is hard, and it is expensive. Unmotivated people do less work and do it less well. I hope that more organizations learn this and start to put effort into valuing those that contribute to everyone’s success.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Worse Before Better

    There was a thread on Twitter on career longevity and fixing issues inside an organization. IT notes that often there is a problem and someone is assigned or hired to fix them. Often when someone starts to dig in, they can fix some things and reduce the pain.  That’s good, as things get better.

    However, as you gain more knowledge of the issue, sometimes you realize there are more fundamental problems. If you try to fix them, you might make things worse. This could result in a repeat of the process of worsening and bettering of the problems over time. You might not make much progress if new people are constantly assigned when things get worse. If you stick with the person that is working on underlying problems, things get better over the long term. I don’t know how often I find management willing to stick with the same person.

    I think my experience has often been that organizations engage in short-term thinking. They just try to patch an issue and don’t necessarily make things better over time. I certainly saw this with supporting Windows systems in the 90s. We often rebooted machines first, which “fixed” the problem. At least for then. Often the issue would repeat, but customers could reboot their own machines.

    Is that the right approach? It could be, if a long-term fix requires lots of resources, perhaps a regular set of reboots from people is a better tradeoff. In a more complex system, usually, we find someone fixing a short-term software issue with code that is less reliable, or even less upgradable in the future. How many times do we see code that has a comment to “not touch this” or a note that the last developer didn’t understand this, but it worked. We end up with spaghetti code that no one maintains, doesn’t want to touch, and it inhibits our ability to grow and react to new requirements.

    Good fundamentals make a difference in how we build and maintain systems. This is especially true in databases, as we have to live with their design for a long time. We need to be agile, but we should apply good database modeling and integrity practices as we do so. Making quick decisions on how to add something to a schema is fine, but do so in line with best practices and an eye on the future.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Getting Beyond Passwords

    Most of us that work with SQL Server likely use either the Windows authentication or a user name and password when connecting to an instance in SSMS or ADS. It’s how we’ve operated for years, and likely will for some time to come. If you connect to Azure cloud resources, perhaps you use some multi-factor authentication (MFA), but that’s a minority of us.

    If this article is a picture of the real world, far too few people are using authentication beyond passwords for many services. While plenty are using fingerprints, patterns, or face recognition on a mobile device, that’s usually the extent to which they actually go beyond a password. I’ve actually started to see people using PINs on laptops instead of a password, which feels like a step backward.

    Recently I saw someone suggest MFA for SQL Server. I would hope that we would get not only more complex authentication for the platform, perhaps even two-person authentication. but I’m not holding out hope. I think the integration with AD is likely to require more steps than most administrators want to take. For now, I expect that any sort of on-premises SQL Server security is going to remain the same. For cloud databases, I do think that we will see other options as they become available.

    I personally don’t think we’ll ever get beyond all passwords. There are just too many situations where someone might not have a smart device they can access. Too many unlinked services and organizations that might not want to authenticate to GitHub, Google, Facebook, or any other large service. I certainly can’t see email moving beyond passwords entirely. We might get a login with some other service, but a password will still be a last resort.

    While I’ve gotten comfortable with quite a few different authentication mechanisms on a daily basis, I do think that the entire structure is still complex. While I often authenticate with some sort of MFA, it’s a mix of copy/pasting codes or pressing authorize buttons. That’s if I actually remember which service I used to authenticate to a particular service.

    Ultimately, I find unlocking a safe and copy/pasting passwords to be the simplest method, and I find myself often choosing to create accounts with email and passwords. Easier than me trying to track where I might have used Google v Microsoft for authentication.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.