失业之前的安全工作总结

2019年结束已经几个月了，正好趁着在职最后一天，对上一年的工作做一个完整性质的总结及梳理。

如有不对之处还请各位帮忙扶正，不甚感激。

写这篇文章初衷有三个目的，总结自身工作内容、分享在工作中的经验、及...找工作。

遭受到袭卷全球的突发事件影响，给现就职的公司主营业务造成了打击。高层在本周不得不宣布整体中国区裁员百分之七十，以此来维持运转。

我不表态公司高层这样的决定是否正确，复工两周期间上班每人都发了口罩，对于被裁员员工均有不同的补偿金额（虽然下周一才轮到我们部门），在这段期间已经算是良心了，毕竟其他公司的坏消息太多了。

还差十七天在这家公司就满一年了，所以有JD吗？

目前人在上海，不过有湖南省的机会优先考虑。

入职初期

依托于前期的技术积累加上一点运气，在19年3月入职现在这家公司从事甲方安全工作。之前一直在从事后端研发工作（PHPer），期间出于兴趣爱好会做一些代码审计和渗透测试，顺利在补天爬到了685名（已经掉到800+开外了），通过代码审计拿到了三个CNVD的原创证书。

上面的成绩比起各位大佬来说不算什么，比如这样的：

只是想说明我是属于那一类从研发转安全，已 Web 安全爱好者的思维角度跳入甲方安全建设中去的，基本是从0开始步入到1的过程。

额，大体的描述下就是你在渗透测试过程中，突然有一天突破了站点的防御拿到了 shell ，可是你不会内网渗透陷入了知识盲区，空有一堆宝藏但不会识别，也不会挖掘。你不得不去花费大把的时间去研究内网信息收集、横向渗透、权限维持、端口转发、识别 DMZ 区等等等等。

所以我初期缺乏甲方安全建设方面的视野和格局，对甲方“饭碗”合规管制处于肤浅了解。通过从实际工作中去实践累计经验，一边根据CISP体系培训内容进行学习映照。

这里我总结了下初入甲方安全公司时，应该对你有帮助的三件事：

一、了解企业组织架构的组成及主营业务

这个应该是首先主动需要去了解和熟知的事情。一般通过入职时的新员工培训，或通过查看公司组织架构来获悉。随后你要明确职责，应该这会是你后面开展安全工作的主要交集人员。

比如你接到一个新的需求，要做某个事情并使他最终有效的落地。那么，你在调研、规划阶段就应该知道去找谁去沟通才有效，以及变更某一项东西时，需要对应部门的 VP 或者 Leader 知悉。不然不但耽误了时间，后续还会有扯不清的麻烦事。

在此基础上你要知道自己的公司主营业务有哪些，以及平时隐藏又不怎么关注的业务。因为你后期的安全工作大部分都是围绕业务资产来建设的。安全是保障业务资产的可持续性、完整性、保密性，如果核心业务受到破坏，连带你的支撑业务都会受到影响。反之，如果支撑业务受到了影响，是否有手段有技术保障主业务不受影响，甚至阻断该风险。

二、判断当前企业安全建设处于什么样的一个水准

可以从你的 Leader、已部署的设备、规范化的流程文档、网路拓扑图中获取到这部分的信息。这样能够可以快速的对其建模，用于评估当前企业安全建设处于一个什么样的水位。是起步阶段的基础建设阶段，还是安全运维、深度感知运营阶段。

这些都会方便以后你在安全建设中为企业的安全添砖加瓦，或者查缺补漏进行 “从无到有” 的过程。

三、积极参加项目需求评审、技术评审及安全评审

这个应该不需要过多的介绍了吧，通过这些评审会让你更快了解企业自身的业务域、产品线、产品形态，对后续的定级及支撑系统有个可评估范围。

另外就是你能快速在公司刷脸刷存在感，知道对应的应用owner是谁，出问题或沟通这块的需求知道找谁。

我是如何学习的？看等保及27000的指导文件、CISP教程及考题反向学习、搜索各种企业安全学习的视频、文档资料。结合日常工作印证是否完善。

安全运维工作

设备巡检维护

因为是外资企业，最开始拓展中国区时应用服务就已经上云。不过那时是部署在AWS上，我入职前已经全部迁移到了阿里云上，公司自身是没有应用服务器机房的，相对的减轻了后续拿认证时关于物理安全机房测评项。

Leader 也是有意的引导我，先对阿里云使用的安全产品及配置规则进行一波梳理，然后就有了下面这张图：

这些产品分别用来干什么？

既然已经上云了，那么安全产品也就选择同云的产品，毕竟后期的技术支和产品迭代会相对保障很多，不至于出现多家供应商直接互相踢皮球的情况（主要当时有钱，尤为记得在这家公司第一次参加 All Hands 时，CTO说我们有钱的那个画面）。

• 首先，线上的所有站点接入 HTTPS ，从 应用安全 上保护传输过程中的 数据完整性 、 数据保密性 ，对具有敏感信息字段的通信时，采用加解密技术保障 通信安全 。

• 通过将重要业务接入 抗 DDOS 产品、应用防火墙、爬虫风险管理 ，来保障 应用服务的可用性 ，同时保障 应用服务的资源控制 ，具备 外部入侵防范 。

• 通过专有网络 VPC 划分不同的子网，进行有效的 边界隔离防护 ，对特殊区域设置黑白名单进行有效的 设备访问控制 。

• 通过 RAM访问控制 对不同账号做不同的最小权限分配，强制开启双因素校验进行有效的 身份鉴别 ，这样不同业务域的人只能查看和使用他自己的云产品。

• 通过应用接入内容安全检测，对用户投递的文本内容、图片做有效的敏感 内容识别 ，同时也对 OSS 进行 内容的访问控制 。

• 安全组策略、安骑士、在加上运维部署的 ELK 、Zabblx 保障资源控制等。其中安骑士和云安全中心集合，可以满足主机安全的 入侵防范 ，如高危漏洞扫描、入侵事件及时告警、端口开放扫描等。

• 日志服务承载上述安全产品的所有日志的存储、查询、及告警策略，提供了 安全审计 保障。

渗透测试

定期会对 UAT 环境的全站点，分批进行渗透测试。已及时发现业务运维期间的安全问题，并发出安全风险通告，跟进应用owner最终修复情况。然后就有了这张图：

当然，我个人建议是入职后，在加深公司业务了解时可以进行适当的渗透测试，说不定就会发现意外惊喜。然后喜滋滋的去汇报，编写安全风险通告在 VP 面前刷个脸熟。这样也可以通过安全事件的形式，推动安全规则的制定和落地执行。

当公司体积和业务线庞大复杂时，只要预算够这种工作基本会通过外购渗透测试、漏洞扫描等服务解决，除非是在甲方中专门设有这么个岗位。

安全评审

这块属于日常工作范畴，一般每周会占用15%~20%的时间，对业务方提出的新需求、功能变更、产线变更、设置变更等都需要进行安全评估，这个环节可以说是比较容易体现出个人安全水平的。因为你要面临的业务需求是多种多样的，业务的组成交际域也是错中复杂的，你要和架构师一样了解架构、中间件、基础组件、不安全的协议等等.

对于我来说前期就是属于知识盲区，你要根据 PRD 、业务口头沟通需求时找到安全风险点，这属于日常 “ Battle ” 环节。

比如，业务因为种种需要将内网站变更成公网站，你怎么找出风险且让业务方放弃这个想法。或者要通过什么制度，来进行有效的控制。有没有做相应的操作审计？

其次需要评估流程中高风险功能，及可能存在的逻辑漏洞，并对本次评审提出安全解决方案给到业务方认领、执行。

这块就比较杂了，别动式的响应或处置事件。

• 比如通过近期接口日志、安全日志、审计日志，分析找到近期可能受到的威胁。

• 对安全事件的响应，比如 Github 代码泄漏、流量攻击的应急处置。

安全项目

DLP&AV

入职那个月正好在进行数据防泄漏 DLP 的项目，需求的背景是建立在防止数据泄露事件的发生，防止内部的商业机密及内部数据外泄，做好线下安全防护起到纵深防御的效果。

需求由安全团队发起并负责技术选型、安全架构设计，再由 IT 团队负责 DLP 项目的实施和维护。定期汇报管理层，好获得项目推动、协调资源与确认业务优先级。

一起三款产品（趋势、Symantec、McAfee），我主要参与的是 McAfee 这个产品的技术选型工作。

办公网络是基于租借的办公场地做的网络部署，三个网段相互隔离（两个公共网段：一个是办公场地自有的，一个我们的自己的。以及一个Work网段：办公网络，基于钉钉做了准入），设备的操作系统主要是两种：Mac 和 Windows，IT 对电脑的客户端软件没有做限制，但主要还是集中在钉钉。

基于上述场景下，办公网络可能会泄漏的方式为：

• 通过钉钉，微信，qq，等常见聊天通讯工具的将敏感信息外泄 。

• 通过个人邮箱（outlook,阿里云邮箱客户端，QQ邮箱）将敏感信息外泄 。

• 通过线上网盘（百度，新浪，115等主流网盘）将敏感信息外泄。

• 通过U盘等移动，等等......

对上面所需需求做个DLP功能对比打分表格，从架构、客户端、服务端三个维度进行需求评分，随后在三个产品见进行比评。比如：

• 架构是否支持C/S、B/S等问题

• 客户端是否覆盖全面的邮箱或通讯软件

  系统 补丁推送、安全事件上报、 水印等问题

• 服务端是有三权分立等问题

杀软需求也是一样的，完善了一份AV需求POC表格。比如：

• 架构是否支持自定义策略推送等问题

• 客户端离线查杀率、在线查杀率、防火墙和入侵防御功能支持等问题

• 服务是否具备入网终端主动发现功能、终端节点数量支持等问题

安全检测

在7月至9月，给予 Django 框架写了一个内部的安全扫描平台。用于敏捷开放带来的软件开发周期缩减，一人盯多人的代码审计显然不行。所以需要改进当时代码扫描的方式，通过持续继承/持续发布来自动触发扫描，安全只需要对结果进行审计，核对是否存在安全隐患，逐条核检查分析缺陷引起的安全漏洞。除了白盒方面的检测还有黑盒检测。

白盒检测方面公司当时用的是 SonarQube ，主要是质量团队在用，安全这边基本没用。然后分给我去整理 SonarQube 中的安全扫描规则，调优 Sonar way 规则。

瓦特？没用过，好方啊。赶紧搭建一个，导规则拉代码进行扫描，然后将不同编程语言的高缺陷规则整理到列表里，一条条进行核对，对不符的规则进行降级。

整体将规则梳理了一遍，在这过程中发现如果我需要自定义扫描规则，会存在一定的上手开发难度。干脆我重新开个项目来弄吧。

然后整理需求写文档，整体的架构是这样设计的：

最终部署关系图是这样的：

流程的发起主要来源于两个地方：

• 登陆平台设置黑盒、白盒扫描目标及定时检查任务，任务执行完成后会进行结果通知

• 运维发布平台在构建发布任务时，调用扫描API接口触发对应的异步扫描

扫描任务完成后，会对发现的漏洞详情做存储，做为安全知识库的一部分。漏洞会关联上对于的项目负责人，推送漏洞详情让对方验收。

如果有对这个感兴趣的，后面我会单独写一篇详细的文章

等保及27000认证

等保三级

等保保护备案是在19年8月底发的证，当时还是按照1.0的标准来做的。ISO27001是在今年的1月3号发证，目前均是2013标准。

很有幸，我全程参与配合其中。做这两个证的目的主要原因有几个：

1.满足国家对企业所处行业上级主管部门的合规性要求

2.完 善安全管理制度使其有体系 规划

3.完善常态化审查机制，安全自检

等级保护定级的原则，是根据定级对象在受破坏后综合判断对社会、公共利益即国家安全的侵害程度来定级。对应用综合评定后，我们是按照等保三级来做的。

在提前完善好等保关于技术、管理安全建设落实执行后，准备填写好的等保备案表、纸质盖章材料就可以按流程向上级部门申请等保测。

经过专家初次的现场检测评估后，最后提出一些差异改进项。比如：

优先修复所有高风险项，其余风险项可以根据自身业务场景归为可接受风险（有一些控制点更具不同情况会比较难落地）。

在第二次的现场测评时，核对控制点是否修复缺失材料是否满足等等。以上完成后最终会给你两样东西：一本装订厚厚的《信息系统安全等级测评报告》，拿介绍信去所在地网安总队自行领取备案证明。

27000

等保的时候说了这是一家跨国企业，后续如果在战略上需要在业务扩展、对外公信度等层面上，安全需要有一个国际体系认证做为支撑。

是一个建立、实施、运行、监视、评审、保持和改进的模型体系（ISMS），通过PDCA（Pla、Do、Check、Act）过程模型有效的运转，通过循环不断前进、不断提高。做 27000 也有很多好处的，比如：

1. 对照标准建立消除制度盲区，使之更健全

2. 完善安全管理水平

3. 了解你们公司的重要资产

在申请27000认证之前，你应当先已依照 27001 标准要求搭建好的体系，并良好持续的运行三个月以上（可根据认证公司的认证流程，准备好相应的材料）。

它是重文件化的体系，在体系运转期间需要产生执行过程文档。而这些文件是否完整及足够，都将做为审核是否成功的依据。

额.. 它涉及的文档有多少呢？根据适应性声明你要有对应的关联文件，可以看看：

然后你就着有审核机制的公司申请了，填文件收集材料，接着向下进入预审（可不错，收费的）、现场一审、现场二审。

在此之前，注意控制好认证范围和支撑认证范围的部门人数，免得出现什么变故。

根据审核通知，会告知一审的审核老师联系方式及审核日程安排。记得提前申请好当日的会议室，与各部分负责人协调好时间配合问询工作，首次和末次会议都需要重要企业领导到场，或代管到场。

一审和二审都会在最后给出整改事项，我们还好一审没有不足项，就是需要补充部分合同材料证明。二审时间很长（三人进行了三天的审核），审核的控制措施及合同非常多，通过问询的方式套你话，你说有这个他就会让你给他看这个。

完了后会在末次会上，给出不符合项清单要求整改：

拿到纠正措施后手写表格内容，提供修正措施过程材料证明盖章回寄就可以了。

人机防护

这 个项目应该算是应急响应的场景下，紧急加的安全需求。每个月我们都会上营销活动，经过持续的日志观察分析发现，活动持续受到羊毛党的攻击。

 对活动整体进行了一次分析：

这是某此活动，在凌晨30分钟内的关键API请求次数：

按道理这应该属于风控部门的范畴，但他们那边建设不完善，我们就拿过来做了。

之前对全站及网关加了防爬服务、Waf、高防，结合阿里云自身的威胁情报可以做到Web应用防护、扫描器阻断、目录扫描防护、CC限速、地域封禁、黑白名单等，可以防御较多的黑客攻击行为。

在这里分了三步加优化建设：

1. 增加了防爬服务中的APP增强防护，增加防护SDK对活动的主要接口增加非法签名校验，阻止模拟器及客户端代理。

2. 用户交互增加人机验证码，阻断灰产通过机器模拟真人大批量操作。

3. 增加活动参与门槛，对已标记的恶意用户生成虚拟数据进行误导。

人机防护是阿里云的业务安全功能，最开始是希望业务在活动主要交互功能 中，接上滑动验证来保障。业务方阻力挺大的，增了拉新活动流程认为不友好，没办法只能上无痕认证。

效果有用吗？当然是有用的：

风控也会在提现、发卷等关键环节设坎，这样的结果就是引起羊毛党的反弹。客诉被刷爆，羊毛党开始在贴吧里大肆庆祝。

你们的线报群、线报网站真当我看不到的啊？这次体验真的让我感觉到与羊毛党的对抗持久性、重要性。

其实不想写上这个的，有天早上上班的路上 R3start 给我发来一段圈子的聊天记录，被狂喷。印象非常深，多少打击了当时工作的积极性。哎...

数据安全治理

背景是在满足监管合规、业务核心资产保护、敏感数据保护的三重场景下，安全牵头建立敏感数据治理项目。已围绕核心资产建立数据安全治理模型，建设数据安全全生命周期保护。

从企业安全建设开始之初，我们就在一直在持续化做这个事情。主要从敏感数据识别、敏感数据保护、敏感数据审计、敏感数据响应，这四个纬度进行数据安全治理，解决数据传输、业务处理、存储、使用和销毁整个生命周期安全解决方案。

比如对数据传输的安全解决方案：

• 需要全站 HTTPS/SSL ，保证密钥大小要 2,048 位以上

• CDN的安全可以考虑SRI策略、Keyless SSL

• 双因素认证

• 等等

并不需要一次性全部铺开，但需要有计划的持续落地建设，先做“从无到有”后面有时间了在做细节优化。

在这里由衷的感谢，感谢这一年的照顾及点拨，感谢提供了一个实践的平台。这一年里一起干了很多事，还有挺多零零碎碎的东西我就不一一列举了（比如建立外审人员的数据安全屋需求、敏感信息治理、安全编码培训、人员安全意识培训等等...）。

首先对我帮助最大的应该是视野上的开阔，甲方安全工作不像我之前做研发。不能持续聚集在一个点上，要有架构师的思想。其次是对制度、流程、技术的一次理解，加深了安全意识。

不过更多的是心底的那份遗憾，按照安全规划今年还要做很多事情，有需要优化也有需要建设的...

管理和技术那个重要？有技术缺少管理是不行的，有管理不配上对应的技术去实施也是不能独活的，所以两个都重要。

在企业安全的运维期间，要持续检查业务点可抗拒风险的程度。从而调整安全建设工作的优先级，不要在其他方面留下短板。会有持续不断的内因、外因在被发现，而安全工作就是要解决她们，让她们长期处于一个受控及可接受风险的状态。

同样的，有做的好的东西也就是做的不足的东西。比如我最开始很多事情当初做的时候，属于囫囵吞枣的闷头干，做着做着会发现各种艰难。但坑踩着踩着也就知道怎么应对它。伟人不是说过吗：只要思想不滑坡，办法总比困难多。

多请教、多沟通、多学习、多总结