首先，知道业务有哪些，有多少资产，然后是数据的流向，知道要分析哪些流量。想要发现什么，阻止什么。其实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%)。
但是在现在这样的环境里，很多事情都是步步维艰。只求做好自己的事情了。
