我认为这是一种错误的二分法，您的 CSO 很愚蠢。

虽然我喜欢愚蠢，但安全部门应该推动风险缓解。在“责任”领域争吵显然没有成效，尽管它可能符合一般的企业文化。

虽然有多种方式来限定安全领域及其责任——中央情报局三合会就是其中之一，但还有其他方式——一个成熟、负责任的 CSO 至少会推动解决方案。

我听说有人说“安全风险”和“操作风险”之间的区别在于是否存在潜在的威胁行为者，或者仅仅是意外或误用。
虽然这确实很有意义，但我认为更务实的方法是简单地接受两者之间存在大量重叠 - 这只是意味着有更多资源可以解决这个问题，而不是每个人都可以放弃责任.

也就是说 - 在这种特定情况下，我建议的流程是让 CSO（或他部门的技术人员）推动缓解程序，定义风险级别框架等 - 然后将其交给运营部门实施拟合解决方案。也许安全人员可以推荐一个解决方案，或者他们应该只定义解决方案应该满足的指标，这取决于团队的技术/动手能力。

通过这种方式，公司可以处理这样一个事实：虽然风险是安全风险，但解决方案是运营风险。

虽然我通常不同意 CSO，但我可以看到他画这条线的原因。

问题可以归结为界定谁需要领导缓解和补救工作。当然，DDoS 确实会影响可用性，但通常由运营团队处理。如果发生 DDoS 事件，您的 CSO 可能会觉得他无能为力，并希望另一方负责。换句话说，不要在 DDoS 发生时在凌晨 2 点给 CSO 打电话，而是在凌晨 2 点有漏洞时给他打电话。

考虑 CIA 三合会的范围。每个 CSO 都应该最终负责服务器机房的设施消防和安全系统吗？火灾也是可用性风险。但是，在某些组织中，该责任应该落在设施经理而不是 CSO 身上（尽管 CSO 也应该在这方面有所帮助。）在与上述类似的情况下，如果火警在凌晨 2 点响起，请致电设施经理，而不是 CSO。您的 CSO 可能会划清界限，将火灾和 DDoS 等同于对组织构成的风险。

也就是说，DDoS 事件也有可能分散注意力或利用更广泛的安全攻击，所以我相信 CSO 仍然需要在某种程度上参与。

所以严格来说，你的评估是正确的，我一般同意你的看法，但这可能归结为对角色定义和可用资源的不同理解。

由于上述三元组，DDoS 攻击分为操作和安全类别。然而，安全人员往往更了解攻击，因此像 AviD 表示，安全团队和 IT 团队之间应该进行沟通以解决问题，而不是浪费数小时涵盖可以通过 10 分钟电话解决的研究。

从技术、1 和 0 的角度来看，他是正确的，但安全威胁的“可接受范围”包括可用性。但是，所有公司都可以自由分配他们认为合适的职责，因此您的 CSO 可能只是说明了一个观点，即减轻该特定风险不是他的责任。