合规与政策

1 级合规与政策

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

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

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

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

软件处理个人身份信息 (PII) 的方式可以经过明确规定,但即便不是如此,隐私也是一个热门话题。SSG 在确定和描述监管和客户期望催生的 PII 义务方面发挥着关键作用。它使用这些信息来推广与隐私相关的最佳实践。例如,如果组织处理信用卡交易,SSG 将确定 PCI DSS 对持卡人数据处理的约束条件,然后再通知所有利益相关者。请注意,外包给托管环境(例如云)并不能免除 PII 义务。另请注意,创建处理 PII 的软件产品(但不一定直接处理 PII)的公司可以通过为其客户提供隐私控制和指导来获得信用。物联网 (IoT) 和移动设备的繁荣为 PII 保护增加了另一个维度。

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

SSG 通过制定或促成制定满足内部、法规和客户驱动的安全要求的软件安全策略来指导组织的其他部门。该政策包含一套统一的方法,可满足治理层面的(可能冗长的)安全驱动因素清单。因此,项目团队可以不必随时关注符合所有适用法规或其他规定涉及的所有细节。同样地,项目团队也不必亲自重新了解客户安全要求。SSG 政策文件有时着重介绍主要合规主题,例如 PII 处理或密码学的使用。有时,政策文件与 SSDL 及其在公司的使用直接相关。关于物联网、云和移动架构的决策非常新颖,所以能够为政策讨论增加一些非常需要的细节。同样,可能有必要解释 CI/CD 和持续部署管道能够实现哪些功能和哪些不能实现自动化。架构标准和编码准则并不属于软件安全策略。另一方面,规定并强制使用某些类别的应用程序的编码准则和架构标准的政策确实能够发挥作用。政策就是在计划层面允许和否定的内容。不是强制执行的,就不是政策。  

2 级合规与政策

[CP2.1: 39] 确定 PII 数据库存。

组织确定每个系统及其数据存储库(包括移动和云环境)处理或存储的 PII 种类。可以通过两种方式来处理 PII 库存:从每个单独的应用程序开始,记下 PII 的使用情况,或者从特定类型的 PII 和接触它们的应用程序开始。无论哪种情况,都需要数据存储库的清单。请注意,当应用程序分布在多个部署环境中时,PII 库存控制可能会变得棘手。不要忽视这一情况。同样,不要忽视 PII 时常演变的定义。该清单与组织的 PII 义务相结合,即可指导隐私计划。例如,SSG 现在可以创建一个数据库列表,要求在发生泄露时,必须通知客户。

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

无论开发方法如何,组织都具备正式的合规风险接受和问责流程来处理所有软件开发项目。风险接受者在发布之前签核软件的状态时,SSG 可以为其充当顾问。例如,签核政策可能要求业务部门负责人签核尚未得到缓解的问题或与跳过的合规性相关的 SSDL 步骤。签核应当内容明确,并拍照留待后续查阅。即便使用最快的敏捷方法,也应该跟踪所有异常情况。即便是没有安全缺陷的应用程序也可能不合规。

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

该组织可以证明符合适用的法规,因为其 SSDL 符合 SSG 制定的控制声明(参见 [CP1.1 统一监管压力])。 SSG 跟踪控制措施,指导问题领域,并确保让审核与监管机构都满意。如果组织的 SDLC 是可预测并且可靠,那么 SSG 就可以在很大程度上保持稳定并保持得分。如果 SDLC 不均衡、不太可靠,或者试图超越其支持基础架构能够处理的速度(对于您而言就是 CI/CD),SSG 就可能会被迫担当裁判等更加主动的角色。处理得当的公司可以明确地将满足合规问题与遵循其 SSDL 联系起来。

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

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

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

SSG 开展的合规与隐私保护活动获得高管赞誉。针对组织的合规和隐私保护义务,以及不履行这些义务的潜在后果,向高管作出简单明了的解释。对一些组织而言,解释不合规或数据泄露产生的直接成本和可能后果,可能是提出这个问题的有效方法。而对于其他组织而言,请外部专家向董事会讲解则能行得通,因为一些高管看重外部视角多过内部观点。适当的高管意识的一个明确标志就是分配足够的资源来完成工作。请注意,一次数据泄露散发的光和热通常都不长久。

3 级合规与政策

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

SSG 拥有监管者想要的信息。SSDL 收集的一系列书面政策、控制文件和工件,使 SSG 能够展示组织的合规图景,而不需要针对每次审核进行演习,也不必为每个迭代编写一份文书。有时,监管机构、审核机构及高管都对相同种类的报告感到满意,此类报告可能是通过各类工具直接生成。

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

供应商必须遵守在内部使用的相同政策,还必须提交证明他们的软件安全实践合格的证据。这也适用于云和移动平台提供商。证据可以包括代码审查或渗透测试的结果。供应商也可以证明他们正在执行某些 SSDL 流程。有时,可使用 BSIMM 评分或 vBSIMM 评分来帮助确保供应商遵守公司的政策。

[CP3.3: 5] 利用 SSDL 数据的反馈改进政策。

SSDL 产生的信息会例行地反馈进入政策制定流程,帮助提早发现缺陷并立即阻止缺陷的发生。基于 SSDL 故障趋势消除盲点。例如,架构分析不充分、反复产生漏洞、忽视的安全门,或者选择不合适的公司进行渗透测试,都可能暴露政策薄弱环节。同样,可能需要调整太过机械官僚的政策以适应敏捷方法。久而久之,这些政策就会变得更加切合实际并且便于实施(参见 [SM1.1 根据需要改进发布流程(职务、职责、计划)])。最后,调整政策使其与 SSDL 数据保持一致,从而加强和提高公司效率。