事件驱动安全性的优点和缺点

各位，好消息！ Forrester Research 表示，2016 年记录的所有数据泄露事件中，有 95% 来自仅三个行业：政府、技术和零售业。 其他人都安全... 大概吧？

请稍等一下。 技术？ 零售？ 这是哪门子行业多元化？ 毕竟，我们生活在 2019 年，每个企业都是技术企业。 我们所有人都在不断销售某种东西，无论是创新产品还是优质服务。

因此，该报告应该说的是，在记录的所有数据泄露事件中，有 95% 来自对 95% 的线上和线下企业的攻击。 一些攻击者还针对了 .gov 网站。

关于此事，43% 的攻击者以小型企业为目标——考虑到平均每 39 秒就会发生一次黑客攻击，这个数字非常高。

更糟糕的是，预计到 2020 年，数据泄露的平均成本将超过 1.5 亿美元。 这些统计数据在脱离上下文的情况下听起来有点可怕，但威胁仍然非常真实。 哎哟。

那么，我们有哪些选择呢？

嗯，要么开发人员、利益相关者、决策者和企业所有者愿意通过不作为来冒其解决方案的完整性和安全性的风险，要么他们可以考虑加强其数字基础设施。

当然，这种两难境地似乎没有提供太多选择，这仅仅是因为它确实没有。 话虽如此，建立有效的网络安全说起来容易做起来难。

安全的成本

显然，安全是一项昂贵的努力，甚至是一种奢侈品。

• 网络安全成本仅在一年内（从 2016 年到 2017 年）就增加了 22.7%。
• 根据 Gartner 的数据，各组织在网络安全上的总支出为 816 亿美元，增加了 177 亿美元！
• 然而，最糟糕的是——无论我们投入多少资金，问题似乎都不会消失。

也许我们做错了什么？ 也许是我们看待网络安全的方式存在缺陷？ 也许，可能，存在更便宜且更好的解决方案？

可扩展性：不好吗？

在过去的十年中，软件、网络和架构开发发生了巨大的变化。 我们已经从古老的单体架构方法转向更精简、更动态的方法，这些方法允许对现代市场不断变化的需求做出更快的反应。

话虽如此，灵活性是有代价的。 单体架构是基础设施的坚固、稳定的元素，其中一个小的更改可能会像纸牌屋一样使整个系统崩溃。 但是，所述更改——无论其潜在危险如何——都易于追踪。

如今，架构主要基于服务，其中每个功能部分都像一个独立的乐高积木。 一个积木中的错误不会丢弃整个系统。 它甚至可能不会影响附近的积木。

这种方法在增加可扩展性的同时，也存在一个缺点——很难追踪单个恶意更改，尤其是在每个元素都受到来自人力资源或安全更新到恶意代码攻击等任何地方的新数据轰炸的环境中。

这是否意味着为了安全而牺牲可扩展性是最好的？

完全不是。 我们离开单体架构是有原因的。 现在回去可能会让你付出整个项目的代价。 棘手的部分在于有效地识别什么是威胁，什么不是威胁，因为这是微服务缺陷所在。

我们需要预防措施。

事件、警报和事故

您网络中发生的一切都可以用以下三个词之一来描述：事件、警报或事故。

事件是指网络、环境或工作流程中发生的任何可观察到的变化。 例如，当推送新的防火墙策略时，您可以认为事件已经发生。 当路由器更新时，另一个事件发生了，依此类推。

警报是指需要采取行动的事件。 简单来说，如果您或您的团队需要因为发生的事件而做某事，则将其视为警报。

根据 CERT NISTT 800-61 的定义，事故是指违反您的安全策略的事件。 或者，简单来说，它是对业务产生负面影响的事件，例如蠕虫病毒在网络中传播、钓鱼攻击或敏感数据丢失。

按照这个逻辑，您的基础设施开发人员、安全官和网络管理员的任务非常简单：建立有效的预防措施来防范任何和所有事故。

再说一次，说起来容易做起来难。

一次发生的不同事件实在太多了。 每个更改、转移或更新都彼此不同，导致数十起误报事件。 再加上恶意事件非常热衷于伪装自己，您就会明白为什么您的网络管理员看起来像至少在过去的几周里一直靠咖啡和红牛为生。

作为负责任的开发人员、经理、利益相关者、产品和企业所有者社区，我们有什么可以做的吗？

简而言之的事件驱动安全性

您忽略、采取行动或做出反应的所有事物中，有什么共同点？

事件。

您需要发生一些事情才能以任何形式对其做出响应。 此外，许多事件彼此相似，可以归类为流。

这是一个例子。

假设您有一个电子商务商店。 您的一个客户将商品添加到购物车（事件），然后将其删除（事件）或继续购买（事件）。

我需要说的是，除了简单地对这些事件进行分类之外，我们还可以分析这些事件以识别行为模式，这使得实时识别威胁变得更容易（甚至使人力资源/开发/营销团队能够获得更多数据）？

事件与命令

因此，事件驱动安全性本质上是基于跟踪事件。 我们曾经没有跟踪它们吗？ 我们没有为此提供命令吗？

是的，是的，我们有，这在某种程度上是问题所在。 这是一个事件与命令的示例

> 事件：我坐在沙发上，电视打开了。

> 命令：我坐在沙发上并打开电视。

看到区别了吗？ 在第二种情况下，我必须执行一个操作； 在第一种情况下，电视对事件做出反应（我坐在沙发上触发了电视打开），这是自动发生的。

第一种方法通过有效利用自动化来确保网络的完整性，本质上是允许软件自行运行并决定是在 Netflix 上启动下一季的黑镜还是隔离即将到来的威胁。

隔离

任何事件本质上都是一个触发器，用于启动架构中的下一个应用程序。 用户输入其登录名，系统验证其正确性，从数据库请求确认，并测试输入中是否存在代码。

到目前为止，一切都很好。 没有太大变化，对吧？

关键在于——每个进程和每个应用程序都像独立的事件一样自主运行，每个事件都触发自己的链。 应用程序都不知道是否已触发其他应用程序，以及它们是否正在运行任何进程。

将它们视为独立的、自主的集群。 如果其中一个集群受到攻击，它不会影响整个系统，因为它根本不知道是否存在其他任何东西。 也就是说，一个集群中的故障将触发警报，从而防止事故发生。

额外的好处

隔离的应用程序彼此不依赖，这意味着您可以根据需要插入任意数量的应用程序，而不会使任何应用程序冒风险或影响系统的其余部分。

如果您愿意，可以称其为开箱即用的可扩展性。

事件驱动方法的优点

我们已经讨论了事件驱动方法的大部分优点。 让我们在这里以简短的要点形式总结它们。

• 封装：每个进程都有一组清晰、易于执行的边界。
• 解耦：进程是独立的，并且彼此不知道。
• 可扩展性：可以轻松添加新功能、应用程序和流程。
• 数据生成：事件字符串生成您可以轻松分析的可预测的数据模式。

事件驱动方法的缺点

遗憾的是，尽管事件驱动架构和安全性为企业带来了令人印象深刻的诸多好处，但它们并非万能药。 该方法有其缺点。

首先，开发任何具有疯狂可扩展性的架构都非常困难、昂贵且耗时。

事件驱动安全性远非真正坚不可摧的墙。 黑客进化和适应速度相当快。 如果他们下定决心，他们很可能会在任何系统中找到漏洞，无论是通过编码还是通过网络钓鱼。

幸运的是，您不必建造一个诺克斯堡。 您所需要的只是一个足够坚固的系统，让黑客难以破解而放弃并转移到更容易的目标。 事件驱动的网络安全方法正是如此。

此外，如果事故真的发生，它可以最大限度地减少您的损失，所以这对您有利，这很好。