Open mylamour opened 6 years ago
大佬,能转发吗
@Pa55w0rd 可以转发,但需要注明出处。issues最好能用来讨论主题相关的内容, 其他交流可以通过邮件等方式。
现在看之前的文章,还是有很多值得改进的地方。增加更新:
补充: 有时候你以为这是野路子,没想到他确实另一种方法。直到我最新学习了六西格玛方法论,才知道这个就是六西格玛法中的一种思考方式。又有感于TOGAF的学习,不禁反思,似乎学习了框架之后又缺少了思维的灵活性和跳跃性。无论是锤子还是钉子,都应该审视自身,然后审视自身之外。亦或反之。
首先,知道业务有哪些,有多少资产,然后是数据的流向,知道要分析哪些流量。想要发现什么,阻止什么。其实Google的OKR也可以在这里应用。例如,安全架构的OKR可以这样:
O: 发现入侵者,减缓或者阻断攻击,以及取证。 KR: 资产管理系统 --------- 19% KR: 入侵检测系统 --------- 19% KR: 日志收集系统 --------- 19% KR: 关联分析系统 --------- 19% KR: 应急响应系统 --------- 19%
但,即便都做了,也不能100%保证不出问题,还需要做定期的渗透测试。我们先按照这种思路,画出类似的OKR图
O: 日志收集 KR: 明确数据流向 --------- 50% KR: 明确收集类型 --------- 40% KR: 明确收集方式 --------- 5% KR: 明确存储方式 --------- 5%
其实我之前画的时候,是先画的脑图,分析下当前系统拥有的哪些资产以及所需的对应的措施。然后绘制的。下图就是结合现状列出的日志列表。
明确了各个部分之后,其实整个系统就有点呼之如出了。但是即便如此,之后还是需要进行修改,此时可以去继续和其他部门进行沟通,比如说我之前就先和区块链代理组沟通对方的架构,和产品经理沟通关键业务有哪些,又和运维沟通,让其统计出相应的资产。跨职能沟通并不是一件容易的事,碰到sb的话就更困难了。
下面看一个V1版本的设计![image](https://user-images.githubusercontent.com/12653147/43367427-2ea05d7c-937f-11e8-8d5a-6c923c6b99a3.png)
这是一个V2的版本设计,修改后的,明显的对比是增加了蜜罐系统,复用威胁情报,以及补上了内网的IDS系统。
当然具体到落地实现,还需要不少东西,比如说,是否是要修改开源ids,使agent监听某个服务,一旦更新规则,自动发送到每台机器。或者说ossec、suricata已具有这些功能,以及关联分析的时候,怎么选择适应的算法,并降低误报和漏报,引流到蜜罐系统等等,不一而足。以及自动化的部署更新。每个模块其实都需要一个人或者几个人去负责,但是作为一个人的安全部,能做的就是按照轻重缓急,自己排期进行。
你应该还能看到这里其实还缺少SDL相关的设计以及落地。还有就是切记不能忘了安全系统本身的漏洞问题,不要因为具有高权限的安全系统本身有问题,导致从该点被攻破。在日常的设计中,20%的防御做好就能抵挡住80%的攻击。 比如说 生产环境的CDN + WAF 1+ WAF 2 + IDS。测试环境的ACL,这些最基本的防护足以抵挡80%的攻击,甚至90%。但是作为一个安全人员,我不希望看到的是,做到这20%就结束了,出现问题就跑路(引咎辞职其实是很不负责的行为), 而是应该专注于剩下的80%,怎么做好,做的更好。不仅从工具上(很多人喜欢安装一套又一套的系统,以其展现的报表去谋得赞扬。而不是通过跨职能的沟通和设计适合自己系统的安全架构和SDL流程去做剩下的80%)。
虽然名誉上也算是安全负责人,但是在现在这样的环境里,很多事情都是步步维艰。只求做好自己的事情了。
其他(技术无关)
面了默安,本来是安全研发,然后研发老哥发现更适合做安全研究,就和hal0eye聊了下,之后老大找 king's way 聊了2小时,更像是技术交流,互相切磋(被虐底层虐惨了,好多不知道,内存崇拜)。最后是云舒大大面,非常开心和云舒大大聊天。不过最后因为我那天搬的家,就没办法去杭州了。总体来说,这次的面试体验极佳。
其实见贤思齐焉,见不贤而内自省也。在当前的环境下,学习到的很多东西,都在不时的提醒以后决不可如此。
搬家一上午,瘦了四斤。应该是脱了四斤水.....