"野路子"企业安全架构设计

[mylamour]

首先，知道业务有哪些，有多少资产，然后是数据的流向，知道要分析哪些流量。想要发现什么，阻止什么。其实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版本的设计

这是一个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小时，更像是技术交流，互相切磋(被虐底层虐惨了，好多不知道，内存崇拜)。最后是云舒大大面，非常开心和云舒大大聊天。不过最后因为我那天搬的家，就没办法去杭州了。总体来说，这次的面试体验极佳。

• 其实见贤思齐焉，见不贤而内自省也。在当前的环境下，学习到的很多东西，都在不时的提醒以后决不可如此。

• 搬家一上午，瘦了四斤。应该是脱了四斤水.....

[Pa55w0rd]

大佬，能转发吗

[mylamour]

@Pa55w0rd 可以转发，但需要注明出处。issues最好能用来讨论主题相关的内容， 其他交流可以通过邮件等方式。

[mylamour]

现在看之前的文章，还是有很多值得改进的地方。增加更新：

• 什么是安全架构 https://iami.xyz/Security-Architecture-Review/
• 什么是安全架构二 http://iami.xyz/Security-Architecture-Review-II/

[mylamour]

补充： 有时候你以为这是野路子，没想到他确实另一种方法。直到我最新学习了六西格玛方法论，才知道这个就是六西格玛法中的一种思考方式。又有感于TOGAF的学习，不禁反思，似乎学习了框架之后又缺少了思维的灵活性和跳跃性。无论是锤子还是钉子，都应该审视自身，然后审视自身之外。亦或反之。