How could one have detected this kind of attack even faster?
Periodically calling the endpoint and validating the certificate used is the right one?
Periodically calling the endpoint and validating the certificate used is the right one?
Also, automated DNS monitoring could work too.
Which is still highly valuable, in the scheme of things. But wouldn't improve on the timescales they've described.
(I run ctadvisor.lolware.net)
Note, Google crawler will also submit anything it sees, so if your CA lags by a week but your new site is crawled in the next hour, you'll end up logged.
Note that this doesn't tell you whether a CA logs all/ most or none of the certificates they issue. In my experience it would be unusual for a CA to deliberately _wait_ before logging certificates, either they're logged more or less immediately or they don't intend to log them at all. To issue certificates with an SCT baked inside them (which is convenient for customers) you have to log a "pre-certificate" with the exact same details first anyway to get the SCT.
BUT if there's a problem the Mozilla trust store policy (and perhaps others, but only Mozilla's happens in public where we can see it) says the CA must show the trust store all the affected certificates. By far the easiest way to do that in 2017 is shove them all into a CT log and then spew a list of links to crt.sh or another monitor, rather than uploading some Word document full of X.509 PEM files or whatever. So even CAs that we know don't normally log everything will put all the problematic stuff into logs during disclosure, or else someone reading m.d.s.policy will do it for them.
Some CAs have a deliberate customer policy of letting you choose NOT to log, sometimes with a warning saying if you don't log this stuff then Google might distrust it. Symantec was really into redaction, which is logging but with the "sensitive" bits of the certificate removed. But Google never really bought that idea, and Symantec are exiting the CA business.
Once a certificate is submitted to the logs (which as mentioned elsewhere, Google wants to make mandatory, but today they only enforce for EV and only by treating as non-EV if it isn't logged) the log won't necessarily immediately tell monitors about that certificate. Accepting new items for the logs can be (and usually would be) parallelised, but the log structure is a single Merkle Tree and so cannot be calculated entirely in parallel, usually updating this structure is a serial operation that happens asynchronously, with the result available some time later.
A policy value called the Maximum Merge Delay decides how long a log has to get this done and produce a new head value for the log, Google has currently chosen 24 hours for logs to be accepted in Chrome. Once a log presents somebody with an SCT proving it logged a particular certificate, it has 24 hours to make a Merkle Tree with that cert in it available to the monitors. That sounds like a long time, but it's not "business hours" or "best effort" it's an absolute limit. Data Centre flooded by a tsunami? Too bad. OS upgrade is incompatible with your CPU model? Don't care. Some lunatic threw a billion dollars in bills out of an aeroplane and your employees are out collecting as much as they can carry? Not our problem. Usually you can expect the actual turnaround to be much less than 24 hours, if it's ever greater the log should be distrusted and shut down.
There have already been logs that had "problems" and went away for this reason. Because the logs are only useful if they obey the MMD Google is being pretty strict about this.
However, just because something is in one or more logs doesn't mean any monitor, including famous ones like crt.sh, or Google's own transparency site, has actually obtained and processed the log item right away. There can definitely be slowdowns in this part, but they're only a matter of throwing enough resources at the problem.