DevOps下的安全实施之路: 2020年研发运营安全白皮书

2021年9月17日 8点热度 0条评论 来源: 淼叔

来源声明:本文诸多信息来源于云计算开源产业联盟,相关版权归云计算产业联盟所有,本文内容仅在此基础之上对于DevOps下安全相关的内容进行个人解读与分析。

疫情之年

第八个年头,DORA开始全文讨论安全主题,DesSecOps也讨论安全,而在第九个年头,不知是新冠的影响还是DevOps已经不存在完整可以讨论一期的内容,DevOps的调研报告悄然停止。而国内云产业联盟在2020年7月也发布了研发运营安全白皮书,研发运营=DevOps,安全=Sec,这份研发运营安全白皮书大概就是国内云产业联盟2020年关于DevSecOps的总结和整理,让我们来一起解读一下这份包含了发展概况、建议架构以及实践总结等内容的研发运营安全白皮书。

层出不穷的安全事故

  • 2017年,美国最大的征信机构之一Equifax因未能及时修补已知的安全漏洞发生一起涉及1.48亿用户的数据安全、隐私泄露事件,影响几乎一半的美国人口;
  • 国内电商因优惠券漏洞被恶意牟利,酒店、求职等网站也曾发生数据安全事件,泄露百万级、亿级用户隐私数据。

分析解读:重视安全问题的同时安全问题层出不穷,对于安全的重视态度和似乎控制不住的安全风险表现大概率会长期持续。

什么因素导致的不安全

根据研究表明软件应用服务自身安全漏洞被黑客利用攻击是此类问题的最关键因素之一,以下是证明此项结论的数据:

  • 根据Verizon 2019年的研究报告《Data Breach Investigations Report》,在总计核实的2013次数据泄露安全事件中,超过30%与Web应用程序相关,Web应用程序威胁漏洞具体指程序中的代码安全漏洞以及权限设置机制等。
  • Forrester 2019年发布的 调 查 报 告 《Forrester Analytics Global Business Technographics Security Survey,2019》中显示,在283家全球企业已经确认的外部攻击中,针对软件漏洞以及Web应用程序是位于前两位的,分别占比达到了40%与37%,其中软件漏洞主要指对于安全漏洞的利用攻击,攻击Web应用程序主要指基于程序的SQL注入、跨站脚本攻击等。
  • 根据咨询公司Gartner统计数据显示,超过75%的安全攻击发生在代码应用层面。

分析解读:相较于其他因素,应用程序本身或者关联的代码安全漏洞和权限设置仍是当前安全问题的最主要因素之一。

安全漏洞哪家强

  • 美国国家标准技术研究院(NIST)的统计数据显示92%的漏洞属于应用层而非网络层。
  • 国家计算机网络应急技术处理协调中心2020年4月的发布的数据显示,2019年,国家信息安全漏洞共享平台(CNVD)收录的安全漏洞数量创下历史新高,数量同比增长14.0%,达到16193个,其中应用程序漏洞占比56.2%,Web应用程序占比23.3%,二者相加占比超过76%,充分说明安全漏洞大多存在于软件应用服务本身。

分析解读:安全漏洞哪家强,应用程序安全漏洞与Web应用程序安全漏洞。无论是NIST的数据还是CNVD的收录,应用程序的问题明显占较大比例。

安全左移:屡试不爽的万应灵药?

  • 根据美国国家标准与技术研究所(NIST)统计,在发布后执行代码修复,其修复成本相当于在设计阶段执行修复的30倍。

分析解读:安全左移已是刻不容缓。安全介入较晚,只能进行被动防御,缺乏安全左移的实践似乎这一切的灾难源泉。但是尽早发现安全问题进行修复确实能够有效节省成本这已经是共识,NIST或者其他机构都给出了不同的量化倍数(比如在我在<<企业级DevOps技术与工具实战>>一书中源引多年之前某大型跨国公司的一份报告,此数值是最高是达100倍的),虽然相差较大,但是结论基本一致,这也是安全左移的意义所在。

研发运营安全参考架构

云产业开源联盟在这份报告中,还给出了一份研发运营安全参考架构,具体构成如下所示:

分析解读:这这份架构中从软件生命周期的各个阶段都对安全涉及的方面进行了展开,具有一定的参考意义,尤其提到了明确隐私保护合规方案,确保数据留存符合最小化原则,满足国家相关规范要求等方面,随着软件应用面对的客户不同,此方面的问题将会越来越严重,尤其是当软件走出国门之时,如果对于不同地区的数据合规保护规则不够了解,形式大好的机会说不准会变成灭顶之灾。

研发运营安全的发展状况

  • 国际方面:根据Gartner 2020年6月发布的统计数据显示,全球2019年各项安全类支出总计1209.34亿美元,预计2020年将达到1238.18亿美元,其中应用安全市场规模2019年为30.95亿美元,预计2020年将达到32.87亿美元,年增长率达到6.2%,明显高于整体信息安全市场的2.4%年增长率。
  • 中国方面:我国应用安全市场增速高于全球,市场规模占全球比例达到近三分之一。2019年,我国应用安全市场规模达到8.48亿美元,市场规模占全球应用安全市场规模比例达到近三分之一,预计2020年市场规模将达到9.45亿美元,年增长率达到11.5%,高于全球6.2%的增长率。

分析解读:结合实际的咨询与业务落地实施经验来说,也确实明显感到进来企业在数字化转型的过程中国内的大型企业明显对于安全愈加重视,此方面的投入也越来越多。

安全发展的重中之重:AST

  • 应用程序安全测试(AST)市场增速最为迅猛,市场规模占比超过应用安全总体市场规模的三分之一。
  • 根据Gartner 2019年4月发布的报告调查数据显示,应用安全测试市场预计将以10%的复合年增长率增长,这仍是信息安全领域中快速增长的部分,到2019年底,AST的市场规模估计将达到11.5亿美元,市场规模占比超过应用安全总体市场规模的三分之一。
  • 根据Industry Research 2019年8月发布的数据显示,按照应用程序安全测试类型区分,静态应用程序安全测试(SAST)将占主导地位,预计将以24.06%的复合年增长率增长,交互式应用程序安全性测试(IAST)预计将以最快的27.58%的复合年增长率增长。

分析解读:多家调查美国以及市场反馈都表明,包含SAST和IAST的AST在安全投入中增长迅猛,也是近几年各大企业发力点和着力点。

来自国家层面的规范与指导

美国:发布战略计划,含括四个领域

  • 美国国家科技委员会(NSTC)网络和信息技术研发分委会在2019年12月发布《联邦网络安全研发战略计划》,主要内容涵盖四个相互关联的防御能力:威慑、保护、探测、响应。
  • 研发方面:在威慑能力中强调设计安全的软件,在保护能力中强调降低脆弱性产生的问题以及引入加密机制对数据进行保护以及访问控制手段以避免安全漏洞的产生。通过SQL项目通过工具的有效使用消除和降低漏洞问题。
  • 运营方面:探测与响应能力则是和运营能力相关,具体内容就是监控与告警,包括实时监测系统安全、及时检测或者预测安全威胁、动态评估安全风险,以及对于安全威胁进行联动、自适应处理等内容。

英国:发布指南,强化扫描与评估

  • 背景:英国使用其他国家的网络技术产品和服务较多,供应链复杂。
  • 源码扫描:引入源码扫描,用于检测安全漏洞和缺陷。
  • 研发方面:英国国家网络安全中心(NCSC)于2018年11月发布《安全开发和部署指南》,提及八项安全开发原则
    • 1)安全开发关系每一个人;
    • 2)保持安全知识实时更新;
    • 3)研发干净可维护的代码;
    • 4)保护开发环境;
    • 5)保护代码库;
    • 6)保护构建和部署管道;
    • 7)持续进行安全性测试;
    • 8)对于安全威胁、漏洞影响提前计划
  • 运营方面:《国家网络安全战略2016-2021》中明确提出要提升防御能力,提高政府和公共部门抵御网络攻击的弹性,定期评估关键系统的安全漏洞,业界应与国家网络安全中心(NCSC)共享网络威胁最新情报,进行主动防御等具体举措

欧盟:正式实施网络安全法案,保持领跑状态

  • 2019年6月27日,正式施行《网络安全法案》,进一步完善欧盟的网络安全保护框架。
  • 研发方面:要求参与产品设计开发的组织、制造商、提供商应在设计和开发的早期阶段采取安全措施,推测安全攻击的发生,减少安全风险的影响,同时安全应贯穿产品全生命周期,以减少规避安全风险
  • 运营方面:强调制定和更新联盟级别的网络和信息系统安全策略,对于安全事件联合处理,内部成员国共享安全信息、技术解决办法,提升事件处置的效率

分析解读:国家层面的规范与指导,可以看到主要聚焦在国家层面信息系统基础架构的研发与运营的安全,提出的一般是通用性的规范与指导,落地实施需要更加明确的细则才能保证落到实处。

非营利性组织的安全指导与规范

聚焦于流程与框架的ISO27034

  • ISO27034是国际标准化组织通过的第一个关注建立安全软件程序流程和框架的标准,提供了面向企业落地应用安全生命周期的指导框架,其本质目的是指导企业如何通过标准化的方式把安全融合进入软件生命周期。
  • ISO27034由七个部分组成,除了第四部分外已全部发布。

聚焦于应用安全的SAFECode

  • SAFECode成立于2007年10月,在过去10余年中,其发布的指南已被用于为许多重要行业和政府提供信息,以解决软件安全问题,内容主要包括安全设计原则、威胁建模、安全编码实践、测试和验证、脆弱性及安全事件响应等。

聚焦于应用安全风险的OWASP

  • OWASP(Open Web Application Security Project,即开放Web应用程序安全项目)关注软件安全,致力于改善软件的安全性,推动全球软件安全的革新与发展。OWASP是一个非盈利组织,于2004年4月21日在美国成立。OWASP提供有关计算机和互联网应用程序的公正、实际、有成本效益的信息,协助个人、企业和机构来发现和使用可信赖软件。其发布的OWASP Top 10代表了对Web应用程序最严重的10大安全风险,已经成为业界共识,是企业制定代码安全策略的重要参考文件,也是进行安全编码的有效一步。

分析解读:ISO27034聚焦于整理的流程与框架标准方面,而SAFECode则是应用安全,而OWASP这在应用方面更多发力,与大部分项目接触更紧密能够直接影响的反而是诸如OWASP Top 10这样的内容了。

企业层级的安全指导与规范

微软与SDL

  • 微软持续改进安全开发生命周期(SDL,即Security Development Lifecycle,以下简称SDL)流程措施,推行研发运营安全实践。自2004年以来,SDL作为微软一项强制性政策,在将安全性融入企业文化与软件开发实践中发挥了重大作用。目前主要内容包括
    • 1)管理制度,提供安全培训,增强安全意识,确保人员了解安全基础知识;
    • 2)安全要求,定义安全隐私要求与安全门限要求,包括法律和行业要求,内部标准和编码惯例,对先前事件的审查以及已知威胁等,安全门限要求指安全质量的最低可接受级别,明确定义安全漏洞的严重性阈值
    • 3)安全隐私需求分析与设计,具体措施包括执行威胁建模,建立设计要求,明确加密标准
    • 4)管理使用第三方组件的安全风险,拥有准确的第三方组件清单,并了解其安全漏洞可能对集成它们的系统的安全性产生影响;
    • 5)安全研发与验证,具体举措包括使用经过安全性检查,认可的工具,执行静态应用程序与动态应用程序安全性测试,进行渗透测试;
    • 6)发布部署阶段,建立标准的事件响应流程
    • 7)针对运营安全,通过人员权限认证,数据加密存储、传输,安全监控,定期更新安全策略,抵御常见网络攻击,执行渗透测试等手段保证上线运营阶段的安全。

分析解读:作为几乎是最早在此方面系统而全面进行实践的企业,微软的SDL具有极强的参考意义,尤其是对于传统的非快速迭代的项目,另外这份报告之中还给出了诸如VMWare和Cisco等公司的SDL方式的推行特点,对于很多企业应该具有通用性的参考作用。

Gartner与DevSecOps

  • Gartner公司于2012年推出了DevSecOps的概念,DevSecOps即Development Security Operations的缩写,是一套基于DevOps体系的全新安全实践战略框架,旨在将安全融入敏捷过程中,即通过设计一系列可集成的控制措施,增大监测、跟踪和分析的力度,优化安全实践,集成到开发和运营的各项工作中,并将安全能力赋给各个团队,同时保持“敏捷”和“协作”的初衷。
  • DevOps的目的决定了其对“自动化”和“持续性”的要求更加突出,因此在将安全控制集成其中时,也应该尽量遵循“自动化”和“透明”的原则。为了将安全无缝集成到DevOps中,Gartner和一些专家从实践出发提出了一系列建议,主要包括:风险和威胁建模、自定义代码扫描、开源软件扫描和追踪、考虑供应链安全问题、整合预防性安全控制到共享源代码库和共享服务中、版本控制和安全测试的自动化部署、系统配置漏洞扫描、工作负载和服务的持续监控等。

分析解读:相较于SDL流,DevSecOps在DevOps基础之上注定了其团队协作与敏捷的基因,DevOps文化也使得安全职责成为整个团队的共同责任而不是专门的安全团队,另外敏捷的需求也引入了工具提升整体的效率。

研发运营安全的7大关键要素

分析解读:此部分内容为此白皮书的精华所在,非常系统全面的整理了DevSecOps落地实施的多个方面,非常值得认真研读。

管理制度

  • 管理制度中需要明确:组织、人员、责任体系、管理制度、流程规范以及人员培训。
  • 管理制度与操作规范:确保落到实处如下内容非常关键,确保制度和操作规范中至少包含:
    • 1)账号和密码管理
    • 2)故障流程管理办法
    • 3)应急事件分级处理措施
    • 4)人员行为安全规范
    • 5)变更管理制度
    • 6)团队间安全协作流程和规范
  • 人员培训:人员培训针对所有研发、测试、运营人员以及第三方合作人员,目前是为了提升安全意识,增强研发运营安全能力。培训内容应包括
    • 1)安全管理制度
    • 2)安全意识培训
    • 3)安全开发流程
    • 4)安全编码规范
    • 5)安全设计
    • 6)安全测试
    • 7)安全上岗考核,对于培训结果进行考核,制定特殊岗位的上岗前考核机制,未通过相关考核的,不得从事相关岗位的工作。

分析解读:制度规范与人员培训,两者缺一不可,尤其是人员安全技能和意识的强化,才能真正地将安全落到实处。

安全要求与策略

  • 质量安全门限:设立质量安全门限,可定制具有项目级、团队级、组织级的质量安全门限,可根据业务场景、产品类型、语言类型划分。后续可智能化收集质量安全门限要求,以及根据业务场景等进行智能推荐
  • 用户权限控制:项目角色以及权限管理,依据最小权限原则,建立资源、行为操作权限管控,采用多因素认证机制保证访问安全,配置强密码策略,及时为不需要权限的用户或用户组移除权限
  • 操作审计:对于包括研发、测试、运营的所有相关人员的所有操作行为进行审计,对于审计记录进行保护,有效期内避免非授权的访问、篡改、覆盖及删除,对于审计记录形成报表,方便查询、统计与分析,针对审计日志进行自动化与人工审计,对于安全事件进行详细记录,对于高危操作进行重点审计,进行告警通知,针对行业特点,业务特点进行定制化的安全审计策略,对于审计记录进行统计分析、关联分析等
  • 环境管理:研发、测试、生产环境隔离,生产环境具有安全基线要求,保障环境的安全,针对研发、测试环境有明确的权限管控机制,针对各类环境的操作进行详细记录,具有可追溯性,定期执行生产环境的安全基线扫描,及时发现和处理安全风险,研发、生产环境具有良好的抗攻击与灾备容错能力,根据特定行业以及业务场景,对于测试环境接入安全扫描,针对不同的业务场景以及架构,对于发布环境进行分类管理,安全加固,生产环境具安全风险自动发现、分析和修复以及秒级容灾容错切换能力
  • 变更管理:有明确的进行变更条件与变更执行机制,有明确的变更授权机制,对于变更请求进行统一分析、整理,确定变更方案
  • 开源与三方组件管理:具有组织级的第三方组件库,明确优选、可用、禁用的第三方组件列表,统一组件来源,具有明确的第三方组件入库审批机制,第三方组件的引入应遵循最小化引入原则,减少安全风险,开源及第三方组件与自研代码独立存放、目录隔离,开源及第三方组件来源可追溯,开源组件追溯源社区,第三方组件信息追溯到供应商,对开源软件的生命周期进行管理,记录开源软件的生命周期信息,通过自动化工具及时向使用产品进行通知预警
  • 安全编码与测试规范:需要具有组织级、团队级、项目级的安全编码规范、安全测试规范。

分析解读:编码测试时阶段的规范,分层的质量安全门限,各层的环境管理,严格的开源管控,明确的变更管理,完整的权限控制和审计机制是安全要求和策略需要重点关注的内容。

安全左移后的分析设计阶段

  • 安全隐私需求分析:应包括安全合规需求以及安全功能需求,针对安全合规需求,应分析涉及的法律法规、行业监管等要求,制定合规和安全需求基线,针对安全功能需求应根据业务场景、技术,具备相应的测试用例,安全隐私需求来自法律法规、行业监管要求、公司安全策略、业界最佳实践以及客户安全需求,具有明确的安全需求管理流程,能够对安全需求的分析、评审、决策等环节进行有效管理,需求分解分配可追溯;
  • 整体安全设计原则与策略
  • 确定质量安全门限要求
  • 受攻击面分析:分析应从系统各个模块的重要程度、系统各个模块接口分析、攻击者视角分析攻击手段、方式、攻击路径、权限设置是否合理、攻击难度等维度进行分析;
  • 威胁建模:具体行为包括确定安全目标、分解应用程序、确定威胁列表;
  • 共享型的安全知识库:设计形成具有组织级安全需求知识分享平台,形成知识的复用,根据安全需求,得出安全设计解决方案

分析解读:安全的设计重点在于威胁建模,在于对于安全隐私需求和风险的分析,反响确认攻击目标和纬度以及手段,从而更好地进行分析和设计。

研发与测试

  • 安全编码:维护获得安全认可的工具、框架列表,使用获得认可的工具、框架,具有统一的版本控制系统,将全部源代码纳入版本控制系统管理,版本控制系统具有明确的权限管控机制,代码仓库具有实时代码安全扫描机制,发现安全问题并提示修复,根据安全编码规范制定自定义安全策略,进行自动化安全扫描,采用集成于IDE或其他形式提供的自动化测试工具定时进行代码安全检测,针对版本控制系统有监控机制,包括人员、时间、行为操作等,方便审计回溯,制定代码合入门禁机制,确保代码合入质量,代码仓库支持线上代码动态扫描,发现安全问题并提示修复
  • 开源及第三方组件安全风险管理:对于第三方组件根据风险级别,有明确的优选、可用、禁用机制,代码提交前采用扫描工具进行第三方组件安全检查,管理项目中的第三方组件许可证以及安全漏洞等风险,针对第三方组件安全风险,推荐安全解决方案
  • 变更管理:对于变更操作进行统一管理,明确记录变更信息,包括但不限于变更人员、变更时间、变更内容,针对重点变更内容进行评审,变更操作具有明确的审批授权机制,重大变更操作具有分级评审机制,具有统一的变更管理系统,变更操作覆盖需求设计到发布部署全流程
  • 代码安全审查:制定明确的源代码安全检视方法,开展源代码安全审计活动,采用工具与人工核验相结合的方式进行代码安全审计,对于威胁代码及时通知研发人员进行修复,对高风险源代码有分级审核机制,对于审计发现的威胁代码自动通知研发人员,进行修复,根据行业特点、业务场景定制化开发代码安全审查工具,制定安全审查策略。
  • 开源及第三方组件安全风险评估:采用工具与人工评估的方式确认第三方组件的安全性、一致性,根据许可证信息、安全漏洞等综合考虑法律、安全风险。
  • 配置审计:具有明确的配置审计机制,配置审计包括但不限于配置项是否完备、配置项与前期安全需求的一致性、配置项版本的描述精确,与相关版本一致制,配置项的每次变更有记录,可以追溯到具体修改时间和修改人,产品依赖的自研模块、平台组件、开源源码、开源二进制、第三方软件被准确的定义和记录,对于明确统一的合规需求以及安全需求,进行自动化配置审计
  • 安全隐私测试:具有明确的安全隐私测试要求,作为发布部署的前置条件,测试数据不包含未经清洗的敏感数据,基于安全隐私需求,有相应的安全隐私测试用例,并进行验证测试,单个测试用例的执行不受其他测试用例结果的影响,测试数据、用例应统一管理,有明确的权限管控机制,测试用例、测试数据应定期更新,满足不同阶段、环境的测试要求,具备自动化安全测试能力,对于测试结果有集中汇总与展示的能力,持续优化安全测试策略,持续降低误报率与漏报率,测试过程有记录可查询,测试设计、执行端到端可追溯,基于不同业务场景以及系统架构,进行安全测试智能化推荐与测试策略智能优化
  • 漏洞扫描:采用主流的安全工具进行漏洞扫描,漏洞扫描结果有统一管理与展示平台,漏洞扫描的结果及时反馈研发人员,进行漏洞修复,具有自身以及第三方漏洞库,对于漏洞库定期更新,基于漏洞信息进行关联与聚合分析
  • 模糊测试:采用主流的模糊测试工具,自动化进行模糊测试,模糊测试的结果及时反馈研发人员,进行修复,持续改进模糊测试策略
  • 渗透测试:引入人工渗透测试机制,针对系统架构、应用程序、网络层面漏洞进行渗透测试,根据行业特点与业务场景实施渗透测试,范围应覆盖重要安全风险点与重要业务系统,有明确的渗透测试计划与管理机制

分析解读:此部分内容很多已经是企业落到实处的地方,但是整理来说智能化相关的部分前路尚远,虽然整体是方向,大概需要投入的成本和效率效果的平衡合适能够达到一个真正可使用的临界点时此部分内容才会真正落地。

发布部署

  • 发布管理:有相应的发布安全流程与规范,发布操作具有明确的权限管控机制,发布应具有明确的安全检查节点,根据安全节点检查结果,有相关告警机制,针对发布流程具有安全回退、备份机制,制定发布策略,通过低风险的发布策略进行发布,如灰度发布或者蓝绿发布等方式,发布流程实现自动化,一键发布,根据安全节点检查结果,发现高危安全问题,自动阻断发布流程,对于发布流程具有监控机制,出现问题自动化回滚,建立稽核机制,发布前需要通过稽核部门的独立检查;
  • 安全性检查:进行病毒扫描以及数字签名验证等完整性校验,校验结果作为发布的前置条件;
  • 事件响应计划:具有预先的事件响应计划,包括但不限于安全事件应急响应流程,安全负责人与联系方式。

分析解读:发布管理时的事件是发布部署中的关键因素,很多项目只注意灰度发布,缺少此部分内容,相应计划如果能够真正落地会有较好效果,另外关键核心业务发布部署中如果添加对于实施之前的在准生产的问题验证可能会效果更好。

上线运营

  • 安全监控:具有运营阶段安全监控机制,覆盖全部业务场景,抵御常见威胁攻击的能力,如DDoS攻击,暴力破解,病毒攻击,注入攻击,网页篡改,具有统一的安全监控平台,对于威胁攻击处理能够统一监控并可视化展示,对于监控安全事件进行分级展示,具有智能化安全监控平台,对于监控事件统一关联分析,智能识别潜在的安全风险,实现智能化用户行为分析以及资产数据的安全画像;
  • 安全运营:定期进行常规安全检查与改进,运营人员有明确的权限管控机制与管理规范,监控运营数据加密存储,存储与备份机制符合安全要求,保证全生命周期安全,对于安全事件有多种方式的告警机制,通过统一平台对于安全事件处置全流程进行跟踪,具备从外部接收相关漏洞通告和安全情报的能力,对于自动化运维工具进行安全加固并具备自动化监控机制,及时发现工具的操作安全风险,对于运营过程中的安全日志等数据进行自动化分析,发现安全风险并告警,可建设统一的安全运营中心,分布于不同位置的云平台接入统一运营中心,将管理数据统一进行处理,对于监控数据进行统计、展示,具备持续的安全漏洞、安全信息外部反馈机制,对于运营过程中的安全日志等数据进行智能化关联分析,发现潜在安全风险并告警,根据漏洞信息、业务场景等智能化推荐安全解决方案,进行智能化处置;
  • 风险评估:制定和实施安全风险评估计划,定期进行安全测试与评估,安全风险评估、测试范围应覆盖重要业务系统、应用,建立渗透测试流程,根据渗透测试流程,针对系统架构、应用程序、网络层面漏洞进行安全测试,制定漏洞奖励计划,鼓励第三方渗透测试,安全风险评估、测试范围应覆盖全业务系统,建立智能化的风险评估体系,对于生产环境中的安全风险进行分析、告警;
  • 应急响应:具有明确的应急事件响应流程,基于应急事件进行分级、分类处理,具备专门的应急响应安全团队,有统一的技术平台,对于应急事件进行全流程跟踪与可视化展示,对于应急事件及时复盘,形成相关处理知识库,对于应急事件处理具有具体的量化指标,包括但不限于威胁处理时间、响应时间,定期开展应急事件演练,对于应急响应事件可以实现一定程度上的自动化处理,对于应急事件具有全面的自动化以及一定程度智能化处理能力;
  • 升级与变更管理:有明确的升级与变更操作制度流程,升级变更操作有明确的权限管控机制,升级变更操作有明确的审批授权机制,对于升级变更操作有明确的操作信息记录,包括但不限于变更升级内容、变更升级时间,变更升级操作对于用户无感知,对于用户有影响的,需要提前告知沟通,有相应的回滚机制,变更升级操作与版本系统同步,确保版本信息一致,对于重大变更升级有分级评审机制,实现自动化变更升级与回滚,变更升级操作有相应监控机制,出现问题自动化回滚;
  • 服务与技术支持:有明确的服务与技术支持方式,通过电话等方式对于用户反馈问题进行反馈、回访,对于监管部门、运营商提出的安全问题及时响应,对于用户反馈问题有分级处理机制,及时对于处理结果进行反馈,说明处理结果、影响程度等,对于反馈问题分类处理、记录、归档,方便知识的反馈、复用,针对安全类问题具有专属反馈通道,确保安全问题的及时响应;
  • 运营反馈:定期收集运营过程中的安全问题,进行反馈,对于反馈安全问题分类、分级处理,完善前期安全需求设计、安全研发等流程,具有明确的反馈改善管理流程与度量机制,有统一的运营安全问题反馈平台,统一收集反馈的安全问题,分类、分级处理,反馈全流程跟踪,对于收集的安全问题自动化实现汇总分析,优化从需求设计到研发运营整个流程,对于反馈安全问题实现智能化关联分析,发现潜在安全问题,优化研发运营全流程

分析解读:运营的阶段实际更多是以监控和告警作为问题的被动响应,结合升级与变更管控,对于风险进行评估,对于响应进行分级,在相关硬件和软件基础建设完毕的情况之下定期进行攻防演练,是整个运营阶段需要坚持不懈关注的内容。

停用下线

  • 服务停用下线是研发运营安全体系的最后一环,指系统在终止服务之后,应制定制定服务下线方案与计划,保护用户的隐私安全与数据安全,具体要求为明确隐私保护合规方案,确保数据留存符合最小化原则,满足国家相关规范要求

分析解读:这确实是一个容易被忽视的阶段,数据存留的最小化结合隐私合规要求是需要关注的内容。

安全相关的6大常用工具

各阶段常用工具

  • 常用工具:

    • 静态应用程序安全测试(Static Application Security Testing ,简称SAST)
    • 动态应用程序安全测试(Dynamic Application Security Testing,简称DAST)
    • 交互式应用程序安全测试(Interactive Application Security Testing,简称IAST)
    • 软件组成分析(Software Composition Analysis,简称SCA)
    • 实 时 应 用 自 我 保 护 (Runtime Application Self-protection,简称RASP)
    • Web应用防火墙(Web Application Firewall,简称WAF)
  • 各阶段常用工具

SAST

静态应用程序安全测试(SAST)是指不运行被测程序本身,仅通过分析或者检查源程序的语法、结构、过程、接口等来检查程序的正确性。源代码静态分析技术的发展与编译技术和计算机硬件设备的进步息息相关,源代码安全分析技术多是在编译技术或程序验证技术的基础上提出的,利用此类技术能够自动地发现代码中的安全缺陷和违背安全规则的情况。目前主流的分析技术包括:

  • 词法分析技术:只对代码的文本或Token流与已知归纳好的缺陷模式进行相似匹配,不深入分析代码的语义和代码上下文。词法分析检测效率较高,但是只能找到简单的缺陷,并且误报率较高。
  • 抽象解释技术:用于证明某段代码没有错误,但不保证报告错误的真实性。该技术的基本原理是将程序变量的值映射到更加简单的抽象域上并模拟程序的执行情况。因此,该技术的精度和性能取决于抽象域对真实程序值域的近似情况。
  • 程序模拟技术:模拟程序执行得到所有执行状态,分析结果较为精确,主要用于查找逻辑复杂和触发条件苛刻的缺陷,但性能提高难度大。主要包括模型检查和符号执行两种技术,模型检查将软件构造为状态机或者有向图等抽象模型,并使用模态/时序逻辑公式等形式化的表达式来描述安全属性,对模型遍历验证这些属性是否满足;符号执行使用符号值表示程序变量值,并模拟程序的执行来查找满足漏洞检测规则的情况。
  • 定理证明技术:将程序错误的前提和程序本身描述成一组逻辑表达式,然后基于可满足性理论并利用约束求解器求得可能导致程序错误的执行路径。该方法较为灵活性,能
    够使用逻辑公式方便地描述软件缺陷,并可根据分析性能和精度的不同要求调整约束条件,对于大型工业级软件的分析较为有效。
  • 数据流分析技术,数据流分析技术基于控制流图,按照某种方式扫面控制流图的每一条指令,试图理解指令行为,以此判断程序中存在的威胁漏洞。数据流分析的通用方法是在控制流图上定义一组方程并迭代求解,一般分为正向传播和逆向传播,正向传播就是沿着控制流路径,状态向前传递,前驱块的值传到后继块;逆向传播就是逆着控制流路径,后继块的值反向传给前驱块。

静态应用程序安全测试(SAST)使用功能主要包括:

  • 代码提交与集成:在用户 IDE 环境中集成代码静态检测插件进行代码检查,对发现的问题能够直接显示在 IDE 上。将代码提交到远程仓库时,触发代码检查,系统会先去拉取代码,再执行代码扫描,扫描时支持全量与增量代码扫描方式。构建时,支持每日定时设置,每天执行代码检查,同时也支持根据需要手动触发检查。
  • 风险展示与处理:扫描结束后,会在代码扫描系统及代码仓库上展示整体风险趋势变化,包括新增、修复、遗留告警、项目代码质量状态展示等,同时支持各个告警详情查看,包括风险等级、错误代码片段、问题描述、修复指导等。支持用户对告警进行标记,包括确认、误报、设计如此等多种场景。
  • 定制化支持:支持用户自定义规则扫描,也支持单个告警/批量告警/路径屏蔽等功能,便于提高与业务场景的契合度

主要厂商:Synopsys、Micro Focus、Checkmarx、Veracode、奇安信、棱镜七彩等

SCA

  • 软件组成分析(SCA):主要针对开源组件,通过扫描识别开源组件,获取组件安全漏洞信息、许可证等信息,避免安全与法律法规风险。开源软件相比于闭源软件,带来了如获取便捷、降低成本等诸多好处,但相比于闭源软件,由于开源软件的所有权和使用权分离,如果使用不当,会导致最终的使用用户被迫承受风险。因此在使用中用户仍然需要注意遵循相关规则,例如遵循开源许可证的相关要求和监管条例、甚至需要公开自有的商业代码等,对引入和使用过程中潜在的安全风险进行有效监管。
  • 开源软件主要涉及的安全风险:不清楚具体引用或使用了哪些开源组件、对开源许可证引入的知识产权和合规风险、开源软件自身的安全风险
  • 现有的开源扫描技术主要有:
    • 1)通过进行源代码片段式比对来识别组件并识别许可证类型;
    • 2)对文件级别提取哈希值,进行文件级哈希值比对,若全部文件哈希值全部匹配成功则开源组件被识别;
    • 3)通过扫描包配置文件读取信息,进行组件识别从而识别组件并识别许可证类型
    • 4)对开源项目的文件目录和结构进行解析,分析开源组件路径和开源组件依赖
    • 5)通过编译开源项目并对编译后的开源项目进行依赖分析,这种方式可以识别用在开源项目中的开源组件信息。
    • 上述 5 种识别技术的识别速度是依次增快的,并且组件物料清单的完整性也是依次增高的。源代码片段识别出的开源组件的数量较多,但因为源代码片段比对受行数和关键词位置影响,识别出的开源组件的误报率通常较高,且识别出的开源组件需要手动确认,对操作人员的技术能力要求较高;其他 3 类识别出的开源组件数量通常少于源代码片段识别,但因为哈希值的不变性,其识别出的开源组件的误报率较低,同时相比于开源代码片段识别,由于源代码被改写生成哈希值也会随之改变,因此漏报率通常比源代码片段识别高。
  • 主流的安全漏洞检测原理如下:
    • 第一种方法是依据获取到的开源组件名称和版本号信息,在公开的 CVE 或 CNVD 库里去查寻该版本曾经出现过的漏洞;
    • 第二种方法是通过程序分析技术,获取到开源组件名称、版本信息和引用的函数,依据企业的商业漏洞库去匹配所引用的函数是否会造成漏洞。
    • 方法二的准确性远远高于方法一,但是实现难度也非常大。针对开源组件自身安全风险,与传统的软件漏洞修复流程不同的是并不对开源软件做漏洞修补工作,开源软件漏洞治理通常会依靠扫描技术发现存有安全漏洞的开源软件版本号,与当前最新版本号做匹配,进行替换。因此开源软件的版本号管理、漏洞更新及跟踪工作也十分重要。
  • 主要厂商包括Synopsys、Micro Focus、WhiteHat Security、奇安信、棱镜七彩 等,

IAST

  • 交互式应用程序安全测试(IAST):是2012年Gartner公司提出的一种新的应用程序安全测试方案,通过代理和在服务端部署的Agent程序,收集、监控Web应用程序运行时请求数据、函数执行,并与扫描器端进行实时交互,高效、准确的识别安全漏洞,同时可准确确定漏洞所在的代码文件、行数、函数及参数。

  • 运行原理与方式:主要工作内容包括流量采集、Agent监控、交互扫描。

    • 1)流量采集:指采集应用程序测试过程中的HTTP/HTTPS请求流量,采集可以通过代理层或者服务端Agent。采集到的流量是测试人员提交的带有授权信息有效数据,能够最大程度避免传统扫描中因为测试目标权限问题、多步骤问题导致扫描无效;同时,流量采集可以省去爬虫功能,避免测试目标爬虫无法爬取到导致的扫描漏水问题。
    • 2)Agent 监控:指部署在 Web 服务端的 Agent 程序,一般是 Web 服务编程语言的扩展程序,Agent 通过扩展程序监控Web 应用程序性运行时的函数执行,包括 SQL 查询函数、命令执行函数、代码执行函数、反序列化函数、文件操作函数、网络操作函数,以及 XML 解析函数等有可能触发漏洞利用的敏感函数。
    • 3)交互扫描:指 Web 应用漏洞扫描器通过 Agent 监控辅助,只需要重放少量采集到的请求流量,且重放时附带扫描器标记,即可完成对 Web 应用程序漏洞的检测。例如在检测 SQL 注入漏洞时,单个参数检测,知名开源 SQL注入检测程序 SQLMAP 需要发送上千个 HTTP 请求数据包;交互扫描只需要重放一个请求,附带上扫描器标记,Agent 监控 SQL 查询函数中的扫描器标记,即可判断是否存在漏洞,大大减少了扫描发包量。
  • 主要厂商包括的Synopsys、Veracode、悬镜安全、默安科技等。

DAST

  • 动态应用程序安全测试(DAST):在测试或运行阶段分析应用程序的动态运行状态。它模拟黑客行为对应用程序进行动态攻击,分析应用程序的反应,从而确定该应用是否易受攻击。

  • 运行原理与方式:以 Web 网站测试为例对于动态应用程序安全测试进行介绍,主要
    包括三个方面的内容:

    • 1)信息收集:测试人员在测试开始前,需要收集待测试网站的全部 URL,包括静态资源和动态接口等,每一条 URL需要包含路径和完整的参数信息。测试人员收集 URL 的方式包括但不限于:
      • (1)从网站源代码中获取 URL 的路径和参数信息,
      • (2)编写网络爬虫对目标网站进行爬取,获得网站每一个页面中包含的全部URL 信息。网络爬虫不仅要具备静态页面的爬取和分析能力,同时也要具备对 Web2.0 时代新型的动态展示页面的爬取和分析能力。此外,网络爬虫在最终输出结果前,应当具备以某种规则对 URL 列表进行去重的能力
      • (3)在目标网站的服务器上安装 Web 流量采集工具,该工具会记录该网站所有的 Web 请求。测试人员模拟正常访问把目标网站的所有功能都是访问一遍,随后从流量采集工具中导出全部请求信息,从中提取出网站的 URL 列表。除了收集 URL,测试人员还要解决目标网站访问权限的问题。如果网站的部分功能需要账号登录后才能访问,则测试人员需准备一套或多套能满足测试要求的账号密码信息,并将信息传递到安全测试工具中,且保证测试过程产生的数据包都有携带登录态信息。
    • 2)测试过程:测试开始前,测试人员应当将测试所需的 URL 列表导入到测试工具中。导入的方式包括但不限于:
      • (1)手工从测试工具的管理页面逐条添加
      • (2)测试工具本身提供 API 接口,测试人员可以通过编写程序调用该 API 接口进行提交
      • (3)测试人员将 URL 集合按照一定的格式写入到文件中,然后上传到测试工
        具的服务器上,使得后者可以读取。测试工具需要提供“检测风险项”的选择列表,测试人员可根据测试计划选择不同的风险检测项。测试工具在测试过程中,应当对访问目标网站的速度进行控制,保证目标网站不会因为同一时刻的请求数过高,导致网站响应变慢或崩溃。测试人员在设定测试任务的基本信息时,应当根据目标网站的性能情况填入“每秒请求数”的最大值。测试工具在测试过程中应当保证每秒发送请求的总数不超过该数值。
    • 3)测试报告:在安全测试各步骤都完成后,输出测试报告。测试报告一般包含总览页面,内容包括:
      • (1)根据测试过程产生的各种数据,输出目标网站安全性的概要性结论;
      • (2)测试过程发现的总漏洞数,以及按照不同安全等级维度进行统计的漏洞数据。测试报告应详细列出每一项风险的详细信息。详细信息包括:风险名称、风险等级、修复方案等关于风险的基本信息,证明风险存在的证据,包括复现风险情况的步骤和方法,测试过程中被用于证实存在风险的原始请求数据包和网站响应数据包,以及在原始请求数据包中指出触发漏洞的关键点。
  • 主要厂商及工具包括Micro Focus Fortify WebInspect、Veracode等

RASP

  • 实时应用自我保护(RASP):是一种运行时应用自我保护程序,可自身注入到应用程序中,与应用程序融为一体,实时监测、阻断攻击,使程序自身拥有自保护的能力,并且应用程序无需在编码时进行任何的修改,只需进行简单的配置即可。通过RASP可以实现对关键函数的监控,获取关键函数的参数信息(如对数据库操作进行监控)。
  • 运行原理和方式:注入到被保护的应用中,替换关键函数,获取到应用运行时的上下文,根据运行时上下文或者敏感操作,对攻击进行精准的识别或拦截。实时采集Web应用的高风险行为,在安全测试阶段可以辅助测试人员提前发现安全漏洞,在业务线上运行阶段可以实时检测到外部攻击和漏洞利用,可检测的风险包括SQL注入、命令注入、代码执行、上传漏洞、文件读取等。同时通过特征规则、上下文语义分析及第三方安全产品数据关联分析等多种安全模型来提升检测准确率,相较于传统Web应用安全产品,RASP从海量的攻击中排除掉了大量的无效攻击,聚焦发现真实的安全威胁。
  • 主要厂商以及工具包括Micro Focus、Prevoty、Waretek、安百科技的灵犀、百度安全的OpenRasp等。

WAF

  • Web应用防护墙(WAF):作为Web安全主要防护手段,是通过执行一系列针对HTTP/HTTPS的安全策略来专门为Web应用提供保护,主要用于防御针对网络应用层的攻击,如SQL注入、XSS跨站脚本攻击、文件包含攻击、CC拒绝服务攻击等。
  • 运行原理和方式:WAF一般部署在web服务器前面或者作为一个模块嵌入在web服务器里面,对请求的入流量和出流量均可以进行过滤检测或处理。
    • 1)请求入流量方向上,在用户请求到达应用程序前对用户请求进行检测过滤,采用基于规则的模式特征匹配或基于语义理解和机器学习的检测方案,分析并校验每个用户请求的网络包,拦截恶意攻击流量,放过正常请求,确保每个用户请求有效且安全。
    • 2)出流量响应方向上,在响应到达客户端之前对响应请求内容进行内容检测,可以准确防护恶意攻击及避免敏感信息泄漏等。同时,在处理响应时通过下发JS方式,结合风控大数据,解决一些风控场景需求,如防刷,打击羊毛党等。
  • 研发运营安全体系中,在预发布阶段流水线中加入检测是否接入WAF防护的质量红线,保证业务服务上线环境处于WAF安全防护状态,在安全运营响应阶段WAF作为重要的安全能力工具对线上攻击请求进行实时防护。以默认安全为原则,WAF在和Web接入层直接交互结合后,业务通过Web接入层开放外网Web服务时,就默认带有WAF防护能力,可以及时有效的阻断实际产生的某些攻击尝试和行为。WAF的所有基础配置和策略下发可以由WAF运营人员统一实施,无需业务介入,就默认带有基础防护能力。同时,WAF提供防护能力开放平台,用户可以在WAF开放平台自助便捷操作,实现场景化定制防护需求。
  • 主要厂商包括Imperva、Akamai、Cloudflare、AWS、阿里云、腾讯云、奇安信、绿盟等。

总结

整体来说,随着DevOps和安全的不断融合与实践,研发运营安全相关的管理制度与规范更加完善,并会结合工具和技术进行一步发展,找到效率安全并行的平衡点,对于整体工具链的生态会围绕打造安全可信的整体生态进行,以满足不同用户、行业和场景的安全需求,同时对于整体软件相关的供应链要求将会有进一步的上升。

    原文作者:淼叔
    原文地址: https://blog.csdn.net/liumiaocn/article/details/109505275
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系管理员进行删除。