Gary McGraw描述了构建安全软件的几种最佳实践。
一种是利用所谓的虐待案件 。
由于他关于滥用案例的章节使我渴望获得更多信息，因此本帖子将探讨有关该主题以及如何将滥用案例纳入安全开发生命周期 （SDL）的其他文献。
用例对功能需求建模
滥用案例是对使用案例的改编， 即系统与其环境之间交互的抽象事件。
用例包含许多相关场景。
场景是对系统与特定参与者之间特定交互的描述。
每个用例都有一个主要的成功方案和一些其他方案，以涵盖变化和例外情况。
演员是外部主体，可以是人类，也可以是非人类。
为了更好地理解，每个用例应说明主要演员正在努力的目标 。
用例在UML图（请参见左侧的示例）中表示为椭圆形，这些椭圆形连接到代表角色的棒图上。
用例图随附文本用例描述，这些用例描述解释了参与者和系统之间的交互方式。
用滥用案例对安全需求进行建模
经常使用案例中的某些行为者也可能在滥用案例中充当攻击者（例如，在内部威胁的情况下）。
然后，我们应该引入一个新的参与者以避免混淆（可能使用继承 ）。
这与使演员代表角色而不是实际用户的最佳做法一致。
与常规角色相比，攻击者的描述更为详细，从而可以更轻松地从他们的角度看待系统。
他们的描述应该包括他们可以使用的资源，他们的技能和他们的目标。
请注意，目标比（用例）用例的目标更长远。
例如，攻击者针对滥用案件的目标可能是在特定服务器上获得root特权，而她的目标可能是工业间谍活动。
滥用案例在某些方面与用例有很大不同：虽然我们知道用例中的参与者是如何实现其目标的，但我们并不确切知道攻击者将如何破坏系统的安全性。
如果可以，我们将修复漏洞！
因此，与常规用例场景相比，滥用用例场景对交互的描述不够精确。
建模其他非功能需求
请注意，由于用例中的参与者不必是人类，因此我们可以采用类似的方法来滥用具有“网络故障”等参与者的案例，以对非功能性需求进行建模，这些需求超出了安全性，例如可靠性，可移植性，可维护性等。
为此，必须能够将非功能性需求表示为一种交互方案。
在这篇文章中，我将不再进一步讨论这个主题。
创建滥用案例
在以下情况下，最好创建滥用案例模型：在需求收集期间。
在确定（甚至定义）常规用例之后，最容易定义滥用案例。
滥用案例建模要求戴黑帽 。
因此，邀请具有黑帽功能的人员（例如测试人员和网络运营商或管理员）参加会议是有意义的。
制定虐待案件的第一步是寻找行动者。
如前所述，常规用例中的每个参与者都可能在滥用案例中变成恶意参与者。
接下来，我们应该为不同类型的入侵者添加演员。
这些基于其资源和技能而有所区别。
当有了参与者时，我们可以通过确定滥用案例与系统的交互方式来识别它们。
通过将常规用例与攻击模式结合起来，我们可能会识别出这种恶意互动。
通过将它们与常规用例系统地和递归地结合起来，我们可以发现更多的滥用案例。
结合用例和滥用案例
有些人将用例和滥用案例分开放置以避免混淆。
其他人将它们组合在一起，但将滥用案例显示为倒置的使用案例（即，黑色椭圆形带有白色文本，演员黑色头部）。
后一种方法使使用UML关联将滥用案例与用例联系起来成为可能。
例如，一个滥用案例可能会威胁一个用例，而一个使用案例可能会减轻一个滥用案例。
后者的用例也称为安全用例 。
安全用例通常处理安全功能 。
我们不应该期望赢得这场“比赛”。
相反，我们应该在安全性要求和系统的其他方面（如可用性和开发成本）之间做出良好的权衡。
理想情况下，通过使用良好的风险管理框架，利益相关者可以清楚地看到这些权衡取舍。
重用滥用案例
结论
尽管滥用案例与常规使用案例有所不同，但它们的主要价值在于，它们以软件开发过程的涉众可能已经熟悉的格式提供有关安全风险的信息。
特别是开发人员可能会了解它们。
对于那些几乎没有安全背景或没有安全背景的人来说，这应该使他们更容易开始考虑保护系统安全以及如何权衡安全性和功能性。
但是，威胁建模似乎具有与滥用案例相同的优势。
由于威胁建模受工具支持，因此毫不奇怪，人们将其包含在安全开发生命周期中而不是滥用案例。
翻译自: https://www.javacodegeeks.com/2012/09/security-requirements-with-abuse-cases.html
364
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
