白帽渗透测试的36条军规

  1. 云栖社区>
  2. 博客>
  3. 正文

白帽渗透测试的36条军规

沉默术士 2017-07-03 11:06:00 浏览1044

几年前, 360出过一个黑掉北京公交一卡通系统的事, 当时我应邀给一些渗透测试人员做过一个关于渗透测试行业自律和职业规范的报告。 其中提到了ISECOM的Open Source Security Test Methodology Manual 中提到的职业规范Rule of Engagement。 这个职业规范的目的是规范渗透测试人员的行为, 以避免白帽子陷入法律纠纷。

这些年, 网络安全服务市场日益发展, 出现了不少白帽团队和漏洞平台。 但是白帽子在提高技术的同时, 法律和职业规范方面却并没有跟上, 出现了不少违法的案例。 今天看来, OSSTMM的Rule of Engagement还是具有很好的指导意义的。

OSSTMM的Rule of Engagement分为9个部分共36条。 这些条款应该作为网络安全和渗透测试服务的自律准则。 遵守这些原则, 可以使得安全测试人员避免法律风险以及合同纠纷。

销售和营销

1) 不要用恐吓的方式进行网络安全渗透服务的营销。
2) 不要提供哪种“渗透不成功不收费”的服务
3) 禁止以销售产品和渗透服务为目的的渗透比赛
4) 在未经授权的情况下严禁对任何系统进行渗透测试
5) 也不要在渗透测试的宣传中提及以前采用过你的渗透测试的客户的名字即使在客户同意的情况下也不要提。 这样是对客户和渗透团队自身的保护。
6) 对客户提供可信的安全咨询建议, 即使这样的建议可能会丢掉合同。

漏洞评估

1) 禁止在没有书面同意的情况下验证漏洞
2) 在相应的安全措施到位前, 严禁对那些安全性极差,极不稳定的进行漏洞验证。

合同及谈判

1) 不管有没有签保密协议, 渗透测试人员都对客户的机密信息以及安全测试结果具有保密的责任
2) 安全测试人员在每一个测试中都承担有限责任。 包括恶意的和非恶意的错误。
3) 合同必须明确的指明安全测试的局限以及风险
4) 在远程测试的情况下, 合同中必须包括有远程测试人员的电话以及原始IP地址
5) 合同中必须包括应急情况下的联系人及电话
6) 合同中必须明确对可恢复错误, 拒绝服务, 过程测试, 社交工程等测试手段的许可。
7) 合同必须明确对将来合同修改和工作范围修改的流程。

工作范围

1) 在合同明确工作范围之前不要进行漏洞验证
2) 工作范围中需要明确指明安全测试的局限

提供测试计划

1) 测试计划必须包括天数和人时信息
2) 测试计划必须包括测试需要的时间

对客户的要求

1) 在测试期间不要有大的网络调整
2) 为避免因为渗透测试而采取临时性提供安全防护标准的情况。 应该要求客户知通知重要人员。 应该由客户自行决定哪些人员应该通知而哪些人员不必要通知
3) 测试中如果需要用户权限, 客户应该提供两个不同的用户账号, 这些账号应该与需要测试的用户账号一样, 而不是特殊的访客账号或者安全账号。
4) 在测试需要用户权限时, 测试人员应该首先以黑盒方式, 在无用户权限情况下测试, 然后再用客户提供的用户账号进行测试。

测试

1) 测试人员应该了解所采用的测试工具, 明确测试工具提供方, 了解测试工具如何使用。 必须对测试工具严格的实验环境下测试后才能进行测试工作。
2) DoS的测试必须得到客户的明确许可。 OSSTMM通常不要求对系统进行DoS等具有破坏性的测试,而是采用审阅的方式评估系统对此类攻击的防范水平
3) 社交工程以及过程测试只能够对那些未经训练的人员, 采用统计抽样的方式进行测试。
4) 社交工程和过程测试应该严格针对合同范围内界定的人员, 不应该包括客户, 合作伙伴, 供应商人员。
5) 一旦发现高风险漏洞, 必须立刻向客户报告并提供解决方案
6) 严禁通过互联网进行DDoS攻击测试
7) 严禁以超过系统目标承受能力的Flooding Test
8) 任何情况下的测试范围变化, 攻击源的变化, 重要的发现等都需要立即通知客户。 应该每两周提供客户一份进度报告

报告撰写

1) 对发现的安全问题必须在报告中提供解决方案
2) 所有未知的情况必须在报告中表明“未知”
3) 报告应该包括所有的安全状况, 而不仅仅是安全漏洞
4) 报告必须按照行业标准给出定性的风险评估, 风险评估应该依据相应的公式而不是测试人员的感觉

报告发送

1) 必须明确通知客户何时发出报告, 并且需要客户确认已收到报告
2) 所有的与客户的通信方式必须是端到端安全的。
本文转自d1net(转载)