产品安全和开源合规在软件研发项目中越来越重要，滥用案例是一个研发活动中比较好的实践。滥用案例的介绍来源于OWASP官网的这份说明
https://cheatsheetseries.owasp.org/cheatsheets/Abuse_Case_Cheat_Sheet.html，有兴趣的可以直接看原文。
Why：项目中为何要引入滥用案例？
通常，我们在对应用程序的安全级别提出要求时，会要求满足以下要求：
-该应用程序必须是安全的
-该应用程序必须防御针对此类应用程序的所有攻击
-该应用程序必须防御来自OWASP TOP 10的攻击
-......
这些安全要求过于笼统，因此对开发团队的工作无法进行具体的指导。从实用的角度来看，为了构建安全的应用程序，根据应用程序所在的业务和技术上下文环境，识别出应用程序必须防御的具体攻击变得非常重要。
What：什么是滥用案例？滥用案例实时的方法是怎样的？
【定义】
A way to use a feature that was not expected by the implementer, allowing an attacker to influence the feature or outcome of use of the feature based on the attacker action (or input). |
-OWASP定义：实现的功能特性，被攻击者以未预计到的方式进行使用，导致影响特性功能自身，或者导致特性不该有的运行结果。
Misuse and abuse cases describe how users misuse or exploit the weaknesses of controls in software features to attack an application. This can lead to tangible business impact when a direct attack against business functionalities, which may bring in revenue or provide positive user experience, are attacked. Abuse cases can also be an effective way to drive security requirementsthat lead to proper protection of these critical business use cases. |
-Synopsys公司的定义
【实施】
1、识别滥用案例清单的方法
可以通过正式的分析，也可以通过头脑风暴，也可以采用工作坊等方式进行滥用案例清单的识别和梳理。如果使用工作坊方式，最好把业务分析师、风险分析师、技术负责人、质量分析师、测试人员、渗透攻击人员等汇聚在一起，通过业务和技术的维度，进行识别梳理滥用案例列表。
Example:
Technical flagged abuse case: Add Cross Site Scripting injection into a comment input field.
Business flagged abuse case: Ability to modify arbitrary the price of an article in an online shop prior to pass an order causing the user to pay a lower amount for the wanted article.
2、什么时候识别
对于敏捷项目，定义滥用案例清单的研讨会必须在Sprint中包含用户故事的会议之后进行。在瀑布式项目中，必须在企业识别并了解实施的业务功能时进行定义研讨会。
无论使用哪种项目模式（敏捷或瀑布），选择要解决的滥用案例都必须成为每个功能说明部分（瀑布）或用户故事接受标准（敏捷）中的安全性要求，以便进行额外的成本/工作量评估，确定并实施对策。
每个滥用案例都必须具有唯一的标识符，以便在整个项目/冲刺中进行跟踪。唯一ID格式的示例可以是ABUSE_CASE_001。
3、怎么识别
Description of the business feature by the business
->Enumeration of the possible attacks against the feature
->Risk rating on all possible attacks identified
->Filtering of the attacks based on risk rating
->Definition of the list of abuse cases for a feature
简单来说必须有以下几个步骤：
1）关键业务人员从业务角度解释当前功能。
2）攻击者提议并解释可以针对该功能执行的一系列攻击。
3）对于提出的每种攻击：
-应用设计设计考虑应对策略，包括首选在哪一层进行防护（基础设施架构、网络层、代码实现等等）
-技术人员对提出的对策的可行性提供反馈。
-渗透人员可以使用CVSS打分来确定风险等级。
-风险评估人员接受/提高/降低风险评级，使其与公司的实际业务影响相匹配。
4）业务、风险和技术关键人员找到共识，并过滤当前功能的滥用列表，以保留必须解决的功能，然后在“滥用案例”表中相应地标记它们。
4、如何跟踪
-根据识别的清单，制定验收准则，评估实施工作量
-功能开发时考虑滥用情况的防护
-进行验证：验证的方式可以是自动化的或者手工的。
自动化：
--静态应用程序安全测试（SAST）或动态应用程序安全测试（DAST）
--单元测试、集成测试或功能安全性测试的自动化实现
--。。。
人工：
--安全代码审查
--提供滥用案例的列表，人工去验证
--。。。
5、滥用案例示例
从feature推导abuse case，明确应对defense
功能表：
对策表：
滥用案例表：
How：在实际项目中应该怎么实施？
1、需要达成几点共识
-滥用案例的识别是常态，结合例行功能特性开发常态化落地，无法通用一种方式解决所有问题。
-并不是所有的攻击案例都是滥用案例，需要项目相关人员达成共识。
-滥用案例的守护不一定都是能够自动化解决的，但是能自动化的一定自动化。
2、流程需要内嵌
-结合现有的软件研发流程，在方案设计或者用户故事卡评审的时候就要考虑进来，可以结合威胁建模一起做。
-在验收测试环境设计对应的安全用例进行验证闭环。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
