应用平安评估方式.docx

应用平安评估方式.docx

《应用平安评估方式.docx》由会员分享，可在线阅读，更多相关《应用平安评估方式.docx（16页珍藏版）》请在冰豆网上搜索。

应用平安评估方式

1.1.1应用平安评估

应用评估概述

针对企业关键应用的平安性进行的评估，分析XXX应用程序体系结构、设计思想和功能模块，从中发觉可能的平安隐患。

全面的了解应用系统在网络上的“表现”，将有助于对应用系统的保护与支持工作。

了解XXX应用系统的现状，发觉存在的弱点和风险，作为后期改造的需求。

本期项目针对XXX具有代表性的不超过10个关键应用进行平安评估。

在进行应用评估的时候，引入了要挟建模的方式，这一方式是一种基于平安的分析，有助于咱们确信应用系统造成的平安风险，和解决是如何表现出来的。

输入：

关于要挟建模，下面的输入超级有效：

用例和利用方案

数据流

数据架构

部署关系图

尽管这些都超级有效，但它们都不是必需的。

可是，必然要了解应用程序的要紧功能和体系结构。

输出：

要挟建模活动的输出结果是一个要挟模型。

要挟模型捕捉的要紧项目包括：

要挟列表

漏洞列表

应用评估步骤

五个要紧的要挟建模步骤如图1所示。

图1

咱们把应用系统的平安评估划分为以下五个步骤：

识别应用系统的平安目标：

其中包括系统业务目标和平安目标。

目标清楚有助于将注意力集中在要挟建模活动，和确信后续步骤要做多少工作。

11

了解应用系统概况：

逐条列出应用程序的重要特点和参与者有助于在步骤4中确信相关要挟。

应用系统分解：

全面了解应用程序的结构能够更轻松地发觉更相关、更具体的要挟。

应用系统的要挟识别：

利用步骤2和3中的详细信息来确信与您的应用程序方案和上下文相关的要挟。

应用系统的弱点分析：

查应用程序的各层以确信与要挟有关的弱点。

步骤1：

识别平安目标

业务目标是应用系统利用的相关目标和约束。

平安目标是与数据及应用程序的保密性、完整性和可用性相关的目标和约束。

以约束的观点来考虑平安目标利用平安目标来指导要挟建模活动。

请考虑那个问题，“您不希望发生什么？

”例如，确保解决者无法窃取用户凭据。

通过确信要紧的平安目标，能够决定将要紧精力放在什么地址。

确信目标也有助于明白得潜在解决者的目标，并将注意力集中于那些需要紧密留意的应用程序区域。

例如，若是将客户帐户的详细信息确信为需要爱惜的灵敏数据，那么您能够检查数据存储的平安性，和如何操纵和审查对数据的访问。

业务目标：

一个应用系统的业务目标应该从如下几个方面入手进行分析：

信誉：

应用系统发生异样情形和受到解决造成的商业信誉的损失；

经济：

关于应用系统，若是发生解决或其它平安时刻造成的直接和潜在的经济损失。

隐私：

应用系统需要爱惜的用户数据。

国家的法律或政策：

例如：

品级化爱惜要求、SOX法案等。

公司的规章制度。

国际标准：

例如：

ISO1779九、ISO13335等。

法律协议。

公司的信息平安策略。

平安目标：

一个应用系统的平安目标应该从如下几个方面入手进行分析：

系统的机密性：

明确需要爱惜哪些客户端数据。

应用系统是不是能够爱惜用户的识别信息不被滥用？

例如：

用户的信息被盗取用于其它非法用途；

系统的完整性：

明确应用系统是不是要求确保数据信息的有效性。

系统的可用性：

明确有特殊的效劳质量要求。

应用系统得可用性应该达到什么级别（例如：

中断的时刻不能超过10分钟/年）？

依照系统靠得住性的要求，能够重点爱惜重点的应用系统，从而节约投资。

通过访谈的方式确信应用系统业务目标和平安目标，对业务目标和平安目标进行细化，取得应用系统平安要求。

输入：

访谈备忘录

输出：

应用系统业务目标、平安目标和平安要求。

资料来源：

分类

序号

目标

安全要求

备注

业务目标

1

2

3

安全目标

1

2

3

4

步骤2：

应用系统概述

在本步骤中，概述应用系统的行为。

确信应用程序的要紧功能、特性和客户端。

创建应用系统概述步骤：

画出端对端的部署方案。

确信角色。

确信要紧利用方案。

确信技术。

确信应用程序的平安机制。

下面几部份将对此一一进行说明：

画出端对端的部署方案：

画出一个描述应用程序的组成和结构、它的子系统和部署特点的粗略图。

随着对身份验证、授权和通信机制的发觉来添加相关细节。

部署关系图通常应当包括以下元素：

端对端的部署拓扑：

显示效劳器的布局，并指示Intranet、Extranet或Internet访问。

从逻辑网络拓扑入手，然后在把握详细信息时对其进行细化，以显示物理拓扑。

依照所选的特定物理拓扑来添加或删除要挟。

逻辑层:

显示表示层、业务层和数据访问层的位置。

明白物理效劳器的边界后，对此进行细化以将它们包括在内。

要紧组件:

显示每一个逻辑层中的重要组件。

明确实际流程和组件边界后，对此进行细化以将它们包括在内。

要紧效劳:

确信重要的效劳。

通信端口和协议。

显示哪些效劳器、组件和效劳彼此进行通信，和它们如何进行通信。

了解入站和出站信息包的细节后，显示它们。

标识：

若是您有这些信息，那么显示用于应用程序和所有相关效劳帐户的要紧标识。

外部依托项：

显示应用程序在外部系统上的依托项。

在稍后的建模进程中，这会帮忙您确信由于您所作的有关外部系统的假设是错误的、或由于外部系统发生任何更改而产生的漏洞。

随着设计的进行，您应当按期复查要挟模型以添加更多细节。

例如，最初您可能不了解所有的组件。

应依照需要细分应用程序，以取得足够的细节来确信要挟。

确信角色：

确信应用程序的角色：

即，确信应用程序中由谁来完成哪些工作。

用户能做什么？

您有什么样的高特权用户组？

例如，谁能够读取数据、谁能够更新数据、谁能够删除数据？

利用角色标识来确信应当发生什么和不该当发生什么。

确信要紧的利用方案：

确信的应用程序的要紧功能是什么？

它能够做什么？

利用应用程序的用例来取得这些信息。

确信应用程序的要紧功能和用法，并捕捉Create、Read、Update和Delete等方面。

常常在用例的上下文中说明要紧功能。

能够帮忙明白得应用程序应当如何利用，和如何是误用。

用例有助于确信数据流，并能够在稍后的建模进程中确信要挟时提供核心。

在这些用例中，您能够考察误用业务规那么的可能性。

例如，考虑某个用户试图更改另一个用户的个人详细资料。

您通常需要考虑为进行完整的分析而同时发生的几个用例。

确信技术:

只要您能确信，就列出软件的技术和要紧功能，和您利用的技术。

确信以下各项：

操作系统。

效劳器软件。

数据库效劳器软件。

在表示层、业务层和数据访问层中利用的技术。

开发语言。

确信技术有助于在稍后的要挟建模活动中将要紧精力放在特定于技术的要挟上，有助于确信正确的和最适当的减缓技术。

步骤3：

系统分解

通过度解应用程序来确信信任边界、数据流、入口点和出口点。

对应用程序结构了解得越多，就越容易发觉要挟和漏洞。

分解应用程序按如下步骤：

确信信任边界。

确信数据流。

确信入口点。

确信出口点。

下面几部份将对此一一进行说明。

确信信任边界：

确信应用程序的信任边界有助于将分析集中在所关注的区域。

信任边界指示在什么地址更改信任级别。

能够从机密性和完整性的角度来考虑信任。

例如，在需要特定的角色或特权级别才能访问资源或操作的应用程序中，更改访问操纵级别确实是更改信任级别。

另一个例子是应用程序的入口点，您可能可不能完全信任传递到入口点的数据。

如何确信信任边界：

1.从确信外部系统边界入手。

例如，应用程序能够写效劳器X上的文件，能够挪用效劳器Y上的数据库，而且能够挪用Web效劳Z。

这就概念了系统边界。

2.确信访问操纵点或需要附加的特权或角色成员资格才能访问的关键地址。

例如，某个特殊页可能只限于治理人员利用。

该页要求通过身份验证的访问，还要求挪用方是某个特定角色的成员。

3.从数据流的角度确信信任边界。

关于每一个子系统，考虑是不是信任上游数据流或用户输入，若是不信任，那么考虑如何对数据流和输入进行身份验证和授权。

了解信任边界之间存在哪些入口点能够使您将要挟识别集中在这些关键入口点上。

例如，可能需要在信任边界处对通过入口点的数据执行更多的验证。

确信数据流：

从入口到出口，跟踪应用程序的数据输入通过应用程序。

如此做能够了解应用程序如何与外部系统和客户端进行交互，和内部组件之间如何交互。

要专门注意跨信任边界的数据流，和如安在信任边界的入口点验证这些数据。

还要紧密注意灵敏数据项，和这些数据如何流过系统、它们通过网络传递到何处和在什么地址保留。

一种较好的方式是从最高级别入手，然后通过度析各个子系统之间的数据流来解构应用程序。

例如，从分析应用程序、中间层效劳器和数据库效劳器之间的数据流开始。

然后，考虑组件到组件的数据流。

确信入口点：

应用程序的入口点也是解决的入口点。

入口点能够包括侦听前端应用程序。

这种入口点本来确实是向客户端公布的。

存在的其他入口点（例如，由跨应用程序层的子组件公布的内部入口点）。

考虑访问入口点所需的信任级别，和由入口点公布的功能类型。

确信出口点：

确信应用程序向客户端或外部系统发送数据的点。

设置出口点的优先级，应用程序能够在这些出口点上写数据，包括客户端输入或来自不受信任的源（例如，共享数据库）的数据。

步骤4：

要挟识别

在本步骤中，确信可能阻碍应用程序和危及平安目标的要挟和解决。

这些要挟可能会对应用程序有不良阻碍。

能够利用两种大体方式：

1.从常见的要挟和解决入手。

利用这种方式，您能够从一系列按应用程序漏洞类别分组的常见要挟入手。

接下来，将要挟列表应用到您自己的应用程序体系结构中。

2.利用问题驱动的方式。

问题驱动的方式确信相关的要挟和解决。

STRIDE类别包括各类类型的要挟，例如，欺骗、窜改、否定、信息泄漏和拒绝访问。

利用STRIDE

模型来提出与应用程序的体系结构和设计的方方面面有关的问题。

这是一种基于目标的方式，您要考虑的是解决者的目标。

例如，解决者能够以一个虚假身份来访问您的效劳器或Web应用程序吗？

他人能够在网络或数据存储中窜改数据吗？

当您报告错误消息或记录事件时会泄漏灵敏信息吗？

他人能拒绝效劳吗？

确信要挟时，要逐级、逐层、逐功能地进行检查。

通过关注漏洞类别，将注意力集中在那些最常发生平安错误的区域。

在本步骤中，您要完成以下任务：

确信常见的要挟和解决。

依照用例来确信要挟。

依照数据流来确信要挟。

利用要挟/解决树研究其他要挟.

下面几部份将对此一一进行说明。

确信常见的要挟和解决：

许多常见的要挟和解决依托于常见的漏洞，依照应用程序平安框架确信要挟、依照用例确信要挟、依照数据流确信要挟和利用要挟/解决树研究其他要挟。

应用程序平安框架

下面的漏洞类别是由平安专家对应用程序中数量最多的平安问题进行调查和分析后提掏出来的。

本部份为每一个类别都确信了一组要紧问题。

1.身份验证

通过提出以下问题，对身份验证进行检查：

解决者如何欺骗身份？

解决者如何访问凭据存储？

解决者如何发动字典解决？

您的用户凭据是如何存储的和执行的密码策略是什么？

解决者如何更改、截取或回避用户的凭据重置机制？

2.授权

通过提出以下问题，对授权进行检查：

解决者如何阻碍授权检查来进行特权操作？

解决者如何提升特权？

3.输入和数据验证

通过提出以下问题，对输入和数据验证进行检查：

解决者如何注入SQL命令？

解决者如何进行跨站点脚本解决？

解决者如何回避输入验证？

解决者如何发送无效的输入来阻碍效劳器上的平安逻辑？

解决者如何发送异样输入来使应用程序崩溃？

1.配置治理

通过提出以下问题，对配置治理进行检查：

解决者如何利用治