第15章 安全评估与测试

15.1构建安全评估和测试方案

安全评估和测试方案(Program)是信息安全团队的基础维护活动。

该方案包括测试、评估和审计，定期验证组织是否已采取足够的安全控制，及这些安全控制是否正常运行并有效地保护信息产。

安全评估方案的三个主要组成部分：

•安全测试

•安全评估

•安全审计

15.1.1安全测试

安全测试是验证某项控制措施是否正常运行。

这些测试包括自动化扫描、工具辅助的渗透测试、试图破坏安全的手动测试。

安全测试应该定期执行，安全控制措施为组织保驾护航。

在安排安全控制措施审查时，信息安全管理者(information security manager)应考虑以下因素：

•安全测试资源的可用性

•待测控制措施所保护系统及应用程序的重要性(Criticality)

•待测系统及应用程序所含信息的敏感性

•执行控制措施的机制出现技术故障的可能性

•关乎安全的控制措施出现错误配置的可能性

•系统可能遭受攻击的风险

•控制措施配置变更的频率

•技术环境下可能影响控制措施性能的其他变更

•执行控制措施测试的难度及时间

•测试对正常业务操作造成的影响

15.1.2安全评估

安全评估是对系统、应用程序或其他待测环境的安全性进行全面审查。

在安全评估期间，经过训练的信息安全专业人员执行风险评估，识别出可能造成危害的安全漏洞，并根据需要提出修复建议。

安全评估通常包括安全测试工具的使用，但不限于自动化扫描和手工渗透测试。

它们还包括对威胁环境、当前和未来风险、目标环境价值的细致审查。

安全评估的主要工作成果通常是向管理层提交的评估报告。

报告包括以非技术语言描述的评估结果，并通常以提高待测环境安全性的具体建议作为结尾。

评估可以由内部团队执行，也可以外包到在待评估领域具备经验的第三方评估团队进行。

根据NIST 800-53A，评估包括4个组成部分：

•规范(Specification) 是与待审计系统有关的文档。规范通常包括政策、规程、要求、详细及设计。

•机制 是信息系统中用于满足规范的控制措施。机制可以基于硬件、软件或固件。

•活动 是在信息系统中人员所采取的行动。这些行动可能包括执行备份，导出日志文件或审查账户历史记录。

•人员 是指执行规范、机制及活动的人员。

在进行评估时，评估人员可检查此处列出的四个组件中的任意一个。

他们也可以采访个体并进行直接测试来确定控制措施的有效性。

15.1.3安全审计

安全评估期间，安全审计虽然遵循许多相同技术，但必须由独立审核员执行。

尽管组织安全人员可能会定期执行安全测试和评估，但这不是安全审计。

评估和测试结果仅供内部使用，旨在评估控制措施，着眼于发现潜在的改进空间。

另一方面，审计是为了向第三方证明控制措施有效性而进行的评估。

在评估这些控制措施有效性时，为组织设计、实施和监控控制措施的员工存在内在的利益冲突。

审计员(Auditor)为组织的安全控制状态提供一种客观中立的视角。

他们撰写的报告与安全评估报告非常相似，但适用于不同的受众，可能包括组织的董事会、政府监管机构和其他第三方。

审核有三种主要类型：内部审计、外部审计和第三方审计。

1．内部审计

内部审计是由组织内部审计人员执行，通常适用于组织内部。

内部审计人员在执行审计时，通常完全独立于所评估的职能。

在许多组织中，审计负责人直接向类似总裁、首席执行官汇报。

审计负责人也可直接向组织的董事会报告。

2.外部审计

外部审计通常由外部审计公司执行。

因为执行评估的审计员与组织并没有利益冲突，所以外部审计具有很高的公信力。

最为人们所认可的四大审计公司：

•安永(Ernst & Young)

•德勤(Deloitte & Touche)

•普华永道(PricewaterhouseCoopers)

•毕马威(KPMG)

多数投资者和理事机构成员通常认可这些公司的审计结果。

3.第三方审计

第三方审计是由另一个组织，或以另一个组织的名义进行的审计。

比如，监管机构可依据合同或法律对被监管公司进行审计。

在第三方审计的情况下，执行审计的组织通常会选择审核员和设计审计范围。

向其他组织提供服务的组织通常要求进行第三方审计。

如果被审计的组织拥有大量客户，第三方审计会成为不小的负担。

美国注册会计师协会(American Institute of Certified Public Accountants, AICPA)发布一个减轻这类负担的标准。

第16号认证业务标准声明(The Statement on Standards for Attestation Engagements document 16, SSAE16)提供一个通用标准，

审计员采用该标准来对服务组织进行评估，目的是让组织只需要进行一次第三方评估，

而不需要开展多次第三方评估，然后与用户及潜在用户共享最终评估报告。

SSAE16评估活动产生两种不同类型的报告。

•I类报告

I类报告描述了被审计组织提供的控制措施，以及审计员基于该描述所形成的意见。

I类报告适用于某个时间点，不会涉及审计员对控制措施的实际测试。

•II类报告

II类报告至少覆盖6个月的时间，还包括审计员根据实际测试结果对这些控制措施的有效性所形成的意见。

人们通常认为II类报告比I类型报告更可靠，因为II类报告包括对控制措施的独立测试。

类型I报告只是让服务组织自圆其说，控制措施已按照描述实现。

信息安全专业人员经常被要求参与内部、外部和第三方审计。

他们通常必须以访谈和书面文档的方式，向审计员提供有关安全控制措施的信息。

审计员还可要求安全人员参与控制评估的过程。

审计员通常可全权访问组织内的所有信息，而安全人员应服从审计员的请求，如果需要可请示管理层。

4.审计标准

在进行审计或评估时，审计团队应该明确评估组织所采用的标准。

标准描述了需要满足的控制目标，审计或评估的目的就是确保组织正确实施控制措施来实现这些目标。

信息和相关技术控制目标(Control Objectives for Information and related Technology, COBIT)是一个开展审计和评估的通用框架。

COBIT描述了组织围绕其信息系统所应具备的通用要求。

国际标准化组织(ISO)还发布了一套与信息安全相关的标准。

ISO27001描述了建立信息安全管理系统的标准方法。

ISO27002详细介绍了信息安全控制的细节。

这些国际公认的标准在安全领域得到了广泛使用，组织可以选择获得符合ISO27001标准的官方认证。

15.2开展漏洞评估

15.2.1漏洞描述

•安全内容自动化协议(Security Content Automation Protocol, SCAP)：

SCAP是NIST为安全社区提供的漏洞描述和评估通用标准，促进不同安全系统之间交互的自动化。

SCAP组件包括：

•通用漏洞披露(Common Vulnerabilities and Exposures, CVE)：提供一个描述安全漏洞的命名系统。

•通用漏洞评分系统(Common Vulnerability Scoring System, CVSS)：提供一个描述安全漏洞严重性的标准化评分系统。

•通用配置枚举(Common Configuration Enumeration, CCE)：提供一个系统配置问题的命名系统。

•通用平台枚举(Common Platform Enumeration, CPE)：提供一个操作系统、应用程序及设备的命名系统。

•可扩展配置检查表描述格式(Extensible Configuration Checklist Description Format，XCCDF)：提供一种描述安全检查表的语言。

•开放漏洞评估语言(Open Vulnerability and Assessment Language, OVAL)：提供一种描述安全测试过程的语言。

15.2.2漏洞扫描

漏洞扫描可自动探测系统、应用程序及网络，探测可能被攻击者利用的漏洞。

漏洞扫描工具可提供快速点击式测试，不需要人工干预即可执行繁杂的测试任务。

漏洞扫描主要分为4类：

网络发现扫描、网络漏洞扫描、Web应用漏涧扫描及数据库漏洞扫描。

1．网络发现扫描

网络发现扫描运用多种技术来扫描一段IP地址，探测存在开放网络端口的系统。

网络扫描实际上并不探测系统漏洞，而是提供扫描报告，

指出网络上探测到的系统、通过网络暴码出来的端口列表、位于扫描器和被测系统网络之间的服务器防火墙。

常见的扫描技术：

•TCP SYN扫描（也称为半开放(half-open)扫描）：

向目标系统的每个端口发送一个设置SYN标志位的数据包。

这个数据包表示请求创建一个新TCP连接。

如果扫描器接收到设置SYN和ACK标志位的响应数据包，

这种情况表明目标系统已经进入TCP三次握手的第二阶段，也说明这个端口是开放的。

•TCP Connect扫描：

向远程系统的某个端口创建全连接。

这种扫描类型适用于执行扫描的用户没有运行半开放扫描所需权限的情况。

大多数其他类型的扫描需要发送原生数据包的能力，扫描用户可能受到操作系统限制，无法发送构造的原生数据包。

•TCPACK扫描：

发送设置ACK标志位的数据包，表明它属于某个开放连接。

这种扫描可以尝试确定防火墙规则或防火墙方法。

•Xmas扫描：发送设置FIN、PSH及URG标志位的数据包。

因为，设置如此多标志位的数据包据说像“圣诞树一样亮起来“，故此得名。

NMAP：网络发现扫描最常用的工具(开源)。

在扫描系统时，nmap会识别出系统上所有网络端口的当前状态。

针对nmap扫描端口的结果，namp可以提供该端口的目前状态：

开放：该端口在远程系统上已经开放，同时在该端口上运行应用程序，主要接受连接请求。

关闭：该端口在远程系统可以访问，意味着防火墙允许访问该端口，但是在该端口上没有运行接受连接请求的应用程序。

过滤：因为防火墙会干扰连接尝试，nmap无法确定该端口是开放还是关闭。

用户在Linux终端输入如下命令：

nmap -vv 52.4.85.159

nmap软件开始对IP为52.4.85.159的系统进行端口扫描。

-vv参数：启用详细模式，详细输出扫描结果。

扫描结果显示nmap在该系统上扫描到3个活动端口：22、80和443。

22和80端口是开放状态，表示该系统可在这些端口上接受连接请求。

443端口处于关闭状态，表示防火墙已经允许在443端口接受连接，但该系统并未运行接受这些连接请求的应用程序。

我们大致浏览一下nmap扫描的结果：

•端口列表的首行：22/tcp open ssh,表示该系统可在TCP22端口上接受连接请求。SSH服务使用22端口对服务器进行运维。

•端口列表的第二行：80/tcp open http,表示该系统在TCP80端口上接受连接请求，此端口通常运行超文本传输协议(Hypertext Transfer Protocol, HTTP)，发布网页。

•端口列表的最后一行：443/tcp closed https,表示防火墙规则允许访问443端口，但没有服务在443端口上进行监听。443端口通常运行HTTPS，接收加密的Web服务连接。

从这些结果，我们可了解到什么？

被扫描的系统可能是一台Web服务器，正大方地接收来自扫描器的连接请求。

介于扫描器和该系统之间的防火墙配置成允许安全(443端口）和不安全(80端口）的连接，但是该系统未设置加密传输服务。

该系统也开启管理端口，允许命令行的连接。

读取这些信息后，攻击者可对目标系统进行一些观察，以便进一步探测：

•使用Web浏览器访问该服务器，可能了解到服务器用途及运营者。

在浏览器的地址栏上简单输入http://52.4.85.159,便可索引到有用信息。

图15.2显示执行此操作的结果：站点正在运行Apache Web服务器默认安装界面。

•访问到该服务器的连接是未加密的。如果可能，监听这些连接，可获取敏感信息。

•SSH端口开放是个有趣的发现。攻击者可尝试在该端口上对管理员账户进行暴力密码攻击，获取系统的访问权限。

nmap工具也可扫描整个网络，探测已开放端口的系统。

图15.3 所示的扫描覆盖192.168.1.0/24整个网络，包括192.168.1.0-192.168.1.255范围内的所有IP地址。

2.网络漏洞扫描

网络漏洞扫描不止步于探测开放端口，会继续探测目标系统或网络，发现是否存在已知漏洞。

这些工具包含数于已知漏洞的数据库及相应测试，这些工具通过这些测试确认某个系统是否受到工具漏洞数据库中漏洞的影响。

当对某个系统进行网络漏洞扫描时，扫描器使用数据库中的测试用例来确定系统是否存在漏洞。

误报(false positive report)，扫描器没有获取充足信息来判定某个漏洞是否存在，即使系统实际上不存在该漏洞，扫描器也会报告存在。

误报有时会对系统管理员造成干扰。

漏报(false negative report)：当漏洞扫描器漏过某个漏洞，未能向系统管理员报告存在危险情况，这种清况更危险。

网络扫描器默认执行未经身份验证的扫描。

即在不知悉口令或可获取特权的其他重要信息的清况下，网络扫描器对系统进行测试。

这种清况虽然使扫描基于攻击者视角运行，但也限制网络扫描器充分发现系统可能存在的漏洞。

执行经身份验证的系统扫描是一种有效方法，可提高扫描的准确性，同时减少漏洞的漏报和误报。

在这种方法中，网络扫描器拥有待测系统的只读权限，使用只读权限来读取待测系统的配置信息，然后在分析漏洞测试结果时加以运用。

相对于本章之前的网络发现扫描，使用Nessus漏洞扫描器对同一个系统执行网络漏洞扫描。

图15.4展示了网络漏洞扫描的结果。

图15.4中所示的扫描结果非常简洁，系统维护状态良好。

被扫描系统不存在严重漏洞，只有与SSH服务相关的两个低危漏洞。

虽然系统管理员可稍微调整SSH密码配置，修复这两个低危漏洞，但这份报告对管理员而言已是一份非常棒的报告。

漏洞扫描器：

•Nessus，是一种广泛应用的漏洞扫描器。

•QualysGuard，Qualys公司。

•NeXpose，Rapid7公司。

•OpenVAS，开源扫描器。

组织也可针对无线网络开展定制化漏洞评估。

Aircrack是一种常见的无线网络安全评估工具，它通过测试无线网络的加密算法和其他安全参数进行安全评估。

3.Web应用漏洞扫描

Web应用程序复杂多样，通常具有访问底层数据库的权限。

攻击者往往使用SQL注入和针对应用安全设计缺陷的其他攻击，尝试攻击Web应用程序。

Web应用漏洞扫描器扫描服务器上的web应用程序。

Web应用漏洞扫描器使用自动化技术探测Web应用程序，这些自动化技术控制输入及其他参数来识别Web应用漏洞。

Web应用漏洞扫描器会提供一份扫描结果报告，该报告通常包括推荐的漏洞修复方法。

图15.5展示了使用Nessus漏洞扫描工具进行Web应用漏洞扫描的示例。

Nessus漏洞扫描器是可执行网络漏洞扫描和Web应用漏洞扫描两种扫描的复合工具。

Web应用漏洞扫描是组织安全评估和测试项目中非常重要的组成部分。

在以下情况下运行Web应用扫描是良好实践：

•首次开始执行Web漏洞扫描时，扫描所有应用程序。这种做法将检测到遗留应用程序的问题。

•任何新应用程序首次移植到生产环境前，必须进行扫描。

•代码变更引入生产环境前，必须扫描任何修改过的应用程序。

•定期扫描所有应用程序。如果资源有限，可能需要根据应用程序的优先级安排扫描任务。

例如，应该更频繁地扫描与敏感信息交互的应用程序，其他应用程序的扫描频率退居其次。

有些情况下，Web应用漏洞扫描需要满足合规性的要求。

例如，支付卡行业数据安全标准(PCI DSS)要求企业至少每年执行一次Web应用漏洞扫描，或安装专业的Web应用防火墙，增加针对Web漏洞的额外防护层。

常用的Web应用漏洞扫描工具包括:

•Nessus

•商业扫描器 Acunetix

•开源扫描器 Nikto和Wapiti

•开源扫描器 Wapiti

•代理工具 BurpSuite。

4.数据库漏洞扫描

数据库存储一些组织最敏感的数据，容易成为攻击者牟利的目标。

虽然大多数数据库受防火墙的保护，避免外部直接访问，但Web应用程序会提供这些数据库的入口。

攻击者可能利用Web应用程序来直接攻击后端数据库，包括SQL注入攻击。

数据库漏洞扫描器允许安全专业人员扫描数据库和Web应用程序，寻找影响数据库安全的漏洞。

sqlmap：常用的开源数据库漏洞扫描工具，帮助安全专业人员探测Web应用程序的数据库漏洞。

5.漏洞管理工作流程

采用漏洞管理系统的组织应该形成一套工作流程来管理漏洞。

这套工作流程应该包括以下的基本步骤：

(1)检测：通常在扫描漏洞之后，第一次发行某个漏洞。

(2)验证：一旦扫描器检测到一个漏洞，管理员应该确认此漏洞，判断它是否为误报。

(3)修复：此后，验证过的漏洞需要加以修复。

漏洞修复可能包括-应用供应商提供的补丁、修改设备配置、执行规避漏洞的折中方法、安装Web应用防火墙及采取阻止漏洞利用的其他控制措施。

应根据漏洞的严重性、漏洞利用的可能性、漏洞修复的可能性来决定漏洞修复顺序。

15.2.3渗透测试

渗透测试过程通常包含以下几个阶段。

•规划 阶段包括测试范围和规则的协议。规划阶段是极其重要的阶段，它确保测试团队和管理人员对测试性质达成共识，明确测试是经过授权的。

•信息收集和发现 阶段结合人工和自动化工具来收集目标环境的信息。此阶段包括执行

基本的侦察来确定系统功能（如访问系统上托管的网站），并执行网络发现扫描来识别系统的开放端口。

•漏洞扫描 阶段探测系统脆弱点，结合网络漏洞扫描、Web漏洞扫描和数据库漏洞扫描。

•漏洞利用 阶段试图使用人工和自动化漏洞利用工具来尝试攻破系统安全防线。

•报告 阶段总结渗透测试结果，并提出改进系统安全的建议。

渗透工具：Metasploit，自动对目标系统进行漏洞利用，使用脚本语言来实现常见攻击的自动化执行。

通过消除攻击执行过程中大量繁杂和重复的步骤，Metasploit为测试人员（以及黑客）节省了不少时间。

渗透测试通常划分为以下三种：

•白盒渗透测试(White Box Penetration Test)：向攻击者提供目标系统的详细信息。

这种情况通常可以绕过攻击之前的许多侦察步骤，缩短攻击时间，提升发现安全漏洞的可能性。

•灰盒渗透测试(Gray Box Penetration Test)：也称为部分知识测试，有时是为了平衡臼盒渗透测试和黑盒渗透测试的优缺点。

当需要黑盒测试结果，但由于成本或时间受限，需要一些知识来完成测试时，常使用这种测试方式。

•黑盒渗透测试(Black Box Penetration Test) ：攻击之前不会向测试人员透露任何信息。

这种测试模拟外部攻击者，在攻击之前试图获取有关业务和技术环境的信息。

开展渗透测试的组织应该小心谨慎，确保己了解测试本身的危害。

渗透测试试图利用漏洞，因此可能中断系统访问或损坏系统存储的数据。

在启动测试前，需要在测试规划期间明确指出参与的规则，并从高级管理层获得充分授权，这非常重要。

15.3测试软件

软件是系统安全的关键组成部分。

现代企业所使用众多软件的如下共同特点：

•软件应用程序通常拥有操作系统、硬件和其他资源的访问特权。

•软件应用程序往往处理敏感信息，包括信用卡号码、社会保险号码和专有的业务信息。

•许多软件应用程序依赖于存储敏感信息的数据库。

•软件应用程序是现代企业的核心，执行关键业务功能。软件故障可能对业务造成严重破坏。

15.3.1代码审查与测试

代码审查与测试是软件测试方案最关键的组成部分。

在代码移植到生产环境前，这些过程对研发工作进行第三方审查。

在应用程序正式上线前，代码审查和测试可发现应用程序在安全、性能、可靠性方面的缺陷，从而避免对业务运营产生负面影响。

1.代码审查(code review)，也称为同行评审"(peer review)

代码审查是软件评估的基础。除了编写代码的开发人员，其他开发人员审查代码是否存在缺陷。

代码审查可能决定应用程序是允许移植到生产环境，还是退回给原开发人员，让其重写代码。

代码审查可采用多种不同的形式，并且不同组织之间的形式上也有所不同。

范根检查法(Fagan inspections)，最正式的代码审查过程，遵循严格的审查和测试过程。

范根检查包含六个步骤：

(1)规划

(2)概述

(3)准备

(4)审查

(5)返工

(6)追查

范根检查的每个步骤都已定义好进入和退出的标准，这些标准必须在流程正式转换到下一阶段之前得到满足。

范根检查级别的审查通常只出现在严格限制的研发环境中，在这里代码缺陷会造成灾难性危害。

大多数组织采用稍微宽松的代码审查流程，使用同行审查方法，包括：

•开发人员在会议上与一个或多个其他团队成员走查(walk through)代码。

•高级开发人员执行手动代码审查，在移植到生产环境之前签署所有代码。

•在移植到生产环境之前，使用自动化代码审查工具，检测常见应用缺陷。

所有组织应该采用符合其业务需求和软件开发文化的代码审查流程。

2.静态测试

静态测试在不运行软件的清况下，通过分析软件源代码或编译后的应用程序，评估软件的安全性。

静态分析经常涉及自动化检测工具，用于检测常见的软件缺陷，如缓冲区溢出。

在成熟的开发环境中，软件开发人员可访问静态分析工具，并在软件设计、构建和测试过程中加以运用。

3.动态测试

动态测试在软件运行环境下检测软件的安全性，如果组织部署他人开发的软件，这将是唯一选择。

这些情况下，测试人员无法接触到软件的底层源代码。

动态测试的常见示例：使用Web应用程序扫描工具来检测Web应用程序是否存在跨站脚本、SQL注入或其他濡洞。

在生产环境中，动态测试应该谨慎开展，避免服务的额外中断。

动态测试可能使用模拟事务(synthetic transactions)在内的方法，从而验证系统的性能。

动态测试包含一些脚本化的事务用例及其预期结果。

测试人员针对测试代码运行模拟事务，然后将事务活动的输出与预期结果进行比较。

如果实际输出与预期结果存在偏差，那就表示代码存在缺陷，有待进一步调查。

4.模糊测试

模糊测试是一种特殊的动态测试技术，向软件提供许多不同类型输入来测试其限制，发现之前未检测到的缺陷。

模糊测试向软件提供无效的输入（随机产生的或特殊构造的输入），触发已知的软件漏洞。

模糊测试人员监测软件的性能，观察软件是否崩溃，是否出现缓冲区溢出或其他不可取和（或）不可预知的结果。

模糊测试主要分为两大类：

•突变(Mutation或Dumb)模糊测试：从软件实际操作获取输入值，然后操纵（或变异）输入值来生成模糊输入。

突变模糊测试可能改变输入的内容，在内容尾部追加字符串，或执行其他的数据操纵方法。

•预生成（智能）模糊测试：设计数据模型，基于对软件所用数据类型的理解创建新的模糊输入。

zzuf工具可根据用户使用说明，通过操纵软件输入，实现突变模糊测试自动化。

例如，图15.10显示了使用zzuf工具生成包含一串“1"的文件

图15.11显示zzuf工具应用到输入文件。

经模糊化的文档和原文档内容几乎一样，仍然绝大多数是“1",但现在文本已经发生几处改变，这种变化可能扰乱程序对原输入的期望。

这种略微控制输入的过程称为比特反转(bit flipping)。

模糊测试局限性：

模糊测试通常不能完全覆盖所有代码，一般仅限于检测不涉及复杂业务逻辑的简单漏洞。

因此，模糊测试仅被视为测试套件中的一个工具而已，并有助于执行测试覆恙率分析，从而确定测试范围是否完整。

15.3.2接口测试

在软件测试过程中，需要测试的接口分为三种类型：

(1)应用编程接口(Application Programming Interface, API）：

为代码模块之间交互提供统一方法，并通过Web服务形式向外部公开。

开发人员对API进行测试，确保API实施了所有安全要求。

(2)用户界面(User Interface, UI)：

包括图形用户界面(Graphic User Interface, GUI)和命令行界面。

UI为终端用户提供与软件交互的能力。接口测试应该审查所有用户界面，以验证用户界面是否正常工作。

(3)物理接口：

存在于操作机械装置、逻辑控制器或其他物理设备的一些应用程序。

软件测试人员应该谨慎测试物理接口，因为如果物理接口失效，可能导致一些潜在后果。

15.3.3误用例测试

一些应用程序存在明显的说明示例，展示软件用户可能尝试错误使用该应用程序。

例如，银行软件的用户可能尝试修改输入字符串，达到访问其他用户账户的目的。

他们也可能尝试从已透支的账户上取款。

软件测试人员使用一种称为误用例测试的过程，评估软件是否存在与这些已知风险相关的漏洞。

在误用例测试过程中，测试人员首先列举已知误用例。

然后，尝试通过手工或自动化攻击的方法，尝试利用这些误用例来测试应用程序。

15.3.4测试覆盖率分析

虽然测试是所有软件开发过程中的一个重要组成部分，但是，不可能测试软件的所有部分。

因为软件可能出现故障或遭受攻击的方式不胜枚举。

软件测试人员通常进行测试覆盖率分析，由此估计对新软件的测试程度。

用以下公式计算测试覆盖率：

测试覆盖率＝已测用例的数量/全部用例的数量

当然，这是一个非常主观的计算。

精准计算测试覆盖率需要列举所有可能的用户用例，但这是一个极其困难的任务。

所以，测试人员在解释测试结果时，需要注意理解用于生成输入值的过程。

测试覆盖率分析公式适用于许多不同标准。

下面是五个常见标准：

•分支覆盖率：在所有if和else条件下，每个if语句是否已被执行？

•条件覆盖率：在所有输入集合下，代码中每个逻辑是否已被测试？

•函数覆盖率：代码中每个函数是否已被调用并返回结果？

•循环覆盖率：在导致代码执行多次、一次或零次的条件下，代码中每个循环已被执行？

•语句覆盖率：测试期间，是否已运行过每行代码？

15.3.5网站监测

安全专业人员也经常参与网站持续监控，从事性能管理、故障排除、潜在安全问题识别等活动。

这类网站监测可分为两类：

(1)被动监测：

在经网络传输或抵达服务器的过程中，通过捕获发送到网站的实际网络流量，进行分析。

被动监测提供真实监测数据，帮助管理员深入理解网络上正在发生的事情。

真实用户监控(Real User Monitoring, RUM)是一种被动监测的变体，监测工具重组单个用户的活动，追踪其与网站的交互。

(2)综合监测（或主动监测）：

是对网站执行伪造的事务活动，从而评估其性能。

综合监测可以是从站点请求一个页面来确定响应时间那么简单，也可能执行复杂的脚本来确认事务活动的结果。

这两种技术通常相互配合使用，因为它们可以达到不同目的。

由于监测真实用户活动，被动监测仅在真实用户出现问题之后才能监测到。

被动监测擅长解决用户识别的问题，因为可捕获到与问题相关的流量。

如果相关测试内容未包含在测试脚本，综合监测可能忽略真实用户遇到的问题，但可在真正发生之前检测到问题。

15.4实施安全管理流程

除了执行评估和测试外，健全的信息安全计划还包括各种管理过程，旨在监督信息安全计划有效运行。

这些过程为安全评估提供一个关键反馈环路，因为它们可提供管理监督，并对内部攻击威胁产生威慑作用。

满足这种需求的安全管理审查包括日志审查、账户管理、备份验证、关键性能和风险指标。

每项审查都应遵循一个标准化流程，包括审查完成后的管理层批准。

15.4.1日志审查

安全信息和事件管理(Security Information and Event Management, SIEM)工具包可在这些过程中起到重要作用，使日志审查的许多常规工作实现自动化。

这些工具包利用许多设备、操作系统和应用程序中存在的syslog功能来收集信息。

一些设备（包括Windows系统）可能需要安装第三方客户端来增加对syslog的支持。

管理员可通过Windows组策略对象(Windows Group Policy Objects,GPO)来部署日志策略，也可通过在整个组织中部署和实施标准策略的其他机来实现。

网络时间协议(NTP)

日志系统还应该利用NTP，确保向SIEM发送日志记录的系统和SIEM本身的时钟同步。

保证多种来源的信息具有一致的时间轴。

信息安全管理者还应该定期进行日志审查，特别是对于敏感功能，确保特权用户不会滥用其职权。

例如，如果信息安全团队可访问eDiscovery工具，检索个人用户的文件内容。

那么信息安全管理者应该定期审查这些信息安全团队成员的操作日志，确保文件访问符合合法使用eDiscovery的初衷，并且要避免侵犯用户隐私。

15.4.2账户管理

账户管理审查(account management review)确保用户仅保留被授予的权限，并不发生未授权的修改。

账户管理审查可以是信息安全管理人员或内部审计员的一项职能。

执行账户管理审查的一种方式是对所有账户进行全面审查。

考虑到所耗费的时间，这种方法通常只适用于特权账户。

具体过程可能因组织而异，下面是一个通用示例：

(1)管理人员要求系统管理员提供具有特权权限的用户列表及特权。管理人员可在检索此列表时监测管理员，以避免篡改。

(2)管理人员要求特权审批机构提供授权用户的列表及其分配的权限。

(3)然后，管理人员对这两份清单进行比较，确保只有经授权的用户才能保留对系统的访问权限，并且每个用户的访问权限不超过其授权。

此过程可能包括许多其他检查，如验证已解雇的用户不保留对系统的访问权限，检查特定账户的书面记录以及其他任务。

组织如果没有时间执行全部过程，可改用抽样方式。

在这种方法中，管理人员会随机抽取部分账户，并对这些账户的授权过程进行充分验证。

如果在抽取账户中没有发现明显缺陷，管理入员推测这些抽样账户可代表全部账户。

组织还可自动执行账户审核流程的一部分工作。

许多身份和访问管理(Identity and Access Management, IAM)供应商可提供账户审查工作流程提示管理员审查、维护用户账户的文档并提供说明审查已完成的审计踪迹(audit trail)。

15.4.3备份验证

管理人员应定期检查备份结果，确保流程可有效地运行并满足组织的数据保护需求。

这个过程可能涉及审查日志、审查散列值或请求系统或文件的实际恢复。

15.4.4关键绩效和风险指标

安全管理人员还应持续监测关键绩效和风险指标。

虽然监视的具体指标因组织而异，但可能包括如下内容：

•遗留漏洞的数量

•修复漏洞的时间

•漏洞/缺陷重现

•被盗用账户的数量

•在移植到生产环境前扫描过程中检测到的软件缺陷数量

•重复审计的结果

•尝试访问已知恶意站点的用户

组织一旦识别出想要跟踪的关键安全指标，管理人员可能希望开发一个仪表板，

随着时间清晰地展示这些指标的值，而且管理人员和安全团队可以定期查看。