ISO 27001 & SOC 2: 审计员实际上想要的技术证据
两个标准都说"每年进行一次渗透测试". 两者都要求没有任何文件可以证明的东西:你的控制实际有效. 下面是审计师接受的证据——以及悄悄地造成不符合情理的情况.
询问一个工程师室, ISO 27001要求的, 有人会说"每年一次笔试". 搜索这个字的标准,你就找不到了. 框架字面上的说法与审计师实际要求之间的差距在于认证项目悄悄地出错(mdash);以及范围很广的渗透测试变成你所购买的最廉价证据。
两个框架,一个令人不舒服的要求
ISO 27001和SOC 2是管理框架。 它们不是弱点核对表, 他们都没有给你一个待办清单 上面写着“按时间表测试你的应用程序”。 相反,它们所做的更微妙,而且实际上更难:它们需要证明你的技术措施发挥作用。 文档可以显示您写了政策。 它不能显示政策阻止任何人。
这就是渗透测试进入的裂缝。 看过风险登记册的审计员会看到意图 审计员在阅读一份倒数报告时,会看到结果和mdash;一个真实的人,拥有真正的工具,试图破门而入,并准确地报告其进展。 几乎每个审计员,几乎每一份证书都要求得到这一结果。 不是因为标准名称,而是因为没有其他答案。
Which ISO 27001控制需要真正的测试
2022年修订附件A调整了控制装置,三个控制直接依靠技术测试. A.8.8 涵盖技术脆弱性的管理。 A.8.29 涵盖开发和接受过程中的安全测试。 A.8.9 覆盖配置管理。 这些标准的主体是:监测、衡量、分析和评价信息系统系统。 两者之间的实际区别在于人们的旅程。 自动扫描仪可以清晰地回答 A.8.8 & mdash; 您可以显示一个发现清单和一个补救跟踪器, 这满足了“ 我们知道我们的弱点”。 它没有回答A.8.29,也没有回答第9.1条,因为也没有问你是否有清单。 他们问您是否核实您的防御工事。
扫描仪不会将两个中等强度的发现连成一个可行的折中方案。 它不理解暴露的中转点加上再利用的证书等于域管理员。 人类测试者确实如此, 因为这是全部工作。
Caution: 注意你的适用性声明。 如果标注A.8.29适用,且没有测试证据可证明,则自己写了不符合要求的字。 审计员检查您所宣称的可适用性与您实际可以生产哪些 & mdash; 行的匹配性 。
如果渗透测试符合SOC 2
SOC 2标准,则以信托服务标准为基础,在此两个标准最为重要。 CC4.1 要求定期评估控制的有效性。 CC7.1 需要检测和监测脆弱性和新的配置。
接下来的详情 捕捉公司关闭警戒。 在第二类审计中,审计员不检查一瞬间 & mdash;他们正在检查一个窗口,通常是3至12个月。 重要的是,测试发生在窗口的inside ,而且每一次补救都一直到关闭。 你观察期开始前一个月的一次精彩测试 得出了完全零的证据 这是SOC 2 编制中最昂贵的单项调度错误,完全可以避免:计划测试与审计窗口同时进行,而不是在审计窗口之后。
每个控制要求什么,以及一个笔试结果
下面的地图是你收集证据时 值得放在桌上的 将中间一栏读作要求,将右一栏读作审计员接受。
注意右栏有多少取决于“em>second 测试,而不是第一个测试。 第9.1条不满足于快照;它满足于趋势。 一个审计师想要看到你发现了一些东西,修好了它,然后验证了修补 & mdash; 并且循环重复. 单一报告无论多么粗糙,都讲述了一半的故事。
何时将测试排入认证周期
时机是好测试被浪费的地方. 跨越ISO和SOC 2 约定的拇指规则:
- 在对ISO & mdash; 进行第二阶段审计之前, 您会在与自己的团队一起的会议室里, 而不是在审计员面前, 发现主要结果。
- 在SOC 2 II型观测期的前几周 & mdash; 留有空间在同一窗口内进行补救和重新测试.
- Annually, feed 监视审核.
- 在任何重大架构变化后,云迁移,或新产品推出.
最后一点值得强调。 认证不是一次性事件,而是节奏。 每当你的攻击表面改变形状, 来自去年的证据 描述了一个不再存在的系统。 审计员知道这一点,他们问。
报告必须包含哪些内容才能在审计
之后继续存在。 笔试报告不能仅供工程团队使用 它是一种审计艺术,需要为不在场的读者写。 有五样东西可以区分关闭控制的报告和产生后续问题的报告:
- rstrongrstrongr>r>r>r>r>r>r>r>r>r>dashdash;其中涉及,应用和账户经过了测试,同样重要的是,漏掉了什么.
- r>r>r>r>r>r>rTESr>r>r>r>r>r>r>r>r>r>r>r>r>r>l>r>r>r>l>r>r>l>l>r>r>r>r>r>r>/strongr>r>r>r>r>r>r>r>r>r>r>r>r>r>/strongr>r>r>r>r>r>/strongr>r>r>r> 最后一个项目是第一个审计员。 一个标记为"补救"而不经过重新检验的发现是一种断言,而不是证据. 一项标记为"补救,本日再试,不再可复制"的认定为证据. 审计结果的差别与所涉努力不成比例。 注:这些交付品已经支持了摩尔多瓦金融机构和付款处理者的审计和登记程序。 模式在各部门和mdash之间一致;动脉与结果一样重要。
范围:审计员首先注意到的事情
您的测试范围必须覆盖您所申报的ISMS范围内的系统, 或者支持您选择的SOC 2 标准的系统 。 在实践中,这意味着面向客户的应用程序,托管这些应用程序的基础设施,认证机制,以及 & mdash; 越来越多的 & mdash; 云配置.
比您宣布的范围更窄的边界是审计师发现的第一件事,因为它是最容易检查的不一致之处:它们把您的范围说明放在一边,把您的报告放在一边。 覆盖你80%的申报系统的测试 不读作"大部分符合". 它读作一个漏洞,漏洞引来关于其他事物的更深层的问题。
谁应进行测试
一个内部团队可以做到这一点。 然而,独立是审计员的定价。 ISO 27001要求评价是客观的,而SOC 2对外部方更有利. 如果建立该系统的团队也是测试该系统的团队,则希望获得关于职责分离和mdash的额外证据;大多数组织无法令人信服地提供证据。 直截了当的路径是外部提供者,有宣布的方法和独立的书面报告。 它在出现前消除了整个类别的审计摩擦。
每次出现的问题
ISO 27001授权进行渗透测试吗?
该标准从未将这个词作为明确的义务。 但是,A.8.8、A.8.29和9.1条要求查明技术弱点、测试安全性和评价措施的效力。 在实践中,审计师接受渗透测试作为这些要求的最直接证据 & mdash; 以及一个宣布A.8.29可适用但无法显示测试结果的组织暴露在不符合要求的发现中。
脆弱性扫描对于SOC 2是否足够?
扫描涵盖CC7.1的连续监测要素,但很少单独满足CC4.1,因为CC4.1询问有效性. 扫描仪报告哪些是脆弱的;渗透测试显示哪些是实际可以利用的,攻击者获得多少程度. 大多数审计员都期望:在观察期间进行经常性扫描,加上至少一次人工测试。
报告能有多旧?
通常的规则是最长为12个月,但对于SOC 2类型,则有其他规定:报告必须在观察窗口内注明日期。 在窗子打开一个月前的一次出色测试 没有为窗子提供证据 对于ISO, 在认证审计之前进行测试, 然后每年在监控时进行测试.
需要测试什么认证范围?
ISMS范围内的一切,或支持您所选择的 SOC 2 标准的一切: 客户化应用程序,托管基础设施,认证机制,以及云面配置. 比申报范围窄的周边正是审计员首先检查的。
内部小组能做到这一点吗?
是的,但独立很重要。 ISO要求客观评价,SOC 2对外部方给予更多的信任. 当建设者也是测试者时, 期望请求额外分期证据 & mdash; 最简单的路线是外部提供者, 并有申报的方法和一份独立报告.
外购
认证行业习惯于将渗透测试作为审计前不久购买的复选箱. 这种框架忽略了框架的实际要求。 ISO 27001和SOC 2在心里都只问一个问题:你能否证明你的防御系统对试图打破它们的人起作用? 一项政策证明了意图。 扫描仪证明了意识 只有测试 & mdash; 瞄准您所宣布的系统, 运行在您的审计窗口内, 然后是文件记录的重新测试 & mdash; 验证函数 。 将早期支出较少用于认证的公司内部化,而不是更多的公司,因为它们停止购买审计员无法使用的证据。 这些材料是信息性的,不构成认证建议。 具体要求取决于您申报的范围以及您选择的认证机构或审计公司。