有两大领域需要关注：

1. 难以进入。
2. 制定政策和程序，冷静有效地处理某人过去的事件1。

难以进入

这是一个非常复杂的话题，很多都是围绕确保你有足够的信息来确定事后发生的WTF。 为简单起见，抽象的要点是：

• 保持日志（另请参阅安全信息事件pipe理）
  • 任何授权尝试，无论是成功还是失败，最好是完整的源信息。
  • 防火墙访问日志（这可能必须包括每个服务器的防火墙，如果使用的话）。
  • Web服务器访问日志
  • 数据库服务器authentication日志
  • 特定于应用的使用情况日志
  • 如果可能的话，SIEM可以对可疑模式发出警报。
• 强制适当的访问控制
  • 确保权利在任何地方正确设置，并尽可能避免“懒惰权利”（“哦，只是让每个人阅读”）。
  • 定期对ACL进行审核以确保程序实际得到遵守，并在故障排除完成后正确删除临时故障排除步骤（“让所有人阅读，看看是否能正常工作”）。
  • 所有的防火墙传递规则都需要合理化，并定期进行审计。
  • Web服务器访问控制也需要进行审核，包括Web服务器和文件系统ACL。
• 强制变更pipe理
  • 安全环境的任何变化都需要由多人进行集中跟踪和审查。
  • 补丁应该包含在这个过程中。
  • 拥有一个通用的操作系统版本（模板）将简化环境并使更改更容易跟踪和应用。
• 禁用访客帐户。
• 确保所有密码都没有设置为默认值。
  • 现成的应用程序可以使用预定义的密码来设置用户。 改变他们。
  • 很多IT设备都附带了众所周知的用户/密码对。 即使你一年只login一次，也要改变这些。
• 实践最小特权。 给用户他们实际需要的访问权限。
  • 对于pipe理员用户，双帐户设置是明智的。 一个普通账户用于电子邮件和其他办公任务，另一个用于高级私人工作。 虚拟机使这更容易生活。
  • 不要鼓励经常使用通用pipe理员/ root帐户，很难跟踪谁在做什么。

制定政策和程序，冷静有效地处理某人进入的事件

安全事件政策是所有组织必须遵守的。 它大大减less了“随我们头脑切断”的反应阶段，因为面对诸如此类的事件时人们往往会变得不合理。 侵入是大事，可怕的事情。 在遭受侵入时感到羞耻可能导致系统pipe理员以其他方式开始不正确的反应。

组织的各个层面都需要了解这些政策。 事件越大，高层pipe理人员就越有可能参与其中，并且设定处理事务的程序将大大有助于从高处抵御“帮助”。 它还为直接参与事件响应的技术人员提供一定程度的保障，以中层pipe理人员与组织其他部门接口的程序的forms提供。

理想情况下，您的灾难恢复策略已经定义了灾难恢复策略启动之前某些服务可能无法使用的时间。这将有助于事件响应，因为这类事件是灾难。 如果事件属于恢复窗口不能满足的types（例如：热备份灾难恢复站点获取已更改数据的实时馈送，并且入侵者删除了一系列复制到灾难恢复站点之前的数据因此需要采用冷补措施），上层pipe理者需要参与风险评估的谈判。

任何事故响应计划的一些组成部分：

• 识别受损系统和暴露的数据。
• 及早确定是否需要保留合法证据以进行最终检控。
  • 如果要保留证据，除非有绝对的要求，否则不要触摸该系统的任何内容 。 不要login到它。 不要筛选日志文件。 做。 不。 触摸。
  • 如果要保留证据，那么受损系统需要保持在线状态，但是直到获得authentication的计算机取证专家才能以符合证据处理规则的方式对系统进行剖析。
    • closures受损系统可能会污染数据。
    • 如果您的存储系统允许此（离散SAN设备）在断开连接之前快照受影响的LUN，并将其标记为只读。
  • 证据处理规则很复杂，很容易搞砸。 除非你接受过培训，否则不要这样做。 大多数一般的系统pipe理员都没有这种培训。
  • 如果证据被保留，将服务丢失视为硬件损失灾难，并使用新硬件启动恢复程序。
• 事先设定的规定什么样的灾害需要什么样的通知。 法律法规因地区而异。
  • 与“暴露”和“已证实妥协”有关的规则确实有所不同。
  • 通知规则将要求交stream部门参与。
  • 如果要求的通知足够大，最高pipe理层将不得不参与其中。
• 通过使用灾难恢复数据，确定在将服务恢复在线之前可以花费多less“WTF刚刚发生”的时间成为更高的优先级。
  • 服务恢复时间可能需要搞清楚发生了什么事情。 如果是这样，那么在恢复服务之后，采取受影响设备的驱动器图像进行解剖（这不是证据副本，而是技术人员的逆向工程）。
  • 规划你的服务恢复任务，包括一个完整的受影响系统的重build，而不仅仅是清理混乱。
  • 在某些情况下，服务恢复时间已经足够紧密，因此在确定发生妥协之后需要立即采取磁盘映像，并且不保留法律证据。 一旦服务重build，搞清楚发生了什么的工作可以开始。
• 通过日志文件筛选有关攻击者如何进入的信息，以及他们曾经做过的事情。
• 通过更改文件筛选有关他们如何进来的信息，以及他们进来后做了什么。
• 筛选防火墙日志以获取有关它们来自哪里，可能发送数据的位置以及可能发送了多less数据的信息。

妥协之前已经制定了政策和程序，并且在妥协的情况下将会执行这些政策和程序的人所熟知的，这只是需要做的事情。 在人们不会直截了当的时候，它给每个人提供了一个回应框架。 上层pipe理人员可以在法律诉讼和刑事指控上大肆吹捧，但实际上起诉是一个昂贵的过程，而且事先知道可以帮助阻止愤怒。

我也注意到，这些事件确实需要纳入整个灾难应对计划。 妥协很可能会触发“硬件丢失”响应政策，并可能引发“数据丢失”响应。 了解您的服务恢复时间有助于设置安全响应团队在服务恢复所需的时间之前能够倾注实际受损系统（如果不保留合法证据）多久的期望。

如何适当的帮助台程序可以帮助

我们需要考虑如何处理客户（这适用于联系帮助台的内部和外部客户）。

首先，沟通是重要的 ; 用户会对业务中断感到愤怒，也可能担心可能作为入侵一部分发生的任何信息泄露的程度和后果。 保持这些人的信息将有助于pipe理他们的愤怒和担忧，从共享知识是好的angular度来看，从稍微不太明显的angular度来看，他们需要听到的一件事是你在控制情况。

服务台和ITpipe理人员在这一点上需要扮演一个“保护伞”的angular色，掩盖人们的工作，以确定入侵的程度，并从无数的查询中恢复服务，从而破坏这项工作。

1. 尝试并向客户发布切合实际的更新，并与他们合作以确定将服务恢复到在线状态的紧迫性。 了解客户需求是重要的，但同时也不要让他们指定一个不可行的时间表给你。
2. 确保你的帮助台团队知道哪些信息可以发布，哪些不能发布，不应该鼓励谣言和猜测（绝对不应该讨论任何可能损害你的组织可能采取或面临的任何法律行动的任何事情）。
3. 帮助台应该做的一件好事是logging与入侵有关的所有调用 – 这可以帮助衡量入侵本身和处理它的过程所造成的破坏。 把时间和金钱成本都放在入侵和缓解方面，对于完善未来战略都是非常有帮助的，而且在任何法律行动中显然都是有用的。 ITIL事件与问题logging可以在这里帮助 – 入侵本身和缓解可以被logging为单独的问题，并且每个呼叫者被追踪为一个或两个问题的事件。

部署标准如何提供帮助

部署到一个设置的模板（或者至less一个清单）也可以帮助您实施更改控制/pipe理任何定制/升级到您的部署模板。 你可以有几个模板来说明做不同工作的服务器（例如邮件服务器模板，Web服务器模板等）。

模板应该适用于操作系统和应用程序，不仅包括安全性，还包括您使用的所有设置，理想情况下应该脚本化（例如模板），而不是手动应用（例如清单）以尽可能消除人为错误。

这有助于多种方式：

• 使您能够在发生入侵的情况下更快地恢复/重build（请注意，您不应该按照 “原样”部署此模板，因为您知道这是脆弱的，但可以让您回到“最后一次正确的configuration“ 在实际部署之前需要进一步强化 ……并且一旦确定其正确locking，不要忘记更新部署模板）
• 给你一个“基准”来比较被黑客入侵的服务器
• 减less可能导致入侵的不必要的错误
• 有助于更改和修补程序pipe理，因为当显然需要修补程序/升级或为安全性（或任何其他原因）需要进行修改时，可以更容易地查看哪些系统需要更改，使编写testing变得更容易查看更改是否正确应用等）。
• 如果所有事情都尽可能的一致和合理，那么这会让不寻常和可疑的事件进一步突显出来。

对于大多数我们的服务器，我们依靠主机和networking防火墙，反病毒/间谍软件软件，networkingIDS和主机IDS来实现我们大多数的预防。 这与所有的一般指导方针，如最低权限，卸载非必要程序，更新等。从那里我们使用的产品，如Nagios的，仙人掌和SIEM解决scheme的各种基线和事件发生时的通知。 我们的HIDS（OSSEC）也做了很多SIEMtypes的logging，这也很好。 我们基本上尽可能地做一些阻塞的事情，然后集中logging下来，如果有事情发生，我们可以分析和关联它。

你真正想要的可以分为三个基本领域：

1. 标准系统configuration
2. 系统/应用程序监视
3. 事件响应

如果你有任何信息（保证）人员，那么你一定要和他们交谈。 “事件响应”往往是上述办公室的唯一职权范围，其余部分应该是所有相关方面的联合开发工作。

冒着自我暴露的风险，这个相关问题的答案应该为你提供很多有用的资源： 保护LAMP服务器的技巧。

理想情况下，您应该拥有最less的受支持的操作系统，并使用基本映像构build每个操作系统。 您应该尽可能多地提供服务器提供的服务。 应该logging偏差，或者如果必须符合PCI / HIPAA /等要求，则可能需要偏差。 或其他遵从性。 使用部署和configurationpipe理系统可以在这方面帮助很多。 具体将取决于你的操作系统，鞋匠/木偶/ Altiris / DeployStudio / SCCM等等。

你一定要进行一些定期的日志审查。 考虑到SIEM的select可能会非常有帮助，但是它们在购买价格和build设成本方面也有昂贵的缺点。 请从IT Security SE网站查看关于日志分析的一些意见： 如何处理日志分析？ 如果这仍然过于沉重，甚至像LogWatch这样的常用工具都可以为正在发生的事情提供一些良好的背景。 不过，重要的一点，就是花时间看日志。 这将帮助你了解什么是正常的行为，以便你可以识别exception。

除了日志审查之外，监视服务器的状态也很重要。 了解何时发生变化，无论是否有计划，都是至关重要的。 使用Tripwire等本地监控工具可以提醒pipe理员进行更改。 不幸的是，SIEM和IDS很像调谐和/或购买昂贵的缺点。 而且，如果没有良好的调整，您的警戒阈值将会非常高，以至于任何好的信息都会在噪音中丢失，变得毫无用处。

适当的安全信息和事件pipe理 （SIEM）策略将会使您的安全生活变得更加容易。

我不是一个安全专家，所以我主要依靠他们。 但从最低特权委托人开始几乎总是使他们的工作更容易。 应用这个像愈合药膏一样适用于安全的许多方面：文件权限，运行时用户，防火墙规则等等.KISS从来不会伤害任何人。

这里提到的大多数解决scheme都适用于主机和networking级别，但我们经常会忘记不安全的Web应用程序。 Web应用程序是最常见的安全漏洞。 通过Web应用程序，攻击者可以访问您的数据库或主机。 没有防火墙，IDS，防火墙可以保护你免受这些。 OWASP维护一个十大关键漏洞列表，并为他们提供修复。

http://www.scribd.com/doc/19982/OWASP-Web-Security-Guide