如何设定合理的安全工作指标
1. 指标和愿景、目标的联系
2. 指标要有明确的价值
3. 指标匹配现阶段工作重心
4. 指标要同整体规划一致
5. 指标必须是可衡量的
6. 指标要有反向验证手段
7. 指标并不一定要达成
8. 最重要的是指标要说人话
参考资料
如何设定合理的安全工作指标
你和你的团队是做什么的？产出是什么？实现路线是什么？怎么衡量做的好和坏？你在朝着什么方向前进？
设定指标能规划工作，衡量进展，防止出现工作偏差，但在年初工作中怎么制定一个合理的指标体系是个颇为头疼的事情，笔者以安全行业的特点做了一些阐述，希望可以同广大读者一起探讨交流。
愿景是团队的长期希望，为了实现伟大的愿景拆分了具体目标，达成目标需要用指标对各个子任务进行拆解量化产出。
**目标往往是一个预期结果，不是有效的指标，指标对了目标是自然会达成的，单独统计目标没有价值。**不要将目标等同于指标。
愿景和目标是指出工作的整体的方向，而且愿景和目标在指标统计周期并不一定会达成。如果首先混淆了愿景、目标和指标三者的关系，那么指标设定的逻辑出发点就会被质疑，接下来思考都是错的。
举个例子，Google安全的整体愿景是"让用户使用互联网更安全"，Google Project Zero的目标是"让攻击者更难发现和利用安全漏洞"，那么具体团队的技术指标会是高危漏洞发现数，修复率、平均修复时间、漏洞挖掘产品覆盖率等。Google Project Zero设定的量化指标不会包含"攻击者漏洞利用时间和成本是否增加"这一项。
再举个例子，如果安全团队的愿景是"做国内领先的安全团队"，目标是"不出现颠覆性的安全风险"，指标应该是完成Hvv任务、严重安全漏洞及时止损、规则覆盖率xx%等。当然团队的目标也可以设定为"顺利完成hvv任务"，那么也可以有对应的细分指标为这个目标服务，而不是直接将"顺利完成hvv任务"放在指标项中。
指标的设定以目标为前提，必须以明确的结果为导向，而不是描述过程行为，指标**"以终为始"，做正确的事，而不是正确的做事。**
比如在设定指标要有明确有达成、改善、降低、提升的判断，而不是使用解决、参与、负责、上线，覆盖这样的模糊的、过程性的描述字眼。
比如一项指标的是"第三方组件扫描率80%"，完成了又如何呢？那你应该达到多少呢？为什么不是79%，为什么不是81%呢？这件事的意义应该是"引入开源组件风险得到显著降低"，一定要说清指标背后带来的安全效果。
为了体现技术和专业能力在不同时期的提升，指标在不同场景下要侧重实际状况。
同一个安全工作，从分工方面要区分安全开发、安全治理、安全运维等侧重点，做运营的指标不要和做开发的指标放在一起，虽然大家是为了处理一样的安全风险。
同一个安全工作，指标要和不同发展阶段的工作相结合：刚起步的工作在于调查研究，摸清状况，探索实践；常态化运营的工作在于优化流程，保证效果，数据积累。切忌贪大求全眉毛胡子一把抓最后都做不完。
同一个安全工作，对于不同职能团队是有倾斜的。比如常用的一个指标--漏洞修复延期率，实际情况是业务不修你也没有办法，业务团队的指标不包括你的安全业绩，这时候要把和业务相关的和安全自己做的事情拆分开来，不然写个你基本无法掌控的一个指标，没法对结果负责。
**各小团队的指标导向要为整体大目标服务。**如果今年安全部门的战略是"迁移上云的安全防护"，那么工作重心要向云相关的整体指标倾斜。如果主题是"降本增效"，那么要体现通过技术实现能效提升等关键动作。
举个反向的例子，如果部门的目标是"尽快搭建安全团队，完成安全防护"，你的指标里却有一项是"节约xx成本"，谁让你省钱来着？？！这是个与规划背离的指标。
将安全作为一门科学，有量化才能有改进。"好"，"坏"，"高中低","达成"都是虚词，指标要有数据量化，可是有些指标确实难以量化怎么办呢？把不能量化的量化也是一种能力。运营型的通过合理的周、月、季度周期自动化统计，建设型的通过项目管理指标量化。
量化的分子分母要准确，分母找全才能说明结果的正确性。举个简单的例子：职场电脑杀毒软件覆盖率100%，看起来挺好的，但是细问起来这里的职场是否包括外包场地？答案是没包括，为什么没包括？没意识到或者没法统计，这样就因为视野盲区设定了一个虚假的分母，对完成工作是有损害的。
量化不仅仅需要百分比，也需要绝对数量。举个例子：WAF的接入率为100%，但是实际只有10个域名接入了，其他域名排除在计划中，如果这里分母实际是公司的全量域名才比较合理。
**通过寻找反向指标来验证事情做得好和坏。**反向指标有时候很难找到，找不到就算了，在寻找反向指标的时候可以加深对做事的理解。
举个例子:SDL团队的漏洞发现率应该和SRC运营的外部漏洞提交数互为反向指标。如果SRC没有高危漏洞提交，不能说明漏洞扫描修复做得好，也许是运营投入不给力，吸引不到优秀的黑客发现风险。反过来如果SRC收到了大量的高危漏洞，并不能说明SRC运营给力，而是SDL没有关注此类风险。
一个比较极端的例子是，安全讲师要达成"安全意识考试合格率"，那么蓝军要有"经过培训后攻击成功率"指标，显示经过安全培训的人员，仍然可以被蓝军用高超的社工技术欺骗。这个案例太卷了现实估计没有，本质是为了剖析真实的原因，持续改进团队整体工作。
寻找反向指标时一个常见的错误是采取同一个团队的同一份数据源。比如做弱口令治理，用hydra通过采集的密码字典收敛弱口令，设定修复率100%。这个合理的反向指标不能选取未来hydra还能不能复查出来，要换个技术手段，比如域控弱口令审计策略、红蓝演练之类的数据源。
不论是OKR还是KPI，指标的锚点是目标，目标一般采取SMART原则--Specific（明确）、Measurable（可衡量）、Achievable（可达成）、Relevant（相关）和Time-bound（有时限）制定。本身已经涵盖设定有挑战的的目标，如果指标都轻易达成了，说明当初目标设定不合理-过低或者过高。指标完不成也是正常的。
当然实际情况是在绩效考核的时候，你能达成就更好了，可以在指标模板加一列标注该指标属于承诺型还是期望型。
**如果一件事情不能简单说清楚，那么说明你没有想清楚。**我们制定的指标看起来要有审美的能力，衡量指标好坏的标准在于是否优雅简洁。花里胡哨列了复杂的数学统计公式不是做数学题，拿出来一两个关键指标就行，其他的都是辅助数据说明逻辑正确。
说人话的另一个好处是指标并不仅仅给技术同学看，给CISO、合作方汇报的时候，可以清晰明白安全整体是什么水位，重点在关注什么。
