导图社区 CISSP-8-应用安全开发
- 188
- 9
- 举报
CISSP-8-应用安全开发
CISSP-信息系统安全专业认证之应用安全开发思维导图，主要包括应用开发学习目标、系统开发安全、软件开发模型、编程的语言和概念、典型的应用系统、评估软件安全的有效性。
编辑于2021-11-10 12:06:10- 安全管理
- 相似推荐
- 大纲
应用安全开发
应用开发学习目标
软件开发生命周期安全
软件开发生命周期的方法
成熟度模型
运行和维护
变更管理
综合产品团队
开发环境中的安全控制
软件环境的安全（程序语言、库、工具箱、综合开发环境、 运行时间）；
源代码级的安全弱点和漏洞
配置管理作为安全编码的重要组成
应用程序界面的安全
软件安全的效果
审计和日志的变更
风险分析和缓解 （纠正性措施、测试和验证、回归测试）
用户接受测试
应用开发关注点
架构模式
三层架构
用户
前端
复杂中间件
数据仓库
错误跟踪和安全功能
客户端/服务器
客户端：用户接口，本地数据库操作、通信机制
服务器：执行和处理数据请求，返回结果
浏览器/服务器
环境控制V应用控制
多种控制手段的平衡
理解环境控制和应用控制的界限
安全性V功能性
软件功能和安全手段的平衡
功能需求、安全需求和安全机制的平衡
安全性V用户体验
通常成反比
安全功能V配置安全
默认安装无法保证安全性
配置安全未启用（应该默认拒绝访问）
未遵循最小安装原则
后期补丁安装
系统开发安全
SDLC
项目启动
明确需求，确定产品的基本安全目标
风险分析评估，评估威胁和脆弱性， 估计不同安全对策的成本/收益比
风险管理
风险分析
需求分析
安全需求
系统或应用程序的功能需求
标准和指导原则
出口限制
数据的敏感度级别
相关的安全策略
成本/收益分析结果
达到目标所需的保护级别
项目开发和需求管理团队对现行以及可能的未来功能需求进行复杂的分析以确保新系统满足终端用户要求
项目组员还会审查项目初始阶段输出的文档，并根据需求加以修正和更新。
相对较小的项目而言，以上过程往往包含在在项目初始阶段。
安全需求也应该对应形成。 （安全需求是在需求分析阶段确定， 安全人员在需求阶段就要参与）
系统设计
软件开发作为系统设计的一部分
一般在系统设计时决定使用软件实施的功能 而软件的验证必须要考虑所有为系统而设计的背景。 软件验证包含确认符合所有软件规格说明已经确认所有软件要求可追溯到系统规格说明中。
硬件不同与软件
一般在系统设计时 决定使用软件实施的功能。
而软件的验证必须要考虑所有为系统而设计的背景
软件验证包含确认符合所有软件规格说明已经确认所有软件要求可追溯到系统规格说明中。
考虑规格说明
软件和硬件的不同
软件是可以有分支的，软件基于不同的输入能执行不同的命令，所以软件是复杂的；
软件不是实体的也就不会磨损；
软件不是实体的也就不会磨损；
软件很容易和快速的改变；
软件的开发流程应充分计划、控制以及进行记录，用于检测和矫正由于软件变更所带来的非预期结果
.软件组件没有像硬件一样经常进行标准化以及可替换的。
软件组件没有像硬件一样经常进行标准化以及可替换的。 software components have not been as frequently standardized and interchangeable as hardware components
用于描述用户需求和系统内部行为的工具
包括系统与软件设计相关的所有活动。
设计系统架构，系统的输出和系统接口
建立数据输入，数据流和数据输出需求，以及一般基于公司的安全架构设计软件安全功能。
设计
数据设计
抽取数据设计和信息模型数据，转换为数据结构
体系结构设计
定义了主要结构和应用程序组件之间的关系
过程设计
将结构化组件转换为描述性过程
安全设计方法
威胁建模（STRIDE）
攻击面最小化分析
净化输入输出
需要考虑的问题
后续阶段的工作分解结构（WBS）
产品的细节和实现产品的环境
产品的模块化合重用问题
软件开发和实施
主要工作
源代码已经生成、测试场景和测试用例也相应开发出来
开始实施单元和集成测试
程序和系统也开始文档化为了维护然后向验收性测试和产品转化
测试类型
单元测试
验证数据结构、逻辑和边界条件
集成测试
验证组件是否按照设计规范中协同工作
系统测试
功能/性能
验收测试
确保代码满足客户的需求
回归测试
进行系统变更后会从新测试，以 确保功能性、性能和保护级别
功能测试
性能测试
负载测试
压力测试
模糊测试（Fuzzing testing）
发送复杂/随机的数据给软件来引起软件的错误，主要用于识别缓存溢出、DOS、注入、验证错误以及其他可能导致软件死机、崩溃或发生各种错误。
脆弱性扫描（Vulnerability scanning）
通过自动化工具检查程序的主要错误，如强类型语言的错误、开发和配置错误、交易序列错误（ transaction sequence faults ）、映射出发条件（ mapping trigger conditions. ）等，通常在扫描完后需要手工进一步的调查。
人工测试
通过人员的经验和直觉来分析程序，通常使用计算机技术来判断，测试人员能定位设计错误，如逻辑错误。包括渗透测试。
动态分析（Dynamic analysis）
动态分析是及时的分析正在运行的程序， 一般是在静态分析之后，程序的基本问题都被解决完后执行。
环境分离，职责分离
验证 (verification)
确保满足了产品规范（specfication）
确认 (validation)
确保项目的主要目标得到满足
着重于如何使用和操作开发好的系统或应用程序
认证 (Certification)
对一个IT系统的技术和非技术安全特性以及其 防护措施安全评价，衡量特定设计和实施满足 一套规定的安全需求的程度，为认可过程提供支持。
一个检查和评估安全控制的过程
外部独立的检查机构执行
确认对安全策略和标准的合规
鉴定或认可 (Accreditation)
权威机构正式声明，某个IT系统已经得到批准，能 够运行于特定的安全模式，该安全模式采用了满足可接受风险等级的一套规定的安全措施
管理层对系统认可
对风险的明确接受
迁移和修正
此阶段，系统从验收阶段转换到真实生产环境。
此阶段活动包括获取安全认可 （security accreditation）；
根据计划培训用户；
实施系统，包括含安装和数据转换；
如有必要，执行并行操作。
运行/维护
正确配置安全环境
持续进行脆弱性测试，监控系统活动和审计事件 （在维护阶段发现发现了漏洞，采取的行动是报告）
如果发生重大变更执行风险评估， 并执行认证和鉴定过程（re-certification, re-accreditation）
处置 （disposal）
根据数据敏感程度，销毁数据。
销毁方法
物理破坏
消磁
覆写
SELC 系统工程生命周期 (Systems Engineering Life Cycle)
需求分析，设计，实施，验证，运营 Requirements analysis, Design, Implementation, Verification, Operation
变更和配置管理
能力成熟度模型 （CMM）
初始（Ad hoc）
可重复（Repeatable）
已定义（Defined 已定义）
已管理（Managed 已管理，衡量指标）
优化（Optimizing，持续改进）
能力成熟度模型集成 （CMMI）
1，3，5 相同，2.已管理，4.量化已管理
综合产品团队
Integrated Product and Process Development (IPPD)集成产品和流程开发
通过使用多科目团队同时集成所有必要获取活动来优化设计、制造和支持流程的管理技术
IPPD从产品概念到生产，包括现场支持，促进满足成本和绩效目标
IPPD的关键原则是集成产品团队（IPTs）的多学科协作模式
IPT
来自所有各职能科目的代表与Team Leader 一起工作来构建成功和平衡的程序，识别并解决问题，妥善并及时的决策
小组成员不一定贡献100%的时间在项目上，一个成员可以在多个IPT团队。
IPTs的目的是制定团队决策基于来自所有团队的实时输入（e.g.，项目管理、工程、制造、测试、逻辑、财务管理、采购和合同管理）也包括客户和供应商
ITPs的团队成员由项目经理级组成，包括来自企业和系统/子系统承包商的成员
典型IPT处于项目集级，例如，可能由以下功能学科组成：设计工程学、制造、系统的工程，测试和评估，分包、质量保证、培训、财务、可靠性、维修性、保障性、采购、合同管理、供应商和客户。
DevOps
从广义上讲，DevOps一种基于精益和敏捷原则的方法将业务属主和开发、运营和质量保证部门协作并以连续的方式交付软件，使业务能够更快地抓住市场机会和减少包括客户反馈的时间。 当全面实施时，DevOps可以变成业务驱动的软件交付方法，是一种能够从注意一直到产品线所采取新的或者加强的业务能力方法，以一种有效的方式向用户提供价值并在客户参与能力建设时捕获反馈。 为了做到这些，你不仅仅需要开发和运维团队的利益相关者参与。 真实的DevOps方法包括业务线、从业者、管理人员、合作伙伴和供应商等。
概念
原则
有许多企业都采用本地化的方式来实施DevOps框架，包括IBM、Amazon、Google、Mircrosoft。
对类似成产系统进行开发和测试
目的是允许开发和质量保障（QA）团队来对行为像生产系统样的系统进行开发和测试，这样他们能够知道应用在准备部属前如何行为以及如何良好执行。
以可重复、可靠流程进行部署
本原则允许开发和运维支持迭代的软件开发流程直到生产上线。 自动化对于产生可迭代、频繁、可重复以及可靠的流程至关重要，这样组织就可以建立允许持续性和自动化的部署以及测试管线。 频繁的部署允许团队自己测试部署流程，从而降低发布时部署失败的风险。
监控和验证运营质量
这个原则在生命周期早期开始监控，通过早起实施的自动化测试以及经常监控应用的功能和非功能特征来获取。 每当应用被部署和测试，质量指标应被获得和分析。 频繁监控可以提供关于生产环境中发生的运营和质量问题较早的告警。
扩大反馈回路
这个原则要求组织建立沟通渠道允许所有利益相关者可以访问并进行反馈。
软件开发模型
瀑布模型(waterfall)
制定计划、需求分析、软件设计、程序编写、软件测试、运行维护
螺旋模型
结构化编程开发
迭代开发
原型模型
抛弃
改进
快速原型法
探索模型
联合分析开发
快速应用开发(RAD)
重用模型
净室
组件型开发
敏捷开发
极限编程XP
Scrum
Lean
敏捷宣言4句话
个体和互动 高于 流程和工具 工作的软件 高于 详尽的文档 客户合作 高于 合同谈判 响应变化 高于 遵循计划
编程的语言和概念
结构化程序设计
自顶向下的分析设计； 自底向上的逐步实施
面向用户的观点，严格区分工作阶段
缺点：开发周期长、开发过程繁琐和复杂 审计比较较困难，用户交流不直观
面向对象程序设计
类 类（Class）定义了一件事物的抽象特点。通常来说，类定义了事物的属性和它可以做到的（它的行为）。举例来说，“狗”这个类会包含狗的一切基础特征，例如它的孕育、毛皮颜色和吠叫的能力。类可以为程序提供模版和结构。一个类的方法和属性被称为“成员”。 我们来看一段伪代码： 类 狗 开始 私有成员: 孕育: 毛皮颜色: 公有成员: 吠叫(): 结束 在这串代码中，我们声明了一个类，这个类具有一些狗的基本特征。关于公有成员和私有成员，请参见下面的继承性一节。 对象 对象（Object）是类的实例。例如，“狗”这个类列举狗的特点，从而使这个类定义了世界上所有的狗。而莱丝这个对象则是一条具体的狗，它的属性也是具体的。狗有皮毛颜色，而莱丝的皮毛颜色是棕白色的。因此，莱丝就是狗这个类的一个实例。一个具体对象属性的值被称作它的“状态”。（系统给对象分配内存空间，而不会给类分配内存空间，这很好理解，类是抽象的系统不可能给抽象的东西分配空间，对象是具体的） 假设我们已经在上面定义了狗这个类，我们就可以用这个类来定义对象： 定义莱丝是狗 莱丝.毛皮颜色:=棕白色 莱丝.吠叫() 我们无法让狗这个类去吠叫，但是我们可以让对象“莱丝”去吠叫，正如狗可以吠叫，但没有具体的狗就无法吠叫。 方法（秩序；条例） 方法（Method，可看成能力）是定义一个类可以做的，但不一定会去做的事。作为一条狗，莱丝是会叫的，因此“吠叫()”就是它的一个方法。与此同时，它可能还会有其它方法，例如“坐下()”，或者“吃()”。 对一个具体对象的方法进行调用并不影响其它对象，正如所有的狗都会叫，但是你让一条狗叫不代表所有的狗都叫。 如下例： 定义莱丝是狗 定义泰尔是狗 莱丝.吠叫() 则泰尔是会叫——但没有吠叫，因为这里的吠叫只是对对象“莱丝”进行的。 消息传递 一个对象通过接受消息、处理消息、传出消息或使用其他类的方法来实现一定功能，这叫做消息传递机制（Message Passing）。 继承 继承性（Inheritance）是指，在某种情况下，一个类会有“子类”。子类比原本的类（称为父类）要更加具体化，例如，“狗”这个类可能会有它的子类“牧羊犬”和“吉娃娃犬”。在这种情况下，“莱丝”可能就是牧羊犬的一个实例。子类会继承父类的属性和行为，并且也可包含它们自己的。我们假设“狗”这个类有一个方法叫做“吠叫()”和一个属性叫做“毛皮颜色”。它的子类（前例中的牧羊犬和吉娃娃犬）会继承这些成员。这意味着程序员只需要将相同的代码写一次。 在伪代码中我们可以这样写： 类牧羊犬:继承狗 定义莱丝是牧羊犬 莱丝.吠叫() /* 注意这里调用的是狗这个类的吠叫方法。 */ 回到前面的例子，“牧羊犬”这个类可以继承“毛皮颜色”这个属性，并指定其为棕白色。而“吉娃娃犬”则可以继承“吠叫()”这个方法，并指定它的音调高于平常。子类也可以加入新的成员，例如，“吉娃娃犬”这个类可以加入一个方法叫做“颤抖()”。设若用“牧羊犬”这个类定义了一个实例“莱丝”，那么莱丝就不会颤抖，因为这个方法是属于吉娃娃犬的，而非牧羊犬。事实上，我们可以把继承理解为“是”。例如，莱丝“是”牧羊犬，牧羊犬“是”狗。因此，莱丝既得到了牧羊犬的属性，又继承了狗的属性。 我们来看伪代码： 类吉娃娃犬:继承狗 开始 公有成员: 颤抖() 结束 类牧羊犬:继承狗 定义莱丝是牧羊犬 莱丝.颤抖() /* 错误：颤抖是吉娃娃犬的成员方法。 */ 当一个类从多个父类继承时，我们称之为“多重继承”。多重继承并不总是被支持的，因为它很难理解，又很难被好好使用。 封装性 具备封装性（Encapsulation）的面向对象程序设计隐藏了某一方法的具体执行步骤，取而代之的是通过消息传递机制传送消息给它。因此，举例来说，“狗”这个类有“吠叫()”的方法，这一方法定义了狗具体该通过什么方法吠叫。但是，莱丝的朋友蒂米并不需要知道它到底如何吠叫。 从实例来看： /* 一个面向过程的程序会这样写： */ 定义莱丝 莱丝.设置音调(5) 莱丝.吸气() 莱丝.吐气() /* 而当狗的吠叫被封装到类中，任何人都可以简单地使用： */ 定义莱丝是狗 莱丝.吠叫() 封装是通过限制只有特定类的实例可以访问这一特定类的成员，而它们通常利用接口实现消息的传入传出。举个例子，接口能确保幼犬这一特征只能被赋予狗这一类。通常来说，成员会依它们的访问权限被分为3种：公有成员、私有成员以及保护成员。有些语言更进一步：Java可以限制同一包内不同类的访问；C#和VB.NET保留了为类的成员聚集准备的关键字：internal（C#）和Friend（VB.NET）；Eiffel语言则可以让用户指定哪个类可以访问所有成员。 多态 多态（Polymorphism）是指由继承而产生的相关的不同的类，其对象对同一消息会做出不同的响应。[2]举例来说，狗和鸡都有“叫()”这一方法，但是调用狗的“叫()”，狗会吠叫；调用鸡的“叫()”，鸡则会啼叫。 我们将它体现在伪代码上： 类狗 开始 公有成员: 叫() 开始 吠叫() 结束 结束 类鸡 开始 公有成员: 叫() 开始 啼叫() 结束 结束 定义莱丝是狗 定义鲁斯特是鸡 莱丝.叫() 鲁斯特.叫() 这样，同样是叫，莱丝和鲁斯特做出的反应将大不相同。多态性的概念可以用在运算符重载上，本文不再赘述。 抽象性 抽象(Abstraction)是简化复杂的现实问题的途径，它可以为具体问题找到最恰当的类定义，并且可以在最恰当的继承级别解释问题。举例说明，莱丝在大多数时候都被当作一条狗，但是如果想要让它做牧羊犬做的事，你完全可以调用牧羊犬的方法。如果狗这个类还有动物的父类，那么你完全可以视莱丝为一个动物。
采用类和对象两部分组成
类 (Class)
类（Class）定义了一件事物的抽象特点
类定义了事物的属性和它可以做到的（它的行为）
一个类的方法和属性被称为“成员”
对象 (Object)
对象（Object）是类的实例。
系统给对象分配内存空间，而不会给类分配内存空间; 类是抽象的,系统不可能给抽象的东西分配空间，对象是具体的
对象=属性+方法
属性:
描述了对象的结构和状态特征
方法:
对象能够执行的功能或过程
对象间通信的方法：消息传递
多态性 (polymorphism)
封装最简单的理解就是包装，指隐藏对象的属性和实现细节， 仅仅对外公开接口，即对象的内部状态对外界是透明的。
封装性 (Encapsulation)
意味着将对象信息隐藏
公有成员
私有成员
继承 (inheritance)
是一种由已存在的类创建一个或多个子类型的机制.
软件体系结构
数据结构
对数据元素之间逻辑关系的表示
标量
链表
层次树
内聚和耦合 （高内聚，低耦合）
内聚
反应某个模块能够执行多少种不同类型的任务
内聚越高，就越容易对其进行更新和修改， 而不会影响到与其它交互的其他模块
耦合
一个模块执行任务时需要进行多少交互
低耦合更加容易重复使用，修改时也不会影响其他模块
分布式计算
通用对象请求代理体系结构 (CORBA)
微软COM/DCOM模型
EJB
API
API是IoT（Internet of Things）的连接器，允许设备互相连接
Representational State Transfer (REST) API
REST通过URL路径元素来解释系统的具体实体的； REST不是架构，但是构建Web顶层服务的架构类型； REST与机遇Web的系统通过简化URL进行通信而不是复杂的请求正文或者POST参数来请求系统特定项目； REST广泛应用；
REST 安全专家使用建议
当组织部署Web应用时为API使用同样的安全机制，如果你在WEB前端过滤XSS，同样API也要如此； 不要建立和实施你自己的安全方案，如使用经过同行审查和测试的框架或现有库； 除非API是免费，仅读公共API，不要使用单个基于密钥的认证，需要加上密码要求； 不要通过未加密的固态密钥； 理想情况下，使用HMAC（ hash-based message authentication code ）因为足够安全，使用SHA-2或者以上的。
REST API的三种安全路径
Basic Authentication w/TLS： 是三种最简单的一种方式，实施时不需要其他库； 使用该协议使用Base64 （64进制），绝对不要在没有TLS加密的方式使用； Oauth 1.0a： 三种协议中最安全的方式； 使用加密签名，HMAC-SHA1； 绝不通过有线传递令牌秘密； Oauth 2.0 ： Oauth2现有规格移除签名，不需要再使用加密算法来建立、生成和验证签名； 所有的加密由TLS来处理； 现在的库不想1.0那么多，所以使用是个挑战
典型的应用系统
Web安全
信息收集 （Information gathering）
管理界面 （Administrative interfaces）
鉴别和访问控制 （Authentication and access control）
输入验证 （Input validation）
路径/目录遍历（Path or directory traversal）：这个攻击又被成为“../”(dot dot slash),通过URL中插入几个“../”字符来回溯或遍历本不应该通过Web访问的目录； 统一代码编码（Unicode encoding）：Unicode是一种行业标准，开发他的目的是为了以标准的编码格式来表示世界上的10万多个文本字符。Web服务器支持Unicode以支持不同的字符，在Unicode下，攻击者不用“../”来攻击，而使用Unicode的“%c1%1c, %c0%9v, and %c0%af”，这个请求可能绕过输入验证而被执行； 网址编码（URL encoding）：是否曾发现在URL中的“空格”中展示“%20”，实际上“%20”代表空格，因为在URL中禁止使用空格。攻击者发现他们可以以不同的方式表示字符，可能会绕过过滤并提出请求。 缓冲区溢出（buffer overflow）：缓冲区溢出是指当计算机向缓冲区内填充数据位数时超过了缓冲区本身的容量，使得溢出的数据覆盖在合法数据上，理想的情况是程序检查数据长度并不允许输入超过缓冲区长度的字符，但是绝大多数程序都会假设数据长度总是与所分配的储存空间相匹配，这就为缓冲区溢出埋下隐患。操作系统所使用的缓冲区又被称为"堆栈"。在各个操作进程之间，指令会被临时储存在"堆栈"当中，"堆栈"也会出现缓冲区溢出。. 客户端验证（Client-side validation）：指将指令发送到服务器之前在客户端进行验证，如果客户端作为唯一验证，可能会被攻击者劫持，插入恶意数据。 SQL注入、XSS。
应对
缓存溢出攻击
XSS跨站脚本攻击
SQL注入攻击
参数验证 （Parameter validation）
会话管理 （Session management）
数据库管理
数据库管理系统 （DBMS）
管理和控制数据访问的程序集
以一定的格式组织并存储数据、 记录文件，允许用户存取、管理和更新
焦点：数据采集、存储、恢复
最关注完整性，其次是可用性，最后是保密性
元数据（metadata）
本质：有关数据的数据
有关数据源定义，目标定义，转换规则等相关的关键数据。
特点：
数据一致性
操作必须遵守每个数据库的完整性策略， 完成交易数据保持一致
数据共享
同一时刻可以有多个用户访问数据库， 借助并发控制
数据恢复
若发生错误或系统崩溃，系统可以恢复。 检查在崩溃时候正处理的交易或者回滚， 或者向前已完成一次交易，维护数据的一致性
检查点是一种常见的恢复技术
安全控制
提供各种安全控制，以限制用户访问
数据库语言
数据定义语言(DDL)， 例如：CREATE、DROP、ALTER等语句。
数据操作语言(DML)， 例如：SELECT（查询）、INSERT（插入）、 UPDATE（修改）、DELETE（删除）语句。
数据控制语言(DCL)， 例如：GRANT、REVOKE等语句。
事务控制语句（TCL）， 例如：COMMIT、ROLLBACK等语句。
确保有效途径或过程
压缩：研所数据并节省存储空间和I/O的能力
重组：回收不用的空间
重构：添加和改变记录、数据、访问控制、 磁盘配置、处理方法的能力
数据库模型
层次数据库模型
逻辑树结构，由在逻辑树结构中相关联的记录和字段组成
树形结构包含许多分支，每个分支又具有许多叶子或数据字段
访问需要明确路径， 不适合经常更改，适合于经常性查询
示例：轻量级目录访问协议LDAP、注册表结构
网状数据库模型
用有向图表示实体类型及实体间联系。 类似于网状的冗余结构，非严格树形结构
每个数据元素拥有多个父节点和子节点
与层次模型相比检索速度更快
关系数据库模型
特点：属性/字段（列）和元组/记录（行）
笛卡尔积的组合
主键和外键
主键能唯一标识一条记录
外键：如果一个表中的某个属性值与另一个表中的主键相匹配， 并且建立了某种关系，那么这个属性就视为外键
基本组件：
数据定义语言（DDL）
定义数据库的架构(Structure)和数据架构(Schema)
结构：说明表的大小、键的位置、视图和数据元素关系
架构：描述数据库存储和操作的数据类型及其属性
定义数据库的机构、访问操作和完整性过程
数据操作语言（DML）
用户操作命令
数据控制语言（DCL）
创建用户访问和授权对象
查询语言（QL）
对数据库提出查询请求
报表生成器
用户定义方式的数据过程输出
（RDBMS） 关系完整性
实体完整性 (Entity integrity)
每一条记录由主键值唯一确定
语义完整性 (Semantic integrity)
保证结构化规则和语义规则得到遵守， 防止语义上不正确的数据进入数据库。 可以通过规则约束的规则来实现
（参照)引用完整性 (Referential integrity)
任何数据库记录都不能引用一个不存在的主键， 如果一个包含有主键的记录被删除了， 所有被引用的记录都必须删除掉。（外键）
数据字典：
是一种描述数据元素及其关系的中心库， 可存储数据用法、数据关系、数据来源和数据格式等关键信息
数据字典是一个控制数据库数据的集中管理部分， 描述了数据元素和数据库间的交叉引用
描述数据元素定义、模式对象和引用键的集合
模式对象包括表、视图、索引、过程、函数和触发器
数据管理软件读取数据字典，确定模是否存在，并检查特定 用户进程的访问权限，还定义了对每个用户的视图权限设置
需要增加新记录、表、视图或模式时，更新数据字典
面向对象数据库模型
将面向对象编程中的对象数据模型与DBMS结合在一起， 可存储图像、语音、视频等数据。
面向对象的数据库使用类来定义其对象的属性和过程
对象-关系数据库模型
数据库编程接口
开放数据库互连，ODBC
对象连接和嵌入数据库，OLEDB
ActiveX数据对象，ADO
Java数据库互连，JDBC
数据库漏洞和威胁
完整性 (integrity)
回滚
终止当前事务，取消更改，恢复前一状态
提交
提交，终止当前事务，执行用户进行的修改， 如果不能执行成功则回滚
保存点/检查点 （check point）
如果检测到错误，用户可以返回相应的位置。
应对并发操作的威胁使用锁机制
聚合 (Aggregation)
一些信息片段分开时并不敏感，但放在一起就敏感。
解决方法
严格控制聚合函数的访问
禁止用户直接访问数据，可以通过视图方式
推理 （Inference）
聚合想要达到的结果
推理得不到显示可用的信息
解决方法：
访问控制
基于内容相关的访问控制
基于上下文相关的访问控制
单元抑制 (Cell suppression)
用于隐藏特定单元的技术
数据库分割 (database partition)
将数据库分成不同的部分
噪声和扰动 (noise and perturbation)
在数据库中插入伪造信息的技术
数据库视图
多实例 (MRDBMS)
建立具有相同主键的多个元组和 由安全级别定义的实例之间的关系
死锁 （DeadLocking）
其他威胁
数据库
联机事务处理，OLTP
ACID原则
原子性(Atomicity)
要么所有修改都提交，要么数据库回滚
一致性(Consistency)
遵循数据库完整性， 保证不同数据库中数据的一致性
隔离性(Isolation)
交易之间互不影响
持久性(Durability)
一旦提交无法进行回滚
联机分析处理，OLAP
OLAP是数据仓库系统的主要应用
适用于决策人员和高级管理人员
数据仓库和数据挖掘
为了实现信息检索和数据分析， 将多个数据库或数据源组合成一个大的数据库
数据挖掘
分类：根据共同的相似性对数据分组
可能性：标识数据之间的相互依赖关系， 并将可能性应用与他们之间的关系
专家系统
基于规则的编程
规则基于if-then逻辑单元
组成
推理机
推理机提供用户界面、外部文件、计划和程序访问能力
知识库
知识库包含特定问题或者领域相关的数据
专家系统通常被 IDS 用于自动审查安全日志
人工神经网络
基于人脑神经结构的电子模型
大脑以模式的形式存储信息
当学习到某个事物并经常使用时， 到信息存储单元的连接路径就会加强
神经网络被设定位拥有决策和学习能力， 通过大量的试探和错误决策过程改善其功能
威胁
缓冲区溢出 (Buffer Overflow)
隐蔽通道 Convert Channel
计时(timing)
存储(storage)
内存重用/对象重用 (Memory reuse/Object reuse )
社会工程学
Trapdoor/Backdoor （陷门／后门）
欺骗攻击 (spoofing attack)
web安全
故意破坏
用修改过的图片和标题替换核发图片和标题
认知及现实
金融欺诈
虚拟环境下的服务和交易的欺骗
特权访问
限制特权用户的访问
盗窃交易信息
盗窃知识产权
拒绝服务攻击
特定安全
信息收集
管理接口
身份验证与访问控制
配置管理
输入确认
参数确认
会话管理
SAML
SAML 安全断言语言（Security Assertion Markup Language）， 是一个基于XML的协议。 是一个联合身份标准。 用于在不同安全域传送身份验证和授权信息，可用于实现单点登录。 类似于Kerberos依赖于KDC，SAML依赖于IDP(Identity provider)。 SAML有一项功能叫策略执行（policy enforcement）。
OAuth2.0
在认证和授权的过程中涉及的三方包括： 1、服务提供方 ，用户使用服务提供方来存储受保护的资源，如照片，视频，联系人列表。 2、用户 ，存放在服务提供方的受保护的资源的拥有者。提供方 3、客户端 ，要访问服务提供方资源的第三方应用，通常是网站，如提供照片打印服务的网站。在认证过程之前，客户端要向服务提供者申请客户端标识。 使用OAuth进行认证和授权的过程如下所示: 用户想操作存放在服务提供方的资源。 用户登录客户端向服务提供方请求一个临时令牌。 服务提供方验证客户端的身份后，授予一个临时令牌。 客户端获得临时令牌后，将用户引导至服务提供方的授权页面请求用户授权。在这个过程中将临时令牌和客户端的回调连接发送给服务提供方。 用户在服务提供方的网页上输入用户名和密码，然后授权该客户端访问所请求的资源。 授权成功后，服务提供方引导用户返回客户端的网页。 客户端根据临时令牌从服务提供方那里获取访问令牌。 服务提供方根据临时令牌和用户的授权情况授予客户端访问令牌。 客户端使用获取的访问令牌访问存放在服务提供方上的受保护的资源。
OAuth（开放授权）是一个开放标准， 允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表）， 而无需将用户名和密码提供给第三方应用。
原先的OAuth，会发行一个 有效期非常长的token(典型的是一年有效期或者无有效期限制)，在OAuth 2.0中，server将发行一个短有效期的access token和长生命期的refresh token。这将允许客户端无需用户再次操作而获取一个新的access token，并且也限制了access token的有效期
移动代码
java applet
java语言由字节码构成，java虚拟机 将其转换成机器能够识别的机器码。
applet运行在沙箱 （沙箱有助于实现最小授权， 是应对恶意代码攻击的有效手段 替代防病毒软件）
ActiveX控件
恶意代码
病毒
特点：繁殖和破坏，需要宿主
宏病毒
引导区病毒
可以删除引导区的数据或重新引导区
压缩病毒
自身附加在可执行程序上，并使用用户的权限进行压缩
隐蔽性病毒
隐藏他对文件盒引导记录所做的修改
变形病毒
制作变化的，但仍然可用的自身副本
通过噪声或伪造指令，变异引擎和随机数 生成器来改变指令顺序，逃避检测
分体病毒
同时感染硬盘引导区和可执行文件
自乱病毒
通过打乱自身代码来逃避防病毒软件检测
脚本病毒
隧道病毒
将自己安装在防病毒程序下，杀毒软件 检测病毒时，七拦截这个调用
蠕虫
可以不需要宿主进行自我复制
通过邮件、web站点下载等方式传播
僵尸网络
僵尸程序是一种恶意软件，是一段潜伏 的代码
特洛伊木马
一种伪装成另外一个程序的程序
rootkit
逻辑炸弹
特定事件发生时，逻辑炸弹被执行
防病毒软件
特征性检测法 （signature）
启发式检测 （heuristic） 检测到异常行为
可疑性计数器
有的防病毒软件可疑创建一个沙盒， 动态分析可疑代码
分类：
审查一段代码有关的信息称为静态分析法
允许一部分代码在虚拟机中运行则称为动态分析法
免疫程序
针对某种病毒，使其认为已被感染。
行为阻止器
防病毒程序
通过行政、物理和技术方法来防止病毒
垃圾邮件检测
贝叶斯过滤
拒绝服务攻击 （DOS） （看上去是正常的活动）
特点
消耗受害者的网络带宽
消耗受害者的资源
分类
smurf攻击
利用ICMP协议的缺陷
fraggle攻击
利用UDP协议的缺陷
smurf和farggle是两种利用协议缺陷和 使用放大网络发动DoS的例子
SYN洪泛攻击
利用TCP连接的三次握手
超过了连接队列的上限
泪滴攻击
利用发送很小的分片包来利用这个设计缺陷
分布式拒绝服务攻击 （DDOS）
下水道（sinkhole）路由是应对DDOS的方法之一
评估软件安全的有效性
认证和认可
作用
通过最佳实务管理、操作的和技术的安全控制措施的应用将信息安全能力植入到联邦信息系统中
通过不断强化监控流程维持信息系统的安全状态意识
提供高层领导推进决策的重要信息，包括关于组织运维风险的接受，以及资产、个人、其他组织或国家由信息系统使用和运维所引起的风险；
变更的审计和日志
信息审计作用
审计程序辅助检测任何异常活动
审计级别和审计类型依赖于安装软件的审计要求以及系统处理或存储数据的敏感度
系统资源可用时应受到保护
日志审计的作用
日志提供清晰的视角表明谁拥有一个过程，启动了什么行动，什么时候启动，活动发生的地方，以及为什么进程运行。
建立基线的必要性
不同服务器和系统的绩效
应用的功能和运维问题
有效的入侵检测
取证分析
符合各种法律法规
信息的完整性
应用程序对比或协调所处理的与所期望处理的
对比总计
检查序列号
信息的准确度 (应用控制)
检查输入的精确性： 应在适当的应用程序中集成数据验证和校验检查
字符检查（Character checks）： 对比输入字符和期望字符类型，如数字或字母
范围检查（Range checks）： 验证输入数据对比预订的上限和下限
关系检查（Relationship checks）： 对比输入数据与主记录文件中的数据
合理性检查 （Reasonableness checks）： 对比输入数据与所期望的标准，其他形式的完整性检查
交易限制（Transaction limits）： 检查输入数据对比制定交易中管理设置限制
风险分析和缓解
风险管理
风险管理是持续的过程，跨越整个项目的生命周期
风险管理流程包括风险的策划、识别、分析、监控和控制
风险的识别开始于项目启动之前，并且风险的数量随着项目不断成熟逐渐增多
风险记录过程包括风险缓解和持续性计划
风险降低步骤能够降低事件发生的可能性，风险缓减会产生费用，需要进行成本效益分析；
持续性计划或者在事件发生之时或之前采取的一系列活动，计划可以是在风险发生之前先发制人活动或者是在风险发生之后活动
风险分析和降低策略
集成到SDLC流程以及组织的变更管理流程中
使用标准化的风险评估方法以及将风险报给给利益相关者
追踪和管理在评估、变更管理和持续性监控所发现的弱点
纠正性行为-补丁管理
软件常常在带有直到软件实施和运维后才发现的漏洞进行发布，需要更新补丁，可以采取以下措施 使用变更控制流程 阅读所有相关文档： 更新相关并将解决现有问题的书籍； 补丁的实施不再导致生产系统的其他的问题； 与更新有关的依赖关系，如一些功能禁掉或不禁掉会使得更新更加有效； 由更新序列导致的潜在问题 测试： 必须在部署生产环境之前在非生产环境中进行测试 有效备份并安排生产停机时间 长期保留回退（back-out）计划 预先告知服务台和关键用户组： 需要告知服务台员工以及支持人员关于变更暂停事宜以便他们准备面对变更引起的问题，也是 为减小用户的影响准备建议更新的关键用户组以助于管理用户期望 首先针对非关键服务， 如果在实验环境测试成功，开始部署在非关键服务器，如果可能，在部署到生产环境10-14天后迁移到主服务器 补丁管理中并不是所有的风险发现需要消减，必须做到： 风险发现的支持细节以及如何被发现的； 风险如何被确定以及任何关于威胁、脆弱性、可能性以及影响的补充信息； 修补费用的细节和需要买什么来减低以及如何影响威胁、脆弱性、可能性或影响的； 准备定义没有消减弱点的影响及其会发生的场景、故事和案例
基础设置
研究
MD5比较指纹和数字签名
文件完整性检查
评估和测试
测试环境中测试补丁
缓解（“回滚”）
部署（“首次展示”）
现在不太关键的系统上部署
确证、报告和日志记录
补丁更新日志，记录存档
测试和验证
实施风险控制措施需要进行测试
安全评估人员或其他独立实体验证和确认所需验证的漏洞
在大型组织
独立的验证和确认（independent verification and validation (IV&V)）团队来决定安全问题和漏洞是否被解决
开发和系统所有者不能在没有独立实体同意的情况下授权宣告风险已被消减
代码签名（Code signing）
代码签名（Code signing）被用于保证代码的完整性的技术，确定谁开发那段代码，并确定开发者打算将这段代码用于何处
代码签名证书和数字证书帮助用户免于下载泄密文件或应用程序
当代码被签名可以确定代码的可靠度并检测带是否被开发展之外的人所修改
代码签名用于
确保代码片段不被修改
识别代码来源（开发着或签名者）
确定代码是否值得为特定目标的信任
代码签名包含三个部分
印章、数字证书和唯一标示符
代码签名不能做的事情
不能保证代码片段免于安全漏洞
不能保证在执行过程中APP不会装载不安全或更改的代码（如不可行的插件）
不是数字版权管理（DRM）或拷贝保护技术
回归和接受测试 Regression and Acceptance Testing
By re-running testing scenarios that were originally scripted when known problems were first fixed, the developer or security professional can make sure that any new changes to an application have not resulted in a regression or caused components that formerly worked to fail. Adequate coverage without wasting time should be a primary consideration when conducting regression tests.
测试注意事项
迅速的测试Bug
观察修补的副作用
为每个Bug修补编写回归测试方案
如果两个或多个测试相似，确定哪个较为低效并舍弃
识别测试方案并持续的将其传递和归档
关注与功能问题而不是设计相关
确定数据的变更（无论大小）以及找到任何由此产生的破坏
追踪在程序内存上变更的影响
回归测试
最有效的方法是基于可以在新版本建立时每次都能运行的标准测试用例池所组成的测试库
建立测试库的难点在于确定包含什么样的测试用例
自动化测试和测试用例一样涉及到边界条件以及时机都属于测试库
为了自动化测试的有效性，作为复杂测试方法论的一部分，当集成足够的变量时是符合成本效益和效率
接受性测试 (验收测试)
执行的正式测试来确定系统是否满足其接受标准以及使得客户能确定是否接受该系统
在敏捷开发中，可接受性测试/标准通常由业务客户所建立以及业务领域的语言所描述
SwA（software assurance）的阶段 （确保开发或购置的软件达到安全要求 SAMM Software Assurance Maturity Model SAMM is a framework used to design software that is secure and tailored to an organization’s specific risks.）
“Software assurance is the level of confidence that software is free from vulnerabilities, either intentionally designed into the software or accidentally inserted at any time during its lifecycle, and that it functions in the intended manner 软件保障是软件免于漏洞的信心水平，在软件生命周期中既有有意设计成软件或在任何时间的意外插入，而它的功能按预期的方式
计划阶段
获取软件服务或产品所确定的需求，识别潜在替代软件的方法，识别替代的风险
开发需求被包含进工作说明书中
建立获取策略并包含识别与各种软件获取策略有关的风险
开发评价标准和评价计划
招标阶段
建立/发布具有工作说明、邀约人说明、条款和条件、资格预审以及认证的请求书或招标书（RFP），
评估供应商响应建议书（RFP）或者招标文件 (ITT) 所提交的方案
完成合同协商包含条款和条件的变更
监督和接受阶段
这个阶段主要是监控供应商工作以及接受合同所约定的最终服务或产品交付
建立并同意合同工作日程
实施变更控制程序
评审和接受软件交付
后续（follow-on）阶段
维持（包含风险管理、保障用例管理以及变更管理）
处置和下线
在后续阶段，软件风险必须通过持续保证用例分析管理并且被调整以降低风险
安全专家必须确保在企业中具有详实记录的SwA策略以及流程
意外错误导致错误的运维
故意插入恶意代码
盗窃重要或敏感的信息
盗窃个人信息
变更产品，插入代理或破坏信息