===================

      在过去的十几年里，随着信息技术的高速发展和企业信息化步伐的深入，企业在利用信息技术实现其商业目标的同时也变得越来越依赖于信息技术。以银行业为例，为了降低运营成本，提高用户满意度，今天的银行普遍利用信息技术支持的电话银行、ATM及网络银行系统为客户提供个性化、差异化的服务。另外，银行也在不断利用信息技术收集和分析大量的与客户有关的数据和信息，为新产品开发提供决策支持，从而达到提高盈利水平的目标。在今天的企业信息环境里，如何保证信息系统以及信息本身的安全性已然变得至关重要了。事实上，在今天具有一定规模的企业的IT环境里往往存在着少则几百个多则上千个大大小小的业务应用（Line of Business Applications），小到支持几个人的小规模团队的协同应用，大到贯穿于一个企业生产、经营、管理全过程的企业级应用。如何降低信息技术给企业带来的各种安全风险呢？无疑已成为当今所有企业面临的新挑战。

      企业信息安全的涵盖面非常广，涉及到人员、流程和技术等诸多方面的因素。正因为如此，一方面信息安全越来越受到广泛的关注，并且企业在信息安全方面的投入不断增加，而另一方面各种给企业造成负面影响的安全事件却层出不穷。单纯的技术手段往往无法帮助企业xxxx存在的诸多安全问题，只有建立起一整套安全策略和流程，通过合理地资源配置并且充分利用各种技术和非技术手段，企业才有可能更加有效地管理各类安全风险。

      信息安全包括安全体系的构建和管理、物理和环境安全、数据中心和网络安全、系统开发和维护安全等多方面内容。今天我们在这里讨论的话题将主要围绕安全系统开发，即企业在业务应用的开发过程中应该如何应对各种可能对应用造成影响的安全性问题。微软看来，保证和提高应用安全性的{zj0}时机是在应用的开发阶段。微软信息安全部门的ACE团队通过多年来在应用安全领域的实践经验，创建了一整套安全开发流程，即信息技术安全开发生命周期流程（Secure Development Lifecycle for Information Technology，缩写为SDL-IT）。该流程包含有一系列的{zj0}实践和工具，多年以来不仅被用于微软内部业务应用的开发过程中，而且也被成功地应用在许多微软客户的开发项目中。

      SDL-IT流程涵盖了软件开发生命周期的整个过程（如下图所示）。目的是通过在软件开发生命周期的每个阶段执行必要的安全控制或任务，保证应用安全{zj0}实践得以很好地应用。SDL-IT强调在业务应用的开发和部署过程中对应用安全给予充分的关注，通过预防、检测和监控措施相结合的方式，从而降低应用安全开发和维护的总成本。

      SDL-IT流程的{dy}步首先是对所要开发的应用进行安全风险评估。根据应用的风险和影响程度确定在整个软件开发生命周期过程中需要采取的安全控制。在对应用进行安全风险评估时需要考虑的因素包括应用本身，应用存储和处理的数据类型（比如是否涉及高业务影响数据或个人身份信息等）以及应用的部署环境（比如 Internet、Intranet或Extranet应用）等。评估通常是以问卷形式开展的，根据开发团队调查问卷的结果计算加权得分，确定应用的安全风险等级。微软的安全策略明确规定了不同安全风险等级的应用所需采取的安全控制（如下图所示）。

      接下来SDL-IT流��要求为应用建立安全威胁模型。安全威胁建模的目的是帮助应用开发团队在应用的设计阶段充分了解应用中存在的各种安全威胁并指导应用开发团队选择适当的应对措施。应对措施的建议可能涉及技术层面，比如如何改进应用的设计或者如何在代码编写过程中避免某些代码安全漏洞的出现等，也可能涉及流程和人员培训等方面。安全威胁建模的目的是对应用可能带来的风险进行管理。因此，在确定处理安全威胁的优先级和选择适当的应对措施时既要考虑安全威胁可能造成影响的大小，同时也要考虑安全威胁发生的可能性（如下图所示）。

      这里将大致介绍一下微软安全威胁建模的流程。首先是定义应用的安全目标和需要保护的信息资产。微软看来，一个安全威胁如果不能够被证明会对企业的信息资产造成损害，它就不构成一个真正的安全威胁。接下来需要了解应用的体系架构，包括子系统、信任边界和数据流，并且通过对应用体系架构的进一步细化，定义应用的角色、模块、数据和使用案例。在对应用的安全目标、体系架构、实现细节和技术应用有了清楚的了解以后，安全人员就可以帮助开发团队找出应用中可能存在的安全风险和漏洞，并且提出应对措施建议。同时，安全团队还会对所有的安全风险按照保密性、完整性和可用性（Confidentiality、 Integrity﹠Availability，缩写为CIA）进行归类，以便更好地帮助开发团队了解安全漏洞可能造成的影响。{zh1}，针对各种安全风险，开发团队综合考虑各方面因素确定是否接受、避免、降低或转移安全风险。

      如果使用微软安全威胁建模工具（），开发团队可以利用工具本身提供的报表功能生成面向应用开发以及测试人员的报告。开发团队可以利用报告中的有针对性的安全编程{zj0}实践和安全检查清单辅助进行安全开发和测试。从而实现从安全人员到应用开发人员的应用安全推动。此外，在应用的开发过程中，微软要求开发团队内部成员间应该进行代码安全审核。

      在应用投产前，微软要求由独立的安全团队对应用的安全性进行综合评估。主要内容包括对应用进行代码安全审核（即白盒安全测试）以及对应用的部署及环境进行安全审核。投产前安全审核的主要目的是检验在前面阶段定义的安全措施是否在应用的开发过程中被正确实施。安全人员会利用代码分析工具（Code Analysis Tool）结合对关键应用模块的源代码进行人工逐行扫描的方式，找出应用中存在的安全漏洞并提出应对措施建议。开发团队根据严重性级别对安全漏洞进行修复。应用部署及环境审核的目的则是降低应用的受攻击面，确保不会因为部署环境特别是服务器的安全性而影响到整个应用的安全性。

      在应用投产后对应用及其运行环境进行实时监控也是保障应用安全的必要措施。一方面应用本身及其部署环境可能会发生改变，使得以前的某些安全性方面的假设不再有效。另一方面，新的黑客攻击手段和方法也会不断地出现，也可能给应用带来新的安全威胁。此外，某些行业的企业可能还会有合规性管理（比如ISO、 PCI、SOX等）方面的需要，要求企业对其IT环境的技术标准遵从状况进行监控和管理。

      以上关于SDL-IT流程的描述主要是针对正在或将要开发的应用。那么如何利用SDL-IT，特别是在有限的资源和预算条件下，提高企业IT环境中已投产应用的安全性呢？微软建议企业应遵循SEE（Secure、Enhance﹠Empower）框架：

• Secure：对关键应用进行安全设计审核和代码安全审核
• Enhance：对全部应用进行风险分析和威胁建模
• Empower：帮助所有开发人员了解最常见安全漏洞的成因和修复方法

      在企业越来越注重xxxx的今天，SDL-IT的成本是企业最关注的问题。另外，如何处理好应用安全性和易用性的矛盾并实现两者之间的平衡也是企业需要面对的实际问题。SDL-IT会在一定程度和一定阶段增加应用开发的成本，但是却可以有效地帮助企业提高开发、部署和投产的应用的安全性和质量。通过对 SDLC前期的必要投入（比如安全威胁建模和设计审核等），SDL-IT可以有效地帮助企业降低在应用投产后发现和修复安全漏洞的成本以及可能带来的其它损失，比如生产力损失或者对企业声誉、法规遵从造成影响等。关于应用安全方面xxxx的讨论是一个复杂的话题，在这里就不做更深入地讨论了。需要强调的是：应用的安全性和其它需求一样，是应用的一部分。从前"寻找安全漏洞"的做法并不能真正保证应用的安全性。企业有必要改进软件开发流程，做到在应用开发的整个过程中自始至终地关注应用安全。{zh1}借用Bill Malick的一句话"Security is like the brakes on your car. Their function is to slow you down. But their purpose is to allow you to go fast."

===================

两种安全模型：

微软的安全软件开发模型：

1.安全开发生命周期（SDL）：



SDL总计为四步：
{dy}步：安全教育，通过教育才能提高安全意识。
         设计人员：学会分析威胁
         开发人员：跟踪代码中每字节数据、质疑所有关于数据的假设
         测试人员：关注数据的变化
第二步：设计阶段，利用威胁建模技术建立系统模型。
第三步：开发阶段，编码与测试并行。
第四步：发行与维护阶段，使用标准的修复机制修复安全缺陷。

2.威胁建模：

威胁模型是一种基于安全的分析，有助于人们确定给产品造成的{zgj}别的安全风险，以及攻击是如何表现出来的。
其目标是确定需要缓和哪些威胁，如何来缓和这些威胁。

主要分为四个步骤：

{dy}步：分解应用程序。使用DFD（数据流图）或者UML（统一建模语言）描述威胁模型，作为分析应用程序的重要组成部分。对应用程序进行形式化分解，自顶向下，逐层细化，在分解过程中关注过程之间的数据流。
例如：

第二步：确定系统面临的威胁。按照“STRIDE”威胁模型：
         S：身份欺骗(Spoofing identity)，造成冒充合法用户、服务器欺骗(DNS 欺骗，DNS缓存中毒)。
         T：篡改数据(Tampering with data)。
         R：否认(Repudiation)、。
         I：信息泄露(Information disclosure)。
         D：拒绝服务(Denial of service, DOS)。
         E：特权提升(Elevation of privilege)。

第三步：威胁评估。按照“DREAD”算法为威胁分级，并建立攻击树：
         D：潜在的破坏性(damage potential)
         R：再现性(reproducibility)
         E：可利用性(exploitability)
         A：受影响的用户(affected users)
         D：可发现性(discoverability)
         例如：
         Threat #1: 恶意用户浏览网络上的秘密工资数据
         潜在的破坏性: 读取他人的私密工资并不是开玩笑的事。——风险值为8
         再现性:{bfb}可再现。——风险值为10
         可利用性: 必须处于同一子网或者处于同一路由器下。——风险值为7
         受影响的用户: 每个人都将受到影响。——风险值为10
         可发现性: 让我们假设它已经发生。——风险值为10
         计算风险DREAD: (8+10+7+10+10) / 5 = 9

         攻击树描述了攻击者利用系统漏洞破坏各组件，对威胁目标进行攻击所经历的决策过程。建立攻击树需要考虑的几个方面：
         安全威胁：潜在的事件，当攻击有动机并付诸实施时，威胁转变为攻击事件。
         安全漏洞：系统中的弱点。
         资源：受威胁(或攻击)的目标。
        
         例如：
         对Threat #1的威胁描述表格：


         Threat #1的攻击树：

        
第四步：建立缓和方案，选择适当的安全技术。



接触点开发模型:



根据有效性排列的接触点:
代码审查（Code review）
架构风险分析（Architectural risk analysis ）
渗透测试（Penetration testing ）
基于风险的安全测试（Risk-based security tests ）
滥用用例（Abuse cases ）
安全需求（Security requirements ）
安全操作（Security operations ）

1.代码审查

代码审查的目标是找到bug，架构风险分析的目标是找到缺陷。在很多情况下，这两个主要的接触点的执行顺序能够交换。

静态分析工具：
静态分析工具在代码中查找固定的模式或规则集合。
静态分析工具的输出仍然需要人为判断。
错报（false negatives）问题，程序中含有bug但工具没有报告。
误报(false positives)问题，工具报出的bugs程序中不存在。

动态分析工具：
执行程序、错误注入。

二进制分析：
反汇编和反编译都是攻击者最常用的黑客工具。
例如：Fortify Source Code Analysis Suite


2.架构风险分析

架构风险分析的主要活动是从适当的高度建立一个目标系统的视图，避免“只见树林不见森林”，提倡一页纸的总览, “forest-level”视图。
例如：


在forest-level视图中主要分析以下几个方面：
威胁（谁可能攻击系统）、每一层环境中的风险、每个组件和数据流中可能存在的漏洞、技术风险可能造成的商业破坏、风险被实现的可能性、任何在每一层能够实现的可行对策、考虑整个系统范围内的可用保护机制。

3.渗透测试

渗透测试，针对系统威胁尝试对系统进行渗透，包括：积极（正向）测试，验证软件正常执行了规定的任务；消极（负向）测试，安全测试人员必须深入研究安全风险（可能由滥用用例和体系风险驱动）以便确定系统在攻击之下如何反应。

测试工具：
错误注入工具。
其他工具:Fortify Software, CANVAS。
攻击者的工具包。

4.基于风险的安全测试

此测试旨在揭示可能的软件风险和潜在攻击。

实施人员：
使用传统方式的标准测试组织可以执行功能安全测试；
基于风险的安全测试更依赖于专门技术和经验，而不是测试经验和安全经验；
教会测试专业人员学会在测试时如何象一个攻击者一样思考。

实施方式：
有源码：白盒测试，静态分析－－发现程序中的错误；
根据基于对软件体系深入的理解而进行的风险分析的结论，进行白盒测试；
无源码：黑盒测试，运行程序－－恶意输入。

5.滥用用例

滥用用例指软件开发人员需要在正常特性之外思考软件系统的固有特性，如可靠性、安全和性能。

实施方式：
对系统的异常行为必须事先有所预期；
象攻击者一样思考你的系统，利用“反需求”尝试出错点。
例如：你的系统有一个使用加密保护通过序列化将关键数据写到磁盘上的安全需求，与这个需求对应的反需求就是要确定当缺少加密的时候会发什么情况。

6.安全需求

设计系统的安全需求。

7.安全操作

注重配置管理的安全性，由于配置的改变是必然的，因此我们在开发和维护过程中需要控制配置的改变，建立开发活动（程序、数据、文档）的快照，验证配置的任何修改，防止恶意修改配置。

常用工具：
Rational ClearCase，MS Visual SourceSafe等。