Press J to jump to the feed. Press question mark to learn the rest of the keyboard shortcuts
2

Backing up PCI devices

So I've been wracking my brain on this one, and I'm hoping some community involvement might help.

I'm trying to have a healthy way to back up some PCI In-Scope devices.

Storing the devices and credentials to get into them requires you to have a username and password somewhere, because not all devices support certificate based authentication. So somewhere you have to have a system that accesses a plain text, "this username, this password." It could be stored in a database, and the database itself is encrypted, but somewhere you need to have some method that says, "You'll access this database at this location with these credentials", so if its on the same host as the backup system, where's the real mitigation?

PCI data at rest needs to be encrypted. So, the config files when resting need to be in an encrypted location. Which, I suppose an EFS should handle that accordingly, and as long as you limit access to the box, shouldn't be that bad. But if you're using encryption at rest, wouldn't the mitigated risk by the device list in an encrypted database not be as necessary?

Am I overthinking this as a problem, or is backing up plain text files of configs just something that isn't as complicated as I feel it's being? Or maybe I'm just circling around in my own head for the day overthinking issues.

15 comments
57% Upvoted
What are your thoughts? Log in or Sign uplog insign up
level 1

You might get a bit more help at /r/sysadmin.

level 2
Original Poster2 points · 2 months ago

I'd thought about it, I was just curious to see if any of us had this same fun experience, especially since I'm only dealing with Routers, Switches, and Firewalls, no servers. If I get no joy, I'll definitely cross post it there.

level 1

Your CDE equipment needs to have MFA enabled so that's kind of a second line of defense. Use a password manager with a second 2FA and call it good?

You hopefully aren't making frequent changes in that environment so backups should be infrequent as well.

level 2
Original Poster1 point · 2 months ago

Honestly, they're mostly firewall rules. I'd honestly thought about saying, "Fuck the backups, configuration management through Git with zero touch deployment" but I'd get nixed.

level 1

So somewhere you have to have a system that accesses a plain text, "this username, this password."

Hopefully not plain text, but a hash.

level 2

Systems doing the authentication (present your creds to me) can store a hash.

Systems attempting to prove their identity need to hold the actual password.

level 2
Original Poster1 point · 2 months ago

Also true.

level 1

Wouldn't certificates be just as bad as plain text credentials in this scenario? If somebody gets physical or remote access to your backup device, then can't they still use the certificate to gain access to your networking infrastructure? Regardless of technical security, at some point physical security (i.e. a locked room) is going to be relied upon, no?

level 2
Original Poster2 points · 2 months ago

The sad part with Virtualization is that physical security can only go so far, because you can virtually steal the physical machine. Which is why EFS would be a good solution, because once the machine is booted you can decrypt the volume that has the contents. Store the cert or the username/password in the encrypted volume, additional layer of protection.

And in theory, certs could be in that same boat, there's just the idea of revoking the cert, which would be the same as disabling the user account.

level 3

I'm only vaguely familiar with EFS, but doesn't that mean you'd have to be constantly logged into the server so the contents of the file/folder/disk/etc could be decrypted? So if the server reboots, you'd need to manually log back in for backups to continue? And if it's a VM that you're always logged into, then if somebody got into the hypervisor and could snapshot the contents of the guest's memory, wouldn't that decryption key be somewhere in there?

It just seems like at some point there's always a weak link in the chain. I'm not being argumentative or anything. This is something I sit and ponder about.

level 4
Original Poster1 point · 2 months ago

I appreciate the thoughts, genuinely. Wouldn't have posted if I didn't! Trust me, I spent all day Friday just wracking my brain on this, and that's what had me so frustrated.

you'd have to be constantly logged into the server so the contents of the file/folder/disk/etc could be decrypted?

As long as when the server boots, the system has an account to de-crypt the EFS, it wouldn't require a human interaction.

So if the server reboots, you'd need to manually log back in for backups to continue?

Script it out. Something to set at boot.

then if somebody got into the hypervisor and could snapshot the contents of the guest's memory, wouldn't that decryption key be somewhere in there?

If someone got into the Hypervisor there are much bigger problems. If they got the system into being suspended and not shut down, the host would be still up and accessible.

level 1

somewhere you have to have a system that accesses a plain text, "this username, this password."

Hashicorp's Vault is made to handle this problem and hand out the stored keys (or even generate tokens/creds on demand) according to a configurable policy. It's pretty neat.

Vault can use any of a few different types of backstores (databases, flat files, key-value stores). The data that goes into the backstore is encrypted.

The encryption key itself is reed-solomon encoded and encyrypted, so that you can distribute passphrases to a bunch of employees: so long as M of N employees are available to enter their passphrases, the vault service will start.

level 2
Original Poster1 point · 2 months ago

Vault is something I'm actually working with. For my inventory and standards scripts, I pull the credential set out of the Vault, and a cert is issued to the host for a three month time period.

Because the cert gives me the credentials, and they're not hard coded in a script, it's never stored anywhere in code.

I think I was just getting frustrated in how to solve the problem that didn't involve, "Re-write it yourself."

level 1

The secrets and passwords within the device configuration are typically obfuscated so storing this in plane text shouldn’t be an issue as long as backup destination is protected with authentication. I have not come across a PCI requirement to encrypt the config backups at rest.

level 1

If it's just networking kit, use Cattools on a windows server that is inside the PCI scope. The data never leaves PCI, you use your normal encryption and the credentials are masked within Cattools.

Source - that's how we did it in the PCI environment I previously worked in.

Community Details

131k

Subscribers

991

Online

###Enterprise Networking Routers, switches and firewalls. Network blogs, news and network management articles. Cisco, Juniper, Brocade and more all welcome.

Create Post
r/networking Rules
1.
Rule #1: No Home Networking.
2.
Rule #2: No Certification Brain Dumps / Cheating.
3.
Rule #3: No BlogSpam / Traffic re-direction.
4.
Rule #4: No Low Quality Posts.
5.
Rule #5: No Early Career Advice.
6.
Rule #6: Educational Questions must show effort.
Cookies help us deliver our Services. By using our Services or clicking I agree, you agree to our use of cookies. Learn More.