破局

很多刚独立开展安全工作的小伙子本身技术都很好，但是初始做一个人的安全部容易莽撞。笔者尤其记得第一次接触甲方安全岗位时，领导面试问到:“为了公司安全建设，你准备着手怎么做？”，笔者的回答是“引入CVSS3.0评分机制......”,现在想来依然令人汗颜。笔者想到有一些关于工作的真相，为一些埋头做事，不到心战的层次的小伙子写出来。大家简单看下，本文内容有对有错，缺一漏万，多谈权，少谈责，欢迎批判，本文配合基层安全管理者需要具备的素质阅读效果更佳。

权责的游戏规则

做安全要同运维、开发团队、法务团队打交道，需要领导授权，授权的开始时做事情、能做成事情的数量和质量，决定了部门领导为其逐步授予权利的范围和大小。刚开始后不要急着要授权，如要求对开发的绩效占比20%的安全考核，而是要先干活，有了责任就有了权限。先从上任初始自然有适当的权利找具体的事情干，当把事情干漂亮后，权利就归你了。不要急于表现发力，一下领的任务太多，涉及环节多了，就压垮自己，容易暴露问题。注意要区分你入职的角色是干活的劳动力（典型特征是挂在IT下面的运维下面的小安全），还是补充的角色（向首席行政官汇报安全的某公司），如滴滴那样首席信息安全官向首席技术官（CTO）汇报和360集团首席安全官（CSO）向集团CEO（周鸿祎）是比较合理的。安全从业人员推脱管理者不重视安全的理由，因为高管受到的网络风险教育正是来自IT与安全负责人，而你也做到负责减轻衡量和汇报风险。法律规定企业老板是信息安全的第一责任人，为了企业生存发展必须像抓紧法务、财务一样抓住安全。

知情权

好的开始是从做一次等级保护\HW\大应急之类的合规审查，牵涉到产品资质和影响力的事情，又有第三方评估机构背书，领导觉得之前做的不够，终于有人懂开始抓起来了。以安全人员擅长的信息安全体系为标准，推广到IT的资产排查、人员岗位梳理、制定补全规章制度，稽核安全记录内容。从知情权破局，参加安全制度制定的会议，听取运维总监、负责开发的各种总监总裁的报告，看到基础设施的架构设计和资产大盘材料。让同事知道做好安全是政治正确的事，对他明白对上级可以汇报出加分项。除了职务规定要参加列席的会议外，要多参加接触半公开的讨论。以合适的名义接触到信息的圈子。往往在召开会议前后的讨论，是最真实关键的信息。开会多了，就是认为是有关的大佬，可以发挥影响力了。

合作权：要让自己的观点更犀利

就如我之前说的那样，在公司搞安全要“政治正确”，拿起安全的理由，谁也不敢不从。所以一旦提出安全的建议时，必须要有权威性，提出建议后也势必要有可行性，可行性优于必要性。拿出不切实际的断网建议，会被业务背后说书呆子的。国外有一个趋势是工程师不是从上至下地进行集中安全性活动的集中式安全小组，而是由下而上地领导软件安全性工作，但是不适合国内。推动信息安全任务从小兵着手最简单，可以让安全工程师多接触，但是推动任何事情，一定要从上层贯彻开始，没有捷径可走。

内部合作

以威胁建模谈合作，建模看起来高大上，本公众号也阐述了一些实践，千万不要畏于开展这类协作练习。搞这些事的本意是有助于项目在立项和设计的最早阶段识别潜在问题，为安全测试计划提供必要信息指导（首先要有安全测试.....）。对重点项目早期介入，将来自交付团队，安全部门，业务利益相关方以及双方领导聚在一起，讨论假设攻击者将拥有什么资产，攻击者如何精心构造漏洞进行攻击来gain access。然后团队一起将这些对应用程序和支持基础结构的潜在威胁进行分类，并集体讨论缓解这些威胁的对策形成会议纪要。当安全和交付团队就威胁模型进行协作时，他们能够将安全构建到应用程序的设计中，讨论安全影响和权衡因素（例如成本，进度和改进范围），不要担心做的不好，反正没有文档参考，对于旁人你就是安全专家。

外部合作

莫道君行早，更有早行人。参与一些沙龙，组织中最优秀和最聪明的人有机会在一个大型舞台上分享他们的知识和技能。多看ppt真的可以提高视野，哪怕学不能致用，颠覆自己的认知也是进步。和国际一线厂家仔细对标，也好和领导说：我们现在做的如何如何，距离差距如何如何，缺XX资源......

检查权：管理是受罪，技术是受累。

安全的检查工作是指出安全漏洞，督办业务的修复进展，复查业务修复百分比，千万不要身体力行的为业务开发个补丁，你会陷入甩锅的汪洋大海（业务说因为你给业务开发补丁，所以修复慢，修复效果差，角色反转了）。给出具体的建议和安全要求时，可以适当妥协。互相合作就意味着没有人能够命令别人，强加意志于别人。技术人员以自己是搞技术的，不需要妥协是大错特错，是偷懒不努力的借口，是舍不得为了达成目标放弃自尊。哪怕是高管也要妥协、生闷气、抢资源、担心被底下人愚弄。要做成事就得沉住气，承受压力才能做难事，总要有点理想主义的。做成事的动力来自于拥护，而不是上级赋予职责。在推动运营的过程中不要害怕失败，可以对负责人坦承说我们目前系统建设投入小，时间短，有什么什么不足，不要因为安全的面子而慌张掩盖，正视差距，不断复盘。

审批权

上线前的安全检查是典型的审批权。选择SDL合入企业开发流程并不是要全面检查每个流程，而是要添加定义明确的安全性卡点和安全性可交付成果。要推行业务方的软件本身就是要做到默认安全的，不应该引起安全插手让开发人员增加工作量做了安全功能的错觉。做SDL的要求是懂开发、也要懂安全，所以很容易陷入的舒适区是去做开发安全，而在应急响应阶段方面放手，不管是技术攻击、物理入侵、社会工程学，都囊括在SDL阶段，在区分红蓝队职责和范围的时候，可以适当掌握审批定级权。

声明：本文来自安全乐观主义，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。