安全性是 DevOps 的关键部分。 但是团队如何知道系统是否安全？ 是否确实可以提供完全安全的服务？
不幸的是，答案 不是。 DevSecOps 是一项持续且持续的努力，需要开发和 IT 运营中的每个人注意。 虽然工作从未真正完成，但团队用来预防和处理违规的做法可以帮助生成尽可能安全且具有复原能力的系统。
从根本上说，如果有人想进去，他们就一定会进去……接受这个事实吧。 我们告诉客户的是：第一，你已经参与到战斗中，无论你是否意识到或认为自己参与了。 第二，你几乎肯定被渗透了。“--迈克尔海登，前国家安全局局长和中情局局长迈克尔·海登
安全对话
鼓励没有正式 DevSecOps 策略的团队尽快开始规划。 起初，团队成员可能会产生抵触情绪，因为他们并不完全意识到现存的威胁。 其他人可能觉得团队没有能力面对这个问题，任何特殊的投资都会浪费注意力，分散开发和发布功能的精力。 但是，有必要开始对话，以就风险的性质、团队如何缓解风险以及团队是否需要他们当前没有的资源达成共识。
期待怀疑论者带来一些常见的论点，例如：
- 威胁有多真实？ 团队通常没有意识到他们负责保护的服务和数据的潜在价值。
- 我们的团队很好，对吧？ 有时，人们可能认为进行安全讨论是在质疑团队构建安全系统的能力。
- 我认为这是不可能的。 这是初级工程师的常见论点。 那些有经验的人通常更了解。
- 我们从来没有被破坏过。 但是你怎么知道？ 你怎么知道？
- 关于价值的无休止的辩论。 DevSecOps 是一项严重承诺，可能被视为对核心功能工作的干扰。 虽然安全投资应与其他需求保持平衡，但不能忽略它。
思维模式转变
DevSecOps 文化需要一个重要的思维模式转变。 你不仅需要 防止 违规，而且还 要假设 它们。
安全策略组件
在寻求更安全的系统时，有许多技术可以应用。
| 防止违规 | 假设出现违规 |
|---|---|
| 威胁模型 | 战争游戏练习 |
| 代码评审 | 中央安全监视器 |
| 安全测试 | 实时站点渗透测试 |
| 安全开发生命周期 （SDL） |
每个团队至少应该有一些防止违规的做法。 编写安全代码变得更加默认，并且有许多免费的商业工具来帮助静态分析和其他安全测试功能。
但是，许多团队缺乏假设系统违规是不可避免的策略。 假设你遭到入侵可能很难承认，尤其是在与管理层进行困难对话时，但该假设可以帮助你在自己时间回答有关安全性的问题。 你不想在真正的安全紧急情况下弄清楚这一切。
要思考的常见问题包括：
- 如何检测攻击？
- 如果有攻击或渗透，你会如何响应？
- 如何从攻击中恢复，例如数据泄露或篡改数据？
关键 DevSecOps 做法
几乎任何团队都有几种常见的 DevSecOps 做法。
首先，重点改进平均检测时间和平均恢复时间。 这些指标指示检测违规需要多长时间，以及分别恢复所需的时间。 可以通过持续对安全响应计划进行现场测试来跟踪它们。 评估潜在策略时，改进这些指标应该是一个重要的考虑因素。
深入练习防御。 发生漏洞时，攻击者可以访问内部网络及其内部的所有内容。 虽然在到达这一步之前阻止攻击者是理想的做法，但假设安全漏洞存在会促使团队尽量减少已经进入的攻击者造成的暴露。
最后，对做法和环境执行定期违规后评估。 解决违规问题后，你的团队应评估策略的性能，以及他们自己的遵守情况。 当团队实际遵循策略时，策略最有效。 无论实际还是实践，每个违规行为都应被视为改进的机会。
缓解威胁的策略
存在太多威胁，无法一一列举。 某些安全漏洞是由于操作系统和库等依赖项中存在的问题，因此保持它们更新至关重要。 其他原因是系统代码中的 bug 需要仔细分析才能查找和修复。 糟糕的秘密管理是许多违规的原因，社会工程也是原因。 最好是考虑不同类型的安全漏洞，以及它们对系统意味着什么。
攻击途径
假设攻击者获得了开发人员凭据的访问权限。 他们可以做什么？
| 权限 | 攻击 |
|---|---|
| 他们可以发送电子邮件吗？ | 网络钓鱼同事 |
| 他们是否可以访问其他计算机？ | 登录，使用mimikatz，再重复 |
| 他们是否可以修改源 | 注入代码 |
| 他们可以修改生成/发布过程吗？ | 注入代码，运行脚本 |
| 他们能否访问测试环境？ | 如果生产环境依赖于测试环境，则利用它 |
| 他们能否访问生产环境？ | 这么多选项... |
你的团队如何抵御这些向量？
- 将机密存储在受保护的保管库中
- 删除本地管理员帐户
- 限制 SAMR
- 凭据防护
- 删除双宿主服务器
- 单独订阅
- 多重身份验证
- 特权访问工作站
- 使用 ATP 和 Microsoft Defender for Cloud 进行检测
机密管理
所有机密都必须存储在受保护的保管库中。 机密包括：
- 密码、密钥和令牌
- 存储帐户密钥
- 证书
- 共享非生产环境中使用的凭据也
应使用保管库层次结构来消除机密重复。 另请考虑如何以及何时访问机密。 有些在生成环境配置时在部署时使用，而另一些是在运行时访问的。 部署时的机密通常需要进行新的部署以应用新的设置，而运行时的机密可以在需要时访问，并且可以随时更新。
平台具有用于管理 CI/CD 管道和云环境（例如 Azure Key Vault 和 GitHub Actions）中的机密的安全存储功能。
有用的工具
- Microsoft Defender for Cloud 非常适合通用基础结构警报，例如恶意软件、可疑进程等。
- 用于静态应用程序安全测试的源代码分析工具（SAST）。
- GitHub 高级安全性 ，用于分析和监视存储库。
-
mimikatz 从 Windows 上的本地安全机构子系统服务的内存
lsass.exe中提取密码、密钥、pin 代码、票证等。 它只需要对计算机或启用了调试权限的帐户进行管理访问。 - BloodHound 在 Active Directory 环境中生成关系图。 可以借助红队轻松识别那些难以快速发现的攻击途径。
战争游戏练习
Microsoft的一种常见做法是进行 战争游戏演习。 这些是安全测试事件，其中两个团队负责测试系统的安全性和策略。
红队扮演攻击者的角色。 他们试图对实际攻击进行建模，以发现安全方面的差距。 如果他们可以利用任何漏洞，它们也表明其违规的潜在影响。
蓝色团队承担 DevOps 团队的角色。 他们测试他们检测和响应红队攻击的能力。 这有助于增强态势意识，并衡量 DevSecOps 策略的就绪性和有效性。
发展战争游戏策略
战争游戏在强化安全上是有效的，因为它们激励红队寻找和利用问题。 它可能比早期预期的要容易得多。 尚未主动尝试攻击其系统的团队通常不知道攻击者可用的安全漏洞的大小和数量。 蓝队起初可能会感到沮丧，因为他们会屡次被打败。 幸运的是，系统和做法应该随着时间的推移而发展，使蓝队一直获胜。
准备军事演习
在开始战争游戏之前，团队应该处理他们可以通过安全通行证找到的任何问题。 在尝试攻击之前，这是一个很好的练习，因为它将为每个人提供基线体验，以便在以后发现第一次攻击之后进行比较。 首先，通过手动代码评审和静态分析工具识别漏洞。
组织团队
红队和蓝队应根据专业领域进行组织。 目标是为每个球队构建最有能力的团队，以便尽可能有效地执行。
红团队应包括一些安全意识的工程师和开发人员，他们非常熟悉代码。 如果可能的话，通过渗透测试专家来增强团队也很有帮助。 如果没有内部专家，许多公司会提供这项服务以及指导。
蓝色团队应该由对系统和日志记录有深入了解的运营工程师组成。 他们有检测和解决可疑行为的最佳机会。
运行早期战争游戏
期待红队在早期军事演习中表现出色。 他们应该能够通过相当简单的攻击（例如，通过查找保护不足的机密、SQL 注入和成功的网络钓鱼活动）取得成功。 在阶段之间留出充足时间来修正问题并整合对策略的反馈。 这将因组织而异，但你不想开始下一轮，直到每个人都相信上一轮已经挖掘了其全部价值。
正在进行的战争游戏
几轮后，红队需要依靠更复杂的技术，例如跨站点脚本（XSS）、反序列化攻击和工程系统漏洞。 在 Active Directory 等领域引入外部安全专家可能有助于攻击更模糊的攻击。 到这一次，蓝队不仅应该有一个强化的平台来防守，而且将利用全面的集中日志记录，进行违规后取证。
防御者以列表形式思考。 攻击者在图形中思考。 只要这是真的，攻击者就赢了。“约翰·兰伯特（MSTIC）
随着时间的推移，红队需要更长的时间才能达到目标。 这样做时，通常需要发现和链接多个漏洞，从而产生有限的影响。 通过使用实时监视工具，蓝色团队应开始实时捕获尝试。
准则
战争游戏不应该是一个免费。 必须认识到，目标是生成一个更有效的系统，由一个更有效的团队运行。
行为准则
下面是Microsoft使用的示例行为准则：
- 红蓝两队都不会造成任何伤害。 如果造成损害的可能性很大，则应记录并解决它。
- 红队不应在捕获目标资产时做出过多妥协。
- 常识规则适用于物理攻击。 尽管鼓励红队在非技术攻击上发挥创造性，例如社会工程攻击，但他们不应打印假徽章、骚扰他人等。
- 如果社会工程攻击成功，请不要透露被入侵者的姓名。 课程可以分享，而不让团队成员感到被孤立或尴尬，每个人都需要继续与之合作。
参与规则
下面是微软使用的参与规则示例：
- 不影响任何系统的可用性。
- 不要访问外部客户数据。
- 不要显著削弱任何服务的就地安全保护。
- 不要有意对任何资源进行破坏性行为。
- 保护获取的凭据、漏洞和其他关键信息。
可交付内容
任何安全风险或吸取的教训都应记录在待修复事项列表中。 Teams 应定义服务级别协议（SLA），以确定安全风险的解决速度。 应尽快解决严重风险，而次要问题可能具有两个冲刺期限。
应向整个组织提交一份报告，其中包含所学到的教训和漏洞。 这是每个人的学习机会，所以充分利用它。
Microsoft学到的教训
Microsoft经常练习战争游戏，并一路上学到了很多教训。
- 战争游戏是改变 DevSecOps 文化并保持安全首要目标的有效方法。
- 网络钓鱼攻击对攻击者非常有效，不应低估。 影响可以通过限制生产访问和要求双重身份验证来包含。
- 控制工程系统会导致控制一切。 请务必严格控制对生成/发布代理、队列、池和定义的访问。
- 实行纵深防御，以使攻击者更难以入侵。 他们必须突破的每一个边界都减缓了它们，并提供了另一个抓住他们的机会。
- 永远不要跨越信任领域。 生产绝不应信任测试中的任何内容。