一个人的企业安全建设之路

如今很多中小型互联网公司对安全需求不高，安全资源贫乏，领导只重视业务忽略安全，在这种情况下可能安全人员很难立足，推动公司做好安全，从而进入了进退两难的窘境，目前从事国内某车联网公司，公司团队在300人左右，生产服务器数量在千余台级别，业务线冗长，以下给各位介绍一下个人的工作经验：

一、熟悉环境

该部分为后续工作做铺垫，所以此部分工作也是十分重要的，首先需要有如下三个图：

1、架构图：第一步就是要了解企业的组织架构，认清哪些部门是跟自己紧密相关的，哪些部门是日后可能开展合作的，安全信息应该发给谁，这些都是十分必要的;

2、拓扑图：第二步是熟悉网络环境，公司之前也可能采购了一些安全设备，这些设备是如何部署，的部署在哪些机房的哪个节点下，会有助于以后故障排查;

3、业务图：第三部是熟悉业务，这也是最困难的，一个企业可能有多个业务，每个业务分部在不同的机房与服务器上，这些就算无法完全梳理透彻，也要有一个简单的了解与掌握;

二、基础安全工作

基础性的工作不难，但琐碎，比如：周期性安全测试、设备运维、弱口令审计、外网端口监控、等保测评以及安全策略审批管控等，如何优化做好这部分工作十分重要：

1、策略管控：部分业务进展需要安全部门审批，如果对业务非常熟悉的情况下可以坚持安全性的原则去审批，但往往并没有那么熟悉，况且还是一个人的情况下，可以先放宽条件，日后再逐步缩紧，但不要成为背锅侠，该提的原则要提前表明，锅要先扣到业务部门头上，这样才方便做事;

2、安全测试：在有限的时间内周期性对重点业务进行渗透测试，每次迭代更新可以选择性做测试，比如大版本改动时，并且可以将安全测试放在SDL里面，在 SDL阶段会介绍我的方式方法，在这不做过多解释;

3、设备运维：期初还是需要了解一下安全设备的，如堡垒机、WAF、IPS 等，不出问题则罢，一旦影响其他用户使用如堡垒机，变会比较头疼，建议提前了解好设备处故障的“套路”;

4、账号审计：弱口令是一个极其简单而威胁程度又特别高的安全隐患，性价比极高，所以关键系统的弱口令一定要排除，必然是放在基础工作之中的;

5、外网端口监控：端口监控刚开始可以直接用Nmap扫描，手工肉眼核查，没有特殊端口开放即可;

6、等级保护：这点不需多说了，都是套路~~~

三、优化工作

根据上述基础工作大致可以看出，某些工作是可以优化的，如果你不优化，自己一个人无休止的搞下去，要么公司死，要么你死。

1、端口监控自动化：外网端口监控每次都手动扫描，然后人工肉眼核查是特比Low的方式，完全可以靠脚本自动化完成， python里面包含了Nmap模块，可以返回扫描结果，效率虽然比直接使用Nmap低一点，但也可以将就，所以第一步就是抽时间写了自动化的监控脚本，当然也可以借助巡风这样的系统去监控扫描;

2、弱口令死于初始化：弱口令审计重点把控几个位置，邮箱、VPN、以及即时通讯软件(当时我们用的是 RTX)，其中VPN每次是管理员创建且用户无法自己修改密码，一般没什么问题;企业邮箱我们在密码修改功能模块强制添加密码复杂度策略，弱口令无法通过;RTX 已经弃用，并不需要付出太多精力，这样一来弱口令审计工作也从此消失。

3、安全扫描：如今的AWVS11已经支持Web 界面，更加直观，如果再汉化一下就更加得心应手，既能体现扫描结果，还方便各部门人员使用，可以从一台机器上搭建后由各项目组自行去扫描测试，会变得更加方便。

四、SDL安全开发周期

一个人的SDL安全开发周期?是的，没错，安全部门仅一人，如何推动?许多大型互联网公司举全团队之力都难以完成的项目，如何一个人去完成，近期也跟朋友简单聊过，得到了认可，答案就是“ 阉割版的SDL”，国外的东西不要照搬，也未必合适，但思路可以借鉴，下面介绍一下个人的思路：

1、明确目标： 要明确自己的目标，什么是SDL，自己能做多少，要评估出最终的效果，在我看来 SDL简单概括就是：减少漏洞频率、降低人力成本。因为传统的安全测试基本都在上线前，漏洞不断重复出现，开发人员再重复修改，效率极其低下。

2、团队支持：其次才是得到各项目组负责人的认可，刚开始大领导支持还好，不支持的话小领导支持一下也不错，当然要让他们知道推动SDL 的目标是给他们减轻工作量，而不是增加成本。然后从各项目组安排一名 “安全负责人”，这样很多安全工作的落地对接，业务信息的收集就比较方便了，并且还安排他们讲问题代码做整理统计，形成内部的 “ 漏洞库 ”，以此作为SDL的基础。

3、项目选择：项目选择也十分重要，有些项目领导压得紧，别说SDL了，正常的安全测试都做不完就需要紧急上线，这种并不适合你自己去搞 SDL，可以选择一个迭代没那么快，最好周期性的项目最佳。

4、安全负责人核心价值：每个项目组的“安全负责人 ” 作为接口人主要两方面作用：第一是在开发过程中能看到功能的实现方式，可提前避免出现安全漏洞;第二是在开发后修复漏洞时可以协助安全人员归纳总结，提取案例，将修复后的代码提取出来供其他项目组参考，这样无形之中减少了很多沟通与重复撸代码的成本，后来发现安全负责人这个概念在唯品会有使用。

5、他山之石：从测试部门“借人”，做功能测试的人员要比安全测试人员更加熟悉业务，这样其实更容易发现细微的逻辑漏洞，所以跟测试部门强强联手也是是非必要的，这块参考京东的一部分做法。

五、制度推动

具体落地时还会有很多问题，很多工作空口无凭，口头承诺不代表一定会做，所以有相关制度流程是一种控制措施，但不是完全有效的，比如：

1、所有上线走JIRA，安全审批后才能上线;

2、安全负责人不会平白无故给你干活，能在制度绩效上为他们谋福利一定要去努力;

3、每月定期召开安全月会，请大领导参加，并将目前的安全问题抛出来由大领导排版定夺;

六、安全意识

最后来说安全意识，也是贯穿始终的，目前以培训方式为主，地毯式轰炸为辅，尽30%努力去覆盖70%的成员就觉得已经成功了，做安全不要总想着 100%，实际工作主要是：

1、平台搭建：公司内网搭建信息安全中心(包含乌云的镜像网站、XSS跨站平台;攻防演练平台、 AWVS远程扫描、以及巡风系统)，来源都是比较简单的开源系统，但方便推广，也比较实用一些，主要是有一种归属感，起码有个平台属于自己;

2、安全培训：安全意识培训可以对公司的人力、财务、新员工等做培训，偶尔也发几个钓鱼邮件给被培训的同事(20% 中招概率)，都是比较好玩的过程;

3、安全文章：如果公司有内刊的话可以写几个安全科普的文章，虽然很多人不看，但领导偶尔闲暇会瞄一眼，不要放过任何一个角落与机会，包括此文也希望更多中小型企业借鉴推广，希望提供参考价值。