深入业务场景，解决业务安全风险

最近接受网安加云课堂的邀请，做了一期关于业务安全的访谈，他们提出了一些非常好的问题，我也借机把自己对于业务安全的理解再做了一遍梳理和总结。过后又重新思考了一遍，觉得还可以做些补充和优化，于是在访谈稿的基础上重新整理。

我的职业生涯中初次提出“业务安全”这个概念的是我的前任领导王智。在他的带领下，安全团队在业务安全方向从2008年就开始探索“什么叫业务安全”“为什么做业务安全”“怎么做业务安全”，探究、实践了很久，我们算是把这个理念和实践方法掌握的比较透彻了。2016年左右，我报名作为安全牛《反欺诈技术指南》的主笔，也是因为听说业内对“业务安全”的认知大多是反欺诈、业务风控，对这个领域充满了好奇，居然还有这些玩法？！前后一折腾、对比、学习，深有感悟。正好趁这次的机会总结一下，以飨行业读者。特此声明，这不是我一个人的成果，是当时整个团队的成果。

一、What：什么叫“业务安全”

现在安全从业者对于业务安全的解读，多数是受到了互联网行业的影响，将业务安全基本等同于互联网、互联网金融业务运行中的反欺诈、业务风控。我认为，业务安全指：为了防范企业业务流程中出现风险，避免业务遭遇各类威胁或遭受经济损失，保障整体业务逻辑的顺畅，最终帮助企业达成业务目标、降低经营成本、提升业务收益，进一步增强企业竞争力而采取的风险控制措施。

基于这个定义，如果是一家互联网、互联网金融的企业，其业务安全的实质内容大概率就是各种反欺诈、对抗薅羊毛、反爬虫、营销活动中的反舞弊等措施；而如果是一家高精尖设备生产制造企业（比如台积电），业务安全的实质内容就应该是保障生产过程不中断、及时交付、交付产品质量高、不会被勒索软件危害；如果是一家研发型企业，业务安全的实质可能就是保障技术或产品的市场领先性、保障销售拿单的竞争力、保障核心研发人员的稳定忠诚。

“业务安全”概念中，

• “业务”应该定义为公司的核心业务，就是能够对公司经营产生重大影响的业务活动。比如以我上面所举的几个例子，物流管理可能就不是核心业务，因为这个业务的好坏对公司经营没有决定性影响，那业务安全就可以不用管它（或者说优先级不高）。
• “安全”这个词的内涵可拆分为如下几个维度，每家企业可以根据自身业务的情况决定选择哪几条。这几条可能也不完整，需要持续完善：
  • 保障业务和业务相关方的可持续运行和可用性，保障业务目标达成。
  • 确保合规性，避免被监管处罚或影响声誉。
  • 保障核心信息不被泄露，或信息泄露不影响业务的运转、收益。
  • 保障数据的完整性、一致性。
  • 自证清白的能力。不论业务运行过程中出现任何问题，业务部门能够证明自己负责部分是合规的、风险受控的。

很多人可能会奇怪，为什么没有把“不被攻击、入侵、控制”作为业务安全的内涵？我是这么看的：如果遭受攻击、入侵或控制，入侵就入侵了嘛，控制就控制了嘛，那是潜在风险，只要业务运转、公司经营、收入利润不受影响，那就不是业务安全范畴需要考虑的事情，那是你基础安全需要面对和解决的问题。但是如果被勒索了，那业务连续性就受到严重影响了，那就是业务安全需要面对的问题了；如果被DDOS了，游戏用户没办法登录、顺畅地体验游戏、往游戏里面充值了，那就影响业务运行、收入了，那就是业务安全需要面对的问题了；如果官网被攻击导致用户无法访问，老板觉得不影响业务，那这就不属于业务安全的工作范畴，可是如果官网被篡改并发布了一些敏感、不符合要求的言论，公司会被监管部门处罚、影响公司声誉了，老板觉得影响了业务，那这个就属于业务安全的工作范畴。

 

二、为什么要做“业务安全”？业务安全和基础安全有什么关系？

先说结论：有区别，但是总体一致。

基于上述对于业务安全的解读，可以说信息安全的最终目的就是保障业务安全，此为二者的一致性。这也就是为什么要做“业务安全”的根本原因。

二者的区别在于，基础安全是业务安全开展的基础，基础安全更强调在遭受攻击、控制、窃取、破坏、勒索时，采取技术、管理手段来针对这些风险予以防范、控制。但是基础安全的工作仅是业务安全的基础，没有传统信息安全的防范规避工作作为基础，业务安全的工作是无法开展的；且传统安全重点关注攻防、内外部信息窃取、泄露等“面”上的工作，如果最终不能保障业务安全，基础安全的工作就无法体现在公司业务中的价值，这也是很多安全团队会面临的困境“为什么我干了那么多工作，又是修漏洞打补丁，又是建防火墙WAF，还对文档进行加密，怎么老板就是不认可我们的工作呢？”要知道，老板是要看价值的、投入产出比的，如果你的工作无法体现在公司经营上的直接价值，那么，不要怪老板，首先要想想自己的工作思路和方法是不是有问题。

做的好的安全团队，甚至会把基础安全工作形成可组合的安全能力（有点像单个菜品），基于业务需求和场景、定制安全解决方案（有点像套餐），最终实现既在“面”上形成普适的安全控制水平，同时在业务场景的“点”上形成针对性的安全价值。

三、如何有效推动业务安全工作的落地？

首先需要让业务部门的领导看到价值，这样才能得到业务部门的认可、支持和参与。剩下的就都是操作层面的问题。

至于价值展示可从几个方面入手，说起来其实很简单。

• 安全团队要主动积极地去和业务部门合作沟通，帮助他们。既是了解业务，也是识别和发现风险。
• 发现风险，并通过可视化直观的形式将风险暴露出来，同时提出改进建议和改进措施，积极推动这些改进措施的落地，从而确保业务正常、安全地开展。
• 不抢功。安全团队在业务过程中是辅助角色，需要适当地出现、多一些付出。

下面针对这几点，一个个来说。

1、如何更好地与业务部门沟通、合作，实现了解业务、识别和发现风险的目的？

• 如果公司有流程管理部门，那最好了，先从阅读流程文件、业务部门的各种规章规范、通知要求入手；这个操作有点像审计的“文审”；
• 开会、聊天，正式的、非正式地沟通，通过懂行的熟人去了解，同行搜集了解信息，参与业务部门的例会；在“文审”的基础上建立直观、粗浅的认知。在具备恰当的人员、技能的前提下，在业务部门与安全部门进行适当的人员轮岗，更好地互相理解；轮岗这一举措具备一定难度，退而求其次，我们可以增加业务部门与安全部门面对面的沟通与交流的频次，一起探讨研究，也能更好地促进安全团队对业务的理解。
• 安全人员实际参与到业务过程中，从业务流程开始的第一个环节，全流程、端到端、实地参与进去，搜集、了解、剖析业务过程中的人流、物流、资金流、信息流、所处环境、所使用的工具（不仅仅是IT工具）；这个有点像审计的“现场检查”。
• 运用风险评估的方法，对业务过程中的威胁、脆弱性进行分析，识别出业务过程中存在的风险；

2、识别、发现风险之后，怎么办？

当然是制订解决方案！对不对？NO！NO！NO！

应该是分析风险产生的原因！到底是工具缺乏，是人员意识不到位，是流程缺乏控制点，是开发过程中存在的安全建模过程不全面，还是什么？这个步骤很容易被忽略，也是很多安全工作者最容易犯的毛病。一看到要数据保密就说DLP，一看到非结构文档保密就说文档加密，一看到有人薅羊毛就说要上反欺诈系统、接入风控情报，一看到勒索软件就说要做数据备份，这样很容易治标不治本。所以一定要针对风险产生的原因进行针对性改进。

改进措施也一定是针对人、工具、流程、环境的综合解决方案，不能仅仅是IT工具的改进，这也是很多安全工作者容易犯的毛病。尤其是业务流程，合理的情况下一定要去调整，否则有的时候就无法控制住风险。

3、如何保证风险控制措施是有效的、可落地的？

• 制订出来的改进措施，要充分听取业务部门的意见，这既是尊重、合作的基础，同时沟通的过程也是一个不断教育的过程，让业务部门自己真正懂安全、懂如何控制风险的过程，必不可少。在互联网、互金行业里面，典型的做法就是制订风控策略的过程，一定会有业务部门的参与，而不仅仅是安全团队来制订风控策略。
• 安全团队给出的改进措施，一定要学会站在公司经营的角度思考（而不是安全团队的角度），如何在业务收益和安全之间取得良好的平衡，不要把这个职责甩给业务部门。站在公司经营角度思考问题，业务部门就会觉得你是在真心为他们着想，才会有更好的合作意愿；站在公司经营角度思考问题，业务部门才会觉得你是个懂行的安全专家，而不是一个安全技术专家；站在公司经营角度思考问题，你才会真正知道为什么要做业务安全。
• 要从业务安全的目的出发、寻找综合解决方案，而不是只从技术工具出发、做有限的工作。安全从业者因为组织架构、自身意愿、资源的限制，制定解决方案的时候往往会有“现在市面上的DLP工具就是这些功能，有些问题我也解决不了”“公司给我的资源就是这2个人，我也没有更多的精力来解决这个问题”等思维局限，这个其实很要命，务必要改。

在推行顺序上，免不了要讨论一下是先做基础安全还是先做业务安全。一般而言，我会建议先等最紧急的风险得到有效控制之后，就着手从事业务安全的工作；如果当下没有紧急的风险需要应对，那么将业务安全作为整体安全工作的一部分统筹考虑。因为业务安全的目标，将决定基础安全部分的架构、未来演进和发展的方向。

 

四、举几个例子来说说，应该怎么做业务安全。

例子1：大项目投标。

公司当时定义了一个核心业务叫“大项目投标”。为啥呢？因为大项目的成败对公司订单、收入都直接而显著的影响。当时行业竞争很激烈，如果在项目招投标过程中，投标的底牌被泄露、被竞争对手掌握，对投标结果的影响也是不言而喻的，对手只要比你少1万就能轻松耗掉你前期的所有努力。以往也时不时发生这样的情况，搞的业务团队很郁闷。那么，安全团队需要和业务团队一起保障在整个业务过程中投标底牌的安全，该如何做？

如果我是个安全技术人员，可能我的第一反应就是“上DLP啊！上文档加密啊！对各种文档出口进行监控和分析啊！”但实际情况却出乎所有人的意料。经过深入业务、和业务团队一起摸爬滚打了几个项目投标全过程，安全团队的人甚至一起参与投标决策、一起送标书，我们发现整个投标过程中，业务团队对投标信息的掌控很严格，有很强的安全保护意识，公司内发生信息泄露的可能性并不大。不过，最后还是发现两个风险点。

第一个风险点：最终决策会议阶段。最终决策会议所在的会议室管控不严、缺乏保护，很容易因为窃听窃照而造成信息泄露。因此，需要在决策会议召开之前进行防窃听防偷拍检查，确保会议室安全可控；其次，开会期间，会场实施信号屏蔽、与会人员禁入任何电子设备、严格控制出入会议室人员；最后，会议后清理会场、监督投标底牌信息的留存发布的受控。这样就保证了会前、会中、会后的人、设备、场所、信息流转都是安全的。

第二个风险点：标书制作过程。为了标书的精美度，标书通常会交到专门文印店去制作装潢，不可避免地在这个过程中，标书会存在公司外部的电脑上，而文印店的电脑内外部交互是非常频繁、易受攻击的，一旦电脑被攻击，标书的信息也就被窃取了。针对这一风险点，现场派工作人员对全过程进行监督，标书制作完毕后、用专门的清除工具将文印店电脑上的标书文档彻底清除，确保文档不能被恢复，保证标书制作流程的安全可控，避免该阶段标书被泄露的风险。当然，传说中在这个过程中不但保护了自己的标书，还获得了对手的标书。

从以上过程可以看出，安全人员不能简单地按照自己的臆想去上安全工具、手段，而是要真正深入业务执行过程发现风险、解决问题。

例子2、关键物料和生产制造业务

公司当时定义了一个核心业务叫“关键物料和生产制造业务”。为啥呢？生产制造过程中，需要定期下PO采购关键物料。采购量、品种、型号等不能被竞争对手提前知道，一旦泄露，竞争对手可能提前下单、卡位，造成对我们的供应不足，影响项目交付。但是，麻烦的是，采购和制造属于同一个副总裁管理，所以关键物料的采购计划和后续的生产制造计划是在同一次决策会议上决定的，会议纪要中会描述明细采购计划和制造计划、再分头发往相关的十几个团队去执行，信息扩散范围很广。

业务流程分析完，脆弱点很容易发现，就是控制会议纪要的传播范围。于是，文档加密和邮件、网络、终端DLP的手段全部用上去。半年后，忽然有一天觉得似乎不对劲，这似乎不是最佳方法。如果我们把会议纪要的发放流程做个改造不就行了吗？于是和业务团队商量，在决策会议后的会议纪要发放过程中，将会议纪要拆分为十几份，每个团队只收到与自己相关的执行要求、而看不到全局的采购和执行计划。这样，能掌握全局信息的就那么1-2个人，信息暴露面就大大收敛，既利于管控、也利于追溯。

从这个例子可以看出的是，做业务安全有时候不需要上工具，只要改造一下业务流程就能达到效果。这依赖于安全人员对业务的深入理解，以及要具备改造流程的意识。

 

例子3：互联网、互金场景的业务风控

很抱歉，针对这个场景，我自己没有切身的实践经历，都是道听途说+自己揣摩，就不在这里献丑了。但我想基本思路都是一样的，安全人员不要自己坐在座位上臆想（或照搬别人的）一套风控系统、风控策略，而是要和业务团队一起合作，真正站在公司经营的角度，寻求减少经营损失、提高公司收入和利润的方法。在互联网、互金场景的业务风控中，为了良好的用户体验，安全团队、风控团队可能不得不在后台做大量的、看不到的工作，但这都是值得的。

写完了，希望这次的总结，能给大家带来不一样的业务安全视角。