DevSecOps最佳实践探索.PDF

DevSecOps最佳实践 探索 肖文棣 Mendick Xiao 安全架构师目录 DevSecOps 漫话 DevOps 和DevDevOps DevSecOps 和S-SDLC S-SDLC 向DevOps 演进的实践 DevSecOps 的未来DevSecOps漫话安全修复成本曲线 5 10 20 50 100 0 20 40 60 80 100 120 计划 设计 开发 测试 发布 $ USD 开发生命周期 安全修复成本 安全修复成本 指数 ( 安全修复成本)DevSecOps宣言 Leaning in over Always Saying “No” 向前一步胜过说不 Data & Security Science over Fear, Uncertainty and Doubt 数据和安全科学胜过害怕、不确定和质 疑 Open Contribution & Collaboration over Security-Only Requirements 开放性的贡献和合作胜过单纯的安全性 需 求 Consumable Security Services with APIs over Mandated Security Controls & Paperwork 可用的基于API 的安全服 务胜过强制性的安全控制和文档 Business Driven Security Scores over Rubber Stamp Security 业务驱动的安全分数胜过橡皮图章 的安全 审核 Red & Blue Team Exploit Testing over Relying on Scans & Theoretical Vulnerabilities 红蓝团队漏洞测试胜过依赖 扫描和理论上的漏洞 24x7 Proactive Security Monitoring over Reacting after being Informed of an Incident 24x7主动安全监控胜过安 全事件通告后的应急响应 Shared Threat Intelligence over Keeping Info to Ourselves 共享威胁情报胜过保持自己的信息 Compliance Operations over Clipboards & Checklists 合规运营胜过剪贴板和检查清单 http:/www.devsecops.org/DevSecOps的过程 代码开发 代码提交 构建脚本 测试 单元测试 系统测试 代码完成 预发布 发布 IAST-SAST 手工扫描 SAST Fuzz PenTest DAST DAST RASPGartner 的DevSecOps九条 建议 Adapt your security testing tools and processes to the developers, not the other way around 让你的安全测试工 具和流程适应开发人员，而不是相反 Quit trying to eliminate all vulnerability during development 不要尝试消除开发过程中的所有漏洞 Focus first on identifying and removing the known critical vulnerabilities 首先关注识别和删除已知的严重漏洞 Dont expect to use traditional DAST/SAST without changes 不要期望在没有变化的情况下使用传统 的 DAST/SAST Train all developers on the basic of secure coding, but dont expect then to become security experts 培训所有开 发人员基本的安全编码规范，但不要 期望他 们成为 安全专 家 Eliminate the use of known vulnerable components at the source 从源头上消除已知的易受攻击组件的 使用 Secure and apply operational discipline to automation scripts 将安全操作规程变为自动化脚本执行 Implement strong version control on all code and components 对所有的代码和组件进行严格的版本 管理 Adopt an immutable infrastructure mind-set 接受不可变的基础架构的思维模式DevOps和DevSecOps 开发 软件发布和更 新 安全 保密性 完整性 可用性 运维 可靠性 性能 伸缩性DevOps进化DevSecOps意义 团队或社区effor ，而不是个人' 自治和自动安全 - >规模安全 DevSecOps 是一种基于DevOps 原则的IT 安全方法 DevSecOps 跨越整个IT 堆栈 DevSecOps 还涵盖整个软件生命周期 信息安全架构师必须以协作的方式将多个安全点集成到DevOps 工作流中，这对 开发人员来说非常透明，并且保护团队的工作，灵活性和DevOps 和敏捷开发环 境的速度，这就是“DevSecOps”DevSecOps中的Sec 业务项目 内部 项目 运营变更 临时 工作 业务安全工作 构建安全控制（认证，鉴 权，攻 击阻断 ，加密 ）和合 规要求 内部安全工作 执行威胁建模，风险管理 ，资产 识别， 安全架 构，安 全研究 ， 漏洞评估，安全监控和分 析，安 全工具 和基础 架构安 全 运营安全工作 打补丁，操作系统更新， 漏洞修 复意见 ，产生 分析报 告，监 控 告警，工作问题单 其他安全工作 安全救火，紧急安全漏洞 处理， 恢复系 统和对 外工作 处理DevSecOps的挑战 DevOps 合规性是IT 领导者最关心的问题，但信息安 全被视为DevOps 敏捷性的抑制因素 安全基础设施在成为“软件定义”和可编程的能力 方面落后，因此难以以自动，透明的方式将安全控 制集成到DevOps 风格的工作流程中 现代应用程序主要是“组装”而非开发，开发人员 经常下载和使用已知的易受攻击的开源组件和框架。DevSecOps的挑战解 决建议 从安全开发和培训开始，但不要让开发人员成 为安全专家或交换工具 接受以人为本的安全概念，并让开发人员承担 个人责任，通过监控补偿安全性。 拥抱“信 任和验证”的心态。 要求所有信息安全平台通过API 公开全部功能 以实现自动化。DevSecOps的核心实践 分析 识别你最关键的安全挑战 安全 针对这个挑战实施防御策略 校验 对这个挑战实现自动化验证 防御 对这个挑战检测攻击和防御注入如何识别安全过程 在云上遗忘的控制 退出控制 基于云的基础设施安全 系统构建和控制 考虑数据类型和敏感程度 首先考虑威胁把Sec 集成到DevOps 中 微隔离 更改检测和自动回滚 日志和事件管理 账户和特权管理 漏洞扫描和评估 配置和补丁管理 构建管理 开发过程挑选安全工具的原则 政策范围 准确率 速度 弹性扩展 流程匹配度 集成评估参考表格 项目 分数 项目 分数 CI/CD 集成 支持多种格式的灵活报告 自动化结果收集并且集成到运 维工作 可以设置安全阀值终止流程 安全专家提供支持 漏洞类型覆盖的广度 通过检视结果降低误报率 目标语言覆盖的广度 提供容易理解的结果报告 减少识别漏洞和建议修复的时 间DevSecOps和S-SDLC SDLC S-SDLC 传统 开发 DevOps DevSecOps 敏捷 开发S-SDLC的具体实践 需求 架构 编码 测试 运维 渗透测试 安全测试 安全需求 威胁建模 代码检视S-SDLC向DevSecOps演进 某跨国金融企业，研发中心遍及北美，中国，印 度，欧洲，研发人员1000人左右，安全团队10- 20人，研发产品包括客户端系统，移动端系统， 网页端系统以及数据服务API 。开发语言涉及C+ ， Java ，.Net ，Python ，Scala。数据中心从自有向 混合云架构部署。安全流程也从S-SDLC 向 DevSecOps过渡。安全 v1.0 开始 设计与架构 安全需求 网站 应用 静态代码扫 描 静态代码扫 描 动态代码扫 描 分析 接受 或修 复 缺陷库 统计 误报/ 漏报 培训 不是 是 接受 不接受 架构评审 安全扫描 治理审计 第三方安全检查 修复建议 修复建议架构评审 版本 描述 周期 缺陷 状态 1.0 架构评审文档 Word 版本 一个大的 Release 很难分享 淘汰 1.1 架构评审文档 Wiki版本 一个大的 Release 比较容易分享 淘汰 1.2 专家系统 Json 邮件版本 一个Sprint 的 周期 邮件比较麻烦 正在工作中 1.3 专家系统在线 版本 一个Sprint 的 周期 需要安全专家 检视 计划上线 2.0 专家系统API 实时 正在计划中静态代码扫描 版本 描述 周期 缺陷 状态 1.0 Fortify 一个月一次扫 描 基于代码编译， 速度很慢，无 法自服务 淘汰 1.1 Checkmarx 一周一次或者 基于代码更新 扫描 开发人员不能 在本地扫描 正在使用 2.0 Checkmarx + 实时 计划中动态代码扫描 版本 描述 周期 缺陷 状态 1.0 Burp suite 一个Release之 后 缺陷率比较高， 与JIRA集成不 好，无法自服 务 淘汰 1.1 Whitehat 一个Sprint 没有API 正在运行 2.0 Whitehat + 实时 正在计划安全 v2.0 测试 更多 校验 配置 发布 监控 检测 保持 稳定 分析 预测 计划 编码 构建 渗透测试 合规检查 Fuzzing 常见异常用例 打破构建代码分析 静态代码分析 异常用例测试 代码检视 威胁建模 -> 安全Backlog 条目 分析/ 预测 -> 安全Backlog 条目 容量预测 条件分析预测 事故根因分 析 和 FMEA 分析 新的攻击面 计划更新威 胁 模 型 恢复/ 维护 非攻击使 用系统 RASP 自动响应 回滚或者关闭 阻断攻击者 关闭服务 入侵检测 App攻击检测 事故后分析的 日志信息 配置校验 降级限流安全 v2.0 进行中 阶段 状态 阶段 状态 计划 上个Sprint 的问题会放到Blacklog中，出现的安全 事故的 解 决方案会放到Blacklog中 监控 有完善的监控，有公司级的日志标准 ，日志 数据会 导入到 Splunk 平台 编码 使用Checkmarx 进行静态代码扫描 ，代码 采用Pull-Request 模式，强制检视 检测 有入侵检测系统，有WAF 防火墙 构建 无构建扫描，计划构建OSA 扫描 保持 RASP 正在计划中，通过WAF 阻断攻击 测试 部分团队有进行安全测试，有使用Whitehat进行 动态测 试 稳定 有24x7团队恢复系统， 根据ITIL 流程 建立起 三级响 应机制 更多校验 发布前使用GoASQ 系统（已开源）进行 专家检 视 分析 对事故有根因分析，有必要会更新GoASQ 的问 卷系统 配置发布 有服务器扫描工具，会扫描服务器以 及里面 相关软 件的配 置，降级限流正在计划中 预测 有进行容量预测并及时扩容Gartner 的九条建议实 施情况 建议 状态 建议 状态 适应开发人员 共赢态度，安全开发一体 ，现在 做得很 多 工作也是便利开发 从源头消除易受 攻击组件 正在推行OSA扫描，对员 工是信 任的态 度， 没有做太多限制，但是上 线前有 足够 的 扫 描 进行保证 不追求过分完美 漏洞修复 有优先 级，Critical一个月 内修复 ， High两个月内修复，非常合 理 安全操作规程自 动化 生成环境与开发环境分离 ，开发 人员 与 发 布 人员分离，发布过程已经 基本自 动化 和 脚 本 化 关注识别删除已知 漏洞 有团队跟踪已知漏洞，并 及时打 补丁， 对 于OWASP Top10 问题，在开发 阶段就 会避 免 对所有的代码和 组件进行严格版 本管理 代码是使用Git 进行管理 ，组件 管理放 权到 各个Scrum 团队，但 是有OSA 扫描 和其他 扫 描保证 DAST/SAST 的使用 我们公司开发文化是敏捷 文化， 拥抱变 化 接受不可变的基 础架构思维 基于Amazon 上推行Infrastructure-As-Code 的 思维，在自己的数据中心 没有推 行。 培训开发人员 新员工入职都会进行安全 基础培 训，另 外 有Whitehat的 网上课 程对开 发人员 进行培 训DevSecOps宣言检视 宣言 状态 宣言 状态 向前一步 公司是敏捷文化，拥抱变化 红蓝团队漏洞 测试 现在没有做红蓝对抗，还是依赖于扫描 以及专家系统检视 相信数据 公司建立了Dashboard 以及评级标准，对全员 公开，不害怕问题的暴露 24X7主动安全 监控 有24X7团队监控系统，并且建立了WAF ， IDP 等一系列系统 贡献合作 强调共赢，开发，测试，运维，安全都一起努 力做好产品 共享威胁情报 正在考虑建议威胁情报系统 基于API 的 安全服务 很多安全服务还没有完成API 化，不能做到完 全自助，还要努力 合规运营 公司遵循严格的ITIL 流程，并定期审计 业务驱动 的安全 安全是公司的生命线，行业有安全的核心需求， 公司最高层非常重视安全Gartner 关于DevSecOps的预 测 0 10 20 30 40 50 60 70 80 90 2016 2021 Gartner 2017年预测 自动化漏洞扫描和配置扫描 DevSecOps 线性 ( 自动化漏洞扫描和配置扫描) 线性 (DevSecOps)DevSecOps的未来晨星欢迎你附录 GoASQ https:/github.com/Morningstar/GoASQ 10 Things to Get Right for Successful DevSecOps https:/www.scribd.com/document/385486244/10- Things-to-Get-Right-for-Successful-DevSecOps