Voice of the DBA

Tag: security

  • Bad Culture Bad Security

    I ran across a blog noting that Cisco has a vulnerability in a new product. The blog also lists two (one, two) articles showing that Cisco has had hard-coded credentials in the past. I understand that many times a known process is repeated, essentially copy-pasted between people, and we have similar issues as we have had in the past. However, in 2022 or 2023, it’s unacceptable to hard-code credentials in digital systems that will be used in today’s world.

    What’s worse than having this issue is stating that the fix is “an upgrade”. Their verbiage for those without a service contract is: “Customers should have the product serial number available and be prepared to provide the URL of this advisory as evidence of entitlement to a free upgrade.” Which, to me, is not only bad for the world, but it’s equivalent to the stuff that bulls leave behind in the fields.

    I suspect that this product and software were based on something that already exists, and it was rushed out without a good security evaluation. Or perhaps there are developers and managers who don’t think that hard-coding credentials will compromise security.

    That’s a cultural problem. Either you’re going too fast, or you don’t take this seriously, either way, you don’t have a good culture that values quality and protection. Certainly, their disclaimer about needing valid contracts or proving you have a device to get a security patch for a flaw they built is also a sign of a poor culture that doesn’t really understand the problems they are creating, nor are they taking responsibility for the issues.

    At the very least, fixing their poor security ought to be free and easy. I get that there are likely some software upgrades included in this patch, given the nature of software development and limited branches under support. However, there are other ways to ensure those features aren’t enabled for customers who shouldn’t have them. Making the entire world of computer network infrastructure less secure because you want customers to pay for your mistakes isn’t a model I’d want to adapt.

    I know many people don’t want more regulation or guidelines from governments (or even from insurance), but if I were going to accept some universal restriction, this would be the place. If you use hard-coded passwords, your product can’t be sold and no insurance claims apply if you are sued.

    Maybe that would change the way Cisco and others build software.

    Steve Jones

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

  • Practicing (Annoying) Better Security

    At Redgate Software, we’ve been looking to “level up” our internal security game. While we have had very good security during the 16 years I’ve been there, there have been a few security issues with our products. The speed at which we address things, as well as the communications with customers, has impressed me.

    We’ve had almost no problems with our internal systems, unlike a few other places I’ve worked. We haven’t had the phishing/virus/breach/ransomware issues that I’ve seen at other employers or heard about from friends. I do think our IT staff is diligent and careful, as well as forward-thinking. It also helps that we’ve had a relatively small employee staff that worked in physical offices for most of our existence.

    Recently, we’ve been on a security push to tighten up the way we deal with systems. As we grow our staff, and as we add more offices, there is a recognition that our attack surface area is growing. We also find more and more people using non-Redgate-owned devices. This year we’ve had a series of policies rolled out that we are supposed to adhere to in order to ensure strong security, as well as compliance with data privacy rules such as the GDPR.

    One of these is a bring-your-own-device (BYOD) policy. For years I’ve used my personal mobile phone for Redgate, with a few settings enabled to allow a remote wipe if I lose it. However, I’ve also had a personal desktop that I use for daily work in my home office. I’ve never enabled a lock on this as my wife occasionally uses it to get a picture or other document. Or send me something I forgot to sync in the cloud.

    Part of our new policy is that I need to enable a lock on my desktop, as there is privileged Redgate information on there. Not much Redgate data, but the machine does connect to our business OneDrive and SharePoint systems. This lock should be a 2-minute timeout, which means that I come back to my desktop after coffee, laundry, or something else to find it locked. After years of always locking my desktop in corporate offices, I somehow find this more annoying. Especially as I’ve gotten used to rarely typing my 15-character password. I mess this up regularly and have to (more slowly) re-type my password a few times.

    I know this is better security, and I am always conscious of locking my laptop in our various offices when I go in. However, I find it annoying at home. Especially when I pop in away from work to look up something on the Internet. I keep telling myself this is good security, and good for both Redgate and our customers. I’m still annoyed by the change, but I know it’s for the best. Like many who work in organizations, I’ve been lazy about some security aspects for years, and the change is a disruption. I’m sure some of you feel the same way about the rules and protocols that your employers have implemented.

    You’re not alone in desiring a more convenient workplace, but security is a series of overlapping measures that work together to protect data. Practicing and adhering to good security is a lot like a daily backup. Most of the time it’s something never need, but when there’s an issue you’ll be glad you followed the process that day.

    Steve Jones

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

  • The Need for DevSecOps

    One of the things that happens with many companies that start adopting DevOps is that they release new features constantly. They publish their lists of changes, and they try to attract customers and grow their businesses. They may make some mistakes, but they fix those quickly and keep pushing forward. That’s the idea, and it works well.

    However, many of the developers (and most managers), don’t think about the security side of their changes. This piece looks at the way hackers and criminals view DevOps, often using release notes and feature changes as a target to focus their efforts. In this way, they exploit holes and vulnerabilities in software to attack data storage. The examples include S3 buckets of storage and Elasticsearch, which is notoriously poorly secured by many people.

    I’m sure there are hacks that also expose relational data stores and NoSQL stores, but those are often more secure and harder to directly attack. Certainly, hackers do get credentials and can query data, it’s more often I hear about data breaches from other sources than direct relational database access. SQL Injection is definitely still an issue, and I hope that more and more developers are learning patterns that avoid these vulnerabilities.

    DevOps works. I think it’s great. However, it’s not enough to trust developers to build features without including static code analysis, pen testing, and other security evaluations before you release code. Often developers can build features just as fast with good patterns as bad. Use automation to catch bad patterns and force developers to learn new ones.

    Also, avoid letting developers implement data stores out of convenience and speed. Ensure that strong security practices, long passwords, service accounts, secrets, and more are implemented from the start. It’s easy to shortcut these, but it’s also harder to explain to customers and investors why we didn’t do better.

    If you’re a developer, the main thing to keep in mind is that you will often be the scapegoat for these issues. Upper management might not support you and pressure you to move faster, but when there are issues, they’ll also be quick to blame you and let you go first. Push back and ensure that you have the tools and the process to evaluate if you are building problematic code. Always use long passwords, and document what you do for others to follow.

    And if your boss insists on cutting corners, get that in writing. It might not save your job, but that documentation has served me well in the past when issues come to light.

    Steve Jones

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

  • Rogue Colleagues

    The economy might be good or bad for you right now. Some of that depends on where you live, what your employment situation is like, what your habits dictate about how you live life, and more. No matter what your situation, likely there are people around you that complain about the world and others who think things are fine. There are likely more of the former than the latter, but that’s because humans tend to complain out loud more than they praise.

    When people think there is an economic downtown for themselves, they may be more likely to engage in malicious activities. While I don’t think most data professionals will start to hack other systems, or even their own employer’s systems, there is evidence to support the idea that some might be susceptible to recruitment by bad actors. This piece references some research and warns security groups to be wary.

    There is no shortage of books, or television and movie scripts that might show creative ways to access information, but how can you tell if a colleague makes a simple mistake or they are a bad actor? Clicking on a phishing email could be either one. Not removing anonymous access to an S3 bucket could be either. Losing their credentials through social engineering is something that happens every day. Who’s to say that this happened purposefully?

    I don’t want to second guess the people I work with making mistakes, but I also think these possibilities are why we want to use our computer systems with strong auditing and multiple groups reviewing logs. We might not necessarily stop all activity, but we can often detect it quickly and mitigate the issues. It’s also why DevOps and automated deployments with logging are a good idea. They can limit the problems from both accidents and malicious actors.

    My employer has started to do more education around security and how individuals can avoid accidentally causing issues. We use a lot of automation, and more all the time, that ensures once we know how we ought to patch and update systems, we can do it regularly and confidently. Repeatable, reliable deployments of changes are what we aim for.

    We know they’ll be some mistakes, but we also know that we can quickly identify issues (MTTD) and fix them (MTTR). Even if we get a bad patch from a vendor, we can quickly deploy a “fix” if we get one, or even reinstall and re-patch to lower levels, if needed.

    DevOps, GitOps, and other xxOps aren’t just about getting new features out quickly. They also include the ability to fix problems when the need arises. They don’t prevent rogue actors from causing issues, but they should help you detect and recover quicker than you might expect.

    Steve Jones

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