但是绝大多数，应该也都面临着一个很现实的问题：
安全是为业务服务的，业务部门为了方便，为了效率，为了性能……
总之，有一大堆的借口，阻碍我们对他们做安全防护，终端管理软件他们不愿意装，说兼容性不好，密码保存在本地不愿意改，说要不换你每天登陆几百台服务器挨 个维护试试？补丁不愿意打，右下角的金黄色小盾牌几个月来一直孜孜不倦的提醒：有可以安装的更新，就是不舍得把鼠标晃过去点一下……
更不用说什么离开座位必须锁屏，禁止使用U盘，禁止系统弱口令，禁止共享写入……
好像安全部门就是一个找茬的，今天说这里不对，明天说那里不好，业务部门和内部客户的需求到了安全部这里总是被抑制，久而久之，安全部门在谁眼里看着都不顺眼。
安全部也委屈：我这么做也都是分内之事，我也不愿意管这管那的，你们不听我的，天天中毒，老板最后还是得骂我。
解决这个问题（也就是有些朋友说在企业里推送ITIL和安全策略比较困难的问题），不能单纯靠标准，不能靠流程，自然也不能靠技术，需要的是智慧。
说到智慧，这是一个很高境界的词语，我轻易不敢说的，怕玷污了这个词。而且，一般来说，智慧是只有道，没有术的，而我所能理解的，似乎总是那么几个可以直接实践的“术”。所以，高手看到了就笑过吧。
在我自己的经验中，总结出了推行安全策略又不至于被抵抗的几条经验：
1. 自上而下
2. 事件触发（避免激进式的变革）
3. 注重用户体验
4. 把握强势的度
5. 占据制高点
6. 贴近核心业务
1. 自上而下
这一点在不少的标准和流程文档里也都提过了，老板签字并发布的安全规范、标准流程、操作手册，小的们往往还是会畏惧三分的，至少比以安全部的名义发布的要强。
而要让老板签署发布，并在同学们不听话的时候抓一只鸡出来打手板心给猴子看，尤其需要智慧。
什么样的智慧呢？威逼利诱？坑蒙拐骗？
其实老板不傻，老板天天想着一个问题，那就是企业的风险，外面的竞争对手，自己的运营成本，大环境的恶化，老板考虑的风险是关乎到公司全体员工有没有季度奖金的或者还能不能继续发工资的。
所以，针对公司的现状做一个风险评估，把老板最不愿意别人看到的核心资产截个图，把你需要说明严重性的安全问题分别做个PPT，写上几句话发给老板，基本上这事就定了，老板肯定会关照业务部门的头儿：你们的安全很成问题，要听安全部的。
做到这一点，不是一蹴而就的，也不是屡试不爽的，需要持续不断的和老板沟通，当然了，记住我在一楼里提到的，和老板沟通的时候要能够占到老板的层面上，说老板感兴趣的话题。
2. 事件触发（避免激进式改革）
要知道，人们的惰性是可怕的。
财务室的报销老太婆，每天板着一张脸，谁找她要钱她都要刁难万分。
这样的同事，你想要改变她的电脑桌面墙纸，都会遭到拼死的抵抗，以后再想报销打车费，没门～
同理，业务部门的用户习惯也是不容轻易改变的，即使你提供了一个更省事，更高效，更安全的替代方案，对不起，他们会说，那只是对你自己更省事，我不想改变现状的一切。
因此，有些经验丰富的同学上来根据各种安全标准，流程，内控的专业知识，制定了一大把的安全规范，写了一叠的文档。
结果这些文档发布以后，没多少人知道文档里高深莫测的专业术语是什么意思，一切仍然没有改变。
要么就是天天缠着老板，让老板帮助自己把这些安全规范和流程文档统统推出去，最后业务部门实在受不了了，集体跟老板吹耳边风，后果不堪设想。
所以，稍微高明一点的同学不会一下子把所有的问题都解决掉，更不会激进式的变革原有的习惯。
我们建议留心公司发生的各种安全事件，从安全事件表象背后推出其深层本质原因。然后逐个建立相关的流程和规范出来。
例如，财务部门一台办公电脑中毒，经过检查发现是因为管报销的大姐用了一个带病毒的U盘被感染的。
那么，安全部除了要从技术上免疫U盘病毒外，还可以将全公司禁止使用U盘的策略推出去（当然了，如果有些业务确实需要使用移动存储，也是要灵活把握的）。
不敢说做到100%有效，但是这种基于事件触发的安全策略，往往很容易得到老板的支持。
所以，出现安全事故的时候，不少安全部门都会叫苦不迭，生怕老板又责备下来，其实，这正是借机发挥的时机，可以跟老板暗示某些策略没人遵守，某些资源还不足，某些防线还没建立……
3. 注重用户体验
安全策略也是有用户体验的。
举例来说，弱口令使用问题，既可以通过管理制度规定不允许使用弱口令，也可以通过技术手段对密码设置的过程做复杂度检验。
但用户确实很难记住复杂的密码，更何况我们还要求别人每一套系统都要有不同的密码。
那么，采用一套密码管理系统，自动生成复杂密码并保存，使用的时候，用户只需要复制粘贴即可连接服务器的时候，弱口令现象就少多了。
因此，做安全策略的时候，还需要仔细考虑：在满足安全需求的同时，如何最大的兼顾用户习惯问题。
4. 把握强势的度
安全部门必须强势，因为我们是策略的制定者，我们要做安全策略，去审计和抓违规典型，以确保安全策略的权威性。
但是，强势必然导致反感，尤其是有利益纷争关系的部门leader之间的对话。
因此，又不能够太强势。
中庸之道讲究不偏不倚，恰到好处。
这个境界我自己也说不清楚什么样的标准是合适的。
但是必须要提醒的一点是：
安全既不能一味的做坏人，抓典型和打PP都是会损伤自己的亲和力的
但是也不能过于软弱，否则分蛋糕的时候，弱势的部门分到的那一块必然是最小的，弟兄们辛苦忙活一整年，都指望你给他们带来好处呢
5. 占据制高点
很多安全团队仅仅将自身作为安全领域的专家，却忽视了，安全团队的成员常常有一部分“黑客精神”（这里的黑客精神是指原始的定义，喜欢钻研，喜欢学习，喜欢追根究底，喜欢创新，并且这种学习的驱动力极强，可以使无数非计算机科班出身的小朋友变成安全界的名人）
基于这种异于常人的学习驱动精神，安全部对特定的技术理解往往会比一般的业务团队高出很多。
例如喜欢搞搞缓冲区溢出的，看本书对逆向工程就能熟手熟脚的，也许能为软件安全做出点贡献，出现计算机异常的时候从DUMP文件里也能追查出更精确的线索来。
喜欢研究Rootkit的，对操作系统的理解肯定比一般运维团队的操作人员要强，服务器维护有点什么需求都可以帮忙解决。
喜欢写一些脚本（BAT,VBS,PERL,PYTHON……）的同学，可以帮助业务部门制作简易脚本提高工作效率，将工作都自动化、工具化、无人值守化，减少人力成本的同时提高效率，还降低了对人的依赖，降低了出错率。
等等等等。
最后，安全部往往还肩负着一个职责——技术兼管理顾问
业务部门出现一些小问题，都可能会尝试着寻求安全部的帮助。哪怕是网络故障了，服务器小毛病了，都借口说：帮我查查是不是安全问题，为什么出现这个症状。
别怕，在不影响安全部门战略计划实施的同时，有空就义务做做这些额外的劳动，它会帮助我们树立一个咨询顾问的形象，确立安全部在技术和管理上的地位，保证 占据制高点，年底分蛋糕的时候，也能够多一条有竞争力的筹码：我们团队的技术和管理水平都很高，他们都是很有能力的人，平常做完安全的本职工作，一直帮助 业务部门解决各种疑难杂症还提供自动化工具脚本，帮助提高工作效率。
6. 贴近核心业务
在《杜拉拉升职记》第一部的结尾部分，杜拉拉在飞机上给一个陌生人指点职业规划，提到了一句：要贴近核心业务
其实安全也一样，
如果没有能够贴近核心业务，一直在外围打打擦边球，就不可能真正的实现组织的信息安全目标。
楼上的朋友提醒了要调查清楚组织的信息安全需求，其实隐含的另一层意思是：每个企业的业务和组织架构，核心资产的使用和存储，转移方式都有不同，自然每个企业的信息安全需求就不一样。
而除了一般泛泛的办公网环境的安全外，大头工作就依附在企业核心业务上。
我们可以想象，门户网站的安全需求、在线交易平台的安全需求、网络游戏的安全需求、实体制造业企业的安全需求，
都有不同。
身为甲方安全人员，你对自己企业的业务够了解么？业务所依赖的数据从诞生到服务交付全过程流向都清楚么？企业的IT架构图和风险管理威胁点都有哪些？
这些问题可以是CIO考虑的，安全部做个小棋子去执行
也可以是安全部去考虑的，然后兼任CIO的职责。
主动承担更多责任的人，会被赋予更多的责任。
当然，多数情况下责任和蛋糕是成正比的。
本文还暂无回复