Strive for lofty goals

如何设定网络安全目标

恰逢半财年,又到了绩效目标设定的时候。上周给其他团队安全同事们分享了在网络安全运营指标制定的一些想法,得到了比较好的评价。想着整理下思路并分享出来,与各位探讨,不一定适用于每家公司,仅作为抛砖引玉希望能有一些帮助。由于时间仓促,如有错漏还请指出。

一个好的目标是事情成败的关键,在出现需要抉择的路口能指引我们朝着正确的方向去努力。

目标来自哪里?

首先我们需要解决目标来自哪里?很多情况下我们面临的问题是不明确的,老板的要求是不具体的,需要我们自己去寻找目标。

多数情况下,我们的目标来自于上级老板目标的拆解。要拆解老板的目标,首先得理解上级方向、目标和策略,找准自己团队的定位和独特价值。与主管对焦其目标背后的意图,同时也需要了解各个横向团队和上下游的的规划,以及回过头看看做完这些事情对实际关键风险能起到控制作用。

假设你是网络安全团队负责人,或者某个安全方向负责人,你该如何设定自己团队的目标。

在确定目标之前,需要回归初心,想想我所带领的团队到底扮演了什么样的角色?是在为谁服务?能发挥什么价值?目标设定第一原则是从客户价值出发对于安全团队来说,脱离风险的目标设定是一切灾难的源头。我见过太多安全团队其实在自娱自乐,原因在于多数公司老板是不懂安全的,安全的事情基本上安全负责人说了算,导致如果愿景和目标没想清楚就会出现所做的事情对实际风险控制没有太大帮助,一旦遇到针对性的高级威胁所有的工作形同虚设。

一旦目标错了后续一切都错了,因此在目标设定上多花些时间想清楚是值得的,此时的慢是为了后续的快。此外风险控制也只是安全团队最基础的事情,在此基础之上还需要考虑对业务的价值,这部分内容以后再展开讲。

设定安全目标

以应用安全团队为例,可以从风险角度出发,打开脑洞想一想我们期望将风险控制到什么程度。在此之前,我们需要先暂时抛弃行业的一些通用做法,惯性思维和先前经验,这些往往会将我们思想画地为牢。

假设目标是:

  • 没有漏洞?没有漏洞不太可能,我们知道有人写代码就会产生漏洞。
  • 有漏洞但不能被利用?安全本质是对抗,任何防护都有可能被绕过。
  • 有漏洞但都被我们发现了?发现必然存在风险敞口。
  • 有漏洞都被我们上线前发现了?发现意味着必然存在遗漏。很多企业安全体系建设会有类似“重检测,快响应”的指导思想,这类做法有其优势,安全团队自行即可做好,可不足之处也非常明显,存在遗漏和风险敞口。检测必然存在遗漏,上线后面向的往往是全世界的攻击者,你和他们是同一起跑线,比谁更先挖出漏洞。但上线前可以将整体风险敞口缩小至企业内。这其中的风险对于任何以结果出发的企业来讲都是不可接受的。
  • 不断的发现和修复好像也有问题?需要的让写出来的漏洞不断减少,所以规避好于发现。这里提到的是“规避”而非“发现”,“发现”代表的是上线前一部分工作,此外上线前还有诸如意识提升、安全防护组件等工作,“规避”更能体现这些工作期望达成的目标。

当通过上面的一次次的推敲后,会发现思路和路线逐渐清晰起来。此时可通过一句话直白的描述目标,这样大家就能一听就懂并且能快速记住:所有的安全风险在上线前高效规避,零软件安全风险能被利用。前半句是期望将风险规避在上线前,这和建设阶段相关,一旦风险上线后再去发现、感知、止血就必然存在遗漏和风险敞口,这对于风险敏感型企业是不可承受的,这是在引导后续的安全建设,为后续的安全建设指明方向。后半句是当有风险遗漏后也无法利用成功的,建设期间必然还是会有风险遗漏到线上,因此需要通过各种方法来解决各种遗漏的风险被利用的可能。这其实就是我们这个部门的愿景,是指引我们长期建设的方向。

我们需要根据企业实际的情况,围绕愿景确定短期目标。不同公司不同阶段距离这个愿景的差距也不一样,也许距离还很遥远,也许快接近了。在这里我们将其定为两个O,多数安全风险在上线前高效规避,极少软件安全风险可被利用。可以看到这个目标是很有挑战性的,但也能激发大家的斗志,通过各种创新的方式去达成。但要注意不能照搬上级的O或简单的对上级的O进行数字上的拆解。

这里可以看到目标有几个特性,用一句话清晰明确的体现客户价值,有挑战也有方向感,同时一层层拆解后的目标也有延续性。

接下来我将使用OKR(Objectives and Key Results,目标与关键结果)来描述目标设定,主要分为O(Objectives,目标)和KR(Key Results,关键结果)两步,O是指我们期望达成什么样的状态。KR是指哪些结果达成后能表明O完成了。

确定了目标后,需要进一步拆解当哪些情况达到了就说明目标完成了,也就是确定KR(Key Results,关键结果)。KR最重要的点是看这些都达成了是否就能支撑O的完成,需要拆分到最细粒度且可衡量,但并非事无巨细的罗列,另外描述上要清晰易懂,有过程和结果,符合SMART原则。同时不宜过多,建议不超过5个。

O:多数安全风险上线前高效规避

  • KR1:上线前高效发现绝大多数风险(上线前发现率>=NN%,自动化发现率>=NN%,公网接口评估率NN%,已发现风险0遗漏上线)
  • KR2:重难点风险攻克(水平越权上线前遗漏N,逻辑漏洞遗漏<=N)
  • KR3:整体漏洞趋势向好(千行代码漏洞率<=千分之N)

既然希望多数的安全风险上线前高效规避,首先多数风险应该是上线前被发现解决的,因此上线前漏洞发现率要有一个指标。但如果只有这个指标就会导致大量的人肉渗透测试工作,因此上线前的漏洞发现也需要自动化比例的。

在不同阶段将面对不同的风险类型,因此对于其中的重难点风险可以单拎出来专项跟进,比如水平越权。虽然水平越权的数据也会反映在上线前发现、自动化发现率指标上,但从目标达成上来看,拎出来能获得更好的效果。

整体风险都在上线前发现了,重难点风险也已经解决了,这还不够。这会导致陷入不断的漏洞发现、修复的循环,因此必须还要有一个正向指标来牵引,让漏洞越来越少。多数漏洞的产生都源自于写代码,那从整体来看相对新写出来的代码所产生的漏洞应该是相对的,因此可以使用千行代码漏洞率来看整体的漏洞趋势是否向好。

O:极少软件安全风险能被利用

  • KR1:绝大多数安全风险自主发现(自动化发现率>=NN%,可造成入侵、数据泄漏、资金损失的漏洞<=N),按时修复漏洞(修复率NNN%,修复时效达成率NNN%)
  • KR2:高频持续推动外部机构检验(举办N次SRC高倍奖励众测,N次外部顶级厂商攻击,主动参加各类攻防比赛)
  • KR3:及时全面应急Nday漏洞(应急平均时间<=Nh,应急遗漏次数<=N)
  • KR4:增强高危0day漏洞防护(RASP可信防护NNN%,禁外联NNN%,三方软件流量可信覆盖率>=NNN%,依赖包投毒遗漏<=N,外采应用高危漏洞N遗漏)

看完上线前,再看开上线后的。我们知道理论上必然存在各种遗漏到上线的风险,因此如何能保证风险上线了也无法被利用呢?

第一部分就是让多数风险都是自主发现并解决掉,也就是自主发现率。同时当漏洞比较多的时候,还应该设定遗漏漏洞的绝对值,对那些可造成入侵、数据泄漏、资金损失的漏洞要小于几个。

自主发现率是依赖外部人员挖掘漏洞的,那就有可能外部人员刚好没挖指标就躺着达成了。因此需要高频持续推动外部机构进行检验。可以通过举办多次SRC活动,并且根据建设阶段来设置高倍奖励来更大激发白帽子的兴趣。此外还可以通过购买外部顶级安全厂商的渗透测试和红蓝对抗服务。有条件的自己组建安全蓝军就更好了,同时各种免费的外部红蓝演练活动,比如各等级的HW要主动参与。

除了上面我们自己写出的代码产生的漏洞外,我们所使用的各类软件、框架、组件依赖包等都会产生漏洞,其中一部分各类平台会有预警和分析,我们需要做的是确保及时的发现这类情报,并排查影响范围、止血以及推动修复等工作。但情报的覆盖范围是有限的,一些安装依赖包时触发后门这类高风险并没有可靠的情报源,针对此部分可通过设定相关指标来牵引安全建设。

最后一部分是0day,这部分的防御确实很难,但始终要面对的。通过推动可信级的RASP覆盖所有应用来防止高危型的0day,并针对所有应用禁止回联外网,来缓解0day的风险。最后对于一些采购的三方软件,无法覆盖RASP,于是通过为其定制请求参数过滤,实现请求可信,来降低各类常见高危漏洞的防护,同时将这些外采应用都隔离起来,网络访问最小化,避免出现问题后影响范围扩大,并通过采购流程审批节点、非标机器申请等方式管控住增量的外采应用。

追求过程还是结果指标?

在制定KR时往往有一个误区,往往大家更多的在追求结果指标,而非过程指标。但实际情况时我们应该去定可以控制的指标,而不是结果指标。以上面提到的漏洞自主发现率为例,我们期望多数漏洞都是自己发现的,于是设定通过一个终极目标漏洞自主发现率作为KR来衡量安全漏洞发现工作的好坏。如果单单以这个作为最终指标,就可能产生对于外部发现的漏洞被低估或给的奖励少,甚至不主动举办安全众测活动。会发现影响这个指标的因素很多,也许我们什么都不做,也没有外部白帽子挖到我们漏洞,那指标也达成了。所以对于达成自主发现率那一定需要有支撑它的过程指标,我们会关注到底那些KR可以支撑自主发现率,比如公网每一个接口是否都进行了渗透测试、各类扫描器对公网漏洞是否都能及时有效的发现、每一次nday排查是否覆盖了所有公网应用、是否有邀请外部各种白帽子、安全公司进行高强度检验来验证最终效果等。所以我们应该关注驱动一件事情最核心的要素,而不是关注事情发生后的效果

OKR和KPI区别?

首先是OKR(Objectives and Key Results,目标与关键结果)与KPI(Key Performance Indicator,关键绩效指标)区别,这两个工具或者说方法论本质都是为了促进目标达成。其最大的区别在于是否为目标导向,在KPI的模式下,更加侧重的是对结果的考核,看最终的衡量指标是否达成了。这会导致一些问题,比如设置目标的时候要求没那么高、指标定的没那么合理,或是采取一些取巧的方式去达成,甚至使用一些损害用户价值的方式去实现,问一问自己,你能一句话说明白你的目标吗?你团队同学呢?多数人可能并不清楚。而OKR则是以目标为出发点,并通过对关键结果的描述来判断最终目标是否达成,它能够让全员参与逐级从上到下分解,也可以从下到上对焦。

举例来说,KPI有点像运动裁判,他会拿着秒表关注你最终的成绩。OKR有点像运动教练,也会关注你的成绩,但同时更加关注你的运动方式、运动强度、饮食作息等是否能支撑你拿到好的成绩。

听着好像是OKR比KPI要好,那为何之前阿里巴巴会使用KPI呢?大家都知道阿里的价值观,其中就有客户第一,以及对管理者的要求也会有客户价值优先的体现。也就是说在之前阿里依靠的是管理成熟度和文化价值观来驱动大家设立正确的KPI,但随着新进的管理者比例提高,管理成熟度变低的同时公司文化传递效率也存在问题,所以逐步通过OKR这类工具来支撑。同时也能够提升组织的运转效率。但有一点要说明,不同公司对于OKR的理解和实施都不太一样,阿里这边目前阶段更多的是通过OKR和KPI融合的方式,在这里我们不讨论怎么样最好,适合自己的才是最好的。

对焦目标

定好OKR后,还需要去持续与上下左右对焦。我们的OKR是否能有效的支撑上级的O。能影响我们OKR的相关方是否知道,需要谁的支持时我们OKR是否在对方OKR中。这其中对于直接参与OKR的人员需要就行宣讲,听得懂目标,记得住目标,同时对目标的理解一致,让每个人都能找到自己的位置,知道自己的职责和价值,让参与的人员知道目标达成后对公司的价值,能让我们的安全达到一个新的水位。

对焦完之后需要跟进好OKR,这就需要制定达成策略以及里程碑制定,确定一号位和各子域负责人,并持续跟踪,这部分内容后续另起文章展开来讲。

Strive for lofty goals
Loading