系统设备产生的日志，如果在攻击事件中被清掉了，有没有什么恢复方法？一般日志管理这一块平时应该怎么做？

A1：

要不上日志审计设备，要不统一备份日志到专用服务器。

A2：

日志Syslog或者Kafka发到态势感知平台，为提升查询效率，数据量大可考虑冷热数据分离存储（冷数据：长周期数据，如1-12个月；热数据：短周期数据，如1个月内的数据），流量或者行为数据缩短保存周期。

A3：

重要日志需要推到集中的日志平台，有商用的方案，也可以自建ELK那一套，可以加上各种Beat，也是够用的。

A4：

硬件设备Syslog发送存着就好。如果是主机的话，HIDS都会收集这些日志存到服务端的，为的就是避免日志被篡改。日志管理就是SIEM那一套了，ELK或者商业化产品。

A5：

日志被删除了，如果没被其他数据覆盖的话可以尝试数据恢复，但是一般不推荐这样做，这是靠运气，靠不住啊。所以才有了SOC，SOC除了安全综合分析、运营的作用，也可以作为安全日志数据的备份，防止原始日志被删除。

A1：

SOC接入主机防护、防火墙、流量分析、日志审计等安全设备日志。

A2：

个人还是倾向于安全设备、网络设备和主机设备日志比例 6:3:1，难点在于网络设备日志和主机设备日志有价值的比例过低，占用资源太多。

A3：

日志接入属于SOC告警中心的业务范围。对于安全监测有益的日志都需要接入，基于业务场景形成单体异常告警。如HIDS、WAF、IDS、防火墙、各类网络设备变更记录、桌管日志、堡垒机日志、数据作业平台日志、内部账号登录日志、邮箱日志、AD日志、各类自研应用日志等等。

A4：

难点有解密流量、Nginx代理（导致源IP无法溯源）、规则覆盖不全、流量覆盖不全等。

A5：

网络跟安全设备的日志比较有用，也比较容易取得，主要接入SOC的也是这两类数据。

A6：

能接尽接，硬盘越来越便宜了不是。难点就是关联分析起来很困难，各家嘴上都很厉害，实际都很困难。

→ Q：日志审计做起来是不是比较麻烦？比如网络中的各种设备的日志都放在一起，进行综合性的查询，对于不同格式，以及兼容性、响应速率，有没有比较好的解决办法？

A1：

是很麻烦，所以寄希望于人工智能分析，但目前还很困难。

A2：

有二开能力可以做日志融合工作，这样可以按照自己想法去优化日志这块工作。

A3：

不太建议在日志格式统一做太多的工作，在日志种类较多的现在，此工作量巨大，占用资源较多，可以将日志格式定粗一点，更多利用规则将日志利用起来。

其实日志处理工作，很多安全设备已经帮你去处理了，更多可以关注在IP、攻击特征等的关联上，而不是去从底层去做分类、定义，这工作投入与产出完全不成正比，严格上说，没多大实际意义。

最后补充一点，要想利用好SOC，最好尽量少地址转换或者可以备注，无法有效地址溯源发现也没啥用，因为后续的溯源追踪会很难搞。

A4：

可建立安全数据标准，保障不同来源数据按照相同标准进行解析，不同来源告警按照告警类别做映射，从而保证不同数据源告警可以使用一套分析规则进行分析和统计。

A5：

异构日志处理的话，一个是内部从日志合规等角度推进日志规定的起早跟落地实践，拉研发一起给出标准化的参考案例，但这个部分只对自研的部分起作用，外购的系统还有老旧系统的日志就只有自己去把关键信息去解析出来，无法用的部分丢弃掉，然后重组存到集中日志平台中去。

A6：

日志审计，狭隘的可以说是SIEM查日志配置告警，这个其实就基本靠写正则解析获取自己的字段，过程很痛苦，结果还是很方便的。ELK我不清楚能不能跨Index，Splunk是可以的。

A7：

想要做好日志审计，技术、产品内力缺一不可。不同格式的问题在技术上来说简单地去切割日志转换成统一的格式即可。通过单体告警+可疑事件思路快速找到准确的入侵或违规事件。

单体告警：商用安全设备自有规则，根据渗透、合规经验自定义规则。

可疑事件：聚合多个告警产生准确事件。笼统地说可分为人员事件（违规、泄密）和入侵事件（同一主机入侵深度、不同主机入侵广度）。将准确事件抛给预置的SOAR剧本进行快速处置（前期手动，完全训练成熟后才能考虑逐步自动化）。

话题二：RSA加密的Public key，泄露了会有啥风险么，需要更换么？

A1：

Public key本身不就是公开的吗？结合业务具体场景分析下，Public key不是开放给指定个人的话就没啥问题。

A2：

简单看了下逻辑，大概是这样。实际内容是先用一个随机的AES加密，随机的AES秘钥和AES加密后的内容再通过RSA加密传给服务端。解密服务端返回的时候，应该是直接用随机生成的AES解密的。这样Public key泄露了，应该是有问题了？比如我可以直接伪造一个内容，用一个指定的AES秘钥加密，然后用泄露的Public key 再做RAS加密，服务端应该是会认为是一个正常的业务请求。服务端返回后的内容，就可以直接用指定的AES秘钥解密，可以这样理解么？

A3：

这有什么意义吗？你这个只是加密流程，不是业务场景，你要结合业务场景去看。

A4：

你的逻辑是对的，但是你忘了还有个第三方的CA。非对称加密里的CA有RSA的私钥匙的，可以防止伪造。所以非对称加密里公钥就是公开的，要保密的是私钥。这个场景里，负责数据加密的是AES，RSA做的是AES秘钥的分发而已。

A5：

对，RSA其实就是起到了传递AES秘钥的作用。理论上拿到RSA公钥，也无法解密出来AES加密的内容。

想了下，如果有人拿到了公钥，想构造出来一个服务端可以正常响应的请求，还得需要知道AES加密前的所有内容，这个有点苛刻了。好像不会有什么风险。

→ Q：话说这个AES加密有什么作用吗？

A1：

就是把内容加密一下。客户端AES加密后，还需要把AES秘钥发给服务端。所以客户端把AES秘钥又做了一次RSA加密。这个逻辑似乎比较常见。

A2：

因为我看着不是最后都要做一次RSA加密嘛，这个传输的时候AES密钥和内容是一起传输的，RSA密钥泄露后那不就相当于都泄露了吗？那RSA之前的加密似乎没什么用了啊。

A3：

RSA只做前面的AES密钥分发，后面传输数据都只用AES加密就好了的。

非对称加密适合做身份验证、秘钥分发（速度慢）；对称加密适合做数据加密（速度快）。

申请流程：扫码申请-后台审核（2-5个工作日）-邮件通知-加入会员俱乐部

如有疑问，也可扫码添加小助手微信哦！