3 ms·

I don't know who this Wolf guy is, but he's absolutely right: if we are in the government, and we have a breach, and we're working on it, we have an obligation

I don't know who this Wolf guy is, but he's absolutely right: if we are in the government, and we have a breach, and we're working on it, we have an obligation to fess up. (Unless there's some kind of counter-intelligence operations underway) We can all sit back in our comfy chairs and debate whether it really is China or not, whether various networks are secure or not, or how much various agencies can store (and the dangers associated with them storing things). But we can only do that if we have recent and valid information about what's going on. Good public policy decisions depend on an informed electorate. This kind of situation is not the place to be covering up your mistakes.

neolefty 12y ago
I think you're right that an open attitude towards security breaches is essential for a healthy security ecosystem. However, in practice, fessing up in public during an investigation will rarely happen. Security incident responses are some of the most-hushed processes, even inside otherwise open organizations. That's because you want to find and close the vulnerabilities before publicizing them. Otherwise, by publicizing, you invite attacks that will (a) multiply the noise you have to sift through to complete the investigation and (b) potentially create new incidents, at a time when you are already in a crisis (the current attack & investigation). So most security departments will only talk about what happened after the fact, when it's all been tidied up again. But even then, the habit of secrecy has already been established. It's a constant struggle to bring openness to a process where secrecy is a short-term advantage. If you want an informative accounting of what happened, I think you need to add it to the incident response process. For example (simplified for illustration) 1. Notice an intrusion 2. Capture information (logs, vulnerabilities used, etc) 3. Secure systems that have been compromised 4. Prevent future intrusions within the organization Need to modify 4 (or add 5) 5. Publish to help other orgs also prevent intrusions. But other orgs may hate you for that, because in the process of publishing, you have exposed their lax practices that (in hindsight) used to be your lax practices ...

neolefty 12y ago

I think you're right that an open attitude towards security breaches is essential for a healthy security ecosystem. However, in practice, fessing up in public during an investigation will rarely happen. Security incident responses are some of the most-hushed processes, even inside otherwise open organizations. That's because you want to find and close the vulnerabilities before publicizing them. Otherwise, by publicizing, you invite attacks that will (a) multiply the noise you have to sift through to complete the investigation and (b) potentially create new incidents, at a time when you are already in a crisis (the current attack & investigation). So most security departments will only talk about what happened after the fact, when it's all been tidied up again. But even then, the habit of secrecy has already been established. It's a constant struggle to bring openness to a process where secrecy is a short-term advantage. If you want an informative accounting of what happened, I think you need to add it to the incident response process. For example (simplified for illustration) 1. Notice an intrusion 2. Capture information (logs, vulnerabilities used, etc) 3. Secure systems that have been compromised 4. Prevent future intrusions within the organization Need to modify 4 (or add 5) 5. Publish to help other orgs also prevent intrusions. But other orgs may hate you for that, because in the process of publishing, you have exposed their lax practices that (in hindsight) used to be your lax practices ...