數(shù)據(jù)防泄密項目經(jīng)驗分享
素包子近期也負責過一個數(shù)據(jù)防泄密項目，磕磕碰碰半年走下來，用兩個字來總結(jié)就是：值得。
這個數(shù)據(jù)防泄密項目（DLP）涉及形形色色的角色：國內(nèi)外供應(yīng)商、大集團的領(lǐng)導和同事、產(chǎn)業(yè)集團的領(lǐng)導和同事、事業(yè)部的領(lǐng)導和同事、試點部門的領(lǐng)導和同事；在這么多角色中，輸出了各式各樣的想法，也就有很多根杠桿，有的需要平衡，有的需要壓制，有的需要抬高；多的不說，謝謝各位角色的支持和包容，特別感謝沒中標的供應(yīng)商們，你們在項目前期也給予了我很重要的支持和幫助。
#ChangeLog |
2010.09.07 補充權(quán)限及加密的選擇，控制項目需求。
今天在TT安全上看到一個名為《終端數(shù)據(jù)丟失防護部署中的5大安全技巧》，由于TT明文要求不能轉(zhuǎn)載，我也就不轉(zhuǎn)了，有興趣的同學自己去注冊個帳號看吧。
我非常認同文中的“在你推出部署數(shù)據(jù)丟失防護解決方案的第一個部門確定一些關(guān)鍵用戶，根據(jù)需要對他們進行培訓，并在測試階段與他們密切合作。通過關(guān)鍵用戶的幫助，可以避免非技術(shù)業(yè)務(wù)部門測試中出現(xiàn)的問題，也可避免部署中沒有任何用戶反饋的情形發(fā)生?！焙汀奥齺恚鸩酵瞥龃砗筒呗浴边@兩個觀點。
前者決定了我們是否可以很好的邁出第一步。小范圍的試用是最關(guān)鍵的。在這個過程里，數(shù)據(jù)和事件運營非常重要，真的是要“積跬步”才有機會“至千里”的。在這個階段，乙方項目團隊做的非常漂亮，他們的專業(yè)，穩(wěn)健，快速，靈活讓我十分佩服，也讓我學到不少東西。
后者小步快跑的思路決定了我們的項目阻力?！胺e跬步”僅僅是一個開頭，我們要“至千里”的話，還有很長很崎嶇的路要走。我在這個項目里的感覺是前期一定要“小”，小為我們快速發(fā)現(xiàn)并解決大部分問題爭取了時間和空間。
我還有一些其他的觀點：
1、盡量避免把數(shù)據(jù)防泄密項目做成一個咨詢項目。
沒錯，前期的調(diào)研很重要，中期的展示很重要，后期的領(lǐng)導認可更重要，這些都要做漂亮，但我想提醒的是，管理手段等這些“務(wù)虛”的內(nèi)容在這個項目里是非常必要的而且是非常重要的，但所占比例不宜太大，項目時間有25%在做這些東西事情就差不多了。
為啥？高樓大廈平地起，只有把“務(wù)實”的基礎(chǔ)打好了，務(wù)虛的東西才能站的更高，更穩(wěn)更久，一個如此復雜的項目，走的越空，問題越多，問題越多，越不利于務(wù)虛的東西；另外務(wù)虛的項目的驗收是一個大問題。我不是想論證三分技術(shù)七分管理還是七分技術(shù)三分管理，其實根本沒這必要，不同的行業(yè)，不同的企業(yè)，不同的領(lǐng)導要求都不一樣，我的想法是如果條件允許的話，先跑穩(wěn)，再跳高；如果條件不允許，只能硬著頭皮先摸高，再軟著陸了。
2、選擇一個負責的供應(yīng)商。
素包子還是要感謝那將近20個供應(yīng)商，但是坦白說，從我個人的判斷來看，這些供應(yīng)商各有所長，當然也各有所短。為了更好的提高數(shù)據(jù)防泄密項目的成功率，我覺得負責和經(jīng)驗豐富是最重要的。當然這不能憑口說，得看他們的作為?？谀瓩M飛天花亂墜的說；但不著邊際忽忽悠悠的做，實在是無法讓我放心把項目交付給他們。我不排斥售前或者銷售忽悠我，我也不想和他們?nèi)K某一個細節(jié)的真?zhèn)?，但我希望大家在做事的時候，一是一二是二。作為甲方來說，走錯了這一步，啥都別說了，拿出勇氣抽自己一巴掌，趁早回頭是岸；下不了手或者要抽很多人巴掌？那就自求多福吧。
3、選擇一個經(jīng)驗豐富的供應(yīng)商
供應(yīng)商的經(jīng)驗也很重要，我們不能做供應(yīng)商在某個領(lǐng)域的小白鼠，應(yīng)用市場細分的很厲害，安全市場也細分的很厲害，DL產(chǎn)品同質(zhì)化也比較厲害；但在DLP項目里不同行業(yè)之間經(jīng)驗復制程度還是有較大差別的，一個有經(jīng)驗豐富供應(yīng)商可以傳遞很多經(jīng)驗給我們，給我們提供合適的方案，讓我們少走彎路，少摔跤，這對數(shù)據(jù)防泄密這種用戶敏感度較高項目來說非常關(guān)鍵。
至于國內(nèi)還是國外的供應(yīng)商，我們選擇了國內(nèi)供應(yīng)商。原因很簡單，你要想找老外按你的意思改個東西，dream!不過這個缺點對廠商自身來說也是優(yōu)點，標準化，好維護，好服務(wù)，就看廠商的取舍和平衡了。
另外老外的DLP產(chǎn)品很少文件加密的，大多是權(quán)限、網(wǎng)關(guān)類的產(chǎn)品，還有需要考慮的是外國的加密類產(chǎn)品在國內(nèi)是不允許銷售的，小企業(yè)采購的話無所謂，大企業(yè)采購的時候要考慮法務(wù)風險。說到這個銷售許可，有一些國內(nèi)的廠商喜歡拿這個東西大做文章攻擊國內(nèi)的其他競爭對手。這些廠商也就是在許可這塊投入了較多的精力，但這對項目的質(zhì)量影響不大，不必太在意。
4、選擇一個合適的產(chǎn)品。
為什么素包子現(xiàn)在才說產(chǎn)品的問題呢？因為結(jié)合我們個人的認識及前期與各供應(yīng)商洗腦，及互相PK的結(jié)果，再結(jié)合2、3兩點，會自然而然的輸出合適的DLP大方向（文件加密、磁盤加密、格式轉(zhuǎn)換、權(quán)限控制、網(wǎng)關(guān)控制等）及產(chǎn)品，這是一個水到渠成的過程。退一步說：產(chǎn)品要不好可以改進，但供應(yīng)商有問題的話，那可不是說換就換的。
什么叫合適的產(chǎn)品？素包子的理解就是符合滿足多種角色需求的產(chǎn)品，項目所處的環(huán)境越復雜，我們要滿足和均衡的人和事就越多，下面列舉一些有共性的需求：
A、滿足企業(yè)高管需求的產(chǎn)品。
B、滿足項目經(jīng)理領(lǐng)導需求的產(chǎn)品。
C、滿足項目經(jīng)理需求的產(chǎn)品。
D、滿足維護人員需求的產(chǎn)品。
E、滿足使用人員需求的產(chǎn)品。
橫向再插入三個關(guān)鍵詞：穩(wěn)定，簡單，可靠。
以上幾點看似廢話，但要真的想清楚，權(quán)衡好，再做好，對甲方和乙方的項目負責人都是非常大的挑戰(zhàn)。換一個說法可能更好理解，這里面的眾多角色想通過這個項目讓什么人可以獲得什么，規(guī)避什么，說明什么，推動什么，阻止什么。
作為項目負責人，我們得搞清楚keyman是哪些人，我們選擇的產(chǎn)品的輸出能滿足他們的需求嗎？需要提醒的是，在項目的不同階段，keyman有可能是變化的 ：）哪怕在試點測試的這一個階段里，不子階段的keyman也不一樣。
至于穩(wěn)定、簡單、可靠。就不用說太多了，一個要在3萬用戶終端上跑的東西：
能不成熟嗎？三天兩頭就崩潰或者占用大量資源，上述C、D、E人員也會跟著崩潰的一塌糊涂，進而A、B人員崩潰，項目夭折。
能不簡單嗎？我一直認為一個優(yōu)秀的產(chǎn)品就要做到”dont make me think”，幾萬人，就算我們培訓，發(fā)手冊，有30%的人看就不錯了，即使還有5%不到的IT人員能自學，那剩下的65%的人中如果每天有個1%的E人員打電話問D咋用，那大家也是崩潰的。這里說的簡單并不是單純的簡單，而是產(chǎn)品設(shè)計者要真正從用戶的角度去考慮和實踐，才知道怎么樣才是從架構(gòu)上、從流程上、從產(chǎn)品上真正的簡單，當然接受用戶的反饋并改進這非常有利于做到“簡單”，這也是國內(nèi)產(chǎn)品的潛在優(yōu)勢，國外產(chǎn)品你給反饋個想法，不管好是不好，等個3579個月再說吧。
能不可靠嗎？如果不可靠，可能會在務(wù)實和務(wù)虛的層面的ABCDE人員中全面起火。當然我也是做安全的，我也知道安全是需要均衡的，所以我對可靠的定義是：首先能正視問題，然后能主動的發(fā)現(xiàn)問題和快速的解決問題，如果短期內(nèi)不能解決問題，就必須提供緩解方法。
正如實施SDL，我們不怕0day漏洞，只怕出了0day后無法快速發(fā)現(xiàn)，更怕發(fā)現(xiàn)了沒響應(yīng)或不及時，還怕響應(yīng)了但解決不了問題。SDL里的一些mitigation手段就是緩解問題的好方法。
上述成熟和簡單的問題或許有點夸張和孤立，但是當放大到一個很復雜的環(huán)境里的時候，還真可能有這么夸張，即使真沒那么夸張，但是用戶就說的這么夸張，供應(yīng)商也挺頭疼，雖然有一些辦法緩解 ：）
本文持續(xù)更新，最新版本請訪問《數(shù)據(jù)防泄密項目經(jīng)驗分享》 http://baoz.net/share-the-experience-of-data-lost-prevent-project/
5、權(quán)限還是加密？
前幾天有朋友問到我這個問題，補充分享一下我個人的觀點。首先我們在需求調(diào)研的時候業(yè)務(wù)部門對權(quán)限控制的呼聲是比較大的，我們也仔細分析和討論過權(quán)限控制這個方向，得出的結(jié)論是：“權(quán)限，看起來很美，做起來要命”。
A、業(yè)務(wù)部門期望太高。權(quán)限結(jié)合文件，的確是完美的控制，也是業(yè)務(wù)部門（需求方）的呼聲。對這么一個完美的東西，大家對這個項目的期望必須是80分以上的。在這個期望之上，如果我們做到了80分，那是勉強及格，如果低于80分，那就是一個失敗的項目了，項目如何走下去？如何驗收？如何。。。？由于各種周知的原因，終端數(shù)據(jù)防泄密項目想做60分就不容易，更別說80分了。這類項目一般是企業(yè)高管或業(yè)務(wù)部門逼著IT部門做的，一般來說IT部門都不愿意主動折騰這事，因為給別人找麻煩，就是給自己找麻煩，項目風險太高，IT部門的投資回報率太低。
B、很多東西看起來很美，但落地（落到責任人）就有問題。如果企業(yè)每天文件流轉(zhuǎn)300個的話，誰負責權(quán)限的設(shè)置（用戶數(shù)*權(quán)限*文件數(shù)=天文數(shù)字）？權(quán)限給誰？誰負責流轉(zhuǎn)時的權(quán)限變更？變更結(jié)果如何審計？誰審核權(quán)限是否有被濫用（做了權(quán)限，領(lǐng)導能不要求出這個審計報告嗎？誰來出？IT部、審計部還是業(yè)務(wù)部？）？誰負責舊文檔的權(quán)限的設(shè)置，如何設(shè)置？誰來決定以上所有問題？看到了吧，這一堆的問號，千萬不要輕易的回答，因為交流的時候可以隨意說，但是實施的時候要落實到具體的責任人或角色的時候，大家是最怕?lián)熑蔚摹＿@些責任分不出去的話，IT部的同學估計就只有自己扛著了。
C、權(quán)限管理有不少問題，一旦被繞過，那就是批量的丟失文檔。簡單的方法都不少，就不贅述了，說個案例吧。我一哥們所在的公司用了微軟的DRM，離職前他問我，他想搞走一些文檔，咋繞DRM，我還沒來得及回復他，他就說：網(wǎng)上說用虛擬機就可以搞定。退一步說，個別的文檔流失是可以容忍的，但是批量的文檔丟失，DLP項目的意義就會受質(zhì)疑了。
D、某些公司實施過基于文件權(quán)限的DLP，最后項目還是掛了。掛的原因就是上述的A+B。
E、業(yè)務(wù)部門對權(quán)限的呼聲很大，怎么辦？這個就要看我們控制項目需求的能力了，和業(yè)務(wù)部門及高管溝通，特別是在需求調(diào)研的過程中，可以通過調(diào)研表很好的引導相關(guān)人員的需求。數(shù)據(jù)防泄密本來就不是一蹴而就的事，必須從多個維度，結(jié)合管理及技術(shù)手段完善的。我們可以把權(quán)限的需求放在應(yīng)用系統(tǒng)里面做，比如PDM，OA等，通過對這些系統(tǒng)的改進，而實現(xiàn)權(quán)限管理。另外可以把數(shù)據(jù)防泄密項目分期來做，一期做成60分，二期想辦法奔80分。話說如果項目管理等務(wù)虛的工作做的好的話，60分的期望或許會帶來80分的收獲的。所以說選擇一個正確的供應(yīng)商和正確的項目經(jīng)理非常重要。
6、成功案例考察很重要。
我們得選擇一些供應(yīng)商的成功案例進行考察，當然，如果可以考察到失敗案例就更好了。通過這個考察，我們可以從第三方考察前面說的1、2、3、4點。這里面也有一些竅門，一是我們自主選擇案例，二是問題要設(shè)計好，三是要注意觀察。
在這里我不點名的說一下，某些供應(yīng)商還沒驗收的“成功案例”就真別拿來忽悠人了，最后可能會令你們自己難堪的：）
說在最后的話：
當我在這個項目之前，領(lǐng)導說了三年前我們失敗過一次，產(chǎn)業(yè)集團的人也在這個上面碰過釘子，事業(yè)部也栽過跟頭，是個硬骨頭，但我堅定的啃了。
當我在這個項目之中，我感覺有非常大的壓力，非常的累，非常的坎坷，偶爾晚上做夢都會夢到這項目的事情，但從頭到尾都非常有信心。
當我回頭再審視這個項目的時候，整個過程還有不少可以改進的地方，但我感覺非常有成就感和收獲感。
【編輯推薦】
