1. Disclose the incident ASAP, even before all facts are known. The disclosure doesn't need to have any action items, and in this case, didn't
2. Add more details as investigation proceeds, even before it fully finishes to help clarify scope
The proactive communication and transparency could have downsides (causing undue panic), but I think these posts have presented a sense that they have it mostly under control. Of course, this is only possible because they, unlike some other companies, probably do have a good security team who caught this early.
I expect the next (or perhaps the 4th) post will be a fuller post-mortem from after the incident. This series of disclosures has given me more confidence in Stackoverflow than I had before!
We only get very superficial information by one of the rare companies that could typically contribute and help the community by sharing what really went wrong.
Right now, I'm in a situation that forces me to speculate (in addition to reading all the speculation comments below) on whether or not I could do the same mistake than SO did, and that terribly saddens me.
Might not be fair to judge the overall response yet. If full details of the problem were expected upon initial disclosure, then they wouldn't be able to do prompt disclosure.
Of course, this is based on nothing but wild guesswork and it could be just coincidence. But in their shoes, I would really want to make sure no one else gained access and did anything more to hide their tracks, since it seemed like such a quickly found exploit.
> The intrusion originated on May 5 when a build deployed to the development tier for stackoverflow.com contained a bug, which allowed an attacker to log in to our development tier as well as escalate their access on the production version of stackoverflow.com.
> Between May 5 and May 11, the intruder contained their activities to exploration
To me, that reads "we deployed a bug on May 5th that allowed intrusion, and it was exploited the same day." If that's not what they meant - I certainly recant my criticism - but "on May 5th when a build deployed contained a bug" is difficult for me to interpret differently.
I share your curiosity :)
(Even if I'm right, though, I definitely agree that the wording is very easy to misinterpret and they should clarify the post to explain what the "development tier" is.)
Should dev not be sandboxed from production?
"The intrusion originated on May 5 when a build deployed to the development tier for stackoverflow.com contained a bug, which allowed an attacker to log in to our development tier as well as escalate their access on the production version of stackoverflow.com.
Why are the credentials for production granted to development systems?
I sure wish more companies did this. Such peace of mind.
Stack Overflow seem to be following a very responsible incident response procedure, perhaps instituted by their new VP of Engineering (the author of the OP). It is nice to see.
Also, what User table are you looking at? The one I'm looking at only has these fields: Reputation, CreationDate, DisplayName, LastAccessDate, WebsiteUrl, Location, AboutMe, Views, UpVotes, DownVotes, ProfileImageUrl, EmailHash, AccountId
This was their post for context: "API reports is_employee as False, but the user is not on mod lists, so... ?"
Some recognition would have been nice instead of saying "we" quickly found out.