Voice of the DBA

Tag: security

  • Teams Security Issues

    At some point during my career sharing files and links in email became a security concern. There were all sorts of malware problems and issues that spread throughout organizations because someone unknowingly clicked on or forwarded a malicious item. At a couple of large organizations, we had to turn off email for days while we cleaned out systems. Fortunately, antivirus and other types of scanning software improved to prevent most of these problems.

    It seems that not all developers learned the lessons of the past. Microsoft Teams has a few vulnerabilities inside it based on link sharing in the chats. One of the issues is that the preview features aren’t well implemented, though Microsoft security doesn’t think this is a problem as a user would notice the link would be incorrect. I think that’s a huge leap and not a very safe one to make.

    I don’t use Teams often, and as a Slack user, I find it rather confusing, busy, and unintuitive. I know lots of others that like Teams and find it very productive in the Microsoft world, and I’m glad we can have the choice of a way to collaborate with others. However, no matter which type of communication mechanism is used inside of your organization, the security protections ought to be very strong. We are often busy with work and distracted. We are often expecting the information in Slack or Teams to be safer than browsing sites on the public internet. Perhaps that’s not the way things should be, but it is.

    Attack vectors that use code inside a webpage are very common, and I dislike many of the “preview” features that I’ve seen in various pieces of software. They slow down the application, especially on a mobile network, and take up unnecessary space. As someone that often can see bandwidth constraints, I’ve prefer that all of these features were optional. Let me decide if I want a preview.

    The trend to build richer experiences in applications and pre-fetch data can make the experience better, but there is a tradeoff. There are potential security concerns, but apart from those, these features can make the experience more enjoyable or unnecessarily slow things down and interfere with the way we use an application. More isn’t always better, especially when the pattern for an individual user might not match what the majority does. If 51% of users often use a feature, I’m not sure the other 49% view this as a positive way of architecting the system.

    Steve Jones

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

  • The Challenge of Edge Security

    We know that our organizations will adopt and use more devices over time. Given the growth of cheap computing, frameworks for managing devices, and the desire for more data, I expect some of those devices will collect data, or even contain databases. Azure SQL Edge use is growing, and we will see more devices that contain it (or another database platform), which means we have a larger attack surface area for that data.

    There was a recent report on a vulnerability in edge devices used by AT&T that was detected as part of an attack. The attack used a known vulnerability based on default credentials. The vulnerability was fixed, but the patch required manual work. From various reports, it is unclear whether devices have been patched. It’s also unclear if customer data was accessed. Here is one such report, but there are others, all with similar information.

    When developers build something, whether a device or just software, we often set up easy ways for us to access the system to test features and functionality. Certainly when software is deployed to users, there is often a default credential that is supplied. I don’t know if this is good or bad, and if the management of random credentials for each device might result in better or worse security. Strong passwords might lull customers into feeling that they don’t need to change anything.

    I do think that the installation of any software ought to require a strong password. Once one is entered, and defaults ought to be permanently removed or changed. Leaving around defaults for maintenance or ease of updates is a sure way to get hacked. If we’ve learned anything in the age of computing it ought to be that anything you deploy in the wild will be taken apart and analyzed by someone. Hard-coded values or default accounts will become known.

    The bigger problem might be that patching is still a problem and even more of a problem when it’s not easy. I know that the SQL Server update system is fairly easy, but not dead simple. Many people still don’t apply patches. Heck, even when updates are built into something like Windows, people try to avoid patching their systems.

    For those of us that work with databases, we may or may not control the update process. We can, however, ensure that those that do are aware of when patches are available, how far behind the system is, and where to get the patch. That information, and a little pressure, will become increasingly important as we deploy and work with data on more edge devices.

    Steve Jones

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

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

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