公司网络安全 企业网络安全之安全管理体系

教程列表见微信微信官方账号底部菜单

安全管理体系类似于项目管理的PMBOK，本质上是一个方法论和参考维度，涵盖了一个组织的所有技术活动和整个生命周期。从高层管理的角度来看，它仍然属于组织技术活动的方法，仍然被视为“技术活动”。

安全管理体系是一个随着业务的扩大而逐步完善的过程，并不是一个大而全的安全体系一形成就有的。另一方面，也与组织文化有关。在松散的非流程组织中过度强调管理措施也会遇到冲突行为。

过去管理咨询服务通常是这样的。涵盖ISO27001的ISMS对大多数组织来说已经足够了。但是咨询服务的问题可能和麦肯锡的咨询类似，理论是正确的。但是，本土化需要一个因地制宜的过程。另一方面，国际标准代表了普遍适用情况下的最佳做法，而不是特定情况下的最佳做法。因此，企业在认为自己已经部分进入了某个领域的最佳实践时，可以扔掉那些参考文献。这并不是说对国际标准一无所知的人可以嗤之以鼻，而只是对跨过那道坎的人有实际意义。

1、相对“全集”

其实这里说的全集不是全集，是相对的，部分的集合。真正意义上的全套是指很多国际标准和最佳做法，太复杂，太庞大，安全管理新手很容易掉海里找不到出路。曾经看到一家大公司在讲安防系统，可能是怕读者觉得他水平不够高，所以设置了很多高大的模型，但是很多类别在实际工作中是不会碰的。所以下图是从安全功能的角度来看平时做什么，不常用或者更高级别的IT治理的内容就不列了。如图1所示。

图1全套网络安全

几个大工厂都用SDL模式，但这里不直接引用SDL。他们还是以ITIL+SDL+SAMM为骨架，尽可能的结合公司研发和运输整合的价值链流程，同时在不同维度上体现安全做什么。

当然，还有很多内容遗漏了，比如供应链安全、对外开放与合作等。

2.组织

对于一个相对较小的安全团队来说，其实并不需要严格的划分，甚至不需要引入过于复杂的团队管理。进一步发展到20人的规模后，可能需要做一些简单的工作分类。对于比较大的公司和平台，安全团队也比较大，一般分为两个团队:一个团队从事传统领域的攻防对抗，另一个团队从事偏向业务安全的“风险控制”。图2只是作为组织划分的一个例子，现实中未必如此。

图2大型安全部门组织结构图示例

当安全团队发展到一定规模，就会有一些变化。团队小的时候基本以安全本身为主，大部分都是纯安全的人。当达到一定规模，比如自己的安全产品运营，就需要支持。安全团队本身会介绍产品经理、开发、DBA等各种职能的人。，让它看起来像一个业务线。从本质上来说，风险控制是一种商业智能类型的业务，它自然包括各种功能，如R&D、项目管理、软件和后台手动审计。它不再是传统意义上由人员组成的小型安全车间，对团队管理者的要求将远远超过安全本身。最好是集安全、R&D和愿景于一体的全球技术经理。理解和不理解建筑都会很累，反之亦然。

参与安全产品自我研究的团队可以是独立的，也可以分为应用安全和架构安全两个分支。例如，Web和WAF R&D可以归为一组，负责发现问题和捍卫产品，以及继承知识和思想。

从团队规模来看，国内最大的两家公司阿里和腾讯的安全团队约为2000人。两家公司员工总数都在3万以上，安全技术人员约占7%。在安全系统中，业务安全和风险控制团队通常是前者的两倍多。有关安全团队规模和业务增长之间的适应性比率，请参见表1。

表1安全团队规模与业务适应性的比率

事实上，安全团队的规模不能仅仅用IDC的规模来衡量，还与业务的复杂程度有很大的关系。有许多同类业务，例如，如果一个产品上运行10万个站点，那么安全支持团队不一定需要这么多人。如果是弱账户系统，业务痛苦不大，风险控制团队规模可以大大缩小，具体看应用场景。

3、关键绩效指标

对于安全性这个不直接产生利润的功能来说，其KPI度量一直是行业内的难题，就像这类工作不能简单的通过代码行数和单位时间的费率来评价一个人的能力输出一样。业内有类似IT平衡计分卡这样的工具，提供了高纬度的参考，如图3所示。

图3信息技术平衡记分卡

将信息技术部门映射到安全部门是安全经理需要考虑的问题。从“IT用户满意度”来看，主要有两个客户，一个内部客户，一个外部客户。内部客户是使用和依赖安全功能的兄弟部门，例如业务线、R&D和其他功能。是否能得到安全团队的优质支持，尽量不降低自己的工作效率，比如使用安全部门提供的安全产品，对业务系统的性能影响非常小，访问和变更在业务端都处于“非感知”状态，以免扫描时出现性能峰值，升级变更时出现断网。其实每个部门都隐含着一个心理，就是我在获得安全能力的时候不需要付出太多.对于外部客户来说，2C型服务是在线用户，最大的安全需求是保护用户，保护用户隐私，不损失用户体验。

在“IT价值贡献”这个维度上，成本很容易计算，但价值很难衡量。投资回报率一直是高层管理者需要考虑的问题。这个行业问题很难量化，现在所有的量化都缺乏合理的立足点。比如检测到一个APT事件，可以说是保护了整个公司的资产。据此，安保部门对公司保护了上百次，老板们每年都要给安保队送一个超大型的。但实际上很难界定真正的功能是否等同于保护整个公司的资产。为了避免大公司的病，一些公司开始让各部门自行承担盈亏，独立核算，公开能力强，招标公平。但这种内部报价结算模式，本质上有强买强卖的味道，并不是真正意义上的市场化行为。至少离乙方的保安公司还远，靠完全市场化的活动来养活自己。因此，这种模式可以鼓励和提高内部效率，防止腐败，但并不意味着提高了投资回报。虽然有一些指标可以衡量安保团队的内部工作，但整个安保部门似乎很难有评估标准，比如一年有多少暴力袭击被阻止，有多少袭击被阻止。这些数据可以用于营销推广，但使用KPI完全没有意义。当然，如果有一些明显不合格的评价，比如在与管理层约定的时间内，没有形成有足够支撑能力的安全团队，安全事件频发情况没有改善，基本离下课不远了。

在“IT内部流程”维度上，安全作为辅助功能，主要保证交付、运营等流程的效率。风险和效率的折中只是一个理论上的说法。事实上，每个人都默认安全团队的作用是尽可能避免所有的安全风险。所以在风险承受度不太妥协空的前提下，主要是支持业务提高效率，对应的是安全工作。有几个方面:

覆盖率——安全能力在公司的普及程度，有多少业务受到保护，有多少灰色地带，有多少没有被注意到或者忽略，当然还有一个很重要的，知道有风险但不能推动安全策略，看着有事发生。另一方面，如果安全团队人力太少，自动化能力太低，专业技能不高，导致缺乏力量支持R&D和整个产品线的运营，其实是安全团队本身的责任。他们的责任是R&D和运维不要在短时间内扩大和提高系统的并发性。同样，不能支持公司所有业务的安全活动也是安全团队的责任，赢得必要的资源也是责任之一。

覆盖深度——对于一个应用系统，上线前运行一次扫描器也叫覆盖，做代码审计也叫覆盖，做威胁建模也叫覆盖。显然深度不同。虽然在资源有限的情况下很难做到全覆盖和覆盖深度，但对于部门内部的长期工作改进来说，覆盖深度是一个可以不断优化的方向。事实上，从源头上解决安全问题是一项非常具有挑战性的任务，特别是在战线很长的情况下，而且不可能用像SDL这样的方法来解决问题。

检出率/主动止损率——现有安全机制对攻击行为的有效检出率。例如，在线安全产品和规则集对生产环境造成的威胁的检测率为80%，其中20%是通过外部报告或事后发现的。希望明年这个指数能提高到90%。因此，要通过创新技术手段优化纵深防御体系，清理灰色地带和死角，逐步提高效果。

TCO/ROI——这是一个比较传统的指标，很好理解，它反映了使用了多少资源，支持了多少业务，支持的深度，取得的效果。通常有几个层次:1)勉强支持，2)全力支持，3)挤出剩余资源进行再创新。勉强支持其实是消防队指挥官的状态，全力支持是系统的但不进取。只有第三种方式才能做到业内最佳实践，没有剩余实力整理思路进行研究的安全团队总是会筋疲力尽。目前看来能否转化为对外服务部门的账面利润，似乎还是一个小众话题。

技术维度指标——入侵检测检测率、入侵检测误报率、入侵检测响应时间、网络层抵抗力、安全方案可扩展性、安全方案可用性、1-1天主动发现时间、高风险全网调查时间、高风险全网修复时间...

“信息技术学习和创新”的维度是一个成熟的安全团队会考虑的事情。总体思路是如何考虑消防阶段后的安保发展。有几个方面:1)向行业领导学习。2)为了应对业务的增长，如果业务端的规划是用户数的10倍，系统容量的20倍，云转型完成，安全能适应这种变化吗？3)应对外部威胁趋势的变化。攻防是一个动态的过程，即使是目前业界被称为最佳实践的整体框架也不能一劳永逸。当学习和能力培养过度超过业务增长率时，也会出现问题。主业决定安全上限，这个时候可能就陷入自娱自乐了。这个问题就像一个诅咒，一年四季都解决不了。

4.外部评价指标

从外部评估甲方的安全团队通常有几个考虑因素:

攻防能力——如果懂安保团队的骨干很少，那就谈不上像样的安保团队。理解是做安全的基础。业内普遍情况是，整体实力强的安保团队不一定弱，能力弱的团队安保建设不一定强。一般能请得起一堆人才的安全团队预算充足，说明公司比较重视。技术属于安全施工中的“单点”技术，决定了单点的控制和深度。

愿景和方法论——单点技术代表局部执行，但在影响整个安全团队的输出因素上，仍然受制于团队的整体愿景和方法论。甲方的安全团队不是纯粹的安全研究职能，仅仅强调和谐是不足以产生高ROI的，因为很大一部分安全建设与具体无关，与缓解和免疫机制无关。如果只强调方法而不强调，就会陷入全消防队的状态。纵观行业，过分强调风险管理方法论的单位往往缺乏解决实际问题的能力，而一味强调排除安全标准的团队往往在顶层安全设计上存在问题。

工程能力——对于大中型公司的安全建设来说，能否将单一的一点知识转化为整个公司业务的防御、纵深防御和自动化的能力，就是工程。比如:1)根据我自己的经验，被感染的机器查看进程，转储文件解决单个事件；2)将这种体验转化为文档和脚本可以解决一些自动化问题，让更多的工程师有能力做出响应；3)进一步说，如果脚本可以在所有平台上转换部署，相当于整个业务线都有一定的入侵感知能力，单点技术强往往意味着从1)到2)没有问题。然而，在衡量一个企业或平台的整体安全能力时，我们实际上看3)。很多团队就是这一步无法进步，导致人才济济，但是整体安全建设的ROI不高。

对业务的影响——这和内部影响力、跨组织沟通能力、晋升能力、团队视野有很大关系。最明显的特点就是安全团队是在做狭义的微安全还是广义的安全。在安全方面做得最好的企业必须将安全和风险意识根植于企业文化中。

5.最小集

对于创业型公司来说，在不强调流程的企业文化中，为了保证安全管理在整个生命周期中的实施效果，必须在流程层面处理好以下几个方面:

1)提前建立安全基线，各种安全编程规范，运维配置规范等。

2)事件中发布&变更环节的安全管理。

3)事后灭火机制。

以上三项很好理解，但仅仅这三项显然是不够的。如果业务在发展，安全永远停留在这个治理层面是不合理的，所以必须有一些机制来保证安全管理水平与时俱进。至少在公司内部或者安全团队内部，有办法帮助建立并不断完善安全体系本身。

4)逐步将消防转化为防御机制或升级现有安全政策的过程。

5)定期对全公司或至少业务条线层面进行风险评估，主要用于识别可能转化为安全事件的新风险和潜在激励，以考察当前安全体系是否缺乏必要的自检环节。

资产管理

找出组织中有多少资产需要纳入安全管理范围是所有安全工作的基础。否则发现西墙还有洞，北无墙...

有时候，我突然发现一台机器被破坏了。查了对口部门，说是给第三方合作组织的，所以没有初始安全策略，也没有预装安全Agent。但是资产分配的时候是业务部门申请的，所以和这个部门的其他机器在同一个内网，没有隔离，这就使得三无关怀区的这个资产成为用户直接开进去的跳板。这是典型的资产管理不善导致的安全事故。

资产管理的质量直接反映了管理能力，也将在很大程度上影响安全工作。没有一套好的资产管理方法，安全工作永远处于亚健康状态。因此，督促相关部门进行有效的资产管理，利用自动化手段发现资产变化，是需要与安全部门共同考虑的事情，尤其是在云资源时代，资产管理是最基本的要求。

继基础资产管理之后，这不仅是BCM的需求，也是BCM的基本要求。

发布和变更流程

大多数安全管理流程不会独立存在于任何公司，但“安全措施”会嵌入公司的其他R&D和运营环节。安全可以看作是价值链中的一个风险控制环节，只是作为一个业务对外开放。

对于互联网公司来说，变更发布是价值链中最重要的任务之一，所以图4简单给出了一个如何在这个环节“堵塞”的例子。这个图不是一个正式的流程，只是为了说明这里抛出的问题。

图4发布流程示意图

主要是在“设计”和“交付”两个点进行设计，设计阶段的参与程度根据产品权重的大小来确定。设计很容易理解，包括体系结构级安全性、预先商定的规范和编码级安全性标准。交付包括安全测试、发布前的前一轮扫描以及预先制定的应急计划。

事件处理流程

事件处理流程是灭火阶段的必备环节，决定了它是单纯的灭火还是PDCA管理措施。下面显示了一个事件处理流程的示例。

角色定义

重大安全作业事故响应过程中涉及的角色定义如下:

1)联系人:比如在白天工作时间，联系人是对应的故障系统或保安事件的第一责任人，在夜间工作时间，他可能是监控系统的人，负责与指挥确认事件开始处理，并与客服等相关功能进行交互；

2)执行者:在响应过程中处理故障的技术人员；

3)指挥长:负责响应过程的协调、决策和调度的人。

定义责任矩阵

应急响应中涉及的角色和职责的定义如表2所示。

表2责任矩阵

缩写具有以下含义:

r =负责，负责执行任务的角色，具体负责操纵项目和解决问题。

a =问责，谁对任务负全责，项目要经过其同意或签字才能进行。

c =被咨询者，在任务实施之前或期间提供指导的人。

I =知情。及时得知结果的人无需咨询或征求意见。

流程图

安全操作事故的响应过程如图5所示。

图5重大安全作业事故响应流程图

在处理安全事故时，应遵循应急基金模型和NIST-800中定义的应急处理方法。

系统关联的影响

处理突发事件时，在繁忙的工作中容易造成混乱，从而导致失误。因此，SOA服务治理、接口间的调用关系、数据流梳理、嵌套引用关联影响反映了内部治理的水平。对于应急处理，关联影响分析属于P阶段的前期准备和循环中的日常工作。表3是一个简单的例子。

表4系统关联的影响

其实事件处理流程之外还有很多流程，这里就不举例了。

6.安全产品的研发

以前甲方安保基本不涉及这个话题。行业崛起后，以谷歌为首的行业领先厂商，在自主开发的系统和开源软件上构建自己的解决方案，这似乎是行业潜规则。不自己开发两个软件，不好意思说是有工程技术文化的公司，不自己开发一个，不好意思说是大公司。较大厂家的安防团队也顺应了这个趋势，根据乙方在市场上的安防产品。根据葫芦画瓢，明确原理，搜索相关开源软件，逐步转化为使用分布式架构的安全产品。一开始可能不像商业产品那么好用，但是节省了大量的软件许可和硬件盒费用。经过多年的不断完善和实战，商业产品不再被视为仿制对象，走上了“业内最佳实践”的道路。

关于是否有必要做自我研究，业内众说纷纭。乙方的一些厂商认为甲方专注于自己的业务是好的，把基础部分交给乙方..业内认为，如果谷歌使用IBM 解决方案，那就破产了。有几个方面需要考虑:

●即使是大公司，也不能在安全性方面选择事事亲力亲为。比如需要一个动态令牌，不是主营业务，不面对客户，受众群体不多。花点钱买个现成的就够了。完全没有必要自己做。

●规模效应决定性价比。如果您计划自己开发一个安全产品，应用场景覆盖的信息技术资产必须超过一定的数量级，这样手动R&D和维护的成本将低于使用商业解决方案时相同数量级的信息技术资产的总购买成本。不然一个几百个单位的小企业，花10个人的小团队去研发相关的安全产品，是吃力不讨好的。R&D团队平均工资2万，每年增税福利公司支出360万，不算管理成本。如果业务调整或者与经济周期不谋而合，需要考虑如何调整甚至补偿裁员。事实上，中国规模在10万以上的公司并不多。花1000万买imperva的WAF不一定是错误的决定，因为可能无法达到同样的研发水平。但是如果需求是不需要imperva WAF那么多功能，只需要简单的过滤，那么开源软件可以考虑改进。再比如IDC有几万个物理单元，但是页面不多，大部分是静态资源，入口比较集中，不需要自己开发分布式WAF。买一个业务，部署在业务前端就够了，不要在IDC门口。

●攻防安全产品很容易获得一般的商业解决方案，但对于风控产品，由于与业务密切相关，现成的解决方案很少，所以风控方面的需求和自主研究的必要性更大。

7.开放与合作

SRC只是一个正式的开始，意味着安全工作不能只坐在办公室里苦练，要走出去，寻求与行业的广泛合作。在目前的安全形势下，没有一家公司能够幸免。合作有几个方面:

●与乙方的安全供应商合作，共享数据和。

●与其他甲方公司或第三方SRC合作分享。

●与供应链上下游合作，使安全流程覆盖价值链的延伸。

●参与行业交流，避免闭门造车。