维持和发展安全态势
安全状况不能随着时间的推移而降级。 必须不断改进安全运营,以便更有效地处理新的中断。 努力使改进与行业标准定义的阶段保持一致。 通过此做法,可以实现更好的准备、缩短事件检测的时间,以及实施有效的遏制和缓解措施。 持续改进应基于从以往事件中吸取的教训。
请务必衡量安全状况、强制实施维护该态势的策略,并定期验证安全缓解措施和补偿控制措施,以在面临不断演变的威胁时持续改善安全状况。
示例方案
Contoso Race Day Performance 为专业拉力赛车队创建了数据捕获系统。 大部分系统都嵌入在汽车中,并向车队提供本地反馈,但在比赛结束时,所有遥测数据会上传到云进行分析处理。 该处理可将赛道、环境条件和车辆遥测数据合并到报表中,车队可使用该报表评估其比赛并微调策略。 云系统将在 Azure Synapse Analytics 中使用 Azure Spark。 工作负载中的辅助系统全部使用 PaaS 产品/服务。 世界前五名车队中已有三支车队使用了该系统。
车队高度关注对其数据的保护,并希望知道 Contoso Race Day Performance 会如何与时俱进,以应对可能会攻击其数据的不断发展的安全威胁。
执行威胁建模以识别和缓解潜在威胁
分析工作流的每个组件,并评估每个组件可能受到的潜在威胁。 使用行业标准方法对已识别的威胁进行分类。
通过采用此方法,可以生成按其严重性级别确定优先级的攻击途径的报告。 此外,还可以快速识别威胁和漏洞,并设置相应对策。
Contoso 的挑战
- 虽然尚未发生安全事件,但工作负载团队没有标准化的方式来评估是否存在现有安全控制中未充分解决的任何威胁途径。
- 团队意识到,他们在工作负载的安全性方面存在一个盲点,如果发生安全事件,他们可能会措手不及。
应用方法和结果
- 该团队聘请了安全咨询专家来了解如何执行威胁建模。
- 执行初始威胁建模练习后,他们发现自己对大多数威胁途径具有设计良好的控制,但确实在 Azure Spark 作业完成后进行的一项数据清理任务中发现了漏洞,并发现了两个可导致数据外泄的内部威胁途径。
- 这些漏洞已计划在下一个开发周期中进行修正。
- 该团队还发现不再使用该服务的一支车队所使用的旧版系统对比赛遥测数据具有重要访问权限。 该修正的一部分是停用此系统。
独立验证控件
运行由工作负载团队外部的专家进行的定期安全测试,这些专家将试图对系统进行道德黑客攻击。 执行例程和集成的漏洞扫描,以检测基础结构、依赖项和应用程序代码中的漏洞。
借助这些测试,你能够通过使用渗透测试等技术模拟实际攻击来验证安全防御。
威胁可以作为更改管理的一部分引入。 通过将扫描程序集成到部署管道中,可以自动检测漏洞,甚至在移除漏洞之前隔离使用。
Contoso 的挑战
- 威胁建模练习帮助团队发现了安全漏洞,他们现在有兴趣验证其控制措施,尤其是在实施修正后。
- 该团队过去已经试验过开放源代码工具来测试其安全性,并发现这种练习既有趣又富有教育意义。 但他们和利益干系人希望引进安全专业人员来定期执行彻底和严格的测试。
应用方法和结果
- 该团队与一位从事云安全性研究的知名 Microsoft 合作伙伴合作,一起讨论渗透测试。
- 工作负载团队签署了季度渗透测试服务的工作声明,其中混合了每年进行的一次白盒测试,以确保更高的可信度。
- 咨询团队还帮助开发团队在开发箱和自承载生成代理上安装反恶意软件。
- 通过这些措施,工作负载团队和利益干系人对应对将来不断发展的威胁具备了高度的信心。
获取最新信息,保持最新状态
随时了解更新、修补和安全修补程序。 持续评估系统,并根据来自测试活动的审核报告、基准测试和经验教训对其进行改进。 根据需要考虑采用自动化。 使用由安全分析提供支持的威胁智能来动态检测威胁。 定期评审工作负载是否符合安全开发生命周期 (SDL) 最佳做法。
通过采用此方法,你将能够确保安全状况不会随时间推移而恶化。 通过集成来自实际攻击和测试活动的发现,你将能够对抗不断改进和利用新类别漏洞的攻击者。 自动执行重复任务可降低可能导致风险的人为错误的几率。
SDL 评审使安全功能更加清晰。 SDL 有助于维护工作负载资产及其安全报表的清单,其中包括源、使用情况、运营弱点和其他因素。
Contoso 的挑战
- 负责编写 Apache Spark 作业的开发人员对引入更改犹豫不决,并且通常对作业采用“没坏就别修”的方法。 这意味着他们引入解决方案的 Python 和 R 包可能会随着时间推移而过时。
应用方法和结果
- 在工作负载团队评审内部流程后,他们发现如果不解决维护 Spark 作业的过程,工作负载中就会存在未修补组件的风险。
- 团队为 Apache 作业采用新的标准,要求使用的所有技术必须连同其定期更新和修补计划一起更新。
- 通过解决安全控制方面的这种差距,整个工作负载不太可能面临存在未修补组件的风险。 他们对 PaaS 和 SaaS 服务的使用也有助于限制他们受到此风险的影响,因为他们不必修补底层基础结构。