Voice of the DBA

Category: Editorial

  • Cyber Insurance for War

    Is the United States at war in cyberspace with other countries? It’s the claim that a few insurers made when US-based Merck filed a claim after a 2017 cyberattack. The company filed a $700mm-ish claim, and the insurers rejected this saying that the attack was an act of war by Russian government operatives. If a factory were disrupted in the real world by actual government operatives (soldiers, spies, etc.), then it likely would be considered an act of war, but in cyberspace, who knows.

    Actually, in cyberspace, who really knows who is whom, and for who they work? Maybe we don’t even know who “they” are in many cases.

    Bruce Schneier wrote a piece on this, talking about a possible solution of using a government backstop that would provide some assistance or coverage that insurers might not be able to cover. While that sounds good if you have a claim, as a citizen, I think this likely encourages more attacks from others, whether they are nation-states or individuals. If someone thinks they might create a spending crisis in a country, maybe they would mount many attacks that are disguised as coming from a foreign nation and cause a government spending issues.

    The United States has a scale issue, but this could cause similar issues in many smaller countries if this were a way of doing business. Perhaps this might also cause some economic issues if companies don’t want to do business in places where they aren’t covered.

    However, this might not be a big issue as more insurers are starting to carve out exceptions in their coverage for these types of attacks, so if your organization is hacked by a supposed nation-state, you aren’t covered. I suspect this will also start to extend to other exceptions, such as having unpatched (or incompletely patched) systems, poor policies or just incompetent employees, lack of security scans, and more.

    In some sense, I would hope that some of these attacks will force, or at least pressure, many organizations to take security more seriously. At the same time, as someone dealing with these changes, it can be inconvenient and a blow to productivity as I struggle to adapt to changes in policy, protocol, and procedure. Some are easy, like locking my home machine. Some are more challenging and frustrating as I try to share more content inside the company. It’s good, but it’s frustrating.

    Cyberattacks and cybersecurity are increasingly a part of our lives as technology professionals and I urge you to spend a little time learning about the field. If you want a fun challenge, try the Advent of Cyber 2023 is still up as of this writing. I went through it and it was a fun (and scary) way to learn a few things about security, vulnerabilities, and tools out there.

    Steve Jones

  • Using AI for Security

    AI (Artificial Intelligence) systems and technology has been all over our industry for the past year or so, ever since ChatGPT released the initial public version in late 2022. It seems that there is a lot of hype around the possibilities, with plenty of excitement and skepticism, depending on who is talking about the tech. However, there do seem to be some places where the technology is working well, and security is one of them.

    There is an article about how Microsoft is using AI to help spot ransomware, which seemed to have run rampant a few years ago. It’s still around, though it seems fewer exploits are being publicized. That might be because systems are better protected, perhaps there are fewer attacks (unlikely), or maybe more organizations are getting better at covering up their issues. They might be better prepared to restore backups or quicker to pay a ransom.

    In any case, Microsoft is exploring machine learning (ML, a subset of AI) to detect patterns and behaviors that can indicate a ransomware campaign is starting on a system. Looking through logs of activity for unusual behavior is something ML might be much better at, or faster at, than humans.

    I certainly know that if I were running queries that might look at my activity on systems, taking a guess about whether or not the activity this week is “regular” and matches patterns from last week is hard. Often exact matches of activity patterns cause lots of false positives if they are too tightly written. If we loosen the parameters too much, we miss potential attacks. A fuzzy view of the pattern is needed, something ML is good at detecting. After all, we need to look at all activity from all users, and determine if Steve’s activity this week is different than last week, and at the same time, is Grant’s activity unusual and a sign that his account is compromised?

    Some humans are very good at spotting patterns in activity, but only at a limited scale. We get tired, our minds wander, and we can’t only focus on looking for patterns in log files. We’ll get bored, distracted, and start to make mistakes. AIs don’t get tired, and while they might miss some anomalous activity, and certainly will report plenty of false positives, humans can focus on this subset of reports and perhaps partner with AIs to do a better job helping secure our systems.

    I lean towards the idea that AI technology will help us better spot malicious activity in the tremendous amount of data we capture about our networked systems when humans are attempting to hack us. What I’m not sure about is how well criminal actors will use AI tech to further disguise their activity. I can certainly see a future where lots of AI bots battle each other at blinding speed while humans watch and hope the defenders manage to outwit their attacking AI opponents.

    Steve Jones

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

  • The Art of the Code Review

    The inspiration for this was a piece about the art of the good code review. Throughout my career, I’ve seen code reviews grow and change. From formal meetings to automated notifications and asynchronous discussions to complete lip service to the process. I’d like to think that most organizations are beyond the latter and there is some sort of review beyond the developer, but I still see a lack of other eyes looking at code before it’s deployed, especially database code.

    The article above opens with the idea of why we review code. The main reason is to create ownership, or more specifically, shared ownership. I had never thought of it in these terms, even though I think the ideas of standards and patterns are certainly shared items. Having everyone take ownership not only keeps quality high but could help you share knowledge and also ensure everyone feels a responsibility to safeguard all the code. This also helps everyone keep an eye on the larger picture of the entire codebase.

    I know lots of modern application developers are very familiar with pull requests, though I think these are still somewhat rare in the database world. This is a notification that someone would like their code to be put together with everyone else’s code. A good code review does start with a good pull request, as the idea is to have enough information to let the reviewer decide if they should approve things. PRs should also be focused, so if you are making a major change in one object and refactoring another, make those two different PRs. That way I can reject one without the other.

    Overall I like the suggestions in the post, but I worry about one of them. The author notes that if there are minor changes requested in a comment, you should pre-approve the PR and trust the author to address the issues. In today’s very busy world, and with the challenge of changing code once it’s deployed to a database, I don’t know if I’d follow this for SQL code. Maybe for C#, but if I have to live with your code for a decade, I don’t want mistakes deployed that could be prevented.

    Steve Jones

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

  • The Dangers of Not Upgrading

    About ten years ago my sister-in-law broke the screen on her mobile phone. She’d had an older iPhone and when she went to upgrade, none of the upgrade processes worked because her OS was so far behind that they couldn’t transfer her information smoothly. She had been avoiding OS updates because they interrupted her life, but that was now a problem because the world had marched so far beyond her version that there weren’t tools, or at least, no one was interested in trying to perform an upgrade across multiple OS versions (I think it was 3 or 5 versions).

    I ran into this recently with someone else I knew, but not for a mobile phone. For TFS 2015. This customer had been working along with this older system and is finally ready to upgrade to Azure DevOps in the cloud. They wanted to know if they could somehow upgrade the TFS database and move all that data easily into the cloud. I said this wasn’t likely easy as this isn’t an upgrade, but an export and import of a lot of data. Microsoft offered a path, but it was multiple upgrades before an export/import, which was deemed too expensive. Right now, I’m not sure what they’re doing to do.

    I know that many people keep old versions of SQL Server out there. Brent’s population report still shows some 2014 and older databases, and I’m sure there are plenty of 2008-era (or older) instances in use. Many of you continue to run older software because it works. That might especially be true on desktops, where we often install specific software for a task that might not change for years. I think there is plenty of value in older software that works well, though there might be security concerns.

    However, for platforms or software where there is a regular upgrade path that you will need at some point, it pays to keep up, at least a bit. Maybe you don’t upgrade with every version, but you likely shouldn’t fall more than two versions behind. Vendors don’t want to maintain compatibility for too long and certainly don’t want to keep providing updates for new features. Even security updates get expensive to produce for old versions with complex test matrices needed to ensure the patches work and don’t break the application.

    Software is a bit of a crazy business. In the analog world, if we own a product and it breaks or has an issue, often there are third parties who can repair it, or even create the necessary parts for the DIY market. Software is different, and the pace of change can be a bit overwhelming, expensive, and annoying. We can’t fix old software, heck, we’re not even allowed to fix old software. We can get into legal trouble if we try.

    I don’t know if there is any good solution, but I certainly do know that if you manage software, you ought to be careful to keep abreast of how often the software upgrades and when support for previous versions is waning. Even if you don’t care about customer support calls, you likely care about upgrading to a newer version at some point, so make sure you know when they might drop support for upgrading from your version. Stepped upgrades work, but they can be expensive and time-consuming, and if there are issues, often vendors aren’t interested in why the upgrade didn’t work from your extremely-old version to a slightly-less-old version.

    I still expect a database version to run for 10 years, but I know that support is tricky, and I also know that I better be ready to upgrade at that time.

    Steve Jones

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