合规与政策

1 级合规与政策

合规&与政策实践着重确定 PCI DSS 和 HIPAA 等合规领域的控制措施、制定服务级协议 (SLA) 等合约控制措施,帮助控制 COTS 软件风险、设定组织软件安全政策,并根据该政策进行审核。  

[CP1.1: 81] 统一监管压力。

如果企业或其客户受到美国的支付卡行业安全标准、GLBA、SOX 和 HIPAA;或欧盟的 GDPR 等监管或合规驱动因素的影响,则 SSG 就会成为了解驱动因素对软件施加约束的焦点。有时,SSG 会独自或合作创建统一的方法,消除重叠的合规要求产生的冗余和冲突。正式的方法会映射法规的适用部分,以管控说明组织合规方法的声明。作为替代方案,SSG 以外的法律或其他风险与合规团队运转的现有业务流程也可以作为监管焦点。采用一套符合监管压力要求的统一软件安全指南,能够确保尽可能高效地完成合规工作。一些公司通过直接参与标准工作组开发新技术和要求来影响监管环境。

[CP1.2: 105] 确定 PII 责任。

SSG 利用此类信息推动形成隐私保护最佳实践,在确定和描述监管和客户期望催生的 PII 义务方面发挥着关键作用。软件处理 PII 的方式可以经过明确规定,但即便不是如此,隐私也是一个热门话题。例如,如果组织处理信用卡交易,SSG 将帮助确定 PCI DSS 对持卡人数据处理的约束条件,然后再通知所有利益相关者。请注意,外包到托管环境(例如,云)不会减少 PII 义务,甚至可能会增加识别所有相关义务的难度。另请注意,创建处理 PII 的软件产品(公司不一定要直接处理 PII)的公司可以通过为其客户提供隐私控制和指导来满足这一需要。消费者的隐私保护预期、“软件无所不在”的扩散以及数据抓取和关联(例如,社交媒体)都在不断增强,从而为 PII 保护增加了另一个维度。

[CP1.3: 76] 制定政策。

SSG 通过制定或促成制定满足内部、法规和客户驱动的安全要求的软件安全策略来指导组织的其他部门。该政策包含一套统一的方法,可满足治理层面的(可能冗长的)安全驱动因素清单。因此,项目团队可以不必随时关注符合所有适用法规或其他规定涉及的所有细节。同样地,项目团队也不必亲自重新了解客户安全要求。SSG 政策声明有时可能会关注主要的合规性主题,例如处理 PII 或使用加密技术。有时,政策与 SSDL 及其在公司的使用直接相关。因为它们可能是新主题,所以关于物联网、云和移动架构的编码决策可能会重新引起人们对制定政策的兴趣。同样,例如可能需要解释可以和不可以自动化到 CI/CD 和连续部署通道中的内容(请参阅 [SM3.4 集成软件定义的生命周期管理])。架构标准和编码指南不属于政策范畴,但规定并强制要求对某些软件类别使用编码指南和架构标准的政策却属于该范畴。政策就是在初步行动层面给予许可和否定的内容;如果是非强制性,则就不能称之为政策。很多时候,政策声明必须可以转换为在软件定义的生命周期中使用的自动化程序,而不仅仅是人们强制执行的流程,但即使是自动化政策也必须具有强制性。  

2 级合规与政策

[CP2.1: 48] 确定 PII 库存。

组织确定每个系统及其关联数据存储库处理或存储的 PII 种类。可以通过两种方式来处理 PII 库存:从每个单独的应用程序开始,记下 PII 的使用情况,或者从特定类型的 PII 和标注接触它们的应用程序开始。系统架构的发展使得 PII 流入基于云的服务和终端设备生态系统并停留在那里(例如,内容交付网络、社交网络、移动设备、IoT 设备),导致保持准确的 PII 库存变得非常棘手。必须在关键情况下能够轻松引用库存,例如制作一份要求在遭遇泄露时通知客户的数据库列表,或一份在危机模拟中使用的列表(参见 [CMVM3.3 模拟软件危机])。

[CP2.2: 47] 要求合规风险接受安全签核。

组织具备正式的合规风险接受和问责流程来处理所有软件开发项目。在这一进程中,风险接受者在发布之前签核软件的状态时,SSG 可以为其充当顾问。例如,签核政策可能要求业务部门负责人签核尚未得到缓解的问题或与跳过的合规性相关的 SSDL 步骤。签核内容应当清晰可辨并且要截图以供将来参考,即使在最快的敏捷方法下也可以跟踪任何例外情况。请注意,没有安全缺陷的应用程序可能也会不合规,因此无害的渗透测试不能代替合规性签核。即使 DevOps 组织中的工程师有发布软件的技术能力,标准已纳入自动化流程,也仍然需要有意识的风险接受步骤。如果风险接受者签署了一套特定的合规性验收标准,然后在自动化流程中实施,则必须持续验证标准是否准确并且自动化流程是否切实可行。

[CP2.3: 51] 实施并追踪合规控制措施。

该组织可以证明符合相关要求,因为其 SSDL 符合 SSG 制定的控制声明(参见 [CP1.1 统一监管压力])。SSG 跟踪 SDLC 控制措施、指导问题领域,并确保达到审核与监管机构的满意程度。如果组织的 SDLC 可预测且可靠,则 SSG 即可保留在后台,因为遵循 SSDL 会生成所需的合规性证据。DevOps 在流程中嵌入合规性控制措施的方法会越来越多地出现在软件定义的基础架构和网络中,而不是出现在流程和人工干预中。处理得当的公司可以明确地将满足合规问题与遵循其 SSDL 联系起来。

[CP2.4: 44] 在所有供应商合同中加入软件安全 SLA。

供应商合同中包含 SLA,以确保供应商不会危害组织的合规历程或 SSI。每份新签订或续签的合同都包含一些规定,要求供应商解决软件安全问题并交付与组织的安全政策兼容的产品或服务(参见 [SR2.5 创建 SLA 模板])。有时,开源许可会涉及发起供应商管理流程,这样可以为在 SLA 中增加软件安全语言提供便利。此时仅仅依靠传统 IT 安全要求和允许进行渗透测试的一份简单协议并不够。

[CP2.5: 56] 确保高管注重合规和隐私保护义务。

为了获得高管对于各种合规和隐私保护活动的支持,SSG 采用简明的语言为高管解释了组织合规性和隐私保护义务,以及不履行这些义务的潜在后果。对一些组织而言,解释不合规或数据泄露产生的直接成本和可能后果,是提出这个问题的有效方法。而对于另一些组织而言,请外部专家向董事会讲解则能行得通,因为一些高管看重外部视角多过内部观点。获得高管充分支持的一个明确标志就是他们分配充足的资源来履行这些义务。虽然给人紧迫感(而且通常还要在此之后发生一次泄露)有助于开展引导工作,但是效果不会长久。

3 级合规与政策

[CP3.1: 25] 构建监管合规图景。

SSG 具备监管部门需要的信息,SSDL 收集的一系列书面政策、控制文件和工件,使 SSG 能够展示组织的合规图景,而不需要针对每次审核进行演习,也不必为每个迭代编写一份文书。监管机构、审核机构及高管通常都会对相同种类的报告感到满意,此类报告可通过各类工具直接生成。在某些情况下,组织将需要供应商提供更多信息,说明供应商的控制措施如何支持组织达到合规性(例如,云提供商,尤其是在多云部署中)。通常需要规范化来自不同来源的信息。政府是最大的但不是唯一的行为监管者。 

[CP3.2: 15] 针对供应商实施政策。

供应商必须遵守在内部使用的相同政策,还必须提交证明他们的软件安全实践合格的证据。在一个特定的组织中,供应商可能包括云提供商、中间件提供商、虚拟化提供商、容器和编排提供商、定制软件创建者、承包商等等,每个供应商可能会遵守不同的政策要求。他们的合规性证据可能包括代码审查或渗透测试的结果,或直接置入自动化或基础架构中的测试。供应商可能会证明他们执行了某些 SSDL 流程。有时,可使用 BSIMM 评分或 BSIMMsc 评分来帮助确保供应商遵守公司的软件安全政策。

[CP3.3: 7] 利用软件生命周期数据的反馈改进政策。

软件生命周期产生的信息会例行地反馈进入政策制定流程,帮助提早发现缺陷并立即阻止缺陷的发生。这样可以将盲点映射到 SSDL 故障趋势中,进而消除盲点。如果经常出现架构分析不充分、反复产生漏洞、忽视的安全门,或者选择不合适的公司进行渗透测试等问题,都可能暴露政策薄弱环节。有时,生命周期数据可能表明政策过于官僚化,例如因为阻碍了工程部门跟上预期的交付节奏,而引起冲突。技术的快速发展也可能造成政策空白,必需加以解决。久而久之,这些政策就会变得更加切合实际并且便于实施(参见 [SM1.1 发布流程并根据需要进行改进])。最后,调整政策使其与 SSDL 数据保持一致,从而加强和提高公司效率。