企业安全建设的起步｜科技创新型企业专刊·安全村

一、前言

近些年来“企业安全”这个话题比较火热，一个人的安全部、甲方安全建设相关文章倍受欢迎。网上已经有不少甲方安全建设相关文章，其中不乏身经百战之后的填坑解读，也有不少成功的安全项目分享，但大多都是非常体系化的结构。然而本文与之大相径庭，仅从甲方“搬砖工人”的角色出发看待整个企业的安全，结合切身负责或参与的项目，对自己平时工作中的所见+所闻+所思+所感进行记录总结与分享。

本文写于笔者的第一段甲方企业安全建设的经历，在此之前服务于国内某老牌安全乙方公司，并没有体系化的做过企业安全建设相关项目；刚实现从乙方到甲方的角色转变，甲方安全建设之路也刚开始不久，没有经过系统化、工程化的安全资质培训；仅凭借自身的项目经历（渗透测试、APP安全评估、风险评估、代码审计、应急响应、安全培训等）+平时积累（甲方安全建设相关文章与书籍、向其他甲方安全大佬请教问题等），出发视角较为狭小&高度不够，如果出现不足与错误之处，还望指出并劳驾见谅与包涵。

二、企业安全需求

除了没有被外部黑客攻击造成财产损失外，影响企业难以花费成本在安全建设方面的因素还有很多，比如企业业务还没有到达一定规模、没有相关部门的监管、没有第三方的合作监督等。如果要想把公司的安全做好，首先需要获得领导的支持与重视，通常较为常见的有以下几种方式。

1、安全事件

公司主页被纂改造成不良声誉影响，业务场景存在安全缺陷导致被恶意攻击造成财产损失，内网服务器被远程植入挖矿脚本占用大量系统资源，...各种安全事件层出不穷。作为甲方的安全人员，除了需要掌握必备的安全技能来应对安全事件的发生外，还应该充分认识到每次安全事件的宝贵性，合理、充分的利用安全事件。首先是对产生的原因、影响、危害等进行分析、评估、止血，其次是对原因进行深挖与扩展，联想到企业当前的安全威胁，使之与当前进行的安全项目甚至即将开展的、潜在的安全项目结合，发挥“一次安全事件，一波安全整改，一次企业安全能力提升”的实质效果。

2、合规检查

不少行业都会有相关机构的安全检查，比如拥有支付牌照的支付公司而言，每年多次的人民银行安全检查，各种合规性要求各种指标都需要达标。此外针对部分系统还要求过等级保护，这无疑又是一层安全的壁垒。

先从乙方公司的角度来看，之前参与过很多安全评估与等级保护的项目，大到运营商与巨头银行，小到基金公司与高等院校，觉得等级保护就那么几个常用招式：技术（漏洞扫描+渗透测试）+咨询（根据企业特点多个checklist走一遍），然后就是项目经理套路式的思维输出在固定模板的报告，交付甲方轻松+愉快。对于中小型公司而言，一般都是这样操作，但也遇到过一些真心想把安全做好的公司，即使不太懂但是头脑思路清晰、逻辑能力很强，每一个得出的结果都需要从头推论，甚至是常对得出的结果产生质疑，乙方人员要是说不出个一二三，别想蒙混过关。不过个人还是比较喜欢这样的客户，因为会使自己的服务水平和专业能力得到不断提升。最难忘的是想吐槽乙方安全公司销售为了单子，让安服工程师听从甲方要求任意篡改漏洞扫描报告，修改高、中危漏洞数量来达到上级部门的检查标准，这种活儿不禁会使人怀疑职业生涯。

站在甲方的角度考虑，各种合规检查无疑是目前来说具备效果的方法之一。因为没有统一详细落地的行业安全标杆，所以很难甄别是否具备足够的安全防御水平。基本需求是“有，总比没有好”，更高的渴望是“充分利用合规检查”落实企业安全建设。企业的安全能力与相关负责人、安全团队息息相关，究竟是务实还是专心搞政治分心做安全，往往取决于人。

3、企业内鬼

当手握企业大量敏感数据，当工作不再那么负责与忠诚，当个人价值观远远高于企业价值观，再受到外部的金钱诱惑，企业内鬼很容易就会产生。“日防夜防，家贼难防”这句话说的很有道理，唯有进行一些安全建设，比如让员工远离敏感数据（敏感数据分级管理）、对重要文件进行严密保护或监控、员工上网行为管理等，才能减少该类事件的发生，从而避免企业遭受损失。

4、产品竞争力

安全不是业务发展的阻力，而是产品的竞争力。这句话听起耳熟，说起容易，做起来难。不过无疑也是企业安全项目实施的推动力，从产品的角度出发，让安全成为产品的一个重要特性甚至是闪光点，吸引用户并使用户放心。这部分向客户介绍产品的安全设计理念、先进技术、安全架构甚至提供第三方权威机构的安全评估报告证明。

5、三方合作要求

如果企业与其他大型互联网合作，一般都会对安全性有所要求。这种情况下，业务会主动找到安全人员为其做安全测试、安全评估，这算是企业安全需求中，业务方最主动的一种情形。这不难说明两个真相：

• 对外部第三方推动业务安全，对内业务呈现主动趋势

• 业务为主，凡是业务上需要的都会想办法实现与完成

所以在推动安全项目与公司各部门对接、沟通时，应主动足够去了解其业务特点，抓住他们的痛点和难点及时插入安全因素，甚至为其业务量身打造安全铠甲。

6、网络安全法实施

从”企业出安全事故，请领导喝茶“的结果去推动安全项目也是十分有效的途径，从法律的角度出发，业务产品、开发会信服，领导也会听取。《网络安全法》条目较多，引用下面一条表明立场。

网络安全法第五十六条：发现网络存在较大安全风险或者发生安全事件的，可以按照规定的权限和程序对该网络的运营者的法定代表人或者主要负责人进行约谈。

三、企业安全威胁分析

企业面临的威胁可以说是来自四面八方，既有恶意的外部攻击者，也不排除来自内部的安全隐患。往往在不经意间，又可能引入新的安全因素，也有可能在输出产品时给其他企业带来安全风险。大而言之，企业的威胁从个人理解的角度出发，大致可以分为以下几点：

• 输入威胁

• 内部威胁

• 外部威胁

• 输出威胁

1、输入威胁分析

• 输入：第三方软件系统上线

• 输入：第三方硬件设备入网

• 输入：第三方开源框架与组件

企业常常需要向其他公司采购软、硬件设备，或采用第三方开源框架与组件进行开发。相关部门如果缺乏安全意识，就很有可能不经过任何安全相关评估，将安全风险带到公司，比如：买到即上线。然而对于一些稍有安全意识的公司，会对引入的产品进行安全评估，起初是这样一种情形：费&累

等待信息安全组沟通、验证回归漏洞完毕后，继续走流程购买付款，然后系统正式上线。在整个过程中，可见安全已经介入但出现较晚，导致的后果就是“费时费力帮别人家的产品做安全”。除此之外，再分享一个不靠谱的现象：飘&虚

曾有供应商提起，他们的系统经过某银行严格安全检查，并成功入驻，还向我们展示了部分检测报告。但在我们进行安全测试时，结果却不十分理想。刨根问底一番探究后，才弄明白：原来那银行使用绿盟主机漏洞扫描器，对供应商产品所在地址进行了主机漏洞扫描（在主机前还架设了防火墙，隔着墙扫的），而非对其产品进行安全评估。

难怪隔行如隔山，此类大跌眼镜、没有把安全落到实处的情形，估计还有不少。那问题来了，如何有效的对输入威胁进行有效控制？显而易见的是需要将安全提前，在业务方进行需求分析时，便把安全因素加入其中，成为需求的一个环节，在产品选型时可由安全组相关同事进行把关，可参考是否具有第三方安全机构出具的报告，可询问是否自行做过安全测试等保证产品安全性的流程。如果需要更进一步的确认，可以进行“抽样”式安全测试，对涉及到敏感数据环节或重要操作进行安全评估。

2、内部威胁浅析

企业内部威胁主要来自于人，如果细分的话可以从安全意识、相关制度、内网管控等方面进行考量，比如：

• 内鬼泄露内部机密信息资产

• 内部人员主动攻击外部其他系统

• 内部系统沦为肉鸡被动攻击外部其他系统

• 内部网络混乱，比如访客网络与办公网甚至生产网未做隔离

• 内部员工安全意识薄弱，被钓鱼或社工等攻击

• 公司内部安全管理制度缺失，员工随意带电脑外出公司或带机密文件出公司

实际遇到的情况会比列出来的多、复杂的多、隐蔽的多，但在面对诸多威胁的时候，应该具备发现问题的眼光并深入下去，找到企业欠缺之处的根源，从源头进行修补。没有制度就制定并推行制度，安全意识不足就全员推送安全意识并坚持下去。以安全意识为例，可从视、培、读、写四个方面开展：

3、外部威胁粗析

• 竞争对手的长期觊觎，导致雇佣黑客攻击的恶意竞争；

• 业务发展壮大安全跟不上，导致不法分子的获利攻击；

• 公司架构采用主流与非主流框架，出现0day时的攻击；

……

“与其落后挨打，不如主动求变”，企业的安全建设只有主动将救火阶段慢慢的转到安全建设，才能在遭受外部攻击时稍微淡定一点。

4、输出威胁剖析

• 技术输出：分享到外部的技术文档与其他资源存在安全缺陷，被其他人员当做模板使用。

• 产品输出：本身产品存在安全隐患，导致恶意攻击者恶意利用漏洞，或私藏后门开关按钮被外部发现且恶意利用。

公司产品（系统）严格控制经过安全测试后，再投入生产及交易。有条件的或时机成熟的公司，落地版的SDL走一遍，不仅是对客户负责，更有可能避免了以后某一天遭到曝光或攻击带来的麻烦。

四、企业安全架构建设

分析完了企业面临的信息安全需求（为什么做信息安全）和安全威胁，那么如何开展信息安全建设呢？我认为要从安全团队建设、安全架构设计和向上管理三个方面着手。

1、安全团队建设

在甲方的安全工作中，重点自然是在企业的安全建设上，但是为了能持续不断的输出，安全队伍的建设变成了不可或缺的一环。成员的能力决定着企业安全的高度，合理的安全队伍配置是整个建设之路上的引擎。

1.1 理想中团队

按照角色与工作职责，安全相关的岗位可细分为：CSO、安全架构、安全审计、安全测试、代码审计、安全开发、安全运维、安全运营、安全风控等方向，比较理想的安全团队并不是要求设置以上全部岗位，而是在开展相关工作时需要涉及这些专业技能。根据公司的大小差异，各个岗位的名称与headcount也都不太一样。

1.2 现实版团队

“理想很丰满，现实很骨感”，这句话尤其请乙方安全工程师注意。为什么是乙方安全工程师呢？因为很多人以后都希望转到甲方。虽然平时有接触不少客户，但若不是项目负责人或不是参与安全评估类的项目，很少清楚知道客户所处环境。很多甲方公司或许并没有专职的安全人员，或许仅有临时工，此类场景常常出现在传统企业、非互联网过渡到互联网的企业中，所以在准备跳槽时对企业的选择需要谨慎。

作为掌舵者的CSO重要性不言而喻，由于具备实战能力与经验兼备的CSO较少，从成本与安全需求的迫切性出发，不少企业在该职位上也没有留下足够的薪金，也导致了目前比较普遍的现象：

• 安全由运维leader负责，向cto汇报；

• 安全由测试leader负责，向cto汇报；

• 安全由开发leader负责，向cto汇报；

• 企业内部由运维/测试/开发参与安全项目，向上一级负责人汇报…

术业有专攻，即使很强大的leader在遇到一些安全项目的决策时，也极有可能持保守态度，在没把握情况下与其犯错不如不做。相比专业的安全人员，这无疑在一定程度上限制了企业安全的发展。此外，由于对安全领域的不熟悉，在与上级领导沟通、对安全项目上的投入等方面表现不足，往往也会成为制约企业安全建设的因素。

还有一种较为常见的场景，公司中并没有设置CSO这一职位，该职务一般由安全部经理甚至有发展潜力的安全工程师担任。所谓的潜力简要概括为：

1.3 安全架构组

组成：CTO、CSO、架构师、安全架构师、中间件等各部门领导

职能：重大安全架构决策，安全相关规章制度评审。

1.4 安全接口人

成员：各业务部门负责人（可设置AB岗）

职责：负责所在部门/业务线安全问题的对接、沟通、跟踪。

2、安全架构规划

安全架构规划是一个非常复杂与庞大的话题，由于水平有限以下观点仅供参考。在一些对外交流中，有不少人会参照书本上或其他公司分享的案例，从标准体系(27001&等级保护等)—>具体工作的视角进行规划。但作为安全建设从头开始的体验者，深刻感受其可行性、效率与不足之处。

2.1 安全风险发掘

在实习的时候，记得当时的部门领导(上交大网络安全学院老师)说过：信息安全从业者就好比是医生，企业有问题需要我们去出诊，首先就是要根据病症进行相关检查分析才能对症下药。那么甲方安全工程师做安全就是医生给自己看病，需要不断的搜集异常症状并进行分析判断是否有问题，即安全风险发掘。以下是对常见企业安全风险的简单梳理：

要做到实用性，往往要求熟悉公司网络环境与业务形态，此外还需要一定的嗅觉性，追究其根源便是：意识、经验与视野。

2.2 外部经验交流

在一次企业安全沙龙中，看到了蘑菇街的安全项目蓝图，并从中得以借鉴。通过前期安全风险挖掘的积累，我们进行头脑风暴并对相关项目进行梳理，把相同实现效果的项目整合成一大类，再把各个大类聚合在一起，便有了初始的安全架构规划图：

安全是动态的、持续性的，需要保持一颗善于发现问题、思考总结的心，不断完善企业安全的整体画像，不断优化相关环节的同时也进行项目的推进。

3、安全工作推动

3.1 领导支持

安全工作的推动是一个自上而下的过程，在建设的伊始便是与上层领导沟通，并争取获得必要的支持，具体理由可参照【第二章：企业安全建设需求】进行分析与汇报。此外如果是项目负责人，应该自己先竭尽所能的去推动，实在有困难时邀请领导出面参与会议或回复邮件，也是提升工作效率的一大利器。

3.2 安全运营

在企业安全建设初期，除了救火工作外还建议开展体系化的、丰富的安全意识培训。人是安全的知名薄弱环节，因为员工的安全意识参差不齐，所以需要进行多个渠道（邮件、即时通讯工作群）、多种方式（海报、易拉宝、动画片、暴漫）、多种内容（通用安全意识、最新安全威胁、行业安全情况）等方面的长期"洗脑"。这里把安全意识的培训推广工作加入到了安全运营的一个环节，除此之外安全方案的不断优化、漏扫插件的更新、waf规则的即时添加调整、SRC的推广都应该属于运营范畴。

3.3 做事思路

根据已经参与或负责的安全项目发现，在甲方做事情很讲究做事的思路。以下简要的记录了深有体会的几个小点：

1）城市包围农村，结合多个部门一起推动

在推动专项安全项目时，会出现不好对付的部门。这时候不能硬碰硬，从存在安全问题的部门做起，其次是支持安全工作的部门，接着再按照实现难易程度与花销依次排序，把最难推动的部门放最后。推动过程中，不断及时汇报项目进展情况，比如本周推动90%的部门完成安全改造，剩余10%的部门尚未整改。迫于压力，一般情况下10%左右的部门也会尽快加入进来。

2）鼓励+奖励 > 惩罚

面对业务部门时采用鼓励与奖励的方法会好过惩罚。不少人有时会产生一种错觉，凭借自己的技术强力把业务方怼回去并暗自高兴，然而我的想法确是和业务方友好相处甚至做朋友，安全的出现是为了业务变得更加安全更好，而不是阻止业务前进的步伐，当高危漏洞降级至没法再降比如低危时，可以注明情况并通过安全测试。不过需要补充的是，礼让、文明合作是有尺度的，基本的原则不能丢，某些情况下不能轻易妥协。

3）主动出击引导业务进入安全节奏

一般的甲方可能只有一个或几个人懂安全，无论是开发大神还是运维大神都不会太懂，所以信息安全组的成员更应该主动的去找相关人员沟通，交流遇到的安全问题以及结合实际业务场景提出合理的安全建议，将安全早点带入到各个业务场景中。在日常的工作中，效率值的排名一般是：直接找人当面沟通 > 电话沟通 > 即时通讯工具沟通 > 邮件沟通，当然也可以几种相结合，主动想办法提升工作效率。

---

作者介绍

武鑫，现就职于奇安信网络安全部，负责公司产品安全和威胁狩猎相关工作。擅长从网络攻防、安全隐患发现视角进行企业安全建设。在SDLC 方面有一定思考与落地经验，业余时间运营个人微信公众号《我的安全视界观》，发表原创文章近五十篇。

RECOMMEND

往期回顾

关于 安全村文集·科技创新型企业专刊

科技强大的根本在于企业创新，创新过程中需要确保信息安全工作。专刊汇集了安全工作者的经验、教训、心得、体会、思路、方法、架构、方案，希望搭建一个创新型企业信息安全交流的平台，推动行业的信息安全工作交流、共享、提升。

关于 安全村

安全村始终致力于为安全人服务，通过博客、文集、专刊、沙龙等形态，交流最新的技术和资讯，增强互动与合作，与行业人员共同建设协同生态。

投稿邮箱：[e-mail]