幾年前，360出過一個黑掉北京公交一卡通系統(tǒng)的事，當(dāng)時我應(yīng)邀給一些滲透測試人員做過一個關(guān)于滲透測試行業(yè)自律和職業(yè)規(guī)范的報告。其中提到了ISECOM的Open Source Security Test Methodology Manual 中提到的職業(yè)規(guī)范Rule of Engagement。這個職業(yè)規(guī)范的目的是規(guī)范滲透測試人員的行為，以避免白帽子陷入法律糾紛。

這些年，網(wǎng)絡(luò)安全服務(wù)市場日益發(fā)展，出現(xiàn)了不少白帽團隊和漏洞平臺。但是白帽子在提高技術(shù)的同時，法律和職業(yè)規(guī)范方面卻并沒有跟上，出現(xiàn)了不少違法的案例。今天看來，OSSTMM的Rule of Engagement還是具有很好的指導(dǎo)意義的。

OSSTMM的Rule of Engagement分為9個部分共36條。這些條款應(yīng)該作為網(wǎng)絡(luò)安全和滲透測試服務(wù)的自律準(zhǔn)則。遵守這些原則，可以使得安全測試人員避免法律風(fēng)險以及合同糾紛。

銷售和營銷

1） 不要用恐嚇的方式進行網(wǎng)絡(luò)安全滲透服務(wù)的營銷；

2） 不要提供哪種“滲透不成功不收費”的服務(wù)；

3） 禁止以銷售產(chǎn)品和滲透服務(wù)為目的的滲透比賽；

4） 在未經(jīng)授權(quán)的情況下嚴(yán)禁對任何系統(tǒng)進行滲透測試；

5） 也不要在滲透測試的宣傳中提及以前采用過你的滲透測試的客戶的名字即使在客戶同意的情況下也不要提。 這樣是對客戶和滲透團隊自身的保護；

6） 對客戶提供可信的安全咨詢建議， 即使這樣的建議可能會丟掉合同。

漏洞評估

1） 禁止在沒有書面同意的情況下驗證漏洞；

2） 在相應(yīng)的安全措施到位前， 嚴(yán)禁對那些安全性極差，極不穩(wěn)定的進行漏洞驗證。

合同及談判

1） 不管有沒有簽保密協(xié)議， 滲透測試人員都對客戶的機密信息以及安全測試結(jié)果具有保密的責(zé)任；

2） 安全測試人員在每一個測試中都承擔(dān)有限責(zé)任。 包括惡意的和非惡意的錯誤；

3） 合同必須明確的指明安全測試的局限以及風(fēng)險；

4） 在遠(yuǎn)程測試的情況下， 合同中必須包括有遠(yuǎn)程測試人員的電話以及原始IP地址；

5） 合同中必須包括應(yīng)急情況下的聯(lián)系人及電話；

6） 合同中必須明確對可恢復(fù)錯誤， 拒絕服務(wù)， 過程測試， 社交工程等測試手段的許可；

7） 合同必須明確對將來合同修改和工作范圍修改的流程。

工作范圍

1） 在合同明確工作范圍之前不要進行漏洞驗證；

2） 工作范圍中需要明確指明安全測試的局限。

提供測試計劃

1） 測試計劃必須包括天數(shù)和人時信息；

2） 測試計劃必須包括測試需要的時間。

對客戶的要求

1） 在測試期間不要有大的網(wǎng)絡(luò)調(diào)整；

2） 為避免因為滲透測試而采取臨時性提供安全防護標(biāo)準(zhǔn)的情況。 應(yīng)該要求客戶知通知重要人員。 應(yīng)該由客戶自行決定哪些人員應(yīng)該通知而哪些人員不必要通知；

3） 測試中如果需要用戶權(quán)限， 客戶應(yīng)該提供兩個不同的用戶賬號， 這些賬號應(yīng)該與需要測試的用戶賬號一樣， 而不是特殊的訪客賬號或者安全賬號；

4） 在測試需要用戶權(quán)限時， 測試人員應(yīng)該首先以黑盒方式， 在無用戶權(quán)限情況下測試， 然后再用客戶提供的用戶賬號進行測試。

測試

1） 測試人員應(yīng)該了解所采用的測試工具， 明確測試工具提供方， 了解測試工具如何使用。 必須對測試工具嚴(yán)格的實驗環(huán)境下測試后才能進行測試工作；

2） DoS的測試必須得到客戶的明確許可。 OSSTMM通常不要求對系統(tǒng)進行DoS等具有破壞性的測試，而是采用審閱的方式評估系統(tǒng)對此類攻擊的防范水平；

3） 社交工程以及過程測試只能夠?qū)δ切┪唇?jīng)訓(xùn)練的人員， 采用統(tǒng)計抽樣的方式進行測試；

4） 社交工程和過程測試應(yīng)該嚴(yán)格針對合同范圍內(nèi)界定的人員， 不應(yīng)該包括客戶， 合作伙伴， 供應(yīng)商人員；

5） 一旦發(fā)現(xiàn)高風(fēng)險漏洞， 必須立刻向客戶報告并提供解決方案；

6） 嚴(yán)禁通過互聯(lián)網(wǎng)進行DDoS攻擊測試；

7） 嚴(yán)禁以超過系統(tǒng)目標(biāo)承受能力的Flooding Test；

8） 任何情況下的測試范圍變化， 攻擊源的變化， 重要的發(fā)現(xiàn)等都需要立即通知客戶。 應(yīng)該每兩周提供客戶一份進度報告。

報告撰寫

1) 對發(fā)現(xiàn)的安全問題必須在報告中提供解決方案；

2) 所有未知的情況必須在報告中表明“未知”；

3) 報告應(yīng)該包括所有的安全狀況， 而不僅僅是安全漏洞；

4) 報告必須按照行業(yè)標(biāo)準(zhǔn)給出定性的風(fēng)險評估， 風(fēng)險評估應(yīng)該依據(jù)相應(yīng)的公式而不是測試人員的感覺。

報告發(fā)送

1） 必須明確通知客戶何時發(fā)出報告， 并且需要客戶確認(rèn)已收到報告；

2） 所有的與客戶的通信方式必須是端到端安全的。