软件项目风险减轻采用的方法
云服务安全策略专注于云安全的不同方面,具体取决于您所指的交付模型方案— SaaS,PaaS或IaaS:
本文简要介绍了云服务安全性问题的重要方面,然后介绍了作为风险评估程序一部分的缓解风险。
云服务安全可能受到以下威胁:
让我们更详细地看看每个。
所有云服务类型都在基础虚拟机管理程序之上的虚拟机上运行,该虚拟机管理程序允许多个操作系统共享单个硬件主机。 不同信任级别的参与者(用户,租户和云管理员)可以访问它们。 例如,租户可能具有1000个用户的许可协议,以访问某些作为服务的软件。
当虚拟机管理程序出现故障或受到威胁时,所有实例资源和数据请求队列都会受到威胁。 它们可能会恶意影响阈值策略[ 详细信息 ],这些阈值策略用于在工作负载需求激增期间监视实例资源和数据请求队列的消耗。 内部虚拟网络上用于在虚拟机之间进行通信的控件不够明显,无法实施安全策略。 虚拟机的网络和安全控制职责可能无法很好地分开。
黑客可以成为具有管理控制权的高特权用户,然后脱离虚拟机,然后在管理程序上执行恶意程序。 例如,他可能访问目录文件,并恶意将实例资源重新分配给另一个虚拟机。 他可能导致将同一虚拟机上的租户之间的存储,内存,路由和信誉分开的机制出现故障。
黑客可以从尚未从虚拟机中重新分配的实例资源清除的残留数据中窃取敏感信息。 黑客可以使用有缺陷的管理程序来识别运行状况良好的虚拟机的邻居并监视其活动。 他可以进入邻居的虚拟机,并向PaaS应用程序添加恶意代码。
最终用户应在建立关系之前评估服务提供商的安全策略。 您需要将云计算的安全状况与本地环境进行比较,并确保安全策略中不会缺少云中的实例资源,用户和数据请求阈值策略。
资源阈值策略在监视工作负载需求高峰期间如何消耗额外的实例资源时很有用。 用户阈值策略检查有多少用户同时登录和注销云服务类型,以及它们是否接近许可证中指定的最大用户数。
不制定这些政策存在风险:
负载平衡用于分配实例资源和数据请求。 例如,每个实例资源应最多加载其容量的50%,这样,如果一个实例发生故障,则正常的实例资源将从发生故障的资源实例中接管业务事务。
每个队列都应加载高达队列容量的50%的数据请求,以使一个队列发生故障,健康的队列将接管最初发往故障队列的数据请求。
当实例资源的负载平衡被虚拟机中的恶意软件应用恶意破坏时,它可能导致这些资源泛滥,恶意交易将每个资源的容量填满至其容量的100%。
将业务事务从失败的资源实例转移到正常的资源实例是不可能的。 膨胀的负载平衡不能用于实现故障转移机制,例如实例资源或负载共享冗余。
需要某种形式的加密来保护数据的机密性和完整性。 即使数据不是敏感数据或个人数据,在将数据传输到云中或在云中进行操作时,也应使用加密技术对其进行保护。
黑客可以利用密码分析或恶意实例资源的进步来使密码算法变得不安全。 他们可以在恶意修改密码算法以将强加密变成弱加密之前探测密码算法中的缺陷。
黑客可以通过找到最新版本的密码算法来走得更远,然后在自己的计算机上进行逆向工程以了解算法的工作原理。
以经济有效的方式,您可以通过应用安全控制来减轻风险,从而可以降低利用资产漏洞并导致实施威胁的可能性。
在尝试减轻风险之前,您需要确定要保护的资产。 最简单的风险评估方法是:
要记住的一个关键概念是,您可以循环浏览任何阶段的步骤,以合并以后添加或您不知道的变量。
首先确定资产-硬件,软件,网络组件,人员,用户,文档,设施; 直接属于云服务类型的那些资产和其他资产。 当您确定它们,尝试减轻风险并发现您已排除某些资产时,可以随时返回到第一步以更新资产清单,然后重复第二步。
如果在分析安全对策的第三步中发现某些风险尚未解决,则可以返回到第二步以将它们包括在内,并确定潜在的损失风险或威胁利用漏洞的每种风险的可能性。 您可以从第三步返回到第一步,以更新要保护的资产清单。
在第四步中,您会定期重新评估风险评估程序,该程序会受到新风险,具有成本效益的安全控制,新兴基础架构技术和新法规的影响。
让我们更详细地查看每个步骤。
云计算消费者和提供商都需要标识硬件和软件资产,并估算更换每种资产的成本。 他们应维护并定期更新资产清单,这些资产会因组织重组,更节能的技术,更好的故障转移机制以及有关跨辖区的数据隐私导出的新法规而改变。
从SaaS提供商那里租用服务时,消费者需要识别的硬件和软件资产的数量远远少于使用PaaS模型(更大程度地使用IaaS)进行控制的消费者。
现在,让我们看一下每种云服务类型需要识别哪些资产。
SaaS资产
由于云消费者唯一的控制权是从其台式机,笔记本电脑或移动设备访问应用程序,因此他需要识别的资产是移动设备操作系统,应用程序和默认程序。 因此,将设备资产的清单限制为与SaaS一起使用的程序和应用程序很重要。 将个人使用的程序(例如下载的游戏)与在同一设备上访问SaaS所需的程序混合在一起不是一个好主意。
至少,以下资产应由云提供商控制:
消费者不负责识别它们。
PaaS资产
云消费者需要识别的资产是他可以控制的资产:平台整个业务生命周期中的所有应用程序(例如,电子表格,文字处理器,备份,计费,工资核算和发票)。
至少,以下资产应由PaaS设置中的云提供商控制:
云消费者不负责标识这些资产。
IaaS资产
云消费者需要识别的资产是他可以控制的资产:虚拟机级别的操作系统,网络设备和已部署的应用程序。 使用者可以向上或向下扩展实例资源和虚拟服务器或存储区域块的数量。
云消费者无法控制基础架构和底层组件。 提供者需要识别那些资产。
风险是威胁可能利用云服务漏洞的潜在损失或可能性。 如果没有成本有效的对策,则云服务很容易受到漏洞攻击,如果被利用,可能会引发威胁。
资产风险的潜在损失取决于风险对每种资产的影响(即,对于始终可供用户使用的文档资产而言,该风险为零或零;对于具有以下风险的云环境中的资源资产,其评估值为0.96):没有足够的对策)。 资产风险的潜在损失还取决于在一年的时间范围内威胁发生的频率。
如何利用漏洞
让我们看一个简单的示例,该示例说明黑客如何共同利用以下漏洞对实例资源的资产发起攻击。 漏洞包括:
良好的应用程序分为多个模块,这些模块相互交互以执行一个任务或一系列任务。 这使开发人员可以通过重用现有模块或添加新模块来将模块添加到应用程序中。 当应用程序缺少阈值模块(设置为低于实例资源的最大容量和另一个数据请求级别)时,使用者和提供者将无法知道实例资源或数据请求是否已达到最大容量。 他们不知道黑客是否在容纳正常虚拟机的同一台物理服务器上创建了恶意虚拟机,直到为时已晚(例如,直到发生拒绝服务攻击之后)。 黑客通过用恶意实例资源和恶意数据请求队列向恶意虚拟机的邻居泛洪来实现此目的。 他诱使受害者增加虚拟机的数量,直到虚拟机达到物理服务器的最大容量为止。
当先前分配的实例资源在重新分配给相同或不同用户之前没有完全清除数据时,会发生残留数据。 实例资源包括内存,缓存,进程,会话,阈值和存储资源。 黑客寻找内部实例资源来获取受害者的个人信息。
当在IaaS网络基础架构中无法运行在网络级别上的安全控件时,虚拟网络中的基于网络的控件不足。 这限制了授权管理员对基础结构的访问。 黑客利用了IaaS管理员无法在虚拟化网络中应用标准控件(例如基于IP的网络分区)这一事实。 IaaS提供程序可能不允许基于网络的漏洞扫描,因为它们无法将友好的网络扫描与攻击活动区分开。 还没有足够的控件来区分真实网络上的流量和虚拟网络(例如,同一服务器上虚拟机管理程序顶部的两个或多个虚拟机之间的通信)。
当提供者未充分监控黑客的恶意活动时,就会发生特权用户监控不足,该黑客已从虚拟机管理程序以具有管理访问控制权的特权用户的身份从虚拟机监控程序获得了对虚拟机的访问权限。 例如,具有此访问权限的黑客可以创建恶意实例资源和数据请求队列,而提供商不会注意到黑客在做什么。 另一个示例是从一个虚拟机的正常实例资源中恶意地将实例资源作为恶意实例资源重新分配给另一台虚拟机。
漏洞严重性的潜在排名
当然,您必须开发自己的系统或对不同类型的利用的损失潜力进行排名,但是我按以下优先级对各种利用的损失潜力进行排名:
例如,黑客可以伪装成具有管理访问控制权的特权用户,并执行合法系统管理员最初并未注意到的恶意活动。 黑客还可以通过发送SQL注入来查找文件名来进入,并可以在那些文件中查找剩余数据。
一旦进入虚拟机,就可以使用黑客工具以友好网络扫描的名义发起恶意网络扫描攻击活动。 攻击活动可以包括每个应用程序中的模块列表。 如果黑客发现此应用程序不包含阈值模块,则他可以使用或创建工具来创建实例资源,直到它们达到最大容量。
风险评估的下一步在概念上相对容易,并且与许多事情一样,在现实生活中会更加困难-找出减轻风险的对策是否具有成本效益,从而使收益高于实施对策的成本。 降低威胁利用漏洞的风险的可能性,并增加ROI。
接下来的一点很重要:如果发现对策不具成本效益,则残留风险仍然存在,并且这些风险无法缓解。 您需要学习与他们生活在一起,而不必花更多的钱在他们身上。 这是风险评估/缓解中最难接受的概念之一:某些风险的成本太高,无法抵消其提供的收益。
但是,如果残留风险 太多而成本效益的对策太少 ,则出于以下几个原因,您应该重复进行风险评估的步骤:
我在本文中提到的一些对策示例包括:
尽管应该每三年定期进行一次风险评估,但是如果出现以下情况,则可能需要更频繁地重新评估风险:
实际上,如果您负责组织的云服务的风险评估和缓解,则可能应该每周大约一次检查信息流以获取有关这些条件的信息。 考虑为新的威胁和漏洞建立新闻源。
要在保持高正常运行时间可用性的同时降低云服务风险,就需要进行积极的风险规划,以解决以下问题:针对每种云类型识别哪些资产,要分析哪些风险,哪些对策具有成本效益以及缓解风险后要进行评估。 您的开发人员,用户和业务分析师团队需要共同努力,以减少云服务的残留风险。 团队将发现解决这些问题使他们减轻云服务风险的工作变得更加容易。
翻译自: https://www.ibm.com/developerworks/cloud/library/cl-cloudservicerisks/index.html
软件项目风险减轻采用的方法