这个项目涉及形形色色的角色：国内外供应商、大集团的领导和同事、产业集团的领导和同事、事业部的领导和同事、试点部门的领导和同事；在这么多角色中，输出了各式各样的想法，也就有很多根杠杆，有的需要平衡，有的需要压制，有的需要抬高；多的不说，谢谢各位角色的支持和包容，特别感谢没中标的供应商们，你们在项目前期也给予了我很重要的支持和帮助。

今天在TT安全上看到一个名为《终端数据丢失防护部署中的5大安全技巧》，由于TT明文要求不能转载，我也就不转了，有兴趣的同学自己去注册个帐号看吧。

我非常认同文中的“在你推出部署数据丢失防护解决方案的第一个部门确定一些关键用户，根据需要对他们进行培训，并在测试阶段与他们密切合作。通过关键用户的帮助，可以避免非技术业务部门测试中出现的问题，也可避免部署中没有任何用户反馈的情形发生。”和“慢慢来，逐步推出代理和策略”这两个观点。

前者决定了我们是否可以很好的迈出第一步。小范围的试用是最关键的。在这个过程里，数据和事件运营非常重要，真的是要“积跬步”才有机会“至千里” 的。在这个阶段，乙方项目团队做的非常漂亮，他们的专业，稳健，快速，灵活让我十分佩服，也让我学到不少东西。

后者小步快跑的思路决定了我们的项目阻力。“积跬步”仅仅是一个开头，我们要“至千里”的话，还有很长很崎岖的路要走。我在这个项目里的感觉是前期一定要“小”，小为我们快速发现并解决大部分问题争取了时间和空间。

我还有一些其他的观点：

1、尽量避免把数据防泄密项目做成一个咨询项目

没错，前期的调研很重要，中期的展示很重要，后期的领导认可更重要，这些都要做漂亮，但我想提醒的是，管理手段等这些“务虚”的内容在这个项目里是非常必要的而且是非常重要的，但所占比例不宜太大，项目时间有25%在做这些东西事情就差不多了。

为啥？高楼大厦平地起，只有把“务实”的基础打好了，务虚的东西才能站的更高，更稳更久，一个如此复杂的项目，走的越空，问题越多，问题越多，越不利于务虚的东西；另外务虚的项目的验收是一个大问题。我不是想论证三分技术七分管理还是七分技术三分管理，其实根本没这必要，不同的行业，不同的企业，不同的领导要求都不一样，我的想法是如果条件允许的话，先跑稳，再跳高；如果条件不允许，只能硬着头皮先摸高，再软着陆了。

2、选择一个负责的供应商

素包子还是要感谢那将近20个供应商，但是坦白说，从我个人的判断来看，这些供应商各有所长，当然也各有所短。为了更好的提高数据防泄密项目的成功率，我觉得负责和经验丰富是最重要的。当然这不能凭口说，得看他们的作为。口沫横飞天花乱坠的说；但不着边际忽忽悠悠的做，实在是无法让我放心把项目交付给他们。我不排斥售前或者销售忽悠我，我也不想和他们去PK某一个细节的真伪，但我希望大家在做事的时候，一是一二是二。作为甲方来说，走错了这一步，啥都别说了，拿出勇气抽自己一巴掌，趁早回头是岸；下不了手或者要抽很多人巴掌？那就自求多福吧。

3、选择一个经验丰富的供应商

供应商的经验也很重要，我们不能做供应商在某个领域的小白鼠，应用市场细分的很厉害，安全市场也细分的很厉害，DL产品同质化也比较厉害；但在 DLP项目里不同行业之间经验复制程度还是有较大差别的，一个有经验丰富供应商可以传递很多经验给我们，给我们提供合适的方案，让我们少走弯路，少摔跤，这对数据防泄密这种用户敏感度较高项目来说非常关键。

至于国内还是国外的供应商，我们选择了国内供应商。原因很简单，你要想找老外按你的意思改个东西，dream!不过这个缺点对厂商自身来说也是优点，标准化，好维护，好服务，就看厂商的取舍和平衡了。

另外老外的DLP产品很少文件加密的，大多是权限、网关类的产品，还有需要考虑的是外国的加密类产品在国内是不允许销售的，小企业采购的话无所谓，大企业采购的时候要考虑法务风险。说到这个销售许可，有一些国内的厂商喜欢拿这个东西大做文章攻击国内的其他竞争对手。这些厂商也就是在许可这块投入了较多的精力，但这对项目的质量影响不大，不必太在意。

4、选择一个合适的产品

为什么素包子现在才说产品的问题呢？因为结合我们个人的认识及前期与各供应商洗脑，及互相PK的结果，再结合2、3两点，会自然而然的输出合适的 DLP大方向（文件加密、磁盘加密、格式转换、权限控制、网关控制等）及产品，这是一个水到渠成的过程。退一步说：产品要不好可以改进，但供应商有问题的话，那可不是说换就换的。

什么叫合适的产品？素包子的理解就是符合满足多种角色需求的产品，项目所处的环境越复杂，我们要满足和均衡的人和事就越多，下面列举一些有共性的需求：

A、满足企业高管需求的产品。

B、满足项目经理领导需求的产品。

C、满足项目经理需求的产品。

D、满足维护人员需求的产品。

E、满足使用人员需求的产品。

横向再插入三个关键词：稳定，简单，可靠。

以上几点看似废话，但要真的想清楚，权衡好，再做好，对甲方和乙方的项目负责人都是非常大的挑战。换一个说法可能更好理解，这里面的众多角色想通过这个项目让什么人可以获得什么，规避什么，说明什么，推动什么，阻止什么。

作为项目负责人，我们得搞清楚keyman是哪些人，我们选择的产品的输出能满足他们的需求吗？需要提醒的是，在项目的不同阶段，keyman有可能是变化的 ：）哪怕在试点测试的这一个阶段里，不子阶段的keyman也不一样。

至于稳定、简单、可靠。就不用说太多了，一个要在3万用户终端上跑的东西：

能不成熟吗？三天两头就崩溃或者占用大量资源，上述 C、D、E人员也会跟着崩溃的一塌糊涂，进而A、B人员崩溃，项目夭折。

能不简单吗？我一直认为一个优秀的产品就要做到”dont make me think”，几万人，就算我们培训，发手册，有30%的人看就不错了，即使还有5%不到的IT人员能自学，那剩下的65%的人中如果每天有个1%的E人员打电话问D咋用，那大家也是崩溃的。这里说的简单并不是单纯的简单，而是产品设计者要真正从用户的角度去考虑和实践，才知道怎么样才是从架构上、从流程上、从产品上真正的简单，当然接受用户的反馈并改进这非常有利于做到“简单”，这也是国内产品的潜在优势，国外产品你给Y反馈个想法，不管好是不好，日后再说吧。

能不可靠吗？如果不可靠，可能会在务实和务虚的层面的 ABCDE人员中全面起火。当然我也是做安全的，我也知道安全是需要均衡的，所以我对可靠的定义是：首先能正视问题，然后能主动的发现问题和快速的解决问题，如果短期内不能解决问题，就必须提供缓解方法。

正如实施SDL，我们不怕0day漏洞，只怕出了0day后无法快速发现，更怕发现了没响应或不及时，还怕响应了但解决不了问题。SDL里的一些 mitigation手段就是缓解问题的好方法。

上述成熟和简单的问题或许有点夸张和孤立，但是当放大到一个很复杂的环境里的时候，还真可能有这么夸张，即使真没那么夸张，但是用户就说的这么夸张，供应商也挺头疼，虽然有一些办法缓解 ：）

本文持续更新，最新版本请访问《数据防泄密项目经验分享》 http://baoz.net/share-the-experience-of-data-lost-prevent-project/

5、成功案例考察很重要

我们得选择一些供应商的成功案例进行考察，当然，如果可以考察到失败案例就更好了。通过这个考察，我们可以从第三方考察前面说的1、2、3、4点。这里面也有一些窍门，一是我们自主选择案例，二是问题要设计好，三是要注意观察。

在这里我不点名的说一下，某些供应商还没验收的“成功案例”就真别拿来忽悠人了，最后可能会令你们自己难堪的：）

说在最后的话：

当我在这个项目之前，领导说了三年前我们失败过一次，产业集团的人也在这个上面碰过钉子，事业部也栽过跟头，是个硬骨头，但我坚定的啃了。

当我在这个项目之中，我感觉有非常大的压力，非常的累，非常的坎坷，偶尔晚上做梦都会梦到这项目的事情，但从头到尾都非常有信心。

当我回头再审视这个项目的时候，整个过程还有不少可以改进的地方，但我感觉非常有成就感和收获感。

被我们选上的那家供应商，素包子真诚的谢谢你们宝贵知识和经验的传递，谢谢你们对我们工作的支持，你们比我们累多了，嗯，是有点恶心，但出自真心。