安全需求-建模归类

漏洞与Bug并不等同,他们之间的关系基本可以描述为:大部分的Bug影响功能性,并不涉及安全性,也就不构成漏洞;大部分的漏洞来源于Bug,但并不是全部,它们之间只是有一个很大的交集。可以用如下这个图来展示它们的关系:

安全漏洞与BUG的关系说明

我们只有对安全威胁/漏洞的原理了然于心并紧扣公司的核心业务进行研究,才可能对我们的基础安全技术的安全性做出正确的评价,以及更加全面的判断和有效验证我们公司的工程实现的安全性。

安全漏洞是信息系统在生命周期的各个阶段(设计、实现、运维等过程) 中产生的某类问题,这些问题会对系统的安全(机密性、完整性、可用性)产生影响。安全漏洞会在系统生命周期内的各个阶段被引入进来,比如设计阶段引入的一个设计得非常容易被破解的加密算法,实现阶段引入的一个代码缓冲区溢出问题,运维阶段的一个错误的安全配置,这些都有可能最终成为漏洞。

和其他事物一样,安全漏洞具有多方面的属性, 也就可以从多个维度对其进行分类,下面提到的所有分类并不是在数学意义上严格的,也就是说并不保证同一抽象层次、 穷举和互斥,而是极其简化的出于实用为目的分类。基于漏洞成因技术的分类具体说明如下:


编号


大类


子类型


基于漏洞成因技术的描述


A.


设计错误类


A-1.协议设计问题


协议设计问题是指在协议设计过程中的错误或不严谨导致的问题,从而导致泄密、崩溃、可远程控制、不可用等后果,此问题影响面非常大。实例:WEP协议的协议设计漏洞


A-2.算法设计问题


算法设计的脆弱性或者某些弱点导致攻击者得到口令HASH后可以非常容易地暴力猜测出等价的明文口令。实例:双椭圆曲线确定性随机比特生成器的问题


A-3.系统设计问题


系统设计上对安全机制的考虑不足导致的在设计阶段就已经引入的安全漏洞。


B.


内存破坏类


此类漏洞的共同特征是由于某种形式的非预期的内存越界访问(读、写或兼而有之),可控程度较好的情况下可执行攻击者指定的任意指令,其他的大多数情况下会导致拒绝服务或信息泄露。


C.


逻辑错误类


涉及安全检查的实现逻辑上存在的问题,导致设计的安全机制被绕过。


D.


配置错误类


系统运维过程中默认不安全的配置状态, 大多涉及访问验证的方面。


E.


输入验证类


E-1.SQL   注入


Web   应用对来自用户的输入数据未做充分检查过滤,就用于构造访问后台数据库的   SQL 命令,导致执行非预期的 SQL 操作,最终导致数据泄露或数据库破坏。


E-2.跨站脚本执行


Web   应用对来自用户的输入数据未做充分检查过滤,用于构造返回给用户浏览器的回应数据,导致在用户浏览器中执行任意脚本代码。


E-3.远程或本地文件包含


PHP   语言支持在   URL 中包含一个远程服务器上的文件执行其中的代码,这一特性在编码不安全的 Web 应用中很容易被滥用。如果程序员在使用来自客户端的 URL 参数时没有充分地检查过滤,攻击者可以让其包含一个他所控制的服务器上的文件执行其中的代码,导致远程文件包含命令执行。


E-4.命令注入


涉及系统命令调用和执行的函数在接收用户的参数输入时未做检查过滤,   或者攻击者可以通过编码及其他替换手段绕过安全限制注入命令串,导致执行攻击指定的命令。


E-5.目录遍历


涉及系统用于生成访问文件路径用户输入数据时未做检查过滤,并且对最终的文件绝对路径的合法性检查存在问题,导致访问允许位置以外的文件。多见于   CGI 类应用,其他服务类型也可能存在此类漏洞。


F.


拒绝服务类


拒绝服务 (DoS) 是指攻击者通过禁用或破坏网络、系统或服务来拒绝为特定用户提供服务的一种攻击方式。DoS 攻击包括使系统崩溃或将系统性能降低至无法使用的状态。但是,DoS 也可以只是简单地删除或破坏信息。大多数情况下,执行此类攻击只需简单地运行黑客程序或脚本。

时间: 2024-10-01 02:50:05

安全需求-建模归类的相关文章

47、软件需求工程的活动可以划分为5个独立的阶段:需求获取、需求建模、形成需求规格、需求验证和需求管理,需求建模是()

2013年下半年软考高级信息系统项目管理师综合知识真题答案与解析: 47.软件需求工程的活动可以划分为5个独立的阶段:需求获取.需求建模.形成需求规格.需求验证和需求管理,需求建模是() A.分析需求的正确性和可行性的过程 B.对需求的抽象描述 C.对生成需求模型构件的精确的形式化的描述 D.开发.捕获和修订用户的需求 信管网参考答案:B 信管网解析: 需求建模就是需求分析过程,目的是对各种需求信息进行分析并抽象描述,为目标系统建立一个概念模型.软件需求工程活动的5个阶段:http://www.

需求建模和表述的技术

核心概念 需求分析最常见的误会是需求分析可以将需求做出成为方案,这是最大的误区,需求应该是还原业务,应该以业务为线索,换句话说就是 需求分析----->业务分析,但 需求分析--X-->方案分析. 什么是分析 分解 提炼 消除矛盾 实际上分析就是分解-->提炼-->消除矛盾这么一个过程. 分解 提炼 消除矛盾 建模技术 什么是建模和为什么要建模 使用UML 用例图 流程图和跨职能流程图 活动图 部署图 需求描述的方式和方法 自然语言 图文并茂 规格化 如何选择适合自己的 谈谈用户界

性能测试之互联网应用需求建模分析

转自:https://blog.csdn.net/musen518/article/details/50553689 某互联应用,预计推广群体达500万人左右,用户使用时间早8点---晚8点,12小时 分析建模如下 1. 注册用户转化率,预估5%,那么注册用户:500万*5%=25万 2. 高峰时段(有活动)每日在线用户,在线率预估10%,那么在线用户数:25万*10%=2.5万 3. 用户常用下单到成功,触发20个请求,总请求量:2.5万*20=50万 4. 利用二八原则计算吞吐量:50万*8

需求工程——软件需求建模与分析阅读笔记01

软件的模拟特性: 导致需求问题的原因中,一个最为重要的原因是:未能很好地理解和掌握"应用"型软件的模拟型以及由此产生的一系列影响和要求. 软件的模拟特性来源于其知识载体的特性:软件在运行中表现出来的特性.行为应该和应用的现实情况保持一致.这样,人们通过 观察软件的表现就可以得出相应现实的问题的答案,即软件模拟了现实. 软件可以被分为三种类别: 面向专业用户的纯工具型软件.面向普通用户的纯工具型软件和应用型软件.专业用户通常是以软件为中心开展工作,工具软件是 他们的主要手段,因此面向专业

需求工程——软件需求建模与分析阅读笔记02

需求工程的j简单定义 需求工程是所有需求处理活动的总和,它收集信息.分析问题.整合观点.记录需求并验证其正确性,最终反映软件 被应用后与其环境互动形成的期望效应. 需求工程的3个主要任务 1.需求工程必须说明软件系统被应用的环境极其目标,说明用来达成这些目标的软件功能,还需说明在设计和实现这些 功能时上下文环境对软件完成任务所用方式.方法所施加的限制和约束,即要同时说明软件需要"做什么"和"为什么"需要做. 2.需求工程必须将目标.功能和约束反映到软件系统中,映射为

《软件需求十步走》读书笔记二

这次都<软件需求十步走>的后三篇,分别为“方法篇”.“规划篇”.“开发篇”. 方法篇: 1.需求工程的方法观 方法的使命就是要将问题的结构和规律展现出来 2.分析计算方法 分析计算是需求规划方法与传统需求分析方法有本质区别的地方之一.分析计算包括系统支撑能力计算和业务发展能力计算 3.结构化分析方法 结构化的分析(又称SA)方法是本书在需求规划中的业务建模.系统建模和体系建模所采用的方法 4.面向对象分析方法 在需求分析中本书采用面向对象的分析方法作为用例分析和功能需求分析的方法 5.需求统一

软件需求十步走读书笔记2

今天读完了软件需求十步走的第二部分.读了知识篇和方法篇.在知识篇中知识体系的构建方法 事物的知识是由知的知识和识的知识构成.识的知识是以知的知识为核心的需求工程的知识构成 需求工程的知识体系是由基础知识体系.专用知识体系.特有知识体系三个部分构成需求工程的基础知识 形式逻辑中演绎.推理.假设.论证等方法对于解决软件需求中“不完整.不准确.总在变.不一致”问题具有帮助需求工程的专有知识.需求工程的专有知识包括软件工程.软件体系架构和信息资源规划需求工程的特有知识 需求规划是新一代软件需求工程有别于

《软件需求十步走》阅读笔记4

需求统一模式:将大部分软件系统的需求进行归类.所有系统需求本质上彼此相似或者它们都会出现在大多数系统中.比如系统都有查询功能,查询功能有特定的需求,但本质上都是相同的.需求模式是定义一种特定类型需求的方法.需求模式包含模式名称.基本细节.适用性.讨论.内容.模板.实例.额外需求.开发考虑.测试考虑10个要素.需求统一模式包括基础需求.信息需求.数据实体需求.用户功能需求.性能需求.适应性需求.访问控制需求.商业需求8类38中需求模式. 何时以及如何使用需求模式,需求模式的目的是帮助定义一个新系统

《需求工程-软件建模与分析之读书笔记之三》

第9章<需求获取方法之观察与文档审查>中提出了常见的观察方法有采样观察,民族志,话语分析,协议分析和任务分析,它能让我们理解复杂的协同事件,获取工作中的异常处理,获取与用户认知不一致的实际共识,了解用户的认知和获取默认知识.在文档审查中,对于相关产品的需求规格说明,所采用的方法是需求重用:对于硬数据采用的是文档分析:对于客户的需求文档采用的是需求剥离.第10章!<需求的组织>提出了需求获取的常见模型驱动方法,包括面向目标,基于场景和基于用例的方法,它可以指导和组织需求获取行为的开展