事实上目前整个互联网安全体系的整体设计重心偏向入侵检测，而不是太多的防御。根本原因只有一个：
安全手段是适应和服务业务的，没有业务那安全就是无根之水。
对于全部业务都是 Web 服务的公司来说，除了 WAF 和 RASP 会做比较强力的防御拦截之外，基本就没太多做主动阻断的安全手段了（实际上还有L4防火墙 加固一类的，不过和业务相关的大头基本就是 WAF 和 RASP）。因此，本文从我做入侵检测的经验入手，给大家介绍一下我的设计思路和具体实现。
入侵检测需要检测的数据源
建设一套技术上有效的入侵检测系统一定要先提前弄清楚业务流程、数据流向和基础架构。因此需要采集至少以下数据：
安全基础设施和服务：包括但不限于EDR、Firewall、IDS和WAF日志
网络基础设施和服务：ELB 负载均衡、CDN 和反向代理日志等
Runtime Env：RASP 、 Web 服务器的运行时环境和 Web App 的日志等
DB：RDS 和 KV 类数据库的访问模式和查询日志等
已知漏洞：这里实际上是说对内做的漏洞扫描日志记录等
配置：实际上配置项不应单独列出，但我发现大家都不太爱收集对操作系统和应用程序的配置更改日志，但这一点对入侵检测很重要，通过看配置是否被改还是能发现很多威胁的，例如对 Linux 下 kptr_restrict 值的大概率是异常的，需要运营看下到底什么情况。
资产：设备接入、网络接入、资产变更等日志记录
以上是建设一套有效的入侵检测系统所需要收据的数据项和一些例子，但这里需要注意一些问题：
如果团队不够大，那就暂时放弃收集一部分日志，举一个不恰当的例子就是放弃开发、测试、办公网的入侵检测，只看生产；或者做好风险评估之后，干掉非核心系统、低风险应用、第三方应用的入侵检测。这里还是要具体业务具体分析，我们要知道核心业务是什么，哪些数据库被拖了会出大事，哪些边缘应用暂时无需关注，因此假设人力极度不足，安全投入特别少时候，我们只需做到不让黑客操作数据库和虚拟机就行了。
我们是想建设更有效的入侵检测系统，那就需要持续运营这个系统，否则做完了系统直接丢一边，安全设备挂掉了没人发现更离谱
无效的入侵检测系统是，日志收集的大而全，所有的协议、所有的行为乱七八糟一堆告警，真正有效的告警被一大堆误报淹没，这时候就可以宣布失败了！如何解决呢？做好纵深和数据关联！在流量进来的每一步做好过滤，尽量缩小供给面，使用漏斗滤除数据，入侵检测需要的覆盖面（广度）和检测层次（深度）上随着攻击面的缩小就会大幅缩减。其次把数据多关联，例如通过规则做关联，通过 trace id 或者 IP 都能关联一条链的数据，再高阶一点就是行为分析和机器学习咯。
从攻防视角再看看入侵检测
抽象的看，外部到生产网的流量是先过抗D，到防火墙（ACL之类），到应用层，再到实际应用。
那我们做入侵检测时，就先按照攻击者的常规思路走一遍，每一层都做好数据收集，按照前面说的，第一步先做好最核心的主机和数据库层面的日志收集审计，第二步按攻防视角对攻击者会经过的每一条链路做好日志收集审计，最后再去追求完善大而全的入侵检测系统。
再说说 NIDS 和 HIDS
我前面说的入侵检测没怎么提到 NIDS，倒不是我故意想弱化这个概念，只是一方面 NIDS 和 WAF 的效果有部分重合；另一方面公司提供的对外服务几乎都是基于 Web，所有非 HTTP 和 S 的协议都被过滤掉了，NIDS 显得不是特别重要。
HIDS 这种基于主机的入侵检测就相对更重要，入侵者已经到了主机层，已经很接近核心资产了，这里如果不设防不记录，那入侵者留下日志、进程、命令、网络等安全团队就完全不知道，后续取证很难很麻烦。
后记
关于误报这一块全靠运营，搭建系统前期的误报只能一条一条看，一条一条改规则，例如我上家公司内网机有过的文件篡改误报，由于用的是机械盘，有一个盘快挂了，文件哈希每次算出来都不一样...换了块磁盘就好了。
在实际运营的第一天误报极多，只要运营跟得上按需调优即可，收敛速度还是蛮快的，不过解决误报这一块我也没啥太好的解决方案，要说行为检测机器学习之类的手段在前期也不太可行，没数据这些都玩不转。
顺带再说几句关于 SOC 的吧，其实做安全基建的初期完全没必要做 SOC，不要信厂商的忽悠！日志成千上万，基础的数据源和告警的误报都没解决的时候，纵深防御体系还完全没弄起来，等于你盖楼想先盖第二层，第一层还没建好，这肯定是不靠谱的行为。