Lately, I find myself saying this a whole lot.
The conversations in which I’m saying this follow the pattern of these examples:
Me: “Let me understand your problem – tell me why you don’t want to have expiring passwords on this service account?”
Other guy: “Because when we change passwords, we’d have to change the password at the domain controller, then log on to each machine that runs the service, change the passwords, and stop and restart the service on those machines. Then we’d have to take note of which machines had issues with the process, so that we could work on troubleshooting those.”
Me: “Someone should invent a machine to do that … they could call it something like … a komputor. I’m sure they’d sell millions.”
Yes, it’s a little sarcastic when I put it that way, and for the most part that last piece is in my head. It usually comes out as “that could be done by a simple script”, or “can we justify the cost of buying one of the many programs out there that manages that entire process automatically?”
When you take a boring and mundane manual process and turn it into an automated process, whether through scripting or purpose-built applications, you significantly reduce the likelihood of error, and you can take your staff and turn them to other tasks that require human thought and are interesting.
In the spirit of "ten unavoidable security truths", and numerous other top-ten lists, here’s a list of ten key truths that apply to public / private key pairs:
Note that this list describes what happens when cryptography is working perfectly. There are other key facts that apply to broken cryptography and broken process:
Note that these lists are rather arbitrarily scoped to ten – there may be more important truths I’ve forgotten, or items I’ve included that aren’t really so important.