失业之前的安全工作总结
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接口触发对应的异步扫描
扫描任务完成后，会对发现的漏洞详情做存储，做为安全知识库的一部分。漏洞会关联上对于的项目负责人，推送漏洞详情让对方验收。
如果有对这个感兴趣的，后面我会单独写一篇详细的文章
等保三级
等保保护备案是在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. 增加活动参与门槛，对已标记的恶意用户生成虚拟数据进行误导。
人机防护是阿里云的业务安全功能，最开始是希望业务在活动主要交互功能中，接上滑动验证来保障。业务方阻力挺大的，增了拉新活动流程认为不友好，没办法只能上无痕认证。
效果有用吗？当然是有用的：
风控也会在提现、发卷等关键环节设坎，这样的结果就是引起羊毛党的反弹。客诉被刷爆，羊毛党开始在贴吧里大肆庆祝。
你们的线报群、线报网站真当我看不到的啊？这次体验真的让我感觉到与羊毛党的对抗持久性、重要性。
背景是在满足监管合规、业务核心资产保护、敏感数据保护的三重场景下，安全牵头建立敏感数据治理项目。已围绕核心资产建立数据安全治理模型，建设数据安全全生命周期保护。
从企业安全建设开始之初，我们就在一直在持续化做这个事情。主要从敏感数据识别、敏感数据保护、敏感数据审计、敏感数据响应，这四个纬度进行数据安全治理，解决数据传输、业务处理、存储、使用和销毁整个生命周期安全解决方案。
比如对数据传输的安全解决方案：
需要全站 HTTPS/SSL ，保证密钥大小要 2,048 位以上
CDN的安全可以考虑SRI策略、Keyless SSL
双因素认证
等等
并不需要一次性全部铺开，但需要有计划的持续落地建设，先做“从无到有”后面有时间了在做细节优化。
在这里由衷的感谢，感谢这一年的照顾及点拨，感谢提供了一个实践的平台。这一年里一起干了很多事，还有挺多零零碎碎的东西我就不一一列举了（比如建立外审人员的数据安全屋需求、敏感信息治理、安全编码培训、人员安全意识培训等等...）。
首先对我帮助最大的应该是视野上的开阔，甲方安全工作不像我之前做研发。不能持续聚集在一个点上，要有架构师的思想。其次是对制度、流程、技术的一次理解，加深了安全意识。
不过更多的是心底的那份遗憾，按照安全规划今年还要做很多事情，有需要优化也有需要建设的...
管理和技术那个重要？有技术缺少管理是不行的，有管理不配上对应的技术去实施也是不能独活的，所以两个都重要。
在企业安全的运维期间，要持续检查业务点可抗拒风险的程度。从而调整安全建设工作的优先级，不要在其他方面留下短板。会有持续不断的内因、外因在被发现，而安全工作就是要解决她们，让她们长期处于一个受控及可接受风险的状态。
同样的，有做的好的东西也就是做的不足的东西。比如我最开始很多事情当初做的时候，属于囫囵吞枣的闷头干，做着做着会发现各种艰难。但坑踩着踩着也就知道怎么应对它。伟人不是说过吗：只要思想不滑坡，办法总比困难多。
多请教、多沟通、多学习、多总结