信息安全度量：什么是云要收集的

CISO需要知道云安全性能的真实数据。因为C级别的高管和董事会会一直问安全管理者风险暴露相关的问题——“我们需要多高级别的安全?我们距离满足合规要求还有多少距离?”——CISO们也在寻找能够高效度量基于战略目标的云控制的方式，并且汇报这些发现。

如果没有深入风险和花费，以及高官们实际关心的其他信息安全度量的仪表盘，那么怎么才能正确度量云上的安全运维呢?

缓慢但坚定地，IT部门正在调整安全控制(文档化的流程)和架构模型来适应公有和私有云环境里的信息系统。随着预防性的，检测性的和响应式的控制正在进入混合云模型，CISO们现在必须思考云里的管控以及新的信息安全度量标准，为了内部跟踪以及服务级别协议(SLA)。

有一些监控活动，信息安全度量基本上都在内部数据中心和云里。机会在于引入云环境的安全工具能够大量抓取相同的数据，并且提供目前收集的任何信息安全度量。比如，虚拟防火墙设备日志丢弃或者堵塞的连接;基于云的漏洞扫描能够报告基础架构即服务或者平台即服务系统的系统以及补丁和暴露的状态;基于主机的安全监控工具记录文件的访问和配置的变化。

新的InfoSec云度量

但，CISO必须更多地关注于云里的性能指标以及SLA相关的度量。这意味着安全团队需要研究能够收集到的和云安全(云运维)相关的新度量。如果自动化的预配和Chef，Puppet这样的编排工具一起工作，就能够收集到实例生成和态势评估的日志。事件则适用于管理活动，密码工具和秘钥使用及访问，以及被批准的配置的变形也能够被监控，从而确定云供应商的安全态势。重要的信息安全度量包括如下几种：

• 管理登入云供应商控制台的次数
• 云环境里超过特定时间一直不活跃的“孤儿”账号数量
• 启动系统数量vs运行超过定义时间的系统数量(也就是说，在一段时间之后仍然在运行的系统)
• 使用批准的配置的系统数量vs没有使用批准配置的系统数量

技术控制不足

安全资深管理还需要监控云供应商的合同义务，法律和供应链方面的都需要监控。在每份供应商的合同里，通常会定义一系列的SLA，从标准运维能力(在线时间和性能)到安全相关的需求(事件响应时间和法律或者鉴证请求)。一些云供应商可能有义务满足数据生命周期的需求，比如数据滞留，邮件消息的合法持有以及对设备和证据的产销监管链鉴证需求的响应。

必须密切跟踪这些合同义务并且向运维和执行管理层汇报。还必须仔细监控并且汇报云供应商审计的任何变化和鉴证报告。如果供应商的SOC 2报告里的控制声明的重大变更是相关的，那么就必须由安全和法务团队公告并且评估。

虽然云服务花费更多地和运维以及开发团队相关，大多数成熟的部署现在也包括很多安全相关的费用。花费包括由安全技术导致的额外消耗到和“云上”工具和产品相关的许可证，到新的类似云访问安全代理的服务。花费还可能包括认证和加密服务，以及为这些环境提供控制的其他云服务。安全团队不能忽略云使用的财务和预算方面，因为信息安全控制和服务现在已经是部署和运维的不可缺少的一部分。云度量可能包括随时间产生的费用和预算，不可预见的变更(可能是积极也可能是消极的)以及花费在云上vs本地的整体安全预算的百分比。

模型还未成熟

另一个需要跟踪的重要领域是云安全项目的整体成熟度。所有企业都想要知道和业界其他公司相比，他们的表现如何。并且该领域还缺少这一类别的比较基准，我们需要从哪里先开始。

大多数安全团队使用类似的控制框架，比如国家标准技术局 800-53(National Institute of Standards and Technology (NIST) 800-53)，NIST网络安全框架，以及云安全联盟云控制度量，和传统的成熟模型，比如通用成熟度模型相结合。从任何角度看这都不是什么***的方案，但是至少企业能够将本地控制的成熟度和云上的相对比，并且研究能够改进的领域。目前，一些控制方法在云上还不太成熟。需要时间等待云供应商改进他们的能力，并且等待云环境里的原生集成更加稳定。

无论你选择哪种云度量，都需要确保收集反馈，并且确认这些是否真的对利益相关者有用。安全资深管理趋向报告超级复杂的信息安全度量，或者仅仅是未整理的数据，这些对于业务高管来讲并没什么用处。这是我们在云上推进时可以有意识阻止的不好趋势。

关注于真正重要的事情：改进安全控制的状态，发现流程或者策略弱点并且修复它们，报告花销并且满足合规需求和成熟度目标。关注于这些领域，那么一定能收获很多。