牢骚者
PDF追求合规的理想境界
不要让SOX和PCI压垮你
格雷格·A·诺兰
合规性。仅仅提及它就会让人联想到一连串令人担忧的问题和顾虑。例如，谁在遵守？遵守什么？面对如此众多的标准、法律、角度、交叉、重叠和后果，最终由谁来决定你是否合规？你如何确定哪些在范围内，哪些不在范围外？为什么一听到“合规性”这个词，你立刻会想到审计？
要想了解合规性这团乱麻，看看我的公司就知道了。作为一家上市公司，我们受到SOX（萨班斯-奥克斯利法案，2002年）的约束；为了多家银行，我们还要遵守PCI DSS（支付卡行业数据安全标准），也称为Visa CISP（持卡人信息安全计划）；还有HIPAA（健康保险流通与责任法案）；CA 1786（以及所有其他州的披露法）；以及欧盟、其成员国、日本、韩国和少数其他国家的隐私和数据安全法（仅这些就可能衍生出一整套课程和讲座！）。
SOX和PCI这两项主要的合规义务，目标相似，但采取的方法却截然相反。SOX没有指定标准；而是说要使用其他已建立的方法或实践。另一方面，PCI明确规定了你必须做什么，谁可以做，它适用于哪里，以及如何确定你是否合规。应该有一个理想的平衡点，让两者都能兼顾。让我们分别看一下这两者，并指出它们各自的独特问题。
SOX
萨班斯-奥克斯利法案——第一次实施时真是痛苦不堪！SOX有一个组成部分，旨在解决向华尔街报告数字的系统的完整性问题。正是SOX的这一小部分造成了如此大的痛苦，因为根据不同的解读，它可能会将非财务系统纳入财务审计的范围。审计计算机系统，特别是那些本质上不是财务性质的系统，与审计财务和财务系统完全不同，大型审计公司为了通过最终审计而经常采取的地毯式轰炸方法弊大于利。我说的地毯式轰炸是指一种全力以赴的方法，即派出大批审计师及其主管（又名项目经理）进入公司，首先试图弄清楚哪些在范围内以及在多大程度上在范围内，然后（数月）纠缠这些团队，描绘出他们认为合规的内容，并迫使他们适应该模型，以便在实际审计之前使审计结果达到100%的合规。让审计师（内部和外部）和合规项目经理连续数月在你面前晃悠，会削弱士气并影响利润。为什么不通过一个单一的联络点来承担这些人的冲击，让人们做好自己的工作呢？
这个单一的联络点将是唯一被允许在两个方向上与团队进行沟通的人。这个人将做好准备工作，以确定审计的范围，确定弄清楚系统如何运行所需的最少人员，然后将特定的系统知识转化为审计师可以理解的内容。这样，原本可能需要数月、无休止的会议，房间里挤满了不必要的人，就可以减少到仅仅几周的干扰。
SOX的另一个问题是实际的控制框架。立法者没有指定要遵循的标准；他们把它留给了审计公司。如果这只是一个财务系统审计，我会说没问题。但事实并非如此。你现在有经验不足的顾问在遵循某种清单，这些清单可能适用也可能不适用，并指定可能相关也可能不相关的控制措施。是的，SOX是CFO及其审计师的领域，但现实情况是，它针对的系统是CIO的领域。为什么不让CIO来主导SOX合规性，使其满足CFO提出的要求呢？
归根结底，关键是要确保与收入流相关的系统是安全的，并且由适当的人员进行适当的访问。评估这一点真的那么困难吗？通过识别问题、找到适合系统/环境的解决方案、制定解决问题的时间表，并实施长期的文化努力（例如，教育、流程、政策）以帮助避免未来出现类似问题，难道不更重要吗？
PCI
别误会，我完全赞成保护信用卡数据和处理系统。这是常识，但可悲的是，常识一点也不普及。正因如此，支付卡行业——你知道的，Visa、万事达和美国运通等卡公司组成的卡特尔——已主动强制要求遵守其数据安全标准。
DSS是PCI试图定义如果你参与信用卡交易，你可以做什么和不可以做什么。该标准涉及网络安全、持卡人数据保护、漏洞管理计划、强访问控制、网络监控和INFOSEC（信息系统安全）策略。如果你接触过信息安全的概念，你就知道解决这些概念的方法不止一种。
话虽如此，PCI DSS写得很差，定义了非常具体（有时甚至是外行）的技术控制措施，并且应用不一致。审计师被迫遵循该标准定义的字面意思，而不是其精神，而后者会更有意义。PCI对审计师必须做什么过于霸道，以至于四大会计师事务所都退出了该业务领域。
该标准似乎也是为了符合流行语而编写的，并且是以基于Windows的系统为模型的（嗯，我们是Unix商店）。再说一遍，重点不是让审计师接受培训来查找特定平台上可能存在也可能不存在的特定实现，而是让审计师接受培训来理解给定系统出现的问题——它做什么、如何做以及如何满足标准。你是在寻找标记为防火墙的设备还是防火墙功能？你是在寻找扫描整个IP空间，还是仅仅扫描连接到卡处理系统的网络？你是在寻找捕获非常特定事件的非常特定数据的日志文件，还是验证在发生调查时，是否可以追究行为责任？
另一个问题是，本应为卡公司强制商家遵守合规性的银行自身也不合规，并且并不真正理解问题所在。如果他们一旦收到我们的数据就面临更大的问题，或者根本没有经验来理解给定的技术细微之处，他们如何批准补偿性控制措施？
幸运的是，我们的系统架构使得关键部分与公司的其余部分隔离，访问控制到位以访问它们，并且数据得到适当处理。优秀的系统工程可以正确识别系统的风险（给定应用程序、其用户、数据和处理中固有的风险），考虑业务和技术约束，并将所有这些整合在一起。这使我们的PCI审计更容易。毕竟，这不就是重点吗？我们的系统并非完美——没有完美的东西——但它们可以确保数据安全。
涅槃
理想情况下，每年应该只有一次审计，以验证公司的安全要求，并可用于满足任何或所有外部利益相关者的需求。这些安全要求部分基于针对公司业务/系统的特定风险或威胁而制定，部分基于相关的外部合规义务而制定。被确定为与这些外部追求者相关的系统将接受基于日历的审计，而所有其余系统将每四个季度（左右）审查一次，以确保它们仍在做正确的事情并应对潜在的新标准。
通过审计不必让人头疼。一台运转良好的合规机器对于产品开发团队来说是隐形的。这一切都始于产品开发文化。产品在定义时就考虑了风险以及如何应对这些风险。架构师构建的系统旨在解决用户、他们的数据、管理员、他们的访问以及所有这些发生的接口。开发人员编写故障安全代码，并解决常见的输入验证问题（以及其他问题）。运维人员以类似的方式部署和管理系统。
是的，合规性不仅仅是审计师每年多次纠缠开发人员，让他们远离自己的工作。如果做得正确，合规性就会根植于员工的脑海中，并成为业务的一部分。你可以通过大量的培训和内置的制衡机制来实现这一点。对我来说，一个没有审计师——尤其是四大——的世界就是涅槃。
格雷格·A·诺兰是一位工程经理，自1980年代中期以来一直活跃在安全/合规领域。他目前正在一家财富500强公司努力实现安全合规的理想境界。当他不考虑安全策略、流程或保护用户数据时，你可以发现他在拍照或探索都市丛林。
最初发表于Queue杂志第4卷第7期—
在数字图书馆中评论本文
更多相关文章
Jatinder Singh, Jennifer Cobbe, Do Le Quoc, Zahra Tarkhani - 云端飞地
随着组织数据实践受到越来越多的审查，对可以帮助组织履行其数据管理义务的机制的需求也在增长。TEE（可信执行环境）提供基于硬件的机制，具有各种安全属性，可用于辅助计算和数据管理。TEE关注数据、代码和相应计算的机密性和完整性。由于主要安全属性来自硬件，因此即使主机特权软件堆栈存在漏洞，也可以提供某些保护和保证。
Tracy Ragan - 在IT合规游戏中保持领先
让开发人员接受用于管理从开发到发布应用程序的标准化程序，是当今组织面临的最大障碍之一。建立标准化的开发到发布工作流程（通常称为ALM（应用程序生命周期管理）流程）对于组织努力满足严格的IT合规性要求尤为重要。但这说起来容易做起来难，因为不同的开发团队创建了自己的独特程序，这些程序没有文档记录，不明确且不可追溯。
J. C. Cannon, Marilee Byers - 解构合规性
合规性这个话题每年都变得越来越复杂。数十项监管要求可能会影响公司的业务流程。而且，这些要求通常含糊不清且令人困惑。当负责合规性的人员被问及他们的业务流程是否合规时，他们很难简洁而自信地回答，这是可以理解的。本文探讨了公司如何解构合规性，以系统的方式处理合规性，并应用技术来自动化与合规性相关的业务流程。本文还专门探讨了微软如何处理SOX合规性。
John Bostick - 摆脱SOX的束缚
数据对于任何大型组织来说都是宝贵的资源。组织规模越大，就越有可能在某种程度上依赖第三方供应商和合作伙伴来帮助其管理和监控其关键任务数据。在针对上市公司的新法规（例如SOX第404条）出台后，财富1000强公司的IT部门负责人越来越需要确信，在对其关键数据交易进行24/7/365监控时，他们拥有具有良好计划和完善文档记录的程序的业务合作伙伴。为了响应验证第三方控制和程序日益增长的需求，一些公司坚持要求某些供应商接受SAS 70 Type II审计。
© 保留所有权利。