DevOps (DevSecOps) 中的安全性

安全性是 DevOps 的关键部分。 但是团队如何知道系统是否安全呢？ 真的有可能提供完全安全的服务吗？

非常遗憾，答案是否。 DevSecOps 是一项持续不断的工作，需要开发和 IT 运营中每个人的关注。 虽然这项工作没有真正完成的时候，但团队用于预防和处理违规行为的做法可以帮助生产出尽可能安全和有弹性的系统。

“从根本上说，如果有人想进来，他们就会进来……请接受这一点。 我们告诉客户的是：第一，无论您是否认为自己在战斗，您都在战斗。 第二，您几乎可以肯定被渗透了。“——前美国国家安全局和中央情报局局长迈克尔 · 海登

安全对话

鼓励没有正式 DevSecOps 策略的 Teams 尽快开始进行规划。 起初，没有充分理解现有威胁的团队成员可能会有抵制。 其他人可能不觉得团队有能力面对这个问题，任何特殊投资都是浪费，会分散在所交付功能方面的精力。 但是，需要开始对话，以便在风险的性质、团队如何缓解风险以及团队是否需要当前不具有的资源方面达成共识。

预计怀疑论者会提出一些常见论点，例如：

• 威胁有多么真实？ 团队通常不理解它们负责保护的服务和数据的潜在价值。
• 我们的团队很好，对吗？ 安全讨论可能会被视为对团队构建安全系统的能力的怀疑。
• 我不认为这是可能的。 这是初级工程师的常见论点。 有经验的人通常更加了解。
• 我们从未被侵犯过。 不过你怎么知道？ 你怎么知道？
• 关于价值的无休止的争论。 DevSecOps 是一个严肃承诺，可能被视为会分散在核心功能工作方面的精力。 虽然安全投资应与其他需求保持平衡，但不能忽略它。

思维模式转变

DevSecOps 文化需要思维模式的重要转变。 您不仅需要阻止泄露，还需要假设泄露。

安全策略组件

有许多技术可以应用于寻求更安全的系统。

预防安全漏洞	假设出现安全漏洞
威胁模型	战争游戏练习
代码评审	中央安全监视器
安全测试	实时站点渗透测试
安全开发生命周期 (SDL)

每个团队都应至少准备一些预防安全漏洞的做法。 编写安全代码已成为一种默认做法，并且许多免费和商业工具都可用于进行静态分析和用于其他安全测试功能。

然而，许多团队缺乏假设系统漏洞不可避免的策略。 假设您遭到漏洞攻击可能很难承认，尤其是在与管理层进行艰难对话时，但这种假设可以帮助您在自己的时间内回答有关安全性的问题。 您不想在真正的安全性紧急情况下再弄清楚这一切。

需要思考的常见问题包括：

• 您将如何检测攻击？
• 如果有攻击或渗透，你会如何响应？
• 如何从攻击（例如数据遭泄露或篡改）中恢复？

关键 DevSecOps 实践

有几种常见的 DevSecOps 实践几乎适用于任何团队。

首先，重点提高平均检测时间和平均恢复时间。 这些指标分别指示检测漏洞需要多长时间和恢复需要多长时间。 可以通过正在进行的安全响应计划现场测试来跟踪它们。 在评估潜在的政策时，改进这些指标应该是一个重要的考虑因素。

练习深度防守。 当受到漏洞攻击时，攻击者可以访问内部网络及其内部的一切。 虽然理想情况在攻击者到达之前阻止他们，但假设出现安全漏洞的政策促使团队尽量减少已经进入的攻击者的风险。

最后，定期对您的实践和环境进行入侵后评估。 在入侵问题得到解决后，您的团队应该评估政策的执行情况，以及他们自己对政策的遵守情况。 当团队真正遵循政策时，政策才最有效。 每一次入侵，无论是真实的还是练习的，都应该被视为改进的机会。

缓解威胁的策略

威胁太多了，无法一一列举。 某些安全漏洞是操作系统和库等依赖项出问题引起的，因此让这些依赖项保持最新状态至关重要。 其他安全漏洞是系统代码中的 Bug 引起的，需要仔细分析才能发现和修复这些 Bug。 机密管理不善是导致许多安全漏洞的原因，社会工程也是。 需要练习考虑不同类型的安全漏洞，以及它们对系统的影响。

攻击途径

考虑这样一种情况：攻击者获得了对开发人员凭据的访问权限。 他们能做什么？

Privilege	攻击
他们能发电子邮件吗？	钓鱼同事
他们能访问其他机器吗？	登录，mimikatz，重复
他们能修改源吗	注入代码
他们能修改构建/发布过程吗？	注入代码，运行脚本
他们可以访问测试环境吗？	如果生产环境依赖于测试环境，利用它
他们可以访问生产环境吗？	这么多选择...

您的团队如何防御这些攻击途径？

• 将机密存储在受保护的保管库中
• 删除本地管理员帐户
• 限制 SAMR
• Credential Guard
• 删除双主服务器
• 单独的订阅
• 多重身份验证
• 特权访问工作站
• 使用 ATP & Microsoft Defender for Cloud 进行检测

机密管理

所有机密都必须存储在受保护的保管库中。 机密包括：

• 密码、密钥和令牌
• 存储帐户密钥
• Certificates
• 共享非生产环境中也使用的凭据

您应该使用保管库的层次结构来消除机密的重复。 还要考虑如何以及何时访问机密。 其中一些在构建环境配置时在部署时使用，而另一些则在运行时访问。 部署时间机密通常需要新的部署才能获取新的设置，而运行时机密在需要时访问，并且可以随时更新。

平台具有用于管理 CI/CD 管道和云环境中的机密的安全存储功能，如 Azure Key Vault 和 GitHub Actions。

有用的工具

• Microsoft Defender for Cloud 非常适用于通用基础结构警报，如恶意软件、可疑进程等。
• 用于静态应用程序安全测试 (SAST) 的源代码分析工具。
• GitHub advanced security 用于分析和监视存储库。
• mimikatz 从 Windows 上的本地安全机构子系统服务 lsass.exe 的内存中提取密码、密钥、pin 代码、票证等。 它只需要对计算机的管理访问权限，或启用调试权限的帐户。
• BloodHound 构建了一个 Active Directory 环境中的关系图。 红队可以使用它轻松识别难以快速识别的攻击矢量。

战争游戏练习

Microsoft 的一种常见做法是进行战争游戏演习。 这些是安全测试活动，两个团队的任务是测试系统的安全性和策略。

红队扮演攻击者的角色。 他们试图对真实世界的攻击进行建模，以找出安全漏洞。 如果他们能够利用任何漏洞，他们也会证明其违规行为的潜在影响。

蓝色团队扮演 DevOps 团队的角色。 他们测试自己探测和应对红队进攻的能力。 这有助于增强态势感知，并衡量 DevSecOps 战略的准备程度和有效性。

发展战争游戏策略

战争游戏在加强安全方面是有效的，因为它们激励红队发现并利用问题。 这可能比早期预期的要容易得多。 没有积极尝试攻击自己系统的团队通常不知道攻击者可用的安全漏洞的大小和数量。 蓝队一开始可能士气低落，因为他们会被反复碾压。 幸运的是，系统和实践应该随着时间的推移而发展，这样蓝队才能始终获胜。

为战争游戏做准备

在开始战争比赛之前，团队应该处理好他们通过安全通行证发现的任何问题。 这是在尝试攻击之前进行的一项很好的练习，因为它将为每个人提供基线体验，以便在稍后发现第一个漏洞后进行比较。 首先通过手动代码审查和静态分析工具识别漏洞。

组织团队

红队和蓝队应该按专业组织。 我们的目标是为每一方建立最有能力的团队，以便尽可能有效地执行任务。

红队应该包括一些有安全意识的工程师和对代码非常熟悉的开发人员。 如果可能的话，配备一名渗透测试专家来增强团队也很有帮助。 如果内部没有专家，许多公司会在提供启导的同时提供这项服务。

蓝色团队应该由具有操作意识的工程师组成，他们对可用的系统和日志有着深刻的理解。 他们有最好的机会发现和解决可疑行为。

运行早期战争游戏

期待红队在早期的战争中发挥作用。 他们应该能够通过相当简单的攻击获得成功，例如通过发现保护不力的机密、SQL 注入和成功的网络钓鱼活动。 在两轮之间花大量时间应用修复程序并对政策进行反馈。 这会因组织而异，但直到每个人都相信上一轮的经验已经被充分理解吸收，再开始下一轮。

正在进行的战争游戏

几轮之后，红队将需要依赖更复杂的技术，如跨站点脚本 (XSS)、反序列化漏洞和工程系统漏洞。 在 Active Directory 等领域引入外部安全专家可能有助于攻击更隐蔽的漏洞。 到那时，蓝色团队不仅应该有一个坚固的防御平台，而且还将利用全面、集中的日志记录进行漏洞后取证。

“防御者用列表思考。 攻击者用图表思考。 只要这是真的，攻击者就会获胜。“——约翰 · 兰伯特（MSTIC）

随着时间的推移，红队将需要更长的时间才能达到目标。 当他们这样做时，通常需要发现和链接多个漏洞才能产生有限的影响。 通过使用实时监视工具，蓝色团队应该开始实时捕捉尝试。

准则

战争游戏不应该是自由交战。 重要的是要认识到，目标是建立一个由更有效的团队运行的更有效的系统。

行为准则

以下是 Microsoft 使用的行为准则示例：

1. 红队和蓝队都不会造成伤害。 如果造成损坏的可能性很大，则应记录并解决。
2. 红队的妥协不应超过捕获目标资产所需的妥协。
3. 常识规则适用于物理攻击。 虽然红队被鼓励在非技术性攻击方面发挥创造性，比如社会工程，但他们不应该打印假徽章，骚扰他人等。
4. 如果社会工程攻击成功，不要透露被攻击者的姓名。 可以在不疏远或尴尬每个人都需要继续合作的团队成员的情况下分享经验教训。

交战规则

以下是 Microsoft 使用的参与规则示例：

1. 不要影响任何系统的可用性。
2. 不要访问外部客户数据。
3. 不要显著削弱任何服务的现有安全性保护。
4. 不要故意对任何资源采取破坏性行动。
5. 保护获得的凭据、漏洞和其他关键信息。

可交付内容

任何安全性风险或经验教训都应记录在维修项目的积压中。 团队应定义一个服务级别协议 (SLA)，以确定解决安全风险的速度。 严重的风险应该尽快解决，而小问题可能有两个冲刺的最后期限。

应向整个组织提交一份报告，说明吸取的经验教训和发现的漏洞。 这对每个人来说都是一个学习的机会，所以要充分利用它。

Microsoft 的经验教训

Microsoft 经常练习战争游戏，并在这一过程中吸取了很多教训。

• 战争游戏是改变 DevSecOps 文化并将安全放在首位的有效方式。
• 网络钓鱼攻击对攻击者来说非常有效，不应被低估。 可以通过限制生产访问和要求双因素身份验证来控制这种影响。
• 对工程系统的控制导致对一切的控制。 请确保严格控制对生成/发布代理、队列、池和定义的访问。
• 深入练习防守，让进攻更加困难。 他们必须突破的每一个边界都会减慢他们的速度，并提供另一个抓住他们的机会。
• 永远不要跨越信任领域。 生产永远不应该相信测试中的任何东西。

后续步骤

了解有关安全性开发生命周期和 Azure 上的 DevSecOps 的更多信息。