转载

失业之前的安全工作总结

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

  • 双因素认证

  • 等等

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

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

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

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

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

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

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

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

相关文章

原创   为 web 安全初学者准备的新春礼物

失业之前的安全工作总结

原文  https://mp.weixin.qq.com/s?__biz=MzI5MDQ2NjExOQ==&mid=2247492455&idx=1&sn=9110f2302af57911b47906ad926bb5e8&chksm=ec1dd34fdb6a5a5925106dcedb75f5aa7e7298e89bb4b57e7eb013891226830d2d494b3f393a&scene=0&xtrack=1&clicktime=1584712079&enterid=1584712079&forceh5=1
正文到此结束
Loading...