（一）介绍
有一段时间，Web应用安全被认为只有在使组织符合行业支付标准或政府合规性要求时才具有价值。现在来看，Web应用安全已被认为是大多数组织的一个关键任务。用户需求推动各类组织将开发资源转移到基于Web的、面向客户的应用，其功能和内容可以快速变化，以跟上公司市场、竞争或战略的变化。今天的基于Web应用是复杂的，基于各种编程语言、Web服务器和数据库，并由各种客户端浏览器访问，而后者可能具有很多安全问题。云平台可以轻松地扩展基础设施以满足需求，但是它们使安全模型更加复杂，特别是对于必须管理数百甚至数千个web
app时，通常非常复杂。
在本白皮书中，SANS提出了一种方法，在建立和维护跨企业的Web应用安全方面，帮助组织获得能力成熟度。这种方法借鉴了业界领先的一些建议：CMMI的能力成熟度，OWASP的测试框架和SANS的安全最佳实践。
漏洞管理在整个Web应用程序生命周期中安全方面起着不可或缺的作用。漏洞管理依靠漏洞扫描来评估APP，开发人员可能无法直接访问所有源代码或管理员无法管理底层服务器的所有配置。由于组织希望在Web应用安全的能力成熟度方面取得成功，他们应如何应对改进漏洞管理所固有的挑战？应该如何选择自动化工具，使扫描更有效率和效率？
Web App安全的成熟度
企业如何评估其整体组织流程的成熟程度？其基于Web的应用安全的有效性？能力成熟度模型提供了一个实践的参考框架，无论是开发，服务提供还是采购。该组织可以将其目前的做法与框架进行比较，以确定需要改进领域。
CMMI是1987年卡内基梅隆大学开发。今天由CMM研究所管理，它被全球公认，该计划在101个国家和11个国家政府中被使用，翻译成10个语言。
CMMI for Development（CMMI-DEV）是框架，允许组织改进其产品和服务开发、维护和获取过程，从而系统地提高客户满意度。 CMMI-DEV提供了评估流程能力和流程成熟度的标准。
安全性几乎涉及组织的每个方面。有针对性有计划的安全比特设安全性更可靠。引入了“设计安全”（Security by Design），将安全流程无缝集成到CMMI-DEV的相关流程类别中。其四个过程领域如表1所示。
虽然CMMI-DEV为特定进程（如软件，系统和安全工程）提供目标级定义和属性，但它既不是工程开发标准也不是开发生命周期框架。 它不提供设计和开发工作的操作指导。
OWASP帮助组织开发，购买和维护可信任的软件应用程序。 它提供了从开发和测试的最佳实践资源 – 其TOP10列表通常被认为是当前Web危害最大的安全漏洞，也是提供了解决这些漏洞最有效的方法。
因此，建立Web应用安全的成熟度方法的方法如下所示：
现在让我们将这个公式应用于Web应用安全、漏洞管理和使用漏洞扫描。
重点：WEB APP生命周期的漏洞管理
漏洞管理是对组织信息系统和应用程序中的缺陷进行识别、评估和修补的持续过程，它超越了基本的扫描，按照风险等级对资产进行分类和分类。它需要与其他关键的企业流程紧密合作，如变更/配置管理或补丁管理。单个不安全的应用程序（或应用程序的组件）可能危及整个网络的安全性。
有效的漏洞管理计划的核心是漏洞扫描。SANS一直主张组织持续性扫描，以应对生产网络和计算环境中不可避免的不断变化。恶意攻击者可以发现严重的软件缺陷，从而危及应用程序的安全性。
SANS还主张扫描（动态应用安全测试或DAST）作为软件测试的一部分，特别是应用从单元测试转移到系统和集成测试阶段。
表2提供了一个视图，无论采用什么开发方法（例如敏捷 ，瀑布，螺旋），CMMI-DEV、OWASP测试框架和SANS实践元素如何应用于漏洞管理，一起支持实现安全的Web应用。
（二）提前规划
设计安全”（Security by Design）强调组织建立开发和维护安全产品的能力，这些产品可以在多个项目中使用。这些过程和工具随后可以被用于各种项目。漏洞管理是OPSD流程领域的具体目标之一。
OPSD具体目标和实践总结
具体目标1：建立安全产品开发的组织能力。
Specific Practice1.1：获得管理承诺和支持，安全和安全业务目标。
SP 1.2：建立标准流程和其他流程资产以实现安全开发。
SP 1.3：建立产品安全意识，知识和技能。
SP 1.4：建立安全的工作环境标准。
SP 1.5：建立漏洞处理过程。
2.1 规划流程
在进行漏洞管理之前，组织应如何投资于所需的流程和工具？ SANS根据OPSD SP 1.5的具体目标建议以下四步法。
步骤1：处理漏洞的流程和工具标准化
小型组织在基本预算限制内工作;由于缺乏管理承诺，较大的组织可能面临同样的问题，因为资金有限。但不要绝望！组织可以采取进化的方法来建立和维护流程和支持资产（工具和存储库）。从小的开始，随着时间逐步成长。
互联网安全中心（CIS）关键安全控制中心的前四个家族与CIS控制18一起可以被认为是Web应用程序安全性的基本要求：
•CSC 1：授权和未授权设备的清单
•CSC 2：授权和未经授权的软件清单
•CSC 3：移动设备，笔记本电脑，工作站和服务器上硬件和软件的安全配置
•CSC 4：持续脆弱性评估与修复
•CSC 18：应用软件安全
不要忽视组织也应该为所有利益相关方（终端用户，运营人员和管理层）投资必要的培训和意识，不要忘记开发者！
第2步：准备漏洞记录和报告（格式和内容标准化）
需要收集有关脆弱性的数据，包括内部系统和外部来源，以及脆弱性数据库（如国家漏洞数据库）以及例如US-CERT告警之类的建议。一旦收集了不同的数据源，挑战就是如何展现数据。给安全分析师展示问题严重程度的介绍与说服管理层所需要的不一样。衡量指标是关键，理想情况下，应以业界公认的措施为依据。例如，“CIS关键安全控制措施的测量标准”提供了建议的指标，可以清楚地向管理层传达操作流程的需求，这些操作流程在获得批准时将有助于快速关闭漏洞。
此外，在开发和监测与评估过程中，还要考虑到漏洞管理在Web应用程序的整体管理中的作用。管理者喜欢跟踪漏洞管理状态的报告，总结发现的漏洞数量，导致的错误修复或修补程序的数量以及解决的问题数量。
步骤3：创建关于漏洞管理的沟通计划
需要以有组织，有效和及时的方式将漏洞扫描的成果，特别是关键问题传达给利益攸关方。那么为什么不建立专门针对漏洞管理的正式沟通计划？漏洞管理计划应至少解决以下问题：
•沟通类型（告警，文本，电子邮件，标准报告，安全咨询）
•沟通的重点/紧急性（关键，高，中，低）
•主要联系方（内部，外部）
•分发列表（如果需要）
•联系方式（将在内部和外部之间变化）
•沟通频率（每日，每周，每月一次，例行问题;在警报的一小时内）
沟通计划将基于基础设施（例如，电子邮件地址，热线或内部网站）。请务必考虑应急通讯，这可能是紧急中断所必需的。事件发生后的媒体沟通。
步骤4：确保漏洞管理流程能持续改进
一旦按照步骤1中定义和建立过程和工具，不要停止。将漏洞管理的使用扩展到组织的其他部分。寻求将漏洞管理嵌入组织的其他操作领域，如变更/配置管理，策略合规性和风险管理，以及安全操作中的传统角色。
2.2 自动化：不是必要的邪恶
明确的所有权通过提供单一决策或控制点来提升安全性。然而，网络应用程序的所有权通常由于组织结构的原因很复杂。代表经营的业务单位的管理人员和负责建立和维护申请的开发或运营团队之间经常存在重大差距。这些差距在生产环境中倍增，这些环境包含内部和商业开发的应用程序，可能在组织内部部署或云计算。最佳实践建议应用程序至少设计有三层体系结构，表示层（presentation）、应用层（application）和持久层（persistence）相互隔离和保护。每一层的服务器应根据其提供的服务适当加固，包括及时修补操作系统，关闭不必要的服务，禁用默认帐户以及建立适当的日志记录和告警。保持层级的安全配置的失败不仅仅会影响Web应用程序，还可能影响其他组织后端系统和整个企业网络。
Web应用安全需要一种整体的方法来识别和补救软件和底层基础架构中的漏洞。组织存在的差距需要被确定和关闭，特别是在开发与业务部门之间。自动化可以帮助弥补这些差距，特别是在大型组织中。
Web应用漏洞扫描器是“扫描Web应用以查找安全漏洞（如跨站脚本，SQL注入，命令执行，目录遍历和不安全服务器配置）的自动化工具”，其中许多可能是由不安全或不正确的编码和设计。另一方面，通用（网络或系统）扫描器可以识别开放端口，主动IP地址和登录，主机操作系统和软件类型，修订版本和修补程序级别以及运行的服务。
图1显示了这两种扫描器类型如何集成到生产环境中，以支持CIS Critical Security Control系列4（连续脆弱性评估和修复）和18（应用软件安全）。 这可以使组织有成熟的漏洞管理，支持持续性监控，从而可以了解企业的安全状况。
这也允许在开发期间进行集成和端到端系统测试，其中DAST是关键方法。 Web应用漏洞扫描器可以在一个尽可能模拟生产的测试环境中快速分析应用程序。 通用扫描工具可用于调查测试网络和计算基础架构。
漏洞的所有指标都应存储在中央存储库中，信息可以根据既定规则进行关联，优先排序和采取行动。图1所示的通用“告警/报告分析系统”应包括与SIEM系统、帮助台/故障追踪系统、以及外部开发的问题报告和跟踪存储库（例如GitHub）的接口。可视化（例如，报告和仪表板）加强了有关预防和保护的决策。此存储库中的数据也必须可用于组织分析和报告平台。
漏洞扫描器看什么？
扫描器在支持的协议、使用的身份验证和会话管理方法以及具有的爬网和解析功能上有所不同。确保扫描器可以解决问题，包括Web应用的架构缺陷和漏洞。
OWASP TOP
10反映了在现实世界中被利用的主要漏洞，包括注入（如SQL，LDAP，XPath），缺少输入过滤，跨站点脚本，身份验证和会话漏洞。
考虑扫描器如何识别漏洞。它是否基于签名的方法？还是利用广泛的启发式Web漏洞检查，由研究和现场的频繁更新支持，可以在定制应用程序中更好地识别问题（包括0-day漏洞）？它还是否支持已知漏洞的来源，例如CVSS？
还可以从CIS控制系列1至4（重点为3和4）以及控制18中获得一组可靠的技术要求。
接下来，探索扫描器的准确度 – 最重要的指标 – 以及可靠性，可扩展性和报告质量。针对基准进行概念验证，测试套件旨在评估自动化工具的速度，覆盖面和准确性。基准测试可以基于行业定义的标准或您的组织定义。
理解扫描器调整过程是必不可少的。例如，基准测试可能会有false/true
positives和false/true
negatives。如果未正确配置，自动扫描程序可能无法正确抓取目标，并且有误报，这需要手动验证（这是一个耗时而困难的过程）。这违背了自动化的目的！
因此，在基准测试过程中，还应该对预扫描和扫描后操作进行评估。扫描器是否需要大量配置，还是可以自动调整？在没有安全专家的参与下，能否验证发现？
如果缺乏准确性，您可能会最终运行两种不同的扫描器，希望一个能互补。这为扫描过程增加了时间，成本和努力，因为IT人员必须花费两倍的时间进行扫描过程，并梳理两组扫描结果。
注意报告功能 – 特别是扫描器在定义显示和排序标准时提供的灵活性以及呈现最佳可视化方法。该工具是否提供仪表板？它是否显示符合Gramm-Leach-Bliley法案等合规标准？是否可以按位置、业务单位或优先级来分组和标记扫描资产吗？
扫描其的输出是否容易映射到组织采用的常用术语，因此可以与通用的报警和状态报告分析平台集成，如图1所示。
最后，将所需功能与预算和可用资源进行匹配。不要忽视工具对管理和分析所需的时间和资源的现实估计！自动化应该减少对两者的需求，允许拥有数百个Web应用程序的组织集中精力进行修复，而不仅仅是确定优先漏洞。
低端漏洞扫描程序可能只是扫描网络或系统并提供补救报告。高端产品可以进一步自动化流程，如配置审核和执行、目标建模，渗透测试和详细的漏洞分析。
对于中小型企业来说，一种基于云的软件即服务（SaaS）工具的漏洞扫描器可能是有益的。内部部署需要在硬件和人员方面进行投资。
基于云的扫描对于大型企业来说可能更为理想。它允许这些组织轻松扩展业务，而无需对专门的硬件和员工进行大量投资。基于云的扫描工具可以对所有网段（周边到内部）以及云服务的所有组织资产提供持续性监控。一个例子是一个拥有1,500个域名的组织。按需解决方案可以在24小时内扫描1,000个网站，不需要安装，手动集成和维护
– 企业只需订阅服务，配置扫描即可。
（三）项目管理
漏洞管理支持整个Web应用生命周期中与安全相关的活动和风险的整体管理。 主要目的是获得可以防止在相同或相似条件下复发的可操作信息。 漏洞管理项目管理流程见下表。
项目的安全管理：具体目标和实践总结
具体目标(SG)1：准备和管理项目活动，以实现安全。
具体做法（SP）1.1：明确整体计划中包括安全计划。
SP 1.2：规划和提供安全培训。
SP 1.3：选择安全的供应商和第三方组件。
SP 1.4：确定漏洞的根本原因。
SG 2：管理产品安全风险。
SP 2.1：建立产品安全风险管理计划。
SP 2.2：进行产品安全风险评估。
SP 2.3：计划产品安全的风险缓解计划。
漏洞管理也是一个持续的过程。组织过程可以被纳入一个特定的PDCA项目计划中，如图2所示。
（四）工程化
CMMI-DEV下的工程过程与DD＆I的生命周期阶段一致。 有两个关键的活动：第一个是创建技术解决方案，从需求开始，另一个是测试，其中包括验证和验证。
安全需求和技术解决方案：具体目标和实践总结
SG 1：开发客户安全要求和安全架构设计。
SP 1.1：制定客户安全要求。
SP 1.2：根据安全的架构和安全性设计产品设计原则。
SP 1.3：使用安全标准选择适当的技术。
SP 1.4：建立安全产品配置标准。
SG 2：实施安全设计。
SP 2.1：使用安全标准实施。
SP 2.2：在产品支持文档中添加安全。
安全验证和确认：具体目标和实践总结
SG 1：执行安全验证。
SP 1.1：准备安全验证。
SP 1.2：执行安全验证。
SG 2：执行安全验证。
SP 2.1：准备安全验证。
SP 2.2：执行安全验证。
安全验证（Security Verification）：确保Web应用符合规定的要求和标准（例如，架构，代码，配置）。
安全验证（Security Validation）：识别网络应用中无明显的漏洞（例如，在暴露于潜在的威胁时抵制攻击）。
CMMI-DEV工程流程与OWASP的构建步骤相互叠加，如图3所示。协议，平台或编程语言等技术将对Web应用安全产生影响，特别是当将应用放入 最终生产环境。 在定义和设计过程中，对系统体系结构进行审查，考虑到已知漏洞（如OWASP Top 10）和威胁。
（五）安全性：复杂性需要可见性
DAST在开发过程中发挥突出作用。传统上，它是集成和端到端系统测试中的主要测试方法。但是，DAST也可以用来揭示不安全编码实践造成的漏洞。它可以与静态应用程序安全测试（SAST）一起工作，以更有效地找到和修复漏洞，而不是单独使用测试方法。在良好的仪器化测试环境中，DAST演示了各种应用组件在受控条件下如何一起作用，提供了应用在生产中的行为的可视化。
最后，集成的web应用在部署到生产之前需要进行最终测试和验收。整个WEB应用应该进行漏洞扫描。这种测试越稳健，例如确定潜在的0day攻击的敏感度或识别能力，信心就越大。
维护和运行：冲洗和重复
一旦Web应用程序部署到生产中，漏洞管理就成为一个持续的过程。
漏洞管理如何在Web应用后期支持安全性如图4所示。过程的核心是漏洞扫描，支持与CMMI-DEV相关的三个关键进程：配置管理（CM）、测量分析（MA）以及过程和产品质量（PPQ）。
（五）结论
由于安全是一个过程，因此建立有效的漏洞管理程序也是一个过程。最初，组织可能没有成熟度（包括过程、基础设施或人力资源）持续扫描和分析其Web应用程序。但仍需要努力实现这一目标。
而这个程序的核心是有效集成漏洞扫描。持续性漏洞扫描可帮助组织确定从一开始就设计安全性，也帮助解决了修复生产中发现的缺陷。它可以帮助确定漏洞管理程序的性能趋势，安全管理人员和其他管理人员可以使用这些信息来向董事会证明预算。
下一步应该是什么？根据CMMI-DEV的成熟度来构建您的方法。关于如何加强漏洞程序成熟度和使用漏洞扫描的建议如表3所示。
每个成熟度级别为有效实施下一级建立的流程提供了必要的基础。 成熟度水平不应该被跳过，因为较高层次的流程（如CM，MA和PPQ）的成功机会较少，如果没有通过较低层次。
原文地址：https://www.sans.org/reading-room/whitepapers/application/security-design-role-vulnerability-scanning-web-app-security-37810