问这是处理事件反应的好方法吗？

EN

假设这是您的完整流程，而不是已经做出其他决策的子集，我建议您的第一个决策点不是是否存在入侵，而是是否存在业务服务影响。

通知->检查日志->业务服务影响？

在确定了业务服务影响之后，您可以使用它来驱动事件响应的其余部分。如果您的服务受到影响，您需要在业务中雇用正确的人员(这些人员应该已经记录在案)，以便将影响通知他们，并对问题进行早期概述。

业务服务影响？->是->通知业务事件管理器

一旦通知了业务，您就可以继续确定问题的确切性质，并继续处理流程的其余部分。

如果没有业务服务影响，您仍将继续进行问题确定。

业务服务影响->没有->入侵？

我的下一个观点是，即使事件不是入侵，它也可能是您希望(或需要)作为结果执行操作的安全事件。

例如，您检测到web应用程序的某种形式的自动或手动扫描。您可能会决定要阻止攻击者的IP地址。这只是一个简单的例子。

这样的决定可能需要得到适当的业务或技术代表的授权，因此，与业务有关的必要挂钩必须反映在您的流程流程中。

总括而言，我的回应是：

1. 不要忘记您在维护业务应用程序，确保您的事件响应过程反映了业务的需求，而不仅仅是详细说明了所需的技术步骤。
2. 显然，入侵是最坏的情况，但不要忽略其他与安全相关的事件所需的操作。它可能不仅仅是错误的配置。

哈哈！！

OSSIM有OSSEC。除了文件完整性监控和syslog管理之外，OSSEC还可以用于诸如monitoring、Wordpress和MySQL UDF日志接口等方面。

我不明白当25和Q1Labs QRadar Log拥有更好的可自由下载的选项，以及许多其他开源项目也更好(尤其是在价格方面)时，对Splunk的需求或愿望。我同意Splunk太贵了。

这些原则很简单，也符合你所概述的方针。

1. 远程记录。不是延迟伐木，而是实时的。rsyslog工作得很好。作为一个完美主义者，我尝试直接从源捕获和发送日志，而不是先将日志记录到文件中，然后让rsyslog获取它们--只是为了避免在两者之间截获日志的可能性。
2. 包括文件完整性监视。OSSEC在这方面很好，但我使用自己的。
3. 现场分析。我使用MozDef ( Mozilla防御平台)。OSSIM过于专有和限制性(一段时间后，它感觉OSSIM的唯一目的是推广付费产品)。如果你是第一次，试试码头形象。对于生产使用，您需要了解组件是如何结合在一起的，并为自己创建一个自定义配置。如果你愿意的话，我很乐意帮忙。
4. 配置管理。是。
5. 自动重新部署。等等！作为一个DevOps函数，这是很棒的，但当涉及到IR时，您希望是超级保守的。任何自动化都需要涵盖许多场景。我们使用简单的We服务器来实现这一点，但不是其他任何东西。这是因为我们发现，在现实生活中，几乎每一个场景都与我们想象和准备的不同(我知道这也意味着我们没有充分的想象/准备)。
6. 远程取证和自动捕获。很高兴有，虽然自动化与否是值得商榷的。有太多的风险，除非你有一个非常严格的控制环境(我没有遇到太多)。我们更喜欢使用GRR /等效。对现场法医的需求很少(我们的经验)。要尝试并配置您所关心的每个端点(甚至只是服务器)，这可能有点过了，除非您正在管理高价值资产(Bank/ might /.)。所以我们有选择地这样做。