Loading…
0
A security guy in Austin told me to stop rotating secrets on a schedule, and my audit results actually got better
I used to force every team to rotate API keys and DB passwords every 90 days because that is what our policy said. A guy named Dev at a meetup in Austin last year told me that calendar based rotation was mostly theater and that I should rotate on events instead, like a dev leaving or a key showing up in a log. I ignored him for a few months until we had to prove where a leaked key came from and could not tell if it was the old one or the new one. So we switched to event based rotation and started logging key usage per service, and over 6 weeks we cut our unused secrets from 340 down to 60. Turns out a shorter list of live keys made the audit way easier than showing a rotation log nobody read. Anyone else move away from the 90 day clock, and what did you replace it with?
1 comments
Log in to join the discussion
Log In1 Comment
emmam6724d ago
One thing in your post is not quite right and it matters for audits. Event based rotation is better than the 90 day clock, sure, but the real win you saw was the key usage logging, not the rotation trigger itself. Cutting 340 keys down to 60 worked because you finally knew which keys were dead, and you could have gotten that same number while still rotating on a schedule. The leaked key story proves the point too, your problem was not the timing of rotation, it was that you could not tell old from new because you had no usage trail. Plenty of teams rotate on events and still fail audits because they never built that per service log. So keep the event based rotation if it works for you, but do not let anyone tell you the calendar was the whole reason your audit got easier.
6