精于技术, 专于培训

安全审计与评估,姿势很重要

2019-01-12 11:11:15 690

安全审计与评估,姿势很重要

1 审计策略

审计是对信息系统内部安全控制的系统性评估。所谓“信息系统”被广泛认为是一组特定范围的人、计算机、过程和信息的集合。信息系统的安全审计是对特定范围的人、计算机、过程和信息的各种安全控制所实施的一个系统性评估。

安全审计与评估,姿势很重要


安全审计等同于针对特定计算平台的漏洞评估或是渗透测试。

审计的范围应该与业务经理协调之后再确定。这是因为安全专业人员往往只注重于IT,却遗忘了各种业务场景。而事实上,业务经理应该介入到审计计划过程的早期阶段,并在整个工作过程中一直参与进来。这不仅有助于弥合两大团队之间的差距,还有助于识别出审计本身给组织带来潜在风险的领域。想象一下,如果你的评估干扰了一个关键但不明显的业务流程,并最终让组织花费了大量的资金,那么结果会是怎样呢?我们称之为RGE个人履历生成事件(resume-generating event)。

你所面临的一个关键性决定是:由内部团队还是由第三方来执行审计。如果你没有内部的专业经验,那么你可能已经做出了决定。但是,即使你的团队拥有这类专业知识,你仍然会因为某些原因而选择引入外部审计师。例如,可能某个监管法规要求由外部团队来测试你的系统;或者你可能希望用外部团队来标准化自己的内部资产;或者你自己的测试团队人手不够,不足以涉及所有审核需求,因此你需要引入外部帮助。

信息系统的安全审计流程

1、确定目标

2、让合适的业务部门领导参与进来,以确保业务需求能够被识别和涉及。

3、确定范围,因为并不需要全部涵盖进来。

4、选择审计团队,根据目标、范围、预算和可用的专业知识,来决定是由内部人员还是外部人员所组成。

5、计划审计,以确保按时、按预算实现所有目标。

6、执行审计,要在坚持计划的同时,记录其中的任何偏差。

7、记录结果,因为所产生的大量信息既是有价值的,同时也是不稳定的。

8、将结果传达给合适的领导,以实现和维持强有力的安全态势。

计划阶段:

•我们必须确保能够涉及任何可能在业务流程中引入的风险。没有计划,这些风险将不得而知、且不易被降低。

•记录计划,以确保我们满足每一项审计的目标。审计团队有时会试图遵循他们自己拟定的计划,而这不一定涉及针对某项特定审计的所有组织目标。

•记录计划将有助于我们记住那些不在评估范围内的项自。回顾一下,我们已经承认了“不可能测试一切”这一事实,因此记录会标注出那些我们没做的测试。

•计划应确保审计过程是可重复的。就像任何好的科学实验那样,我们也应该能够通过重复过程来重现其结果。这是非常重要的,因为我们可能遇到一些值得进一步调查的意想不到的结果。

某些情况下(例如“法规的遵从性”),可能需要由外部审计团队来指定和执行审计的各项参数。这意味着组织的角色仅限于准备审计,以确保审计团队能获得所有必要的资源。

任何审计的最终期望状态是:有效地将结果传达给目标受众。我们将结果传达给高管的方式与我们传达给IT团队成员的方式会截然不同。这就回到了先前对易于捕获和记录计划的描述,及需要执行的细节和产品的论点上了。相对于那些仅存在于我们大脑中,并还需要去证明结论的事实而言,从大数据集里提取信息的方式总归要更为容易些。许多安全审计之所以最终没能成功?就是因为团队无法与关键的利益相关者进行有效沟通。

1.1 内部审计

使用自己的人员进行审计的好处之一是:他们熟悉组织的内部运作。这种熟悉程度使得他们能够马上开始工作,而不必花费太多时间去适应网络环境。高级对手通常可以达到内部审计团队对组织的了解水平。在任何情况下,如果审计的目的是不遗余力地测试信息系统中那些最薄弱、最模糊的部分的话,那么内部团队可能会比任何其他团队更能接近该目标。

使用内部资源还会使得组织在评估工作中更为灵活。由于内部团队时刻可以就位,领导层需要做的仅是重新调整其测试的优先级,以适应不断变化的需求。例如,假设一个业务部门被安排每年审计一次,但一个月前的一次最新评估结果不佳,并且显示出组织风险有增加的趋势。那么安全管理层应顺理成章地重新安排其他测试,作为三个月后的后续审计。这种灵活性不会给组织带来额外成本。

使用内部团队的会有这样一个客观上的缺点:在运用其他方法来保护和利用信息系统的“发现能力”方面,他们可能受到限制。除非团队里最近聘用了一些有前期经验的成员,否则该团队即使可能有很多高深的技术,也不会有太大的广度。因为他们只练就了用于测试自己组织所需的技能。

使用内部审计师的另一个不太明显的缺点是:存在着利益冲突的可能性。如果审计师们认为其老板或同事可能会受到负面报告的影响,或者甚至由于记录所存在的缺陷而招致不利的影响,那么审计师们则可能不愿意准确地报告他们的发现。由此可见,组织的文化可能是这一潜在冲突中最有影响力的因素。如果整体气氛是开放和信任的,那么无论他们发现什么,审计师们都不太可能察觉到高层或同事的任何风险。相反,在那些对失败容忍度较低的、非常僵硬的官僚组织中,利益冲突的可能性则可能更高。

利益冲突的另一个方面问题是:团队成员或其老板可能会有一个用户操控审计结果的过程。如果他们打算获得更多的安全资金,则很可能夸大、甚至捏造出安全缺陷。同样,如果他们认为另一个部门需要被教训一下,则可能故意或者下意识地产生比客观事实更差的结果。因此在决定是否使用内部审计团队时,应当清楚地考虑到政治因素和团队动力。

1.2 第三方审计

首先,外部审计师可能己经见证并测试过不同组织中的许多信息系统。这就意味着,他们几乎肯定会给你的组织带来从未获得的知识。即使你有一些具备前期经验的内部审计师,他们也不太可能像那些定期测试各类组织的外包审计师那样具备广泛的经验。

第三方审计师的另一个优势是:他们不了解目标组织的内部动力和政治。这就意味着除了“寻找各种缺陷”这一挑战之外,他们并无偏好或特定的过程。这种客观性会是他们在测试中的优势。如果内部人员在实施控制之初担任了一定的角色,则可能会忽视或者潜意识地阻碍对缺陷的查找。

雇用外部团队的明显缺点就是成本。即使在低端小规模的组织里,出现数万美元的标价也并不罕见。如果别无其他,这可能意味着你将不能经常使用外部审计师。虽然拿着高薪,但是那些完全依赖高端扫描工具来工作(和做判断)的测试人员仍比比皆是。当一个组织花费了大量费用,却发现测试人员只是将其笔记本电脑连入网络、运行扫描工具、然后打印出报告的话,这将非常不幸。

即使你找了一个有担当且胜任的团队来测试信息系统,仍然需要解决那些使他们能够熟悉本组织并能监管其工作所增加资源的问题。即使签署过保密协议(nondisclosure agreement,NDA),大多数公司也不会放任外部审计师们,而毫无任何监管。此外,缺乏对组织内部工作的了解,通常会转化为审计师们在开始测试之前,需要花费更长的时间去摸清方向。

在允许第三方团队去审计一个组织的系统之前,签署保密协议几乎已成为一个常规的先决条件。

但是在诸如有“萨班斯-奥克斯利法案(Sarbanes-Oxley Act)”等法规要求的组织进行第三方测试时,后者就成了唯一的选择。这些被称为合规审计,而且必须由外部团队来实施

服务性组织(Statement on Auditing StandardsNo.70:Service Organizations,SAS 70)规定由第三方进行审计,以评估服务性组织的内部控制。采用SAS70审计,确保你所合作并依赖的公司能真正地如其宣称的那样,去保护公司的资产。

AICPA发布了一个新的服务性组织控制(Service Organization Controls,SOC)审计标准框架,它在美国鉴定业务准则公告(American Statement on Standards forAttestation Engagements,SSAE)第16号和国际计算中心(International Computing Center,ACC)的国际鉴定业务准则(International Standard on AssuranceEngagements,ISAE)第3402号中被定义。其中有三种soc报告:

• SOCl适用于财务控制

• SOC2适用于信任服务(安全性、可用性、保密性、过程完整性和隐私)

• SOC3也适用于信任服务(安全性、可用性、保密性、过程完整性和隐私)

SOC2和3之间的差异是:SOC2报告所产生的结果提供了适用于所列出的、信任服务控制的详细数据,这不是给一般公众的。而SOC3生成的报告细节较少,可用于一般公众性目的。

SOC2报告包括由审计师进行过测试的描述和这些测试的结果,以及审计师对各个控制和系统有效性的意见。SOC3不包含测试信息和适当的控制细节,而仅报告系统是否满足特定信任服务标准的要求。soc3通常用作“批准证明”,并被放在服务提供商的网站和营销材料上。

ISO15408(CC)评价目标软件的安全保护等级,CC(安全评估标准)中定义可重用的安全需求是:PP(保护轮廓 protection profile),PP定义了用户对安全的需求,ST(Security Target)安全目标是厂商回应的产品的安全承诺。

BSIMM(Building Security In Maturity Model软件安全构建成熟度模型)了解、执行、计划软件开发的初始(initiative),BSIMM是一个测量和评估软件安全计划(SSI)的工具。BSIMM收集超过100家企业的真实数据,基于这些数据对SSI进行精细研究和分析。是一个开放的模型,包括一个基于软件安全实践模块的框架,企业可以据此来评估其软件安全。

进行安全评估的时,首先需要:确定安全评估需求

安全度量(metric)是为了:量化(评估)安全措施的有效性

审计人员进行安全审计时的第一步:识别法律法规,而不是和管理层就审计报告的结果达成一致

如果对某项专门的技术做审计:审计人员需要有专项的技能

XACML是一种用于决定请求/响应的通用访问控制策略语言和执行授权策略的框架,它在传统的分布式环境中被广泛用于访问控制策略的执行。在典型的访问控制框架中,有策略执行点PEP(Policy Enforcement Point)和策略决定点PDP(Policy Decision Point)。PEP用于表达请求和执行访问控制决定。PDP从PEP处接受请求,评估适用于该请求的策略,并将授权决定返回给PEP。

2 审计技术控制

技术控制是通过使用IT资产来实现的安全控制。这种资产通常是一些以特定方式配置的软件。当我们审计自己的技术控制时,所要测试的是:它们对那些我们在风险管理流程中所识别的风险的降低能力。因为我们需要理解实施特定控制的环境,所有各种控制与那些试图降低的风险之间的联系是很重要的。

一旦我们理解了技术控制的目的,我们就能选择合适的方法来测试其是否有效。而对于试图做代码审查而言,我们可能更适合去测试第三方软件的漏洞。作为安全专业人员,我们必须熟悉最常用的审计技术控制方法并具有相关经验,以便能为当前的工作选择合适的方法。

2.1 脆弱性测试

脆弱性测试,无论是手动和/或自动进行,都需要由拥有深厚安全背景、极其可信的员工或顾问来完成。即使自动化程度最高脆弱性扫描工具也会生成误报;或者就一个具体的脆弱性向你报警,但这个脆弱性并不会危及你的环境或者在其他地方己经进行了充分的保护。此外,还可能存在两个单独的脆弱性,它们本身并不是非常重要,但结合在一起就会造成严重影响。当然,漏报还是会发生,例如某个脆弱性的一个隐蔽元素会给你的环境造成重大危害,但并没有被工具指出。

在执行脆弱性测试之前,管理层需要拟定一份书面协议。这样做可以防止测试人员因为该项工作而被起诉,并通过书面形式向测试人员说明在测试过程中哪些应该做、哪些不应该做,以确保他们不会对工作职责存在误解

测试评估的包括下列目标:

•评估一个环境的真实安全状况(如前所述,不要发出错误警报)。

•标识尽可能多的脆弱性,对每个脆弱性进行公正的评估并排定优先顺序。

•测试系统如何应对某些情况和攻击,不仅了解己知的脆弱性(如数据库的版本、操作系统的版本或一个没有设置口令的用户ID),还要了解环境中的特定元素如何被滥用(SQL注入攻击、缓冲区溢出以及易于遭受社会工程攻击的设计缺陷)。

•在决定测试范围并就此达成一致前,测试人员必须解释测试可能造成的后果。某些测试可能使易受攻击的系统离线,测试在系统上增加的负载可能会对生产造成负面影响。

管理层必须了解,测试的结果只是一个“即时快照”。随着环境发生改变,新的脆弱性可能会出现。管理层还应该了解,可供使用的测试方法有若干种,每种方法都可以解释环境中存在的不同种类的脆弱性,每种方法所能提供的结果的完整性也存在一定限制。

•人员测试包括检查员工的任务,从而标识在要求员工遵循的标准实践和措施中存在的脆弱性,证明教导用户检测和阻止社会工程攻击的价值,审查员工策略和措施,以确保通过行政管理控制来缓解那些不能通过物理和逻辑控制消除的风险。

•物理测试包括审查设施和周边保护机制。例如:门确实会自动关闭吗?如果门敞开太久,会响起警报吗?对服务器机房、配线柜、敏感系统和资产实施的内部保护机制适当吗(如标记阅读器是否正常工作,它是否确实能够限制只有授权人员才能访问内部设施)?垃圾搜索是一种威胁吗(换句话说,敏感信息没有经过销毁就被丢弃了吗)?针对人为、自然或技术威胁,组织机构实现了什么保护机制?组织机构是否配备了消防系统?它能正常运行吗?能保障大楼内的人员和设备安全吗?灵敏的电子元件放在抬高的地板上,在较小的水灾发生时能够保证安全呢?

•在讨论信息安全脆弱性测试时,大多数人想到的可能是系统和网络测试。为提高测试效率,应当使用一种自动扫描产品来标识已知的系统脆弱性。如果管理层已经认可测试可能造成的性能影响和中断风险,还可以使用某些产品来尝试利用这些脆弱性。

由于安全评估是环境安全状况的即时快照,因此评估应当定期进行。优先级较低、保护较为完善、风险较小的环境区域可以一年扫描1~2次。高优先级、更加脆弱的目标(如电子商务Web服务器组以及它们后面的中间件)应当几乎持续进行扫描。

根据所使用工具的自动化程度,应当使用几个工具,或者每次测试都使用一个不同的工具。没有哪一种工具能够知道或发现所有己知的脆弱性。各种扫描工具供应商更新其“工具”脆弱性数据库的速度各不相同,添加特定脆弱性的顺序也各不相同。因此,应始终在使用工具前更新每个工具的脆弱性数据库。同样,应常聘请不同的专家来测试与解释测试结果。任何专家都找不到结果中的所有脆弱性。

大多数网络由许多异构设备所组成,每今设备都有自己特定的潜在漏洞。我们在边界路由器上找到的潜在问题与无线接入点(WAP)或是后端数据库管理服务器(database managementserver,DBMS)上的是截然不同的。每个这些设备中的漏洞又将取决于特定的硬件、软件和所使用的配置。即使你能找到一个对于各种设备和设备特定的安全问题具有专家级别知识的个人或工具,此人或工具也会有着自身固有的偏差。因此,最好利用团队/工具的多样性,以提高覆盖各种盲点的可能性。


安全审计与评估,姿势很重要


2.2 渗透测试

渗透测试是指根据所有者(高级管理层)的要求模拟攻击一个网络及其系统的过程。渗透测试应用一组专门进行测试及可能绕过系统安全控制的程序和工具,它的目的是评估组织机构抵御某种攻击的能力,以及暴露环境中存在的任何弱点。组织机构需要确定其安全措施的有效性,而不能只是听信安全供应商的承诺。可靠的计算机安全应基于现实,而不是一些说明应该如何做的自以为是的目标。

渗透测试模仿攻击者将使用的相同方法。攻击者十分聪明,有创造力,并且应用各种技巧,因此渗透测试应该利用最新的黑客技术和强大的基本测试方法。测试还应全面考虑网络中的每一台计算机,因为攻击者不一定只扫描一两台计算机,也不仅发动一次攻击。

渗透测试的类型取决于组织机构、它的安全目标和管理层的目标。一些企业使用不同类型的工具对自己进行定期的渗透测试,或者使用持续对系统进行检查的扫描设备。另一些企业则邀请第三方公司来执行脆弱性和渗透测试,以获得更客观的意见。

渗透测试能够评估Web服务器、DNS服务器、路由器配置、工作站脆弱性、敏感信息访问、远程拨号访问、开放端口以及真正的攻击者可能用来危及公司整体安全的有效服务属性。一些测试可能具有相当的入侵性和破坏性。应该就测试的期限达成一致,以使公司的生产不会受到影响,并且工作人员在必要时可以使系统重新上线。

漏洞扫描可提供如下功能:

•识别网络中处于活动状态的主机

•识别主机上处于活动状态的和易攻击的服务(端口)

•识别应用程序和其标识的捕获

•识别操作系统

•识别己发现的操作系统和应用程序的相关漏洞

•识别错误配置的设置

•测试主机上应用程序的使用/安全策略合规性

•建立渗透测试的基础

渗透测试的结果应以报告的形式提交给管理层,其中应说明被标识的脆弱性和这些脆弱性的严重程度,并就如何处理这些脆弱性给出合理的建议。从此时起,就由管理层来决定如何处理脆弱性和实现什么对策。

在授权进行测试之前,高级管理层应意识到测试中可能包含的风险,这一点极为关键。极少数情况下,使用测试工具和技巧的系统或应用程序可能发生意外故障。本来,渗透测试的目的是标识脆弱性,评估环境中安全机制提供的真正保护,以及了解如何报告可疑的活动;但是,意外事故也可能确实会发生。

安全专业人员应获得包含授权测试范围的授权书。在测试活动中,测试图队成员需要使用这份授权书或备忘录。这份授权书通常称为“免死金牌”。授权书中还应包括关键人员的联系信息和一个电话列表,以便在出现意外情况和需要恢复系统时使用。

执行渗透测试时,测试团队要完成下列5个步骤

(1)发现搜集和收集目标的相关信息。

(2)枚举执行端口扫描和资源标识方法。

(3)脆弱性映射在确定的系统和资源中标识脆弱性。

(4)利用尝试利用脆弱性进行未授权访问。

(5)向管理层报告向管理层提交测试结果报告文件,并提供应对措施建议。

安全审计与评估,姿势很重要


在实际开始测试之前,渗透测试团队可能对渗透目标有不同程度的了解:

•零了解渗透团队根本不了解测试目标,必须从零开始。

•部分了解渗透团队了解一些与测试目标相关的信息。

•完全了解渗透团队了解测试目标的本质。

测试还应在外部(从一个远程地点进行测试)或内部(指测试人员在网络中进行测试)进行。组织机构应当全部进行这两种测试,以了解任何一个领域(内部和外部)的威胁。

测试可能是盲目的、双盲的或有针对性的。盲目测试指的是评估人员只能利用公开可用的数据,而网络人员知道将进行这种测试。

双盲测试(也称为隐蔽评估)对评估人员而言也是一种盲目测试,只是安全人员不会收到测试通知。因此,这种测试能够评估网络的安全级别以及员工的响应能力、日志监控和上报流程,从而更加现实地说明了发起某种攻击的成功或失败概率。

脆弱性评估可以标识系统内的一系列脆弱性,这种评估通常采用一个扫描工具来完成。与之相反,在渗透测试中,安全专业人员利用了一个或几个脆弱性,从而向客户(或你的上司)证明黑客确实能够访问公司的资源。

针对性测试指的是由外部顾问和内部员工共同对特别感兴趣的区域进行集中测试。例如,在发布一个新的应用程序之前,开发团队可能会进行脆弱性测试,然后将其安装到生产系统中。另一个针对性测试的示例为专门测试处理电子商务交易的系统,而不是测试公司的日常活动。

测试团队应该从基本的用户级访问开始,适当地模拟各种攻击。测试团队需要利用一系列工具和攻击方法,并考虑各种脆弱性,因为这些都是攻击者会采用的手段。哪种漏洞最难评估:硬件。

做渗透测试前必须得到:管理层书面批准授权;发生在运维阶段;目的是评估,而不是测试;进入系统后根据需要可能会纵向提权(纵向提权:低权限角色获得高权限角色的权限;横向提权:获取同级别角色的权限);购买第三方渗透测试服务注意网络渗透和应用渗透不一样;渗透发现阶段的目的:收集目标系统的信息(Discovery Footprinting and gatheringinformation about the target)

2.3 战争拨号攻击

战争拨号允许攻击者和管理员拨打大量的电话号码,以搜索可用的调制解调器。

许多传真(FAX)机器是可以被远程利用的,并且能够允许攻击者获得由该设备发送或接收的传真副本。许多金融机构仍然通过传真来从事相当数量的业务。

应调查有战争拨号标识的任何未授权调制解调器,使其符合规范或从系统中删除,而安装未授权调制解调器的员工应当再次进行培训或接受处罚。

2.4 其他脆弱性类型

经常被攻击者利用的脆弱性包括:

•内核缺陷这些问题在后台出现,深入到操作系统内。内核中的任何缺陷都可能被攻击者发现,如果可被利用,那么攻击者就能最大限度地控制系统。

对策:确保为环境中的操作系统及时安装安全补丁(经过充分测试后),尽可能减少出现脆弱性的可能性。

•缓冲区溢出糟糕的编程实践或者库中偶尔出现的bug都可以使输入程序被分配空间的存储限额。这会重写分配到缓冲区之后的数据或程序内存,有时允许攻击者注入程序代码,然后让处理器执行。这样,攻击者就拥有了与被攻击程序相同的访问权限。如果程序以管理用户身份或由系统本身运行,就可能意味着攻击者能够访问整个系统。

对策:良好的编程实践和开发人员教育、自动化的源代码扫描器、改良的编程库以及防止缓冲区溢出的强类型语言,这些都是避免这种极常见脆弱性的方法。

•符号链接虽然攻击者无法查看或修改敏感系统文件和数据的内容,但是如果一个程序访问一个符号链接(一个将访问重定向至其他位置的存根文件),那么攻击者就可以入侵这个符号链接,从而获得未授权访问(符号链接主要用在Unix和Linux系统中)。这样,攻击者就可以破坏重要的数据或获得系统的特权访问级别。在过去,攻击者曾利用符号链接使一个程序检测口令数据库,或者使用一些字符替换口令数据库中的一行数据,从而创建一个权限与根用户相当的、不需要口令的账户。

对策:必须编写程序和特定的脚本,确保无法绕开文件的完整路径。

•文件描述符攻击文件描述符是许多操作系统用于表示某个进程中的开放文件的编号。某些文件描述符是通用的,在所有程序中都是指相同的文件。如果程序以不安全的方式使用文件描述符,那么攻击者就能够向程序提供无法预料的输入,或者将输出转移到一个具有执行程序权限的、意想不到的位置。

对策:良好的编程实践和开发人员教育、自动化的源代码扫描器以及应用程序安全测试都可以减少这种脆弱性。

•竞态条件如果一个程序的设计方式使它处于某种易受攻击的条件,而后再设法减少那些易受攻击的条件,就会出现竞态条件。竞态条件的示例包括:打开临时文件,而没有首先确保未授权用户或进程无法读取或写入这些文件;在特权模式下运行或初始化动态负载库功能,而没有首先确认动态负载库路径是否安全。攻击者可以利用这些竞态条件让程序(使用它得到提升的权限)读取或写入无法预料的数据,或者执行未授权的命令。

对策:良好的编程实践和开发人员教育、自动化的源代码扫描器以及应用程序安全测试都可以减少这种脆弱性。

•文件和目录许可前面描述的许多攻击主要利用的是不适当的文件或目录权限,也就是说,系统某部分(一个更加安全的系统部件依赖于它)的访问控制中的一个错误。而且,如果系统管理员犯下错误,导致某个关键文件的权限的安全性降低(如允许常规用户访问口令数据库),那么攻击者就可以利用这个错误将一名未授权用户添加到口令数据库中,或者将一个不可信的目录添加到动态负载库的搜索路径中。

对策:文件完整性检查器(它还应检查预期的文件和目录权限)可以及时(甚至有望在攻击者注意并利用它们之前)检测出这类问题。

2.5 事后检查

测试类型

频率

好处

网络扫描

持续或每季度进行

·列举网络结构井决定活动主机和相关软件

·标识连接到网络的未授权主机

·标识开放端口

·标识未授权的服务

战争拨号

每年进行

·检测未授权的调制解调器,并阻止对被保护网络的未授权访问

驾驶攻击

持续或每周进行

·检测未授权的无线访问点,并阻止对被保护网络的未授权访问

病毒检测器

每周或按需进行

·在病毒安装到系统之前检测并删除

日志检查

每天对关键系统进行

·确认系统根据策略运行

口令破解

持续或按终止策略以相同的频率进行

·验证策略能够有效生成或多或少难以破解的口令

·验证用户选择了符合组织机构安全策略的口令

脆弱性评估

每季度进行或每两月进行,或者在更新脆弱性数据库时进行

·列举网络结构井决定活动主机和相关软件

·标识一组目标计算机专门进行脆弱性分析

·标识目标计算机上的潜在脆弱性

·确认操作系统和主要的应用程序安装了最新的安全补丁和软件版本

渗透测试

每年进行

确定组织机构网络被渗透的脆弱性以及可能导致的损失程度

测试IT人员如何响应己知的安全事故以及他们的知识水准,并测试组织机构安全策略和系统安全要求的实现情况

完整性检查器

每月及在发生可疑事件时进行

检测未授权的文件修改

2.6 日志审查

日志审查通过检查系统的日志文件,以检测各种安全事件或验证各种安全控制的有效性。日志审查实际上是在安全专家进行第一项事件检查之前就开始了。为使事件日志能够提供有价值的信息,他们必须捕获非常具体的、基于行业最佳实践和组织风险管理流程的大量信息。而那些可以帮助你评估安全态势的,一整套万能的事件类型是并不存在的。相反,你需要不断调整系统,以应对持续变化的威胁环境。

另一个为组织设置有效日志审查的关键因素是:确保所有联网的设备时间都标准化。如果一个事件影响了三个设备,而它们的内部时钟相差几秒钟,那么确定事件的发生顺序和理解攻击的整体流程将是非常困难的。虽然可以标准化不同的时间戳,但是该额外的步骤却会增加我们去理解攻击者在网络中的行为过程的挑战性和复杂性。标准化和同步时间并不是一件困难的事情,在RFC5905中描述的网络时间协议(Network Time Protocol,NTP)第4版就是用于在联网设备之间同步计算机时钟的工业标准。

网络时间协议NTP在端口123上以携带着64位时间戳的UDP数据报形式被发送的。

远程日志 当攻击者破坏一台设备时,他们时常会获得足够的特权来修改或清除该设备上的日志文件。将日志、文件放到一个单独的“盒子”里,则需要攻击者也将该“盒子”作为攻击目标,这至少为你发现并注意到该入侵争取了时间。

单工通信 一些高安全性的环境在其各个报告设备和中央日志存储库之间使用的是单向(或单工)通信。这可以通过在以太网线上分割“接收”消息对来轻松实现。而术语“数据二极管”有时用来指在物理上确保单向路径的方法。

复制 仅保存重要资源的单个副本作为合并日志的条目永远不是一个好主意。通过制作多个副本,并将其保存在不同位置,特别是在网络上至少有一处位置是无法被移动设备等访问到时,攻击者将难以更改这些日志文件。

一次性写入介质 如果你备份的日志文件位置之一是只能被一次性写入的话,那么攻击者将无法篡改该数据的副本。当然,他们仍然可以试图在物理上窃取介质,但是你现在是将条件强制设定为他们能够进入物理区域内了,而许多攻击者是根本做不到的。

加密散列链 使用加密散列链是一种保证事件的修改或删除能够容易地被注意到的强大技术。在该技术中,每个事件都被附加上该前导事件的加密散列(列如,SHA-256)。这就创建了一个链,用以证明其中每个事件的完整性和一致性。

安全信息和事件管理器(Security Information and EventManagers,SIEM)能实现事件数据的集中、关联、分析和保留,以便生成自动警报系统。通常情况下,SIEM提供了一个突显可能性安全事件的仪表板界面。由安全专家根据界面的显示去调查每个警报,并判定是否需要执行进一步的操作。当然,其挑战在于:要保证假阳性的数量尽量少,并且其假阴性的数量被保持为较低的水平。

假阳性率:得到了阳性结果,但这个阳性结果是假的。即在金标准判断无病(阴性)人群中,检测出为阳性的几率。(没病,但却检测结果说有病),为误诊率。

假阴性率:得到了阴性结果,但这个阴性结果是假的。即在金标准判断有病(阳性)人群中,检测出为阴性的几率。(有病,但却检测结果说没病),为漏诊率。收集的大量日志导致:及时评审日志变得困难;审核审计日志的目的:确定发生的事件

2.7 综合事务

综合事务的实用性是:允许我们系统地测试关键服务的行为和性能。也许最简单的例子莫过于你要确保自己的主页能够被启动并运行的场景了。你不必等到愤怒的客户发来电子邮件告知你首页无法被访问,或是你花了一天里的大部分时间用浏览器访问该页面。你完全可以编写一个脚本,定期访问你的主页,并能返回一个特定的字符串。那么这个脚本就可以在页面被关闭或无法访问时立即提醒你,以使你在自己主动注意到之前就能开始展开调查了。这将成为你的Web服务器在被黑掉或者遭遇分布式拒绝服务(Distributed Denial ofService,DDoS)攻击时的早期预警器。

综合事务可以做的不仅是告诉你服务是启动还是停止;它们可以通过测量性能参数,如响应时间,来提醒网络中的拥塞或服务器的过度使用;它们还可以通过模仿典型的最终用户行为来帮助你测试新服务,以确保系统能按预期进行工作。最后,这些事务可以被写成恶意用户的行为,例如:尝试跨站点脚本(Cross-Site Scripting,XSS)的攻击,以确保你的控制是有效的。这是从外部测试软件的有效方法。

真实用户监控(Real User Monitoring,RUM)采用被动方式来监控真实用户与WEB应用程序或系统的交互。它使用代理从用户的角度来捕获诸如延迟、抖动和错误等指标。不同于综合事务,RUM使用的是真人而不是脚本的命令。虽然RUM能够更准确地捕获实际的用户体验,但它更倾向于产生噪声数据(例如,由于用户改变主意或失去移动连接,而导致的不完整事物),因此可能需要有更多的后端分析。它也缺乏可预测性和规律性的要素,这可能意味着在低使用率期间,将不会检查到问题。

另一方面,综合事务是可预测和非常有规律的,因为它们的行为都是脚本化的。它们还可以比等待用户实际触发其行为更可靠地检测出罕见事件。综合事务是一种积极的方法,从而不必等待用户变得不满意或遇到问题才开始处理。

2.8 误用案例测试

用例通常是用于描述信息系统中所需功能的结构化场景。可将它们视为外部角色(例如用户)需要在系统上完成的给定目标的事件。用例描述了角色和系统之间的交互,和导致期望结果的顺序。用例是文本化的,但通常使用统一建模语言(Unified Modeling Language,UML)进行概括和图形化描述。

误用案例包括各种威胁角色和他们想要在系统上执行的任务用例。威胁角色通常被描绘为带有阴影头像的人物线条画,他们的行动(或误用案例)被描绘为阴影椭圆。

威胁者的误用案例是指:威胁我们系统特定部分或合法的用例。通常你所看到的带阴影的椭圆连接到带有标记为“威胁”箭头的无阴影椭圆就表示这种关系。另一方面,系统开发者和安全人员可以实施控制来消减这些误用。这就创建了新的、带有标记为“减缓”箭头的、在无阴影与带阴影椭圆形之间的连接。

误用案例测试背后的思想是:确保我们有效和全面地识别出每个风险,以决定在风险管理过程中需要减缓的风险,并能够适用于考虑的系统。这并不意味着误用案例的测试需要包括系统中所有可能的威胁,但至少应该包括我们需要涉及的威胁。这个过程迫使系统开发人员和集成商将风险管理过程的产品融入各种系统开发工作的早期阶段。它还使得快速跨越复杂的系统更为容易,并确保有效的安全控制被置于正确的地方,而不必深入到源代码中。

静态分析(Static analysis)是一种调试技术,在不执行程序的情况下检查代码,因此在程序被压缩之前进行。静态分析一词通常指辅助编程人员和开发人员的自动化工具。而人工所做的检查通常称为代码审核。

静态分析使开发人员可快速清除已知编程缺陷和脆弱性的源代码。此外,静态分析提供了可升级的安全代码审核方法,确保了遵循了安全编码策略。然而必须记住,静态代码分析从不暴露逻辑错误和设计缺陷,因此必须与人工代码审核结合使用,确保进行透彻的评估。

一个全面的安全测试包括手动测试和自动化测试。自动化测试有助于定位通常由于粗心或者与错误代码实现有关的大量缺陷。自动化测试通常使用的程序有模糊器、脆弱性扫描仪和代码扫描仪。模糊器使用复杂的输入来削弱程序执行。

模糊指发送随机数据到目标程序从而触发故障的行为。攻击者接下来会利用这些错误和缺陷,把他们自己的代码注入系统中来破坏它的安全性和稳定性。模糊工具往往可以成功识别缓冲区溢出、DoS脆弱性、注入弱点和验证缺陷以及一些其他能造成软件卡死、崩溃或投放意外错误的活动。

手动测试用来分析程序中需要人凭直觉和通常使用计算机技术才能判断的一些方面。测试者也是试图寻找设计缺陷。其中包括逻辑错误,攻击者可通过使用精心制作的程序序列来访问较大权限或者绕过身份验证机制来操作程序流。手动测试是由以安全为中心任务的编程人员进行代码审计,他尝试使用流氓输入和逆向工程技术来修改逻辑程序结构。手动测试模拟真实攻击中出现的场景。有些手动测试也使用社会功能来分析那些可能导致系统破损的人类弱点。

动态分析指对程序进行实时评估,如在它运行时。一旦程序完成了静态分析且基本的编程缺陷被处理掉之后,便开始进行动态分析。动态分析支持开发人员跟踪软件中可能引起安全混乱的细微的逻辑错误。这种技术的主要好处是它无须创建人为导致错误的场景。动态分析也适用于进行兼容性测试、探测存储器泄露和识别依赖、关系, 它无须访问软件真正的源代码便可以对软件进行分析。

负向negative测试:输入范围外的数字来判断系统的反应。

回归测试:变更后,用之前的测试用例重新进行测试,以确认变更没有引入新的错误。

结构测试(又称白盒测试):测试者全面了解程序内部逻辑结构、对所有逻辑路径进行测试。

功能测试(又称黑盒测试):涉及了软件在功能上正反两面的测试

非功能测试:所有其他方面的测试,包括性能、负载、可靠性等。

黑盒测试的特点:只要功能说明书就够。

独立测试:提高发现隐藏风险点的可能性。

图灵测试:是指测试者在与被测试者(一个人和一台机器)隔开的情况下,通过一些装置(如键盘)向被测试者随意提问。进行多次测试后,如果有超过30%的测试者不能确定出被测试者是人还是机器,那么这台机器就通过了图灵测试,并被认为具有人类智能

审计师要求软件留后门(trapdoor)以便合成交易,在使用trapdoor的时候要注意:使用时必须有严格的书面文档,使用过程必须严格控制,必须明确使用后果。(后门是绕过正常访问控制的途径,不需要什么良好的访问控制)

等价类分析:不属于已知分类的一个输入

边界值分析:超过有效值域边界外的输入

决策表分析:同条件集合下采取行动的若干组合的情况。

基于状态的分析:对于每种已知的条件,选择非预期的输入

2.9 代码审查

代码审查,系统地检查组成一个软件各部分的指令,并由该代码作者以外的其他人来执行。这种方法可以说是一种成熟软件开发过程的标志。事实上在许多组织中,一直到有人进行了代码审查并予以签发之后,开发人员才被允许推出他们的软件模块。这就像把一份重要文件发送给一位重要人物之前需要进行校对一样。如果你试图自己校对的话,可能不会像其他人为你校对那样容易地捕获到所有那些令人尴尬的打字错误和语法错误。

代码审查远不只是检查打字错误,虽然这也是它的一个元素,但这一切都要从组织开发出一套用于编写软件编码的标准开始。可以由内部团队、外包开发人员或商业供应商来实现。显然,除非软件是开源的或者你恰好在一个主要的政府机关,否则对于现成商业软件的代码审查一般极为罕见。不过,每个开发商都会有一个样式指南或一套文档化的编码标准,以涵盖从如何缩进代码到何时(以及如何)使用现有代码库等所有方面。因此,代码审查的预备步骤就是确保作者遵循团队的风格指南或标准。除了有助于软件的可维护性之外,该步骤还会给出代码审查者未来工作量的预览,因为一个粗心的编码者的代码中可能有他人难以发现的很多缺陷。

检查了代码的结构和格式后,审查者会着手寻找不被调用或不需要的函数或过程。因为这些会导致“代码肿胀”,而使得应用程序更难以被维护和保护。出于同样的原因,审查者也会去寻找那些过于复杂,且应该被重构或拆分为多个例程的模块。最后,在降低复杂性方面,审查者还会寻找可以被重构的重复代码块。更好的结果是:这些被拖出来的代码块能被转换为外部可重用的组件,如库函数。

对于那些不必要的(且危险的)过程,一个极端例子是:开发人员经常在其开发的软件中包含代码存根和测试例程。开发人员在软件的最终版本中留下测试代码(有时包括硬编码的凭证)的情况比比皆是。一旦对于发现了这种情况,利用软件去绕过安全控制将轻而易举地实现。这种问题的隐患就在于:因为开发人员有时仅会注释掉最终测试的代码,以防万一在测试失败时,他们必须回来并返工的情况发生。他们本应该牢记要重新访问该文件,并删除这些危险的代码,但之后却忘记这样做了。虽然在编译程序后,注释代码不会被攻击者得到(除非他们有权访问源代码),但常见的分布式应用程序的脚本却并非如此。

防御性编程是所有软件开发操作应该采用的最佳实践。简而言之,它意味着:当你在开发或审查代码时,你是在不断寻找那些会使事物变糟的因素。防御性编程的最好例子可能是:将所有输入都视为不可信,直到被证明并非如此。用户输入验证的实现可能比它听起来更为微妙,因为你必须了解输入的上下文环境。你期望的是一个数值吗?如果是,该值的可接受范围是多少呢?这个范围能够随时间变化吗?在我们决定输入是否有效之前,需要回答这些以及其他许多问题。我们经常看到的许多被利用的漏洞,其根本原因都是缺少输入的验证

通过:代码适合使用

返工后通过:只要稍加改变和修改,代码便可使用

重新检查:修复各种问题并进行另一轮检查

2.10 接口测试

图形用户界面(Graphical User Interface,GUI)。虽然GUI是一种类型的接口,但还可能存在其他更重要的类型。实质上,接口是用于系统和/或用户之间的数据交换点。你可以在计算机的网络接口卡(Network Interface Card,NIC)中看到,它是计算机(系统)和局域网(另一个系统)之间的数据交换点。接口的另一个示例是应用程序编程接口(Application Programming Interface,API),它是软件系统(如应用程序)与另一软件系统(如库)交换信息的一组交点。

接口测试对给定的一组交换点的系统进行评估。这种评估应包括己知的好的交换和坏的交换,以确保系统在交换的两端能正确运行。然而真正的障碍却在于发现其间的测试用例上。在软件测试中,位于好的和差的分割边界处,被称为边界条件。例如,如果给定的数据包应该包含不超过1024个字节的有效负载,那么当出现1024字节再加上一位(或字节)的数据时,系统将如何运作呢?如果恰好是1024个字节呢?或者有1024个字节减去一位(或字节)的数据呢?这个想法就是探究好与坏的边界线,来测试当我们真正接近它时会发生什么。

测试用例最重要的原则是:接口测试的主要任务是提前设想所有的测试用例,记录它们,然后将它们插入到一个可重复的且自动化的测试引擎中。这样,你可以确保随着系统的发展,特定的接口总能被正确的测试用例集合所测试到。接口测试是一个被称为集成测试的特例,它评估系统的不同部分彼此之间如何进行交互。

3 审计管理控制

管理控制通常主要通过策略或流程来实施。

3.1 账户管理

攻击者的一种首选技巧是尽快成为他们攻击系统的“正常”特权用户。可通过至少三种方式来完成此操作:盗用现有特权账户,创建新的特权账户,或是提升常规用户账号的权限。第一种方法可以通过使用强身份验证(例如强密码或更好的双因素身份验证)以及通过让管理员仅在执行特定任务时使用特权账户的方法予以消减。

可通过密切注意用户账号的创建、修改或误用来消减第二和第三种方法。这些控制都属于账户管理的类别。

1,添加账户

当新员工到岗时,他们应该被一个明确的流程所指导,其目的不仅是确保他们能理解自己的职责,还保证分配给他们的所需公司资产是被正确配置、保护和记录的。虽然如何完成这些具体细节会因组织不同而异,但有一些具体的管理控制却是通用的。

首先,应该要求所有新用户阅读并确认理解了(通常通过签名)相关的所有策略。每个组织至少应该有(并且每个用户都应该签名)可接受的使用策略(Acceptable Use Policy,AUP),其中规定组织认可的雇员对信息系统的适当使用行为。例如:使用工作计算机观看色情物品,发送内容偏激的电子邮件,或攻击其他计算机,这些几乎都是被禁止的。另一方面,许多组织允许其雇员有限地进行个人目的的使用,例如,检查私人电子邮件或在休息期间上网。AUP是有效的第一道防线,因为它记录了每个用户应知道的,在工作中可以使用计算机和其他资源做什么。这使得用户在违反了AUP后很难声称其一无所知。

测试所有员工都是否知道AUP和其他适用的策略是审核用户账户的第一步。因为每个用户都应该有一个签名过的AUP,例如:我们所需要的是获得组织中所有用户的列表,然后将其与含有签名的文件进行比较。许多情况下,新员工签名过的所有文件由人力资源(Human Resources,HR)保存,而计算机账户则由IT维护。交叉检查AUP和用户账号还可以验证这两个部门是否进行着有效的沟通。

策略还应规定账户的默认到期日期、密码策略以及用户应具有的访问权限信息。这最后一部分是很困难的,因为个体用户的信息需求常随时间的推移而变化。

2.修改账户

假设一个新雇用的IT技术人员最初被分配的任务是去管理一组服务器的备份作业。随着时间的推移,你意识到这个人最适合支持内部用户,包括添加新账户、重置密码等。在每个角色所需的权限不同时,你应该如何处理呢?不幸的是,许多组织会采取给予用户所有可能需要的特权的办法。我们经常会看到或听到:在组织里,每个用户都是他(或她)的计算机上的本地管理员,并且IT部门的每个成员也都是域管理员。这是一个特别危险的做法,特别是他们都默认使用这些高级身份凭证时。这通常被称为特权累积

添加、删除或修改权限应该有一套被精确控制和记录的过程。新权限何时生效?他们为什么需要?谁授权?那些具有成熟安全过程的组织有适当的变更控制过程,以处理用户的特权。许多审计人员将注意力集中在组织中谁具有管理权限,但仍有许多自定义的权限集已经达到管理员账户的级别。因此,重要的是要有可用来测试那些定制的高级权限的过程。

3. 暂停账户

账户管理的另一个重要实践是暂停不再需要的账户。每个大型组织最终都会碰到一个或多个不再隶属于组织的用户账号。在极端情况下,组织可能会发现几个月前离开的用户仍具有特权。这些账户在我们的网络上不受约束地存在着,使对于们拥有了成为看似合法用户的有力手段,也使得我们检测和击退他们的工作变得更困难。

有多种原因会导致账户可能会变得不再必要,因此需要予以暂停,其中最常见的一种情况是:该账号的用户被解雇了或以其他方式离开了组织。其他暂停的原因还包括:达到了账户的默认失效期,以及临时的、但需延期的雇员缺勤(例如产假、军事部署)。无论什么原因,我们必须确保暂停那些不在组织内被使用的账户,直到该人员返回或我们保留策略的条款被满足为止。

要测试己暂停账户的管理控制,可遵循前两节中己经阐述过的相同模式:查看每个账户(或获取所有账户的代表性示例),并根据人力资源的记录将这些与其所有者的状态进行比较。或者,可获取一个临时或永久离开组织的员工名单,并检查这些账户的状态。严格按照数据保留策略去删除账户是非常重要的。当然管理员过早删除用户账号和/或文件,会对己离职员工的许多调查造成阻碍。

3.2 备份验证

磁带降级为其备份的备份。组织每天将其用户和企业的数据备份到存储区域网络(Storage Area Network,SAN),并且每周将这些备份再次备份到磁带的做法并不罕见。显然,每种备份的频率(每小时、每天、每周)由风险管理流程所驱动。

无论采用何种组织数据的备份方法,我们都需要定期测试,以确保备份在我们需要时能按预定方式运行。一些遭受过事故或灾难的组织会被要求从备份中恢复一些(或所有)数据,以提前发现备份的丢失、损坏或过期。

不要将数据备份到存放原始数据的同一设备上。

1. 数据类型

并非所有的数据都是被同等创建的,而且不同类型的数据在备份时可能有独特的要求。下面讨论的是我们大多数人所处理的一些主要数据类别, 以及在计划保留这些数据时的一些注意事项。记住,其实还有许多其他类型的数据,我们只是为了简洁起见,未在这里讨论而己。

用户数据文件这是我们大多数人熟悉的数据类型。这些包括我们每天所创建或使用的文档、演示文稿和电子表格。虽然备份这些文件可能看起来很简单,但当用户将“备份”副本放在多个位置以妥善保存时,挑战就出现了。如果用户留在自己的设备上,则可能导致保留文件的不一致,甚至可能违反保留的要求。这种类型的数据所存在挑战是:确保根据所有适用的政策、法规和法律得以持续备份。

数据库数据库与常规文件不同,它们通常将整个数据库存储在具有专用文件系统的文件中。为理解这个嵌入式文件系统,你的数据库软件使用驻留在系统中其他文件中的元数据。此架构可在数据库服务器上的文件之间创建复杂的依赖关系。幸运的是,所有主要的数据库管理系统(Database Managemen Systems,DBMS)都包括一个或多个备份其数据库的方法。但是,要确保其备份足以在必要时能够重建数据库却是一个挑战。为验证备份,许多组织定期使用一台测试数据库的服务器,来验证数据库能否从备份中恢复,以及能否从恢复的数据中正确地执行查询。

邮箱数据据估计,在一般组织里有高达75%的数据存在于邮箱中。根据你所运行的邮件系统的不同,备份过程可能有很大差异。然而,所有平台中都存在一些共同点,例如:在邮件服务器配置的每个方面都需要记录细节。多数大型或中型组织都有多个邮件服务器(可能互为备份),因此最好不要同时备份它们。最后,你为邮件服务器设置的任何适当的备份机制都应该有助于电子发现的合规性。

使用虚拟机(Virtual Machine,VM)快照作为一种备份策略。这种方法的主要优点是其恢复几乎是即时的。通常你只需要点击按钮或发出脚本化的命令,然后VM将其恢复到指定状态。另一个重要优点是该方法适用于与其他安全系统的自动化集成。例如由于用户点击一个链接而使工作站被攻破,进而被入侵检测系统(Intrusion Detection System,IDS)检测到了该事件,那么VM可以被立即隔离以供后续分析,同时在影响生产效率最小的情况下,将该用户行为自动放入最近的快照里。

测试数据备份

•开发各种场景,以捕获那些代表组织所面临威胁的特定事件集。

•制定计划,测试每个场景中所有关键任务的数据备份。

•利用自动化,以最小化审计师所需的工作量,并确保定期进行测试。

•最小化数据备份测试计划对业务流程的影响,以便其可以被定期执行。

•确保覆盖面,以便测试每个系统,虽然那不一定在同一测试中。

•记录各种结果,以使你能知晓什么是有效的,而什么是需要加强的。

•修复或改进你记录的任何问题。

3.3 灾难恢复和业务连续性

1.测试和修订业务连续性计划

BCP的维护应成为变更管理程序的一部分。这样,环境中的任何变化都能反映在计划本身上。

测试和灾难恢复演练应当至少每年进行一次。在一个制定好的计划没有实际测试之前,公司不应该对其真正抱有信心。测试和演练帮助员工为可能面对的情况做好准备,使得他们了解自己应该完成的任务。这些测试和演练还能指出计划团队和管理层事先没有考虑和解决的一些问题,并在规划过程中加以解决。最后,这些演练可论证公司能否从灾难中恢复过来。

演练应当具有一个事先设定的场景,这个场景是公司某天可能真正面对的。在开始演练之前,应该确定特定的参数和演练范围。测试团队必须在测试内容与如何合理决定成功与否方面达成一致。同样需要达成一致的还有测试的时间安排和持续时间、参加测试的人员、谁将接受何种指派以及需要采取的步骤。此外,测试团队还需要确定硬件、软件、人员、程序和通信线路是否要接受测试,是测试它们中的一些、全部还是一部分。如果在测试过程中要将一些设备转移到备用站点,还必须解决和评估运输问题、额外的设备以及备用场所的准备就绪情况。

灾难发生后,电话服务可能无法使用。为能够进行通信,应当准备备用方法,如移动电话或无线电台。

核查性测试 在这种测试中,BCP的副本被分发至不同的部门和职能区域接受审查。这样做是为了使每个职能经理都能对计划进行审核,指出是否有遗漏项,或者某些方法是否应当修改或删除。这种方法能确保不会遗忘或忽略一些问题。一旦各部门完成审核并提出建议,计划团队就将这些变化整合到主计划中

核查性测试也称为桌面检验测试

结构化的排练性测试 在这种测试中,各部门或职能区域的代表聚在一起对计划进行检查,以保证它的准确性。代表们审查计划的目标,讨论计划的作用范围和设想,检查组织和报告结构,并评估计划所描述的测试、维护和培训要求。这为那些负责保证灾难恢复快速高效进行的人员提供了一个机会,使他们能检查己经决定的内容与他们必须完成的任务。这些代表从头至尾将计划的不同场景演练一次,保证没有遗漏任何项。这也提高了团队成员对恢复程序的认识。

模拟测试 这种测试需要制定更多计划,参与的人也更多。在模拟测试中,所有操作和支持职能部门的员工或他们的代表集中起来,根据一个特定的场景练习执行灾难恢复计划。这个场景用于测试每个操作和支持部门代表的反应。此外,这样做还可以保证不会遗漏特殊的步骤或忽略某些威胁。它就像催化剂一样,能提高所有参与人员的意识。为模拟一个更现实的环境,这种测试仅使用那些在实际灾难中可供利用的材料。这种模拟测试可延伸到异地设施的实际重新部署阶段和替代设施的运输阶段。

并行测试 并行测试用于确保特定系统在异地备用设施中能充分发挥其功能。某些系统需要移动到备用场所并开始进行处理。处理的结果和原场所进行的正常处理结果进行比较,这样就可以指出任何必要的调整或重新进行配置。

全中断测试 这种测试对公司的正常操作和业务生产干扰最大。在测试过程中,实际上要将原始站点关闭并将业务处理转移到备用站点完成。恢复团队要履行他们的职责,为备用站点准备好系统和环境。所有处理都将在异地备用设施的设备上进行。

这是一种完全展开的演练,需要进行大量的计划和协调工作,但它可以揭示计划中存在的真正灾难发生之前需要修补的许多漏洞。全中断测试应在所有类型的测试都己成功完成后再执行。它们的风险最高,如果管理不当,会对公司业务造成非常严重的破坏。因此,进行全中断测试需要获得高级管理层的批准。

在每种测试的过程中以及测试之后,需要记录值得注意的事件,并将其提交给管理层,以使他们能够了解测试的结果。

应急响应 通常,对紧急事件的最初响应会影响到最终结果。应急响应程序是制定好的行动计划,用于帮助人们在危急情况下更好地应付遭到的破坏。在处理危急情形时,这是第一道防线。

那些对灾难恢复知识十分熟悉并了解最新进展的人们总会表现得最好,这就是我们重视培训和演练的原因。紧急事件总是无法预知的,因此没有人真正知道什么时候他们会被召集起来执行任务。

对生命的保护是至关重要的,因此在抢救物品之前应该先抢救人。应当通过培训和演练向负责人说明如何疏散人群。所有人员也应该知道指定的紧急出口和目的地。紧急、集中地点应当考虑到季节性气候因素。一般情况下,每个小组应指定一个人负责疏散所有人员,还需要有一个人专门负责通知相关机构:警察局、保安人员、消防队、紧急救援部门和管理层。经过适当的培训,员工就能更好地处理紧急情况,而不是只顾着逃生。

如果出现的情况不会危及生命,就应按顺序关闭系统,并在疏散时带走关键的数据文件或资源以及贵重的个人物品(如钱包和皮夹)。这就是要按顺序采取行动的原因。与所有过程一样,我们所做的每件事之间都存在依赖关系。省略或添加一些步骤实际可能造成更大伤害,而不是带来好处。

一旦事态平稳下来,这时很可能需要一个或几个人与外界实体打交道,如新闻界、客户、股东和民事官员。这个人(或这些人)应当回顾刚发生的灾难,以便能够统一回应,即对事件进行合理解释:公司如何应对这场灾难,客户和其他人应对公司有什么期待。公司应该立即向外界提供这些信息,而不是让外界随意下结论并散布不利的流言。公司应当至少指定一个人与新闻界交涉,以保证他们发布正面消息。

此外,在紧急事件发生之前需要优先处理一些恶意行为:在物理逻辑层面上的潜在抢劫、故意破坏和欺诈行为。公司在经历一场大规模动乱或灾难之后往往最容易遭受攻击,其他人可能会利用这种脆弱性。公司需要仔细进行考虑和计划,以便对这些问题进行合理处理,并随时提供必要的和预期的保护。

2.维护计划

然而,本章中讨论的各种计划也许很快就会过时。过时的业务连续性计划可能在公司中建立一种错误的安全感,如果灾难确实发生,那么可能造成破坏性后果。

计划过时的主要原因如下:

• 业务连续性过程没有整合到变更管理过程。

• 基础设施和环境发生变化。

• 公司进行过重组、裁员或合并。

• 硬件、软件和应用程序发生变化。

• 制定计划后,人们认为没必要再做其他工作。

• 人员发生更换。

• 大型计划要进行许多维护工作。

• 计划并不直接带来利润。

组织机构能采用下列动作使计划保持更新:

• 使业务连续性成为每个业务决策的一部分。

• 将维护责任整合到职位描述中。

• 将维护工作表现包含在个人评估中。

• 执行包括灾难恢复、连续性文档与措施的内部审计。

• 进行应用计划的常规演习。

• 将BCP整合到当前的变更管理过程中。

• 将从实际事故中得到的教训整合到计划中。

将计划整合到组织机构的变更管理过程,这是一种使计划保持最合算和最高效的最简单方法。

3. BCP生命周期

多数组织都不是静止的,而是不断快速变化的,组织运营的环境也是如此。所以,DRP和BCP都具有生命周期,需要应对那些不断出现的、不可避免的影响到组织的变化。

3.4 安全培训和安全意识培训

安全培训是讲授一种或一组技能的过程,这将允许人们更好地执行特定的职能。安全意识培训是让人们了解安全问题,以使他们能更好地识别并响应问题的过程。安全培训通常是提供给安全人员,而安全意识培训应该提供给组织的每个成员。

由于培训能与特定的安全功能相关联,因此评估安全培训计划的有效性可以相当直接。为测试培训计划的有效性,我们所要做的就是对比个体在各个职能上培训前后的绩效。如果绩效提高,那么培训就可能是有效的。记住,技能会随着时间的推移而衰退,所以培训的有效性应该在其结束后立即被衡量。否则,我们所评估到的只是一些长期滞后的功能性技能。

现在让我们将注意力转向更困难的评估:安全意识培训方案的有效性问题。当我们提出这个问题时,请记住,最终状态是使我们的队友能更好地识别和处理安全问题。这意味着安全意识计划有效性的一个关键衡量方法就是:人们在面对某些情况时,他们行为改变的程度。如果这种变化是朝着更好的安全态势发展,那么我们可以推断出整体计划是有效的

1.社会工程

在信息安全环境中,社会工程是操纵个人,以便他们执行那些违反安全协议的行为的过程。无论该行为是泄露密码,让某人进入建筑物,还是简单地点击链接,这些都由对于所精心设计,以帮助他们能利用我们的信息系统。一种常见的误解是认为社会工程是一种即兴艺术。虽然即兴动作可以帮助攻击者更好地应对挑战,但事实上,最有效的社会工程是针对特定目标(通常是特定的个人)煞费苦心设计出来的。

最流行的社会工程形式也许就是网络钓鱼了,这是通过数字通信进行的社会工程。就像将带有诱饵的钓鱼线投入满是小鱼的池塘中一样,网络钓鱼依赖的是:如果有足够多的人接收到诱人的或可信的消息,至少有一个人将点击其中的嵌入链接。

一些对于针对特定个人或群体的情况,被称为鱼叉式网络钓鱼。某些情况下,目标是高级管理人员的被称为捕鲸。无论何种类型,网络钓鱼的预期结果几乎总是让目标点击一个会把他们带到一个由攻击者所控制的网站链接。有时,该网站看起来像一个受信任网站(例如用户的银行)的合法登录页面。而其他时候,该网站虽是合法的,但早已被攻击者所攻陷,而且会将用户重定向到其他地方。在自动下载的情况下,网站无形中会将用户重定向到恶意软件的分发服务器上

冒充是社会工程的一种形式,通常是攻击者创造一个可信的场景,亲自或通过电话的方式努力说服目标去违反安全策略。一个常见的例子是以(自称)客服或银行反欺诈部门的名义打来电话,攻击者试图使目标暴露其账号、个人识别号(PIN)、密码或一些类似的有价值信息。值得注意的是,在2007年之前,只要不是用于获取财务记录,冒充行为在美国是合法的。2006年,惠普陷入过一个丑闻,即通过使用冒充的手段,以确定其董事会信息泄露的来源。美国国会于2006年通过了“电话记录和隐私保护法”,对任何使用冒充方式来获取机密信息的人施以严厉的刑事处罚

如何着手评估那些旨在打击所有形式的社会工程的安全意识计划呢?其中一种方法是跟踪用户在意识培训练前后,成为此类攻击受害者的次数。这种方法的挑战是:受害者可能不会自愿承认败给过这些伎俩,我们的安全系统也肯定不会检测到所有成功的攻击案例。另一种方法是让审计师(内部或外部)对我们的用户进行良性的社会工程活动。当用户点击由审计师插入的链接时,其错误的行为会被警告,并可能会被重定向到一个网页或短视频,用以阐述未来如何能避免此类错误。一直以来,我们的自动化系统都在密切注意着哪些用户最容易受到影响,以及这些攻击得逞的频率。坊间有个建议:如果有一组用户不愿参加纠正式培训的话,那么领导层就有理由处理这些反复做错选择的人。

2.上网安全

通常不必诱骗用户去做错事,他们会自愿地沿着那条路走。这通常是不明风险的结果,而对这种无知的补救恰好是安全意识活动的全部。有效的安全意识计划应该包括那些与代表组织风险的不安全在线行为相关的各种问题。

上网安全行为的最重要元素之一就是正确地使用社交媒体。一个好的起点源自正确地使用隐私设置,特别是要考虑到:所有主要的社交媒体网站都有限制与谁共享何种信息的各种设置方法。默认设置并不总是专注于隐私保护,因此用户了解其选项很是重要的。而这在用户发布那些涉及他们工作场所的信息时,就变得更重要了。安全意识计划的一部分应该包括教育用户:如果他们的帖子暴露了敏感信息,则可能给其雇主造成风险。信息一旦发布就不能被召回,它们就永远留在那里了。

有时威胁并非是信息流出到互联网上,而是由于用户的好奇招致的。用户仅浏览了恶意网站(特别是在工作场所的计算机上),都很可能使整个公司陷入瘫痪。自动下载是一种只需要访问恶意网站即可触发的自动攻击。虽然它们的机制会有所不同,但其效果都是在客户端计算机上执行需要或者不需要用户额外交互的恶意软件。虽然网络过滤器可以减缓一些浏览不适当网站的风险,但对于一些本来合法却已被黑掉的网站,这意味着过滤器也可能无效了。

3.数据保护

值得重申的是无论是静止的还是在传输中,所有敏感数据都必须总是被加密。由于用户完全可以规避控制并使数据不受保护,因此安全意识是防止此类行为的关键。未加密的数据如果存储在未授权的在线资源中或有意(但可能不是恶意地)与其他人共享,则容易受到泄露的影响。当敏感数据不再被需要,并且超出强制保留期时,应当将其适当地销毁。

要测试用户了解数据保护要求和最佳实践的程度,最好通过在文件的元数据中使用标签来完成。信息分类标签成为跟踪数据位置的有效手段。类似地,数据丢失防护(Data Loss Prevention,DLP)解决方案有助于阻止泄露和识别恶意或无意地暴露敏感信息的个人。这使得我们能够针对此类用户进行额外的意识培训,或采取纪律处分。

4.文化

最后,测试一个组织在安全意识方面的最好方法就是评估其安全文化。我们是否有这样的环境,使用户能安心地进行自我报告呢?他们此举是否被很好地激励了?他们在遇到奇怪或可疑情况时是否积极地寻求信息和指导?用户的自我报告和信息请求体现了组织文化是否会帮助或阻碍我们保护的系统,这是一个很好的指标。

3.5 关键绩效和风险指标

关键绩效指标(Key Performance Indicators,KPI)和关键风险指标(Key Risk Indicators,KRI)。 KPI衡量目前情况的进展程度,而KRI衡量的是未来情况会差到什么程度。

1. 关键绩效指标

试图运行一个没有充分度量标准的信息安全管理系统(Information SecurityManagement System,ISMS)可能比根本不去管理安全更危险。其原因是:就像跟随错误的路径指示一样,使用错误的度量可能导致组织走向错误的路径,并导致比把所有机会都置于眼前更差的结果。幸运的是,国际标准化组织(International Organization for Standardization,ISO)己经发布了一个行业标准,用于开发和衡量安全计划有效性。标题为“信息安全测量实施”的ISO27004概述了衡量安全控制和过程性能的流程。请记住,该标准的一个关键目的就是支持持续改进组织的安全态势。

在这一点上,定义一些术语将是非常有帮助的:

• 因子 ISMS的一个属性,可以描述为一个随时间变化的值。因子的示例是IDS生成的警报的数量或事件响应(Incident Response,IR)团队所调查事件的数量。

 测量 在一个特定时间点上因子的值。换句话说,这是一个原始数据。两个有关测量的例子分别是:最近24小时内的IDS产生的356个警报,以及IR团队在1月份调查的42个被证实的事件。

• 基线 一个因子的任意值,它提供一个参考点,或表示达到某个阙值后满足了某个条件。例如,基线可以是过去12个月中的IDS警报数量的历史趋势(一条参考线),或是IR团队将调查任何给定月份中的小子或等于100个事件( 阙值)的目标。

• 度量标准 通过在多个测量之间,或与基准进行比较而生成的派生值。度量本身就具有比较性。基于前面的例子,有效的度量标准可以是30天周期内IDS警报中被证实的事件比率。

• 指标 描述ISMS的某些有效性的一个或多个测量的解释。换句话说,指标对管理层来说是有意义的。如果管理层的目标之一是:调整组织的“传感器”,以便降低错误率(从而更有效地利用其IR团队),则指标可以在一个报告周期内用绿色交通灯来表示阙值比率不超过30%的假性(或未被IDS检测到的)事件。

根据上述定义,关键绩效指标(Key Performance Indicator,KPI)是显示ISMS绩效方面特别重要的指标。各种KPI都精选自更大的指标池它概括显示了我们的ISMS是否能跟上对于组织的潜在威胁,或显示了在降低威胁方面的有效性。KRI应该能被业务和技术人员方便地理解,并应该与组织的一个或多个目标相一致。

我们选择KPI的过程是由组织的目标所驱动的。理想情况下,高级领导层为组织的安全设定(或批准)目标。然后,ISMS团队致力于厘清我们是在迈向、还是远离这些目标的。该过程可以总结为如下方面:

(1)选择可以显示安全状态的因素。为此,我们要在数据源的总量和获取所有数据所需的资源之间取得平衡。

(2)定义所考虑的一些或所有因子的基线。我们在这样做时,考虑哪些测量将用来相互比较,和哪些将用作基线是非常重要的。请记住,给定的基线可应用于多个因子的测量。

(3)制定一个计划,定期捕获这些因子的值,并固定其抽样的周期。理想情况下,我们使用自动化方法来收集数据,以确保此过程的周期性和一致性。

(4)分析和解析数据。虽然一些分析可以(并且可能应该)是自动化的,但仍存在需要人工干预的情况。某些情况下,我们能通过表面值直接获取数据,而在其他情况下,我们必须深入挖掘并获得更多信息,然后才能得出结论。

(5)将各项指标传达给所有利益相关者。最后,我们需要以一种能被广大利益相关者理解的方式整理发现的结果。一种常见的方法是:从非技术性摘要开始,该摘要将逐渐递进的支持性技术信息作为支撑。在这个摘要里,我们选择并放置自己的KPI。

前面的过程和定义并非通用,却代表了业务上的一些最佳实践。最后,KPI是“蒸馆”了大量信息的产物,其目的是回答一个具体问题:我们是否足够好地管理信息安全?世间没有所谓完美的安全,因此我们真正要努力做到的是找到一个最佳位置,使得ISMS能够可持续地使用可接受数量的资源。显然,鉴于不断变化的威胁和风险的格局,这一点是一个可移动的目标。

2.主要风险指标

尽管KPI能告诉我们当前相对于目标的位置,而关键风险指标(Key Risk Indicators,KRI)能告诉我们的是当前与风险偏好的关系。它们衡量一项活动的风险值,以便领导层能够对该活动做出明智的决定,同时也考虑到潜在的资源损失。与KPI一样,KRI是在组织中由高级领导层根据决策的影响而选择的。这意味着KRI通常不会特定于一个部门或业务职能,而会影响组织的多个方面。根据定义,KRI对业务的影响非常高。

在考虑KRI时,将它们与单一损失预期SingleLoss Expectancy,SLE)方程相关联是非常有用的。如果特定的威胁一旦出现,SLE就是该组织潜在的货币损失。它是损失和成胁发生可能性的乘积。换句话说,如果我们有一个建材专用的流程,其价值为50万美元,而我们估计攻击者偷窃并通过该流程赚钱的概率为5%,那么我们的SLE将是25000美元。很明显,5%的数字会受到组织内各种活动的影响,例如IDS的调优、IR团队的熟练程度和最终用户的安全意识。

随着时间的推移,威胁被发现的可能性将根据组织内的多个活动而改变。随着该数值的变化,风险也随着改变。当我们超过了一个阙值,使得当前活动对于规定风险偏好的风险太大时,KRI将会捕捉到,并提醒我们注意。此触发条件使得组织能变更其行为,以弥补过度的风险。例如,它可能促使组织停下来,进行安全意识培训。

最后,关于KRI要重点记住的是:它们要被设计得如矿井里的金丝雀一般,当坏的情况可能发生时能够警告我们,以使我们可以改变行为和击败威胁。

4 报告

4.1 技术报告

技术报告应该比自动扫描工具的输出(或带有“是/否”勾选框的清单)具有更多内容。有太多的所谓审计师,只是按下扫描工具上的启动按钮,等待其完成工作,然后打印出根本没有任何定制或分析的报告。技术报告应该是针对被研究系统(System Under Study,SUS)具体情况的标准方法论的应用。换句话说,报告必须表明这是一个定制的审计。它必须记录所使用的方法论、根据SUS定制的方式、结果、所建议的控制或更改。原始数据和自动报告应该提供在附录中。最重要的是:报告应该说明组织的风险状况。

以下是一份好的技术审计报告所需的各种要素:

•威胁,风险管理过程(Risk ManagementProcess,RMP)详细描述了组织确定威胁的方式。所以报告应考虑这些威胁,以便与RMP保持一致。

•漏洞 这些与威胁有关,我们与其跟踪任何威胁无法利用的漏洞,还不如跟踪那些可利用的漏洞。漏洞所处的环境比其存在性更重要。

•利用的可能性 一个漏洞经常会被我们所跟踪的各种威胁在其他地方利用。如果我们不对其采取措施,它们同样会对我们的组织造成影响。为确定工作的优先级并更好地评估成功利用带来的影响,确定它们的可能性是非常重要的。

•利用后的影响 这通常用货币数值来表示,以便更好地符合我们的RMP。

•建议措施 这些是针对漏洞所采取的步骤,从而减少利用的概率和/或影响。

你始终要注意那些看似自动生成的报告,因为它们通常能反映出一个无效的审计团队。你还要小心那些没有找到任何重大漏洞,却过分强调不重要缺陷的报告。如果组织的安全态势确实良好,那么审计师要毫不避讳地说出来。

4.2 执行摘要

撰写具有影响力的报告的下一步是:将重要的发现和建议转化为对组织高级领导层来说可以理解且有意义的语言。毕竟,他们的支持将允许你实施必要的变更。他们将提供你所需要的权威和资源。

通常,技术报告(及其他内容)包括不超过一页或两页的执行摘要,这样能突出那些高级领导层需要从报告中了解的内容。而其目标是获得他们的注意,并产生所需的改变。获得业务领导关注的一个方法是根据风险暴露来解释审计的发现。安全几乎总是被视为业务的成本中心。因此对于不产生利润的部门来说,显示投资回报率(Return On Investment,ROI)的好方法是:用具体金额来量化那些被推荐的可能挽救公司的变更。

一种量化风险的方法是用货币数值来表示。我们可以认为:风险(以美元计)是资产的价值乘以该资产损失的概率。换句话说,如果我们客户数据的价值是100万美元,并且这些数据有10%的机会被泄露,那么该数据泄露的风险将是100000美元。我们如何能够得出这些数值呢?虽然会计师会有不同的方法去估值各种资产,但以下的方法最为常见。

•成本法仅考虑获取或更换资产的成本。这是我们通常用来评估IT资产的方法(当然要减去信息)。那么如何将其应用到信息呢?例如某个信息资产是一个包含威胁情报报告的文件,其对组织的价值是10000美元,则成本法将该数值附加到其资产中。

•收入法考虑的是资产对公司收入流的预期贡献。一般公式是价值等于预期(或潜在)收入除以资本化率。资本化率为实际净收入除以资产价值。因此,假设这个1万美元的威胁情报报告在去年带来了1000美元的净收入(所以资本化率为0.10),且我们预测今年将带来2000美元,那么其现值将是2000美元÷0.10或$20000。正如你能看到的,这种方法的优点是它考虑了过去和预期的业务情况。

•市场法是基于确定其他公司在市场上为类似资产所支付的费用。前提是其他组织在行为上有相当大的透明度。例如,如果我们无法知道其他人为这个威胁情报报告支付了多少费用,我们就不能使用市场法来估价。另一方面,如果我们能发现该报告的现行市场价格实际上是12000美元,那么我们可使用该数值来表示它(资产),并庆祝我们能够如此划算。

因此,只要我们所提出的控制措施的生命周期成本(如180000美元)低于其所减缓的风险。(1000000美元),那么显然我们应该实施该控制,对吗?答案是:不完全如此。其控制毕竟不是完美的。它们不能完全地消除风险,有时甚至还会失败。这就意味着我们需要知道控制在阻止攻击时有效的可能性。比如说,我们正在考虑一个己被证明其约80%的时间有效,且成本为18万美元的解决方案。我们知道会有10%的被攻击可能,而且有20%的机会发生我们的控制无法保护的情况。

这就意味着剩余的风险是100万美元的2%,即2万美元。然后将其加上我们的控制成本(180000美元),得到了我们的总有效成本为200000美元。

这是一些在与高级领导交往时颇具影响力的内容。他们想知道这些问题的答案:它有多大的运作可能性?它会挽救我们多少?它要花费多少钱?可见,技术细节对ISMS团队有着直接重要性,但对企业领导层却只有间接重要性。

5 管理评审

管理评审是高级组织领导层的正式会议,用于确定管理系统是否有效地实现其目标。

这些标准定义了一个计划,执行“检查”处理的循环。计划阶段是我们在ISMS中所要做的一切事情的基础,因为它决定了我们的目标,并驱动着我们的政策。循环中的执行阶段覆盖了多个地方。最后,处理阶段是我们在管理评审中正式去做的。我们会评审从前面阶段得到的所有信息,决定我们是否需要调整目标、标准或政策,以不断改善安全态势。

管理层的审查,无疑看的是大局,以帮助设定前进的战略。因此,一个运行良好的审查不会将非常具体的技术主题卷入详细的讨论中。相反,它将对组织进行全面观察,并做出战略决策,这就是管理评审必须包括组织中所有关键决策者的主要原因。这种高级别的参与方式给予ISMS合法性和权力。

与高级管理层沟通时,请务必使用业务语言,并以简洁的方式说出。如果我们不能在第一次尝试中清楚和迅速地领会高级领导层的关注点,我们可能就不会再有机会这样做了。

5.1 管理评审前

管理评审应该定期进行。管理系统和/或组织越不成熟,这些审查应该越频繁。显然,计划期间的一个制约因素就是关键领导资源的可获取性。这种周期性将有助于确保整个组织制定并输出高级决策过程的可操作性“节奏”。如果缺乏这种规律性,审查就会有陷入被动的风险。

会议的频率也应该与执行前一次评审决定所需的时长同步。例如,如果领导层决定用一整年的时间开发、整合和测量全面的改变,那么在年度结束之前进行审查,可能就不会特别有效。如果此类评审太过频繁,管理层将无法根据所呈报的前期处理结果做出新决定。

5.2 审查输入

各种来源将产生管理评审的输入。一个主要的输入是内、外部相关的审计结果。除了提供审计报告以供评审外,还有必要生成描述各种关键发现、对组织的影响和建议性变更的执行摘要。请记住用商业语言来写这些摘要。

评审的另一个重要输入是前一次管理评审的未决问题和执行项目的清单。理想情况下,所有这些问题应己得到解决,所有执行都已完成和验证。如果不是这样的话,突出任何阻止它们完成的问题(例如资源、法规、环境的变化)是很重要的。高级领导层通常不喜欢惊奇(特别是那些不愉快的),因此在评审正式召开之前应该明智地向他们提醒任何未完成的事项。

除了审计师和执行人员的反馈,客户的反馈也是管理评审的一个重要输入。实际上,几乎每个组织都有客户,而且他们通常是组织存在的首要原因。他们满意与否,对于组织的成功至关重要。真实用户监控(Real User Monitoring,RUM)是作为衡量他们与信息系统交互的一种方式。组织也越来越依靠社交媒体的分析来衡量客户对组织一般情况和具体问题的感受。最后,我们可使用问卷或调查,虽然这些往往会产生答复率低和受访者有负面偏见之类的挑战。

管理评审的最终输入是基于所有其他输入的改进建议。而这的确是评审的关键。虽然在技术上评审不会包括任何实质性的变更建议,但如果它意味着ISMS团队不能想出任何方式来改善组织态势,那将是十分异常的。ISMS团队提出的任何建议性高级变更都需要高级领导层的批准和/或支持。我们要求更改的是关键策略或其他资源。这些建议必须在逻辑上由提交给审查小组的其他输入产生。

在高级领导层的决策过程阶段,向他们提供一系列选项通常是非常有用的。根据问题的复杂性,许多安全专业人员通常会提供三到五种选择。例如,一种选项可以是“不做任何操作”,它描述了如果没有做出改变将发生什么。另一方面,我们可列出一种相当于“纯金”方法的选项,即我们大胆地叫停所有,并付出高昂的变化代价,但可以保证顾及所有方面的问题。而在这两者之间,我们也可提供一到三种具有各种风险级别、资源要求和商业吸引力的其他选择。

当提出各种选项时,我们还应该提供客观的评价标准,以供管理层考虑。在各种提案中几乎总会用到的一个标准是:变更的货币成本。这个因素应该是选项的整个生命周期的成本,而不仅是执行成本。忽略系统/过程在整个生命周期中的维护成本是一种常见错误,这些被忽视的成本通常远大于购置的价格。你可能需要考虑的其他因素还包括:风险、对于现有系统或过程的影响、各种培训的需求和复杂性。但是,无论你选择什么样的评价性因素,你都应该将它们应用到每个选项,以评估哪个才是最好的。

5.3 管理层的行动

高级领导层在考虑所有投入时,通常会问及一些相当尖锐的问题,然后决定批准、拒绝或推迟建议。此时的辩论或讨论的数量,通常能有效地反映ISMS团队提出的那些能够嵌入(和支持)业务流程的合理变更论证的有效性。显然,领导的决定最终证明了ISMS团队的建议有多少说服力。

通常,高级管理层将做出几种决定:接受整个建议、接受但需要进行具体修改、拒绝建议、发回给ISMS小组以获得更多支持数据、重新设计选项。不管结果如何,总会有一份下一次管理评审将要提及的可交付成果的列表。我们最好用开放的、有行动项的综述去总结管理评审,包括谁将处理它们,以及分别是何时到期。这些都将成为下一次管理评审的输入,并且周期性地无限持续下去。


专注于渗透测试培训,咨询,提供行业顶级安全证书的培训,CEH,OSCP, PenTest+ 等,关注微信,公众号获取更多信息

网络安全培训|渗透测试|道德黑客CEH|OSCP培训|DevOps,SCRUM培训网络安全培训|渗透测试|道德黑客CEH|OSCP培训|DevOps,SCRUM培训