互联网安全小兵的日常：如何体面地与业务打交道

题图 by 6姐

生活不止眼前的枸杞，还有诗和甲方。两年前，我来了甲方，成为一名互联网公司的安全工程师。刚开始的阶段也是与一个个漏洞为伴，做做安全测试与漏洞推修。那时的日常可以参照我的那篇《安全摘记：互联网安全小兵的日常》。

后来，领导发现我吹牛逼的水平远远高于我的技术水平，决定对我因材培养，逐渐让我和业务打交道，作为安全接口人对接业务的安全需求，以及对通用型的业务需求做一些安全能力的沉淀。从此之后，就开启了我的打杂生活，日常工作包括输出一些安全场景的解决方案、安全意识安全制度安全技术的培训、安全事件审计、应急响应、安全合规、安全推广运营等。

很多人对安全工程师都有一个误解，这里就要思考一下了：

安全工程师的工作就是挖洞吗？

外部给企业提交漏洞的“白帽子”，以及内部经常收到漏洞通知的同事些，往往会觉得安全工程师就是与漏洞打交道。其实就像宜人贷在先知的一次安全大会上分享的那样，处理安全漏洞只是甲方安全人员一部分工作职责，事实上企业内的信息安全建设涉及的工作范畴可以很丰富，如安全需求评审、安全事件审计、安全培训、应急响应、业务风控、安全系统研发、安全合规等。

在《互联网企业安全高级指南》那本书里，作者大致将互联网公司的安全工作分为四个方面，简单描述下供参考：

• 信息安全管理：安全流程、整体以及场景化的安全策略制定与推动等。

• 基础架构与网络安全：生产网络各种网络设备、链路、服务器、服务器程序、数据库等涉及的安全运维，比如漏扫、打补丁、防火墙、安全配置、主机入侵检测等。

• 应用与交付安全：应用层面很多表现为Web服务（APP很多也是基于Web），这部分是目前攻防对抗主战场。代码审计、渗透测试、Web应用防火墙，安全开发SDL等可以划分到这部分。

• 业务安全：帐号安全、垃圾注册、交易风控、反外挂、反羊毛党等可以算作这部分。这些是在基础安全问题解决后的进阶需求，也越来越受到重视。

来到甲方之后，开始跟业务打交道，突然感觉有点忧伤的就是，明明我来到了甲方，可是作为安全支持对接业务的时候，我好像又变成了乙方…实际情况想想也可以理解，因为安全是一个偏服务、支持类的工作，在服务于为公司创造营收的主营业务的时候，安全更容易处于“弱势”地位。好吧，为了爱与责任，只能“业务虐我千万遍，我待业务如初恋”。

最近拜读了几篇分享企业安全人员日常工作的文章，比如友田的这篇《卧底“一个人的安全部”，我发现了某些大秘密》，以及“他们都叫她女神”的这篇《安全的价值》，读完很有感触。回想这两年在企业做安全建设、推动安全方案、以及与业务打交道的经历，从职场萌新混到了“老油条”，作为安全工程师，也慢慢学会了如何“体面”地与业务打交道。于是便写了此文，闲扯一下。

0x01 安全与业务的关系

举一个我经常喜欢说的例子，比如下边这张图，你过桥的时候会扶着栏杆吗？

我在现场讲安全培训的时候，也问过很多同事扶不扶，大家反馈除非靠在桥边看风景，基本不扶。

好吧，那如果桥上没有栏杆，你有没有一些忐忑呢？就像下图这样。

我觉得对于用户来说，产品和信息安全，就像是桥和桥栏杆，行人过桥的时候可能很少扶着栏杆，但如果桥没有栏杆，碰巧行人安全意识也比较薄弱，很可能就会出现安全事故。

《白帽子讲Web安全》那本书里说过，当一个产品其他方面都还可以的时候，那么“安全”也应该成为产品的一个重要属性，甚至也可以成为产品的一项核心竞争力，比如对于电商来说，支付安全、用户账号安全、订单数据防泄漏等，这些安全能力建设就可以成为电商业务的核心竞争力。

但实际的情况呢，因为很多做技术的处理人际关系会比较僵硬。很多安全人员也有一个误区，就是把安全放在业务的对立面上。经常对业务同事说：你们应该如何如何…应该这么做否则就会被黑…然后业务同学觉得安全根本不了解业务场景站着说话不腰疼…然后安全和业务就互相觉得对方是sb…

我觉得互联网公司中，安全本质还是为业务服务。

作为安全人员，我们要有一种 安全合伙人（SecPartner）的概念，我们是要帮助业务解决问题，在一个战壕里战斗，而不是在一旁指指点点。明确我们的初衷是给业务帮忙而不是添乱。

交流的时候，面对业务，不要再用“你们”，而是用“我们”、“咱们”，换位思考，先理解实际的业务场景与安全风险，如果你的安全建议提的很专业，很接地气，那么，我觉得业务人员不仅会接受，而且后面推动实施的时候，研发和运维同事也会觉得掌握了更好的编码技能或者安全配置技能而产生正向的驱动力。

一旦合作的过程中，对方认可了你的专业与态度，那么以后合作会越来越信任和默契。

当然，作为安全人员，如果觉得自己水平不足以提出好的解决方案，就努力把存在的安全问题和业务童鞋解释清楚，只要他们对安全风险的本质认识到位，很多情况可以从业务的角度提出更适合的解决方案，然后咱们一起论证。

切忌不懂装懂，提一些纸上谈兵的方案。至于水平，慢慢积累修炼就好。

当然，安全在支持业务的时候，生气总是难免的。

比如我原来做安全测试和漏洞推修的时候，也会遇到下边这种情况。

5月份发现的漏洞，业务9月份直接“标记忽略”，而且对方连话都不想和你说。我能说啥，我只能回一句扎心了老铁，然后确认忽略…

还有这个，直接“内部系统，开发不修了”…我心里多少头羊驼奔腾，当初是你让测试，测试就测试…..

我就想拿着某次去阿里参加安全会议送的扇子去找业务理论。

信不信我扇你。

后来我一想，研发也不容易，排期紧张，而且动不动就要被拉去祭天。

这个时候我就要反思了。

我是不是陷入了“安全好治无病以为功” 的陷阱

其实有些问题，从技术上看确实是安全漏洞，但是从业务风险来看，可能问题并不大，甚至修复的成本比可能造成的损失都高，这种确实可以风险可接受。

既然生气总是难免的，那生过业务的气之后怎么办呢？

当然是原谅他。

以后业务有安全需求了还是要好好招待。

我觉得作为甲方的安全工程师，不光要关注安全技术本身，更重要的是要理解安全和业务的关系，和产品业务方沟通的时候，应该多一些真诚，少一些套路，有一个安全建设者的视角，以安全合伙人（SecPartner）的态度，思考如何帮助我们的产品更健壮，让我们的业务更健康。

0x02 如何输出更易被业务认可的安全方案

1、“正确解”与“最优解”

首先我们需要理解的就是解决安全问题的“正确解”与实际可以落地的“最优解”往往是有差异的，我举个例子说明：

你觉得服务器需要装杀毒软件吗？

首先，客观上来说，服务器也会面临恶意代码的威胁，比如webshell、挖矿程序、rookit后门、病毒、木马等。所以不管是从政治正确的角度来说，还是参考各种安全体系标准，服务器上安装杀毒软件都是一个正确解。

但是实际情况呢？

对互联网公司来说，追求高性能与用户体验，这就需要生产服务器的计算能力要大部分留给处理业务需求，如果服务器的安全防护程序的性能消耗超过10%或者5%，或者因为安全方案的性能消耗导致业务出现卡顿，那这个方案就是业务不能接受的。实际在生产服务器的计算资源上，留给安全的及其有限，所以直接在服务器上安装杀毒软件目前看来不是业务能够接受的，它不是一个最优解。

那恶意代码的防护需求有更好的解决思路吗？

一个可行的做法是，将防范常见恶意代码的功能做成模块，集成到服务器的入侵检测终端程序中，终端的入侵检测程序要做的也主要是记录服务器的一些状态和日志，而且为了降低服务端的性能，尽量不在本地分析计算，而是将日志返回给后端的安全分析服务器，做进一步的分析和处理。

这种安全方案，既考虑到了恶意代码的检测与防护，又降低了生产服务器的资源消耗。平时在与一些安全厂商的交流中，也注意到一些安全厂商在给企业提供安全产品时，也考虑到了降低服务器资源消耗的需求，有些产品都设置了自杀机制，比如当自身资源消耗超过10%，服务器又比较忙碌，就将自己的进程kill掉，将资源让给业务。

上边这种解决服务端恶意代码的方案就是更易被业务接受的可实施的最优解。这里的“最优”不一定最好，主要想表达的意思是业务可接受实施可落地。而且最优解往往也不是最安全的解。

2、是“治标”还是“治本”

这里我要先讲一个小故事：

有次我重感冒，鼻塞很难受，去看医生，医生是怎么给我治疗的呢？

他先是用一个长得和眼药水差不多的滴鼻液，在我鼻子里滴了几滴，很快就帮我缓解了鼻塞的难受，畅呼吸。然后又给我开了缓解感冒的药，告诉我按时服药、近几天如果鼻塞难受就再用滴鼻液缓解。

这个例子中，滴鼻液起到了一个临时缓解鼻塞的治标的作用，缓解感冒的药就是治本的作用，医生的方案对我来说就是标本兼治。

安全也一样，出现安全问题，我们也要知道什么时候需要治标，什么时候应该治本，什么时候可以标本兼治。

就像我们处理漏洞应急的时候，假设发现了一个服务端的安全漏洞，修复方式可以有多种，比如：

1）改产品代码；
2）改服务器配置；
3）有WAF（Web应用防火墙）的话，直接加条过滤规则。

治本当然是在代码层修复，但是这个方案代价也最大，修复代码、排期迭代上线，而且研发作为唯一的生产力可能排期也很紧张。
如果运维更新服务器配置能解决也行，但是要考虑到是临时更改还是要加到安全配置基线里，配置更改后会不会对其他功能造成影响。
如果有WAF的话，最快的方法就是临时加条规则进行拦截，也叫“虚拟补丁”，这种很快，但是是治标的方法，也可能被绕过。

实际的应用中，比较靠谱的做法是，先通过WAF或者运维配置，临时控制安全漏洞的风险，然后让研发评估修复成本，排期迭代修复。这是比较理想的状况，实际的情况就需要因地制宜随机应变了。

3、“均码”与“量体裁衣”

我们买衣服会考虑尺寸，有的衣服就只提供了均码，身高体重在一个区间里的都可以穿，有的衣服就有更细分的尺码，消费者能选择更合身的尺寸，当然，也有那种量身定做的衣服，同时这种服务和产品就比较贵。

其实大的互联网公司，也往往有为集团输出通用安全方案的通用安全团队，以及重要业务自己组建的能为自己提供定制化安全解决方案的自建安全团队。

一些广泛的差异化小的安全需求，比如漏洞扫描、数据防泄漏、终端和服务器的安全配置基线等，通用安全团队来提供解决方案就比较适合，性价比高边际成本低，比如对A业务的数据防泄漏方案，稍加改动就能适合B业务。

而对于业务来说，通用的安全需求可以直接对接集团的安全团队，如果有自身定制化很高的安全需求，通用安全团队资源又不够的，就可以自己组建专门的业务安全团队，解决业务的定制化安全需求，比如SDL（安全开发生命周期）、一些独特业务场景下的风控等，从而为业务提供更贴合的定制化安全解决方案。

说到这里，我又想起了一个自己嗓子疼的例子：

大学毕业期间，有一次嗓子疼，我就去看医生，医生发现我喉咙有些红肿，给我开了消炎药，我回去吃了几天嗓子慢慢不疼了。

结果不到1周，我再次嗓子疼，这次我换了个医院。去看医生的时候，医生仔细观察了我的情况，先是问我这几天吃了什么东西，我当时觉得挺奇怪的，不就是嗓子发炎了吗开点消炎药不就行了，但是我想了想还是如实回答了，就是说因为是毕业季吗，同学聚餐喝酒较多，那几天吃的也都比较丰盛。

然后医生又观察了一会，最后和我说：你这不是感冒发烧引起的嗓子疼，也不是嗓子发炎，你是因为最近饮食吃得比较多，睡觉可能姿势也有些问题，导致胃液反流到喉咙，蛰的你嗓子疼。我给你开一盒消解胃液的药。

我当时就觉得这医生比较专业，比较靠谱，诊断地也比较仔细。遵医嘱吃了胃药后，当天症状就明显缓解了。

好了，故事讲完了，你知道我想表达什么吗？

其实可以引申的点有很多，我简单说几个，比如：

1、同样的安全事件，根因可能会有不同，需要安全工程师根据专业知识以及对业务场景的调研来给出更专业更本质的解决方案，而不是头痛医头脚痛医脚治标不治本。

2、通用的安全方案通常没有量身定制的安全方案效果好。

3、一些KPI的导向可能会使得员工有不同的表现，比如如果医生的诊费很便宜，药品提成比较多，面对业绩压力他可能就会想尽快结束每位病人的诊断时间，给个差不多的判断然后给你开很多药。如果医生的诊费很贵，同时KPI需要重点考核治疗方案的质量和治疗效果，然后他就愿意给患者提供更细致更认真的诊断服务，然后开平价的对症药品。其实有时候在企业和其他部门合作的时候，如果有一些现象感觉有点奇怪，不妨去想一想背后有没有一些特别的原因，比如合作伙伴自己的一些考虑和诉求，这里就不引申了，实际工作中总会遇到一些因其他原因导致的折腾。

讲到这里，再讨论一下，你觉得业务什么时候需要安全呢？需要什么款式的安全呢？

举个例子，如果业务有100万，你让他花2万买个保险柜，他是愿意的。而如果业务只有2万，你让他花8000买个保险箱，他估计是会抗拒的。

原来我们都说，业务自己还活不下去的时候，是不会太考虑安全的，就跟那个桥一样，先把桥面铺好能走，再考虑栏杆的事情。当然，近几年也出现过，初始的时候没考虑安全，导致出一些重大安全事件给业务造成了很大的打击。所以，安全其实也可以尽早考虑，尽早规划。

在安全方案的款式上，就像网易春风一样，安全方案有轻薄也有厚重，业务体验很重要。

有时也不禁感叹，都是做安全，大家对春风这种安全的重视程度和风险意识可比信息安全强多了。

总之，如果想输出更易被业务认可的安全方案，首先要明确安全角度的“正确解”不一定是业务接受并且可以实施的“最优解”，然后知道什么时候要“治标”什么时候要“治本”，同时在条件允许的情况下，更多地深入业务，了解业务具体的安全场景，从而提出更接地气的安全解决方案。

0x03 一些安全工作的感受与观点

首先想讨论的就是：

你觉得信息安全的目标是什么呢？

是没有蛀牙没有漏洞吗？是不出现安全事件吗？

当然我们有一个理想化的目标：

进不来，拿不走，改不了，看不懂，跑不了

很白话，我就不自己解释了，总之理想很丰满。

但是实际的企业安全建设中，我觉得：

信息安全的目标是：风险控制。用有限的资源投入将信息安全的风险降低到可以接受的范围内。

而且安全建设也要考虑性价比以及投入产出比（ROI）。

资源有限我这里稍微引申一下，如果要做SDL（安全开发生命周期），但是资源不够，那就可以根据实际情况做精简，比如：

这是相对完整的SDL流程：

根据实际情况，在资源和能力有限的情况下，可以因地制宜裁剪SDL：

而在实施落地的时候，可能会更精简。

那么安全什么情况下方便介入业务呢？我遇到的通常有2种情况：

1）和“钱（重要资产）”相关的业务发展迅速，安全问题暴露明显，业务主动寻求安全支持。
2）高危事件驱动，安全主动介入。

当然，对安全人员来说，如果是业务主动寻求支持，后续的合作会更顺畅一些。安全主动介入的话，如果安全的内部影响力不足，坑还是很多的，吃冷饭被敷衍也是正常情况。

所以，这个时候安全更喜欢被动。

好吧，我们回顾一下题目：如何“体面”地与业务打交道？

啰嗦了这么久，篇幅也很长了，能读到这里的估计都是老铁，这里就不继续扩展了，要不然到下个月也写不完~汗

分享几条我感受比较深的的关于企业内部安全建设以及如何与业务合作的心得吧：

• 3331原则：安全建设要想做成，30%看领导的决心，30%看业务与安全方案，30%看实施落地与运营情况，10%看运气。

• 安全建设目标：风险控制。用有限的资源投入将风险降低到可以接受的范围内。

• 防护策略优先考虑：如何缩小攻击面/风险面。

• 互联网公司中安全本质还是为业务服务。

• 安全可以成为业务和产品的一项属性与核心竞争力。

• 解决安全问题的正确解往往不是适合业务实际落地的最优解。

• 业务规模到一定程度，安全会上升为系统化和工程化的日常化活动。

• 根据业务情况和目标，安全建设是分阶段和分优先级的。

时隔，依旧认同唯品会安全大会上分享的那首诗：

方法都知道，落地很艰难。
领导不支持，一切都免谈。
除了靠自己，还得靠伙伴。

讲真，企业安全建设，知不易，行更难。打铁还得自身硬，安全部门要想工作推动更顺利，用实力和疗效赢得认可才是王道！

作为一个互联网安全小兵，在有限资源的情况下，日常致力于为业务寻求场景化的安全“最优解”，随着安全解决方案的实践与经验积累，越来越认同《白帽子讲Web安全》中的那些关于企业安全建设的观点：

1. 安全工程师的核心竞争力在于他对安全理解的深度，以及由此引申的看待安全问题的角度和高度。

2. 最可贵的不是那一个个工业化的解决方案，而是在解决这些问题时，背后的思考过程。掌握了以正确的思路去看待安全问题，在解决问题的过程中将无往而不利。我们不是要做一个能够解决问题的方案，而是要做一个能够“漂亮地”解决问题的方案。

3. 安全是一门朴素的学问，也是一种平衡的艺术。

唯有务实、努力。

共勉！

---

转载请注明出处 ：sosly 菜鸟笔记

电脑上也可直接访问博客（https://sosly.me）查看，如有内容更新以博客为准。点击原文链接即可跳转。

原文始发于微信公众号（sosly菜鸟笔记）：互联网安全小兵的日常：如何“体面”地与业务打交道