[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <optid.3820bd4d61.6190AFC15DE07D4FB10B1DC7715E0FD84381C8EB@EX2010.hammerofgod.com>
Date: Fri, 23 Jul 2010 17:29:00 +0000
From: Meadow <Meadow@...merofgod.com>
To: Dan Kaminsky <dan@...para.com>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: Expired certificate
I agree, that would be a very expensive approach. But if you're in a situation where you have 500 servers with expiration dates staggered every 2 days, you need a better program manager.
A much more likely scenario is that you have certs on all of your servers supporting Application A expire in February. The certs on the servers supporting Application B all expire in April. And the certs supporting Application C all expire in September. Your $60/hour employee(s) can change a bunch of certs at one time, which means steps 2-6 that you outlined would be bundled rather than duplicative. This approach would save not only labor costs, but many sleepless nights.
If your organization really did have the expiration staggered at every 2 days, then you should take a bunch of servers (grouped by segment/application/whatever makes sense in your environment) and renew all the certs on that group of servers at once, even if they aren't all quite expired yet. You should also fire your program manager. The savings in labor and down-time would make up for the one-time cost of renewing some certs prematurely.
PS. Hi Dan! :)
From: full-disclosure-bounces@...ts.grok.org.uk [mailto:full-disclosure-bounces@...ts.grok.org.uk] On Behalf Of Dan Kaminsky
Sent: Thursday, July 22, 2010 6:06 PM
To: Marsh Ray
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: [Full-disclosure] Expired certificate
Operationally, it just shouldn't be that big a deal to schedule a maintenance every few years. Like expiring domain registrations, the hardest part is simply to not lose track of it. The Accounting dept in an organization can sometimes help to not forget that stuff.
Shouldn't? That's a nice word.
What does the data say?
Suppose I have five hundred web servers with five hundred expiration dates, strewn out roughly uniformly over a three year period. That means, I have about one expiration every two days.
Now, to run a change:
1) A purchase must be made, of the thing to be changed
2) A meeting must be scheduled, to organize the change (especially if, as you suggest, an external organization tracks these things)
3) An administrator must be tapped to implement the change in non-peak time
4) The change must happen
5) The change must be tested and validated
6) The new expiration time must be confirmed for tracking purposes
Lets say this is 8 man hours. That means this is 4,000 man hours of work. Assume the employee doing this work has an average cost to the company of $60/hr (remember, you need to roughly double the cost of a full time employee, after you factor in benefits, payroll taxes, etc).
That's $240K/yr being spent to manage three year expirations, just on labor.
And, of course, you see the result of this: People don't go ahead and put 500 different certs on 500 different machines. Instead, you end up with an Internet having but a million SSL endpoints, only half of which even pretend to have a validating certificate.
Costs can hide. Consequences are another matter.
Content of type "text/html" skipped
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists