您的浏览器禁用了JavaScript(一种计算机语言,用以实现您与网页的交互),请解除该禁用,或者联系我们。[新思科技]:以企业规模管理 AppSec 风险 - 发现报告
当前位置:首页/行业研究/报告详情/

以企业规模管理 AppSec 风险

信息技术2023-10-12新思科技爱***
以企业规模管理 AppSec 风险

以企业规模管理AppSec 风险 更多的软件意味着更多的风险来管理 软件行业继续呈现前所未有的增长和变革,随着数字化、云应用和人工智能的兴起,软件已经成为各行各业的支柱业务。然而,软件的快速扩散给开发和应用安全(AppSec)团队带来了新的挑战。 为内部和外部目的加速软件开发意味着组织必须保护越来越多的应用程序。随着时间的推移,这导致了安全工具的激增。因此,团队正在管理大型,复杂,异构的应用程序安全测试(AST)环境,其中数百个应用程序正在由数十种工具进行测试,通常跨多个团队。他们面对着。 随着更多的工具,运行更多的测试,并提供更多的结果,这可能会导致很多噪音。 随着软件数量的增加,攻击面恶意行为者的目标也在增加。此外,人工智能生成代码等开发的增加创造了一个日益复杂的软件供应链。更多的代码导致更多的端到端风险。当这种增加的风险与对代码来源的可见性以及所带来的安全风险的较少时,AppSec团队管理的复杂性甚至更高。 除了软件的重要性和增加的攻击面之外,还增加了监管压力。一些法规已经实施了相当一段时间,例如PCI和HIPPA,但团队也在整理行政命令中关于软件供应链安全,安全软件开发框架和DHS-CISA自我认证的要求。对于那些努力维护和证明其应用程序安全性的团队来说 ,这一切都相当于增加了审查和巨大的声誉、财务和法律风险。 其中许多发展并不新鲜。软件的增长已经发生了很多年,随着安全工具的发展,以企业需求的规模管理所有这些的任务变得越来越复杂。鉴于当前的经济形势,团队面临的预算和资源压力增加了真正的紧迫性。许多团队被要求保护更多的软件,这些软件在日益复杂的供应链中组装,监管压力越来越大,预算或员工人数没有增加。 简化和整合是解决这些问题的关键。它们越来越被视为降低总体总体拥有成本(TCO)、改善总体风险状况以及为团队提供快速风险洞察的方法。 |synopys.com|2 “向左转移”已经演变成“到处转移” 随着软件开发多年来从瀑布式发展到敏捷,安全性也是如此。安全性曾经是事后才想到的,在将应用程序部署到生产环境之前,在QA阶段执行了一些活动。在2000年代初,这种情况发生了变化。引入“左移”的想法是为了在不减慢速度的情况下提高安全性,但是由于缺乏深入的测试,这一过程受到了阻碍。在左移的早期阶段,团队只有在软件开发生命周期(SDLC)的编码阶段才能真正获得测试的静态分析。 2020年,“成熟度模型中的建筑安全性”(BSIMM)报告首次记录了“到处转移”的倡议。“任何地方的转移都会让软件安全计划(SSP)在工件可用后立即执行安全测试,无论SDLC中的可用性下降。由于数字化转型要求所有部门进行软件创新,因此到处转移已成为安全专家现在倡导的主要模式。 因此,组织不断进行测试,以提高安全测试的效率和有效性。整个SDLC的应用程序安全活动也相应增加,开发团队现在的任务是在常规开发工作流程的基础上加入,学习和运行一整套安全工具。 因为到处转移意味着到处都是AST,AST必须共同充当遥测发生器,这是工程管道的一部分。当且仅当优先级确定表明现在必须解决问题时,必须对AST结果进行策划并提交给工程团队。遥测还必须超越AST。从自动化AST到程序和一致性问题,整个安全功能必须从中心点运行,以确保一致性并提供必要的监管控制。依靠电子表格、电话、电子邮件和昂贵的小组会议,而不是自动化的安全门,是增加成本和降低组织风险洞察力的众多因素之一。 快速安全的挑战 当团队的产品安全目标和开发速度冲突时,组织如何平衡安全性和速度?开发人员的目标是速度-他们通常会评估构建功能并将其推向生产的速度。从历史上看,安全并不是他们工作的一部分,即使安全无处不在,安全团队的一个长期挑战是,开发团队经常寻求将非关键缺陷定义为可以在以后解决的技术债务。同时,如果安全团队正在自动化策略,并在工件可用时立即设置测试门,那么每个开发团队都会在开发周期的更多阶段对更多工件进行更多测试。当你在团队和工具之间增加这一点时,所有这些测试都变得越来越难以管理。 主要安全活动发生在SDLC的所有阶段。这包括 •规划阶段的威胁建模和风险分析 •IDE工具可在开发人员实时编写代码时测试和提供补救指导 •构建和测试阶段的“三大”-静态应用程序安全测试(SAST),软件组成分析(SCA)和动态应用程序安全测试(DAST) •生产中的渗透测试和连续动态测试 在寻求保护SDLC的过程中,许多组织发现自己被太多的测试、太多的结果和太多的工具淹没了。在企业规模上管理AppSec需要工具、流程和人员的组合,以保持开发以您的业务需求的速度进行,同时确保您保护您的业务、声誉和客户。 让我们来看看在SDLC的每个阶段中执行的一些重要的AST活动,从这一切的核心开始:风险管理。 软件复杂性意味着安全复杂性 导航复杂的软件环境可能会将宝贵的资源从关键的开发活动中转移出来,从而阻碍了敏捷性,并使组织难以快速响应不断变化的市场和客户需求。 在安全方面,安全工具环境的复杂性增加会减慢生产速度并增加风险。当开发管道陷入困境时,开发团队可能会跳过或忽略安全门以实现其开发里程碑。问题无处不在。企业战略小组最近的一篇论文“破解DevSecOps代码”发现,超过70%的企业正在使用10种以上的AST解决方案。 SDLC中的工具蔓延 DevOps工具缺乏标准化,这使得自动化并将其集成到CI/CD管道中成为企业安全团队的挑战。 安全复杂性是软件复杂性在组织中带来的问题的一个缩影。更多的安全工具导致更多的测试,从而转化为更多的结果。由于结果是从各种点工具返回的,开发人员经常会收到重复的结果和低效的、非上下文的补救指导。这意味着他们浪费了宝贵的时间和资源,试图在他们甚至希望开始修复安全问题之前对其进行分类。由于大多数开发人员的主要工作是运送软件,而不是运送安全软件,他们最终发布了他们知道不安全或有漏洞的软件。管理工具、执行维护以及将工具集成到现有环境中所需的努力阻碍了组织保持生产力。这种安全工具的蔓延增加了复杂性,消耗了资源,并且在规模上变得难以管理。 应用程序安全状况管理可让您控制 要控制安全蔓延,您需要一个全面的策略来规划您的应用程序安全程序。它应该包括您的风险偏好和将执行您的SLA的策略,您的关键测试需求,以及对工具和供应商的要求,以帮助您实现这一目标。理想情况下,此策略将允许您整合工具、测试和结果,并集中策略、测试编排和报告等活动。 应用程序安全状况管理(ASPM)工具可以通过提供单一的事实来源来设置和实施策略,并在SLDC中识别、关联和确定安全漏洞的优先级,从而帮助您实现这一目标。ASPM工具可以充当 应用安全团队和开发团队之间的抽象层。它们提供了一个中央控制点来管理您的AppSec程序,并使开发人员摆脱了安全工具本身的复杂性。这是开发人员的梦想- 他们不渴望学习AppSec管理工具,他们希望通过已经使用的工具使用相关的安全信息。ASPM工具允许AppSec团队在整个组织中实施和管理一致的工作流和策略 ,而无需跨多个工具和团队复制这些策略,或培训开发团队如何使用它们。 完成此操作并集成AST工具后,您可以使用关联和分析来自各种来源的数据的ASPM解决方案来简化问题解释、分类和补救。ASPM解决方案还管理和协调安全工具,以便您可以实施自动化的安全策略。ASPM允许安全团队通过利用整个软件开发环境中的安全和风险状态的整合视图来集中管理应用程序安全结果。 ASPM工具允许您通过提供整个安全形势的单一统一视图来实现此目的。这使您可以在一个集中的位置对调查结果、资产、利益相关者和策略进行标准化、汇总和优先排序。这种整合方法 洞察管理改进了安全流程,优化了资源分配,提供了快速的审计时间,以确保法规遵从性,并在整个组织中实现更强大和有效的安全态势。 拥有此统一视图后,您可以使用数据来打破安全工具和团队之间的孤岛,从而促进持续有效的AppSec实践。您可以将安全工作集中在单个平台上,从而实现一致的安全评估和简化的工作流程,而不是杂耍令人眼花缭乱的工具。这不仅节省了宝贵的时间和资源,而且确保所有利益相关者都可以访问应用程序安全的统一视图 ,从而实现更好的决策和风险管理。 有了抽象层,并配备了快速评估功效所需的数据,您就可以整合下面的工具。这样做的影响不仅可以消除安全工具堆栈中的复杂性和潜在重复,还可以简化预算、培训、支持和实施,以提高您的整体appsec计划TCO。 在预算和资源压力巨大的情况下,ASPM可实现AppSec计划实施的一致性、快速的风险洞察、关键缺陷的高效优先级排序以及工具整合。那么,组织如何在开发的各个阶段提高安全性呢?让我们来看看一些最佳实践,以帮助您在整个SDLC中加强安全状况。 |synopys.com|5 SDLC规划阶段 AppSec在SDLC的规划阶段经常被忽视,尽管数据显示近50%的软件系统“实施错误”可归因于设计缺陷。安全软件设计有助于防止由设计缺陷引起的安全漏洞。因此,全面的威胁建模是SDLC规划阶段的一项重要工作。 威胁建模从与软件系统的业务所有者进行访谈开始,以更好地了解影响系统业务目标的安全风险。然后以体系结构图的形式说明系统中存在的主要组件、资产 、威胁代理和安全控制,以捕获这些实体及其之间的关系。最后一步是识别基于软件的风险,并根据业务影响确定它们的优先级(例如Procedre,未经授权访问数据或服务可用性)。 在规划和设计阶段的早期进行威胁建模,可以避免成本高昂的返工,以解决后来在SDLC中发现的安全缺陷。最重要的是,与等待编写代码或执行QA 测试相比,在SDLC中早期发现和修复安全问题的成本更低、侵入性更低、耗时更少。 SDLC编码/构建阶段 静态应用程序安全测试(SAST)是AppSec不可或缺的一部分。它是在不执行代码的情况下对非运行环境中的应用程序源代码进行全面分析。当代码更改的破坏性最小且最容易解决时,SAST在SDLC的早期检测软件安全漏洞和代码质量问题。SAST工具应包括 •通过IDE、SCM系统和CI管道与常见开发人员工作流集成,可触发SDLC每个阶段的自动扫描 •可配置的安全性和质量检查器,可进行调整以匹配每个应用程序的风险状况 •能够运行与您的总体AppSec策略一致的基于策略的扫描,同时平衡整个SDLC的工作效率和安全性 •一流的代码质量问题识别,以及随着时间的推移跟踪和管理符合通用安全和行业标准的能力 随着对开放源代码的依赖不断增加,SCA工具在您的现代AppSec武器库中至关重要。良好的SCA工具有助于管理安全性,许可证合规性和代码质量风险,这些风险来自在应用程序,容器和基础架构即代码(IaC)中使用开放源代码。同类最佳的SCA工具应 •根据正在运行的SDLC中的哪个阶段以及正在测试的软件的重要性,提供多种方法来识别开源 •生成和监控完整的软件材料清单 •包括全面的开源组件知识库,并支持自己的安全源,以增强和及时的信息以及针对开源漏洞的补救指导 •快速轻松地分析供应商提供的二进制文件,以识别软件供应链中的薄弱环节,而无需访问源代码 另一个经常被忽视的考虑在编码/构建阶段运行的AppSec测试是恶意代码检测(MCD)。没有人愿意相信内部黑客会发生在他们身上,但事实是,心怀不满的开发人员可以并且确实在软件系统中植入恶意代码。彻底的MCD测试会发现可疑的结构,并识别典型安全工具找不到的恶意代码以及内部威胁参与者 。MCD提供有关恶意代码管理的专家建议,并提供漏洞修复策略。 SDLC测试阶段 除了在适当的测试阶段运行SAST和SCA之外,交互式应用程序安全测试(IAST)在SDLC的测试阶段至关重要。它利用运行时测试技术来识别与 运行Web应用程序中的漏洞。IAST通过软件检测来监视应用程序的运行,并收集有关其功能和执行方式的信息。它以提供快速分类的准确结果而闻名。IAST 工具应提供 •支持基于云的应用程序(除了本地),微服务,容器,无服务器等。