网络安全领域20种最差劲指标

weixq

安全主管可以根据各项指标作出决策，只要指标不属于以下糟糕指标范畴即可。
; _7 F6 g% F$ w3 S, g6 j$ Q; e/ w
3 Z2 B9 o" S8 h( N2 A8 o8 B+ B

  Z$ d8 s% n3 c
网络安全权威人士苦心规劝十来年之后，CISO 需从业务角度以数据说话的理念终于深入人心，各项测量指标意识最终确立。无论是合理化开支、量化风险，还是争取高管支持安全运营，CISO 的讨论中如今满是仪表板、图表和关键业绩指标 (KPI)。唯一的问题是什么呢？安全团队及其主管使用的大量数据，其实，并不十分有用。

5 {5 h3 B1 o: ]; C5 X
$ [2 J6 u' `$ y7 C, W. w8 E) Q事实上，很多测量出来的数据都是无用指标，没有上下文，数据量大，且缺少分析，还往往测得错误的观察项而无法获悉真正的风险。Edge 最近向业内多位安全专家咨询了他们最不喜欢的指标都有哪些，结果，专家们列出来的清单有点长。下面 20 条就是日夜与安全为伍的专业人士给出的网络安全领域最糟糕指标。
, Q: q, g* d( f5 w

4 _! Y1 i0 }5 Z1 d1. 太过复杂的指标

8 P. _$ C+ j+ K- M

Cobalt.io 首席策略官 Caroline Wong 表示，在你拿出依托复杂计算模型的安全指标前，无论该指标是 FAIR 这种正式的东西，还是你内部使用的客户安全评分，你都得考虑你的受众对该指标背后计算模型的熟悉或不熟悉程度。如果受众不熟悉你得出该指标的方法，你会发现自己更忙于解释和捍卫自己方法的正确性，而不是讨论该安全指标本身、其含义，以及你建议的相应操作。
0 R9 M+ C7 y2 W0 D

& H' w% L& X6 a8 y6 ~" P
2. 震慑型指标

# H* K- H( u9 O. o
; P6 k: N  a$ _7 S
震慑型指标就数字让你大吃一惊的那种。比如：有 23,456 个未修复漏洞。但数字本身并没有上下文或风险考虑。
4 ]. q: s- f  b% J4 w% ^, X

Optiv CISO Brain Wrozek 表示，这数字是好是坏，是正常还是意外，上升还是下降？漏洞是新是旧？漏洞在高价值资产还是低价值资产上？是少量资产上的很多漏洞，还是很多资产上的少量漏洞？所有这些上下文表征都很重要。但不幸的是，太多这种耸人听闻的安全统计数据都缺乏上下文。

% L5 D0 r- B- K/ M1 T
" {# {$ f- Q" }" H% P3. 质性指标

" s2 H5 n; i- |& [: w6 y
% q; P" j5 c) \; X/ z& F! n5 e
, s% s: ?! M. U" I$ |Fractional 创始人、高管、CISO Rob Black 表示，质性指标就是正确组织行为的拦路虎。很多企业都将风险划分为高、中、低三级。各个方面上看这么做都错了。

4 [5 ~- `8 Q! w5 p& V# F- u0 v
* n7 |! G8 n' c! |! Z3 D% v“
财政部门就永远不会说这个项目我们需要 ‘大量’ 资金支持。他们会给出一个具体数额。网络安全人员也应该这么做。尝试获得‘中等’保障什么的。这种质性指标对其他业务线完全没意义。安全部门不应该用质性指标。质性指标应该像肘尺那样扔进历史的垃圾桶！
6 O& E3 h) N4 i9 J

0 t" y8 n: z6 x9 O1 f& P4. 一个攻击风险指标走天下
+ e5 q9 k8 q+ X# A
; b$ D# E+ s/ F& r  X

% f7 D" }) X) D0 L5 dVerodin CISO Brian Contos 表示，面对攻击我们有多安全？每当我看到用单一指标回答此类问题，我都想要退避三舍，因为该指标通常由已发现漏洞和已修复漏洞数量计算得出。这个指标能很好地描述你的漏洞修复工作成效，当然，漏洞是必须修复的。但这个指标并不能真正描述你面对攻击的安全程度。


“
安全程度应由细分为多个方面的 [指标衡量]，比如：我的网络、终端、电子邮件和云安全工具有效性如何？我的托管安全服务提供商 (MSSP) 有多遵守他们的服务水平协议 (SLA)？我的安全团队事件响应有效性有多高？安全团队遵循的各项过程有效程度如何？
. B" M/ J. Y- h0 d

8 M  @# i) }' |7 m# Q8 \1 l5. 安全项目增长
# Z; ?6 o# ?8 |0 {% {

. a' f! q& i/ l. P) K) A' f2 EZeroNorth 创始人兼总裁 Ernesto DiGiambattista 表示，人员、应用和工具的增长常被认为是成功的表现，但这种评价方式是有缺陷的，因为数量增加未必等同于安全状况改善。更重要的考虑是安全项目空白的填补程度，而这常常是通过现有人员和工具实现的。当然，某些领域里增长可能是必要的，但仅这一个指标显然不能衡量成功与否。
; J  |% K6 y8 S" B! @8 n

6. 基于 CVSS 的风险评分

& u. N- l3 b$ T: C" m" d

5 v( `# k9 q# C8 @. xKenna Security 首席数据科学家 Michael Roytman 表示，仅一小部分漏洞被恶意黑客利用，但 CVSS 得分并没有反映出这一事实。CVSS 得分没考虑漏洞的普遍程度和已知漏洞利用的公开可用性。基本上，CVSS 就没将漏洞被用于黑客攻击的可能性或威胁纳入考虑，但仍有很多公司将之作为漏洞修复工作的唯一指引。
. T0 a5 t4 a' H* M2 Q
/ s. Z. c/ ?  U; u) _8 r
“
# _9 p* y* Q# I) W. \# A 安全团队评估哪些漏洞需首先修复时，除 CVSS 之外还应考虑这些漏洞被利用的概率。


. c, p6 q! ]) \5 `1 M3 A3 q7. 能力成熟度模型集成 (CMMI) 得分


' H7 \" B, a/ ~, e, l2 ]
FRSecure 专业服务与创新总监 Brad Nigh 表示，公司企业常将 CMMI 看作其安全项目各部分成熟程度的分类标签。CMMI 关注有利于尽可能不中断过程/项目地引入新员工的过程和文档。CMMI 得分的问题在于，并没有考虑到企业所拥有的资产的价值。
" u( Q# ?+ z; p9 r7 s' K
' B' t+ M5 M4 O/ e( k: f, y6 i$ X
7 w& x; m0 U1 |# ?因此，得出的是虚假的安全感，是仅仅因为过程平滑就认为安全的假定，没有考虑到这些过程是否适用于自身环境，是否解决了自己最大的风险/漏洞。


8. 平均检测/响应时间
7 M% u- b5 C* {( y' o2 e
( q% f7 \& s/ L8 i' n2 P
+ r. ~0 ^2 [( f" T
  A3 `5 n2 K0 ^! mCriticalStart CTO Randy Watkins 表示，多数企业将均检测时间 (MTTD) 和平均响应时间 (MTTR) 视为网络安全警报调查的实际指标。问题出在‘平均’响应时间的衡量上。根据实际需要响应的警报数量，只看平均时间可能会给入侵分类可用时间设置人为上限。


6 O1 z* F# x' l# K8 V: `6 C3 ~, c为考虑进分类和响应耗时较长的调查，可以选择计算中位检测时间。剔除时间线两端的奇点可以获得安全团队响应效能的准确视图。



, \) V6 \5 X, e6 R2 w' G9. 完成培训的员工占比
9 o, O: X) V- k1 L
! y' V3 k( U- u5 p7 x  _4 c  S
Altitude Networks 共同创始人兼 CEO Micheal Coates 表示，完成安全培训的员工占比是个伪指标，只会带来对安全态势和企业弹性的虚假安全感。安全意识是个不可或缺的好东西。但如果企业仅仅因为接受年度培训的员工占比高就对自身安全意识盲目自信，那可真是完全看错了方向。
4 B9 T) o$ P  A( v0 i

% L' r% e& V. v7 c10. 被泄记录数量
/ ~$ [) [4 B. U/ |9 n

# [# y0 b+ [$ m2 i- ]Contrast Security 共同创始人兼 CTO Jeff Williams 表示，被泄记录数量是公司和个人理解数据泄露严重性的一个非常糟糕的方式。黑客不泄露任何一条‘记录’也可以完全接管公司所有服务器，清空公司账户，摧毁所有记录。

" ~- d$ @+ J$ [" n+ |
' e0 k) K9 x; U' O. p& \) U11. 平均故障时间



SecurityFirst 首席产品及策略官 Pankaj Parekh 表示，这个指标很具误导性，因为现代复杂数据中心里，单个组件常会故障。衡量基础设施容错能力和弹性要有意义得多，这样即便哪个部分故障了，整个数据中心运营也不受影响。Netflix 在 2011 年构建的‘混世魔猴 (Chaos Monkey)’就是通过随机禁用某个服务器，来验证各个系统的健壮性，确保整体系统能挺过混乱情况。
  h. O$ d. o" f5 [* [  w

12. 安全控制措施封堵的威胁数量
8 o0 A% ~/ M7 w- V- U" ~- h3 s
  q; J2 [+ e5 V, X- Y3 Q
) ~" m  P- G, y
6 Q+ k+ P9 z; Y6 V) @0 a4 nDigital Guardian 网络安全副总裁 Tim Bandos 表示，向董事会报告称各项安全控制措施将千千万万个威胁封堵在边界防火墙之外固然听起来很有成就感，但实际上这可谓是最糟糕的指标了。这东西根本是在传达有关网络安全项目有效性的错误信息，并未真正衡量公司面对实际威胁的弹性，比如勒索软件或国家支持的网络攻击。



“
" p3 m0 C5 I* u 在我看来，更好的指标是从初始感染到检测的平均周期时间，或者平复成功威胁的耗时，毕竟，他们总会侵入的。


13. 漏洞数量



SecureAuth 策略研究总监 Martin Gallo 表示，常见无效指标样例之一是去数影响应用、系统或网络的漏洞数量，然后以之评判系统安全程度。漏洞数量当然很重要，但仅仅数出问题数量而不考虑潜在影响和漏洞被利用的概率，那就是奔着糟糕风险管理去了。
7 E+ k6 p6 `7 |7 y0 Y; ^6 ~

/ d% A1 X, b! F- v7 G类似的，公司资产关键程度有别，有些资产就是比别的资产重要。对最重要资产和不那么重要的资产都应用同样的指标，可能导致混乱，也产生不了什么特别的动作。

2 ~1 E, J9 g; R2 z3 I( c
/ ]  l( P+ C; J8 ?: ~) ~3 u
14. 网络钓鱼链接点击率
9 X$ q/ X; _$ h/ Q9 S5 Q


- M5 t- f/ r0 D1 B" Y" D' _Barracuda Networks 安全意识副总裁 Dennis Dillman 表示， 虽然降低网络钓鱼链接点击率看起来像是用户意识项目投资回报率 (ROI) 的良好体现，但不应作为公司培训项目的主要关注点。关注重点全放在降低点击率上时，管理员倾向于向用户重复发送非常相似的网络钓鱼邮件。这种重复能教会用户识别鱼叉式网络钓鱼攻击，但并不能使用户做好准备应对可能遭遇的各种攻击。
3 H& \6 z9 u: _; T- r; j' l
: V7 ?  o5 M2 m# @6 V. O
7 |5 x) Y1 v2 }/ R/ V- ?
需要注意的重要指标不止点击率一个。想更好地评估培训项目有效性，可以看有多少人在假冒登录页面上输入了凭证，多少人回复了你的模拟钓鱼，IT 团队收到了多少可疑电子邮件报告。
0 f- t+ C; ~/ ~# o7 v) B% |
5 h: X% I( Z7 d" H, b+ I( k8 D& f) u
; O' A: E0 ]3 X( ^" N# ^15. 漏洞修复天数

3 O+ f4 c' C2 Q+ {
8 a/ b, Q% O9 G
XM Cyber 产品副总裁 Menacem Shafran 表示，很多公司里，漏洞修复天数都是非常基础和常用的指标。因为很容易用漏洞扫描器获得。大部分企业会跟踪自身修复漏洞所需时长，无论是整体耗时还是按 CVSS 风险得分和资产分组得出的耗时。问题是，这个指标并不能真正反映出公司当前风险。非关键资产上的低风险评分漏洞也是可以助黑客染指更为重要的资产的。
0 H% M+ U- a: z" k) C( U, X) B

. |( a: r2 J' W9 i: R, Q3 l16. 处理事件数
! h2 h& S6 T' u3 g  V
4 W  q# j0 W( C8 Q4 o# p

# h+ R8 o- X9 Q/ E) P! X( XSiemplify 首席策略官 Nimmy Reichenberg 表示，说到安全运营，我最不喜欢的无用指标是 “处理事件数”。这个指标是典型的报告 “忙碌情况” 而不是 “业务情况”。处理事件数未能具现化 SecOps 在理解真正需处理事件上的有效性，呈现不了处理关键事件以减少威胁驻留时间的效率，反映不出自动排除误报以减少需处理事件数量的功效。
: t2 ]+ c! a8 g: j+ m


- a. @, W+ J" p- V2 _& S! H17. 每员工缓解事件数


- f2 C: Q3 n9 \9 k: h
DivvyCloud 共同创始人兼 CTO Chris DeRamus 表示，另一个无用指标是跟踪每个员工所缓解的事件数量。当今网络安全态势下，公司面临的活跃威胁数量动辄上百万。同样地，在如此庞大的威胁与漏洞数量面前，每员工能缓解的事件数量毫无意义，即使最有经验、技术最精湛的安全从业人员也无济于事。

5 n  u6 C" D6 @1 z; V& C
$ l. f+ S9 m- B+ f仅靠人力不可能实时追踪所有活跃威胁并缓解全部安全事件，所以公司企业不应该在这些指标上浪费自身时间。
. T* y) u% N& }$ `2 i6 A7 r

% ~& s( x2 ~0 d
18. 事件开放时间/完结时间



Capgemini 首席安全官兼策略主管 Joe McMann 表示，特别令人生气的一个指标是 “事件完结时长”，这个指标太含混不清了，变数很多，有太多依赖关系。安全运营的目标不应该是尽可能快地了结任务处理请求，好让请求队列保持为空；安全运营中心不是客服中心。


* W9 u# D9 B9 {: `' R% k作为企业防御者，我们的真正目标应该是有效响应、完整且深入的分析，以及利用所学构建更主动的防御态势。我想要衡量枚举整个进攻生命周期的能力，想确信该分析产生了新的特征码、检测或缓解。



& ]" N9 `0 I: _9 t19. 安全项目控制覆盖百分比
! x; R5 V. Q+ e% r4 @! Q+ T8 z


Cybersecurity GRC 创始人表示，策略中安全项目控制覆盖的百分比是一柄双刃剑。确保策略全面且覆盖安全项目中的控制措施很重要，所以这里并不是要贬低该指标的重要性。

! _2 h( t8 S0 n' t2 C$ R. x6 J% n% N
但只有理解且遵循了的策略才能减少公司风险，所以还需要另一个相应的指标来衡量员工对策略的理解程度——审查后测试知识，以及/或评估策略遵从度。
- K& y. F& `) }

' d0 R: T+ c% z" M& \& j20. 分析师待处理工单
6 g1 _  L$ L' J" q4 P
# p8 w' M' M: t% q8 T9 u

Respond Sofware 客户成功副总裁 Chris Triolo 表示，我们讨厌这个，这就是在比谁更快了结工单，而不是分析并修复，或确保不出现问题。这是典型的 “衡量即完成” 问题。

* V. N$ ?" @5 a6 }# \

$ t3 L- D4 l$ M/ Q- @$ x“
* I2 ^! O* z6 K! K4 ?: o 如果我们衡量已关闭工单的数量，你要么得到大量已处理工单，要么衡量内含真正需缓解事件的工单数量，但是分析和修复的质量才是有价值的指标。


2 j4 S% J+ Y0 O8 [3 z9 U
相关阅读
  r  A2 |1 b' x* @6 { 业务驱动安全：安全人员应当了解的7个业务指标
" ^% \% B! c! G6 |0 O9 a' _& |让业务与安全贴合：适应业务需求的网络安全指标
8 s7 N* d$ M9 y+ q0 ^. A+ K


# h& d* S: w% K2 s


" d( O0 ?* d$ |$ \' J9 s. B9 V来源：http://mp.weixin.qq.com/s?src=11&timestamp=1569742205&ver=1881&signature=vs-6AGu3V-GfvFB7GAOCgKCxLb7b5ClRh1F3CcnTqQRUlHx9GgcuFrD*x75lGZPMGK9YSRrHSLVePIZJLqQOitUNKmFSBhbZunLCJUrx6q3AOj6GLYgT8XBttLo3xuMy&new=1
& I0 T# S2 G3 ]! l! {* l免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！