Voice of the DBA

Author: way0utwest

T-SQL Tuesday #167 – Encryption and Data Protection
I missed September since I was gone half the month in Europe and busy with a roadshow.

And, I missed October, since I was busy this month and lost track of this during my travels. However, I can still write, and I love the invitation from Matthew McGiffen. It’s on Encryption and Data Protection, two things I care about and about which I’ve delivered a few presentations.

As always, T-SQL Tuesday is a monthly blog party where you can write on a particular topic. It’s a great way to stimulate some learning and writing, but it’s also something you can catch up on later. I’ll likely write something on #166 in the future.

If you want to host, send me your interest on Twitter (@way0utwest), LinkedIn (/in/way0utwest), or email (sjones using the sqlservercentral domain).

Protecting Encrypted Data

One of the things I deal with regularly is how do you deal with encryption in your software pipeline. There are two concerns here:
1. How do we deploy encryption keys to production from development?
2. How do we refresh development environments with encrypted data?
It should go without saying, but I’ll say it. You can’t use the same keys in development and production because most auditors and regulatory authorities won’t see this as secure. If you have really secured development, and you are bonding developers, them maybe, but most of the time you need different keys/certificates/etc. in production than development.

This means you can’t have the key definitions (SQL Server) or asymmetric key files/certificates in version control. That makes deployment a challenge.

What I usually recommend here is that you have a separate pipeline for privileged, DBA, users who can store some of this in a separate repository and secure that.

At the same time, how do we get this data down to dev? Honestly, I wouldn’t. I’d let it come down encrypted, without the keys (those can be deleted as part of the refresh) and then add in known, secure, PII data with a dev key. The mechanics here get complex, but suffice it to say that protecting keys and keeping them out of dev is important.
October 25, 2023
Deleting a Git Branch–#SQLNewBlogger
I had someone ask me recently about deleting branches. While I had known how to delete a local branch, I had to look up how to delete a remote one. Documenting these both will hopefully help me remember this.

Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

Deleting Branches

Most parameters have something do to with the action, and most people might guess a –d is used to delete a branch in Git. The actual syntax for a branch named “Feature123” is:

git branch –d Feature123

You can also use a –D, though be aware that –D is the same as –d with the –force option. The –d actually aliases to –delete, so you have three options:
- -d
- –delete
- -D (this will run –-force)
To delete a remote branch, you can use (with v1.7+)

git push origin –-delete Feature123

where origin is the remote name and Feature123 is the branch. This is better than the old syntax, and you ought to keep your git up to date.

You can see this working for one of my branches below:

Git docs for branch have more details.

Use this to clean up branches if your changes are merged and you don’t need to send in any more PRs for this branch.

SQL New Blogger

This is a simple thing, but one that I don’t do often, so I wrote this as much to document it for myself as to put this out there as a piece of knowledge. If someone reads this post and asks the question in an interview, it’s likely an easy one for me to give.

You can do this, help showcase your career knowledge and control the interview. This piece took me about 8 minutes to write. You could do your own version of this topic.
October 23, 2023
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.

October 23, 2023
The Year in Travel
Here’s my year, which is pre-populated with a couple more trips coming up in November. Those should be all, as I’ve declined to go back to the UK in December and am hoping to lay low a bit. These are the trips I’ve taken, plotted against distance from home.

A lot of similar trips. I had repeats that were:
- London – 3 times
- Las Vegas – 3 times
- Chicago – 3 times
- Austin – 3 times
- Boston – 2 times
- Syracuse – 2 times
- Florida – 3 times (JAX, Orlando, Miami)
- St Louis – 2 times
- Dallas – 2 times
The big trip was Alaska, which was my wife’s 50th state. I think it was 46 or so for me. I know I’m missing Maine, Arkansas, Iowa, probably one more I can’t think of right now. I’ve spent the night in all other states.

I have (I think) a total of 30 airplane trips away from Denver. The actual flights are more like 70 with some connections. I spent 100 nights away from home, though some of those were in the mountains or camping. Or in airplanes. I probably spent 3 nights on airplanes this year.

That’s a lot. A long year for me, and I’m likely to avoid some travel until March or April, so hopefully I can recharge over the winter and relax at home.
October 20, 2023