Rotating Keys

Question

Rotating Keys

Steve Jones - SSC Editor

SSC Guru

Points: 736210
More actions
January 28, 2010 at 10:07 pm

#220138

Comments posted to this topic are about the item Rotating Keys

Viewing 13 posts - 1 through 12 (of 12 total)

You must be logged in to reply to this topic. Login to reply

Manie Verster SSCertifiable Points: 7152 More actions · Answer 1

I cannot answer on encryption because I have never done that and that is not because I do not want to but because it hasn't been important enough yet. I am relying heavily on windows security and our network security for attacks from outside. Regarding passwords I think every 3 months is good.:smooooth::-)

:-PManie Verster
Developer
Johannesburg
South Africa

I can do all things through Christ who strengthens me. - Holy Bible
I am a man of fixed and unbending principles, the first of which is to be flexible at all times. - Everett Mckinley Dirkson (Well, I am trying. - Manie Verster)

IceDread SSCertifiable Points: 5050 More actions · Answer 2

I dont think there is such a thing as a good interval, what ever the interval it's annoying to users with all the account information to their home computer and emails and various portals on the net and on their work.

Anyway I find that a new password each 3 month is perhaps enough, but really some white paper on it sounds like a good idea for you to try and find Steve since your interested in it, and well we all should have security in mind. Together with some interval for new passwords the passwords needs to be strong or else the password is a little bit of an illusion of security.

John Magnabosco Ten Centuries Points: 1195 More actions · Answer 3

There are a lot of dependencies in the answer to the question of how often keys are to be changed. If you are considering key changes for encrypting credit card numbers, PCI DSS states that it is their preference that the key is changed at least once a year.

One thing to consider is that you will (or should) have a series of keys that protect each other, also known as a key hierarchy, rather than only one layer of key protection. Each key in the hierarchy can be changed at different intervals.

The ideal situation would be the establishment of a key life cycle. This is where a key exists in a sequence of states before it is permanently destroyed.

For example:

Pending: Newly created and not yet in use

Active: Used to encrypt and decrypt

Expired: Used to decrypt data that was encrypted when the key was active

Retired: No longer in use

Destroyed: The key is destroyed

In this scenario, you would not do the key change and re-encrypt; but rather the re-encrypt process occurs naturally as older data is updated. This also limits the volume of the data that is encrypted by any given key. If a key is compromised, the entire database is not at risk of disclosure.

SQL Server does not offer this functionality as part of the product. I would argue that it shouldn't be. There is a risk of housing the key management functionality within the database/instance that the keys are protecting. Extensible Key Management provides a way to "hook in" providers that can accomplish more advanced key management.

Shameless Plug: Hopefully one of the books that Steve is reading is mine: 😀 Protecting SQL Server Data

dpsligar-591875 SSC Rookie Points: 35 More actions · Answer 4

Simple reply: our corp standard is to change the encryption key every 90 days.

Cris E Ten Centuries Points: 1255 More actions · Answer 5

Every hundred years, whether they need it or not. 😀

Actually I don't think we have a standard for that yet. SSL Certs tell you when to attend to them, and we have a schedule for password changes, but encryption keys are sort of invisible around here. Maybe I'll ask around a little...

[font="Arial"]Are you lost daddy? I asked tenderly.
Shut up he explained.[/font]
- Ring Lardner

Patrick Cahill SSCertifiable Points: 6470 More actions · Answer 6

We have a policy in place to change our encryption passwords once a year. I am interested to see what others do, as we are always looking for the best practice on this.

AJHall Mr or Mrs. 500 Points: 580 More actions · Answer 7

Thankfully I don't manage those standards at work but I've been trying to maintain best practices on my own test server at home. Although I have no confidential data on my test server I still encrypt and rotate keys every 3 months. I roughly keep things on the same schedule at home, I change my wireless and admin account passwords on the same frequency.

I find any maintenance routines that may involve me physically doing anything is best done in batches. Thankfully my backup procedures are automated otherwise they'd never get done at home.

Aaron Hall
IT Infrastructure Consultant

Nothing is more confounding than a DBA that uses bureaucracy as a means to inflate his power. Ever try to get an index added to a government run SQL server and you'll know what I mean.

SQLRNNR SSC Guru Points: 281334 More actions · Answer 8

A good interval is sometimes dictated by compliance to some outside authority. For us, it was made clear that we must rotate the keys every 90 days at minimum. It could easily be integrated with that quarterly DR test / or at least mass restore test.

To play advocate a little:

Let's say somebody does get a copy of the old database and has been able to hack the key - why bother hacking the current database? The only real gain seems to be in getting some more records worth of information. If you have 1 million person records with personal data attached to them that must be encrypted (i.e. ssn), and only add 10,000 records in the next 3 months - where is the worth? I would already have 1 million social security numbers - from the old database.

Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events

laurav Mr or Mrs. 500 Points: 510 More actions · Answer 9

Depending on your environment & up-time requirements, service account passwords may take months to change; every 90 days is not reasonable. I, too, think there are much easier targets. An old backup, Guest accounts, unpatched instances...

Jeff Moden SSC Guru Points: 1004339 More actions · Answer 10

Ummm... I'm confused. Wouldn't the real key be to keep people from getting a copy of the database to begin with??? :blink:

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Steve Jones - SSC Editor SSC Guru Points: 736210 More actions · Answer 11

In terms of hacking an old database, how would they know the record count? What if it was a dev database? I've seen those before, development passwords moving to production and never changing. What if that happened with encryption keys?

TomThomson SSC Guru Points: 104773 More actions · Answer 12

Trouble with this question is that it is oversimplified.

For passwords there's a need to distinguish between (i) the passwords of individual people, (ii) group passwords, (iii) functional passwords which are protected by personal or group passwords and maybe also by encryption, and (iv) functional passwords which are protected only by obfuscation. You also have to worry about the environment in which the password is used (is it used in public, in internet cafes? Or only in secure premises? Is it ever transmitted in clear over a telephone or telegraph line, over an insecure LAN, over a secure LAN? Is it used as a whole or does authentication ask for just some attributes of it?

For encryption keys, it's useful to distinguish between (i) keys that are used for a large amount of material, (ii) transient (single session or single message) keys, (iii) non-transient keys that are used for only a small amount of data, (iv) keys that are used only to protect transient keys, (v) keys that are used only to protect other non-transient keys, and it's maybe necessary in most of these cases to (a) make all the distinctions made for passwords and (b) add in the complication of keys which no single person is permitted to know (equally for for passwords some organisations use multi-part passwords where it needs several people to each to apply their part to authenticate) and (c) distinguish symmetric and asymmetric encryption systms, and in asymetric systems distinguisg keys used only for authentication, keys used only for validation, and keys used for data encryption.

For personal passwords, my feeling is never rotate. Of course change the password if you suspect compromise, and if the person concerned leaves the organisation diable the password, but regular rotation will reduce security be encouraging people to choose easy passwords and/or write them down. For all the other cases, I would look at the details of what's being protected and how the key or password is being used and come to a conclusion - as there at least a hundred csases to consider given variations in use and exposure even before we come to look at the sensitivity of the protected material any simple answer giving a single period will be wrong.

Tom